Re: [PATCH v3 1/8] x86: Kill E820_RESERVED_KERN
On Sat, Mar 7, 2015 at 5:59 PM, David Rientjes wrote: > > Hmm, although the bug is reported for a 3.12 kernel, I assume this is for > stable 3.10+? If so, it should apply fine with the exception of removing > e820_reserve_setup_data() from setup_arch() rather than > memblock_x86_reserve_range_setup_data(). Or is it for 3.2 as well and > needs to be completely rebased for that kernel? For 3.10+, we will need to following patches, otherwise will have warning for SETUP_PCI with ioremap. for 3.2 that does not SETUP_PCI, should be ok, but will need rebase. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 0/7] randomize kernel physical address and virtual address separately
Currently kaslr only randomize physical address of kernel loading, then add the delta to virtual address of kernel text mapping. Because kernel virtual address can only be from __START_KERNEL_map to LOAD_PHYSICAL_ADDR+CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely [0x8000, 0xc000], so physical address can only be randomized in region [LOAD_PHYSICAL_ADDR, CONFIG_RANDOMIZE_BASE_MAX_OFFSET], namely [16M, 1G]. So hpa and Vivek suggested the randomization should be done separately for both physical and virtual address. In this patchset the behavior is changed. Randomize both the physical address where kernel is decompressed and the virtual address where kernel text is mapped. And physical address can be randomized from where vmlinux was linked to load to maximum physical memory, possibly near 64T. While virtual address can get a random offset from load address to CONFIG_RANDOMIZE_BASE_MAX_OFFSET, then added to __START_KERNEL_map. And relocation handling only depends on virtual address randomization. Means if and only if virtual address is randomized to a different value, add the delta to the offset of kernel relocs. This patchset depends on Yinghai's patch set which makes kaslr clean up and build ident mapping to make kernel be able to be reloaded above 4G. People can get his related patchset in below link, then apply this patchset on top of it for testing and reviewing. https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-4.0-rc2-aslr or git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-4.0-rc2-aslr Issue need be discussed: Currently kaslr only randomize from the original address where bootloader put kernel. However some bootloaders may put kernel in a very high address. Then possibly a very huge region below that address won't be calculated and added as candidate slots. Yinghai uses a patched grub2 to do this right now, put kernel near 5G. And he suggested moving down random base to 512M when it's bigger than this value. But 512M seems a little arbitrary because I can't see its theoretical foundation. I am wondering how about 16M since Yinghai said currently all related data in boot stage has been avoided safely. Any opinion? v1->v2: Thanks to Yinghai's patch which make kernel be able to load above 4G in boot stage, physical address can be randomized anywhere, even near 64T. v2>v3: Rearrange patchset to make it bisect-able according to Yinghai's comment. Fix two code bugs in process_e820_entry and slots_fetch_random. Baoquan He (7): x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G x86, kaslr: Introduce struct slot_area to manage randomization slot info x86, kaslr: Add two functions which will be used later x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text mapping address x86, kaslr: Randomize physical and virtual address of kernel separately x86, kaslr: Add support of kernel physical address randomization above 4G x86, kaslr: Remove useless codes arch/x86/boot/compressed/aslr.c | 215 +--- arch/x86/boot/compressed/misc.c | 41 +--- arch/x86/boot/compressed/misc.h | 24 +++-- 3 files changed, 194 insertions(+), 86 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 2/7] x86, kaslr: Introduce struct slot_area to manage randomization slot info
Kernel is expected to be randomly reloaded anywhere in the whole
physical memory area, it could be near 64T at most. In this case
there could be about 4*1024*1024 randomization slots. Hence the
old slot array will cost too much memory and also not efficient
to store the slot information one by one into slot array.
Here introduce struct slot_area to manage randomization slot info
in one contiguous memory area excluding the avoid area. slot_areas
is used to store all slot area info. Since setup_data is a linked
list, could contain many datas by pointer to point one by one,
excluding them will split RAM memory into many smaller areas, here
only take the first 100 slot areas if too many of them.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 34eb652..c452a60 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -232,8 +232,20 @@ static bool mem_avoid_overlap(struct mem_vector *img)
static unsigned long slots[CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
CONFIG_PHYSICAL_ALIGN];
+
+struct slot_area {
+ unsigned long addr;
+ int num;
+};
+
+#define MAX_SLOT_AREA 100
+
+static struct slot_area slot_areas[MAX_SLOT_AREA];
+
static unsigned long slot_max;
+static unsigned long slot_area_index;
+
static void slots_append(unsigned long addr)
{
/* Overflowing the slots list should be impossible. */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 4/7] x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text mapping address
Kaslr extended kernel text mapping region size from 512M to 1G,
namely CONFIG_RANDOMIZE_BASE_MAX_OFFSET. This means kernel text
can be mapped to below region:
[__START_KERNEL_map + LOAD_PHYSICAL_ADDR, __START_KERNEL_map + 1G]
Introduce a function find_random_virt_offset() to get random value
between LOAD_PHYSICAL_ADDR and CONFIG_RANDOMIZE_BASE_MAX_OFFSET.
This random value will be added to __START_KERNEL_map to get the
starting address which kernel text is mapped from. Since slot can
be anywhere of this region, means it is an independent slot_area,
it is simple to get a slot according to random value.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index afb1641..0ca4c5b 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -382,6 +382,28 @@ static unsigned long find_random_addr(unsigned long
minimum,
return slots_fetch_random();
}
+static unsigned long find_random_virt_offset(unsigned long minimum,
+ unsigned long image_size)
+{
+ unsigned long slot_num, random;
+
+ /* Make sure minimum is aligned. */
+ minimum = ALIGN(minimum, CONFIG_PHYSICAL_ALIGN);
+
+ if (image_size <= CONFIG_PHYSICAL_ALIGN)
+ slot_num = (CONFIG_RANDOMIZE_BASE_MAX_OFFSET - minimum) /
+ CONFIG_PHYSICAL_ALIGN;
+ else
+ slot_num = (CONFIG_RANDOMIZE_BASE_MAX_OFFSET -
+ minimum - image_size) /
+ CONFIG_PHYSICAL_ALIGN + 1;
+
+ random = get_random_long() % slot_num;
+
+ return random * CONFIG_PHYSICAL_ALIGN + minimum;
+}
+
+
static void add_kaslr_setup_data(struct boot_params *params, __u8 enabled)
{
struct setup_data *data;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 3/7] x86, kaslr: Add two functions which will be used later
Add two functions mem_min_overlap() and store_slot_info() which will be
used later.
Given a memory region mem_min_overlap will iterate all avoid region to
find the first one which overlap with it.
store_slot_info() calculates the slot info of passed in region and
store it into slot_areas[].
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index c452a60..afb1641 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -230,6 +230,40 @@ static bool mem_avoid_overlap(struct mem_vector *img)
return false;
}
+static unsigned long
+mem_min_overlap(struct mem_vector *img, struct mem_vector *out)
+{
+ int i;
+ struct setup_data *ptr;
+ unsigned long min = img->start + img->size;
+
+ for (i = 0; i < MEM_AVOID_MAX; i++) {
+ if (mem_overlaps(img, &mem_avoid[i]) &&
+ (mem_avoid[i].start < min)) {
+ *out = mem_avoid[i];
+ min = mem_avoid[i].start;
+ }
+ }
+
+ /* Check all entries in the setup_data linked list. */
+ ptr = (struct setup_data *)(unsigned long)real_mode->hdr.setup_data;
+ while (ptr) {
+ struct mem_vector avoid;
+
+ avoid.start = (unsigned long)ptr;
+ avoid.size = sizeof(*ptr) + ptr->len;
+
+ if (mem_overlaps(img, &avoid) && (avoid.start < min)) {
+ *out = avoid;
+ min = avoid.start;
+ }
+
+ ptr = (struct setup_data *)(unsigned long)ptr->next;
+ }
+
+ return min;
+}
+
static unsigned long slots[CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
CONFIG_PHYSICAL_ALIGN];
@@ -246,6 +280,23 @@ static unsigned long slot_max;
static unsigned long slot_area_index;
+static void store_slot_info(struct mem_vector *region, unsigned long
image_size)
+{
+ struct slot_area slot_area;
+
+ slot_area.addr = region->start;
+ if (image_size <= CONFIG_PHYSICAL_ALIGN)
+ slot_area.num = region->size / CONFIG_PHYSICAL_ALIGN;
+ else
+ slot_area.num = (region->size - image_size) /
+ CONFIG_PHYSICAL_ALIGN + 1;
+
+ if (slot_area.num > 0) {
+ slot_areas[slot_area_index++] = slot_area;
+ slot_max += slot_area.num;
+ }
+}
+
static void slots_append(unsigned long addr)
{
/* Overflowing the slots list should be impossible. */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/3] irqchip: vf610-mscm: add MSCM interrupt router driver
On Sun, Mar 01, 2015 at 11:41:26PM +0100, Stefan Agner wrote: ... > Stefan Agner (3): > irqchip: vf610-mscm-ir: add support for MSCM interrupt router > irqchip: vf610-mscm: dt-bindings: add MSCM bindings > ARM: dts: vf610: add Miscellaneous System Control Module (MSCM) > > .../arm/freescale/fsl,vf610-mscm-cpucfg.txt| 14 ++ > .../bindings/arm/freescale/fsl,vf610-mscm-ir.txt | 33 > arch/arm/boot/dts/vf500.dtsi | 137 + > arch/arm/boot/dts/vfxxx.dtsi | 49 + > arch/arm/mach-imx/Kconfig | 1 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-vf610-mscm-ir.c| 212 > + > 7 files changed, 314 insertions(+), 133 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt > create mode 100644 > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt > create mode 100644 drivers/irqchip/irq-vf610-mscm-ir.c Applied patches 1 and 2 to irqchip/vybrid. Please let me know if you need to base other work off of this. thx, 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/
[Patch v3 7/7] x86, kaslr: Remove useless codes
Several auxiliary functions and slots[] are not needed any more since
struct slot_area is used to store the slot info of kaslr now. Hence
remove them in this patch.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 24
1 file changed, 24 deletions(-)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 2cf8f82..ce6ee28 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -126,17 +126,6 @@ struct mem_vector {
#define MEM_AVOID_MAX 4
static struct mem_vector mem_avoid[MEM_AVOID_MAX];
-static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
-{
- /* Item at least partially before region. */
- if (item->start < region->start)
- return false;
- /* Item at least partially after region. */
- if (item->start + item->size > region->start + region->size)
- return false;
- return true;
-}
-
static bool mem_overlaps(struct mem_vector *one, struct mem_vector *two)
{
/* Item one is entirely before item two. */
@@ -264,9 +253,6 @@ mem_min_overlap(struct mem_vector *img, struct mem_vector
*out)
return min;
}
-static unsigned long slots[CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
- CONFIG_PHYSICAL_ALIGN];
-
struct slot_area {
unsigned long addr;
int num;
@@ -297,16 +283,6 @@ static void store_slot_info(struct mem_vector *region,
unsigned long image_size)
}
}
-static void slots_append(unsigned long addr)
-{
- /* Overflowing the slots list should be impossible. */
- if (slot_max >= CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
- CONFIG_PHYSICAL_ALIGN)
- return;
-
- slots[slot_max++] = addr;
-}
-
static unsigned long slots_fetch_random(void)
{
unsigned long random;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 5/7] x86, kaslr: Randomize physical and virtual address of kernel separately
On x86_64, in old kaslr implementaion only physical address of kernel
loading is randomized. Then calculate the delta of physical address
where vmlinux was linked to load and where it is finally loaded. If
delta is not equal to 0, namely there's a new physical address where
kernel is actually decompressed, relocation handling need be done. Then
delta is added to offset of kernel symbol relocation, this makes the
address of kernel text mapping move delta long.
Here the behavior is changed. Randomize both the physical address
where kernel is decompressed and the virtual address where kernel text
is mapped. And relocation handling only depends on virtual address
randomization. Means if and only if virtual address is randomized to
a different value, we add the delta to the offset of kernel relocs.
Note that up to now both virtual offset and physical addr randomization
cann't exceed CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely 1G.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 48 +
arch/x86/boot/compressed/misc.c | 39 -
arch/x86/boot/compressed/misc.h | 24 +++--
3 files changed, 62 insertions(+), 49 deletions(-)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 0ca4c5b..5f9f174 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -365,7 +365,7 @@ static void process_e820_entry(struct e820entry *entry,
}
}
-static unsigned long find_random_addr(unsigned long minimum,
+static unsigned long find_random_phy_addr(unsigned long minimum,
unsigned long size)
{
int i;
@@ -425,49 +425,51 @@ static void add_kaslr_setup_data(struct boot_params
*params, __u8 enabled)
}
-unsigned char *choose_kernel_location(struct boot_params *params,
- unsigned char *input,
- unsigned long input_size,
- unsigned char *output,
- unsigned long init_size)
+void choose_kernel_location(struct boot_params *params,
+ unsigned char *input,
+ unsigned long input_size,
+ unsigned char **output,
+ unsigned long init_size,
+ unsigned char **virt_offset)
{
- unsigned long choice = (unsigned long)output;
unsigned long random;
+ *virt_offset = (unsigned char *)LOAD_PHYSICAL_ADDR;
#ifdef CONFIG_HIBERNATION
if (!cmdline_find_option_bool("kaslr")) {
debug_putstr("KASLR disabled by default...\n");
add_kaslr_setup_data(params, 0);
- goto out;
+ return;
}
#else
if (cmdline_find_option_bool("nokaslr")) {
debug_putstr("KASLR disabled by cmdline...\n");
add_kaslr_setup_data(params, 0);
- goto out;
+ return;
}
#endif
add_kaslr_setup_data(params, 1);
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigned long)input, input_size,
- (unsigned long)output, init_size);
+ (unsigned long)*output, init_size);
/* Walk e820 and find a random address. */
- random = find_random_addr(choice, init_size);
- if (!random) {
+ random = find_random_phy_addr((unsigned long)*output, init_size);
+ if (!random)
debug_putstr("KASLR could not find suitable E820 region...\n");
- goto out;
+ else {
+ if ((unsigned long)*output != random) {
+ fill_pagetable(random, init_size);
+ switch_pagetable();
+ *output = (unsigned char *)random;
+ }
}
- /* Always enforce the minimum. */
- if (random < choice)
- goto out;
-
- choice = random;
-
- fill_pagetable(choice, init_size);
- switch_pagetable();
-out:
- return (unsigned char *)choice;
+ /*
+* Get a random address between LOAD_PHYSICAL_ADDR and
+* CONFIG_RANDOMIZE_BASE_MAX_OFFSET
+*/
+ random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, init_size);
+ *virt_offset = (unsigned char *)random;
}
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index f3ca33e..78380af 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -231,7 +231,8 @@ static void error(char *x)
}
#if CONFIG_X86_NEED_RELOCS
-static void handle_relocations(void *output, unsigned long output_len)
+static void handle_relocations(void *output, unsigned long output_len,
+ void *virt_offset)
{
int *reloc;
unsigned long delta, ma
[Patch v3 6/7] x86, kaslr: Add support of kernel physical address randomization above 4G
In kaslr implementation mechanism, mainly process_e820_entry and
slots_fetch_random do the job. process_e820_entry is responsible
for storing the slot information. slots_fetch_random takes care
of fetching slot information. In this patch, for adding support
of kernel physical address randomization above 4G, both of these
two functions are changed based on the new slot_area data structure.
Now kernel can be reloaded and decompressed anywhere of the whole
physical memory, even near 64T at most.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 68 ++---
1 file changed, 51 insertions(+), 17 deletions(-)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 5f9f174..2cf8f82 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -309,27 +309,40 @@ static void slots_append(unsigned long addr)
static unsigned long slots_fetch_random(void)
{
+ unsigned long random;
+ int i;
+
/* Handle case of no slots stored. */
if (slot_max == 0)
return 0;
- return slots[get_random_long() % slot_max];
+ random = get_random_long() % slot_max;
+
+ for (i = 0; i < slot_area_index; i++) {
+ if (random >= slot_areas[i].num) {
+ random -= slot_areas[i].num;
+ continue;
+ }
+ return slot_areas[i].addr + random * CONFIG_PHYSICAL_ALIGN;
+ }
+
+ if (i == slot_area_index)
+ debug_putstr("Something wrong happened in
slots_fetch_random()...\n");
+ return 0;
}
static void process_e820_entry(struct e820entry *entry,
unsigned long minimum,
unsigned long image_size)
{
- struct mem_vector region, img;
+ struct mem_vector region, out;
+ struct slot_area slot_area;
+ unsigned long min, start_orig;
/* Skip non-RAM entries. */
if (entry->type != E820_RAM)
return;
- /* Ignore entries entirely above our maximum. */
- if (entry->addr >= CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
- return;
-
/* Ignore entries entirely below our minimum. */
if (entry->addr + entry->size < minimum)
return;
@@ -337,10 +350,17 @@ static void process_e820_entry(struct e820entry *entry,
region.start = entry->addr;
region.size = entry->size;
+repeat:
+ start_orig = region.start;
+
/* Potentially raise address to minimum location. */
if (region.start < minimum)
region.start = minimum;
+ /* Return if slot area array is full */
+ if (slot_area_index == MAX_SLOT_AREA)
+ return;
+
/* Potentially raise address to meet alignment requirements. */
region.start = ALIGN(region.start, CONFIG_PHYSICAL_ALIGN);
@@ -349,20 +369,30 @@ static void process_e820_entry(struct e820entry *entry,
return;
/* Reduce size by any delta from the original address. */
- region.size -= region.start - entry->addr;
+ region.size -= region.start - start_orig;
- /* Reduce maximum size to fit end of image within maximum limit. */
- if (region.start + region.size > CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
- region.size = CONFIG_RANDOMIZE_BASE_MAX_OFFSET - region.start;
+ /* Return if region can't contain decompressed kernel */
+ if (region.size < image_size)
+ return;
- /* Walk each aligned slot and check for avoided areas. */
- for (img.start = region.start, img.size = image_size ;
-mem_contains(®ion, &img) ;
-img.start += CONFIG_PHYSICAL_ALIGN) {
- if (mem_avoid_overlap(&img))
- continue;
- slots_append(img.start);
+ if (!mem_avoid_overlap(®ion)) {
+ store_slot_info(®ion, image_size);
+ return;
}
+
+ min = mem_min_overlap(®ion, &out);
+
+ if (min > region.start + image_size) {
+ struct mem_vector tmp;
+
+ tmp.start = region.start;
+ tmp.size = min - region.start;
+ store_slot_info(&tmp, image_size);
+ }
+
+ region.size -= out.start - region.start + out.size;
+ region.start = out.start + out.size;
+ goto repeat;
}
static unsigned long find_random_phy_addr(unsigned long minimum,
@@ -377,6 +407,10 @@ static unsigned long find_random_phy_addr(unsigned long
minimum,
/* Verify potential e820 positions, appending to slots list. */
for (i = 0; i < real_mode->e820_entries; i++) {
process_e820_entry(&real_mode->e820_map[i], minimum, size);
+ if (slot_area_index == MAX_SLOT_AREA) {
+ debug_putstr("Stop processing e820 since slot_areas is
full...\n");
+ break
[Patch v3 1/7] x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G
When process 32 bit relocation tables a local variable extended is
defined to calculate the physical address of relocs entry. However
it's type is int which is enough for i386, for x86_64 not enough.
That's why relocation can only be handled when kernel is loaded
below 2G, otherwise a overflow will happen and cause system hang.
Here change it to long as 32 bit inverse relocation processing does,
and this change is safe for i386 relocation handling too.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 51e9e54..f3ca33e 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -278,7 +278,7 @@ static void handle_relocations(void *output, unsigned long
output_len)
* So we work backwards from the end of the decompressed image.
*/
for (reloc = output + output_len - sizeof(*reloc); *reloc; reloc--) {
- int extended = *reloc;
+ long extended = *reloc;
extended += map;
ptr = (unsigned long)extended;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Input: elan_i2c - Return error code when resume fail.
On Sat, Mar 07, 2015 at 07:42:47PM +0800, Duson Lin wrote:
> The resume function always return success, so stop event can not be
> triggered when "suspend_stress_test" running. In order to debug more
> easily, we add some error messages in elan_enable_power and
> elan_disable_power funtion.
>
> Signed-off-by: Duson Lin
Applied, thank you.
> ---
> drivers/input/mouse/elan_i2c_core.c | 10 +++---
> drivers/input/mouse/elan_i2c_i2c.c |7 ++-
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 16f9584..f24078b 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -111,6 +111,7 @@ static int elan_enable_power(struct elan_tp_data *data)
> msleep(30);
> } while (--repeat > 0);
>
> + dev_err(&data->client->dev, "Failed to enable power\n");
> return error;
> }
>
> @@ -138,6 +139,7 @@ static int elan_disable_power(struct elan_tp_data *data)
> msleep(30);
> } while (--repeat > 0);
>
> + dev_err(&data->client->dev, "Failed to disable power\n");
> return error;
> }
>
> @@ -1084,16 +1086,18 @@ static int __maybe_unused elan_resume(struct device
> *dev)
> }
>
> error = elan_enable_power(data);
> - if (error)
> + if (error) {
> dev_err(dev, "power up when resuming failed: %d\n", error);
> + goto err;
> + }
>
> error = elan_initialize(data);
> if (error)
> dev_err(dev, "initialize when resuming failed: %d\n", error);
>
> +err:
> enable_irq(data->client->irq);
> -
> - return 0;
> + return error;
> }
>
> static SIMPLE_DEV_PM_OPS(elan_pm_ops, elan_suspend, elan_resume);
> diff --git a/drivers/input/mouse/elan_i2c_i2c.c
> b/drivers/input/mouse/elan_i2c_i2c.c
> index 029941f..e29b28c 100644
> --- a/drivers/input/mouse/elan_i2c_i2c.c
> +++ b/drivers/input/mouse/elan_i2c_i2c.c
> @@ -117,7 +117,12 @@ static int elan_i2c_write_cmd(struct i2c_client *client,
> u16 reg, u16 cmd)
> int ret;
>
> ret = i2c_transfer(client->adapter, &msg, 1);
> - return ret == 1 ? 0 : (ret < 0 ? ret : -EIO);
> + if (ret != 1) {
> + dev_err(&client->dev, "writing cmd (0x%04x) fail.\n", reg);
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> }
>
> static int elan_i2c_initialize(struct i2c_client *client)
> --
> 1.7.10.4
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 4/5] Input: add haptic drvier on max77843
On Sat, Mar 07, 2015 at 09:21:02PM +0100, Sebastian Reichel wrote: > Hi, > > On Wed, Mar 04, 2015 at 02:47:42PM -0800, Dmitry Torokhov wrote: > > [...] > > > >Do you want it to go through my or MFD tree? > > > Other drivers merged in each maintainers git. > > Actually only Lee took PATCH 1 so far. > > > > If you don`t hava a problem, please merge your input git tree. > > > > Applied, thank you. > > Patches 2-4 depend on linux/mfd/max77843-private.h from Patch 1, > so taking them independently will introduce build problems. Luckily at least the input driver depends no MFD core so while I agree that the situation is not ideal it is pretty safe since make *config will not allow selecting it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, Mar 07, 2015 at 11:38:55PM +0100, Paul Bolle wrote:
> On Sat, 2015-03-07 at 14:26 -0800, Dmitry Torokhov wrote:
> > On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote:
> > I was talking about them being treated differently from technological
> > standpoint (i.e. the code), not from legal one.
>
> From a technological standpoint it would be easy to declare "GPL" (or
> any other string) to mean "GPL v2 compatible", which is, I think, all
> that matters. But license_is_gpl_compatible() doesn't do that. And I
> fear that's for a reason. Is my fear unfounded?
Well we might ask Rusty on the off chance that he remembers but my guess
would be that he added "GPL v2" in addition to "GPL" and other license
stings because at the time there was one driver,
drivers/net/tulip/xircom_tulip_cb.c, that used MODULE_LICENSE("GPL v2").
>
> > If you want to fix up input drivers I'll take such patch, but I am
> > sure more such cases will sneak in unless you also make sure that
> > there are tools (such as checkpatch.pl) that can alert developers to
> >the inconsistency.
>
> checkpatch.pl crossed my mind too. But in just over a week of checking
> the license comments of (a subset of) the submitted patches I've come to
> think that just won't work.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/8] irqchip: New driver for ST's SysCfg controlled IRQs
Lee, On Wed, Feb 18, 2015 at 03:13:56PM +, Lee Jones wrote: > Rebased (again) and resending. > > This driver enables IRQs which are controlled using System Configuration > registers. Without it Performance Monitoring, Core Sight Tracing and some > L2 Caches will fail to function. > > v2 => v3: > - Removed filename from header as suggested by Thomas > > v1 => v2: > - Fixed up Jason's review comments > > Lee Jones (8): > dt: bindings: Supply shared ST IRQ defines > irqchip: Supply new driver for STi based devices > irqchip: irq-st: Add documentation for STi based syscfg IRQs ... > .../interrupt-controller/st,sti-irq-syscfg.txt | 35 ... > drivers/irqchip/Kconfig| 7 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-st.c | 206 > + > include/dt-bindings/interrupt-controller/irq-st.h | 30 +++ ... > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt > create mode 100644 drivers/irqchip/irq-st.c > create mode 100644 include/dt-bindings/interrupt-controller/irq-st.h Patches 1-3 applied to irqchip/st several days ago. Sorry for not letting you know earlier. I'm just getting things back in order from hardware failures in my build machine *and* my mailserver. It's been a rough week. :-/ Let me know if you'd like to use that branch as a stable base. thx, 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/
Re: [PATCH] irqchip: renesas-irqc: Use u32 to store 32-bit register values
Geert, On Thu, Feb 26, 2015 at 11:43:32AM +0100, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > drivers/irqchip/irq-renesas-irqc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to irqchip/core several days ago (my mailserver was down). thx, 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/
[PATCH] usb gadget: remove size limitation for storage cdrom
I used usb cdrom emulation to play video dvd for my daughter, but I got below
error:
[dave@darkstar tmp]$ cat /mnt/sr1/VIDEO_TS/VTS_01_5.VOB >/dev/null
cat: /mnt/sr1/VIDEO_TS/VTS_01_5.VOB: Input/output error
[dave@darkstar tmp]$ dmesg|tail -1
[ 3349.371857] sr1: rw=0, want=8028824, limit=4607996
The assumption of cdrom size is not right, we can create data dvd large then
4G, also mkisofs can create an iso with only one blank directory, the size is
less than 300 sectors. The size limit does not make sense, thus remove them.
Signed-off-by: Dave Young
---
drivers/usb/gadget/function/storage_common.c |9 -
1 file changed, 9 deletions(-)
--- linux.orig/drivers/usb/gadget/function/storage_common.c
+++ linux/drivers/usb/gadget/function/storage_common.c
@@ -247,15 +247,6 @@ int fsg_lun_open(struct fsg_lun *curlun,
num_sectors = size >> blkbits; /* File size in logic-block-size blocks
*/
min_sectors = 1;
- if (curlun->cdrom) {
- min_sectors = 300; /* Smallest track is 300 frames */
- if (num_sectors >= 256*60*75) {
- num_sectors = 256*60*75 - 1;
- LINFO(curlun, "file too big: %s\n", filename);
- LINFO(curlun, "using only first %d blocks\n",
- (int) num_sectors);
- }
- }
if (num_sectors < min_sectors) {
LINFO(curlun, "file too small: %s\n", filename);
rc = -ETOOSMALL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 3/4] psmouse: Disable resolution/rate/scale changes for FocalTech touchpads.
Hi Mathias,
On Fri, Feb 27, 2015 at 12:20:07AM +0100, Mathias Gottschlag wrote:
> These PS/2 commands make some touchpads stop responding, so this commit
> adds some dummy functions to replace the generic implementation. Because
> @@ -60,6 +65,7 @@ struct psmouse {
>
> unsigned int rate;
> unsigned int resolution;
> + enum psmouse_scale scale;
> unsigned int resetafter;
> unsigned int resync_time;
> bool smartscroll; /* Logitech only */
I do not believe we need to store the scaling factor so I dropped these
chunks, otherwise applied all 4.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver
Hi Yong Wu,
Thanks for this series. Please see my comments inline.
On Fri, Mar 6, 2015 at 7:48 PM, wrote:
> From: Yong Wu
>
> This patch adds support for mediatek m4u (MultiMedia Memory Management Unit).
> Currently this only supports m4u gen 2 with 2 levels of page table on mt8173.
[snip]
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> new file mode 100644
> index 000..d62d4ab
> --- /dev/null
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -0,0 +1,754 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Yong Wu
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt) "m4u:"fmt
This format is not very useful, especially when using dev_ helpers
prepends messages with device name.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_iommu.h"
CodingStyle: The definitions below do not seem to be aligned
correctly. Please make sure all the values are in the same column and
are aligned using tabs only (remembering that tab width specified by
Linux coding style is 8 characters).
> +
> +#define REG_MMUG_PT_BASE0x0
> +
> +#define REG_MMU_INVLD 0x20
> +#define F_MMU_INV_ALL 0x2
> +#define F_MMU_INV_RANGE 0x1
> +
> +#define REG_MMU_INVLD_SA0x24
> +#define REG_MMU_INVLD_EA 0x28
> +
> +#define REG_MMU_INVLD_SEC 0x2c
> +#define F_MMU_INV_SEC_ALL 0x2
> +#define F_MMU_INV_SEC_RANGE0x1
> +
> +#define REG_INVLID_SEL 0x38
> +#define F_MMU_INV_EN_L1 BIT(0)
> +#define F_MMU_INV_EN_L2 BIT(1)
> +
> +#define REG_MMU_STANDARD_AXI_MODE 0x48
> +#define REG_MMU_DCM_DIS 0x50
> +#define REG_MMU_LEGACY_4KB_MODE 0x60
> +
> +#define REG_MMU_CTRL_REG 0x110
> +#define F_MMU_CTRL_REROUTE_PFQ_TO_MQ_EN BIT(4)
> +#define F_MMU_CTRL_TF_PROT_VAL(prot) (((prot) & 0x3)<<5)
CodingStyle: Operators (e.g. <<) should have spaces on both sides.
> +#define F_MMU_CTRL_COHERE_EN BIT(8)
> +
> +#define REG_MMU_IVRP_PADDR 0x114
> +#define F_MMU_IVRP_PA_SET(PA)(PA>>1)
Please make sure that all references to macro arguments in macro
definitions are surrounded by parentheses to avoid issues with
operator precedence. (i.e. ((pa) >> 1))
CodingStyle: Macro arguments should be lowercase.
> +
> +#define REG_MMU_INT_L2_CONTROL 0x120
> +#define F_INT_L2_CLR_BITBIT(12)
> +
> +#define REG_MMU_INT_MAIN_CONTROL0x124
> +#define F_INT_TRANSLATION_FAULT(MMU)
> (1<<(0+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_MAIN_MULTI_HIT_FAULT(MMU)
> (1<<(1+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_INVALID_PA_FAULT(MMU)
> (1<<(2+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_ENTRY_REPLACEMENT_FAULT(MMU)
> (1<<(3+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_TLB_MISS_FAULT(MMU)
> (1<<(4+(((MMU)<<1)|((MMU)<<2
> +#define F_INT_PFH_FIFO_ERR(MMU)
> (1<<(6+(((MMU)<<1)|((MMU)<<2
Multiple coding style issues in these 6 macros, as per my comments above.
> +
> +#define REG_MMU_CPE_DONE 0x12C
> +
> +#define REG_MMU_MAIN_FAULT_ST 0x134
> +
> +#define REG_MMU_FAULT_VA(mmu) (0x13c+((mmu)<<3))
> +#define F_MMU_FAULT_VA_MSK((~0x0)<<12)
Please specify the mask manually to avoid ambiguities with result type.
+ CodingStyle
> +#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
> +#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
> +
> +#define REG_MMU_INVLD_PA(mmu) (0x140+((mmu)<<3))
> +#define REG_MMU_INT_ID(mmu) (0x150+((mmu)<<2))
> +#define F_MMU0_INT_ID_TF_MSK (~0x3) /* only for MM iommu. */
Ditto.
> +
> +#define MTK_TFID(larbid, portid) ((larbid << 7) | (portid << 2))
Missing parentheses around macro arguments.
> +
> +static const struct mtk_iommu_port mtk_iommu_mt8173_port[] = {
> + /* port namem4uid slaveid larbid portid tfid */
> + /* larb0 */
> + {"M4U_PORT_DISP_OVL0", 0, 0,0, 0, MTK_TFID(0, 0)},
> + {"M4U_PORT_DISP_RDMA0", 0, 0,0, 1, MTK_TFID(0, 1)},
> + {"M4U_PORT_DISP_WDMA0", 0, 0,0, 2, MTK_TFID(0, 2)},
> + {"M4U_PORT_DISP_OD_R", 0, 0,0, 3, MTK_TFID(0, 3)},
> + {"M4U_PORT_DISP_OD_W", 0, 0,0, 4, MTK_TFID(0, 4)},
> + {"M4U_POR
Re: Rcceiving a generic netlink multicast - should be restricted to the root user?
Some code to reproduce this is at https://github.com/craig65535/mcast-exmpl. The kernel module hooks TCP connects via a jprobe, and multicasts a generic netlink message on every connect. So after insmod'ing the module, just connect anywhere to send a multicast. The client receives multicasts, even when it's not running as root. Again, the documentation (man 7 netlink) does not agree with this. Is this just a documentation bug, or a real bug? On Fri, Mar 6, 2015 at 7:08 PM, Craig Davison wrote: > I wrote a kernel module that sends generic Netlink multicasts, and > wrote a userland client using libmnl that receives them. > > That all works fine, but my client works even when it's not the root user. > > man 7 netlink says: > > Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability > may send or listen to a netlink multicast group. > > The listen part of this is seemingly not true. I've tried this on > kernels 3.13 (Ubuntu 14.04), 2.6.32 (CentOS 6) and 2.6.18 (CentOS 5). > > Is this a bug? > > If not: I know that restricting receiving generic netlink commands > incoming to the kernel to being only from root is possible with > GENL_ADMIN_PERM flag, but is it possible to send multicasts from the > kernel that can only be received by root? > > Thank you -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: dsa: mv88e6xxx: Add EEE support
From: Guenter Roeck Date: Fri, 6 Mar 2015 22:23:51 -0800 > EEE configuration is similar for the various MV88E6xxx chips. > Add generic support for it. > > Signed-off-by: Guenter Roeck > Reviewed-by: Florian Fainelli Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: dsa: mv88e6352: Add support for EEE
From: Guenter Roeck Date: Fri, 6 Mar 2015 22:23:52 -0800 > Enable EEE support for MV88E6352. > > Signed-off-by: Guenter Roeck Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Drivers: net: ieee802154: mrf24j40: fix some space around operator coding style issues
Fixed some codeing style issues.
Signed-off-by: hmsjwzb
---
drivers/net/ieee802154/mrf24j40.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index fba2dfd..d35c7a0 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -235,9 +235,9 @@ static int write_tx_buf(struct mrf24j40 *devrec, u16 reg,
};
/* Range check the length. 2 bytes are used for the length fields.*/
- if (length > TX_FIFO_SIZE-2) {
+ if (length > TX_FIFO_SIZE - 2) {
dev_err(printdev(devrec), "write_tx_buf() was passed too large
a buffer. Performing short write.\n");
- length = TX_FIFO_SIZE-2;
+ length = TX_FIFO_SIZE - 2;
}
spi_message_init(&msg);
@@ -290,9 +290,9 @@ static int mrf24j40_read_rx_buf(struct mrf24j40 *devrec,
/* Range check the RX FIFO length, accounting for the one-byte
* length field at the beginning. */
- if (rx_len > RX_FIFO_SIZE-1) {
+ if (rx_len > RX_FIFO_SIZE - 1) {
dev_err(printdev(devrec), "Invalid length read from device.
Performing short read.\n");
- rx_len = RX_FIFO_SIZE-1;
+ rx_len = RX_FIFO_SIZE - 1;
}
if (rx_len > *len) {
@@ -302,7 +302,7 @@ static int mrf24j40_read_rx_buf(struct mrf24j40 *devrec,
}
/* Set up the commands to read the data. */
- cmd = MRF24J40_READLONG(REG_RX_FIFO+1);
+ cmd = MRF24J40_READLONG(REG_RX_FIFO + 1);
addr[0] = cmd >> 8 & 0xff;
addr[1] = cmd & 0xff;
data_xfer.len = rx_len;
@@ -402,7 +402,7 @@ static int mrf24j40_start(struct ieee802154_hw *hw)
ret = read_short_reg(devrec, REG_INTCON, &val);
if (ret)
return ret;
- val &= ~(0x1|0x8); /* Clear TXNIE and RXIE. Enable interrupts */
+ val &= ~(0x1 | 0x8); /* Clear TXNIE and RXIE. Enable interrupts */
write_short_reg(devrec, REG_INTCON, val);
return 0;
@@ -419,7 +419,7 @@ static void mrf24j40_stop(struct ieee802154_hw *hw)
ret = read_short_reg(devrec, REG_INTCON, &val);
if (ret)
return;
- val |= 0x1|0x8; /* Set TXNIE and RXIE. Disable Interrupts */
+ val |= 0x1 | 0x8; /* Set TXNIE and RXIE. Disable Interrupts */
write_short_reg(devrec, REG_INTCON, val);
}
@@ -436,7 +436,7 @@ static int mrf24j40_set_channel(struct ieee802154_hw *hw,
u8 page, u8 channel)
WARN_ON(channel > MRF24J40_CHAN_MAX);
/* Set Channel TODO */
- val = (channel-11) << 4 | 0x03;
+ val = (channel - 11) << 4 | 0x03;
write_long_reg(devrec, REG_RFCON0, val);
/* RF Reset */
@@ -558,7 +558,7 @@ static int mrf24j40_handle_rx(struct mrf24j40 *devrec)
}
/* Cut off the checksum */
- skb_trim(skb, len-2);
+ skb_trim(skb, len - 2);
/* TODO: Other drivers call ieee20154_rx_irqsafe() here (eg: cc2040,
* also from a workqueue). I think irqsafe is not necessary here.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] net/macb: merge at91_ether driver into macb driver
From: Boris Brezillon Date: Sat, 7 Mar 2015 07:23:28 +0100 > The rm9200 boards use the dedicated at91_ether driver instead of the > regular macb driver. > > Both the macb and at91_ether drivers can be compiled as separated > modules. > Since the at91_ether driver uses code from the macb driver, at91_ether.ko > depends on macb.ko. > > However the macb.ko module always fails to load on rm9200 boards: the > macb_probe() function expects a hclk clock which doesn't exist on rm9200. > Then the at91_ether.ko can't be loaded in turn due to unresolved > dependencies. > > This series of patches fix this issue by merging at91_ether into macb. > > Patch 1 is fixing a problem that might happen when enabling ARM > multi-platform suppot. Series applied, 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/
[patch] mm, mempool: do not allow atomic resizing
Allocating a large number of elements in atomic context could quickly
deplete memory reserves, so just disallow atomic resizing entirely.
Nothing currently uses mempool_resize() with anything other than
GFP_KERNEL, so convert existing callers to drop the gfp_mask.
Signed-off-by: David Rientjes
---
drivers/s390/scsi/zfcp_erp.c | 4 ++--
fs/cifs/connect.c| 6 ++
include/linux/mempool.h | 2 +-
mm/mempool.c | 9 +
4 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -738,11 +738,11 @@ static int zfcp_erp_adapter_strategy_open_fsf(struct
zfcp_erp_action *act)
return ZFCP_ERP_FAILED;
if (mempool_resize(act->adapter->pool.sr_data,
- act->adapter->stat_read_buf_num, GFP_KERNEL))
+ act->adapter->stat_read_buf_num))
return ZFCP_ERP_FAILED;
if (mempool_resize(act->adapter->pool.status_read_req,
- act->adapter->stat_read_buf_num, GFP_KERNEL))
+ act->adapter->stat_read_buf_num))
return ZFCP_ERP_FAILED;
atomic_set(&act->adapter->stat_miss, act->adapter->stat_read_buf_num);
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -773,8 +773,7 @@ static void clean_demultiplex_info(struct TCP_Server_Info
*server)
length = atomic_dec_return(&tcpSesAllocCount);
if (length > 0)
- mempool_resize(cifs_req_poolp, length + cifs_min_rcv,
- GFP_KERNEL);
+ mempool_resize(cifs_req_poolp, length + cifs_min_rcv);
}
static int
@@ -848,8 +847,7 @@ cifs_demultiplex_thread(void *p)
length = atomic_inc_return(&tcpSesAllocCount);
if (length > 1)
- mempool_resize(cifs_req_poolp, length + cifs_min_rcv,
- GFP_KERNEL);
+ mempool_resize(cifs_req_poolp, length + cifs_min_rcv);
set_freezable();
while (server->tcpStatus != CifsExiting) {
diff --git a/include/linux/mempool.h b/include/linux/mempool.h
--- a/include/linux/mempool.h
+++ b/include/linux/mempool.h
@@ -29,7 +29,7 @@ extern mempool_t *mempool_create_node(int min_nr,
mempool_alloc_t *alloc_fn,
mempool_free_t *free_fn, void *pool_data,
gfp_t gfp_mask, int nid);
-extern int mempool_resize(mempool_t *pool, int new_min_nr, gfp_t gfp_mask);
+extern int mempool_resize(mempool_t *pool, int new_min_nr);
extern void mempool_destroy(mempool_t *pool);
extern void * mempool_alloc(mempool_t *pool, gfp_t gfp_mask);
extern void mempool_free(void *element, mempool_t *pool);
diff --git a/mm/mempool.c b/mm/mempool.c
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -113,23 +113,24 @@ EXPORT_SYMBOL(mempool_create_node);
* mempool_create().
* @new_min_nr: the new minimum number of elements guaranteed to be
* allocated for this pool.
- * @gfp_mask: the usual allocation bitmask.
*
* This function shrinks/grows the pool. In the case of growing,
* it cannot be guaranteed that the pool will be grown to the new
* size immediately, but new mempool_free() calls will refill it.
+ * This function may sleep.
*
* Note, the caller must guarantee that no mempool_destroy is called
* while this function is running. mempool_alloc() & mempool_free()
* might be called (eg. from IRQ contexts) while this function executes.
*/
-int mempool_resize(mempool_t *pool, int new_min_nr, gfp_t gfp_mask)
+int mempool_resize(mempool_t *pool, int new_min_nr)
{
void *element;
void **new_elements;
unsigned long flags;
BUG_ON(new_min_nr <= 0);
+ might_sleep();
spin_lock_irqsave(&pool->lock, flags);
if (new_min_nr <= pool->min_nr) {
@@ -145,7 +146,7 @@ int mempool_resize(mempool_t *pool, int new_min_nr, gfp_t
gfp_mask)
spin_unlock_irqrestore(&pool->lock, flags);
/* Grow the pool */
- new_elements = kmalloc(new_min_nr * sizeof(*new_elements), gfp_mask);
+ new_elements = kmalloc(new_min_nr * sizeof(*new_elements), GFP_KERNEL);
if (!new_elements)
return -ENOMEM;
@@ -164,7 +165,7 @@ int mempool_resize(mempool_t *pool, int new_min_nr, gfp_t
gfp_mask)
while (pool->curr_nr < pool->min_nr) {
spin_unlock_irqrestore(&pool->lock, flags);
- element = pool->alloc(gfp_mask, pool->pool_data);
+ element = pool->alloc(GFP_KERNEL, pool->pool_data);
if (!element)
goto out;
spin_lock_irqsave(&pool->lock, flags);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
[PATCH] Sound: soc: codecs: rt5670: fix two space coding style issue
fixed a coding style issue
Signed-off-by: weizhewang
---
sound/soc/codecs/rt5670.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c
index fd10261..11ced93 100644
--- a/sound/soc/codecs/rt5670.c
+++ b/sound/soc/codecs/rt5670.c
@@ -1913,8 +1913,8 @@ static const struct snd_soc_dapm_route
rt5670_dapm_routes[] = {
{ "IF1 ADC2 IN1 Mux", "IF1_ADC2_IN", "IF1 ADC2 IN Mux" },
{ "IF1 ADC2 IN1 Mux", "IF1_ADC4", "IF1_ADC4" },
- { "IF1_ADC1" , NULL, "IF1 ADC1 IN2 Mux" },
- { "IF1_ADC2" , NULL, "IF1 ADC2 IN1 Mux" },
+ { "IF1_ADC1", NULL, "IF1 ADC1 IN2 Mux" },
+ { "IF1_ADC2", NULL, "IF1 ADC2 IN1 Mux" },
{ "Stereo1 ADC MIX", NULL, "Stereo1 ADC MIXL" },
{ "Stereo1 ADC MIX", NULL, "Stereo1 ADC MIXR" },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] block: allocate request memory local to request queue
On Sat, Mar 07, 2015 at 06:53:46PM -0800, David Rientjes wrote: > blk_init_rl() allocates a mempool using mempool_create_node() with node > local memory. This only allocates the mempool and element list locally > to the requeue queue node. > > What we really want to do is allocate the request itself local to the > queue. To do this, we need our own alloc and free functions that will > allocate from request_cachep and pass the request queue node in to prefer > node local memory. > > Cc: Tejun Heo > Signed-off-by: David Rientjes Acked-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block: allocate request memory local to request queue
blk_init_rl() allocates a mempool using mempool_create_node() with node
local memory. This only allocates the mempool and element list locally
to the requeue queue node.
What we really want to do is allocate the request itself local to the
queue. To do this, we need our own alloc and free functions that will
allocate from request_cachep and pass the request queue node in to prefer
node local memory.
Cc: Tejun Heo
Signed-off-by: David Rientjes
---
block/blk-core.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -557,6 +557,18 @@ void blk_cleanup_queue(struct request_queue *q)
}
EXPORT_SYMBOL(blk_cleanup_queue);
+/* Allocate memory local to the request queue */
+static void *alloc_request_struct(gfp_t gfp_mask, void *data)
+{
+ int nid = (int)(long)data;
+ return kmem_cache_alloc_node(request_cachep, gfp_mask, nid);
+}
+
+static void free_request_struct(void *element, void *unused)
+{
+ kmem_cache_free(request_cachep, element);
+}
+
int blk_init_rl(struct request_list *rl, struct request_queue *q,
gfp_t gfp_mask)
{
@@ -569,9 +581,10 @@ int blk_init_rl(struct request_list *rl, struct
request_queue *q,
init_waitqueue_head(&rl->wait[BLK_RW_SYNC]);
init_waitqueue_head(&rl->wait[BLK_RW_ASYNC]);
- rl->rq_pool = mempool_create_node(BLKDEV_MIN_RQ, mempool_alloc_slab,
- mempool_free_slab, request_cachep,
- gfp_mask, q->node);
+ rl->rq_pool = mempool_create_node(BLKDEV_MIN_RQ, alloc_request_struct,
+ free_request_struct,
+ (void *)(long)q->node, gfp_mask,
+ q->node);
if (!rl->rq_pool)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] Cleaned hexadecimal dump
On Sat, 2015-03-07 at 12:56 -0500, Adrian Remonda wrote:
> Signed-off-by: Adrian Remonda
[]
> diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c
[]
> +static void hexDump(const void *src, size_t length, size_t bLine, char
> *prefix)
> +{
Is there something necessary that print_hex_dump can't do?
> + int i = 0;
> + char *address = (char *)src;
> + char *line = (char *)address;
> + unsigned char c;
> +
> + printf("%s | ", prefix);
> + while (length-- > 0) {
> + printf("%02X ", (unsigned char)*address++);
> + if (!(++i % bLine) || (length == 0 && i % bLine)) {
> + if (length == 0) {
> + while (i++ % bLine)
> + printf("__ ");
> + }
> + printf(" | "); /* right close */
> + while (line < address) {
> + c = *line++;
> + printf("%c", (c < 33 || c == 255) ? 0x2E : c);
> + }
> + printf("\n");
> + if (length > 0)
> + printf("%s | ", prefix);
> + }
> + }
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 4/4] charger-manager: Enable psy based charge control
Hi, On Fri, Mar 06, 2015 at 04:03:27PM +0530, Jenny TC wrote: > At present charger manager support only regulator based charging > control. But most of the charger drivers are registered with power > supply subsystem. This patch adds support for power supply based > charging control along with the regulator based control. With the > patch, charging control can be done either using power supply > interface or with regulator interface. The charging is setup > based on battery parameters received through the battery info > handlers. [...] (so far I only skipped over the patch) [...] > @@ -1704,6 +1968,10 @@ static int charger_manager_probe(struct > platform_device *pdev) > strncpy(cm->psy_name_buf, desc->psy_name, PSY_NAME_MAX); > cm->charger_psy.name = cm->psy_name_buf; > > + if (!power_supply_get_property(fuel_gauge, POWER_SUPPLY_PROP_MODEL_NAME, > + &val)) > + cm->battery_info = psy_get_battery_info(val.strval); > + > /* Allocate for psy properties because they may vary */ > cm->charger_psy.properties = devm_kzalloc(&pdev->dev, > sizeof(enum power_supply_property) We are currently splitting battery data from fuel gauge data, so acquiring the battery using the fuel gauge's MODEL_NAME is not very nice. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v3 1/8] x86: Kill E820_RESERVED_KERN
On Sat, 7 Mar 2015, Yinghai Lu wrote: > Now we are using memblock to do early resource reserver/allocation > instead of using e820 map directly, and setup_data is reserved in > memblock early already. > Also kexec generate setup_data and pass pointer to second kernel, > so second kernel reserve setup_data by their own. > (Now kexec-tools create SETUP_EFI and SETUP_E820_EXT). > > We can kill E820_RESERVED_KERN and not touch e820 map at all. > > That will fix bug in mark_nonsave_region that can not handle that > case: E820_RAM and E820_RESERVED_KERN ranges are continuous and > boundary is not page aligned. > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=913885 Is this the bug referenced in the commit message that is fixed? If so, it's only a bug for resume, correct? I'm not sure if that's clear enough just from the commit message, I was looking at this patch for an e820 problem I'm currently facing on 3.3. > Reported-by: "Lee, Chun-Yi" > Tested-by: "Lee, Chun-Yi" > Cc: "Lee, Chun-Yi" > Signed-off-by: Yinghai Lu > Cc: sta...@vger.kernel.org Hmm, although the bug is reported for a 3.12 kernel, I assume this is for stable 3.10+? If so, it should apply fine with the exception of removing e820_reserve_setup_data() from setup_arch() rather than memblock_x86_reserve_range_setup_data(). Or is it for 3.2 as well and needs to be completely rebased for that kernel? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] power_supply: Introduce charger control interface
Hi,
On Fri, Mar 06, 2015 at 04:03:26PM +0530, Jenny TC wrote:
> Introduce power_supply charger control interfaces to control
> charging from charging framework like charger-manager. The interfaces
> are similar to the existing power supply get/set interfaces, but
> introduce a different set of properties in order to differentiate
> itself from other power supply properties which exposed in sysfs
>
> Signed-off-by: Jenny TC
> ---
> include/linux/power_supply.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 30145d8e..a80a3ef 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -176,6 +176,32 @@ union power_supply_propval {
> struct device;
> struct device_node;
>
> +enum psy_charger_control_property {
> + PSY_CHARGER_PROP_ENABLE_CHARGING = 0,
> + PSY_CHARGER_PROP_ENABLE_CHARGER,
> + PSY_CHARGER_PROP_RESET_WDT,
> +};
> +
> +/**
> + * struct power_supply_charger - power supply charger driver
> + * @get_property: get property function to retrieve charger properties
> defined
> + * in enum power_supply_charger_property
> + * @set_property: get property function to retrieve charger properties
> defined
> + * in enum power_supply_charger_property
> + *
> + * This structure is used by charger drivers to register with power supply
> + * charging driver
> + */
> +
> +struct power_supply_charger {
> + int (*get_property)(struct power_supply_charger *psyc,
> + enum psy_charger_control_property pspc,
> + union power_supply_propval *val);
The charging framework can simply call the same get_property
as used by sysfs. This is already done by all kind of drivers.
> + int (*set_property)(struct power_supply_charger *psyc,
> + enum psy_charger_control_property pspc,
> + const union power_supply_propval *val);
I guess this is needed for values, which are supposed to be
writable by the kernel / charging framework, but non-writable
by the sysfs. I suggest to add set_property_kernel() instead
(and make the above properties part of enum power_supply_property)
> +};
> +
> struct power_supply {
> const char *name;
> enum power_supply_type type;
> @@ -200,6 +226,8 @@ struct power_supply {
> void (*external_power_changed)(struct power_supply *psy);
> void (*set_charged)(struct power_supply *psy);
>
> + struct power_supply_charger *psy_charger;
Why is this a pointer?
> +
> /*
>* Set if thermal zone should not be created for this power supply.
>* For example for virtual supplies forwarding calls to actual
-- Sebastian
signature.asc
Description: Digital signature
Re: [patch 1/2] block, drbd: fix drbd_req_new() initialization
On 03/07/2015 06:27 PM, David Rientjes wrote: > On Sat, 7 Mar 2015, Jens Axboe wrote: > > mempool_alloc() does not support __GFP_ZERO since elements may come from > memory that has already been released by mempool_free(). > > Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly > initialize it to 0. You should add it to mempool instead, avoid having this issue show up for other folks as well. It'd be trivial to do. Normal ->alloc() should honor __GFP_ZERO, just do the same manually for removing an item from the internal pool. >>> >>> Umm, it's not trivial to do and wouldn't make sense to do it. Mempools >> >> Uhm, it would make sense, though. >> > > Disagree, I don't think we should extend mempool to know the element size, > modify every user of mempool to pass it in, and keep it consistent with > mempool_alloc_t for the benefit of __GFP_ZERO for this one buggy caller. > Most users don't need __GFP_ZERO and just overwrite the entire element > after mempool_alloc() and it would be an unnecessary overhead to even > check for the bit set. So it wouldn't make sense in terms of performance > or maintainability. My point is that conceptually, of course it makes sense to do and it _should_ do it. We don't have the size, too bad, I don't disagree that adding it just for this is necessarily the best idea. >>> don't know the element size, in other words it wouldn't know the length to >>> memset() to 0 for mempool_alloc(). It shouldn't be modified to know the >>> element size since elements are allocated by the implementation of >>> mempool_alloc_t and they could easily become inconsistent. This patch is >>> what you want to merge, really. >>> >> >> I forgot we don't have the size in there. Then I would suggest adding a >> WARN_ON() for __GFP_ZERO being set in mempool_alloc(), at the very least. >> > > There is, it's a VM_WARN_ON_ONCE() that will show up if you configure > CONFIG_DEBUG_VM. OK, that's good enough then. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ->poll() bugs
On Sat, Mar 07, 2015 at 12:53:14PM -0800, Linus Torvalds wrote: > On Sat, Mar 7, 2015 at 12:44 PM, Al Viro wrote: > > > > Most of the catch consists of ->poll() instances that return -E...; there's > > also an unpleasant mess in net/9p/trans_fd.c and a braino in sunrpc > > unexpectedly caught by the same annotations. > > Hmm. I do wonder if we should just *allow* ->poll() to return an > error, and just turn it into "all bits set"? Doable, but... we do have a bunch of ->poll() call sites (AFAICS, right now it's drivers/staging/comedi/drivers/serial2002.c:142: drivers/vfio/pci/vfio_pci_intrs.c:191: drivers/vhost/vhost.c:95: fs/eventpoll.c:800: fs/proc/inode.c:229: fs/select.c:461: fs/select.c:764: mm/memcontrol.c:4285: net/9p/trans_fd.c:249: net/9p/trans_fd.c:254: virt/kvm/eventfd.c:418: ) and while they could be turned into calls of a wrapper, I really don't like returning negatives as a part of ->poll() calling conventions. I mean, really - "you should return a bitmap of POLL... flags *or* -E...; doesn't matter which error number it is, it'll be lost anyway"... It's OK to have the caller(s) catch such bugs (and report them, IMO), but silently treating it that way as a part of calling conventions... Besides, that doesn't catch the bugs like one in net/9p; sparse annotations do. > But if getting sparse to catch them all isn't *too* painful and the > patch doesn't end up being horribly big, then I guess that's ok. Getting sparse to catch them all is as trivial as * introduce a __bitwise typedef __poll_t => unsigned int * say that ->poll() (in file_operations, as well as in proto_ops, tty_ldisc_ops and several in other subsystems) returns __poll_t * switch the return type of instances from unsigned int to __poll_t * do the same to local variable(s) (if any) used to hold the return value to be. Again, from cc(1) POV it's a no-op - unannotated foo_poll() will be just fine as it is. The only place where I did something more fancy than such type change actually had been buggy - drivers/media/common/siano/smsdvb-debugfs.c:smsdvb_stats_poll() relied upon smsdvb_stats_wait_read() never returning negatives and it needs s/__poll_t rc/& = 0/ for correctness (fixed and folded). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] power_supply: Introduce charging object table
Hi,
On Fri, Mar 06, 2015 at 12:12:50PM +0100, Oliver Neukum wrote:
> On Fri, 2015-03-06 at 16:03 +0530, Jenny TC wrote:
> > +struct psy_temp_mon_table {
> > + int temp_max;
> > + int temp_min;
> > + int charging_current; /* CC */
> > + int charging_voltage; /* CV */
>
> In which units?
First few lines from power_supply.h:
/*
* All voltages, currents, charges, energies, time and temperatures in uV,
* µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
* stated. It's driver's job to convert its raw values to units in which
* this class operates.
*/
-- Sebastian
signature.asc
Description: Digital signature
Re: [patch 1/2] block, drbd: fix drbd_req_new() initialization
On Sat, 7 Mar 2015, Jens Axboe wrote: > >>> mempool_alloc() does not support __GFP_ZERO since elements may come from > >>> memory that has already been released by mempool_free(). > >>> > >>> Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly > >>> initialize it to 0. > >> > >> You should add it to mempool instead, avoid having this issue show up for > >> other folks as well. It'd be trivial to do. Normal ->alloc() should honor > >> __GFP_ZERO, just do the same manually for removing an item from the > >> internal > >> pool. > >> > > > > Umm, it's not trivial to do and wouldn't make sense to do it. Mempools > > Uhm, it would make sense, though. > Disagree, I don't think we should extend mempool to know the element size, modify every user of mempool to pass it in, and keep it consistent with mempool_alloc_t for the benefit of __GFP_ZERO for this one buggy caller. Most users don't need __GFP_ZERO and just overwrite the entire element after mempool_alloc() and it would be an unnecessary overhead to even check for the bit set. So it wouldn't make sense in terms of performance or maintainability. > > don't know the element size, in other words it wouldn't know the length to > > memset() to 0 for mempool_alloc(). It shouldn't be modified to know the > > element size since elements are allocated by the implementation of > > mempool_alloc_t and they could easily become inconsistent. This patch is > > what you want to merge, really. > > > > I forgot we don't have the size in there. Then I would suggest adding a > WARN_ON() for __GFP_ZERO being set in mempool_alloc(), at the very least. > There is, it's a VM_WARN_ON_ONCE() that will show up if you configure CONFIG_DEBUG_VM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block, drbd: fix drbd_req_new() initialization
On 03/07/2015 05:53 PM, David Rientjes wrote: > On Sat, 7 Mar 2015, Jens Axboe wrote: > >>> mempool_alloc() does not support __GFP_ZERO since elements may come from >>> memory that has already been released by mempool_free(). >>> >>> Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly >>> initialize it to 0. >> >> You should add it to mempool instead, avoid having this issue show up for >> other folks as well. It'd be trivial to do. Normal ->alloc() should honor >> __GFP_ZERO, just do the same manually for removing an item from the internal >> pool. >> > > Umm, it's not trivial to do and wouldn't make sense to do it. Mempools Uhm, it would make sense, though. > don't know the element size, in other words it wouldn't know the length to > memset() to 0 for mempool_alloc(). It shouldn't be modified to know the > element size since elements are allocated by the implementation of > mempool_alloc_t and they could easily become inconsistent. This patch is > what you want to merge, really. > I forgot we don't have the size in there. Then I would suggest adding a WARN_ON() for __GFP_ZERO being set in mempool_alloc(), at the very least. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/8] x86, boot: clean up setup_data handling
Now setup_data is reserved via memblock and e820 and different handlers have different ways, and it is confusing. 1. SETUP_E820_EXT: is consumed early and will not copy or access again. have memory wasted. 2. SETUP_EFI: is accessed via ioremap every time at early stage. have memory wasted. 3. SETUP_DTB: is copied locally. have memory wasted. 4. SETUP_PCI: is accessed via ioremap for every pci devices, even run-time. 5. SETUP_KASLR: is accessed early, will not copy or access again. have memory wasted. Also setup_data is exported to debugfs for debug purpose. Here will convert to let every handler to decide how to handle it. and will not reserve the setup_data generally, so will not waste memory and also make memblock/e820 keep page aligned. 1. not touch E820 anymore. 2. copy SETUP_EFI to __initdata variable and access it without ioremap. 3. SETUP_DTB: reserver and copy to local and free. 4. SETUP_PCI: reverve localy and convert to list, to avoid keeping ioremap. 5. export SETUP_PCI via sysfs. Also put them in: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-4.0-rc2-setup_data Should be materials for v4.1. Thanks Yinghai Lu -v3: separated with kasl patches, and fix early_ioremap return checking. Yinghai Lu (8): x86: Kill E820_RESERVED_KERN x86, efi: Copy SETUP_EFI data and access directly x86, of: Let add_dtb reserve setup_data locally x86, boot: Add add_pci handler for SETUP_PCI x86: Kill not used setup_data handling code x86, boot, PCI: Convert SETUP_PCI data to list x86, boot, PCI: Copy SETUP_PCI rom to kernel space x86, boot, PCI: Export SETUP_PCI data via sysfs arch/x86/include/asm/efi.h | 2 +- arch/x86/include/asm/pci.h | 4 + arch/x86/include/asm/prom.h | 9 +- arch/x86/include/uapi/asm/e820.h | 9 -- arch/x86/kernel/devicetree.c | 43 +++--- arch/x86/kernel/e820.c | 6 +- arch/x86/kernel/kdebugfs.c | 142 -- arch/x86/kernel/setup.c | 52 ++- arch/x86/kernel/tboot.c | 3 +- arch/x86/mm/init_64.c| 11 +- arch/x86/pci/common.c| 316 --- arch/x86/platform/efi/efi.c | 13 +- arch/x86/platform/efi/efi_64.c | 13 +- arch/x86/platform/efi/quirks.c | 23 +-- 14 files changed, 371 insertions(+), 275 deletions(-) -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] power_supply: Introduce charging object table
Hi,
On Fri, Mar 06, 2015 at 04:03:24PM +0530, Jenny TC wrote:
> Charging current (CC) and charging voltage (CV) may vary based on
> battery temperature. To support CC and CV for different temperature
> zones, defined a charging object which holds the properties related
> to battery charging.
>
> Signed-off-by: Jenny TC
> ---
> include/linux/power_supply.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 096dbce..7aada44 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -252,6 +252,33 @@ struct power_supply_info {
> int use_for_apm;
> };
>
> +
> +struct psy_temp_mon_table {
> + int temp_max;
> + int temp_min;
> + int charging_current; /* CC */
> + int charging_voltage; /* CV */
> + /* delta voltage at which charging should restart */
> + int maint_voltage_delta;
> +};
> +
> +#define PSY_MAX_BAT_NAME_LEN 8
> +#define PSY_MAX_TEMP_ZONE 6
> +
> +struct psy_charging_obj {
This is not just about charging data, but also about the batteries
thermal limits, technology and full capacity, so how about
struct psy_battery_information {
> + char name[PSY_MAX_BAT_NAME_LEN];
char *name;
No need for arbitrary length limitation.
> + int battery_type;
> + int temp_max;
> + int temp_min;
> + int full_condition_soc;
Please be more verbose about the information being stored here.
> + int full_condition_capacity;
> + int full_condition_voltage;
> + int iterm; /* charge termination current */
> + /* CC/CV table for different temperature range */
> + int temp_mon_count; /* number of entries in temp_mon_table */
> + struct psy_temp_mon_table temp_mon_table[PSY_MAX_TEMP_ZONE];
No need to embed this into the struct. Just point to the array and
remove the size limitation.
> +};
> +
> extern struct atomic_notifier_head power_supply_notifier;
> extern int power_supply_reg_notifier(struct notifier_block *nb);
> extern void power_supply_unreg_notifier(struct notifier_block *nb);
-- Sebastian
signature.asc
Description: Digital signature
[PATCH v3 6/8] x86, boot, PCI: Convert SETUP_PCI data to list
So we could avoid ioremap every time later.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel/setup.c| 1 +
arch/x86/pci/common.c | 77 +-
3 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 7fbd5f3..99b261f 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -88,9 +88,11 @@ static inline void pci_dma_burst_advice(struct pci_dev *pdev,
*strategy_parameter = ~0UL;
}
void add_pci(u64 pa_data);
+int fill_setup_pci_entries(void);
#else
static inline void early_quirks(void) { }
static inline void add_pci(u64 pa_data) { }
+static inline int fill_setup_pci_entries(void) { }
#endif
extern void pci_iommu_alloc(void);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a7e688c..39940a7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1195,6 +1195,7 @@ void __init setup_arch(char **cmdline_p)
acpi_boot_init();
sfi_init();
x86_dtb_init();
+ fill_setup_pci_entries();
/*
* get boot-time SMP configuration:
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index f40df5c..67dc2a9 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -668,7 +668,7 @@ unsigned int pcibios_assign_all_busses(void)
return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0;
}
-static u64 pci_setup_data;
+static u64 pci_setup_data __initdata;
void __init add_pci(u64 pa_data)
{
struct setup_data *data;
@@ -683,36 +683,83 @@ void __init add_pci(u64 pa_data)
early_memunmap(data, sizeof(*data));
}
-int pcibios_add_device(struct pci_dev *dev)
+struct firmware_setup_pci_entry {
+ struct list_head list;
+ uint16_t vendor;
+ uint16_t devid;
+ uint64_t pcilen;
+ unsigned long segment;
+ unsigned long bus;
+ unsigned long device;
+ unsigned long function;
+ phys_addr_t romdata;
+};
+
+static LIST_HEAD(setup_pci_entries);
+
+int __init fill_setup_pci_entries(void)
{
struct setup_data *data;
struct pci_setup_rom *rom;
+ struct firmware_setup_pci_entry *entry;
+ phys_addr_t pa_entry;
u64 pa_data;
pa_data = pci_setup_data;
while (pa_data) {
- data = ioremap(pa_data, sizeof(*rom));
+ data = early_memremap(pa_data, sizeof(*rom));
if (!data)
return -ENOMEM;
-
rom = (struct pci_setup_rom *)data;
- if ((pci_domain_nr(dev->bus) == rom->segment) &&
- (dev->bus->number == rom->bus) &&
- (PCI_SLOT(dev->devfn) == rom->device) &&
- (PCI_FUNC(dev->devfn) == rom->function) &&
- (dev->vendor == rom->vendor) &&
- (dev->device == rom->devid)) {
- dev->rom = pa_data +
- offsetof(struct pci_setup_rom, romdata);
- dev->romlen = rom->pcilen;
+ pa_entry = memblock_alloc(sizeof(*entry), sizeof(long));
+ if (!pa_entry) {
+ early_memunmap(data, sizeof(*rom));
+ return -ENOMEM;
+ }
+
+ entry = phys_to_virt(pa_entry);
+ entry->segment = rom->segment;
+ entry->bus = rom->bus;
+ entry->device = rom->device;
+ entry->function = rom->function;
+ entry->vendor = rom->vendor;
+ entry->devid = rom->devid;
+ entry->pcilen = rom->pcilen;
+ entry->romdata = pa_data +
+offsetof(struct pci_setup_rom, romdata);
+
+ list_add(&entry->list, &setup_pci_entries);
+
+ memblock_free(pa_data, sizeof(*rom));
+ pa_data = data->next;
+ early_memunmap(data, sizeof(*rom));
+ }
+
+ pci_setup_data = 0;
+
+ return 0;
+}
+
+int pcibios_add_device(struct pci_dev *dev)
+{
+ struct firmware_setup_pci_entry *entry;
+
+ list_for_each_entry(entry, &setup_pci_entries, list) {
+ if ((pci_domain_nr(dev->bus) == entry->segment) &&
+ (dev->bus->number == entry->bus) &&
+ (PCI_SLOT(dev->devfn) == entry->device) &&
+ (PCI_FUNC(dev->devfn) == entry->function) &&
+ (dev->vendor == entry->vendor) &&
+ (dev->device == entry->devid)) {
+ dev->rom = entry->romdata;
+ dev->romlen = entry->pcilen;
dev_printk(KERN_DEBUG, &dev->dev, "set rom to [%#010lx,
%#010lx] via SETUP_PCI\n",
(unsigned long)dev->rom,
(unsigned long)(dev->rom
[PATCH v3 5/8] x86: Kill not used setup_data handling code
Cc: Matt Fleming
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/kdebugfs.c | 142 -
arch/x86/kernel/setup.c| 17 --
2 files changed, 159 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..c8ca86c 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -21,142 +21,6 @@ struct dentry *arch_debugfs_dir;
EXPORT_SYMBOL(arch_debugfs_dir);
#ifdef CONFIG_DEBUG_BOOT_PARAMS
-struct setup_data_node {
- u64 paddr;
- u32 type;
- u32 len;
-};
-
-static ssize_t setup_data_read(struct file *file, char __user *user_buf,
- size_t count, loff_t *ppos)
-{
- struct setup_data_node *node = file->private_data;
- unsigned long remain;
- loff_t pos = *ppos;
- struct page *pg;
- void *p;
- u64 pa;
-
- if (pos < 0)
- return -EINVAL;
-
- if (pos >= node->len)
- return 0;
-
- if (count > node->len - pos)
- count = node->len - pos;
-
- pa = node->paddr + sizeof(struct setup_data) + pos;
- pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- p = ioremap_cache(pa, count);
- if (!p)
- return -ENXIO;
- } else
- p = __va(pa);
-
- remain = copy_to_user(user_buf, p, count);
-
- if (PageHighMem(pg))
- iounmap(p);
-
- if (remain)
- return -EFAULT;
-
- *ppos = pos + count;
-
- return count;
-}
-
-static const struct file_operations fops_setup_data = {
- .read = setup_data_read,
- .open = simple_open,
- .llseek = default_llseek,
-};
-
-static int __init
-create_setup_data_node(struct dentry *parent, int no,
- struct setup_data_node *node)
-{
- struct dentry *d, *type, *data;
- char buf[16];
-
- sprintf(buf, "%d", no);
- d = debugfs_create_dir(buf, parent);
- if (!d)
- return -ENOMEM;
-
- type = debugfs_create_x32("type", S_IRUGO, d, &node->type);
- if (!type)
- goto err_dir;
-
- data = debugfs_create_file("data", S_IRUGO, d, node, &fops_setup_data);
- if (!data)
- goto err_type;
-
- return 0;
-
-err_type:
- debugfs_remove(type);
-err_dir:
- debugfs_remove(d);
- return -ENOMEM;
-}
-
-static int __init create_setup_data_nodes(struct dentry *parent)
-{
- struct setup_data_node *node;
- struct setup_data *data;
- int error;
- struct dentry *d;
- struct page *pg;
- u64 pa_data;
- int no = 0;
-
- d = debugfs_create_dir("setup_data", parent);
- if (!d)
- return -ENOMEM;
-
- pa_data = boot_params.hdr.setup_data;
-
- while (pa_data) {
- node = kmalloc(sizeof(*node), GFP_KERNEL);
- if (!node) {
- error = -ENOMEM;
- goto err_dir;
- }
-
- pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- data = ioremap_cache(pa_data, sizeof(*data));
- if (!data) {
- kfree(node);
- error = -ENXIO;
- goto err_dir;
- }
- } else
- data = __va(pa_data);
-
- node->paddr = pa_data;
- node->type = data->type;
- node->len = data->len;
- error = create_setup_data_node(d, no, node);
- pa_data = data->next;
-
- if (PageHighMem(pg))
- iounmap(data);
- if (error)
- goto err_dir;
- no++;
- }
-
- return 0;
-
-err_dir:
- debugfs_remove(d);
- return error;
-}
-
static struct debugfs_blob_wrapper boot_params_blob = {
.data = &boot_params,
.size = sizeof(boot_params),
@@ -181,14 +45,8 @@ static int __init boot_params_kdebugfs_init(void)
if (!data)
goto err_version;
- error = create_setup_data_nodes(dbp);
- if (error)
- goto err_data;
-
return 0;
-err_data:
- debugfs_remove(data);
err_version:
debugfs_remove(version);
err_dir:
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 94f95e0..a7e688c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -486,20 +486,6 @@ static void __init parse_setup_data(void)
boot_params.hdr.setup_data = 0; /* all done */
}
-static void __init memblock_x86_reserve_range_setup_data(void)
-{
- struct setup_data *data;
- u64 pa_data;
-
- pa_data = boot_params.hdr.setup_data;
- while (
[PATCH v3 3/8] x86, of: Let add_dtb reserve setup_data locally
We will not reserve setup_data in generic code. Every handler need to
reserve and copy setup_data locally.
Current dtd handling already have code for copying, just add reserve code.
Also simplify code a bit by storing real dtb size.
Cc: Rob Herring
Cc: David Vrabel
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/prom.h | 9 ++---
arch/x86/kernel/devicetree.c | 43 +--
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/prom.h b/arch/x86/include/asm/prom.h
index 1d081ac..fb716eddc 100644
--- a/arch/x86/include/asm/prom.h
+++ b/arch/x86/include/asm/prom.h
@@ -24,17 +24,20 @@
#ifdef CONFIG_OF
extern int of_ioapic;
-extern u64 initial_dtb;
-extern void add_dtb(u64 data);
void x86_of_pci_init(void);
void x86_dtb_init(void);
#else
-static inline void add_dtb(u64 data) { }
static inline void x86_of_pci_init(void) { }
static inline void x86_dtb_init(void) { }
#define of_ioapic 0
#endif
+#ifdef CONFIG_OF_FLATTREE
+extern void add_dtb(u64 data);
+#else
+static inline void add_dtb(u64 data) { }
+#endif
+
extern char cmd_line[COMMAND_LINE_SIZE];
#endif /* __ASSEMBLY__ */
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 3d35033..55cf76a 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -2,6 +2,7 @@
* Architecture specific OF callbacks.
*/
#include
+#include
#include
#include
#include
@@ -23,7 +24,6 @@
#include
#include
-__initdata u64 initial_dtb;
char __initdata cmd_line[COMMAND_LINE_SIZE];
int __initdata of_ioapic;
@@ -43,11 +43,27 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64
align)
return __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS));
}
+#ifdef CONFIG_OF_FLATTREE
+static u64 initial_dtb __initdata;
+static u32 initial_dtb_size __initdata;
void __init add_dtb(u64 data)
{
+ u32 map_len;
+
initial_dtb = data + offsetof(struct setup_data, data);
-}
+ map_len = max(PAGE_SIZE - (initial_dtb & ~PAGE_MASK), (u64)128);
+ initial_boot_params = early_memremap(initial_dtb, map_len);
+ if (!initial_boot_params) {
+ initial_dtb = 0;
+ return;
+ }
+ initial_dtb_size = of_get_flat_dt_size();
+ early_memunmap(initial_boot_params, map_len);
+ initial_boot_params = NULL;
+ memblock_reserve(initial_dtb, initial_dtb_size);
+}
+#endif
/*
* CE4100 ids. Will be moved to machine_device_initcall() once we have it.
*/
@@ -272,31 +288,22 @@ static void __init dtb_apic_setup(void)
dtb_ioapic_setup();
}
-#ifdef CONFIG_OF_FLATTREE
static void __init x86_flattree_get_config(void)
{
- u32 size, map_len;
+#ifdef CONFIG_OF_FLATTREE
void *dt;
if (!initial_dtb)
return;
- map_len = max(PAGE_SIZE - (initial_dtb & ~PAGE_MASK), (u64)128);
-
- initial_boot_params = dt = early_memremap(initial_dtb, map_len);
- size = of_get_flat_dt_size();
- if (map_len < size) {
- early_iounmap(dt, map_len);
- initial_boot_params = dt = early_memremap(initial_dtb, size);
- map_len = size;
- }
-
+ initial_boot_params = dt = early_memremap(initial_dtb,
+ initial_dtb_size);
unflatten_and_copy_device_tree();
- early_iounmap(dt, map_len);
-}
-#else
-static inline void x86_flattree_get_config(void) { }
+ early_memunmap(dt, initial_dtb_size);
+
+ memblock_free(initial_dtb, initial_dtb_size);
#endif
+}
void __init x86_dtb_init(void)
{
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 8/8] x86, boot, PCI: Export SETUP_PCI data via sysfs
So we could let kexec-tools to rebuild SETUP_PCI and pass it to
second kernel if needed.
Now kexec-tools already build SETUP_EFI and SETUP_E820EXT.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/pci/common.c | 175 ++
1 file changed, 175 insertions(+)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 15e1b3f..502e707 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -685,6 +685,8 @@ void __init add_pci(u64 pa_data)
struct firmware_setup_pci_entry {
struct list_head list;
+ struct kobject kobj;
+ struct bin_attribute *rom_attr;
uint16_t vendor;
uint16_t devid;
uint64_t pcilen;
@@ -806,6 +808,179 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
+#ifdef CONFIG_SYSFS
+static inline struct firmware_setup_pci_entry *
+to_setup_pci_entry(struct kobject *kobj)
+{
+ return container_of(kobj, struct firmware_setup_pci_entry, kobj);
+}
+
+static ssize_t vendor_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%04llx\n",
+ (unsigned long long)entry->vendor);
+}
+
+static ssize_t devid_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%04llx\n",
+ (unsigned long long)entry->devid);
+}
+
+static ssize_t pcilen_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n",
+ (unsigned long long)entry->pcilen);
+}
+
+static ssize_t segment_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%04llx\n",
+ (unsigned long long)entry->segment);
+}
+
+static ssize_t bus_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%02llx\n",
+ (unsigned long long)entry->bus);
+}
+
+static ssize_t device_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%02llx\n",
+ (unsigned long long)entry->device);
+}
+
+static ssize_t function_show(struct firmware_setup_pci_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%1llx\n",
+ (unsigned long long)entry->function);
+}
+
+struct setup_pci_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct firmware_setup_pci_entry *entry, char *buf);
+};
+
+static inline struct setup_pci_attribute *to_setup_pci_attr(
+ struct attribute *attr)
+{
+ return container_of(attr, struct setup_pci_attribute, attr);
+}
+
+static ssize_t setup_pci_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct firmware_setup_pci_entry *entry = to_setup_pci_entry(kobj);
+ struct setup_pci_attribute *setup_pci_attr = to_setup_pci_attr(attr);
+
+ return setup_pci_attr->show(entry, buf);
+}
+
+static struct setup_pci_attribute setup_pci_vendor_attr = __ATTR_RO(vendor);
+static struct setup_pci_attribute setup_pci_devid_attr = __ATTR_RO(devid);
+static struct setup_pci_attribute setup_pci_pcilen_attr = __ATTR_RO(pcilen);
+static struct setup_pci_attribute setup_pci_segment_attr = __ATTR_RO(segment);
+static struct setup_pci_attribute setup_pci_bus_attr = __ATTR_RO(bus);
+static struct setup_pci_attribute setup_pci_device_attr = __ATTR_RO(device);
+static struct setup_pci_attribute setup_pci_function_attr =
__ATTR_RO(function);
+
+/*
+ * These are default attributes that are added for every memmap entry.
+ */
+static struct attribute *def_attrs[] = {
+ &setup_pci_vendor_attr.attr,
+ &setup_pci_devid_attr.attr,
+ &setup_pci_pcilen_attr.attr,
+ &setup_pci_segment_attr.attr,
+ &setup_pci_bus_attr.attr,
+ &setup_pci_device_attr.attr,
+ &setup_pci_function_attr.attr,
+ NULL
+};
+
+static const struct sysfs_ops setup_pci_attr_ops = {
+ .show = setup_pci_attr_show,
+};
+
+static struct kobj_type __refdata setup_pci_ktype = {
+ .sysfs_ops = &setup_pci_attr_ops,
+ .default_attrs = def_attrs,
+};
+
+static ssize_t setup_pci_rom_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf,
+ loff_t off, size_t count)
+{
+ struct firmware_setup_pci_entry *entry = to_setup_pci_entry(kobj);
+
+ if (off >= entry->pcilen)
+ count = 0;
+ else {
+ unsigned char *rom = phys_to_virt(entry->romdata);
+
+ if (off + count > entry->pcilen)
+ count = entry->pcilen - off;
+
+ memcpy(buf, rom + off, count);
+ }
+
+ return count;
+}
+
+static int __init add_sysfs_fw_setup_pc
[PATCH v3 4/8] x86, boot: Add add_pci handler for SETUP_PCI
Let it reserve setup_data, and keep it's own list.
Also clear the hdr.setup_data, as all handler now handle or
reserve setup_data locally already.
Cc: Bjorn Helgaas
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel/setup.c| 8
arch/x86/pci/common.c | 45 +++--
3 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4e370a5..7fbd5f3 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -87,8 +87,10 @@ static inline void pci_dma_burst_advice(struct pci_dev *pdev,
*strat = PCI_DMA_BURST_INFINITY;
*strategy_parameter = ~0UL;
}
+void add_pci(u64 pa_data);
#else
static inline void early_quirks(void) { }
+static inline void add_pci(u64 pa_data) { }
#endif
extern void pci_iommu_alloc(void);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index aed343b..94f95e0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -458,6 +458,8 @@ static void __init parse_setup_data(void)
pa_next = data->next;
early_iounmap(data, sizeof(*data));
+ printk(KERN_DEBUG "setup_data type: %d @ %#010llx\n",
+ data_type, pa_data);
switch (data_type) {
case SETUP_E820_EXT:
parse_e820_ext(pa_data, data_len);
@@ -465,6 +467,9 @@ static void __init parse_setup_data(void)
case SETUP_DTB:
add_dtb(pa_data);
break;
+ case SETUP_PCI:
+ add_pci(pa_data);
+ break;
case SETUP_EFI:
parse_efi_setup(pa_data, data_len);
break;
@@ -472,10 +477,13 @@ static void __init parse_setup_data(void)
parse_kaslr_setup(pa_data, data_len);
break;
default:
+ pr_warn("Unknown setup_data type: %d @ %#010llx
ignored!\n",
+ data_type, pa_data);
break;
}
pa_data = pa_next;
}
+ boot_params.hdr.setup_data = 0; /* all done */
}
static void __init memblock_x86_reserve_range_setup_data(void)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 3d2612b..f40df5c 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -667,31 +668,47 @@ unsigned int pcibios_assign_all_busses(void)
return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0;
}
+static u64 pci_setup_data;
+void __init add_pci(u64 pa_data)
+{
+ struct setup_data *data;
+
+ data = early_memremap(pa_data, sizeof(*data));
+ if (!data)
+ return;
+
+ memblock_reserve(pa_data, sizeof(*data) + data->len);
+ data->next = pci_setup_data;
+ pci_setup_data = pa_data;
+ early_memunmap(data, sizeof(*data));
+}
+
int pcibios_add_device(struct pci_dev *dev)
{
struct setup_data *data;
struct pci_setup_rom *rom;
u64 pa_data;
- pa_data = boot_params.hdr.setup_data;
+ pa_data = pci_setup_data;
while (pa_data) {
data = ioremap(pa_data, sizeof(*rom));
if (!data)
return -ENOMEM;
- if (data->type == SETUP_PCI) {
- rom = (struct pci_setup_rom *)data;
-
- if ((pci_domain_nr(dev->bus) == rom->segment) &&
- (dev->bus->number == rom->bus) &&
- (PCI_SLOT(dev->devfn) == rom->device) &&
- (PCI_FUNC(dev->devfn) == rom->function) &&
- (dev->vendor == rom->vendor) &&
- (dev->device == rom->devid)) {
- dev->rom = pa_data +
- offsetof(struct pci_setup_rom, romdata);
- dev->romlen = rom->pcilen;
- }
+ rom = (struct pci_setup_rom *)data;
+
+ if ((pci_domain_nr(dev->bus) == rom->segment) &&
+ (dev->bus->number == rom->bus) &&
+ (PCI_SLOT(dev->devfn) == rom->device) &&
+ (PCI_FUNC(dev->devfn) == rom->function) &&
+ (dev->vendor == rom->vendor) &&
+ (dev->device == rom->devid)) {
+ dev->rom = pa_data +
+ offsetof(struct pci_setup_rom, romdata);
+ dev->romlen = rom->pcilen;
+ dev_printk(KERN_DEBUG, &dev->dev, "set rom to [%#010lx,
%#010lx] via SETUP_PCI\n",
+ (unsign
[PATCH v3 2/8] x86, efi: Copy SETUP_EFI data and access directly
The copy will be in __initdata, and it is small.
We can use pointer to access the setup_data instead of using early_memmap
everywhere.
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/efi.h | 2 +-
arch/x86/platform/efi/efi.c| 13 ++---
arch/x86/platform/efi/efi_64.c | 13 -
arch/x86/platform/efi/quirks.c | 23 ++-
4 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 25bce45..edbecd6 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -114,7 +114,7 @@ struct efi_setup_data {
u64 reserved[8];
};
-extern u64 efi_setup;
+extern struct efi_setup_data *efi_setup;
#ifdef CONFIG_EFI
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index dbc8627..1cd38e8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -68,7 +68,7 @@ static efi_config_table_type_t arch_tables[] __initdata = {
{NULL_GUID, NULL, NULL},
};
-u64 efi_setup; /* efi setup_data physical address */
+struct efi_setup_data *efi_setup __initdata; /* cached efi setup_data pointer
*/
static int add_efi_memmap __initdata;
static int __init setup_add_efi_memmap(char *arg)
@@ -225,20 +225,13 @@ static int __init efi_systab_init(void *phys)
{
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *systab64;
- struct efi_setup_data *data = NULL;
+ struct efi_setup_data *data = efi_setup;
u64 tmp = 0;
- if (efi_setup) {
- data = early_memremap(efi_setup, sizeof(*data));
- if (!data)
- return -ENOMEM;
- }
systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
- if (data)
- early_memunmap(data, sizeof(*data));
return -ENOMEM;
}
@@ -271,8 +264,6 @@ static int __init efi_systab_init(void *phys)
tmp |= data ? data->tables : systab64->tables;
early_memunmap(systab64, sizeof(*systab64));
- if (data)
- early_memunmap(data, sizeof(*data));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 17e80d8..a541c6c 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -292,9 +292,20 @@ void __iomem *__init efi_ioremap(unsigned long phys_addr,
unsigned long size,
return (void __iomem *)__va(phys_addr);
}
+static struct efi_setup_data efi_setup_data __initdata;
+
void __init parse_efi_setup(u64 phys_addr, u32 data_len)
{
- efi_setup = phys_addr + sizeof(struct setup_data);
+ struct efi_setup_data *data;
+
+ data = early_memremap(phys_addr + sizeof(struct setup_data),
+ sizeof(*data));
+ if (!data)
+ return;
+
+ efi_setup_data = *data;
+ early_memunmap(data, sizeof(*data));
+ efi_setup = &efi_setup_data;
}
void __init efi_runtime_mkexec(void)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 1c7380d..45fec7d 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -203,9 +203,8 @@ void __init efi_free_boot_services(void)
*/
int __init efi_reuse_config(u64 tables, int nr_tables)
{
- int i, sz, ret = 0;
+ int i, sz;
void *p, *tablep;
- struct efi_setup_data *data;
if (!efi_setup)
return 0;
@@ -213,22 +212,15 @@ int __init efi_reuse_config(u64 tables, int nr_tables)
if (!efi_enabled(EFI_64BIT))
return 0;
- data = early_memremap(efi_setup, sizeof(*data));
- if (!data) {
- ret = -ENOMEM;
- goto out;
- }
-
- if (!data->smbios)
- goto out_memremap;
+ if (!efi_setup->smbios)
+ return 0;
sz = sizeof(efi_config_table_64_t);
p = tablep = early_memremap(tables, nr_tables * sz);
if (!p) {
pr_err("Could not map Configuration table!\n");
- ret = -ENOMEM;
- goto out_memremap;
+ return -ENOMEM;
}
for (i = 0; i < efi.systab->nr_tables; i++) {
@@ -237,15 +229,12 @@ int __init efi_reuse_config(u64 tables, int nr_tables)
guid = ((efi_config_table_64_t *)p)->guid;
if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
- ((efi_config_table_64_t *)p)->table = da
[PATCH v3 7/8] x86, boot, PCI: Copy SETUP_PCI rom to kernel space
As EFI stub code could put them high when on 32bit or with exactmap=
on 64bit conf.
Check if the range is mapped, otherwise allocate new one and have
the rom data copied. So we could access them directly.
Signed-off-by: Yinghai Lu
---
arch/x86/pci/common.c | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 67dc2a9..15e1b3f 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -697,6 +697,48 @@ struct firmware_setup_pci_entry {
static LIST_HEAD(setup_pci_entries);
+static phys_addr_t check_copy(phys_addr_t start, unsigned long size)
+{
+ unsigned long start_pfn = PFN_DOWN(start);
+ unsigned long end_pfn = PFN_UP(start + size);
+ unsigned char *p, *q;
+ phys_addr_t pa_p, pa_q;
+ long sz = size;
+
+ if (pfn_range_is_mapped(start_pfn, end_pfn))
+ return start;
+
+ /* allocate and copy */
+ pa_p = memblock_alloc(size, PAGE_SIZE);
+ if (!pa_p)
+ return start;
+
+ p = phys_to_virt(pa_p);
+
+ pa_q = start;
+ while (sz > 0) {
+ long chunk_size = 64<<10;
+
+ if (chunk_size > sz)
+ chunk_size = sz;
+
+ q = early_memremap(pa_q, chunk_size);
+ if (!q) {
+ memblock_free(pa_p, size);
+ return start;
+ }
+ memcpy(p, q, chunk_size);
+ early_memunmap(q, chunk_size);
+ p += chunk_size;
+ pa_q += chunk_size;
+ sz -= chunk_size;
+ }
+
+ memblock_free(start, size);
+
+ return pa_p;
+}
+
int __init fill_setup_pci_entries(void)
{
struct setup_data *data;
@@ -726,8 +768,9 @@ int __init fill_setup_pci_entries(void)
entry->vendor = rom->vendor;
entry->devid = rom->devid;
entry->pcilen = rom->pcilen;
- entry->romdata = pa_data +
-offsetof(struct pci_setup_rom, romdata);
+ entry->romdata = check_copy(pa_data +
+ offsetof(struct pci_setup_rom, romdata),
+ rom->pcilen);
list_add(&entry->list, &setup_pci_entries);
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/8] x86: Kill E820_RESERVED_KERN
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve setup_data by their own.
(Now kexec-tools create SETUP_EFI and SETUP_E820_EXT).
We can kill E820_RESERVED_KERN and not touch e820 map at all.
That will fix bug in mark_nonsave_region that can not handle that
case: E820_RAM and E820_RESERVED_KERN ranges are continuous and
boundary is not page aligned.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=913885
Reported-by: "Lee, Chun-Yi"
Tested-by: "Lee, Chun-Yi"
Cc: "Lee, Chun-Yi"
Signed-off-by: Yinghai Lu
Cc: sta...@vger.kernel.org
---
arch/x86/include/uapi/asm/e820.h | 9 -
arch/x86/kernel/e820.c | 6 ++
arch/x86/kernel/setup.c | 26 --
arch/x86/kernel/tboot.c | 3 +--
arch/x86/mm/init_64.c| 11 ---
5 files changed, 7 insertions(+), 48 deletions(-)
diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index d993e33..edc8a71 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -33,15 +33,6 @@
#define E820_NVS 4
#define E820_UNUSABLE 5
-
-/*
- * reserved RAM used by kernel itself
- * if CONFIG_INTEL_TXT is enabled, memory of this type will be
- * included in the S3 integrity calculation and so should not include
- * any memory that BIOS might alter over the S3 transition
- */
-#define E820_RESERVED_KERN128
-
#ifndef __ASSEMBLY__
#include
struct e820entry {
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 46201de..2a6bed9 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -134,7 +134,6 @@ static void __init e820_print_type(u32 type)
{
switch (type) {
case E820_RAM:
- case E820_RESERVED_KERN:
printk(KERN_CONT "usable");
break;
case E820_RESERVED:
@@ -688,7 +687,7 @@ void __init e820_mark_nosave_regions(unsigned long
limit_pfn)
register_nosave_region(pfn, PFN_UP(ei->addr));
pfn = PFN_DOWN(ei->addr + ei->size);
- if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN)
+ if (ei->type != E820_RAM)
register_nosave_region(PFN_UP(ei->addr), pfn);
if (pfn >= limit_pfn)
@@ -902,7 +901,6 @@ void __init finish_e820_parsing(void)
static inline const char *e820_type_to_string(int e820_type)
{
switch (e820_type) {
- case E820_RESERVED_KERN:
case E820_RAM: return "System RAM";
case E820_ACPI: return "ACPI Tables";
case E820_NVS: return "ACPI Non-volatile Storage";
@@ -1077,7 +1075,7 @@ void __init memblock_x86_fill(void)
if (end != (resource_size_t)end)
continue;
- if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN)
+ if (ei->type != E820_RAM)
continue;
memblock_add(ei->addr, ei->size);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 912f124..aed343b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -478,30 +478,6 @@ static void __init parse_setup_data(void)
}
}
-static void __init e820_reserve_setup_data(void)
-{
- struct setup_data *data;
- u64 pa_data;
- int found = 0;
-
- pa_data = boot_params.hdr.setup_data;
- while (pa_data) {
- data = early_memremap(pa_data, sizeof(*data));
- e820_update_range(pa_data, sizeof(*data)+data->len,
-E820_RAM, E820_RESERVED_KERN);
- found = 1;
- pa_data = data->next;
- early_iounmap(data, sizeof(*data));
- }
- if (!found)
- return;
-
- sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
- memcpy(&e820_saved, &e820, sizeof(struct e820map));
- printk(KERN_INFO "extended physical RAM map:\n");
- e820_print_map("reserve setup_data");
-}
-
static void __init memblock_x86_reserve_range_setup_data(void)
{
struct setup_data *data;
@@ -1037,8 +1013,6 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
#endif
- /* update the e820_saved too */
- e820_reserve_setup_data();
finish_e820_parsing();
if (efi_enabled(EFI_BOOT))
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 91a4496..3c2752a 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -195,8 +195,7 @@ static int tboot_setup_sleep(void)
tboot->num_mac_regions = 0;
for (i = 0; i < e820.nr_map; i++) {
- if ((e820.map[i].type != E820_RAM)
-&& (e820.map[i].type != E820_RESERVED_KERN))
+ if (e820.map[i
Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
On Sun, Mar 08, 2015 at 01:01:14AM +0100, Rafał Miłecki wrote: > Thanks for your work on this. It looks amazing, nice piece of code :) Thanks :) And thanks for testing this. I believe I suggested to you that I'd be releasing this "soon" several months ago. Better late than never, I guess? > On 7 March 2015 at 02:18, Brian Norris wrote: > > This adds (long in coming) support for the Broadcom BCM7xxx Set-Top Box NAND > > controller. This controller has been used in a variety of Broadcom SoCs. > > > > There are a few more features I'd like add in the near future, mostly to > > support more SoCs, but this is the base set, which should only need > > relatively > > minor additions to support chips like BCM63138, BCM3384, and Cygnus/iProc. > > Particularly, we may need to straighten out some endianness issues for the > > data > > path on iProc, and interrupt enabling/acking on iProc, BCM63xxx, BCM3xxx, > > and > > others. > > After applying workaround for not working IRQ, it seems I have some > problem with endianess on my BCM4708 (SoC with 6.01 controller). > > Let me start with dumps of "nvram" MTD partition. > 1) Dumping with Netgear's original firmware: > # hexdump -C -n 16 mtdblock1.bin > 46 4c 53 48 40 79 00 00 84 01 00 00 47 01 1c 08 |FLSH@y..G...| > 2) Dumping with OpenWrt and its bcm_nand.c: > root@OpenWrt:/# hexdump -C -n 16 /dev/mtdblock1 > 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c 08 |FLSH8y..G...| > > This makes me feel that bcm_nand.c driver is OK. > Unfortunately when using brcmstb_nand.c my bcm47xxpart partition > driver didn't detect any partition at all. This means I couldn't use > any /dev/mtdblockX, not even user space as it wasn't mounted. > > So since I didn't have user space, I decided to add some debugging to > bcm47xxpart itself. There is what I got: > 1) OpenWrt and its bcm_nand.c: > [bcm47xxpart_parse] 0x8 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c > 08 > 2) OpenWrt and brcmstb_nand.c: > [bcm47xxpart_parse] 0x8 48 53 4c 46 00 00 79 38 00 00 01 cb 08 1c 01 > 47 > > So obviously data returned by brcmstb_nand.c seems to be all > endianess-flipped. Could you take a loo at this? I'll take a look at all your comments/questions when I get back into the office, but a few pointers: 1. IRQs are a touchy subject; for platforms I've supported, I've found it best if the NAND interrupt bits are handled in an irqchip driver. Particularly, that's one of the use cases for drivers/irqchip/irq-brcmstb-l2.c. If you can arrange the NAND enable/ack registers to act as a second-level interrupt controller, that should hopefully solve your problems. But if BCM4708's NAND interrupt registers can't be shaped into a sane irqchip driver, then we can probably handle them in a per-SoC extension of the driver. I have code already that supports another chip in this way, so I can point you that way if the first suggestion doesn't work out. 2. Endianness is a known issue with at least one other platform. On many chips (spanning MIPS LE, MIPS BE, and ARM LE), NAND has been integrated such that data can just be read/programmed in the native endianness through the FLASH_CACHE registers (as this driver does), but there are a few (on ARM, LE) that require a be32_to_cpu()/cpu_to_be32() swap. I'm considering supporting DT properties like one of the following: brcm,nand-cache-be brcm,nand-cache-big-endian brcm,nand-cache-reverse-endian You might also check (though I might actually be better equipped for this) if there is a separate register that can tell the NAND data bus to automatically endian-swap data into the native endianness. I know a lot of the buses and peripherals in BCG, at least, are designed such that either (1) they can work naturally in the CPU's native endianness or else (2) they can be configured to swap endianness into either format. But if such a register does not exist, then we'll definitely have to do something like the DT property above. Do the bad block markers look OK without extra endian swapping? I'm wondering whether the swapping will have to occur on both the FLASH_CACHE and SPARE_AREA registers. 3. I was told that there were only 2 or 3 chips that were released with a v6.1 NAND controller, and BCM4708 wasn't one of them. Apparently I was told wrong... I'll have to see if there are any other quirks we should be accounting for. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block, drbd: fix drbd_req_new() initialization
On Sat, 7 Mar 2015, Jens Axboe wrote: > > mempool_alloc() does not support __GFP_ZERO since elements may come from > > memory that has already been released by mempool_free(). > > > > Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly > > initialize it to 0. > > You should add it to mempool instead, avoid having this issue show up for > other folks as well. It'd be trivial to do. Normal ->alloc() should honor > __GFP_ZERO, just do the same manually for removing an item from the internal > pool. > Umm, it's not trivial to do and wouldn't make sense to do it. Mempools don't know the element size, in other words it wouldn't know the length to memset() to 0 for mempool_alloc(). It shouldn't be modified to know the element size since elements are allocated by the implementation of mempool_alloc_t and they could easily become inconsistent. This patch is what you want to merge, really. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/8] x86, efi: Copy SETUP_EFI data and access directly
The copy will be in __initdata, and it is small.
We can use pointer to access the setup_data instead of using early_memmap
everywhere.
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/efi.h | 2 +-
arch/x86/platform/efi/efi.c| 13 ++---
arch/x86/platform/efi/efi_64.c | 13 -
arch/x86/platform/efi/quirks.c | 23 ++-
4 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 25bce45..edbecd6 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -114,7 +114,7 @@ struct efi_setup_data {
u64 reserved[8];
};
-extern u64 efi_setup;
+extern struct efi_setup_data *efi_setup;
#ifdef CONFIG_EFI
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index dbc8627..1cd38e8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -68,7 +68,7 @@ static efi_config_table_type_t arch_tables[] __initdata = {
{NULL_GUID, NULL, NULL},
};
-u64 efi_setup; /* efi setup_data physical address */
+struct efi_setup_data *efi_setup __initdata; /* cached efi setup_data pointer
*/
static int add_efi_memmap __initdata;
static int __init setup_add_efi_memmap(char *arg)
@@ -225,20 +225,13 @@ static int __init efi_systab_init(void *phys)
{
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *systab64;
- struct efi_setup_data *data = NULL;
+ struct efi_setup_data *data = efi_setup;
u64 tmp = 0;
- if (efi_setup) {
- data = early_memremap(efi_setup, sizeof(*data));
- if (!data)
- return -ENOMEM;
- }
systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
- if (data)
- early_memunmap(data, sizeof(*data));
return -ENOMEM;
}
@@ -271,8 +264,6 @@ static int __init efi_systab_init(void *phys)
tmp |= data ? data->tables : systab64->tables;
early_memunmap(systab64, sizeof(*systab64));
- if (data)
- early_memunmap(data, sizeof(*data));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 17e80d8..a541c6c 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -292,9 +292,20 @@ void __iomem *__init efi_ioremap(unsigned long phys_addr,
unsigned long size,
return (void __iomem *)__va(phys_addr);
}
+static struct efi_setup_data efi_setup_data __initdata;
+
void __init parse_efi_setup(u64 phys_addr, u32 data_len)
{
- efi_setup = phys_addr + sizeof(struct setup_data);
+ struct efi_setup_data *data;
+
+ data = early_memremap(phys_addr + sizeof(struct setup_data),
+ sizeof(*data));
+ if (!data)
+ return;
+
+ efi_setup_data = *data;
+ early_memunmap(data, sizeof(*data));
+ efi_setup = &efi_setup_data;
}
void __init efi_runtime_mkexec(void)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 1c7380d..45fec7d 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -203,9 +203,8 @@ void __init efi_free_boot_services(void)
*/
int __init efi_reuse_config(u64 tables, int nr_tables)
{
- int i, sz, ret = 0;
+ int i, sz;
void *p, *tablep;
- struct efi_setup_data *data;
if (!efi_setup)
return 0;
@@ -213,22 +212,15 @@ int __init efi_reuse_config(u64 tables, int nr_tables)
if (!efi_enabled(EFI_64BIT))
return 0;
- data = early_memremap(efi_setup, sizeof(*data));
- if (!data) {
- ret = -ENOMEM;
- goto out;
- }
-
- if (!data->smbios)
- goto out_memremap;
+ if (!efi_setup->smbios)
+ return 0;
sz = sizeof(efi_config_table_64_t);
p = tablep = early_memremap(tables, nr_tables * sz);
if (!p) {
pr_err("Could not map Configuration table!\n");
- ret = -ENOMEM;
- goto out_memremap;
+ return -ENOMEM;
}
for (i = 0; i < efi.systab->nr_tables; i++) {
@@ -237,15 +229,12 @@ int __init efi_reuse_config(u64 tables, int nr_tables)
guid = ((efi_config_table_64_t *)p)->guid;
if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
- ((efi_config_table_64_t *)p)->table = da
[PATCH v3 1/8] x86: Kill E820_RESERVED_KERN
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve setup_data by their own.
(Now kexec-tools create SETUP_EFI and SETUP_E820_EXT).
We can kill E820_RESERVED_KERN and not touch e820 map at all.
That will fix bug in mark_nonsave_region that can not handle that
case: E820_RAM and E820_RESERVED_KERN ranges are continuous and
boundary is not page aligned.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=913885
Reported-by: "Lee, Chun-Yi"
Tested-by: "Lee, Chun-Yi"
Cc: "Lee, Chun-Yi"
Signed-off-by: Yinghai Lu
Cc: sta...@vger.kernel.org
---
arch/x86/include/uapi/asm/e820.h | 9 -
arch/x86/kernel/e820.c | 6 ++
arch/x86/kernel/setup.c | 26 --
arch/x86/kernel/tboot.c | 3 +--
arch/x86/mm/init_64.c| 11 ---
5 files changed, 7 insertions(+), 48 deletions(-)
diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index d993e33..edc8a71 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -33,15 +33,6 @@
#define E820_NVS 4
#define E820_UNUSABLE 5
-
-/*
- * reserved RAM used by kernel itself
- * if CONFIG_INTEL_TXT is enabled, memory of this type will be
- * included in the S3 integrity calculation and so should not include
- * any memory that BIOS might alter over the S3 transition
- */
-#define E820_RESERVED_KERN128
-
#ifndef __ASSEMBLY__
#include
struct e820entry {
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 46201de..2a6bed9 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -134,7 +134,6 @@ static void __init e820_print_type(u32 type)
{
switch (type) {
case E820_RAM:
- case E820_RESERVED_KERN:
printk(KERN_CONT "usable");
break;
case E820_RESERVED:
@@ -688,7 +687,7 @@ void __init e820_mark_nosave_regions(unsigned long
limit_pfn)
register_nosave_region(pfn, PFN_UP(ei->addr));
pfn = PFN_DOWN(ei->addr + ei->size);
- if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN)
+ if (ei->type != E820_RAM)
register_nosave_region(PFN_UP(ei->addr), pfn);
if (pfn >= limit_pfn)
@@ -902,7 +901,6 @@ void __init finish_e820_parsing(void)
static inline const char *e820_type_to_string(int e820_type)
{
switch (e820_type) {
- case E820_RESERVED_KERN:
case E820_RAM: return "System RAM";
case E820_ACPI: return "ACPI Tables";
case E820_NVS: return "ACPI Non-volatile Storage";
@@ -1077,7 +1075,7 @@ void __init memblock_x86_fill(void)
if (end != (resource_size_t)end)
continue;
- if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN)
+ if (ei->type != E820_RAM)
continue;
memblock_add(ei->addr, ei->size);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 912f124..aed343b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -478,30 +478,6 @@ static void __init parse_setup_data(void)
}
}
-static void __init e820_reserve_setup_data(void)
-{
- struct setup_data *data;
- u64 pa_data;
- int found = 0;
-
- pa_data = boot_params.hdr.setup_data;
- while (pa_data) {
- data = early_memremap(pa_data, sizeof(*data));
- e820_update_range(pa_data, sizeof(*data)+data->len,
-E820_RAM, E820_RESERVED_KERN);
- found = 1;
- pa_data = data->next;
- early_iounmap(data, sizeof(*data));
- }
- if (!found)
- return;
-
- sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
- memcpy(&e820_saved, &e820, sizeof(struct e820map));
- printk(KERN_INFO "extended physical RAM map:\n");
- e820_print_map("reserve setup_data");
-}
-
static void __init memblock_x86_reserve_range_setup_data(void)
{
struct setup_data *data;
@@ -1037,8 +1013,6 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
#endif
- /* update the e820_saved too */
- e820_reserve_setup_data();
finish_e820_parsing();
if (efi_enabled(EFI_BOOT))
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 91a4496..3c2752a 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -195,8 +195,7 @@ static int tboot_setup_sleep(void)
tboot->num_mac_regions = 0;
for (i = 0; i < e820.nr_map; i++) {
- if ((e820.map[i].type != E820_RAM)
-&& (e820.map[i].type != E820_RESERVED_KERN))
+ if (e820.map[i
[PATCH v3 0/8] x86, boot: clean up setup_data handling
Now setup_data is reserved via memblock and e820 and different handlers have different ways, and it is confusing. 1. SETUP_E820_EXT: is consumed early and will not copy or access again. have memory wasted. 2. SETUP_EFI: is accessed via ioremap every time at early stage. have memory wasted. 3. SETUP_DTB: is copied locally. have memory wasted. 4. SETUP_PCI: is accessed via ioremap for every pci devices, even run-time. 5. SETUP_KASLR: is accessed early, will not copy or access again. have memory wasted. Also setup_data is exported to debugfs for debug purpose. Here will convert to let every handler to decide how to handle it. and will not reserve the setup_data generally, so will not waste memory and also make memblock/e820 keep page aligned. 1. not touch E820 anymore. 2. copy SETUP_EFI to __initdata variable and access it without ioremap. 3. SETUP_DTB: reserver and copy to local and free. 4. SETUP_PCI: reverve localy and convert to list, to avoid keeping ioremap. 5. export SETUP_PCI via sysfs. Also put them in: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-4.0-rc2-setup_data Should be materials for v4.1. Thanks Yinghai Lu -v3: separated with kasl patches, and fix early_ioremap return checking. Yinghai Lu (8): x86: Kill E820_RESERVED_KERN x86, efi: Copy SETUP_EFI data and access directly x86, of: Let add_dtb reserve setup_data locally x86, boot: Add add_pci handler for SETUP_PCI x86: Kill not used setup_data handling code x86, boot, PCI: Convert SETUP_PCI data to list x86, boot, PCI: Copy SETUP_PCI rom to kernel space x86, boot, PCI: Export SETUP_PCI data via sysfs arch/x86/include/asm/efi.h | 2 +- arch/x86/include/asm/pci.h | 4 + arch/x86/include/asm/prom.h | 9 +- arch/x86/include/uapi/asm/e820.h | 9 -- arch/x86/kernel/devicetree.c | 43 +++--- arch/x86/kernel/e820.c | 6 +- arch/x86/kernel/kdebugfs.c | 142 -- arch/x86/kernel/setup.c | 52 ++- arch/x86/kernel/tboot.c | 3 +- arch/x86/mm/init_64.c| 11 +- arch/x86/pci/common.c| 316 --- arch/x86/platform/efi/efi.c | 13 +- arch/x86/platform/efi/efi_64.c | 13 +- arch/x86/platform/efi/quirks.c | 23 +-- 14 files changed, 371 insertions(+), 275 deletions(-) -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
On Saturday, March 07, 2015 12:29:33 PM Pavel Machek wrote: > On Sat 2015-03-07 12:06:45, Alexandre Belloni wrote: > > On 07/03/2015 at 11:39:39 +0100, Pavel Machek wrote : > > > > The Atmel watchdog can't be stopped once it's started. This is actually > > > > very useful so we can reset if suspend or resume failed, the only > > > > drawback is that you have to wake up from time to time (e.g. by using > > > > the RTC/RTT) to clear the watchdog and then go back to sleep ASAP. > > > > > > Yeah. So you do "echo mem > /sys/power/state", and few seconds/minutes > > > after watchdog kills the system. But you did not ask for dead system, > > > you asked for suspend. > > > > > > And while that behaviour is useful for you, I don't think it is > > > exactly useful behaviour, nor it is the behaviour user would expect. > > > > > > > I think you misunderstood, that is exactly the expected behaviour. This > > is hardware defined. Once the watchdog is started, nobody can stop it. > > Trying to change the mode register will result in a reset of the > > SoC. > > Well, it boils down to "what is stronger". Desire to suspend the > system, or desire to reboot the system. > > It is "echo mem > state", not "echo reboot > state". > > > It is documented in the datasheet and any user wanting another behaviour > > is out of luck. > > Actaully, your platform should just refuse to enter suspend-to-RAM > when hw watchdog is enabled. Quite likely, depending on how exactly the suspend is implemented. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
On Saturday, March 07, 2015 12:06:45 PM Alexandre Belloni wrote: > On 07/03/2015 at 11:39:39 +0100, Pavel Machek wrote : > > > The Atmel watchdog can't be stopped once it's started. This is actually > > > very useful so we can reset if suspend or resume failed, the only > > > drawback is that you have to wake up from time to time (e.g. by using > > > the RTC/RTT) to clear the watchdog and then go back to sleep ASAP. > > > > Yeah. So you do "echo mem > /sys/power/state", and few seconds/minutes > > after watchdog kills the system. But you did not ask for dead system, > > you asked for suspend. > > > > And while that behaviour is useful for you, I don't think it is > > exactly useful behaviour, nor it is the behaviour user would expect. > > > > I think you misunderstood, that is exactly the expected behaviour. This > is hardware defined. Once the watchdog is started, nobody can stop it. > Trying to change the mode register will result in a reset of the SoC. > > It is documented in the datasheet and any user wanting another behaviour > is out of luck. > > So basically, when using a watchdog, you have to wake up every 15-16s to > restart it. So question is if we need a separate interrupt handler for that, expecially since it is shared with the PIT timer anyway. Seems to me that the simplest way out of this conundrum would be to simply make the timer's interrupt handler kick the watchdog every once a while and get rid of the separate watchdog interrupt handler entirely. While at it, can anyone explain to me please how the suspend state (full suspend) looks like on that platform? What's different from the working state in particular. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] dm log userspace: use mempool_create_kmalloc_pool()
Mempools created for kmalloc caches should use
mempool_create_kmalloc_pool().
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Neil Brown
Signed-off-by: David Rientjes
---
drivers/md/dm-log-userspace-base.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/md/dm-log-userspace-base.c
b/drivers/md/dm-log-userspace-base.c
--- a/drivers/md/dm-log-userspace-base.c
+++ b/drivers/md/dm-log-userspace-base.c
@@ -74,18 +74,6 @@ struct log_c {
uint32_t integrated_flush;
};
-static mempool_t *flush_entry_pool;
-
-static void *flush_entry_alloc(gfp_t gfp_mask, void *pool_data)
-{
- return kmalloc(sizeof(struct flush_entry), gfp_mask);
-}
-
-static void flush_entry_free(void *element, void *pool_data)
-{
- kfree(element);
-}
-
static int userspace_do_request(struct log_c *lc, const char *uuid,
int request_type, char *data, size_t data_size,
char *rdata, size_t *rdata_size)
@@ -537,6 +525,8 @@ static int flush_by_group(struct log_c *lc, struct
list_head *flush_list,
return r;
}
+static mempool_t *flush_entry_pool;
+
/*
* userspace_flush
*
@@ -886,9 +876,8 @@ static int __init userspace_dirty_log_init(void)
{
int r = 0;
- flush_entry_pool = mempool_create(100, flush_entry_alloc,
- flush_entry_free, NULL);
-
+ flush_entry_pool = mempool_create_kmalloc_pool(100,
+ sizeof(struct flush_entry));
if (!flush_entry_pool) {
DMWARN("Unable to create flush_entry_pool: No memory.");
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 18:39, Rafał Miłecki wrote: > It seems that brcmnand_ctlrdy_irq never fires on my device. Just like > controller was never generating any IRQ. > > > I started comparing your driver with OpenWrt's bcm_nand.c (which > should be very similar to Broadcom's SDK NAND driver for ARM). Below > are few things I've noticed. > > 1) In bcm_nand.c IRQ handler also doesn't seem to be fired (or very rarely). Oh, wait, I was wrong there. So in bcm_nand.c IRQ handler fires very often, just not during the early phase (RESET, READID), when we don't use IRQs. During standard read/program/etc IRQ is commonly used. So maybe all we're missing in case of brcmstb_nand.c is enabling/acking/disabling IRQ? It seem that my controller 6.01 has: 1) Following IRQs: DIREC_READ_MISS ERASE_COMPLETE COPYBACK_COMPLETE PROGRAM_COMPLETE CONTROLLER_RDY RDBSY_RDY ECC_UNCORRECTABLE ECC_CORRECTABLE 2) Registers for reading/acking above IRQs: 0xf00 DIREC_READ_MISS 0xf04 ERASE_COMPLETE 0xf08 COPYBACK_COMPLETE 0xf0c PROGRAM_COMPLETE 0xf10 CONTROLLER_RDY 0xf14 RDBSY_RDY 0xf18 ECC_UNCORRECTABLE 0xf1c ECC_CORRECTABLE (if 0x1 is set, it means IRQ was raised, writing 0x1 ack-es it) 3) Register 0x408 for enabling/disabling IRQs: 0x0004 DIREC_READ_MISS 0x0008 ERASE_COMPLETE 0x0010 COPYBACK_COMPLETE 0x0020 PROGRAM_COMPLETE 0x0040 CONTROLLER_RDY 0x0080 RDBSY_RDY 0x0100 ECC_UNCORRECTABLE 0x0200 ECC_CORRECTABLE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block, drbd: fix drbd_req_new() initialization
On 03/07/2015 05:24 PM, David Rientjes wrote: mempool_alloc() does not support __GFP_ZERO since elements may come from memory that has already been released by mempool_free(). Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly initialize it to 0. You should add it to mempool instead, avoid having this issue show up for other folks as well. It'd be trivial to do. Normal ->alloc() should honor __GFP_ZERO, just do the same manually for removing an item from the internal pool. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_
From: Oleg Drokin
This patch continues to further remove deprecated functions, such as
any_online_cpu, for_each_cpu_mask and also cleaning up
usage of NR_CPUS in a few places
Signed-off-by: Oleg Drokin
---
.../staging/lustre/lustre/libcfs/linux/linux-cpu.c | 32 --
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
index 1eeacef..cc3ab35 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c
@@ -204,7 +204,7 @@ cfs_cpt_table_print(struct cfs_cpt_table *cptab, char *buf,
int len)
}
tmp += rc;
- for_each_cpu_mask(j, *cptab->ctb_parts[i].cpt_cpumask) {
+ for_each_cpu(j, cptab->ctb_parts[i].cpt_cpumask) {
rc = snprintf(tmp, len, "%d ", j);
len -= rc;
if (len <= 0) {
@@ -251,8 +251,10 @@ cfs_cpt_online(struct cfs_cpt_table *cptab, int cpt)
LASSERT(cpt == CFS_CPT_ANY || (cpt >= 0 && cpt < cptab->ctb_nparts));
return cpt == CFS_CPT_ANY ?
- any_online_cpu(*cptab->ctb_cpumask) < nr_cpu_ids :
- any_online_cpu(*cptab->ctb_parts[cpt].cpt_cpumask) < nr_cpu_ids;
+ cpumask_any_and(cptab->ctb_cpumask,
+ cpu_online_mask) < nr_cpu_ids :
+ cpumask_any_and(cptab->ctb_parts[cpt].cpt_cpumask,
+ cpu_online_mask) < nr_cpu_ids;
}
EXPORT_SYMBOL(cfs_cpt_online);
@@ -356,22 +358,22 @@ cfs_cpt_unset_cpu(struct cfs_cpt_table *cptab, int cpt,
int cpu)
LASSERT(node_isset(node, *cptab->ctb_parts[cpt].cpt_nodemask));
LASSERT(node_isset(node, *cptab->ctb_nodemask));
- for_each_cpu_mask(i, *cptab->ctb_parts[cpt].cpt_cpumask) {
+ for_each_cpu(i, cptab->ctb_parts[cpt].cpt_cpumask) {
/* this CPT has other CPU belonging to this node? */
if (cpu_to_node(i) == node)
break;
}
- if (i == NR_CPUS)
+ if (i >= nr_cpu_ids)
node_clear(node, *cptab->ctb_parts[cpt].cpt_nodemask);
- for_each_cpu_mask(i, *cptab->ctb_cpumask) {
+ for_each_cpu(i, cptab->ctb_cpumask) {
/* this CPT-table has other CPU belonging to this node? */
if (cpu_to_node(i) == node)
break;
}
- if (i == NR_CPUS)
+ if (i >= nr_cpu_ids)
node_clear(node, *cptab->ctb_nodemask);
return;
@@ -383,13 +385,14 @@ cfs_cpt_set_cpumask(struct cfs_cpt_table *cptab, int cpt,
cpumask_t *mask)
{
int i;
- if (cpumask_weight(mask) == 0 || any_online_cpu(*mask) >= nr_cpu_ids) {
+ if (cpumask_weight(mask) == 0 ||
+ cpumask_any_and(mask, cpu_online_mask) >= nr_cpu_ids) {
CDEBUG(D_INFO, "No online CPU is found in the CPU mask for CPU
partition %d\n",
cpt);
return 0;
}
- for_each_cpu_mask(i, *mask) {
+ for_each_cpu(i, mask) {
if (!cfs_cpt_set_cpu(cptab, cpt, i))
return 0;
}
@@ -403,7 +406,7 @@ cfs_cpt_unset_cpumask(struct cfs_cpt_table *cptab, int cpt,
cpumask_t *mask)
{
int i;
- for_each_cpu_mask(i, *mask)
+ for_each_cpu(i, mask)
cfs_cpt_unset_cpu(cptab, cpt, i);
}
EXPORT_SYMBOL(cfs_cpt_unset_cpumask);
@@ -493,7 +496,7 @@ cfs_cpt_clear(struct cfs_cpt_table *cptab, int cpt)
}
for (; cpt <= last; cpt++) {
- for_each_cpu_mask(i, *cptab->ctb_parts[cpt].cpt_cpumask)
+ for_each_cpu(i, cptab->ctb_parts[cpt].cpt_cpumask)
cfs_cpt_unset_cpu(cptab, cpt, i);
}
}
@@ -578,7 +581,7 @@ cfs_cpt_bind(struct cfs_cpt_table *cptab, int cpt)
nodemask = cptab->ctb_parts[cpt].cpt_nodemask;
}
- if (any_online_cpu(*cpumask) >= nr_cpu_ids) {
+ if (cpumask_any_and(cpumask, cpu_online_mask) >= nr_cpu_ids) {
CERROR("No online CPU found in CPU partition %d, did someone do
CPU hotplug on system? You might need to reload Lustre modules to keep system
working well.\n",
cpt);
return -EINVAL;
@@ -654,7 +657,7 @@ cfs_cpt_choose_ncpus(struct cfs_cpt_table *cptab, int cpt,
LASSERT(!cpumask_empty(core));
- for_each_cpu_mask(i, *core) {
+ for_each_cpu(i, core) {
cpumask_clear_cpu(i, socket);
cpumask_clear_cpu(i, node);
@@ -965,7 +968,8 @@ cfs_cpu_notify(struct notifier_block *self, unsigned long
action, void *hcpu)
mutex_lock(&cpt_data.cpt_mutex);
/* if all HTs in a core are offline, it m
[PATCH 2/4] staging/lustre/o2iblnd: Don't use cpus_weight
From: Oleg Drokin
cpus_weight and for_each_cpu_mask are deprecated, so replace them
with cpumask_weight and for_each_cpu respectively.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 109f44c..b725a99 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -638,8 +638,8 @@ kiblnd_get_completion_vector(kib_conn_t *conn, int cpt)
return 0;
/* hash NID to CPU id in this partition... */
- off = do_div(nid, cpus_weight(*mask));
- for_each_cpu_mask(i, *mask) {
+ off = do_div(nid, cpumask_weight(mask));
+ for_each_cpu(i, mask) {
if (off-- == 0)
return i % vectors;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] staging/lustre/llite: avoid nonatomic memory alloc under spinlock
From: Lai Siyao
ll_intent_drop_lock() may sleep in memory allocation, which
should not be called inside spinlock.
Signed-off-by: Lai Siyao
Signed-off-by: Jian Yu
Reviewed-on: http://review.whamcloud.com/10674
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2272
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/llite/statahead.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/statahead.c
b/drivers/staging/lustre/lustre/llite/statahead.c
index fe732fa..b75562c 100644
--- a/drivers/staging/lustre/lustre/llite/statahead.c
+++ b/drivers/staging/lustre/lustre/llite/statahead.c
@@ -706,11 +706,21 @@ static int ll_statahead_interpret(struct ptlrpc_request
*req,
struct ll_inode_info *lli = ll_i2info(dir);
struct ll_statahead_info *sai = NULL;
struct ll_sa_entry *entry;
+ __u64 handle = 0;
intwakeup;
if (it_disposition(it, DISP_LOOKUP_NEG))
rc = -ENOENT;
+ if (rc == 0) {
+ /* release ibits lock ASAP to avoid deadlock when statahead
+* thread enqueues lock on parent in readdir and another
+* process enqueues lock on child with parent lock held, eg.
+* unlink. */
+ handle = it->d.lustre.it_lock_handle;
+ ll_intent_drop_lock(it);
+ }
+
spin_lock(&lli->lli_sa_lock);
/* stale entry */
if (unlikely(lli->lli_sai == NULL ||
@@ -745,8 +755,7 @@ static int ll_statahead_interpret(struct ptlrpc_request
*req,
* when statahead thread tries to enqueue lock on parent
* for readpage and other tries to enqueue lock on child
* with parent's lock held, for example: unlink. */
- entry->se_handle = it->d.lustre.it_lock_handle;
- ll_intent_drop_lock(it);
+ entry->se_handle = handle;
wakeup = sa_received_empty(sai);
list_add_tail(&entry->se_list,
&sai->sai_entries_received);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Lustre fixes
From: Oleg Drokin The first two patches are a follow on for the previous patch series on not using deprecated cpumask-related code. And two blocking while atomic/not running fixes. Please consider. Lai Siyao (1): staging/lustre/llite: avoid nonatomic memory alloc under spinlock Oleg Drokin (3): staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_ staging/lustre/o2iblnd: Don't use cpus_weight staging/lustre: Don't call blocking funcitons when !RUNNABLE .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 4 +-- .../staging/lustre/lustre/libcfs/linux/linux-cpu.c | 32 -- .../lustre/lustre/libcfs/linux/linux-tcpip.c | 10 +++ drivers/staging/lustre/lustre/llite/statahead.c| 13 +++-- 4 files changed, 35 insertions(+), 24 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] staging/lustre: Don't call blocking funcitons when !RUNNABLE
From: Oleg Drokin
Move setting of TASK_INTERRUPTIBLE just around schedule call in
libcfs_sock_accept.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/libcfs/linux/linux-tcpip.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-tcpip.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-tcpip.c
index cd2fc01..f2462e7 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-tcpip.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-tcpip.c
@@ -543,19 +543,17 @@ libcfs_sock_accept (struct socket **newsockp, struct
socket *sock)
newsock->ops = sock->ops;
- set_current_state(TASK_INTERRUPTIBLE);
- add_wait_queue(sk_sleep(sock->sk), &wait);
-
rc = sock->ops->accept(sock, newsock, O_NONBLOCK);
if (rc == -EAGAIN) {
/* Nothing ready, so wait for activity */
+ set_current_state(TASK_INTERRUPTIBLE);
+ add_wait_queue(sk_sleep(sock->sk), &wait);
schedule();
+ remove_wait_queue(sk_sleep(sock->sk), &wait);
+ set_current_state(TASK_RUNNING);
rc = sock->ops->accept(sock, newsock, O_NONBLOCK);
}
- remove_wait_queue(sk_sleep(sock->sk), &wait);
- set_current_state(TASK_RUNNING);
-
if (rc != 0)
goto failed;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] block, drbd: use mempool_create_slab_pool()
Mempools created for slab caches should use mempool_create_slab_pool(). Cc: Lars Ellenberg Cc: Jens Axboe Signed-off-by: David Rientjes --- drivers/block/drbd/drbd_main.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c --- a/drivers/block/drbd/drbd_main.c +++ b/drivers/block/drbd/drbd_main.c @@ -2107,13 +2107,12 @@ static int drbd_create_mempools(void) if (drbd_md_io_page_pool == NULL) goto Enomem; - drbd_request_mempool = mempool_create(number, - mempool_alloc_slab, mempool_free_slab, drbd_request_cache); + drbd_request_mempool = mempool_create_slab_pool(number, + drbd_request_cache); if (drbd_request_mempool == NULL) goto Enomem; - drbd_ee_mempool = mempool_create(number, - mempool_alloc_slab, mempool_free_slab, drbd_ee_cache); + drbd_ee_mempool = mempool_create_slab_pool(number, drbd_ee_cache); if (drbd_ee_mempool == NULL) goto Enomem; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] block, drbd: fix drbd_req_new() initialization
mempool_alloc() does not support __GFP_ZERO since elements may come from
memory that has already been released by mempool_free().
Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
initialize it to 0.
Cc: Lars Ellenberg
Cc: Jens Axboe
Signed-off-by: David Rientjes
---
drivers/block/drbd/drbd_req.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -52,9 +52,10 @@ static struct drbd_request *drbd_req_new(struct drbd_device
*device,
{
struct drbd_request *req;
- req = mempool_alloc(drbd_request_mempool, GFP_NOIO | __GFP_ZERO);
+ req = mempool_alloc(drbd_request_mempool, GFP_NOIO);
if (!req)
return NULL;
+ memset(req, 0, sizeof(*req));
drbd_req_make_private_bio(req, bio_src);
req->rq_state= bio_data_dir(bio_src) == WRITE ? RQ_WRITE : 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 tip 0/7] tracing: attach eBPF programs to kprobes
On 3/6/15 5:09 PM, Steven Rostedt wrote: On Wed, 4 Mar 2015 15:48:24 -0500 Steven Rostedt wrote: On Wed, 4 Mar 2015 21:33:16 +0100 Ingo Molnar wrote: * Alexei Starovoitov wrote: On Sun, Mar 1, 2015 at 3:27 PM, Alexei Starovoitov wrote: Peter, Steven, I think this set addresses everything we've discussed. Please review/ack. Thanks! icmp echo request I'd really like to have an Acked-by from Steve (propagated into the changelogs) before looking at applying these patches. I'll have to look at this tomorrow. I'm a bit swamped with other things at the moment :-/ Just an update. I started looking at it but then was pulled off to do other things. I'll make this a priority next week. Sorry for the delay. There is no rush. Please let me know if I need to clarify anything. One thing I just caught which I'm planning to address in the follow on patch is missing 'recursion check'. Since attaching programs to kprobes means that root may create loops by adding a kprobe somewhere in the call chain invoked from bpf program. So far I'm thinking to do simple stack_trace_call()-like check. I don't think it's a blocker for this set, but if I'm done coding recursion soon, I'll just roll it in and respin this set :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
السلام عليكم
مرحبا عزيزي، أنا ميريام راجحة، اتصلت لك بقلب مثقل بسبب الصراع أو العنف في بلدي سوريا، حيث كانت هناك اعتقالات والجماعية شعبي البلاد مما أسفر عن مقتل بسبب الهجمات بين الحكومة و المعار&# 1590;ة المعروفة باسم الائتلاف الوطني لقوى الثورة والمعارضة السورية. بسبب العلاقة الوثيقة بين عائلتي مع حكومة الأسد، ونحن مستهدفون باستمرار من قبل المتمردين وكفلائهم. أنا، كان زوجي أرملة وزير الدفاع السابق داود راجحة سوريا مسؤول كبير سابق في حكومة بشار الأسعد تعرض للهجوم من قبل المتمردين 19 يوليو 2012 عندما بلدي في وقت متأخر يقدم الزوج في ا 4;حكومة وزيرا للدفاع في بلدي. بعد وفاته تمكنت من انقاذ مبلغ (تسعة مليون وخمسمائة دولار أمريكي أنا على الاتصال بك وهو مؤمن مسلم وطبيب مساعدتنا لمحبة الله نحن عالقة وحركتنا محدودة، ونحن لا يمكن أن تجعل تشريد لبلدنا لأنها مستهدفة جدا من قبل المتمردين لإنقاذ هذا الم&# 1575;ل أريد رجل صادق وجاد لمساعدتنا. بسبب الوضع في بلادنا أرى البارع للأمة المتحدة أكثر أمنا لإيداع الأموال. I المودعة تحت تهمة للأمة متحدة في مكان آمن وكذلك عائلة لديها ما يقرب من التحرك في الخارج على الحمل، ولكن دون تحديد أنه هو المال لسبب من الأمن. وفقا لإيصالات المعلومات أن الكثير من الامم المتحدة ستغادر قريبا سوريا لذلك أنا لن أود أن أغتنم هذه الفرصة لتحريك ثروة في الخارج، ولست بحاجة مساعدتكم مساعدة فورية تأمي 06; حسن نيتنا. أحتاج معلومات كاملة مثل الاسم الكامل والعنوان ورقم الهاتف، بطاقة الهوية الوطنية أو نسخة من جواز السفر الخاص بك صورة دولية يجري على مقربة من عائلتي يعيشون خارج سوريا حت 609; أتمكن من إعطاء المعلومات لل أمة موحدة. مع أطيب التحيات ميريام راجحة -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support
Hi Brian, Thanks for your work on this. It looks amazing, nice piece of code :) On 7 March 2015 at 02:18, Brian Norris wrote: > This adds (long in coming) support for the Broadcom BCM7xxx Set-Top Box NAND > controller. This controller has been used in a variety of Broadcom SoCs. > > There are a few more features I'd like add in the near future, mostly to > support more SoCs, but this is the base set, which should only need relatively > minor additions to support chips like BCM63138, BCM3384, and Cygnus/iProc. > Particularly, we may need to straighten out some endianness issues for the > data > path on iProc, and interrupt enabling/acking on iProc, BCM63xxx, BCM3xxx, and > others. After applying workaround for not working IRQ, it seems I have some problem with endianess on my BCM4708 (SoC with 6.01 controller). Let me start with dumps of "nvram" MTD partition. 1) Dumping with Netgear's original firmware: # hexdump -C -n 16 mtdblock1.bin 46 4c 53 48 40 79 00 00 84 01 00 00 47 01 1c 08 |FLSH@y..G...| 2) Dumping with OpenWrt and its bcm_nand.c: root@OpenWrt:/# hexdump -C -n 16 /dev/mtdblock1 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c 08 |FLSH8y..G...| This makes me feel that bcm_nand.c driver is OK. Unfortunately when using brcmstb_nand.c my bcm47xxpart partition driver didn't detect any partition at all. This means I couldn't use any /dev/mtdblockX, not even user space as it wasn't mounted. So since I didn't have user space, I decided to add some debugging to bcm47xxpart itself. There is what I got: 1) OpenWrt and its bcm_nand.c: [bcm47xxpart_parse] 0x8 46 4c 53 48 38 79 00 00 cb 01 00 00 47 01 1c 08 2) OpenWrt and brcmstb_nand.c: [bcm47xxpart_parse] 0x8 48 53 4c 46 00 00 79 38 00 00 01 cb 08 1c 01 47 So obviously data returned by brcmstb_nand.c seems to be all endianess-flipped. Could you take a loo at this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] sh, dwarf: use mempool_create_slab_pool()
Mempools created for slab caches should use mempool_create_slab_pool(). Signed-off-by: David Rientjes --- arch/sh/kernel/dwarf.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c --- a/arch/sh/kernel/dwarf.c +++ b/arch/sh/kernel/dwarf.c @@ -1180,17 +1180,13 @@ static int __init dwarf_unwinder_init(void) sizeof(struct dwarf_reg), 0, SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL); - dwarf_frame_pool = mempool_create(DWARF_FRAME_MIN_REQ, - mempool_alloc_slab, - mempool_free_slab, - dwarf_frame_cachep); + dwarf_frame_pool = mempool_create_slab_pool(DWARF_FRAME_MIN_REQ, + dwarf_frame_cachep); if (!dwarf_frame_pool) goto out; - dwarf_reg_pool = mempool_create(DWARF_REG_MIN_REQ, -mempool_alloc_slab, -mempool_free_slab, -dwarf_reg_cachep); + dwarf_reg_pool = mempool_create_slab_pool(DWARF_REG_MIN_REQ, + dwarf_reg_cachep); if (!dwarf_reg_pool) goto out; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] sh, dwarf: destroy mempools on cleanup
dwarf_reg_pool and dwarf_frame_pool are not properly destroyed when
cleaning up the dwarf unwinder. Destroy them with mempool_destroy().
Also mark dwarf_unwinder_cleanup() as __init.
Signed-off-by: David Rientjes
---
arch/sh/kernel/dwarf.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c
--- a/arch/sh/kernel/dwarf.c
+++ b/arch/sh/kernel/dwarf.c
@@ -993,7 +993,7 @@ static struct unwinder dwarf_unwinder = {
.rating = 150,
};
-static void dwarf_unwinder_cleanup(void)
+static void __init dwarf_unwinder_cleanup(void)
{
struct dwarf_fde *fde, *next_fde;
struct dwarf_cie *cie, *next_cie;
@@ -1009,6 +1009,10 @@ static void dwarf_unwinder_cleanup(void)
rbtree_postorder_for_each_entry_safe(cie, next_cie, &cie_root, node)
kfree(cie);
+ if (dwarf_reg_pool)
+ mempool_destroy(dwarf_reg_pool);
+ if (dwarf_frame_pool)
+ mempool_destroy(dwarf_frame_pool);
kmem_cache_destroy(dwarf_reg_cachep);
kmem_cache_destroy(dwarf_frame_cachep);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Anspruch €950,000.00
Liebe Begünstigte, Sie wurden ausgewählt, um (€950.000,00 EURO) als Charity-Spenden / Hilfe der Qatar Foundation erhalten. Kontaktieren Sie uns über E-Mail für weitere Informationen; Mit freundlichen Grüßen, Ingenieur Saad Al Muhannadi. Kontakt e-mail: saadalm...@gmail.com Präsident der Qatar Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] omap3 crypto fixes
Hi, On Fri, Feb 27, 2015 at 01:40:44PM +0100, Pali Rohár wrote: > > However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS > > is not set: > > > > alg: hash: Chunking test 1 failed for omap-sha1 > > alg: hash: Chunking test 1 failed for omap-md5 > > alg: hash: Chunking test 1 failed for omap-hmac-sha1 > > alg: hash: Chunking test 1 failed for omap-hmac-md5 BTW, it seems these errors are reported to be introduced possibly somewhere between 3.11 and 3.15: https://lists.fedoraproject.org/pipermail/arm/2014-August/008240.html A. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 19/21] ARM64 / ACPI: Enable ARM64 in Kconfig
On Wed, 25 Feb 2015 16:39:59 +0800 , Hanjun Guo wrote: > From: Graeme Gregory > > Add Kconfigs to build ACPI on ARM64, and make ACPI available on ARM64. > > acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR > depend on X86 || IA64, and implement it on ARM64 in the future. > > CC: Rafael J. Wysocki > CC: Catalin Marinas > CC: Will Deacon > Reviewed-by: Grant Likely > Tested-by: Suravee Suthikulpanit > Tested-by: Yijing Wang > Tested-by: Mark Langsdorf > Tested-by: Jon Masters > Tested-by: Timur Tabi > Tested-by: Robert Richter > Acked-by: Robert Richter > Signed-off-by: Graeme Gregory > Signed-off-by: Al Stone > Signed-off-by: Hanjun Guo Acked-by: Grant Likely > --- > arch/arm64/Kconfig | 2 ++ > drivers/acpi/Kconfig | 3 ++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index d00ab9a..e5aa081 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -713,6 +713,8 @@ source "drivers/Kconfig" > > source "drivers/firmware/Kconfig" > > +source "drivers/acpi/Kconfig" > + > source "fs/Kconfig" > > source "arch/arm64/kvm/Kconfig" > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index e6c3ddd..7aa3288 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -5,7 +5,7 @@ > menuconfig ACPI > bool "ACPI (Advanced Configuration and Power Interface) Support" > depends on !IA64_HP_SIM > - depends on IA64 || X86 > + depends on IA64 || X86 || (ARM64 && EXPERT) > depends on PCI > select PNP > default y > @@ -163,6 +163,7 @@ config ACPI_PROCESSOR > tristate "Processor" > select THERMAL > select CPU_IDLE > + depends on X86 || IA64 > default y > help > This driver installs ACPI as the idle handler for Linux and uses > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 18/21] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64
On Wed, 25 Feb 2015 16:39:58 +0800 , Hanjun Guo wrote: > From: Al Stone > > ACPI reduced hardware mode is disabled by default, but ARM64 > can only run properly in ACPI hardware reduced mode, so select > ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64. > > CC: Catalin Marinas > CC: Will Deacon > Reviewed-by: Grant Likely > Tested-by: Suravee Suthikulpanit > Tested-by: Yijing Wang > Tested-by: Mark Langsdorf > Tested-by: Jon Masters > Tested-by: Timur Tabi > Tested-by: Robert Richter > Acked-by: Robert Richter > Signed-off-by: Al Stone > Signed-off-by: Hanjun Guo Acked-by: Grant Likely > --- > arch/arm64/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1b8e973..d00ab9a 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1,5 +1,6 @@ > config ARM64 > def_bool y > + select ACPI_REDUCED_HARDWARE_ONLY if ACPI > select ARCH_BINFMT_ELF_RANDOMIZE_PIE > select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE > select ARCH_HAS_GCOV_PROFILE_ALL > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 17/21] clocksource / arch_timer: Parse GTDT to initialize arch timer
On Wed, 25 Feb 2015 16:39:57 +0800
, Hanjun Guo
wrote:
> Using the information presented by GTDT (Generic Timer Description Table)
> to initialize the arch timer (not memory-mapped).
>
> CC: Daniel Lezcano
> CC: Thomas Gleixner
> Originally-by: Amit Daniel Kachhap
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Tested-by: Robert Richter
> Acked-by: Robert Richter
> Signed-off-by: Hanjun Guo
Reviewed-by: Grant Likely
> ---
> arch/arm64/kernel/time.c | 7 ++
> drivers/clocksource/arm_arch_timer.c | 132
> ---
> include/linux/clocksource.h | 6 ++
> 3 files changed, 118 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index 1a7125c..42f9195 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -72,6 +73,12 @@ void __init time_init(void)
>
> tick_setup_hrtimer_broadcast();
>
> + /*
> + * Since ACPI or FDT will only one be available in the system,
> + * we can use acpi_generic_timer_init() here safely
> + */
> + acpi_generic_timer_init();
> +
> arch_timer_rate = arch_timer_get_rate();
> if (!arch_timer_rate)
> panic("Unable to initialise architected timer.\n");
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index a3025e7..ea62fc7 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -371,8 +372,12 @@ arch_timer_detect_rate(void __iomem *cntbase, struct
> device_node *np)
> if (arch_timer_rate)
> return;
>
> - /* Try to determine the frequency from the device tree or CNTFRQ */
> - if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
> + /*
> + * Try to determine the frequency from the device tree or CNTFRQ,
> + * if ACPI is enabled, get the frequency from CNTFRQ ONLY.
> + */
> + if (!acpi_disabled ||
> + of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
> if (cntbase)
> arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
> else
> @@ -691,28 +696,8 @@ static void __init arch_timer_common_init(void)
> arch_timer_arch_init();
> }
>
> -static void __init arch_timer_init(struct device_node *np)
> +static void __init arch_timer_init(void)
> {
> - int i;
> -
> - if (arch_timers_present & ARCH_CP15_TIMER) {
> - pr_warn("arch_timer: multiple nodes in dt, skipping\n");
> - return;
> - }
> -
> - arch_timers_present |= ARCH_CP15_TIMER;
> - for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
> - arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
> - arch_timer_detect_rate(NULL, np);
> -
> - /*
> - * If we cannot rely on firmware initializing the timer registers then
> - * we should use the physical timers instead.
> - */
> - if (IS_ENABLED(CONFIG_ARM) &&
> - of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
> - arch_timer_use_virtual = false;
> -
> /*
>* If HYP mode is available, we know that the physical timer
>* has been configured to be accessible from PL1. Use it, so
> @@ -731,13 +716,39 @@ static void __init arch_timer_init(struct device_node
> *np)
> }
> }
>
> - arch_timer_c3stop = !of_property_read_bool(np, "always-on");
> -
> arch_timer_register();
> arch_timer_common_init();
> }
> -CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
> -CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
> +
> +static void __init arch_timer_of_init(struct device_node *np)
> +{
> + int i;
> +
> + if (arch_timers_present & ARCH_CP15_TIMER) {
> + pr_warn("arch_timer: multiple nodes in dt, skipping\n");
> + return;
> + }
> +
> + arch_timers_present |= ARCH_CP15_TIMER;
> + for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
> + arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
> +
> + arch_timer_detect_rate(NULL, np);
> +
> + arch_timer_c3stop = !of_property_read_bool(np, "always-on");
> +
> + /*
> + * If we cannot rely on firmware initializing the timer registers then
> + * we should use the physical timers instead.
> + */
> + if (IS_ENABLED(CONFIG_ARM) &&
> + of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
> + arch_timer_use_virtual = false;
> +
> + arch_timer_init();
> +}
> +CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer",
> a
Re: [PATCH v9 16/21] irqchip: Add GICv2 specific ACPI boot support
On Wed, 25 Feb 2015 16:39:56 +0800
, Hanjun Guo
wrote:
> From: Tomasz Nowicki
>
> ACPI kernel uses MADT table for proper GIC initialization. It needs to
> parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>
> NOTE: This commit allow to initialize GICv1/2 basic functionality.
> While now simple GICv2 init call is used, any further GIC features
> require generic infrastructure for proper ACPI irqchip initialization.
> That mechanism and stacked irqdomains to support GICv2 MSI/virtualization
> extension, GICv3/4 and its ITS are considered as next steps.
>
> CC: Jason Cooper
> CC: Marc Zyngier
> CC: Thomas Gleixner
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Tested-by: Robert Richter
> Acked-by: Robert Richter
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Hanjun Guo
Reviewed-by: Grant Likely
> ---
> arch/arm64/include/asm/acpi.h| 2 +
> arch/arm64/kernel/acpi.c | 25 +
> drivers/irqchip/irq-gic.c| 102
> +++
> drivers/irqchip/irqchip.c| 3 ++
> include/linux/acpi.h | 14 +
> include/linux/irqchip/arm-gic-acpi.h | 29 ++
> 6 files changed, 175 insertions(+)
> create mode 100644 include/linux/irqchip/arm-gic-acpi.h
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 9a23369..a720a61 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -13,6 +13,8 @@
> #define _ASM_ACPI_H
>
> #include
> +#include
> +
> #include
> #include
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 31f080e..af308c3 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -359,3 +359,28 @@ void __init acpi_boot_table_init(void)
> pr_err("Can't find FADT\n");
> }
> }
> +
> +void __init acpi_gic_init(void)
> +{
> + struct acpi_table_header *table;
> + acpi_status status;
> + acpi_size tbl_size;
> + int err;
> +
> + if (acpi_disabled)
> + return;
> +
> + status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
> + if (ACPI_FAILURE(status)) {
> + const char *msg = acpi_format_exception(status);
> +
> + pr_err("Failed to get MADT table, %s\n", msg);
> + return;
> + }
> +
> + err = gic_v2_acpi_init(table);
> + if (err)
> + pr_err("Failed to initialize GIC IRQ controller");
> +
> + early_acpi_os_unmap_memory((char *)table, tbl_size);
> +}
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 4634cf7..929d668 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -33,12 +33,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1086,3 +1088,103 @@ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic",
> gic_of_init);
> IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
>
> #endif
> +
> +#ifdef CONFIG_ACPI
> +static phys_addr_t dist_phy_base, cpu_phy_base __initdata;
> +
> +static int __init
> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_interrupt *processor;
> + phys_addr_t gic_cpu_base;
> + static int cpu_base_assigned;
> +
> + processor = (struct acpi_madt_generic_interrupt *)header;
> +
> + if (BAD_MADT_ENTRY(processor, end))
> + return -EINVAL;
> +
> + /*
> + * There is no support for non-banked GICv1/2 register in ACPI spec.
> + * All CPU interface addresses have to be the same.
> + */
> + gic_cpu_base = processor->base_address;
> + if (cpu_base_assigned && gic_cpu_base != cpu_phy_base)
> + return -EINVAL;
> +
> + cpu_phy_base = gic_cpu_base;
> + cpu_base_assigned = 1;
> + return 0;
> +}
> +
> +static int __init
> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_distributor *dist;
> +
> + dist = (struct acpi_madt_generic_distributor *)header;
> +
> + if (BAD_MADT_ENTRY(dist, end))
> + return -EINVAL;
> +
> + dist_phy_base = dist->base_address;
> + return 0;
> +}
> +
> +int __init
> +gic_v2_acpi_init(struct acpi_table_header *table)
> +{
> + void __iomem *cpu_base, *dist_base;
> + int count;
> +
> + /* Collect CPU base addresses */
> + count = acpi_parse_entries(ACPI_SIG_MADT,
> +sizeof(struct acpi_table_madt),
> +
Re: [ANNOUNCE] 3.18.9-rt4
On Sat, Mar 07, 2015 at 12:25:29PM -0300, Gustavo Bittencourt wrote: > On Sat, Mar 7, 2015 at 11:15 AM, Sebastian Andrzej Siewior > wrote: > > > > I'm pleased to announce the v3.18.9-rt4 patch set. > > > > Changes since v3.18.9-rt3 > > > > Has v3.18.9-rt3 been released? If so, I missed the announcement. Probably v3.18.9-rt3 is just v3.18.7-rt2 rebased to v3.18.9. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: i2c: add support for omnivision's ov2659 sensor
On Sat, 2015-03-07 at 15:21 +, Lad Prabhakar wrote:
> --- /dev/null
> +++ b/drivers/media/i2c/ov2659.c
> @@ -0,0 +1,1495 @@
> +/*
> + * Omnivision OV2659 CMOS Image Sensor driver
> + *
> + * Copyright (C) 2015 Texas Instruments, Inc.
> + *
> + * Benoit Parrot
> + * Lad, Prabhakar
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
This states the license of this modules is GPL v2.
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
(If you think this is a bit silly, and somewhere I think so too, you're
invited to jump into the discussion starting at
https://lkml.org/lkml/2015/3/7/119 .)
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Wed, 25 Feb 2015 16:39:55 +0800
, Hanjun Guo
wrote:
> Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
> used, and then register device's gsi with the core IRQ subsystem.
>
> acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
> since gsi is unique in the system, so use hwirq number directly
> for the mapping.
>
> We are going to implement stacked domains when GICv2m, GICv3, ITS
> support are added.
>
> CC: Marc Zyngier
> Originally-by: Amit Daniel Kachhap
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Tested-by: Robert Richter
> Acked-by: Robert Richter
> Signed-off-by: Hanjun Guo
Reviewed-by: Grant Likely
> ---
> arch/arm64/kernel/acpi.c | 73
>
> drivers/acpi/bus.c | 3 ++
> include/linux/acpi.h | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 0f35d87..31f080e 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -76,6 +76,12 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
> }
>
> /*
> + * Since we're on ARM, the default interrupt routing model
> + * clearly has to be GIC.
> + */
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
> +
> +/*
> * __acpi_map_table() will be called before page_init(), so early_ioremap()
> * or early_memremap() should be called here to for ACPI table mapping.
> */
> @@ -218,6 +224,73 @@ void __init acpi_init_cpus(void)
> pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> }
>
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> + *irq = irq_find_mapping(NULL, gsi);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>0)
> + * failure: return =< 0
> + */
> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +{
> + unsigned int irq;
> + unsigned int irq_type;
> +
> + /*
> + * ACPI have no bindings to indicate SPI or PPI, so we
> + * use different mappings from DT in ACPI.
> + *
> + * For FDT
> + * PPI interrupt: in the range [0, 15];
> + * SPI interrupt: in the range [0, 987];
> + *
> + * For ACPI, GSI should be unique so using
> + * the hwirq directly for the mapping:
> + * PPI interrupt: in the range [16, 31];
> + * SPI interrupt: in the range [32, 1019];
> + */
> +
> + if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_EDGE_FALLING;
> + else if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_EDGE_RISING;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_LEVEL_LOW;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_LEVEL_HIGH;
> + else
> + irq_type = IRQ_TYPE_NONE;
> +
> + /*
> + * Since only one GIC is supported in ACPI 5.0, we can
> + * create mapping refer to the default domain
> + */
> + irq = irq_create_mapping(NULL, gsi);
> + if (!irq)
> + return irq;
> +
> + /* Set irq type if specified and different than the current one */
> + if (irq_type != IRQ_TYPE_NONE &&
> + irq_type != irq_get_trigger_type(irq))
> + irq_set_irq_type(irq, irq_type);
> + return irq;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> +
> static int __init acpi_parse_fadt(struct acpi_table_header *table)
> {
> struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 8b67bd0..c412fdb 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -448,6 +448,9 @@ static int __init acpi_bus_init_irq(void)
> case ACPI_IRQ_MODEL_IOSAPIC:
> message = "IOSAPIC";
> break;
> + case ACPI_IRQ_MODEL_GIC:
> + message = "GIC";
> + break;
> case ACPI_IRQ_MODEL_PLATFORM:
> message = "platform specific model";
> break;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 0eabd15..c03d8d1 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -73,6 +73,7 @@ enum acpi_irq_model_id {
> ACPI_IRQ_MODEL_IOAPIC,
> ACPI_IRQ_MODEL_IOSAPIC,
> ACPI_IRQ_MODEL_PLATFORM,
> + ACPI_IRQ_MODEL_GIC,
> ACPI_IRQ_MODEL_COUNT
> };
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Re: [PATCH v9 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC
On Wed, 25 Feb 2015 16:39:54 +0800
, Hanjun Guo
wrote:
> Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
> from the GICC Structure introduced by ACPI 5.1.
>
> The ARM architecture defines the MPIDR register as the CPU hardware
> identifier. This patch adds the code infrastructure to retrieve the MPIDR
> values from the ARM ACPI GICC structure in order to look-up the kernel CPU
> hardware ids required by the ACPI core code to identify CPUs.
>
> CC: Rafael J. Wysocki
> CC: Catalin Marinas
> CC: Will Deacon
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Tested-by: Robert Richter
> Acked-by: Robert Richter
> Signed-off-by: Hanjun Guo
Reviewed-by: Grant Likely
> ---
> arch/arm64/include/asm/acpi.h | 12
> drivers/acpi/processor_core.c | 30 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 9719921..9a23369 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -13,6 +13,8 @@
> #define _ASM_ACPI_H
>
> #include
> +#include
> +#include
>
> /* Basic configuration for ACPI */
> #ifdef CONFIG_ACPI
> @@ -27,6 +29,9 @@ static inline void __iomem
> *acpi_os_ioremap(acpi_physical_address phys,
> }
> #define acpi_os_ioremap acpi_os_ioremap
>
> +typedef u64 phys_cpuid_t;
> +#define CPU_PHYS_ID_INVALID INVALID_HWID
> +
> #define acpi_strict 1/* No out-of-spec workarounds on ARM64 */
> extern int acpi_disabled;
> extern int acpi_noirq;
> @@ -59,6 +64,13 @@ static inline void enable_acpi(void)
> }
>
> /*
> + * The ACPI processor driver for ACPI core code needs this macro
> + * to find out this cpu was already mapped (mapping from CPU hardware
> + * ID to CPU logical ID) or not.
> + */
> +#define cpu_physical_id(cpu) cpu_logical_map(cpu)
> +
> +/*
> * It's used from ACPI core in kdump to boot UP system with SMP kernel,
> * with this check the ACPI core will not override the CPU index
> * obtained from GICC with 0 and not print some error message as well.
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index a5547dc..8654adb 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -83,6 +83,31 @@ static int map_lsapic_id(struct acpi_subtable_header
> *entry,
> return 0;
> }
>
> +/*
> + * Retrieve the ARM CPU physical identifier (MPIDR)
> + */
> +static int map_gicc_mpidr(struct acpi_subtable_header *entry,
> + int device_declaration, u32 acpi_id, phys_cpuid_t *mpidr)
> +{
> + struct acpi_madt_generic_interrupt *gicc =
> + container_of(entry, struct acpi_madt_generic_interrupt, header);
> +
> + if (!(gicc->flags & ACPI_MADT_ENABLED))
> + return -ENODEV;
> +
> + /* device_declaration means Device object in DSDT, In the
> + * GIC interrupt model, logical processors are required to
> + * have a Processor Device object in the DSDT, so we should
> + * check device_declaration here
> + */
> + if (device_declaration && (gicc->uid == acpi_id)) {
> + *mpidr = gicc->arm_mpidr;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> @@ -111,6 +136,9 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> } else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
> if (!map_lsapic_id(header, type, acpi_id, &phys_id))
> break;
> + } else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
> + if (!map_gicc_mpidr(header, type, acpi_id, &phys_id))
> + break;
> }
> entry += header->length;
> }
> @@ -143,6 +171,8 @@ static phys_cpuid_t map_mat_entry(acpi_handle handle, int
> type, u32 acpi_id)
> map_lsapic_id(header, type, acpi_id, &phys_id);
> else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC)
> map_x2apic_id(header, type, acpi_id, &phys_id);
> + else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT)
> + map_gicc_mpidr(header, type, acpi_id, &phys_id);
>
> exit:
> kfree(buffer.pointer);
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] irqchip: Core changes for v4.0
Thomas, Here's a small round of changes for the next merge window. Please pull. thx, Jason. The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.infradead.org/users/jcooper/linux.git tags/irqchip-core-4.0 for you to fetch changes up to c9558659e68ee30740f265c54f792bf75add21f2: Merge branch 'irqchip/st' into irqchip/core (2015-03-07 21:56:47 +) irqchip core changes for v4.0 - STi - New driver, irq-st - Renesas - Use u32 type for 32bit regs Geert Uytterhoeven (1): irqchip: renesas-irqc: Use u32 to store 32-bit register values Jason Cooper (1): Merge branch 'irqchip/st' into irqchip/core Lee Jones (3): dt: bindings: Supply shared ST IRQ defines irqchip: st: Supply new driver for STi based devices irqchip: st: Add documentation for STi based syscfg IRQs .../interrupt-controller/st,sti-irq-syscfg.txt | 35 drivers/irqchip/Kconfig| 7 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-renesas-irqc.c | 4 +- drivers/irqchip/irq-st.c | 206 + include/dt-bindings/interrupt-controller/irq-st.h | 30 +++ 6 files changed, 281 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt create mode 100644 drivers/irqchip/irq-st.c create mode 100644 include/dt-bindings/interrupt-controller/irq-st.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 v9 13/21] ARM64 / ACPI: Parse MADT for SMP initialization
On Wed, 25 Feb 2015 16:39:53 +0800
, Hanjun Guo
wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map.
>
> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
> Parking protocol, but the Parking protocol is only specified for
> ARMv7 now, so make PSCI as the only way for the SMP boot protocol
> before some updates for the ACPI spec or the Parking protocol spec.
>
> Parking protocol patches for SMP boot will be sent to upstream when
> the new version of Parking protocol is ready.
>
> CC: Lorenzo Pieralisi
> CC: Catalin Marinas
> CC: Will Deacon
> CC: Mark Rutland
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Tested-by: Robert Richter
> Acked-by: Robert Richter
> Signed-off-by: Hanjun Guo
> Signed-off-by: Tomasz Nowicki
Reviewed-by: Grant Likely
> ---
> arch/arm64/include/asm/acpi.h| 2 +
> arch/arm64/include/asm/cpu_ops.h | 1 +
> arch/arm64/include/asm/smp.h | 5 +-
> arch/arm64/kernel/acpi.c | 149
> ++-
> arch/arm64/kernel/cpu_ops.c | 2 +-
> arch/arm64/kernel/setup.c| 7 +-
> arch/arm64/kernel/smp.c | 2 +-
> 7 files changed, 160 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 9ea650c..9719921 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -71,10 +71,12 @@ static inline bool acpi_has_cpu_in_madt(void)
> }
>
> static inline void arch_fix_phys_package_id(int num, u32 slot) { }
> +void __init acpi_init_cpus(void);
>
> #else
> static inline bool acpi_psci_present(void) { return false; }
> static inline bool acpi_psci_use_hvc(void) { return false; }
> +static inline void acpi_init_cpus(void) { }
> #endif /* CONFIG_ACPI */
>
> #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu_ops.h
> b/arch/arm64/include/asm/cpu_ops.h
> index da301ee..5a31d67 100644
> --- a/arch/arm64/include/asm/cpu_ops.h
> +++ b/arch/arm64/include/asm/cpu_ops.h
> @@ -66,5 +66,6 @@ struct cpu_operations {
> extern const struct cpu_operations *cpu_ops[NR_CPUS];
> int __init cpu_read_ops(struct device_node *dn, int cpu);
> void __init cpu_read_bootcpu_ops(void);
> +const struct cpu_operations *cpu_get_ops(const char *name);
>
> #endif /* ifndef __ASM_CPU_OPS_H */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index 780f82c..bf22650 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -39,9 +39,10 @@ extern void show_ipi_list(struct seq_file *p, int prec);
> extern void handle_IPI(int ipinr, struct pt_regs *regs);
>
> /*
> - * Setup the set of possible CPUs (via set_cpu_possible)
> + * Discover the set of possible CPUs and determine their
> + * SMP operations.
> */
> -extern void smp_init_cpus(void);
> +extern void of_smp_init_cpus(void);
>
> /*
> * Provide a function to raise an IPI cross call on CPUs in callmap.
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index bdcc9fc..0f35d87 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -25,6 +25,10 @@
> #include
> #include
>
> +#include
> +#include
> +#include
> +
> int acpi_noirq = 1; /* skip ACPI IRQ initialization */
> int acpi_disabled = 1;
> EXPORT_SYMBOL(acpi_disabled);
> @@ -32,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
> int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */
> EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* Processors with enabled flag and sane MPIDR */
> +static int enabled_cpus;
> +
> +/* Boot CPU is valid or not in MADT */
> +static bool __initdata bootcpu_valid;
> +
> static bool __initdata param_acpi_off;
> static bool __initdata param_acpi_force;
>
> @@ -85,6 +95,129 @@ void __init __acpi_unmap_table(char *map, unsigned long
> size)
> early_memunmap(map, size);
> }
>
> +/**
> + * acpi_map_gic_cpu_interface - generates a logical cpu number
> + * and map to MPIDR represented by GICC structure
> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logical cpu number which maps to MPIDR
> + */
> +static int __init acpi_map_gic_cpu_interface(u64 mpidr, u8 enabled)
> +{
> + int i;
> +
> + if (mpidr == INVALID_HWID) {
> + pr_info("Skip MADT cpu entry with invalid MPIDR\n");
> + return -EINVAL;
> + }
> +
> + total_cpus++;
> + if (!enabled)
> + return -EINVAL;
> +
> + if (enabled_cpus >= NR_CPUS) {
> + pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx
> ignored.\n",
> + NR_
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, 2015-03-07 at 14:26 -0800, Dmitry Torokhov wrote: > On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote: > I was talking about them being treated differently from technological > standpoint (i.e. the code), not from legal one. >From a technological standpoint it would be easy to declare "GPL" (or any other string) to mean "GPL v2 compatible", which is, I think, all that matters. But license_is_gpl_compatible() doesn't do that. And I fear that's for a reason. Is my fear unfounded? > If you want to fix up input drivers I'll take such patch, but I am > sure more such cases will sneak in unless you also make sure that > there are tools (such as checkpatch.pl) that can alert developers to >the inconsistency. checkpatch.pl crossed my mind too. But in just over a week of checking the license comments of (a subset of) the submitted patches I've come to think that just won't work. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote: >On Sat, 2015-03-07 at 14:02 -0800, Dmitry Torokhov wrote: >> On March 7, 2015 1:54:41 PM PST, Paul Bolle >wrote: >> >By that logic we might as well simplify the logic of >> >license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why >check >> >for six variants instead of just one and be done with it? >> >> Because nobody wants to go through hundreds of drivers and change >them? > >Not fun, but surely doable. > >> >Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So, >> >unless a patch is applied to treat them interchangeably, somehow, in >> >the module license checking code, >> >> They are treated interchangeably as far as I can see. Where do you >see >> "GPL" is being treated differently than "GPL v2". > >I'm not going to explain here why "GPL v2" or "GPL v2 or later" differ. I was talking about them being treated differently from technological standpoint (i.e. the code), not from legal one. > >"GPL" is documented to mean "GPL v2 or later". "GPL v2" is documented >to >mean just that (see include/linux/module.h). Again, you're free to >submit a patch to somehow simplify that. But unless a patch like that >is >applied, we should make sure MODULE_LICENSE() matches the actual >license >of the module involved. If you want to fix up input drivers I'll take such patch, but I am sure more such cases will sneak in unless you also make sure that there are tools (such as checkpatch.pl) that can alert developers to the inconsistency. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0 01/11] stm class: Introduce an abstraction for System Trace Module devices
On Sat, 2015-03-07 at 13:35 +0200, Alexander Shishkin wrote: > Documentation/ABI/testing/configfs-stp-policy| 44 ++ git am whined about this file when I tried to apply this patch: Applying: stm class: Introduce an abstraction for System Trace Module devices [...]/.git/rebase-apply/patch:77: new blank line at EOF. > Documentation/ABI/testing/sysfs-class-stm| 14 + > Documentation/ABI/testing/sysfs-class-stm_source | 11 + > Documentation/trace/stm.txt | 77 +++ > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/stm/Kconfig | 8 + > drivers/stm/Makefile | 3 + > drivers/stm/core.c | 839 > +++ > drivers/stm/policy.c | 470 + > drivers/stm/stm.h| 77 +++ > include/linux/stm.h | 87 +++ > include/uapi/linux/stm.h | 47 ++ > --- /dev/null > +++ b/drivers/stm/Kconfig > @@ -0,0 +1,8 @@ > +config STM > + tristate "System Trace Module devices" > + help > + A System Trace Module (STM) is a device exporting data in System > + Trace Protocol (STP) format as defined by MIPI STP standards. > + Examples of such devices are Intel Trace Hub and Coresight STM. > + > + Say Y here to enable System Trace Module device support. > diff --git a/drivers/stm/Makefile b/drivers/stm/Makefile > new file mode 100644 > index 00..adec701649 > --- /dev/null > +++ b/drivers/stm/Makefile > @@ -0,0 +1,3 @@ > +obj-$(CONFIG_STM)+= stm_core.o > + > +stm_core-y := core.o policy.o I tried to compile this as a module: $ make -C ../.. M=$PWD CONFIG_STM=m stm_core.ko make: Entering directory `[...]' LD [M] [...]/drivers/stm/stm_core.o [...]/drivers/stm/policy.o: In function `stp_configfs_init': policy.c:(.text+0x5f0): multiple definition of `init_module' [...]/drivers/stm/core.o:core.c:(.init.text+0x0): first defined here make[1]: *** [[...]/drivers/stm/stm_core.o] Error 1 make: *** [stm_core.ko] Error 2 make: Leaving directory `[...]' I think that's because postcore_initcall(stm_core_init); in core.c becomes module_init(stm_core_init); if this driver is compiled as a module. And that will clash with module_init(stp_configfs_init); in policy.c. Am I missing something obvious or should STM not be a tristate symbol? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Re: issues on last 32 bit m68k toolchain
On Fri, Feb 06, 2015 at 09:46:52PM +0100, Angelo Dureghello wrote: Dear all, i was using the public x86 32bit toolchain from kernel.org: https://www.kernel.org/pub/tools/crosstool/files/bin/i686/4.6.3/i686-gcc-4.6.3-nolibc_m68k-linux.tar.gz Unfortunately, for ColdFire arch, there is a bug in gas/binutils for this toolchain: https://sourceware.org/bugzilla/show_bug.cgi?id=17877 Produced binaries are not working on the target. Is it possible to have available another m68k toolchain (including older or newer binutils/as than the bugged 2.22) ? Can you try the 64 bit toolchain ? https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_m68k-linux.tar.gz Guenter Tested: that toolchain have the same issues related to mcf5307. So the issue should have been fixed only after v2.24 of binutils. So none of the 2 toolchains for coldfire works for me. Regards Angelo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
On 7 March 2015 at 02:18, Brian Norris wrote:
> +static int brcmnand_waitfunc(struct mtd_info *mtd, struct nand_chip *this)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct brcmnand_host *host = chip->priv;
> + struct brcmnand_controller *ctrl = host->ctrl;
> + unsigned long timeo = msecs_to_jiffies(100);
> +
> + dev_dbg(ctrl->dev, "wait on native cmd %d\n", ctrl->cmd_pending);
> + if (ctrl->cmd_pending &&
> + wait_for_completion_timeout(&ctrl->done, timeo) <= 0)
> {
> + unsigned long cmd = brcmnand_read_reg(ctrl,
> BRCMNAND_CMD_START)
> + >> brcmnand_cmd_shift(ctrl);
> +
> + dev_err_ratelimited(ctrl->dev,
> + "timeout waiting for command %u (%ld)\n",
> + host->last_cmd, cmd);
I think that using host->last_cmd in the above message is really
misleading. Please consider following:
[2.061139] [brcmnand_cmdfunc:1151] command:0x90 native_cmd:0x07
[2.067123] brcmstb_nand 18028000.nand: send native cmd 7 addr_lo 0x40
[2.168395] brcmstb_nand 18028000.nand: timeout waiting for command 144 (7)
[2.175321] brcmstb_nand 18028000.nand: intfc status f000
[2.181051] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1
[2.187370] nand: Eon NAND 128MiB 3,3V 8-bit
[2.191632] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[2.199192] brcmstb_nand 18028000.nand: detected 128MiB total,
128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-8
[2.199192]
[2.210724] Scanning device for bad blocks
[2.214812] brcmstb_nand 18028000.nand: send native cmd 1 addr_lo 0x0
[2.318394] brcmstb_nand 18028000.nand: timeout waiting for command 144 (1)
As you can see, first there was a brcmnand_cmdfunc call with 0x90
(NAND_CMD_READID). It was translated into internal command 0x07
(CMD_DEVICE_ID_READ).
Then there was a call to brcmnand_read_by_pio which resulted in
sending internal command 0x01 (CMD_PAGE_READ). This one overwrote
previous command. So the timeout wasn't about 144 (0x90) anymore.
I suggest replacing that with something like
"timeout waiting for internal command 0x%02x\n", cmd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: support for GPIO forwarding
On Wed, Feb 25, 2015 at 7:25 PM, David Cohen wrote: > In my case [1] I need 2 "virtual devices" (and more in future) to be > part of an USB OTG port control. I call it virtual because they are too > simple components connected to no bus and controlled by GPIOs: > - a fixed regulator controlled by GPIO > - a generic mux controlled by GPIO > > I'd need to request official ACPI HID for them in order to make them > self-sufficient. > > I can go ahead with this approach, but we have many examples of drivers > on upstream that are platform driver expecting to receive gpio via > platform data (e.g. extcon-gpio). The ACPI table of some products on > market were defined following this concept and won't change anymore. So it's not just going to be GPIOs I take it? There is going to be regulator forwarding, clock forwarding, pin control forwarding, IRQ forwarding and DMA channel forwarding etc at the end of the day? I think it's strange that we see this so much, is the real problem that ACPI and the kernel have different ideas of what constitutes a device? And how come the DT seems to be a much better fit and not experience this? Because we haven't had to deal with deployed device trees with resources (GPIOs, regulators, etc) bound to some complex MFD device? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, 2015-03-07 at 14:02 -0800, Dmitry Torokhov wrote: > On March 7, 2015 1:54:41 PM PST, Paul Bolle wrote: > >By that logic we might as well simplify the logic of > >license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check > >for six variants instead of just one and be done with it? > > Because nobody wants to go through hundreds of drivers and change them? Not fun, but surely doable. > >Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So, > >unless a patch is applied to treat them interchangeably, somehow, in > >the module license checking code, > > They are treated interchangeably as far as I can see. Where do you see > "GPL" is being treated differently than "GPL v2". I'm not going to explain here why "GPL v2" or "GPL v2 or later" differ. "GPL" is documented to mean "GPL v2 or later". "GPL v2" is documented to mean just that (see include/linux/module.h). Again, you're free to submit a patch to somehow simplify that. But unless a patch like that is applied, we should make sure MODULE_LICENSE() matches the actual license of the module involved. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fix compat msgrcv with negative msgtyp for LTS kernel 3.10
A patch referenced in: https://lkml.org/lkml/2014/1/15/253 is in mainline (3.19 kernel). However this patch is not in longterm (3.10 kernel). There is a bug report related to this issue in: https://bugzilla.kernel.org/show_bug.cgi?id=94181 by a user that is running a 3.10.x kernel. It would be great if the patch is included in the 3.10 line. Thank you, Akemi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data
Boris found data from boot stage can not be used kernel stage.
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that decompressor would not have output
overwrite input data before input data get consumed.
After decompressor is called, VO (vmlinux) use whole buffer from start,
and ZO code and data section is overlapped with VO bss section.
And later VO/clear_bss() clear them before code in arch/x86/kernel/setup.c
access them.
We need to avoid overlapping to keep ZO data.
In previous patch, We already move ZO close the end of buffer instead of
middle of buffer. But there is overlapping beween VO brk with ZO data area.
Extend init_size so VO bss and brk will not overlap with data ZO data area
(most from boot/compressed/misc.c).
The increase is from _rodata to _end in ZO (arch/x86/boot/compressed/vmlinux).
-v2: add init_size in arch/x86/boot/header.S instead of BRK.
-v3: split code that move ZO to end of buffer to another patch.
Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
Cc: "H. Peter Anvin"
Cc: Matt Fleming
Cc: Kees Cook
Signed-off-by: Yinghai Lu
---
arch/x86/boot/Makefile | 2 +-
arch/x86/boot/compressed/vmlinux.lds.S | 1 +
arch/x86/boot/header.S | 7 +--
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 57bbf2f..863ef25 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -86,7 +86,7 @@ targets += voffset.h
$(obj)/voffset.h: vmlinux FORCE
$(call if_changed,voffset)
-sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW]
\(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|z_.*\)$$/\#define
ZO_\2 0x\1/p'
+sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW]
\(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_rodata\|z_.*\)$$/\#define
ZO_\2 0x\1/p'
quiet_cmd_zoffset = ZOFFSET $@
cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@
diff --git a/arch/x86/boot/compressed/vmlinux.lds.S
b/arch/x86/boot/compressed/vmlinux.lds.S
index e24e0a0..6d6158e 100644
--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -35,6 +35,7 @@ SECTIONS
*(.text.*)
_etext = . ;
}
+. = ALIGN(PAGE_SIZE); /* keep ADDON_ZO_SIZE page aligned */
.rodata : {
_rodata = . ;
*(.rodata) /* read-only data */
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9bfab22..bc5d78d 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -440,12 +440,15 @@ setup_data: .quad 0 #
64-bit physical pointer to
pref_address: .quad LOAD_PHYSICAL_ADDR# preferred load addr
+# don't overlap data area of ZO with VO
+#define ADDON_ZO_SIZE (ZO__end - ZO__rodata)
+
#define ZO_INIT_SIZE (ZO__end - ZO_startup_32 + ZO_z_min_extract_offset)
#define VO_INIT_SIZE (VO__end - VO__text)
#if ZO_INIT_SIZE > VO_INIT_SIZE
-#define INIT_SIZE ZO_INIT_SIZE
+#define INIT_SIZE (ZO_INIT_SIZE + ADDON_ZO_SIZE)
#else
-#define INIT_SIZE VO_INIT_SIZE
+#define INIT_SIZE (VO_INIT_SIZE + ADDON_ZO_SIZE)
#endif
init_size: .long INIT_SIZE # kernel initialization size
handover_offset: .long 0 # Filled in by build.c
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/7] x86, boot: Split kernel_ident_mapping_init to another file
We need to include that in boot::decompress_kernel stage to set new
ident mapping.
Also add checking for __pa/__va macro definition, as we need to override them
in boot::decompress_kernel stage.
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/page.h | 5 +++
arch/x86/mm/ident_map.c | 74 +
arch/x86/mm/init_64.c | 74 +
3 files changed, 80 insertions(+), 73 deletions(-)
create mode 100644 arch/x86/mm/ident_map.c
diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index 802dde3..cf8f619 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -37,7 +37,10 @@ static inline void copy_user_page(void *to, void *from,
unsigned long vaddr,
alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
+#ifndef __pa
#define __pa(x)__phys_addr((unsigned long)(x))
+#endif
+
#define __pa_nodebug(x)__phys_addr_nodebug((unsigned long)(x))
/* __pa_symbol should be used for C visible symbols.
This seems to be the official gcc blessed way to do such arithmetic. */
@@ -51,7 +54,9 @@ static inline void copy_user_page(void *to, void *from,
unsigned long vaddr,
#define __pa_symbol(x) \
__phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))
+#ifndef __va
#define __va(x)((void *)((unsigned
long)(x)+PAGE_OFFSET))
+#endif
#define __boot_va(x) __va(x)
#define __boot_pa(x) __pa(x)
diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
new file mode 100644
index 000..751ca92
--- /dev/null
+++ b/arch/x86/mm/ident_map.c
@@ -0,0 +1,74 @@
+
+static void ident_pmd_init(unsigned long pmd_flag, pmd_t *pmd_page,
+ unsigned long addr, unsigned long end)
+{
+ addr &= PMD_MASK;
+ for (; addr < end; addr += PMD_SIZE) {
+ pmd_t *pmd = pmd_page + pmd_index(addr);
+
+ if (!pmd_present(*pmd))
+ set_pmd(pmd, __pmd(addr | pmd_flag));
+ }
+}
+static int ident_pud_init(struct x86_mapping_info *info, pud_t *pud_page,
+ unsigned long addr, unsigned long end)
+{
+ unsigned long next;
+
+ for (; addr < end; addr = next) {
+ pud_t *pud = pud_page + pud_index(addr);
+ pmd_t *pmd;
+
+ next = (addr & PUD_MASK) + PUD_SIZE;
+ if (next > end)
+ next = end;
+
+ if (pud_present(*pud)) {
+ pmd = pmd_offset(pud, 0);
+ ident_pmd_init(info->pmd_flag, pmd, addr, next);
+ continue;
+ }
+ pmd = (pmd_t *)info->alloc_pgt_page(info->context);
+ if (!pmd)
+ return -ENOMEM;
+ ident_pmd_init(info->pmd_flag, pmd, addr, next);
+ set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
+ }
+
+ return 0;
+}
+
+int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page,
+ unsigned long addr, unsigned long end)
+{
+ unsigned long next;
+ int result;
+ int off = info->kernel_mapping ? pgd_index(__PAGE_OFFSET) : 0;
+
+ for (; addr < end; addr = next) {
+ pgd_t *pgd = pgd_page + pgd_index(addr) + off;
+ pud_t *pud;
+
+ next = (addr & PGDIR_MASK) + PGDIR_SIZE;
+ if (next > end)
+ next = end;
+
+ if (pgd_present(*pgd)) {
+ pud = pud_offset(pgd, 0);
+ result = ident_pud_init(info, pud, addr, next);
+ if (result)
+ return result;
+ continue;
+ }
+
+ pud = (pud_t *)info->alloc_pgt_page(info->context);
+ if (!pud)
+ return -ENOMEM;
+ result = ident_pud_init(info, pud, addr, next);
+ if (result)
+ return result;
+ set_pgd(pgd, __pgd(__pa(pud) | _KERNPG_TABLE));
+ }
+
+ return 0;
+}
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 30eb05a..c30efb6 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -56,79 +56,7 @@
#include "mm_internal.h"
-static void ident_pmd_init(unsigned long pmd_flag, pmd_t *pmd_page,
- unsigned long addr, unsigned long end)
-{
- addr &= PMD_MASK;
- for (; addr < end; addr += PMD_SIZE) {
- pmd_t *pmd = pmd_page + pmd_index(addr);
-
- if (!pmd_present(*pmd))
- set_pmd(pmd, __pmd(addr | pmd_flag));
- }
-}
-static int ident_pud_init(struct x86_mapping_info *info, pud_t *pud_page,
- unsigned long addr, unsigned long end)
-{
-
[PATCH v3 4/7] x86, kaslr: Access the correct kaslr_enabled variable
Commit
f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
started passing KASLR status to kernel proper, but it uses a physical
address as the vaule, leading to parsing bogus KASLR status in kernel
proper.
The setup_data linked list and thus the element which contains
kaslr_enabled is chained together using physical addresses. At the time
when we access it in the kernel proper, we're already running with
paging enabled and therefore must access it through its virtual address.
This patch changes the code to use early_memmap() and access the value.
-v3: add checking return from early_memmap according to Boris.
-v4: add description about setup_data accessing from Boris to change log.
Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
Cc: Matt Fleming
Cc: Borislav Petkov
Cc: Kees Cook
Cc: Jiri Kosina
Acked-by: Jiri Kosina
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/setup.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 98dc931..912f124 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -429,7 +429,18 @@ static void __init reserve_initrd(void)
static void __init parse_kaslr_setup(u64 pa_data, u32 data_len)
{
- kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
+ /* kaslr_setup_data is defined in aslr.c */
+ unsigned char *data;
+ unsigned long offset = sizeof(struct setup_data);
+
+ data = early_memremap(pa_data, offset + 1);
+ if (!data) {
+ kaslr_enabled = true;
+ return;
+ }
+
+ kaslr_enabled = *(data + offset);
+ early_memunmap(data, offset + 1);
}
static void __init parse_setup_data(void)
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/7] x86, kaslr: Consolidate mem_avoid array filling
Now ZO sit end of the buffer, we can find out where is ZO text
and data/bss etc.
[input, input+input_size) is copied compressed kernel, not the whole ZO.
[output, output+init_size) is the buffer for VO.
[input+input_size, output+init_size) is [_text, _end) for ZO.
that could be first range in mem_avoid. We don't need to guess that anymore.
That area already include heap and stack for ZO running. So we don't need
to put them into mem_avoid array.
We need to put boot_params into the mem_avoid too. As with 64bit bootloader
could put it anywhere.
Also change output_size referring to init_size, as we pass init_size instead.
Cc: Kees Cook
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/aslr.c | 29 ++---
arch/x86/boot/compressed/misc.h | 4 ++--
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 7083c16..a279514 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -116,7 +116,7 @@ struct mem_vector {
unsigned long size;
};
-#define MEM_AVOID_MAX 5
+#define MEM_AVOID_MAX 4
static struct mem_vector mem_avoid[MEM_AVOID_MAX];
static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
@@ -142,7 +142,7 @@ static bool mem_overlaps(struct mem_vector *one, struct
mem_vector *two)
}
static void mem_avoid_init(unsigned long input, unsigned long input_size,
- unsigned long output, unsigned long output_size)
+ unsigned long output, unsigned long init_size)
{
u64 initrd_start, initrd_size;
u64 cmd_line, cmd_line_size;
@@ -151,10 +151,13 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
/*
* Avoid the region that is unsafe to overlap during
-* decompression (see calculations at top of misc.c).
+* decompression.
+* As we already move ZO (arch/x86/boot/compressed/vmlinux)
+* to the end of buffer, [input+input_size, output+init_size)
+* has [_text, _end) for ZO.
*/
- unsafe_len = (output_size >> 12) + 32768 + 18;
- unsafe = (unsigned long)input + input_size - unsafe_len;
+ unsafe_len = output + init_size - (input + input_size);
+ unsafe = (unsigned long)input + input_size;
mem_avoid[0].start = unsafe;
mem_avoid[0].size = unsafe_len;
@@ -176,13 +179,9 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
mem_avoid[2].start = cmd_line;
mem_avoid[2].size = cmd_line_size;
- /* Avoid heap memory. */
- mem_avoid[3].start = (unsigned long)free_mem_ptr;
- mem_avoid[3].size = BOOT_HEAP_SIZE;
-
- /* Avoid stack memory. */
- mem_avoid[4].start = (unsigned long)free_mem_end_ptr;
- mem_avoid[4].size = BOOT_STACK_SIZE;
+ /* Avoid params */
+ mem_avoid[3].start = (unsigned long)real_mode;
+ mem_avoid[3].size = sizeof(*real_mode);
}
/* Does this memory vector overlap a known avoided area? */
@@ -327,7 +326,7 @@ unsigned char *choose_kernel_location(struct boot_params
*params,
unsigned char *input,
unsigned long input_size,
unsigned char *output,
- unsigned long output_size)
+ unsigned long init_size)
{
unsigned long choice = (unsigned long)output;
unsigned long random;
@@ -349,10 +348,10 @@ unsigned char *choose_kernel_location(struct boot_params
*params,
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigned long)input, input_size,
- (unsigned long)output, output_size);
+ (unsigned long)output, init_size);
/* Walk e820 and find a random address. */
- random = find_random_addr(choice, output_size);
+ random = find_random_addr(choice, init_size);
if (!random) {
debug_putstr("KASLR could not find suitable E820 region...\n");
goto out;
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index ee3576b..23156e7 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -61,7 +61,7 @@ unsigned char *choose_kernel_location(struct boot_params
*params,
unsigned char *input,
unsigned long input_size,
unsigned char *output,
- unsigned long output_size);
+ unsigned long init_size);
/* cpuflags.c */
bool has_cpuflag(int flag);
#else
@@ -70,7 +70,7 @@ unsigned char *choose_kernel_location(struct boot_params
*params,
unsigned char *input,
[PATCH v3 7/7] x86, kaslr, 64bit: Set new or extra ident_mapping
First, aslr will support to put random VO above 4G, so we must set ident
mapping for the range even we come from startup_32 path.
Second, when boot from 64bit bootloader, bootloader set ident mapping,
and boot via ZO (arch/x86/boot/compressed/vmlinux) startup_64.
Those pages for pagetable need to be avoided when we select new random
VO (vmlinux) base. Otherwise decompressor would overwrite them during
decompressing.
One solution: go through pagetable and find out every page is used by
pagetable for every mem_aovid checking but we will need extra code.
Other solution: create new ident mapping instead, and pages for pagetable
will sit in _pagetable section of ZO, and they are in mem_avoid array already.
In this way, we can reuse the code for setting ident mapping.
The _pgtable will be shared 32bit and 64bit path to reduce init_size,
as now ZO _rodata to _end will contribute init_size.
Need to increase pgt buffer size.
When boot via startup_64, as we need to cover old VO, params, cmdline
and new VO, in extreme case we could have them all cross 512G boundary,
will need (2+2)*4 pages with 2M mapping. And need 2 for first 2M for vga ram.
Plus one for level4. Total will be 19 pages.
When boot via startup_32, aslr would move new VO above 4G, we need set extra
ident mapping for new VO, pgt buffer come from _pgtable offset 6 pages.
should only need (2+2) pages at most when it cross 512G boundary.
So 19 pages could make both pathes happy.
-v3: add mapping for first 2M with video ram when X86_VERBOSE_BOOTUP is set.
Don't need to set mapping for setup_data, as it is already late
in boot/ZO stage, will not access it until VO stage, and VO stage
will use early_memmap or kernel address to access them.
Cc: Kees Cook
Cc: Jiri Kosina
Cc: Borislav Petkov
Cc: Matt Fleming
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/aslr.c | 21
arch/x86/boot/compressed/head_64.S | 4 +-
arch/x86/boot/compressed/misc_pgt.c | 98 +
arch/x86/include/asm/boot.h | 19 +++
4 files changed, 140 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/boot/compressed/misc_pgt.c
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index a279514..34eb652 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -1,3 +1,8 @@
+#ifdef CONFIG_X86_64
+#define __pa(x) ((unsigned long)(x))
+#define __va(x) ((void *)((unsigned long)(x)))
+#endif
+
#include "misc.h"
#include
@@ -21,6 +26,8 @@ struct kaslr_setup_data {
__u8 data[1];
} kaslr_setup_data;
+#include "misc_pgt.c"
+
#define I8254_PORT_CONTROL 0x43
#define I8254_PORT_COUNTER00x40
#define I8254_CMD_READBACK 0xC0
@@ -160,6 +167,7 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
unsafe = (unsigned long)input + input_size;
mem_avoid[0].start = unsafe;
mem_avoid[0].size = unsafe_len;
+ fill_pagetable(output, init_size);
/* Avoid initrd. */
initrd_start = (u64)real_mode->ext_ramdisk_image << 32;
@@ -168,6 +176,7 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
initrd_size |= real_mode->hdr.ramdisk_size;
mem_avoid[1].start = initrd_start;
mem_avoid[1].size = initrd_size;
+ /* don't need to set mapping for initrd */
/* Avoid kernel command line. */
cmd_line = (u64)real_mode->ext_cmd_line_ptr << 32;
@@ -178,10 +187,19 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
;
mem_avoid[2].start = cmd_line;
mem_avoid[2].size = cmd_line_size;
+ fill_pagetable(cmd_line, cmd_line_size);
/* Avoid params */
mem_avoid[3].start = (unsigned long)real_mode;
mem_avoid[3].size = sizeof(*real_mode);
+ fill_pagetable((unsigned long)real_mode, sizeof(*real_mode));
+
+ /* don't need to set mapping for setup_data */
+
+#ifdef CONFIG_X86_VERBOSE_BOOTUP
+ /* for video ram */
+ fill_pagetable(0, PMD_SIZE);
+#endif
}
/* Does this memory vector overlap a known avoided area? */
@@ -362,6 +380,9 @@ unsigned char *choose_kernel_location(struct boot_params
*params,
goto out;
choice = random;
+
+ fill_pagetable(choice, init_size);
+ switch_pagetable();
out:
return (unsigned char *)choice;
}
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/compressed/head_64.S
index 69015b5..1b6e34a 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -125,7 +125,7 @@ ENTRY(startup_32)
/* Initialize Page tables to 0 */
lealpgtable(%ebx), %edi
xorl%eax, %eax
- movl$((4096*6)/4), %ecx
+ movl$(BOOT_INIT_PGT_SIZE/4), %ecx
rep stosl
/* Build Level 4 */
@@ -477,4 +477,4 @@ boot_stack_end:
.section ".pgtable","a",@nobits
[PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size
commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
introduced one run_size for kaslr.
We should use real runtime size (include copy/decompress) aka init_size.
run_size is VO (vmlinux) init size include bss and brk.
init_size is the size needed for decompress and it is bigger than run_size
when decompress need more buff.
According to arch/x86/boot/header.S:
| #define ZO_INIT_SIZE(ZO__end - ZO_startup_32 + ZO_z_extract_offset)
| #define VO_INIT_SIZE(VO__end - VO__text)
| #if ZO_INIT_SIZE > VO_INIT_SIZE
| #define INIT_SIZE ZO_INIT_SIZE
| #else
| #define INIT_SIZE VO_INIT_SIZE
| #endif
| init_size: .long INIT_SIZE # kernel initialization size
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
init_size first come from VO (vmlinux) init size. That VO init size
is from VO _end to VO _end and include VO bss and brk area.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that decompressor would not have output
overwrite input data before input data get consumed.
But z_extract_offset calculating is based on size of VO (vmlinux) and size
of compressed VO only at first.
So need to make sure [z_extra_offset, init_size) will fit ZO, that means
init_size need to be adjusted according to ZO size.
That make init_size is always >= run_size.
During aslr buffer searching, we need to make sure the new buffer is big
enough for decompress at first. So use init_size instead, and kill not
needed run_size related code.
Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
Cc: "H. Peter Anvin"
Cc: Josh Triplett
Cc: Matt Fleming
Cc: Kees Cook
Cc: Andrew Morton
Cc: Ard Biesheuvel
Cc: Junjie Mao
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/Makefile | 4 +---
arch/x86/boot/compressed/head_32.S | 5 ++---
arch/x86/boot/compressed/head_64.S | 5 +
arch/x86/boot/compressed/misc.c| 15 +++---
arch/x86/boot/compressed/mkpiggy.c | 9 ++--
arch/x86/tools/calc_run_size.sh| 42 --
6 files changed, 13 insertions(+), 67 deletions(-)
delete mode 100644 arch/x86/tools/calc_run_size.sh
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index 0a291cd..70cc92c 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -92,10 +92,8 @@ suffix-$(CONFIG_KERNEL_XZ) := xz
suffix-$(CONFIG_KERNEL_LZO):= lzo
suffix-$(CONFIG_KERNEL_LZ4):= lz4
-RUN_SIZE = $(shell $(OBJDUMP) -h vmlinux | \
-$(CONFIG_SHELL) $(srctree)/arch/x86/tools/calc_run_size.sh)
quiet_cmd_mkpiggy = MKPIGGY $@
- cmd_mkpiggy = $(obj)/mkpiggy $< $(RUN_SIZE) > $@ || ( rm -f $@ ; false )
+ cmd_mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false )
targets += piggy.S
$(obj)/piggy.S: $(obj)/vmlinux.bin.$(suffix-y) $(obj)/mkpiggy FORCE
diff --git a/arch/x86/boot/compressed/head_32.S
b/arch/x86/boot/compressed/head_32.S
index 1d7fbbc..cbed140 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -207,8 +207,7 @@ relocated:
* Do the decompression, and jump to the new kernel..
*/
/* push arguments for decompress_kernel: */
- pushl $z_run_size /* size of kernel with .bss and .brk */
- pushl $z_output_len /* decompressed length, end of relocs */
+ pushl $z_output_len /* decompressed length */
lealz_extract_offset_negative(%ebx), %ebp
pushl %ebp/* output address */
pushl $z_input_len/* input_len */
@@ -218,7 +217,7 @@ relocated:
pushl %eax/* heap area */
pushl %esi/* real mode pointer */
calldecompress_kernel /* returns kernel location in %eax */
- addl$28, %esp
+ addl$24, %esp
/*
* Jump to the decompressed kernel.
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/compressed/head_64.S
index 6b1766c..2884e0c 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -402,16 +402,13 @@ relocated:
* Do the decompression, and jump to the new kernel..
*/
pushq %rsi/* Save the real mode argument */
- movq$z_run_size, %r9/* size of kernel with .bss and .brk */
- pushq %r9
movq%rsi, %rdi /* real mode address */
leaqboot_heap(%rip), %rsi /* malloc area for uncompression */
leaqinput_data(%rip), %rdx /* input_data */
movl$z_input_len, %ecx /* input_len */
movq%rbp, %r8 /* output target address */
- movq$z_output_len, %r9 /* decompressed length, end of relocs */
+ movq$z_output_len, %r9 /* decompressed length */
calldecompress_kernel /* returns kernel
[PATCH v3 2/7] x86, boot: Move ZO to end of buffer
Boris found data from boot stage can not be used kernel stage.
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that decompressor would not have output
overwrite input data before input data get consumed.
After decompressor is called, VO (vmlinux) use whole buffer from start,
and ZO code and data section is overlapped with VO bss section.
And later VO/clear_bss() clear them before code in arch/x86/kernel/setup.c
access them.
To make the data survive that later, we should avoid the overlapping.
At first move ZO close the end of buffer instead of middle of the buffer,
that will move out ZO data out of VO bss area.
Also after that we can find out where is data section of copied ZO
instead of guessing. That will aslr mem_avoid array filling for
new buffer seaching much simple.
And rename z_extract_offset to z_min_extract_offset, as it is
actually the minimum offset for extracting now.
To keep the final real extract_offset to be page aligned like
min_extract_offset, we need make VO _end and ZO _end both
page aligned to make sure init_size always page aligned.
Next patch will add ZO data size to init_size, so it will make sure
ZO data is even out of VO brk area.
Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
Cc: "H. Peter Anvin"
Cc: Matt Fleming
Cc: Kees Cook
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/head_32.S | 11 +--
arch/x86/boot/compressed/head_64.S | 8 ++--
arch/x86/boot/compressed/mkpiggy.c | 7 ++-
arch/x86/boot/compressed/vmlinux.lds.S | 1 +
arch/x86/boot/header.S | 2 +-
arch/x86/kernel/asm-offsets.c | 1 +
arch/x86/kernel/vmlinux.lds.S | 1 +
7 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/arch/x86/boot/compressed/head_32.S
b/arch/x86/boot/compressed/head_32.S
index cbed140..a9b56f1 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -147,7 +147,9 @@ preferred_addr:
1:
/* Target address to relocate to for decompression */
- addl$z_extract_offset, %ebx
+ movlBP_init_size(%esi), %eax
+ subl$_end, %eax
+ addl%eax, %ebx
/* Set up the stack */
lealboot_stack_end(%ebx), %esp
@@ -208,8 +210,13 @@ relocated:
*/
/* push arguments for decompress_kernel: */
pushl $z_output_len /* decompressed length */
- lealz_extract_offset_negative(%ebx), %ebp
+
+ movlBP_init_size(%esi), %eax
+ subl$_end, %eax
+ movl%ebx, %ebp
+ subl%eax, %ebp
pushl %ebp/* output address */
+
pushl $z_input_len/* input_len */
lealinput_data(%ebx), %eax
pushl %eax/* input_data */
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/compressed/head_64.S
index 2884e0c..69015b5 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -101,7 +101,9 @@ ENTRY(startup_32)
1:
/* Target address to relocate to for decompression */
- addl$z_extract_offset, %ebx
+ movlBP_init_size(%esi), %eax
+ subl$_end, %eax
+ addl%eax, %ebx
/*
* Prepare for entering 64 bit mode
@@ -329,7 +331,9 @@ preferred_addr:
1:
/* Target address to relocate to for decompression */
- leaqz_extract_offset(%rbp), %rbx
+ movlBP_init_size(%rsi), %ebx
+ subl$_end, %ebx
+ addq%rbp, %rbx
/* Set up the stack */
leaqboot_stack_end(%rbx), %rsp
diff --git a/arch/x86/boot/compressed/mkpiggy.c
b/arch/x86/boot/compressed/mkpiggy.c
index b669ab6..c03b009 100644
--- a/arch/x86/boot/compressed/mkpiggy.c
+++ b/arch/x86/boot/compressed/mkpiggy.c
@@ -80,11 +80,8 @@ int main(int argc, char *argv[])
printf("z_input_len = %lu\n", ilen);
printf(".globl z_output_len\n");
printf("z_output_len = %lu\n", (unsigned long)olen);
- printf(".globl z_extract_offset\n");
- printf("z_extract_offset = 0x%lx\n", offs);
- /* z_extract_offset_negative allows simplification of head_32.S */
- printf(".globl z_extract_offset_negative\n");
- printf("z_extract_offset_negative = -0x%lx\n", offs);
+ printf(".globl z_min_extract_offset\n");
+ printf("z_min_extract_offset = 0x%lx\n", offs);
printf(".globl input_data, input_data_end\n");
printf("input_data:\n");
diff --git a/arch/x86/boot/compressed/vmlinux.lds.S
b/arch/x86/boot/compressed/vmlinux.lds.S
index 34d047c..e24e0a0 100644
--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -70,5 +70,6 @@ SECTIONS
_epgtable = . ;
}
#endif
+ . = ALIGN(PAGE_SIZE); /* ke
[PATCH v3 0/7] x86, boot: clean up kasl
First 3 patches make ZO (arch/x86/boot/compressed/vmlinux) data region is not overwritten by VO (vmlinux) after decompress. So could pass data from ZO to VO. The 4th one is fixing kaslr_enabled accessing. Old code is using address as value wrongly. Last 3 patches are the base for kaslr supporting kernel above 4G. create new ident mapping for kasl 64bit, so we can cover above 4G random kernel base, also don't need to track pagetable for 64bit bootloader (patched grub2 or kexec). that will make mem_avoid handling simple. Please put first 4 patches into tip/x86/urgent to v4.0 Last 3 patches should go to tip/x86/kasl and to v4.1, but you may need to pull x86/urgent to x86/kasl, as them depends on first 4 patches. He could rebase his patches about kasl on top those patches. git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-4.0-rc2-aslr Thanks Yinghai Lu Yinghai Lu (7): x86, kaslr: Use init_size instead of run_size x86, boot: Move ZO to end of buffer x86, boot: Don't overlap VO with ZO data x86, kaslr: Access the correct kaslr_enabled variable x86, kaslr: Consolidate mem_avoid array filling x86, boot: Split kernel_ident_mapping_init to another file x86, kaslr, 64bit: Set new or extra ident_mapping arch/x86/boot/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 4 +- arch/x86/boot/compressed/aslr.c| 48 - arch/x86/boot/compressed/head_32.S | 16 -- arch/x86/boot/compressed/head_64.S | 17 +++--- arch/x86/boot/compressed/misc.c| 15 +++--- arch/x86/boot/compressed/misc.h| 4 +- arch/x86/boot/compressed/misc_pgt.c| 98 ++ arch/x86/boot/compressed/mkpiggy.c | 16 ++ arch/x86/boot/compressed/vmlinux.lds.S | 2 + arch/x86/boot/header.S | 9 ++-- arch/x86/include/asm/boot.h| 19 +++ arch/x86/include/asm/page.h| 5 ++ arch/x86/kernel/asm-offsets.c | 1 + arch/x86/kernel/setup.c| 13 - arch/x86/kernel/vmlinux.lds.S | 1 + arch/x86/mm/ident_map.c| 74 + arch/x86/mm/init_64.c | 74 + arch/x86/tools/calc_run_size.sh| 42 --- 19 files changed, 288 insertions(+), 172 deletions(-) create mode 100644 arch/x86/boot/compressed/misc_pgt.c create mode 100644 arch/x86/mm/ident_map.c delete mode 100644 arch/x86/tools/calc_run_size.sh -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On March 7, 2015 1:54:41 PM PST, Paul Bolle wrote:
>On Sat, 2015-03-07 at 13:25 -0800, Dmitry Torokhov wrote:
>> I am not sure if anyone cares about exact version of GPL in module
>> information (2 only vs 2+) since it only used to figure out if the
>> module taints kernel or not. In fact there are more modules that are
>v2
>> only that claim GPL than the ones claiming GPL v2.
>>
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL")'`; do grep -H '2 as published' $file; done | wc
>-l
>> 259
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL v2")'`; do grep -H '2 as published' $file; do ne |
>wc -l
>> 150
>>
>> Also:
>>
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL v2")'`; do grep -H '2 or ' $file; done | wc -l
>> 68
>> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
>'MODULE_LICENSE("GPL")'`; do grep -H '2 or ' $file; done | wc -l
>> 237
>
>By that logic we might as well simplify the logic of
>license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check
>for six variants instead of just one and be done with it?
Because nobody wants to go through hundreds of drivers and change them?
>
>Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So,
>unless a patch is applied to treat them interchangeably, somehow, in
>the
>module license checking code,
They are treated interchangeably as far as I can see. Where do you see "GPL" is
being treated differently than "GPL v2".
> we ought to make each instance of
>MODULE_LICENSE() match the actual license of the module it's used for.
>
>Yes, that's annoying. You're free to submit a patch to end all the
>busywork this brings along. But I fear there's a reason for all that
>busywork. Please prove me wrong. It would make everyone's life a bit
>easier.
>
>
>Paul Bolle
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar, On Sat, Mar 07, 2015 at 03:21:40PM +, Lad Prabhakar wrote: > + pixel-clock-frequency = <7000>; As commented privately, could you use the link-frequencies property for this purpose? On parallel bus if often equals the pixel clock, but works much better on serial busses. It'd documented in video-interfaces.txt. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Sat, 2015-03-07 at 13:25 -0800, Dmitry Torokhov wrote:
> I am not sure if anyone cares about exact version of GPL in module
> information (2 only vs 2+) since it only used to figure out if the
> module taints kernel or not. In fact there are more modules that are v2
> only that claim GPL than the ones claiming GPL v2.
>
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
> 'MODULE_LICENSE("GPL")'`; do grep -H '2 as published' $file; done | wc -l
> 259
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL
> v2")'`; do grep -H '2 as published' $file; do ne | wc -l
> 150
>
> Also:
>
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l 'MODULE_LICENSE("GPL
> v2")'`; do grep -H '2 or ' $file; done | wc -l
> 68
> dtor@dtor-ws:~/kernel/master$ for file in `grep -r -l
> 'MODULE_LICENSE("GPL")'`; do grep -H '2 or ' $file; done | wc -l
> 237
By that logic we might as well simplify the logic of
license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check
for six variants instead of just one and be done with it?
Anyhow, "GPL" and "GPL v2" are both allowed but not identical. So,
unless a patch is applied to treat them interchangeably, somehow, in the
module license checking code, we ought to make each instance of
MODULE_LICENSE() match the actual license of the module it's used for.
Yes, that's annoying. You're free to submit a patch to end all the
busywork this brings along. But I fear there's a reason for all that
busywork. Please prove me wrong. It would make everyone's life a bit
easier.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] rcu: Panic if RCU tree can not accommodate all CPUs
On Sat, Mar 07, 2015 at 06:48:21PM +, Alexander Gordeev wrote:
> On Sat, Mar 07, 2015 at 09:42:34AM -0800, Paul E. McKenney wrote:
> > On Sat, Mar 07, 2015 at 06:03:36PM +0100, Alexander Gordeev wrote:
> > > Currently a condition when RCU tree is unable to accommodate
> > > the configured number of CPUs is not permitted and causes
> > > a fall back to compile-time values. However, the code has no
> > > means to exceed the RCU tree capacity neither at compile-time
> > > nor in run-time. Therefore, if the condition is met in run-
> > > time then it indicates a serios problem elsewhere and should
> > > be handled with a panic.
> > >
> > > Cc: "Paul E. McKenney"
> > > Signed-off-by: Alexander Gordeev
> >
> > The place to put a check like this is in the code that calculates
> > nr_cpu_ids. And at least some (perhaps all) are set up so that nr_cpu_ids
> > cannot exceed NR_CPUS, which would render this check redundant.
>
> The emphasis here the existing check (... n > rcu_capacity[MAX_RCU_LVLS])
> (below as [1]) should not cause the fall back to compiled-time values.
> It either must panic or, as you say - redundant.
You are right, I responded too early on a Saturday. The point of the
check below is indeed to verify that RCU's calculations are correct.
So do the testing with CONFIG_RCU_FANOUT and CONFIG_RCU_FANOUT_LEAF both
equal to five, and rebase to the rcu/next branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
And I will give them a spin.
Thanx, Paul
> > So I have to say "no" to this one.
> >
> > Thanx, Paul
> >
> > > ---
> > > kernel/rcu/tree.c | 15 +--
> > > 1 file changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 48d640c..7588c7f 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -3889,16 +3889,19 @@ static void __init rcu_init_geometry(void)
> > > rcu_capacity[i] = rcu_capacity[i - 1] * CONFIG_RCU_FANOUT;
> > >
> > > /*
> > > + * The tree must be able to accommodate the configured number of CPUs.
> > > + * If this limit is exceeded than we have a serious problem elsewhere.
> > > + *
> > >* The boot-time rcu_fanout_leaf parameter is only permitted
> > >* to increase the leaf-level fanout, not decrease it. Of course,
> > >* the leaf-level fanout cannot exceed the number of bits in
> > > - * the rcu_node masks. Finally, the tree must be able to accommodate
> > > - * the configured number of CPUs. Complain and fall back to the
> > > - * compile-time values if these limits are exceeded.
> > > + * the rcu_node masks. Complain and fall back to the compile-
> > > + * time values if these limits are exceeded.
> > >*/
> > > - if (rcu_fanout_leaf < CONFIG_RCU_FANOUT_LEAF ||
> > > - rcu_fanout_leaf > sizeof(unsigned long) * 8 ||
> > > - n > rcu_capacity[MAX_RCU_LVLS]) {
>
> [1]
>
> > > + if (n > rcu_capacity[MAX_RCU_LVLS])
> > > + panic("rcu_init_geometry: rcu_capacity[] is too small");
> > > + else if (rcu_fanout_leaf < CONFIG_RCU_FANOUT_LEAF ||
> > > + rcu_fanout_leaf > sizeof(unsigned long) * 8) {
> > > WARN_ON(1);
> > > return;
> > > }
> > > --
> > > 1.8.3.1
> > >
> >
>
> --
> Regards,
> Alexander Gordeev
> agord...@redhat.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/
