date:20130529


When "cp >= barg_buf + BARG_LEN-2", it breaks internel looping 'while',
but outside loop 'for' still has effect, so "*cp++ = ' '" will continue
repeating which may cause memory overflow.

So need additional length check for it in the outside looping.

Also beautify the related code which found by "./scripts/checkpatch.pl"


Signed-off-by: Chen Gang 
---
 arch/sparc/prom/bootstr_32.c |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/prom/bootstr_32.c b/arch/sparc/prom/bootstr_32.c
index f5ec32e..d2b49d2 100644
--- a/arch/sparc/prom/bootstr_32.c
+++ b/arch/sparc/prom/bootstr_32.c
@@ -23,23 +23,25 @@ prom_getbootargs(void)
return barg_buf;
}
 
-   switch(prom_vers) {
+   switch (prom_vers) {
case PROM_V0:
cp = barg_buf;
/* Start from 1 and go over fd(0,0,0)kernel */
-   for(iter = 1; iter < 8; iter++) {
+   for (iter = 1; iter < 8; iter++) {
arg = (*(romvec->pv_v0bootargs))->argv[iter];
if (arg == NULL)
break;
-   while(*arg != 0) {
+   while (*arg != 0) {
/* Leave place for space and null. */
-   if(cp >= barg_buf + BARG_LEN-2){
+   if (cp >= barg_buf + BARG_LEN - 2)
/* We might issue a warning here. */
break;
-   }
*cp++ = *arg++;
}
*cp++ = ' ';
+   if (cp >= barg_buf + BARG_LEN - 1)
+   /* We might issue a warning here. */
+   break;
}
*cp = 0;
break;
-- 
1.7.7.6
--
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] scsi: Introduce a help function local_time_seconds() to simplify the getting time stamp operation

2013-05-29 Thread Gu Zheng

On 05/30/2013 11:00 AM, Libo Chen wrote:

> On 2013/5/29 17:33, Gu Zheng wrote:
>> >From 4d4caa16f3886ae910ad6dfe13353fc836f546cc Mon Sep 17 00:00:00 2001
>> From: Gu Zheng 
>> Date: Wed, 29 May 2013 17:34:22 +0900
>> Subject: [PATCH] driver/scsi: Introduce a help function local_time_seconds() 
>> to simplify the getting time stamp operation
>>
> hi gu,
> 
> next time, you can remove above info.

Ah~, I forgot to clean up the unnecessary title infos, thanks for your reminder.

Regards,
Gu

> 
> 
> thanks,
> 
> Libo
> 
> 
>> Signed-off-by: Gu Zheng 
>> ---
>>  drivers/scsi/3w-9xxx.c |   14 ++
>>  drivers/scsi/3w-sas.c  |   14 ++
>>  include/scsi/scsi.h|9 +
>>  3 files changed, 13 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
>> index 5e1e12c..44b3ea8 100644
>> --- a/drivers/scsi/3w-9xxx.c
>> +++ b/drivers/scsi/3w-9xxx.c
>> @@ -374,8 +374,6 @@ out:
>>  /* This function will queue an event */
>>  static void twa_aen_queue_event(TW_Device_Extension *tw_dev, 
>> TW_Command_Apache_Header *header)
>>  {
>> -u32 local_time;
>> -struct timeval time;
>>  TW_Event *event;
>>  unsigned short aen;
>>  char host[16];
>> @@ -398,9 +396,7 @@ static void twa_aen_queue_event(TW_Device_Extension 
>> *tw_dev, TW_Command_Apache_H
>>  memset(event, 0, sizeof(TW_Event));
>>  
>>  event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
>> -do_gettimeofday();
>> -local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
>> -event->time_stamp_sec = local_time;
>> +event->time_stamp_sec = local_time_seconds();
>>  event->aen_code = aen;
>>  event->retrieved = TW_AEN_NOT_RETRIEVED;
>>  event->sequence_id = tw_dev->error_sequence_id;
>> @@ -479,11 +475,9 @@ out:
>>  static void twa_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>>  {
>>  u32 schedulertime;
>> -struct timeval utc;
>>  TW_Command_Full *full_command_packet;
>>  TW_Command *command_packet;
>>  TW_Param_Apache *param;
>> -u32 local_time;
>>  
>>  /* Fill out the command packet */
>>  full_command_packet = tw_dev->command_packet_virt[request_id];
>> @@ -503,11 +497,7 @@ static void twa_aen_sync_time(TW_Device_Extension 
>> *tw_dev, int request_id)
>>  param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
>>  param->parameter_size_bytes = cpu_to_le16(4);
>>  
>> -/* Convert system time in UTC to local time seconds since last 
>> -   Sunday 12:00AM */
>> -do_gettimeofday();
>> -local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
>> -schedulertime = local_time - (3 * 86400);
>> +schedulertime = local_time_seconds() - (3 * 86400);
>>  schedulertime = cpu_to_le32(schedulertime % 604800);
>>  
>>  memcpy(param->data, , sizeof(u32));
>> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
>> index c845bdb..69f1d8a 100644
>> --- a/drivers/scsi/3w-sas.c
>> +++ b/drivers/scsi/3w-sas.c
>> @@ -236,8 +236,6 @@ out:
>>  /* This function will queue an event */
>>  static void twl_aen_queue_event(TW_Device_Extension *tw_dev, 
>> TW_Command_Apache_Header *header)
>>  {
>> -u32 local_time;
>> -struct timeval time;
>>  TW_Event *event;
>>  unsigned short aen;
>>  char host[16];
>> @@ -256,9 +254,7 @@ static void twl_aen_queue_event(TW_Device_Extension 
>> *tw_dev, TW_Command_Apache_H
>>  memset(event, 0, sizeof(TW_Event));
>>  
>>  event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
>> -do_gettimeofday();
>> -local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
>> -event->time_stamp_sec = local_time;
>> +event->time_stamp_sec = local_time_seconds();
>>  event->aen_code = aen;
>>  event->retrieved = TW_AEN_NOT_RETRIEVED;
>>  event->sequence_id = tw_dev->error_sequence_id;
>> @@ -444,11 +440,9 @@ out:
>>  static void twl_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>>  {
>>  u32 schedulertime;
>> -struct timeval utc;
>>  TW_Command_Full *full_command_packet;
>>  TW_Command *command_packet;
>>  TW_Param_Apache *param;
>> -u32 local_time;
>>  
>>  /* Fill out the command packet */
>>  full_command_packet = tw_dev->command_packet_virt[request_id];
>> @@ -468,11 +462,7 @@ static void twl_aen_sync_time(TW_Device_Extension 
>> *tw_dev, int request_id)
>>  param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
>>  param->parameter_size_bytes = cpu_to_le16(4);
>>  
>> -/* Convert system time in UTC to local time seconds since last 
>> -   Sunday 12:00AM */
>> -do_gettimeofday();
>> -local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
>> -schedulertime = local_time - (3 * 86400);
>> +schedulertime = local_time_seconds() - (3 * 86400);
>>  schedulertime = cpu_to_le32(schedulertime % 604800);
>>  
>>  memcpy(param->data, , sizeof(u32));
>>

Re: [PATCH RFC v2] media: OF: add sync-on-green endpoint property

2013-05-29 Thread Laurent Pinchart

Hi Sylwester,

On Saturday 25 May 2013 16:11:52 Sylwester Nawrocki wrote:
> On 05/25/2013 11:17 AM, Prabhakar Lad wrote:
> >> > From looking at Figure 8 "TVP7002 Application Example" in the TVP7002's
> >> > datasheet ([2], p. 52) and your initial TVP7002 patches it looks like
> >> > what you want is to specify polarity of the SOGOUT signal, so the
> >> > processor that receives this signal can properly interpret it, is it
> >> > correct ?
> > 
> > Yes
> > 
> >> >  If so then wouldn't it be more appropriate to define e.g. 'sog-active'
> >> >  property and media bus flags:
> >> >   V4L2_MBUS_SYNC_ON_GREEN_ACTIVE_LOW
> >> >   V4L2_MBUS_SYNC_ON_GREEN_ACTIVE_HIGH
> >> >  
> >> >  ?
> > 
> > Agreed I'll add these flags.
> > 
> >> >  And for synchronisation method on the analog part we could perhaps
> >> >  define 'component-sync' or similar property that would enumerate all
> >> >  possible synchronisation methods. We might as well use separate
> >> >  boolean properties, but I'm a bit concerned about the increasing
> >> >  number of properties that need to be parsed for each parallel video
> >> >  bus "endpoint".
> > 
> > I am not clear on it can please elaborate more on this.
> 
> I thought about two possible options:
> 
> 1. single property 'component-sync' or 'video-sync' that would have values:
> 
> #define VIDEO_SEPARATE_SYNC   0x01
> #define VIDEO_COMPOSITE_SYNC  0x02
> #define VIDEO_SYNC_ON_COMPOSITE   0x04
> #define VIDEO_SYNC_ON_GREEN   0x08
> #define VIDEO_SYNC_ON_LUMINANCE   0x10
> 
> And we could put these definitions into a separate header, e.g.
> 
> 
> Then in a device tree source file one could have, e.g.
> 
> video-sync = ;
> 
> 
> 2. Separate boolean property for each video sync type, e.g.
> 
>   "video-composite-sync"
>   "video-sync-on-composite"
>   "video-sync-on-green"
>   "video-sync-on-luminance"
> 
> Separate sync, with separate VSYNC, HSYNC lines, would be the default, when
> none of the above is specified and 'vsync-active', 'hsync-active' properties
> are present.

I prefer 1. over 2.

> However, I suppose the better would be to deduce the video synchronisation
> method from the sync signal polarity flags. Then, for instance, when an
> endpoint node contains "composite-sync-active" property the parser would
> determine the "composite sync" synchronisation type is used.
> 
> Thus it might make sense to have only following integer properties (added
> as needed):
> 
> composite-sync-active
> sync-on-green-active
> sync-on-comp-active
> sync-on-luma-active
> 
> This would allow to specify polarity of each signal and at the same time
> the parsing code could derive synchronisation type. A new field could be
> added to struct v4l2_of_parallel_bus, e.g. sync_type and it would be filled
> within v4l2_of_parse_endpoint().
> 
> What do you think ?

My gut feeling is that we should have separate properties for the video sync 
type and the synchronization signals polarities. We could have a chip that 
supports sync-on-green on the analog (input) side and outputs separate hsync 
and vsync signals only on the digital (output) side. There would be no sync-
on-green polarity in that case.

-- 
Regards,

Laurent Pinchart

--
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: a question about range_map_cfg

2013-05-29 Thread Bard Liao

> -Original Message-
> From: Mark Brown [mailto:broo...@sirena.org.uk]
> Sent: Wednesday, May 29, 2013 10:56 PM
> To: Bard Liao
> Cc: Stephen Warren
> Subject: Re: a question about range_map_cfg
> 
> On Wed, May 29, 2013 at 08:46:40PM +0800, Bard Liao wrote:
> 
> > > However, I /think/ that the window_start/len fields in
> > > regmap_range_cfg are meant to represent the "virtual" registers
> > > numbers of the registers behind the addr/data keyhole, and hence
> > > should be 0x100 and something much larger than 1, respectively. Does that
> solve the problem?
> 
> > In my opinion, window_start represents the address of indirectly accessed
> registers' data.
> > Ie. If we want to access the private register of ALC5640, we should
> > write the private register's address to 0x6a which is defined in 
> > .selector_reg.
> > Then read/write it's data from reg 0x6c which is defined in .window_start.
> > And the .window_len represents the data length of indirectly accessed
> register.
> > So if I set .window_len = 2 for example, it will write the private
> > register's address to 0x6a, and read/write 0x6c and 0x6d to access the
> private register's data.
> > But I don't know if my thought is right or not.
> 
> That sounds about right, though obviously that's a *very* small window.
> The window is the physical registers through which the range can be seen, the
> range is the virtual registers where the windowed region is linearised for
> upper layers.
> 
> > I look at regmap-debugfs.c and guess the issue is from
> regmap_debugfs_get_dump_start function.
> > It add debugfs_off_cache list in if (list_empty(>debugfs_off_cache))
> condition.
> > So if I cat "PR" first, it will add indirectly accessed registers' range in
> debugfs_off_cache.
> > But after that if I cat "range" or "registers" debugfs_off_cache is not 
> > empty.
> > So it will not enter if (list_empty(>debugfs_off_cache)) condition.
> > That's why I will only see indirectly accessed registers' data from "range"
> and "registers".
> > In the other case, if I cat "registers" or "range" first,
> > regmap_debugfs_get_dump_start will add all registers'(including directly
> and indirectly accessed registers) range in debugfs_off_cache.
> 
> Yes, the cache should be suppressed in the case where we're not looking at the
> full map.  Try the patch below:
> 
> From c53da2153185cf3f522ce4952e4148aa7287cb89 Mon Sep 17 00:00:00
> 2001
> From: Mark Brown 
> Date: Wed, 29 May 2013 15:54:54 +0100
> Subject: [PATCH] regmap: debugfs: Suppress cache for partial register files
> 
> The cache is based on the full register map so confuses things if used for a
> partial map.

Unfortunately, it does not work.
Actually, I see from is always 0, so it never enter the "if (from)" condition.


> 
> Reported-by: Bard Liao 
> Signed-off-by: Mark Brown 
> ---
>  drivers/base/regmap/regmap-debugfs.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/base/regmap/regmap-debugfs.c
> b/drivers/base/regmap/regmap-debugfs.c
> index 98cb94e..5349575 100644
> --- a/drivers/base/regmap/regmap-debugfs.c
> +++ b/drivers/base/regmap/regmap-debugfs.c
> @@ -84,6 +84,10 @@ static unsigned int
> regmap_debugfs_get_dump_start(struct regmap *map,
>   unsigned int fpos_offset;
>   unsigned int reg_offset;
> 
> + /* Suppress the cache if we're using a subrange */
> + if (from)
> + return from;
> +
>   /*
>* If we don't have a cache build one so we don't have to do a
>* linear scan each time.
> --
> 1.7.10.4
> 
> 
> --Please consider the environment before printing this e-mail.
--
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] arch: frv: kernel: using strncmp() instead of memcmp()


'cmdline' is a NUL terminated string, when its length < 4, memcmp()
will cause memory access out of boundary.

So need use strncmp() instead of memcmp().


Signed-off-by: Chen Gang 
---
 arch/frv/kernel/setup.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
index a513647..622d5ee 100644
--- a/arch/frv/kernel/setup.c
+++ b/arch/frv/kernel/setup.c
@@ -735,7 +735,7 @@ static void __init parse_cmdline_early(char *cmdline)
/* "mem=XXX[kKmM]" sets SDRAM size to , overriding the 
value we worked
 * out from the SDRAM controller mask register
 */
-   if (!memcmp(cmdline, "mem=", 4)) {
+   if (!strncmp(cmdline, "mem=", 4)) {
unsigned long long mem_size;
 
mem_size = memparse(cmdline + 4, );
-- 
1.7.7.6
--
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 v1 02/13] mrst: Fixed indentation issues

Fixed indentation issues reported by checkpatch script in
mrst related files.

Change-Id: I4deceed3ff2fc92bdb8118300f18eed963b9b988
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/pci/mrst.c|4 ++--
 arch/x86/platform/mrst/early_printk_mrst.c |3 ++-
 arch/x86/platform/mrst/mrst.c  |   24 +---
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pci/mrst.c b/arch/x86/pci/mrst.c
index a08cf1b..66a672e 100644
--- a/arch/x86/pci/mrst.c
+++ b/arch/x86/pci/mrst.c
@@ -251,8 +251,8 @@ static void pci_d3delay_fixup(struct pci_dev *dev)
 {
/* PCI fixups are effectively decided compile time. If we have a dual
   SoC/non-SoC kernel we don't want to mangle d3 on non SoC devices */
-if (!pci_soc_mode)
-return;
+   if (!pci_soc_mode)
+   return;
/* true pci devices in lincroft should allow type 1 access, the rest
 * are langwell fake pci devices.
 */
diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 95880f7..39ecc27 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -219,7 +219,8 @@ static void early_mrst_spi_putc(char c)
 }
 
 /* Early SPI only uses polling mode */
-static void early_mrst_spi_write(struct console *con, const char *str, 
unsigned n)
+static void early_mrst_spi_write(struct console *con, const char *str,
+   unsigned n)
 {
int i;
 
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index fbfbe36..58cdfd1 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -131,7 +131,7 @@ struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
int i;
if (hint < sfi_mtimer_num) {
if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",\
+   pr_debug("hint taken for timer %d irq %d\n",
hint, sfi_mtimer_array[hint].irq);
sfi_mtimer_usage[hint] = 1;
return _mtimer_array[hint];
@@ -679,14 +679,14 @@ static void *msic_thermal_platform_data(void *info)
 /* tc35876x DSI-LVDS bridge chip and panel platform data */
 static void *tc35876x_platform_data(void *data)
 {
-   static struct tc35876x_platform_data pdata;
+   static struct tc35876x_platform_data pdata;
 
-   /* gpio pins set to -1 will not be used by the driver */
-   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
-   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
-   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+   /* gpio pins set to -1 will not be used by the driver */
+   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
 
-   return 
+   return 
 }
 
 static const struct devs_id __initconst device_ids[] = {
@@ -729,7 +729,7 @@ static int i2c_next_dev;
 
 static void __init intel_scu_device_register(struct platform_device *pdev)
 {
-   if(ipc_next_dev == MAX_IPCDEVS)
+   if (ipc_next_dev == MAX_IPCDEVS)
pr_err("too many SCU IPC devices");
else
ipc_devs[ipc_next_dev++] = pdev;
@@ -872,7 +872,8 @@ static void __init sfi_handle_spi_dev(struct spi_board_info 
*spi_info)
 
while (dev->name[0]) {
if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias, 
SFI_NAME_LEN)) {
+   !strncmp(dev->name, spi_info->modalias,
+   SFI_NAME_LEN)) {
pdata = dev->get_platform_data(spi_info);
break;
}
@@ -904,7 +905,7 @@ static void __init sfi_handle_i2c_dev(int bus, struct 
i2c_board_info *i2c_info)
intel_scu_i2c_device_register(bus, i2c_info);
else
i2c_register_board_info(bus, i2c_info, 1);
- }
+}
 
 
 static int __init sfi_parse_devs(struct sfi_table_header *table)
@@ -1034,7 +1035,8 @@ static int __init pb_keys_init(void)
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
gb[i].gpio = get_gpio_by_name(gb[i].desc);
-   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc, 
gb[i].gpio);
+   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
+   gb[i].gpio);
if (gb[i].gpio == -1)
continue;
 
-- 
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

[PATCH v1 00/13] mrst refactoring patches

As Intel rolling out more SoC's after Moorestown, we need to re-structure
the code in a way that is backward compatible and easy to expand.This
patch set implements a flexible way to support multiple boards and devices.

Patch 1 - 5 fixes some indentation issue, compiler warnings and renames.
Patch 6 - 13 refactors mrst code.

Andy Shevchenko (2):
  sfi: fix compiler warnings
  gpiolib: append SFI helpers for GPIO API

Sathyanarayanan Kuppuswamy (11):
  mrst: Fixed printk/pr_* related issues
  mrst: Fixed indentation issues
  mrst: Fixed checkpatch warnings
  intel_mid: Renamed *mrst* to *intel_mid*
  intel_mid: Renamed *mrst* to *intel_mid*
  intel_mid: Refactored sfi_parse_devs() function
  intel_mid: Added custom device_handler support
  intel_mid: Added custom handler for ipc devices
  intel_mid: Moved board related code to a new file
  intel_mid: Moved SFI related code to intel_mid_sfi.c
  x86: mrst: move to generic SFI GPIO API

 Documentation/kernel-parameters.txt|6 +-
 arch/x86/include/asm/{mrst.h => intel-mid.h}   |   62 +-
 .../include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}  |4 +-
 arch/x86/include/asm/setup.h   |4 +-
 arch/x86/include/uapi/asm/bootparam.h  |2 +-
 arch/x86/kernel/apb_timer.c|   10 +-
 arch/x86/kernel/early_printk.c |2 +-
 arch/x86/kernel/head32.c   |4 +-
 arch/x86/kernel/rtc.c  |4 +-
 arch/x86/pci/Makefile  |2 +-
 arch/x86/pci/{mrst.c => intel_mid_pci.c}   |   22 +-
 arch/x86/platform/Makefile |2 +-
 arch/x86/platform/intel-mid/Makefile   |9 +
 arch/x86/platform/intel-mid/board.c|  109 ++
 arch/x86/platform/intel-mid/device_libs/Makefile   |   21 +
 .../intel-mid/device_libs/platform_emc1403.c   |   33 +
 .../intel-mid/device_libs/platform_emc1403.h   |   16 +
 .../intel-mid/device_libs/platform_gpio_keys.c |   82 ++
 .../intel-mid/device_libs/platform_gpio_keys.h |   16 +
 .../platform/intel-mid/device_libs/platform_ipc.c  |   59 ++
 .../platform/intel-mid/device_libs/platform_ipc.h  |   17 +
 .../intel-mid/device_libs/platform_lis331.c|   32 +
 .../intel-mid/device_libs/platform_lis331.h|   16 +
 .../intel-mid/device_libs/platform_max3111.c   |   28 +
 .../intel-mid/device_libs/platform_max3111.h   |   16 +
 .../intel-mid/device_libs/platform_max7315.c   |   62 ++
 .../intel-mid/device_libs/platform_max7315.h   |   19 +
 .../intel-mid/device_libs/platform_mpu3050.c   |   28 +
 .../intel-mid/device_libs/platform_mpu3050.h   |   16 +
 .../platform/intel-mid/device_libs/platform_msic.c |   87 ++
 .../platform/intel-mid/device_libs/platform_msic.h |   19 +
 .../intel-mid/device_libs/platform_msic_audio.c|   36 +
 .../intel-mid/device_libs/platform_msic_audio.h|   16 +
 .../intel-mid/device_libs/platform_msic_battery.c  |   26 +
 .../intel-mid/device_libs/platform_msic_battery.h  |   17 +
 .../intel-mid/device_libs/platform_msic_gpio.c |   37 +
 .../intel-mid/device_libs/platform_msic_gpio.h |   16 +
 .../intel-mid/device_libs/platform_msic_ocd.c  |   39 +
 .../intel-mid/device_libs/platform_msic_ocd.h  |   16 +
 .../device_libs/platform_msic_power_btn.c  |   25 +
 .../device_libs/platform_msic_power_btn.h  |   17 +
 .../intel-mid/device_libs/platform_msic_thermal.c  |   26 +
 .../intel-mid/device_libs/platform_msic_thermal.h  |   17 +
 .../intel-mid/device_libs/platform_pmic_gpio.c |   36 +
 .../intel-mid/device_libs/platform_pmic_gpio.h |   16 +
 .../intel-mid/device_libs/platform_tc35876x.c  |   29 +
 .../intel-mid/device_libs/platform_tc35876x.h  |   16 +
 .../intel-mid/device_libs/platform_tca6416.c   |   45 +
 .../intel-mid/device_libs/platform_tca6416.h   |   20 +
 .../early_printk_intel_mid.c}  |   11 +-
 arch/x86/platform/intel-mid/intel-mid.c|  213 
 arch/x86/platform/intel-mid/intel_mid_sfi.c|  434 
 .../{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c}|   21 +-
 arch/x86/platform/intel-mid/intel_mid_weak_decls.h |   15 +
 arch/x86/platform/mrst/Makefile|3 -
 arch/x86/platform/mrst/mrst.c  | 1052 
 drivers/gpio/Kconfig   |4 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpiolib-sfi.c |   76 ++
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |2 +-
 drivers/gpu/drm/gma500/oaktrail_device.c   |2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |2 +-
 drivers/platform/x86/intel_scu_ipc.c   |4 +-
 drivers/rtc/rtc-mrst.c |4 +-
 drivers/sfi/sfi_core.c |   11 +-

[PATCH v1 08/13] intel_mid: Added custom handler for ipc devices

Added a custom handler for medfield based ipc devices and
moved devs_id structure defintion to header file.

Change-Id: Ib34d12e0f70da9b0890972d286072369bebf349d
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/include/asm/intel-mid.h|   15 ++
 arch/x86/platform/intel-mid/intel-mid.c |   87 ---
 2 files changed, 71 insertions(+), 31 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index beb7a5f..ad236ae 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -19,6 +19,21 @@ extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
 /*
+ * Here defines the array of devices platform data that IAFW would export
+ * through SFI "DEVS" table, we use name and type to match the device and
+ * its platform data.
+ */
+struct devs_id {
+   char name[SFI_NAME_LEN + 1];
+   u8 type;
+   u8 delay;
+   void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
+};
+
+/*
  * Medfield is the follow-up of Moorestown, it combines two chip solution into
  * one. Other than that it also added always-on and constant tsc and lapic
  * timers. Medfield is the platform name, and the chip name is called Penwell
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index f3abd75..1018ee8 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -78,6 +78,8 @@ int sfi_mtimer_num;
 struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
 EXPORT_SYMBOL_GPL(sfi_mrtc_array);
 int sfi_mrtc_num;
+static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 
 static void intel_mid_power_off(void)
 {
@@ -386,21 +388,6 @@ static int get_gpio_by_name(const char *name)
return -1;
 }
 
-/*
- * Here defines the array of devices platform data that IAFW would export
- * through SFI "DEVS" table, we use name and type to match the device and
- * its platform data.
- */
-struct devs_id {
-   char name[SFI_NAME_LEN + 1];
-   u8 type;
-   u8 delay;
-   void *(*get_platform_data)(void *info);
-   /* Custom handler for devices */
-   void (*device_handler)(struct sfi_device_table_entry *pentry,
-   struct devs_id *dev);
-};
-
 /* the offset for the mapping of global gpio pin to irq */
 #define INTEL_MID_IRQ_OFFSET 0x100
 
@@ -695,27 +682,32 @@ static void *tc35876x_platform_data(void *data)
 static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data,
+   _device_handler},
{"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
{"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data,
+   _device_handler},
{"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
{"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data,
-   NULL},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+   _device_handler},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data,
+   _device_handler},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data,
+   _device_handler},
{"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data,
-   NULL},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+   _device_handler},
+   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data,
+   _device_handler},
{"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data,
-   NULL},
+   _device_handler},
{},
 };
 
