[PATCH] staging: nokia_h4: nokia_core.c: use usleep_range() instead of msleep()

[Miguel Oliveira]

Creating this patch for the Eudyptula Challenge.
Replaced msleep() for a delay < 20ms with a usleep_range() between 1us and 
15000us.
Also inserted a blank line after adeclaration.

Signed-off-by: Miguel Oliveira 
---
 drivers/staging/nokia_h4p/nokia_core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/nokia_h4p/nokia_core.c 
b/drivers/staging/nokia_h4p/nokia_core.c
index 5e19cd6..ba0506d 100644
--- a/drivers/staging/nokia_h4p/nokia_core.c
+++ b/drivers/staging/nokia_h4p/nokia_core.c
@@ -724,7 +724,7 @@ static int hci_h4p_reset(struct hci_h4p_info *info)

gpio_set_value(info->reset_gpio, 0);
gpio_set_value(info->bt_wakeup_gpio, 1);
-   msleep(10);
+   usleep_range(1, 15000);

if (gpio_get_value(info->host_wakeup_gpio) == 1) {
dev_err(info->dev, "host_wakeup_gpio not low\n");
@@ -756,6 +756,7 @@ static int hci_h4p_reset(struct hci_h4p_info *info)
static int hci_h4p_hci_flush(struct hci_dev *hdev)
{
struct hci_h4p_info *info = hci_get_drvdata(hdev);
+
skb_queue_purge(>txq);

return 0;
--
1.7.10.4

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

[PATCH 1/1] mfd: asic3: Fix potential null pointer dereference

[Sachin Kamat]

We previously assumed 'mem_sdio' could be null but it is
dereferenced in ioremap(). Add a check to avoid a potential
null pointer dereference error.

Signed-off-by: Sachin Kamat 
---
 drivers/mfd/asic3.c |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
index 9f6294f2a070..9fc4186d4132 100644
--- a/drivers/mfd/asic3.c
+++ b/drivers/mfd/asic3.c
@@ -899,13 +899,15 @@ static int __init asic3_mfd_probe(struct platform_device 
*pdev,
ds1wm_resources[0].end   >>= asic->bus_shift;
 
/* MMC */
-   asic->tmio_cnf = ioremap((ASIC3_SD_CONFIG_BASE >> asic->bus_shift) +
+   if (mem_sdio) {
+   asic->tmio_cnf = ioremap((ASIC3_SD_CONFIG_BASE >> 
asic->bus_shift) +
 mem_sdio->start,
 ASIC3_SD_CONFIG_SIZE >> asic->bus_shift);
-   if (!asic->tmio_cnf) {
-   ret = -ENOMEM;
-   dev_dbg(asic->dev, "Couldn't ioremap SD_CONFIG\n");
-   goto out;
+   if (!asic->tmio_cnf) {
+   ret = -ENOMEM;
+   dev_dbg(asic->dev, "Couldn't ioremap SD_CONFIG\n");
+   goto out;
+   }
}
asic3_mmc_resources[0].start >>= asic->bus_shift;
asic3_mmc_resources[0].end   >>= asic->bus_shift;
-- 
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 5/7 v6] trace, RAS: Add eMCA trace event interface

[Borislav Petkov]

On Fri, May 30, 2014 at 05:22:32AM -0400, Chen, Gong wrote:
> We have two big chunk string. One for memory error location, the other
> for DIMM error location. Since DIMM error location depends on some
> other conditions, how about just converting memory error location to a
> compact mode but leaving DIMM error location alone?

Please elaborate, what conditions? DIMM silk screen labels or so? Maybe
we can generate a mapping between text labels and indices and we can
dump the indices in the tracepoint and do the mapping back to strings in
userspace...?

> For memory error location, I will utilize type offset to save one
> more byte, furthermore, I want to drop requestor_id, responder_id
> and target_id. 1) They are very rare (I've never seen them by now)

My concern is, are we sure we're never going to need them at all? Tony,
what's your take on this?

> 2) They are u64 but not u16. So to keep whole struct clean I want
> to use following struct. We can extend it later when necessary.
> 
> struct __attribute__((__packed__)) cper_sec_mem_rec {
>   u8 type;
>   u16 data;
> };
> 
> So whole struct is just 3 bytes. Even if all fields are valid, we
> have 3 * 9 = 27 bytes in total for a record in the ring buffer.
> 
> Make sense?

That is definitely much better than what we have now.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] MAINTAINERS: Update Eduardo Valentin's email address

[Lee Jones]

Eduardo TI address is bouncing, but it looks like he's still
contributing via his Gmail address.

Cc: Eduardo Valentin 
Signed-off-by: Lee Jones 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6dc67b1..a9dc15b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8850,7 +8850,7 @@ F:drivers/media/radio/radio-raremono.c
 
 THERMAL
 M: Zhang Rui 
-M: Eduardo Valentin 
+M: Eduardo Valentin 
 L: linux...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
@@ -8877,7 +8877,7 @@ S:Maintained
 F: drivers/platform/x86/thinkpad_acpi.c
 
 TI BANDGAP AND THERMAL DRIVER
-M: Eduardo Valentin 
+M: Eduardo Valentin 
 L: linux...@vger.kernel.org
 S: Supported
 F: drivers/thermal/ti-soc-thermal/
-- 
1.8.3.2

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

Re: [PATCH tty-next] serial: sirf: Fix compilation failure

[Barry Song]

2014-05-30 2:25 GMT+08:00 Greg Kroah-Hartman :
> On Thu, May 29, 2014 at 08:14:02PM +0800, Barry Song wrote:
>> 2014-05-29 18:13 GMT+08:00 Daniel Thompson :
>> > After 07d410e0) serial: sirf: fix spinlock deadlock issue it is no longer
>> > possiblet to compile this driver. The rename of one of the spinlocks is
>> > faulty. After looking at the original patch I believe this is the correct
>> > fix.
>> >
>> > Compile tested using ARM's multi_v7_defconfig
>> >
>> > Cc: Greg Kroah-Hartman 
>> > Cc: Jiri Slaby 
>> > Cc: Barry Song 
>> > Cc: Qipan Li 
>> > Cc: linux-ser...@vger.kernel.org
>> > Signed-off-by: Daniel Thompson 
>>
>> Qipan prepared a same patch to fix this.
>
> Why didn't he send it?

it is not that he didn't want to send, it is because Daniel has sent
the same patch earlier.

>

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

Re: serial console does not wake from S3 suspend

[Valerio Vanni]

When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints a
text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with "cat txtfile > /dev/ttyS0").

Full details are here:
https://bugzilla.kernel.org/show_bug.cgi?id=69751


The problem is still present in 3.14.4, 3.15-rc7 and today's next.

I hope someone is going to look at this bug.

--
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 09/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.

[Srinivas Kandagatla]

On 30/05/14 10:55, Ulf Hansson wrote:

On 28 May 2014 15:47,   wrote:

From: Srinivas Kandagatla 

This patch adds specifics of clk and datactrl register on Qualcomm SD
Card controller. This patch also populates the Qcom variant data with
these new values specific to Qualcomm SD Card Controller.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Linus Walleij 
---
  drivers/mmc/host/mmci.c |  4 
  drivers/mmc/host/mmci.h | 17 +
  2 files changed, 21 insertions(+)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 8deea4a..dbcb952 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -179,6 +179,10 @@ static struct variant_data variant_qcom = {
 .fifosize   = 16 * 4,
 .fifohalfsize   = 8 * 4,
 .clkreg = MCI_CLK_ENABLE,
+   .clkreg_enable  = MCI_QCOM_CLK_FLOWENA |
+ MCI_QCOM_CLK_SELECT_IN_FBCLK,
+   .clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
+   .datactrl_mask_ddrmode  = MCI_QCOM_CLK_SELECT_IN_DDR_MODE,


This stuff should go in patch3.


Yes, I will merge patch3 and this change-set in next version.




 .blksz_datactrl4= true,
 .datalength_bits= 24,
 .pwrreg_powerup = MCI_PWR_UP,
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index cd83ca3..706eb513 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -41,6 +41,15 @@
  /* Modified PL180 on Versatile Express platform */
  #define MCI_ARM_HWFCEN BIT(12)

+/* Modified on Qualcomm Integrations */
+#define MCI_QCOM_CLK_WIDEBUS_8 (BIT(10) | BIT(11))
+#define MCI_QCOM_CLK_FLOWENA   BIT(12)
+#define MCI_QCOM_CLK_INVERTOUT BIT(13)
+
+/* select in latch data and command in */
+#define MCI_QCOM_CLK_SELECT_IN_FBCLK   BIT(15)
+#define MCI_QCOM_CLK_SELECT_IN_DDR_MODE(BIT(14) | BIT(15))
+
  #define MMCIARGUMENT   0x008
  #define MMCICOMMAND0x00c
  #define MCI_CPSM_RESPONSE  BIT(6)
@@ -54,6 +63,14 @@
  #define MCI_ST_NIENBIT(13)
  #define MCI_ST_CE_ATACMD   BIT(14)

+/* Modified on Qualcomm Integrations */
+#define MCI_QCOM_CSPM_DATCMD   BIT(12)
+#define MCI_QCOM_CSPM_MCIABORT BIT(13)
+#define MCI_QCOM_CSPM_CCSENABLEBIT(14)
+#define MCI_QCOM_CSPM_CCSDISABLE   BIT(15)
+#define MCI_QCOM_CSPM_AUTO_CMD19   BIT(16)
+#define MCI_QCOM_CSPM_AUTO_CMD21   BIT(21)
+


Maybe you should have one patch in the beginning of the patchset, that
adds all the new QCOM bits in the header file? Instead of splitting
them up?

Ok, I will do that in next version.

Thanks,
srini



  #define MMCIRESPCMD0x010
  #define MMCIRESPONSE0  0x014
  #define MMCIRESPONSE1  0x018
--
1.9.1



Kind regards
Ulf Hansson


--
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 09/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.

[Ulf Hansson]

On 28 May 2014 15:47,   wrote:
> From: Srinivas Kandagatla 
>
> This patch adds specifics of clk and datactrl register on Qualcomm SD
> Card controller. This patch also populates the Qcom variant data with
> these new values specific to Qualcomm SD Card Controller.
>
> Signed-off-by: Srinivas Kandagatla 
> Reviewed-by: Linus Walleij 
> ---
>  drivers/mmc/host/mmci.c |  4 
>  drivers/mmc/host/mmci.h | 17 +
>  2 files changed, 21 insertions(+)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 8deea4a..dbcb952 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -179,6 +179,10 @@ static struct variant_data variant_qcom = {
> .fifosize   = 16 * 4,
> .fifohalfsize   = 8 * 4,
> .clkreg = MCI_CLK_ENABLE,
> +   .clkreg_enable  = MCI_QCOM_CLK_FLOWENA |
> + MCI_QCOM_CLK_SELECT_IN_FBCLK,
> +   .clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
> +   .datactrl_mask_ddrmode  = MCI_QCOM_CLK_SELECT_IN_DDR_MODE,

This stuff should go in patch3.

> .blksz_datactrl4= true,
> .datalength_bits= 24,
> .pwrreg_powerup = MCI_PWR_UP,
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index cd83ca3..706eb513 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -41,6 +41,15 @@
>  /* Modified PL180 on Versatile Express platform */
>  #define MCI_ARM_HWFCEN BIT(12)
>
> +/* Modified on Qualcomm Integrations */
> +#define MCI_QCOM_CLK_WIDEBUS_8 (BIT(10) | BIT(11))
> +#define MCI_QCOM_CLK_FLOWENA   BIT(12)
> +#define MCI_QCOM_CLK_INVERTOUT BIT(13)
> +
> +/* select in latch data and command in */
> +#define MCI_QCOM_CLK_SELECT_IN_FBCLK   BIT(15)
> +#define MCI_QCOM_CLK_SELECT_IN_DDR_MODE(BIT(14) | BIT(15))
> +
>  #define MMCIARGUMENT   0x008
>  #define MMCICOMMAND0x00c
>  #define MCI_CPSM_RESPONSE  BIT(6)
> @@ -54,6 +63,14 @@
>  #define MCI_ST_NIENBIT(13)
>  #define MCI_ST_CE_ATACMD   BIT(14)
>
> +/* Modified on Qualcomm Integrations */
> +#define MCI_QCOM_CSPM_DATCMD   BIT(12)
> +#define MCI_QCOM_CSPM_MCIABORT BIT(13)
> +#define MCI_QCOM_CSPM_CCSENABLEBIT(14)
> +#define MCI_QCOM_CSPM_CCSDISABLE   BIT(15)
> +#define MCI_QCOM_CSPM_AUTO_CMD19   BIT(16)
> +#define MCI_QCOM_CSPM_AUTO_CMD21   BIT(21)
> +

Maybe you should have one patch in the beginning of the patchset, that
adds all the new QCOM bits in the header file? Instead of splitting
them up?

>  #define MMCIRESPCMD0x010
>  #define MMCIRESPONSE0  0x014
>  #define MMCIRESPONSE1  0x018
> --
> 1.9.1
>

Kind regards
Ulf Hansson
--
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 06/13] mmc: mmci: add ddrmode mask to variant data

[Srinivas Kandagatla]

On 30/05/14 10:35, Ulf Hansson wrote:

On 28 May 2014 15:46,   wrote:

From: Srinivas Kandagatla 

This patch adds ddrmode mask to variant structure giving more flexibility
to the driver to support more SOCs which have different datactrl register
layout.

Without this patch datactrl register is updated with wrong ddrmode mask on non
ST SOCs, resulting in card detection failures.


The above statement seems not correct. We don't have any issues
currently, right. :-)

I should have said Qualcomm instead of generalizing it to non-ST SOCs.
Will fix this in next version.

Thanks,
srini


Kind regards
Ulf Hansson



Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Linus Walleij 
---
  drivers/mmc/host/mmci.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 23401b0..729105b 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -59,6 +59,7 @@ static unsigned int fmax = 515633;
   *   is asserted (likewise for RX)
   * @sdio: variant supports SDIO
   * @st_clkdiv: true if using a ST-specific clock divider algorithm
+ * @datactrl_mask_ddrmode: ddr mode mask in datactrl register.
   * @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl 
register
   * @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
   *  register
@@ -74,6 +75,7 @@ struct variant_data {
 unsigned intdatalength_bits;
 unsigned intfifosize;
 unsigned intfifohalfsize;
+   unsigned intdatactrl_mask_ddrmode;
 boolsdio;
 boolst_clkdiv;
 boolblksz_datactrl16;
@@ -152,6 +154,7 @@ static struct variant_data variant_ux500v2 = {
 .fifohalfsize   = 8 * 4,
 .clkreg = MCI_CLK_ENABLE,
 .clkreg_enable  = MCI_ST_UX500_HWFCEN,
+   .datactrl_mask_ddrmode  = MCI_ST_DPSM_DDRMODE,
 .datalength_bits= 24,
 .sdio   = true,
 .st_clkdiv  = true,
@@ -779,7 +782,7 @@ static void mmci_start_data(struct mmci_host *host, struct 
mmc_data *data)
 }

 if (host->mmc->ios.timing == MMC_TIMING_UHS_DDR50)
-   datactrl |= MCI_ST_DPSM_DDRMODE;
+   datactrl |= variant->datactrl_mask_ddrmode;

 /*
  * Attempt to use DMA operation mode, if this
--
1.9.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 v2 08/11] sched: get CPU's activity statistic

[Dietmar Eggemann]

On 23/05/14 16:53, Vincent Guittot wrote:
> Monitor the activity level of each group of each sched_domain level. The
> activity is the amount of cpu_power that is currently used on a CPU or group
> of CPUs. We use the runnable_avg_sum and _period to evaluate this activity
> level. In the special use case where the CPU is fully loaded by more than 1
> task, the activity level is set above the cpu_power in order to reflect the
> overload of the CPU
> 
> Signed-off-by: Vincent Guittot 

[...]

>  /*
>   * select_task_rq_fair: Select target runqueue for the waking task in domains
>   * that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE,
> @@ -5518,6 +5535,7 @@ struct sg_lb_stats {
>   unsigned long sum_weighted_load; /* Weighted load of group's tasks */
>   unsigned long load_per_task;
>   unsigned long group_power;
> + unsigned long group_activity; /* Total activity of the group */
>   unsigned int sum_nr_running; /* Nr tasks running in the group */
>   unsigned int group_capacity;
>   unsigned int idle_cpus;
> @@ -5538,6 +5556,7 @@ struct sd_lb_stats {
>   struct sched_group *busiest;/* Busiest group in this sd */
>   struct sched_group *local;  /* Local group in this sd */
>   unsigned long total_load;   /* Total load of all groups in sd */
> + unsigned long total_activity;  /* Total activity of all groups in sd */
>   unsigned long total_pwr;/* Total power of all groups in sd */
>   unsigned long avg_load; /* Average load across all groups in sd */
>  
> @@ -5557,6 +5576,7 @@ static inline void init_sd_lb_stats(struct sd_lb_stats 
> *sds)
>   .busiest = NULL,
>   .local = NULL,
>   .total_load = 0UL,
> + .total_activity = 0UL,

AFAICS, total_activity is not used right now. Do you intend to use it to
calculate something like avg_activity later (like total_load/avg_load)?

>   .total_pwr = 0UL,
>   .busiest_stat = {
>   .avg_load = 0UL,

[...]

--
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 5/7 v6] trace, RAS: Add eMCA trace event interface

[Chen, Gong]

On Wed, May 28, 2014 at 12:56:25PM -0400, Steven Rostedt wrote:
> Instead of making that a huge string, what about a dynamic array of
> special structures?
> 
> 
> struct __attribute__((__packed__)) cper_sec_mem_rec {
>   short type;
>   int data;
> };
> 
> 
HI, Steven & Boris

We have two big chunk string. One for memory error location, the other
for DIMM error location. Since DIMM error location depends on some
other conditions, how about just converting memory error location
to a compact mode but leaving DIMM error location alone? 

For memory error location, I will utilize type offset to save one
more byte, furthermore, I want to drop requestor_id, responder_id
and target_id. 1) They are very rare (I've never seen them by now)
2) They are u64 but not u16. So to keep whole struct clean I want
to use following struct. We can extend it later when necessary.

struct __attribute__((__packed__)) cper_sec_mem_rec {
u8 type;
u16 data;
};

So whole struct is just 3 bytes. Even if all fields are valid, we
have 3 * 9 = 27 bytes in total for a record in the ring buffer.

Make sense?


signature.asc
Description: Digital signature

Re: [PATCH v4 03/13] mmc: mmci: Add Qualcomm Id to amba id table

[Srinivas Kandagatla]

On 30/05/14 10:39, Ulf Hansson wrote:

On 28 May 2014 15:46,   wrote:

From: Srinivas Kandagatla 

This patch adds a fake Qualcomm ID 0x00051180 to the amba_ids, as Qualcomm
SDCC controller is pl180, but amba id registers read 0x0's.
The plan is to remove SDCC driver totally and use mmci as the main SD
controller driver for Qualcomm SOCs.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Linus Walleij 
---
  drivers/mmc/host/mmci.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a38e714..86f25a9 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -160,6 +160,14 @@ static struct variant_data variant_ux500v2 = {
 .pwrreg_nopower = true,
  };

+static struct variant_data variant_qcom = {
+   .fifosize   = 16 * 4,
+   .fifohalfsize   = 8 * 4,
+   .clkreg = MCI_CLK_ENABLE,
+   .datalength_bits= 24,
+   .pwrreg_powerup = MCI_PWR_UP,
+};
+
  static int mmci_card_busy(struct mmc_host *mmc)
  {
 struct mmci_host *host = mmc_priv(mmc);
@@ -1750,6 +1758,12 @@ static struct amba_id mmci_ids[] = {
 .mask   = 0xf0ff,
 .data   = _ux500v2,
 },
+   /* Qualcomm variants */
+   {
+   .id = 0x00051180,
+   .mask   = 0x000f,
+   .data   = _qcom,
+   },
 { 0, 0 },
  };


Shouldn't this patch be moved to very end of this patchset?

If we would apply this patch on it's own - the Qcom variant wouldn't
work, right?

Yes, I would not work. I will move it to the end of the patchset.

Thanks,
srini


Kind regards
Ulf Hansson



--
1.9.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] extcon: Set parent device of extcon device using prameter of devm_extcon_dev_allocate

[Chanwoo Choi]

Hi Charles,

On 05/30/2014 06:36 PM, Charles Keepax wrote:
> On Fri, May 30, 2014 at 10:41:39AM +0900, Chanwoo Choi wrote:
>> This patch set the parent device of extcon device using first parameter of
>> devm_extco_dev_allocate() to remove duplicate code on all of extcon provider
>> drivers.
>>
>> Signed-off-by: Chanwoo Choi 
>> Reported-by: Charles Keepax 
>> Cc: Charles Keepax 
>> Cc: Mark Brown 
>> Cc: Graeme Gregory 
>> Cc: Kishon Vijay Abraham I 
>> Cc: Krzysztof Kozlowski 
>> ---
>>  drivers/extcon/extcon-adc-jack.c | 1 -
>>  drivers/extcon/extcon-arizona.c  | 1 -
>>  drivers/extcon/extcon-class.c| 2 ++
>>  drivers/extcon/extcon-gpio.c | 1 -
>>  drivers/extcon/extcon-max77693.c | 1 -
>>  drivers/extcon/extcon-max8997.c  | 1 -
>>  drivers/extcon/extcon-palmas.c   | 1 -
>>  7 files changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-adc-jack.c 
>> b/drivers/extcon/extcon-adc-jack.c
>> index e18f95b..d860229 100644
>> --- a/drivers/extcon/extcon-adc-jack.c
>> +++ b/drivers/extcon/extcon-adc-jack.c
>> @@ -112,7 +112,6 @@ static int adc_jack_probe(struct platform_device *pdev)
>>  dev_err(>dev, "failed to allocate extcon device\n");
>>  return -ENOMEM;
>>  }
>> -data->edev->dev.parent = >dev;
>>  data->edev->name = pdata->name;
>>  
>>  /* Check the length of array and set num_cables */
>> diff --git a/drivers/extcon/extcon-arizona.c 
>> b/drivers/extcon/extcon-arizona.c
>> index c634796..d9bd3c3 100644
>> --- a/drivers/extcon/extcon-arizona.c
>> +++ b/drivers/extcon/extcon-arizona.c
>> @@ -1165,7 +1165,6 @@ static int arizona_extcon_probe(struct platform_device 
>> *pdev)
>>  return -ENOMEM;
>>  }
>>  info->edev->name = "Headset Jack";
>> -info->edev->dev.parent = arizona->dev;
>>  
>>  ret = devm_extcon_dev_register(>dev, info->edev);
> 
> This changes the parent device for the Arizona stuff, I don't
> think this is a problem but I should probably test here first.

OK, Let me know about test result.

Thanks,
Chanwoo Choi


--
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 2/2] x86_64: expand kernel stack to 16K

[Richard Weinberger]

On Thu, May 29, 2014 at 5:24 PM, Linus Torvalds
 wrote:
> So I'm not in fact arguing against Minchan's patch of upping
> THREAD_SIZE_ORDER to 2 on x86-64, but at the same time stack size does
> remain one of my "we really need to be careful" issues, so while I am
> basically planning on applying that patch, I _also_ want to make sure
> that we fix the problems we do see and not just paper them over.
>
> The 8kB stack has been somewhat restrictive and painful for a while,
> and I'm ok with admitting that it is just getting _too_ damn painful,
> but I don't want to just give up entirely when we have a known deep
> stack case.

If we raise the stack size on x86_64 to 16k, what about i386?
Beside of the fact that most of you consider 32bits as dead and must die... ;)

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

Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator

[Herbert Xu]

On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote:
>
> A second aspect is the implementation of the stdrng. Currently, the offered 
> patch does not include the stdrng selection. I am currently working on the 
> completion of the addition of the stdrng selection to the offered patch. My 
> idea is the following: currently, all DRBG types are registered with their 
> own 
> cra_name. However, there shall be one particular DRBG registered twice. When 
> registering the instance again, the cra_name shall be "stdrng". In addition, 
> if the kernel command line contains fips=1, the cra_priority of that stdrng 
> should be set to 300. That implies that when the kernel resolves the stdrng, 
> it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in 
> FIPS 
> mode.

Just have all of them register as stdrng with differing priorities.
We already have a user-space interface to change priorities.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/bio.c: update bi_iter.bi_size before recounting segments

[Dongsu Park]

Hi Ming,

On 29.05.2014 15:59, Ming Lei wrote:
> The patch of "bio: modify __bio_add_page() to accept pages that
> don't start a new segment" changes the way for adding one page
> to bio:
> 
>   - previously by adding page after checking successfully
>   - now by trying to add page and recover if it fails
> 
> Unfortunately the patch forgets to update bio->bi_iter.bi_size
> before trying to add page, then the last vector for holding
> the added page may not be covered if recouning segments is needed,
> so bio->bi_phys_segments may become not consistent with the
> actual bio page buffers after the page is added successfully
> to the bio(after bi_iter.bi_size is added by 'len')
> 
> Suppose the page in the last vector can't be merged to bio, tragedy
> will happen when __bio_add_page() is called to add another page:
> 
>   - blk_recount_segments() is called and the actual segments get
>   figured out correctly
> 
>   - the actual segments may become queue_max_segments(q) plus one
>   in failure path
> 
>   - driver will find the segment count is too big to handle.
> 
> The patch fixes the virtio-blk oops bug reported from Jet Chen in
> below link:
> 
>   http://marc.info/?l=linux-kernel=140113053817095=2

A great patch description, thanks! :-)
You can add:

Tested-by: Dongsu Park 

