Re: [PATCH v3] dynamic_debug: add wildcard support to filter files/functions/modules

[Changbin Du]

2013/10/30 Joe Perches :
> On Tue, 2013-10-29 at 21:33 +0800, Du, Changbin wrote:
>> This patch add wildcard '*'(matches zero or more characters) and '?'
>> (matches one character) support when qurying debug flags.
>
> Hi again.  Some trivial notes and a possible logic error:
>

>> +/* check if the string matches given pattern which includes wildcards */
>> +static bool match_pattern(const char *pattern, const char *string)
>> +{
>> + const char *s = string,
>> +*p = pattern;
>
> This sort of alignment is pretty unusual.
> Most kernel uses just repeat the type like:
>
> const char *s = string;
> const char *p = pattern;
>
I think so.

>> + bool star = 0;
>
> bool star = false;
>
>> +
>> + while (*s) {
>> + switch (*p) {
>> + case '?':
>> + ++s, ++p;
>> + break;
>> + case '*':
>> + star = true;
>> + string = s;
>> + if (!*++p)
>> + return true;
>> + pattern = p;;
>
> repeated ;
> Running your patches through checkpatch should find
> this sort of defect.
>

Sorry, it's may fault. I forgot to check it using the tool.

>> + break;
>> + default:
>> + if (*s != *p) {
>> + if (!star)
>> + return false;
>> + string++;
>> + s = string;
>> + p = pattern;
>> + break;
>> + }
>> + ++s, ++p;
>
> Maybe nicer with an if/else, I think you're still
> missing a reset of "star = false;" and I also think
> it's better to use a break here too.
>
> if (*s == *p) {
> s++;
> p++;
> star = false;
> } else {
> if (!star)
> return false;
> string++;
> s = string;
> p = pattern;
> }
> break;

I have run loss of test before sending patch. all case passed. But I
will double check if need reset star flag. really thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/init.c between commit 6979287a7df6 ("x86/mm: Add 'step_size'
comments to init_mem_mapping()") from the tip tree and commits
6452c268c6d6 ("x86/mm: factor out of top-down direct mapping setup") and
f790250c098a ("x86/mem-hotplug: support initialize page tables in
bottom-up") from the akpm-current tree.

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

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

diff --cc arch/x86/mm/init.c
index ce32017c5e38,b6892a71cbfc..
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@@ -399,28 -399,23 +399,39 @@@ static unsigned long __init init_range_
return mapped_ram_size;
  }
  
 -/* (PUD_SHIFT-PMD_SHIFT)/2 */
 -#define STEP_SIZE_SHIFT 5
 +static unsigned long __init get_new_step_size(unsigned long step_size)
 +{
 +  /*
 +   * Explain why we shift by 5 and why we don't have to worry about
 +   * 'step_size << 5' overflowing:
 +   *
 +   * initial mapped size is PMD_SIZE (2M).
 +   * We can not set step_size to be PUD_SIZE (1G) yet.
 +   * In worse case, when we cross the 1G boundary, and
 +   * PG_LEVEL_2M is not set, we will need 1+1+512 pages (2M + 8k)
 +   * to map 1G range with PTE. Use 5 as shift for now.
 +   *
 +   * Don't need to worry about overflow, on 32bit, when step_size
 +   * is 0, round_down() returns 0 for start, and that turns it
 +   * into 0x1ULL.
 +   */
 +  return step_size << 5;
 +}
  
- void __init init_mem_mapping(void)
+ /**
+  * memory_map_top_down - Map [map_start, map_end) top down
+  * @map_start: start address of the target memory range
+  * @map_end: end address of the target memory range
+  *
+  * This function will setup direct mapping for memory range
+  * [map_start, map_end) in top-down. That said, the page tables
+  * will be allocated at the end of the memory, and we map the
+  * memory in top-down.
+  */
+ static void __init memory_map_top_down(unsigned long map_start,
+  unsigned long map_end)
  {
-   unsigned long end, real_end, start, last_start;
+   unsigned long real_end, start, last_start;
unsigned long step_size;
unsigned long addr;
unsigned long mapped_ram_size = 0;
@@@ -470,8 -454,89 +470,89 @@@
mapped_ram_size += new_mapped_ram_size;
}
  
-   if (real_end < end)
-   init_range_memory_mapping(real_end, end);
+   if (real_end < map_end)
+   init_range_memory_mapping(real_end, map_end);
+ }
+ 
+ /**
+  * memory_map_bottom_up - Map [map_start, map_end) bottom up
+  * @map_start: start address of the target memory range
+  * @map_end: end address of the target memory range
+  *
+  * This function will setup direct mapping for memory range
+  * [map_start, map_end) in bottom-up. Since we have limited the
+  * bottom-up allocation above the kernel, the page tables will
+  * be allocated just above the kernel and we map the memory
+  * in [map_start, map_end) in bottom-up.
+  */
+ static void __init memory_map_bottom_up(unsigned long map_start,
+   unsigned long map_end)
+ {
+   unsigned long next, new_mapped_ram_size, start;
+   unsigned long mapped_ram_size = 0;
+   /* step_size need to be small so pgt_buf from BRK could cover it */
+   unsigned long step_size = PMD_SIZE;
+ 
+   start = map_start;
+   min_pfn_mapped = start >> PAGE_SHIFT;
+ 
+   /*
+* We start from the bottom (@map_start) and go to the top (@map_end).
+* The memblock_find_in_range() gets us a block of RAM from the
+* end of RAM in [min_pfn_mapped, max_pfn_mapped) used as new pages
+* for page table.
+*/
+   while (start < map_end) {
+   if (map_end - start > step_size) {
+   next = round_up(start + 1, step_size);
+   if (next > map_end)
+   next = map_end;
+   } else
+   next = map_end;
+ 
+   new_mapped_ram_size = init_range_memory_mapping(start, next);
+   start = next;
+ 
+   if (new_mapped_ram_size > mapped_ram_size)
 -  step_size <<= STEP_SIZE_SHIFT;
++  step_size = get_new_step_size(step_size);
+   mapped_ram_size += new_mapped_ram_size;
+   }
+ }
+ 
+ void __init init_mem_mapping(void)
+ {
+   unsigned long end;
+ 
+   probe_page_size_mask();
+ 
+ #ifdef CONFIG_X86_64
+   end = max_pfn << PAGE_SHIFT;
+ #else
+   end = max_low_pfn << PAGE_SHIFT;
+ #endif
+ 
+   /* the ISA range is always mapped regardless of memory holes */
+   init_memory_mapping(0, ISA_END_ADDRESS);
+ 
+   /*
+* If the allocation is in bottom-up direction, we setup direct mapping
+* i

Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()

[David Miller]

From: Cong Wang 
Date: Tue, 29 Oct 2013 20:50:08 -0700

> Normally ->poll() is called in softirq context, while netpoll could
> be called in any context depending on its caller.

It still makes amends to make the execution context still looks
"compatible" as far as locking et al. is concerned.
--
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] memstick: rtsx: fix ms card data transfer bug

[micky_ching]

From: Micky Ching 

unlike mspro card, ms card use normal read/write mode for DMA
data transfer.

Signed-off-by: Micky Ching 
---
 drivers/memstick/host/rtsx_pci_ms.c |   87 ---
 1 file changed, 81 insertions(+), 6 deletions(-)

diff --git a/drivers/memstick/host/rtsx_pci_ms.c 
b/drivers/memstick/host/rtsx_pci_ms.c
index 25f8f93..95eb208 100644
--- a/drivers/memstick/host/rtsx_pci_ms.c
+++ b/drivers/memstick/host/rtsx_pci_ms.c
@@ -137,8 +137,9 @@ static int ms_power_off(struct realtek_pci_ms *host)
return rtsx_pci_card_pull_ctl_disable(pcr, RTSX_MS_CARD);
 }
 
-static int ms_transfer_data(struct realtek_pci_ms *host, unsigned char 
data_dir,
-   u8 tpc, u8 cfg, struct scatterlist *sg)
+static int mspro_transfer_data(struct realtek_pci_ms *host,
+   unsigned char data_dir, u8 tpc, u8 cfg,
+   struct scatterlist *sg)
 {
struct rtsx_pcr *pcr = host->pcr;
int err;
@@ -198,6 +199,77 @@ static int ms_transfer_data(struct realtek_pci_ms *host, 
unsigned char data_dir,
return 0;
 }
 
+static int ms_transfer_data(struct realtek_pci_ms *host,
+   unsigned char data_dir, u8 tpc, u8 cfg,
+   struct scatterlist *sg)
+{
+   struct rtsx_pcr *pcr = host->pcr;
+   int err;
+   unsigned int length = sg->length;
+   u8 val, trans_mode, dma_dir;
+   struct completion trans_done;
+   int timeleft;
+
+   dev_dbg(ms_dev(host), "%s: tpc = 0x%02x, data_dir = %s, length = %d\n",
+   __func__, tpc, (data_dir == READ) ? "READ" : "WRITE",
+   length);
+
+   if (data_dir == READ) {
+   dma_dir = DMA_DIR_FROM_CARD;
+   trans_mode = MS_TM_NORMAL_READ;
+   } else {
+   dma_dir = DMA_DIR_TO_CARD;
+   trans_mode = MS_TM_NORMAL_WRITE;
+   }
+
+   rtsx_pci_init_cmd(pcr);
+
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TPC, 0xFF, tpc);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TRANS_CFG, 0xFF, cfg);
+
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, IRQSTAT0,
+   DMA_DONE_INT, DMA_DONE_INT);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, DMATC3, 0xFF, (u8)(length >> 24));
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, DMATC2, 0xFF, (u8)(length >> 16));
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, DMATC1, 0xFF, (u8)(length >> 8));
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, DMATC0, 0xFF, (u8)length);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, DMACTL,
+   0x03 | DMA_PACK_SIZE_MASK, dma_dir | DMA_EN | DMA_512);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_DATA_SOURCE,
+   0x01, RING_BUFFER);
+
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TRANSFER,
+   0xFF, MS_TRANSFER_START | trans_mode);
+   rtsx_pci_add_cmd(pcr, CHECK_REG_CMD, MS_TRANSFER,
+   MS_TRANSFER_END, MS_TRANSFER_END);
+
+   rtsx_pci_send_cmd_no_wait(pcr);
+
+   err = rtsx_pci_transfer_data(pcr, sg, 1, data_dir == READ, 1);
+   if (err < 0) {
+   ms_print_debug_regs(host);
+   ms_clear_error(host);
+   return err;
+   }
+
+   if (pcr->trans_result == TRANS_NOT_READY) {
+   init_completion(&trans_done);
+   timeleft = wait_for_completion_interruptible_timeout(
+   &trans_done, 1000);
+   if (timeleft < 0) {
+   dev_dbg(ms_dev(host),
+   "%s: timeout wait for ok interrupt.\n",
+   __func__);
+   return -ETIMEDOUT;
+   }
+   }
+   rtsx_pci_read_register(pcr, MS_TRANS_CFG, &val);
+   if (val & (MS_CRC16_ERR | MS_RDY_TIMEOUT))
+   return -EIO;
+
+   return 0;
+}
+
 static int ms_write_bytes(struct realtek_pci_ms *host, u8 tpc,
u8 cfg, u8 cnt, u8 *data, u8 *int_reg)
 {
@@ -340,6 +412,7 @@ static int ms_read_bytes(struct realtek_pci_ms *host, u8 
tpc,
 static int rtsx_pci_ms_issue_cmd(struct realtek_pci_ms *host)
 {
struct memstick_request *req = host->req;
+   struct memstick_dev *card = host->msh->card;
int err = 0;
u8 cfg = 0, int_reg;
 
@@ -350,9 +423,12 @@ static int rtsx_pci_ms_issue_cmd(struct realtek_pci_ms 
*host)
cfg = WAIT_INT;
}
 
-   if (req->long_data) {
+   if (req->long_data && card->id.type != MEMSTICK_TYPE_PRO) {
err = ms_transfer_data(host, req->data_dir,
req->tpc, cfg, &(req->sg));
+   } else if (req->long_data) {
+   err = mspro_transfer_data(host, req->data_dir,
+   req->tpc, cfg, &(req->sg));
} else {
if (req->data_dir == READ) {
err = ms_read_bytes(host, req->tpc, cfg,
@@ -461,9 +537,8 @@ static int rtsx_p

Re: [PATCH v3] ARM: bcm: Add DEBUG_LL console support

[Christian Daudt]

On Wed, Oct 16, 2013 at 11:12 PM, Christian Daudt  wrote:
> On Sat, Oct 5, 2013 at 8:43 AM, Christian Daudt  wrote:
>> This patch adds low level debug uart support to Broadcom
>>  mobile based SOCs.
>>
>> Signed-off-by: Christian Daudt 
>>
>> Changes from V2:
>>  - Changed to follow hex ordering on entries
>>  - Dropped defconfig changes
>>
>> Changes from V1:
>>  - Switched to use the common 8250 debug introduced in 3.12-rc1
>>
>
> Hi Russell,
>  Does V3 look ok ?
>
>  Thanks,
>csd
Hi,
 Can anyone provide an ack on this mod ?

 Thanks,
   csd
--
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] dynamic_debug: add wildcard support to filter files/functions/modules

[Changbin Du]

2013/10/30 Marcel Holtmann :
> Hi Changbin,
>
>> This patch add wildcard '*'(matches zero or more characters) and '?'
>> (matches one character) support when qurying debug flags.
>>
>> Now we can open debug messages using keywords. eg:
>> 1. open debug logs in all usb drivers
>>echo "file drivers/usb/* +p" > /dynamic_debug/control
>> 2.  open debug logs for usb xhci code
>>echo "file *xhci* +p" > /dynamic_debug/control
>
> and this should have a section in Documentation/dynamic-debug-howto.txt.

Yes, I will add a section to update the documentation also. Thanks for
reminding.

>
> Regards
>
> Marcel
>
--
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] UAPI: include in linux/raid/md_p.h

[NeilBrown]

On Tue, 29 Oct 2013 13:28:58 +0100 Aurelien Jarno 
wrote:

> linux/raid/md_p.h is using conditionals depending on endianess and fails
> with an error if neither of __BIG_ENDIAN, __LITTLE_ENDIAN or
> __BYTE_ORDER are defined, but it doesn't include any header which can
> define these constants. This make this header unusable alone.
> 
> This patch adds a #include  at the beginning of this
> header to make it usable alone. This is needed to compile klibc on MIPS.
> 
> Signed-off-by: Aurelien Jarno 
> ---
>  include/uapi/linux/raid/md_p.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h
> index fe1a540..f7cf7f3 100644
> --- a/include/uapi/linux/raid/md_p.h
> +++ b/include/uapi/linux/raid/md_p.h
> @@ -16,6 +16,7 @@
>  #define _MD_P_H
>  
>  #include 
> +#include 
>  
>  /*
>   * RAID superblock.

Makes sense.  Applied.  Thanks.

NeilBrown


signature.asc
Description: PGP signature

[RFC PATCH 0/2] DT match helpers for initcalls and platform devices

[Rob Herring]

From: Rob Herring 

This series adds a couple of boilerplate helpers to match with DT for
initcalls and platform device creation and probe. The goal here is to 
remove more platform code out of arch/arm and eventually the machine
descriptors.

Rob

Rob Herring (2):
  driver core: introduce module_platform_driver_match_and_probe
  of: add initcall with match boilerplate helpers

 include/linux/of.h  | 12 
 include/linux/platform_device.h | 23 +++
 2 files changed, 35 insertions(+)

-- 
1.8.1.2

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

[RFC PATCH 2/2] of: add initcall with match boilerplate helpers

[Rob Herring]

From: Rob Herring 

Add boilerplate helpers to create initcalls which are conditional on
matching on devicetree properties.

Cc: Grant Likely 
Signed-off-by: Rob Herring 
---
 include/linux/of.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/of.h b/include/linux/of.h
index f95aee3..a1327c9 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -592,6 +592,18 @@ static inline int of_property_read_u32(const struct 
device_node *np,
s;  \
s = of_prop_next_string(prop, s))
 
+#define of_initcall_match(__func, __lvl, __match) \
+static int __init __func##_init(void) \
+{ \
+   if (of_find_matching_node(NULL, __match)) \
+   return __func(); \
+   else \
+   return -ENODEV; \
+} \
+__lvl(__func##_init);
+
+#define of_module_init_match(__func, __match) of_initcall_match(__func, 
module_init, __match)
+
 #if defined(CONFIG_PROC_FS) && defined(CONFIG_PROC_DEVICETREE)
 extern void proc_device_tree_add_node(struct device_node *, struct 
proc_dir_entry *);
 extern void proc_device_tree_add_prop(struct proc_dir_entry *pde, struct 
property *prop);
-- 
1.8.1.2

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

Re: [PATCH] UAPI: include in linux/raid/md_p.h

[NeilBrown]

On Tue, 29 Oct 2013 13:28:58 +0100 Aurelien Jarno 
wrote:

> linux/raid/md_p.h is using conditionals depending on endianess and fails
> with an error if neither of __BIG_ENDIAN, __LITTLE_ENDIAN or
> __BYTE_ORDER are defined, but it doesn't include any header which can
> define these constants. This make this header unusable alone.
> 
> This patch adds a #include  at the beginning of this
> header to make it usable alone. This is needed to compile klibc on MIPS.
> 
> Signed-off-by: Aurelien Jarno 
> ---
>  include/uapi/linux/raid/md_p.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h
> index fe1a540..f7cf7f3 100644
> --- a/include/uapi/linux/raid/md_p.h
> +++ b/include/uapi/linux/raid/md_p.h
> @@ -16,6 +16,7 @@
>  #define _MD_P_H
>  
>  #include 
> +#include 
>  
>  /*
>   * RAID superblock.

Makes sense.  Applied.  Thanks.

NeilBrown


signature.asc
Description: PGP signature

[RFC PATCH 1/2] driver core: introduce module_platform_driver_match_and_probe

[Rob Herring]

From: Rob Herring 

Introduce a helper to match, create and probe a platform device. This
is for drivers such as cpuidle or cpufreq that typically don't have a
bus device node and need to match on a system-level compatible property.

Cc: Greg Kroah-Hartman 
Cc: Grant Likely 
Signed-off-by: Rob Herring 
---
 include/linux/platform_device.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index ce8e4ff..0b4b1c9 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -12,6 +12,7 @@
 #define _PLATFORM_DEVICE_H_
 
 #include 
+#include 
 #include 
 
 #define PLATFORM_DEVID_NONE(-1)
@@ -241,6 +242,28 @@ extern struct platform_device *platform_create_bundle(
struct resource *res, unsigned int n_res,
const void *data, size_t size);
 
+/*
+ * module_platform_driver_match_and_probe() - Helper macro for drivers without
+ * a bus device node and need to match on an arbitrary compatible property.
+ * This eliminates a lot of boilerplate.  Each module may only use this macro
+ * once, and calling it replaces module_init() and module_exit()
+ */
+#define module_platform_driver_match_and_probe(__platform_driver, 
__platform_probe) \
+static int __init __platform_driver##_init(void) \
+{ \
+   if (of_find_matching_node(NULL, 
(__platform_driver).driver.of_match_table)) \
+   return 
PTR_ERR_OR_ZERO(platform_create_bundle(&(__platform_driver), \
+   __platform_probe, NULL, 0, NULL, 0)); \
+   else \
+   return -ENODEV; \
+} \
+module_init(__platform_driver##_init); \
+static void __exit __platform_driver##_exit(void) \
+{ \
+   platform_driver_unregister(&(__platform_driver)); \
+} \
+module_exit(__platform_driver##_exit);
+
 /* early platform driver interface */
 struct early_platform_driver {
const char *class_str;
-- 
1.8.1.2

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

Re: [PATCH RESEND] ACPI: Add Toshiba NB100 to Vista _OSI blacklist

[Levente Kurusa]

2013-10-29 23:44 keltezéssel, Rafael J. Wysocki írta:
> On Tuesday, October 29, 2013 05:52:56 PM Levente Kurusa wrote:
>> This patch adds Toshiba NB100 to the Vista _OSI blacklist.
>>
>> The _OSI(Windows 2006) method is bugged on the netbook resulting in messed up
>> PCI IRQ Routing information. This was observed on a netbook,
>> whose SATA controller mode was set to Compatibility mode.
>> The driver would then register itself to IRQ#16, but the device
>> was in fact issuing interrupts to IRQ#20.
>> No side-effects were found during testing, everything is
>> working as it did before.
>>
>> See thread:
>> http://marc.info/?t=13786223021&r=1&w=2
>> http://www.spinics.net/lists/linux-ide/msg46173.html
>>
>>
>> Signed-off-by: Levente Kurusa 
>> Reviewed-by: Robert Hancock 
> 
> That should be in linux-pm/linux-next already, isn't it there?

Hm, I didn't receive any reply back on the other mail, so I thought it got
lost somewhere. I see now that it has been applied, thanks and sorry for
the inconvenience.

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

Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter

[Baoquan He]

On 10/30/13 at 09:44am, HATAYAMA Daisuke wrote:
> (2013/10/29 23:21), Baoquan He wrote:
> >Hi,
> >
> >I am reviewing this patchset, and found there's a cpu0 hotplug feature
> >posted by intel which we can borrow an idea from. In that implementation,
> >CPU0 is waken up by nmi not INIT to avoid the realmode bootstrap code
> >execution. I tried it by below patch which includes one line of change.
> >
> >By console printing, I got the boot cpu is always 0(namely cpu=0),
> >however the apicid related to each processor keeps the same as in 1st
> >kernel. In my HP Z420 machine, the apicid for BSP is 0, so I just make a
> >test patch which depends on the fact that apicid for BSP is 0. Maybe
> >generally the apicid for BSP can't be guaranteed, then passing it from
> >1st kernel to 2nd kernel in cmdline is very helpful, just as you have
> >done for disable_cpu_apic.
> >
> >On my HP z420, I add nr_cpus=4 in /etc/sysconfig/kdump, and then execute
> >below command, then 3 APs (1 boot cpu and 2 AP) can be waken up
> >correctly, but BSP failed because NMI received for unknown reason 21 on
> >CPU0. I think I need further check why BSP failed to wake up by nmi. But
> >3 processors are brought up successfully and kdump is successful too.
> >
> >sudo taskset -c 1 sh -c "echo c >/proc/sysrq-trigger"
> >
> >[0.296831] smpboot: Booting Node   0, Processors  #   1
> >[0.302095]
> >*cpu=1, apicid=0, 
> >wakeup_cpu_via_init_nmi
> >[0.311942] cpu=1, apicid=0, register_nmi_handlercpu=1, apicid=0, 
> >wakeup_secondary_cpu_via_nmi
> >[0.320826] Uhhuh. NMI received for unknown reason 21 on CPU 0.
> >[0.327129] Do you have a strange power saving mode enabled?
> >[0.333858] Dazed and confused, but trying to continue
> >[0.339290] cpu=1, apicid=0, wakeup_cpu_via_init_nmi
> >[2.409099] Uhhuh. NMI received for unknown reason 21 on CPU 0.
> >[2.415393] Do you have a strange power saving mode enabled?
> >[2.421142] Dazed and confused, but trying to continue
> >[5.379519] smpboot: CPU1: Not responding
> >[5.383692] NMI watchdog: enabled on all CPUs, permanently consumes one 
> >hw-PMU counter.
> >
> 
> We've already discussed this approach and concluded this is not applicable
> to our issue.
> Follow http://lists.infradead.org/pipermail/kexec/2012-October/006905.html.
> 
> The reason is:
> 
> - The cpu0-hotplugging approach assumes BSP to be halting before initiating
>   NMI to it while in our case, BSP is halting in the 1st kernel or is
>   running in arbitrary position of the 1st kernel in catastrophic state.
> 
> - In general, NMI modifies stack, which means if throwing NMI to the BSP
>   in the 1st kernel, stack on the 1st kernel is modified. It's unpermissible
>   from kdump's perspective.

Hi HATAYAMA,

All right. I didn't think of the stack issues NMI will bring. In fact
without this NMI stack problem, using CPU0 Hotplug as a base and sending
nmi to bsp will be good, because BSP failure can be acceptable, then
(N-1)cpus can be used. Later on if possible the contexts modifying can
be changed to let BSP wake up correctly. After all, from the user's
point of view, multiple cpus can be waken up, why not waking up all cpus
including BSP.  

Anyway, this issue has been discussed so long time, and it will be great
to run multiple cpus in 2nd kernel. This evolution may be like CPU0 Hotplug,
they let cpus except of BSP hot plug available, then hanle the last cpu -
the BSP finally. From this perspective, I like your patch and hope it
can be merged asap.

Baoquan
Thanks a lot

> 
> - On x86_64, there are two cases where stack is changed to another one
>   when receiving interrupts. One is when receiving interrupt in user mode.
>   The other is when using Interrupt Stack Table (IST), which is already
>   used in the current x86_64 implementation.
> 
>   By using either, it would be possible to wake up BSP in the 1st kernel
>   by modifying the contexts on the 2nd kernel's NMI stack pushed on when NMI
>   to the 1st kernel is initiated.
> 
>   However, this approach depends on the logic in the 1st kernel, there's
>   no guarantee that it works well. Consider severely buggy situation again.
> 
> - To do this approach rigorously, we need to check if states of BSP and APs
>   are kept in just what we assume in the place where logic is guaranteed to be
>   sane, i.e., at least after purgatory. However, adding new logic in the
>   purgatory means we are forced to introduce additional dependency between
>   kernel and kexec. The process performed in purgatory itself is not so
>   simple.I don't like this complication.
> 
> To sum up, I think the current idea is simple enough approach.
> 
> -- 
> Thanks.
> HATAYAMA, Daisuke
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th

Re: [PATCH] watchdog: at91sam9_wdt: various fixes

[b.brezillon]

On Tue, 29 Oct 2013 14:27:38 -0700, Guenter Roeck 
wrote:
> On Tue, Oct 29, 2013 at 06:22:47PM +0100, boris brezillon wrote:
>> On 29/10/2013 17:43, Guenter Roeck wrote:
>> >On Tue, Oct 29, 2013 at 05:22:50PM +0100, boris brezillon wrote:
>> >>On 29/10/2013 16:45, Guenter Roeck wrote:
>> >>>On Tue, Oct 29, 2013 at 11:37:33AM +0100, Boris BREZILLON wrote:
>> Fix the secs_to_ticks macro in case 0 is passed as an argument.
>> 
>> Rework the heartbeat calculation to increase the security margin of the
>> watchdog reset timer.
>> 
>> Use the min_heartbeat value instead of the calculated heartbeat value for
>> the first watchdog reset.
>> 
>> Signed-off-by: Boris BREZILLON 
>> >>>Hi Boris,
>> >>>
>> >>>can you possibly split the three changes into separate patches ?
>> >>Sure. My first idea was to split this in 3 patches, but, as the
>> >>buggy at91 watchdog series was
>> >>already applied to linux-watchdog-next, I thought it would be faster
>> >>to only provide one
>> >>patch to fix all the issues at once.
>> >>
>> >>>The first is a no-brainer. Gives my opinion of my code review capabilities
>> >>>a slight damper ;-).
>> >>>
>> >>>For the other two problems, it might make sense to describe
>> >>>the problems you are trying to solve.
>> >>>
>> >>>Couple of comments inline.
>> >>>
>> >>>Thanks,
>> >>>Guenter
>> >>>
>> >>>
>> ---
>>   drivers/watchdog/at91sam9_wdt.c |   35 
>>  ---
>>   1 file changed, 24 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/watchdog/at91sam9_wdt.c 
>> b/drivers/watchdog/at91sam9_wdt.c
>> index 9bd089e..f1b59f1 100644
>> --- a/drivers/watchdog/at91sam9_wdt.c
>> +++ b/drivers/watchdog/at91sam9_wdt.c
>> @@ -51,7 +51,7 @@
>>   #define ticks_to_hz_rounddown(t)   t) + 1) * HZ) >> 8)
>>   #define ticks_to_hz_roundup(t) (t) + 1) * HZ) + 255) >> 8)
>>   #define ticks_to_secs(t)   (((t) + 1) >> 8)
>> -#define secs_to_ticks(s)(((s) << 8) - 1)
>> +#define secs_to_ticks(s)(s ? (((s) << 8) - 1) : 0)
>> >>>  (s)
>> >>>
>>   #define WDT_MR_RESET   0x3FFF2FFF
>> @@ -61,6 +61,11 @@
>>   /* Watchdog max delta/value in secs */
>>   #define WDT_COUNTER_MAX_SECS   ticks_to_secs(WDT_COUNTER_MAX_TICKS)
>> +/* Watchdog heartbeat shift used for security margin:
>> + * we'll try to rshift the heartbeat value with this value to secure
>> + * the watchdog reset. */
>> +#define WDT_HEARTBEAT_SHIFT 2
>> +
>>   /* Hardware timeout in seconds */
>>   #define WDT_HW_TIMEOUT 2
>> @@ -158,7 +163,9 @@ static int at91_wdt_init(struct platform_device 
>> *pdev, struct at91wdt *wdt)
>>  int err;
>>  u32 mask = wdt->mr_mask;
>>  unsigned long min_heartbeat = 1;
>> +unsigned long max_heartbeat;
>>  struct device *dev = &pdev->dev;
>> +int shift;
>>  tmp = wdt_read(wdt, AT91_WDT_MR);
>>  if ((tmp & mask) != (wdt->mr & mask)) {
>> @@ -181,23 +188,27 @@ static int at91_wdt_init(struct platform_device 
>> *pdev, struct at91wdt *wdt)
>>  if (delta < value)
>>  min_heartbeat = ticks_to_hz_roundup(value - delta);
>> -wdt->heartbeat = ticks_to_hz_rounddown(value);
>> -if (!wdt->heartbeat) {
>> +max_heartbeat = ticks_to_hz_rounddown(value);
>> +if (!max_heartbeat) {
>>  dev_err(dev,
>>  "heartbeat is too small for the system to 
>>  handle it correctly\n");
>>  return -EINVAL;
>>  }
>> -if (wdt->heartbeat < min_heartbeat + 4) {
>> +for (shift = WDT_HEARTBEAT_SHIFT; shift > 0; shift--) {
>> +if ((max_heartbeat >> shift) < min_heartbeat)
>> +continue;
>> +
>> +wdt->heartbeat = max_heartbeat >> shift;
>> +break;
>> +}
>> +
>> +if (!shift)
>>  wdt->heartbeat = min_heartbeat;
>> >>>Correct me if I am wrong, but it seems to me that
>> >>>
>> >>>  if ((max_heartbeat >> 2) >= min_heartbeat)
>> >>>   wdt->heartbeat = max_heartbeat >> 2;
>> >>>  else if ((max_heartbeat >> 1) >= min_heartbeat)
>> >>>  wdt->heartbeat = max_heartbeat >> 1;
>> >>>  else
>> >>>  wdt->heartbeat = min_heartbeat;
>> >>>
>> >>>would accomplish the same and be easier to understand.
>> >>This is exactly what I'm trying to accomplish.
>> >>I used the for loop in case we ever want to change the
>> >>WDT_HEARTBEAT_SHIFT value
>> >>(which is unlikely to happen).
>> >>
>> >>I'll move to your proposition.
>> >>
>> >>>However, given that, I wonder if it is really necessary to bail out above 
>> >>>if
>> >>>max_heartbeat is 0. After all, you set heartbeat to min_heartbeat any

Re: Re: RFC: paravirtualizing perf_clock

[Masami Hiramatsu]

(2013/10/29 11:58), David Ahern wrote:
> On 10/28/13 7:15 AM, Peter Zijlstra wrote:
>>> Any suggestions on how to do this and without impacting performance. I
>>> noticed the MSR path seems to take about twice as long as the current
>>> implementation (which I believe results in rdtsc in the VM for x86 with
>>> stable TSC).
>>
>> So assuming all the TSCs are in fact stable; you could implement this by
>> syncing up the guest TSC to the host TSC on guest boot. I don't think
>> anything _should_ rely on the absolute TSC value.
>>
>> Of course you then also need to make sure the host and guest tsc
>> multipliers (cyc2ns) are identical, you can play games with
>> cyc2ns_offset if you're brave.
>>
> 
> This and the method Gleb mentioned both are going to be complex and 
> fragile -- based assumptions on how the perf_clock timestamps are 
> generated. For example, 489223e assumes you have the tracepoint enabled 
> at VM start with some means of capturing the data (e.g., a perf-session 
> active). In both cases the end result requires piecing together and 
> re-generating the VM's timestamp on the events. For perf this means 
> either modifying the tool to take parameters and an algorithm on how to 
> modify the timestamp or a homegrown tool to regenerate the file with 
> updated timestamps.
> 
> To back out a bit, my end goal is to be able to create and merge 
> perf-events from any context on a KVM-based host -- guest userspace, 
> guest kernel space, host userspace and host kernel space (userspace 
> events with a perf-clock timestamp is another topic ;-)).

That is almost same as what we(Yoshihiro and I) are trying on integrated
tracing, we are doing it on ftrace and trace-cmd (but perhaps, it eventually
works on perf-ftrace).

> Having the 
> events generated with the proper timestamp is the simpler approach than 
> trying to collect various tidbits of data, massage timestamps (and 
> hoping the clock source hasn't changed) and then merge events.

Yeah, if possible, we'd like to use it too.

> 
> And then for the cherry on top a design that works across architectures 
> (e.g., x86 now, but arm later).

I think your proposal is good for the default implementation, it doesn't
depends on the arch specific feature. However, since physical timer(clock)
interfaces and virtualization interfaces strongly depends on the arch,
I guess the optimized implementations will become different on each arch.
For example, maybe we can export tsc-offset to the guest to adjust clock
on x86, but not on ARM, or other devices. In that case, until implementing
optimized one, we can use paravirt perf_clock.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: OMAPFB: CMA allocation failures

[Minchan Kim]

Hello, Ивайло


On Tue, Oct 29, 2013 at 02:47:35PM +0200, Ивайло Димитров wrote:
>  
> Hi,
> 
> 
>  > Оригинално писмо 
>  >От:  Minchan Kim 
>  >Относно: Re: OMAPFB: CMA allocation failures
>  >До: Ивайло Димитров 
>  >Изпратено на: Понеделник, 2013, Октомври 28 09:37:48 EET
>  >
>  >
>  >Hello,
>  >
>  >On Tue, Oct 15, 2013 at 09:49:51AM +0300, Ивайло Димитров wrote:
>  >>  Hi
>  >> 
>  >>  > Оригинално писмо 
>  >>  >От:  Tomi Valkeinen 
>  >>  >Относно: Re: OMAPFB: CMA allocation failures
>  >>  >До: Ивайло Димитров
>  >>   
>  >>  >Изпратено на: Понеделник, 2013, Октомври 14 09:04:35 EEST
>  >>  >
>  >>  >
>  >>  >Hi,
>  >>  >
>  >>  >On 12/10/13 17:43, Ивайло Димитров wrote:
>  >>  >>  Hi Tomi,
>  >>  >> 
>  >>  >> patch 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html
>  modifies
>  >>  >> omapfb driver to use DMA API to allocate framebuffer memory instead 
> of preallocating VRAM.
>  >>  >> 
>  >>  >> With this patch I see a lot of:
>  >>  >> 
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
> dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
> dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
> dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
> dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
> dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
> dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
> dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
> dma_alloc_from_contiguous(): returned   (null)
>  >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: 
> failed to allocate framebuffer
>  >>  >> 
>  >>  >> errors while trying to play a video on N900 with Maemo 5 (Fremantle) 
> on top of linux-3.12rc1.
>  >>  >> It is deffinitely the CMA that fails to allocate the memory most of 
> the times, but I wonder
>  >>  >> how reliable CMA is to be used in omapfb. I even reserved 64MB for 
> CMA, but that made no
>  >>  >> difference. If CMA is disabled, the memory allocation still fails as 
> obviously it is highly
>  >>  >> unlikely there will be such a big chunk of continuous free memory on 
> RAM limited device like
>  >>  >> N900. 
>  >>  >> 
>  >>  >> One obvious solution is to just revert the removal of VRAM memory 
> allocator, but that would
>  >>  >> mean I'll have to maintain a separate tree with all the implications 
> that brings.
>  >>  >> 
>  >>  >> What would you advise on how to deal with the issue?
>  >>  >
>  >>  >I've not seen such errors, and I'm no expert on CMA. But I guess the
>  >>  >contiguous memory area can get fragmented enough no matter how hard one
>  >>  >tries to avoid it. The old VRAM system had the same issue, although it
>  >>  >was quite difficult to hit it.
>  >> 
>  >> I am using my n900 as a daily/only device since the beginning of 2010, 
> never seen such an 
>  >> issue with video playback. And as a maintainer of one of the community 
> supported kernels for
>  >> n900 (kernel-power) I've never had such an issue reported. On stock 
> kernel and derivatives of
>  >> course. It seems VRAM allocator is virtually impossible to fail, while 
> with CMA OMAPFB fails on
>  >> the first video after boot-up.
>  >> 
>  >> When saying you've not seen such an issue - did you actually test video 
> playback, on what
>  >> device and using which distro? Did you use DSP accelerated decoding?
>  >> 
>  >>  >64MB does sound quite a lot, though. I wonder what other drivers are
>  >>  >using CMA, and how do they manage to allocate so much memory and
>  >>  >fragment it so badly... With double buffering, N900 should only need
>  >>  >something like 3MB for the frame buffer.
>  >> 
>  >> Sure, 64 MB is a lot, but I just wanted to see if that would make any 
> difference. And for 720p 
>  >> 3MB is not enough, something like 8MB is needed.
>  >> 
>  >>  >With a quick glance I didn't find any debugfs or such files to show
>  >>  >information about the CMA area. It'd be helpful to find out what's going
>  >>  >on there. Or maybe normal allocations are fragmenting the CMA area, but
>  >>  >for some reason they cannot be moved? Just guessing.
>  >> 
>  >> I was able to track down the failures to:
>  >> http://lxr.free-electrons.com/source/mm/migrate.c#L320
>  >
>  >That path is for anonymous page migration so the culprit I can think of
>  >is that you did get_user_pages on those anonymous pages for pi

Re: [PATCH] edac, highbank: Add MAINTAINERS entry

[Rob Herring]

On 10/29/2013 12:47 PM, Robert Richter wrote:
> So taking over maintainership for the EDAC highbank driver.
> 
> Cc: Rob Herring 
> Cc: Borislav Petkov 
> Signed-off-by: Robert Richter 

Acked-by: Rob Herring 

--
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: cma: free cma page to buddy instead of being cpu hot page

[Minchan Kim]

Hello,

On Tue, Oct 29, 2013 at 09:14:03AM -0700, Laura Abbott wrote:
> On 10/29/2013 8:02 AM, Zhang Mingjun wrote:
> 
> >It would move the cost to the CMA paths so I would complain less. Bear
> >in mind as well that forcing everything to go through free_one_page()
> >means that every free goes through the zone lock. I doubt you have any
> >machine large enough but it is possible for simultaneous CMA allocations
> >to now contend on the zone lock that would have been previously fine.
> >Hence, I'm interesting in knowing the underlying cause of the
> >problem you
> >are experiencing.
> >
> >my platform uses CMA but disabled CMA's migration func by del MIGRATE_CMA
> >in fallbacks[MIGRATE_MOVEABLE]. But I find CMA pages can still used by
> >pagecache or page fault page request from PCP list and cma allocation has to
> >migrate these page. So I want to free these cma pages to buddy directly
> >not PCP..
> >
> > > of course, it will waste the memory outside of the alloc range
> >but in the
> > > pageblocks.
> > >
> >
> >I would hope/expect that the loss would only last for the duration of
> >the allocation attempt and a small amount of memory.
> >
> > > > when a range of pages have been isolated and migrated. Is there any
> > > > measurable benefit to this patch?
> > > >
> > > after applying this patch, the video player on my platform works more
> > > fluent,
> >
> >fluent almost always refers to ones command of a spoken language. I do
> >not see how a video player can be fluent in anything. What is measurably
> >better?
> >
> >For example, are allocations faster? If so, why? What cost from another
> >path is removed as a result of this patch? If the cost is in the PCP
> >flush then can it be checked if the PCP flush was unnecessary and called
> >unconditionally even though all the pages were freed already? We had
> >problems in the past where drain_all_pages() or similar were called
> >unnecessarily causing long sync stalls related to IPIs. I'm wondering if
> >we are seeing a similar problem here.
> >
> >Maybe the problem is the complete opposite. Are allocations failing
> >because there are PCP pages in the way? In that case, it real fix might
> >be to insert a  if the allocation is failing due to per-cpu
> >pages.
> >
> >problem is not the allocation failing, but the unexpected cma migration
> >slows
> >down the allocation.
> >
> >
> > > and the driver of video decoder on my test platform using cma
> >alloc/free
> > > frequently.
> > >
> >
> >CMA allocations are almost never used outside of these contexts. While I
> >appreciate that embedded use is important I'm reluctant to see an impact
> >in fast paths unless there is a good reason for every other use case. I
> >also am a bit unhappy to see CMA allocations making the zone->lock
> >hotter than necessary even if no embedded use case it likely to
> >experience the problem in the short-term.
> >
> >--
> >Mel Gorman
> >SUSE Labs
> >
> >
> 
> We've had a similar patch in our tree for a year and a half because
> of CMA migration failures, not just for a speedup in allocation
> time. I understand that CMA is not the fast case or the general use
> case but the problem is that the cost of CMA failure is very high
> (complete failure of the feature using CMA). Putting CMA on the PCP
> lists means they may be picked up by users who temporarily make the
> movable pages unmovable (page cache etc.) which prevents the
> allocation from succeeding. The problem still exists even if the CMA
> pages are not on the PCP list but the window gets slightly smaller.

I understand that I have seen many people want to use CMA have tweaked
their system to work well and although they do best effort, it doesn't
work well because CMA doesn't gaurantee to succeed in getting free
space since there are lots of hurdle. (get_user_pages, AIO ring buffer,
buffer cache, short of free memory for migration, no swap and so on).
Even, someone want to allocate CMA space with speedy. SIGH.

Yeah, at the moment, CMA is really SUCK.

> 
> This really highlights one of the biggest issues with CMA today.
> Movable pages make return -EBUSY for any number of reasons. For
> non-CMA pages this is mostly fine, another movable page may be
> substituted for the movable page that is busy. CMA is a restricted
> range though so any failure in that range is very costly because CMA
> regions are generally sized exactly for the use cases at hand which
> means there is very little extra space for retries.
> 
> To make CMA actually usable, we've had to go through and add in
> hacks/quirks that prevent CMA from being allocated in any path which
> may prevent migration. I've been mixed on if this is the right path
> or if the definition of MIGRATE_CMA needs to be changed to be more
> restrictive (can't prevent migration).

Fundamental probl

[PATCH -next] ARM i.MX53: remove duplicated include from clk-imx51-imx53.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 arch/arm/mach-imx/clk-imx51-imx53.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
b/arch/arm/mach-imx/clk-imx51-imx53.c
index ce37af2..2828ea65 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

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

[PATCH -next] ARM: ixp4xx: remove duplicated include from dsmg600-setup.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 arch/arm/mach-ixp4xx/dsmg600-setup.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c 
b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 736dc69..7740e13 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 

--
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 01/21] scripts/gdb: Add infrastructure

[Andi Kleen]

> The loading mechanism is based on gdb loading for -gdb.py when
> opening . Therefore, this places a corresponding link to the
> main helper script into the output directory that contains vmlinux.

> This feature depends on CONFIG_DEBUG_INFO.

Could you make this a separate config option? Having the links for
people who don't use gdb would be ugly.

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

[PATCH -next] mtd: remove duplicated include from mtdcore.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 drivers/mtd/mtdcore.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 7189089..92311a5 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 

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

[PATCH -next] tifm: fix error return code in tifm_7xx1_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return ENODEV in the pci ioremap error handling case
instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/misc/tifm_7xx1.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/tifm_7xx1.c b/drivers/misc/tifm_7xx1.c
index ae282a1..a606c89 100644
--- a/drivers/misc/tifm_7xx1.c
+++ b/drivers/misc/tifm_7xx1.c
@@ -356,8 +356,10 @@ static int tifm_7xx1_probe(struct pci_dev *dev,
pci_set_drvdata(dev, fm);
 
fm->addr = pci_ioremap_bar(dev, 0);
-   if (!fm->addr)
+   if (!fm->addr) {
+   rc = -ENODEV;
goto err_out_free;
+   }
 
rc = request_irq(dev->irq, tifm_7xx1_isr, IRQF_SHARED, DRIVER_NAME, fm);
if (rc)

--
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] scripts/kconfig/menu.c: warning: jump may be used uninitialized in this function

[Madhavan Srinivasan]

On Tuesday 29 October 2013 11:23 PM, Yann E. MORIN wrote:
> Christian, All,
> 
> On 2013-10-27 19:02 -0700, Christian Kujau spake thusly:
>> On Sun, 27 Oct 2013 at 18:28, Christian Kujau wrote:
>>> While doing "make oldconfig" on 3.12-rc7 with gcc-4.7.2 (Debian), the 
>>> following warning is printed:
>>>
>>>   HOSTCC  scripts/kconfig/zconf.tab.o
>>> In file included from scripts/kconfig/zconf.tab.c:2537:0:
>>> /usr/local/src/linux-git/scripts/kconfig/menu.c: In function 
>>> ‘get_symbol_str’:
>>> /usr/local/src/linux-git/scripts/kconfig/menu.c:586:18: warning: ‘jump’ may 
>>> be used uninitialized in this function [-Wmaybe-uninitialized]
>>> /usr/local/src/linux-git/scripts/kconfig/menu.c:547:19: note: ‘jump’ was 
>>> declared here
>>
>> Grrr, only after I sent this message I found this was reported in 
>> September already by Madhavan Srinivasan:  https://lkml.org/lkml/2013/9/19/24
>>
>> Does anybody know the state of this fix?
> 
My bad, somehow this slipped from my todo list.

> The solution was to properly comment that this was a gcc issue, in that 
> this is a spurious error, does not appear in previous gcc versions, and
> has been fixed in later gcc versions.
> 
I also notice this with gcc 4.8.1 (20131002) build.

> Setting 'jump' to NULL may hide reall issues in case the code is changed
> in the future, so it is not appropriate a fix. Hence why the previously-
> submitted patches were not applied.
> 
> I'll take this on me to properly fix this. Thanks for the heads up.
> 
> Regards,
> Yann E. MORIN.
> 

--
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 v9 01/13] KVM: PPC: POWERNV: move iommu_add_device earlier

[Bhushan Bharat-R65777]

Hi Alex,

Looks like this patch is not picked by anyone, Are you going to pick this patch?
My vfio/iommu patches have dependency on this patch (this is already tested by 
me).

Thanks
-Bharat

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Alexey
> Kardashevskiy
> Sent: Wednesday, August 28, 2013 2:08 PM
> To: linuxppc-...@lists.ozlabs.org
> Cc: k...@vger.kernel.org; Gleb Natapov; Alexey Kardashevskiy; Alexander Graf;
> kvm-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; 
> Paul
> Mackerras; Paolo Bonzini; David Gibson
> Subject: [PATCH v9 01/13] KVM: PPC: POWERNV: move iommu_add_device earlier
> 
> The current implementation of IOMMU on sPAPR does not use iommu_ops and
> therefore does not call IOMMU API's bus_set_iommu() which
> 1) sets iommu_ops for a bus
> 2) registers a bus notifier
> Instead, PCI devices are added to IOMMU groups from
> subsys_initcall_sync(tce_iommu_init) which does basically the same thing 
> without
> using iommu_ops callbacks.
> 
> However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
> implements iommu_ops and when tce_iommu_init is called, every PCI device is
> already added to some group so there is a conflict.
> 
> This patch does 2 things:
> 1. removes the loop in which PCI devices were added to groups and adds 
> explicit
> iommu_add_device() calls to add devices as soon as they get the iommu_table
> pointer assigned to them.
> 2. moves a bus notifier to powernv code in order to avoid conflict with the
> notifier from Freescale driver.
> 
> iommu_add_device() and iommu_del_device() are public now.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v8:
> * added the check for iommu_group!=NULL before removing device from a group as
> suggested by Wei Yang 
> 
> v2:
> * added a helper - set_iommu_table_base_and_group - which does
> set_iommu_table_base() and iommu_add_device()
> ---
>  arch/powerpc/include/asm/iommu.h|  9 +++
>  arch/powerpc/kernel/iommu.c | 41 
> +++--
>  arch/powerpc/platforms/powernv/pci-ioda.c   |  8 +++---
>  arch/powerpc/platforms/powernv/pci-p5ioc2.c |  2 +-
>  arch/powerpc/platforms/powernv/pci.c| 33 ++-
>  arch/powerpc/platforms/pseries/iommu.c  |  8 +++---
>  6 files changed, 55 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/iommu.h 
> b/arch/powerpc/include/asm/iommu.h
> index c34656a..19ad77f 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct
> iommu_table * tbl,
>   int nid);
>  extern void iommu_register_group(struct iommu_table *tbl,
>int pci_domain_number, unsigned long pe_num);
> +extern int iommu_add_device(struct device *dev); extern void
> +iommu_del_device(struct device *dev);
> +
> +static inline void set_iommu_table_base_and_group(struct device *dev,
> +   void *base)
> +{
> + set_iommu_table_base(dev, base);
> + iommu_add_device(dev);
> +}
> 
>  extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
>   struct scatterlist *sglist, int nelems, diff --git
> a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index
> b20ff17..15f8ca8 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tbl)  }
> EXPORT_SYMBOL_GPL(iommu_release_ownership);
> 
> -static int iommu_add_device(struct device *dev)
> +int iommu_add_device(struct device *dev)
>  {
>   struct iommu_table *tbl;
>   int ret = 0;
> @@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
> 
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(iommu_add_device);
> 
> -static void iommu_del_device(struct device *dev)
> +void iommu_del_device(struct device *dev)
>  {
>   iommu_group_remove_device(dev);
>  }
> -
> -static int iommu_bus_notifier(struct notifier_block *nb,
> -   unsigned long action, void *data)
> -{
> - struct device *dev = data;
> -
> - switch (action) {
> - case BUS_NOTIFY_ADD_DEVICE:
> - return iommu_add_device(dev);
> - case BUS_NOTIFY_DEL_DEVICE:
> - iommu_del_device(dev);
> - return 0;
> - default:
> - return 0;
> - }
> -}
> -
> -static struct notifier_block tce_iommu_bus_nb = {
> - .notifier_call = iommu_bus_notifier,
> -};
> -
> -static int __init tce_iommu_init(void)
> -{
> - struct pci_dev *pdev = NULL;
> -
> - BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> -
> - for_each_pci_dev(pdev)
> - iommu_add_device(&pdev->dev);
> -
> - bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> - return 

Re: [PATCH] sysfs: move assignment to be under lock in sysfs_remove_dir()

[Eric W. Biederman]

Linus Torvalds  writes:

> On Tue, Oct 29, 2013 at 5:39 PM, Eric W. Biederman
>  wrote:
>>
>> I don't have a strong feeling either way but how would that matter?
>> There is only ever one sd associated with a kobj.
>
> What does that matter? If you have multiple callers, they might try to
> free that one sd twice, since they could both see a non-NULL case.

>> And we better be under the sysfs_mutex when the assignment and and
>> sysfs_remove_dir are called.
>
> Not as far as I can tell. kobject_del() calls sysfs_remove_dir(), and
> I'm not seeing why that would be under the mutex.  The only locking I
> see is that sysfs_assoc_lock, which _isn't_ held for the reading of
> kobj->sd.
>
> Now, there may be other reasons for this all working (like the fact
> that only one user ever calls kobject_del() on any particular object,
> but it sure as hell isn't obvious. The fact that you seem to be
> confused about this only proves my point.

I never actually looked deeply into it, and I was working from several
year old memory and a quick skim of the patch when I asked the question.

The protection we have previous to this patch is that syfs_remove_dir is
only sane to call once.

Which makes the code that does:
if (!dir_sd)
return;
in __sysfs_remove_dir very suspicious.   I expect we want a
WARN_ON(!dir_sd);

But the entire directory removal process and working on sysfs stopped
being fun before I managed to get that cleaned up.  And unless I missed
something go by Tejun is going to go generalize this thing before this
bit gets cleaned up.  Sigh.

> Besides, the "design pattern" of having a lock for the assignment, but
> then reading the value without that lock seems to be all kinds of
> f*cking stupid, wouldn't you agree? I'm really not seeing how that
> could _ever_ be something you make excuses for in the first place.
> Even if there is some external locking (which, as far as I can tell,
> there is not), that would just raise the question as to what reason
> that spinlock has to exist at all.

I wasn't making excuses I was just trying to understand the reasoning
for this little patch flying through my inbox.

On an equally bizarre note.  I don't understand why we have a separate
spinlock there.  Looks...  Sigh.  We use a different lock from
everything as a premature optimization so that sysfs_remove_dir could be
modified to just take a sysfs_dirent, and all of the kobject handling
could be removed.

Sigh. It was never in my way and while I was working on the code that
there was a good locking reason for doing that silly thing.

> The code doesn't make any sense with the locking the way it is now. It
> might _work_, of course, but it sure as hell doesn't make sense.

In net I agree.

Eric





--
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] x86: Run checksumming in parallel accross multiple alu's

[Doug Ledford]

* Neil Horman  wrote:
> 3) The run times are proportionally larger, but still indicate that Parallel 
> ALU
> execution is hurting rather than helping, which is counter-intuitive.  I'm
> looking into it, but thought you might want to see these results in case
> something jumped out at you

So here's my theory about all of this.

I think that the original observation some years back was a fluke caused by
either a buggy CPU or a CPU design that is no longer used.

The parallel ALU design of this patch seems OK at first glance, but it means
that two parallel operations are both trying to set/clear both the overflow
and carry flags of the EFLAGS register of the *CPU* (not the ALU).  So, either
some CPU in the past had a set of overflow/carry flags per ALU and did some
sort of magic to make sure that the last state of those flags across multiple
ALUs that might have been used in parallelizing work were always in the CPU's
logical EFLAGS register, or the CPU has a buggy microcode that allowed two
ALUs to operate on data at the same time in situations where they would
potentially stomp on the carry/overflow flags of the other ALUs operations.

It's my theory that all modern CPUs have this behavior fixed, probably via a
microcode update, and so trying to do parallel ALU operations like this simply
has no effect because the CPU (rightly so) serializes the operations to keep
them from clobbering the overflow/carry flags of the other ALUs operations.

My additional theory then is that the reason you see a slowdown from this
patch is because the attempt to parallelize the ALU operation has caused
us to write a series of instructions that, once serialized, are non-optimal
and hinder smooth pipelining of the data (aka going 0*8, 2*8, 4*8, 6*8, 1*8,
3*8, 5*8, and 7*8 in terms of memory accesses is worse than doing them in
order, and since we aren't getting the parallel operation we want, this
is the net result of the patch).

It would explain things anyway.

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

[PATCH -next] skd: fix error return code in skd_pci_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return -ENOMEM in the skd construct error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/block/skd_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index ab17bff..1a8717f 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -5321,8 +5321,10 @@ static int skd_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
}
 
skdev = skd_construct(pdev);
-   if (skdev == NULL)
+   if (skdev == NULL) {
+   rc = -ENOMEM;
goto err_out_regions;
+   }
 
skd_pci_info(skdev, pci_str);
pr_info("(%s): %s 64bit\n", skd_name(skdev), pci_str);

--
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/5] fat: add fat_fallocate operation

[Namjae Jeon]

2013/10/30, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
 +  /* Release unwritten fallocated blocks on file release. */
 +  if (round_up(inode->i_size, sb->s_blocksize) <
 +  MSDOS_I(inode)->i_disksize && inode->i_nlink != 0)
 +  fat_truncate_blocks(inode, inode->i_size);
 +
truncate_inode_pages(&inode->i_data, 0);
if (!inode->i_nlink) {
inode->i_size = 0;
>
> [...]
>
>>> And inode->i_size should be ->mmu_private?
>> Sorry, I don't understand your question yet...
>> Could you elaborate more ?
>
> "if" part is checking "round_up(->i_size) < ->i_disksize", but I guess
> fallocate() truncation should be only needed if there is uninitialized
> data. So, I felt that part should check ->mmu_private and ->i_disksize.
Yes, right. I will change it as your points.
Thanks for review!!

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

linux-next: manual merge of the xen-tip tree with the tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in
arch/arm/include/asm/dma-mapping.h between commit 223016339ce7 ("ARM:
7805/1: mm: change max*pfn to include the physical offset of memory")
from the arm tree and commit 06e6295bcece ("arm: make SWIOTLB available")
from the xen-tip tree.

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

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

diff --cc arch/arm/include/asm/dma-mapping.h
index 863cd84eb1a2,f5945d4e4e9f..
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@@ -87,13 -98,42 +99,49 @@@ static inline dma_addr_t virt_to_dma(st
  }
  #endif
  
 +/* The ARM override for dma_max_pfn() */
 +static inline unsigned long dma_max_pfn(struct device *dev)
 +{
 +  return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);
 +}
 +#define dma_max_pfn(dev) dma_max_pfn(dev)
 +
+ static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+ {
+   unsigned int offset = paddr & ~PAGE_MASK;
+   return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
+ }
+ 
+ static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+ {
+   unsigned int offset = dev_addr & ~PAGE_MASK;
+   return __pfn_to_phys(dma_to_pfn(dev, dev_addr)) + offset;
+ }
+ 
+ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t 
size)
+ {
+   u64 limit, mask;
+   
+   if (dev->dma_mask)
+   mask = *dev->dma_mask;
+   else 
+   mask = dev->coherent_dma_mask;
+ 
+   if (mask == 0)
+   return 0;
+ 
+   limit = (mask + 1) & ~mask;
+   if (limit && size > limit)
+   return 0;
+ 
+   if ((addr | (addr + size - 1)) & ~mask)
+   return 0;
+ 
+   return 1;
+ }
+ 
+ static inline void dma_mark_clean(void *addr, size_t size) { }
+ 
  /*
   * DMA errors are defined by all-bits-set in the DMA address.
   */


pgpQR063Sd7kF.pgp
Description: PGP signature

[PATCH] of: set dma_mask to point to coherent_dma_mask

[Rob Herring]

From: Rob Herring 

Platform devices created by DT code don't initialize dma_mask pointer to
anything. Set it to coherent_dma_mask by default if the architecture
code has not set it.

Signed-off-by: Rob Herring 
---
I think this is at least part of what is needed to fix dma_mask issue
raised by Stefano [1]. Things should work AFAICT with just this, but
I suppose the xgmac driver needs to set the mask as well (not relying
on the default), but some pointing the dma_mask to a valid value is
needed first.

Rob

[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg528236.html

 drivers/of/platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index f6dcde2..fce088e 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -215,6 +215,8 @@ static struct platform_device 
*of_platform_device_create_pdata(
dev->archdata.dma_mask = 0xUL;
 #endif
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   if (!dev->dev.dma_mask)
+   dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
 
-- 
1.8.1.2

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

Re: [PATCH 1/3] dma: imx-sdma: Add ssi dual fifo script support

[Nicolin Chen]

Hi Sascha,

On Tue, Oct 29, 2013 at 02:51:43PM +0100, Sascha Hauer wrote:
> Look at drivers/dma/imx-sdma.c:
> 
> > /**
> >  * struct sdma_firmware_header - Layout of the firmware image
> >  *
> >  * @magic   "SDMA"
> >  * @version_major   increased whenever layout of struct
> >  * sdma_script_start_addrs
> >  *  changes.
> 
> Can you image why this firmware has a version field? Right, it's because
> it encodes the layout of struct sdma_script_start_addrs.
> 
> As the comment clearly states you have to *increase this field* when you
> add scripts.
> 
> Obviously you missed that, as the firmware on lkml posted recently
> shows:
> 
> > : 414d4453 0001 0001 001c SDMA
>  
>  Still '1'
> 
> > 0010: 0026 00b4 067a 0282 &...z...
> > 0020:     
> > 0030:     
> > 0040:   1a6a  j...
> > 0050: 02eb 18bb  0408 
> > 0060:  03c0   
> > 0070:  02ab  037b {...
> > 0080:   044c 046e L...n...
> > 0090:  1800   
> > 00a0:  1800 1862 1a16 b...
>   ^
>   new script addresses introduced
> 
> 
> > -#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V134
> > +#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V137
> 
> And no, this is not a bug. It's your firmware header that is buggy.
> 

I wasn't aware that the problem is far more complicated than I thought.
And thank you for telling me all this.

> What you need is:
> 
> #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2  37
> 
> You (you as a company, not you as a person) knew that it was me who
> created this firmware format. So it was absolutely unnecessary to create
> an incompatible firmware instead of dropping me a short note.
> 
> Please add a version check to the driver as necessary and provide a proper
> firmware.
> 

Just currently it's not easy for me to create a new proper firmware,
and I's been told that besides this version number, it also lacks a
decent license info. So may I just refine this patch as you suggested
to add a version check and add those new scripts first?

Thank you,
Nicolin Chen

> Sascha
> 
> -- 
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> 


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

Re: [PATCH 1/5] fat: add i_disksize to represent uninitialized size

[Namjae Jeon]

2013/10/30, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
 diff --git a/fs/fat/cache.c b/fs/fat/cache.c
 index 91ad9e1..37572c2 100644
 --- a/fs/fat/cache.c
 +++ b/fs/fat/cache.c
 @@ -329,10 +329,10 @@ int fat_bmap(struct inode *inode, sector_t
 sector,
 sector_t *phys,
return 0;

/*
 -   * ->mmu_private can access on only allocation path.
 +   * ->i_disksize can access on only allocation path.
 * (caller must hold ->i_mutex)
 */
 -  last_block = (MSDOS_I(inode)->mmu_private + (blocksize - 1))
 +  last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
>> blocksize_bits;
if (sector >= last_block)
return 0;
>>>
>>> Hm, bmap() ioctl returns between ->mmu_private and i_disksize? I'm not
>>> checking other FSes what does...
>> I added this code after checking such behaviour from ext4.
>
> OK. I will check with it. BTW, comment should say the both
> (i.e. ->mmu_private and ->i_disksize must under ->i_mutex).
Okay, I will update.
Thanks!
> --
> OGAWA Hirofumi 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] crypto: omap-aes: Fix CTR mode counter length

[Herbert Xu]

On Tue, Oct 29, 2013 at 05:37:38PM -0500, Joel Fernandes wrote:
> NIST vectors for CTR mode in testmgr.h assume the entire IV as the counter. To
> get correct results that match the output of these vectors, we need to set the
> counter length correctly.
> 
> Signed-off-by: Joel Fernandes 

Patch applied.  Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] hwrng: msm: Add PRNG support for MSM SoC's

[Herbert Xu]

On Fri, Oct 18, 2013 at 11:39:28AM -0700, Stephen Boyd wrote:
> On 10/15/13 07:11, Stanimir Varbanov wrote:
> > This adds a driver for hardware random number generator present
> > on Qualcomm MSM SoC's.
> >
> > Signed-off-by: Stanimir Varbanov 
> > ---
> 
> Reviewed-by: Stephen Boyd 

Both patches applied.  Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CRYPTO: omap-sham: Add missing modalias

[Herbert Xu]

On Sat, Oct 26, 2013 at 11:00:41PM +0200, Pali Rohár wrote:
> From: Joni Lapilainen 
> 
> Signed-off-by: Joni Lapilainen 

Patch applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] include/linux/wait.h: add ';' for the statement which missed it.

[Chen Gang]

Add ';' for the statement, or can not pass compiling. The related error
(for powerpc allmodconfig):

CC  block/blk-mq.o
  block/blk-mq.c: In function ‘blk_mq_queue_enter’:
  block/blk-mq.c:108:8: error: expected ‘;’ before ‘__ret’
  block/blk-mq.c:108:6: error: void value not ignored as it ought to be


Signed-off-by: Chen Gang 
---
 include/linux/wait.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 7f8caa5..fcc9680 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -768,7 +768,7 @@ do {
\
int __ret = 0;  \
if (!(condition))   \
__ret = __wait_event_interruptible_lock_irq(wq, \
-   condition, lock,)   \
+   condition, lock,);  \
__ret;  \
 })
 