@@ -846,13 +838,6 @@ static void

[PATCH v1 03/13] mrst: Fixed checkpatch warnings

Fixed checkpatch warnings in mrst related files.

Change-Id: I4aa558a1b1c261444ae6b63b0da6273923d0afaa
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/pci/mrst.c   |2 +-
 arch/x86/platform/mrst/mrst.c |2 +-
 arch/x86/platform/mrst/vrtc.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/pci/mrst.c b/arch/x86/pci/mrst.c
index 66a672e..d5d222e 100644
--- a/arch/x86/pci/mrst.c
+++ b/arch/x86/pci/mrst.c
@@ -43,7 +43,7 @@
 #define PCI_FIXED_BAR_4_SIZE   0x14
 #define PCI_FIXED_BAR_5_SIZE   0x1c
 
-static int pci_soc_mode = 0;
+static int pci_soc_mode;
 
 /**
  * fixed_bar_cap - return the offset of the fixed BAR cap if found
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 58cdfd1..4784c33 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -977,7 +977,7 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
case SFI_DEV_TYPE_UART:
case SFI_DEV_TYPE_HSI:
default:
-   ;
+   break;
}
}
return 0;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index d735deb..05191dc 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -109,7 +109,7 @@ int vrtc_set_mmss(unsigned long nowtime)
spin_unlock_irqrestore(_lock, flags);
} else {
pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
-   __FUNCTION__, nowtime);
+   __func__, nowtime);
retval = -EINVAL;
}
return retval;
-- 
1.7.9.5

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

[PATCH v1 05/13] intel_mid: Renamed mrst to intel_mid

mrst is used as common name to represent all intel_mid type
soc's. But moorsetwon is just one of the intel_mid soc. So
renamed them to use intel_mid.

This patch mainly renames the variables and related
functions that uses *mrst* prefix with *intel_mid*.

To ensure that there are no functional changes, I have compared
the objdump of related files before and after rename and found
the only difference is symbol and name changes.

Change-Id: I86729b45c653def052d8275edd50cdae76edb18d
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 Documentation/kernel-parameters.txt|6 +-
 arch/x86/include/asm/intel-mid.h   |   26 ++---
 arch/x86/include/asm/setup.h   |4 +-
 arch/x86/include/uapi/asm/bootparam.h  |2 +-
 arch/x86/kernel/apb_timer.c|8 +-
 arch/x86/kernel/head32.c   |4 +-
 arch/x86/kernel/rtc.c  |2 +-
 arch/x86/pci/intel_mid_pci.c   |   12 +--
 .../platform/intel-mid/early_printk_intel_mid.c|2 +-
 arch/x86/platform/intel-mid/intel-mid.c|  109 ++--
 arch/x86/platform/intel-mid/intel_mid_vrtc.c   |8 +-
 drivers/platform/x86/intel_scu_ipc.c   |2 +-
 drivers/watchdog/intel_scu_watchdog.c  |2 +-
 13 files changed, 93 insertions(+), 94 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 6e3b18a..667408b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3345,11 +3345,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
 
-   x86_mrst_timer= [X86-32,APBT]
-   Choose timer option for x86 Moorestown MID platform.
+   x86_intel_mid_timer= [X86-32,APBT]
+   Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
-   x86_mrst_timer=apbt_only | lapic_and_apbt
+   x86_intel_mid_timer=apbt_only | lapic_and_apbt
 
xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks.
xd_geo= See header of drivers/block/xd.c.
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index cc79a4f..beb7a5f 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -13,7 +13,7 @@
 
 #include 
 
-extern int pci_mrst_init(void);
+extern int intel_mid_pci_init(void);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
@@ -25,33 +25,33 @@ extern struct sfi_rtc_table_entry sfi_mrtc_array[];
  * we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
  * identified via MSRs.
  */
-enum mrst_cpu_type {
+enum intel_mid_cpu_type {
/* 1 was Moorestown */
-   MRST_CPU_CHIP_PENWELL = 2,
+   INTEL_MID_CPU_CHIP_PENWELL = 2,
 };
 
-extern enum mrst_cpu_type __mrst_cpu_chip;
+extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
 
 #ifdef CONFIG_X86_INTEL_MID
 
-static inline enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
 {
-   return __mrst_cpu_chip;
+   return __intel_mid_cpu_chip;
 }
 
 #else /* !CONFIG_X86_INTEL_MID */
 
-#define mrst_identify_cpu()(0)
+#define intel_mid_identify_cpu()(0)
 
 #endif /* !CONFIG_X86_INTEL_MID */
 
-enum mrst_timer_options {
-   MRST_TIMER_DEFAULT,
-   MRST_TIMER_APBT_ONLY,
-   MRST_TIMER_LAPIC_APBT,
+enum intel_mid_timer_options {
+   INTEL_MID_TIMER_DEFAULT,
+   INTEL_MID_TIMER_APBT_ONLY,
+   INTEL_MID_TIMER_LAPIC_APBT,
 };
 
-extern enum mrst_timer_options mrst_timer_options;
+extern enum intel_mid_timer_options intel_mid_timer_options;
 
 /*
  * Penwell uses spread spectrum clock, so the freq number is not exactly
@@ -76,6 +76,6 @@ extern void intel_scu_devices_destroy(void);
 #define MRST_VRTC_MAP_SZ   (1024)
 /*#define MRST_VRTC_PGOFFSET   (0xc00) */
 
-extern void mrst_rtc_init(void);
+extern void intel_mid_rtc_init(void);
 
 #endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index b7bf350..cafa665 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -49,9 +49,9 @@ extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_INTEL_MID
-extern void x86_mrst_early_setup(void);
+extern void x86_intel_mid_early_setup(void);
 #else
-static inline void x86_mrst_early_setup(void) { }
+static inline void x86_intel_mid_early_setup(void) { }
 #endif
 
 #ifdef CONFIG_X86_INTEL_CE
diff --git

[PATCH v1 04/13] intel_mid: Renamed mrst to intel_mid

Following files contains code that is common to all intel mid
soc's. So renamed them as below.

mrst/mrst.c  -> intel-mid/intel-mid.c
mrst/vrtc.c  -> intel-mid/intel_mid_vrtc.c
mrst/early_printk_mrst.c -> intel-mid/intel_mid_vrtc.c
pci/mrst.c   -> pci/intel_mid_pci.c

Also, renamed the corresponding header files and made changes
to the driver files that included these header files.

To ensure that there are no functional changes, I have compared
the objdump of renamed files before and after rename and found
that the only difference is file name change.

Change-Id: I33f23d7d662eda6e33ecead26fb3fe453ab66345
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/include/asm/{mrst.h => intel-mid.h}   |8 
 .../include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}  |4 ++--
 arch/x86/kernel/apb_timer.c|2 +-
 arch/x86/kernel/early_printk.c |2 +-
 arch/x86/kernel/rtc.c  |2 +-
 arch/x86/pci/Makefile  |2 +-
 arch/x86/pci/{mrst.c => intel_mid_pci.c}   |2 +-
 arch/x86/platform/Makefile |2 +-
 arch/x86/platform/intel-mid/Makefile   |3 +++
 .../early_printk_intel_mid.c}  |4 ++--
 .../{mrst/mrst.c => intel-mid/intel-mid.c} |   11 ++-
 .../{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c}|6 +++---
 arch/x86/platform/mrst/Makefile|3 ---
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |2 +-
 drivers/gpu/drm/gma500/oaktrail_device.c   |2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |2 +-
 drivers/platform/x86/intel_scu_ipc.c   |2 +-
 drivers/rtc/rtc-mrst.c |4 ++--
 drivers/watchdog/intel_scu_watchdog.c  |2 +-
 19 files changed, 33 insertions(+), 32 deletions(-)
 rename arch/x86/include/asm/{mrst.h => intel-mid.h} (93%)
 rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
 rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (99%)
 create mode 100644 arch/x86/platform/intel-mid/Makefile
 rename arch/x86/platform/{mrst/early_printk_mrst.c => 
intel-mid/early_printk_intel_mid.c} (98%)
 rename arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c} (99%)
 rename arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} (96%)
 delete mode 100644 arch/x86/platform/mrst/Makefile

diff --git a/arch/x86/include/asm/mrst.h b/arch/x86/include/asm/intel-mid.h
similarity index 93%
rename from arch/x86/include/asm/mrst.h
rename to arch/x86/include/asm/intel-mid.h
index fc18bf3..cc79a4f 100644
--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -1,5 +1,5 @@
 /*
- * mrst.h: Intel Moorestown platform specific setup code
+ * intel-mid.h: Intel MID specific setup code
  *
  * (C) Copyright 2009 Intel Corporation
  *
@@ -8,8 +8,8 @@
  * as published by the Free Software Foundation; version 2
  * of the License.
  */
-#ifndef _ASM_X86_MRST_H
-#define _ASM_X86_MRST_H
+#ifndef _ASM_X86_INTEL_MID_H
+#define _ASM_X86_INTEL_MID_H
 
 #include 
 
@@ -78,4 +78,4 @@ extern void intel_scu_devices_destroy(void);
 
 extern void mrst_rtc_init(void);
 
-#endif /* _ASM_X86_MRST_H */
+#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/mrst-vrtc.h 
b/arch/x86/include/asm/intel_mid_vrtc.h
similarity index 81%
rename from arch/x86/include/asm/mrst-vrtc.h
rename to arch/x86/include/asm/intel_mid_vrtc.h
index 73668ab..11ababf 100644
--- a/arch/x86/include/asm/mrst-vrtc.h
+++ b/arch/x86/include/asm/intel_mid_vrtc.h
@@ -1,5 +1,5 @@
-#ifndef _MRST_VRTC_H
-#define _MRST_VRTC_H
+#ifndef _INTEL_MID_VRTC_H
+#define _INTEL_MID_VRTC_H
 
 extern unsigned char vrtc_cmos_read(unsigned char reg);
 extern void vrtc_cmos_write(unsigned char val, unsigned char reg);
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index c9876ef..9154836 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -40,7 +40,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #define APBT_CLOCKEVENT_RATING 110
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index d15f575..38ca398 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 198eb20..7a9ed8f 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index ee0af58..e063eed 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_X86_VISWS)   += visws.o
 obj-$(CONFIG_X86_NUMAQ)+= numaq_32.o

[PATCH v1 10/13] intel_mid: Moved SFI related code to intel_mid_sfi.c

Moved SFI specific parsing/handling code to intel_mid_sfi.c. This will enable
us to reuse our intel-mid code for platforms that supports firmware interfaces
other than SFI (like ACPI).

Change-Id: I95f6c233914c949fda8a7d14715a7e954fe7512e
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/include/asm/intel-mid.h|1 +
 arch/x86/platform/intel-mid/Makefile|5 +-
 arch/x86/platform/intel-mid/intel-mid.c |  450 -
 arch/x86/platform/intel-mid/intel_mid_sfi.c |  485 +++
 4 files changed, 489 insertions(+), 452 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/intel_mid_sfi.c

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index afc282a..358e0d2 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -18,6 +18,7 @@ extern int intel_mid_pci_init(void);
 extern int get_gpio_by_name(const char *name);
 extern void intel_scu_device_register(struct platform_device *pdev);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
+extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile
index 36323ee..9a6b6c3 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,8 +1,9 @@
 obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
 obj-$(CONFIG_X86_INTEL_MID)+= intel_mid_vrtc.o
 obj-$(CONFIG_EARLY_PRINTK_INTEL_MID)   += early_printk_intel_mid.o
-
+# SFI specific code
+obj-$(CONFIG_SFI) += intel_mid_sfi.o
 # BOARD files
 obj-$(CONFIG_X86_INTEL_MID) += board.o
 # platform configuration for board devices
-obj-y += device_libs/
\ No newline at end of file
+obj-y += device_libs/
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index e770028..7a98e9d 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -18,19 +18,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
@@ -69,17 +59,9 @@
 
 __cpuinitdata enum intel_mid_timer_options intel_mid_timer_options;
 
-static u32 sfi_mtimer_usage[SFI_MTMR_MAX_NUM];
-static struct sfi_timer_table_entry sfi_mtimer_array[SFI_MTMR_MAX_NUM];
 enum intel_mid_cpu_type __intel_mid_cpu_chip;
 EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
-int sfi_mtimer_num;
-
-struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
-EXPORT_SYMBOL_GPL(sfi_mrtc_array);
-int sfi_mrtc_num;
-
 static void intel_mid_power_off(void)
 {
 }
@@ -89,114 +71,6 @@ static void intel_mid_reboot(void)
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
 }
 
-/* parse all the mtimer info to a static mtimer array */
-static int __init sfi_parse_mtmr(struct sfi_table_header *table)
-{
-   struct sfi_table_simple *sb;
-   struct sfi_timer_table_entry *pentry;
-   struct mpc_intsrc mp_irq;
-   int totallen;
-
-   sb = (struct sfi_table_simple *)table;
-   if (!sfi_mtimer_num) {
-   sfi_mtimer_num = SFI_GET_NUM_ENTRIES(sb,
-   struct sfi_timer_table_entry);
-   pentry = (struct sfi_timer_table_entry *) sb->pentry;
-   totallen = sfi_mtimer_num * sizeof(*pentry);
-   memcpy(sfi_mtimer_array, pentry, totallen);
-   }
-
-   pr_debug("SFI MTIMER info (num = %d):\n", sfi_mtimer_num);
-   pentry = sfi_mtimer_array;
-   for (totallen = 0; totallen < sfi_mtimer_num; totallen++, pentry++) {
-   pr_debug("timer[%d]: paddr = 0x%08x, freq = %dHz,"
-   " irq = %d\n", totallen, (u32)pentry->phys_addr,
-   pentry->freq_hz, pentry->irq);
-   if (!pentry->irq)
-   continue;
-   mp_irq.type = MP_INTSRC;
-   mp_irq.irqtype = mp_INT;
-/* triggering mode edge bit 2-3, active high polarity bit 0-1 */
-   mp_irq.irqflag = 5;
-   mp_irq.srcbus = MP_BUS_ISA;
-   mp_irq.srcbusirq = pentry->irq; /* IRQ */
-   mp_irq.dstapic = MP_APIC_ALL;
-   mp_irq.dstirq = pentry->irq;
-   mp_save_irq(_irq);
-   }
-
-   return 0;
-}
-
-struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
-{
-   int i;
-   if (hint < sfi_mtimer_num) {
-   if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",
-   hint, sfi_mtimer_array[hint].irq);
-   sfi_mtimer_usage[hint] = 1;
-   return _mtimer_array[hint];
-   }
-   }
-   /* take

Re: Stupid VFS name lookup interface..

2013-05-29 Thread Linus Torvalds

On Thu, May 30, 2013 at 10:28 AM, Eric Paris  wrote:
>
> How do I tell what is taking time inside selinux_inode_permission?

Go to "annotate" (just press 'a' when the function is highlighted),
which will show you the disassembly and the cost of each instruction.

That's when you really want to use "-e cycles:pp" to get the
instruction-level profile right, though. Otherwise the cost will
usually be assigned to the instructions following the expensive one.

And I can tell you that the cost is almost certainly the cache miss on
the inode->i_security accesses. Which was the reason for that second
patch that moved "sid" to the inode->i_sid field and avoided the extra
dereference.

 Linus
--
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 v1 12/13] gpiolib: append SFI helpers for GPIO API

From: Andy Shevchenko 

To support some (legacy) firmwares and platforms let's make life easier for
their customers.

Change-Id: I39a0e3e0ed4e04a0d733801f59d46d76189195e8
Signed-off-by: Andy Shevchenko 
---
 drivers/gpio/Kconfig   |4 +++
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpiolib-sfi.c |   76 
 drivers/sfi/sfi_core.c |7 
 include/linux/sfi_gpio.h   |   27 
 5 files changed, 115 insertions(+)
 create mode 100644 drivers/gpio/gpiolib-sfi.c
 create mode 100644 include/linux/sfi_gpio.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 573c449..8e4b0b8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -51,6 +51,10 @@ config OF_GPIO
def_bool y
depends on OF
 
+config GPIO_SFI
+   def_bool y
+   depends on SFI
+
 config GPIO_ACPI
def_bool y
depends on ACPI
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0cb2d65..63d2abd 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
 obj-$(CONFIG_GPIO_DEVRES)  += devres.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib.o
 obj-$(CONFIG_OF_GPIO)  += gpiolib-of.o
+obj-$(CONFIG_GPIO_SFI) += gpiolib-sfi.o
 obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-sfi.c b/drivers/gpio/gpiolib-sfi.c
new file mode 100644
index 000..2f15a81
--- /dev/null
+++ b/drivers/gpio/gpiolib-sfi.c
@@ -0,0 +1,76 @@
+/*
+ * SFI helpers for GPIO API
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Andy Shevchenko 
+ *
+ * Based on work done for Intel MID platforms (mrst.c)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "SFI: GPIO: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct sfi_gpio_table_entry *sfi_gpio_table;
+static int sfi_gpio_num_entry;
+
+int sfi_get_gpio_by_name(const char *name)
+{
+   struct sfi_gpio_table_entry *pentry = sfi_gpio_table;
+   int i;
+
+   if (!pentry)
+   return -1;
+
+   for (i = 0; i < sfi_gpio_num_entry; i++, pentry++) {
+   if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN))
+   return pentry->pin_no;
+   }
+
+   return -1;
+}
+EXPORT_SYMBOL_GPL(sfi_get_gpio_by_name);
+
+static int __init sfi_gpio_parse(struct sfi_table_header *table)
+{
+   struct sfi_table_simple *sb = (struct sfi_table_simple *)table;
+   struct sfi_gpio_table_entry *pentry;
+   int num, i;
+
+   if (sfi_gpio_table)
+   return 0;
+
+   num = SFI_GET_NUM_ENTRIES(sb, struct sfi_gpio_table_entry);
+   pentry = (struct sfi_gpio_table_entry *)sb->pentry;
+
+   sfi_gpio_table = kmalloc(num * sizeof(*pentry), GFP_KERNEL);
+   if (!sfi_gpio_table)
+   return -ENOMEM;
+
+   memcpy(sfi_gpio_table, pentry, num * sizeof(*pentry));
+   sfi_gpio_num_entry = num;
+
+   pr_debug("Pin info:\n");
+   for (i = 0; i < num; i++, pentry++)
+   pr_debug("[%2d] chip = %16.16s, name = %16.16s, pin=%d\n", i,
+pentry->controller_name, pentry->pin_name,
+pentry->pin_no);
+
+   return 0;
+}
+
+int __init sfi_gpio_init(void)
+{
+   return sfi_table_parse(SFI_SIG_GPIO, NULL, NULL, sfi_gpio_parse);
+}
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a..2828da0 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -67,6 +67,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sfi_core.h"
@@ -512,6 +513,12 @@ void __init sfi_init_late(void)
syst_va = sfi_map_memory(syst_pa, length);
 
sfi_acpi_init();
+
+   /*
+* Parsing GPIO table first, since the DEVS table will need this table
+* to map the pin name to the actual pin.
+*/
+   sfi_gpio_init();
 }
 
 /*
diff --git a/include/linux/sfi_gpio.h b/include/linux/sfi_gpio.h
new file mode 100644
index 000..ef7e497
--- /dev/null
+++ b/include/linux/sfi_gpio.h
@@ -0,0 +1,27 @@
+#ifndef _LINUX_SFI_GPIO_H_
+#define _LINUX_SFI_GPIO_H_
+
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_GPIO_SFI
+
+int sfi_get_gpio_by_name(const char *name);
+int __init sfi_gpio_init(void);
+
+#else /* CONFIG_GPIO_SFI */
+
+static inline int sfi_get_gpio_by_name(const char *name);
+{
+   return -1;
+}
+
+static inline int __init sfi_gpio_init(void)
+{
+   return -ENODEV;
+}
+
+#endif /* CONFIG_GPIO_SFI */
+
+#endif /* _LINUX_SFI_GPIO_H_ */
-- 
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