> Cc: Jens Axboe 
> Cc: Maurizio Lombardi 
> Cc: Dongsu Park 
> Cc: Christoph Hellwig 
> Cc: Kent Overstreet 
> Cc: Andrew Morton 
> Reported-by: Jet Chen 
> Tested-by: Jet Chen 
> Signed-off-by: Ming Lei 
> ---
> Andrew, could you put the patch in your -mm tree
> because the previous two patches were routed from
> your tree?
> 
>  block/bio.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/block/bio.c b/block/bio.c
> index 0443694..f9bae56 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -744,6 +744,7 @@ static int __bio_add_page(struct request_queue *q, struct 
> bio *bio, struct page
>   }
>   }
>  
> + bio->bi_iter.bi_size += len;
>   goto done;
>   }
>   }
> @@ -761,6 +762,7 @@ static int __bio_add_page(struct request_queue *q, struct 
> bio *bio, struct page
>   bvec->bv_offset = offset;
>   bio->bi_vcnt++;
>   bio->bi_phys_segments++;
> + bio->bi_iter.bi_size += len;
>  
>   /*
>* Perform a recount if the number of segments is greater
> @@ -802,7 +804,6 @@ static int __bio_add_page(struct request_queue *q, struct 
> bio *bio, struct page
>   bio->bi_flags &= ~(1 << BIO_SEG_VALID);
>  
>   done:
> - bio->bi_iter.bi_size += len;
>   return len;
>  
>   failed:
> @@ -810,6 +811,7 @@ static int __bio_add_page(struct request_queue *q, struct 
> bio *bio, struct page
>   bvec->bv_len = 0;
>   bvec->bv_offset = 0;
>   bio->bi_vcnt--;
> + bio->bi_iter.bi_size -= len;
>   blk_recount_segments(q, bio);
>   return 0;
>  }
> -- 
> 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 3/4] extcon: arizona: Update manual headphone detection calculation

[Charles Keepax]

On Fri, May 30, 2014 at 10:27:35AM +0900, Chanwoo Choi wrote:
> Hi Charles,
> 
> On 05/30/2014 12:27 AM, Charles Keepax wrote:
> > The higher levels of impedance have a higher minimum value than the
> > first level. As the same value was used for all levels, higher impedances
> > were reported with a very low level of accuracy. This patch applies the
> > approriate lower threshold for each level.
> > 
> > Signed-off-by: Charles Keepax 
> > ---
> >  drivers/extcon/extcon-arizona.c |   13 -
> >  1 files changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/extcon/extcon-arizona.c 
> > b/drivers/extcon/extcon-arizona.c
> > index f2c36b1..c1c8647 100644
> > --- a/drivers/extcon/extcon-arizona.c
> > +++ b/drivers/extcon/extcon-arizona.c
> > @@ -329,12 +329,13 @@ static void arizona_stop_mic(struct 
> > arizona_extcon_info *info)
> >  }
> >  
> >  static struct {
> > +   unsigned int threshold;
> > unsigned int factor_a;
> > unsigned int factor_b;
> >  } arizona_hpdet_b_ranges[] = {
> > -   {  5528,   362464 },
> > -   { 11084,  6186851 },
> > -   { 11065, 65460395 },
> > +   { 100,  5528,   362464 },
> > +   { 169, 11084,  6186851 },
> > +   { 169, 11065, 65460395 },
> 
> If you possible, I want to know the 'unit' of the variable(factor_a, 
> factor_b).

I am not sure there are really especially sensible units to give.

> 
> >  };
> >  
> >  static struct {
> > @@ -391,7 +392,8 @@ static int arizona_hpdet_read(struct 
> > arizona_extcon_info *info)
> >>> ARIZONA_HP_IMPEDANCE_RANGE_SHIFT;
> >  
> > if (range < ARRAY_SIZE(arizona_hpdet_b_ranges) - 1 &&
> > -   (val < 100 || val >= 0x3fb)) {
> > +   (val < arizona_hpdet_b_ranges[range].threshold ||
> > +val >= 0x3fb)) {
> 
> I don't understand the meaning of 0x3fb hex value.
> I prefer to define constant variable for readability.

Thats fine I can add a define as part of this patch.

Thanks,
Charles
--
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] bio: decrease bi_iter.bi_size by len in the fail path

[Dongsu Park]

Hi Ming,

On 29.05.2014 00:59, Ming Lei wrote:
> On Wed, May 28, 2014 at 11:42 PM, Ming Lei  wrote:
> > Would you mind explaining why bi_iter.bi_size need to be
> > decreased by 'len'? In the failure path, it wasn't added by
> > 'len', was it?
> 
> Actually, the correct thing may be like what did in the
> attached patch, as Maurizio discussed with me[1].

Yes, I agree. Your patch is the correct fix.
Please ignore my patch, and take yours,


> Very interestingly, I have reproduced the problem one time
> with ext4/271 ext4/301 ext4/305, but won't with the attached
> patch after running it for 3 rounds.

I also had a trouble with reproducing this bug on my home desktop,
while I can reliably reproduce the bug on my office workstation.
I'm not quite sure what makes the difference.
(The same kernel, the same qemu version, the same xfstests version, etc.)

Anyway, coming back to my office, now I can confirm that your patch
fixes the bug. You can add:

Tested-by: Dongsu Park 

Thanks,
Dongsu

> [tom@localhost xfstests]$ sudo ./check ext4/271 ext4/301 ext4/305
> FSTYP -- ext4
> PLATFORM  -- Linux/x86_64 localhost 3.15.0-rc7-next-20140527+
> MKFS_OPTIONS  -- /dev/vdc
> MOUNT_OPTIONS -- -o acl,user_xattr /dev/vdc /mnt/scratch
> 
> ext4/271 1s ... 1s
> ext4/301 31s ... 32s
> ext4/305 181s ... 180s
> Ran: ext4/271 ext4/301 ext4/305
> Passed all 3 tests
> 
> Jet, could you test the attached patch?
> 
> [1], https://lkml.org/lkml/2014/5/27/327
> 
> 
> Thanks,
> -- 
> Ming Lei


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

Re: [PATCH v4 03/13] mmc: mmci: Add Qualcomm Id to amba id table

[Ulf Hansson]

On 28 May 2014 15:46,   wrote:
> From: Srinivas Kandagatla 
>
> This patch adds a fake Qualcomm ID 0x00051180 to the amba_ids, as Qualcomm
> SDCC controller is pl180, but amba id registers read 0x0's.
> The plan is to remove SDCC driver totally and use mmci as the main SD
> controller driver for Qualcomm SOCs.
>
> Signed-off-by: Srinivas Kandagatla 
> Reviewed-by: Linus Walleij 
> ---
>  drivers/mmc/host/mmci.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index a38e714..86f25a9 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -160,6 +160,14 @@ static struct variant_data variant_ux500v2 = {
> .pwrreg_nopower = true,
>  };
>
> +static struct variant_data variant_qcom = {
> +   .fifosize   = 16 * 4,
> +   .fifohalfsize   = 8 * 4,
> +   .clkreg = MCI_CLK_ENABLE,
> +   .datalength_bits= 24,
> +   .pwrreg_powerup = MCI_PWR_UP,
> +};
> +
>  static int mmci_card_busy(struct mmc_host *mmc)
>  {
> struct mmci_host *host = mmc_priv(mmc);
> @@ -1750,6 +1758,12 @@ static struct amba_id mmci_ids[] = {
> .mask   = 0xf0ff,
> .data   = _ux500v2,
> },
> +   /* Qualcomm variants */
> +   {
> +   .id = 0x00051180,
> +   .mask   = 0x000f,
> +   .data   = _qcom,
> +   },
> { 0, 0 },
>  };

Shouldn't this patch be moved to very end of this patchset?

If we would apply this patch on it's own - the Qcom variant wouldn't
work, right?

Kind regards
Ulf Hansson

>
> --
> 1.9.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 1/6] thermal: sti: Supply Device Tree documentation

[Lee Jones]

Signed-off-by: Ajit Pal Singh 
Signed-off-by: Lee Jones 
---
 .../devicetree/bindings/thermal/st-thermal.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/st-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt 
b/Documentation/devicetree/bindings/thermal/st-thermal.txt
new file mode 100644
index 000..8537fdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st-thermal.txt
@@ -0,0 +1,42 @@
+Binding for Thermal Sensor driver for STMicroelectronics STi series of SoCs.
+
+Required parameters:
+---
+
+compatible :   st,--thermal; should be one of:
+ "st,stih415-sas-thermal",
+ "st,stih415-mpe-thermal",
+ "st,stih416-sas-thermal"
+ "st,stih416-mpe-thermal"
+ "st,stid127-thermal" or
+ "st,stih407-thermal"
+   according to the SoC type (stih415, stih416, stid127, stih407)
+   and module type (sas or mpe). On stid127 & stih407 there is only
+   one die/module, so there is no module type in the compatible
+   string.
+clock-names :  Should be "thermal".
+ See: Documentation/devicetree/bindings/resource-names.txt
+clocks :   Phandle of the clock used by the thermal sensor.
+ See: 
Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Optional parameters:
+---
+
+reg :  For non-sysconf based sensors, this should be the physical base
+   address and length of the sensor's registers.
+interrupts :   Standard way to define interrupt number.
+   Interrupt is mandatory to be defined when compatible is
+   "stih416-mpe-thermal".
+ NB: For thermal sensor's for which no interrupt has been
+ defined, a polling delay of 1000ms will be used to read the
+ temperature from device.
+
+Example:
+
+   temp1@fdfe8000 {
+   compatible  = "st,stih416-mpe-thermal";
+   reg = <0xfdfe8000 0x10>;
+   clock-names = "thermal";
+   clocks  = <_M_MPETHSENS>;
+   interrupts  = ;
+   };
-- 
1.8.3.2

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

[PATCH 3/6] thermal: sti: Add support for ST's System Config Register based Thermal controller

[Lee Jones]

Supply controller specific information to the ST Thermal Core.

Signed-off-by: Ajit Pal Singh 
Signed-off-by: Lee Jones 
---
 drivers/thermal/st/Kconfig |   4 +
 drivers/thermal/st/Makefile|   1 +
 drivers/thermal/st/st_thermal_syscfg.c | 179 +
 3 files changed, 184 insertions(+)
 create mode 100644 drivers/thermal/st/st_thermal_syscfg.c

diff --git a/drivers/thermal/st/Kconfig b/drivers/thermal/st/Kconfig
index 1ba6760..d7b6e03 100644
--- a/drivers/thermal/st/Kconfig
+++ b/drivers/thermal/st/Kconfig
@@ -2,3 +2,7 @@ config ST_THERMAL
tristate "Thermal sensors on STMicroelectronics STi series of SoCs"
help
  Support for thermal sensors on STMicroelectronics STi series of SoCs.
+
+config ST_THERMAL_SYSCFG
+   select ST_THERMAL
+   tristate "STi series syscfg register access based thermal sensors"
diff --git a/drivers/thermal/st/Makefile b/drivers/thermal/st/Makefile
index 10f4bf6..e5058c6 100644
--- a/drivers/thermal/st/Makefile
+++ b/drivers/thermal/st/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_ST_THERMAL)   := st_thermal.o
+obj-$(CONFIG_ST_THERMAL_SYSCFG)+= st_thermal_syscfg.o
diff --git a/drivers/thermal/st/st_thermal_syscfg.c 
b/drivers/thermal/st/st_thermal_syscfg.c
new file mode 100644
index 000..888b58e
--- /dev/null
+++ b/drivers/thermal/st/st_thermal_syscfg.c
@@ -0,0 +1,179 @@
+/*
+ * ST Thermal Sensor Driver for syscfg based sensors.
+ * Author: Ajit Pal Singh 
+ *
+ * Copyright (C) 2003-2014 STMicroelectronics (R) Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include "st_thermal.h"
+
+/* STiH415 */
+#define STIH415_SYSCFG_FRONT(num)  ((num - 100) * 4)
+#define STIH415_SAS_THSENS_CONF
STIH415_SYSCFG_FRONT(178)
+#define STIH415_SAS_THSENS_STATUS  STIH415_SYSCFG_FRONT(198)
+#define STIH415_SYSCFG_MPE(num)((num - 600) * 4)
+#define STIH415_MPE_THSENS_CONFSTIH415_SYSCFG_MPE(607)
+#define STIH415_MPE_THSENS_STATUS  STIH415_SYSCFG_MPE(667)
+
+/* STiH416 */
+#define STIH416_SYSCFG_FRONT(num)  ((num - 1000) * 4)
+#define STIH416_SAS_THSENS_CONF
STIH416_SYSCFG_FRONT(1552)
+#define STIH416_SAS_THSENS_STATUS1 STIH416_SYSCFG_FRONT(1554)
+#define STIH416_SAS_THSENS_STATUS2 STIH416_SYSCFG_FRONT(1594)
+
+/* STiD127 */
+#define STID127_SYSCFG_CPU(num)((num - 700) * 4)
+#define STID127_THSENS_CONFSTID127_SYSCFG_CPU(743)
+#define STID127_THSENS_STATUS  STID127_SYSCFG_CPU(767)
+
+static const struct reg_field st_415sas_regfields[MAX_REGFIELDS] = {
+   [TEMP_PWR] = REG_FIELD(STIH415_SAS_THSENS_CONF,   9,  9),
+   [DCORRECT] = REG_FIELD(STIH415_SAS_THSENS_CONF,   4,  8),
+   [OVERFLOW] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 8,  8),
+   [DATA] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 10, 16),
+};
+
+static const struct reg_field st_415mpe_regfields[MAX_REGFIELDS] = {
+   [TEMP_PWR] = REG_FIELD(STIH415_MPE_THSENS_CONF,   8,  8),
+   [DCORRECT] = REG_FIELD(STIH415_MPE_THSENS_CONF,   3,  7),
+   [OVERFLOW] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 9,  9),
+   [DATA] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 11, 18),
+};
+
+static const struct reg_field st_416sas_regfields[MAX_REGFIELDS] = {
+   [TEMP_PWR] = REG_FIELD(STIH416_SAS_THSENS_CONF,9,  9),
+   [DCORRECT] = REG_FIELD(STIH416_SAS_THSENS_CONF,4,  8),
+   [OVERFLOW] = REG_FIELD(STIH416_SAS_THSENS_STATUS1, 8,  8),
+   [DATA] = REG_FIELD(STIH416_SAS_THSENS_STATUS2, 10, 16),
+};
+
+static const struct reg_field st_127_regfields[MAX_REGFIELDS] = {
+   [TEMP_PWR] = REG_FIELD(STID127_THSENS_CONF,   7,  7),
+   [DCORRECT] = REG_FIELD(STID127_THSENS_CONF,   2,  6),
+   [OVERFLOW] = REG_FIELD(STID127_THSENS_STATUS, 9,  9),
+   [DATA] = REG_FIELD(STID127_THSENS_STATUS, 11, 18),
+};
+
+/* Private OPs for System Configuration Register based thermal sensors */
+static int st_syscfg_power_ctrl(struct st_thermal_sensor *sensor,
+   enum st_thermal_power_state power_state)
+{
+   return regmap_field_write(sensor->pwr, power_state);
+}
+
+static int st_syscfg_alloc_regfields(struct st_thermal_sensor *sensor)
+{
+   struct device *dev = sensor->dev;
+
+   sensor->pwr = devm_regmap_field_alloc(dev, sensor->regmap,
+   sensor->cdata->reg_fields[TEMP_PWR]);
+
+   if (IS_ERR(sensor->pwr)) {
+   dev_err(dev, "failed to alloc syscfg regfields\n");
+   return PTR_ERR(sensor->pwr);
+   }
+
+   return 0;
+}
+

[PATCH 5/6] ARM: STi: DT: STiH416: Supply Thermal Controller Device Tree nodes

[Lee Jones]

We supply two of these.  The first is controlled by the System Configuration
registers and the second one provided is a more traditional 'memory mapped'
variant.  Each are handled by they own sub-driver.

Signed-off-by: Ajit Pal Singh 
Signed-off-by: Lee Jones 
---
 arch/arm/boot/dts/stih416.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 06473c5..ed80220 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -236,5 +236,23 @@
resets  = < STIH416_KEYSCAN_POWERDOWN>,
  < STIH416_KEYSCAN_SOFTRESET>;
};
+
+   temp0 {
+   compatible = "st,stih416-sas-thermal";
+   clock-names = "thermal";
+   clocks = <_c_vcc 14>;
+
+   status = "okay";
+   };
+
+   temp1@fdfe8000 {
+   compatible = "st,stih416-mpe-thermal";
+   reg = <0xfdfe8000 0x10>;
+   clocks = <_e 3>;
+   clock-names = "thermal";
+   interrupts = ;
+
+   status = "okay";
+   };
};
 };
-- 
1.8.3.2

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

Re: [PATCH 2/2] perf script: handle the num array type in python properly

[Sebastian Andrzej Siewior]

On 05/29/2014 06:43 AM, Namhyung Kim wrote:
> But this requires a change in generation time as I faced a type error
> when try to print an array argument as number.  I'll post a separate
> patch for this.

Thank you.

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

[PATCH 2/6] thermal: sti: Introduce ST Thermal core code

[Lee Jones]

This core is shared by both ST's 'memory mapped' and
'system configuration register' based Thermal controllers.

Signed-off-by: Ajit Pal Singh 
Signed-off-by: Lee Jones 
---
 drivers/thermal/Kconfig |   5 +
 drivers/thermal/Makefile|   1 +
 drivers/thermal/st/Kconfig  |   4 +
 drivers/thermal/st/Makefile |   1 +
 drivers/thermal/st/st_thermal.c | 313 
 drivers/thermal/st/st_thermal.h | 104 +
 6 files changed, 428 insertions(+)
 create mode 100644 drivers/thermal/st/Kconfig
 create mode 100644 drivers/thermal/st/Makefile
 create mode 100644 drivers/thermal/st/st_thermal.c
 create mode 100644 drivers/thermal/st/st_thermal.h

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d51912..6f88de1 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -231,4 +231,9 @@ depends on PLAT_SAMSUNG
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
+menu "STMicroelectronics thermal drivers"
+depends on ARCH_STI && OF
+source "drivers/thermal/st/Kconfig"
+endmenu
+
 endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 54e4ec9..ea36799 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_INTEL_POWERCLAMP)+= intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
 obj-$(CONFIG_TI_SOC_THERMAL)   += ti-soc-thermal/
 obj-$(CONFIG_ACPI_INT3403_THERMAL) += int3403_thermal.o
+obj-$(CONFIG_ST_THERMAL)   += st/
diff --git a/drivers/thermal/st/Kconfig b/drivers/thermal/st/Kconfig
new file mode 100644
index 000..1ba6760
--- /dev/null
+++ b/drivers/thermal/st/Kconfig
@@ -0,0 +1,4 @@
+config ST_THERMAL
+   tristate "Thermal sensors on STMicroelectronics STi series of SoCs"
+   help
+ Support for thermal sensors on STMicroelectronics STi series of SoCs.
diff --git a/drivers/thermal/st/Makefile b/drivers/thermal/st/Makefile
new file mode 100644
index 000..10f4bf6
--- /dev/null
+++ b/drivers/thermal/st/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ST_THERMAL)   := st_thermal.o
diff --git a/drivers/thermal/st/st_thermal.c b/drivers/thermal/st/st_thermal.c
new file mode 100644
index 000..90163b3
--- /dev/null
+++ b/drivers/thermal/st/st_thermal.c
@@ -0,0 +1,313 @@
+/*
+ * ST Thermal Sensor Driver core routines
+ * Author: Ajit Pal Singh 
+ *
+ * Copyright (C) 2003-2014 STMicroelectronics (R) Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "st_thermal.h"
+
+/* The Thermal Framework expects millidegrees */
+#define mcelsius(temp) ((temp) * 1000)
+
+/*
+ * Function to allocate regfields which are common
+ * between syscfg and memory mapped based sensors
+ */
+int st_thermal_alloc_regfields(struct st_thermal_sensor *sensor)
+{
+   struct device *dev = sensor->dev;
+   struct regmap *regmap = sensor->regmap;
+   const struct reg_field *reg_fields = sensor->cdata->reg_fields;
+
+   sensor->dcorrect = devm_regmap_field_alloc(dev, regmap,
+  reg_fields[DCORRECT]);
+
+   sensor->overflow = devm_regmap_field_alloc(dev, regmap,
+  reg_fields[OVERFLOW]);
+
+   sensor->temp_data = devm_regmap_field_alloc(dev, regmap,
+   reg_fields[DATA]);
+
+   if (IS_ERR(sensor->dcorrect) ||
+   IS_ERR(sensor->overflow) ||
+   IS_ERR(sensor->temp_data)) {
+   dev_err(dev, "failed to allocate common regfields\n");
+   return -EINVAL;
+   }
+
+   return sensor->ops->alloc_regfields(sensor);
+}
+
+static int st_thermal_sensor_on(struct st_thermal_sensor *sensor)
+{
+   int ret;
+   struct device *dev = sensor->dev;
+
+   ret = clk_prepare_enable(sensor->clk);
+   if (ret) {
+   dev_err(dev, "failed to enable clk\n");
+   return ret;
+   }
+
+   ret = sensor->ops->power_ctrl(sensor, POWER_ON);
+   if (ret) {
+   dev_err(dev, "failed to power on sensor\n");
+   clk_disable_unprepare(sensor->clk);
+   }
+
+   return ret;
+}
+
+static int st_thermal_sensor_off(struct st_thermal_sensor *sensor)
+{
+   int ret;
+
+   ret = sensor->ops->power_ctrl(sensor, POWER_OFF);
+   if (ret)
+   return ret;
+
+   clk_disable_unprepare(sensor->clk);
+
+   return 0;
+}
+
+static int st_thermal_calibration(struct st_thermal_sensor *sensor)
+{
+   int ret;
+   unsigned int val;
+   struct device *dev = sensor->dev;
+
+   /* Check if sensor calibration data is already written */
+   ret = 

[PATCH 6/6] ARM: multi_v7_defconfig: Configure in ST's Thermal Controller

[Lee Jones]

Signed-off-by: Ajit Pal Singh 
Signed-off-by: Lee Jones 
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index d4e8a47..dcc4e3e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -204,6 +204,8 @@ CONFIG_SENSORS_LM90=y
 CONFIG_THERMAL=y
 CONFIG_DOVE_THERMAL=y
 CONFIG_ARMADA_THERMAL=y
+CONFIG_ST_THERMAL_SYSCFG=y
+CONFIG_ST_THERMAL_MEMMAP=y
 CONFIG_WATCHDOG=y
 CONFIG_ORION_WATCHDOG=y
 CONFIG_MFD_AS3722=y
-- 
1.8.3.2

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

[PATCH 4/6] thermal: sti: Add support for ST's Memory Mapped based Thermal controller

[Lee Jones]

This is the traditional way of obtaining a device driver's register
address space.  The aim of this driver is to supply controller specific
information to the ST Thermal Core.

Signed-off-by: Ajit Pal Singh 
Signed-off-by: Lee Jones 
---
 drivers/thermal/st/Kconfig |   4 +
 drivers/thermal/st/Makefile|   1 +
 drivers/thermal/st/st_thermal_memmap.c | 209 +
 3 files changed, 214 insertions(+)
 create mode 100644 drivers/thermal/st/st_thermal_memmap.c

diff --git a/drivers/thermal/st/Kconfig b/drivers/thermal/st/Kconfig
index d7b6e03..490fdbe 100644
--- a/drivers/thermal/st/Kconfig
+++ b/drivers/thermal/st/Kconfig
@@ -6,3 +6,7 @@ config ST_THERMAL
 config ST_THERMAL_SYSCFG
select ST_THERMAL
tristate "STi series syscfg register access based thermal sensors"
+
+config ST_THERMAL_MEMMAP
+   select ST_THERMAL
+   tristate "STi series memory mapped access based thermal sensors"
diff --git a/drivers/thermal/st/Makefile b/drivers/thermal/st/Makefile
index e5058c6..b388789 100644
--- a/drivers/thermal/st/Makefile
+++ b/drivers/thermal/st/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_ST_THERMAL)   := st_thermal.o
 obj-$(CONFIG_ST_THERMAL_SYSCFG)+= st_thermal_syscfg.o