-- 
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] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()

[Cong Wang]

On Tue, Oct 29, 2013 at 7:42 PM, David Miller  wrote:
> From: David Mackey 
> Date: Tue, 29 Oct 2013 15:16:38 -0700
>
>> Using dev_kfree_skb_any() will resolve the below issue when a
>> netconsole message is transmitted in an irq.
>  ...
>> Signed-off-by: David Mackey 
>
> This is absolutely not the correct fix.
>
> The netpoll facility must invoke ->poll() in an environment which
> is compatible, locking and interrupt/soft-interrupt wise, as that
> in which it is normally called.
>

Normally ->poll() is called in softirq context, while netpoll could
be called in any context depending on its caller.

Also, netpoll disables IRQ for tx, which is another difference.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/2] tps6507x-ts: Add DT support

[Manish Badarkhe]

Hi Mark,

Apologize for my late reply.


On Thu, Oct 24, 2013 at 10:57 PM, Mark Rutland  wrote:
>
> On Thu, Oct 24, 2013 at 06:05:53PM +0100, Manish Badarkhe wrote:
> > Hi Mark,
> >
> > Thank you for your reply.
> >
> > On Wed, Oct 23, 2013 at 10:15 PM, Mark Rutland  wrote:
> >
> > On Wed, Oct 23, 2013 at 05:28:52PM +0100, Manish Badarkhe wrote:
> > > Add device tree based support for TI's tps6507x touchscreen.
> > >
> > > Signed-off-by: Manish Badarkhe 
> > > ---
> > > Changes since V3:
> > >  - Rebased on top of Dmitry's changes
> > >  - Removed error handling for optional DT properties
> > >
> > > Changes since V2:
> > >  - Removed unnecessary code.
> > >  - Updated Documentation to provide proper names of
> > >devicetree properties.
> > >
> > > Changes since V1:
> > >  - Updated documentation to specify tps6507x as multifunctional
> > >device.
> > >  - return proper error value in absence of platform and DT
> > >data for touchscreen.
> > >  - Updated commit message.
> > >
> > > :100755 100755 8fffa3c... e1b9cfd... M
> > Documentation/devicetree/
> > bindings/mfd/tps6507x.txt
> > > :100644 100644 db604e0... 0cf0eb1... M
> > drivers/input/touchscreen/
> > tps6507x-ts.c
> > >  Documentation/devicetree/bindings/mfd/tps6507x.txt |   24 ++-
> > >  drivers/input/touchscreen/tps6507x-ts.c|   72
> > 
> > >  2 files changed, 67 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/
> > Documentation/devicetree/bindings/mfd/tps6507x.txt
> > > index 8fffa3c..e1b9cfd 100755
> > > --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> > > @@ -1,4 +1,8 @@
> > > -TPS6507x Power Management Integrated Circuit
> > > +TPS6507x Multifunctional Device.
> > > +
> > > +Features provided by TPS6507x:
> > > +1.Power Management Integrated Circuit.
> > > +2.Touch-Screen.
> > >
> > >  Required properties:
> > >  - compatible: "ti,tps6507x"
> > > @@ -23,6 +27,9 @@ Required properties:
> > > vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
> > > vindcdc3-supply  : VDCDC3 input.
> > > vldo1_2-supply   : VLDO1 and VLDO2 input.
> > > +- tsc: This node specifies touch screen data.
> >
> > This is a node, but is listed un "Required properties". That seems odd.
> >
> > When is it required?
> >
> > Why is the data under the tsc subnode? Why not directly under the main
> > node?
> >
> >
> > Yes, It seems odd to add a subnode properties here. I gone through other
> > documentation
> > for MFD devices and observed that separate documentation file is present for
> > sub node modules.
>
> I was trying to say that nodes != properties rather than that this should be
> split into separate files.
>

