Re: [PATCH v2 0/2] pstore,efi_pstore: Avoid deadlock in non-blocking paths

[Don Zickus]

On Mon, Dec 17, 2012 at 08:56:27PM +, Seiji Aguchi wrote:
> Changelog v1 -> v2
>  - Erase a logic checking the number of online cpus.
>  - Create a patchset to fix deadlocking issue in both pstore filesystem and
>efi_pstore driver.
>- Introduce a function, is_non_blocking_path(), to check if pstore 
>  is in panic and emergency-restart paths (PATCH 1/2)
>- Avoid efi_pstore_driver is blocked in non-blocking paths
>  such as nmi, panic and emergency-restart paths (PATCH 2/2)

This patch set seems cleaner.  Though it seems most of patch2 should have
been in patch1 (except for the efi part).

The only nitpick I have is the name 'is_non_blocking_path'.  I don't know
why, but the name doesn't seem exactly right to me.  I was thinking
something like 'pstore_cannot_block_path' or something.  But it is just a
nitpick, so it doesn't matter either way to me.

Cheers,
Don

> 
> [Issue]
> 
> There are some paths which shouldn't be blocked in kernel, like NMI, panic 
> case after stopping cpus, 
> emergency-restart.
> 
> On the other hand, current pstore avoids blocking in a NMI path but it may be 
> blocked in other paths.
> Also, an efi_pstore driver may be blocked in all of those paths because it 
> simply takes a spin lock 
> at writing time.
> 
> If they are blocked in those paths, the system will hang up and it has a big 
> impact for users.
> 
> Here is an example scenario which pstore is blocked in panic path.
> 
>  - cpuA grabs psinfo->buf_lock
>  - cpuB panics and calls smp_send_stop
>  - smp_send_stop sends IRQ to cpuA
>after 1 second, cpuB gives up on cpuA and sends an NMI instead
>  - cpuA is now in an NMI handler while still holding buf_lock.
>And then, cpuB is deadlocked by taking efi_pstore->lock again.
> 
> This case may happen if a firmware has a bug and cpuA is stuck in it.
> 
> [Solution]
> 
> This patchset avoids that pstore and efi_pstore driver are blocked in the 
> non-blocking paths 
> like NMI, panic, and emrgency-restart by introducing a function checking if 
> they are in those paths.
> Please see each patch for detailed explanations.
> 
> Seiji Aguchi (2):
>   [PATCH v2 1/2] pstore: Avoid deadlock in panic and emergency-restart path
>   [PATCH v2 2/2] efi_pstore: Avoid deadlock in non-blocking paths
> 
>  drivers/firmware/efivars.c |   11 ++-
>  fs/pstore/platform.c   |   34 --
>  include/linux/pstore.h |6 ++
>  3 files changed, 44 insertions(+), 7 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 3/4] ARM: tegra: Add OF_DEV_AUXDATA for uart driver in board dt

[Stephen Warren]

On 12/17/2012 05:08 AM, Laxman Dewangan wrote:
> Add OF_DEV_AUXDATA for high speed uart controller driver for
> Tegra20/Tegra30 board dt files.
> Set the parent clock of uart controller to PLLP.

> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c 
> b/arch/arm/mach-tegra/board-dt-tegra20.c

> @@ -94,6 +94,11 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata 
> = {

> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006000, "tegra-uart.0", 
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006040, "tegra-uart.1", 
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006200, "tegra-uart.2", 
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006300, "tegra-uart.3", 
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006400, "tegra-uart.4", 
> NULL),

Instead, can we simply get the clocks from device tree? Prashant, how
much effort will that be once your clock patches are checked in, or is
it already part of those patches?

> @@ -106,7 +111,10 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] 
> __initdata = {
>  static __initdata struct tegra_clk_init_table tegra_dt_clk_init_table[] = {
>   /* name parent  rateenabled */
>   { "uarta",  "pll_p",21600,  true },
> + { "uartb",  "pll_p",21600,  false },
> + { "uartc",  "pll_p",21600,  false },
>   { "uartd",  "pll_p",21600,  true },
> + { "uarte",  "pll_p",21600,  false },

Prashant's clock patches remove this table. Please work with him to work
out how to deal with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling

[Vivek Goyal]

On Mon, Dec 17, 2012 at 01:33:14PM -0800, Tejun Heo wrote:
> Hello,
> 
> On Mon, Dec 17, 2012 at 04:27:36PM -0500, Vivek Goyal wrote:
> > What I do care about is atleast being able to read and understand the
> > code easily. Right now, it is hard to understand. I am still struggling
> > to wrap my head around it.
> 
> Hmm... I thought it was really simple.  Maybe I'm just too familiar
> with it.  You just walk up the tree multiplying the fraction you have
> at each level.  It really doesn't get much simpler than that.
> 
> > For example, while adding a group to service tree we calculate
> > cfqg->vfaction as follows.
> > 
> > vfr = vfr * pos->leaf_weight / pos->level_weight;
> > 
> > and then 
> > 
> > vfr = vfr * pos->weight / parent->level_weight;
> > 
> > cfqg->vfraction = max_t(unsigned, vfr, 1)
> > 
> > If cfqg->vfraction is about cfqg then why should we take into account
> > leaf_weight and level_weight. We should be just worried about pos->weight
> > and parent->level_weight and that should determine vfaction of cfqg.
> 
> Eh?  Then how would it compete with the children cfqgs?  You can
> consider it as the hidden leaf node competing with the children cfqgs,
> right?  So, you take the leaf weight and divide it by the total active
> weight of all the children (including the hidden leaf node).  It isn't
> different from the rest of the calculation.  It just looks different
> because leaf_weight is stored elsewhere and we look down there and
> then walke up.  The calculation being done is exactly the same one.

Again it is coming from multiplexing cfqg and cfqg->task_group. So
effectively we are calculating the vfraction of task_group inside cfqg.
Once you say cfqg->vfraction, I immediately think of total share of
group (including task_group and all children cgroups).

May be cfqg->task_group_vfraction (or cfqg->tg_fraction) is a better name.

Also descrition says.

/* vfraction  the fraction of vdisktime that a cfqg is entitled to */

May be we can clarify it that it is share of task_group of cfqg.

I guess i am too familiar with how cpu has done it. I think I am getting
confused with properties which belong to cfqg and properties which
belong to cfqg->task_group.

I guess if we prefix fields belong to task_group with somete suitable
string, it might become little easier to understand.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: tegra: add serial driver

[Stephen Warren]

On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
> Nvidia's Tegra has multiple uart controller which supports:
> - APB dma based controller fifo read/write.
> - End Of Data interrupt in incoming data to know whether end
>   of frame achieve or not.
> - Hw controlled RTS and CTS flow control to reduce SW overhead.
> 
> Add serial driver to use all above feature.

> diff --git a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt 
> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt

> +Required properties:
> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".

I think you want ", or" not just "," there. If both are specified,
"tegra30" should come before "tegra20", so you might want to re-order
that. That said, other bindings say something like
"nvidia,tegra-hsuart" so avoid having to spell out all the
supported Tegra versions.

> diff --git a/drivers/tty/serial/serial_tegra.c 
> b/drivers/tty/serial/serial_tegra.c

> +struct tegra_uart_chip_data tegra20_uart_chip_data = {
> + .tx_fifo_full_status= false,
> + .allow_txfifo_reset_fifo_mode   = true,
> + .support_clk_src_div= false,
> +};
> +
> +struct tegra_uart_chip_data tegra30_uart_chip_data = {
> + .tx_fifo_full_status= true,
> + .allow_txfifo_reset_fifo_mode   = false,
> + .support_clk_src_div= true,
> +};

Nit: Perhaps it'd be nice to move those right before
tegra_uart_of_match[] - i.e. right where they're used.

> +static struct tegra_uart_platform_data *tegra_uart_parse_dt(

> + if (of_get_property(np, "nvidia,enable-modem-interrupt", NULL))
> + pdata->enable_modem_interrupt = 1;

That should use of_property_read_bool().

> +static int __devinit tegra_uart_probe(struct platform_device *pdev)

> + if (pdev->dev.of_node) {

That will always be true these days.

I didn't review the body of the UART implementation since I'm not
familiar with drivers/tty/serial nor too much about our UART HW beyond
basic 8250 usage.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpuidle_get_cpu_driver livelocks idle system

[Daniel Lezcano]

On 12/17/2012 08:36 PM, Russ Anderson wrote:
> The 3.7 kernel grinds to a halt on boot of a system with
> 2048 cpus.  NMI showed most of the cpus in
> _raw_spin_lock in cpuidle_get_cpu_driver().  (backtrace below)
> 
> A quick look at cpuidle_get_cpu_driver() shows the hot lock.
> 
> In drivers/cpuidle/driver.c:
> 
> /**
>  * cpuidle_get_cpu_driver - return the driver tied with a cpu
>  */
> struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
> {
> struct cpuidle_driver *drv;
> 
> if (!dev)
> return NULL;
> 
> spin_lock(&cpuidle_driver_lock);
> drv = __cpuidle_get_cpu_driver(dev->cpu);
> spin_unlock(&cpuidle_driver_lock);
> 
> return drv;
> }
> 

Hi Russ,

thanks for investigating the problem. You are right, there is a
bottleneck here.

Regarding how is used the cpuidle code, I think it is safe to remove the
locks.



> This change was added in on Nov 14th, 2012.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92
> 
> The patch says it adds support for cpus with different characteristics,
> but adds a big global lock.  The comment claims "no impact for the other
> platforms if the option is disabled", which leads me to believe the
> spin_lock was added inadvertently.  CPU_IDLE_MULTIPLE_DRIVERS is off
> in my config file.
> 
> linux$ grep CPU_IDLE_MULTIPLE_DRIVERS .config
> # CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
> 
> As more cpus become idle, more cpus fight over the lock until
> the system livelocks on the crushing weight of idle.
> 
> The fix may be to move the spin_lock into __cpuidle_get_cpu_driver,
> which has different versions for CONFIG_CPU_IDLE_MULTIPLE_DRIVERS,
> to avoid impacting the disabled case, or get rid of the spin_lock
> all together.
> 
> 
> 
> == UV NMI process trace cpu 12: ==
> CPU 12
> Pid: 0, comm: swapper/12 Tainted: G   O 3.7.0.rja-sgi+ #38
> RIP: 0010:[]  [] _raw_spin_lock+0x25/0x30
> [...]
> Call Trace:
>  [] cpuidle_get_cpu_driver+0x1c/0x30
>  [] cpuidle_idle_call+0x7d/0x1b0
>  [] cpu_idle+0xdd/0x130
>  [] start_secondary+0xc6/0xcc
> 
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH] serial: tegra: add serial driver

[Mitch Bradley]

On 12/17/2012 11:36 AM, Stephen Warren wrote:
> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>> Nvidia's Tegra has multiple uart controller which supports:
>> - APB dma based controller fifo read/write.
>> - End Of Data interrupt in incoming data to know whether end
>>   of frame achieve or not.
>> - Hw controlled RTS and CTS flow control to reduce SW overhead.
> 
>> diff --git 
>> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt 
>> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
> 
>> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver.
>> +
>> +Required properties:
>> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".
> 
> One question that isn't addressed here is:
> 
> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying
> compatible = "nvidia,tegra20-uart".

The way it is supposed to work is that the compatible property should
list "nvidia,tegra30-hsuart" first, followed by a fallback name that
refers to the generic 8250 compatibility.  Having the 8250.c driver bind
to the more-specific tegra30-hsuart name is wrong.

 However, the 8250.c driver doesn't
> support the DMA features of this driver. This driver is an alternate
> driver for the same HW that allows DMA to be used with it, etc.
> 
> Since DT is supposed to describe the HW, modifying the DT to change the
> compatible value in order to select a different driver in Linux doesn't
> seem correct, or is it? Is there any kind of precedent for how to select
> different drivers for the same HW at run-time? I'd wondered about using
> the sysfs bind/unbind "methods" from user-space as the driver selection
> mechanism...
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts: add checkmaintainers.py

[Cesar Eduardo Barros]

Em 17-12-2012 15:00, Borislav Petkov escreveu:

On Mon, Dec 17, 2012 at 07:35:44AM -0800, Joe Perches wrote:

Perhaps Cesar can use his script as a starting point to find those
pattern invalidating commits or maybe add the capability (or a
--strict check) to checkpatch.


Or that, I don't have a strict preference.

So, yeah, I can see how checkpatch saying: "you've just renamed a
file and thusly invalidated a pattern in MAINTAINERS. Pls, consider
correcting the pattern" could make sense. And I would even add it to
default functionality since the MAINTAINERS patterns are something we
want to always have up-to-date, IMO.


Good idea, but a standalone MAINTAINERS checker is still useful, to 
check for things checkpatch did not catch, either because it was not 
run, or because it did not have enough information.


For instance, consider the case of a patch removing the last file in a 
directory going in via one branch, while a patch adding a file pattern 
for that same directory goes in via a separate branch. There is no way 
checkpatch can catch that.


As for finding the pattern invalidating commits, it is usually not that 
hard, a simple "git log -- " or similar usually does the trick, 
except in the cases where the pattern addition itself was wrong. The 
hard part can be interpreting it and the surrounding commits to find out 
the committer's intention, how it should affect the MAINTAINERS entry, 
and who should get a Cc: of the fix.


--
Cesar Eduardo Barros
ces...@cesarb.net
cesar.bar...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mm: Downgrade mmap_sem before locking or populating on mmap

[Andy Lutomirski]

On Sun, Dec 16, 2012 at 7:29 PM, Michel Lespinasse  wrote:
> On Sun, Dec 16, 2012 at 10:05 AM, Andy Lutomirski  wrote:
>> On Sun, Dec 16, 2012 at 4:39 AM, Michel Lespinasse  wrote:
>>> I think this could be done by extending the mlock work I did as part
>>> of v2.6.38-rc1. The commit message for
>>> c explains the idea; basically
>>> mlock() was split into do_mlock() which just sets the VM_LOCKED flag
>>> on vmas as needed, and do_mlock_pages() which goes through a range of
>>> addresses and actually populates/mlocks each individual page that is
>>> part of a VM_LOCKED vma.
>>
>> Doesn't this have the same problem?  It holds mmap_sem for read for a
>> long time, and if another writer comes in then r/w starvation
>> prevention will kick in.
>
> Well, my point is that do_mlock_pages() doesn't need to hold the
> mmap_sem read side for a long time. It currently releases it when
> faulting a page requires a disk read, and could conceptually release
> it more often if needed.

I can't find this code.  It looks like do_mlock_pages calls
__mlock_vma_pages_range, which calls __get_user_pages, which makes its
way to __do_fault, which doesn't seem to drop mmap_sem.

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

Re: [PATCH 2/2] cpufreq: db8500: set CPUFREQ_CONST_LOOPS

[Fabio Baltieri]

On Mon, Dec 17, 2012 at 10:24:15AM -0800, Stephen Boyd wrote:
> On 12/04/12 02:10, Fabio Baltieri wrote:
> >  static struct cpufreq_driver db8500_cpufreq_driver = {
> > -   .flags  = CPUFREQ_STICKY,
> > +   .flags  = CPUFREQ_STICKY | CPUFREQ_CONST_LOOPS,
> 
> Wouldn't you want to fold this into the previous patch so bisection is
> not broken? Otherwise you have a place where lpj is all screwed up when
> cpufreq mucks with it.

You are basically right... but that's not going to be as screwed up as
it's now, so I'd say that it's not worth the rebase unless the
maintainer says so. :-)

Thanks!
Fabio

-- 
Fabio Baltieri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: tegra: add serial driver

[Stephen Warren]

On 12/17/2012 02:58 PM, Mitch Bradley wrote:
> On 12/17/2012 11:36 AM, Stephen Warren wrote:
>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>>> Nvidia's Tegra has multiple uart controller which supports:
>>> - APB dma based controller fifo read/write.
>>> - End Of Data interrupt in incoming data to know whether end
>>>   of frame achieve or not.
>>> - Hw controlled RTS and CTS flow control to reduce SW overhead.
>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt 
>>> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
>>
>>> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver.
>>> +
>>> +Required properties:
>>> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".
>>
>> One question that isn't addressed here is:
>>
>> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying
>> compatible = "nvidia,tegra20-uart".
> 
> The way it is supposed to work is that the compatible property should
> list "nvidia,tegra30-hsuart" first, followed by a fallback name that
> refers to the generic 8250 compatibility.  Having the 8250.c driver bind
> to the more-specific tegra30-hsuart name is wrong.

8250.c binds to nvidia,tegra20-uart, so that aspect is fine.

However, the real issue is that we probably want 4 of the 5 ports to use
the plain old 8250.c (so as not to use up too many DMA channels), but
just 1 of the ports to use the DMA-capable high-performance driver (e.g.
the one that a particular board has hooked up to a Bluetooth radio). The
only way to do that with DT that I know of would be to specify different
subsets of legal compatible values for each UART in the per-board .dts file.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm: tegra: Add new DT property to USB node.

[Alan Stern]

On Mon, 17 Dec 2012, Stephen Warren wrote:

> On 12/13/2012 11:59 PM, Venu Byravarasu wrote:
> > As Tegra USB host driver is using instance number for resetting
> > PORT0 twice, adding a new DT property for handling this.
> 
> Alan, Greg, Felip,e
> 
> This series looks fine to me.
> 
> I'd like to take all the Tegra-related USB patches through the Tegra
> tree for 3.9 if possible (so I'm looking for your acks here). I believe
> Venu plans to significantly clean up the EHCI/PHY driver split for
> Tegra, rework the drivers, and add support for Tegra30 in addition to
> Tegra20. Some of this requires changes to some Tegra board files and
> device trees to maintain "git bisect" I don't know for sure yet, but I
> believe that rework may also end up conflicting with other clock-related
> rework that will show up for Tegra in 3.9. Are you OK with this? I'll
> certainly look for your review/acks on the patches before picking them
> up though.

Regarding the changes to drivers/usb/host/ehci-tegra.c:

Acked-by: Alan Stern 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm: tegra: Add new DT property to USB node.

[Alan Stern]

On Mon, 17 Dec 2012, Greg KH wrote:

> You can't pick anything up for 3.9 until after 3.8-rc1 is out, according
> to the rules of linux-next

Well, you can accept a submission and store it in a private tree until 
then.  You just can't put it in any tree that feeds into linux-next.

Alan Stern

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

Re: [PATCH 3/3] ACPI: Overriding ACPI tables via initrd only works with an initrd

[Thomas Renninger]

On Monday, December 17, 2012 10:08:52 AM H. Peter Anvin wrote:
> On 12/17/2012 01:28 AM, Borislav Petkov wrote:
> > Hi guys,
> > 
> > this one sanitizes the Kconfig entry prompt so can we pick it up for
> > -rc1 or later, please?
> 
> Hm... all these are actually cleanups or fixes for the stuff that is now
> upstream, I believe... as minor fixes I think these can be pushed
> post-rc1 if we don't get to them sooner but it looks like they are all
> needed.
This and another one are more or less minor cleanups, not
urgently needed.
I can repost them the next days.

Thanks hpa for helping to finally get this feature mainline.
It's a huge enhancement for developing and debugging
ACPI related stuff on Linux.

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

Re: [PATCH 1/3] arch/tile: implement user_regset interface on tilegx

[Simon Marchi]

On Mon, Dec 17, 2012 at 12:06 PM, Chris Metcalf  wrote:
> On 12/14/2012 11:34 PM, Simon Marchi wrote:
>> This is an implementation of user_regset for the tilegx architecture. It
>> reuses the basic blocks that were already there.
>
> Thanks, Simon!  A couple of comments:
>
> I encourage you to respin this for tilepro as well as tilegx, since it's 
> going to be trivial to make it happen.  Just take away all yours ifdefs, and 
> use #include  and CHIP_ARCH_NAME instead of the string "tilegx". 
>  It's worth it just to avoid the ifdefs in the code :-)

Ok, I will send a v2 with this soon.

> I think with this support added, we have all the prerequisites to add "select 
> HAVE_ARCH_TRACEHOOK" under "config TILE" in arch/tile/Kconfig, so we might as 
> well do that too.  That will enable PTRACE_GETREGSET and PTRACE_SETREGSET, as 
> well as /proc/PID/syscall, so why not?

This is indeed my objective ;), and it is an intermediate objective to
add support for HAVE_SYSCALL_TRACEPOINTS. If we look at arch/Kconfig,
just above HAVE_ARCH_TRACEHOOK, we still have

TIF_SYSCALL_TRACE   calls tracehook_report_syscall_{entry,exit}
TIF_NOTIFY_RESUME   calls tracehook_notify_resume()
signal delivery calls tracehook_signal_handler()

that we need to implement.

> --
> Chris Metcalf, Tilera Corp.
> http://www.tilera.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: [PATCH 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling

[Tejun Heo]

Hey, Vivek.

On Mon, Dec 17, 2012 at 04:49:11PM -0500, Vivek Goyal wrote:
> > Eh?  Then how would it compete with the children cfqgs?  You can
> > consider it as the hidden leaf node competing with the children cfqgs,
> > right?  So, you take the leaf weight and divide it by the total active
> > weight of all the children (including the hidden leaf node).  It isn't
> > different from the rest of the calculation.  It just looks different
> > because leaf_weight is stored elsewhere and we look down there and
> > then walke up.  The calculation being done is exactly the same one.
> 
> Again it is coming from multiplexing cfqg and cfqg->task_group. So
> effectively we are calculating the vfraction of task_group inside cfqg.

Or calculating the fraction of the hidden leaf node.

> Once you say cfqg->vfraction, I immediately think of total share of
> group (including task_group and all children cgroups).

Any tasks should be treated as member of the hidden leaf node, so...

> May be cfqg->task_group_vfraction (or cfqg->tg_fraction) is a better name.

I don't know.  Wouldn't just explaining clearly in the comment e
enough?  I think the name "vfraction" is already weird enough to
indicate that it's something which you need to read explanation about.
If that explanation is readily available as comment, I think it should
be okay.

> Also descrition says.
> 
> /* vfraction  the fraction of vdisktime that a cfqg is entitled to */
> 
> May be we can clarify it that it is share of task_group of cfqg.

Yeah, no objection.  Let's beef up the explanation there.

> I guess i am too familiar with how cpu has done it. I think I am getting
> confused with properties which belong to cfqg and properties which
> belong to cfqg->task_group.
> 
> I guess if we prefix fields belong to task_group with somete suitable
> string, it might become little easier to understand.

I usually am not a big fan of adding wordy prefixes.  I think they
tend to obfuscate/frustrate more than help.  Let's stick a weird (that
is, non-generic) name to something weird and explain it well in the
comment.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: tegra: add serial driver

[Mitch Bradley]

On 12/17/2012 12:04 PM, Stephen Warren wrote:
> On 12/17/2012 02:58 PM, Mitch Bradley wrote:
>> On 12/17/2012 11:36 AM, Stephen Warren wrote:
>>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
 Nvidia's Tegra has multiple uart controller which supports:
 - APB dma based controller fifo read/write.
 - End Of Data interrupt in incoming data to know whether end
   of frame achieve or not.
 - Hw controlled RTS and CTS flow control to reduce SW overhead.
>>>
 diff --git 
 a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt 
 b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
>>>
 +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver.
 +
 +Required properties:
 +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".
>>>
>>> One question that isn't addressed here is:
>>>
>>> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying
>>> compatible = "nvidia,tegra20-uart".
>>
>> The way it is supposed to work is that the compatible property should
>> list "nvidia,tegra30-hsuart" first, followed by a fallback name that
>> refers to the generic 8250 compatibility.  Having the 8250.c driver bind
>> to the more-specific tegra30-hsuart name is wrong.
> 
> 8250.c binds to nvidia,tegra20-uart, so that aspect is fine.
> 
> However, the real issue is that we probably want 4 of the 5 ports to use
> the plain old 8250.c (so as not to use up too many DMA channels), but
> just 1 of the ports to use the DMA-capable high-performance driver (e.g.
> the one that a particular board has hooked up to a Bluetooth radio). The
> only way to do that with DT that I know of would be to specify different
> subsets of legal compatible values for each UART in the per-board .dts file.


That's an okay way to do it.  The whole purpose of the compatible
property is to support driver binding.  The mantra to "describe the
hardware" is good, but shouldn't be taken to extremes.

It would be a good idea to comment the .dts file to explain why the
compatible property differs between the otherwise-identical nodes.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add 32 bit VDSO time function support

[stefani]

From: Stefani Seibold 

This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() to the 32 bit VDSO.

The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time time stamp, without knowing the pitfalls. VDSO
time functions a fast and reliable way, because the kernel knows the
best time source and the P- and C-state of the CPU.

The helper library to use the VDSO functions can be download at
http://http://seibold.net/vdso.c
The libary is very small, only 228 lines of code. Compile it with
gcc -Wall -O3 -fpic vdso.c -lrt -shared -o libvdso.so
and use it with LD_PRELOAD=/libvdso.so

This kind of helper must be integrated into glibc, for x86 64-bit and
PowerPC it is already there.

Some benchmark linux 32 bit results (all measurements are in nano seconds):

Intel(R) Celeron(TM) CPU 400MHz

Average time kernel call:
 gettimeofday(): 1039
 clock_gettime(): 1578
 time(): 526
Average time VDSO call:
 gettimeofday(): 378
 clock_gettime(): 303
 time(): 60

Celeron(R) Dual-Core CPU T3100 1.90GHz

Average time kernel call:
 gettimeofday(): 209
 clock_gettime(): 406
 time(): 135
Average time VDSO call:
 gettimeofday(): 51
 clock_gettime(): 43
 time(): 10

So you can see a performance increase between 4 and 13, depending on the
CPU and the function.

The patch is against kernel 3.7. Please apply if you like it.

Changelog:
25.11.2012 - first release and proof of concept for linux 3.4
11.12.2012 - Port to linux 3.7 and code cleanup
12.12.2012 - fixes suggested by Andy Lutomirski
   - fixes suggested by John Stultz
   - use call VDSO32_vsyscall instead of int 80
   - code cleanup
17.12.2012 - support for IA32_EMULATION, this includes
 - code cleanup
 - include cleanup to fix compile warnings and errors
 - move out seqcount from seqlock, enable use in VDSO
 - map FIXMAP and HPET into the 32 bit address space

Signed-off-by: Stefani Seibold 
---
 arch/x86/Kconfig  |   4 +-
 arch/x86/include/asm/clocksource.h|   4 -
 arch/x86/include/asm/fixmap.h |   6 +-
 arch/x86/include/asm/vgtod.h  |  10 ++-
 arch/x86/include/asm/vsyscall.h   |   1 -
 arch/x86/include/asm/vvar.h   |   5 ++
 arch/x86/kernel/Makefile  |   1 +
 arch/x86/kernel/hpet.c|  11 ++-
 arch/x86/kernel/setup.c   |   2 +
 arch/x86/kernel/tsc.c |   2 -
 arch/x86/kernel/vmlinux.lds.S |   4 -
 arch/x86/kernel/vsyscall_64.c |  49 ---
 arch/x86/kernel/vsyscall_gtod.c   |  93 +
 arch/x86/mm/init_32.c |   1 +
 arch/x86/vdso/Makefile|   6 ++
 arch/x86/vdso/vclock_gettime.c| 108 ++--
 arch/x86/vdso/vdso32-setup.c  |  41 ++
 arch/x86/vdso/vdso32/vclock_gettime.c |  29 +++
 arch/x86/vdso/vdso32/vdso32.lds.S |   3 +
 include/linux/clocksource.h   |   1 -
 include/linux/mm.h|   3 +
 include/linux/seqcount.h  | 150 ++
 include/linux/seqlock.h   | 145 +---
 include/linux/time.h  |   3 +-
 include/linux/timekeeper_internal.h   |   1 +
 include/linux/types.h |   2 +
 mm/mmap.c |  20 -
 27 files changed, 457 insertions(+), 248 deletions(-)
 create mode 100644 arch/x86/kernel/vsyscall_gtod.c
 create mode 100644 arch/x86/vdso/vdso32/vclock_gettime.c
 create mode 100644 include/linux/seqcount.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 46c3bff..b8c2c74 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -100,9 +100,9 @@ config X86
select GENERIC_CMOS_UPDATE
select CLOCKSOURCE_WATCHDOG
select GENERIC_CLOCKEVENTS
-   select ARCH_CLOCKSOURCE_DATA if X86_64
+   select ARCH_CLOCKSOURCE_DATA
select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && 
X86_LOCAL_APIC)
-   select GENERIC_TIME_VSYSCALL if X86_64
+   select GENERIC_TIME_VSYSCALL
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/x86/include/asm/clocksource.h 
b/arch/x86/include/asm/clocksource.h
index 0bdbbb3..67d68b9 100644
--- a/arch/x86/include/asm/clocksource.h
+++ b/arch/x86/include/asm/clocksource.h
@@ -3,8 +3,6 @@
 #ifndef _ASM_X86_CLOCKSOURCE_H
 #define _ASM_X86_CLOCKSOURCE_H
 
-#ifdef CONFIG_X86_64
-
 #define VCLOCK_NONE 0  /* No vDSO clock available. */
 #define VCLOCK_TSC  1  /* vDSO should use vread_tsc.   */
 #define VCLOCK_HPET 2  /* vDSO should use vread_hpet.  */
@@ -13,6 +11,4 @@ struct arch_clocksource_data {
int vclock_mode;
 };
 
-#endif /* CONFIG_X86_64 */
-
 #endif /* _ASM_X86_CLOCKSOURCE_H */
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 4da3c0c..75ebc52 100644
--

Re: [PATCH 4/4] ARM: tegra: Set SCU base address dynamically from DT

[Stephen Warren]

On 12/17/2012 07:00 AM, Rob Herring wrote:
> On 12/17/2012 12:18 AM, Hiroshi Doyu wrote:
>> Set Snoop Control Unit(SCU) register base address dynamically from DT.

>> diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c

>>  static void __init tegra_smp_init_cpus(void)
>>  {
>> -unsigned int i, ncores = scu_get_core_count(scu_base);
>> +struct device_node *np;
>> +unsigned int i, ncores = 1;
>> +
>> +np = of_find_matching_node(NULL, cortex_a9_scu_match);
>> +if (!np)
>> +return;
>> +scu_base = of_iomap(np, 0);
> 
> Did you actually test this? Unless something changed, ioremap does not
> work this early. The only reason to have it mapped this early is to get
> the core count, but that doesn't work on A15 or A7. So we really need to
> get core count/mask in a standard way. At least some work to get core
> count from DT went into 3.8.

Does it work if the machine's .map_io() function has set up a static
mapping that includes the specified region? I believe that is the case
on Tegra. What is the alternative if the registers can't be mapped;
should the code count the number of child nodes in /cpus?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/27] 3.7.1-stable review

[Greg Kroah-Hartman]

On Mon, Dec 17, 2012 at 11:07:38PM +0100, Mariusz Kozlowski wrote:
> On Fri, Dec 14, 2012 at 03:01:13PM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.7.1 release.
> > There are 27 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Dec 16 22:16:56 UTC 2012.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.1-rc1.gz
> > and the diffstat can be found below.
> 
> Greg, would that be a problem to send these patches for review to
> linux-3.7.y branch and mark them with v3.7.1-rc1 commit/tag?

Yes, it is a problem, sorry.

> Is something goes wrong there is still place to fix/revert as needed.
> If not do the final commit/tag that says this is v3.7.1 [1].
> 
> It would be easier to automate things by just monitoring linux-stable
> remote for new tags.

Automate what?  You can just look for the patch files to show up on
kernel.org if you wish to automate testing.

Otherwise, sorry, but creating a git tree of these patches, for the -rc
kernels, doesn't work with the current work flow.  I have to have the
ability to remove and add patches and change patches in the middle of
the series of patches before the final kernel release for a variety of
reasons, all of which have come up over the years of doing these stable
kernel releases.

In other words, I don't ever want to rebase.

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] Add 32 bit VDSO time function support