[PATCH v1 06/13] intel_mid: Refactored sfi_parse_devs() function

SFI device_id[] table parsing code is duplicated in every SFI
device handler. This patch removes this code duplication, by
adding a seperate function get_device_id() to parse through the
device table. Also this patch moves the SPI, I2C, IPC info code from
sfi_parse_devs() to respective device handlers.

Change-Id: I995bcf6ab872272d4a08a900231ddc5f3110c8a6
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/platform/intel-mid/intel-mid.c |  141 ---
 1 file changed, 71 insertions(+), 70 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 38071c1..ef94c7d 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -831,20 +831,15 @@ static void __init install_irq_resource(struct 
platform_device *pdev, int irq)
platform_device_add_resources(pdev, , 1);
 }
 
-static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *entry)
+static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
struct platform_device *pdev;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_IPC &&
-   !strncmp(dev->name, entry->name, SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(entry);
-   break;
-   }
-   dev++;
-   }
+   pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
+   pentry->name, pentry->irq);
+   pdata = dev->get_platform_data(pentry);
 
/*
 * On Medfield the platform device creation is handled by the MSIC
@@ -853,68 +848,94 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *entry)
if (intel_mid_has_msic())
return;
 
-   pdev = platform_device_alloc(entry->name, 0);
+   pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
pr_err("out of memory for SFI platform device '%s'.\n",
-   entry->name);
+   pentry->name);
return;
}
-   install_irq_resource(pdev, entry->irq);
+   install_irq_resource(pdev, pentry->irq);
 
pdev->dev.platform_data = pdata;
intel_scu_device_register(pdev);
 }
 
-static void __init sfi_handle_spi_dev(struct spi_board_info *spi_info)
+static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct spi_board_info spi_info;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias,
-   SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(spi_info);
-   break;
-   }
-   dev++;
-   }
-   spi_info->platform_data = pdata;
+   memset(_info, 0, sizeof(spi_info));
+   strncpy(spi_info.modalias, pentry->name, SFI_NAME_LEN);
+   spi_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   spi_info.bus_num = pentry->host_num;
+   spi_info.chip_select = pentry->addr;
+   spi_info.max_speed_hz = pentry->max_freq;
+   pr_debug("SPI bus=%d, name=%16.16s, irq=0x%2x, max_freq=%d, cs=%d\n",
+   spi_info.bus_num,
+   spi_info.modalias,
+   spi_info.irq,
+   spi_info.max_speed_hz,
+   spi_info.chip_select);
+
+   pdata = dev->get_platform_data(_info);
+
+   spi_info.platform_data = pdata;
if (dev->delay)
-   intel_scu_spi_device_register(spi_info);
+   intel_scu_spi_device_register(_info);
else
-   spi_register_board_info(spi_info, 1);
+   spi_register_board_info(_info, 1);
 }
 
-static void __init sfi_handle_i2c_dev(int bus, struct i2c_board_info *i2c_info)
+static void __init sfi_handle_i2c_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct i2c_board_info i2c_info;
void *pdata = NULL;
 
+   memset(_info, 0, sizeof(i2c_info));
+   strncpy(i2c_info.type, pentry->name, SFI_NAME_LEN);
+   i2c_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   i2c_info.addr = pentry->addr;
+   pr_debug("I2C bus = %d, name = %16.16s, irq = 0x%2x, addr = 0x%x\n",
+   pentry->host_num,
+   i2c_info.type,
+   i2c_info.irq,
+   i2c_info.addr);
+   pdata = dev->get_platform_data(_info);
+   i2c_info.platform_data = pdata;
+
+   if (dev->delay)
+

[PATCH v1 13/13] x86: mrst: move to generic SFI GPIO API

Let's use the common SFI helpers for GPIO API.

Change-Id: I7aba6e61af7df3e34ffc4dfe161ab6ea2d723691
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/include/asm/intel-mid.h   |2 +-
 .../intel-mid/device_libs/platform_emc1403.c   |4 +-
 .../intel-mid/device_libs/platform_gpio_keys.c |2 +-
 .../intel-mid/device_libs/platform_lis331.c|4 +-
 .../intel-mid/device_libs/platform_max3111.c   |2 +-
 .../intel-mid/device_libs/platform_max7315.c   |4 +-
 .../intel-mid/device_libs/platform_mpu3050.c   |2 +-
 .../intel-mid/device_libs/platform_msic_gpio.c |2 +-
 .../intel-mid/device_libs/platform_msic_ocd.c  |2 +-
 .../intel-mid/device_libs/platform_pmic_gpio.c |2 +-
 .../intel-mid/device_libs/platform_tc35876x.c  |6 +--
 .../intel-mid/device_libs/platform_tca6416.c   |4 +-
 arch/x86/platform/intel-mid/intel_mid_sfi.c|   51 
 13 files changed, 18 insertions(+), 69 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 358e0d2..e66555d 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -12,10 +12,10 @@
 #define _ASM_X86_INTEL_MID_H
 
 #include 
+#include 
 #include 
 
 extern int intel_mid_pci_init(void);
-extern int get_gpio_by_name(const char *name);
 extern void intel_scu_device_register(struct platform_device *pdev);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c 
b/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
index 301e414..14812625 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
@@ -20,8 +20,8 @@ void __init *emc1403_platform_data(void *info)
 {
static short intr2nd_pdata;
struct i2c_board_info *i2c_info = info;
-   int intr = get_gpio_by_name("thermal_int");
-   int intr2nd = get_gpio_by_name("thermal_alert");
+   int intr = sfi_get_gpio_by_name("thermal_int");
+   int intr2nd = sfi_get_gpio_by_name("thermal_alert");
 
if (intr == -1 || intr2nd == -1)
return NULL;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c 
b/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
index 4cae400..859829c 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
@@ -62,7 +62,7 @@ static int __init pb_keys_init(void)
 
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
-   gb[i].gpio = get_gpio_by_name(gb[i].desc);
+   gb[i].gpio = sfi_get_gpio_by_name(gb[i].desc);
pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
gb[i].gpio);
if (gb[i].gpio == -1)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_lis331.c 
b/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
index db96e30..770fdd4 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
@@ -19,8 +19,8 @@ void __init *lis331dl_platform_data(void *info)
 {
static short intr2nd_pdata;
struct i2c_board_info *i2c_info = info;
-   int intr = get_gpio_by_name("accel_int");
-   int intr2nd = get_gpio_by_name("accel_2");
+   int intr = sfi_get_gpio_by_name("accel_int");
+   int intr2nd = sfi_get_gpio_by_name("accel_2");
 
if (intr == -1 || intr2nd == -1)
return NULL;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_max3111.c 
b/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
index 1fdc259..7466ba7 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
@@ -18,7 +18,7 @@
 void __init *max3111_platform_data(void *info)
 {
struct spi_board_info *spi_info = info;
-   int intr = get_gpio_by_name("max3111_int");
+   int intr = sfi_get_gpio_by_name("max3111_int");
 
spi_info->mode = SPI_MODE_0;
if (intr == -1)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_max7315.c 
b/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
index 1c10cb4..30055e6 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
@@ -45,8 +45,8 @@ void __init *max7315_platform_data(void *info)
strcpy(intr_pin_name, "max7315_int");
}
 
-   gpio_base = get_gpio_by_name(base_pin_name);
-   intr = get_gpio_by_name(intr_pin_name);
+   gpio_base =

[PATCH v1 11/13] sfi: fix compiler warnings

From: Andy Shevchenko 

drivers/sfi/sfi_core.c:164:26: warning: no previous prototype for 
‘sfi_map_table’ [-Wmissing-prototypes]
drivers/sfi/sfi_core.c:192:6: warning: no previous prototype for 
‘sfi_unmap_table’ [-Wmissing-prototypes]

Change-Id: I2c2053dcd364a21c6b86016b28f2fb4961ccf43e
Signed-off-by: Andy Shevchenko 
---
 drivers/sfi/sfi_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 1e824fb..296db7a 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -161,7 +161,7 @@ static int sfi_verify_table(struct sfi_table_header *table)
  * Check for common case that we can re-use mapping to SYST,
  * which requires syst_pa, syst_va to be initialized.
  */
-struct sfi_table_header *sfi_map_table(u64 pa)
+static struct sfi_table_header *sfi_map_table(u64 pa)
 {
struct sfi_table_header *th;
u32 length;
@@ -189,7 +189,7 @@ struct sfi_table_header *sfi_map_table(u64 pa)
  * Undoes effect of sfi_map_table() by unmapping table
  * if it did not completely fit on same page as SYST.
  */
-void sfi_unmap_table(struct sfi_table_header *th)
+static void sfi_unmap_table(struct sfi_table_header *th)
 {
if (!TABLE_ON_PAGE(syst_va, th, th->len))
sfi_unmap_memory(th, TABLE_ON_PAGE(th, th, th->len) ?
-- 
1.7.9.5

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

[PATCH v1 07/13] intel_mid: Added custom device_handler support

This patch provides a means to add custom handler for
SFI devices. If you set device_handler as NULL in
device_id table standard SFI device handler will be used.
If its not NULL custom handler will be called.

Change-Id: I294371004b2c4b6bb0713fd6f5ea94ab0fc2df52
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/platform/intel-mid/intel-mid.c |   75 +--
 1 file changed, 42 insertions(+), 33 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index ef94c7d..f3abd75 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -396,6 +396,9 @@ struct devs_id {
u8 type;
u8 delay;
void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 };
 
 /* the offset for the mapping of global gpio pin to irq */
@@ -690,27 +693,29 @@ static void *tc35876x_platform_data(void *data)
 }
 
 static const struct devs_id __initconst device_ids[] = {
-   {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
-   {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data},
-   {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data},
-   {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data},
+   {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
+   {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
-   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data},
-   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data},
-   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data},
-
+   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data,
+   NULL},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data,
+   NULL},
+   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data,
+   NULL},
{},
 };
 
@@ -965,20 +970,24 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
if ((dev == NULL) || (dev->get_platform_data == NULL))
continue;
 
