Re: [PATCH v4 net-next 2/4] net: convert low latency sockets to sched_clock()
On 14/06/2013 06:12, Eric Dumazet wrote:
On Fri, 2013-06-14 at 04:57 +0300, Eliezer Tamir wrote:
Use sched_clock() instead of get_cycles().
We can use sched_clock() because we don't care much about accuracy.
Remove the dependency on X86_TSC
Signed-off-by: Eliezer Tamir eliezer.ta...@linux.intel.com
---
-static inline bool can_poll_ll(cycles_t end_time)
+static inline bool can_poll_ll(u64 end_time)
{
- return !time_after((unsigned long)get_cycles(),
+ return !time_after((unsigned long)sched_clock(),
(unsigned long)end_time);
}
I do not really understand why you bother to have 64bit wide values,
and then use these unsigned long casts here.
On 32bit arches, this will really limit to 2^31 ns range.
You should instead either :
- use time_after_64() or
- explicitly limit sysctl_net_ll_poll range
OK
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] sched: scale the busy and this queue's per-task load before compare
Since for max_load and this_load, they are the value that already be
scaled. It is not reasonble to get a minimum value between the scaled
and non-scaled value, like below example.
min(sds-busiest_load_per_task, sds-max_load);
Also add comment over in what condition, there would be cpu power gain
in move the load.
Signed-off-by: Lei Wen lei...@marvell.com
---
kernel/sched/fair.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 28052fa..77a149c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4692,7 +4692,7 @@ void fix_small_imbalance(struct lb_env *env, struct
sd_lb_stats *sds)
{
unsigned long tmp, pwr_now = 0, pwr_move = 0;
unsigned int imbn = 2;
- unsigned long scaled_busy_load_per_task;
+ unsigned long scaled_busy_load_per_task, scaled_this_load_per_task;
if (sds-this_nr_running) {
sds-this_load_per_task /= sds-this_nr_running;
@@ -4714,6 +4714,9 @@ void fix_small_imbalance(struct lb_env *env, struct
sd_lb_stats *sds)
return;
}
+ scaled_this_load_per_task = sds-this_load_per_task
+* SCHED_POWER_SCALE;
+ scaled_this_load_per_task /= sds-this-sgp-power;
/*
* OK, we don't have enough imbalance to justify moving tasks,
* however we may be able to increase total CPU power used by
@@ -4721,28 +4724,35 @@ void fix_small_imbalance(struct lb_env *env, struct
sd_lb_stats *sds)
*/
pwr_now += sds-busiest-sgp-power *
- min(sds-busiest_load_per_task, sds-max_load);
+ min(scaled_busy_load_per_task, sds-max_load);
pwr_now += sds-this-sgp-power *
- min(sds-this_load_per_task, sds-this_load);
+ min(scaled_this_load_per_task, sds-this_load);
pwr_now /= SCHED_POWER_SCALE;
/* Amount of load we'd subtract */
if (sds-max_load scaled_busy_load_per_task) {
pwr_move += sds-busiest-sgp-power *
- min(sds-busiest_load_per_task,
+ min(scaled_busy_load_per_task,
sds-max_load - scaled_busy_load_per_task);
- tmp = (sds-busiest_load_per_task * SCHED_POWER_SCALE) /
- sds-this-sgp-power;
+ tmp = scaled_busy_load_per_task;
} else
- tmp = (sds-max_load * sds-busiest-sgp-power) /
- sds-this-sgp-power;
+ tmp = sds-max_load;
+ /* Scale to this queue from busiest queue */
+ tmp = (tmp * sds-busiest-sgp-power) /
+ sds-this-sgp-power;
/* Amount of load we'd add */
pwr_move += sds-this-sgp-power *
- min(sds-this_load_per_task, sds-this_load + tmp);
+ min(scaled_this_load_per_task, sds-this_load + tmp);
pwr_move /= SCHED_POWER_SCALE;
/* Move if we gain throughput */
+ /*
+* The only possibilty for below statement be true, is:
+* sds-max_load is larger than scaled_busy_load_per_task, while,
+* scaled_this_load_per_task is larger than sds-this_load plus by
+* the scaled scaled_busy_load_per_task moved into this queue
+*/
if (pwr_move pwr_now)
env-imbalance = sds-busiest_load_per_task;
}
--
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: [Trivial PATCH 25/33] xfs: Convert use of typedef ctl_table to struct ctl_table
On Thu, Jun 13, 2013 at 10:33:26PM -0700, Joe Perches wrote: On Fri, 2013-06-14 at 15:21 +1000, Dave Chinner wrote: On Thu, Jun 13, 2013 at 07:37:50PM -0700, Joe Perches wrote: This typedef is unnecessary and should just be removed. Signed-off-by: Joe Perches j...@perches.com Looks fine, Joe. Acked-by: Dave Chinner dchin...@redhat.com How do you want us to handle this? Push it through the XFS tree or are you going to send it on up yourself? Hi Dave. I'd prefer you pick it up. These are all pretty trivial patches, but Jiri typically doesn't pick them up for months. I expect I'll have to resend whatever maintainers don't pick up in 6 months or so. No worries, I'll add it to my current 3.11 patchset. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] small fix for fix_small_imbalance
Here is two patches which correct the scale usage in the fix_small_balance, and give out comment over when fix_small_imbalance would cause load change. Lei Wen (2): sched: reduce calculation effort in fix_small_imbalance sched: scale the busy and this queue's per-task load before compare kernel/sched/fair.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) -- 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/
[PATCH 1/2] sched: reduce calculation effort in fix_small_imbalance
Actually all below item could be repalced by scaled_busy_load_per_task
(sds-busiest_load_per_task * SCHED_POWER_SCALE)
/sds-busiest-sgp-power;
Signed-off-by: Lei Wen lei...@marvell.com
---
kernel/sched/fair.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61a614..28052fa 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4727,20 +4727,17 @@ void fix_small_imbalance(struct lb_env *env, struct
sd_lb_stats *sds)
pwr_now /= SCHED_POWER_SCALE;
/* Amount of load we'd subtract */
- tmp = (sds-busiest_load_per_task * SCHED_POWER_SCALE) /
- sds-busiest-sgp-power;
- if (sds-max_load tmp)
+ if (sds-max_load scaled_busy_load_per_task) {
pwr_move += sds-busiest-sgp-power *
- min(sds-busiest_load_per_task, sds-max_load - tmp);
-
- /* Amount of load we'd add */
- if (sds-max_load * sds-busiest-sgp-power
- sds-busiest_load_per_task * SCHED_POWER_SCALE)
- tmp = (sds-max_load * sds-busiest-sgp-power) /
- sds-this-sgp-power;
- else
+ min(sds-busiest_load_per_task,
+ sds-max_load - scaled_busy_load_per_task);
tmp = (sds-busiest_load_per_task * SCHED_POWER_SCALE) /
sds-this-sgp-power;
+ } else
+ tmp = (sds-max_load * sds-busiest-sgp-power) /
+ sds-this-sgp-power;
+
+ /* Amount of load we'd add */
pwr_move += sds-this-sgp-power *
min(sds-this_load_per_task, sds-this_load + tmp);
pwr_move /= SCHED_POWER_SCALE;
--
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: hrtimer: one more expiry time overflow check in hrtimer_interrupt
Hello, On 6/12/2013 9:21 PM, Prarit Bhargava wrote: On 06/11/2013 03:41 AM, Shinya Kuribayashi wrote: [ 27.857330] hrtimer: interrupt took 0 ns ^^^ see below ... This may be because the frequency of our tick timer source in this system is very slow, it's 32768 Hz. I think it's not suitable for the high resolution timer at all, but we had no choice... And with this patch applied, diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index cdd5607..bc37552 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -1371,6 +1371,8 @@ retry: tick_program_event(expires_next, 1); printk_once(KERN_WARNING hrtimer: interrupt took %llu ns\n, ktime_to_ns(delta)); + printk_once(KERN_WARNING # now=%lld entry_time=%lld\n, ktime_to_ns(now), ktime_to_ns(entry_time)); + printk_once(KERN_WARNING # expires_next=%lld\n, ktime_to_ns(expires_next)); } /* I've got this: [ 22.857849] hrtimer: interrupt took 0 ns [ 22.861755] # now=-4294967273343634023 entry_time=-4294967273343634023 [ 22.868286] # expires_next=-4294967273343634023 now == entry_time == expires_next, and delta == 0. This means: 1) there haven't been no tick interrupts between 'entry_time' and 'now', 2) delta can be zero, 3) expires_next = ktime_add(now, delta) doesn't move expires_next forward. Ok, it's simply hrtimer is not supposed to work with such a slow timer source. However, this issue happens on other shmobile ARM systems with more faster tick timer source (10--13MHz), see below. @@ -1368,6 +1370,8 @@ retry: expires_next = ktime_add_ns(now, 100 * NSEC_PER_MSEC); else expires_next = ktime_add(now, delta); +if (expires_next.tv64 0) +expires_next.tv64 = KTIME_MAX; Even with this change you will still see the warning below if delta = 0. Correct. tick_program_event(expires_next, 1); printk_once(KERN_WARNING hrtimer: interrupt took %llu ns\n, ktime_to_ns(delta)); So I'm not sure that this is the correct thing to do. Is this reproducible on any ARM system? I'll grab an x86_64 box and give it a shot there too. Can you dump the values of now, delta, and expires_next when the printk_once triggers? It's 100% reproducible in our shmobile ARM kernels, v3.4 and v3.10-rc2. And it doesn't reproduce with v2.6.35-based kernels so far. Here're logs from Cortex-A15 UP/SMP systems. They're having ARM architected tiemrs (the Generic Timers, running at 10--13MHz) using as clocksource, clockevents, sched_clock, and read_current_timer (udelay) sources. - machine: R-Mobile APE6 (Cortex-A15 UP system - it's octo-core A15/A7 SoC, but not yet available in mainline) kernel : v3.10-rc2 mainline timer : the Generic Timers (arch/arm/kernel/arch_timer.c) running at 13MHz - |# uname -a |Linux arm 3.10.0-rc2-00966-gd658f9e #1284 Tue Jun 11 13:36:10 JST 2013 armv7l GNU/Linux |# cat /proc/timer_list |egrep Clock Event Device|event_handler |Clock Event Device: arch_sys_timer | event_handler: hrtimer_interrupt |# date -s 2038-1-19 3:14:00 |Tue Jan 19 03:14:00 UTC 2038 |# [ 138.942325] [ cut here ] |[ 138.946910] WARNING: at kernel/time/clockevents.c:209 clockevents_program_event+0x130/0x148() |[ 138.955315] Modules linked in: |[ 138.958339] CPU: 0 PID: 0 Comm: swapper Tainted: GW 3.10.0-rc2-00966-gd658f9e #1284 |[...] |[ 139.131970] ---[ end trace f879bec39a6bf85c ]--- |[ 139.136521] hrtimer: interrupt took 2385 ns - machine: R-Car H2 (quad-core Cortex-A15 SMP system) kernel : v3.4-based custom Android kernel timer : the Generic Timers (arch/arm/kernel/arch_timer.c) running at 10MHz - |root@renesas:~# date -s 2038-1-19 3:14:00 |Tue Jan 19 03:14:00 GMT 2038 |root@renesas:~# [ 26.458377] [ cut here ] |[ 26.472214] WARNING: at kernel/time/clockevents.c:209 clockevents_program_event+0x3c/0x138() |[...] |[ 26.980342] ---[ end trace 5218f4fd6603f493 ]--- |[ 26.994166] hrtimer: interrupt took 1900 ns |[ 27.006687] # now=-4294967269549995552 entry_time=-4294967269549997452 |[ 27.026240] # expires_next=-4294967269549993652 I also gave a try on my Ubuntu box, but it seems to work without printk_once() at the bottome of hrtimer_interrupt() printed, which means that hrtimer_update_base()-and-retries mechanism works as expected. $ uname -a Linux RI106878 3.2.0-45-generic #70-Ubuntu SMP Wed May 29 20:12:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I'd like to see whether this happens on other ARM machines excpet for shmobile. Could someone help, please? -- Shinya Kuribayashi Renesas Electronics -- To unsubscribe from this list: send the line
Re: [PATCH 1/4] ARM: cfa10036: Add USB0 OTG port
On Fri, Jun 14, 2013 at 12:06:51AM +0200, Arnd Bergmann wrote:
On Thursday 13 June 2013 15:43:42 Maxime Ripard wrote:
+
+ ahb@8008 {
+ usb0: usb@8008 {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_otg_cfa10036;
+ status = okay;
};
};
The patches all look good, just one trivial comment about the fragment above:
There is already a usb0 label in the imx28.dtsi file for the same
node. When you refer to the node from a board.dts file, either leave
out the redundant label, or use it to simplify the statements above
to the brief version:
usb0 {
pinctrl-names = default;
pinctrl-0 = usb0_otg_cfa10036;
status = okay;
};
Yeah, I moved all imx board level dts files to use this. But I was told
by Olof that the change does not gain too much and looks like a churn.
That's why I haven't made the same move for mxs. So I will remove the
redundant label when applying this patch.
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: Linux 2.6.32.61 - x86/ptrace/gcc 4.7 build error
Willy Tarreau wrote... I'm attaching the two patches here to be appled on top of 2.6.32.61, I would like it if you could try in your environment to confirm that they correctly fix the issue. Confirmation: Kernel builds and runs for both Debian squeeze and wheezy (gcc 4.4 and gcc 4.7) on i386. There are still other issues that need investigation but they might be older and/or related to changes on my end. virtio-net doesn't seem to work at all (but does so in the Debian squeeze 2.6.32 kernel), and the virtualbox guest module (4.1.18) fails to load (known issue on i386 if build using gcc 4.7, but know this also happens with gcc 4.4). Unfortunately my time ressources are very limited at the moment, and there's also something in 3.4.49 which has higher priority. Stay tuned. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
On 14/06/13 08:47, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [130613 22:41]: Hi, On Thursday 13 June 2013 06:35 PM, Tomi Valkeinen wrote: Hi, On 28/05/13 08:18, Kishon Vijay Abraham I wrote: Hi Tony, On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy label) should be added in the platform data of the controller. This series would be needed to get MUSB working in OMAP3 boards for non-dt boot case. Do you think this is good enough to go in this rc cycle? Did this or some other solution go forward? I'm still unable to boot with usb-gadget-ethernet with v3.10-rc5. No. I think Tony is ok to take this only during next merge window. Yes I'll apply them to omap-for-v3.11/fixes-non-critical. We really should have basic functionaly tested and working always before the merge window so we only need to do minimal fixes during the -rc cycle. I'm mostly interested in the USB gadget ethernet for the boards I have, but if I'm not mistaken, all USB gadget support for many OMAP boards is broken in v3.10. Shouldn't that be fixed, no matter if it's a minimal fix or not? Or is there some other, more minimal, way to fix this? Tomi signature.asc Description: OpenPGP digital signature
Re: Linux 2.6.32.61 - x86/ptrace/gcc 4.7 build error
Hi Christoph, On Fri, Jun 14, 2013 at 08:23:18AM +0200, Christoph Biedl wrote: Willy Tarreau wrote... I'm attaching the two patches here to be appled on top of 2.6.32.61, I would like it if you could try in your environment to confirm that they correctly fix the issue. Confirmation: Kernel builds and runs for both Debian squeeze and wheezy (gcc 4.4 and gcc 4.7) on i386. There are still other issues that need investigation but they might be older and/or related to changes on my end. virtio-net doesn't seem to work at all (but does so in the Debian squeeze 2.6.32 kernel), and the virtualbox guest module (4.1.18) fails to load (known issue on i386 if build using gcc 4.7, but know this also happens with gcc 4.4). Thanks for your report. Do you know if the issues you get are regressions from 2.6.32.60 or just compared to the Debian kernel ? Willy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
On 06/10/2013 07:01 AM, Matthew Garrett wrote: Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems. Signed-off-by: Matthew Garrett matthew.garr...@nebula.com --- drivers/gpu/drm/i915/i915_dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3b315ba..23b6292 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) /* Must be done after probing outputs */ intel_opregion_init(dev); acpi_video_register(); + /* Don't use ACPI backlight functions on Windows 8 platforms */ + if (acpi_osi_version() = ACPI_OSI_WIN_8) + acpi_video_backlight_unregister(); What about the platform driver created backlight interface? Oh right, thinkpad_acpi will not create backlight interface for them since they are not in DMI table, so acpi_video_backlight_support() will return true and thinkspad_acpi thinks ACPI video driver is controlling backlight so it will not create backlight interface for them. Then we will need to remember not to add any of those systems into the DMI table of video_detect.c, or thinkpad_acpi module will create backlight interface for them and according to reporter, that interface does not work either. What about a priority based solution? We can introduce a new field named priority to backlight_device and instead of calling another module's function like the unregister one here(which cause unnecessary module dependency), we only need to boost priority for its own interface. This field will be exported to sysfs, so user can change it during runtime too. And we can also introduce a new kernel command line as backlight.force_interface=raw/firmware/platform, to overcome the limited functionality provided by acpi_backlight=video/vendor, which does not involve GPU's interface. And we can place the quirk code in backlight layer instead of individual backlight functionality provider module. Suppose we have a backlight manager there, for all win8 systems, we can boost the raw type's priority on its registration, so no need to add code in intel/amd/etc./'s GPU driver code. With priority based solution, all backlight control interfaces stay, the priority field is an indication given by kernel to user space. For a complete description on backlight control background and the proposed solution, please take a look at: https://gist.github.com/aaronlu/5779828 It would be good to know your opinions, thanks. -Aaron -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: cfa10036: Add USB0 OTG port
On Fri, Jun 14, 2013 at 02:30:53PM +0800, Shawn Guo wrote:
On Fri, Jun 14, 2013 at 12:06:51AM +0200, Arnd Bergmann wrote:
On Thursday 13 June 2013 15:43:42 Maxime Ripard wrote:
+
+ ahb@8008 {
+ usb0: usb@8008 {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_otg_cfa10036;
+ status = okay;
};
};
The patches all look good, just one trivial comment about the fragment
above:
There is already a usb0 label in the imx28.dtsi file for the same
node. When you refer to the node from a board.dts file, either leave
out the redundant label, or use it to simplify the statements above
to the brief version:
usb0 {
pinctrl-names = default;
pinctrl-0 = usb0_otg_cfa10036;
status = okay;
};
Yeah, I moved all imx board level dts files to use this. But I was told
by Olof that the change does not gain too much and looks like a churn.
That's why I haven't made the same move for mxs. So I will remove the
redundant label when applying this patch.
I would have the label stay there, because I found it's there like a
comment telling the controller instance.
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: [PATCH 0/4] ARM: mxs: Various Crystalfontz DT additions
On Thu, Jun 13, 2013 at 03:43:41PM +0200, Maxime Ripard wrote: Brian Lilly (3): ARM: cfa10049: Switch the chip select pin of the LCD controller ARM: mxs: dt: Add the Crystalfontz CFA-10055 device tree ARM: mxs: dt: Add Crystalfontz CFA-10057 device tree Maxime Ripard (1): ARM: cfa10036: Add USB0 OTG port All applied, 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: A bug about system call on ARM
Hi Will, We have tested the patch, It seems ok in the stability test . We have merged it into our main branch . Thanks for your patch ! -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Monday, June 03, 2013 5:54 PM To: Wang, Yalin Cc: 'richard -rw- weinberger'; 'linux-a...@vger.kernel.org'; 'linux-kernel@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org' Subject: Re: A bug about system call on ARM On Mon, Jun 03, 2013 at 06:25:26AM +0100, Wang, Yalin wrote: Hi Will, I have a question about this patch . If the user space is thumb mode, The PC should be rewind by 2 bytes, So the fix_up code should be Sub lr, lr, #2 . Am I right ? No, because we don't have OABI-compat support for Thumb applications and force everything down the EABI path instead. Did you manage to test the patch? Will -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ipv4: Fixed MD5 key lookups when adding/ removing MD5 to/ from TCP sockets.
MD5 key lookups on a given TCP socket were being performed
incorrectly. This fix alters parameter inputs to the MD5
lookup function tcp_md5_do_lookup, which is called by functions
tcp_md5_do_add and tcp_md5_do_del. Specifically, the change now
inputs the correct address and address family required to make
a proper lookup.
Signed-off-by: Aydin Arik aydin.a...@alliedtelesis.co.nz
---
net/ipv4/tcp_ipv4.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index d09203c..04dfdc9 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1005,7 +1005,7 @@ int tcp_md5_do_add(struct sock *sk, const union
tcp_md5_addr *addr,
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_md5sig_info *md5sig;
- key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, AF_INET);
+ key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, family);
if (key) {
/* Pre-existing entry - just update that one. */
memcpy(key-key, newkey, newkeylen);
@@ -1050,7 +1050,7 @@ int tcp_md5_do_del(struct sock *sk, const union
tcp_md5_addr *addr, int family)
struct tcp_md5sig_key *key;
struct tcp_md5sig_info *md5sig;
- key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, AF_INET);
+ key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, family);
if (!key)
return -ENOENT;
hlist_del_rcu(key-node);
--
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 Resend 1/1] mfd: davinci_voicecodec: Convert to use devm_* APIs
On Fri, 14 Jun 2013, Sachin Kamat wrote: Hi Lee, On 13 June 2013 16:19, Lee Jones lee.jo...@linaro.org wrote: On Wed, 12 Jun 2013, Sachin Kamat wrote: devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Miguel Aguilar miguel.agui...@ridgerun.com --- CC'd Lee Jones Can you resubmit this based on -rc5 please? There have been some related changes since you wrote this patch. This patch is based on Samuel's mfd-next tree [1]. This patch is dependent on your patch mfd: davinci_voicecodec: Convert to managed resources for allocating memory which is applied in mfd-next. Please let me know which other tree you want me to rebase this patch on considering the dependency. [1] http://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git I believe Sam's branch has been updated considerably since you wrote the patch. Would you mind rebasing it onto Sam's latest master branch please? Should be commit: d8c5d658f425bd25bbfb137f2617f59ed4fdee7d. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 RFC ticketlock] v3 Auto-queued ticketlock
On 06/14/2013 07:57 AM, Paul E. McKenney wrote: On Fri, Jun 14, 2013 at 07:25:57AM +0800, Lai Jiangshan wrote: On Thu, Jun 13, 2013 at 11:22 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Thu, Jun 13, 2013 at 10:55:41AM +0800, Lai Jiangshan wrote: On 06/12/2013 11:40 PM, Paul E. McKenney wrote: Breaking up locks is better than implementing high-contention locks, but if we must have high-contention locks, why not make them automatically switch between light-weight ticket locks at low contention and queued locks at high contention? After all, this would remove the need for the developer to predict which locks will be highly contended. This commit allows ticket locks to automatically switch between pure ticketlock and queued-lock operation as needed. If too many CPUs are spinning on a given ticket lock, a queue structure will be allocated and the lock will switch to queued-lock operation. When the lock becomes free, it will switch back into ticketlock operation. The low-order bit of the head counter is used to indicate that the lock is in queued mode, which forces an unconditional mismatch between the head and tail counters. This approach means that the common-case code path under conditions of low contention is very nearly that of a plain ticket lock. A fixed number of queueing structures is statically allocated in an array. The ticket-lock address is used to hash into an initial element, but if that element is already in use, it moves to the next element. If the entire array is already in use, continue to spin in ticket mode. Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com [ paulmck: Eliminate duplicate code and update comments (Steven Rostedt). ] [ paulmck: Address Eric Dumazet review feedback. ] [ paulmck: Use Lai Jiangshan idea to eliminate smp_mb(). ] [ paulmck: Expand -head_tkt from s32 to s64 (Waiman Long). ] [ paulmck: Move cpu_relax() to main spin loop (Steven Rostedt). ] [ paulmck: Reduce queue-switch contention (Waiman Long). ] [ paulmck: __TKT_SPIN_INC for __ticket_spin_trylock() (Steffen Persvold). ] [ paulmck: Type safety fixes (Steven Rostedt). ] [ paulmck: Pre-check cmpxchg() value (Waiman Long). ] [ paulmck: smp_mb() downgrade to smp_wmb() (Lai Jiangshan). ] Hi, Paul, I simplify the code and remove the search by encoding the index of struct tkt_q_head into lock-tickets.head. A) lock-tickets.head(when queued-lock): - index of struct tkt_q_head |0|1| - Interesting approach! It might reduce queued-mode overhead a bit in some cases, though I bet that in the common case the first queue element examined is the right one. More on this below. The bit0 = 1 for queued, and the bit1 = 0 is reserved for __ticket_spin_unlock(), thus __ticket_spin_unlock() will not change the higher bits of lock-tickets.head. B) tqhp-head is for the real value of lock-tickets.head. if the last bit of tqhp-head is 1, it means it is the head ticket when started queuing. But don't you also need the xadd() in __ticket_spin_unlock() to become a cmpxchg() for this to work? Or is your patch missing your changes to arch/x86/include/asm/spinlock.h? Either way, this is likely to increase the no-contention overhead, which might be counterproductive. Wouldn't hurt to get measurements, though. No, don't need to change __ticket_spin_unlock() in my idea. bit1 in the tickets.head is reserved for __ticket_spin_unlock(), __ticket_spin_unlock() only changes the bit1, it will not change the higher bits. tkt_q_do_wake() will restore the tickets.head. This approach avoids cmpxchg in __ticket_spin_unlock(). Ah, I did miss that. But doesn't the adjustment in __ticket_spin_lock() need to be atomic in order to handle concurrent invocations of __ticket_spin_lock()? Either way, it would be good to see the performance effects of this. Thanx, Paul Given the results that Davidlohr posted, I believe that the following optimizations would also provide some improvement: 1. Move the call to tkt_spin_pass() from __ticket_spin_lock() to a separate linker section in order to reduce the icache penalty exacted by the spinloop. This is likely to be causing some of the performance reductions in the cases where ticket locks are not highly contended. 2. Limit the number of elements searched for in the array of queues. However, this would help only if a number of ticket locks were in queued mode at the same time. 3. Dynamically allocate the queue array at boot. This might also reduce cache pressure, again, at least in cases where there are a number of ticket locks in queued mode at the same time. Frederic just reminded me that I owe him some energy-efficiency improvements for adaptive ticks, so I won't get to
[PATCH v2] extcon: Add an API to get extcon device from dt node
From: Kishon Vijay Abraham I kis...@ti.com
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes since v1:
- If edev-name is NULL, dev_name(dev) is used as edev-name.
- Change filename from of-extcon.* to of_extcon.*
- Fix build error when CONFIG_OF is not set
- Add header file(linux/err.h) to of_extcon.c
drivers/extcon/Makefile | 2 ++
drivers/extcon/extcon-class.c| 3 +-
drivers/extcon/of_extcon.c | 64
include/linux/extcon/of_extcon.h | 30 +++
4 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/extcon/of_extcon.c
create mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..83468f7 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,6 +2,8 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF) += of_extcon.o
+
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 23f11ea..08509ea 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -602,7 +602,8 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
edev-dev-class = extcon_class;
edev-dev-release = extcon_dev_release;
- dev_set_name(edev-dev, edev-name ? edev-name : dev_name(dev));
+ edev-name = edev-name ? edev-name : dev_name(dev);
+ dev_set_name(edev-dev, edev-name);
if (edev-max_supported) {
char buf[10];
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
new file mode 100644
index 000..72173ec
--- /dev/null
+++ b/drivers/extcon/of_extcon.c
@@ -0,0 +1,64 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of_extcon.h
+
+/*
+ * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_dbg(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, unable to find device by node\n);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
+ if (!edev) {
+ dev_dbg(dev, unable to get extcon device : %s\n,
+ dev_name(extcon_parent_dev-dev));
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of_extcon.h b/include/linux/extcon/of_extcon.h
new file mode 100644
index 000..462f071
--- /dev/null
+++ b/include/linux/extcon/of_extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_OF_EXTCON_H
+#define __LINUX_OF_EXTCON_H
+
+#if
Re: [PATCH v2 07/11] ARM:stixxxx: Add STiH416 SOC support
On 10/06/13 14:52, Arnd Bergmann wrote:
On Monday 10 June 2013 10:27:05 Srinivas KANDAGATLA wrote:
+ soc {
+ pin-controller-sbc {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,stih416-pinctrl, simple-bus;
Why is this both its own device with a compatible string and a
simple-bus at the same time? Wouldn't it be simpler to just
scan the child device nodes from the st,stih416-pinctrl
driver instead of having a separate platform_driver for them?
I did try this suggestion, and it simplified driver too, I will do this
change in next version.
Thanks,
srini
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] Add pin list based GPIO ranges
On 06/13/2013 02:55 PM, Christian Ruppert wrote:
Traditionally, GPIO ranges are based on consecutive ranges of both GPIO
and pin numbers. This patch allows for GPIO ranges with arbitrary lists
of pin numbers.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
---
drivers/pinctrl/core.c | 59 --
include/linux/pinctrl/pinctrl.h |4 ++-
2 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 5327f35..25bb17e 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -280,6 +280,29 @@ static int pinctrl_register_pins(struct pinctrl_dev
*pctldev,
}
/**
+ * gpio_to_pin() - GPIO range GPIO number to pin number translation
+ * @range: GPIO range used for the translation
+ * @gpio: gpio pin to translate to a pin number
+ *
+ * Finds the pin number for a given GPIO using the specified GPIO range
+ * as a base for translation. The distinction between linear GPIO ranges
+ * and pin list based GPIO ranges is managed correctly by this function.
+ *
+ * This function assumes the gpio is part of the specified GPIO range, use
+ * only after making sure this is the case (e.g. by calling it on the
+ * result of successful pinctrl_get_device_gpio_range calls)!
+ */
+static inline int gpio_to_pin(struct pinctrl_gpio_range *range,
+ unsigned int gpio)
+{
+ unsigned int offset = gpio - range-base;
+ if (range-pins)
+ return range-pins[offset];
+ else
+ return range-pin_base + offset;
+}
+
+/**
* pinctrl_match_gpio_range() - check if a certain GPIO pin is in range
* @pctldev: pin controller device to check
* @gpio: gpio pin to check taken from the global GPIO pin space
@@ -444,8 +467,14 @@ pinctrl_find_gpio_range_from_pin(struct pinctrl_dev
*pctldev,
/* Loop over the ranges */
list_for_each_entry(range, pctldev-gpio_ranges, node) {
/* Check if we're in the valid range */
- if (pin = range-pin_base
- pin range-pin_base + range-npins) {
+ if (range-pins) {
+ int a;
+ for (a = 0; a range-npins; a++) {
+ if (range-pins[a] == pin)
+ return range;
+ }
+ } else if (pin = range-pin_base
+pin range-pin_base + range-npins) {
mutex_unlock(pctldev-mutex);
return range;
}
@@ -528,7 +557,7 @@ int pinctrl_request_gpio(unsigned gpio)
}
/* Convert to the pin controllers number space */
- pin = gpio - range-base + range-pin_base;
+ pin = gpio_to_pin(range, gpio);
ret = pinmux_request_gpio(pctldev, range, pin, gpio);
@@ -562,7 +591,7 @@ void pinctrl_free_gpio(unsigned gpio)
mutex_lock(pctldev-mutex);
/* Convert to the pin controllers number space */
- pin = gpio - range-base + range-pin_base;
+ pin = gpio_to_pin(range, gpio);
pinmux_free_gpio(pctldev, pin, range);
@@ -589,7 +618,7 @@ static int pinctrl_gpio_direction(unsigned gpio, bool
input)
mutex_lock(pctldev-mutex);
/* Convert to the pin controllers number space */
- pin = gpio - range-base + range-pin_base;
+ pin = gpio_to_pin(range, gpio);
ret = pinmux_gpio_direction(pctldev, range, pin, input);
mutex_unlock(pctldev-mutex);
@@ -1296,11 +1325,21 @@ static int pinctrl_gpioranges_show(struct seq_file
*s, void *what)
/* Loop over the ranges */
list_for_each_entry(range, pctldev-gpio_ranges, node) {
- seq_printf(s, %u: %s GPIOS [%u - %u] PINS [%u - %u]\n,
-range-id, range-name,
-range-base, (range-base + range-npins - 1),
-range-pin_base,
-(range-pin_base + range-npins - 1));
+ if (range-pins) {
+ int a;
+ seq_printf(s, %u: %s GPIOS [%u - %u] PINS {,
+ range-id, range-name,
+ range-base, (range-base + range-npins - 1));
+ for (a = 0; a range-npins - 1; a++)
+ seq_printf(s, %u, , range-pins[a]);
+ seq_printf(s, %u}\n, range-pins[a]);
+ }
+ else
+ seq_printf(s, %u: %s GPIOS [%u - %u] PINS [%u - %u]\n,
+ range-id, range-name,
+ range-base, (range-base + range-npins - 1),
+ range-pin_base,
+ (range-pin_base + range-npins - 1));
}
mutex_unlock(pctldev-mutex);
diff --git a/include/linux/pinctrl/pinctrl.h
Re: [PATCH] extcon: class: Add NULL pointer checking for removing notifier block.
On 06/14/2013 11:11 AM, Jonghwa Lee wrote:
This patch adds NULL pointer checking of extcon device to 'extcon_unregister
_interest' which unregisters extcon notifier block.
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/extcon/extcon-class.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 8c69803..23f11ea 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -491,7 +491,7 @@ EXPORT_SYMBOL_GPL(extcon_register_interest);
*/
int extcon_unregister_interest(struct extcon_specific_cable_nb *obj)
{
- if (!obj)
+ if (!obj || !obj-edev)
return -EINVAL;
return raw_notifier_chain_unregister(obj-edev-nh, obj-internal_nb);
Applied it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/1] ipv4: Fixed MD5 key lookups when adding/ removing MD5 to/ from TCP sockets.
On Fri, 2013-06-14 at 18:56 +1200, Aydin Arik wrote:
MD5 key lookups on a given TCP socket were being performed
incorrectly. This fix alters parameter inputs to the MD5
lookup function tcp_md5_do_lookup, which is called by functions
tcp_md5_do_add and tcp_md5_do_del. Specifically, the change now
inputs the correct address and address family required to make
a proper lookup.
Signed-off-by: Aydin Arik aydin.a...@alliedtelesis.co.nz
---
net/ipv4/tcp_ipv4.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index d09203c..04dfdc9 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1005,7 +1005,7 @@ int tcp_md5_do_add(struct sock *sk, const union
tcp_md5_addr *addr,
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_md5sig_info *md5sig;
- key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, AF_INET);
+ key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, family);
if (key) {
/* Pre-existing entry - just update that one. */
memcpy(key-key, newkey, newkeylen);
@@ -1050,7 +1050,7 @@ int tcp_md5_do_del(struct sock *sk, const union
tcp_md5_addr *addr, int family)
struct tcp_md5sig_key *key;
struct tcp_md5sig_info *md5sig;
- key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, AF_INET);
+ key = tcp_md5_do_lookup(sk, (union tcp_md5_addr *)addr, family);
if (!key)
return -ENOENT;
hlist_del_rcu(key-node);
Good catch !
Could you remove the casts (union tcp_md5_addr *) as well ?
And please add in the changelog the bug origin to ease stable
submissions :
commit a915da9b69273815527ccb3789421cb7027b545b
(tcp: md5: rcu conversion)
Thanks !
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/14] perf: Add persistent event facilities
On 14.06.13 11:15:13, Namhyung Kim wrote:
+int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr
*attr)
+{
+ struct pers_event_desc *desc;
+
+ if (cpu = (unsigned)nr_cpu_ids)
+ return -EINVAL;
+
+ list_for_each_entry(desc, per_cpu(pers_events, cpu), plist)
+ if (desc-attr-config == attr-config)
+ return __alloc_persistent_event_fd(desc);
+
So it only supports tracepoint events. Don't we need to add other types
of event?
We have choosen tracepoints as initial implementation since they are
our first use case and its specifiers are unique already.
So this is for the initial implementation only. We can easily
implement support for other event types later. The only thing we need
to implement for this are unique identifiers for each persistent
event. Since all events are described in sysfs this change can be done
later without changing ABI or breaking userland.
The support for all event types is definitely on our list. We need
this also for a later implemention of registering all system wide
events as persistent events. This allows sharing events between
processes and is one of Ingos use cases to enable persistent events at
runtime.
-Robert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/4] perf tools: Retry mapping buffers readonly on EACCES
On 14.06.13 11:08:40, Namhyung Kim wrote:
- if (perf_evlist__mmap(evlist, opts-mmap_pages, false) 0) {
+try_again2:
+ if (perf_evlist__mmap(evlist, opts-mmap_pages, opts-mmap_ro) 0) {
+ if (!opts-mmap_ro errno == EACCES) {
+ opts-mmap_ro = true;
+ goto try_again2;
+ }
ui__error(Failed to mmap with %d (%s)\n,
errno, strerror(errno));
goto out_err;
You will need this also:
@@ -161,7 +161,8 @@ static int perf_record__mmap_read(struct perf_record *rec,
}
md-prev = old;
- perf_mmap__write_tail(md, old);
+ if (!rec-opts.mmap_ro)
+ perf_mmap__write_tail(md, old);
out:
return rc;
Yes, indeed. Will add your change
-Robert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: i2c: introduce i2c helper i2c_find_client_by_name()
On Tue, Jun 11, 2013 at 8:11 PM, Bin Gao bin@linux.intel.com wrote: On Sun, Jun 09, 2013 at 10:53:35PM +0300, Andy Shevchenko wrote: Please, try to avoid top posting in the future emails. On Fri, Jun 7, 2013 at 12:26 AM, Bin Gao bin@linux.intel.com wrote: With v4l2, the camera sensor i2c devices are taken over by v4l2 master driver, i.e. ISP driver, and are not expected to be accessed from user sapce by ioctl. So ISP driver has to register them by itself to get all related information for further communication. Please check v4l2_i2c_new_subdev_board() in drivers/media/video/v4l2-common.c for details. Yes, this is legacy approach for non-DT/non-ACPI5 platforms. So what's the new approach for DT/ACPI5 platforms? When DT or ACPI5 is enabled and used the devices are enumerated through corresponding frameworks in the kernel automatically. So, you get them initialized just after i2c host. The platform code can definitely disallow calling i2c_register_board_info() to register them but keep the i2c devices list and then let ISP driver register them. But, problems come when a single kernel is going to run on two platforms - one platform has ACPI5 and the other has SFI. You have to forget about SFI. Your ISP subdevices use plain platform data anyway. Why have to forget about SFI which is supported by upstream kernel? It doesn't matter. Second sentence above is explained why. SFI, unfortunately, has few design flaws, that's why the information located there is not much useful in ISP case. In ACPI 5 case v4l2 framework must be extended to cover that case. To extend v4l2 framework is one of the options, That is proper option. but this helper is also one option. I think this helper doesn't align to the current workflow. The dynamic unregister and then register based on this new helper will not have dependency on firmware interface - the same platform code will work for all platforms. It's not a care of the ISP driver. I think you have to talk to Sakari about your issues. We have to do it in the ISP driver if we want one binary kernel supporting multiple platforms. What I'm talking about is not contradicting with that. A good example is that an ISP(Imaging Signal Processor) driver needs register i2c camera sensor devices via v4l2, so it has to unregister all i2c clients that were previously registered by calling i2c_register_board_info(), and then re-register. Why do you need to re-register them at run time? Still this question is not answered. -- 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 2/2] netns: exclude ipvs from struct net when IPVS disabled
From: JunweiZhang junwei.zh...@6wind.com
no real problem is fixed, just save a few bytes in
net_namespace structure.
Signed-off-by: JunweiZhang junwei.zh...@6wind.com
Signed-off-by: Nicolas Dichtel nicolas.dich...@6wind.com
---
include/net/net_namespace.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index b176978..c2bf266 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -115,7 +115,9 @@ struct net {
#ifdef CONFIG_XFRM
struct netns_xfrm xfrm;
#endif
+#if IS_ENABLED(CONFIG_IP_VS)
struct netns_ipvs *ipvs;
+#endif
struct sock *diag_nlsk;
atomic_trt_genid;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] kernel: remove unnecessary head file
From: JunweiZhang junwei.zh...@6wind.com ip_vs.h is not necessary for sysctl_binary.c. prepare for the next patch to avoid compile issue. Signed-off-by: JunweiZhang junwei.zh...@6wind.com Signed-off-by: Nicolas Dichtel nicolas.dich...@6wind.com --- kernel/sysctl_binary.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c index aea4a9e..b609213 100644 --- a/kernel/sysctl_binary.c +++ b/kernel/sysctl_binary.c @@ -3,7 +3,6 @@ #include ../fs/xfs/xfs_sysctl.h #include linux/sunrpc/debug.h #include linux/string.h -#include net/ip_vs.h #include linux/syscalls.h #include linux/namei.h #include linux/mount.h -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] mm/writeback: Don't check force_wait to handle bdi-work_list
After commit 839a8e86(writeback: replace custom worker pool implementation
with unbound workqueue), bdi_writeback_workfn runs off bdi_writeback-dwork,
on each execution, it processes bdi-work_list and reschedules if there are
more things to do instead of flush any work that race with us existing. It is
unecessary to check force_wait in wb_do_writeback since it is always 0 after
the mentioned commit. This patch remove the force_wait in wb_do_writeback.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
fs/fs-writeback.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index f892dec..e15aa97 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -959,7 +959,7 @@ static long wb_check_old_data_flush(struct bdi_writeback
*wb)
/*
* Retrieve work items and do the writeback they describe
*/
-static long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
+static long wb_do_writeback(struct bdi_writeback *wb)
{
struct backing_dev_info *bdi = wb-bdi;
struct wb_writeback_work *work;
@@ -967,12 +967,6 @@ static long wb_do_writeback(struct bdi_writeback *wb, int
force_wait)
set_bit(BDI_writeback_running, wb-bdi-state);
while ((work = get_next_work_item(bdi)) != NULL) {
- /*
-* Override sync mode, in case we must wait for completion
-* because this thread is exiting now.
-*/
- if (force_wait)
- work-sync_mode = WB_SYNC_ALL;
trace_writeback_exec(bdi, work);
@@ -1021,7 +1015,7 @@ void bdi_writeback_workfn(struct work_struct *work)
* rescuer as work_list needs to be drained.
*/
do {
- pages_written = wb_do_writeback(wb, 0);
+ pages_written = wb_do_writeback(wb);
trace_writeback_pages_written(pages_written);
} while (!list_empty(bdi-work_list));
} else {
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] mm/thp: fix doc for transparent huge zero page
Transparent huge zero page is used during the page fault instead of in khugepaged. # ls /sys/kernel/mm/transparent_hugepage/ defrag enabled khugepaged use_zero_page # ls /sys/kernel/mm/transparent_hugepage/khugepaged/ alloc_sleep_millisecs defrag full_scans max_ptes_none pages_collapsed pages_to_scan scan_sleep_millisecs This patch corrects the documentation just like the codes done. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com --- Documentation/vm/transhuge.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt index 8785fb8..4a63953 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -120,8 +120,8 @@ By default kernel tries to use huge zero page on read page fault. It's possible to disable huge zero page by writing 0 or enable it back by writing 1: -echo 0 /sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page -echo 1 /sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page +echo 0 /sys/kernel/mm/transparent_hugepage/use_zero_page +echo 1 /sys/kernel/mm/transparent_hugepage/use_zero_page khugepaged will be automatically started when transparent_hugepage/enabled is set to always or madvise, and it'll -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] mm/writeback: fix wb_do_writeback exported unsafely
There is just one caller in fs-writeback.c call wb_do_writeback and
current codes unnecessary export it in header file, this patch fix
it by changing wb_do_writeback to static function.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
fs/fs-writeback.c | 2 +-
include/linux/writeback.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 3be5718..f892dec 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -959,7 +959,7 @@ static long wb_check_old_data_flush(struct bdi_writeback
*wb)
/*
* Retrieve work items and do the writeback they describe
*/
-long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
+static long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
{
struct backing_dev_info *bdi = wb-bdi;
struct wb_writeback_work *work;
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 579a500..e27468e 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -94,7 +94,6 @@ int try_to_writeback_inodes_sb_nr(struct super_block *,
unsigned long nr,
void sync_inodes_sb(struct super_block *);
long writeback_inodes_wb(struct bdi_writeback *wb, long nr_pages,
enum wb_reason reason);
-long wb_do_writeback(struct bdi_writeback *wb, int force_wait);
void wakeup_flusher_threads(long nr_pages, enum wb_reason reason);
void inode_wait_for_writeback(struct inode *inode);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] mm/pgtable: Don't accumulate addr during pgd prepopulate pmd
The old codes accumulate addr to get right pmd, however,
currently pmds are preallocated and transfered as a parameter,
there is unnecessary to accumulate addr variable any more, this
patch remove it.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
arch/x86/mm/pgtable.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 17fda6a..cb787da 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -240,7 +240,6 @@ static void pgd_mop_up_pmds(struct mm_struct *mm, pgd_t
*pgdp)
static void pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t *pgd, pmd_t
*pmds[])
{
pud_t *pud;
- unsigned long addr;
int i;
if (PREALLOCATED_PMDS == 0) /* Work around gcc-3.4.x bug */
@@ -248,8 +247,7 @@ static void pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t
*pgd, pmd_t *pmds[])
pud = pud_offset(pgd, 0);
- for (addr = i = 0; i PREALLOCATED_PMDS;
-i++, pud++, addr += PUD_SIZE) {
+ for (i = 0; i PREALLOCATED_PMDS; i++, pud++) {
pmd_t *pmd = pmds[i];
if (i = KERNEL_PGD_BOUNDARY)
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] mm/page_alloc: fix blank in show_free_areas
There is a blank in show_free_areas which lead to dump messages aren't aligned. This patch remove blank. Before patch: [155219.720141] active_anon:50675 inactive_anon:35273 isolated_anon:0 [155219.720141] active_file:215421 inactive_file:344268 isolated_file:0 [155219.720141] unevictable:0 dirty:35 writeback:0 unstable:0 [155219.720141] free:1334870 slab_reclaimable:28833 slab_unreclaimable:5115 [155219.720141] mapped:25233 shmem:35511 pagetables:1705 bounce:0 [155219.720141] free_cma:0 After patch: [ 73.913889] active_anon:39578 inactive_anon:32082 isolated_anon:0 [ 73.913889] active_file:14621 inactive_file:57993 isolated_file:0 [ 73.913889] unevictable:0dirty:263 writeback:0 unstable:0 [ 73.913889] free:1865614 slab_reclaimable:3264 slab_unreclaimable:4566 [ 73.913889] mapped:21192 shmem:32327 pagetables:1572 bounce:0 [ 73.913889] free_cma:0 Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com --- mm/page_alloc.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c3edb62..3c5ba4e 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3001,12 +3001,12 @@ void show_free_areas(unsigned int filter) } printk(active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n -active_file:%lu inactive_file:%lu isolated_file:%lu\n -unevictable:%lu -dirty:%lu writeback:%lu unstable:%lu\n -free:%lu slab_reclaimable:%lu slab_unreclaimable:%lu\n -mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n -free_cma:%lu\n, + active_file:%lu inactive_file:%lu isolated_file:%lu\n + unevictable:%lu + dirty:%lu writeback:%lu unstable:%lu\n + free:%lu slab_reclaimable:%lu slab_unreclaimable:%lu\n + mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n + free_cma:%lu\n, global_page_state(NR_ACTIVE_ANON), global_page_state(NR_INACTIVE_ANON), global_page_state(NR_ISOLATED_ANON), -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] mm/page_alloc: fix doc for numa_zonelist_order
The default zonelist order selecter will select node order if any node's DMA zone comprises greater than 70% of its local memory instead of 60%, according to default_zonelist_order::low_kmem_size total * 70/100. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index dcc75a9..36ecc26 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -510,7 +510,7 @@ Specify [Dd]efault to request automatic configuration. Autoconfiguration will select node order in following case. (1) if the DMA zone does not exist or (2) if the DMA zone comprises greater than 50% of the available memory or -(3) if any node's DMA zone comprises greater than 60% of its local memory and +(3) if any node's DMA zone comprises greater than 70% of its local memory and the amount of local memory is big enough. Otherwise, zone order will be selected. Default order is recommended unless -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] mm/writeback: remove wb_reason_name
wb_reason_name is not used any more, this patch remove it.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
include/linux/writeback.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index e27468e..8b5cec4 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -51,7 +51,6 @@ enum wb_reason {
WB_REASON_MAX,
};
-extern const char *wb_reason_name[];
/*
* A control structure which tells the writeback code what to do. These are
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
* Tomi Valkeinen tomi.valkei...@ti.com [130613 23:42]: On 14/06/13 08:47, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [130613 22:41]: Hi, On Thursday 13 June 2013 06:35 PM, Tomi Valkeinen wrote: Hi, On 28/05/13 08:18, Kishon Vijay Abraham I wrote: Hi Tony, On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy label) should be added in the platform data of the controller. This series would be needed to get MUSB working in OMAP3 boards for non-dt boot case. Do you think this is good enough to go in this rc cycle? Did this or some other solution go forward? I'm still unable to boot with usb-gadget-ethernet with v3.10-rc5. No. I think Tony is ok to take this only during next merge window. Yes I'll apply them to omap-for-v3.11/fixes-non-critical. We really should have basic functionaly tested and working always before the merge window so we only need to do minimal fixes during the -rc cycle. I'm mostly interested in the USB gadget ethernet for the boards I have, but if I'm not mistaken, all USB gadget support for many OMAP boards is broken in v3.10. Shouldn't that be fixed, no matter if it's a minimal fix or not? Or is there some other, more minimal, way to fix this? Yes it's unfortunate it's broken. But frankly I'm pretty tired of this constant fixing up of basic things for omaps after every merge window. If some patches are not tested properly, then everybody, _do_not_try_to_merge_broken_patches_upstream_. Let them float on the mailing lists until they get fixed or forgotten. Simple as that. If we want to fix something this late in the merge window, the patches must have a clear description what caused the regression and what happens without the patches. These patches don't have that. And they are marked RFC also. So actually I'm not applying any of them before the regression descriptions are there and the patches have been reposted without RFC and have sufficient acks from people. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] mm/writeback: rename WB_REASON_FORKER_THREAD to WB_REASON_WORKER_THREAD
After commit 839a8e86(writeback: replace custom worker pool implementation
with unbound workqueue), there is no bdi forker thread any more. This patch
rename WB_REASON_FORKER_THREAD to WB_REASON_WORKER_THREAD since works are
done by emergency worker.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
fs/fs-writeback.c| 2 +-
include/linux/writeback.h| 2 +-
include/trace/events/writeback.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index e15aa97..87d91d9 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1025,7 +1025,7 @@ void bdi_writeback_workfn(struct work_struct *work)
* enough for efficient IO.
*/
pages_written = writeback_inodes_wb(bdi-wb, 1024,
- WB_REASON_FORKER_THREAD);
+ WB_REASON_WORKER_THREAD);
trace_writeback_pages_written(pages_written);
}
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 8b5cec4..c153073 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -47,7 +47,7 @@ enum wb_reason {
WB_REASON_LAPTOP_TIMER,
WB_REASON_FREE_MORE_MEM,
WB_REASON_FS_FREE_SPACE,
- WB_REASON_FORKER_THREAD,
+ WB_REASON_WORKER_THREAD,
WB_REASON_MAX,
};
diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h
index 464ea82..f3b33f6 100644
--- a/include/trace/events/writeback.h
+++ b/include/trace/events/writeback.h
@@ -28,7 +28,7 @@
{WB_REASON_LAPTOP_TIMER,laptop_timer},\
{WB_REASON_FREE_MORE_MEM, free_more_memory},\
{WB_REASON_FS_FREE_SPACE, fs_free_space}, \
- {WB_REASON_FORKER_THREAD, forker_thread}
+ {WB_REASON_WORKER_THREAD, worker_thread}
struct wb_writeback_work;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8] watchdog: New watchdog driver for MEN A21 watchdogs
On Thu, Jun 13, 2013 at 08:55:33PM -0700, Guenter Roeck wrote:
[...]
Signed-off-by: Johannes Thumshirn johannes.thumsh...@men.de
Almost good. One comment below.
Thanks,
Guenter
Nice to hear. Thanks for the review by the way.
[...]
+
+ drv-num_gpios = of_gpio_count(node);
+ if (drv-num_gpios = 0) {
+ dev_err(pdev-dev, gpios DT property empty / missing);
+ return -ENODEV;
+ }
Not happy with this. Code accepts one gpio pin, but then assumes throughout
the
driver that all pins are defined. I am quite sure I can get it to crash if I
specify only a single gpio pin. num_gpios will be 1, you allocate a single
entry, but then access all 6 of them.
I think it would be easier if you expect a fixed number of gpio pins (6) and
abort
if it is not correct. You can then make drv-gpios an array and don't have to
allocate it separately, and you don't need drv-num_gpios (which you don't
need
anyway as it is not used outside this function).
Yup, you're right. Now that you're saying it I see it as well. This is probably
a
copy'n'paste error from drivers/hwmon/gpio-fan.c.
@Wim are there any objections from your side?
Byte
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/
[PATCH v3 1/3] cpufreq: Add boost frequency support in core
This commit adds boost frequency support in cpufreq core (Hardware
Software).
Some SoC (like Exynos4 - e.g. 4x12) allow setting frequency above
its normal operation limits. Such a mode shall be only used for a short
time.
Overclocking (boost) support is essentially provided by platform
dependent cpufreq driver.
This commit unifies support for SW and HW (Intel) over clocking solutions
in the core cpufreq driver. Previously the boost sysfs attribute was
defined at acpi driver code.
By default boost is disabled. One global attribute is available at:
/sys/devices/system/cpu/cpufreq/boost.
It only shows up when cpufreq driver supports overclocking.
Under the hood frequencies dedicated for boosting are marked with a
special flag (CPUFREQ_BOOST_FREQ) at driver's frequency table.
It is the user's concern to enable/disable overclocking with proper call to
sysfs.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
Changes for v2:
- Removal of cpufreq_boost structure and move its fields to cpufreq_driver
structure
- Flag to indicate if global boost attribute is already defined
- Extent the pr_{err|debbug} functions to show current function names
Changes for v3:
- Method for reading boost status
- Removal of cpufreq_frequency_table_max()
- Extent cpufreq_frequency_table_cpuinfo() to support boost parameter
- boost_supported flag added to cpufreq_driver struct
- boost sysfs attribute control flag removed
- One global flag describing state of the boost defined at cpufreq core
- Rename cpufreq_driver's low_level_boost field to set_boost_freq()
- Usage of cpufreq_sysfs_{remove|add}_file() routines
---
arch/arm/mach-s3c24xx/cpufreq.c |2 +-
arch/powerpc/platforms/pasemi/cpufreq.c |2 +-
arch/powerpc/platforms/powermac/cpufreq_32.c |2 +-
arch/powerpc/platforms/powermac/cpufreq_64.c |2 +-
drivers/cpufreq/acpi-cpufreq.c |2 +-
drivers/cpufreq/arm_big_little.c |3 +-
drivers/cpufreq/blackfin-cpufreq.c |2 +-
drivers/cpufreq/cpufreq-cpu0.c |2 +-
drivers/cpufreq/cpufreq.c| 87 ++
drivers/cpufreq/cris-artpec3-cpufreq.c |2 +-
drivers/cpufreq/cris-etraxfs-cpufreq.c |2 +-
drivers/cpufreq/davinci-cpufreq.c|2 +-
drivers/cpufreq/dbx500-cpufreq.c |2 +-
drivers/cpufreq/e_powersaver.c |3 +-
drivers/cpufreq/elanfreq.c |2 +-
drivers/cpufreq/exynos-cpufreq.c |3 +-
drivers/cpufreq/exynos5440-cpufreq.c |2 +-
drivers/cpufreq/freq_table.c | 44 ++---
drivers/cpufreq/ia64-acpi-cpufreq.c |2 +-
drivers/cpufreq/imx6q-cpufreq.c |2 +-
drivers/cpufreq/kirkwood-cpufreq.c |3 +-
drivers/cpufreq/longhaul.c |2 +-
drivers/cpufreq/loongson2_cpufreq.c |2 +-
drivers/cpufreq/maple-cpufreq.c |2 +-
drivers/cpufreq/omap-cpufreq.c |2 +-
drivers/cpufreq/p4-clockmod.c|2 +-
drivers/cpufreq/powernow-k6.c|2 +-
drivers/cpufreq/powernow-k7.c|2 +-
drivers/cpufreq/powernow-k8.c|2 +-
drivers/cpufreq/ppc_cbe_cpufreq.c|2 +-
drivers/cpufreq/pxa2xx-cpufreq.c |4 +-
drivers/cpufreq/pxa3xx-cpufreq.c |2 +-
drivers/cpufreq/s3c2416-cpufreq.c|2 +-
drivers/cpufreq/s3c64xx-cpufreq.c|2 +-
drivers/cpufreq/s5pv210-cpufreq.c|2 +-
drivers/cpufreq/sc520_freq.c |2 +-
drivers/cpufreq/sh-cpufreq.c |2 +-
drivers/cpufreq/sparc-us2e-cpufreq.c |2 +-
drivers/cpufreq/sparc-us3-cpufreq.c |2 +-
drivers/cpufreq/spear-cpufreq.c |3 +-
drivers/cpufreq/speedstep-centrino.c |2 +-
drivers/cpufreq/speedstep-ich.c |2 +-
drivers/cpufreq/speedstep-smi.c |2 +-
drivers/cpufreq/tegra-cpufreq.c |4 +-
include/linux/cpufreq.h | 18 +-
45 files changed, 187 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/cpufreq.c b/arch/arm/mach-s3c24xx/cpufreq.c
index 3c0e78e..882fcb5 100644
--- a/arch/arm/mach-s3c24xx/cpufreq.c
+++ b/arch/arm/mach-s3c24xx/cpufreq.c
@@ -387,7 +387,7 @@ static int s3c_cpufreq_init(struct cpufreq_policy *policy)
policy-cpuinfo.transition_latency = cpu_cur.info-latency;
if (ftab)
- cpufreq_frequency_table_cpuinfo(policy, ftab);
+ cpufreq_frequency_table_cpuinfo(policy, ftab, 0);
return 0;
}
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c
b/arch/powerpc/platforms/pasemi/cpufreq.c
index be1e795..3d2fcc7 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++
[PATCH v3 2/3] cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution
The Intel's hardware based boost solution driver has been changed to cooperate
with
common cpufreq boost framework.
The global sysfs boost attribute entry code
(/sys/devices/system/cpu/cpufreq/boost)
has been moved to a core cpufreq code. This attribute is now only visible,
when cpufreq driver supports it.
The boost supported global flag was replaced with the one defined at acpi's
cpufreq driver.
The _store_boost() function has been redesigned to be used as set_boost_freq
callback.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
Changes for v2:
- Replace boost_enabled and boost_supported global flags with proper entries
at struct cpufreq_driver.
- Removal of struct cpufreq_boost
Changes for v3:
- Bring back boost_enabled as a global flag
- Move boost_supported to cpufreq_driver structure
---
drivers/cpufreq/acpi-cpufreq.c | 60 ++--
1 file changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index abca529..9cd528e 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -80,7 +80,7 @@ static struct acpi_processor_performance __percpu
*acpi_perf_data;
static struct cpufreq_driver acpi_cpufreq_driver;
static unsigned int acpi_pstate_strict;
-static bool boost_enabled, boost_supported;
+static bool boost_enabled;
static struct msr __percpu *msrs;
static bool boost_state(unsigned int cpu)
@@ -133,20 +133,10 @@ static void boost_set_msrs(bool enable, const struct
cpumask *cpumask)
wrmsr_on_cpus(cpumask, msr_addr, msrs);
}
-static ssize_t _store_boost(const char *buf, size_t count)
+static int _store_boost(int val)
{
- int ret;
- unsigned long val = 0;
-
- if (!boost_supported)
- return -EINVAL;
-
- ret = kstrtoul(buf, 10, val);
- if (ret || (val 1))
- return -EINVAL;
-
if ((val boost_enabled) || (!val !boost_enabled))
- return count;
+ return 0;
get_online_cpus();
@@ -157,30 +147,31 @@ static ssize_t _store_boost(const char *buf, size_t count)
boost_enabled = val;
pr_debug(Core Boosting %sabled.\n, val ? en : dis);
- return count;
+ return 0;
}
-static ssize_t store_global_boost(struct kobject *kobj, struct attribute *attr,
- const char *buf, size_t count)
+static ssize_t store_boost(const char *buf, size_t count)
{
- return _store_boost(buf, count);
-}
+ int ret;
+ unsigned long val = 0;
-static ssize_t show_global_boost(struct kobject *kobj,
-struct attribute *attr, char *buf)
-{
- return sprintf(buf, %u\n, boost_enabled);
-}
+ if (!acpi_cpufreq_driver.boost_supported)
+ return -EINVAL;
+
+ ret = kstrtoul(buf, 10, val);
+ if (ret || (val 1))
+ return -EINVAL;
-static struct global_attr global_boost = __ATTR(boost, 0644,
- show_global_boost,
- store_global_boost);
+ _store_boost((int) val);
+
+ return count;
+}
#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
static ssize_t store_cpb(struct cpufreq_policy *policy, const char *buf,
size_t count)
{
- return _store_boost(buf, count);
+ return store_boost(buf, count);
}
static ssize_t show_cpb(struct cpufreq_policy *policy, char *buf)
@@ -930,8 +921,8 @@ static void __init acpi_cpufreq_boost_init(void)
if (!msrs)
return;
- boost_supported = true;
boost_enabled = boost_state(0);
+ acpi_cpufreq_driver.boost_supported = true;
get_online_cpus();
@@ -941,22 +932,11 @@ static void __init acpi_cpufreq_boost_init(void)
register_cpu_notifier(boost_nb);
put_online_cpus();
- } else
- global_boost.attr.mode = 0444;
-
- /* We create the boost file in any case, though for systems without
-* hardware support it will be read-only and hardwired to return 0.
-*/
- if (cpufreq_sysfs_create_file((global_boost.attr)))
- pr_warn(PFX could not register global boost sysfs file\n);
- else
- pr_debug(registered global boost sysfs file\n);
+ }
}
static void __exit acpi_cpufreq_boost_exit(void)
{
- cpufreq_sysfs_remove_file((global_boost.attr));
-
if (msrs) {
unregister_cpu_notifier(boost_nb);
--
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/
[PATCH v3 3/3] cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework
The struct cpufreq_driver has been extended to embrace the information
related to boost support.
When boost_mode device tree attribute is defined for a platform, the
boost_supported flag is set. Moreover boost related attributes were
exported.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
Changes for v2:
- Removal of struct cpufreq_boost
- Removal of the CONFIG_CPU_FREQ_BOOST flag
- low_level_boost with valid address when boost is supported
Changes for v3:
- Remove low level boost code
- Move boost management code to cpufreq core code
- Use boost_supported flag to indicate if driver supports over clocking
---
drivers/cpufreq/exynos-cpufreq.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 32ec2f6..0420d47 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -265,6 +265,7 @@ static int exynos_cpufreq_cpu_exit(struct cpufreq_policy
*policy)
static struct freq_attr *exynos_cpufreq_attr[] = {
cpufreq_freq_attr_scaling_available_freqs,
+ cpufreq_freq_attr_scaling_boost_freqs,
NULL,
};
@@ -360,6 +361,7 @@ static struct of_device_id exynos_cpufreq_of_match[]
__initconst = {
static int __init exynos_cpufreq_probe(struct platform_device *pdev)
{
+ struct device_node *node = pdev-dev.of_node;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(struct exynos_dvfs_info), GFP_KERNEL);
@@ -392,6 +394,8 @@ static int __init exynos_cpufreq_probe(struct
platform_device *pdev)
}
locking_frequency = exynos_getspeed(0);
+ if (of_property_read_bool(node, boost_mode))
+ exynos_driver.boost_supported = 1;
register_pm_notifier(exynos_cpufreq_nb);
--
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/
[PATCH v3 0/3] cpufreq:boost: CPU Boost mode support
This patch series introduces support for CPU overclocking technique called Boost. It is a follow up of a LAB governor proposal. Boost is a LAB component: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq Boost unifies hardware based solution (e.g. Intel Nehalem) with software oriented one (like the one done at Exynos). For this reason cpufreq/freq_table code has been reorganized to include common code. Important design decisions: - Boost related code is compiled-in unconditionally and disabled by default The cpufreq_driver is responsibile for providing set_boost_freq callback (if needed) - struct cpufreq_driver has been extended with boost related fields: -- boost_supported - when driver supports boosting -- set_boost_freq - callback to function, which is necessary to enable boost at the processor (like it is done at Intel) - Boost sysfs attributies are seen only when cpufreq driver supports them. They will not show up until either cpufreq_driver defines boost_supported flag or device tree's cpufreq boost_mode attribute. - No special spin_lock for Boost was created. The one from cpufreq_driver was reused. - The Boost code doesn't rely on any policy. When boost state is changed, then policies attached to each CPU are updated. Tested at: HW: Exynos 4412 3.10 linux Exynos 4210 3.10 linux Compile tested x86_64 defconfig (acpi) - help with HW (Intel Nehalem) test needed Lukasz Majewski (3): cpufreq: Add boost frequency support in core cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework arch/arm/mach-s3c24xx/cpufreq.c |2 +- arch/powerpc/platforms/pasemi/cpufreq.c |2 +- arch/powerpc/platforms/powermac/cpufreq_32.c |2 +- arch/powerpc/platforms/powermac/cpufreq_64.c |2 +- drivers/cpufreq/acpi-cpufreq.c | 62 +++--- drivers/cpufreq/arm_big_little.c |3 +- drivers/cpufreq/blackfin-cpufreq.c |2 +- drivers/cpufreq/cpufreq-cpu0.c |2 +- drivers/cpufreq/cpufreq.c| 87 ++ drivers/cpufreq/cris-artpec3-cpufreq.c |2 +- drivers/cpufreq/cris-etraxfs-cpufreq.c |2 +- drivers/cpufreq/davinci-cpufreq.c|2 +- drivers/cpufreq/dbx500-cpufreq.c |2 +- drivers/cpufreq/e_powersaver.c |3 +- drivers/cpufreq/elanfreq.c |2 +- drivers/cpufreq/exynos-cpufreq.c |7 ++- drivers/cpufreq/exynos5440-cpufreq.c |2 +- drivers/cpufreq/freq_table.c | 44 ++--- drivers/cpufreq/ia64-acpi-cpufreq.c |2 +- drivers/cpufreq/imx6q-cpufreq.c |2 +- drivers/cpufreq/kirkwood-cpufreq.c |3 +- drivers/cpufreq/longhaul.c |2 +- drivers/cpufreq/loongson2_cpufreq.c |2 +- drivers/cpufreq/maple-cpufreq.c |2 +- drivers/cpufreq/omap-cpufreq.c |2 +- drivers/cpufreq/p4-clockmod.c|2 +- drivers/cpufreq/powernow-k6.c|2 +- drivers/cpufreq/powernow-k7.c|2 +- drivers/cpufreq/powernow-k8.c|2 +- drivers/cpufreq/ppc_cbe_cpufreq.c|2 +- drivers/cpufreq/pxa2xx-cpufreq.c |4 +- drivers/cpufreq/pxa3xx-cpufreq.c |2 +- drivers/cpufreq/s3c2416-cpufreq.c|2 +- drivers/cpufreq/s3c64xx-cpufreq.c|2 +- drivers/cpufreq/s5pv210-cpufreq.c|2 +- drivers/cpufreq/sc520_freq.c |2 +- drivers/cpufreq/sh-cpufreq.c |2 +- drivers/cpufreq/sparc-us2e-cpufreq.c |2 +- drivers/cpufreq/sparc-us3-cpufreq.c |2 +- drivers/cpufreq/spear-cpufreq.c |3 +- drivers/cpufreq/speedstep-centrino.c |2 +- drivers/cpufreq/speedstep-ich.c |2 +- drivers/cpufreq/speedstep-smi.c |2 +- drivers/cpufreq/tegra-cpufreq.c |4 +- include/linux/cpufreq.h | 18 +- 45 files changed, 211 insertions(+), 95 deletions(-) -- 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 1/2] scsi: ufs: Add support for sending NOP OUT UPIU
On 6/13/2013 10:03 AM, Sujit Reddy Thumma wrote:
static struct scsi_host_template ufshcd_driver_template = {
@@ -1771,8 +2064,8 @@ int ufshcd_init(struct device *dev, struct
ufs_hba **hba_handle,
/* Configure LRB */
ufshcd_host_memory_configure(hba);
- host-can_queue = hba-nutrs;
- host-cmd_per_lun = hba-nutrs;
+ host-can_queue = SCSI_CMD_QUEUE_SIZE;
I don't think this is appropriate. Reserving a slot exclusively for
query/DM requests is not optimal. can_queue should be changed
dynamically, scsi_adjust_queue_depth() maybe?
The motivation to change the design for this patch is that routing
query command through SCSI layer raised problems when we are trying to
improve the fatal error handling as we need to block the SCSI layer and
recover the link. Hence, the need to have the query/DM command send as
internal commands. Which probably makes sense.
One possible option was to look for a free command slot whenever we
try to send an internal command, but getting a free slot is not always
guaranteed.
Even if we get hold of a tag, there is no way we can explain this to
SCSI/block layer that particular tag is in use internally (case where
normal query requests are sent in tandem with SCSI requests). In which
case, other option is to use tag[31] as you have said on need basis
and change the queue depth to 31. This again has problems - one
changing queue depth doesn't take effect immediately but for the next
command. Second, if the command in tag[31] is the root cause of the
fatal error and is stuck, then the internal command has to wait forever
(until scsi timesout) to plan recovery. Considering, all these factors
it is better to reserve a tag and use it for internal commands instead
of playing around with the tags internally without/partially informing
SCSI/block layers.
I am open for discussion, if there are any suggestions to handle such
LLD requirements in the SCSI layer optimally.
Coming to how optimal is to work with 31 slots instead of h/w defined 32
is something which we can answer when we have true multi queueing.
AFAIK, there may not exist real-world applications which utilize full 32
tags at particular instant. SATA AHCI controller driver which is
ubiquitous in modern systems also reserves a slot for internal commands
which is used only in case of error handling and AFAIK, no one has ever
reported performance problems with this (its about 7 years the commit to
reserve a slot is merged into Linux tree).
I hope this explains the intent. Please let me know what do you think.
--
Regards,
Sujit
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
perf bench does compile in 3.9.6
Hello, on my 64bit kernel / 32 bit userspace system with libnuma 2.0.8 i get this error on linux 3.9.6: bench/numa.c: In function ‘worker_thread’: bench/numa.c:1113:20: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] bench/numa.c:1161:6: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘u64’ [-Werror=format] Haven't tried latest git but it looks like there's the same issue. thanks, riccardo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [BUG] PCI related panic on powerpc based board with 3.10-rcX
On Thursday 13 June 2013 11:49:17 Scott Wood wrote: On 06/13/2013 02:21:24 AM, Rojhalat Ibrahim wrote: On Wednesday 12 June 2013 16:50:26 Scott Wood wrote: On 06/12/2013 03:19:30 AM, Rojhalat Ibrahim wrote: On Tuesday 11 June 2013 12:28:59 Scott Wood wrote: Yes, I figured it was non-PCIe because the code change that you said helped was on the non-PCIe branch of the if/else. Generally it's good to explicitly mention the chip you're using, though. fsl_setup_indirect_pci should be renamed to fsl_setup_indirect_pcie. Your patch above should be applied, and fsl_setup_indirect_pcie should be moved into the booke/86xx ifdef to avoid an unused function warning. -Scott How about this patch? It uses setup_indirect_pci for the PCI case in mpc83xx_add_bridge. Additionally it adds a check in fsl_setup_indirect_pci to only use the modified read function in case of PCIe. If we're adding the check to fsl_setup_indirect_pci, there's no need to change the 83xx call back to setup_indirect_pci. I see that 85xx is also callirng fsl_setup_indirect_pci for both; it'd be good to be consistent. In any case, can you send a proper patch with a signoff and commit message? -Scott Where is it called for 85xx? As far as I can tell fsl_setup_indirect_pci is called exactly once in fsl_add_bridge and nowhere else (after applying the proposed patch). fsl_add_bridge() is where it's called for 85xx. For 83xx the decision between PCI and PCIe has already been made at the point where the setup function is called. So IMO it doesn't make sense to call fsl_setup_indirect_pci and do the check again. Moreover PCIe on 83xx uses a completely different set of functions. My concern is consistency. E.g. if 85xx is using fsl_setup_indirect_pci for both, but 83xx isn't, then a developer using 83xx could end up breaking 85xx by introducing another PCIe dependency in fsl_setup_indirect_pci. Or an 85xx developer could put something non-PCIe-related in fsl_setup_indirect_pci that 83xx would benefit from. Alternatively, you could call it fsl_setup_indirect_pcie, and move the PCIe check into fsl_add_bridge(). -Scott Ok. I'll post a v2 of the patch. Rojhalat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: show_interrupts() after free_irq issue 3.10-rc4?
I've been working with device passthrough irq on armv7 after disassociating the device from guest free_irq() is executed on host. Display of /proc/interrupts still shows the IRQ info with no irq name associated, and there is no irq_action associated with the IRQ. 'show_interrupts()' in 'kernel/irq/proc.c' displays info on the IRQ due to prior stats accumulated. Few other arch specific ones only on irq_action. Is there some specific reason for that? To me it appears misleading to display dormant IRQ info. For the end user - use case like above or unloading driver and seeing the irq show up is confusing as well. Also not sure what you gain by displaying old IRQ info. Please cc on responses. Sorry for the double copy misspelled mailing list - Mario -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] should read(2) update the position if it returns an error?
We have an unpleasant HPFS (at least) race with read(2) vs. unlink(2) The thing is, HPFS and several other filesystems keep track of all opened struct file for directory and update the position in it upon directory modifications. For HPFS it's particulary painful, since it encodes the location of directory block (times 64 + number of entry in block) as -f_pos. lseek() validates the offset under i_mutex, directory modifications update -f_pos of all files (again, under i_mutex) and readdir does all accesses under i_mutex. The trouble with that scheme is sys_read(). There we save the current position, pass the address of local copy to vfs_read() and, once vfs_read() has returned an error, store the value in that local copy back into -f_pos. The value is unmodified, of course, and everything would be fine if not for the following problem: directory modification done in parallel with that has no idea of that local copy and does *not* update it. It does update -f_pos, but that update gets reverted as soon as vfs_read() returns and sys_read() does file_pos_write(). It's not just HPFS - HFS, HFS+ and sysfs have a similar (but probably milder) issue. For HPFS it's really nasty - we might end up with subsequent readdir() reading from a completely unrelated directory ;-/ We obviously don't want to grab i_mutex in sys_read(), but I really wonder if we should do file_pos_write() there in case of vfs_read() returning an error. Most of the -read() instances leave *pos unchanged if they decide to return an error - after all, if we'd consumed some data, the right thing is short read, with whatever errors happening on subsequent reads. I'm not sure if it's mandated by POSIX, but it seems to be what the userland would reasonably expect. And that matches the usual logics with e.g. interruptible waits catching signals in -read() instances... Comments? I'd obviously prefer to solve it that way (i.e. leave -f_pos untouched if vfs_read() returns an error), but I might be missing some case where we want position updated even though read() returns an error. I can't come up with one, but then I hadn't RTFS through every -read() instance in drivers in search of weird cases like that - we've too many instances ;-/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] pinctrl: add function to parse generic pinconfig properties from a dt node
Hi Laurent,
Am Freitag, 14. Juni 2013, 02:27:01 schrieb Laurent Pinchart:
Hi Heiko,
Thank you for the patch. I've tested it on an sh73a0 KZM9G board with the
sh- pfc driver and it seems to work fine. Please see the code below for
comments.
On Monday 10 June 2013 21:40:29 Heiko Stübner wrote:
pinconf_generic_parse_dt_config() takes a node as input and generates an
array of generic pinconfig values from the properties of this node.
As I couldn't find a mechanism to count the number of properties of a
node the function uses internally an array to accept one of parameter
and copies the real present options to a smaller variable at its end.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../bindings/pinctrl/pinctrl-bindings.txt | 38 +
drivers/pinctrl/pinconf-generic.c | 81
+ drivers/pinctrl/pinconf.h |
6 ++
3 files changed, 125 insertions(+), 0 deletions(-)
diff --git
a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index
c95ea82..ef7cd57 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -126,3 +126,41 @@ device; they may be grandchildren, for example.
Whether this is legal, and whether there is any interaction between the
child and intermediate parent nodes, is again defined entirely by the
binding for the individual pin controller device.
+
+== Using generic pinconfig options ==
+
+Generic pinconfig parameters can be used by defining a separate node
containing +the applicable parameters (and optional values), like:
+
+pcfg_pull_up: pcfg_pull_up {
+ bias-pull-up;
+ drive-strength = 20;
+};
+
+This node should then be referenced in the appropriate pinctrl node as a
phandle +and parsed in the driver using the
pinconf_generic_parse_dt_config function. +
+Supported configuration parameters are:
+
+bias-disable - disable any pin bias
+bias-high-impedance- high impedance mode (third-state,
floating)
+bias-bus-hold - latch weakly
+bias-pull-up - pull up the pin
+bias-pull-down - pull down the pin
+bias-pull-pin-default - use pin-default pull state
+drive-push-pull- drive actively high and low
+drive-open-drain - drive with open drain
+drive-open-source - drive with open source
+drive-strength - sink or source at most X mA
+input-schmitt-enable - enable schmitt-trigger mode
+input-schmitt-disable - disable schmitt-trigger mode
+input-schmitt - run in schmitt-trigger mode with hysteresis X
+input-debounce - debounce mode with debound time X
+power-source - select power source X
+slew-rate - use slew-rate X
+low-power-mode - low power mode
+output-low - set the pin to output mode with low level
+output-high- set the pin to output mode with high level
+
+More in-depth documentation on these parameters can be found in
+include/linux/pinctrl/pinconfig-generic.h
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c index 9a6812b..3610e7b 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -21,6 +21,7 @@
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinconf.h
#include linux/pinctrl/pinconf-generic.h
+#include linux/of.h
#include core.h
#include pinconf.h
@@ -139,3 +140,83 @@ void pinconf_generic_dump_config(struct pinctrl_dev
*pctldev, }
EXPORT_SYMBOL_GPL(pinconf_generic_dump_config);
#endif
+
+#ifdef CONFIG_OF
+struct pinconf_generic_dt_params {
+ const char * const property;
+ enum pin_config_param param;
+ u32 default_value;
+};
+
+static struct pinconf_generic_dt_params dt_params[] = {
+ { bias-disable, PIN_CONFIG_BIAS_DISABLE, 0 },
+ { bias-high-impedance, PIN_CONFIG_BIAS_HIGH_IMPEDANCE, 0 },
+ { bias-bus-hold, PIN_CONFIG_BIAS_BUS_HOLD, 0 },
+ { bias-pull-up, PIN_CONFIG_BIAS_PULL_UP, 0 },
+ { bias-pull-down, PIN_CONFIG_BIAS_PULL_DOWN, 0 },
+ { bias-pull-pin-default, PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 0 },
+ { drive-push-pull, PIN_CONFIG_DRIVE_PUSH_PULL, 0 },
+ { drive-open-drain, PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
+ { drive-open-source, PIN_CONFIG_DRIVE_OPEN_SOURCE, 0 },
+ { drive-strength, PIN_CONFIG_DRIVE_STRENGTH, 0 },
+ { input-schmitt-enable, PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
+ { input-schmitt-disable, PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
+ { input-schmitt, PIN_CONFIG_INPUT_SCHMITT, 0 },
+ { input-debounce, PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+ { power-source, PIN_CONFIG_POWER_SOURCE, 0 },
+ { slew-rate,
[no subject]
-- hallo, Haben Sie ein Darlehen, Rechnungen zu bezahlen oder Ihr eigenes Unternehmen gründen möchten, können Sie für ein Darlehen bewerben Sie sich jetzt und kontaktieren Sie uns via E-mail: willsrichardloancompan...@yahoo.co.uk Kreditantrag Name: Adresse: Tel: Alter: Beruf: Land: Darlehensbetrag benötigt: Die Laufzeit des Kredits: Zweck des Darlehens: Mr. Mike Petter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
On 14/06/13 10:33, Tony Lindgren wrote: If we want to fix something this late in the merge window, the patches must have a clear description what caused the regression and what happens without the patches. These patches don't have that. And they are marked RFC also. So actually I'm not applying any of them before the regression descriptions are there and the patches have been reposted without RFC and have sufficient acks from people. No disagreement there. Kishon, I tested the patches on top of v3.10-rc5, booting with nfs root via usb gadget eth: Overo: works Beagle: works, but I need to reconnect the usb cable after kernel is up Beagle-xm: doesn't work. The cable is detected correctly, though Panda: works The problems with Beagles are there even without these patches, so they do make things better (fix Overo). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos
On Thursday, June 13, 2013 11:14 PM, Arnd Bergmann wrote:
On Thursday 13 June 2013 22:22:31 Jingoo Han wrote:
+struct pcie_port_info {
+ u32 cfg0_size;
+ u32 cfg1_size;
+ u32 io_size;
+ u32 mem_size;
+ phys_addr_t io_bus_addr;
+ phys_addr_t mem_bus_addr;
+};
+
+struct pcie_port {
+ struct device *dev;
+ u8 controller;
+ u8 root_bus_nr;
+ void __iomem*dbi_base;
+ void __iomem*elbi_base;
+ void __iomem*phy_base;
+ void __iomem*purple_base;
+ phys_addr_t cfg0_base;
+ void __iomem*va_cfg0_base;
+ phys_addr_t cfg1_base;
+ void __iomem*va_cfg1_base;
+ phys_addr_t io_base;
+ phys_addr_t mem_base;
+ spinlock_t conf_lock;
+ struct resource cfg;
+ struct resource io;
+ struct resource mem;
+ struct pcie_port_info config;
+ struct clk *clk;
+ struct clk *bus_clk;
+ int irq;
+ int reset_gpio;
+};
You mentioned that you'd use u64 for the resources here but did not.
Do you mean the following?
+ u64 cfg0_base;
+ u64 cfg1_base;
+ u64 io_base;
+ u64 mem_base;
+
+static void exynos_pcie_prog_viewport_cfg0(struct pcie_port *pp, u32
busdev)
+{
+ u32 val;
+ void __iomem *dbi_base = pp-dbi_base;
+
+ /* Program viewport 0 : OUTBOUND : CFG0 */
+ val = PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
+ writel_rc(pp, (u64)pp-cfg0_base, dbi_base + PCIE_ATU_LOWER_BASE);
+ writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_BASE);
+ writel_rc(pp, (u64)pp-cfg0_base + pp-config.cfg0_size - 1,
+ dbi_base + PCIE_ATU_LIMIT);
+ writel_rc(pp, busdev, dbi_base + PCIE_ATU_LOWER_TARGET);
+ writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
+ writel_rc(pp, PCIE_ATU_TYPE_CFG0, dbi_base + PCIE_ATU_CR1);
+ val = PCIE_ATU_ENABLE;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_CR2);
+}
+
+static void exynos_pcie_prog_viewport_cfg1(struct pcie_port *pp, u32
busdev)
+{
+ u32 val;
+ void __iomem *dbi_base = pp-dbi_base;
+
+ /* Program viewport 1 : OUTBOUND : CFG1 */
+ val = PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
+ writel_rc(pp, PCIE_ATU_TYPE_CFG1, dbi_base + PCIE_ATU_CR1);
+ val = PCIE_ATU_ENABLE;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_CR2);
+ writel_rc(pp, (u64)pp-cfg1_base, dbi_base + PCIE_ATU_LOWER_BASE);
+ writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_BASE);
+ writel_rc(pp, (u64)pp-cfg1_base + pp-config.cfg1_size - 1,
+ dbi_base + PCIE_ATU_LIMIT);
+ writel_rc(pp, busdev, dbi_base + PCIE_ATU_LOWER_TARGET);
+ writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
+}
And you still don't set up the UPPER halves, which was really the point
of my comment. Same thing for all the other ones.
Do you mean the following?
+ writel_rc(pp, pp-cfg1_base, dbi_base + PCIE_ATU_LOWER_BASE);
+ writel_rc(pp, (pp-cfg1_base 32), dbi_base + PCIE_ATU_UPPER_BASE);
+static void exynos_pcie_prog_viewport_mem_inbound(struct pcie_port *pp)
+{
+ u32 val;
+ void __iomem *dbi_base = pp-dbi_base;
+
+ /* Program viewport 0 : INBOUND : MEM */
+ val = PCIE_ATU_REGION_INBOUND | PCIE_ATU_REGION_INDEX0;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
+ writel_rc(pp, PCIE_ATU_TYPE_MEM, dbi_base + PCIE_ATU_CR1);
+ val = PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_CR2);
+ writel_rc(pp, (u64)pp-config.mem_bus_addr,
+ dbi_base + PCIE_ATU_LOWER_BASE);
+ writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_BASE);
+ writel_rc(pp, (u64)pp-config.mem_bus_addr + pp-config.mem_size - 1,
+ dbi_base + PCIE_ATU_LIMIT);
+ writel_rc(pp, (u64)pp-mem_base, dbi_base + PCIE_ATU_LOWER_TARGET);
+ writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
+}
This makes even less sense than before, it seems like now you only
allow DMA between PCI devices but not to main memory.
Sorry, I cannot understand it.
Could you give me more details?
Also, pseudo-code will be very helpful.
+static void exynos_pcie_prog_viewport_io_inbound(struct pcie_port *pp)
+{
+ u32 val;
+ void __iomem *dbi_base = pp-dbi_base;
+
+ /* Program viewport 1 : INBOUND : IO */
+ val = PCIE_ATU_REGION_INBOUND | PCIE_ATU_REGION_INDEX1;
+ writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
+ writel_rc(pp, PCIE_ATU_TYPE_IO, dbi_base + PCIE_ATU_CR1);
+ val =
Re: [PATCH Resend 1/1] mfd: davinci_voicecodec: Convert to use devm_* APIs
On 14 June 2013 12:36, Lee Jones lee.jo...@linaro.org wrote: On Fri, 14 Jun 2013, Sachin Kamat wrote: Hi Lee, On 13 June 2013 16:19, Lee Jones lee.jo...@linaro.org wrote: On Wed, 12 Jun 2013, Sachin Kamat wrote: devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Miguel Aguilar miguel.agui...@ridgerun.com --- CC'd Lee Jones Can you resubmit this based on -rc5 please? There have been some related changes since you wrote this patch. This patch is based on Samuel's mfd-next tree [1]. This patch is dependent on your patch mfd: davinci_voicecodec: Convert to managed resources for allocating memory which is applied in mfd-next. Please let me know which other tree you want me to rebase this patch on considering the dependency. [1] http://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git I believe Sam's branch has been updated considerably since you wrote the patch. Would you mind rebasing it onto Sam's latest master branch please? Should be commit: d8c5d658f425bd25bbfb137f2617f59ed4fdee7d. It applies cleanly on top of the commit: d8c5d658f425bd25bbfb137f2617f59ed4fdee7d (Merge tag 'am335x_tsc-adc' of git://breakpoint.cc/bigeasy/linux). I am surprised that you are getting errors. Anyway resending once again. -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] irqdomain: Remove temporary MIPS workaround code
On Fri, Jun 14, 2013 at 12:19:43AM +0100, Grant Likely wrote: The MIPS interrupt controllers are all registering their own irq_domains now. Drop the MIPS specific code because it is no longer needed. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Ralf Baechle r...@linux-mips.org Cc: linux-m...@linux-mips.org --- Ralf, this should be okay to pull out now. I'll be submitting it for v3.11 unless someone yells. Even if so, all the irqdomain infrastructure is in place to make it trivial to add an irqdomain where missing. I would like to merge this through the MIPS tree so it'll receive maximum testing, just in case, ok? Ralf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: event filtering with trace-cmd
On 06/12/2013 07:16 PM, Steven Rostedt wrote: On Wed, 2013-06-12 at 12:22 -0400, Steven Rostedt wrote: # sudo trace-cmd record -e brcmfmac:brcmf_dbg -f 'level 0x4' disable all enable brcmfmac:brcmf_dbg path = /sys/kernel/debug/tracing/events/brcmfmac/brcmf_dbg/enable (level 0x4) ^ parse_error: Invalid operator The record -f command passes the filter into the kernel file /sys/kerne/debug/tracing/events/brcmfmac/brcmf_dbg/filter, and the error is actually coming from the kernel itself. Looking at the code, we do not currently accept binary operations. Although, it shouldn't be too hard to add. I may go and implement it for 3.11. Here, can you apply this patch and see if it does what you expect? Hi Steven, That patch does exactly what I expect. Thanks. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] Fix comment on pinctrl_gpio_range.pin_base
The comment introduced with the recently added pinctrl_gpio_range.pins
element was wrong. This corrects it.
Thanks to Patrice Chotard for pointing this out.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
---
include/linux/pinctrl/pinctrl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
index 286c5e5..47ab2fb 100644
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -49,7 +49,7 @@ struct pinctrl_pin_desc {
* @name: a name for the chip in this range
* @id: an ID number for the chip in this range
* @base: base offset of the GPIO range
- * @pin_base: base pin number of the GPIO range if pins != NULL
+ * @pin_base: base pin number of the GPIO range if pins == NULL
* @pins: enumeration of pins in GPIO range or NULL
* @npins: number of pins in the GPIO range, including the base number
* @gc: an optional pointer to a gpio_chip
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 7/8] mm/thp: fix doc for transparent huge zero page
Wanpeng Li wrote: Transparent huge zero page is used during the page fault instead of in khugepaged. # ls /sys/kernel/mm/transparent_hugepage/ defrag enabled khugepaged use_zero_page # ls /sys/kernel/mm/transparent_hugepage/khugepaged/ alloc_sleep_millisecs defrag full_scans max_ptes_none pages_collapsed pages_to_scan scan_sleep_millisecs This patch corrects the documentation just like the codes done. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com -- Kirill A. Shutemov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ARM: tegra: basic support for Trusted Foundations
On Fri, Jun 14, 2013 at 4:19 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
Add basic support for booting secondary processors on Tegra devices
using the Trusted Foundations secure monitor.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Documentation/devicetree/bindings/arm/tegra.txt| 11 +
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/configs/tegra_defconfig | 1 +
The defconfig change should be a separate patch, so that I can squash it
into any other defconfig updates separately from all the code changes.
Ok, moved that part into its own patch.
diff --git a/arch/arm/mach-tegra/firmware.c b/arch/arm/mach-tegra/firmware.c
+void __init tegra_init_firmware(void)
+{
+ struct device_node *node;
+
+ if (!of_have_populated_dt())
+ return;
+
+ node = of_find_compatible_node(NULL, NULL, tl,trusted-foundations);
+ if (node !IS_ENABLED(CONFIG_TEGRA_TRUSTED_FOUNDATIONS))
+ pr_warn(Trusted Foundations detected but support missing!\n);
+#if IS_ENABLED(CONFIG_TEGRA_TRUSTED_FOUNDATIONS)
+ else if (node)
+ register_firmware_ops(tegra_trusted_foundations_ops);
+#endif
+}
Is it worth continuing on in the node !IS_ENABLED case here? After
all, we can be pretty certain that the write to the CPU reset vector is
immediately going to trap...
That's what was happening until 3.9, but from 3.10 on the trap is
apparently handled and the boot completes (although with only one
processor).
I suppose that perhaps without SMP, cpuidle, suspend, ... we could keep
running, but that seems a little niche.
If we can keep running, even in degraded mode, I see no reason to
panic. The problem is well reported in the kernel log, and having a
running system might be helpful to analyze the issue.
Thanks,
Alex.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqdomain: Remove temporary MIPS workaround code
On Fri, Jun 14, 2013 at 9:22 AM, Ralf Baechle r...@linux-mips.org wrote: On Fri, Jun 14, 2013 at 12:19:43AM +0100, Grant Likely wrote: The MIPS interrupt controllers are all registering their own irq_domains now. Drop the MIPS specific code because it is no longer needed. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Ralf Baechle r...@linux-mips.org Cc: linux-m...@linux-mips.org --- Ralf, this should be okay to pull out now. I'll be submitting it for v3.11 unless someone yells. Even if so, all the irqdomain infrastructure is in place to make it trivial to add an irqdomain where missing. I would like to merge this through the MIPS tree so it'll receive maximum testing, just in case, ok? okay. I'll keep it out of my -next branch. g. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] extcon: Add an API to get extcon device from dt node
Hi,
On Friday 14 June 2013 12:45 PM, Chanwoo Choi wrote:
From: Kishon Vijay Abraham I kis...@ti.com
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes since v1:
- If edev-name is NULL, dev_name(dev) is used as edev-name.
- Change filename from of-extcon.* to of_extcon.*
- Fix build error when CONFIG_OF is not set
- Add header file(linux/err.h) to of_extcon.c
drivers/extcon/Makefile | 2 ++
drivers/extcon/extcon-class.c| 3 +-
drivers/extcon/of_extcon.c | 64
include/linux/extcon/of_extcon.h | 30 +++
4 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/extcon/of_extcon.c
create mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..83468f7 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,6 +2,8 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF) += of_extcon.o
+
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 23f11ea..08509ea 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -602,7 +602,8 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
edev-dev-class = extcon_class;
edev-dev-release = extcon_dev_release;
- dev_set_name(edev-dev, edev-name ? edev-name : dev_name(dev));
+ edev-name = edev-name ? edev-name : dev_name(dev);
+ dev_set_name(edev-dev, edev-name);
if (edev-max_supported) {
char buf[10];
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
new file mode 100644
index 000..72173ec
--- /dev/null
+++ b/drivers/extcon/of_extcon.c
@@ -0,0 +1,64 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of_extcon.h
+
+/*
+ * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_dbg(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, unable to find device by node\n);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
+ if (!edev) {
+ dev_dbg(dev, unable to get extcon device : %s\n,
+ dev_name(extcon_parent_dev-dev));
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of_extcon.h b/include/linux/extcon/of_extcon.h
new file mode 100644
index 000..462f071
--- /dev/null
+++ b/include/linux/extcon/of_extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
[PATCH Resend] mfd: davinci_voicecodec: Convert to use devm_* APIs
devm_* APIs are device managed and make code simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Miguel Aguilar miguel.agui...@ridgerun.com
---
Patch is based on mfd-next tree and compile tested.
This driver gives following compilation error (not introduced by this patch):
drivers/mfd/davinci_voicecodec.c:86:3: error: implicit declaration
of function ‘io_v2p’ [-Werror=implicit-function-declaration]
(dma_addr_t)(io_v2p(davinci_vc-base) + DAVINCI_VC_WFIFO);
In order to test my changes I added the following to davinci_voicecodec.h file:
+#define IO_OFFSET 0xfd00 /* Virtual IO = 0xfec0 */
+#define io_v2p(va) ((va) - IO_OFFSET)
I am not sure if these changes are right fix for the above error.
---
drivers/mfd/davinci_voicecodec.c | 48 +++-
include/linux/mfd/davinci_voicecodec.h |2 --
2 files changed, 10 insertions(+), 40 deletions(-)
diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c
index b6e2973..fb64398 100644
--- a/drivers/mfd/davinci_voicecodec.c
+++ b/drivers/mfd/davinci_voicecodec.c
@@ -46,7 +46,7 @@ void davinci_vc_write(struct davinci_vc *davinci_vc,
static int __init davinci_vc_probe(struct platform_device *pdev)
{
struct davinci_vc *davinci_vc;
- struct resource *res, *mem;
+ struct resource *res;
struct mfd_cell *cell = NULL;
int ret;
@@ -58,7 +58,7 @@ static int __init davinci_vc_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- davinci_vc-clk = clk_get(pdev-dev, NULL);
+ davinci_vc-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(davinci_vc-clk)) {
dev_dbg(pdev-dev,
could not get the clock for voice codec\n);
@@ -67,35 +67,18 @@ static int __init davinci_vc_probe(struct platform_device
*pdev)
clk_enable(davinci_vc-clk);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(pdev-dev, no mem resource\n);
- ret = -ENODEV;
- goto fail2;
- }
-
- davinci_vc-pbase = res-start;
- davinci_vc-base_size = resource_size(res);
- mem = request_mem_region(davinci_vc-pbase, davinci_vc-base_size,
-pdev-name);
- if (!mem) {
- dev_err(pdev-dev, VCIF region already claimed\n);
- ret = -EBUSY;
- goto fail2;
- }
-
- davinci_vc-base = ioremap(davinci_vc-pbase, davinci_vc-base_size);
- if (!davinci_vc-base) {
- dev_err(pdev-dev, can't ioremap mem resource.\n);
- ret = -ENOMEM;
- goto fail3;
+ davinci_vc-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(davinci_vc-base)) {
+ ret = PTR_ERR(davinci_vc-base);
+ goto fail;
}
res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!res) {
dev_err(pdev-dev, no DMA resource\n);
ret = -ENXIO;
- goto fail4;
+ goto fail;
}
davinci_vc-davinci_vcif.dma_tx_channel = res-start;
@@ -106,7 +89,7 @@ static int __init davinci_vc_probe(struct platform_device
*pdev)
if (!res) {
dev_err(pdev-dev, no DMA resource\n);
ret = -ENXIO;
- goto fail4;
+ goto fail;
}
davinci_vc-davinci_vcif.dma_rx_channel = res-start;
@@ -132,19 +115,13 @@ static int __init davinci_vc_probe(struct platform_device
*pdev)
DAVINCI_VC_CELLS, NULL, 0, NULL);
if (ret != 0) {
dev_err(pdev-dev, fail to register client devices\n);
- goto fail4;
+ goto fail;
}
return 0;
-fail4:
- iounmap(davinci_vc-base);
-fail3:
- release_mem_region(davinci_vc-pbase, davinci_vc-base_size);
-fail2:
+fail:
clk_disable(davinci_vc-clk);
- clk_put(davinci_vc-clk);
- davinci_vc-clk = NULL;
return ret;
}
@@ -155,12 +132,7 @@ static int davinci_vc_remove(struct platform_device *pdev)
mfd_remove_devices(pdev-dev);
- iounmap(davinci_vc-base);
- release_mem_region(davinci_vc-pbase, davinci_vc-base_size);
-
clk_disable(davinci_vc-clk);
- clk_put(davinci_vc-clk);
- davinci_vc-clk = NULL;
return 0;
}
diff --git a/include/linux/mfd/davinci_voicecodec.h
b/include/linux/mfd/davinci_voicecodec.h
index 0ab6132..94c53d4 100644
--- a/include/linux/mfd/davinci_voicecodec.h
+++ b/include/linux/mfd/davinci_voicecodec.h
@@ -112,8 +112,6 @@ struct davinci_vc {
/* Memory resources */
void __iomem *base;
- resource_size_t pbase;
- size_t base_size;
/* MFD cells */
struct mfd_cell cells[DAVINCI_VC_CELLS];
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Re: [PATCH v2 1/3] ARM: tegra: basic support for Trusted Foundations
On Thu, Jun 13, 2013 at 11:35 PM, Dave Martin dave.mar...@arm.com wrote:
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt
b/Documentation/devicetree/bindings/arm/tegra.txt
index ed9c853..d59bc19 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -32,3 +32,14 @@ board-specific compatible values:
nvidia,whistler
toradex,colibri_t20-512
toradex,iris
+
+Optional nodes
+---
+
+Trusted Foundations:
+Boards using the Trusted Foundations secure monitor should signal its
+presence by declaring a node compatible with tl,trusted-foundations:
+
+ firmware {
You need to make a clear statement about whether the node name is
I think it shouldn't required to be exactly equal to firmware, because
that would lead to problems if there were multiple independent firmware
APIs present (which is certainly possible, whether or not it is true
on Tegra).
Yes, the name of the node is not fixed (doing so would make its lookup
faster, but the gain is not obvious). Will make it explicit in the
doc.
+ compatible = tl,trusted-foundations;
+ };
For now, it might make more sense to make this binding tegra-specific,
and to interpret the node is only implying the presence of the low-
level SoC functions you are using on Tegra, not TF as a whole.
Do you mean the vendor should be changed from tl to nvidia here?
Otherwise, it feels too generic. There is no description of exactly
what functionality will be available if this node it present: if
this is going to be a generic binding for TF, then it needs to work
for all deployments of TF, not just your specific case. For example,
how to you find out what functionality is present? Will there be
a standard probing ABI for all versions and deployments of TF, or
would extra information need to be described in the DT?
Partly, this depends on whether the TF_SET_CPU_BOOT_ADDR_SMC call will
be present, working, and with compatible ABI and semantics, on every SoC
where an implementation of TF is present. Someone from Trusted Logic, or
someone with visibility of the relevant ABI/API specs would need to
judge on that -- do you have that info?
I'm currently looking into that. This patch makes the assumption that
all TF implementations have the same features and the same interface -
if this is the case, do you agree this binding is ok as it is?
If indeed TF's functionality and ABI is the same no matter whether we
are on Tegra on not, then its support should even be moved outside of
mach-tegra.
--- /dev/null
+++ b/arch/arm/mach-tegra/firmware.c
@@ -0,0 +1,40 @@
+/*
+ * SecureOS support for Tegra CPUs
Should the name SecureOS change in these comment headers? (affects
multiple files)
Yes, I missed these ones, thanks. Another missed opportunity to use git grep...
+ node = of_find_compatible_node(NULL, NULL, tl,trusted-foundations);
+ if (node !IS_ENABLED(CONFIG_TEGRA_TRUSTED_FOUNDATIONS))
+ pr_warn(Trusted Foundations detected but support missing!\n);
Should this be more than just a warning?
It looks to me like tegra_cpu_reset_handler_set() might either silently
fail or trigger an external abort in this situation, depending on the
hardware and on how TF sets things up.
What will happen (from 3.10) is that tegra_cpu_reset_handler_set()
will output a CPUX: failed to come online for each secondary CPU and
boot will continue (albeit on one CPU). The system's features are
degraded, but it is not fatal, so I think it is reasonable to continue
here.
There seems to be no way to signal an error when attempting to set a
CPU's reset address.
Indeed. But even if that fails the system can still survive, at least on Tegra.
+#if IS_ENABLED(CONFIG_TEGRA_TRUSTED_FOUNDATIONS)
+ else if (node)
+ register_firmware_ops(tegra_trusted_foundations_ops);
+#endif
+}
IS_ENABLED() allows #ifdefs to be avoided -- maybe this would be clearer
as:
node = of_find_compatible_node(NULL, NULL, tl,trusted-foundations);
if (!node)
return;
if (WARN_ON(!IS_ENABLED(CONFIG_TEGRA_TRUSTED_FOUNDATIONS))) {
pr_warn(Trusted Foundations detected but support
missing!\n);
return;
}
register_firmware_ops(tegra_trusted_foundations_ops);
But then you will get a link error when TF support is not compiled in
because tegra_trusted_foundations_ops will not be defined. That's why
I used a #ifdef here - I agree it is terribly inelegant though.
+ asm volatile(
+ .arch_extensionsec\n\t
+ stmfd sp!, {r3 - r11, lr}\n\t
I think you don't need to save r3: the ARM PCS makes r3 caller-save, so
it shouldn't matter if the SMC call causes it to get trashed.
One less register to save, I take it! :)
Thanks,
Alex.
--
To unsubscribe from this list: send the line
Re: [PATCH v2 2/3] ARM: tegra: split setting of CPU reset handler
On Fri, Jun 14, 2013 at 4:21 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/13/2013 03:12 AM, Alexandre Courbot wrote: Not all Tegra devices need to set the CPU reset handler in the same way. s/need/can/ ? Fixed, thanks! Alex. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: pinctrl: add active state to core
* Stephen Warren swar...@wwwdotorg.org [130613 12:37]: On 06/12/2013 12:33 PM, Tony Lindgren wrote: * Linus Walleij linus.wall...@linaro.org [130611 12:59]: On Tue, Jun 11, 2013 at 6:33 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/11/2013 02:16 AM, Linus Walleij wrote: From: Linus Walleij linus.wall...@linaro.org In addition to the recently introduced pinctrl core control, the PM runtime pin control for the OMAP platforms require a fourth state in addtition to the default, idle and sleep states already handled by the core: an explicit active state. Let's introduce this to the core in addition to the other states already defined. Surely default /is/ active? That's what it's meant so far. I thought so too, until Tony informed us that in the OMAP world this state is not always the active one. But I don't know the exact reasons for. I guess that some default states on the OMAP may mean these are configured as decoupled, inactive, until explicitly activated or something like that. The main reason is that remuxing all the pins for a device for PM runtime suspend and resume is not necessary. Most pins are static and configured once during the consumer driver probe. And in most cases, remuxing only one pin for the rx line is needed. This is performance critical as it may need to be done constantly while entering and exiting idle, and remuxing all the pins is just a waste of cycles. Then isn't the correct solution to optimize the code that switches between states, so that it only reprograms the pins/groups necessary? Inventing extra states just to work around that issue seems quite wrong. Hmm how would the pinctrl subsystem know which pins to reprogram and which ones are static? So, I think you're relying on: default: Set up everything static. active: flip just a few pins to active state. idle: flip just a few pins to idle state. ... and assuming that the default-active or default-idle transitions will not affect any pins that are used in default, but not used in active/idle. Yes except the default pins are not touched after probe at all. However, that very specifically isn't the case; pinctrl drivers are allowed to force unused pins back to some default unused state when the pinctrl state that's being switched to doesn't mention them, and hence this concept won't work in general. We don't have any default state for pins for omaps at least and pinctrl single does not not set them to anything when disable is called unless function-off is specified. But even if the pinctrl driver does something to the pins in disable, that should work too. It's just an extra step between toggling between two named pin states. Also, if default uses more pins that active, when you switch to active, those pins won't be marked as owned any more, I think, so something else could in theory grab them. At least, debugfs wouldn't be entirely accurate any more. I think you're misunderstanding. The default pins are held for as long as the device is loaded. We're not touching the default pins at all after probe. Active and idle pins are not subsets of default. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ASoc: si476x: Do not use binary constants
Gcc 4.3 doesn't understand binary constants (0b*):
sound/soc/codecs/si476x.c:172:8: error: invalid suffix b110 on integer
constant
sound/soc/codecs/si476x.c:219:9: error: invalid suffix b111 on integer
constant
sound/soc/codecs/si476x.c:219:56: error: invalid suffix b111 on integer
constant
So use hexadecimal constants (0x*) instead.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Andrey Smirnov andrey.smir...@convergeddevices.net
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.de
Cc: alsa-de...@alsa-project.org
---
sound/soc/codecs/si476x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/si476x.c b/sound/soc/codecs/si476x.c
index 721587c..73e205c 100644
--- a/sound/soc/codecs/si476x.c
+++ b/sound/soc/codecs/si476x.c
@@ -38,9 +38,9 @@ enum si476x_digital_io_output_format {
SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT = 8,
};
-#define SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK((0b111
SI476X_DIGITAL_IO_SLOT_SIZE_SHIFT) | \
- (0b111
SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT))
-#define SI476X_DIGITAL_IO_OUTPUT_FORMAT_MASK (0b110)
+#define SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK((0x7
SI476X_DIGITAL_IO_SLOT_SIZE_SHIFT) | \
+ (0x7
SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT))
+#define SI476X_DIGITAL_IO_OUTPUT_FORMAT_MASK (0x7e)
enum si476x_daudio_formats {
SI476X_DAUDIO_MODE_I2S = (0x0 1),
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] extcon: Add an API to get extcon device from dt node
On 06/14/2013 05:36 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 14 June 2013 12:45 PM, Chanwoo Choi wrote:
From: Kishon Vijay Abraham I kis...@ti.com
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes since v1:
- If edev-name is NULL, dev_name(dev) is used as edev-name.
- Change filename from of-extcon.* to of_extcon.*
- Fix build error when CONFIG_OF is not set
- Add header file(linux/err.h) to of_extcon.c
drivers/extcon/Makefile | 2 ++
drivers/extcon/extcon-class.c| 3 +-
drivers/extcon/of_extcon.c | 64
include/linux/extcon/of_extcon.h | 30 +++
4 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/extcon/of_extcon.c
create mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..83468f7 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,6 +2,8 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF)+= of_extcon.o
+
obj-$(CONFIG_EXTCON)+= extcon-class.o
obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 23f11ea..08509ea 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -602,7 +602,8 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
edev-dev-class = extcon_class;
edev-dev-release = extcon_dev_release;
-dev_set_name(edev-dev, edev-name ? edev-name : dev_name(dev));
+edev-name = edev-name ? edev-name : dev_name(dev);
+dev_set_name(edev-dev, edev-name);
if (edev-max_supported) {
char buf[10];
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
new file mode 100644
index 000..72173ec
--- /dev/null
+++ b/drivers/extcon/of_extcon.c
@@ -0,0 +1,64 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of_extcon.h
+
+/*
+ * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+struct device_node *node;
+struct extcon_dev *edev;
+struct platform_device *extcon_parent_dev;
+
+if (!dev-of_node) {
+dev_dbg(dev, device does not have a device node entry\n);
+return ERR_PTR(-EINVAL);
+}
+
+node = of_parse_phandle(dev-of_node, extcon, index);
+if (!node) {
+dev_dbg(dev, failed to get phandle in %s node\n,
+dev-of_node-full_name);
+return ERR_PTR(-ENODEV);
+}
+
+extcon_parent_dev = of_find_device_by_node(node);
+if (!extcon_parent_dev) {
+dev_dbg(dev, unable to find device by node\n);
+return ERR_PTR(-EPROBE_DEFER);
+}
+
+edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
+if (!edev) {
+dev_dbg(dev, unable to get extcon device : %s\n,
+dev_name(extcon_parent_dev-dev));
+return ERR_PTR(-ENODEV);
+}
+
+return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of_extcon.h
b/include/linux/extcon/of_extcon.h
new file mode 100644
index 000..462f071
--- /dev/null
+++ b/include/linux/extcon/of_extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your
Re: [PATCH v2 3/3] ARM: tegra: set CPU reset handler with firmware op
On Fri, Jun 14, 2013 at 4:23 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
Use a firmware operation to set the CPU reset handler and only resort to
doing it ourselves if there is none defined.
This supports the booting of secondary CPUs on devices using a TrustZone
secure monitor.
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
+ err = call_firmware_op(set_cpu_boot_addr, 0, reset_address);
+ switch (err) {
+ case -ENOSYS:
+ tegra_cpu_reset_handler_set(reset_address);
+ /* pass-through */
Rather than detecting -ENOSYS and falling back to the custom
tegra_cpu_reset_handler_set(), does it make sense to plug in
tegra_cpu_reset_handler_set as the firmware op when there is no secure
firmware detected? That way, this code wouldn't need the special case;
that would be isolated to firmware.c.
Mmmm I admit I just followed what Exynos did without thinking much
about it. I don't see any reason why your suggestion wouldn't work,
but on second thought tegra_cpu_reset_handler_set() is not a firmware
operation - wouldn't it be unexpected (and maybe confusing) to have it
called through call_firmware_op()?
Alex.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 13/14] perf, persistent: Exposing persistent events using sysfs
On 14.06.13 11:36:00, Namhyung Kim wrote:
+static int pers_event_sysfs_register(struct pers_event *event)
+{
+ struct device_attribute *attr = event-sysfs.attr;
+ int idx;
+
+ *attr = (struct device_attribute)__ATTR(, 0444, pers_event_sysfs_show,
+ NULL);
+ attr-attr.name = event-name;
When I added another persistent event with this API, I got an WARNING
from lockdep like this:
[0.432506] BUG: key 88040946f140 not in .data!
[0.432581] [ cut here ]
[0.432656] WARNING: at /home/namhyung/project/linux/kernel/lockdep.c:2987
lockdep_init_map+0x53d/0x570()
[0.432763] DEBUG_LOCKS_WARN_ON(1)
I guess we need the following line here:
sysfs_attr_init(attr-attr);
Yes, added your change. Thanks Namhyung for reviewing and testing.
-Robert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [Trivial PATCH 02/33] frv: Convert use of typedef ctl_table to struct ctl_table
These look okay. Feel free to add my Acked-by. I presume they can't become const also? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/8] mm/writeback: fix wb_do_writeback exported unsafely
On Fri 14-06-13 15:30:34, Wanpeng Li wrote:
There is just one caller in fs-writeback.c call wb_do_writeback and
current codes unnecessary export it in header file, this patch fix
it by changing wb_do_writeback to static function.
So what?
Besides that git grep wb_do_writeback tells that
mm/backing-dev.c: wb_do_writeback(me, 0);
Have you tested this at all?
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
fs/fs-writeback.c | 2 +-
include/linux/writeback.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 3be5718..f892dec 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -959,7 +959,7 @@ static long wb_check_old_data_flush(struct bdi_writeback
*wb)
/*
* Retrieve work items and do the writeback they describe
*/
-long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
+static long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
{
struct backing_dev_info *bdi = wb-bdi;
struct wb_writeback_work *work;
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 579a500..e27468e 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -94,7 +94,6 @@ int try_to_writeback_inodes_sb_nr(struct super_block *,
unsigned long nr,
void sync_inodes_sb(struct super_block *);
long writeback_inodes_wb(struct bdi_writeback *wb, long nr_pages,
enum wb_reason reason);
-long wb_do_writeback(struct bdi_writeback *wb, int force_wait);
void wakeup_flusher_threads(long nr_pages, enum wb_reason reason);
void inode_wait_for_writeback(struct inode *inode);
--
1.8.1.2
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] powerpc/pci: Fix setup of Freescale PCI / PCIe controllers
Commit 50d8f87d2b3 (powerpc/fsl-pci Make PCIe hotplug work with Freescale
PCIe controllers) does not handle non-PCIe controllers properly, which causes
a panic during boot for certain configurations.
This patch fixes the issue by calling setup_indirect_pci for all device types.
fsl_indirect_read_config is now only used for booke/86xx PCIe controllers.
Reported-by: Michael Guntsche m...@it-loops.com
Cc: Scott Wood scottw...@freescale.com
Signed-off-by: Rojhalat Ibrahim i...@rtschenk.de
---
v2: Make it more consistent.
arch/powerpc/sysdev/fsl_pci.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..5682c8a 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -97,20 +97,12 @@ static int fsl_indirect_read_config(struct pci_bus *bus,
unsigned int devfn,
return indirect_read_config(bus, devfn, offset, len, val);
}
-static struct pci_ops fsl_indirect_pci_ops =
+static struct pci_ops fsl_indirect_pcie_ops =
{
.read = fsl_indirect_read_config,
.write = indirect_write_config,
};
-static void __init fsl_setup_indirect_pci(struct pci_controller* hose,
- resource_size_t cfg_addr,
- resource_size_t cfg_data, u32 flags)
-{
- setup_indirect_pci(hose, cfg_addr, cfg_data, flags);
- hose-ops = fsl_indirect_pci_ops;
-}
-
#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
#define MAX_PHYS_ADDR_BITS 40
@@ -504,13 +496,15 @@ int __init fsl_add_bridge(struct platform_device *pdev,
int is_primary)
if (!hose-private_data)
goto no_bridge;
- fsl_setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
- PPC_INDIRECT_TYPE_BIG_ENDIAN);
+ setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
+ PPC_INDIRECT_TYPE_BIG_ENDIAN);
if (in_be32(pci-block_rev1) PCIE_IP_REV_3_0)
hose-indirect_type |= PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK;
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
+ /* use fsl_indirect_read_config for PCIe */
+ hose-ops = fsl_indirect_pcie_ops;
/* For PCIE read HEADER_TYPE to identify controler mode */
early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, hdr_type);
if ((hdr_type 0x7f) != PCI_HEADER_TYPE_BRIDGE)
@@ -814,8 +808,8 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
if (ret)
goto err0;
} else {
- fsl_setup_indirect_pci(hose, rsrc_cfg.start,
- rsrc_cfg.start + 4, 0);
+ setup_indirect_pci(hose, rsrc_cfg.start,
+ rsrc_cfg.start + 4, 0);
}
printk(KERN_INFO Found FSL PCI host bridge at 0x%016llx.
--
1.8.1.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] Make non-linear GPIO ranges accesible from gpiolib
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.
That's not exactly true. The existing gpio-ranges property already
allows non-linear ranges to be represented quite easily; each entry in
the gpio-ranges list is gpio-base pinctrl-base count, so you can
piece together any mapping you want.
You're right, my description is somewhat imprecise here.
The potential advantage of this patch is that the pinctrl-side of the
mapping can be a group name rather than pin IDs, which might reduce the
size of the mapping list if you have an extremely sparse or non-linear
mapping /and/ parts of that mapping just happen to align with the pin
groups in the pin controller HW, since each entry in the gpio-ranges
property can be sparse/non-linear, rather than being a small linear
chunk of the mapping.
Pin controller authors have the freedom to define pin groups just for
the purpose of predefining the pinctrl side of GPIO ranges. For
example, the pinctrl driver from the original patch in this discussion
has different types of pin groups treated differently by the driver's
internal logic.
As an aside, for Tegra I solved this differently: In the pinctrl driver,
I simply defined the pin IDs to exactly match the GPIO IDs in order, so
the mapping is 100% linear. Of course, this only works if your pinctrl
HW documentation doesn't define any kind of numbering/ordering for your
pins, so you can pick any order you want for the pinctrl binding/driver.
This was true for Tegra20, since the HW only used groups for muxing.
Given more recent Tegra SoCs have moved to per-pin muxing, that might
not have been the best decision though, since now the HW registers at
least do have a defined ordering/ID for each pin. If only we'd started
with Tegra30 support not Tegra20:-)
My motivation of this patch is exactly the same problem put differently:
Confine the pin numbering (or what could be called a pin data base) to
the pin controller and free it from external constraints (which can be
gpio-ranges consecutiveness, customer documentation coherency or
whatever).
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
+In addition, named groups of pins can be mapped to pin groups of a given
+pin controller:
+
+ gpio_pio_g: gpio-controller@1480 {
+ #gpio-cells = 2;
+ compatible = fsl,qe-pario-bank-e, fsl,qe-pario-bank;
+ reg = 0x1480 0x18;
+ gpio-controller;
+ gpio-pingrps = pinctrl1 0, pinctrl2 3;
+ gpio-pingrp-names = pctl1_gpio_g, pctl2_gpio_g;
A few thoughts here:
gpio-pingrps doesn't sound very similar to the existing gpio-ranges.
Can we make their equivalent purpose more obvious by renaming this
gpio-group-ranges?
I'm not actually even sure we need a new property for this, except for
the string group names. We could fold the new gpio-pingrps into the
existing gpio-ranges, whose entries have the format:
gpio-base pinctrl-base count
... by saying that if count==0, it means to use a group name instead of
a pinctrl-base value. We can insist that pinctrl-base==0 in this case
too. If we go made, count==0 could mean special and pinctrl-base==0
could mean by pinctrl group name, and other values of pinctrl-base
could be added later to mean other things!
gpio-ranges =
pinctrl1 0 20 10, /* Existing numeric style */
pinctrl2 10 0 0, /* Count==0, so group name style */
pinctrl1 0 20 10, /* Existing numeric style */
gpio-ranges-group-names =
,/* No group name required for entry 0 */
gr1, /* Group name for entry 1 */
;/* No group name required for entry 2 */
Does this seem better?
I had a similar hesitation when implementing this and found the
gpio-ranges-contains-everything approach slightly confusing. On the
other hand I think it is more elegant to have only one property (plus
the strings). I didn't reach a clear conclusion and I'll happily follow
the advice of people having more device-tree experience than myself.
Just tell me if you prefer to rename the gpio-pingrps or merge
everything into gpio-ranges.
+ gpio-pingrp-names = pctl1_gpio_g, pctl2_gpio_g;
I'm slightly worried that those example group names appear to be
globally scoped. I would hope the group names are interpreted
relative-to or within the pin controller that they are associated with.
They are relative to the pin controller that they are associated with.
I wouldn't expect the pin controllers to include their own name in the
names of the pin groups they expose. In other words, I'd expect that
example to be more like:
+ gpio-pingrp-names = foo, bar;
OK, I'll change that in the doc.
+The pinctrl node must
Re: [PATCH v2] ARM: mmp: bring up pxa988 with device tree support
On Mon, Jun 10, 2013 at 4:35 PM, Arnd Bergmann a...@arndb.de wrote:
__initdata = {
.virtual= (unsigned long)AXI_VIRT_BASE,
.length = AXI_PHYS_SIZE,
.type = MT_DEVICE,
- },
+ }, {
+ .pfn= __phys_to_pfn(MMP_CORE_PERIPH_PHYS_BASE),
+ .virtual= (unsigned long)MMP_CORE_PERIPH_VIRT_BASE,
+ .length = MMP_CORE_PERIPH_PHYS_SIZE,
+ .type = MT_DEVICE,
+ }
};
void __init mmp_map_io(void)
What is this needed for?
This function is used to static map the device registers.
I understand what map_io does. Why do you need a static mapping?
The AXI and APB bus register mapping, It does not need to be static mapping.
Because we define the registers for each peripharals in device tree.
The device driver can map it.
Ok. Please try if it all keeps working without these mappings (aside
from the SCU). You can leave them in as a performance optimization
since the registers will get mapped as large pages this way, but it
should really work without them.
I would also suggest defining the virtual base addresses locally in this
file rather than globally, just to ensure that no driver starts relying
on the static mapping.
There is a exception. The address space used by core for example CPU
SCU registers for CA9.
We have to read/write the registers even device tree has not been
build up in kernel, for example -smp_prepare_cpus.
At this point, how can we get the base address for SCU?
I guess that is a problem we have on other platforms as well, we should
find a generic solution for that. It would be nice to reserve a page
in fixmap and have common code map the SCU page into that.
So you mean that reserve a page in arch/arm/asm/include/fixmap.h?
This reserve will depend on the cpu type beacuse only A9 will have SCU part.
I do not know that in fixmap, the #ifdef is acceptable or not.
For the common code to map the SCU page, where do you suggest to put it?
+/* PXA988 */
+static const struct of_dev_auxdata pxa988_auxdata_lookup[]
__initconst
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: [iput] BUG: Bad page state in process rm pfn:0b0ce
On Thu, Jun 13, 2013 at 06:25:49PM +0800, Fengguang Wu wrote: Greetings, I got the below dmesg in linux-next and the first bad commit is Thanks Fengguang. Can you try the following please? I do not see the same issue unfortunately but I am the wrong type of unlucky here. ---8--- mm: Clear page active before releasing pages Active pages should not be freed to the page allocator as it triggers a bad page state warning. Fengguang Wu reported the following bug [ 84.212960] BUG: Bad page state in process rm pfn:0b0c9 [ 84.214682] page:88000d646240 count:0 mapcount:0 mapping: (null) index:0x0 [ 84.216883] page flags: 0x204c(referenced|uptodate|active) [ 84.218697] CPU: 1 PID: 283 Comm: rm Not tainted 3.10.0-rc4-04361-geeb9bfc #49 [ 84.220729] 88000d646240 88000d179bb8 82562956 88000d179bd8 [ 84.223242] 811333f1 204c 88000d646240 88000d179c28 [ 84.225387] 811346a4 8827 0006 [ 84.227294] Call Trace: [ 84.227867] [82562956] dump_stack+0x27/0x30 [ 84.229045] [811333f1] bad_page+0x130/0x158 [ 84.230261] [811346a4] free_pages_prepare+0x8b/0x1e3 [ 84.231765] [8113542a] free_hot_cold_page+0x28/0x1cf [ 84.233171] [82585830] ? _raw_spin_unlock_irqrestore+0x6b/0xc6 [ 84.234822] [81135b59] free_hot_cold_page_list+0x30/0x5a [ 84.236311] [8113a4ed] release_pages+0x251/0x267 [ 84.237653] [8112a88d] ? delete_from_page_cache+0x48/0x9e [ 84.239142] [8113ad93] __pagevec_release+0x2b/0x3d [ 84.240473] [8113b45a] truncate_inode_pages_range+0x1b0/0x7ce [ 84.242032] [810e76ab] ? put_lock_stats.isra.20+0x1c/0x53 [ 84.243480] [810e77f5] ? lock_release_holdtime+0x113/0x11f [ 84.244935] [8113ba8c] truncate_inode_pages+0x14/0x1d [ 84.246337] [8119b3ef] evict+0x11f/0x232 [ 84.247501] [8119c527] iput+0x1a5/0x218 [ 84.248607] [8118f015] do_unlinkat+0x19b/0x25a [ 84.249828] [810ea993] ? trace_hardirqs_on_caller+0x210/0x2ce [ 84.251382] [8144372e] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 84.252879] [8118f10d] SyS_unlinkat+0x39/0x4c [ 84.254174] [825874d6] system_call_fastpath+0x1a/0x1f [ 84.255596] Disabling lock debugging due to kernel taint The problem was that a page marked for activation was released via pagevec. This patch clears the active bit before freeing in this case. Signed-off-by: Mel Gorman mgor...@suse.de --- mm/swap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/swap.c b/mm/swap.c index ac23602..4a1d0d2 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -739,6 +739,9 @@ void release_pages(struct page **pages, int nr, int cold) del_page_from_lru_list(page, lruvec, page_off_lru(page)); } + /* Clear Active bit in case of parallel mark_page_accessed */ + ClearPageActive(page); + list_add(page-lru, pages_to_free); } if (zone) -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] pinctrl: add function to parse generic pinconfig properties from a dt node
Am Freitag, 14. Juni 2013, 01:53:49 schrieb Laurent Pinchart: Hi Linus, On Thursday 13 June 2013 17:36:00 Linus Walleij wrote: On Thu, Jun 13, 2013 at 5:23 PM, Heiko Stübner he...@sntech.de wrote: Ok, I'll see that I get this fixed :-) Hmm ... what is the meaning of the argument of bias-disable and bias-high- impedance, as the kernel-doc in pinconf-generic.h does not tell? I think those arguments are N/A, ignored, doesn't matter. If these options were typed, they would be bool. Please improve documentation if you can... sorry for all the rough edges. bias-bus-hold ignores its argument and we already clarified that the pull-* do have != 0 or 0 argument. I think in the DT binding, both these forms: bias-pull-up; bias-pull-up = 15; Should be allowed. So when parsing, you first check if it exists, then if there is an argument, if there is no value supplied, just set it to 1, as that is clearly != 0... What's the expected way to disable pull-ups in DT ? Should it be 'bias-pull-up = 0;' or 'bias-disable;' ? According to the kernedoc I think both are valid and should be handled. Using bias-disable is more descriptive but would also include disabling a high- impedance or bus-hold bias (if supported by the hardware). Personally, for my rockchip stuff I go with using the bias-pull-pin-default - bias-disable. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
Hi, On Friday 14 June 2013 01:47 PM, Tomi Valkeinen wrote: On 14/06/13 10:33, Tony Lindgren wrote: If we want to fix something this late in the merge window, the patches must have a clear description what caused the regression and what happens without the patches. These patches don't have that. And they are marked RFC also. So actually I'm not applying any of them before the regression descriptions are there and the patches have been reposted without RFC and have sufficient acks from people. I posted this as RFC since this series uses _label_ and initially Felipe din't want to find PHYs by _label_. After the device names are created using PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't work reliable (since the device name changes). And I couldn't think of any other way to find the PHY other than using _label_. So I just wanted to know if it's ok to use _label_ or if there is any other better way to find PHYs. No disagreement there. Kishon, I tested the patches on top of v3.10-rc5, booting with nfs root via usb gadget eth: Overo: works Beagle: works, but I need to reconnect the usb cable after kernel is up Beagle-xm: doesn't work. The cable is detected correctly, though Panda: works The problems with Beagles are there even without these patches, so they do make things better (fix Overo). Thanks for testing this. I'll post a new version removing RFC after Felipe ACKs it. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/8] mm/writeback: fix wb_do_writeback exported unsafely
Michal Hocko wrote: On Fri 14-06-13 15:30:34, Wanpeng Li wrote: There is just one caller in fs-writeback.c call wb_do_writeback and current codes unnecessary export it in header file, this patch fix it by changing wb_do_writeback to static function. So what? Besides that git grep wb_do_writeback tells that mm/backing-dev.c: wb_do_writeback(me, 0); Have you tested this at all? Commit 839a8e8 removes that. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com -- Kirill A. Shutemov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] memcg: do not sleep on OOM waitqueue with full charge context
On Thu 13-06-13 13:34:46, David Rientjes wrote: On Thu, 13 Jun 2013, Michal Hocko wrote: Right now it appears that that number of users is 0 and we're talking about a problem that was reported in 3.2 that was released a year and a half ago. The rules of inclusion in stable also prohibit such a change from being backported, specifically It must fix a real bug that bothers people (not a, This could be a problem... type thing). As you can see there is an user seeing this in 3.2. The bug is _real_ and I do not see what you are objecting against. Do you really think that sitting on a time bomb is preferred more? Nobody has reported the problem in seven months. You're patching a kernel that's 18 months old. Your user hasn't even bothered to respond to your backport. This isn't a timebomb. Doh. This is getting ridiculous! So you are claiming that oom blocking while the task might be sitting on an unpredictable amount of locks which could block oom victims to die is OK? I would consider it a _bug_ and I am definitely backporting it to our kernel which is 3.0 based whether it end up in the stable or not. Whether this is a general stable material I will leave for others (I would be voting for it because it definitely makes sense). The real regardless how many users suffer from it. The stable-or-not discussion shouldn't delay the fix for the current tree though. Or do you disagree with the patch itself? We have deployed memcg on a very large number of machines and I can run a query over all software watchdog timeouts that have occurred by deadlocking on i_mutex during memcg oom. It returns 0 results. Do you capture /prc/pid/stack for each of them to find that your deadlock (and you have reported that they happen) was in fact caused by a locking issue? These kind of deadlocks might got unnoticed especially when the oom is handled by userspace by increasing the limit (my mmecg is stuck and increasing the limit a bit always helped). We dump stack traces for every thread on the system to the kernel log for a software watchdog timeout and capture it over the network for searching later. We have not experienced any deadlock that even remotely resembles the stack traces in the chnagelog. We do not reproduce this issue. OK. This could really rule it out for you. The analysis is not really trivial because locks might be hidden nicely but having the data is definitely useful. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/8] mm/writeback: fix wb_do_writeback exported unsafely
On Fri, Jun 14, 2013 at 03:30:34PM +0800, Wanpeng Li wrote:
There is just one caller in fs-writeback.c call wb_do_writeback and
current codes unnecessary export it in header file, this patch fix
it by changing wb_do_writeback to static function.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
Hi Wanpeng,
A simliar patch has been merged in -next tree with commit#:
836f29bbb0f7a08dbdf1ed3ee704ef8aea81e56f
BTW, actually this should have nothing to do with safety, just unnecessary to
export it globally.
---
fs/fs-writeback.c | 2 +-
include/linux/writeback.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 3be5718..f892dec 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -959,7 +959,7 @@ static long wb_check_old_data_flush(struct bdi_writeback
*wb)
/*
* Retrieve work items and do the writeback they describe
*/
-long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
+static long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
{
struct backing_dev_info *bdi = wb-bdi;
struct wb_writeback_work *work;
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 579a500..e27468e 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -94,7 +94,6 @@ int try_to_writeback_inodes_sb_nr(struct super_block *,
unsigned long nr,
void sync_inodes_sb(struct super_block *);
long writeback_inodes_wb(struct bdi_writeback *wb, long nr_pages,
enum wb_reason reason);
-long wb_do_writeback(struct bdi_writeback *wb, int force_wait);
void wakeup_flusher_threads(long nr_pages, enum wb_reason reason);
void inode_wait_for_writeback(struct inode *inode);
--
1.8.1.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /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] metag: fix mm/hugetlb.c build breakage
Commit 106c992a5ebef28193cf5958e49ceff5e4aebb04 (mm/hugetlb: add more arch-defined huge_pte functions) merged in v3.10-rc1. The above commit added an include of asm-generic/hugetlb.h to each architecture's asm/hugetlb.h (except s390). Unfortunately metag was missed which resulted in build errors when hugetlbfs is enabled (see below). Add the include for metag too to fix the build errors. mm/hugetlb.c In function 'make_huge_pte': mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkwrite' mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkdirty' mm/hugetlb.c +2250 : error: implicit declaration of function 'mk_huge_pte' mm/hugetlb.c +2251 : error: incompatible types in assignment mm/hugetlb.c +2254 : error: incompatible type for argument 1 of 'huge_pte_wrprotect' mm/hugetlb.c In function 'set_huge_ptep_writable': mm/hugetlb.c +2268 : error: incompatible types in assignment mm/hugetlb.c In function '__unmap_hugepage_range': mm/hugetlb.c +2383 : error: implicit declaration of function 'huge_pte_clear' mm/hugetlb.c +2407 : error: implicit declaration of function 'huge_pte_dirty' mm/hugetlb.c In function 'hugetlb_fault': mm/hugetlb.c +2860 : error: implicit declaration of function 'huge_pte_write' mm/hugetlb.c +2895 : error: incompatible types in assignment mm/hugetlb.c In function 'hugetlb_change_protection': mm/hugetlb.c +3047 : error: implicit declaration of function 'huge_pte_modify' mm/hugetlb.c +3047 : error: incompatible type for argument 1 of 'pte_mkhuge' make[1]: *** [mm/hugetlb.o] Error 1 make: *** [mm/hugetlb.o] Error 2 Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Gerald Schaefer gerald.schae...@de.ibm.com Cc: Andrew Morton a...@linux-foundation.org Cc: Michal Hocko mho...@suse.cz --- arch/metag/include/asm/hugetlb.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/metag/include/asm/hugetlb.h b/arch/metag/include/asm/hugetlb.h index f545477..471f481 100644 --- a/arch/metag/include/asm/hugetlb.h +++ b/arch/metag/include/asm/hugetlb.h @@ -2,6 +2,7 @@ #define _ASM_METAG_HUGETLB_H #include asm/page.h +#include asm-generic/hugetlb.h static inline int is_hugepage_only_range(struct mm_struct *mm, -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] mm/writeback: fix wb_do_writeback exported unsafely
On Fri 14-06-13 12:29:52, Kirill A. Shutemov wrote: Michal Hocko wrote: On Fri 14-06-13 15:30:34, Wanpeng Li wrote: There is just one caller in fs-writeback.c call wb_do_writeback and current codes unnecessary export it in header file, this patch fix it by changing wb_do_writeback to static function. So what? Besides that git grep wb_do_writeback tells that mm/backing-dev.c: wb_do_writeback(me, 0); Have you tested this at all? Commit 839a8e8 removes that. OK, I didn't check the most up-to-date tree. Sorry about this confusion. I do not object to cleanups like this but it should be clear they are cleanups. fix wb_do_writeback exported unsafely sounds like a fix rather than a cleanup Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/7] Convert GPIO Davinci to platform driver
To support DT booting of da850 EVM, davinci gpio driver converted to platform driver. Also when here, start using gpiolib API for gpio get/set functionalities. Hence removing gpio inline functionalities. However usage of gpiolib API will cause an additional software latencies. In this patch series - Cleaned gpio Davinci driver code with proper commenting style. - Create platform driver for GPIO Davinci in da8xx and dmxxx platforms and removed gpio related member updation in davinci_soc_info structure. - Remove soc_info reference in the gpio davinci driver and start uses gpiolib interface. - gpio-tnetv107x driver also modified to use gpiolib API interface. This series has been tested on da850 EVM for gpio interrupt generation. This patch series is based on Linux 3.10-rc4 and is availabel at [1]. 1. https://github.com/avinashphilip/am335x_linux/tree/linux_davinci_v3.10_soc_gpio_v310-rc4 KV Sujith (2): gpio: davinci: move to platform device ARM: davinci: da8xx: creation of gpio platform device Philip Avinash (5): gpio: davinci: coding style correction ARM: davinci: creation of gpio platform device for dmxxx platforms ARM: davinci: da8xx: gpio device creation ARM: davinci: dmxxx: gpio device creation ARM: davinci: Start using gpiolib API inplace of inline functions arch/arm/Kconfig |1 - arch/arm/mach-davinci/board-da830-evm.c | 19 ++- arch/arm/mach-davinci/board-da850-evm.c | 11 ++ arch/arm/mach-davinci/board-dm355-evm.c | 27 arch/arm/mach-davinci/board-dm355-leopard.c |1 + arch/arm/mach-davinci/board-dm365-evm.c | 28 arch/arm/mach-davinci/board-dm644x-evm.c | 26 arch/arm/mach-davinci/board-dm646x-evm.c | 27 arch/arm/mach-davinci/board-neuros-osd2.c |1 + arch/arm/mach-davinci/board-omapl138-hawk.c |2 + arch/arm/mach-davinci/da830.c |5 - arch/arm/mach-davinci/da850.c |5 - arch/arm/mach-davinci/devices-da8xx.c | 26 arch/arm/mach-davinci/devices.c | 13 ++ arch/arm/mach-davinci/dm355.c |5 - arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/dm644x.c|5 - arch/arm/mach-davinci/dm646x.c|5 - arch/arm/mach-davinci/include/mach/common.h |4 + arch/arm/mach-davinci/include/mach/da8xx.h|1 + arch/arm/mach-davinci/include/mach/gpio-davinci.h | 91 - arch/arm/mach-davinci/include/mach/gpio.h | 88 - arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/gpio/gpio-davinci.c | 144 ++--- drivers/gpio/gpio-tnetv107x.c |1 + include/linux/platform_data/gpio-davinci.h| 59 + 26 files changed, 341 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/mach-davinci/include/mach/gpio-davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/gpio.h create mode 100644 include/linux/platform_data/gpio-davinci.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/7] gpio: davinci: coding style correction
Make some minor coding style fixes. Use proper multi-line
commenting style, arrange include files alphabetically use
macros for bit definitions.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Changes since v1:
- Remove variable name replacement
- Add line break after BINTEN macro definition
drivers/gpio/gpio-davinci.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 17df6db..e8d189c 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -9,12 +9,12 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
-#include linux/gpio.h
-#include linux/errno.h
-#include linux/kernel.h
+
#include linux/clk.h
-#include linux/err.h
+#include linux/errno.h
+#include linux/gpio.h
#include linux/io.h
+#include linux/kernel.h
#include asm/mach/irq.h
@@ -31,6 +31,8 @@ struct davinci_gpio_regs {
u32 intstat;
};
+#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
+
#define chip2controller(chip) \
container_of(chip, struct davinci_gpio_controller, chip)
@@ -304,7 +306,8 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
- /* NOTE: we assume for now that only irqs in the first gpio_chip
+ /*
+* NOTE: we assume for now that only irqs in the first gpio_chip
* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
*/
if (offset soc_info-gpio_unbanked)
@@ -368,7 +371,8 @@ static int __init davinci_gpio_irq_setup(void)
}
clk_prepare_enable(clk);
- /* Arrange gpio_to_irq() support, handling either direct IRQs or
+ /*
+* Arrange gpio_to_irq() support, handling either direct IRQs or
* banked IRQs. Having GPIOs in the first GPIO bank use direct
* IRQs, while the others use banked IRQs, would need some setup
* tweaks to recognize hardware which can do that.
@@ -450,10 +454,11 @@ static int __init davinci_gpio_irq_setup(void)
}
done:
- /* BINTEN -- per-bank interrupt enable. genirq would also let these
+ /*
+* BINTEN -- per-bank interrupt enable. genirq would also let these
* bits be set/cleared dynamically.
*/
- __raw_writel(binten, gpio_base + 0x08);
+ __raw_writel(binten, gpio_base + BINTEN);
printk(KERN_INFO DaVinci: %d gpio irqs\n, irq - gpio_to_irq(0));
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/7] ARM: davinci: da8xx: creation of gpio platform device
From: KV Sujith sujit...@ti.com
gpio controller resource information being associated with
davinci_soc_info structure and not created any device. Hence davinci
gpio didn't fall under proper device model. This patch creates gpio
davinci as a platform device for da8xx platforms.
- Add Memory and IRQ resources for da8xx
- Register GPIO platform driver for da8xx.
- Add da8xx_register_gpio API to create platform device for da8xx
platforms.
Signed-off-by: KV Sujith sujit...@ti.com
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 26 ++
arch/arm/mach-davinci/include/mach/da8xx.h |1 +
2 files changed, 27 insertions(+)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..892ad86 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -640,6 +640,32 @@ int __init da8xx_register_lcdc(struct
da8xx_lcdc_platform_data *pdata)
return platform_device_register(da8xx_lcdc_device);
}
+static struct resource da8xx_gpio_resources[] = {
+ { /* registers */
+ .start = DA8XX_GPIO_BASE,
+ .end= DA8XX_GPIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* interrupt */
+ .start = IRQ_DA8XX_GPIO0,
+ .end= IRQ_DA8XX_GPIO8,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device da8xx_gpio_device = {
+ .name = davinci_gpio,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(da8xx_gpio_resources),
+ .resource = da8xx_gpio_resources,
+};
+
+int __init da8xx_register_gpio(void *pdata)
+{
+ da8xx_gpio_device.dev.platform_data = pdata;
+ return platform_device_register(da8xx_gpio_device);
+}
+
static struct resource da8xx_mmcsd0_resources[] = {
{ /* registers */
.start = DA8XX_MMCSD0_BASE,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
index 2e1c9ea..aa66690 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -96,6 +96,7 @@ int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
int da850_register_mmcsd1(struct davinci_mmc_config *config);
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata);
int da8xx_register_rtc(void);
+int da8xx_register_gpio(void *pdata);
int da850_register_cpufreq(char *async_clk);
int da8xx_register_cpuidle(void);
void __iomem * __init da8xx_get_mem_ctlr(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/7] gpio: davinci: move to platform device
From: KV Sujith sujit...@ti.com
Modify GPIO Davinci driver to be compliant to standard platform drivers.
The driver did not have platform driver structure or a probe. Instead,
had a davinci_gpio_setup() function which is called in the pure_init
sequence. The function also had dependency on davinci_soc_info structure
of the corresponding platform. For Device Tree(DT) implementation, we
need to get rid of the dependency on the davinci_soc_info structure.
Hence as a first stage of DT conversion, we implement a probe. Future
commits shall modify the probe to read platform related data from DT.
- Add platform_driver structure and driver register function for davinci
GPIO driver. The driver registration is made to happen in
postcore_initcall. This is required since machine init functions like
da850_lcd_hw_init() make use of GPIO.
- Convert the davinci_gpio_setup() to davinci_gpio_probe().
- Remove access of members in soc_info structure. Instead, relevant data
are taken from davinci_gpio_platform_data structure pointed by
pdev-dev.platform_data.
- Change clk_get() to devm_clk_get() as devm_clk_get() is a device
managed function and makes error handling simpler.
- Change pr_err to dev_err for ngpio error reporting.
- Arrange include files in alphabetical order
- Add struct davinci_gpio_platform_data davinci for gpio module.
Signed-off-by: KV Sujith sujit...@ti.com
[avinashphi...@ti.com: Move global definition for struct
davinci_gpio_controller variable to local in probe and set it as driver
data.]
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Changes since v1:
- Merge header file to drivermodification patch
- Return error value updated.
- line break alignment fixing.
arch/arm/mach-davinci/include/mach/gpio-davinci.h |2 +
drivers/gpio/gpio-davinci.c | 123 ++---
include/linux/platform_data/gpio-davinci.h| 25 +
3 files changed, 112 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/gpio-davinci.h
b/arch/arm/mach-davinci/include/mach/gpio-davinci.h
index 1fdd1fd..b325a1d 100644
--- a/arch/arm/mach-davinci/include/mach/gpio-davinci.h
+++ b/arch/arm/mach-davinci/include/mach/gpio-davinci.h
@@ -60,6 +60,8 @@ struct davinci_gpio_controller {
void __iomem*set_data;
void __iomem*clr_data;
void __iomem*in_data;
+ int gpio_unbanked;
+ unsignedgpio_irq;
};
/* The __gpio_to_controller() and __gpio_mask() functions inline to constants
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index e8d189c..475a5ece 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -11,12 +11,17 @@
*/
#include linux/clk.h
+#include linux/device.h
#include linux/errno.h
#include linux/gpio.h
#include linux/io.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/irqdomain.h
#include linux/kernel.h
-
-#include asm/mach/irq.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/platform_data/gpio-davinci.h
struct davinci_gpio_regs {
u32 dir;
@@ -36,10 +41,9 @@ struct davinci_gpio_regs {
#define chip2controller(chip) \
container_of(chip, struct davinci_gpio_controller, chip)
-static struct davinci_gpio_controller chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
static void __iomem *gpio_base;
-static struct davinci_gpio_regs __iomem __init *gpio2regs(unsigned gpio)
+static struct davinci_gpio_regs __iomem *gpio2regs(unsigned gpio)
{
void __iomem *ptr;
@@ -67,7 +71,7 @@ static inline struct davinci_gpio_regs __iomem *irq2regs(int
irq)
return g;
}
-static int __init davinci_gpio_irq_setup(void);
+static int davinci_gpio_irq_setup(struct platform_device *pdev);
/*--*/
@@ -133,33 +137,53 @@ davinci_gpio_set(struct gpio_chip *chip, unsigned offset,
int value)
__raw_writel((1 offset), value ? g-set_data : g-clr_data);
}
-static int __init davinci_gpio_setup(void)
+static int davinci_gpio_probe(struct platform_device *pdev)
{
int i, base;
unsigned ngpio;
- struct davinci_soc_info *soc_info = davinci_soc_info;
- struct davinci_gpio_regs *regs;
-
- if (soc_info-gpio_type != GPIO_TYPE_DAVINCI)
- return 0;
+ struct davinci_gpio_controller *chips;
+ struct davinci_gpio_platform_data *pdata;
+ struct davinci_gpio_regs __iomem *regs;
+ struct device *dev = pdev-dev;
+ struct resource *res;
+
+ pdata = dev-platform_data;
+ if (!pdata) {
+ dev_err(dev, No platform data found\n);
+ return -EINVAL;
+ }
/*
* The gpio banks conceptually expose a segmented bitmap,
*
[PATCH v2 7/7] ARM: davinci: Start using gpiolib API inplace of inline functions
Remove NEED_MACH_GPIO_H config select option for ARCH_DAVINCI to start use gpiolib interface for davinci platforms. However with this software latencies for gpio_get/set APIs will affect. Latency has increased by 18 microsecond with gpiolib API as compared with inline API's. Software latency is calculated on da850 EVM for gpio_get_value API by taking the printk timing for API execution with interrupts disabled. Experiment has done for inline and gpiolib API interface. inline gpio API with interrupt disabled [ 29.734337] before gpio_get [ 29.736847] after gpio_get Time difference 0.00251 gpio library with interrupt disabled [ 272.876763] before gpio_get [ 272.879291] after gpio_get Time difference 0.002528 Latency increased by (0.002528 - 0.00251) = 18 microsecond. Also being here - Moved following definitions from mach folder to include directory struct davinci_gpio_controller Macro GPIO(x) inline function __gpio_mask - Removed GPIO_TYPE_DAVINCI enum definition as GPIO Davinci is converted to Linux device driver model. - With removal of select option of NEED_MACH_GPIO_H for ARCH_DAVINCI, gpio-tnetv107x also start using gpiolib interface. Hence removes related header files arch/arm/mach-davinci/include/mach/gpio-davinci.h arch/arm/mach-davinci/include/mach/gpio.h and include linux/platform_data/gpio-davinci.h header file to support gpio-davinci platform definitions. Signed-off-by: Philip Avinash avinashphi...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com --- Changes since v1: - Remove inline GPIO API support for tnetv107x platforms - Remove gpio header files in mach directory. - Remove include of gpio header files from mach directory. - Moved enum davinci_gpio_type to include folder - Replace __ASM_ARCH_DAVINCI_GPIO_H with __DAVINCI_GPIO_PLATFORM_H arch/arm/Kconfig |1 - arch/arm/mach-davinci/da830.c |1 - arch/arm/mach-davinci/da850.c |1 - arch/arm/mach-davinci/dm355.c |1 - arch/arm/mach-davinci/dm365.c |1 - arch/arm/mach-davinci/dm644x.c|1 - arch/arm/mach-davinci/dm646x.c|1 - arch/arm/mach-davinci/include/mach/gpio-davinci.h | 93 - arch/arm/mach-davinci/include/mach/gpio.h | 88 --- arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/gpio/gpio-tnetv107x.c |1 + include/linux/platform_data/gpio-davinci.h| 34 12 files changed, 36 insertions(+), 189 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 49d993c..4d099fe 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -839,7 +839,6 @@ config ARCH_DAVINCI select GENERIC_CLOCKEVENTS select GENERIC_IRQ_CHIP select HAVE_IDE - select NEED_MACH_GPIO_H select USE_OF select ZONE_DMA help diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c index e7b79ee..0f2cb28 100644 --- a/arch/arm/mach-davinci/da830.c +++ b/arch/arm/mach-davinci/da830.c @@ -20,7 +20,6 @@ #include mach/common.h #include mach/time.h #include mach/da8xx.h -#include mach/gpio-davinci.h #include clock.h #include mux.h diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index de8753d..cf62641 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -28,7 +28,6 @@ #include mach/da8xx.h #include mach/cpufreq.h #include mach/pm.h -#include mach/gpio-davinci.h #include clock.h #include mux.h diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index f7a18ff..9564202 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -27,7 +27,6 @@ #include mach/serial.h #include mach/common.h #include linux/platform_data/spi-davinci.h -#include mach/gpio-davinci.h #include davinci.h #include clock.h diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 2c80a6b..8c8c0de 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -31,7 +31,6 @@ #include mach/common.h #include linux/platform_data/keyscan-davinci.h #include linux/platform_data/spi-davinci.h -#include mach/gpio-davinci.h #include davinci.h #include clock.h diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 9e23e64..75146b5 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -23,7 +23,6 @@ #include mach/time.h #include mach/serial.h #include mach/common.h -#include mach/gpio-davinci.h #include davinci.h #include clock.h diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 1058e7c..d15a36c 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -24,7
RE: [PATCH v2 0/7] Convert GPIO Davinci to platform driver
Sender mail id got corrupted. I will send another. Thanks Avinash On Fri, Jun 14, 2013 at 15:04:34, y...@symphony.india.ext.ti.com wrote: From: Philip Avinash avinashphi...@ti.com To support DT booting of da850 EVM, davinci gpio driver converted to platform driver. Also when here, start using gpiolib API for gpio get/set functionalities. Hence removing gpio inline functionalities. However usage of gpiolib API will cause an additional software latencies. In this patch series - Cleaned gpio Davinci driver code with proper commenting style. - Create platform driver for GPIO Davinci in da8xx and dmxxx platforms and removed gpio related member updation in davinci_soc_info structure. - Remove soc_info reference in the gpio davinci driver and start uses gpiolib interface. - gpio-tnetv107x driver also modified to use gpiolib API interface. This series has been tested on da850 EVM for gpio interrupt generation. This patch series is based on Linux 3.10-rc4 and is availabel at [1]. 1. https://github.com/avinashphilip/am335x_linux/tree/linux_davinci_v3.10_soc_gpio_v310-rc4 KV Sujith (2): gpio: davinci: move to platform device ARM: davinci: da8xx: creation of gpio platform device Philip Avinash (5): gpio: davinci: coding style correction ARM: davinci: creation of gpio platform device for dmxxx platforms ARM: davinci: da8xx: gpio device creation ARM: davinci: dmxxx: gpio device creation ARM: davinci: Start using gpiolib API inplace of inline functions arch/arm/Kconfig |1 - arch/arm/mach-davinci/board-da830-evm.c | 19 ++- arch/arm/mach-davinci/board-da850-evm.c | 11 ++ arch/arm/mach-davinci/board-dm355-evm.c | 27 arch/arm/mach-davinci/board-dm355-leopard.c |1 + arch/arm/mach-davinci/board-dm365-evm.c | 28 arch/arm/mach-davinci/board-dm644x-evm.c | 26 arch/arm/mach-davinci/board-dm646x-evm.c | 27 arch/arm/mach-davinci/board-neuros-osd2.c |1 + arch/arm/mach-davinci/board-omapl138-hawk.c |2 + arch/arm/mach-davinci/da830.c |5 - arch/arm/mach-davinci/da850.c |5 - arch/arm/mach-davinci/devices-da8xx.c | 26 arch/arm/mach-davinci/devices.c | 13 ++ arch/arm/mach-davinci/dm355.c |5 - arch/arm/mach-davinci/dm365.c |6 - arch/arm/mach-davinci/dm644x.c|5 - arch/arm/mach-davinci/dm646x.c|5 - arch/arm/mach-davinci/include/mach/common.h |4 + arch/arm/mach-davinci/include/mach/da8xx.h|1 + arch/arm/mach-davinci/include/mach/gpio-davinci.h | 91 - arch/arm/mach-davinci/include/mach/gpio.h | 88 - arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/gpio/gpio-davinci.c | 144 ++--- drivers/gpio/gpio-tnetv107x.c |1 + include/linux/platform_data/gpio-davinci.h| 59 + 26 files changed, 341 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/mach-davinci/include/mach/gpio-davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/gpio.h create mode 100644 include/linux/platform_data/gpio-davinci.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/7] ARM: davinci: da8xx: gpio device creation
Create davinci gpio device and remove references in davinci_soc_info
structure. Also rearrange header file inclusion in group basis.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-da830-evm.c | 19 +++
arch/arm/mach-davinci/board-da850-evm.c | 11 +++
arch/arm/mach-davinci/board-omapl138-hawk.c |2 ++
arch/arm/mach-davinci/da830.c |4
arch/arm/mach-davinci/da850.c |4
5 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 1332de8..4e8bcc1 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -22,17 +22,19 @@
#include linux/mtd/partitions.h
#include linux/spi/spi.h
#include linux/spi/flash.h
+#include linux/platform_data/mtd-davinci.h
+#include linux/platform_data/gpio-davinci.h
+#include linux/platform_data/usb-davinci.h
+#include linux/platform_data/mtd-davinci-aemif.h
+#include linux/platform_data/spi-davinci.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include mach/cp_intc.h
#include mach/mux.h
-#include linux/platform_data/mtd-davinci.h
+#include mach/common.h
#include mach/da8xx.h
-#include linux/platform_data/usb-davinci.h
-#include linux/platform_data/mtd-davinci-aemif.h
-#include linux/platform_data/spi-davinci.h
#define DA830_EVM_PHY_ID
/*
@@ -590,11 +592,20 @@ static struct spi_board_info da830evm_spi_info[] = {
},
};
+static struct davinci_gpio_platform_data da830_gpio_platform_data = {
+ .ngpio = 128,
+ .intc_irq_num = DA830_N_CP_INTC_IRQ,
+};
+
static __init void da830_evm_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
int ret;
+ ret = da8xx_register_gpio(da830_gpio_platform_data);
+ if (ret)
+ pr_warn(da830_evm_init: GPIO init failed: %d\n, ret);
+
ret = da830_register_edma(da830_edma_rsv);
if (ret)
pr_warning(da830_evm_init: edma registration failed: %d\n,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..d5dd010 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -28,6 +28,7 @@
#include linux/mtd/partitions.h
#include linux/mtd/physmap.h
#include linux/platform_device.h
+#include linux/platform_data/gpio-davinci.h
#include linux/platform_data/mtd-davinci.h
#include linux/platform_data/mtd-davinci-aemif.h
#include linux/platform_data/spi-davinci.h
@@ -42,6 +43,7 @@
#include mach/da8xx.h
#include mach/mux.h
#include mach/sram.h
+#include mach/common.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -1138,6 +1140,11 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
da850_edma_cc1_rsv,
};
+static struct davinci_gpio_platform_data da850_gpio_platform_data = {
+ .ngpio = 144,
+ .intc_irq_num = DA850_N_CP_INTC_IRQ,
+};
+
#ifdef CONFIG_CPU_FREQ
static __init int da850_evm_init_cpufreq(void)
{
@@ -1444,6 +1451,10 @@ static __init void da850_evm_init(void)
{
int ret;
+ ret = da8xx_register_gpio(da850_gpio_platform_data);
+ if (ret)
+ pr_warn(da850_evm_init: GPIO init failed: %d\n, ret);
+
ret = pmic_tps65070_init();
if (ret)
pr_warn(%s: TPS65070 PMIC init failed: %d\n, __func__, ret);
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index b8c20de..1f44a1b 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/console.h
#include linux/gpio.h
+#include linux/platform_data/gpio-davinci.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -20,6 +21,7 @@
#include mach/cp_intc.h
#include mach/da8xx.h
#include mach/mux.h
+#include mach/common.h
#define HAWKBOARD_PHY_ID davinci_mdio-0:07
#define DA850_HAWK_MMCSD_CD_PINGPIO_TO_PIN(3, 12)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index abbaf02..e7b79ee 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1195,10 +1195,6 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
.intc_irq_prios = da830_default_priorities,
.intc_irq_num = DA830_N_CP_INTC_IRQ,
.timer_info = da830_timer_info,
- .gpio_type = GPIO_TYPE_DAVINCI,
- .gpio_base = DA8XX_GPIO_BASE,
- .gpio_num = 128,
- .gpio_irq = IRQ_DA8XX_GPIO0,
.serial_dev = da8xx_serial_device,
.emac_pdata = da8xx_emac_pdata,
};
diff --git
[PATCH v2 6/7] ARM: davinci: dmxxx: gpio device creation
Create davinci gpio device and remove gpio references in
davinci_soc_info structure for dmxxx platforms. Also add Memory and IRQ
resources for GPIO platform device.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Changes since v1:
- Add commit message
arch/arm/mach-davinci/board-dm355-evm.c | 27 ++
arch/arm/mach-davinci/board-dm355-leopard.c |1 +
arch/arm/mach-davinci/board-dm365-evm.c | 28 +++
arch/arm/mach-davinci/board-dm644x-evm.c| 26 +
arch/arm/mach-davinci/board-dm646x-evm.c| 27 ++
arch/arm/mach-davinci/board-neuros-osd2.c |1 +
arch/arm/mach-davinci/dm355.c |4
arch/arm/mach-davinci/dm365.c |5 -
arch/arm/mach-davinci/dm644x.c |4
arch/arm/mach-davinci/dm646x.c |4
arch/arm/mach-davinci/include/mach/common.h |2 ++
11 files changed, 112 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index c2a0a67..05e6e86 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -28,9 +28,11 @@
#include linux/platform_data/i2c-davinci.h
#include mach/serial.h
+#include mach/common.h
#include linux/platform_data/mtd-davinci.h
#include linux/platform_data/mmc-davinci.h
#include linux/platform_data/usb-davinci.h
+#include linux/platform_data/gpio-davinci.h
#include davinci.h
@@ -376,9 +378,34 @@ static struct spi_board_info dm355_evm_spi_info[]
__initconst = {
},
};
+static struct resource dm355_gpio_resources[] = {
+ { /* registers */
+ .start = DAVINCI_GPIO_BASE,
+ .end= DAVINCI_GPIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* interrupt */
+ .start = IRQ_DM355_GPIOBNK0,
+ .end= IRQ_DM355_GPIOBNK6,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct davinci_gpio_platform_data dm355_gpio_platform_data = {
+ .ngpio = 104,
+ .intc_irq_num = DAVINCI_N_AINTC_IRQ,
+};
+
static __init void dm355_evm_init(void)
{
struct clk *aemif;
+ int ret;
+
+ ret = davinci_gpio_register(dm355_gpio_resources,
+ sizeof(dm355_gpio_resources),
+ dm355_gpio_platform_data);
+ if (ret)
+ pr_warn(dm355_evm_init: GPIO init failed: %d\n, ret);
gpio_request(1, dm9000);
gpio_direction_input(1);
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index dff4ddc..34a2b64 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -25,6 +25,7 @@
#include linux/platform_data/i2c-davinci.h
#include mach/serial.h
+#include mach/common.h
#include linux/platform_data/mtd-davinci.h
#include linux/platform_data/mmc-davinci.h
#include linux/platform_data/usb-davinci.h
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index fd38c8d..60f7b84 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -39,6 +39,7 @@
#include linux/platform_data/mmc-davinci.h
#include linux/platform_data/mtd-davinci.h
#include linux/platform_data/keyscan-davinci.h
+#include linux/platform_data/gpio-davinci.h
#include media/ths7303.h
#include media/tvp514x.h
@@ -746,8 +747,35 @@ static struct spi_board_info dm365_evm_spi_info[]
__initconst = {
},
};
+static struct resource dm365_gpio_resources[] = {
+ { /* registers */
+ .start = DAVINCI_GPIO_BASE,
+ .end= DAVINCI_GPIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* interrupt */
+ .start = IRQ_DM365_GPIO0,
+ .end= IRQ_DM365_GPIO7,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct davinci_gpio_platform_data dm365_gpio_platform_data = {
+ .ngpio = 104,
+ .intc_irq_num = DAVINCI_N_AINTC_IRQ,
+ .gpio_unbanked = 8,
+};
+
static __init void dm365_evm_init(void)
{
+ int ret;
+
+ ret = davinci_gpio_register(dm365_gpio_resources,
+ sizeof(dm365_gpio_resources),
+ dm365_gpio_platform_data);
+ if (ret)
+ pr_warn(dm365_evm_init: GPIO init failed: %d\n, ret);
+
evm_init_i2c();
davinci_serial_init(uart_config);
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index a33686a..57a7ed8 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -39,6 +39,7 @@
#include
[PATCH v2 4/7] ARM: davinci: creation of gpio platform device for dmxxx platforms
gpio controller resource information being associated with
davinci_soc_info structure and not created any device. Hence davinci
gpio didn't fall under proper device model. This patch creates gpio
davinci as a platform device for dmxxx platforms.
Also add daivinci_register_gpio API to create platform device for dmxxx
platforms.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/devices.c | 13 +
arch/arm/mach-davinci/include/mach/common.h |2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index a7068a3..b4f345b 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -313,6 +313,19 @@ static void davinci_init_wdt(void)
platform_device_register(davinci_wdt_device);
}
+static struct platform_device davinci_gpio_device = {
+ .name = davinci_gpio,
+ .id = -1,
+};
+
+int davinci_gpio_register(struct resource *res, int size, void *pdata)
+{
+ davinci_gpio_device.resource = res;
+ davinci_gpio_device.num_resources = size;
+ davinci_gpio_device.dev.platform_data = pdata;
+ return platform_device_register(davinci_gpio_device);
+}
+
/*-*/
/*-*/
diff --git a/arch/arm/mach-davinci/include/mach/common.h
b/arch/arm/mach-davinci/include/mach/common.h
index b124b77..bd389ba 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -14,6 +14,7 @@
#include linux/compiler.h
#include linux/types.h
+#include linux/ioport.h
extern void davinci_timer_init(void);
@@ -83,6 +84,7 @@ extern void davinci_common_init(struct davinci_soc_info
*soc_info);
extern void davinci_init_ide(void);
void davinci_restart(char mode, const char *cmd);
void davinci_init_late(void);
+int davinci_gpio_register(struct resource *res, int size, void *pdata);
#ifdef CONFIG_DAVINCI_RESET_CLOCKS
int davinci_clk_disable_unused(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] mm/writeback: fix wb_do_writeback exported unsafely
On 06/14/2013 05:31 PM, Michal Hocko wrote: On Fri 14-06-13 12:29:52, Kirill A. Shutemov wrote: Michal Hocko wrote: On Fri 14-06-13 15:30:34, Wanpeng Li wrote: There is just one caller in fs-writeback.c call wb_do_writeback and current codes unnecessary export it in header file, this patch fix it by changing wb_do_writeback to static function. So what? Besides that git grep wb_do_writeback tells that mm/backing-dev.c: wb_do_writeback(me, 0); Have you tested this at all? Commit 839a8e8 removes that. OK, I didn't check the most up-to-date tree. Sorry about this confusion. I do not object to cleanups like this but it should be clear they are cleanups. fix wb_do_writeback exported unsafely sounds like a fix rather than a cleanup Agreed. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] of/fdt: Add FDT address translation
Any comment or feedback for this patch?
On Fri, 2013-05-24 at 17:36 +0800, Ley Foon Tan wrote:
This patch adds address translation to fdt. It is needed when the early
console is connected to a simple-bus (bridge) that has address translation
enabled.
Walter Goossens have submitted first version of patch previously. This
patch resolved the feedback from first submission and some enhancements
on translation functions.
Reviewed-by: Walter Goossens waltergooss...@home.nl
Signed-off-by: Ley Foon Tan lf...@altera.com
---
drivers/of/fdt.c | 188
include/linux/of_fdt.h |2 +
2 files changed, 190 insertions(+), 0 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 808be06..74cc1bc 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -695,6 +695,194 @@ int __init early_init_dt_scan_chosen(unsigned long
node, const char *uname,
/* break now */
return 1;
}
+/**
+ * flat_dt_translate_address - Translate an address using the ranges property
+ *
+ * This function converts address from node address-space to parent
address-
+ * space
+ */
+static int __init flat_dt_translate_address(unsigned long node,
+ unsigned long parent, u64 *address)
+{
+ unsigned long size = 0;
+ __be32 *prop;
+ __be32 *ranges;
+ int size_cells = 0;
+ int addr_cells = 0;
+ int paddr_cells = OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
+
+ ranges = of_get_flat_dt_prop(node, ranges, size);
+
+ if (!ranges) {
+ pr_warn(Address cannot be translated\n);
+ return -EINVAL;
+ }
+
+ if (!size) {
+ pr_debug(No translation possible/necessary\n);
+ return 0;
+ }
+
+ prop = of_get_flat_dt_prop(node, #size-cells, NULL);
+ if (!prop)
+ return -EINVAL;
+ size_cells = be32_to_cpup(prop);
+
+ prop = of_get_flat_dt_prop(node, #address-cells, NULL);
+ if (!prop)
+ return -EINVAL;
+ addr_cells = be32_to_cpup(prop);
+
+ if (parent) {
+ prop = of_get_flat_dt_prop(parent, #address-cells, NULL);
+ if (prop)
+ paddr_cells = be32_to_cpup(prop);
+ }
+ if ((addr_cells = 0) || (size_cells = 0) ||
+ (addr_cells 2) || (size_cells 2) || (paddr_cells 2)) {
+ pr_warn(Translation not possible in fdt. Invalid address.\n);
+ *address = 0;
+ return -1;
+ }
+
+ while (size 0) {
+ u64 from, to, tsize;
+ from = be32_to_cpup(ranges++);
+ size -= 4;
+ if (addr_cells == 2) {
+ from += (((u64)be32_to_cpup(ranges++)) 32);
+ size -= 4;
+ }
+ to = be32_to_cpup(ranges++);
+ size -= 4;
+ if (paddr_cells == 2) {
+ to += (((u64)be32_to_cpup(ranges++)) 32);
+ size -= 4;
+ }
+ tsize = be32_to_cpup(ranges++);
+ size -= 4;
+ if (size_cells == 2) {
+ tsize += (((u64)be32_to_cpup(ranges++)) 32);
+ size -= 4;
+ }
+ pr_debug( From %llX To %llX Size %llX\n, from, to, tsize);
+ if ((*address = from) (*address (from + tsize)))
+ *address += (to - from);
+ }
+ return 1;
+}
+
+static int __init of_scan_flat_dt_ranges(unsigned long *pnode,
+ unsigned long parent, unsigned long target,
+ u64 *address, int ignore)
+{
+ int rc = 0;
+ int depth = -1;
+ const char *pathp;
+ unsigned long p = *pnode;
+ do {
+ u32 tag = be32_to_cpup((__be32 *)p);
+
+ p += 4;
+ if (tag == OF_DT_END_NODE) {
+ if (depth--)
+ break;
+ else
+ continue;
+ }
+ if (tag == OF_DT_NOP)
+ continue;
+ if (tag == OF_DT_END)
+ break;
+ if (tag == OF_DT_PROP) {
+ u32 sz = be32_to_cpup((__be32 *)p);
+ p += 8;
+ if (be32_to_cpu(initial_boot_params-version) 0x10)
+ p = ALIGN(p, sz = 8 ? 8 : 4);
+ p += sz;
+ p = ALIGN(p, 4);
+ continue;
+ }
+ if (tag != OF_DT_BEGIN_NODE) {
+ pr_err(Invalid tag %x in flat device tree!\n, tag);
+ return -EINVAL;
+ }
+ pathp = (char *)p;
+ p = ALIGN(p + strlen(pathp) + 1, 4);
+ if ((*pathp) == '/')
+ pathp = kbasename(pathp);
+ if
Re: [PATCH v4] irqchip: Add support for ARMv7-M's NVIC
On Wed, Jun 12, 2013 at 10:50:35PM +0100, Uwe Kleine-K??nig wrote: This interrupt controller is found on Cortex-M3 and Cortex-M4 machines. Support for this controller appeared in Catalin's Cortex tree based on 2.6.33 but was nearly completely rewritten. Signed-off-by: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Uwe Kleine-K??nig u.kleine-koe...@pengutronix.de Since you pretty much re-wrote my original code, you can drop my Signed-off-by. Feel free to replace with: Acked-by: Catalin Marinas catalin.mari...@arm.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] GPIO DT support for da850
With conversion of GPIO davinci driver to platform driver, gpio-davinci driver can support DT boot. This patch series - adds dt binding support for gpio-davinci. - da850 dt support goio. This patch series is based on Linux 3.10-rc4 and is availabel at [1]. 1. https://github.com/avinashphilip/am335x_linux/tree/linux_davinci_v3.10_soc_gpio_v310-rc4 KV Sujith (3): gpio: davinci: DT changes for driver ARM: davinci: da850: add GPIO DT entries ARM: davinci: da850 evm: add GPIO DT data Philip Avinash (1): ARM: davinci: da850: Use #include for all device trees .../devicetree/bindings/gpio/gpio-davinci.txt | 32 +++ arch/arm/boot/dts/da850-enbw-cmc.dts |2 +- arch/arm/boot/dts/da850-evm.dts| 21 +++- arch/arm/boot/dts/da850.dtsi | 17 +- drivers/gpio/gpio-davinci.c| 57 ++-- 5 files changed, 123 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt -- 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: [iput] BUG: Bad page state in process rm pfn:0b0ce
On Fri, Jun 14, 2013 at 10:16:55AM +0100, Mel Gorman wrote: On Thu, Jun 13, 2013 at 06:25:49PM +0800, Fengguang Wu wrote: Greetings, I got the below dmesg in linux-next and the first bad commit is Thanks Fengguang. Can you try the following please? I do not see the same issue unfortunately but I am the wrong type of unlucky here. Sure I'll test it right away, thanks for the quick fix! Thanks, Fengguang ---8--- mm: Clear page active before releasing pages Active pages should not be freed to the page allocator as it triggers a bad page state warning. Fengguang Wu reported the following bug [ 84.212960] BUG: Bad page state in process rm pfn:0b0c9 [ 84.214682] page:88000d646240 count:0 mapcount:0 mapping: (null) index:0x0 [ 84.216883] page flags: 0x204c(referenced|uptodate|active) [ 84.218697] CPU: 1 PID: 283 Comm: rm Not tainted 3.10.0-rc4-04361-geeb9bfc #49 [ 84.220729] 88000d646240 88000d179bb8 82562956 88000d179bd8 [ 84.223242] 811333f1 204c 88000d646240 88000d179c28 [ 84.225387] 811346a4 8827 0006 [ 84.227294] Call Trace: [ 84.227867] [82562956] dump_stack+0x27/0x30 [ 84.229045] [811333f1] bad_page+0x130/0x158 [ 84.230261] [811346a4] free_pages_prepare+0x8b/0x1e3 [ 84.231765] [8113542a] free_hot_cold_page+0x28/0x1cf [ 84.233171] [82585830] ? _raw_spin_unlock_irqrestore+0x6b/0xc6 [ 84.234822] [81135b59] free_hot_cold_page_list+0x30/0x5a [ 84.236311] [8113a4ed] release_pages+0x251/0x267 [ 84.237653] [8112a88d] ? delete_from_page_cache+0x48/0x9e [ 84.239142] [8113ad93] __pagevec_release+0x2b/0x3d [ 84.240473] [8113b45a] truncate_inode_pages_range+0x1b0/0x7ce [ 84.242032] [810e76ab] ? put_lock_stats.isra.20+0x1c/0x53 [ 84.243480] [810e77f5] ? lock_release_holdtime+0x113/0x11f [ 84.244935] [8113ba8c] truncate_inode_pages+0x14/0x1d [ 84.246337] [8119b3ef] evict+0x11f/0x232 [ 84.247501] [8119c527] iput+0x1a5/0x218 [ 84.248607] [8118f015] do_unlinkat+0x19b/0x25a [ 84.249828] [810ea993] ? trace_hardirqs_on_caller+0x210/0x2ce [ 84.251382] [8144372e] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 84.252879] [8118f10d] SyS_unlinkat+0x39/0x4c [ 84.254174] [825874d6] system_call_fastpath+0x1a/0x1f [ 84.255596] Disabling lock debugging due to kernel taint The problem was that a page marked for activation was released via pagevec. This patch clears the active bit before freeing in this case. Signed-off-by: Mel Gorman mgor...@suse.de --- mm/swap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/swap.c b/mm/swap.c index ac23602..4a1d0d2 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -739,6 +739,9 @@ void release_pages(struct page **pages, int nr, int cold) del_page_from_lru_list(page, lruvec, page_off_lru(page)); } + /* Clear Active bit in case of parallel mark_page_accessed */ + ClearPageActive(page); + list_add(page-lru, pages_to_free); } if (zone) -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 1/4] ARM: davinci: da850: Use #include for all device trees
Replace /include/ by #include for da850 device tree files, in order to
use the C pre-processor, making use of #define features possible.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
- New patch and comes as a dependency of patch 3/4
arch/arm/boot/dts/da850-enbw-cmc.dts |2 +-
arch/arm/boot/dts/da850-evm.dts |2 +-
arch/arm/boot/dts/da850.dtsi |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index 422fdb3..e750ab9 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -10,7 +10,7 @@
* option) any later version.
*/
/dts-v1/;
-/include/ da850.dtsi
+#include da850.dtsi
/ {
compatible = enbw,cmc, ti,da850;
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c914357..5bce7cc 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -8,7 +8,7 @@
* Free Software Foundation, version 2.
*/
/dts-v1/;
-/include/ da850.dtsi
+#include da850.dtsi
/ {
compatible = ti,da850-evm, ti,da850;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 452bdc6..3b66020 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -7,7 +7,7 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
-/include/ skeleton.dtsi
+#include skeleton.dtsi
/ {
arm {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] ARM: davinci: da850: add GPIO DT entries
From: KV Sujith sujit...@ti.com
Add DT entries for Davinci GPIO.
Signed-off-by: KV Sujith sujit...@ti.com
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
- interrupts member defined as array and with interrupt flags
arch/arm/boot/dts/da850.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3b66020..cd7b362 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -8,6 +8,7 @@
* option) any later version.
*/
#include skeleton.dtsi
+#include dt-bindings/interrupt-controller/irq.h
/ {
arm {
@@ -126,6 +127,20 @@
;
};
};
+ gpio: gpio@1e26000 {
+ compatible = ti,da830-gpio;
+ reg = 0x226000 0x1000;
+ interrupts = 42 IRQ_TYPE_EDGE_BOTH
+ 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
+ 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
+ 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
+ 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH;
+ ngpio = 144;
+ intc_irq_num = 101;
+ gpio_unbanked = 0;
+ status = disabled;
+ };
serial0: serial@1c42000 {
compatible = ns16550a;
reg = 0x42000 0x100;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] ARM: davinci: da850 evm: add GPIO DT data
From: KV Sujith sujit...@ti.com
- Add GPIO DT Data and pinmux for DA850 EVM. GPIO is configurable differently
on different boards. So add GPIO pinmuxing in dts file.
- Dependency: This patch is dependent on Grab-pin-control patch;
https://patchwork.kernel.org/patch/2013751/
Signed-off-by: KV Sujith sujit...@ti.com
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
arch/arm/boot/dts/da850-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 5bce7cc..2c127ff 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -17,6 +17,20 @@
soc {
pmx_core: pinmux@1c14120 {
status = okay;
+ gpio_pins: pinmux_gpio_pins {
+ pinctrl-single,bits =
+ /* GPIO2_4 GPIO2_6 */
+ 0x18 0x8080 0xf0f0
+ /* GPIO2_8 GPIO2_15 */
+ 0x14 0x8008 0xf00f
+ /* GPIO3_12 GPIO3_13 */
+ 0x1C 0x8800 0xff00
+ /* GPIO4_0 GPIO4_1 */
+ 0x28 0x8800 0xff00
+ /* GPIO6_9 GPIO6_10 GPIO6_13 */
+ 0x34 0x08800800 0x0ff00f00
+ ;
+ };
};
serial0: serial@1c42000 {
status = okay;
@@ -90,6 +104,11 @@
};
};
};
+ gpio: gpio@1e26000 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = gpio_pins;
+ };
};
nand_cs3@6200 {
status = okay;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: Fix double assignment of .owner in struct snd_soc_card
In struct snd_soc_card zylonite .owner is assigned THIS_MODULE
twice, remove one of them.
Signed-off-by: Emil Goode emilgo...@gmail.com
---
sound/soc/pxa/zylonite.c |1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/pxa/zylonite.c b/sound/soc/pxa/zylonite.c
index ceb6566..db8aadf 100644
--- a/sound/soc/pxa/zylonite.c
+++ b/sound/soc/pxa/zylonite.c
@@ -256,7 +256,6 @@ static struct snd_soc_card zylonite = {
.resume_pre = zylonite_resume_pre,
.dai_link = zylonite_dai,
.num_links = ARRAY_SIZE(zylonite_dai),
- .owner = THIS_MODULE,
};
static struct platform_device *zylonite_snd_ac97_device;
--
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/
[PATCH v3 2/2] USB: ehci-omap: select NOP_USB_XCEIV PHY driver
ehci-omap needs NOP_USB_XCEIV PHY driver to function properly, so select it. As the USB PHY drivers no longer depend on USB_PHY, it is safe to select the PHY drivers. Signed-off-by: Roger Quadros rog...@ti.com Tested-by: Adrien Vergé adrienve...@gmail.com --- drivers/usb/host/Kconfig |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 7ded784..48e1b70 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -150,13 +150,11 @@ config USB_EHCI_MXC config USB_EHCI_HCD_OMAP tristate EHCI support for OMAP3 and later chips depends on ARCH_OMAP + select NOP_USB_XCEIV default y ---help--- Enables support for the on-chip EHCI controller on OMAP3 and later chips. - If your system uses a PHY on the USB port, you will need to - enable USB_PHY and the appropriate PHY driver as well. Most - boards need the NOP_USB_XCEIV PHY driver. config USB_EHCI_HCD_ORION tristate Support for Marvell EBU on-chip EHCI USB controller -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] USB: PHY: Make PHY driver selection possible by controller drivers
Convert PHY Drivers from menuconfig to menu so that the PHY drivers can be explicitely selected by the controller drivers. USB_PHY is no longer a user visible option. It is upto to the PHY drivers to select it if needed. This patch does so for the existing PHY drivers that use the USB_PHY library. Doing so moves the USB_PHY and PHY driver selection problem from the end user to the PHY and controller driver developer. e.g. Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver depended on USB_PHY. Making the controller driver depend on USB_PHY has a negative effect i.e. it becomes invisible to the user till USB_PHY is enabled. Most end users will not familiar with this. With this patch, the end user just needs to select the controller driver needed for his/her platform without worrying about which PHY driver to select. Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend on USB_PHY any more. They can safely select the necessary PHY drivers. CC: Pavankumar Kondeti pkond...@codeaurora.org CC: Roland Stigge sti...@antcom.de Signed-off-by: Roger Quadros rog...@ti.com [USB_LPC32XX part] Acked-by: Roland Stigge sti...@antcom.de Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/Makefile |2 +- drivers/usb/gadget/Kconfig |2 -- drivers/usb/host/Kconfig |1 - drivers/usb/phy/Kconfig| 31 +-- 4 files changed, 22 insertions(+), 14 deletions(-) diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index c41feba..b9bb845 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -44,7 +44,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/ obj-$(CONFIG_USB_SERIAL) += serial/ obj-$(CONFIG_USB) += misc/ -obj-$(CONFIG_USB_PHY) += phy/ +obj-$(CONFIG_USB_SUPPORT) += phy/ obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/ obj-$(CONFIG_USB_ATM) += atm/ diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f41aa0d..86d5d80 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -144,7 +144,6 @@ config USB_AT91 config USB_LPC32XX tristate LPC32XX USB Peripheral Controller depends on ARCH_LPC32XX - depends on USB_PHY select USB_ISP1301 help This option selects the USB device controller in the LPC32xx SoC. @@ -195,7 +194,6 @@ config USB_FUSB300 config USB_OMAP tristate OMAP USB Device Controller depends on ARCH_OMAP1 - depends on USB_PHY select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG help Many Texas Instruments OMAP processors have flexible full diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 344d5e2..7ded784 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -188,7 +188,6 @@ config USB_EHCI_HCD_AT91 config USB_EHCI_MSM tristate Support for Qualcomm QSD/MSM on-chip EHCI USB controller depends on ARCH_MSM - depends on USB_PHY select USB_EHCI_ROOT_HUB_TT select USB_MSM_OTG ---help--- diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 7ef3eb8..b57f7f0 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -1,16 +1,11 @@ # # Physical Layer USB driver configuration # -menuconfig USB_PHY - bool USB Physical Layer drivers - help - USB controllers (those which are host, device or DRD) need a - device to handle the physical layer signalling, commonly called - a PHY. - - The following drivers add support for such PHY devices. +menu USB Physical Layer drivers -if USB_PHY +config USB_PHY + bool + default n # # USB Transceiver Drivers @@ -18,6 +13,7 @@ if USB_PHY config AB8500_USB tristate AB8500 USB Transceiver Driver depends on AB8500_CORE + select USB_PHY help Enable this to support the USB OTG transceiver in AB8500 chip. This transceiver supports high and full speed devices plus, @@ -27,12 +23,14 @@ config FSL_USB2_OTG bool Freescale USB OTG Transceiver Driver depends on USB_EHCI_FSL USB_FSL_USB2 PM_RUNTIME select USB_OTG + select USB_PHY help Enable this to support Freescale USB OTG transceiver. config ISP1301_OMAP tristate Philips ISP1301 with OMAP OTG depends on I2C ARCH_OMAP_OTG + select USB_PHY help If you say yes here you get support for the Philips ISP1301 USB-On-The-Go transceiver working with the OMAP OTG controller. @@ -46,12 +44,14 @@ config ISP1301_OMAP config MV_U3D_PHY bool Marvell USB 3.0 PHY controller Driver depends on CPU_MMP3 + select USB_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. config NOP_USB_XCEIV tristate NOP
[PATCH v3 0/2] USB: PHY: Improve PHY selection logic
Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. v3: - Fix linking problem when CONFIG_USB is m v2: - Merge patches 3-5 into the first patch to prevent circular dependency between the Kconfig options during bisection. cheers, -roger Roger Quadros (2): USB: PHY: Make PHY driver selection possible by controller drivers USB: ehci-omap: select NOP_USB_XCEIV PHY driver drivers/usb/Makefile |2 +- drivers/usb/gadget/Kconfig |2 -- drivers/usb/host/Kconfig |5 + drivers/usb/phy/Kconfig| 31 +-- 4 files changed, 23 insertions(+), 17 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