[Andy Lutomirski]

On Mon, Dec 17, 2012 at 2:12 PM,   wrote:
> From: Stefani Seibold 
>
> This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> and vdso_time() to the 32 bit VDSO.
>
> The reason to do this was to get a fast reliable time stamp. Many developers
> uses TSC to get a fast time time stamp, without knowing the pitfalls. VDSO
> time functions a fast and reliable way, because the kernel knows the
> best time source and the P- and C-state of the CPU.
>
> The helper library to use the VDSO functions can be download at
> http://http://seibold.net/vdso.c
> The libary is very small, only 228 lines of code. Compile it with
> gcc -Wall -O3 -fpic vdso.c -lrt -shared -o libvdso.so
> and use it with LD_PRELOAD=/libvdso.so
>
> This kind of helper must be integrated into glibc, for x86 64-bit and
> PowerPC it is already there.
>
> Some benchmark linux 32 bit results (all measurements are in nano seconds):
>
> Intel(R) Celeron(TM) CPU 400MHz
>
> Average time kernel call:
>  gettimeofday(): 1039
>  clock_gettime(): 1578
>  time(): 526
> Average time VDSO call:
>  gettimeofday(): 378
>  clock_gettime(): 303
>  time(): 60
>
> Celeron(R) Dual-Core CPU T3100 1.90GHz
>
> Average time kernel call:
>  gettimeofday(): 209
>  clock_gettime(): 406
>  time(): 135
> Average time VDSO call:
>  gettimeofday(): 51
>  clock_gettime(): 43
>  time(): 10
>
> So you can see a performance increase between 4 and 13, depending on the
> CPU and the function.
>
> The patch is against kernel 3.7. Please apply if you like it.

This would probably be a lot more readable if you split out the
preparation parts -- i.e. struct rearrangement and bitness issues, and
then added the new code on top of it.

>
> Changelog:
> 25.11.2012 - first release and proof of concept for linux 3.4
> 11.12.2012 - Port to linux 3.7 and code cleanup
> 12.12.2012 - fixes suggested by Andy Lutomirski
>- fixes suggested by John Stultz
>- use call VDSO32_vsyscall instead of int 80
>- code cleanup
> 17.12.2012 - support for IA32_EMULATION, this includes
>  - code cleanup
>  - include cleanup to fix compile warnings and errors
>  - move out seqcount from seqlock, enable use in VDSO
>  - map FIXMAP and HPET into the 32 bit address space
>
> Signed-off-by: Stefani Seibold 
> ---
>  arch/x86/Kconfig  |   4 +-
>  arch/x86/include/asm/clocksource.h|   4 -
>  arch/x86/include/asm/fixmap.h |   6 +-
>  arch/x86/include/asm/vgtod.h  |  10 ++-
>  arch/x86/include/asm/vsyscall.h   |   1 -
>  arch/x86/include/asm/vvar.h   |   5 ++
>  arch/x86/kernel/Makefile  |   1 +
>  arch/x86/kernel/hpet.c|  11 ++-
>  arch/x86/kernel/setup.c   |   2 +
>  arch/x86/kernel/tsc.c |   2 -
>  arch/x86/kernel/vmlinux.lds.S |   4 -
>  arch/x86/kernel/vsyscall_64.c |  49 ---
>  arch/x86/kernel/vsyscall_gtod.c   |  93 +
>  arch/x86/mm/init_32.c |   1 +
>  arch/x86/vdso/Makefile|   6 ++
>  arch/x86/vdso/vclock_gettime.c| 108 ++--
>  arch/x86/vdso/vdso32-setup.c  |  41 ++
>  arch/x86/vdso/vdso32/vclock_gettime.c |  29 +++
>  arch/x86/vdso/vdso32/vdso32.lds.S |   3 +
>  include/linux/clocksource.h   |   1 -
>  include/linux/mm.h|   3 +
>  include/linux/seqcount.h  | 150 
> ++
>  include/linux/seqlock.h   | 145 +---
>  include/linux/time.h  |   3 +-
>  include/linux/timekeeper_internal.h   |   1 +
>  include/linux/types.h |   2 +
>  mm/mmap.c |  20 -
>  27 files changed, 457 insertions(+), 248 deletions(-)
>  create mode 100644 arch/x86/kernel/vsyscall_gtod.c
>  create mode 100644 arch/x86/vdso/vdso32/vclock_gettime.c
>  create mode 100644 include/linux/seqcount.h
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 46c3bff..b8c2c74 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -100,9 +100,9 @@ config X86
> select GENERIC_CMOS_UPDATE
> select CLOCKSOURCE_WATCHDOG
> select GENERIC_CLOCKEVENTS
> -   select ARCH_CLOCKSOURCE_DATA if X86_64
> +   select ARCH_CLOCKSOURCE_DATA
> select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && 
> X86_LOCAL_APIC)
> -   select GENERIC_TIME_VSYSCALL if X86_64
> +   select GENERIC_TIME_VSYSCALL
> select KTIME_SCALAR if X86_32
> select GENERIC_STRNCPY_FROM_USER
> select GENERIC_STRNLEN_USER
> diff --git a/arch/x86/include/asm/clocksource.h 
> b/arch/x86/include/asm/clocksource.h
> index 0bdbbb3..67d68b9 100644
> --- a/arch/x86/include/asm/clocksource.h
> +++ b/arch/x86/include/asm/clocksource.h
> @@ -3,8 +3,6 @@
>  #ifndef _ASM_X86_CLOCKSOURCE_H
>  #define _ASM_X86_CLOCKSOURCE_H
>
> -#ifdef

Re: [PATCH] Add 32 bit VDSO time function support

[H. Peter Anvin]

On 12/17/2012 02:12 PM, stef...@seibold.net wrote:
>  arch/x86/Kconfig  |   4 +-
>  arch/x86/include/asm/clocksource.h|   4 -
>  arch/x86/include/asm/fixmap.h |   6 +-
>  arch/x86/include/asm/vgtod.h  |  10 ++-
>  arch/x86/include/asm/vsyscall.h   |   1 -
>  arch/x86/include/asm/vvar.h   |   5 ++
>  arch/x86/kernel/Makefile  |   1 +
>  arch/x86/kernel/hpet.c|  11 ++-
>  arch/x86/kernel/setup.c   |   2 +
>  arch/x86/kernel/tsc.c |   2 -
>  arch/x86/kernel/vmlinux.lds.S |   4 -
>  arch/x86/kernel/vsyscall_64.c |  49 ---
>  arch/x86/kernel/vsyscall_gtod.c   |  93 +
>  arch/x86/mm/init_32.c |   1 +
>  arch/x86/vdso/Makefile|   6 ++
>  arch/x86/vdso/vclock_gettime.c| 108 ++--
>  arch/x86/vdso/vdso32-setup.c  |  41 ++
>  arch/x86/vdso/vdso32/vclock_gettime.c |  29 +++
>  arch/x86/vdso/vdso32/vdso32.lds.S |   3 +
>  include/linux/clocksource.h   |   1 -
>  include/linux/mm.h|   3 +
>  include/linux/seqcount.h  | 150 
> ++
>  include/linux/seqlock.h   | 145 +---
>  include/linux/time.h  |   3 +-
>  include/linux/timekeeper_internal.h   |   1 +
>  include/linux/types.h |   2 +
>  mm/mmap.c |  20 -
>  27 files changed, 457 insertions(+), 248 deletions(-)
>  create mode 100644 arch/x86/kernel/vsyscall_gtod.c
>  create mode 100644 arch/x86/vdso/vdso32/vclock_gettime.c
>  create mode 100644 include/linux/seqcount.h

Please break this up in a series with the generic changes separately first.

> diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
> index 46e24d3..74c80d4 100644
> --- a/arch/x86/include/asm/vgtod.h
> +++ b/arch/x86/include/asm/vgtod.h
> @@ -1,8 +1,8 @@
>  #ifndef _ASM_X86_VGTOD_H
>  #define _ASM_X86_VGTOD_H
>  
> -#include 
> -#include 
> +#include 
> +#include 
>  
>  struct vsyscall_gtod_data {
>   seqcount_t  seq;
> @@ -13,7 +13,7 @@ struct vsyscall_gtod_data {
>   cycle_t mask;
>   u32 mult;
>   u32 shift;
> - } clock;
> + } __attribute__((aligned(4),packed)) clock;
>  
>   /* open coded 'struct timespec' */
>   time_t  wall_time_sec;
> @@ -24,7 +24,9 @@ struct vsyscall_gtod_data {
>   struct timezone sys_tz;
>   struct timespec wall_time_coarse;
>   struct timespec monotonic_time_coarse;
> -};
> +} __attribute__((aligned(4),packed));
> +
>  extern struct vsyscall_gtod_data vsyscall_gtod_data;
>  
> +extern void map_vgtod(void);
>  #endif /* _ASM_X86_VGTOD_H */

Please use the macros from .  Also, aligned(4) raises
a huge red flag for me.  Why??

> diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
> index de656ac..1e71e6c 100644
> --- a/arch/x86/include/asm/vvar.h
> +++ b/arch/x86/include/asm/vvar.h
> @@ -17,7 +17,11 @@
>   */
>  
>  /* Base address of vvars.  This is not ABI. */
> +#ifdef CONFIG_X86_64
>  #define VVAR_ADDRESS (-10*1024*1024 - 4096)
> +#else
> +#define VVAR_ADDRESS 0xd000
> +#endif
> 

I thought we had agreed this was going to be part of the vdso and not a
fixmap?

> + struct vm_area_struct *vma = _install_special_mapping(mm,
> + __fix_to_virt(VSYSCALL_HPET) & 0x,
> + PAGE_SIZE, VM_READ|VM_EXEC|VM_IO|VM_LOCKED,
> + NULL);

This style is generally frowned upon; please separate the declaration
and the assignment.  The & 0x there also looks... "special"...
but again, see previous statement about fixed addresses.

-hpa

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

[PATCH 0/3] HID: introduce, and use, module_hid_driver

[H Hartley Sweeten]

Introduce, and use, the helper macro module_hid_driver to allow removing
the init/exit boilerplate code from the HID drivers.

H Hartley Sweeten (3):
  HID: introduce helper for hid_driver boilerplate
  HID: hid.h: remove unused hid_generic_{init,exit} prototypes
  HID: Use module_hid_driver macro

 drivers/hid/hid-a4tech.c   | 13 +
 drivers/hid/hid-apple.c| 19 +--
 drivers/hid/hid-aureal.c   | 13 +
 drivers/hid/hid-axff.c | 14 +-
 drivers/hid/hid-belkin.c   | 13 +
 drivers/hid/hid-cherry.c   | 13 +
 drivers/hid/hid-chicony.c  | 13 +
 drivers/hid/hid-cypress.c  | 13 +
 drivers/hid/hid-dr.c   | 13 +
 drivers/hid/hid-elecom.c   | 13 +
 drivers/hid/hid-emsff.c| 13 +
 drivers/hid/hid-ezkey.c| 13 +
 drivers/hid/hid-gaff.c | 13 +
 drivers/hid/hid-generic.c  | 14 +-
 drivers/hid/hid-gyration.c | 13 +
 drivers/hid/hid-holtek-kbd.c   | 13 +
 drivers/hid/hid-holtekff.c | 15 +--
 drivers/hid/hid-icade.c| 19 +--
 drivers/hid/hid-kensington.c   | 13 +
 drivers/hid/hid-keytouch.c | 13 +
 drivers/hid/hid-kye.c  | 13 +
 drivers/hid/hid-lcpower.c  | 13 +
 drivers/hid/hid-lenovo-tpkbd.c | 14 +-
 drivers/hid/hid-lg.c   | 13 +
 drivers/hid/hid-magicmouse.c   | 19 +--
 drivers/hid/hid-microsoft.c| 13 +
 drivers/hid/hid-monterey.c | 13 +
 drivers/hid/hid-multitouch.c   | 14 +-
 drivers/hid/hid-ntrig.c| 13 +
 drivers/hid/hid-ortek.c| 13 +
 drivers/hid/hid-petalynx.c | 13 +
 drivers/hid/hid-picolcd_core.c | 13 +
 drivers/hid/hid-pl.c   | 13 +
 drivers/hid/hid-primax.c   | 13 +
 drivers/hid/hid-prodikeys.c| 19 +--
 drivers/hid/hid-ps3remote.c| 13 +
 drivers/hid/hid-roccat-lua.c   | 14 +-
 drivers/hid/hid-saitek.c   | 13 +
 drivers/hid/hid-samsung.c  | 13 +
 drivers/hid/hid-sensor-hub.c   | 14 +-
 drivers/hid/hid-sjoy.c | 13 +
 drivers/hid/hid-sony.c | 13 +
 drivers/hid/hid-speedlink.c| 13 +
 drivers/hid/hid-sunplus.c  | 13 +
 drivers/hid/hid-tivo.c | 13 +
 drivers/hid/hid-tmff.c | 13 +
 drivers/hid/hid-topseed.c  | 13 +
 drivers/hid/hid-twinhan.c  | 13 +
 drivers/hid/hid-uclogic.c  | 13 +
 drivers/hid/hid-wacom.c| 18 +-
 drivers/hid/hid-waltop.c   | 13 +
 drivers/hid/hid-wiimote-core.c | 19 +--
 drivers/hid/hid-zpff.c | 13 +
 drivers/hid/hid-zydacron.c | 13 +
 include/linux/hid.h| 15 ---
 55 files changed, 66 insertions(+), 694 deletions(-)

-- 
1.8.0.2

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

[PATCH 1/3] HID: introduce helper for hid_driver boilerplate

[H Hartley Sweeten]

Introduce the module_hid_driver macro which is a convenience macro
for HID driver modules similar to module_usb_driver. It is intended
to be used by drivers with init/exit sections that do nothing but
register/unregister the HID driver.

Signed-off-by: H Hartley Sweeten 
Cc: Jiri Kosina 
---
 include/linux/hid.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/hid.h b/include/linux/hid.h
index 7330a0f..d6c71a6 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -700,6 +700,18 @@ extern int __must_check __hid_register_driver(struct 
hid_driver *,
 
 extern void hid_unregister_driver(struct hid_driver *);
 
+/**
+ * module_hid_driver() - Helper macro for registering a HID driver
+ * @__hid_driver: hid_driver struct
+ *
+ * Helper macro for HID drivers which do not do anything special in module
+ * init/exit. This eliminates a lot of boilerplate. Each module may only
+ * use this macro once, and calling it replaces module_init() and module_exit()
+ */
+#define module_hid_driver(__hid_driver) \
+   module_driver(__hid_driver, hid_register_driver, \
+ hid_unregister_driver)
+
 extern void hidinput_hid_event(struct hid_device *, struct hid_field *, struct 
hid_usage *, __s32);
 extern void hidinput_report_event(struct hid_device *hid, struct hid_report 
*report);
 extern int hidinput_connect(struct hid_device *hid, unsigned int force);
-- 
1.8.0.2

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

[PATCH 2/3] HID: hid.h: remove unused hid_generic_{init,exit} prototypes

[H Hartley Sweeten]

These functions are not defined. Remove the extern declarations.

Signed-off-by: H Hartley Sweeten 
Cc: Jiri Kosina 
---
 include/linux/hid.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/hid.h b/include/linux/hid.h
index d6c71a6..828726c 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -884,9 +884,6 @@ static inline int hid_hw_power(struct hid_device *hdev, int 
level)
 int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
int interrupt);
 
-extern int hid_generic_init(void);
-extern void hid_generic_exit(void);
-
 /* HID quirks API */
 u32 usbhid_lookup_quirk(const u16 idVendor, const u16 idProduct);
 int usbhid_quirks_init(char **quirks_param);
-- 
1.8.0.2

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

[PATCH 3/3] HID: Use module_hid_driver macro

[H Hartley Sweeten]

Use the new module_hid_driver macro in all HID drivers that have
a simple register/unregister init/exit.

This also converts the hid drivers that test for a failure of
hid_register_driver() and report the failure. Using module_hid_driver
in those drivers removes the failure message.

Signed-off-by: H Hartley Sweeten 
Cc: Jiri Kosina 
---
 drivers/hid/hid-a4tech.c   | 13 +
 drivers/hid/hid-apple.c| 19 +--
 drivers/hid/hid-aureal.c   | 13 +
 drivers/hid/hid-axff.c | 14 +-
 drivers/hid/hid-belkin.c   | 13 +
 drivers/hid/hid-cherry.c   | 13 +
 drivers/hid/hid-chicony.c  | 13 +
 drivers/hid/hid-cypress.c  | 13 +
 drivers/hid/hid-dr.c   | 13 +
 drivers/hid/hid-elecom.c   | 13 +
 drivers/hid/hid-emsff.c| 13 +
 drivers/hid/hid-ezkey.c| 13 +
 drivers/hid/hid-gaff.c | 13 +
 drivers/hid/hid-generic.c  | 14 +-
 drivers/hid/hid-gyration.c | 13 +
 drivers/hid/hid-holtek-kbd.c   | 13 +
 drivers/hid/hid-holtekff.c | 15 +--
 drivers/hid/hid-icade.c| 19 +--
 drivers/hid/hid-kensington.c   | 13 +
 drivers/hid/hid-keytouch.c | 13 +
 drivers/hid/hid-kye.c  | 13 +
 drivers/hid/hid-lcpower.c  | 13 +
 drivers/hid/hid-lenovo-tpkbd.c | 14 +-
 drivers/hid/hid-lg.c   | 13 +
 drivers/hid/hid-magicmouse.c   | 19 +--
 drivers/hid/hid-microsoft.c| 13 +
 drivers/hid/hid-monterey.c | 13 +
 drivers/hid/hid-multitouch.c   | 14 +-
 drivers/hid/hid-ntrig.c| 13 +
 drivers/hid/hid-ortek.c| 13 +
 drivers/hid/hid-petalynx.c | 13 +
 drivers/hid/hid-picolcd_core.c | 13 +
 drivers/hid/hid-pl.c   | 13 +
 drivers/hid/hid-primax.c   | 13 +
 drivers/hid/hid-prodikeys.c| 19 +--
 drivers/hid/hid-ps3remote.c| 13 +
 drivers/hid/hid-roccat-lua.c   | 14 +-
 drivers/hid/hid-saitek.c   | 13 +
 drivers/hid/hid-samsung.c  | 13 +
 drivers/hid/hid-sensor-hub.c   | 14 +-
 drivers/hid/hid-sjoy.c | 13 +
 drivers/hid/hid-sony.c | 13 +
 drivers/hid/hid-speedlink.c| 13 +
 drivers/hid/hid-sunplus.c  | 13 +
 drivers/hid/hid-tivo.c | 13 +
 drivers/hid/hid-tmff.c | 13 +
 drivers/hid/hid-topseed.c  | 13 +
 drivers/hid/hid-twinhan.c  | 13 +
 drivers/hid/hid-uclogic.c  | 13 +
 drivers/hid/hid-wacom.c| 18 +-
 drivers/hid/hid-waltop.c   | 13 +
 drivers/hid/hid-wiimote-core.c | 19 +--
 drivers/hid/hid-zpff.c | 13 +
 drivers/hid/hid-zydacron.c | 13 +
 54 files changed, 54 insertions(+), 691 deletions(-)

diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
index 0a23988..7c5507e 100644
--- a/drivers/hid/hid-a4tech.c
+++ b/drivers/hid/hid-a4tech.c
@@ -146,17 +146,6 @@ static struct hid_driver a4_driver = {
.probe = a4_probe,
.remove = a4_remove,
 };
+module_hid_driver(a4_driver);
 
-static int __init a4_init(void)
-{
-   return hid_register_driver(&a4_driver);
-}
-
-static void __exit a4_exit(void)
-{
-   hid_unregister_driver(&a4_driver);
-}
-
-module_init(a4_init);
-module_exit(a4_exit);
 MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index d0f7662..320a958 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -555,23 +555,6 @@ static struct hid_driver apple_driver = {
.input_mapping = apple_input_mapping,
.input_mapped = apple_input_mapped,
 };
+module_hid_driver(apple_driver);
 
-static int __init apple_init(void)
-{
-   int ret;
-
-   ret = hid_register_driver(&apple_driver);
-   if (ret)
-   pr_err("can't register apple driver\n");
-
-   return ret;
-}
-
-static void __exit apple_exit(void)
-{
-   hid_unregister_driver(&apple_driver);
-}
-
-module_init(apple_init);
-module_exit(apple_exit);
 MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-aureal.c b/drivers/hid/hid-aureal.c
index 7968187..340ba9d 100644
--- a/drivers/hid/hid-aureal.c
+++ b/drivers/hid/hid-aureal.c
@@ -37,17 +37,6 @@ static struct hid_driver aureal_driver = {
.id_table = aureal_devices,
.report_fixup = aureal_report_fixup,
 };
+module_hid_driver(aureal_driver);
 
-static int __init aureal_init(void)
-{
-   return hid_register_driver(&aureal_driver);
-}
-
-static void __exit aureal_exit(void)
-{
-   hid_unregister_driver(&aureal_driver);
-}
-

Re: [ 00/27] 3.7.1-stable review

[Mariusz Kozlowski]

On Fri, Dec 14, 2012 at 03:01:13PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.7.1 release.
> There are 27 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Dec 16 22:16:56 UTC 2012.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.1-rc1.gz
> and the diffstat can be found below.

Greg, would that be a problem to send these patches for review to
linux-3.7.y branch and mark them with v3.7.1-rc1 commit/tag? Is something goes
wrong there is still place to fix/revert as needed. If not do the final
commit/tag that says this is v3.7.1 [1].

It would be easier to automate things by just monitoring linux-stable
remote for new tags.

[1] linux-3.7.y is just an example here

Regards,
-- 
Mariusz Kozlowski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] char/misc.c: misc_register: Do not loop on misc_list unconditionally

[Dae S. Kim]

If the minor number is assigned dynamically, there is no need to
search for misc->minor in misc_list, since misc->minor == 
MISC_DYNAMIC_MINOR.

Signed-off-by: Dae S. Kim 
---
 drivers/char/misc.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 522136d..7b262b6 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -190,12 +190,6 @@ int misc_register(struct miscdevice * misc)
INIT_LIST_HEAD(&misc->list);
 
mutex_lock(&misc_mtx);
-   list_for_each_entry(c, &misc_list, list) {
-   if (c->minor == misc->minor) {
-   mutex_unlock(&misc_mtx);
-   return -EBUSY;
-   }
-   }
 
if (misc->minor == MISC_DYNAMIC_MINOR) {
int i = find_first_zero_bit(misc_minors, DYNAMIC_MINORS);
@@ -205,6 +199,13 @@ int misc_register(struct miscdevice * misc)
}
misc->minor = DYNAMIC_MINORS - i - 1;
set_bit(i, misc_minors);
+   } else {
+   list_for_each_entry(c, &misc_list, list) {
+   if (c->minor == misc->minor) {
+   mutex_unlock(&misc_mtx);
+   return -EBUSY;
+   }
+   }
}
 
dev = MKDEV(MISC_MAJOR, misc->minor);
-- 
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 v2 1/3] arch/tile: implement user_regset interface on tile

[Simon Marchi]

This is a basic implementation of user_regset for the tile
architecture. It reuses the basic blocks that were already there.

Signed-off-by: Simon Marchi 
---
 arch/tile/kernel/ptrace.c |   62 +
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c
index b32bc3f..222d9fc 100644
--- a/arch/tile/kernel/ptrace.c
+++ b/arch/tile/kernel/ptrace.c
@@ -19,7 +19,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
 void user_enable_single_step(struct task_struct *child)
 {
@@ -80,6 +83,65 @@ static void putregs(struct task_struct *child, struct 
pt_regs *uregs)
*regs = *uregs;
 }
 
