[v2 PATCH 10/14] spi/atmel_spi: correct 16 bits transfers using PIO

2012-12-03 Thread Wenyou Yang
From: Richard Genoud 

Signed-off-by: Richard Genoud 
Cc: grant.lik...@secretlab.ca
Cc: spi-devel-gene...@lists.sourceforge.net
---
 drivers/spi/spi-atmel.c |   46 +-
 1 file changed, 37 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 7f624b6..9616fab 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -573,13 +573,17 @@ static void atmel_spi_next_xfer_pio(struct spi_master 
*master,
}
 
if (xfer->tx_buf)
-   spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
+   if (xfer->bits_per_word > 8)
+   spi_writel(as, TDR, *(u16 *)(xfer->tx_buf));
+   else
+   spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
else
spi_writel(as, TDR, 0);
 
dev_dbg(master->dev.parent,
-   "  start pio xfer %p: len %u tx %p rx %p\n",
-   xfer, xfer->len, xfer->tx_buf, xfer->rx_buf);
+   "  start pio xfer %p: len %u tx %p rx %p bitpw %d\n",
+   xfer, xfer->len, xfer->tx_buf, xfer->rx_buf,
+   xfer->bits_per_word);
 
/* Enable relevant interrupts */
spi_writel(as, IER, SPI_BIT(RDRF) | SPI_BIT(OVRES));
@@ -997,21 +1001,39 @@ atmel_spi_pump_pio_data(struct atmel_spi *as, struct 
spi_transfer *xfer)
 {
u8  *txp;
u8  *rxp;
+   u16 *txp16;
+   u16 *rxp16;
unsigned long   xfer_pos = xfer->len - as->current_remaining_bytes;
 
if (xfer->rx_buf) {
-   rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
-   *rxp = spi_readl(as, RDR);
+   if (xfer->bits_per_word > 8) {
+   rxp16 = (u16 *)(((u8 *)xfer->rx_buf) + xfer_pos);
+   *rxp16 = spi_readl(as, RDR);
+   } else {
+   rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
+   *rxp = spi_readl(as, RDR);
+   }
} else {
spi_readl(as, RDR);
}
-
-   as->current_remaining_bytes--;
+   if (xfer->bits_per_word > 8) {
+   as->current_remaining_bytes -= 2;
+   if (as->current_remaining_bytes < 0)
+   as->current_remaining_bytes = 0;
+   } else {
+   as->current_remaining_bytes--;
+   }
 
if (as->current_remaining_bytes) {
if (xfer->tx_buf) {
-   txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
-   spi_writel(as, TDR, *txp);
+   if (xfer->bits_per_word > 8) {
+   txp16 = (u16 *)(((u8 *)xfer->tx_buf)
+   + xfer_pos + 2);
+   spi_writel(as, TDR, *txp16);
+   } else {
+   txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
+   spi_writel(as, TDR, *txp);
+   }
} else {
spi_writel(as, TDR, 0);
}
@@ -1431,6 +1453,12 @@ static int atmel_spi_transfer(struct spi_device *spi, 
struct spi_message *msg)
return -ENOPROTOOPT;
}
}
+   if (xfer->bits_per_word > 8) {
+   if (xfer->len % 2) {
+   dev_dbg(>dev, "buffer len should be 16 
bits aligned\n");
+   return -EINVAL;
+   }
+   }
 
/* FIXME implement these protocol options!! */
if (xfer->speed_hz) {
-- 
1.7.9.5

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


[v2 PATCH 08/14] spi/atmel_spi: add dmaengine support

2012-12-03 Thread Wenyou Yang
From: Nicolas Ferre 

Add dmaengine support.
The has_dma_support to select DMA as the SPI xfer mode.

Signed-off-by: Nicolas Ferre 
[wenyou.y...@atmel.com: add has_dma_support to select DMA as the SPI xfer mode]
[wenyou.y...@atmel.com: add support NPCS1,2,3 chip select other than NPCS0]
[wenyou.y...@atmel.com: fix DMA: OOPS if buffer > 4096 bytes]
Signed-off-by: Wenyou Yang 
Cc: grant.lik...@secretlab.ca
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: richard.gen...@gmail.com
---
Hi, Richard,

This patch is based on the original patch from Nicolas
[PATCH] spi/atmel_spi: add dmaengine support
and merge the patches from Richard Genoud,
[PATCH] spi-atmel: update with dmaengine interface
[PATCH] spi-atmel: fix __init/__devinit sections mismatch
and Wenyou Yang add the code to support DTS section for selecting the SPI xfer 
mode,
add support NPCS1,2,3 chip select other than NPCS0.
fix DMA: OOPS if buffer > 4096 bytes.

Could you sign your signature in this patch?

Best Regards,
Wenyou Yang

 drivers/spi/spi-atmel.c |  564 ---
 1 file changed, 532 insertions(+), 32 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index e032e3d..1de45c2 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* SPI register offsets */
 #define SPI_CR 0x
@@ -180,6 +182,19 @@
 #define spi_writel(port,reg,value) \
__raw_writel((value), (port)->regs + SPI_##reg)
 
+/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
+ * cache operations; better heuristics consider wordsize and bitrate.
+ */
+#define DMA_MIN_BYTES  16
+
+struct atmel_spi_dma {
+   struct dma_chan *chan_rx;
+   struct dma_chan *chan_tx;
+   struct scatterlist  sgrx;
+   struct scatterlist  sgtx;
+   struct dma_async_tx_descriptor  *data_desc_rx;
+   struct dma_async_tx_descriptor  *data_desc_tx;
+};
 
 /*
  * The core SPI transfer engine just talks to a register bank to set up
@@ -188,6 +203,8 @@
  */
 struct atmel_spi_pdata {
u8  version;
+   boolhas_dma_support;
+   struct at_dma_slave dma_slave;
 };
 
 struct atmel_spi {
@@ -203,6 +220,7 @@ struct atmel_spi {
 
u8  stopping;
struct list_headqueue;
+   struct tasklet_struct   tasklet;
struct spi_transfer *current_transfer;
unsigned long   current_remaining_bytes;
struct spi_transfer *next_transfer;
@@ -210,8 +228,15 @@ struct atmel_spi {
int done_status;
struct atmel_spi_pdata  *pdata;
 
+   booluse_dma;
+   booluse_pdc;
+
+   /* scratch buffer */
void*buffer;
dma_addr_t  buffer_dma;
+
+   /* dmaengine data */
+   struct atmel_spi_dmadma;
 };
 
 /* Controller-specific per-slave state */
@@ -225,14 +250,17 @@ struct atmel_spi_device {
 
 static struct atmel_spi_pdata at91rm9200_config = {
.version = 1,
+   .has_dma_support = false,
 };
 
 static struct atmel_spi_pdata at91sam9260_config = {
.version = 2,
+   .has_dma_support = false,
 };
 
 static struct atmel_spi_pdata at91sam9x5_config = {
.version = 2,
+   .has_dma_support = true,
 };
 
 static const struct platform_device_id atmel_spi_devtypes[] = {
@@ -309,9 +337,7 @@ static bool atmel_spi_is_v2(struct atmel_spi *as)
  * and (c) will trigger that first erratum in some cases.
  *
  * TODO: Test if the atmel_spi_is_v2() branch below works on
- * AT91RM9200 if we use some other register than CSR0. However, don't
- * do this unconditionally since AP7000 has an errata where the BITS
- * field in CSR0 overrides all other CSRs.
+ * AT91RM9200 if we use some other register than CSR0.
  */
 
 static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
@@ -321,14 +347,9 @@ static void cs_activate(struct atmel_spi *as, struct 
spi_device *spi)
u32 mr;
 
if (atmel_spi_is_v2(as)) {
-   /*
-* Always use CSR0. This ensures that the clock
-* switches to the correct idle polarity before we
-* toggle the CS.
-*/
-   spi_writel(as, CSR0, asd->csr);
-   spi_writel(as, MR, SPI_BF(PCS, 0x0e) | SPI_BIT(MODFDIS)
-   | SPI_BIT(MSTR));
+   spi_writel(as, CSR0 + 4 * spi->chip_select, asd->csr);
+   spi_writel(as, MR, SPI_BF(PCS, ~(0x01 << spi->chip_select))
+   | SPI_BIT(MODFDIS) | SPI_BIT(MSTR));
mr = spi_readl(as, MR);
 

[v2 PATCH 09/14] spi/atmel_spi: Fix spi-atmel driver to adapt to slave_config changes

2012-12-03 Thread Wenyou Yang
From: Richard Genoud 

This is the following of the patch e2b35f3dbfc080f15b72834d08f04f0269dbe9be

Signed-off-by: Richard Genoud 
[wenyou.y...@atmel.com: fix DMA: when enable both spi0 and spi1, spi0 doesn't 
work]
Signed-off-by: Wenyou Yang 
Cc: grant.lik...@secretlab.ca
Cc: spi-devel-gene...@lists.sourceforge.net
---
 drivers/spi/spi-atmel.c |   60 ---
 1 file changed, 51 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 1de45c2..7f624b6 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -438,6 +438,37 @@ static inline int atmel_spi_xfer_can_be_chained(struct 
spi_transfer *xfer)
return xfer->delay_usecs == 0 && !xfer->cs_change;
 }
 
+static int atmel_spi_dma_slave_config(struct atmel_spi *as,
+   struct dma_slave_config *slave_config)
+{
+   int err = 0;
+
+   slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+   slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+
+   slave_config->dst_addr = (dma_addr_t)as->phybase + SPI_TDR;
+   slave_config->src_addr = (dma_addr_t)as->phybase + SPI_RDR;
+   slave_config->src_maxburst = 1;
+   slave_config->dst_maxburst = 1;
+   slave_config->device_fc = false;
+
+   slave_config->direction = DMA_MEM_TO_DEV;
+   if (dmaengine_slave_config(as->dma.chan_tx, slave_config)) {
+   dev_err(>pdev->dev,
+   "failed to configure tx dma channel\n");
+   err = -EINVAL;
+   }
+
+   slave_config->direction = DMA_DEV_TO_MEM;
+   if (dmaengine_slave_config(as->dma.chan_rx, slave_config)) {
+   dev_err(>pdev->dev,
+   "failed to configure rx dma channel\n");
+   err = -EINVAL;
+   }
+
+   return err;
+}
+
 static bool filter(struct dma_chan *chan, void *slave)
 {
struct  at_dma_slave *sl = slave;
@@ -454,14 +485,12 @@ static int __devinit atmel_spi_configure_dma(struct 
atmel_spi *as)
 {
struct at_dma_slave *sdata
= (struct at_dma_slave *)>pdata->dma_slave;
+   struct dma_slave_config slave_config;
+   int err;
 
if (sdata && sdata->dma_dev) {
dma_cap_mask_t mask;
 
-   /* setup DMA addresses */
-   sdata->rx_reg = (dma_addr_t)as->phybase + SPI_RDR;
-   sdata->tx_reg = (dma_addr_t)as->phybase + SPI_TDR;
-
/* Try to grab two DMA channels */
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -471,21 +500,28 @@ static int __devinit atmel_spi_configure_dma(struct 
atmel_spi *as)
dma_request_channel(mask, filter, sdata);
}
if (!as->dma.chan_rx || !as->dma.chan_tx) {
-   if (as->dma.chan_rx)
-   dma_release_channel(as->dma.chan_rx);
-   if (as->dma.chan_tx)
-   dma_release_channel(as->dma.chan_tx);
dev_err(>pdev->dev, "DMA channel not available, " \
"unable to use SPI\n");
-   return -EBUSY;
+   err = -EBUSY;
+   goto error;
}
 
+   err = atmel_spi_dma_slave_config(as, _config);
+   if (err)
+   goto error;
+
dev_info(>pdev->dev, "Using %s (tx) and " \
" %s (rx) for DMA transfers\n",
dma_chan_name(as->dma.chan_tx),
dma_chan_name(as->dma.chan_rx));
 
return 0;
+error:
+   if (as->dma.chan_rx)
+   dma_release_channel(as->dma.chan_rx);
+   if (as->dma.chan_tx)
+   dma_release_channel(as->dma.chan_tx);
+   return err;
 }
 
 static void atmel_spi_stop_dma(struct atmel_spi *as)
@@ -562,6 +598,7 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master 
*master,
struct dma_chan *txchan = as->dma.chan_tx;
struct dma_async_tx_descriptor *rxdesc;
struct dma_async_tx_descriptor *txdesc;
+   struct dma_slave_config slave_config;
dma_cookie_tcookie;
u32 len = *plen;
 
@@ -600,6 +637,10 @@ static int atmel_spi_next_xfer_dma_submit(struct 
spi_master *master,
 
*plen = len;
 
+   if (atmel_spi_dma_slave_config(as, _config))
+   goto err_exit;
+
+
/* Send both scatterlists */
rxdesc = rxchan->device->device_prep_slave_sg(rxchan,
>dma.sgrx,
@@ -648,6 +689,7 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master 
*master,
 err_dma:
spi_writel(as, IDR, SPI_BIT(OVRES));
atmel_spi_stop_dma(as);
+err_exit:
atmel_spi_lock(as);
return -ENOMEM;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org

[v2 PATCH 06/14] spi/atmel_spi: add flag to controller data for lock operations

2012-12-03 Thread Wenyou Yang
From: Nicolas Ferre 

Will allow to drop the lock during DMA operations.

Signed-off-by: Nicolas Ferre 
Cc: grant.lik...@secretlab.ca
Cc: spi-devel-gene...@lists.sourceforge.net
---
 drivers/spi/spi-atmel.c |   31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 76a1baf..37f54c3 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -187,6 +187,7 @@
  */
 struct atmel_spi {
spinlock_t  lock;
+   unsigned long   flags;
 
resource_size_t phybase;
void __iomem*regs;
@@ -323,6 +324,16 @@ static void cs_deactivate(struct atmel_spi *as, struct 
spi_device *spi)
gpio_set_value(asd->npcs_pin, !active);
 }
 
+static void atmel_spi_lock(struct atmel_spi *as)
+{
+   spin_lock_irqsave(>lock, as->flags);
+}
+
+static void atmel_spi_unlock(struct atmel_spi *as)
+{
+   spin_unlock_irqrestore(>lock, as->flags);
+}
+
 static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
struct spi_transfer *xfer)
 {
@@ -559,9 +570,9 @@ atmel_spi_msg_done(struct spi_master *master, struct 
atmel_spi *as,
"xfer complete: %u bytes transferred\n",
msg->actual_length);
 
-   spin_unlock(>lock);
+   atmel_spi_unlock(as);
msg->complete(msg->context);
-   spin_lock(>lock);
+   atmel_spi_lock(as);
 
as->current_transfer = NULL;
as->next_transfer = NULL;
@@ -788,13 +799,11 @@ static int atmel_spi_setup(struct spi_device *spi)
spi->controller_state = asd;
gpio_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
} else {
-   unsigned long   flags;
-
-   spin_lock_irqsave(>lock, flags);
+   atmel_spi_lock(as);
if (as->stay == spi)
as->stay = NULL;
cs_deactivate(as, spi);
-   spin_unlock_irqrestore(>lock, flags);
+   atmel_spi_unlock(as);
}
 
asd->csr = csr;
@@ -813,7 +822,6 @@ static int atmel_spi_transfer(struct spi_device *spi, 
struct spi_message *msg)
 {
struct atmel_spi*as;
struct spi_transfer *xfer;
-   unsigned long   flags;
struct device   *controller = spi->master->dev.parent;
u8  bits;
struct atmel_spi_device *asd;
@@ -878,11 +886,11 @@ static int atmel_spi_transfer(struct spi_device *spi, 
struct spi_message *msg)
msg->status = -EINPROGRESS;
msg->actual_length = 0;
 
-   spin_lock_irqsave(>lock, flags);
+   atmel_spi_lock(as);
list_add_tail(>queue, >queue);
if (!as->current_transfer)
atmel_spi_next_message(spi->master);
-   spin_unlock_irqrestore(>lock, flags);
+   atmel_spi_unlock(as);
 
return 0;
 }
@@ -892,17 +900,16 @@ static void atmel_spi_cleanup(struct spi_device *spi)
struct atmel_spi*as = spi_master_get_devdata(spi->master);
struct atmel_spi_device *asd = spi->controller_state;
unsignedgpio = (unsigned) spi->controller_data;
-   unsigned long   flags;
 
if (!asd)
return;
 
-   spin_lock_irqsave(>lock, flags);
+   atmel_spi_lock(as);
if (as->stay == spi) {
as->stay = NULL;
cs_deactivate(as, spi);
}
-   spin_unlock_irqrestore(>lock, flags);
+   atmel_spi_unlock(as);
 
spi->controller_state = NULL;
gpio_free(gpio);
-- 
1.7.9.5

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


[v2 PATCH 07/14] spi/atmel_spi: add DT support

2012-12-03 Thread Wenyou Yang
From: Jean-Christophe PLAGNIOL-VILLARD 

The atmel_spi use only gpio for chip select.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
[wenyou.y...@atmel.com: Add driver data and compatible "atmel,at91sam9260-spi", 
"atmel,at91sam9x5-spi"]
Signed-off-by: Wenyou Yang 
Cc: devicetree-disc...@lists.ozlabs.org
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: grant.lik...@secretlab.ca
Cc: rob.herr...@calxeda.com
Cc: r...@landley.net
Cc: linux-...@vger.kernel.org
Cc: richard.gen...@gmail.com
---
Hi, Richard,

This patches is based on the original patch from Jean-Christophe
[PATCH] spi/atmel: add DT support
and merge the patch from Richard Genoud
[PATCH] spi-atmel OF: complete documentation
ane wenyou yang add more compatible "atmel,at91sam9260-spi", 
"atmel,at91sam9x5-spi", 
add driver data to get IP version and dma support.

Could you sign your signature in this patch?

Best Regards,
Wenyou Yang

 .../devicetree/bindings/spi/spi_atmel.txt  |   23 +
 drivers/spi/spi-atmel.c|  102 +---
 2 files changed, 113 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel.txt

diff --git a/Documentation/devicetree/bindings/spi/spi_atmel.txt 
b/Documentation/devicetree/bindings/spi/spi_atmel.txt
new file mode 100644
index 000..20cdc91
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi_atmel.txt
@@ -0,0 +1,23 @@
+Atmel SPI device
+
+Required properties:
+- compatible : should be "atmel,at91rm9200-spi".
+- reg: Address and length of the register set for the device
+- interrupts: Should contain macb interrupt
+- cs-gpio: Should contain the GPIOs used for chipselect.
+- dma-mask: device coherent dma mask.
+
+spi0: spi@f000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "atmel,at91rm9200-spi";
+   reg = <0xf000 0x100>;
+   interrupts = <13 4>;
+   cs-gpios = < 14 0
+7 0 /* conflicts with TXD2 */
+1 0 /* conflicts with RXD0 */
+3 0 /* conflicts with ERXDV */
+  >;
+   dma-mask = <0x>;
+   status = "disabled";
+};
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 37f54c3..e032e3d 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -185,6 +186,10 @@
  * DMA transfers; transfer queue progress is driven by IRQs.  The clock
  * framework provides the base clock, subdivided for each spi_device.
  */
+struct atmel_spi_pdata {
+   u8  version;
+};
+
 struct atmel_spi {
spinlock_t  lock;
unsigned long   flags;
@@ -203,6 +208,7 @@ struct atmel_spi {
struct spi_transfer *next_transfer;
unsigned long   next_remaining_bytes;
int done_status;
+   struct atmel_spi_pdata  *pdata;
 
void*buffer;
dma_addr_t  buffer_dma;
@@ -217,6 +223,51 @@ struct atmel_spi_device {
 #define BUFFER_SIZEPAGE_SIZE
 #define INVALID_DMA_ADDRESS0x
 
+static struct atmel_spi_pdata at91rm9200_config = {
+   .version = 1,
+};
+
+static struct atmel_spi_pdata at91sam9260_config = {
+   .version = 2,
+};
+
+static struct atmel_spi_pdata at91sam9x5_config = {
+   .version = 2,
+};
+
+static const struct platform_device_id atmel_spi_devtypes[] = {
+   {
+   .name = "spi-at91rm9200",
+   .driver_data = (unsigned long) _config,
+   }, {
+   .name = "spi-at91sam9260",
+   .driver_data = (unsigned long) _config,
+   }, {
+   .name = "spi-at91sam9x5",
+   .driver_data = (unsigned long) _config,
+   }, {
+   /* sentinel */
+   }
+};
+
+#if defined(CONFIG_OF)
+static const struct of_device_id atmel_spi_dt_ids[] = {
+   {
+   .compatible = "atmel,at91rm9200-spi",
+   .data = _config,
+   } , {
+   .compatible = "atmel,at91sam9260-spi",
+   .data = _config,
+   } , {
+   .compatible = "atmel,at91sam9x5-spi",
+   .data = _config,
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(of, atmel_spi_dt_ids);
+#endif
+
 /*
  * Version 2 of the SPI controller has
  *  - CR.LASTXFER
@@ -229,11 +280,15 @@ struct atmel_spi_device {
  * register, but I haven't checked that it exists on all chips, and
  * this is cheaper anyway.
  */
-static bool atmel_spi_is_v2(void)
+static bool atmel_spi_is_v2(struct atmel_spi *as)
 {
-   return !cpu_is_at91rm9200();
+   if (as->pdata->version == 2)
+   return true;
+   else
+   return false;
 }
 
+
 /*
  * Earlier SPI controllers (e.g. on at91rm9200) have a design bug whereby
  * they assume that spi slave device 

[v2 PATCH 05/14] spi/atmel_spi: status information passed through controller data

2012-12-03 Thread Wenyou Yang
From: Nicolas Ferre 

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

Signed-off-by: Nicolas Ferre 
Cc: grant.lik...@secretlab.ca
Cc: spi-devel-gene...@lists.sourceforge.net
---
 drivers/spi/spi-atmel.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index fc1222a..76a1baf 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -201,6 +201,7 @@ struct atmel_spi {
unsigned long   current_remaining_bytes;
struct spi_transfer *next_transfer;
unsigned long   next_remaining_bytes;
+   int done_status;
 
void*buffer;
dma_addr_t  buffer_dma;
@@ -544,15 +545,15 @@ static void atmel_spi_dma_unmap_xfer(struct spi_master 
*master,
 
 static void
 atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
-   struct spi_message *msg, int status, int stay)
+   struct spi_message *msg, int stay)
 {
-   if (!stay || status < 0)
+   if (!stay || as->done_status < 0)
cs_deactivate(as, msg->spi);
else
as->stay = msg->spi;
 
list_del(>queue);
-   msg->status = status;
+   msg->status = as->done_status;
 
dev_dbg(master->dev.parent,
"xfer complete: %u bytes transferred\n",
@@ -564,6 +565,7 @@ atmel_spi_msg_done(struct spi_master *master, struct 
atmel_spi *as,
 
as->current_transfer = NULL;
as->next_transfer = NULL;
+   as->done_status = 0;
 
/* continue if needed */
if (list_empty(>queue) || as->stopping)
@@ -641,7 +643,8 @@ atmel_spi_interrupt(int irq, void *dev_id)
/* Clear any overrun happening while cleaning up */
spi_readl(as, SR);
 
-   atmel_spi_msg_done(master, as, msg, -EIO, 0);
+   as->done_status = -EIO;
+   atmel_spi_msg_done(master, as, msg, 0);
} else if (pending & (SPI_BIT(RXBUFF) | SPI_BIT(ENDRX))) {
ret = IRQ_HANDLED;
 
@@ -659,7 +662,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
 
if (atmel_spi_xfer_is_last(msg, xfer)) {
/* report completed message */
-   atmel_spi_msg_done(master, as, msg, 0,
+   atmel_spi_msg_done(master, as, msg,
xfer->cs_change);
} else {
if (xfer->cs_change) {
-- 
1.7.9.5

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


[v2 PATCH 04/14] spi/atmel_spi: call unmapping on transfers buffers

2012-12-03 Thread Wenyou Yang
From: Nicolas Ferre 

Signed-off-by: Nicolas Ferre 
Cc: grant.lik...@secretlab.ca
Cc: spi-devel-gene...@lists.sourceforge.net
---
 drivers/spi/spi-atmel.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 2e040be..fc1222a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1010,6 +1010,7 @@ static int __devexit atmel_spi_remove(struct 
platform_device *pdev)
struct spi_master   *master = platform_get_drvdata(pdev);
struct atmel_spi*as = spi_master_get_devdata(master);
struct spi_message  *msg;
+   struct spi_transfer *xfer;
 
/* reset the hardware and block queue progress */
spin_lock_irq(>lock);
@@ -1021,9 +1022,10 @@ static int __devexit atmel_spi_remove(struct 
platform_device *pdev)
 
/* Terminate remaining queued transfers */
list_for_each_entry(msg, >queue, queue) {
-   /* REVISIT unmapping the dma is a NOP on ARM and AVR32
-* but we shouldn't depend on that...
-*/
+   list_for_each_entry(xfer, >transfers, transfer_list) {
+   if (!msg->is_dma_mapped)
+   atmel_spi_dma_unmap_xfer(master, xfer);
+   }
msg->status = -ESHUTDOWN;
msg->complete(msg->context);
}
-- 
1.7.9.5

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


Re: [PATCH 1/5] asm-generic/mmu.h: Remove unused vmlist field from mm_context_t

2012-12-03 Thread Lars-Peter Clausen
On 12/04/2012 12:54 AM, Arnd Bergmann wrote:
> On Thursday 01 November 2012, Lars-Peter Clausen wrote:
>> Nothing is using the vmlist field in mm_context_t anymore. It has been 
>> removed
>> from the non-generic versions over 3 years ago 8feae1311 ("NOMMU: Make VMAs 
>> per
>> MM as for MMU-mode linux").
>>
>> Signed-off-by: Lars-Peter Clausen 
> 
> Whole series:
> 
> Acked-by: Arnd Bergmann 
> 
> Do you want to include the patches in a patch set of your own, or should I 
> put them
> into the asm-generic tree?
> 
>   Arnd

Hi Arnd,

The plan was to let it go through the asm-generic tree.

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


[v2 PATCH 01/14] of: add dma-mask binding

2012-12-03 Thread Wenyou Yang
From: Jean-Christophe PLAGNIOL-VILLARD 

This will allow each device to specify its dma-mask for this we use the
coherent_dma_mask as pointer. By default the dma-mask will be set to
DMA_BIT_MASK(32).
The microblaze architecture hook is drop

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
Cc: grant.lik...@secretlab.ca
Cc: rob.herr...@calxeda.com
Cc: devicetree-disc...@lists.ozlabs.org
---
 drivers/of/platform.c |   23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b80891b..31ed405 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -130,6 +130,21 @@ void of_device_make_bus_id(struct device *dev)
dev_set_name(dev, "%s.%d", node->name, magic - 1);
 }
 
+static void of_get_dma_mask(struct device *dev, struct device_node *np)
+{
+   const __be32 *prop;
+   int len;
+
+   prop = of_get_property(np, "dma-mask", );
+
+   dev->dma_mask = >coherent_dma_mask;
+
+   if (!prop)
+   dev->coherent_dma_mask = DMA_BIT_MASK(32);
+   else
+   dev->coherent_dma_mask = of_read_number(prop, len / 4);
+}
+
 /**
  * of_device_alloc - Allocate and initialize an of_device
  * @np: device node to assign to device
@@ -171,10 +186,8 @@ struct platform_device *of_device_alloc(struct device_node 
*np,
WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
}
 
+   of_get_dma_mask(>dev, np);
dev->dev.of_node = of_node_get(np);
-#if defined(CONFIG_MICROBLAZE)
-   dev->dev.dma_mask = >archdata.dma_mask;
-#endif
dev->dev.parent = parent;
 
if (bus_id)
@@ -211,10 +224,6 @@ struct platform_device *of_platform_device_create_pdata(
if (!dev)
return NULL;
 
-#if defined(CONFIG_MICROBLAZE)
-   dev->archdata.dma_mask = 0xUL;
-#endif
-   dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dev->dev.bus = _bus_type;
dev->dev.platform_data = platform_data;
 
-- 
1.7.9.5

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


[v2 PATCH 00/14] atmel SPI controller with dmaengine and device tree support

2012-12-03 Thread Wenyou Yang
Hi All, 

This set of patches is to add dmaengine and device tree support for atmel spi.
The work is based on Jean-Christophe, Nicolas and Richard's work.
I tested it on at91sam9x5ek, at91sam9m10g45ek.

It is based on v3.7-rc8.

Changelog:
v2: 
   1./ Remove the patch :PATCH]mtd: m25p80: change the m25p80_read to reading 
page to page
which purpose to fix the BUG: when run "flashcp /bin/busybox /dev/mtdX" 
in 
the at91sam9g25ek with DMA mode, it arises a OOPS. 
Now fix it in this patch:
[PATHC] spi/atmel_spi: add dmaengine support changing to fix the [BUG].

   2./ Remove two patches:
which purpose to read dts property to select SPI IP version and DMA mode
Now they will be gat from device tree different compatile.

   3./ Fix DMA: when enable both spi0 AND spi1, the spi0 doesn't work BUG.

   4./ Rebase v3.7-rc8.

Best Regards,
Wenyou Yang.


Jean-Christophe PLAGNIOL-VILLARD (3):
  of: add dma-mask binding
  of_spi: add generic binding support to specify cs gpio
  spi/atmel_spi: add DT support

Nicolas Ferre (5):
  spi/atmel_spi: add physical base address
  spi/atmel_spi: call unmapping on transfers buffers
  spi/atmel_spi: status information passed through controller data
  spi/atmel_spi: add flag to controller data for lock operations
  spi/atmel_spi: add dmaengine support

Richard Genoud (6):
  spi/atmel_spi: Fix spi-atmel driver to adapt to slave_config changes
  spi/atmel_spi: correct 16 bits transfers using PIO
  spi/atmel_spi: correct 16 bits transfer with DMA
  ARM: at91: add clocks for spi DT entries
  ARM: dts: add spi nodes for atmel SoC
  ARM: dts: add spi nodes for atmel boards

 Documentation/devicetree/bindings/spi/spi-bus.txt  |6 +
 .../devicetree/bindings/spi/spi_atmel.txt  |   23 +
 arch/arm/boot/dts/at91sam9260.dtsi |   30 +
 arch/arm/boot/dts/at91sam9263.dtsi |   30 +
 arch/arm/boot/dts/at91sam9263ek.dts|9 +
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi|9 +
 arch/arm/boot/dts/at91sam9g25ek.dts|9 +
 arch/arm/boot/dts/at91sam9g45.dtsi |   30 +
 arch/arm/boot/dts/at91sam9m10g45ek.dts |9 +
 arch/arm/boot/dts/at91sam9n12.dtsi |   30 +
 arch/arm/boot/dts/at91sam9n12ek.dts|9 +
 arch/arm/boot/dts/at91sam9x5.dtsi  |   30 +
 arch/arm/mach-at91/at91sam9260.c   |2 +
 arch/arm/mach-at91/at91sam9g45.c   |2 +
 arch/arm/mach-at91/at91sam9n12.c   |2 +
 arch/arm/mach-at91/at91sam9x5.c|2 +
 drivers/of/platform.c  |   23 +-
 drivers/spi/spi-atmel.c|  793 ++--
 drivers/spi/spi.c  |   55 +-
 include/linux/spi/spi.h|3 +
 20 files changed, 1033 insertions(+), 73 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel.txt

-- 
1.7.9.5

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


Re: [PATCH -next 0/9] tty: Fix buffer work access-after-free

2012-12-03 Thread Ilya Zykov
On 04.12.2012 11:07, Peter Hurley wrote:
> This patch series addresses the causes of flush_to_ldisc accessing
> the tty after freeing.
> 

I think, it is have sense only if you can take effect,
with this patch or something like. I can't. :)

Signed-off-by: Ilya Zykov 
---
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 2ea176b..f24751d 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -170,6 +170,10 @@ struct tty_struct *alloc_tty_struct(void)
return kzalloc(sizeof(struct tty_struct), GFP_KERNEL);
 }

+static void flush_to_ldisc2(struct work_struct *work)
+{
+   printk(KERN_WARNING "Possible intrusion detected.\n");
+}
 /**
  * free_tty_struct -   free a disused tty
  * @tty: tty struct to free
@@ -188,6 +192,8 @@ void free_tty_struct(struct tty_struct *tty)
kfree(tty->write_buf);
tty_buffer_free_all(tty);
tty->magic = 0xDEADDEAD;
+   PREPARE_WORK(>buf.work,flush_to_ldisc2);
+   //memset(tty, 0, sizeof(struct tty_struct));
kfree(tty);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [net-next rfc v7 2/3] virtio_net: multiqueue support

2012-12-03 Thread Michael S. Tsirkin
On Mon, Dec 03, 2012 at 06:30:49PM +0800, Jason Wang wrote:
> On 12/03/2012 06:14 PM, Michael S. Tsirkin wrote:
> > On Tue, Nov 27, 2012 at 06:15:59PM +0800, Jason Wang wrote:
> >> > -if (!try_fill_recv(>rq, GFP_KERNEL))
> >> > -schedule_delayed_work(>rq.refill, 0);
> >> > +for (i = 0; i < vi->max_queue_pairs; i++)
> >> > +if (!try_fill_recv(>rq[i], GFP_KERNEL))
> >> > +schedule_delayed_work(>rq[i].refill, 0);
> >> >  
> >> >  mutex_lock(>config_lock);
> >> >  vi->config_enable = true;
> >> >  mutex_unlock(>config_lock);
> >> >  
> >> > +BUG_ON(virtnet_set_queues(vi));
> >> > +
> >> >  return 0;
> >> >  }
> >> >  #endif
> > Also crashing on device nack of command is also not nice.
> > In this case it seems we can just switch to
> > single-queue mode which should always be safe.
> 
> Not sure it's safe. It depends on the reason why this call fails. If we
> left a state that the driver only use single queue but the device use
> multi queues, we may still lost the network.

Looks like we won't: napi will stay enabled on all queues
so we will process incoming packets.

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


Re: [PATCH 1/2] Input: xpad - Minor coding style errors fixed.

2012-12-03 Thread Guillermo A. Amaral
On Mon, Dec 03, 2012 at 09:24:00PM -0800, Dmitry Torokhov wrote:
> On Sat, Dec 01, 2012 at 11:36:19PM -0800, Guillermo A. Amaral wrote:
> > From: "Guillermo A. Amaral" 
> > 
> > Fixed a few minor coding style issues in xpad driver.
> 
> Applied both, thanks Guillermo.

Thanks! Sorry about the double email btw, I thought it failed to send the
first one.

I've getting quite a few gamepad donations for my game console project, so
expect more patches. ;)

Cheers,
G

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


Re: [YASB] Re: Linux 3.7-rc7

2012-12-03 Thread Andreas Mohr
Hi,

On Mon, Dec 03, 2012 at 08:48:17PM +0100, Andreas Mohr wrote:
> Will try script to unload half of all drivers etc.
> (heavy amounts of bisection wouldn't be joyful on this box).
> 
> 
> I failed to mention the effects:
> Suspend starts, disk does spin down, yet display backlight stays
> until finally monitor blanks.

Unloading *all* unloadable modules didn't help.

Current status:

$ git bisect log
git bisect start
# good: [f4a75d2eb7b1e2206094b901be09adb31ba63681] Linux 3.7-rc6
git bisect good f4a75d2eb7b1e2206094b901be09adb31ba63681
# bad: [3c46f3d6406b1d0c53575774b2d1fd013cd7f76f] Merge branch
# 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
git bisect bad 3c46f3d6406b1d0c53575774b2d1fd013cd7f76f
# good: [35f95d228e55eebdc87b5c0dbdecc46884f476a6] Merge tag
# 'for-linus-20121123' of git://git.infradead.org/mtd-2.6
git bisect good 35f95d228e55eebdc87b5c0dbdecc46884f476a6
# good: [e9296e89b85604862bd9ec2d54dc43edad775c0d] Merge
# git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good e9296e89b85604862bd9ec2d54dc43edad775c0d


Currently processing a95251b8bac4a91a43db795a7193545dac65f4f4 .


So far everything in the normal, no interim (build) breakage etc.

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


Re: [RFC v2] Support volatile range for anon vma

2012-12-03 Thread Minchan Kim
On Mon, Dec 03, 2012 at 04:57:20PM -0800, John Stultz wrote:
> On 12/03/2012 04:00 PM, Minchan Kim wrote:
> >On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote:
> >>On 11/21/2012 04:36 PM, John Stultz wrote:
> >>>2) Being able to use this with tmpfs files. I'm currently trying
> >>>to better understand the rmap code, looking to see if there's a
> >>>way to have try_to_unmap_file() work similarly to
> >>>try_to_unmap_anon(), to allow allow users to madvise() on mmapped
> >>>tmpfs files. This would provide a very similar interface as to
> >>>what I've been proposing with fadvise/fallocate, but just using
> >>>process virtual addresses instead of (fd, offset) pairs.   The
> >>>benefit with (fd,offset) pairs for Android is that its easier to
> >>>manage shared volatile ranges between two processes that are
> >>>sharing data via an mmapped tmpfs file (although this actual use
> >>>case may be fairly rare).  I believe we should still be able to
> >>>rework the ashmem internals to use madvise (which would provide
> >>>legacy support for existing android apps), so then its just a
> >>>question of if we could then eventually convince Android apps to
> >>>use the madvise interface directly, rather then the ashmem unpin
> >>>ioctl.
> >>Hey Minchan,
> >> I've been playing around with your patch trying to better
> >>understand your approach and to extend it to support tmpfs files. In
> >>doing so I've found a few bugs, and have some rough fixes I wanted
> >>to share. There's still a few edge cases I need to deal with (the
> >>vma-purged flag isn't being properly handled through vma merge/split
> >>operations), but its starting to come along.
> >Hmm, my patch doesn't allow to merge volatile with another one by
> >inserting VM_VOLATILE into VM_SPECIAL so I guess merge isn't problem.
> >In case of split, __split_vma copy old vma to new vma like this
> >
> > *new = *vma;
> >
> >So the problem shouldn't happen, I guess.
> >Did you see the real problem about that?
> Yes, depending on the pattern that MADV_VOLATILE and MADV_NOVOLATILE
> is applied, we can get a result where data is purged, but we aren't
> notified of it.  Also, since madvise returns early if it encounters
> an error, in the case where you have checkerboard volatile regions
> (say every other page is volatile), which you mark non-volatile with
> one large MADV_NOVOLATILE call, the first volatile vma will be
> marked non-volatile, but since it returns purged, the madvise loop
> will stop and the following volatile regions will be left volatile.
> 
> The patches in the git tree below which handle the perged state
> better seem to work for my tests, as far as resolving any
> overlapping calls. Of course there may yet still be problems I've
> not found.
> 
> >>Anyway, take a look at the tree here and let me know what you think.
> >>http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/minchan-anonvol
> 
> Eager to hear what you think!

Below two patches look good to me.

[rmap: Simplify volatility checking by moving it out of try_to_unmap_one]
[rmap: ClearPageDirty() when returning SWAP_DISCARD]

[madvise: Fix NOVOLATILE bug]
I can't understand description of the patch.
Could you elaborate it with example?

[madvise: Fixup vma->purged handling]
I included VM_VOLATILE into VM_SPECIAL intentionally.
If comment of VM_SPECIAL is right, merge with volatile vmas shouldn't happen.
So I guess you see other problem. When I see my source code today, locking
scheme/purge handling is totally broken. I will look at it. Maybe you are seeing
bug related that. Part of patch is needed. It could be separate patch.
I will merge it.

ff --git a/mm/madvise.c b/mm/madvise.c
index 65af0b5..5469d76 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -139,8 +139,10 @@ success:
if (behavior == MADV_NOVOLATILE || behavior == MADV_VOLATILE)
volatile_lock(vma);
vma->vm_flags = new_flags;
-   if (behavior == MADV_NOVOLATILE)
+   if (behavior == MADV_NOVOLATILE) {
error = vma->purged;
+   vma->purged = 0;
+   }
if (behavior == MADV_NOVOLATILE || behavior == MADV_VOLATILE)
volatile_unlock(vma);
 out:

First of all, after I resolve above issue, let's talk about tmpfs volatile.
Thanks for the fix, John!

> 
> Thanks again!
> -john
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

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


Re: [PATCH v3 1/7] mfd: max8925: add irqdomain for dt

2012-12-03 Thread Haojian Zhuang
On Thu, Nov 29, 2012 at 11:29 AM, Qing Xu  wrote:
> From: Qing Xu 
>
> Add irqdomains for max8925's main irq, wrap irq register operations
> into irqdomain's map func. it is necessary for dt support.
>
> Also, add dt support for max8925 driver.
>
> Signed-off-by: Qing Xu 
> ---
>  drivers/mfd/max8925-core.c  |   69 
> ++-
>  drivers/mfd/max8925-i2c.c   |   37 +--
>  include/linux/mfd/max8925.h |3 +-
>  3 files changed, 78 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
> index 1e0ab0a..d0ebdbf 100644
> --- a/drivers/mfd/max8925-core.c
> +++ b/drivers/mfd/max8925-core.c
> @@ -14,10 +14,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  static struct resource bk_resources[] __devinitdata = {
> { 0x84, 0x84, "mode control", IORESOURCE_REG, },
> @@ -639,17 +642,33 @@ static struct irq_chip max8925_irq_chip = {
> .irq_disable= max8925_irq_disable,
>  };
>
> +static int max8925_irq_domain_map(struct irq_domain *d, unsigned int virq,
> +irq_hw_number_t hw)
> +{
> +   irq_set_chip_data(virq, d->host_data);
> +   irq_set_chip_and_handler(virq, _irq_chip, handle_edge_irq);
> +   irq_set_nested_thread(virq, 1);
> +#ifdef CONFIG_ARM
> +   set_irq_flags(virq, IRQF_VALID);
> +#else
> +   irq_set_noprobe(virq);
> +#endif
> +   return 0;
> +}
> +
> +static struct irq_domain_ops max8925_irq_domain_ops = {
> +   .map= max8925_irq_domain_map,
> +   .xlate  = irq_domain_xlate_onetwocell,
> +};
> +
> +
>  static int max8925_irq_init(struct max8925_chip *chip, int irq,
> struct max8925_platform_data *pdata)
>  {
> unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
> -   int i, ret;
> -   int __irq;
> +   int ret;
> +   struct device_node *node = chip->dev->of_node;
>
> -   if (!pdata || !pdata->irq_base) {
> -   dev_warn(chip->dev, "No interrupt support on IRQ base\n");
> -   return -EINVAL;
> -   }
> /* clear all interrupts */
> max8925_reg_read(chip->i2c, MAX8925_CHG_IRQ1);
> max8925_reg_read(chip->i2c, MAX8925_CHG_IRQ2);
> @@ -667,35 +686,32 @@ static int max8925_irq_init(struct max8925_chip *chip, 
> int irq,
> max8925_reg_write(chip->rtc, MAX8925_RTC_IRQ_MASK, 0xff);
>
> mutex_init(>irq_lock);
> -   chip->core_irq = irq;
> -   chip->irq_base = pdata->irq_base;
>
> -   /* register with genirq */
> -   for (i = 0; i < ARRAY_SIZE(max8925_irqs); i++) {
> -   __irq = i + chip->irq_base;
> -   irq_set_chip_data(__irq, chip);
> -   irq_set_chip_and_handler(__irq, _irq_chip,
> -handle_edge_irq);
> -   irq_set_nested_thread(__irq, 1);
> -#ifdef CONFIG_ARM
> -   set_irq_flags(__irq, IRQF_VALID);
> -#else
> -   irq_set_noprobe(__irq);
> -#endif
> -   }
> -   if (!irq) {
> -   dev_warn(chip->dev, "No interrupt support on core IRQ\n");
> -   goto tsc_irq;
> +   chip->irq_base = irq_alloc_descs(-1, 0, MAX8925_NR_IRQS, 0);
> +   if (chip->irq_base < 0) {
> +   dev_err(chip->dev, "Failed to allocate interrupts, ret:%d\n",
> +   chip->irq_base);
> +   return -EBUSY;
> }
>
> +   irq_domain_add_legacy(node, MAX8925_NR_IRQS, chip->irq_base, 0,
> + _irq_domain_ops, chip);
> +
> +   /* request irq handler for pmic main irq*/
> +
> +   chip->core_irq = irq;
> +   if (!chip->core_irq)
> +   return -EBUSY;
> ret = request_threaded_irq(irq, NULL, max8925_irq, flags,
>"max8925", chip);
> if (ret) {
> dev_err(chip->dev, "Failed to request core IRQ: %d\n", ret);
> chip->core_irq = 0;
> +   return -EBUSY;
> }
>
> -tsc_irq:
> +   /* request irq handler for pmic tsc irq*/
> +
> /* mask TSC interrupt */
> max8925_reg_write(chip->adc, MAX8925_TSC_IRQ_MASK, 0x0f);
>
> @@ -704,7 +720,6 @@ tsc_irq:
> return 0;
> }
> chip->tsc_irq = pdata->tsc_irq;
> -
> ret = request_threaded_irq(chip->tsc_irq, NULL, max8925_tsc_irq,
>flags, "max8925-tsc", chip);
> if (ret) {
> @@ -876,7 +891,7 @@ int __devinit max8925_device_init(struct max8925_chip 
> *chip,
> if (pdata && pdata->power) {
> ret = mfd_add_devices(chip->dev, 0, _devs[0],
> ARRAY_SIZE(power_devs),
> - _supply_resources[0], 0, NULL);
> +   _supply_resources[0], 0, NULL);
> 

Re: [PATCH 0/7] mfd: update on max8925 for DT support

2012-12-03 Thread Haojian Zhuang
On Thu, Nov 29, 2012 at 1:54 PM, Qing Xu  wrote:
> On 11/23/2012 05:09 PM, Haojian Zhuang wrote:
>>
>> On Tue, Nov 6, 2012 at 3:35 PM, Qing Xu  wrote:
>>>
>>> From: Qing Xu 
>>>
>>> 1. add irqdomain for max8925, it is necessary for dt support
>>> 2. bug fix in max8925 mfd devices'irq base and device registry failure
>>> 3. support DT for max8925 mfd devices
>>>
>>> Qing Xu (7):
>>>mfd: max8925: add irqdomain for dt
>>>mfd: max8925: fix mfd device register failure
>>>mfd: max8925: fix onkey driver irq base
>>>mfd: max8925: support dt for power supply
>>>mfd: max8925: support dt for regulator
>>>mfd: max8925: support dt for backlight
>>>mfd: max8925: add dts
>>>
>>>   arch/arm/boot/dts/mmp2-brownstone.dts |  166
>>> +
>>>   arch/arm/boot/dts/mmp2.dtsi   |4 +-
>>>   drivers/input/misc/max8925_onkey.c|3 -
>>>   drivers/mfd/max8925-core.c|  107 +
>>>   drivers/mfd/max8925-i2c.c |   32 ++-
>>>   drivers/power/max8925_power.c |   57 ++-
>>>   drivers/regulator/max8925-regulator.c |   35 +++-
>>>   drivers/video/backlight/max8925_bl.c  |   31 ++-
>>>   include/linux/mfd/max8925.h   |   12 ++-
>>>   9 files changed, 389 insertions(+), 58 deletions(-)
>>>
>> No document on devicetree binding?
>
> I added a new patch of "Documentation: add docs for max8925 dt",
> please help to review, thanks a lot!

Acked.

Samuel,
How do you think about this patch series? From my view, it's ok.

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


[PATCH -next 0/9] tty: Fix buffer work access-after-free

2012-12-03 Thread Peter Hurley
This patch series addresses the causes of flush_to_ldisc accessing
the tty after freeing.

The most common cause stems from the n_tty_close() path spuriously
scheduling buffer work, when the ldisc has already been halted.
This is fixed in 'tty: Don't reschedule buffer work while closing'

The other causes have a central theme: incorrect order-of-operations
when halting a line discipline. In general, to prevent buffer work
from being scheduled requires:
  1. Disallowing further ldisc references
  2. Waiting for all existing ldisc references to be released
  3. Cancelling existing buffer work
If the wait takes place _after_ cancellation, then new work
can be scheduled by existing holder(s) of ldisc reference(s). That's
bad.

Halting the line discipline is performed when,
 - hanging up the tty (tty_ldisc_hangup())
 - TIOCSETD ioctl (tty_set_ldisc())
 - finally closing the tty (pair) (tty_ldisc_release())

Concurrent halts are governed by the following requirements:
1. tty_ldisc_release is not concurrent with the other two and so
   does not need lock or state protection during the ldiscs halt.
2. Accesses through tty->ldisc must be protected by the ldisc_mutex.
   The wait operation checks the user count (ldisc references)
   in tty->ldisc->users.
3. tty_set_ldisc() reschedules buffer work that was pending when
   the ldiscs were halted. That must be an atomic operation in
   conjunction with re-enabling the ldisc -- which necessitates
   locking concurrent halts (tty_ldisc_release is exempt here)
4. The legacy mutex cannot be held while waiting for ldisc
   reference(s) release -or- for cancelling buffer work.
5. Because of #4, the legacy mutex must be dropped prior to or
   during the halt. Which means reacquiring after the halt. But
   to preserve lock order the ldisc_mutex must be dropped and
   reacquired after reacquiring the legacy mutex.
6. Because of #5, the ldisc state may have changed while the
   ldisc mutex was dropped.

Note: this series does not include the lock correction initially
reported on by Sebastian Andrzej Siewior  here
https://lkml.org/lkml/2012/11/21/267 . I commented on the latest
version here https://lkml.org/lkml/2012/12/3/362

This series also does not include Jiri's debug patch here
https://lkml.org/lkml/2012/11/2/278 for identifying which itty cleanup
path is used. I think it may be helpful to include this in -next.

Peter Hurley (9):
  tty: WARN if buffer work racing with tty free
  tty: Add diagnostic for halted line discipline
  tty: Don't reschedule buffer work while closing
  tty: Refactor wait for ldisc refs out of tty_ldisc_hangup()
  tty: Remove unnecessary re-test of ldisc ref count
  tty: Fix ldisc halt sequence on hangup
  tty: Strengthen no-subsequent-use guarantee of tty_ldisc_halt()
  tty: Remove unnecessary buffer work flush
  tty: Halt both ldiscs concurrently

 drivers/tty/n_tty.c  |   8 ++-
 drivers/tty/tty_buffer.c |   3 +
 drivers/tty/tty_io.c |   2 +
 drivers/tty/tty_ldisc.c  | 171 +--
 include/linux/tty.h  |   1 +
 5 files changed, 119 insertions(+), 66 deletions(-)

-- 
1.8.0

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


[PATCH -next 4/9] tty: Refactor wait for ldisc refs out of tty_ldisc_hangup()

2012-12-03 Thread Peter Hurley
Refactor tty_ldisc_hangup() to extract standalone function,
tty_ldisc_hangup_wait_idle(), to wait for ldisc references
to be released.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 54 -
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index f986bb0..6c1d8aa 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -549,6 +549,41 @@ static int tty_ldisc_halt(struct tty_struct *tty)
 }
 
 /**
+ * tty_ldisc_hangup_wait_idle - wait for the ldisc to become idle
+ * @tty: tty to wait for
+ *
+ * Wait for the line discipline to become idle. The discipline must
+ * have been halted for this to guarantee it remains idle.
+ *
+ * Caller must hold legacy and ->ldisc_mutex.
+ */
+static bool tty_ldisc_hangup_wait_idle(struct tty_struct *tty)
+{
+   while (tty->ldisc) {/* Not yet closed */
+   if (atomic_read(>ldisc->users) != 1) {
+   char cur_n[TASK_COMM_LEN], tty_n[64];
+   long timeout = 3 * HZ;
+   tty_unlock(tty);
+
+   while (tty_ldisc_wait_idle(tty, timeout) == -EBUSY) {
+   timeout = MAX_SCHEDULE_TIMEOUT;
+   printk_ratelimited(KERN_WARNING
+   "%s: waiting (%s) for %s took too long, 
but we keep waiting...\n",
+   __func__, get_task_comm(cur_n, current),
+   tty_name(tty, tty_n));
+   }
+   /* must reacquire both locks and preserve lock order */
+   mutex_unlock(>ldisc_mutex);
+   tty_lock(tty);
+   mutex_lock(>ldisc_mutex);
+   continue;
+   }
+   break;
+   }
+   return !!(tty->ldisc);
+}
+
+/**
  * tty_set_ldisc   -   set line discipline
  * @tty: the terminal to set
  * @ldisc: the line discipline
@@ -824,7 +859,6 @@ void tty_ldisc_hangup(struct tty_struct *tty)
cancel_work_sync(>port->buf.work);
set_bit(TTY_LDISC_HALTED, >flags);
mutex_unlock(>ldisc_mutex);
-retry:
tty_lock(tty);
mutex_lock(>ldisc_mutex);
 
@@ -832,23 +866,7 @@ retry:
   reopen it. We could defer this to the next open but
   it means auditing a lot of other paths so this is
   a FIXME */
-   if (tty->ldisc) {   /* Not yet closed */
-   if (atomic_read(>ldisc->users) != 1) {
-   char cur_n[TASK_COMM_LEN], tty_n[64];
-   long timeout = 3 * HZ;
-   tty_unlock(tty);
-
-   while (tty_ldisc_wait_idle(tty, timeout) == -EBUSY) {
-   timeout = MAX_SCHEDULE_TIMEOUT;
-   printk_ratelimited(KERN_WARNING
-   "%s: waiting (%s) for %s took too long, 
but we keep waiting...\n",
-   __func__, get_task_comm(cur_n, current),
-   tty_name(tty, tty_n));
-   }
-   mutex_unlock(>ldisc_mutex);
-   goto retry;
-   }
-
+   if (tty_ldisc_hangup_wait_idle(tty)) {
if (reset == 0) {
 
if (!tty_ldisc_reinit(tty, tty->termios.c_line))
-- 
1.8.0

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


Re: [PATCH] Documentation: add docs for max8925 dt

2012-12-03 Thread Haojian Zhuang
On Thu, Nov 29, 2012 at 1:52 PM, Qing Xu  wrote:
> From: Qing Xu 
>
> add docs for dt of max8925-mfd, max8925-backlight, and
> max8925-battery
>
> Signed-off-by: Qing Xu 
> ---
>  Documentation/devicetree/bindings/mfd/max8925.txt  |   64 
> 
>  .../bindings/power_supply/max8925_batter.txt   |   18 ++
>  .../bindings/video/backlight/max8925-backlight.txt |   10 +++
>  3 files changed, 92 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/max8925.txt
>  create mode 100644 
> Documentation/devicetree/bindings/power_supply/max8925_batter.txt
>  create mode 100644 
> Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
>

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


Re: Linux 3.7-rc8

2012-12-03 Thread Romain Francoise
Hi,

Linus Torvalds  writes:

> Does that fix the printk's for you too?

Yep, works for me, thanks!

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


[PATCH -next 7/9] tty: Strengthen no-subsequent-use guarantee of tty_ldisc_halt()

2012-12-03 Thread Peter Hurley
In preparation for destructing and freeing the tty, the line discipline
must first be brought to an inactive state before it can be destructed.
This line discipline shutdown must:
 - disallow new users of the ldisc
 - wait for existing ldisc users to finish
 - only then, cancel/flush their pending/running work

Factor tty_ldisc_wait_idle() from tty_set_ldisc() and tty_ldisc_kill()
to ensure this shutdown order.

Failure to provide this guarantee can result in scheduled work
running after the tty has already been freed, as indicated in the
following log message:

[   88.331234] WARNING: at 
/home/peter/src/kernels/next/drivers/tty/tty_buffer.c:435 
flush_to_ldisc+0x194/0x1d0()
[   88.334505] Hardware name: Bochs
[   88.335618] tty is bad=-1
[   88.335703] Modules linked in: netconsole configfs bnep rfcomm bluetooth 
..
[   88.345272] Pid: 39, comm: kworker/1:1 Tainted: GW
3.7.0-next-20121129+ttydebug-xeon #20121129+ttydebug
[   88.347736] Call Trace:
[   88.349024]  [] warn_slowpath_common+0x7f/0xc0
[   88.350383]  [] warn_slowpath_fmt+0x46/0x50
[   88.351745]  [] flush_to_ldisc+0x194/0x1d0
[   88.353047]  [] ? _raw_spin_unlock_irq+0x21/0x50
[   88.354190]  [] ? finish_task_switch+0x49/0xe0
[   88.355436]  [] process_one_work+0x121/0x490
[   88.357674]  [] ? __tty_buffer_flush+0x90/0x90
[   88.358954]  [] worker_thread+0x164/0x3e0
[   88.360247]  [] ? manage_workers+0x120/0x120
[   88.361282]  [] kthread+0xc0/0xd0
[   88.362284]  [] ? cmos_do_probe+0x2eb/0x3bf
[   88.363391]  [] ? flush_kthread_worker+0xb0/0xb0
[   88.364797]  [] ret_from_fork+0x7c/0xb0
[   88.366087]  [] ? flush_kthread_worker+0xb0/0xb0
[   88.367266] ---[ end trace 453a7c9f38fbfec0 ]---

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 35 +--
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index c3dec37..9f4c7b0 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -528,24 +528,38 @@ static int tty_ldisc_wait_idle(struct tty_struct *tty, 
long timeout)
 /**
  * tty_ldisc_halt  -   shut down the line discipline
  * @tty: tty device
+ * @pending: returns true if work was scheduled when cancelled
+ *   (can be set to NULL)
+ * @timeout: # of jiffies to wait for ldisc refs to be released
  *
  * Shut down the line discipline and work queue for this tty device.
  * The TTY_LDISC flag being cleared ensures no further references can
  * be obtained while the delayed work queue halt ensures that no more
  * data is fed to the ldisc.
  *
+ * Furthermore, guarantee that existing ldisc references have been
+ * released, which in turn, guarantees that no future buffer work
+ * can be rescheduled.
+ *
  * You need to do a 'flush_scheduled_work()' (outside the ldisc_mutex)
  * in order to make sure any currently executing ldisc work is also
  * flushed.
  */
 
-static int tty_ldisc_halt(struct tty_struct *tty)
+static int tty_ldisc_halt(struct tty_struct *tty, int *pending, long timeout)
 {
-   int scheduled;
+   int scheduled, retval;
+
clear_bit(TTY_LDISC, >flags);
+   retval = tty_ldisc_wait_idle(tty, timeout);
+   if (retval)
+   return retval;
+
scheduled = cancel_work_sync(>port->buf.work);
set_bit(TTY_LDISC_HALTED, >flags);
-   return scheduled;
+   if (pending)
+   *pending = scheduled;
+   return 0;
 }
 
 /**
@@ -687,9 +701,9 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
 *  parallel to the change and re-referencing the tty.
 */
 
-   work = tty_ldisc_halt(tty);
+   retval = tty_ldisc_halt(tty, , 5 * HZ);
if (o_tty)
-   o_work = tty_ldisc_halt(o_tty);
+   tty_ldisc_halt(o_tty, _work, 0);
 
/*
 * Wait for ->hangup_work and ->buf.work handlers to terminate.
@@ -700,8 +714,6 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
 
tty_ldisc_flush_works(tty);
 
-   retval = tty_ldisc_wait_idle(tty, 5 * HZ);
-
tty_lock(tty);
mutex_lock(>ldisc_mutex);
 
@@ -920,11 +932,6 @@ int tty_ldisc_setup(struct tty_struct *tty, struct 
tty_struct *o_tty)
 
 static void tty_ldisc_kill(struct tty_struct *tty)
 {
-   /* There cannot be users from userspace now. But there still might be
-* drivers holding a reference via tty_ldisc_ref. Do not steal them the
-* ldisc until they are done. */
-   tty_ldisc_wait_idle(tty, MAX_SCHEDULE_TIMEOUT);
-
mutex_lock(>ldisc_mutex);
/*
 * Now kill off the ldisc
@@ -958,10 +965,10 @@ void tty_ldisc_release(struct tty_struct *tty, struct 
tty_struct *o_tty)
 */
 
tty_lock_pair(tty, o_tty);
-   tty_ldisc_halt(tty);
+   tty_ldisc_halt(tty, NULL, MAX_SCHEDULE_TIMEOUT);
tty_ldisc_flush_works(tty);
if (o_tty) {
-   

Re: [PATCH v4 7/7] mfd: max8925: add dts

2012-12-03 Thread Haojian Zhuang
On Thu, Nov 29, 2012 at 11:35 AM, Qing Xu  wrote:
> From: Qing Xu 
>
> add max8925 dts support into mmp2 brownstone platform
>
> Signed-off-by: Qing Xu 
> ---
>  arch/arm/boot/dts/mmp2-brownstone.dts |  158 
> +
>  arch/arm/boot/dts/mmp2.dtsi   |4 +-
>  2 files changed, 161 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts 
> b/arch/arm/boot/dts/mmp2-brownstone.dts
> index c9b4f27..f03d4f4 100644
> --- a/arch/arm/boot/dts/mmp2-brownstone.dts
> +++ b/arch/arm/boot/dts/mmp2-brownstone.dts
> @@ -29,6 +29,164 @@
> };
> twsi1: i2c@d4011000 {
> status = "okay";
> +   pmic: max8925@3c {
> +   compatible = "maxim,max8925";
> +   reg = <0x3c>;
> +   interrupts = <1>;
> +   interrupt-parent = <>;
> +   interrupt-controller;
> +   #interrupt-cells = <1>;
> +   tsc-irq = <0>;
> +
> +   regulators {
> +   SDV1 {
> +   
> regulator-min-microvolt = <637500>;
> +   
> regulator-max-microvolt = <1425000>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   SDV2 {
> +   
> regulator-min-microvolt = <65>;
> +   
> regulator-max-microvolt = <2225000>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   SDV3 {
> +   
> regulator-min-microvolt = <75>;
> +   
> regulator-max-microvolt = <390>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   LDO1 {
> +   
> regulator-min-microvolt = <75>;
> +   
> regulator-max-microvolt = <390>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   LDO2 {
> +   
> regulator-min-microvolt = <65>;
> +   
> regulator-max-microvolt = <225>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   LDO3 {
> +   
> regulator-min-microvolt = <65>;
> +   
> regulator-max-microvolt = <225>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   LDO4 {
> +   
> regulator-min-microvolt = <75>;
> +   
> regulator-max-microvolt = <390>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   LDO5 {
> +   
> regulator-min-microvolt = <75>;
> +   
> regulator-max-microvolt = <390>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +   

[PATCH -next 9/9] tty: Halt both ldiscs concurrently

2012-12-03 Thread Peter Hurley
The pty driver does not obtain an ldisc reference to the linked
tty when writing. When the ldiscs are sequentially halted, it
is possible for one ldisc to be halted, and before the second
ldisc can be halted, a concurrent write schedules buffer work on
the first ldisc. This can lead to an access-after-free error when
the scheduled buffer work starts on the closed ldisc.

Prevent subsequent use after halt by performing each stage
of the halt alternately the tty pair.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 40 ++--
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 19e088a..a6d3078 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -527,37 +527,53 @@ static int tty_ldisc_wait_idle(struct tty_struct *tty, 
long timeout)
 /**
  * tty_ldisc_halt  -   shut down the line discipline
  * @tty: tty device
+ * @o_tty: paired pty device (can be NULL)
  * @pending: returns true if work was scheduled when cancelled
  *   (can be set to NULL)
+ * @o_pending: returns true if work was scheduled when cancelled
+ * (can be set to NULL)
  * @timeout: # of jiffies to wait for ldisc refs to be released
  *
- * Shut down the line discipline and work queue for this tty device.
- * The TTY_LDISC flag being cleared ensures no further references can
- * be obtained while the delayed work queue halt ensures that no more
- * data is fed to the ldisc.
+ * Shut down the line discipline and work queue for this tty device and
+ * its paired pty (if exists). Clearing the TTY_LDISC flag ensures
+ * no further references can be obtained while the work queue halt
+ * ensures that no more data is fed to the ldisc.
  *
  * Furthermore, guarantee that existing ldisc references have been
  * released, which in turn, guarantees that no future buffer work
  * can be rescheduled.
  *
- * You need to do a 'flush_scheduled_work()' (outside the ldisc_mutex)
+ * You need to do a 'tty_ldisc_flush_works()' (outside the ldisc_mutex)
  * in order to make sure any currently executing ldisc work is also
  * flushed.
  */
 
-static int tty_ldisc_halt(struct tty_struct *tty, int *pending, long timeout)
+static int tty_ldisc_halt(struct tty_struct *tty, struct tty_struct *o_tty,
+ int *pending, int *o_pending, long timeout)
 {
-   int scheduled, retval;
+   int scheduled, o_scheduled, retval;
 
clear_bit(TTY_LDISC, >flags);
+   if (o_tty)
+   clear_bit(TTY_LDISC, _tty->flags);
+
retval = tty_ldisc_wait_idle(tty, timeout);
+   if (!retval && o_tty)
+   retval = tty_ldisc_wait_idle(o_tty, timeout);
if (retval)
return retval;
 
scheduled = cancel_work_sync(>port->buf.work);
set_bit(TTY_LDISC_HALTED, >flags);
+   if (o_tty) {
+   o_scheduled = cancel_work_sync(_tty->port->buf.work);
+   set_bit(TTY_LDISC_HALTED, _tty->flags);
+   }
+
if (pending)
*pending = scheduled;
+   if (o_tty && o_pending)
+   *o_pending = o_scheduled;
return 0;
 }
 
@@ -700,9 +716,7 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
 *  parallel to the change and re-referencing the tty.
 */
 
-   retval = tty_ldisc_halt(tty, , 5 * HZ);
-   if (o_tty)
-   tty_ldisc_halt(o_tty, _work, 0);
+   retval = tty_ldisc_halt(tty, o_tty, , _work, 5 * HZ);
 
/*
 * Wait for ->hangup_work and ->buf.work handlers to terminate.
@@ -964,12 +978,10 @@ void tty_ldisc_release(struct tty_struct *tty, struct 
tty_struct *o_tty)
 */
 
tty_lock_pair(tty, o_tty);
-   tty_ldisc_halt(tty, NULL, MAX_SCHEDULE_TIMEOUT);
+   tty_ldisc_halt(tty, o_tty, NULL, NULL, MAX_SCHEDULE_TIMEOUT);
tty_ldisc_flush_works(tty);
-   if (o_tty) {
-   tty_ldisc_halt(o_tty, NULL, MAX_SCHEDULE_TIMEOUT);
+   if (o_tty)
tty_ldisc_flush_works(o_tty);
-   }
 
/* This will need doing differently if we need to lock */
tty_ldisc_kill(tty);
-- 
1.8.0

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


[PATCH -next 6/9] tty: Fix ldisc halt sequence on hangup

2012-12-03 Thread Peter Hurley
Flip buffer work cannot be cancelled until all outstanding ldisc
references have been released. Convert the ldisc ref wait into
a full ldisc halt with buffer work cancellation.

Note that the legacy mutex is not held while cancelling.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 0d18d1e..c3dec37 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -549,22 +549,31 @@ static int tty_ldisc_halt(struct tty_struct *tty)
 }
 
 /**
- * tty_ldisc_hangup_wait_idle - wait for the ldisc to become idle
- * @tty: tty to wait for
- *
- * Wait for the line discipline to become idle. The discipline must
- * have been halted for this to guarantee it remains idle.
+ * tty_ldisc_hangup_halt - halt the line discipline for hangup
+ * @tty: tty being hung up
  *
+ * Shut down the line discipline and work queue for the tty device
+ * being hungup. Clear the TTY_LDISC flag to ensure no further
+ * references can be obtained, wait for remaining references to be
+ * released, and cancel pending buffer work to ensure no more
+ * data is fed to the ldisc.
  * Caller must hold legacy and ->ldisc_mutex.
  *
  * NB: tty_set_ldisc() is prevented from changing the ldisc concurrently
  * with this function when it checks the TTY_HUPPING state.
+ *
+ * NB: if tty->ldisc is NULL then buffer work does not need to be
+ * cancelled because it must already have done as a precondition
+ * of setting tty->ldisc to NULL
+ *
  */
-static bool tty_ldisc_hangup_wait_idle(struct tty_struct *tty)
+static bool tty_ldisc_hangup_halt(struct tty_struct *tty)
 {
char cur_n[TASK_COMM_LEN], tty_n[64];
long timeout = 3 * HZ;
 
+   clear_bit(TTY_LDISC, >flags);
+
if (tty->ldisc) {   /* Not yet closed */
tty_unlock(tty);
 
@@ -575,6 +584,10 @@ static bool tty_ldisc_hangup_wait_idle(struct tty_struct 
*tty)
__func__, get_task_comm(cur_n, current),
tty_name(tty, tty_n));
}
+
+   cancel_work_sync(>port->buf.work);
+   set_bit(TTY_LDISC_HALTED, >flags);
+
/* must reacquire both locks and preserve lock order */
mutex_unlock(>ldisc_mutex);
tty_lock(tty);
@@ -849,24 +862,11 @@ void tty_ldisc_hangup(struct tty_struct *tty)
 */
mutex_lock(>ldisc_mutex);
 
-   /*
-* this is like tty_ldisc_halt, but we need to give up
-* the BTM before calling cancel_work_sync, which may
-* need to wait for another function taking the BTM
-*/
-   clear_bit(TTY_LDISC, >flags);
-   tty_unlock(tty);
-   cancel_work_sync(>port->buf.work);
-   set_bit(TTY_LDISC_HALTED, >flags);
-   mutex_unlock(>ldisc_mutex);
-   tty_lock(tty);
-   mutex_lock(>ldisc_mutex);
-
/* At this point we have a closed ldisc and we want to
   reopen it. We could defer this to the next open but
   it means auditing a lot of other paths so this is
   a FIXME */
-   if (tty_ldisc_hangup_wait_idle(tty)) {
+   if (tty_ldisc_hangup_halt(tty)) {
if (reset == 0) {
 
if (!tty_ldisc_reinit(tty, tty->termios.c_line))
-- 
1.8.0

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


[PATCH -next 8/9] tty: Remove unnecessary buffer work flush

2012-12-03 Thread Peter Hurley
In order to safely call tty_ldisc_flush_works(), the ldisc must
already have been halted, so any pending buffer work has already
been cancelled or flushed as part of the halt.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 9f4c7b0..19e088a 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -506,7 +506,6 @@ static void tty_ldisc_flush_works(struct tty_struct *tty)
 {
flush_work(>hangup_work);
flush_work(>SAK_work);
-   flush_work(>port->buf.work);
 }
 
 /**
-- 
1.8.0

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


[PATCH -next 5/9] tty: Remove unnecessary re-test of ldisc ref count

2012-12-03 Thread Peter Hurley
Since the tty->ldisc is prevented from being changed by tty_set_ldisc()
when a tty is being hung up, re-testing the ldisc user count is
unnecessary -- ie, it cannot be a different ldisc and the user count
cannot have increased (assuming the caller meets the precondition that
TTY_LDISC flag is cleared)

Removal of the 'early-out' locking optimization is necessary for
the subsequent patch 'tty: Fix ldisc halt sequence on hangup'.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_ldisc.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 6c1d8aa..0d18d1e 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -556,29 +556,29 @@ static int tty_ldisc_halt(struct tty_struct *tty)
  * have been halted for this to guarantee it remains idle.
  *
  * Caller must hold legacy and ->ldisc_mutex.
+ *
+ * NB: tty_set_ldisc() is prevented from changing the ldisc concurrently
+ * with this function when it checks the TTY_HUPPING state.
  */
 static bool tty_ldisc_hangup_wait_idle(struct tty_struct *tty)
 {
-   while (tty->ldisc) {/* Not yet closed */
-   if (atomic_read(>ldisc->users) != 1) {
-   char cur_n[TASK_COMM_LEN], tty_n[64];
-   long timeout = 3 * HZ;
-   tty_unlock(tty);
-
-   while (tty_ldisc_wait_idle(tty, timeout) == -EBUSY) {
-   timeout = MAX_SCHEDULE_TIMEOUT;
-   printk_ratelimited(KERN_WARNING
-   "%s: waiting (%s) for %s took too long, 
but we keep waiting...\n",
-   __func__, get_task_comm(cur_n, current),
-   tty_name(tty, tty_n));
-   }
-   /* must reacquire both locks and preserve lock order */
-   mutex_unlock(>ldisc_mutex);
-   tty_lock(tty);
-   mutex_lock(>ldisc_mutex);
-   continue;
+   char cur_n[TASK_COMM_LEN], tty_n[64];
+   long timeout = 3 * HZ;
+
+   if (tty->ldisc) {   /* Not yet closed */
+   tty_unlock(tty);
+
+   while (tty_ldisc_wait_idle(tty, timeout) == -EBUSY) {
+   timeout = MAX_SCHEDULE_TIMEOUT;
+   printk_ratelimited(KERN_WARNING
+   "%s: waiting (%s) for %s took too long, but we 
keep waiting...\n",
+   __func__, get_task_comm(cur_n, current),
+   tty_name(tty, tty_n));
}
-   break;
+   /* must reacquire both locks and preserve lock order */
+   mutex_unlock(>ldisc_mutex);
+   tty_lock(tty);
+   mutex_lock(>ldisc_mutex);
}
return !!(tty->ldisc);
 }
-- 
1.8.0

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


[PATCH -next 3/9] tty: Don't reschedule buffer work while closing

2012-12-03 Thread Peter Hurley
Prevent buffer work scheduling when called from n_tty_close(). Since
the ldisc has been halted and the tty soon-to-be-destructed, pending
work would be accessing an invalid tty and ldisc state. Fixes this:

[   38.05] [ cut here ]
[   38.052113] WARNING: at /home/peter/src/kernels/next/drivers/tty/n_tty.c:160 
n_tty_set_room.part.6+0x8b/0xa0()
[   38.053916] Hardware name: Bochs
[   38.054819] Modules linked in: netconsole configfs bnep rfcomm bluetooth 
parport_pc ppdev snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse 
snd_timer serio_raw mac_hid snd_seq_device
snd microcode lp parport virtio_balloon soundcore i2c_piix4 snd_page_alloc 
floppy 8139too 8139cp
[   38.059704] Pid: 1564, comm: pty_kill Tainted: GW
3.7.0-next-20121130+ttydebug-xeon #20121130+ttydebug
[   38.061578] Call Trace:
[   38.062491]  [] warn_slowpath_common+0x7f/0xc0
[   38.063448]  [] warn_slowpath_null+0x1a/0x20
[   38.064439]  [] n_tty_set_room.part.6+0x8b/0xa0
[   38.065381]  [] n_tty_set_room+0x42/0x80
[   38.066323]  [] reset_buffer_flags+0x102/0x160
[   38.077508]  [] n_tty_flush_buffer+0x1d/0x90
[   38.078782]  [] ? default_spin_lock_flags+0x9/0x10
[   38.079734]  [] n_tty_close+0x24/0x60
[   38.080730]  [] tty_ldisc_close.isra.2+0x41/0x60
[   38.081680]  [] tty_ldisc_kill+0x3b/0x80
[   38.082618]  [] tty_ldisc_release+0x77/0xe0
[   38.083549]  [] tty_release+0x451/0x4d0
[   38.084525]  [] __fput+0xae/0x230
[   38.085472]  [] fput+0xe/0x10
[   38.086401]  [] task_work_run+0xc8/0xf0
[   38.087334]  [] do_exit+0x196/0x4b0
[   38.088304]  [] ? __dequeue_signal+0x6b/0xb0
[   38.089240]  [] do_group_exit+0x44/0xa0
[   38.090182]  [] get_signal_to_deliver+0x20d/0x4e0
[   38.091125]  [] do_signal+0x29/0x130
[   38.092096]  [] ? tty_ldisc_deref+0xe/0x10
[   38.093030]  [] ? tty_write+0xb7/0xf0
[   38.093976]  [] ? vfs_write+0xb3/0x180
[   38.094904]  [] do_notify_resume+0x80/0xc0
[   38.095830]  [] int_signal+0x12/0x17
[   38.096788] ---[ end trace 5f6f7a9651cd999b ]---

Signed-off-by: Peter Hurley 
---
 drivers/tty/n_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 3f704a9..574d099 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -149,7 +149,7 @@ static void n_tty_set_room(struct tty_struct *tty)
tty->receive_room = left;
 
/* Did this open up the receive buffer? We may need to flip */
-   if (left && !old_left) {
+   if (left && !old_left && !test_bit(TTY_CLOSING, >flags)) {
WARN_RATELIMIT(tty->port->itty == NULL,
"scheduling with invalid itty\n");
/* see if ldisc has been killed - if so, this means that
-- 
1.8.0

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


[PATCH -next 2/9] tty: Add diagnostic for halted line discipline

2012-12-03 Thread Peter Hurley
Flip buffer work must not be scheduled after the line discipline
has been halted; issue warning.

Signed-off-by: Peter Hurley 
---
 drivers/tty/n_tty.c  |  6 ++
 drivers/tty/tty_buffer.c |  3 +++
 drivers/tty/tty_ldisc.c  | 45 +
 include/linux/tty.h  |  1 +
 4 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 19083ef..3f704a9 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -152,6 +152,12 @@ static void n_tty_set_room(struct tty_struct *tty)
if (left && !old_left) {
WARN_RATELIMIT(tty->port->itty == NULL,
"scheduling with invalid itty\n");
+   /* see if ldisc has been killed - if so, this means that
+* even though the ldisc has been halted and ->buf.work
+* cancelled, ->buf.work is about to be rescheduled
+*/
+   WARN_RATELIMIT(test_bit(TTY_LDISC_HALTED, >flags),
+  "scheduling buffer work for halted ldisc\n");
schedule_work(>port->buf.work);
}
 }
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index cc9cbcf..d8d6f77 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -520,6 +520,9 @@ void tty_flip_buffer_push(struct tty_struct *tty)
struct tty_bufhead *buf = >port->buf;
unsigned long flags;
 
+   WARN_RATELIMIT(test_bit(TTY_LDISC_HALTED, >flags),
+  "scheduling buffer work for halted ldisc\n");
+
spin_lock_irqsave(>lock, flags);
if (buf->tail != NULL)
buf->tail->commit = buf->tail->used;
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index c578229..f986bb0 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -373,6 +373,7 @@ static inline void tty_ldisc_put(struct tty_ldisc *ld)
 
 void tty_ldisc_enable(struct tty_struct *tty)
 {
+   clear_bit(TTY_LDISC_HALTED, >flags);
set_bit(TTY_LDISC, >flags);
clear_bit(TTY_LDISC_CHANGING, >flags);
wake_up(_ldisc_wait);
@@ -496,26 +497,6 @@ static void tty_ldisc_restore(struct tty_struct *tty, 
struct tty_ldisc *old)
 }
 
 /**
- * tty_ldisc_halt  -   shut down the line discipline
- * @tty: tty device
- *
- * Shut down the line discipline and work queue for this tty device.
- * The TTY_LDISC flag being cleared ensures no further references can
- * be obtained while the delayed work queue halt ensures that no more
- * data is fed to the ldisc.
- *
- * You need to do a 'flush_scheduled_work()' (outside the ldisc_mutex)
- * in order to make sure any currently executing ldisc work is also
- * flushed.
- */
-
-static int tty_ldisc_halt(struct tty_struct *tty)
-{
-   clear_bit(TTY_LDISC, >flags);
-   return cancel_work_sync(>port->buf.work);
-}
-
-/**
  * tty_ldisc_flush_works   -   flush all works of a tty
  * @tty: tty device to flush works for
  *
@@ -545,6 +526,29 @@ static int tty_ldisc_wait_idle(struct tty_struct *tty, 
long timeout)
 }
 
 /**
+ * tty_ldisc_halt  -   shut down the line discipline
+ * @tty: tty device
+ *
+ * Shut down the line discipline and work queue for this tty device.
+ * The TTY_LDISC flag being cleared ensures no further references can
+ * be obtained while the delayed work queue halt ensures that no more
+ * data is fed to the ldisc.
+ *
+ * You need to do a 'flush_scheduled_work()' (outside the ldisc_mutex)
+ * in order to make sure any currently executing ldisc work is also
+ * flushed.
+ */
+
+static int tty_ldisc_halt(struct tty_struct *tty)
+{
+   int scheduled;
+   clear_bit(TTY_LDISC, >flags);
+   scheduled = cancel_work_sync(>port->buf.work);
+   set_bit(TTY_LDISC_HALTED, >flags);
+   return scheduled;
+}
+
+/**
  * tty_set_ldisc   -   set line discipline
  * @tty: the terminal to set
  * @ldisc: the line discipline
@@ -818,6 +822,7 @@ void tty_ldisc_hangup(struct tty_struct *tty)
clear_bit(TTY_LDISC, >flags);
tty_unlock(tty);
cancel_work_sync(>port->buf.work);
+   set_bit(TTY_LDISC_HALTED, >flags);
mutex_unlock(>ldisc_mutex);
 retry:
tty_lock(tty);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 8db1b56..e6b968d 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -314,6 +314,7 @@ struct tty_file_private {
 #define TTY_NO_WRITE_SPLIT 17  /* Preserve write boundaries to driver 
*/
 #define TTY_HUPPED 18  /* Post driver->hangup() */
 #define TTY_HUPPING21  /* ->hangup() in progress */
+#define TTY_LDISC_HALTED   22  /* Line discipline is halted */
 
 #define TTY_WRITE_FLUSH(tty) tty_write_flush((tty))
 
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 

[PATCH -next 1/9] tty: WARN if buffer work racing with tty free

2012-12-03 Thread Peter Hurley

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

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 78c3000..3d2b6d7 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1511,6 +1511,8 @@ static void queue_release_one_tty(struct kref *kref)
 {
struct tty_struct *tty = container_of(kref, struct tty_struct, kref);
 
+   WARN_ON(work_pending(>port->buf.work));
+
/* The hangup queue is now free so we can reuse it rather than
   waste a chunk of memory for each port */
INIT_WORK(>hangup_work, release_one_tty);
-- 
1.8.0

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


Re: [PATCH 3/4] rtc: pxa: add pxa95x rtc support

2012-12-03 Thread Haojian Zhuang
On Thu, Nov 29, 2012 at 10:21 AM, Chao Xie  wrote:
> the pxa95x rtc need access PBSR register before write to
> RTTR, RCNR, RDCR, and RYCR registers.
>
> Signed-off-by: Chao Xie 
> ---
>  drivers/rtc/rtc-pxa.c |   97 
> +++--
>  1 files changed, 85 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c
> index 22ea4f5..29646af 100644
> --- a/drivers/rtc/rtc-pxa.c
> +++ b/drivers/rtc/rtc-pxa.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -81,14 +82,28 @@
>  #define RTCPICR0x34
>  #define PIAR   0x38
>
> +#define PSBR_RTC   0x00
> +
>  #define rtc_readl(pxa_rtc, reg)\
> __raw_readl((pxa_rtc)->base + (reg))
>  #define rtc_writel(pxa_rtc, reg, value)\
> __raw_writel((value), (pxa_rtc)->base + (reg))
> +#define rtc_readl_psbr(pxa_rtc, reg)   \
> +   __raw_readl((pxa_rtc)->base_psbr + (reg))
> +#define rtc_writel_psbr(pxa_rtc, reg, value)   \
> +   __raw_writel((value), (pxa_rtc)->base_psbr + (reg))
> +
> +enum {
> +   RTC_PXA27X,
> +   RTC_PXA95X,
> +};
>
>  struct pxa_rtc {
> struct resource *ress;
> +   struct resource *ress_psbr;
> +   unsigned intid;
> void __iomem*base;
> +   void __iomem*base_psbr;
> int irq_1Hz;
> int irq_Alrm;
> struct rtc_device   *rtc;
> @@ -250,9 +265,26 @@ static int pxa_rtc_set_time(struct device *dev, struct 
> rtc_time *tm)
>  {
> struct pxa_rtc *pxa_rtc = dev_get_drvdata(dev);
>
> +   /*
> +* sequence to wirte pxa rtc register RCNR RDCR RYCR is
> +* 1. set PSBR[RWE] bit, take 2x32-khz to complete
> +* 2. write to RTC register,take 2x32-khz to complete
> +* 3. clear PSBR[RWE] bit,take 2x32-khz to complete
> +*/
> +   if (pxa_rtc->id == RTC_PXA95X) {
> +   rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x01);
> +   udelay(100);
> +   }
> +
> rtc_writel(pxa_rtc, RYCR, ryxr_calc(tm));
> rtc_writel(pxa_rtc, RDCR, rdxr_calc(tm));
>
> +   if (pxa_rtc->id == RTC_PXA95X) {
> +   udelay(100);
> +   rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x00);
> +   udelay(100);
> +   }
> +
> return 0;
>  }
>
> @@ -318,6 +350,20 @@ static const struct rtc_class_ops pxa_rtc_ops = {
> .proc = pxa_rtc_proc,
>  };
>
> +static struct of_device_id pxa_rtc_dt_ids[] = {
> +   { .compatible = "marvell,pxa-rtc", .data = (void *)RTC_PXA27X },
> +   { .compatible = "marvell,pxa95x-rtc", .data = (void *)RTC_PXA95X },
> +   {}
> +};
> +MODULE_DEVICE_TABLE(of, pxa_rtc_dt_ids);
> +
> +static const struct platform_device_id pxa_rtc_id_table[] = {
> +   { "pxa-rtc", RTC_PXA27X },
> +   { "pxa95x-rtc", RTC_PXA95X },
> +{ },
> +};
> +MODULE_DEVICE_TABLE(platform, pxa_rtc_id_table);
> +
>  static int __init pxa_rtc_probe(struct platform_device *pdev)
>  {
> struct device *dev = >dev;
> @@ -332,13 +378,34 @@ static int __init pxa_rtc_probe(struct platform_device 
> *pdev)
> spin_lock_init(_rtc->lock);
> platform_set_drvdata(pdev, pxa_rtc);
>
> +   if (pdev->dev.of_node) {
> +   const struct of_device_id *of_id =
> +   of_match_device(pxa_rtc_dt_ids, >dev);
> +
> +   pxa_rtc->id = (unsigned int)(of_id->data);
> +   } else {
> +   const struct platform_device_id *id =
> +   platform_get_device_id(pdev);
> +
> +   pxa_rtc->id = id->driver_data;
> +   }
> +
> ret = -ENXIO;
> pxa_rtc->ress = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!pxa_rtc->ress) {
> -   dev_err(dev, "No I/O memory resource defined\n");
> +   dev_err(dev, "No I/O memory resource(id=0) defined\n");
> goto err_ress;
> }
>
> +   if (pxa_rtc->id == RTC_PXA95X) {
> +   pxa_rtc->ress_psbr =
> +   platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +   if (!pxa_rtc->ress_psbr) {
> +   dev_err(dev, "No I/O memory resource(id=1) 
> defined\n");
> +   goto err_ress;
> +   }
> +   }
> +
> pxa_rtc->irq_1Hz = platform_get_irq(pdev, 0);
> if (pxa_rtc->irq_1Hz < 0) {
> dev_err(dev, "No 1Hz IRQ resource defined\n");
> @@ -355,7 +422,17 @@ static int __init pxa_rtc_probe(struct platform_device 
> *pdev)
> resource_size(pxa_rtc->ress));
> if (!pxa_rtc->base) {
> dev_err(>dev, "Unable to map pxa RTC I/O memory\n");
> -   goto err_map;
> +   goto err_map_base;
> +   }
> +
> +   if (pxa_rtc->id == RTC_PXA95X) {
> +   

Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

2012-12-03 Thread Haojian Zhuang
On Tuesday, December 4, 2012, Chao Xie wrote:
>
> On Mon, Dec 3, 2012 at 5:48 PM, Russell King - ARM Linux
>  wrote:
> > On Mon, Dec 03, 2012 at 10:53:07AM +0800, Chao Xie wrote:
> >> I want to correct what i said. For the irq register/unregister i think
> >> can be done at open/release. But for clock enable/disable, i do not
> >> think so. If clock is disabled, as i think RTC will not work. User API
> >> still use open->get_time->close for "date" command. It means that RTC
> >> will not return correct date to user.
> >
> > "I think" is not good enough for patches like this.  Please test it.
> >
> > On SA11x0 and PXA platforms, the clock for the sa1100-rtc is a dummy
> > clock; it has no effect.  For MMP, I don't have access to the TRMs so
> > that's something you're going to have to find out.
>
> I tested at pxa910 which uses rtc-sa1100 as driver.
> the test procedure is simple
> open->ioctl(RTC_RD_TIME)->close
> With the original code, the rtc will not update, i always get the same value
>
> remove clock disable/enable in release/open, and enable/disable clock
> at probe/remove.
> the rtc can update, and i can read the correct rtc value.

Yes, clock shouldn't be controlled in open/close. Otherwise, RTC can't
work since
clock is already gated. I didn't find the issue since there're two RTC
enabled in my
board. The default one impacts the test.

I think that you need send the patch that only move clock operation
into probe().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [linux-keystone] [PATCH v2] drivers: cma: fix addressing on PAE machines

2012-12-03 Thread Santosh Shilimkar

On Monday 03 December 2012 09:16 PM, Vitaly Andrianov wrote:

This patch fixes a couple of bugs that otherwise impair CMA functionality on
PAE machines:

   - alignment must be a 64-bit type when running on systems with 64-bit
 physical addresses.  If this is not the case, the limit calculation thunks
 allocations down to an address range < 4G.

   - The allocated range check is removed. On 32bit ARM kernel with LPAE
 enabled the base may be allocated outside the fist 4GB of physical
 memory (keystone SoC for example).


Any reason you have clubbed two fixes in one patch. Its better to keep
the two fixes separate patches.


Signed-off-by: Vitaly Andrianov 
Signed-off-by: Cyril Chemparathy 
---

Other than that, patch looks good to my eyes.

Regards,
Santosh


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


RE: [PATCH] da8xx: Fix revision check on the da8xx driver

2012-12-03 Thread Manjunathappa, Prakash
Hi Tomi,

On Wed, Oct 31, 2012 at 09:21:35, Manjunathappa, Prakash wrote:
> On Wed, Oct 31, 2012 at 21:26:24, Pantelis Antoniou wrote:
> > The revision check fails for the beaglebone; Add new revision ID.
> > 
> > Signed-off-by: Pantelis Antoniou 
> > ---
> >  drivers/video/da8xx-fb.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> > index 80665f6..866d804 100644
> > --- a/drivers/video/da8xx-fb.c
> > +++ b/drivers/video/da8xx-fb.c
> > @@ -1283,6 +1283,7 @@ static int __devinit fb_probe(struct platform_device 
> > *device)
> > lcd_revision = LCD_VERSION_1;
> > break;
> > case 0x4F200800:
> > +   case 0x4F201000:
> 
> Thanks for Correcting. This is the LCDC revision on am335x silicon in 
> comparison
> with to one read(0x4F200800) on emulator platform.
> 
> Acked-by: Manjunathappa, Prakash 
> 

This patch is necessary for am335x FB, I could not see in your for-next branch,
could you please consider this patch for 3.8 merge window. There are no pending
review comments on this.

Thanks,
Prakash

> > lcd_revision = LCD_VERSION_2;
> > break;
> > default:
> > -- 
> > 1.7.12
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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


[PATCH RFT] spi: spi-xcomm: Fix wrong setting for SPI_XCOMM_SETTINGS_CPHA

2012-12-03 Thread Axel Lin
The logic of setting SPI_XCOMM_SETTINGS_CPHA bit is reversed.

Signed-off-by: Axel Lin 
---
Hi Lars,
The logic of setting SPI_XCOMM_SETTINGS_CPHA bit looks wrong to me.
Can you check if this patch works?

Thanks,
Axel

 drivers/spi/spi-xcomm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-xcomm.c b/drivers/spi/spi-xcomm.c
index 266a847..c2a3e8f 100644
--- a/drivers/spi/spi-xcomm.c
+++ b/drivers/spi/spi-xcomm.c
@@ -99,9 +99,9 @@ static int spi_xcomm_setup_transfer(struct spi_xcomm 
*spi_xcomm,
*settings &= ~SPI_XCOMM_SETTINGS_CPOL;
 
if (spi->mode & SPI_CPHA)
-   *settings &= ~SPI_XCOMM_SETTINGS_CPHA;
-   else
*settings |= SPI_XCOMM_SETTINGS_CPHA;
+   else
+   *settings &= ~SPI_XCOMM_SETTINGS_CPHA;
 
if (spi->mode & SPI_3WIRE)
*settings |= SPI_XCOMM_SETTINGS_3WIRE;
-- 
1.7.9.5



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


Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if fat_dget() fails

2012-12-03 Thread Namjae Jeon
2012/12/3, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> From: Namjae Jeon 
>>
>> This patch enables rebuilding of directory inodes which are not present
>> in the cache.This is done by traversing the disk clusters to find the
>> directory entry of the parent directory and using its i_pos to build the
>> inode.
>> Do this only if the "nostale_ro" nfs mount option is specified.
>
> This became much better than before. However, we have to consolidate the
> code with fat_search_long() finally.
>
> E.g. this version is having the issue already fixed. If there is
> corruption in fat cluster-chain, it lead to infinite
> loop. fat_get_cluster() checks infinite loop by limit.
since, the focus this time was for NFS functionality for FAT (removing
ESTALE error). The changes were made in that context.

Later, we can make the changes as part of code reorganizing which can
be controlled via. Separate patches which do not have any impact on
default functionality and verification can be carried out in that
scope.



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


Re: [PATCH v5 8/8] Documentation: update nfs option in filesystem/vfat.txt

2012-12-03 Thread Namjae Jeon
2012/12/3, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> From: Namjae Jeon 
>>
>> update nfs option in filesystem/vfat.txt
>>
>> Signed-off-by: Namjae Jeon 
>> Signed-off-by: Ravishankar N 
>> Signed-off-by: Amit Sahrawat 
>> ---
>>  Documentation/filesystems/vfat.txt |   23 ++-
>>  1 file changed, 18 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/filesystems/vfat.txt
>> b/Documentation/filesystems/vfat.txt
>> index d230dd9..f663c70 100644
>> --- a/Documentation/filesystems/vfat.txt
>> +++ b/Documentation/filesystems/vfat.txt
>> @@ -150,13 +150,26 @@ discard   -- If set, issues discard/TRIM
>> commands to the block
>>   device when blocks are freed. This is useful for SSD devices
>>   and sparse/thinly-provisoned LUNs.
>>
>> -nfs   -- This option maintains an index (cache) of directory
>> - inodes by i_logstart which is used by the nfs-related code to
>> - improve look-ups.
>> -
>> - Enable this only if you want to export the FAT filesystem
>> +nfs= stale_rw|nostale_ro
>> +  -- Enable this only if you want to export the FAT filesystem
>>   over NFS
>>
>> + stale_rw:This option maintains an index (cache) of directory
>> + inodes by i_logstart which is used by the nfs-related code to
>> + improve look-ups.Full file operations (read/write) over NFS is
>> supported
>> + but with cache eviction at NFS server, this could result in 
>> ESTALE
>> issues.
>> +
>> + nostale_ro:This option bases the inode number and filehandle 
>> on the
>> on-disk
>> + location of a file in the MS-DOS directory entry.This ensures 
>> that
>> ESTALE
>> + will not be returned after a file is evicted from the inode 
>> cache.
>> However,
>> + it means that operations such as rename, create and unlink 
>> could
>> cause
>> + filehandles that previously pointed at one file to point at a
>> different file,
>> + potentially causing data corruption. For this reason, this 
>> option also
>> mounts
>> + the filesystem readonly.
>> +
>> + To maintain backward compatibility, '-o nfs' is also accepted,
>> defaulting to
>> + stale_rw
>
> Please add whitespace after ":" and ".". And please care 80 columns.
Okay, I will fix it.
Thanks.
> --
> OGAWA Hirofumi 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 5/8] fat: restructure export_operations

2012-12-03 Thread Namjae Jeon
2012/12/3, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> +if (MSDOS_SB(inode->i_sb)->options.nfs == FAT_NFS_NOSTALE_RO) {
>> +/* Use i_pos for ino. This is used as fileid of nfs. */
>> +stat->ino = fat_i_pos_read(MSDOS_SB(inode->i_sb), inode);
>
> BTW, what number is used for root dir? If it is 0 (0 is special ino in
> glibc), we have to use MSDOS_ROOT_INO instead.
we have used default root ino number which is MSDOS_ROOT_INO.
>
>> +#define FAT_FID_SIZE_WITHOUT_PARENT (offsetof(struct fat_fid, \
>> +  parent_i_pos_hi)/4)
>
> (offset parent_i_pos_hi) / 4 == 2. Wrong.
 Yes, this needs correction. Since, at all the places the condition
was for ‘fh_len < 2’ so this error condition was never caught.
>
>> +#define FAT_FID_SIZE_WITH_PARENT (sizeof(struct fat_fid)/4)
>
> 4 should be sizeof(u32). Or simplely use immediate value.
Okay.
>
>> +static int
>> +fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp,
>> +  struct inode *parent)
>> +{
>> +int len = *lenp;
>> +struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
>> +struct fat_fid *fid = (struct fat_fid *) fh;
>> +loff_t i_pos;
>> +int type = FILEID_FAT_WITHOUT_PARENT;
>> +
>> +if (parent && (len < FAT_FID_SIZE_WITH_PARENT)) {
>> +*lenp = FAT_FID_SIZE_WITH_PARENT;
>> +return 255;
>
> 255 is now FILEID_INVALID, I think.
Yes, right.
>
>> +} else if (len < FAT_FID_SIZE_WITHOUT_PARENT) {
>> +*lenp = FAT_FID_SIZE_WITHOUT_PARENT;
>> +return 255;
>> +}
>> +
>> +i_pos = fat_i_pos_read(sbi, inode);
>> +*lenp = FAT_FID_SIZE_WITHOUT_PARENT;
>> +fid->i_gen = inode->i_generation;
>> +fid->i_pos_low = i_pos & 0x;
>> +fid->i_pos_hi = (i_pos >> 32) & 0x;
>> +if (parent) {
>> +i_pos = fat_i_pos_read(sbi, parent);
>> +fid->parent_i_pos_hi = (i_pos >> 32) & 0x;
>> +fid->parent_i_pos_low = i_pos & 0x;
>> +fid->parent_i_gen = parent->i_generation;
>> +type = FILEID_FAT_WITH_PARENT;
>> +*lenp = FAT_FID_SIZE_WITH_PARENT;
>> +}
>> +
>> +return type;
>> +}
>> +
>>  /**
>>   * Map a NFS file handle to a corresponding dentry.
>>   * The dentry may or may not be connected to the filesystem root.
>>   */
>> -struct dentry *fat_fh_to_dentry(struct super_block *sb, struct fid *fid,
>> +static struct dentry *fat_fh_to_dentry(struct super_block *sb, struct fid
>> *fid,
>>  int fh_len, int fh_type)
>>  {
>>  return generic_fh_to_dentry(sb, fid, fh_len, fh_type,
>>  fat_nfs_get_inode);
>>  }
>>
>> +static struct dentry *fat_fh_to_dentry_nostale(struct super_block *sb,
>> +   struct fid *fh, int fh_len,
>> +   int fh_type)
>> +{
>> +struct inode *inode = NULL;
>> +struct fat_fid *fid = (struct fat_fid *)fh;
>> +loff_t i_pos;
>> +
>> +switch (fh_type) {
>> +case FILEID_FAT_WITHOUT_PARENT:
>> +if (fh_len < FAT_FID_SIZE_WITHOUT_PARENT)
>> +return NULL;
>> +case FILEID_FAT_WITH_PARENT:
>> +if ((fh_len < FAT_FID_SIZE_WITH_PARENT) &&
>> +(fh_type == FILEID_FAT_WITH_PARENT))
>> +return NULL;
>
> Do we have to care (FILEID_FAT_WITH_PARENT and fh_len < 5) here?
>
>   if (fh_len < 2)
>   return NULL;
>
>   switch (fh_type) {
>   case FILEID_INO32_GEN:
>   case FILEID_INO32_GEN_PARENT:
>   inode = get_inode(sb, fid->i32.ino, fid->i32.gen);
>   break;
>   }
>
>   return d_obtain_alias(inode);
>
> generic_fh_to_dentry() is above. I wonder why we have to care
> fat_fid->parent* here.
Let me think, if ‘subtree’ checking is enabled then we should check
the length condition over here also? Please share if there are any
other comments also.

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


Why a host not ping-able?

2012-12-03 Thread Woody Wu
Hi, list

I am not sure this has something with kernel.  But the system I just
generated cannot be reached from ping.  It can ping outside, but if I
ping it from outside, I just get "Destination Host Unreachable".

I think there is not firewall in between, and the two host in the test
are in the same ethernet sub network.  Is that possible the strange
behavior caused by somehow misconfigured kernel?

-- 
woody
I can't go back to yesterday - because I was a different person then.

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


Re: [RFC v2 1/8] video: tegra: Add nvhost driver

2012-12-03 Thread Terje Bergström
On 03.12.2012 23:03, Thierry Reding wrote:
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single host1x in a system. I know this will
> never happen, but all of a sudden it happens anyway and the code breaks.
> Doing this right isn't very hard and it will lead to a better design and
> is less likely to break at some point.

I agree that the chip ops access goes through too much indirection and
macro magic (which I already declared I hate), so we're going to design
something simpler.

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


linux-next: build failure after merge of the final tree (ext4 tree related)

2012-12-03 Thread Stephen Rothwell
Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

fs/ocfs2/built-in.o: In function `.walk_page_buffers':
(.text+0x2c104): multiple definition of `.walk_page_buffers'
fs/ext4/built-in.o:(.text+0x10c1c): first defined here
fs/ocfs2/built-in.o: In function `walk_page_buffers':
(.opd+0x1020): multiple definition of `walk_page_buffers'
fs/ext4/built-in.o:(.opd+0xa68): first defined here

Caused by commit c99dcc3889f5 ("ext4: add normal write support for inline
data") from the ext4 tree.  Who would have thought that a generic name
like that would clash? ;-(

Grep is your friend ...

I have added this patch for today (ocfs2 might like to apply something
similar):

From: Stephen Rothwell 
Date: Tue, 4 Dec 2012 17:06:30 +1100
Subject: [PATCH] ext4: use a less generic version of the name walk_page_buffers

Signed-off-by: Stephen Rothwell 
---
 fs/ext4/ext4.h   |2 +-
 fs/ext4/inline.c |2 +-
 fs/ext4/inode.c  |   20 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 9e30958..b1a169a 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2057,7 +2057,7 @@ int ext4_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create);
 int ext4_da_get_block_prep(struct inode *inode, sector_t iblock,
   struct buffer_head *bh, int create);
-int walk_page_buffers(handle_t *handle,
+int ext4_walk_page_buffers(handle_t *handle,
 struct buffer_head *head,
 unsigned from,
 unsigned to,
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 811457e..1fe0cc4 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -583,7 +583,7 @@ retry:
ret = __block_write_begin(page, from, to, ext4_get_block);
 
if (!ret && ext4_should_journal_data(inode)) {
-   ret = walk_page_buffers(handle, page_buffers(page),
+   ret = ext4_walk_page_buffers(handle, page_buffers(page),
from, to, NULL, do_journal_get_write_access);
}
 
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index f92bd69..1a190e0 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -770,7 +770,7 @@ struct buffer_head *ext4_bread(handle_t *handle, struct 
inode *inode,
return NULL;
 }
 
-int walk_page_buffers(handle_t *handle,
+int ext4_walk_page_buffers(handle_t *handle,
 struct buffer_head *head,
 unsigned from,
 unsigned to,
@@ -911,7 +911,7 @@ retry:
ret = __block_write_begin(page, pos, len, ext4_get_block);
 
if (!ret && ext4_should_journal_data(inode)) {
-   ret = walk_page_buffers(handle, page_buffers(page),
+   ret = ext4_walk_page_buffers(handle, page_buffers(page),
from, to, NULL, do_journal_get_write_access);
}
 
@@ -1133,7 +1133,7 @@ static int ext4_journalled_write_end(struct file *file,
page_zero_new_buffers(page, from+copied, to);
}
 
-   ret = walk_page_buffers(handle, page_buffers(page), from,
+   ret = ext4_walk_page_buffers(handle, page_buffers(page), from,
to, , write_end_fn);
if (!partial)
SetPageUptodate(page);
@@ -1942,7 +1942,7 @@ static int __ext4_journalled_writepage(struct page *page,
} else {
page_bufs = page_buffers(page);
BUG_ON(!page_bufs);
-   walk_page_buffers(handle, page_bufs, 0, len, NULL, bget_one);
+   ext4_walk_page_buffers(handle, page_bufs, 0, len, NULL, 
bget_one);
}
/* As soon as we unlock the page, it can go away, but we have
 * references to buffers so we are safe */
@@ -1962,10 +1962,10 @@ static int __ext4_journalled_writepage(struct page 
*page,
err = ext4_handle_dirty_metadata(handle, inode, inode_bh);
 
} else {
-   ret = walk_page_buffers(handle, page_bufs, 0, len, NULL,
+   ret = ext4_walk_page_buffers(handle, page_bufs, 0, len, NULL,
do_journal_get_write_access);
 
-   err = walk_page_buffers(handle, page_bufs, 0, len, NULL,
+   err = ext4_walk_page_buffers(handle, page_bufs, 0, len, NULL,
write_end_fn);
}
 
@@ -1977,7 +1977,7 @@ static int __ext4_journalled_writepage(struct page *page,
ret = err;
 
if (!ext4_has_inline_data(inode))
-   walk_page_buffers(handle, page_bufs, 0, len, NULL, bput_one);
+   ext4_walk_page_buffers(handle, page_bufs, 0, len, NULL, 
bput_one);
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
 out:

Re: [RFC PATCH v3] Add rcu user eqs exception hooks for async page fault

2012-12-03 Thread Li Zhong
On Tue, 2012-12-04 at 07:11 +0200, Gleb Natapov wrote:
> On Tue, Dec 04, 2012 at 10:36:02AM +0800, Li Zhong wrote:
> > On Mon, 2012-12-03 at 11:57 +0200, Gleb Natapov wrote:
> > > Please regenerate the patch against
> > > git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue.
> > 
> > Done.
> > 
> > By the way, the included file  is replaced with
> >  in latest next tree(91d1aa43 from rcu tree). 
> > 
> What is the url of the rcu tree?

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git

and the url of the commit:

git.kernel.org/?p=linux/kernel/git/paulmck/linux-rcu.git;a=commit;h=91d1aa43d30505b0b825db8898ffc80a8eca96c7

Thanks, Zhong

> 
> > Seems if they are merged, there won't be conflicts, but we need change
> > the including file name after that. I don't know how to handle this kind
> > of thing... 
> > 
> > Thanks, Zhong
> > 
> > > 
> > > On Fri, Nov 30, 2012 at 05:18:41PM +0800, Li Zhong wrote:
> > > > This patch adds user eqs exception hooks for async page fault page not
> > > > present code path, to exit the user eqs and re-enter it as necessary. 
> > > > 
> > > > Async page fault is different from other exceptions that it may be
> > > > triggered from idle process, so we still need rcu_irq_enter() and
> > > > rcu_irq_exit() to exit cpu idle eqs when needed, to protect the code
> > > > that needs use rcu.
> > > > 
> > > > As Frederic pointed out it would be safest and simplest to protect the
> > > > whole kvm_async_pf_task_wait(). Otherwise, "we need to check all the
> > > > code there deeply for potential RCU uses and ensure it will never be
> > > > extended later to use RCU.".
> > > > 
> > > > However, We'd better re-enter the cpu idle eqs if we get the exception
> > > > in cpu idle eqs, by calling rcu_irq_exit() before native_safe_halt(). 
> > > > 
> > > > So the patch does what Frederic suggested for rcu_irq_*() API usage
> > > > here, except that I moved the rcu_irq_*() pair originally in
> > > > do_async_page_fault() into kvm_async_pf_task_wait(). 
> > > > 
> > > > That's because, I think it's better to have rcu_irq_*() pairs to be in
> > > > one function ( rcu_irq_exit() after rcu_irq_enter() ), especially here,
> > > > kvm_async_pf_task_wait() has other callers, which might cause
> > > > rcu_irq_exit() be called without a matching rcu_irq_enter() before it,
> > > > which is illegal if the cpu happens to be in rcu idle state. 
> > > > 
> > > > Signed-off-by: Li Zhong 
> > > > ---
> > > >  arch/x86/kernel/kvm.c | 12 ++--
> > > >  1 file changed, 10 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > > > index 4180a87..342b00b 100644
> > > > --- a/arch/x86/kernel/kvm.c
> > > > +++ b/arch/x86/kernel/kvm.c
> > > > @@ -42,6 +42,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  
> > > >  static int kvmapf = 1;
> > > >  
> > > > @@ -112,6 +113,8 @@ void kvm_async_pf_task_wait(u32 token)
> > > > DEFINE_WAIT(wait);
> > > > int cpu, idle;
> > > >  
> > > > +   rcu_irq_enter();
> > > > +
> > > > cpu = get_cpu();
> > > > idle = idle_cpu(cpu);
> > > > put_cpu();
> > > > @@ -123,6 +126,8 @@ void kvm_async_pf_task_wait(u32 token)
> > > > hlist_del(>link);
> > > > kfree(e);
> > > > spin_unlock(>lock);
> > > > +
> > > > +   rcu_irq_exit();
> > > > return;
> > > > }
> > > >  
> > > > @@ -147,13 +152,16 @@ void kvm_async_pf_task_wait(u32 token)
> > > > /*
> > > >  * We cannot reschedule. So halt.
> > > >  */
> > > > +   rcu_irq_exit();
> > > > native_safe_halt();
> > > > +   rcu_irq_enter();
> > > > local_irq_disable();
> > > > }
> > > > }
> > > > if (!n.halted)
> > > > finish_wait(, );
> > > >  
> > > > +   rcu_irq_exit();
> > > > return;
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(kvm_async_pf_task_wait);
> > > > @@ -247,10 +255,10 @@ do_async_page_fault(struct pt_regs *regs, 
> > > > unsigned long error_code)
> > > > break;
> > > > case KVM_PV_REASON_PAGE_NOT_PRESENT:
> > > > /* page is swapped out by the host. */
> > > > -   rcu_irq_enter();
> > > > +   exception_enter(regs);
> > > > exit_idle();
> > > > kvm_async_pf_task_wait((u32)read_cr2());
> > > > -   rcu_irq_exit();
> > > > +   exception_exit(regs);
> > > > break;
> > > > case KVM_PV_REASON_PAGE_READY:
> > > > rcu_irq_enter();
> > > > -- 
> > > > 1.7.11.4
> > > 
> > > --
> > >   Gleb.
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to 

linux-next: manual merge of the akpm tree with the rr-fixes tree

2012-12-03 Thread Stephen Rothwell
Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
include/linux/kernel.h between commit cbdbf2abb784 ("linux/kernel.h:
define SYMBOL_PREFIX") from the rr-fixes tree and commit "mm: use
IS_ENABLED(CONFIG_COMPACTION) instead of COMPACTION_BUILD" from the akpm
tree.

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

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

diff --cc include/linux/kernel.h
index 69ddcb3,1e98564..000
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@@ -684,20 -684,6 +684,13 @@@ static inline void ftrace_dump(enum ftr
  /* Trap pasters of __FUNCTION__ at compile-time */
  #define __FUNCTION__ (__func__)
  
- /* This helps us avoid #ifdef CONFIG_COMPACTION */
- #ifdef CONFIG_COMPACTION
- #define COMPACTION_BUILD 1
- #else
- #define COMPACTION_BUILD 0
- #endif
- 
 +/* This helps us to avoid #ifdef CONFIG_SYMBOL_PREFIX */
 +#ifdef CONFIG_SYMBOL_PREFIX
 +#define SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
 +#else
 +#define SYMBOL_PREFIX ""
 +#endif
 +
  /* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */
  #ifdef CONFIG_FTRACE_MCOUNT_RECORD
  # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD


pgporSe8vSXNt.pgp
Description: PGP signature


[PATCH v3] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON

2012-12-03 Thread Jingoo Han
From: Marko Katic 

Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
triggers WARN_ON message:

WARNING: at drivers/gpio/gpiolib.c:1672 __gpio_set_value+0x38/0xa4()
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
 r6:c0158fc8 r5:0009 r4: r3:c03d4f70
[] (dump_stack+0x0/0x1c) from [] 
(warn_slowpath_common+0x54/0x6c)
[] (warn_slowpath_common+0x0/0x6c) from [] 
(warn_slowpath_null+0x24/0x2c)
 r8:c38d5c00 r7:c03f82c0 r6: r5:00d0 r4:c384e4fc
r3:0009
[] (warn_slowpath_null+0x0/0x2c) from [] 
(__gpio_set_value+0x38/0xa4)
[] (__gpio_set_value+0x0/0xa4) from [] 
(corgi_bl_set_intensity+0x44/0x74)
 r7:c3933418 r6:c3933400 r5:c392cdf0 r4:002f
[] (corgi_bl_set_intensity+0x0/0x74) from [] 
(corgi_bl_update_status+0x5c/0x64)
 r5:c03d31f0 r4:c3933400
[] (corgi_bl_update_status+0x0/0x64) from [] 
(corgi_lcd_probe+0x1a8/0x258)
 r4:c392cdf0 r3:c0169bc0
[] (corgi_lcd_probe+0x0/0x258) from [] 
(spi_drv_probe+0x20/0x24)
 r8:0052 r7:c0192d9c r6:c03da6e8 r5:c38d5c34 r4:c38d5c00
[] (spi_drv_probe+0x0/0x24) from [] 
(driver_probe_device+0xb0/0x208)
[] (driver_probe_device+0x0/0x208) from [] 
(__driver_attach+0x70/0x94)
 r6:c03da6e8 r5:c38d5c34 r4:c38d5c00 r3:
[] (__driver_attach+0x0/0x94) from [] 
(bus_for_each_dev+0x54/0x90)
 r6:c03da6e8 r5:c3827e80 r4: r3:
[] (bus_for_each_dev+0x0/0x90) from [] 
(driver_attach+0x20/0x28)
 r7: r6:c03e29ec r5:c3932980 r4:c03da6e8
[] (driver_attach+0x0/0x28) from [] 
(bus_add_driver+0xd4/0x22c)
[] (bus_add_driver+0x0/0x22c) from [] 
(driver_register+0xa4/0x134)
 r8:0052 r7:c03ea900 r6:c03c32ac r5:c03bdfc8 r4:c03da6e8
[] (driver_register+0x0/0x134) from [] 
(spi_register_driver+0x4c/0x60)
[] (spi_register_driver+0x0/0x60) from [] 
(corgi_lcd_driver_init+0x14/0x1c)
[] (corgi_lcd_driver_init+0x0/0x1c) from [] 
(do_one_initcall+0x9c/0x174)
[] (do_one_initcall+0x0/0x174) from [] 
(kernel_init+0xf4/0x2a8)
[] (kernel_init+0x0/0x2a8) from [] (ret_from_fork+0x14/0x24)
---[ end trace a863a63f242ee38c ]---

Akita machines have backlight controls hooked to a gpio expander chip,
max7310. In this case, pca953x_gpio_set_value() can be called to control
gpio, and pca953x_setup_gpio() sets can_sleep flag. Therefore,
gpio_set_value_cansleep() should be used in order to avoid WARN_ON on
akita machines.

Akita is the only exception in this case since other users of corgi_lcd
access backlight gpio controls through a different gpio expander such as
max7310 which does not set the can_sleep flag.

[jg1@samsung.com: used gpio_cansleep()]
Signed-off-by: Marko Katic 
Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/corgi_lcd.c |   17 +
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/corgi_lcd.c 
b/drivers/video/backlight/corgi_lcd.c
index e2e1b62..e5168f4 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -408,11 +408,20 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd, 
int intensity)
/* Bit 5 via GPIO_BACKLIGHT_CONT */
cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
 
-   if (gpio_is_valid(lcd->gpio_backlight_cont))
-   gpio_set_value(lcd->gpio_backlight_cont, cont);
+   if (gpio_is_valid(lcd->gpio_backlight_cont)) {
+   if (gpio_cansleep(lcd->gpio_backlight_cont))
+   gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont);
+   else
+   gpio_set_value(lcd->gpio_backlight_cont, cont);
+   }
 
-   if (gpio_is_valid(lcd->gpio_backlight_on))
-   gpio_set_value(lcd->gpio_backlight_on, intensity);
+   if (gpio_is_valid(lcd->gpio_backlight_on)) {
+   if (gpio_cansleep(lcd->gpio_backlight_on))
+   gpio_set_value_cansleep(lcd->gpio_backlight_on,
+   intensity);
+   else
+   gpio_set_value(lcd->gpio_backlight_on, intensity);
+   }
 
if (lcd->kick_battery)
lcd->kick_battery();
-- 
1.7.2.5


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


Re: [PATCH 1/2] Input: xpad - Minor coding style errors fixed.

2012-12-03 Thread Dmitry Torokhov
On Sat, Dec 01, 2012 at 11:36:19PM -0800, Guillermo A. Amaral wrote:
> From: "Guillermo A. Amaral" 
> 
> Fixed a few minor coding style issues in xpad driver.

Applied both, thanks Guillermo.

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


[PATCH -next] powerpc/82xx: use for_each_compatible_node() macro

2012-12-03 Thread Wei Yongjun
From: Wei Yongjun 

Use for_each_compatible_node() macro instead of open coding it.

Signed-off-by: Wei Yongjun 
---
 arch/powerpc/platforms/82xx/pq2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/82xx/pq2.c 
b/arch/powerpc/platforms/82xx/pq2.c
index fb94d10..fc8b2d6 100644
--- a/arch/powerpc/platforms/82xx/pq2.c
+++ b/arch/powerpc/platforms/82xx/pq2.c
@@ -71,11 +71,11 @@ err:
 
 void __init pq2_init_pci(void)
 {
-   struct device_node *np = NULL;
+   struct device_node *np;
 
ppc_md.pci_exclude_device = pq2_pci_exclude_device;
 
-   while ((np = of_find_compatible_node(np, NULL, "fsl,pq2-pci")))
+   for_each_compatible_node(np, NULL, "fsl,pq2-pci")
pq2_pci_add_bridge(np);
 }
 #endif


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


[PATCH -next] TTY: hvsi: use for_each_compatible_node() macro

2012-12-03 Thread Wei Yongjun
From: Wei Yongjun 

Use for_each_compatible_node() macro instead of open coding it.

Signed-off-by: Wei Yongjun 
---
 drivers/tty/hvc/hvsi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 5b95b4f..70e0ef7 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1187,9 +1187,7 @@ static int __init hvsi_console_init(void)
hvsi_wait = poll_for_state; /* no irqs yet; must poll */
 
/* search device tree for vty nodes */
-   for (vty = of_find_compatible_node(NULL, "serial", "hvterm-protocol");
-   vty != NULL;
-   vty = of_find_compatible_node(vty, "serial", 
"hvterm-protocol")) {
+   for_each_compatible_node(vty, "serial", "hvterm-protocol") {
struct hvsi_struct *hp;
const uint32_t *vtermno, *irq;
 


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


[PATCH -next] Drivers: hv: remove unused variable in vmbus_recvpacket_raw()

2012-12-03 Thread Wei Yongjun
From: Wei Yongjun 

The variable userlen is initialized but never used
otherwise, so remove the unused variable.

Signed-off-by: Wei Yongjun 
---
 drivers/hv/channel.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 773a2f2..3148d80 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -774,7 +774,6 @@ int vmbus_recvpacket_raw(struct vmbus_channel *channel, 
void *buffer,
 {
struct vmpacket_descriptor desc;
u32 packetlen;
-   u32 userlen;
int ret;
 
*buffer_actual_len = 0;
@@ -788,7 +787,6 @@ int vmbus_recvpacket_raw(struct vmbus_channel *channel, 
void *buffer,
 
 
packetlen = desc.len8 << 3;
-   userlen = packetlen - (desc.offset8 << 3);
 
*buffer_actual_len = packetlen;
 

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


Re: [PATCH 2/2] i2c-s3c2410: Add bus arbitration implementation

2012-12-03 Thread Naveen Krishna Ch
On 4 December 2012 05:41, Olof Johansson  wrote:
> On Sat, Dec 1, 2012 at 5:26 AM, Mark Brown
>  wrote:
>> On Thu, Nov 29, 2012 at 10:14:58PM -0800, Olof Johansson wrote:
>>> On Thu, Nov 29, 2012 at 6:13 PM, Simon Glass  wrote:
>>
>>> > It was originally done separately but I think it was felt that this
>>> > was overly complex. Olof can you please comment on this?
>>
>>> it is indeed not controller specific per se, but we are unaware of any
>>> other platform/driver using it. So, it seemed reasonable to implement
>>> it in the driver as long as we have only one user; if another one
>>> comes along it's of course better to move it to the common i2c code.
>>
>>> At least that was my opinion at the time. I could be convinced
>>> otherwise if someone else has strong opinions on the matter.
>>
>> This sort of approach is half the reason SPI ended up being so fun...  I
>> suspect if you look hard enough you'll find that this is just the first
>> time someone tried to upstream such a scheme.  This is all especially
>> true for the DT bindings, even if the implementation is driver local for
>> now it'd be better to define generic bindings.
>
> Ok, sounds like we might as well make it generic then. Naveen?
Thanks for the comments.

Sure, Will send an RFC soon.
>
>
> -Olof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



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


Re: [RFC PATCH v3] Add rcu user eqs exception hooks for async page fault

2012-12-03 Thread Gleb Natapov
On Tue, Dec 04, 2012 at 10:36:02AM +0800, Li Zhong wrote:
> On Mon, 2012-12-03 at 11:57 +0200, Gleb Natapov wrote:
> > Please regenerate the patch against
> > git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue.
> 
> Done.
> 
> By the way, the included file  is replaced with
>  in latest next tree(91d1aa43 from rcu tree). 
> 
What is the url of the rcu tree?

> Seems if they are merged, there won't be conflicts, but we need change
> the including file name after that. I don't know how to handle this kind
> of thing... 
> 
> Thanks, Zhong
> 
> > 
> > On Fri, Nov 30, 2012 at 05:18:41PM +0800, Li Zhong wrote:
> > > This patch adds user eqs exception hooks for async page fault page not
> > > present code path, to exit the user eqs and re-enter it as necessary. 
> > > 
> > > Async page fault is different from other exceptions that it may be
> > > triggered from idle process, so we still need rcu_irq_enter() and
> > > rcu_irq_exit() to exit cpu idle eqs when needed, to protect the code
> > > that needs use rcu.
> > > 
> > > As Frederic pointed out it would be safest and simplest to protect the
> > > whole kvm_async_pf_task_wait(). Otherwise, "we need to check all the
> > > code there deeply for potential RCU uses and ensure it will never be
> > > extended later to use RCU.".
> > > 
> > > However, We'd better re-enter the cpu idle eqs if we get the exception
> > > in cpu idle eqs, by calling rcu_irq_exit() before native_safe_halt(). 
> > > 
> > > So the patch does what Frederic suggested for rcu_irq_*() API usage
> > > here, except that I moved the rcu_irq_*() pair originally in
> > > do_async_page_fault() into kvm_async_pf_task_wait(). 
> > > 
> > > That's because, I think it's better to have rcu_irq_*() pairs to be in
> > > one function ( rcu_irq_exit() after rcu_irq_enter() ), especially here,
> > > kvm_async_pf_task_wait() has other callers, which might cause
> > > rcu_irq_exit() be called without a matching rcu_irq_enter() before it,
> > > which is illegal if the cpu happens to be in rcu idle state. 
> > > 
> > > Signed-off-by: Li Zhong 
> > > ---
> > >  arch/x86/kernel/kvm.c | 12 ++--
> > >  1 file changed, 10 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > > index 4180a87..342b00b 100644
> > > --- a/arch/x86/kernel/kvm.c
> > > +++ b/arch/x86/kernel/kvm.c
> > > @@ -42,6 +42,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  static int kvmapf = 1;
> > >  
> > > @@ -112,6 +113,8 @@ void kvm_async_pf_task_wait(u32 token)
> > >   DEFINE_WAIT(wait);
> > >   int cpu, idle;
> > >  
> > > + rcu_irq_enter();
> > > +
> > >   cpu = get_cpu();
> > >   idle = idle_cpu(cpu);
> > >   put_cpu();
> > > @@ -123,6 +126,8 @@ void kvm_async_pf_task_wait(u32 token)
> > >   hlist_del(>link);
> > >   kfree(e);
> > >   spin_unlock(>lock);
> > > +
> > > + rcu_irq_exit();
> > >   return;
> > >   }
> > >  
> > > @@ -147,13 +152,16 @@ void kvm_async_pf_task_wait(u32 token)
> > >   /*
> > >* We cannot reschedule. So halt.
> > >*/
> > > + rcu_irq_exit();
> > >   native_safe_halt();
> > > + rcu_irq_enter();
> > >   local_irq_disable();
> > >   }
> > >   }
> > >   if (!n.halted)
> > >   finish_wait(, );
> > >  
> > > + rcu_irq_exit();
> > >   return;
> > >  }
> > >  EXPORT_SYMBOL_GPL(kvm_async_pf_task_wait);
> > > @@ -247,10 +255,10 @@ do_async_page_fault(struct pt_regs *regs, unsigned 
> > > long error_code)
> > >   break;
> > >   case KVM_PV_REASON_PAGE_NOT_PRESENT:
> > >   /* page is swapped out by the host. */
> > > - rcu_irq_enter();
> > > + exception_enter(regs);
> > >   exit_idle();
> > >   kvm_async_pf_task_wait((u32)read_cr2());
> > > - rcu_irq_exit();
> > > + exception_exit(regs);
> > >   break;
> > >   case KVM_PV_REASON_PAGE_READY:
> > >   rcu_irq_enter();
> > > -- 
> > > 1.7.11.4
> > 
> > --
> > Gleb.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 

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


[PATCH -next] mn10300: use for_each_pci_dev to simplify the code

2012-12-03 Thread Wei Yongjun
From: Wei Yongjun 

Use for_each_pci_dev to simplify the code.

Signed-off-by: Wei Yongjun 
---
 arch/mn10300/unit-asb2305/pci-irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mn10300/unit-asb2305/pci-irq.c 
b/arch/mn10300/unit-asb2305/pci-irq.c
index 91212ea..77439da 100644
--- a/arch/mn10300/unit-asb2305/pci-irq.c
+++ b/arch/mn10300/unit-asb2305/pci-irq.c
@@ -29,7 +29,7 @@ void __init pcibios_fixup_irqs(void)
struct pci_dev *dev = NULL;
u8 line, pin;
 
-   while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+   for_each_pci_dev(dev) {
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
if (pin) {
dev->irq = XIRQ1;


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


Re: [GIT PULL] linux-firmware: cx23885: update to Version 2.06.139

2012-12-03 Thread Ben Hutchings
On Mon, 2012-12-03 at 11:13 -0700, Tim Gardner wrote:
> Ben - what is your policy on extracting firmware from Windows drivers?

I suppose the policy should be that the driver's licence must allow
extracting and then distributing the result.  Which I wouldn't expect
ever to be the case, in practice.

Your commit message refers to the Hauppuage driver package at
.  
I didn't find any licence text, other than 'All rights reserved', in either 
that or the currently distributed version of the same driver 
.

> It seems like it ought to be OK, and they _are_ the same files that are
> covered under the license in WHENCE.

I'm not sure how you can say they are the same files, as you're
proposing to change the contents.  The copyright on the current files
belongs to the chipset vendor, Conexant, and Hauppuage *presumably* used
firmware supplied by Conexant, but either of them might have chosen a
different licence for the versions in this driver package.

> The following changes since commit bda53ca96deb3cacbef10a7a84bbaee2d09c7f34:
> 
>   brcm: new firmware version for brcmsmac (2012-12-03 14:46:28 +)
> 
> are available in the git repository at:
> 
>   git://kernel.ubuntu.com/rtg/linux-firmware.git master
> 
> for you to fetch changes up to 3c592f80519a7e82eadeccfad7a5cd1604ca463c:
> 
>   cx23885: update to Version 2.06.139 (2012-12-03 11:07:43 -0700)
> 
> 
> Tim Gardner (1):
>   cx23885: update to Version 2.06.139
> 
>  v4l-cx23885-avcore-01.fw |  Bin 16382 -> 16382 bytes
>  v4l-cx23885-enc.fw   |  Bin 16382 -> 376836 bytes
>  2 files changed, 0 insertions(+), 0 deletions(-)

How odd, these two files are currently identical to each other...

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part


Re: [RFC v2 PATCH 2.1] sched: Use Per-Entity-Load-Tracking metric for load balancing

2012-12-03 Thread Preeti U Murthy

sched: Use Per-Entity-Load-Tracking metric for load balancing

From: Preeti U Murthy 

Currently the load balancer weighs a task based upon its priority,and this
weight consequently gets added up to the weight of the run queue that it is
on.It is this weight of the runqueue that sums up to a sched group's load
which is used to decide the busiest or the idlest group and the runqueue
thereof.

The Per-Entity-Load-Tracking metric however measures how long a task has
been runnable over the duration of its lifetime.This gives us a hint of
the amount of CPU time that the task can demand.This metric takes care of the
task priority as well.Therefore apart from the priority of a task we also
have an idea of the live behavior of the task.This seems to be a more
realistic metric to use to compute task weight which adds upto the run queue
weight and the weight of the sched group.Consequently they can be used for
load balancing.

The semantics of load balancing is left untouched.The two functions
load_balance() and select_task_rq_fair() perform the task of load
balancing.These two paths have been browsed through in this patch to make
necessary changes.

weighted_cpuload() and task_h_load() provide the run queue weight and the
weight of the task respectively.They have been modified to provide the
Per-Entity-Load-Tracking metric as relevant for each.
The rest of the modifications had to be made to suit these two changes.

Completely Fair Scheduler class is the only sched_class which contributes to
the run queue load.Therefore the rq->load.weight==cfs_rq->load.weight when
the cfs_rq is the root cfs_rq (rq->cfs) of the hierarchy.When replacing this
with Per-Entity-Load-Tracking metric,cfs_rq->runnable_load_avg needs to be
used as this is the right reflection of the run queue load when
the cfs_rq is the root cfs_rq (rq->cfs) of the hierarchy.This metric reflects
the percentage uptime of the tasks that are queued on it and hence that 
contribute
to the load.Thus cfs_rq->runnable_load_avg replaces the metric earlier used in
weighted_cpuload().

The task load is aptly captured by se.avg.load_avg_contrib which captures the
runnable time vs the alive time of the task against its priority.This metric
replaces the earlier metric used in task_h_load().

The consequent changes appear as data type changes for the helper variables;
they abound in number.Because cfs_rq->runnable_load_avg needs to be big enough
to capture the tasks' load often and accurately.

The following patch does not consider CONFIG_FAIR_GROUP_SCHED AND
CONFIG_SCHED_NUMA.This is done so as to evaluate this approach starting from the
simplest scenario.Earlier discussions can be found in the link below.

Link: https://lkml.org/lkml/2012/10/25/162
Signed-off-by: Preeti U Murthy 
---
I apologise about having overlooked this one change in the patchset.This needs 
to
be applied on top of patch2 of this patchset.The experiment results that have 
been
posted in reply to this thread are done after having applied this patch.

 kernel/sched/fair.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f8f3a29..19094eb 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4362,7 +4362,7 @@ struct sd_lb_stats {
  * sg_lb_stats - stats of a sched_group required for load_balancing
  */
 struct sg_lb_stats {
-   unsigned long avg_load; /*Avg load across the CPUs of the group */
+   u64 avg_load; /*Avg load across the CPUs of the group */
u64 group_load; /* Total load over the CPUs of the group */
unsigned long sum_nr_running; /* Nr tasks running in the group */
u64 sum_weighted_load; /* Weighted load of group's tasks */

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


[PATCH 3/3] perf diff: Use internal rb tree for compute resort

2012-12-03 Thread Namhyung Kim
From: Namhyung Kim 

There's no reason to run hists_compute_resort() using output tree.
Convert it to use internal tree so that it can remove unnecessary
_output_resort.  Also move position computation below the resort since
it changes the output ordering.

Cc: Jiri Olsa 
Cc: Stephane Eranian 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-diff.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index b52f5d8c4a6b..4e18cea7c845 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -435,19 +435,25 @@ static void insert_hist_entry_by_compute(struct rb_root 
*root,
 
 static void hists__compute_resort(struct hists *hists)
 {
-   struct rb_root tmp = RB_ROOT;
-   struct rb_node *next = rb_first(>entries);
+   struct rb_root *root;
+   struct rb_node *next;
+
+   if (sort__need_collapse)
+   root = >entries_collapsed;
+   else
+   root = hists->entries_in;
+
+   hists->entries = RB_ROOT;
+   next = rb_first(root);
 
while (next != NULL) {
-   struct hist_entry *he = rb_entry(next, struct hist_entry, 
rb_node);
+   struct hist_entry *he;
 
-   next = rb_next(>rb_node);
+   he = rb_entry(next, struct hist_entry, rb_node_in);
+   next = rb_next(>rb_node_in);
 
-   rb_erase(>rb_node, >entries);
-   insert_hist_entry_by_compute(, he, compute);
+   insert_hist_entry_by_compute(>entries, he, compute);
}
-
-   hists->entries = tmp;
 }
 
 static void hists__process(struct hists *old, struct hists *new)
@@ -459,16 +465,16 @@ static void hists__process(struct hists *old, struct 
hists *new)
else
hists__link(new, old);
 
-   hists__output_resort(new);
-
-   if (show_displacement)
-   hists__compute_position(new);
-
if (sort_compute) {
hists__precompute(new);
hists__compute_resort(new);
+   } else {
+   hists__output_resort(new);
}
 
+   if (show_displacement)
+   hists__compute_position(new);
+
hists__fprintf(new, true, 0, 0, stdout);
 }
 
-- 
1.7.11.7

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


[PATCH 2/3] perf hists: Link hist entries before inserting to an output tree

2012-12-03 Thread Namhyung Kim
From: Namhyung Kim 

For matching and/or linking hist entries, they need to be sorted by
given sort keys.  However current hists__match/link did this on the
output trees, so that the entries in the output tree need to be resort
before doing it.

This looks not so good since we have trees for collecting or
collapsing entries before passing them to an output tree and they're
already sorted by the given sort keys.  Since we don't need to print
anything at the time of matching/linking, we can use these internal
trees directly instead of bothering with double resort on the output
tree.

Its only user - at the time of this writing - perf diff can be easily
converted to use the internal tree and can save some lines too by
getting rid of unnecessary resorting codes.

It seems we need to do output resort on baseline hists for
displacement prior to the match/link.  But AFAIK it's okay since the
resort doesn't make any change to the internal tree - i.e. every
entries in the internal tree remain as is and just linked to both of
internal and output tree using different keys.  So linking entries in
the internal tree after output resorting will not cause any harm IMHO.

Cc: Jiri Olsa 
Cc: Stephane Eranian 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-diff.c | 73 ++-
 tools/perf/util/hist.c| 49 +++
 2 files changed, 65 insertions(+), 57 deletions(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index d869029fb75e..b52f5d8c4a6b 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -276,46 +276,19 @@ static struct perf_tool tool = {
.ordering_requires_timestamps = true,
 };
 
-static void insert_hist_entry_by_name(struct rb_root *root,
- struct hist_entry *he)
-{
-   struct rb_node **p = >rb_node;
-   struct rb_node *parent = NULL;
-   struct hist_entry *iter;
-
-   while (*p != NULL) {
-   parent = *p;
-   iter = rb_entry(parent, struct hist_entry, rb_node);
-   if (hist_entry__cmp(he, iter) < 0)
-   p = &(*p)->rb_left;
-   else
-   p = &(*p)->rb_right;
-   }
-
-   rb_link_node(>rb_node, parent, p);
-   rb_insert_color(>rb_node, root);
-}
-
-static void hists__name_resort(struct hists *self, bool sort)
+static void hists__compute_position(struct hists *hists)
 {
unsigned long position = 1;
-   struct rb_root tmp = RB_ROOT;
-   struct rb_node *next = rb_first(>entries);
+   struct rb_node *next = rb_first(>entries);
 
while (next != NULL) {
-   struct hist_entry *n = rb_entry(next, struct hist_entry, 
rb_node);
+   struct hist_entry *he;
 
-   next = rb_next(>rb_node);
-   n->position = position++;
+   he = rb_entry(next, struct hist_entry, rb_node);
+   he->position = position++;
 
-   if (sort) {
-   rb_erase(>rb_node, >entries);
-   insert_hist_entry_by_name(, n);
-   }
+   next = rb_next(next);
}
-
-   if (sort)
-   self->entries = tmp;
 }
 
 static struct perf_evsel *evsel_match(struct perf_evsel *evsel,
@@ -330,34 +303,39 @@ static struct perf_evsel *evsel_match(struct perf_evsel 
*evsel,
return NULL;
 }
 
-static void perf_evlist__resort_hists(struct perf_evlist *evlist, bool name)
+static void perf_evlist__resort_hists(struct perf_evlist *evlist, bool base)
 {
struct perf_evsel *evsel;
 
list_for_each_entry(evsel, >entries, node) {
struct hists *hists = >hists;
 
-   hists__output_resort(hists);
+   hists__collapse_resort(hists);
 
-   /*
-* The hists__name_resort only sets possition
-* if name is false.
-*/
-   if (name || ((!name) && show_displacement))
-   hists__name_resort(hists, name);
+   if (base && show_displacement) {
+   hists__output_resort(hists);
+   hists__compute_position(hists);
+   }
}
 }
 
 static void hists__baseline_only(struct hists *hists)
 {
-   struct rb_node *next = rb_first(>entries);
+   struct rb_root *root;
+   struct rb_node *next;
+
+   if (sort__need_collapse)
+   root = >entries_collapsed;
+   else
+   root = hists->entries_in;
 
+   next = rb_first(root);
while (next != NULL) {
-   struct hist_entry *he = rb_entry(next, struct hist_entry, 
rb_node);
+   struct hist_entry *he = rb_entry(next, struct hist_entry, 
rb_node_in);
 
-   next = rb_next(>rb_node);
+   next = rb_next(>rb_node_in);
if (!hist_entry__next_pair(he)) {
-   rb_erase(>rb_node, 

[PATCH 0/3] perf hists: Changes on hists__{link,match}

2012-12-03 Thread Namhyung Kim
Hi Arnaldo,

This is what I talked to Jiri yesterday, and it can be a common basis
of both event group and multiple diff patchset.  The point is using
internal input or collapsed rb tree to sort hist entries rather than
output tree with unnessary resort.

Please take a look.

Thanks,
Namhyung


Cc: Jiri Olsa 
Cc: Stephane Eranian 
Cc: Namhyung Kim 

Namhyung Kim (3):
  perf hists: Exchange order of comparing items when collapsing hists
  perf hists: Link hist entries before inserting to an output tree
  perf diff: Use internal rb tree for compute resort

 tools/perf/builtin-diff.c | 95 +--
 tools/perf/util/hist.c| 51 ++---
 2 files changed, 80 insertions(+), 66 deletions(-)

-- 
1.7.11.7

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


[PATCH 1/3] perf hists: Exchange order of comparing items when collapsing hists

2012-12-03 Thread Namhyung Kim
From: Namhyung Kim 

When comparing entries for collapsing put the given entry first, and
then the iterated entry.  This is not the case of hist_entry__cmp()
when called if given sort keys don't require collapsing.  So change
the order for the sake of consistency.  It will be required for
matching and/or linking multiple hist entries.

Cc: Jiri Olsa 
Cc: Stephane Eranian 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/hist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 82df1b26f0d4..161c35e7ed0e 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -433,7 +433,7 @@ static bool hists__collapse_insert_entry(struct hists 
*hists __maybe_unused,
parent = *p;
iter = rb_entry(parent, struct hist_entry, rb_node_in);
 
-   cmp = hist_entry__collapse(iter, he);
+   cmp = hist_entry__collapse(he, iter);
 
if (!cmp) {
he_stat__add_stat(>stat, >stat);
-- 
1.7.11.7

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


linux-next: manual merge of the arm-soc tree with the iommu tree

2012-12-03 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/clock44xx_data.c between commit 298ea44f211d ("ARM:
OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf
clocks") from the iommu tree and commit 13a5b6228679 ("ARM: OMAP44xx:
clock: drop obsolete clock data") from the arm-soc tree.

I just deleted the file as the latter did and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpswzgRHC7iw.pgp
Description: PGP signature


Re: [net-next rfc v7 1/3] virtio-net: separate fields of sending/receiving queue from virtnet_info

2012-12-03 Thread Rusty Russell
Jason Wang  writes:
> On Monday, December 03, 2012 12:25:42 PM Rusty Russell wrote:
>> > +
>> > +  /* Work struct for refilling if we run low on memory. */
>> > +  struct delayed_work refill;
>> 
>> I can't really see the justificaiton for a refill per queue.  Just have
>> one work iterate all the queues if it happens, unless it happens often
>> (in which case, we need to look harder at this anyway).
>
> But during this kind of iteration, we may need enable/disable the napi 
> regardless of whether the receive queue has lots to be refilled. This may add 
> extra latency. 

Sure, but does it actually happen?  We only use the work when we run out
of memory.  If this happens in normal behaviour we need to change
something else...

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


Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)

2012-12-03 Thread Greg KH
On Sun, Dec 02, 2012 at 07:26:27PM +0200, Eli Billauer wrote:
> On 11/30/2012 06:32 PM, Greg KH wrote:
> >  >>+static struct class *xillybus_class;
>   >Why not just use the misc interface instead of your own class?
> >>>  When Xillybus is used, the whole system's mission is usually around
> >>>  it (e.g. it's a computer doing data acquisition through the Xillybus
> >>>  pipes). So giving it a high profile makes sense, I believe. Besides,
> >>>  a dozen of device files are not rare.
> >It is no problem to create dozens of misc devices.  It makes your driver
> >smaller, contain less code that I have to audit and you have to ensure
> >you got right, and it removes another user of 'struct class' which we
> >are trying to get rid of anyway.  So please, move to use a misc device.
> >
> 
> It has just occurred to me that DYNAMIC_MINORS is 64
> (drivers/char/misc.c), so I guess that limits the number of misc
> devices that can be generated, at least with dynamically allocated
> minors. I previously mentioned "a dozen" as the number of devices,
> but I've already run tests with 100+ devices, and I can also think
> of a sane application for that.
> 
> 
> So if I understood the situation correctly, it looks like using misc
> devices will create a limitation which will be reached sooner or
> later.
> 
> Any suggestion what to do?

Given that I don't really understand how you can have that many device
nodes, because I don't know what they all seem to be needed for, I can't
answer this question.

Again, any hints on the user/kernel api you use/need here?  Does it
really have to be device nodes?  What's wrong with the simple firmware
interface the kernel provides?

thanks,

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


RE: [PATCH 01/11] watchdog/at91sam9_wdt: remove the file_operations struct

2012-12-03 Thread Yang, Wenyou
Hi JC,

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
> Sent: 2012年11月16日 21:54
> To: Yang, Wenyou
> Cc: linux-arm-ker...@lists.infradead.org; w...@iguana.be;
> linux-watch...@vger.kernel.org; linux-kernel@vger.kernel.org; Ferre, Nicolas; 
> Lin,
> JM
> Subject: Re: [PATCH 01/11] watchdog/at91sam9_wdt: remove the file_operations
> struct
> 
> On 15:15 Wed 14 Nov , Wenyou Yang wrote:
> > Remove the file_operations struct and miscdevice struct for future
> > add to use the watchdog framework.
> NACK
> 
> you break the watchdog support
> 
> you must not break the kernel suport except if it's impossible to do otherwise
> here it is no the case

Thanks.

But it is said so in the kernel document 
(Documentation/watchdog/convert_drivers_to_kernel_api.txt).
"the old drivers define their own file_operations for actions like open(), 
write()etc... These are now handled by the framework"

And the codes in these function is not used under the new framework which is 
implemented in the framework.
So I only make it in the separated patch to simpler.
> 
> Best Regards,
> J.

Best Regards
Wenyou Yang

> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >  drivers/watchdog/at91sam9_wdt.c |  131 
> > ---
> >  1 file changed, 131 deletions(-)
> >
> > diff --git a/drivers/watchdog/at91sam9_wdt.c 
> > b/drivers/watchdog/at91sam9_wdt.c
> > index 05e1be8..549c256 100644
> > --- a/drivers/watchdog/at91sam9_wdt.c
> > +++ b/drivers/watchdog/at91sam9_wdt.c
> > @@ -18,11 +18,9 @@
> >  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -31,7 +29,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >
> >  #include "at91sam9_wdt.h"
> >
> > @@ -102,35 +99,6 @@ static void at91_ping(unsigned long data)
> >  }
> >
> >  /*
> > - * Watchdog device is opened, and watchdog starts running.
> > - */
> > -static int at91_wdt_open(struct inode *inode, struct file *file)
> > -{
> > -   if (test_and_set_bit(0, _private.open))
> > -   return -EBUSY;
> > -
> > -   at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
> > -   mod_timer(_private.timer, jiffies + WDT_TIMEOUT);
> > -
> > -   return nonseekable_open(inode, file);
> > -}
> > -
> > -/*
> > - * Close the watchdog device.
> > - */
> > -static int at91_wdt_close(struct inode *inode, struct file *file)
> > -{
> > -   clear_bit(0, _private.open);
> > -
> > -   /* stop internal ping */
> > -   if (!at91wdt_private.expect_close)
> > -   del_timer(_private.timer);
> > -
> > -   at91wdt_private.expect_close = 0;
> > -   return 0;
> > -}
> > -
> > -/*
> >   * Set the watchdog time interval in 1/256Hz (write-once)
> >   * Counter is 12 bit.
> >   */
> > @@ -168,101 +136,11 @@ static const struct watchdog_info at91_wdt_info = {
> > WDIOF_MAGICCLOSE,
> >  };
> >
> > -/*
> > - * Handle commands from user-space.
> > - */
> > -static long at91_wdt_ioctl(struct file *file,
> > -   unsigned int cmd, unsigned long arg)
> > -{
> > -   void __user *argp = (void __user *)arg;
> > -   int __user *p = argp;
> > -   int new_value;
> > -
> > -   switch (cmd) {
> > -   case WDIOC_GETSUPPORT:
> > -   return copy_to_user(argp, _wdt_info,
> > -   sizeof(at91_wdt_info)) ? -EFAULT : 0;
> > -
> > -   case WDIOC_GETSTATUS:
> > -   case WDIOC_GETBOOTSTATUS:
> > -   return put_user(0, p);
> > -
> > -   case WDIOC_KEEPALIVE:
> > -   at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
> > -   return 0;
> > -
> > -   case WDIOC_SETTIMEOUT:
> > -   if (get_user(new_value, p))
> > -   return -EFAULT;
> > -
> > -   heartbeat = new_value;
> > -   at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
> > -
> > -   return put_user(new_value, p);  /* return current value */
> > -
> > -   case WDIOC_GETTIMEOUT:
> > -   return put_user(heartbeat, p);
> > -   }
> > -   return -ENOTTY;
> > -}
> > -
> > -/*
> > - * Pat the watchdog whenever device is written to.
> > - */
> > -static ssize_t at91_wdt_write(struct file *file, const char *data, size_t 
> > len,
> > -   loff_t *ppos)
> > -{
> > -   if (!len)
> > -   return 0;
> > -
> > -   /* Scan for magic character */
> > -   if (!nowayout) {
> > -   size_t i;
> > -
> > -   at91wdt_private.expect_close = 0;
> > -
> > -   for (i = 0; i < len; i++) {
> > -   char c;
> > -   if (get_user(c, data + i))
> > -   return -EFAULT;
> > -   if (c == 'V') {
> > -   at91wdt_private.expect_close = 42;
> > -   break;
> > -   }
> > -   }
> > -   

Re: [PATCH 041/270] pnfsblock: fix partial page buffer wirte

2012-12-03 Thread Greg Kroah-Hartman
On Tue, Dec 04, 2012 at 02:55:14AM +, Peng, Tao wrote:
> > -Original Message-
> > From: Peng, Tao
> > Sent: Saturday, December 01, 2012 11:47 PM
> > To: Myklebust, Trond; Greg Kroah-Hartman; Ben Hutchings
> > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 
> > kernel-t...@lists.ubuntu.com; Herton Ronaldo
> > Krzesinski
> > Subject: RE: [PATCH 041/270] pnfsblock: fix partial page buffer wirte
> > 
> > Hi Greg and Ben,
> > 
> > Attached is the patch of upstream commit 
> > fe6e1e8d9fad86873eb74a26e80a8f91f9e870b5 backported to 3.4.20
> > stable branch (head 0f4475cfaaf80e34ea5496a93ce579fe8c6950d5).
> > 
> Hi Greg,
> 
> Somehow the patch got dropped? I just scanned through the newly
> released 3.4.21 and it doesn't have the patch.

Yes, because it came after I started the -rc cycle, it will be in the
next 3.4-stable release.

thanks,

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


RE: [PATCH 00/11] watchdog/at91sam9_wdt: use watchdog framework, support DT

2012-12-03 Thread Yang, Wenyou
Hi JC
> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
> Sent: 2012年11月16日 21:51
> To: Yang, Wenyou
> Cc: linux-arm-ker...@lists.infradead.org; w...@iguana.be;
> linux-watch...@vger.kernel.org; linux-kernel@vger.kernel.org; Ferre, Nicolas; 
> Lin,
> JM
> Subject: Re: [PATCH 00/11] watchdog/at91sam9_wdt: use watchdog framework,
> support DT
> 
> On 15:15 Wed 14 Nov , Wenyou Yang wrote:
> > Hi, All
> >
> > The patch series is intended to convert to use the watchdog framework,
> > and add support to device tree.
> > It has been tested on sam9m10g45ek, sam9g20ek, sam9263ek and sam9g25ek.
> you need to check Fabio wrok which is present on the ML for a while and  was
> reviewed and binding too
>
OK, I will do it, thanks.
 
> Best Regards,
> J.
> >
> > It is based on v3.7-rc5.
> >
> > Best Regards
> > Wenyou Yang
> >

Best Regards
Wenyou Yang

> > Wenyou Yang (11):
> >   watchdog/at91sam9_wdt: remove the file_operations struct
> >   watchdog/at91sam9_wdt: change the at91wdt_private struct to the
> > at91wdt_drvdata struct
> >   watchdog/at91sam9_wdt: change the wdt_read and wdt_write macro to the
> > inline function
> >   watchdog/at91sam9_wdt: change "at91_wdt_settimeout" function name to
> > "at91wdt_enable"
> >   watchdog/at91sam9_wdt: add to use the watchdog framework
> >   watchdog/at91sam9_wdt: change the timer function name
> >   watchdog/at91sam9_wdt: add nowayout helpers to Watchdog Timer Driver
> > Kernel API
> >   watchdog/at91sam9_wdt: use module_platform_driver()
> >   watchdog/at91sam9_wdt: add support to device tree
> >   watchdog/at91sam9_wdt: using dev_info replaces pr_info, dev_crit
> > repalces pr_crit
> >   ARM: dts: add the watchdog nodes for atmel SoC
> >
> >  .../devicetree/bindings/watchdog/atmel-wdt.txt |   14 +
> >  arch/arm/boot/dts/at91sam9260.dtsi |6 +
> >  arch/arm/boot/dts/at91sam9263.dtsi |6 +
> >  arch/arm/boot/dts/at91sam9263ek.dts|4 +
> >  arch/arm/boot/dts/at91sam9g20ek_common.dtsi|4 +
> >  arch/arm/boot/dts/at91sam9g25ek.dts|4 +
> >  arch/arm/boot/dts/at91sam9g45.dtsi |5 +
> >  arch/arm/boot/dts/at91sam9m10g45ek.dts |4 +
> >  arch/arm/boot/dts/at91sam9n12.dtsi |6 +
> >  arch/arm/boot/dts/at91sam9n12ek.dts|4 +
> >  arch/arm/boot/dts/at91sam9x5.dtsi  |6 +
> >  drivers/watchdog/Kconfig   |1 +
> >  drivers/watchdog/at91sam9_wdt.c|  294 
> > 
> >  13 files changed, 185 insertions(+), 173 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >
> > --
> > 1.7.9.5
> >


RE: [PATCH 03/11] watchdog/at91sam9_wdt: change the wdt_read and wdt_write macro to the inline function

2012-12-03 Thread Yang, Wenyou
Hi JC,

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
> Sent: 2012年11月16日 21:49
> To: Yang, Wenyou
> Cc: linux-arm-ker...@lists.infradead.org; w...@iguana.be;
> linux-watch...@vger.kernel.org; linux-kernel@vger.kernel.org; Ferre, Nicolas; 
> Lin,
> JM
> Subject: Re: [PATCH 03/11] watchdog/at91sam9_wdt: change the wdt_read and
> wdt_write macro to the inline function
> 
> On 15:16 Wed 14 Nov , Wenyou Yang wrote:
> > Signed-off-by: Wenyou Yang 
> > ---
> >  drivers/watchdog/at91sam9_wdt.c |   28 ++--
> >  1 file changed, 18 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/watchdog/at91sam9_wdt.c 
> > b/drivers/watchdog/at91sam9_wdt.c
> > index 31c914a..98e7d5a 100644
> > --- a/drivers/watchdog/at91sam9_wdt.c
> > +++ b/drivers/watchdog/at91sam9_wdt.c
> > @@ -34,11 +34,6 @@
> >
> >  #define DRV_NAME "AT91SAM9 Watchdog"
> >
> > -#define wdt_read(field) \
> > -   __raw_readl(at91wdt_private.base + field)
> > -#define wdt_write(field, val) \
> > -   __raw_writel((val), at91wdt_private.base + field)
> > -
> >  /* AT91SAM9 watchdog runs a 12bit counter @ 256Hz,
> >   * use this to convert a watchdog
> >   * value from/to milliseconds.
> > @@ -75,13 +70,24 @@ struct at91wdt_drvdata {
> >
> >  /* 
> > . */
> >
> > +static inline unsigned int wdt_read(struct at91wdt_drvdata *driver_data,
> > +   unsigned int field)
> > +{
> > +   return __raw_readl(driver_data->base + field);
> > +}
> > +
> > +static inline void wdt_write(struct at91wdt_drvdata *driver_data,
> > +   unsigned int field, unsigned int val)
> > +{
> > +   __raw_writel((val), driver_data->base + field);
> > +}
> use relaxed version

Thanks, I will change it.
> 
> Best Regrds,
> J.

Best Regards,
Wenyou Yang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf"�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

Re: sigaltstack fun

2012-12-03 Thread David Miller
From: Al Viro 
Date: Mon, 26 Nov 2012 05:15:44 +

> On Mon, Nov 26, 2012 at 05:10:02AM +, Al Viro wrote:
>> On Sun, Nov 18, 2012 at 10:27:24PM -0500, David Miller wrote:
>> > > Cc: sta...@vger.kernel.org
>> > > Signed-off-by: Al Viro 
>> > 
>> > Applied, thanks.
>> 
>> Hmm...  There's something odd going on with {rt_,}sigaction on sparc -
>> we *do* have sa_restorer in struct sigaction and struct old_sigaction,
>> but it's not used for anything whatsoever.  There's also a separately
>> passed restorer pointer for rt_sigaction() and *that* is used instead,
>> but not reported via *oact.
>> 
>> What's the reason for that weirdness?  I understand why we do that on
>> alpha (we have no sa_restorer in struct sigaction we'd inherited from
>> OSF/1), but sparc always had perfectly normal sigaction->sa_restorer
>> field all along - even for old sigaction(2)...
> 
> PS: speaking of weirdness, what's the reason for sparc and ppc (and nothing
> else) expecting the first argument of sigaction(2) to be minus signal
> number?  ABI archaeology is fun...

It's because of stupidity.

We had two sigaction interpretations, and distinguished the two cases
by whether the signal passed in was positive or negative.

The positive code got phased out and simply deleted, leaving only
the negative case.

If you look into ancient trees (f.e. 2.4.x) you'll see stuff like
this:

if (sig < 0) {
current->thread.new_signal = 1;
sig = -sig;
}

in sparc_sigaction().

The main problem is that, originally, I didn't pass a siginfo into the
signal handler.  I didn't want to break applications that made use of
the arguments I did provide.  So this was the compatability facility.

If you passed in a negative signal number, I passed the signal()
handler args as they are documented in sigaction(2).  Otherwise
I passed in whatever I had passed previously.


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


Re: sigaltstack fun

2012-12-03 Thread David Miller
From: Al Viro 
Date: Mon, 26 Nov 2012 05:10:02 +

> On Sun, Nov 18, 2012 at 10:27:24PM -0500, David Miller wrote:
>> > Cc: sta...@vger.kernel.org
>> > Signed-off-by: Al Viro 
>> 
>> Applied, thanks.
> 
> Hmm...  There's something odd going on with {rt_,}sigaction on sparc -
> we *do* have sa_restorer in struct sigaction and struct old_sigaction,
> but it's not used for anything whatsoever.  There's also a separately
> passed restorer pointer for rt_sigaction() and *that* is used instead,
> but not reported via *oact.
> 
> What's the reason for that weirdness?  I understand why we do that on
> alpha (we have no sa_restorer in struct sigaction we'd inherited from
> OSF/1), but sparc always had perfectly normal sigaction->sa_restorer
> field all along - even for old sigaction(2)...

I have no idea how things got this way.

In the old sigaction() we do use the sa_restorer, and for both RT and
non-RT sigaction, we do fill in the sa_restorer member for the old
sigaction returned.

This special 'restorer' argument overrides the sigaction one.

GLIBC wraps calls to this system call, see:

sysdeps/unix/sysv/linux/sparc/sparc32/sigaction.c
sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c

I wish I had more context and info, but I don't :-(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4 16/31] loop: use aio to perform io on the underlying file

2012-12-03 Thread Dave Kleikamp
On 12/03/2012 08:52 PM, Dave Chinner wrote:
> On Mon, Dec 03, 2012 at 10:59:39AM -0600, Dave Kleikamp wrote:
>> On 11/22/2012 05:06 PM, Dave Chinner wrote:

>>> And this extra fsync is now not done in the aio path. I.e. the AIO
>>> completion path needs to issue the fsync to maintain correct REQ_FUA
>>> semantics...
>>
>> If this is really necessary, I can fix it.
> 
> Absolutely. If we don't implement FUA properly, we'll end up with
> corrupted filesystems and/or data loss when kernel crashes or
> powerloss occurs. That's not an acceptable outcome, so we need FUA
> to be implemented properly.

Okay, just wanted to make sure.

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


RE: [PATCH 041/270] pnfsblock: fix partial page buffer wirte

2012-12-03 Thread Peng, Tao
> -Original Message-
> From: Peng, Tao
> Sent: Saturday, December 01, 2012 11:47 PM
> To: Myklebust, Trond; Greg Kroah-Hartman; Ben Hutchings
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 
> kernel-t...@lists.ubuntu.com; Herton Ronaldo
> Krzesinski
> Subject: RE: [PATCH 041/270] pnfsblock: fix partial page buffer wirte
> 
> Hi Greg and Ben,
> 
> Attached is the patch of upstream commit 
> fe6e1e8d9fad86873eb74a26e80a8f91f9e870b5 backported to 3.4.20
> stable branch (head 0f4475cfaaf80e34ea5496a93ce579fe8c6950d5).
> 
Hi Greg,

Somehow the patch got dropped? I just scanned through the newly released 3.4.21 
and it doesn't have the patch.

Is it because the patch was sent as attachment? My apology for that... I'm 
resending it bellow. It applies cleanly on top of 3.4.21 (commit 3d514b82). 
Please queue it for the next 3.4 stable release. Thanks!

Best,
Tao

From bb51f7df0688f137998c3746705a346c7d8323c2 Mon Sep 17 00:00:00 2001
From: Peng Tao 
Date: Fri, 24 Aug 2012 00:27:51 +0800
Subject: [PATCH] pnfsblock: fix partial page buffer wirte

commit fe6e1e8d9fad86873eb74a26e80a8f91f9e870b5 upstream.

If applications use flock to protect its write range, generic NFS
will not do read-modify-write cycle at page cache level. Therefore
LD should know how to handle non-sector aligned writes. Otherwise
there will be data corruption.

Signed-off-by: Peng Tao 
Signed-off-by: Trond Myklebust 
---
 fs/nfs/blocklayout/blocklayout.c |  176 +++---
 fs/nfs/blocklayout/blocklayout.h |1 +
 2 files changed, 165 insertions(+), 12 deletions(-)

diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index 7f6a23f..d16dae2 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -162,25 +162,39 @@ static struct bio *bl_alloc_init_bio(int npg, sector_t 
isect,
return bio;
 }
 
-static struct bio *bl_add_page_to_bio(struct bio *bio, int npg, int rw,
+static struct bio *do_add_page_to_bio(struct bio *bio, int npg, int rw,
  sector_t isect, struct page *page,
  struct pnfs_block_extent *be,
  void (*end_io)(struct bio *, int err),
- struct parallel_io *par)
+ struct parallel_io *par,
+ unsigned int offset, int len)
 {
+   isect = isect + (offset >> SECTOR_SHIFT);
+   dprintk("%s: npg %d rw %d isect %llu offset %u len %d\n", __func__,
+   npg, rw, (unsigned long long)isect, offset, len);
 retry:
if (!bio) {
bio = bl_alloc_init_bio(npg, isect, be, end_io, par);
if (!bio)
return ERR_PTR(-ENOMEM);
}
-   if (bio_add_page(bio, page, PAGE_CACHE_SIZE, 0) < PAGE_CACHE_SIZE) {
+   if (bio_add_page(bio, page, len, offset) < len) {
bio = bl_submit_bio(rw, bio);
goto retry;
}
return bio;
 }
 
+static struct bio *bl_add_page_to_bio(struct bio *bio, int npg, int rw,
+ sector_t isect, struct page *page,
+ struct pnfs_block_extent *be,
+ void (*end_io)(struct bio *, int err),
+ struct parallel_io *par)
+{
+   return do_add_page_to_bio(bio, npg, rw, isect, page, be,
+ end_io, par, 0, PAGE_CACHE_SIZE);
+}
+
 /* This is basically copied from mpage_end_io_read */
 static void bl_end_io_read(struct bio *bio, int err)
 {
@@ -443,6 +457,107 @@ map_block(struct buffer_head *bh, sector_t isect, struct 
pnfs_block_extent *be)
return;
 }
 
+static void
+bl_read_single_end_io(struct bio *bio, int error)
+{
+   struct bio_vec *bvec = bio->bi_io_vec + bio->bi_vcnt - 1;
+   struct page *page = bvec->bv_page;
+
+   /* Only one page in bvec */
+   unlock_page(page);
+}
+
+static int
+bl_do_readpage_sync(struct page *page, struct pnfs_block_extent *be,
+   unsigned int offset, unsigned int len)
+{
+   struct bio *bio;
+   struct page *shadow_page;
+   sector_t isect;
+   char *kaddr, *kshadow_addr;
+   int ret = 0;
+
+   dprintk("%s: offset %u len %u\n", __func__, offset, len);
+
+   shadow_page = alloc_page(GFP_NOFS | __GFP_HIGHMEM);
+   if (shadow_page == NULL)
+   return -ENOMEM;
+
+   bio = bio_alloc(GFP_NOIO, 1);
+   if (bio == NULL)
+   return -ENOMEM;
+
+   isect = (page->index << PAGE_CACHE_SECTOR_SHIFT) +
+   (offset / SECTOR_SIZE);
+
+   bio->bi_sector = isect - be->be_f_offset + be->be_v_offset;
+   bio->bi_bdev = be->be_mdev;
+   bio->bi_end_io = bl_read_single_end_io;
+
+   lock_page(shadow_page);
+   if (bio_add_page(bio, shadow_page,
+

Re: [PATCH 2/4] rtc: pxa: fix rtc caculation issue

2012-12-03 Thread Chao Xie
On Mon, Dec 3, 2012 at 10:40 AM, Chao Xie  wrote:
> On Fri, Nov 30, 2012 at 4:04 AM, Robert Jarzmik  
> wrote:
>> Chao Xie  writes:
>>
>> Hi Chao Xie,
>>
>> First of all, could you please send patches from rtc-pxa to me also, as I'm
>> maintaining that driver ?
>>
>> Second point, the original design of the driver relies on the special case of
>> writing zeroes to WOM and DOM, as mentionned in PXA27x Developers Guide, 
>> chapter
>> 21.4.2.3.5 "Writing Alarm Registers with Invalid (Zero) Data", which states :
>>> Day-Of-Week (DOW), or Week-Of-Month (WOM), Day of Month (DOM), Month or Year
>>> fields—Zero is not valid for these fields. If zero is written into any of
>>> these fields, it is ignored while generating the alarm.
>>
>> I'd like to know if your patch fixes something, or is an enhancement ?
>>
>> Cheers.
>>
>> --
>> Robert
>>
>> PS: I've not checked the patch yet, that's just a prelimary comment on the 
>> patch
>> message.
>
> hi
> I am sorry, i just use get_maintainer.pl to get the "to" list.
> I have go through the spec. The spec has the desctiption about the
> invalid data writing.
> I am a little confused about the "wrting 0 to DOW". The descrption is
> confused. first it said that "If zero is written into any of these
> fields, it is ignored
> while generating the alarm", then it gives a example, that if writing
> 0 to DOW, "For example, if a zero is written into a DOW field, the
> alarm is set
> every day at the time written in the Hours, Minutes, and Seconds
> field”. It seems that the Year/Month/Week will not take effect.
> I will do the test on the board again, and send out the update.

hi, Robert
You are right. it does not matter to set WOM and DOW. please ignore this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4 16/31] loop: use aio to perform io on the underlying file

2012-12-03 Thread Dave Chinner
On Mon, Dec 03, 2012 at 10:59:39AM -0600, Dave Kleikamp wrote:
> On 11/22/2012 05:06 PM, Dave Chinner wrote:
> > On Wed, Nov 21, 2012 at 04:40:56PM -0600, Dave Kleikamp wrote:
> >> From: Zach Brown 
> >>
> >> This uses the new kernel aio interface to process loopback IO by
> >> submitting concurrent direct aio.  Previously loop's IO was serialized
> >> by synchronous processing in a thread.
> >>
> >> The aio operations specify the memory for the IO with the bio_vec arrays
> >> directly instead of mappings of the pages.
> >>
> >> The use of aio operations is enabled when the backing file supports the
> >> read_iter and write_iter methods.  These methods must only be added when
> >> O_DIRECT on bio_vecs is supported.
> >>
> >> Signed-off-by: Dave Kleikamp 
> >> Cc: Zach Brown 
> > 
> > I suspect aio iocompetion here doesn't work for FUA write IO.
> 
> Since the underlying file system is doing direct IO, we at least know
> that the IO has been performed to the underlying device. It could still
> be in the devices write cache, so maybe an fsync is still needed. It
> wouldn't be hard to fix if that's the right thing to do.

FUA means the write is all the way to stable storage when completion
is signalled by the underlying device. That means the loop device
needs to (at least) fdatasync after the write completes...

> >> +static void lo_rw_aio_complete(u64 data, long res)
> >> +{
> >> +  struct bio *bio = (struct bio *)(uintptr_t)data;
> >> +
> >> +  if (res > 0)
> >> +  res = 0;
> >> +  else if (res < 0)
> >> +  res = -EIO;
> >> +
> >> +  bio_endio(bio, res);
> >> +}
> > 
> > This effectively does nothing...
> 
> It passes the IO completion from the underlying device to the caller.

Yes, I know. What I'm saying is that it does nothing on completion
of a FUA write when it should be doing a fsync.

> >> -  lo->lo_encrypt_key_size) {
> >> -  ret = -EOPNOTSUPP;
> >> -  goto out;
> >> -  }
> >> -  ret = file->f_op->fallocate(file, mode, pos,
> >> -  bio->bi_size);
> >> -  if (unlikely(ret && ret != -EINVAL &&
> >> -   ret != -EOPNOTSUPP))
> >> -  ret = -EIO;
> >> -  goto out;
> >> -  }
> >> -
> >>ret = lo_send(lo, bio, pos);
> >>  
> >>if ((bio->bi_rw & REQ_FUA) && !ret) {
> > 
> > And as you can see here that after writing the data in the filebacked
> > path, there's special handling for REQ_FUA (i.e. another fsync).
> > 
> 
> In this path, the data may still be in the underlying filesystem's page
> cache.

Sure, but fsync means that it ends up on stable storage, as per the
requirement of an FUA write. Direct IO does not mean the data is on
stable storage, just that it bypasses the page cache.

> > And this extra fsync is now not done in the aio path. I.e. the AIO
> > completion path needs to issue the fsync to maintain correct REQ_FUA
> > semantics...
> 
> If this is really necessary, I can fix it.

Absolutely. If we don't implement FUA properly, we'll end up with
corrupted filesystems and/or data loss when kernel crashes or
powerloss occurs. That's not an acceptable outcome, so we need FUA
to be implemented properly.

Cheers,

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


Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

2012-12-03 Thread Chao Xie
On Mon, Dec 3, 2012 at 5:48 PM, Russell King - ARM Linux
 wrote:
> On Mon, Dec 03, 2012 at 10:53:07AM +0800, Chao Xie wrote:
>> I want to correct what i said. For the irq register/unregister i think
>> can be done at open/release. But for clock enable/disable, i do not
>> think so. If clock is disabled, as i think RTC will not work. User API
>> still use open->get_time->close for "date" command. It means that RTC
>> will not return correct date to user.
>
> "I think" is not good enough for patches like this.  Please test it.
>
> On SA11x0 and PXA platforms, the clock for the sa1100-rtc is a dummy
> clock; it has no effect.  For MMP, I don't have access to the TRMs so
> that's something you're going to have to find out.

I tested at pxa910 which uses rtc-sa1100 as driver.
the test procedure is simple
open->ioctl(RTC_RD_TIME)->close
With the original code, the rtc will not update, i always get the same value

remove clock disable/enable in release/open, and enable/disable clock
at probe/remove.
the rtc can update, and i can read the correct rtc value.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC PATCH v3] Add rcu user eqs exception hooks for async page fault

2012-12-03 Thread Li Zhong
On Mon, 2012-12-03 at 11:57 +0200, Gleb Natapov wrote:
> Please regenerate the patch against
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue.

Done.

By the way, the included file  is replaced with
 in latest next tree(91d1aa43 from rcu tree). 

Seems if they are merged, there won't be conflicts, but we need change
the including file name after that. I don't know how to handle this kind
of thing... 

Thanks, Zhong

> 
> On Fri, Nov 30, 2012 at 05:18:41PM +0800, Li Zhong wrote:
> > This patch adds user eqs exception hooks for async page fault page not
> > present code path, to exit the user eqs and re-enter it as necessary. 
> > 
> > Async page fault is different from other exceptions that it may be
> > triggered from idle process, so we still need rcu_irq_enter() and
> > rcu_irq_exit() to exit cpu idle eqs when needed, to protect the code
> > that needs use rcu.
> > 
> > As Frederic pointed out it would be safest and simplest to protect the
> > whole kvm_async_pf_task_wait(). Otherwise, "we need to check all the
> > code there deeply for potential RCU uses and ensure it will never be
> > extended later to use RCU.".
> > 
> > However, We'd better re-enter the cpu idle eqs if we get the exception
> > in cpu idle eqs, by calling rcu_irq_exit() before native_safe_halt(). 
> > 
> > So the patch does what Frederic suggested for rcu_irq_*() API usage
> > here, except that I moved the rcu_irq_*() pair originally in
> > do_async_page_fault() into kvm_async_pf_task_wait(). 
> > 
> > That's because, I think it's better to have rcu_irq_*() pairs to be in
> > one function ( rcu_irq_exit() after rcu_irq_enter() ), especially here,
> > kvm_async_pf_task_wait() has other callers, which might cause
> > rcu_irq_exit() be called without a matching rcu_irq_enter() before it,
> > which is illegal if the cpu happens to be in rcu idle state. 
> > 
> > Signed-off-by: Li Zhong 
> > ---
> >  arch/x86/kernel/kvm.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > index 4180a87..342b00b 100644
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> > @@ -42,6 +42,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  static int kvmapf = 1;
> >  
> > @@ -112,6 +113,8 @@ void kvm_async_pf_task_wait(u32 token)
> > DEFINE_WAIT(wait);
> > int cpu, idle;
> >  
> > +   rcu_irq_enter();
> > +
> > cpu = get_cpu();
> > idle = idle_cpu(cpu);
> > put_cpu();
> > @@ -123,6 +126,8 @@ void kvm_async_pf_task_wait(u32 token)
> > hlist_del(>link);
> > kfree(e);
> > spin_unlock(>lock);
> > +
> > +   rcu_irq_exit();
> > return;
> > }
> >  
> > @@ -147,13 +152,16 @@ void kvm_async_pf_task_wait(u32 token)
> > /*
> >  * We cannot reschedule. So halt.
> >  */
> > +   rcu_irq_exit();
> > native_safe_halt();
> > +   rcu_irq_enter();
> > local_irq_disable();
> > }
> > }
> > if (!n.halted)
> > finish_wait(, );
> >  
> > +   rcu_irq_exit();
> > return;
> >  }
> >  EXPORT_SYMBOL_GPL(kvm_async_pf_task_wait);
> > @@ -247,10 +255,10 @@ do_async_page_fault(struct pt_regs *regs, unsigned 
> > long error_code)
> > break;
> > case KVM_PV_REASON_PAGE_NOT_PRESENT:
> > /* page is swapped out by the host. */
> > -   rcu_irq_enter();
> > +   exception_enter(regs);
> > exit_idle();
> > kvm_async_pf_task_wait((u32)read_cr2());
> > -   rcu_irq_exit();
> > +   exception_exit(regs);
> > break;
> > case KVM_PV_REASON_PAGE_READY:
> > rcu_irq_enter();
> > -- 
> > 1.7.11.4
> 
> --
>   Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


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


[ PATCH] Add rcu user eqs exception hooks for async page fault

2012-12-03 Thread Li Zhong
This patch adds user eqs exception hooks for async page fault page not
present code path, to exit the user eqs and re-enter it as necessary.

Async page fault is different from other exceptions that it may be
triggered from idle process, so we still need rcu_irq_enter() and
rcu_irq_exit() to exit cpu idle eqs when needed, to protect the code
that needs use rcu.

As Frederic pointed out it would be safest and simplest to protect the
whole kvm_async_pf_task_wait(). Otherwise, "we need to check all the
code there deeply for potential RCU uses and ensure it will never be
extended later to use RCU.".

However, We'd better re-enter the cpu idle eqs if we get the exception
in cpu idle eqs, by calling rcu_irq_exit() before native_safe_halt().

So the patch does what Frederic suggested for rcu_irq_*() API usage
here, except that I moved the rcu_irq_*() pair originally in
do_async_page_fault() into kvm_async_pf_task_wait().

That's because, I think it's better to have rcu_irq_*() pairs to be in
one function ( rcu_irq_exit() after rcu_irq_enter() ), especially here,
kvm_async_pf_task_wait() has other callers, which might cause
rcu_irq_exit() be called without a matching rcu_irq_enter() before it,
which is illegal if the cpu happens to be in rcu idle state.

Signed-off-by: Li Zhong 
---
 arch/x86/kernel/kvm.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 08b973f..e99af60 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int kvmapf = 1;
 
@@ -121,6 +122,8 @@ void kvm_async_pf_task_wait(u32 token)
struct kvm_task_sleep_node n, *e;
DEFINE_WAIT(wait);
 
+   rcu_irq_enter();
+
spin_lock(>lock);
e = _find_apf_task(b, token);
if (e) {
@@ -128,6 +131,8 @@ void kvm_async_pf_task_wait(u32 token)
hlist_del(>link);
kfree(e);
spin_unlock(>lock);
+
+   rcu_irq_exit();
return;
}
 
@@ -152,13 +157,16 @@ void kvm_async_pf_task_wait(u32 token)
/*
 * We cannot reschedule. So halt.
 */
+   rcu_irq_exit();
native_safe_halt();
+   rcu_irq_enter();
local_irq_disable();
}
}
if (!n.halted)
finish_wait(, );
 
+   rcu_irq_exit();
return;
 }
 EXPORT_SYMBOL_GPL(kvm_async_pf_task_wait);
@@ -252,10 +260,10 @@ do_async_page_fault(struct pt_regs *regs, unsigned long 
error_code)
break;
case KVM_PV_REASON_PAGE_NOT_PRESENT:
/* page is swapped out by the host. */
-   rcu_irq_enter();
+   exception_enter(regs);
exit_idle();
kvm_async_pf_task_wait((u32)read_cr2());
-   rcu_irq_exit();
+   exception_exit(regs);
break;
case KVM_PV_REASON_PAGE_READY:
rcu_irq_enter();
-- 
1.7.11.4

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


Re: [patch,v2] bdi: add a user-tunable cpu_list for the bdi flusher threads

2012-12-03 Thread Dave Chinner
On Mon, Dec 03, 2012 at 01:53:39PM -0500, Jeff Moyer wrote:
> Hi,
> 
> In realtime environments, it may be desirable to keep the per-bdi
> flusher threads from running on certain cpus.  This patch adds a
> cpu_list file to /sys/class/bdi/* to enable this.  The default is to tie
> the flusher threads to the same numa node as the backing device (though
> I could be convinced to make it a mask of all cpus to avoid a change in
> behaviour).

The default seems reasonable to me.

> Comments, as always, are appreciated.
.

> +static ssize_t cpu_list_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
> +{
> + struct backing_dev_info *bdi = dev_get_drvdata(dev);
> + struct bdi_writeback *wb = >wb;
> + cpumask_var_t newmask;
> + ssize_t ret;
> + struct task_struct *task;
> +
> + if (!alloc_cpumask_var(, GFP_KERNEL))
> + return -ENOMEM;
> +
> + ret = cpulist_parse(buf, newmask);
> + if (!ret) {
> + spin_lock(>wb_lock);
> + task = wb->task;
> + if (task)
> + get_task_struct(task);
> + spin_unlock(>wb_lock);
> + if (task) {
> + ret = set_cpus_allowed_ptr(task, newmask);
> + put_task_struct(task);
> + }

Why is this set here outside the bdi->flusher_cpumask_mutex?

Also, I'd prefer it named "..._lock" as that is the normal
convention for such variables. You can tell the type of lock from
the declaration or the use...



> @@ -437,6 +488,14 @@ static int bdi_forker_thread(void *ptr)
>   spin_lock_bh(>wb_lock);
>   bdi->wb.task = task;
>   spin_unlock_bh(>wb_lock);
> + mutex_lock(>flusher_cpumask_mutex);
> + ret = set_cpus_allowed_ptr(task,
> + bdi->flusher_cpumask);
> + mutex_unlock(>flusher_cpumask_mutex);

As it is set under the lock here

Cheers,

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


[PATCH] regulator: gpio-regulator: Add ifdef CONFIG_OF guard for regulator_gpio_of_match

2012-12-03 Thread Axel Lin
Use of_match_ptr and add ifdef CONFIG_OF guard for regulator_gpio_of_match.

Signed-off-by: Axel Lin 
---
 drivers/regulator/gpio-regulator.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/gpio-regulator.c 
b/drivers/regulator/gpio-regulator.c
index 3ee79c8..2cfd9d3 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -364,10 +364,12 @@ static int gpio_regulator_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#if defined(CONFIG_OF)
 static const struct of_device_id regulator_gpio_of_match[] __devinitconst = {
{ .compatible = "regulator-gpio", },
{},
 };
+#endif
 
 static struct platform_driver gpio_regulator_driver = {
.probe  = gpio_regulator_probe,
@@ -375,7 +377,7 @@ static struct platform_driver gpio_regulator_driver = {
.driver = {
.name   = "gpio-regulator",
.owner  = THIS_MODULE,
-   .of_match_table = regulator_gpio_of_match,
+   .of_match_table = of_match_ptr(regulator_gpio_of_match),
},
 };
 
-- 
1.7.9.5



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


[PATCH] dev_change_net_namespace: send a KOBJ_REMOVED/KOBJ_ADD

2012-12-03 Thread Serge Hallyn
When a new nic is created in namespace ns1, the kernel sends a KOBJ_ADD uevent
to ns1.  When the nic is moved to ns2, we only send a KOBJ_MOVE to ns2, and
nothing to ns1.

This patch changes that behavior so that when moving a nic from ns1 to ns2, we
send a KOBJ_REMOVED to ns1 and KOBJ_ADD to ns2.  (The KOBJ_MOVE is still
sent to ns2).

The effects of this can be seen when starting and stopping containers in
an upstart based host.  Lxc will create a pair of veth nics, the kernel
sends KOBJ_ADD, and upstart starts network-instance jobs for each.  When
one nic is moved to the container, because no KOBJ_REMOVED event is
received, the network-instance job for that veth never goes away.  This
was reported at https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589
With this patch the networ-instance jobs properly go away.

The other oddness solved here is that if a nic is passed into a running
upstart-based container, without this patch no network-instance job is
started in the container.  But when the container creates a new nic
itself (ip link add new type veth) then network-interface jobs are
created.  With this patch, behavior comes in line with a regular host.

v2: also send KOBJ_ADD to new netns.  There will then be a
_MOVE event from the device_rename() call, but that should
be innocuous.

Signed-off-by: Serge Hallyn 
Acked-by: "Eric W. Biederman" 
Acked-by: Daniel Lezcano 
---
 net/core/dev.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index e2215ee..2c43aaf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6172,6 +6172,9 @@ int dev_change_net_namespace(struct net_device *dev, 
struct net *net, const char
dev_uc_flush(dev);
dev_mc_flush(dev);
 
+   /* Send a netdev-removed uevent to the old namespace */
+   kobject_uevent(>dev.kobj, KOBJ_REMOVE);
+
/* Actually switch the network namespace */
dev_net_set(dev, net);
 
@@ -6183,6 +6186,9 @@ int dev_change_net_namespace(struct net_device *dev, 
struct net *net, const char
dev->iflink = dev->ifindex;
}
 
+   /* Send a netdev-add uevent to the new namespace */
+   kobject_uevent(>dev.kobj, KOBJ_ADD);
+
/* Fixup kobjects */
err = device_rename(>dev, dev->name);
WARN_ON(err);
-- 
1.7.9.5

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


Re: [RFC v2 1/8] video: tegra: Add nvhost driver

2012-12-03 Thread Mark Zhang
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
> 
> One other thing that such a design can help with is refactoring common
> code or parameterizing code. Maybe newer generations are not compatible
> but can easily be made to work with existing code by introducing a
> variable such as register stride or something.
> 
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single host1x in a system. I know this will
> never happen, but all of a sudden it happens anyway and the code breaks.
> Doing this right isn't very hard and it will lead to a better design and
> is less likely to break at some point.
> 

Sorry I forget to reply this in last mail...

Agree. Even for userspace programs, we should avoid using global
variables as possible as we can. So we need to think about this and try
to reduce the number of global vars.

Mark
> Thierry
> 
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC v2 1/8] video: tegra: Add nvhost driver

2012-12-03 Thread Mark Zhang
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
>> I think there's room for letting Terje's complete knowledge of future
>> chips guide the design of the current code that's sent upstream.
>> Certainly we shouldn't add a ton of unnecessary abstraction layers
>> right now that aren't needed for Tegra20/30, but if there's some
>> decision that doesn't affect the bloat, opaqueness, ... of the current
>> code but one choice is better for future development without serious
>> negatives for the current code, it's pretty reasonable to make that
>> decision rather than the other.
> 
> The original point was that the current design stashes every function of
> host1x into an ops structure and you have to go through those ops to get
> at the functionality. I can understand the need to add an ops structure
> to cope with incompatibilities between versions, but as you say there
> should to be a reason for them being introduced. If such reasons exists,
> then I think they at least warrant a comment somewhere.
> 
> Furthermore this is usually best handled by wrapping the ops accesses in
> a public API, so that the ops structure can be hidden within the driver.
> For example, submitting a job to a channel should have a public API such
> as:
> 
>   int host1x_channel_submit(struct host1x_channel *channel,
> struct host1x_job *job)
>   {
>   ...
>   }
> 
> An initial implementation would just add the code into this function. If
> it turns out some future version requires special incantations to submit
> a job, only then should we introduce an ops structure, with only the one
> function:
> 
>   struct host1x_channel_ops {
>   int (*submit)(struct host1x_channel *channel,
> struct host1x_job *job);
>   };
> 
> But since only the public API above has been used, access to the special
> implementation can be hidden from the user. So the public function could
> be modified in this way:
> 
>   int host1x_channel_submit(struct hostx1_channel *channel,
> struct host1x_job *job)
>   {
>   if (channel->ops && channel->ops->submit)
>   return channel->ops->submit(channel, job);
> 
>   ...
>   }
> 

I guess we do this in exactly this way at the beginning. Then we
realized that we need to define callbacks to make different tegra has
different logics. So that's why we see the codes have lots of function
ops right now.

If so, this will make Terje modify the code back to the original
version, and this is not an interesting work.

Just my personal guess, no offence.

Mark
> And then you have two choices: either you keep the code for previous
> generations after the if block or you provide a separate ops structure
> for older generations as well and handle them via the same code path.
> 
> One other thing that such a design can help with is refactoring common
> code or parameterizing code. Maybe newer generations are not compatible
> but can easily be made to work with existing code by introducing a
> variable such as register stride or something.
> 
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single host1x in a system. I know this will
> never happen, but all of a sudden it happens anyway and the code breaks.
> Doing this right isn't very hard and it will lead to a better design and
> is less likely to break at some point.
> 
> Thierry
> 
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux 3.7-rc8

2012-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2012 at 3:40 PM, Linus Torvalds
 wrote:
>
> Yup, I can reproduce it with that.
>
> I'll shut the printk up some way. In the meantime, you can ignore it.

Here's a patch to handle the "buffer head crosses the end of the disk" case.

It works for me, and in fact it should allow us to basically always
set the default block size to the PAGE_CACHE_SIZE (see bd_set_size()).
But it doesn't do that part yet, this is just the "guard against
crossing bh" part.

Does that fix the printk's for you too?

Linus


patch.diff
Description: Binary data


[PATCH] watchdog: store the watchdog sample period as a variable

2012-12-03 Thread Chuansheng Liu

Currently getting the sample period is always thru complex
calculation: get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5).
But just like the watchdog_thresh, which is not changed often.

So we can store the sample period as a variable, and set it as
__read_mostly type.

Signed-off-by: liu chuansheng 
---
 kernel/watchdog.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index dd4b80a..7a32b20 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -31,6 +31,7 @@
 int watchdog_enabled = 1;
 int __read_mostly watchdog_thresh = 10;
 static int __read_mostly watchdog_disabled;
+static u64 __read_mostly sample_period;
 
 static DEFINE_PER_CPU(unsigned long, watchdog_touch_ts);
 static DEFINE_PER_CPU(struct task_struct *, softlockup_watchdog);
@@ -116,7 +117,7 @@ static unsigned long get_timestamp(int this_cpu)
return cpu_clock(this_cpu) >> 30LL;  /* 2^30 ~= 10^9 */
 }
 
-static u64 get_sample_period(void)
+static void set_sample_period(void)
 {
/*
 * convert watchdog_thresh from seconds to ns
@@ -125,7 +126,7 @@ static u64 get_sample_period(void)
 * and hard thresholds) to increment before the
 * hardlockup detector generates a warning
 */
-   return get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5);
+   sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5);
 }
 
 /* Commands for resetting the watchdog */
@@ -275,7 +276,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct 
hrtimer *hrtimer)
wake_up_process(__this_cpu_read(softlockup_watchdog));
 
/* .. and repeat */
-   hrtimer_forward_now(hrtimer, ns_to_ktime(get_sample_period()));
+   hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));
 
if (touch_ts == 0) {
if (unlikely(__this_cpu_read(softlockup_touch_sync))) {
@@ -356,7 +357,7 @@ static void watchdog_enable(unsigned int cpu)
hrtimer->function = watchdog_timer_fn;
 
/* done here because hrtimer_start can only pin to smp_processor_id() */
-   hrtimer_start(hrtimer, ns_to_ktime(get_sample_period()),
+   hrtimer_start(hrtimer, ns_to_ktime(sample_period),
  HRTIMER_MODE_REL_PINNED);
 
/* initialize timestamp */
@@ -383,7 +384,7 @@ static int watchdog_should_run(unsigned int cpu)
 /*
  * The watchdog thread function - touches the timestamp.
  *
- * It only runs once every get_sample_period() seconds (4 seconds by
+ * It only runs once every sample_period seconds (4 seconds by
  * default) to reset the softlockup timestamp. If this gets delayed
  * for more than 2*watchdog_thresh seconds then the debug-printout
  * triggers in watchdog_timer_fn().
@@ -516,6 +517,7 @@ int proc_dowatchdog(struct ctl_table *table, int write,
if (ret || !write)
return ret;
 
+   set_sample_period();
if (watchdog_enabled && watchdog_thresh)
watchdog_enable_all_cpus();
else
@@ -537,6 +539,7 @@ static struct smp_hotplug_thread watchdog_threads = {
 
 void __init lockup_detector_init(void)
 {
+   set_sample_period();
if (smpboot_register_percpu_thread(_threads)) {
pr_err("Failed to create watchdog threads, disabled\n");
watchdog_disabled = -ENODEV;
-- 
1.7.0.4



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


[PATCH 7/7] aoe: update internal version number to 81

2012-12-03 Thread Ed Cashin
This version number is printed to the console on module
initialization and is available in sysfs, which is where the
userland aoe-version tool looks for it.

Signed-off-by: Ed Cashin 
---
 drivers/block/aoe/aoe.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index f8d6c7e..1756494 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -1,6 +1,5 @@
-
 /* Copyright (c) 2012 Coraid, Inc.  See COPYING for GPL terms. */
-#define VERSION "64+"
+#define VERSION "81"
 #define AOE_MAJOR 152
 #define DEVICE_NAME "aoe"
 
-- 
1.7.1

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


[PATCH 6/7] aoe: identify source of runt AoE packets

2012-12-03 Thread Ed Cashin
This change only affects experimental AoE storage networks.

It modifies the console message about runt packets detected so
that the AoE major and minor addresses of the AoE target that
generated the runt are mentioned.

Signed-off-by: Ed Cashin 
---
 drivers/block/aoe/aoecmd.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index abf4ad2..25ef5c0 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -1217,8 +1217,10 @@ noskb:   if (buf)
case ATA_CMD_PIO_READ:
case ATA_CMD_PIO_READ_EXT:
if (skb->len < n) {
-   pr_err("aoe: runt data size in read.  skb->len=%d 
need=%ld\n",
-   skb->len, n);
+   pr_err("%s e%ld.%d.  skb->len=%d need=%ld\n",
+   "aoe: runt data size in read from",
+   (long) d->aoemajor, d->aoeminor,
+  skb->len, n);
clear_bit(BIO_UPTODATE, >bio->bi_flags);
break;
}
@@ -1233,7 +1235,9 @@ noskb:if (buf)
break;
case ATA_CMD_ID_ATA:
if (skb->len < 512) {
-   pr_info("aoe: runt data size in ataid.  skb->len=%d\n",
+   pr_info("%s e%ld.%d.  skb->len=%d need=512\n",
+   "aoe: runt data size in ataid from",
+   (long) d->aoemajor, d->aoeminor,
skb->len);
break;
}
-- 
1.7.1

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


Re: [RFC v2 8/8] drm: tegra: Add gr2d device

2012-12-03 Thread Mark Zhang
On 12/03/2012 05:40 PM, Daniel Vetter wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang  wrote:
>> I'm new in kernel development. Could you tell me or give me some
>> materials to read that why we need to align the size of IOCTL structures
>> to 64bit? I can understand if we're working in a 64bit kernel but why we
>> need to do this if we're in a 32bit arm kernel? Besides, why the
>> pointers in IOCTL structure should be declared as u64?
> 
> Because in a few years/months you'll have arm64, but still the same
> driver with the same ioctls ... and if the ioctls are not _exactly_
> the same you get to write compat ioctl code which copies the old 32bit
> struct into the 64bit struct the kernel understands. Hence your ioctl
> must be laid out exactly the same for both 32bit and 64bit, which
> happens if you naturally align/pad everything to 64bits and only use
> fixed-sized integers and no pointers.

Ah, I see. Thanks. Yes, u64 still works as 32 bit pointer.

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


[PATCH 5/7] aoe: allow comma separator in aoe_iflist value

2012-12-03 Thread Ed Cashin
By default, the aoe driver uses any ethernet interface for AoE,
but the aoe_iflist module parameter provides a convenient way to
limit AoE traffic to a specific list of local network interfaces.

This change allows a list to be specified using the comma
character as a separator.  For example,

  modprobe aoe aoe_iflist=eth2,eth3

Before, it was inconvenient to get the quoting right in shell
scripts when setting aoe_iflist to have more than one network
interface.

Signed-off-by: Ed Cashin 
---
 drivers/block/aoe/aoe.h|2 +-
 drivers/block/aoe/aoenet.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index 0f478dc..f8d6c7e 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -11,7 +11,7 @@
 #define AOE_PARTITIONS (16)
 #endif
 
-#define WHITESPACE " \t\v\f\n"
+#define WHITESPACE " \t\v\f\n,"
 
 enum {
AOECMD_ATA,
diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c
index 2e47404..71d3ea8 100644
--- a/drivers/block/aoe/aoenet.c
+++ b/drivers/block/aoe/aoenet.c
@@ -31,7 +31,7 @@ enum {
 
 static char aoe_iflist[IFLISTSZ];
 module_param_string(aoe_iflist, aoe_iflist, IFLISTSZ, 0600);
-MODULE_PARM_DESC(aoe_iflist, "aoe_iflist=\"dev1 [dev2 ...]\"");
+MODULE_PARM_DESC(aoe_iflist, "aoe_iflist=dev1[,dev2...]");
 
 static wait_queue_head_t txwq;
 static struct ktstate kts;
-- 
1.7.1

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


[PATCH 4/7] aoe: allow user to disable target failure timeout

2012-12-03 Thread Ed Cashin
With this change, the aoe driver treats the value zero as special
for the aoe_deadsecs module parameter.  Normally, this value
specifies the number of seconds during which the driver will
continue to attempt retransmits to an unresponsive AoE target.
After aoe_deadsecs has elapsed, the aoe driver marks the aoe
device as "down" and fails all I/O.

The new meaning of an aoe_deadsecs of zero is for the driver to
retransmit commands indefinitely.

Signed-off-by: Ed Cashin 
---
 Documentation/aoe/aoe.txt  |4 +++-
 drivers/block/aoe/aoecmd.c |4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt
index bfc9cb1..c71487d 100644
--- a/Documentation/aoe/aoe.txt
+++ b/Documentation/aoe/aoe.txt
@@ -125,7 +125,9 @@ DRIVER OPTIONS
   The aoe_deadsecs module parameter determines the maximum number of
   seconds that the driver will wait for an AoE device to provide a
   response to an AoE command.  After aoe_deadsecs seconds have
-  elapsed, the AoE device will be marked as "down".
+  elapsed, the AoE device will be marked as "down".  A value of zero
+  is supported for testing purposes and makes the aoe driver keep
+  trying AoE commands forever.
 
   The aoe_maxout module parameter has a default of 128.  This is the
   maximum number of unresponded packets that will be sent to an AoE
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index da360f9..abf4ad2 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -812,7 +812,9 @@ rexmit_timer(ulong vp)
since = tsince_hr(f);
n = f->waited_total + since;
n /= USEC_PER_SEC;
-   if (n > aoe_deadsecs && !(f->flags & FFL_PROBE)) {
+   if (aoe_deadsecs
+   && n > aoe_deadsecs
+   && !(f->flags & FFL_PROBE)) {
/* Waited too long.  Device failure.
 * Hang all frames on first hash bucket for downdev
 * to clean up.
-- 
1.7.1

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


Re: [patch,v3,repost 07/10] megaraid_sas: use scsi_host_alloc_node

2012-12-03 Thread adam radford
On Tue, Nov 27, 2012 at 8:46 AM, Jeff Moyer  wrote:
>
> Signed-off-by: Jeff Moyer 
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index d2c5366..707a6cd 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4020,8 +4020,9 @@ megasas_probe_one(struct pci_dev *pdev, const struct 
> pci_device_id *id)
> if (megasas_set_dma_mask(pdev))
> goto fail_set_dma_mask;
>
> -   host = scsi_host_alloc(_template,
> -  sizeof(struct megasas_instance));
> +   host = scsi_host_alloc_node(_template,
> +   sizeof(struct megasas_instance),
> +   dev_to_node(>dev));
>
> if (!host) {
> printk(KERN_DEBUG "megasas: scsi_host_alloc failed\n");

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


[PATCH 3/7] aoe: use dynamic number of remote ports for AoE storage target

2012-12-03 Thread Ed Cashin
Many AoE targets have four or fewer network ports, but some
existing storage devices have many, and the AoE protocol sets no
limit.

This patch allows the use of more than eight remote MAC addresses
per AoE target, while reducing the amount of memory used by the
aoe driver in cases where there are many AoE targets with fewer
than eight MAC addresses each.

Signed-off-by: Ed Cashin 
---
 drivers/block/aoe/aoe.h|6 ++--
 drivers/block/aoe/aoeblk.c |2 +-
 drivers/block/aoe/aoecmd.c |   50 ++-
 drivers/block/aoe/aoedev.c |   12 -
 4 files changed, 49 insertions(+), 21 deletions(-)

diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index d50e945..0f478dc 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -84,7 +84,7 @@ enum {
 enum {
DEFAULTBCNT = 2 * 512,  /* 2 sectors */
MIN_BUFS = 16,
-   NTARGETS = 8,
+   NTARGETS = 4,
NAOEIFS = 8,
NSKBPOOLMAX = 256,
NFACTIVE = 61,
@@ -185,9 +185,9 @@ struct aoedev {
ulong maxbcnt;
struct list_head factive[NFACTIVE]; /* hash of active frames */
struct list_head rexmitq; /* deferred retransmissions */
-   struct aoetgt *targets[NTARGETS];
+   struct aoetgt **targets;
+   ulong ntargets; /* number of allocated aoetgt pointers */
struct aoetgt **tgt;/* target in use when working */
-   ulong ntargets;
ulong kicked;
char ident[512];
 };
diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
index 6b5b787..a129f8c 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -67,7 +67,7 @@ static ssize_t aoedisk_show_netif(struct device *dev,
nd = nds;
ne = nd + ARRAY_SIZE(nds);
t = d->targets;
-   te = t + NTARGETS;
+   te = t + d->ntargets;
for (; t < te && *t; t++) {
ifp = (*t)->ifs;
e = ifp + NAOEIFS;
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 000f7fb..da360f9 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -242,14 +242,14 @@ newframe(struct aoedev *d)
int use_tainted;
int has_untainted;
 
-   if (d->targets[0] == NULL) {/* shouldn't happen, but I'm paranoid */
+   if (!d->targets || !d->targets[0]) {
printk(KERN_ERR "aoe: NULL TARGETS!\n");
return NULL;
}
tt = d->tgt;/* last used target */
for (use_tainted = 0, has_untainted = 0;;) {
tt++;
-   if (tt >= >targets[NTARGETS] || !*tt)
+   if (tt >= >targets[d->ntargets] || !*tt)
tt = d->targets;
t = *tt;
if (!t->taint) {
@@ -1104,7 +1104,7 @@ gettgt(struct aoedev *d, char *addr)
struct aoetgt **t, **e;
 
t = d->targets;
-   e = t + NTARGETS;
+   e = t + d->ntargets;
for (; t < e && *t; t++)
if (memcmp((*t)->addr, addr, sizeof((*t)->addr)) == 0)
return *t;
@@ -1479,28 +1479,44 @@ aoecmd_ata_id(struct aoedev *d)
return skb;
 }
 
+static struct aoetgt **
+grow_targets(struct aoedev *d)
+{
+   ulong oldn, newn;
+   struct aoetgt **tt;
+
+   oldn = d->ntargets;
+   newn = oldn * 2;
+   tt = kcalloc(newn, sizeof(*d->targets), GFP_ATOMIC);
+   if (!tt)
+   return NULL;
+   memmove(tt, d->targets, sizeof(*d->targets) * oldn);
+   d->tgt = tt + (d->tgt - d->targets);
+   kfree(d->targets);
+   d->targets = tt;
+   d->ntargets = newn;
+
+   return >targets[oldn];
+}
+
 static struct aoetgt *
 addtgt(struct aoedev *d, char *addr, ulong nframes)
 {
struct aoetgt *t, **tt, **te;
 
tt = d->targets;
-   te = tt + NTARGETS;
+   te = tt + d->ntargets;
for (; tt < te && *tt; tt++)
;
 
if (tt == te) {
-   printk(KERN_INFO
-   "aoe: device addtgt failure; too many targets\n");
-   return NULL;
+   tt = grow_targets(d);
+   if (!tt)
+   goto nomem;
}
t = kzalloc(sizeof(*t), GFP_ATOMIC);
-   if (!t) {
-   printk(KERN_INFO "aoe: cannot allocate memory to add target\n");
-   return NULL;
-   }
-
-   d->ntargets++;
+   if (!t)
+   goto nomem;
t->nframes = nframes;
t->d = d;
memcpy(t->addr, addr, sizeof t->addr);
@@ -1509,6 +1525,10 @@ addtgt(struct aoedev *d, char *addr, ulong nframes)
t->maxout = t->nframes / 2;
INIT_LIST_HEAD(>ffree);
return *tt = t;
+
+ nomem:
+   pr_info("aoe: cannot allocate memory to add target\n");
+   return NULL;
 }
 
 static void
@@ -1518,7 +1538,7 @@ setdbcnt(struct aoedev *d)
int bcnt = 0;
 
t = d->targets;
-   e = t + NTARGETS;
+   e = t + 

Re: [PATCH 1/1] Input: STMicroelectronics multi touch capacitive touchscreen ftk

2012-12-03 Thread Dmitry Torokhov
Hi Li,

On Tue, Dec 04, 2012 at 08:32:05AM +0800, Li Wu wrote:
> Thanks Felipe for the nice comments.
> 
> I have consolidated most of your comments to a new version, but I am not
> sure how should I send it out.
> 
> I am using git send-email from shell command, then shall I just send out
> the patch v2? Or do I need send both v1 and v2?

Use "git rebase" to squash the 2 commit together and then send it out as
a single patch.

Thanks.

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


[PATCH 2/7] aoe: avoid races between device destruction and discovery

2012-12-03 Thread Ed Cashin
This change avoids a race that could result in a NULL pointer
derference following a WARNing from kobject_add_internal, "don't
try to register things with the same name in the same directory."

The problem was found with a test that forgets and discovers an
aoe device in a loop:

  while test ! -r /tmp/stop; do
aoe-flush -a
aoe-discover
  done

The race was between aoedev_flush taking aoedevs out of the
devlist, allowing a new discovery of the same AoE target to take
place before the driver gets around to calling
sysfs_remove_group.  Fixing that one revealed another race
between do_open and add_disk, and this patch avoids that, too.

The fix required some care, because for flushing (forgetting) an
aoedev, some of the steps must be performed under lock and some
must be able to sleep.  Also, for discovering a new aoedev, some
steps might sleep.

The check for a bad aoedev pointer remains from a time when about
half of this patch was done, and it was possible for the
bdev->bd_disk->private_data to become corrupted.  The check
should be removed eventually, but it is not expected to add
significant overhead, occurring in the aoeblk_open routine.

Signed-off-by: Ed Cashin 
---
 drivers/block/aoe/aoe.h|7 ++-
 drivers/block/aoe/aoeblk.c |   36 +-
 drivers/block/aoe/aoedev.c |  166 
 3 files changed, 146 insertions(+), 63 deletions(-)

diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index b6d2b16..d50e945 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -74,8 +74,11 @@ enum {
DEVFL_TKILL = (1<<1),   /* flag for timer to know when to kill self */
DEVFL_EXT = (1<<2), /* device accepts lba48 commands */
DEVFL_GDALLOC = (1<<3), /* need to alloc gendisk */
-   DEVFL_KICKME = (1<<4),  /* slow polling network card catch */
-   DEVFL_NEWSIZE = (1<<5), /* need to update dev size in block layer */
+   DEVFL_GD_NOW = (1<<4),  /* allocating gendisk */
+   DEVFL_KICKME = (1<<5),  /* slow polling network card catch */
+   DEVFL_NEWSIZE = (1<<6), /* need to update dev size in block layer */
+   DEVFL_FREEING = (1<<7), /* set when device is being cleaned up */
+   DEVFL_FREED = (1<<8),   /* device has been cleaned up */
 };
 
 enum {
diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
index 57ac72c..6b5b787 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -147,9 +147,18 @@ aoeblk_open(struct block_device *bdev, fmode_t mode)
struct aoedev *d = bdev->bd_disk->private_data;
ulong flags;
 
+   if (!virt_addr_valid(d)) {
+   pr_crit("aoe: invalid device pointer in %s\n",
+   __func__);
+   WARN_ON(1);
+   return -ENODEV;
+   }
+   if (!(d->flags & DEVFL_UP) || d->flags & DEVFL_TKILL)
+   return -ENODEV;
+
mutex_lock(_mutex);
spin_lock_irqsave(>lock, flags);
-   if (d->flags & DEVFL_UP) {
+   if (d->flags & DEVFL_UP && !(d->flags & DEVFL_TKILL)) {
d->nopen++;
spin_unlock_irqrestore(>lock, flags);
mutex_unlock(_mutex);
@@ -259,6 +268,18 @@ aoeblk_gdalloc(void *vp)
struct request_queue *q;
enum { KB = 1024, MB = KB * KB, READ_AHEAD = 2 * MB, };
ulong flags;
+   int late = 0;
+
+   spin_lock_irqsave(>lock, flags);
+   if (d->flags & DEVFL_GDALLOC
+   && !(d->flags & DEVFL_TKILL)
+   && !(d->flags & DEVFL_GD_NOW))
+   d->flags |= DEVFL_GD_NOW;
+   else
+   late = 1;
+   spin_unlock_irqrestore(>lock, flags);
+   if (late)
+   return;
 
gd = alloc_disk(AOE_PARTITIONS);
if (gd == NULL) {
@@ -282,6 +303,11 @@ aoeblk_gdalloc(void *vp)
}
 
spin_lock_irqsave(>lock, flags);
+   WARN_ON(!(d->flags & DEVFL_GD_NOW));
+   WARN_ON(!(d->flags & DEVFL_GDALLOC));
+   WARN_ON(d->flags & DEVFL_TKILL);
+   WARN_ON(d->gd);
+   WARN_ON(d->flags & DEVFL_UP);
blk_queue_max_hw_sectors(q, BLK_DEF_MAX_SECTORS);
q->backing_dev_info.name = "aoe";
q->backing_dev_info.ra_pages = READ_AHEAD / PAGE_CACHE_SIZE;
@@ -306,6 +332,11 @@ aoeblk_gdalloc(void *vp)
 
add_disk(gd);
aoedisk_add_sysfs(d);
+
+   spin_lock_irqsave(>lock, flags);
+   WARN_ON(!(d->flags & DEVFL_GD_NOW));
+   d->flags &= ~DEVFL_GD_NOW;
+   spin_unlock_irqrestore(>lock, flags);
return;
 
 err_mempool:
@@ -314,7 +345,8 @@ err_disk:
put_disk(gd);
 err:
spin_lock_irqsave(>lock, flags);
-   d->flags &= ~DEVFL_GDALLOC;
+   d->flags &= ~DEVFL_GD_NOW;
+   schedule_work(>work);
spin_unlock_irqrestore(>lock, flags);
 }
 
diff --git a/drivers/block/aoe/aoedev.c b/drivers/block/aoe/aoedev.c
index f0c0c74..3776715 100644
--- a/drivers/block/aoe/aoedev.c
+++ b/drivers/block/aoe/aoedev.c
@@ -15,7 +15,6 @@
 

[PATCH 1/7] aoe: improve handling of misbehaving network paths

2012-12-03 Thread Ed Cashin
An AoE target can have multiple network ports used for AoE, and
in the aoe driver, those are tracked by the aoetgt struct.  These
changes allow the aoe driver to handle network paths, or aoetgts,
that are not working well, compared to the others.

Paths that do not get responses despite the retransmission of AoE
commands are marked as "tainted", and non-tainted paths are
preferred.

Meanwhile, the aoe driver attempts to "probe" the tainted path in
the background by issuing reads of LBA 0 that are padded out to
full (possibly jumbo-frame) size.  If the probes get responses,
then the path is "redeemed", and its taint is removed.

This mechanism has been shown to be helpful in transparently
handling and recovering from real-world network "brown outs" in
ways that the earlier "shoot the help-needing target in the head"
mechanism could not.

Signed-off-by: Ed Cashin 
---
 drivers/block/aoe/aoe.h|   11 ++-
 drivers/block/aoe/aoecmd.c |  377 ++--
 drivers/block/aoe/aoedev.c |1 -
 3 files changed, 268 insertions(+), 121 deletions(-)

diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index bfd765c..b6d2b16 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -91,6 +91,9 @@ enum {
RTTDSCALE = 3,
RTTAVG_INIT = USEC_PER_SEC / 4 << RTTSCALE,
RTTDEV_INIT = RTTAVG_INIT / 4,
+
+   HARD_SCORN_SECS = 10,   /* try another remote port after this */
+   MAX_TAINT = 1000,   /* cap on aoetgt taint */
 };
 
 struct buf {
@@ -103,6 +106,10 @@ struct buf {
struct request *rq;
 };
 
+enum frame_flags {
+   FFL_PROBE = 1,
+};
+
 struct frame {
struct list_head head;
u32 tag;
@@ -118,6 +125,7 @@ struct frame {
struct bio_vec *bv;
ulong bcnt;
ulong bv_off;
+   char flags;
 };
 
 struct aoeif {
@@ -138,8 +146,10 @@ struct aoetgt {
ushort next_cwnd;   /* incr maxout after decrementing to zero */
ushort ssthresh;/* slow start threshold */
ulong falloc;   /* number of allocated frames */
+   int taint;  /* how much we want to avoid this aoetgt */
int minbcnt;
int wpkts, rpkts;
+   char nout_probes;
 };
 
 struct aoedev {
@@ -174,7 +184,6 @@ struct aoedev {
struct list_head rexmitq; /* deferred retransmissions */
struct aoetgt *targets[NTARGETS];
struct aoetgt **tgt;/* target in use when working */
-   struct aoetgt *htgt;/* target needing rexmit assistance */
ulong ntargets;
ulong kicked;
char ident[512];
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 391dd8e..000f7fb 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -22,6 +22,7 @@
 #define MAXIOC (8192)  /* default meant to avoid most soft lockups */
 
 static void ktcomplete(struct frame *, struct sk_buff *);
+static int count_targets(struct aoedev *d, int *untainted);
 
 static struct buf *nextbuf(struct aoedev *);
 
@@ -43,6 +44,8 @@ static struct {
spinlock_t lock;
 } iocq;
 
+static struct page *empty_page;
+
 static struct sk_buff *
 new_skb(ulong len)
 {
@@ -179,8 +182,10 @@ aoe_freetframe(struct frame *f)
 
t = f->t;
f->buf = NULL;
+   f->lba = 0;
f->bv = NULL;
f->r_skb = NULL;
+   f->flags = 0;
list_add(>head, >ffree);
 }
 
@@ -234,20 +239,25 @@ newframe(struct aoedev *d)
struct frame *f;
struct aoetgt *t, **tt;
int totout = 0;
+   int use_tainted;
+   int has_untainted;
 
if (d->targets[0] == NULL) {/* shouldn't happen, but I'm paranoid */
printk(KERN_ERR "aoe: NULL TARGETS!\n");
return NULL;
}
tt = d->tgt;/* last used target */
-   for (;;) {
+   for (use_tainted = 0, has_untainted = 0;;) {
tt++;
if (tt >= >targets[NTARGETS] || !*tt)
tt = d->targets;
t = *tt;
-   totout += t->nout;
+   if (!t->taint) {
+   has_untainted = 1;
+   totout += t->nout;
+   }
if (t->nout < t->maxout
-   && t != d->htgt
+   && (use_tainted || !t->taint)
&& t->ifp->nd) {
f = newtframe(d, t);
if (f) {
@@ -256,8 +266,12 @@ newframe(struct aoedev *d)
return f;
}
}
-   if (tt == d->tgt)   /* we've looped and found nada */
-   break;
+   if (tt == d->tgt) { /* we've looped and found nada */
+   if (!use_tainted && !has_untainted)
+   use_tainted = 1;
+   else
+   break;
+   }
}
if (totout == 0) {
  

[PATCH] X86/acpi: remove redundant logic of acpi memory hotadd

2012-12-03 Thread Liu, Jinsong
Resend it, add Rafael and linux-a...@vger.kernel.org

Thanks,
Jinsong

===
>From 1d39279e45c54ce531691da5ffe261e7689dd92c Mon Sep 17 00:00:00 2001
From: Liu Jinsong 
Date: Wed, 14 Nov 2012 18:52:06 +0800
Subject: [PATCH] X86/acpi: remove redundant logic of acpi memory hotadd

When memory hotadd, acpi_memory_enable_device has already been done
at drv->ops.add (acpi_memory_device_add), no need to do it again
at notify callback.

At acpi_memory_enable_device, acpi_memory_get_device_resources
is also a redundant action, since it has been done at drv->ops.add.

Signed-off-by: Liu Jinsong 
---
 drivers/acpi/acpi_memhotplug.c |   17 -
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 24c807f..a6489fd 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -220,15 +220,6 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
struct acpi_memory_info *info;
int node;
 
-
-   /* Get the range from the _CRS */
-   result = acpi_memory_get_device_resources(mem_device);
-   if (result) {
-   printk(KERN_ERR PREFIX "get_device_resources failed\n");
-   mem_device->state = MEMORY_INVALID_STATE;
-   return result;
-   }
-
node = acpi_get_node(mem_device->device->handle);
/*
 * Tell the VM there is more memory here...
@@ -357,14 +348,6 @@ static void acpi_memory_device_notify(acpi_handle handle, 
u32 event, void *data)
break;
}
 
-   if (acpi_memory_check_device(mem_device))
-   break;
-
-   if (acpi_memory_enable_device(mem_device)) {
-   printk(KERN_ERR PREFIX "Cannot enable memory device\n");
-   break;
-   }
-
ost_code = ACPI_OST_SC_SUCCESS;
break;
 
-- 
1.7.1


0001-X86-acpi-remove-redundant-logic-of-acpi-memory-hotad.patch
Description: 0001-X86-acpi-remove-redundant-logic-of-acpi-memory-hotad.patch


[PATCH 0/7] aoe: driver improvements and fixes through v81

2012-12-03 Thread Ed Cashin
This patch series applies to today's linux-next/akpm, commit
a5944abc848a1b8e5329a631a84e35a3b0249ecb.

Ed L. Cashin (7):
  aoe: improve handling of misbehaving network paths
  aoe: avoid races between device destruction and discovery
  aoe: use dynamic number of remote ports for AoE storage target
  aoe: allow user to disable target failure timeout
  aoe: allow comma separator in aoe_iflist value
  aoe: identify source of runt AoE packets
  aoe: update internal version number to 81

 Documentation/aoe/aoe.txt  |4 +-
 drivers/block/aoe/aoe.h|   29 ++-
 drivers/block/aoe/aoeblk.c |   38 -
 drivers/block/aoe/aoecmd.c |  439 ++--
 drivers/block/aoe/aoedev.c |  177 --
 drivers/block/aoe/aoenet.c |2 +-
 6 files changed, 477 insertions(+), 212 deletions(-)

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


Re: [PATCH] clk: factor: calculate rate by do_div

2012-12-03 Thread Haojian Zhuang
On Mon, Dec 3, 2012 at 4:14 PM, Haojian Zhuang  wrote:
> clk->rate = parent->rate / div * mult
>
> The formula is OK. But it may overflow while we do operate with
> unsigned long. So use do_div instead.
>
> Signed-off-by: Haojian Zhuang 
> ---
>  drivers/clk/clk-fixed-factor.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> index a489985..1ef271e 100644
> --- a/drivers/clk/clk-fixed-factor.c
> +++ b/drivers/clk/clk-fixed-factor.c
> @@ -28,8 +28,11 @@ static unsigned long clk_factor_recalc_rate(struct clk_hw 
> *hw,
> unsigned long parent_rate)
>  {
> struct clk_fixed_factor *fix = to_clk_fixed_factor(hw);
> +   unsigned long long int rate;
>
> -   return parent_rate * fix->mult / fix->div;
> +   rate = (unsigned long long int)parent_rate * fix->mult;
> +   do_div(rate, fix->div);
> +   return (unsigned long)rate;
>  }
>
>  static long clk_factor_round_rate(struct clk_hw *hw, unsigned long rate,
> --
> 1.7.10.4
>

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


[PATCH] staging: echo: remove unused variable

2012-12-03 Thread Cong Ding
the variable j isn't used in the loop

Signed-off-by: Cong Ding 
---
 drivers/staging/echo/echo.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/echo/echo.c b/drivers/staging/echo/echo.c
index ca87ce9..14dfd91 100644
--- a/drivers/staging/echo/echo.c
+++ b/drivers/staging/echo/echo.c
@@ -119,7 +119,6 @@
 static inline void lms_adapt_bg(struct oslec_state *ec, int clean, int shift)
 {
int i;
-   int j;
int offset1;
int offset2;
int factor;
@@ -142,7 +141,7 @@ static inline void lms_adapt_bg(struct oslec_state *ec, int 
clean, int shift)
 
/* asm("st:"); */
n = ec->taps;
-   for (i = 0, j = offset2; i < n; i++, j++) {
+   for (i = 0; i < n; i++) {
exp = *phist++ * factor;
ec->fir_taps16[1][i] += (int16_t) ((exp + (1 << 14)) >> 15);
}
-- 
1.7.4.5

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


Re: [RFT PATCH v2 4/5] mm: provide more accurate estimation of pages occupied by memmap

2012-12-03 Thread Jiang Liu
On 2012-12-4 7:17, Andrew Morton wrote:
> On Sun, 02 Dec 2012 19:55:09 +
> Chris Clayton  wrote:
> 
>>
>>
>> On 11/29/12 10:52, Chris Clayton wrote:
>>> On 11/28/12 23:52, Andrew Morton wrote:
 On Wed, 21 Nov 2012 23:09:46 +0800
 Jiang Liu  wrote:

> Subject: Re: [RFT PATCH v2 4/5] mm: provide more accurate estimation
> of pages occupied by memmap

 How are people to test this?  "does it boot"?

>>>
>>> I've been running kernels with Gerry's 5 patches applied for 11 days
>>> now. This is on a 64bit laptop but with a 32bit kernel + HIGHMEM. I
>>> joined the conversation because my laptop would not resume from suspend
>>> to disk - it either froze or rebooted. With the patches applied the
>>> laptop does successfully resume and has been stable.
>>>
>>> Since Monday, I have have been running a kernel with the patches (plus,
>>> from today, the patch you mailed yesterday) applied to 3.7rc7, without
>>> problems.
>>>
>>
>> I've been running 3.7-rc7 with the patches listed below for a week now 
>> and it has been perfectly stable. In particular, my laptop will now 
>> successfully resume from suspend to disk, which always failed without 
>> the patches.
>>
>>  From Jiang Liu:
>> 1. [RFT PATCH v2 1/5] mm: introduce new field "managed_pages" to struct zone
>> 2. [RFT PATCH v1 2/5] mm: replace zone->present_pages with 
>> zone->managed_pages if appreciated
>> 3. [RFT PATCH v1 3/5] mm: set zone->present_pages to number of existing 
>> pages in the zone
>> 4. [RFT PATCH v2 4/5] mm: provide more accurate estimation of pages 
>> occupied by memmap
>> 5. [RFT PATCH v1 5/5] mm: increase totalram_pages when free pages 
>> allocated by bootmem allocator
>>
>>  From Andrew Morton:
>> 6. mm-provide-more-accurate-estimation-of-pages-occupied-by-memmap.patch
>>
>> Tested-by: Chris Clayton 
> 
> Thanks.
> 
> I have only two of these five patches queued for 3.8:
> mm-introduce-new-field-managed_pages-to-struct-zone.patch and
> mm-provide-more-accurate-estimation-of-pages-occupied-by-memmap.patch. 
> I don't recall what happened with the other three.

Hi Andrew,
I think the story that,
1) I sent out all five patches for the first version.
2) Later updated and resend the first and forth patches according to 
   review comments without touching the other three patches.
So you may just get the updated two without noticing the other
three from the initial patchset.
Sorry for the trouble.
Regards!
Gerry

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


Re: [PATCH v4 1/2] leds/tca6507: Add support for devicetree.

2012-12-03 Thread Bryan Wu
Looks like this patch is based on linux-next tree, I fixed this. And I
will solve the conflict when we do actually merge in next cycle.

-Bryan

On Fri, Nov 30, 2012 at 2:00 PM, Marek Belisko
 wrote:
> Support added only for leds (not for gpio's).
>
> Signed-off-by: Marek Belisko 
> ---
> Changes from v3:
> - fix code according Bryan suggestions
> - use common leds binding description instead copy'n'paste
> - use "-" instead "_" in bindings example for leds names
>
> Changes from v2:
> - change compatible property to "ti,tca6507"
> - add documentation for linux,default-trigger
>
> Changes from v1:
> - return proper error value not NULL from tca6507_led_dt_init()
> - remove empty lines
> - remove kfree()
>  drivers/leds/leds-tca6507.c |   74 
> +--
>  1 file changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c
> index b26a63b..3ad46fb 100644
> --- a/drivers/leds/leds-tca6507.c
> +++ b/drivers/leds/leds-tca6507.c
> @@ -667,6 +667,70 @@ static void tca6507_remove_gpio(struct tca6507_chip *tca)
>  }
>  #endif /* CONFIG_GPIOLIB */
>
> +#ifdef CONFIG_OF
> +static struct tca6507_platform_data *
> +tca6507_led_dt_init(struct i2c_client *client)
> +{
> +   struct device_node *np = client->dev.of_node, *child;
> +   struct tca6507_platform_data *pdata;
> +   struct led_info *tca_leds;
> +   int count = 0;
> +
> +   for_each_child_of_node(np, child)
> +   count++;
> +   if (!count)
> +   return ERR_PTR(-ENODEV);
> +
> +   if (count > NUM_LEDS)
> +   return ERR_PTR(-ENODEV);
> +
> +   tca_leds = devm_kzalloc(>dev,
> +   sizeof(struct led_info) * count, GFP_KERNEL);
> +   if (!tca_leds)
> +   return ERR_PTR(-ENOMEM);
> +
> +   for_each_child_of_node(np, child) {
> +   struct led_info led;
> +   u32 reg;
> +   int ret;
> +
> +   led.name =
> +   of_get_property(child, "label", NULL) ? : child->name;
> +   led.default_trigger =
> +   of_get_property(child, "linux,default-trigger", NULL);
> +
> +   ret = of_property_read_u32(child, "reg", );
> +   if (ret != 0)
> +   continue;
> +
> +   tca_leds[reg] = led;
> +   }
> +   pdata = devm_kzalloc(>dev,
> +   sizeof(struct tca6507_platform_data), GFP_KERNEL);
> +   if (!pdata)
> +   return ERR_PTR(-ENOMEM);
> +
> +   pdata->leds.leds = tca_leds;
> +   pdata->leds.num_leds = count;
> +
> +   return pdata;
> +}
> +
> +static const struct of_device_id of_tca6507_leds_match[] = {
> +   { .compatible = "ti,tca6507", },
> +   {},
> +};
> +
> +#else
> +static tca6507_platform_data *
> +tca6507_led_dt_init(struct i2c_client *client)
> +{
> +   return ERR_PRT(-ENODEV);
> +}
> +
> +#define of_tca6507_leds_match NULL
> +#endif
> +
>  static int tca6507_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
>  {
> @@ -683,9 +747,12 @@ static int tca6507_probe(struct i2c_client *client,
> return -EIO;
>
> if (!pdata || pdata->leds.num_leds != NUM_LEDS) {
> -   dev_err(>dev, "Need %d entries in platform-data 
> list\n",
> -   NUM_LEDS);
> -   return -ENODEV;
> +   pdata = tca6507_led_dt_init(client);
> +   if (IS_ERR(pdata)) {
> +   dev_err(>dev, "Need %d entries in 
> platform-data list\n",
> +   NUM_LEDS);
> +   return PTR_ERR(pdata);
> +   }
> }
> tca = devm_kzalloc(>dev, sizeof(*tca), GFP_KERNEL);
> if (!tca)
> @@ -750,6 +817,7 @@ static struct i2c_driver tca6507_driver = {
> .driver   = {
> .name= "leds-tca6507",
> .owner   = THIS_MODULE,
> +   .of_match_table = of_tca6507_leds_match,
> },
> .probe= tca6507_probe,
> .remove   = tca6507_remove,
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC v2] Support volatile range for anon vma

2012-12-03 Thread John Stultz

On 12/03/2012 04:00 PM, Minchan Kim wrote:

On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote:

On 11/21/2012 04:36 PM, John Stultz wrote:

2) Being able to use this with tmpfs files. I'm currently trying
to better understand the rmap code, looking to see if there's a
way to have try_to_unmap_file() work similarly to
try_to_unmap_anon(), to allow allow users to madvise() on mmapped
tmpfs files. This would provide a very similar interface as to
what I've been proposing with fadvise/fallocate, but just using
process virtual addresses instead of (fd, offset) pairs.   The
benefit with (fd,offset) pairs for Android is that its easier to
manage shared volatile ranges between two processes that are
sharing data via an mmapped tmpfs file (although this actual use
case may be fairly rare).  I believe we should still be able to
rework the ashmem internals to use madvise (which would provide
legacy support for existing android apps), so then its just a
question of if we could then eventually convince Android apps to
use the madvise interface directly, rather then the ashmem unpin
ioctl.

Hey Minchan,
 I've been playing around with your patch trying to better
understand your approach and to extend it to support tmpfs files. In
doing so I've found a few bugs, and have some rough fixes I wanted
to share. There's still a few edge cases I need to deal with (the
vma-purged flag isn't being properly handled through vma merge/split
operations), but its starting to come along.

Hmm, my patch doesn't allow to merge volatile with another one by
inserting VM_VOLATILE into VM_SPECIAL so I guess merge isn't problem.
In case of split, __split_vma copy old vma to new vma like this

 *new = *vma;

So the problem shouldn't happen, I guess.
Did you see the real problem about that?
Yes, depending on the pattern that MADV_VOLATILE and MADV_NOVOLATILE is 
applied, we can get a result where data is purged, but we aren't 
notified of it.  Also, since madvise returns early if it encounters an 
error, in the case where you have checkerboard volatile regions (say 
every other page is volatile), which you mark non-volatile with one 
large MADV_NOVOLATILE call, the first volatile vma will be marked 
non-volatile, but since it returns purged, the madvise loop will stop 
and the following volatile regions will be left volatile.


The patches in the git tree below which handle the perged state better 
seem to work for my tests, as far as resolving any overlapping calls. Of 
course there may yet still be problems I've not found.



Anyway, take a look at the tree here and let me know what you think.
http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/minchan-anonvol


Eager to hear what you think!

Thanks again!
-john

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


[patch] mm, mempolicy: Introduce spinlock to read shared policy tree

2012-12-03 Thread David Rientjes
From: Peter Zijlstra 

Sasha was fuzzing with trinity and reported the following problem:

BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 6361, name: trinity-main
2 locks held by trinity-main/6361:
 #0:  (>mmap_sem){++}, at: [] 
__do_page_fault+0x1e4/0x4f0
 #1:  (&(>page_table_lock)->rlock){+.+...}, at: [] 
handle_pte_fault+0x3f7/0x6a0
Pid: 6361, comm: trinity-main Tainted: GW 
3.7.0-rc2-next-20121024-sasha-1-gd95ef01-dirty #74
Call Trace:
 [] __might_sleep+0x1c3/0x1e0
 [] mutex_lock_nested+0x29/0x50
 [] mpol_shared_policy_lookup+0x2e/0x90
 [] shmem_get_policy+0x2e/0x30
 [] get_vma_policy+0x5a/0xa0
 [] mpol_misplaced+0x41/0x1d0
 [] handle_pte_fault+0x465/0x6a0

do_numa_page() calls the new mpol_misplaced() function introduced by 
"sched, numa, mm: Add the scanning page fault machinery" in the page fault 
patch while holding mm->page_table_lock and then 
mpol_shared_policy_lookup() ends up trying to take the shared policy 
mutex.

The fix is to protect the shared policy tree with both a spinlock and 
mutex; both must be held to modify the tree, but only one is required to 
read the tree.  This allows sp_lookup() to grab the spinlock for read.

[rient...@google.com: wrote changelog]
Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: David Rientjes 
---
 include/linux/mempolicy.h |1 +
 mm/mempolicy.c|   23 ++-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -133,6 +133,7 @@ struct sp_node {
 
 struct shared_policy {
struct rb_root root;
+   spinlock_t lock;
struct mutex mutex;
 };
 
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2090,12 +2090,20 @@ bool __mpol_equal(struct mempolicy *a, struct mempolicy 
*b)
  *
  * Remember policies even when nobody has shared memory mapped.
  * The policies are kept in Red-Black tree linked from the inode.
- * They are protected by the sp->lock spinlock, which should be held
- * for any accesses to the tree.
+ *
+ * The rb-tree is locked using both a mutex and a spinlock. Every modification
+ * to the tree must hold both the mutex and the spinlock, lookups can hold
+ * either to observe a stable tree.
+ *
+ * In particular, sp_insert() and sp_delete() take the spinlock, whereas
+ * sp_lookup() doesn't, this so users have choice.
+ *
+ * shared_policy_replace() and mpol_free_shared_policy() take the mutex
+ * and call sp_insert(), sp_delete().
  */
 
 /* lookup first element intersecting start-end */
-/* Caller holds sp->mutex */
+/* Caller holds either sp->lock and/or sp->mutex */
 static struct sp_node *
 sp_lookup(struct shared_policy *sp, unsigned long start, unsigned long end)
 {
@@ -2134,6 +2142,7 @@ static void sp_insert(struct shared_policy *sp, struct 
sp_node *new)
struct rb_node *parent = NULL;
struct sp_node *nd;
 
+   spin_lock(>lock);
while (*p) {
parent = *p;
nd = rb_entry(parent, struct sp_node, nd);
@@ -2146,6 +2155,7 @@ static void sp_insert(struct shared_policy *sp, struct 
sp_node *new)
}
rb_link_node(>nd, parent, p);
rb_insert_color(>nd, >root);
+   spin_unlock(>lock);
pr_debug("inserting %lx-%lx: %d\n", new->start, new->end,
 new->policy ? new->policy->mode : 0);
 }
@@ -2159,13 +2169,13 @@ mpol_shared_policy_lookup(struct shared_policy *sp, 
unsigned long idx)
 
if (!sp->root.rb_node)
return NULL;
-   mutex_lock(>mutex);
+   spin_lock(>lock);
sn = sp_lookup(sp, idx, idx+1);
if (sn) {
mpol_get(sn->policy);
pol = sn->policy;
}
-   mutex_unlock(>mutex);
+   spin_unlock(>lock);
return pol;
 }
 
@@ -2178,8 +2188,10 @@ static void sp_free(struct sp_node *n)
 static void sp_delete(struct shared_policy *sp, struct sp_node *n)
 {
pr_debug("deleting %lx-l%lx\n", n->start, n->end);
+   spin_lock(>lock);
rb_erase(>nd, >root);
sp_free(n);
+   spin_unlock(>lock);
 }
 
 static struct sp_node *sp_alloc(unsigned long start, unsigned long end,
@@ -2264,6 +2276,7 @@ void mpol_shared_policy_init(struct shared_policy *sp, 
struct mempolicy *mpol)
int ret;
 
sp->root = RB_ROOT; /* empty tree == default mempolicy */
+   spin_lock_init(>lock);
mutex_init(>mutex);
 
if (mpol) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] block: Restore /proc/partitions to not display non-partitionable removable devices

2012-12-03 Thread Andrew Morton
On Mon, 03 Dec 2012 18:40:32 -0600
Josh Hunt  wrote:

> On 12/03/2012 06:06 PM, Andrew Morton wrote:
> > On Mon, 19 Nov 2012 18:56:49 -0800
> > Josh Hunt  wrote:
> >
> >> We found with newer kernels we started seeing the cdrom device showing
> >> up in /proc/partitions, but it was not there before. Looking into this I 
> >> found
> >> that commit d27769ec... block: add GENHD_FL_NO_PART_SCAN introduces this 
> >> change
> >> in behavior. It's not clear to me from the commit's changelog if this 
> >> change was
> >> intentional or not. This comment still remains:
> >> /* Don't show non-partitionable removeable devices or empty devices */
> >> so I've decided to send a patch to restore the behavior of not printing
> >> unpartitionable removable devices.
> >
> > d27769ec was merged in August 2011, so I after all this time, your fix
> > could be viewed as "changing existing behaviour".
> >
> > So perhaps it would be best to leave things alone.  Is there any
> > particular problem with the post-Aug, 2011 behaviour?
> >
> 
> We caught this by a script that parses /proc/partitions and made some 
> assumptions about the contents therein. It had worked fine up until when 
> this behavior changed. We were able to modify our script to get what we 
> needed.
> 
> The patch was meant to do two things: 1) understand if this was an 
> unintended change and 2) if so, propose a solution to resolve it. Since 
> the comment was left in the source I believe either a) my patch should 
> be applied or b) a new patch with the comment removed should be put in 
> since it's no longer correct. I did not think this type of change to 
> kernel abi was generally acceptable.
> 
> While the commit is over a year old, it changes behavior which had been 
> in tact for a while (years?) from what I can tell. We were running 3.0 
> with stable updates until we upgraded to 3.2 and hit this. Neither of 
> these are what I would consider "old" kernels.
> 

Yes, this is difficult.  Removing existing entries is more likely to
cause damage than adding new ones, so I suspect the safest approach is
to just leave things as they now are.

In which case yes, we should repair that comment.  ie: change it to a
comment which explains *why* we display removable devices.  Unlike the
existing comment which tells us "what" but not "why", when "why" is
what we wanted to know, sigh.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-03 Thread Andrew Morton
On Mon, 3 Dec 2012 16:35:01 -0800
Michel Lespinasse  wrote:

> On Mon, Dec 3, 2012 at 3:01 PM, Andrew Morton  
> wrote:
> > On Fri, 30 Nov 2012 22:56:27 -0800
> > Michel Lespinasse  wrote:
> >
> >> expand_stack() runs with a shared mmap_sem lock. Because of this, there
> >> could be multiple concurrent stack expansions in the same mm, which may
> >> cause problems in the vma gap update code.
> >>
> >> I propose to solve this by taking the mm->page_table_lock around such vma
> >> expansions, in order to avoid the concurrency issue. We only have to worry
> >> about concurrent expand_stack() calls here, since we hold a shared mmap_sem
> >> lock and all vma modificaitons other than expand_stack() are done under
> >> an exclusive mmap_sem lock.
> >>
> >> I previously tried to achieve the same effect by making sure all
> >> growable vmas in a given mm would share the same anon_vma, which we
> >> already lock here. However this turned out to be difficult - all of the
> >> schemes I tried for refcounting the growable anon_vma and clearing
> >> turned out ugly. So, I'm now proposing only the minimal fix.
> >
> > I think I don't understand the problem fully.  Let me demonstrate:
> >
> > a) vma_lock_anon_vma() doesn't take a lock which is specific to
> >"this" anon_vma.  It takes anon_vma->root->mutex.  That mutex is
> >shared with vma->vm_next, yes?  If so, we have no problem here?
> >(which makes me suspect that the races lies other than where I think
> >it lies).
> 
> So, the first thing I need to mention is that this fix is NOT for any
> problem that has been reported (and in particular, not for Sasha's
> trinity fuzzing issue). It's just me looking at the code and noticing
> I haven't gotten locking right for the case of concurrent stack
> expansion.
> 
> Regarding vma and vma->vm_next sharing the same root anon_vma mutex -
> this will often be the case, but not always. find_mergeable_anon_vma()
> will try to make it so, but it could fail if there was another vma
> in-between at the time the stack's anon_vmas got assigned (either a
> non-stack vma that later gets unmapped, or another stack vma that
> didn't get its own anon_vma assigned yet).
> 
> > b) I can see why a broader lock is needed in expand_upwards(): it
> >plays with a different vma: vma->vm_next.  But expand_downwards()
> >doesn't do that - it only alters "this" vma.  So I'd have thought
> >that vma_lock_anon_vma("this" vma) would be sufficient.
> 
> The issue there is that vma_gap_update() accesses vma->vm_prev, so the
> issue is actually symetrical with expand_upwards().
> 
> > What are the performance costs of this change?
> 
> It's expected to be small. glibc doesn't use expandable stacks for the
> threads it creates, so having multiple growable stacks is actually
> uncommon (another reason why the problem hasn't been observed in
> practice). Because of this, I don't expect the page table lock to get
> bounced between threads, so the cost of taking it should be small
> (compared to the cost of delivering the #PF, let alone handling it in
> software).
> 
> But yes, the initial idea of forcing all growable vmas in an mm to
> share the same root anon_vma sounded much more appealing at first.
> Unfortunately I haven't been able to make that work in a simple enough
> way to be comfortable submitting it this late in the release cycle :/

hm, OK.  Could you please cook up a new changelog which explains these
things to the next puzzled reader and send it along?

Ingo is playing in the same area with "mm/rmap: Convert the struct
anon_vma::mutex to an rwsem", but as that patch changes
vma_lock_anon_vma() to use down_write(), I expect it won't affect
anything.  But please check it over.

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


  1   2   3   4   5   6   7   8   9   10   >