+obj-$(CONFIG_ST_THERMAL_MEMMAP)+= st_thermal_memmap.o
diff --git a/drivers/thermal/st/st_thermal_memmap.c 
b/drivers/thermal/st/st_thermal_memmap.c
new file mode 100644
index 000..39896ce
--- /dev/null
+++ b/drivers/thermal/st/st_thermal_memmap.c
@@ -0,0 +1,209 @@
+/*
+ * ST Thermal Sensor Driver for memory mapped sensors.
+ * Author: Ajit Pal Singh 
+ *
+ * Copyright (C) 2003-2014 STMicroelectronics (R) Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include "st_thermal.h"
+
+#define STIH416_MPE_CONF   0x0
+#define STIH416_MPE_STATUS 0x4
+#define STIH416_MPE_INT_THRESH 0x8
+#define STIH416_MPE_INT_EN 0xC
+
+/* Power control bits for the memory mapped thermal sensor */
+#define THERMAL_PDNBIT(4)
+#define THERMAL_SRSTN  BIT(10)
+
+static const struct reg_field st_mmap_thermal_regfields[MAX_REGFIELDS] = {
+   /*
+* According to the STIH416 MPE temp sensor data sheet -
+* the PDN (Power Down Bit) and SRSTN (Soft Reset Bit) need to be
+* written simultaneously for powering on and off the temperature
+* sensor. regmap_update_bits() will be used to update the register.
+*/
+   [INT_THRESH_HI] = REG_FIELD(STIH416_MPE_INT_THRESH, 0,  7),
+   [DCORRECT]  = REG_FIELD(STIH416_MPE_CONF,   5,  9),
+   [OVERFLOW]  = REG_FIELD(STIH416_MPE_STATUS, 9,  9),
+   [DATA]  = REG_FIELD(STIH416_MPE_STATUS, 11, 18),
+   [INT_ENABLE]= REG_FIELD(STIH416_MPE_INT_EN, 0,  0),
+};
+
+static irqreturn_t st_mmap_thermal_trip_handler(int irq, void *sdata)
+{
+   struct st_thermal_sensor *sensor = sdata;
+
+   thermal_zone_device_update(sensor->thermal_dev);
+
+   return IRQ_HANDLED;
+}
+
+/* Private ops for the Memory Mapped based thermal sensors */
+static int st_mmap_power_ctrl(struct st_thermal_sensor *sensor,
+ enum st_thermal_power_state power_state)
+{
+   const unsigned int mask = (THERMAL_PDN | THERMAL_SRSTN);
+   const unsigned int val = power_state ? mask : 0;
+
+   return regmap_update_bits(sensor->regmap, STIH416_MPE_CONF, mask, val);
+}
+
+static int st_mmap_alloc_regfields(struct st_thermal_sensor *sensor)
+{
+   struct device *dev = sensor->dev;
+   struct regmap *regmap = sensor->regmap;
+   const struct reg_field *reg_fields = sensor->cdata->reg_fields;
+
+   sensor->int_thresh_hi = devm_regmap_field_alloc(dev, regmap,
+   reg_fields[INT_THRESH_HI]);
+   sensor->int_enable = devm_regmap_field_alloc(dev, regmap,
+   reg_fields[INT_ENABLE]);
+
+   if (IS_ERR(sensor->int_thresh_hi) || IS_ERR(sensor->int_enable)) {
+   dev_err(dev, "failed to alloc mmap regfields\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int st_mmap_enable_irq(struct st_thermal_sensor *sensor)
+{
+   int ret;
+
+   /* Set upper critical threshold */
+   ret = regmap_field_write(sensor->int_thresh_hi,
+sensor->cdata->crit_temp -
+sensor->cdata->temp_adjust_val);
+   if (ret)
+   return ret;
+
+   return regmap_field_write(sensor->int_enable, 1);
+}
+
+static int 

[PATCH 0/6] thermal: sti: Add new Thermal driver

[Lee Jones]

This patchset adds full support for 2 types of Thermal Controllers
produced by STMicroelectronics.  One is a more traditional memory
mapped variant, the other is controlled solely by system configuration
registers.

 Documentation/devicetree/bindings/thermal/st-thermal.txt |  42 
 arch/arm/boot/dts/stih416.dtsi   |  18 +++
 arch/arm/configs/multi_v7_defconfig  |   2 +
 drivers/thermal/Kconfig  |   5 ++
 drivers/thermal/Makefile |   1 +
 drivers/thermal/st/Kconfig   |  12 +
 drivers/thermal/st/Makefile  |   3 ++
 drivers/thermal/st/st_thermal.c  | 313 
++
 drivers/thermal/st/st_thermal.h  | 104 
++
 drivers/thermal/st/st_thermal_memmap.c   | 209 

 drivers/thermal/st/st_thermal_syscfg.c   | 179 
+
 11 files changed, 888 insertions(+)

--
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] Remove an unnecessary blank line in drivers/staging/xillybus/xillybus_of.c

[Federico Di Pierro]

Hi!
This is my latest task of the eudyptula challenge.
Just a very small patch!
Signed-off-by: Federico Di Pierro 

--- xillybus_of.c	2014-05-30 11:27:18.160063074 +0200
+++ /home/federico/xillybus_of.c	2014-05-30 11:27:10.030063570 +0200
@@ -69,7 +69,6 @@
   int direction
 	)
 {
-	
 	dma_addr_t addr = 0;
 	struct xilly_dma *this;
 

Re: [PATCH] extcon: Set parent device of extcon device using prameter of devm_extcon_dev_allocate

[Charles Keepax]

On Fri, May 30, 2014 at 10:41:39AM +0900, Chanwoo Choi wrote:
> This patch set the parent device of extcon device using first parameter of
> devm_extco_dev_allocate() to remove duplicate code on all of extcon provider
> drivers.
> 
> Signed-off-by: Chanwoo Choi 
> Reported-by: Charles Keepax 
> Cc: Charles Keepax 
> Cc: Mark Brown 
> Cc: Graeme Gregory 
> Cc: Kishon Vijay Abraham I 
> Cc: Krzysztof Kozlowski 
> ---
>  drivers/extcon/extcon-adc-jack.c | 1 -
>  drivers/extcon/extcon-arizona.c  | 1 -
>  drivers/extcon/extcon-class.c| 2 ++
>  drivers/extcon/extcon-gpio.c | 1 -
>  drivers/extcon/extcon-max77693.c | 1 -
>  drivers/extcon/extcon-max8997.c  | 1 -
>  drivers/extcon/extcon-palmas.c   | 1 -
>  7 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-adc-jack.c 
> b/drivers/extcon/extcon-adc-jack.c
> index e18f95b..d860229 100644
> --- a/drivers/extcon/extcon-adc-jack.c
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -112,7 +112,6 @@ static int adc_jack_probe(struct platform_device *pdev)
>   dev_err(>dev, "failed to allocate extcon device\n");
>   return -ENOMEM;
>   }
> - data->edev->dev.parent = >dev;
>   data->edev->name = pdata->name;
>  
>   /* Check the length of array and set num_cables */
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index c634796..d9bd3c3 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1165,7 +1165,6 @@ static int arizona_extcon_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   }
>   info->edev->name = "Headset Jack";
> - info->edev->dev.parent = arizona->dev;
>  
>   ret = devm_extcon_dev_register(>dev, info->edev);

This changes the parent device for the Arizona stuff, I don't
think this is a problem but I should probably test here first.

Thanks,
Charles
--
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 06/13] mmc: mmci: add ddrmode mask to variant data

[Ulf Hansson]

On 28 May 2014 15:46,   wrote:
> From: Srinivas Kandagatla 
>
> This patch adds ddrmode mask to variant structure giving more flexibility
> to the driver to support more SOCs which have different datactrl register
> layout.
>
> Without this patch datactrl register is updated with wrong ddrmode mask on non
> ST SOCs, resulting in card detection failures.

The above statement seems not correct. We don't have any issues
currently, right. :-)

Kind regards
Ulf Hansson

>
> Signed-off-by: Srinivas Kandagatla 
> Reviewed-by: Linus Walleij 
> ---
>  drivers/mmc/host/mmci.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 23401b0..729105b 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -59,6 +59,7 @@ static unsigned int fmax = 515633;
>   *   is asserted (likewise for RX)
>   * @sdio: variant supports SDIO
>   * @st_clkdiv: true if using a ST-specific clock divider algorithm
> + * @datactrl_mask_ddrmode: ddr mode mask in datactrl register.
>   * @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl 
> register
>   * @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
>   *  register
> @@ -74,6 +75,7 @@ struct variant_data {
> unsigned intdatalength_bits;
> unsigned intfifosize;
> unsigned intfifohalfsize;
> +   unsigned intdatactrl_mask_ddrmode;
> boolsdio;
> boolst_clkdiv;
> boolblksz_datactrl16;
> @@ -152,6 +154,7 @@ static struct variant_data variant_ux500v2 = {
> .fifohalfsize   = 8 * 4,
> .clkreg = MCI_CLK_ENABLE,
> .clkreg_enable  = MCI_ST_UX500_HWFCEN,
> +   .datactrl_mask_ddrmode  = MCI_ST_DPSM_DDRMODE,
> .datalength_bits= 24,
> .sdio   = true,
> .st_clkdiv  = true,
> @@ -779,7 +782,7 @@ static void mmci_start_data(struct mmci_host *host, 
> struct mmc_data *data)
> }
>
> if (host->mmc->ios.timing == MMC_TIMING_UHS_DDR50)
> -   datactrl |= MCI_ST_DPSM_DDRMODE;
> +   datactrl |= variant->datactrl_mask_ddrmode;
>
> /*
>  * Attempt to use DMA operation mode, if this
> --
> 1.9.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 01/27] mtd: nand: introduce function to fix a common bug in most nand-drivers not showing a device in sysfs

[Alexander Holler]

Am 29.05.2014 08:17, schrieb Artem Bityutskiy:

On Wed, 2014-05-28 at 23:09 +0200, Alexander Holler wrote:

I'm very sorry, but I find such discussions extremly tiresome.


Why discussing then at all, just go ahead and to something else.


Agreed. In order to maintain psychical health it's better to not get in 
contact with this kindergarten.


Regards,

Alexander Holler
--
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] mfd: wm5102: Correct default for LDO Control 2 register

[Lee Jones]

> Update the default value to match the patch.
> 
> Signed-off-by: Richard Fitzgerald 
> ---
>  drivers/mfd/wm5102-tables.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
> index 9b9923c..02c44fd 100644
> --- a/drivers/mfd/wm5102-tables.c
> +++ b/drivers/mfd/wm5102-tables.c
> @@ -333,7 +333,7 @@ static const struct reg_default wm5102_reg_default[] = {
>   { 0x01AA, 0x0004 },   /* R426   - FLL2 GPIO Clock */ 
>   { 0x0200, 0x0006 },   /* R512   - Mic Charge Pump 1 */ 
>   { 0x0210, 0x00D4 },   /* R528   - LDO1 Control 1 */ 
> - { 0x0212, 0x0001 },   /* R530   - LDO1 Control 2 */
> + { 0x0212, 0x },   /* R530   - LDO1 Control 2 */
>   { 0x0213, 0x0344 },   /* R531   - LDO2 Control 1 */ 
>   { 0x0218, 0x01A6 },   /* R536   - Mic Bias Ctrl 1 */ 
>   { 0x0219, 0x01A6 },   /* R537   - Mic Bias Ctrl 2 */ 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] mfd: intel_soc_pmic: Core driver

[Lee Jones]

>  +static const struct i2c_device_id intel_soc_pmic_i2c_id[] = {
>  +{"INT33FD:00", (kernel_ulong_t)_soc_pmic_config_crc},
>  +{ }
>  +};
>  +MODULE_DEVICE_TABLE(i2c, intel_soc_pmic_i2c_id);
>  +
>  +static struct acpi_device_id intel_soc_pmic_acpi_match[] = {
>  +{"INT33FD", (kernel_ulong_t)_soc_pmic_config_crc},
>  +{ },
>  +};
>  +MODULE_DEVICE_TABLE(acpi, intel_soc_pmic_acpi_match);
> >>>
> >>> Does ACPI have a match function to extact it's .driver_data attribute?
> >>>
> >>> If so, are you using it here? If not, why not?
> >>>
> >>
> >> The ACPI table is used in i2c_device_match(), and the i2c table is used
> >> in i2c_device_probe(), so the id in the i2c table is actually fed to
> >> intel_soc_pmic_probe(). But I only found out now that having the i2c
> >> table alone is enough, because i2c_device_match will fallback to the i2c
> >> table if there's no ACPI table. So to keep it simple, I'll remove the
> >> ACPI table completely.
> > 
> > Actually, can you do it the other way round?  Minimise the i2c table
> > and populate the ACPI one.  I'm just about to work on a separate
> > patch-set which deprecates the use of the i2c table on DT and/or ACPI
> > only registered devices.
> 
> Current i2c_device_probe will only feed driver_data from i2c_device_id
> table to intel_soc_pmic_probe(), because it uses i2c_match_id(). So if I
> remove "_soc_pmic_config_crc" from the i2c table, I will get NULL
> from id->driver_data until your new patch fixes it.

Right, which is why I asked if ACPI has a match function - I just
looked and it does.  So what you need to do is supply a very simple
i2c_device_id struct (just until my patch lands, then there'll be no
reason to supply one at all) and use  acpi_match_device() instead of
using id->driver_data.

> So for the driver to work for the i2c code both today and in the future,
> I think it's best to keep the driver_data populated in both tables. What
> do you think?


-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] serial: imx: remove the DMA wait queue

[Wang, Jiada (ESD)]

Hi Shijie

After apply this patch into our kernel,
We are facing data hang issue when sending big size file (2M used in test) to 
uart port
Note: Rx port is also keep receiving data.

After read the implementation of uart_stop(),
I feel like, stop_tx() is used to perform flow control when like a XOFF is 
received.
Which means no data should be dropped, as they may need to be sent out,
When next start_tx() is called.

But by calling dmaengine_termiate_all(), the data already be submitted to DMA 
engine,
May be lost, thus cause data hang.

What do you think?

Thanks,
Jiada

-Original Message-
From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org] On 
Behalf Of Huang Shijie
Sent: Friday, May 23, 2014 1:33 PM
To: gre...@linuxfoundation.org
Cc: linux-arm-ker...@lists.infradead.org; Huang Shijie; 
linux-kernel@vger.kernel.org; linux-ser...@vger.kernel.org
Subject: [PATCH 1/2] serial: imx: remove the DMA wait queue

The DMA wait queue makes the code very complicated:
  For RX, the @->stop_rx hook does not really stop the RX;
  For TX, the @->stop_tx hook does not really stop the TX.

The above make the imx_shutdown has to wait the RX/TX DMA to be finished.

In order to make code more simple, this patch removes the DMA wait queue.
By calling the dmaengine_terminate_all, this patch makes the RX stops 
immediately after we call the @->stop_rx hook, so does the TX.

Signed-off-by: Huang Shijie 
---
 drivers/tty/serial/imx.c |   42 ++
 1 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 
d1f16d3..ed6cdf7 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -225,7 +225,6 @@ struct imx_port {
void*rx_buf;
unsigned inttx_bytes;
unsigned intdma_tx_nents;
-   wait_queue_head_t   dma_wait;
unsigned intsaved_reg[11];
 };
 
@@ -417,12 +416,10 @@ static void imx_stop_tx(struct uart_port *port)
return;
}
 
-   /*
-* We are maybe in the SMP context, so if the DMA TX thread is running
-* on other cpu, we have to wait for it to finish.
-*/
-   if (sport->dma_is_enabled && sport->dma_is_txing)
-   return;
+   if (sport->dma_is_enabled && sport->dma_is_txing) {
+   dmaengine_terminate_all(sport->dma_chan_tx);
+   sport->dma_is_txing = 0;
+   }
 
temp = readl(sport->port.membase + UCR1);
writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1); @@ -436,12 
+433,10 @@ static void imx_stop_rx(struct uart_port *port)
struct imx_port *sport = (struct imx_port *)port;
unsigned long temp;
 
-   /*
-* We are maybe in the SMP context, so if the DMA TX thread is running
-* on other cpu, we have to wait for it to finish.
-*/
-   if (sport->dma_is_enabled && sport->dma_is_rxing)
-   return;
+   if (sport->dma_is_enabled && sport->dma_is_rxing) {
+   dmaengine_terminate_all(sport->dma_chan_rx);
+   sport->dma_is_rxing = 0;
+   }
 
temp = readl(sport->port.membase + UCR2);
writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2); @@ -498,12 
+493,6 @@ static void dma_tx_callback(void *data)
dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
 
uart_write_wakeup(>port);
-
-   if (waitqueue_active(>dma_wait)) {
-   wake_up(>dma_wait);
-   dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
-   return;
-   }
 }
 
 static void imx_dma_tx(struct imx_port *sport) @@ -876,10 +865,6 @@ static 
void imx_rx_dma_done(struct imx_port *sport)
writel(temp, sport->port.membase + UCR1);
 
sport->dma_is_rxing = 0;
-
-   /* Is the shutdown waiting for us? */
-   if (waitqueue_active(>dma_wait))
-   wake_up(>dma_wait);
 }
 
 /*
@@ -1026,8 +1011,6 @@ static void imx_enable_dma(struct imx_port *sport)  {
unsigned long temp;
 
-   init_waitqueue_head(>dma_wait);
-
/* set UCR1 */
temp = readl(sport->port.membase + UCR1);
temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN | @@ -1219,10 +1202,13 
@@ static void imx_shutdown(struct uart_port *port)
unsigned long flags;
 
if (sport->dma_is_enabled) {
-   /* We have to wait for the DMA to finish. */
-   wait_event(sport->dma_wait,
-   !sport->dma_is_rxing && !sport->dma_is_txing);
+   /*
+* The upper layer may does not call the @->stop_tx and
+* @->stop_rx, so we call them ourselves.
+*/
+   imx_stop_tx(port);
imx_stop_rx(port);
+
imx_disable_dma(sport);
imx_uart_dma_exit(sport);
}
--
1.7.8


___

RE: [PATCH v4 13/16] iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups

[Varun Sethi]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 23, 2014 4:39 AM
> To: linux-...@vger.kernel.org; io...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org; aco...@gmail.com; li...@horizon.com;
> bhelg...@google.com; Sethi Varun-B16395; eddy0...@gmail.com
> Subject: [PATCH v4 13/16] iommu/fsl: Use iommu_group_get_for_dev() for
> IOMMU groups
> 
> Drop custom code and use IOMMU provided grouping support for PCI.
> 
> Signed-off-by: Alex Williamson 
> Cc: Varun Sethi 
> ---
>  drivers/iommu/fsl_pamu_domain.c |   66 +
> --
>  1 file changed, 1 insertion(+), 65 deletions(-)
> 
> diff --git a/drivers/iommu/fsl_pamu_domain.c
> b/drivers/iommu/fsl_pamu_domain.c index 93072ba..d02d668 100644
> --- a/drivers/iommu/fsl_pamu_domain.c
> +++ b/drivers/iommu/fsl_pamu_domain.c
> @@ -38,7 +38,6 @@
>  #include 
> 
>  #include "fsl_pamu_domain.h"
> -#include "pci.h"
> 
>  /*
>   * Global spinlock that needs to be held while @@ -892,8 +891,6 @@
> static int fsl_pamu_get_domain_attr(struct iommu_domain *domain,
>   return ret;
>  }
> 
> -#define REQ_ACS_FLAGS(PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR |
> PCI_ACS_UF)
> -
>  static struct iommu_group *get_device_iommu_group(struct device *dev)  {
>   struct iommu_group *group;
> @@ -950,74 +947,13 @@ static struct iommu_group
> *get_pci_device_group(struct pci_dev *pdev)
>   struct pci_controller *pci_ctl;
>   bool pci_endpt_partioning;
>   struct iommu_group *group = NULL;
> - struct pci_dev *bridge, *dma_pdev = NULL;
> 
>   pci_ctl = pci_bus_to_host(pdev->bus);
>   pci_endpt_partioning = check_pci_ctl_endpt_part(pci_ctl);
>   /* We can partition PCIe devices so assign device group to the
> device */
>   if (pci_endpt_partioning) {
> - bridge = pci_find_upstream_pcie_bridge(pdev);
> - if (bridge) {
> - if (pci_is_pcie(bridge))
> - dma_pdev = pci_get_domain_bus_and_slot(
> - pci_domain_nr(pdev->bus),
> - bridge->subordinate->number, 0);
> - if (!dma_pdev)
> - dma_pdev = pci_dev_get(bridge);
> - } else
> - dma_pdev = pci_dev_get(pdev);
> -
> - /* Account for quirked devices */
> - swap_pci_ref(_pdev, pci_get_dma_source(dma_pdev));
> -
> - /*
> -  * If it's a multifunction device that does not support our
> -  * required ACS flags, add to the same group as lowest
> numbered
> -  * function that also does not suport the required ACS flags.
> -  */
> - if (dma_pdev->multifunction &&
> - !pci_acs_enabled(dma_pdev, REQ_ACS_FLAGS)) {
> - u8 i, slot = PCI_SLOT(dma_pdev->devfn);
> -
> - for (i = 0; i < 8; i++) {
> - struct pci_dev *tmp;
> -
> - tmp = pci_get_slot(dma_pdev->bus, 
> PCI_DEVFN(slot,
> i));
> - if (!tmp)
> - continue;
> -
> - if (!pci_acs_enabled(tmp, REQ_ACS_FLAGS)) {
> - swap_pci_ref(_pdev, tmp);
> - break;
> - }
> - pci_dev_put(tmp);
> - }
> - }
> -
> - /*
> -  * Devices on the root bus go through the iommu.  If that's
> not us,
> -  * find the next upstream device and test ACS up to the root
> bus.
> -  * Finding the next device may require skipping virtual
> buses.
> -  */
> - while (!pci_is_root_bus(dma_pdev->bus)) {
> - struct pci_bus *bus = dma_pdev->bus;
> -
> - while (!bus->self) {
> - if (!pci_is_root_bus(bus))
> - bus = bus->parent;
> - else
> - goto root_bus;
> - }
> -
> - if (pci_acs_path_enabled(bus->self, NULL,
> REQ_ACS_FLAGS))
> - break;
> -
> - swap_pci_ref(_pdev, pci_dev_get(bus->self));
> - }
> + group = iommu_group_get_for_dev(>dev);
> 
> -root_bus:
> - group = get_device_iommu_group(_pdev->dev);
> - pci_dev_put(dma_pdev);
>   /*
>* PCIe controller is not a paritionable entity
>* free the controller device iommu_group.
Acknowledged-by: Varun Sethi 
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: Unionmount and overlayfs testsuite

[J. R. Okajima]

David Howells:
> >   Does readlink(2) return "/u/fileA" instead of /ro/fileA?"
>
> No.
>
> The test suite sets the lower symlink to point to the union path for its 
> target.
>
> [root@andromeda union-testsuite]# readlink /lower/a/indirect_dir_sym100 
> /mnt/a/direct_dir_sym100

Now I've found your latest commit fixed the path.
No problemo.


J. R. Okajima
--
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: Unionmount and overlayfs testsuite

[David Howells]

David Howells  wrote:

> I'll have to address the termslash alterations at some point.

Okay.  Done and pushed.

David
--
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] NFS: Use smp_mb__{before,after}_atomic()

[Thierry Reding]

From: Thierry Reding 

Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic())
deprecated the smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}*()
functions in favour of the unified smp_mb__{before,after}_atomic().

While at it, convert the smb_mb__before_atomic()/clear_bit() pattern to
the more idiomatic clear_bit_unlock().

Signed-off-by: Thierry Reding 
---
 fs/nfs/pagelist.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index 353331969626..c00d4f1de8ef 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -173,9 +173,8 @@ nfs_page_group_unlock(struct nfs_page *req)
 
WARN_ON_ONCE(head != head->wb_head);
 
-   smp_mb__before_clear_bit();
-   clear_bit(PG_HEADLOCK, >wb_flags);
-   smp_mb__after_clear_bit();
+   clear_bit_unlock(PG_HEADLOCK, >wb_flags);
+   smp_mb__after_atomic();
wake_up_bit(>wb_flags, PG_HEADLOCK);
 }
 
-- 
1.9.2

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

Re: [PATCH v4 1/3] mfd: intel_soc_pmic: Core driver

[Zhu, Lejun]

On 2014/5/30 16:08, Lee Jones wrote:
 +static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 +{
 +  struct gpio_desc *desc;
 +  int irq;
 +
 +  desc = devm_gpiod_get_index(dev, KBUILD_MODNAME, 0);
>>>
>>> What does "KBUILD_MODNAME" translate to?
>>
>> It translates into "intel_soc_pmic".
> 
> Can you just put that instead?

Sure. I'll fix it.

(...)

 +static const struct i2c_device_id intel_soc_pmic_i2c_id[] = {
 +  {"INT33FD:00", (kernel_ulong_t)_soc_pmic_config_crc},
 +  { }
 +};
 +MODULE_DEVICE_TABLE(i2c, intel_soc_pmic_i2c_id);
 +
 +static struct acpi_device_id intel_soc_pmic_acpi_match[] = {
 +  {"INT33FD", (kernel_ulong_t)_soc_pmic_config_crc},
 +  { },
 +};
 +MODULE_DEVICE_TABLE(acpi, intel_soc_pmic_acpi_match);
>>>
>>> Does ACPI have a match function to extact it's .driver_data attribute?
>>>
>>> If so, are you using it here? If not, why not?
>>>
>>
>> The ACPI table is used in i2c_device_match(), and the i2c table is used
>> in i2c_device_probe(), so the id in the i2c table is actually fed to
>> intel_soc_pmic_probe(). But I only found out now that having the i2c
>> table alone is enough, because i2c_device_match will fallback to the i2c
>> table if there's no ACPI table. So to keep it simple, I'll remove the
>> ACPI table completely.
> 
> Actually, can you do it the other way round?  Minimise the i2c table
> and populate the ACPI one.  I'm just about to work on a separate
> patch-set which deprecates the use of the i2c table on DT and/or ACPI
> only registered devices.

Current i2c_device_probe will only feed driver_data from i2c_device_id
table to intel_soc_pmic_probe(), because it uses i2c_match_id(). So if I
remove "_soc_pmic_config_crc" from the i2c table, I will get NULL
from id->driver_data until your new patch fixes it.

So for the driver to work for the i2c code both today and in the future,
I think it's best to keep the driver_data populated in both tables. What
do you think?

Best Regards
Lejun

--
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 13/13] mmc: mmci: Add Qcom specific pio_read function.

[Linus Walleij]

On Fri, May 30, 2014 at 3:30 AM, Stephen Boyd  wrote:

> Hm... that doesn't sound right. Please see this thread on lkml[1], and
> also this video from Ben H.[2]

But Benji is talking about the *PCI BUS*, and this is raw register
access. He just says that "This is how a BE CPU is normally
wired to a LE bus" we have no idea whether that is actually the
case on any existing system with this peripheral. Such things
have to be tested.

> My understanding is that this is a fifo
> so I would think we want to use the ioread32_rep() function here (or
> other "string" io functionality). Otherwise we're going to byteswap the
> data that we're trying to interpret as a buffer and big endian CPUs
> won't work.

You don't know that until you have tested on real BE ARM
hardware with this PrimeCell. How do you know the SoC
designers will have been smart enough to insert byte swap
logic?

>> You are right. readsl() or ioread32_rep() isn't used for this reason.
>
> We could always use a size of 1 right?

What do you mean? Do you mean using:

ioread32_rep(io, buf, 1)?

Notice this is totally equivalent to readsl() in arm/include/asm/io.h:

#define readsl(p,d,l)   __raw_readsl(p,d,l)
#define ioread32_rep(p,d,c) __raw_readsl(p,d,c)

The semantic effect is switching from readl() -> readsl() or
conversely ioread32 -> ioread32_rep() which will use
__raw accessors in native endianness rather than LE access.

Which is what you want if the bus will do byte swapping. Which
we don't know if it does, because noone has such a system and
can verify.

If the native bus is not byte swapping this will just force you to
use cpu_to_le32() on the result. That is not helpful at all.

We need to experiment with real BE hardware with this
PrimeCell to determine whether to do this, and until that is
done just don't try to outsmart the hardware by thinking ahead
and designing for the unknown, that will just fail.

Yours,
Linus Walleij
--
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: Performance regression in v3.14

[Johan Hovold]

On Thu, May 29, 2014 at 07:27:34PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 28, 2014 at 09:59:45AM +0200, Johan Hovold wrote:
> > [ +CC: Greg, Doug, Stratos, Yuyang ]
> > 
> > On Wed, May 21, 2014 at 11:00:51AM +0200, Johan Hovold wrote:
> > > On Wed, May 07, 2014 at 07:10:49AM -0700, Dirk Brandewie wrote:
> > > > On 05/06/2014 10:40 PM, Viresh Kumar wrote:
> > > > > Cc'ing Dirk who is taking care of intel-pstate driver.
> > > > >
> > > > 
> > > > Thanks Viresh I had seen this thread.
> > > > 
> > > > I am looking into it
> > > 
> > > Any updates on this, Dirk? 3.14 is still basically unusable with the
> > > intel_pstate driver.
> > > 
> > > Any fixes or workarounds posted elsewhere that I can apply in the
> > > meantime?
> > 
> > Another week and still no reply, Dirk?
> > 
> > I tried applying your (rejected) patch "intel_pstate: Remove C0
> > tracking" posted here:
> > 
> > https://lkml.org/lkml/2014/5/8/574
> > 
> > to v3.14.4 and it fixes the problem as expected.
> > 
> > So we have a commit fcb6a15c2e7e ("intel_pstate: Take core C0 time into
> > account for core busy calculation") that went into v3.14-rc2 (and was
> > even marked for *stable*) that first broke Greg KH's system:
> > 
> > https://lkml.org/lkml/2014/2/19/626
> > 
> > That was apparently fixed by e66c17683746 ("intel_pstate: Change
> > busy calculation to use fixed point math."), but still left v3.14
> > basically unusable for lower-intensity workloads such as my
> > bash-completion example and other reported regressions:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=75121
> > 
> > Sure there may be issues with v3.13 not hitting the lowest frequencies
> > but at least the system was *usable*.
> > 
> > In my opinion there's really no other option than to restore the 3.13
> > behaviour by effectively reverting fcb6a15c2e7e ("intel_pstate: Take
> > core C0 time into account for core busy calculation") until you have
> > figured out a way to take C0 into account without breaking things too
> > badly.
> 
> Dirk has posted some patches, do they fix the problem for you?

Thanks for letting me know.

As the series posted yesterday includes the effective revert
"intel_pstate: Remove C0 tracking" mentioned above, they do.  

The series does not apply at all to v3.14.4, and I choose to include
d37e2b764499 ("intel_pstate: remove unneeded sample buffers") in order
to ease backporting slightly.

I don't see much difference from applying only the revert patch or all
of them. I've included turbostat output from when running my
bash-construct on an idle system (running X, though) below.

With 3.14.4 all cores appear stuck at minimum frequency. With the
revert patch (with or without the remaining patches) frequencies are
around 3.7Ghz for all cores.

As at least one of the new patches has already raised some discussion:

http://marc.info/?l=linux-pm=140141648726863=2

perhaps we should consider simply applying and backporting the revert
(and fixed-point rounding fix) to restore v3.13 behaviour and un-break
v3.14 in the meantime?

Thanks,
Johan


v3.14.4 (with "intel_pstate: Remove C0 tracking" and a version of
"intel_pstate: Fix fixed point rounding macro" from two weeks ago):

cor CPU%c0  GHz  TSC SMI%c1%c3%c6%c7 CTMP PTMP   %pc2   
%pc3   %pc6   %pc7  Pkg_W  Cor_W GFX_W
 12.63 3.88 3.39   0  13.32   0.02   0.06  73.96   41   41   0.00   
0.00   0.00   0.00  18.69  10.70  0.00
  0   0   0.50 3.88 3.39   0   3.28   0.10   0.24  95.88   31   41   0.00   
0.00   0.00   0.00  18.69  10.70  0.00
  0   4   0.57 3.87 3.39   0   3.22
  1   1   0.09 3.61 3.39   0   0.03   0.00   0.00  99.88   31
  1   5   0.01 3.74 3.39   0   0.11
  2   2   0.02 3.61 3.39   0   0.02   0.00   0.00  99.96   31
  2   6   0.01 3.80 3.39   0   0.04
  3   3  99.85 3.89 3.39   0   0.04   0.00   0.00   0.12   41
  3   7   0.01 3.81 3.39   0  99.87
1.194291 sec

v3.14.4 (with patches from yesterday):

cor CPU%c0  GHz  TSC SMI%c1%c3%c6%c7 CTMP PTMP   %pc2   
%pc3   %pc6   %pc7  Pkg_W  Cor_W GFX_W
 12.63 3.88 3.39   0  13.33   0.04   0.04  73.95   44   45   0.00   
0.00   0.00   0.00  18.65  10.70  0.00
  0   0   0.52 3.88 3.39   0   3.28   0.17   0.16  95.88   33   45   0.00   
0.00   0.00   0.00  18.65  10.70  0.00
  0   4   0.58 3.87 3.39   0   3.22
  1   1   0.10 3.45 3.39   0   0.05   0.00   0.00  99.85   34
  1   5   0.01 3.67 3.39   0   0.14
  2   2   0.02 3.56 3.39   0   0.04   0.00   0.00  99.94   34
  2   6   0.01 3.63 3.39   0   0.05
  3   3  99.82 3.89 3.39   0   0.05   0.00   0.00   0.13   44
  3   7   0.01 3.70 3.39   0  99.86
1.197190 sec

v3.14.4 (current stable):

cor CPU%c0  GHz  TSC SMI%c1%c3%c6%c7 CTMP PTMP   %pc2   
%pc3   %pc6   %pc7  Pkg_W  Cor_W GFX_W
 12.86 0.82 3.39   0  14.16   0.00   0.00  72.97   32   32   0.00   
0.00   0.00   0.00   5.55   0.61  0.00
  0   0   2.26 0.82 3.39   0   5.74   0.01   0.02  91.98   32   32   0.00   
0.00   0.00   0.00 

Re: Unionmount and overlayfs testsuite

[David Howells]

J. R. Okajima  wrote:

> I've found some interesting cases.
> 
> - impermissible.test,
>   open_file_as_bin -t -w $file -E EACCES
>   When $termslash is "/", a '/' is appended to the expanded $file, such
>   as "/path/fileA/". If fileA is a regular file, that path is obviously
>   wrong. Does UnionMount expect EACCES in this case too?
>   Should it be ENOTDIR?
>   It might be better to change
>   errcode=EACCES
>   test ! "$termslash" = "" && errcode=ENOTDIR
>   open_file_as_bin -t -w $file -E $errcode

I'd never got to the end of the impermissible test because the utimes test
fails on both unionmount and overlayfs.  I'll have to address the termslash
alterations at some point.

> - readlink.test,
>   fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E 
> EINVAL}
>   It expects "$testdir/direct_dir_sym100". Does it mean UnionMount
>   converts the target path?
>   For example,
>   - /u = /rw + /ro
>   - /rw/symlinkA doesn't exist
>   - /ro/symlinkA points to /ro/fileA

No.  Unionmount unions are constructed by mounting the lower layers all on the
same mountpoint and then mounting the union over them, also on the same
mountpoint.  So their paths are coincident.

>   Does readlink(2) return "/u/fileA" instead of /ro/fileA?"

No.

The test suite sets the lower symlink to point to the union path for its target.

[root@andromeda union-testsuite]# readlink /lower/a/indirect_dir_sym100 
/mnt/a/direct_dir_sym100

> And all tests should be done by a superuser?

Yes.  It also will test things like mknod at some point and runs things as
other users to test permissions.

David
--
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/1] PINCTRL: Warn if direct IRQ GPIO set to output

[Mika Westerberg]

On Tue, May 27, 2014 at 12:26:44PM -0700, eric.er...@linux.intel.com wrote:
> From: Eric Ernst 
> 
> For Baytrail, you should never set a GPIO set to direct_irq
> to output mode.  When direct_irq_en is set for a GPIO, it is
> tied directly to an APIC internally, and making the pad output
> does not make any sense. Assert a WARN() in the event this happens.

Can't we just clear that flag when the GPIO is requested? Or is this
something which can't be done at this point?
--
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] Implement Batched (group) ticket lock

[Raghavendra K T]

On 05/30/2014 04:15 AM, Waiman Long wrote:

On 05/28/2014 08:16 AM, Raghavendra K T wrote:

- we need an intelligent way to nullify the effect of batching for
baremetal
  (because extra cmpxchg is not required).


To do this, you will need to have 2 slightly different algorithms
depending on the paravirt_ticketlocks_enabled jump label.


Thanks for the hint Waiman.

[...]

+spin:
+for (;;) {
+inc.head = ACCESS_ONCE(lock->tickets.head);
+if (!(inc.head&  TICKET_LOCK_HEAD_INC)) {
+new.head = inc.head | TICKET_LOCK_HEAD_INC;
+if (cmpxchg(>tickets.head, inc.head, new.head)
+== inc.head)
+goto out;
+}
+cpu_relax();
+}
+


It had taken me some time to figure out the the LSB of inc.head is used
as a bit lock for the contending tasks in the spin loop. I would suggest
adding some comment here to make it easier to look at.


Agree. 'll add a comment.

[...]

+#define TICKET_BATCH0x4 /* 4 waiters can contend simultaneously */
+#define TICKET_LOCK_BATCH_MASK
(~(TICKET_BATCH<

I don't think TAIL_INC has anything to do with setting the BATCH_MASK.
It works here because TAIL_INC is 2. I think it is clearer to define it
as either "(~(TICKET_BATCH<

You are right.
Thanks for pointing out. Your expression is simple and clearer. 'll use
one of them.

--
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 13/14] perf tests: Add test for caching dso file descriptors

[Jiri Olsa]

On Fri, May 30, 2014 at 11:11:20AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Thu, 29 May 2014 10:37:32 +0200, Jiri Olsa wrote:
> > On Thu, May 29, 2014 at 09:06:05AM +0900, Namhyung Kim wrote:
> >> On Tue, 27 May 2014 09:54:36 +0200, Jiri Olsa wrote:
> >> > On Tue, May 27, 2014 at 10:36:44AM +0900, Namhyung Kim wrote:
> >> >> On Thu, 15 May 2014 19:23:34 +0200, Jiri Olsa wrote:
> >> >> > Adding test that setup test_dso_data__fd_limit and test
> >> >> > dso data file descriptors are cached appropriately.
> >> >> 
> >> >> [SNIP]
> >> >> > +static long open_files_cnt(void)
> >> >> > +{
> >> >> > + char path[PATH_MAX];
> >> >> > + struct dirent *dent;
> >> >> > + DIR *dir;
> >> >> > + long nr = 0;
> >> >> > + int n;
> >> >> > +
> >> >> > + n = scnprintf(path, PATH_MAX, "%s/self/fd", 
> >> >> > procfs__mountpoint());
> >> >> > + TEST_ASSERT_VAL("couldn't get fd path", n < PATH_MAX);
> >> >> 
> >> >> Looks like an unnecessary check since the scnprintf() cannot return more
> >> >> than (or equal to) PATH_MAX.
> >> >
> >> > once it's equal it's bad.. as the man says:
> >> > "return value of size or more means that the output was  truncated"
> >> 
> >> Did you see "sn"printf?
> >
> > yes, I just double checked.. jirka
> 
> Please see "scn"printf then. :)  It does something like below..
> 
>   i = snprintf(buf, size, ...);
>   return (i >= size) ? : size - 1 : i;

aaargh... ok ;-)

thanks,
jirka
--
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] fs: proc/stat: use usual seq_file ops rather than single_open

[Heiko Carstens]

On Wed, May 28, 2014 at 03:37:04PM -0700, Andrew Morton wrote:
> On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens  
> wrote:
> > With this patch it should not happen anymore that reading /proc/stat
> > fails because of a failing high order memory allocation.
> 
> So this deletes the problematic allocation which [1/2] kind-of fixed,
> yes?

Yes.

> I agree with Ian - there's a hotplugging race.  And [1/2] doesn't do
> anything to address the worst-case allocation size.  So I think we may
> as well do this all in a single patch.

Fine with me. However the hotplugging race in 1/2 doesn't matter: if the
result doesn't fit into the preallocated buffer the seq_file infrastructure
would simply allocate a buffer twice as large as before and retry.

The point of patch 1/2 was to have a patch that probably solves the problem
almost always ;) , without having the problems you describe below.

> Without having looked closely at the code I worry a bit about the
> effects.  /proc/pid/stat is a complex thing and its contents will vary

It's /proc/stat not /proc/pid/stat.

> So..  can we take this up for 3.16-rc1?  See if we can get some careful
> review done then and test it for a couple of months?

Sure.

> Meanwhile, the changelog looks a bit hastily thrown together - some
> smoothing would be nice, and perhaps some work spent identifying
> possible behavioural changes.  Timing changes, locking canges, effects
> of concurrent fork/exit activity etc?

Well... I'll try to come up with something better. Even though I only
forward ported an existing patch to address a memory allocation failure.
Oh oh...

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

[PATCH v3] zram: remove global tb_lock with fine grain lock

[Weijie Yang]

Currently, we use a rwlock tb_lock to protect concurrent access to
the whole zram meta table. However, according to the actual access model,
there is only a small chance for upper user to access the same table[index],
so the current lock granularity is too big.

The idea of optimization is to change the lock granularity from whole
meta table to per table entry (table -> table[index]), so that we can
protect concurrent access to the same table[index], meanwhile allow
the maximum concurrency.
With this in mind, several kinds of locks which could be used as a
per-entry lock were tested and compared:

Test environment:
x86-64 Intel Core2 Q8400, system memory 4GB, Ubuntu 12.04,
kernel v3.15.0-rc3 as base, zram with 4 max_comp_streams LZO.

iozone test:
iozone -t 4 -R -r 16K -s 200M -I +Z
(1GB zram with ext4 filesystem, take the average of 10 tests, KB/s)

  Test   base  CASspinlockrwlock   bit_spinlock
---
 Initial write  1381094   1425435   1422860   1423075   1421521
   Rewrite  1529479   1641199   1668762   1672855   1654910
  Read  8468009  11324979  11305569  7273  10997202
   Re-read  8467476  11260914  11248059  11145336  10906486
  Reverse Read  6821393   8106334   8282174   8279195   8109186
   Stride read  7191093   8994306   9153982   8961224   9004434
   Random read  7156353   8957932   9167098   8980465   8940476
Mixed workload  4172747   5680814   5927825   5489578   5972253
  Random write  1483044   1605588   1594329   1600453   1596010
Pwrite  1276644   1303108   1311612   1314228   1300960
 Pread  4324337   4632869   4618386   4457870   4500166

To enhance the possibility of access the same table[index] concurrently,
set zram a small disksize(10MB) and let threads run with large loop count.

fio test:
fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers
--scramble_buffers=1 --direct=1 --loops=3000 --numjobs=4
--filename=/dev/zram0 --name=seq-write --rw=write --stonewall
--name=seq-read --rw=read --stonewall --name=seq-readwrite
--rw=rw --stonewall --name=rand-readwrite --rw=randrw --stonewall
(10MB zram raw block device, take the average of 10 tests, KB/s)

Test base CASspinlockrwlock  bit_spinlock
-
seq-write   933789   999357   1003298995961   1001958
 seq-read  5634130  6577930   6380861   6243912   6230006
   seq-rw  1405687  1638117   1640256   1633903   1634459
  rand-rw  1386119  1614664   1617211   1609267   1612471

All the optimization methods show a higher performance than the base,
however, it is hard to say which method is the most appropriate.

On the other hand, zram is mostly used on small embedded system, so we
don't want to increase any memory footprint.

This patch pick the bit_spinlock method, pack object size and page_flag
into an unsigned long table.value, so as to not increase any memory
overhead on both 32-bit and 64-bit system.

On the third hand, even though different kinds of locks have different
performances, we can ignore this difference, because:
if zram is used as zram swapfile, the swap subsystem can prevent concurrent
access to the same swapslot;
if zram is used as zram-blk for set up filesystem on it, the upper filesystem
and the page cache also prevent concurrent access of the same block mostly.
So we can ignore the different performances among locks.

Changes since v1: https://lkml.org/lkml/2014/5/5/1
  - replace CAS method with bit_spinlock method
  - rename zram_test_flag() to zram_test_zero()
  - add some comments

Changes since v2: https://lkml.org/lkml/2014/5/15/113
  - change size type from int to size_t in zram_set_obj_size()
  - refactor zram_set_obj_size() to make it readable
  - add comments

Signed-off-by: Weijie Yang 
---
 drivers/block/zram/zram_drv.c |   89 -
 drivers/block/zram/zram_drv.h |   22 +++---
 2 files changed, 68 insertions(+), 43 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9849b52..166e882 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -179,23 +179,32 @@ static ssize_t comp_algorithm_store(struct device *dev,
return len;
 }
 
-/* flag operations needs meta->tb_lock */
-static int zram_test_flag(struct zram_meta *meta, u32 index,
-   enum zram_pageflags flag)
+static int zram_test_zero(struct zram_meta *meta, u32 index)
 {
-   return meta->table[index].flags & BIT(flag);
+   return meta->table[index].value & BIT(ZRAM_ZERO);
 }
 
-static void zram_set_flag(struct zram_meta *meta, u32 index,
-   enum zram_pageflags flag)
+static void zram_set_zero(struct zram_meta *meta, u32 index)
 {
-   meta->table[index].flags |= BIT(flag);
+   meta->table[index].value |= BIT(ZRAM_ZERO);
 }
 