+enum tile_regset {
+   REGSET_GPR,
+};
+
+static int tile_gpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+   struct pt_regs regs;
+
+   getregs(target, ®s);
+
+   return user_regset_copyout(&pos, &count, &kbuf, &ubuf, ®s, 0,
+  sizeof(regs));
+}
+
+static int tile_gpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+   int ret;
+   struct pt_regs regs;
+
+   ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, ®s, 0,
+sizeof(regs));
+   if (ret)
+   return ret;
+
+   putregs(target, ®s);
+
+   return 0;
+}
+
+static const struct user_regset tile_user_regset[] = {
+   [REGSET_GPR] = {
+   .core_note_type = NT_PRSTATUS,
+   .n = ELF_NGREG,
+   .size = sizeof(elf_greg_t),
+   .align = sizeof(elf_greg_t),
+   .get = tile_gpr_get,
+   .set = tile_gpr_set,
+   },
+};
+
+static const struct user_regset_view tile_user_regset_view = {
+   .name = CHIP_ARCH_NAME,
+   .e_machine = ELF_ARCH,
+   .ei_osabi = ELF_OSABI,
+   .regsets = tile_user_regset,
+   .n = ARRAY_SIZE(tile_user_regset),
+};
+
+const struct user_regset_view *task_user_regset_view(struct task_struct *task)
+{
+   return &tile_user_regset_view;
+}
+
 long arch_ptrace(struct task_struct *child, long request,
 unsigned long addr, unsigned long data)
 {
-- 
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/

[PATCH v2 2/3] arch/tile: implement arch_ptrace using user_regset on tile

[Simon Marchi]

This patch changes arch_ptrace on tile so that it uses user_regset
to implement the PTRACE_GETREGS and PTRACE_SETREGS operations.

Signed-off-by: Simon Marchi 
---
 arch/tile/kernel/ptrace.c |   15 ++-
 1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c
index 222d9fc..d11661f 100644
--- a/arch/tile/kernel/ptrace.c
+++ b/arch/tile/kernel/ptrace.c
@@ -193,18 +193,15 @@ long arch_ptrace(struct task_struct *child, long request,
break;
 
case PTRACE_GETREGS:  /* Get all registers from the child. */
-   if (copy_to_user(datap, getregs(child, ©regs),
-sizeof(struct pt_regs)) == 0) {
-   ret = 0;
-   }
+   ret = copy_regset_to_user(child, &tile_user_regset_view,
+ REGSET_GPR, 0,
+ sizeof(struct pt_regs), datap);
break;
 
case PTRACE_SETREGS:  /* Set all registers in the child. */
-   if (copy_from_user(©regs, datap,
-  sizeof(struct pt_regs)) == 0) {
-   putregs(child, ©regs);
-   ret = 0;
-   }
+   ret = copy_regset_from_user(child, &tile_user_regset_view,
+   REGSET_GPR, 0,
+   sizeof(struct pt_regs), datap);
break;
 
case PTRACE_GETFPREGS:  /* Get the child FPU state. */
-- 
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/

[PATCH v2 3/3] arch/tile: set CORE_DUMP_USE_REGSET on tile

[Simon Marchi]

Following the previous patch which adds support for user_regset, tile
can now use this feature.

Signed-off-by: Simon Marchi 
---
 arch/tile/include/asm/elf.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/tile/include/asm/elf.h b/arch/tile/include/asm/elf.h
index f8ccf08..2b43fa0 100644
--- a/arch/tile/include/asm/elf.h
+++ b/arch/tile/include/asm/elf.h
@@ -169,4 +169,6 @@ do { \
 
 #endif /* CONFIG_COMPAT */
 
+#define CORE_DUMP_USE_REGSET
+
 #endif /* _ASM_TILE_ELF_H */
-- 
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/

i915: GPU hang

[Guennadi Liakhovetski]

Hi all

Sorry, not sure what information is most appropriate here. GPU hangs from 
time to time on this laptop, typically when running firefox on 
graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6 
(squeeze), lspci

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 011f
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at fc00 (64-bit, non-prefetchable) [size=1M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915

kernel version 3.5.2 (yes, I'll try to upgrade). Sometimes also the 
X-server freezes and restarts with no errors in dmesg. Is it a known 
problem?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
[drm:i915_reset] *ERROR* Failed to reset chip.
[ cut here ]
WARNING: at drivers/gpu/drm/i915/intel_display.c:906 
intel_enable_pipe+0x16c/0x1c0 [i915]()
Hardware name: Extensa 5220   
PLL state assertion failure (expected on, current off)
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat usb_storage tun 
crypto_blkcipher aes_generic mperf cpufreq_powersave cpufreq_userspace 
cpufreq_stats i915 drm_kms_helper bnep rfcomm bluetooth crc16 fuse cryptomgr 
aead arc4 crypto_algapi rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib 
mac80211 cfg80211 uhci_hcd sg ehci_hcd tg3 sr_mod tifm_7xx1 usbcore cdrom 
coretemp snd_hda_codec_realtek pcmcia psmouse tifm_core i2c_i801 yenta_socket 
pcmcia_rsrc snd_hda_intel hwmon libphy snd_hda_codec usb_common pcmcia_core 
sdhci_pci sdhci mmc_core
Pid: 1780, comm: Xorg Not tainted 3.5.2 #32
Call Trace:
[] ? warn_slowpath_common+0x78/0xb0
[] ? intel_enable_pipe+0x16c/0x1c0 [i915]
[] ? intel_enable_pipe+0x16c/0x1c0 [i915]
[] ? warn_slowpath_fmt+0x33/0x40
[] ? intel_enable_pipe+0x16c/0x1c0 [i915]
[] ? i9xx_crtc_mode_set+0x942/0x1070 [i915]
[] ? intel_crtc_mode_set+0x5b/0x90 [i915]
[] ? drm_crtc_helper_set_mode+0x358/0x4a0 [drm_kms_helper]
[] ? intel_get_load_detect_pipe+0x22c/0x3a0 [i915]
[] ? find_get_page+0x63/0xc0
[] ? __find_get_block+0x9a/0x1e0
[] ? __find_get_block_slow+0xfa/0x1b0
[] ? intel_tv_detect+0x9b/0x460 [i915]
[] ? __getblk+0x1b/0x320
[] ? drm_get_connector_name+0x31/0x50
[] ? drm_helper_probe_single_connector_modes+0x258/0x310 
[drm_kms_helper]
[] ? drm_mode_getconnector+0x33f/0x370
[] ? drm_ioctl+0x263/0x4e0
[] ? drm_mode_getencoder+0xb0/0xb0
[] ? drm_version+0x90/0x90
[] ? do_vfs_ioctl+0x8d/0x600
[] ? fsnotify+0x196/0x2c0
[] ? alloc_fd+0xc0/0x110
[] ? vfs_write+0x107/0x150
[] ? sys_ioctl+0x3d/0x70
[] ? sysenter_do_call+0x12/0x22
---[ end trace 81ff939dea1daea3 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/27] 3.7.1-stable review

[Mariusz Kozlowski]

On Mon, Dec 17, 2012 at 02:14:06PM -0800, Greg Kroah-Hartman wrote:
> On Mon, Dec 17, 2012 at 11:07:38PM +0100, Mariusz Kozlowski wrote:
> > On Fri, Dec 14, 2012 at 03:01:13PM -0800, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.7.1 release.
> > > There are 27 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun Dec 16 22:16:56 UTC 2012.
> > > Anything received after that time might be too late.
> > > 
> > > The whole patch series can be found in one patch at:
> > >   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.1-rc1.gz
> > > and the diffstat can be found below.
> > 
> > Greg, would that be a problem to send these patches for review to
> > linux-3.7.y branch and mark them with v3.7.1-rc1 commit/tag?
> 
> Yes, it is a problem, sorry.
> 
> > Is something goes wrong there is still place to fix/revert as needed.
> > If not do the final commit/tag that says this is v3.7.1 [1].
> > 
> > It would be easier to automate things by just monitoring linux-stable
> > remote for new tags.
> 
> Automate what?

Automate builing stable -rc kernels so that the builds trigger
themselves when needed and all I have to do is install the kernel and
boot it - I do that on real hardware so this part is done manually so
far (for various reasons).

>You can just look for the patch files to show up on
> kernel.org if you wish to automate testing.

That's already done. Ugly but it works.

> Otherwise, sorry, but creating a git tree of these patches, for the -rc
> kernels, doesn't work with the current work flow.  I have to have the
> ability to remove and add patches and change patches in the middle of
> the series of patches before the final kernel release for a variety of
> reasons, all of which have come up over the years of doing these stable
> kernel releases.
> 
> In other words, I don't ever want to rebase.

Ok. Thanks for explanation.


BTW. Nothing breaks for me so far so nothing to report.
-- 
Mariusz Kozlowski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

[Yinghai Lu]

On Sun, Dec 16, 2012 at 12:50 AM, Yinghai Lu  wrote:
> On Sat, Dec 15, 2012 at 9:17 PM, Yinghai Lu  wrote:
>> On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu  wrote:
>>> On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin  wrote:
 On 12/15/2012 12:55 PM, Yinghai Lu wrote:
>
> BTW, did you look at smp boot problem with early_level4_pgt version?


 No, I have been busy with non-Linux stuff today.

>>>
>>> ok, i sorted it out. I will split it to small pieces and post them.
>>
>> I updated for-x86-boot branch with it, and it is based on
>> linus:master
>> tip:x86/mm
>> tip:x86/urgent
>> tip:x86/mm2.
>>
>> also attach 7 new ones are just added to that branch.
>>
> just updated the branch to fix compiling problem that was found by
> Fengguang's kbuild test robot.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-x86-boot

Peter, can you check that branch again?

I moved the early_trap_init after init_mem_mapping.
so for 64bit native, init_mem_mapping will setup page table for ram from blank.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/7] mm: reduce rmap overhead for ex-KSM page copies created on swap faults

[Hugh Dickins]

On Mon, 17 Dec 2012, Johannes Weiner wrote:

> When ex-KSM pages are faulted from swap cache, the fault handler is
> not capable of re-establishing anon_vma-spanning KSM pages.  In this
> case, a copy of the page is created instead, just like during a COW
> break.
> 
> These freshly made copies are known to be exclusive to the faulting
> VMA and there is no reason to go look for this page in parent and
> sibling processes during rmap operations.
> 
> Use page_add_new_anon_rmap() for these copies.  This also puts them on
> the proper LRU lists and marks them SwapBacked, so we can get rid of
> doing this ad-hoc in the KSM copy code.
> 
> Signed-off-by: Johannes Weiner 
> Reviewed-by: Rik van Riel 

Yes, that's good, thanks Hannes:
Acked-by: Hugh Dickins 

> ---
>  mm/ksm.c| 6 --
>  mm/memory.c | 5 -
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 382d930..7275c74 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -1590,13 +1590,7 @@ struct page *ksm_does_need_to_copy(struct page *page,
>  
>   SetPageDirty(new_page);
>   __SetPageUptodate(new_page);
> - SetPageSwapBacked(new_page);
>   __set_page_locked(new_page);
> -
> - if (!mlocked_vma_newpage(vma, new_page))
> - lru_cache_add_lru(new_page, LRU_ACTIVE_ANON);
> - else
> - add_page_to_unevictable_list(new_page);
>   }
>  
>   return new_page;
> diff --git a/mm/memory.c b/mm/memory.c
> index db2e9e7..7e17eb0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3020,7 +3020,10 @@ static int do_swap_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   }
>   flush_icache_page(vma, page);
>   set_pte_at(mm, address, page_table, pte);
> - do_page_add_anon_rmap(page, vma, address, exclusive);
> + if (swapcache) /* ksm created a completely new copy */
> + page_add_new_anon_rmap(page, vma, address);
> + else
> + do_page_add_anon_rmap(page, vma, address, exclusive);
>   /* It's better to call commit-charge after rmap is established */
>   mem_cgroup_commit_charge_swapin(page, ptr);
>  
> -- 
> 1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: LTSI 3.4.24-rc2 kernel now released

[Greg KH]

On Mon, Dec 17, 2012 at 02:38:53PM -0800, Greg KH wrote:
> Hi all,
> 
> I'd like to announce the LTSI 3.4.24-rc2 kernel.  It's the second -rc
> release for the LTSI 3.4 kernel, and if there's no complaints about this
> one, odds are it will be the release version.
> 
> Differences from the -rc1 release are:
>   - refreshed to be based on 3.4.24
>   - minor bugs fixed
>   - pramfs now builds properly
>   - CODEL support patches added
> 
> I'll respond to the LTSI mailing list with the patch itself attached to
> the email, hopefully I'll figure out how to upload it to the ltsi web
> site one of these days to make it easier for people to download.

The link is now working, it can be found at:

http://ltsi.linuxfoundation.org/sites/default/files/patch-3.4.24-ltsi-rc2.gz

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 4/4] block: Optionally snapshot page contents to provide stable pages during write

[Darrick J. Wong]

On Fri, Dec 14, 2012 at 06:06:50PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 6:01 PM, Darrick J. Wong
>  wrote:
> > On Fri, Dec 14, 2012 at 05:12:37PM -0800, Andy Lutomirski wrote:
> >> It survived.  I hit at least one mm bug, but I really don't think it's
> >> a problem with your code.  (I have not tried this workload on Linux
> >> 3.7 at all before.  It normally runs on 3.5.)  The box in question is
> >
> > Would you mind sending along the bug report so I can make sure?
> 
> http://marc.info/?l=linux-mm&m=135553342803210&w=2

Hm, this looks like a hugepages thing, which (afaik) doesn't touch fs code at
all.  Looks like this patchset is in the clear.

> >
> >> ext4 on LVM on dm-crypt on (hardware) RAID 5 on hpsa, which should not
> >> need stable pages.
> >>
> >> The majority of the data written (that wasn't unlinked before it was
> >> dropped from cache) was checksummed when written and verified later.
> >> Most of this data was written using mmap.  This workload hammers the
> >> vm concurrently in several threads, and it frequently stalls when
> >> stable pages are enabled, so it's probably exercising the code
> >> decently well.
> >
> > Did you observe any change in performance?
> 
> No.  But I'm comparing to 3.5 + butchery to remove stable pages.  With
> stable pages on, this workload performs terribly.  (It's a soft
> real-time thing, as you can possibly guess from my domain name, and
> various latency monitoring things go nuts when stable pages are
> active.)

Well, I guess that's good. :)

> Actually, performance appears to be improved, probably due to
> https://lkml.org/lkml/2012/12/14/14, which I tested concurrently.
> 
> >
> >> Feel free to add Tested-by: Andy Lutomirski 
> >
> > Will do!  Thanks for the testing!
> 
> My pleasure.  When these changes go in to an upstream kernel, they'll
> represent a significant reduction in how much our kernel differs from
> kernel.org's :)  Thanks for fixing this.

No problem!

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

Re: [PATCH 4/4] block: Optionally snapshot page contents to provide stable pages during write

[Darrick J. Wong]

On Mon, Dec 17, 2012 at 12:13:36AM +0800, Zheng Liu wrote:
> On Thu, Dec 13, 2012 at 12:08:11AM -0800, Darrick J. Wong wrote:
> > diff --git a/mm/bounce.c b/mm/bounce.c
> > index 0420867..fa11935 100644
> > --- a/mm/bounce.c
> > +++ b/mm/bounce.c
> > @@ -178,6 +178,38 @@ static void bounce_end_io_read_isa(struct bio *bio, 
> > int err)
> > __bounce_end_io_read(bio, isa_page_pool, err);
> >  }
> >  
> > +#ifdef CONFIG_NEED_BOUNCE_POOL
> > +static int might_snapshot_stable_page_write(struct bio **bio_orig)
> > +{
> > +   return bio_data_dir(*bio_orig) == WRITE;
> > +}
> > +
> > +static int should_snapshot_stable_pages(struct page *page, int rw)
> > +{
> > +   struct backing_dev_info *bdi;
> > +   struct address_space *mapping = page_mapping(page);
> > +
> > +   if (!mapping)
> > +   return 0;
> > +   bdi = mapping->backing_dev_info;
> > +   if (!bdi_cap_stable_pages_required(bdi))
> > +   return 0;
> > +
> > +   return mapping->host->i_sb->s_flags & MS_SNAP_STABLE &&
> > +  rw == WRITE;
> > +}
> > +#else
> > +static int might_snapshot_stable_page_write(struct bio **bio_orig)
> > +{
> > +   return 0;
> > +}
> > +
> > +static int should_snapshot_static_pages(struct page *page, int rw)
>   ^^
>   It should be _stable_.

Good catch!  Thank you!

--D
> 
> Regards,
> - Zheng
> > +{
> > +   return 0;
> > +}
> > +#endif /* CONFIG_NEED_BOUNCE_POOL */
> > +
> >  static void __blk_queue_bounce(struct request_queue *q, struct bio 
> > **bio_orig,
> >mempool_t *pool)
> >  {
> > @@ -192,7 +224,8 @@ static void __blk_queue_bounce(struct request_queue *q, 
> > struct bio **bio_orig,
> > /*
> >  * is destination page below bounce pfn?
> >  */
> > -   if (page_to_pfn(page) <= queue_bounce_pfn(q))
> > +   if (page_to_pfn(page) <= queue_bounce_pfn(q) &&
> > +   !should_snapshot_stable_pages(page, rw))
> > continue;
> >  
> > /*
> > @@ -284,7 +317,8 @@ void blk_queue_bounce(struct request_queue *q, struct 
> > bio **bio_orig)
> >  * don't waste time iterating over bio segments
> >  */
> > if (!(q->bounce_gfp & GFP_DMA)) {
> > -   if (queue_bounce_pfn(q) >= blk_max_pfn)
> > +   if (queue_bounce_pfn(q) >= blk_max_pfn &&
> > +   !might_snapshot_stable_page_write(bio_orig))
> > return;
> > pool = page_pool;
> > } else {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] arch/tile: implement user_regset interface on tilegx

[Chris Metcalf]

On 12/17/2012 5:07 PM, Simon Marchi wrote:
>> I think with this support added, we have all the prerequisites to add 
>> "select HAVE_ARCH_TRACEHOOK" under "config TILE" in arch/tile/Kconfig, so we 
>> might as well do that too.  That will enable PTRACE_GETREGSET and 
>> PTRACE_SETREGSET, as well as /proc/PID/syscall, so why not?
> This is indeed my objective ;), and it is an intermediate objective to
> add support for HAVE_SYSCALL_TRACEPOINTS. If we look at arch/Kconfig,
> just above HAVE_ARCH_TRACEHOOK, we still have
>
> TIF_SYSCALL_TRACE   calls tracehook_report_syscall_{entry,exit}
> TIF_NOTIFY_RESUME   calls tracehook_notify_resume()
> signal delivery calls tracehook_signal_handler()

I believe we do properly support TIF_SYSCALL_TRACE; see 
arch/tile/kernel/intvec_64.S.  Likewise TIF_NOTIFY_RESUME; see 
do_work_pending() in arch/tile/kernel/process.c.  And signal delivery seems to 
be handled in a platform-independent way now; see kernel/signal.c.

My only comment on the revised patch is that I believe you should #include 
, not .  Source code (.c files) doesn't seem to 
use the  prefix.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.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/

uapi header self-containing

[Thiago Macieira]

I was told that each header in include/uapi/linux should be self-contained and 
compile on its own. So I tried a quick check. I don't have patches fixing them.

First of all: include/uapi/linux/compiler.h is missing. Nothing compiles 
without that header.

Then I ran this script (zsh rules) on 9360b53:
for f in linux/**/*.h(.); do 
err=`g++ -I. -c -o /dev/null -D__EXPORTED_HEADERS__ -Wall -Wextra -xc 
$f 
2>&1` && continue
echo === $f ===
echo $err
echo
done

Here's the result:
=== linux/agpgart.h ===
linux/agpgart.h:66:2: error: unknown type name ‘size_t’
linux/agpgart.h:67:2: error: unknown type name ‘size_t’
linux/agpgart.h:68:2: error: unknown type name ‘size_t’
linux/agpgart.h:69:2: error: unknown type name ‘size_t’

=== linux/atmbr2684.h ===
In file included from linux/atmbr2684.h:6:0:
./linux/if.h:184:19: error: field ‘ifru_addr’ has incomplete type
./linux/if.h:185:19: error: field ‘ifru_dstaddr’ has incomplete type
./linux/if.h:186:19: error: field ‘ifru_broadaddr’ has incomplete type
./linux/if.h:187:19: error: field ‘ifru_netmask’ has incomplete type
./linux/if.h:188:20: error: field ‘ifru_hwaddr’ has incomplete type

=== linux/atm_zatm.h ===
linux/atm_zatm.h:39:17: error: field ‘real’ has incomplete type
linux/atm_zatm.h:40:17: error: field ‘expected’ has incomplete type

=== linux/auto_fs4.h ===
In file included from linux/auto_fs4.h:16:0:
./linux/auto_fs.h:65:12: error: ‘NAME_MAX’ undeclared here (not in a function)

=== linux/auto_fs.h ===
linux/auto_fs.h:65:12: error: ‘NAME_MAX’ undeclared here (not in a function)

=== linux/can/bcm.h ===
linux/can/bcm.h:33:17: error: field ‘ival1’ has incomplete type
linux/can/bcm.h:33:24: error: field ‘ival2’ has incomplete type

=== linux/chio.h ===
linux/chio.h:99:25: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ 
before ‘*’ token

=== linux/coda.h ===
linux/coda.h:216:2: error: unknown type name ‘u_short’
linux/coda.h:226:2: error: unknown type name ‘u_long’
linux/coda.h:227:2: error: unknown type name ‘u_long’
linux/coda.h:298:5: error: unknown type name ‘pid_t’
linux/coda.h:299:5: error: unknown type name ‘pid_t’
linux/coda.h:330:5: error: unknown type name ‘ino_t’
linux/coda.h:380:5: error: unknown type name ‘caddr_t’
linux/coda.h:540:5: error: unknown type name ‘caddr_t’
linux/coda.h:718:9: error: unknown type name ‘u_short’
linux/coda.h:719:9: error: unknown type name ‘u_short’

=== linux/coda_psdev.h ===
linux/coda_psdev.h:12:22: error: field ‘uc_chain’ has incomplete type
linux/coda_psdev.h:13:2: error: unknown type name ‘caddr_t’
linux/coda_psdev.h:14:2: error: unknown type name ‘u_short’
linux/coda_psdev.h:15:2: error: unknown type name ‘u_short’
linux/coda_psdev.h:16:2: error: unknown type name ‘u_short’
linux/coda_psdev.h:17:2: error: unknown type name ‘u_short’
linux/coda_psdev.h:19:2: error: unknown type name ‘wait_queue_head_t’

=== linux/dlm_netlink.h ===
linux/dlm_netlink.h:35:21: error: ‘DLM_RESNAME_MAXLEN’ undeclared here (not in 
a function)

=== linux/dm-log-userspace.h ===
linux/dm-log-userspace.h:402:2: error: unknown type name ‘uint64_t’
linux/dm-log-userspace.h:406:2: error: unknown type name ‘uint32_t’
linux/dm-log-userspace.h:407:2: error: unknown type name ‘int32_t’
linux/dm-log-userspace.h:409:2: error: unknown type name ‘uint32_t’
linux/dm-log-userspace.h:410:2: error: unknown type name ‘uint32_t’
linux/dm-log-userspace.h:411:2: error: unknown type name ‘uint32_t’

=== linux/elfcore.h ===
In file included from ./linux/signal.h:4:0,
 from linux/elfcore.h:5:
/usr/include/asm/signal.h:135:2: error: unknown type name ‘size_t’
linux/elfcore.h:20:1: error: unknown type name ‘elf_greg_t’
linux/elfcore.h:21:1: error: unknown type name ‘elf_gregset_t’
linux/elfcore.h:22:1: error: unknown type name ‘elf_fpregset_t’
linux/elfcore.h:23:1: error: unknown type name ‘elf_fpxregset_t’
linux/elfcore.h:51:2: error: unknown type name ‘pid_t’
linux/elfcore.h:52:2: error: unknown type name ‘pid_t’
linux/elfcore.h:53:2: error: unknown type name ‘pid_t’
linux/elfcore.h:54:2: error: unknown type name ‘pid_t’
linux/elfcore.h:62:2: error: unknown type name ‘elf_gregset_t’
linux/elfcore.h:87:2: error: unknown type name ‘pid_t’

=== linux/hdlc/ioctl.h ===
linux/hdlc/ioctl.h:73:14: error: ‘IFNAMSIZ’ undeclared here (not in a 
function)

=== linux/hsi/hsi_char.h ===
linux/hsi/hsi_char.h:51:2: error: unknown type name ‘uint32_t’
linux/hsi/hsi_char.h:52:2: error: unknown type name ‘uint32_t’
linux/hsi/hsi_char.h:53:2: error: unknown type name ‘uint32_t’
linux/hsi/hsi_char.h:57:2: error: unknown type name ‘uint32_t’
linux/hsi/hsi_char.h:58:2: error: unknown type name ‘uint32_t’
linux/hsi/hsi_char.h:59:2: error: unknown type name ‘uint32_t’
linux/hsi/hsi_char.h:60:2: error: unknown type name ‘uint32_t’

=== linux/if_arp.h ===
In file included from ./linux/netdevice.h:28:0,
 from linux/if_arp.h:26:
./linux/if.h:184:19: error: field ‘ifru_addr’ has incomplete type
./linux/if.h:185:19: err

Re: [Update][PATCH] ACPI / PCI: Set root bridge ACPI handle in advance

[Rafael J. Wysocki]

On Monday, December 17, 2012 09:24:14 AM Yinghai Lu wrote:
> On Mon, Dec 17, 2012 at 4:20 AM, Rafael J. Wysocki  wrote:
> > From: Rafael J. Wysocki 
> >
> > The ACPI handles of PCI root bridges need to be known to
> > acpi_bind_one(), so that it can create the appropriate
> > "firmware_node" and "physical_node0" files for them, but currently
> > the way it gets to know those handles is not exactly straightforward
> > (to put it lightly).
> >
> > This is how it works, roughly:
> >
> >   1. acpi_bus_scan() finds the handle of a PCI root bridge,
> >  creates a struct acpi_device object for it and passes that
> >  object to acpi_pci_root_add().
> >
> >   2. acpi_pci_root_add() creates a struct acpi_pci_root object,
> >  populates its "device" field with its argument's address
> >  (device->handle is the ACPI handle found in step 1).
> >
> >   3. The struct acpi_pci_root object created in step 2 is passed
> >  to pci_acpi_scan_root() and used to get resources that are
> >  passed to pci_create_root_bus().
> >
> >   4. pci_create_root_bus() creates a struct pci_host_bridge object
> >  and passes its "dev" member to device_register().
> >
> >   5. platform_notify(), which for systems with ACPI is set to
> >  acpi_platform_notify(), is called.
> >
> > So far, so good.  Now it starts to be "interesting".
> >
> >   6. acpi_find_bridge_device() is used to find the ACPI handle of
> >  the given device (which is the PCI root bridge) and executes
> >  acpi_pci_find_root_bridge(), among other things, for the
> >  given device object.
> >
> >   7. acpi_pci_find_root_bridge() uses the name (sic!) of the given
> >  device object to extract the segment and bus numbers of the PCI
> >  root bridge and passes them to acpi_get_pci_rootbridge_handle().
> >
> >   8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI
> >  root bridges and finds the one that matches the given segment
> >  and bus numbers.  Its handle is then used to initialize the
> >  ACPI handle of the PCI root bridge's device object by
> >  acpi_bind_one().  However, this is *exactly* the ACPI handle we
> >  started with in step 1.
> >
> > Needless to say, this is quite embarassing, but it may be avoided
> > thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be
> > initialized in advance), which makes it possible to initialize the
> > ACPI handle of a device before passing it to device_register().
> > Namely, if pci_acpi_scan_root() could easily pass the root bridge's
> > ACPI handle to pci_create_root_bus(), the latter could set the ACPI
> > handle in its struct pci_host_bridge object's "dev" member before
> > passing it to device_register() and steps 6-8 above wouldn't be
> > necessary any more.
> >
> > To make that happen I decided to repurpose the 4th argument of
> > pci_create_root_bus(), because that allowed me to avoid defining
> > additional callbacks or similar things and didn't seem to impact
> > architectures without ACPI substantially.
> >
> > All architectures using pci_create_root_bus() directly are updated
> > as needed, but only x86 and ia64 are affected as far as the behavior
> > is concerned (no one else uses ACPI).  There should be no changes in
> > behavior resulting from this on the other architectures.
> >
> > Signed-off-by: Rafael J. Wysocki 
> 
> Acked-by: Yinghai Lu 
> 
> and the ones in your acpi_scan_temp branches.

Thanks!


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

Re: [Update][PATCH] ACPI / PCI: Set root bridge ACPI handle in advance

[Rafael J. Wysocki]

On Monday, December 17, 2012 10:44:05 AM Greg Kroah-Hartman wrote:
> On Mon, Dec 17, 2012 at 01:20:15PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > The ACPI handles of PCI root bridges need to be known to
> > acpi_bind_one(), so that it can create the appropriate
> > "firmware_node" and "physical_node0" files for them, but currently
> > the way it gets to know those handles is not exactly straightforward
> > (to put it lightly).
> 
> That's just crazy, thanks for unwinding this mess, nice job.
> 
> Acked-by: Greg Kroah-Hartman 

Thanks!


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

Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

[H. Peter Anvin]

On 12/17/2012 02:47 PM, Yinghai Lu wrote:


Peter, can you check that branch again?

I moved the early_trap_init after init_mem_mapping.
so for 64bit native, init_mem_mapping will setup page table for ram from blank.



Looks better, at first glance at least.  There are a couple of 
unnecessary changes (the counter in head_64.S cannot exceed 32 bits once 
computed, so the change from %rcx to %ecx change is pointless.)


There is another bug in my patch: it either needs to mask off the NX bit 
if we are running on non-NX-enabled hardware, or it needs to not set the 
NX bit (which is mostly okay that early on, I suspect.)


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Heinz Diehl]

On 17.12.2012, Guennadi Liakhovetski wrote: 

> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm] capturing error event; look for more information in 
> /debug/dri/0/i915_error_state
> [drm:i915_reset] *ERROR* Failed to reset chip.

I have the same problem, are able to reproduce it and have bisected
it, but the commit which git --bisect identified seems not to be the
cause.

root@wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson 
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages


This is a quite nasty (3.7) regression. I have it on all of my three
machines and it drives me mad (3.6.x hangs my USB 3.0 port and 3.7 my
intel graphics).

Try to boot with "i915.i915_enable_rc6=0" and switch to SNA in your
Xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

There are tons of this "GPU hangcheck timer elapsed"
messages on the net...

Good luck!

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

[Daniel Vetter]

On Mon, Dec 17, 2012 at 11:36 PM, Guennadi Liakhovetski
 wrote:
> Sorry, not sure what information is most appropriate here. GPU hangs from
> time to time on this laptop, typically when running firefox on
> graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6
> (squeeze), lspci
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
> Subsystem: Acer Incorporated [ALI] Device 011f
> Flags: bus master, fast devsel, latency 0, IRQ 46
> Memory at fc00 (64-bit, non-prefetchable) [size=1M]
> Memory at d000 (64-bit, prefetchable) [size=256M]
> I/O ports at 1800 [size=8]
> Expansion ROM at  [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Capabilities: [d0] Power Management version 3
> Kernel driver in use: i915
>
> kernel version 3.5.2 (yes, I'll try to upgrade). Sometimes also the
> X-server freezes and restarts with no errors in dmesg. Is it a known
> problem?

Upgrading to 3.7 highly recommended, if just to get the recent pile of
gpu reset fixes - those should increase the chances that the reset
works and your system survives. Also worth testing is upgrading
userspace gfx driver components to the latest versions (mesa +
xf86-video-intel). If you still have gpu hangs with all that, please
file a bug report against DRM -> DRI/Intel and please attach the
i915_error_state from debugfs after your gpu hung).

Yours, Daniel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: i915: GPU hang

[Daniel Vetter]

On Tue, Dec 18, 2012 at 12:15 AM, Heinz Diehl  wrote:
>> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
>> [drm] capturing error event; look for more information in 
>> /debug/dri/0/i915_error_state
>> [drm:i915_reset] *ERROR* Failed to reset chip.
>
> I have the same problem, are able to reproduce it and have bisected
> it, but the commit which git --bisect identified seems not to be the
> cause.
>
> root@wildsau linux-git]# git bisect good
> 6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
> commit 6c085a728cf000ac1865d66f8c9b52935558b328
> Author: Chris Wilson 
> Date:   Mon Aug 20 11:40:46 2012 +0200
>
> drm/i915: Track unbound pages

