linux.kernel - 26 new messages in 19 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* Input: synaptics-rmi4 - rework transport device allocation - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/127bd12f65fad9d0?hl=en
* VELGØRENHED BISTAND - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/314062796b286406?hl=en
* re-shrink 'struct page' when SLUB is on. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d6d1692f51c2de27?hl=en
* Documentation: DT: omap-ssi binding documentation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eeb43e2db54d8847?hl=en
* lib/vsprintf: add %pT format specifier - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/798326cec82e4895?hl=en
* ACPI/SCAN: _STA status read - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/332c7e2cd251892f?hl=en
* APM - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c8506cae9a47bc63?hl=en
* kernfs, sysfs, driver-core: implement synchronous self-removal - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/b72ccc5edcdfb313?hl=en
* dt-bindings: pci: xgene pcie device tree bindings - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bb793bfb4a89dad9?hl=en
* cpuidle: rework device state count handling - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/06bf48773e084467?hl=en
* Bluetooth: Add hci_h4p driver - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5851dede4d9d0250?hl=en
* dma-debug: enhance dma_debug_device_change() to check for mapping errors - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/9225e1a50c795de9?hl=en
* mm/swap: fix race on swap_info reuse between swapoff and swapon - 2 messages,
1 author
http://groups.google.com/group/linux.kernel/t/c7226daad86a019b?hl=en
* dt: binding documentation for bq2415x charger - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/449dac390dc0190d?hl=en
* mm/memblock: Add memblock memory allocation apis - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/0273d0da4b062687?hl=en
* pinctrl: tegra1x4: initialize at arch_initcall time - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1eeecd995959785f?hl=en
* Unable to load modules from 9p filesystem with kmod 16 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/57bf21c25663646c?hl=en
* Documentation: add dts binding for X-Gene reboot dts node. - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/12227fdb34cca7d6?hl=en
* [PATCH 1/3] f2fs: move grabing orphan pages out of protection region - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/28d651f093c9c162?hl=en

==============================================================================
TOPIC: Input: synaptics-rmi4 - rework transport device allocation
http://groups.google.com/group/linux.kernel/t/127bd12f65fad9d0?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 3:40 pm
From: Christopher Heiny


On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
> Instead of allocating common and private part of transport device
> separately make private wrap common part and get rid of private data
> pointer in the transport device.
>
> Also rename rmi_i2c_data -> rmi_i2c_xport and data -> rmi_i2c.

Acked-by: Christopher Heiny <cheiny@synaptics.com>

