Re: Stupid user with user-space questions, matrix LED driving with user space code only.
On Sat, 2013-02-16 at 14:37 +, Jonathan Andrews wrote:
> I hope this is the correct place, I expect to get abused.
>
> I'm trying to do a mostly soft real-time task with a very small hard
> real time element.
>
> I've written some code to drive matrix LED signs using a Raspberry Pi.
>
> Source here:
> http://www.jonshouse.co.uk/download/128x32_red_green_led_sign.tar.gz
>
>
> Since I last used linux you kernel people have fiddled with it yet
> again:
>
> Linux raspberrypi 3.6.11+ #375 PREEMPT Tue Feb 12 01:41:07 GMT 2013 armv6l
> GNU/Linux
>
> I'm scanning an LED display to produce a 2 bits per pixel image. The
> code simply alters the amount of time any one LED is on, for higher
> intensity pixels the true amount of "on" time is non critical.
>
> I've marked my process as realtime.
>
> My problem is that for very dim pixels the amount of "on" time for the
> LED is very critical, this is only a fraction of a percent of the total
> processes timeslice.
> It scans 100 frames of brightest, 100 frames of brighter and 1 frame of
> dim pixels for example, so 200:1 ratio of don't care much /vs care a lot
> timing !
>
> To this end I'm using a hard coded small delay instead of usleep for the
> tight timing section:
>
> // Delay for ARM without yeilding to schedular, roughly calibrated but better
> than usleep for short delays
> inline usleep_arm_hard(int usecs)
> {
> long int outer,inner;
>
> for (outer=0;outer {
> for (inner=0;inner<300;inner++)
> asm("andeq r0, r0, r0"); // NOP
> }
> }
>
> The dim pixel code is timing critical (but as I said only a tiny
> fraction of the total CPU usage). What I need to do is grab the CPU and
> prevent any context switch (IRQ or PREEMPT) for this period.
why you want to do this?
>
> I cant find a user space mechanism other than changing the kernel to
> disable preemtion ? No simple /proc switch to turn it on/off ? If not
> why - I cant be the only one who wants to toggle preemption off without
> swapping kernels ?
you can't disable pre-emption from user space.
>
> The other issue is that of IRQs, my dim pixels on the display seem to
> flash brighter from time to time, this I assume is partly preemption
> (maybe possibly) and partly IRQ handling (more likely) allowing context
> switches or just taking a while on slow hardware.
>
> I need only a tiny fraction of the runtime to be hard real time, on
> intel in the past i've simply disabled IRQs briefly with some inline
> assembler.
you shouldn't fiddle with irq's from user space but...
> The Raspberry Pi board would also probably survive this as the only
> active peripheral is ethenet, I suspect couple of missed IRQs would not
> matter as once IRQs are re-enabled the USB/ethernet hardware will likely
> have the data or it can be re-tried. Does anyone have an example of a
> dirty hack along these lines they can share with me :-)
> Do I have any simple mechanism available to disable (or defer) kernel
> IRQ handling briefly from user space code, I suspect not but no harm in
> asking ?
Use any sysfs to disable/enable the irq. This approach is very bad but
as you said you wanted a hack.
> Thanks,
> Jon
>
> PS I'm not a kernel hacker - yes I know I could write a proper driver
> for the task but I lack any real skill and the required time !
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of: use platform_device_add
On Sun, Feb 17, 2013 at 11:03:35AM +0800, Shawn Guo wrote: > On Fri, Jan 18, 2013 at 01:40:00AM +, Grant Likely wrote: > > This allows platform_device_add a chance to call insert_resource on all > > of the resources from OF. At a minimum this fills in proc/iomem and > > presumably makes resource tracking and conflict detection work better. > > However, it has the side effect of moving all OF generated platform > > devices from /sys/devices to /sys/devices/platform/. It /shouldn't/ > > break userspace because userspace is not supposed to depend on the full > > path (because userspace always does what it is supposed to, right?). > > > > This may cause breakage if either: > > 1) any two nodes in a given device tree have overlapping & staggered > >regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained > >within the other). In this case one of the devices will fail to > >register and an exception will be needed in platform_device_add() to > >complain but not fail. > > Grant, > > The patch introduce a regression on imx6q boot. It also breaks all of_amba_device users. of_amba_device_create() --> amba_device_add() --> request_resource() and fails. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] xen/acpi: xen cpu hotplug minor updates
>From 195df2bf6174959baa025ccb249041bb53d6060a Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Sun, 17 Feb 2013 11:47:24 +0800
Subject: [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates
Recently at native Rafael did some cleanup for acpi, say, drop
acpi_bus_add, remove unnecessary argument of acpi_bus_scan,
and run acpi_bus_scan under acpi_scan_lock.
This patch does similar cleanup for xen cpu hotplug, removing
redundant logic, and adding lock.
Signed-off-by: Liu Jinsong
---
drivers/xen/xen-acpi-cpuhotplug.c | 34 --
1 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/xen/xen-acpi-cpuhotplug.c
b/drivers/xen/xen-acpi-cpuhotplug.c
index 7578279..18c742b 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -239,24 +239,6 @@ static acpi_status xen_acpi_cpu_hotadd(struct
acpi_processor *pr)
return AE_OK;
}
-static
-int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device)
-{
- acpi_handle phandle;
- struct acpi_device *pdev;
-
- if (acpi_get_parent(handle, &phandle))
- return -ENODEV;
-
- if (acpi_bus_get_device(phandle, &pdev))
- return -ENODEV;
-
- if (acpi_bus_scan(handle))
- return -ENODEV;
-
- return 0;
-}
-
static int acpi_processor_device_remove(struct acpi_device *device)
{
pr_debug(PREFIX "Xen does not support CPU hotremove\n");
@@ -272,6 +254,8 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
int result;
+ acpi_scan_lock_acquire();
+
switch (event) {
case ACPI_NOTIFY_BUS_CHECK:
case ACPI_NOTIFY_DEVICE_CHECK:
@@ -286,12 +270,16 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
if (!acpi_bus_get_device(handle, &device))
break;
- result = acpi_processor_device_add(handle, &device);
+ result = acpi_bus_scan(handle);
if (result) {
pr_err(PREFIX "Unable to add the device\n");
break;
}
-
+ result = acpi_bus_get_device(handle, &device);
+ if (result) {
+ pr_err(PREFIX "Missing device object\n");
+ break;
+ }
ost_code = ACPI_OST_SC_SUCCESS;
break;
@@ -321,11 +309,13 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
"Unsupported event [0x%x]\n", event));
/* non-hotplug event; possibly handled by other handler */
- return;
+ goto out;
}
(void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
- return;
+
+out:
+ acpi_scan_lock_release();
}
static acpi_status is_processor_device(acpi_handle handle)
--
1.7.1
0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch
Description: 0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch
Re: [PATCH] mm: introduce __linear_page_index()
于 2013年02月06日 05:27, Andrew Morton 写道:
On Tue, 5 Feb 2013 15:03:39 +0800
Huang Shijie wrote:
+static inline pgoff_t __linear_page_index(struct vm_area_struct *vma,
unsigned long address)
{
pgoff_t pgoff;
+
+ pgoff = (address - vma->vm_start)>> PAGE_SHIFT;
+ return pgoff + vma->vm_pgoff;
+}
+
+static inline pgoff_t linear_page_index(struct vm_area_struct *vma,
+ unsigned long address)
+{
if (unlikely(is_vm_hugetlb_page(vma)))
return linear_hugepage_index(vma, address);
- pgoff = (address - vma->vm_start)>> PAGE_SHIFT;
- pgoff += vma->vm_pgoff;
- return pgoff>> (PAGE_CACHE_SHIFT - PAGE_SHIFT);
+ return __linear_page_index(vma, address)>>
+ (PAGE_CACHE_SHIFT - PAGE_SHIFT);
}
I don't think we need bother creating both linear_page_index() and
__linear_page_index(). Realistically, we won't be supporting
Just as Hocko said, the unmap_ref_private() (in hugetlb.c) may also uses
the __linear_page_index().
So it's better to the two helpers : linear_page_index() and
__linear_page_index().
do you agree?
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] xen/acpi: xen memory hotplug minor updates
>From aa363f1a4f862fab2f50dfe3ad602bb8dd234709 Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Sat, 16 Feb 2013 16:59:03 +0800
Subject: [PATCH 1/2] xen/acpi: xen memory hotplug minor updates
Dan Carpenter found current xen memory hotplug logic
has potential issue: at func acpi_memory_get_device()
*mem_device = acpi_driver_data(device);
while the device may be NULL and then dereference.
At native side, Rafael recently updated acpi_memory_get_device(),
dropping acpi_bus_add, adding lock, and avoiding above issue.
This patch updates xen memory hotplug logic accordingly, removing
redundant logic, adding lock, and avoiding dereference.
Signed-off-by: Liu Jinsong
---
drivers/xen/xen-acpi-memhotplug.c | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/xen/xen-acpi-memhotplug.c
b/drivers/xen/xen-acpi-memhotplug.c
index 853b12d..faef5b3 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -158,31 +158,17 @@ acpi_memory_get_device_resources(struct
acpi_memory_device *mem_device)
return 0;
}
-static int
-acpi_memory_get_device(acpi_handle handle,
- struct acpi_memory_device **mem_device)
+static int acpi_memory_get_device(acpi_handle handle,
+ struct acpi_memory_device **mem_device)
{
- acpi_status status;
- acpi_handle phandle;
struct acpi_device *device = NULL;
- struct acpi_device *pdevice = NULL;
- int result;
+ int result = 0;
- if (!acpi_bus_get_device(handle, &device) && device)
- goto end;
+ acpi_scan_lock_acquire();
- status = acpi_get_parent(handle, &phandle);
- if (ACPI_FAILURE(status)) {
- pr_warn(PREFIX "Cannot find acpi parent\n");
- return -EINVAL;
- }
-
- /* Get the parent device */
- result = acpi_bus_get_device(phandle, &pdevice);
- if (result) {
- pr_warn(PREFIX "Cannot get acpi bus device\n");
- return -EINVAL;
- }
+ acpi_bus_get_device(handle, &device);
+ if (device)
+ goto end;
/*
* Now add the notified device. This creates the acpi_device
@@ -190,18 +176,28 @@ acpi_memory_get_device(acpi_handle handle,
*/
result = acpi_bus_scan(handle);
if (result) {
- pr_warn(PREFIX "Cannot add acpi bus\n");
- return -EINVAL;
+ pr_warn(PREFIX "ACPI namespace scan failed\n");
+ result = -EINVAL;
+ goto out;
+ }
+ result = acpi_bus_get_device(handle, &device);
+ if (result) {
+ pr_warn(PREFIX "Missing device object\n");
+ result = -EINVAL;
+ goto out;
}
end:
*mem_device = acpi_driver_data(device);
if (!(*mem_device)) {
- pr_err(PREFIX "Driver data not found\n");
- return -ENODEV;
+ pr_err(PREFIX "driver data not found\n");
+ result = -ENODEV;
+ goto out;
}
- return 0;
+out:
+ acpi_scan_lock_release();
+ return result;
}
static int acpi_memory_check_device(struct acpi_memory_device *mem_device)
@@ -259,12 +255,15 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"\nReceived EJECT REQUEST notification for device\n"));
+ acpi_scan_lock_acquire();
if (acpi_bus_get_device(handle, &device)) {
+ acpi_scan_lock_release();
pr_err(PREFIX "Device doesn't exist\n");
break;
}
mem_device = acpi_driver_data(device);
if (!mem_device) {
+ acpi_scan_lock_release();
pr_err(PREFIX "Driver Data is NULL\n");
break;
}
@@ -274,6 +273,7 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
* acpi_bus_remove if Xen support hotremove in the future
*/
acpi_memory_disable_device(mem_device);
+ acpi_scan_lock_release();
break;
default:
--
1.7.1
0001-xen-acpi-xen-memory-hotplug-minor-updates.patch
Description: 0001-xen-acpi-xen-memory-hotplug-minor-updates.patch
RE: linux-next: build failure after merge of the xen-two tree
Rafael J. Wysocki wrote: > On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote: >> Hi Rafael, > > Hi, > >> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" >> wrote: >>> >>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote: On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk wrote: > > Thank you. I keep on forgetting - but would it be OK for me to > take this patch in my tree? Or should I not since this is a new > functionality that Rafael is going to introduce in v3.9? It is an API change in the pm tree that is not yet in Linus' tree. > And if so, perhaps I should tack it on in my tree, once Rafael > does a git pull to Linus? Or just point Linus to this git commit? You should point Linus at this patch if the pm tree is merged first, or Rafael should do the same if the reverse happens. >>> >>> Alternatively, Konrad can pull the acpi-scan branch containing the >>> changes in question from my tree into his tree and rebase the new >>> material on top of that. >> >> Or pull the acpi-scan branch into his tree and use my conflict >> resolution in the resulting merge thus requiring no rebasing. >> However, Linus likes to see such interactions, so it can be left up >> to when the latter of the two tress is merged by Linus. > > Well, I'm afraid this won't be sufficient this time, because of this > commit in my tree (which is not on the acpi-scan branch): > > commit 3757b94802fb65d8f696597a74053cf21738da0b > Author: Rafael J. Wysocki > Date: Wed Feb 13 14:36:47 2013 +0100 > > ACPI / hotplug: Fix concurrency issues and memory leaks > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under > acpi_scan_lock (new in my tree as well). Yes, we noticed that and only need minor updates at xen side, will send out 2 xen patches later accordingly, for cleanup and adding lock. Thanks, Jinsong > > Moreover, I think that the introduction of ACPI-based CPU hotplug > into Xen and this point would be premature, because we need to rework > the original ACPI-based CPU hotplug and quite frankly it shouldn't > call acpi_bus_scan() directly at all. > > Konrad? > > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: manual merge of the acpi tree with the pm tree
> Hi Len, > > On Mon, 11 Feb 2013 18:34:06 -0500 Len Brown wrote: > > > > BTW. Rafael's "pm" tree now carries the ACPI patch stream, so it is > > probably a mis-representation to call my tree the "acpi" tree. > > My tree is primarily focused on the "idle" part of pm these days. > > OK, I have renamed your tree to "idle". Thanks for fixing the conflicts. The new ACPICA release contains a patch renaming the PM_TIMER_FREQUENCY macro. A further CA release patch cleans up the repo (pm/linux-next) where the release patch set based on. The conflicts would happen if other repos contained new codes using the old macro definition. Thanks -Lv -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: The removal of idle_balance()
On Sun, 2013-02-17 at 07:26 +0100, Mike Galbraith wrote: > On Sat, 2013-02-16 at 11:12 -0500, Steven Rostedt wrote: > > On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote: > > > On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote: > > > > > > > Think about it some more, just because we go idle isn't enough reason to > > > > pull a runable task over. CPUs go idle all the time, and tasks are woken > > > > up all the time. There's no reason that we can't just wait for the sched > > > > tick to decide its time to do a bit of balancing. Sure, it would be nice > > > > if the idle CPU did the work. But I think that frame of mind was an > > > > incorrect notion from back in the early 2000s and does not apply to > > > > today's hardware, or perhaps it doesn't apply to the (relatively) new > > > > CFS scheduler. If you want aggressive scheduling, make the task rt, and > > > > it will do aggressive scheduling. > > > > > > (the throttle is supposed to keep idle_balance() from doing severe > > > damage, that may want a peek/tweak) > > > > > > Hackbench spreads itself with FORK/EXEC balancing, how does say a kbuild > > > do with no idle_balance()? > > > > > > > Interesting, I added this patch and it brought down my hackbench to the > > same level as removing idle_balance(). > > The typo did it's job well :) > > Hrm, turning idle balancing off here does not help hackbench at all. (And puts a dent in x264 ultrafast) +SD_BALANCE_NEWIDLE encoded 600 frames, 425.04 fps, 22132.71 kb/s encoded 600 frames, 416.07 fps, 22132.71 kb/s encoded 600 frames, 417.49 fps, 22132.71 kb/s encoded 600 frames, 420.65 fps, 22132.71 kb/s encoded 600 frames, 425.55 fps, 22132.71 kb/s encoded 600 frames, 425.58 fps, 22132.71 kb/s encoded 600 frames, 426.18 fps, 22132.71 kb/s encoded 600 frames, 424.21 fps, 22132.71 kb/s encoded 600 frames, 422.20 fps, 22132.71 kb/s encoded 600 frames, 423.15 fps, 22132.71 kb/s -SD_BALANCE_NEWIDLE encoded 600 frames, 378.52 fps, 22132.71 kb/s encoded 600 frames, 378.75 fps, 22132.71 kb/s encoded 600 frames, 378.20 fps, 22132.71 kb/s encoded 600 frames, 372.54 fps, 22132.71 kb/s encoded 600 frames, 366.69 fps, 22132.71 kb/s encoded 600 frames, 378.46 fps, 22132.71 kb/s encoded 600 frames, 379.89 fps, 22132.71 kb/s encoded 600 frames, 382.25 fps, 22132.71 kb/s encoded 600 frames, 384.10 fps, 22132.71 kb/s encoded 600 frames, 375.24 fps, 22132.71 kb/s -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dmi_scan: Refactor dmi_scan_machine(), {smbios,dmi}_present()
On Sat, Feb 16, 2013 at 06:02:22PM +, Ben Hutchings wrote: > Move the calls to memcpy_fromio() up into the loop in > dmi_scan_machine(), and move the signature checks back down into > dmi_decode(). We need to check at 16-byte intervals but keep a > 32-byte buffer for an SMBIOS entry, so shift the buffer after each > iteration. > > Merge smbios_present() into dmi_present(), so we look for an SMBIOS > signature at the beginning of the given buffer and then for a DMI > signature at an offset of 16 bytes. > > Signed-off-by: Ben Hutchings > --- > This file mixes up __iomem and regular pointers a lot, and this patch > fixes some but not all of those instances. Presumably it is quite > safe to read a BIOS image with any mov instructions the compiler > generates, but in that case maybe we should explicitly cast away the > __iomem qualifier in dmi_ioremap()? > > Tim, you might like to test that this doesn't cause a regression > of the previous fix. I can confirm that this works just as well as the last patch you gave me. I'm sorry that it took me a while to reply. Tim McGrath pgpHSobinKZwr.pgp Description: PGP signature
[PATCH] staging: comedi: drivers: addi-data: hwdrv_apci3200.c: Add a missing semicolon
fix for missing end-of-statement by adding a semicolon
Signed-off-by: Kumar Amit Mehta
---
.../comedi/drivers/addi-data/hwdrv_apci3200.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3200.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3200.c
index 829af18..c790873 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3200.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3200.c
@@ -633,7 +633,7 @@ static int apci3200_do_insn_bits(struct comedi_device *dev,
s->state = inl(devpriv->i_IobaseAddon) & 0xf;
if (mask) {
s->state &= ~mask;
- s->state |= (bits & mask)
+ s->state |= (bits & mask);
outl(s->state, devpriv->i_IobaseAddon);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cgroup: fix cgroup_path() vs rename() race, take 2
On Sun, Feb 17, 2013 at 12:03:37PM +0800, Li Zefan wrote: > rename() will change dentry->d_name. The result of this race can > be worse than seeing partially rewritten name, but we might access > a stale pointer because rename() will re-allocate memory to hold > a longer name. > > As accessing dentry->name must be protected by dentry->d_lock or > parent inode's i_mutex, while on the other hand cgroup-path() can > be called with some irq-safe spinlocks held, we can't generate > cgroup path using dentry->d_name. > > Alternatively we make a copy of dentry->d_lock and save it in > cgrp->name when a cgroup is created, and update cgrp->name at > rename(). Yecchhh... This is just plain wrong. If nothing else, your locking is way too heavy for your uses. Just put freeing those separately allocated names in RCU callback and assign them on rename with rcu_assign_pointer(). Then put cgroup_path() under rcu_read_lock() (most of the callers already are) and be done with that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] fs: encode_fh: return FILEID_INVALID if invalid fid_type
From: Namjae Jeon
This patch is a follow up on below patch:
[PATCH] exportfs: add FILEID_INVALID to indicate invalid fid_type
commit: 216b6cbdcbd86b1db0754d58886b466ae31f5a63
Signed-off-by: Namjae Jeon
Signed-off-by: Vivek Trivedi
Acked-by: Steven Whitehouse
Acked-by: Sage Weil
---
fs/btrfs/export.c |4 ++--
fs/ceph/export.c|4 ++--
fs/fuse/inode.c |2 +-
fs/gfs2/export.c|4 ++--
fs/isofs/export.c |4 ++--
fs/nilfs2/namei.c |4 ++--
fs/ocfs2/export.c |4 ++--
fs/reiserfs/inode.c |4 ++--
fs/udf/namei.c |4 ++--
fs/xfs/xfs_export.c |4 ++--
mm/cleancache.c |2 +-
mm/shmem.c |2 +-
12 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/fs/btrfs/export.c b/fs/btrfs/export.c
index 614f34a..81ee29e 100644
--- a/fs/btrfs/export.c
+++ b/fs/btrfs/export.c
@@ -22,10 +22,10 @@ static int btrfs_encode_fh(struct inode *inode, u32 *fh,
int *max_len,
if (parent && (len < BTRFS_FID_SIZE_CONNECTABLE)) {
*max_len = BTRFS_FID_SIZE_CONNECTABLE;
- return 255;
+ return FILEID_INVALID;
} else if (len < BTRFS_FID_SIZE_NON_CONNECTABLE) {
*max_len = BTRFS_FID_SIZE_NON_CONNECTABLE;
- return 255;
+ return FILEID_INVALID;
}
len = BTRFS_FID_SIZE_NON_CONNECTABLE;
diff --git a/fs/ceph/export.c b/fs/ceph/export.c
index ca3ab3f..16796be 100644
--- a/fs/ceph/export.c
+++ b/fs/ceph/export.c
@@ -81,7 +81,7 @@ static int ceph_encode_fh(struct inode *inode, u32 *rawfh,
int *max_len,
if (parent_inode) {
/* nfsd wants connectable */
*max_len = connected_handle_length;
- type = 255;
+ type = FILEID_INVALID;
} else {
dout("encode_fh %p\n", dentry);
fh->ino = ceph_ino(inode);
@@ -90,7 +90,7 @@ static int ceph_encode_fh(struct inode *inode, u32 *rawfh,
int *max_len,
}
} else {
*max_len = handle_length;
- type = 255;
+ type = FILEID_INVALID;
}
if (dentry)
dput(dentry);
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 9876a87..973e8f0 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -679,7 +679,7 @@ static int fuse_encode_fh(struct inode *inode, u32 *fh, int
*max_len,
if (*max_len < len) {
*max_len = len;
- return 255;
+ return FILEID_INVALID;
}
nodeid = get_fuse_inode(inode)->nodeid;
diff --git a/fs/gfs2/export.c b/fs/gfs2/export.c
index 4767774..9973df4 100644
--- a/fs/gfs2/export.c
+++ b/fs/gfs2/export.c
@@ -37,10 +37,10 @@ static int gfs2_encode_fh(struct inode *inode, __u32 *p,
int *len,
if (parent && (*len < GFS2_LARGE_FH_SIZE)) {
*len = GFS2_LARGE_FH_SIZE;
- return 255;
+ return FILEID_INVALID;
} else if (*len < GFS2_SMALL_FH_SIZE) {
*len = GFS2_SMALL_FH_SIZE;
- return 255;
+ return FILEID_INVALID;
}
fh[0] = cpu_to_be32(ip->i_no_formal_ino >> 32);
diff --git a/fs/isofs/export.c b/fs/isofs/export.c
index 2b4f235..12088d8 100644
--- a/fs/isofs/export.c
+++ b/fs/isofs/export.c
@@ -125,10 +125,10 @@ isofs_export_encode_fh(struct inode *inode,
*/
if (parent && (len < 5)) {
*max_len = 5;
- return 255;
+ return FILEID_INVALID;
} else if (len < 3) {
*max_len = 3;
- return 255;
+ return FILEID_INVALID;
}
len = 3;
diff --git a/fs/nilfs2/namei.c b/fs/nilfs2/namei.c
index 1d0c0b8..9de78f0 100644
--- a/fs/nilfs2/namei.c
+++ b/fs/nilfs2/namei.c
@@ -517,11 +517,11 @@ static int nilfs_encode_fh(struct inode *inode, __u32
*fh, int *lenp,
if (parent && *lenp < NILFS_FID_SIZE_CONNECTABLE) {
*lenp = NILFS_FID_SIZE_CONNECTABLE;
- return 255;
+ return FILEID_INVALID;
}
if (*lenp < NILFS_FID_SIZE_NON_CONNECTABLE) {
*lenp = NILFS_FID_SIZE_NON_CONNECTABLE;
- return 255;
+ return FILEID_INVALID;
}
fid->cno = root->cno;
diff --git a/fs/ocfs2/export.c b/fs/ocfs2/export.c
index 322216a..2965116 100644
--- a/fs/ocfs2/export.c
+++ b/fs/ocfs2/export.c
@@ -195,11 +195,11 @@ static int ocfs2_encode_fh(struct inode *inode, u32
*fh_in, int *max_len,
if (parent && (len < 6)) {
*max_len = 6;
- type = 255;
+ type = FILEID_INVALID;
goto bail;
} else if (len < 3) {
*max_len = 3;
- type = 255;
+ type = FILEID_INVALID;
goto bail;
}
diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/i
Re: [PATCH 3/9] virtio-blk: use virtqueue_start_buf on bio path
On 02/12/2013 08:23 PM, Paolo Bonzini wrote:
> Move the creation of the request header and response footer to
> __virtblk_add_req. vbr->sg only contains the data scatterlist,
> the header/footer are added separately using the new piecewise
> API for building virtqueue buffers.
>
> With this change, virtio-blk (with use_bio) is not relying anymore on
> the virtio functions ignoring the end markers in a scatterlist.
> The next patch will do the same for the other path.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Asias He
> ---
> drivers/block/virtio_blk.c | 74 ++-
> 1 files changed, 45 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index fd8a689..4a31fcc 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -62,6 +62,7 @@ struct virtblk_req
> struct virtio_blk *vblk;
> int flags;
> u8 status;
> + int nents;
> struct scatterlist sg[];
> };
>
> @@ -100,24 +101,52 @@ static inline struct virtblk_req
> *virtblk_alloc_req(struct virtio_blk *vblk,
> return vbr;
> }
>
> -static inline int __virtblk_add_req(struct virtqueue *vq,
> - struct virtblk_req *vbr,
> - unsigned long out,
> - unsigned long in)
> +static int __virtblk_add_req(struct virtqueue *vq,
> + struct virtblk_req *vbr)
> {
> - return virtqueue_add_buf(vq, vbr->sg, out, in, vbr, GFP_ATOMIC);
> + struct scatterlist sg;
> + enum dma_data_direction dir;
> + int ret;
> +
> + unsigned int nents = 2;
> + unsigned int nsg = 2;
> +
> + if (vbr->nents) {
> + nsg++;
> + nents += vbr->nents;
> + }
> +
> + ret = virtqueue_start_buf(vq, vbr, nents, nsg, GFP_ATOMIC);
> + if (ret < 0)
> + return ret;
> +
> + dir = DMA_TO_DEVICE;
> + sg_init_one(&sg, &vbr->out_hdr, sizeof(vbr->out_hdr));
> + virtqueue_add_sg(vq, &sg, 1, dir);
> +
> + if (vbr->nents) {
> + if ((vbr->out_hdr.type & VIRTIO_BLK_T_OUT) == 0)
> + dir = DMA_FROM_DEVICE;
> +
> + virtqueue_add_sg(vq, vbr->sg, vbr->nents, dir);
> + }
> +
> + dir = DMA_FROM_DEVICE;
> + sg_init_one(&sg, &vbr->status, sizeof(vbr->status));
> + virtqueue_add_sg(vq, &sg, 1, dir);
> +
> + virtqueue_end_buf(vq);
> + return 0;
> }
>
> -static void virtblk_add_req(struct virtblk_req *vbr,
> - unsigned int out, unsigned int in)
> +static void virtblk_add_req(struct virtblk_req *vbr)
> {
> struct virtio_blk *vblk = vbr->vblk;
> DEFINE_WAIT(wait);
> int ret;
>
> spin_lock_irq(vblk->disk->queue->queue_lock);
> - while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr,
> - out, in)) < 0)) {
> + while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr)) < 0)) {
> prepare_to_wait_exclusive(&vblk->queue_wait, &wait,
> TASK_UNINTERRUPTIBLE);
>
> @@ -134,22 +163,18 @@ static void virtblk_add_req(struct virtblk_req *vbr,
>
> static void virtblk_bio_send_flush(struct virtblk_req *vbr)
> {
> - unsigned int out = 0, in = 0;
> -
> vbr->flags |= VBLK_IS_FLUSH;
> vbr->out_hdr.type = VIRTIO_BLK_T_FLUSH;
> vbr->out_hdr.sector = 0;
> vbr->out_hdr.ioprio = 0;
> - sg_set_buf(&vbr->sg[out++], &vbr->out_hdr, sizeof(vbr->out_hdr));
> - sg_set_buf(&vbr->sg[out + in++], &vbr->status, sizeof(vbr->status));
> + vbr->nents = 0;
>
> - virtblk_add_req(vbr, out, in);
> + virtblk_add_req(vbr);
> }
>
> static void virtblk_bio_send_data(struct virtblk_req *vbr)
> {
> struct virtio_blk *vblk = vbr->vblk;
> - unsigned int num, out = 0, in = 0;
> struct bio *bio = vbr->bio;
>
> vbr->flags &= ~VBLK_IS_FLUSH;
> @@ -157,24 +182,15 @@ static void virtblk_bio_send_data(struct virtblk_req
> *vbr)
> vbr->out_hdr.sector = bio->bi_sector;
> vbr->out_hdr.ioprio = bio_prio(bio);
>
> - sg_set_buf(&vbr->sg[out++], &vbr->out_hdr, sizeof(vbr->out_hdr));
> -
> - num = blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg + out);
> -
> - sg_set_buf(&vbr->sg[num + out + in++], &vbr->status,
> -sizeof(vbr->status));
> -
> - if (num) {
> - if (bio->bi_rw & REQ_WRITE) {
> + vbr->nents = blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg);
> + if (vbr->nents) {
> + if (bio->bi_rw & REQ_WRITE)
> vbr->out_hdr.type |= VIRTIO_BLK_T_OUT;
> - out += num;
> - } else {
> + else
> vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
> - in += num;
> - }
> }
>
> - virtblk_add_req(vbr, out, in);
> + virtblk_add_req(vbr);
> }
>
> static void virtb
Re: [PATCH 2/9] virtio-blk: reorganize virtblk_add_req
On 02/12/2013 08:23 PM, Paolo Bonzini wrote:
> Right now, both virtblk_add_req and virtblk_add_req_wait call
> virtqueue_add_buf. To prepare for the next patches, abstract the call
> to virtqueue_add_buf into a new function __virtblk_add_req, and include
> the waiting logic directly in virtblk_add_req.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Asias He
> ---
> drivers/block/virtio_blk.c | 55
>
> 1 files changed, 20 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 8ad21a2..fd8a689 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -100,50 +100,39 @@ static inline struct virtblk_req
> *virtblk_alloc_req(struct virtio_blk *vblk,
> return vbr;
> }
>
> -static void virtblk_add_buf_wait(struct virtio_blk *vblk,
> - struct virtblk_req *vbr,
> - unsigned long out,
> - unsigned long in)
> +static inline int __virtblk_add_req(struct virtqueue *vq,
> + struct virtblk_req *vbr,
> + unsigned long out,
> + unsigned long in)
> {
> + return virtqueue_add_buf(vq, vbr->sg, out, in, vbr, GFP_ATOMIC);
> +}
> +
> +static void virtblk_add_req(struct virtblk_req *vbr,
> + unsigned int out, unsigned int in)
> +{
> + struct virtio_blk *vblk = vbr->vblk;
> DEFINE_WAIT(wait);
> + int ret;
>
> - for (;;) {
> + spin_lock_irq(vblk->disk->queue->queue_lock);
> + while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr,
> + out, in)) < 0)) {
> prepare_to_wait_exclusive(&vblk->queue_wait, &wait,
> TASK_UNINTERRUPTIBLE);
>
> + spin_unlock_irq(vblk->disk->queue->queue_lock);
> + io_schedule();
> spin_lock_irq(vblk->disk->queue->queue_lock);
> - if (virtqueue_add_buf(vblk->vq, vbr->sg, out, in, vbr,
> - GFP_ATOMIC) < 0) {
> - spin_unlock_irq(vblk->disk->queue->queue_lock);
> - io_schedule();
> - } else {
> - virtqueue_kick(vblk->vq);
> - spin_unlock_irq(vblk->disk->queue->queue_lock);
> - break;
> - }
>
> + finish_wait(&vblk->queue_wait, &wait);
> }
>
> - finish_wait(&vblk->queue_wait, &wait);
> -}
> -
> -static inline void virtblk_add_req(struct virtblk_req *vbr,
> -unsigned int out, unsigned int in)
> -{
> - struct virtio_blk *vblk = vbr->vblk;
> -
> - spin_lock_irq(vblk->disk->queue->queue_lock);
> - if (unlikely(virtqueue_add_buf(vblk->vq, vbr->sg, out, in, vbr,
> - GFP_ATOMIC) < 0)) {
> - spin_unlock_irq(vblk->disk->queue->queue_lock);
> - virtblk_add_buf_wait(vblk, vbr, out, in);
> - return;
> - }
> virtqueue_kick(vblk->vq);
> spin_unlock_irq(vblk->disk->queue->queue_lock);
> }
>
> -static int virtblk_bio_send_flush(struct virtblk_req *vbr)
> +static void virtblk_bio_send_flush(struct virtblk_req *vbr)
> {
> unsigned int out = 0, in = 0;
>
> @@ -155,11 +144,9 @@ static int virtblk_bio_send_flush(struct virtblk_req
> *vbr)
> sg_set_buf(&vbr->sg[out + in++], &vbr->status, sizeof(vbr->status));
>
> virtblk_add_req(vbr, out, in);
> -
> - return 0;
> }
>
> -static int virtblk_bio_send_data(struct virtblk_req *vbr)
> +static void virtblk_bio_send_data(struct virtblk_req *vbr)
> {
> struct virtio_blk *vblk = vbr->vblk;
> unsigned int num, out = 0, in = 0;
> @@ -188,8 +175,6 @@ static int virtblk_bio_send_data(struct virtblk_req *vbr)
> }
>
> virtblk_add_req(vbr, out, in);
> -
> - return 0;
> }
>
> static void virtblk_bio_send_data_work(struct work_struct *work)
>
--
Asias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] virtio-blk: use virtqueue_start_buf on req path
On 02/12/2013 08:23 PM, Paolo Bonzini wrote:
> This is similar to the previous patch, but a bit more radical
> because the bio and req paths now share the buffer construction
> code. Because the req path doesn't use vbr->sg, however, we
> need to add a couple of arguments to __virtblk_add_req.
>
> We also need to teach __virtblk_add_req how to build SCSI command
> requests.
>
> Signed-off-by: Paolo Bonzini
> ---
> drivers/block/virtio_blk.c | 74 ++-
> 1 files changed, 38 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 4a31fcc..22deb65 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -102,18 +102,26 @@ static inline struct virtblk_req
> *virtblk_alloc_req(struct virtio_blk *vblk,
> }
>
> static int __virtblk_add_req(struct virtqueue *vq,
> - struct virtblk_req *vbr)
> + struct virtblk_req *vbr,
> + struct scatterlist *data_sg,
> + unsigned data_nents)
> {
> struct scatterlist sg;
> enum dma_data_direction dir;
> int ret;
>
> + int type = vbr->out_hdr.type & ~VIRTIO_BLK_T_OUT;
> unsigned int nents = 2;
> unsigned int nsg = 2;
>
> - if (vbr->nents) {
> + if (type == VIRTIO_BLK_T_SCSI_CMD) {
> + BUG_ON(use_bio);
Do we really need the BUG_ON? Even if with use_bio=1,
VIRTIO_BLK_T_SCSI_CMD cmd can be fired. See this:
# cat /proc/cmdline
root=/dev/mapper/rhel-root console=ttyS0 virtio_blk.use_bio=1
# sg_inq /dev/vda
[ 36.042300] [ cut here ]
[ 36.043021] kernel BUG at drivers/block/virtio_blk.c:118!
[ 36.043021] invalid opcode: [#1] SMP
[ 36.043021] Modules linked in:
[ 36.043021] CPU 2
[ 36.043021] Pid: 3311, comm: sg_inq Not tainted 3.8.0-rc7+ #618 Bochs
Bochs
[ 36.043021] RIP: 0010:[] []
__virtblk_add_req+0x1cd/0x1e0
[ 36.043021] RSP: 0018:88007b59b9d8 EFLAGS: 00010002
[ 36.043021] RAX: 0001 RBX: 0002 RCX:
0002
[ 36.043021] RDX: 0002 RSI: 88007a43 RDI:
88007b422000
[ 36.043021] RBP: 88007b59ba28 R08: 88007b59b9e0 R09:
88007b59b9f4
[ 36.043021] R10: 0001 R11: 88007bf57900 R12:
88007a43
[ 36.043021] R13: 88007b422000 R14: 0001 R15:
880077d34088
[ 36.043021] FS: 7eff2efcb740() GS:88007eb0()
knlGS:
[ 36.043021] CS: 0010 DS: ES: CR0: 80050033
[ 36.043021] CR2: 003f33e0f200 CR3: 7f023000 CR4:
06e0
[ 36.043021] DR0: DR1: DR2:
[ 36.043021] DR3: DR6: 0ff0 DR7:
0400
[ 36.043021] Process sg_inq (pid: 3311, threadinfo 88007b59a000,
task 88007f47a3f0)
[ 36.043021] Stack:
[ 36.043021] 88007b59ba40 880077d34088 88007bf57980
00010001
[ 36.043021] 88007fffa6c0 88007a43 88007f66abc0
880077d34000
[ 36.043021] 88007bdab410 88007b59ba78
816d7f6c
[ 36.043021] Call Trace:
[ 36.043021] [] virtblk_request+0xec/0x1c0
[ 36.043021] [] __blk_run_queue+0x37/0x50
[ 36.043021] [] __elv_add_request+0xb0/0x230
[ 36.043021] [] blk_execute_rq_nowait+0x79/0x100
[ 36.043021] [] ? bio_phys_segments+0x21/0x30
[ 36.043021] [] blk_execute_rq+0x6d/0xf0
[ 36.043021] [] ? blk_rq_append_bio+0x28/0x70
[ 36.043021] [] ? blk_rq_map_user+0x1a0/0x280
[ 36.043021] [] sg_io+0x274/0x3e0
[ 36.043021] [] scsi_cmd_ioctl+0x3e5/0x460
[ 36.043021] [] ? handle_pte_fault+0xf6/0x9c0
[ 36.043021] [] ? release_pages+0x190/0x1e0
[ 36.043021] [] scsi_cmd_blk_ioctl+0x51/0x70
[ 36.043021] [] virtblk_ioctl+0x6c/0x90
[ 36.043021] [] __blkdev_driver_ioctl+0x28/0x30
[ 36.043021] [] blkdev_ioctl+0x200/0x7b0
[ 36.043021] [] ? cp_new_stat+0x116/0x130
[ 36.043021] [] block_ioctl+0x3c/0x40
[ 36.043021] [] do_vfs_ioctl+0x9a/0x550
[ 36.043021] [] sys_ioctl+0x57/0x90
[ 36.043021] [] ? trace_hardirqs_on_thunk+0x3a/0x3c
[ 36.043021] [] system_call_fastpath+0x16/0x1b
[ 36.043021] Code: 24 20 48 8d 7d b0 ba 10 00 00 00 e8 2e 3d de ff 48
8d 75 b0 b9 02 00 00 00 ba 01 00 00 00 4c 89 ef e8 88 bb e6 ff
e9 d9 fe ff ff <0f> 0b eb fe 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
00 55 48
[ 36.043021] RIP [] __virtblk_add_req+0x1cd/0x1e0
[ 36.043021] RSP
[ 36.043021] ---[ end trace 93ac0a3ba2789369 ]---
> + nsg += 3;
> + nents += 3;
> + }
> + if (data_nents) {
> nsg++;
> - nents += vbr->nents;
> + nents += data_nents;
> }
>
> ret = virtqueue_start_buf(vq, vbr, nents, nsg, GFP_ATOMIC);
> @@ -124,14 +132,32 @@ static int __virtblk_add_req(struct virtqueue *vq,
> sg_init_one(&sg, &vbr->out
Re: WARNING: at drivers/tty/tty_buffer.c:476 (tty is NULL)
Hi Peter, On Mon, Feb 11, 2013 at 09:42:30AM -0500, Peter Hurley wrote: > Can you reproduce after using the following patch series? > [PATCH v3 00/23] ldisc fixes > I'm constantly seeing this warning on my board (imx6q - ARM Cortex-A9 Quad) with -next kernel, while I believe v3.8-rc kernel works just fine for me. The warning can be seen during both boot and suspend/resume (in a couple of iterations). The bad thing is "[PATCH v3 00/23] ldisc fixes" does not help my case at all. Shawn Booting Linux on physical CPU 0x0 Linux version 3.8.0-rc7-next-20130215+ (r65073@S2101-09) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #330 SMP Sun Feb 17 13:59:44 CST 2013 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: Freescale i.MX6 Quad (Device Tree), model: Freescale i.MX6Q SABRE Smart Device Board Memory policy: ECC disabled, Data cache writealloc On node 0 totalpages: 262144 free_area_init_node: node 0, pgdat 80746180, node_mem_map 8079f000 Normal zone: 2048 pages used for memmap Normal zone: 0 pages reserved Normal zone: 262144 pages, LIFO batch:31 PERCPU: Embedded 7 pages/cpu @80fad000 s6656 r8192 d13824 u32768 pcpu-alloc: s6656 r8192 d13824 u32768 alloc=8*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: console=ttymxc0,115200 debug earlyprintk no_console_suspend root=/dev/nfs ip=dhcp nfsroot=192.168.1.100:/home/r65073/nfs/rfs-imx6q,v3,tcp PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) __ex_table already sorted, skipping sort Memory: 1024MB = 1024MB total Memory: 1031576k/1031576k available, 17000k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xc080 - 0xff00 (1000 MB) lowmem : 0x8000 - 0xc000 (1024 MB) modules : 0x7f00 - 0x8000 ( 16 MB) .text : 0x80008000 - 0x806aff04 (6816 kB) .init : 0x806b - 0x806faa00 ( 299 kB) .data : 0x806fc000 - 0x80746ae0 ( 299 kB) .bss : 0x80746ae0 - 0x8079ef54 ( 354 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Hierarchical RCU implementation. NR_IRQS:16 nr_irqs:16 16 L310 cache controller enabled l2x0: 16 ways, CACHE_ID 0x00c0, AUX_CTRL 0x0207, Cache size: 1048576 B sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 65075ms smp_twd: clock not found -2 CPU identified as i.MX6Q, silicon rev 1.2 Console: colour dummy device 80x30 Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok CPU0: thread -1, cpu 0, socket 0, mpidr 8000 Calibrating local timer... 396.17MHz. Setting up static identity map for 0x8051f678 - 0x8051f6e8 CPU1: Booted secondary processor CPU1: thread -1, cpu 1, socket 0, mpidr 8001 CPU2: Booted secondary processor CPU2: thread -1, cpu 2, socket 0, mpidr 8002 CPU3: Booted secondary processor CPU3: thread -1, cpu 3, socket 0, mpidr 8003 Brought up 4 CPUs SMP: Total of 4 processors activated (6324.22 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized pinctrl core: initialized pinctrl subsystem regulator-dummy: no parameters NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations syscon 20c8000.anatop: syscon regmap start 0x20c8000 end 0x20c8fff registered vdd1p1: 800 <--> 1375 mV at 1100 mV vdd3p0: 2800 <--> 3150 mV at 3000 mV vdd2p5: 2000 <--> 2750 mV at 2400 mV cpu: 725 <--> 1450 mV at 1100 mV vddpu: 725 <--> 1450 mV at 1100 mV vddsoc: 725 <--> 1450 mV at 1200 mV syscon 20e.iomuxc-gpr: syscon regmap start 0x20e end 0x20e0037 registered imx6q-pinctrl 20e.iomuxc: initialized IMX pinctrl driver bio: create slab at 0 mxs-dma 11.dma-apbh: initialized SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Linux video capture interface: v2.00 pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered Advanced Linux Sound Architecture Driver Initialized. Switching to clocksource mxc_timer1 NET: Registered protocol family 2 TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP: reno registered UDP hash table entries: 512 (order: 2, 16384 bytes) UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport mod
Re: [RFC] sched: The removal of idle_balance()
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote: > I've been working on cleaning up the scheduler a little and I moved the > call to idle_balance() from directly in the scheduler proper into the > idle class. Benchmarks (well hackbench) improved slightly as I did this. > I was adding some more tweaks and running perf stat on the results when > I made a mistake and notice a drastic change. > > My runs looked something like this on my i7 4 core 4 hyperthreads: > > 293,801,912,874 cycles#1.470 GHz > ( +- 4.20% ) [100.00%] > 215,927,081,108 cycles#2.198 GHz > ( +- 5.48% ) [100.00%] Hm. Maybe set governor to performance? -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: The removal of idle_balance()
On Sat, 2013-02-16 at 11:12 -0500, Steven Rostedt wrote: > On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote: > > On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote: > > > > > Think about it some more, just because we go idle isn't enough reason to > > > pull a runable task over. CPUs go idle all the time, and tasks are woken > > > up all the time. There's no reason that we can't just wait for the sched > > > tick to decide its time to do a bit of balancing. Sure, it would be nice > > > if the idle CPU did the work. But I think that frame of mind was an > > > incorrect notion from back in the early 2000s and does not apply to > > > today's hardware, or perhaps it doesn't apply to the (relatively) new > > > CFS scheduler. If you want aggressive scheduling, make the task rt, and > > > it will do aggressive scheduling. > > > > (the throttle is supposed to keep idle_balance() from doing severe > > damage, that may want a peek/tweak) > > > > Hackbench spreads itself with FORK/EXEC balancing, how does say a kbuild > > do with no idle_balance()? > > > > Interesting, I added this patch and it brought down my hackbench to the > same level as removing idle_balance(). The typo did it's job well :) Hrm, turning idle balancing off here does not help hackbench at all. 3.8.0-master Q6600 +SD_BALANCE_NEWIDLE Performance counter stats for 'hackbench -l 500' (100 runs): 5221.559519 task-clock#4.001 CPUs utilized ( +- 0.26% ) [100.00%] 129863 context-switches #0.025 M/sec ( +- 3.65% ) [100.00%] 7576 cpu-migrations#0.001 M/sec ( +- 4.60% ) [100.00%] 31095 page-faults #0.006 M/sec ( +- 0.39% ) 12258227539 cycles#2.348 GHz ( +- 0.27% ) [49.91%] stalled-cycles-frontend stalled-cycles-backend 5395089628 instructions #0.44 insns per cycle ( +- 0.28% ) [74.99%] 1012563262 branches # 193.920 M/sec ( +- 0.28% ) [75.08%] 43217098 branch-misses #4.27% of all branches ( +- 0.23% ) [75.01%] 1.305024749 seconds time elapsed ( +- 0.26% ) Q6600 -SD_BALANCE_NEWIDLE Performance counter stats for 'hackbench -l 500' (100 runs): 5356.549500 task-clock#4.001 CPUs utilized ( +- 0.37% ) [100.00%] 153093 context-switches #0.029 M/sec ( +- 3.20% ) [100.00%] 6887 cpu-migrations#0.001 M/sec ( +- 4.65% ) [100.00%] 31248 page-faults #0.006 M/sec ( +- 0.48% ) 12141992004 cycles#2.267 GHz ( +- 0.30% ) [49.90%] stalled-cycles-frontend stalled-cycles-backend 5426436261 instructions #0.45 insns per cycle ( +- 0.22% ) [75.00%] 1016967893 branches # 189.855 M/sec ( +- 0.22% ) [75.09%] 43207200 branch-misses #4.25% of all branches ( +- 0.13% ) [75.01%] 1.338768889 seconds time elapsed ( +- 0.37% ) E5620+HT +SD_BALANCE_NEWIDLE Performance counter stats for 'hackbench -l 500' (100 runs): 3884.162557 task-clock#7.997 CPUs utilized ( +- 0.14% ) [100.00%] 97366 context-switches #0.025 M/sec ( +- 1.68% ) [100.00%] 12383 CPU-migrations#0.003 M/sec ( +- 3.29% ) [100.00%] 30749 page-faults #0.008 M/sec ( +- 0.13% ) 9377671582 cycles#2.414 GHz ( +- 0.11% ) [83.04%] 6973792586 stalled-cycles-frontend # 74.37% frontend cycles idle ( +- 0.15% ) [83.27%] 2529338603 stalled-cycles-backend# 26.97% backend cycles idle ( +- 0.32% ) [66.93%] 5214109586 instructions #0.56 insns per cycle #1.34 stalled cycles per insn ( +- 0.07% ) [83.50%] 984681811 branches # 253.512 M/sec ( +- 0.07% ) [83.56%] 7050196 branch-misses #0.72% of all branches ( +- 0.49% ) [83.24%] 0.485726223 seconds time elapsed ( +- 0.14% ) E5620+HT -SD_BALANCE_NEWIDLE Performance counter stats for 'hackbench -l 500' (100 runs): 4124.204725 task-clock#7.996 CPUs utilized ( +- 0.20% ) [100.00%] 151292 c
Re: [PATCH v2] zsmalloc: Add Kconfig for enabling PTE method
On 02/06/2013 10:17 AM, Minchan Kim wrote:
Zsmalloc has two methods 1) copy-based and 2) pte-based to access
allocations that span two pages. You can see history why we supported
two approach from [1].
In summary, copy-based method is 3 times fater in x86 while pte-based
is 6 times faster in ARM.
Why in some arches copy-based method is better and in the other arches
pte-based is better? What's the root reason?
But it was bad choice that adding hard coding to select architecture
which want to use pte based method. This patch removed it and adds
new Kconfig to select the approach.
This patch is based on next-20130205.
[1] https://lkml.org/lkml/2012/7/11/58
* Changelog from v1
* Fix CONFIG_PGTABLE_MAPPING in zsmalloc-main.c - Greg
Cc: Andrew Morton
Cc: Seth Jennings
Cc: Nitin Gupta
Cc: Dan Magenheimer
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Minchan Kim
---
drivers/staging/zsmalloc/Kconfig | 12
drivers/staging/zsmalloc/zsmalloc-main.c | 20 +---
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/zsmalloc/Kconfig b/drivers/staging/zsmalloc/Kconfig
index 9084565..232b3b6 100644
--- a/drivers/staging/zsmalloc/Kconfig
+++ b/drivers/staging/zsmalloc/Kconfig
@@ -8,3 +8,15 @@ config ZSMALLOC
non-standard allocator interface where a handle, not a pointer, is
returned by an alloc(). This handle must be mapped in order to
access the allocated space.
+
+config PGTABLE_MAPPING
+bool "Use page table mapping to access allocations that span two pages"
+depends on ZSMALLOC
+default n
+help
+ By default, zsmalloc uses a copy-based object mapping method to access
+ allocations that span two pages. However, if a particular architecture
+ performs VM mapping faster than copying, then you should select this.
+ This causes zsmalloc to use page table mapping rather than copying
+ for object mapping. You can check speed with zsmalloc benchmark[1].
+ [1] https://github.com/spartacus06/zsmalloc
diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
b/drivers/staging/zsmalloc/zsmalloc-main.c
index 06f73a9..2c1805c 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmalloc/zsmalloc-main.c
@@ -207,6 +207,7 @@ struct zs_pool {
struct size_class size_class[ZS_SIZE_CLASSES];
gfp_t flags; /* allocation flags used when growing pool */
+
};
/*
@@ -218,19 +219,8 @@ struct zs_pool {
#define CLASS_IDX_MASK((1 << CLASS_IDX_BITS) - 1)
#define FULLNESS_MASK ((1 << FULLNESS_BITS) - 1)
-/*
- * By default, zsmalloc uses a copy-based object mapping method to access
- * allocations that span two pages. However, if a particular architecture
- * performs VM mapping faster than copying, then it should be added here
- * so that USE_PGTABLE_MAPPING is defined. This causes zsmalloc to use
- * page table mapping rather than copying for object mapping.
-*/
-#if defined(CONFIG_ARM)
-#define USE_PGTABLE_MAPPING
-#endif
-
struct mapping_area {
-#ifdef USE_PGTABLE_MAPPING
+#ifdef CONFIG_PGTABLE_MAPPING
struct vm_struct *vm; /* vm area for mapping object that span pages */
#else
char *vm_buf; /* copy buffer for objects that span pages */
@@ -622,7 +612,7 @@ static struct page *find_get_zspage(struct size_class
*class)
return page;
}
-#ifdef USE_PGTABLE_MAPPING
+#ifdef CONFIG_PGTABLE_MAPPING
static inline int __zs_cpu_up(struct mapping_area *area)
{
/*
@@ -663,7 +653,7 @@ static inline void __zs_unmap_object(struct mapping_area
*area,
flush_tlb_kernel_range(addr, end);
}
-#else /* USE_PGTABLE_MAPPING */
+#else /* CONFIG_PGTABLE_MAPPING*/
static inline int __zs_cpu_up(struct mapping_area *area)
{
@@ -741,7 +731,7 @@ out:
pagefault_enable();
}
-#endif /* USE_PGTABLE_MAPPING */
+#endif /* CONFIG_PGTABLE_MAPPING */
static int zs_cpu_notifier(struct notifier_block *nb, unsigned long action,
void *pcpu)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] input: tsc2005: Add MODULE_ALIAS
On Sun, Feb 17, 2013 at 01:27:52AM +0100, Pali Rohár wrote:
> * This patch enable autoloading tsc2005 driver when is compiled as module
>
> Signed-off-by: Pali Rohár
> ---
> drivers/input/touchscreen/tsc2005.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/touchscreen/tsc2005.c
> b/drivers/input/touchscreen/tsc2005.c
> index 9c0cdc7..7213e8b 100644
> --- a/drivers/input/touchscreen/tsc2005.c
> +++ b/drivers/input/touchscreen/tsc2005.c
> @@ -753,3 +753,4 @@ module_spi_driver(tsc2005_driver);
> MODULE_AUTHOR("Lauri Leukkunen ");
> MODULE_DESCRIPTION("TSC2005 Touchscreen Driver");
> MODULE_LICENSE("GPL");
> +MODULE_ALIAS("spi:tsc2005");
Applied, thank you Pali.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dmi_scan: Refactor dmi_scan_machine(), {smbios,dmi}_present()
On Sat, Feb 16, 2013 at 06:02:22PM +, Ben Hutchings wrote: > Tim, you might like to test that this doesn't cause a regression > of the previous fix. > > Ben. Ugh, I see what happened now. I only got one copy of this email which was 'helpfully' sorted into the linux kernel mailbox. gmail really doesn't help with things like this, sorry Ben, I'll test this as soon as I can. Tim Mcgrath pgpuiTzS8fFXB.pgp Description: PGP signature
Re: [PATCH 1/2] dmi_scan: Fix missing check for _DMI_ signature in smbios_present()
On Sat, Feb 16, 2013 at 06:35:04PM -0800, Zhenzhong Duan wrote:
>
> - b...@decadent.org.uk wrote???
>
> > Commit 9f9c9cbb6057 ('drivers/firmware/dmi_scan.c: fetch dmi version
> > from SMBIOS if it exists') hoisted the check for "_DMI_" into
> > dmi_scan_machine(), which means that we don't bother to check for
> > "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also
> > call dmi_present() for an address where we found "_SM_", if it failed
> > further validation.
> >
> > Check for "_DMI_" in smbios_present() before calling dmi_present().
> >
> > Reported-by: Tim McGrath
> > Signed-off-by: Ben Hutchings
> > Cc: stable
> > ---
> > This has a memcmp() that wasn't in the previous version, so I've not
> > included the Acked-by or Tested-by for that.
> Yes, the further "_DMI_" check is needed.
> Acked-by: Zhenzhong Duan
> >
> > Ben.
> >
> > drivers/firmware/dmi_scan.c |5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/firmware/dmi_scan.c
> > b/drivers/firmware/dmi_scan.c
> > index 982f1f5..a86ccff 100644
> > --- a/drivers/firmware/dmi_scan.c
> > +++ b/drivers/firmware/dmi_scan.c
> > @@ -442,7 +442,6 @@ static int __init dmi_present(const char __iomem
> > *p)
> > static int __init smbios_present(const char __iomem *p)
> > {
> > u8 buf[32];
> > - int offset = 0;
> >
> > memcpy_fromio(buf, p, 32);
> > if ((buf[5] < 32) && dmi_checksum(buf, buf[5])) {
> > @@ -461,9 +460,9 @@ static int __init smbios_present(const char
> > __iomem *p)
> > dmi_ver = 0x0206;
> > break;
> > }
> > - offset = 16;
> > + return memcmp(q + 16, "_DMI_", 5) || dmi_present(p + 16);
> > }
> > - return dmi_present(buf + offset);
> > + return 1;
> > }
> >
> > void __init dmi_scan_machine(void)
I'm a little confused, do you need me to test something?
Tim McGrath
pgpkPT5nexL3S.pgp
Description: PGP signature
sched: circular dependency between sched_domains_mutex and oom_notify_list
Hi all,
I was fuzzing with trinity inside a KVM tools guest, with today's -next kernel
when I've hit the following spew.
I suspect it's the result of adding the new rcu_oom_notify, but that happened
about half a year ago so I'm not sure why this showed up only now.
[ 1039.634183] ==
[ 1039.635717] [ INFO: possible circular locking dependency detected ]
[ 1039.637255] 3.8.0-rc7-next-20130215-sasha-3-gea816fa #286 Tainted: G
W
[ 1039.639104] ---
[ 1039.640579] init/1 is trying to acquire lock:
[ 1039.641224] ((oom_notify_list).rwsem){.+.+..}, at: []
__blocking_notifier_call_chain+0x7f/0xc0
[ 1039.641224]
[ 1039.641224] but task is already holding lock:
[ 1039.641224] (sched_domains_mutex){+.+.+.}, at: []
partition_sched_domains+0x28/0x3f0
[ 1039.641224]
[ 1039.641224] which lock already depends on the new lock.
[ 1039.641224]
[ 1039.641224]
[ 1039.641224] the existing dependency chain (in reverse order) is:
[ 1039.641224]
-> #2 (sched_domains_mutex){+.+.+.}:
[ 1039.641224][] check_prevs_add+0xba/0x1a0
[ 1039.641224][] validate_chain.isra.21+0x6a0/0x7b0
[ 1039.641224][] __lock_acquire+0xa13/0xb00
[ 1039.641224][] lock_acquire+0x1ca/0x270
[ 1039.641224][] __mutex_lock_common+0x5a/0x560
[ 1039.641224][] mutex_lock_nested+0x3f/0x50
[ 1039.641224][] partition_sched_domains+0x28/0x3f0
[ 1039.641224][] cpuset_cpu_inactive+0x3b/0x50
[ 1039.641224][] notifier_call_chain+0xee/0x130
[ 1039.641224][] __raw_notifier_call_chain+0x9/0x10
[ 1039.641224][] __cpu_notify+0x1b/0x30
[ 1039.641224][] _cpu_down+0xaf/0x350
[ 1039.641224][] disable_nonboot_cpus+0x84/0x1c0
[ 1039.641224][] kernel_restart+0x16/0x60
[ 1039.641224][] sys_reboot+0x161/0x2b0
[ 1039.641224][] tracesys+0xe1/0xe6
[ 1039.641224]
-> #1 (cpu_hotplug.lock){+.+.+.}:
[ 1039.641224][] check_prevs_add+0xba/0x1a0
[ 1039.641224][] validate_chain.isra.21+0x6a0/0x7b0
[ 1039.641224][] __lock_acquire+0xa13/0xb00
[ 1039.641224][] lock_acquire+0x1ca/0x270
[ 1039.641224][] __mutex_lock_common+0x5a/0x560
[ 1039.641224][] mutex_lock_nested+0x3f/0x50
[ 1039.641224][] get_online_cpus+0x37/0x50
[ 1039.641224][] rcu_oom_notify+0x94/0x150
[ 1039.641224][] notifier_call_chain+0xee/0x130
[ 1039.641224][]
__blocking_notifier_call_chain+0x98/0xc0
[ 1039.641224][]
blocking_notifier_call_chain+0x11/0x20
[ 1039.641224][] out_of_memory+0x45/0x1f0
[ 1039.641224][] __alloc_pages_nodemask+0x83d/0xbf0
[ 1039.641224][] alloc_pages_vma+0xfc/0x150
[ 1039.641224][] read_swap_cache_async+0x90/0x220
[ 1039.641224][] swapin_readahead+0x9e/0xf0
[ 1039.641224][] do_swap_page.isra.41+0x107/0x5a0
[ 1039.641224][] handle_pte_fault+0x126/0x200
[ 1039.641224][] handle_mm_fault+0x397/0x3e0
[ 1039.641224][] __get_user_pages+0x418/0x5f0
[ 1039.641224][] __mlock_vma_pages_range+0xb3/0xc0
[ 1039.641224][] __mm_populate+0xf4/0x170
[ 1039.641224][] sys_mlockall+0x160/0x1a0
[ 1039.641224][] tracesys+0xe1/0xe6
[ 1039.641224]
-> #0 ((oom_notify_list).rwsem){.+.+..}:
[ 1039.641224][] check_prev_add+0x115/0x640
[ 1039.641224][] check_prevs_add+0xba/0x1a0
[ 1039.641224][] validate_chain.isra.21+0x6a0/0x7b0
[ 1039.641224][] __lock_acquire+0xa13/0xb00
[ 1039.641224][] lock_acquire+0x1ca/0x270
[ 1039.641224][] down_read+0x47/0x8e
[ 1039.641224][]
__blocking_notifier_call_chain+0x7f/0xc0
[ 1039.641224][]
blocking_notifier_call_chain+0x11/0x20
[ 1039.641224][] out_of_memory+0x45/0x1f0
[ 1039.641224][] __alloc_pages_nodemask+0x83d/0xbf0
[ 1039.641224][] allocate_slab+0x13a/0x1f0
[ 1039.641224][] new_slab+0x2b/0x1b0
[ 1039.641224][] __slab_alloc.isra.34+0x1c5/0x31f
[ 1039.641224][]
kmem_cache_alloc_node_trace+0x114/0x390
[ 1039.641224][] __sdt_alloc+0x137/0x1f0
[ 1039.641224][] build_sched_domains+0x2c/0x4e0
[ 1039.641224][] partition_sched_domains+0x353/0x3f0
[ 1039.641224][] cpuset_cpu_inactive+0x3b/0x50
[ 1039.641224][] notifier_call_chain+0xee/0x130
[ 1039.641224][] __raw_notifier_call_chain+0x9/0x10
[ 1039.641224][] __cpu_notify+0x1b/0x30
[ 1039.641224][] _cpu_down+0xaf/0x350
[ 1039.641224][] disable_nonboot_cpus+0x84/0x1c0
[ 1039.641224][] kernel_restart+0x16/0x60
[ 1039.641224][] sys_reboot+0x161/0x2b0
[ 1039.641224][] tracesys+0xe1/0xe6
[ 1039.641224]
[ 1039.641224] other info that might help us debug this:
[ 1039.641224]
[ 1039.641224] Chain exists of:
(oom_notify_list).rwsem --> cpu_hotplug.lock --> sched_domains_mutex
[ 1039.641224] Possible unsafe locking scenario:
[
[PATCH 2/2] cgroup: fix cgroup_path() vs rename() race, take 2
rename() will change dentry->d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
a longer name.
As accessing dentry->name must be protected by dentry->d_lock or
parent inode's i_mutex, while on the other hand cgroup-path() can
be called with some irq-safe spinlocks held, we can't generate
cgroup path using dentry->d_name.
Alternatively we make a copy of dentry->d_lock and save it in
cgrp->name when a cgroup is created, and update cgrp->name at
rename().
Signed-off-by: Li Zefan
---
include/linux/cgroup.h | 4 ++-
kernel/cgroup.c| 94 +++---
2 files changed, 76 insertions(+), 22 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 900af59..8b2ce2a 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -171,6 +171,8 @@ struct cgroup {
struct cgroup *parent; /* my parent */
struct dentry *dentry; /* cgroup fs entry, RCU protected */
+ char *name; /* a copy of dentry->d_name */
+ spinlock_t name_lock;
/* Private pointers for each registered subsystem */
struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
@@ -409,7 +411,7 @@ int cgroup_rm_cftypes(struct cgroup_subsys *ss, struct
cftype *cfts);
int cgroup_is_removed(const struct cgroup *cgrp);
-int cgroup_path(const struct cgroup *cgrp, char *buf, int buflen);
+int cgroup_path(struct cgroup *cgrp, char *buf, int buflen);
int cgroup_task_count(const struct cgroup *cgrp);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 5d4c92e..cea6a88 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -890,6 +890,7 @@ static void cgroup_free_fn(struct work_struct *work)
simple_xattrs_free(&cgrp->xattrs);
ida_simple_remove(&cgrp->root->cgroup_ida, cgrp->id);
+ kfree(cgrp->name);
kfree(cgrp);
}
@@ -1410,6 +1411,7 @@ static void init_cgroup_housekeeping(struct cgroup *cgrp)
mutex_init(&cgrp->pidlist_mutex);
INIT_LIST_HEAD(&cgrp->event_list);
spin_lock_init(&cgrp->event_list_lock);
+ spin_lock_init(&cgrp->name_lock);
simple_xattrs_init(&cgrp->xattrs);
}
@@ -1565,6 +1567,18 @@ static int cgroup_get_rootdir(struct super_block *sb)
return 0;
}
+static char *cgroup_alloc_name(struct dentry *dentry)
+{
+ char *name;
+
+ name = kmalloc(dentry->d_name.len + 1, GFP_KERNEL);
+ if (!name)
+ return NULL;
+ memcpy(name, dentry->d_name.name, dentry->d_name.len);
+ name[dentry->d_name.len] = '\0';
+ return name;
+}
+
static struct dentry *cgroup_mount(struct file_system_type *fs_type,
int flags, const char *unused_dev_name,
void *data)
@@ -1613,13 +1627,19 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
int i;
struct hlist_node *node;
struct css_set *cg;
+ struct dentry *dentry;
BUG_ON(sb->s_root != NULL);
ret = cgroup_get_rootdir(sb);
if (ret)
goto drop_new_super;
- inode = sb->s_root->d_inode;
+ dentry = sb->s_root;
+ inode = dentry->d_inode;
+
+ root_cgrp->name = cgroup_alloc_name(dentry);
+ if (!root_cgrp->name)
+ goto drop_new_super;
mutex_lock(&inode->i_mutex);
mutex_lock(&cgroup_mutex);
@@ -1660,8 +1680,8 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
list_add(&root->root_list, &roots);
root_count++;
- sb->s_root->d_fsdata = root_cgrp;
- root->top_cgroup.dentry = sb->s_root;
+ dentry->d_fsdata = root_cgrp;
+ root->top_cgroup.dentry = dentry;
/* Link the top cgroup in this hierarchy into all
* the css_set objects */
@@ -1751,6 +1771,7 @@ static void cgroup_kill_sb(struct super_block *sb) {
mutex_unlock(&cgroup_root_mutex);
mutex_unlock(&cgroup_mutex);
+ kfree(cgrp->name);
simple_xattrs_free(&cgrp->xattrs);
kill_litter_super(sb);
@@ -1774,38 +1795,39 @@ static struct kobject *cgroup_kobj;
* Called with cgroup_mutex held or else with an RCU-protected cgroup
* reference. Writes path of cgroup into buf. Returns 0 on success,
* -errno on error.
+ *
+ * We can't generate cgroup path using dentry->d_name, as accessing
+ * dentry->name must be protected by irq-unsafe dentry->d_lock or
+ * parent inode's i_mutex, while on the other hand cgroup_path() can
+ * be called with some irq-safe spinlocks held.
*/
-int cgroup_path(const struct cgroup *cgrp, char *buf, int buflen)
+int cgroup_path(struct cgroup *cgrp, cha
[PATCH 1/2] Revert "cgroup: fix cgroup_path() vs rename() race"
This reverts commit 299772fab304ab3a36b22b5d28ed81f9408972e7
Sasha reported this:
[ 313.262599] ==
[ 313.271340] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 313.277542] 3.8.0-rc6-next-20130208-sasha-00028-ge4e162d #278 Tainted: G
W
[ 313.277542] --
[ 313.277542] kworker/u:3/4490 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 313.277542] (rename_lock){+.+...}, at: []
dentry_path_raw+0x29/0x70
[ 313.277542]
[ 313.277542] and this task is already holding:
[ 313.277542] (&(&q->__queue_lock)->rlock){-.-...}, at: []
put_io_context_active+0x63/0x100
[ 313.277542] which would create a new lock dependency:
[ 313.277542] (&(&q->__queue_lock)->rlock){-.-...} -> (rename_lock){+.+...}
[ 313.277542]
[ 313.277542] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 313.277542] (&(&q->__queue_lock)->rlock){-.-...}
dentry_path_raw() grabs rename_lock and dentry->d_lock without disabling
irqs, which means cgroup_path() can't be called if the caller has already
held a spinlock with irq disabled.
Reported-by: Sasha Levin
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 776ff75..5d4c92e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1792,10 +1792,26 @@ int cgroup_path(const struct cgroup *cgrp, char *buf,
int buflen)
return 0;
}
- start = dentry_path_raw(dentry, buf, buflen);
- if (IS_ERR(start))
- return PTR_ERR(start);
+ start = buf + buflen - 1;
+ *start = '\0';
+ for (;;) {
+ int len = dentry->d_name.len;
+
+ if ((start -= len) < buf)
+ return -ENAMETOOLONG;
+ memcpy(start, dentry->d_name.name, len);
+ cgrp = cgrp->parent;
+ if (!cgrp)
+ break;
+
+ dentry = cgrp->dentry;
+ if (!cgrp->parent)
+ continue;
+ if (--start < buf)
+ return -ENAMETOOLONG;
+ *start = '/';
+ }
memmove(buf, start, buf + buflen - start);
return 0;
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] of: use platform_device_add
On Fri, Jan 18, 2013 at 01:40:00AM +, Grant Likely wrote:
> This allows platform_device_add a chance to call insert_resource on all
> of the resources from OF. At a minimum this fills in proc/iomem and
> presumably makes resource tracking and conflict detection work better.
> However, it has the side effect of moving all OF generated platform
> devices from /sys/devices to /sys/devices/platform/. It /shouldn't/
> break userspace because userspace is not supposed to depend on the full
> path (because userspace always does what it is supposed to, right?).
>
> This may cause breakage if either:
> 1) any two nodes in a given device tree have overlapping & staggered
>regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained
>within the other). In this case one of the devices will fail to
>register and an exception will be needed in platform_device_add() to
>complain but not fail.
Grant,
The patch introduce a regression on imx6q boot. The IOMUXC block on
imx6q is special. It acts not only a pin controller but also a system
controller with a bunch of system level registers in there. That's why
we currently have the following two nodes in imx6q device tree with the
same start "reg" address, which work with drivers/mfd/syscon.c and
drivers/pinctrl/pinctrl-imx6q.c respectively.
gpr: iomuxc-gpr@020e {
compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
reg = <0x020e 0x38>;
};
iomuxc: iomuxc@020e {
compatible = "fsl,imx6q-iomuxc";
reg = <0x020e 0x4000>;
};
With the patch in place, pinctrl-imx6q fails to register like below.
syscon 20e.iomuxc: syscon regmap start 0x20e end 0x20e3fff registered
imx6q-pinctrl 20e.iomuxc: can't request region for resource [mem
0x020e-0x020e3fff]
imx6q-pinctrl: probe of 20e.iomuxc failed with error -16
Shawn
> 2) any device calls request_mem_region() on a region larger than
>specified in the device tree. In this case the device node may be
>wrong, or the driver is overreaching. In either case I'd like to know
>about any problems and fix them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mfd: syscon: Removed unneeded field "dev" from private driver structure
On 12 February 2013 02:42, Alexander Shiyan wrote:
>
> Signed-off-by: Alexander Shiyan
Acked-by: Dong Aisheng
Regards
Dong Aisheng
> ---
> drivers/mfd/syscon.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index e1886fb..4a7ed5a 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -24,17 +24,15 @@
> static struct platform_driver syscon_driver;
>
> struct syscon {
> - struct device *dev;
> void __iomem *base;
> struct regmap *regmap;
> };
>
> static int syscon_match(struct device *dev, void *data)
> {
> - struct syscon *syscon = dev_get_drvdata(dev);
> struct device_node *dn = data;
>
> - return (syscon->dev->of_node == dn) ? 1 : 0;
> + return (dev->of_node == dn) ? 1 : 0;
> }
>
> struct regmap *syscon_node_to_regmap(struct device_node *np)
> @@ -129,7 +127,6 @@ static int syscon_probe(struct platform_device *pdev)
> return PTR_ERR(syscon->regmap);
> }
>
> - syscon->dev = dev;
> platform_set_drvdata(pdev, syscon);
>
> dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
> --
> 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/
Re: thermal governor: does it actually work??
Hi Boris, Alex, Andreas,
what do you think about this acerhdf patch?
I think it makes things straight and implements the two-point regulation of
acerhdf to be for correctly handled by the thermal layer:
>From 7b39bd8837de6dc5658ac3e54ac5d4df9d351528 Mon Sep 17 00:00:00 2001
From: Peter Feuerer
Date: Sun, 17 Feb 2013 03:29:19 +0100
Subject: [PATCH] added two more trip points to acerhdf, this allows thermal
layer to correctly handle the two point regulation of acerhdf. Trip point 0
will be active from 0 degree to "fanoff" and is marked as passive, then trip
point 1 is valid from "fanoff" to "fanon" value and is marked as active,
even if it's only really active in case temperature is going down from trip
point 2. Trip point 2 will be valid above "fanon" value and is also marked
as active.
---
drivers/platform/x86/acerhdf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f94467c..c36633b 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -400,6 +400,10 @@ static int acerhdf_get_trip_type(struct
thermal_zone_device *thermal, int trip,
enum thermal_trip_type *type)
{
if (trip == 0)
+ *type = THERMAL_TRIP_PASSIVE;
+ if (trip == 1)
+ *type = THERMAL_TRIP_ACTIVE;
+ if (trip == 2)
*type = THERMAL_TRIP_ACTIVE;
return 0;
@@ -409,6 +413,10 @@ static int acerhdf_get_trip_temp(struct
thermal_zone_device *thermal, int trip,
unsigned long *temp)
{
if (trip == 0)
+ *temp = 0;
+ if (trip == 1)
+ *temp = fanoff;
+ if (trip == 2)
*temp = fanon;
return 0;
@@ -486,7 +494,8 @@ static int acerhdf_set_cur_state(struct
thermal_cooling_device *cdev,
(cur_temp < fanoff))
acerhdf_change_fanstate(ACERHDF_FAN_OFF);
} else {
- if (cur_state == ACERHDF_FAN_OFF)
+ if ((cur_state == ACERHDF_FAN_OFF) &&
+ (cur_temp > fanon))
acerhdf_change_fanstate(ACERHDF_FAN_AUTO);
}
return 0;
@@ -661,8 +670,8 @@ static int acerhdf_register_thermal(void)
if (IS_ERR(cl_dev))
return -EINVAL;
- thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
- &acerhdf_dev_ops, NULL, 0,
+ thz_dev = thermal_zone_device_register("acerhdf", 3, 0, NULL,
+ &acerhdf_dev_ops, (kernelmode) ?
interval*1000 : 0,
(kernelmode) ? interval*1000 : 0);
if (IS_ERR(thz_dev))
return -EINVAL;
--
1.8.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] mfd: syscon: Removed support for unloading
On 12 February 2013 02:42, Alexander Shiyan wrote:
> The driver can be used in various subsystems and therefore should not
> be unloaded when it is defined in the kernel configuration, so remove
> support for unloading it.
>
> Signed-off-by: Alexander Shiyan
Acked-by: Dong Aisheng
Regards
Dong Aisheng
> ---
> drivers/mfd/syscon.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 3f10591..e1886fb 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -138,17 +138,6 @@ static int syscon_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int syscon_remove(struct platform_device *pdev)
> -{
> - struct syscon *syscon;
> -
> - syscon = platform_get_drvdata(pdev);
> - iounmap(syscon->base);
> - platform_set_drvdata(pdev, NULL);
> -
> - return 0;
> -}
> -
> static struct platform_driver syscon_driver = {
> .driver = {
> .name = "syscon",
> @@ -156,7 +145,6 @@ static struct platform_driver syscon_driver = {
> .of_match_table = of_syscon_match,
> },
> .probe = syscon_probe,
> - .remove = syscon_remove,
> };
>
> static int __init syscon_init(void)
> @@ -165,12 +153,6 @@ static int __init syscon_init(void)
> }
> postcore_initcall(syscon_init);
>
> -static void __exit syscon_exit(void)
> -{
> - platform_driver_unregister(&syscon_driver);
> -}
> -module_exit(syscon_exit);
> -
> MODULE_AUTHOR("Dong Aisheng ");
> MODULE_DESCRIPTION("System Control driver");
> MODULE_LICENSE("GPL v2");
> --
> 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/
Re: Re[4]: [PATCH] mfd: syscon: Added support for using platform driver resources
Hi Alexander,
On 7 February 2013 23:52, Alexander Shiyan wrote:
> Hello.
>
>> > ...
>> >> Thanks for the patch adding non-dt support. :-)
>> >>
>> >> On Mon, Feb 04, 2013 at 07:00:40PM +0400, Alexander Shiyan wrote:
>> >> > This patch adds support usage platform driver resources, i.e.
>> >> > possibility works without oftree support. Additionally patch
>> >> > removes CONFIG_OF dependency and adds helper for accessing
>> >> > regmap by searching device by its name.
>> > ...
>> >> > +static int syscon_match_name(struct device *dev, void *data)
>> >> > +{
>> >> > + return !strcmp(dev_name(dev), (const char *)data);
>> >> > +}
>> >> > +
>> >> > +struct regmap *syscon_regmap_lookup_by_name(const char *name)
>> >> > +{
>> >> > + struct syscon *syscon;
>> >> > + struct device *dev;
>> >> > +
>> >> > + dev = driver_find_device(&syscon_driver.driver, NULL, (void *)name,
>> >> > +syscon_match_name);
>> >> > + if (!dev)
>> >> > + return ERR_PTR(-EPROBE_DEFER);
>> >> > +
>> >> > + syscon = dev_get_drvdata(dev);
>> >> > +
>> >> > + return syscon->regmap;
>> >> > +}
>> >> > +
>> >>
>> >> How about syscon_dev_to_regmap(struct device *dev) as the exist dt version
>> >> syscon_node_to_regmap since it's not affected by the name change of
>> >> devices?
>> >
>> > I am not completely understand what you mean. In my version which doing
>> > search regmap by name, we can call this function with desired device name,
>> > then use regmap:
>> > struct regmap *r = syscon_regmap_lookup_by_name("syscon.1");
>> >
>>
>> My concern is that this API may be used by other client drivers, if we
>> hardcode
>> the device name in those drivers, once the device name is changed,
>> all those drivers need change too.
>> For dt case, we use device node to find regmap, so does not care about the
>> name.
>>
>> > You suggest use "struct device" as parameter?
>>
>> A device pointer.
>>
>> > I do not know what we should
>> > use as parameter to the function in this case, since we can get "struct
>> > device"
>> > only when register this device,
>>
>> If we have a platform_device, then we have its device pointer, right?
>>
>> > i.e. in board support code, not from anywhere,
>> > for example from another driver.
>> > Fixme please.
>> >
>>
>> My understanding is that in board support code, we can have the
>> platform device instance
>> of that syscon compatible device, then we can use it as the platform
>> data parameter for those devices driver who wants to use it.
>> Then in client driver, it can call:
>> syscon_dev_to_regmap(syscon_compatible_dev)
>> to find the regmap.
>> Just like dt working way, the device node usually uses a phandle pointing to
>> the syscon compatible node which it wants to use.
>
> This is not as easy as it seems.
> All devices that will use "syscon" driver, in this case should have a
> platform_data
> record.
Yes, that's the same way as the dt version does.
> I think that it can create problems with using these drivers as modules.
What problems do you think?
> Alternatively, we can create additional (virtual) "compatible" text property
> in syscon
> private data structure and use it to find the proper device. What is your
> opinion?
>
Hmm, i can't see why we need that.
IMO, for non-dt, we can just use platform_device_id to match devices.
>> > ...
>> >> > + if (IS_ENABLED(CONFIG_OF) && np) {
>> >> > + syscon->base = of_iomap(np, 0);
>> >> > + if (!syscon->base)
>> >> > + return -EADDRNOTAVAIL;
>> >> > +
>> >> > + res = &res_of;
>> >> > + ret = of_address_to_resource(np, 0, res);
>> >> > + if (ret)
>> >> > + return ret;
>> >> > + } else {
>> >> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> >> > + if (!res)
>> >> > + return -ENXIO;
>> >> > +
>> >> > + if (!request_mem_region(res->start, resource_size(res),
>> >> > + dev_name(&pdev->dev)))
>> >> > + return -EBUSY;
>> >> > +
>> >> > + syscon->base = ioremap(res->start, resource_size(res));
>> >> > + if (!syscon->base)
>> >> > + return -EADDRNOTAVAIL;
>> >>
>> >> devm_request_and_ioremap?
>> >
>> > We call of_iomap for DT-version, for removal procedure - iounmap.
>> > Will iounmap work properly with devm_-version, I'm not sure.
>>
>> You're right, i'm afraid not.
>> If that, i wonder the ioremap resource may be freed twice for driver removal.
>> So, i'm okay with your current way.
>> But one issue is that then we need take care of the resource free by
>> ourselves
>> for probe failed cases. e.g. ioremap and request_mem_region.
>> You may need add them.
>
> Yes, thanks. I forget about it.
>
>> > May be better to completely remove ".remove" (and module_exit) feature for
>> > driver?
>> > It is loaded at startup always once compiled, and should always be in the
>> > system.
>>
Re: [PATCH 1/2] dmi_scan: Fix missing check for _DMI_ signature in smbios_present()
- b...@decadent.org.uk wrote：
> Commit 9f9c9cbb6057 ('drivers/firmware/dmi_scan.c: fetch dmi version
> from SMBIOS if it exists') hoisted the check for "_DMI_" into
> dmi_scan_machine(), which means that we don't bother to check for
> "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also
> call dmi_present() for an address where we found "_SM_", if it failed
> further validation.
>
> Check for "_DMI_" in smbios_present() before calling dmi_present().
>
> Reported-by: Tim McGrath
> Signed-off-by: Ben Hutchings
> Cc: stable
> ---
> This has a memcmp() that wasn't in the previous version, so I've not
> included the Acked-by or Tested-by for that.
Yes, the further "_DMI_" check is needed.
Acked-by: Zhenzhong Duan
>
> Ben.
>
> drivers/firmware/dmi_scan.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/dmi_scan.c
> b/drivers/firmware/dmi_scan.c
> index 982f1f5..a86ccff 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -442,7 +442,6 @@ static int __init dmi_present(const char __iomem
> *p)
> static int __init smbios_present(const char __iomem *p)
> {
> u8 buf[32];
> - int offset = 0;
>
> memcpy_fromio(buf, p, 32);
> if ((buf[5] < 32) && dmi_checksum(buf, buf[5])) {
> @@ -461,9 +460,9 @@ static int __init smbios_present(const char
> __iomem *p)
> dmi_ver = 0x0206;
> break;
> }
> - offset = 16;
> + return memcmp(q + 16, "_DMI_", 5) || dmi_present(p + 16);
> }
> - return dmi_present(buf + offset);
> + return 1;
> }
>
> void __init dmi_scan_machine(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 vmalloc_fault oops during lazy MMU updates.
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.
One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:
- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries
Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.
Signed-off-by: Samu Kallio
---
arch/x86/mm/fault.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 8e13ecb..0a45298 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long
address)
if (pgd_none(*pgd_ref))
return -1;
- if (pgd_none(*pgd))
+ if (pgd_none(*pgd)) {
set_pgd(pgd, *pgd_ref);
- else
+ arch_flush_lazy_mmu_mode();
+ } else {
BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+ }
/*
* Below here mismatches are bugs because these lower tables
--
1.8.1.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: Debugging Thinkpad T430s occasional suspend failure.
On Sat, 16 Feb 2013, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >
> > I think it's worth it to give them a heads-up already. So I've cc'd
> > the main suspects here..
>
> Okay, thanks.
>
> >
> > Daniel, Dave - any comments about a NULL fb in
> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> > googling shows this:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>
> Great, yes, I'm sure that's the same (though it says "suspend"
> and I say "resume").
>
> >
> > which sounds remarkably similar, and is also during a suspend attempt
> > (but apparently Satish got a full oops out).. Some timing race with a
> > worker entry?
Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
on lid open", whose force_restore case now passes down crtc->base.fb. But
I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
your timing race with a worker entry, perhaps.
And 45e2b5f640b3 contains a fine history of going back and forth, so I
wouldn't want to play further with it out of ignorance - though tempted
to replace the "if (force_restore) {" by an interim safe-seeming
compromise of "if (force_restore && crtc->base.fb) {".
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] m68k/nommu: fix build when CPU is not coldfire
Commit dd1cb3a7c43508c29e17836628090c0735bd3137 unified mm/init.c for both MMU
and non-MMU m68k platforms. However, it broke when we build a non-MMU M68K
Classic CPU kernel.
This fix builds a section that came from the MMU version only when we are
building a MMU kernel.
Signed-off-by: Thadeu Lima de Souza Cascardo
---
arch/m68k/mm/init.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index afd8106f..519aad8 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -188,7 +188,7 @@ void __init mem_init(void)
}
}
-#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
+#if defined(CONFIG_MMU) && !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
/* insert pointer tables allocated so far into the tablelist */
init_pointer_table((unsigned long)kernel_pg_dir);
for (i = 0; i < PTRS_PER_PGD; i++) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH 3/3] regulator: max8649: Use enable_is_inverted flag with regulator_enable_regmap and friends APIs
On Sat, Feb 16, 2013 at 2:38 PM, Axel Lin wrote: > Signed-off-by: Axel Lin > --- > drivers/regulator/max8649.c | 39 ++- > 1 file changed, 6 insertions(+), 33 deletions(-) > Reviewed-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH 2/3] regulator: 88pm8607: Use enable_is_inverted flag with regulator_enable_regmap and friends APIs
On Sat, Feb 16, 2013 at 2:37 PM, Axel Lin wrote: > Signed-off-by: Axel Lin > --- > drivers/regulator/88pm8607.c | 36 > 1 file changed, 4 insertions(+), 32 deletions(-) > Reviewed-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH 1/3] regulator: core: Add enable_is_inverted flag to indicate set enable_mask bits to disable
On Sat, Feb 16, 2013 at 2:36 PM, Axel Lin wrote:
> Add enable_is_inverted flag to indicate set enable_mask bits to disable
> when using regulator_enable_regmap and friends APIs.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/core.c | 24
> include/linux/regulator/driver.h |3 +++
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index da9782b..142205b 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1794,7 +1794,10 @@ int regulator_is_enabled_regmap(struct regulator_dev
> *rdev)
> if (ret != 0)
> return ret;
>
> - return (val & rdev->desc->enable_mask) != 0;
> + if (rdev->desc->enable_is_inverted)
> + return (val & rdev->desc->enable_mask) == 0;
> + else
> + return (val & rdev->desc->enable_mask) != 0;
> }
> EXPORT_SYMBOL_GPL(regulator_is_enabled_regmap);
>
> @@ -1809,9 +1812,15 @@ EXPORT_SYMBOL_GPL(regulator_is_enabled_regmap);
> */
> int regulator_enable_regmap(struct regulator_dev *rdev)
> {
> + unsigned int val;
> +
> + if (rdev->desc->enable_is_inverted)
> + val = 0;
> + else
> + val = rdev->desc->enable_mask;
> +
> return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
> - rdev->desc->enable_mask,
> - rdev->desc->enable_mask);
> + rdev->desc->enable_mask, val);
> }
> EXPORT_SYMBOL_GPL(regulator_enable_regmap);
>
> @@ -1826,8 +1835,15 @@ EXPORT_SYMBOL_GPL(regulator_enable_regmap);
> */
> int regulator_disable_regmap(struct regulator_dev *rdev)
> {
> + unsigned int val;
> +
> + if (rdev->desc->enable_is_inverted)
> + val = rdev->desc->enable_mask;
> + else
> + val = 0;
> +
> return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
> - rdev->desc->enable_mask, 0);
> + rdev->desc->enable_mask, val);
> }
> EXPORT_SYMBOL_GPL(regulator_disable_regmap);
>
> diff --git a/include/linux/regulator/driver.h
> b/include/linux/regulator/driver.h
> index 23070fd..074b57e 100644
> --- a/include/linux/regulator/driver.h
> +++ b/include/linux/regulator/driver.h
> @@ -199,6 +199,8 @@ enum regulator_type {
> *output when using regulator_set_voltage_sel_regmap
> * @enable_reg: Register for control when using regmap enable/disable ops
> * @enable_mask: Mask for control when using regmap enable/disable ops
> + * @enable_is_inverted: A flag to indicate set enable_mask bits to disable
> + * when using regulator_enable_regmap and friends APIs.
> *
> * @enable_time: Time taken for initial enable of regulator (in uS).
> */
> @@ -226,6 +228,7 @@ struct regulator_desc {
> unsigned int apply_bit;
> unsigned int enable_reg;
> unsigned int enable_mask;
> + bool enable_is_inverted;
> unsigned int bypass_reg;
> unsigned int bypass_mask;
>
> --
> 1.7.9.5
>
>
>
Reviewed-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ia64: rename cache_show to topology_cache_show
On Sat, Feb 16, 2013 at 01:18:53PM +0100, Michal Hocko wrote: > On Fri 15-02-13 14:46:29, Andrew Morton wrote: > > On Fri, 15 Feb 2013 13:38:24 +0100 > > Michal Hocko wrote: > > > > > Fenguang Wu has reported the following compile time issue > > > arch/ia64/kernel/topology.c:278:16: error: conflicting types for > > > 'cache_show' > > > include/linux/slab.h:224:5: note: previous declaration of 'cache_show' > > > was here > > > > > > which has been introduced by 749c5415 (memcg: aggregate memcg cache > > > values in slabinfo). Let's rename ia64 local function to prevent from > > > the name conflict. > > > > Confused. Tony fixed this ages ago? > > Yes but it was after 3.7 so I didn't have it in my tree and I found out > only after I sent this email. Sorry about the confusion. Michal, sorry about the confusions. Does this indicate anything improveable in the build test/notification? Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: dove: convert serial DT nodes to clocks property
On Tue, Jan 29, 2013 at 09:59:46PM +0100, Sebastian Hesselbarth wrote: > of_serial now has support for using clocks property and we have > a DT clock provider. This patch replaces the hard coded clock-frequency > property with a clocks phandle to tclk. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Russell King > Cc: Sebastian Hesselbarth > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Thomas Petazzoni > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/dove.dtsi |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Applied to mvebu/dt thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform
On Tue, Jan 22, 2013 at 10:10:25PM +0100, Gregory CLEMENT wrote: > The Globalscale Mirabox platform can be connected to the JTAG/GPIO box > through the Multi-IO port. The GPIO box use the NXP PCA9505 I/O port > expansion IC to provide 40-bit parallel input/output GPIOs. This patch > enable the use of this expander on the Mirabox. > > Signed-off-by: Gregory CLEMENT > Acked-by: Linus Walleij > --- > arch/arm/boot/dts/armada-370-mirabox.dts | 10 ++ > 1 file changed, 10 insertions(+) Applied to mvebu/dt_deps with a dependency on gpio/for-next for: 89f5df0 gpio: pca953x: add support for pca9505 f5f0b7a gpio: pca953x: make the register access by GPIO bank thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/11] ARM: samsung: fix assembly syntax for new gas
Hi, On Thu, Feb 14, 2013 at 02:49:18PM +0100, Arnd Bergmann wrote: > Recent assembler versions complain about extraneous > whitespace inside [] brackets. This fixes all of > these instances for the samsung platforms. We should > backport this to all kernels that might need to > be built with new binutils. Which binutils version is this? A. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: tsc2005: Add MODULE_ALIAS
* This patch enable autoloading tsc2005 driver when is compiled as module
Signed-off-by: Pali Rohár
---
drivers/input/touchscreen/tsc2005.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 9c0cdc7..7213e8b 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -753,3 +753,4 @@ module_spi_driver(tsc2005_driver);
MODULE_AUTHOR("Lauri Leukkunen ");
MODULE_DESCRIPTION("TSC2005 Touchscreen Driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:tsc2005");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 0/4] 3.0.65-stable review
On Sat, Feb 16, 2013 at 03:08:38PM -0700, Shuah Khan wrote: > On Fri, Feb 15, 2013 at 3:55 PM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 3.0.65 release. > > There are 4 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Feb 17 22:53:56 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.65-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > - > > Patches applied cleanly to 3.0.64, 3.4.31, and 3.7.8. > Compiled and booted on the following systems: > HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz > HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Thanks for testing all of these and letting us know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7 HDMI channel map regression
On Mon, Jan 28, 2013 at 08:52:05PM -0600, Shawn Bohrer wrote: > On Mon, Jan 28, 2013 at 09:56:33AM +0100, Takashi Iwai wrote: > > At Sun, 27 Jan 2013 19:18:27 -0600, > > Shawn Bohrer wrote: > > > > > > Hi Takashi, > > > > > > I recently updated my HTPC from 3.6.11 to 3.7.2 and this caused my RL > > > and FC channels to swap, and my RR and LFE channels to swap for PCM > > > audio. Doing a git bisect identified > > > d45e6889ee69456a4d5b1bbb32252f460cd48fa9 "ALSA: hda - Provide the > > > proper channel mapping for generic HDMI driver" as the commit that > > > caused my channels to swap. The commit doesn't revert cleanly on > > > 3.7.4, and I haven't really looked to see what the correct fix might > > > be. > > > > > > Some info that may be relevant, the sound card is a: > > > > > > 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset > > > Family High Definition Audio Controller (rev 04) > > > > > > The machine is running Fedora 18 and audio goes over HDMI to a 5.1 > > > receiver. I'm not really sure what other info you might need, but > > > let me know if you need something else or have any patches you would > > > like me to test. > > > > OK, it's the first time to get a bug report about this. > > Could you tell me how did you test it (i.e. which application, which > > sound backend)? Can you confirm that it's reproduced via speaker-test > > program in alsa-utils package? > > I originally noticed the problem when all of the dialog started coming > out of my rear left speaker in MythTV after the kernel update. Then I > started using the Gnome 3 sound configuration gui in the system > settings which has a speaker test and I assume is using pulseaudio. > Running 'speaker-test -c6 -l1 -twav' also reproduces the problem. > > For reference here are the versions of the various packages that I'm > running: > > alsa-utils-1.0.26-1.fc18.x86_64 > alsa-firmware-1.0.25-2.fc18.noarch > alsa-plugins-pulseaudio-1.0.26-2.fc18.x86_64 > alsa-lib-devel-1.0.26-2.fc18.x86_64 > alsa-lib-1.0.26-2.fc18.x86_64 > alsa-tools-firmware-1.0.26.1-1.fc18.x86_64 > pulseaudio-gdm-hooks-2.1-5.fc18.x86_64 > pulseaudio-libs-2.1-5.fc18.x86_64 > pulseaudio-libs-glib2-2.1-5.fc18.x86_64 > pulseaudio-module-x11-2.1-5.fc18.x86_64 > pulseaudio-module-bluetooth-2.1-5.fc18.x86_64 > pulseaudio-2.1-5.fc18.x86_64 > pulseaudio-utils-2.1-5.fc18.x86_64 Hi Takashi, Any updates on this issue? I'd really like to see this issue fixed and am happy to help in any way I can. Until this gets fixed I'm stuck on a 3.6.* kernel. Thanks, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Debugging Thinkpad T430s occasional suspend failure.
On Sat, 16 Feb 2013, Linus Torvalds wrote:
> On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
> >
> > I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> > yesterday, to save an oopsing core kernel ip there, instead of hashed
> > pm trace info (it makes sense in this case to invert your sequence,
> > putting the high order into years and the low order into minutes).
>
> That sounds like a good idea in general. The PM_TRACE() thing was done
> to figure out things that locked up the PCI bus etc, but encoding the
> oopses during suspend sounds like a really good idea too.
Yes, it can and should be generalized, but needs more than I gave it.
>
> Is your patch clean enough to just be made part of the standard
> PM_TRACE infrastructure, or was it something really hacky and one-off?
Not really hacky, but three reasons why it cannot be standard without
more work (I am supposing that it should not be tied to suspend/resume,
but could be used for any oops which gets hidden by graphic screen,
and also fails to reach /var/log/messages).
1. Because I usually have a version of KDB patched into my kernels
("forked" many years ago, never time to integrate with that subset
which eventually went into 2.6.??), it was easiest to implement as
a pair of KDB commands (needing keyboard input: I already knew I
could "reboot" from KDB in this state). (Sidenote: using KDB can
prevent getting a trace into /var/log/messages: so I had tried
without it, but still failed to get one.)
2. I don't use initrd, have very little in modules, and a pared down
kernel: so for me it was not a serious restriction to limit to core
kernel addresses, which easily fitted within the limit; but we ought
to put thought into handling module addresses too.
3. Needs care on the interface: a debug config option presumably,
but perhaps also needs to tie in with panic_on_oops or something -
I don't like my date getting messed up by surprise, and there's no
point in messing it up unless there's reason to believe the machine
will very quickly be rebooted. Since I had to open the lid to resume
to hit the oops, in this case we could rely on me quickly rebooting.
But I've appended what I had below, so it's on the record, and can
be taken further if (likely) someone gets there sooner than I do.
>
> > Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
> > 812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
> >
> > /home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
> > * enable dithering as needed, but that costs bandwidth. So choose
> > * the minimum value that expresses the full color range of the fb
> > but
> > * also stays within the max display bpc discovered above.
> > */
> >
> > switch (fb->depth) {
> > 812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
> > 812d60ed: 8b 02 mov(%rdx),%eax
> >
> > (gcc chose to pass a pointer to fb->depth down to the function,
> > instead of fb itself, since that is the only use of it there.)
> >
> > I expect that fb is NULL; but with an average of one failure to resume
> > per day, and ~26 bits of info per crash, this is not a fast procedure!
> >
> > I notice that intel_pipe_set_base() allows for NULL fb,
> > so I'm currently running with the oops-in-rtc hackery, plus
> > - switch (fb->depth) {
> > + if (WARN_ON(!fb))
> > + bpc = 8;
> > + else switch (fb->depth) {
> >
> > There's been a fair bit of change to intel_display.c since 3.7 (if
> > my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
> > ironlake_, but I've not yet spotted anything obvious; nor yet looked
> > to see where fb would originate from anyway.
> >
> > Once I've got just a little more info out of it, I'll start another
> > thread addressed principally to the drm/gpu/i915 guys.
>
> I think it's worth it to give them a heads-up already. So I've cc'd
> the main suspects here..
Okay, thanks.
>
> Daniel, Dave - any comments about a NULL fb in
> intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> googling shows this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=895123
Great, yes, I'm sure that's the same (though it says "suspend"
and I say "resume").
>
> which sounds remarkably similar, and is also during a suspend attempt
> (but apparently Satish got a full oops out).. Some timing race with a
> worker entry?
>
> Linus
#include
#include
/*
* HughD adapted the following from drivers/base/power/trace.c:
*
* Copyright (C) 2006 Linus Torvalds
*
* Trace facility for suspend/resume problems, when none of the
* devices may be working.
*
* Horrid, horrid, horrid.
*
* It turns out that the _only_ piece of hardware that actually
* keeps its value across a hard boot (and, more importantly, the
* POST init sequence) is literally the realtime clock.
*
* Never mind that an RTC chip has
[PATCH] watchdog: omap_wdt: Add option nowayout
Like other watchdog drivers, this patch adds new option nowayout
which overwrite WATCHDOG_NOWAYOUT.
---
drivers/watchdog/omap_wdt.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index b0e541d..af88ffd 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -45,6 +45,11 @@
#include "omap_wdt.h"
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+ "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
@@ -201,7 +206,6 @@ static const struct watchdog_ops omap_wdt_ops = {
static int omap_wdt_probe(struct platform_device *pdev)
{
struct omap_wd_timer_platform_data *pdata = pdev->dev.platform_data;
- bool nowayout = WATCHDOG_NOWAYOUT;
struct watchdog_device *omap_wdt;
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Driver lis3lv02d_i2c not working on Nokia RX-51
Hello, Accelerometer driver lis3lv02d_i2c not working on Nokia RX-51 with linux kernel 3.8-rc3. Probing for i2c device failing. I tried to compile older version and it working without problem. Then I bisected commit which broke support for RX-51. That commit is ec400c9fab99d16a491cea17d27d0c6a5780b97c "lis3lv02d: make regulator API usage unconditional" CCing everybody who signed off that commit. When I reverted that commit on top of 3.8-rc3, lis3lv02d working without problem. It looks like driver is trying to use some regulator, but there is nothing defined for RX-51. Any idea what to do? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCHv3 2/4] dmaengine: dw_dmac: move to generic DMA binding
On Saturday 16 February 2013, Andy Shevchenko wrote:
> > @@ -1836,6 +1825,12 @@ static int dw_probe(struct platform_device *pdev)
> >
> > dma_async_device_register(&dw->dma);
> >
> > + if (pdev->dev.of_node)
> > + err = of_dma_controller_register(pdev->dev.of_node,
> > +dw_dma_xlate, dw);
> > + if (err && err != -ENODEV)
> > + dev_err(&pdev->dev, "could not register
> > of_dma_controller\n");
>
> I believe we may make it as
> if (...of_node) {
> err = ...register();
> if (err...)
> dev_err();
> }
I thing the two are equivalent because we only get to the first if()
when err is 0. However, I agree that your version is a bit clearer,
so I'll change it.
> > --- a/drivers/dma/dw_dmac_regs.h
> > +++ b/drivers/dma/dw_dmac_regs.h
>
> > @@ -211,9 +212,15 @@ struct dw_dma_chan {
> > /* hardware configuration */
> > unsigned intblock_size;
> > boolnollp;
> > + unsigned intrequest_line;
> > + struct dw_dma_slave slave;
> > +
>
> Do we really need an extra empty line here?
No, that was an accident.
> > /* configuration passed via DMA_SLAVE_CONFIG */
> > struct dma_slave_config dma_sconfig;
> > +
> > + /* backlink to dw_dma */
> > + struct dw_dma *dw;
>
> Seems it's not needed and came from rebase?
Probably. It certainly was not intentional.
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: [PATCH 02/11] ARM: samsung: fix assembly syntax for new gas
On Thu, Feb 14, 2013 at 02:49:18PM +0100, Arnd Bergmann wrote: > Recent assembler versions complain about extraneous > whitespace inside [] brackets. This fixes all of > these instances for the samsung platforms. We should > backport this to all kernels that might need to > be built with new binutils. I hope that's also been reported as a bug to the binutils people. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 2/4] dmaengine: dw_dmac: move to generic DMA binding
The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of the slave-dma tree, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
This version incorporates feedback from Viresh Kumar, Andy Shevchenko
and Russell King.
Signed-off-by: Arnd Bergmann
Acked-by: Viresh Kumar
Acked-by: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 +-
drivers/dma/dw_dmac.c | 145 ++---
drivers/dma/dw_dmac_regs.h | 7 +-
include/linux/dw_dmac.h| 5 -
4 files changed, 111 insertions(+), 116 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..d58675e 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,59 +3,61 @@
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
- that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by
the
- general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported, up to 16
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be <3>
- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
-- nr_masters: Number of AHB masters supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-- slave_info:
- - bus_id: name of this device channel, not just a device name since
- devices may have more than one channel e.g. "foo_tx". For using the
- dw_generic_filter(), slave drivers must pass exactly this string as
- param to filter function.
- - cfg_hi: Platform-specific initializer for the CFG_HI register
- - cfg_lo: Platform-specific initializer for the CFG_LO register
- - src_master: src master for transfers on allocated channel.
- - dst_master: dest master for transfers on allocated channel.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma@fc00 {
+ dmahost: dma@fc00 {
compatible = "snps,dma-spear1340";
reg = <0xfc00 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
- nr_channels = <8>;
+ dma-channels = <8>;
+ dma-requests = <16>;
+ dma-masters = <2>;
+ #dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
- nr_masters = <2>;
data_width = <3 3 0 0>;
+ };
- slave_info {
- uart0-tx {
- bus_id = "uart0-tx";
- cfg_hi = <0x4000>; /* 0x8 << 11 */
- cfg_lo = <0>;
- src_master = <0>;
- dst_master = <1>;
- };
- spi0-tx {
- bus_id = "spi0-tx";
- cfg_hi = <0x2000>; /* 0x4 << 11 */
- cfg_lo = <0>;
- src_master = <0>;
- dst_master = <0>;
- };
- };
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a four-cell specifier for each channel.
+The four cel
Re: [PATCH 01/11] ARM: disable virt_to_bus/virt_to_bus almost everywhere
On Saturday 16 February 2013, Emilio López wrote: > Small nitpick: Please have a look at the patch subject, I suppose you > meant something like "virt_to_bus/bus_to_virt" instead of > "virt_to_bus/virt_to_bus". Yes, absolutely right, thanks for your attention. The patch is already applied to a stable branch now, so I would prefer not to rebase it though. If there is an important reason to change the applied patches, I will fix this one as well. 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: [RFC 1/3] power_supply: Define Binding for supplied-nodes
On Fri, Feb 15, 2013 at 06:36:54PM -0500, Rhyland Klein wrote:
> This property is meant to be used in device nodes which represent
> power_supply devices that wish to provide a list of supplies to
> which they provide power. A common case is a AC Charger with
> the batteries it powers.
>
> Signed-off-by: Rhyland Klein
> ---
> .../bindings/power_supply/power_supply.txt | 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/power_supply/power_supply.txt
>
> diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt
> b/Documentation/devicetree/bindings/power_supply/power_supply.txt
> new file mode 100644
> index 000..1c58d4ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/power_supply.txt
> @@ -0,0 +1,17 @@
> +Power Supply Core Support
> +
> +Optional Properties:
> + - power-supply,supplied-nodes : This property is added to a supply
> + in order to specify the list of supplicant devices directly by their
> + phandles.
"supplied nodes" sounds confusing (doesn't reflect direction), IMO. I'd
rather call it power-supply,supplied-to = <&some_battery>;
But... I'm recalling there was a similar discussion not that long ago, and
Arnd came up with the idea that supplied-to is not fully in spirit of DT,
and proposed his view of proper bindings. Please find the discussion here:
http://lkml.org/lkml/2012/9/14/104
Thanks,
Anton
> +
> +Example:
> +
> + charger@e {
> + compatible = "some,charger";
> + ...
> +
> + power-supply,supplied-nodes = <&some_battery>,
> + <&another_battery>;
> + ...
> + };
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARM: sa1100: collie-battery.c: include platform_device.h directly
Hi Andrea, On Sat, Feb 16, 2013 at 07:16:00PM +0100, Andrea Adami wrote: > Initial try to fix compilation error Things are a bit more complex... > linux/include/linux/mfd/mcp.h:22:16: error: field 'attached_device' has > incomplete type You have to add #include into mfd/mcp.h. This will add struct device and... > linux/include/linux/mfd/mcp.h:48:23: error: field 'drv' has incomplete type struct device_driver. > linux/include/linux/mfd/ucb1x00.h:137:17: error: field 'dev' has incomplete > type Same here, the file ucb1x00.h needs #include . > linux/drivers/power/collie_battery.c:290:56: error: unknown type name > 'pm_message_t' #include into collie_battery.c Thanks, Anton > linux/drivers/power/collie_battery.c:371:13: error: 'collie_bat_suspend' > undeclared here (not in a function) > | make[4]: *** [drivers/power/collie_battery.o] Error 1 > | make[3]: *** [drivers/power] Error 2 > > As seen in Arnd Bergmann patches on LAKML > [PATCH 7/9] ARM defconfigs: add missing inclusions of linux/platform_device.h > [PATCH 1/9] ARM: sa1100/assabet: include platform_device.h directly > > Compilation is still not clean, two warnings: > linux/drivers/power/collie_battery.c:372:2: warning: initialization from > incompatible pointer type [enabled by default] > linux/drivers/power/collie_battery.c:372:2: warning: (near initialization for > 'collie_bat_driver.suspend') [enabled by default] > > Signed-off-by: Andrea Adami > --- > drivers/power/collie_battery.c| 1 + > drivers/video/logo/logo_linux_clut224.ppm | 232006 > ++- > 2 files changed, 230404 insertions(+), 1603 deletions(-) > > diff --git a/drivers/power/collie_battery.c b/drivers/power/collie_battery.c > index c58d0e3..52cbab3 100644 > --- a/drivers/power/collie_battery.c > +++ b/drivers/power/collie_battery.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include I don't see anywhere in the driver which would need platform_device.h... But pm.h, yes. > #include > #include > #include > -- > 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/
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
>
> I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> yesterday, to save an oopsing core kernel ip there, instead of hashed
> pm trace info (it makes sense in this case to invert your sequence,
> putting the high order into years and the low order into minutes).
That sounds like a good idea in general. The PM_TRACE() thing was done
to figure out things that locked up the PCI bus etc, but encoding the
oopses during suspend sounds like a really good idea too.
Is your patch clean enough to just be made part of the standard
PM_TRACE infrastructure, or was it something really hacky and one-off?
> Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
> 812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
>
> /home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
> * enable dithering as needed, but that costs bandwidth. So choose
> * the minimum value that expresses the full color range of the fb but
> * also stays within the max display bpc discovered above.
> */
>
> switch (fb->depth) {
> 812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
> 812d60ed: 8b 02 mov(%rdx),%eax
>
> (gcc chose to pass a pointer to fb->depth down to the function,
> instead of fb itself, since that is the only use of it there.)
>
> I expect that fb is NULL; but with an average of one failure to resume
> per day, and ~26 bits of info per crash, this is not a fast procedure!
>
> I notice that intel_pipe_set_base() allows for NULL fb,
> so I'm currently running with the oops-in-rtc hackery, plus
> - switch (fb->depth) {
> + if (WARN_ON(!fb))
> + bpc = 8;
> + else switch (fb->depth) {
>
> There's been a fair bit of change to intel_display.c since 3.7 (if
> my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
> ironlake_, but I've not yet spotted anything obvious; nor yet looked
> to see where fb would originate from anyway.
>
> Once I've got just a little more info out of it, I'll start another
> thread addressed principally to the drm/gpu/i915 guys.
I think it's worth it to give them a heads-up already. So I've cc'd
the main suspects here..
Daniel, Dave - any comments about a NULL fb in
intel_choose_pipe_bpp_dither() during either suspend or resume? Some
googling shows this:
https://bugzilla.redhat.com/show_bug.cgi?id=895123
which sounds remarkably similar, and is also during a suspend attempt
(but apparently Satish got a full oops out).. Some timing race with a
worker entry?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/4] dmaengine: dw_dmac: move to generic DMA binding
On Sun, Feb 17, 2013 at 12:21 AM, Arnd Bergmann wrote:
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This is an attempt to replace it with an implementation of the generic
> binding, but it is currently completely untested, because I do not have
> any hardware with this particular controller.
>
> The patch applies on top of the slave-dma tree, which contains both the base
> support for the generic DMA binding, as well as the earlier attempt from
> Viresh. Both of these are currently not merged upstream however.
>
> This version incorporates feedback from Viresh Kumar, Andy Shevchenko
> and Russell King.
Sorry, few comments below.
After addressing them take my Acked-by: Andy Shevchenko
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1836,6 +1825,12 @@ static int dw_probe(struct platform_device *pdev)
>
> dma_async_device_register(&dw->dma);
>
> + if (pdev->dev.of_node)
> + err = of_dma_controller_register(pdev->dev.of_node,
> +dw_dma_xlate, dw);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev, "could not register of_dma_controller\n");
I believe we may make it as
if (...of_node) {
err = ...register();
if (err...)
dev_err();
}
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -211,9 +212,15 @@ struct dw_dma_chan {
> /* hardware configuration */
> unsigned intblock_size;
> boolnollp;
> + unsigned intrequest_line;
> + struct dw_dma_slave slave;
> +
Do we really need an extra empty line here?
>
> /* configuration passed via DMA_SLAVE_CONFIG */
> struct dma_slave_config dma_sconfig;
> +
> + /* backlink to dw_dma */
> + struct dw_dma *dw;
Seems it's not needed and came from rebase?
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: mxser: improve error handling in mxser_probe() and mxser_module_init()
1. Currently mxser_probe() and mxser_module_init() ignore errors
that can happen in tty_port_register_device().
2. mxser_module_init() does not deallocate resources allocated in
mxser_get_ISA_conf()
if mxser_initbrd() failed.
The patch adds proper error handling in all the cases.
Also it moves free_irq() from mxser_release_ISA_res() to mxser_board_remove(),
since it makes mxser_release_ISA_res() a counterpart for mxser_get_ISA_conf(),
while free_irq() is relevant to both ISA and PCI boards.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/tty/mxser.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 4011386..d82294c 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2364,7 +2364,6 @@ static void mxser_release_vector(struct mxser_board *brd)
static void mxser_release_ISA_res(struct mxser_board *brd)
{
- free_irq(brd->irq, brd);
release_region(brd->ports[0].ioaddr, 8 * brd->info->nports);
mxser_release_vector(brd);
}
@@ -2430,6 +2429,7 @@ static void mxser_board_remove(struct mxser_board *brd)
tty_unregister_device(mxvar_sdriver, brd->idx + i);
tty_port_destroy(&brd->ports[i].port);
}
+ free_irq(brd->irq, brd);
}
static int __init mxser_get_ISA_conf(int cap, struct mxser_board *brd)
@@ -2554,6 +2554,7 @@ static int mxser_probe(struct pci_dev *pdev,
struct mxser_board *brd;
unsigned int i, j;
unsigned long ioaddress;
+ struct device *tty_dev;
int retval = -EINVAL;
for (i = 0; i < MXSER_BOARDS; i++)
@@ -2637,13 +2638,25 @@ static int mxser_probe(struct pci_dev *pdev,
if (retval)
goto err_rel3;
- for (i = 0; i < brd->info->nports; i++)
- tty_port_register_device(&brd->ports[i].port, mxvar_sdriver,
- brd->idx + i, &pdev->dev);
+ for (i = 0; i < brd->info->nports; i++) {
+ tty_dev = tty_port_register_device(&brd->ports[i].port,
+ mxvar_sdriver, brd->idx + i, &pdev->dev);
+ if (IS_ERR(tty_dev)) {
+ retval = PTR_ERR(tty_dev);
+ for (i--; i >= 0; i--)
+ tty_unregister_device(mxvar_sdriver,
+ brd->idx + i);
+ goto err_relbrd;
+ }
+ }
pci_set_drvdata(pdev, brd);
return 0;
+err_relbrd:
+ for (i = 0; i < brd->info->nports; i++)
+ tty_port_destroy(&brd->ports[i].port);
+ free_irq(brd->irq, brd);
err_rel3:
pci_release_region(pdev, 3);
err_zero:
@@ -2665,7 +2678,6 @@ static void mxser_remove(struct pci_dev *pdev)
mxser_board_remove(brd);
- free_irq(pdev->irq, brd);
pci_release_region(pdev, 2);
pci_release_region(pdev, 3);
pci_disable_device(pdev);
@@ -2683,6 +2695,7 @@ static struct pci_driver mxser_driver = {
static int __init mxser_module_init(void)
{
struct mxser_board *brd;
+ struct device *tty_dev;
unsigned int b, i, m;
int retval;
@@ -2728,14 +2741,29 @@ static int __init mxser_module_init(void)
/* mxser_initbrd will hook ISR. */
if (mxser_initbrd(brd, NULL) < 0) {
+ mxser_release_ISA_res(brd);
brd->info = NULL;
continue;
}
brd->idx = m * MXSER_PORTS_PER_BOARD;
- for (i = 0; i < brd->info->nports; i++)
- tty_port_register_device(&brd->ports[i].port,
+ for (i = 0; i < brd->info->nports; i++) {
+ tty_dev = tty_port_register_device(&brd->ports[i].port,
mxvar_sdriver, brd->idx + i, NULL);
+ if (IS_ERR(tty_dev)) {
+ for (i--; i >= 0; i--)
+ tty_unregister_device(mxvar_sdriver,
+ brd->idx + i);
+ for (i = 0; i < brd->info->nports; i++)
+ tty_port_destroy(&brd->ports[i].port);
+ free_irq(brd->irq, brd);
+ mxser_release_ISA_res(brd);
+ brd->info = NULL;
+ break;
+ }
+ }
+ if (brd->info == NULL)
+ continue;
m++;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ a
[BONUS PATCH] dmaengine: dw_dmac: simplify master selection
The patch to add the common DMA binding added a dummy dw_dma_slave
structure into the dw_dma_chan structure in order to configure the
masters correctly. It turns out that this can be simplified if we
pick the DMA masters in the dwc_alloc_chan_resources function instead
and save them in the dw_dma_chan structure directly.
This could be simplified further once all users that today use
dw_dma_slave for configuration get converted to device tree based
setup instead.
This is just a proof of concept patch and should not get merged in
3.9, but I hope that Andy and Viresh find it useful and submit it
for 3.10 after testing and refining it.
Signed-off-by: Arnd Bergmann
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/dma/dw_dmac.c | 96 --
drivers/dma/dw_dmac_regs.h | 4 +-
2 files changed, 36 insertions(+), 64 deletions(-)
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 72d6abf..72c6f6d 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -37,40 +37,10 @@
* The driver has currently been tested only with the Atmel AT32AP7000,
* which does not support descriptor writeback.
*/
-
-static inline unsigned int dwc_get_dms(struct dw_dma_slave *slave)
-{
- return slave ? slave->dst_master : 0;
-}
-
-static inline unsigned int dwc_get_sms(struct dw_dma_slave *slave)
-{
- return slave ? slave->src_master : 1;
-}
-
-#define SRC_MASTER 0
-#define DST_MASTER 1
-
-static inline unsigned int dwc_get_master(struct dma_chan *chan, int master)
-{
- struct dw_dma *dw = to_dw_dma(chan->device);
- struct dw_dma_slave *dws = chan->private;
- unsigned int m;
-
- if (master == SRC_MASTER)
- m = dwc_get_sms(dws);
- else
- m = dwc_get_dms(dws);
-
- return min_t(unsigned int, dw->nr_masters - 1, m);
-}
-
#define DWC_DEFAULT_CTLLO(_chan) ({\
struct dw_dma_chan *_dwc = to_dw_dma_chan(_chan); \
struct dma_slave_config *_sconfig = &_dwc->dma_sconfig; \
bool _is_slave = is_slave_direction(_dwc->direction); \
- int _dms = dwc_get_master(_chan, DST_MASTER); \
- int _sms = dwc_get_master(_chan, SRC_MASTER); \
u8 _smsize = _is_slave ? _sconfig->src_maxburst : \
DW_DMA_MSIZE_16;\
u8 _dmsize = _is_slave ? _sconfig->dst_maxburst : \
@@ -80,8 +50,8 @@ static inline unsigned int dwc_get_master(struct dma_chan
*chan, int master)
| DWC_CTLL_SRC_MSIZE(_smsize) \
| DWC_CTLL_LLP_D_EN\
| DWC_CTLL_LLP_S_EN\
-| DWC_CTLL_DMS(_dms) \
-| DWC_CTLL_SMS(_sms)); \
+| DWC_CTLL_DMS(_dwc->dst_master) \
+| DWC_CTLL_SMS(_dwc->src_master)); \
})
/*
@@ -91,13 +61,6 @@ static inline unsigned int dwc_get_master(struct dma_chan
*chan, int master)
*/
#define NR_DESCS_PER_CHANNEL 64
-static inline unsigned int dwc_get_data_width(struct dma_chan *chan, int
master)
-{
- struct dw_dma *dw = to_dw_dma(chan->device);
-
- return dw->data_width[dwc_get_master(chan, master)];
-}
-
/*--*/
static struct device *chan2dev(struct dma_chan *chan)
@@ -171,13 +134,7 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
if (dwc->initialized == true)
return;
- if (dws && dws->cfg_hi == ~0 && dws->cfg_lo == ~0) {
- /* autoconfigure based on request line from DT */
- if (dwc->direction == DMA_MEM_TO_DEV)
- cfghi = DWC_CFGH_DST_PER(dwc->request_line);
- else if (dwc->direction == DMA_DEV_TO_MEM)
- cfghi = DWC_CFGH_SRC_PER(dwc->request_line);
- } else if (dws) {
+ if (dws) {
/*
* We need controller-specific data to set up slave
* transfers.
@@ -187,10 +144,12 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
cfghi = dws->cfg_hi;
cfglo |= dws->cfg_lo & ~DWC_CFGL_CH_PRIOR_MASK;
} else {
+ unsigned int request_line = (dwc->request_line != ~0) ?
+ dwc->request_line : dwc->dma_sconfig.slave_id;
if (dwc->direction == DMA_MEM_TO_DEV)
- cfghi = DWC_CFGH_DST_PER(dwc->dma_sconfig.slave_id);
+ cfghi = DWC_CFGH_DST_PER(request_line);
else if (dwc->direction == DMA_DEV_TO_MEM)
- cfghi = DWC_CFGH_SRC_PER(dwc->dma_sconfig.slave_id);
[PATCHv3 2/4] dmaengine: dw_dmac: move to generic DMA binding
The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of the slave-dma tree, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
This version incorporates feedback from Viresh Kumar, Andy Shevchenko
and Russell King.
Signed-off-by: Arnd Bergmann
Acked: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 +-
drivers/dma/dw_dmac.c | 142 ++---
drivers/dma/dw_dmac_regs.h | 11 +-
include/linux/dw_dmac.h| 5 -
4 files changed, 112 insertions(+), 116 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..d58675e 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,59 +3,61 @@
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
- that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by
the
- general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported, up to 16
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be <3>
- chan_allocation_order: order of allocation of channel, 0 (default):
ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
-- nr_masters: Number of AHB masters supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-- slave_info:
- - bus_id: name of this device channel, not just a device name since
- devices may have more than one channel e.g. "foo_tx". For using the
- dw_generic_filter(), slave drivers must pass exactly this string as
- param to filter function.
- - cfg_hi: Platform-specific initializer for the CFG_HI register
- - cfg_lo: Platform-specific initializer for the CFG_LO register
- - src_master: src master for transfers on allocated channel.
- - dst_master: dest master for transfers on allocated channel.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- is_private: The device channels should be marked as private and not for by
the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma@fc00 {
+ dmahost: dma@fc00 {
compatible = "snps,dma-spear1340";
reg = <0xfc00 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
- nr_channels = <8>;
+ dma-channels = <8>;
+ dma-requests = <16>;
+ dma-masters = <2>;
+ #dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
- nr_masters = <2>;
data_width = <3 3 0 0>;
+ };
- slave_info {
- uart0-tx {
- bus_id = "uart0-tx";
- cfg_hi = <0x4000>; /* 0x8 << 11 */
- cfg_lo = <0>;
- src_master = <0>;
- dst_master = <1>;
- };
- spi0-tx {
- bus_id = "spi0-tx";
- cfg_hi = <0x2000>; /* 0x4 << 11 */
- cfg_lo = <0>;
- src_master = <0>;
- dst_master = <0>;
- };
- };
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a four-cell specifier for each channel.
+The four cells in ord
Re: [PATCH 01/11] ARM: disable virt_to_bus/virt_to_bus almost everywhere
Hello Arnd, El 14/02/13 10:49, Arnd Bergmann escribió: > We are getting a number of warnings about the use of the deprecated > bus_to_virt function in drivers using the ARM ISA DMA API: > > drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma': > drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated > (declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations] > > This is only because that function gets used by the inline > set_dma_addr() helper. We know that any driver for the ISA DMA API > is correctly using the DMA addresses, so we can change this > to use the __bus_to_virt() function instead, which does not warn. > > After this, there are no remaining drivers that are used on > any defconfigs on ARM using virt_to_bus or bus_to_virt, with > the exception of the OSS sound driver. That driver is only used > on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS > on all other platforms and hide the deprecated functions, which > is far more effective than marking them as deprecated, in order > to avoid any new users of that code. > > Signed-off-by: Arnd Bergmann > Cc: Russell King Small nitpick: Please have a look at the patch subject, I suppose you meant something like "virt_to_bus/bus_to_virt" instead of "virt_to_bus/virt_to_bus". Thanks, Emilio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tg3: Use different macros for pci_chip_rev_id accesses
On Sat, 2013-02-16 at 13:20 -0800, Joe Perches wrote: > Upper case macros for various chip attributes are slightly > difficult to read and are a bit out of characterto the other > tg3_ attribute functions. > > Convert: > > GET_ASIC_REV(tp->pci_chip_rev_id) -> tg3_asic_rev(tp) > GET_CHIP_REV(tp->pci_chip_rev_id) -> tg3_chip_rev(tp) > > Remove: > GET_METAL_REV(tp->pci_chip_rev_id) -> tg3_metal_rev(tp) (unused) > > Add: > tg3_chip_rev_id(tp) for tp->pci_chip_rev_id so access styles > are similar to tg3_asic_rev and tg3_chip_rev. > > These macros are not converted to static inline functions > because gcc (tested with 4.7.2) is currently unable to > optimize the object code it produces the same way and code > is otherwise larger. > > Signed-off-by: Joe Perches Acked-by: Michael Chan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 0/8] 3.4.32-stable review
On Fri, Feb 15, 2013 at 3:56 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.32 release. > There are 8 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Feb 17 22:53:47 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.32-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - Patches applied cleanly to 3.0.64, 3.4.31, and 3.7.8. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Reviewed patches Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/10] 3.7.9-stable review
On Fri, Feb 15, 2013 at 3:56 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.7.9 release. > There are 10 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Feb 17 22:54:03 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.9-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.64, 3.4.31, and 3.7.8. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Reviewed patches Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 0/4] 3.0.65-stable review
On Fri, Feb 15, 2013 at 3:55 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.65 release. > There are 4 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Feb 17 22:53:56 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.65-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - Patches applied cleanly to 3.0.64, 3.4.31, and 3.7.8. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics Reviewed patches Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y. mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Debugging Thinkpad T430s occasional suspend failure.
The syscall generation *should* make files with different names only, but I'll look. Linus Torvalds wrote: >On Sat, Feb 16, 2013 at 11:25 AM, Paul E. McKenney > wrote: >> >> Sorry for the delay in testing this, but there was a need to upgrade >> my laptop, and bozo here figured "why not go to 64 bits while I am at >> it?" -- and then proceeded to learn the hard way that it is necessary >> to do "make mrproper" before doing a build in 64-bit mode. :-/ > >Hmm. Our object file dependency check includes checking that the >compiler options are the same, but that's only true for normal C >files. Some of the other rules do *not* test the full range of config >options, so in general, if you change architecture etc models, you do >indeed want to make sure that you do a "make distclean" (aka "make >mrproper") or something like "git clean -dqfx". > >For a number of other files, we just depend on the normal make >timestamp logic, which means that "if the object file is newer than >the sources", we'll trust it. Which obviously doesn't work for cases >where the object file may have been generated under totally different >architecture rules.. > >(That said, what kind of old environment did you do this in? >stub32_sigaltstack was removed during the merge window, so I'm >assuming you applied my patch on top of plain 3.7 or something?) > >> The kernel build system's way of telling you this at the moment is: >> >> arch/x86/built-in.o:(.rodata+0x4990): undefined reference to >`stub32_sigaltstack' > >Adding Peter Anvin to the people, just in case he sees what's wrong >with the system call stub generation that keeps excessively old object >files around. If it's easy to fix, it might be worth trying to make it >ok to switch from i386 to x86-64 and back in the same tree. > >Peter? Not a big deal, but if you see something obvious, let's just >try to fix it, ok? > >> Anyway, with this patch, I see CPU stall warnings when running >rcutorture >> as shown below. This is not a hard failure: > >Yeah, there's something wrong with the patch, I didn't bother trying >to figure it out for now. It also causes a hard failure with lockdep >(or lock proving/debugging, I'm not sure which one triggered it) - and >it happens too early to even see anything on the screen. > >So I'd like to make that "downgrade from hardirq to softirq" atomic, >and I think it would clean up the crazy code too (currently it does a >*lot* of back-and-forth on the preempt flags), but I clearly missed >some case where we used a wrapper or two to add some tracepoint or a >RCU scheduling point. And I'm not going to worry about it right now, >since I'm preparing to make v3.8 soon. > >But if somebody spots the bug, holler. > > Linus -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] I2C: add i2c_master_send_exact() and friends
On Sat, Feb 16, 2013 at 10:25:24PM +0100, Jean Delvare wrote:
> Hi Dmitry,
>
> On Fri, 15 Feb 2013 18:42:35 -0800, Dmitry Torokhov wrote:
> > Many i2c users consider short transfers to be an error and would prefer
> > getting -EIO instead of a positive return value and having to convert
> > it to error code by themselves. So let's add the following new helpers:
> >
> > i2c_master_send_exact()
> > i2c_master_recv_exact()
> > i2c_transfer_exact()
>
> This is interesting, so far people had been complaining that
> i2c_transfer() wasn't telling enough to the caller on error. You're the
> first one asking for less detail. But in a way this is the same
> request: the current API can't report both errors and number of
> transferred messages/bytes, so the interface ends up being too complex
> for what it can actually do.
>
> There was a proposal to improve that but it required touching struct
> i2c_msg in a way that would break binary compatibility on some
> architectures, so it was rejected.
>
> At this point I can only think of two ways to address the issue
> properly: either introduce a new i2c_msg-like structure, or add an
> optional u16* parameter to i2c_transfer(), pointing to an array with
> the same size as msgs, where the number of transferred bytes for each
> message would be recorded. The latter doesn't look as nice but would be
> better performance-wise (no need to convert between old and new i2c_msg
> structures in compatibility paths.) In both cases, this would have to
> be implemented optionally on a per-driver basis, and user-space
> wouldn't benefit of it unless someone explicitly adds new ioctls to the
> i2c-dev interface.
>
> If this ever happens then your proposal makes sense. Otherwise it might
> actually make more sense to just simplify the current API by only
> returning success (0) or a negative error code, and adding some
> compatibility code into i2c-dev.c so that user-space doesn't see the
> change.
I'd be OK with this as well. What I want to avoid is the checks below
repeated in every input driver for I2C devices. If you look at them they
all care about getting (or transmitting) the whole structure and neither
of them is happy with partial transfers.
I am pretty sure if I look into other subsystems I will find more
examples of that.
>
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > Resending to Wolfram's new address...
> >
> > drivers/i2c/i2c-core.c | 69
> >
> > include/linux/i2c.h| 11
> > 2 files changed, 80 insertions(+)
> >
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index e388590..6cddb5d 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -1430,6 +1430,33 @@ int i2c_transfer(struct i2c_adapter *adap, struct
> > i2c_msg *msgs, int num)
> > EXPORT_SYMBOL(i2c_transfer);
> >
> > /**
> > + * i2c_transfer_exact - transfer given number of I2C messages
> > + * @adap: Handle to I2C bus
> > + * @msgs: One or more messages to execute before STOP is issued to
> > + * terminate the operation; each message begins with a START.
> > + * @num: Number of messages to be executed.
> > + *
> > + * Returns negative errno (including -EIO on short transfer),
> > + * or 0 if all messages have been tranferred successfully.
> > + *
> > + * Note that there is no requirement that each message be sent to
> > + * the same slave address, although that is the most common model.
> > + */
> > +int i2c_transfer_exact(struct i2c_adapter *adap,
> > + struct i2c_msg *msgs, int num)
> > +{
> > + int ret;
> > +
> > + ret = i2c_transfer(adap, msgs, num);
> > + if (ret == num)
> > + return 0;
> > +
> > + return ret < 0 ? ret : -EIO;
> > +
> > +}
> > +EXPORT_SYMBOL(i2c_transfer_exact);
>
> Two questions here which apply to other functions as well:
> * Why don't you use EXPORT_SYMBOL_GPL()?
2 reasons:
1. I am following the rest of the file which uses standard
EXPORT_SYMBOL()
2. I find EXPORT_SYMBOL_GPL() is stupid idea as it does not really add
anything over standard EXPORT_SYMBOL(). The entire kernel is GPL and a
particular code is either derivative work or it is not. If it is and it
is not GPL then it is in violation of the license and can not use any of
the symbols. And if it is not a derivative work, then again GPL vs
non-GPL symbols make no real difference.
However if you prefer EXPORT_SYMBOL_GPL() I can change it.
> * Did you check if an inline function wouldn't be cheaper in practice?
> i2c_transfer() is already a wrapper around __i2c_transfer(), and
> i2c_master_send/recv() are wrappers around i2c_transfer(). Adding one
> more wrapper level is going to do no good to performance and stack
> usage.
I'll check, but I do not expect a wrapper adding any performance
penalties. We'd also pass most of the parameters in registers so I do
not think the stack usage is an issue either.
Thanks.
--
Dmitry
--
To unsubscribe fro
Re: thermal governor: does it actually work??
On Sat, Feb 16, 2013 at 04:08:11PM -0500, Alexander Lam wrote: > I wrote a patch to fix this: > > http://lkml.org/lkml/2012/12/30/47 > > But nobody picked it up and since then I have been too busy to respin > the patch for new -rc kernels. Hmm, that's definitely worth a try - we've been discussing maybe the same issue with acerhdf recently. Peter, Andreas? I'll try to test it soon too. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging Thinkpad T430s occasional suspend failure.
On Thu, 14 Feb 2013, Linus Torvalds wrote:
> On Thu, Feb 14, 2013 at 6:09 PM, Hugh Dickins wrote:
> >
> > Which won't affect my case since I never enabled it.
>
> Well, in theory, you may have the same bug Dave just made it easier to
> trigger for himself with the forced config option.
>
> In reality, your bug behavior differences were already big enough that
> it sounded likely that they were two different things to start with..
Yes.
I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
yesterday, to save an oopsing core kernel ip there, instead of hashed
pm trace info (it makes sense in this case to invert your sequence,
putting the high order into years and the low order into minutes).
Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
/home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
* enable dithering as needed, but that costs bandwidth. So choose
* the minimum value that expresses the full color range of the fb but
* also stays within the max display bpc discovered above.
*/
switch (fb->depth) {
812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
812d60ed: 8b 02 mov(%rdx),%eax
(gcc chose to pass a pointer to fb->depth down to the function,
instead of fb itself, since that is the only use of it there.)
I expect that fb is NULL; but with an average of one failure to resume
per day, and ~26 bits of info per crash, this is not a fast procedure!
I notice that intel_pipe_set_base() allows for NULL fb,
so I'm currently running with the oops-in-rtc hackery, plus
- switch (fb->depth) {
+ if (WARN_ON(!fb))
+ bpc = 8;
+ else switch (fb->depth) {
There's been a fair bit of change to intel_display.c since 3.7 (if
my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
ironlake_, but I've not yet spotted anything obvious; nor yet looked
to see where fb would originate from anyway.
Once I've got just a little more info out of it, I'll start another
thread addressed principally to the drm/gpu/i915 guys.
Anyway, nothing I've found yet is worth delaying v3.8.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tg3: Remove define and single use of GET_CHIP_REV_ID
On Sat, 2013-02-16 at 13:20 -0800, Joe Perches wrote: > It's the same value as tp->pci_chip_rev_id so use that > instead. This makes all CHIPREV_ID_ tests the same. > > Signed-off-by: Joe Perches Acked-by: Michael Chan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power: rx51_battery: Fix reporting correct values
On Fri, Feb 15, 2013 at 11:56:50PM +0100, Pali Rohár wrote: > Tell twl4030_madc_conversion that this driver needs raw values. > Driver twl4030_madc has some hardcoded values and conversation > functions which are incorrect for Nokia RX-51 board. This driver > rx51_battery expects raw values which convert itself. > > This patch fixing values reported by power supply interface. > Before this patch driver reported always incorrect values on > 3.8 kernel (sometimes design capacity was negative). > > Signed-off-by: Pali Rohár Assuming you want to pass the series via MFD tree, Acked-by: Anton Vorontsov Thanks! > --- > drivers/power/rx51_battery.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/power/rx51_battery.c b/drivers/power/rx51_battery.c > index 527d256..d1e17b0 100644 > --- a/drivers/power/rx51_battery.c > +++ b/drivers/power/rx51_battery.c > @@ -42,6 +42,7 @@ static int rx51_battery_read_adc(int channel) > req.method = TWL4030_MADC_SW1; > req.func_cb = NULL; > req.type = TWL4030_MADC_WAIT; > + req.raw = true; > > if (twl4030_madc_conversion(&req) <= 0) > return -ENODATA; > -- > 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bq2415x_charger: Add support for offline and 100mA mode
On Sun, Feb 10, 2013 at 06:32:18PM +0100, Pali Rohár wrote: > * Renamed mode BQ2415X_MODE_NONE to BQ2415X_MODE_OFF > because this mode turning chaging completly off > > * Added new mode BQ2415X_MODE_NONE which enable charging > with maximal current limit 100mA (this is minimal safe > value for bq2415x chips) > > Signed-off-by: Pali Rohár Applied, thanks a lot! Anton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] bq27x00_battery: Fix reporting battery temperature
On Sat, Feb 09, 2013 at 12:02:15PM +0100, Pali Rohár wrote:
> On Saturday 09 February 2013 02:57:18 Anton Vorontsov wrote:
> >
> > Hm. The documentation says tenth (1/10) degrees, and you even
> > restate it in the commit message. But the subject, and your
> > example seem to prove that you still report it in 1/100 of
> > Celsius.
> >
> > Unless your phone was on fire during the time you took the
> > values, I tend to think the patch needs to be fixed. :-)
> >
> > Thanks,
> > Anton
> >
>
> Ah, my mistake. I very quicky looked that bq and rx driver
> reporting different values... But bad conversation is in
> rx51_battery driver, not in bq. So drop previous bq patch...
>
> Here is patch for rx51_battery. I think now it should report
> correct temperature. On Nokia N900 it reporting: POWER_SUPPLY_TEMP=350
>
> From 92efbf24ac2fdc7af41abb12afd5e8c319479f6b Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Pali=20Roh=C3=A1r?=
> Date: Sat, 9 Feb 2013 11:06:48 +0100
> Subject: [PATCH]
> =?UTF-8?q?rx51=5Fbattery:=20Fix=20reporting=20temperature=20?=
> =?UTF-8?q?(in=201/10=20=C2=B0C)?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
The patch is missing signed-off-by tag and commit message. :-/
Thanks,
> ---
> drivers/power/rx51_battery.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/rx51_battery.c b/drivers/power/rx51_battery.c
> index 820..527d256 100644
> --- a/drivers/power/rx51_battery.c
> +++ b/drivers/power/rx51_battery.c
> @@ -119,7 +119,7 @@ static int rx51_battery_read_temperature(struct
> rx51_device_info *di)
>
> /* First check for temperature in first direct table */
> if (raw < ARRAY_SIZE(rx51_temp_table1))
> - return rx51_temp_table1[raw] * 100;
> + return rx51_temp_table1[raw] * 10;
>
> /* Binary search RAW value in second inverse table */
> while (max - min > 1) {
> @@ -132,7 +132,7 @@ static int rx51_battery_read_temperature(struct
> rx51_device_info *di)
> break;
> }
>
> - return (rx51_temp_table2_first - min) * 100;
> + return (rx51_temp_table2_first - min) * 10;
> }
>
> /*
> --
> 1.7.10.4
>
> --
> Pali Rohár
> pali.ro...@gmail.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] generic-adc-battery: forever loop in gab_remove()
On Thu, Feb 14, 2013 at 10:26:43AM +0300, Dan Carpenter wrote: > There is a forever loop calling iio_channel_release() because the > "chan < " part of the "chan < ARRAY_SIZE()" is missing. This is in both > the error handling on probe and also in the remove function. > > The other thing is that it's possible for some of the elements of the > adc_bat->channel[chan] array to be an ERR_PTR(). I've changed them to > be NULL instead. We're still not allowed to pass NULLs to > iio_channel_release() so I've added a check. > > Finally, I removed an unused "chan = ARRAY_SIZE(gab_chan_name);" > statement as a small cleanup. > > Signed-off-by: Dan Carpenter Applied, thanks a lot! Anton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/15] drivers/power,goldfisch battery: add missing GENERIC_HARDIRQS dependency
On Wed, Feb 06, 2013 at 05:24:02PM +0100, Heiko Carstens wrote: > Fix this link error on s390: > > ERROR: "devm_request_threaded_irq" [drivers/power/goldfish_battery.ko] > undefined! > > Cc: Anton Vorontsov > Cc: David Woodhouse > Signed-off-by: Heiko Carstens > --- Applied, thanks! > drivers/power/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig > index 1e47197..9e00c38 100644 > --- a/drivers/power/Kconfig > +++ b/drivers/power/Kconfig > @@ -348,6 +348,7 @@ config AB8500_BM > > config BATTERY_GOLDFISH > tristate "Goldfish battery driver" > + depends on GENERIC_HARDIRQS > help > Say Y to enable support for the battery and AC power in the > Goldfish emulator. > -- > 1.7.10.4 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] I2C: add i2c_master_send_exact() and friends
Hi Dmitry,
On Fri, 15 Feb 2013 18:42:35 -0800, Dmitry Torokhov wrote:
> Many i2c users consider short transfers to be an error and would prefer
> getting -EIO instead of a positive return value and having to convert
> it to error code by themselves. So let's add the following new helpers:
>
> i2c_master_send_exact()
> i2c_master_recv_exact()
> i2c_transfer_exact()
This is interesting, so far people had been complaining that
i2c_transfer() wasn't telling enough to the caller on error. You're the
first one asking for less detail. But in a way this is the same
request: the current API can't report both errors and number of
transferred messages/bytes, so the interface ends up being too complex
for what it can actually do.
There was a proposal to improve that but it required touching struct
i2c_msg in a way that would break binary compatibility on some
architectures, so it was rejected.
At this point I can only think of two ways to address the issue
properly: either introduce a new i2c_msg-like structure, or add an
optional u16* parameter to i2c_transfer(), pointing to an array with
the same size as msgs, where the number of transferred bytes for each
message would be recorded. The latter doesn't look as nice but would be
better performance-wise (no need to convert between old and new i2c_msg
structures in compatibility paths.) In both cases, this would have to
be implemented optionally on a per-driver basis, and user-space
wouldn't benefit of it unless someone explicitly adds new ioctls to the
i2c-dev interface.
If this ever happens then your proposal makes sense. Otherwise it might
actually make more sense to just simplify the current API by only
returning success (0) or a negative error code, and adding some
compatibility code into i2c-dev.c so that user-space doesn't see the
change.
> Signed-off-by: Dmitry Torokhov
> ---
>
> Resending to Wolfram's new address...
>
> drivers/i2c/i2c-core.c | 69
>
> include/linux/i2c.h| 11
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index e388590..6cddb5d 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1430,6 +1430,33 @@ int i2c_transfer(struct i2c_adapter *adap, struct
> i2c_msg *msgs, int num)
> EXPORT_SYMBOL(i2c_transfer);
>
> /**
> + * i2c_transfer_exact - transfer given number of I2C messages
> + * @adap: Handle to I2C bus
> + * @msgs: One or more messages to execute before STOP is issued to
> + * terminate the operation; each message begins with a START.
> + * @num: Number of messages to be executed.
> + *
> + * Returns negative errno (including -EIO on short transfer),
> + * or 0 if all messages have been tranferred successfully.
> + *
> + * Note that there is no requirement that each message be sent to
> + * the same slave address, although that is the most common model.
> + */
> +int i2c_transfer_exact(struct i2c_adapter *adap,
> +struct i2c_msg *msgs, int num)
> +{
> + int ret;
> +
> + ret = i2c_transfer(adap, msgs, num);
> + if (ret == num)
> + return 0;
> +
> + return ret < 0 ? ret : -EIO;
> +
> +}
> +EXPORT_SYMBOL(i2c_transfer_exact);
Two questions here which apply to other functions as well:
* Why don't you use EXPORT_SYMBOL_GPL()?
* Did you check if an inline function wouldn't be cheaper in practice?
i2c_transfer() is already a wrapper around __i2c_transfer(), and
i2c_master_send/recv() are wrappers around i2c_transfer(). Adding one
more wrapper level is going to do no good to performance and stack
usage.
> +
> +/**
> * i2c_master_send - issue a single I2C message in master transmit mode
> * @client: Handle to slave device
> * @buf: Data that will be written to the slave
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] tg3: Remove define and single use of GET_CHIP_REV_ID
It's the same value as tp->pci_chip_rev_id so use that
instead. This makes all CHIPREV_ID_ tests the same.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/broadcom/tg3.c | 10 --
drivers/net/ethernet/broadcom/tg3.h | 4 +---
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index 1b59876..f511e8b 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -15761,12 +15761,10 @@ static int tg3_get_invariants(struct tg3 *tp, const
struct pci_device_id *ent)
&pci_state_reg);
if ((pci_state_reg & PCISTATE_CONV_PCI_MODE) == 0 &&
!tg3_flag(tp, PCIX_TARGET_HWBUG)) {
- u32 chiprevid = GET_CHIP_REV_ID(tp->misc_host_ctrl);
-
- if (chiprevid == CHIPREV_ID_5701_A0 ||
- chiprevid == CHIPREV_ID_5701_B0 ||
- chiprevid == CHIPREV_ID_5701_B2 ||
- chiprevid == CHIPREV_ID_5701_B5) {
+ if (tp->pci_chip_rev_id == CHIPREV_ID_5701_A0 ||
+ tp->pci_chip_rev_id == CHIPREV_ID_5701_B0 ||
+ tp->pci_chip_rev_id == CHIPREV_ID_5701_B2 ||
+ tp->pci_chip_rev_id == CHIPREV_ID_5701_B5) {
void __iomem *sram_base;
/* Write some dummy words into the SRAM status block
diff --git a/drivers/net/ethernet/broadcom/tg3.h
b/drivers/net/ethernet/broadcom/tg3.h
index b676728..3e27f2e 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -120,9 +120,7 @@
#define MISC_HOST_CTRL_TAGGED_STATUS 0x0200
#define MISC_HOST_CTRL_CHIPREV 0x
#define MISC_HOST_CTRL_CHIPREV_SHIFT 16
-#define GET_CHIP_REV_ID(MISC_HOST_CTRL) \
-(((MISC_HOST_CTRL) & MISC_HOST_CTRL_CHIPREV) >> \
- MISC_HOST_CTRL_CHIPREV_SHIFT)
+
#define CHIPREV_ID_5700_A0 0x7000
#define CHIPREV_ID_5700_A1 0x7001
#define CHIPREV_ID_5700_B0 0x7100
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: thermal governor: does it actually work??
I wrote a patch to fix this: http://lkml.org/lkml/2012/12/30/47 But nobody picked it up and since then I have been too busy to respin the patch for new -rc kernels. On Fri, Feb 15, 2013 at 10:49 AM, Andreas Mohr wrote: > > Hi, > > On Fri, Feb 15, 2013 at 09:47:07AM +, Zhang, Rui wrote: > > Please attach the output of > > "grep . /sys/class/thermal/thermal_zone*/cdev*/*"? > > # grep . /sys/class/thermal/thermal_zone*/cdev*/* > /sys/class/thermal/thermal_zone0/cdev0/cur_state:1 > /sys/class/thermal/thermal_zone0/cdev0/max_state:1 > grep: /sys/class/thermal/thermal_zone0/cdev0/power: Is a directory > grep: /sys/class/thermal/thermal_zone0/cdev0/subsystem: Is a directory > /sys/class/thermal/thermal_zone0/cdev0/type:acerhdf-fan > > > The question is that if we can also call it "throttle" when reducing the > > device performance to generate less heat. > > I won't continue to elaborate on this separate issue now, given that my > time > currently is very limited ;) > > Andreas Mohr > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Alexander Lam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Debugging Thinkpad T430s occasional suspend failure.
On Wed, Feb 13, 2013 at 03:53:13PM -0500, Dave Jones wrote: > On Wed, Feb 13, 2013 at 11:56:25AM -0800, Linus Torvalds wrote: [ . . . ] > Which points out something in tree-rcu. Which I don't even have compiled in, > because I have CONFIG_PREEMPT set. FWIW, the code in kernel/rcutree.c is shared between CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU. The differences between these two options is mostly in kernel/rcutree_plugin.h under #ifdef, with some others in include/linux/rcudate.h and kernel/rcutree.h. Thanx, Paul > I'll keep trying some of the earlier good branches in case I missed something. > > 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/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/6] Input: Add ChromeOS EC keyboard driver
Hi Simon,
On Fri, Feb 15, 2013 at 08:16:12PM -0800, Simon Glass wrote:
> + for (row = 0; row < ckdev->rows; row++) {
> + if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
> + return true;
> + }
No need for curly braces here. I would not care if not for below.
> +
> + return 0;
> +
> +fail_register:
> + kfree(idev->keycode);
Sorry I did not notice this before, but idev->keycode is devm-managed,
so you either need to use devm_kfree() or just remove call to kfree()
and let it clean up automatically (which will happen if binding fails or
upon removal).
BTW, maybe you should move the whole driver to devm_*? We have
devm_kzalloc() for ckdev and you can use devm_input_allocate_device().
Then you can get rid of entire erro handling path and completely remove
the remove() method as well.
> +fail_matrix:
> + input_free_device(idev);
> +fail_alloc_dev:
> + kfree(ckdev);
> + return err;
> +}
> +
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: twl: Use to_twl() instead of container_of()
On Sat, Feb 16, 2013 at 08:54:32PM +0100, Johannes Thumshirn wrote: > Always use to_twl() for converting into private data instead of container_of() > > Signed-off-by: Johannes Thumshirn > --- > drivers/pwm/pwm-twl.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) I've squashed this patch into the previous one and applied to the for-next branch. Thanks, Thierry pgpnRr1zNxf8Y.pgp Description: PGP signature
Re: linux-next: build failure after merge of the xen-two tree
On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote: > Hi Rafael, Hi, > On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" wrote: > > > > On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote: > > > > > > On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk > > > wrote: > > > > > > > > Thank you. I keep on forgetting - but would it be OK for me to take this > > > > patch in my tree? Or should I not since this is a new functionality that > > > > Rafael is going to introduce in v3.9? > > > > > > It is an API change in the pm tree that is not yet in Linus' tree. > > > > > > > And if so, perhaps I should tack it on in my tree, once Rafael does a > > > > git > > > > pull to Linus? Or just point Linus to this git commit? > > > > > > You should point Linus at this patch if the pm tree is merged first, or > > > Rafael should do the same if the reverse happens. > > > > Alternatively, Konrad can pull the acpi-scan branch containing the changes > > in question from my tree into his tree and rebase the new material on top > > of that. > > Or pull the acpi-scan branch into his tree and use my conflict resolution > in the resulting merge thus requiring no rebasing. However, Linus likes > to see such interactions, so it can be left up to when the latter of the > two tress is merged by Linus. Well, I'm afraid this won't be sufficient this time, because of this commit in my tree (which is not on the acpi-scan branch): commit 3757b94802fb65d8f696597a74053cf21738da0b Author: Rafael J. Wysocki Date: Wed Feb 13 14:36:47 2013 +0100 ACPI / hotplug: Fix concurrency issues and memory leaks after which acpi_bus_scan() and acpi_bus_trim() have to be run under acpi_scan_lock (new in my tree as well). Moreover, I think that the introduction of ACPI-based CPU hotplug into Xen and this point would be premature, because we need to rework the original ACPI-based CPU hotplug and quite frankly it shouldn't call acpi_bus_scan() directly at all. Konrad? Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: twl: Use to_twl() instead of container_of()
Always use to_twl() for converting into private data instead of container_of()
Signed-off-by: Johannes Thumshirn
---
drivers/pwm/pwm-twl.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
index a34c235..9cd2c9a 100644
--- a/drivers/pwm/pwm-twl.c
+++ b/drivers/pwm/pwm-twl.c
@@ -200,8 +200,7 @@ out:
static void twl4030_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
- chip);
+ struct twl_pwm_chip *twl = to_twl(chip);
int ret;
u8 val, mask;
@@ -231,8 +230,7 @@ out:
static int twl6030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
- chip);
+ struct twm_pwm_chip *twl = to_twl(chip);
int ret;
u8 val;
--
1.8.1.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: [-rc7 regression] Buggy commit: "mm: use aligned zone start for pfn_to_bitidx calculation"
On Sat, Feb 16, 2013 at 11:38 AM, Yinghai Lu wrote: > > but you forgot to update setup_usemap() for SPARSEMEM Heh. I tried desperately to find a config to test my patch in, because I couldn't see how to even disable SPARSEMEM for my normal x86-64 build. But then I *only* tested it for that non-SPARSEMEM case, expecting that to be what showed any problems. The fact that I didn't bother testing my normal config is a bit ironic. But I'd still like verification that it actually fixes Ingo's issue. It *looks* like it should, and it would explain the potential for memory corruption, but perhaps Ingo's odd lock-up is due to something really subtle and unrelated to the actual allocation size. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] coredump: ignore non-fatal signals when core dumping to a pipe
On 02/16, Oleg Nesterov wrote:
>
> On 02/16, Mandeep Singh Baines wrote:
> >
> > +static int sigkill_pending(struct task_struct *tsk)
> > +{
> > + return signal_pending(tsk) &&
> > + (sigismember(&tsk->pending.signal, SIGKILL) ||
> > +sigismember(&tsk->signal->shared_pending.signal, SIGKILL));
> > +}
>
> Why? __fatal_signal_pending() is enough, you do not need to check
> ->shared_pending. And once again, ignoring the freezer problems I
> do not think we need this check at all.
>
> IOW. Yes, we will probably need to do this change but only to be
> freezer-friendly.
And, forgot to mention, this logic is not right in the multi-
threaded case. I mean, you can't assume that 'kill -9 dumpingtask"
will wake the coredumping thread up. So this sigkill_pending() or
__fatal_signal_pending() check can only work in the single-threaded
case.
> --- x/fs/coredump.c
> +++ x/fs/coredump.c
> @@ -416,17 +416,17 @@ static void wait_for_dump_helpers(struct
> pipe_lock(pipe);
> pipe->readers++;
> pipe->writers--;
> + // TODO: wake_up_interruptible_sync_poll ?
> + wake_up_interruptible_sync(&pipe->wait);
> + kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
> + pipe_unlock(pipe);
>
> - while ((pipe->readers > 1) && (!signal_pending(current))) {
> - wake_up_interruptible_sync(&pipe->wait);
> - kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
> - pipe_wait(pipe);
> - }
> + wait_event_freezekillable(&pipe->wait, pipe->readers == 1);
I tried to check (but didn't even try to test). I think this should
work. Assuming that we teach SIGKILL to actually kill the dumper, but
we need this in any case.
But. Then we need to change pipe_release() to use wake_up_sync_poll()
(which we do not have). Probably we can do this... but otoh if we protect
the dumping thread from the non-fatal signals (and again, we need this
anyway ;) then we can simply do wait_event_freezable().
Damn. I need to think more.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Debugging Thinkpad T430s occasional suspend failure.
On Sat, Feb 16, 2013 at 11:25 AM, Paul E. McKenney wrote: > > Sorry for the delay in testing this, but there was a need to upgrade > my laptop, and bozo here figured "why not go to 64 bits while I am at > it?" -- and then proceeded to learn the hard way that it is necessary > to do "make mrproper" before doing a build in 64-bit mode. :-/ Hmm. Our object file dependency check includes checking that the compiler options are the same, but that's only true for normal C files. Some of the other rules do *not* test the full range of config options, so in general, if you change architecture etc models, you do indeed want to make sure that you do a "make distclean" (aka "make mrproper") or something like "git clean -dqfx". For a number of other files, we just depend on the normal make timestamp logic, which means that "if the object file is newer than the sources", we'll trust it. Which obviously doesn't work for cases where the object file may have been generated under totally different architecture rules.. (That said, what kind of old environment did you do this in? stub32_sigaltstack was removed during the merge window, so I'm assuming you applied my patch on top of plain 3.7 or something?) > The kernel build system's way of telling you this at the moment is: > > arch/x86/built-in.o:(.rodata+0x4990): undefined reference to > `stub32_sigaltstack' Adding Peter Anvin to the people, just in case he sees what's wrong with the system call stub generation that keeps excessively old object files around. If it's easy to fix, it might be worth trying to make it ok to switch from i386 to x86-64 and back in the same tree. Peter? Not a big deal, but if you see something obvious, let's just try to fix it, ok? > Anyway, with this patch, I see CPU stall warnings when running rcutorture > as shown below. This is not a hard failure: Yeah, there's something wrong with the patch, I didn't bother trying to figure it out for now. It also causes a hard failure with lockdep (or lock proving/debugging, I'm not sure which one triggered it) - and it happens too early to even see anything on the screen. So I'd like to make that "downgrade from hardirq to softirq" atomic, and I think it would clean up the crazy code too (currently it does a *lot* of back-and-forth on the preempt flags), but I clearly missed some case where we used a wrapper or two to add some tracepoint or a RCU scheduling point. And I'm not going to worry about it right now, since I'm preparing to make v3.8 soon. But if somebody spots the bug, holler. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: twl: Use to_twl() instead of container_of()
On Sat, Feb 16, 2013 at 07:56:18PM +0100, Thierry Reding wrote: > On Sat, Feb 16, 2013 at 07:20:51PM +0100, Johannes Thumshirn wrote: > > In twl6030_pwm_disable() use to_twl() instead of container_of() like in the > > rest of the driver. > > > > Signed-off-by: Johannes Thumshirn > > --- > > drivers/pwm/pwm-twl.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > Hi Johannes, > > I see that container_of() is also still used in twl4030_pwm_free() and > twl6030_pwm_enable(). Would you mind fixing those up as well? > > Thierry Oh sorry haven't seen them, I'll take care of it. 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: [-rc7 regression] Buggy commit: "mm: use aligned zone start for pfn_to_bitidx calculation"
On Sat, Feb 16, 2013 at 10:26 AM, Linus Torvalds
wrote:
> On Fri, Feb 15, 2013 at 3:44 AM, Ingo Molnar wrote:
>>>
>>> c060f943d092 may be related as you config does not have
>>> CONFIG_SPARSEMEM defined.
>>
>> Right, that's the commit causing the x86 regression:
>>
>> c060f943d0929f3e429c5d9522290584f6281d6e is the first bad commit
>> commit c060f943d0929f3e429c5d9522290584f6281d6e
>> Date: Fri Jan 11 14:31:51 2013 -0800
>>
>> mm: use aligned zone start for pfn_to_bitidx calculation
>
> Ok, looking more at this, I don't really want to revert it, and I have
> an idea of what is wrong.
>
> When we allocate the zone use bitmap, we do not take the
> zone_start_pfn into account. So I *think* that what happens is that
> "pfn_to_bitidx()" simply overruns the allocation for unaligned zonesm
> and the spinlock just happens to be right after (or the overrun causes
> some other memory corruption that then indirectly causes the spinlock
> corruption).
>
> So I'm wondering if the fix is simply something like the attached
> patch. It takes the zone_start_pfn into account when allocating the
> zone bitmap.
Yes, that is right fix.
but you forgot to update setup_usemap() for SPARSEMEM
static inline void setup_usemap(struct pglist_data *pgdat,
struct zone *zone, unsigned long zonesize) {}
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Debugging Thinkpad T430s occasional suspend failure.
On Fri, Feb 15, 2013 at 10:50:31AM -0800, Linus Torvalds wrote: > On Fri, Feb 15, 2013 at 10:35 AM, Linus Torvalds > wrote: > > On Fri, Feb 15, 2013 at 10:34 AM, Linus Torvalds > > wrote: > >> > >> Something like this ENTIRELY UNTESTED patch. > > > > .. and let's actually attach the patch this time. > > That's odd. I got a "server error" from gmail. And again no attachment. > > Maybe THIS time. Sorry for the delay in testing this, but there was a need to upgrade my laptop, and bozo here figured "why not go to 64 bits while I am at it?" -- and then proceeded to learn the hard way that it is necessary to do "make mrproper" before doing a build in 64-bit mode. :-/ The kernel build system's way of telling you this at the moment is: arch/x86/built-in.o:(.rodata+0x4990): undefined reference to `stub32_sigaltstack' Anyway, with this patch, I see CPU stall warnings when running rcutorture as shown below. This is not a hard failure: [ 32.553647] rcu-torture: rtc: 836a57a0 ver: 131 tfle: 0 rta: 131 rtaf: 0 rtf: 93 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 27 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=1000) barrier: 6/7:0 Note the "ver: 131", which means that rcutorture successfully did 131 grace periods before the failure. It manages to offline a CPU subsequently, but then appears to hang while onlining it. Thanx, Paul [ 23.706051] INFO: rcu_preempt self-detected stall on CPU[ 23.707053] INFO: rcu_preempt self-detected stall on CPU [ 23.707053] 1: (20976 ticks this GP) idle=883/141/0 drain=5 . timer not pending [ 23.707053] (t=21000 jiffies g=85 c=84 q=6756) [ 23.707053] Pid: 606, comm: rcu_torture_rea Not tainted 3.8.0-rc7+ #2 [ 23.707053] Call Trace: [ 23.707053][] rcu_pending+0x192/0x7a0 [ 23.707053] [] rcu_check_callbacks+0xbb/0x220 [ 23.707053] [] update_process_times+0x43/0x80 [ 23.707053] [] tick_sched_handle.isra.8+0x31/0x40 [ 23.707053] [] tick_sched_timer+0x47/0x70 [ 23.707053] [] __run_hrtimer+0x7c/0x240 [ 23.707053] [] ? tick_nohz_handler+0xa0/0xa0 [ 23.707053] [] ? ktime_get_update_offsets+0x47/0xd0 [ 23.707053] [] hrtimer_interrupt+0xf7/0x240 [ 23.707053] [] smp_apic_timer_interrupt+0x63/0xa0 [ 23.707053] [] apic_timer_interrupt+0x6a/0x70 [ 23.707053][] ? _raw_spin_unlock_irq+0xd/0x40 [ 23.707053] [] __schedule+0x68a/0x790 [ 23.707053] [] schedule+0x24/0x70 [ 23.707053] [] rcu_torture_reader+0xd7/0x2d0 [ 23.707053] [] ? rcu_torture_reader+0x2d0/0x2d0 [ 23.707053] [] ? rcutorture_trace_dump+0x50/0x50 [ 23.707053] [] kthread+0xbb/0xc0 [ 23.707053] [] ? timer_cpu_notify+0x1e9/0x300 [ 23.707053] [] ? flush_kthread_worker+0xa0/0xa0 [ 23.707053] [] ret_from_fork+0x7c/0xb0 [ 23.707053] [] ? flush_kthread_worker+0xa0/0xa0 [ 23.706051] [ 23.706051] 0: (1 GPs behind) idle=429/141/0 drain=5 . timer not pending [ 23.706051] (t=21000 jiffies g=85 c=84 q=6756) [ 23.706051] Pid: 603, comm: rcu_torture_rea Not tainted 3.8.0-rc7+ #2 [ 23.706051] Call Trace: [ 23.706051][] rcu_pending+0x192/0x7a0 [ 23.706051] [] rcu_check_callbacks+0xbb/0x220 [ 23.706051] [] update_process_times+0x43/0x80 [ 23.706051] [] tick_sched_handle.isra.8+0x31/0x40 [ 23.706051] [] tick_sched_timer+0x47/0x70 [ 23.706051] [] __run_hrtimer+0x7c/0x240 [ 23.706051] [] ? tick_nohz_handler+0xa0/0xa0 [ 23.706051] [] ? ktime_get_update_offsets+0x47/0xd0 [ 23.706051] [] hrtimer_interrupt+0xf7/0x240 [ 23.706051] [] smp_apic_timer_interrupt+0x63/0xa0 [ 23.706051] [] apic_timer_interrupt+0x6a/0x70 [ 23.706051][] ? add_preempt_count+0x30/0x90 [ 23.706051] [] __schedule+0x3d/0x790 [ 23.706051] [] schedule+0x24/0x70 [ 23.706051] [] rcu_torture_reader+0xd7/0x2d0 [ 23.706051] [] ? rcu_torture_reader+0x2d0/0x2d0 [ 23.706051] [] ? rcutorture_trace_dump+0x50/0x50 [ 23.706051] [] kthread+0xbb/0xc0 [ 23.706051] [] ? timer_cpu_notify+0x1e9/0x300 [ 23.706051] [] ? flush_kthread_worker+0xa0/0xa0 [ 23.706051] [] ret_from_fork+0x7c/0xb0 [ 23.706051] [] ? flush_kthread_worker+0xa0/0xa0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: twl: Use to_twl() instead of container_of()
On Sat, Feb 16, 2013 at 07:20:51PM +0100, Johannes Thumshirn wrote: > In twl6030_pwm_disable() use to_twl() instead of container_of() like in the > rest of the driver. > > Signed-off-by: Johannes Thumshirn > --- > drivers/pwm/pwm-twl.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Hi Johannes, I see that container_of() is also still used in twl4030_pwm_free() and twl6030_pwm_enable(). Would you mind fixing those up as well? Thierry pgpY7jvkQ9y7U.pgp Description: PGP signature
Re: [-rc7 regression] Buggy commit: "mm: use aligned zone start for pfn_to_bitidx calculation"
On Fri, Feb 15, 2013 at 3:44 AM, Ingo Molnar wrote: >> >> c060f943d092 may be related as you config does not have >> CONFIG_SPARSEMEM defined. > > Right, that's the commit causing the x86 regression: > > c060f943d0929f3e429c5d9522290584f6281d6e is the first bad commit > commit c060f943d0929f3e429c5d9522290584f6281d6e > Date: Fri Jan 11 14:31:51 2013 -0800 > > mm: use aligned zone start for pfn_to_bitidx calculation Ok, looking more at this, I don't really want to revert it, and I have an idea of what is wrong. When we allocate the zone use bitmap, we do not take the zone_start_pfn into account. So I *think* that what happens is that "pfn_to_bitidx()" simply overruns the allocation for unaligned zonesm and the spinlock just happens to be right after (or the overrun causes some other memory corruption that then indirectly causes the spinlock corruption). So I'm wondering if the fix is simply something like the attached patch. It takes the zone_start_pfn into account when allocating the zone bitmap. Laura? Mel? Ingo, can you test this? I was going to do the 3.8 today, but I guess I can just wait, and if you can test this we could get it in.. Linus patch.diff Description: Binary data
[PATCH] pwm: twl: Use to_twl() instead of container_of()
In twl6030_pwm_disable() use to_twl() instead of container_of() like in the
rest of the driver.
Signed-off-by: Johannes Thumshirn
---
drivers/pwm/pwm-twl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
index f783efc..a34c235 100644
--- a/drivers/pwm/pwm-twl.c
+++ b/drivers/pwm/pwm-twl.c
@@ -255,8 +255,7 @@ out:
static void twl6030_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
- chip);
+ struct twl_pwm_chip *twl = to_twl(chip);
int ret;
u8 val;
--
1.8.1.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/
[RFC] ARM: sa1100: collie-battery.c: include platform_device.h directly
Initial try to fix compilation error linux/include/linux/mfd/mcp.h:22:16: error: field 'attached_device' has incomplete type linux/include/linux/mfd/mcp.h:48:23: error: field 'drv' has incomplete type linux/include/linux/mfd/ucb1x00.h:137:17: error: field 'dev' has incomplete type linux/drivers/power/collie_battery.c:290:56: error: unknown type name 'pm_message_t' linux/drivers/power/collie_battery.c:371:13: error: 'collie_bat_suspend' undeclared here (not in a function) | make[4]: *** [drivers/power/collie_battery.o] Error 1 | make[3]: *** [drivers/power] Error 2 As seen in Arnd Bergmann patches on LAKML [PATCH 7/9] ARM defconfigs: add missing inclusions of linux/platform_device.h [PATCH 1/9] ARM: sa1100/assabet: include platform_device.h directly Compilation is still not clean, two warnings: linux/drivers/power/collie_battery.c:372:2: warning: initialization from incompatible pointer type [enabled by default] linux/drivers/power/collie_battery.c:372:2: warning: (near initialization for 'collie_bat_driver.suspend') [enabled by default] Signed-off-by: Andrea Adami --- drivers/power/collie_battery.c| 1 + drivers/video/logo/logo_linux_clut224.ppm | 232006 ++- 2 files changed, 230404 insertions(+), 1603 deletions(-) diff --git a/drivers/power/collie_battery.c b/drivers/power/collie_battery.c index c58d0e3..52cbab3 100644 --- a/drivers/power/collie_battery.c +++ b/drivers/power/collie_battery.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include -- 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 2/2] dmi_scan: Refactor dmi_scan_machine(), {smbios,dmi}_present()
Move the calls to memcpy_fromio() up into the loop in
dmi_scan_machine(), and move the signature checks back down into
dmi_decode(). We need to check at 16-byte intervals but keep a
32-byte buffer for an SMBIOS entry, so shift the buffer after each
iteration.
Merge smbios_present() into dmi_present(), so we look for an SMBIOS
signature at the beginning of the given buffer and then for a DMI
signature at an offset of 16 bytes.
Signed-off-by: Ben Hutchings
---
This file mixes up __iomem and regular pointers a lot, and this patch
fixes some but not all of those instances. Presumably it is quite
safe to read a BIOS image with any mov instructions the compiler
generates, but in that case maybe we should explicitly cast away the
__iomem qualifier in dmi_ioremap()?
Tim, you might like to test that this doesn't cause a regression
of the previous fix.
Ben.
drivers/firmware/dmi_scan.c | 80 ---
1 file changed, 37 insertions(+), 43 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index a86ccff..3439f59 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -410,22 +410,45 @@ static void __init dmi_dump_ids(void)
printk(KERN_CONT "\n");
}
-static int __init dmi_present(const char __iomem *p)
+static int __init dmi_present(const char *buf)
{
- u8 buf[15];
+ int smbios_ver;
- memcpy_fromio(buf, p, 15);
- if (dmi_checksum(buf, 15)) {
+ if (memcmp(buf, "_SM_", 4) == 0 &&
+ buf[5] < 32 && dmi_checksum(buf, buf[5])) {
+ smbios_ver = (buf[6] << 8) + buf[7];
+
+ /* Some BIOS report weird SMBIOS version, fix that up */
+ switch (smbios_ver) {
+ case 0x021F:
+ case 0x0221:
+ pr_debug("SMBIOS version fixup(2.%d->2.%d)\n",
+smbios_ver & 0xFF, 3);
+ smbios_ver = 0x0203;
+ break;
+ case 0x0233:
+ pr_debug("SMBIOS version fixup(2.%d->2.%d)\n", 51, 6);
+ smbios_ver = 0x0206;
+ break;
+ }
+ } else {
+ smbios_ver = 0;
+ }
+
+ buf += 16;
+
+ if (memcmp(buf, "_DMI_", 5) == 0 && dmi_checksum(buf, 15)) {
dmi_num = (buf[13] << 8) | buf[12];
dmi_len = (buf[7] << 8) | buf[6];
dmi_base = (buf[11] << 24) | (buf[10] << 16) |
(buf[9] << 8) | buf[8];
if (dmi_walk_early(dmi_decode) == 0) {
- if (dmi_ver)
+ if (smbios_ver) {
+ dmi_ver = smbios_ver;
pr_info("SMBIOS %d.%d present.\n",
dmi_ver >> 8, dmi_ver & 0xFF);
- else {
+ } else {
dmi_ver = (buf[14] & 0xF0) << 4 |
(buf[14] & 0x0F);
pr_info("Legacy DMI %d.%d present.\n",
@@ -435,40 +458,14 @@ static int __init dmi_present(const char __iomem *p)
return 0;
}
}
- dmi_ver = 0;
- return 1;
-}
-static int __init smbios_present(const char __iomem *p)
-{
- u8 buf[32];
-
- memcpy_fromio(buf, p, 32);
- if ((buf[5] < 32) && dmi_checksum(buf, buf[5])) {
- dmi_ver = (buf[6] << 8) + buf[7];
-
- /* Some BIOS report weird SMBIOS version, fix that up */
- switch (dmi_ver) {
- case 0x021F:
- case 0x0221:
- pr_debug("SMBIOS version fixup(2.%d->2.%d)\n",
- dmi_ver & 0xFF, 3);
- dmi_ver = 0x0203;
- break;
- case 0x0233:
- pr_debug("SMBIOS version fixup(2.%d->2.%d)\n", 51, 6);
- dmi_ver = 0x0206;
- break;
- }
- return memcmp(q + 16, "_DMI_", 5) || dmi_present(p + 16);
- }
return 1;
}
void __init dmi_scan_machine(void)
{
char __iomem *p, *q;
- int rc;
+ char buf[32];
if (efi_enabled(EFI_CONFIG_TABLES)) {
if (efi.smbios == EFI_INVALID_TABLE_ADDR)
@@ -481,10 +478,10 @@ void __init dmi_scan_machine(void)
p = dmi_ioremap(efi.smbios, 32);
if (p == NULL)
goto error;
-
- rc = smbios_present(p);
+ memcpy_fromio(buf, p, 32);
dmi_iounmap(p, 32);
- if (!rc) {
+
+ if (!dmi_present(buf)) {
dmi_available = 1;
goto out;
}
@@ -499,18 +496,15 @@ void __init dmi_scan_machine(void)
if (p == N
[PATCH 1/2] dmi_scan: Fix missing check for _DMI_ signature in smbios_present()
Commit 9f9c9cbb6057 ('drivers/firmware/dmi_scan.c: fetch dmi version
from SMBIOS if it exists') hoisted the check for "_DMI_" into
dmi_scan_machine(), which means that we don't bother to check for
"_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also
call dmi_present() for an address where we found "_SM_", if it failed
further validation.
Check for "_DMI_" in smbios_present() before calling dmi_present().
Reported-by: Tim McGrath
Signed-off-by: Ben Hutchings
Cc: stable
---
This has a memcmp() that wasn't in the previous version, so I've not
included the Acked-by or Tested-by for that.
Ben.
drivers/firmware/dmi_scan.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 982f1f5..a86ccff 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -442,7 +442,6 @@ static int __init dmi_present(const char __iomem *p)
static int __init smbios_present(const char __iomem *p)
{
u8 buf[32];
- int offset = 0;
memcpy_fromio(buf, p, 32);
if ((buf[5] < 32) && dmi_checksum(buf, buf[5])) {
@@ -461,9 +460,9 @@ static int __init smbios_present(const char __iomem *p)
dmi_ver = 0x0206;
break;
}
- offset = 16;
+ return memcmp(q + 16, "_DMI_", 5) || dmi_present(p + 16);
}
- return dmi_present(buf + offset);
+ return 1;
}
void __init dmi_scan_machine(void)
signature.asc
Description: This is a digitally signed message part
[PATCH] ethernet: neterion: vxge: vxge-traffic.c: fix for a potential NULL pointer dereference
fix for a potential NULL pointer dereference and removal of a redundant
assignment operation. Found using smatch.
Signed-off-by: Kumar Amit Mehta
---
drivers/net/ethernet/neterion/vxge/vxge-traffic.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
index 99749bd..adb05a8 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
@@ -611,11 +611,8 @@ __vxge_hw_vpath_alarm_process(struct __vxge_hw_virtualpath
*vpath,
struct vxge_hw_vpath_stats_sw_info *sw_stats;
struct vxge_hw_vpath_reg __iomem *vp_reg;
- if (vpath == NULL) {
- alarm_event = VXGE_HW_SET_LEVEL(VXGE_HW_EVENT_UNKNOWN,
- alarm_event);
+ if (vpath == NULL)
goto out2;
- }
hldev = vpath->hldev;
vp_reg = vpath->vp_reg;
@@ -852,13 +849,12 @@ __vxge_hw_vpath_alarm_process(struct
__vxge_hw_virtualpath *vpath,
}
out:
hldev->stats.sw_dev_err_stats.vpath_alarms++;
+ __vxge_hw_device_handle_error(hldev, vpath->vp_id, alarm_event);
out2:
if ((alarm_event == VXGE_HW_EVENT_ALARM_CLEARED) ||
(alarm_event == VXGE_HW_EVENT_UNKNOWN))
return VXGE_HW_OK;
- __vxge_hw_device_handle_error(hldev, vpath->vp_id, alarm_event);
-
if (alarm_event == VXGE_HW_EVENT_SERR)
return VXGE_HW_ERR_CRITICAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: xhci module fails when booting in UEFI mode
On Thu, Jan 10, 2013 at 11:15:56AM +, Frederik Himpe wrote: >I've got a HP EliteBook 8470p on which I installed Debian Wheezy in UEFI >mode. With both the 3.2 kernel from Wheezy, as the 3.7.1 kernel from >experimental, xhci fails to initialize and my USB mouse connected to one >of these ports is not recognized at all. The USB3 ports work fine in >Windows. > >[1.316248] xhci_hcd :00:14.0: can't derive routing for PCI INT A >[1.316251] xhci_hcd :00:14.0: PCI INT A: no GSI >[1.316253] >[1.316277] xhci_hcd :00:14.0: setting latency timer to 64 >[1.316281] xhci_hcd :00:14.0: xHCI Host Controller >[1.316287] xhci_hcd :00:14.0: new USB bus registered, assigned >bus number 1 >[1.316393] xhci_hcd :00:14.0: cache line size of 64 is not >supported >[1.316395] xhci_hcd :00:14.0: request interrupt 255 failed >[1.316447] xhci_hcd :00:14.0: USB bus 1 deregistered >[1.316466] xhci_hcd :00:14.0: can't derive routing for PCI INT A >[1.316467] xhci_hcd :00:14.0: init :00:14.0 fail, -22 >[1.316505] xhci_hcd: probe of :00:14.0 failed with error -22 > >Full dmesg, lspci, lsusb and lsmod can be found here: >http://artipc10.vub.ac.be/~frederik/uefi-xhci/ > >I found this report about the same problem on a HP Probook system: >https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072918 I have the same problem (HP Elitebook 8570p in my case). This thread seems related: https://lkml.org/lkml/2012/2/13/453 No idea what happened to the patches in that thread though... -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] coredump: use a freezable_schedule for the coredump_finish wait
On 02/16, Mandeep Singh Baines wrote: > > @@ -483,7 +484,7 @@ static void exit_mm(struct task_struct * tsk) > set_task_state(tsk, TASK_UNINTERRUPTIBLE); > if (!self.task) /* see coredump_finish() */ > break; > - schedule(); > + freezable_schedule(); I think this particular change is fine in any case, no matter what else will we do. Acked-by: Oleg Nesterov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] freezer: clear fake signal on exit from __refrigerator
Forgot to mention... On 02/16, Oleg Nesterov wrote: > On 02/16, Mandeep Singh Baines wrote: > > > > --- a/kernel/freezer.c > > +++ b/kernel/freezer.c > > @@ -81,6 +81,9 @@ bool __refrigerator(bool check_kthr_stop) > > */ > > set_current_state(save); > > > > + /* Clear fake signal from freeze_task(). */ > > + recalc_sigpending(); > > NACK. We can't do this lockless. > > And I am not sure we should reinstantiate it here. And note that with the fix I propose in reply to 5/5 this change is not needed. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] coredump: ignore non-fatal signals when core dumping to a pipe
On 02/16, Mandeep Singh Baines wrote:
>
> Make wait_for_dump_helpers() not abort piping the core dump data when the
> crashing process has received a non-fatal signal. The abort still occurs
> in the case of SIGKILL.
>
> Testing:
>
> localhost ~ # echo "|/usr/bin/sleep 1d" > /proc/sys/kernel/core_pattern
> localhost ~ # sleep 1d &
As I already said, this is not enough. And if we change send_signal() paths
to "ignore" the non-fatal signals sent to the dumping process (and I think
we should do this anyway), this change is not needed.
Except we have other problems with the freezer.
> +static int sigkill_pending(struct task_struct *tsk)
> +{
> + return signal_pending(tsk) &&
> + (sigismember(&tsk->pending.signal, SIGKILL) ||
> + sigismember(&tsk->signal->shared_pending.signal, SIGKILL));
> +}
Why? __fatal_signal_pending() is enough, you do not need to check
->shared_pending. And once again, ignoring the freezer problems I
do not think we need this check at all.
IOW. Yes, we will probably need to do this change but only to be
freezer-friendly.
> static void wait_for_dump_helpers(struct file *file)
> {
> struct pipe_inode_info *pipe;
> + sigset_t blocked, previous;
> +
> + /* Block all but fatal signals. */
> + siginitsetinv(&blocked, sigmask(SIGKILL));
> + sigprocmask(SIG_BLOCK, &blocked, &previous);
(sigprocmask() must die, please never use, we have set_current_blocked().
Although in this particular case this doesn't matter...)
Heh. When I suggested this change a looong ago, my attempt was NACK'ed
because the core handler looks at /proc/pid/status.
If we could do this, we could simply ignore all signals except SIGKILL
at the start, in zap_threads(). This could solve almost all problems
with the signals/SIGKILL.
But see above, we can't.
Anyway. Please look at the patch below. I need to recheck it, and I was
going to send it later, along with other changes I am _trying_ to do. But
if it is correct, it looks certainly better and perhaps it can go ahead.
Afaics it could equally fix the mentioned problems (again, if correct ;).
"equally" also means it is equally incomplete.
Oleg.
--- x/fs/coredump.c
+++ x/fs/coredump.c
@@ -416,17 +416,17 @@ static void wait_for_dump_helpers(struct
pipe_lock(pipe);
pipe->readers++;
pipe->writers--;
+ // TODO: wake_up_interruptible_sync_poll ?
+ wake_up_interruptible_sync(&pipe->wait);
+ kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
+ pipe_unlock(pipe);
- while ((pipe->readers > 1) && (!signal_pending(current))) {
- wake_up_interruptible_sync(&pipe->wait);
- kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
- pipe_wait(pipe);
- }
+ wait_event_freezekillable(&pipe->wait, pipe->readers == 1);
+ pipe_lock(pipe);
pipe->readers--;
pipe->writers++;
pipe_unlock(pipe);
-
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] freezer: clear fake signal on exit from __refrigerator
On 02/16, Mandeep Singh Baines wrote: > > --- a/kernel/freezer.c > +++ b/kernel/freezer.c > @@ -81,6 +81,9 @@ bool __refrigerator(bool check_kthr_stop) >*/ > set_current_state(save); > > + /* Clear fake signal from freeze_task(). */ > + recalc_sigpending(); NACK. We can't do this lockless. And I am not sure we should reinstantiate it here. The coredumping is "special". It is not a kernel thread, but it does a lot of in-kernel activity and never returns to user-mode. If it play games with the freezer, perhaps it should take care itself... Tejun? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] vfork: don't freezer_count() for in-kernel users of CLONE_VFORK
On 02/16, Mandeep Singh Baines wrote:
>
> We don't need to call freezer_do_not_count() for in-kernel users
> of CLONE_VFORK since exec will get called in bounded time.
>
> We don't want to call freezer_count() for in-kernel users because
> they may be holding locks. freezer_count() calls try_to_freeze().
> We don't want to freeze an in-kernel user because it may be
> holding locks.
I can only repeat my question ;)
Who? We should not do this anyway. And __call_usermodehelper() doesn't
afaics.
OK, its caller (process_one_work) does lock_map_acquire() for debugging
purposes, this can "confuse" print_held_locks_bug(). But this thread is
PF_NOFREEZE ?
Previously this was needed to suppress the false positive. Now that 2/5
checks PF_NOFREEZE, why do we need this change?
> @@ -722,9 +722,11 @@ static int wait_for_vfork_done(struct task_struct *child,
> {
> int killed;
>
> - freezer_do_not_count();
> + if (!(current->flags & PF_KTHREAD))
> + freezer_do_not_count();
If I missed something and we really need this, imho this needs a comment.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