Note that Guennadi is running kernel 3.5 which does not contain that
patch - generally there are billions of ways to hang your gpu, so
every gpu hang needs it's own bug (until we've analyzed the
error_state and triaged the bug taking other evidence into account).
Also, this is on a different gpu generation, so even more likely that
it's a different kind of hang.

Thanks, Daniel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] user namespace and namespace infrastructure changes for 3.8

[Eric W. Biederman]

Linus,

Please pull the for-linus git tree from:

   git://git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-linus

   HEAD: 5155040ed349950e16c093ba8e65ad534994df2a userns: Fix typo in 
description of the limitation of userns_install

   This tree is against v3.7-rc3

The embarrasing oversights that Andy found have been corrected.

While small this set of changes is very significant with respect to
containers in general and user namespaces in particular.  The user space
interface is now complete.

This set of changes adds support for unprivileged users to create user
namespaces and as a user namespace root to create other namespaces.  The
tyrrany of supporting suid root preventing unprivileged users from using
cool new kernel features is broken.

This set of changes completes the work on setns, adding support for
the pid, user, mount namespaces.

This set of changes includes a bunch of basic pid namespace
cleanups/simplifications.  Of particular significance is the rework of
the pid namespace cleanup so it no longer requires sending out tendrils
into all kinds of unexpected cleanup paths for operation.  At least one
case of broken error handling is fixed by this cleanup.

The files under /proc//ns/ have been converted from regular files
to magic symlinks which prevents incorrect caching by the VFS, ensuring
the files always refer to the namespace the process is currently using
and ensuring that the ptrace_mayaccess permission checks are always
applied.

The files under /proc//ns/ have been given stable inode numbers so
it is now possible to see if different processes share the same
namespaces.

Through the David Miller's net tree are changes to relax many of the
permission checks in the networking stack to allowing the user namespace
root to usefully use the networking stack.  Similar changes for the
mount namespace and the pid namespace are coming through my tree.

Two small changes to add user namespace support were commited here
adn in David Miller's -net tree so that I could complete the work on the
/proc//ns/ files in this tree.  

Work remains to make it safe to build user namespaces and 9p, afs,
ceph, cifs, coda, gfs2, ncpfs, nfs, nfsd, ocfs2, and xfs so the Kconfig
guard remains in place preventing that user namespaces from being built
when any of those filesystems are enabled.

Future design work remains to allow root users outside of the initial
user namespace to mount more than just /proc and /sys.

Eric W. Biederman (41):
  userns: Support autofs4 interacing with multiple user namespaces
  userns: Support fuse interacting with multiple user namespaces
  netns: Deduplicate and fix copy_net_ns when !CONFIG_NET_NS
  userns: make each net (net_ns) belong to a user_ns
  userns: On mips modify check_same_owner to use uid_eq
  procfs: Use the proc generic infrastructure for proc/self.
  procfs: Don't cache a pid in the root inode.
  pidns: Capture the user namespace and filter ns_last_pid
  pidns: Use task_active_pid_ns where appropriate
  pidns: Make the pidns proc mount/umount logic obvious.
  pidns: Don't allow new processes in a dead pid namespace.
  pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed == 1
  pidns: Deny strange cases when creating pid namespaces.
  pidns: Add setns support
  pidns: Consolidate initialzation of special init task state
  pidns: Support unsharing the pid namespace.
  vfs: Allow chroot if you have CAP_SYS_CHROOT in your user namespace
  vfs: Add setns support for the mount namespace
  vfs: Add a user namespace reference from struct mnt_namespace
  vfs: Only support slave subtrees across different user namespaces
  vfs: Allow unprivileged manipulation of the mount namespace.
  userns: Ignore suid and sgid on binaries if the uid or gid can not be 
mapped
  userns: Allow unprivileged users to create user namespaces.
  userns: Allow chown and setgid preservation
  userns: Allow setting a userns mapping to your current uid.
  userns: Allow unprivileged users to create new namespaces
  userns: Allow unprivileged use of setns.
  userns: Make create_new_namespaces take a user_ns parameter
  userns: Kill task_user_ns
  userns: Implent proc namespace operations
  userns: Implement unshare of the user namespace
  procfs: Print task uids and gids in the userns that opened the proc file
  userns: For /proc/self/{uid,gid}_map derive the lower userns from the 
struct file
  userns: Allow unprivilged mounts of proc and sysfs
  proc: Generalize proc inode allocation
  proc: Fix the namespace inode permission checks.
  proc: Usable inode numbers for the namespace file descriptors.
  Fix cap_capable to only allow owners in the parent user namespace to have 
caps.
  userns: Require CAP_SYS_ADMIN for most uses of setns.
  userns: Add a more complete capability subset test to commit_creds
  user

Re: [PATCH 4/4] block: Optionally snapshot page contents to provide stable pages during write

[Darrick J. Wong]

On Mon, Dec 17, 2012 at 11:23:59AM +0100, Jan Kara wrote:
> On Thu 13-12-12 00:08:11, Darrick J. Wong wrote:
> > Several complaints have been received regarding long file write latencies 
> > when
> > memory pages must be held stable during writeback.  Since it might not be
> > acceptable to stall programs for the entire duration of a page write (which 
> > may
> > take many milliseconds even on good hardware), enable a second strategy 
> > wherein
> > pages are snapshotted as part of submit_bio; the snapshot can be held stable
> > while writes continue.
> > 
> > This provides a band-aid to provide stable page writes on jbd without 
> > needing
> > to backport the fixed locking scheme in jbd2.  A mount option is added to 
> > ext4
> > to allow administrators to enable it there.
> > 
> > For those wondering about the ext3 bandage -- fixing the jbd locking (which 
> > was
> > done as part of ext4dev years ago) is a lot of surgery, and setting
> > PG_writeback on data pages when we actually hold the page lock dropped ext3
> > performance by nearly an order of magnitude.  If we're going to migrate 
> > iscsi
> > and raid to use stable page writes, the complaints about high latency will
> > likely return.  We might as well centralize their page snapshotting thing to
> > one place.
>   Umm, I kind of like this solution for ext3...

:)

> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index a3f8ddd..78db0e1 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -224,6 +224,16 @@ config BOUNCE
> > def_bool y
> > depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
> >  
> > +# On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will 
> > often
> > +# have more than 4GB of memory, but we don't currently use the IOTLB to 
> > present
> > +# a 32-bit address to OHCI.  So we need to use a bounce pool instead.
> > +#
> > +# We also use the bounce pool to provide stable page writes for users that
> > +# don't (or can't) afford the wait latency.
> > +config NEED_BOUNCE_POOL
> > +   bool
> > +   default y if (TILE && USB_OHCI_HCD) || (BLK_DEV_INTEGRITY && (EXT3_FS 
> > || EXT4_FS))
> > +
>   This means that NEED_BOUNCE_POOL is going to be enabled on pretty much
> any distro kernel...

I want to drop EXT4_FS from that default line.  Then we only need it in the
case where EXT4_USE_FOR_EXT23=y hasn't taken the place of EXT3_FS=y.

 Has anyone actually done that?

Heh, even *I* haven't done that.

> >  config NR_QUICK
> > int
> > depends on QUICKLIST
> > diff --git a/mm/bounce.c b/mm/bounce.c
> > index 0420867..fa11935 100644
> > --- a/mm/bounce.c
> > +++ b/mm/bounce.c
> > @@ -178,6 +178,38 @@ static void bounce_end_io_read_isa(struct bio *bio, 
> > int err)
> > __bounce_end_io_read(bio, isa_page_pool, err);
> >  }
> >  
> > +#ifdef CONFIG_NEED_BOUNCE_POOL
> > +static int might_snapshot_stable_page_write(struct bio **bio_orig)
> > +{
> > +   return bio_data_dir(*bio_orig) == WRITE;
> > +}
> ... so might might_snapshot_stable_page_write() will be true for each
> write. And thus blk_queue_bounce() becomes considerably more expensive?
> Also calling should_snapshot_stable_pages() for every page seems to be
> stupid since its result is going to be the same for all the pages in the
> bio (well, I could imagine setups where it won't be but do we want to
> support them?).
> 
> So cannot we just make a function like should_snapshot_stable_pages() to
> test whether we really need the bouncing, use it in blk_queue_bounce() and
> then pass the information to __blk_queue_bounce() if needed?

Yes.  I'd actually considered simply calling should_snapshot() on the first
bio_vec page and passing that information through, but thought I should play it
safe for the first revision.

However, a bio targets a single block device, so this seems like a safe
optimization.

--D
> 
>   Honza
> 
> > +static int should_snapshot_stable_pages(struct page *page, int rw)
> > +{
> > +   struct backing_dev_info *bdi;
> > +   struct address_space *mapping = page_mapping(page);
> > +
> > +   if (!mapping)
> > +   return 0;
> > +   bdi = mapping->backing_dev_info;
> > +   if (!bdi_cap_stable_pages_required(bdi))
> > +   return 0;
> > +
> > +   return mapping->host->i_sb->s_flags & MS_SNAP_STABLE &&
> > +  rw == WRITE;
> > +}
> > +#else
> > +static int might_snapshot_stable_page_write(struct bio **bio_orig)
> > +{
> > +   return 0;
> > +}
> > +
> > +static int should_snapshot_static_pages(struct page *page, int rw)
> > +{
> > +   return 0;
> > +}
> > +#endif /* CONFIG_NEED_BOUNCE_POOL */
> > +
> >  static void __blk_queue_bounce(struct request_queue *q, struct bio 
> > **bio_orig,
> >mempool_t *pool)
> >  {
> > @@ -192,7 +224,8 @@ static void __blk_queue_bounce(struct request_queue *q, 
> > struct bio **bio_orig,
> > /*
> >  * is destination page below bounce pfn?
> >  */
> > -   if (pag

[PATCH] [stable-resend] regulator: core: if voltage scaling fails, restore original voltage values

[Paolo Pisati]

Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Pisati 
Tested-by: Robert Nelson 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
 {
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
+   int old_min_uV, old_max_uV;
 
mutex_lock(&rdev->mutex);
 
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, &min_uV, &max_uV);
if (ret < 0)
goto out;
+   
+   /* restore original values in case of error */
+   old_min_uV = regulator->min_uV;
+   old_max_uV = regulator->max_uV;
regulator->min_uV = min_uV;
regulator->max_uV = max_uV;
 
ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
if (ret < 0)
-   goto out;
+   goto out2;
 
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+   if (ret < 0)
+   goto out2;
+   
 out:
mutex_unlock(&rdev->mutex);
return ret;
+out2:
+   regulator->min_uV = old_min_uV;
+   regulator->max_uV = old_max_uV;
+   mutex_unlock(&rdev->mutex);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_voltage);
 
-- 
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/

[Update 2][PATCH] ACPI / PCI: Set root bridge ACPI handle in advance

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The ACPI handles of PCI root bridges need to be known to
acpi_bind_one(), so that it can create the appropriate
"firmware_node" and "physical_node" files for them, but currently
the way it gets to know those handles is not exactly straightforward
(to put it lightly).

This is how it works, roughly:

  1. acpi_bus_scan() finds the handle of a PCI root bridge,
 creates a struct acpi_device object for it and passes that
 object to acpi_pci_root_add().

  2. acpi_pci_root_add() creates a struct acpi_pci_root object,
 populates its "device" field with its argument's address
 (device->handle is the ACPI handle found in step 1).

  3. The struct acpi_pci_root object created in step 2 is passed
 to pci_acpi_scan_root() and used to get resources that are
 passed to pci_create_root_bus().

  4. pci_create_root_bus() creates a struct pci_host_bridge object
 and passes its "dev" member to device_register().

  5. platform_notify(), which for systems with ACPI is set to
 acpi_platform_notify(), is called.

So far, so good.  Now it starts to be "interesting".

  6. acpi_find_bridge_device() is used to find the ACPI handle of
 the given device (which is the PCI root bridge) and executes
 acpi_pci_find_root_bridge(), among other things, for the
 given device object.

  7. acpi_pci_find_root_bridge() uses the name (sic!) of the given
 device object to extract the segment and bus numbers of the PCI
 root bridge and passes them to acpi_get_pci_rootbridge_handle().

  8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI
 root bridges and finds the one that matches the given segment
 and bus numbers.  Its handle is then used to initialize the
 ACPI handle of the PCI root bridge's device object by
 acpi_bind_one().  However, this is *exactly* the ACPI handle we
 started with in step 1.

Needless to say, this is quite embarassing, but it may be avoided
thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be
initialized in advance), which makes it possible to initialize the
ACPI handle of a device before passing it to device_register().

Accordingly, make pci_acpi_scan_root() pass the root bridge's ACPI
handle to pci_create_root_bus() and make the latter set the ACPI
handle in its struct pci_host_bridge object's "dev" member before
passing it to device_register(), so that steps 6-8 above aren't
necessary any more.

To implement that, I decided to repurpose the 4th argument of
pci_create_root_bus(), because that allowed me to avoid defining
additional callbacks or similar things and didn't seem to impact
architectures without ACPI substantially.

All architectures using pci_create_root_bus() directly are updated
as needed, but only x86 and ia64 are affected as far as the behavior
is concerned (no one else uses ACPI).  There should be no changes in
behavior resulting from this on the other architectures.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Yinghai Lu 
Acked-by: Greg Kroah-Hartman 
Acked-by: H. Peter Anvin 
---

Peter Anvin pointed out to me that it's better to make it clear in the
changelog what the patch actually does versus what might be left as future
work, so here's another update with a slightly modified (and hopefully better)
changelog.  The patch itself hasn't been changed.

Thanks,
Rafael

---
 arch/ia64/pci/pci.c  |5 -
 arch/powerpc/kernel/pci-common.c |3 ++-
 arch/s390/pci/pci.c  |3 ++-
 arch/sparc/kernel/pci.c  |3 ++-
 arch/x86/pci/acpi.c  |5 -
 drivers/acpi/pci_root.c  |   18 --
 drivers/pci/pci-acpi.c   |   19 ---
 drivers/pci/probe.c  |   17 -
 include/acpi/acpi_bus.h  |1 -
 include/linux/pci.h  |9 -
 10 files changed, 34 insertions(+), 49 deletions(-)

Index: linux-pm/arch/x86/pci/acpi.c
===
--- linux-pm.orig/arch/x86/pci/acpi.c
+++ linux-pm/arch/x86/pci/acpi.c
@@ -483,6 +483,7 @@ struct pci_bus * __devinit pci_acpi_scan
LIST_HEAD(resources);
struct pci_bus *bus = NULL;
struct pci_sysdata *sd;
+   struct pci_root_sys_info si;
int node;
 #ifdef CONFIG_ACPI_NUMA
int pxm;
@@ -522,6 +523,8 @@ struct pci_bus * __devinit pci_acpi_scan
sd = &info->sd;
sd->domain = domain;
sd->node = node;
+   si.acpi_node.handle = device->handle;
+   si.sysdata = sd;
/*
 * Maybe the desired pci bus has been already scanned. In such case
 * it is unnecessary to scan the pci bus with the given domain,busnum.
@@ -553,7 +556,7 @@ struct pci_bus * __devinit pci_acpi_scan
if (!setup_mcfg_map(info, domain, (u8)root->secondary.start,
(u8)root->secondary.end, root->mcfg_addr))
bus = pci_create_root_bus(NU

Re: [regression] cpuidle_get_cpu_driver livelocks idle system

[Rafael J. Wysocki]

On Monday, December 17, 2012 10:59:09 PM Daniel Lezcano wrote:
> On 12/17/2012 08:36 PM, Russ Anderson wrote:
> > The 3.7 kernel grinds to a halt on boot of a system with
> > 2048 cpus.  NMI showed most of the cpus in
> > _raw_spin_lock in cpuidle_get_cpu_driver().  (backtrace below)
> > 
> > A quick look at cpuidle_get_cpu_driver() shows the hot lock.
> > 
> > In drivers/cpuidle/driver.c:
> > 
> > /**
> >  * cpuidle_get_cpu_driver - return the driver tied with a cpu
> >  */
> > struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
> > {
> > struct cpuidle_driver *drv;
> > 
> > if (!dev)
> > return NULL;
> > 
> > spin_lock(&cpuidle_driver_lock);
> > drv = __cpuidle_get_cpu_driver(dev->cpu);
> > spin_unlock(&cpuidle_driver_lock);
> > 
> > return drv;
> > }
> > 
> 
> Hi Russ,
> 
> thanks for investigating the problem. You are right, there is a
> bottleneck here.
> 
> Regarding how is used the cpuidle code, I think it is safe to remove the
> locks.

OK, a patch would be appreciated. :-)

If you prepare one, please explain in the changelog why it is safe to drop the
locks.

Thanks,
Rafael


> > This change was added in on Nov 14th, 2012.
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92
> > 
> > The patch says it adds support for cpus with different characteristics,
> > but adds a big global lock.  The comment claims "no impact for the other
> > platforms if the option is disabled", which leads me to believe the
> > spin_lock was added inadvertently.  CPU_IDLE_MULTIPLE_DRIVERS is off
> > in my config file.
> > 
> > linux$ grep CPU_IDLE_MULTIPLE_DRIVERS .config
> > # CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
> > 
> > As more cpus become idle, more cpus fight over the lock until
> > the system livelocks on the crushing weight of idle.
> > 
> > The fix may be to move the spin_lock into __cpuidle_get_cpu_driver,
> > which has different versions for CONFIG_CPU_IDLE_MULTIPLE_DRIVERS,
> > to avoid impacting the disabled case, or get rid of the spin_lock
> > all together.
> > 
> > 
> > 
> > == UV NMI process trace cpu 12: ==
> > CPU 12
> > Pid: 0, comm: swapper/12 Tainted: G   O 3.7.0.rja-sgi+ #38
> > RIP: 0010:[]  [] 
> > _raw_spin_lock+0x25/0x30
> > [...]
> > Call Trace:
> >  [] cpuidle_get_cpu_driver+0x1c/0x30
> >  [] cpuidle_idle_call+0x7d/0x1b0
> >  [] cpu_idle+0xdd/0x130
> >  [] start_secondary+0xc6/0xcc
> > 
> > 
> 
> 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Resend][PATCH] PM: Move disabling/enabling runtime PM to late suspend/early resume

[Rafael J. Wysocki]

On Monday, December 17, 2012 10:18:14 PM Ulf Hansson wrote:
> On 16 December 2012 16:29, Alan Stern  wrote:
> > On Sun, 16 Dec 2012, Rafael J. Wysocki wrote:
> >
> >> On Saturday, December 15, 2012 10:16:29 PM Jiri Kosina wrote:
> >> > On Sat, 15 Dec 2012, Rafael J. Wysocki wrote:
> >> >
> >> > > From: Rafael J. Wysocki 
> >> > >
> >> > > Currently, the PM core disables runtime PM for all devices right
> >> > > after executing subsystem/driver .suspend() callbacks for them
> >> > > and re-enables it right before executing subsystem/driver .resume()
> >> > > callbacks for them.  This may lead to problems when there are
> >> > > two devices such that the .suspend() callback executed for one of
> >> > > them depends on runtime PM working for the other.  In that case,
> >> > > if runtime PM has already been disabled for the second device,
> >> > > the first one's .suspend() won't work correctly (and analogously
> >> > > for resume).
> >> > >
> >> > > To make those issues go away, make the PM core disable runtime PM
> >> > > for devices right before executing subsystem/driver .suspend_late()
> >> > > callbacks for them and enable runtime PM for them right after
> >> > > executing subsystem/driver .resume_early() callbacks for them.  This
> >> > > way the potential conflitcs between .suspend_late()/.resume_early()
> >> > > and their runtime PM counterparts are still prevented from happening,
> >> > > but the subtle ordering issues related to disabling/enabling runtime
> >> > > PM for devices during system suspend/resume are much easier to avoid.
> >> > >
> >> > > Reported-and-tested-by: Jan-Matthias Braun 
> >> > > Signed-off-by: Rafael J. Wysocki 
> >> >
> >> > Hi Rafael,
> >> >
> >> > just curious what is the reason for resend? Do you want to gather more
> >> > Acks before pushing this upstream?
> >>
> >> Well, I thought that some people might actually look at it when they found 
> >> it
> >> again in their mailboxes. :-)
> >
> > I did look at it the first time it appeared.  It seemed to be okay, but
> > I haven't tried any testing.
> >
> > Alan Stern
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> I believe this should work fine for ux500 platforms, so:
> 
> Reviewed-by: Ulf Hansson 

Thanks!


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

RE: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit

[Yu, Fenghua]

> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Sunday, December 16, 2012 4:42 PM
> To: Yu, Fenghua
> Cc: H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86
> Subject: Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-
> bit
> 
> On Sun, Dec 16, 2012 at 3:59 PM, Yu, Fenghua 
> wrote:
> >
> >> it has to be rebased after #PF handler version. otherwise it can not
> >> handle for framdisk
> >> that is loaded after 1G.
> >>
> >> Fenghua,
> >>
> >> can you post your boot log with 64bit with your patch?
> >>
> >> Yinghai
> >
> > Attached is dmesg with the patches.
> >
> 
> yes, your laptop only have 1G ram, and
> 
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009d7ff]
> usable
> [0.00] BIOS-e820: [mem 0x0009d800-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff]
> reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f]
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0x3e6a]
> usable
> [0.00] BIOS-e820: [mem 0x3e6b-0x3e6ccfff]
> ACPI data
> [0.00] BIOS-e820: [mem 0x3e6cd000-0x3e6f]
> ACPI NVS
> [0.00] BIOS-e820: [mem 0x3e70-0x3eff]
> reserved
> [0.00] BIOS-e820: [mem 0xf000-0xf3ff]
> reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec0]
> reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff]
> reserved
> [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff]
> reserved
> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8]
> reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff]
> reserved
> [0.00] BIOS-e820: [mem 0xff00-0x]
> reserved
> 
> ramdisk is at
>  RAMDISK: [mem 0x27608000-0x2fafbfff]
> 
> and current kernel default set 1G to kernel mapping. so it happens to
> work with your patchset.
> 
> please find one sytem with 4G or more to test it.
> 
> and you may need to rebase your patches on top of my for-x86-boot
> branch with working
> #PF handler set page table patch.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-x86-boot
> 
> Thanks
> 
> Yinghai

OSV may need the patchset based on old kernel. So I'll have the patchset ready. 
Is this the right place to call load_ucode_bsp() in the upstream kernel?

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index a512f56..e94b90e 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -93,6 +88,11 @@ void __init x86_64_start_kernel(char * real_mode_data)
}
load_idt((const struct desc_ptr *)&idt_descr);

+   /*
+* Load microcode early on BSP.
+*/
+   load_ucode_bsp(__va(real_mode_data));
+
if (console_loglevel == 10)
early_printk("Kernel alive\n");

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Please pull powerpc.git next branch

[Benjamin Herrenschmidt]

On Sat, 2012-12-15 at 07:44 +1100, Benjamin Herrenschmidt wrote:
> Hi Linus !
> 
> Finally managed to get my head away from some other distractions
> to put this pull request together, sorry for the lateness :-)
> 
> The main highlight is probably some base POWER8 support. There's
> more to come such as transactional memory support but that will
> wait for the next one. (next merge window)
> 
> Overall it's pretty quiet, or rather I've been pretty poor at
> picking things up from patchwork and reviewing them this time
> around and Kumar no better on the FSL side it seems...

So it looks like I'm an idiot and totally failed to put your email
address on the CC list of that pull request :-)

