Re: [PATCH v2] IB/mlx4: silence GCC warning

[Jack Morgenstein]

On Monday 25 February 2013 19:23, Roland Dreier wrote:
> On Mon, Feb 25, 2013 at 8:54 AM, Roland Dreier  wrote:
> > I'm finally noticing that this is in the build_mlx_header() function,
> > which is pretty much a slow path.  Certainly another compare isn't
> > going to change performance given all the other stuff we do there.
> >
> > Let me look at the patches that have gone by and see what the cleanest
> > way to handle this is.
> 
> OK, after playing around a bit, I see that just initializing vlan
> doesn't really change the generated code (my gcc at least was already
> if effect setting vlan in the generated assembly code), so I'll just
> merge that.
> 
>  - R.

Thanks!

-Jack 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

[Yasuaki Ishimatsu]

Hi Yinghai,

2013/02/26 15:57, Yinghai Lu wrote:

On Mon, Feb 25, 2013 at 10:09 PM, Tang Chen  wrote:

On 02/26/2013 12:51 PM, Martin Bligh wrote:


Do you mean we can remove numaq x86 32bit code now?



Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
Was useful in the early days of getting NUMA up and running on Linux,
but is now too old to be a museum piece, really.

M.



Hi Martin, Yinghai,

It was me that I failed to make numa_init() fall back path working, and
forgot
to call early_parse_srat in ia64. Sorry for the breaking of other platform.
:)

So now, is Yinghai's patch enough for this problem ?
Or we can encapsulate the following clear up work into one function ?


+   for (i = 0; i < MAX_LOCAL_APIC; i++)
+   set_apicid_to_node(i, NUMA_NO_NODE);
+   nodes_clear(numa_nodes_parsed);
+   memset(&numa_meminfo, 0, sizeof(numa_meminfo));




That is temporary workaround and your patch and this workaround make
x86 acpi numa init too messy.

I don't see the point to hack SRAT to make memory hotplug working.

Do you guys check and use PMTT in ACPI spec instead?


I read PMTT specification in ACPI spec revision 5.0. But this table
does not have hotpluggable information. So we cannot know which memory
device can hotplug from this table.

Thanks,
Yasuaki Ishimatsu



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




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

Re: [Ocfs2-users] Kernel panic due to ocfs2

[richard -rw- weinberger]

On Tue, Feb 26, 2013 at 7:31 AM, Srinivas Eeda  wrote:
> This is due to a race in lock mastery/purge. I have recently fixed this
> problem but haven't yet submitted the patch to mainline. Please file a
> Service request with Oracle to get a one-off fix.

Please submit the patch immediately.
Why does one need a f§&"!#$ SR from Oracle to have this fixed?
OCFS2 is mainline...

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

Re: [PATCH 00/10] ipc MSG_COPY fixes

[Stanislav Kinsbursky]

Looks good to me. Thanks you, Peter!

Acked-by: Stanislav Kinsbursky 

Next time please, add maintainer to "To" list instead of "CC" list (no need to resend - 
I've added Andrew Morton to "To" list in this reply).

26.02.2013 06:21, Peter Hurley пишет:

Over the weekend testing with trinity on KVM, I hit a similar oops
(pasted below) to what others have already reported here
  http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html

While trying to uncover the underlying cause of the list corruption,
I uncovered two other bugs which are addressed in
   ipc: Fix potential oops when src msg > 4k w/ MSG_COPY
   ipc: Don't allocate a copy larger than max

The other cleanup was incidental to trying to uncover the oops (so far
unsuccessfully).

Can the alloc_msg() be further simplified to allocate one block with
vmalloc() and link the msg segments in-place?


[   86.026309] BUG: unable to handle kernel paging request at 00058134
[   86.035004] IP: [] testmsg.isra.5+0x30/0x60
[   86.035004] PGD 5ff2d067 PUD 5ee34067 PMD 0
[   86.035004] Oops:  [#1] PREEMPT SMP
[   86.035004] Modules linked in: can_bcm bridge stp dlci af_rxrpc ...
[   86.035004] CPU 5
[   86.035004] Pid: 1736, comm: trinity-child37 Not tainted 
3.9.0-next-20130220+ldsem-xeon+lockdep #20130220+ldsem Bochs Bochs
[   86.035004] RIP: 0010:[]  [] 
testmsg.isra.5+0x30/0x60
[   86.035004] RSP: 0018:88005ee2fe78  EFLAGS: 00010246
[   86.035004] RAX:  RBX: 0004 RCX: 0001
[   86.035004] RDX: 0004 RSI: 8000 RDI: 00058134
[   86.035004] RBP: 88005ee2fe78 R08: 000b0ff4 R09: 
[   86.035004] R10: 0001 R11:  R12: 8000
[   86.035004] R13: 880061275c20 R14: 00058124 R15: 880061275b70
[   86.035004] FS:  7f9b37442700() GS:88007d40() 
knlGS:
[   86.035004] CS:  0010 DS:  ES:  CR0: 80050033
[   86.035004] CR2: 00058134 CR3: 5ff2c000 CR4: 07e0
[   86.035004] DR0:  DR1:  DR2: 
[   86.035004] DR3:  DR6: 0ff0 DR7: 0400
[   86.035004] Process trinity-child37 (pid: 1736, threadinfo 88005ee2e000, 
task 88005edaa440)
[   86.035004] Stack:
[   86.035004]  88005ee2ff68 81309c06 001d5b00 
88005edaa440
[   86.035004]  88005edaa440 88005edaa440  
813085e0
[   86.035004]   88005ff7e458  
006fe000
[   86.035004] Call Trace:
[   86.035004]  [] do_msgrcv+0x1d6/0x6a0
[   86.035004]  [] ? load_msg+0x180/0x180
[   86.035004]  [] ? trace_hardirqs_on_caller+0x10d/0x1a0
[   86.035004]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   86.035004]  [] sys_msgrcv+0x15/0x20
[   86.035004]  [] system_call_fastpath+0x16/0x1b
[   86.035004] Code: 55 83 fa 02 48 89 e5 74 32 7e 10 83 fa 03 74 3b 83 fa 04 74 16 
31 c0 5d c3 66 90 83 fa 01 b8 01 00 00 00 74 f2 31 c0 eb ee 66 90 <48> 39 37 b8 
01 00 00 00 7e e2 31 c0 eb de 66 90 48 3b 37 75 d5
[   86.035004] RIP  [] testmsg.isra.5+0x30/0x60
[   86.035004]  RSP 
[   86.035004] CR2: 00058134
[   86.183799] ---[ end trace f8a403aaa782a5b4 ]---



Peter Hurley (10):
   ipc: Fix potential oops when src msg > 4k w/ MSG_COPY
   ipc: Clamp with min()
   ipc: Separate msg allocation from userspace copy
   ipc: Tighten msg copy loops
   ipc: Set EFAULT as default error in load_msg()
   ipc: Don't allocate a copy larger than max
   ipc: Remove msg handling from queue scan
   ipc: Implement MSG_COPY as a new receive mode
   ipc: Simplify msg list search
   ipc: Refactor msg list search into separate function

  ipc/msg.c |  84 +---
  ipc/msgutil.c | 109 +++---
  2 files changed, 90 insertions(+), 103 deletions(-)




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

Re: [PATCH 1/2] gpio: gpio-generic: Fix bug in big endian bit conversion

[Grant Likely]

On Sat, 09 Feb 2013 14:58:55 +, Grant Likely  
wrote:
> On Tue,  5 Feb 2013 11:33:02 +0100, Andreas Larsson  
> wrote:
> > The swap to convert LE to BE in bgpio_pin2mask_be should be on byte level, 
> > not
> > on bit level.
> > 
> > Signed-off-by: Andreas Larsson 
> > ---
> >  drivers/gpio/gpio-generic.c |5 -
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
> > index 05fcc0f..7f11537 100644
> > --- a/drivers/gpio/gpio-generic.c
> > +++ b/drivers/gpio/gpio-generic.c
> > @@ -112,7 +112,10 @@ static unsigned long bgpio_pin2mask(struct bgpio_chip 
> > *bgc, unsigned int pin)
> >  static unsigned long bgpio_pin2mask_be(struct bgpio_chip *bgc,
> >unsigned int pin)
> >  {
> > -   return 1 << (bgc->bits - 1 - pin);
> > +   unsigned int bit = pin & 0x7; /* Bit number within byte */
> > +   unsigned int base = pin - bit; /* Pin that is bit 0 within byte */
> > +
> > +   return 1 << ((bgc->bits - base - 8) + bit); /* shifted base + bit */
> 
> Ah, sorry for my previous reply. I see you have seen gpio-generic.  :-)
> 
> No, the original calculation is correct. BE and LE bit numbering are
> opposite, bit Linux always uses LE numbers as far as bit masks are
> concerned. Therefore pin 0 is the most significant bit, and
> pin (nr_bits-1) is the least significant bit.

Hi Andreas,

Actually I'm wrong here (at least partially) after looking closer at the
generic gpio driver. The problem is that things get messed up on 16 or
32 bit access depending on how the hardware expects to be accessed.
bgpio always uses iowrite/ioread for register access which is inherently
little endian, but if the hardware is wired up as a big-endian device
then you have to do the fiddly bit you did above to get the bit
positions to line up where you what then. So, there could potentially be
4 different ways to count bits on a value ioread() from a gpio register:

little-endian, LSB = 0 (sane)
little-endian, MSB = 0 (odd)
big-endian (bytes swapped), MSB = 0 (common on BE platforms)
big-endian (bytes swapped), LSB = 0 (why are you making my life hard?)

We /could/ have a ioread32be/write32be mode in the driver, but I don't
think that is the right approach. It means we need yet another set of
accessors for register except using the 'be' variants. Blech. What I'd
actually like to do is add a bitmask field to the gpio_desc which can be
calculated ahead of time to whatever madness is required from the way
the device is wired. Then the access routines don't need to even care.
they just apply the bitmask to ioread/iowrite and it doesn't even need
to know what the bit number actually is. The new support for gpio_desc
in the core code makes this feasable.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio/gpio-generic: Add OF bindings

[Grant Likely]

On Fri, 7 Dec 2012 16:10:17 -0700, Jason Gunthorpe 
 wrote:
> Allow the platform driver to bind through OF. The existing
> OF machinery for setting the resource names through OF is used to
> configure the device, so the change is minimally intrusive and
> fully featured.
> 
> Signed-off-by: Jason Gunthorpe 

Hi Jason,

Thanks for looking at this. I've wanted this feature for a while now,
but I haven't liked the bindings that I've seen so far because each
individual register is broken out into separate reg tuples. Blech. Too
much unlike existing bindings.

The root problem is that the bindings all try to match the current
basic-mmio-gpio pdata implementation which uses a separate resource
structure for each register, and the bindings have all followed that
pattern, but that runs pretty contrary to established device tree
conventions. What I'd much rather see is a single resource for the block
of registers and properties laying out the offsets to the registers and
the access width. I also think the method of access (dat, set+clr,
dirin, dirout) should be specified explicity, not implicitly by the
registers that are defined. I think the binding should also allow for
multiple register banks since several gpio devices are arranged that way.
Something like the following (rough draft, needs to be refined):

* General purpose MMIO GPIO controller

Required properties:
- compatible: "mmio-gpio"
- reg: Address of register block
- reg-io-width: Access width in bytes (1, 2, 4 or 8)
- #gpio-cells: Should be two.
- gpio-controller: Marks the device node as a GPIO controller.
- gpio-io-type: One of: "data"
Required depending on access mode:
- gpio-io-datain: list of offsets to data registers, one per bank
- gpio-io-dataout: list of offsets to data out registers, one per bank
- gpio-io-dataset: list of offsets to data set registers, one per bank
- gpio-io-dataclr: list of offsets to data clear registers, one per bank
Required depending on how direction is set:
- gpio-io-dirin: list of offsets to direction in registers, one per bank
- gpio-io-dirout: list of offsets to direction out registers, one per 
bank

There are two ways you can do this, adapt the current basic-mmio-gpio
driver to use a since resource region for the whole block, or create a
new driver that will work nicely with the binding I've described above.
I prefer adapting the current driver since there are only 4 actual users
of that driver in tree, and all of them are trivial.  It is easy to fix.

Also, it should be possible to move existing mmio gpio controllers over
to this new driver /without/ changing their bindings. (I'm not asking
you to do this, just thinking out loud). This can be done by adding
their compatible property to the match table and using the data field to
carry a pdata structure for that device.

g.

> ---
>  .../devicetree/bindings/gpio/gpio-generic.txt  |   28 
> 
>  drivers/gpio/gpio-generic.c|   18 -
>  2 files changed, 45 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-generic.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-generic.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
> new file mode 100644
> index 000..12b4989
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
> @@ -0,0 +1,28 @@
> +* General purpose MMIO GPIO controller
> +
> +Required properties:
> +- compatible: "linux,basic-mmio-gpio" or "linux,basic-mmio-gpio-be",
> +  the choice determines which bit is considered GPIO #0
> +- reg and reg-names: An array of named register ranges describing the 
> windows,
> +  in one of these combinations:
> +   * 'dat' - Single input/output data register.
> +   * 'dat', 'set' and 'clr' - 'dat' is the input and drive 1 writes high to 
> 'set'
> +  and drive 0 writes high to 'clr'
> +   * 'dat' and 'set' - 'dat' is the input and drive 1 write high to 'set' and
> +   drive 0 writes low to set
> +  Additionally one of these may be specified:
> +   * dirout - Write 1 to set as output, 0 to set as input
> +   * dirin - Write 1 to set as input, 0 to set as output
> +
> +  The size of the registers should be 1, 4 or 8.
> +- #gpio-cells: Should be two.
> +- gpio-controller: Marks the device node as a GPIO controller.
> +
> +Example:
> + gpio0: gpio@8 {
> + #gpio-cells = <2>;
> + compatible = "linux,basic-mmio-gpio";
> + gpio-controller;
> + reg-names = "dat", "set", "dirin";
> + reg = <0x8 4>, <0xc 4>, <0x10 4>;
> + };
> diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
> index 82e2e4f..f71a917 100644
> --- a/drivers/gpio/gpio-generic.c
> +++ b/drivers/gpio/gpio-generic.c
> @@ -458,6 +458,7 @@ static int __devi

Re: [PATCH] ptrace: add ability to retrieve signals without removing from a queue (v2)

[Andrey Wagin]

Andrew, thank you for the comments. I will fix them and send a new
patch. A few comments are inline.

2013/2/26 Andrew Morton :
> On Mon, 25 Feb 2013 14:06:53 +0400
>> + for (i = 0; i < arg.nr; i++) {
>> + off = arg.off + i;
>
> "long long" = "u64" + "int".
>
> Wanna have a little think about what we're doing here, see if we can
> pick the most appropriate types?

A number of signal has the type int, because the system call ptrace()
return "int" and my interface supposed to return a number of dumped
signals.
"off" is signed to check on a negative value and it can not be more
then MAX_RAM / sizeof(siginfo), so
long long is enough. It can be changed on s64 for avoiding misleading.

>
> `off' could be made local to this loop, which is a bit neater.
>
>> + spin_lock_irq(&child->sighand->siglock);
>> + list_for_each_entry(q, &pending->list, list) {
>> + if (!off--) {
>> + copy_siginfo(&info, &q->info);
>> + break;
>> + }
>> + }
>> + spin_unlock_irq(&child->sighand->siglock);
>> +
>> + if (off >= 0)
>> + break;
>
> 
>
> Oh I see what you did there - the user requested an entry which is
> beyond the end of the list? A code comment would be nice.
>
> What's the return value in this case?  "i".  So how does userspace find
> out what happened?

The request PTRACE_PEEKSIGINFO returns a number of dumped signals. If
a signal with the specified sequence number doesn't exist, ptrace
returns 0.

>
> Please fully describe the interface so things such as this can be
> understood.
>
>> +#ifdef CONFIG_COMPAT
>> + if (unlikely(is_compat_task())) {
>> + compat_siginfo_t __user *uinfo = compat_ptr(data);
>> +
>> + ret = copy_siginfo_to_user32(uinfo, &info);
>> + if (!ret)
>> + ret = __put_user(info.si_code, 
>> &uinfo->si_code);
>> + } else
>> +#endif
>> + {
>> + siginfo_t __user *uinfo = (siginfo_t __user *) data;
>> +
>> + ret = copy_siginfo_to_user(uinfo, &info);
>> + if (!ret)
>> + ret = __put_user(info.si_code, 
>> &uinfo->si_code);
>> + }
>> +
>> + if (ret)
>> + break;
>> +
>> + data += sizeof(siginfo_t);
>> +
>> + if (signal_pending(current)) {
>> + i++;
>
> What does the i++ do?

For accounting a current siginfo. I will add a comment here.

>
>> + break;
>> + }
>> +
>> + cond_resched();
>> + }
>> +
>> + return i ? : ret;
>
> I hate that gcc thing :(
>
> Also, is it buggy?  `ret' might be -EFAULT here.  We appear to be using
> read() return semantics here?

I have tried to implement read() semantics here. ptrace() returns a
number of dumped signals even if dumping of the last signal is failed.
And it returns an error if not one signal has been dumped
successfully.

The similar logic is used in read()
generic_file_aio_read()

retval += desc.written;
if (desc.error) {
retval = retval ?: desc.error;
break;
}

Thanks,
  Andrey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] proc connector: reject unprivileged listener bumps

[Kees Cook]

While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible
for an unprivileged user to turn off notifications for all listeners by
sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as
required for a multicast bind.

Signed-off-by: Kees Cook 
Cc: Evgeniy Polyakov 
Cc: Matt Helsley 
Cc: sta...@vger.kernel.org
---
 drivers/connector/cn_proc.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index fce2000..1110478 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -313,6 +313,12 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
(task_active_pid_ns(current) != &init_pid_ns))
return;
 
+   /* Can only change if privileged. */
+   if (!capable(CAP_NET_ADMIN)) {
+   err = EPERM;
+   goto out;
+   }
+
mc_op = (enum proc_cn_mcast_op *)msg->data;
switch (*mc_op) {
case PROC_CN_MCAST_LISTEN:
@@ -325,6 +331,8 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
err = EINVAL;
break;
}
+
+out:
cn_proc_ack(err, msg->seq, msg->ack);
 }
 
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Media: remove incorrect __init/__exit markups

[Guennadi Liakhovetski]

On Mon, 25 Feb 2013, Dmitry Torokhov wrote:

> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically disables sysfs bind/unbind
> attributes.
> 
> Similarly probe() methods should not be marked __init unless
> platform_driver_probe() is used.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> v1->v2: removed __init markup on omap1_cam_probe() that was pointed out
>   by Guennadi Liakhovetski.
> 
>  drivers/media/platform/soc_camera/omap1_camera.c | 6 +++---

Acked-by: Guennadi Liakhovetski 

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

[Tang Chen]

On 02/26/2013 02:57 PM, Yinghai Lu wrote:

That is temporary workaround and your patch and this workaround make
x86 acpi numa init too messy.

I don't see the point to hack SRAT to make memory hotplug working.

Do you guys check and use PMTT in ACPI spec instead?


Hi Yinghai,

Thanks for the suggestion. :)

The point we are using SRAT is that we need the hot-pluggable bit in SRAT.
I didn't find such info in PMTT or elsewhere.

We use SRAT in this way aims to satisfy users who don't want to specify
physical address ranges in kernel command line. They want to use SRAT to
determine which memory is hot-pluggable, and which is not.

To achieve this aim, we have to ensure we have the SRAT info before 
memblock

starts to allocate memory. So that we can prevent memblock from allocating
memory in the hot-pluggable area. So I have to parse SRAT earlier.

I don't think the code is that messy. I think we can encapsulate the clear
up job into one function, and call it where it is needed.

How do you think ?

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/

[GIT PULL] scheduler fixes

[Ingo Molnar]

Linus,

Please pull the latest sched-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
sched-urgent-for-linus

   HEAD: 7f6575f1fb963d5231afbceecd3feadb6ab58cd3 cputime: Use local_clock() 
for full dynticks cputime accounting

 Thanks,

Ingo

-->
Clark Williams (1):
  sched: Move RR_TIMESLICE from sysctl.h to rt.h

Frederic Weisbecker (1):
  cputime: Use local_clock() for full dynticks cputime accounting

Li Zhong (1):
  cputime: Constify timeval_to_cputime(timeval) argument

Nathan Zimmer (2):
  sched: Fix /proc/sched_stat failure on very very large systems
  sched: Fix /proc/sched_debug failure on very very large systems

Sha Zhengju (1):
  sched/core: Remove the obsolete and unused nr_uninterruptible() function


 include/asm-generic/cputime_nsecs.h |  2 +-
 include/linux/sched.h   |  1 -
 include/linux/sched/rt.h|  6 +++
 include/linux/sched/sysctl.h|  6 ---
 kernel/sched/core.c | 22 +
 kernel/sched/cputime.c  |  2 +-
 kernel/sched/debug.c| 90 -
 kernel/sched/stats.c| 79 +++-
 8 files changed, 148 insertions(+), 60 deletions(-)

diff --git a/include/asm-generic/cputime_nsecs.h 
b/include/asm-generic/cputime_nsecs.h
index b6485ca..a8ece9a 100644
--- a/include/asm-generic/cputime_nsecs.h
+++ b/include/asm-generic/cputime_nsecs.h
@@ -76,7 +76,7 @@ static inline void cputime_to_timespec(const cputime_t ct, 
struct timespec *val)
 /*
  * Convert cputime <-> timeval (msec)
  */