-static void zram_clear_flag(struct zram_meta *meta, u32 

Re: [PATCH] base: platform: name the device already during allocation

[Heikki Krogerus]

On Wed, May 28, 2014 at 01:58:06PM -0700, Greg KH wrote:
> On Mon, Apr 28, 2014 at 03:09:27PM +0300, Heikki Krogerus wrote:
> > This allows resources such as GPIOs and clocks, which can be
> > matched based on the device name when requested, to be
> > assigned even when PLATFORM_DEVID_AUTO is used.
> 
> Why would anyone want to do that?

The idea is to be able to share more resources of the parent device
with child platform devices that are created on fly without tricks.

Many frameworks offer lookup tables that we can use to bind the device
to a resource. I want to be able to always use those instead of being
forced to deliver the resources with platform_data in this kind of
cases..

> > 
> > Signed-off-by: Heikki Krogerus 
> > ---
> >  drivers/base/platform.c | 77 
> > ++---
> >  1 file changed, 47 insertions(+), 30 deletions(-)
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 5b47210..697896d 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -174,11 +174,45 @@ struct platform_object {
> >   */
> >  void platform_device_put(struct platform_device *pdev)
> >  {
> > -   if (pdev)
> > -   put_device(>dev);
> > +   if (!pdev)
> > +   return;
> > +
> > +   if (pdev->id_auto) {
> > +   ida_simple_remove(_devid_ida, pdev->id);
> > +   pdev->id = PLATFORM_DEVID_AUTO;
> > +   }
> > +
> > +   put_device(>dev);
> >  }
> >  EXPORT_SYMBOL_GPL(platform_device_put);
> >  
> > +static int pdev_set_name(struct platform_device *pdev)
> > +{
> > +   int ret;
> > +
> > +   switch (pdev->id) {
> > +   default:
> > +   return dev_set_name(>dev, "%s.%d", pdev->name,  pdev->id);
> > +   case PLATFORM_DEVID_NONE:
> > +   return dev_set_name(>dev, "%s", pdev->name);
> > +   case PLATFORM_DEVID_AUTO:
> > +   /*
> > +* Automatically allocated device ID. We mark it as such so
> > +* that we remember it must be freed, and we append a suffix
> > +* to avoid namespace collision with explicit IDs.
> > +*/
> > +   ret = ida_simple_get(_devid_ida, 0, 0, GFP_KERNEL);
> > +   if (ret < 0)
> > +   return ret;
> > +   pdev->id = ret;
> > +   pdev->id_auto = true;
> > +   return dev_set_name(>dev, "%s.%d.auto", pdev->name,
> > +   pdev->id);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  static void platform_device_release(struct device *dev)
> >  {
> > struct platform_object *pa = container_of(dev, struct platform_object,
> > @@ -211,6 +245,10 @@ struct platform_device *platform_device_alloc(const 
> > char *name, int id)
> > device_initialize(>pdev.dev);
> > pa->pdev.dev.release = platform_device_release;
> > arch_setup_pdev_archdata(>pdev);
> > +   if (pdev_set_name(>pdev)) {
> > +   kfree(pa);
> > +   return NULL;
> > +   }
> > }
> >  
> > return pa ? >pdev : NULL;
> > @@ -291,28 +329,6 @@ int platform_device_add(struct platform_device *pdev)
> >  
> > pdev->dev.bus = _bus_type;
> >  
> > -   switch (pdev->id) {
> > -   default:
> > -   dev_set_name(>dev, "%s.%d", pdev->name,  pdev->id);
> > -   break;
> > -   case PLATFORM_DEVID_NONE:
> > -   dev_set_name(>dev, "%s", pdev->name);
> > -   break;
> > -   case PLATFORM_DEVID_AUTO:
> > -   /*
> > -* Automatically allocated device ID. We mark it as such so
> > -* that we remember it must be freed, and we append a suffix
> > -* to avoid namespace collision with explicit IDs.
> > -*/
> > -   ret = ida_simple_get(_devid_ida, 0, 0, GFP_KERNEL);
> > -   if (ret < 0)
> > -   goto err_out;
> > -   pdev->id = ret;
> > -   pdev->id_auto = true;
> > -   dev_set_name(>dev, "%s.%d.auto", pdev->name, pdev->id);
> > -   break;
> > -   }
> > -
> > for (i = 0; i < pdev->num_resources; i++) {
> > struct resource *p, *r = >resource[i];
> >  
> > @@ -355,7 +371,6 @@ int platform_device_add(struct platform_device *pdev)
> > release_resource(r);
> > }
> >  
> > - err_out:
> > return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(platform_device_add);
> > @@ -375,11 +390,6 @@ void platform_device_del(struct platform_device *pdev)
> > if (pdev) {
> > device_del(>dev);
> >  
> > -   if (pdev->id_auto) {
> > -   ida_simple_remove(_devid_ida, pdev->id);
> > -   pdev->id = PLATFORM_DEVID_AUTO;
> > -   }
> > -
> > for (i = 0; i < pdev->num_resources; i++) {
> > struct resource *r = >resource[i];
> > unsigned long type = resource_type(r);
> > @@ -397,8 +407,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> >   */
> >  int 

Re: [PATCH 0/10] ACPI enumeration rework (was: Re: [PATCH V7 00/11] ACPI: ACPI enumeration rework)

[Mika Westerberg]

On Fri, May 30, 2014 at 04:20:41AM +0200, Rafael J. Wysocki wrote:
> On Friday, May 23, 2014 02:02:22 AM Zhang Rui wrote:
> > Hi, all,
> > 
> > Currently, PNP bus is used as the default bus for for enumerating ACPI
> > devices with _HID/_CID.
> > For a device that needs to be enumerated to platform bus, we need to add
> > its id string to the platform scan handler white list explicitly.
> > 
> > This becomes a problem as more and more _HID devices need to be
> > enumerated to platform bus nowadays, thus the list is continuously growing.
> > 
> > So, a solution that uses platform bus for _HID enumeration by default
> > is preferred.
> > 
> 
> OK, this has had several rounds of review already and we're really starting
> to run out of time with it, so my version of this patchset follows.
> 
> It is mostly based on your patches, but reordered and with some major
> changes.  Compiled only for now, so please let me know if there's any
> breakage in it.  [The last patch will not apply without update of the
> device list being removed, but generally this is on top of linux-next
> material.]

The series looks good to me now.

You can add

Reviewed-by: Mika Westerberg 

to all the patches if you like.
--
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] gpio: Add support for Intel SoC PMIC (Crystal Cove)

[Mika Westerberg]

On Thu, May 29, 2014 at 05:22:05PM +0200, Linus Walleij wrote:
> On Thu, May 29, 2014 at 6:03 PM, Grygorii Strashko
>  wrote:
> 
> > Also, I'd like to note that GPIO IRQs can be accessible not only
> > when GPIO chips is added, but also when IRQ domain is registered
> > (at least it's valid for DT cases). In these cases gpiod_to_irq()
> > might be not used at all.
> 
> Yes. We concluded some time back that gpio_chip:s and
> irq_chip:s are orthogonal abstractions: you should be able
> to use one of them without paying any respect to the other.
> 
> We only added the ability to flag GPIO lines as used for
> IRQs so they would not be set to output by mistake...
> (Straightening up the semantics.)
> 
> The only real semantic dependence that really makes sense
> is .to_irq() which leads to this semantic registration ordering.

acpi_gpiochip_request_interrupts() depends on ->to_irq() to be set
before acpi_gpiochip_add() is called. Since the ordering changes this
won't work anymore.

I'm thinking that could we solve this so that we call
acpi_gpiochip_request_interrupts() at the end of gpiochip_irqchip_add()
and convert both pinctrl-baytrail and gpio-lynxpoint to use
gpiochip_irqchip_add()?
--
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 0/5] efuse driver for Tegra

[Peter De Schrijver]

On Thu, May 29, 2014 at 09:01:27PM +0200, Stephen Warren wrote:
> On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> > This driver allows userspace to read the raw efuse data. Its userspace
> > interface is modelled after the sunxi_sid driver which provides similar
> > functionality for some Allwinner SoCs. It has been tested on
> > Tegra20 (ventana), Tegra30 (beaverboard), Tegra114 (dalmore) and
> > Tegra124 (jetson TK1).
> 
> > Changes since v4:
> > 
> > * Provide fallback to hardcoded 0x7800 in case the apbmisc DT node is
> >   missing. This is exactly what the current code does and prevents a system
> >   crash in that case due to an invalid memory access by tegra_read_chipid()
> 
> Wouldn't it be better to simply return an error?

This would mean you can't boot a system with these patches applied unless you
also update the device tree. The system would crash during boot because CCF
relies on tegra_read_chipid() as an APB barrier. Also tegra_boot_secondary()
relies on the chipid to select the correct method for booting secondary cores.

Cheers,

Peter.
--
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] sound: remove checks for CONFIG_SND_DEBUG_ROM

[Takashi Iwai]

At Thu, 29 May 2014 18:58:25 +0200,
Paul Bolle wrote:
> 
> Checks for CONFIG_SND_DEBUG_ROM were added in v2.5.5 but a Kconfig
> symbol SND_DEBUG_ROM was never added. These checks have always
> evaluated to false. Remove them and the printk()s they hide.
> 
> Signed-off-by: Paul Bolle 
> ---
> Untested.
> 
> Perhaps one is expected to define this debugging macro by hand, somehow.
> In that case it would be nice to drop the CONFIG_ prefix.

Yeah, but I guess a developer can add such printk anyway easily, so
let's clean up the code at first.  So, I took your patch now as is.

thanks,

Takashi

> 
>  sound/isa/gus/interwave.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/sound/isa/gus/interwave.c b/sound/isa/gus/interwave.c
> index 5abbbe477d16..ad55e5cb8e94 100644
> --- a/sound/isa/gus/interwave.c
> +++ b/sound/isa/gus/interwave.c
> @@ -442,17 +442,11 @@ static void snd_interwave_detect_memory(struct 
> snd_gus_card *gus)
>   for (bank_pos = 0; bank_pos < 16L * 1024L * 1024L; bank_pos += 4L * 
> 1024L * 1024L) {
>   for (i = 0; i < 8; ++i)
>   iwave[i] = snd_gf1_peek(gus, bank_pos + i);
> -#ifdef CONFIG_SND_DEBUG_ROM
> - printk(KERN_DEBUG "ROM at 0x%06x = %8phC\n", bank_pos, iwave);
> -#endif
>   if (strncmp(iwave, "INTRWAVE", 8))
>   continue;   /* first check */
>   csum = 0;
>   for (i = 0; i < sizeof(struct rom_hdr); i++)
>   csum += snd_gf1_peek(gus, bank_pos + i);
> -#ifdef CONFIG_SND_DEBUG_ROM
> - printk(KERN_DEBUG "ROM checksum = 0x%x (computed)\n", csum);
> -#endif
>   if (csum != 0)
>   continue;   /* not valid rom */
>   gus->gf1.rom_banks++;
> -- 
> 1.9.3
> 
--
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: [PATCHv2 2/3] regulator: s2mps11: Add support S2MPU02 regulator device

[Krzysztof Kozlowski]

On pią, 2014-05-30 at 09:25 +0900, Chanwoo Choi wrote:
> This patch add S2MPU02 regulator device to existing S2MPS11 device driver
> because of little difference between S2MPS1x and S2MPU02. The S2MPU02
> regulator device includes LDO[1-28] and BUCK[1-7].
> 
> Signed-off-by: Chanwoo Choi 
> [Add missing linear_min_sel of S2MPU02 LDO regulators by Jonghwa Lee]
> Signed-off-by: Jonghwa Lee 
> ---
>  drivers/mfd/sec-core.c  |  26 +++
>  drivers/regulator/s2mps11.c | 319 
> +---
>  include/linux/mfd/samsung/s2mpu02.h | 200 ++
>  3 files changed, 525 insertions(+), 20 deletions(-)
>  create mode 100644 include/linux/mfd/samsung/s2mpu02.h
> 

(...)

> diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
> index 02e2fb2..f7e5dab3d 100644
> --- a/drivers/regulator/s2mps11.c
> +++ b/drivers/regulator/s2mps11.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct s2mps11_info {
>   unsigned int rdev_num;
> @@ -40,11 +41,15 @@ struct s2mps11_info {
>   int ramp_delay16;
>   int ramp_delay7810;
>   int ramp_delay9;
> +
> + enum sec_device_type dev_type;
> +
>   /*
> -  * One bit for each S2MPS14 regulator whether the suspend mode
> +  * One bit for each S2MPS14/S2MPU02 regulator whether the suspend mode
>* was enabled.
>*/
> - unsigned int s2mps14_suspend_state:30;
> + unsigned long long s2mps14_suspend_state:35;
> +
>   /* Array of size rdev_num with GPIO-s for external sleep control */
>   int *ext_control_gpio;
>  };
> @@ -415,12 +420,24 @@ static int s2mps14_regulator_enable(struct 
> regulator_dev *rdev)
>   struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
>   unsigned int val;
>  
> - if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
> - val = S2MPS14_ENABLE_SUSPEND;
> - else if (gpio_is_valid(s2mps11->ext_control_gpio[rdev_get_id(rdev)]))
> - val = S2MPS14_ENABLE_EXT_CONTROL;
> - else
> - val = rdev->desc->enable_mask;
> + switch (s2mps11->dev_type) {
> + case S2MPS14X:
> + if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
> + val = S2MPS14_ENABLE_SUSPEND;
> + else if 
> (gpio_is_valid(s2mps11->ext_control_gpio[rdev_get_id(rdev)]))
> + val = S2MPS14_ENABLE_EXT_CONTROL;
> + else
> + val = rdev->desc->enable_mask;
> + break;
> + case S2MPU02:
> + if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
> + val = S2MPU02_ENABLE_SUSPEND;
> + else
> + val = rdev->desc->enable_mask;
> + break;
> + default:
> + return -EINVAL;
> + };
>  
>   return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
>   rdev->desc->enable_mask, val);
> @@ -431,16 +448,42 @@ static int s2mps14_regulator_set_suspend_disable(struct 
> regulator_dev *rdev)
>   int ret;
>   unsigned int val;
>   struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
> + int rdev_id = rdev_get_id(rdev);
>  
> - /* LDO3 should be always on and does not support suspend mode */
> - if (rdev_get_id(rdev) == S2MPS14_LDO3)
> - return 0;
> + /* Below LDO should be always on or does not support suspend mode. */
> + switch (s2mps11->dev_type) {
> + case S2MPS14X:
> + switch (rdev_id) {
> + case S2MPS14_LDO3:
> + return 0;
> + };
> + case S2MPU02:
> + switch (rdev_id) {
> + case S2MPU02_LDO13:
> + case S2MPU02_LDO14:
> + case S2MPU02_LDO15:
> + case S2MPU02_LDO16:
> + case S2MPU02_LDO17:
> + case S2MPU02_BUCK7:
> + return 0;
> + };
> + default:
> + return -EINVAL;
> + };
>  
>   ret = regmap_read(rdev->regmap, rdev->desc->enable_reg, );
>   if (ret < 0)
>   return ret;
>  
> - s2mps11->s2mps14_suspend_state |= (1 << rdev_get_id(rdev));
> + switch (s2mps11->dev_type) {
> + case S2MPS14X:
> + case S2MPU02:
> + s2mps11->s2mps14_suspend_state |= (1 << rdev_get_id(rdev));
> + break;
> + default:
> + return -EINVAL;
> + };
> +

I think this change is not needed. You are actually returning EINVAL on
wrong devices in switch above so:
s2mps11->s2mps14_suspend_state |= (1 << rdev_get_id(rdev));
would be safe and sufficient.

Anyway:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH 4/4] kvm: Implement PEBS virtualization

[Gleb Natapov]

On Thu, May 29, 2014 at 06:12:07PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> PEBS (Precise Event Bases Sampling) profiling is very powerful,
> allowing improved sampling precision and much additional information,
> like address or TSX abort profiling. cycles:p and :pp uses PEBS.
> 
> This patch enables PEBS profiling in KVM guests.
That sounds really cool!

> 
> PEBS writes profiling records to a virtual address in memory. Since
> the guest controls the virtual address space the PEBS record
> is directly delivered to the guest buffer. We set up the PEBS state
> that is works correctly.The CPU cannot handle any kinds of faults during
> these guest writes.
> 
> To avoid any problems with guest pages being swapped by the host we
> pin the pages when the PEBS buffer is setup, by intercepting
> that MSR.
It will avoid guest page to be swapped, but shadow paging code may still drop
shadow PT pages that build a mapping from DS virtual address to the guest page.
With EPT it is less likely to happen (but still possible IIRC depending on 
memory
pressure and how much memory shadow paging code is allowed to use), without EPT
it will happen for sure.

> 
> Typically profilers only set up a single page, so pinning that is not
> a big problem. The pinning is limited to 17 pages currently (64K+1)
> 
> In theory the guest can change its own page tables after the PEBS
> setup. The host has no way to track that with EPT. But if a guest
> would do that it could only crash itself. It's not expected
> that normal profilers do that.
Spec says:

 The following restrictions should be applied to the DS save area.
   • The three DS save area sections should be allocated from a
   non-paged pool, and marked accessed and dirty. It is the responsibility
   of the operating system to keep the pages that contain the buffer
   present and to mark them accessed and dirty. The implication is that
   the operating system cannot do “lazy” page-table entry propagation
   for these pages.

There is nothing, as far as I can see, that says what will happen if the
condition is not met. I always interpreted it as undefined behaviour so
anything can happen including CPU dies completely.  You are saying above
on one hand that CPU cannot handle any kinds of faults during write to
DS area, but on the other hand a guest could only crash itself. Is this
architecturally guarantied?


> 
> The patch also adds the basic glue to enable the PEBS CPUIDs
> and other PEBS MSRs, and ask perf to enable PEBS as needed.
> 
> Due to various limitations it currently only works on Silvermont
> based systems.
> 
> This patch doesn't implement the extended MSRs some CPUs support.
> For example latency profiling on SLM will not work at this point.
> 
> Timing:
> 
> The emulation is somewhat more expensive than a real PMU. This
> may trigger the expensive PMI detection in the guest.
> Usually this can be disabled with
> echo 0 > /proc/sys/kernel/perf_cpu_time_max_percent
> 
> Migration:
> 
> In theory it should should be possible (as long as we migrate to
> a host with the same PEBS event and the same PEBS format), but I'm not
> sure the basic KVM PMU code supports it correctly: no code to
> save/restore state, unless I'm missing something. Once the PMU
> code grows proper migration support it should be straight forward
> to handle the PEBS state too.
> 
> Signed-off-by: Andi Kleen 
> ---
>  arch/x86/include/asm/kvm_host.h   |   6 ++
>  arch/x86/include/uapi/asm/msr-index.h |   4 +
>  arch/x86/kvm/cpuid.c  |  10 +-
>  arch/x86/kvm/pmu.c| 184 
> --
>  arch/x86/kvm/vmx.c|   6 ++
>  5 files changed, 196 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 7de069af..d87cb66 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -319,6 +319,8 @@ struct kvm_pmc {
>   struct kvm_vcpu *vcpu;
>  };
>  
> +#define MAX_PINNED_PAGES 17 /* 64k buffer + ds */
> +
>  struct kvm_pmu {
>   unsigned nr_arch_gp_counters;
>   unsigned nr_arch_fixed_counters;
> @@ -335,6 +337,10 @@ struct kvm_pmu {
>   struct kvm_pmc fixed_counters[INTEL_PMC_MAX_FIXED];
>   struct irq_work irq_work;
>   u64 reprogram_pmi;
> + u64 pebs_enable;
> + u64 ds_area;
> + struct page *pinned_pages[MAX_PINNED_PAGES];
> + unsigned num_pinned_pages;
>  };
>  
>  enum {
> diff --git a/arch/x86/include/uapi/asm/msr-index.h 
> b/arch/x86/include/uapi/asm/msr-index.h
> index fcf2b3a..409a582 100644
> --- a/arch/x86/include/uapi/asm/msr-index.h
> +++ b/arch/x86/include/uapi/asm/msr-index.h
> @@ -72,6 +72,10 @@
>  #define MSR_IA32_PEBS_ENABLE 0x03f1
>  #define MSR_IA32_DS_AREA 0x0600
>  #define MSR_IA32_PERF_CAPABILITIES   0x0345
> +#define PERF_CAP_PEBS_TRAP   (1U << 6)
> +#define PERF_CAP_ARCH_REG(1U << 7)
> +#define 

Re: [PATCH] sound: remove checks for CONFIG_BCM_CS4297A_CSWARM

[Takashi Iwai]

At Thu, 29 May 2014 18:51:44 +0200,
Paul Bolle wrote:
> 
> Checks for CONFIG_BCM_CS4297A_CSWARM were added in v2.6.11. The related
> Kconfig symbol was never added so these checks always evaluated to true.
> Remove them.
> 
> Signed-off-by: Paul Bolle 

Thanks, applied.


Takashi

> ---
> Untested.
> 
>  sound/oss/swarm_cs4297a.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/sound/oss/swarm_cs4297a.c b/sound/oss/swarm_cs4297a.c
> index f851fd0e199c..a33e8ce8085b 100644
> --- a/sound/oss/swarm_cs4297a.c
> +++ b/sound/oss/swarm_cs4297a.c
> @@ -2625,15 +2625,12 @@ static int __init cs4297a_init(void)
>   u32 pwr, id;
>   mm_segment_t fs;
>   int rval;
> -#ifndef CONFIG_BCM_CS4297A_CSWARM
>   u64 cfg;
>   int mdio_val;
> -#endif
>  
>   CS_DBGOUT(CS_INIT | CS_FUNCTION, 2, printk(KERN_INFO 
>   "cs4297a: cs4297a_init_module()+ \n"));
>  
> -#ifndef CONFIG_BCM_CS4297A_CSWARM
>  mdio_val = __raw_readq(KSEG1 + A_MAC_REGISTER(2, R_MAC_MDIO)) &
>  (M_MAC_MDIO_DIR|M_MAC_MDIO_OUT);
>  
> @@ -2659,7 +2656,6 @@ static int __init cs4297a_init(void)
>  __raw_writeq(mdio_val | M_MAC_GENC, KSEG1+A_MAC_REGISTER(2, 
> R_MAC_MDIO));
>  /* Give the codec some time to finish resetting (start the bit 
> clock) */
>  udelay(100);
> -#endif
>  
>   if (!(s = kzalloc(sizeof(struct cs4297a_state), GFP_KERNEL))) {
>   CS_DBGOUT(CS_ERROR, 1, printk(KERN_ERR
> -- 
> 1.9.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the pinctrl tree

[Linus Walleij]

On Fri, May 30, 2014 at 8:08 AM, Stephen Rothwell  wrote:

> Hi Linus,
>
> After merging the pinctrl tree, today's linux-next build (arm 
> multi_v7_defconfig)
> failed like this:
>
> drivers/pinctrl/sirf/pinctrl-sirf.c: In function 'sirfsoc_gpio_handle_irq':
> drivers/pinctrl/sirf/pinctrl-sirf.c:578:11: error: 'sgpio_chip' undeclared 
> (first use in this function)
>
> Caused by commit 294d1351ff47 ("pinctrl: sirf: switch to using
> allocated state container").

Grr a bad cherry-pick from my side. I've fixed it up today.
Thanks a lot for this Stephen.

Yours,
Linus Walleij
--
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] fence: Use smp_mb__before_atomic()

[Thierry Reding]

On Wed, May 28, 2014 at 01:51:45PM -0700, Greg Kroah-Hartman wrote:
> On Wed, May 28, 2014 at 04:26:32PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic())
> > deprecated the smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}*()
> > functions in favour of the unified smp_mb__{before,after}_atomic().
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/base/fence.c | 4 ++--
> 
> Where does this file come from?  I've not seen it before, and it's not
> in my tree.

I think it came in through Sumit's tree and it's only in linux-next I
believe.

Thierry


pgpWJZU2d2Lns.pgp
Description: PGP signature

Re: [PATCH] drm/exynos: remove unnecessary exynos_hdmi.h file

[Lee Jones]

> > The exynos_hdmi.h has been used for the dedicated i2c drivers
> > that were already removed. Thus, the unnecessary exynos_hdmi.h
> > should be removed.
> > 
> > Signed-off-by: Jingoo Han 
> > ---
> >  drivers/gpu/drm/exynos/exynos_hdmi.h |   23 ---
> >  1 file changed, 23 deletions(-)
> >  delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmi.h
> 
> https://lkml.org/lkml/2014/5/29/810

Oh, I see.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] kexec : add sparse memory related values to vmcore

[Liu hua]

On 2014/5/29 8:13, Simon Horman wrote:
> On Wed, May 28, 2014 at 09:49:56PM +0800, Liu Hua wrote:
>> This patch deales with sparse memory model.
>>
>> For ARM32 platforms, different vendors may define different
>> SECTION_SIZE_BITS, which we did not write to vmcore.
>>
>> For example:
>>
>>   1 arch/arm/mach-clps711x/include/mach/memory.h
>> #define SECTION_SIZE_BITS 24
>>   2 arch/arm/mach-exynos/include/mach/memory.h
>> #define SECTION_SIZE_BITS 28
>>   3 arch/arm/mach-sa1100/include/mach/memory.h
>> #define SECTION_SIZE_BITS 27
> 
> I wonder if this problem will eventually go away, or at least only
> apply to older platforms, as ARM moves towards multiplatform: a single
> kernel for more than one platform.

For ARM32 platform, it may cost a long time. And when glancing over
the commit log of kernel, we can find this macro changed several times.
The user space tools must take care of all these changed for compatibility.

> 
>> It is really a bad news for user space tools such as
>> makedumpfile and crash, who have to defines them as
>> macros. So for the same architecture, we may need to
>> recomile them to parse vmcores with different
>> SECTION_SIZE_BITS.
>>
>> And if we enable LPAE, MAX_PHYSMEM_SIZE can alse
>> be variable.
>>
>> This patch adds these SECTION_SIZE_BITS and MAX_PHYSMEM_SIZE
>> to vmcore. which makes user space tools more compatible.
>>
>> BTW, makedumpfile has queued the related patch.
>>
>> Signed-off-by: Liu Hua 
>> ---
>>  kernel/kexec.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index bf0b929e..8b1a193 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -1577,6 +1577,8 @@ static int __init crash_save_vmcoreinfo_init(void)
>>  VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
>>  VMCOREINFO_STRUCT_SIZE(mem_section);
>>  VMCOREINFO_OFFSET(mem_section, section_mem_map);
>> +VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
>> +VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
>>  #endif
>>  VMCOREINFO_STRUCT_SIZE(page);
>>  VMCOREINFO_STRUCT_SIZE(pglist_data);
>> -- 
>> 1.9.0
>>
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 
> .
> 


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

Re: [PATCH] drm/exynos: remove unnecessary exynos_hdmi.h file

[Lee Jones]

> The exynos_hdmi.h has been used for the dedicated i2c drivers
> that were already removed. Thus, the unnecessary exynos_hdmi.h
> should be removed.
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.h |   23 ---
>  1 file changed, 23 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmi.h

https://lkml.org/lkml/2014/5/29/810

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/11] printk: safe printing in NMI context

[Jan Kara]

On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
> On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
> > On Fri, 9 May 2014, Petr Mladek wrote:
> > 
> > > printk() cannot be used safely in NMI context because it uses internal 
> > > locks
> > > and thus could cause a deadlock. Unfortunately there are circumstances 
> > > when
> > > calling printk from NMI is very useful. For example, all WARN.*(in_nmi())
> > > would be much more helpful if they didn't lockup the machine.
> > > 
> > > Another example would be arch_trigger_all_cpu_backtrace for x86 which 
> > > uses NMI
> > > to dump traces on all CPU (either triggered by sysrq+l or from RCU stall
> > > detector).
> > 
> > I am rather surprised that this patchset hasn't received a single review 
> > comment for 3 weeks.
> > 
> > Let me point out that the issues Petr is talking about in the cover letter 
> > are real -- we've actually seen the lockups triggered by RCU stall 
> > detector trying to dump stacks on all CPUs, and hard-locking machine up 
> > while doing so.
> > 
> > So this really needs to be solved.
> 
> The lack of review may be partly due to a not very appealing changestat on an
> old codebase that is already unpopular:
> 
>  Documentation/kernel-parameters.txt |   19 +-
>  kernel/printk/printk.c  | 1218 
> +--
>  2 files changed, 878 insertions(+), 359 deletions(-)
> 
> 
> Your patches look clean and pretty nice actually. They must be seriously
> considered if we want to keep the current locked ring buffer design and
> extend it to multiple per context buffers. But I wonder if it's worth to
> continue that way with the printk ancient design.
> 
> If it takes more than 1000 line changes (including 500 added) to make it
> finally work correctly with NMIs by working around its fundamental flaws,
> shouldn't we rather redesign it to use a lockless ring buffer like ftrace
> or perf ones?
  I agree that lockless ringbuffer would be a more elegant solution but a
much more intrusive one and complex as well. Petr's patch set basically
leaves ordinary printk path intact to avoid concerns about regressions
there.

Given how difficult / time consuming is it to push any complex changes to
printk I'd push for fixing printk from NMI in this inelegant but relatively
non-contentious way and work on converting printk to lockless
implementation long term. But before spending huge amount of time on that
I'd like to get some wider concensus that this is really the way we want to
go - at least AKPM and Steven - something for discussion in the KS topic I'd
proposed I think [1].

Honza

[1]
http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000598.html
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] phy: sun4i-usb: Use PTR_ERR_OR_ZERO

[Hans de Goede]

Hi,

On 05/29/2014 08:30 AM, Sachin Kamat wrote:
> PTR_ERR_OR_ZERO simplifies the code.
> 
> Signed-off-by: Sachin Kamat 
> Cc: Hans de Goede 
> Cc: Maxime Ripard 
> ---
>  drivers/phy/phy-sun4i-usb.c |5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 115d8d5190d5..7a4ea552f621 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -306,10 +307,8 @@ static int sun4i_usb_phy_probe(struct platform_device 
> *pdev)
>  
>   dev_set_drvdata(dev, data);
>   phy_provider = devm_of_phy_provider_register(dev, sun4i_usb_phy_xlate);
> - if (IS_ERR(phy_provider))
> - return PTR_ERR(phy_provider);
>  
> - return 0;
> + return PTR_ERR_OR_ZERO(phy_provider);
>  }
>  
>  static const struct of_device_id sun4i_usb_phy_of_match[] = {
> 


Looks good:

Acked-by: Hans de Goede 

Regards,

Hans
--
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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

[Mika Westerberg]

On Thu, May 29, 2014 at 07:52:01PM +0100, Al Viro wrote:
> On Thu, May 29, 2014 at 05:53:51PM +0100, Al Viro wrote:
> > On Thu, May 29, 2014 at 09:29:42AM -0700, Linus Torvalds wrote:
> > > On Thu, May 29, 2014 at 9:23 AM, Al Viro  wrote:
> > > >
> > > > BTW, lock_parent() might be better off if in contended case it would not
> > > > bother with rename_lock and did something like this:
> > > > again:
> > > 
> > > Ack. I think that's much better.
> > 
> > Pushed to #for-linus (with dumb braino fixed - it's if (parent != dentry),
> > not if (parent)).  I'll wait with folding it back into the commit that
> > introduces lock_parent() until we get testing results...
> 
> Grrr...  Sadly, that's not good enough.  Leaking rcu_read_lock() on
> success is trivial, but there's more serious problem: suppose dentries
> involved get moved before we get to locking what we thought was parent.
> We end up taking ->d_lock on two dentries that might be nowhere near each
> other in the tree, with obvious nasty implications.  Would be _very_ hard
> to reproduce ;-/
> 
> AFAICS, the following would be safe, but I'd really appreciate any extra
> eyes on that sucker:
> 
> static inline struct dentry *lock_parent(struct dentry *dentry)
> {
> struct dentry *parent = dentry->d_parent;
> if (IS_ROOT(dentry))
> return NULL;
> if (likely(spin_trylock(>d_lock)))
> return parent;
> spin_unlock(>d_lock);
> rcu_read_lock();
> again:
> parent = ACCESS_ONCE(dentry->d_parent);
> spin_lock(>d_lock);
> /*
>  * We can't blindly lock dentry until we are sure
>  * that we won't violate the locking order.
>  * While parent->d_lock is not enough to stabilize
>* dentry->d_parent, it *is* enough to stabilize
>* dentry->d_parent == parent.
>  */
> if (unlikely(parent != dentry->d_parent)) {
> spin_unlock(>d_lock);
> goto again;
> }
> rcu_read_unlock();
> if (parent != dentry)
> spin_lock(>d_lock);
> else
> parent = NULL;
> return parent;
> }
> 
> That variant got force-pushed in place of the previous one, again at the
> head of #for-linus.  And I'm definitely not folding it in until it gets
> more review and testing.

Tested your latest #for-linus from here:

https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-linus

and the livelock is gone,

Tested-by: Mika Westerberg 

Thanks again!
--
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] clk: flatten clk tree in debugfs

[Peter De Schrijver]

> >>
> >> Mike, others,
> >>
> >> Any objections to this idea? If there's not much opposition, then maybe
> >> Peter can actually spend time fixing and testing this patch?
> >
> > Idea seems fine. I had actually considered removing the hiearchal
> > directory structure completely with the advent of clk_dump and
> > clk_summary, but if there is value in the flattened directory structure
> > then I'm all for it.
> I think the additional value of the flattened directory probably comes 
> from internal tree patches that would add set rate capability to clocks, 
> etc that would be helpful with testing.
> 

Yes. Eg. I posted a patch to dump a clocks registers for Tegra.

> Agree with all the comments so far.
> 
> Peter,
> 
> Looks like there's some support and no opposition so far. So do you want 
> to send out a real patch that's been tested and with the comments above 
> taken care of?

Yes. I will do that.

Cheers,

Peter.
--
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] ncr53c8xx: remove ancient configuration macros

[Paul Bolle]

It has not been possible to set CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO,
CONFIG_SCSI_NCR53C8XX_DISABLE_MPARITY_CHECK, and
CONFIG_SCSI_NCR53C8XX_DISABLE_PARITY_CHECK through the configuration
system since v2.1.20. Remove these ancient macros.

To enable (or disable) the functionality they covered one should edit a
header file and set related preprocessor macros. Since this is actually
a documented feature those related macros remain available.

Signed-off-by: Paul Bolle 
---
Untested.

Note that the documentation still contains
insmod ncr53c8xx

Besides insmod being outdated, the modules that use ncr53c8xx's code
appear to be NCR_Q720_mod.ko and zalon7xx.ko. So the documentation needs
probably to be updated to reflect this.

 Documentation/scsi/ncr53c8xx.txt |  5 -
 drivers/scsi/ncr53c8xx.h | 12 
 2 files changed, 17 deletions(-)

diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index 49c7b723225b..df4a1b97e659 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt
@@ -580,11 +580,6 @@ CONFIG_SCSI_NCR53C8XX_SYNC(default answer: 5)
 This frequency can be changed later with the "setsync" control command.
 0 means "asynchronous data transfers".
 
-CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO (default answer: n)
-Force synchronous negotiation for all SCSI-2 devices.
-Some SCSI-2 devices do not report this feature in byte 7 of inquiry 
-response but do support it properly (TAMARACK scanners for example).
-
 CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT   (default and only reasonable answer: n)
 If you suspect a device of yours does not properly support disconnections,
 you can answer "y". Then, all SCSI devices will never disconnect the bus 
diff --git a/drivers/scsi/ncr53c8xx.h b/drivers/scsi/ncr53c8xx.h
index e34ec5a2ea5e..8043635982bc 100644
--- a/drivers/scsi/ncr53c8xx.h
+++ b/drivers/scsi/ncr53c8xx.h
@@ -148,29 +148,17 @@
 /*
  * Force synchronous negotiation for all targets
  */
-#ifdef CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO
-#define SCSI_NCR_SETUP_FORCE_SYNC_NEGO (1)
-#else
 #define SCSI_NCR_SETUP_FORCE_SYNC_NEGO (0)
-#endif
 
 /*
  * Disable master parity checking (flawed hardwares need that)
  */
-#ifdef CONFIG_SCSI_NCR53C8XX_DISABLE_MPARITY_CHECK
-#define SCSI_NCR_SETUP_MASTER_PARITY   (0)
-#else
 #define SCSI_NCR_SETUP_MASTER_PARITY   (1)
-#endif
 
 /*
  * Disable scsi parity checking (flawed devices may need that)
  */
-#ifdef CONFIG_SCSI_NCR53C8XX_DISABLE_PARITY_CHECK
-#define SCSI_NCR_SETUP_SCSI_PARITY (0)
-#else
 #define SCSI_NCR_SETUP_SCSI_PARITY (1)
-#endif
 
 /*
  * Settle time after reset at boot-up
-- 
1.9.3

--
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/3] mfd: intel_soc_pmic: Core driver

[Lee Jones]

> >> +static int intel_soc_pmic_find_gpio_irq(struct device *dev)
> >> +{
> >> +  struct gpio_desc *desc;
> >> +  int irq;
> >> +
> >> +  desc = devm_gpiod_get_index(dev, KBUILD_MODNAME, 0);
> > 
> > What does "KBUILD_MODNAME" translate to?
> 
> It translates into "intel_soc_pmic".

Can you just put that instead?

> >> +  if (IS_ERR(desc)) {
> >> +  dev_dbg(dev, "Not using GPIO as interrupt.\n");
> > 
> > You can't have a debug print, then return an err - use dev_err().
> 
> Actually returning ENOENT here is just a hardware difference. On some
> boards the PMIC interrupt is from a GPIO line exposed by the CPU, on the
> rest (e.g. Asus T100TA) it's not. When -ENOENT is returned, probe() will
> simply use the IRQ provided by the I2C.
> 
> I will remove this line completely, and put a comment before the function.

That'll do, thanks.

> >> +static const struct i2c_device_id intel_soc_pmic_i2c_id[] = {
> >> +  {"INT33FD:00", (kernel_ulong_t)_soc_pmic_config_crc},
> >> +  { }
> >> +};
> >> +MODULE_DEVICE_TABLE(i2c, intel_soc_pmic_i2c_id);
> >> +
> >> +static struct acpi_device_id intel_soc_pmic_acpi_match[] = {
> >> +  {"INT33FD", (kernel_ulong_t)_soc_pmic_config_crc},
> >> +  { },
> >> +};
> >> +MODULE_DEVICE_TABLE(acpi, intel_soc_pmic_acpi_match);
> > 
> > Does ACPI have a match function to extact it's .driver_data attribute?
> > 
> > If so, are you using it here? If not, why not?
> > 
> 
> The ACPI table is used in i2c_device_match(), and the i2c table is used
> in i2c_device_probe(), so the id in the i2c table is actually fed to
> intel_soc_pmic_probe(). But I only found out now that having the i2c
> table alone is enough, because i2c_device_match will fallback to the i2c
> table if there's no ACPI table. So to keep it simple, I'll remove the
> ACPI table completely.

Actually, can you do it the other way round?  Minimise the i2c table
and populate the ACPI one.  I'm just about to work on a separate
patch-set which deprecates the use of the i2c table on DT and/or ACPI
only registered devices.

> By the way, the GPIO child driver got reviewed-by from Linus Walleij,
> but can't be merged because it depends on intel_soc_pmic.h. May I
> include it in next version of the patch set and have it merged along
> with the MFD driver?

Yes, if it's okay with Linus and you aapply his Ack.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pinctrl: sirf: fix a bad conflict resolution

[Linus Walleij]

Commit 294d1351ff47726f0f110b88e816cbafe89512fb
"pinctrl: sirf: switch to using allocated state container"
caused a build conflict due to a bad conflict resolution
when cherry-picking the patch. Fix it up.

Cc: Barry Song 
Signed-off-by: Linus Walleij 
---
 drivers/pinctrl/sirf/pinctrl-sirf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sirf/pinctrl-sirf.c 
b/drivers/pinctrl/sirf/pinctrl-sirf.c
index 0e835219c42e..014f5b1fee55 100644
--- a/drivers/pinctrl/sirf/pinctrl-sirf.c
+++ b/drivers/pinctrl/sirf/pinctrl-sirf.c
@@ -575,7 +575,7 @@ static void sirfsoc_gpio_handle_irq(unsigned int irq, 
struct irq_desc *desc)
int i;
 
for (i = 0; i < SIRFSOC_GPIO_NO_OF_BANKS; i++) {
-   bank = _chip.sgpio_bank[i];
+   bank = >sgpio_bank[i];
if (bank->parent_irq == irq)
break;
}
-- 
1.9.3

--
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: Unionmount and overlayfs testsuite

[David Howells]

Sedat Dilek  wrote:

> umount: /mnt: not mounted

Don't worry about that.

> TEST104: Impermissible utimes
>  - fs_op_as_bin utimes /mnt/a/rootfile104 -E EACCES
> /mnt/a/rootfile104: Test file not on upper filesystem (line 130)

That might be a failure in overlayfs.

David
--
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 2/3] CMA: aggressively allocate the pages on cma reserved memory when not used

[Gioh Kim]

Joonsoo,

I'm attaching a patch for combination of __rmqueue and __rmqueue_cma.
I didn't test fully but my board is turned on and working well if no frequent 
memory allocations.

I'm sorry to send not-tested code.
I just want to report this during your working hour ;-)

I'm testing this this evening and reporting next week.
Have a nice weekend!

-- 8< 
-
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7f97767..9ced736 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -964,7 +964,7 @@ static int fallbacks[MIGRATE_TYPES][4] = {
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE, 
MIGRATE_R
 #ifdef CONFIG_CMA
[MIGRATE_MOVABLE] = { MIGRATE_CMA, MIGRATE_RECLAIMABLE, 
MIGRATE_U
-   [MIGRATE_CMA] = { MIGRATE_RESERVE }, /* Never used */
+   [MIGRATE_CMA] = { MIGRATE_MOVABLE, MIGRATE_RECLAIMABLE, 
MIGRATE_U
 #else
[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,   
MIGRATE_R
 #endif
@@ -1170,9 +1170,22 @@ static struct page *__rmqueue(struct zone *zone, 
unsigned int
int migratetype)
 {
struct page *page;
+   long free, free_cma, free_wmark;

 retry_reserve:
-   page = __rmqueue_smallest(zone, order, migratetype);
+   if (IS_ENABLED(CONFIG_CMA) && migratetype == MIGRATE_MOVABLE) {
+   if (zone->nr_try_movable) {
+   zone->nr_try_movable -= 1 << order;
+   } else if (zone->nr_try_cma) {
+   zone->nr_try_cma -= 1 << order;
+   migratetype = MIGRATE_CMA;
+   } else {
+   zone->nr_try_movable = zone->max_try_movable;
+   zone->nr_try_movable -= 1 << order;
+   zone->nr_try_cma = zone->max_try_cma;
+   }
+   }
+   page = __rmqueue_smallest(zone, order, migratetype);

if (unlikely(!page) && migratetype != MIGRATE_RESERVE) {
page = __rmqueue_fallback(zone, order, migratetype);


2014-05-28 오후 4:04, Joonsoo Kim 쓴 글:
> CMA is introduced to provide physically contiguous pages at runtime.
> For this purpose, it reserves memory at boot time. Although it reserve
> memory, this reserved memory can be used for movable memory allocation
> request. This usecase is beneficial to the system that needs this CMA
> reserved memory infrequently and it is one of main purpose of
> introducing CMA.
> 
> But, there is a problem in current implementation. The problem is that
> it works like as just reserved memory approach. The pages on cma reserved
> memory are hardly used for movable memory allocation. This is caused by
> combination of allocation and reclaim policy.
> 
> The pages on cma reserved memory are allocated if there is no movable
> memory, that is, as fallback allocation. So the time this fallback
> allocation is started is under heavy memory pressure. Although it is under
> memory pressure, movable allocation easily succeed, since there would be
> many pages on cma reserved memory. But this is not the case for unmovable
> and reclaimable allocation, because they can't use the pages on cma
> reserved memory. These allocations regard system's free memory as
> (free pages - free cma pages) on watermark checking, that is, free
> unmovable pages + free reclaimable pages + free movable pages. Because
> we already exhausted movable pages, only free pages we have are unmovable
> and reclaimable types and this would be really small amount. So watermark
> checking would be failed. It will wake up kswapd to make enough free
> memory for unmovable and reclaimable allocation and kswapd will do.
> So before we fully utilize pages on cma reserved memory, kswapd start to
> reclaim memory and try to make free memory over the high watermark. This
> watermark checking by kswapd doesn't take care free cma pages so many
> movable pages would be reclaimed. After then, we have a lot of movable
> pages again, so fallback allocation doesn't happen again. To conclude,
> amount of free memory on meminfo which includes free CMA pages is moving
> around 512 MB if I reserve 512 MB memory for CMA.
> 
> I found this problem on following experiment.
> 
> 4 CPUs, 1024 MB, VIRTUAL MACHINE
> make -j16
> 
> CMA reserve:0 MB512 MB
> Elapsed-time:   225.2   472.5
> Average-MemFree:322490 KB   630839 KB
> 
> To solve this problem, I can think following 2 possible solutions.
> 1. allocate the pages on cma reserved memory first, and if they are
> exhausted, allocate movable pages.
> 2. interleaved allocation: try to allocate specific amounts of memory
> from cma reserved memory and then allocate from free movable memory.
> 
> I tested #1 approach and found the problem. Although free memory on
> meminfo can move around low watermark, there is large fluctuation on free

Re: [PATCH]x86 efi: do not export efi runtime map in case old map

[Borislav Petkov]

On Fri, May 30, 2014 at 11:20:10AM +0800, Dave Young wrote:
> 
> For ioremapped efi memory aka old_map the virt addresses are not persistant
> across kexec reboot. kexec-tools will read the runtime maps from sysfs then
> pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause
> kexec boot failure.
> 
> To address this issue do not export runtime maps in case efi old_map so
> userspace can use no efi boot instead.
> 
> Signed-off-by: Dave Young 

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 4/4] ARM: debug: qcom: add UART addresses to Kconfig help

[Ivan T. Ivanov]

On Thu, 2014-05-29 at 17:26 +0200, Matthias Brugger wrote:

> IMHO the dependancy is that DEBUG_LL uses the uart device, and this is
> added when you add the dts.
> AFAIK there can arise problems with multi-platform kernels if the uart
> is not present.

Once DEBUG_LL is enabled you don't have multi-platform kernel anymore,
so this should not be an issue here.

Regards,
Ivan

--
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] swap: Avoid scanning invalidated region for cheap seek

[Shaohua Li]

On Tue, May 27, 2014 at 08:53:00PM -0700, Hugh Dickins wrote:
> On Mon, 26 May 2014, Chen Yucong wrote:
> 
> > For cheap seek, when we scan the region between si->lowset_bit
> > and scan_base, if san_base is greater than si->highest_bit, the
> > scan operation between si->highest_bit and scan_base is not
> > unnecessary.
> > 
> > This patch can be used to avoid scanning invalidated region for
> > cheap seek.
> > 
> > Signed-off-by: Chen Yucong 
> 
> I was going to suggest that you are adding a little code to a common
> path, in order to optimize a very unlikely case: which does not seem
> worthwhile to me.
> 
> But digging a little deeper, I think you have hit upon something more
> interesting (though still in no need of your patch): it looks to me
> like that is not even a common path, but dead code.
> 
> Shaohua, am I missing something, or does all SWP_SOLIDSTATE "seek is
> cheap" now go your si->cluster_info scan_swap_map_try_ssd_cluster()
> route?  So that the "last_in_cluster < scan_base" loop in the body
> of scan_swap_map() is just redundant, and should have been deleted?

Sorry for the delay, you are right. SSD case always goes
scan_swap_map_try_ssd_cluster, otherwise we just scan from lowest_bit to
highest_bit, so the "last_in_cluster < scan_base" loop is dead.

Yucong, can you resent a patch to delete it as Hugh suggested?

Thanks,
Shaohua
--
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 0/6] staging: comedi: addi_apci_1564: fix Change-of-State interrupt functionality.

[Dan Carpenter]

When you do a v2 patchset, put a v2 in the subject and say which things
changed since v1. https://www.google.com/search?q=how+to+send+a+v2+patch

regards,
dan carpenter

--
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] ncr53c8xx: remove remnants of immediate arbitration

[Paul Bolle]

The code for immediate arbitration was removed from (what looks like a
predecessor of) the ncr53c8xx code in v2.6.0. Remove its remnants now.

Signed-off-by: Paul Bolle 
---
Untested.

 Documentation/scsi/ncr53c8xx.txt | 52 
 drivers/scsi/ncr53c8xx.c | 12 --
 drivers/scsi/ncr53c8xx.h |  8 ---
 3 files changed, 72 deletions(-)

diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index 1d508dcbf859..49c7b723225b 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt
@@ -52,12 +52,10 @@ Written by Gerard Roudier 
  10.2.19 Check SCSI BUS 
  10.2.20 Exclude a host from being attached
  10.2.21 Suggest a default SCSI id for hosts
- 10.2.22 Enable use of IMMEDIATE ARBITRATION
   10.3 Advised boot setup commands
   10.4 PCI configuration fix-up boot option
   10.5 Serial NVRAM support boot option
   10.6 SCSI BUS checking boot option
-  10.7 IMMEDIATE ARBITRATION boot option
 11. Some constants and flags of the ncr53c8xx.h header file
 12. Installation
 13. Architecture dependent features
@@ -843,16 +841,6 @@ port address 0x1400.
 try to deduce the value previously set in the hardware and use value 
 7 if the hardware value is zero.
 
-10.2.22 Enable use of IMMEDIATE ARBITRATION
-(only supported by the sym53c8xx driver. See 10.7 for more details)
-iarb:0do not use this feature.
-iarb:#x   use this feature according to bit fields as follow:
-
-bit 0 (1) : enable IARB each time the initiator has been reselected 
-when it arbitrated for the SCSI BUS.
-(#x >> 4) : maximum number of successive settings of IARB if the initiator 
-win arbitration and it has other commands to send to a device.
-
 Boot fail safe
 safe:y load the following assumed fail safe initial setup
 
@@ -876,7 +864,6 @@ Boot fail safe
   differential support from BIOS settings  diff:1
   irq mode from BIOS settings  irqm:1
   SCSI BUS check   do not attach on error  buschk:1
-  immediate arbitrationdisablediarb:0
 
 10.3 Advised boot setup commands
 
@@ -1005,45 +992,6 @@ Unfortunately, the following common SCSI BUS problems are 
not detected:
 On the other hand, either bad cabling, broken devices, not conformant 
 devices, ... may cause a SCSI signal to be wrong when te driver reads it.
 
-10.7 IMMEDIATE ARBITRATION boot option
-
-This option is only supported by the SYM53C8XX driver (not by the NCR53C8XX).
-
-SYMBIOS 53C8XX chips are able to arbitrate for the SCSI BUS as soon as they 
-have detected an expected disconnection (BUS FREE PHASE). For this process 
-to be started, bit 1 of SCNTL1 IO register must be set when the chip is 
-connected to the SCSI BUS.
-
-When this feature has been enabled for the current connection, the chip has 
-every chance to win arbitration if only devices with lower priority are 
-competing for the SCSI BUS. By the way, when the chip is using SCSI id 7, 
-then it will for sure win the next SCSI BUS arbitration.
-
-Since, there is no way to know what devices are trying to arbitrate for the 
-BUS, using this feature can be extremely unfair. So, you are not advised
-to enable it, or at most enable this feature for the case the chip lost 
-the previous arbitration (boot option 'iarb:1').
-
-This feature has the following advantages:
-
-a) Allow the initiator with ID 7 to win arbitration when it wants so.
-b) Overlap at least 4 micro-seconds of arbitration time with the execution 
-   of SCRIPTS that deal with the end of the current connection and that 
-   starts the next job.
-
-Hmmm... But (a) may just prevent other devices from reselecting the initiator, 
-and delay data transfers or status/completions, and (b) may just waste 
-SCSI BUS bandwidth if the SCRIPTS execution lasts more than 4 micro-seconds.
-
-The use of IARB needs the SCSI_NCR_IARB_SUPPORT option to have been defined 
-at compile time and the 'iarb' boot option to have been set to a non zero 
-value at boot time. It is not that useful for real work, but can be used 
-to stress SCSI devices or for some applications that can gain advantage of 
-it. By the way, if you experience badnesses like 'unexpected disconnections', 
-'bad reselections', etc... when using IARB on heavy IO load, you should not 
-be surprised, because force-feeding anything and blocking its arse at the 
-same time cannot work for a long time. :-))
-
 
 11. Some constants and flags of the ncr53c8xx.h header file
 