-   switch (pentry->type) {
-   case SFI_DEV_TYPE_IPC:
-   sfi_handle_ipc_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_SPI:
-   sfi_handle_spi_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_I2C:
-   sfi_handle_i2c_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_UART:
-   case SFI_DEV_TYPE_HSI:
-   default:
-   break;
+   if (dev->device_handler) {
+   dev->device_handler(pentry, dev);
+   } else {
+   switch (pentry->type) {
+   case SFI_DEV_TYPE_IPC:
+   sfi_handle_ipc_dev(pentry, dev);
+   break;
+   case SFI_DEV_TYPE_SPI:
+   sfi_handle_spi_dev(pentry, dev);
+   break;
+   case SFI_DEV_TYPE_I2C:
+

[PATCH v1 01/13] mrst: Fixed printk/pr_* related issues

Fixed printk and pr_* related issues in mrst related files.

Change-Id: I7dafe04f1cd6a0ee2c97672b98441ade5b2000a7
Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 arch/x86/pci/mrst.c|2 +-
 arch/x86/platform/mrst/early_printk_mrst.c |2 +-
 arch/x86/platform/mrst/mrst.c  |2 +-
 arch/x86/platform/mrst/vrtc.c  |5 ++---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/pci/mrst.c b/arch/x86/pci/mrst.c
index 6eb18c4..a08cf1b 100644
--- a/arch/x86/pci/mrst.c
+++ b/arch/x86/pci/mrst.c
@@ -235,7 +235,7 @@ struct pci_ops pci_mrst_ops = {
  */
 int __init pci_mrst_init(void)
 {
-   printk(KERN_INFO "Intel MID platform detected, using MID PCI ops\n");
+   pr_info("Intel MID platform detected, using MID PCI ops\n");
pci_mmcfg_late_init();
pcibios_enable_irq = mrst_pci_irq_enable;
pci_root_ops = pci_mrst_ops;
diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 028454f..95880f7 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -213,7 +213,7 @@ static void early_mrst_spi_putc(char c)
}
 
if (!timeout)
-   pr_warning("MRST earlycon: timed out\n");
+   pr_warn("MRST earlycon: timed out\n");
else
max3110_write_data(c);
 }
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index a0a0a43..fbfbe36 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -328,7 +328,7 @@ static inline int __init setup_x86_mrst_timer(char *arg)
else if (strcmp("lapic_and_apbt", arg) == 0)
mrst_timer_options = MRST_TIMER_LAPIC_APBT;
else {
-   pr_warning("X86 MRST timer option %s not recognised"
+   pr_warn("X86 MRST timer option %s not recognised"
   " use x86_mrst_timer=apbt_only or lapic_and_apbt\n",
   arg);
return -EINVAL;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index d62b0a3..d735deb 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -79,7 +79,7 @@ unsigned long vrtc_get_time(void)
/* vRTC YEAR reg contains the offset to 1972 */
year += 1972;
 
-   printk(KERN_INFO "vRTC: sec: %d min: %d hour: %d day: %d "
+   pr_info("vRTC: sec: %d min: %d hour: %d day: %d "
"mon: %d year: %d\n", sec, min, hour, mday, mon, year);
 
return mktime(year, mon, mday, hour, min, sec);
@@ -108,8 +108,7 @@ int vrtc_set_mmss(unsigned long nowtime)
vrtc_cmos_write(tm.tm_sec, RTC_SECONDS);
spin_unlock_irqrestore(_lock, flags);
} else {
-   printk(KERN_ERR
-  "%s: Invalid vRTC value: write of %lx to vRTC failed\n",
+   pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
__FUNCTION__, nowtime);
retval = -EINVAL;
}
-- 
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] scsi: Introduce a help function local_time_seconds() to simplify the getting time stamp operation

On 2013/5/29 17:33, Gu Zheng wrote:
>>From 4d4caa16f3886ae910ad6dfe13353fc836f546cc Mon Sep 17 00:00:00 2001
> From: Gu Zheng 
> Date: Wed, 29 May 2013 17:34:22 +0900
> Subject: [PATCH] driver/scsi: Introduce a help function local_time_seconds() 
> to simplify the getting time stamp operation
> 
hi gu,

next time, you can remove above info.


thanks,

Libo


> Signed-off-by: Gu Zheng 
> ---
>  drivers/scsi/3w-9xxx.c |   14 ++
>  drivers/scsi/3w-sas.c  |   14 ++
>  include/scsi/scsi.h|9 +
>  3 files changed, 13 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index 5e1e12c..44b3ea8 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -374,8 +374,6 @@ out:
>  /* This function will queue an event */
>  static void twa_aen_queue_event(TW_Device_Extension *tw_dev, 
> TW_Command_Apache_Header *header)
>  {
> - u32 local_time;
> - struct timeval time;
>   TW_Event *event;
>   unsigned short aen;
>   char host[16];
> @@ -398,9 +396,7 @@ static void twa_aen_queue_event(TW_Device_Extension 
> *tw_dev, TW_Command_Apache_H
>   memset(event, 0, sizeof(TW_Event));
>  
>   event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
> - do_gettimeofday();
> - local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> - event->time_stamp_sec = local_time;
> + event->time_stamp_sec = local_time_seconds();
>   event->aen_code = aen;
>   event->retrieved = TW_AEN_NOT_RETRIEVED;
>   event->sequence_id = tw_dev->error_sequence_id;
> @@ -479,11 +475,9 @@ out:
>  static void twa_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>  {
>   u32 schedulertime;
> - struct timeval utc;
>   TW_Command_Full *full_command_packet;
>   TW_Command *command_packet;
>   TW_Param_Apache *param;
> - u32 local_time;
>  
>   /* Fill out the command packet */
>   full_command_packet = tw_dev->command_packet_virt[request_id];
> @@ -503,11 +497,7 @@ static void twa_aen_sync_time(TW_Device_Extension 
> *tw_dev, int request_id)
>   param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
>   param->parameter_size_bytes = cpu_to_le16(4);
>  
> - /* Convert system time in UTC to local time seconds since last 
> -   Sunday 12:00AM */
> - do_gettimeofday();
> - local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
> - schedulertime = local_time - (3 * 86400);
> + schedulertime = local_time_seconds() - (3 * 86400);
>   schedulertime = cpu_to_le32(schedulertime % 604800);
>  
>   memcpy(param->data, , sizeof(u32));
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index c845bdb..69f1d8a 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -236,8 +236,6 @@ out:
>  /* This function will queue an event */
>  static void twl_aen_queue_event(TW_Device_Extension *tw_dev, 
> TW_Command_Apache_Header *header)
>  {
> - u32 local_time;
> - struct timeval time;
>   TW_Event *event;
>   unsigned short aen;
>   char host[16];
> @@ -256,9 +254,7 @@ static void twl_aen_queue_event(TW_Device_Extension 
> *tw_dev, TW_Command_Apache_H
>   memset(event, 0, sizeof(TW_Event));
>  
>   event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
> - do_gettimeofday();
> - local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> - event->time_stamp_sec = local_time;
> + event->time_stamp_sec = local_time_seconds();
>   event->aen_code = aen;
>   event->retrieved = TW_AEN_NOT_RETRIEVED;
>   event->sequence_id = tw_dev->error_sequence_id;
> @@ -444,11 +440,9 @@ out:
>  static void twl_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>  {
>   u32 schedulertime;
> - struct timeval utc;
>   TW_Command_Full *full_command_packet;
>   TW_Command *command_packet;
>   TW_Param_Apache *param;
> - u32 local_time;
>  
>   /* Fill out the command packet */
>   full_command_packet = tw_dev->command_packet_virt[request_id];
> @@ -468,11 +462,7 @@ static void twl_aen_sync_time(TW_Device_Extension 
> *tw_dev, int request_id)
>   param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
>   param->parameter_size_bytes = cpu_to_le16(4);
>  
> - /* Convert system time in UTC to local time seconds since last 
> -   Sunday 12:00AM */
> - do_gettimeofday();
> - local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
> - schedulertime = local_time - (3 * 86400);
> + schedulertime = local_time_seconds() - (3 * 86400);
>   schedulertime = cpu_to_le32(schedulertime % 604800);
>  
>   memcpy(param->data, , sizeof(u32));
> diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
> index 66216c1..f3377ca 100644
> --- a/include/scsi/scsi.h
> +++ b/include/scsi/scsi.h
> @@ -574,4 +574,13 @@ static inline __u32 scsi_to_u32(__u8 *ptr)
>

Re: [PATCH] usb: gadget: add Faraday fotg210_udc driver

2013-05-29 Thread Yuan-Hsin Chen

Hi,

On Thu, May 30, 2013 at 7:55 AM, Felipe Balbi  wrote:
> Hi,
>
> On Wed, May 29, 2013 at 06:31:50PM +, Yuan-Hsin Chen wrote:
>> Faraday fotg210 udc driver supports only Bulk transfer so far.
>> fotg210 could be configured as an USB2.0 peripheral.
>>
>> This driver is tested with mass storage gadget driver on Faraday
>> EVB a369.
>>
>> Signed-off-by: Yuan-Hsin Chen 
>
> Run through checkpatch.pl --strict and fix all errors, warnings and all
> checks which make sense.
>
> WARNING: please write a paragraph that describes the config symbol fully
> #81: FILE: drivers/usb/gadget/Kconfig:196:
> +config USB_FOTG210_UDC
>
> CHECK: braces {} should be used on all arms of this statement
> #183: FILE: drivers/usb/gadget/fotg210-udc.c:76:
> +   if (ep->epnum) {
> [...]
> +   } else
> [...]
>
> WARNING: line over 80 characters
> #190: FILE: drivers/usb/gadget/fotg210-udc.c:83:
> +static void fotg210_fifo_ep_mapping(struct fotg210_ep *ep, u32 epnum, u32 
> dir_in)
>
> WARNING: line over 80 characters
> #237: FILE: drivers/usb/gadget/fotg210-udc.c:130:
> +static void fotg210_set_mps(struct fotg210_ep *ep, u32 epnum, u32 mps, u32 
> dir_in)
>
> WARNING: line over 80 characters
> #241: FILE: drivers/usb/gadget/fotg210-udc.c:134:
> +   u32 offset = dir_in ? FOTG210_INEPMPSR(epnum) : 
> FOTG210_OUTEPMPSR(epnum);
>
> WARNING: line over 80 characters
> #349: FILE: drivers/usb/gadget/fotg210-udc.c:242:
> +static void fotg210_ep_free_request(struct usb_ep *_ep, struct usb_request 
> *_req)
>
> WARNING: Avoid CamelCase: 
> #372: FILE: drivers/usb/gadget/fotg210-udc.c:265:
> +   value |= DMATFNR_ACC_Fn(ep->epnum - 1);
>
> WARNING: line over 80 characters
> #418: FILE: drivers/usb/gadget/fotg210-udc.c:311:
> +   value = ioread32(ep->fotg210->reg + FOTG210_FIBCR(ep->epnum - 
> 1));
>
> WARNING: line over 80 characters
> #420: FILE: drivers/usb/gadget/fotg210-udc.c:313:
> +   iowrite32(value, ep->fotg210->reg + FOTG210_FIBCR(ep->epnum - 
> 1));
>
> WARNING: line over 80 characters
> #441: FILE: drivers/usb/gadget/fotg210-udc.c:334:
> +   length = ioread32(ep->fotg210->reg + 
> FOTG210_FIBCR(ep->epnum - 1));
>
> WARNING: Avoid CamelCase: 
> #442: FILE: drivers/usb/gadget/fotg210-udc.c:335:
> +   length &= FIBCR_BCFx;
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to printk(KERN_DEBUG ...
> #456: FILE: drivers/usb/gadget/fotg210-udc.c:349:
> +   printk(KERN_DEBUG "dma_mapping_error\n");
>
> CHECK: Alignment should match open parenthesis
> #461: FILE: drivers/usb/gadget/fotg210-udc.c:354:
> +   dma_sync_single_for_device(NULL, d, length,
> +   ep->dir_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
>
> WARNING: line over 80 characters
> #476: FILE: drivers/usb/gadget/fotg210-udc.c:369:
> +static void fotg210_ep0_queue(struct fotg210_ep *ep, struct fotg210_request 
> *req)
>
> CHECK: braces {} should be used on all arms of this statement
> #483: FILE: drivers/usb/gadget/fotg210-udc.c:376:
> +   if (req->req.length) {
> [...]
> +   } else
> [...]
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to printk(KERN_DEBUG ...
> #486: FILE: drivers/usb/gadget/fotg210-udc.c:379:
> +   printk(KERN_DEBUG "%s : req->req.length = 0x%x\n",
>
> CHECK: Alignment should match open parenthesis
> #487: FILE: drivers/usb/gadget/fotg210-udc.c:380:
> +   printk(KERN_DEBUG "%s : req->req.length = 0x%x\n",
> +   __func__, req->req.length);
>
> CHECK: braces {} should be used on all arms of this statement
> #492: FILE: drivers/usb/gadget/fotg210-udc.c:385:
> +   if (!req->req.length)
> [...]
> +   else {
> [...]
>
> WARNING: line over 80 characters
> #495: FILE: drivers/usb/gadget/fotg210-udc.c:388:
> +   u32 value = ioread32(ep->fotg210->reg + 
> FOTG210_DMISGR0);
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to printk(KERN_DEBUG ...
> #680: FILE: drivers/usb/gadget/fotg210-udc.c:573:
> +   printk(KERN_DEBUG "0x%x\n", data);
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to printk(KERN_DEBUG ...
> #691: FILE: drivers/usb/gadget/fotg210-udc.c:584:
> +   printk(KERN_DEBUG "0x%x\n", data);
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to printk(KERN_DEBUG ...
> #696: FILE: drivers/usb/gadget/fotg210-udc.c:589:
> +   printk(KERN_DEBUG "0x%x\n", data);
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to printk(KERN_DEBUG ...
> #702: FILE: drivers/usb/gadget/fotg210-udc.c:595:
> +   printk(KERN_DEBUG "0x%x\n", data);
>
> WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then 
> pr_debug(...  to

[PATCH 3.9-stable] ARM: EXYNOS: fix software reset logic for EXYNOS5440 SOC

2013-05-29 Thread Jonghwan Choi

This patch looks like it should be in the 3.9-stable tree, should we apply
it?

--

From: "Jungseok Lee "

commit 1ba830c9997214a7fbe4d91cf238793764620e3b upstream

This patch fixes software reset logic. Software reset applies only to
powered-on domains in SOC because software reset to all domains causes
reboot failure.

Signed-off-by: Jungseok Lee 
Signed-off-by: Kukjin Kim 
Signed-off-by: Jonghwan Choi 
---
 arch/arm/mach-exynos/common.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index d63d399..4d962ec 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -308,9 +308,16 @@ void exynos5_restart(char mode, const char *cmd)
val = 0x1;
addr = EXYNOS_SWRESET;
} else if (of_machine_is_compatible("samsung,exynos5440")) {
+   u32 status;
np = of_find_compatible_node(NULL, NULL,
"samsung,exynos5440-clock");
+
+   addr = of_iomap(np, 0) + 0xbc;
+   status = __raw_readl(addr);
+
addr = of_iomap(np, 0) + 0xcc;
-   val = (0xfff << 20) | (0x1 << 16);
+   val = __raw_readl(addr);
+
+   val = (val & 0x) | (status & 0x);
} else {
pr_err("%s: cannot support non-DT\n", __func__);
return;
-- 
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: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

2013-05-29 Thread joeyli

於 三，2013-05-29 於 17:46 -0500，Russ Anderson 提到：
> On Thu, May 30, 2013 at 12:22:13AM +0200, Jiri Kosina wrote:
> > On Wed, 29 May 2013, Russ Anderson wrote:
> > 
> > > > What appears to be happening is that your the EFI runtime services code
> > > > is calling into the EFI boot services code, which is definitely a bug in
> > > > your firmware because we're at runtime, but we've seen other machines
> > > > that do similar things so we usually handle it just fine. However, what
> > > > makes your case different, and the reason you see the above splat, is
> > > > that it's using the physical address of the EFI boot services region,
> > > > not the virtual one we setup with SetVirtualAddressMap(). Which is a
> > > > second firmware bug. Again, we have seen other machines that access
> > > > physical addresses after SetVirtualAddressMap(), but until now we
> > > > haven't had any non-optional code that triggered them.
> > > > 
> > > > The only reason I can see that the offending commit would introduce this
> > > > problem is because it calls QueryVariableInfo() at boot time. I notice
> > > > that your machine is an SGI UV one, is there any chance you could get a
> > > > firmware fix for this? If possible, it would be also good to confirm
> > > > that it's this chunk of code in setup_efi_vars(),
> > > > 
> > > > status = efi_call_phys4(sys_table->runtime->query_variable_info,
> > > > EFI_VARIABLE_NON_VOLATILE |
> > > > EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > > > EFI_VARIABLE_RUNTIME_ACCESS, 
> > > > _size,
> > > > _size, _size);
> > > 
> > > This does trigger the problem.  Note that the definition of
> > > QueryVariableInfo() in the UEFI spec says:
> > > 
> > >   The returned MaximumVariableStorageSize, RemainingVariableStorageSize,
> > >   MaximumVariableSize information may change immediately after the call
> > >   based on other runtime activities including asynchronous error events.
> > >   Also, these values associated with different attributes are not
> > >   additive in nature.
> > > 
> > > Note the values may be accurate at the point in time when returned,
> > > but may not be after that.
> > > 
> > >   After the system has transitioned into runtime (after
> > >   ExitBootServices() is called), an implementation may not be able to
> > >   accurately return information about the Boot Services variable store.
> > >   In such cases, EFI_INVALID_PARAMETER should be returned.
> > > 
> > > It is not clear to me exactly when ExitBootServices() is called.
> > > Our bios is returning a failing indication on the call.
> > 
> > Yes, but this call is clearly happening way before ExitBootServices() -- 
> > see the surrounding code, see for example this in efi_main():
> > 
> > [ ... snip ... ]
> > setup_efi_vars(boot_params);
> > 
> > setup_efi_pci(boot_params);
> > 
> > status = efi_call_phys3(sys_table->boottime->allocate_pool,
> > EFI_LOADER_DATA, sizeof(*gdt),
> > (void **));
> > if (status != EFI_SUCCESS) {
> > efi_printk("Failed to alloc mem for gdt structure\n");
> > goto fail;
> > }
> > [ ... snip ... ]
> 
> Yes.  Note the failing call is sys_table->runtime while all the
> other calls are sys_table->boottime and seem to work.  Not sure
> why the sys_table->runtime call has a problem but it may be
> a clue.  Could something in the runtime path not be set up???
> 

Per UEFI spec Section 6, all runtime services should a available both on
boot time and runtime. And, we query the EFI_VARIABLE_BOOTSERVICE_ACCESS
space information before ExitBootServices(), that means we call it in
boot time, so, QueryVariableInfo() should return information to us.

Back to the kernel oops, the oops happened in runtime environment when
efivar_init running. As Matt's point out as following:

於 五，2013-05-24 於 08:43 +0100，Matt Fleming 提到： 
> On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> >efi: mem127: type=4, attr=0xf, 
> > range=[0x6bb22000-0x7ca9c000) (271MB)
> 
> EFI_BOOT_SERVICES_CODE

Per UEFI 2.3.1 Section 6.2, type 4 is EfiBootServicesCode. This area available 
for
OS using after ExitBootServices():

UEFI 2.3.1 P.133
 EfiBootServicesData Memory available for general use.

So, any runtime services should not access this area, it's the first thing need 
to check
the BIOS code for why.

> >efi: mem133: type=5, attr=0x800f, 
> > range=[0x7daff000-0x7dbff000) (1MB)
> 
> EFI_RUNTIME_SERVICES_CODE
> 
> >EFI Variables Facility v0.08 2004-May-17
> >BUG: unable to handle kernel paging request at 7ca95b10
> >IP: [] 0x88007dbf213f
[...]
What appears to be happening is that your the EFI runtime services code
> is calling into the EFI boot services code, which is definitely a bug in
> your firmware because we're at runtime, but

[PATCH] arch: ia64: hp: sim: sprintf() memory overflow, need really use the default value just as it has already said.


When "strlen(s) > MAX_ROOT_LEN", it has already said to use the default
value, but in fact, it still use the input value.

If happens, next sprintf() for 'fname' in simscsi_queuecommand_lck()
may be memory overflow.


Signed-off-by: Chen Gang 
---
 arch/ia64/hp/sim/simscsi.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/hp/sim/simscsi.c b/arch/ia64/hp/sim/simscsi.c
index 331de72..3a428f1 100644
--- a/arch/ia64/hp/sim/simscsi.c
+++ b/arch/ia64/hp/sim/simscsi.c
@@ -88,8 +88,8 @@ simscsi_setup (char *s)
if (strlen(s) > MAX_ROOT_LEN) {
printk(KERN_ERR "simscsi_setup: prefix too long---using default 
%s\n",
   simscsi_root);
-   }
-   simscsi_root = s;
+   } else
+   simscsi_root = s;
return 1;
 }
 
-- 
1.7.7.6
--
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 RESEND] scsi: megaraid: check kzalloc

On 2013/5/30 9:38, Libo Chen wrote:
> On 2013/5/29 23:03, Tomas Henzl wrote:
>> On 05/24/2013 11:40 AM, Libo Chen wrote:
>>> we should check kzalloc, avoid to hit oops
>>>
>>> Signed-off-by: Libo Chen 
>>> ---
>>>  drivers/scsi/megaraid.c |4 
>>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> instead of checking scmd->device, sdev is more appropriate.
>>>
>>> diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
>>> index 846f475..6b623cb 100644
>>> --- a/drivers/scsi/megaraid.c
>>> +++ b/drivers/scsi/megaraid.c
>>> @@ -4161,6 +4161,10 @@ mega_internal_command(adapter_t *adapter, megacmd_t 
>>> *mc, mega_passthru *pthru)
>>> memset(scb, 0, sizeof(scb_t));
>>>
>>> sdev = kzalloc(sizeof(struct scsi_device), GFP_KERNEL);
>>> +   if (sdev) {
>>> +   scsi_free_command(GFP_KERNEL, scmd);
>>
>> I think, that a mutex_unlock(>int_mtx); is also needed
>> Maybe just setting a rval = -ENOMEM and a jump to to some point below?
>>
>> tomash
> 
> thanks for catching this.
> 
> when kzalloc broken, fist unlock and then return.  I will update later.
> 

I think we can put kzalloc outside of mutex_lock(>int_mtx) ?
phase:

   mutex_lock  kzalloc
   kzalloc ->  mutex_lock


> 
> Libo
> 
>>
>>> +   return -ENOMEM;
>>> +   }
>>> scmd->device = sdev;
>>>
>>> memset(adapter->int_cdb, 0, sizeof(adapter->int_cdb));
>>
>>
>> .
>>
> 


--
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 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-29 Thread Andy Walls

Mauro Carvalho Chehab  wrote:

>Em Wed, 29 May 2013 22:41:16 +0200
>Jon Arne Jørgensen  escreveu:
>
>> Change all default values in the initial setup table to match the
>table
>> in the datasheet.
>
>This is not a good idea, as it can produce undesired side effects
>on the existing drivers that depend on it, and can't be easily
>tested.
>
>Please, don't change the current "default". It is, of course, OK
>to change them if needed via the information provided inside the
>platform data.
>
>Regards,
>Mauro
>> 
>> Signed-off-by: Jon Arne Jørgensen 
>> ---
>>  drivers/media/i2c/saa7115.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/media/i2c/saa7115.c
>b/drivers/media/i2c/saa7115.c
>> index d6f589a..4403679 100644
>> --- a/drivers/media/i2c/saa7115.c
>> +++ b/drivers/media/i2c/saa7115.c
>> @@ -223,12 +223,12 @@ static const unsigned char saa7111_init[] = {
>>  static const unsigned char saa7113_init[] = {
>>  R_01_INC_DELAY, 0x08,
>>  R_02_INPUT_CNTL_1, 0xc2,
>> -R_03_INPUT_CNTL_2, 0x30,
>> +R_03_INPUT_CNTL_2, 0x33,
>>  R_04_INPUT_CNTL_3, 0x00,
>>  R_05_INPUT_CNTL_4, 0x00,
>> -R_06_H_SYNC_START, 0x89,
>> +R_06_H_SYNC_START, 0xe9,
>>  R_07_H_SYNC_STOP, 0x0d,
>> -R_08_SYNC_CNTL, 0x88,
>> +R_08_SYNC_CNTL, 0x98,
>>  R_09_LUMA_CNTL, 0x01,
>>  R_0A_LUMA_BRIGHT_CNTL, 0x80,
>>  R_0B_LUMA_CONTRAST_CNTL, 0x47,
>> @@ -236,11 +236,11 @@ static const unsigned char saa7113_init[] = {
>>  R_0D_CHROMA_HUE_CNTL, 0x00,
>>  R_0E_CHROMA_CNTL_1, 0x01,
>>  R_0F_CHROMA_GAIN_CNTL, 0x2a,
>> -R_10_CHROMA_CNTL_2, 0x08,
>> +R_10_CHROMA_CNTL_2, 0x00,
>>  R_11_MODE_DELAY_CNTL, 0x0c,
>> -R_12_RT_SIGNAL_CNTL, 0x07,
>> +R_12_RT_SIGNAL_CNTL, 0x01,
>>  R_13_RT_X_PORT_OUT_CNTL, 0x00,
>> -R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
>> +R_14_ANAL_ADC_COMPAT_CNTL, 0x00,/* RESERVED */
>>  R_15_VGATE_START_FID_CHG, 0x00,
>>  R_16_VGATE_STOP, 0x00,
>>  R_17_MISC_VGATE_CONF_AND_MSB, 0x00,
>
>
>-- 
>
>Cheers,
>Mauro
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

I was going to make a comment along the same line as Mauro.  
Please leave the driver defaults alone.  It is almost impossible to regression 
test all the different devices with a SAA7113 chip, to ensure the change 
doesn't cause someone's device to not work properly.

Regards,
Andy

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

Re: [PATCH] ACPI: Fix potential NULL pointer dereference in acpi_processor_add()

2013-05-29 Thread Hanjun Guo

On 2013-5-29 19:07, Martin Mokrejs wrote:
> Hanjun Guo wrote:
>> On 2013-5-29 7:30, Rafael J. Wysocki wrote:
>>> On Thursday, May 23, 2013 08:44:26 PM Hanjun Guo wrote:
 In acpi_processor_add(), get_cpu_device() will return NULL sometimes,
 although the chances are small, I think it should be fixed.

 Signed-off-by: Hanjun Guo 
>>>
>>> This patch isn't necessary any more after the changes queued up for 3.11
>>> in the acpi-hotplug branch of the linux-pm.git tree.
>>
>> Ok, I noticed your patch set, just drop my patch.
> 
> But shouldn't this go to stable at least? I checked linux-3.9.4
> and it applies fine. Whether this is relevant for other stable
> series I will leave up to somebody else. ;)

Hi Rafeal,

What's your opinion on Martin's suggestion?

Thanks
Hanjun

> Martin


--
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 RESEND 2/2] mtd: bcm47: convert to module_platform_driver instead of init/exit


convert to module_platform_driver instead of init/exit

Suggested-by: Andy Shevchenko 
Signed-off-by: Libo chen 
---
 drivers/mtd/devices/bcm47xxsflash.c |   20 +---
 1 files changed, 1 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/devices/bcm47xxsflash.c 
b/drivers/mtd/devices/bcm47xxsflash.c
index 2630d5c..54230cd 100644
--- a/drivers/mtd/devices/bcm47xxsflash.c
+++ b/drivers/mtd/devices/bcm47xxsflash.c
@@ -108,22 +108,4 @@ static struct platform_driver bcma_sflash_driver = {
  * Init
  **/

-static int __init bcm47xxsflash_init(void)
-{
-   int err;
-
-   err = platform_driver_register(_sflash_driver);
-   if (err)
-   pr_err("Failed to register BCMA serial flash driver: %d\n",
-  err);
-
-   return err;
-}
-
-static void __exit bcm47xxsflash_exit(void)
-{
-   platform_driver_unregister(_sflash_driver);
-}
-
-module_init(bcm47xxsflash_init);
-module_exit(bcm47xxsflash_exit);
+module_platform_driver(bcma_sflash_driver);
-- 
1.7.1


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

[PATCH RESEND 1/2] mtd: bcm47: convert kzalloc to avoid invalid access


mtd is just member of bcm47xxsflash, so we should free bcm47xxsflash not its 
member.
So I use devm_kazlloc instead of kazlloc to avoid it.

* Changelog:
   convert to devm_kzalloc

Signed-off-by: Libo chen 
Suggested-by: Andy Shevchenko 
---
 drivers/mtd/devices/bcm47xxsflash.c |   16 
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/devices/bcm47xxsflash.c 
b/drivers/mtd/devices/bcm47xxsflash.c
index 18e7761..2630d5c 100644
--- a/drivers/mtd/devices/bcm47xxsflash.c
+++ b/drivers/mtd/devices/bcm47xxsflash.c
@@ -54,11 +54,9 @@ static int bcm47xxsflash_bcma_probe(struct platform_device 
*pdev)
struct bcm47xxsflash *b47s;
int err;

-   b47s = kzalloc(sizeof(*b47s), GFP_KERNEL);
-   if (!b47s) {
-   err = -ENOMEM;
-   goto out;
-   }
+   b47s = devm_kzalloc(>dev, sizeof(*b47s), GFP_KERNEL);
+   if (!b47s)
+   return -ENOMEM;
sflash->priv = b47s;

b47s->bcma_cc = container_of(sflash, struct bcma_drv_cc, sflash);
@@ -81,15 +79,10 @@ static int bcm47xxsflash_bcma_probe(struct platform_device 
*pdev)
err = mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
if (err) {
pr_err("Failed to register MTD device: %d\n", err);
-   goto err_dev_reg;
+   return err;
}

return 0;
-
-err_dev_reg:
-   kfree(>mtd);
-out:
-   return err;
 }

 static int bcm47xxsflash_bcma_remove(struct platform_device *pdev)
@@ -98,7 +91,6 @@ static int bcm47xxsflash_bcma_remove(struct platform_device 
*pdev)
struct bcm47xxsflash *b47s = sflash->priv;

mtd_device_unregister(>mtd);
-   kfree(b47s);

return 0;
 }
-- 
1.7.1


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

Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

2013-05-29 Thread joeyli

於 四，2013-05-30 於 00:53 +0200，Jiri Kosina 提到：
> On Wed, 29 May 2013, Russ Anderson wrote:
> 
> > > Yes, but this call is clearly happening way before ExitBootServices() -- 
> > > see the surrounding code, see for example this in efi_main():
> > > 
> > > [ ... snip ... ]
> > >   setup_efi_vars(boot_params);
> > > 
> > >   setup_efi_pci(boot_params);
> > > 
> > >   status = efi_call_phys3(sys_table->boottime->allocate_pool,
> > >   EFI_LOADER_DATA, sizeof(*gdt),
> > >   (void **));
> > >   if (status != EFI_SUCCESS) {
> > >   efi_printk("Failed to alloc mem for gdt structure\n");
> > >   goto fail;
> > >   }
> > > [ ... snip ... ]
> > 
> > Yes.  Note the failing call is sys_table->runtime while all the
> > other calls are sys_table->boottime and seem to work.  Not sure
> > why the sys_table->runtime call has a problem but it may be
> > a clue.  Could something in the runtime path not be set up???
> 
> That was my original idea early today as well. My understanding of the 
> UEFI spec is admittedly limited, but afaics calling runtime method from 
> boot environment should be a valid thing to do ... ?

QueryVariableInfo() is a runtime services, all runtime services should
available bother on boot time and runtime:

UEFI spec 2.3.1 P.109:
  Runtime Services
  Functions that are available before and after any call to  
  ExitBootServices(). These functions are described in Section 7.

> 
> > > We are calling QueryVariableInfo() in setup_efi_vars(), and later on 
> > > AllocatePool is being called (through boot table).
> > 
> > On my system the QueryVariableInfo() call fails, so AllocatePool()
> > is not called in setup_efi_vars().
> 
> But it's being called later on coming back to efi_main(). That was just a 
> poor man's demonstration attempt why this code is running before 
> ExitBootServices() has been called.
> 

Yes, I agreed your point, the space information of
EFI_VARIABLE_BOOTSERVICE_ACCESS should still return by
QueryVariableInfo() because we call it before ExitBootServices():

arch/x86/boot/compressed/eboot.c
efi_main(void *handle, efi_system_table_t *_table, struct boot_params 
*boot_params)
..
sys_table = _table;
/* Check if we were booted by the EFI firmware */
if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
goto fail;
boot_params->secure_boot = get_secure_boot(sys_table)   
/* check does BIOS in secure boot mode */
setup_graphics(boot_params);
setup_efi_vars(boot_params);
/* Pass boot services variable info to runtime code, call QueryVariableInfo() */
...
status = exit_boot(boot_params, handle);
/* call ExitBootServices() */
...

Thanks a lot!
Joey Lee

--
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: System slow down from udev

2013-05-29 Thread Yinghai Lu

On Wed, May 29, 2013 at 5:20 PM, Rafael J. Wysocki  wrote:
> On Thursday, May 30, 2013 01:55:07 AM Rafael J. Wysocki wrote:
>> On Wednesday, May 29, 2013 03:49:38 PM Yinghai Lu wrote:
>> > On Wed, May 29, 2013 at 2:34 PM, Rafael J. Wysocki  wrote:
>> > > On Wednesday, May 29, 2013 01:13:46 PM Yinghai Lu wrote:
>> > >> On Wed, May 29, 2013 at 4:29 AM, Rafael J. Wysocki  wrote:
>> > >> > On your systems the processor driver is built-in.  Any chance to 
>> > >> > build it as
>> > >> > a module and see if that helps?
>> > >>
>> > >> it CONFIG_ACPI_PROCESSOR it not set in the config
>> > >> the boot get to normal speed.
>> > >
>> > > Well, if it is not set at all, there won't be problems with it. :-)
>> > >
>> > > I've tested my linux-next branch on OpenSUSE 11.3 both with the processor
>> > > driver built in and modular and I'm not able to reproduce the issue 
>> > > you're
>> > > seeing.
>> > >
>> > > Moreover, I'm not sure if user space is involved here at all, because the
>> > > problem triggers for you when all of the relevant kernel code is 
>> > > non-modular.
>> > >
>> > > With the processor driver enabled, when the slowdown happens, are the 
>> > > systems
>> > > usable enough to get some debug info out of them?
>> >
>> > please check the bootchart data.
>> >
>> > looks like it take 200s if no acpi_processor ...
>> > otherwise will take 800s or more.
>>
>> Well, something's fishy for sure.
>>
>> To my eyes it looks like we're getting lots of notifications related to the
>> processor driver and that generates a lot of workqueue load.
>>
>> Can you please get /proc/interrupts from both cases and the output of
>> "find /sys/firmware/acpi/interrupts/ -print -exec cat {} \;"?
>>
>> Also please send the output of "ls -l /sys/devices/system/cpu/cpu*" with the
>> processor driver present.
>
> Well, this is kind of a blind shot, but I'm wondering if the appended patch
> makes any difference?

No difference. it's still slow.

>
>
> ---
>  drivers/acpi/processor_driver.c |3 ---
>  1 file changed, 3 deletions(-)
>
> Index: linux-pm/drivers/acpi/processor_driver.c
> ===
> --- linux-pm.orig/drivers/acpi/processor_driver.c
> +++ linux-pm/drivers/acpi/processor_driver.c
> @@ -87,9 +87,6 @@ static void acpi_processor_notify(acpi_h
> struct acpi_processor *pr;
> int saved;
>
> -   if (device->handle != handle)
> -   return;
> -
> pr = acpi_driver_data(device);
> if (!pr)
> return;
>
--
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] pwm: add sysfs interface

2013-05-29 Thread Ryan Mallon

On 30/05/13 07:08, H Hartley Sweeten wrote:
> Add a simple sysfs interface to the PWM framework.
> 
>   /sys/class/pwm/
>   `-- pwmchipN/  for each PWM chip
>   |-- export (w/o) ask the kernel to export a PWM to userspace
>   |-- npwm   (r/o) number of PWM in pwmchipN
>   |-- pwmN/  for each exported PWM
>   |   |-- duty_ns(r/w) duty cycle (in nanoseconds)
>   |   |-- enable (r/w) enable/disable PWM
>   |   |-- period_ns  (r/w) period (in nanoseconds)
>   |   `-- polarity   (r/w) polarity of PWM
>   `-- unexport   (w/o) return a PWM to the kernel
> 
> Signed-off-by: H Hartley Sweeten 
> Cc: Thierry Reding 
> Cc: Lars Poeschel 
> ---
> This is based on previous work by Lars Poeshel.

Some comments below.

You will also fail to get this past Greg KH unless you add documentation
for the new sysfs interface to Documentation/ABI/stable/.

~Ryan

> 
>  drivers/pwm/Kconfig |   6 +
>  drivers/pwm/Makefile|   1 +
>  drivers/pwm/core.c  |  25 +++-
>  drivers/pwm/pwm-sysfs.c | 357 
> 
>  include/linux/pwm.h |  28 
>  5 files changed, 415 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/pwm/pwm-sysfs.c
> 
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 115b644..61a53b5 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -28,6 +28,12 @@ menuconfig PWM
>  
>  if PWM
>  
> +config PWM_SYSFS
> + bool "/sys/class/pwm/... (sysfs interface)"
> + depends on SYSFS
> + help
> +   Say Y here to provide a sysfs interface to control PWMs.
> +
>  config PWM_AB8500
>   tristate "AB8500 PWM support"
>   depends on AB8500_CORE && ARCH_U8500
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 94ba21e..fb92e1d 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_PWM)+= core.o
> +obj-$(CONFIG_PWM_SYSFS)  += pwm-sysfs.o
>  obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
>  obj-$(CONFIG_PWM_ATMEL_TCB)  += pwm-atmel-tcb.o
>  obj-$(CONFIG_PWM_BFIN)   += pwm-bfin.o
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 32221cb..f67465c 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -274,6 +274,8 @@ int pwmchip_add(struct pwm_chip *chip)
>   if (IS_ENABLED(CONFIG_OF))
>   of_pwmchip_add(chip);
>  
> + pwmchip_sysfs_export(chip);
> +
>  out:
>   mutex_unlock(_lock);
>   return ret;
> @@ -310,6 +312,8 @@ int pwmchip_remove(struct pwm_chip *chip)
>  
>   free_pwms(chip);
>  
> + pwmchip_sysfs_unexport(chip);
> +
>  out:
>   mutex_unlock(_lock);
>   return ret;
> @@ -402,10 +406,19 @@ EXPORT_SYMBOL_GPL(pwm_free);
>   */
>  int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
>  {
> + int err;
> +
>   if (!pwm || duty_ns < 0 || period_ns <= 0 || duty_ns > period_ns)
>   return -EINVAL;
>  
> - return pwm->chip->ops->config(pwm->chip, pwm, duty_ns, period_ns);
> + err = pwm->chip->ops->config(pwm->chip, pwm, duty_ns, period_ns);
> + if (err)
> + return err;
> +
> + pwm->duty = duty_ns;
> + pwm->period = period_ns;
> +
> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(pwm_config);
>  
> @@ -418,6 +431,8 @@ EXPORT_SYMBOL_GPL(pwm_config);
>   */
>  int pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity)
>  {
> + int err;
> +
>   if (!pwm || !pwm->chip->ops)
>   return -EINVAL;
>  
> @@ -427,7 +442,13 @@ int pwm_set_polarity(struct pwm_device *pwm, enum 
> pwm_polarity polarity)
>   if (test_bit(PWMF_ENABLED, >flags))
>   return -EBUSY;
>  
> - return pwm->chip->ops->set_polarity(pwm->chip, pwm, polarity);
> + err = pwm->chip->ops->set_polarity(pwm->chip, pwm, polarity);
> + if (err)
> + return err;
> +
> + pwm->polarity = polarity;
> +
> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(pwm_set_polarity);
>  
> diff --git a/drivers/pwm/pwm-sysfs.c b/drivers/pwm/pwm-sysfs.c
> new file mode 100644
> index 000..6a2bf76
> --- /dev/null
> +++ b/drivers/pwm/pwm-sysfs.c
> @@ -0,0 +1,357 @@
> +/*
> + * A simple sysfs interface for the generic PWM framework
> + *
> + * Copyright (C) 2013 H Hartley Sweeten 
> + *
> + * Based on previous work by Lars Poeschel 
> + *
> + * 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, 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>

Re: [PATCH v2 1/2] clk: Disable unused clocks after deferred probing is done

2013-05-29 Thread Saravana Kannan


On 05/29/2013 12:51 AM, Mike Turquette wrote:

Quoting Saravana Kannan (2013-05-15 21:34:03)

On 05/09/2013 11:35 AM, Saravana Kannan wrote:

With deferred probing, late_initcall() is too soon to declare a clock as
unused. Wait for deferred probing to finish before declaring a clock as
unused. Since deferred probing is done in late_initcall(), do the unused
check to late_initcall_sync.

Signed-off-by: Saravana Kannan 
---
   drivers/clk/clk.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index fe4055f..5ecb64c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -534,7 +534,7 @@ static int clk_disable_unused(void)

   return 0;
   }
-late_initcall(clk_disable_unused);
+late_initcall_sync(clk_disable_unused);

   /***helper functions   ***/


Mike,

Thoughts? Picking it up? Removing the existing auto-disable code (I
think they are still useful)?



Hi Saravana,

I've taken this into clk-next for testing.

Regards,
Mike



Thanks.

-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] sched:fix: Signed overflow prevention for vacancy calculation

2013-05-29 Thread Alex Shi

On 05/23/2013 04:34 PM, Lukasz Majewski wrote:
> Nasty bug with vacancy calculation has been fixed.
> In the if statement the FULL_UTIL is a large constant, max_cfs_util()
> returns unsigned and putil is also defined as unsigned. The outcome
> is that this condition is always true.
> 
> As observed, this was the reason for frequent jumps of processes between
> CPUs.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 

Thanks for the catching!
I do a little change, would you like to keep the authorship?

---

>From 4f7f2d091b7210e0be689d3e063d3cc82da1b1af Mon Sep 17 00:00:00 2001
From: Lukasz Majewski 
Date: Thu, 30 May 2013 09:21:46 +0800
Subject: [PATCH 2/2] sched:fix: Signed overflow prevention for vacancy
 calculation

Nasty bug with vacancy calculation has been fixed.
In the if statement the FULL_UTIL is a large constant, max_cfs_util()
returns unsigned and putil is also defined as unsigned. The outcome
is that this condition is always true.

As observed, this was the reason for frequent jumps of processes between
CPUs.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Signed-off-by: Alex Shi 
---
 kernel/sched/fair.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3a4917c..56a9d16 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3468,10 +3468,10 @@ find_leader_cpu(struct sched_group *group, struct 
task_struct *p, int this_cpu,
unsigned putil;
putil = div_u64(((u64)p->se.avg.runnable_avg_sum << SCHED_POWER_SHIFT),
p->se.avg.runnable_avg_period + 1);
+   vacancy = FULL_UTIL - max_cfs_util(this_cpu, wakeup) - (putil << 2);
 
/* bias toward local cpu */
-   if (cpumask_test_cpu(this_cpu, tsk_cpus_allowed(p)) &&
-   FULL_UTIL - max_cfs_util(this_cpu, wakeup) - (putil << 2) > 0)
+   if (cpumask_test_cpu(this_cpu, tsk_cpus_allowed(p)) && vacancy > 0)
return this_cpu;
 
/* Traverse only the allowed CPUs */
-- 
1.7.12


-- 
Thanks
Alex
--
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] sched: Use do_div() for 64 bit division at power utilization calculation (putil)

2013-05-29 Thread Alex Shi

On 05/23/2013 04:34 PM, Lukasz Majewski wrote:
> Now explicit casting is done when power usage variable (putil) is calculated
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> ---
> This patch was developed on top of the following Alex's repository:
> https://github.com/alexshi/power-scheduling/commits/power-scheduling
> ---
>  kernel/sched/fair.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 


Thanks for catch this issue. seems use div_u64 is better, and there are 2 same 
bugs.
so, could I rewrite the patch like following?
---

>From 9f72c25607351981898d99822f5a66e0ca67a3da Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Wed, 29 May 2013 11:09:39 +0800
Subject: [PATCH 1/2] sched: fix cast on power utilization calculation and use
 div_u64

Now explicit casting is done when power usage variable (putil) is
calculated.
div_u64 is optimized on u32.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Signed-off-by: Alex Shi 
---
 kernel/sched/fair.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 09ae48a..3a4917c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1504,8 +1504,8 @@ static inline void update_rq_runnable_avg(struct rq *rq, 
int runnable)
__update_tg_runnable_avg(>avg, >cfs);
 
period = rq->avg.runnable_avg_period ? rq->avg.runnable_avg_period : 1;
-   rq->util = (u64)(rq->avg.runnable_avg_sum << SCHED_POWER_SHIFT)
-   / period;
+   rq->util = div_u64(((u64)rq->avg.runnable_avg_sum << SCHED_POWER_SHIFT),
+   period);
 }
 
 /* Add the load generated by se into cfs_rq's child load-average */
@@ -3407,8 +3407,8 @@ static int is_sd_full(struct sched_domain *sd,
/* p maybe a new forked task */
putil = FULL_UTIL;
else
-   putil = (u64)(p->se.avg.runnable_avg_sum << SCHED_POWER_SHIFT)
-   / (p->se.avg.runnable_avg_period + 1);
+   putil = div_u64(((u64)p->se.avg.runnable_avg_sum << 
SCHED_POWER_SHIFT),
+   p->se.avg.runnable_avg_period + 1);
 
/* Try to collect the domain's utilization */
group = sd->groups;
@@ -3463,9 +3463,11 @@ find_leader_cpu(struct sched_group *group, struct 
task_struct *p, int this_cpu,
int vacancy, min_vacancy = INT_MAX;
int leader_cpu = -1;
int i;
+
/* percentage of the task's util */
-   unsigned putil = (u64)(p->se.avg.runnable_avg_sum << SCHED_POWER_SHIFT)
-   / (p->se.avg.runnable_avg_period + 1);
+   unsigned putil;
+   putil = div_u64(((u64)p->se.avg.runnable_avg_sum << SCHED_POWER_SHIFT),
+   p->se.avg.runnable_avg_period + 1);
 
/* bias toward local cpu */
if (cpumask_test_cpu(this_cpu, tsk_cpus_allowed(p)) &&
-- 
1.7.12


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

Re: [RFT][PATCH 1/1] thermal: step_wise: return instance->target by default

2013-05-29 Thread Zhang Rui

On Wed, 2013-05-29 at 18:58 -0400, Eduardo Valentin wrote:
> In case the trend is not changing or when there is no
> request for throttling, it is expected that the instance
> would not change its requested target. This patch improves
> the code implementation to cover for this expected behavior.
> 
right. agreed.

> With current implementation, the instance will always
> reset to cdev.cur_state, even in not expected cases,
> like those mentioned above.
> 
> This patch changes the step_wise governor implementation
> of get_target so that we accomplish:
> (a) - default value will be current instance->target, so
> we do not change the thermal instance target unnecessarily.

> (b) - the code now it is clear about what is the intention.
> There is a clear statement of what are the expected outcomes
> (c) - removal of hardcoded constants, now it is put in use
> the THERMAL_NO_TARGET macro.

> (d) - variable names are also improved so that reader can
> clearly understand the difference between instance cur target,
> next target and cdev cur_state.
> 
> Cc: Zhang Rui 
> Cc: Durgadoss R 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reported-by: Ruslan Ruslichenko 
> Signed-of-by: Eduardo Valentin 
> ---
>  drivers/thermal/step_wise.c | 29 ++---
>  1 file changed, 18 insertions(+), 11 deletions(-)
> ---
> 
> Hello all,
> 
> I am requesting for tests on this patch. Based on an internal
> discussion with Ruslan, I concluded that this code needs improvement.
> 
> Ruslan, I did not keep your original code because I believe the
> get_target_state needs a better implementation for code readiness.
> Besides, I also believe we are facing the bug of emul_temp in your case [1],
> so this patch is not really fixing anything, but improving the
> code quality and making sure the instance behaves as expected.
> The fact you see the cooling device stuck at 1 is most probably because
> the thermal core uses trend computed by the driver, not by emul_temp.
> 
> I have implemented a different improvement as you may find below. But
> I kept a Reported-by under your name.
> 
it would be good to let me know what the problem is.
As I'm fixing a couple of thermal bugs recently.
Most of them are suspend/hibernate related, and I've been changing this
piece of code a lot.

thanks,
rui
> In any case, because I believe this change in step_wise is significant,
> I am sending this patch for broader review and I kindly ask interested
> audience for testing it.
> 
> [1] - https://patchwork.kernel.org/patch/2632831/
> 
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index 4d4ddae..769bfa3 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -51,44 +51,51 @@ static unsigned long get_target_state(struct 
> thermal_instance *instance,
>  {
>   struct thermal_cooling_device *cdev = instance->cdev;
>   unsigned long cur_state;
> + unsigned long next_target;
>  
> + /*
> +  * We keep this instance the way it is by default.
> +  * Otherwise, we use the current state of the
> +  * cdev in use to determine the next_target.
> +  */
>   cdev->ops->get_cur_state(cdev, _state);
> + next_target = instance->target;
>  
>   switch (trend) {
>   case THERMAL_TREND_RAISING:
>   if (throttle) {
> - cur_state = cur_state < instance->upper ?
> + next_target = cur_state < instance->upper ?
>   (cur_state + 1) : instance->upper;
> - if (cur_state < instance->lower)
> - cur_state = instance->lower;
> + if (next_target < instance->lower)
> + next_target = instance->lower;
>   }
>   break;
>   case THERMAL_TREND_RAISE_FULL:
>   if (throttle)
> - cur_state = instance->upper;
> + next_target = instance->upper;
>   break;
>   case THERMAL_TREND_DROPPING:
>   if (cur_state == instance->lower) {
>   if (!throttle)
> - cur_state = -1;
> + next_target = THERMAL_NO_TARGET;
>   } else {
> - cur_state -= 1;
> - if (cur_state > instance->upper)
> - cur_state = instance->upper;
> + next_target = cur_state - 1;
> + if (next_target > instance->upper)
> + next_target = instance->upper;
>   }
>   break;
>   case THERMAL_TREND_DROP_FULL:
>   if (cur_state == instance->lower) {
>   if (!throttle)
> - cur_state = -1;
> + next_target = THERMAL_NO_TARGET;
>   } else
> - cur_state =

RE: A bug about system call on ARM

2013-05-29 Thread Wang, Yalin

Hi  Will,

Have you received the log files?

And is there someone looking at this issue now ?
This issue happened on Qcom Scorpoin CPUs,
And  it just happened in our stability test occasionally .

If you have some patch for this issue,
I can do the test for it .

Thanks for your help very much !

-Original Message-
From: Wang, Yalin 
Sent: Wednesday, May 29, 2013 5:51 PM
To: 'Will Deacon'; richard -rw- weinberger
Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org
Subject: RE: A bug about system call on ARM

Hi 

This is kernel.log  and  the stack which is recovered by Trace32 tools.
Please have a look at it .

Thanks 

-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: Wednesday, May 29, 2013 5:48 PM
To: richard -rw- weinberger
Cc: Wang, Yalin; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org
Subject: Re: A bug about system call on ARM

Hello,

On Wed, May 29, 2013 at 09:46:42AM +0100, richard -rw- weinberger wrote:
> On Wed, May 29, 2013 at 10:24 AM, Wang, Yalin  
> wrote:
> > I have download the latest linux kernel code  3.9.4 And Compare with
> > 3.4.0 kernel .
> >
> > It seems there is no change for this part , So it will still happen 
> > .
> > Does anyone know who is responsible for  arm arch part kernel code ?
> 
> See MAINTAINERS file.
> CC'ing linux-arm-ker...@lists.infradead.org

Cheers for adding us to CC.

> >> #ifdef CONFIG_ARM_THUMB
> >> tst r8, #PSR_T_BIT
> >> movne   r10, #0 @ no thumb OABI emulation
> >> ldreq   r10, [lr, #-4]  @ get SWI instruction  
> >> // crash at this instruction, when get SWI instruction

Do you have the panic log please? Also, which SoC are you using and how are you 
reproducing this?

> >> ldr r10, [lr, #-4]  @ get SWI instruction
> >>   A710( and ip, r10, #0x0f00@ check for SWI )
> >>   A710( teq ip, #0x0f00 )
> >>   A710( bne .Larm710bug )
> >> #endif
> >> #ifdef CONFIG_CPU_ENDIAN_BE8
> >> rev r10, r10@ little endian instruction
> >> #endif
> >>
> >> /**
> >> ***
> >> **/
> >>
> >> Then reason why it will crash when get SWI instruction is maybe 
> >> This page is clear to aged by kernel, But this MMU fault happpened 
> >> in kernel, So the kernel do_page_fault function will not clear this 
> >> page to young, So that  will crash .

Sounds like we might need some USER annotations around the instruction loads, 
but we should also rework the code so that we re-enable interrupts first.

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

[PATCH V2] rtc: rtc-mpc5121: use platform_{get,set}_drvdata()

2013-05-29 Thread Jingoo Han

Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with >dev,
so we can directly pass a struct platform_device.

Signed-off-by: Jingoo Han 
---
Changes since v1:
- fixed conflicts with rtc-rtc-mpc5121-use-devm_-functions.patch

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

diff --git a/drivers/rtc/rtc-mpc5121.c b/drivers/rtc/rtc-mpc5121.c
index 4c02497..9c8f609 100644
--- a/drivers/rtc/rtc-mpc5121.c
+++ b/drivers/rtc/rtc-mpc5121.c
@@ -324,7 +324,7 @@ static int mpc5121_rtc_probe(struct platform_device *op)
 
device_init_wakeup(>dev, 1);
 
-   dev_set_drvdata(>dev, rtc);
+   platform_set_drvdata(op, rtc);
 
rtc->irq = irq_of_parse_and_map(op->dev.of_node, 1);
err = request_irq(rtc->irq, mpc5121_rtc_handler, 0,
@@ -382,7 +382,7 @@ out_dispose:
 
 static int mpc5121_rtc_remove(struct platform_device *op)
 {
-   struct mpc5121_rtc_data *rtc = dev_get_drvdata(>dev);
+   struct mpc5121_rtc_data *rtc = platform_get_drvdata(op);
struct mpc5121_rtc_regs __iomem *regs = rtc->regs;
 
/* disable interrupt, so there are no nasty surprises */
-- 
1.7.10.4


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

Re: [PATCH RESEND] scsi: megaraid: check kzalloc

On 2013/5/29 23:03, Tomas Henzl wrote:
> On 05/24/2013 11:40 AM, Libo Chen wrote:
>> we should check kzalloc, avoid to hit oops
>>
>> Signed-off-by: Libo Chen 
>> ---
>>  drivers/scsi/megaraid.c |4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> instead of checking scmd->device, sdev is more appropriate.
>>
>> diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
>> index 846f475..6b623cb 100644
>> --- a/drivers/scsi/megaraid.c
>> +++ b/drivers/scsi/megaraid.c
>> @@ -4161,6 +4161,10 @@ mega_internal_command(adapter_t *adapter, megacmd_t 
>> *mc, mega_passthru *pthru)
>>  memset(scb, 0, sizeof(scb_t));
>>
>>  sdev = kzalloc(sizeof(struct scsi_device), GFP_KERNEL);
>> +if (sdev) {
>> +scsi_free_command(GFP_KERNEL, scmd);
> 
> I think, that a mutex_unlock(>int_mtx); is also needed
> Maybe just setting a rval = -ENOMEM and a jump to to some point below?
> 
> tomash

thanks for catching this.

when kzalloc broken, fist unlock and then return.  I will update later.


Libo

> 
>> +return -ENOMEM;
>> +}
>>  scmd->device = sdev;
>>
>>  memset(adapter->int_cdb, 0, sizeof(adapter->int_cdb));
> 
> 
> .
> 


--
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: Stupid VFS name lookup interface..

2013-05-29 Thread Eric Paris

On Sat, May 25, 2013 at 10:19 PM, Linus Torvalds
 wrote:
> On Sat, May 25, 2013 at 10:04 PM, James Morris  wrote:
>> On Sat, 25 May 2013, Linus Torvalds wrote:
>>
>>> But I haven't even looked at what non-selinux setups do to
>>> performance. Last time I tried Ubuntu (they still use apparmor, no?),
>>> "make modules_install ; make install" didn't work for the kernel, and
>>> if the Ubuntu people don't want to support kernel engineers, I
>>> certainly am not going to bother with them. Who uses smack?
>>
>> Tizen, perhaps a few others.
>
> Btw, it really would be good if security people started realizing that
> performance matters. It's annoying to see the security lookups cause
> 50% performance degradations on pathname lookup (and no, I'm not
> exaggerating, that's literally what it was before we fixed it - and
> no, by "we" I don't mean security people).

I take a bit of exception to this.  I do care.  Stephen Smalley, the
only other person who does SELinux kernel work, cares.  I don't speak
for other LSMs, but at least both of us who have done anything with
SELinux in the last years care.  I did the RCU work for selinux and
you, sds, and I did a bunch of work to stop wasting so much stack
space which was crapping on performance.  And I'm here again   :)

> Right now (zooming into the kernel only - ignoring the fact that make
> really spends a fair amount of time in user space) I get
>
>   9.79%  make  [k] __d_lookup_rcu
>   5.48%  make  [k] link_path_walk
>   2.94%  make  [k] avc_has_perm_noaudit
>   2.47%  make  [k] selinux_inode_permission
>   2.25%  make  [k] path_lookupat
>   1.89%  make  [k] generic_fillattr
>   1.50%  make  [k] lookup_fast
>   1.27%  make  [k] copy_user_generic_string
>   1.17%  make  [k] generic_permission
>   1.15%  make  [k] dput
>   1.12%  make  [k] inode_has_perm.constprop.58
>   1.11%  make  [k] __inode_permission
>   1.08%  make  [k] kmem_cache_alloc
>   ...

I tried something else, doing caching of the last successful security
check inside the isec.  It isn't race free, so it's not ready for
prime time.  But right now my >1% looks like:

  7.97%  make  [k] __d_lookup_rcu
  5.79%  make  [k] link_path_walk
  3.67%  make  [k] selinux_inode_permission
  2.02%  make  [k] lookup_fast
  1.90%  make  [k] system_call
  1.76%  make  [k] path_lookupat
  1.68%  make  [k] inode_has_perm.isra.45.constprop.61
  1.53%  make  [k] copy_user_enhanced_fast_string
  1.39%  make  [k] generic_permission
  1.35%  make  [k] kmem_cache_free
  1.30%  make  [k] __audit_syscall_exit
  1.13%  make  [k] kmem_cache_alloc
  1.00%  make  [k] strncpy_from_user

How do I tell what is taking time inside selinux_inode_permission?
--
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] usb: gadget: r8a66597-udc: do not unlock unheld spinlock in r8a66597_sudmac_irq()

2013-05-29 Thread Shimoda, Yoshihiro

Hi,

(2013/05/30 8:58), Felipe Balbi wrote:
> HI,
> 
> On Thu, May 30, 2013 at 12:51:37AM +0400, Alexey Khoroshilov wrote:
>> r8a66597_irq() processes sudmac part (r8a66597_sudmac_irq()) before locking 
>> r8a66597->lock.
>> But transfer_complete(), that is called inside 
>> (r8a66597_sudmac_irq()->sudmac_finish()->transfer_complete()),
>> expects r8a66597->lock is locked. As a result unheld spinlock can be 
>> unlocked.
>>
>> The patch just moves locking before calling r8a66597_sudmac_irq().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Alexey Khoroshilov 
> 
> should this go to stable ? Looks like this bug has been there since
> 2.6.32.
> 

Because non SMP CPUs have sudmac for now, this may not go to stable, I think.

Best regards,
Yoshihiro Shimoda
--
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] arch: parisc: kernel: using strlcpy() instead of strcpy()


'boot_args' is an input args, and 'boot_command_line' has a fix length.

So need use strlcpy() instead of strcpy() to avoid memory overflow.


Signed-off-by: Chen Gang 
---
 arch/parisc/kernel/setup.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index 60c1ae6..7349a3f 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -69,7 +69,8 @@ void __init setup_cmdline(char **cmdline_p)
/* called from hpux boot loader */
boot_command_line[0] = '\0';
} else {
-   strcpy(boot_command_line, (char *)__va(boot_args[1]));
+   strlcpy(boot_command_line, (char *)__va(boot_args[1]),
+   COMMAND_LINE_SIZE);
 
 #ifdef CONFIG_BLK_DEV_INITRD
if (boot_args[2] != 0) /* did palo pass us a ramdisk? */
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] mm, memcg: add oom killer delay

2013-05-29 Thread David Rientjes

Completely disabling the oom killer for a memcg is problematic if
userspace is unable to address the condition itself, usually because it
is unresponsive.  This scenario creates a memcg deadlock: tasks are
sitting in TASK_KILLABLE waiting for the limit to be increased, a task to
exit or move, or the oom killer reenabled and userspace is unable to do
so.

An additional possible use case is to defer oom killing within a memcg
for a set period of time, probably to prevent unnecessary kills due to
temporary memory spikes, before allowing the kernel to handle the
condition.

This patch adds an oom killer delay so that a memcg may be configured to
wait at least a pre-defined number of milliseconds before calling the oom
killer.  If the oom condition persists for this number of milliseconds,
the oom killer will be called the next time the memory controller
attempts to charge a page (and memory.oom_control is set to 0).  This
allows userspace to have a short period of time to respond to the
condition before deferring to the kernel to kill a task.

Admins may set the oom killer delay using the new interface:

# echo 6 > memory.oom_delay_millisecs

This will defer oom killing to the kernel only after 60 seconds has
elapsed by putting the task to sleep for 60 seconds.

This expiration is cleared in four cases:

 - anytime the oom killer is called so another memory.oom_delay_millisecs
   delay is incurred the next time,

 - anytime memory is uncharged from a memcg so it is no longer oom so
   that there is now more available memory,

 - anytime memory.limit_in_bytes is raised so that there is now more
   available memory, and

 - anytime memory.oom_delay_millisecs is written from userspace to change
   the next delay.

Unless one of these events occurs after an oom delay has expired, all
future oom kills in that memcg will continue without incurring any delay.

When a memory.oom_delay_millisecs is set for a cgroup, it is propagated
to all children memcg as well and is inherited when a new memcg is
created.

Signed-off-by: David Rientjes 
---
 Documentation/cgroups/memory.txt | 27 ++
 mm/memcontrol.c  | 59 
 2 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -71,6 +71,7 @@ Brief summary of control files.
 (See sysctl's vm.swappiness)
  memory.move_charge_at_immigrate # set/show controls of moving charges
  memory.oom_control # set/show oom controls.
+ memory.oom_delay_millisecs # set/show millisecs to wait before oom kill
  memory.numa_stat   # show the number of memory usage per numa node
 
  memory.kmem.limit_in_bytes  # set/show hard limit for kernel memory
@@ -766,6 +767,32 @@ At reading, current status of OOM is shown.
under_oom0 or 1 (if 1, the memory cgroup is under OOM, tasks may
 be stopped.)
 
+It is possible to configure an oom killer delay to prevent the possibility that
+the memcg will deadlock looking for memory if userspace has disabled the oom
+killer with oom_control but cannot act to fix the condition itself (usually
+because it is unresponsive).
+
+To set an oom killer delay for a memcg, write the number of milliseconds to 
wait
+before killing a task to memory.oom_delay_millisecs:
+
+   # echo 6 > memory.oom_delay_millisecs   # 60 seconds before kill
+
+When this memcg is oom, it is guaranteed that this delay will elapse before the
+kernel kills a process.  If memory is uncharged from this memcg or one of its
+limits is expanded during this period, the oom kill is inhibited.
+
+Disabling the oom killer for a memcg with memory.oom_control takes precedence
+over memory.oom_delay_millisecs, so it must be set to 0 (default) to allow the
+oom kill after the delay has expired.
+
+This value is inherited from the memcg's parent on creation.  Setting a delay
+for a memcg sets the same delay for all children.
+
+There is no delay if memory.oom_delay_millisecs is set to 0 (default).  This
+tunable's upper bound is MAX_SCHEDULE_TIMEOUT (about 24 days on 32-bit and a
+lifetime on 64-bit).
+
+
 11. Memory Pressure
 
 The pressure level notifications can be used to monitor the memory
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -308,6 +308,10 @@ struct mem_cgroup {
int swappiness;
/* OOM-Killer disable */
int oom_kill_disable;
+   /* number of ticks to stall before calling oom killer */
+   int oom_delay;
+   /* expiration of current delay in jiffies, if oom in progress */
+   atomic64_t  oom_delay_expire;
 
/* set when res.limit == memsw.limit */
boolmemsw_is_minimum;
@@ -2185,8 +2189,11 @@ static void

Re: [PATCH RFC] PM / Runtime: Rework the "runtime idle" helper routine

2013-05-29 Thread Aaron Lu

On 05/30/2013 06:18 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 29, 2013 10:51:11 AM Alan Stern wrote:
>> On Wed, 29 May 2013, Rafael J. Wysocki wrote:
>>
>>> From: Rafael J. Wysocki 
>>>
>>> The "runtime idle" helper routine, rpm_idle(), currently ignores
>>> return values from .runtime_idle() callbacks executed by it.
>>>
>>> However, it turns out that many subsystems use the generic idle
>>> callback routine pm_generic_runtime_idle() which checks the return
>>> value of the driver's callback and executes pm_runtime_suspend() for
>>> the device unless that value is different from 0.  If that logic is
>>> moved to rpm_idle() instead, pm_generic_runtime_idle() can be dropped
>>> and its users will not need any .runtime_idle() callbacks any more.
>>
>> Since you're making this change, wouldn't it be a good idea to adopt
>> Mika's original suggestion and turn on the RPM_AUTO bit in rpmflags
>> when the use_autosuspend flag is set?
> 
> I'm not actually sure.  It can be done, but I'd prefer to do that as a 
> separate
> change in any case.

For SCSI idle callback, that would be a welcome change, where instead of
calling pm_runtime_autosuspend and then return -EBUSY, it can be changed
to simply return 0 after mark_last_busy.

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

Re: [PATCH] mm: sparse: use __aligned() instead of manual padding in mem_section

2013-05-29 Thread Jiang Liu

On Thu 30 May 2013 07:14:39 AM CST, Cody P Schafer wrote:
> Instead of leaving a trap for the next person who comes along and wants
> to add something to mem_section, add an __aligned() and remove the
> manual padding added for MEMCG.
>
> Signed-off-by: Cody P Schafer 
> ---
>  include/linux/mmzone.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> ---
>
> Also, does anyone know what causes this alignment to be required here? I found
> this was breaking things in a patchset I'm working on (WARNs in sysfs code
> about duplicate filenames when initing mem_sections). Adding some 
> documentation
> for the reason would be appreciated.
Hi Cody,
I think the alignment requirement is caused by the way the 
mem_section array is
organized. Basically it requires that PAGE_SIZE could be divided by 
sizeof(struct mem_section).
So your change seems risky too because it should be aligned to power of 
two instead
of 2 * sizeof(long).
Regards!
Gerry

>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 131989a..a8e8056 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1125,9 +1125,8 @@ struct mem_section {
>* section. (see memcontrol.h/page_cgroup.h about this.)
>*/
>   struct page_cgroup *page_cgroup;
> - unsigned long pad;
>  #endif
> -};
> +} __aligned(2 * sizeof(unsigned long));
>
>  #ifdef CONFIG_SPARSEMEM_EXTREME
>  #define SECTIONS_PER_ROOT   (PAGE_SIZE / sizeof (struct mem_section))


--
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 10/11] KVM: MMU: collapse TLB flushes when zap all pages

2013-05-29 Thread Gleb Natapov

On Wed, May 29, 2013 at 09:19:41PM +0800, Xiao Guangrong wrote:
> On 05/29/2013 08:39 PM, Marcelo Tosatti wrote:
> > On Wed, May 29, 2013 at 11:03:19AM +0800, Xiao Guangrong wrote:
> > the pages since other vcpus may be doing locklessly shadow
> > page walking
> >>>
> >>> Ah, yes, i agree with you.
> >>>
> >>> We can introduce a list, say kvm->arch.obsolte_pages, to link all of the
> >>> zapped-page, the page-shrink will free the page on that list first.
> >>>
> >>> Marcelo, if you do not have objection on  patch 1 ~ 8 and 11, could you 
> >>> please
> >>> let them merged first, and do add some comments and tlb optimization 
> >>> later?
> >>
> >> Exclude patch 11 please, since it depends on the "collapse" optimization.
> > 
> > I'm fine with patch 1 being merged. I think the remaining patches need 
> > better
> > understanding or explanation. The problems i see are:
> > 
> > 1) The magic number "10" to zap before considering reschedule is
> > annoying. It would be good to understand why it is needed at all.
> 
> ..
> 
> > 
> > But then again, the testcase is measuring kvm_mmu_zap_all performance
> > alone which we know is not a common operation, so perhaps there is
> > no need for that minimum-pages-to-zap-before-reschedule.
> 
> Well. Although, this is not the common operation, but this operation
> can be triggered by VCPU - it one VCPU take long time on zap-all-pages,
> other vcpus is missing IPI-synce, or missing IO. This is easily cause
> soft lockups if the vcpu is doing memslot-releated things.
> 
+1. If it is trigarable by a guest it may slow down the guest, but we
should not allow for it to slow down a host.

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

Re: [patch v6 8/8] sched: remove blocked_load_avg in tg

2013-05-29 Thread Alex Shi

On 05/30/2013 01:00 AM, Jason Low wrote:
> On Fri, 2013-05-10 at 23:17 +0800, Alex Shi wrote:
>> blocked_load_avg sometime is too heavy and far bigger than runnable load
>> avg. that make balance make wrong decision. So better don't consider it.
>>
>> Signed-off-by: Alex Shi 
> 
> Hi Alex,
> 
> I have been testing these patches with a Java server workload on an 8
> socket (80 core) box with Hyperthreading enabled, and I have been seeing
> good results with these patches.
> 
> When using a 3.10-rc2 tip kernel with patches 1-8, there was about a 40%
> improvement in performance of the workload compared to when using the
> vanilla 3.10-rc2 tip kernel with no patches. When using a 3.10-rc2 tip
> kernel with just patches 1-7, the performance improvement of the
> workload over the vanilla 3.10-rc2 tip kernel was about 25%.
> 
> Tested-by: Jason Low 
> 

That is impressive!

Thanks a lot for your testing! Just curious, what the benchmark are you
using? :)

> Thanks,
> Jason
> 


-- 
Thanks
Alex
--
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 3/3] saa7115: Implement i2c_board_info.platform data

2013-05-29 Thread Mauro Carvalho Chehab

Em Wed, 29 May 2013 22:41:18 +0200
Jon Arne Jørgensen  escreveu:

> Implement i2c_board_info.platform_data handling in the driver so we can
> make device specific changes to the chips we support.
> 

...

> +struct saa7115_platform_data {
> + /* Horizontal time constant */
> + u8 saa7113_r08_htc;
> +
> + u8 saa7113_r10_vrln;
> + u8 saa7113_r10_ofts;
> +
> + u8 saa7113_r12_rts0;
> + u8 saa7113_r12_rts1;
> +
> + u8 saa7113_r13_adlsb;
> +};

While this works, it makes harder to analyze what's changed there,
as the above nomenclature is too obfuscated.

The better would be if you could, instead, name the bits (or bytes)
that will require different data, like (I just got some random
bits from reg08, on saa7113 datasheet - I didn't actually checked
what bits are you using):

unsigned pll_closed: 1;
unsigned fast_mode: 1;
unsigned fast_locking: 1;


-- 

Cheers,
Mauro
--
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 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-29 Thread Mauro Carvalho Chehab

Em Wed, 29 May 2013 22:41:16 +0200
Jon Arne Jørgensen  escreveu:

> Change all default values in the initial setup table to match the table
> in the datasheet.

This is not a good idea, as it can produce undesired side effects
on the existing drivers that depend on it, and can't be easily
tested.

Please, don't change the current "default". It is, of course, OK
to change them if needed via the information provided inside the
platform data.

Regards,
Mauro
> 
> Signed-off-by: Jon Arne Jørgensen 
> ---
>  drivers/media/i2c/saa7115.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
> index d6f589a..4403679 100644
> --- a/drivers/media/i2c/saa7115.c
> +++ b/drivers/media/i2c/saa7115.c
> @@ -223,12 +223,12 @@ static const unsigned char saa7111_init[] = {
>  static const unsigned char saa7113_init[] = {
>   R_01_INC_DELAY, 0x08,
>   R_02_INPUT_CNTL_1, 0xc2,
> - R_03_INPUT_CNTL_2, 0x30,
> + R_03_INPUT_CNTL_2, 0x33,
>   R_04_INPUT_CNTL_3, 0x00,
>   R_05_INPUT_CNTL_4, 0x00,
> - R_06_H_SYNC_START, 0x89,
> + R_06_H_SYNC_START, 0xe9,
>   R_07_H_SYNC_STOP, 0x0d,
> - R_08_SYNC_CNTL, 0x88,
> + R_08_SYNC_CNTL, 0x98,
>   R_09_LUMA_CNTL, 0x01,
>   R_0A_LUMA_BRIGHT_CNTL, 0x80,
>   R_0B_LUMA_CONTRAST_CNTL, 0x47,
> @@ -236,11 +236,11 @@ static const unsigned char saa7113_init[] = {
>   R_0D_CHROMA_HUE_CNTL, 0x00,
>   R_0E_CHROMA_CNTL_1, 0x01,
>   R_0F_CHROMA_GAIN_CNTL, 0x2a,
> - R_10_CHROMA_CNTL_2, 0x08,
> + R_10_CHROMA_CNTL_2, 0x00,
>   R_11_MODE_DELAY_CNTL, 0x0c,
> - R_12_RT_SIGNAL_CNTL, 0x07,
> + R_12_RT_SIGNAL_CNTL, 0x01,
>   R_13_RT_X_PORT_OUT_CNTL, 0x00,
> - R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
> + R_14_ANAL_ADC_COMPAT_CNTL, 0x00,/* RESERVED */
>   R_15_VGATE_START_FID_CHG, 0x00,
>   R_16_VGATE_STOP, 0x00,
>   R_17_MISC_VGATE_CONF_AND_MSB, 0x00,


-- 

Cheers,
Mauro
--
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] timer: Fix jiffies wrap behavior of round_jiffies*()

2013-05-29 Thread Joe Perches

On Wed, 2013-05-29 at 16:38 -0700, Andrew Morton wrote:
> On Wed, 29 May 2013 16:17:47 -0700 Joe Perches  wrote:
> 
> > >   We could perhaps have a checkpatch rule
> > > which looks for comparisons against jiffes (and any other
> > > time-measuring variables we can detect)
> > 
> > other variables like?
> 
> Grepping for time_after finds a bunch.  There's no real pattern to it though.

get_jiffies_64() should probably be added as
another test too.

Also, these might be wrong:

arch/arm/kernel/smp_twd.c:  while (get_jiffies_64() < waitjiffies)
arch/arm/kernel/smp_twd.c:  while (get_jiffies_64() < waitjiffies)
fs/fuse/dir.c:  else if (fuse_dentry_time(entry) < get_jiffies_64()) {
fs/fuse/dir.c:  if (fi->i_time < get_jiffies_64()) {
fs/fuse/dir.c:  if (fi->i_time < get_jiffies_64()) {


--
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: System slow down from udev

2013-05-29 Thread Rafael J. Wysocki

On Thursday, May 30, 2013 01:55:07 AM Rafael J. Wysocki wrote:
> On Wednesday, May 29, 2013 03:49:38 PM Yinghai Lu wrote:
> > On Wed, May 29, 2013 at 2:34 PM, Rafael J. Wysocki  wrote:
> > > On Wednesday, May 29, 2013 01:13:46 PM Yinghai Lu wrote:
> > >> On Wed, May 29, 2013 at 4:29 AM, Rafael J. Wysocki  wrote:
> > >> > On your systems the processor driver is built-in.  Any chance to build 
> > >> > it as
> > >> > a module and see if that helps?
> > >>
> > >> it CONFIG_ACPI_PROCESSOR it not set in the config
> > >> the boot get to normal speed.
> > >
> > > Well, if it is not set at all, there won't be problems with it. :-)
> > >
> > > I've tested my linux-next branch on OpenSUSE 11.3 both with the processor
> > > driver built in and modular and I'm not able to reproduce the issue you're
> > > seeing.
> > >
> > > Moreover, I'm not sure if user space is involved here at all, because the
> > > problem triggers for you when all of the relevant kernel code is 
> > > non-modular.
> > >
> > > With the processor driver enabled, when the slowdown happens, are the 
> > > systems
> > > usable enough to get some debug info out of them?
> > 
> > please check the bootchart data.
> > 
> > looks like it take 200s if no acpi_processor ...
> > otherwise will take 800s or more.
> 
> Well, something's fishy for sure.
> 
> To my eyes it looks like we're getting lots of notifications related to the
> processor driver and that generates a lot of workqueue load.
> 
> Can you please get /proc/interrupts from both cases and the output of
> "find /sys/firmware/acpi/interrupts/ -print -exec cat {} \;"?
> 
> Also please send the output of "ls -l /sys/devices/system/cpu/cpu*" with the
> processor driver present.

Well, this is kind of a blind shot, but I'm wondering if the appended patch
makes any difference?

Rafael


---
 drivers/acpi/processor_driver.c |3 ---
 1 file changed, 3 deletions(-)

Index: linux-pm/drivers/acpi/processor_driver.c
===
--- linux-pm.orig/drivers/acpi/processor_driver.c
+++ linux-pm/drivers/acpi/processor_driver.c
@@ -87,9 +87,6 @@ static void acpi_processor_notify(acpi_h
struct acpi_processor *pr;
int saved;
 
-   if (device->handle != handle)
-   return;
-
pr = acpi_driver_data(device);
if (!pr)
return;

--
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] usb: gadget: r8a66597-udc: do not unlock unheld spinlock in r8a66597_sudmac_irq()

2013-05-29 Thread Felipe Balbi

HI,

On Thu, May 30, 2013 at 12:51:37AM +0400, Alexey Khoroshilov wrote:
> r8a66597_irq() processes sudmac part (r8a66597_sudmac_irq()) before locking 
> r8a66597->lock.
> But transfer_complete(), that is called inside 
> (r8a66597_sudmac_irq()->sudmac_finish()->transfer_complete()),
> expects r8a66597->lock is locked. As a result unheld spinlock can be unlocked.
> 
> The patch just moves locking before calling r8a66597_sudmac_irq().
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

should this go to stable ? Looks like this bug has been there since
2.6.32.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: gadget: add Faraday fotg210_udc driver

2013-05-29 Thread Felipe Balbi

Hi,

On Wed, May 29, 2013 at 06:31:50PM +, Yuan-Hsin Chen wrote:
> Faraday fotg210 udc driver supports only Bulk transfer so far.
> fotg210 could be configured as an USB2.0 peripheral.
> 
> This driver is tested with mass storage gadget driver on Faraday
> EVB a369.
> 
> Signed-off-by: Yuan-Hsin Chen 

Run through checkpatch.pl --strict and fix all errors, warnings and all
checks which make sense.

WARNING: please write a paragraph that describes the config symbol fully
#81: FILE: drivers/usb/gadget/Kconfig:196:
+config USB_FOTG210_UDC

CHECK: braces {} should be used on all arms of this statement
#183: FILE: drivers/usb/gadget/fotg210-udc.c:76:
+   if (ep->epnum) {
[...]
+   } else
[...]

WARNING: line over 80 characters
#190: FILE: drivers/usb/gadget/fotg210-udc.c:83:
+static void fotg210_fifo_ep_mapping(struct fotg210_ep *ep, u32 epnum, u32 
dir_in)

WARNING: line over 80 characters
#237: FILE: drivers/usb/gadget/fotg210-udc.c:130:
+static void fotg210_set_mps(struct fotg210_ep *ep, u32 epnum, u32 mps, u32 
dir_in)

WARNING: line over 80 characters
#241: FILE: drivers/usb/gadget/fotg210-udc.c:134:
+   u32 offset = dir_in ? FOTG210_INEPMPSR(epnum) : 
FOTG210_OUTEPMPSR(epnum);

WARNING: line over 80 characters
#349: FILE: drivers/usb/gadget/fotg210-udc.c:242:
+static void fotg210_ep_free_request(struct usb_ep *_ep, struct usb_request 
*_req)

WARNING: Avoid CamelCase: 
#372: FILE: drivers/usb/gadget/fotg210-udc.c:265:
+   value |= DMATFNR_ACC_Fn(ep->epnum - 1);

WARNING: line over 80 characters
#418: FILE: drivers/usb/gadget/fotg210-udc.c:311:
+   value = ioread32(ep->fotg210->reg + FOTG210_FIBCR(ep->epnum - 
1));

WARNING: line over 80 characters
#420: FILE: drivers/usb/gadget/fotg210-udc.c:313:
+   iowrite32(value, ep->fotg210->reg + FOTG210_FIBCR(ep->epnum - 
1));

WARNING: line over 80 characters
#441: FILE: drivers/usb/gadget/fotg210-udc.c:334:
+   length = ioread32(ep->fotg210->reg + 
FOTG210_FIBCR(ep->epnum - 1));

WARNING: Avoid CamelCase: 
#442: FILE: drivers/usb/gadget/fotg210-udc.c:335:
+   length &= FIBCR_BCFx;

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#456: FILE: drivers/usb/gadget/fotg210-udc.c:349:
+   printk(KERN_DEBUG "dma_mapping_error\n");

CHECK: Alignment should match open parenthesis
#461: FILE: drivers/usb/gadget/fotg210-udc.c:354:
+   dma_sync_single_for_device(NULL, d, length,
+   ep->dir_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);

WARNING: line over 80 characters
#476: FILE: drivers/usb/gadget/fotg210-udc.c:369:
+static void fotg210_ep0_queue(struct fotg210_ep *ep, struct fotg210_request 
*req)

CHECK: braces {} should be used on all arms of this statement
#483: FILE: drivers/usb/gadget/fotg210-udc.c:376:
+   if (req->req.length) {
[...]
+   } else
[...]

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#486: FILE: drivers/usb/gadget/fotg210-udc.c:379:
+   printk(KERN_DEBUG "%s : req->req.length = 0x%x\n",

CHECK: Alignment should match open parenthesis
#487: FILE: drivers/usb/gadget/fotg210-udc.c:380:
+   printk(KERN_DEBUG "%s : req->req.length = 0x%x\n",
+   __func__, req->req.length);

CHECK: braces {} should be used on all arms of this statement
#492: FILE: drivers/usb/gadget/fotg210-udc.c:385:
+   if (!req->req.length)
[...]
+   else {
[...]

WARNING: line over 80 characters
#495: FILE: drivers/usb/gadget/fotg210-udc.c:388:
+   u32 value = ioread32(ep->fotg210->reg + 
FOTG210_DMISGR0);

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#680: FILE: drivers/usb/gadget/fotg210-udc.c:573:
+   printk(KERN_DEBUG "0x%x\n", data);

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#691: FILE: drivers/usb/gadget/fotg210-udc.c:584:
+   printk(KERN_DEBUG "0x%x\n", data);

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#696: FILE: drivers/usb/gadget/fotg210-udc.c:589:
+   printk(KERN_DEBUG "0x%x\n", data);

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#702: FILE: drivers/usb/gadget/fotg210-udc.c:595:
+   printk(KERN_DEBUG "0x%x\n", data);

WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...  
to printk(KERN_DEBUG ...
#741: FILE: drivers/usb/gadget/fotg210-udc.c:634:
+   printk(KERN_DEBUG "request error!!\n");

WARNING: line over 80 characters
#744: FILE: drivers/usb/gadget/fotg210-udc.c:637:
+static void fotg210_set_address(struct fotg210_udc *fotg210, struct 
usb_ctrlrequest *ctrl)

Re: [PATCH] timer: Fix jiffies wrap behavior of round_jiffies*()

2013-05-29 Thread Joe Perches

On Wed, 2013-05-29 at 16:38 -0700, Andrew Morton wrote:
> On Wed, 29 May 2013 16:17:47 -0700 Joe Perches  wrote:
> 
> > >   We could perhaps have a checkpatch rule
> > > which looks for comparisons against jiffes (and any other
> > > time-measuring variables we can detect)
> > 
> > other variables like?
> 
> Grepping for time_after finds a bunch.  There's no real pattern to it though.

Yup, that's the problem.
Thought I'd ask what I was missing though.

No variable really stands out as testable other
than jiffies.

I added this to my local queue and I'll send it later.

# check for comparisons of jiffies
if ($line =~ 
/\bif\s*\((\s*jiffies\s*[\<\>]|.*[\<\>]=?\s*jiffies\b)/) {
WARN("JIFFIES_COMPARISON",
 "Comparing jiffies is almost always wrong; prefer 
time_after, time_before and friends\n" . $herecurr);
}

--
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: System slow down from udev

2013-05-29 Thread Rafael J. Wysocki

On Wednesday, May 29, 2013 03:49:38 PM Yinghai Lu wrote:
> On Wed, May 29, 2013 at 2:34 PM, Rafael J. Wysocki  wrote:
> > On Wednesday, May 29, 2013 01:13:46 PM Yinghai Lu wrote:
> >> On Wed, May 29, 2013 at 4:29 AM, Rafael J. Wysocki  wrote:
> >> > On your systems the processor driver is built-in.  Any chance to build 
> >> > it as
> >> > a module and see if that helps?
> >>
> >> it CONFIG_ACPI_PROCESSOR it not set in the config
> >> the boot get to normal speed.
> >
> > Well, if it is not set at all, there won't be problems with it. :-)
> >
> > I've tested my linux-next branch on OpenSUSE 11.3 both with the processor
> > driver built in and modular and I'm not able to reproduce the issue you're
> > seeing.
> >
> > Moreover, I'm not sure if user space is involved here at all, because the
> > problem triggers for you when all of the relevant kernel code is 
> > non-modular.
> >
> > With the processor driver enabled, when the slowdown happens, are the 
> > systems
> > usable enough to get some debug info out of them?
> 
> please check the bootchart data.
> 
> looks like it take 200s if no acpi_processor ...
> otherwise will take 800s or more.

Well, something's fishy for sure.

To my eyes it looks like we're getting lots of notifications related to the
processor driver and that generates a lot of workqueue load.

Can you please get /proc/interrupts from both cases and the output of
"find /sys/firmware/acpi/interrupts/ -print -exec cat {} \;"?

Also please send the output of "ls -l /sys/devices/system/cpu/cpu*" with the
processor driver present.

Thanks,
Rafael


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

Re: [PATCH] timer: Fix jiffies wrap behavior of round_jiffies*()

2013-05-29 Thread Andrew Morton

On Wed, 29 May 2013 16:17:47 -0700 Joe Perches  wrote:

> >   We could perhaps have a checkpatch rule
> > which looks for comparisons against jiffes (and any other
> > time-measuring variables we can detect)
> 
> other variables like?

Grepping for time_after finds a bunch.  There's no real pattern to it though.
--
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] KVM: PPC: Add support for IOMMU in-kernel handling

2013-05-29 Thread Scott Wood


On 05/29/2013 06:29:13 PM, Alexey Kardashevskiy wrote:

On 05/30/2013 09:14 AM, Scott Wood wrote:
> On 05/29/2013 06:10:33 PM, Alexey Kardashevskiy wrote:
>> On 05/30/2013 06:05 AM, Scott Wood wrote:
>> > But you didn't put it in the same section as  
KVM_CREATE_SPAPR_TCE.  0xe0

>> > begins a different section.
>>
>> It is not really obvious that there are sections as no comment  
defines

>> those :)
>
> There is a comment /* ioctls for fds returned by KVM_CREATE_DEVICE  
*/

>
> Putting KVM_CREATE_DEVICE in there was mainly to avoid dealing with  
the
> ioctl number conflict mess in the vm-ioctl section, but at least  
that one

> is related to the device control API. :-)
>
>> But yes, makes sense to move it up a bit and change the code to  
0xad.

>
> 0xad is KVM_KVMCLOCK_CTRL

That's it. I am _completely_ confused now. No system whatsoever :(
What rule should I use in order to choose the number for my new  
ioctl? :)


Yeah, it's a mess.  0xaf seems to be free. :-)

-Scott
--
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] KVM: PPC: Add support for IOMMU in-kernel handling

2013-05-29 Thread Alexey Kardashevskiy

On 05/30/2013 09:14 AM, Scott Wood wrote:
> On 05/29/2013 06:10:33 PM, Alexey Kardashevskiy wrote:
>> On 05/30/2013 06:05 AM, Scott Wood wrote:
>> > On 05/28/2013 07:12:32 PM, Alexey Kardashevskiy wrote:
>> >> On 05/29/2013 09:35 AM, Scott Wood wrote:
>> >> > On 05/28/2013 06:30:40 PM, Alexey Kardashevskiy wrote:
>> >> >> >> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>> >> >> >> >>> #define KVM_GET_DEVICE_ATTR  _IOW(KVMIO,  0xe2, struct
>> >> >> >> >>> kvm_device_attr)
>> >> >> >> >>> #define KVM_HAS_DEVICE_ATTR  _IOW(KVMIO,  0xe3, struct
>> >> >> >> >>> kvm_device_attr)
>> >> >> >> >>>
>> >> >> >> >>> +/* ioctl for SPAPR TCE IOMMU */
>> >> >> >> >>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO,  0xe4, struct
>> >> >> >> >>> kvm_create_spapr_tce_iommu)
>> >> >> >> >>
>> >> >> >> >> Shouldn't this go under the vm ioctl section?
>> >> >> >>
>> >> >> >>
>> >> >> >> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated
>> >> >> devices) is
>> >> >> >> in this section so I decided to keep them together. Wrong?
>> >> >> >
>> >> >> > You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with
>> >> >> > KVM_CREATE_SPAPR_TCE_IOMMU?
>> >> >>
>> >> >> Yes.
>> >> >
>> >> > Sigh.  That's the same thing repeated.  There's only one IOCTL.
>> >> Nothing is
>> >> > being "kept together".
>> >>
>> >> Sorry, I meant this ioctl - KVM_CREATE_SPAPR_TCE.
>> >
>> > But you didn't put it in the same section as KVM_CREATE_SPAPR_TCE.  0xe0
>> > begins a different section.
>>
>> It is not really obvious that there are sections as no comment defines
>> those :)
> 
> There is a comment /* ioctls for fds returned by KVM_CREATE_DEVICE */
> 
> Putting KVM_CREATE_DEVICE in there was mainly to avoid dealing with the
> ioctl number conflict mess in the vm-ioctl section, but at least that one
> is related to the device control API. :-)
> 
>> But yes, makes sense to move it up a bit and change the code to 0xad.
> 
> 0xad is KVM_KVMCLOCK_CTRL

That's it. I am _completely_ confused now. No system whatsoever :(
What rule should I use in order to choose the number for my new ioctl? :)



-- 
Alexey
--
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 0/5] rtc-at91rm9200: add shadow interrupt mask

2013-05-29 Thread Douglas Gilbert

On 13-05-29 04:41 PM, Robert Nelson wrote:

On Wed, May 29, 2013 at 3:33 PM, Andrew Morton
wrote:

On Thu, 23 May 2013 10:38:50 +0200 Johan Hovold wrote:

This is an update of the shadow-interrupt-mask series against v3.10-rc2.

I guess we need Atmel to confirm that all sam9x5 SoCs are indeed
affected. If not, then some probing mechanism as the one Doug suggested
could be implemented on top of (a subset of) these patches. What do you
say, Nicolas?

Note that the first patch (adding a missing OF compile guard) could be
applied straight away.

At this stage it is unclear to me how to proceed with patches 2-5.

fyi:

A version of these patches had been applied once before:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0ef1594c017521ea89278e80fe3f80dafb17abde

But due to a few issues it was later reverted:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e24b0bfa2f0446ffaad2661040be23668133aef8

Strange life of a patch. Mine was the original, Johan Hovold
objected and had it reverted. Johan then presented his first
patch then v2. They got lost in the weeds.

My hardware was still broken and this bug caused collateral
damage. My original patch no longer applied to lk 3.10.0-rc1
so I rewrote it, borrowing some of Johan's ideas and doing a
probe time check for the broken RTC_IMR. That patch was
presented about a week ago:
http://marc.info/?l=linux-arm-kernel=136917492531478=2
The top of that post gives some more background.

That prompted Johan to produce v3 of his patch which is the
subject of this thread. I was hoping that Nicolas Ferre would
comment or ack one of these patches. Still waiting.

I have a copy of the original, publicly released manual for
the at91sam9g25 (a member of the at91sam9x5 family) marked
"11032A–ATARM–27-Jul-11". It contains the following:
Errata
49.3.1
RTC: Interrupt Mask Register cannot be used
Interrupt Mask Register reading always returns 0.

Both Rev B and Rev C of that manual drop that particular
erratum. My g25 SoC-based subsystems come from an Atmel
partner and still have the RTC IMR bug.

Doug Gilbert

--
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] md: Partially revert 2f6db2a7, which broke raid5

2013-05-29 Thread NeilBrown

On Wed, 29 May 2013 15:03:40 +0200 Jens Axboe  wrote:

> On Wed, May 29 2013, Richard W.M. Jones wrote:
> > 
> > On Sun, May 19, 2013 at 10:51:45AM -0700, Kent Overstreet wrote:
> > > Sorry for the delay - been vacationing. Reproduced the original bug,
> > > here's a patch that fixes it:
> > > 
> > > 
> > > commit 402f5db3708b2062795a384a3d8397cf702e27bc
> > > Author: Kent Overstreet 
> > > Date:   Sun May 19 10:27:07 2013 -0700
> > > 
> > > raid5: Initialize bi_vcnt
> > > 
> > > The patch that converted raid5 to use bio_reset() forgot to initialize
> > > bi_vcnt.
> > > 
> > > Signed-off-by: Kent Overstreet 
> > > Cc: NeilBrown 
> > > Cc: Jens Axboe 
> > > Cc: linux-r...@vger.kernel.org
> > > 
> > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > > index 9359828..753f318 100644
> > > --- a/drivers/md/raid5.c
> > > +++ b/drivers/md/raid5.c
> > > @@ -664,6 +664,7 @@ static void ops_run_io(struct stripe_head *sh, struct 
> > > stripe_head_state *s)
> > >   if (test_bit(R5_ReadNoMerge, >dev[i].flags))
> > >   bi->bi_rw |= REQ_FLUSH;
> > >  
> > > + bi->bi_vcnt = 1;
> > >   bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
> > >   bi->bi_io_vec[0].bv_offset = 0;
> > >   bi->bi_size = STRIPE_SIZE;
> > > @@ -701,6 +702,7 @@ static void ops_run_io(struct stripe_head *sh, struct 
> > > stripe_head_state *s)
> > >   else
> > >   rbi->bi_sector = (sh->sector
> > > + rrdev->data_offset);
> > > + rbi->bi_vcnt = 1;
> > >   rbi->bi_io_vec[0].bv_len = STRIPE_SIZE;
> > >   rbi->bi_io_vec[0].bv_offset = 0;
> > >   rbi->bi_size = STRIPE_SIZE;
> > 
> > Ditto to the previous follow up.  We've been tracking this
> > bug for nearly a month:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=962079
> > 
> > Please include this (or the other) patch to fix it.
> 
> I'm assuming both Kent and I are waiting for Neil to pick it up. Neil, I
> can include this in my next round going upstream, just let me know. It
> should have been sent upstream a while back, sorry guys.
> 

Seems you were waiting for me, and I was waiting for you :-)

Yes: please include it with your next round.  Thanks!

NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH] tg3: remove redundant pm init code

2013-05-29 Thread Michael Chan

On Wed, 2013-05-29 at 17:00 +0800, Yijing Wang wrote: 
> Pci_enable_device() will set device pm state to D0, so
> it's no need to do it again in tg3_init_one().
> 
> Signed-off-by: Yijing Wang 

Acked-by: Michael Chan 

> ---
>  drivers/net/ethernet/broadcom/tg3.c |   20 +---
>  1 files changed, 1 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index 728d42a..1396ab3 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -17042,25 +17042,10 @@ static int tg3_init_one(struct pci_dev *pdev,
>  
>   pci_set_master(pdev);
>  
> - /* Find power-management capability. */
> - pm_cap = pci_find_capability(pdev, PCI_CAP_ID_PM);
> - if (pm_cap == 0) {
> - dev_err(>dev,
> - "Cannot find Power Management capability, aborting\n");
> - err = -EIO;
> - goto err_out_free_res;
> - }
> -
> - err = pci_set_power_state(pdev, PCI_D0);
> - if (err) {
> - dev_err(>dev, "Transition to D0 failed, aborting\n");
> - goto err_out_free_res;
> - }
> -
>   dev = alloc_etherdev_mq(sizeof(*tp), TG3_IRQ_MAX_VECS);
>   if (!dev) {
>   err = -ENOMEM;
> - goto err_out_power_down;
> + goto err_out_free_res;
>   }
>  
>   SET_NETDEV_DEV(dev, >dev);
> @@ -17406,9 +17391,6 @@ err_out_iounmap:
>  err_out_free_dev:
>   free_netdev(dev);
>  
> -err_out_power_down:
> - pci_set_power_state(pdev, PCI_D3hot);
> -
>  err_out_free_res:
>   pci_release_regions(pdev);
>  



--
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/8] mm: vmscan: Stall page reclaim and writeback pages based on dirty/writepage pages encountered

The patch "mm: vmscan: Have kswapd writeback pages based on dirty pages
encountered, not priority" decides whether to writeback pages from reclaim
context based on the number of dirty pages encountered. This situation
is flagged too easily and flushers are not given the chance to catch up
resulting in more pages being written from reclaim context and potentially
impacting IO performance. The check for PageWriteback is also misplaced as
it happens within a PageDirty check which is nonsense as the dirty may have
been cleared for IO. The accounting is updated very late and pages that are
already under writeback, were reactivated, could not unmapped or could not
be released are all missed. Similarly, a page is considered congested for
reasons other than being congested and pages that cannot be written out
in the correct context are skipped. Finally, it considers stalling and
writing back filesystem pages due to encountering dirty anonymous pages
at the tail of the LRU which is dumb.

This patch causes kswapd to begin writing filesystem pages from reclaim
context only if page reclaim found that all filesystem pages at the tail of
the LRU were unqueued dirty pages. Before it starts writing filesystem pages,
it will stall to give flushers a chance to catch up. The decision on whether
wait_iff_congested is also now determined by dirty filesystem pages only.
Congested pages are based on whether the underlying BDI is congested
regardless of the context of the reclaiming process.

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 61 -
 1 file changed, 48 insertions(+), 13 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4a43c28..999ef0b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -669,6 +669,25 @@ static enum page_references page_check_references(struct 
page *page,
return PAGEREF_RECLAIM;
 }
 
+/* Check if a page is dirty or under writeback */
+static void page_check_dirty_writeback(struct page *page,
+  bool *dirty, bool *writeback)
+{
+   /*
+* Anonymous pages are not handled by flushers and must be written
+* from reclaim context. Do not stall reclaim based on them
+*/
+   if (!page_is_file_cache(page)) {
+   *dirty = false;
+   *writeback = false;
+   return;
+   }
+
+   /* By default assume that the page flags are accurate */
+   *dirty = PageDirty(page);
+   *writeback = PageWriteback(page);
+}
+
 /*
  * shrink_page_list() returns the number of reclaimed pages
  */
@@ -697,6 +716,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
struct page *page;
int may_enter_fs;
enum page_references references = PAGEREF_RECLAIM_CLEAN;
+   bool dirty, writeback;
 
cond_resched();
 
@@ -725,6 +745,24 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
(PageSwapCache(page) && (sc->gfp_mask & __GFP_IO));
 
/*
+* The number of dirty pages determines if a zone is marked
+* reclaim_congested which affects wait_iff_congested. kswapd
+* will stall and start writing pages if the tail of the LRU
+* is all dirty unqueued pages.
+*/
+   page_check_dirty_writeback(page, , );
+   if (dirty || writeback)
+   nr_dirty++;
+
+   if (dirty && !writeback)
+   nr_unqueued_dirty++;
+
+   /* Treat this page as congested if underlying BDI is */
+   mapping = page_mapping(page);
+   if (mapping && bdi_write_congested(mapping->backing_dev_info))
+   nr_congested++;
+
+   /*
 * If a page at the tail of the LRU is under writeback, there
 * are three cases to consider.
 *
@@ -819,9 +857,10 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (!add_to_swap(page, page_list))
goto activate_locked;
may_enter_fs = 1;
-   }
 
-   mapping = page_mapping(page);
+   /* Adding to swap updated mapping */
+   mapping = page_mapping(page);
+   }
 
/*
 * The page is mapped into the page tables of one or more
@@ -841,11 +880,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
}
 
if (PageDirty(page)) {
-   nr_dirty++;
-
-   if (!PageWriteback(page))
-   nr_unqueued_dirty++;
-
/*
 * Only kswapd can writeback filesystem pages to
 * avoid risk of stack overflow

[PATCH 4/8] mm: vmscan: Set zone flags before blocking

In shrink_page_list a decision may be made to stall and flag a zone
as ZONE_WRITEBACK so that if a large number of unqueued dirty pages are
encountered later then the reclaimer will stall. Set ZONE_WRITEBACK before
potentially going to sleep so it is noticed sooner.

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5b1a79c..5f80d01 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1445,8 +1445,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
 */
if (nr_writeback && nr_writeback >=
(nr_taken >> (DEF_PRIORITY - sc->priority))) {
-   wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);
zone_set_flag(zone, ZONE_WRITEBACK);
+   wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);
}
 
/*
-- 
1.8.1.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 3/8] mm: vmscan: Stall page reclaim after a list of pages have been processed

Commit "mm: vmscan: Block kswapd if it is encountering pages under writeback"
blocks page reclaim if it encounters pages under writeback marked for
immediate reclaim. It blocks while pages are still isolated from the
LRU which is unnecessary. This patch defers the blocking until after the
isolated pages have been processed and tidies up some of the comments.

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 49 +
 1 file changed, 33 insertions(+), 16 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 999ef0b..5b1a79c 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -697,6 +697,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
  enum ttu_flags ttu_flags,
  unsigned long *ret_nr_unqueued_dirty,
  unsigned long *ret_nr_writeback,
+ unsigned long *ret_nr_immediate,
  bool force_reclaim)
 {
LIST_HEAD(ret_pages);
@@ -707,6 +708,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
unsigned long nr_congested = 0;
unsigned long nr_reclaimed = 0;
unsigned long nr_writeback = 0;
+   unsigned long nr_immediate = 0;
 
cond_resched();
 
@@ -773,8 +775,8 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
 *IO can complete. Waiting on the page itself risks an
 *indefinite stall if it is impossible to writeback the
 *page due to IO error or disconnected storage so instead
-*block for HZ/10 or until some IO completes then clear the
-*ZONE_WRITEBACK flag to recheck if the condition exists.
+*note that the LRU is being scanned too quickly and the
+*caller can stall after page list has been processed.
 *
 * 2) Global reclaim encounters a page, memcg encounters a
 *page that is not marked for immediate reclaim or
@@ -804,10 +806,8 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (current_is_kswapd() &&
PageReclaim(page) &&
zone_is_reclaim_writeback(zone)) {
-   unlock_page(page);
-   congestion_wait(BLK_RW_ASYNC, HZ/10);
-   zone_clear_flag(zone, ZONE_WRITEBACK);
-   goto keep;
+   nr_immediate++;
+   goto keep_locked;
 
/* Case 2 above */
} else if (global_reclaim(sc) ||
@@ -1033,6 +1033,7 @@ keep:
mem_cgroup_uncharge_end();
*ret_nr_unqueued_dirty += nr_unqueued_dirty;
*ret_nr_writeback += nr_writeback;
+   *ret_nr_immediate += nr_immediate;
return nr_reclaimed;
 }
 
@@ -1044,7 +1045,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
.priority = DEF_PRIORITY,
.may_unmap = 1,
};
-   unsigned long ret, dummy1, dummy2;
+   unsigned long ret, dummy1, dummy2, dummy3;
struct page *page, *next;
LIST_HEAD(clean_pages);
 
@@ -1057,7 +1058,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
 
ret = shrink_page_list(_pages, zone, ,
TTU_UNMAP|TTU_IGNORE_ACCESS,
-   , , true);
+   , , , true);
list_splice(_pages, page_list);
__mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
return ret;
@@ -1353,6 +1354,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
unsigned long nr_taken;
unsigned long nr_unqueued_dirty = 0;
unsigned long nr_writeback = 0;
+   unsigned long nr_immediate = 0;
isolate_mode_t isolate_mode = 0;
int file = is_file_lru(lru);
struct zone *zone = lruvec_zone(lruvec);
@@ -1394,7 +1396,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
return 0;
 
nr_reclaimed = shrink_page_list(_list, zone, sc, TTU_UNMAP,
-   _unqueued_dirty, _writeback, false);
+   _unqueued_dirty, _writeback, _immediate,
+   false);
 
spin_lock_irq(>lru_lock);
 
@@ -1447,14 +1450,28 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
}
 
/*
-* Similarly, if many dirty pages are encountered that are not
-* currently being written then flag that kswapd should start
-* writing back pages and stall to give a chance for flushers
-* to catch up.
+* memcg will stall in page writeback so only consider

[PATCH 5/8] mm: vmscan: Move direct reclaim wait_iff_congested into shrink_list

shrink_inactive_list makes decisions on whether to stall based on the
number of dirty pages encountered. The wait_iff_congested() call in
shrink_page_list does no such thing and it's arbitrary.

This patch moves the decision on whether to set ZONE_CONGESTED and the
wait_iff_congested call into shrink_page_list. This keeps all the
decisions on whether to stall or not in the one place.

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 62 -
 1 file changed, 33 insertions(+), 29 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5f80d01..4898daf 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -695,7 +695,9 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
  struct zone *zone,
  struct scan_control *sc,
  enum ttu_flags ttu_flags,
+ unsigned long *ret_nr_dirty,
  unsigned long *ret_nr_unqueued_dirty,
+ unsigned long *ret_nr_congested,
  unsigned long *ret_nr_writeback,
  unsigned long *ret_nr_immediate,
  bool force_reclaim)
@@ -1017,20 +1019,13 @@ keep:
VM_BUG_ON(PageLRU(page) || PageUnevictable(page));
}
 
-   /*
-* Tag a zone as congested if all the dirty pages encountered were
-* backed by a congested BDI. In this case, reclaimers should just
-* back off and wait for congestion to clear because further reclaim
-* will encounter the same problem
-*/
-   if (nr_dirty && nr_dirty == nr_congested && global_reclaim(sc))
-   zone_set_flag(zone, ZONE_CONGESTED);
-
free_hot_cold_page_list(_pages, 1);
 
list_splice(_pages, page_list);
count_vm_events(PGACTIVATE, pgactivate);
mem_cgroup_uncharge_end();
+   *ret_nr_dirty += nr_dirty;
+   *ret_nr_congested += nr_congested;
*ret_nr_unqueued_dirty += nr_unqueued_dirty;
*ret_nr_writeback += nr_writeback;
*ret_nr_immediate += nr_immediate;
@@ -1045,7 +1040,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
.priority = DEF_PRIORITY,
.may_unmap = 1,
};
-   unsigned long ret, dummy1, dummy2, dummy3;
+   unsigned long ret, dummy1, dummy2, dummy3, dummy4, dummy5;
struct page *page, *next;
LIST_HEAD(clean_pages);
 
@@ -1057,8 +1052,8 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
}
 
ret = shrink_page_list(_pages, zone, ,
-   TTU_UNMAP|TTU_IGNORE_ACCESS,
-   , , , true);
+   TTU_UNMAP|TTU_IGNORE_ACCESS,
+   , , , , , true);
list_splice(_pages, page_list);
__mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
return ret;
@@ -1352,6 +1347,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
unsigned long nr_scanned;
unsigned long nr_reclaimed = 0;
unsigned long nr_taken;
+   unsigned long nr_dirty = 0;
+   unsigned long nr_congested = 0;
unsigned long nr_unqueued_dirty = 0;
unsigned long nr_writeback = 0;
unsigned long nr_immediate = 0;
@@ -1396,8 +1393,9 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
return 0;
 
nr_reclaimed = shrink_page_list(_list, zone, sc, TTU_UNMAP,
-   _unqueued_dirty, _writeback, _immediate,
-   false);
+   _dirty, _unqueued_dirty, _congested,
+   _writeback, _immediate,
+   false);
 
spin_lock_irq(>lru_lock);
 
@@ -1431,7 +1429,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
 * same way balance_dirty_pages() manages.
 *
 * This scales the number of dirty pages that must be under writeback
-* before throttling depending on priority. It is a simple backoff
+* before a zone gets flagged ZONE_WRITEBACK. It is a simple backoff
 * function that has the most effect in the range DEF_PRIORITY to
 * DEF_PRIORITY-2 which is the priority reclaim is considered to be
 * in trouble and reclaim is considered to be in trouble.
@@ -1442,12 +1440,14 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
 * ...
 * DEF_PRIORITY-6 For SWAP_CLUSTER_MAX isolated pages, throttle if any
 * isolated page is PageWriteback
+*
+* Once a zone is flagged ZONE_WRITEBACK, kswapd will count the number
+* of pages under pages flagged for immediate reclaim and stall if any
+

[PATCH 7/8] mm: vmscan: Take page buffers dirty and locked state into account

Page reclaim keeps track of dirty and under writeback pages and uses it to
determine if wait_iff_congested() should stall or if kswapd should begin
writing back pages. This fails to account for buffer pages that can be under
writeback but not PageWriteback which is the case for filesystems like ext3
ordered mode. Furthermore, PageDirty buffer pages can have all the buffers
clean and writepage does no IO so it should not be accounted as congested.

This patch adds an address_space operation that filesystems may
optionally use to check if a page is really dirty or really under
writeback. An implementation is provided for for buffer_heads is added
and used for block operations and ext3 in ordered mode. By default the
page flags are obeyed.

Credit goes to Jan Kara for identifying that the page flags alone are
not sufficient for ext3 and sanity checking a number of ideas on how
the problem could be addressed.

Signed-off-by: Mel Gorman 
---
 fs/block_dev.c  |  1 +
 fs/buffer.c | 34 ++
 fs/ext3/inode.c |  1 +
 include/linux/buffer_head.h |  3 +++
 include/linux/fs.h  |  1 +
 mm/vmscan.c | 10 ++
 6 files changed, 50 insertions(+)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2091db8..9c8ebe4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1583,6 +1583,7 @@ static const struct address_space_operations def_blk_aops 
= {
.writepages = generic_writepages,
.releasepage= blkdev_releasepage,
.direct_IO  = blkdev_direct_IO,
+   .is_dirty_writeback = buffer_check_dirty_writeback,
 };
 
 const struct file_operations def_blk_fops = {
diff --git a/fs/buffer.c b/fs/buffer.c
index 1aa0836..4247aa9 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -91,6 +91,40 @@ void unlock_buffer(struct buffer_head *bh)
 EXPORT_SYMBOL(unlock_buffer);
 
 /*
+ * Returns if the page has dirty or writeback buffers. If all the buffers
+ * are unlocked and clean then the PageDirty information is stale. If
+ * any of the pages are locked, it is assumed they are locked for IO.
+ */
+void buffer_check_dirty_writeback(struct page *page,
+bool *dirty, bool *writeback)
+{
+   struct buffer_head *head, *bh;
+   *dirty = false;
+   *writeback = false;
+
+   BUG_ON(!PageLocked(page));
+
+   if (!page_has_buffers(page))
+   return;
+
+   if (PageWriteback(page))
+   *writeback = true;
+
+   head = page_buffers(page);
+   bh = head;
+   do {
+   if (buffer_locked(bh))
+   *writeback = true;
+
+   if (buffer_dirty(bh))
+   *dirty = true;
+
+   bh = bh->b_this_page;
+   } while (bh != head);
+}
+EXPORT_SYMBOL(buffer_check_dirty_writeback);
+
+/*
  * Block until a buffer comes unlocked.  This doesn't stop it
  * from becoming locked again - you have to lock it yourself
  * if you want to preserve its state.
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index 23c7128..8e590bd 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -1984,6 +1984,7 @@ static const struct address_space_operations 
ext3_ordered_aops = {
.direct_IO  = ext3_direct_IO,
.migratepage= buffer_migrate_page,
.is_partially_uptodate  = block_is_partially_uptodate,
+   .is_dirty_writeback = buffer_check_dirty_writeback,
.error_remove_page  = generic_error_remove_page,
 };
 
diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
index 6d9f5a2..d458880 100644
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -139,6 +139,9 @@ BUFFER_FNS(Prio, prio)
})
 #define page_has_buffers(page) PagePrivate(page)
 
+void buffer_check_dirty_writeback(struct page *page,
+bool *dirty, bool *writeback);
+
 /*
  * Declarations
  */
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 0a9a6766..96f857f 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -380,6 +380,7 @@ struct address_space_operations {
int (*launder_page) (struct page *);
int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
unsigned long);
+   void (*is_dirty_writeback) (struct page *, bool *, bool *);
int (*error_remove_page)(struct address_space *, struct page *);
 
/* swapfile support */
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bf47784..c857943 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -673,6 +673,8 @@ static enum page_references page_check_references(struct 
page *page,
 static void page_check_dirty_writeback(struct page *page,
   bool *dirty, bool *writeback)
 {
+   struct address_space *mapping;
+
/*
 * Anonymous pages are not handled by flushers and must be written
 * from reclaim context. Do not stall

[PATCH 8/8] fs: nfs: Inform the VM about pages being committed or unstable

VM page reclaim uses dirty and writeback page states to determine if
flushers are cleaning pages too slowly and that page reclaim should
stall waiting on flushers to catch up. Page state in NFS is a bit
more complex and a clean page can be unreclaimable due to being
unstable which is effectively "dirty" from the perspective of the
VM from reclaim context. Similarly, if the inode is currently being
committed then it's similar to being under writeback.

This patch adds a is_dirty_writeback() handled for NFS that checks
if a pages backing inode is being committed and should be accounted as
writeback and if a page has private state indicating that it is
effectively dirty.

Signed-off-by: Mel Gorman 
---
 fs/nfs/file.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index a87a44f..a4250a4 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -493,6 +493,35 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
return nfs_fscache_release_page(page, gfp);
 }
 
+static void nfs_check_dirty_writeback(struct page *page,
+   bool *dirty, bool *writeback)
+{
+   struct nfs_inode *nfsi;
+   struct address_space *mapping = page_file_mapping(page);
+
+   if (!mapping || PageSwapCache(page))
+   return;
+
+   /*
+* Check if an unstable page is currently being committed and
+* if so, have the VM treat it as if the page is under writeback
+* so it will not block due to pages that will shortly be freeable.
+*/
+   nfsi = NFS_I(mapping->host);
+   if (test_bit(NFS_INO_COMMIT, >flags)) {
+   *writeback = true;
+   return;
+   }
+
+   /*
+* If PagePrivate() is set, then the page is not freeable and as the
+* inode is not being committed, it's not going to be cleaned in the
+* near future so treat it as dirty
+*/
+   if (PagePrivate(page))
+   *dirty = true;
+}
+
 /*
  * Attempt to clear the private state associated with a page when an error
  * occurs that requires the cached contents of an inode to be written back or
@@ -540,6 +569,7 @@ const struct address_space_operations nfs_file_aops = {
.direct_IO = nfs_direct_IO,
.migratepage = nfs_migrate_page,
.launder_page = nfs_launder_page,
+   .is_dirty_writeback = nfs_check_dirty_writeback,
.error_remove_page = generic_error_remove_page,
 #ifdef CONFIG_NFS_SWAP
.swap_activate = nfs_swap_activate,
-- 
1.8.1.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 6/8] mm: vmscan: Treat pages marked for immediate reclaim as zone congestion

Currently a zone will only be marked congested if the underlying BDI
is congested but if dirty pages are spread across zones it is possible
that an individual zone is full of dirty pages without being congested.
The impact is that zone gets scanned very quickly potentially reclaiming
really clean pages. This patch treats pages marked for immediate reclaim
as congested for the purposes of marking a zone ZONE_CONGESTED and
stalling in wait_iff_congested.

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4898daf..bf47784 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -761,9 +761,15 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (dirty && !writeback)
nr_unqueued_dirty++;
 
-   /* Treat this page as congested if underlying BDI is */
+   /*
+* Treat this page as congested if the underlying BDI is or if
+* pages are cycling through the LRU so quickly that the
+* pages marked for immediate reclaim are making it to the
+* end of the LRU a second time.
+*/
mapping = page_mapping(page);
-   if (mapping && bdi_write_congested(mapping->backing_dev_info))
+   if ((mapping && bdi_write_congested(mapping->backing_dev_info)) 
||
+   (writeback && PageReclaim(page)))
nr_congested++;
 
/*
-- 
1.8.1.4

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

Re: [PATCH] timer: Fix jiffies wrap behavior of round_jiffies*()

2013-05-29 Thread Joe Perches

On Wed, 2013-05-29 at 16:01 -0700, Andrew Morton wrote:
> On Tue, 21 May 2013 20:43:50 +0200 Bart Van Assche  
> wrote:
> 
> > Make sure that the round_jiffies*() functions return a time that is
> > in the future when the jiffies counter is about to wrap.
> 
> Actually "when the jiffies counter has recently wrapped".
> 
> I assume this was found by inspection?
> 
> > @@ -149,9 +149,7 @@ static unsigned long round_jiffies_common(unsigned long 
> > j, int cpu,
> > /* now that we have rounded, subtract the extra skew again */
> > j -= cpu * 3;
> > -   if (j <= jiffies) /* rounding ate our timeout entirely; */
> 
> This used to be a very common bug - we've weeded out many instances but
> I'm sure more still remain.

This list probably isn't comprehensive.

$ git grep -E "if\s*\((\s*jiffies\s*[\<\>]|.*[\<\>]=?\s*jiffies\b)"
drivers/acpi/acpi_pad.c:if (last_jiffies + round_robin_time * 
HZ < jiffies) {
drivers/acpi/acpi_pad.c:if (jiffies > expire_time) {
drivers/dma/ioat/dma_v2.c:  if (jiffies > chan->timer.expires && 
timer_pending(>timer)) {
drivers/infiniband/hw/ipath/ipath_sdma.c:   if (jiffies < 
dd->ipath_sdma_abort_intr_timeout)
drivers/infiniband/hw/ipath/ipath_sdma.c:   if (jiffies > 
dd->ipath_sdma_abort_jiffies) {
drivers/infiniband/ulp/ipoib/ipoib_cm.c:if (p && 
time_after_eq(jiffies, p->jiffies + IPOIB_CM_RX_UPDATE
drivers/infiniband/ulp/ipoib/ipoib_cm.c:if 
(time_before_eq(jiffies, p->jiffies + IPOIB_CM_RX_TIMEOUT))
drivers/input/misc/ati_remote2.c:   if (!time_after_eq(jiffies, 
ar2->jiffies))
drivers/md/dm-log-userspace-base.c: else if (jiffies < limit)
drivers/misc/sgi-gru/grumain.c: if (gts->ts_steal_jiffies + 
GRU_STEAL_DELAY < jiffies)
drivers/net/ethernet/intel/e1000/e1000_ethtool.c:   if (jiffies >= 
(time + 2)) {
drivers/net/ethernet/intel/e1000e/ethtool.c:if (jiffies >= (time + 
20)) {
drivers/net/ethernet/micrel/ksz884x.c:  if (next_jiffies < 
jiffies)
drivers/net/ethernet/micrel/ksz884x.c:  } else if (jiffies >= 
hw_priv->counter[i].time) {
drivers/net/ethernet/micrel/ksz884x.c:  if (hw_priv->pme_wait <= 
jiffies) {
drivers/net/ethernet/neterion/vxge/vxge-main.c: if (jiffies > fifo->jiffies + 
HZ / 100) {
drivers/net/ethernet/neterion/vxge/vxge-main.c: if (jiffies > ring->jiffies + 
HZ / 100) {
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c: if (jiffies > 
(QLCNIC_FILTER_AGE * HZ + time)) {
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c: if (jiffies > 
(QLCNIC_FILTER_AGE * HZ + time)) {
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c: if 
(jiffies > (QLCNIC_READD_AGE * HZ + time))
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c: if (jiffies > 
(QLCNIC_READD_AGE * HZ + tmp_fil->ftime))
drivers/scsi/lpfc/lpfc_scsi.c:  if ((phba->last_ramp_down_time + 
QUEUE_RAMP_DOWN_INTERVAL) > jiffies) {
drivers/staging/bcm/InterfaceIdleMode.c:if (timeout < jiffies )
drivers/staging/lustre/include/linux/libcfs/linux/linux-prim.h: 
if (jiffies > expire) {   \
drivers/staging/speakup/speakup_acntpc.c:   if (jiffies >= jiff_max 
&& ch == SPACE) {
drivers/staging/speakup/speakup_decext.c:   if (jiffies >= 
jiff_max) {
drivers/staging/speakup/speakup_decpc.c:if (jiffies >= 
jiff_max) {
drivers/staging/speakup/speakup_dectlk.c:   if (jiffies >= 
jiff_max) {
kernel/timer.c: if (j <= jiffies) /* rounding ate our timeout entirely; */
net/rds/ib_send.c:  if (ic->i_ack_queued + HZ/2 < jiffies)
net/rds/ib_send.c:  if (send->s_queued + HZ/2 < jiffies)
net/rds/iw_send.c:  if (ic->i_ack_queued + HZ/2 < jiffies)
net/rds/iw_send.c:  if (send->s_queued + HZ/2 < jiffies)

>   We could perhaps have a checkpatch rule
> which looks for comparisons against jiffes (and any other
> time-measuring variables we can detect)

other variables like?

>  and tells people to use
> time_after() and friends, or time_is_*_jiffies().


--
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/8] mm: vmscan: Block kswapd if it is encountering pages under writeback -fix

The patch "mm: vmscan: Block kswapd if it is encountering pages
under writeback" stalls in congestion_wait it encounters a page under
writeback that is marked for immediate reclaim. Initially this was a
wait_on_page_writeback() but after the switch to congestion_wait(),
there is no guarantee the page has completed writeback and it can
be placed on a list for freeing.

This is a fix for
mm-vmscan-block-kswapd-if-it-is-encountering-pages-under-writeback.patch

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index b1b38ad..4a43c28 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -766,8 +766,10 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (current_is_kswapd() &&
PageReclaim(page) &&
zone_is_reclaim_writeback(zone)) {
+   unlock_page(page);
congestion_wait(BLK_RW_ASYNC, HZ/10);
zone_clear_flag(zone, ZONE_WRITEBACK);
+   goto keep;
 
/* Case 2 above */
} else if (global_reclaim(sc) ||
-- 
1.8.1.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 0/8] Reduce system disruption due to kswapd followup V3