>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/rmi4/rmi_bus.h | 3 --
> drivers/input/rmi4/rmi_i2c.c | 112 +++++++++++++++++++++----------------------
> 2 files changed, 56 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
> index ccf26dc..decb479 100644
> --- a/drivers/input/rmi4/rmi_bus.h
> +++ b/drivers/input/rmi4/rmi_bus.h
> @@ -165,7 +165,6 @@ struct rmi_transport_stats {
> * default irq_thread implementation.
> * @hard_irq: if not NULL, the sensor driver will use this for the hard IRQ
> * handling
> - * @data: Private data pointer
> * @proto_name: name of the transport protocol (SPI, i2c, etc)
> * @ops: pointer to transport operations implementation
> * @stats: transport statistics
> @@ -181,8 +180,6 @@ struct rmi_transport_dev {
> irqreturn_t (*irq_thread)(int irq, void *p);
> irqreturn_t (*hard_irq)(int irq, void *p);
>
> - void *data;
> -
> const char *proto_name;
> const struct rmi_transport_ops *ops;
> struct rmi_transport_stats stats;
> diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
> index 40badf3..cdc8527 100644
> --- a/drivers/input/rmi4/rmi_i2c.c
> +++ b/drivers/input/rmi4/rmi_i2c.c
> @@ -17,22 +17,25 @@
> #define BUFFER_SIZE_INCREMENT 32
>
> /**
> - * struct rmi_i2c_data - stores information for i2c communication
> + * struct rmi_i2c_xport - stores information for i2c communication
> + *
> + * @xport: The transport interface structure
> *
> * @page_mutex: Locks current page to avoid changing pages in unexpected ways.
> * @page: Keeps track of the current virtual page
> - * @xport: Pointer to the transport interface
> *
> * @tx_buf: Buffer used for transmitting data to the sensor over i2c.
> * @tx_buf_size: Size of the buffer
> */
> -struct rmi_i2c_data {
> +struct rmi_i2c_xport {
> + struct rmi_transport_dev xport;
> + struct i2c_client *client;
> +
> struct mutex page_mutex;
> int page;
> - struct rmi_transport_dev *xport;
>
> u8 *tx_buf;
> - int tx_buf_size;
> + size_t tx_buf_size;
> };
>
> #define RMI_PAGE_SELECT_REGISTER 0xff
> @@ -52,10 +55,10 @@ struct rmi_i2c_data {
> *
> * Returns zero on success, non-zero on failure.
> */
> -static int rmi_set_page(struct rmi_transport_dev *xport, u8 page)
> +static int rmi_set_page(struct rmi_i2c_xport *rmi_i2c, u8 page)
> {
> - struct i2c_client *client = to_i2c_client(xport->dev);
> - struct rmi_i2c_data *data = xport->data;
> + struct rmi_transport_dev *xport = &rmi_i2c->xport;
> + struct i2c_client *client = rmi_i2c->client;
> u8 txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
> int retval;
>
> @@ -70,37 +73,40 @@ static int rmi_set_page(struct rmi_transport_dev *xport, u8 page)
> "%s: set page failed: %d.", __func__, retval);
> return (retval < 0) ? retval : -EIO;
> }
> - data->page = page;
> + rmi_i2c->page = page;
> return 0;
> }
>
> static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
> const void *buf, size_t len)
> {
> - struct i2c_client *client = to_i2c_client(xport->dev);
> - struct rmi_i2c_data *data = xport->data;
> + struct rmi_i2c_xport *rmi_i2c =
> + container_of(xport, struct rmi_i2c_xport, xport);
> + struct i2c_client *client = rmi_i2c->client;
> size_t tx_size = len + 1;
> int retval;
>
> - mutex_lock(&data->page_mutex);
> -
> - if (!data->tx_buf || data->tx_buf_size < tx_size) {
> - if (data->tx_buf)
> - devm_kfree(&client->dev, data->tx_buf);
> - data->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
> - data->tx_buf = devm_kzalloc(&client->dev, data->tx_buf_size,
> - GFP_KERNEL);
> - if (!data->tx_buf) {
> - data->tx_buf_size = 0;
> + mutex_lock(&rmi_i2c->page_mutex);
> +
> + if (!rmi_i2c->tx_buf || rmi_i2c->tx_buf_size < tx_size) {
> + if (rmi_i2c->tx_buf)
> + devm_kfree(&client->dev, rmi_i2c->tx_buf);
> + rmi_i2c->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
> + rmi_i2c->tx_buf = devm_kzalloc(&client->dev,
> + rmi_i2c->tx_buf_size,
> + GFP_KERNEL);
> + if (!rmi_i2c->tx_buf) {
> + rmi_i2c->tx_buf_size = 0;
> retval = -ENOMEM;
> goto exit;
> }
> }
> - data->tx_buf[0] = addr & 0xff;
> - memcpy(data->tx_buf + 1, buf, len);
>
> - if (RMI_I2C_PAGE(addr) != data->page) {
> - retval = rmi_set_page(xport, RMI_I2C_PAGE(addr));
> + rmi_i2c->tx_buf[0] = addr & 0xff;
> + memcpy(rmi_i2c->tx_buf + 1, buf, len);
> +
> + if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
> + retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
> if (retval < 0)
> goto exit;
> }
> @@ -110,29 +116,30 @@ static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
>
> xport->stats.tx_count++;
> xport->stats.tx_bytes += tx_size;
> - retval = i2c_master_send(client, data->tx_buf, tx_size);
> + retval = i2c_master_send(client, rmi_i2c->tx_buf, tx_size);
> if (retval < 0)
> xport->stats.tx_errs++;
> else
> retval--; /* don't count the address byte */
>
> exit:
> - mutex_unlock(&data->page_mutex);
> + mutex_unlock(&rmi_i2c->page_mutex);
> return retval;
> }
>
> static int rmi_i2c_read_block(struct rmi_transport_dev *xport, u16 addr,
> void *buf, size_t len)
> {
> - struct i2c_client *client = to_i2c_client(xport->dev);
> - struct rmi_i2c_data *data = xport->data;
> + struct rmi_i2c_xport *rmi_i2c =
> + container_of(xport, struct rmi_i2c_xport, xport);
> + struct i2c_client *client = rmi_i2c->client;
> u8 txbuf[1] = {addr & 0xff};
> int retval;
>
> - mutex_lock(&data->page_mutex);
> + mutex_lock(&rmi_i2c->page_mutex);
>
> - if (RMI_I2C_PAGE(addr) != data->page) {
> - retval = rmi_set_page(xport, RMI_I2C_PAGE(addr));
> + if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
> + retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
> if (retval < 0)
> goto exit;
> }
> @@ -160,7 +167,7 @@ static int rmi_i2c_read_block(struct rmi_transport_dev *xport, u16 addr,
> len, addr, (int)len, buf);
>
> exit:
> - mutex_unlock(&data->page_mutex);
> + mutex_unlock(&rmi_i2c->page_mutex);
> return retval;
> }
>
> @@ -174,14 +181,14 @@ static int rmi_i2c_probe(struct i2c_client *client,
> {
> const struct rmi_device_platform_data *pdata =
> dev_get_platdata(&client->dev);
> - struct rmi_transport_dev *xport;
> - struct rmi_i2c_data *data;
> + struct rmi_i2c_xport *rmi_i2c;
> int retval;
>
> if (!pdata) {
> dev_err(&client->dev, "no platform data\n");
> return -EINVAL;
> }
> +
> dev_dbg(&client->dev, "Probing %s at %#02x (GPIO %d).\n",
> pdata->sensor_name ? pdata->sensor_name : "-no name-",
> client->addr, pdata->attn_gpio);
> @@ -202,44 +209,36 @@ static int rmi_i2c_probe(struct i2c_client *client,
> }
> }
>
> - xport = devm_kzalloc(&client->dev, sizeof(struct rmi_transport_dev),
> + rmi_i2c = devm_kzalloc(&client->dev, sizeof(struct rmi_i2c_xport),
> GFP_KERNEL);
> -
> - if (!xport)
> + if (!rmi_i2c)
> return -ENOMEM;
>
> - data = devm_kzalloc(&client->dev, sizeof(struct rmi_i2c_data),
> - GFP_KERNEL);
> - if (!data)
> - return -ENOMEM;
> -
> - data->xport = xport;
> -
> - xport->data = data;
> - xport->dev = &client->dev;
> + rmi_i2c->client = client;
> + mutex_init(&rmi_i2c->page_mutex);
>
> - xport->proto_name = "i2c";
> - xport->ops = &rmi_i2c_ops;
> -
> - mutex_init(&data->page_mutex);
> + rmi_i2c->xport.dev = &client->dev;
> + rmi_i2c->xport.proto_name = "i2c";
> + rmi_i2c->xport.ops = &rmi_i2c_ops;
>
> /*
> * Setting the page to zero will (a) make sure the PSR is in a
> * known state, and (b) make sure we can talk to the device.
> */
> - retval = rmi_set_page(xport, 0);
> + retval = rmi_set_page(rmi_i2c, 0);
> if (retval) {
> dev_err(&client->dev, "Failed to set page select to 0.\n");
> return retval;
> }
>
> - retval = rmi_register_transport_device(xport);
> + retval = rmi_register_transport_device(&rmi_i2c->xport);
> if (retval) {
> dev_err(&client->dev, "Failed to register transport driver at 0x%.2X.\n",
> client->addr);
> goto err_gpio;
> }
> - i2c_set_clientdata(client, xport);
> +
> + i2c_set_clientdata(client, rmi_i2c);
>
> dev_info(&client->dev, "registered rmi i2c driver at %#04x.\n",
> client->addr);
> @@ -248,16 +247,17 @@ static int rmi_i2c_probe(struct i2c_client *client,
> err_gpio:
> if (pdata->gpio_config)
> pdata->gpio_config(pdata->gpio_data, false);
> +
> return retval;
> }
>
> static int rmi_i2c_remove(struct i2c_client *client)
> {
> - struct rmi_transport_dev *xport = i2c_get_clientdata(client);
> const struct rmi_device_platform_data *pdata =
> dev_get_platdata(&client->dev);
> + struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
>
> - rmi_unregister_transport_device(xport);
> + rmi_unregister_transport_device(&rmi_i2c->xport);
>
> if (pdata->gpio_config)
> pdata->gpio_config(pdata->gpio_data, false);
>


--

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





==============================================================================
TOPIC: VELGØRENHED BISTAND
http://groups.google.com/group/linux.kernel/t/314062796b286406?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 3:50 pm
From: "Rod Thompson"


VELG�RENHED BISTAND

Hej Ven .

Mens du l�ser dette , jeg vil have dig til at blive r�rt , fordi jeg tror,
&#8203;&#8203;at alle vil d� en dag. Mit navn er Rod Thompson, en k�bmand
.

Jeg er blevet diagnosticeret med kr�ft i spiser�ret . Det har besmittet
alle former for medicinsk behandling, og lige nu har jeg kun omkring et
par m�neder at leve i henhold til medicinske eksperter . Jeg har ikke
s�rlig levet mit liv s� godt, som jeg aldrig rigtig passet for nogen (ikke
engang mig selv ), men min forretning. Selvom jeg er meget rig , var jeg
aldrig gavmild , jeg kun fokuseret p� min virksomhed , da det var det
eneste, jeg plejet. Men nu jeg fortryder alt dette, som jeg ved nu, at der
er mere i livet end bare �nsker at have eller g�re alle de penge i verden.

Jeg tror, &#8203;&#8203;n�r Gud giver mig en chance for at komme til denne
verden, jeg ville leve mit liv p� en anden m�de fra, hvordan jeg har levet
det . Nu, Gud har kaldet mig, jeg har villet og givet det meste af min
ejendom og aktiver til min umiddelbare og udvidede familiemedlemmer samt
et par n�re venner.

Jeg �nsker Gud at v�re barmhjertig til mig og acceptere min sj�l, s� jeg
har besluttet at give almisser til velg�rende organisationer , som jeg vil
have det til at v�re en af &#8203;&#8203;de sidste gode gerninger , jeg
g�r p� jorden.

Nu, mit helbred er forv�rret s� d�rligt , kan jeg ikke g�re det selv
l�ngere. Jeg spurgte engang medlemmer af min familie at lukke en af
&#8203;&#8203;mine konti og distribuere de penge, som jeg har der til
velg�renhed organisation i Bulgarien og Pakistan , de n�gtede og beholdt
pengene til sig selv. Derfor beh�ver jeg ikke stoler p� dem l�ngere, som
de synes ikke at v�re tilfreds med hvad jeg har tilbage for dem.

Den sidste af mine penge , som ingen kender , er den enorme kontant
depositum p� 6 millioner euro. (Seks millioner euro) , som jeg har med en
finansiel institution i Holland. Jeg vil have dig til at hj�lpe mig at
indsamle dette depositum og sendt det til velg�rende organisationer , jeg
har n�vnt ovenfor. Jeg har afsat 15% for dig og for din tid.

Gud v�re med dig . bedes du svar p� min private e-mail :
rodthompson50@aol.com

Hilsen ,

Rod Thompson ( rodthompson50@aol.com )




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





==============================================================================
TOPIC: re-shrink 'struct page' when SLUB is on.
http://groups.google.com/group/linux.kernel/t/d6d1692f51c2de27?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 3:50 pm
From: Dave Hansen


On 01/10/2014 03:39 PM, Andrew Morton wrote:
>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The
>> first 3 are with vanilla upstream kernel source. The 4th is patched
>> with my new slub code (all single-threaded):
>>
>> http://www.sr71.net/~dave/intel/slub/slub-perf-20140109.png
>
> So we're converging on the most complex option. argh.

Yeah, looks that way.

> So all this testing was performed in a VM? If so, how much is that
> likely to have impacted the results?

Nope, none of it was in a VM. All the results here are from bare-metal.


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





==============================================================================
TOPIC: Documentation: DT: omap-ssi binding documentation
http://groups.google.com/group/linux.kernel/t/eeb43e2db54d8847?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 4:00 pm
From: Sebastian Reichel


Hi Tony,

On Thu, Dec 19, 2013 at 11:03:44AM -0800, Tony Lindgren wrote:
> > +Required properties:
> > +- compatible: Should include "ti,omap3-ssi".
> > +- reg-names: Contains the values "sys" and "gdd".
>
> Do you need the reg-names? The order won't change so you can just
> document the order in the binding?

The names are not needed, but I like self-documenting code/bindings.

Also the examples in Documentation/devicetree/bindings/resource-names.txt
look similar to this case.

What do you have against the -names properties?

The same statement goes for the following -names comments, so I will
skip them ;)

> [...]
> > +- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE
> > + events for the port. This is an optional board-specific
> > + property. If it's missing the port will not be
> > + enabled.
>
> Hmm this might be just a wake-up GPIO? If so, you should be able to
> just set it up as an interrupt and do a request_irq on the pinctrl-single
> entry for it.

Yes, this gpio is used as interrupt in the driver, but its also read
directly. I already considered making it an irq in the DT data
(since its mainly used as irq), but I could not find out how to read
the current status of an irq line.

> It might even be one of the already mapped interrupt lines that the code is
> remuxing to a GPIO for idle? If so, then you can just use the new binding
> for interrupts-extended to handle the wake-up events.
>
> If you post the GPIO number for ti,ssi-cawake-gpio and the interrupt
> numbers I can check if there's a need to handle it separately as a GPIO
> pin or if it already can be automatically handled for the wake-up events.

You can see it in one of the next patches, which adds the needed
nodes in omap3-n900.dts. The used GPIO on N900 is 151 (gpio5 23)
and I use the following pinmux configuration:

0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4)

P.S.: I intend to get this into 3.15. Before I will send an updated
series, which uses the omap clock DT bindings as requested by
DT binding maintainers.

-- Sebastian





==============================================================================
TOPIC: lib/vsprintf: add %pT format specifier
http://groups.google.com/group/linux.kernel/t/798326cec82e4895?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Jan 10 2014 4:10 pm
From: Andrew Morton


On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> This patch introduces %pT format specifier for printing task_struct->comm.
> Currently %pT does not provide consistency. I'm planning to change to use RCU
> in the future. By using RCU, the comm name read from task_struct->comm will be
> guaranteed to be consistent. But before modifying set_task_comm() to use RCU,
> we need to kill direct ->comm users who do not use get_task_comm().

On reflection...

It isn't obvious that this patch is sufficiently beneficial until we
have that RCU code in place.

So I could retain this patch in -mm until we have that all sorted out.
And I'll have to avoid merging %pT users into mainline in the
meanwhile!

Am I wrong? The patch seems fairly pointless as a standalone thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Fri, Jan 10 2014 4:10 pm
From: Andrew Morton


On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> Hello.
>
> Since addition of %pT itself seems to be agreed,

sort-of. The reason I suggested inventing a new token was code
density: avoid pointlessly passing current all the time.

Oh well, whatever - this patch has other intentions.

> I refreshed this patch using
> linux-next-20140109. Please pick up if this patch is OK for you; I will start
> making patches for killing most of direct ->comm readers.
>
> Regards.
> ----------------------------------------
> >From 0d1f03d59a477459f3d3c190593d9e78f5d67de8 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Thu, 9 Jan 2014 21:32:22 +0900
> Subject: [PATCH] lib/vsprintf: add %pT format specifier
>
> Since task_struct->comm can be modified by other threads while the current
> thread is reading it, it is recommended to use get_task_comm() for reading it.
>
> However, since get_task_comm() holds task_struct->alloc_lock spinlock,
> some users cannot use get_task_comm(). Also, a lot of users are directly
> reading from task_struct->comm even if they can use get_task_comm().
> Such users might obtain inconsistent result.
>
> This patch introduces %pT format specifier for printing task_struct->comm.
> Currently %pT does not provide consistency. I'm planning to change to use RCU
> in the future. By using RCU, the comm name read from task_struct->comm will be
> guaranteed to be consistent.

Not completely accurate - RCU won't protect code which accesses ->comm
from interrupts. Printing current->comm from irq is quite daft, but I
bet there's code that does it :(

As long as the kernel doesn't crash or otherwise misbehave when this
happens, I think we're OK.

(And I guess there's also non-daft code which accesses current->comm
from interrupt context: oops, panic, etc).

> But before modifying set_task_comm() to use RCU,
> we need to kill direct ->comm users who do not use get_task_comm().
>
> An example for converting direct ->comm users is shown below. Since many debug
> printings use p == current, you can pass NULL instead of p if p == current.
>
> pr_info("comm=%s\n", p->comm); => pr_info("comm=%pT\n", p);
> pr_info("comm=%s\n", current->comm); => pr_info("comm=%pT\n", NULL);
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Reviewed-by: Pavel Machek <pavel@ucw.cz>
> ---
> Documentation/printk-formats.txt | 6 ++++++
> lib/vsprintf.c | 20 +++++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 6f4eb32..94459b4 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -184,6 +184,12 @@ dentry names:
> equivalent of %s dentry->d_name.name we used to use, %pd<n> prints
> n last components. %pD does the same thing for struct file.
>
> +task_struct comm name:
> +
> + %pT
> +
> + For printing task_struct->comm.
> +
> struct va_format:
>
> %pV
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 185b6d3..a97f18b 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1179,6 +1179,21 @@ char *address_val(char *buf, char *end, const void *addr,
> return number(buf, end, num, spec);
> }
>
> +static noinline_for_stack

hm, does noinline_for_stack actually do anything useful here? I
suspect it *increases* stack depth in the way comm_name() is used here.

> +char *comm_name(char *buf, char *end, struct task_struct *tsk,
> + struct printf_spec spec, const char *fmt)
> +{
> + char name[TASK_COMM_LEN];
> +
> + /* Caller can pass NULL instead of current. */
> + if (!tsk)
> + tsk = current;
> + /* Not using get_task_comm() in case I'm in IRQ context. */
> + memcpy(name, tsk->comm, TASK_COMM_LEN);
> + name[sizeof(name) - 1] = '\0';

get_task_comm() uses strncpy()?

> + return string(buf, end, name, spec);
> +}
> +

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




== 3 of 4 ==
Date: Fri, Jan 10 2014 5:30 pm
From: Tetsuo Handa


Andrew Morton wrote:
> On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> > This patch introduces %pT format specifier for printing task_struct->comm.
> > Currently %pT does not provide consistency. I'm planning to change to use RCU
> > in the future. By using RCU, the comm name read from task_struct->comm will be
> > guaranteed to be consistent. But before modifying set_task_comm() to use RCU,
> > we need to kill direct ->comm users who do not use get_task_comm().
>
> On reflection...
>
> It isn't obvious that this patch is sufficiently beneficial until we
> have that RCU code in place.
>
> So I could retain this patch in -mm until we have that all sorted out.
> And I'll have to avoid merging %pT users into mainline in the
> meanwhile!
>
> Am I wrong? The patch seems fairly pointless as a standalone thing?
>

Step 1: (targeted to 3.14-rc1)
Add "%pT" format specifier and commcpy() wrapper function.

Step 2: (started after step 1 is reflected to other git trees)
Replace printk("%s", p->comm) with printk("%pT", p).
Replace strcpy(buf, p->comm) with commcpy(buf, p).

Step 3: (started after step 2 is reflected to other git trees)
Add rcu_read_lock()/rcu_read_unlock() into commcpy().
Modify set_task_comm() etc. to replace ->comm using RCU.

This patch and commcpy() patch ( https://lkml.org/lkml/2014/1/10/217 ) are
targeted to be merged into 3.14-rc1. This is because we can start writing
patches to use "%pT" or commcpy() only after other git trees have rebased
using 3.14-rc1. After all direct ->comm readers are replaced to use "%pT" or
commcpy(), I can start ->comm modifying functions to use RCU.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 4 of 4 ==
Date: Fri, Jan 10 2014 5:40 pm
From: Joe Perches


On Sat, 2014-01-11 at 10:28 +0900, Tetsuo Handa wrote:
> Step 1: (targeted to 3.14-rc1)
> Add "%pT" format specifier and commcpy() wrapper function.
>
> Step 2: (started after step 1 is reflected to other git trees)
> Replace printk("%s", p->comm) with printk("%pT", p).

Replace printk("%s", current->comm) with printk("%pT", NULL);

?

> Replace strcpy(buf, p->comm) with commcpy(buf, p).

> Step 3: (started after step 2 is reflected to other git trees)
> Add rcu_read_lock()/rcu_read_unlock() into commcpy().
> Modify set_task_comm() etc. to replace ->comm using RCU.

Aren't steps 2 and 3 independent?

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





==============================================================================
TOPIC: ACPI/SCAN: _STA status read
http://groups.google.com/group/linux.kernel/t/332c7e2cd251892f?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 10 2014 4:10 pm
From: Srinivas Pandruvada


This patch adds a "status" attribute for an acpi device. This status
attribute shows the value of _STA object. The _STA object returns
current status of an ACPI device to show enabled, disabled or removed.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/acpi/scan.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index fd39459..a5f4a60 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -567,6 +567,20 @@ acpi_device_sun_show(struct device *dev, struct device_attribute *attr,
}
static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);

+static ssize_t status_show(struct device *dev, struct device_attribute *attr,
+ char *buf) {
+ struct acpi_device *acpi_dev = to_acpi_device(dev);
+ acpi_status status;
+ unsigned long long sta;
+
+ status = acpi_evaluate_integer(acpi_dev->handle, "_STA", NULL, &sta);
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
+ return sprintf(buf, "%llu\n", sta);
+}
+static DEVICE_ATTR_RO(status);
+
static int acpi_device_setup_files(struct acpi_device *dev)
{
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
@@ -622,6 +636,12 @@ static int acpi_device_setup_files(struct acpi_device *dev)
dev->pnp.sun = (unsigned long)-1;
}

+ if (acpi_has_method(dev->handle, "_STA")) {
+ result = device_create_file(&dev->dev, &dev_attr_status);
+ if (result)
+ goto end;
+ }
+
/*
* If device has _EJ0, 'eject' file is created that is used to trigger
* hot-removal function from userland.
@@ -677,6 +697,8 @@ static void acpi_device_remove_files(struct acpi_device *dev)
device_remove_file(&dev->dev, &dev_attr_adr);
device_remove_file(&dev->dev, &dev_attr_modalias);
device_remove_file(&dev->dev, &dev_attr_hid);
+ if (acpi_has_method(dev->handle, "_STA"))
+ device_remove_file(&dev->dev, &dev_attr_status);
if (dev->handle)
device_remove_file(&dev->dev, &dev_attr_path);
}
--
1.8.3.1

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




== 2 of 2 ==
Date: Fri, Jan 10 2014 5:10 pm
From: "Rafael J. Wysocki"


On Friday, January 10, 2014 04:00:05 PM Srinivas Pandruvada wrote:
> This patch adds a "status" attribute for an acpi device. This status
> attribute shows the value of _STA object. The _STA object returns
> current status of an ACPI device to show enabled, disabled or removed.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

Queued up for 3.14, thanks!

> ---
> drivers/acpi/scan.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index fd39459..a5f4a60 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -567,6 +567,20 @@ acpi_device_sun_show(struct device *dev, struct device_attribute *attr,
> }
> static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
>
> +static ssize_t status_show(struct device *dev, struct device_attribute *attr,
> + char *buf) {
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + acpi_status status;
> + unsigned long long sta;
> +
> + status = acpi_evaluate_integer(acpi_dev->handle, "_STA", NULL, &sta);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + return sprintf(buf, "%llu\n", sta);
> +}
> +static DEVICE_ATTR_RO(status);
> +
> static int acpi_device_setup_files(struct acpi_device *dev)
> {
> struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> @@ -622,6 +636,12 @@ static int acpi_device_setup_files(struct acpi_device *dev)
> dev->pnp.sun = (unsigned long)-1;
> }
>
> + if (acpi_has_method(dev->handle, "_STA")) {
> + result = device_create_file(&dev->dev, &dev_attr_status);
> + if (result)
> + goto end;
> + }
> +
> /*
> * If device has _EJ0, 'eject' file is created that is used to trigger
> * hot-removal function from userland.
> @@ -677,6 +697,8 @@ static void acpi_device_remove_files(struct acpi_device *dev)
> device_remove_file(&dev->dev, &dev_attr_adr);
> device_remove_file(&dev->dev, &dev_attr_modalias);
> device_remove_file(&dev->dev, &dev_attr_hid);
> + if (acpi_has_method(dev->handle, "_STA"))
> + device_remove_file(&dev->dev, &dev_attr_status);
> if (dev->handle)
> device_remove_file(&dev->dev, &dev_attr_path);
> }
>

--
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: APM
http://groups.google.com/group/linux.kernel/t/c8506cae9a47bc63?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 4:20 pm
From: "Rafael J. Wysocki"


On Friday, January 10, 2014 11:50:08 AM Jiri Kosina wrote:
> Rafael,
>
> please consider pulling
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/apm.git for-next
>
> into linux-pm.git, to receive:
>
>
> - addition of hibernation events to apm-emulation, from Bin Shi
>
>
> Thanks.
>
> Bin Shi (1):
> apm-emulation: add hibernation APM events to support suspend2disk
>
> drivers/char/apm-emulation.c | 11 +++++++++--
> include/uapi/linux/apm_bios.h | 2 ++
> 2 files changed, 11 insertions(+), 2 deletions(-)

Pulled, thanks Jiri!

--
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: kernfs, sysfs, driver-core: implement synchronous self-removal
http://groups.google.com/group/linux.kernel/t/b72ccc5edcdfb313?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 4:20 pm
From: Greg KH


On Fri, Jan 10, 2014 at 07:08:56AM -0800, Greg KH wrote:
> On Fri, Jan 10, 2014 at 08:57:17AM -0500, Tejun Heo wrote:
> > Hello,
> >
> > This is v3 of kernfs self-removal patchset. v2 posting mistakenly
> > sent out slightly old set of patches, so the v3. Sorry about the
> > noise. Changes from the first take[L] are,
>
> It's really late in the -rc cycle for me to take this for 3.14, but I
> see patch 1 is a good one to have, so I'll take that now, and queue the
> rest up for after 3.14-rc1 is out for 3.15. Is that ok with you, or do
> you have patches that depend on this series for 3.14?

Oh nevermind, these are all good, now applied :)

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





==============================================================================
TOPIC: dt-bindings: pci: xgene pcie device tree bindings
http://groups.google.com/group/linux.kernel/t/bb793bfb4a89dad9?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 4:20 pm
From: Tanmay Inamdar


On Tue, Jan 7, 2014 at 7:35 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 07 January 2014, Tanmay Inamdar wrote:
>> On Fri, Jan 3, 2014 at 1:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> +Required properties:
>> >> +- status: Either "ok" or "disabled".
>> >> +- device_type: set to "pci"
>> >> +- compatible: should contain "xgene,pcie" to identify the core.
>> >> +- reg: base addresses and lengths of the pcie controller configuration
>> >> + space register.
>> >> +- #address-cells: set to <3>
>> >> +- #size-cells: set to <2>
>> >> +- ranges: ranges for the PCI memory, I/O regions, config and MSI regions
>> >> +- #interrupt-cells: set to <1>
>> >> +- interrupt-map-mask and interrupt-map: standard PCI properties
>> >> + to define the mapping of the PCIe interface to interrupt
>> >> + numbers.
>> >> +- clocks: from common clock binding: handle to pci clock.
>> >> +- clock-names: from common clock binding. Should be "pcieclk".
>> >> +
>> >
>> > Better use an anonymous clock?
>>
>> Sorry. Can you please elaborate?
>
> I mean drop the "clock-names" property.
>
Did you mean clock-names in pcie-clock node or pcie node? I can drop
clock-names from pcie clock node. However if I drop clock-names from
pcie node, then clk_get call from pcie host driver would result in
failure. Right?

>> >> +SoC specific DT Entry:
>> >> + pcie0: pcie@1f2b0000 {
>> >> + status = "disabled";
>> >> + device_type = "pci";
>> >> + compatible = "xgene,pcie";
>> >> + #interrupt-cells = <1>;
>> >> + #size-cells = <2>;
>> >> + #address-cells = <3>;
>> >> + reg = < 0x00 0x1f2b0000 0x0 0x00010000>;
>> >> + ranges = <0x02000000 0x0 0x00000000 0xe0 0x00000000 0x0 0x10000000 /* mem*/
>> >
>> >
>> > Also, do you support no prefetchable memory?
>>
>> HW has either IO or Memory regions for mapping device's memory space.
>> There is no separate prefetchable memory space.
>
> Are you sure the memory is non-prefetchable then? I would have expected
> 0x42000000 rather than 0x02000000, but I could be misremembering it.
>
>> >
>> >> + 0x00000000 0x0 0xd0000000 0xe0 0xd0000000 0x0 0x00200000 /* cfg */
>> >
>> > config space is not normally in the ranges property, and I think you will need
>> > it in the pcie node itself as a 'reg' property so the code can access it.
>>
>> pcie-designware.c does it that way. I just followed their implementation.
>
> I don't remember what led to that, it still seems wrong and I can't find anything
> in the PCI binding for host bridges telling their config space this way.
>
>> >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
>> >> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1>;
>> >
>> > Only one IRQ for all devices?
>>
>> The node represents a port. I believe that Linux framework uses only
>> one of the legacy IRQs per port. Rest all remain unused. Hence I
>> removed them. Please correct me if I am wrong.
>
> Any PCI device can normally have four interrupts (IntA through IntD), which are
> traditionally separate pins on a PCI bus, but get emulated on PCIe. While it's
> not common for any normal device to use more than one IRQ, a bridge device
> will swizzle these (virtual) IRQ lines, so a device behind the bridge actually
> gets a different host IRQ.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: cpuidle: rework device state count handling
http://groups.google.com/group/linux.kernel/t/06bf48773e084467?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 10 2014 4:30 pm
From: "Rafael J. Wysocki"


On Friday, December 20, 2013 07:47:22 PM Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Some cpuidle drivers assume that cpuidle core will handle cases where
> device->state_count is smaller than driver->state_count, unfortunately
> currently this is untrue (device->state_count is used only for handling
> cpuidle state sysfs entries and driver->state_count is used for all
> other cases) and will not be fixed in the future as device->state_count
> is planned to be removed [1].
>
> This patchset fixes such drivers (ARM EXYNOS cpuidle driver and ACPI
> cpuidle driver), removes superflous device->state_count initialization
> from drivers for which device->state_count equals driver->state_count
> (POWERPC pseries cpuidle driver and intel_idle driver) and finally
> removes state_count field from struct cpuidle_device.
>
> Additionaly (while at it) this patchset fixes C1E promotion disable
> quirk handling (in intel_idle driver) and converts cpuidle drivers code
> to use the common cpuidle_[un]register() routines (in POWERPC pseries
> cpuidle driver and intel_idle driver).
>
> [1] http://permalink.gmane.org/gmane.linux.power-management.general/36908
>
> Reference to v1:
> http://comments.gmane.org/gmane.linux.power-management.general/37390
>
> Changes since v1:
> - synced patch series with next-20131220
> - added ACKs from Daniel Lezcano

This series breaks boot on one of my test machines with intel_idle, so I'm
not sure how well it has been tested.

I've dropped it entirely for now. If I have the time, I will try to identify
the root cause of the failure, but that may not happen before the merge window.
Sorry about that.

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Bluetooth: Add hci_h4p driver
http://groups.google.com/group/linux.kernel/t/5851dede4d9d0250?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 10 2014 4:30 pm
From: Pavel Machek


Hi!

> > +static inline void hci_h4p_handle_byte(struct hci_h4p_info *info, u8 byte)
>
> pretty big function to be inline

Called from just one place, so that should be ok.

> > +static void hci_h4p_rx_tasklet(unsigned long data)
> > +{
> []
> > + while (hci_h4p_inb(info, UART_LSR) & UART_LSR_DR) {
> []
> > + pr_debug("0x%.2x ", byte);
>
> pr_debug is prefixed by a newline if necessary
> and then <7>, one for each use.
>
> This will produce a lot of dmesg output lines
> (1 for each byte) and isn't in my opinion
> necessary/useful.

Ok, I just killed it.

> > + if (set != !!test_bit(H4P_ACTIVE_MODE, &info->pm_flags)) {
> > + bt_plat_data->set_pm_limits(info->dev, set);
> > + if (set)
> > + set_bit(H4P_ACTIVE_MODE, &info->pm_flags);
> > + else
> > + clear_bit(H4P_ACTIVE_MODE, &info->pm_flags);
> > + BT_DBG("Change pm constraints to: %s", sset);
>
> missing newline

Actually, it is the other way around. BT_DBG adds the newline. I'll
remove it from the rest.

> > + if (!hdev) {
> > + printk(KERN_WARNING "hci_h4p: Frame for unknown device\n");
> > + return -ENODEV;
> > + }
>
> Is this possible?

Probably not, removed.

> > + if (ret != 6)
> > + return -EINVAL;
> > +
> > + for (i = 0; i < 6; i++)
> > + info->bd_addr[i] = bdaddr[i] & 0xff;
>
> This could also return -EINVAL if bdaddr[i] > 0xff

Why not.

> > +static int hci_h4p_bcm_set_bdaddr(struct hci_h4p_info *info, struct sk_buff *skb)
> > +{
> > + int i;
> > + static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
> > + int not_valid;
> > +
> > + not_valid = 1;
> > + for (i = 0; i < 6; i++) {
> > + if (info->bd_addr[i] != 0x00) {
> > + not_valid = 0;
> > + break;
> > + }
> > + }
>
> This seems wrong as addresses can have valid 0 bytes.
> Perhaps use:
>
> if (!is_valid_ether_addr(info->bd_addr))
>

I am not sure bluetooth rules are same as ethernet. And notice that it
only errors out on 00:00:00:00:00:00 which seems like invalid address
to me.

I fixed the other ones.

Thanks,
Pavel


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Fri, Jan 10 2014 4:30 pm
From: Pavel Machek


Add hci_h4p bluetooth driver to bluetooth-next. This device is used
for example on Nokia N900 cell phone.

Signed-off-by: Pali Roh�r <pali.rohar@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Thanks-to: Sebastian Reichel <sre@debian.org>
Thanks-to: Joe Perches <joe@perches.com>

---

Changes from v5: Comment fixes and some refactoring suggested by
Joe Perches. Please apply.

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 11a6104..a53e8c7 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -241,5 +241,15 @@ config BT_WILINK
core driver to communicate with the BT core of the combo chip.

Say Y here to compile support for Texas Instrument's WiLink7 driver
- into the kernel or say M to compile it as module.
+ into the kernel or say M to compile it as module (btwilink).
+
+config BT_NOKIA_H4P
+ tristate "HCI driver with H4 Nokia extensions"
+ depends on BT && ARCH_OMAP
+ help
+ Bluetooth HCI driver with H4 extensions. This driver provides
+ support for H4+ Bluetooth chip with vendor-specific H4 extensions.
+
+ Say Y here to compile support for h4 extended devices into the kernel
+ or say M to compile it as module (btnokia_h4p).
endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9fe8a87..6f25db2 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -31,4 +31,8 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
hci_uart-$(CONFIG_BT_HCIUART_3WIRE) += hci_h5.o
hci_uart-objs := $(hci_uart-y)

+obj-$(CONFIG_BT_NOKIA_H4P) += btnokia_h4p.o
+btnokia_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o nokia_fw-csr.o \
+ nokia_fw-bcm.o nokia_fw-ti1273.o
+
ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_h4p.h b/drivers/bluetooth/hci_h4p.h
new file mode 100644
index 0000000..fd7a640
--- /dev/null
+++ b/drivers/bluetooth/hci_h4p.h
@@ -0,0 +1,228 @@
+/*
+ * This file is part of Nokia H4P bluetooth driver
+ *
+ * Copyright (C) 2005-2008 Nokia Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef __DRIVERS_BLUETOOTH_HCI_H4P_H
+#define __DRIVERS_BLUETOOTH_HCI_H4P_H
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+#include <net/bluetooth/hci.h>
+
+#define FW_NAME_TI1271_PRELE "ti1273_prele.bin"
+#define FW_NAME_TI1271_LE "ti1273_le.bin"
+#define FW_NAME_TI1271 "ti1273.bin"
+#define FW_NAME_BCM2048 "bcmfw.bin"
+#define FW_NAME_CSR "bc4fw.bin"
+
+#define UART_SYSC_OMAP_RESET 0x03
+#define UART_SYSS_RESETDONE 0x01
+#define UART_OMAP_SCR_EMPTY_THR 0x08
+#define UART_OMAP_SCR_WAKEUP 0x10
+#define UART_OMAP_SSR_WAKEUP 0x02
+#define UART_OMAP_SSR_TXFULL 0x01
+
+#define UART_OMAP_SYSC_IDLEMODE 0x03
+#define UART_OMAP_SYSC_IDLEMASK (3 << UART_OMAP_SYSC_IDLEMODE)
+
+#define UART_OMAP_SYSC_FORCE_IDLE (0 << UART_OMAP_SYSC_IDLEMODE)
+#define UART_OMAP_SYSC_NO_IDLE (1 << UART_OMAP_SYSC_IDLEMODE)
+#define UART_OMAP_SYSC_SMART_IDLE (2 << UART_OMAP_SYSC_IDLEMODE)
+
+#define H4P_TRANSFER_MODE 1
+#define H4P_SCHED_TRANSFER_MODE 2
+#define H4P_ACTIVE_MODE 3
+
+struct hci_h4p_info {
+ struct timer_list lazy_release;
+ struct hci_dev *hdev;
+ spinlock_t lock;
+
+ void __iomem *uart_base;
+ unsigned long uart_phys_base;
+ int irq;
+ struct device *dev;
+ u8 chip_type;
+ u8 bt_wakeup_gpio;
+ u8 host_wakeup_gpio;
+ u8 reset_gpio;
+ u8 reset_gpio_shared;
+ u8 bt_sysclk;
+ u8 man_id;
+ u8 ver_id;
+
+ struct sk_buff_head fw_queue;
+ struct sk_buff *alive_cmd_skb;
+ struct completion init_completion;
+ struct completion fw_completion;
+ struct completion test_completion;
+ int fw_error;
+ int init_error;
+
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+ long rx_count;
+ unsigned long rx_state;
+ unsigned long garbage_bytes;
+
+ u8 bd_addr[6];
+ struct sk_buff_head *fw_q;
+
+ int pm_enabled;
+ int tx_enabled;
+ int autorts;
+ int rx_enabled;
+ unsigned long pm_flags;
+
+ int tx_clocks_en;
+ int rx_clocks_en;
+ spinlock_t clocks_lock;
+ struct clk *uart_iclk;
+ struct clk *uart_fclk;
+ atomic_t clk_users;
+ u16 dll;
+ u16 dlh;
+ u16 ier;
+ u16 mdr1;
+ u16 efr;
+};
+
+struct hci_h4p_radio_hdr {
+ __u8 evt;
+ __u8 dlen;
+} __attribute__ ((packed));
+
+struct hci_h4p_neg_hdr {
+ __u8 dlen;
+} __attribute__ ((packed));
+#define H4P_NEG_HDR_SIZE 1
+
+#define H4P_NEG_REQ 0x00
+#define H4P_NEG_ACK 0x20
+#define H4P_NEG_NAK 0x40
+
+#define H4P_PROTO_PKT 0x44
+#define H4P_PROTO_BYTE 0x4c
+
+#define H4P_ID_CSR 0x02
+#define H4P_ID_BCM2048 0x04
+#define H4P_ID_TI1271 0x31
+
+struct hci_h4p_neg_cmd {
+ __u8 ack;
+ __u16 baud;
+ __u16 unused1;
+ __u8 proto;
+ __u16 sys_clk;
+ __u16 unused2;
+} __attribute__ ((packed));
+
+struct hci_h4p_neg_evt {
+ __u8 ack;
+ __u16 baud;
+ __u16 unused1;
+ __u8 proto;
+ __u16 sys_clk;
+ __u16 unused2;
+ __u8 man_id;
+ __u8 ver_id;
+} __attribute__ ((packed));
+
+#define H4P_ALIVE_REQ 0x55
+#define H4P_ALIVE_RESP 0xcc
+
+struct hci_h4p_alive_hdr {
+ __u8 dlen;
+} __attribute__ ((packed));
+#define H4P_ALIVE_HDR_SIZE 1
+
+struct hci_h4p_alive_pkt {
+ __u8 mid;
+ __u8 unused;
+} __attribute__ ((packed));
+
+#define MAX_BAUD_RATE 921600
+#define BC4_MAX_BAUD_RATE 3692300
+#define UART_CLOCK 48000000
+#define BT_INIT_DIVIDER 320
+#define BT_BAUDRATE_DIVIDER 384000000
+#define BT_SYSCLK_DIV 1000
+#define INIT_SPEED 120000
+
+#define H4_TYPE_SIZE 1
+#define H4_RADIO_HDR_SIZE 2
+
+/* H4+ packet types */
+#define H4_CMD_PKT 0x01
+#define H4_ACL_PKT 0x02
+#define H4_SCO_PKT 0x03
+#define H4_EVT_PKT 0x04
+#define H4_NEG_PKT 0x06
+#define H4_ALIVE_PKT 0x07
+#define H4_RADIO_PKT 0x08
+
+/* TX states */
+#define WAIT_FOR_PKT_TYPE 1
+#define WAIT_FOR_HEADER 2
+#define WAIT_FOR_DATA 3
+
+struct hci_fw_event {
+ struct hci_event_hdr hev;
+ struct hci_ev_cmd_complete cmd;
+ u8 status;
+} __attribute__ ((packed));
+
+int hci_h4p_send_alive_packet(struct hci_h4p_info *info);
+
+void hci_h4p_bcm_parse_fw_event(struct hci_h4p_info *info,
+ struct sk_buff *skb);
+int hci_h4p_bcm_send_fw(struct hci_h4p_info *info,
+ struct sk_buff_head *fw_queue);
+
+void hci_h4p_bc4_parse_fw_event(struct hci_h4p_info *info,
+ struct sk_buff *skb);
+int hci_h4p_bc4_send_fw(struct hci_h4p_info *info,
+ struct sk_buff_head *fw_queue);
+
+void hci_h4p_ti1273_parse_fw_event(struct hci_h4p_info *info,
+ struct sk_buff *skb);
+int hci_h4p_ti1273_send_fw(struct hci_h4p_info *info,
+ struct sk_buff_head *fw_queue);
+
+int hci_h4p_read_fw(struct hci_h4p_info *info, struct sk_buff_head *fw_queue);
+int hci_h4p_send_fw(struct hci_h4p_info *info, struct sk_buff_head *fw_queue);
+void hci_h4p_parse_fw_event(struct hci_h4p_info *info, struct sk_buff *skb);
+
+void hci_h4p_outb(struct hci_h4p_info *info, unsigned int offset, u8 val);
+u8 hci_h4p_inb(struct hci_h4p_info *info, unsigned int offset);
+void hci_h4p_set_rts(struct hci_h4p_info *info, int active);
+int hci_h4p_wait_for_cts(struct hci_h4p_info *info, int active, int timeout_ms);
+void __hci_h4p_set_auto_ctsrts(struct hci_h4p_info *info, int on, u8 which);
+void hci_h4p_set_auto_ctsrts(struct hci_h4p_info *info, int on, u8 which);
+void hci_h4p_change_speed(struct hci_h4p_info *info, unsigned long speed);
+int hci_h4p_reset_uart(struct hci_h4p_info *info);
+void hci_h4p_init_uart(struct hci_h4p_info *info);
+void hci_h4p_enable_tx(struct hci_h4p_info *info);
+void hci_h4p_store_regs(struct hci_h4p_info *info);
+void hci_h4p_restore_regs(struct hci_h4p_info *info);
+void hci_h4p_smart_idle(struct hci_h4p_info *info, bool enable);
+
+