diff --git a/drivers/scsi/ncr53c8xx.c b/drivers/scsi/ncr53c8xx.c
index 7d014b11df62..9661a2c9e13c 100644
--- a/drivers/scsi/ncr53c8xx.c
+++ b/drivers/scsi/ncr53c8xx.c
@@ -615,10 +615,6 @@ static struct ncr_driver_setup
 #define OPT_EXCLUDE24
 #define OPT_HOST_ID25
 
-#ifdef SCSI_NCR_IARB_SUPPORT

Re: [PATCH 1/3] mfd: iManager2: Add support for IT8516/18/28

[Lee Jones]

Couple of things on top of Guenter's comments.

> +config MFD_IMANAGER2
> + tristate "Support for Advantech iManager2 EC ICs"
> + select MFD_CORE

So you're not using any other frameworks? I see quite a lot of Mailbox
stuff.  Why aren't you using the Mailbox API, drivers/mailbox?  I'm
gussing you'll need I2C somewhere down the line too.  And Regmap?

> +/* imanager2_core.c - MFD core driver of Advantech EC IT8516/18/28

I can't find any documentation on this device.  Is there a datasheet
or similar?

> + * Copyright (C) 2014  Richard Vidal-Dorsch 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */

Documentation/CodingStyle - Comments.

Run scripts/checkpatch.pl on your patches _before_ resending.

> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Don't like this.

> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME CHIP_NAME

Or this.

> +#define DRV_VERSION  "0.2.2"
> +
> +static struct platform_device *pdev;

Why don't you register from Device Tree or platform data? I.e. from
arch//.  While we're on the subject, which architecture(s) is
this likely to run on, or is this device completely agnostic?

> +static struct mfd_cell it85xx_devs[] = {
> + { .name = DRV_NAME "_hwm", },
> + { .name = DRV_NAME "_i2c", },
> +};

Don't like this, just use "it85xx" instead of DRV_NAME.

