Re: [PATCH v2] pwm: renesas-tpu: Add missing pwmchip_remove() call in tpu_remove()
On Thu, May 23, 2013 at 09:12:17PM +0200, Thierry Reding wrote: > On Thu, May 23, 2013 at 10:39:34AM +0900, Simon Horman wrote: > > On Mon, May 20, 2013 at 03:46:59PM +0200, Laurent Pinchart wrote: > > > Hi Axel, > > > > > > Thank you for the patch. > > > > > > On Monday 20 May 2013 21:45:41 Axel Lin wrote: > > > > Signed-off-by: Axel Lin > > > > > > Acked-by: Laurent Pinchart > > > > Thanks. I have queued this up for v3.11 in the pinmux branch > > of my renesas tree on kernel.org. > > I'd rather take this through the PWM tree along with the original driver > patch. Sure that is fine. I had them queued up in my tree but I have dropped them now. That should propogate to linux-next in the not too distant future. I have also dropped the following changes from my tree as they appear to ether depend on the TPU PWD driver or one of the other patches in the list below. Laurent, I think it would be best if you resubmitted these patches once there is a stable branch available with the TPU PWD driver merged which I can use as a base. ARM: mach-shmobile: armadillo800eva: Add backlight support ARM: mach-shmobile: kota2: Use leds-pwm + pwm-rmob leds: Remove leds-renesas-tpu driver sh-pfc: sh73a0: Remove function GPIOs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
On Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote: > I'll go along with this. I'm also wondering what the problem would be > if we just allowed all commands on either CAP_SYS_RAWIO or opening the > device for write, so we just defer to the filesystem permissions and > restricted read only opens to the basic all device opcodes. I've been out of this area for a bit, but the problem used to be that you could send destructive commands to a partition. The right fix for that would be to not allow SG_IO on partitions at all, just wondering if anything would be broken by 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/
Re: XFS assertion from truncate. (3.10-rc2)
On 5/24/13 3:03 AM, Dave Chinner wrote: > Right, patch below should fix the problem. > > What a frustrating bug. Now, where's my bottle of scotch? In your pantry, Dave. Next to the others! ;) -Eric > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] module: use a macro instead of platform_driver_register
I found a lot of mistakes using struct platform_driver without owner
so I make a macro instead of the function platform_driver_register.
It can set owner in it, then guys don`t care about module owner again.
Signed-off-by: Libo Chen
---
drivers/base/platform.c |8 +---
include/linux/platform_device.h |8 +++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9eda842..ed75cf6 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -523,11 +523,13 @@ static void platform_drv_shutdown(struct device *_dev)
}
/**
- * platform_driver_register - register a driver for platform-level devices
+ * __platform_driver_register - register a driver for platform-level devices
* @drv: platform driver structure
*/
-int platform_driver_register(struct platform_driver *drv)
+int __platform_driver_register(struct platform_driver *drv,
+ struct module *owner)
{
+ drv->driver.owner = owner;
drv->driver.bus = _bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
@@ -538,7 +540,7 @@ int platform_driver_register(struct platform_driver *drv)
return driver_register(>driver);
}
-EXPORT_SYMBOL_GPL(platform_driver_register);
+EXPORT_SYMBOL_GPL(__platform_driver_register);
/**
* platform_driver_unregister - unregister a driver for platform-level devices
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 9abf1db..cd46ee5 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -180,7 +180,13 @@ struct platform_driver {
const struct platform_device_id *id_table;
};
-extern int platform_driver_register(struct platform_driver *);
+/*
+ * use a macro to avoid include chaining to get THIS_MODULE
+ */
+#define platform_driver_register(drv) \
+ __platform_driver_register(drv, THIS_MODULE)
+extern int __platform_driver_register(struct platform_driver *,
+ struct module *);
extern void platform_driver_unregister(struct platform_driver *);
/* non-hotpluggable platform devices may use this so that probe() and
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV
On OMAP4 platforms, EHCI HCD needs the physical layer signalling activated, along with the NOP USB Transceiver driver. Otherwise, the kernel boots without registering any USB device. This patch applies to Linux 3.10-rc2. Signed-off-by: Adrien Vergé --- diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index de94f26..47959d7 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -44,6 +44,8 @@ endif # USB_XHCI_HCD config USB_EHCI_HCD tristate "EHCI HCD (USB 2.0) support" depends on USB_ARCH_HAS_EHCI + select USB_PHY if ARCH_OMAP4 + select NOP_USB_XCEIV if ARCH_OMAP4 ---help--- The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0 "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
On Fri, 2013-05-24 at 17:02 +0900, Tejun Heo wrote: > On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini wrote: > >> The same filtering table being applied to different classes of > >> hardware is a software bug, but my point is that the practive > >> essentially entrusts non-insignificant part of security enforcement to > >> the hardware itself. The variety of hardware in question is very wide > >> and significant portion has historically been known to be flaky. > > > > Unproven theory, and contradicted by actual practice. Bugs are more > > common in the handling of borderline conditions, not in the handling of > > unimplemented commands. > > > > If you want to be secure aginst buggy firmware, the commands you have to > > block are READ and WRITE. Check out the list of existing USB quirks. > > Well, I'd actually much prefer disabling CDB whitelisting for all !MMC > devices if at all possible. I'll go along with this. I'm also wondering what the problem would be if we just allowed all commands on either CAP_SYS_RAWIO or opening the device for write, so we just defer to the filesystem permissions and restricted read only opens to the basic all device opcodes. > You're basically arguing that because what > we have is already broken, it should be okay to break it further. > Also, RW commands having more quirks doesn't necessarily indicate that > they tend to be more broken. They just get hammered on a lot in > various ways so problems on those commands tend to be more noticeable. I agree with this, so finding a way to get rid of the opcode table seems to be what we need. > > You need to allow more commands. > > The count-me-out knob allows all commands. > > You cannot always allow all commands. > > Ergo, you cannot always use the count-me-out knob. Do we have a real world example of this? Getting the kernel out of the command filtering business does seem to be a good idea to me. > The thing is that both approaches aren't perfect here so you can make > similar type of argument from the other side. If the system wants to > give out raw hardware access to VMs, requiring it to delegate the > device fully could be reasonable. Not ideal but widening direct > command access by default is pretty nasty too. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86, mm: fix boot hang regression
Commit 8d57470d introduced a kernel panic while setting mem=2G at
boot time, and commit c9b3234a6 turns the the kernel panic to hang.
While, the reason is the same: the are accessing a BAD address; I mean
the mapping is broken.
Here is a mem mapping range dumped at boot time:
[mem 0x-0x000f] page 4k (0)
[mem 0x7fe0-0x7fff] page 1G (1)
[mem 0x7c00-0x7fdf] page 1G (2)
[mem 0x0010-0x001f] page 4k (3)
[mem 0x0020-0x7bff] page 2M (4)
Where, we met no problems while setting memory map for region (0) to
(3). But we have set PG_LEVEL_1G mapping for pud index 0x1 at (1).
And pud index comes to 0x1 as well while setting 0x4000-0x7bf0
part of (4). What's more, it's PG_LEVEL_2M mapping, which results to a
splitting of PG_LEVEL_1G mapping. This breaks former mapping for (1) and
(2). In the same time, due to "end" setting to 0x7c00, we missed the
chance to fix it at phys_pmd_init() for code:
if (address >= end) {
continue;
}
Thus, using a extra flag to indicate we are splitting a large PUD(or PMD)
and changing the above if statement to following will make this issue gone:
if(address >= end && !spliting) {
...
}
Reported-by: LKP
CC: For 3.9+
Cc: H. Peter Anvin
Cc: Yinghai Lu
Bisected-by: "Xie, ChanglongX"
Signed-off-by: Yuanhan Liu
---
I reported this panic regression long time ago, and I didn't notic the above
panic->hang change before, which might confuse Yinghai for understanding
what happened from 2 logs I sent before(one is from 8d57470d, another is
from the HEAD commit at that time, which turn to a hang as stated).
More, it seems that Yinghai can't produce it. And I was busying at
something else. And I finally got a day yesterday(and a good mood ;).
Last, Thanks Changlong's effort for bisecting the 2 above commit.
---
arch/x86/mm/init_64.c | 51 +---
1 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index bb00c46..e4c7038 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -401,7 +401,7 @@ void __init cleanup_highmap(void)
static unsigned long __meminit
phys_pte_init(pte_t *pte_page, unsigned long addr, unsigned long end,
- pgprot_t prot)
+ pgprot_t prot, bool split_pmd)
{
unsigned long pages = 0, next;
unsigned long last_map_addr = end;
@@ -411,7 +411,7 @@ phys_pte_init(pte_t *pte_page, unsigned long addr, unsigned
long end,
for (i = pte_index(addr); i < PTRS_PER_PTE; i++, addr = next, pte++) {
next = (addr & PAGE_MASK) + PAGE_SIZE;
- if (addr >= end) {
+ if (addr >= end && !split_pmd) {
if (!after_bootmem &&
!e820_any_mapped(addr & PAGE_MASK, next, E820_RAM)
&&
!e820_any_mapped(addr & PAGE_MASK, next,
E820_RESERVED_KERN))
@@ -446,7 +446,7 @@ phys_pte_init(pte_t *pte_page, unsigned long addr, unsigned
long end,
static unsigned long __meminit
phys_pmd_init(pmd_t *pmd_page, unsigned long address, unsigned long end,
- unsigned long page_size_mask, pgprot_t prot)
+ unsigned long page_size_mask, pgprot_t prot, bool split_pud)
{
unsigned long pages = 0, next;
unsigned long last_map_addr = end;
@@ -457,9 +457,10 @@ phys_pmd_init(pmd_t *pmd_page, unsigned long address,
unsigned long end,
pmd_t *pmd = pmd_page + pmd_index(address);
pte_t *pte;
pgprot_t new_prot = prot;
+ bool split_pmd = false;
next = (address & PMD_MASK) + PMD_SIZE;
- if (address >= end) {
+ if (address >= end && !split_pud) {
if (!after_bootmem &&
!e820_any_mapped(address & PMD_MASK, next,
E820_RAM) &&
!e820_any_mapped(address & PMD_MASK, next,
E820_RESERVED_KERN))
@@ -472,7 +473,7 @@ phys_pmd_init(pmd_t *pmd_page, unsigned long address,
unsigned long end,
spin_lock(_mm.page_table_lock);
pte = (pte_t *)pmd_page_vaddr(*pmd);
last_map_addr = phys_pte_init(pte, address,
- end, prot);
+ end, prot, split_pmd);
spin_unlock(_mm.page_table_lock);
continue;
}
@@ -495,6 +496,7 @@ phys_pmd_init(pmd_t *pmd_page, unsigned long address,
unsigned long end,
continue;
}
new_prot = pte_pgprot(pte_clrhuge(*(pte_t *)pmd));
+ split_pmd = true;
}
Re: [PATCH v3 part1 1/4] sg_io: pass request_queue to blk_verify_command
On Fri, 2013-05-24 at 10:32 +0200, Paolo Bonzini wrote: > Il 24/05/2013 10:03, James Bottomley ha scritto: > > > >>> Does anyone in the real world actually care about this bug? > > >> > > >> Yes, or I would move on and not waste so much time on this. > >>> > > > >>> > > Fine, so produce a simple fix for this bug which we can discuss that's > >>> > > not tied to this feature. > >> > > >> > Honestly, I have no idea how this is even possible. > > Really? It looks to me like a simple block on the commands for disk > > devices in the opcode switch would do it (with a corresponding change to > > sg.c:sg_allow_access). > > Which switch? What I can do is something like this in blk_verify_command: not in blk_verify_command: outside of it, in the three places it's used. > if (q->sgio_type == TYPE_ROM) > return 0; > if (rq->cmd[0] == 0xA4) > return -EPERM; > if (!is_write && > (req->cmd[0] == ... || rq->cmd[0] == ...)) > return -EPERM; > > But then the particular patch you're replying to is still necessary, > and you're slowing down blk_verify_command. It's a set if if switches in non performance critical code. > It may be fine for stable > and -rc, but IMHO it calls for a better implementation in 3.11. What goes into stable should be what goes into the real kernel and it helps separate the bug fix from feature argument. James > (Besides, I did it like this because it is what Tejun suggested). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
Martin K. Petersen, on 05/22/2013 09:32 AM wrote: > Paolo> First of all, I'll note that SG_IO and block-device-specific > Paolo> ioctls both have their place. My usecase for SG_IO is > Paolo> virtualization, where I need to pass information from the LUN to > Paolo> the virtual machine with as much fidelity as possible if I choose > Paolo> to virtualize at the SCSI level. > > Now there's your problem! Several people told you way back that the SCSI > virt approach was a really poor choice. The SG_IO permissions problem is > a classic "Doctor, it hurts when I do this". > > The kernel's fundamental task is to provide abstraction between > applications and intricacies of hardware. The right way to solve the > problem would have been to provide a better device abstraction built on > top of the block/SCSI infrastructure we already have in place. If you > need more fidelity, add fidelity to the block layer instead of punching > a giant hole through it. > > I seem to recall that reservations were part of your motivation for > going the SCSI route in the first place. A better approach would have > been to create a generic reservations mechanism that could be exposed to > the guest. And then let the baremetal kernel worry about the appropriate > way to communicate with the physical hardware. Just like we've done with > reads and writes, discard, write same, etc. Well, any abstraction is good only if it isn't artificial, so solving more problems than creating. Reality is that de facto in the industry _SCSI_ is the abstraction for block/direct access to data. Look around. How many of systems around you after all layers end up to SCSI commands in their storage devices? Linux block layer is purely artificial creature slowly reinventing wheel creating more problems, than solving. It enforces approach, where often "impossible" means "impossible in this interface". For instance, how about copy offload? How about reservations? How about atomic writes? Look at history of barriers and compare then with what can be done in SCSI. It's still worse, because doesn't allow usage of all devices capabilities. Why was it needed to create special blk integrity interface with the only end user - SCSI? Artificial task created - then well solved. Etc, etc. The block layer keeps repeating SCSI. So, maybe, after all, it's better to acknowledge that direct usage of SCSI without any intermediate layers and translations is more productive? And for those minors not using SCSI internally, translate from SCSI to their internal commands? Creating and filling CDB fields for most cases isn't anyhow harder, than creating and feeling bio fields. So, I appreciate work Paolo is doing in this direction. At least, the right thing will be on the virtualization level. I do understand that with all existing baggage replacing block layer by SCSI isn't practical and not proposing it, but let's at least acknowledge limitations of the academic block abstraction. Let's don't make those limitations global walls. Many things better to do using direct SCSI, hence let's do the better way. Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] s390: Remove setting for saved_max_pfn
From: Zhang Yanfei The only user of saved_max_pfn in s390 is read_oldmem interface but we have removed that interface, so saved_max_pfn is now unneeded in s390, and we needn't set it anymore. Signed-off-by: Zhang Yanfei Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Michael Holzheu --- arch/s390/kernel/setup.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c index 0a49095..497451e 100644 --- a/arch/s390/kernel/setup.c +++ b/arch/s390/kernel/setup.c @@ -719,10 +719,6 @@ static void reserve_oldmem(void) } create_mem_hole(memory_chunk, OLDMEM_BASE, OLDMEM_SIZE); create_mem_hole(memory_chunk, OLDMEM_SIZE, real_size - OLDMEM_SIZE); - if (OLDMEM_BASE + OLDMEM_SIZE == real_size) - saved_max_pfn = PFN_DOWN(OLDMEM_BASE) - 1; - else - saved_max_pfn = PFN_DOWN(real_size) - 1; #endif } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] ia64: Remove setting for saved_max_pfn
From: Zhang Yanfei The only user of saved_max_pfn in ia64 is read_oldmem interface but we have removed that interface, so saved_max_pfn is now unneeded in ia64, and we needn't set it anymore. Signed-off-by: Zhang Yanfei Cc: Matt Fleming Cc: Tony Luck Cc: Fenghua Yu --- arch/ia64/kernel/efi.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c index f034563..51bce59 100644 --- a/arch/ia64/kernel/efi.c +++ b/arch/ia64/kernel/efi.c @@ -1116,11 +1116,6 @@ efi_memmap_init(u64 *s, u64 *e) if (!is_memory_available(md)) continue; -#ifdef CONFIG_CRASH_DUMP - /* saved_max_pfn should ignore max_addr= command line arg */ - if (saved_max_pfn < (efi_md_end(md) >> PAGE_SHIFT)) - saved_max_pfn = (efi_md_end(md) >> PAGE_SHIFT); -#endif /* * Round ends inward to granule boundaries * Give trimmings to uncached allocator -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] powerpc: Remove savemaxmem parameter setup
From: Zhang Yanfei
saved_max_pfn is used to know the amount of memory that the previous
kernel used. And for powerpc, we set saved_max_pfn by passing the
kernel commandline parameter "savemaxmem=".
The only user of saved_max_pfn in powerpc is read_oldmem interface.
Since we have removed read_oldmem, we don't need this parameter anymore.
Signed-off-by: Zhang Yanfei
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
arch/powerpc/kernel/crash_dump.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 9ec3fe1..779a78c 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -69,16 +69,6 @@ void __init setup_kdump_trampoline(void)
}
#endif /* CONFIG_NONSTATIC_KERNEL */
-static int __init parse_savemaxmem(char *p)
-{
- if (p)
- saved_max_pfn = (memparse(p, ) >> PAGE_SHIFT) - 1;
-
- return 1;
-}
-__setup("savemaxmem=", parse_savemaxmem);
-
-
static size_t copy_oldmem_vaddr(void *vaddr, char *buf, size_t csize,
unsigned long offset, int userbuf)
{
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] mips: Remove savemaxmem parameter setup
From: Zhang Yanfei
saved_max_pfn is used to know the amount of memory that the previous
kernel used. And for powerpc, we set saved_max_pfn by passing the
kernel commandline parameter "savemaxmem=".
The only user of saved_max_pfn in mips is read_oldmem interface.
Since we have removed read_oldmem, so we don't need this parameter
anymore.
Signed-off-by: Zhang Yanfei
Cc: Ralf Baechle
---
arch/mips/kernel/crash_dump.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/mips/kernel/crash_dump.c b/arch/mips/kernel/crash_dump.c
index 3be9e7b..f291cf9 100644
--- a/arch/mips/kernel/crash_dump.c
+++ b/arch/mips/kernel/crash_dump.c
@@ -4,16 +4,6 @@
#include
#include
-static int __init parse_savemaxmem(char *p)
-{
- if (p)
- saved_max_pfn = (memparse(p, ) >> PAGE_SHIFT) - 1;
-
- return 1;
-}
-__setup("savemaxmem=", parse_savemaxmem);
-
-
static void *kdump_buf_page;
/**
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] Documentation/kdump/kdump.txt: Remove /dev/oldmem description
From: Zhang Yanfei Signed-off-by: Zhang Yanfei Cc: Vivek Goyal --- Documentation/kdump/kdump.txt | 31 ++- 1 files changed, 6 insertions(+), 25 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 9c7fd98..bec123e 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -47,19 +47,12 @@ parameter. Optionally the size of the ELF header can also be passed when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax. -With the dump-capture kernel, you can access the memory image, or "old -memory," in two ways: - -- Through a /dev/oldmem device interface. A capture utility can read the - device file and write out the memory in raw format. This is a raw dump - of memory. Analysis and capture tools must be intelligent enough to - determine where to look for the right information. - -- Through /proc/vmcore. This exports the dump as an ELF-format file that - you can write out using file copy commands such as cp or scp. Further, - you can use analysis tools such as the GNU Debugger (GDB) and the Crash - tool to debug the dump file. This method ensures that the dump pages are - correctly ordered. +With the dump-capture kernel, you can access the memory image through +/proc/vmcore. This exports the dump as an ELF-format file that you can +write out using file copy commands such as cp or scp. Further, you can +use analysis tools such as the GNU Debugger (GDB) and the Crash tool to +debug the dump file. This method ensures that the dump pages are correctly +ordered. Setup and Installation @@ -423,18 +416,6 @@ the following command: cp /proc/vmcore -You can also access dumped memory as a /dev/oldmem device for a linear -and raw view. To create the device, use the following command: - -mknod /dev/oldmem c 1 12 - -Use the dd command with suitable options for count, bs, and skip to -access specific portions of the dump. - -To see the entire memory, use the following command: - - dd if=/dev/oldmem of=oldmem.001 - Analysis -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] Documentation/devices.txt: Remove /dev/oldmem description
From: Zhang Yanfei Signed-off-by: Zhang Yanfei Cc: Dave Jones --- Documentation/devices.txt |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 08f01e7..4f85739 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -100,8 +100,6 @@ Your cooperation is appreciated. 10 = /dev/aio Asynchronous I/O notification interface 11 = /dev/kmsg Writes to this come out as printk's, reads export the buffered printk records. -12 = /dev/oldmem Used by crashdump kernels to access - the memory of the kernel that crashed. 1 block RAM disk 0 = /dev/ram0 First RAM disk -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] /dev/oldmem: Remove the interface
From: Zhang Yanfei
/dev/oldmem provides the interface for us to access the "old memory" in
the dump-capture kernel. Unfortunately, no one actually uses this interface.
And this interface could actually cause some real problems if used on ia64
where the cached/uncached accesses are mixed. See the discussion from
the link: https://lkml.org/lkml/2013/4/12/386.
So Eric suggested that we should remove /dev/oldmem as an unused piece of
code.
Suggested-by: "Eric W. Biederman"
Signed-off-by: Zhang Yanfei
Cc: Vivek Goyal
Cc: Dave Hansen
Cc: "H. Peter Anvin"
Cc: Andrew Morton
---
drivers/char/mem.c | 47 ---
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 1ccbe94..bbe8ab4 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -357,40 +356,6 @@ static int mmap_kmem(struct file *file, struct
vm_area_struct *vma)
}
#endif
-#ifdef CONFIG_CRASH_DUMP
-/*
- * Read memory corresponding to the old kernel.
- */
-static ssize_t read_oldmem(struct file *file, char __user *buf,
- size_t count, loff_t *ppos)
-{
- unsigned long pfn, offset;
- size_t read = 0, csize;
- int rc = 0;
-
- while (count) {
- pfn = *ppos / PAGE_SIZE;
- if (pfn > saved_max_pfn)
- return read;
-
- offset = (unsigned long)(*ppos % PAGE_SIZE);
- if (count > PAGE_SIZE - offset)
- csize = PAGE_SIZE - offset;
- else
- csize = count;
-
- rc = copy_oldmem_page(pfn, buf, csize, offset, 1);
- if (rc < 0)
- return rc;
- buf += csize;
- *ppos += csize;
- read += csize;
- count -= csize;
- }
- return read;
-}
-#endif
-
#ifdef CONFIG_DEVKMEM
/*
* This function reads the *virtual* memory as seen by the kernel.
@@ -772,7 +737,6 @@ static int open_port(struct inode *inode, struct file *filp)
#define aio_write_zero aio_write_null
#define open_mem open_port
#define open_kmem open_mem
-#define open_oldmemopen_mem
static const struct file_operations mem_fops = {
.llseek = memory_lseek,
@@ -837,14 +801,6 @@ static const struct file_operations full_fops = {
.write = write_full,
};
-#ifdef CONFIG_CRASH_DUMP
-static const struct file_operations oldmem_fops = {
- .read = read_oldmem,
- .open = open_oldmem,
- .llseek = default_llseek,
-};
-#endif
-
static const struct memdev {
const char *name;
umode_t mode;
@@ -866,9 +822,6 @@ static const struct memdev {
#ifdef CONFIG_PRINTK
[11] = { "kmsg", 0644, _fops, NULL },
#endif
-#ifdef CONFIG_CRASH_DUMP
- [12] = { "oldmem", 0, _fops, NULL },
-#endif
};
static int memory_open(struct inode *inode, struct file *filp)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] Remove unused /dev/oldmem interface
/dev/oldmem provides the interface for us to access the "old memory" in the dump-capture kernel. Unfortunately, no one actually uses this interface. And this interface could actually cause some real problems if used on ia64 where the cached/uncached accesses are mixed. See the discussion from the link: https://lkml.org/lkml/2013/4/12/386. So Eric suggested that we should remove /dev/oldmem as an unused piece of code. Besides, we used a global variable saved_max_pfn to let the capture kernel know the amount of memory that the previous kernel used. And for almost all architectures (except x86. In x86, saved_max_pfn is used by detect_calgary()), the only user of this variable is the read_oldmem interface of /dev/oldmem, so also remove the setting for saved_max_pfn in those architectures. Zhang Yanfei (7): /dev/oldmem: Remove this interface Documentation/devices.txt: Remove /dev/oldmem description Documentation/kdump/kdump.txt: Remove /dev/oldmem description mips: Remove savemaxmem parameter setup powerpc: Remove savemaxmem parameter setup ia64: Remove setting for saved_max_pfn s390: Remove setting for saved_max_pfn Documentation/devices.txt|2 - Documentation/kdump/kdump.txt| 31 + arch/ia64/kernel/efi.c |5 arch/mips/kernel/crash_dump.c| 10 arch/powerpc/kernel/crash_dump.c | 10 arch/s390/kernel/setup.c |4 --- drivers/char/mem.c | 47 -- 7 files changed, 6 insertions(+), 103 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stupid VFS name lookup interface..
On Tue, May 21, 2013 at 3:22 PM, Linus Torvalds
wrote:
>
> Untested patch attached. It compiles cleanly, looks sane, and most of
> it is just making the function prototypes look much nicer. I think it
> works.
Ok, here's another patch in the "let's make the VFS go faster series".
This one, sadly, is not a cleanup.
The concept is simple: right now the inode->i_security pointer chasing
kills us on inode security checking with selinux. So let's move two of
the fields from the selinux security fields directly into the inode.
So instead of doing "inode->i_security->{sid,sclass}", we can just do
"inode->{i_sid,i_sclass}" directly.
It's a very mechanical transform, so it should all be good, but the
reason I don't much like it is that I think other security models
might want to do something like this too, and right now it's
selinux-specific. I could imagine making it just an anonymous union of
size 64 bits or something, and just making one of the union entries be
an (anonymous) struct with those two fields. So it's not conceptually
selinux-specific, but right now it's pretty much a selinux hack.
But it's a selinux-specific hack that really does matter. The
inode_has_perm() and selinux_inode_permission() functions show up
pretty high on kernel profiles that do a lot of filename lookup, and
it's pretty much all just that i_security pointer chasing and extra
cache miss.
With this, inode->i_security is not very hot any more, and we could
move the i_security pointer elsewhere in the inode.
Comments? I don't think this is *pretty* (and I do want to repeat that
it's not even tested yet), but I think it's worth it. We've been very
good at avoiding extra pointer dereferences in the path lookup, this
is one of the few remaining ones.
Linus
patch.diff
Description: Binary data
Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Zhang Yanfei writes: > Hello Eric, > >> The function copy_oldmem_page also concerns me. I don't have a clue why >> we duplicate that function on every architecutre in a slightly different >> form. There should be enough abstractions in the kernel to make that >> unnecessary. I would be glad to see that function go, and remove the >> possibility of confusion that happened on s390. > > You mean we should have a common copy_oldmem_page for all architectures? And > just like vivek said above, for s390, we should put the swap info in the elf > headers instead of doing that in copy_oldmem_page. Exactly. The user space change in /sbin/kexec should even be backwards compatible for s390. So fixing /sbin/kexec should probably come first. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
> >diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> >index 8465c2a..da6bf61 100644
> >--- a/arch/powerpc/kvm/powerpc.c
> >@@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> >+++ b/arch/powerpc/kvm/powerpc.c
> > break;
> > #endif
> > case KVM_CAP_SPAPR_MULTITCE:
> >+case KVM_CAP_SPAPR_TCE_IOMMU:
> > r = 1;
> > break;
> > default:
>
> Don't advertise SPAPR capabilities if it's not book3s -- and
> probably there's some additional limitation that would be
> appropriate.
So, in the case of MULTITCE, that's not quite right. PR KVM can
emulate a PAPR system on a BookE machine, and there's no reason not to
allow TCE acceleration as well. We can't make it dependent on PAPR
mode being selected, because that's enabled per-vcpu, whereas these
capabilities are queried on the VM before the vcpus are created.
CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable
host side hardware (i.e. a PAPR style IOMMU), though.
>
> >@@ -1025,6 +1026,17 @@ long kvm_arch_vm_ioctl(struct file *filp,
> > r = kvm_vm_ioctl_create_spapr_tce(kvm, _tce);
> > goto out;
> > }
> >+case KVM_CREATE_SPAPR_TCE_IOMMU: {
> >+struct kvm_create_spapr_tce_iommu create_tce_iommu;
> >+struct kvm *kvm = filp->private_data;
> >+
> >+r = -EFAULT;
> >+if (copy_from_user(_tce_iommu, argp,
> >+sizeof(create_tce_iommu)))
> >+goto out;
> >+r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm,
> >_tce_iommu);
> >+goto out;
> >+}
> > #endif /* CONFIG_PPC_BOOK3S_64 */
> >
> > #ifdef CONFIG_KVM_BOOK3S_64_HV
> >diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >index 5a2afda..450c82a 100644
> >--- a/include/uapi/linux/kvm.h
> >+++ b/include/uapi/linux/kvm.h
> >@@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
> > #define KVM_CAP_PPC_RTAS 91
> > #define KVM_CAP_IRQ_XICS 92
> > #define KVM_CAP_SPAPR_MULTITCE (0x11 + 89)
> >+#define KVM_CAP_SPAPR_TCE_IOMMU (0x11 + 90)
>
> Hmm...
Ah, yeah, that needs to be fixed. Those were interim numbers so that
we didn't have to keep changing our internal trees as new upstream
ioctls got added to the list. We need to get a proper number for the
merge, though.
> >@@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
> > #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
> >kvm_device_attr)
> > #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
> >kvm_device_attr)
> >
> >+/* ioctl for SPAPR TCE IOMMU */
> >+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
> >kvm_create_spapr_tce_iommu)
>
> Shouldn't this go under the vm ioctl section?
>
> -Scott
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
Re: [PATCH 4/4] mem-hotplug: Do not free LOCAL_NODE_DATA pages to buddy system in hot-remove procedure.
On 2013/5/24 17:30, Tang Chen wrote:
> In memory hot-remove procedure, we free pagetable pages to buddy system.
> But for local pagetable pages, do not free them to buddy system because
> they were skipped in offline procedure. The memory block they reside in
> could have been offlined, and we won't offline it again.
>
> Signed-off-by: Tang Chen
> ---
> mm/memory_hotplug.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 21d6fcb..c30e819 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -119,6 +119,14 @@ void __ref put_page_bootmem(struct page *page)
> INIT_LIST_HEAD(>lru);
>
> /*
> + * Do not free pages with local node kernel data (for now, just
> + * local pagetables) to the buddy system because we skipped
> + * these pages when offlining the corresponding block.
> + */
> + if (type == LOCAL_NODE_DATA)
> + return;
Hi Tang,
I think this should be check in free_pagetable(), like:
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 474e28f..08fe80e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -725,7 +725,7 @@ static void __meminit free_pagetable(struct page *page, int
order)
if (magic == SECTION_INFO || magic == MIX_SECTION_INFO) {
while (nr_pages--)
put_page_bootmem(page++);
- } else
+ } else if (magic != LOCAL_NODE_DATA)
__free_pages_bootmem(page, order);
} else
free_pages((unsigned long)page_address(page), order);
Thanks,
Jianguo Wu.
> +
> + /*
>* Please refer to comment for __free_pages_bootmem()
>* for why we serialize here.
>*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] ftrace/rcu: Prevent function tracer from calling into rcu debug checks
I was testing a config for one bug and triggered a livelock lockup. A
NMI watchdog dump showed what was happening:
[ 65.972000] NMI backtrace for cpu 2
[ 65.972000] CPU: 2 PID: 48 Comm: kworker/2:1 Not tainted 3.10.0-rc2-test+
#151
[ 65.972000] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To
be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
[ 65.972000] task: 880078dc2140 ti: 880078dc4000 task.ti:
880078dc4000
[ 65.972000] RIP: 0010:[] []
ftrace_ops_list_func+0x144/0x151
[ 65.972000] RSP: :880078dc5ac8 EFLAGS: 0006
[ 65.972000] RAX: 8000 RBX: 0001 RCX: 000f
[ 65.972000] RDX: 0002 RSI: 810c0e9f RDI: 810b73f7
[ 65.972000] RBP: 880078dc5af8 R08: 880078dc5be0 R09: 880078dc5bb0
[ 65.972000] R10: 81a3c730 R11: 0001 R12: 8000
[ 65.972000] R13: 810b73f7 R14: R15: 810c0e9f
[ 65.972000] FS: () GS:88007aa0()
knlGS:
[ 65.972000] CS: 0010 DS: ES: CR0: 8005003b
[ 65.972000] CR2: 0168 CR3: 01a0b000 CR4: 07e0
[ 65.972000] DR0: DR1: DR2:
[ 65.972000] DR3: DR6: 0ff0 DR7: 0400
[ 65.972000] Stack:
[ 65.972000] 880078d97480 0001 810b9148
880078d97480
[ 65.972000] 810bb6ba 880078dc5bd0
814fa7c0
[ 65.972000] 810bb6ba 880078dc5c00
814fa7c0
[ 65.972000] Call Trace:
[ 65.972000] [] ? check_for_new_grace_period+0x115/0x115
[ 65.972000] [] ? rcu_note_context_switch+0x20e/0x260
[ 65.972000] [] ftrace_call+0x5/0x2f
[ 65.972000] [] ? rcu_note_context_switch+0x20e/0x260
[ 65.972000] [] ? ftrace_call+0x5/0x2f
[ 65.972000] [] ? rcu_is_cpu_idle+0x5/0x69
[ 65.972000] [] ? debug_lockdep_rcu_enabled+0x5/0x35
[ 65.972000] [] ? rcu_is_cpu_idle+0x5/0x69
[ 65.972000] [] ? rcu_read_lock_held+0x19/0x3c
[ 65.972000] [] ftrace_ops_test+0x47/0x93
[ 65.972000] [] ? check_for_new_grace_period+0x115/0x115
[ 65.972000] [] ftrace_ops_list_func+0xcc/0x151
[ 65.972000] [] ftrace_call+0x5/0x2f
[ 65.972000] [] ? ftrace_ops_list_func+0x11f/0x151
[ 65.972000] [] ? rcu_note_context_switch+0x206/0x260
[ 65.972000] [] ? rcu_preempt_qs+0x5/0x53
[ 65.972000] [] ? trace_hardirqs_off+0xd/0xf
[ 65.972000] [] ? rcu_preempt_qs+0x5/0x53
[ 65.972000] [] ? rcu_note_context_switch+0x20e/0x260
[ 65.972000] [] ? schedule+0x64/0x66
[ 65.972000] [] __schedule+0x67/0x710
[ 65.972000] [] ? worker_thread+0x1e9/0x1f3
[ 65.972000] [] ? worker_thread+0x1e9/0x1f3
[ 65.972000] [] schedule+0x64/0x66
[ 65.972000] [] worker_thread+0x1ee/0x1f3
[ 65.972000] [] ? rescuer_thread+0x26c/0x26c
[ 65.972000] [] kthread+0xb1/0xb9
[ 65.972000] [] ? finish_task_switch+0x7c/0xf8
[ 65.972000] [] ? __init_kthread_worker+0x59/0x59
[ 65.972000] [] ret_from_fork+0x7c/0xb0
[ 65.972000] [] ? __init_kthread_worker+0x59/0x59
What happened was that ftrace's function tracer uses
hlist_for_each_entry_rcu() which uses rcu_dereference_raw(), and also
calls rcu_dereference_raw() directly. As this macro is defined as
rcu_dereference_check() and will call rcu_read_lock_sched_held() which
does various rcu checks as well as lockdep and such, when it happens for
*every* function call in the kernel it slows the system down where it
can live lock (interrupts taking too long to finish, before another
interrupt is triggered).
To give an idea of the abuse that function tracing is taking, every
function that is traced can do the following:
in __ftrace_ops_list_func() we have:
do_for_each_ftrace_op(op, ftrace_ops_list) {
if (ftrace_ops_test(op, ip))
op->func(ip, parent_ip, op, regs);
} while_for_each_ftrace_op(op);
Where:
#define do_for_each_ftrace_op(op, list) \
op = rcu_dereference_raw(list); \
do
and
#define while_for_each_ftrace_op(op)\
while (likely(op = rcu_dereference_raw((op)->next)) && \
unlikely((op) != _list_end))
And ftrace_ops_test() has:
filter_hash = rcu_dereference_raw(ops->filter_hash);
notrace_hash = rcu_dereference_raw(ops->notrace_hash);
if ((ftrace_hash_empty(filter_hash) ||
ftrace_lookup_ip(filter_hash, ip)) &&
(ftrace_hash_empty(notrace_hash) ||
!ftrace_lookup_ip(notrace_hash, ip)))
ret = 1;
Where ftrace_lookup_ip() has:
hlist_for_each_entry_rcu(entry, hhd, hlist) {
Now that is 6 calls to rcu_dereference_raw() that happens for every
single function that is traced! And this doesn't count possibly more by
the callbacks that were registered by
Re: [PATCH 2/4] mem-hotplug: Skip LOCAL_NODE_DATA pages in memory offline procedure.
On 2013/5/24 17:30, Tang Chen wrote:
> In memory offline procedure, skip pages marked as LOCAL_NODE_DATA.
> For now, this kind of pages are used to store local node pagetables.
>
> The minimum unit of memory online/offline is a memory block. In a
> block, the movable pages will be offlined as usual (unmapped and
> isolated), and the pagetable pages will be skipped. After the iteration
> of all page, the block will be set as offline, but the kernel can
> still access the pagetable pages. This is user transparent.
>
> Signed-off-by: Tang Chen
> ---
> mm/page_alloc.c | 18 --
> mm/page_isolation.c |6 ++
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 557b21b..73b8f0b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5701,11 +5701,18 @@ bool has_unmovable_pages(struct zone *zone, struct
> page *page, int count,
> pfn = page_to_pfn(page);
> for (found = 0, iter = 0; iter < pageblock_nr_pages; iter++) {
> unsigned long check = pfn + iter;
> + unsigned long magic;
>
> if (!pfn_valid_within(check))
> continue;
>
> page = pfn_to_page(check);
> +
> + /* Skip pages storing local node kernel data. */
> + magic = (unsigned long)page->lru.next;
> + if (magic == LOCAL_NODE_DATA)
Hi Tang,
I think can define this as a macro, and can be reused in the other places.
Thanks,
Jianguo Wu.
> + continue;
> +
> /*
>* We can't use page_count without pin a page
>* because another CPU can free compound page.
> @@ -6029,8 +6036,7 @@ __offline_isolated_pages(unsigned long start_pfn,
> unsigned long end_pfn)
> struct page *page;
> struct zone *zone;
> int order, i;
> - unsigned long pfn;
> - unsigned long flags;
> + unsigned long pfn, flags, magic;
> /* find the first valid pfn */
> for (pfn = start_pfn; pfn < end_pfn; pfn++)
> if (pfn_valid(pfn))
> @@ -6046,6 +6052,14 @@ __offline_isolated_pages(unsigned long start_pfn,
> unsigned long end_pfn)
> continue;
> }
> page = pfn_to_page(pfn);
> +
> + /* Skip pages storing local node kernel data. */
> + magic = (unsigned long)page->lru.next;
> + if (magic == LOCAL_NODE_DATA) {
> + pfn++;
> + continue;
> + }
> +
> /*
>* The HWPoisoned page may be not in buddy system, and
>* page_count() is not 0.
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 383bdbb..fb60a27 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -174,6 +174,7 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
> unsigned long end_pfn,
> bool skip_hwpoisoned_pages)
> {
> struct page *page;
> + unsigned long magic;
>
> while (pfn < end_pfn) {
> if (!pfn_valid_within(pfn)) {
> @@ -181,6 +182,8 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
> unsigned long end_pfn,
> continue;
> }
> page = pfn_to_page(pfn);
> + magic = (unsigned long)page->lru.next;
> +
> if (PageBuddy(page)) {
> /*
>* If race between isolatation and allocation happens,
> @@ -208,6 +211,9 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
> unsigned long end_pfn,
>*/
> pfn++;
> continue;
> + } else if (magic == LOCAL_NODE_DATA) {
> + pfn++;
> + continue;
> }
> else
> break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: xhci: Use non-interruptible sleep for XHCI commands
The XHCI stack usually uses wait_for_completion_interruptible_timeout()
to wait for the completion of an XHCI command, and treats both timeouts
and interruptions as errors. This is a bad idea, since these commands
are often essential for the correct operation of the USB stack, and
their failure can leave devices in a misconfigured and/or unusable
state. While a timeout probably means a real problem that needs to be
dealt with, a random signal to the controlling user-space process should
not cause such harsh consequences.
This patch changes that behavior to use uninterruptible waits instead.
It fixes an easy to reproduce bug that occurs when you kill -9 a
process that reads from a UVC camera. The UVC driver's release code
tries to set the camera's alternate setting back to 0, but the lingering
SIGKILL instantly aborts any Stop Endpoint or Configure Endpoint command
sent to the xHC. The code dies halfway through the bandwidth allocation
process, leaving the device in an active configuration and preventing
future access to it due to the now out-of-sync bandwidth calculation.
This patch should be backported to kernels as far 2.6.31 that contain
the commit 3ffbba9511b4148cbe1f6b6238686adaeaca8feb "USB: xhci: Allocate
and address USB devices".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-hub.c | 7 +++
drivers/usb/host/xhci.c | 26 +++---
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 187a3ec..c1bcfa8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -293,12 +293,11 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_unlock_irqrestore(>lock, flags);
/* Wait for last stop endpoint command to finish */
- timeleft = wait_for_completion_interruptible_timeout(
+ timeleft = wait_for_completion_timeout(
cmd->completion,
- USB_CTRL_SET_TIMEOUT);
+ XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft <= 0) {
- xhci_warn(xhci, "%s while waiting for stop endpoint command\n",
- timeleft == 0 ? "Timeout" : "Signal");
+ xhci_warn(xhci, "Timeout while waiting for Stop Endpoint\n");
spin_lock_irqsave(>lock, flags);
/* The timeout might have raced with the event ring handler, so
* only delete from the list if the item isn't poisoned.
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b4aa79d..302f992 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2613,15 +2613,14 @@ static int xhci_configure_endpoint(struct xhci_hcd
*xhci,
spin_unlock_irqrestore(>lock, flags);
/* Wait for the configure endpoint command to complete */
- timeleft = wait_for_completion_interruptible_timeout(
+ timeleft = wait_for_completion_timeout(
cmd_completion,
XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft <= 0) {
- xhci_warn(xhci, "%s while waiting for %s command\n",
- timeleft == 0 ? "Timeout" : "Signal",
+ xhci_warn(xhci, "Timeout while waiting for %s\n",
ctx_change == 0 ?
- "configure endpoint" :
- "evaluate context");
+ "Configure Endpoint" :
+ "Evaluate Context");
/* cancel the configure endpoint command */
ret = xhci_cancel_cmd(xhci, command, cmd_trb);
if (ret < 0)
@@ -3399,12 +3398,11 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd,
struct usb_device *udev)
spin_unlock_irqrestore(>lock, flags);
/* Wait for the Reset Device command to finish */
- timeleft = wait_for_completion_interruptible_timeout(
+ timeleft = wait_for_completion_timeout(
reset_device_cmd->completion,
- USB_CTRL_SET_TIMEOUT);
+ XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft <= 0) {
- xhci_warn(xhci, "%s while waiting for reset device command\n",
- timeleft == 0 ? "Timeout" : "Signal");
+ xhci_warn(xhci, "Timeout while waiting for Reset Device\n");
spin_lock_irqsave(>lock, flags);
/* The timeout might have raced with the event ring handler, so
* only delete from the list if the item isn't poisoned.
@@ -3588,11 +3586,10 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct
usb_device *udev)
spin_unlock_irqrestore(>lock, flags);
/* XXX: how much time for xHC slot assignment? */
- timeleft = wait_for_completion_interruptible_timeout(>addr_dev,
+ timeleft =
[PATCH] usb: xhci: Fix Command Ring Stopped Event handling
The current XHCI code treats a command completion event with the
COMP_CMD_STOP code as a slightly different version of COMP_CMD_ABORT. In
particular, it puts the pointed-to command TRB through the normal
command completion handlers. This is not how this event works.
As XHCI spec 4.6.1.1 describes, unlike other command completion events
Command Ring Stopped sets the Command TRB Pointer to the *current*
Command Ring Dequeue Pointer. This is the command TRB that the XHCI will
execute next, and not a command that has already been executed. The
driver's internal command ring dequeue pointer should not be increased
after this event, since it does not really mark a command completion...
it's just a hint for the driver that execution is stopped now and where
it will be picked up again if the ring gets restarted.
This patch gets rid of the handle_stopped_command_ring() function and
splits its behavior into two distinct parts for COMP_CMD_STOP and
COMP_CMD_ABORT events. It ensures that the former no longer messes with
the dequeue pointer, while the latter's behavior is unchanged. This
prevents the hardware and software dequeue pointer from going out of
sync during command cancellations, which can lead to a variety of
problems (up to a total HCD death if the next command after the one that
was cancelled is Stop Endpoint, and the stop_endpoint_watchdog won't see
the command's completion because it got skipped by the software dequeue
pointer).
This patch should be backported to kernels as far as 3.0 that contain
the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI: handle
command after aborting the command ring".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 85 +---
1 file changed, 33 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1969c00..98b7673 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1314,47 +1314,11 @@ static int xhci_search_cmd_trb_in_cd_list(struct
xhci_hcd *xhci,
return 0;
}
-/*
- * If the cmd_trb_comp_code is COMP_CMD_ABORT, we just check whether the
- * trb pointed by the command ring dequeue pointer is the trb we want to
- * cancel or not. And if the cmd_trb_comp_code is COMP_CMD_STOP, we will
- * traverse the cancel_cmd_list to trun the all of the commands according
- * to command descriptor to NO-OP trb.
- */
-static int handle_stopped_cmd_ring(struct xhci_hcd *xhci,
- int cmd_trb_comp_code)
-{
- int cur_trb_is_good = 0;
-
- /* Searching the cmd trb pointed by the command ring dequeue
-* pointer in command descriptor list. If it is found, free it.
-*/
- cur_trb_is_good = xhci_search_cmd_trb_in_cd_list(xhci,
- xhci->cmd_ring->dequeue);
-
- if (cmd_trb_comp_code == COMP_CMD_ABORT)
- xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
- else if (cmd_trb_comp_code == COMP_CMD_STOP) {
- /* traversing the cancel_cmd_list and canceling
-* the command according to command descriptor
-*/
- xhci_cancel_cmd_in_cd_list(xhci);
-
- xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
- /*
-* ring command ring doorbell again to restart the
-* command ring
-*/
- if (xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue)
- xhci_ring_cmd_db(xhci);
- }
- return cur_trb_is_good;
-}
-
static void handle_cmd_completion(struct xhci_hcd *xhci,
struct xhci_event_cmd *event)
{
int slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
+ int comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
u64 cmd_dma;
dma_addr_t cmd_dequeue_dma;
struct xhci_input_control_ctx *ctrl_ctx;
@@ -1377,16 +1341,34 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
return;
}
- if ((GET_COMP_CODE(le32_to_cpu(event->status)) == COMP_CMD_ABORT) ||
- (GET_COMP_CODE(le32_to_cpu(event->status)) == COMP_CMD_STOP)) {
- /* If the return value is 0, we think the trb pointed by
-* command ring dequeue pointer is a good trb. The good
-* trb means we don't want to cancel the trb, but it have
-* been stopped by host. So we should handle it normally.
-* Otherwise, driver should invoke inc_deq() and return.
-*/
- if (handle_stopped_cmd_ring(xhci,
- GET_COMP_CODE(le32_to_cpu(event->status {
+ /*
+* Command Ring Stopped events point at the xHC's *current* dequeue
+* pointer, i.e. the next command that will be executed. That TRB may
+* or may not have been issued yet. Just overwrite all canceled commands
+* with NOOPs and restart the ring,
Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Hello Eric, 于 2013年05月25日 06:44, Eric W. Biederman 写道: > Vivek Goyal writes: > >> On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote: >>> Hello Vivek, >>> >>> On Fri, 24 May 2013 10:36:44 -0400 >>> Vivek Goyal wrote: >>> >>> [snip] >>> Sorry, I don't understand the problem. If we swapped low memory and crash reserved memory, that should have been taken care by prepared ELF headers so that we map the right pfns. In x86 we swap 640K of low memory with 640K of memory in reserved and we take care of this by preparing elf headers accordingly. So why s390 can't do the same thing? >>> >>> I am not sure if I understand this. Currently we create the ELF >>> header in a way that we have virtual=real. In the copy_oldmem_page() we >>> do the swap so that for the /proc/vmcore code it looks like contiguous >>> non-swapped memory. >>> >>> One reason why I thought this was necessary was that /dev/oldmem >>> also uses the function and it should provide linear memory access like >>> it is on the live system with /dev/mem. >>> >>> Is that implementation incorrect? >> >> [ CC Andrew. Keep him in loop for all kernel kdump patches as all kdump >> patches are routed through him ]. >> >> [ CC Eric Biederman ] >> >> Looking at the code, looks like /dev/oldmem is broken. It does not know >> anything about swap of any of the memory areas and it will simply >> return the contents of page frame asked. And this has been like this >> since the beginning. >> >> I have always questioned the utility of /dev/oldmem. Atleast I am not >> aware of any tool making use of it. >> >> If we want to fix it, then somebow all the swapped memory region info >> needs to be communicated to second kernel so that read_oldmem() can >> do the mapping correctly and we really don't have any mechanism for >> that. (I am assuming that in s390 you must have hardcoded the regions >> of memory which are always swapped). >> >> As /proc/vmcore is the most used and useful interface, I prefer that >> we swap memory and put that info in elf headers. For /dev/oldme, I >> don't mind if we leave it as it is. If somebody really cares, then >> I guess we need to write a new command line option which /dev/mem >> can parse and which tells it about swaps so that /dev/oldmem can >> map things correctly. (This is better than hardcoding things). >> >> Eric, do you have any thoughts on this. > > I don't think anyone actually uses /dev/oldmem. I would like to cite > the s390 confusion as proof but I don't think that quite works. > > I think the solution is for someone to send a patch removing /dev/oldmem > as an unused piece of code. That will also move us in the direction of > resolving HPAs concerns. I think I can try this. > > The function copy_oldmem_page also concerns me. I don't have a clue why > we duplicate that function on every architecutre in a slightly different > form. There should be enough abstractions in the kernel to make that > unnecessary. I would be glad to see that function go, and remove the > possibility of confusion that happened on s390. You mean we should have a common copy_oldmem_page for all architectures? And just like vivek said above, for s390, we should put the swap info in the elf headers instead of doing that in copy_oldmem_page. Zhang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ata1.00: failed to enable AA (error_mask=0x1)
Hello, Please advise if you can help me with bellow problem. I receive the following messages on boot: May 25 01:52:37 Leny kernel: ata1.00: failed to enable AA (error_mask=0x1) May 25 01:52:37 Leny kernel: ata1.00: ATA-8: ST500LM012 HN-M500MBB, 2AR10001, max UDMA/100 May 25 01:52:37 Leny kernel: ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) May 25 01:52:37 Leny kernel: ata1.00: failed to enable AA (error_mask=0x1) May 25 01:52:37 Leny kernel: ata1.00: configured for UDMA/100 May 25 01:52:37 Leny kernel: scsi 0:0:0:0: Direct-Access ATA ST500LM012 HN-M5 2AR1 PQ: 0 ANSI: 5 lspci shows the following: 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05) Subsystem: Lenovo Device 3975 Kernel driver in use: ahci Kernel modules: ahci I have read topics varying from "it's nothing" to "your HDD will fail soon", so I really do not know what is this. Please cc me in the reply if you can. Thank you very much. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 13/14] misc/ep93xx_pwm: use module_platform_driver()
Add the (*probe) function to the platform_driver and use the
module_platform_driver() macro to initialize the module.
Remove the unnecessary __init and __exit tags.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index dd570d1..b5ad0c6 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -215,7 +215,7 @@ static const struct attribute_group ep93xx_pwm_sysfs_files
= {
.attrs = ep93xx_pwm_attrs,
};
-static int __init ep93xx_pwm_probe(struct platform_device *pdev)
+static int ep93xx_pwm_probe(struct platform_device *pdev)
{
struct ep93xx_pwm *pwm;
struct resource *res;
@@ -257,7 +257,7 @@ static int __init ep93xx_pwm_probe(struct platform_device
*pdev)
return 0;
}
-static int __exit ep93xx_pwm_remove(struct platform_device *pdev)
+static int ep93xx_pwm_remove(struct platform_device *pdev)
{
struct ep93xx_pwm *pwm = platform_get_drvdata(pdev);
@@ -274,10 +274,10 @@ static struct platform_driver ep93xx_pwm_driver = {
.name = "ep93xx-pwm",
.owner = THIS_MODULE,
},
- .remove = __exit_p(ep93xx_pwm_remove),
+ .probe = ep93xx_pwm_probe,
+ .remove = ep93xx_pwm_remove,
};
-
-module_platform_driver_probe(ep93xx_pwm_driver, ep93xx_pwm_probe);
+module_platform_driver(ep93xx_pwm_driver);
MODULE_AUTHOR("Matthieu Crapet , "
"H Hartley Sweeten ");
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/14] misc/ep93xx_pwm: remove ep93xx_pwm_normal() inline function
This is a simple wrapper around writel(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 5193faf..cdc2ffc 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -49,11 +49,6 @@ static inline int ep93xx_pwm_is_enabled(struct ep93xx_pwm
*pwm)
return readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1;
}
-static inline void ep93xx_pwm_normal(struct ep93xx_pwm *pwm)
-{
- writel(0x0, pwm->mmio_base + EP93XX_PWMx_INVERT);
-}
-
static inline int ep93xx_pwm_is_inverted(struct ep93xx_pwm *pwm)
{
return readl(pwm->mmio_base + EP93XX_PWMx_INVERT) & 0x1;
@@ -203,7 +198,7 @@ static ssize_t ep93xx_pwm_set_invert(struct device *dev,
return -EINVAL;
if (val == 0)
- ep93xx_pwm_normal(pwm);
+ writel(0x0, pwm->mmio_base + EP93XX_PWMx_INVERT);
else if (val == 1)
writel(0x1, pwm->mmio_base + EP93XX_PWMx_INVERT);
else
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Don't let mmio fallback to must-only, if ioport fails with must+optional
On Fri, May 24, 2013 at 10:25 AM, Bjorn Helgaas wrote: > > The problem we're trying to solve is that when allocation for type X > fails, we retry allocation for type Y. > > This patch handles IO specially. I think it basically says, "if we > only have IO allocation failures, don't retry MEM allocation." But a > clean strategy would also avoid retrying IO allocation if we only had > MEM allocation failures. Well, that will make it little bit complicated as v3 that is sent in another mail. Need to separate ioport, mmio, mmio pref three types. 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/
Re: [PATCH] fs: ecryptfs: fixed msync to flush data
On 2013-05-23 14:31:43, Paul Taysom wrote:
> When msync is called on a memory mapped file, that
> data is not flushed to the disk.
>
> In Linux, msync calls fsync for the file. For ecryptfs,
> fsync just calls the lower level file system's fsync.
> Changed the ecryptfs fsync code to call filemap_write_and_wait
> before calling the lower level fsync.
>
> Addresses the problem described in http://crbug.com/239536
>
> Signed-off-by: Paul Taysom
> ---
Thanks, Paul! I've pushed this to the eCryptfs next branch:
http://git.kernel.org/cgit/linux/kernel/git/tyhicks/ecryptfs.git/log/?h=next
I also marked it for the stable kernel as affecting 3.6 and newer.
As a side note, we need to make ecryptfs_fsync() more selective about
what gets synced by using filemap_write_and_wait_range() and
vfs_fsync_range(). Since we're already calling vfs_fsync() for the
entire lower file, this patch is good enough for now.
Tyler
> fs/ecryptfs/file.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
> index 201f0a0..16f509d 100644
> --- a/fs/ecryptfs/file.c
> +++ b/fs/ecryptfs/file.c
> @@ -295,6 +295,7 @@ static int ecryptfs_release(struct inode *inode, struct
> file *file)
> static int
> ecryptfs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
> {
> + filemap_write_and_wait(file->f_mapping);
> return vfs_fsync(ecryptfs_file_to_lower(file), datasync);
> }
>
> --
> 1.8.2.1
>
signature.asc
Description: Digital signature
[PATCH v3] PCI: Don't let mmio fallback to must-only, if ioport fails with must+optional
BenH reported that there is some assign unassigned resource problem
in powerpc.
It turns out after
| commit 0c5be0cb0edfe3b5c4b62eac68aa2aa15ec681af
| Date: Thu Feb 23 19:23:29 2012 -0800
|
|PCI: Retry on IORESOURCE_IO type allocations
even the root bus does not have io port range, it will keep retrying
to realloc with mmio.
Current retry logic is : try with must+optional at first, and if
it fails with any ioport or mmio, it will try must then try to extend
must with optional. The reassign will put extended mmio or pref mmio
in the middle of parent resource range.
That will prevent other sibling resources to get must-have resources
or get extended properly.
We can check fail type to see if can we need fall back to must-have
only, that will keep not needed release resource to be must+optional.
Separate three resource type checking if we need to release
assigned resource after requested + add_size try.
1. if there is io port assign fail, will release assigned io port.
2. if there is pref mmio assign fail, release assigned pref mmio.
if assigned pref mmio's parent is non-pref mmio and there
is non-pref mmio assign fail, will release that assigned pref mmio.
3. if there is non-pref mmio assign fail or pref mmio assigned fail,
will release assigned non-pref mmio.
This will be become more often when we have x86 8 sockets or 32 sockets
system, and those system will have one root bus per socket.
They will have some root buses do not have ioport range.
-v2: need to remove assigned entries from optional list too.
-v3: not just checking ioport related, requested by Bjorn.
Reported-by: Benjamin Herrenschmidt
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 70 +++-
1 file changed, 69 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/pci/setup-bus.c
===
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -300,6 +300,48 @@ static void assign_requested_resources_s
}
}
+static unsigned long pci_fail_res_type_mask(struct list_head *fail_head)
+{
+ struct pci_dev_resource *fail_res;
+ unsigned long mask = 0;
+
+ /* check failed type */
+ list_for_each_entry(fail_res, fail_head, list)
+ mask |= fail_res->flags;
+
+ /*
+* one pref failed resource will set IORESOURCE_MEM,
+* as we can allocate pref in non-pref range.
+* Will release all asssigned non-pref sibling resources
+* according to that bit.
+*/
+ return mask & (IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH);
+}
+
+static bool pci_need_to_release(unsigned long mask, struct resource *res)
+{
+ if (res->flags & IORESOURCE_IO)
+ return !!(mask & IORESOURCE_IO);
+
+ /* check pref at first */
+ if (res->flags & IORESOURCE_PREFETCH) {
+ if (mask & IORESOURCE_PREFETCH)
+ return true;
+ /* count pref if its parent is non-pref */
+ else if ((mask & IORESOURCE_MEM) &&
+!(res->parent->flags & IORESOURCE_PREFETCH))
+ return true;
+ else
+ return false;
+ }
+
+ if (res->flags & IORESOURCE_MEM)
+ return !!(mask & IORESOURCE_MEM);
+
+ /* should not get here */
+ return false;
+}
+
static void __assign_resources_sorted(struct list_head *head,
struct list_head *realloc_head,
struct list_head *fail_head)
@@ -312,11 +354,24 @@ static void __assign_resources_sorted(st
* if could do that, could get out early.
* if could not do that, we still try to assign requested at first,
*then try to reassign add_size for some resources.
+*
+* Separate three resource type checking if we need to release
+* assigned resource after requested + add_size try.
+* 1. if there is io port assign fail, will release assigned
+* io port.
+* 2. if there is pref mmio assign fail, release assigned
+* pref mmio.
+* if assigned pref mmio's parent is non-pref mmio and there
+* is non-pref mmio assign fail, will release that assigned
+* pref mmio.
+* 3. if there is non-pref mmio assign fail or pref mmio
+* assigned fail, will release assigned non-pref mmio.
*/
LIST_HEAD(save_head);
LIST_HEAD(local_fail_head);
struct pci_dev_resource *save_res;
- struct pci_dev_resource *dev_res;
+ struct pci_dev_resource *dev_res, *tmp_res;
+ unsigned long fail_type;
/* Check if optional add_size is there */
if (!realloc_head || list_empty(realloc_head))
@@ -348,6 +403,19 @@ static void __assign_resources_sorted(st
[PATCH 14/14] misc/ep93xx_pwm: use kstrtol instead of strict_strtol
strict_strtol is deprecated in favor of kstrtol. Signed-off-by: H Hartley Sweeten Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Ryan Mallon Cc: Matthieu Crapet --- drivers/misc/ep93xx_pwm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c index b5ad0c6..cdb67a9 100644 --- a/drivers/misc/ep93xx_pwm.c +++ b/drivers/misc/ep93xx_pwm.c @@ -92,7 +92,7 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev, long val; int err; - err = strict_strtol(buf, 10, ); + err = kstrtol(buf, 10, ); if (err) return -EINVAL; @@ -145,7 +145,7 @@ static ssize_t ep93xx_pwm_set_duty_percent(struct device *dev, long val; int err; - err = strict_strtol(buf, 10, ); + err = kstrtol(buf, 10, ); if (err) return -EINVAL; @@ -179,7 +179,7 @@ static ssize_t ep93xx_pwm_set_invert(struct device *dev, long val; int err; - err = strict_strtol(buf, 10, ); + err = kstrtol(buf, 10, ); if (err) return -EINVAL; -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/14] misc/ep93xx_pwm: remove ep93xx_pwm_is_inverted() inline function
This is a simple wrapper around readl(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 3dd2006..dd570d1 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -39,11 +39,6 @@ struct ep93xx_pwm {
u32 duty_percent;
};
-static inline int ep93xx_pwm_is_inverted(struct ep93xx_pwm *pwm)
-{
- return readl(pwm->mmio_base + EP93XX_PWMx_INVERT) & 0x1;
-}
-
/*
* /sys/devices/platform/ep93xx-pwm.N
* /min_freq read-only minimum pwm output frequency
@@ -171,8 +166,9 @@ static ssize_t ep93xx_pwm_get_invert(struct device *dev,
{
struct platform_device *pdev = to_platform_device(dev);
struct ep93xx_pwm *pwm = platform_get_drvdata(pdev);
+ int inverted = readl(pwm->mmio_base + EP93XX_PWMx_INVERT) & 0x1;
- return sprintf(buf, "%d\n", ep93xx_pwm_is_inverted(pwm));
+ return sprintf(buf, "%d\n", inverted);
}
static ssize_t ep93xx_pwm_set_invert(struct device *dev,
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/14] misc/ep93xx_pwm: remove ep93xx_pwm_read_tc() inline function
This is a simple wrapper around readl(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index cdc2ffc..6f48375 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -39,11 +39,6 @@ struct ep93xx_pwm {
u32 duty_percent;
};
-static inline u16 ep93xx_pwm_read_tc(struct ep93xx_pwm *pwm)
-{
- return readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
-}
-
static inline int ep93xx_pwm_is_enabled(struct ep93xx_pwm *pwm)
{
return readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1;
@@ -91,7 +86,7 @@ static ssize_t ep93xx_pwm_get_freq(struct device *dev,
if (ep93xx_pwm_is_enabled(pwm)) {
unsigned long rate = clk_get_rate(pwm->clk);
- u16 term = ep93xx_pwm_read_tc(pwm);
+ u16 term = readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
return sprintf(buf, "%ld\n", rate / (term + 1));
} else {
@@ -122,7 +117,7 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev,
if (val < 1)
val = 1;
- term = ep93xx_pwm_read_tc(pwm);
+ term = readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
duty = ((val + 1) * pwm->duty_percent / 100) - 1;
/* If pwm is running, order is important */
@@ -165,7 +160,7 @@ static ssize_t ep93xx_pwm_set_duty_percent(struct device
*dev,
return -EINVAL;
if (val > 0 && val < 100) {
- u32 term = ep93xx_pwm_read_tc(pwm);
+ u32 term = readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
u32 duty = ((term + 1) * val / 100) - 1;
writel(duty, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/14] misc/ep93xx_pwm: remove ep93xx_pwm_is_enabled() inline function
This is a simple wrapper around readl(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 6f48375..3dd2006 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -39,11 +39,6 @@ struct ep93xx_pwm {
u32 duty_percent;
};
-static inline int ep93xx_pwm_is_enabled(struct ep93xx_pwm *pwm)
-{
- return readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1;
-}
-
static inline int ep93xx_pwm_is_inverted(struct ep93xx_pwm *pwm)
{
return readl(pwm->mmio_base + EP93XX_PWMx_INVERT) & 0x1;
@@ -84,7 +79,7 @@ static ssize_t ep93xx_pwm_get_freq(struct device *dev,
struct platform_device *pdev = to_platform_device(dev);
struct ep93xx_pwm *pwm = platform_get_drvdata(pdev);
- if (ep93xx_pwm_is_enabled(pwm)) {
+ if (readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1) {
unsigned long rate = clk_get_rate(pwm->clk);
u16 term = readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
@@ -129,7 +124,7 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev,
writel(val, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
- if (!ep93xx_pwm_is_enabled(pwm))
+ if (!readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1)
writel(0x1, pwm->mmio_base + EP93XX_PWMx_ENABLE);
} else {
return -EINVAL;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/14] misc/ep93xx_pwm: remove ep93xx_pwm_invert() inline function
This is a simple wrapper around writel(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 320d911..5193faf 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -49,11 +49,6 @@ static inline int ep93xx_pwm_is_enabled(struct ep93xx_pwm
*pwm)
return readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1;
}
-static inline void ep93xx_pwm_invert(struct ep93xx_pwm *pwm)
-{
- writel(0x1, pwm->mmio_base + EP93XX_PWMx_INVERT);
-}
-
static inline void ep93xx_pwm_normal(struct ep93xx_pwm *pwm)
{
writel(0x0, pwm->mmio_base + EP93XX_PWMx_INVERT);
@@ -210,7 +205,7 @@ static ssize_t ep93xx_pwm_set_invert(struct device *dev,
if (val == 0)
ep93xx_pwm_normal(pwm);
else if (val == 1)
- ep93xx_pwm_invert(pwm);
+ writel(0x1, pwm->mmio_base + EP93XX_PWMx_INVERT);
else
return -EINVAL;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/14] misc/ep93xx_pwm: remove ep93xx_pwm_disable() inline function
This is a simple wrapper around writel(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index cf42347..320d911 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -44,11 +44,6 @@ static inline u16 ep93xx_pwm_read_tc(struct ep93xx_pwm *pwm)
return readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
-static inline void ep93xx_pwm_disable(struct ep93xx_pwm *pwm)
-{
- writel(0x0, pwm->mmio_base + EP93XX_PWMx_ENABLE);
-}
-
static inline int ep93xx_pwm_is_enabled(struct ep93xx_pwm *pwm)
{
return readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1;
@@ -127,7 +122,7 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev,
return -EINVAL;
if (val == 0) {
- ep93xx_pwm_disable(pwm);
+ writel(0x0, pwm->mmio_base + EP93XX_PWMx_ENABLE);
} else if (val <= (clk_get_rate(pwm->clk) / 2)) {
u32 term, duty;
@@ -276,7 +271,7 @@ static int __init ep93xx_pwm_probe(struct platform_device
*pdev)
pwm->duty_percent = 50;
/* disable pwm at startup. Avoids zero value. */
- ep93xx_pwm_disable(pwm);
+ writel(0x0, pwm->mmio_base + EP93XX_PWMx_ENABLE);
writel(EP93XX_PWM_MAX_COUNT, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
writel(EP93XX_PWM_MAX_COUNT/2, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
@@ -290,7 +285,7 @@ static int __exit ep93xx_pwm_remove(struct platform_device
*pdev)
{
struct ep93xx_pwm *pwm = platform_get_drvdata(pdev);
- ep93xx_pwm_disable(pwm);
+ writel(0x0, pwm->mmio_base + EP93XX_PWMx_ENABLE);
clk_disable(pwm->clk);
sysfs_remove_group(>dev.kobj, _pwm_sysfs_files);
ep93xx_pwm_release_gpio(pdev);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/14] misc/ep93xx_pwm: remove ep93xx_pwm_enable() inline function
This is a simple wrapper around writel(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 7a13304..cf42347 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -44,11 +44,6 @@ static inline u16 ep93xx_pwm_read_tc(struct ep93xx_pwm *pwm)
return readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
-static inline void ep93xx_pwm_enable(struct ep93xx_pwm *pwm)
-{
- writel(0x1, pwm->mmio_base + EP93XX_PWMx_ENABLE);
-}
-
static inline void ep93xx_pwm_disable(struct ep93xx_pwm *pwm)
{
writel(0x0, pwm->mmio_base + EP93XX_PWMx_ENABLE);
@@ -155,7 +150,7 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev,
}
if (!ep93xx_pwm_is_enabled(pwm))
- ep93xx_pwm_enable(pwm);
+ writel(0x1, pwm->mmio_base + EP93XX_PWMx_ENABLE);
} else {
return -EINVAL;
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/14] misc/ep93xx_pwm: remove ep93xx_pwm_write_tc() inline function
This is a simple wrapper around writel(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 06f0c63..ab5a481 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -39,11 +39,6 @@ struct ep93xx_pwm {
u32 duty_percent;
};
-static inline void ep93xx_pwm_write_tc(struct ep93xx_pwm *pwm, u16 value)
-{
- writel(value, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
-}
-
static inline u16 ep93xx_pwm_read_tc(struct ep93xx_pwm *pwm)
{
return readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
@@ -157,11 +152,11 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev,
/* If pwm is running, order is important */
if (val > term) {
- ep93xx_pwm_write_tc(pwm, val);
+ writel(val, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
ep93xx_pwm_write_dc(pwm, duty);
} else {
ep93xx_pwm_write_dc(pwm, duty);
- ep93xx_pwm_write_tc(pwm, val);
+ writel(val, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
if (!ep93xx_pwm_is_enabled(pwm))
@@ -290,7 +285,7 @@ static int __init ep93xx_pwm_probe(struct platform_device
*pdev)
/* disable pwm at startup. Avoids zero value. */
ep93xx_pwm_disable(pwm);
- ep93xx_pwm_write_tc(pwm, EP93XX_PWM_MAX_COUNT);
+ writel(EP93XX_PWM_MAX_COUNT, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
ep93xx_pwm_write_dc(pwm, EP93XX_PWM_MAX_COUNT / 2);
clk_enable(pwm->clk);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/14] misc/ep93xx_pwm: remove ep93xx_pwm_write_dc() inline function
This is a simple wrapper around writel(), remove it.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index ab5a481..7a13304 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -44,11 +44,6 @@ static inline u16 ep93xx_pwm_read_tc(struct ep93xx_pwm *pwm)
return readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
-static inline void ep93xx_pwm_write_dc(struct ep93xx_pwm *pwm, u16 value)
-{
- writel(value, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
-}
-
static inline void ep93xx_pwm_enable(struct ep93xx_pwm *pwm)
{
writel(0x1, pwm->mmio_base + EP93XX_PWMx_ENABLE);
@@ -153,9 +148,9 @@ static ssize_t ep93xx_pwm_set_freq(struct device *dev,
/* If pwm is running, order is important */
if (val > term) {
writel(val, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
- ep93xx_pwm_write_dc(pwm, duty);
+ writel(duty, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
} else {
- ep93xx_pwm_write_dc(pwm, duty);
+ writel(duty, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
writel(val, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
@@ -191,7 +186,9 @@ static ssize_t ep93xx_pwm_set_duty_percent(struct device
*dev,
if (val > 0 && val < 100) {
u32 term = ep93xx_pwm_read_tc(pwm);
- ep93xx_pwm_write_dc(pwm, ((term + 1) * val / 100) - 1);
+ u32 duty = ((term + 1) * val / 100) - 1;
+
+ writel(duty, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
pwm->duty_percent = val;
return count;
}
@@ -286,7 +283,7 @@ static int __init ep93xx_pwm_probe(struct platform_device
*pdev)
/* disable pwm at startup. Avoids zero value. */
ep93xx_pwm_disable(pwm);
writel(EP93XX_PWM_MAX_COUNT, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
- ep93xx_pwm_write_dc(pwm, EP93XX_PWM_MAX_COUNT / 2);
+ writel(EP93XX_PWM_MAX_COUNT/2, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
clk_enable(pwm->clk);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/14] misc/ep93xx_pwm: remove ep93xx_pwm_{write,read}l() inline functions
These are simple wrappers around writel() and readl(). Remove them.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index af01fb9..06f0c63 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -39,61 +39,49 @@ struct ep93xx_pwm {
u32 duty_percent;
};
-static inline void ep93xx_pwm_writel(struct ep93xx_pwm *pwm,
- unsigned int val, unsigned int off)
-{
- writel(val, pwm->mmio_base + off);
-}
-
-static inline unsigned int ep93xx_pwm_readl(struct ep93xx_pwm *pwm,
- unsigned int off)
-{
- return readl(pwm->mmio_base + off);
-}
-
static inline void ep93xx_pwm_write_tc(struct ep93xx_pwm *pwm, u16 value)
{
- ep93xx_pwm_writel(pwm, value, EP93XX_PWMx_TERM_COUNT);
+ writel(value, pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
static inline u16 ep93xx_pwm_read_tc(struct ep93xx_pwm *pwm)
{
- return ep93xx_pwm_readl(pwm, EP93XX_PWMx_TERM_COUNT);
+ return readl(pwm->mmio_base + EP93XX_PWMx_TERM_COUNT);
}
static inline void ep93xx_pwm_write_dc(struct ep93xx_pwm *pwm, u16 value)
{
- ep93xx_pwm_writel(pwm, value, EP93XX_PWMx_DUTY_CYCLE);
+ writel(value, pwm->mmio_base + EP93XX_PWMx_DUTY_CYCLE);
}
static inline void ep93xx_pwm_enable(struct ep93xx_pwm *pwm)
{
- ep93xx_pwm_writel(pwm, 0x1, EP93XX_PWMx_ENABLE);
+ writel(0x1, pwm->mmio_base + EP93XX_PWMx_ENABLE);
}
static inline void ep93xx_pwm_disable(struct ep93xx_pwm *pwm)
{
- ep93xx_pwm_writel(pwm, 0x0, EP93XX_PWMx_ENABLE);
+ writel(0x0, pwm->mmio_base + EP93XX_PWMx_ENABLE);
}
static inline int ep93xx_pwm_is_enabled(struct ep93xx_pwm *pwm)
{
- return ep93xx_pwm_readl(pwm, EP93XX_PWMx_ENABLE) & 0x1;
+ return readl(pwm->mmio_base + EP93XX_PWMx_ENABLE) & 0x1;
}
static inline void ep93xx_pwm_invert(struct ep93xx_pwm *pwm)
{
- ep93xx_pwm_writel(pwm, 0x1, EP93XX_PWMx_INVERT);
+ writel(0x1, pwm->mmio_base + EP93XX_PWMx_INVERT);
}
static inline void ep93xx_pwm_normal(struct ep93xx_pwm *pwm)
{
- ep93xx_pwm_writel(pwm, 0x0, EP93XX_PWMx_INVERT);
+ writel(0x0, pwm->mmio_base + EP93XX_PWMx_INVERT);
}
static inline int ep93xx_pwm_is_inverted(struct ep93xx_pwm *pwm)
{
- return ep93xx_pwm_readl(pwm, EP93XX_PWMx_INVERT) & 0x1;
+ return readl(pwm->mmio_base + EP93XX_PWMx_INVERT) & 0x1;
}
/*
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/14] misc/ep93xx_pwm: use {read,write}* instead of __raw_* versions for io
The mmio_base is an ioremap'ed memory resource. The normal memory
io functions should be used not the __raw_* versions.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 36370b4..af01fb9 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -42,13 +42,13 @@ struct ep93xx_pwm {
static inline void ep93xx_pwm_writel(struct ep93xx_pwm *pwm,
unsigned int val, unsigned int off)
{
- __raw_writel(val, pwm->mmio_base + off);
+ writel(val, pwm->mmio_base + off);
}
static inline unsigned int ep93xx_pwm_readl(struct ep93xx_pwm *pwm,
unsigned int off)
{
- return __raw_readl(pwm->mmio_base + off);
+ return readl(pwm->mmio_base + off);
}
static inline void ep93xx_pwm_write_tc(struct ep93xx_pwm *pwm, u16 value)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/14] misc/ep93xx_pwm: use managed device resources
Use managed device resources to clean up the probe/remove.
Signed-off-by: H Hartley Sweeten
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Ryan Mallon
Cc: Matthieu Crapet
---
drivers/misc/ep93xx_pwm.c | 73 +--
1 file changed, 20 insertions(+), 53 deletions(-)
diff --git a/drivers/misc/ep93xx_pwm.c b/drivers/misc/ep93xx_pwm.c
index 9ba93f0..36370b4 100644
--- a/drivers/misc/ep93xx_pwm.c
+++ b/drivers/misc/ep93xx_pwm.c
@@ -273,50 +273,33 @@ static int __init ep93xx_pwm_probe(struct platform_device
*pdev)
{
struct ep93xx_pwm *pwm;
struct resource *res;
- int err;
+ int ret;
- err = ep93xx_pwm_acquire_gpio(pdev);
- if (err)
- return err;
+ pwm = devm_kzalloc(>dev, sizeof(*pwm), GFP_KERNEL);
+ if (!pwm)
+ return -ENOMEM;
- pwm = kzalloc(sizeof(struct ep93xx_pwm), GFP_KERNEL);
- if (!pwm) {
- err = -ENOMEM;
- goto fail_no_mem;
- }
+ pwm->clk = devm_clk_get(>dev, "pwm_clk");
+ if (IS_ERR(pwm->clk))
+ return PTR_ERR(pwm->clk);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- err = -ENXIO;
- goto fail_no_mem_resource;
- }
-
- res = request_mem_region(res->start, resource_size(res), pdev->name);
- if (res == NULL) {
- err = -EBUSY;
- goto fail_no_mem_resource;
- }
-
- pwm->mmio_base = ioremap(res->start, resource_size(res));
- if (pwm->mmio_base == NULL) {
- err = -ENXIO;
- goto fail_no_ioremap;
- }
-
- err = sysfs_create_group(>dev.kobj, _pwm_sysfs_files);
- if (err)
- goto fail_no_sysfs;
-
- pwm->clk = clk_get(>dev, "pwm_clk");
- if (IS_ERR(pwm->clk)) {
- err = PTR_ERR(pwm->clk);
- goto fail_no_clk;
+ pwm->mmio_base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(pwm->mmio_base))
+ return PTR_ERR(pwm->mmio_base);
+
+ ret = ep93xx_pwm_acquire_gpio(pdev);
+ if (ret)
+ return ret;
+
+ ret = sysfs_create_group(>dev.kobj, _pwm_sysfs_files);
+ if (ret) {
+ ep93xx_pwm_release_gpio(pdev);
+ return ret;
}
pwm->duty_percent = 50;
- platform_set_drvdata(pdev, pwm);
-
/* disable pwm at startup. Avoids zero value. */
ep93xx_pwm_disable(pwm);
ep93xx_pwm_write_tc(pwm, EP93XX_PWM_MAX_COUNT);
@@ -324,33 +307,17 @@ static int __init ep93xx_pwm_probe(struct platform_device
*pdev)
clk_enable(pwm->clk);
+ platform_set_drvdata(pdev, pwm);
return 0;
-
-fail_no_clk:
- sysfs_remove_group(>dev.kobj, _pwm_sysfs_files);
-fail_no_sysfs:
- iounmap(pwm->mmio_base);
-fail_no_ioremap:
- release_mem_region(res->start, resource_size(res));
-fail_no_mem_resource:
- kfree(pwm);
-fail_no_mem:
- ep93xx_pwm_release_gpio(pdev);
- return err;
}
static int __exit ep93xx_pwm_remove(struct platform_device *pdev)
{
struct ep93xx_pwm *pwm = platform_get_drvdata(pdev);
- struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ep93xx_pwm_disable(pwm);
clk_disable(pwm->clk);
- clk_put(pwm->clk);
sysfs_remove_group(>dev.kobj, _pwm_sysfs_files);
- iounmap(pwm->mmio_base);
- release_mem_region(res->start, resource_size(res));
- kfree(pwm);
ep93xx_pwm_release_gpio(pdev);
return 0;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/14] misc/ep93xx_pwm: cleanup driver for conversion to PWM framework
This driver needs to be converted to the new PWM framework.
Before converting it clean up all the cruft,
H Hartley Sweeten (14):
misc/ep93xx_pwm: use managed device resources
misc/ep93xx_pwm: use {read,write}* instead of __raw_* versions for io
misc/ep93xx_pwm: remove ep93xx_pwm_{write,read}l() inline functions
misc/ep93xx_pwm: remove ep93xx_pwm_write_tc() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_write_dc() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_enable() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_disable() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_invert() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_normal() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_read_tc() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_is_enabled() inline function
misc/ep93xx_pwm: remove ep93xx_pwm_is_inverted() inline function
misc/ep93xx_pwm: use module_platform_driver()
misc/ep93xx_pwm: use kstrtol instead of strict_strtol
drivers/misc/ep93xx_pwm.c | 187 +-
1 file changed, 50 insertions(+), 137 deletions(-)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: SoC fixes for 3.10-rc
Hi Linus, The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to f4ae176c626311d6507c9a2d263657c4cc4e1667: Merge tag 'sunxi-fixes-for-3.10' of git://github.com/mripard/linux into fixes (2013-05-24 15:50:28 -0700) ARM: SoC fixes for 3.10-rc We didn't have any fixes sent up for -rc2, so this is a slightly larger batch. A bit all over the place platform-wise; OMAP, at91, marvell, renesas, sunxi, ux500, etc. I tried to summarize highlights but there isn't a whole lot to point out. Lots of little things fixed all over. A couple of defconfig updates due to new/changing options. Alexandre Courbot (1): ARM: tegra: defconfig fixes Andrew Lunn (1): ARM: Orion: Remove redundant init_dma_coherent_pool_size() Boris BREZILLON (1): ARM: at91/dt: fix macb pinctrl_macb_rmii_mii_alt definition Dirk Behme (1): ARM i.MX6: correct MLB clock configuration Emilio López (1): ARM: ux500: select REGULATOR Ezequiel Garcia (2): ARM: mvebu: Add a ranges entry to translate devbus childs ARM: mvebu: Fix ranges entry on XP GP board Gregory CLEMENT (3): ARM: mvebu: select ARCH_REQUIRE_GPIOLIB for mvebu platform ARM: plat-orion: Fix num_resources and id for ge10 and ge11 ARM: dts: mvebu: Fix wrong the address reg value for the L2-cache node Jean-Christophe PLAGNIOL-VILLARD (3): ARM: at91/trivial: fix model name for SAM9X25-EK ARM: at91: rm9200 fix time support ARM: at91: at91sam9n12: move external irq declatation to DT Josh Wu (1): ARM: at91/sama5: fix incorrect PMC pcr div definition Lee Jones (3): ARM: ux500: Remove duplicated assignment of ab8500_platdata ARM: ux500: Fix incorrect DEBUG UART virtual addresses ARM: ux500: Provide device enumeration number suffix for SMSC911x Linus Walleij (1): ARM: nomadik: fix IRQ assignment for SMC ethernet Lucas Stach (2): clk: tegra: remove USB from clk init table clk: tegra: add ac97 controller clock Ludovic Desroches (1): ARM: at91: dts: request only spi cs-gpios used on sama5d3x cpu module Martin Michlmayr (1): Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x Maxime Ripard (2): ARM: sunxi: Fix Mini X-plus device tree build ARM: sunxi: select ARCH_REQUIRE_GPIOLIB Nicolas Ferre (1): ARM: at91/trivial: typo in GEM compatible string Olof Johansson (10): Merge tag 'fixes-3.10-1' of git://git.infradead.org/users/jcooper/linux into fixes Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes Merge tag 'omap-for-v3.10-rc1/fixes' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'fixes-3.10-2' of git://git.infradead.org/users/jcooper/linux into fixes Merge tag 'imx-fixes-3.10' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes Merge tag 'ux500-arm-soc-v3.10-fixes' of git://git.kernel.org/.../linusw/linux-stericsson into fixes Merge tag 'omap-fixes-a-for-3.10-rc' of git://git.kernel.org/.../pjw/omap-pending into fixes Merge tag 'renesas-boards-marzen-fixes-for-v3.10' of git://git.kernel.org/.../horms/renesas into fixes Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes Merge tag 'sunxi-fixes-for-3.10' of git://github.com/mripard/linux into fixes Paul Walmsley (1): ARM: OMAP2+: Add missing CONFIG_ARCH_MULTI_V6=y to omap2plus_defconfig Philipp Zabel (1): ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel clocks Rajendra Nayak (2): ARM: OMAP2+: hwmod: Fix sidle programming in _enable_sysc()/_idle_sysc() ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in active Santosh Shilimkar (4): ARM: OMAP2+: hwmod-data: UART IP needs software control to manage sidle modes ARM: OMAP2+: serial: Remove the un-used slave idle hooks SERIAL: OMAP: Remove the slave idle handling from the driver ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis Sebastian Hesselbarth (1): ARM: plat-orion: add missing ehci include to common.h Shawn Guo (2): ARM: imx: replicate the diagnostic register of boot cpu into secondary cores ARM: imx: fix typo in gpu3d_shader_sels Simon Horman (1): ARM: shmobile: marzen: Use error values in usb_power_* Srinivas Kandagatla (1): ARM: vt8500: Add missing NULL terminator in dt_compat Thomas Petazzoni (2): ARM: mvebu: do not duplicate the mpic alias arm: mvebu: fix the 'ranges' property to handle PCIe Tony Lindgren (1): ARM: dts: Fix musb interrupt for device tree booting Vaibhav Hiremath (1): ARM: AM33XX:
Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Vivek Goyal writes: > On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote: >> Hello Vivek, >> >> On Fri, 24 May 2013 10:36:44 -0400 >> Vivek Goyal wrote: >> >> [snip] >> >> > Sorry, I don't understand the problem. If we swapped low memory and >> > crash reserved memory, that should have been taken care by prepared >> > ELF headers so that we map the right pfns. In x86 we swap 640K of low >> > memory with 640K of memory in reserved and we take care of this by >> > preparing elf headers accordingly. >> > >> > So why s390 can't do the same thing? >> >> I am not sure if I understand this. Currently we create the ELF >> header in a way that we have virtual=real. In the copy_oldmem_page() we >> do the swap so that for the /proc/vmcore code it looks like contiguous >> non-swapped memory. >> >> One reason why I thought this was necessary was that /dev/oldmem >> also uses the function and it should provide linear memory access like >> it is on the live system with /dev/mem. >> >> Is that implementation incorrect? > > [ CC Andrew. Keep him in loop for all kernel kdump patches as all kdump > patches are routed through him ]. > > [ CC Eric Biederman ] > > Looking at the code, looks like /dev/oldmem is broken. It does not know > anything about swap of any of the memory areas and it will simply > return the contents of page frame asked. And this has been like this > since the beginning. > > I have always questioned the utility of /dev/oldmem. Atleast I am not > aware of any tool making use of it. > > If we want to fix it, then somebow all the swapped memory region info > needs to be communicated to second kernel so that read_oldmem() can > do the mapping correctly and we really don't have any mechanism for > that. (I am assuming that in s390 you must have hardcoded the regions > of memory which are always swapped). > > As /proc/vmcore is the most used and useful interface, I prefer that > we swap memory and put that info in elf headers. For /dev/oldme, I > don't mind if we leave it as it is. If somebody really cares, then > I guess we need to write a new command line option which /dev/mem > can parse and which tells it about swaps so that /dev/oldmem can > map things correctly. (This is better than hardcoding things). > > Eric, do you have any thoughts on this. I don't think anyone actually uses /dev/oldmem. I would like to cite the s390 confusion as proof but I don't think that quite works. I think the solution is for someone to send a patch removing /dev/oldmem as an unused piece of code. That will also move us in the direction of resolving HPAs concerns. The function copy_oldmem_page also concerns me. I don't have a clue why we duplicate that function on every architecutre in a slightly different form. There should be enough abstractions in the kernel to make that unnecessary. I would be glad to see that function go, and remove the possibility of confusion that happened on s390. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rcu_read_lock() used illegally while idle!
On Fri, May 24, 2013 at 03:23:40PM -0400, Steven Rostedt wrote: > On Fri, 2013-05-24 at 10:23 -0400, Dave Jones wrote: > > > .config: http://paste.fedoraproject.org/14281/94052971/raw/ > > > > trace shows the problem process was 'cc1', so I was likely building a > > kernel > > at the time. There was also a trinity run going on in the background. > > > > cmdline: nothing special.. > > > > BOOT_IMAGE=/vmlinuz-3.10.0-rc2+ > > root=UUID=bee21cd9-1852-4d1d-9e9d-2e44332b8df1 ro rd.md=0 rd.lvm=0 rd.dm=0 > > vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 > > consoleblank=0 console=ttyUSB0,115200 console=tty0 pause_on_oops=30 audit=0 > > > > OK, I'm able to reproduce this. Looks like the same issue happens from > other ways from userspace into the kernel (the next way was tracing > system calls). > > Forget the other patch. Here's a new patch that is more specific to > tracing and context tracking. > > Can you try this one out, please. It's looking good so far. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: Add Option GTM681W to qcserial device table.
On Fri, 2013-05-24 at 20:25 +0200, Bjørn Mork wrote: > Richard Weinberger writes: > > Am 24.05.2013 15:18, schrieb Bjørn Mork: > >> Richard Weinberger writes: > >> > >>> The Option GTM681W uses a qualcomm chip and can be > >>> served by the qcserial device driver. > >> > >> Should it also be added to the qmi_wwan driver? > > > > Don't know. But I can happily test it. :) > > Can you please explain me how to use the qmi_wwan driver? > > I've never used it. > > The QMI management protocol is delegated to userspace using a > /dev/cdc-wdmX character device. So you need a userspace component to > test the driver, like for example libqmi. See > http://sigquit.wordpress.com/2012/08/20/an-introduction-to-libqmi/ for a > short intro. Various marketing collateral suggests the 681W is a Gobi3K and thus it most certainly should also get added to qmi_wwan. lsusb -v output for it would be helpful too I think? http://www.option.com/product/gtm681wgtm689w/ Dan > This library is packaged in Debian. Don't know the status of other > distros. > > The driver supports dynamic device IDs, so if you have qcserial bound to > all serial ports, and there is a QMI interface with no driver bound yet, > then testing should be as easy as > > modprobe qmi_wwan > echo "0af0 8120" >/sys/bus/usb/drivers/qmi_wwan/new_id > qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer > > > > Bjørn > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] ipc: move locking out of ipcctl_pre_down_nolock
On Fri, 24 May 2013 15:21:36 -0700 Davidlohr Bueso wrote: > > > > Where should readers go to understand the overall locking scheme? A > > description of the overall object hierarchy and the role which the > > various locks play? > > That can be done, how about something like > Documentation/ipc-locking.txt? I find that code comments at definition sites work better, if possible. Standalone documentation ends up being too verbose and never gets updated or read... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/11] ipc: move locking out of ipcctl_pre_down_nolock
On Fri, 2013-05-24 at 13:16 -0700, Andrew Morton wrote:
> On Wed, 15 May 2013 18:08:03 -0700 Davidlohr Bueso
> wrote:
>
> > This function currently acquires both the rw_mutex and the rcu lock on
> > successful lookups, leaving the callers to explicitly unlock them, creating
> > another two level locking situation.
> >
> > Make the callers (including those that still use ipcctl_pre_down())
> > explicitly
> > lock and unlock the rwsem and rcu lock.
> >
> > ...
> >
> > @@ -409,31 +409,38 @@ static int msgctl_down(struct ipc_namespace *ns, int
> > msqid, int cmd,
> > return -EFAULT;
> > }
> >
> > + down_write(_ids(ns).rw_mutex);
> > + rcu_read_lock();
> > +
> > ipcp = ipcctl_pre_down(ns, _ids(ns), msqid, cmd,
> >_perm, msqid64.msg_qbytes);
> > - if (IS_ERR(ipcp))
> > - return PTR_ERR(ipcp);
> > + if (IS_ERR(ipcp)) {
> > + err = PTR_ERR(ipcp);
> > + /* the ipc lock is not held upon failure */
>
> Terms like "the ipc lock" are unnecessarily vague. It's better to
> identify the lock by name, eg msg_queue.q_perm.lock.
Ok, I can send a patch to rephrase that to perm.lock when I send the shm
patchset (which will be very similar to this one).
>
> Where should readers go to understand the overall locking scheme? A
> description of the overall object hierarchy and the role which the
> various locks play?
That can be done, how about something like
Documentation/ipc-locking.txt?
>
> Have you done any performance testing of this patchset? Just from
> squinting at it, I'd expect the effects to be small...
>
Right, I don't expect much performance benefits. (a) unlike sems, I
haven't seen mqueues ever show up as any source of contention, and (b) I
think sysv mqueues have mostly been replaced by posix ones...
For testing, I did run these patches with ipccmd
(http://code.google.com/p/ipcmd/), pgbench, aim7 and Oracle on large
machines - no regressions but nothing new in terms of performance.
I suspect that shm could have a little more impact, but haven't looked
too much into it.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
On Fri, May 24, 2013 at 11:45:33AM +0200, Paolo Bonzini wrote:
> > It's not just unimplemented commands. Exposing any new command exposes
> > its borderline problems together with it.
>
> For commands that are used by Linux already, the right way to fix the
> problems is not obscuring the commands from userspace's view. You can
> hit the same problems with ioctls or even with normal operation of the
> device.
The kernel is providing an isolation layer between the userland and
the devices. It isn't obscuring. We can go through many adjectives
but it's still increasing the amount exposed surface and accelerating
expansion of cdb filter.
> And prohibiting the extension of whitelists is gonna increase the
> usage of unpriv_sgio and less-secure userspace whitelists.
>
> Anvil, meet hammer.
Delegating full device access is still a fringe use case compared to
generic block RW access. Given thta we're expecting to have an extra
separation layer albeit in userland, the overall picture doesn't seem
to favor extension of whitelists.
> > If the bulk of filtering can be solved with userland whitelisting as a
> > confined user, it should be possible to resolve peripheral problems
> > like log messages in simpler way, no? Can you please elaborate on the
> > log message problem? Who's spewing those messages?
>
> For example:
>
> if (bdev_write_same(bdev)) {
> unsigned char bdn[BDEVNAME_SIZE];
>
> if (!blkdev_issue_write_same(bdev, sector, nr_sects, gfp_mask,
> ZERO_PAGE(0)))
> return 0;
>
> bdevname(bdev, bdn);
> pr_err("%s: WRITE SAME failed. Manually zeroing.\n", bdn);
> }
>
> return __blkdev_issue_zeroout(bdev, sector, nr_sects, gfp_mask);
>
> The device exposes the ability to zero out LUN blocks, but the command is
> not whitelisted and it fails.
Which can be solved by userland filtering, right?
--
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] ARM: at91: Fix link breakage when !CONFIG_PHY
Fixes:
arch/arm/mach-at91/built-in.o: In function `ksz9021rn_phy_fixup':
:(.text+0x1174): undefined reference to `mdiobus_write'
:(.text+0x1188): undefined reference to `mdiobus_write'
:(.text+0x119c): undefined reference to `mdiobus_write'
:(.text+0x11b0): undefined reference to `mdiobus_write'
arch/arm/mach-at91/built-in.o: In function `sama5_dt_device_init':
:(.init.text+0x1e34): undefined reference to
`phy_register_fixup_for_uid'
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/board-dt-sama5.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-at91/board-dt-sama5.c
b/arch/arm/mach-at91/board-dt-sama5.c
index 705305e..f510381 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -38,6 +38,7 @@ static void __init at91_dt_init_irq(void)
of_irq_init(irq_of_match);
}
+#ifdef CONFIG_PHY
static int ksz9021rn_phy_fixup(struct phy_device *phy)
{
int value;
@@ -59,12 +60,15 @@ static int ksz9021rn_phy_fixup(struct phy_device *phy)
return 0;
}
+#endif
static void __init sama5_dt_device_init(void)
{
+#ifdef CONFIG_PHY
if (of_machine_is_compatible("atmel,sama5d3xcm"))
phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
ksz9021rn_phy_fixup);
+#endif
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mmc: sdhci: Added set_power sdhci_ops handler.
Hi all, On Thu, May 23, 2013 at 9:02 PM, Jaehoon Chung wrote: > On 05/23/2013 04:25 PM, Guennadi Liakhovetski wrote: >> On Wed, 22 May 2013, Felipe Ferreri Tonello wrote: >> >>> Hi Guennadi, >>> >>> On Wednesday, May 22, 2013 10:30:40 PM Guennadi Liakhovetski wrote: On Wed, 22 May 2013, Felipe F. Tonello wrote: > From: "Felipe F. Tonello" > > This is useful for power managment purposes if a sdhci child host wants to > turn off some other peripheral also. Sorry, could you elaborate a bit? In what situations is it exactly useful? And why cannot the regulator API be used there? >>> >>> Sorry about that. >>> >>> One example that I can think of is when you have a wifi module connected as >>> a >>> mmc card via sdio. So you can register a callback function in your machine >>> source code to turn on/off the wifi module based on the mmc host power. >> >> Ok, understand. Your second patch in this series adds such a callback in >> your SDHCI host driver and there it just calls a platform callback. I >> don't think this is a good idea. First, we want to go away from platform >> callbacks, because they are incompatible with DT. Second, because the >> proper solution IMHO would be for your platform to export a regulator, and >> the SDHCI core driver already includes regulator support. > We can use the regulator framework. > i think this callback function didn't need. > Ok, thanks for the feed back. Just to get things clear, is this implementation using regulator framework already done? BR, Felipe > Best Regards, > Jaehoon Chung >> >>> I've seen this implementation in others mmc hosts, such as omap. >> >> Which, however, doesn't yet mean, it's a good idea :) >> >> Thanks >> Guennadi >> --- >> Guennadi Liakhovetski, Ph.D. >> Freelance Open-Source Software Developer >> http://www.open-technology.de/ >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v1.8.3
The latest feature release Git v1.8.3 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: bfb88c182daeed5601ba860d785ac813433f55f1 git-1.8.3.tar.gz 92cc8ae5f4c1db2e7751ad0dc9c3227ca31080aa git-htmldocs-1.8.3.tar.gz be6527e803d3b2e51c5e71f53ca8ccff2ef68939 git-manpages-1.8.3.tar.gz The following public repositories all have a copy of the v1.8.3 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Also, http://www.kernel.org/pub/software/scm/git/ has copies of the release tarballs. Git v1.8.3 Release Notes Backward compatibility notes (for Git 2.0) -- When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the "simple" semantics that pushes only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch. Use the user preference configuration variable "push.default" to change this. If you are an old-timer who is used to the "matching" semantics, you can set the variable to "matching" to keep the traditional behaviour. If you want to live in the future early, you can set it to "simple" today without waiting for Git 2.0. When "git add -u" (and "git add -A") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.2 Foreign interface * remote-hg and remote-bzr helpers (in contrib/ since v1.8.2) have been updated; especially, the latter has been done in an accelerated schedule (read: we may not have merged to this release if we were following the usual "cook sufficiently in next before unleashing it to the world" workflow) in order to help Emacs folks, whose primary SCM seems to be stagnating. UI, Workflows & Features * A handful of updates applied to gitk, including an addition of "revert" action, showing dates in tags in a nicer way, making colors configurable, and support for -G'pickaxe' search. * The prompt string generator (in contrib/completion/) learned to show how many changes there are in total and how many have been replayed during a "git rebase" session. * "git branch --vv" learned to paint the name of the branch it integrates with in a different color (color.branch.upstream, which defaults to blue). * In a sparsely populated working tree, "git checkout " no longer unmarks paths that match the given pathspec that were originally ignored with "--sparse" (use --ignore-skip-worktree-bits option to resurrect these paths out of the index if you really want to). * "git log --format" specifier learned %C(auto) token that tells Git to use color when interpolating %d (decoration), %h (short commit object name), etc. for terminal output. * "git bisect" leaves the final outcome as a comment in its bisect log file. * "git clone --reference" can now refer to a gitfile "textual symlink" that points at the real location of the repository. * "git count-objects" learned "--human-readable" aka "-H" option to show various large numbers in Ki/Mi/GiB scaled as necessary. * "git cherry-pick $blob" and "git cherry-pick $tree" are nonsense, and a more readable error message e.g. "can't cherry-pick a tree" is given (we used to say "expected exactly one commit"). * The "--annotate" option to "git send-email" can be turned on (or off) by default with sendemail.annotate configuration variable (you can use --no-annotate
Re: [PATCH 0/7] mfd: arizona: Updates for v3.11
Hi Mark, On Tue, May 21, 2013 at 01:12:30PM -0500, Mark Brown wrote: > The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: > > Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git > tags/mfd-arizona-v3.10-rc2 > > for you to fetch changes up to f773fc6dca4619bdf8da767eaba101a83b766059: > > mfd: arizona: Change fast_start pdata name to better reflect functionality > (2013-05-21 12:41:54 -0500) > > > mfd: arizona: Updates for v3.10 > > A bunch of enhancements and fixes for the arizona devices, adding a few > new features (the main one being device tree) and improving robustness. > > > > There's going to be some changes following on from this which overlap > with ASoC, it might be simplest to merge all this stuff in via ASoC if > that's OK? That's fine with me. I pulled it anyway to keep mfd-next in sync with the ASoC tree as far as MFD is concerned, and avoid potential merge conflicts. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: avoid mis-detecting some V7 cores in the decompressor
On 05/24, Russell King - ARM Linux wrote: > On Thu, May 23, 2013 at 10:54:26AM -0700, Stephen Boyd wrote: > > On 05/15/13 12:38, Stephen Boyd wrote: > > > On 05/08/13 14:47, Stephen Boyd wrote: > > >> From: Brian Swetland > > >> > > >> Currently v7 CPUs with an MIDR that has no bits set in the range > > >> [16:12] will be detected as old ARM CPUs with no caches and so > > >> the cache will never be turned on during decompression. ARM's > > >> Cortex chips have an 0xC in the range [16:12] so they never match > > >> this entry, but Qualcomm's Scorpion and Krait processors never > > >> set these bits to anything besides 0 so they always match. > > >> > > >> Skip this entry if we've compiled in support for v7 CPUs. This > > >> allows kernel decompression to happen nearly instantly instead of > > >> taking over 20 seconds. > > >> > > >> Signed-off-by: Brian Swetland > > >> [sboyd: Clarified and extended commit text] > > >> Signed-off-by: Stephen Boyd > > >> --- > > > Ping? > > > > Russell, shall I add this to the patch tracker? > > Yes please. > Ok, thanks. I've noticed another problem now that our caches are used. On MSM we have TEXT_OFFSET set to at least 0x208000 if we've built-in support for MSM8x60/8960. If I boot a kernel with the MSM code built-in that requires the higher text offset, but I load my compressed kernel below that address (such as 0x0) the decompression fails. This happens because the page tables are written into the compressed data region before we relocate ourself to a higher location. Here's some ascii art to show the problem We start off at 0x0 0x00 +-+ | | | zImage | 0x208000 |-| <- r4 (zreladdr) | zImage | 0x30 +-+ <- _edata Then we run far enough to call cache_on which goes ahead and calls __setup_mmu and sets up our page tables. 0x008000 +-+ | | | zImage | | | 0x204000 |-| | pgdir | 0x208000 |-| <- r4 (zreladdr) | | | zImage | | | 0x30 +-+ <- _edata This is bad because we just wrote our page tables into the compressed data. Nobody notices though and we finish relocating ourselves and then we call decompress_kernel() which fails randomly. (BTW, why does error() sit in a while loop forever? We can't get any information about why the decompression failed if we have debug_ll enabled. I had to patch the error() routine to not while loop forever to get that print after do_decompress to be useful.) I see a few solutions. 1) Relocate with caches off and then turn on caches after we're running in a location where we won't overwrite ourselves. 2) Have temporary page tables for the relocation phase that live just below the location we're going to relocate to. 3) Force bootloaders loading these types of images to load the zImage at least as high as the TEXT_OFFSET is compiled to. I don't think we can convince everyone that #3 is ok to do. I'm leaning towards #2 since we get all the benefits of the cache during the relocation phase but #1 is the obviously simple fix. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: EXYNOS: add PM dependency to PM_GENERIC_DOMAINS for Exynos4210
On 05/14/13 10:19, Jingoo Han wrote: PM_GENERIC_DOMAINS needs PM dependency. Fixed build warning as below: warning: (PLAT_S3C64XX&& CPU_EXYNOS4210) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM) If so, PLAT_S3C64XX should be fixed together. diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index 2057853..c04c4ee 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -8,7 +8,7 @@ config PLAT_S3C64XX bool depends on ARCH_S3C64XX default y - select PM_GENERIC_DOMAINS + select PM_GENERIC_DOMAINS if PM select SAMSUNG_WAKEMASK help Base platform code for any Samsung S3C64XX device warning: (PLAT_S3C64XX&& CPU_EXYNOS4210) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM) arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp] drivers/base/power/domain.c: In function '__pm_genpd_add_device': drivers/base/power/domain.c:1422:2: error: implicit declaration of function 'genpd_acquire_lock' [-Werror=implicit-function-declaration] drivers/base/power/domain.c:1466:2: error: implicit declaration of function 'genpd_release_lock' [-Werror=implicit-function-declaration] drivers/base/power/domain.c: In function 'pm_genpd_add_subdomain': drivers/base/power/domain.c:1649:3: error: implicit declaration of function 'genpd_sd_counter_inc' [-Werror=implicit-function-declaration] drivers/base/power/domain.c: In function 'pm_genpd_remove_subdomain': drivers/base/power/domain.c:1721:4: error: implicit declaration of function 'genpd_sd_counter_dec' [-Werror=implicit-function-declaration] drivers/base/power/domain.c: In function 'pm_genpd_attach_cpuidle': drivers/base/power/domain.c:1887:2: error: implicit declaration of function 'genpd_recalc_cpu_exit_latency' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Jingoo Han --- arch/arm/mach-exynos/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index d19edff..1f7ddb2 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -34,7 +34,7 @@ config CPU_EXYNOS4210 default y depends on ARCH_EXYNOS4 select ARM_CPU_SUSPEND if PM - select PM_GENERIC_DOMAINS + select PM_GENERIC_DOMAINS if PM select S5P_PM if PM select S5P_SLEEP if PM select SAMSUNG_DMADEV -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dmatest: do not allow to interrupt ongoing tests
Hi Andy
On Thu, 23 May 2013, Andy Shevchenko wrote:
> When user interrupts ongoing transfers the dmatest may end up with console
> lockup, oops, or data mismatch. This patch prevents user to abort any ongoing
> test.
Personally I would be against such a change. What about interrupting the
test with rmmod? Is it still possible after this your patch or not? If not
- this doesn't seem like a good idea to me. Why don't we just fix those
bugs, that you're describing?
Thanks
Guennadi
>
> Documentation is updated accordingly.
>
> Signed-off-by: Andy Shevchenko
> Reported-by: Will Deacon
> Tested-by: Will Deacon
> ---
> Documentation/dmatest.txt | 6 +++---
> drivers/dma/dmatest.c | 45 +++--
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/dmatest.txt b/Documentation/dmatest.txt
> index 279ac0a..132a094 100644
> --- a/Documentation/dmatest.txt
> +++ b/Documentation/dmatest.txt
> @@ -34,7 +34,7 @@ command:
> After a while you will start to get messages about current status or error
> like
> in the original code.
>
> -Note that running a new test will stop any in progress test.
> +Note that running a new test will not stop any in progress test.
>
> The following command should return actual state of the test.
> % cat /sys/kernel/debug/dmatest/run
> @@ -52,8 +52,8 @@ To wait for test done the user may perform a busy loop that
> checks the state.
>
> The module parameters that is supplied to the kernel command line will be
> used
> for the first performed test. After user gets a control, the test could be
> -interrupted or re-run with same or different parameters. For the details see
> -the above section "Part 2 - When dmatest is built as a module..."
> +re-run with the same or different parameters. For the details see the above
> +section "Part 2 - When dmatest is built as a module..."
>
> In both cases the module parameters are used as initial values for the test
> case.
> You always could check them at run-time by running
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index d8ce4ec..e88ded2 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -716,8 +716,7 @@ static int dmatest_func(void *data)
> }
> dma_async_issue_pending(chan);
>
> - wait_event_freezable_timeout(done_wait,
> - done.done || kthread_should_stop(),
> + wait_event_freezable_timeout(done_wait, done.done,
>msecs_to_jiffies(params->timeout));
>
> status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
> @@ -997,7 +996,6 @@ static void stop_threaded_test(struct dmatest_info *info)
> static int __restart_threaded_test(struct dmatest_info *info, bool run)
> {
> struct dmatest_params *params = >params;
> - int ret;
>
> /* Stop any running test first */
> __stop_threaded_test(info);
> @@ -1012,13 +1010,23 @@ static int __restart_threaded_test(struct
> dmatest_info *info, bool run)
> memcpy(params, >dbgfs_params, sizeof(*params));
>
> /* Run test with new parameters */
> - ret = __run_threaded_test(info);
> - if (ret) {
> - __stop_threaded_test(info);
> - pr_err("dmatest: Can't run test\n");
> + return __run_threaded_test(info);
> +}
> +
> +static bool __is_threaded_test_run(struct dmatest_info *info)
> +{
> + struct dmatest_chan *dtc;
> +
> + list_for_each_entry(dtc, >channels, node) {
> + struct dmatest_thread *thread;
> +
> + list_for_each_entry(thread, >threads, node) {
> + if (!thread->done)
> + return true;
> + }
> }
>
> - return ret;
> + return false;
> }
>
> static ssize_t dtf_write_string(void *to, size_t available, loff_t *ppos,
> @@ -1091,22 +1099,10 @@ static ssize_t dtf_read_run(struct file *file, char
> __user *user_buf,
> {
> struct dmatest_info *info = file->private_data;
> char buf[3];
> - struct dmatest_chan *dtc;
> - bool alive = false;
>
> mutex_lock(>lock);
> - list_for_each_entry(dtc, >channels, node) {
> - struct dmatest_thread *thread;
> -
> - list_for_each_entry(thread, >threads, node) {
> - if (!thread->done) {
> - alive = true;
> - break;
> - }
> - }
> - }
>
> - if (alive) {
> + if (__is_threaded_test_run(info)) {
> buf[0] = 'Y';
> } else {
> __stop_threaded_test(info);
> @@ -1132,7 +1128,12 @@ static ssize_t dtf_write_run(struct file *file, const
> char __user *user_buf,
>
> if (strtobool(buf, ) == 0) {
> mutex_lock(>lock);
> - ret = __restart_threaded_test(info, bv);
> +
> + if
Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
On 05/18/13 19:19, Oliver Schinagl wrote:
+
+
+/* We read the entire key, using a look up table. Returned is only the
+ * requested byte. This is of course slower then it could be and uses 4 times
+ * more reads as needed but keeps code a little simpler.
+ */
+u8 sunxi_sid_read_byte(const int key)
+{
+ u32 sid_key;
+ u8 ret;
+
+ ret = 0;
+ if (likely((key <= SUNXI_SID_SIZE))) {
+ sid_key = ioread32(p->sid_base + keys_lut[key >> 2]);
+ switch (key % 4) {
+ case 0:
+ ret = (sid_key >> 24) & 0xff;
+ break;
+ case 1:
+ ret = (sid_key >> 16) & 0xff;
+ break;
+ case 2:
+ ret = (sid_key >> 8) & 0xff;
+ break;
+ case 3:
+ ret = sid_key & 0xff;
+ break;
+ }
+ }
Come on, you can do better. This lookup table is useless.
I didn't want to depend on the fixed layout of memory, but consider it
removed.
But i'm not smart enough :p
We can either use the look up table (which does have benefits as its
potentially more future proof), or do some ((key >> 2) << 2) to 'drop'
the LSB's that we want to ignore (unless there's some smarter way).
Personally, I think the LUT is a little cleaner and more readable, but I
guess if you look at poor efficiency, the lut costs some memory, the
left/right shift cost an additional >> 2 ... what you prefer.
Also, why the first key is the one with the MSBs?
I'd expect that the key 0 is the one holding the LSBs.
Strangely enough, they have swapped the MSB and LSB bytes. I double
checked it with u-boot and yep, swapped. Though in the end, if we write
stuff there and we read stuff from there, order doesn't matter? So what
do we prefer. Have it so that it makes sense and ignore how u-boot reads
it, or correct it and be consistent?
You had me confused and I was looking at this for a little while.
Bit-ordering does not change, Byte endianness is a different story of
course. As it is now, I decided to use Big endianess. So now a 32bit key
looks like:
0x162367c7 and if we read one byte at a time, we get 0x16, 0x23, 0x67
and 0xc7. I made a comment that data is read as Big endian. If it is
important, for eeprom data, to be stored little endian, I'll obviously
change it per request.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 part1 1/4] sg_io: pass request_queue to blk_verify_command
Il 24/05/2013 10:32, Paolo Bonzini ha scritto: > Il 24/05/2013 10:03, James Bottomley ha scritto: >> Does anyone in the real world actually care about this bug? Yes, or I would move on and not waste so much time on this. >> >> Fine, so produce a simple fix for this bug which we can discuss that's >> not tied to this feature. Honestly, I have no idea how this is even possible. >> Really? It looks to me like a simple block on the commands for disk >> devices in the opcode switch would do it (with a corresponding change to >> sg.c:sg_allow_access). > > Which switch? What I can do is something like this in blk_verify_command: > > if (q->sgio_type == TYPE_ROM) > return 0; > if (rq->cmd[0] == 0xA4) > return -EPERM; > if (!is_write && > (req->cmd[0] == ... || rq->cmd[0] == ...)) > return -EPERM; > > But then the particular patch you're replying to is still necessary, > and you're slowing down blk_verify_command. It may be fine for stable > and -rc, but IMHO it calls for a better implementation in 3.11. Ok, so I did a patch along these lines. And it's just as ugly as everything else that I've been posting in these threads. Yes, perhaps it has a redeeming grace in that it is fine for <= 3.10, but that's it. Because actually I agree with you. The rework of the SG_IO command filter _is_ dubious to say the least; 300 lines of default, immutable policy don't belong in the kernel. So why am I posting this crap? Because I have to work around the nack of the generic sysfs bitmap patches, which would have beatifully solved all of this. In fact, you had proposed that approach. I posted it in September 2012. Then (as usual) silence for one month until it was quickly dismissed by Tejun. *You and Jens* failed to review patches, and this rathole is what that led to. It's unpleasant for me as it is for everyone else. Yes, you and Jens are busy, we all are. But *you and Jens* are the maintainers. Please make a decision instead of drawing straws, so that we can all go back to our regular business. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas
> On Thur, 23 May 2013 Andrew Morton wrote: > > On Wed, 15 May 2013 07:46:36 -0500 Cliff Wickman wrote: > > Certain tests in walk_page_range() (specifically split_huge_page_pmd()) > > assume that all the mapped PFN's are backed with page structures. And this > > is > > not usually true for VM_PFNMAP areas. This can result in panics on kernel > > page faults when attempting to address those page structures. > > > > There are a half dozen callers of walk_page_range() that walk through > > a task's entire page table (as N. Horiguchi pointed out). So rather than > > change all of them, this patch changes just walk_page_range() to ignore > > VM_PFNMAP areas. > > > > The logic of hugetlb_vma() is moved back into walk_page_range(), as we > > want to test any vma in the range. > > > > VM_PFNMAP areas are used by: > > - graphics memory manager gpu/drm/drm_gem.c > > - global reference unit sgi-gru/grufile.c > > - sgi special memorychar/mspec.c > > - and probably several out-of-tree modules > > What are your thoughts on the urgency/scheduling of this fix? The panic can be caused by simply cat'ing /proc//smaps while an application has a VM_PFNMAP range. It happened in-house when a benchmarker was trying to decipher the memory layout of his program. So that makes it rather urgent from our point of view. We would like to see the fix included in upcoming distro releases, and having it upstream makes that much easier to accomplish. > (Just to be irritating: "When writing a changelog, please describe the > end-user-visible effects of the bug, so that others can more easily > decide which kernel version(s) should be fixed, and so that downstream > kernel maintainers can more easily work out whether this patch will fix > a problem which they or their customers are observing.") -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression: from 3.8 to 3.9: headphones output no sound on Intel HDA, codec VIA VT1802
On Fri, May 24, 2013 at 7:22 PM, Takashi Iwai wrote: > > Well, I assumed that the EAPD off triggers the pin widget off by the > hardware, too. But it seems wrong. By some reason, the hardware > clears the pin automatically. Hmm. > > Could you try to trace the verbs while plugging the headphone? Attached, it's ~70k, so compressed again. >> I did, it does not work. Transcript and alsa-info before and after >> hda-verb attached. > > OK, I'll cook up the new patch later. I'm sorry to say that I will not be able to test it in the next 8 or so days: I'll be traveling and without this particular laptop with me. I hope someone with similar model (Sytem76 Lemur lemu4, i7) can provide some testing in the meantime. Otherwise, I'll test it as soon as I get back. trace.log.gz Description: GNU Zip compressed data
Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote: > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote: > > Russ, > > > > Can we open a bug for the BIOS folks and see if we can get this addressed? > > I already talked with them. It is not in an area that we > normally change, so if there is a bug may be in the Intel > reference code. More investigation is needed to track down > the actual problem, and that could take help from Intel. > > Regardless of that, it is a kernel patch that triggers the > problem. This isn't the first time a kernel change does > the "right thing" but trips across questionable bios/EFI/bootloader > implementation. That still makes it a kernel bug. > > I'm still digging to better understand the root problem. When we rebased the Fedora 18 kernel to 3.9 we had a bunch of reports from people who can no longer boot with what looks like similar symptoms. https://bugzilla.redhat.com/show_bug.cgi?id=964335 Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers.
On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote: > If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend, > a reset will be performed upon runtime resume. Any previously suspended > devices attached to the controller will be re-enumerated at this time. > This will cause problems, for example, if an open system call on the > device triggered the resume (the open call will fail). That's ugly, but disabling runtime PM is going to have a big impact on the power consumption of those systems. Alan, do you think this is really the right thing to be doing here? It feels like userspace should just be able to deal with devices disconnecting on resume. After all, there are lots of USB devices that can't handle USB device suspend at all. Shouldn't userspace just disable runtime PM for the USB device classes that don't have a reset resume callback? > Note that this change is only relevant when persist_enabled is not set > for USB devices. Could we at least wrap the call in an ifdef CONFIG_USB_DEFAULT_PERSIST? That way if people have USB persist turned off in their configuration, their host will still be able to suspend. Sarah Sharp > > Signed-off-by: Shawn Nematbakhsh > --- > drivers/usb/host/xhci.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index b4aa79d..7455156 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -4687,6 +4687,12 @@ int xhci_gen_setup(struct usb_hcd *hcd, > xhci_get_quirks_t get_quirks) > > get_quirks(dev, xhci); > > + /* If we are resetting upon resume, we must disable runtime PM. > + * Otherwise, an open() syscall to a device on our runtime suspended > + * controller will trigger controller reset and device re-enumeration */ > + if (xhci->quirks & XHCI_RESET_ON_RESUME) > + pm_runtime_get_noresume(dev); > + > /* Make sure the HC is halted. */ > retval = xhci_halt(xhci); > if (retval) > -- > 1.7.12.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] jfs: Several bugs in jfs_freeze() and jfs_unfreeze()
Vahram,
This is your first patch modified to be a little more robust. If there is
no objection, I'll push it to linux-next along with Gu's nointegrity
patch.
From: Vahram Martirosyan
Date: Fri, 24 May 2013 13:57:12 +0500
The mentioned functions do not pay attention to the error codes returned
by the functions updateSuper(), lmLogInit() and lmLogShutdown(). It brings
to system crash later when writing to log.
The patch adds corresponding code to check and return the error codes
and to print correct error messages in case of errors.
Found by Linux File System Verification project (linuxtesting.org).
Signed-off-by: Vahram Martirosyan
Reviewed-by: Gu Zheng
Signed-off-by: Dave Kleikamp
---
fs/jfs/super.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 2003e83..788e0a9 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -611,11 +611,28 @@ static int jfs_freeze(struct super_block *sb)
{
struct jfs_sb_info *sbi = JFS_SBI(sb);
struct jfs_log *log = sbi->log;
+ int rc = 0;
if (!(sb->s_flags & MS_RDONLY)) {
txQuiesce(sb);
- lmLogShutdown(log);
- updateSuper(sb, FM_CLEAN);
+ rc = lmLogShutdown(log);
+ if (rc) {
+ jfs_error(sb, "jfs_freeze: lmLogShutdown failed");
+
+ /* let operations fail rather than hang */
+ txResume(sb);
+
+ return rc;
+ }
+ rc = updateSuper(sb, FM_CLEAN);
+ if (rc) {
+ jfs_err("jfs_freeze: updateSuper failed\n");
+ /*
+* Don't fail here. Everything succeeded except
+* marking the superblock clean, so there's really
+* no harm in leaving it frozen for now.
+*/
+ }
}
return 0;
}
@@ -627,13 +644,18 @@ static int jfs_unfreeze(struct super_block *sb)
int rc = 0;
if (!(sb->s_flags & MS_RDONLY)) {
- updateSuper(sb, FM_MOUNT);
- if ((rc = lmLogInit(log)))
- jfs_err("jfs_unlock failed with return code %d", rc);
- else
- txResume(sb);
+ rc = updateSuper(sb, FM_MOUNT);
+ if (rc) {
+ jfs_error(sb, "jfs_unfreeze: updateSuper failed");
+ goto out;
+ }
+ rc = lmLogInit(log);
+ if (rc)
+ jfs_error(sb, "jfs_unfreeze: lmLogInit failed");
+out:
+ txResume(sb);
}
- return 0;
+ return rc;
}
static struct dentry *jfs_do_mount(struct file_system_type *fs_type,
--
1.8.2.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: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
On Fri, May 24, 2013 at 08:11:01PM +, Matthew Garrett wrote: > On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote: > > > One other data point is if the query_variable_info call is hacked to > > remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS) > > the efi_call_phys4() call fails with EFI_INVALID_PARAMETER and > > the system boots. Of course it does not create /sys/firmware/efivars > > entries and complains "[Firmware Bug]: efi: Inconsistent initial sizes". > > But at least it boots. > > EFI_VARIABLE_RUNTIME_ACCESS is only legal if > EFI_VARIABLE_BOOTSERVICE_ACCESS is set, so it's correct to throw > EFI_INVALID_PARAMETER there. Yes. The point of the experiment was to see if it returned a valid failure status (which it did) and see if the boot still failed (which it didn't). So something about going deeper into that call seems to trigger the failure. Why does the kernel still try to create /sys/firmware/efivars/ entries in the original failure even though efi_call_phys4() failed? Or does it always try to create those entries and GetNextVariable() blows up in the original failure but not in my experiment? Thanks, -- Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc r...@sgi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 04/11] KVM: MMU: zap pages in batch
On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote: > Zap at lease 10 pages before releasing mmu-lock to reduce the overload > caused by requiring lock > > After the patch, kvm_zap_obsolete_pages can forward progress anyway, > so update the comments > > [ It improves kernel building 0.6% ~ 1% ] Can you please describe the overload in more detail? Under what scenario is kernel building improved? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] jfs: Log shutdown error in jfs_freeze() function
On 05/24/2013 04:25 AM, Gu Zheng wrote:
> Hi Vahram,
>I saw the same issue in the bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=53331,
> and I sent out a patch this issue, but I've get any feedback.
Sorry I missed that bug. I just realized that bugzilla.kernel.org has
been sending my email to my old IBM address. I've got some catching up
to do.
> In fact, I think it's the right way to fix this issue,
> can you help to test it?
I might go with your patch for now, as it is an improvement, but I don't
really like the way that lmLogShutdown is skipped altogether during a
"nointegrity" unmount. If we skip it during a "nointegrity" freeze, we
should also skip lmLogInit on "nointegrity" unfreeze. I'd like to keep
the nointegrity logic in jfs_logmgr.c, but it would be easiest to fix in
the freeze and unfreeze functions. A code cleanup may be better than the
easy fix. I'll have to work on that.
It also looks like freeze/unfreeze doesn't take into account that two or
more mounted file systems can share the same journal. I don't know how
often, if ever, this is done in practice, but it looks like it would be
a problem. Two "nointegrity" mounts may have problem too. That should be
easy enough to verify.
Thanks,
Shaggy
>
> Thanks,
> Gu
>
>
> On 05/24/2013 04:57 PM, Vahram Martirosyan wrote:
>
>> In function jfs_freeze() the log is shut down through lmLogShutdown() call.
>> When the "nointegrity" mount option is enabled, the log is actually not
>> initialized. As a result the freeze operation in that case brings to a
>> kernel OOPS.
>>
>> The solution is to check if the "nointegrity" option is enabled and if it is
>> not
>> then shut the log down.
>>
>> May be this is not the best solution, but at least it fixes the OOPS.
>>
>> Found by Linux File System Verification project (linuxtesting.org)
>>
>> Signed-off-by: Vahram Martirosyan
>> ---
>> fs/jfs/super.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/jfs/super.c b/fs/jfs/super.c
>> index a3d424d..9788970 100644
>> --- a/fs/jfs/super.c
>> +++ b/fs/jfs/super.c
>> @@ -615,10 +615,12 @@ static int jfs_freeze(struct super_block *sb)
>>
>> if (!(sb->s_flags & MS_RDONLY)) {
>> txQuiesce(sb);
>> -rc = lmLogShutdown(log);
>> -if (rc != 0) {
>> -jfs_err("lmLogShutdown failed with return code %d", rc);
>> -return rc;
>> +if (!log->no_integrity) {
>> +rc = lmLogShutdown(log);
>> +if (rc != 0) {
>> +jfs_err("lmLogShutdown failed with return code
>> %d", rc);
>> +return rc;
>> +}
>> }
>> rc = updateSuper(sb, FM_CLEAN);
>> if (rc != 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: Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3
On Wed, 2013-05-22 at 13:59 +0200, Stanislaw Gruszka wrote: > > AFICT, we wake queues only if beacon arrives or mac80211 call drv_config > > with BSS_CHANGED_IDLE. I'm not sure if the latter prevent stuck. > > It should prevent stuck. When we fail to auth, drv_config() with > BSS_CHANGED_IDLE > is called via: > > ieee80211_destroy_auth_data -> > ieee80211_vif_release_channel -> > __ieee80211_vif_release_channel -> > ieee80211_unassign_vif_chanctx -> > ieee80211_bss_info_change_notify > > But there is need to have ->vif.chanctx_conf valid in > __ieee80211_vif_release_channel(), where is below condition: > > conf = rcu_dereference_protected(sdata->vif.chanctx_conf, > > lockdep_is_held(>chanctx_mtx)); > if (!conf) > return; > > I'm not sure if that always happen. Perhaps would be better to change > BSS_CHANGED_IDLE to BSS_CHANGED_BSSID, which is called directly from > ieee80211_destroy_auth_data() ? I don't think the "!conf" can hit in this case, since to even try to associate you have to have a channel context assigned. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] backlight: add devm_backlight_device_{register,unregister}()
On Thu, 16 May 2013 05:28:26 + (GMT) Jingoo Han wrote:
> These functions allow the driver core to automatically clean up any
> allocation made by backlight drivers. Thus it simplifies the error
> paths.
>
> ...
>
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -370,6 +370,81 @@ void backlight_device_unregister(struct backlight_device
> *bd)
> }
> EXPORT_SYMBOL(backlight_device_unregister);
>
> +static void devm_backlight_device_release(struct device *dev, void *res)
> +{
> + struct backlight_device *backlight = *(struct backlight_device **)res;
> +
> + backlight_device_unregister(backlight);
> +}
>
> ...
>
> +struct backlight_device *devm_backlight_device_register(struct device *dev,
> + const char *name, struct device *parent, void *devdata,
> + const struct backlight_ops *ops,
> + const struct backlight_properties *props)
> +{
> + struct backlight_device **ptr, *backlight;
> +
> + ptr = devres_alloc(devm_backlight_device_release, sizeof(*ptr),
> + GFP_KERNEL);
Well this is an awkward-looking thing. We allocate a silly little 4-
or 8-byte object just to track the backlight_device* via the devres
system.
I assume this was done so that devres could be used as a wrapper around
the existing code?
Really it would be better if things like backlight_device_register()
were themselves directly converted to use devm_foo(), yes?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/11] KVM: MMU: fast invalidate all pages
Hi Xiao,
On Thu, May 23, 2013 at 03:55:52AM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become worse if guest uses more memory or vcpus. It is not good for
> scalability
>
> In this patch, we introduce a faster way to invalidate all shadow pages.
> KVM maintains a global mmu invalid generation-number which is stored in
> kvm->arch.mmu_valid_gen and every shadow page stores the current global
> generation-number into sp->mmu_valid_gen when it is created
>
> When KVM need zap all shadow pages sptes, it just simply increase the
> global generation-number then reload root shadow pages on all vcpus.
> Vcpu will create a new shadow page table according to current kvm's
> generation-number. It ensures the old pages are not used any more.
> Then the obsolete pages (sp->mmu_valid_gen != kvm->arch.mmu_valid_gen)
> are zapped by using lock-break technique
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/kvm_host.h |2 +
> arch/x86/kvm/mmu.c | 84
> +++
> arch/x86/kvm/mmu.h |1 +
> 3 files changed, 87 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 3741c65..bff7d46 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -222,6 +222,7 @@ struct kvm_mmu_page {
> int root_count; /* Currently serving as active root */
> unsigned int unsync_children;
> unsigned long parent_ptes; /* Reverse mapping for parent_pte */
> + unsigned long mmu_valid_gen;
> DECLARE_BITMAP(unsync_child_bitmap, 512);
>
> #ifdef CONFIG_X86_32
> @@ -529,6 +530,7 @@ struct kvm_arch {
> unsigned int n_requested_mmu_pages;
> unsigned int n_max_mmu_pages;
> unsigned int indirect_shadow_pages;
> + unsigned long mmu_valid_gen;
> struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
> /*
>* Hash table of struct kvm_mmu_page.
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index f8ca2f3..f302540 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -1838,6 +1838,11 @@ static void clear_sp_write_flooding_count(u64 *spte)
> __clear_sp_write_flooding_count(sp);
> }
>
> +static bool is_obsolete_sp(struct kvm *kvm, struct kvm_mmu_page *sp)
> +{
> + return unlikely(sp->mmu_valid_gen != kvm->arch.mmu_valid_gen);
> +}
> +
> static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
>gfn_t gfn,
>gva_t gaddr,
> @@ -1900,6 +1905,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
> kvm_vcpu *vcpu,
>
> account_shadowed(vcpu->kvm, gfn);
> }
> + sp->mmu_valid_gen = vcpu->kvm->arch.mmu_valid_gen;
> init_shadow_page_table(sp);
> trace_kvm_mmu_get_page(sp, true);
> return sp;
> @@ -2070,8 +2076,10 @@ static int kvm_mmu_prepare_zap_page(struct kvm *kvm,
> struct kvm_mmu_page *sp,
> ret = mmu_zap_unsync_children(kvm, sp, invalid_list);
> kvm_mmu_page_unlink_children(kvm, sp);
> kvm_mmu_unlink_parents(kvm, sp);
> +
> if (!sp->role.invalid && !sp->role.direct)
> unaccount_shadowed(kvm, sp->gfn);
> +
> if (sp->unsync)
> kvm_unlink_unsync_page(kvm, sp);
> if (!sp->root_count) {
> @@ -4195,6 +4203,82 @@ restart:
> spin_unlock(>mmu_lock);
> }
>
> +static void kvm_zap_obsolete_pages(struct kvm *kvm)
> +{
> + struct kvm_mmu_page *sp, *node;
> + LIST_HEAD(invalid_list);
> +
> +restart:
> + list_for_each_entry_safe_reverse(sp, node,
> + >arch.active_mmu_pages, link) {
> + /*
> + * No obsolete page exists before new created page since
> + * active_mmu_pages is the FIFO list.
> + */
> + if (!is_obsolete_sp(kvm, sp))
> + break;
Can you add a comment to list_add(x, active_mmu_pages) callsites
mentioning this case?
Because it'll break silently if people do list_add_tail().
> + /*
> + * Do not repeatedly zap a root page to avoid unnecessary
> + * KVM_REQ_MMU_RELOAD, otherwise we may not be able to
> + * progress:
> + *vcpu 0vcpu 1
> + * call vcpu_enter_guest():
> + *1): handle KVM_REQ_MMU_RELOAD
> + *and require mmu-lock to
> + *load mmu
> + * repeat:
> + *1): zap root page and
> + *send KVM_REQ_MMU_RELOAD
> + *
> + *
Re: [PATCH 04/11] ipc: move locking out of ipcctl_pre_down_nolock
On Wed, 15 May 2013 18:08:03 -0700 Davidlohr Bueso
wrote:
> This function currently acquires both the rw_mutex and the rcu lock on
> successful lookups, leaving the callers to explicitly unlock them, creating
> another two level locking situation.
>
> Make the callers (including those that still use ipcctl_pre_down()) explicitly
> lock and unlock the rwsem and rcu lock.
>
> ...
>
> @@ -409,31 +409,38 @@ static int msgctl_down(struct ipc_namespace *ns, int
> msqid, int cmd,
> return -EFAULT;
> }
>
> + down_write(_ids(ns).rw_mutex);
> + rcu_read_lock();
> +
> ipcp = ipcctl_pre_down(ns, _ids(ns), msqid, cmd,
> _perm, msqid64.msg_qbytes);
> - if (IS_ERR(ipcp))
> - return PTR_ERR(ipcp);
> + if (IS_ERR(ipcp)) {
> + err = PTR_ERR(ipcp);
> + /* the ipc lock is not held upon failure */
Terms like "the ipc lock" are unnecessarily vague. It's better to
identify the lock by name, eg msg_queue.q_perm.lock.
Where should readers go to understand the overall locking scheme? A
description of the overall object hierarchy and the role which the
various locks play?
Have you done any performance testing of this patchset? Just from
squinting at it, I'd expect the effects to be small...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: XFS assertion from truncate. (3.10-rc2)
On Fri, May 24, 2013 at 06:03:00PM +1000, Dave Chinner wrote: > xfstest generic/193 is *supposed* to test behaviour of suid/sgid bits > and clearing them is various situations. > > You know what I'm about to say, don't you? The test doesn't test > what it thinks it is testing. it puts the destination file in root > directory of the xfstests harness, not in the filesystems being > tested. awesome, two bugs for the price of one! > So, on all my machines, it runs on ext3 filesystems, never on the > ext4, btrfs, xfs, etc filesystems that I'm actually testing. > > That's beside the point, because it doesn't test truncate behaviour. > But at least I know now why my attempts to reproduce the problem > didn't work... > > Right, patch below should fix the problem. Haven't seen anything out of the ordinary since I applied that, so I'd call it good. > What a frustrating bug. Now, where's my bottle of scotch? heh, enjoy the weekend. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote:
> One other data point is if the query_variable_info call is hacked to
> remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS)
> the efi_call_phys4() call fails with EFI_INVALID_PARAMETER and
> the system boots. Of course it does not create /sys/firmware/efivars
> entries and complains "[Firmware Bug]: efi: Inconsistent initial sizes".
> But at least it boots.
EFI_VARIABLE_RUNTIME_ACCESS is only legal if
EFI_VARIABLE_BOOTSERVICE_ACCESS is set, so it's correct to throw
EFI_INVALID_PARAMETER there.
--
Matthew Garrett | mj...@srcf.ucam.org
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCHv3 5/6] ARM: cubieboard: Enable ethernet (EMAC) support in dts
Hi Emilio,
On Fri, May 24, 2013 at 09:53:07AM -0300, Emilio López wrote:
> Hi,
>
> El 24/05/13 06:23, Maxime Ripard escribió:
> > From: Stefan Roese
> >
> > Signed-off-by: Stefan Roese
> > ---
> > arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> > b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> > index b70fe0d..32d9b18 100644
> > --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> > +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> > @@ -27,6 +27,21 @@
> > };
> >
> > soc@01c2 {
> > + emac: ethernet@01c0b000 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins_a>;
> > + phy = <>;
> > + status = "okay";
> > + };
> > +
> > + mdio@01c0b080 {
> > + status = "okay";
> > +
> > + phy0: ethernet-phy@0 {
> > + reg = <0>;
> > + };
>
> During my testing I found out that I needed to use 1 as reg for the
> driver to work. You can find a fixup patch enclosed that changes this;
> it's possible that some extra changes may also be needed (s/phy0/phy1/
> on the node?)
Merged, thanks for noticing!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/6] net: Add EMAC ethernet driver found on Allwinner A10 SoC's
Hi Emilio, On Fri, May 24, 2013 at 09:46:32AM -0300, Emilio López wrote: > El 24/05/13 06:23, Maxime Ripard escribió: > > From: Stefan Roese > > > > The Allwinner A10 has an ethernet controller that seem to be developped > > internally by them. > > > > The exact feature set of this controller is unknown, since there is no > > public documentation for this IP, and this driver is mostly the one > > published by Allwinner that has been heavily cleaned up. > > > > Signed-off-by: Stefan Roese > > Signed-off-by: Maxime Ripard > > --- > > (snip) > > > + > > +config SUN4I_EMAC > > +tristate "Allwinner A10 EMAC support" > > + depends on ARCH_SUNXI > > + depends on OF > > + select CRC32 > > + select NET_CORE > > + select MII > > + select REGULATOR_FIXED_VOLTAGE > > +---help--- > > + Support for Allwinner A10 EMAC ethernet driver. > > + > > + To compile this driver as a module, choose M here. The module > > + will be called sun4i-emac. > > + > > You also need to select REGULATOR when you select REGULATOR_FIXED_VOLTAGE Actually, this should be in patch 2/6. Thanks for noticing! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote: > On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote: > >efi: mem127: type=4, attr=0xf, > > range=[0x6bb22000-0x7ca9c000) (271MB) > > EFI_BOOT_SERVICES_CODE > > >efi: mem133: type=5, attr=0x800f, > > range=[0x7daff000-0x7dbff000) (1MB) > > EFI_RUNTIME_SERVICES_CODE > > >EFI Variables Facility v0.08 2004-May-17 > >BUG: unable to handle kernel paging request at 7ca95b10 > >IP: [] 0x88007dbf213f > > > [] ? efi_call3+0x43/0x80 > > [] ? virt_efi_get_next_variable+0x47/0x1c0 > > [] ? create_efivars_bin_attributes+0x150/0x150 > > [] ? efivar_init+0xd5/0x390 > > [] ? efivar_update_sysfs_entries+0x90/0x90 > > [] ? kobject_uevent+0xb/0x10 > > [] ? kset_register+0x5b/0x70 > > [] ? create_efivars_bin_attributes+0x150/0x150 > > [] ? efivars_sysfs_init+0x87/0xf0 > > [] ? do_one_initcall+0x15a/0x1b0 > > [] ? do_basic_setup+0xad/0xce > > [] ? kernel_init_freeable+0x291/0x291 > > [] ? sched_init_smp+0x15b/0x162 > > [] ? kernel_init_freeable+0x20d/0x291 > > [] ? rest_init+0x80/0x80 > > [] ? kernel_init+0xe/0x180 > > [] ? ret_from_fork+0x7c/0xb0 > > [] ? rest_init+0x80/0x80 > > Here's the real call stack leading up to the crash. > > What appears to be happening is that your the EFI runtime services code > is calling into the EFI boot services code, which is definitely a bug in > your firmware because we're at runtime, but we've seen other machines > that do similar things so we usually handle it just fine. However, what > makes your case different, and the reason you see the above splat, is > that it's using the physical address of the EFI boot services region, > not the virtual one we setup with SetVirtualAddressMap(). Which is a > second firmware bug. Again, we have seen other machines that access > physical addresses after SetVirtualAddressMap(), but until now we > haven't had any non-optional code that triggered them. > > The only reason I can see that the offending commit would introduce this > problem is because it calls QueryVariableInfo() at boot time. I notice > that your machine is an SGI UV one, is there any chance you could get a > firmware fix for this? If possible, it would be also good to confirm > that it's this chunk of code in setup_efi_vars(), > > status = efi_call_phys4(sys_table->runtime->query_variable_info, > EFI_VARIABLE_NON_VOLATILE | > EFI_VARIABLE_BOOTSERVICE_ACCESS | > EFI_VARIABLE_RUNTIME_ACCESS, _size, > _size, _size); This call is failing, but not returning a valid EFI_* return status. setup_efi_vars() returns at that point. Maybe it is not set up to do GetNextVariable() later on??? Why call GetNextVariable() if the earlier call failed? > that later makes GetNextVariable() jump to the physical address of the > EFI Boot Services region. Because if not, we need to do some more > digging. One other data point is if the query_variable_info call is hacked to remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS) the efi_call_phys4() call fails with EFI_INVALID_PARAMETER and the system boots. Of course it does not create /sys/firmware/efivars entries and complains "[Firmware Bug]: efi: Inconsistent initial sizes". But at least it boots. One of the BIOS guys will build a debug bios next week to help see what is going on in the query_variable_info() call. > Borislav, how are your 1:1 mapping patches coming along? In theory, once > those are merged we can gracefully workaround these kinds of issues. > > -- > Matt Fleming, Intel Open Source Technology Center -- Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc r...@sgi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dma: mxs-dma: Staticize mxs_dma_xlate
From: Fabio Estevam
Fix the following sparse warning:
drivers/dma/mxs-dma.c:696:17: warning: symbol 'mxs_dma_xlate' was not declared.
Should it be static?
Signed-off-by: Fabio Estevam
---
drivers/dma/mxs-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index b48a79c..7195930 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -693,7 +693,7 @@ static bool mxs_dma_filter_fn(struct dma_chan *chan, void
*fn_param)
return true;
}
-struct dma_chan *mxs_dma_xlate(struct of_phandle_args *dma_spec,
+static struct dma_chan *mxs_dma_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma)
{
struct mxs_dma_engine *mxs_dma = ofdma->of_dma_data;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] coredump: kill call_count, add core_name_size
On Wed, 15 May 2013 22:12:32 +0200 Oleg Nesterov wrote: > Imho, "atomic_t call_count" is ugly and should die. It buys > nothing and in fact it can grow more than necessary, expand > doesn't check if it was already incremented by another task. > > Kill it, and introduce "static int core_name_size" updated by > expand_corename(). This is obviously racy too but harmless, > and core_name_size never grows for no reason. > > We do not bother to to calculate the "right" new size, we > simply do kmalloc(size_we_need) and use ksize() to rely on > kmalloc_index's decision. > > Finally change format_corename() to use expand_corename(), > krealloc(NULL) is fine. The code still looks like a bunch of fluff. I look at it and think "wtf, why doesn't it just use kasprintf()". If there were any comments in there at all which explained the reason for the code's existence, perhaps I wouldn't think that. But there aren't, so I do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/3] x86/microcode: early microcode patch loading support on AMD
On Fri, May 24, 2013 at 03:33:38PM +, Yu, Fenghua wrote:
> > From: Jacob Shin [mailto:jacob.s...@amd.com]
> > Add support for early microcode patch loading on AMD.
> >
> > Signed-off-by: Jacob Shin
> > ---
> > arch/x86/Kconfig | 16 +-
> > arch/x86/include/asm/microcode.h |1 -
> > arch/x86/include/asm/microcode_amd.h | 17 ++
> > arch/x86/include/asm/microcode_intel.h |1 +
> > arch/x86/kernel/microcode_amd.c| 338
> >
> > arch/x86/kernel/microcode_core_early.c |7 +
> > 6 files changed, 333 insertions(+), 47 deletions(-)
> > create mode 100644 arch/x86/include/asm/microcode_amd.h
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 3a5bced..fab72e7 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1090,8 +1090,18 @@ config MICROCODE_INTEL_LIB
> > depends on MICROCODE_INTEL
> >
> > config MICROCODE_INTEL_EARLY
> > - bool "Early load microcode"
> > + def_bool n
> > depends on MICROCODE_INTEL && BLK_DEV_INITRD
> > +
> > +config MICROCODE_AMD_EARLY
> > + def_bool n
> > + depends on MICROCODE_AMD && BLK_DEV_INITRD
> > +
> > +config MICROCODE_EARLY
> > + bool "Early load microcode"
> > + depends on (MICROCODE_INTEL || MICROCODE_AMD) && BLK_DEV_INITRD
> > + select MICROCODE_INTEL_EARLY if MICROCODE_INTEL
> > + select MICROCODE_AMD_EARLY if MICROCODE_AMD
> > default y
> > help
> > This option provides functionality to read additional microcode
> > data
> > @@ -1099,10 +1109,6 @@ config MICROCODE_INTEL_EARLY
> > microcode to CPU's as early as possible. No functional change
> > if no
> > microcode data is glued to the initrd, therefore it's safe to
> > say Y.
> >
> > -config MICROCODE_EARLY
> > - def_bool y
> > - depends on MICROCODE_INTEL_EARLY
> > -
> > config X86_MSR
> > tristate "/dev/cpu/*/msr - Model-specific register support"
> > ---help---
> > diff --git a/arch/x86/include/asm/microcode.h
> > b/arch/x86/include/asm/microcode.h
> > index 6825e2e..f4be4cc 100644
> > --- a/arch/x86/include/asm/microcode.h
> > +++ b/arch/x86/include/asm/microcode.h
> > @@ -58,7 +58,6 @@ static inline void __exit exit_amd_microcode(void) {}
> > #endif
> >
> > #ifdef CONFIG_MICROCODE_EARLY
> > -#define MAX_UCODE_COUNT 128
> > extern void __init load_ucode_bsp(void);
> > extern __init void load_ucode_ap(void);
> > extern int __init save_microcode_in_initrd(void);
> > diff --git a/arch/x86/include/asm/microcode_amd.h
> > b/arch/x86/include/asm/microcode_amd.h
> > new file mode 100644
> > index 000..376123c
> > --- /dev/null
> > +++ b/arch/x86/include/asm/microcode_amd.h
> > @@ -0,0 +1,17 @@
> > +#ifndef _ASM_X86_MICROCODE_AMD_H
> > +#define _ASM_X86_MICROCODE_AMD_H
> > +
> > +#ifdef CONFIG_MICROCODE_AMD_EARLY
> > +extern void __init load_ucode_amd_bsp(void);
> > +extern void __cpuinit load_ucode_amd_ap(void);
> > +extern int __init save_microcode_in_initrd_amd(void);
> > +#else
> > +static inline void __init load_ucode_amd_bsp(void) {}
> > +static inline void __cpuinit load_ucode_amd_ap(void) {}
> > +static inline int __init save_microcode_in_initrd_amd(void)
> > +{
> > + return -EINVAL;
> > +}
> > +#endif
> > +
> > +#endif /* _ASM_X86_MICROCODE_AMD_H */
> > diff --git a/arch/x86/include/asm/microcode_intel.h
> > b/arch/x86/include/asm/microcode_intel.h
> > index 538e407..db4a2f9 100644
> > --- a/arch/x86/include/asm/microcode_intel.h
> > +++ b/arch/x86/include/asm/microcode_intel.h
> > @@ -64,6 +64,7 @@ extern int
> > update_match_revision(struct microcode_header_intel *mc_header, int
> > rev);
> >
> > #ifdef CONFIG_MICROCODE_INTEL_EARLY
> > +#define MAX_UCODE_COUNT 128
> > extern void __init load_ucode_intel_bsp(void);
> > extern void __cpuinit load_ucode_intel_ap(void);
> > extern void show_ucode_info_early(void);
> > diff --git a/arch/x86/kernel/microcode_amd.c
> > b/arch/x86/kernel/microcode_amd.c
> > index efdec7c..cda647e 100644
> > --- a/arch/x86/kernel/microcode_amd.c
> > +++ b/arch/x86/kernel/microcode_amd.c
> > @@ -27,10 +27,13 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > +#include
> > #include
> > #include
> > +#include
> >
> > MODULE_DESCRIPTION("AMD Microcode Update Driver");
> > MODULE_AUTHOR("Peter Oruba");
> > @@ -84,23 +87,28 @@ struct ucode_patch {
> >
> > static LIST_HEAD(pcache);
> >
> > -static u16 find_equiv_id(unsigned int cpu)
> > +static u16 _find_equiv_id(struct equiv_cpu_entry *eq,
> > + struct ucode_cpu_info *uci)
> > {
> > - struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
> > int i = 0;
> >
> > - if (!equiv_cpu_table)
> > + if (!eq)
> > return 0;
> >
> > - while (equiv_cpu_table[i].installed_cpu != 0) {
> > - if (uci->cpu_sig.sig == equiv_cpu_table[i].installed_cpu)
> > - return equiv_cpu_table[i].equiv_cpu;
> > + while (eq[i].installed_cpu != 0) {
> > +
Re: [RESEND PATCH] pwm: pwm-atmel-tcb: pinctrl support
On 10:15 Fri 24 May , boris brezillon wrote: > On 23/05/2013 21:35, Thierry Reding wrote: > >On Thu, May 23, 2013 at 06:38:52PM +0200, Boris BREZILLON wrote: > >>Hello, > >> > >>I sent a patch 1 month ago to add pinctrl support to pwm-atmel-tcb > >>driver and didn't get any review. > >> > >>Could you take a look? > >> > >>This patch adds pins request for the pwm device exposed by the TC > >>block using the pinctrl subsystem. > >I was actually looking at this a few days back and thought I remembered > >this being handled in the core now. There was some discussion about this > >back in January (?) as far as I remember. I just verified that indeed > >there is code in the driver core code to do this. See commit: > > > > ab78029ecc347debbd737f06688d788bd9d60c1d drivers/pinctrl: grab default > > handles from device core > > > >Are you sure this is really necessary in the driver? > No. > > Thanks for pointing this commit out (I didn't notice the default > handles were grabbed > from device core). > > I'll test it without this patch. You can drop it, it's handled at core level for every struct device Best Regards, J. > > Best Regards, > Boris > >Thierry > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] aerdrv: Move cper_print_aer() call out of interrupt context
On Thu, May 9, 2013 at 1:51 PM, Lance Ortiz wrote:
> The following warning was seen on 3.9 when a corrected PCIe error was being
> handled by the AER subsystem.
>
> WARNING: at .../drivers/pci/search.c:214 pci_get_dev_by_id+0x8a/0x90()
>
> This occurred because a call to pci_get_domain_bus_and_slot() was added to
> cper_print_pcie() to setup for the call to cper_print_aer(). The warning
> showed up because cper_print_pcie() is called in an interrupt context and
> pci_get* functions are not supposed to be called in that context.
>
> The solution is to move the cper_print_aer() call out of the interrupt
> context and into aer_recover_work_func() to avoid any warnings when calling
> pci_get* functions.
>
> v2 - Re-worded header text. Removed prefix arg from cper_print_aer().
> Added TODO message in cper_print_aer().
>
> Signed-off-by: Lance Ortiz
> Acked-by: Borislav Petkov
> ---
>
> drivers/acpi/apei/cper.c | 18 --
> drivers/acpi/apei/ghes.c |3 ++-
> drivers/pci/pcie/aer/aerdrv_core.c |6 +-
> drivers/pci/pcie/aer/aerdrv_errprint.c | 10 --
> include/linux/aer.h|4 ++--
> 5 files changed, 17 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
> index 1e5d8a4..8713229 100644
> --- a/drivers/acpi/apei/cper.c
> +++ b/drivers/acpi/apei/cper.c
> @@ -250,10 +250,6 @@ static const char *cper_pcie_port_type_strs[] = {
> static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie
> *pcie,
> const struct acpi_hest_generic_data *gdata)
> {
> -#ifdef CONFIG_ACPI_APEI_PCIEAER
> - struct pci_dev *dev;
> -#endif
> -
> if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
> printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
>pcie->port_type < ARRAY_SIZE(cper_pcie_port_type_strs)
> ?
> @@ -285,20 +281,6 @@ static void cper_print_pcie(const char *pfx, const
> struct cper_sec_pcie *pcie,
> printk(
> "%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> -#ifdef CONFIG_ACPI_APEI_PCIEAER
> - dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
> - pcie->device_id.bus, pcie->device_id.function);
> - if (!dev) {
> - pr_err("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
> - pcie->device_id.segment, pcie->device_id.bus,
> - pcie->device_id.slot, pcie->device_id.function);
> - return;
> - }
> - if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO)
> - cper_print_aer(pfx, dev, gdata->error_severity,
> - (struct aer_capability_regs *)
> pcie->aer_info);
> - pci_dev_put(dev);
> -#endif
> }
>
> static const char *apei_estatus_section_flag_strs[] = {
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index d668a8a..f2084b5 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -454,7 +454,8 @@ static void ghes_do_proc(struct ghes *ghes,
> aer_severity = cper_severity_to_aer(sev);
> aer_recover_queue(pcie_err->device_id.segment,
> pcie_err->device_id.bus,
> - devfn, aer_severity);
> + devfn, aer_severity,
> + pcie_err->aer_info);
> }
>
> }
> diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
> b/drivers/pci/pcie/aer/aerdrv_core.c
> index 564d97f..ceba124 100644
> --- a/drivers/pci/pcie/aer/aerdrv_core.c
> +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> @@ -582,6 +582,7 @@ struct aer_recover_entry
> u8 devfn;
> u16 domain;
> int severity;
> + u8 *regs;
> };
>
> static DEFINE_KFIFO(aer_recover_ring, struct aer_recover_entry,
> @@ -595,7 +596,7 @@ static DEFINE_SPINLOCK(aer_recover_ring_lock);
> static DECLARE_WORK(aer_recover_work, aer_recover_work_func);
>
> void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
> - int severity)
> + int severity, u8 *aer_regs)
> {
> unsigned long flags;
> struct aer_recover_entry entry = {
> @@ -603,6 +604,7 @@ void aer_recover_queue(int domain, unsigned int bus,
> unsigned int devfn,
> .devfn = devfn,
> .domain = domain,
> .severity = severity,
> + .regs = aer_regs,
> };
>
> spin_lock_irqsave(_recover_ring_lock, flags);
> @@ -629,6 +631,8 @@ static void aer_recover_work_func(struct work_struct
> *work)
>
[PATCH] cciss: fix broken mutex usage in ioctl
From: Stephen M. Cameron
If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
(as is normal with the Array Configuration Utility) the process
will hang as below. It attempts to acquire the same mutex twice, once
in do_ioctl() and once in cciss_unlocked_open(). The BKL was recursive,
the mutex isn't.
Linux version 3.10.0-rc2 (scameron@localhost.localdomain) (gcc version 4.4.7
20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Fri May 24 14:32:12 CDT 2013
[...]
acu D 0001 0 3246 3191 0x0080
8800da833a18 0086 8800da833fd8 00012d00
8800da832010 00012d00 00012d00 00012d00
8800da833fd8 00012d00 8800da8294e0 8800db50eb10
Call Trace:
[] schedule+0x29/0x70
[] schedule_preempt_disabled+0xe/0x10
[] __mutex_lock_slowpath+0x17b/0x220
[] mutex_lock+0x2b/0x50
[] cciss_unlocked_open+0x2f/0x110 [cciss]
[] __blkdev_get+0xd3/0x470
[] blkdev_get+0x5c/0x1e0
[] register_disk+0x182/0x1a0
[] add_disk+0x17c/0x310
[] cciss_add_disk+0x13a/0x170 [cciss]
[] cciss_update_drive_info+0x39b/0x480 [cciss]
[] rebuild_lun_table+0x258/0x370 [cciss]
[] cciss_ioctl+0x34f/0x470 [cciss]
[] ? mutex_lock+0x1e/0x50
[] do_ioctl+0x49/0x70 [cciss]
[] __blkdev_driver_ioctl+0x28/0x30
[] blkdev_ioctl+0x200/0x7b0
[] ? mntput+0x23/0x40
[] block_ioctl+0x3c/0x40
[] do_vfs_ioctl+0x89/0x350
[] ? fput+0xe/0x10
[] ? task_work_run+0x94/0xf0
[] SyS_ioctl+0xa1/0xb0
[] system_call_fastpath+0x16/0x1b
This mutex usage was added into the ioctl path when the big kernel
lock was removed. As it turns out, these paths are all thread
safe anyway (or can easily be made so) and we don't want ioctl()
to be single threaded in any case.
Signed-off-by: Stephen M. Cameron
Cc: sta...@vger.kernel.org
---
drivers/block/cciss.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 6374dc1..62b6c2c 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -168,8 +168,6 @@ static irqreturn_t do_cciss_msix_intr(int irq, void
*dev_id);
static int cciss_open(struct block_device *bdev, fmode_t mode);
static int cciss_unlocked_open(struct block_device *bdev, fmode_t mode);
static void cciss_release(struct gendisk *disk, fmode_t mode);
-static int do_ioctl(struct block_device *bdev, fmode_t mode,
- unsigned int cmd, unsigned long arg);
static int cciss_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg);
static int cciss_getgeo(struct block_device *bdev, struct hd_geometry *geo);
@@ -235,7 +233,7 @@ static const struct block_device_operations cciss_fops = {
.owner = THIS_MODULE,
.open = cciss_unlocked_open,
.release = cciss_release,
- .ioctl = do_ioctl,
+ .ioctl = cciss_ioctl,
.getgeo = cciss_getgeo,
#ifdef CONFIG_COMPAT
.compat_ioctl = cciss_compat_ioctl,
@@ -1143,16 +1141,6 @@ static void cciss_release(struct gendisk *disk, fmode_t
mode)
mutex_unlock(_mutex);
}
-static int do_ioctl(struct block_device *bdev, fmode_t mode,
- unsigned cmd, unsigned long arg)
-{
- int ret;
- mutex_lock(_mutex);
- ret = cciss_ioctl(bdev, mode, cmd, arg);
- mutex_unlock(_mutex);
- return ret;
-}
-
#ifdef CONFIG_COMPAT
static int cciss_ioctl32_passthru(struct block_device *bdev, fmode_t mode,
@@ -1179,7 +1167,7 @@ static int cciss_compat_ioctl(struct block_device *bdev,
fmode_t mode,
case CCISS_REGNEWD:
case CCISS_RESCANDISK:
case CCISS_GETLUNINFO:
- return do_ioctl(bdev, mode, cmd, arg);
+ return cciss_ioctl(bdev, mode, cmd, arg);
case CCISS_PASSTHRU32:
return cciss_ioctl32_passthru(bdev, mode, cmd, arg);
@@ -1219,7 +1207,7 @@ static int cciss_ioctl32_passthru(struct block_device
*bdev, fmode_t mode,
if (err)
return -EFAULT;
- err = do_ioctl(bdev, mode, CCISS_PASSTHRU, (unsigned long)p);
+ err = cciss_ioctl(bdev, mode, CCISS_PASSTHRU, (unsigned long)p);
if (err)
return err;
err |=
@@ -1261,7 +1249,7 @@ static int cciss_ioctl32_big_passthru(struct block_device
*bdev, fmode_t mode,
if (err)
return -EFAULT;
- err = do_ioctl(bdev, mode, CCISS_BIG_PASSTHRU, (unsigned long)p);
+ err = cciss_ioctl(bdev, mode, CCISS_BIG_PASSTHRU, (unsigned long)p);
if (err)
return err;
err |=
@@ -1311,11 +1299,14 @@ static int cciss_getpciinfo(ctlr_info_t *h, void __user
*argp)
static int cciss_getintinfo(ctlr_info_t *h, void __user *argp)
{
cciss_coalint_struct intinfo;
+ unsigned long flags;
if (!argp)
return -EINVAL;
+ spin_lock_irqsave(>lock, flags);
intinfo.delay =
Re: rcu_read_lock() used illegally while idle!
On Fri, 2013-05-24 at 10:23 -0400, Dave Jones wrote:
> .config: http://paste.fedoraproject.org/14281/94052971/raw/
>
> trace shows the problem process was 'cc1', so I was likely building a kernel
> at the time. There was also a trinity run going on in the background.
>
> cmdline: nothing special..
>
> BOOT_IMAGE=/vmlinuz-3.10.0-rc2+
> root=UUID=bee21cd9-1852-4d1d-9e9d-2e44332b8df1 ro rd.md=0 rd.lvm=0 rd.dm=0
> vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 consoleblank=0
> console=ttyUSB0,115200 console=tty0 pause_on_oops=30 audit=0
>
OK, I'm able to reproduce this. Looks like the same issue happens from
other ways from userspace into the kernel (the next way was tracing
system calls).
Forget the other patch. Here's a new patch that is more specific to
tracing and context tracking.
Can you try this one out, please.
-- Steve
diff --git a/include/linux/preempt.h b/include/linux/preempt.h
index 87a03c7..f5d4723 100644
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -33,9 +33,25 @@ do { \
preempt_schedule(); \
} while (0)
+#ifdef CONFIG_CONTEXT_TRACKING
+
+void preempt_schedule_context(void);
+
+#define preempt_check_resched_context() \
+do { \
+ if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \
+ preempt_schedule_context(); \
+} while (0)
+#else
+
+#define preempt_check_resched_context() preempt_check_resched()
+
+#endif /* CONFIG_CONTEXT_TRACKING */
+
#else /* !CONFIG_PREEMPT */
#define preempt_check_resched()do { } while (0)
+#define preempt_check_resched_context()do { } while (0)
#endif /* CONFIG_PREEMPT */
@@ -88,7 +104,7 @@ do { \
do { \
preempt_enable_no_resched_notrace(); \
barrier(); \
- preempt_check_resched(); \
+ preempt_check_resched_context(); \
} while (0)
#else /* !CONFIG_PREEMPT_COUNT */
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 65349f0..ac3a312 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -71,6 +71,46 @@ void user_enter(void)
local_irq_restore(flags);
}
+/**
+ * preempt_schedule_context - preempt_schedule called by tracing
+ *
+ * The tracing infrastructure uses preempt_enable_notrace to prevent
+ * recursion and tracing preempt enabling caused by the tracing
+ * infrastructure itself. But as tracing can happen in areas coming
+ * from userspace or just about to enter userspace, a preempt enable
+ * can occur before user_exit() is called. This will cause the scheduler
+ * to be called when the system is still in usermode.
+ *
+ * To prevent this, the preempt_enable_notrace will use this function
+ * instead of preempt_schedule() to exit user context if needed before
+ * calling the scheduler.
+ */
+void __sched notrace preempt_schedule_context(void)
+{
+ struct thread_info *ti = current_thread_info();
+ enum ctx_state prev_ctx;
+
+ if (likely(ti->preempt_count || irqs_disabled()))
+ return;
+
+ /*
+* Need to disable preemption in case user_exit() is traced
+* and the tracer calls preempt_enable_notrace() causing
+* an infinite recursion.
+*/
+ preempt_disable_notrace();
+ prev_ctx = this_cpu_read(context_tracking.state);
+ user_exit();
+ preempt_enable_no_resched_notrace();
+
+ preempt_schedule();
+
+ preempt_disable_notrace();
+ if (prev_ctx == IN_USER)
+ user_enter();
+ preempt_enable_notrace();
+}
+EXPORT_SYMBOL(preempt_schedule_context);
/**
* user_exit - Inform the context tracking that the CPU is
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: Add Option GTM681W to qcserial device table.
Richard Weinberger writes: > Am 24.05.2013 15:18, schrieb Bjørn Mork: >> Richard Weinberger writes: >> >>> The Option GTM681W uses a qualcomm chip and can be >>> served by the qcserial device driver. >> >> Should it also be added to the qmi_wwan driver? > > Don't know. But I can happily test it. :) > Can you please explain me how to use the qmi_wwan driver? > I've never used it. The QMI management protocol is delegated to userspace using a /dev/cdc-wdmX character device. So you need a userspace component to test the driver, like for example libqmi. See http://sigquit.wordpress.com/2012/08/20/an-introduction-to-libqmi/ for a short intro. This library is packaged in Debian. Don't know the status of other distros. The driver supports dynamic device IDs, so if you have qcserial bound to all serial ports, and there is a QMI interface with no driver bound yet, then testing should be as easy as modprobe qmi_wwan echo "0af0 8120" >/sys/bus/usb/drivers/qmi_wwan/new_id qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9.4
diff --git a/Makefile b/Makefile
index 01003d4..bfbfaf9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 9
-SUBLEVEL = 3
+SUBLEVEL = 4
EXTRAVERSION =
NAME = Unicycling Gorilla
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index 0c3ba9f..f4726dc 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -136,8 +136,6 @@ void disable_debug_monitors(enum debug_el el)
*/
static void clear_os_lock(void *unused)
{
- asm volatile("msr mdscr_el1, %0" : : "r" (0));
- isb();
asm volatile("msr oslar_el1, %0" : : "r" (0));
isb();
}
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index abe69b8..48a3860 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -52,7 +52,7 @@ loop1:
add x2, x2, #4 // add 4 (line length offset)
mov x4, #0x3ff
and x4, x4, x1, lsr #3 // find maximum number on the
way size
- clz x5, x4 // find bit position of way
size increment
+ clz w5, w4 // find bit position of way
size increment
mov x7, #0x7fff
and x7, x7, x1, lsr #13 // extract max number of the
index size
loop2:
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index f1d8b9b..a82ae88 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -119,8 +119,7 @@ ENTRY(__cpu_setup)
mov x0, #3 << 20
msr cpacr_el1, x0 // Enable FP/ASIMD
- mov x0, #1
- msr oslar_el1, x0 // Set the debug OS lock
+ msr mdscr_el1, xzr // Reset mdscr_el1
tlbivmalle1is // invalidate I + D TLBs
/*
* Memory region attributes for LPAE:
diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 6cf0a9c..5a0be0a 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -37,8 +37,8 @@ asmlinkage int sys_get_thread_area(struct user_desc __user *);
unsigned long sys_sigreturn(void);
/* kernel/vm86_32.c */
-int sys_vm86old(struct vm86_struct __user *);
-int sys_vm86(unsigned long, unsigned long);
+asmlinkage long sys_vm86old(struct vm86_struct __user *);
+asmlinkage long sys_vm86(unsigned long, unsigned long);
#else /* CONFIG_X86_32 */
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 1c68ccb..8f3201d 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -34,7 +34,7 @@
extern pgd_t early_level4_pgt[PTRS_PER_PGD];
extern pmd_t early_dynamic_pgts[EARLY_DYNAMIC_PAGE_TABLES][PTRS_PER_PMD];
static unsigned int __initdata next_early_pgt = 2;
-pmdval_t __initdata early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL |
_PAGE_NX);
+pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL | _PAGE_NX);
/* Wipe all early page tables except for the kernel symbol map */
static void __init reset_early_page_tables(void)
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 1cf5766..3dbdd9c 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,7 +49,6 @@
#include
#include
#include
-#include
/*
* Known problems:
@@ -202,17 +202,16 @@ out:
static int do_vm86_irq_handling(int subfunction, int irqnumber);
static void do_sys_vm86(struct kernel_vm86_struct *info, struct task_struct
*tsk);
-int sys_vm86old(struct vm86_struct __user *v86)
+SYSCALL_DEFINE1(vm86old, struct vm86_struct __user *, v86)
{
struct kernel_vm86_struct info; /* declare this _on top_,
* this avoids wasting of stack space.
* This remains on the stack until we
* return to 32 bit user space.
*/
- struct task_struct *tsk;
+ struct task_struct *tsk = current;
int tmp, ret = -EPERM;
- tsk = current;
if (tsk->thread.saved_sp0)
goto out;
tmp = copy_vm86_regs_from_user(, >regs,
@@ -227,11 +226,12 @@ int sys_vm86old(struct vm86_struct __user *v86)
do_sys_vm86(, tsk);
ret = 0;/* we never return here */
out:
+ asmlinkage_protect(1, ret, v86);
return ret;
}
-int sys_vm86(unsigned long cmd, unsigned long arg)
+SYSCALL_DEFINE2(vm86, unsigned long, cmd, unsigned long, arg)
{
struct kernel_vm86_struct info; /* declare this _on top_,
* this avoids wasting of stack space.
@@ -278,6 +278,7 @@ int sys_vm86(unsigned long cmd, unsigned long arg)
do_sys_vm86(, tsk);
ret = 0;/* we never return here */
out:
+
Linux 3.9.4
I'm announcing the release of the 3.9.4 kernel. All users of the 3.9 kernel series must upgrade. The updated 3.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm64/kernel/debug-monitors.c |2 arch/arm64/mm/cache.S |2 arch/arm64/mm/proc.S|3 arch/x86/include/asm/syscalls.h |4 arch/x86/kernel/head64.c|2 arch/x86/kernel/vm86_32.c | 11 - drivers/gpu/drm/nouveau/core/subdev/bios/init.c |4 drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/radeon_ttm.c |2 drivers/gpu/drm/radeon/si.c |4 drivers/hwmon/abituguru.c | 16 +- drivers/i2c/busses/i2c-designware-core.c| 14 + drivers/i2c/busses/i2c-designware-core.h|2 drivers/net/ntb_netdev.c|2 drivers/ntb/ntb_hw.c| 10 - drivers/ntb/ntb_transport.c | 175 +++- fs/btrfs/ioctl.c| 10 - include/uapi/linux/virtio_console.h |2 19 files changed, 170 insertions(+), 101 deletions(-) Alexander van Heukelum (1): x86, vm86: fix VM86 syscalls: use SYSCALL_DEFINEx(...) Ben Skeggs (1): drm/nouveau/bios: fix thinko in ZM_MASK_ADD opcode Dan Carpenter (2): ntb: off by one sanity checks NTB: fix pointer math issues Gabriel de Perthuis (1): btrfs: don't stop searching after encountering the wrong item Greg Kroah-Hartman (1): Linux 3.9.4 Jon Mason (8): NTB: variable dereferenced before check NTB: Handle 64bit BAR sizes NTB: Link toggle memory leak NTB: reset tx_index on link toggle NTB: Correctly handle receive buffers of the minimal size NTB: memcpy lockup workaround ntb_netdev: remove from list on exit NTB: Multiple NTB client fix Josef Ahmad (1): i2c: designware: fix RX FIFO overrun Linus Torvalds (1): x86: Fix bit corruption at CPU resume time Michael S. Tsirkin (1): virtio_console: fix uapi header Mika Westerberg (1): i2c: designware: always clear interrupts before enabling them Niels Ole Salscheider (1): drm/radeon: Fix VRAM size calculation for VRAM >= 4GB Sukanto Ghosh (1): arm64: mm: Fix operands of clz in __flush_dcache_all Wei Yongjun (1): hwmon: fix error return code in abituguru_probe() Will Deacon (1): arm64: debug: clear mdscr_el1 instead of taking the OS lock signature.asc Description: Digital signature
Re: [PATCH v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/17/2013 11:17 AM, Dan Murphy wrote:
> On 05/17/2013 11:15 AM, Nishanth Menon wrote:
>> On 11:02-20130517, Dan Murphy wrote:
>>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>>> are different.
>>>
>>> A1-A3 = gpio_wk7
>>> ES = gpio_110
>>>
>>> There is no change to LED D2
>>>
>>> Abstract away the pinmux and the LED definitions for the two boards into
>>> the respective DTS files.
>>>
>>> Signed-off-by: Dan Murphy
>>> ---
>>> Changes in this version:
>>> - review comments incorporated.
>>> Previous version of this patch was discussed in:
>>> https://patchwork.kernel.org/patch/2582771/
>> one minor nit,
>> $subject could do with space after the ':'
>> otherwise, it looks fine to me. Will suggest waiting for further
>> reviewers if they have an opinion prior to a new rev.
> Thanks NM I will queue up this change locally and await further review prior
> to sending v7.
>
>>> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
>>> arch/arm/boot/dts/omap4-panda-es.dts | 28
>>>
>>> 2 files changed, 43 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> index 03bd60d..5fd59b3 100644
>>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> @@ -16,8 +16,13 @@
>>> reg = <0x8000 0x4000>; /* 1 GB */
>>> };
>>>
>>> - leds {
>>> + leds: leds {
>>> compatible = "gpio-leds";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <
>>> + _wkgpio_pins
>>> + >;
>>> +
>>> heartbeat {
>>> label = "pandaboard::status1";
>>> gpios = < 7 0>;
>>> @@ -137,6 +142,15 @@
>>> };
>>> };
>>>
>>> +_pmx_wkup {
>>> + led_wkgpio_pins: pinmux_leds_wkpins {
>>> + pinctrl-single,pins = <
>>> + 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
>>> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>>> + >;
>>> + };
>>> +};
>>> +
>>> {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_pins>;
>>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>>> b/arch/arm/boot/dts/omap4-panda-es.dts
>>> index f1d8c21..c968a3b 100644
>>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>>> @@ -34,3 +34,31 @@
>>> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>>> >;
>>> };
>>> +
>>> +_pmx_core {
>>> + led_gpio_pins: gpio_led_pmx {
>>> + pinctrl-single,pins = <
>>> + 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
>>> + >;
>>> + };
>>> +};
>>> +
>>> +_wkgpio_pins {
>>> + pinctrl-single,pins = <
>>> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>>> + >;
>>> +};
>>> +
>>> + {
>>> + pinctrl-0 = <
>>> + _gpio_pins
>>> + _wkgpio_pins
>>> + >;
>>> +
>>> + heartbeat {
>>> + gpios = < 14 0>;
>>> + };
>>> + mmc {
>>> + gpios = < 8 0>;
>>> + };
>>> +};
>
Any additional comments besides the headline?
If not I will post v7
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add co-maintainer for fbdev
On Friday 24 May 2013, Olof Johansson wrote: > [+akpm] [+florian] > On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD > wrote: > > Hi Florian, > > > > As you seems very busy I'd like to propose the help you to handle > > the > > fbdev subsystem to easier the rich of the fbdev patch to Linus > > > > As I'm working on fbdev on at91 and others and already Co-Maintain > > the > > at91 mach on ARM > > > > And if you are not willing to continue I could take over > > Andrew has been fallback fbdev maintainer for a while, we have the > option of formalizing that as well. Adding him on cc so he sees this. It seems that Florian himself was missing on Cc too, probably by accident. I would certainly welcome Jean-Christophe to step in for fbdev, since I frequently have trivial patches for the subsystem, either from myself or one of the subarch maintainers, and it would be helpful to get feedback on them in order to merge them through arm-soc when they depend on other patches we carry, or to have them picked up into a git tree. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: EnhanceIO(TM) caching driver features [1/3]
On Fri, May 24 2013, OS Engineering wrote: > Hi Jens and Kernel Gurus, [snip] Thanks for writing all of this up, but I'm afraid it misses the point somewhat. As stated previously, we have (now) two existing competing implementations in the kernel. I'm looking for justification on why YOUR solution is better. A writeup and documentation on error handling details is nice and all, but it doesn't answer the key important questions. Lets say somebody sends in a patch that he/she claims improves memory management performance. To justify such a patch (or any patch, really), the maintenance burden vs performance benefit needs to be quantified. Such a person had better supply a set of before and after numbers, such that the benefit can be quantified. It's really the same with your solution. You mention "the solution has been proven in independent testing, such as testing by Demartek.". I have no idea what this testing is, what they ran, compared with, etc. So, to put it bluntly, I need to see some numbers. Run relevant workloads on EnhanceIO, bcache, dm-cache. Show why EnhanceIO is better. Then we can decide whether it really is the superior solution. Or, perhaps, it turns out there are inefficiencies in eg bcache/dm-cache that could be fixed up. Usually I'm not such a stickler for including new code. But a new driver is different than EnhanceIO. If somebody submitted a patch to add a newly written driver for hw that we already have a driver for, that would be similar situation. The executive summary: your writeup was good, but we need some relevant numbers to look at too. -- 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 2/3] ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60
MSM_TLMM_BASE is currently not mapped by 8x60. Remove it. Signed-off-by: Rohit Vaswani --- arch/arm/mach-msm/include/mach/msm_iomap-8x60.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h index 199372e..cf24b5c 100644 --- a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h +++ b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h @@ -41,10 +41,6 @@ #define MSM8X60_QGIC_CPU_PHYS 0x02081000 #define MSM8X60_QGIC_CPU_SIZE SZ_4K -#define MSM_TLMM_BASE IOMEM(0xF0004000) -#define MSM_TLMM_PHYS 0x0080 -#define MSM_TLMM_SIZE SZ_16K - #define MSM8X60_TMR_PHYS 0x0200 #define MSM8X60_TMR_SIZE SZ_4K -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 3/3] gpio: msm: Add device tree and irqdomain support for gpio-msm-v2
This cleans up the gpio-msm-v2 driver of all the global define usage.
The number of gpios are now defined in the device tree. This enables
adding irqdomain support as well.
Signed-off-by: Rohit Vaswani
---
.../devicetree/bindings/gpio/gpio-msm.txt | 26 +++
arch/arm/boot/dts/msm8660-surf.dts | 11 ++
arch/arm/boot/dts/msm8960-cdp.dts | 11 ++
drivers/gpio/Kconfig |2 +-
drivers/gpio/gpio-msm-v2.c | 165
5 files changed, 152 insertions(+), 63 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-msm.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-msm.txt
b/Documentation/devicetree/bindings/gpio/gpio-msm.txt
new file mode 100644
index 000..ac20e68
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-msm.txt
@@ -0,0 +1,26 @@
+MSM GPIO controller bindings
+
+Required properties:
+- compatible:
+ - "qcom,msm-gpio" for MSM controllers
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be 2.
+- interrupt-controller: Mark the device node as an interrupt controller
+- interrupts : Specify the TLMM summary interrupt number
+- ngpio : Specify the number of MSM GPIOs
+
+Example:
+
+ msmgpio: gpio@fd51 {
+ compatible = "qcom,msm-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0xfd51 0x4000>;
+ interrupts = <0 208 0>;
+ ngpio = <150>;
+ };
diff --git a/arch/arm/boot/dts/msm8660-surf.dts
b/arch/arm/boot/dts/msm8660-surf.dts
index 9bf49b3..8931906 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/msm8660-surf.dts
@@ -26,6 +26,17 @@
cpu-offset = <0x4>;
};
+ msmgpio: gpio@80 {
+ compatible = "qcom,msm-gpio";
+ reg = <0x0080 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpio = <173>;
+ interrupts = <0 32 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
serial@19c40 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x19c4 0x1000>,
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
b/arch/arm/boot/dts/msm8960-cdp.dts
index 2e4d87a..52fe253 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -26,6 +26,17 @@
cpu-offset = <0x8>;
};
+ msmgpio: gpio@fd51 {
+ compatible = "qcom,msm-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpio = <150>;
+ interrupts = <0 32 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0xfd51 0x4000>;
+ };
+
serial@19c40 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x1644 0x1000>,
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 87d5670..9ef3b04 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -165,7 +165,7 @@ config GPIO_MSM_V1
config GPIO_MSM_V2
tristate "Qualcomm MSM GPIO v2"
- depends on GPIOLIB && ARCH_MSM
+ depends on GPIOLIB && OF
help
Say yes here to support the GPIO interface on ARM v7 based
Qualcomm MSM chips. Most of the pins on the MSM can be
diff --git a/drivers/gpio/gpio-msm-v2.c b/drivers/gpio/gpio-msm-v2.c
index 75cc821..2081f23 100644
--- a/drivers/gpio/gpio-msm-v2.c
+++ b/drivers/gpio/gpio-msm-v2.c
@@ -19,17 +19,22 @@
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
+#include
-#include
+static int summary_irq;
+void __iomem *msm_tlmm_base;
/* Bits of interest in the GPIO_IN_OUT register.
*/
@@ -77,11 +82,11 @@ enum {
};
-#define GPIO_INTR_CFG_SU(gpio)(MSM_TLMM_BASE + 0x0400 + (0x04 * (gpio)))
-#define GPIO_CONFIG(gpio) (MSM_TLMM_BASE + 0x1000 + (0x10 * (gpio)))
-#define GPIO_IN_OUT(gpio) (MSM_TLMM_BASE + 0x1004 + (0x10 * (gpio)))
-#define GPIO_INTR_CFG(gpio) (MSM_TLMM_BASE + 0x1008 + (0x10 * (gpio)))
-#define GPIO_INTR_STATUS(gpio)(MSM_TLMM_BASE + 0x100c + (0x10 * (gpio)))
+#define GPIO_INTR_CFG_SU(gpio)(msm_tlmm_base + 0x0400 + (0x04 * (gpio)))
+#define GPIO_CONFIG(gpio) (msm_tlmm_base + 0x1000 + (0x10 * (gpio)))
+#define GPIO_IN_OUT(gpio) (msm_tlmm_base + 0x1004 + (0x10 * (gpio)))
+#define GPIO_INTR_CFG(gpio) (msm_tlmm_base + 0x1008 + (0x10 * (gpio)))
+#define
[PATCH 1/3] ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs
Remove gpiomux-v2 as it's not being used and make way for future improvements.
Signed-off-by: Rohit Vaswani
---
arch/arm/mach-msm/Kconfig| 13 +++-
arch/arm/mach-msm/Makefile |6 +--
arch/arm/mach-msm/gpiomux-8x60.c | 19
arch/arm/mach-msm/gpiomux-v2.c | 25 ---
arch/arm/mach-msm/gpiomux-v2.h | 61 --
arch/arm/mach-msm/gpiomux.c | 15 +
arch/arm/mach-msm/gpiomux.h |5 ---
drivers/gpio/gpio-msm-v2.c |5 +--
8 files changed, 24 insertions(+), 125 deletions(-)
delete mode 100644 arch/arm/mach-msm/gpiomux-8x60.c
delete mode 100644 arch/arm/mach-msm/gpiomux-v2.c
delete mode 100644 arch/arm/mach-msm/gpiomux-v2.h
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index fceb093..614e41e 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -48,9 +48,7 @@ config ARCH_MSM8X60
select CPU_V7
select GPIO_MSM_V2
select HAVE_SMP
- select MSM_GPIOMUX
select MSM_SCM if SMP
- select MSM_V2_TLMM
select USE_OF
config ARCH_MSM8960
@@ -58,9 +56,8 @@ config ARCH_MSM8960
select ARM_GIC
select CPU_V7
select HAVE_SMP
- select MSM_GPIOMUX
+ select GPIO_MSM_V2
select MSM_SCM if SMP
- select MSM_V2_TLMM
select USE_OF
config MSM_HAS_DEBUG_UART_HS
@@ -124,10 +121,10 @@ config MSM_SMD
bool
config MSM_GPIOMUX
- bool
-
-config MSM_V2_TLMM
- bool
+ depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
+ bool "MSM V1 TLMM GPIOMUX architecture"
+ help
+ Support for MSM V1 TLMM GPIOMUX architecture.
config MSM_SCM
bool
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 17519fa..1a26d04 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -27,7 +27,5 @@ obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o
devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-dt-8660.o
obj-$(CONFIG_ARCH_MSM8960) += board-dt-8960.o
-
-obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-v1.o gpiomux.o
-obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
-obj-$(CONFIG_ARCH_MSM8X60) += gpiomux-8x60.o gpiomux-v2.o gpiomux.o
+obj-$(CONFIG_MSM_GPIOMUX) += gpiomux.o
+obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o
diff --git a/arch/arm/mach-msm/gpiomux-8x60.c b/arch/arm/mach-msm/gpiomux-8x60.c
deleted file mode 100644
index 7b380b3..000
--- a/arch/arm/mach-msm/gpiomux-8x60.c
+++ /dev/null
@@ -1,19 +0,0 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-#include "gpiomux.h"
-
-struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {};
diff --git a/arch/arm/mach-msm/gpiomux-v2.c b/arch/arm/mach-msm/gpiomux-v2.c
deleted file mode 100644
index 273396d..000
--- a/arch/arm/mach-msm/gpiomux-v2.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-#include
-#include
-#include "gpiomux.h"
-
-void __msm_gpiomux_write(unsigned gpio, gpiomux_config_t val)
-{
- writel(val & ~GPIOMUX_CTL_MASK,
- MSM_TLMM_BASE + 0x1000 + (0x10 * gpio));
-}
diff --git a/arch/arm/mach-msm/gpiomux-v2.h b/arch/arm/mach-msm/gpiomux-v2.h
deleted file mode 100644
index 3bf10e7..000
--- a/arch/arm/mach-msm/gpiomux-v2.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the
[PATCHv3 0/3] Cleanup MSM_GPIOMUX and add DT support for gpio-msm
Hi Linus, Could this series go through David's tree or is there a better way to do this? It would be great if I can have you ack for the gpio patch. Thanks, Rohit Rohit Vaswani (3): ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60 gpio: msm: Add device tree and irqdomain support for gpio-msm-v2 .../devicetree/bindings/gpio/gpio-msm.txt | 26 +++ arch/arm/boot/dts/msm8660-surf.dts | 11 ++ arch/arm/boot/dts/msm8960-cdp.dts | 11 ++ arch/arm/mach-msm/Kconfig | 13 +- arch/arm/mach-msm/Makefile |6 +- arch/arm/mach-msm/gpiomux-8x60.c | 19 --- arch/arm/mach-msm/gpiomux-v2.c | 25 --- arch/arm/mach-msm/gpiomux-v2.h | 61 --- arch/arm/mach-msm/gpiomux.c| 15 ++ arch/arm/mach-msm/gpiomux.h|5 - arch/arm/mach-msm/include/mach/msm_iomap-8x60.h|4 - drivers/gpio/Kconfig |2 +- drivers/gpio/gpio-msm-v2.c | 170 13 files changed, 176 insertions(+), 192 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-msm.txt delete mode 100644 arch/arm/mach-msm/gpiomux-8x60.c delete mode 100644 arch/arm/mach-msm/gpiomux-v2.c delete mode 100644 arch/arm/mach-msm/gpiomux-v2.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/3] Cleanup MSM_GPIOMUX and add DT support for gpio-msm
Hi Linus, Could this series go through David's tree or is there a better way to do this? It would be great if I can have you ack for the gpio patch. Thanks, Rohit Rohit Vaswani (3): ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60 gpio: msm: Add device tree and irqdomain support for gpio-msm-v2 .../devicetree/bindings/gpio/gpio-msm.txt | 26 +++ arch/arm/boot/dts/msm8660-surf.dts | 11 ++ arch/arm/boot/dts/msm8960-cdp.dts | 11 ++ arch/arm/mach-msm/Kconfig | 13 +- arch/arm/mach-msm/Makefile |6 +- arch/arm/mach-msm/gpiomux-8x60.c | 19 --- arch/arm/mach-msm/gpiomux-v2.c | 25 --- arch/arm/mach-msm/gpiomux-v2.h | 61 --- arch/arm/mach-msm/gpiomux.c| 15 ++ arch/arm/mach-msm/gpiomux.h|5 - arch/arm/mach-msm/include/mach/msm_iomap-8x60.h|4 - drivers/gpio/Kconfig |2 +- drivers/gpio/gpio-msm-v2.c | 170 13 files changed, 176 insertions(+), 192 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-msm.txt delete mode 100644 arch/arm/mach-msm/gpiomux-8x60.c delete mode 100644 arch/arm/mach-msm/gpiomux-v2.c delete mode 100644 arch/arm/mach-msm/gpiomux-v2.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.4.47
diff --git a/Makefile b/Makefile
index 3d88eb8..a85d4eb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 46
+SUBLEVEL = 47
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index e458acb..6a8776e 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2443,8 +2443,8 @@ int evergreen_mc_init(struct radeon_device *rdev)
rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
} else {
/* size in MB on evergreen/cayman/tn */
- rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
- rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+ rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL *
1024ULL;
+ rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL *
1024ULL;
}
rdev->mc.visible_vram_size = rdev->mc.aper_size;
r700_vram_gtt_location(rdev, >mc);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f493c64..49b55ed 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -744,7 +744,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
return r;
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
-(unsigned)rdev->mc.real_vram_size / (1024 * 1024));
+(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
r = ttm_bo_init_mm(>mman.bdev, TTM_PL_TT,
rdev->mc.gtt_size >> PAGE_SHIFT);
if (r) {
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 5508ad7..2dbd585 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2464,8 +2464,8 @@ static int si_mc_init(struct radeon_device *rdev)
rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
/* size in MB on si */
- rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
- rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+ rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
rdev->mc.visible_vram_size = rdev->mc.aper_size;
si_vram_gtt_location(rdev, >mc);
radeon_update_bandwidth_info(rdev);
diff --git a/drivers/hwmon/abituguru.c b/drivers/hwmon/abituguru.c
index a72bf25..56b178a 100644
--- a/drivers/hwmon/abituguru.c
+++ b/drivers/hwmon/abituguru.c
@@ -1410,14 +1410,18 @@ static int __devinit abituguru_probe(struct
platform_device *pdev)
pr_info("found Abit uGuru\n");
/* Register sysfs hooks */
- for (i = 0; i < sysfs_attr_i; i++)
- if (device_create_file(>dev,
- >sysfs_attr[i].dev_attr))
+ for (i = 0; i < sysfs_attr_i; i++) {
+ res = device_create_file(>dev,
+>sysfs_attr[i].dev_attr);
+ if (res)
goto abituguru_probe_error;
- for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++)
- if (device_create_file(>dev,
- _sysfs_attr[i].dev_attr))
+ }
+ for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++) {
+ res = device_create_file(>dev,
+_sysfs_attr[i].dev_attr);
+ if (res)
goto abituguru_probe_error;
+ }
data->hwmon_dev = hwmon_device_register(>dev);
if (!IS_ERR(data->hwmon_dev))
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 6193349..3c2812f 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -349,7 +349,8 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
/* Enable the adapter */
dw_writel(dev, 1, DW_IC_ENABLE);
- /* Enable interrupts */
+ /* Clear and enable interrupts */
+ i2c_dw_clear_int(dev);
dw_writel(dev, DW_IC_INTR_DEFAULT_MASK, DW_IC_INTR_MASK);
}
diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
b/drivers/media/dvb/mantis/mantis_dvb.c
index e5180e4..5d15c6b 100644
--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -248,8 +248,10 @@ int __devinit mantis_dvb_init(struct mantis_pci *mantis)
err5:
tasklet_kill(>tasklet);
dvb_net_release(>dvbnet);
- dvb_unregister_frontend(mantis->fe);
- dvb_frontend_detach(mantis->fe);
+ if (mantis->fe) {
+ dvb_unregister_frontend(mantis->fe);
+ dvb_frontend_detach(mantis->fe);
+ }
err4:
mantis->demux.dmx.remove_frontend(>demux.dmx, >fe_mem);
diff
Linux 3.4.47
I'm announcing the release of the 3.4.47 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- drivers/gpu/drm/radeon/evergreen.c |4 ++-- drivers/gpu/drm/radeon/radeon_ttm.c |2 +- drivers/gpu/drm/radeon/si.c |4 ++-- drivers/hwmon/abituguru.c| 16 ++-- drivers/i2c/busses/i2c-designware-core.c |3 ++- drivers/media/dvb/mantis/mantis_dvb.c|6 -- fs/btrfs/ioctl.c | 10 +- 8 files changed, 27 insertions(+), 20 deletions(-) Alan Cox (1): media: mantis: fix silly crash case Gabriel de Perthuis (1): btrfs: don't stop searching after encountering the wrong item Greg Kroah-Hartman (1): Linux 3.4.47 Mika Westerberg (1): i2c: designware: always clear interrupts before enabling them Niels Ole Salscheider (1): drm/radeon: Fix VRAM size calculation for VRAM >= 4GB Wei Yongjun (1): hwmon: fix error return code in abituguru_probe() signature.asc Description: Digital signature
Re: Linux 3.0.80
diff --git a/Makefile b/Makefile
index f8ade05..dad194f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 79
+SUBLEVEL = 80
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/drivers/hwmon/abituguru.c b/drivers/hwmon/abituguru.c
index 65a35cf..61ab615 100644
--- a/drivers/hwmon/abituguru.c
+++ b/drivers/hwmon/abituguru.c
@@ -1280,14 +1280,18 @@ static int __devinit abituguru_probe(struct
platform_device *pdev)
pr_info("found Abit uGuru\n");
/* Register sysfs hooks */
- for (i = 0; i < sysfs_attr_i; i++)
- if (device_create_file(>dev,
- >sysfs_attr[i].dev_attr))
+ for (i = 0; i < sysfs_attr_i; i++) {
+ res = device_create_file(>dev,
+>sysfs_attr[i].dev_attr);
+ if (res)
goto abituguru_probe_error;
- for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++)
- if (device_create_file(>dev,
- _sysfs_attr[i].dev_attr))
+ }
+ for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++) {
+ res = device_create_file(>dev,
+_sysfs_attr[i].dev_attr);
+ if (res)
goto abituguru_probe_error;
+ }
data->hwmon_dev = hwmon_device_register(>dev);
if (!IS_ERR(data->hwmon_dev))
diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
b/drivers/media/dvb/mantis/mantis_dvb.c
index e5180e4..5d15c6b 100644
--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -248,8 +248,10 @@ int __devinit mantis_dvb_init(struct mantis_pci *mantis)
err5:
tasklet_kill(>tasklet);
dvb_net_release(>dvbnet);
- dvb_unregister_frontend(mantis->fe);
- dvb_frontend_detach(mantis->fe);
+ if (mantis->fe) {
+ dvb_unregister_frontend(mantis->fe);
+ dvb_frontend_detach(mantis->fe);
+ }
err4:
mantis->demux.dmx.remove_frontend(>demux.dmx, >fe_mem);
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a3c4751..a205027 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1539,7 +1539,11 @@ static noinline int copy_to_sk(struct btrfs_root *root,
item_off = btrfs_item_ptr_offset(leaf, i);
item_len = btrfs_item_size_nr(leaf, i);
- if (item_len > BTRFS_SEARCH_ARGS_BUFSIZE)
+ btrfs_item_key_to_cpu(leaf, key, i);
+ if (!key_in_sk(key, sk))
+ continue;
+
+ if (sizeof(sh) + item_len > BTRFS_SEARCH_ARGS_BUFSIZE)
item_len = 0;
if (sizeof(sh) + item_len + *sk_offset >
@@ -1548,10 +1552,6 @@ static noinline int copy_to_sk(struct btrfs_root *root,
goto overflow;
}
- btrfs_item_key_to_cpu(leaf, key, i);
- if (!key_in_sk(key, sk))
- continue;
-
sh.objectid = key->objectid;
sh.offset = key->offset;
sh.type = key->type;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.0.80
I'm announcing the release of the 3.0.80 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- drivers/hwmon/abituguru.c | 16 ++-- drivers/media/dvb/mantis/mantis_dvb.c |6 -- fs/btrfs/ioctl.c | 10 +- 4 files changed, 20 insertions(+), 14 deletions(-) Alan Cox (1): media: mantis: fix silly crash case Gabriel de Perthuis (1): btrfs: don't stop searching after encountering the wrong item Greg Kroah-Hartman (1): Linux 3.0.80 Wei Yongjun (1): hwmon: fix error return code in abituguru_probe() signature.asc Description: Digital signature