This is an updated version with Anatolij 52xx which I hadn't merged back
then but have now (it's all be in -next for a while).

Cheers,
Ben.

The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3:

  Linux 3.7-rc8 (2012-12-03 11:22:37 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next

for you to fetch changes up to 376bddd34433065aeb9b9a140870537feecf90ef:

  Merge remote-tracking branch 'agust/next' into next (2012-12-18 10:22:27 
+1100)



Akinobu Mita (3):
  powerpc/iommu: Use bitmap library
  powerpc: Remove BITOP_MASK and BITOP_WORD from asm/bitops.h
  powerpc: Use asm-generic/bitops/le.h

Andreas Schwab (1):
  powerpc/powermac/cpufreq_32: Set non-infinite transition time for 7447A 
driver

Anton Blanchard (3):
  powerpc: Move most of setup.h out of uapi
  powerpc: Remove stale function prototypes from setup.h
  powerpc: Fix CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n build

Aravinda Prasad (1):
  powerpc/ptrace: Enable hardware breakpoint upon re-registering

Benjamin Herrenschmidt (6):
  powerpc/powernv: Fix OPAL debug entry
  Merge branch 'dt' into next
  Merge branch 'merge' into next
  Merge remote-tracking branch 'kumar/next' into next
  powerpc+of: Rename and fix OF reconfig notifier error inject module
  Merge remote-tracking branch 'agust/next' into next

Dan Horák (1):
  fbdev: Add GXT4000P and GXT6500P support to the gxt4500 driver

Gavin Shan (1):
  powerpc/pnv: Avoid bogus output

Ian Munsie (5):
  powerpc: Add set_mode hcall
  powerpc: Add wrappers to enable/disable relocation on exceptions
  powerpc: Move get_longbusy_msecs into hvcall.h and remove duplicate 
function
  powerpc: Enable relocation on during exceptions at boot
  powerpc: Disable relocation on exceptions when kexecing

Jia Hongtao (1):
  powerpc/fsl-pci: Add PCI controller ATMU PM support

JoonSoo Kim (1):
  powerpc: Change free_bootmem() to kfree()

Julia Lawall (1):
  powerpc/rtas_flash: Eliminate possible double free

K.Prasad (1):
  powerpc/hw-breakpoint: Use generic hw-breakpoint interfaces for new PPC 
ptrace flags

Li Zhong (1):
  powerpc: Fix MAX_STACK_TRACE_ENTRIES too low warning !

Matthew McClintock (1):
  powerpc: dtc is required to build dtb files

Michael Ellerman (12):
  powerpc/udbg: Remove unused udbg_read()
  powerpc/xmon: Remove unused xmon_expect() & xmon_read_poll()
  powerpc/xmon: Remove empty xmon_map_scc()
  powerpc/xmon: Make xmon_getchar() static
  powerpc/xmon: Merge start.c into nonstdio.c
  powerpc/xmon: Remove renaming #defines of scanhex() and skipbl()
  powerpc/xmon: Remove unused #defines
  powerpc/xmon: Use STACK_FRAME_OVERHEAD in xmon_show_stack()
  powerpc/xmon: Fiddle xmon_depth_to_print logic in xmon_show_stack()
  powerpc/xmon: Fallback to printk() in xmon_printf() if udbg is not setup
  powerpc: Remove no longer used ppc_md.idle_loop()
  powerpc/perf: Add missing L2 constraint handling in Power7 PMU

Michael Neuling (16):
  powerpc/ptrace: Fix spelling mistake
  powerpc/ptrace: Remove unused addr parameter in ppc_del_hwdebug()
  powerpc: make POWER7 setup code name generic
  powerpc: Add POWER8 setup code
  powerpc: POWER8 cputable entry
  powerpc: Fix denorm symbol name
  powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8
  powerpc: Add POWER8 architected mode to cputable
  powerpc: Whitespace changes in exception64s.S
  powerpc: Remove unessessary 0x3000 location enforcement
  powerpc: Make load_hander handle upto 64k offset
  powerpc: Turn syscall handler into macros
  powerpc: Add new macros needed for relocation on exceptions
  powerpc: Add relocation on exception vector handlers
  powerpc: Move initial mfspr LPCR out of __init_LPCR
  powerpc: Setup relocation on exceptions for bare metal systems

Nathan Fontenot (6):
  powerpc+of: Add /proc device tree updating to of node add/remove
  powerpc+of: Move of_drconf_cell struct definition to asm/prom.h
  powerpc+of: Add of node/property notification chain f

Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit

[Yinghai Lu]

On Mon, Dec 17, 2012 at 3:30 PM, Yu, Fenghua  wrote:
>
> OSV may need the patchset based on old kernel. So I'll have the patchset 
> ready. Is this the right place to call load_ucode_bsp() in the upstream 
> kernel?
>
> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> index a512f56..e94b90e 100644
> --- a/arch/x86/kernel/head64.c
> +++ b/arch/x86/kernel/head64.c
> @@ -93,6 +88,11 @@ void __init x86_64_start_kernel(char * real_mode_data)
> }
> load_idt((const struct desc_ptr *)&idt_descr);
>
> +   /*
> +* Load microcode early on BSP.
> +*/
> +   load_ucode_bsp(__va(real_mode_data));
> +
> if (console_loglevel == 10)
> early_printk("Kernel alive\n");
>
it has to be after #PF handler set page table patch...

otherwise when ramdisk is above 1G, customer will get early PF exception.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

[Yinghai Lu]

On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin  wrote:
> On 12/17/2012 02:47 PM, Yinghai Lu wrote:
>>
>>
>> Peter, can you check that branch again?
>>
>> I moved the early_trap_init after init_mem_mapping.
>> so for 64bit native, init_mem_mapping will setup page table for ram from
>> blank.
>>
>
> Looks better, at first glance at least.  There are a couple of unnecessary
> changes (the counter in head_64.S cannot exceed 32 bits once computed, so
> the change from %rcx to %ecx change is pointless.)

ok,  return to use %ecx

>
> There is another bug in my patch: it either needs to mask off the NX bit if
> we are running on non-NX-enabled hardware, or it needs to not set the NX bit
> (which is mostly okay that early on, I suspect.)

i test that in kvm guest, and westmere, current version seem ok.

will repost the patchset to list to get more review.

:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [RFC] dma-buf: implement vmap refcounting in the interface logic

[Daniel Vetter]

All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.

To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.

Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.

v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.

Cc: Aaron Plattner 
Signed-off-by: Daniel Vetter 
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.

Cheers, Daniel
---
 Documentation/dma-buf-sharing.txt |  6 +-
 drivers/base/dma-buf.c| 42 ++-
 include/linux/dma-buf.h   |  4 +++-
 3 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three 
steps:
   void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 
The vmap call can fail if there is no vmap support in the exporter, or if it
-   runs out of vmalloc space. Fallback to kmap should be implemented.
+   runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+   the dma-buf layer keeps a reference count for all vmap access and calls down
+   into the exporter's vmap function only when no vmapping exists, and only
+   unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+   by taking the dma_buf->lock mutex.
 
 3. Finish access
 
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..36af5de 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 
dmabuf = file->private_data;
 
+   BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
  */
 void *dma_buf_vmap(struct dma_buf *dmabuf)
 {
+   void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
 
-   if (dmabuf->ops->vmap)
-   return dmabuf->ops->vmap(dmabuf);
-   return NULL;
+   if (!dmabuf->ops->vmap)
+   return NULL;
+
+   mutex_lock(&dmabuf->lock);
+   if (dmabuf->vmapping_counter) {
+   dmabuf->vmapping_counter++;
+   BUG_ON(!dmabuf->vmap_ptr);
+   ptr = dmabuf->vmap_ptr;
+   goto out_unlock;
+   }
+
+   BUG_ON(dmabuf->vmap_ptr);
+
+   ptr = dmabuf->ops->vmap(dmabuf);
+   if (IS_ERR_OR_NULL(ptr))
+   goto out_unlock;
+
+   dmabuf->vmap_ptr = ptr;
+   dmabuf->vmapping_counter = 1;
+
+out_unlock:
+   mutex_unlock(&dmabuf->lock);
+   return ptr;
 }
 EXPORT_SYMBOL_GPL(dma_buf_vmap);
 
@@ -501,7 +525,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
 
-   if (dmabuf->ops->vunmap)
-   dmabuf->ops->vunmap(dmabuf, vaddr);
+   BUG_ON(!dmabuf->vmap_ptr);
+   BUG_ON(dmabuf->vmapping_counter > 0);
+
+   mutex_lock(&dmabuf->lock);
+   if (--dmabuf->vmapping_counter == 0) {
+   if (dmabuf->ops->vunmap)
+   dmabuf->ops->vunmap(dmabuf, vaddr);
+   dmabuf->vmap_ptr = NULL;
+   }
+   mutex_unlock(&dmabuf->lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
-   /* mutex to serialize list manipulation and attach/detach */
+   /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+   unsigned vmapping_counter;
+   void *vmap_ptr;
void *priv;
 };
 
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [RFC] dma-buf: implement vmap refcounting in the interface logic

[Daniel Vetter]

All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.

To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.

Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.

v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.

v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping.  Suggested by Chris Wilson.

Cc: Aaron Plattner 
Signed-off-by: Daniel Vetter 
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.

Cheers, Daniel
---
 Documentation/dma-buf-sharing.txt |  6 +-
 drivers/base/dma-buf.c| 43 ++-
 include/linux/dma-buf.h   |  4 +++-
 3 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three 
steps:
   void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 
The vmap call can fail if there is no vmap support in the exporter, or if it
-   runs out of vmalloc space. Fallback to kmap should be implemented.
+   runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+   the dma-buf layer keeps a reference count for all vmap access and calls down
+   into the exporter's vmap function only when no vmapping exists, and only
+   unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+   by taking the dma_buf->lock mutex.
 
 3. Finish access
 
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..67d3cd5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 
dmabuf = file->private_data;
 
+   BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
  */
 void *dma_buf_vmap(struct dma_buf *dmabuf)
 {
+   void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
 
-   if (dmabuf->ops->vmap)
-   return dmabuf->ops->vmap(dmabuf);
-   return NULL;
+   if (!dmabuf->ops->vmap)
+   return NULL;
+
+   mutex_lock(&dmabuf->lock);
+   if (dmabuf->vmapping_counter) {
+   dmabuf->vmapping_counter++;
+   BUG_ON(!dmabuf->vmap_ptr);
+   ptr = dmabuf->vmap_ptr;
+   goto out_unlock;
+   }
+
+   BUG_ON(dmabuf->vmap_ptr);
+
+   ptr = dmabuf->ops->vmap(dmabuf);
+   if (IS_ERR_OR_NULL(ptr))
+   goto out_unlock;
+
+   dmabuf->vmap_ptr = ptr;
+   dmabuf->vmapping_counter = 1;
+
+out_unlock:
+   mutex_unlock(&dmabuf->lock);
+   return ptr;
 }
 EXPORT_SYMBOL_GPL(dma_buf_vmap);
 
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
 
-   if (dmabuf->ops->vunmap)
-   dmabuf->ops->vunmap(dmabuf, vaddr);
+   BUG_ON(!dmabuf->vmap_ptr);
+   BUG_ON(dmabuf->vmapping_counter > 0);
+   BUG_ON(dmabuf->vmap_ptr != vaddr);
+
+   mutex_lock(&dmabuf->lock);
+   if (--dmabuf->vmapping_counter == 0) {
+   if (dmabuf->ops->vunmap)
+   dmabuf->ops->vunmap(dmabuf, vaddr);
+   dmabuf->vmap_ptr = NULL;
+   }
+   mutex_unlock(&dmabuf->lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
-   /* mutex to serialize list manipulation and attach/detach */
+   /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+   unsigned vmapping_counter;
+   void *vmap_ptr;
void *priv;
 };
 
-- 
1.7.11.7

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

Re: [PATCH 152/241] mm: vmscan: fix endless loop in kswapd balancing

[Johannes Weiner]

On Sat, Dec 15, 2012 at 07:56:51PM +, Ben Hutchings wrote:
> On Thu, 2012-12-13 at 11:58 -0200, Herton Ronaldo Krzesinski wrote:
> > 3.5.7.2 -stable review patch.  If anyone has any objections, please let me 
> > know.
> > 
> > --
> > 
> > From: Johannes Weiner 
> > 
> > commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.
> [...]
> 
> Greg, you missed this in 3.{0,4}.y.  I'm attaching the version I used
> for 3.2.y, which seems to be applicable to 3.0.y.  One or other of these
> should work for 3.4.y.

Please don't put this in anything earlier than 3.4 as this was the
first version that exhibited the problem.

I apologize for letting it slip into 3.2; a result of failing to
properly mention the origin of the problem in the changelog, tagging
it stable for 3.4+, and noticing the email proposing it for 3.2.  Time
for vacation, I guess... :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 rev.2 1/6] ACPI: Separate adding ACPI device objects from probing ACPI drivers

[Toshi Kani]

On Thu, 2012-12-13 at 23:17 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 

(snip)

>  struct acpi_device_ops {
> Index: linux/drivers/acpi/scan.c
> ===
> --- linux.orig/drivers/acpi/scan.c
> +++ linux/drivers/acpi/scan.c
> @@ -494,7 +494,8 @@ static int acpi_bus_match(struct device
>   struct acpi_device *acpi_dev = to_acpi_device(dev);
>   struct acpi_driver *acpi_drv = to_acpi_driver(drv);
>  
> - return !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
> + return acpi_dev->bus_ops.acpi_op_match
> + && !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
>  }
>  
>  static int acpi_device_uevent(struct device *dev, struct kobj_uevent_env 
> *env)
> @@ -1418,6 +1419,17 @@ static int acpi_bus_remove(struct acpi_d
>   return 0;
>  }
>  
> +/*
> + * acpi_hot_add_bind - Bind _ADR-based devices on hot-add.
> + * @device: ACPI device node to bind.
> + */
> +static void acpi_hot_add_bind(struct acpi_device *device)
> +{
> + if (device->flags.bus_address
> + && device->parent && device->parent->ops.bind)
> + device->parent->ops.bind(device);
> +}
> +
>  static int acpi_add_single_object(struct acpi_device **child,
> acpi_handle handle, int type,
> unsigned long long sta,
> @@ -1490,13 +1502,8 @@ static int acpi_add_single_object(struct
>  
>   result = acpi_device_register(device);
>  
> - /*
> -  * Bind _ADR-Based Devices when hot add
> -  */
> - if (device->flags.bus_address) {
> - if (device->parent && device->parent->ops.bind)
> - device->parent->ops.bind(device);
> - }

I think the original code above is hot-add only because ops.bind is not
set at boot since the acpi_pci driver has not been registered yet.  It
seems that acpi_pci_bridge_scan() called from acpi_pci_root_add() takes
care of the binding.

This brings me a question for acpi_bus_probe_start() below...


> + if (device->bus_ops.acpi_op_match)
> + acpi_hot_add_bind(device);
>  
>  end:
>   if (!result) {
> @@ -1522,6 +1529,7 @@ static void acpi_bus_add_power_resource(
>   struct acpi_bus_ops ops = {
>   .acpi_op_add = 1,
>   .acpi_op_start = 1,
> + .acpi_op_match = 1,
>   };
>   struct acpi_device *device = NULL;
>  
> @@ -1574,9 +1582,9 @@ static acpi_status acpi_bus_check_add(ac
> void *context, void **return_value)
>  {
>   struct acpi_bus_ops *ops = context;
> + struct acpi_device *device = NULL;
>   int type;
>   unsigned long long sta;
> - struct acpi_device *device;
>   acpi_status status;
>   int result;
>  
> @@ -1596,52 +1604,86 @@ static acpi_status acpi_bus_check_add(ac
>   return AE_CTRL_DEPTH;
>   }
>  
> - /*
> -  * We may already have an acpi_device from a previous enumeration.  If
> -  * so, we needn't add it again, but we may still have to start it.
> -  */
> - device = NULL;
>   acpi_bus_get_device(handle, &device);
>   if (ops->acpi_op_add && !device) {
> - acpi_add_single_object(&device, handle, type, sta, ops);
> - /* Is the device a known good platform device? */
> - if (device
> - && !acpi_match_device_ids(device, acpi_platform_device_ids))
> - acpi_create_platform_device(device);
> - }
> -
> - if (!device)
> - return AE_CTRL_DEPTH;
> + struct acpi_bus_ops add_ops = *ops;
>  
> - if (ops->acpi_op_start && !(ops->acpi_op_add)) {
> - status = acpi_start_single_object(device);
> - if (ACPI_FAILURE(status))
> + add_ops.acpi_op_match = 0;
> + acpi_add_single_object(&device, handle, type, sta, &add_ops);
> + if (!device)
>   return AE_CTRL_DEPTH;
> +
> + device->bus_ops.acpi_op_match = 1;
>   }
>  
>   if (!*return_value)
>   *return_value = device;
> +
>   return AE_OK;
>  }
>  
> +static acpi_status acpi_bus_probe_start(acpi_handle handle, u32 lvl,
> + void *context, void **not_used)
> +{
> + struct acpi_bus_ops *ops = context;
> + acpi_status status = AE_OK;
> + struct acpi_device *device;
> + unsigned long long sta_not_used;
> + int type_not_used;
> +
> + /*
> +  * Ignore errors ignored by acpi_bus_check_add() to avoid terminating

"ignore" seems duplicated. 

> +  * namespace walks prematurely.
> +  */
> + if (acpi_bus_type_and_status(handle, &type_not_used, &sta_not_used))
> + return AE_OK;
> +
> + if (acpi_bus_get_device(handle, &device))
> + return AE_CTRL_DEPTH;
> +
> + if (ops->acpi_op_add) {
> + if (!acpi_match_device_ids(device, acpi_platform_device_ids)) {
> +  

RE: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit

[Yu, Fenghua]

> >
> it has to be after #PF handler set page table patch...
> 
> otherwise when ramdisk is above 1G, customer will get early PF
> exception.

In old kernel, where can I put load_ucode_bsp()? Is calling load_ucode_bsp() 
after relocate_initrd() earliest place?

Thanks.

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

Re: [PATCH 1/3] ARM: Dove: split legacy and DT setup

[Jason Cooper]

Sebastian,

On Tue, Dec 18, 2012 at 01:24:27AM +0100, Sebastian Hesselbarth wrote:
> In the beginning of DT for Dove it was reasonable to have it close to
> non-DT code. With improved DT support, it became more and more difficult
> to not break non-DT while changing DT code.
> 
> This patch splits up DT board setup and introduces a DOVE_LEGACY config
> to allow to remove legacy code for DT-only kernels.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-dove/Kconfig|5 ++
>  arch/arm/mach-dove/Makefile   |4 +-
>  arch/arm/mach-dove/board-dt.c |  102 
> +
>  arch/arm/mach-dove/common.c   |   85 --

Could you please make this patch second in the series?  It'll prevent
dependency problems later if cleanup (patch #2) comes before board work.

thx,

Jason.

>  4 files changed, 110 insertions(+), 86 deletions(-)
>  create mode 100644 arch/arm/mach-dove/board-dt.c
> 
> diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
> index 603c5fd..aedd0ba 100644
> --- a/arch/arm/mach-dove/Kconfig
> +++ b/arch/arm/mach-dove/Kconfig
> @@ -2,8 +2,12 @@ if ARCH_DOVE
>  
>  menu "Marvell Dove Implementations"
>  
> +config DOVE_LEGACY
> + bool
> +
>  config MACH_DOVE_DB
>   bool "Marvell DB-MV88AP510 Development Board"
> + select DOVE_LEGACY
>   select I2C_BOARDINFO
>   help
> Say 'Y' here if you want your kernel to support the
> @@ -11,6 +15,7 @@ config MACH_DOVE_DB
>  
>  config MACH_CM_A510
>   bool "CompuLab CM-A510 Board"
> + select DOVE_LEGACY
>   help
> Say 'Y' here if you want your kernel to support the
> CompuLab CM-A510 Board.
> diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
> index 5e683ba..3f0a858 100644
> --- a/arch/arm/mach-dove/Makefile
> +++ b/arch/arm/mach-dove/Makefile
> @@ -1,4 +1,6 @@
> -obj-y+= common.o addr-map.o irq.o mpp.o
> +obj-y+= common.o addr-map.o irq.o
> +obj-$(CONFIG_DOVE_LEGACY)+= mpp.o
>  obj-$(CONFIG_PCI)+= pcie.o
>  obj-$(CONFIG_MACH_DOVE_DB)   += dove-db-setup.o
> +obj-$(CONFIG_MACH_DOVE_DT)   += board-dt.o
>  obj-$(CONFIG_MACH_CM_A510)   += cm-a510.o
> diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
> new file mode 100644
> index 000..2310f55
> --- /dev/null
> +++ b/arch/arm/mach-dove/board-dt.c
> @@ -0,0 +1,102 @@
> +/*
> + * arch/arm/mach-dove/board-dt.c
> + *
> + * Marvell Dove 88AP510 System On Chip FDT Board
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "common.h"
> +
> +/*
> + * There are still devices that doesn't even know about DT,
> + * get clock gates here and add a clock lookup.
> + */
> +static void __init dove_legacy_clk_init(void)
> +{
> + struct device_node *np = of_find_compatible_node(NULL, NULL,
> +  "marvell,dove-gating-clock");
> + struct of_phandle_args clkspec;
> +
> + clkspec.np = np;
> + clkspec.args_count = 1;
> +
> + clkspec.args[0] = CLOCK_GATING_BIT_USB0;
> + orion_clkdev_add(NULL, "orion-ehci.0",
> +  of_clk_get_from_provider(&clkspec));
> +
> + clkspec.args[0] = CLOCK_GATING_BIT_USB1;
> + orion_clkdev_add(NULL, "orion-ehci.1",
> +  of_clk_get_from_provider(&clkspec));
> +
> + clkspec.args[0] = CLOCK_GATING_BIT_GBE;
> + orion_clkdev_add(NULL, "mv643xx_eth_port.0",
> +  of_clk_get_from_provider(&clkspec));
> +
> + clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
> + orion_clkdev_add("0", "pcie",
> +  of_clk_get_from_provider(&clkspec));
> +
> + clkspec.args[0] = CLOCK_GATING_BIT_PCIE1;
> + orion_clkdev_add("1", "pcie",
> +  of_clk_get_from_provider(&clkspec));
> +}
> +
> +static void __init dove_of_clk_init(void)
> +{
> + mvebu_clocks_init();
> + dove_legacy_clk_init();
> +}
> +
> +static struct mv643xx_eth_platform_data dove_dt_ge00_data = {
> + .phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
> +};
> +
> +static void __init dove_dt_init(void)
> +{
> + pr_info("Dove 88AP510 SoC\n");
> +
> +#ifdef CONFIG_CACHE_TAUROS2
> + tauros2_init(0);
> +#endif
> + dove_setup_cpu_mbus();
> +
> + /* Setup root of clk tree */
> + dove_of_clk_init();
> +
> + /* Internal devices not ported to DT yet */
> + dove_ge00_init(&dove_dt_ge00_data);
> + dove_ehci0_init();
> + dove

Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit

[Yinghai Lu]

On Mon, Dec 17, 2012 at 4:32 PM, Yu, Fenghua  wrote:
>> >
>> it has to be after #PF handler set page table patch...
>>
>> otherwise when ramdisk is above 1G, customer will get early PF
>> exception.
>
> In old kernel, where can I put load_ucode_bsp()? Is calling load_ucode_bsp() 
> after relocate_initrd() earliest place?

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

Re: [PATCH 3/3] ARM: Dove: add Cubox sdhci card detect gpio

[Jason Cooper]

Sebastian,

On Tue, Dec 18, 2012 at 01:24:29AM +0100, Sebastian Hesselbarth wrote:
> Card detect for sdhci on Cubox is connected to the wrong pin
> (sdio1_cd instead of sdio0_cd). With support for cd-gpios and
> pinctrl add the corresponding properties to DT for Cubox.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/dove-cubox.dts |   14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dove-cubox.dts 
> b/arch/arm/boot/dts/dove-cubox.dts
> index fed7d3f..cdee96f 100644
> --- a/arch/arm/boot/dts/dove-cubox.dts
> +++ b/arch/arm/boot/dts/dove-cubox.dts
> @@ -26,10 +26,15 @@
>  };
>  
>  &uart0 { status = "okay"; };
> -&sdio0 { status = "okay"; };
>  &sata0 { status = "okay"; };
>  &i2c0 { status = "okay"; };
>  
> +&sdio0 {
> + status = "okay";
> + /* sdio0 card detect is connected to wrong pin on CuBox */
> + cd-gpios = <&gpio0 12 1>;

this looks like a fix that should be merged into v3.8, I'll cue it up
for v3.8-rc2.

thx,

Jason.

> +};
> +
>  &spi0 {
>   status = "okay";
>  
> @@ -42,9 +47,14 @@
>  };
>  
>  &pinctrl {
> - pinctrl-0 = <&pmx_gpio_18>;
> + pinctrl-0 = <&pmx_gpio_12 &pmx_gpio_18>;
>   pinctrl-names = "default";
>  
> + pmx_gpio_12: pmx-gpio-12 {
> + marvell,pins = "mpp12";
> + marvell,function = "gpio";
> + };
> +
>   pmx_gpio_18: pmx-gpio-18 {
>   marvell,pins = "mpp18";
>   marvell,function = "gpio";
> -- 
> 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 3/3] ARM: Dove: add Cubox sdhci card detect gpio

[Sebastian Hesselbarth]

On 12/18/2012 01:38 AM, Jason Cooper wrote:
> On Tue, Dec 18, 2012 at 01:24:29AM +0100, Sebastian Hesselbarth wrote:
>> Card detect for sdhci on Cubox is connected to the wrong pin
>> (sdio1_cd instead of sdio0_cd). With support for cd-gpios and
>> pinctrl add the corresponding properties to DT for Cubox.
>>
>> Signed-off-by: Sebastian Hesselbarth
>> ...
>> +&sdio0 {
>> +  status = "okay";
>> +  /* sdio0 card detect is connected to wrong pin on CuBox */
>> +  cd-gpios =<&gpio0 12 1>;
>
> this looks like a fix that should be merged into v3.8, I'll cue it up
> for v3.8-rc2.

Jason,

it is more a feature than a fix, as gpio-cd support for sdhci-dove
moved in lately. You want me to split this patch from the other two
(that I'll reorder as requested)?

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

Rumble support for Jess/Saitek "color rumble pad"

[Michael Karcher]

Hello developers (and testers)

The attached pad adds supports for another gamepad to the hid-pl driver.
The "color rumble pad P580" marketed using the "Saitek" brand in
Germany, and using a USB Vendor ID attributed to "Jess" seems to be
electronically identical to the 4-field variant of the "Green Asia"
gamepad.

The pad has been tested to support rumble strengths up to 255, not just
127. Currently the patch discriminates the pads by an if on the vendor
ID, a bit in the driver_data field with definitely do better, but I
recommend the owners of the 4-field green asia pad to verify whether the
maximum rumble strength is indeed only 127, otherwise the condition
should be removed entirely and 255 used in all cases.

Regards,
  Michael Karcher
>From 935b0e9f08bf7b4d271eab3356eacc1b7c47eb73 Mon Sep 17 00:00:00 2001
From: Michael Karcher 
Date: Mon, 17 Dec 2012 08:41:37 +0100
Subject: [PATCH] Support Jess/Saitek Color Rumble Pad

---
 drivers/hid/hid-ids.h |3 +++
 drivers/hid/hid-pl.c  |   13 +++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3203923..9267188 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -419,6 +419,9 @@
 #define USB_VENDOR_ID_JESS		0x0c45
 #define USB_DEVICE_ID_JESS_YUREX	0x1010
 
+#define USB_VENDOR_ID_JESS2		0x0f30
+#define USB_DEVICE_ID_JESS_COLOR_RUMBLE_PAD 0x0111
+
 #define USB_VENDOR_ID_KBGEAR		0x084e
 #define USB_DEVICE_ID_KBGEAR_JAMSTUDIO	0x1001
 
diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
index 47ed74c..825d102 100644
--- a/drivers/hid/hid-pl.c
+++ b/drivers/hid/hid-pl.c
@@ -14,6 +14,8 @@
  *  0e8f:0003 "GASIA USB Gamepad"
  *   - another version of the König gamepad
  *
+ *  0f30:0111 "Saitek Color Rumble Pad"
+ *
  *  Copyright (c) 2007, 2009 Anssi Hannula 
  */
 
@@ -51,6 +53,7 @@
 
 struct plff_device {
 	struct hid_report *report;
+	s32 maxval;
 	s32 *strong;
 	s32 *weak;
 };
@@ -66,8 +69,8 @@ static int hid_plff_play(struct input_dev *dev, void *data,
 	right = effect->u.rumble.weak_magnitude;
 	debug("called with 0x%04x 0x%04x", left, right);
 
-	left = left * 0x7f / 0x;
-	right = right * 0x7f / 0x;
+	left = left * plff->maxval / 0x;
+	right = right * plff->maxval / 0x;
 
 	*plff->strong = left;
 	*plff->weak = right;
@@ -87,6 +90,7 @@ static int plff_init(struct hid_device *hid)
 	struct list_head *report_ptr = report_list;
 	struct input_dev *dev;
 	int error;
+	s32 maxval;
 	s32 *strong;
 	s32 *weak;
 
@@ -123,6 +127,7 @@ static int plff_init(struct hid_device *hid)
 			return -ENODEV;
 		}
 
+		maxval = 0x7f;
 		if (report->field[0]->report_count >= 4) {
 			report->field[0]->value[0] = 0x00;
 			report->field[0]->value[1] = 0x00;
@@ -135,6 +140,8 @@ static int plff_init(struct hid_device *hid)
 			report->field[1]->value[0] = 0x00;
 			strong = &report->field[2]->value[0];
 			weak = &report->field[3]->value[0];
+			if (hid->vendor == USB_VENDOR_ID_JESS2)
+maxval = 0xff;
 			debug("detected 4-field device");
 		} else {
 			hid_err(hid, "not enough fields or values\n");
@@ -158,6 +165,7 @@ static int plff_init(struct hid_device *hid)
 		plff->report = report;
 		plff->strong = strong;
 		plff->weak = weak;
+		plff->maxval = maxval;
 
 		*strong = 0x00;
 		*weak = 0x00;
@@ -207,6 +215,7 @@ static const struct hid_device_id pl_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_GAMERON, USB_DEVICE_ID_GAMERON_DUAL_PCS_ADAPTOR),
 		.driver_data = 1 }, /* Twin USB Joystick */
 	{ HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, 0x0003), },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_JESS2, USB_DEVICE_ID_JESS_COLOR_RUMBLE_PAD), },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, pl_devices);
-- 
1.7.10.4

Re: [PATCH 1/3] arch/tile: implement user_regset interface on tilegx

[Simon Marchi]

On Mon, Dec 17, 2012 at 5:59 PM, Chris Metcalf  wrote:
> On 12/17/2012 5:07 PM, Simon Marchi wrote:
>>> I think with this support added, we have all the prerequisites to add 
>>> "select HAVE_ARCH_TRACEHOOK" under "config TILE" in arch/tile/Kconfig, so 
>>> we might as well do that too.  That will enable PTRACE_GETREGSET and 
>>> PTRACE_SETREGSET, as well as /proc/PID/syscall, so why not?
>> This is indeed my objective ;), and it is an intermediate objective to
>> add support for HAVE_SYSCALL_TRACEPOINTS. If we look at arch/Kconfig,
>> just above HAVE_ARCH_TRACEHOOK, we still have
>>
>> TIF_SYSCALL_TRACE   calls tracehook_report_syscall_{entry,exit}
>> TIF_NOTIFY_RESUME   calls tracehook_notify_resume()
>> signal delivery calls tracehook_signal_handler()
>
> I believe we do properly support TIF_SYSCALL_TRACE; see 
> arch/tile/kernel/intvec_64.S.  Likewise TIF_NOTIFY_RESUME; see 
> do_work_pending() in arch/tile/kernel/process.c.  And signal delivery seems 
> to be handled in a platform-independent way now; see kernel/signal.c.

TIF_SYSCALL_TRACE is handled, but it doesn't call
tracehook_report_syscall_{entry,exit} as specified. The two others
seem handled like you said.

> My only comment on the revised patch is that I believe you should #include 
> , not .  Source code (.c files) doesn't seem 
> to use the  prefix.

Oh, I didn't know the include path contained arch/tile/include/uapi
directly. Fixing it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] arch/tile: set CORE_DUMP_USE_REGSET on tile

[Simon Marchi]

Following the previous patch which adds support for user_regset, tile
can now use this feature.

Signed-off-by: Simon Marchi 
---
 arch/tile/include/asm/elf.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/tile/include/asm/elf.h b/arch/tile/include/asm/elf.h
index f8ccf08..2b43fa0 100644
--- a/arch/tile/include/asm/elf.h
+++ b/arch/tile/include/asm/elf.h
@@ -169,4 +169,6 @@ do { \
 
 #endif /* CONFIG_COMPAT */
 
+#define CORE_DUMP_USE_REGSET
+
 #endif /* _ASM_TILE_ELF_H */
-- 
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/

[PATCH v3 2/3] arch/tile: implement arch_ptrace using user_regset on tile

[Simon Marchi]

This patch changes arch_ptrace on tile so that it uses user_regset
to implement the PTRACE_GETREGS and PTRACE_SETREGS operations.

Signed-off-by: Simon Marchi 
---
 arch/tile/kernel/ptrace.c |   15 ++-
 1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c
index 882e381..9835312 100644
--- a/arch/tile/kernel/ptrace.c
+++ b/arch/tile/kernel/ptrace.c
@@ -193,18 +193,15 @@ long arch_ptrace(struct task_struct *child, long request,
break;
 
case PTRACE_GETREGS:  /* Get all registers from the child. */
-   if (copy_to_user(datap, getregs(child, ©regs),
-sizeof(struct pt_regs)) == 0) {
-   ret = 0;
-   }
+   ret = copy_regset_to_user(child, &tile_user_regset_view,
+ REGSET_GPR, 0,
+ sizeof(struct pt_regs), datap);
break;
 
case PTRACE_SETREGS:  /* Set all registers in the child. */
-   if (copy_from_user(©regs, datap,
-  sizeof(struct pt_regs)) == 0) {
-   putregs(child, ©regs);
-   ret = 0;
-   }
+   ret = copy_regset_from_user(child, &tile_user_regset_view,
+   REGSET_GPR, 0,
+   sizeof(struct pt_regs), datap);
break;
 
case PTRACE_GETFPREGS:  /* Get the child FPU state. */
-- 
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/

[PATCH v3 1/3] arch/tile: implement user_regset interface on tile

[Simon Marchi]

This is a basic implementation of user_regset for the tile
architecture. It reuses the basic blocks that were already there.

Signed-off-by: Simon Marchi 
---
v2 included change for all tile architectures (not just tilegx)
v3 changed #include  to 

 arch/tile/kernel/ptrace.c |   62 +
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c
index b32bc3f..882e381 100644
--- a/arch/tile/kernel/ptrace.c
+++ b/arch/tile/kernel/ptrace.c
@@ -19,7 +19,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
 void user_enable_single_step(struct task_struct *child)
 {
@@ -80,6 +83,65 @@ static void putregs(struct task_struct *child, struct 
pt_regs *uregs)
*regs = *uregs;
 }
 
+enum tile_regset {
+   REGSET_GPR,
+};
+
+static int tile_gpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+   struct pt_regs regs;
+
+   getregs(target, ®s);
+
+   return user_regset_copyout(&pos, &count, &kbuf, &ubuf, ®s, 0,
+  sizeof(regs));
+}
+
+static int tile_gpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+   int ret;
+   struct pt_regs regs;
+
+   ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, ®s, 0,
+sizeof(regs));
+   if (ret)
+   return ret;
+
+   putregs(target, ®s);
+
+   return 0;
+}
+
+static const struct user_regset tile_user_regset[] = {
+   [REGSET_GPR] = {
+   .core_note_type = NT_PRSTATUS,
+   .n = ELF_NGREG,
+   .size = sizeof(elf_greg_t),
+   .align = sizeof(elf_greg_t),
+   .get = tile_gpr_get,
+   .set = tile_gpr_set,
+   },
+};
+
+static const struct user_regset_view tile_user_regset_view = {
+   .name = CHIP_ARCH_NAME,
+   .e_machine = ELF_ARCH,
+   .ei_osabi = ELF_OSABI,
+   .regsets = tile_user_regset,
+   .n = ARRAY_SIZE(tile_user_regset),
+};
+
+const struct user_regset_view *task_user_regset_view(struct task_struct *task)
+{
+   return &tile_user_regset_view;
+}
+
 long arch_ptrace(struct task_struct *child, long request,
 unsigned long addr, unsigned long data)
 {
-- 
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: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

[Yinghai Lu]

On Mon, Dec 17, 2012 at 3:26 PM, Yinghai Lu  wrote:
> On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin  wrote:
>> On 12/17/2012 02:47 PM, Yinghai Lu wrote:
>>>
>>>
>>> Peter, can you check that branch again?
>>>
>>> I moved the early_trap_init after init_mem_mapping.
>>> so for 64bit native, init_mem_mapping will setup page table for ram from
>>> blank.
>>>
>>
>> Looks better, at first glance at least.  There are a couple of unnecessary
>> changes (the counter in head_64.S cannot exceed 32 bits once computed, so
>> the change from %rcx to %ecx change is pointless.)
>
> ok,  return to use %ecx
>
>>
>> There is another bug in my patch: it either needs to mask off the NX bit if
>> we are running on non-NX-enabled hardware, or it needs to not set the NX bit
>> (which is mostly okay that early on, I suspect.)
>
> i test that in kvm guest, and westmere, current version seem ok.
>
> will repost the patchset to list to get more review.
>

not sure if i could move that early_trap_init down.

jason,

We need to move down early_trap_init after init_memory_mapping to use
early #PF handler to set page table.

So can we do that? for kgdb it is that ok to move it down?

or can we just move
set_intr_gate(X86_TRAP_PF, &page_fault)
back to trap_init?

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/

Re: [PATCH 2/3] perf tool: Add support to include non architectural event aliases

[Namhyung Kim]

Hi Jiri,

On Mon, 17 Dec 2012 14:37:04 +0100, Jiri Olsa wrote:
> Adding support to parse non architectural event aliases
> for given cpu. These aliases will be provided as 'events'
> directory like architectural ones provided by kernel.
>
[snip]
> +
> +$(OUTPUT)$(OUTPUT)arch/$(ARCH)/util/pmu.o: $(OUTPUT)arch/$(ARCH)/util/pmu.c 
> $(OUTPUT)PERF-CFLAGS

Double OUTPUT ? ;)


> + $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) \
> +  '-DPERF_EXEC_PATH="$(perfexecdir_SQ)"' \
> +  '-DPREFIX="$(prefix_SQ)"' \
> +  $<
[snip]
> +static int cpu_aliases(struct list_head *head)
> +{
> + unsigned vendol, model;

s/vendol/vendor/ ?

Thanks,
Namhyung


> + int ret;
> +
> + ret = cpu_specs(&vendol, &model);
> + if (ret) {
> + pr_info("failed to get cpu aliases");
> + return 0;
> + }
> +
> + switch (vendol) {
> + /* Intel */
> + case 0:
> + return intel_aliases(head, model);
> + default:
> + /* unknown vendor.. plenty to cover ;-) */
> + return 0;
> + }
> +
> + return 0;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.8.0-rc0 on xen-unstable: RCU Stall during boot as dom0 kernel after IOAPIC

[Konrad Rzeszutek Wilk]

On Mon, Dec 17, 2012 at 10:35:58PM +0100, Sander Eikelenboom wrote:
> 
> Monday, December 17, 2012, 10:12:40 PM, you wrote:
> 
> > On Mon, Dec 17, 2012 at 03:46:34PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Dec 17, 2012 at 09:32:17PM +0100, Sander Eikelenboom wrote:
> >> > 
> >> > Sunday, December 16, 2012, 6:38:24 PM, you wrote:
> >> > 
> >> > > On Fri, Dec 14, 2012 at 04:55:57PM +0100, Sander Eikelenboom wrote:
> >> > >> Hi Konrad,
> >> > >> 
> >> > >> I just tried to boot a 3.8.0-rc0 kernel (last commit: 
> >> > >> 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with 
> >> > >> current xen-unstable.
> >> > 
> >> > > Yeah, saw it over the Dec 11->Dec 12 merges and was out on
> >> > > vacation during that time (just got back).
> >> > 
> >> > > Did you by any chance try to do a git bisect to narrow down
> >> > > which merge it was?
> >> > 
> >> > Hi Konrad,
> >> 
> >> Hey Sander,
> >> 
> >> Thank you for doing the bisection.
> >> 
> >> Fenghua - any ideas what might be amiss in the Xen subsystem?
> >> I hadn't looked at the patchset of the CPU0 offlining/onlining
> >> so I am not completly up to speed on the particulars of the patches.
> 
> >> > 30106c174311b8cfaaa3186c7f6f9c36c62d17da is the first bad commit
> >> > commit 30106c174311b8cfaaa3186c7f6f9c36c62d17da
> >> > Author: Fenghua Yu 
> >> > Date:   Tue Nov 13 11:32:41 2012 -0800
> >> > 
> >> > x86, hotplug: Support functions for CPU0 online/offline
> >> > 
> >> > Add smp_store_boot_cpu_info() to store cpu info for BSP during boot 
> >> > time.
> >> > 
> >> > Now smp_store_cpu_info() stores cpu info for bringing up BSP or AP 
> >> > after
> >> > it's offline.
> >> > 
> >> > Continue to online CPU0 in native_cpu_up().
> >> > 
> >> > Continue to offline CPU0 in native_cpu_disable().
> >> > 
> >> > Signed-off-by: Fenghua Yu 
> >> > Link: 
> >> > http://lkml.kernel.org/r/1352835171-3958-5-git-send-email-fenghua...@intel.com
> >> > Signed-off-by: H. Peter Anvin 
> >> > 
> 
> > This patch:
> 
> 
> > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> > index 353c50f..4f7d259 100644
> > --- a/arch/x86/xen/smp.c
> > +++ b/arch/x86/xen/smp.c
> > @@ -254,7 +254,7 @@ static void __init xen_smp_prepare_cpus(unsigned int 
> > max_cpus)
> > }
> > xen_init_lock_cpu(0);
> >  
> > -   smp_store_cpu_info(0);
> > +   smp_store_boot_cpu_info();
> > cpu_data(0).x86_max_cores = 1;
> >  
> > for_each_possible_cpu(i) {
> 
> > Would do the corresponding change in the Xen subsystem that the above
> > mentioned commit did. Perhaps that is all that is needed? I am going to
> > be able to test this and look in more details tomorrow.
> 
> Seems like it, don't know if there are other things still lurking, but with 
> your patch it boots again as dom0 :-)

Excellent. And it seems that it also fixes it on my test machine. Great.
I am going to stick Reported-and-Tested-by: Sander Eikelenboom
and push it to Linus shortly. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] brd: sanity checks and dynamic ram disk creation/destroying

[Hannes Frederic Sowa]

While toying around with a library which needs small block devices for
quorum management, I came up with these patches to dynamically create
and destroy ram disks (I wanted to have non-swappable backed devices).

Change log (since RFC patch <20121014024836.gb27...@order.stressinduktion.org>):
1) module parameters(rd_nr, rd_size, max_part) are now unsigned ints
2) check for active users of ram disk before BLKFLSBUFing
3) switched from lists to idrs for device management