-static inline cputime_t timeval_to_cputime(struct timeval *val)
+static inline cputime_t timeval_to_cputime(const struct timeval *val)
 {
u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_usec * NSEC_PER_USEC;
return (__force cputime_t) ret;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 33cc421..f9ca237d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -98,7 +98,6 @@ extern int nr_threads;
 DECLARE_PER_CPU(unsigned long, process_counts);
 extern int nr_processes(void);
 extern unsigned long nr_running(void);
-extern unsigned long nr_uninterruptible(void);
 extern unsigned long nr_iowait(void);
 extern unsigned long nr_iowait_cpu(int cpu);
 extern unsigned long this_cpu_load(void);
diff --git a/include/linux/sched/rt.h b/include/linux/sched/rt.h
index 94e19ea..440434d 100644
--- a/include/linux/sched/rt.h
+++ b/include/linux/sched/rt.h
@@ -55,4 +55,10 @@ static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
 extern void normalize_rt_tasks(void);
 
 
+/*
+ * default timeslice is 100 msecs (used only for SCHED_RR tasks).
+ * Timeslices get refilled after they expire.
+ */
+#define RR_TIMESLICE   (100 * HZ / 1000)
+
 #endif /* _SCHED_RT_H */
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index d2bb0ae..bf8086b 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -91,12 +91,6 @@ extern unsigned int sysctl_sched_cfs_bandwidth_slice;
 extern unsigned int sysctl_sched_autogroup_enabled;
 #endif
 
-/*
- * default timeslice is 100 msecs (used only for SCHED_RR tasks).
- * Timeslices get refilled after they expire.
- */
-#define RR_TIMESLICE   (100 * HZ / 1000)
-
 extern int sched_rr_timeslice;
 
 extern int sched_rr_handler(struct ctl_table *table, int write,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 03d7784..b7b03cd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1969,11 +1969,10 @@ context_switch(struct rq *rq, struct task_struct *prev,
 }
 
 /*
- * nr_running, nr_uninterruptible and nr_context_switches:
+ * nr_running and nr_context_switches:
  *
  * externally visible scheduler statistics: current number of runnable
- * threads, current number of uninterruptible-sleeping threads, total
- * number of context switches performed since bootup.
+ * threads, total number of context switches performed since bootup.
  */
 unsigned long nr_running(void)
 {
@@ -1985,23 +1984,6 @@ unsigned long nr_running(void)
return sum;
 }
 
-unsigned long nr_uninterruptible(void)
-{
-   unsigned long i, sum = 0;
-
-   for_each_possible_cpu(i)
-   sum += cpu_rq(i)->nr_uninterruptible;
-
-   /*
-* Since we read the counters lockless, it might be slightly
-* inaccurate. Do not allow it to go below zero though:
-*/
-   if (unlikely((long)sum < 0))
-   sum = 0;
-
-   return sum;
-}
-
 unsigned long long nr_context_switches(void)
 {
int i;
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 9857329..ed12cbb 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -604,7 +604,7 @@ static unsigned long long vtime_delta(struct task_struct 
*tsk)
 {
unsigned long long clock;
 
-   clock = sched_clock();
+   clock = local_clock();
if

Re: linux-next: manual merge of the infiniband tree with Linus' tree

[Or Gerlitz]

On 26/02/2013 02:45, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the infiniband tree got a conflict in
drivers/net/ethernet/mellanox/mlx4/mlx4.h between commit 23537b732f5d
("net/mlx4_core: Use firmware driven flow steering hash mode") from
Linus' tree and commit e448834e3545 ("mlx4_core: Enable memory windows in
{INIT, QUERY}_HCA") from the infiniband tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).



thanks,

Acked-by: Or Gerlitz 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Media: remove incorrect __init/__exit markups

[Dmitry Torokhov]

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Similarly probe() methods should not be marked __init unless
platform_driver_probe() is used.

Signed-off-by: Dmitry Torokhov 
---

v1->v2: removed __init markup on omap1_cam_probe() that was pointed out
by Guennadi Liakhovetski.

 drivers/media/i2c/adp1653.c  | 4 ++--
 drivers/media/i2c/smiapp/smiapp-core.c   | 4 ++--
 drivers/media/platform/soc_camera/omap1_camera.c | 6 +++---
 drivers/media/radio/radio-si4713.c   | 4 ++--
 drivers/media/rc/ir-rx51.c   | 4 ++--
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index df16380..ef75abe 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -447,7 +447,7 @@ free_and_quit:
return ret;
 }
 
-static int __exit adp1653_remove(struct i2c_client *client)
+static int adp1653_remove(struct i2c_client *client)
 {
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
struct adp1653_flash *flash = to_adp1653_flash(subdev);
@@ -476,7 +476,7 @@ static struct i2c_driver adp1653_i2c_driver = {
.pm = &adp1653_pm_ops,
},
.probe  = adp1653_probe,
-   .remove = __exit_p(adp1653_remove),
+   .remove = adp1653_remove,
.id_table   = adp1653_id_table,
 };
 
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 83c7ed7..cae4f46 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2833,7 +2833,7 @@ static int smiapp_probe(struct i2c_client *client,
 sensor->src->pads, 0);
 }
 
-static int __exit smiapp_remove(struct i2c_client *client)
+static int smiapp_remove(struct i2c_client *client)
 {
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
@@ -2881,7 +2881,7 @@ static struct i2c_driver smiapp_i2c_driver = {
.pm = &smiapp_pm_ops,
},
.probe  = smiapp_probe,
-   .remove = __exit_p(smiapp_remove),
+   .remove = smiapp_remove,
.id_table = smiapp_id_table,
 };
 
diff --git a/drivers/media/platform/soc_camera/omap1_camera.c 
b/drivers/media/platform/soc_camera/omap1_camera.c
index 39a77f0..e5091b7 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -1546,7 +1546,7 @@ static struct soc_camera_host_ops omap1_host_ops = {
.poll   = omap1_cam_poll,
 };
 
-static int __init omap1_cam_probe(struct platform_device *pdev)
+static int omap1_cam_probe(struct platform_device *pdev)
 {
struct omap1_cam_dev *pcdev;
struct resource *res;
@@ -1677,7 +1677,7 @@ exit:
return err;
 }
 
-static int __exit omap1_cam_remove(struct platform_device *pdev)
+static int omap1_cam_remove(struct platform_device *pdev)
 {
struct soc_camera_host *soc_host = to_soc_camera_host(&pdev->dev);
struct omap1_cam_dev *pcdev = container_of(soc_host,
@@ -1709,7 +1709,7 @@ static struct platform_driver omap1_cam_driver = {
.name   = DRIVER_NAME,
},
.probe  = omap1_cam_probe,
-   .remove = __exit_p(omap1_cam_remove),
+   .remove = omap1_cam_remove,
 };
 
 module_platform_driver(omap1_cam_driver);
diff --git a/drivers/media/radio/radio-si4713.c 
b/drivers/media/radio/radio-si4713.c
index 1507c9d..8ae8442d 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -328,7 +328,7 @@ exit:
 }
 
 /* radio_si4713_pdriver_remove - remove the device */
-static int __exit radio_si4713_pdriver_remove(struct platform_device *pdev)
+static int radio_si4713_pdriver_remove(struct platform_device *pdev)
 {
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
struct radio_si4713_device *rsdev = container_of(v4l2_dev,
@@ -350,7 +350,7 @@ static struct platform_driver radio_si4713_pdriver = {
.name   = "radio-si4713",
},
.probe  = radio_si4713_pdriver_probe,
-   .remove = __exit_p(radio_si4713_pdriver_remove),
+   .remove = radio_si4713_pdriver_remove,
 };
 
 module_platform_driver(radio_si4713_pdriver);
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8ead492..31b955b 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -464,14 +464,14 @@ static int lirc_rx51_probe(struct platform_device *dev)
return 0;
 }
 
-static int __exit lirc_rx51_remove(struct platform_device *dev)
+static int lirc_rx51_remo

[GIT PULL] OpenRISC updates for 3.9

[Jonas Bonn]

The following changes since commit 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39:

  Linux 3.8-rc7 (2013-02-09 08:20:39 +1100)

are available in the git repository at:

  git://openrisc.net/jonas/linux for-upstream

for you to fetch changes up to 160d83781a32e94a1e337efd6722939001e62398:

  openrisc: add missing header inclusion (2013-02-26 07:44:08 +0100)


OpenRISC updates for 3.9

An equal number of bug fixes and trivial cleanups; no new features.

* Two patches to fix errors thrown by the updated toolchain.
* Three other bug fixes.
* Four trivial cleanups.


James Hogan (1):
  openrisc: remove CONFIG_SYMBOL_PREFIX

Jonas Bonn (4):
  openrisc: remove unused current_regs
  openrisc: fix up vmalloc page table loading
  openrisc: update DTLB-miss handler last
  openrisc: really pass correct arg to schedule_tail

Len Brown (1):
  openrisc idle: delete pm_idle

Sebastian Macke (1):
  Add bitops include needed for ext2 filesystem

Stefan Kristiansson (2):
  openrisc: avoid using function parameter regs in reset vector
  openrisc: add missing header inclusion

 arch/openrisc/Kconfig |4 
 arch/openrisc/include/asm/bitops.h|1 +
 arch/openrisc/include/asm/processor.h |1 -
 arch/openrisc/kernel/entry.S  |   16 +---
 arch/openrisc/kernel/head.S   |   13 ++---
 arch/openrisc/kernel/idle.c   |5 -
 arch/openrisc/mm/init.c   |   17 ++---
 7 files changed, 34 insertions(+), 23 deletions(-)

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

Re: [PATCH] Use config scripts to detect ncurses libs for, menuconfig/nconfig dialogs

[justin]

On 25/02/13 21:53, Yann E. MORIN wrote:
> Justin, All,
> 
> On Monday 25 February 2013 Justin wrote:
>> On 25.02.2013 19:30, Yann E. MORIN wrote:
>>> On Sunday 24 February 2013 Justin wrote:
 when ncurses is build with --with-termlib several symbols are moved to a
 seperate terminfo library (libtinfo.so). Current Kernel buildsystem
 results in a build error with menuconfig and nconfig dialogs.
>>>
>>> Do you know of a distribution where this is the case, so I can test?
>>
>> This is using Gentoo Linux testing with ld.gold. But I assume you will
>> get the same result using any distro with gold.
> 
> No, I meant a distro where ncurses is built with --with-termlib.
> On my Debian stable (squeeze), libtinfo does not exist at all,
> so I can not test linking against it:
> 
> $ apt-file search libtinfo
> (zilch)
> 
> But I'll see at installing a Gentoo (if that's not too complex) in a
> VM to do the checks (can you confirm that Gentoo by default configures
> ncurses with --with-termlib ?).
> 
> Regards,
> Yann E. MORIN.
> 

I can be build optionally (mostly for binary package compatibility
reasons) with --with-termlib. I will send a step-by-step instruction how
to test this with our live cd later today.

Thanks,
Justin



signature.asc
Description: OpenPGP digital signature

[GIT PULL] perf fixes

[Ingo Molnar]

Linus,

Please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus

   HEAD: ff1fb5f6b4925a536ffb8171e5f2dbd01ccfeb97 Merge branch 'tip/perf/core' 
of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace into 
perf/urgent

 Thanks,

Ingo

-->
Stephane Eranian (1):
  perf/x86: Add Intel IvyBridge event scheduling constraints

Steven Rostedt (1):
  tracing/syscalls: Allow archs to ignore tracing compat syscalls

Steven Rostedt (Red Hat) (1):
  ftrace: Call ftrace cleanup module notifier after all other notifiers


 arch/x86/include/asm/ftrace.h  | 24 ++
 arch/x86/include/asm/thread_info.h |  1 -
 arch/x86/kernel/cpu/perf_event_intel.c | 23 -
 kernel/trace/ftrace.c  | 46 +++---
 kernel/trace/trace_syscalls.c  | 43 +++
 5 files changed, 116 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 86cb51e..0525a8b 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -72,4 +72,28 @@ int ftrace_int3_handler(struct pt_regs *regs);
 #endif /* __ASSEMBLY__ */
 #endif /* CONFIG_FUNCTION_TRACER */
 
+
+#if !defined(__ASSEMBLY__) && !defined(COMPILE_OFFSETS)
+
+#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION)
+#include 
+
+/*
+ * Because ia32 syscalls do not map to x86_64 syscall numbers
+ * this screws up the trace output when tracing a ia32 task.
+ * Instead of reporting bogus syscalls, just do not trace them.
+ *
+ * If the user realy wants these, then they should use the
+ * raw syscall tracepoints with filtering.
+ */
+#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS 1
+static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
+{
+   if (is_compat_task())
+   return true;
+   return false;
+}
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_IA32_EMULATION */
+#endif /* !__ASSEMBLY__  && !COMPILE_OFFSETS */
+
 #endif /* _ASM_X86_FTRACE_H */
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 2d946e6..2cd056e 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -20,7 +20,6 @@
 struct task_struct;
 struct exec_domain;
 #include 
-#include 
 #include 
 
 struct thread_info {
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 4914e94..529c893 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -107,6 +107,27 @@ static struct event_constraint 
intel_snb_event_constraints[] __read_mostly =
EVENT_CONSTRAINT_END
 };
 
+static struct event_constraint intel_ivb_event_constraints[] __read_mostly =
+{
+   FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
+   FIXED_EVENT_CONSTRAINT(0x003c, 1), /* CPU_CLK_UNHALTED.CORE */
+   FIXED_EVENT_CONSTRAINT(0x0300, 2), /* CPU_CLK_UNHALTED.REF */
+   INTEL_UEVENT_CONSTRAINT(0x0148, 0x4), /* L1D_PEND_MISS.PENDING */
+   INTEL_UEVENT_CONSTRAINT(0x0279, 0xf), /* IDQ.EMTPY */
+   INTEL_UEVENT_CONSTRAINT(0x019c, 0xf), /* IDQ_UOPS_NOT_DELIVERED.CORE */
+   INTEL_UEVENT_CONSTRAINT(0x04a3, 0xf), /* 
CYCLE_ACTIVITY.CYCLES_NO_EXECUTE */
+   INTEL_UEVENT_CONSTRAINT(0x05a3, 0xf), /* 
CYCLE_ACTIVITY.STALLS_L2_PENDING */
+   INTEL_UEVENT_CONSTRAINT(0x06a3, 0xf), /* 
CYCLE_ACTIVITY.STALLS_LDM_PENDING */
+   INTEL_UEVENT_CONSTRAINT(0x08a3, 0x4), /* 
CYCLE_ACTIVITY.CYCLES_L1D_PENDING */
+   INTEL_UEVENT_CONSTRAINT(0x0ca3, 0x4), /* 
CYCLE_ACTIVITY.STALLS_L1D_PENDING */
+   INTEL_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PREC_DIST */
+   INTEL_EVENT_CONSTRAINT(0xd0, 0xf), /* MEM_UOPS_RETIRED.* */
+   INTEL_EVENT_CONSTRAINT(0xd1, 0xf), /* MEM_LOAD_UOPS_RETIRED.* */
+   INTEL_EVENT_CONSTRAINT(0xd2, 0xf), /* MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */
+   INTEL_EVENT_CONSTRAINT(0xd3, 0xf), /*  MEM_LOAD_UOPS_LLC_MISS_RETIRED.* 
*/
+   EVENT_CONSTRAINT_END
+};
+
 static struct extra_reg intel_westmere_extra_regs[] __read_mostly =
 {
INTEL_EVENT_EXTRA_REG(0xb7, MSR_OFFCORE_RSP_0, 0x, RSP_0),
@@ -2095,7 +2116,7 @@ __init int intel_pmu_init(void)
 
intel_pmu_lbr_init_snb();
 
-   x86_pmu.event_constraints = intel_snb_event_constraints;
+   x86_pmu.event_constraints = intel_ivb_event_constraints;
x86_pmu.pebs_constraints = intel_ivb_pebs_event_constraints;
x86_pmu.pebs_aliases = intel_pebs_aliases_snb;
x86_pmu.extra_regs = intel_snb_extra_regs;
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index ce8c3d6..98ca94a 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3996,37 +3996,51 @@ static void ftrace_init_module(struct module *mod,
ftrace_process_locs(

Re: [PATCH 02/16] virtio_ring: virtqueue_add_sgs, to add multiple sgs.

[Paolo Bonzini]

Il 24/02/2013 23:12, Michael S. Tsirkin ha scritto:
> On Tue, Feb 19, 2013 at 06:26:20PM +1030, Rusty Russell wrote:
>> virtio_scsi can really use this, to avoid the current hack of copying
>> the whole sg array.  Some other things get slightly neater, too.
>>
>> Signed-off-by: Rusty Russell 
> 
> Hmm, this makes add_buf a bit slower. virtio_test results
> (I'll send a patch to update the test shortly):
> 
> Before:
> 0.09user 0.01system 0:00.12elapsed 91%CPU (0avgtext+0avgdata 480maxresident)k
> 0inputs+0outputs (0major+145minor)pagefaults 0swaps
> 
> After:
> 0.11user 0.01system 0:00.13elapsed 90%CPU (0avgtext+0avgdata 480maxresident)k
> 0inputs+0outputs (0major+145minor)pagefaults 0swaps

Not unexpected at all... :(

Some of it can be recovered, but if it's 20% I doubt all of it.  So my
patches were not premature optimization; you really can take just two
among speed, flexibility, and having a nice API.

Paolo

> 
> 
> 
>> ---
>>  drivers/virtio/virtio_ring.c |  144 
>> ++
>>  include/linux/virtio.h   |7 ++
>>  2 files changed, 109 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>> index 245177c..27e31d3 100644
>> --- a/drivers/virtio/virtio_ring.c
>> +++ b/drivers/virtio/virtio_ring.c
>> @@ -100,14 +100,16 @@ struct vring_virtqueue
>>  
>>  /* Set up an indirect table of descriptors and add it to the queue. */
>>  static int vring_add_indirect(struct vring_virtqueue *vq,
>> -  struct scatterlist sg[],
>> -  unsigned int out,
>> -  unsigned int in,
>> +  struct scatterlist *sgs[],
>> +  unsigned int total_sg,
>> +  unsigned int out_sgs,
>> +  unsigned int in_sgs,
>>gfp_t gfp)
>>  {
>>  struct vring_desc *desc;
>>  unsigned head;
>> -int i;
>> +struct scatterlist *sg;
>> +int i, n;
>>  
>>  /*
>>   * We require lowmem mappings for the descriptors because
>> @@ -116,25 +118,31 @@ static int vring_add_indirect(struct vring_virtqueue 
>> *vq,
>>   */
>>  gfp &= ~(__GFP_HIGHMEM | __GFP_HIGH);
>>  
>> -desc = kmalloc((out + in) * sizeof(struct vring_desc), gfp);
>> +desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
>>  if (!desc)
>>  return -ENOMEM;
>>  
>> -/* Transfer entries from the sg list into the indirect page */
>> -for (i = 0; i < out; i++) {
>> -desc[i].flags = VRING_DESC_F_NEXT;
>> -desc[i].addr = sg_phys(sg);
>> -desc[i].len = sg->length;
>> -desc[i].next = i+1;
>> -sg++;
>> +/* Transfer entries from the sg lists into the indirect page */
>> +i = 0;
>> +for (n = 0; n < out_sgs; n++) {
>> +for (sg = sgs[n]; sg; sg = sg_next(sg)) {
>> +desc[i].flags = VRING_DESC_F_NEXT;
>> +desc[i].addr = sg_phys(sg);
>> +desc[i].len = sg->length;
>> +desc[i].next = i+1;
>> +i++;
>> +}
>>  }
>> -for (; i < (out + in); i++) {
>> -desc[i].flags = VRING_DESC_F_NEXT|VRING_DESC_F_WRITE;
>> -desc[i].addr = sg_phys(sg);
>> -desc[i].len = sg->length;
>> -desc[i].next = i+1;
>> -sg++;
>> +for (; n < (out_sgs + in_sgs); n++) {
>> +for (sg = sgs[n]; sg; sg = sg_next(sg)) {
>> +desc[i].flags = VRING_DESC_F_NEXT|VRING_DESC_F_WRITE;
>> +desc[i].addr = sg_phys(sg);
>> +desc[i].len = sg->length;
>> +desc[i].next = i+1;
>> +i++;
>> +}
>>  }
>> +BUG_ON(i != total_sg);
>>  
>>  /* Last one doesn't continue. */
>>  desc[i-1].flags &= ~VRING_DESC_F_NEXT;
>> @@ -176,8 +184,48 @@ int virtqueue_add_buf(struct virtqueue *_vq,
>>void *data,
>>gfp_t gfp)
>>  {
>> +struct scatterlist *sgs[2];
>> +unsigned int i;
>> +
>> +sgs[0] = sg;
>> +sgs[1] = sg + out;
>> +
>> +/* Workaround until callers pass well-formed sgs. */
>> +for (i = 0; i < out + in; i++)
>> +sg_unmark_end(sg + i);
>> +
>> +sg_mark_end(sg + out + in - 1);
>> +if (out && in)
>> +sg_mark_end(sg + out - 1);
>> +
>> +return virtqueue_add_sgs(_vq, sgs, out ? 1 : 0, in ? 1 : 0, data, gfp);
>> +}
>> +EXPORT_SYMBOL_GPL(virtqueue_add_buf);
>> +
>> +/**
>> + * virtqueue_add_sgs - expose buffers to other end
>> + * @vq: the struct virtqueue we're talking about.
>> + * @sgs: array of terminated scatterlists.
>> + * @out_num: the number of scatterlists readable by other side
>> + * @in_num: the number of scatterlists which are writable (after readable 
>> ones)
>> + * @data: the token identifying the buffer.
>> + * @gfp

[PATCH v5 08/16] spi/spi-atmel: add dmaengine support

[Wenyou Yang]

From: Nicolas Ferre 

Add dmaengine support.

For different SoC, the "has_dma_support" is used to select
the transfer mode: dmaengine or PDC.

The "has_dma_support" member of the capabilities struct is used to select
the transfer mode: dmaengine or PDC.

For the dmaengine transfer mode, if it fails to config dmaengine,
or if the message len less than 16 bytes, it will use the PIO transfer mode.

Signed-off-by: Nicolas Ferre 
[wenyou.y...@atmel.com: using "has_dma_support" to select dmaengine as the spi 
xfer mode]
[wenyou.y...@atmel.com: fix DMA: OOPS if buffer > 4096 bytes]
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang 
Cc: richard.gen...@gmail.com
Cc: spi-devel-gene...@lists.sourceforge.ne
Cc: linux-kernel@vger.kernel.org
---
This patch is based on the original patch from Nicolas
[PATCH] spi/atmel_spi: add dmaengine support
and merge the patches from Richard Genoud 
[PATCH] spi-atmel: update with dmaengine interface
[PATCH] spi-atmel: fix __init/__devinit sections mismatch

Hi, Richard,

Could you sign your signature in this patch?

Best Regards,
Wenyou Yang
 drivers/spi/spi-atmel.c |  541 +--
 1 file changed, 520 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 1c2933a..d77dd53 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -15,11 +15,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -183,6 +185,22 @@
 #define spi_writel(port,reg,value) \
__raw_writel((value), (port)->regs + SPI_##reg)
 
+/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
+ * cache operations; better heuristics consider wordsize and bitrate.
+ */
+#define DMA_MIN_BYTES  16
+
+struct atmel_spi_dma {
+   struct dma_chan *chan_rx;
+   struct dma_chan *chan_tx;
+   struct scatterlist  sgrx;
+   struct scatterlist  sgtx;
+   struct dma_async_tx_descriptor  *data_desc_rx;
+   struct dma_async_tx_descriptor  *data_desc_tx;
+
+   struct at_dma_slave dma_slave;
+};
+
 struct atmel_spi_caps {
boolis_spi2;
boolhas_wdrbt;
@@ -207,16 +225,23 @@ struct atmel_spi {
 
u8  stopping;
struct list_headqueue;
+   struct tasklet_struct   tasklet;
struct spi_transfer *current_transfer;
unsigned long   current_remaining_bytes;
struct spi_transfer *next_transfer;
unsigned long   next_remaining_bytes;
int done_status;
 
+   /* scratch buffer */
void*buffer;
dma_addr_t  buffer_dma;
 
struct atmel_spi_caps   caps;
+
+   booluse_dma;
+   booluse_pdc;
+   /* dmaengine data */
+   struct atmel_spi_dmadma;
 };
 
 /* Controller-specific per-slave state */
@@ -285,6 +310,7 @@ static void cs_activate(struct atmel_spi *as, struct 
spi_device *spi)
| SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
}
+
mr = spi_readl(as, MR);
gpio_set_value(asd->npcs_pin, active);
} else {
@@ -345,6 +371,12 @@ static void atmel_spi_unlock(struct atmel_spi *as)
spin_unlock_irqrestore(&as->lock, as->flags);
 }
 
+static inline bool atmel_spi_use_dma(struct atmel_spi *as,
+   struct spi_transfer *xfer)
+{
+   return as->use_dma && xfer->len >= DMA_MIN_BYTES;
+}
+
 static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
struct spi_transfer *xfer)
 {
@@ -356,6 +388,219 @@ static inline int atmel_spi_xfer_can_be_chained(struct 
spi_transfer *xfer)
return xfer->delay_usecs == 0 && !xfer->cs_change;
 }
 
+static bool filter(struct dma_chan *chan, void *slave)
+{
+   struct  at_dma_slave *sl = slave;
+
+   if (sl->dma_dev == chan->device->dev) {
+   chan->private = sl;
+   return true;
+   } else {
+   return false;
+   }
+}
+
+static int atmel_spi_configure_dma(struct atmel_spi *as)
+{
+   struct at_dma_slave *sdata = &as->dma.dma_slave;
+
+   if (sdata && sdata->dma_dev) {
+   dma_cap_mask_t mask;
+
+   /* setup DMA addresses */
+   sdata->rx_reg = (dma_addr_t)as->phybase + SPI_RDR;
+   sdata->tx_reg = (dma_addr_t)as->phybase + SPI_TDR;
+
+   /* Try to grab two DMA channels */
+   dma_cap_zero(mask);
+   dma_cap_set(DMA_SLAVE, mask);
+   as->dma.chan_tx = dma_request_channel(mask, filter, sdata);
+   if (as->dma.chan_tx)
+   as->dma.chan_rx =
+

Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

[Yinghai Lu]

On Mon, Feb 25, 2013 at 10:09 PM, Tang Chen  wrote:
> On 02/26/2013 12:51 PM, Martin Bligh wrote:
>>>
>>> Do you mean we can remove numaq x86 32bit code now?
>>
>>
>> Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
>> Was useful in the early days of getting NUMA up and running on Linux,
>> but is now too old to be a museum piece, really.
>>
>> M.
>>
>
> Hi Martin, Yinghai,
>
> It was me that I failed to make numa_init() fall back path working, and
> forgot
> to call early_parse_srat in ia64. Sorry for the breaking of other platform.
> :)
>
> So now, is Yinghai's patch enough for this problem ?
> Or we can encapsulate the following clear up work into one function ?
>
>
> +   for (i = 0; i < MAX_LOCAL_APIC; i++)
> +   set_apicid_to_node(i, NUMA_NO_NODE);
> +   nodes_clear(numa_nodes_parsed);
> +   memset(&numa_meminfo, 0, sizeof(numa_meminfo));
>
>

That is temporary workaround and your patch and this workaround make
x86 acpi numa init too messy.

I don't see the point to hack SRAT to make memory hotplug working.

Do you guys check and use PMTT in ACPI spec instead?

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 07/16] spi/spi-atmel: add flag to controller data for lock operations

[Wenyou Yang]

From: Nicolas Ferre 

Will allow to drop the lock during DMA operations.

Signed-off-by: Nicolas Ferre 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang 
---
 drivers/spi/spi-atmel.c |   31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 136ed8f..1c2933a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -196,6 +196,7 @@ struct atmel_spi_caps {
  */
 struct atmel_spi {
spinlock_t  lock;
+   unsigned long   flags;
 
resource_size_t phybase;
void __iomem*regs;
@@ -334,6 +335,16 @@ static void cs_deactivate(struct atmel_spi *as, struct 
spi_device *spi)
gpio_set_value(asd->npcs_pin, !active);
 }
 
+static void atmel_spi_lock(struct atmel_spi *as)
+{
+   spin_lock_irqsave(&as->lock, as->flags);
+}
+
+static void atmel_spi_unlock(struct atmel_spi *as)
+{
+   spin_unlock_irqrestore(&as->lock, as->flags);
+}
+
 static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
struct spi_transfer *xfer)
 {
@@ -570,9 +581,9 @@ atmel_spi_msg_done(struct spi_master *master, struct 
atmel_spi *as,
"xfer complete: %u bytes transferred\n",
msg->actual_length);
 
-   spin_unlock(&as->lock);
+   atmel_spi_unlock(as);
msg->complete(msg->context);
-   spin_lock(&as->lock);
+   atmel_spi_lock(as);
 
as->current_transfer = NULL;
as->next_transfer = NULL;
@@ -803,13 +814,11 @@ static int atmel_spi_setup(struct spi_device *spi)
spi->controller_state = asd;
gpio_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
} else {
-   unsigned long   flags;
-
-   spin_lock_irqsave(&as->lock, flags);
+   atmel_spi_lock(as);
if (as->stay == spi)
as->stay = NULL;
cs_deactivate(as, spi);
-   spin_unlock_irqrestore(&as->lock, flags);
+   atmel_spi_unlock(as);
}
 
asd->csr = csr;
@@ -828,7 +837,6 @@ static int atmel_spi_transfer(struct spi_device *spi, 
struct spi_message *msg)
 {
struct atmel_spi*as;
struct spi_transfer *xfer;
-   unsigned long   flags;
struct device   *controller = spi->master->dev.parent;
u8  bits;
struct atmel_spi_device *asd;
@@ -893,11 +901,11 @@ static int atmel_spi_transfer(struct spi_device *spi, 
struct spi_message *msg)
msg->status = -EINPROGRESS;
msg->actual_length = 0;
 
-   spin_lock_irqsave(&as->lock, flags);
+   atmel_spi_lock(as);
list_add_tail(&msg->queue, &as->queue);
if (!as->current_transfer)
atmel_spi_next_message(spi->master);
-   spin_unlock_irqrestore(&as->lock, flags);
+   atmel_spi_unlock(as);
 
return 0;
 }
@@ -907,17 +915,16 @@ static void atmel_spi_cleanup(struct spi_device *spi)
struct atmel_spi*as = spi_master_get_devdata(spi->master);
struct atmel_spi_device *asd = spi->controller_state;
unsignedgpio = (unsigned) spi->controller_data;
-   unsigned long   flags;
 
if (!asd)
return;
 
-   spin_lock_irqsave(&as->lock, flags);
+   atmel_spi_lock(as);
if (as->stay == spi) {
as->stay = NULL;
cs_deactivate(as, spi);
}
-   spin_unlock_irqrestore(&as->lock, flags);
+   atmel_spi_unlock(as);
 
spi->controller_state = NULL;
gpio_free(gpio);
-- 
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 v5 06/16] spi/spi-atmel: status information passed through controller data

[Wenyou Yang]

From: Nicolas Ferre 

The status of transfer is stored in controller data structure
so that it can be used not only by atmel_spi_msg_done() function.
This will be useful for upcoming dmaengine enabled driver.

Signed-off-by: Nicolas Ferre 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang 
---
 drivers/spi/spi-atmel.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 6ea41a7..136ed8f 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -210,6 +210,7 @@ struct atmel_spi {
unsigned long   current_remaining_bytes;
struct spi_transfer *next_transfer;
unsigned long   next_remaining_bytes;
+   int done_status;
 
void*buffer;
dma_addr_t  buffer_dma;
@@ -555,15 +556,15 @@ static void atmel_spi_dma_unmap_xfer(struct spi_master 
*master,
 
 static void
 atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
-   struct spi_message *msg, int status, int stay)
+   struct spi_message *msg, int stay)
 {
-   if (!stay || status < 0)
+   if (!stay || as->done_status < 0)
cs_deactivate(as, msg->spi);
else
as->stay = msg->spi;
 
list_del(&msg->queue);
-   msg->status = status;
+   msg->status = as->done_status;
 
dev_dbg(master->dev.parent,
"xfer complete: %u bytes transferred\n",
@@ -575,6 +576,7 @@ atmel_spi_msg_done(struct spi_master *master, struct 
atmel_spi *as,
 
as->current_transfer = NULL;
as->next_transfer = NULL;
+   as->done_status = 0;
 
/* continue if needed */
if (list_empty(&as->queue) || as->stopping)
@@ -652,7 +654,8 @@ atmel_spi_interrupt(int irq, void *dev_id)
/* Clear any overrun happening while cleaning up */
spi_readl(as, SR);
 
-   atmel_spi_msg_done(master, as, msg, -EIO, 0);
+   as->done_status = -EIO;
+   atmel_spi_msg_done(master, as, msg, 0);
} else if (pending & (SPI_BIT(RXBUFF) | SPI_BIT(ENDRX))) {
ret = IRQ_HANDLED;
 
@@ -670,7 +673,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
 
if (atmel_spi_xfer_is_last(msg, xfer)) {
/* report completed message */
-   atmel_spi_msg_done(master, as, msg, 0,
+   atmel_spi_msg_done(master, as, msg,
xfer->cs_change);
} else {
if (xfer->cs_change) {
-- 
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 v5 05/16] spi/spi-atmel: call unmapping on transfers buffers

[Wenyou Yang]

From: Nicolas Ferre 

Signed-off-by: Nicolas Ferre 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang 
---
 drivers/spi/spi-atmel.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index c70142e..6ea41a7 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1059,6 +1059,7 @@ static int atmel_spi_remove(struct platform_device *pdev)
struct spi_master   *master = platform_get_drvdata(pdev);
struct atmel_spi*as = spi_master_get_devdata(master);
struct spi_message  *msg;
+   struct spi_transfer *xfer;
 
/* reset the hardware and block queue progress */
spin_lock_irq(&as->lock);
@@ -1070,9 +1071,10 @@ static int atmel_spi_remove(struct platform_device *pdev)
 
/* Terminate remaining queued transfers */
list_for_each_entry(msg, &as->queue, queue) {
-   /* REVISIT unmapping the dma is a NOP on ARM and AVR32
-* but we shouldn't depend on that...
-*/
+   list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+   if (!msg->is_dma_mapped)
+   atmel_spi_dma_unmap_xfer(master, xfer);
+   }
msg->status = -ESHUTDOWN;
msg->complete(msg->context);
}
-- 
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 v5 04/16] spi/spi-atmel: add physical base address

[Wenyou Yang]

From: Nicolas Ferre 

Needed for future use with dmaengine enabled driver.

Signed-off-by: Nicolas Ferre 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
[wenyou.y...@atmel.com: submit the patch]
Signed-off-by: Wenyou Yang 
---
 drivers/spi/spi-atmel.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 9c8f2d5..c70142e 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -197,6 +197,7 @@ struct atmel_spi_caps {
 struct atmel_spi {
spinlock_t  lock;
 
+   resource_size_t phybase;
void __iomem*regs;
int irq;
struct clk  *clk;
@@ -1003,6 +1004,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->regs = ioremap(regs->start, resource_size(regs));
if (!as->regs)
goto out_free_buffer;
+   as->phybase = regs->start;
as->irq = irq;
as->clk = clk;
 
-- 
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 v5 03/16] spi/spi-atmel: add support transfer on CS1,2,3, not only on CS0

[Wenyou Yang]

Signed-off-by: Wenyou Yang 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
 drivers/spi/spi-atmel.c |   25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index a8e091b..9c8f2d5 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -256,11 +256,6 @@ static bool atmel_spi_is_v2(struct atmel_spi *as)
  * Master on Chip Select 0.")  No workaround exists for that ... so for
  * nCS0 on that chip, we (a) don't use the GPIO, (b) can't support CS_HIGH,
  * and (c) will trigger that first erratum in some cases.
- *
- * TODO: Test if the atmel_spi_is_v2() branch below works on
- * AT91RM9200 if we use some other register than CSR0. However, don't
- * do this unconditionally since AP7000 has an errata where the BITS
- * field in CSR0 overrides all other CSRs.
  */
 
 static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
@@ -270,18 +265,22 @@ static void cs_activate(struct atmel_spi *as, struct 
spi_device *spi)
u32 mr;
 
if (atmel_spi_is_v2(as)) {
-   /*
-* Always use CSR0. This ensures that the clock
-* switches to the correct idle polarity before we
-* toggle the CS.
+   spi_writel(as, CSR0 + 4 * spi->chip_select, asd->csr);
+   /* For the low SPI version, there is a issue that PDC transfer
+* on CS1,2,3 needs SPI_CSR0.BITS config as SPI_CSR1,2,3.BITS
 */
spi_writel(as, CSR0, asd->csr);
if (as->caps.has_wdrbt) {
-   spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(WDRBT)
-   | SPI_BIT(MODFDIS) | SPI_BIT(MSTR));
+   spi_writel(as, MR,
+   SPI_BF(PCS, ~(0x01 << spi->chip_select))
+   | SPI_BIT(WDRBT)
+   | SPI_BIT(MODFDIS)
+   | SPI_BIT(MSTR));
} else {
-   spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
-   | SPI_BIT(MSTR));
+   spi_writel(as, MR,
+   SPI_BF(PCS, ~(0x01 << spi->chip_select))
+   | SPI_BIT(MODFDIS)
+   | SPI_BIT(MSTR));
}
mr = spi_readl(as, MR);
gpio_set_value(asd->npcs_pin, active);
-- 
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 v5 02/16] spi/spi-atmel: detect the capabilities of SPI core by reading the VERSION register.

[Wenyou Yang]

the "has_dma_support" needed for future use with dmaengine driver.

Signed-off-by: Wenyou Yang 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
 drivers/spi/spi-atmel.c |   70 ++-
 1 file changed, 57 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 5bf3786..a8e091b 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -39,6 +39,7 @@
 #define SPI_CSR1   0x0034
 #define SPI_CSR2   0x0038
 #define SPI_CSR3   0x003c
+#define SPI_VERSION0x00fc
 #define SPI_RPR0x0100
 #define SPI_RCR0x0104
 #define SPI_TPR0x0108
@@ -71,6 +72,8 @@
 #define SPI_FDIV_SIZE  1
 #define SPI_MODFDIS_OFFSET 4
 #define SPI_MODFDIS_SIZE   1
+#define SPI_WDRBT_OFFSET   5
+#define SPI_WDRBT_SIZE 1
 #define SPI_LLB_OFFSET 7
 #define SPI_LLB_SIZE   1
 #define SPI_PCS_OFFSET 16
@@ -180,6 +183,11 @@
 #define spi_writel(port,reg,value) \
__raw_writel((value), (port)->regs + SPI_##reg)
 
+struct atmel_spi_caps {
+   boolis_spi2;
+   boolhas_wdrbt;
+   boolhas_dma_support;
+};
 
 /*
  * The core SPI transfer engine just talks to a register bank to set up
@@ -204,6 +212,8 @@ struct atmel_spi {
 
void*buffer;
dma_addr_t  buffer_dma;
+
+   struct atmel_spi_caps   caps;
 };
 
 /* Controller-specific per-slave state */
@@ -222,14 +232,10 @@ struct atmel_spi_device {
  *  - SPI_SR.TXEMPTY, SPI_SR.NSSR (and corresponding irqs)
  *  - SPI_CSRx.CSAAT
  *  - SPI_CSRx.SBCR allows faster clocking
- *
- * We can determine the controller version by reading the VERSION
- * register, but I haven't checked that it exists on all chips, and
- * this is cheaper anyway.
  */
-static bool atmel_spi_is_v2(void)
+static bool atmel_spi_is_v2(struct atmel_spi *as)
 {
-   return !cpu_is_at91rm9200();
+   return as->caps.is_spi2;
 }
 
 /*
@@ -263,15 +269,20 @@ static void cs_activate(struct atmel_spi *as, struct 
spi_device *spi)
unsigned active = spi->mode & SPI_CS_HIGH;
u32 mr;
 
-   if (atmel_spi_is_v2()) {
+   if (atmel_spi_is_v2(as)) {
/*
 * Always use CSR0. This ensures that the clock
 * switches to the correct idle polarity before we
 * toggle the CS.
 */
spi_writel(as, CSR0, asd->csr);
-   spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
+   if (as->caps.has_wdrbt) {
+   spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(WDRBT)
+   | SPI_BIT(MODFDIS) | SPI_BIT(MSTR));
+   } else {
+   spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
+   }
mr = spi_readl(as, MR);
gpio_set_value(asd->npcs_pin, active);
} else {
@@ -318,7 +329,7 @@ static void cs_deactivate(struct atmel_spi *as, struct 
spi_device *spi)
asd->npcs_pin, active ? " (low)" : "",
mr);
 
-   if (atmel_spi_is_v2() || spi->chip_select != 0)
+   if (atmel_spi_is_v2(as) || spi->chip_select != 0)
gpio_set_value(asd->npcs_pin, !active);
 }
 
@@ -719,7 +730,7 @@ static int atmel_spi_setup(struct spi_device *spi)
}
 
/* see notes above re chipselect */
-   if (!atmel_spi_is_v2()
+   if (!atmel_spi_is_v2(as)
&& spi->chip_select == 0
&& (spi->mode & SPI_CS_HIGH)) {
dev_dbg(&spi->dev, "setup: can't be active-high\n");
@@ -728,7 +739,7 @@ static int atmel_spi_setup(struct spi_device *spi)
 
/* v1 chips start out at half the peripheral bus speed. */
bus_hz = clk_get_rate(as->clk);
-   if (!atmel_spi_is_v2())
+   if (!atmel_spi_is_v2(as))
bus_hz /= 2;
 
if (spi->max_speed_hz) {
@@ -804,7 +815,7 @@ static int atmel_spi_setup(struct spi_device *spi)
"setup: %lu Hz bpw %u mode 0x%x -> csr%d %08x\n",
bus_hz / scbr, bits, spi->mode, spi->chip_select, csr);
 
-   if (!atmel_spi_is_v2())
+   if (!atmel_spi_is_v2(as))
spi_writel(as, CSR0 + 4 * spi->chip_select, csr);
 
return 0;
@@ -910,6 +921,32 @@ static void atmel_spi_cleanup(struct spi_device *spi)
kfree(asd);
 }
 
+static inline unsigned int atmel_get_version(struct atmel_spi *as)
+{
+   return spi_readl(as, VERSION) & 0x0fff;

[PATCH v5 01/16] spi/spi-atmel: fix master->num_chipselect wrongly set.

[Wenyou Yang]

if the spi property "cs-gpios" is set as below:

cs-gpios = <0>, <&pioC 11 0>, <0>, <0>;

the master->num_chipselect will wrongly be set to 0,
and the spi fail to probe.

Signed-off-by: Wenyou Yang 
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
 drivers/spi/spi-atmel.c |2 +-
 drivers/spi/spi.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..5bf3786 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -944,7 +944,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
 
master->dev.of_node = pdev->dev.of_node;
master->bus_num = pdev->id;
-   master->num_chipselect = master->dev.of_node ? 0 : 4;
+   master->num_chipselect = 4;
master->setup = atmel_spi_setup;
master->transfer = atmel_spi_transfer;
master->cleanup = atmel_spi_cleanup;
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 19ee901..d88cbef 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1070,7 +1070,7 @@ static int of_spi_register_master(struct spi_master 
*master)
master->num_chipselect = max(nb, master->num_chipselect);
 
if (nb < 1)
-   return 0;
+   nb = master->num_chipselect;
 
cs = devm_kzalloc(&master->dev,
  sizeof(int) * master->num_chipselect,
-- 
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: [GIT PULL] PCI changes for v3.9

[Yinghai Lu]

On Mon, Feb 25, 2013 at 9:19 PM, Linus Torvalds
 wrote:
> On Sat, Feb 23, 2013 at 6:49 PM, Yinghai Lu  wrote:
>>
>> Please check if attached diff is right, and hope it could save Linus some 
>> time.
>
> Hmm. I did things a bit differently, moving things around more in
> drivers/acpi/internal.h.

Yes, it is better to put them together with acpi_pci_root_init().

>
> Also, my *gut* feel is that the new _handle_hotplug_event_root()
> function should do that whole dance with
> acpi_scan_lock_acquire()/acpi_scan_lock_release(), but I didn't really
> know if it's required or appropriate, so I left it alone. Could you
> take a look?

Yes, we need that for root bridge hot add path.

for hot remove path, we already have lock acquire/release in
acpi_bus_hot_remove_device().

Please check attached patch for hot add path.

Thanks

Yinghai


fix_acpi_pci_root_acquire_lock.patch
Description: Binary data

[PATCH v5 2/8] mfd: Add commands abstraction layer for SI476X MFD

[Andrey Smirnov]

From: Andrey Smirnov 

This patch adds all the functions used for exchanging commands with
the chip.

Signed-off-by: Andrey Smirnov 
---
 drivers/mfd/si476x-cmd.c | 1553 ++
 1 file changed, 1553 insertions(+)
 create mode 100644 drivers/mfd/si476x-cmd.c

diff --git a/drivers/mfd/si476x-cmd.c b/drivers/mfd/si476x-cmd.c
new file mode 100644
index 000..0ae1b63
--- /dev/null
+++ b/drivers/mfd/si476x-cmd.c
@@ -0,0 +1,1553 @@
+/*
+ * drivers/mfd/si476x-cmd.c -- Subroutines implementing command
+ * protocol of si476x series of chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ * Copyright (C) 2013 Andrey Smirnov
+ *
+ * Author: Andrey Smirnov 
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define msb(x)  ((u8)((u16) x >> 8))
+#define lsb(x)  ((u8)((u16) x &  0x00FF))
+
+
+
+#define CMD_POWER_UP   0x01
+#define CMD_POWER_UP_A10_NRESP 1
+#define CMD_POWER_UP_A10_NARGS 5
+
+#define CMD_POWER_UP_A20_NRESP 1
+#define CMD_POWER_UP_A20_NARGS 5
+
+#define POWER_UP_DELAY_MS  110
+
+#define CMD_POWER_DOWN 0x11
+#define CMD_POWER_DOWN_A10_NRESP   1
+
+#define CMD_POWER_DOWN_A20_NRESP   1
+#define CMD_POWER_DOWN_A20_NARGS   1
+
+#define CMD_FUNC_INFO  0x12
+#define CMD_FUNC_INFO_NRESP7
+
+#define CMD_SET_PROPERTY   0x13
+#define CMD_SET_PROPERTY_NARGS 5
+#define CMD_SET_PROPERTY_NRESP 1
+
+#define CMD_GET_PROPERTY   0x14
+#define CMD_GET_PROPERTY_NARGS 3
+#define CMD_GET_PROPERTY_NRESP 4
+
+#define CMD_AGC_STATUS 0x17
+#define CMD_AGC_STATUS_NRESP_A10   2
+#define CMD_AGC_STATUS_NRESP_A206
+
+#define PIN_CFG_BYTE(x) (0x7F & (x))
+#define CMD_DIG_AUDIO_PIN_CFG  0x18
+#define CMD_DIG_AUDIO_PIN_CFG_NARGS4
+#define CMD_DIG_AUDIO_PIN_CFG_NRESP5
+
+#define CMD_ZIF_PIN_CFG0x19
+#define CMD_ZIF_PIN_CFG_NARGS  4
+#define CMD_ZIF_PIN_CFG_NRESP  5
+
+#define CMD_IC_LINK_GPO_CTL_PIN_CFG0x1A
+#define CMD_IC_LINK_GPO_CTL_PIN_CFG_NARGS  4
+#define CMD_IC_LINK_GPO_CTL_PIN_CFG_NRESP  5
+
+#define CMD_ANA_AUDIO_PIN_CFG  0x1B
+#define CMD_ANA_AUDIO_PIN_CFG_NARGS1
+#define CMD_ANA_AUDIO_PIN_CFG_NRESP2
+
+#define CMD_INTB_PIN_CFG   0x1C
+#define CMD_INTB_PIN_CFG_NARGS 2
+#define CMD_INTB_PIN_CFG_A10_NRESP 6
+#define CMD_INTB_PIN_CFG_A20_NRESP 3
+
+#define CMD_FM_TUNE_FREQ   0x30
+#define CMD_FM_TUNE_FREQ_A10_NARGS 5
+#define CMD_FM_TUNE_FREQ_A20_NARGS 3
+#define CMD_FM_TUNE_FREQ_NRESP 1
+
+#define CMD_FM_RSQ_STATUS  0x32
+
+#define CMD_FM_RSQ_STATUS_A10_NARGS1
+#define CMD_FM_RSQ_STATUS_A10_NRESP17
+#define CMD_FM_RSQ_STATUS_A30_NARGS1
+#define CMD_FM_RSQ_STATUS_A30_NRESP23
+
+
+#define CMD_FM_SEEK_START  0x31
+#define CMD_FM_SEEK_START_NARGS1
+#define CMD_FM_SEEK_START_NRESP1
+
+#define CMD_FM_RDS_STATUS  0x36
+#define CMD_FM_RDS_STATUS_NARGS1
+#define CMD_FM_RDS_STATUS_NRESP16
+
+#define CMD_FM_RDS_BLOCKCOUNT  0x37
+#define CMD_FM_RDS_BLOCKCOUNT_NARGS1
+#define CMD_FM_RDS_BLOCKCOUNT_NRESP8
+
+#define CMD_FM_PHASE_DIVERSITY 0x38
+#define CMD_FM_PHASE_DIVERSITY_NARGS   1
+#define CMD_FM_PHASE_DIVERSITY_NRESP   1
+
+#define CMD_FM_PHASE_DIV_STATUS0x39
+#define CMD_FM_PHASE_DIV_STATUS_NRESP  2
+
+#define CMD_AM_TUNE_FREQ   0x40
+#define CMD_AM_TUNE_FREQ_NARGS 3
+#define CMD_AM_TUNE_FREQ_NRESP 1
+
+#define CMD_AM_RSQ_STATUS  0x42
+#define CMD_AM_RSQ_STATUS_NARGS1
+#define CMD_AM_RSQ_STATUS_NRESP13
+
+#define CMD_AM_SEEK_START  0x41
+#define

[PATCH v5 1/8] mfd: Add header files and Kbuild plumbing for SI476x MFD core

[Andrey Smirnov]

From: Andrey Smirnov 

This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.

The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.

Signed-off-by: Andrey Smirnov 
---
 drivers/mfd/Kconfig |   13 +
 drivers/mfd/Makefile|4 +
 include/linux/mfd/si476x-core.h |  525 +++
 3 files changed, 542 insertions(+)
 create mode 100644 include/linux/mfd/si476x-core.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1c0abd4..3214927 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -970,6 +970,19 @@ config MFD_WL1273_CORE
  driver connects the radio-wl1273 V4L2 module and the wl1273
  audio codec.
 
+config MFD_SI476X_CORE
+   tristate "Support for Silicon Laboratories 4761/64/68 AM/FM radio."
+   depends on I2C
+   select MFD_CORE
+   default n
+   help
+ This is the core driver for the SI476x series of AM/FM
+ radio. This MFD driver connects the radio-si476x V4L2 module
+ and the si476x audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
 config MFD_OMAP_USB_HOST
bool "Support OMAP USBHS core and TLL driver"
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8b977f8..bf7627b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -131,6 +131,10 @@ obj-$(CONFIG_MFD_JZ4740_ADC)   += jz4740-adc.o
 obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
 obj-$(CONFIG_MFD_VX855)+= vx855.o
 obj-$(CONFIG_MFD_WL1273_CORE)  += wl1273-core.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE)  += si476x-core.o
+
 obj-$(CONFIG_MFD_CS5535)   += cs5535-mfd.o
 obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
 obj-$(CONFIG_MFD_PM8921_CORE)  += pm8921-core.o
diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..2136b26
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,525 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov 
+ *
+ * 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; version 2 of the License.
+ *
+ * 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.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Command Timeouts */
+#define SI476X_DEFAULT_TIMEOUT 10
+#define SI476X_TIMEOUT_TUNE70
+#define SI476X_TIMEOUT_POWER_UP33
+#define SI476X_STATUS_POLL_US  0
+
+/*  si476x-i2c.c --- */
+
+enum si476x_freq_supported_chips {
+   SI476X_CHIP_SI4761 = 1,
+   SI476X_CHIP_SI4764,
+   SI476X_CHIP_SI4768,
+};
+
+enum si476x_mfd_cells {
+   SI476X_RADIO_CELL = 0,
+   SI476X_CODEC_CELL,
+   SI476X_MFD_CELLS,
+};
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * turned on, reset line pulled high, IRQ line is enabled(polling is
+ * active for polling use scenario) and device is turned on with
+ * POWER_UP command. The device is ready to be used.
+ * @SI476X_POWER_INCONSISTENT: This state indicates that previous
+ * power down was inconsistent, meaning some of the regulators were
+ * not turned down and thus use of the device, without power-cycling
+ * is impossible.
+ */
+enum si476x_power_state {
+   SI476X_POWER_DOWN   = 0,
+   SI476X_POWER_UP_FULL= 1,
+   SI476X_POWER_INCONSISTENT   = 2,
+};
+
+/**
+ * struct si476x_core - internal data structure representing the
+ * underlying "core" device which all the MFD cell-devices use.
+ *
+ * @client: Actual I2C client used to transfer commands to the chip.
+ * @chip_id: Last digit of the chip model(E.g. "1" for SI4761)
+ * @cells: MFD cell devices created by this driver.
+ * @cmd_lock: Mutex used to serialize all the requests to the core
+ * device. 

[PATCH v5 3/8] mfd: Add the main bulk of core driver for SI476x code

[Andrey Smirnov]

From: Andrey Smirnov 

This patch adds main part(out of three) of the I2C driver for the
"core" of MFD device.

Signed-off-by: Andrey Smirnov 
---
 drivers/mfd/si476x-i2c.c |  878 ++
 1 file changed, 878 insertions(+)
 create mode 100644 drivers/mfd/si476x-i2c.c

diff --git a/drivers/mfd/si476x-i2c.c b/drivers/mfd/si476x-i2c.c
new file mode 100644
index 000..053a6a3
--- /dev/null
+++ b/drivers/mfd/si476x-i2c.c
@@ -0,0 +1,878 @@
+/*
+ * drivers/mfd/si476x-i2c.c -- Core device driver for si476x MFD
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ * Copyright (C) 2013 Andrey Smirnov
+ *
+ * Author: Andrey Smirnov 
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define SI476X_MAX_IO_ERRORS   10
+#define SI476X_DRIVER_RDS_FIFO_DEPTH   128
+
+/**
+ * si476x_core_config_pinmux() - pin function configuration function
+ *
+ * @core: Core device structure
+ *
+ * Configure the functions of the pins of the radio chip.
+ *
+ * The function returns zero in case of succes or negative error code
+ * otherwise.
+ */
+static int si476x_core_config_pinmux(struct si476x_core *core)
+{
+   int err;
+   dev_dbg(&core->client->dev, "Configuring pinmux\n");
+   err = si476x_core_cmd_dig_audio_pin_cfg(core,
+   core->pinmux.dclk,
+   core->pinmux.dfs,
+   core->pinmux.dout,
+   core->pinmux.xout);
+   if (err < 0) {
+   dev_err(&core->client->dev,
+   "Failed to configure digital audio pins(err = %d)\n",
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_zif_pin_cfg(core,
+ core->pinmux.iqclk,
+ core->pinmux.iqfs,
+ core->pinmux.iout,
+ core->pinmux.qout);
+   if (err < 0) {
+   dev_err(&core->client->dev,
+   "Failed to configure ZIF pins(err = %d)\n",
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_ic_link_gpo_ctl_pin_cfg(core,
+ core->pinmux.icin,
+ core->pinmux.icip,
+ core->pinmux.icon,
+ core->pinmux.icop);
+   if (err < 0) {
+   dev_err(&core->client->dev,
+   "Failed to configure IC-Link/GPO pins(err = %d)\n",
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_ana_audio_pin_cfg(core,
+   core->pinmux.lrout);
+   if (err < 0) {
+   dev_err(&core->client->dev,
+   "Failed to configure analog audio pins(err = %d)\n",
+   err);
+   return err;
+   }
+
+   err = si476x_core_cmd_intb_pin_cfg(core,
+  core->pinmux.intb,
+  core->pinmux.a1);
+   if (err < 0) {
+   dev_err(&core->client->dev,
+   "Failed to configure interrupt pins(err = %d)\n",
+   err);
+   return err;
+   }
+
+   return 0;
+}
+
+static inline void si476x_core_schedule_polling_work(struct si476x_core *core)
+{
+   schedule_delayed_work(&core->status_monitor,
+ usecs_to_jiffies(SI476X_STATUS_POLL_US));
+}
+
+/**
+ * si476x_core_start() - early chip startup function
+ * @core: Core device structure
+ * @soft: When set, this flag forces "soft" startup, where "soft"
+ * power down is the one done by sending appropriate command instead
+ * of using reset pin of the tuner
+ *
+ * Perform required startup sequence to correctly power
+ * up the chip and perform initial configuration. It does the
+ * following sequence of actions:
+ *   1. Claims and enables the power supplies VD and VIO1 required
+ *  for I2C interface of the chip operation.
+ *   2. Waits for 100us, pulls the reset line up, enables irq,
+ *  waits for another 100us as it is spe

[PATCH v5 5/8] v4l2: Add standard controls for FM receivers

[Andrey Smirnov]

This commit introduces new class of standard controls
V4L2_CTRL_CLASS_FM_RX. This class is intended to all controls
pertaining to FM receiver chips. Also, two controls belonging to said
class are added as a part of this commit: V4L2_CID_TUNE_DEEMPHASIS and
V4L2_CID_RDS_RECEPTION.

Signed-off-by: Andrey Smirnov 
---
 drivers/media/v4l2-core/v4l2-ctrls.c |   14 +++---
 include/uapi/linux/v4l2-controls.h   |   13 -
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6b28b58..8b89fb8 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -297,8 +297,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Text",
NULL
};
-   static const char * const tune_preemphasis[] = {
-   "No Preemphasis",
+   static const char * const tune_emphasis[] = {
+   "None",
"50 Microseconds",
"75 Microseconds",
NULL,
@@ -508,7 +508,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
case V4L2_CID_SCENE_MODE:
return scene_mode;
case V4L2_CID_TUNE_PREEMPHASIS:
-   return tune_preemphasis;
+   return tune_emphasis;
+   case V4L2_CID_TUNE_DEEMPHASIS:
+   return tune_emphasis;
case V4L2_CID_FLASH_LED_MODE:
return flash_led_mode;
case V4L2_CID_FLASH_STROBE_SOURCE:
@@ -799,6 +801,9 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_DV_RX_POWER_PRESENT:  return "Power Present";
case V4L2_CID_DV_RX_RGB_RANGE:  return "Rx RGB Quantization 
Range";
 
+   case V4L2_CID_FM_RX_CLASS:  return "FM Radio Receiver 
Controls";
+   case V4L2_CID_TUNE_DEEMPHASIS:  return "De-Emphasis";
+   case V4L2_CID_RDS_RECEPTION:return "RDS Reception";
default:
return NULL;
}
@@ -846,6 +851,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_MPEG4_QPEL:
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
+   case V4L2_CID_RDS_RECEPTION:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -904,6 +910,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_DV_TX_RGB_RANGE:
case V4L2_CID_DV_RX_RGB_RANGE:
case V4L2_CID_TEST_PATTERN:
+   case V4L2_CID_TUNE_DEEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
@@ -926,6 +933,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_IMAGE_SOURCE_CLASS:
case V4L2_CID_IMAGE_PROC_CLASS:
case V4L2_CID_DV_CLASS:
+   case V4L2_CID_FM_RX_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index dcd6374..296d20e 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -59,6 +59,7 @@
 #define V4L2_CTRL_CLASS_IMAGE_SOURCE   0x009e  /* Image source 
controls */
 #define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f  /* Image processing 
controls */
 #define V4L2_CTRL_CLASS_DV 0x00a0  /* Digital Video 
controls */
+#define V4L2_CTRL_CLASS_FM_RX  0x00a1  /* Digital Video 
controls */
 
 /* User-class control IDs */
 
@@ -711,10 +712,14 @@ enum v4l2_auto_focus_range {
 #define V4L2_CID_PILOT_TONE_FREQUENCY  (V4L2_CID_FM_TX_CLASS_BASE + 98)
 
 #define V4L2_CID_TUNE_PREEMPHASIS  (V4L2_CID_FM_TX_CLASS_BASE + 
112)
-enum v4l2_preemphasis {
+enum v4l2_xemphasis {
V4L2_PREEMPHASIS_DISABLED   = 0,
V4L2_PREEMPHASIS_50_uS  = 1,
V4L2_PREEMPHASIS_75_uS  = 2,
+   V4L2_DEEMPHASIS_DISABLED= V4L2_PREEMPHASIS_DISABLED,
+   V4L2_DEEMPHASIS_50_uS   = V4L2_PREEMPHASIS_50_uS,
+   V4L2_DEEMPHASIS_75_uS   = V4L2_PREEMPHASIS_75_uS,
+
 };
 #define V4L2_CID_TUNE_POWER_LEVEL  (V4L2_CID_FM_TX_CLASS_BASE + 
113)
 #define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
@@ -825,4 +830,10 @@ enum v4l2_dv_rgb_range {
 #defineV4L2_CID_DV_RX_POWER_PRESENT(V4L2_CID_DV_CLASS_BASE 
+ 100)
 #define V4L2_CID_DV_RX_RGB_RANGE   (V4L2_CID_DV_CLASS_BASE + 101)
 
+#define V4L2_CID_FM_RX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS   (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_TUNE_DEEMPHASIS   (V4L2_CID_FM_RX_

[PATCH v5 4/8] mfd: Add chip properties handling code for SI476X MFD

[Andrey Smirnov]

From: Andrey Smirnov 

This patch adds code related to manipulation of the properties of
SI476X chips.

Signed-off-by: Andrey Smirnov 
---
 drivers/mfd/si476x-prop.c |  234 +
 1 file changed, 234 insertions(+)
 create mode 100644 drivers/mfd/si476x-prop.c

diff --git a/drivers/mfd/si476x-prop.c b/drivers/mfd/si476x-prop.c
new file mode 100644
index 000..d2b5cc0
--- /dev/null
+++ b/drivers/mfd/si476x-prop.c
@@ -0,0 +1,234 @@
+/*
+ * drivers/mfd/si476x-prop.c -- Subroutines to manipulate with
+ * properties of si476x chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ * Copyright (C) 2013 Andrey Smirnov
+ *
+ * Author: Andrey Smirnov 
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#include 
+
+#include 
+#include 
+
+struct si476x_property_range {
+   u16 low, high;
+};
+
+static bool si476x_core_element_is_in_array(u16 element, const u16 array[], 
size_t size)
+{
+   int i;
+
+   for (i = 0; i < size; i++)
+   if (element == array[i])
+   return true;
+
+   return false;
+}
+
+static bool si476x_core_element_is_in_range(u16 element,
+   const struct si476x_property_range 
range[],
+   size_t size)
+{
+   int i;
+
+   for (i = 0; i < size; i++)
+   if (element <= range[i].high && element >= range[i].low)
+   return true;
+
+   return false;
+}
+
+static bool si476x_core_is_valid_property_a10(struct si476x_core *core,
+ u16 property)
+{
+   static const u16 valid_properties[] = {
+   0x,
+   0x0500, 0x0501,
+   0x0600,
+   0x0709, 0x070C, 0x070D, 0x70E, 0x710,
+   0x0718,
+   0x1207, 0x1208,
+   0x2007,
+   0x2300,
+   };
+
+   static const struct si476x_property_range valid_ranges[] = {
+   { 0x0200, 0x0203 },
+   { 0x0300, 0x0303 },
+   { 0x0400, 0x0404 },
+   { 0x0700, 0x0707 },
+   { 0x1100, 0x1102 },
+   { 0x1200, 0x1204 },
+   { 0x1300, 0x1306 },
+   { 0x2000, 0x2005 },
+   { 0x2100, 0x2104 },
+   { 0x2106, 0x2106 },
+   { 0x2200, 0x220E },
+   { 0x3100, 0x3104 },
+   { 0x3207, 0x320F },
+   { 0x3300, 0x3304 },
+   { 0x3500, 0x3517 },
+   { 0x3600, 0x3617 },
+   { 0x3700, 0x3717 },
+   { 0x4000, 0x4003 },
+   };
+
+   return  si476x_core_element_is_in_range(property, valid_ranges,
+   ARRAY_SIZE(valid_ranges)) ||
+   si476x_core_element_is_in_array(property, valid_properties,
+   ARRAY_SIZE(valid_properties));
+}
+
+static bool si476x_core_is_valid_property_a20(struct si476x_core *core,
+ u16 property)
+{
+   static const u16 valid_properties[] = {
+   0x071B,
+   0x1006,
+   0x2210,
+   0x3401,
+   };
+
+   static const struct si476x_property_range valid_ranges[] = {
+   { 0x2215, 0x2219 },
+   };
+
+   return  si476x_core_is_valid_property_a10(core, property) ||
+   si476x_core_element_is_in_range(property, valid_ranges,
+   ARRAY_SIZE(valid_ranges))  ||
+   si476x_core_element_is_in_array(property, valid_properties,
+   ARRAY_SIZE(valid_properties));
+}
+
+static bool si476x_core_is_valid_property_a30(struct si476x_core *core,
+ u16 property)
+{
+   static const u16 valid_properties[] = {
+   0x071C, 0x071D,
+   0x1007, 0x1008,
+   0x220F, 0x2214,
+   0x2301,
+   0x3105, 0x3106,
+   0x3402,
+   };
+
+   static const struct si476x_property_range valid_ranges[] = {
+   { 0x0405, 0x0411 },
+   { 0x2008, 0x200B },
+   { 0x2220, 0x2223 },
+   { 0x3100, 0x3106 },
+   };
+
+   return  si476x_core_is_valid_property_a20(core, property) ||
+   si476x_core_element_is_in_range(property, valid_ranges,
+   ARRAY_SIZE(valid_ranges

[PATCH v5 7/8] v4l2: Add private controls base for SI476X

[Andrey Smirnov]

Add a base to be used for allocation of all the SI476X specific
controls in the corresponding driver.

Signed-off-by: Andrey Smirnov 
---
 include/uapi/linux/v4l2-controls.h |4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 296d20e..133703d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -147,6 +147,10 @@ enum v4l2_colorfx {
  * of controls. We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_MEYE_BASE(V4L2_CID_USER_BASE + 
0x1000)
 
+/* The base for the si476x driver controls. See include/media/si476x.h for the 
list
+ * of controls. */
+#define V4L2_CID_USER_SI476X_BASE  (V4L2_CID_USER_BASE + 0x2000)
+
 /* MPEG-class control IDs */
 
 #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
-- 
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/

[PATCH v5 0/8] Driver for Si476x series of chips

[Andrey Smirnov]

This is a fourth version of the patchset originaly posted here:
https://lkml.org/lkml/2012/9/13/590

Second version of the patch was posted here:
https://lkml.org/lkml/2012/10/5/598

Third version of the patch was posted here:
https://lkml.org/lkml/2012/10/23/510

Fourth version of the patch was posted here:
https://lkml.org/lkml/2013/2/18/572

To save everyone's time I'll repost the original description of it:

This patchset contains a driver for a Silicon Laboratories 476x series
of radio tuners. The driver itself is implemented as an MFD devices
comprised of three parts: 
 1. Core device that provides all the other devices with basic
functionality and locking scheme.
 2. Radio device that translates between V4L2 subsystem requests into
Core device commands.
 3. Codec device that does similar to the earlier described task, but
for ALSA SoC subsystem.

v5 of this driver has following changes:
- Generic controls are converted to standard ones
- Custom controls use a differend offest as base
- Added documentation with controls description


Andrey Smirnov (8):
  mfd: Add header files and Kbuild plumbing for SI476x MFD core
  mfd: Add commands abstraction layer for SI476X MFD
  mfd: Add the main bulk of core driver for SI476x code
  mfd: Add chip properties handling code for SI476X MFD
  v4l2: Add standard controls for FM receivers
  v4l2: Add documentation for the FM RX controls
  v4l2: Add private controls base for SI476X
  v4l2: Add a V4L2 driver for SI476X MFD

 Documentation/DocBook/media/v4l/compat.xml |3 +
 Documentation/DocBook/media/v4l/controls.xml   |   72 +
 .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml   |   11 +-
 Documentation/video4linux/si476x.txt   |  187 +++
 drivers/media/radio/Kconfig|   17 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-si476x.c | 1581 
 drivers/media/v4l2-core/v4l2-ctrls.c   |   14 +-
 drivers/mfd/Kconfig|   13 +
 drivers/mfd/Makefile   |4 +
 drivers/mfd/si476x-cmd.c   | 1553 +++
 drivers/mfd/si476x-i2c.c   |  878 +++
 drivers/mfd/si476x-prop.c  |  234 +++
 include/linux/mfd/si476x-core.h|  525 +++
 include/media/si476x.h |  426 ++
 include/uapi/linux/v4l2-controls.h |   17 +-
 16 files changed, 5531 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/video4linux/si476x.txt
 create mode 100644 drivers/media/radio/radio-si476x.c
 create mode 100644 drivers/mfd/si476x-cmd.c
 create mode 100644 drivers/mfd/si476x-i2c.c
 create mode 100644 drivers/mfd/si476x-prop.c
 create mode 100644 include/linux/mfd/si476x-core.h
 create mode 100644 include/media/si476x.h

-- 
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: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

Dave,

Here's a further thought, extending on the analogy with closed
graphics hardware which requires proprietary drivers.  We _could_ have
made life easier for users who had the misfortune of purchasing closed
hardware.  We could have tied ourselves in knots and promulgated a
stable kernel ABI, so that Nvidia and ATI/AMD could more easly inflict
proprietary binary blob drivers just like they do for Windows.  We
chose not to screw ourselves over that way, even though it meant that
some users had a harder time of it.

Remember, before Intel came out with their graphics chips, for a while
it seemed that there were very grahpics options with decent
performance available that didn't require propietary drivers.  There
was a while when things looked pretty bleak.  Yet we didn't cave, and
eventually, life got better and more open options came on the scene.

Yet in the case of Secure Boot, everyone is assuming that Windows 8
will be a success, and that Microsoft will continue to dominate x86
client machines, and there will be no significant numbers of machines
that won't be locked down to Microsoft whims.  And so, we should run
up the white flag of surrender, and do everything that Microsoft
_might_ possibly require lest they capriciously and arbitrary decide
to revoke Linux distro's keys.

Linux distributions can do whatever they want, including locking down
kernel ABI's like they did for enterprise kernels (and I don't need to
tell people how painful that was for Linux distros).  But we didn't do
that for upstream kernels; instead, we pushed for open source device
drivers, and open hardware.  It took years, and we're still not 100%
successful, but we've made incredible progress, to the point where
we're no longer stressed out about device drivers any more; we just
avoid the proprietary crap, and it's not so hard to do that.

Maybe there's a lesson to be drawn from that which can be applied to
the Secure Boot mess.

Regards,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 found in loopback.c patch (0cf833a)

[Eric Dumazet]

On Mon, 2013-02-25 at 22:30 -0800, Neil Salstrom wrote:
> Hello,
> 
> I believe I have found a regression in drivers/net/loopback.c which was
> introduced starting with the v3.7 kernel series (and also affects
> v3.8).  Oddly enough, it affects DVD playback (both physical disk and
> .iso files) in MythTV (I'm using v0.26 and compile from source).  I
> don't know if MythTV mounts a .iso or DVD over a loopback device but for
> whatever reason there is a problem.
> 
> When playing a DVD there is a constant stuttering of the video and
> corresponding audio dropouts.  This is continual with mythfrontend logs
> showing "Waiting for video buffers."
> 
> I found that any kernel before v3.7 did not cause this issue so I did a
> git bisect between v3.6 and v3.7.  The resulting bisection was to commit
> 0cf833a (net: loopback: set default mtu to 64K).
> 
> I downloaded the source to v3.7.9 and reverted the line:
> 
> dev->mtu = 64 * 1024;
> 
> back to:
> 
> dev->mtu = (16 * 1024) + 20 + 20 + 12;
> 
> 
> The resulting kernel did not cause the playback stuttering.  I have also
> compiled v3.8.0 using (16 * 1024) + 20 + 20 + 12; and again had no problems.
> 
> Please let me know if you have any questions.
> 
> Thank you,
> 
> Neil Salstrom
> 

Hmm, I suspect an application bug.

Try to find what particular mtu value makes the application going bad,
doing a dichotomy ?

No need to recompile the kernel :

ifconfig lo mtu X



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Abysmal HDD/USB write speed after sleep on a UEFI system

[Artem S. Tashkinov]

Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>
>Where are we at with this, Artem?  I assume it's still a problem.
>

Yes, it is, Bjorn.

In order to eliminate this problem I switched back to MBR yesterday, because
so far I haven't received any instructions or guidance as to how I can debug
it further. I'm absolutely sure USB write speed is just another manifestation of
it so I decided not to debug USB specifically (it just doesn't make too much
sense).

What I see is that something terribly wrong is going on but if Linus has no 
ideas
I, as an average Joe, don't have a slightest clue as to what I can do.

The bug report with necessary, but seemingly useless information, can be 
found here: https://bugzilla.kernel.org/show_bug.cgi?id=53551

If anyone comes up with new ideas I can quickly try UEFI again now that I
have two HDDs at my disposal (the old one is formatted as GPT, the new one is
MBR).

Best regards,

Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 found in loopback.c patch (0cf833a)

[Neil Salstrom]

Hello,

I believe I have found a regression in drivers/net/loopback.c which was
introduced starting with the v3.7 kernel series (and also affects
v3.8).  Oddly enough, it affects DVD playback (both physical disk and
.iso files) in MythTV (I'm using v0.26 and compile from source).  I
don't know if MythTV mounts a .iso or DVD over a loopback device but for
whatever reason there is a problem.

When playing a DVD there is a constant stuttering of the video and
corresponding audio dropouts.  This is continual with mythfrontend logs
showing "Waiting for video buffers."

I found that any kernel before v3.7 did not cause this issue so I did a
git bisect between v3.6 and v3.7.  The resulting bisection was to commit
0cf833a (net: loopback: set default mtu to 64K).

I downloaded the source to v3.7.9 and reverted the line:

dev->mtu = 64 * 1024;

back to:

dev->mtu = (16 * 1024) + 20 + 20 + 12;


The resulting kernel did not cause the playback stuttering.  I have also
compiled v3.8.0 using (16 * 1024) + 20 + 20 + 12; and again had no problems.

Please let me know if you have any questions.

Thank you,

Neil Salstrom


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

[RFC PATCH v2 3/4] arm: Add support for LZ4-compressed kernel

[Kyungsik Lee]

This patch integrates the LZ4 decompression code to the arm pre-boot code.
And it depends on two patchs below

lib: Add support for LZ4-compressed kernel
decompressor: Add LZ4 decompressor module

Signed-off-by: Kyungsik Lee 

v2:
- Apply CFLAGS, -Os to decompress.o to improve decompress
  performance during boot-up process
---
 arch/arm/Kconfig  | 1 +
 arch/arm/boot/compressed/.gitignore   | 1 +
 arch/arm/boot/compressed/Makefile | 6 +-
 arch/arm/boot/compressed/decompress.c | 4 
 arch/arm/boot/compressed/piggy.lz4.S  | 6 ++
 5 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/compressed/piggy.lz4.S

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..0f9b363 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -38,6 +38,7 @@ config ARM
select HAVE_IDE if PCI || ISA || PCMCIA
select HAVE_IRQ_WORK
select HAVE_KERNEL_GZIP
+   select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
select HAVE_KERNEL_XZ
diff --git a/arch/arm/boot/compressed/.gitignore 
b/arch/arm/boot/compressed/.gitignore
index f79a08e..47279aa 100644
--- a/arch/arm/boot/compressed/.gitignore
+++ b/arch/arm/boot/compressed/.gitignore
@@ -6,6 +6,7 @@ piggy.gzip
 piggy.lzo
 piggy.lzma
 piggy.xzkern
+piggy.lz4
 vmlinux
 vmlinux.lds
 
diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index 5cad8a6..2249d52 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -24,6 +24,9 @@ endif
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
 HEAD   = head.o
 OBJS   += misc.o decompress.o
+ifeq ($(CONFIG_KERNEL_LZ4),y)
+CFLAGS_decompress.o := -Os
+endif
 FONTC  = $(srctree)/drivers/video/console/font_acorn_8x8.c
 
 # string library code (-Os is enforced to keep it much smaller)
@@ -88,6 +91,7 @@ suffix_$(CONFIG_KERNEL_GZIP) = gzip
 suffix_$(CONFIG_KERNEL_LZO)  = lzo
 suffix_$(CONFIG_KERNEL_LZMA) = lzma
 suffix_$(CONFIG_KERNEL_XZ)   = xzkern
+suffix_$(CONFIG_KERNEL_LZ4)  = lz4
 
 # Borrowed libfdt files for the ATAG compatibility mode
 
@@ -112,7 +116,7 @@ targets   := vmlinux vmlinux.lds \
 font.o font.c head.o misc.o $(OBJS)
 
 # Make sure files are removed during clean
-extra-y   += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern \
+extra-y   += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
 lib1funcs.S ashldi3.S $(libfdt) $(libfdt_hdrs)
 
 ifeq ($(CONFIG_FUNCTION_TRACER),y)
diff --git a/arch/arm/boot/compressed/decompress.c 
b/arch/arm/boot/compressed/decompress.c
index 9deb56a..a95f071 100644
--- a/arch/arm/boot/compressed/decompress.c
+++ b/arch/arm/boot/compressed/decompress.c
@@ -53,6 +53,10 @@ extern char * strstr(const char * s1, const char *s2);
 #include "../../../../lib/decompress_unxz.c"
 #endif
 
+#ifdef CONFIG_KERNEL_LZ4
+#include "../../../../lib/decompress_unlz4.c"
+#endif
+
 int do_decompress(u8 *input, int len, u8 *output, void (*error)(char *x))
 {
return decompress(input, len, NULL, NULL, output, NULL, error);
diff --git a/arch/arm/boot/compressed/piggy.lz4.S 
b/arch/arm/boot/compressed/piggy.lz4.S
new file mode 100644
index 000..3d9a575
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.lz4.S
@@ -0,0 +1,6 @@
+   .section .piggydata,#alloc
+   .globl  input_data
+input_data:
+   .incbin "arch/arm/boot/compressed/piggy.lz4"
+   .globl  input_data_end
+input_data_end:
-- 
1.8.1.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/

[RFC PATCH v2 4/4] x86: Add support for LZ4-compressed kernel

[Kyungsik Lee]

This patch integrates the LZ4 decompression code to the x86 pre-boot code.
And it depends on two patchs below

lib: Add support for LZ4-compressed kernel
decompressor: Add LZ4 decompressor module

Signed-off-by: Kyungsik Lee 
---
 arch/x86/Kconfig  | 1 +
 arch/x86/boot/compressed/Makefile | 5 -
 arch/x86/boot/compressed/misc.c   | 4 
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 225543b..ab916fd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -63,6 +63,7 @@ config X86
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_XZ
select HAVE_KERNEL_LZO
+   select HAVE_KERNEL_LZ4
select HAVE_HW_BREAKPOINT
select HAVE_MIXED_BREAKPOINTS_REGS
select PERF_EVENTS
diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 8a84501..c275db5 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -4,7 +4,7 @@
 # create a compressed vmlinux image from the original vmlinux
 #
 
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 
vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo head_$(BITS).o misc.o string.o 
cmdline.o early_serial_console.o piggy.o
+targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 
vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4 head_$(BITS).o 
misc.o string.o cmdline.o early_serial_console.o piggy.o
 
 KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
 KBUILD_CFLAGS += -fno-strict-aliasing -fPIC
@@ -64,12 +64,15 @@ $(obj)/vmlinux.bin.xz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,xzkern)
 $(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzo)
+$(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
+   $(call if_changed,lz4)
 
 suffix-$(CONFIG_KERNEL_GZIP)   := gz
 suffix-$(CONFIG_KERNEL_BZIP2)  := bz2
 suffix-$(CONFIG_KERNEL_LZMA)   := lzma
 suffix-$(CONFIG_KERNEL_XZ) := xz
 suffix-$(CONFIG_KERNEL_LZO):= lzo
+suffix-$(CONFIG_KERNEL_LZ4):= lz4
 
 quiet_cmd_mkpiggy = MKPIGGY $@
   cmd_mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false )
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 88f7ff6..166a0a8 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -145,6 +145,10 @@ static int lines, cols;
 #include "../../../../lib/decompress_unlzo.c"
 #endif
 
+#ifdef CONFIG_KERNEL_LZ4
+#include "../../../../lib/decompress_unlz4.c"
+#endif
+
 static void scroll(void)
 {
int i;
-- 
1.8.1.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/

[RFC PATCH v2 2/4] lib: Add support for LZ4-compressed kernel

[Kyungsik Lee]

This patch adds support for extracting LZ4-compressed kernel images,
as well as LZ4-compressed ramdisk images in the kernel boot process.

This depends on the patch below
decompressor: Add LZ4 decompressor module

Signed-off-by: Kyungsik Lee 

v2:
- Clean up code
- Use lz4_decompress() for LZ4-compressed kernel during boot-process
---
 include/linux/decompress/unlz4.h |  10 +++
 init/Kconfig |  13 ++-
 lib/Kconfig  |   7 ++
 lib/Makefile |   2 +
 lib/decompress.c |   5 ++
 lib/decompress_unlz4.c   | 190 +++
 lib/lz4/Makefile |   1 +
 lib/lz4/lz4_decompress.c |   2 +-
 scripts/Makefile.lib |   5 ++
 usr/Kconfig  |   9 ++
 10 files changed, 242 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/decompress/unlz4.h
 create mode 100644 lib/decompress_unlz4.c
 create mode 100644 lib/lz4/Makefile

diff --git a/include/linux/decompress/unlz4.h b/include/linux/decompress/unlz4.h
new file mode 100644
index 000..d5b68bf
--- /dev/null
+++ b/include/linux/decompress/unlz4.h
@@ -0,0 +1,10 @@
+#ifndef DECOMPRESS_UNLZ4_H
+#define DECOMPRESS_UNLZ4_H
+
+int unlz4(unsigned char *inbuf, int len,
+   int(*fill)(void*, unsigned int),
+   int(*flush)(void*, unsigned int),
+   unsigned char *output,
+   int *pos,
+   void(*error)(char *x));
+#endif
diff --git a/init/Kconfig b/init/Kconfig
index be8b7f5..86dc67c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -133,10 +133,13 @@ config HAVE_KERNEL_XZ
 config HAVE_KERNEL_LZO
bool
 
+config HAVE_KERNEL_LZ4
+   bool
+
 choice
prompt "Kernel compression mode"
default KERNEL_GZIP
-   depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || 
HAVE_KERNEL_XZ || HAVE_KERNEL_LZO
+   depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || 
HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4
help
  The linux kernel is a kind of self-extracting executable.
  Several compression algorithms are available, which differ
@@ -203,6 +206,14 @@ config KERNEL_LZO
  size is about 10% bigger than gzip; however its speed
  (both compression and decompression) is the fastest.
 
+config KERNEL_LZ4
+   bool "LZ4"
+   depends on HAVE_KERNEL_LZ4
+   help
+ Its compression ratio is worse than LZO. The size of the kernel
+ is about 8% bigger than LZO. But the decompression speed is
+ faster than LZO.
+
 endchoice
 
 config DEFAULT_HOSTNAME
diff --git a/lib/Kconfig b/lib/Kconfig
index 75cdb77..b108047 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -189,6 +189,9 @@ config LZO_COMPRESS
 config LZO_DECOMPRESS
tristate
 
+config LZ4_DECOMPRESS
+   tristate
+
 source "lib/xz/Kconfig"
 
 #
@@ -213,6 +216,10 @@ config DECOMPRESS_LZO
select LZO_DECOMPRESS
tristate
 
+config DECOMPRESS_LZ4
+   select LZ4_DECOMPRESS
+   tristate
+
 #
 # Generic allocator support is selected if needed
 #
diff --git a/lib/Makefile b/lib/Makefile
index 02ed6c0..c2073bf 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/
 obj-$(CONFIG_BCH) += bch.o
 obj-$(CONFIG_LZO_COMPRESS) += lzo/
 obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
+obj-$(CONFIG_LZ4_DECOMPRESS) += lz4/
 obj-$(CONFIG_XZ_DEC) += xz/
 obj-$(CONFIG_RAID6_PQ) += raid6/
 
@@ -80,6 +81,7 @@ lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
 lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
 lib-$(CONFIG_DECOMPRESS_XZ) += decompress_unxz.o
 lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
+lib-$(CONFIG_DECOMPRESS_LZ4) += decompress_unlz4.o
 
 obj-$(CONFIG_TEXTSEARCH) += textsearch.o
 obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o
diff --git a/lib/decompress.c b/lib/decompress.c
index 31a8042..c70810e 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,9 @@
 #ifndef CONFIG_DECOMPRESS_LZO
 # define unlzo NULL
 #endif
+#ifndef CONFIG_DECOMPRESS_LZ4
+# define unlz4 NULL
+#endif
 
 struct compress_format {
unsigned char magic[2];
@@ -45,6 +49,7 @@ static const struct compress_format compressed_formats[] 
__initdata = {
{ {0x5d, 0x00}, "lzma", unlzma },
{ {0xfd, 0x37}, "xz", unxz },
{ {0x89, 0x4c}, "lzo", unlzo },
+   { {0x02, 0x21}, "lz4", unlz4 },
{ {0, 0}, NULL, NULL }
 };
 
diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c
new file mode 100644
index 000..84346c4
--- /dev/null
+++ b/lib/decompress_unlz4.c
@@ -0,0 +1,190 @@
+/*
+ * Wrapper for decompressing LZ4-compressed kernel, initramfs, and initrd
+ *
+ * Copyright (C) 2013, LG Electronics, Kyungsik Lee 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as publi

[RFC PATCH v2 1/4] decompressor: Add LZ4 decompressor module

[Kyungsik Lee]

This patch adds support for LZ4 decompression in the Linux Kernel.
LZ4 Decompression APIs for kernel are based on LZ4 implementation
by Yann Collet.

LZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html
LZ4 source repository : http://code.google.com/p/lz4/

Signed-off-by: Kyungsik Lee 

v2:
- Clean up code
- Enable unaligned access for ARM v6 and above with
  CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
- Add lz4_decompress() for faster decompression with
  uncompressed output size
---
 include/linux/lz4.h  |  48 +++
 lib/lz4/lz4_decompress.c | 331 +++
 lib/lz4/lz4defs.h|  93 +
 3 files changed, 472 insertions(+)
 create mode 100644 include/linux/lz4.h
 create mode 100644 lib/lz4/lz4_decompress.c
 create mode 100644 lib/lz4/lz4defs.h

diff --git a/include/linux/lz4.h b/include/linux/lz4.h
new file mode 100644
index 000..66b504c
--- /dev/null
+++ b/include/linux/lz4.h
@@ -0,0 +1,48 @@
+#ifndef __LZ4_H__
+#define __LZ4_H__
+/*
+ * LZ4 Kernel Interface
+ *
+ * Copyright (C) 2013, LG Electronics, Kyungsik Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * LZ4_COMPRESSBOUND()
+ * Provides the maximum size that LZ4 may output in a "worst case" scenario
+ * (input data not compressible)
+ */
+#define LZ4_COMPRESSBOUND(isize) (isize + ((isize)/255) + 16)
+
+/*
+ * lz4_decompress()
+ * src : source address of the compressed data
+ * src_len : is the input size, whcih is returned after decompress done
+ * dest: output buffer address of the decompressed data
+ * actual_dest_len: is the size of uncompressed data, supposing it's known
+ * return  : Success if return 0
+ *   Error if return (< 0)
+ * note :  Destination buffer must be already allocated.
+ * a bit faster than lz4_decompress_unknownoutputsize()
+ */
+int lz4_decompress(const char *src, size_t *src_len, char *dest,
+   size_t actual_dest_len);
+
+/*
+ * lz4_decompress_unknownoutputsize()
+ * src : source address of the compressed data
+ * src_len : is the input size, therefore the compressed size
+ * dest: output buffer address of the decompressed data
+ * dest_len: is the max size of the destination buffer, which is
+ * returned with actual size of decompressed data after
+ * decompress done
+ * return  : Success if return 0
+ *   Error if return (< 0)
+ * note :  Destination buffer must be already allocated.
+ */
+int lz4_decompress_unknownoutputsize(const char *src, size_t src_len,
+   char *dest, size_t *dest_len);
+#endif
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
new file mode 100644
index 000..1998d7a
--- /dev/null
+++ b/lib/lz4/lz4_decompress.c
@@ -0,0 +1,331 @@
+/*
+ * LZ4 Decompressor for Linux kernel
+ *
+ * Copyright (C) 2013 LG Electronics Co., Ltd. (http://www.lge.com/)
+ *
+ * Based on LZ4 implementation by Yann Collet.
+ *
+ * LZ4 - Fast LZ compression algorithm
+ * Copyright (C) 2011-2012, Yann Collet.
+ * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You can contact the author at :
+ *  - LZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html
+ *  - LZ4 source repository : http://code.google.com/p/lz4/
+ */
+
+#ifndef STATIC
+#include 
+#include 
+#endif
+#include 
+
+#include 
+
+#include "lz4defs.h"
+
+static int lz4_uncompress(const char *source, char *dest, int os

[RFC PATCH v2 0/4] Add support for LZ4-compressed kernel

[Kyungsik Lee]

Hi,

First of all, Thank you for the comments and emails from the community.

Here is the second version of support for LZ4-compressed kernel.
In this version, lz4_decompress() has been added. In case of knowing
the uncompressed data size, this function can be used to decompress
more faster.

Through the benchmark, it was found that -Os Compiler flag for
decompress.o brought better decompression performance in most of cases
(ex, different compiler and hardware spec.) in ARM architecture.

Lastly, CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not always the best
option even though it is supported. The decompression speed can be
slightly slower in some cases.

This patchset is based on 3.8.

Any comments are appreciated.

Thanks,
Kyungsik


Benchmark Results(PATCH v2)
Compiler: Linaro ARM gcc 4.6.2
1. ARMv7, 1.5GHz based board
   Kernel: linux 3.4
   Uncompressed Kernel Size: 14MB
Compressed Size  Decompression Speed
   LZO  6.7MB21.1MB/s
   LZ4  7.3MB29.1MB/s, 45.6MB/s(UA)
2. ARMv7, 1.7GHz based board
   Kernel: linux 3.7
   Uncompressed Kernel Size: 14MB
Compressed Size  Decompression Speed
   LZO  6.0MB34.1MB/s
   LZ4  6.5MB86.7MB/s
UA: Unaligned memory Access support


Change log: v2
- Clean up code
- Enable unaligned access for ARM v6 and above with
  CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
- Add lz4_decompress() for faster decompression with
  uncompressed output size
- Use lz4_decompress() for LZ4-compressed kernel during
  boot-process
- Apply -Os to decompress.o to improve decompress
  performance during boot-up process


Kyungsik Lee (4):
  decompressor: Add LZ4 decompressor module
  lib: Add support for LZ4-compressed kernel
  arm: Add support for LZ4-compressed kernel
  x86: Add support for LZ4-compressed kernel

 arch/arm/Kconfig  |   1 +
 arch/arm/boot/compressed/.gitignore   |   1 +
 arch/arm/boot/compressed/Makefile |   6 +-
 arch/arm/boot/compressed/decompress.c |   4 +
 arch/arm/boot/compressed/piggy.lz4.S  |   6 +
 arch/x86/Kconfig  |   1 +
 arch/x86/boot/compressed/Makefile |   5 +-
 arch/x86/boot/compressed/misc.c   |   4 +
 include/linux/decompress/unlz4.h  |  10 +
 include/linux/lz4.h   |  48 +
 init/Kconfig  |  13 +-
 lib/Kconfig   |   7 +
 lib/Makefile  |   2 +
 lib/decompress.c  |   5 +
 lib/decompress_unlz4.c| 190 +++
 lib/lz4/Makefile  |   1 +
 lib/lz4/lz4_decompress.c  | 331 ++
 lib/lz4/lz4defs.h |  93 ++
 scripts/Makefile.lib  |   5 +
 usr/Kconfig   |   9 +
 20 files changed, 739 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/compressed/piggy.lz4.S
 create mode 100644 include/linux/decompress/unlz4.h
 create mode 100644 include/linux/lz4.h
 create mode 100644 lib/decompress_unlz4.c
 create mode 100644 lib/lz4/Makefile
 create mode 100644 lib/lz4/lz4_decompress.c
 create mode 100644 lib/lz4/lz4defs.h

-- 
1.8.1.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: what's the next LTSI kernel version for long-term support

[Greg Kroah-Hartman]

On Tue, Feb 26, 2013 at 01:36:09PM +0800, Barry Song wrote:
> Hi Greg,
> 
> 2013/2/26 Greg Kroah-Hartman :
> > On Tue, Feb 26, 2013 at 11:46:04AM +0800, Barry Song wrote:
> >> 2013/2/26 Greg Kroah-Hartman :
> >> > On Tue, Feb 26, 2013 at 11:06:56AM +0800, Barry Song wrote:
> >> >> Hi Greg/All,
> >> >> we have seen 3.4 was announced to be an LTSI in Aug, 2012. I'd like to
> >> >> know what is the next LTSI version since we might want to align our
> >> >> next release with LTSI.
> >> >
> >> > Who is "we" here?
> >> >
> >> people.
> >
> > I don't take anonymous "we want this" requests serious at all, sorry.
> > Please provide details as you are asking me to do work for you, right?
> >
> 
> i just want to get some generic information not specific to any SoC
> vendor at all :-)

Then my generic response is going to be, "It will be announced when it
will be announced."

sorry,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] DMA-mapping updates for v3.9-rc1

[Marek Szyprowski]

Hi Linus,

I would like to ask You for pulling some fixes and extensions to ARM
dma-mapping subsystem for v3.9-rc1.

The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:

  Linux 3.8 (2013-02-18 15:58:34 -0800)

are available in the git repository at:

  git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.9

for you to fetch changes up to d589829107c5528164a9b7dfe50d0001780865ed:

  ARM: DMA-mapping: fix memory leak in IOMMU dma-mapping implementation 
(2013-02-25 15:30:44 +0100)



This time all patches are related only to ARM DMA-mapping subsystem. The
main extension provided by this pull request is highmem support. Besides
that it contains a bunch of small bugfixes and cleanups.

Thanks!

Best regards
Marek Szyprowski
Samsung Poland R&D Center


Patch summary:

Hiroshi Doyu (3):
  ARM: dma-mapping: Set arm_dma_set_mask() for iommu->set_dma_mask()
  ARM: dma-mapping: Add macro to_dma_iommu_mapping()
  ARM: dma-mapping: Add arm_iommu_detach_device()

Laurent Pinchart (1):
  ARM: iommu: Include linux/kref.h in asm/dma-iommu.h

Marek Szyprowski (3):
  ARM: dma-mapping: add support for CMA regions placed in highmem zone
  ARM: dma-mapping: use himem for DMA buffers for IOMMU-mapped devices
  ARM: DMA-mapping: fix memory leak in IOMMU dma-mapping implementation

Prathyush K (1):
  arm: dma mapping: export arm iommu functions

Seung-Woo Kim (1):
  ARM: dma-mapping: Add maximum alignment order for dma iommu buffers

 arch/arm/Kconfig |   21 
 arch/arm/include/asm/device.h|6 +++
 arch/arm/include/asm/dma-iommu.h |2 +
 arch/arm/mm/dma-mapping.c|  108 +++---
 4 files changed, 117 insertions(+), 20 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.

[Sethi Varun-B16395]

This patch is not present in Joerg's tree and the add_device API in the PAMU 
driver requires this patch.

-Varun

> -Original Message-
> From: Stuart Yoder [mailto:b08...@gmail.com]
> Sent: Tuesday, February 26, 2013 5:39 AM
> To: Sethi Varun-B16395
> Cc: io...@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; Wood Scott-B07421; Joerg Roedel; Yoder
> Stuart-B08248
> Subject: Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device
> information corresponding to the pci controller.
> 
> This patch was submitted separately to linuxppc-dev (and was already
> applied).  You don't need it in this patch set, right?
> 
> Stuart
> 
> On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi 
> wrote:
> > The pci controller structure has a provision to store the device
> > strcuture pointer of the corresponding platform device. Currently this
> > information is not stored during fsl pci controller initialization.
> > This information is required while dealing with iommu groups for pci
> > devices connected to the fsl pci controller. For the case where the
> > pci devices can't be paritioned, they would fall under the same device
> group as the pci controller.
> >
> > This patch stores the platform device information in the pci
> > controller structure during initialization.
> >
> > Signed-off-by: Varun Sethi 
> > ---
> >  arch/powerpc/sysdev/fsl_pci.c |9 +++--
> >  arch/powerpc/sysdev/fsl_pci.h |2 +-
> >  2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c index 92a5915..b393ae7 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -421,13 +421,16 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
> > }
> >  }
> >
> > -int __init fsl_add_bridge(struct device_node *dev, int is_primary)
> > +int __init fsl_add_bridge(struct platform_device *pdev, int
> > +is_primary)
> >  {
> > int len;
> > struct pci_controller *hose;
> > struct resource rsrc;
> > const int *bus_range;
> > u8 hdr_type, progif;
> > +   struct device_node *dev;
> > +
> > +   dev = pdev->dev.of_node;
> >
> > if (!of_device_is_available(dev)) {
> > pr_warning("%s: disabled\n", dev->full_name); @@
> > -453,6 +456,8 @@ int __init fsl_add_bridge(struct device_node *dev, int
> is_primary)
> > if (!hose)
> > return -ENOMEM;
> >
> > +   /* set platform device as the parent */
> > +   hose->parent = &pdev->dev;
> > hose->first_busno = bus_range ? bus_range[0] : 0x0;
> > hose->last_busno = bus_range ? bus_range[1] : 0xff;
> >
> > @@ -880,7 +885,7 @@ static int fsl_pci_probe(struct platform_device
> > *pdev)  #endif
> >
> > node = pdev->dev.of_node;
> > -   ret = fsl_add_bridge(node, fsl_pci_primary == node);
> > +   ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
> >
> >  #ifdef CONFIG_SWIOTLB
> > if (ret == 0) {
> > diff --git a/arch/powerpc/sysdev/fsl_pci.h
> > b/arch/powerpc/sysdev/fsl_pci.h index d078537..c495c00 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.h
> > +++ b/arch/powerpc/sysdev/fsl_pci.h
> > @@ -91,7 +91,7 @@ struct ccsr_pci {
> > __be32  pex_err_cap_r3; /* 0x.e34 - PCIE error capture
> register 0 */
> >  };
> >
> > -extern int fsl_add_bridge(struct device_node *dev, int is_primary);
> > +extern int fsl_add_bridge(struct platform_device *pdev, int
> > +is_primary);
> >  extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);  extern int
> > mpc83xx_add_bridge(struct device_node *dev);
> >  u64 fsl_pci_immrbar_base(struct pci_controller *hose);
> > --
> > 1.7.4.1
> >
> >
> > ___
> > iommu mailing list
> > io...@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

[Tang Chen]

On 02/26/2013 12:51 PM, Martin Bligh wrote:

Do you mean we can remove numaq x86 32bit code now?


Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
Was useful in the early days of getting NUMA up and running on Linux,
but is now too old to be a museum piece, really.

M.



Hi Martin, Yinghai,

It was me that I failed to make numa_init() fall back path working, and 
forgot
to call early_parse_srat in ia64. Sorry for the breaking of other 
platform. :)


So now, is Yinghai's patch enough for this problem ?
Or we can encapsulate the following clear up work into one function ?

+   for (i = 0; i < MAX_LOCAL_APIC; i++)
+   set_apicid_to_node(i, NUMA_NO_NODE);
+   nodes_clear(numa_nodes_parsed);
+   memset(&numa_meminfo, 0, sizeof(numa_meminfo));


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: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 02:55:32PM +1000, Dave Airlie wrote:
> 
> So it would be nice if LF could undertake to go and talk to Microsoft,
> and get vague opinions turned into something real.

Uh, folks like James and Greg K-H have talked to folks at
Microsoft I haven't talked to the folks at Microsoft personally,
but my understanding is that did _not_ tell us we had to do what
Matthew claims other folks at Mircrosoft have claimed that we have to
do, "or else".

> Ted you might be at liberty to get a chromebook pixel from google, but
> that isn't going to help the other X% of users who have a PC they want
> to use Linux on, and maybe boot Windows to do their taxes.

The point is that users will have choices.  It wasn't the end of the
world when some laptop manufacturers shipped devices that required
crappy Nvidia drivers.  I just simply chose not to buy laptops that
were crippled with the Optimus chipset, and purchased laptops that
used Intel graphics instead.  That's the free market at work.

Yes, it's sad that some users got stuck buying hardware which screwed
them over and made it very hard or impossible to use bleeding edge
kernels.  It's too bad some people had to learn the hard way.  The
good news though is that people who did do their due diligence could
purchase open hardware, and not get screwed by peripherals that
required proprietary drivers, whether they be WiFi or Graphics
drivers.

Of course, there are still crappy laptops that require proprietary
drivers, or for which no Linux drivers exist at all.  There's a reason
why I buy Thinkpads and not Sony laptops.  Similarly, the good news is
that there are open x86 devices being sold right now, post Windows-8,
which don't require us to be beholden to Microsoft.  Yes, there will
be users who buy the locked down crap.  There are also users who buy
Sony laptops.  Sometimes, we can't help everyone, and somtimes, it's
better not to encourage users to use hardware that require propietary
drivers, but to rather incentize them to use open hardware instead.

Regards,

 - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [B.A.T.M.A.N.] batman-adv: gpf in batadv_slide_own_bcast_window

[Marek Lindner]

On Saturday, February 23, 2013 02:37:06 Sasha Levin wrote:
> I'm confused about how batadv_orig_hash_del_if removes an interface from
> the hashtable. I see the hashtable is using rcu to protect it, but when we
> delete an entry we free it straight away by calling
> batadv_orig_node_del_if() and not going through kfree_rcu().
> 
> Is there a reason behind doing that, or might it be the cause of the
> problem we're seeing here?

Maybe I am overlooking something but it seems to me access to this memory is 
protected by the same lock: orig_node->ogm_cnt_lock
Before batadv_orig_node_del_if() is called this lock is acquired and 
batadv_slide_own_bcast_window() also attempts acquire the orig_node-
>ogm_cnt_lock spinlock before writing to this chunk of memory.

Do we know for certain that batadv_orig_hash_del_if() is involved or is that a 
guess at this point ? If you ask me the next for-loop in 
batadv_orig_hash_del_if() looks more suspicious than the first one. The 
interfaces get renumbered without any protection. Could be a regression from 
the orig_hash_lock removal (the comments refer to a now inexisting lock).

Cheers,
Marek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()

[Artem Savkov]

On Mon, Feb 25, 2013 at 03:54:45PM -0800, Andrew Morton wrote:
> On Sun, 24 Feb 2013 13:22:02 +0400
> Artem Savkov  wrote:
> 
> > set_freezable() checks freezing during which no locks should be held.
> > hotkey_thread_mutex lock should be moved closer to where it is actually 
> > needed.
> > 
> 
> Thanks.
> 
> When fixing a bug, we always like to see a full description of that bug
> so we can better work out which kernel versions need the fix.
Sorry, will do thah in future.

> Did you actually hit a lockup because of this?  Or was it just from
> code inspection?  Or ...  ?
I didn't hit an actual lockup, but I did hit a warning during boot. The
warning was added by "lockdep: check that no locks held at freeze time"
patch (2f2ff7b8979c50491b3cbce622d7bea4d44a8682 in linux-next.git)


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

Re: [PATCH] perf report: fix handling of memory sampling sort orders

[Namhyung Kim]

Hi,

On Fri, 22 Feb 2013 15:43:22 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 22, 2013 at 03:28:38PM +0100, Stephane Eranian escreveu:
>> 
>> When the memory sampling sort orders were used on perf.data
>> files without memory sampling data, it would crash perf. This
>> patch fixes this by  handling the lack of memory information
>> gracefully, printing N/A and formatting columns correctly
>> whenever necessary.

It'd be great if we could detect the perf.data contains memory sampling
data and then warn user about it and exit like I did for branch
sampling.  What do you think?

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/16] virtio_ring: virtqueue_add_sgs, to add multiple sgs.

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> On Tue, Feb 19, 2013 at 06:26:20PM +1030, Rusty Russell wrote:
>> virtio_scsi can really use this, to avoid the current hack of copying
>> the whole sg array.  Some other things get slightly neater, too.
>> 
>> Signed-off-by: Rusty Russell 
>
> Hmm, this makes add_buf a bit slower. virtio_test results
> (I'll send a patch to update the test shortly):
>
> Before:
> 0.09user 0.01system 0:00.12elapsed 91%CPU (0avgtext+0avgdata 480maxresident)k
> 0inputs+0outputs (0major+145minor)pagefaults 0swaps
>
> After:
> 0.11user 0.01system 0:00.13elapsed 90%CPU (0avgtext+0avgdata 480maxresident)k
> 0inputs+0outputs (0major+145minor)pagefaults 0swaps

Interesting: how much of this is due to the shim in virtqueue_add_buf()
to clean up the sg arrays?

(Perhaps we should make virtio_test run for longer, too).

BTW, you might be interested in:
https://github.com/rustyrussell/stats.git

Which provides a useful filter for multiple results.

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

[PULL] virtio

[Rusty Russell]

The following changes since commit 226364766f936d249e408de03821468c1bf11dda:

  Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux (2013-01-20 16:44:28 
-0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/virtio-next-for-linus

for you to fetch changes up to 8078db789a92b10ff6e2d713231b5367e014c53b:

  virtio_console: Initialize guest_connected=true for rproc_serial (2013-02-13 
20:57:45 +1030)


All trivial, thanks to the stuff which didn't quite make it time.

Cheers,
Rusty.


Rusty Russell (1):
  virtio: use module_virtio_driver.

Ryota Ozaki (1):
  virtio-mmio: fix wrong comment about register offset

Sjur Brændeland (4):
  virtio_console: Let unconnected rproc device receive data.
  virtio_console: Use virtio device index to generate port name
  virtio: Add module driver macro for virtio drivers.
  virtio_console: Initialize guest_connected=true for rproc_serial

Stephen Hemminger (2):
  virtio: make config_ops const
  virtio: make pci_device_id const

 drivers/char/hw_random/virtio-rng.c|   13 +
 drivers/char/virtio_console.c  |   18 --
 drivers/lguest/lguest_device.c |2 +-
 drivers/net/virtio_net.c   |   12 +---
 drivers/remoteproc/remoteproc_virtio.c |2 +-
 drivers/s390/kvm/kvm_virtio.c  |2 +-
 drivers/virtio/virtio_balloon.c|   13 +
 drivers/virtio/virtio_mmio.c   |4 ++--
 drivers/virtio/virtio_pci.c|8 
 include/linux/virtio.h |   11 ++-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] f2fs: introduce readahead mode of node pages

[Jaegeuk Kim]

Previously, f2fs reads several node pages ahead when get_dnode_of_data is called
with RDONLY_NODE flag.
And, this flag is set by the following functions.
- get_data_block_ro
- get_lock_data_page
- do_write_data_page
- truncate_blocks
- truncate_hole

However, this readahead mechanism is initially introduced for the use of
get_data_block_ro to enhance the sequential read performance.

So, let's clarify all the cases with the additional modes as follows.

enum {
ALLOC_NODE, /* allocate a new node page if needed */
LOOKUP_NODE,/* look up a node without readahead */
LOOKUP_NODE_RA, /*
 * look up a node with readahead called
 * by get_datablock_ro.
 */
}

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 12 ++--
 fs/f2fs/f2fs.h | 12 
 fs/f2fs/file.c |  8 
 fs/f2fs/node.c |  6 +++---
 fs/f2fs/recovery.c |  2 +-
 5 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7bd22a2..277966a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -183,7 +183,7 @@ struct page *find_data_page(struct inode *inode, pgoff_t 
index)
f2fs_put_page(page, 0);
 
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, index, RDONLY_NODE);
+   err = get_dnode_of_data(&dn, index, LOOKUP_NODE);
if (err)
return ERR_PTR(err);
f2fs_put_dnode(&dn);
@@ -222,7 +222,7 @@ struct page *get_lock_data_page(struct inode *inode, 
pgoff_t index)
int err;
 
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, index, RDONLY_NODE);
+   err = get_dnode_of_data(&dn, index, LOOKUP_NODE);
if (err)
return ERR_PTR(err);
f2fs_put_dnode(&dn);
@@ -262,7 +262,7 @@ struct page *get_new_data_page(struct inode *inode, pgoff_t 
index,
int err;
 
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, index, 0);
+   err = get_dnode_of_data(&dn, index, ALLOC_NODE);
if (err)
return ERR_PTR(err);
 
@@ -392,7 +392,7 @@ static int get_data_block_ro(struct inode *inode, sector_t 
iblock,
 
/* When reading holes, we need its node page */
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, pgofs, RDONLY_NODE);
+   err = get_dnode_of_data(&dn, pgofs, LOOKUP_NODE_RA);
if (err)
return (err == -ENOENT) ? 0 : err;
 
@@ -443,7 +443,7 @@ int do_write_data_page(struct page *page)
int err = 0;
 
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, page->index, RDONLY_NODE);
+   err = get_dnode_of_data(&dn, page->index, LOOKUP_NODE);
if (err)
return err;
 
@@ -607,7 +607,7 @@ static int f2fs_write_begin(struct file *file, struct 
address_space *mapping,
mutex_lock_op(sbi, DATA_NEW);
 
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, index, 0);
+   err = get_dnode_of_data(&dn, index, ALLOC_NODE);
if (err) {
mutex_unlock_op(sbi, DATA_NEW);
f2fs_put_page(page, 1);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cc2213a..be7ae70 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -125,11 +125,15 @@ static inline int update_sits_in_cursum(struct 
f2fs_summary_block *rs, int i)
 * file keeping -1 as its node offset to
 * distinguish from index node blocks.
 */
-#define RDONLY_NODE1   /*
-* specify a read-only mode when getting
-* a node block. 0 is read-write mode.
-* used by get_dnode_of_data().
+enum {
+   ALLOC_NODE, /* allocate a new node page if needed */
+   LOOKUP_NODE,/* look up a node without readahead */
+   LOOKUP_NODE_RA, /*
+* look up a node with readahead called
+* by get_datablock_ro.
 */
+};
+
 #define F2FS_LINK_MAX  32000   /* maximum link count per file */
 
 /* for in-memory extent cache entry */
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index b7a053d..d4e29a5 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -43,7 +43,7 @@ static int f2fs_vm_page_mkwrite(struct vm_area_struct *vma,
 
/* block allocation */
set_new_dnode(&dn, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(&dn, page->index, 0);
+   err = get_dnode_of_data(&dn, page->index, ALLOC_NODE);
if (err) {
mutex_unlock_op(sbi, DATA_NEW);
goto out;
@@ -258,7 +258,7 @@

[PATCH 1/2] f2fs: read with READ_SYNC when getting dnode page

[Jaegeuk Kim]

It must be set READ_SYNC not READA.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index e275218..185454f 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -930,7 +930,7 @@ repeat:
if (!page)
return ERR_PTR(-ENOMEM);
 
-   err = read_node_page(page, READA);
+   err = read_node_page(page, READ_SYNC);
if (err) {
f2fs_put_page(page, 1);
return ERR_PTR(err);
-- 
1.8.1.3.566.gaa39828

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI: Add sysfs links from memory device to memblocks

[Yasuaki Ishimatsu]

2013/02/26 6:02, Toshi Kani wrote:
> In order to eject a memory device object represented as "PNP0C80:%d"
> in sysfs, its associated memblocks (system/memory/memory%d) need to
> be off-lined.  However, there is no user friendly way to correlate
> between a memory device object and its memblocks in sysfs.
> 
> This patch creates sysfs links to memblocks under a memory device
> object so that a user can easily checks and manipulates its memblocks
> in sysfs.
> 
> For example, when PNP0C80:05 is associated with memory8 and memory9,
> the following two links are created under PNP0C80:05.  This allows
> a user to access memory8/9 directly from PNP0C80:05.
> 
># ll /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C80:05
>lrwxrwxrwx. memory8 -> ../../../system/memory/memory8
>lrwxrwxrwx. memory9 -> ../../../system/memory/memory9
> 
> Signed-off-by: Toshi Kani 
> ---

I confirmed that the patch has no problem.
Feel free to add:

Tested-by: Yasuaki Ishimatsu 
Acked-by: Yasuaki Ishimatsu 

Thanks,
Yasuaki Ishimatsu

> 
> This patch applies on top of the Rafael's patch below.
> https://patchwork.kernel.org/patch/2153261/
> 
> v2: Added a NULL return check for find_memory_block_hinted() as
> pointed by Yasuaki Ishimatsu.
> 
> ---
>   drivers/acpi/acpi_memhotplug.c |   56 
> 
>   1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 3b3abbc..98477a5 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -28,6 +28,7 @@
>*/
>   
>   #include 
> +#include 
>   #include 
>   
>   #include "internal.h"
> @@ -168,6 +169,55 @@ static int acpi_memory_check_device(struct 
> acpi_memory_device *mem_device)
>   return 0;
>   }
>   
> +static void acpi_setup_mem_blk_links(struct acpi_memory_device *mem_device,
> + struct acpi_memory_info *info, bool add_links)
> +{
> + struct memory_block *mem_blk = NULL;
> + struct mem_section *mem_sect;
> + unsigned long start_pfn, end_pfn, pfn;
> + unsigned long section_nr;
> + int ret;
> +
> + start_pfn = PFN_DOWN(info->start_addr);
> + end_pfn = PFN_UP(info->start_addr + info->length-1);
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + section_nr = pfn_to_section_nr(pfn);
> +
> + if (!present_section_nr(section_nr))
> + continue;
> +
> + mem_sect = __nr_to_section(section_nr);
> +
> + /* skip if the same memblock */
> + if (mem_blk)
> + if ((section_nr >= mem_blk->start_section_nr) &&
> + (section_nr <= mem_blk->end_section_nr))
> + continue;
> +
> + mem_blk = find_memory_block_hinted(mem_sect, mem_blk);
> + if (!mem_blk)
> + continue;
> +
> + if (add_links) {
> + ret = sysfs_create_link_nowarn(
> + &mem_device->device->dev.kobj,
> + &mem_blk->dev.kobj,
> + kobject_name(&mem_blk->dev.kobj));
> + if (ret && ret != -EEXIST)
> + dev_err(&mem_device->device->dev,
> + "Failed to create sysfs link %s\n",
> + kobject_name(&mem_blk->dev.kobj));
> + } else {
> + sysfs_remove_link(&mem_device->device->dev.kobj,
> + kobject_name(&mem_blk->dev.kobj));
> + }
> + }
> +
> + if (mem_blk)
> + kobject_put(&mem_blk->dev.kobj);
> +}
> +
>   static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
>   {
>   int result, num_enabled = 0;
> @@ -207,6 +257,9 @@ static int acpi_memory_enable_device(struct 
> acpi_memory_device *mem_device)
>   continue;
>   }
>   
> + /* Create sysfs links to its mem_blk devices */
> + acpi_setup_mem_blk_links(mem_device, info, true);
> +
>   if (!result)
>   info->enabled = 1;
>   /*
> @@ -241,6 +294,9 @@ static int acpi_memory_remove_memory(struct 
> acpi_memory_device *mem_device)
>   /* The kernel does not use this memory block */
>   continue;
>   
> + /* Remove sysfs links to its mem_blk devices */
> + acpi_setup_mem_blk_links(mem_device, info, false);
> +
>   if (!info->enabled)
>   /*
>* The kernel uses this memory block, but it may be not
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: what's the next LTSI kernel version for long-term support

[Barry Song]

Hi Greg,

2013/2/26 Greg Kroah-Hartman :
> On Tue, Feb 26, 2013 at 11:46:04AM +0800, Barry Song wrote:
>> 2013/2/26 Greg Kroah-Hartman :
>> > On Tue, Feb 26, 2013 at 11:06:56AM +0800, Barry Song wrote:
>> >> Hi Greg/All,
>> >> we have seen 3.4 was announced to be an LTSI in Aug, 2012. I'd like to
>> >> know what is the next LTSI version since we might want to align our
>> >> next release with LTSI.
>> >
>> > Who is "we" here?
>> >
>> people.
>
> I don't take anonymous "we want this" requests serious at all, sorry.
> Please provide details as you are asking me to do work for you, right?
>

i just want to get some generic information not specific to any SoC
vendor at all :-)

> greg k-h

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

[PATCH v3 2/2] kexec: Use min_t to simplify logic

[Zhang Yanfei]

This is just a tweak: using min_t to simplify logic of variable
assignments.

v3:
- cast type of (PAGE_SIZE - (maddr & ~PAGE_MASK)) into size_t.

v2:
- Rewrite patch description as Simon suggested.
- Fix an inappropriate if test introduced by v1. Thanks Simon.

Cc: "Eric W. Biederman" 
Cc: Andrew Morton 
Reviewed-by: Simon Horman 
Signed-off-by: Zhang Yanfei 
---
 kernel/kexec.c |   24 
 1 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 3cbfcc7..b6b16f9 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -822,13 +822,9 @@ static int kimage_load_normal_segment(struct kimage *image,
/* Start with a clear page */
clear_page(ptr);
ptr += maddr & ~PAGE_MASK;
-   mchunk = PAGE_SIZE - (maddr & ~PAGE_MASK);
-   if (mchunk > mbytes)
-   mchunk = mbytes;
-
-   uchunk = mchunk;
-   if (uchunk > ubytes)
-   uchunk = ubytes;
+   mchunk = min_t(size_t, mbytes,
+  (size_t)(PAGE_SIZE - (maddr & ~PAGE_MASK)));
+   uchunk = min_t(size_t, ubytes, mchunk);
 
result = copy_from_user(ptr, buf, uchunk);
kunmap(page);
@@ -874,13 +870,10 @@ static int kimage_load_crash_segment(struct kimage *image,
}
ptr = kmap(page);
ptr += maddr & ~PAGE_MASK;
-   mchunk = PAGE_SIZE - (maddr & ~PAGE_MASK);
-   if (mchunk > mbytes)
-   mchunk = mbytes;
-
-   uchunk = mchunk;
-   if (uchunk > ubytes) {
-   uchunk = ubytes;
+   mchunk = min_t(size_t, mbytes,
+  (size_t)(PAGE_SIZE - (maddr & ~PAGE_MASK)));
+   uchunk = min_t(size_t, ubytes, mchunk);
+   if (mchunk > uchunk) {
/* Zero the trailing part of the page */
memset(ptr + uchunk, 0, mchunk - uchunk);
}
@@ -1461,8 +1454,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
r = vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
 
-   if (r + vmcoreinfo_size > vmcoreinfo_max_size)
-   r = vmcoreinfo_max_size - vmcoreinfo_size;
+   r = min_t(size_t, r, vmcoreinfo_max_size - vmcoreinfo_size);
 
memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
 
-- 
1.7.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: [GIT PULL] ACPI and power management fixes for v3.9-rc1

[Linus Torvalds]

On Mon, Feb 25, 2013 at 7:17 PM, Rafael J. Wysocki  wrote:
>
> I wonder if this went unnoticed or there's anything wrong with it or it just
> needs to wait for some more time?

Just going through things slowly. It's merged in my tree now.

Oh, and a request: _please_ don't use unknown TLA's like OPP. This has
become a huge problem, to the point that we have a
"Documentation/power/opp.txt" file THAT NEVER CLEARLY STATES WHAT THE
F*CK OPP ACTUALLY MEANS! What nice "documentation".

Ok, I can look up things like this and find that it is "Operating
Performance Points". At least in this context. But no, it's not some
kind of generic standard, and no, it's not something people should be
expected to know in general. Please stop doing "explanations" of
things that use TLA's like this. And people shouldn't have to even
wonder.

   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: linux-next: Tree for Feb 24

[Stephen Rothwell]

Hi,

On Tue, 26 Feb 2013 06:00:24 +0100 Sedat Dilek  wrote:
>
> February 26th...

Yeah  :-(

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


pgpBu5C4PhYDA.pgp
Description: PGP signature

Re: [PATCH 5/6][v4]: perf: Create a sysfs entry for Power event format

[Michael Ellerman]

On Tue, Jan 22, 2013 at 10:26:13PM -0800, Sukadev Bhattiprolu wrote:
> 
> [PATCH 5/6][v4]: perf: Create a sysfs entry for Power event format
> 
> Create a sysfs entry, '/sys/bus/event_source/devices/cpu/format/event'
> which describes the format of a POWER cpu.

Did this patch go upstream? I don't see it.

If not, please don't merge it.

> The format of the event is the same for all POWER cpus at least in
> (Power6, Power7), so bulk of this change is common in the code common
> to POWER cpus.

No. The event format is different on most POWER cpus, in particular it
is different on Power6 and Power7, and will be different again on
Power8.

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

[PATCH v3 1/2] kexec: fix wrong types of some local variables

[Zhang Yanfei]

The types of the following local variables:
  - ubytes/mbytes in kimage_load_crash_segment()/kimage_load_normal_segment()
  - r in vmcoreinfo_append_str()
are wrong, so fix them.

Cc: "Eric W. Biederman" 
Cc: Andrew Morton 
Cc: Simon Horman 
Signed-off-by: Zhang Yanfei 
---
 kernel/kexec.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 2436ffc..3cbfcc7 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -789,7 +789,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 struct kexec_segment *segment)
 {
unsigned long maddr;
-   unsigned long ubytes, mbytes;
+   size_t ubytes, mbytes;
int result;
unsigned char __user *buf;
 
@@ -853,7 +853,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 * We do things a page at a time for the sake of kmap.
 */
unsigned long maddr;
-   unsigned long ubytes, mbytes;
+   size_t ubytes, mbytes;
int result;
unsigned char __user *buf;
 
@@ -1455,7 +1455,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 {
va_list args;
char buf[0x50];
-   int r;
+   size_t r;
 
va_start(args, fmt);
r = vsnprintf(buf, sizeof(buf), fmt, args);
-- 
1.7.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] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[Greg KH]

On Tue, Feb 26, 2013 at 12:10:22AM -0500, David Miller wrote:
> From: Greg KH 
> Date: Mon, 25 Feb 2013 21:03:11 -0800
> 
> > On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote:
> >> From: Greg Kroah-Hartman 
> >> Date: Mon, 25 Feb 2013 20:23:43 -0800
> >> 
> >> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
> >> >> This USB ethernet adapter was purchased in anodyne packaging
> >> >> marked "USB2.0 to LAN" from the computer store adjacent to
> >> >> linux.conf.au 2013 in Canberra (Australia). A web search
> >> >> shows other recent purchasers in Lancaster (UK) and Seattle
> >> >> (USA). Just like an emergent virus, our age of e-commerce and
> >> >> airmail allows underdocumented hardware to spread around the
> >> >> world instantly using the vector of ridiculously low prices.
> >> >> 
> >> >> Paige Thompson, infected via eBay, discovered that the HG20F9
> >> >> is a copy of the Asix 88772B; many viruses copy the RNA of
> >> >> other viruses. See Paige's work at
> >> >> .
> >> >> This patch uses her discovery to update the restructured Asix
> >> >> driver in the current kernel.
> >> >> 
> >> >> The spread of viruses is often accompanied by rumours. It is
> >> >> rumoured that the HG20F9 has extensions to to provide gigabit
> >> >> ethernet. This patch does not chase that chimera.
> >> >> 
> >> >> Just as some viruses inhabit seemingly-healthy cells, the
> >> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> >> >> For the present there is no clash of Product ID 0x20f9.
> >> >> 
> >> >> Signed-off-by: Glen Turner 
> >> > 
> >> > That is the best "add a new device id" changelog entry I have _ever_
> >> > seen.  Wonderful job:
> >> > 
> >> > Acked-by: Greg Kroah-Hartman 
> >> 
> >> Was this patch really submitted properly to netdev?  I can't
> >> find it in patchwork at all.
> > 
> > It was Cc: net...@vger.kernel.org with Message-ID:
> > <1361852232.23197.4.ca...@andromache.adelaide.aarnet.edu.au> so it
> > should have gone through there somehow.
> 
> Nope:
> 
> http://marc.info/?t=13618526711&r=1&w=2
> 
> It didn't make it to any of the lists, that's why you are the
> only person who saw the original patch.

Odd, I've now bounced it to the mailing lists, hopefully it gets there
that way.  If not, I can resend it from me directly.

I'll wait till the morning to see if the messages make it through the
lists.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI changes for v3.9

[Linus Torvalds]

On Sat, Feb 23, 2013 at 6:49 PM, Yinghai Lu  wrote:
>
> Please check if attached diff is right, and hope it could save Linus some 
> time.

Hmm. I did things a bit differently, moving things around more in
drivers/acpi/internal.h.

Also, my *gut* feel is that the new _handle_hotplug_event_root()
function should do that whole dance with
acpi_scan_lock_acquire()/acpi_scan_lock_release(), but I didn't really
know if it's required or appropriate, so I left it alone. Could you
take a look?

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/

[PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[Glen Turner]

This USB ethernet adapter was purchased in anodyne packaging
marked "USB2.0 to LAN" from the computer store adjacent to
linux.conf.au 2013 in Canberra (Australia). A web search
shows other recent purchasers in Lancaster (UK) and Seattle
(USA). Just like an emergent virus, our age of e-commerce and
airmail allows underdocumented hardware to spread around the
world instantly using the vector of ridiculously low prices.

Paige Thompson, infected via eBay, discovered that the HG20F9
is a copy of the Asix 88772B; many viruses copy the RNA of
other viruses. See Paige's work at
.
This patch uses her discovery to update the restructured Asix
driver in the current kernel.

The spread of viruses is often accompanied by rumours. It is
rumoured that the HG20F9 has extensions to to provide gigabit
ethernet. This patch does not chase that chimera.

Just as some viruses inhabit seemingly-healthy cells, the
HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
For the present there is no clash of Product ID 0x20f9.

Signed-off-by: Glen Turner 
---
 drivers/net/usb/asix_devices.c |   24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 7a6e758..649025d 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -883,6 +883,24 @@ static const struct driver_info ax88178_info = {
.tx_fixup = asix_tx_fixup,
 };
 
+// USBLINK 20F9 "USB 2.0 LAN" USB ethernet adapter, typically found in
+// no-name packaging.
+// USB device strings are:
+//   1: Manufacturer: USBLINK
+//   2: Product: HG20F9 USB2.0
+//   3: Serial: 03
+// Appears to be compatible with Asix 88772B.
+static const struct driver_info hg20f9_info = {
+   .description = "HG20F9 USB 2.0 Ethernet",
+   .bind = ax88772_bind,
+   .status = asix_status,
+   .link_reset = ax88772_link_reset,
+   .reset = ax88772_reset,
+   .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_LINK_INTR | 
FLAG_MULTI_PACKET,
+   .rx_fixup = asix_rx_fixup,
+   .tx_fixup = asix_tx_fixup,
+};
+
 extern const struct driver_info ax88172a_info;
 
 static const struct usb_device_id  products [] = {
@@ -1022,6 +1040,12 @@ static const struct usb_device_idproducts [] = {
/* ASIX 88172a demo board */
USB_DEVICE(0x0b95, 0x172a),
.driver_info = (unsigned long) &ax88172a_info,
+}, {
+   // USBLINK HG20F9 "USB 2.0 LAN"
+   // Appears to have gazumped Linksys's manufacturer ID but
+   // doesn't (yet) conflict with any known Linksys product.
+   USB_DEVICE(0x066b, 0x20f9),
+   .driver_info = (unsigned long) &hg20f9_info,
 },
{ },// END
 };
-- 
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] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[David Miller]

From: Greg KH 
Date: Mon, 25 Feb 2013 21:03:11 -0800

> On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote:
>> From: Greg Kroah-Hartman 
>> Date: Mon, 25 Feb 2013 20:23:43 -0800
>> 
>> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
>> >> This USB ethernet adapter was purchased in anodyne packaging
>> >> marked "USB2.0 to LAN" from the computer store adjacent to
>> >> linux.conf.au 2013 in Canberra (Australia). A web search
>> >> shows other recent purchasers in Lancaster (UK) and Seattle
>> >> (USA). Just like an emergent virus, our age of e-commerce and
>> >> airmail allows underdocumented hardware to spread around the
>> >> world instantly using the vector of ridiculously low prices.
>> >> 
>> >> Paige Thompson, infected via eBay, discovered that the HG20F9
>> >> is a copy of the Asix 88772B; many viruses copy the RNA of
>> >> other viruses. See Paige's work at
>> >> .
>> >> This patch uses her discovery to update the restructured Asix
>> >> driver in the current kernel.
>> >> 
>> >> The spread of viruses is often accompanied by rumours. It is
>> >> rumoured that the HG20F9 has extensions to to provide gigabit
>> >> ethernet. This patch does not chase that chimera.
>> >> 
>> >> Just as some viruses inhabit seemingly-healthy cells, the
>> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
>> >> For the present there is no clash of Product ID 0x20f9.
>> >> 
>> >> Signed-off-by: Glen Turner 
>> > 
>> > That is the best "add a new device id" changelog entry I have _ever_
>> > seen.  Wonderful job:
>> > 
>> > Acked-by: Greg Kroah-Hartman 
>> 
>> Was this patch really submitted properly to netdev?  I can't
>> find it in patchwork at all.
> 
> It was Cc: net...@vger.kernel.org with Message-ID:
> <1361852232.23197.4.ca...@andromache.adelaide.aarnet.edu.au> so it
> should have gone through there somehow.

Nope:

http://marc.info/?t=13618526711&r=1&w=2

It didn't make it to any of the lists, that's why you are the
only person who saw the original patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation and source code comments updates (v1)

[Rob Landley]

On 02/25/2013 02:54:07 PM, Konrad Rzeszutek Wilk wrote:

Hey,

Three little patches to update the Documentation/kernel-parameters and
also some of the complex x86 trampoline code.

Nothing serious, just a little cleanup.


Did I miss an attachment?

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

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[Greg KH]

On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote:
> From: Greg Kroah-Hartman 
> Date: Mon, 25 Feb 2013 20:23:43 -0800
> 
> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
> >> This USB ethernet adapter was purchased in anodyne packaging
> >> marked "USB2.0 to LAN" from the computer store adjacent to
> >> linux.conf.au 2013 in Canberra (Australia). A web search
> >> shows other recent purchasers in Lancaster (UK) and Seattle
> >> (USA). Just like an emergent virus, our age of e-commerce and
> >> airmail allows underdocumented hardware to spread around the
> >> world instantly using the vector of ridiculously low prices.
> >> 
> >> Paige Thompson, infected via eBay, discovered that the HG20F9
> >> is a copy of the Asix 88772B; many viruses copy the RNA of
> >> other viruses. See Paige's work at
> >> .
> >> This patch uses her discovery to update the restructured Asix
> >> driver in the current kernel.
> >> 
> >> The spread of viruses is often accompanied by rumours. It is
> >> rumoured that the HG20F9 has extensions to to provide gigabit
> >> ethernet. This patch does not chase that chimera.
> >> 
> >> Just as some viruses inhabit seemingly-healthy cells, the
> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> >> For the present there is no clash of Product ID 0x20f9.
> >> 
> >> Signed-off-by: Glen Turner 
> > 
> > That is the best "add a new device id" changelog entry I have _ever_
> > seen.  Wonderful job:
> > 
> > Acked-by: Greg Kroah-Hartman 
> 
> Was this patch really submitted properly to netdev?  I can't
> find it in patchwork at all.

It was Cc: net...@vger.kernel.org with Message-ID:
<1361852232.23197.4.ca...@andromache.adelaide.aarnet.edu.au> so it
should have gone through there somehow.

thanks,

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

[PATCH 2/2] perf report: Fix build with NO_NEWT=1

[Michael Ellerman]

Commit ad0de09 "Enable the runtime switching of perf data file" broke
the build with NO_NEWT=1:

CC builtin-report.o
builtin-report.c: In function '__cmd_report':
builtin-report.c:479:15: error: 'K_SWITCH_INPUT_DATA' undeclared (first use in 
this function)
builtin-report.c:479:15: note: each undeclared identifier is reported only once 
for each function it appears in
builtin-report.c: In function 'cmd_report':
builtin-report.c:823:13: error: 'K_SWITCH_INPUT_DATA' undeclared (first use in 
this function)
make: *** [builtin-report.o] Error 1

Fix it by adding a dummy definition of K_SWITCH_INPUT_DATA.

Signed-off-by: Michael Ellerman 
---
 tools/perf/util/hist.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 609a115..226a4ae 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -210,6 +210,7 @@ static inline int script_browse(const char *script_opt 
__maybe_unused)
 
 #define K_LEFT  -1000
 #define K_RIGHT -2000
+#define K_SWITCH_INPUT_DATA -3000
 #endif
 
 #ifdef GTK2_SUPPORT
-- 
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/

[PATCH 1/2] perf annotate: Fix build with NO_NEWT=1

[Michael Ellerman]

Commit 18c9e5c "Make it to be able to skip unannotatable symbols" broke
the build with NO_NEWT=1:

   CC builtin-annotate.o
builtin-annotate.c: In function 'hists__find_annotations':
builtin-annotate.c:161:4: error: duplicate case value
builtin-annotate.c:154:4: error: previously used here
make: *** [builtin-annotate.o] Error 1

This is because without NEWT support K_LEFT is #defined to -1 in
utils/hist.h

Fix it by shifting the K_LEFT/K_RIGHT #defines out of the likely range
of error values.

Signed-off-by: Michael Ellerman 
---
 tools/perf/util/hist.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 3862468..609a115 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -208,8 +208,8 @@ static inline int script_browse(const char *script_opt 
__maybe_unused)
return 0;
 }
 
-#define K_LEFT -1
-#define K_RIGHT -2
+#define K_LEFT  -1000
+#define K_RIGHT -2000
 #endif
 
 #ifdef GTK2_SUPPORT
-- 
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/

[PATCH repost] blkcg: fix "scheduling while atomic" in blk_queue_bypass_start

[Jun'ichi Nomura]

Hello Jens,

please consider to pick up this patch.
Without this patch, the warning below splats every when a multipath
device is created.
I got acks from Vivek and Tejun when I posted this for v3.7
and this same patch is still applicable to v3.8.


Since 749fefe677 in v3.7 ("block: lift the initial queue bypass mode
on blk_register_queue() instead of blk_init_allocated_queue()"),
the following warning appears when multipath is used with CONFIG_PREEMPT=y.

This patch moves blk_queue_bypass_start() before radix_tree_preload()
to avoid the sleeping call while preemption is disabled.

  BUG: scheduling while atomic: multipath/2460/0x0002
  1 lock held by multipath/2460:
   #0:  (&md->type_lock){..}, at: [] 
dm_lock_md_type+0x17/0x19 [dm_mod]
  Modules linked in: ...
  Pid: 2460, comm: multipath Tainted: GW3.7.0-rc2 #1
  Call Trace:
   [] __schedule_bug+0x6a/0x78
   [] __schedule+0xb4/0x5e0
   [] schedule+0x64/0x66
   [] schedule_timeout+0x39/0xf8
   [] ? put_lock_stats+0xe/0x29
   [] ? lock_release_holdtime+0xb6/0xbb
   [] wait_for_common+0x9d/0xee
   [] ? try_to_wake_up+0x206/0x206
   [] ? kfree_call_rcu+0x1c/0x1c
   [] wait_for_completion+0x1d/0x1f
   [] wait_rcu_gp+0x5d/0x7a
   [] ? wait_rcu_gp+0x7a/0x7a
   [] ? complete+0x21/0x53
   [] synchronize_rcu+0x1e/0x20
   [] blk_queue_bypass_start+0x5d/0x62
   [] blkcg_activate_policy+0x73/0x270
   [] ? kmem_cache_alloc_node_trace+0xc7/0x108
   [] cfq_init_queue+0x80/0x28e
   [] ? dm_blk_ioctl+0xa7/0xa7 [dm_mod]
   [] elevator_init+0xe1/0x115
   [] ? blk_queue_make_request+0x54/0x59
   [] blk_init_allocated_queue+0x8c/0x9e
   [] dm_setup_md_queue+0x36/0xaa [dm_mod]
   [] table_load+0x1bd/0x2c8 [dm_mod]
   [] ctl_ioctl+0x1d6/0x236 [dm_mod]
   [] ? table_clear+0xaa/0xaa [dm_mod]
   [] dm_ctl_ioctl+0x13/0x17 [dm_mod]
   [] do_vfs_ioctl+0x3fb/0x441
   [] ? file_has_perm+0x8a/0x99
   [] sys_ioctl+0x5e/0x82
   [] ? trace_hardirqs_on_thunk+0x3a/0x3f
   [] system_call_fastpath+0x16/0x1b

Signed-off-by: Jun'ichi Nomura 
Acked-by: Vivek Goyal 
Acked-by: Tejun Heo 
Cc: Jens Axboe 
Cc: Alasdair G Kergon 
---
 block/blk-cgroup.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index b8858fb..53628e4 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -790,10 +790,10 @@ int blkcg_activate_policy(struct request_queue *q,
if (!blkg)
return -ENOMEM;
 
-   preloaded = !radix_tree_preload(GFP_KERNEL);
-
blk_queue_bypass_start(q);
 
+   preloaded = !radix_tree_preload(GFP_KERNEL);
+
/* make sure the root blkg exists and count the existing blkgs */
spin_lock_irq(q->queue_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Feb 24

[Sedat Dilek]

February 26th...

- Sedat -

On Tue, Feb 26, 2013 at 4:16 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Please do not add any work destined for v3.10 to your -next included
> branches until after Linus has release v3.9-rc1.
>
> Changes since 20130223:
>
> The kbuild tree lost its build failure.
>
> The infiniband tree gained a conflict against Linus' tree.
>
> The drm tree still has its build failure for which I applied a patch.
>
> 
>
> 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 216 trees (counting Linus' and 28 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 (ab78265 Merge tag 'mfd-3.9-1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)
> Merging fixes/master (d287b87 Merge branch 'for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
> Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' 
> of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
> Merging arm-current/fixes (b255188 ARM: fix scheduling while atomic warning 
> in alignment handling code)
> Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. 
> CONFIG_HAS_DMA)
> Merging powerpc-merge/merge (eda8eeb powerpc/mm: Fix hash computation 
> function)
> Merging sparc/master (f9fd348 sparc32: refactor smp boot)
> Merging net/master (eb970ff usbnet: smsc95xx: rename FEATURE_AUTOSUSPEND)
> Merging ipsec/master (85dfb74 af_key: initialize satype in 
> key_notify_policy_flush())
> Merging sound-current/for-linus (d0ec95f ALSA: emu10k1: Allow to switch 
> hardware sampe rate on EMU)
> Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when 
> removing a device)
> Merging wireless/master (dc4a787 brcmfmac: fix missing unlock on error in 
> brcmf_notify_vif_event())
> Merging driver-core.current/driver-core-linus (949db15 Linux 3.8-rc5)
> Merging tty.current/tty-linus (8b5628a Merge tag 'virt' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
> Merging usb.current/usb-linus (74e1a2a Merge tag 'usb-3.9-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
> Merging staging.current/staging-linus (8b5628a Merge tag 'virt' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
> Merging char-misc.current/char-misc-linus (7ed214a Merge tag 
> 'char-misc-3.9-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc)
> Merging input-current/for-linus (171fb58 Input: ALPS - update documentation 
> for recent touchpad driver mods)
> Merging md-current/for-linus (c43a660 md/raid1,raid10: fix deadlock with 
> freeze_array())
> Merging audit-current/for-linus (c158a35 audit: no leading space in 
> audit_log_d_path prefix)
> Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied 
> strings are nul-terminated)
> CONFLICT (content): Merge conflict in drivers/crypto/omap-sham.c
> CONFLICT (content): Merge conflict in crypto/ctr.c
> CONFLICT (content): Merge conflict in 
> Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
> Merging dwm

Re: [PATCH] perf, x86: add Intel IvyBridge event scheduling constraints

[yqzhang]

Hi Stephane,

I was wondering what the differences are between
CYCLE_ACTIVITY.CYCLES_**_PENDING and CYCLE_ACTIVITY.STALLS_**_PENDING,
because I could only find following events in the SDM, which seem to be
different from the ones provided here. Correct me if I'm wrong.

A3H 01H CYCLE_ACTIVITY.CYCLES_L2_PENDING
  - Cycles with pending L2 miss loads. Set Cmask=2 tocount cycle. Use only
when HTT is off
A3H 02H CYCLE_ACTIVITY.CYCLES_LDM_PENDING
  - Cycles with pending memory loads. Set Cmask=2 to count cycle.
A3H 05H CYCLE_ACTIVITY.STALLS_L2_PENDING
  - Number of loads missed L2. Use only when HTT is off
A3H 08H CYCLE_ACTIVITY.CYCLES_L1D_PENDING
  - Cycles with pending L1 cache miss loads. SetCmask=8 to count cycle.PMC2
only

Thanks a lot!



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/PATCH-perf-x86-add-Intel-IvyBridge-event-scheduling-constraints-tp604032p606450.html
Sent from the Linux Kernel mailing list archive at Nabble.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: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 08:43:59PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett  wrote:
> >
> > If the user has explicitly enrolled a hash then they're stepping outside
> > the trust model.
> 
> This is the kind of totally bogus crap that no sane person should ever
> spout. Stop it.
> 
> If the user has explicitly enrolled a hash, then that should be the
> *primary* trust model, dammit. That should be very much what you
> should care about first and foremost, and that should be your goal in
> life. That's when the user says "I'm in control of my own machine, and
> I want to trust *this*".

The user has stepped outside the original trust model ("I trust anything 
signed by Microsoft and only things signed by Microsoft") and into a new 
one ("I trust things that I say I trust"). That's a great thing for a 
user to do, but it also means that once the user's done it we don't need 
to give a fuck about what Microsoft think. They're irrelevant once the 
user's made that choice.

> It's not about "stepping outside of the trust model". Quite the
> reverse. It's about actually being *part* of the trust model, and
> taking control of your own machine. It's the *good* scenario. It's
> what you should encourage users to do.

I wholeheartedly agree.

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

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 08:31:08PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett  wrote:
> >
> > Our users want to be able to boot Linux. If Microsoft blacklist a
> > distribution's bootloader, that user isn't going to be able to boot
> > Linux any more. How does that benefit our users?
> 
> How does bringing up an unlikely and bogus scenario - and when people
> call you on it, just double down on it - help users?

What's unlikely or bogus about it? There's incentive to breach the 
Secure Boot trust model, and to do that you need signed code that'll run 
unsigned code in ring 0. Why would the black hats bother finding more 
subtle exploits if they can just write a new kexec loader?

>  - a distro should sign its own modules AND NOTHING ELSE by default.
> And it damn well shouldn't allow any other modules to be loaded at all
> by default, because why the f*ck should it? And what the hell should a
> microsoft signature have to do with *anything*?

So far? Nothing.

>  - before loading any third-party module, you'd better make sure you
> ask the user for permission. On the console. Not using keys. Nothing
> like that. Keys will be compromised. Try to limit the damage, but more
> importantly, let the user be in control.

So some sort of blocking insmod that waits for a sysrq input? I spent 
some time thinking about that, but then there's people who want 
automated installs on systems with bizarre storage hardware that depends 
on out of tree drivers. Like I said, *I'm* absolutely fine with not 
supporting out of tree drivers at all.

>  - encourage things like per-host random keys - with the stupid UEFI
> checks disabled entirely if required. They are almost certainly going
> to be *more* secure than depending on some crazy root of trust based
> on a big company, with key signing authorities that trust anybody with
> a credit card. Try to teach people about things like that instead.
> Encourage people to do their own (random) keys, and adding those to
> their UEFI setups (or not: the whole UEFI thing is more about control
> than security), and strive to do things like one-time signing with the
> private key thrown out entirely. IOW try to encourage *that* kind of
> "we made sure to ask the user very explicitly with big warnings and
> create his own key for that particular module" security. Real
> security, not "we control the user" security.

Yes, ideally people will engage in self-signing and distributions will 
have mechanisms for dealing with that.

> Sure, users will screw that up too. They'll want to load crazy nvidia
> binary modules etc crap. But make it *their* decision, and under
> *their* control, instead of trying to tell the world about how this
> should be blessed by Microsoft.

We can block third party modules by default, but they'll still be 
trusting Microsoft by default.

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

Re: [GIT PULL] Load keys from signed PE binaries

[Dave Airlie]

On Tue, Feb 26, 2013 at 2:45 PM, Theodore Ts'o  wrote:
> On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
>>
>> Its a simple argument, MS can revoke our keys for whatever reason,
>> reducing the surface area of reasons for them to do so seems like a
>> good idea. Unless someone can read the mind of the MS guy that
>> arbitrarily decides this in 5 years time, or has some sort of signed
>> agreement, I tend towards protecting the users from having their Linux
>> not work anymore, because we were scared of a PE loader in the kernel.
>
> If Microsoft will revoke keys for whatever reason they want, without
> any regard to the potential PR and legal consequences to Microsoft,
> there's absolutely **nothing** you can do, short of choosing to use
> more open hardware (for example, like the Chromebook Pixel).
>
> If you're that terrified of the completely arbitrary and capricious
> Microsoft guy having us by the short hairs, why aid and abet Microsoft
> control-freak model?
>

No what I said if you read it, was nobody knows, you don't, Greg
doesn't, Matthew doesn't.

That's the problem you are all arguing like you know shit that none of you know.

So you all have opinions on what Microsoft would do if faced with the
compromise Matthew reports, and really if you think MS are going to
leave a secureboot bypass via Linux live, then you wonder why they are
expending all this money on secureboot at all, since the first person
to write a Linux based exploit is safe because of a PR backlash? At
this point we'd be best served by writing the PoC exploit I suppose
and then seeing what MS do up front!

So it would be nice if LF could undertake to go and talk to Microsoft,
and get vague opinions turned into something real.

Ted you might be at liberty to get a chromebook pixel from google, but
that isn't going to help the other X% of users who have a PC they want
to use Linux on, and maybe boot Windows to do their taxes.

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: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

[Martin Bligh]

> Do you mean we can remove numaq x86 32bit code now?

Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
Was useful in the early days of getting NUMA up and running on Linux,
but is now too old to be a museum piece, really.

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/

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
> >>
> >> Right. We've failed at creating an alternative. That doesn't mean that
> >> we get to skip the responsibilities associated with the choice we've
> >> made.
> >
> > Wait, who is "we" here?  The community?  The community over-all didn't
> > agree with anything with Microsoft, that is between the people getting a
> > signed key and Microsoft.  Again, you are trying to push your (prior)
> > company's agreement between them and Microsoft onto the community, and
> > now the community is pushing back, is that a surprise?
> 
> Do you not work for the LF?, Matthew doesn't work for RH, so please
> leave the petty my employer said this, and he's better than your
> employer and try and stick to technical details.

No, sorry, I'm not trying to say that at all (and my LF employment
agreement is quite weird, I don't speak for them at all, and they can't
tell me what to do, and everyone is happy.)

I am trying to say that the "we" here is NOT the community.  The
community does not have any "responsibility" to Microsoft or any
corporate.  Our only responsibility is to our users, as Linus stated.

thanks,

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

Re: [PATCH v2] kexec: Use min_t to simplify logic

[Zhang Yanfei]

于 2013年02月26日 07:35, Andrew Morton 写道:
> On Mon, 25 Feb 2013 09:36:51 +0900
> Simon Horman  wrote:
> 
>> On Sun, Feb 24, 2013 at 10:37:21PM +0800, Zhang Yanfei wrote:
>>> From: Zhang Yanfei 
>>>
>>> This is just a tweak: using min_t to simplify logic of variable
>>> assignments.
>>>
>>> v2:
>>> - Rewrite patch description as Simon suggested.
>>> - Fix an inappropriate if test introduced by v1. Thanks Simon.
>>
>> Hi Zhang,
>>
>> thanks for the update.
>>
>> Signed-off-by: Simon Horman 
> 
> Signed-off-by: implies that you were involved in the development or
> patch delivery.  Were you?  If not, an Acked-by or Reviewed-by is more
> appropriate.
> 
> Also, the need to use min_t rather than min is a sign that the types
> are screwed up.  Let's take a look.
> 
>>>
>>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>>> index 2436ffc..effd655 100644
>>> --- a/kernel/kexec.c
>>> +++ b/kernel/kexec.c
>>> @@ -822,13 +822,8 @@ static int kimage_load_normal_segment(struct kimage 
>>> *image,
>>> /* Start with a clear page */
>>> clear_page(ptr);
>>> ptr += maddr & ~PAGE_MASK;
>>> -   mchunk = PAGE_SIZE - (maddr & ~PAGE_MASK);
>>> -   if (mchunk > mbytes)
>>> -   mchunk = mbytes;
>>> -
>>> -   uchunk = mchunk;
>>> -   if (uchunk > ubytes)
>>> -   uchunk = ubytes;
>>> +   mchunk = min_t(size_t, mbytes, PAGE_SIZE - (maddr & 
>>> ~PAGE_MASK));
>>> +   uchunk = min_t(size_t, ubytes, mchunk);
> 
> The types of ubytes and mbytes are clearly wrong.  They are initialised
> from a size_t and they are manipulated alongside size_t's.

Ah, yes. I didn't realize this before.

> 
> The types of PAGE_SIZE and PAGE_MASK are vague - iirc they once had
> different types on different architectures, so some form of casting is
> unavoidable here.

Yes.

> 
>>> result = copy_from_user(ptr, buf, uchunk);
>>> kunmap(page);
>>> @@ -874,13 +869,9 @@ static int kimage_load_crash_segment(struct kimage 
>>> *image,
>>> }
>>> ptr = kmap(page);
>>> ptr += maddr & ~PAGE_MASK;
>>> -   mchunk = PAGE_SIZE - (maddr & ~PAGE_MASK);
>>> -   if (mchunk > mbytes)
>>> -   mchunk = mbytes;
>>> -
>>> -   uchunk = mchunk;
>>> -   if (uchunk > ubytes) {
>>> -   uchunk = ubytes;
>>> +   mchunk = min_t(size_t, mbytes, PAGE_SIZE - (maddr & 
>>> ~PAGE_MASK));
>>> +   uchunk = min_t(size_t, ubytes, mchunk);
>>> +   if (mchunk > uchunk) {
>>> /* Zero the trailing part of the page */
>>> memset(ptr + uchunk, 0, mchunk - uchunk);
>>> }
> 
> Again, mybtes and ubytes have the wrong type.
> 
>>> @@ -1461,8 +1452,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>>> r = vsnprintf(buf, sizeof(buf), fmt, args);
>>> va_end(args);
>>>  
>>> -   if (r + vmcoreinfo_size > vmcoreinfo_max_size)
>>> -   r = vmcoreinfo_max_size - vmcoreinfo_size;
>>> +   r = min_t(size_t, r, vmcoreinfo_max_size - vmcoreinfo_size);
>>>  
>>> memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
> 
> vmcoreinfo_max_size is a size_t and vmcoreinfo_size is a size_t and
> memcpy's `size' argument is a size_t.  Therefore the type of `r' should
> be...  what?  int!  bt.

yes.

So I will split the patch into two, first fix the wrong types here. Then
use min_t to simply the logic.

Thanks
Zhang

> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

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

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[David Miller]

From: Greg Kroah-Hartman 
Date: Mon, 25 Feb 2013 20:23:43 -0800

> On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
>> This USB ethernet adapter was purchased in anodyne packaging
>> marked "USB2.0 to LAN" from the computer store adjacent to
>> linux.conf.au 2013 in Canberra (Australia). A web search
>> shows other recent purchasers in Lancaster (UK) and Seattle
>> (USA). Just like an emergent virus, our age of e-commerce and
>> airmail allows underdocumented hardware to spread around the
>> world instantly using the vector of ridiculously low prices.
>> 
>> Paige Thompson, infected via eBay, discovered that the HG20F9
>> is a copy of the Asix 88772B; many viruses copy the RNA of
>> other viruses. See Paige's work at
>> .
>> This patch uses her discovery to update the restructured Asix
>> driver in the current kernel.
>> 
>> The spread of viruses is often accompanied by rumours. It is
>> rumoured that the HG20F9 has extensions to to provide gigabit
>> ethernet. This patch does not chase that chimera.
>> 
>> Just as some viruses inhabit seemingly-healthy cells, the
>> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
>> For the present there is no clash of Product ID 0x20f9.
>> 
>> Signed-off-by: Glen Turner 
> 
> That is the best "add a new device id" changelog entry I have _ever_
> seen.  Wonderful job:
> 
> Acked-by: Greg Kroah-Hartman 

Was this patch really submitted properly to netdev?  I can't
find it in patchwork at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
> 
> Its a simple argument, MS can revoke our keys for whatever reason,
> reducing the surface area of reasons for them to do so seems like a
> good idea. Unless someone can read the mind of the MS guy that
> arbitrarily decides this in 5 years time, or has some sort of signed
> agreement, I tend towards protecting the users from having their Linux
> not work anymore, because we were scared of a PE loader in the kernel.

If Microsoft will revoke keys for whatever reason they want, without
any regard to the potential PR and legal consequences to Microsoft,
there's absolutely **nothing** you can do, short of choosing to use
more open hardware (for example, like the Chromebook Pixel).

If you're that terrified of the completely arbitrary and capricious
Microsoft guy having us by the short hairs, why aid and abet Microsoft
control-freak model?

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett  wrote:
>
> If the user has explicitly enrolled a hash then they're stepping outside
> the trust model.

This is the kind of totally bogus crap that no sane person should ever
spout. Stop it.

If the user has explicitly enrolled a hash, then that should be the
*primary* trust model, dammit. That should be very much what you
should care about first and foremost, and that should be your goal in
life. That's when the user says "I'm in control of my own machine, and
I want to trust *this*".

It's not about "stepping outside of the trust model". Quite the
reverse. It's about actually being *part* of the trust model, and
taking control of your own machine. It's the *good* scenario. It's
what you should encourage users to do.

No, it likely can't be the default because we shouldn't expect users
to care enough, but on the other hand the default should definitely
*not* be "enable random third party modules signed indirectly by MS",
which is what your crazy world-view seems to be.

So the first order should be: "we provide modules to cover all normal
users". You use the RH key for that.

The *second* order should be: "we encourage and tell people how to add
their own keys and sign modules they trust".

The third order should probably be "we encourage people to use random
one-time keys - probably with UEFI key checking turned off entirely,
because let's face it, that doesn't really add any real security for
most people". It's what kernel developers and most servers would
probably want to use. They likely don't do the whole UEFI crap anyway,
and random one-time keys are actually better against things like
rootkits etc than *any* centrally administered chain of trust.

Only somewhere really really deep down should the "ok, what about a MS
signature" thing be. It could be part of the user-level application
(part of your distribution) that displays the "are you really sure you
want to load this module with an unrecognized signature? I can tell
that it has a MS signature on it". But by the time you get this far,
you've already failed the first few normal levels.

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: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett  wrote:
>
> Our users want to be able to boot Linux. If Microsoft blacklist a
> distribution's bootloader, that user isn't going to be able to boot
> Linux any more. How does that benefit our users?

How does bringing up an unlikely and bogus scenario - and when people
call you on it, just double down on it - help users?

Stop the fear mongering already.

So here's what I would suggest, and it is based on REAL SECURITY and
on PUTTING THE USER FIRST instead of your continual "let's please
microsoft by doing idiotic crap" approach.

So instead of pleasing microsoft, try to see how we can add real security:

 - a distro should sign its own modules AND NOTHING ELSE by default.
And it damn well shouldn't allow any other modules to be loaded at all
by default, because why the f*ck should it? And what the hell should a
microsoft signature have to do with *anything*?

 - before loading any third-party module, you'd better make sure you
ask the user for permission. On the console. Not using keys. Nothing
like that. Keys will be compromised. Try to limit the damage, but more
importantly, let the user be in control.

 - encourage things like per-host random keys - with the stupid UEFI
checks disabled entirely if required. They are almost certainly going
to be *more* secure than depending on some crazy root of trust based
on a big company, with key signing authorities that trust anybody with
a credit card. Try to teach people about things like that instead.
Encourage people to do their own (random) keys, and adding those to
their UEFI setups (or not: the whole UEFI thing is more about control
than security), and strive to do things like one-time signing with the
private key thrown out entirely. IOW try to encourage *that* kind of
"we made sure to ask the user very explicitly with big warnings and
create his own key for that particular module" security. Real
security, not "we control the user" security.

Sure, users will screw that up too. They'll want to load crazy nvidia
binary modules etc crap. But make it *their* decision, and under
*their* control, instead of trying to tell the world about how this
should be blessed by Microsoft.

Because it really shouldn't be about MS blessings, it should be about
the *user* blessing kernel modules.

Quite frankly, *you* are what he key-hating crazies were afraid of.
You peddle the "control, not security" crap-ware. The whole "MS owns
your machine" is *exactly* the wrong way to use keys.

 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: [GIT PULL] Load keys from signed PE binaries

[Dave Airlie]

>>
>> Right. We've failed at creating an alternative. That doesn't mean that
>> we get to skip the responsibilities associated with the choice we've
>> made.
>
> Wait, who is "we" here?  The community?  The community over-all didn't
> agree with anything with Microsoft, that is between the people getting a
> signed key and Microsoft.  Again, you are trying to push your (prior)
> company's agreement between them and Microsoft onto the community, and
> now the community is pushing back, is that a surprise?

Do you not work for the LF?, Matthew doesn't work for RH, so please
leave the petty my employer said this, and he's better than your
employer and try and stick to technical details.

Maybe the LF can do something useful and get MS to sign an agreement
saying we don't require any of this extra security stuff and that if
Linux is used to root Windows Secureboot platforms, they won't revoke
the key for our bootloaders. Until then you aren't providing anything
more technical than FUD.

Its a simple argument, MS can revoke our keys for whatever reason,
reducing the surface area of reasons for them to do so seems like a
good idea. Unless someone can read the mind of the MS guy that
arbitrarily decides this in 5 years time, or has some sort of signed
agreement, I tend towards protecting the users from having their Linux
not work anymore, because we were scared of a PE loader in the kernel.

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] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 08:13:24PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 04:04:56AM +, Matthew Garrett wrote:
> > There's no reason for the LF or generic shim to be blacklisted, since 
> > neither will load anything without manual intervention. But that also 
> > means that anyone trying to boot them has to have some knowledge of 
> > English, and that there's no way to netboot them. But sure, anyone 
> > planning that approach has much less to worry about.
> 
> I don't see anything about "manual intervention" in the wording that you
> provided from Microsoft absolving you from the "duty" you feel you owe
> them.  I understand you are worried about "automated" exploits, but that
> really is just a semantic overall, as we know it is easy to get people
> to hit a key when booting just to get on with the process.

If the user has explicitly enrolled a hash then they're stepping outside 
the trust model. That's why the LF loader shows dire warnings, and why 
shim has deliberately awkward UI. Perhaps we'll have made an incorrect 
judgement and it'll turn out that users can still be manipulated into 
being exploited this way, and in that case we'll have to reappraise some 
of those choices. But given that the barrier there is similar to the 
barrier involved in just telling users to disable Secure Boot entirely, 
I don't think it's terribly likely.

> > > Yes you can.  There are all sorts of fun ways you can do this, I can
> > > think of a few more at the moment as well.  So, where does it stop?
> > > And why stop it at all?  Why not just forbid root users at all?
> > 
> > Because there's a distinction between ring 0 and ring 3?
> 
> Since when did you start trusting ring 0 code?  Bozos like me write this
> stuff, surely it isn't secure :)

The fact that we bother with CVEs seems to suggest that we at least 
aspire to it...

> > Right. We've failed at creating an alternative. That doesn't mean that 
> > we get to skip the responsibilities associated with the choice we've 
> > made.
> 
> Wait, who is "we" here?  The community?  The community over-all didn't
> agree with anything with Microsoft, that is between the people getting a
> signed key and Microsoft.  Again, you are trying to push your (prior)
> company's agreement between them and Microsoft onto the community, and
> now the community is pushing back, is that a surprise?

The community's not obliged to take the patches, and I'm sure Red Hat 
and any other vendors who care can carry them themselves. But it'd be 
nice to avoid even more divergence between upstream and the 
distributions, wouldn't it?

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

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[Greg Kroah-Hartman]

On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
> This USB ethernet adapter was purchased in anodyne packaging
> marked "USB2.0 to LAN" from the computer store adjacent to
> linux.conf.au 2013 in Canberra (Australia). A web search
> shows other recent purchasers in Lancaster (UK) and Seattle
> (USA). Just like an emergent virus, our age of e-commerce and
> airmail allows underdocumented hardware to spread around the
> world instantly using the vector of ridiculously low prices.
> 
> Paige Thompson, infected via eBay, discovered that the HG20F9
> is a copy of the Asix 88772B; many viruses copy the RNA of
> other viruses. See Paige's work at
> .
> This patch uses her discovery to update the restructured Asix
> driver in the current kernel.
> 
> The spread of viruses is often accompanied by rumours. It is
> rumoured that the HG20F9 has extensions to to provide gigabit
> ethernet. This patch does not chase that chimera.
> 
> Just as some viruses inhabit seemingly-healthy cells, the
> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> For the present there is no clash of Product ID 0x20f9.
> 
> Signed-off-by: Glen Turner 

That is the best "add a new device id" changelog entry I have _ever_
seen.  Wonderful job:

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

[Yinghai Lu]

On Mon, Feb 25, 2013 at 7:21 PM, Martin Bligh  wrote:
 4, it does not CC to TJ and other numa guys...
>>>
>>> attached workaround the problem for now.
>>> but it will assume NUMAQ would not have SRAT table.
>>
>>  Martin, can you confirm that numaq does not have srat?
>
> No, it's pre-SRAT. I forget the exact name of the table, but no SRAT until 
> x440.
>
> OTOH, you should probably feel free to break it by now, I can't
> imagine they are any use to man nor beast any more.

Do you mean we can remove numaq x86 32bit code now?

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] perf: add dwarf regs map for mips

[liguang]

Signed-off-by: liguang 
---
 tools/perf/arch/mips/Makefile  |4 +++
 tools/perf/arch/mips/util/dwarf-regs.c |   33 
 2 files changed, 37 insertions(+), 0 deletions(-)
 create mode 100644 tools/perf/arch/mips/Makefile
 create mode 100644 tools/perf/arch/mips/util/dwarf-regs.c

diff --git a/tools/perf/arch/mips/Makefile b/tools/perf/arch/mips/Makefile
new file mode 100644
index 000..15130b5
--- /dev/null
+++ b/tools/perf/arch/mips/Makefile
@@ -0,0 +1,4 @@
+ifndef NO_DWARF
+PERF_HAVE_DWARF_REGS := 1
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
+endif
diff --git a/tools/perf/arch/mips/util/dwarf-regs.c 
b/tools/perf/arch/mips/util/dwarf-regs.c
new file mode 100644
index 000..4871489
--- /dev/null
+++ b/tools/perf/arch/mips/util/dwarf-regs.c
@@ -0,0 +1,33 @@
+/*
+ * Mapping of DWARF debug register numbers into register names.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+#define MIPS_MAX_REGS  32
+
+const char *mips_regs_table[MIPS_MAX_REGS] = {
+   "zero", "at", "v0", "v1", "a0", "a1", "a2", "a3",
+   "t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7",
+   "s0", "s1", "s2", "s3", "s4", "s5", "s6", "s7",
+   "t8", "t9", "k0", "k1", "gp", "sp", "fp", "ra",
+};
+
+/**
+ * get_arch_regstr() - lookup register name from it's DWARF register number
+ * @n: the DWARF register number
+ *
+ * get_arch_regstr() returns the name of the register in struct
+ * regdwarfnum_table from it's DWARF register number. If the register is not
+ * found in the table, this returns NULL;
+ */
+const char *get_arch_regstr(unsigned int n)
+{
+   return (n <= MIPS_MAX_REGS) ? mips_regs_table[n] : NULL;
+}
-- 
1.7.2.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 1/3] perf: sort command-list.txt by alphabet order

[liguang]

Signed-off-by: liguang 
---
 tools/perf/command-list.txt |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/perf/command-list.txt b/tools/perf/command-list.txt
index 3e86bbd..a28e31b 100644
--- a/tools/perf/command-list.txt
+++ b/tools/perf/command-list.txt
@@ -10,17 +10,17 @@ perf-buildid-list   mainporcelain common
 perf-diff  mainporcelain common
 perf-evlistmainporcelain common
 perf-injectmainporcelain common
+perf-kmem  mainporcelain common
+perf-kvm   mainporcelain common
 perf-list  mainporcelain common
-perf-sched mainporcelain common
+perf-lock  mainporcelain common
+perf-probe mainporcelain full
 perf-recordmainporcelain common
 perf-reportmainporcelain common
+perf-sched mainporcelain common
+perf-scriptmainporcelain common
 perf-stat  mainporcelain common
+perf-test  mainporcelain common
 perf-timechart mainporcelain common
 perf-top   mainporcelain common
 perf-trace mainporcelain common
-perf-scriptmainporcelain common
-perf-probe mainporcelain full
-perf-kmem  mainporcelain common
-perf-lock  mainporcelain common
-perf-kvm   mainporcelain common
-perf-test  mainporcelain common
-- 
1.7.2.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 2/3] perf: correct a build error

[liguang]

builtin-annotate.c: In function 'hists__find_annotations':
builtin-annotate.c:161:4: error: duplicate case value
builtin-annotate.c:154:4: error: previously used here

it happened when no newt installed

Signed-off-by: liguang 
---
 tools/perf/util/hist.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 3862468..b4436e9 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -208,8 +208,8 @@ static inline int script_browse(const char *script_opt 
__maybe_unused)
return 0;
 }
 
-#define K_LEFT -1
-#define K_RIGHT -2
+#define K_LEFT -2
+#define K_RIGHT -3
 #endif
 
 #ifdef GTK2_SUPPORT
-- 
1.7.2.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: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 04:04:56AM +, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:54:16PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 03:38:04AM +, Matthew Garrett wrote:
> > > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > > So, once that proof is written, suddenly all of the working Linux
> > > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > > odds are, it will not.  Imagine the PR fun that will cause :)
> > > 
> > > No. Why would they be?
> > 
> > Because they are using the "public" shim that you provided them, or the
> > Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> > will end up getting their own shim signed, the rest will just use the
> > one you so helpfully provided them :)
> 
> There's no reason for the LF or generic shim to be blacklisted, since 
> neither will load anything without manual intervention. But that also 
> means that anyone trying to boot them has to have some knowledge of 
> English, and that there's no way to netboot them. But sure, anyone 
> planning that approach has much less to worry about.

I don't see anything about "manual intervention" in the wording that you
provided from Microsoft absolving you from the "duty" you feel you owe
them.  I understand you are worried about "automated" exploits, but that
really is just a semantic overall, as we know it is easy to get people
to hit a key when booting just to get on with the process.

> > Yes you can.  There are all sorts of fun ways you can do this, I can
> > think of a few more at the moment as well.  So, where does it stop?
> > And why stop it at all?  Why not just forbid root users at all?
> 
> Because there's a distinction between ring 0 and ring 3?

Since when did you start trusting ring 0 code?  Bozos like me write this
stuff, surely it isn't secure :)

> > > Microsoft aren't dictating anything here. We're free not to use their 
> > > signatures. However, if we do use their signatures, we agree to play by 
> > > their rules. Nobody seems to have come up with a viable alternative, so 
> > > here we are.
> > 
> > Ok, I keep hearing people say, "why doesn't someone else create a
> > signing authority!" all the time.  And it comes down to one big thing,
> > money.
> 
> Right. We've failed at creating an alternative. That doesn't mean that 
> we get to skip the responsibilities associated with the choice we've 
> made.

Wait, who is "we" here?  The community?  The community over-all didn't
agree with anything with Microsoft, that is between the people getting a
signed key and Microsoft.  Again, you are trying to push your (prior)
company's agreement between them and Microsoft onto the community, and
now the community is pushing back, is that a surprise?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:54:16PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:38:04AM +, Matthew Garrett wrote:
> > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > So, once that proof is written, suddenly all of the working Linux
> > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > odds are, it will not.  Imagine the PR fun that will cause :)
> > 
> > No. Why would they be?
> 
> Because they are using the "public" shim that you provided them, or the
> Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> will end up getting their own shim signed, the rest will just use the
> one you so helpfully provided them :)

There's no reason for the LF or generic shim to be blacklisted, since 
neither will load anything without manual intervention. But that also 
means that anyone trying to boot them has to have some knowledge of 
English, and that there's no way to netboot them. But sure, anyone 
planning that approach has much less to worry about.

> > > I don't buy it.  Yes, I understand this is your position, and has been
> > > all along, and _maybe_ you can extend it to "we should sign our kernel
> > > modules", but to take it farther than that, like the list David has
> > > described, is not required by anyone here.
> > 
> > Failing to take it to that extent is dangerously naive. If you can do it 
> > with kernel modules, you can do it with kexec. If you can do it with 
> > kexec, you can do it with arbitrary mmio access to PCI devices.
> 
> Yes you can.  There are all sorts of fun ways you can do this, I can
> think of a few more at the moment as well.  So, where does it stop?
> And why stop it at all?  Why not just forbid root users at all?

Because there's a distinction between ring 0 and ring 3?

> > Microsoft aren't dictating anything here. We're free not to use their 
> > signatures. However, if we do use their signatures, we agree to play by 
> > their rules. Nobody seems to have come up with a viable alternative, so 
> > here we are.
> 
> Ok, I keep hearing people say, "why doesn't someone else create a
> signing authority!" all the time.  And it comes down to one big thing,
> money.

Right. We've failed at creating an alternative. That doesn't mean that 
we get to skip the responsibilities associated with the choice we've 
made.

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

Re: what's the next LTSI kernel version for long-term support

[Greg Kroah-Hartman]

On Tue, Feb 26, 2013 at 11:46:04AM +0800, Barry Song wrote:
> 2013/2/26 Greg Kroah-Hartman :
> > On Tue, Feb 26, 2013 at 11:06:56AM +0800, Barry Song wrote:
> >> Hi Greg/All,
> >> we have seen 3.4 was announced to be an LTSI in Aug, 2012. I'd like to
> >> know what is the next LTSI version since we might want to align our
> >> next release with LTSI.
> >
> > Who is "we" here?
> >
> people.

I don't take anonymous "we want this" requests serious at all, sorry.
Please provide details as you are asking me to do work for you, right?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 03:38:04AM +, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 03:13:38AM +, Matthew Garrett wrote:
> > > Because Microsoft have indicated that they'd be taking a reactive 
> > > approach to blacklisting and because, so far, nobody has decided to 
> > > write the trivial proof of concept that demonstrates the problem.
> > 
> > So, once that proof is written, suddenly all of the working Linux
> > distros's keys will be revoked?  That will be fun to watch happen, and
> > odds are, it will not.  Imagine the PR fun that will cause :)
> 
> No. Why would they be?

Because they are using the "public" shim that you provided them, or the
Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
will end up getting their own shim signed, the rest will just use the
one you so helpfully provided them :)

> > > "In addition, in the case of Microsoft’s digital signatures of UEFI 
> > > Code, Microsoft may remove a Compatible Product from the Microsoft 
> > > Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> > > notice to Company in the event Microsoft determines in its sole judgment 
> > > that the security of the UEFI Code is compromised."
> > > 
> > > The ability to use the signed code to boot an untrusted copy of the 
> > > Windows kernel is a clear breach of the trust model.
> > 
> > I don't buy it.  Yes, I understand this is your position, and has been
> > all along, and _maybe_ you can extend it to "we should sign our kernel
> > modules", but to take it farther than that, like the list David has
> > described, is not required by anyone here.
> 
> Failing to take it to that extent is dangerously naive. If you can do it 
> with kernel modules, you can do it with kexec. If you can do it with 
> kexec, you can do it with arbitrary mmio access to PCI devices.

Yes you can.  There are all sorts of fun ways you can do this, I can
think of a few more at the moment as well.  So, where does it stop?
And why stop it at all?  Why not just forbid root users at all?

> > Yes, they are all "nice" things to have, but I fail to see how Microsoft
> > should be dictating how Linux, or any other operating system, works,
> > especially when they aren't even signing the kernel, they are merely
> > signing a bootloader shim and saying "do your best for keeping the rest
> > of the system secure please."
> 
> Microsoft aren't dictating anything here. We're free not to use their 
> signatures. However, if we do use their signatures, we agree to play by 
> their rules. Nobody seems to have come up with a viable alternative, so 
> here we are.

Ok, I keep hearing people say, "why doesn't someone else create a
signing authority!" all the time.  And it comes down to one big thing,
money.

The money required to put up a bond to allow a root key to be placed
into the BIOS for just one major OEM is larger than pretty much all of
the Linux companies combined at this moment in time.

The money required to staff up, and put into place the proper
infrastructure to be a signing authority is, I'm pretty sure, larger
than the operating budget of the Linux Foundation at this point in time.
And again, remember the bond requirement of the OEMs.

So that's why the LF, or anyone else, including the UEFI group
themselves, are NOT getting into the key signing business.  Money.

Oh, and the fact that it's just not worth it in the end, but that's a
different topic :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 03:28:39AM +, Matthew Garrett wrote:
> You're happy advising Linux vendors that they don't need to worry about 
> module signing because it's "not obvious" that Microsoft would actually 
> enforce the security model they've spent significant money developing 
> and advertising?

My advice was to Linus and those who are willing to listen to me, not
to Red Hat.  Red Hat has not generally been receptive to my advice in
the past; not that they have any obligation to listen to me, of
course.  After all, I'm not on Red Hat's payroll.  :-)

Speaking more generally, though, (a) revoking the Linux's key is not
zero-cost to Microsoft, (b) it's also not an instant death sentence to
Linux distributions.  Users can always either disable secure boot
mode, or they can install another signing key.  Yes, that is not the
best user experience, but it's something which is doable.

The other thing to consider is that it's not clear in the long run how
much of a lock Microsoft and Windows 8 will have hardware
manufacturers.  There's already been people discussing how to install
Linux on the Chromebook Pixel.  Other traditional PC manufacturers,
including HP and Lenovo, have started creating non-Windows-8 x86
systems using ChromeOS, which can easily have a stock Linux distro
installed on it, and they come at a variety of different price points.
(Heck, the recent ChromeOS boxes, such as Pixel, come with an open
source BIOS which you can reflash.)

Finally note that secure boot is not an issue on server platforms,
which is where most of the traditional Linux vendors have made their
money.  And those who are making money with pre-installed Linux
systems (i.e., like Ubuntu, or Google with ChromeOS) for consumers are
generally doing so in cooperation with hardware OEM partners, where
there's no reason to kowtow to Microsoft's policies.  So there really
isn't a good reason for Linux vendors to cower in fear of Microsoft.

Much of Microsoft power comes from people letting them have power over
them.  You don't have to do it.  Sometimes it's better to let them
carry through on their threat, and while it will be inconvenient, it
is highly likely they will also take damage from their taking action.
Consider what happened the last time the Republicans carried through
on their threat to shut down the US Federal Government.  Sometimes
it's better to let the blackmailers carry through on their threat, and
then steps from there.  Cowering in fear and paying Danegled rarely
gets rid of the Dane.

Regards,

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:45:24PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett  wrote:
> >
> > The user Microsoft care about isn't running Linux
> 
> How f*cking hard is it for you to understand?
> 
> Stop arguing about what MS wants. We do not care. We care bout the
> *user*. You are continually missing the whole point of security, and
> then you make some idiotic arguments about what MS wants you to do.
> 
> It's irrelevant. The only thing that matters is what our *users* want
> us to do, and protecting *their* rights. As long as you seem to treat
> this as some kind of "let's please MS, not our users" issue, all your
> arguments are going to be crap.

Our users want to be able to boot Linux. If Microsoft blacklist a 
distribution's bootloader, that user isn't going to be able to boot 
Linux any more. How does that benefit our users? The user that wants to 
explicitly disable the security is free to do so ("mokutil 
--disable-validation" as root, follow the prompts, reboot), but if 
we only care about *our* users then Microsoft will gleefully blacklist 
us into complete irrelevance.

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

Re: what's the next LTSI kernel version for long-term support

[Barry Song]

2013/2/26 Greg Kroah-Hartman :
> On Tue, Feb 26, 2013 at 11:06:56AM +0800, Barry Song wrote:
>> Hi Greg/All,
>> we have seen 3.4 was announced to be an LTSI in Aug, 2012. I'd like to
>> know what is the next LTSI version since we might want to align our
>> next release with LTSI.
>
> Who is "we" here?
>
people.

>> That might help us to plan the release cycle.
>
> As I've stated before, I do not announce the long-term kernel ahead of
> time, we did that once in the past and it was a total mess.  I announce
> it _after_ the kernel is released.
>
> I have also stated that 3.8 is NOT going to be a long-term kernel, that
> would mean I would be handling 3 long-term kernels at once, plus 1-2
> "normal" stable kernels.  That is a sure way to drive me crazy and burn
> out.

if so, is there a time window for next LTSI? i am hoping there will be
another one in this year?

>
>> BTW, how many people and SoC vendors in ARM communicaty want to align
>> your releases with LTSI?
>
> I do not know.  There was an LTSI meeting last week at ELC where this
> was discussed, I suggest you ask the people who attended it. I was
> there, but it's not up to me to release the meeting minutes, and I
> wasn't taking notes, sorry.

ok.
>
> thanks,
>
> greg k-h

Thanks
barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: resume fails to light display on Macbook Pro Retina on 3.8-rc1

[Greg KH]

On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
> > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH  wrote:
> > > Hi Ben,
> > >
> > > My Macbook Pro Retina fails to resume properly on 3.8.  I tracked this
> > > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp:
> > > move link training helpers into core as display methods)
> > >
> > > Anything I can try to help solve this?
> > >
> > > Note, I'm using the Intel driver as the main controller for this laptop,
> > > well, I think I am, my xorg log is attached.
> > 
> > No you are using the nvidia, the efi always boots nvidia enabled now.
> 
> Really?  When did that change?  I thought I wanted to be using the Intel
> chip to save battery life.
> 
> > btw I just tested my drm-next tree on mine and it resumed the display
> > fine, something oopsed a few seconds later that I haven't tracked down
> > 
> > git://git.freedesktop.org/~airlied/linux drm-next
> > 
> > I'll be sending it to Linus this evening or tomorrow morning, once I
> > fix my tree.
> 
> Ok, I'll test again when it hits Linus's tree, and if that works, it
> would be good to try to work out what patch fixes it to get them into
> the 3.8-stable series so that others don't run into the same problem.

I've tested Linus's tree now (I'm guessing it has all of your changes in
it), and it works!

I see a bunch of patches marked for the stable branch, so I'll try those
out and see if they fix the problem.  If not, I'll let you and Ben know.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett  wrote:
>
> The user Microsoft care about isn't running Linux

How f*cking hard is it for you to understand?

Stop arguing about what MS wants. We do not care. We care bout the
*user*. You are continually missing the whole point of security, and
then you make some idiotic arguments about what MS wants you to do.

It's irrelevant. The only thing that matters is what our *users* want
us to do, and protecting *their* rights. As long as you seem to treat
this as some kind of "let's please MS, not our users" issue, all your
arguments are going to be crap.

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: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:40:31PM -0800, Greg KH wrote:

> What "vendor" is there in this case?  You released a signed shim, as did
> the Linux Foundation, and lots of distros are now using it, and there
> are absolutly no "orginization" behind a bunch of them.  Will your
> signed shim be revoked because a random PoC was posted somewhere that
> could be used with any kernel booted using it?

No, because the version I released doesn't allow you to boot stuff 
without there having been explicit end-user authorisation in advance. 
The LF loader is in the same situation. But no user-focused distribution 
is going to do that.

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