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

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

linux.kernel@googlegroups.com

Today's topics:

* Input: synaptics-rmi4 - fix I2C functionality check - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/127bd12f65fad9d0?hl=en
* re-shrink 'struct page' when SLUB is on. - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d6d1692f51c2de27?hl=en
* VELGØRENHED BISTAND - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/314062796b286406?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 - 2 messages, 1 author
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

==============================================================================
TOPIC: Input: synaptics-rmi4 - fix I2C functionality check
http://groups.google.com/group/linux.kernel/t/127bd12f65fad9d0?hl=en
==============================================================================

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


On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
> When adapter does not support required functionality (I2C_FUNC_I2C) we were
> returning 0 to the upper layers, making them believe that device bound
> successfully.

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

>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/rmi4/rmi_i2c.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
> index cdc8527..c176218 100644
> --- a/drivers/input/rmi4/rmi_i2c.c
> +++ b/drivers/input/rmi4/rmi_i2c.c
> @@ -193,11 +193,10 @@ static int rmi_i2c_probe(struct i2c_client *client,
> pdata->sensor_name ? pdata->sensor_name : "-no name-",
> client->addr, pdata->attn_gpio);
>
> - retval = i2c_check_functionality(client->adapter, I2C_FUNC_I2C);
> - if (!retval) {
> - dev_err(&client->dev, "i2c_check_functionality error %d.\n",
> - retval);
> - return retval;
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + dev_err(&client->dev,
> + "adapter does not support required functionality.\n");
> + return -ENODEV;
> }
>
> if (pdata->gpio_config) {
>


--

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/




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


On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
> Split off transport operations from rmi_transport_dev into a separate
> structure that will be shared between all devices using the same transport
> and use const pointer to access it.
>
> Change signature on transport methods so that length is using the proper
> tyep - size_t.
>
> Also rename rmi_transport_info to rmi_transport_stats and move protocol
> name (which is the only immutable piece of data there) into the transport
> device itself.

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

>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/rmi4/rmi_bus.h | 64 ++++++++++++++++++++++++-----------------
> drivers/input/rmi4/rmi_driver.c | 8 +++---
> drivers/input/rmi4/rmi_i2c.c | 49 ++++++++++++++++---------------
> 3 files changed, 67 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
> index 3e8b57a..ccf26dc 100644
> --- a/drivers/input/rmi4/rmi_bus.h
> +++ b/drivers/input/rmi4/rmi_bus.h
> @@ -135,26 +135,25 @@ struct rmi_driver {
> #define to_rmi_driver(d) \
> container_of(d, struct rmi_driver, driver);
>
> -/** struct rmi_transport_info - diagnostic information about the RMI transport
> +/**
> + * struct rmi_transport_stats - diagnostic information about the RMI transport
> * device, used in the xport_info debugfs file.
> *
> * @proto String indicating the protocol being used.
> * @tx_count Number of transmit operations.
> - * @tx_bytes Number of bytes transmitted.
> * @tx_errs Number of errors encountered during transmit operations.
> + * @tx_bytes Number of bytes transmitted.
> * @rx_count Number of receive operations.
> - * @rx_bytes Number of bytes received.
> * @rx_errs Number of errors encountered during receive operations.
> - * @att_count Number of times ATTN assertions have been handled.
> + * @rx_bytes Number of bytes received.
> */
> -struct rmi_transport_info {
> - const char *proto;
> - long tx_count;
> - long tx_bytes;
> - long tx_errs;
> - long rx_count;
> - long rx_bytes;
> - long rx_errs;
> +struct rmi_transport_stats {
> + unsigned long tx_count;
> + unsigned long tx_errs;
> + size_t tx_bytes;
> + unsigned long rx_count;
> + unsigned long rx_errs;
> + size_t rx_bytes;
> };
>
> /**
> @@ -162,13 +161,14 @@ struct rmi_transport_info {
> *
> * @dev: Pointer to the communication device, e.g. i2c or spi
> * @rmi_dev: Pointer to the RMI device
> - * @write_block: Writing a block of data to the specified address
> - * @read_block: Read a block of data from the specified address.
> * @irq_thread: if not NULL, the sensor driver will use this instead of the
> * 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
> *
> * The RMI transport device implements the glue between different communication
> * buses such as I2C and SPI.
> @@ -178,20 +178,30 @@ struct rmi_transport_dev {
> struct device *dev;
> struct rmi_device *rmi_dev;
>
> - int (*write_block)(struct rmi_transport_dev *xport, u16 addr,
> - const void *buf, const int len);
> - int (*read_block)(struct rmi_transport_dev *xport, u16 addr,
> - void *buf, const int len);
> -
> - int (*enable_device) (struct rmi_transport_dev *xport);
> - void (*disable_device) (struct rmi_transport_dev *xport);
> -
> irqreturn_t (*irq_thread)(int irq, void *p);
> irqreturn_t (*hard_irq)(int irq, void *p);
>
> void *data;
>
> - struct rmi_transport_info info;
> + const char *proto_name;
> + const struct rmi_transport_ops *ops;
> + struct rmi_transport_stats stats;
> +};
> +
> +/**
> + * struct rmi_transport_ops - defines transport protocol operations.
> + *
> + * @write_block: Writing a block of data to the specified address
> + * @read_block: Read a block of data from the specified address.
> + */
> +struct rmi_transport_ops {
> + int (*write_block)(struct rmi_transport_dev *xport, u16 addr,
> + const void *buf, size_t len);
> + int (*read_block)(struct rmi_transport_dev *xport, u16 addr,
> + void *buf, size_t len);
> +
> + int (*enable_device) (struct rmi_transport_dev *xport);
> + void (*disable_device) (struct rmi_transport_dev *xport);
> };
>
> /**
> @@ -232,7 +242,7 @@ bool rmi_is_physical_device(struct device *dev);
> */
> static inline int rmi_read(struct rmi_device *d, u16 addr, void *buf)
> {
> - return d->xport->read_block(d->xport, addr, buf, 1);
> + return d->xport->ops->read_block(d->xport, addr, buf, 1);
> }
>
> /**
> @@ -248,7 +258,7 @@ static inline int rmi_read(struct rmi_device *d, u16 addr, void *buf)
> static inline int rmi_read_block(struct rmi_device *d, u16 addr, void *buf,
> const int len)
> {
> - return d->xport->read_block(d->xport, addr, buf, len);
> + return d->xport->ops->read_block(d->xport, addr, buf, len);
> }
>
> /**
> @@ -262,7 +272,7 @@ static inline int rmi_read_block(struct rmi_device *d, u16 addr, void *buf,
> */
> static inline int rmi_write(struct rmi_device *d, u16 addr, const u8 data)
> {
> - return d->xport->write_block(d->xport, addr, &data, 1);
> + return d->xport->ops->write_block(d->xport, addr, &data, 1);
> }
>
> /**
> @@ -278,7 +288,7 @@ static inline int rmi_write(struct rmi_device *d, u16 addr, const u8 data)
> static inline int rmi_write_block(struct rmi_device *d, u16 addr,
> const void *buf, const int len)
> {
> - return d->xport->write_block(d->xport, addr, buf, len);
> + return d->xport->ops->write_block(d->xport, addr, buf, len);
> }
>
> int rmi_register_transport_device(struct rmi_transport_dev *xport);
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index eb790ff..3483e5b 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -126,8 +126,8 @@ static void disable_sensor(struct rmi_device *rmi_dev)
> if (!data->irq)
> disable_polling(rmi_dev);
>
> - if (rmi_dev->xport->disable_device)
> - rmi_dev->xport->disable_device(rmi_dev->xport);
> + if (rmi_dev->xport->ops->disable_device)
> + rmi_dev->xport->ops->disable_device(rmi_dev->xport);
>
> if (data->irq) {
> disable_irq(data->irq);
> @@ -146,8 +146,8 @@ static int enable_sensor(struct rmi_device *rmi_dev)
> if (data->enabled)
> return 0;
>
> - if (rmi_dev->xport->enable_device) {
> - retval = rmi_dev->xport->enable_device(rmi_dev->xport);
> + if (rmi_dev->xport->ops->enable_device) {
> + retval = rmi_dev->xport->ops->enable_device(rmi_dev->xport);
> if (retval)
> return retval;
> }
> diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
> index 12aea8c..40badf3 100644
> --- a/drivers/input/rmi4/rmi_i2c.c
> +++ b/drivers/input/rmi4/rmi_i2c.c
> @@ -61,11 +61,11 @@ static int rmi_set_page(struct rmi_transport_dev *xport, u8 page)
>
> dev_dbg(&client->dev, "writes 3 bytes: %02x %02x\n",
> txbuf[0], txbuf[1]);
> - xport->info.tx_count++;
> - xport->info.tx_bytes += sizeof(txbuf);
> + xport->stats.tx_count++;
> + xport->stats.tx_bytes += sizeof(txbuf);
> retval = i2c_master_send(client, txbuf, sizeof(txbuf));
> if (retval != sizeof(txbuf)) {
> - xport->info.tx_errs++;
> + xport->stats.tx_errs++;
> dev_err(&client->dev,
> "%s: set page failed: %d.", __func__, retval);
> return (retval < 0) ? retval : -EIO;
> @@ -75,12 +75,12 @@ static int rmi_set_page(struct rmi_transport_dev *xport, u8 page)
> }
>
> static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
> - const void *buf, const int len)
> + const void *buf, size_t len)
> {
> struct i2c_client *client = to_i2c_client(xport->dev);
> struct rmi_i2c_data *data = xport->data;
> + size_t tx_size = len + 1;
> int retval;
> - int tx_size = len + 1;
>
> mutex_lock(&data->page_mutex);
>
> @@ -106,13 +106,13 @@ static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
> }
>
> dev_dbg(&client->dev,
> - "writes %d bytes at %#06x: %*ph\n", len, addr, len, buf);
> + "writes %zd bytes at %#06x: %*ph\n", len, addr, (int)len, buf);
>
> - xport->info.tx_count++;
> - xport->info.tx_bytes += tx_size;
> + xport->stats.tx_count++;
> + xport->stats.tx_bytes += tx_size;
> retval = i2c_master_send(client, data->tx_buf, tx_size);
> if (retval < 0)
> - xport->info.tx_errs++;
> + xport->stats.tx_errs++;
> else
> retval--; /* don't count the address byte */
>
> @@ -121,9 +121,8 @@ exit:
> return retval;
> }
>
> -
> static int rmi_i2c_read_block(struct rmi_transport_dev *xport, u16 addr,
> - void *buf, const int len)
> + void *buf, size_t len)
> {
> struct i2c_client *client = to_i2c_client(xport->dev);
> struct rmi_i2c_data *data = xport->data;
> @@ -140,31 +139,36 @@ static int rmi_i2c_read_block(struct rmi_transport_dev *xport, u16 addr,
>
> dev_dbg(&client->dev, "writes 1 bytes: %02x\n", txbuf[0]);
>
> - xport->info.tx_count++;
> - xport->info.tx_bytes += sizeof(txbuf);
> + xport->stats.tx_count++;
> + xport->stats.tx_bytes += sizeof(txbuf);
> retval = i2c_master_send(client, txbuf, sizeof(txbuf));
> if (retval != sizeof(txbuf)) {
> - xport->info.tx_errs++;
> + xport->stats.tx_errs++;
> retval = (retval < 0) ? retval : -EIO;
> goto exit;
> }
>
> - retval = i2c_master_recv(client, buf, len);
> + xport->stats.rx_count++;
> + xport->stats.rx_bytes += len;
>
> - xport->info.rx_count++;
> - xport->info.rx_bytes += len;
> + retval = i2c_master_recv(client, buf, len);
> if (retval < 0)
> - xport->info.rx_errs++;
> + xport->stats.rx_errs++;
> else
> dev_dbg(&client->dev,
> - "read %d bytes at %#06x: %*ph\n",
> - len, addr, len, buf);
> + "read %zd bytes at %#06x: %*ph\n",
> + len, addr, (int)len, buf);
>
> exit:
> mutex_unlock(&data->page_mutex);
> return retval;
> }
>
> +static const struct rmi_transport_ops rmi_i2c_ops = {
> + .write_block = rmi_i2c_write_block,
> + .read_block = rmi_i2c_read_block,
> +};
> +
> static int rmi_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -214,9 +218,8 @@ static int rmi_i2c_probe(struct i2c_client *client,
> xport->data = data;
> xport->dev = &client->dev;
>
> - xport->write_block = rmi_i2c_write_block;
> - xport->read_block = rmi_i2c_read_block;
> - xport->info.proto = "i2c";
> + xport->proto_name = "i2c";
> + xport->ops = &rmi_i2c_ops;
>
> mutex_init(&data->page_mutex);
>
>


--

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/




== 3 of 3 ==
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: re-shrink 'struct page' when SLUB is on.
http://groups.google.com/group/linux.kernel/t/d6d1692f51c2de27?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 10 2014 3:40 pm
From: Andrew Morton


On Fri, 10 Jan 2014 12:52:32 -0800 Dave Hansen <dave@sr71.net> wrote:

> On 01/05/2014 08:32 PM, Joonsoo Kim wrote:
> > On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
> >> On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen <dave@sr71.net> wrote:
> >>> SLUB depends on a 16-byte cmpxchg for an optimization which
> >>> allows it to not disable interrupts in its fast path. This
> >>> optimization has some small but measurable benefits:
> >>>
> >>> http://lkml.kernel.org/r/52B345A3.6090700@sr71.net
> >>
> >> So really the only significant benefit from the cmpxchg16 is with
> >> cache-cold eight-byte kmalloc/kfree? 8% faster in this case? But with
> >> cache-hot kmalloc/kfree the benefit of cmpxchg16 is precisely zero.
> >
> > I guess that cmpxchg16 is not used in this cache-hot kmalloc/kfree test,
> > because kfree would be done in free fast-path. In this case,
> > this_cpu_cmpxchg_double() would be called, so you cannot find any effect
> > of cmpxchg16.
>
> That's a good point. I also confirmed this theory with the
> free_{fast,slow}path slub counters. So, I ran another round of tests.
>
> One important difference from the last round: I'm now writing to each
> allocation. I originally did this so that I could store the allocations
> in a linked-list, but I also realized that it's important. It's rare in
> practice to do an allocation and not write _something_ to it. This
> change adds a bit of cache pressure which changed the results pretty
> substantially.
>
> 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.

> There are a few important takeaways here:
> 1. The double-cmpxchg optimization has a measurable benefit
> 2. 64-byte 'struct page' is faster than the 56-byte one independent of
> the cmpxchg optimization. Maybe because foo/sizeof(struct page) is
> then a simple shift.
> 3. My new code is probably _slightly_ slower than the existing code,
> but still has the huge space savings
> 4. All of these deltas are greatly magnified here and are hard or
> impossible to demonstrate in practice.
>
> Why does the double-cmpxchg help? The extra cache references that it
> takes to go out and touch the paravirt structures and task struct to
> disable interrupts in the spinlock cases start to show up and hurt our
> allocation rates by about 30%.

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

> This advantage starts to evaporate when
> there is more noise in the caches, or when we start to run the tests
> across more cores.
>
> But the real question here is whether we can shrink 'struct page'. The
> existing (64-byte struct page) slub code wins on allocations under 256b
> by as much as 5% (the 32-byte kmalloc()), but my new code wins on
> allocations over 1k. 4k allocations just happen to be the most common
> on my systems, and they're also very near the "sweet spot" for the new
> code. But, the delta here is _much_ smaller that it was in the spinlock
> vs. cmpxchg cases. This advantage also evaporates when we run things
> across more cores or in less synthetic benchmarks.
>
> I also explored that 5% hit that my code caused in the 32-byte
> allocation case. It looked to me to be mostly explained by the code
> that I added. There were more instructions executed and the
> cycles-per-instruction went down. This looks to be mostly due to a ~15%
> increase in branch misses, probably from the increased code size and
> complexity.
>
> This is the perf stat output for a run doing 16.8M kmalloc(32)/kfree()'s:
> vanilla:
> > 883,412 LLC-loads # 0.296 M/sec [39.76%]
> > 566,546 LLC-load-misses # 64.13% of all LL-cache hits [39.98%]
> patched:
> > 556,751 LLC-loads # 0.186 M/sec [39.86%]
> > 339,106 LLC-load-misses # 60.91% of all LL-cache hits [39.72%]
>
> My best guess is that most of the LLC references are going out and
> touching the struct pages for slab management. It's why we see such a
> big change.
--
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 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: 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: 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 2 ==
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 2 ==
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/





==============================================================================
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);
+
+