Change log (since patch v1 
<1350757943-24981-1-git-send-email-han...@stressinduktion.org>):
1) rebase to v3.7 (in conformance to uapi-header changes)
2) convert simple_stroul to kstrtoul
3) make rd_size static as the last user has vanished

These patches are diffed against v3.7:

 Documentation/ioctl/ioctl-number.txt |   1 +
 block/partition-generic.c|   1 +
 drivers/block/brd.c  | 361 +--
 include/linux/miscdevice.h   |   1 +
 include/uapi/linux/Kbuild|   1 +
 include/uapi/linux/brd.h |  12 ++
 6 files changed, 314 insertions(+), 63 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/

[PATCH v2 1/4] brd: change module parameters rd_size, rd_nr, max_part to unsigned

[Hannes Frederic Sowa]

All parameters of the module brd are now converted to unsigneds. This
saves some less-than-zero checks. rd_size can now be static, because
the last external user in arch/arm/kernel/setup.c:setup_ramdisk is gone.

While at it, move the (perhaps automatically) placed brd_mutex out of
the silly constellation between function prelude comment and function
and convert simple

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 drivers/block/brd.c | 45 ++---
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 531ceb3..70ad8dc 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -48,10 +48,11 @@ struct brd_device {
struct radix_tree_root  brd_pages;
 };
 
+static DEFINE_MUTEX(brd_mutex);
+
 /*
  * Look up and return a brd's page for a given sector.
  */