Ok, got it.I will modify documentation so that only properties comes
under "required
properties" section.

>
> >
> > TPS6507x is multifunctional device and having touch screen submodule. As it 
> > is
> > child node for
> > TPS6507x multifunctional device, I have created child node as "tsc".
> >
> >
> >
> > > + ti,poll-period : Time at which touch input is getting sampled in
> > ms.
> >
> > Is this for debounce? Other bindings have similar but differently named
> > properties.
> >
> >
> > This is not debounce time. This time is required for input poll devices.
> >
> >
> > Why is this necessary? Can the driver not choose a sane value?
> >
> >
> > poll-period is necessary to sample touch inputs. Driver will chose value
> > default poll
> > period if this value is not present. I was bit confused here, whether to add
> > this property
> > as optional or required. As with default period touch not achieve 
> > performance.
> > Can I make this property optional?
>
> Please elaborate. Why will the default period be sub-optimal? What's the
> tradeoff here?

Currently, default period and period passed from Device tree both
are same.I made an assumption here, if default period is less then
touch get sampled faster and report it to upper layer.As I am not I
will make this confirm with Texas instrument's engineers.

>
> >
> >
> > > + ti,min-pressure: Minimum pressure value to trigger touch.
> >
> > What type are these? Single (u32) cells?
> >
> > What units is ti,min-pressure in?
> >
> >
> > No, its a u16 cell. It is measured in ohm. Again default value for 
> > min-pressure
> > is available
> > in driver code. Can I make this property optional?
>
> Why is it a u16, it's very uncommon to have u16 properties.
>
> What _physical_ units is this in, and what order of magnitude? e.g. Pascals,
> millipascals.
>

I gone through data sheet but not able to find any units for this
pressure field.
As per data

Re: [RFC PATCH RESEND] fb: reorder the lock sequence to fix a potential lockdep

[Gu Zheng]

Hi Tomi, Jean,
How about this patch?

Thanks,
Gu


On 10/28/2013 02:01 PM, Gu Zheng wrote:

> Following commits:
> 50e244cc79 fb: rework locking to fix lock ordering on takeover
> e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
> 054430e773 fbcon: fix locking harder
> 
> reworked locking to fix related lock ordering on takeover, and introduced 
> console_lock
> into fbmem, but it seems that the new lock sequence(fb_info->lock ---> 
> console_lock)
> is against with the one in console_callback(console_lock ---> fb_info->lock), 
> and leads to
> a potential deadlock as following:
> [  601.079000] ==
> [  601.079000] [ INFO: possible circular locking dependency detected ]
> [  601.079000] 3.11.0 #189 Not tainted
> [  601.079000] ---
> [  601.079000] kworker/0:3/619 is trying to acquire lock:
> [  601.079000]  (&fb_info->lock){+.+.+.}, at: [] 
> lock_fb_info+0x26/0x60
> [  601.079000]
> but task is already holding lock:
> [  601.079000]  (console_lock){+.+.+.}, at: [] 
> console_callback+0x13/0x160
> [  601.079000]
> which lock already depends on the new lock.
> 
> [  601.079000]
> the existing dependency chain (in reverse order) is:
> [  601.079000]
> -> #1 (console_lock){+.+.+.}:
> [  601.079000][] lock_acquire+0xa1/0x140
> [  601.079000][] console_lock+0x77/0x80
> [  601.079000][] register_framebuffer+0x1d8/0x320
> [  601.079000][] efifb_probe+0x408/0x48f
> [  601.079000][] platform_drv_probe+0x43/0x80
> [  601.079000][] driver_probe_device+0x8b/0x390
> [  601.079000][] __driver_attach+0xab/0xb0
> [  601.079000][] bus_for_each_dev+0x5d/0xa0
> [  601.079000][] driver_attach+0x1e/0x20
> [  601.079000][] bus_add_driver+0x117/0x290
> [  601.079000][] driver_register+0x7a/0x170
> [  601.079000][] 
> __platform_driver_register+0x4a/0x50
> [  601.079000][] platform_driver_probe+0x1d/0xb0
> [  601.079000][] efifb_init+0x273/0x292
> [  601.079000][] do_one_initcall+0x102/0x1c0
> [  601.079000][] kernel_init_freeable+0x15d/0x1ef
> [  601.079000][] kernel_init+0xe/0xf0
> [  601.079000][] ret_from_fork+0x7c/0xb0
> [  601.079000]
> -> #0 (&fb_info->lock){+.+.+.}:
> [  601.079000][] __lock_acquire+0x1e18/0x1f10
> [  601.079000][] lock_acquire+0xa1/0x140
> [  601.079000][] mutex_lock_nested+0x7a/0x3b0
> [  601.079000][] lock_fb_info+0x26/0x60
> [  601.079000][] fbcon_blank+0x29b/0x2e0
> [  601.079000][] do_blank_screen+0x1d8/0x280
> [  601.079000][] console_callback+0x64/0x160
> [  601.079000][] process_one_work+0x1f5/0x540
> [  601.079000][] worker_thread+0x11c/0x370
> [  601.079000][] kthread+0xed/0x100
> [  601.079000][] ret_from_fork+0x7c/0xb0
> [  601.079000]
> other info that might help us debug this:
> 
> [  601.079000]  Possible unsafe locking scenario:
> 
> [  601.079000]CPU0CPU1
> [  601.079000]
> [  601.079000]   lock(console_lock);
> [  601.079000]lock(&fb_info->lock);
> [  601.079000]lock(console_lock);
> [  601.079000]   lock(&fb_info->lock);
> [  601.079000]
>  *** DEADLOCK ***
> 
> so we reorder the lock sequence the same as it in console_callback() to
> avoid this issue.
> Not very sure this change is suitable, any comments is welcome.
> 
> Signed-off-by: Gu Zheng 
> ---
>  drivers/video/fbmem.c |   50 +++-
>  1 files changed, 32 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index dacaf74..010d191 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1108,14 +1108,16 @@ static long do_fb_ioctl(struct fb_info *info, 
> unsigned int cmd,
>   case FBIOPUT_VSCREENINFO:
>   if (copy_from_user(&var, argp, sizeof(var)))
>   return -EFAULT;
> - if (!lock_fb_info(info))
> - return -ENODEV;
>   console_lock();
> + if (!lock_fb_info(info)) {
> + console_unlock();
> + return -ENODEV;
> + }
>   info->flags |= FBINFO_MISC_USEREVENT;
>   ret = fb_set_var(info, &var);
>   info->flags &= ~FBINFO_MISC_USEREVENT;
> - console_unlock();
>   unlock_fb_info(info);
> + console_unlock();
>   if (!ret && copy_to_user(argp, &var, sizeof(var)))
>   ret = -EFAULT;
>   break;
> @@ -1144,12 +1146,14 @@ static long do_fb_ioctl(struct fb_info *info, 
> unsigned int cmd,
>   case FBIOPAN_DISPLAY:
>   if (copy_from_user(&var, argp, sizeof(var)))
>   return -EFAULT;
> -  

Re: [PATCH V2 2/2] sched: Remove un-necessary iteration over sched domains to update nr_busy_cpus

[Preeti U Murthy]

The changelog has missed mentioning the introduction of sd_asym per_cpu sched 
domain.
Apologies for this. The patch with the changelog including mention of sd_asym is
pasted below.

Regards
Preeti U Murthy

---

sched: Remove un-necessary iteration over sched domains to update nr_busy_cpus

From: Preeti U Murthy 

nr_busy_cpus parameter is used by nohz_kick_needed() to find out the number
of busy cpus in a sched domain which has SD_SHARE_PKG_RESOURCES flag set.
Therefore instead of updating nr_busy_cpus at every level of sched domain,
since it is irrelevant, we can update this parameter only at the parent
domain of the sd which has this flag set. Introduce a per-cpu parameter
sd_busy which represents this parent domain.

In nohz_kick_needed() we directly query the nr_busy_cpus parameter
associated with the groups of sd_busy.

By associating sd_busy with the highest domain which has
SD_SHARE_PKG_RESOURCES flag set, we cover all lower level domains which could
have this flag set and trigger nohz_idle_balancing if any of the levels have
more than one busy cpu.

sd_busy is irrelevant for asymmetric load balancing. However sd_asym has been
introduced to represent the highest sched domain which has SD_ASYM_PACKING flag 
set
so that it can be queried directly when required.

While we are at it, we might as well change the nohz_idle parameter to be
updated at the sd_busy domain level alone and not the base domain level of a 
CPU.
This will unify the concept of busy cpus at just one level of sched domain
where it is currently used.

Signed-off-by: Preeti U Murthy
---
 kernel/sched/core.c  |6 ++
 kernel/sched/fair.c  |   38 --
 kernel/sched/sched.h |2 ++
 3 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..e6a6244 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5271,6 +5271,8 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
 DEFINE_PER_CPU(int, sd_llc_size);
 DEFINE_PER_CPU(int, sd_llc_id);
 DEFINE_PER_CPU(struct sched_domain *, sd_numa);
+DEFINE_PER_CPU(struct sched_domain *, sd_busy);
+DEFINE_PER_CPU(struct sched_domain *, sd_asym);
 
 static void update_top_cache_domain(int cpu)
 {
@@ -5282,6 +5284,7 @@ static void update_top_cache_domain(int cpu)
if (sd) {
id = cpumask_first(sched_domain_span(sd));
size = cpumask_weight(sched_domain_span(sd));
+   rcu_assign_pointer(per_cpu(sd_busy, cpu), sd->parent);
}
 
rcu_assign_pointer(per_cpu(sd_llc, cpu), sd);
@@ -5290,6 +5293,9 @@ static void update_top_cache_domain(int cpu)
 
sd = lowest_flag_domain(cpu, SD_NUMA);
rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
+
+   sd = highest_flag_domain(cpu, SD_ASYM_PACKING);
+   rcu_assign_pointer(per_cpu(sd_asym, cpu), sd);
 }
 
 /*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e9c9549..8602b2c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6515,16 +6515,16 @@ static inline void nohz_balance_exit_idle(int cpu)
 static inline void set_cpu_sd_state_busy(void)
 {
struct sched_domain *sd;
+   int cpu = smp_processor_id();
 
rcu_read_lock();
-   sd = rcu_dereference_check_sched_domain(this_rq()->sd);
+   sd = rcu_dereference(per_cpu(sd_busy, cpu));
 
if (!sd || !sd->nohz_idle)
goto unlock;
sd->nohz_idle = 0;
 
-   for (; sd; sd = sd->parent)
-   atomic_inc(&sd->groups->sgp->nr_busy_cpus);
+   atomic_inc(&sd->groups->sgp->nr_busy_cpus);
 unlock:
rcu_read_unlock();
 }
@@ -6532,16 +6532,16 @@ unlock:
 void set_cpu_sd_state_idle(void)
 {
struct sched_domain *sd;
+   int cpu = smp_processor_id();
 
rcu_read_lock();
-   sd = rcu_dereference_check_sched_domain(this_rq()->sd);
+   sd = rcu_dereference(per_cpu(sd_busy, cpu));
 
if (!sd || sd->nohz_idle)
goto unlock;
sd->nohz_idle = 1;
 
-   for (; sd; sd = sd->parent)
-   atomic_dec(&sd->groups->sgp->nr_busy_cpus);
+   atomic_dec(&sd->groups->sgp->nr_busy_cpus);
 unlock:
rcu_read_unlock();
 }
@@ -6748,6 +6748,8 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
 {
unsigned long now = jiffies;
struct sched_domain *sd;
+   struct sched_group_power *sgp;
+   int nr_busy;
 
if (unlikely(idle_cpu(cpu)))
return 0;
@@ -6773,22 +6775,22 @@ static inline int nohz_kick_needed(struct rq *rq, int 
cpu)
goto need_kick;
 
rcu_read_lock();
-   for_each_domain(cpu, sd) {
-   struct sched_group *sg = sd->groups;
-   struct sched_group_power *sgp = sg->sgp;
-   int nr_busy = atomic_read(&sgp->nr_busy_cpus);
+   sd = rcu_dereference(per_cpu(sd_busy, cpu));
 
-   if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
-  

Re: [PATCH 1/2] spi: add Intel Mid SSP driver

[Ning Li]

On Tue, 29 Oct 2013 13:18:37 -0700
David Cohen  wrote:

> Hi Felipe,
> 
> On 10/29/2013 11:31 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Oct 29, 2013 at 11:05:49AM -0700, David Cohen wrote:
> >> diff --git a/drivers/spi/spi-intel-mid-ssp.c
> >> b/drivers/spi/spi-intel-mid-ssp.c new file mode 100644
> >> index 000..b3b9fe8
> >> --- /dev/null
> >> +++ b/drivers/spi/spi-intel-mid-ssp.c
> >> @@ -0,0 +1,1506 @@
> >> +/*
> >> + * spi-intel-mid-ssp.c
> >> + * This driver supports Bulverde SSP core used on Intel MID
> >> platforms
> >> + * It supports SSP of Moorestown & Medfield platforms and handles
> >> clock
> >> + * slave & master modes.
> >> + *
> >> + * Copyright (c) 2013, Intel Corporation.
> >> + * Contacts: Ning Li 
> >> + * David Cohen 
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify it
> >> + * under the terms and conditions of the GNU General Public
> >> License,
> >> + * version 2, as published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope it will be useful, but
> >> WITHOUT
> >> + * ANY WARRANTY; without even the implied warranty of
> >> MERCHANTABILITY or
> >> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> >> License for
> >> + * more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public
> >> License along with
> >> + * this program; if not, write to the Free Software Foundation,
> >> Inc.,
> >> + * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
> >> + *
> >> + */
> >> +
> >> +/*
> >> + * Note:
> >> + *
> >> + * Supports DMA and non-interrupt polled transfers.
> >> + *
> >> + */
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +#define DRIVER_NAME "intel_mid_ssp_spi_unified"
> >> +
> >> +static int ssp_timing_wr;
> >
> > this will prevent multiple instances of the same driver.
> 
> Yeah. I'll fix it.
> 
> >
> >> +#ifdef DUMP_RX
> >> +static void dump_trailer(const struct device *dev, char *buf, int
> >> len, int sz) +{
> >> +  int tlen1 = (len < sz ? len : sz);
> >> +  int tlen2 =  ((len - sz) > sz) ? sz : (len - sz);
> >> +  unsigned char *p;
> >> +  static char msg[MAX_SPI_TRANSFER_SIZE];
> >> +
> >> +  memset(msg, '\0', sizeof(msg));
> >> +  p = buf;
> >> +  while (p < buf + tlen1)
> >> +  sprintf(msg, "%s%02x", msg, (unsigned int)*p++);
> >> +
> >> +  if (tlen2 > 0) {
> >> +  sprintf(msg, "%s .", msg);
> >> +  p = (buf+len) - tlen2;
> >> +  while (p < buf + len)
> >> +  sprintf(msg, "%s%02x", msg, (unsigned
> >> int)*p++);
> >> +  }
> >> +
> >> +  dev_info(dev, "DUMP: %p[0:%d ... %d:%d]:%s", buf, tlen1 -
> >> 1,
> >> + len-tlen2, len - 1, msg);
> >> +}
> >> +#endif
> >
> > either move this to debugfs or stub the function out ifndef DUMP_RX,
> > then you don't need the ifdefs when calling it.
> 
> Agreed.
> 
> >
> >> +static inline u8 ssp_cfg_get_mode(u8 ssp_cfg)
> >> +{
> >> +  if (intel_mid_identify_cpu() ==
> >> INTEL_MID_CPU_CHIP_TANGIER)
> >
> > instead, couldn't you use driver data to pass some flags to the
> > driver ? I can't see intel_mid_identify_cpu and having drivers
> > depend on arch-specific code is usually a bad practice.
> 
> I'll find a way to get rid of this.
> 
> >
> >> +  return (ssp_cfg) & 0x03;
> >> +  else
> >
> > else isn't needed here
> 
> Agreed.
> 
> >
> >> +static inline u32 is_tx_fifo_empty(struct ssp_drv_context *sspc)
> >> +{
> >> +  u32 sssr;
> >
> > blank line here would aid readability
> >
> 
> Agreed.
> 
> >> +  sssr = read_SSSR(sspc->ioaddr);
> >> +  if ((sssr & SSSR_TFL_MASK) || (sssr & SSSR_TNF) == 0)
> >> +  return 0;
> >> +  else
> >
> > else isn't necessary
> 
> Agreed.
> 
> >
> >> +static inline u32 is_rx_fifo_empty(struct ssp_drv_context *sspc)
> >> +{
> >> +  return ((read_SSSR(sspc->ioaddr) & SSSR_RNE) == 0);
> >
> > you don't need the outter parenthesis here, GCC should've warned
> > you, even.
> 
> Yeah. checkpatch supposed to warn too. I'll fix it.
> 
> >
> >> +static inline void disable_interface(struct ssp_drv_context *sspc)
> >> +{
> >> +  void *reg = sspc->ioaddr;
> >
> > blank line here
> >
> >> +  write_SSCR0(read_SSCR0(reg) & ~SSCR0_SSE, reg);
> >> +}
> >> +
> >> +static inline void disable_triggers(struct ssp_drv_context *sspc)
> >> +{
> >> +  void *reg = sspc->ioaddr;
> >
> > and here...
> >
> >> +  write_SSCR1(read_SSCR1(reg) & ~sspc->cr1_sig, reg);
> >> +}
> >> +
> >> +
> >> +static void flush(struct ssp_drv_context *sspc)
> >> +{
> >> +  void *reg = sspc->ioaddr;
> >> +  u32 i = 0;
> >> +
> >> +  /* If the transmit fifo is not empty, reset the
> >> interface. */
> >> +  if (!is_tx_fifo_empty(sspc)) {
> >> +  dev_err(&sspc->pdev->dev, "TX FIFO not empty.
> >> 

Re: [PATCH] perf: fix two warning in bench/numa

[Wei Yang]

Dear maintainer,

Is this one accepted or droped?
Or I missed the right person?

On Sun, Sep 22, 2013 at 04:49:24PM +0800, Wei Yang wrote:
>There two warnings in bench/numa, when buiding this on 32-bit machine. 
>
>The warning output is attached:
>
>bench/numa.c:1113:20: error: comparison between signed and unsigned integer 
>expressions [-Werror=sign-compare]
>bench/numa.c:1161:6: error: format ‘%lx’ expects argument of t'long unsigned 
>int’, but argument 5 has type ‘u64’ [-Werror=format]
>
>This patch fixs these two warnings.
>
>Signed-off-by: Wei Yang 
>---
> tools/perf/bench/numa.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
>index 30d1c32..a73c4ed 100644
>--- a/tools/perf/bench/numa.c
>+++ b/tools/perf/bench/numa.c
>@@ -1110,7 +1110,7 @@ static void *worker_thread(void *__tdata)
>   /* Check whether our max runtime timed out: */
>   if (g->p.nr_secs) {
>   timersub(&stop, &start0, &diff);
>-  if (diff.tv_sec >= g->p.nr_secs) {
>+  if (diff.tv_sec >= (time_t)g->p.nr_secs) {
>   g->stop_work = true;
>   break;
>   }
>@@ -1157,7 +1157,7 @@ static void *worker_thread(void *__tdata)
>   runtime_ns_max += diff.tv_usec * 1000;
>
>   if (details >= 0) {
>-  printf(" #%2d / %2d: %14.2lf nsecs/op [val: 
>%016lx]\n",
>+  printf(" #%2d / %2d: %14.2lf nsecs/op [val: 
>%016"PRIu64"]\n",
>   process_nr, thread_nr, runtime_ns_max / 
> bytes_done, val);
>   }
>   fflush(stdout);
>-- 
>1.7.5.4

-- 
Richard Yang
Help you, Help me

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

[PATCH V2 2/2] sched: Remove un-necessary iteration over sched domains to update nr_busy_cpus

[Preeti U Murthy]

nr_busy_cpus parameter is used by nohz_kick_needed() to find out the number
of busy cpus in a sched domain which has SD_SHARE_PKG_RESOURCES flag set.
Therefore instead of updating nr_busy_cpus at every level of sched domain,
since it is irrelevant, we can update this parameter only at the parent
domain of the sd which has this flag set. Introduce a per-cpu parameter
sd_busy which represents this parent domain.

In nohz_kick_needed() we directly query the nr_busy_cpus parameter
associated with the groups of sd_busy.

By associating sd_busy with the highest domain which has
SD_SHARE_PKG_RESOURCES flag set, we cover all lower level domains which could
have this flag set and trigger nohz_idle_balancing if any of the levels have
more than one busy cpu.

sd_busy is irrelevant for asymmetric load balancing.

While we are at it, we might as well change the nohz_idle parameter to be
updated at the sd_busy domain level alone and not the base domain level of a 
CPU.
This will unify the concept of busy cpus at just one level of sched domain
where it is currently used.

Signed-off-by: Preeti U Murthy
---

 kernel/sched/core.c  |6 ++
 kernel/sched/fair.c  |   38 --
 kernel/sched/sched.h |2 ++
 3 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..e6a6244 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5271,6 +5271,8 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
 DEFINE_PER_CPU(int, sd_llc_size);
 DEFINE_PER_CPU(int, sd_llc_id);
 DEFINE_PER_CPU(struct sched_domain *, sd_numa);
+DEFINE_PER_CPU(struct sched_domain *, sd_busy);
+DEFINE_PER_CPU(struct sched_domain *, sd_asym);
 
 static void update_top_cache_domain(int cpu)
 {
@@ -5282,6 +5284,7 @@ static void update_top_cache_domain(int cpu)
if (sd) {
id = cpumask_first(sched_domain_span(sd));
size = cpumask_weight(sched_domain_span(sd));
+   rcu_assign_pointer(per_cpu(sd_busy, cpu), sd->parent);
}
 
rcu_assign_pointer(per_cpu(sd_llc, cpu), sd);
@@ -5290,6 +5293,9 @@ static void update_top_cache_domain(int cpu)
 
sd = lowest_flag_domain(cpu, SD_NUMA);
rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
+
+   sd = highest_flag_domain(cpu, SD_ASYM_PACKING);
+   rcu_assign_pointer(per_cpu(sd_asym, cpu), sd);
 }
 
 /*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e9c9549..8602b2c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6515,16 +6515,16 @@ static inline void nohz_balance_exit_idle(int cpu)
 static inline void set_cpu_sd_state_busy(void)
 {
struct sched_domain *sd;
+   int cpu = smp_processor_id();
 
rcu_read_lock();
-   sd = rcu_dereference_check_sched_domain(this_rq()->sd);
+   sd = rcu_dereference(per_cpu(sd_busy, cpu));
 
if (!sd || !sd->nohz_idle)
goto unlock;
sd->nohz_idle = 0;
 
-   for (; sd; sd = sd->parent)
-   atomic_inc(&sd->groups->sgp->nr_busy_cpus);
+   atomic_inc(&sd->groups->sgp->nr_busy_cpus);
 unlock:
rcu_read_unlock();
 }
@@ -6532,16 +6532,16 @@ unlock:
 void set_cpu_sd_state_idle(void)
 {
struct sched_domain *sd;
+   int cpu = smp_processor_id();
 
rcu_read_lock();
-   sd = rcu_dereference_check_sched_domain(this_rq()->sd);
+   sd = rcu_dereference(per_cpu(sd_busy, cpu));
 
if (!sd || sd->nohz_idle)
goto unlock;
sd->nohz_idle = 1;
 
-   for (; sd; sd = sd->parent)
-   atomic_dec(&sd->groups->sgp->nr_busy_cpus);
+   atomic_dec(&sd->groups->sgp->nr_busy_cpus);
 unlock:
rcu_read_unlock();
 }
@@ -6748,6 +6748,8 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
 {
unsigned long now = jiffies;
struct sched_domain *sd;
+   struct sched_group_power *sgp;
+   int nr_busy;
 
if (unlikely(idle_cpu(cpu)))
return 0;
@@ -6773,22 +6775,22 @@ static inline int nohz_kick_needed(struct rq *rq, int 
cpu)
goto need_kick;
 
rcu_read_lock();
-   for_each_domain(cpu, sd) {
-   struct sched_group *sg = sd->groups;
-   struct sched_group_power *sgp = sg->sgp;
-   int nr_busy = atomic_read(&sgp->nr_busy_cpus);
+   sd = rcu_dereference(per_cpu(sd_busy, cpu));
 
-   if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
-   goto need_kick_unlock;
+   if (sd) {
+   sgp = sd->groups->sgp;
+   nr_busy = atomic_read(&sgp->nr_busy_cpus);
 
-   if (sd->flags & SD_ASYM_PACKING
-   && (cpumask_first_and(nohz.idle_cpus_mask,
- sched_domain_span(sd)) < cpu))
+   if (nr_busy > 1)
goto need_kick_unlock;
-
-   if (!(sd->flags & (SD_SHARE_PKG_RESOURCES | SD_ASYM_PACKING)))
-

[PATCH V2 1/2] sched: Fix asymmetric scheduling for POWER7

[Preeti U Murthy]

From: Vaidyanathan Srinivasan 

Asymmetric scheduling within a core is a scheduler loadbalancing
feature that is triggered when SD_ASYM_PACKING flag is set.  The goal
for the load balancer is to move tasks to lower order idle SMT threads
within a core on a POWER7 system.

In nohz_kick_needed(), we intend to check if our sched domain (core)
is completely busy or we have idle cpu.

The following check for SD_ASYM_PACKING:

(cpumask_first_and(nohz.idle_cpus_mask, sched_domain_span(sd)) < cpu)

already covers the case of checking if the domain has an idle cpu,
because cpumask_first_and() will not yield any set bits if this domain
has no idle cpu.

Hence, nr_busy check against group weight can be removed.

Reported-by: Michael Neuling 
Signed-off-by: Vaidyanathan Srinivasan 
Signed-off-by: Preeti U Murthy 
Tested-by: Michael Neuling 
---

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

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 813dd61..e9c9549 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6781,7 +6781,7 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
goto need_kick_unlock;
 
-   if (sd->flags & SD_ASYM_PACKING && nr_busy != sg->group_weight
+   if (sd->flags & SD_ASYM_PACKING
&& (cpumask_first_and(nohz.idle_cpus_mask,
  sched_domain_span(sd)) < cpu))
goto need_kick_unlock;

--
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 0/2] sched: Cleanups,fixes in nohz_kick_needed()

[Preeti U Murthy]

Changes from V1:https://lkml.org/lkml/2013/10/21/248

1. Swapped the order of PATCH1 and PATCH2 in V1 so as to not mess with the
nr_busy_cpus parameter computation during asymmetric balancing, while fixing
it.

2. nohz_busy_cpus parameter is to be updated and queried at only one level of
the sched domain-sd_busy where it is relevant.

3. Introduce sd_asym to represent the sched domain where asymmetric load
balancing has to be done.
---

Preeti U Murthy (1):
  sched: Remove un-necessary iteration over sched domains to update 
nr_busy_cpus

Vaidyanathan Srinivasan (1):
  sched: Fix asymmetric scheduling for POWER7


 kernel/sched/core.c  |6 ++
 kernel/sched/fair.c  |   38 --
 kernel/sched/sched.h |2 ++
 3 files changed, 28 insertions(+), 18 deletions(-)

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

Re: [PATCH] scripts/checkkconfig.py: find unused Kconfig parameters

[Michael Opdenacker]

Hi Yann,

Thank you for your review!

On 10/29/2013 07:06 PM, Yann E. MORIN wrote:

> I guess all these grep spawning are what makes it slow.
>
> I wonder if it would not be possible to invert the loop (in pseudo
> Python code):
>
> for f in all_interesting_files:
> read f in memory
> for s in all_symbols:
> if symbol is in f:
> remove f from all_symbols
> break the inner-most loop
You probably meant "remove s from all_symbols", but I got it.
>
> This way:
>   - you scan the tree only once
>   - as soon as a symbol is matched, it is removed, thus decreasing
> the amount of checks done in further loops.
This sounds like a very good idea, thanks! I hope to have time to
implement a mix of it and Michal's proposal later this week, or at least
next week.

Thanks again,

Michael.

-- 
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098

--
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 net 2/3] r8152: modify the tx flow

[David Miller]

From: hayeswang 
Date: Wed, 30 Oct 2013 11:03:55 +0800

>  David Miller [mailto:da...@davemloft.net] 
>> Sent: Wednesday, October 30, 2013 5:50 AM
>> To: Hayeswang
>> Cc: net...@vger.kernel.org; nic_swsd; 
>> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
>> Subject: Re: [PATCH net 2/3] r8152: modify the tx flow
>> 
>> From: Hayes Wang 
>> Date: Tue, 29 Oct 2013 15:56:16 +0800
>> 
>> > Support stopping and waking tx queue. The maximum tx queue length
>> > is 60.
>> 
>> What is so special about the number 60?  It seems arbitrary, and if
>> it isn't arbitrary you haven't described why this value was choosen.
> 
> The value is arbitrary. I think it is better to stop tx when
> queuing many packets, otherwise all the available memory may
> be used for tx skb. The queue length could be any value or
> unlimited if the memory is enough. Should I remove it?

You should at least pick some value that you have analyzed in some
way.  We've done a lot of work to strongly limit the amount of SKB
data which sits in device queues on transmit, and what you're doing
here works against to those goals.

Ideally you should pick a value which is sufficient to meet two
goals at the same time:

1) With constant transmit traffic coming from the networking stack,
   the device never starves for new transmit data to send.

2) We never queue up more traffic than we need to satisfy requirement
   #1.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 1/5] ARM: add basic support for Trusted Foundations

[Alex Courbot]

On 10/29/2013 05:12 PM, Kumar Gala wrote:


On Oct 28, 2013, at 7:25 PM, Mark Rutland wrote:


On Mon, Oct 28, 2013 at 11:31:36PM +, Tomasz Figa wrote:

On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:

On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:

On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:

Trusted Foundations is a TrustZone-based secure monitor for ARM that
can be invoked using the same SMC-based API on all supported
platforms. This patch adds initial basic support for Trusted
Foundations using the ARM firmware API. Current features are limited
to the ability to boot secondary processors.

Note: The API followed by Trusted Foundations does *not* follow the
SMC
calling conventions. It has nothing to do with PSCI neither and is
only
relevant to devices that use Trusted Foundations (like most
Tegra-based
retail devices).

Signed-off-by: Alexandre Courbot 
Reviewed-by: Tomasz Figa 
Reviewed-by: Stephen Warren 
---
.../arm/firmware/tl,trusted-foundations.txt| 20 ++
.../devicetree/bindings/vendor-prefixes.txt|  1 +
arch/arm/Kconfig   |  2 +
arch/arm/Makefile  |  1 +
arch/arm/firmware/Kconfig  | 28 
arch/arm/firmware/Makefile |  1 +
arch/arm/firmware/trusted_foundations.c| 79
++ arch/arm/include/asm/trusted_foundations.h
  | 67 ++ 8 files changed, 199 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundatio
ns.txt create mode 100644 arch/arm/firmware/Kconfig
create mode 100644 arch/arm/firmware/Makefile
create mode 100644 arch/arm/firmware/trusted_foundations.c
create mode 100644 arch/arm/include/asm/trusted_foundations.h

diff --git
a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
ions.txt
b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
ions.txt new file mode 100644
index 000..2ec75c9
--- /dev/null
+++
b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
ions.txt @@ -0,0 +1,20 @@
+Trusted Foundations
+---
+
+Boards that use the Trusted Foundations secure monitor can signal
its
+presence by declaring a node compatible with
"tl,trusted-foundations"
+under the /firmware/ node
+
+Required properties:
+- compatible : "tl,trusted-foundations"
+- version-major : major version number of Trusted Foundations
firmware
+- version-minor: minor version number of Trusted Foundations
firmware


vendor prefix version.


Are you saying he should use tl,version-major tl,version-minor? For
bindings that are already vendor-specific we haven't (on ARM) asked for
vendor prefix on properties. It doesn't mean that we should keep going
down that route though, so I'm just asking for clarification for my own
edification. :)


This is a good question. We should decide what the right thing (TM) is and
write it down. I, on the contrary, was convinced that it's the way Kumar
says.


The impression I got was that properties should be prefixed when they're
extremely vendor-specific and could clash with a more generic property. I'm not
sure that firmware will ever have a generic binding given the variation even in
the set of implemented functionality.

I would imagine that there are many ways different firmwares might be
versioned, and I can't see version-major or version-minor clashing with a
generic property we might add later. However prefixing would not be harmful, so
I'm not opposed to it if others want that.

Another option would be to support a fallback compatible list (e.g.
"tl,trusted-foundations-${MAJOR}-${MINOR}", "tl,trusted-foundations"), and get
versioning information from there. Given that could be painful to handle I
don't want to force it if not required.

Thanks,
Mark.


I'm of the opinion that making all vendor specific properties vendor prefixed 
is the easiest rule of thumb and leaves no gray area to have to argue about.


All good points, I will vendor-prefix these properties.

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] scripts/checkkconfig.py: find unused Kconfig parameters

[Michael Opdenacker]

Hi Michal,

Thank you very much for your reviews!

On 10/25/2013 03:45 PM, Michal Marek wrote:

> You can process Kconfig files and source files separately. And you can
> speed up the script a lot, if you simply record all CONFIG_* strings
> found in the sources, and then compare this to the set of config options
> defined in Kconfig. Then you can also easily implement the opposite
> check, which is currently done by scripts/checkkconfigsymbols.sh.
I like the idea. CONFIG_* strings at least should be easy to identify in
the source code indeed. I'll also have to find all the parameters
referred to in Kconfig files (namely as dependencies), but this should
be worth the effort.

The whole program will be a bit more complex, but it will be orders of
magnitude faster!

Thanks again,

Michael.

-- 
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098

--
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] tpm/tpm_i2c_stm_st33: Check return code of get_burstcount (fix CID: 986658)

[Greg KH]

On Wed, Oct 30, 2013 at 01:42:11AM +0100, Peter Hüwe wrote:
> Hi Greg,
> > > 
> > > CID: 986658
> > What is this field for?
> 
> That's the scan id in the coverity database.
> If you think that's just noise I can leave it out.

It's noise as not everyone can see it or make anything out of it, so
please don't include it.

thanks,

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

RE: [PATCH net 2/3] r8152: modify the tx flow

[hayeswang]

 David Miller [mailto:da...@davemloft.net] 
> Sent: Wednesday, October 30, 2013 5:50 AM
> To: Hayeswang
> Cc: net...@vger.kernel.org; nic_swsd; 
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH net 2/3] r8152: modify the tx flow
> 
> From: Hayes Wang 
> Date: Tue, 29 Oct 2013 15:56:16 +0800
> 
> > Support stopping and waking tx queue. The maximum tx queue length
> > is 60.
> 
> What is so special about the number 60?  It seems arbitrary, and if
> it isn't arbitrary you haven't described why this value was choosen.

The value is arbitrary. I think it is better to stop tx when
queuing many packets, otherwise all the available memory may
be used for tx skb. The queue length could be any value or
unlimited if the memory is enough. Should I remove it?

> I've asked you politely last time around to significantly improve
> the quality of your commit messages, and you haven't done this at
> all.

I thought you indicated the last patch only and the others are clear enough.
I would improve them.

> I'm not applying any of these patches until your commit messages
> properly describe your changes completely.
> 

--
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: cma: free cma page to buddy instead of being cpu hot page

[Minchan Kim]

Hello,

On Tue, Oct 29, 2013 at 11:02:30PM +0800, Zhang Mingjun wrote:
> On Tue, Oct 29, 2013 at 8:27 PM, Mel Gorman  wrote:
> 
> > On Tue, Oct 29, 2013 at 07:49:30PM +0800, Zhang Mingjun wrote:
> > > On Tue, Oct 29, 2013 at 5:33 PM, Mel Gorman  wrote:
> > >
> > > > On Mon, Oct 28, 2013 at 07:42:49PM +0800, zhang.mingjun@linaro.orgwrote:
> > > > > From: Mingjun Zhang 
> > > > >
> > > > > free_contig_range frees cma pages one by one and MIGRATE_CMA pages
> > will
> > > > be
> > > > > used as MIGRATE_MOVEABLE pages in the pcp list, it causes unnecessary
> > > > > migration action when these pages reused by CMA.
> > > > >
> > > > > Signed-off-by: Mingjun Zhang 
> > > > > ---
> > > > >  mm/page_alloc.c |3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > > > index 0ee638f..84b9d84 100644
> > > > > --- a/mm/page_alloc.c
> > > > > +++ b/mm/page_alloc.c
> > > > > @@ -1362,7 +1362,8 @@ void free_hot_cold_page(struct page *page, int
> > > > cold)
> > > > >* excessively into the page allocator
> > > > >*/
> > > > >   if (migratetype >= MIGRATE_PCPTYPES) {
> > > > > - if (unlikely(is_migrate_isolate(migratetype))) {
> > > > > + if (unlikely(is_migrate_isolate(migratetype))
> > > > > + || is_migrate_cma(migratetype))
> > > > >   free_one_page(zone, page, 0, migratetype);
> > > > >   goto out;
> > > >
> > > > This slightly impacts the page allocator free path for a marginal gain
> > > > on CMA which are relatively rare allocations. There is no obvious
> > > > benefit to this patch as I expect CMA allocations to flush the PCP
> > lists
> > > >
> > > how about keeping the migrate type of CMA page block as MIGRATE_ISOLATED
> > > after
> > > the alloc_contig_range , and undo_isolate_page_range at the end of
> > > free_contig_range?
> >
> > It would move the cost to the CMA paths so I would complain less. Bear
> > in mind as well that forcing everything to go through free_one_page()
> > means that every free goes through the zone lock. I doubt you have any
> > machine large enough but it is possible for simultaneous CMA allocations
> > to now contend on the zone lock that would have been previously fine.
> > Hence, I'm interesting in knowing the underlying cause of the problem you
> > are experiencing.
> >
> > my platform uses CMA but disabled CMA's migration func by del MIGRATE_CMA
> in fallbacks[MIGRATE_MOVEABLE]. But I find CMA pages can still used by

In that case, why do you want to use CMA?
It's almost same with resreved memory.

> pagecache or page fault page request from PCP list and cma allocation has to
> migrate these page. So I want to free these cma pages to buddy directly not
> PCP..

I know your goal and understand current problem it could make more number
of migration but how often it happens so that if we apply your patch,
how much is the gain? For example, you can get a number followin as.

1. old

getting XXXM contiguos memory area: 100ms
the number of migration : 200

2. new

getting XXXM contiguos memory area: 10ms
the number of migration : 0

It seems Mel want it and I'd like to see it to convince.
Of course, Andrew might want it, too.

> 
> > of course, it will waste the memory outside of the alloc range but in the
> > > pageblocks.
> > >

We need to know fundamental problem and number before you go with any method
so that we could judge if you approach is good.
Please add more detail explanation about current status in description.
It would be better to include more statistic data.

> >
> > I would hope/expect that the loss would only last for the duration of
> > the allocation attempt and a small amount of memory.
> >
> > > > when a range of pages have been isolated and migrated. Is there any
> > > > measurable benefit to this patch?
> > > >
> > > after applying this patch, the video player on my platform works more
> > > fluent,
> >
> > fluent almost always refers to ones command of a spoken language. I do
> > not see how a video player can be fluent in anything. What is measurably
> > better?
> >
> > For example, are allocations faster? If so, why? What cost from another
> > path is removed as a result of this patch? If the cost is in the PCP
> > flush then can it be checked if the PCP flush was unnecessary and called
> > unconditionally even though all the pages were freed already? We had
> > problems in the past where drain_all_pages() or similar were called
> > unnecessarily causing long sync stalls related to IPIs. I'm wondering if
> > we are seeing a similar problem here.
> >
> > Maybe the problem is the complete opposite. Are allocations failing
> > because there are PCP pages in the way? In that case, it real fix might
> > be to insert a  if the allocation is failing due to per-cpu
> > pages.
> >
> problem is not the allocation failing, but the unexpected cma migration
> slows
> down the allocation.

Re: [PATCH net] virtio-net: correctly handle cpu hotplug notifier during resuming

[David Miller]

From: Jason Wang 
Date: Tue, 29 Oct 2013 15:11:07 +0800

> commit 3ab098df35f8b98b6553edc2e40234af512ba877 (virtio-net: don't respond to
> cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug
> notifier by checking the config_enable and does nothing is it was false. So it
> need to try to hold the config_lock mutex which may happen in atomic
> environment which leads the following warnings:
 ...
> A correct fix is to unregister the hotcpu notifier during restore and 
> register a
> new one in resume.
> 
> Reported-by: Fengguang Wu 
> Tested-by: Fengguang Wu 
> Cc: Wanlong Gao 
> Cc: Rusty Russell 
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 
> ---
> This patch is needed for 3.8 and above.

Applied and queued up for -stable, thanks Jason.
--
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/

BUG_ON(irq_has_action(entry->irq + i)) in free_msi_irqs()

[LF.Tan]

Hi all

I am new in PCI and now working on MSI support on our PCIe host
driver. I have an endpoint driver requests for a MSI interrupt. When
the endpoint driver try to free the interrupt, it cause the kernel
BUG_ON() message is printed out.

The software flow:
Endpoint driver --> pci_disable_msi -->free_msi_irqs -->
BUG_ON(irq_has_action(entry->irq + i));

I have checked desc->action in irq_has_action(), it is non-zero.
It is running on ARM platform. CONFIG_GENERIC_HARDIRQS is turn on by default.

Anyone how to fix this issue? Thanks.


static void free_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *entry, *tmp;

list_for_each_entry(entry, &dev->msi_list, list) {
int i, nvec;

if (!entry->irq)
continue;
nvec = 1 << entry->msi_attrib.multiple;
#ifdef CONFIG_GENERIC_HARDIRQS
for (i = 0; i < nvec; i++)
BUG_ON(irq_has_action(entry->irq + i));
#endif
}
.
}


static inline int irq_has_action(unsigned int irq)
{
 struct irq_desc *desc = irq_to_desc(irq);
return desc->action != NULL;
}



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

[PATCH 1/3] block: Add REQ_NOMERGE into REQ_COMMON_MASK

[majianpeng]

For bio with REQ_NOMERGE,it mean this bio can't merge with other bios.
And the request with this bio has the same meaning.
In blk_queue_bio, bio with REQ_NOMERGE can't be merged and get a new
request. But in init_request_from_bio, request can't test REQ_NOMERGE.
So the request can merge other bio or merge other request.
Add REQ_NOMERGE into REQ_COMMON_MASK to avoid this.

Signed-off-by: Jianpeng Ma 
---
 include/linux/blk_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index fa1abeb..fc7f4c5 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -197,7 +197,7 @@ enum rq_flag_bits {
 #define REQ_COMMON_MASK \
(REQ_WRITE | REQ_FAILFAST_MASK | REQ_SYNC | REQ_META | REQ_PRIO | \
 REQ_DISCARD | REQ_WRITE_SAME | REQ_NOIDLE | REQ_FLUSH | REQ_FUA | \
-REQ_SECURE)
+REQ_SECURE | REQ_NOMERGE)
 #define REQ_CLONE_MASK REQ_COMMON_MASK
 
 #define BIO_NO_ADVANCE_ITER_MASK   (REQ_DISCARD|REQ_WRITE_SAME)
-- 
1.8.4N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ 
zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i

[PATCH 2/3] block: Check bio can merge before call attempt_plug_merge.

[majianpeng]

Signed-off-by: Jianpeng Ma 
---
 block/blk-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 0a00e4e..fb970fd 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1492,7 +1492,7 @@ void blk_queue_bio(struct request_queue *q, struct bio 
*bio)
 * Check if we can merge with the plugged list before grabbing
 * any locks.
 */
-   if (attempt_plug_merge(q, bio, &request_count))
+   if (likely(bio_mergeable(bio)) && attempt_plug_merge(q, bio, 
&request_count))
return;
 
spin_lock_irq(q->queue_lock);
-- 
1.8.4

Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()

[David Miller]

From: David Mackey 
Date: Tue, 29 Oct 2013 15:16:38 -0700

> Using dev_kfree_skb_any() will resolve the below issue when a
> netconsole message is transmitted in an irq.
 ...
> Signed-off-by: David Mackey 

This is absolutely not the correct fix.

The netpoll facility must invoke ->poll() in an environment which
is compatible, locking and interrupt/soft-interrupt wise, as that
in which it is normally called.

Therefore, bnx2_tx_int(), which is invoked from the driver's ->poll()
method, should not need to use dev_kfree_skb_any().  The real problem
is somewhere else.
--
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/3] handle some bugs for REQ_NOMERGE.

[majianpeng]

This patch set mainly handle some bugs for REQ_NOMERGE.

Jianpeng Ma (3):
  block: Add REQ_NOMERGE into REQ_COMMON_MASK
  block: Check bio can merge before call attempt_plug_merge.
  md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with   
 REQ_NOMERGE.

 block/blk-core.c  | 2 +-
 drivers/md/raid5.c| 2 +-
 include/linux/blk_types.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.8.4

[PATCH 3/3] md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with REQ_NOMERGE.

[majianpeng]

For R5_ReadNoMerge,it mean this bio can't merge with other bios or
request.It used REQ_FLUSH to achieve this. But REQ_NOMERGE can do the
same work.

Signed-off-by: Jianpeng Ma 
---
 drivers/md/raid5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index f8b9068..8e0aeaa 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -772,7 +772,7 @@ static void ops_run_io(struct stripe_head *sh, struct 
stripe_head_state *s)
bi->bi_sector = (sh->sector
 + rdev->data_offset);
if (test_bit(R5_ReadNoMerge, &sh->dev[i].flags))
-   bi->bi_rw |= REQ_FLUSH;
+   bi->bi_rw |= REQ_NOMERGE;
 
bi->bi_vcnt = 1;
bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
-- 
1.8.4

Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change

[David Miller]

From: "Du, ChangbinX" 
Date: Tue, 29 Oct 2013 03:30:42 +

> In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
> But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
> be called which calls free_netdev(net). Thus usbnet structure(alloced
> with net_device structure) will be freed,too.
> So we cannot call usbnet_link_change() if cdc_ncm_bind_common() return
> error.

This is not the bug.

The problem is in cdc_ncm_bind_common().

It seems to leave dangling interface data pointers in some cases, and
then branches just to "error" so that they don't get cleared back out.

This bypasses the protection present in cdc_ncm_disconnect() meant to
avoid this problem.
--
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 1/3] Staging: zram: Fix access of NULL pointer

[Minchan Kim]

On Wed, Oct 30, 2013 at 04:40:54AM +0530, Rashika Kheria wrote:
> This patch fixes the bug in reset_store caused by accessing NULL pointer.
> 
> The bdev gets its value from bdget_disk() which could fail when memory
> pressure is severe and hence can return NULL because allocation of
> inode in bdget could fail.
> 
> Hence, this patch introduces a check for bdev to prevent reference to a
> NULL pointer in the later part of the code. It also removes unnecessary
> check of bdev for fsync_bdev().
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rashika Kheria 
> ---
> 
> This patch fixes the following issues of the previous revision-
> Better Description
> 
>  drivers/staging/zram/zram_drv.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 2c4ed52..d640a8f 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -648,6 +648,9 @@ static ssize_t reset_store(struct device *dev,
>   zram = dev_to_zram(dev);
>   bdev = bdget_disk(zram->disk, 0);
>  
> + if (!bdev)
> + return -EBUSY;
> +

Oops, Sorry.
I don't think EBUSY is right. How about ENOMEM?

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

Re: [PATCH v7 3/3] Staging: zram: Fix variable dereferenced before check

[Minchan Kim]

On Wed, Oct 30, 2013 at 04:45:24AM +0530, Rashika Kheria wrote:
> This patch fixes the following Smatch warning in zram_drv.c-
> drivers/staging/zram/zram_drv.c:899
> destroy_device() warn: variable dereferenced before check 'zram->disk' (see 
> line 896)
> 
> Cc: sta...@vger.kernel.org

It shouldn't be a stable stuff because it's just warning of Smatch
but there is no bug in real practice.

> Acked-by: Minchan Kim 
> Signed-off-by: Rashika Kheria 
> ---
>  drivers/staging/zram/zram_drv.c |9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 592e760..bf28d56 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -901,13 +901,10 @@ static void destroy_device(struct zram *zram)
>   sysfs_remove_group(&disk_to_dev(zram->disk)->kobj,
>   &zram_disk_attr_group);
>  
> - if (zram->disk) {
> - del_gendisk(zram->disk);
> - put_disk(zram->disk);
> - }
> + del_gendisk(zram->disk);
> + put_disk(zram->disk);
>  
> - if (zram->queue)
> - blk_cleanup_queue(zram->queue);
> + blk_cleanup_queue(zram->queue);
>  }
>  
>  static int __init zram_init(void)
> -- 
> 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/

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

Re: [PATCH v7 2/3] Staging: zram: Fix decrement of variable by calling bdput()

[Minchan Kim]

On Wed, Oct 30, 2013 at 04:42:56AM +0530, Rashika Kheria wrote:
> As suggested by Jerome Marchand "The code in reset_store get the block device
> (bdget_disk()) but it does not put it (bdput()) when it's done using it.
> The usage count is therefor incremented but never decremented."
> 
> Hence, this patch introduces a call to bdput() to decrement the variable 
> after usage.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rashika Kheria 
> ---
> 
> This revision fixes the following issues of the previous revision-
> Handle more error cases
> 
>  drivers/staging/zram/zram_drv.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index d640a8f..592e760 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -664,6 +664,9 @@ static ssize_t reset_store(struct device *dev,
>  
>   /* Make sure all pending I/O is finished */
>   fsync_bdev(bdev);
> + bdput(bdev);
> + bdput(bdev->bd_holders);
> + bdput(do_reset);

I meant it.

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index e77fb6e..32f9a44 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -621,22 +621,30 @@ static ssize_t reset_store(struct device *dev,
bdev = bdget_disk(zram->disk, 0);
 
/* Do not reset an active device! */
-   if (bdev->bd_holders)
-   return -EBUSY;
+   if (bdev->bd_holders) {
+   ret = -EBUSY;
+   goto out;
+   }
 
ret = kstrtou16(buf, 10, &do_reset);
if (ret)
-   return ret;
+   goto out;
 
-   if (!do_reset)
-   return -EINVAL;
+   if (!do_reset) {
+   ret = -EINVAL;
+   goto out;
+   }
 
/* Make sure all pending I/O is finished */
-   if (bdev)
-   fsync_bdev(bdev);
+   fsync_bdev(bdev);
+   bdput(bdev);
 
zram_reset_device(zram);
return len;
+
+out:
+   bdput(bdev);
+   return ret;
 }
 
 static void __zram_make_request(struct zram *zram, struct bio *bio, int rw)

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

Re: [PATCH v7 1/3] Staging: zram: Fix access of NULL pointer

[Minchan Kim]

On Wed, Oct 30, 2013 at 04:40:54AM +0530, Rashika Kheria wrote:
> This patch fixes the bug in reset_store caused by accessing NULL pointer.
> 
> The bdev gets its value from bdget_disk() which could fail when memory
> pressure is severe and hence can return NULL because allocation of
> inode in bdget could fail.
> 
> Hence, this patch introduces a check for bdev to prevent reference to a
> NULL pointer in the later part of the code. It also removes unnecessary
> check of bdev for fsync_bdev().
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rashika Kheria 
Acked-by: Minchan Kim 

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

Re: [PATCH 2/3] PCI: Refactor MSI/MSIX mask restore code to fix interrupt lost issue

[Zhenzhong Duan]

On 2013-10-30 05:58, Bjorn Helgaas wrote:

On Wed, Oct 16, 2013 at 02:33:04PM +0800, Zhenzhong Duan wrote:

Driver init call graph under baremetal:
driver_init->
 msix_capability_init->
 msix_program_entries->
 msix_mask_irq->
 entry->masked = 1
 request_irq->
 __setup_irq->
 irq_startup->
 unmask_msi_irq->
 msix_mask_irq->
 entry->masked = 0;

So entry->masked is always updated with newest value and its value could be used
to restore to mask register in device.

But in initial domain (aka priviliged guest), it's different.
Driver init call graph under initial domain:
driver_init->
 msix_capability_init->
 msix_program_entries->
 msix_mask_irq->
 entry->masked = 1
 request_irq->
 __setup_irq->
 irq_startup->
 __startup_pirq->
 EVTCHNOP_bind_pirq hypercall(trap into Xen)
[Xen:]
pirq_guest_bind->
 startup_msi_irq->
 unmask_msi_irq->
 msi_set_mask_bit->
 entry->msi_attrib.masked = 0;

The right mask value is saved in entry->msi_attrib.masked on Xen.


So entry->msi_attrib.masked in xen side always has newest value. entry->masked
in initial domain is untouched and is 1 after msix_capability_init.

If we run the following sequence:

 pci_enable_msix()
 request_irq()

don't we end up with the MSI IRQ unmasked if we're on bare metal but masked
if we're on Xen?  It seems like we'd want it unmasked in both cases, so I
expected your patch to do something to make it unmasked if we're on Xen.
But I don't think it does, does it?

As far as I can tell, this patch only changes the pci_restore_state()
path.  I think that part makes sense.

Bjorn

It's unmasked on Xen too. This is just what this patch try to fix.
In PHYSDEVOP_restore_msi hypercall, xen did the right thing that did by 
kernel in baremetal.



Based on above, it's Xen's duty to restore entry->msi_attrib.masked to device,
but with current code, entry->masked is used and MSI-x interrupt is masked.

Before patch, restore call graph under initial domain:
pci_reset_function->
 pci_restore_state->
 __pci_restore_msix_state->
 arch_restore_msi_irqs->
 xen_initdom_restore_msi_irqs->
 PHYSDEVOP_restore_msi hypercall (first mask restore)
 msix_mask_irq(entry, entry->masked) (second mask restore)

So msix_mask_irq call in initial domain call graph needs to be removed.

Based on this we can move the restore of the mask in default_restore_msi_irqs
which would avoid restoring the invalid mask under Xen. Furthermore this
simplifies the API by making everything related to restoring an MSI be in the
platform specific APIs instead of just parts of it.

After patch, restore call graph under initial domain:
pci_reset_function->
 pci_restore_state->
 __pci_restore_msix_state->
 arch_restore_msi_irqs->
 xen_initdom_restore_msi_irqs->
 PHYSDEVOP_restore_msi hypercall (first mask restore)
and entry->msi_attrib.masked is restored to hardware register in 
PHYSDEVOP_restore_msi hypercall on Xen.


Logic for baremetal is not changed.
Before patch, restore call graph under baremetal:
pci_reset_function->
 pci_restore_state->
 __pci_restore_msix_state->
 arch_restore_msi_irqs->
 default_restore_msi_irqs->
 msix_mask_irq(entry, entry->masked) (first mask restore)

After patch, restore call graph under baremetal:
pci_reset_function->
 pci_restore_state->
 __pci_restore_msix_state->
 arch_restore_msi_irqs->
 default_restore_msi_irqs->
 msix_mask_irq(entry, entry->masked) (first mask restore)

The process for MSI code is similiar.

Tested-by: Sucheta Chakraborty 
Signed-off-by: Zhenzhong Duan 
Acked-by: Konrad Rzeszutek Wilk 
---
  drivers/pci/msi.c |   17 ++---
  1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ecd4cdf..38237f4 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -236,6 +236,8 @@ void unmask_msi_irq(struct irq_data *data)
  
  void default_restore_msi_irqs(struct pci_dev *dev, int irq)

  {
+   int pos;
+   u16 control;
struct msi_desc *entry;
  
  	entry = NULL;

@@ -248,8 +250,19 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
entry = irq_get_msi_desc(irq);
}
  
-	if (entry)

+   if (entry) {
write_msi_msg(irq, &entry->msg);
+   if (dev->msix_enabled) {
+   msix_mask_irq(entry, entry->masked);
+   readl(entry->mask_base);
+   } else {
+   pos = entry->msi_attrib.pos;
+   pci_read_config_word(dev, pos +

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/netconsole.c between commit c7c6effdeffc ("netconsole: fix
multiple race conditions") from the net tree and commit 22ded57729e6
("netconsole: Convert to pr_") from the net-next tree.

(Thanks for removing that spare blank line :-))

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

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

diff --cc drivers/net/netconsole.c
index c9a15925a1f7,a8ef4c4b94be..
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@@ -333,18 -336,14 +335,18 @@@ static ssize_t store_enabled(struct net
netpoll_print_options(&nt->np);
  
err = netpoll_setup(&nt->np);
 -  if (err) {
 -  mutex_unlock(&nt->mutex);
 +  if (err)
return err;
 -  }
  
-   printk(KERN_INFO "netconsole: network logging started\n");
+   pr_info("network logging started\n");
 -
} else {/* 0 */
 +  /* We need to disable the netconsole before cleaning it up
 +   * otherwise we might end up in write_msg() with
 +   * nt->np.dev == NULL and nt->enabled == 1
 +   */
 +  spin_lock_irqsave(&target_list_lock, flags);
 +  nt->enabled = 0;
 +  spin_unlock_irqrestore(&target_list_lock, flags);
netpoll_cleanup(&nt->np);
}
  


pgpit2RDByXvR.pgp
Description: PGP signature

Re: [PATCH] mmc: rtsx: change phase searching method

[micky]

Hi Chris:

Have you accepted this patch,  I'm waiting a long time for your reply.

Best Reagards.
micky

On 09/02/2013 05:16 PM, micky_ch...@realsil.com.cn wrote:

From: Micky Ching 

The new phase searching method is more concise, and makes the code
easier to understand.

Signed-off-by: Micky Ching 
---
  drivers/mmc/host/rtsx_pci_sdmmc.c |  107 +++--
  1 file changed, 30 insertions(+), 77 deletions(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index f981f7d..299a27c 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -32,15 +32,6 @@
  #include 
  #include 
  
-/* SD Tuning Data Structure

- * Record continuous timing phase path
- */
-struct timing_phase_path {
-   int start;
-   int end;
-   int mid;
-   int len;
-};
  
  struct realtek_pci_sdmmc {

struct platform_device  *pdev;
@@ -497,85 +488,47 @@ static int sd_change_phase(struct realtek_pci_sdmmc 
*host, u8 sample_point)
return 0;
  }
  
-static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)

+static inline u32 get_phase_point(u32 phase_map, unsigned int idx)
  {
-   struct timing_phase_path path[MAX_PHASE + 1];
-   int i, j, cont_path_cnt;
-   int new_block, max_len, final_path_idx;
-   u8 final_phase = 0xFF;
+   idx &= MAX_PHASE;
+   return phase_map & (1 << idx);
+}
+
+static int get_phase_len(u32 phase_map, unsigned int idx)
+{
+   int i;
  
-	/* Parse phase_map, take it as a bit-ring */

-   cont_path_cnt = 0;
-   new_block = 1;
-   j = 0;
for (i = 0; i < MAX_PHASE + 1; i++) {
-   if (phase_map & (1 << i)) {
-   if (new_block) {
-   new_block = 0;
-   j = cont_path_cnt++;
-   path[j].start = i;
-   path[j].end = i;
-   } else {
-   path[j].end = i;
-   }
-   } else {
-   new_block = 1;
-   if (cont_path_cnt) {
-   /* Calculate path length and middle point */
-   int idx = cont_path_cnt - 1;
-   path[idx].len =
-   path[idx].end - path[idx].start + 1;
-   path[idx].mid =
-   path[idx].start + path[idx].len / 2;
-   }
-   }
+   if (get_phase_point(phase_map, idx + i) == 0)
+   return i;
}
+   return MAX_PHASE + 1;
+}
  
-	if (cont_path_cnt == 0) {

-   dev_dbg(sdmmc_dev(host), "No continuous phase path\n");
-   goto finish;
-   } else {
-   /* Calculate last continuous path length and middle point */
-   int idx = cont_path_cnt - 1;
-   path[idx].len = path[idx].end - path[idx].start + 1;
-   path[idx].mid = path[idx].start + path[idx].len / 2;
-   }
+static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+{
+   int start = 0, len = 0;
+   int start_final = 0, len_final = 0;
+   u8 final_phase = 0xFF;
  
-	/* Connect the first and last continuous paths if they are adjacent */

-   if (!path[0].start && (path[cont_path_cnt - 1].end == MAX_PHASE)) {
-   /* Using negative index */
-   path[0].start = path[cont_path_cnt - 1].start - MAX_PHASE - 1;
-   path[0].len += path[cont_path_cnt - 1].len;
-   path[0].mid = path[0].start + path[0].len / 2;
-   /* Convert negative middle point index to positive one */
-   if (path[0].mid < 0)
-   path[0].mid += MAX_PHASE + 1;
-   cont_path_cnt--;
+   if (phase_map == 0) {
+   dev_dbg(sdmmc_dev(host), "Phase: [map:%x]\n", phase_map);
+   return final_phase;
}
  
-	/* Choose the longest continuous phase path */

-   max_len = 0;
-   final_phase = 0;
-   final_path_idx = 0;
-   for (i = 0; i < cont_path_cnt; i++) {
-   if (path[i].len > max_len) {
-   max_len = path[i].len;
-   final_phase = (u8)path[i].mid;
-   final_path_idx = i;
+   while (start < MAX_PHASE + 1) {
+   len = get_phase_len(phase_map, start);
+   if (len_final < len) {
+   start_final = start;
+   len_final = len;
}
-
-   dev_dbg(sdmmc_dev(host), "path[%d].start = %d\n",
-   i, path[i].start);
-   dev_dbg(sdmmc_dev(host), "path[%d].end = %d\n",
-   i, path[i].end);
-   dev_dbg(sdmmc_dev(host), "path[%d].len

Re: [patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

On 10/29/13 at 02:43pm, Borislav Petkov wrote:
> On Tue, Oct 29, 2013 at 10:32:03AM +0800, Dave Young wrote:
> > I remember I tried your efi branch, but the code is different from
> > what you sent to list, thus I turned to use the mbox patches.
> 
> Yeah, please use the #efi branch as I keep refreshing it with the newest
> changes. They're hopefully not serious changes but minor stuff here and
> there so basing stuff ontop should be ok.

Will try, but please keep the posted patches in mailing list up-to-date,
I'm an old-fashioned person, do not tend to depend on git.

Thanks in advance.
Dave
--
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: mmotm 2013-10-29-16-22 uploaded (input)

[Randy Dunlap]

On 10/29/13 16:23, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2013-10-29-16-22 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (3.x
> or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
> 
> This tree is partially included in linux-next.  To see which patches are
> included in linux-next, consult the `series' file.  Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
> 
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> by Michal Hocko.  It contains the patches which are between the
> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> file, http://www.ozlabs.org/~akpm/mmotm/series.


on 10 i386 builds, I see around 800 build errors like these:

arc_ps2.c:(.text+0x500): multiple definition of `input_led_connect'
arc_ps2.c:(.text+0x510): multiple definition of `input_led_disconnect'
twl4030-irq.c:(.text+0x3d0): multiple definition of `input_led_connect'
twl4030-irq.c:(.text+0x3e0): multiple definition of `input_led_disconnect'
twl6030-irq.c:(.text+0x0): multiple definition of `input_led_connect'
twl6030-irq.c:(.text+0x10): multiple definition of `input_led_disconnect'
twl4030-madc.c:(.text+0xaa0): multiple definition of `input_led_connect'
twl4030-madc.c:(.text+0xab0): multiple definition of `input_led_disconnect'
da9052-irq.c:(.text+0x20): multiple definition of `input_led_connect'
da9052-irq.c:(.text+0x30): multiple definition of `input_led_disconnect'
da9052-core.c:(.text+0x80): multiple definition of `input_led_connect'
da9052-core.c:(.text+0x90): multiple definition of `input_led_disconnect'
da9052-i2c.c:(.text+0x1b0): multiple definition of `input_led_connect'
da9052-i2c.c:(.text+0x1c0): multiple definition of `input_led_disconnect'
(.text+0x60): multiple definition of `input_led_connect'
(.text+0x70): multiple definition of `input_led_disconnect'
ozusbsvc1.c:(.text+0x110): multiple definition of `input_led_connect'
ozusbsvc1.c:(.text+0x120): multiple definition of `input_led_disconnect'
(.text+0xe3f0): multiple definition of `input_led_connect'
(.text+0xe400): multiple definition of `input_led_disconnect'
(.text+0x12eb10): multiple definition of `input_led_connect'
(.text+0x12eb20): multiple definition of `input_led_disconnect'
(.text+0x5f2c0): multiple definition of `input_led_connect'
(.text+0x5f2d0): multiple definition of `input_led_disconnect'
(.text+0x98b0): multiple definition of `input_led_connect'
(.text+0x98c0): multiple definition of `input_led_disconnect'
(.text+0x26f20): multiple definition of `input_led_connect'
(.text+0x26f30): multiple definition of `input_led_disconnect'
(.text+0x2850): multiple definition of `input_led_connect'
(.text+0x2860): multiple definition of `input_led_disconnect'


I suspect input-route-kbd-leds-through-the-generic-leds-layer.patch
but I'm not sure of it.



-- 
~Randy
--
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: ELAN Touchscreen regression in recent 3.12 rc's? (USB)

[Kevin Fenzi]

On Wed, 30 Oct 2013 09:41:06 +0800
AceLan Kao  wrote:

> Hi,
> 
> It's hard to believe that those quirks will lead to the problem.
> And actually, there are 4 new commits introduced to -rc7, and 3 of
> them are quirks.
> 
> % git log --pretty=oneline v3.12-rc6..v3.12-rc7 drivers/hid
> 86b84167d4e67372376a57ea9955c5d53dae232f HID: wiimote: add
> LEGO-wiimote VID ad0e669b922c7790182cf19f8015b30e23ad9499 HID: Fix
> unit exponent parsing again 684524d35fe8d13be1f2649633e43bd02c96c695
> HID: usbhid: quirk for SiS Touchscreen
> 8171a67d587a09e14a4949a81e070345fedcf410 HID: usbhid: quirk for
> Synaptics Large Touchccreen
> 
> CC'd Nikolai, since his commit changes the protocol.

Oddly, after a while it seems to have decided to stay on: 

[ 4021.819962] usb 2-7: Manufacturer: ELAN
[ 4021.820163] usb 2-7: ep 0x2 - rounding interval to 64 microframes, ep desc 
says 80 microframes
[ 4021.828338] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/input/input221
[ 4021.828801] hid-multitouch 0003:04F3:016F.00D3: input,hiddev0,hidraw1: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-7/input0
[ 4023.903599] usb 2-7: USB disconnect, device number 86
[ 4024.198444] usb 2-7: new full-speed USB device number 87 using xhci_hcd
[ 4024.211102] usb 2-7: New USB device found, idVendor=04f3, idProduct=016f
[ 4024.211143] usb 2-7: New USB device strings: Mfr=4, Product=14, 
SerialNumber=0
[ 4024.211177] usb 2-7: Product: Touchscreen
[ 4024.211197] usb 2-7: Manufacturer: ELAN
[ 4024.211489] usb 2-7: ep 0x2 - rounding interval to 64 microframes, ep desc 
says 80 microframes
[ 4024.219707] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/input/input222
[ 4024.220555] hid-multitouch 0003:04F3:016F.00D4:
input,hiddev0,hidraw1: USB HID v1.10 Device [ELAN Touchscreen] on
usb-:00:14.0-7/input0

and it's been working since then. So, only after 87 cycles... 

Some kind of weird race condition?

kevin


signature.asc
Description: PGP signature

Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Chen Gang]

On 10/23/2013 11:12 AM, Chen Gang wrote:
> On 10/23/2013 10:51 AM, Francois Bedard wrote:
>> Our sources are on github at 
>> https://github.com/foss-for-synopsys-dwc-arc-processors  and you can report 
>> problems by opening "Issues" with command lines and log outputs below 
>> against relevant toolchain component:
>>
>> For GCC:  
>> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
>> For binutils: 
>> https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1&state=open
>>  
>>
>> Go ahead and officially file these and we'll take a look at them. 
> 

Hello Francois, I marked them at 2013-10-26 night (China time).

  for gcc (3 issues, but #28 duplicates with #26): 

https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/26
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/27
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/28

  for binutils (1 issue):

https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues/21


Hello Joern, for current shrinking status:

  for gcc issue #26, (#28 is its duplication):

issue command: arc-elf32-gcc -Os -fno-reorder-blocks -c systohc.i
source code:   systohc.i contents 41 lines (past it on website).
whether GNU:   only for arc, gnu no issue: gnu gcc-4.8/4.9 are OK.

  for gcc issue #27:

issue command: arc-elf32-gcc -Os -c target_core_pr.i
status:just shrinking code.
   will/should be finish within 2013-10-31.
   welcome any suggestions or completions.

  for binutils issue #21:

it seems simple enough, if still need shrinking, please let me know.


It seems no response, and I am a newbie about the website, need I do
something more for them? (e.g. cc to some members, although I don't
know how to cc).

> I will/should go ahead, hope I can finish reporting them within this
> week (2013-10-27)
> 
> Thanks.
> 

Thanks.
-- 
Chen Gang
--
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] spi: add Intel Mid SSP driver

[Randy Dunlap]

On 10/29/13 11:05, David Cohen wrote:

a few more comments:

> +static unsigned int ssp_get_clk_div(int speed)
> +{
> + return max(1 / speed, 4) - 1;

Divide uses library call?  I dunno...
Bad if so.  Would need to use some function from
#include 

> +}

> +/**
> + * setup() - Driver setup procedure
> + * @spi: Pointeur to the spi_device struct

Pointer

> + */
> +static int setup(struct spi_device *spi)
> +{
> +}
> +/**
> + * ssp_spi_probe() - Driver probe procedure
> + * @pdev:Pointer to the pci_dev struct
> + * @ent: Pointer to the pci_device_id struct
> + */
> +static int ssp_spi_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + /* Set platform & configuration quirks */
> + if (sspc->quirks & QUIRKS_PLATFORM_MRST) {
> + /* Apply bit banging workarround on MRST */

 workaround

> + sspc->quirks |= QUIRKS_BIT_BANGING;
> + /* MRST slave mode workarrounds */

   workarounds

> + if (ssp_cfg_is_spi_slave(ssp_cfg))
> + sspc->quirks |= QUIRKS_USE_PM_QOS |
> + QUIRKS_SRAM_ADDITIONAL_CPY;
> + }
> + if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER)
> + ssp_timing_wr = 1;
> +
> + if (status < 0) {
> + dev_err(&pdev->dev, "can not get IRQ\n");

 cannot

> + goto err_free_4;
> + }
> +
> +}

> +MODULE_AUTHOR("Ken Mills");
> +MODULE_DESCRIPTION("Bulverde SSP core SPI contoller");

 controller

> +MODULE_LICENSE("GPL");


-- 
~Randy
--
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: ELAN Touchscreen regression in recent 3.12 rc's? (USB)

[AceLan Kao]

Hi,

It's hard to believe that those quirks will lead to the problem.
And actually, there are 4 new commits introduced to -rc7, and 3 of
them are quirks.

% git log --pretty=oneline v3.12-rc6..v3.12-rc7 drivers/hid
86b84167d4e67372376a57ea9955c5d53dae232f HID: wiimote: add LEGO-wiimote VID
ad0e669b922c7790182cf19f8015b30e23ad9499 HID: Fix unit exponent parsing again
684524d35fe8d13be1f2649633e43bd02c96c695 HID: usbhid: quirk for SiS Touchscreen
8171a67d587a09e14a4949a81e070345fedcf410 HID: usbhid: quirk for
Synaptics Large Touchccreen

CC'd Nikolai, since his commit changes the protocol.

Best regards,
AceLan Kao.

2013/10/29 Josh Boyer :
> On Mon, Oct 28, 2013 at 5:02 PM, Kevin Fenzi  wrote:
>> Greetings.
>>
>> I have a lenovo yoga 2 pro.. it has a ELAN Touchscreen.
>>
>> In 3.12rc5 it was detected and works.
>> in 3.12rc6 it was detected and works.
>>
>> Sometime after the rc6 timeframe it stopped working. It doesn't work with
>> rc7.
>>
>> In dmesg I get:
>>
>> [  159.519663] usb 2-7: New USB device found, idVendor=04f3, idProduct=016f
>> [  159.519681] usb 2-7: New USB device strings: Mfr=4, Product=14, 
>> SerialNumber=0
>> [  159.519683] usb 2-7: Product: Touchscreen
>> [  159.519685] usb 2-7: Manufacturer: ELAN
>> [  159.519901] usb 2-7: ep 0x2 - rounding interval to 64 microframes, ep 
>> desc says 80 microframes
>> [  159.528027] input: ELAN Touchscreen as 
>> /devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/input/input20
>> [  159.528544] hid-multitouch 0003:04F3:016F.000A: input,hiddev0,hidraw1: 
>> USB HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-7/input0
>> [  161.601423] usb 2-7: USB disconnect, device number 71
>> [  161.896828] usb 2-7: new full-speed USB device number 72 using xhci_hcd
>> [  163.991296] usb 2-7: unable to read config index 0 descriptor/start: -71
>> [  163.991301] usb 2-7: can't read configurations, error -71
>> [  164.143686] usb 2-7: new full-speed USB device number 73 using xhci_hcd
>> [  166.239273] usb 2-7: unable to read config index 0 descriptor/start: -71
>> [  166.239278] usb 2-7: can't read configurations, error -71
>> [  166.392576] usb 2-7: new full-speed USB device number 74 using xhci_hcd
>> [  168.487051] usb 2-7: unable to read config index 0 descriptor/start: -71
>> [  168.487058] usb 2-7: can't read configurations, error -71
>> [  168.640308] usb 2-7: new full-speed USB device number 75 using xhci_hcd
>> [  170.734850] usb 2-7: unable to read config index 0 descriptor/start: -71
>> [  170.734856] usb 2-7: can't read configurations, error -71
>> [  170.734927] hub 2-0:1.0: unable to enumerate USB device on port 7
>> [  171.022134] usb 2-7: new full-speed USB device number 76 using xhci_hcd
>> [  173.116744] usb 2-7: unable to read config index 0 descriptor/start: -71
>> [  173.116750] usb 2-7: can't read configurations, error -71
>> [  173.269840] usb 2-7: new full-speed USB device number 77 using xhci_hcd
>> [  173.282520] usb 2-7: New USB device found, idVendor=04f3, idProduct=016f
>> [  173.282526] usb 2-7: New USB device strings: Mfr=4, Product=14, 
>> SerialNumber=0
>> [  173.282528] usb 2-7: Product: Touchscreen
>> [  173.282530] usb 2-7: Manufacturer: ELAN
>> [  173.282782] usb 2-7: ep 0x2 - rounding interval to 64 microframes, ep 
>> desc says 80 microframes
>> [  173.290920] input: ELAN Touchscreen
>> as /devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/input/input21
>>
>> So it seems to be bouncing in and out (but never long enough to actually 
>> work).
>>
>> Could be a regression in xhci_hcd?
>
> Hm.  There were no changes in drivers/usb from -rc6 to -rc7, so if
> -rc6 works then I doubt it's xhci_hcd.  There were two touchscreen
> quirks added between those two rcs though, so perhaps one of those
> broke this.
>
> 684524d35fe8d13be1f2649633e43bd02c96c695 HID: usbhid: quirk for SiS 
> Touchscreen
> 8171a67d587a09e14a4949a81e070345fedcf410 HID: usbhid: quirk for
> Synaptics Large Touchccreen
>
> CC'd AceLan and Jiri.
>
> josh
--
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/5] fat: add fat_fallocate operation

[OGAWA Hirofumi]

Namjae Jeon  writes:

>>> +   /* Release unwritten fallocated blocks on file release. */
>>> +   if (round_up(inode->i_size, sb->s_blocksize) <
>>> +   MSDOS_I(inode)->i_disksize && inode->i_nlink != 0)
>>> +   fat_truncate_blocks(inode, inode->i_size);
>>> +
>>> truncate_inode_pages(&inode->i_data, 0);
>>> if (!inode->i_nlink) {
>>> inode->i_size = 0;

[...]

>> And inode->i_size should be ->mmu_private?
> Sorry, I don't understand your question yet...
> Could you elaborate more ?

"if" part is checking "round_up(->i_size) < ->i_disksize", but I guess
fallocate() truncation should be only needed if there is uninitialized
data. So, I felt that part should check ->mmu_private and ->i_disksize.

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

Re: [PATCH] sysfs: move assignment to be under lock in sysfs_remove_dir()

[Linus Torvalds]

On Tue, Oct 29, 2013 at 5:39 PM, Eric W. Biederman
 wrote:
>
> I don't have a strong feeling either way but how would that matter?
> There is only ever one sd associated with a kobj.

What does that matter? If you have multiple callers, they might try to
free that one sd twice, since they could both see a non-NULL case.

> And we better be under the sysfs_mutex when the assignment and and
> sysfs_remove_dir are called.

Not as far as I can tell. kobject_del() calls sysfs_remove_dir(), and
I'm not seeing why that would be under the mutex.  The only locking I
see is that sysfs_assoc_lock, which _isn't_ held for the reading of
kobj->sd.

Now, there may be other reasons for this all working (like the fact
that only one user ever calls kobject_del() on any particular object,
but it sure as hell isn't obvious. The fact that you seem to be
confused about this only proves my point.

Besides, the "design pattern" of having a lock for the assignment, but
then reading the value without that lock seems to be all kinds of
f*cking stupid, wouldn't you agree? I'm really not seeing how that
could _ever_ be something you make excuses for in the first place.
Even if there is some external locking (which, as far as I can tell,
there is not), that would just raise the question as to what reason
that spinlock has to exist at all.

The code doesn't make any sense with the locking the way it is now. It
might _work_, of course, but it sure as hell doesn't make sense.


  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/

Re: [PATCH 17/23] dm: Refactor for new bio cloning/splitting

[Mike Snitzer]

On Tue, Oct 29 2013 at  8:19pm -0400,
Kent Overstreet  wrote:

> On Tue, Oct 29, 2013 at 08:09:08PM -0400, Mike Snitzer wrote:
> > 
> > But now that I look closer, the above dm-thin.c hunks belong in:
> > [PATCH 19/23] block: Generic bio chaining
> > 
> > Seems these changes were mistakenly folded into this 17/23 patch?
> 
> ...Whoops, fixed. Here's the new versions if you want to take a look:
> 
> http://evilpiepirate.org/git/linux-bcache.git/log/?h=for-jens
> http://evilpiepirate.org/git/linux-bcache.git/commit/?h=for-jens&id=74f0f2084f88bb38403ca80bb98976f8219f9262

Yeap, looks good (aside from the dm patches not having my Reviewed-by).

Not sure if Jens can add it?..  that said, I don't mind the commits not
having my Reviewed-by but it does lose some context for your changes
having had some other eyeballs on them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] fat: add i_disksize to represent uninitialized size

[OGAWA Hirofumi]

Namjae Jeon  writes:

>>> diff --git a/fs/fat/cache.c b/fs/fat/cache.c
>>> index 91ad9e1..37572c2 100644
>>> --- a/fs/fat/cache.c
>>> +++ b/fs/fat/cache.c
>>> @@ -329,10 +329,10 @@ int fat_bmap(struct inode *inode, sector_t sector,
>>> sector_t *phys,
>>> return 0;
>>>
>>> /*
>>> -* ->mmu_private can access on only allocation path.
>>> +* ->i_disksize can access on only allocation path.
>>>  * (caller must hold ->i_mutex)
>>>  */
>>> -   last_block = (MSDOS_I(inode)->mmu_private + (blocksize - 1))
>>> +   last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
>>> >> blocksize_bits;
>>> if (sector >= last_block)
>>> return 0;
>>
>> Hm, bmap() ioctl returns between ->mmu_private and i_disksize? I'm not
>> checking other FSes what does...
> I added this code after checking such behaviour from ext4.

OK. I will check with it. BTW, comment should say the both
(i.e. ->mmu_private and ->i_disksize must under ->i_mutex).
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 01/18] arm: make SWIOTLB available

[Stefano Stabellini]

On Tue, 29 Oct 2013, Russell King - ARM Linux wrote:
> So... what I'm saying is please fix xgmac to use the DMA API properly
> rather than working around such problems. :)
 
OK.
Would the appended patch fix your concerns?

---

arm: make SWIOTLB available

IOMMU_HELPER is needed because SWIOTLB calls iommu_is_span_boundary,
provided by lib/iommu_helper.c.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Konrad Rzeszutek Wilk 

Changes in v9:
- remove uneeded include asm/cacheflush.h;
- just return 0 if !dev->dma_mask in dma_capable.

---
 arch/arm/Kconfig   |6 ++
 arch/arm/include/asm/dma-mapping.h |   33 +
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ad6fb6..b08374f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1872,6 +1872,12 @@ config CC_STACKPROTECTOR
  neutralized via a kernel panic.
  This feature requires gcc version 4.2 or above.
 
+config SWIOTLB
+   def_bool y
+
+config IOMMU_HELPER
+   def_bool SWIOTLB
+
 config XEN_DOM0
def_bool y
depends on XEN
diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..1ad2c17 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -86,6 +86,39 @@ static inline dma_addr_t virt_to_dma(struct device *dev, 
void *addr)
 }
 #endif
 
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+   unsigned int offset = paddr & ~PAGE_MASK;
+   return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+{
+   unsigned int offset = dev_addr & ~PAGE_MASK;
+   return __pfn_to_phys(dma_to_pfn(dev, dev_addr)) + offset;
+}
+
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t 
size)
+{
+   u64 limit, mask;
+
+   if (!dev->dma_mask)
+   return 0;
+
+   mask = *dev->dma_mask;
+
+   limit = (mask + 1) & ~mask;
+   if (limit && size > limit)
+   return 0;
+
+   if ((addr | (addr + size - 1)) & ~mask)
+   return 0;
+
+   return 1;
+}
+
+static inline void dma_mark_clean(void *addr, size_t size) { }
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
-- 
1.7.2.5

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

[PATCH-next v3] kernel/system_certificate.S: use real contents instead of macro GLOBAL()

[Chen Gang]

If a macro is only used within 2 times, and also its contents are
within 2 lines, recommend to expand it to shrink code line.

For our case, the macro is not portable either: some architectures'
assembler may use another character to mark newline in a macro (e.g.
'`' for arc), which will cause issue.

If still want to use macro and let it portable enough, it will also
need include additional header file (e.g "#include ",
although it also need be fixed).


Signed-off-by: Chen Gang 
---
 kernel/system_certificates.S |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/kernel/system_certificates.S b/kernel/system_certificates.S
index 552d47b..4aef390 100644
--- a/kernel/system_certificates.S
+++ b/kernel/system_certificates.S
@@ -1,12 +1,10 @@
 #include 
 #include 
 
-#define GLOBAL(name)   \
-   .globl VMLINUX_SYMBOL(name);\
-   VMLINUX_SYMBOL(name):
-
__INITRODATA
 
-GLOBAL(system_certificate_list)
+   .globl VMLINUX_SYMBOL(system_certificate_list)
+VMLINUX_SYMBOL(system_certificate_list):
.incbin "kernel/x509_certificate_list"
-GLOBAL(system_certificate_list_end)
+   .globl VMLINUX_SYMBOL(system_certificate_list_end)
+VMLINUX_SYMBOL(system_certificate_list_end):
-- 
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: [f2fs-dev] [PATCH V2 RESEND] f2fs: check all ones or zeros bitmap with bitops for better mount performance

[Chao Yu]

Hi Lee,

> -Original Message-
> From: Changman Lee [mailto:cm224@samsung.com]
> Sent: Wednesday, October 30, 2013 7:25 AM
> To: 'Chao Yu'; jaegeuk@samsung.com
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: RE: [f2fs-dev] [PATCH V2 RESEND] f2fs: check all ones or zeros 
> bitmap with
bitops for
> better mount performance
> 
> 
> As you know, if any data or function are used once, we can use some keywords
> like __initdata for data and __init for function.

Thanks for reminding me that.
I just think of that generating tmp data by func could save memory use or keep 
program
size small.

Regards
Yu

> 
> 
> -Original Message-
> From: Chao Yu [mailto:chao2...@samsung.com]
> Sent: Tuesday, October 29, 2013 7:52 PM
> To: 'Changman Lee'; jaegeuk@samsung.com
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: RE: [f2fs-dev] [PATCH V2 RESEND] f2fs: check all ones or zeros
> bitmap with bitops for better mount performance
> 
> Hi Lee,
> 
> > -Original Message-
> > From: Changman Lee [mailto:cm224@samsung.com]
> > Sent: Tuesday, October 29, 2013 3:36 PM
> > To: 'Chao Yu'; jaegeuk@samsung.com
> > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Subject: RE: [f2fs-dev] [PATCH V2 RESEND] f2fs: check all ones or
> > zeros
> bitmap
> > with bitops for better mount performance
> >
> > Review attached patch, please.
> 
> Could we hide the pre calculated value by generating it in allocated memory
> by func, because the value will be no use after build_sit_entries();
> 
> Regards
> Yu
> 
> >
> > -Original Message-
> > From: Chao Yu [mailto:chao2...@samsung.com]
> > Sent: Tuesday, October 29, 2013 3:51 PM
> > To: jaegeuk@samsung.com
> > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Subject: [f2fs-dev] [PATCH V2 RESEND] f2fs: check all ones or zeros
> > bitmap
> with
> > bitops for better mount performance
> >
> > Previously, check_block_count check valid_map with bit data type in
> > common scenario that sit has all ones or zeros bitmap, it makes low
> > mount performance.
> > So let's check the special bitmap with integer data type instead of
> > the
> bit one.
> >
> > v1-->v2:
> > use find_next_{zero_}bit_le for better performance and readable as
> > Jaegeuk suggested.
> > use neat logogram in comment as Gu Zheng suggested.
> > search continuous ones or zeros for better performance when checking
> 
> > mixed bitmap.
> >
> > Suggested-by: Jaegeuk Kim 
> > Signed-off-by: Shu Tan 
> > Signed-off-by: Chao Yu 
> > ---
> >  fs/f2fs/segment.h |   19 +++
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> > abe7094..a7abfa8
> > 100644
> > --- a/fs/f2fs/segment.h
> > +++ b/fs/f2fs/segment.h
> > @@ -550,8 +550,9 @@ static inline void check_block_count(struct
> > f2fs_sb_info *sbi,  {
> > struct f2fs_sm_info *sm_info = SM_I(sbi);
> > unsigned int end_segno = sm_info->segment_count - 1;
> > +   bool is_valid  = test_bit_le(0, raw_sit->valid_map) ? true : false;
> > int valid_blocks = 0;
> > -   int i;
> > +   int cur_pos = 0, next_pos;
> >
> > /* check segment usage */
> > BUG_ON(GET_SIT_VBLOCKS(raw_sit) > sbi->blocks_per_seg); @@ -560,9
> > +561,19 @@ static inline void check_block_count(struct f2fs_sb_info
> > +*sbi,
> > BUG_ON(segno > end_segno);
> >
> > /* check bitmap with valid block count */
> > -   for (i = 0; i < sbi->blocks_per_seg; i++)
> > -   if (f2fs_test_bit(i, raw_sit->valid_map))
> > -   valid_blocks++;
> > +   do {
> > +   if (is_valid) {
> > +   next_pos =
> > find_next_zero_bit_le(&raw_sit->valid_map,
> > +   sbi->blocks_per_seg,
> > +   cur_pos);
> > +   valid_blocks += next_pos - cur_pos;
> > +   } else
> > +   next_pos = find_next_bit_le(&raw_sit->valid_map,
> > +   sbi->blocks_per_seg,
> > +   cur_pos);
> > +   cur_pos = next_pos;
> > +   is_valid = !is_valid;
> > +   } while (cur_pos < sbi->blocks_per_seg);
> > BUG_ON(GET_SIT_VBLOCKS(raw_sit) != valid_blocks);  }
> >
> > --
> > 1.7.9.5
> >
> >
> >
> 
> > --
> > Android is increasing in popularity, but the open development platform
> that
> > developers love is also attractive to malware creators. Download this
> white
> > paper to learn more about secure code signing practices that can help
> > keep Android apps secure.
> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> > lktr
> > k
> > 

Re: [PATCH 1/2] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1

[Joe Perches]

On Wed, 2013-10-30 at 01:40 +0100, Peter Huewe wrote:
> strcmp does return the difference between two strings not only -1,0,1
> consequently
>  if (strcmp (a,b) == -1)
> might lead to taking the wrong branch
> 
> -> compare with <= instead.

lib/string.c:strcmp returns only -1,0,1
so that's what the arch versions should do too.
However, arch implementations do vary...

fyi: using
if (strcmp(foo, bar) < 0)
is canonical.

There are no existing <= -1 uses.


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

Re: [PATCH v5 5/7] arm64, jump label: detect %c support for ARM64

[Will Deacon]

On Fri, Oct 18, 2013 at 04:19:59PM +0100, Jiang Liu wrote:
> From: Jiang Liu 
> 
> As commit a9468f30b5eac6 "ARM: 7333/2: jump label: detect %c
> support for ARM", this patch detects the same thing for ARM64
> because some ARM64 GCC versions have the same issue.
> 
> Some versions of ARM64 GCC which do support asm goto, do not
> support the %c specifier. Since we need the %c to support jump
> labels on ARM64, detect that too in the asm goto detection script
> to avoid build errors with these versions.

Acked-by: Will Deacon 

The toolchain is being fixed upstream for this, but we should have the check
for older versions.

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/

Re: [PATCH] arch: use ASM_NL instead of ';' for assembler new line character in the macro

[Chen Gang]

On 10/29/2013 09:59 PM, David Howells wrote:
> Chen Gang  wrote:
> 
> For "kernel/modsign_certificate.S", I recommend to expand the macro
> which will shrink code line, either need not include additional header
> file, I feel that will be simpler for both code reader and writers.
>>> I recommend leaving that file alone.  That gets moved to a .S file in 
>>> patches
>>> queued in the security tree.
>>
>> Excuse me, I am not quite familiar with our version merging, I guess
>> your meaning is "this file will be removed, and the related contents
>> will be in another .S file, so we need not fix it within this file".
>>
>> If what I guess is correct, I support your recommendation (and if what I
>> guess is incorrect, please let me know, thanks). :-)
> 
> Sorry, I misread what you were saying.  The code has already been split out of
> the .c file of course (I'd forgotten that it had).  In the security tree next
> branch, the .S file gets renamed and slightly modified here:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/jmorris/linux-security.git/commit/?h=next&id=b56e5a17b6b9acd16997960504b9940d0d7984e7
> 

Oh, thank you for your information, and I will send patch v3 for it.

I need/should based on another next-tree branch, and use its tag
"next-20131025" to continue (which already contents original related
changes).

And also, excuse me, my English is not quite well (which easily lead
other members misunderstanding).


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

Re: [PATCH v5 6/7] arm64, jump label: optimize jump label implementation

[Will Deacon]

On Fri, Oct 18, 2013 at 04:20:00PM +0100, Jiang Liu wrote:
> From: Jiang Liu 
> 
> Optimize jump label implementation for ARM64 by dynamically patching
> kernel text.
> 
> Signed-off-by: Jiang Liu 
> Cc: Jiang Liu 
> ---
>  arch/arm64/Kconfig  |  1 +
>  arch/arm64/include/asm/jump_label.h | 52 +
>  arch/arm64/kernel/Makefile  |  1 +
>  arch/arm64/kernel/jump_label.c  | 58 
> +
>  4 files changed, 112 insertions(+)
>  create mode 100644 arch/arm64/include/asm/jump_label.h
>  create mode 100644 arch/arm64/kernel/jump_label.c
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c044548..da388e4 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -17,6 +17,7 @@ config ARM64
>   select GENERIC_SMP_IDLE_THREAD
>   select GENERIC_TIME_VSYSCALL
>   select HARDIRQS_SW_RESEND
> + select HAVE_ARCH_JUMP_LABEL
>   select HAVE_ARCH_TRACEHOOK
>   select HAVE_DEBUG_BUGVERBOSE
>   select HAVE_DEBUG_KMEMLEAK
> diff --git a/arch/arm64/include/asm/jump_label.h 
> b/arch/arm64/include/asm/jump_label.h
> new file mode 100644
> index 000..d268fab
> --- /dev/null
> +++ b/arch/arm64/include/asm/jump_label.h
> @@ -0,0 +1,52 @@
> +/*
> + * Copyright (C) 2013 Huawei Ltd.
> + * Author: Jiang Liu 
> + *
> + * Based on arch/arm/include/asm/jump_label.h
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +#ifndef _ASM_ARM64_JUMP_LABEL_H
> +#define _ASM_ARM64_JUMP_LABEL_H
> +#include 
> +
> +#ifdef __KERNEL__
> +
> +#define JUMP_LABEL_NOP_SIZE 4
> +
> +static __always_inline bool arch_static_branch(struct static_key *key)
> +{
> + asm goto("1:\n\t"
> +  "nop\n\t"

Minor nit: can you put the label on the same line as the nop please?

> +  ".pushsection __jump_table,  \"aw\"\n\t"
> +  ".align 3\n\t"
> +  ".quad 1b, %l[l_yes], %c0\n\t"
> +  ".popsection\n\t"
> +  :  :  "i"(key) :  : l_yes);
> +
> + return false;
> +l_yes:
> + return true;
> +}
> +
> +#endif /* __KERNEL__ */
> +
> +typedef u64 jump_label_t;
> +
> +struct jump_entry {
> + jump_label_t code;
> + jump_label_t target;
> + jump_label_t key;
> +};
> +
> +#endif   /* _ASM_ARM64_JUMP_LABEL_H */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 9af6cb3..b7db65e 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP) += smp.o 
> smp_spin_table.o smp_psci.o
>  arm64-obj-$(CONFIG_HW_PERF_EVENTS)   += perf_event.o
>  arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
>  arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
> +arm64-obj-$(CONFIG_JUMP_LABEL)   += jump_label.o
>  
>  obj-y+= $(arm64-obj-y) vdso/
>  obj-m+= $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/jump_label.c b/arch/arm64/kernel/jump_label.c
> new file mode 100644
> index 000..871786a
> --- /dev/null
> +++ b/arch/arm64/kernel/jump_label.c
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (C) 2013 Huawei Ltd.
> + * Author: Jiang Liu 
> + *
> + * Based on arch/arm/kernel/jump_label.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef HAVE_JUMP_LABEL
> +
> +static void __arch_jump_label_transform(struct jump_entry *entry,
> + enum jump_label_type type,
> + bool is_static)
> +{
> + void *addr = (void *)entry->code;
> + u32 insn;
> +
> + if (type == JUMP_LABEL_ENABLE) {
> + insn = aarch64_insn_gen_branch_imm(entry->code,
> +entry->t

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

[Alex Courbot]

On 10/29/2013 10:25 PM, Linus Walleij wrote:

On Tue, Oct 29, 2013 at 10:10 AM, Stephen Rothwell  
wrote:


I have applied the following patch for today (it should go into the gpio
tree if it is considered correct):

From: Stephen Rothwell 
Date: Tue, 29 Oct 2013 20:05:12 +1100
Subject: [PATCH] gpiolib: include gpio/consumer.h in of_gpio.h for
  desc_to_gpio()

Fixes this build error on sparc:

In file included from drivers/spi/spi.c:33:0:
include/linux/of_gpio.h: In function 'of_get_named_gpio_flags':
include/linux/of_gpio.h:93:3: error: implicit declaration of function 
'desc_to_gpio' [-Werror=implicit-function-declaration]

Signed-off-by: Stephen Rothwell 


Patch applied, unless Alexandre has any considerations.


Nope, that include should definitely be there, actually I was convinced 
it was already...


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/

perf confused by modules being loaded in between addresses in /proc/kallsyms

[Michael Hudson-Doyle]

Hi,

On arm, probably since "ARM: use linker magic for vectors and vector
stubs" (although I haven't checked this), perf report tends to allocate
all kernel time to the module loaded at the highest address.

This turns out to be because the "perf_event__synthesize_modules"
generates a PERF_RECORD_MMAP for the last module thats runs from its
start to the end of the address space.

This in turn turns out be because the first symbol in /proc/kallsyms is
now at 0:

# head -n 2 /proc/kallsyms
 t __vectors_start
c00081c0 T asm_do_IRQ

/This/ means that the kallsyms entry in machine->kmaps[MAP__FUNCTION] is
now the first entry rather than the last in the map, so the last module
is the last in the map and so its "end" stays as ~0ULL.

I'm told that there is no particularly good reason for __vectors_start
to be in kallsyms at 0, but in any case this seems like a bug in the
user space tool.  I notice that there is code to split the kallsyms
symbols around symbols from modules (dso__split_kallsyms) but this
doesn't seem to be called for record, only report.  Is the fix as simple
as making sure this happens for record as well?  I don't feel qualified
to answer that.

Cheers,
mwh
--
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 net-next RFC 4/5] xen-netback: Fix indentations

[Zoltan Kiss]

I've left intentionally these indentations in this way, to improve readability 
of previous patches.

Signed-off-by: Zoltan Kiss 
---
 drivers/net/xen-netback/netback.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index c91dd36..204fa46 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -882,8 +882,8 @@ static struct gnttab_map_grant_ref 
*xenvif_get_requests(struct xenvif *vif,
 
for (shinfo->nr_frags = start; shinfo->nr_frags < nr_slots;
 shinfo->nr_frags++, txp++, gop++) {
-   index = pending_index(vif->pending_cons++);
-   pending_idx = vif->pending_ring[index];
+   index = pending_index(vif->pending_cons++);
+   pending_idx = vif->pending_ring[index];
xenvif_tx_create_gop(vif, pending_idx, txp, gop);
frag_set_pending_idx(&frags[shinfo->nr_frags], pending_idx);
}
@@ -929,7 +929,7 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
tx_info = &vif->pending_tx_info[pending_idx];
 
/* Check error status: if okay then remember grant handle. */
-   newerr = (++gop)->status;
+   newerr = (++gop)->status;
 
if (likely(!newerr)) {
if (vif->grant_tx_handle[pending_idx] !=
@@ -1717,10 +1717,10 @@ static void xenvif_idx_release(struct xenvif *vif, u16 
pending_idx,
struct pending_tx_info *pending_tx_info;
pending_ring_idx_t index;
 
-   pending_tx_info = &vif->pending_tx_info[pending_idx];
-   make_tx_response(vif, &pending_tx_info->req, status);
-   index = pending_index(vif->pending_prod++);
-   vif->pending_ring[index] = pending_idx;
+   pending_tx_info = &vif->pending_tx_info[pending_idx];
+   make_tx_response(vif, &pending_tx_info->req, status);
+   index = pending_index(vif->pending_prod++);
+   vif->pending_ring[index] = pending_idx;
 }
 
 void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx)
--
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 net-next RFC 1/5] xen-netback: Introduce TX grant map definitions

[Zoltan Kiss]

This patch contains the new definitions necessary for grant mapping.

Signed-off-by: Zoltan Kiss 

---
 drivers/net/xen-netback/common.h|   22 ++
 drivers/net/xen-netback/interface.c |1 +
 drivers/net/xen-netback/netback.c   |  134 +++
 3 files changed, 157 insertions(+)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 55b8dec..36a3fda 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -79,6 +79,11 @@ struct pending_tx_info {
  * if it is head of one or more tx
  * reqs
  */
+   /* callback data for released SKBs. The callback is always
+* xenvif_zerocopy_callback, ctx points to the next fragment, desc
+* contains the pending_idx
+*/
+   struct ubuf_info callback_struct;
 };
 
 #define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
@@ -101,6 +106,8 @@ struct xenvif_rx_meta {
 
 #define MAX_PENDING_REQS 256
 
+#define NETBACK_INVALID_HANDLE -1
+
 struct xenvif {
/* Unique identifier for this interface. */
domid_t  domid;
@@ -119,13 +126,22 @@ struct xenvif {
pending_ring_idx_t pending_cons;
u16 pending_ring[MAX_PENDING_REQS];
struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
+   grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
 
/* Coalescing tx requests before copying makes number of grant
 * copy ops greater or equal to number of slots required. In
 * worst case a tx request consumes 2 gnttab_copy.
 */
struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS];
+   struct gnttab_unmap_grant_ref tx_unmap_ops[MAX_PENDING_REQS];
+   struct gnttab_map_grant_ref tx_map_ops[MAX_PENDING_REQS];
+   /* passed to gnttab_[un]map_refs with pages under (un)mapping */
+   struct page *pages_to_gnt[MAX_PENDING_REQS];
 
+   spinlock_t dealloc_lock;
+   pending_ring_idx_t dealloc_prod;
+   pending_ring_idx_t dealloc_cons;
+   u16 dealloc_ring[MAX_PENDING_REQS];
 
/* Use kthread for guest RX */
struct task_struct *task;
@@ -226,6 +242,12 @@ void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
 
+/* Callback from stack when TX packet can be released */
+void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success);
+
+/* Unmap a pending page, usually has to be called before xenvif_idx_release */
+void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx);
+
 extern bool separate_tx_rx_irq;
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index e4aa267..f5c3c57 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -37,6 +37,7 @@
 
 #include 
 #include 
+#include 
 
 #define XENVIF_QUEUE_LENGTH 32
 #define XENVIF_NAPI_WEIGHT  64
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 828fdab..10470dc 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -869,6 +869,20 @@ static struct page *xenvif_alloc_page(struct xenvif *vif,
return page;
 }
 
+static inline void xenvif_tx_create_gop(struct xenvif *vif, u16 pending_idx,
+  struct xen_netif_tx_request *txp,
+  struct gnttab_map_grant_ref *gop)
+{
+   vif->pages_to_gnt[gop-vif->tx_map_ops] = vif->mmap_pages[pending_idx];
+   gnttab_set_map_op(gop, idx_to_kaddr(vif, pending_idx),
+ GNTMAP_host_map | GNTMAP_readonly,
+ txp->gref, vif->domid);
+
+   memcpy(&vif->pending_tx_info[pending_idx].req, txp,
+  sizeof(*txp));
+
+}
+
 static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
   struct sk_buff *skb,
   struct xen_netif_tx_request *txp,
@@ -1652,6 +1666,106 @@ static int xenvif_tx_submit(struct xenvif *vif, int 
budget)
return work_done;
 }
 
+void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success)
+{
+   unsigned long flags;
+   pending_ring_idx_t index;
+   u16 pending_idx = ubuf->desc;
+   struct pending_tx_info *temp =
+   container_of(ubuf, struct pending_tx_info, callback_struct);
+   struct xenvif *vif =
+   container_of(temp - pending_idx, struct xenvif,
+   pending_tx_info[0]);
+
+   spin_lock_irqsave(&vif->dealloc_lock, flags);
+   do {
+   pending_idx = ubuf->desc;
+   ubuf = (struct ubuf_info *) ubuf->ctx;
+   index = pending_index(vif->dealloc_prod);
+   vif->dealloc_ring[index] = pending_idx;
+   /* Sync with xenvif_tx_action_dealloc:
+* insert idx then incr pro

[PATCH net-next RFC 2/5] xen-netback: Change TX path from grant copy to mapping

[Zoltan Kiss]

This patch changes the grant copy on the TX patch to grant mapping

Signed-off-by: Zoltan Kiss 
---
 drivers/net/xen-netback/interface.c |   39 +-
 drivers/net/xen-netback/netback.c   |  241 +--
 2 files changed, 126 insertions(+), 154 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index f5c3c57..fb16ede 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -336,8 +336,20 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t 
domid,
vif->pending_prod = MAX_PENDING_REQS;
for (i = 0; i < MAX_PENDING_REQS; i++)
vif->pending_ring[i] = i;
-   for (i = 0; i < MAX_PENDING_REQS; i++)
-   vif->mmap_pages[i] = NULL;
+   err = alloc_xenballooned_pages(MAX_PENDING_REQS,
+   vif->mmap_pages,
+   false);
+   if (err) {
+   netdev_err(dev, "Could not reserve mmap_pages\n");
+   return NULL;
+   }
+   for (i = 0; i < MAX_PENDING_REQS; i++) {
+   vif->pending_tx_info[i].callback_struct = (struct ubuf_info)
+   { .callback = xenvif_zerocopy_callback,
+ .ctx = NULL,
+ .desc = i };
+   vif->grant_tx_handle[i] = NETBACK_INVALID_HANDLE;
+   }
 
/*
 * Initialise a dummy MAC address. We choose the numerically
@@ -481,11 +493,34 @@ void xenvif_disconnect(struct xenvif *vif)
 
 void xenvif_free(struct xenvif *vif)
 {
+   int i;
+
netif_napi_del(&vif->napi);
 
unregister_netdev(vif->dev);
 
free_netdev(vif->dev);
 
+   /* FIXME: This is a workaround for 2 problems:
+* - the guest sent a packet just before teardown, and it is still not
+*   delivered
+* - the stack forgot to notify us that we can give back a slot
+* For the first problem we shouldn't do this, as the skb might still
+* access that page. I will come up with a more robust solution later.
+* The second is definitely a bug, it leaks a slot from the ring
+* forever.
+* Classic kernel patchset has delayed copy for that, we might want to
+* reuse that?
+*/
+   for (i = 0; i < MAX_PENDING_REQS; ++i) {
+   if (vif->grant_tx_handle[i] != NETBACK_INVALID_HANDLE) {
+   netdev_err(vif->dev,
+   "Page still granted! Index: %x\n", i);
+   xenvif_idx_unmap(vif, i);
+   }
+   }
+
+   free_xenballooned_pages(MAX_PENDING_REQS, vif->mmap_pages);
+
module_put(THIS_MODULE);
 }
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 10470dc..e544e9f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -883,10 +883,10 @@ static inline void xenvif_tx_create_gop(struct xenvif 
*vif, u16 pending_idx,
 
 }
 
-static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+static struct gnttab_map_grant_ref *xenvif_get_requests(struct xenvif *vif,
   struct sk_buff *skb,
   struct xen_netif_tx_request *txp,
-  struct gnttab_copy *gop)
+  struct gnttab_map_grant_ref *gop)
 {
struct skb_shared_info *shinfo = skb_shinfo(skb);
skb_frag_t *frags = shinfo->frags;
@@ -907,83 +907,12 @@ static struct gnttab_copy *xenvif_get_requests(struct 
xenvif *vif,
/* Skip first skb fragment if it is on same page as header fragment. */
start = (frag_get_pending_idx(&shinfo->frags[0]) == pending_idx);
 
-   /* Coalesce tx requests, at this point the packet passed in
-* should be <= 64K. Any packets larger than 64K have been
-* handled in xenvif_count_requests().
-*/
-   for (shinfo->nr_frags = slot = start; slot < nr_slots;
-shinfo->nr_frags++) {
-   struct pending_tx_info *pending_tx_info =
-   vif->pending_tx_info;
-
-   page = alloc_page(GFP_ATOMIC|__GFP_COLD);
-   if (!page)
-   goto err;
-
-   dst_offset = 0;
-   first = NULL;
-   while (dst_offset < PAGE_SIZE && slot < nr_slots) {
-   gop->flags = GNTCOPY_source_gref;
-
-   gop->source.u.ref = txp->gref;
-   gop->source.domid = vif->domid;
-   gop->source.offset = txp->offset;
-
-   gop->dest.domid = DOMID_SELF;
-
-   gop->dest.offset = dst_offset;
-   gop->dest.u.gmfn = virt_to_mfn(page_address(page));
-
-   if (dst_offset + txp->size > PAGE_SIZE) {
-   /* This page can

[PATCH net-next RFC 4/5] xen-netback: Change RX path for mapped SKB fragments

[Zoltan Kiss]

RX path need to know if the SKB fragments are stored on pages from another
domain.

Signed-off-by: Zoltan Kiss 
---
 drivers/net/xen-netback/netback.c |   46 +
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 204fa46..0ffa412 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -322,7 +322,9 @@ static struct xenvif_rx_meta *get_next_rx_buffer(struct 
xenvif *vif,
 static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 struct netrx_pending_operations *npo,
 struct page *page, unsigned long size,
-unsigned long offset, int *head)
+unsigned long offset, int *head,
+struct xenvif *foreign_vif,
+grant_ref_t foreign_gref)
 {
struct gnttab_copy *copy_gop;
struct xenvif_rx_meta *meta;
@@ -364,8 +366,15 @@ static void xenvif_gop_frag_copy(struct xenvif *vif, 
struct sk_buff *skb,
copy_gop->flags = GNTCOPY_dest_gref;
copy_gop->len = bytes;
 
-   copy_gop->source.domid = DOMID_SELF;
-   copy_gop->source.u.gmfn = virt_to_mfn(page_address(page));
+   if (foreign_vif) {
+   copy_gop->source.domid = foreign_vif->domid;
+   copy_gop->source.u.ref = foreign_gref;
+   copy_gop->flags |= GNTCOPY_source_gref;
+   } else {
+   copy_gop->source.domid = DOMID_SELF;
+   copy_gop->source.u.gmfn =
+   virt_to_mfn(page_address(page));
+   }
copy_gop->source.offset = offset;
 
copy_gop->dest.domid = vif->domid;
@@ -426,6 +435,9 @@ static int xenvif_gop_skb(struct sk_buff *skb,
int old_meta_prod;
int gso_type;
int gso_size;
+   struct ubuf_info *ubuf = skb_shinfo(skb)->destructor_arg;
+   grant_ref_t foreign_grefs[MAX_SKB_FRAGS];
+   struct xenvif *foreign_vif = NULL;
 
old_meta_prod = npo->meta_prod;
 
@@ -466,6 +478,26 @@ static int xenvif_gop_skb(struct sk_buff *skb,
npo->copy_off = 0;
npo->copy_gref = req->gref;
 
+   if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) &&
+(ubuf->callback == &xenvif_zerocopy_callback)) {
+   u16 pending_idx = ubuf->desc;
+   int i = 0;
+   struct pending_tx_info *temp =
+   container_of(ubuf,
+   struct pending_tx_info,
+   callback_struct);
+   foreign_vif =
+   container_of(temp - pending_idx,
+   struct xenvif,
+   pending_tx_info[0]);
+   do {
+   pending_idx = ubuf->desc;
+   ubuf = (struct ubuf_info *) ubuf->ctx;
+   foreign_grefs[i++] =
+   
foreign_vif->pending_tx_info[pending_idx].req.gref;
+   } while (ubuf);
+   }
+
data = skb->data;
while (data < skb_tail_pointer(skb)) {
unsigned int offset = offset_in_page(data);
@@ -475,7 +507,9 @@ static int xenvif_gop_skb(struct sk_buff *skb,
len = skb_tail_pointer(skb) - data;
 
xenvif_gop_frag_copy(vif, skb, npo,
-virt_to_page(data), len, offset, &head);
+virt_to_page(data), len, offset, &head,
+NULL,
+0);
data += len;
}
 
@@ -484,7 +518,9 @@ static int xenvif_gop_skb(struct sk_buff *skb,
 skb_frag_page(&skb_shinfo(skb)->frags[i]),
 skb_frag_size(&skb_shinfo(skb)->frags[i]),
 skb_shinfo(skb)->frags[i].page_offset,
-&head);
+&head,
+foreign_vif,
+foreign_grefs[i]);
}
 
return npo->meta_prod - old_meta_prod;
--
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 net-next RFC 3/5] xen-netback: Remove old TX grant copy definitons

[Zoltan Kiss]

These became obsolate with grant mapping.

Signed-off-by: Zoltan Kiss 
---
 drivers/net/xen-netback/common.h  |   37 +---
 drivers/net/xen-netback/netback.c |   48 ++---
 2 files changed, 3 insertions(+), 82 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 36a3fda..e82c82c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -46,39 +46,9 @@
 #include 
 
 typedef unsigned int pending_ring_idx_t;
-#define INVALID_PENDING_RING_IDX (~0U)
 
-/* For the head field in pending_tx_info: it is used to indicate
- * whether this tx info is the head of one or more coalesced requests.
- *
- * When head != INVALID_PENDING_RING_IDX, it means the start of a new
- * tx requests queue and the end of previous queue.
- *
- * An example sequence of head fields (I = INVALID_PENDING_RING_IDX):
- *
- * ...|0 I I I|5 I|9 I I I|...
- * -->|<-INUSE
- *
- * After consuming the first slot(s) we have:
- *
- * ...|V V V V|5 I|9 I I I|...
- * -FREE->|<-INUSE
- *
- * where V stands for "valid pending ring index". Any number other
- * than INVALID_PENDING_RING_IDX is OK. These entries are considered
- * free and can contain any number other than
- * INVALID_PENDING_RING_IDX. In practice we use 0.
- *
- * The in use non-INVALID_PENDING_RING_IDX (say 0, 5 and 9 in the
- * above example) number is the index into pending_tx_info and
- * mmap_pages arrays.
- */
 struct pending_tx_info {
-   struct xen_netif_tx_request req; /* coalesced tx request */
-   pending_ring_idx_t head; /* head != INVALID_PENDING_RING_IDX
- * if it is head of one or more tx
- * reqs
- */
+   struct xen_netif_tx_request req; /* tx request */
/* callback data for released SKBs. The callback is always
 * xenvif_zerocopy_callback, ctx points to the next fragment, desc
 * contains the pending_idx
@@ -128,11 +98,6 @@ struct xenvif {
struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
 
-   /* Coalescing tx requests before copying makes number of grant
-* copy ops greater or equal to number of slots required. In
-* worst case a tx request consumes 2 gnttab_copy.
-*/
-   struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS];
struct gnttab_unmap_grant_ref tx_unmap_ops[MAX_PENDING_REQS];
struct gnttab_map_grant_ref tx_map_ops[MAX_PENDING_REQS];
/* passed to gnttab_[un]map_refs with pages under (un)mapping */
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index e544e9f..c91dd36 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -70,16 +70,6 @@ module_param(fatal_skb_slots, uint, 0444);
  */
 #define XEN_NETBK_LEGACY_SLOTS_MAX XEN_NETIF_NR_SLOTS_MIN
 
-/*
- * If head != INVALID_PENDING_RING_IDX, it means this tx request is head of
- * one or more merged tx requests, otherwise it is the continuation of
- * previous tx request.
- */
-static inline int pending_tx_is_head(struct xenvif *vif, RING_IDX idx)
-{
-   return vif->pending_tx_info[idx].head != INVALID_PENDING_RING_IDX;
-}
-
 static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx,
   u8 status);
 
@@ -856,19 +846,6 @@ static int xenvif_count_requests(struct xenvif *vif,
return slots;
 }
 
-static struct page *xenvif_alloc_page(struct xenvif *vif,
- u16 pending_idx)
-{
-   struct page *page;
-
-   page = alloc_page(GFP_ATOMIC|__GFP_COLD);
-   if (!page)
-   return NULL;
-   vif->mmap_pages[pending_idx] = page;
-
-   return page;
-}
-
 static inline void xenvif_tx_create_gop(struct xenvif *vif, u16 pending_idx,
   struct xen_netif_tx_request *txp,
   struct gnttab_map_grant_ref *gop)
@@ -891,13 +868,9 @@ static struct gnttab_map_grant_ref 
*xenvif_get_requests(struct xenvif *vif,
struct skb_shared_info *shinfo = skb_shinfo(skb);
skb_frag_t *frags = shinfo->frags;
u16 pending_idx = *((u16 *)skb->data);
-   u16 head_idx = 0;
-   int slot, start;
-   struct page *page;
-   pending_ring_idx_t index, start_idx = 0;
-   uint16_t dst_offset;
+   int start;
+   pending_ring_idx_t index;
unsigned int nr_slots;
-   struct pending_tx_info *first = NULL;
 
/* At this point shinfo->nr_frags is in fact the number of
 * slots, which can be as large as XEN_NETBK_LEGACY_SLOTS_MAX.
@@ -918,18 +891,6 @@ static struct gnttab_map_grant_ref 
*xenvif_get_requests(struct xenvif *vif,
BUG_ON(shinfo->nr_frags > MAX_SKB_FRAGS);
 
return gop;
-err:
-   /* Unwind, freeing all pages and sending error responses. */
-   whil

[PATCH net-next RFC 0/5] xen-netback: TX grant mapping instead of copy

[Zoltan Kiss]

A long known problem of the upstream netback implementation that on the TX
path (from guest to Dom0) it copies the whole packet from guest memory into
Dom0. That simply became a bottleneck with 10Gb NICs, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series
(http://lwn.net/Articles/491522/) tried to solve this problem, however it
seems to be very invasive on the network stack's code, and therefore haven't
progressed very well.
This patch series use SKBTX_DEV_ZEROCOPY flags to tell the stack it needs to
know when the skb is freed up. That is the way KVM solved the same problem,
and based on my initial tests it can do the same for us. Avoiding the extra
copy boosted up TX throughput from 6.8 Gbps to 7.9 (I used a slower
Interlagos box, both Dom0 and guest on upstream kernel, on the same NUMA node,
running iperf 2.0.5, and the remote end was a bare metal box on the same 10Gb
switch)
Based on my investigations the packet get only copied if it is delivered to
Dom0 stack, which is due to this patch:
https://lkml.org/lkml/2012/7/20/363
That's a bit unfortunate, but as far as I know for the huge majority this use
case is not too important. There are a couple of things which need more
polishing, see the FIXME comments. I will run some more extensive tests, but
in the meantime I would like to hear comments about what I've done so far.
I've tried to broke it down to smaller patches, with mixed results, so I
welcome suggestions on that part as well:
1/5: Introduce TX grant map definitions
2/5: Change TX path from grant copy to mapping
3/5: Remove old TX grant copy definitons
4/5: Fix indentations
5/5: Change RX path for mapped SKB fragments

Signed-off-by: Zoltan Kiss 

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

Re: [PATCH v5 4/7] arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions

[Will Deacon]

On Fri, Oct 18, 2013 at 04:19:58PM +0100, Jiang Liu wrote:
> From: Jiang Liu 
> 
> Introduce aarch64_insn_gen_{nop|branch_imm}() helper functions, which
> will be used to implement jump label on ARM64.
> 
> Signed-off-by: Jiang Liu 
> Cc: Jiang Liu 
> ---
>  arch/arm64/include/asm/insn.h | 13 +
>  arch/arm64/kernel/insn.c  | 28 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
> index 8f94e48..ee4a60d 100644
> --- a/arch/arm64/include/asm/insn.h
> +++ b/arch/arm64/include/asm/insn.h
> @@ -96,9 +96,22 @@ static __always_inline void aarch64_insn_write(void *addr, 
> u32 insn)
>   *(u32 *)addr = cpu_to_le32(insn);
>  }
>  
> +static __always_inline u32 aarch64_insn_gen_hint(enum aarch64_insn_hint_op 
> op)
> +{
> + return aarch64_insn_get_hint_value() | op;

What's the point in that helper function? Does it just return an immediate
value (and are there are other users of it?).

> +}
> +
> +static __always_inline u32 aarch64_insn_gen_nop(void)
> +{
> + return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP);
> +}

Either use plain old `inline' or write these as preprocessor macros.

> +
>  enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
>  u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
> u32 insn, u64 imm);
> +u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
> + bool link);
> +
>  bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
>  
>  int aarch64_insn_patch_text_nosync(void *addr, u32 insn);
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index 886821f..f7498cc 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> @@ -14,6 +14,7 @@
>   * You should have received a copy of the GNU General Public License
>   * along with this program.  If not, see .
>   */
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -233,3 +234,30 @@ u32 aarch64_insn_encode_immediate(enum 
> aarch64_insn_imm_type type,
>  
>   return insn;
>  }
> +
> +u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, bool 
> link)
> +{
> + u32 insn;
> + long offset;
> +
> + /*
> +  * PC: A 64-bit Program Counter holding the address of the current
> +  * instruction. A64 instructions may be word-aligned.
> +  */
> + BUG_ON((pc & 0x3) || (addr & 0x3));
> +
> + /*
> +  * B/BL support [-128M, 128M) offset
> +  * ARM64 virtual address arrangement garantees all kernel and module

Typo: `guarantees'.

> +  * texts are within +/-128M.
> +  */
> + offset = ((long)addr - (long)pc) >> 2;
> + BUG_ON(abs(offset) > BIT(25) || offset == BIT(25));

I really struggle to follow this range checking. Why don't you just compare
the absolute difference between addr and pc with SZ_128M?

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/

Re: pull request for Tegra clock rework and Tegra124 clock support

[Peter De Schrijver]

Mike,

This is an update to the previous pull request which fixes some late bugs.

Thanks,

Peter.

The following changes since commit 6c984fc8c6314596c302bbecf79dc59d9f98f348:

  clk: tegra124: add suspend/resume function for tegra_cpu_car_ops (2013-10-21 
16:39:24 +0300)

are available in the git repository at:
  git://nv-tegra.nvidia.com/user/pdeschrijver/linux.git tegra-clk-tegra124-0

Mikko Perttunen (1):
  clk: tegra114: Initialize clocks needed for HDMI

Peter De Schrijver (1):
  clk: tegra: use pll_ref as the pll_e parent

Thierry Reding (2):
  clk: tegra: Initialize secondary gr3d clock on Tegra30
  clk: tegra: Properly setup PWM clock on Tegra30

 drivers/clk/tegra/clk-pll.c  |7 ---
 drivers/clk/tegra/clk-tegra114.c |5 -
 drivers/clk/tegra/clk-tegra30.c  |5 -
 3 files changed, 12 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter

[HATAYAMA Daisuke]

(2013/10/29 23:21), Baoquan He wrote:

Hi,

I am reviewing this patchset, and found there's a cpu0 hotplug feature
posted by intel which we can borrow an idea from. In that implementation,
CPU0 is waken up by nmi not INIT to avoid the realmode bootstrap code
execution. I tried it by below patch which includes one line of change.

By console printing, I got the boot cpu is always 0(namely cpu=0),
however the apicid related to each processor keeps the same as in 1st
kernel. In my HP Z420 machine, the apicid for BSP is 0, so I just make a
test patch which depends on the fact that apicid for BSP is 0. Maybe
generally the apicid for BSP can't be guaranteed, then passing it from
1st kernel to 2nd kernel in cmdline is very helpful, just as you have
done for disable_cpu_apic.

On my HP z420, I add nr_cpus=4 in /etc/sysconfig/kdump, and then execute
below command, then 3 APs (1 boot cpu and 2 AP) can be waken up
correctly, but BSP failed because NMI received for unknown reason 21 on
CPU0. I think I need further check why BSP failed to wake up by nmi. But
3 processors are brought up successfully and kdump is successful too.

sudo taskset -c 1 sh -c "echo c >/proc/sysrq-trigger"

[0.296831] smpboot: Booting Node   0, Processors  #   1
[0.302095]
*cpu=1, apicid=0, 
wakeup_cpu_via_init_nmi
[0.311942] cpu=1, apicid=0, register_nmi_handlercpu=1, apicid=0, 
wakeup_secondary_cpu_via_nmi
[0.320826] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[0.327129] Do you have a strange power saving mode enabled?
[0.333858] Dazed and confused, but trying to continue
[0.339290] cpu=1, apicid=0, wakeup_cpu_via_init_nmi
[2.409099] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[2.415393] Do you have a strange power saving mode enabled?
[2.421142] Dazed and confused, but trying to continue
[5.379519] smpboot: CPU1: Not responding
[5.383692] NMI watchdog: enabled on all CPUs, permanently consumes one 
hw-PMU counter.



We've already discussed this approach and concluded this is not applicable
to our issue.
Follow http://lists.infradead.org/pipermail/kexec/2012-October/006905.html.

The reason is:

- The cpu0-hotplugging approach assumes BSP to be halting before initiating
  NMI to it while in our case, BSP is halting in the 1st kernel or is
  running in arbitrary position of the 1st kernel in catastrophic state.

- In general, NMI modifies stack, which means if throwing NMI to the BSP
  in the 1st kernel, stack on the 1st kernel is modified. It's unpermissible
  from kdump's perspective.

- On x86_64, there are two cases where stack is changed to another one
  when receiving interrupts. One is when receiving interrupt in user mode.
  The other is when using Interrupt Stack Table (IST), which is already
  used in the current x86_64 implementation.

  By using either, it would be possible to wake up BSP in the 1st kernel
  by modifying the contexts on the 2nd kernel's NMI stack pushed on when NMI
  to the 1st kernel is initiated.

  However, this approach depends on the logic in the 1st kernel, there's
  no guarantee that it works well. Consider severely buggy situation again.

- To do this approach rigorously, we need to check if states of BSP and APs
  are kept in just what we assume in the place where logic is guaranteed to be
  sane, i.e., at least after purgatory. However, adding new logic in the
  purgatory means we are forced to introduce additional dependency between
  kernel and kexec. The process performed in purgatory itself is not so
  simple.I don't like this complication.

To sum up, I think the current idea is simple enough approach.

--
Thanks.
HATAYAMA, Daisuke

--
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] sysfs: move assignment to be under lock in sysfs_remove_dir()

[Eric W. Biederman]

Greg KH  writes:

> From: Greg Kroah-Hartman 
>
> Linus noticed that the assignment of sd isn't protected by the lock in
> sysfs_remove_dir(), so move the assignment of the variable under the
> lock to be safe.

I don't have a strong feeling either way but how would that matter?
There is only ever one sd associated with a kobj.

And we better be under the sysfs_mutex when the assignment and and
sysfs_remove_dir are called.

> Reported-by: Linus Torvalds 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>
> Tejun, any objection to this patch?  You consolidated the locks back in
> 2007 on this function, and nothing has changed there since then, so odds
> are it's not a problem, but nice to be safe, right?
>
>  fs/sysfs/dir.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index eab59de4..2609f934 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -856,9 +856,10 @@ void sysfs_remove(struct sysfs_dirent *sd)
>   */
>  void sysfs_remove_dir(struct kobject *kobj)
>  {
> - struct sysfs_dirent *sd = kobj->sd;
> + struct sysfs_dirent *sd;
>  
>   spin_lock(&sysfs_assoc_lock);
> + sd = kobj->sd;
>   kobj->sd = NULL;
>   spin_unlock(&sysfs_assoc_lock);
>  
--
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] clk: tegra: use pll_ref as the pll_e parent

[Peter De Schrijver]

Use pll_ref instead of pll_re_vco as the pll_e parent on Tegra114 and
Tegra124. Also add a pll_ref table entry for pll_e for Tegra114.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c  |7 ---
 drivers/clk/tegra/clk-tegra114.c |3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 7d775a9..193457b 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -1712,11 +1712,12 @@ struct clk *tegra_clk_register_plle_tegra114(const char 
*name,
val_aux = pll_readl(pll_params->aux_reg, pll);
 
if (val & PLL_BASE_ENABLE) {
-   if (!(val_aux & PLLE_AUX_PLLRE_SEL))
+   if ((val_aux & PLLE_AUX_PLLRE_SEL) || (val_aux & val_aux))
WARN(1, "pll_e enabled with unsupported parent %s\n",
- (val & PLLE_AUX_PLLP_SEL) ? "pllp_out0" : "pll_ref");
+ (val_aux & PLLE_AUX_PLLP_SEL) ? "pllp_out0" :
+   "pll_re_vco");
} else {
-   val_aux |= PLLE_AUX_PLLRE_SEL;
+   val_aux &= ~(PLLE_AUX_PLLRE_SEL | PLLE_AUX_PLLP_SEL);
pll_writel(val, pll_params->aux_reg, pll);
}
 
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index e365b35..5cfcd3e 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -560,6 +560,7 @@ static struct tegra_clk_pll_freq_table pll_e_freq_table[] = 
{
/* PLLE special case: use cpcon field to store cml divider value */
{33600, 1, 100, 21, 16, 11},
{31200, 1, 200, 26, 24, 13},
+   {1200, 1, 200,  1,  24, 13},
{0, 0, 0, 0, 0, 0},
 };
 
@@ -1178,7 +1179,7 @@ static void __init tegra114_pll_init(void __iomem 
*clk_base,
clks[TEGRA114_CLK_PLL_RE_OUT] = clk;
 
/* PLLE */
-   clk = tegra_clk_register_plle_tegra114("pll_e_out0", "pll_re_vco",
+   clk = tegra_clk_register_plle_tegra114("pll_e_out0", "pll_ref",
  clk_base, 0, &pll_e_params, NULL);
clks[TEGRA114_CLK_PLL_E_OUT0] = clk;
 }
-- 
1.7.7.rc0.72.g4b5ea.dirty

--
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] dma: mv_xor: Use high_base mmio where appropriate

[Dan Williams]

On Tue, Oct 29, 2013 at 5:33 PM, Ezequiel Garcia
 wrote:
> By the way, I didn't initially Cced dmaengine list because it's not
> in the MAINTAINERS file.
>
> How about we add it and avoid this happening to other developers?

It's there now, but we just created it so you happened to be one of
the first ones through...

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n2728

--
Dan
--
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] tpm/tpm_i2c_stm_st33: Check return code of get_burstcount (fix CID: 986658)

[Peter Hüwe]

Hi Greg,
> > 
> > CID: 986658
> What is this field for?

That's the scan id in the coverity database.
If you think that's just noise I can leave it out.

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