> +static int ec_authentication(struct it85xx *ec)
> +{
> + u8 tmp;
> + int ret = 0;
> +
> + spin_lock(>lock);
> +
> + if (inb(EC_IO_PORT_CMD) == 0xFF && inb(EC_IO_PORT_DATA) == 0xFF) {

One would guess that the Mailbox driver should be taking care of all
these.

[...]

> +static int ec_get_chip_type(struct it85xx *ec)
> +{
> + spin_lock(>lock);

Can you explain to me why you've chosen spin_lock over, say a mutex?

> + outb(0x20, EC_SIO_CMD);

Don't use magic numbers - all addresses/masks should be #defined

[...]

> +static int ec_get_info(struct it85xx *ec)
> +{
> + int ret;
> + /* first kernel version that supports ITE mailbox */

What?

> + const u16 supmbox_1st_kver = 0x1105;

No way, please remove.

> + u8 *tmp = (u8 *)>info.version.kernel_ver;
> +
> + spin_lock(>lock);
> +
> + ret = ec_io_read(EC_CMD_ACPIRAM_READ,
> +  EC_ACPIRAM_ADDR_KERNEL_MAJOR_VERSION, [0], 2);
> +
> + if (ec->info.version.kernel_ver >= supmbox_1st_kver) {

Yuk!

If you explain why you're doing this, maybe we can suggest another way
of achieving the same aim.


> +static int __init it85xx_probe(struct it85xx *ec)
> +{
> + int ret;
> +
> + ret = ec_authentication(ec);
> + if (ret != 0)
> + return ret;
> +
> + ret = ec_get_chip_type(ec);
> + if (ret != 0)
> + return ret;
> +
> + ret = ec_get_info(ec);
> + if (ret != 0)
> + return ret;
> +
> + ret = ec_build_device_table(ec);
> + if (ret != 0)
> + return ret;
> +
> + if (request_region(EC_IO_PORT_DATA, 2, DRV_NAME) == NULL) {

devm_*

> + release_region(EC_IO_PORT_DATA, 2);

Delete

> + return -EIO;
> + }
> +
> + if (request_region(EC_ITE_PORT_OFS, 2, DRV_NAME) == NULL) {

Etc ...

> + release_region(EC_ITE_PORT_OFS, 2);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int __init it85xx_device_add(const struct it85xx *ec)
> +{
> + int ret;
> +
> + pdev = platform_device_alloc(DRV_NAME, 0);
> + if (pdev == NULL) {
> + ret = -ENOMEM;
> + pr_err("Device allocation failed\n");
> + goto exit;

Remove the 'exit' lable and just 'return ret' here.
> + }
> +
> + ret = platform_device_add_data(pdev, ec,
> +sizeof(struct it85xx));

ec is not platform data, it's device data.  Platform data should be
passed in via the platform_data structure or Device Tree.

> + if (ret != 0) {
> + pr_err("Platform data allocation failed\n");
> + goto exit_device_put;
> + }
> +
> + ret = platform_device_add(pdev);
> + if (ret != 0) {
> + pr_err("Device addition failed (%d)\n", ret);
> + goto exit_device_put;
> + }
> +
> + ret = mfd_add_devices(>dev, pdev->id, it85xx_devs,
> +   ARRAY_SIZE(it85xx_devs), NULL, -1, NULL);

Second argument here should probably be -1 for 

Re: [PATCH v2] pinctrl: Enable "power-source" to be extracted from DT files

[Ivan T. Ivanov]

On Wed, 2014-05-28 at 10:48 +0200, Linus Walleij wrote:
> On Wed, May 28, 2014 at 10:36 AM, Heiko Stübner  wrote:
> > Am Mittwoch, 28. Mai 2014, 10:15:43 schrieb Linus Walleij:
> >> On Tue, May 27, 2014 at 3:09 PM, Heiko Stübner  wrote:
> >> > Am Dienstag, 27. Mai 2014, 09:27:36 schrieb Ivan T. Ivanov:
> >> >> From: "Ivan T. Ivanov" 
> >> >>
> >> >> Add "power-source" property to generic options used for DT parsing 
> >> >> files.
> >> >> This  enables drivers, which use generic pin configurations, to get the
> >> >> value passed to this property.
> >> >
> >> > I think the main problem here is, that pinconf-generic.h defines the
> >> > power-
> >> > source as having a "custom format". With DT as a hardware description,
> >> > implementaton specific values do not work well - instead it should have a
> >> > regular unit-value.
> >> >
> >> > For the power-source I think volts could work well - as this is the main
> >> > use- case for pinctrl I know. The regulator-binding uses microvolts,
> >> > maybe it would be good use a similar unit.
> >>
> >> (...)
> >>
> >> > pcfg_1v8 {
> >> >
> >> > power-source = <180>;
> >> >
> >> > };
> >>
> >> I don't think this is what it's meant for actually. In this case the thing
> >> would be modeled as a regulator rather than some pin control option I
> >> guess?
> >>
> >> I think it's more like a selector, such as found on old amplifiers,
> >> input source A, B or C? So it's just some discrete number.
> >
> > as I said, you know this better than me ;-)
> >
> > I was thinking more of these io-voltages, where one can select between say 
> > 1.8
> > and 3.3V for the pins.
> >
> > I have this somewhere on my todo list for the rockchips too.
> >
> > So essentially the pinctrl driver [as it is a pin-group specific setting]
> > should just export regulators for these voltage settings, without touching 
> > the
> > pinconfig itself, right?
> 
> Hm hm hm.
> 
> I am a bit in the blue actually.
> 
> I think we need to have a discussion with Mark Brown on how to
> handle this.
> 
> We have previously had the case of MMC/SD level-shifters, where
> a certain setting gives a certain level of signals out, and another setting
> gives another level. Like two discrete levels.
> 
> So we modeled that as a regulator provider inside the pin control
> driver eventually, see sh-pfc/pfc-sh73a0.c
> 
> But this is different: it is the power of the pin itself.
> 
> I can think of a "padring regulator" hooking in as part of the pin state
> but have no clear idea on how to actually do that. We need some
> coding I think.
> 

In my case this is just a switch, which can select from different power
sources and these sources are external from the chip. So I can't know
a priory what the levels are and hard code them inside the driver.

Thanks,
Ivan


--
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: Implement PEBS virtualization for Silvermont

[Peter Zijlstra]

On Thu, May 29, 2014 at 06:12:03PM -0700, Andi Kleen wrote:
> PEBS is very useful (e.g. enabling the more cycles:pp event or
> memory profiling) Unfortunately it didn't work in virtualization,
> which is becoming more and more common.
> 
> This patch kit implements simple PEBS virtualization for KVM on Silvermont
> CPUs. Silvermont does not have the leak problems that prevented successfull
> PEBS virtualization earlier.

Silvermont is such an underpowered thing, who in his right mind would
run anything virt on it to further reduce performance?
--
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] perf: Handle guest PEBS events with a fake event

[Peter Zijlstra]

On Thu, May 29, 2014 at 06:12:06PM -0700, Andi Kleen wrote:

> Note: in very rare cases with exotic events this may lead to spurious PMIs
> in the guest.

Qualify that statement so that if someone runs into it we at least know
it is known/expected.
--
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: Tree for May 30

[Stephen Rothwell]

Hi all,

The powerpc allyesconfig is again broken more than usual.

Changes since 20140529:

The mmc tree gained a build failure for which I reverted a commit.

The omap_dss2 tree gained a conflict against the arm-soc tree.

I added a couple of supplied patches to the tip tree.

The tty tree lost its build failure.

The usb tree still had its build failure for which I applied a fix patch.

The pinctrl tree gained a build failure so I used the version from
next-20140529.

Non-merge commits (relative to Linus' tree): 10018
 8219 files changed, 378688 insertions(+), 224693 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 219 trees (counting Linus' and 29 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (a991639c26c7 Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2)
Merging arm-current/fixes (483a6c9d447f ARM: 8064/1: fix v7-M signal return)
Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for 
v3.14-rc1)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (011e4b02f1da powerpc, kexec: Fix "Processor X is 
stuck" issue during kexec from ST mode)
Merging sparc/master (8ecc1bad4c9b sparc64: fix format string mismatch in 
arch/sparc/kernel/sysfs.c)
Merging net/master (8646224cdb94 Merge branch 'for-davem' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless)
Merging ipsec/master (6d004d6cc739 vti: Use the tunnel mark for lookup in the 
error handlers.)
Merging sound-current/for-linus (77f07800cb45 ALSA: hda - Fix onboard audio on 
Intel H97/Z97 chipsets)
Merging pci-current/for-linus (d0b4cc4e3270 PCI: Wrong register used to check 
pending traffic)
Merging wireless/master (2c316e699fa4 Merge branch 'for-john' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (4b660a7f5c80 Linux 3.15-rc6)
Merging tty.current/tty-linus (d6d211db37e7 Linux 3.15-rc5)
Merging usb.current/usb-linus (5dc2808c4729 xhci: delete endpoints from 
bandwidth list before freeing whole device)
Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and 
iomem resource retrieval)
Merging staging.current/staging-linus (9326c5ca0982 staging: r8192e_pci: fix 
htons error)
Merging char-misc.current/char-misc-linus (d1db0eea8524 Linux 3.15-rc3)
Merging input-current/for-linus (0f68f39c393b Input: synaptics - change min/max 
quirk table to pnp-id matching)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode 
concurrency finding.)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes 

Re: [PATCH] export efi.flags to sysfs

[Borislav Petkov]

On Fri, May 30, 2014 at 10:24:38AM +0800, Dave Young wrote:
> > > > How does /sys/firmware/efi/runtime-map/* look like with old mapping? 
> > > > Can't
> > > > we look at it and figure out if it is 1:1 or not.
> > > 
> > > There's phys_addr and virt_addr, (virt_addr - phys_addr) will always be
> > > -64G for 1:1 map, ioremapped addresses space is different.
> 
> Correct myself it's top to down (-4G - -64G) instead of down to top.

This is the new mapping.

AFAICR, the question is about the old mapping. Which was "normal"
ioremap into the kernel page table. The new mapping is into another page
table.

> > I am curious that what's the meaning of 1:1 mapping here? So far I thought
> > that means virt and physical addresses are same but that does not seem
> > to be the case. So what does it mean?
> 
> while doing the mapping, we will iterate the memory ranges (md[])
> 
> Like below without considering alignment:
> Virt addr   (down) <--> (top)
> md0 (size0) <-> 
>  (size0)
> md1 (size1)<--->
> (size1)
> ...
> 
> Boris can correct me if I'm wrong.

Yes, this is the new mapping, top = -2G.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/4] perf: Allow guest PEBS for KVM owned counters

[Peter Zijlstra]

On Thu, May 29, 2014 at 06:12:05PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Currently perf unconditionally disables PEBS for guest.
> 
> Now that we have the infrastructure in place to handle
> it we can allow it for KVM owned guest events. For
> the perf needs to know that a event is owned by
> a guest. Add a new state bit in the perf_event for that.
> 

This doesn't make sense; why does it need to be owned?
--
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] devicetree: Add generic IOMMU device tree bindings

[Thierry Reding]

On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > This commit introduces a generic device tree binding for IOMMU devices.
> > Only a very minimal subset is described here, but it is enough to cover
> > the requirements of both the Exynos System MMU and Tegra SMMU as
> > discussed here:
> > 
> > https://lkml.org/lkml/2014/4/27/346
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> > Apologies for the noise, but apparently I mistyped one of the email
> > addresses, should be fixed now.
> > 
> > Changes in v2:
> > - add notes about "dma-ranges" property (drop note from commit message)
> > - document priorities of "iommus" property vs. "dma-ranges" property
> > - drop #iommu-cells in favour of #address-cells and #size-cells
> 
> I think this is a mistake. address-cells/size-cells are for transactions
> flowing down the bus (from the CPU to date). Describing a connection
> from a device to an IOMMU is something completely different, and should
> therefore simply use an iommu-cells property to describe any necessary
> information. If we start re-using properties for different things in
> different contexts, how is anyone going to know what they mean, and how
> will conflicts be resolved. For example, what if there's a single HW
> module that both acts as a regular register bus with children (where
> address-cells/size-cells defines how transactions reach the children
> from the parent), and is also an IOMMU (where according to this binding
> proposal, address-cells/size-cells represent some aspect of the IOMMU
> feature). Using different properties for different things is the only
> sane way to keep different concepts separate. Another alternative would
> be to represent the single HW module as separate nodes in DT, but I
> think that will only make our lives harder, and where I've done that in
> the past, I've regretted it.

There was some back-and-forth on this topic and the latest concensus
when I wrote the second version was that #address-cells and #size-cells
were to be used.

But there was some bore back-and-forth after that, and it seems like
Arnd no longer thinks that using #address-cells and #size-cells is a
good idea either[0].

Arnd, can you take another look at this binding and see if there's
anything else missing? If not I'll go through the document again and
update all #address-cells/#size-cells references with #iommu-cells as
appropriate and submit v3.

Thanks,
Thierry

[0]: https://lkml.org/lkml/2014/5/20/609


pgpxnRTbmUOwg.pgp
Description: PGP signature

[PATCH] ncr53c8xx: remove remnants of integrity checking

[Paul Bolle]

The code for integrity checking was removed in v2.6.10. Remove its
remnants now.

Signed-off-by: Paul Bolle 
---
Untested.

 drivers/scsi/ncr53c8xx.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/scsi/ncr53c8xx.h b/drivers/scsi/ncr53c8xx.h
index 0e008dacf679..736a9df68d58 100644
--- a/drivers/scsi/ncr53c8xx.h
+++ b/drivers/scsi/ncr53c8xx.h
@@ -63,14 +63,6 @@
 #define SCSI_NCR_BOOT_COMMAND_LINE_SUPPORT
 #define SCSI_NCR_DEBUG_INFO_SUPPORT
 
-/*
-** To disable integrity checking, do not define the 
-** following option.
-*/
-#ifdef CONFIG_SCSI_NCR53C8XX_INTEGRITY_CHECK
-#  define SCSI_NCR_ENABLE_INTEGRITY_CHECK
-#endif
-
 /* -
 ** Take into account kernel configured parameters.
 ** Most of these options can be overridden at startup by a command line.
-- 
1.9.3

--
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 0/7 V4] perf: Enable mmap2 and add dcacheline sorting

[Namhyung Kim]

On Tue, 27 May 2014 12:28:00 -0400, Don Zickus wrote:
> These patches enable mmap2 support in the kernel and perf to
> allow support for data cacheline sorting.
>
> Note: I haven't been able to reproduce Jiri's perf hang yet, so I don't
> have a patch for that particular problem yet.

I have no idea what the hang case is, but from a quick look, the code
for the tooling part (beside few nitpicks) looks good to me.

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

Re: [PATCH 6/7] perf: Add support to dynamically get cacheline size

[Namhyung Kim]

On Tue, 27 May 2014 12:28:06 -0400, Don Zickus wrote:
> Different arches may have different cacheline sizes.  Look it up and set
> a global variable for reference.

[SNIP]
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 635cd8f..6e06567 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -2,6 +2,7 @@
>  #include "hist.h"
>  #include "comm.h"
>  #include "symbol.h"
> +#include "cpumap.h"

It seems not needed anymore?

Thanks,
Namhyung

>  
>  regex_t  parent_regex;
>  const char   default_parent_pattern[] = "^sys_|^do_page_fault";
--
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] MIPS: change type of asid_cache to unsigned long

[Libin]

On 2014/5/29 4:09, Aaro Koskinen wrote:
> Hi,
> 
> On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
>> On 2014/5/21 13:36, Yong Zhang wrote:
>>> asid_cache must be unsigned long otherwise on 64bit system
>>> it will become 0 if the value in get_new_mmu_context()
>>> reaches 0x and in the end the assumption of
>>> ASID_FIRST_VERSION is not true anymore thus leads to
>>> more dangerous things.
>>
>> We should describe what problem this bug can lead to, which
>> will help people who encounter the same problem and google it.
> 
> Please describe it, then. Even if the patch is already committed,
> googling would probably still find this e-mail thread.
> 
> Thanks,
> 
> A.
> 
> 

Problem description:
On our MIPS architecture product, after a long time running our business
service, a random cpu trigger the problem, that if running test cases
include the following code on this cpu will trigger bus error or
segment fault:
...
pid = fork();
if (pid < 0)
return 1;
if (0 == pid)
exit(0);
else
exit(0);
...

Root cause:
After doing a lot of fork/mmap/munmap operations, it will make the asid value
exceeds 0x in get_new_mmu_context function, which is truncated to 0:
|-get_new_mmu_context(struct mm_struct *mm, unsigned long cpu)
unsigned long asid = asid_cache(cpu); //if asid_cache(cpu) is 0x now
if (! ((asid += ASID_INC) & ASID_MASK) ) {  //asid reaches 0x1  
...
local_flush_tlb_all(); /* start new asid cycle */
if (!asid) /* fix version if needed */  //but here 
condition does not meet...
asid = ASID_FIRST_VERSION;
 }
 cpu_context(cpu, mm) = asid_cache(cpu) = asid; //and here cpu_context 
and asid_cache is truncated to 0

In do_fork()->dup_mmap(), adding write-protect flag for writable page but the
following tlb flush does not take effect, and breaks the normal COW:
do_fork()
|-copy_process()
|-copy_mm()
...
|-dup_mmap()
|-copy_page_range()
...
|-copy_one_pte()
...
if (is_cow_mapping(vm_flags)) {
ptep_set_wrprotect(src_mm, addr, src_pte);
pte = pte_wrprotect(pte);
}
...
|-flush_tlb_mm(oldmm)
|-local_flush_tlb_mm（）
if (cpu_context(cpu, mm) != 0) {//cpu_context is 0, no tlb flush
drop_mmu_context(mm, cpu);
}

In addition, the condition ((cpu_context(cpu, next) ^ asid_cache(cpu))
& ASID_VERSION_MASK) can not be met in switch_mm(), and the tlb flush operation
can not be completed during the process switch.
|-switch_mm()
...
/* Check if our ASID is of an older version and thus invalid */
if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK)
get_new_mmu_context(next, cpu);
write_c0_entryhi(cpu_asid(cpu, next));
...

In short, due to the truncation operation caused by inappropriate type 
conversion,
making tlb flush failure, causing problems of COW, triggering bus error or 
segment fault.

Thanks,
Libin

--
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/7] Revert "perf: Disable PERF_RECORD_MMAP2 support"

[Namhyung Kim]

Hi Don,

On Tue, 27 May 2014 12:28:02 -0400, Don Zickus wrote:
> This reverts commit 3090ffb5a2515990182f3f55b0688a7817325488.
>
> Re-enable the mmap2 interface as we will have a user soon.
>
> Since things have changed since perf disabled mmap2, small tweaks
> to the revert had to be done:
>
> o commit 9d4ecc88 forced (n!=8) to become (n<7)
> o a new libunwind test needed updating to use mmap2 interface

Just few nitpicks..


[SNIP]
> @@ -195,14 +196,15 @@ int perf_event__synthesize_mmap_events(struct perf_tool 
> *tool,
>   strcpy(execname, "");
>  
>   /* 0040-0040c000 r-xp  fd:01 41038  /bin/cat */
> - n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %*x:%*x %*u 
> %s\n",
> ->mmap.start, >mmap.len, prot,
> ->mmap.pgoff,
> -execname);
> - /*
> -  * Anon maps don't have the execname.
> -  */

I think it's better to leave this comment as is.


> - if (n < 4)
> + n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %x:%x %u %s\n",
> +>mmap2.start, >mmap2.len, prot,
> +>mmap2.pgoff, >mmap2.maj,
> +>mmap2.min,
> +, execname);
> +
> + event->mmap2.ino = (u64)ino;

And this can be moved below check..

Thanks,
Namhyung


> +
> + if (n < 7)
>   continue;
>   /*
>* Just like the kernel, see __perf_event_mmap in 
> kernel/perf_event.c
> @@ -223,15 +225,15 @@ int perf_event__synthesize_mmap_events(struct perf_tool 
> *tool,
>   strcpy(execname, anonstr);
>  
>   size = strlen(execname) + 1;
> - memcpy(event->mmap.filename, execname, size);
> + memcpy(event->mmap2.filename, execname, size);
>   size = PERF_ALIGN(size, sizeof(u64));
> - event->mmap.len -= event->mmap.start;
> - event->mmap.header.size = (sizeof(event->mmap) -
> - (sizeof(event->mmap.filename) - size));
> - memset(event->mmap.filename + size, 0, machine->id_hdr_size);
> - event->mmap.header.size += machine->id_hdr_size;
> - event->mmap.pid = tgid;
> - event->mmap.tid = pid;
> + event->mmap2.len -= event->mmap.start;
> + event->mmap2.header.size = (sizeof(event->mmap2) -
> + (sizeof(event->mmap2.filename) - size));
> + memset(event->mmap2.filename + size, 0, machine->id_hdr_size);
> + event->mmap2.header.size += machine->id_hdr_size;
> + event->mmap2.pid = tgid;
> + event->mmap2.tid = pid;
>  
>   if (process(tool, event, _sample, machine) != 0) {
>   rc = -1;
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 5c28d82..21154da 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -659,6 +659,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
> record_opts *opts)
>   perf_evsel__set_sample_bit(evsel, WEIGHT);
>  
>   attr->mmap  = track;
> + attr->mmap2 = track && !perf_missing_features.mmap2;
>   attr->comm  = track;
>  
>   if (opts->sample_transaction)
--
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: Bad DMA from Marvell 9230

[Jérôme Carretero]

On Thu, 27 Mar 2014 17:57:37 +1100
Benjamin Herrenschmidt  wrote:

> I've been trying a 9230 on a power box here (a 9235 on the same
> machine works fine) and it blows up with an IOMMU violation early
> during init.

Hi,

That's https://bugzilla.kernel.org/show_bug.cgi?id=42679
if you haven't already found it.

-- 
Jérôme
--
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: virtio ring cleanups, which save stack on older gcc

[Rusty Russell]

Minchan Kim  writes:
> On Thu, May 29, 2014 at 08:38:33PM +0930, Rusty Russell wrote:
>> Minchan Kim  writes:
>> > Hello Rusty,
>> >
>> > On Thu, May 29, 2014 at 04:56:41PM +0930, Rusty Russell wrote:
>> >> They don't make much difference: the easier fix is use gcc 4.8
>> >> which drops stack required across virtio block's virtio_queue_rq
>> >> down to that kmalloc in virtio_ring from 528 to 392 bytes.
>> >> 
>> >> Still, these (*lightly tested*) patches reduce to 432 bytes,
>> >> even for gcc 4.6.4.  Posted here FYI.
>> >
>> > I am testing with below which was hack for Dave's idea so don't have
>> > a machine to test your patches until tomorrow.
>> > So, I will queue your patches into testing machine tomorrow morning.
>> 
>> More interesting would be updating your compiler to 4.8, I think.
>> Saving <100 bytes on virtio is not going to save you, right?
>
> But in my report, virtio_ring consumes more than yours.

Yeah, weird.  I wonder if it's because I'm measuring before the call to
kmalloc; gcc probably spills extra crap on the stack before that.

You got 904 bytes:

5928 376   vring_add_indirect+0x36/0x200
[  111.404781]<...>-15987   5d..2 111689538us : stack_trace_call:   9)
5552 144   virtqueue_add_sgs+0x2e2/0x320
[  111.404781]<...>-15987   5d..2 111689538us : stack_trace_call:  10)
5408 288   __virtblk_add_req+0xda/0x1b0
[  111.404781]<...>-15987   5d..2 111689538us : stack_trace_call:  11)
5120  96   virtio_queue_rq+0xd3/0x1d0

When I move my "stack_top" save code into __kmalloc, with gcc 4.6 and your
.config I get:

[2.506869] virtio_blk: stack used = 640

So I don't know quite what's going on :(

Cheers,
Rusty.

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index cb9b1f8326c3..894e290b4bd2 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -151,15 +151,19 @@ static void virtblk_done(struct virtqueue *vq)
spin_unlock_irqrestore(>vq_lock, flags);
 }
 
+extern struct task_struct *record_stack;
+extern unsigned long stack_top;
+
 static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
 {
struct virtio_blk *vblk = hctx->queue->queuedata;
struct virtblk_req *vbr = req->special;
unsigned long flags;
unsigned int num;
+   unsigned long stack_bottom;
const bool last = (req->cmd_flags & REQ_END) != 0;
int err;
-
+   
BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems);
 
vbr->req = req;
@@ -199,7 +203,12 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, 
struct request *req)
}
 
spin_lock_irqsave(>vq_lock, flags);
+   record_stack = current;
+   __asm__ __volatile__("movq %%rsp,%0" : "=g" (stack_bottom));
err = __virtblk_add_req(vblk->vq, vbr, vbr->sg, num);
+   record_stack = NULL;
+
+   printk("virtio_blk: stack used = %lu\n", stack_bottom - stack_top);
if (err) {
virtqueue_kick(vblk->vq);
blk_mq_stop_hw_queue(hctx);
diff --git a/mm/slub.c b/mm/slub.c
index 2b1ce697fc4b..0f9a1a6b381e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3278,11 +3278,22 @@ static int __init setup_slub_nomerge(char *str)
 
 __setup("slub_nomerge", setup_slub_nomerge);
 
+extern struct task_struct *record_stack;
+struct task_struct *record_stack;
+EXPORT_SYMBOL(record_stack);
+
+extern unsigned long stack_top;
+unsigned long stack_top;
+EXPORT_SYMBOL(stack_top);
+
 void *__kmalloc(size_t size, gfp_t flags)
 {
struct kmem_cache *s;
void *ret;
 
+   if (record_stack == current)
+   __asm__ __volatile__("movq %%rsp,%0" : "=g" (stack_top));
+
if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
return kmalloc_large(size, flags);
 
--
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: virtio_blk: don't hold spin lock during world switch

[Rusty Russell]

Ming Lei  writes:
> Firstly, it isn't necessary to hold lock of vblk->vq_lock
> when notifying hypervisor about queued I/O.
>
> Secondly, virtqueue_notify() will cause world switch and
> it may take long time on some hypervisors(such as, qemu-arm),
> so it isn't good to hold the lock and block other vCPUs.
>
> On arm64 quad core VM(qemu-kvm), the patch can increase I/O
> performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
>   - without the patch: 14K IOPS
>   - with the patch: 34K IOPS
>
> fio script:
>   [global]
>   direct=1
>   bsrange=4k-4k
>   timeout=10
>   numjobs=4
>   ioengine=libaio
>   iodepth=64
>
>   filename=/dev/vdc
>   group_reporting=1
>
>   [f1]
>   rw=randread
>
> Cc: Rusty Russell 
> Cc: "Michael S. Tsirkin" 
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Ming Lei 

Acked-by: Rusty Russell 

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/

[PATCH] [TRIVIAL] Fix typo 'SCSI_NCR_SETUP_MASTER_PARITY'

[Paul Bolle]

Signed-off-by: Paul Bolle 
---
 Documentation/scsi/ncr53c8xx.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index cda5f8fa2c66..1d508dcbf859 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt
@@ -1095,7 +1095,7 @@ SCSI_NCR_SETUP_FORCE_SYNC_NEGO(default: not defined)
 SCSI_NCR_SETUP_MASTER_PARITY   (default: defined)
If defined, master parity checking is enabled.
 
-SCSI_NCR_SETUP_MASTER_PARITY   (default: defined)
+SCSI_NCR_SETUP_SCSI_PARITY (default: defined)
If defined, SCSI parity checking is enabled.
 
 SCSI_NCR_PROFILE_SUPPORT   (default: not defined)
-- 
1.9.3

--
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: virtio_blk: don't hold spin lock during world switch

[Rusty Russell]

Jens Axboe  writes:
> If Rusty agrees, I'd like to add it for 3.16 with a stable marker.

Really stable?  It improves performance, which is nice.  But every patch
which goes into the kernel fixes a bug, improves clarity, improves
performance or adds a feature.  I've now seen all four cases get CC'd
into stable.

Including some of mine explicitly not marked stable which get swept up
by enthusiastic stable maintainers :(

Is now there *any* patch short of a major rewrite which shouldn't get
cc: stable?

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

Re: [PATCH 4/4] virtio_ring: unify direct/indirect code paths.

[Rusty Russell]

Rusty Russell  writes:
> "Michael S. Tsirkin"  writes:
>> On Thu, May 29, 2014 at 04:56:45PM +0930, Rusty Russell wrote:
>>> virtqueue_add() populates the virtqueue descriptor table from the sgs
>>> given.  If it uses an indirect descriptor table, then it puts a single
>>> descriptor in the descriptor table pointing to the kmalloc'ed indirect
>>> table where the sg is populated.
>>> +   for (i = 0; i < total_sg; i++)
>>> +   desc[i].next = i+1;
>>> +   return desc;
>>
>> Hmm we are doing an extra walk over descriptors here.
>> This might hurt performance esp for big descriptors.
>
> Yes, this needs to be benchmarked; since it's cache hot my gut feel is
> that it's a NOOP, but on modern machines my gut feel is always wrong.

CC's trimmed.

Well, I was almost right about being wrong.

I wrote a userspace virtio_ring microbench which does 1000
virtqueue_add_outbuf() calls (which go indirect) and not much else.

Read as -(+/-):
Current kernel:   936153354- 967745359(9.44739e+08+/-6.1e+06)ns
Using sg_next:   1061485790-1104800648(1.08254e+09+/-6.6e+06)ns
Unifying indirect path:  1214289435-1272686712(1.22564e+09+/-8e+06)ns
Using indirect flag: 1125610268-1183528965(1.14172e+09+/-8e+06)ns

Of course this might be lost in the noise on real networking, so that's
my job on Monday.

Subject: vring_bench: simple benchmark for adding descriptors to a virtqueue.

This userspace benchark uses the kernel code to add 8 16-element
scatterlists to a virtqueue, then consume them and start again.

For example:
$ for i in `seq 10`; do ./vring_bench; done | stats --trim-outliers
936153354-967745359(9.44739e+08+/-6.1e+06)ns
872 returned

Signed-off-by: Rusty Russell 

diff --git a/tools/virtio/.gitignore b/tools/virtio/.gitignore
index 1cfbb0157a46..ff32cca971d8 100644
--- a/tools/virtio/.gitignore
+++ b/tools/virtio/.gitignore
@@ -1,3 +1,4 @@
 *.d
 virtio_test
 vringh_test
+vring_bench
diff --git a/tools/virtio/Makefile b/tools/virtio/Makefile
index 3187c62d9814..103101273049 100644
--- a/tools/virtio/Makefile
+++ b/tools/virtio/Makefile
@@ -1,6 +1,7 @@
 all: test mod
-test: virtio_test vringh_test
+test: virtio_test vringh_test vring_bench
 virtio_test: virtio_ring.o virtio_test.o
+vring_bench: virtio_ring.o vring_bench.o
 vringh_test: vringh_test.o vringh.o virtio_ring.o
 
 CFLAGS += -g -O2 -Wall -I. -I ../../usr/include/ -Wno-pointer-sign 
-fno-strict-overflow -fno-strict-aliasing -fno-common -MMD -U_FORTIFY_SOURCE
@@ -9,6 +10,6 @@ mod:
${MAKE} -C `pwd`/../.. M=`pwd`/vhost_test
 .PHONY: all test mod clean
 clean:
-   ${RM} *.o vringh_test virtio_test vhost_test/*.o vhost_test/.*.cmd \
+   ${RM} *.o vringh_test virtio_test vring_bench vhost_test/*.o 
vhost_test/.*.cmd \
   vhost_test/Module.symvers vhost_test/modules.order *.d
 -include *.d
diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h
index fba705963968..8dcff8e3374c 100644
--- a/tools/virtio/linux/kernel.h
+++ b/tools/virtio/linux/kernel.h
@@ -109,4 +109,7 @@ static inline void free_page(unsigned long addr)
(void) (&_min1 == &_min2);  \
_min1 < _min2 ? _min1 : _min2; })
 
+/* Just make it compile */
+#define list_for_each_entry(iter, list, member)
+
 #endif /* KERNEL_H */
diff --git a/tools/virtio/vring_bench.c b/tools/virtio/vring_bench.c
new file mode 100644
index ..0d7544fd26ad
--- /dev/null
+++ b/tools/virtio/vring_bench.c
@@ -0,0 +1,125 @@
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Unused */
+void *__kmalloc_fake, *__kfree_ignore_start, *__kfree_ignore_end;
+
+static struct vring vring;
+static uint16_t last_avail_idx;
+static unsigned int returned;
+
+static bool vq_notify(struct virtqueue *vq)
+{
+   /* "Use" them all. */
+   while (vring.avail->idx != last_avail_idx) {
+   unsigned int i, head;
+
+   i = last_avail_idx++ & (vring.num - 1);
+   head = vring.avail->ring[i];
+   assert(head < vring.num);
+
+   i = vring.used->idx & (vring.num - 1);
+   vring.used->ring[i].id = head;
+   vring.used->ring[i].len = 0;
+   vring.used->idx++;
+   }
+   return true;
+}
+
+static void vq_callback(struct virtqueue *vq)
+{
+   unsigned int len;
+   void *p;
+
+   while ((p = virtqueue_get_buf(vq, )) != NULL)
+   returned++;
+}
+
+/* Ring size 128, just like qemu uses */
+#define VRING_NUM 128
+#define SG_SIZE 16
+
+static inline struct timespec time_sub(struct timespec recent,
+  struct timespec old)
+{
+   struct timespec diff;
+
+   diff.tv_sec = recent.tv_sec - old.tv_sec;
+   if (old.tv_nsec > recent.tv_nsec) {
+   diff.tv_sec--;
+   diff.tv_nsec = 10 + 

[PATCH] watchdog: imx2_wdt: adds big endianness support.

[Xiubo Li]

This watchdog driver will be working on IMX2+, Vybrid, LS1, LS2+
platforms, and will be in different endianness mode in those SoCs:

SoCs CPU endian mode  WDT endian mode

IMX2+LELE
Vybird   LELE
LS1  LEBE
LS2  LELE

Signed-off-by: Xiubo Li 
---
 drivers/watchdog/imx2_wdt.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 9d4874f..68c3d37 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -190,10 +191,12 @@ static struct regmap_config imx2_wdt_regmap_config = {
 
 static int __init imx2_wdt_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
struct imx2_wdt_device *wdev;
struct watchdog_device *wdog;
struct resource *res;
void __iomem *base;
+   bool big_endian;
int ret;
u32 val;
 
@@ -201,6 +204,10 @@ static int __init imx2_wdt_probe(struct platform_device 
*pdev)
if (!wdev)
return -ENOMEM;
 
+   big_endian = of_property_read_bool(np, "big-endian");
+   if (big_endian)
+   imx2_wdt_regmap_config.val_format_endian = REGMAP_ENDIAN_BIG;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(>dev, res);
if (IS_ERR(base))
-- 
1.8.4

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

[PATCH 1/3] memory-failure: Send right signal code to correct thread

[Naoya Horiguchi]

From: Tony Luck 

When a thread in a multi-threaded application hits a machine
check because of an uncorrectable error in memory - we want to
send the SIGBUS with si.si_code = BUS_MCEERR_AR to that thread.
Currently we fail to do that if the active thread is not the
primary thread in the process. collect_procs() just finds primary
threads and this test:
if ((flags & MF_ACTION_REQUIRED) && t == current) {
will see that the thread we found isn't the current thread
and so send a si.si_code = BUS_MCEERR_AO to the primary
(and nothing to the active thread at this time).

We can fix this by checking whether "current" shares the same
mm with the process that collect_procs() said owned the page.
If so, we send the SIGBUS to current (with code BUS_MCEERR_AR).

Reported-by: Otto Bruggeman 
Signed-off-by: Tony Luck 
Cc: Andi Kleen 
Cc: Borislav Petkov 
Cc: Chen Gong 
Acked-by: Naoya Horiguchi 
---
 mm/memory-failure.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git mmotm-2014-05-21-16-57.orig/mm/memory-failure.c 
mmotm-2014-05-21-16-57/mm/memory-failure.c
index e3154d99b87f..b73098ee91e6 100644
--- mmotm-2014-05-21-16-57.orig/mm/memory-failure.c
+++ mmotm-2014-05-21-16-57/mm/memory-failure.c
@@ -204,9 +204,9 @@ static int kill_proc(struct task_struct *t, unsigned long 
addr, int trapno,
 #endif
si.si_addr_lsb = page_size_order(page) + PAGE_SHIFT;
 
-   if ((flags & MF_ACTION_REQUIRED) && t == current) {
+   if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
si.si_code = BUS_MCEERR_AR;
-   ret = force_sig_info(SIGBUS, , t);
+   ret = force_sig_info(SIGBUS, , current);
} else {
/*
 * Don't use force here, it's convenient if the signal
-- 
1.9.3

--
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] memory-failure: Don't let collect_procs() skip over processes for MF_ACTION_REQUIRED

[Naoya Horiguchi]

From: Tony Luck 

When Linux sees an "action optional" machine check (where h/w has
reported an error that is not in the current execution path) we
generally do not want to signal a process, since most processes
do not have a SIGBUS handler - we'd just prematurely terminate the
process for a problem that they might never actually see.

task_early_kill() decides whether to consider a process - and it
checks whether this specific process has been marked for early signals
with "prctl", or if the system administrator has requested early
signals for all processes using /proc/sys/vm/memory_failure_early_kill.

But for MF_ACTION_REQUIRED case we must not defer. The error is in
the execution path of the current thread so we must send the SIGBUS
immediatley.

Fix by passing a flag argument through collect_procs*() to
task_early_kill() so it knows whether we can defer or must
take action.

Signed-off-by: Tony Luck 
Cc: Andi Kleen 
Cc: Borislav Petkov 
Cc: Chen Gong 
Acked-by: Naoya Horiguchi 
---
 mm/memory-failure.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git mmotm-2014-05-21-16-57.orig/mm/memory-failure.c 
mmotm-2014-05-21-16-57/mm/memory-failure.c
index b73098ee91e6..fbcdb1d54c55 100644
--- mmotm-2014-05-21-16-57.orig/mm/memory-failure.c
+++ mmotm-2014-05-21-16-57/mm/memory-failure.c
@@ -380,10 +380,12 @@ static void kill_procs(struct list_head *to_kill, int 
forcekill, int trapno,
}
 }
 
-static int task_early_kill(struct task_struct *tsk)
+static int task_early_kill(struct task_struct *tsk, int force_early)
 {
if (!tsk->mm)
return 0;
+   if (force_early)
+   return 1;
if (tsk->flags & PF_MCE_PROCESS)
return !!(tsk->flags & PF_MCE_EARLY);
return sysctl_memory_failure_early_kill;
@@ -393,7 +395,7 @@ static int task_early_kill(struct task_struct *tsk)
  * Collect processes when the error hit an anonymous page.
  */
 static void collect_procs_anon(struct page *page, struct list_head *to_kill,
- struct to_kill **tkc)
+ struct to_kill **tkc, int force_early)
 {
struct vm_area_struct *vma;
struct task_struct *tsk;
@@ -409,7 +411,7 @@ static void collect_procs_anon(struct page *page, struct 
list_head *to_kill,
for_each_process (tsk) {
struct anon_vma_chain *vmac;
 
-   if (!task_early_kill(tsk))
+   if (!task_early_kill(tsk, force_early))
continue;
anon_vma_interval_tree_foreach(vmac, >rb_root,
   pgoff, pgoff) {
@@ -428,7 +430,7 @@ static void collect_procs_anon(struct page *page, struct 
list_head *to_kill,
  * Collect processes when the error hit a file mapped page.
  */
 static void collect_procs_file(struct page *page, struct list_head *to_kill,
- struct to_kill **tkc)
+ struct to_kill **tkc, int force_early)
 {
struct vm_area_struct *vma;
struct task_struct *tsk;
@@ -439,7 +441,7 @@ static void collect_procs_file(struct page *page, struct 
list_head *to_kill,
for_each_process(tsk) {
pgoff_t pgoff = page_pgoff(page);
 
-   if (!task_early_kill(tsk))
+   if (!task_early_kill(tsk, force_early))
continue;
 
vma_interval_tree_foreach(vma, >i_mmap, pgoff,
@@ -465,7 +467,8 @@ static void collect_procs_file(struct page *page, struct 
list_head *to_kill,
  * First preallocate one tokill structure outside the spin locks,
  * so that we can kill at least one process reasonably reliable.
  */
-static void collect_procs(struct page *page, struct list_head *tokill)
+static void collect_procs(struct page *page, struct list_head *tokill,
+   int force_early)
 {
struct to_kill *tk;
 
@@ -476,9 +479,9 @@ static void collect_procs(struct page *page, struct 
list_head *tokill)
if (!tk)
return;
if (PageAnon(page))
-   collect_procs_anon(page, tokill, );
+   collect_procs_anon(page, tokill, , force_early);
else
-   collect_procs_file(page, tokill, );
+   collect_procs_file(page, tokill, , force_early);
kfree(tk);
 }
 
@@ -963,7 +966,7 @@ static int hwpoison_user_mappings(struct page *p, unsigned 
long pfn,
 * there's nothing that can be done.
 */
if (kill)
-   collect_procs(ppage, );
+   collect_procs(ppage, , flags & MF_ACTION_REQUIRED);
 
ret = try_to_unmap(ppage, ttu);
if (ret != SWAP_SUCCESS)
-- 
1.9.3

--
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] mm/memory-failure.c: support dedicated thread to handle SIGBUS(BUS_MCEERR_AO)

[Naoya Horiguchi]

Currently memory error handler handles action optional errors in the deferred
manner by default. And if a recovery aware application wants to handle it
immediately, it can do it by setting PF_MCE_EARLY flag. However, such signal
can be sent only to the main thread, so it's problematic if the application
wants to have a dedicated thread to handler such signals.

So this patch adds dedicated thread support to memory error handler. We have
PF_MCE_EARLY flags for each thread separately, so with this patch AO signal
is sent to the thread with PF_MCE_EARLY flag set, not the main thread. If
you want to implement a dedicated thread, you call prctl() to set PF_MCE_EARLY
on the thread.

Memory error handler collects processes to be killed, so this patch lets it
check PF_MCE_EARLY flag on each thread in the collecting routines.

No behavioral change for all non-early kill cases.

ChangeLog:
- document more specifically
- add parenthesis in find_early_kill_thread()
- move position of find_early_kill_thread() and task_early_kill()

Signed-off-by: Naoya Horiguchi 
Reviewed-by: Tony Luck 
Cc: Kamil Iskra 
Cc: Andi Kleen 
Cc: Borislav Petkov 
Cc: Chen Gong 
---
 Documentation/vm/hwpoison.txt |  5 
 mm/memory-failure.c   | 58 ---
 2 files changed, 48 insertions(+), 15 deletions(-)

diff --git mmotm-2014-05-21-16-57.orig/Documentation/vm/hwpoison.txt 
mmotm-2014-05-21-16-57/Documentation/vm/hwpoison.txt
index 550068466605..6ae89a9edf2a 100644
--- mmotm-2014-05-21-16-57.orig/Documentation/vm/hwpoison.txt
+++ mmotm-2014-05-21-16-57/Documentation/vm/hwpoison.txt
@@ -84,6 +84,11 @@ PR_MCE_KILL
PR_MCE_KILL_EARLY: Early kill
PR_MCE_KILL_LATE:  Late kill
PR_MCE_KILL_DEFAULT: Use system global default
+   Note that if you want to have a dedicated thread which handles
+   the SIGBUS(BUS_MCEERR_AO) on behalf of the process, you should
+   call prctl(PR_MCE_KILL_EARLY) on the designated thread. Otherwise,
+   the SIGBUS is sent to the main thread.
+
 PR_MCE_KILL_GET
return current mode
 
diff --git mmotm-2014-05-21-16-57.orig/mm/memory-failure.c 
mmotm-2014-05-21-16-57/mm/memory-failure.c
index fbcdb1d54c55..9751e19ab13b 100644
--- mmotm-2014-05-21-16-57.orig/mm/memory-failure.c
+++ mmotm-2014-05-21-16-57/mm/memory-failure.c
@@ -380,15 +380,44 @@ static void kill_procs(struct list_head *to_kill, int 
forcekill, int trapno,
}
 }
 
-static int task_early_kill(struct task_struct *tsk, int force_early)
+/*
+ * Find a dedicated thread which is supposed to handle SIGBUS(BUS_MCEERR_AO)
+ * on behalf of the thread group. Return task_struct of the (first found)
+ * dedicated thread if found, and return NULL otherwise.
+ */
+static struct task_struct *find_early_kill_thread(struct task_struct *tsk)
+{
+   struct task_struct *t;
+   rcu_read_lock();
+   for_each_thread(tsk, t)
+   if ((t->flags & PF_MCE_PROCESS) && (t->flags & PF_MCE_EARLY))
+   goto found;
+   t = NULL;
+found:
+   rcu_read_unlock();
+   return t;
+}
+
+/*
+ * Determine whether a given process is "early kill" process which expects
+ * to be signaled when some page under the process is hwpoisoned.
+ * Return task_struct of the dedicated thread (main thread unless explicitly
+ * specified) if the process is "early kill," and otherwise returns NULL.
+ */
+static struct task_struct *task_early_kill(struct task_struct *tsk,
+  int force_early)
 {
+   struct task_struct *t;
if (!tsk->mm)
-   return 0;
+   return NULL;
if (force_early)
-   return 1;
-   if (tsk->flags & PF_MCE_PROCESS)
-   return !!(tsk->flags & PF_MCE_EARLY);
-   return sysctl_memory_failure_early_kill;
+   return tsk;
+   t = find_early_kill_thread(tsk);
+   if (t)
+   return t;
+   if (sysctl_memory_failure_early_kill)
+   return tsk;
+   return NULL;
 }
 
 /*
@@ -410,16 +439,16 @@ static void collect_procs_anon(struct page *page, struct 
list_head *to_kill,
read_lock(_lock);
for_each_process (tsk) {
struct anon_vma_chain *vmac;
-
-   if (!task_early_kill(tsk, force_early))
+   struct task_struct *t = task_early_kill(tsk, force_early);
+   if (!t)
continue;
anon_vma_interval_tree_foreach(vmac, >rb_root,
   pgoff, pgoff) {
vma = vmac->vma;
if (!page_mapped_in_vma(page, vma))
continue;
-   if (vma->vm_mm == tsk->mm)
-   add_to_kill(tsk, page, vma, to_kill, tkc);
+   if (vma->vm_mm == t->mm)
+   add_to_kill(t, page, vma, to_kill, tkc);
   

[PATCH 0/3] HWPOISON: improve memory error handling for multithread process

[Naoya Horiguchi]

This patchset is the summary of recent discussion about memory error handling
on multithread application. Patch 1 and 2 is for action required errors, and
patch 3 is for action optional errors.

This patchset is based on mmotm-2014-05-21-16-57.

Patches are also available on the following tree/branch.
  g...@github.com:Naoya-Horiguchi/linux.git hwpoison/master

Thanks,
Naoya Horiguchi
---
Summary:

Naoya Horiguchi (1):
  mm/memory-failure.c: support dedicated thread to handle 
SIGBUS(BUS_MCEERR_AO)

Tony Luck (2):
  memory-failure: Send right signal code to correct thread
  memory-failure: Don't let collect_procs() skip over processes for 
MF_ACTION_REQUIRED

 Documentation/vm/hwpoison.txt |  5 +++
 mm/memory-failure.c   | 75 ++-
 2 files changed, 58 insertions(+), 22 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm/gk20a/fb: use dma_alloc_coherent() for VRAM

[Alexandre Courbot]

GK20A's RAM driver was using CMA functions in order to allocate VRAM.
This is wrong because these functions are not exported, which causes
compilation to fail when CMA is enabled and Nouveau is built as a
module. On top of that the driver was leaking (or rather bleeding)
memory.

dma_alloc_coherent() will also use CMA when needed but has the
advantage of being properly exported. It creates a permanent kernel
mapping, but experiment revealed that the lowmem mapping is actually
reused, and this mapping can also be taken advantage of to implement
faster instmem. We lose the ability to allocate memory at finer
granularity, but that's what CMA is here for and it also simplifies the
driver.

This driver is to be replaced by an IOMMU-based one in the future ;
until then, its current form will allow it to do its job.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c | 97 ++-
 1 file changed, 42 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c 
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
index 7effd1a63458..10cdcf8b8a7f 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
@@ -24,32 +24,32 @@
 
 #include 
 
-#include 
 #include 
-#include 
+#include 
+#include 
+
+struct gk20a_mem {
+   struct nouveau_mem base;
+   void *cpuaddr;
+   dma_addr_t handle;
+};
+#define to_gk20a_mem(m) container_of(m, struct gk20a_mem, base)
 
 static void
 gk20a_ram_put(struct nouveau_fb *pfb, struct nouveau_mem **pmem)
 {
struct device *dev = nv_device_base(nv_device(pfb));
-   struct nouveau_mem *mem = *pmem;
-   int i;
+   struct gk20a_mem *mem = to_gk20a_mem(*pmem);
 
*pmem = NULL;
if (unlikely(mem == NULL))
return;
 
-   for (i = 0; i < mem->size; i++) {
-   struct page *page;
-
-   if (mem->pages[i] == 0)
-   break;
+   if (likely(mem->cpuaddr))
+   dma_free_coherent(dev, mem->base.size << PAGE_SHIFT,
+ mem->cpuaddr, mem->handle);
 
-   page = pfn_to_page(mem->pages[i] >> PAGE_SHIFT);
-   dma_release_from_contiguous(dev, page, 1);
-   }
-
-   kfree(mem->pages);
+   kfree(mem->base.pages);
kfree(mem);
 }
 
@@ -58,11 +58,9 @@ gk20a_ram_get(struct nouveau_fb *pfb, u64 size, u32 align, 
u32 ncmin,
 u32 memtype, struct nouveau_mem **pmem)
 {
struct device *dev = nv_device_base(nv_device(pfb));
-   struct nouveau_mem *mem;
-   int type = memtype & 0xff;
-   dma_addr_t dma_addr;
-   int npages;
-   int order;
+   struct gk20a_mem *mem;
+   u32 type = memtype & 0xff;
+   u32 npages, order;
int i;
 
nv_debug(pfb, "%s: size: %llx align: %x, ncmin: %x\n", __func__, size,
@@ -80,59 +78,48 @@ gk20a_ram_get(struct nouveau_fb *pfb, u64 size, u32 align, 
u32 ncmin,
order = fls(align);
if ((align & (align - 1)) == 0)
order--;
+   align = BIT(order);
 
-   ncmin >>= PAGE_SHIFT;
-   /*
-* allocate pages by chunks of "align" size, otherwise we may leave
-* holes in the contiguous memory area.
-*/
-   if (ncmin == 0)
-   ncmin = npages;
-   else if (align > ncmin)
-   ncmin = align;
+   /* ensure returned address is correctly aligned */
+   npages = max(align, npages);
 
mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return -ENOMEM;
 
-   mem->size = npages;
-   mem->memtype = type;
+   mem->base.size = npages;
+   mem->base.memtype = type;
 
-   mem->pages = kzalloc(sizeof(dma_addr_t) * npages, GFP_KERNEL);
-   if (!mem) {
+   mem->base.pages = kzalloc(sizeof(dma_addr_t) * npages, GFP_KERNEL);
+   if (!mem->base.pages) {
kfree(mem);
return -ENOMEM;
}
 
-   while (npages) {
-   struct page *pages;
-   int pos = 0;
-
-   /* don't overflow in case size is not a multiple of ncmin */
-   if (ncmin > npages)
-   ncmin = npages;
-
-   pages = dma_alloc_from_contiguous(dev, ncmin, order);
-   if (!pages) {
-   gk20a_ram_put(pfb, );
-   return -ENOMEM;
-   }
+   *pmem = >base;
 
-   dma_addr = (dma_addr_t)(page_to_pfn(pages) << PAGE_SHIFT);
+   mem->cpuaddr = dma_alloc_coherent(dev, npages << PAGE_SHIFT,
+ >handle, GFP_KERNEL);
+   if (!mem->cpuaddr) {
+   nv_error(pfb, "%s: cannot allocate memory!\n", __func__);
+   gk20a_ram_put(pfb, pmem);
+   return -ENOMEM;
+   }
 
-   nv_debug(pfb, "  alloc count: %x, order: %x, addr: %pad\n", 
ncmin,
-   

Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

[Al Viro]

On Thu, May 29, 2014 at 10:00:49PM -0700, Linus Torvalds wrote:

> Yeah, I think that would be good. Except I think you should create a
> "dentry_is_dead()" helper function that then has that "if you hold the
> dentry or parent lock, this is safe" comment, because for lockref in
> general you do need to have the lock in the lockref itself. The fact
> that dentries have more locking is very much dentry-specific.

With how many callers?  There literally are only two places where we look
at that bit; one of them very tempting to convert to ->d_lockref.count != 0,
since reactions to positive and negative are very similar.  We also have
that bogus BUG_ON() you've mentioned (that one simply should die) and only
one place where we check it for being negative - autofs4_lookup_active().
And that one is better dealt with by taking removal from their active
list from ->d_release() to ->d_prune() (if not turning their ->d_release()
into ->d_prune() wholesale) and making ->d_prune() called for hashed and
unhashed alike (the only instance *already* checks for d_unhashed() and does
nothing in that case; no need to check that in fs/dcache.c).  With that done,
the check will be gone - all it does is filtering out the ones that are
already on the way out, but still hadn't reached ->d_release()).

IOW, it's not a widely used functionality and it's really not something
that should be ever needed outside of fs/dcache.c.  And in fs/dcache.c
we have one call site, so I'm not sure if even mentioning __lockref_not_dead()
would make much sense - (int)child->d_lockref.count < 0 might be better,
along with a comment about ->d_parent->d_lock serializing it against
lockref_mark_dead() in __dentry_kill() just as well as ->d_lock would...

Note that the only reason why autofs is playing those games is that they
keep references to dentries that do not contribute to refcount, rip them
out when dentry is killed and do that in the wrong method, which opens the
window when ->d_lock is already dropped and ->d_release() is inevitable
but yet to be called.  Solution: rip those references out before dropping
->d_lock, which is what ->d_prune() gives us.  To be fair, that code
predates ->d_prune() by several years (Jul 2008 and Oct 2011, resp.)

And "vfs: call d_op->d_prune() before unhashing dentry" has added very
odd checks for !d_unhashed(), despite ceph ->d_prune() being an explicit
no-op in other cases...

While we are at it, what the devil is d_prune_aliases() doing?  OK, we
grab ->d_lock and see that refcount is 0.  Then we call ->d_prune(),
bump refcount to 1, forcibly unhash the sucker, drop ->d_lock and ->i_lock
and call dput().  Which seems to be far too convoluted...  AFAICS, what we
want to do is
spin_lock(>d_lock);
if (!dentry->d_lockref.count) {
parent = lock_parent(dentry);
if (likely(!dentry->d_lockref.count)) {
__dentry_kill(dentry);
goto restart;
}
if (parent)
spin_unlock(>d_lock);
}
spin_unlock(>d_lock);
(which means that pulling ->i_lock trylock into __dentry_kill() is
probably not a good plan, more's the pity...)  And there goes this second
call site of ->d_prune() - after that it would be called exactly in one place,
right after __dentry_kill() has done lockref_mark_dead().  The whole reason
for calling it there was that forcible unhash used to force dput() to kill
the sucker has a side effect of messing ceph ->d_prune()...
--
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/