-static DEFINE_MUTEX(brd_mutex);
 static struct page *brd_lookup_page(struct brd_device *brd, sector_t sector)
 {
pgoff_t idx;
@@ -429,15 +430,15 @@ static const struct block_device_operations brd_fops = {
 /*
  * And now the modules code and kernel interface.
  */
-static int rd_nr;
-int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
-static int max_part;
-static int part_shift;
-module_param(rd_nr, int, S_IRUGO);
+static unsigned int rd_nr;
+static unsigned int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
+static unsigned int max_part;
+static unsigned int part_shift;
+module_param(rd_nr, uint, S_IRUGO);
 MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
-module_param(rd_size, int, S_IRUGO);
+module_param(rd_size, uint, S_IRUGO);
 MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
-module_param(max_part, int, S_IRUGO);
+module_param(max_part, uint, S_IRUGO);
 MODULE_PARM_DESC(max_part, "Maximum number of partitions per RAM disk");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
@@ -447,7 +448,8 @@ MODULE_ALIAS("rd");
 /* Legacy boot options - nonmodular */
 static int __init ramdisk_size(char *str)
 {
-   rd_size = simple_strtol(str, NULL, 0);
+   if (kstrtoul(str, 0, &rd_size))
+   rd_size = 0;
return 1;
 }
 __setup("ramdisk_size=", ramdisk_size);
@@ -555,7 +557,7 @@ static struct kobject *brd_probe(dev_t dev, int *part, void 
*data)
 
 static int __init brd_init(void)
 {
-   int i, nr;
+   unsigned int i, nr;
unsigned long range;
struct brd_device *brd, *next;
 
@@ -574,20 +576,17 @@ static int __init brd_init(void)
 * kernel automatically instantiate actual device on-demand.
 */
 
-   part_shift = 0;
-   if (max_part > 0) {
-   part_shift = fls(max_part);
+   part_shift = fls(max_part);
 
-   /*
-* Adjust max_part according to part_shift as it is exported
-* to user space so that user can decide correct minor number
-* if [s]he want to create more devices.
-*
-* Note that -1 is required because partition 0 is reserved
-* for the whole disk.
-*/
-   max_part = (1UL << part_shift) - 1;
-   }
+   /*
+* Adjust max_part according to part_shift as it is exported
+* to user space so that user can decide correct minor number
+* if [s]he want to create more devices.
+*
+* Note that -1 is required because partition 0 is reserved
+* for the whole disk.
+*/
+   max_part = (1UL << part_shift) - 1;
 
if ((1UL << part_shift) > DISK_MAX_PARTS)
return -EINVAL;
-- 
1.8.0.2

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

[PATCH v2 2/4] brd: check for open partitions when BLKFLSBUFing a ram disk

[Hannes Frederic Sowa]

Users of partitions on ram disks could accidentally flush the block
device with ioctl(BLKFLSBUF) while it is in use. This patch prevents
this from happening.

This patch also adds a call to rescan_partitions after BLKFLSBUFing,
for which a EXPORT_SYMBOL_GPL statement was needed. Otherwise some kind
of use-after-free could happen.

After this change BLKFLSBUFing on partitions of a ram disk is never
possible.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 block/partition-generic.c |  1 +
 drivers/block/brd.c   | 20 +---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/block/partition-generic.c b/block/partition-generic.c
index f1d1451..cd7bc10 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -528,6 +528,7 @@ rescan:
kfree(state);
return 0;
 }
+EXPORT_SYMBOL_GPL(rescan_partitions);
 
 int invalidate_partitions(struct gendisk *disk, struct block_device *bdev)
 {
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 70ad8dc..80dd094 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -385,6 +385,13 @@ static int brd_direct_access(struct block_device *bdev, 
sector_t sector,
 }
 #endif
 
+static int brd_blkdev_in_use(struct block_device *bdev)
+{
+   lockdep_assert_held(&bdev->bd_mutex);
+   return bdev->bd_part_count > 0
+   || bdev->bd_openers > 1;
+}
+
 static int brd_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
 {
@@ -399,9 +406,15 @@ static int brd_ioctl(struct block_device *bdev, fmode_t 
mode,
 * release and destroy the ramdisk data.
 */
mutex_lock(&brd_mutex);
+   if (bdget_disk(brd->brd_disk, 0) != bdev) {
+   error = -EBUSY;
+   goto out;
+   }
mutex_lock(&bdev->bd_mutex);
-   error = -EBUSY;
-   if (bdev->bd_openers <= 1) {
+   error = brd_blkdev_in_use(bdev);
+   if (error) {
+   error = -EBUSY;
+   } else {
/*
 * Kill the cache first, so it isn't written back to the
 * device.
@@ -411,9 +424,10 @@ static int brd_ioctl(struct block_device *bdev, fmode_t 
mode,
 */
kill_bdev(bdev);
brd_free_pages(brd);
-   error = 0;
+   error = rescan_partitions(brd->brd_disk, bdev);
}
mutex_unlock(&bdev->bd_mutex);
+out:
mutex_unlock(&brd_mutex);
 
return error;
-- 
1.8.0.2

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

[PATCH v2 3/4] brd: replace list with brd_devices by an idr indexed by minor ids

[Hannes Frederic Sowa]

This patch replaces the list of brd_devices with an idr, thus enabling
easier block ram disk creation and deletion.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 drivers/block/brd.c | 136 
 1 file changed, 106 insertions(+), 30 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 80dd094..68641d8 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -34,11 +35,8 @@
  * device).
  */
 struct brd_device {
-   int brd_number;
-
struct request_queue*brd_queue;
struct gendisk  *brd_disk;
-   struct list_headbrd_list;
 
/*
 * Backing store of pages and lock to protect it. This is the contents
@@ -50,6 +48,10 @@ struct brd_device {
 
 static DEFINE_MUTEX(brd_mutex);
 
+static char dummy = -1;
+#define DUMMY ((struct brd_device *)&dummy)
+static DEFINE_IDR(brd_idr);
+
 /*
  * Look up and return a brd's page for a given sector.
  */
@@ -458,6 +460,8 @@ MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
 MODULE_ALIAS("rd");
 
+static struct brd_device *brd_new(int id);
+
 #ifndef MODULE
 /* Legacy boot options - nonmodular */
 static int __init ramdisk_size(char *str)
@@ -473,7 +477,6 @@ __setup("ramdisk_size=", ramdisk_size);
  * The device scheme is derived from loop.c. Keep them in synch where possible
  * (should share code eventually).
  */
-static LIST_HEAD(brd_devices);
 static DEFINE_MUTEX(brd_devices_mutex);
 
 static struct brd_device *brd_alloc(int i)
@@ -484,7 +487,6 @@ static struct brd_device *brd_alloc(int i)
brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
goto out;
-   brd->brd_number = i;
spin_lock_init(&brd->brd_lock);
INIT_RADIX_TREE(&brd->brd_pages, GFP_ATOMIC);
 
@@ -534,27 +536,100 @@ static struct brd_device *brd_init_one(int i)
 {
struct brd_device *brd;
 
-   list_for_each_entry(brd, &brd_devices, brd_list) {
-   if (brd->brd_number == i)
-   goto out;
-   }
+   brd = idr_find(&brd_idr, i);
+   if (brd)
+   return brd;
 
-   brd = brd_alloc(i);
-   if (brd) {
+   brd = brd_new(i);
+   if (!IS_ERR(brd))
add_disk(brd->brd_disk);
-   list_add_tail(&brd->brd_list, &brd_devices);
-   }
-out:
return brd;
 }
 
 static void brd_del_one(struct brd_device *brd)
 {
-   list_del(&brd->brd_list);
del_gendisk(brd->brd_disk);
brd_free(brd);
 }
 
+static int brd_new_id(int min)
+{
+   int id, err;
+   err = idr_pre_get(&brd_idr, GFP_KERNEL);
+   if (!err)
+   return -ENOMEM;
+   err = idr_get_new_above(&brd_idr, DUMMY, min, &id);
+   if (err < 0)
+   return err;
+   return id;
+}
+
+static int brd_new_specific_id(int id)
+{
+   int n;
+   n = brd_new_id(id);
+   if (n < 0)
+   return n;
+   if (id != n) {
+   idr_remove(&brd_idr, n);
+   return -EBUSY;
+   }
+   return n;
+}
+
+static struct brd_device *brd_new(int id)
+{
+   int err;
+   struct brd_device *brd, *p;
+
+   err = brd_new_specific_id(id);
+   if (err < 0)
+   return ERR_PTR(err);
+   brd = brd_alloc(id);
+   if (!brd) {
+   p = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+   p = idr_replace(&brd_idr, brd, id);
+   if (IS_ERR(p))
+   goto out2;
+   if (p != DUMMY) {
+   WARN_ON(1);
+   p = ERR_PTR(-EBUSY);
+   goto out2;
+   }
+   return brd;
+out2:
+   brd_free(brd);
+out:
+   idr_remove(&brd_idr, id);
+   return p;
+}
+
+static int brd_add_disk_idr(int id, void *p, void *data)
+{
+   struct brd_device *brd = (struct brd_device *)p;
+   WARN_ON(brd == DUMMY);
+   add_disk(brd->brd_disk);
+   return 0;
+}
+
+static int brd_free_idr(int id, void *p, void *data)
+{
+   struct brd_device *brd = (struct brd_device *)p;
+   WARN_ON(brd == DUMMY);
+   brd_free(brd);
+   return 0;
+}
+
+static int brd_del_one_idr(int id, void *p, void *data)
+{
+   struct brd_device *brd = (struct brd_device *)p;
+   WARN_ON(brd == DUMMY);
+   brd_del_one(brd);
+   return 0;
+}
+
 static struct kobject *brd_probe(dev_t dev, int *part, void *data)
 {
struct brd_device *brd;
@@ -562,7 +637,7 @@ static struct kobject *brd_probe(dev_t dev, int *part, void 
*data)
 
mutex_lock(&brd_devices_mutex);
brd = brd_init_one(MINOR(dev) >> part_shift);
-   kobj = brd ? get_disk(brd->brd_disk) : ERR_PTR(-ENOMEM);
+   kobj = IS_ERR(brd) ? ERR_PTR(PTR_ERR(brd)) : get_disk(brd->brd_disk);
mutex_unlock(&brd_devices_mutex);
 
*part = 0;
@@ -571,9 +646,10 @@ static struct kobject *brd_probe(dev

[PATCH v2 4/4] brd: add miscdevice to control creation and deletion of ram disks

[Hannes Frederic Sowa]

This patch adds the miscdevice /dev/brd-control with two ioctls:

  1) BRD_CTL_ADD: Instantiates a new ram disk with a given size as
 parameter. This parameter is filled in with the new minor id
 on return.

  2) BRD_CTL_DEL: Deletes a ram disk. Takes the minor id as parameter.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 drivers/block/brd.c  | 170 ---
 include/linux/miscdevice.h   |   1 +
 include/uapi/linux/Kbuild|   1 +
 include/uapi/linux/brd.h |  12 +++
 5 files changed, 173 insertions(+), 12 deletions(-)
 create mode 100644 include/uapi/linux/brd.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 2152b0e..6017851 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,4 +321,5 @@ Code  Seq#(hex) Include FileComments

 0xF6   all LTTng   Linux Trace Toolkit Next Generation

+0xF7   00-01   drivers/block/brd.c block ram device control driver
 0xFD   all linux/dm-ioctl.h
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 68641d8..b9a7a2d 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -20,6 +20,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -479,7 +482,7 @@ __setup("ramdisk_size=", ramdisk_size);
  */
 static DEFINE_MUTEX(brd_devices_mutex);
 
-static struct brd_device *brd_alloc(int i)
+static struct brd_device *brd_alloc(int i, unsigned int size_kb)
 {
struct brd_device *brd;
struct gendisk *disk;
@@ -512,7 +515,7 @@ static struct brd_device *brd_alloc(int i)
disk->queue = brd->brd_queue;
disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
sprintf(disk->disk_name, "ram%d", i);
-   set_capacity(disk, rd_size * 2);
+   set_capacity(disk, size_kb * 2);
 
return brd;
 
@@ -585,7 +588,7 @@ static struct brd_device *brd_new(int id)
err = brd_new_specific_id(id);
if (err < 0)
return ERR_PTR(err);
-   brd = brd_alloc(id);
+   brd = brd_alloc(id, rd_size);
if (!brd) {
p = ERR_PTR(-ENOMEM);
goto out;
@@ -606,6 +609,139 @@ out:
return p;
 }
 
+static int brd_control_add(unsigned int size_kb)
+{
+   int val, err;
+   struct brd_device *brd, *p;
+
+   lockdep_assert_held(&brd_devices_mutex);
+
+   val = brd_new_id(0);
+   if (val < 0)
+   return val;
+   if (val >= (MINORMASK >> part_shift)) {
+   err = -EINVAL;
+   goto out;
+   }
+   brd = brd_alloc(val, size_kb);
+   if (!brd) {
+   err = -ENOMEM;
+   goto out;
+   }
+   p = idr_replace(&brd_idr, brd, val);
+   if (IS_ERR(p)) {
+   err = PTR_ERR(p);
+   goto out2;
+   }
+   if (p != DUMMY) {
+   WARN_ON(1);
+   err = -EBUSY;
+   goto out2;
+   }
+   add_disk(brd->brd_disk);
+   return val;
+out2:
+   brd_free(brd);
+out:
+   idr_remove(&brd_idr, val);
+   return err;
+}
+
+static int brd_control_del(unsigned int val)
+{
+   int err = 0;
+   struct brd_device *brd;
+   struct block_device *bdev;
+
+   lockdep_assert_held(&brd_devices_mutex);
+
+   brd = idr_find(&brd_idr, val);
+   if (!brd)
+   return -ENODEV;
+
+   mutex_lock(&brd_mutex);
+   bdev = bdget_disk(brd->brd_disk, 0);
+   if (!bdev) {
+   err = -ENODEV;
+   goto out;
+   }
+   mutex_lock(&bdev->bd_mutex);
+   err = brd_blkdev_in_use(bdev);
+   if (err) {
+   err = -EBUSY;
+   } else {
+   idr_remove(&brd_idr, val);
+   brd_del_one(brd);
+   err = 0;
+   }
+   mutex_unlock(&bdev->bd_mutex);
+out:
+   mutex_unlock(&brd_mutex);
+   return err;
+}
+
+static long brd_control_ioctl(struct file *file, unsigned int cmd,
+   unsigned long param)
+{
+   int err = -ENOSYS;
+   int val;
+   unsigned int size_kb;
+
+   if (rd_nr)
+   return -EINVAL;
+
+   mutex_lock(&brd_devices_mutex);
+   switch (cmd) {
+   case BRD_CTL_ADD:
+   err = get_user(size_kb, (unsigned int __user *)param);
+   if (err < 0)
+   break;
+   val = brd_control_add(size_kb);
+   if (val < 0) {
+   err = val;
+   break;
+   }
+   err = put_user(val << part_shift, (unsigned int __user *)param);
+   if (err < 0) {
+   brd_control_del(val);
+ 

Are there u32 atomic bitops? (or dealing w/ i_flags)

[Andy Lutomirski]

I want to change inode->i_flags access to be atomic -- there are some
locking oddities right now, I think, and I want to use a new inode
flag to signal mtime updates from page_mkwrite.  The problem is that
i_flags is an unsigned int, and making it an unsigned long seems like
a waste, but there aren't any u32 atomic bitops.

What should I do?  Suck it up and waste four bytes on 64-bit machines?

In general, having atomic flag words be long seems likely to waste
bits on 64-bit architectures.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] convert timeconst.pl->mktimeconst.c

[rob]

From: Rob Landley 

Replace perl header file generator with smaller/faster/simpler C version.

Signed-off-by: Rob Landley 
---

 kernel/Makefile  |   10 -
 kernel/mktimeconst.c |  109 +++
 kernel/timeconst.pl  |  378 -
 3 files changed, 115 insertions(+), 382 deletions(-)

diff --git a/kernel/Makefile b/kernel/Makefile
index 5669f71..ba9ce6d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -133,11 +133,13 @@ $(obj)/config_data.h: $(obj)/config_data.gz FORCE
 
 $(obj)/time.o: $(obj)/timeconst.h
 
-quiet_cmd_timeconst  = TIMEC   $@
-  cmd_timeconst  = $(PERL) $< $(CONFIG_HZ) > $@
+hostprogs-y+= mktimeconst
+quiet_cmd_mktimeconst = TIMEC   $@
+   cmd_mktimeconst = $(obj)/mktimeconst $(CONFIG_HZ) $@ || ( rm -f $@ && 
exit 1 )
+
 targets += timeconst.h
-$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
-   $(call if_changed,timeconst)
+$(obj)/timeconst.h: $(obj)/mktimeconst FORCE
+   $(call if_changed,mktimeconst)
 
 ifeq ($(CONFIG_MODULE_SIG),y)
 #
--- /dev/null   2011-01-13 17:00:36.470564274 -0600
+++ b/kernel/mktimeconst.c  2011-01-16 12:44:04.091168778 -0600
@@ -0,0 +1,109 @@
+/* Copyright 2010 Parallels Inc, licensed under GPLv2 */
+
+#include 
+#include 
+#include 
+
+int main(int argc, char *argv[])
+{
+   uint64_t hz, periods[] = {1000, 100};
+   char *names[] = {"MSEC", "USEC"};
+   FILE *file;
+   int i, j;
+
+   if (argc != 3 || (hz = atol(argv[1])) < 1
+   || !(file = fopen(argv[2], "w")))
+   {
+   fprintf(stderr, "Usage: mktimeconst HZ FILENAME\n\n");
+   fprintf(stderr, "Generate a header file with constants to 
convert between\n");
+   fprintf(stderr, "decimal HZ timer ticks and milisecond or 
microsecond delays,\n");
+   fprintf(stderr, "using reciprocal multiplication to avoid 64 
bit division.\n");
+   exit(1);
+   }
+
+   fprintf(file,
+   "/* Automatically generated by kernel/mktimeconst */\n"
+   "/* Conversion constants for HZ == %"PRIu64" */\n\n"
+   "#ifndef __KERNEL_TIMECONST_H\n"
+   "#define __KERNEL_TIMECONST_H\n\n"
+   "#include \n"
+   "#include \n\n"
+   "#if HZ != %"PRIu64"\n"
+   "#error \"kernel/timeconst.h has the wrong HZ value!\"\n"
+   "#endif\n\n", hz, hz);
+
+   /* Repeat for MSEC and USEC */
+
+   for (i = 0; i < 2; i++) {
+   uint64_t gcd, period;
+
+   /* Find greatest common denominator using Euclid's algorithm. */
+
+   gcd = hz;
+   period = periods[i];
+   while (period) {
+   uint64_t temp = gcd % period;
+   gcd = period;
+   period = temp;
+   }
+
+   /* Output both directions (HZ_TO_PERIOD and PERIOD_TO_HZ) */
+
+   for (j = 0; j < 2; j++) {
+   char name[16];
+   uint64_t from = j ? periods[i] : hz;
+   uint64_t to = j ? hz : periods[i];
+   uint64_t mul32 = 0, adj32 = 0, shift = 0;
+
+   sprintf(name, j ? "%s_TO_HZ" : "HZ_TO_%s", names[i]);
+
+   /* Figure out what shift value gives 32 significant
+  bits of MUL32 data.  (Worst case to=1 from=100
+  uses 52 bits, to<= (1UL<<31))
+   break;
+   shift++;
+   }
+
+   /* ADJ32 is is just (((FROM/GCD)-1)< 32) {
+   uint64_t upper, lower;
+
+   upper = (adj32 - 1) << (shift - 32);
+   lower = (upper % adj32) << 32;
+   adj32 = ((upper/adj32) << 32) + (lower/adj32);
+   } else
+   adj32 = ((adj32 - 1) << shift) / adj32;
+
+   /* Emit the constants into the header file. */
+
+   fprintf(file, "#define %s_MUL32\tU64_C(0x%"PRIx64")\n",
+   name, mul32);
+   fprintf(file, "#define %s_ADJ32\tU64_C(0x%"PRIx64")\n",
+   name, adj32);
+   fprintf(file, "#define %s_SHR32\t%"PRIu64"\n",
+   name, shift);
+   fprintf(file, "#define %s_NUM\t\tU64_C(%"PRIu64")\n",
+   name, to/gcd);
+   fprintf(file, "#define %s_DEN\t\tU64_C(%"PRIu64")\n\n",
+   name, from/gcd);
+   }
+   }
+   fprintf(file, "#endif /* __KERNEL_TIMECONST_H */\n");
+
+   /* Notice if the disk fills up. */
+
+   fflush(stdout);
+   return ferror(stdout);
+}
--- a/kernel/timeconst.pl   2010-12-19 11:3

[PATCH] efi: Fix the build with user namespaces enabled.

[Eric W. Biederman]

When compiling efivars.c the build fails with:

 CC  drivers/firmware/efivars.o
drivers/firmware/efivars.c: In function ‘efivarfs_get_inode’:
drivers/firmware/efivars.c:886:31: error: incompatible types when assigning to 
type ‘kgid_t’ from type ‘int’
make[2]: *** [drivers/firmware/efivars.o] Error 1
make[1]: *** [drivers/firmware/efivars.o] Error 2

Fix the build error by removing the duplicate initialization of i_uid and
i_gid inode_init_always has already initialized them to 0.

Signed-off-by: "Eric W. Biederman" 
---
 drivers/firmware/efivars.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 52c5d89..7b1c374 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -883,7 +883,6 @@ static struct inode *efivarfs_get_inode(struct super_block 
*sb,
 
if (inode) {
inode->i_ino = get_next_ino();
-   inode->i_uid = inode->i_gid = 0;
inode->i_mode = mode;
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
switch (mode & S_IFMT) {
-- 
1.7.5.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/3] convert mkcapflags.pl->mkcapflags.sh

[rob]

From: Rob Landley 

Generate asm-x86/cpufeature.h with posix-2008 commands instead of perl.

Signed-off-by: Rob Landley 
---

 arch/x86/kernel/cpu/Makefile  |4 +-
 arch/x86/kernel/cpu/mkcapflags.pl |   48 
 arch/x86/kernel/cpu/mkcapflags.sh |   41 +++
 3 files changed, 43 insertions(+), 50 deletions(-)

--- linux/arch/x86/kernel/cpu/mkcapflags.pl
+++ /dev/null
@@ -1,48 +0,0 @@
-#!/usr/bin/perl -w
-#
-# Generate the x86_cap_flags[] array from include/asm-x86/cpufeature.h
-#
-
-($in, $out) = @ARGV;
-
-open(IN, "< $in\0")   or die "$0: cannot open: $in: $!\n";
-open(OUT, "> $out\0") or die "$0: cannot create: $out: $!\n";
-
-print OUT "#ifndef _ASM_X86_CPUFEATURE_H\n";
-print OUT "#include \n";
-print OUT "#endif\n";
-print OUT "\n";
-print OUT "const char * const x86_cap_flags[NCAPINTS*32] = {\n";
-
-%features = ();
-$err = 0;
-
-while (defined($line = )) {
-   if ($line =~ /^\s*\#\s*define\s+(X86_FEATURE_(\S+))\s+(.*)$/) {
-   $macro = $1;
-   $feature = "\L$2";
-   $tail = $3;
-   if ($tail =~ /\/\*\s*\"([^"]*)\".*\*\//) {
-   $feature = "\L$1";
-   }
-
-   next if ($feature eq '');
-
-   if ($features{$feature}++) {
-   print STDERR "$in: duplicate feature name: $feature\n";
-   $err++;
-   }
-   printf OUT "\t%-32s = \"%s\",\n", "[$macro]", $feature;
-   }
-}
-print OUT "};\n";
-
-close(IN);
-close(OUT);
-
-if ($err) {
-   unlink($out);
-   exit(1);
-}
-
-exit(0);
--- /dev/null   2012-07-11 05:54:12.790418331 -0500
+++ linux/arch/x86/kernel/cpu/mkcapflags.sh 2012-07-22 13:13:57.700823094 
-0500
@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# Generate the x86_cap_flags[] array from include/asm/cpufeature.h
+#
+
+IN=$1
+OUT=$2
+
+TABS="$(printf '\t\t\t\t\t')"
+trap 'rm "$OUT"' EXIT
+
+(
+   echo "#ifndef _ASM_X86_CPUFEATURE_H"
+   echo "#include "
+   echo "#endif"
+   echo ""
+   echo "const char * const x86_cap_flags[NCAPINTS*32] = {"
+
+   # Iterate through any input lines starting with #define X86_FEATURE_
+   sed -n -e 's/\t/ /g' -e 's/^ *# *define *X86_FEATURE_//p' $IN |
+   while read i
+   do
+   # Name is everything up to the first whitespace
+   NAME="$(echo "$i" | sed 's/ .*//')"
+
+   # If the /* comment */ starts with a quote string, grab that.
+   VALUE="$(echo "$i" | sed -n 's@.*/\* *\("[^"]*"\).*\*/@\1@p')"
+   [ -z "$VALUE" ] && VALUE="\"$NAME\""
+   [ "$VALUE" == '""' ] && continue
+
+   # Name is uppercase, VALUE is all lowercase
+   VALUE="$(echo "$VALUE" | tr A-Z a-z)"
+
+   TABCOUNT=$(( ( 5*8 - 14 - $(echo "$NAME" | wc -c) ) / 8 ))
+   printf "\t[%s]%.*s = %s,\n" \
+   "X86_FEATURE_$NAME" "$TABCOUNT" "$TABS" "$VALUE"
+   done
+   echo "};"
+) > $OUT
+
+trap - EXIT
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 25f24dc..9edf7e7 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -40,10 +40,10 @@ obj-$(CONFIG_MTRR)  += mtrr/
 obj-$(CONFIG_X86_LOCAL_APIC)   += perfctr-watchdog.o 
perf_event_amd_ibs.o
 
 quiet_cmd_mkcapflags = MKCAP   $@
-  cmd_mkcapflags = $(PERL) $(srctree)/$(src)/mkcapflags.pl $< $@
+  cmd_mkcapflags = $(CONFIG_SHELL) $(srctree)/$(src)/mkcapflags.sh $< $@
 
 cpufeature = $(src)/../../include/asm/cpufeature.h
 
 targets += capflags.c
-$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.pl FORCE
+$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.sh FORCE
$(call if_changed,mkcapflags)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] arch/tile: implement user_regset interface on tile

[Chris Metcalf]

On 12/17/2012 8:08 PM, Simon Marchi wrote:
> This is a basic implementation of user_regset for the tile
> architecture. It reuses the basic blocks that were already there.
>
> Signed-off-by: Simon Marchi 

Thanks, I'll take this into the tile tree for this merge window.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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

[PATCH 3/3] convert headers_install.pl->headers_install.sh

[rob]

From: Rob Landley 

Remove perl from make headers_install by replacing a perl script (doing
a simple regex search and replace) with a smaller, faster, simpler,
POSIX-2008 shell script implementation.  The new shell script is a single
for loop calling sed and piping its output through unifdef to produce the
target file.

Signed-off-by: Rob Landley 
---

 scripts/Makefile.headersinst |4 +-
 scripts/headers_install.pl   |   63 -
 scripts/headers_install.sh   |   43 ++
 3 files changed, 45 insertions(+), 65 deletions(-)

diff -ruN linux-3.1/scripts/headers_install.sh 
linux-2.6.30/scripts/headers_install.sh
--- linux-3.1/scripts/headers_install.sh
+++ linux/scripts/headers_install.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+if [ $# -lt 1 ]
+then
+   echo "Usage: headers_install.sh OUTDIR [FILES...]
+   echo
+   echo "Prepares kernel header files for use by user space, by removing"
+   echo "all compiler.h definitions and #includes, removing any"
+   echo "#ifdef __KERNEL__ sections, and putting __underscores__ around"
+   echo "asm/inline/volatile keywords."
+   echo
+   echo "OUTDIR: directory to write each userspace header FILE to."
+   echo "FILES:  list of header files to operate on."
+
+   exit 1
+fi
+
+# Grab arguments
+
+OUTDIR="$1"
+shift
+
+# Iterate through files listed on command line
+
+FILE=
+trap 'rm -f "$OUTDIR/$FILE" "$OUTDIR/$FILE.sed"' EXIT
+for i in "$@"
+do
+   FILE="$(basename "$i")"
+   sed -r \
+   -e 's/([ \t(])(__user|__force|__iomem)[ \t]/\1/g' \
+   -e 's/__attribute_const__([ \t]|$)/\1/g' \
+   -e 's@^#include @@' \
+   -e 
's/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g' \
+   -e 's/(^|[ \t])(inline|asm|volatile)([ \t(]|$)/\1__\2__\3/g' \
+   -e 's@#(ifndef|define|endif /[*]) _UAPI@#\1 @' \
+   "$i" > "$OUTDIR/$FILE.sed" || exit 1
+   scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ "$OUTDIR/$FILE.sed" 
\
+   > "$OUTDIR/$FILE"
+   [ $? -gt 1 ] && exit 1
+   rm -f "$OUTDIR/$FILE.sed"
+done
+trap - EXIT
diff -ruN linux-3.1/scripts/Makefile.headersinst
--- linux-3.1/scripts/Makefile.headersinst
+++ linux/scripts/Makefile.headersinst
@@ -55,7 +55,7 @@
 quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
 file$(if $(word 2, $(all-files)),s))
   cmd_install = \
-$(PERL) $< $(installdir) $(SRCARCH) $(input-files); \
+$(CONFIG_SHELL) $< $(installdir) $(input-files); \
 for F in $(wrapper-files); do   \
 echo "\#include " > $(installdir)/$$F;\
 done;   \
@@ -83,7 +83,7 @@
@:
 
 targets += $(install-file)
-$(install-file): scripts/headers_install.pl $(input-files) FORCE
+$(install-file): scripts/headers_install.sh $(input-files) FORCE
$(if $(unwanted),$(call cmd,remove),)
$(if $(wildcard $(dir $@)),,$(shell mkdir -p $(dir $@)))
$(call if_changed,install)
--- a/scripts/headers_install.pl
+++ /dev/null
@@ -1,63 +0,0 @@
-#!/usr/bin/perl -w
-#
-# headers_install prepare the listed header files for use in
-# user space and copy the files to their destination.
-#
-# Usage: headers_install.pl readdir installdir arch [files...]
-# installdir: dir to install the files to
-# arch:   current architecture
-# arch is used to force a reinstallation when the arch
-# changes because kbuild then detect a command line change.
-# files:  list of files to check
-#
-# Step in preparation for users space:
-# 1) Drop all use of compiler.h definitions
-# 2) Drop include of compiler.h
-# 3) Drop all sections defined out by __KERNEL__ (using unifdef)
-
-use strict;
-
-my ($installdir, $arch, @files) = @ARGV;
-
-my $unifdef = "scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__";
-
-foreach my $filename (@files) {
-   my $file = $filename;
-   $file =~ s!^.*/!!;
-
-   my $tmpfile = "$installdir/$file.tmp";
-
-   open(my $in, '<', $filename)
-   or die "$filename: $!\n";
-   open(my $out, '>', $tmpfile)
-   or die "$tmpfile: $!\n";
-   while (my $line = <$in>) {
-   $line =~ s/([\s(])__user\s/$1/g;
-   $line =~ s/([\s(])__force\s/$1/g;
-   $line =~ s/([\s(])__iomem\s/$1/g;
-   $line =~ s/\s__attribute_const__\s/ /g;
-   $line =~ s/\s__attribute_const__$//g;
-   $line =~ s/\b__packed\b/__attribute__((packed))/g;
-   $line =~ s/^#include //;
-   $line =~ s/(^|\s)(inline)\b/$1__$2__/g;
-   $line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g;
-   $line =~ s/(^|\s|[(])(volatile)\b(\s|[(]|$)/$1__$2__$3/g;
-   $line =~ s/#ifndef _UAPI/#ifndef /;
-   $line =~ s/#define _UAPI/#def

[PATCH 0/3] build 3.7 kernel without perl

[rob]

Before 2.6.25 building Linux never required perl. This patch series removes
the requirement from basic kernel builds (tested on i686, x86_64, arm, mips,
powerpc, sparc, sh4, and m68k). Now updated to 3.7, with the UAPI stuff.

Earlier versions of these patches were posted to the mailing list once or twice:

http://lkml.indiana.edu/hypermail/linux/kernel/1201.2/02849.html
http://lkml.indiana.edu/hypermail/linux/kernel/0912.1/00093.htm
http://lkml.indiana.edu/hypermail/linux/kernel/0909.2/01661.html
http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00772.html
http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00148.html
http://lkml.indiana.edu/hypermail/linux/kernel/0802.1/4393.html

They've also been posted individually rather than as a series:
http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00650.html
http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00115.html

Mentioned during related perl removal patches from other people:
http://lkml.indiana.edu/hypermail/linux/kernel/0910.0/02145.html

And so on. The most up to date version of these patches is always available at
http://landley.net/hg/aboriginal in the sources/patches directory.
Specifically, check:

http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-capflags.patch
http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-headers.patch
http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-timeconst.patch

(Earlier versions had the kernel version number in the filename, so you'll have
to dig in the repository a bit to find them if you want the version for an
older kernel.)

Mostly people just copy the patches into their local projects (ala
https://github.com/rofl0r/sabotage/tree/master/KEEP ) but I'm reposting
them to linux-kernel after Gentoo considered using these patches, but didn't 
because they weren't upstream:
  https://bugs.gentoo.org/show_bug.cgi?id=421483
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Please pull NFS client changesets for Linux 3.8

[Myklebust, Trond]

Hi Linus,

The following changes since commit 0e4a43ed08e2f44aa7b96aa95d0a540d675483e1:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes 
(2012-11-07 13:38:56 +0100)

are available in the git repository at:


  git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-3.8-1

for you to fetch changes up to cd6c5968582a273561464fe6b1e8cc8214be02df:

  SUNRPC: continue run over clients list on PipeFS event instead of break 
(2012-12-17 12:19:16 -0500)

Cheers
  Trond


NFS client updates for Linux 3.8

Features include:

- Full audit of BUG_ON asserts in the NFS, SUNRPC and lockd client code
  Remove altogether where possible, and replace with WARN_ON_ONCE and
  appropriate error returns where not.
- NFSv4.1 client adds session dynamic slot table management. There is
  matching server side code that has been submitted to Bruce for
  consideration. Together, this code allows the server to dynamically
  manage the amount of memory it allocates to the duplicate request
  cache for each client. It will constantly resize those caches to
  reserve more memory for clients that are hot while shrinking caches
  for those that are quiescent.

In addition, there are assorted bugfixes for the generic NFS write code,
fixes to deal with the drop_nlink() warnings, and yet another fix for
NFSv4 getacl.


Andy Adamson (2):
  SUNRPC set gss gc_expiry to full lifetime
  SUNRPC handle EKEYEXPIRED in call_refreshresult

Bryan Schumaker (2):
  NFS: Add sequence_priviliged_ops for nfs4_proc_sequence()
  NFS: Remove _nfs_call_sync_session

Jeff Layton (3):
  nfs: don't extend writes to cover entire page if pagecache is invalid
  nfs: don't zero out the rest of the page if we hit the EOF on a DIO READ
  nfs: fix page dirtying in NFS DIO read codepath

Jim Rees (1):
  NFS: Reduce stack use in encode_exchange_id()

NeilBrown (1):
  NFS: avoid NULL dereference in nfs_destroy_server

Stanislav Kinsbursky (1):
  SUNRPC: continue run over clients list on PipeFS event instead of break

Sven Wegener (1):
  NFSv4: Check for buffer length in __nfs4_get_acl_uncached

Trond Myklebust (68):
  NFS: Get rid of unnecessary asserts
  NFS: Remove asserts from the NFS XDR code
  NFSv4: Remove the BUG_ON() from nfs4_get_lease_time_prepare()...
  NFSv4.1: Remove unused function last_byte_offset
  NFSv4.1: Remove assertion BUG_ON()s from the files and generic layout code
  NFS: Remove BUG_ON() calls from the generic writeback code
  NFSv4: Get rid of unnecessary BUG_ON()s
  NFS: Remove BUG_ON()s in the fs/nfs/inode.c
  NFS: Remove the BUG_ON() in the mount code
  lockd: Remove unnecessary BUG_ON()s in the xdr client code
  lockd: Remove trivial BUG_ON()s from the NSM code
  lockd: Remove BUG_ON()s in fs/lockd/host.c
  lockd: Remove BUG_ON()s from fs/lockd/clntproc.c
  SUNRPC: Clean up rpc_bind_new_program
  SUNRPC: Fix validity issues with rpc_pipefs sb->s_fs_info
  NFSv4.1: Handle session reset and bind_conn_to_session before lease check
  NFSv4.1: Don't confuse CREATE_SESSION arguments and results
  NFSv4.1: Adjust CREATE_SESSION arguments when mounting a new filesystem
  NFSv4.1: We must bump the clientid sequence number after CREATE_SESSION
  NFSv4.1: nfs4_alloc_slots doesn't need zeroing
  NFSv4.1: clean up nfs4_recall_slot to use nfs4_alloc_slots
  NFSv4.1: Shrink struct nfs4_sequence_res by moving sr_renewal_time
  NFSv4: Fix a compile time warning when #undef CONFIG_NFS_V4_1
  NFSv4.1: Shrink struct nfs4_sequence_res by moving the session pointer
  NFSv4.1: Label each entry in the session slot tables with its slot number
  NFSv4.1: Simplify struct nfs4_sequence_args too
  NFSv4.1: Simplify slot allocation
  NFSv4.1: Clean up nfs4_free_slot
  NFSv4.1: Ensure that the client tracks the server target_highest_slotid
  NFSv4.1: Reset the sequence number for slots that have been deallocated
  NFSv4.1: Fix nfs4_callback_recallslot to work with dynamic slot allocation
  NFSv4.1: Don't confuse target_highest_slotid and max_slots in 
cb_recall_slot
  NFSv4.1: Allow the server to recall all but one slot
  NFSv4.1: Support dynamic resizing of the session slot table
  NFSv4.1: Allow SEQUENCE to resize the slot table on the fly
  NFSv4.1: Remove the state manager code to resize the slot table
  NFSv4.1: CB_RECALL_SLOT must schedule a sequence op after updating targets
  NFSv4.1: If slot allocation fails due to OOM, retry more quickly
  NFSv4.1: Clean up session draining
  NFSv4: Move nfs4_wait_clnt_recover and nfs4_client_recover_expired_lease
  NFSv4.1: Cleanup move session slot management to fs/nfs/nfs4session.c
  NFS: Remove unused function slot_idx
  NFSv4.1: Move slot table and sess

Re: [PATCH 1/4] ODROID-X: dts: Add board dts file for ODROID-X

[Thomas Abraham]

Hi Dongjin,

On 17 December 2012 13:55, Dongjin Kim  wrote:
> Add initial dtb file for Hardkernel's ODROID-X board based on EXYNOS4412 SoC.
>
> Signed-off-by: Dongjin Kim 
> ---
>  arch/arm/boot/dts/Makefile   |1 +
>  arch/arm/boot/dts/exynos4412-odroidx.dts |   52 
> ++
>  2 files changed, 53 insertions(+)
>  create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ca6fb8e..3355af9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -45,6 +45,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> exynos5250-smdk5250.dtb \
> exynos5440-ssdk5440.dtb \
> exynos4412-smdk4412.dtb \
> +   exynos4412-odroidx.dtb \
> exynos5250-smdk5250.dtb \
> exynos5250-snow.dtb
>  dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
> diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
> b/arch/arm/boot/dts/exynos4412-odroidx.dts
> new file mode 100644
> index 000..786ddd7
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
> @@ -0,0 +1,52 @@
> +/*
> + * Hardkernel's Exynos4412 based ODROID-X board device tree source
> + *
> + * Copyright (c) 2012-2013 Dongjin Kim 
> + *
> + * Device tree source file for Hardkernel's ODROID-X board which is based on
> + * Samsung's Exynos4412 SoC.
> + *
> + * 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.
> +*/
> +
> +/dts-v1/;
> +/include/ "exynos4412.dtsi"
> +
> +/ {
> +   model = "Hardkernel ODROID-X board based on Exynos4412";
> +   compatible = "samsung,exynos4412";
> +
> +   memory {
> +   reg = <0x4000 0x4000>;
> +   };
> +
> +   chosen {
> +   bootargs ="root=/dev/mmcblk0p3 rw console=ttySAC1,115200 
> init=/sbin/init delay=2";
> +   };
> +
> +   serial@1380 {
> +   status = "okay";
> +   };
> +
> +   serial@1381 {
> +   status = "okay";
> +   };
> +
> +   serial@1382 {
> +   status = "okay";
> +   };
> +
> +   serial@1383 {
> +   status = "okay";
> +   };
> +
> +   sdhci@1253 {
> +   bus-width = <4>;
> +   samsung,cd-pinmux-gpio = <&gpk2 2 2 3 3>;

The card detect line should also be configured using pinctrl
interface. When pinctrl is enabled on Exynos, the old-style gpio
bindings is not supported. So a pinctrl node for sd2_cmd should be
defined which then can be listed in pinctrl-0.

> +   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4>;
> +   pinctrl-names = "default";
> +   status = "okay";
> +   };
> +};
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] mm: Downgrade mmap_sem before locking or populating on mmap

[Andy Lutomirski]

This is a serious cause of mmap_sem contention.  MAP_POPULATE
and MCL_FUTURE, in particular, are disastrous in multithreaded programs.

This is not a complete solution due to reader/writer fairness.

Signed-off-by: Andy Lutomirski 
---

Changes from v2:

The mmap functions now unconditionally downgrade mmap_sem.  This is
slightly slower but a lot simpler.

Changes from v1:

The non-unlocking versions of do_mmap_pgoff and mmap_region are still
available for aio_setup_ring's benefit.  In theory, aio_setup_ring
would do better with a lock-downgrading version, but that would be
somewhat ugly and doesn't help my workload.

 arch/tile/mm/elf.c |  11 +++--
 fs/aio.c   |  11 ++---
 include/linux/mm.h |  15 +--
 ipc/shm.c  |   8 +++-
 mm/fremap.c|   9 +++-
 mm/mmap.c  | 122 -
 mm/util.c  |   5 ++-
 7 files changed, 123 insertions(+), 58 deletions(-)

diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 3cfa98b..313acb2 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -129,12 +129,15 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 */
if (!retval) {
unsigned long addr = MEM_USER_INTRPT;
-   addr = mmap_region(NULL, addr, INTRPT_SIZE,
-  MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE,
-  VM_READ|VM_EXEC|
-  VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, 0);
+   addr = mmap_region_downgrade_write(
+   NULL, addr, INTRPT_SIZE,
+   MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE,
+   VM_READ|VM_EXEC|
+   VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, 0);
+   up_read(&mm->mmap-sem);
if (addr > (unsigned long) -PAGE_SIZE)
retval = (int) addr;
+   return retval;  /* We already unlocked mmap_sem. */
}
 #endif
 
diff --git a/fs/aio.c b/fs/aio.c
index 71f613c..912d3d8 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -127,11 +127,12 @@ static int aio_setup_ring(struct kioctx *ctx)
info->mmap_size = nr_pages * PAGE_SIZE;
dprintk("attempting mmap of %lu bytes\n", info->mmap_size);
down_write(&ctx->mm->mmap_sem);
-   info->mmap_base = do_mmap_pgoff(NULL, 0, info->mmap_size, 
-   PROT_READ|PROT_WRITE,
-   MAP_ANONYMOUS|MAP_PRIVATE, 0);
+   info->mmap_base = do_mmap_pgoff_downgrade_write(
+   NULL, 0, info->mmap_size,
+   PROT_READ|PROT_WRITE,
+   MAP_ANONYMOUS|MAP_PRIVATE, 0);
if (IS_ERR((void *)info->mmap_base)) {
-   up_write(&ctx->mm->mmap_sem);
+   up_read(&ctx->mm->mmap_sem);
info->mmap_size = 0;
aio_free_ring(ctx);
return -EAGAIN;
@@ -141,7 +142,7 @@ static int aio_setup_ring(struct kioctx *ctx)
info->nr_pages = get_user_pages(current, ctx->mm,
info->mmap_base, nr_pages, 
1, 0, info->ring_pages, NULL);
-   up_write(&ctx->mm->mmap_sem);
+   up_read(&ctx->mm->mmap_sem);
 
if (unlikely(info->nr_pages != nr_pages)) {
aio_free_ring(ctx);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index bcaab4e..a44aa00 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1441,12 +1441,19 @@ extern int install_special_mapping(struct mm_struct *mm,
 
 extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned 
long, unsigned long, unsigned long);
 
-extern unsigned long mmap_region(struct file *file, unsigned long addr,
+/*
+ * These functions are called with mmap_sem held for write and they return
+ * with mmap_sem held for read.
+ */
+extern unsigned long mmap_region_downgrade_write(
+   struct file *file, unsigned long addr,
unsigned long len, unsigned long flags,
vm_flags_t vm_flags, unsigned long pgoff);
-extern unsigned long do_mmap_pgoff(struct file *, unsigned long,
-unsigned long, unsigned long,
-unsigned long, unsigned long);
+extern unsigned long do_mmap_pgoff_downgrade_write(
+   struct file *, unsigned long addr,
+   unsigned long len, unsigned long prot,
+   unsigned long flags, unsigned long pgoff);
+
 extern int do_munmap(struct mm_struct *, unsigned long, size_t);
 
 /* These take the mm semaphore themselves */
diff --git a/ipc/shm.c b/ipc/shm.c
index dff40c9..482f3d6 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1068,12 +1068,16 @@ long do_shmat(int shmid, char __user *shmaddr, int 
shmflg, ulong *raddr,
addr > current->mm->start_stack - size - PAGE_SIZE * 5)
goto invalid;
}
-   
-   user_addr = do_mmap_pgoff(file, addr, size, prot, flags, 0);
+
+   user_addr = do_mmap_pgoff_dow

Re: PATCH] backlight: add lms501kf03 LCD driver

[Jingoo Han]

On Monday, Monday, December 17, 2012 7:01 PM, Sachin Kamat wrote
> 
> Hi Jingoo,
> 
> I had already submitted a patch for adding support for this driver [1]
> and you had also provided your review comments on them ([2] and [3]).
> There were certain comments from Andrew Morton that needed to be addressed
> which I could not due to some other priorities.

CC'ed Ilho Lee

You have abandoned this patch for 7 months!

In addition, before you submitted a patch, it was already developed and
managed by me with Ilho Lee. So, ownership should be given to me and Ilho Lee.
Also, I am not sure that you can manage this lms501kf03 LCD driver.

> 
> IMO, it would be better to address comments on that driver rather than
> posting a new (similar) driver altogether.
> 
> [1] http://marc.info/?l=linux-fbdev&m=133455903202255&w=4
> [2] http://marc.info/?l=linux-fbdev&m=133574414215045&w=4
> [3] http://marc.info/?l=linux-fbdev&m=133576237619447&w=4
> 
> On 17 December 2012 13:52, Jingoo Han  wrote:
> > Add the lms501kf03 LCD panel driver. The lms501kf03 LCD panel (800
> > x 480) driver uses 3-wired SPI inteface.
> >
> > Signed-off-by: Ilho Lee 
> > Signed-off-by: Jingoo Han 
> > ---
> >  drivers/video/backlight/Kconfig  |8 +
> >  drivers/video/backlight/Makefile |1 +
> >  drivers/video/backlight/lms501kf03.c |  448 
> > ++
> >  3 files changed, 457 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/video/backlight/lms501kf03.c
> >
> > diff --git a/drivers/video/backlight/Kconfig 
> > b/drivers/video/backlight/Kconfig
> > index 765a945..081d6cf 100644
> > --- a/drivers/video/backlight/Kconfig
> > +++ b/drivers/video/backlight/Kconfig
> > @@ -126,6 +126,14 @@ config LCD_AMS369FG06
> >   If you have an AMS369FG06 AMOLED Panel, say Y to enable its
> >   LCD control driver.
> >
> > +config LCD_LMS501KF03
> > +   tristate "LMS501KF03 LCD Driver"
> > +   depends on SPI
> > +   default n
> > +   help
> > + If you have an LMS501KF03 LCD Panel, say Y to enable its
> > + LCD control driver.
> > +
> >  endif # LCD_CLASS_DEVICE
> >
> >  #
> > diff --git a/drivers/video/backlight/Makefile 
> > b/drivers/video/backlight/Makefile
> > index e7ce729..d02a728 100644
> > --- a/drivers/video/backlight/Makefile
> > +++ b/drivers/video/backlight/Makefile
> > @@ -14,6 +14,7 @@ obj-$(CONFIG_LCD_TOSA)   += tosa_lcd.o
> >  obj-$(CONFIG_LCD_S6E63M0)  += s6e63m0.o
> >  obj-$(CONFIG_LCD_LD9040)   += ld9040.o
> >  obj-$(CONFIG_LCD_AMS369FG06)   += ams369fg06.o
> > +obj-$(CONFIG_LCD_LMS501KF03)   += lms501kf03.o
> >
> >  obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
> >  obj-$(CONFIG_BACKLIGHT_ATMEL_PWM)+= atmel-pwm-bl.o
> > diff --git a/drivers/video/backlight/lms501kf03.c 
> > b/drivers/video/backlight/lms501kf03.c
> > new file mode 100644
> > index 000..c30ea53
> > --- /dev/null
> > +++ b/drivers/video/backlight/lms501kf03.c
> > @@ -0,0 +1,448 @@
> > +/*
> > + * lms501kf03 TFT LCD panel driver.
> > + *
> > + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> > + * Author: Jingoo Han  
> > + *
> > + * 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 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define ENDDEF 0xff00
> > +#define COMMAND_ONLY   0x00
> > +#define DATA_ONLY  0x01
> > +
> > +struct lms501kf03 {
> > +   struct device   *dev;
> > +   struct spi_device   *spi;
> > +   unsigned intpower;
> > +   struct lcd_device   *ld;
> > +   struct lcd_platform_data*lcd_pd;
> > +};
> > +
> > +static const unsigned short seq_password[] = {
> > +   0xb9, 0xff, 0x83, 0x69,
> > +   ENDDEF
> > +};
> > +
> > +static const unsigned short seq_power[] = {
> > +   0xb1, 0x01, 0x00, 0x34, 0x06, 0x00, 0x14, 0x14, 0x20, 0x28,
> > +   0x12, 0x12, 0x17, 0x0a, 0x01, 0xe6, 0xe6, 0xe6, 0xe6, 0xe6,
> > +   ENDDEF
> > +};
> > +
> > +static const unsigned short seq_display[] = {
> > +   0xb2, 0x00, 0x2b, 0x03, 0x03, 0x70, 0x00, 0xff, 0x00, 0x00,
> > +   0x00, 0x00, 0x03, 0x03, 0x00, 0x01,
> > +   ENDDEF
> > +};
> > +
> > +static const unsigned short seq_rgb_if[] = {
> > +   0xb3, 0x09,
> > +   ENDDEF
> > +};
> > +
> > +static const unsigned short seq_display_inv[] = {
> > +   0xb4, 0x01, 0x08, 0x77, 0x0e, 0x06,
> > +   ENDDEF
> > +};
> > +
> > +static const unsigned short seq_vcom[] = {
> > +   0xb6, 0x4c, 0x2e,
> > +   ENDDEF
> > +};
> > +
> > +static const unsigned short seq_gate[] = {
> > +   0xd5, 0x00, 0x05, 0x03, 0x29, 0x01, 0x07, 0x17, 0x68,

[PATCH 1/4] regulator: core: Allow specify apply_[reg|bit] for regmap based voltage_sel operations

[Axel Lin]

Some DVM regulators needs to update apply_bit after setting vsel_reg to
initiate voltage change on the output.  This patch adds apply_reg and
apply_bit to struct regulator_desc and update
regulator_set_voltage_sel_regmap() to set apply_bit of apply_reg when
apply_bit is set.

Signed-off-by: Axel Lin 
---
 drivers/regulator/core.c |   12 +++-
 include/linux/regulator/driver.h |6 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index a35858e..9afcdda3 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2074,10 +2074,20 @@ EXPORT_SYMBOL_GPL(regulator_get_voltage_sel_regmap);
  */
 int regulator_set_voltage_sel_regmap(struct regulator_dev *rdev, unsigned sel)
 {
+   int ret;
+
sel <<= ffs(rdev->desc->vsel_mask) - 1;
 
-   return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
+   ret = regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
  rdev->desc->vsel_mask, sel);
+   if (ret)
+   return ret;
+
+   if (rdev->desc->apply_bit)
+   ret = regmap_update_bits(rdev->regmap, rdev->desc->apply_reg,
+rdev->desc->apply_bit,
+rdev->desc->apply_bit);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_voltage_sel_regmap);
 
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index d10bb0f..23070fd 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -193,6 +193,10 @@ enum regulator_type {
  *
  * @vsel_reg: Register for selector when using regulator_regmap_X_voltage_
  * @vsel_mask: Mask for register bitfield used for selector
+ * @apply_reg: Register for initiate voltage change on the output when
+ *using regulator_set_voltage_sel_regmap
+ * @apply_bit: Register bitfield used for initiate voltage change on the
+ *output when using regulator_set_voltage_sel_regmap
  * @enable_reg: Register for control when using regmap enable/disable ops
  * @enable_mask: Mask for control when using regmap enable/disable ops
  *
@@ -218,6 +222,8 @@ struct regulator_desc {
 
unsigned int vsel_reg;
unsigned int vsel_mask;
+   unsigned int apply_reg;
+   unsigned int apply_bit;
unsigned int enable_reg;
unsigned int enable_mask;
unsigned int bypass_reg;
-- 
1.7.9.5



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

Re: [PATCH] firmware: make sure paths remain relative

[Ming Lei]

On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook  wrote:
> Some devices have configurable firmware locations. If these configuration
> mechanisms are exposed to unprivileged userspace, it may be possible to

I an wondering how the unprivileged userspace can write the firmware sysfs
to trigger loading firmware?

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

[PATCH 3/4] regulator: da9052: Use apply_[reg|bit] with regmap based voltage_sel operations

[Axel Lin]

Signed-off-by: Axel Lin 
---
 drivers/regulator/da9052-regulator.c |   41 +-
 1 file changed, 6 insertions(+), 35 deletions(-)

diff --git a/drivers/regulator/da9052-regulator.c 
b/drivers/regulator/da9052-regulator.c
index d096309..c6d8651 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -70,7 +70,6 @@ struct da9052_regulator_info {
int step_uV;
int min_uV;
int max_uV;
-   unsigned char activate_bit;
 };
 
 struct da9052_regulator {
@@ -210,36 +209,6 @@ static int da9052_map_voltage(struct regulator_dev *rdev,
return sel;
 }
 
-static int da9052_regulator_set_voltage_sel(struct regulator_dev *rdev,
-   unsigned int selector)
-{
-   struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
-   struct da9052_regulator_info *info = regulator->info;
-   int id = rdev_get_id(rdev);
-   int ret;
-
-   ret = da9052_reg_update(regulator->da9052, rdev->desc->vsel_reg,
-   rdev->desc->vsel_mask, selector);
-   if (ret < 0)
-   return ret;
-
-   /* Some LDOs and DCDCs are DVC controlled which requires enabling of
-* the activate bit to implment the changes on the output.
-*/
-   switch (id) {
-   case DA9052_ID_BUCK1:
-   case DA9052_ID_BUCK2:
-   case DA9052_ID_BUCK3:
-   case DA9052_ID_LDO2:
-   case DA9052_ID_LDO3:
-   ret = da9052_reg_update(regulator->da9052, DA9052_SUPPLY_REG,
-   info->activate_bit, info->activate_bit);
-   break;
-   }
-
-   return ret;
-}
-
 static struct regulator_ops da9052_dcdc_ops = {
.get_current_limit = da9052_dcdc_get_current_limit,
.set_current_limit = da9052_dcdc_set_current_limit,
@@ -247,7 +216,7 @@ static struct regulator_ops da9052_dcdc_ops = {
.list_voltage = da9052_list_voltage,
.map_voltage = da9052_map_voltage,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
-   .set_voltage_sel = da9052_regulator_set_voltage_sel,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
@@ -257,7 +226,7 @@ static struct regulator_ops da9052_ldo_ops = {
.list_voltage = da9052_list_voltage,
.map_voltage = da9052_map_voltage,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
-   .set_voltage_sel = da9052_regulator_set_voltage_sel,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
@@ -274,13 +243,14 @@ static struct regulator_ops da9052_ldo_ops = {
.owner = THIS_MODULE,\
.vsel_reg = DA9052_BUCKCORE_REG + DA9052_ID_##_id, \
.vsel_mask = (1 << (sbits)) - 1,\
+   .apply_reg = DA9052_SUPPLY_REG, \
+   .apply_bit = (abits), \
.enable_reg = DA9052_BUCKCORE_REG + DA9052_ID_##_id, \
.enable_mask = 1 << (ebits),\
},\
.min_uV = (min) * 1000,\
.max_uV = (max) * 1000,\
.step_uV = (step) * 1000,\
-   .activate_bit = (abits),\
 }
 
 #define DA9052_DCDC(_id, step, min, max, sbits, ebits, abits) \
@@ -294,13 +264,14 @@ static struct regulator_ops da9052_ldo_ops = {
.owner = THIS_MODULE,\
.vsel_reg = DA9052_BUCKCORE_REG + DA9052_ID_##_id, \
.vsel_mask = (1 << (sbits)) - 1,\
+   .apply_reg = DA9052_SUPPLY_REG, \
+   .apply_bit = (abits), \
.enable_reg = DA9052_BUCKCORE_REG + DA9052_ID_##_id, \
.enable_mask = 1 << (ebits),\
},\
.min_uV = (min) * 1000,\
.max_uV = (max) * 1000,\
.step_uV = (step) * 1000,\
-   .activate_bit = (abits),\
 }
 
 static struct da9052_regulator_info da9052_regulator_info[] = {
-- 
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/

[RFC][PATCH v6]trace,x86: add x86 irq vector tracepoints

[Seiji Aguchi]

Change log 

 v5 -> v6
 - Rebased to 3.7
 
 v4 -> v5
 - Rebased to 3.6.0

 - Introduce a logic switching IDT at enabling/disabling TP time 
   so that a time penalty makes a zero when tracepoints are disabled.
   This IDT is created only when CONFIG_TRACEPOINTS is enabled.

 - Remove arch_irq_vector_entry/exit and add followings again
   so that we can add each tracepoint in a generic way.
   - error_apic_vector
   - thermal_apic_vector
   - threshold_apic_vector
   - spurious_apic_vector
   - x86_platform_ipi_vector

 - Drop nmi tracepoints to begin with apic interrupts and discuss a logic 
switching
   IDT first.

 - Move irq_vectors.h in the directory of arch/x86/include/asm/trace because
   I'm not sure if a logic switching IDT is sharable with other architectures.

 v3 -> v4
 - Add a latency measurement of each tracepoint
 - Rebased to 3.6-rc6

 v2 -> v3
 - Remove an invalidate_tlb_vector event because it was replaced by a call 
function vector
   in a following commit.
   
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4

 v1 -> v2
 - Modify variable name from irq to vector.
 - Merge arch-specific tracepoints below to an arch_irq_vector_entry/exit.
   - error_apic_vector
   - thermal_apic_vector
   - threshold_apic_vector
   - spurious_apic_vector
   - x86_platform_ipi_vector

[Purpose of this patch]

As Vaibhav explained in the thread below, tracepoints for irq vectors
are useful.

http://www.spinics.net/lists/mm-commits/msg85707.html


The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled.  They provide good data about when
the system has switched to kernel space and how it affects the currently
running processes.

There are some IRQ vectors which trigger the system into kernel space,
which are not handled in generic IRQ handlers.  Tracing such events gives
us the information about IRQ interaction with other system events.

The trace also tells where the system is spending its time.  We want to
know which cores are handling interrupts and how they are affecting other
processes in the system.  Also, the trace provides information about when
the cores are idle and which interrupts are changing that state.


On the other hand, my usecase is tracing just local timer event and 
getting a value of instruction pointer.

  I suggested to add an argument local timer event to get instruction pointer 
before.
  But there is another way to get it with external module like systemtap.
  So, I don't need to add any argument to irq vector tracepoints now.

[Patch Description]

Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all 
events.
But there is an above use case to trace specific irq_vector rather than tracing 
all events.
In this case, we are concerned about overhead due to unwanted events.

This patch adds following tracepoints instead of introducing 
irq_vector_entry/exit.
so that we can enable them independently.
   - local_timer_vector
   - reschedule_vector
   - call_function_vector
   - call_function_single_vector 
   - irq_work_entry_vector
   - error_apic_vector
   - thermal_apic_vector
   - threshold_apic_vector
   - spurious_apic_vector
   - x86_platform_ipi_vector

Also, it introduces a logic switching IDT at enabling/disabling time so that a 
time penalty makes 
a complete zero when tracepoints are disabled. Detailed explanations are as 
follows.
 - Create new irq handlers inserted tracepoints by using macros.
 - Create a new IDT, trace_idt_table, at boot time by duplicating original IDT, 
idt table, and 
   registering the new handers for tracpoints.
 - Switch IDT to new one at enabling TP time.
 - Restore to an original IDT at disabling TP time.
The new IDT is created only when CONFIG_TRACEPOINTS is enabled to avoid being 
used for other purposes.

Signed-off-by: Seiji Aguchi 
---
 arch/x86/include/asm/desc.h  |   27 +
 arch/x86/include/asm/entry_arch.h|   32 +
 arch/x86/include/asm/hw_irq.h|   14 +++
 arch/x86/kernel/Makefile |1 +
 arch/x86/kernel/apic/apic.c  |  186 +-
 arch/x86/kernel/cpu/mcheck/therm_throt.c |   26 +++--
 arch/x86/kernel/cpu/mcheck/threshold.c   |   27 +++--
 arch/x86/kernel/entry_64.S   |   33 ++
 arch/x86/kernel/head_64.S|6 +
 arch/x86/kernel/irq.c|   44 ---
 arch/x86/kernel/irq_work.c   |   22 +++-
 arch/x86/kernel/irqinit.c|2 +
 arch/x86/kernel/smp.c|   68 
 13 files changed, 345 insertions(+), 143 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 8bf1c06..52becf4 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -345,6 +345,33 @@ static inline void set_intr_gate(unsigned int n, void 
*addr)
_set_gate(n, GATE_INTERRUPT, addr, 0, 0

Re: [PATCH 3/3] ARM: Dove: add Cubox sdhci card detect gpio

[Jason Cooper]

On Tue, Dec 18, 2012 at 01:50:12AM +0100, Sebastian Hesselbarth wrote:
> On 12/18/2012 01:38 AM, Jason Cooper wrote:
> > On Tue, Dec 18, 2012 at 01:24:29AM +0100, Sebastian Hesselbarth wrote:
> >> Card detect for sdhci on Cubox is connected to the wrong pin
> >> (sdio1_cd instead of sdio0_cd). With support for cd-gpios and
> >> pinctrl add the corresponding properties to DT for Cubox.
> >>
> >> Signed-off-by: Sebastian Hesselbarth
> >> ...
> >> +&sdio0 {
> >> +  status = "okay";
> >> +  /* sdio0 card detect is connected to wrong pin on CuBox */
> >> +  cd-gpios =<&gpio0 12 1>;
> >
> > this looks like a fix that should be merged into v3.8, I'll cue it up
> > for v3.8-rc2.
> 
> Jason,
> 
> it is more a feature than a fix, as gpio-cd support for sdhci-dove
> moved in lately. You want me to split this patch from the other two
> (that I'll reorder as requested)?

I was referring to the code more than the physical feature itself.  You
appear to remove the default &sdio0, and replace it with a working
version.  Looked like a fix to me ;-)

No need to send it separate, I'll apply it as is once v3.8-rc1 drops.

thx,

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

[PATCH 2/4] regulator: 88pm8607: Use apply_[reg|bit] with regmap based voltage_sel operations

[Axel Lin]

Signed-off-by: Axel Lin 
---
 drivers/regulator/88pm8607.c |   43 --
 1 file changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index 2b55711..9ebdf8c 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -30,8 +30,6 @@ struct pm8607_regulator_info {
unsigned int*vol_table;
unsigned int*vol_suspend;
 
-   int update_reg;
-   int update_bit;
int slope_double;
 };
 
@@ -222,29 +220,6 @@ static int pm8607_list_voltage(struct regulator_dev *rdev, 
unsigned index)
return ret;
 }
 
-static int pm8607_set_voltage_sel(struct regulator_dev *rdev, unsigned 
selector)
-{
-   struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
-   uint8_t val;
-   int ret;
-
-   val = (uint8_t)(selector << (ffs(rdev->desc->vsel_mask) - 1));
-
-   ret = pm860x_set_bits(info->i2c, rdev->desc->vsel_reg,
- rdev->desc->vsel_mask, val);
-   if (ret)
-   return ret;
-   switch (info->desc.id) {
-   case PM8607_ID_BUCK1:
-   case PM8607_ID_BUCK3:
-   ret = pm860x_set_bits(info->i2c, info->update_reg,
- 1 << info->update_bit,
- 1 << info->update_bit);
-   break;
-   }
-   return ret;
-}
-
 static int pm8606_preg_enable(struct regulator_dev *rdev)
 {
struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
@@ -276,7 +251,7 @@ static int pm8606_preg_is_enabled(struct regulator_dev 
*rdev)
 
 static struct regulator_ops pm8607_regulator_ops = {
.list_voltage   = pm8607_list_voltage,
-   .set_voltage_sel = pm8607_set_voltage_sel,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
@@ -313,11 +288,11 @@ static struct regulator_ops pm8606_preg_ops = {
.n_voltages = ARRAY_SIZE(vreg##_table), \
.vsel_reg = PM8607_##vreg,  \
.vsel_mask = ARRAY_SIZE(vreg##_table) - 1,  \
+   .apply_reg = PM8607_##ureg, \
+   .apply_bit = (ubit),\
.enable_reg = PM8607_##ereg,\
.enable_mask = 1 << (ebit), \
},  \
-   .update_reg = PM8607_##ureg,\
-   .update_bit = (ubit),   \
.slope_double   = (0),  \
.vol_table  = (unsigned int *)&vreg##_table,\
.vol_suspend= (unsigned int *)&vreg##_suspend_table,\
@@ -343,9 +318,15 @@ static struct regulator_ops pm8606_preg_ops = {
 }
 
 static struct pm8607_regulator_info pm8607_regulator_info[] = {
-   PM8607_DVC(BUCK1, GO, 0, SUPPLIES_EN11, 0),
-   PM8607_DVC(BUCK2, GO, 1, SUPPLIES_EN11, 1),
-   PM8607_DVC(BUCK3, GO, 2, SUPPLIES_EN11, 2),
+   PM8607_DVC(BUCK1, GO, BIT(0), SUPPLIES_EN11, 0),
+   /*
+* BUCK2 is designed to control voltage of CP domain.
+* Linux only runs in AP side, so we don't need to control BUCK2 in AP
+* side. Thus set the apply bit to be 0 instead of BIT(1) to avoid
+* updating apply_bit for BUCK2.
+*/
+   PM8607_DVC(BUCK2, GO, 0, SUPPLIES_EN11, 1),
+   PM8607_DVC(BUCK3, GO, BIT(2), SUPPLIES_EN11, 2),
 
PM8607_LDO(1, LDO1, 0, SUPPLIES_EN11, 3),
PM8607_LDO(2, LDO2, 0, SUPPLIES_EN11, 4),
-- 
1.7.9.5



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

Re: [PATCH] resubmit w1_therm:Retries:remove old code add CRC

[david]

w1_therm includes some obsolete code to detect bad_roms, this is no
longer relevant.
The retry code is only used for this bad_rom test, however there is a
CRC check that detects a bad read, but does not trigger a retry. This
patch removes all the bad_rom code and uses the CRC check to trigger
retries.

Signed-off-by: David Stevenson 

diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 92d08e7..5ef583d 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -45,10 +45,6 @@ MODULE_DESCRIPTION("Driver for 1-wire Dallas network 
protocol, temperature famil
 static int w1_strong_pullup = 1;
 module_param_named(strong_pullup, w1_strong_pullup, int, 0);
 
-static u8 bad_roms[][9] = {

-   {0xaa, 0x00, 0x4b, 0x46, 0xff, 0xff, 0x0c, 
0x10, 0x87},
-   {}
-   };
 
 static ssize_t w1_therm_read(struct device *device,

struct device_attribute *attr, char *buf);
@@ -168,16 +164,6 @@ static inline int w1_convert_temp(u8 rom[9], u8 fid)
return 0;
 }
 
-static int w1_therm_check_rom(u8 rom[9])

-{
-   int i;
-
-   for (i=0; i 
 static ssize_t w1_therm_read(struct device *device,

struct device_attribute *attr, char *buf)
@@ -194,10 +180,11 @@ static ssize_t w1_therm_read(struct device *device,
 
 	memset(rom, 0, sizeof(rom));
 
-	verdict = 0;

-   crc = 0;
-
while (max_trying--) {
+
+   verdict = 0;
+   crc = 0;
+
if (!w1_reset_select_slave(sl)) {
int count = 0;
unsigned int tm = 750;
@@ -249,7 +236,7 @@ static ssize_t w1_therm_read(struct device *device,
}
}
 
-		if (!w1_therm_check_rom(rom))

+   if (verdict)
break;
}
 
@@ -260,7 +247,7 @@ static ssize_t w1_therm_read(struct device *device,

if (verdict)
memcpy(sl->rom, rom, sizeof(sl->rom));
else
-   dev_warn(device, "18S20 doesn't respond to CONVERT_TEMP.\n");
+   dev_warn(device, "Read failed CRC check\n");
 
 	for (i = 0; i < 9; ++i)

c -= snprintf(buf + PAGE_SIZE - c, c, "%02x ", sl->rom[i]);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Are there u32 atomic bitops? (or dealing w/ i_flags)

[Ming Lei]

On Tue, Dec 18, 2012 at 9:10 AM, Andy Lutomirski  wrote:
> I want to change inode->i_flags access to be atomic -- there are some
> locking oddities right now, I think, and I want to use a new inode
> flag to signal mtime updates from page_mkwrite.  The problem is that
> i_flags is an unsigned int, and making it an unsigned long seems like
> a waste, but there aren't any u32 atomic bitops.

See below in include/linux/types.h

typedef struct {
int counter;
} atomic_t;

#ifdef CONFIG_64BIT
typedef struct {
long counter;
} atomic64_t;
#endif



Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 rev.2 1/6] ACPI: Separate adding ACPI device objects from probing ACPI drivers

[Rafael J. Wysocki]

On Monday, December 17, 2012 05:08:17 PM Toshi Kani wrote:
> On Thu, 2012-12-13 at 23:17 +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> 
> (snip)
> 
> >  struct acpi_device_ops {
> > Index: linux/drivers/acpi/scan.c
> > ===
> > --- linux.orig/drivers/acpi/scan.c
> > +++ linux/drivers/acpi/scan.c
> > @@ -494,7 +494,8 @@ static int acpi_bus_match(struct device
> > struct acpi_device *acpi_dev = to_acpi_device(dev);
> > struct acpi_driver *acpi_drv = to_acpi_driver(drv);
> >  
> > -   return !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
> > +   return acpi_dev->bus_ops.acpi_op_match
> > +   && !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
> >  }
> >  
> >  static int acpi_device_uevent(struct device *dev, struct kobj_uevent_env 
> > *env)
> > @@ -1418,6 +1419,17 @@ static int acpi_bus_remove(struct acpi_d
> > return 0;
> >  }
> >  
> > +/*
> > + * acpi_hot_add_bind - Bind _ADR-based devices on hot-add.
> > + * @device: ACPI device node to bind.
> > + */
> > +static void acpi_hot_add_bind(struct acpi_device *device)
> > +{
> > +   if (device->flags.bus_address
> > +   && device->parent && device->parent->ops.bind)
> > +   device->parent->ops.bind(device);
> > +}
> > +
> >  static int acpi_add_single_object(struct acpi_device **child,
> >   acpi_handle handle, int type,
> >   unsigned long long sta,
> > @@ -1490,13 +1502,8 @@ static int acpi_add_single_object(struct
> >  
> > result = acpi_device_register(device);
> >  
> > -   /*
> > -* Bind _ADR-Based Devices when hot add
> > -*/
> > -   if (device->flags.bus_address) {
> > -   if (device->parent && device->parent->ops.bind)
> > -   device->parent->ops.bind(device);
> > -   }
> 
> I think the original code above is hot-add only because ops.bind is not
> set at boot since the acpi_pci driver has not been registered yet.  It
> seems that acpi_pci_bridge_scan() called from acpi_pci_root_add() takes
> care of the binding.

Ah, I see the problem.  During boot the PCI root bridge driver is not present
yet when all struct acpi_device "devices" are registered, so their parents'
.bind() callbacks are all empty, so the code above has no effect.

But say we're doing a PCI root bridge hotplug, in which case the driver is
present, so acpi_pci_bind() will be executed both from acpi_pci_bridge_scan()
and from here, won't it?

OK, this needs to be addressed.

> This brings me a question for acpi_bus_probe_start() below...
> 
> 
> > +   if (device->bus_ops.acpi_op_match)
> > +   acpi_hot_add_bind(device);
> >  
> >  end:
> > if (!result) {
> > @@ -1522,6 +1529,7 @@ static void acpi_bus_add_power_resource(
> > struct acpi_bus_ops ops = {
> > .acpi_op_add = 1,
> > .acpi_op_start = 1,
> > +   .acpi_op_match = 1,
> > };
> > struct acpi_device *device = NULL;
> >  
> > @@ -1574,9 +1582,9 @@ static acpi_status acpi_bus_check_add(ac
> >   void *context, void **return_value)
> >  {
> > struct acpi_bus_ops *ops = context;
> > +   struct acpi_device *device = NULL;
> > int type;
> > unsigned long long sta;
> > -   struct acpi_device *device;
> > acpi_status status;
> > int result;
> >  
> > @@ -1596,52 +1604,86 @@ static acpi_status acpi_bus_check_add(ac
> > return AE_CTRL_DEPTH;
> > }
> >  
> > -   /*
> > -* We may already have an acpi_device from a previous enumeration.  If
> > -* so, we needn't add it again, but we may still have to start it.
> > -*/
> > -   device = NULL;
> > acpi_bus_get_device(handle, &device);
> > if (ops->acpi_op_add && !device) {
> > -   acpi_add_single_object(&device, handle, type, sta, ops);
> > -   /* Is the device a known good platform device? */
> > -   if (device
> > -   && !acpi_match_device_ids(device, acpi_platform_device_ids))
> > -   acpi_create_platform_device(device);
> > -   }
> > -
> > -   if (!device)
> > -   return AE_CTRL_DEPTH;
> > +   struct acpi_bus_ops add_ops = *ops;
> >  
> > -   if (ops->acpi_op_start && !(ops->acpi_op_add)) {
> > -   status = acpi_start_single_object(device);
> > -   if (ACPI_FAILURE(status))
> > +   add_ops.acpi_op_match = 0;
> > +   acpi_add_single_object(&device, handle, type, sta, &add_ops);
> > +   if (!device)
> > return AE_CTRL_DEPTH;
> > +
> > +   device->bus_ops.acpi_op_match = 1;
> > }
> >  
> > if (!*return_value)
> > *return_value = device;
> > +
> > return AE_OK;
> >  }
> >  
> > +static acpi_status acpi_bus_probe_start(acpi_handle handle, u32 lvl,
> > +   void *context, void **not_used)
> > +{
> > +   struct acpi_bus_ops *ops = context;
> > +   acpi_status status 

Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

[Yinghai Lu]

On Mon, Dec 17, 2012 at 5:11 PM, Yinghai Lu  wrote:
> On Mon, Dec 17, 2012 at 3:26 PM, Yinghai Lu  wrote:
>> On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin  wrote:
>>> On 12/17/2012 02:47 PM, Yinghai Lu wrote:


 Peter, can you check that branch again?

 I moved the early_trap_init after init_mem_mapping.
 so for 64bit native, init_mem_mapping will setup page table for ram from
 blank.

>>>
>>> Looks better, at first glance at least.  There are a couple of unnecessary
>>> changes (the counter in head_64.S cannot exceed 32 bits once computed, so
>>> the change from %rcx to %ecx change is pointless.)
>>
>> ok,  return to use %ecx
>>
>>>
>>> There is another bug in my patch: it either needs to mask off the NX bit if
>>> we are running on non-NX-enabled hardware, or it needs to not set the NX bit
>>> (which is mostly okay that early on, I suspect.)
>>
>> i test that in kvm guest, and westmere, current version seem ok.
>>
>> will repost the patchset to list to get more review.
>>
>
> not sure if i could move that early_trap_init down.
>
> jason,
>
> We need to move down early_trap_init after init_memory_mapping to use
> early #PF handler to set page table.
>
> So can we do that? for kgdb it is that ok to move it down?

adding to Jan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: dac: ad5446: Don't set error code to voltage_uv

[Axel Lin]

regulator_get_voltage() may return negative error code.
Add error checking to avoid setting error code to voltage_uv.

Signed-off-by: Axel Lin 
---
 drivers/iio/dac/ad5446.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/dac/ad5446.c b/drivers/iio/dac/ad5446.c
index 3310cbb..607378f 100644
--- a/drivers/iio/dac/ad5446.c
+++ b/drivers/iio/dac/ad5446.c
@@ -226,7 +226,11 @@ static int __devinit ad5446_probe(struct device *dev, 
const char *name,
if (ret)
goto error_put_reg;
 
-   voltage_uv = regulator_get_voltage(reg);
+   ret = regulator_get_voltage(reg);
+   if (ret)
+   goto error_disable_reg;
+
+   voltage_uv = ret;
}
 
indio_dev = iio_device_alloc(sizeof(*st));
-- 
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: Are there u32 atomic bitops? (or dealing w/ i_flags)

[Al Viro]

On Mon, Dec 17, 2012 at 05:10:21PM -0800, Andy Lutomirski wrote:
> I want to change inode->i_flags access to be atomic -- there are some
> locking oddities right now, I think, and I want to use a new inode
> flag to signal mtime updates from page_mkwrite.  The problem is that
> i_flags is an unsigned int, and making it an unsigned long seems like
> a waste, but there aren't any u32 atomic bitops.

... and atomic accesses cost more.  A lot more on some architectures.
FWIW, atomic_t *is* 32bit on 32bit architectures, which still doesn't
make it a good idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/