Re: linux-next: Tree for Jun 28 [ BISECTED: rsyslog/imklog: High CPU usage ]
Hi Oleg, Andrew, On Sun, 30 Jun 2013 20:19:45 +0200 Oleg Nesterov wrote: > > Andrew, please drop these > > wait-introduce-wait_event_commonwq-condition-state-timeout.patch > wait-introduce-prepare_to_wait_event.patch > > patches again. I'll send v3 although it really looks like I should > never try to touch wait.h. I have dropped those two patches (and my fixup patch) from linux-next today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpQwxiZQIMRs.pgp Description: PGP signature
[PATCH] sched: fix cpu utilization account error
We setting clock_skip_update = 1 based on the assumption that the
next call to update_rq_clock() will come nearly immediately
after being set. However, it is not always true especially on
non-preempt mode. In this case we may miss some clock update, which
would cause an error curr->sum_exec_runtime account.
The test result show that test_kthread's exec_runtime has been
added to watchdog.
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND
28 root RT 0 000 S 100 0.0 0:05.39 5 watchdog/5
7 root RT 0 000 S 95 0.0 0:05.83 0 watchdog/0
12 root RT 0 000 S 94 0.0 0:05.79 1 watchdog/1
16 root RT 0 000 S 92 0.0 0:05.74 2 watchdog/2
20 root RT 0 000 S 91 0.0 0:05.71 3 watchdog/3
24 root RT 0 000 S 82 0.0 0:05.42 4 watchdog/4
32 root RT 0 000 S 79 0.0 0:05.35 6 watchdog/6
5200 root 20 0 000 R 21 0.0 0:08.88 6 test_kthread/6
5194 root 20 0 000 R 20 0.0 0:08.41 0 test_kthread/0
5195 root 20 0 000 R 20 0.0 0:08.44 1 test_kthread/1
5196 root 20 0 000 R 20 0.0 0:08.49 2 test_kthread/2
5197 root 20 0 000 R 20 0.0 0:08.53 3 test_kthread/3
5198 root 20 0 000 R 19 0.0 0:08.81 4 test_kthread/4
5199 root 20 0 000 R2 0.0 0:08.66 5 test_kthread/5
"test_kthread/i" is a kernel thread which has a infinity loop and it calls
schedule() every 1s. It's main process as below:
static int main_loop (void *unused)
{
unsigned long flags;
unsigned long last = jiffies;
int i;
while (!kthread_should_stop()) {
/* call schedule every 1 sec */
if (HZ <= jiffies - last) {
last = jiffies;
schedule();
}
/* do some thing */
for (i = 0; i < 1000; i++)
;
if (kthread_should_stop())
break;
}
}
In this patch, we do not skip clock update when current task is kernel
thread in non-preempt mode.
Reported-by: Zhang Hang
Signed-off-by: Xie XiuQi
---
kernel/sched/core.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e8b3350..018dc43 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -970,8 +970,19 @@ void check_preempt_curr(struct rq *rq, struct task_struct
*p, int flags)
* A queue event has occurred, and we're going to schedule. In
* this case, we can save a useless back to back clock update.
*/
+#ifdef CONFIG_PREEMPT
if (rq->curr->on_rq && test_tsk_need_resched(rq->curr))
rq->skip_clock_update = 1;
+#else
+ /*
+* In non-preempt mode, a kernel thread may run for a long time
+* until been scheduled out by itself. In this cace, we need update
+* rq clock when calling schedule function, otherwise, we might
+* miss rq clock update for a long time.
+*/
+ if (rq->curr->on_rq && test_tsk_need_resched(rq->curr) && rq->curr->mm)
+ rq->skip_clock_update = 1;
+#endif
}
static ATOMIC_NOTIFIER_HEAD(task_migration_notifier);
--
1.7.6.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 v3 2/4] i2c: Kontron PLD i2c bus driver
On Sun, Jun 23, 2013 at 09:00:04PM -0700, Kevin Strasser wrote: > Add i2c support for the on-board PLD found on some Kontron embedded > modules. > > Originally-From: Michael Brunner > Signed-off-by: Kevin Strasser > Acked-by: Guenter Roeck > Acked-by: Darren Hart Applied to for-next, thanks! signature.asc Description: Digital signature
linux-next: manual merge of the arm-soc tree with the net-next tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-mxs/mach-mxs.c between commit b7c4114b07bb ("can: flexcan:
Use a regulator to control the CAN transceiver") from the net-next tree
and commit 2046338dcbc6 ("ARM: mxs: Use soc bus infrastructure") from the
arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-mxs/mach-mxs.c
index 97b8a44,7fa611c..000
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@@ -323,13 -477,14 +432,14 @@@ static void __init mxs_machine_init(voi
imx28_evk_init();
else if (of_machine_is_compatible("bluegiga,apx4devkit"))
apx4devkit_init();
- else if (of_machine_is_compatible("crystalfontz,cfa10037"))
- cfa10037_init();
- else if (of_machine_is_compatible("crystalfontz,cfa10049"))
- cfa10049_init();
+ else if (of_machine_is_compatible("crystalfontz,cfa10037") ||
+of_machine_is_compatible("crystalfontz,cfa10049") ||
+of_machine_is_compatible("crystalfontz,cfa10055") ||
+of_machine_is_compatible("crystalfontz,cfa10057"))
+ crystalfontz_init();
of_platform_populate(NULL, of_default_bus_match_table,
-NULL, NULL);
- mxs_auxdata_lookup, parent);
++ NULL, parent);
if (of_machine_is_compatible("karo,tx28"))
tx28_post_init();
pgpOik6OLm6Ym.pgp
Description: PGP signature
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote: > MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out > any memory restriction. How do you know this is the same issue? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Add FAT_IOCTL_GET_VOLUME_ID
OGAWA Hirofumi writes: >> +case FAT_IOCTL_GET_VOLUME_ID: >> +id = fat_ioctl_volume_id(inode); >> +return copy_to_user((unsigned int *)arg, &id, sizeof(id)); > >> +case FAT_IOCTL_GET_VOLUME_ID: >> +id = fat_ioctl_volume_id(inode); >> +return copy_to_user((unsigned int *)arg, &id, sizeof(id)); > > This pattern seems to from put_user(). > > Unnecessary cast of 1st arg. And copy_to_user() returns remaining bytes > when fail (not error code). Ah, actually, this needs cast, but it is to annotate for sparse. Well, is there any reason to restrict this only on the directory? For now, fat_generic_ioctl() looks easier way to do this. (fat_generic_ioctl() should work for the both of compat code and dir/file) Thanks. -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10] i2c: exynos5: add High Speed I2C controller driver
On Wed, Jun 19, 2013 at 04:18:25PM +0530, Naveen Krishna Chatradhi wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
>
> Driver only supports Device Tree method.
>
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs
> 7. Use OF data string "clock-frequency" to get the bus operating frequencies
> 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. Removed retries as core does retries if -EAGAIN is returned
> 11. Removed mode from device tree info (use speed to distinguish
> the mode of operation)
> 12. Use wait_for_completion_timeout as the interruptible case is not tested
> well
> 13. few other bug fixes and cosmetic changes
>
> Signed-off-by: Taekgyun Ko
> Signed-off-by: Naveen Krishna Chatradhi
> Reviewed-by: Simon Glass
> Tested-by: Andrew Bresticker
> Signed-off-by: Yuvaraj Kumar C D
> Signed-off-by: Andrew Bresticker
> ---
>
> +Optional properties:
> + - clock-frequency: Desired operating frequency in Hz of the bus.
> +-> If not specified, the default value is 100khz in fast-speed mode and
> + 1Mhz in high-speed mode.
? If not specified, the default is 100kHz. There is no way to get 1MHz,
or?
...
> +static int exynos5_i2c_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct exynos5_i2c *i2c;
> + struct resource *mem;
> + unsigned int op_clock;
My compiler says:
drivers/i2c/busses/i2c-exynos5.c: In function ‘exynos5_i2c_probe’:
drivers/i2c/busses/i2c-exynos5.c:687:5: warning: ‘op_clock’ may be used
uninitialized in this function [-Wuninitialized]
so...
> + int ret;
> +
> + if (!np) {
> + dev_err(&pdev->dev, "no device node\n");
> + return -ENOENT;
> + }
> +
> + i2c = devm_kzalloc(&pdev->dev, sizeof(struct exynos5_i2c), GFP_KERNEL);
> + if (!i2c) {
> + dev_err(&pdev->dev, "no memory for state\n");
> + return -ENOMEM;
> + }
> +
> + if (of_property_read_u32(np, "clock-frequency", &op_clock)) {
> + i2c->speed_mode = HSI2C_FAST_SPD;
> + i2c->fs_clock = HSI2C_FS_TX_CLOCK;
> + }
> +
> + if (op_clock >= HSI2C_HS_TX_CLOCK) {
... this should be 'else if'
> + i2c->speed_mode = HSI2C_HIGH_SPD;
> + i2c->fs_clock = HSI2C_FS_TX_CLOCK;
> + i2c->hs_clock = op_clock;
> + } else {
> + i2c->speed_mode = HSI2C_FAST_SPD;
> + i2c->fs_clock = op_clock;
> + }
...
> + i2c->bus_id = of_alias_get_id(i2c->adap.dev.of_node, "hsi2c");
Huh, the core already gets an alias for you. Can't you use 'adap.nr'?
Rest looks good.
Thanks!
signature.asc
Description: Digital signature
Re: [PATCH RFC] Add FAT_IOCTL_GET_VOLUME_ID
bintian.w...@linaro.org writes:
> This patch, originally from Android kernel, adds vfat directory ioctl command
> FAT_IOCTL_GET_VOLUME_ID, with this command we can get the vfat volume ID using
> following code:
>
> ioctl(dirfd(dir), FAT_IOCTL_GET_VOLUME_ID, &volume_ID)
>
> This patch is a modified version of the patch by Mike Lockwood, with changes
> from Dmitry Pervushin, who noticed the original patch makes some volume IDs
> abiguous with error returns: for example, if volume id is 0xFDAD, that
> matches -ENOIOCTLCMD, we get "" from the user space.
>
> So add a parameter to ioctl to get the correct volume ID.
Adding more specific usage example to changelog would help for
understanding this.
> + case FAT_IOCTL_GET_VOLUME_ID:
> + id = fat_ioctl_volume_id(inode);
> + return copy_to_user((unsigned int *)arg, &id, sizeof(id));
> + case FAT_IOCTL_GET_VOLUME_ID:
> + id = fat_ioctl_volume_id(inode);
> + return copy_to_user((unsigned int *)arg, &id, sizeof(id));
This pattern seems to from put_user().
Unnecessary cast of 1st arg. And copy_to_user() returns remaining bytes
when fail (not error code).
> +struct fat_boot_bsx {
> + __u8 drive; /* drive number */
> + __u8 reserved1;
> + __u8 signature; /* extended boot signature */
> + __u8 vol_id[4]; /* volume ID */
> + __u8 vol_label[11]; /* volume label */
> + __u8 type[8]; /* file system type */
> +};
> +#define FAT16_BSX_OFFSET 36 /* offset of fat_boot_bsx in FAT12 and FAT16 */
> +#define FAT32_BSX_OFFSET 64 /* offset of fat_boot_bsx in FAT32 */
There is any issue to merge those to "struct fat_boot_sector"? I guess,
merging it is cleaner way.
Thanks.
--
OGAWA Hirofumi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sched: context tracking demolishes pipe-test
On Sun, 2013-06-30 at 23:29 +0200, Peter Zijlstra wrote: > Yeah, who'd have thought that putting stuff in the syscall path would've > made syscalls more expensive ;-) (careful, you'll injure my innocence, Santa and the Tooth Fairy exist!) > But yeah, that's a _lot_ more expensive.. I'd not be surprised if more > people would find that objectionable. Distros may want some hot patching or _something_ before doing the usual new=turn-it-on thing. Per trusty (spelled with 'c') old Q6600, the cost is pretty darn high. -regress is my ~light regression testing config, carried forward from 3.6.32...master across all intervening trees. -regressx is plus CONFIG_RCU_USER_QS=y CONFIG_CONTEXT_TRACKING_FORCE=y -regressxx is plus full dynticks taskset -c 3 pipe-test 1 2.6.32-regress654.5 Khz1.000 3.10.0-regress652.1 Khz .996 1.000 3.10.0-regressx 476.8 Khz .728 .731 3.10.0-regressxx 275.6 Khz .421 .422 tbench 2.6.32-regress327.502 MB/sec 1.000 3.10.0-regress319.621 MB/sec.975 1.000 3.10.0-regressx 292.894 MB/sec.894 .916 3.10.0-regressxx 243.738 MB/sec.744 .762 netperf TCP_RR 2.6.32-regress 104041.84 Trans/sec 1.000 3.10.0-regress94961.34 Trans/sec.912 1.000 3.10.0-regressx 82383.33 Trans/sec.791 .867 3.10.0-regressxx 61527.59 Trans/sec.591 .647 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the regulator tree
+Keerthy
On Monday 01 July 2013 09:48 AM, Stephen Rothwell wrote:
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/regulator/palmas-regulator.c: In function 'palmas_regulators_probe':
drivers/regulator/palmas-regulator.c:850:8: error: 'PALMAS_REG_SMPS10'
undeclared (first use in this function)
case PALMAS_REG_SMPS10:
^
Caused by commit 07a02e0b1a4f ("regulator: palmas: model SMPS10 as two
regulators"). Clearly not build tested at all :-( Grep is your
friend ...
commit 1ffb0b (mfd: palmas: Add SMPS10_BOOST feature) had used PALMAS_REG_SMPS10
and I dint have that patch in my tree. Sorry, my bad.
Keerthy will send a fix for 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: cgroup: status-quo and userland efforts
On Sun, Jun 30, 2013 at 12:39 PM, Lennart Poettering wrote: > Heya, > > > On 29.06.2013 05:05, Tim Hockin wrote: >> >> Come on, now, Lennart. You put a lot of words in my mouth. > > >>> I for sure am not going to make the PID 1 a client of another daemon. >>> That's >>> just wrong. If you have a daemon that is both conceptually the manager of >>> another service and the client of that other service, then that's bad >>> design >>> and you will easily run into deadlocks and such. Just think about it: if >>> you >>> have some external daemon for managing cgroups, and you need cgroups for >>> running external daemons, how are you going to start the external daemon >>> for >>> managing cgroups? Sure, you can hack around this, make that daemon >>> special, >>> and magic, and stuff -- or you can just not do such nonsense. There's no >>> reason to repeat the fuckup that cgroup became in kernelspace a second >>> time, >>> but this time in userspace, with multiple manager daemons all with >>> different >>> and slightly incompatible definitions what a unit to manage actualy is... >> >> >> I forgot about the tautology of systemd. systemd is monolithic. > > > systemd is certainly not monolithic for almost any definition of that term. > I am not sure where you are taking that from, and I am not sure I want to > discuss on that level. This just sounds like FUD you picked up somewhere and > are repeating carelessly... It does a number of sort-of-related things. Maybe it does them better by doing them together. I can't say, really. We don't use it at work, and I am on Ubuntu elsewhere, for now. >> But that's not my point. It seems pretty easy to make this cgroup >> management (in "native mode") a library that can have either a thin >> veneer of a main() function, while also being usable by systemd. The >> point is to solve all of the problems ONCE. I'm trying to make the >> case that systemd itself should be focusing on features and policies >> and awesome APIs. > > You know, getting this all right isn't easy. If you want to do things > properly, then you need to propagate attribute changes between the units you > manage. You also need something like a scheduler, since a number of > controllers can only be configured under certain external conditions (for > example: the blkio or devices controller use major/minor parameters for > configuring per-device limits. Since major/minor assignments are pretty much > unpredictable these days -- and users probably want to configure things with > friendly and stable /dev/disk/by-id/* symlinks anyway -- this requires us to > wait for devices to show up before we can configure the parameters.) Soo... > you need a graph of units, where you can propagate things, and schedule > things based on some execution/event queue. And the propagation and > scheduling are closely intermingled. I'm really just talking about the most basic low-level substrate of writing to cgroupfs. Again, we don't use udev (yet?) so we don't have these problems. It seems to me that it's possible to formulate a bottom layer that is usable by both systemd and non-systemd systems. But, you know, maybe I am wrong and our internal universe is so much simpler (and behind the times) than the rest of the world that layering can work for us and not you. > Now, that's pretty much exactly what systemd actually *is*. It implements a > graph of units with a scheduler. And if you rip that part out of systemd to > make this an "easy cgroup management library", then you simply turn what > systemd is into a library without leaving anything. Which is just bogus. > > So no, if you say "seems pretty easy to make this cgroup management a > library" then well, I have to disagree with you. > > >>> We want to run fewer, simpler things on our systems, we want to reuse as >> >> >> Fewer and simpler are not compatible, unless you are losing >> functionality. Systemd is fewer, but NOT simpler. > > > Oh, certainly it is. If we'd split up the cgroup fs access into separate > daemon of some kind, then we'd need some kind of IPC for that, and so you > have more daemons and you have some complex IPC between the processes. So > yeah, the systemd approach is certainly both simpler and uses fewer daemons > then your hypothetical one. Well, it SOUNDS like Serge is trying to develop this to demonstrate that a standalone daemon works. That's what I am keen to help with (or else we have to invent ourselves). I am not really afraid of IPC or of "more daemons". I much prefer simple agents doing one thing and interacting with each other in simple ways. But that's me. >>> much of the code as we can. You don't achieve that by running yet another >>> daemon that does worse what systemd can anyway do simpler, easier and >>> better. >> >> >> Considering this is all hypothetical, I find this to be a funny >> debate. My hypothetical idea is better than your hypothetical idea. > > > Well, systemd is pretty real, and the code to do the unified cg
[PATCH] ktime: add missing declaration of ktime_get() in ktime.h
We cannot use ktime_get() API even if we include ktime.h, because there is
no declaration of this API in ktime.h. So add it.
Signed-off-by: Joonsoo Kim
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index bbca128..29954cd 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -357,6 +357,7 @@ static inline bool ktime_to_timespec_cond(const ktime_t kt,
struct timespec *ts)
#define LOW_RES_NSEC TICK_NSEC
#define KTIME_LOW_RES (ktime_t){ .tv64 = LOW_RES_NSEC }
+extern ktime_t ktime_get(void);
/* Get the monotonic time in timespec format: */
extern void ktime_get_ts(struct timespec *ts);
--
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/3] perf record: support duration option to run during specified time
On Fri, Jun 28, 2013 at 05:27:24PM -0700, Sukadev Bhattiprolu wrote:
> Joonsoo Kim [iamjoonsoo@lge.com] wrote:
> | Currently, there is no method to quit at specified time later.
> | We are used to using 'sleep N' as command argument if we need it,
> | but explicitly supporting this feature maybe makes sense.
> |
> | Cc: Namhyung Kim
> | Signed-off-by: Joonsoo Kim
> |
> | diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> | index cdf58ec..19c65b5 100644
> | --- a/tools/perf/builtin-record.c
> | +++ b/tools/perf/builtin-record.c
> | @@ -29,6 +29,7 @@
> | #include
> | #include
> |
> | +static unsigned int duration;
> | #ifndef HAVE_ON_EXIT
> | #ifndef ATEXIT_MAX
> | #define ATEXIT_MAX 32
> | @@ -194,7 +195,7 @@ static void perf_record__sig_exit(int exit_status
> __maybe_unused, void *arg)
> | psignal(WTERMSIG(status), rec->progname);
> | }
> |
> | - if (signr == -1 || signr == SIGUSR1)
> | + if (signr == -1 || signr == SIGUSR1 || signr == SIGALRM)
> | return;
> |
> | signal(signr, SIG_DFL);
> | @@ -404,6 +405,7 @@ static int __cmd_record(struct perf_record *rec, int
> argc, const char **argv)
> | signal(SIGCHLD, sig_handler);
> | signal(SIGINT, sig_handler);
> | signal(SIGUSR1, sig_handler);
> | + signal(SIGALRM, sig_handler);
> |
> | if (!output_name) {
> | if (!fstat(STDOUT_FILENO, &st) && S_ISFIFO(st.st_mode))
> | @@ -471,6 +473,7 @@ static int __cmd_record(struct perf_record *rec, int
> argc, const char **argv)
> | goto out_delete_session;
> | }
> |
> | + alarm(duration);
> | if (forks) {
> | err = perf_evlist__prepare_workload(evsel_list, &opts->target,
> | argv, opts->pipe_output,
> | @@ -955,6 +958,7 @@ const struct option record_options[] = {
> | parse_branch_stack),
> | OPT_BOOLEAN('W', "weight", &record.opts.sample_weight,
> | "sample by weight (on special events only)"),
> | + OPT_UINTEGER(0, "duration", &duration, "run during specified seconds"),
>
> nit: A slight ambiguity in the help text. Would you mind changing it to:
>
> "run for specified duration (seconds)" ?
>
> Sukadev
Hello, Sukadev.
Okay.
Here goes v2 with your suggestion.
>8--
>From b65e29b33cb250d4a4be103ce5afae29f6bdc11a Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Thu, 13 Jun 2013 18:06:21 +0900
Subject: [PATCH v2] perf, tools: support duration option to run during specified
time
Currently, there is no method to quit at specified time later.
We are used to using 'sleep N' as command argument if we need it,
but explicitly supporting this feature maybe makes sense.
Signed-off-by: Joonsoo Kim
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index cdf58ec..1384118 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -29,6 +29,7 @@
#include
#include
+static unsigned int duration;
#ifndef HAVE_ON_EXIT
#ifndef ATEXIT_MAX
#define ATEXIT_MAX 32
@@ -194,7 +195,7 @@ static void perf_record__sig_exit(int exit_status
__maybe_unused, void *arg)
psignal(WTERMSIG(status), rec->progname);
}
- if (signr == -1 || signr == SIGUSR1)
+ if (signr == -1 || signr == SIGUSR1 || signr == SIGALRM)
return;
signal(signr, SIG_DFL);
@@ -404,6 +405,7 @@ static int __cmd_record(struct perf_record *rec, int argc,
const char **argv)
signal(SIGCHLD, sig_handler);
signal(SIGINT, sig_handler);
signal(SIGUSR1, sig_handler);
+ signal(SIGALRM, sig_handler);
if (!output_name) {
if (!fstat(STDOUT_FILENO, &st) && S_ISFIFO(st.st_mode))
@@ -471,6 +473,7 @@ static int __cmd_record(struct perf_record *rec, int argc,
const char **argv)
goto out_delete_session;
}
+ alarm(duration);
if (forks) {
err = perf_evlist__prepare_workload(evsel_list, &opts->target,
argv, opts->pipe_output,
@@ -955,6 +958,8 @@ const struct option record_options[] = {
parse_branch_stack),
OPT_BOOLEAN('W', "weight", &record.opts.sample_weight,
"sample by weight (on special events only)"),
+ OPT_UINTEGER(0, "duration", &duration,
+ "run for specified duration (seconds)"),
OPT_END()
};
--
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 0/6] Basic scheduler support for automatic NUMA balancing
* Srikar Dronamraju [2013-06-28 19:24:22]: > * Mel Gorman [2013-06-26 15:37:59]: > > > It's several months overdue and everything was quiet after 3.8 came out > > but I recently had a chance to revisit automatic NUMA balancing for a few > > days. I looked at basic scheduler integration resulting in the following > > small series. Much of the following is heavily based on the numacore series > > which in itself takes part of the autonuma series from back in November. In > > particular it borrows heavily from Peter Ziljstra's work in "sched, numa, > > mm: Add adaptive NUMA affinity support" but deviates too much to preserve > > Signed-off-bys. As before, if the relevant authors are ok with it I'll > > add Signed-off-bys (or add them yourselves if you pick the patches up). > > > Here is a snapshot of the results of running autonuma-benchmark running on 8 > node 64 cpu system with hyper threading disabled. Ran 5 iterations for each > setup > > KernelVersion: 3.9.0-mainline_v39+() > Testcase: Min Max Avg > numa01: 1784.16 1864.15 1800.16 > numa02:32.0732.7232.59 > > KernelVersion: 3.9.0-mainline_v39+() + mel's patches > Testcase: Min Max Avg %Change > numa01: 1752.48 1859.60 1785.600.82% > numa02:47.2160.5853.43 -39.00% > > So numa02 case; we see a degradation of around 39%. > I reran the tests again KernelVersion: 3.9.0-mainline_v39+() Testcase: Min Max Avg numa01: 1784.16 1864.15 1800.16 numa01_THREAD_ALLOC: 293.75 315.35 311.03 numa02:32.0732.7232.59 numa02_SMT:39.2739.7939.69 KernelVersion: 3.9.0-mainline_v39+() + your patches Testcase: Min Max Avg %Change numa01: 1720.40 1876.89 1767.751.83% numa01_THREAD_ALLOC: 464.34 554.82 496.64 -37.37% numa02:52.0258.5756.21 -42.02% numa02_SMT:42.0752.6447.33 -16.14% -- Thanks and Regards Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.
Signed-off-by: George Cherian
---
drivers/usb/host/xhci-pci.c | 1 -
drivers/usb/host/xhci.c | 7 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index cc24e39..f00cb20 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
- xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
xhci->limit_active_eps = 64;
xhci->quirks |= XHCI_SW_BW_CHECKING;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d8f640b..0f7be59 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
get_quirks(dev, xhci);
+ /* In xhci controllers which follow xhci 1.0 spec gives a spurious
+* success event after a short transfer. This quirk will ignore such
+* spurious event.
+*/
+ if (xhci->hci_version > 0x96)
+ xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
+
/* Make sure the HC is halted. */
retval = xhci_halt(xhci);
if (retval)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 07/01/2013 07:13 AM, Matthew Garrett wrote: > On Sun, Jun 30, 2013 at 11:30:59PM -0500, Matthew Thode wrote: > >> mjg59, is there anything I can do to help move this bug forward? I've >> done all I can think of (even tried a serial expresscard slot for logging). > > It does sound like a bug, but unfortunately unless it can be duplicated > on real hardware without restrictive mem= arguments it's likely to be > low on my priorities - there's still enough UEFI bugs that hit people in > default configurations that they tend to get priority, I'm afraid. > real hardware -> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out any memory restriction. I guess I should try to get more information for you and see if it isn't some configuration quirk. lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] drivers: spi: Add qspi flash controller
+ Artem
On Wednesday 26 June 2013 01:11 PM, Sourav Poddar wrote:
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).
Signed-off-by: Sourav Poddar
---
drivers/spi/Kconfig |6 +
drivers/spi/Makefile |1 +
drivers/spi/ti-qspi.c | 352 +
3 files changed, 359 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/ti-qspi.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92a9345..29a363b 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,12 @@ config SPI_OMAP24XX
SPI master controller for OMAP24XX and later Multichannel SPI
(McSPI) modules.
+config QSPI_DRA7xxx
+ tristate "DRA7xxx QSPI controller support"
+ depends on ARCH_OMAP2PLUS
+ help
+ QSPI master controller for DRA7xxx used for flash devices.
+
config SPI_OMAP_100K
tristate "OMAP SPI 100K"
depends on ARCH_OMAP850 || ARCH_OMAP730
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..ea14eff 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K) += spi-omap-100k.o
obj-$(CONFIG_SPI_OMAP24XX)+= spi-omap2-mcspi.o
+obj-$(CONFIG_QSPI_DRA7xxx) += ti-qspi.o
obj-$(CONFIG_SPI_ORION) += spi-orion.o
obj-$(CONFIG_SPI_PL022) += spi-pl022.o
obj-$(CONFIG_SPI_PPC4xx) += spi-ppc4xx.o
diff --git a/drivers/spi/ti-qspi.c b/drivers/spi/ti-qspi.c
new file mode 100644
index 000..b33646a
--- /dev/null
+++ b/drivers/spi/ti-qspi.c
@@ -0,0 +1,352 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct dra7xxx_qspi {
+ struct spi_master *master;
+ void __iomem*base;
+ int device_type;
+ struct device *dev;
+ u32 spi_max_frequency;
+ u32 cmd;
+ u32 dc;
+};
+
+#define QSPI_PID (0x0)
+#define QSPI_SYSCONFIG (0x10)
+#define QSPI_INTR_STATUS_RAW_SET (0x20)
+#define QSPI_INTR_STATUS_ENABLED_CLEAR (0x24)
+#define QSPI_INTR_ENABLE_SET_REG (0x28)
+#define QSPI_INTR_ENABLE_CLEAR_REG (0x2c)
+#define QSPI_SPI_CLOCK_CNTRL_REG (0x40)
+#define QSPI_SPI_DC_REG(0x44)
+#define QSPI_SPI_CMD_REG (0x48)
+#define QSPI_SPI_STATUS_REG(0x4c)
+#define QSPI_SPI_DATA_REG (0x50)
+#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SWITCH_REG(0x64)
+#define QSPI_SPI_SETUP1_REG(0x58)
+#define QSPI_SPI_SETUP2_REG(0x5c)
+#define QSPI_SPI_SETUP3_REG(0x60)
+#define QSPI_SPI_DATA_REG_1(0x68)
+#define QSPI_SPI_DATA_REG_2(0x6c)
+#define QSPI_SPI_DATA_REG_3(0x70)
+
+#define QSPI_TIMEOUT 200
+
+#define QSPI_FCLK 19200
+
+/* Clock Control */
+#define QSPI_CLK_EN(1<< 31)
+#define QSPI_CLK_DIV_MAX 0x
+
+/* Command */
+#define QSPI_EN_CS(n) (n<< 28)
+#define QSPI_WLEN(n) ((n-1)<< 19)
+#define QSPI_3_PIN (1<< 18)
+#define QSPI_RD_SNGL (1<< 16)
+#define QSPI_WR_SNGL (2<< 16)
+#define QSPI_RD_QUAD (7<< 16)
+#define QSPI_INVAL (4<< 16)
+
+/* Device Control */
+#define QSPI_DD(m, n) (m<< (3 + n*8))
+#define QSPI_CKPHA(n) (1<< (2 + n*8))
+#define QSPI_CSPOL(n) (1<< (1 + n*8))
+#define QSPI_CKPOL(n) (1<< (n*8))
+
+/* Status */
+#define Q
Re: [PATCH 3/3] drivers: mtd: spinand: Add qspi spansion flash controller
+ Artem
On Wednesday 26 June 2013 01:11 PM, Sourav Poddar wrote:
The patch adds support for spansion s25fl256s spi flash controller.
Currently, the patch supports only SPI based transaction.
As, the qspi to which flash is attached supports memory mapped interface,
support will be added in future for memory mapped transactions also.
This driver gets attached to the generic spinand mtd framework proposed in the
first patch of the series.
Signed-off-by: Sourav Poddar
---
drivers/mtd/spinand/Kconfig |7 +
drivers/mtd/spinand/Makefile|2 +-
drivers/mtd/spinand/ti-qspi-flash.c | 373 +++
3 files changed, 381 insertions(+), 1 deletions(-)
create mode 100644 drivers/mtd/spinand/ti-qspi-flash.c
diff --git a/drivers/mtd/spinand/Kconfig b/drivers/mtd/spinand/Kconfig
index 38c739f..1342de3 100644
--- a/drivers/mtd/spinand/Kconfig
+++ b/drivers/mtd/spinand/Kconfig
@@ -16,6 +16,13 @@ config MTD_SPINAND_ONDIEECC
help
Internel ECC
+config MTD_S25FL256S
+ tristate "Support spansion memory mapped SPI Flash chips"
+ depends on SPI_MASTER
+ help
+ This enables access to spansion QSPI flash chips, which used
+ memory mapped interface used for program and data storage.
+
config MTD_SPINAND_SWECC
bool "Use software ECC"
depends on MTD_NAND
diff --git a/drivers/mtd/spinand/Makefile b/drivers/mtd/spinand/Makefile
index 355e726..8ad0dd5 100644
--- a/drivers/mtd/spinand/Makefile
+++ b/drivers/mtd/spinand/Makefile
@@ -5,6 +5,6 @@
# Core functionality.
obj-$(CONFIG_MTD_SPINAND) += spinand.o
-spinand-objs := spinand_mtd.o spinand_lld.o
+spinand-objs := spinand_mtd.o spinand_lld.o ti-qspi-flash.o
diff --git a/drivers/mtd/spinand/ti-qspi-flash.c
b/drivers/mtd/spinand/ti-qspi-flash.c
new file mode 100644
index 000..dfa6235
--- /dev/null
+++ b/drivers/mtd/spinand/ti-qspi-flash.c
@@ -0,0 +1,373 @@
+/*
+ * MTD SPI driver for spansion s25fl256s (and similar) serial flash chips
+ *
+ * Author: Sourav Poddar, sourav.pod...@ti.com
+ *
+ * Copyright (c) 2013, Texas Instruments.
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#defineCMD_OPCODE_RDSR 0x05/* Read status register */
+#define CMD_OPCODE_FAST_READ 0x0b/* Fast Read */
+#defineMAX_READY_WAIT_JIFFIES (40 * HZ) /* M25P16 specs 40s max chip
erase */
+
+#defineSR_WIP 1 /* Write in progress */
+#defineSR_WEL 2 /* Write enable latch */
+
+static u16 addr_width;
+bool fast_read;
+
+static struct nand_ecclayout spinand_oob_0 = {
+ .eccbytes = 0,
+ .eccpos = {},
+ .oobavail = 0,
+ .oobfree = {
+ {.offset = 0,
+ .length = 0}, }
+};
+
+/*
+ * Read the status register, returning its value in the location
+ * Return the status register value.
+ * Returns negative if error occurred.
+*/
+static int read_sr(struct spi_device *spi_nand)
+{
+ ssize_t retval;
+ u8 val;
+ u8 code = CMD_OPCODE_RDSR;
+
+ retval = spi_write_then_read(spi_nand,&code, 1,&val, 1);
+
+ if (retval< 0) {
+ dev_info(&spi_nand->dev, "error %d reading SR\n",
+ (int) retval);
+ return retval;
+ }
+
+ return val;
+}
+
+/*
+ * Set write enable latch with Write Enable command.
+ * Returns negative if error occurred.
+*/
+static inline int write_enable(struct spi_device *spi_nand)
+{
+ u8 code = CMD_WR_ENABLE;
+
+ return spi_write_then_read(spi_nand,&code, 1, NULL, 0);
+}
+
+/*
+ * Send write disble instruction to the chip.
+*/
+static inline int write_disable(struct spi_device *spi_nand)
+{
+ u8 code = CMD_WR_DISABLE;
+
+ return spi_write_then_read(spi_nand,&code, 1, NULL, 0);
+}
+
+/*
+ * Service routine to read status register until ready, or timeout occurs.
+ * Returns non-zero if error.
+*/
+static int wait_till_ready(struct spi_device *spi_nand)
+{
+ unsigned long deadline;
+ int sr;
+
+ deadline = jiffies + MAX_READY_WAIT_JIFFIES;
+
+ do {
+ sr = read_sr(spi_nand);
+ if (sr< 0)
+ return -1;
+ else if (!(sr& SR_WIP))
+ break;
+
+ cond_resched();
+ } while (!time_after_eq(jiffies, deadline));
+
+ if ((sr& SR_WIP) == 0)
+ return 0;
+
+ return -1;
+}
+
+static inline int spinand_read_id(struct spi_device *spi_nand, u8 *id)
+{
+ u8 code = CMD_READ_ID;
+
+ return spi_write_then_read(spi_nand,&code, 1, id, sizeof(id));
+}
+
Re: [PATCH 0/3] spi/mtd generic framework,ti qspi controller and spansion driver
+ Artem On Wednesday 26 June 2013 01:11 PM, Sourav Poddar wrote: This patch series add support for the generic spi based flash framework(spinand_mtd), which can be used used by any spi based flash device to attach itself to mtd framework. The first patch of this series includes both the generic framework and the the micron device(spinand_lld) making use of the framework. I picked the first patch as a standalone patch. Can split the generic and the lld part based on community suggestions. The second patch is the ti qspi controller driver. The third patch is the spansion s25fl256s driver, making use of the the generic spinand_mtd frameowrk. Test info: Tested the generic framework(spinand_mtd.c) along with patch(2&3) on my dra7xx board for write/erase/read using nand utils. Compile tested(spinand_lld.c). Mona Anonuevo (1): drivers: mtd: spinand: Add generic spinand frameowrk and micron driver. Sourav Poddar (2): drivers: spi: Add qspi flash controller drivers: mtd: spinand: Add qspi spansion flash controller drivers/mtd/Kconfig |2 + drivers/mtd/Makefile|2 + drivers/mtd/spinand/Kconfig | 31 ++ drivers/mtd/spinand/Makefile| 10 + drivers/mtd/spinand/spinand_lld.c | 776 +++ drivers/mtd/spinand/spinand_mtd.c | 690 +++ drivers/mtd/spinand/ti-qspi-flash.c | 373 + drivers/spi/Kconfig |6 + drivers/spi/Makefile|1 + drivers/spi/ti-qspi.c | 352 include/linux/mtd/spinand.h | 155 +++ 11 files changed, 2398 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/spinand/Kconfig create mode 100644 drivers/mtd/spinand/Makefile create mode 100644 drivers/mtd/spinand/spinand_lld.c create mode 100644 drivers/mtd/spinand/spinand_mtd.c create mode 100644 drivers/mtd/spinand/ti-qspi-flash.c create mode 100644 drivers/spi/ti-qspi.c create mode 100644 include/linux/mtd/spinand.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] drivers: mtd: spinand: Add generic spinand frameowrk and micron driver.
+ Artem
On Wednesday 26 June 2013 01:11 PM, Sourav Poddar wrote:
From: Mona Anonuevo
This patch adds support for a generic spinand framework(spinand_mtd.c).
This frameowrk can be used for other spi based flash devices also. The idea
is to have a common model under drivers/mtd, as also present for other no spi
devices(there is a generic framework and device part simply attaches itself to
it.)
The generic frework will be used later by me for a SPI based spansion S25FL256
device.
The patch also contains a micron driver attaching itself to generic framework.
Signed-off-by: Mona Anonuevo
Signed-off-by: Tuan Nguyen
Signed-off-by: Sourav Poddar
[I picked this as a standalone patch, can split it into generic and device part
based on community feedback.]
drivers/mtd/Kconfig |2 +
drivers/mtd/Makefile |2 +
drivers/mtd/spinand/Kconfig | 24 ++
drivers/mtd/spinand/Makefile | 10 +
drivers/mtd/spinand/spinand_lld.c | 776 +
drivers/mtd/spinand/spinand_mtd.c | 690 +
include/linux/mtd/spinand.h | 155
7 files changed, 1659 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spinand/Kconfig
create mode 100644 drivers/mtd/spinand/Makefile
create mode 100644 drivers/mtd/spinand/spinand_lld.c
create mode 100644 drivers/mtd/spinand/spinand_mtd.c
create mode 100644 include/linux/mtd/spinand.h
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 5fab4e6..c9e6c60 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -318,6 +318,8 @@ source "drivers/mtd/nand/Kconfig"
source "drivers/mtd/onenand/Kconfig"
+source "drivers/mtd/spinand/Kconfig"
+
source "drivers/mtd/lpddr/Kconfig"
source "drivers/mtd/ubi/Kconfig"
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 4cfb31e..cce68db 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -32,4 +32,6 @@ inftl-objs:= inftlcore.o inftlmount.o
obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/
+obj-y += spinand/
+
obj-$(CONFIG_MTD_UBI) += ubi/
diff --git a/drivers/mtd/spinand/Kconfig b/drivers/mtd/spinand/Kconfig
new file mode 100644
index 000..38c739f
--- /dev/null
+++ b/drivers/mtd/spinand/Kconfig
@@ -0,0 +1,24 @@
+#
+# linux/drivers/mtd/spinand/Kconfig
+#
+
+menuconfig MTD_SPINAND
+ tristate "SPINAND Device Support"
+ depends on MTD
+ help
+This enables support for accessing Micron SPI NAND flash
+devices.
+
+if MTD_SPINAND
+
+config MTD_SPINAND_ONDIEECC
+ bool "Use SPINAND internal ECC"
+ help
+Internel ECC
+
+config MTD_SPINAND_SWECC
+ bool "Use software ECC"
+ depends on MTD_NAND
+ help
+software ECC
+endif
diff --git a/drivers/mtd/spinand/Makefile b/drivers/mtd/spinand/Makefile
new file mode 100644
index 000..355e726
--- /dev/null
+++ b/drivers/mtd/spinand/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for the SPI NAND MTD
+#
+
+# Core functionality.
+obj-$(CONFIG_MTD_SPINAND) += spinand.o
+
+spinand-objs := spinand_mtd.o spinand_lld.o
+
+
diff --git a/drivers/mtd/spinand/spinand_lld.c
b/drivers/mtd/spinand/spinand_lld.c
new file mode 100644
index 000..9f53737
--- /dev/null
+++ b/drivers/mtd/spinand/spinand_lld.c
@@ -0,0 +1,776 @@
+/*
+spinand_lld.c
+
+Copyright (c) 2009-2010 Micron Technology, Inc.
+
+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.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#define mu_spi_nand_driver_version "Beagle-MTD_01.00_Linux2.6.33_20100507"
+#define SPI_NAND_MICRON_DRIVER_KEY 0x1233567
+
+//
+
+/**
+ OOB area specification layout: Total 32 available free bytes.
+*/
+static struct nand_ecclayout spinand_oob_64 = {
+ .eccbytes = 24,
+ .eccpos = {
+ 1, 2, 3, 4, 5, 6,
+ 17, 18, 19, 20, 21, 22,
+ 33, 34, 35, 36, 37, 38,
+ 49, 50, 51, 52, 53, 54, },
+ .oobavail = 32,
+ .oobfree = {
+ {.offset = 8,
+.length = 8},
+ {.offset = 24,
+.length = 8},
+ {.offset = 40,
+.length = 8},
+ {.offset = 56,
+.length = 8}, }
+};
+/**
+ * spinand_cmd - to process a command to send to the SPI Nand
+ *
+ * Description:
+ *
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On Sun, Jun 30, 2013 at 11:30:59PM -0500, Matthew Thode wrote: > mjg59, is there anything I can do to help move this bug forward? I've > done all I can think of (even tried a serial expresscard slot for logging). It does sound like a bug, but unfortunately unless it can be duplicated on real hardware without restrictive mem= arguments it's likely to be low on my priorities - there's still enough UEFI bugs that hit people in default configurations that they tend to get priority, I'm afraid. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 06/30/2013 11:41 PM, Luca Barbato wrote: > On 07/01/2013 06:30 AM, Matthew Thode wrote: > >> You had the problem where it was blank on boot (right after grub, no >> kernel messages at all)? Sounds like this might not be limited to just >> Lenovo then. > > no grub, efi-stub directly from the efi shell. > >> mjg59, is there anything I can do to help move this bug forward? I've >> done all I can think of (even tried a serial expresscard slot for logging). > > If you feel like bisecting seems the only option =_= > > lu > I was hoping to avoid that, was thinking of bisecting 3.8->3.9 for only the uefi stuff though, should help keep the traffic down. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [LOCKDEP] cpufreq: possible circular locking dependency detected
Hi, Sergey
On 06/26/2013 05:15 AM, Sergey Senozhatsky wrote:
[snip]
>
> [ 60.277848] Chain exists of:
> (&(&j_cdbs->work)->work) --> &j_cdbs->timer_mutex --> cpu_hotplug.lock
>
> [ 60.277864] Possible unsafe locking scenario:
>
> [ 60.277869]CPU0CPU1
> [ 60.277873]
> [ 60.277877] lock(cpu_hotplug.lock);
> [ 60.277885]lock(&j_cdbs->timer_mutex);
> [ 60.277892]lock(cpu_hotplug.lock);
> [ 60.277900] lock((&(&j_cdbs->work)->work));
> [ 60.277907]
> *** DEADLOCK ***
It may caused by that 'j_cdbs->work.work' and 'j_cdbs->timer_mutex'
has the same lock class, although they are different lock...
This may help fix the issue:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 5af40ad..aa05eaa 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -229,6 +229,8 @@ static void set_sampling_rate(struct dbs_data *dbs_data,
}
}
+static struct lock_class_key j_cdbs_key;
+
int cpufreq_governor_dbs(struct cpufreq_policy *policy,
struct common_dbs_data *cdata, unsigned int event)
{
@@ -366,6 +368,8 @@ int (struct cpufreq_policy *policy,
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
mutex_init(&j_cdbs->timer_mutex);
+ lockdep_set_class(&j_cdbs->timer_mutex, &j_cdbs_key);
+
INIT_DEFERRABLE_WORK(&j_cdbs->work,
dbs_data->cdata->gov_dbs_timer);
}
Would you like to take a try?
Regards,
Michael Wang
>
> [ 60.277915] 6 locks held by bash/2225:
> [ 60.277919] #0: (sb_writers#6){.+.+.+}, at: []
> vfs_write+0x1c3/0x1f0
> [ 60.277937] #1: (&buffer->mutex){+.+.+.}, at: []
> sysfs_write_file+0x3c/0x150
> [ 60.277954] #2: (s_active#61){.+.+.+}, at: []
> sysfs_write_file+0xc3/0x150
> [ 60.277972] #3: (x86_cpu_hotplug_driver_mutex){+.+...}, at:
> [] cpu_hotplug_driver_lock+0x17/0x20
> [ 60.277990] #4: (cpu_add_remove_lock){+.+.+.}, at: []
> cpu_down+0x22/0x50
> [ 60.278007] #5: (cpu_hotplug.lock){+.+.+.}, at: []
> cpu_hotplug_begin+0x2b/0x60
> [ 60.278023]
> stack backtrace:
> [ 60.278031] CPU: 3 PID: 2225 Comm: bash Not tainted
> 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744
> [ 60.278037] Hardware name: Acer Aspire 5741G/Aspire 5741G
> , BIOS V1.20 02/08/2011
> [ 60.278042] 8204e110 88014df6b9f8 815b3d90
> 88014df6ba38
> [ 60.278055] 815b0a8d 880150ed3f60 880150ed4770
> 3871c4002c8980b2
> [ 60.278068] 880150ed4748 880150ed4770 880150ed3f60
> 88014df6bb00
> [ 60.278081] Call Trace:
> [ 60.278091] [] dump_stack+0x19/0x1b
> [ 60.278101] [] print_circular_bug+0x2b6/0x2c5
> [ 60.278111] [] __lock_acquire+0x1766/0x1d30
> [ 60.278123] [] ? __kernel_text_address+0x58/0x80
> [ 60.278134] [] lock_acquire+0xa4/0x200
> [ 60.278142] [] ? flush_work+0x5/0x280
> [ 60.278151] [] flush_work+0x3d/0x280
> [ 60.278159] [] ? flush_work+0x5/0x280
> [ 60.278169] [] ? mark_held_locks+0x94/0x140
> [ 60.278178] [] ? __cancel_work_timer+0x77/0x120
> [ 60.278188] [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [ 60.278196] [] __cancel_work_timer+0x8a/0x120
> [ 60.278206] [] cancel_delayed_work_sync+0x13/0x20
> [ 60.278214] [] cpufreq_governor_dbs+0x529/0x6f0
> [ 60.278225] [] cs_cpufreq_governor_dbs+0x17/0x20
> [ 60.278234] [] __cpufreq_governor+0x48/0x100
> [ 60.278244] [] __cpufreq_remove_dev.isra.14+0x80/0x3c0
> [ 60.278255] [] cpufreq_cpu_callback+0x38/0x4c
> [ 60.278265] [] notifier_call_chain+0x5d/0x110
> [ 60.278275] [] __raw_notifier_call_chain+0xe/0x10
> [ 60.278284] [] _cpu_down+0x88/0x330
> [ 60.278292] [] ? cpu_hotplug_driver_lock+0x17/0x20
> [ 60.278302] [] cpu_down+0x36/0x50
> [ 60.278311] [] store_online+0x98/0xd0
> [ 60.278320] [] dev_attr_store+0x18/0x30
> [ 60.278329] [] sysfs_write_file+0xdb/0x150
> [ 60.278337] [] vfs_write+0xbd/0x1f0
> [ 60.278347] [] ? fget_light+0x320/0x4b0
> [ 60.278355] [] SyS_write+0x4c/0xa0
> [ 60.278364] [] tracesys+0xd0/0xd5
> [ 60.280582] smpboot: CPU 1 is now offline
>
>
> -ss
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 07/01/2013 06:30 AM, Matthew Thode wrote: > You had the problem where it was blank on boot (right after grub, no > kernel messages at all)? Sounds like this might not be limited to just > Lenovo then. no grub, efi-stub directly from the efi shell. > mjg59, is there anything I can do to help move this bug forward? I've > done all I can think of (even tried a serial expresscard slot for logging). If you feel like bisecting seems the only option =_= lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/7] autofs - change CONFIG_AUTOFS4_FS to CONFIG_AUTOFS_FS
Hi Ian, On Mon, 01 Jul 2013 11:14:51 +0800 Ian Kent wrote: > > Signed-off-by: Ian Kent Please don't do this. Find a simple way to make sure that if CONFIG_AUTOFS4_FS is set, then "make oldconfig" (or equivalent) will cause CONFIG_AUTOFS_FS to be set the same. The maintainers will update the defconfigs over time. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp39WhdxQp6v.pgp Description: PGP signature
linux-next: manual merge of the trivial tree with the fbdev tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/video/omap2/displays/panel-n8x0.c between commit ecc8b3708986
("OMAPDSS: Add panel dev pointer to dssdev") from the fbdev tree and
commit 8b513d0cf603 ("treewide: Fix typo in printk") from the trivial
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/video/omap2/displays/panel-n8x0.c
index d3860c5,860b180..000
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@@ -527,7 -527,7 +527,7 @@@ static int n8x0_panel_update(struct oma
dh = dssdev->panel.timings.y_res;
if (x != 0 || y != 0 || w != dw || h != dh) {
- dev_err(dssdev->dev, "invaid update region %d, %d, %d, %d\n",
- dev_err(&dssdev->dev, "invalid update region %d, %d, %d, %d\n",
++ dev_err(dssdev->dev, "invalid update region %d, %d, %d, %d\n",
x, y, w, h);
return -EINVAL;
}
pgpYhWbsIC5Wq.pgp
Description: PGP signature
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 06/27/2013 01:17 PM, Luca Barbato wrote: > On 06/27/2013 06:47 PM, Matthew Thode wrote: >> There is an early boot failure with linux-3.[9,10].??? when booting >> using uefi on low memory systems. >> >> This seems like it might be hardware specific, I am running on a Lenovo >> T520, running bios version 1.42, firmware rev 1.36. >> > > Had the same problem with linux 3.10-rc1 and a stock mac book pro, I > hadn't investigated much further though. > > lu > You had the problem where it was blank on boot (right after grub, no kernel messages at all)? Sounds like this might not be limited to just Lenovo then. mjg59, is there anything I can do to help move this bug forward? I've done all I can think of (even tried a serial expresscard slot for logging). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/3] udp: make use of static_key_slow_set_true() interface
On 06/28/2013 11:13 PM, Steven Rostedt wrote:
On Fri, 2013-06-28 at 22:30 +, jba...@akamai.com wrote:
Make use of the simpler API.
Need to make the change log much more descriptive. Never assume someone
in the future that looks up a change to this file will know about other
commits that led to this. Each change log should be sufficient to stand
on its own.
Explain why this patch is needed. And it's not about the use of a
simpler API.
It actually fixes a real bug.
Signed-off-by: Jason Baron
---
net/ipv4/udp.c |9 -
net/ipv6/udp.c |9 -
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 0bf5d39..b8d0029 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1421,11 +1421,10 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct
sk_buff *skb)
}
-static struct static_key udp_encap_needed __read_mostly;
+static struct static_key_boolean udp_encap_needed __read_mostly;
void udp_encap_enable(void)
{
- if (!static_key_enabled(&udp_encap_needed))
- static_key_slow_inc(&udp_encap_needed);
+ static_key_slow_set_true(&udp_encap_needed);
}
EXPORT_SYMBOL(udp_encap_enable);
@@ -1450,7 +1449,7 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
goto drop;
nf_reset(skb);
- if (static_key_false(&udp_encap_needed) && up->encap_type) {
+ if (static_key_false(&udp_encap_needed.key) && up->encap_type) {
I wonder if we should add a static_bool_key_false(), because that added
".key" is a bit confusing.
-- Steve
Yeah - that is sort of ugly, but it avoids introducing a new branch API
call. That said, a 'static_bool_key_false()' would probably be a simple
wrapper function.
-Jason
int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
/*
@@ -1773,7 +1772,7 @@ void udp_destroy_sock(struct sock *sk)
bool slow = lock_sock_fast(sk);
udp_flush_pending_frames(sk);
unlock_sock_fast(sk, slow);
- if (static_key_false(&udp_encap_needed) && up->encap_type) {
+ if (static_key_false(&udp_encap_needed.key) && up->encap_type) {
void (*encap_destroy)(struct sock *sk);
encap_destroy = ACCESS_ONCE(up->encap_destroy);
if (encap_destroy)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 42923b1..94a4091 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -573,11 +573,10 @@ static __inline__ void udpv6_err(struct sk_buff *skb,
__udp6_lib_err(skb, opt, type, code, offset, info, &udp_table);
}
-static struct static_key udpv6_encap_needed __read_mostly;
+static struct static_key_boolean udpv6_encap_needed __read_mostly;
void udpv6_encap_enable(void)
{
- if (!static_key_enabled(&udpv6_encap_needed))
- static_key_slow_inc(&udpv6_encap_needed);
+ static_key_slow_set_true(&udpv6_encap_needed);
}
EXPORT_SYMBOL(udpv6_encap_enable);
@@ -590,7 +589,7 @@ int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
- if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
+ if (static_key_false(&udpv6_encap_needed.key) && up->encap_type) {
int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
/*
@@ -1300,7 +1299,7 @@ void udpv6_destroy_sock(struct sock *sk)
udp_v6_flush_pending_frames(sk);
release_sock(sk);
- if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
+ if (static_key_false(&udpv6_encap_needed.key) && up->encap_type) {
void (*encap_destroy)(struct sock *sk);
encap_destroy = ACCESS_ONCE(up->encap_destroy);
if (encap_destroy)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/regulator/palmas-regulator.c: In function 'palmas_regulators_probe':
drivers/regulator/palmas-regulator.c:850:8: error: 'PALMAS_REG_SMPS10'
undeclared (first use in this function)
case PALMAS_REG_SMPS10:
^
Caused by commit 07a02e0b1a4f ("regulator: palmas: model SMPS10 as two
regulators"). Clearly not build tested at all :-( Grep is your
friend ...
I have used the regulator tree from next-20130628 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpdrk19yEBxO.pgp
Description: PGP signature
Re: [PATCH 0/3] static keys: fix test/set races
On 06/29/2013 03:20 AM, Ingo Molnar wrote: * jba...@akamai.com wrote: Hi, As pointed out by Andi Kleen, some static key users can be racy because they check the value of the key->enabled, and then subsequently update the branch direction. A number of call sites have 'higher' level locking that avoids this race, but the usage in the scheduler features does not. See: http://lkml.indiana.edu/hypermail/linux/kernel/1304.2/01655.html But that's not an issue at all - switching the scheduler features is for development and debugging only, and in some cases higher level locking would be needed to solve it 'properly', beyond what the keys API could give ... So this is pretty pointless, sorry, please don't complicate this facility. Thanks, Ingo Hi Ingo, Yes, I agree that 'higher' level locking may be required for some callers of the newly proposed interface. However, I do think that the static_key_slow_set_true()/false() provides a nice abstraction for some callers, while addressing test/set() races, by making that sequence atomic. I view the proposed inteface of set_true()/set_false() as somewhat analogous to an atomic_set() call. In the same way, the current static_key_slow_inc()/dec() are analogous to atomic_inc()/dec(). It arguably makes the code code a bit more readable, transforming sequences such as: if (!static_key_enabled(&control_var)) static_key_slow_inc(&control_var); into: static_key_slow_set_true(&control_var); I see at least 3 users of static_keys in the tree which I think would benefit from this transformation. The 2 attached with this series, and the usage in kernel/tracepoint.c. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi | 90 +++
arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi | 90 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
3 files changed, 182 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
new file mode 100644
index 000..c626c49
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
@@ -0,0 +1,90 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * Copyright 2011-2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma2";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ cell-index = <4>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ cell-index = <5>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ cell-index = <6>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ cell-index = <7>;
+ interrupts = <79 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
new file mode 100644
index 000..980ea77
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
@@ -0,0 +1,90 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x101000 ]
+ *
+ * Copyright 2011-2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modificatio
[PATCH 2/2] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/fsldma.c | 48 ++--
drivers/dma/fsldma.h |4 ++--
2 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 4fc2980..0f453ea 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1119,27 +1119,33 @@ static irqreturn_t fsldma_ctrl_irq(int irq, void *data)
struct fsldma_device *fdev = data;
struct fsldma_chan *chan;
unsigned int handled = 0;
- u32 gsr, mask;
+ u8 chan_sr[round_up(FSL_DMA_MAX_CHANS_PER_DEVICE, 4)];
+ u32 gsr;
int i;
- gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ? in_be32(fdev->regs)
- : in_le32(fdev->regs);
- mask = 0xff00;
- dev_dbg(fdev->dev, "IRQ: gsr 0x%.8x\n", gsr);
+ memset(&chan_sr, 0, sizeof(chan_sr));
+ gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ? in_be32(fdev->regs0)
+ : in_le32(fdev->regs0);
+ memcpy(&chan_sr[0], &gsr, 4);
+ dev_dbg(fdev->dev, "IRQ: gsr0 0x%.8x\n", gsr);
+
+ if (of_device_is_compatible(fdev->dev->of_node, "fsl,eloplus-dma2")) {
+ gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ?
+ in_be32(fdev->regs1) : in_le32(fdev->regs1);
+ memcpy(&chan_sr[4], &gsr, 4);
+ dev_dbg(fdev->dev, "IRQ: gsr1 0x%.8x\n", gsr);
+ }
for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
chan = fdev->chan[i];
if (!chan)
continue;
- if (gsr & mask) {
+ if (chan_sr[i]) {
dev_dbg(fdev->dev, "IRQ: chan %d\n", chan->id);
fsldma_chan_irq(irq, chan);
handled++;
}
-
- gsr &= ~mask;
- mask >>= 8;
}
return IRQ_RETVAL(handled);
@@ -1261,7 +1267,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
- chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+ chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1341,13 +1349,22 @@ static int fsldma_of_probe(struct platform_device *op)
INIT_LIST_HEAD(&fdev->common.channels);
/* ioremap the registers for use */
- fdev->regs = of_iomap(op->dev.of_node, 0);
- if (!fdev->regs) {
- dev_err(&op->dev, "unable to ioremap registers\n");
+ fdev->regs0 = of_iomap(op->dev.of_node, 0);
+ if (!fdev->regs0) {
+ dev_err(&op->dev, "unable to ioremap register0\n");
err = -ENOMEM;
goto out_free_fdev;
}
+ if (of_device_is_compatible(op->dev.of_node, "fsl,eloplus-dma2")) {
+ fdev->regs1 = of_iomap(op->dev.of_node, 1);
+ if (!fdev->regs1) {
+ dev_err(&op->dev, "unable to ioremap register1\n");
+ err = -ENOMEM;
+ goto out_free_fdev;
+ }
+ }
+
/* map the channel IRQ if it exists, but don't hookup the handler yet */
fdev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
@@ -1427,7 +1444,9 @@ static int fsldma_of_remove(struct platform_device *op)
fsl_dma_chan_remove(fdev->chan[i]);
}
- iounmap(fdev->regs);
+ iounmap(fdev->regs0);
+ if (of_device_is_compatible(op->dev.of_node, "fsl,eloplus-dma2"))
+ iounmap(fdev->regs1);
dev_set_drvdata(&op->dev, NULL);
kfree(fdev);
@@ -1436,6 +1455,7 @@ static int fsldma_of_remove(struct platform_device *op)
static const struct of_device_id fsldma_of_ids[] = {
{ .compatible = "fsl,eloplus-dma", },
+ { .compatible = "fsl,eloplus-dma2", },
{ .compatible = "fsl,elo-dma", },
{}
};
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..880664d 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,10 +112,10 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
- void __iomem *regs; /* DGSR register base */
+ void __iomem *regs0, *regs1;/* DGSR registers */
struct device *dev;
struct dma_device common;
struct fsldma_chan *chan[FSL_DMA_MAX_CHANS_PER_DEVICE];
--
1.7
Re: [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'
On 07/01/2013 09:40 AM, Chen Gang wrote:
> On 06/26/2013 06:22 PM, Chen Gang wrote:
>> > On 06/26/2013 06:17 PM, Richard Weinberger wrote:
>>> >> Am 26.06.2013 12:01, schrieb Chen Gang:
> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>>> >> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger
>>> >> wrote:
>>> >> Since the API itself already contents the
>>> >> meaning: "return NULL means
>>> >> the arch has no related io memory",
>>> >> No, NULL means it could not map the I/O memory.
>>> >>
>
> "it could not map the I/O memory" includes "has no related io
> memory".
> So it is enough for our case.
>
>>> >> Why not define a generic dummy one in
>>> >> "include/asm-generic/io.h" instead
>>> >> of "HAS_IOMEM" (which has already spread many
>>> >> various places, and also,
>>> >> most of new drivers have to know about it).
>>> >>
>>> >> e.g: in "include/asm-generic/io.h", if
>>> >> "CONFIG_HAS_IOMEM=n", define a
>>> >> dummy ioremap() which return NULL ... (also need
>>> >> consider more details).
>>> >>
>>> >> Because we don't even want to build these drivers and
>>> >> not make them fail while
>>> >> executing io memory related functions.
>>> >> Indeed, it doesn't make sense to build drivers that cannot work.
>>> >> And they may fail in a very bad way.
>
> That is our 'platform' guys feeling, not the 'module' guys, as
> 'platform' guys, it is better to provide the choice to 'module' guys,
> and let them decide by themselves, not forced by us.
>>> >> FYI, this is my last reply to this thread.
>>> >>
>>> >> As Geert and I said, drivers which need io memory have to depend on
>>> >> HAS_IOMEM=y.
>>> >> If an arch does not have io memory these drivers cannot work and
>>> >> therefore we don't
>>> >> want them built.
>> >
> Hmm, if the modules select 'COMPILE_TEST', it is better to let asm-generic
> support this features (at least, not forbid it)
>
> So how about the diff below ? ;-)
>
> ---diff begin---
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index d5afe96..ede3775 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -303,13 +303,17 @@ static inline void *phys_to_virt(unsigned long address)
> /*
> * Change "struct page" to physical address.
> *
> - * This implementation is for the no-MMU case only... if you have an MMU
> - * you'll need to provide your own definitions.
> + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
> + * if you have an MMU and IOMEM, you'll need to provide your own definitions.
> */
> -#ifndef CONFIG_MMU
> +#if !defined(CONFIG_MMU) || \
> + (!defined(CONFIG_HAS_IOMEM) && defined(COMPILE_TEST))
Need use 'CONFIG_COMPILE_TEST' instead of 'COMPILE_TEST'.
> static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
> {
> +#if !defined(CONFIG_MMU)
> return (void __iomem*) (unsigned long)offset;
> +#else
> + return NULL;
> }
>
> #define __ioremap(offset, size, flags) ioremap(offset, size)
> @@ -325,7 +329,7 @@ static inline void __iomem *ioremap(phys_addr_t offset,
> unsigned long size)
> static inline void iounmap(void __iomem *addr)
> {
> }
> -#endif /* CONFIG_MMU */
> +#endif /* !MMU || (!HAS_IOMEM && COMPILE_TEST) */
>
> #ifdef CONFIG_HAS_IOPORT
> #ifndef CONFIG_GENERIC_IOMAP
>
> ---diff end-
>
>> > It is really the time for stopping discussion, and thank you all for
>> > spending your time resources on this discussion.
>> >
>> > Next, I will send related patch for it (also cc to you all).
>> >
>> >
>> > Thanks.
>> >
>
> -- Chen Gang
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi | 90 +++
arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi | 90 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
3 files changed, 182 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
new file mode 100644
index 000..c626c49
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi
@@ -0,0 +1,90 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * Copyright 2011-2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma2";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ cell-index = <4>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ cell-index = <5>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ cell-index = <6>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ cell-index = <7>;
+ interrupts = <79 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
new file mode 100644
index 000..980ea77
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi
@@ -0,0 +1,90 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x101000 ]
+ *
+ * Copyright 2011-2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modificatio
[PATCH 2/2] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/fsldma.c | 48 ++--
drivers/dma/fsldma.h |4 ++--
2 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 4fc2980..0f453ea 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1119,27 +1119,33 @@ static irqreturn_t fsldma_ctrl_irq(int irq, void *data)
struct fsldma_device *fdev = data;
struct fsldma_chan *chan;
unsigned int handled = 0;
- u32 gsr, mask;
+ u8 chan_sr[round_up(FSL_DMA_MAX_CHANS_PER_DEVICE, 4)];
+ u32 gsr;
int i;
- gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ? in_be32(fdev->regs)
- : in_le32(fdev->regs);
- mask = 0xff00;
- dev_dbg(fdev->dev, "IRQ: gsr 0x%.8x\n", gsr);
+ memset(&chan_sr, 0, sizeof(chan_sr));
+ gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ? in_be32(fdev->regs0)
+ : in_le32(fdev->regs0);
+ memcpy(&chan_sr[0], &gsr, 4);
+ dev_dbg(fdev->dev, "IRQ: gsr0 0x%.8x\n", gsr);
+
+ if (of_device_is_compatible(fdev->dev->of_node, "fsl,eloplus-dma2")) {
+ gsr = (fdev->feature & FSL_DMA_BIG_ENDIAN) ?
+ in_be32(fdev->regs1) : in_le32(fdev->regs1);
+ memcpy(&chan_sr[4], &gsr, 4);
+ dev_dbg(fdev->dev, "IRQ: gsr1 0x%.8x\n", gsr);
+ }
for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
chan = fdev->chan[i];
if (!chan)
continue;
- if (gsr & mask) {
+ if (chan_sr[i]) {
dev_dbg(fdev->dev, "IRQ: chan %d\n", chan->id);
fsldma_chan_irq(irq, chan);
handled++;
}
-
- gsr &= ~mask;
- mask >>= 8;
}
return IRQ_RETVAL(handled);
@@ -1261,7 +1267,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
- chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+ chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1341,13 +1349,22 @@ static int fsldma_of_probe(struct platform_device *op)
INIT_LIST_HEAD(&fdev->common.channels);
/* ioremap the registers for use */
- fdev->regs = of_iomap(op->dev.of_node, 0);
- if (!fdev->regs) {
- dev_err(&op->dev, "unable to ioremap registers\n");
+ fdev->regs0 = of_iomap(op->dev.of_node, 0);
+ if (!fdev->regs0) {
+ dev_err(&op->dev, "unable to ioremap register0\n");
err = -ENOMEM;
goto out_free_fdev;
}
+ if (of_device_is_compatible(op->dev.of_node, "fsl,eloplus-dma2")) {
+ fdev->regs1 = of_iomap(op->dev.of_node, 1);
+ if (!fdev->regs1) {
+ dev_err(&op->dev, "unable to ioremap register1\n");
+ err = -ENOMEM;
+ goto out_free_fdev;
+ }
+ }
+
/* map the channel IRQ if it exists, but don't hookup the handler yet */
fdev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
@@ -1427,7 +1444,9 @@ static int fsldma_of_remove(struct platform_device *op)
fsl_dma_chan_remove(fdev->chan[i]);
}
- iounmap(fdev->regs);
+ iounmap(fdev->regs0);
+ if (of_device_is_compatible(op->dev.of_node, "fsl,eloplus-dma2"))
+ iounmap(fdev->regs1);
dev_set_drvdata(&op->dev, NULL);
kfree(fdev);
@@ -1436,6 +1455,7 @@ static int fsldma_of_remove(struct platform_device *op)
static const struct of_device_id fsldma_of_ids[] = {
{ .compatible = "fsl,eloplus-dma", },
+ { .compatible = "fsl,eloplus-dma2", },
{ .compatible = "fsl,elo-dma", },
{}
};
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..880664d 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,10 +112,10 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
- void __iomem *regs; /* DGSR register base */
+ void __iomem *regs0, *regs1;/* DGSR registers */
struct device *dev;
struct dma_device common;
struct fsldma_chan *chan[FSL_DMA_MAX_CHANS_PER_DEVICE];
--
1.7
Re: kernel panic in skb_copy_bits
On 06/30/13 17:13, Alex Bligh wrote: > > > --On 28 June 2013 12:17:43 +0800 Joe Jin wrote: > >> Find a similar issue >> http://www.gossamer-threads.com/lists/xen/devel/265611 So copied to Xen >> developer as well. > > I thought this sounded familiar. I haven't got the start of this > thread, but what version of Xen are you running and what device > model? If before 4.3, there is a page lifetime bug in the kernel > (not the xen code) which can affect anything where the guest accesses > the host's block stack and that in turn accesses the networking > stack (it may in fact be wider than that). So, e.g. domU on > iCSSI will do it. It tends to get triggered by a TCP retransmit > or (on NFS) the RPC equivalent. Essentially block operation > is considered complete, returning through xen and freeing the > grant table entry, and yet something in the kernel (e.g. tcp > retransmit) can still access the data. The nature of the bug > is extensively discussed in that thread - you'll also find > a reference to a thread on linux-nfs which concludes it > isn't an nfs problem, and even some patches to fix it in the > kernel adding reference counting. Do you know if have a fix for above? so far we also suspected the grant page be unmapped earlier, we using 4.1 stable during our test. > > A workaround is to turn off O_DIRECT use by Xen as that ensures > the pages are copied. Xen 4.3 does this by default. > > I believe fixes for this are in 4.3 and 4.2.2 if using the > qemu upstream DM. Note these aren't real fixes, just a workaround > of a kernel bug. The guest is pvm, and disk model is xvbd, guest config file as below: vif = ['mac=00:21:f6:00:00:01,bridge=c0a80b00'] OVM_simple_name = 'Guest#1' disk = ['file:/OVS/Repositories/0004fb0391e9eae94d1e907c/VirtualDisks/0004fb12f78799dad800ef47.img,xvda,w', 'phy:/dev/mapper/360060e8010141870058b41570002,xvdb,w', 'phy:/dev/mapper/360060e8010141870058b41570003,xvdc,w'] bootargs = '' uuid = '0004fb00-0006--2b00-77a4766001ed' on_reboot = 'restart' cpu_weight = 27500 OVM_os_type = 'Oracle Linux 5' cpu_cap = 0 maxvcpus = 8 OVM_high_availability = False memory = 4096 OVM_description = '' on_poweroff = 'destroy' on_crash = 'restart' bootloader = '/usr/bin/pygrub' guest_os_type = 'linux' name = '0004fb062b0077a4766001ed' vfb = ['type=vnc,vncunused=1,vnclisten=127.0.0.1,keymap=en-us'] vcpus = 8 OVM_cpu_compat_group = '' OVM_domain_type = 'xen_pvm' > > To fix on a local build of xen you will need something like this: > https://github.com/abligh/qemu-upstream-4.2-testing/commit/9a97c011e1a682eed9bc7195a25349eaf23ff3f9 > and something like this (NB: obviously insert your own git > repo and commit numbers) > https://github.com/abligh/xen/commit/f5c344afac96ced8b980b9659fb3e81c4a0db5ca > I think this only for pvhvm/hvm? Thanks, Joe > Also note those fixes are (technically) unsafe for live migration > unless there is an ordering change made in qemu's block open > call. > > Of course this might be something completely different. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/7] autofs4 - coding style fixes
Try and make the coding style completely consistent throughtout the
autofs module and inline with kernel coding style recommendations.
Signed-off-by: Ian Kent
---
fs/autofs4/autofs_i.h | 30 +++---
fs/autofs4/expire.c | 38 +++---
fs/autofs4/init.c |5 +
fs/autofs4/inode.c |5 +
fs/autofs4/root.c | 22 +++---
fs/autofs4/symlink.c|5 +
fs/autofs4/waitq.c | 14 ++
include/linux/auto_fs.h |5 +
8 files changed, 55 insertions(+), 69 deletions(-)
diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 16d3288..76b8097 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -1,7 +1,4 @@
-/* -*- c -*- - *
- *
- * linux/fs/autofs/autofs_i.h
- *
+/*
* Copyright 1997-1998 Transmeta Corporation - All Rights Reserved
* Copyright 2005-2006 Ian Kent
*
@@ -51,12 +48,14 @@
printk(KERN_ERR "pid %d: %s: " fmt "\n",\
current->pid, __func__, ##__VA_ARGS__)
-/* Unified info structure. This is pointed to by both the dentry and
- inode structures. Each file in the filesystem has an instance of this
- structure. It holds a reference to the dentry, so dentries are never
- flushed while the file exists. All name lookups are dealt with at the
- dentry level, although the filesystem can interfere in the validation
- process. Readdir is implemented by traversing the dentry lists. */
+/*
+ * Unified info structure. This is pointed to by both the dentry and
+ * inode structures. Each file in the filesystem has an instance of this
+ * structure. It holds a reference to the dentry, so dentries are never
+ * flushed while the file exists. All name lookups are dealt with at the
+ * dentry level, although the filesystem can interfere in the validation
+ * process. Readdir is implemented by traversing the dentry lists.
+ */
struct autofs_info {
struct dentry *dentry;
struct inode*inode;
@@ -78,7 +77,7 @@ struct autofs_info {
kgid_t gid;
};
-#define AUTOFS_INF_EXPIRING(1<<0) /* dentry is in the process of expiring
*/
+#define AUTOFS_INF_EXPIRING(1<<0) /* dentry in the process of expiring */
#define AUTOFS_INF_PENDING (1<<2) /* dentry pending mount */
struct autofs_wait_queue {
@@ -138,7 +137,8 @@ static inline struct autofs_info *autofs4_dentry_ino(struct
dentry *dentry)
processes which do manipulations for us in user space sees the raw
filesystem without "magic".) */
-static inline int autofs4_oz_mode(struct autofs_sb_info *sbi) {
+static inline int autofs4_oz_mode(struct autofs_sb_info *sbi)
+{
return sbi->catatonic || task_pgrp(current) == sbi->oz_pgrp;
}
@@ -163,12 +163,12 @@ void autofs4_free_ino(struct autofs_info *);
int is_autofs4_dentry(struct dentry *);
int autofs4_expire_wait(struct dentry *dentry);
int autofs4_expire_run(struct super_block *, struct vfsmount *,
- struct autofs_sb_info *,
- struct autofs_packet_expire __user *);
+ struct autofs_sb_info *,
+ struct autofs_packet_expire __user *);
int autofs4_do_expire_multi(struct super_block *sb, struct vfsmount *mnt,
struct autofs_sb_info *sbi, int when);
int autofs4_expire_multi(struct super_block *, struct vfsmount *,
- struct autofs_sb_info *, int __user *);
+struct autofs_sb_info *, int __user *);
struct dentry *autofs4_expire_direct(struct super_block *sb,
struct vfsmount *mnt,
struct autofs_sb_info *sbi, int how);
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 13ddec9..ddee37a 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -1,7 +1,4 @@
-/* -*- c -*- --- *
- *
- * linux/fs/autofs/expire.c
- *
+/*
* Copyright 1997-1998 Transmeta Corporation -- All Rights Reserved
* Copyright 1999-2000 Jeremy Fitzhardinge
* Copyright 2001-2006 Ian Kent
@@ -18,7 +15,7 @@ static unsigned long now;
/* Check if a dentry can be expired */
static inline int autofs4_can_expire(struct dentry *dentry,
- unsigned long timeout, int do_now)
+unsigned long timeout, int do_now)
{
struct autofs_info *ino = autofs4_dentry_ino(dentry);
@@ -81,7 +78,7 @@ done:
* Calculate and dget next entry in the subdirs list under root.
*/
static struct dentry *get_next_positive_subdir(struct dentry *prev,
- struct dentry *root)
+ struct dentry *root)
{
struct autofs_sb_info *sbi = autofs4_sbi(root->d_sb);
struct list_head
[RFC PATCH 7/7] autofs - change CONFIG_AUTOFS4_FS to CONFIG_AUTOFS_FS
Signed-off-by: Ian Kent --- arch/arm/configs/at91rm9200_defconfig|2 +- arch/arm/configs/bcm_defconfig |2 +- arch/arm/configs/cns3420vb_defconfig |2 +- arch/arm/configs/colibri_pxa270_defconfig|2 +- arch/arm/configs/da8xx_omapl_defconfig |2 +- arch/arm/configs/davinci_all_defconfig |2 +- arch/arm/configs/ebsa110_defconfig |2 +- arch/arm/configs/ezx_defconfig |2 +- arch/arm/configs/footbridge_defconfig|2 +- arch/arm/configs/imote2_defconfig|2 +- arch/arm/configs/imx_v6_v7_defconfig |2 +- arch/arm/configs/lpc32xx_defconfig |2 +- arch/arm/configs/mini2440_defconfig |2 +- arch/arm/configs/omap1_defconfig |2 +- arch/arm/configs/rpc_defconfig |2 +- arch/arm/configs/s3c2410_defconfig |2 +- arch/arm/configs/spear13xx_defconfig |2 +- arch/arm/configs/spear3xx_defconfig |2 +- arch/arm/configs/spear6xx_defconfig |2 +- arch/arm/configs/trizeps4_defconfig |2 +- arch/ia64/configs/bigsur_defconfig |2 +- arch/ia64/configs/generic_defconfig |2 +- arch/ia64/configs/gensparse_defconfig|2 +- arch/ia64/configs/tiger_defconfig|2 +- arch/ia64/configs/xen_domu_defconfig |2 +- arch/m68k/configs/amiga_defconfig|2 +- arch/m68k/configs/apollo_defconfig |2 +- arch/m68k/configs/atari_defconfig|2 +- arch/m68k/configs/bvme6000_defconfig |2 +- arch/m68k/configs/hp300_defconfig|2 +- arch/m68k/configs/mac_defconfig |2 +- arch/m68k/configs/multi_defconfig|2 +- arch/m68k/configs/mvme147_defconfig |2 +- arch/m68k/configs/mvme16x_defconfig |2 +- arch/m68k/configs/q40_defconfig |2 +- arch/m68k/configs/sun3_defconfig |2 +- arch/m68k/configs/sun3x_defconfig|2 +- arch/mips/configs/bcm47xx_defconfig |2 +- arch/mips/configs/bigsur_defconfig |2 +- arch/mips/configs/capcella_defconfig |2 +- arch/mips/configs/e55_defconfig |2 +- arch/mips/configs/fuloong2e_defconfig|2 +- arch/mips/configs/ip22_defconfig |2 +- arch/mips/configs/ip32_defconfig |2 +- arch/mips/configs/jazz_defconfig |2 +- arch/mips/configs/lemote2f_defconfig |2 +- arch/mips/configs/markeins_defconfig |2 +- arch/mips/configs/mpc30x_defconfig |2 +- arch/mips/configs/mtx1_defconfig |2 +- arch/mips/configs/nlm_xlp_defconfig |2 +- arch/mips/configs/nlm_xlr_defconfig |2 +- arch/mips/configs/rm200_defconfig|2 +- arch/mips/configs/tb0219_defconfig |2 +- arch/mips/configs/tb0226_defconfig |2 +- arch/mips/configs/tb0287_defconfig |2 +- arch/mips/configs/workpad_defconfig |2 +- arch/parisc/configs/712_defconfig|2 +- arch/parisc/configs/a500_defconfig |2 +- arch/parisc/configs/b180_defconfig |2 +- arch/parisc/configs/c3000_defconfig |2 +- arch/powerpc/configs/40x/virtex_defconfig|2 +- arch/powerpc/configs/44x/sam440ep_defconfig |2 +- arch/powerpc/configs/44x/virtex5_defconfig |2 +- arch/powerpc/configs/85xx/stx_gp3_defconfig |2 +- arch/powerpc/configs/86xx/sbc8641d_defconfig |2 +- arch/powerpc/configs/c2k_defconfig |2 +- arch/powerpc/configs/cell_defconfig |2 +- arch/powerpc/configs/ep8248e_defconfig |2 +- arch/powerpc/configs/mgcoge_defconfig|2 +- arch/powerpc/configs/mpc8272_ads_defconfig |2 +- arch/powerpc/configs/pasemi_defconfig|2 +- arch/powerpc/configs/pmac32_defconfig|2 +- arch/powerpc/configs/ppc64_defconfig |2 +- arch/powerpc/configs/ppc64e_defconfig|2 +- arch/powerpc/configs/ppc6xx_defconfig|2 +- arch/powerpc/configs/pq2fads_defconfig |2 +- arch/powerpc/configs/ps3_defconfig |2 +- arch/powerpc/configs/pseries_defconfig |2 +- arch/score/configs/spct6600_defconfig|2 +- arch/sh/configs/espt_defconfig |2 +- arch/sh/configs/sdk7780_defconfig|2 +- arch/sh/configs/sdk7786_defconfig|2 +- arch/sh/configs/sh03_defconfig |2 +- arch/sh/configs/sh7763rdp_defconfig |2 +- arch/sparc/configs/sparc32_defconfig |2 +- arch/tile/configs/tilegx_defconfig |2 +- arch/tile/configs/tilepro_defconfig |2 +- arch/um/defconfig|2 +- arch/x86/configs/i386_defconfig
[RFC PATCH 3/7] autofs4 - move linux/auto_dev-ioctl.h to uapi/linux
Since linux/auto_dev-ioctl.h wasn't included in include/linux/Kbuild (although
I should have added it) it wasn't moved to uapi/linux as part of the uapi
series.
Signed-off-by: Ian Kent
---
include/linux/auto_dev-ioctl.h | 224 ---
include/uapi/linux/auto_dev-ioctl.h | 224 +++
2 files changed, 224 insertions(+), 224 deletions(-)
delete mode 100644 include/linux/auto_dev-ioctl.h
create mode 100644 include/uapi/linux/auto_dev-ioctl.h
diff --git a/include/linux/auto_dev-ioctl.h b/include/linux/auto_dev-ioctl.h
deleted file mode 100644
index fe4f373..000
--- a/include/linux/auto_dev-ioctl.h
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * Copyright 2008 Red Hat, Inc. All rights reserved.
- * Copyright 2008 Ian Kent
- *
- * This file is part of the Linux kernel and is made available under
- * the terms of the GNU General Public License, version 2, or at your
- * option, any later version, incorporated herein by reference.
- */
-
-#ifndef _LINUX_AUTO_DEV_IOCTL_H
-#define _LINUX_AUTO_DEV_IOCTL_H
-
-#include
-#include
-
-#define AUTOFS_DEVICE_NAME "autofs"
-
-#define AUTOFS_DEV_IOCTL_VERSION_MAJOR 1
-#define AUTOFS_DEV_IOCTL_VERSION_MINOR 0
-
-#define AUTOFS_DEVID_LEN 16
-
-#define AUTOFS_DEV_IOCTL_SIZE sizeof(struct autofs_dev_ioctl)
-
-/*
- * An ioctl interface for autofs mount point control.
- */
-
-struct args_protover {
- __u32 version;
-};
-
-struct args_protosubver {
- __u32 sub_version;
-};
-
-struct args_openmount {
- __u32 devid;
-};
-
-struct args_ready {
- __u32 token;
-};
-
-struct args_fail {
- __u32 token;
- __s32 status;
-};
-
-struct args_setpipefd {
- __s32 pipefd;
-};
-
-struct args_timeout {
- __u64 timeout;
-};
-
-struct args_requester {
- __u32 uid;
- __u32 gid;
-};
-
-struct args_expire {
- __u32 how;
-};
-
-struct args_askumount {
- __u32 may_umount;
-};
-
-struct args_ismountpoint {
- union {
- struct args_in {
- __u32 type;
- } in;
- struct args_out {
- __u32 devid;
- __u32 magic;
- } out;
- };
-};
-
-/*
- * All the ioctls use this structure.
- * When sending a path size must account for the total length
- * of the chunk of memory otherwise is is the size of the
- * structure.
- */
-
-struct autofs_dev_ioctl {
- __u32 ver_major;
- __u32 ver_minor;
- __u32 size; /* total size of data passed in
-* including this struct */
- __s32 ioctlfd; /* automount command fd */
-
- /* Command parameters */
-
- union {
- struct args_protoverprotover;
- struct args_protosubver protosubver;
- struct args_openmount openmount;
- struct args_ready ready;
- struct args_failfail;
- struct args_setpipefd setpipefd;
- struct args_timeout timeout;
- struct args_requester requester;
- struct args_expire expire;
- struct args_askumount askumount;
- struct args_ismountpointismountpoint;
- };
-
- char path[0];
-};
-
-static inline void init_autofs_dev_ioctl(struct autofs_dev_ioctl *in)
-{
- memset(in, 0, sizeof(struct autofs_dev_ioctl));
- in->ver_major = AUTOFS_DEV_IOCTL_VERSION_MAJOR;
- in->ver_minor = AUTOFS_DEV_IOCTL_VERSION_MINOR;
- in->size = sizeof(struct autofs_dev_ioctl);
- in->ioctlfd = -1;
- return;
-}
-
-/*
- * If you change this make sure you make the corresponding change
- * to autofs-dev-ioctl.c:lookup_ioctl()
- */
-enum {
- /* Get various version info */
- AUTOFS_DEV_IOCTL_VERSION_CMD = 0x71,
- AUTOFS_DEV_IOCTL_PROTOVER_CMD,
- AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD,
-
- /* Open mount ioctl fd */
- AUTOFS_DEV_IOCTL_OPENMOUNT_CMD,
-
- /* Close mount ioctl fd */
- AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD,
-
- /* Mount/expire status returns */
- AUTOFS_DEV_IOCTL_READY_CMD,
- AUTOFS_DEV_IOCTL_FAIL_CMD,
-
- /* Activate/deactivate autofs mount */
- AUTOFS_DEV_IOCTL_SETPIPEFD_CMD,
- AUTOFS_DEV_IOCTL_CATATONIC_CMD,
-
- /* Expiry timeout */
- AUTOFS_DEV_IOCTL_TIMEOUT_CMD,
-
- /* Get mount last requesting uid and gid */
- AUTOFS_DEV_IOCTL_REQUESTER_CMD,
-
- /* Check for eligible expire candidates */
- AUTOFS_DEV_IOCTL_EXPIRE_CMD,
-
- /* Request busy status */
- AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD,
-
- /* Check if path is a mountpoint */
- AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD,
-};
-
-#define AUTOFS_IOCTL 0x93
-
-#define AUTOFS_DEV_IOCTL_VERSION \
-
[RFC PATCH 2/7] autofs4 - fix string.h include in auto_dev-ioctl.h
Since including linux/string.h will now do the right thing remove the conditional check. Signed-off-by: Ian Kent --- include/linux/auto_dev-ioctl.h |5 - 1 file changed, 5 deletions(-) diff --git a/include/linux/auto_dev-ioctl.h b/include/linux/auto_dev-ioctl.h index 850f39b..fe4f373 100644 --- a/include/linux/auto_dev-ioctl.h +++ b/include/linux/auto_dev-ioctl.h @@ -11,12 +11,7 @@ #define _LINUX_AUTO_DEV_IOCTL_H #include - -#ifdef __KERNEL__ #include -#else -#include -#endif /* __KERNEL__ */ #define AUTOFS_DEVICE_NAME "autofs" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 4/7] autofs - merge auto_fs.h and auto_fs4.h
The autofs module has long since been removed so there's no need to have
two separate include files for autofs.
Signed-off-by: Ian Kent
---
fs/autofs4/autofs_i.h |2 -
fs/compat_ioctl.c |1
include/uapi/linux/auto_fs.h | 156 +---
include/uapi/linux/auto_fs4.h | 158 +
4 files changed, 149 insertions(+), 168 deletions(-)
diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 76b8097..1a79bc7 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -10,7 +10,7 @@
/* Internal header file for autofs */
-#include
+#include
#include
#include
#include
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 5d19acf..43345ce 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h
index bb991df..fe7518d 100644
--- a/include/uapi/linux/auto_fs.h
+++ b/include/uapi/linux/auto_fs.h
@@ -1,8 +1,7 @@
-/* -*- linux-c -*- --- *
- *
- * linux/include/linux/auto_fs.h
- *
- * Copyright 1997 Transmeta Corporation - All Rights Reserved
+/*
+ * Copyright 1997 Transmeta Corporation - All Rights Reserved
+ * Copyright 1999-2000 Jeremy Fitzhardinge
+ * Copyright 2005-2006,2013 Ian Kent
*
* This file is part of the Linux kernel and is made available under
* the terms of the GNU General Public License, version 2, or at your
@@ -10,7 +9,6 @@
*
* --- */
-
#ifndef _UAPI_LINUX_AUTO_FS_H
#define _UAPI_LINUX_AUTO_FS_H
@@ -19,13 +17,11 @@
#include
#endif /* __KERNEL__ */
+#define AUTOFS_PROTO_VERSION 5
+#define AUTOFS_MIN_PROTO_VERSION 3
+#define AUTOFS_MAX_PROTO_VERSION 5
-/* This file describes autofs v3 */
-#define AUTOFS_PROTO_VERSION 3
-
-/* Range of protocol versions defined */
-#define AUTOFS_MAX_PROTO_VERSION AUTOFS_PROTO_VERSION
-#define AUTOFS_MIN_PROTO_VERSION AUTOFS_PROTO_VERSION
+#define AUTOFS_PROTO_SUBVERSION2
/*
* The wait_queue_token (autofs_wqt_t) is part of a structure which is passed
@@ -71,4 +67,140 @@ struct autofs_packet_expire {
#define AUTOFS_IOC_SETTIMEOUT _IOWR(0x93,0x64,unsigned long)
#define AUTOFS_IOC_EXPIRE _IOR(0x93,0x65,struct autofs_packet_expire)
+/* autofs version 4 and later definitions */
+
+/* Mask for expire behaviour */
+#define AUTOFS_EXP_IMMEDIATE 1
+#define AUTOFS_EXP_LEAVES 2
+
+#define AUTOFS_TYPE_ANY0U
+#define AUTOFS_TYPE_INDIRECT 1U
+#define AUTOFS_TYPE_DIRECT 2U
+#define AUTOFS_TYPE_OFFSET 4U
+
+static inline void set_autofs_type_indirect(unsigned int *type)
+{
+ *type = AUTOFS_TYPE_INDIRECT;
+ return;
+}
+
+static inline unsigned int autofs_type_indirect(unsigned int type)
+{
+ return (type == AUTOFS_TYPE_INDIRECT);
+}
+
+static inline void set_autofs_type_direct(unsigned int *type)
+{
+ *type = AUTOFS_TYPE_DIRECT;
+ return;
+}
+
+static inline unsigned int autofs_type_direct(unsigned int type)
+{
+ return (type == AUTOFS_TYPE_DIRECT);
+}
+
+static inline void set_autofs_type_offset(unsigned int *type)
+{
+ *type = AUTOFS_TYPE_OFFSET;
+ return;
+}
+
+static inline unsigned int autofs_type_offset(unsigned int type)
+{
+ return (type == AUTOFS_TYPE_OFFSET);
+}
+
+static inline unsigned int autofs_type_trigger(unsigned int type)
+{
+ return (type == AUTOFS_TYPE_DIRECT || type == AUTOFS_TYPE_OFFSET);
+}
+
+/*
+ * This isn't really a type as we use it to say "no type set" to
+ * indicate we want to search for "any" mount in the
+ * autofs_dev_ioctl_ismountpoint() device ioctl function.
+ */
+static inline void set_autofs_type_any(unsigned int *type)
+{
+ *type = AUTOFS_TYPE_ANY;
+ return;
+}
+
+static inline unsigned int autofs_type_any(unsigned int type)
+{
+ return (type == AUTOFS_TYPE_ANY);
+}
+
+/* Daemon notification packet types */
+enum autofs_notify {
+ NFY_NONE,
+ NFY_MOUNT,
+ NFY_EXPIRE
+};
+
+/* Kernel protocol version 4 packet types */
+
+/* Expire entry (umount request) */
+#define autofs_ptype_expire_multi 2
+
+/* Kernel protocol version 5 packet types */
+
+/* Indirect mount missing and expire requests. */
+#define autofs_ptype_missing_indirect 3
+#define autofs_ptype_expire_indirect 4
+
+/* Direct mount missing and expire requests */
+#define autofs_ptype_missing_direct5
+#define autofs_ptype_expire_direct 6
+
+/* v4 multi expire (via pipe) */
+struct autofs_packet_expire_multi {
+ struct autofs_packet_hdr hdr;
+autofs_wqt_t wait_queue_token;
+ int len;
+ char name[NAME_MAX+1];
+};
+
+union autofs_packet_union {
+ struct autofs_packet_hdr hdr
[RFC PATCH 0/7] autofs4 - rename autofs4 to autofs
The autofs4 kernel module provides function for autofs version 3, 4 and 5 and autofs module has long since been removed. Now we're left with a misnamed module. Appart from the name another problem this presents is that module autoload doesn't work because of the mismatch of the directory name and the name of the file system provided by the module. So autofs4 should be renamed to autofs but I've held back doing it because of the potential disruption that could occur with a change like this. The issues are somewhat reduced now because systemd needs the autofs module at startup and because of the autoload issue it is easier to just compile the module into the kernel which is what is done in some cases. The big question for me is whether to leave a build stub in the autofs4 directory along with a warning in Kconfig that the stub will be removed after two kernel versions or just straight out rename it and be done with it. The series here leaves a stub but I'd like comments thoughts on whether to use the stub or just rename the module? --- Ian Kent (7): autofs4 - coding style fixes autofs4 - fix string.h include in auto_dev-ioctl.h autofs4 - move linux/auto_dev-ioctl.h to uapi/linux autofs - merge auto_fs.h and auto_fs4.h autofs - use autofs instead of autofs4 everywhere autofs - rename module autofs4 to autofs autofs - change CONFIG_AUTOFS4_FS to CONFIG_AUTOFS_FS MAINTAINERS |4 arch/arm/configs/at91rm9200_defconfig|2 arch/arm/configs/bcm_defconfig |2 arch/arm/configs/cns3420vb_defconfig |2 arch/arm/configs/colibri_pxa270_defconfig|2 arch/arm/configs/da8xx_omapl_defconfig |2 arch/arm/configs/davinci_all_defconfig |2 arch/arm/configs/ebsa110_defconfig |2 arch/arm/configs/ezx_defconfig |2 arch/arm/configs/footbridge_defconfig|2 arch/arm/configs/imote2_defconfig|2 arch/arm/configs/imx_v6_v7_defconfig |2 arch/arm/configs/lpc32xx_defconfig |2 arch/arm/configs/mini2440_defconfig |2 arch/arm/configs/omap1_defconfig |2 arch/arm/configs/rpc_defconfig |2 arch/arm/configs/s3c2410_defconfig |2 arch/arm/configs/spear13xx_defconfig |2 arch/arm/configs/spear3xx_defconfig |2 arch/arm/configs/spear6xx_defconfig |2 arch/arm/configs/trizeps4_defconfig |2 arch/ia64/configs/bigsur_defconfig |2 arch/ia64/configs/generic_defconfig |2 arch/ia64/configs/gensparse_defconfig|2 arch/ia64/configs/tiger_defconfig|2 arch/ia64/configs/xen_domu_defconfig |2 arch/m68k/configs/amiga_defconfig|2 arch/m68k/configs/apollo_defconfig |2 arch/m68k/configs/atari_defconfig|2 arch/m68k/configs/bvme6000_defconfig |2 arch/m68k/configs/hp300_defconfig|2 arch/m68k/configs/mac_defconfig |2 arch/m68k/configs/multi_defconfig|2 arch/m68k/configs/mvme147_defconfig |2 arch/m68k/configs/mvme16x_defconfig |2 arch/m68k/configs/q40_defconfig |2 arch/m68k/configs/sun3_defconfig |2 arch/m68k/configs/sun3x_defconfig|2 arch/mips/configs/bcm47xx_defconfig |2 arch/mips/configs/bigsur_defconfig |2 arch/mips/configs/capcella_defconfig |2 arch/mips/configs/e55_defconfig |2 arch/mips/configs/fuloong2e_defconfig|2 arch/mips/configs/ip22_defconfig |2 arch/mips/configs/ip32_defconfig |2 arch/mips/configs/jazz_defconfig |2 arch/mips/configs/lemote2f_defconfig |2 arch/mips/configs/markeins_defconfig |2 arch/mips/configs/mpc30x_defconfig |2 arch/mips/configs/mtx1_defconfig |2 arch/mips/configs/nlm_xlp_defconfig |2 arch/mips/configs/nlm_xlr_defconfig |2 arch/mips/configs/rm200_defconfig|2 arch/mips/configs/tb0219_defconfig |2 arch/mips/configs/tb0226_defconfig |2 arch/mips/configs/tb0287_defconfig |2 arch/mips/configs/workpad_defconfig |2 arch/parisc/configs/712_defconfig|2 arch/parisc/configs/a500_defconfig |2 arch/parisc/configs/b180_defconfig |2 arch/parisc/configs/c3000_defconfig |2 arch/powerpc/configs/40x/virtex_defconfig|2 arch/powerpc/configs/44x/sam440ep_defconfig |2 arch/powerpc/configs/44x/virtex5_defconfig |2 arch/powerpc/configs/85xx/stx_gp3_defconfig |2 arch/powerpc/configs/86xx/sbc8641d_defconfig |2 arc
Error creating sysfs files when reloading cx88 driver
Hello, I have a pcHDTV 3000 card [0], on a 3.10-rc6 kernel. Every so often, it stops working [1]. When I try to reload cx88_dvb, module loads, but init errors out because some sysfs file is already there [2]. Removing more of the video-related modules doesn't seem to help (at least not once this happens). Any ideas? It seems like this has been asked before [3] but no response. The files it fails to re-create are: [334698.061395] sysfs: cannot create duplicate filename '/devices/pci:00/:00:1e.0/:09:00.2/dvb/dvb0.frontend0' [334698.062420] sysfs: cannot create duplicate filename '/devices/pci:00/:00:1e.0/:09:00.2/dvb/dvb0.demux0' [334698.062881] sysfs: cannot create duplicate filename '/devices/pci:00/:00:1e.0/:09:00.2/dvb/dvb0.dvr0' And the other warnings are just fallout from that. After removing all of the video-related modules, that dvb directory is still there: # ls /sys/devices/pci:00/:00:1e.0/:09:00.2/dvb dvb0.demux0 dvb0.dvr0 dvb0.frontend0 # ls -l /sys/devices/pci:00/:00:1e.0/:09:00.2/dvb/dvb0.demux0 total 0 -r--r--r-- 1 root root 4096 Jun 30 23:03 dev lrwxrwxrwx 1 root root0 Jun 30 23:03 device -> ../../../:09:00.2 drwxr-xr-x 2 root root0 Jun 27 01:43 power lrwxrwxrwx 1 root root0 Jun 27 01:43 subsystem -> ../../../../../../class/dvb -rw-r--r-- 1 root root 4096 Jun 26 21:43 uevent Note that subsystem there is a broken link, /sys/class/dvb no longer exists since I've unloaded those modules. Let me know if there's anything I should try. I'm pretty sure I can reproduce this at will (just reloading the cx88_dvb module should do it, even if the card isn't wedged) but I haven't tried it. Thanks, -ilia [0] 09:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) 09:00.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) [1] http://pastebin.com/3JAnDUDX [2] http://pastebin.com/QEpajhaF [3] https://lkml.org/lkml/2013/2/6/274 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] percpu_counter: __this_cpu_write doesn't need to be protected by spinlock
__this_cpu_write doesn't need to be protected by spinlock, AS we are doing
per cpu write with preempt disabled. And another reason to remove
__this_cpu_write
outside of spinlock: __percpu_counter_sum is not a accurate counter.
Signed-off-by: Fan Du
---
lib/percpu_counter.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index ba6085d..1fc23a3 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -80,8 +80,8 @@ void __percpu_counter_add(struct percpu_counter *fbc, s64
amount, s32 batch)
if (count >= batch || count <= -batch) {
raw_spin_lock(&fbc->lock);
fbc->count += count;
- __this_cpu_write(*fbc->counters, 0);
raw_spin_unlock(&fbc->lock);
+ __this_cpu_write(*fbc->counters, 0);
} else {
__this_cpu_write(*fbc->counters, count);
}
--
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] arch: m68k: include: asm: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not.
Hello Maintainers: Please help check the patch whether OK or not, when you have time. Thanks. On 06/22/2013 02:49 PM, Chen Gang wrote: > > Define 'VM_DATA_DEFAULT_FLAGS' when 'NOMMU' to pass compiling. > > So move it from "include/asm/page_mm.h to "include/asm/page.h" > > The related make: > > make ARCH=m68k randconfig > make ARCH=m68k menuconfig > choose cross compiler > disable MMU support > make ARCH=m68k V=1 EXTRA_CFLAGS=-W > > The related error: > > security/selinux/hooks.c: In function ‘selinux_init’: > security/selinux/hooks.c:5821:21: error: ‘VM_DATA_DEFAULT_FLAGS’ undeclared > (first use in this function) > > (the attachment is the related .config file) > > > Signed-off-by: Chen Gang > --- > arch/m68k/include/asm/page.h|3 +++ > arch/m68k/include/asm/page_mm.h |3 --- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/m68k/include/asm/page.h b/arch/m68k/include/asm/page.h > index 7c360da..38b024a 100644 > --- a/arch/m68k/include/asm/page.h > +++ b/arch/m68k/include/asm/page.h > @@ -48,6 +48,9 @@ extern unsigned long _ramend; > #include > #endif > > +#define VM_DATA_DEFAULT_FLAGS(VM_READ | VM_WRITE | VM_EXEC | \ > + VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) > + > #include > > #endif /* _M68K_PAGE_H */ > diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h > index 89f2014..5029f73 100644 > --- a/arch/m68k/include/asm/page_mm.h > +++ b/arch/m68k/include/asm/page_mm.h > @@ -173,7 +173,4 @@ static inline __attribute_const__ int > __virt_to_node_shift(void) > > #endif /* __ASSEMBLY__ */ > > -#define VM_DATA_DEFAULT_FLAGS(VM_READ | VM_WRITE | VM_EXEC | \ > - VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) > - > #endif /* _M68K_PAGE_MM_H */ > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] Add FAT_IOCTL_GET_VOLUME_ID
From: Mike Lockwood
This patch, originally from Android kernel, adds vfat directory ioctl command
FAT_IOCTL_GET_VOLUME_ID, with this command we can get the vfat volume ID using
following code:
ioctl(dirfd(dir), FAT_IOCTL_GET_VOLUME_ID, &volume_ID)
This patch is a modified version of the patch by Mike Lockwood, with changes
from Dmitry Pervushin, who noticed the original patch makes some volume IDs
abiguous with error returns: for example, if volume id is 0xFDAD, that
matches -ENOIOCTLCMD, we get "" from the user space.
So add a parameter to ioctl to get the correct volume ID.
Cc: dmitry pervushin
Cc: Mike Lockwood
Cc: Colin Cross
Cc: Android Kernel Team
Cc: OGAWA Hirofumi
Cc: Andrew Morton
Cc: John Stultz
Signed-off-by: Bintian Wang
---
fs/fat/dir.c | 14 ++
fs/fat/fat.h |1 +
fs/fat/inode.c|9 +
include/uapi/linux/msdos_fs.h | 13 +
4 files changed, 37 insertions(+)
diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index 7a6f02c..4c59108 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
@@ -776,12 +776,19 @@ static int fat_ioctl_readdir(struct inode *inode, struct
file *filp,
return ret;
}
+static unsigned int fat_ioctl_volume_id(struct inode *inode)
+{
+ struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
+ return sbi->vol_id;
+}
+
static long fat_dir_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
struct inode *inode = file_inode(filp);
struct __fat_dirent __user *d1 = (struct __fat_dirent __user *)arg;
int short_only, both;
+ unsigned int id;
switch (cmd) {
case VFAT_IOCTL_READDIR_SHORT:
@@ -792,6 +799,9 @@ static long fat_dir_ioctl(struct file *filp, unsigned int
cmd,
short_only = 0;
both = 1;
break;
+ case FAT_IOCTL_GET_VOLUME_ID:
+ id = fat_ioctl_volume_id(inode);
+ return copy_to_user((unsigned int *)arg, &id, sizeof(id));
default:
return fat_generic_ioctl(filp, cmd, arg);
}
@@ -822,6 +832,7 @@ static long fat_compat_dir_ioctl(struct file *filp,
unsigned cmd,
struct inode *inode = file_inode(filp);
struct compat_dirent __user *d1 = compat_ptr(arg);
int short_only, both;
+ unsigned int id;
switch (cmd) {
case VFAT_IOCTL_READDIR_SHORT32:
@@ -832,6 +843,9 @@ static long fat_compat_dir_ioctl(struct file *filp,
unsigned cmd,
short_only = 0;
both = 1;
break;
+ case FAT_IOCTL_GET_VOLUME_ID:
+ id = fat_ioctl_volume_id(inode);
+ return copy_to_user((unsigned int *)arg, &id, sizeof(id));
default:
return fat_generic_ioctl(filp, cmd, (unsigned long)arg);
}
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 21664fc..4241e6f 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -86,6 +86,7 @@ struct msdos_sb_info {
const void *dir_ops; /* Opaque; default directory operations */
int dir_per_block;/* dir entries per block */
int dir_per_block_bits; /* log2(dir_per_block) */
+ unsigned int vol_id;/*volume ID*/
int fatent_shift;
struct fatent_operations *fatent_ops;
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 5d4513c..a14dd4c 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1252,6 +1252,7 @@ int fat_fill_super(struct super_block *sb, void *data,
int silent, int isvfat,
struct inode *fsinfo_inode = NULL;
struct buffer_head *bh;
struct fat_boot_sector *b;
+ struct fat_boot_bsx *bsx;
struct msdos_sb_info *sbi;
u16 logical_sector_size;
u32 total_sectors, total_clusters, fat_clusters, rootdir_sectors;
@@ -1398,6 +1399,8 @@ int fat_fill_super(struct super_block *sb, void *data,
int silent, int isvfat,
goto out_fail;
}
+ bsx = (struct fat_boot_bsx *)(bh->b_data + FAT32_BSX_OFFSET);
+
fsinfo = (struct fat_boot_fsinfo *)fsinfo_bh->b_data;
if (!IS_FSINFO(fsinfo)) {
fat_msg(sb, KERN_WARNING, "Invalid FSINFO signature: "
@@ -1413,8 +1416,14 @@ int fat_fill_super(struct super_block *sb, void *data,
int silent, int isvfat,
}
brelse(fsinfo_bh);
+ } else {
+ bsx = (struct fat_boot_bsx *)(bh->b_data + FAT16_BSX_OFFSET);
}
+ /* interpret volume ID as a little endian 32 bit integer */
+ sbi->vol_id = (((u32)bsx->vol_id[0]) | ((u32)bsx->vol_id[1] << 8) |
+ ((u32)bsx->vol_id[2] << 16) | ((u32)bsx->vol_id[3] << 24));
+
sbi->dir_per_block = sb->s_blocksize / sizeof(struct msdos_dir_entry);
sbi->dir_per_block_bits = ffs(sbi->dir_per_block) - 1;
diff --git a/include/uapi/linux/msdo
Re: [PATCH] arch: m68k: include: asm: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not.
On 06/29/2013 04:26 PM, Geert Uytterhoeven wrote: > On Sat, Jun 29, 2013 at 10:01 AM, Michael Schmitz > wrote: >>> >> The same .config file, also report the compiling error below: >>> >> >>> >> drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of >>> >> function ‘iowrite8’ [-Werror=implicit-function-declaration] >>> >> drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of >>> >> function ‘iowrite16’ [-Werror=implicit-function-declaration] >>> >> drivers/i2c/busses/i2c-ocores.c:91:2: error: implicit declaration of >>> >> function ‘iowrite32’ [-Werror=implicit-function-declaration] >>> >> drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of >>> >> function ‘ioread8’ [-Werror=implicit-function-declaration] >>> >> drivers/i2c/busses/i2c-ocores.c:101:2: error: implicit declaration of >>> >> function ‘ioread16’ [-Werror=implicit-function-declaration] >>> >> drivers/i2c/busses/i2c-ocores.c:106:2: error: implicit declaration of >>> >> function ‘ioread32’ [-Werror=implicit-function-declaration] >>> >> >>> >> Excuse me, I am not quite familiar with the related hardware and m68k, >>> >> I guess under m68k architecture, we need not this drivers, is it correct >>> >> ? > Until someone synthesizes the OpenCores i2c core together with the > OpenCores 68000 core (they seem to have one), and tries to run uClinux > on it... > OK, thanks. >> > That would be correct, yes. Perhaps add appropriate dependencies in >> > drivers/i2c/Kconfig to allow building I2C drivers >> > only on hardware that supports it? > We still want it for compile-coverage. > > Now, the issue is that m68knommu doesn't implement ioread8() and > friends, so I'm adding the uClinux list. Do you also add it to main tree (e.g next-tree), if not, I recommend to do add it to main tree. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] arch: tile: include: asm: add cmpxchg64() definition
Need add cmpxchg64(), or will cause compiling issue.
Need define it as cmpxchg() only for 64-bit operation, since cmpxchg()
can support 8 bytes.
The related error (with allmodconfig):
drivers/block/blockconsole.c: In function ‘bcon_advance_console_bytes’:
drivers/block/blockconsole.c:164:2: error: implicit declaration of function
‘cmpxchg64’ [-Werror=implicit-function-declaration]
Signed-off-by: Chen Gang
---
arch/tile/include/asm/cmpxchg.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/tile/include/asm/cmpxchg.h b/arch/tile/include/asm/cmpxchg.h
index 276f067..1da5bfb 100644
--- a/arch/tile/include/asm/cmpxchg.h
+++ b/arch/tile/include/asm/cmpxchg.h
@@ -68,6 +68,12 @@ extern unsigned long __cmpxchg_called_with_bad_pointer(void);
#define tas(ptr) (xchg((ptr), 1))
+#define cmpxchg64(ptr, o, n) \
+({ \
+ BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
+ cmpxchg((ptr), (o), (n)); \
+})
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_TILE_CMPXCHG_H */
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] regulator: 88pm800: Add missing config.of_node setting for regulator register
> -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Friday, June 28, 2013 9:50 PM > To: Axel Lin > Cc: Yi Zhang; Chao Xie; Liam Girdwood; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/2] regulator: 88pm800: Add missing config.of_node > setting for regulator register > > On Fri, Jun 28, 2013 at 09:32:34PM +0800, Axel Lin wrote: >> Signed-off-by: Axel Lin >> --- >> Hi, >> Seems current code also needs this patch: >> mfd: 88pm800: add regulator sub device [1] > > Oh dear. I've just reverted the patch (my build testing hadn't caught up > yet). Chao, please resubmit for v3.12 - when you submit patches you need to > either ensure it applies and builds on the relevant branch or mention the > dependencies so that the build doesn't break. In this case sending the > regulator driver and matching MFD changes as a single patch series would have > been the normal thing. > > Please incorporate Axel's feedback into any resubmission. It is my mistake. I should add "regulator_data" and "num_regulator" with regulator driver. I have seen that mfd: 88pm800: add regulator sub device is already merged into Linux-next. So you mean that I need wait for 3.11 to release, then resubmit the regulator patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: tile: include: asm: add cmpxchg64() definition
Firstly thank you very much for replying quickly with details.
On 06/28/2013 11:09 PM, Ralf Baechle wrote:
> On Fri, Jun 28, 2013 at 09:51:35AM +0800, Chen Gang wrote:
>
>> Need add cmpxchg64(), or will cause compiling issue.
>>
>> Just define it as cmpxchg(), since cmpxchg() can support 8 bytes.
>>
>> The related error (with allmodconfig):
>>
>> drivers/block/blockconsole.c: In function ‘bcon_advance_console_bytes’:
>> drivers/block/blockconsole.c:164:2: error: implicit declaration of
>> function ‘cmpxchg64’ [-Werror=implicit-function-declaration]
>>
>> Signed-off-by: Chen Gang
>> ---
>> arch/tile/include/asm/cmpxchg.h |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/tile/include/asm/cmpxchg.h
>> b/arch/tile/include/asm/cmpxchg.h
>> index 276f067..7688c28 100644
>> --- a/arch/tile/include/asm/cmpxchg.h
>> +++ b/arch/tile/include/asm/cmpxchg.h
>> @@ -68,6 +68,8 @@ extern unsigned long
>> __cmpxchg_called_with_bad_pointer(void);
>>
>> #define tas(ptr) (xchg((ptr), 1))
>>
>> +#define cmpxchg64(ptr, o, n)cmpxchg((ptr), (o), (n))
>
> that's broken. cmpxchg64 is suposed to work on 64 bit operands ONLY. This
> definition (used by MIPS and Alpha) will work properly:
>
Oh, really it is. thanks.
> #define cmpxchg64(ptr, o, n)\
> ({ \
> BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
> cmpxchg((ptr), (o), (n)); \
> })
>
I should follow it to send patch v2, thanks.
> This should cure blockconsole on Tile but not on MIPS.
>
> struct blockconsole {
> ..
>u64 console_bytes;
> ..
> };
>
> static void bcon_advance_console_bytes(struct blockconsole *bc, int bytes)
> {
> u64 old, new;
> ...
> } while (cmpxchg64(&bc->console_bytes, old, new) != old);
> }
>
> So it's using cmpxchg64() to operate on 64 bit objects - but that's not
> going to work on every architecture. Many 32 bit architectures only
> provide atomic operations that operate on 32 bit quantities.
>
I guess your meaning is:
cmpxchg64() should be an atomic operation.
but on some of 32-bit architectures, they don't implement it as atomic
(no lock protected, at least).
it may cause issue on these 32-bit architectures.
Is it correct ?
If it is correct, I should continue to try to fix it.
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-pci: fix leaks of msix_affinity_masks
Jason Wang writes: > On 06/20/2013 01:36 PM, Andrey Vagin wrote: >> From: Andrew Vagin >> >> vp_dev->msix_vectors should be initialized before allocating >> msix_affinity_masks, otherwise vp_free_vectors will not free these >> objects. >> >> unreferenced object 0x88010f969d88 (size 512): >> comm "systemd-udevd", pid 158, jiffies 4294673645 (age 80.545s) >> hex dump (first 32 bytes): >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> backtrace: >> [] kmemleak_alloc+0x5e/0xc0 >> [] kmem_cache_alloc_node_trace+0x141/0x2c0 >> [] alloc_cpumask_var_node+0x23/0x80 >> [] alloc_cpumask_var+0xe/0x10 >> [] vp_try_to_find_vqs+0x25d/0x810 >> [] vp_find_vqs+0x81/0xb0 >> [] init_vqs+0x85/0x120 [virtio_balloon] >> [] virtballoon_probe+0xf9/0x1a0 [virtio_balloon] >> [] virtio_dev_probe+0xde/0x140 >> [] driver_probe_device+0x98/0x3a0 >> [] __driver_attach+0xab/0xb0 >> [] bus_for_each_dev+0x94/0xb0 >> [] driver_attach+0x1e/0x20 >> [] bus_add_driver+0x200/0x280 >> [] driver_register+0x74/0x160 >> [] register_virtio_driver+0x20/0x40 >> >> v2: change msix_vectors uncoditionaly in vp_free_vectors >> >> Cc: Rusty Russell >> Cc: "Michael S. Tsirkin" >> Cc: Jason Wang >> Signed-off-by: Andrew Vagin >> Signed-off-by: Andrey Vagin >> --- >> drivers/virtio/virtio_pci.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) Thanks, applied. Cheers, Rusty. >> >> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c >> index a7ce730..1aba255 100644 >> --- a/drivers/virtio/virtio_pci.c >> +++ b/drivers/virtio/virtio_pci.c >> @@ -289,9 +289,9 @@ static void vp_free_vectors(struct virtio_device *vdev) >> >> pci_disable_msix(vp_dev->pci_dev); >> vp_dev->msix_enabled = 0; >> -vp_dev->msix_vectors = 0; >> } >> >> +vp_dev->msix_vectors = 0; >> vp_dev->msix_used_vectors = 0; >> kfree(vp_dev->msix_names); >> vp_dev->msix_names = NULL; >> @@ -309,6 +309,8 @@ static int vp_request_msix_vectors(struct virtio_device >> *vdev, int nvectors, >> unsigned i, v; >> int err = -ENOMEM; >> >> +vp_dev->msix_vectors = nvectors; >> + >> vp_dev->msix_entries = kmalloc(nvectors * sizeof *vp_dev->msix_entries, >> GFP_KERNEL); >> if (!vp_dev->msix_entries) >> @@ -336,7 +338,6 @@ static int vp_request_msix_vectors(struct virtio_device >> *vdev, int nvectors, >> err = -ENOSPC; >> if (err) >> goto error; >> -vp_dev->msix_vectors = nvectors; >> vp_dev->msix_enabled = 1; >> >> /* Set the vector used for configuration */ > Acked-by: Jason Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL] (xen) stable/for-linus-3.11-rc0-tag
Hi Konrad, On Sun, 30 Jun 2013 21:03:21 -0400 Konrad Rzeszutek Wilk wrote: > > Since the merge window opened merely three hours ago and I am sure > you are addictively refreshing your email for the next set of > GIT PULLs and can't wait for them - I figured I would offer you a > nice little evening GIT-PULL snack to sustain you until Monday > GIT-PULL-email-avalanche :-) > > With that in mind please git pull the following tag: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-linus-3.11-rc0-tag Not sure why you did a back merge of Linus' tree right at the end there? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpTobZqd5w8l.pgp Description: PGP signature
Re: [PATCH v3 0/2] perf tools: Power7 events name available for perf
On Fri, Jun 28, 2013 at 04:14:55PM +0800, Runzhen Wang wrote: > Thank for Sukadev Bhattip and Xiao Guangrong's help. > Thank for Michael Ellerman's review. > > ChangeLog: v2 -> v3: > > 1. Adding a leading zero to all the events code in "power7-events-list.h" >which don't have a PMC, so that they all line up vertically. Hi Runzhen, These look good to me. Thanks for reworking them. They seem to be on top of Arnaldo's tree, so it's probably easiest if he takes them. You can have my: Acked-by: Michael Ellerman Arnaldo if you also want Benh's ack let us know and I'll pester him. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] regulator: 88pm800: add regulator driver for 88pm800
On Fri, Jun 28, 2013 at 7:56 PM, Mark Brown wrote: > On Thu, Jun 27, 2013 at 04:46:04AM -0400, Chao Xie wrote: >> Add the regulator driver for PMIC 88pm800 including device tree >> support. >> 88pm800 is an I2C-based power-management IC containing voltage >> regulators, a real-time clock, and some general purpose ADC devices, > > Applied, thanks. Your table based list and map voltage functions > actually look very generic so should be added to the core but I'll do > that myself as a refactoring so this can go into v3.11. 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] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'
On 06/26/2013 06:22 PM, Chen Gang wrote:
> On 06/26/2013 06:17 PM, Richard Weinberger wrote:
>> Am 26.06.2013 12:01, schrieb Chen Gang:
On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger
>> wrote:
>> Since the API itself already contents the meaning: "return NULL
>> means
>> the arch has no related io memory",
>> No, NULL means it could not map the I/O memory.
>>
"it could not map the I/O memory" includes "has no related io memory".
So it is enough for our case.
>> Why not define a generic dummy one in "include/asm-generic/io.h"
>> instead
>> of "HAS_IOMEM" (which has already spread many various places,
>> and also,
>> most of new drivers have to know about it).
>>
>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n",
>> define a
>> dummy ioremap() which return NULL ... (also need consider more
>> details).
>>
>> Because we don't even want to build these drivers and not make them
>> fail while
>> executing io memory related functions.
>> Indeed, it doesn't make sense to build drivers that cannot work.
>> And they may fail in a very bad way.
That is our 'platform' guys feeling, not the 'module' guys, as
'platform' guys, it is better to provide the choice to 'module' guys,
and let them decide by themselves, not forced by us.
>> FYI, this is my last reply to this thread.
>>
>> As Geert and I said, drivers which need io memory have to depend on
>> HAS_IOMEM=y.
>> If an arch does not have io memory these drivers cannot work and therefore
>> we don't
>> want them built.
>
Hmm, if the modules select 'COMPILE_TEST', it is better to let asm-generic
support this features (at least, not forbid it)
So how about the diff below ? ;-)
---diff begin---
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index d5afe96..ede3775 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -303,13 +303,17 @@ static inline void *phys_to_virt(unsigned long address)
/*
* Change "struct page" to physical address.
*
- * This implementation is for the no-MMU case only... if you have an MMU
- * you'll need to provide your own definitions.
+ * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
+ * if you have an MMU and IOMEM, you'll need to provide your own definitions.
*/
-#ifndef CONFIG_MMU
+#if !defined(CONFIG_MMU) || \
+ (!defined(CONFIG_HAS_IOMEM) && defined(COMPILE_TEST))
static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
{
+#if !defined(CONFIG_MMU)
return (void __iomem*) (unsigned long)offset;
+#else
+ return NULL;
}
#define __ioremap(offset, size, flags) ioremap(offset, size)
@@ -325,7 +329,7 @@ static inline void __iomem *ioremap(phys_addr_t offset,
unsigned long size)
static inline void iounmap(void __iomem *addr)
{
}
-#endif /* CONFIG_MMU */
+#endif /* !MMU || (!HAS_IOMEM && COMPILE_TEST) */
#ifdef CONFIG_HAS_IOPORT
#ifndef CONFIG_GENERIC_IOMAP
---diff end-
> It is really the time for stopping discussion, and thank you all for
> spending your time resources on this discussion.
>
> Next, I will send related patch for it (also cc to you all).
>
>
> Thanks.
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Support for 2013 Macbook Air
On Sun, Jun 30, 2013 at 09:04:44PM +0200, rydb...@euromail.se wrote: > Hi Dmitry, Jiri, > > Please find enclosed two patches yielding support for the > MacbookAir6,2. As usual, there is one HID and one Input patch. Given > the closeness to the merge window, I suppose we could backport this to > 3.10, unless Linus decides to wait another week. Backports should be > fine back to v3.7, inclusive. Dmitry, would you care to take the > patches, if Jiri is ok with that? Sure, I can take it in if Jiri is OK with it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
On Sun, Jun 30, 2013 at 08:33:49PM +0200, Michal Hocko wrote: > On Sat 29-06-13 12:55:09, Dave Chinner wrote: > > On Thu, Jun 27, 2013 at 04:54:11PM +0200, Michal Hocko wrote: > > > On Thu 27-06-13 09:24:26, Dave Chinner wrote: > > > > On Wed, Jun 26, 2013 at 10:15:09AM +0200, Michal Hocko wrote: > > > > > On Tue 25-06-13 12:27:54, Dave Chinner wrote: > > > > > > On Tue, Jun 18, 2013 at 03:50:25PM +0200, Michal Hocko wrote: > > > > > > > And again, another hang. It looks like the inode deletion never > > > > > > > finishes. The good thing is that I do not see any LRU related > > > > > > > BUG_ONs > > > > > > > anymore. I am going to test with the other patch in the thread. > > > > > > > > > > > > > > 2476 [] __wait_on_freeing_inode+0x9e/0xc0 > > > > > > > <<< waiting for an inode to go away > > > > > > > [] find_inode_fast+0xa1/0xc0 > > > > > > > [] iget_locked+0x4f/0x180 > > > > > > > [] ext4_iget+0x33/0x9f0 > > > > > > > [] ext4_lookup+0xbc/0x160 > > > > > > > [] lookup_real+0x20/0x60 > > > > > > > [] lookup_open+0x175/0x1d0 > > > > > > > [] do_last+0x2de/0x780 <<< > > > > > > > holds i_mutex > > > > > > > [] path_openat+0xda/0x400 > > > > > > > [] do_filp_open+0x43/0xa0 > > > > > > > [] do_sys_open+0x160/0x1e0 > > > > > > > [] sys_open+0x1c/0x20 > > > > > > > [] system_call_fastpath+0x16/0x1b > > > > > > > [] 0x . > Do you mean sysrq+t? It is attached. > > Btw. I was able to reproduce this again. The stuck processes were > sitting in the same traces for more than 28 hours without any change so > I do not think this is a temporal condition. > > Traces of all processes in the D state: > 7561 [] xfs_iget+0xbe/0x190 [xfs] > [] xfs_lookup+0xe8/0x110 [xfs] > [] xfs_vn_lookup+0x49/0x90 [xfs] > [] lookup_real+0x20/0x60 > [] lookup_open+0x175/0x1d0 > [] do_last+0x2de/0x780 > [] path_openat+0xda/0x400 > [] do_filp_open+0x43/0xa0 > [] do_sys_open+0x160/0x1e0 > [] sys_open+0x1c/0x20 > [] system_call_fastpath+0x16/0x1b > [] 0x This looks like it may be equivalent to the ext4 trace above, though I'm not totally sure on that yet. Can you get me the line of code where the above code is sleeping - 'gdb> l *(xfs_iget+0xbe)' output is sufficient. If it's where I suspect it is, we are hitting a VFS inode that igrab() is failing on because I_FREEING is set and that is returning EAGAIN. Hence xfs_iget() sleeps for a short period and retries the lookup. If you've still got a system in this state, can you dump the xfs stats a few times about 5s apart i.e. $ for i in `seq 0 1 5`; do echo ; date; cat /proc/fs/xfs/stat ; sleep 5 ; done Depending on what stat is changing (i'm looking for skip vs recycle in the inode cache stats), that will tell us why the lookup is failing... 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 11/12] cdrom: Remove unnecessary prototype for cdrom_mrw_exit
Move the function to appropriate locations instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 238 +-
1 file changed, 121 insertions(+), 117 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 87a74d4..a7dd384 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,8 +338,6 @@ do {
\
/* Not-exported routines. */
-static int cdrom_mrw_exit(struct cdrom_device_info *cdi);
-
static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di);
static void cdrom_sysctl_register(void);
@@ -359,113 +357,29 @@ static int cdrom_dummy_generic_packet(struct
cdrom_device_info *cdi,
return -EIO;
}
-/* This macro makes sure we don't have to check on cdrom_device_ops
- * existence in the run-time routines below. Change_capability is a
- * hack to have the capability flags defined const, while we can still
- * change it here without gcc complaining at every line.
- */
-#define ENSURE(call, bits) if (cdo->call == NULL) *change_capability &= ~(bits)
-
-int register_cdrom(struct cdrom_device_info *cdi)
-{
- static char banner_printed;
-struct cdrom_device_ops *cdo = cdi->ops;
-int *change_capability = (int *)&cdo->capability; /* hack */
-
- cd_dbg(CD_OPEN, "entering register_cdrom\n");
-
- if (cdo->open == NULL || cdo->release == NULL)
- return -EINVAL;
- if (!banner_printed) {
- pr_info("Uniform CD-ROM driver " REVISION "\n");
- banner_printed = 1;
- cdrom_sysctl_register();
- }
-
- ENSURE(drive_status, CDC_DRIVE_STATUS );
- if (cdo->check_events == NULL && cdo->media_changed == NULL)
- *change_capability = ~(CDC_MEDIA_CHANGED | CDC_SELECT_DISC);
- ENSURE(tray_move, CDC_CLOSE_TRAY | CDC_OPEN_TRAY);
- ENSURE(lock_door, CDC_LOCK);
- ENSURE(select_speed, CDC_SELECT_SPEED);
- ENSURE(get_last_session, CDC_MULTI_SESSION);
- ENSURE(get_mcn, CDC_MCN);
- ENSURE(reset, CDC_RESET);
- ENSURE(generic_packet, CDC_GENERIC_PACKET);
- cdi->mc_flags = 0;
- cdo->n_minors = 0;
-cdi->options = CDO_USE_FFLAGS;
-
- if (autoclose==1 && CDROM_CAN(CDC_CLOSE_TRAY))
- cdi->options |= (int) CDO_AUTO_CLOSE;
- if (autoeject==1 && CDROM_CAN(CDC_OPEN_TRAY))
- cdi->options |= (int) CDO_AUTO_EJECT;
- if (lockdoor==1)
- cdi->options |= (int) CDO_LOCK;
- if (check_media_type==1)
- cdi->options |= (int) CDO_CHECK_TYPE;
-
- if (CDROM_CAN(CDC_MRW_W))
- cdi->exit = cdrom_mrw_exit;
-
- if (cdi->disk)
- cdi->cdda_method = CDDA_BPC_FULL;
- else
- cdi->cdda_method = CDDA_OLD;
-
- if (!cdo->generic_packet)
- cdo->generic_packet = cdrom_dummy_generic_packet;
-
- cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
- mutex_lock(&cdrom_mutex);
- list_add(&cdi->list, &cdrom_list);
- mutex_unlock(&cdrom_mutex);
- return 0;
-}
-#undef ENSURE
-
-void unregister_cdrom(struct cdrom_device_info *cdi)
-{
- cd_dbg(CD_OPEN, "entering unregister_cdrom\n");
-
- mutex_lock(&cdrom_mutex);
- list_del(&cdi->list);
- mutex_unlock(&cdrom_mutex);
-
- if (cdi->exit)
- cdi->exit(cdi);
-
- cdi->ops->n_minors--;
- cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
-}
-
-int cdrom_get_media_event(struct cdrom_device_info *cdi,
- struct media_event_desc *med)
+static int cdrom_flush_cache(struct cdrom_device_info *cdi)
{
struct packet_command cgc;
- unsigned char buffer[8];
- struct event_header *eh = (struct event_header *) buffer;
-
- init_cdrom_command(&cgc, buffer, sizeof(buffer), CGC_DATA_READ);
- cgc.cmd[0] = GPCMD_GET_EVENT_STATUS_NOTIFICATION;
- cgc.cmd[1] = 1; /* IMMED */
- cgc.cmd[4] = 1 << 4;/* media event */
- cgc.cmd[8] = sizeof(buffer);
- cgc.quiet = 1;
-
- if (cdi->ops->generic_packet(cdi, &cgc))
- return 1;
- if (be16_to_cpu(eh->data_len) < sizeof(*med))
- return 1;
+ init_cdrom_command(&cgc, NULL, 0, CGC_DATA_NONE);
+ cgc.cmd[0] = GPCMD_FLUSH_CACHE;
- if (eh->nea || eh->notification_class != 0x4)
- return 1;
+ cgc.timeout = 5 * 60 * HZ;
- memcpy(med, &buffer[sizeof(*eh)], sizeof(*med));
- return 0;
+ return cdi->ops->generic_packet(cdi, &cgc);
}
+/* This macro makes sure we don't have to check on cdrom_device_ops
+ * existence in the run-time routines below. Change_capability is a
+ * hack to have the capability flags defined const, while we can still
+ * change it here without gcc complaining at every line.
+ */
+#define E
[PATCH 12/12] cdrom: Remove unnecessary prototype for cdrom_get_disc_info
Move the function to the proper spot instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 71 ++-
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index a7dd384..7e5b628 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,8 +338,6 @@ do {
\
/* Not-exported routines. */
-static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di);
-
static void cdrom_sysctl_register(void);
static LIST_HEAD(cdrom_list);
@@ -369,6 +367,42 @@ static int cdrom_flush_cache(struct cdrom_device_info *cdi)
return cdi->ops->generic_packet(cdi, &cgc);
}
+/* requires CD R/RW */
+static int cdrom_get_disc_info(struct cdrom_device_info *cdi,
+ disc_information *di)
+{
+ struct cdrom_device_ops *cdo = cdi->ops;
+ struct packet_command cgc;
+ int ret, buflen;
+
+ /* set up command and get the disc info */
+ init_cdrom_command(&cgc, di, sizeof(*di), CGC_DATA_READ);
+ cgc.cmd[0] = GPCMD_READ_DISC_INFO;
+ cgc.cmd[8] = cgc.buflen = 2;
+ cgc.quiet = 1;
+
+ ret = cdo->generic_packet(cdi, &cgc);
+ if (ret)
+ return ret;
+
+ /* not all drives have the same disc_info length, so requeue
+* packet with the length the drive tells us it can supply
+*/
+ buflen = be16_to_cpu(di->disc_information_length) +
+ sizeof(di->disc_information_length);
+
+ if (buflen > sizeof(disc_information))
+ buflen = sizeof(disc_information);
+
+ cgc.cmd[8] = cgc.buflen = buflen;
+ ret = cdo->generic_packet(cdi, &cgc);
+ if (ret)
+ return ret;
+
+ /* return actual fill size */
+ return buflen;
+}
+
/* This macro makes sure we don't have to check on cdrom_device_ops
* existence in the run-time routines below. Change_capability is a
* hack to have the capability flags defined const, while we can still
@@ -3360,39 +3394,6 @@ int cdrom_ioctl(struct cdrom_device_info *cdi, struct
block_device *bdev,
return -ENOSYS;
}
-/* requires CD R/RW */
-static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di)
-{
- struct cdrom_device_ops *cdo = cdi->ops;
- struct packet_command cgc;
- int ret, buflen;
-
- /* set up command and get the disc info */
- init_cdrom_command(&cgc, di, sizeof(*di), CGC_DATA_READ);
- cgc.cmd[0] = GPCMD_READ_DISC_INFO;
- cgc.cmd[8] = cgc.buflen = 2;
- cgc.quiet = 1;
-
- if ((ret = cdo->generic_packet(cdi, &cgc)))
- return ret;
-
- /* not all drives have the same disc_info length, so requeue
-* packet with the length the drive tells us it can supply
-*/
- buflen = be16_to_cpu(di->disc_information_length) +
-sizeof(di->disc_information_length);
-
- if (buflen > sizeof(disc_information))
- buflen = sizeof(disc_information);
-
- cgc.cmd[8] = cgc.buflen = buflen;
- if ((ret = cdo->generic_packet(cdi, &cgc)))
- return ret;
-
- /* return actual fill size */
- return buflen;
-}
-
EXPORT_SYMBOL(cdrom_get_last_written);
EXPORT_SYMBOL(register_cdrom);
EXPORT_SYMBOL(unregister_cdrom);
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] cdrom: Move mmc_ioctls above cdrom_ioctl to remove unnecessary prototype
Neaten the spacing too.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 246 +-
1 file changed, 122 insertions(+), 124 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 70ef0134..5148547 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,8 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static int mmc_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
-unsigned long arg);
int cdrom_get_last_written(struct cdrom_device_info *, long *);
static int cdrom_get_next_writable(struct cdrom_device_info *, long *);
@@ -2714,103 +2712,6 @@ static int cdrom_ioctl_audioctl(struct
cdrom_device_info *cdi,
}
/*
- * Just about every imaginable ioctl is supported in the Uniform layer
- * these days.
- * ATAPI / SCSI specific code now mainly resides in mmc_ioctl().
- */
-int cdrom_ioctl(struct cdrom_device_info *cdi, struct block_device *bdev,
- fmode_t mode, unsigned int cmd, unsigned long arg)
-{
- void __user *argp = (void __user *)arg;
- int ret;
-
- /*
-* Try the generic SCSI command ioctl's first.
-*/
- ret = scsi_cmd_blk_ioctl(bdev, mode, cmd, argp);
- if (ret != -ENOTTY)
- return ret;
-
- switch (cmd) {
- case CDROMMULTISESSION:
- return cdrom_ioctl_multisession(cdi, argp);
- case CDROMEJECT:
- return cdrom_ioctl_eject(cdi);
- case CDROMCLOSETRAY:
- return cdrom_ioctl_closetray(cdi);
- case CDROMEJECT_SW:
- return cdrom_ioctl_eject_sw(cdi, arg);
- case CDROM_MEDIA_CHANGED:
- return cdrom_ioctl_media_changed(cdi, arg);
- case CDROM_SET_OPTIONS:
- return cdrom_ioctl_set_options(cdi, arg);
- case CDROM_CLEAR_OPTIONS:
- return cdrom_ioctl_clear_options(cdi, arg);
- case CDROM_SELECT_SPEED:
- return cdrom_ioctl_select_speed(cdi, arg);
- case CDROM_SELECT_DISC:
- return cdrom_ioctl_select_disc(cdi, arg);
- case CDROMRESET:
- return cdrom_ioctl_reset(cdi, bdev);
- case CDROM_LOCKDOOR:
- return cdrom_ioctl_lock_door(cdi, arg);
- case CDROM_DEBUG:
- return cdrom_ioctl_debug(cdi, arg);
- case CDROM_GET_CAPABILITY:
- return cdrom_ioctl_get_capability(cdi);
- case CDROM_GET_MCN:
- return cdrom_ioctl_get_mcn(cdi, argp);
- case CDROM_DRIVE_STATUS:
- return cdrom_ioctl_drive_status(cdi, arg);
- case CDROM_DISC_STATUS:
- return cdrom_ioctl_disc_status(cdi);
- case CDROM_CHANGER_NSLOTS:
- return cdrom_ioctl_changer_nslots(cdi);
- }
-
- /*
-* Use the ioctls that are implemented through the generic_packet()
-* interface. this may look at bit funny, but if -ENOTTY is
-* returned that particular ioctl is not implemented and we
-* let it go through the device specific ones.
-*/
- if (CDROM_CAN(CDC_GENERIC_PACKET)) {
- ret = mmc_ioctl(cdi, cmd, arg);
- if (ret != -ENOTTY)
- return ret;
- }
-
- /*
-* Note: most of the cd_dbg() calls are commented out here,
-* because they fill up the sys log when CD players poll
-* the drive.
-*/
- switch (cmd) {
- case CDROMSUBCHNL:
- return cdrom_ioctl_get_subchnl(cdi, argp);
- case CDROMREADTOCHDR:
- return cdrom_ioctl_read_tochdr(cdi, argp);
- case CDROMREADTOCENTRY:
- return cdrom_ioctl_read_tocentry(cdi, argp);
- case CDROMPLAYMSF:
- return cdrom_ioctl_play_msf(cdi, argp);
- case CDROMPLAYTRKIND:
- return cdrom_ioctl_play_trkind(cdi, argp);
- case CDROMVOLCTRL:
- return cdrom_ioctl_volctrl(cdi, argp);
- case CDROMVOLREAD:
- return cdrom_ioctl_volread(cdi, argp);
- case CDROMSTART:
- case CDROMSTOP:
- case CDROMPAUSE:
- case CDROMRESUME:
- return cdrom_ioctl_audioctl(cdi, cmd);
- }
-
- return -ENOSYS;
-}
-
-/*
* Required when we need to use READ_10 to issue other than 2048 block
* reads
*/
@@ -2840,9 +2741,9 @@ static int cdrom_switch_blocksize(struct
cdrom_device_info *cdi, int size)
}
static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
- void __user *arg,
- struct packet_command *cgc,
- int cmd)
+ void __user *arg,
+ struct packet_command *cgc,
+
[PATCH 04/12] cdrom: Remove prototype for open_for_data
Move static function to the appropriate place to remove
the now unnecessary prototype.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 114 +-
1 file changed, 57 insertions(+), 57 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index e7efa99..72720d7 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,7 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static int open_for_data(struct cdrom_device_info * cdi);
static int check_for_audio_disc(struct cdrom_device_info * cdi,
struct cdrom_device_ops * cdo);
static void sanitize_format(union cdrom_addr *addr,
@@ -957,63 +956,8 @@ static int cdrom_close_write(struct cdrom_device_info *cdi)
#endif
}
-/* We use the open-option O_NONBLOCK to indicate that the
- * purpose of opening is only for subsequent ioctl() calls; no device
- * integrity checks are performed.
- *
- * We hope that all cd-player programs will adopt this convention. It
- * is in their own interest: device control becomes a lot easier
- * this way.
- */
-int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev,
fmode_t mode)
-{
- int ret;
-
- cd_dbg(CD_OPEN, "entering cdrom_open\n");
-
- /* open is event synchronization point, check events first */
- check_disk_change(bdev);
-
- /* if this was a O_NONBLOCK open and we should honor the flags,
-* do a quick open without drive/disc integrity checks. */
- cdi->use_count++;
- if ((mode & FMODE_NDELAY) && (cdi->options & CDO_USE_FFLAGS)) {
- ret = cdi->ops->open(cdi, 1);
- } else {
- ret = open_for_data(cdi);
- if (ret)
- goto err;
- cdrom_mmc3_profile(cdi);
- if (mode & FMODE_WRITE) {
- ret = -EROFS;
- if (cdrom_open_write(cdi))
- goto err_release;
- if (!CDROM_CAN(CDC_RAM))
- goto err_release;
- ret = 0;
- cdi->media_written = 0;
- }
- }
-
- if (ret)
- goto err;
-
- cd_dbg(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
- cdi->name, cdi->use_count);
- return 0;
-err_release:
- if (CDROM_CAN(CDC_LOCK) && cdi->options & CDO_LOCK) {
- cdi->ops->lock_door(cdi, 0);
- cd_dbg(CD_OPEN, "door unlocked\n");
- }
- cdi->ops->release(cdi);
-err:
- cdi->use_count--;
- return ret;
-}
-
static
-int open_for_data(struct cdrom_device_info * cdi)
+int open_for_data(struct cdrom_device_info *cdi)
{
int ret;
struct cdrom_device_ops *cdo = cdi->ops;
@@ -1119,6 +1063,62 @@ clean_up_and_return:
return ret;
}
+/* We use the open-option O_NONBLOCK to indicate that the
+ * purpose of opening is only for subsequent ioctl() calls; no device
+ * integrity checks are performed.
+ *
+ * We hope that all cd-player programs will adopt this convention. It
+ * is in their own interest: device control becomes a lot easier
+ * this way.
+ */
+int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev,
+ fmode_t mode)
+{
+ int ret;
+
+ cd_dbg(CD_OPEN, "entering cdrom_open\n");
+
+ /* open is event synchronization point, check events first */
+ check_disk_change(bdev);
+
+ /* if this was a O_NONBLOCK open and we should honor the flags,
+* do a quick open without drive/disc integrity checks. */
+ cdi->use_count++;
+ if ((mode & FMODE_NDELAY) && (cdi->options & CDO_USE_FFLAGS)) {
+ ret = cdi->ops->open(cdi, 1);
+ } else {
+ ret = open_for_data(cdi);
+ if (ret)
+ goto err;
+ cdrom_mmc3_profile(cdi);
+ if (mode & FMODE_WRITE) {
+ ret = -EROFS;
+ if (cdrom_open_write(cdi))
+ goto err_release;
+ if (!CDROM_CAN(CDC_RAM))
+ goto err_release;
+ ret = 0;
+ cdi->media_written = 0;
+ }
+ }
+
+ if (ret)
+ goto err;
+
+ cd_dbg(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
+ cdi->name, cdi->use_count);
+ return 0;
+err_release:
+ if (CDROM_CAN(CDC_LOCK) && cdi->options & CDO_LOCK) {
+ cdi->ops->lock_door(cdi, 0);
+ cd_dbg(CD_OPEN, "door unlocked\n");
+ }
+ cdi->ops->release(cdi);
+err:
+ cdi->use_count--;
+ return ret;
+}
+
/* This code is similar to that in open_for_data. The routine is called
whenever an audio play operation is requested
[PATCH 08/12] cdrom: Remove cdrom_get_last_written prototype
Move the function instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 193 +-
1 file changed, 97 insertions(+), 96 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 5148547..4fb9ad5 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,7 +338,6 @@ do {
\
/* Not-exported routines. */
-int cdrom_get_last_written(struct cdrom_device_info *, long *);
static int cdrom_get_next_writable(struct cdrom_device_info *, long *);
static void cdrom_count_tracks(struct cdrom_device_info *, tracktype*);
@@ -2740,6 +2739,103 @@ static int cdrom_switch_blocksize(struct
cdrom_device_info *cdi, int size)
return cdo->generic_packet(cdi, &cgc);
}
+static int cdrom_get_track_info(struct cdrom_device_info *cdi,
+ __u16 track, __u8 type, track_information *ti)
+{
+ struct cdrom_device_ops *cdo = cdi->ops;
+ struct packet_command cgc;
+ int ret, buflen;
+
+ init_cdrom_command(&cgc, ti, 8, CGC_DATA_READ);
+ cgc.cmd[0] = GPCMD_READ_TRACK_RZONE_INFO;
+ cgc.cmd[1] = type & 3;
+ cgc.cmd[4] = (track & 0xff00) >> 8;
+ cgc.cmd[5] = track & 0xff;
+ cgc.cmd[8] = 8;
+ cgc.quiet = 1;
+
+ ret = cdo->generic_packet(cdi, &cgc);
+ if (ret)
+ return ret;
+
+ buflen = be16_to_cpu(ti->track_information_length) +
+ sizeof(ti->track_information_length);
+
+ if (buflen > sizeof(track_information))
+ buflen = sizeof(track_information);
+
+ cgc.cmd[8] = cgc.buflen = buflen;
+ ret = cdo->generic_packet(cdi, &cgc);
+ if (ret)
+ return ret;
+
+ /* return actual fill size */
+ return buflen;
+}
+
+/* return the last written block on the CD-R media. this is for the udf
+ file system. */
+int cdrom_get_last_written(struct cdrom_device_info *cdi, long *last_written)
+{
+ struct cdrom_tocentry toc;
+ disc_information di;
+ track_information ti;
+ __u32 last_track;
+ int ret = -1, ti_size;
+
+ if (!CDROM_CAN(CDC_GENERIC_PACKET))
+ goto use_toc;
+
+ ret = cdrom_get_disc_info(cdi, &di);
+ if (ret < (int)(offsetof(typeof(di), last_track_lsb)
+ + sizeof(di.last_track_lsb)))
+ goto use_toc;
+
+ /* if unit didn't return msb, it's zeroed by cdrom_get_disc_info */
+ last_track = (di.last_track_msb << 8) | di.last_track_lsb;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
+ if (ti_size < (int)offsetof(typeof(ti), track_start))
+ goto use_toc;
+
+ /* if this track is blank, try the previous. */
+ if (ti.blank) {
+ if (last_track == 1)
+ goto use_toc;
+ last_track--;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
+ }
+
+ if (ti_size < (int)(offsetof(typeof(ti), track_size)
+ + sizeof(ti.track_size)))
+ goto use_toc;
+
+ /* if last recorded field is valid, return it. */
+ if (ti.lra_v && ti_size >= (int)(offsetof(typeof(ti), last_rec_address)
+ + sizeof(ti.last_rec_address))) {
+ *last_written = be32_to_cpu(ti.last_rec_address);
+ } else {
+ /* make it up instead */
+ *last_written = be32_to_cpu(ti.track_start) +
+ be32_to_cpu(ti.track_size);
+ if (ti.free_blocks)
+ *last_written -= (be32_to_cpu(ti.free_blocks) + 7);
+ }
+ return 0;
+
+ /* this is where we end up if the drive either can't do a
+ GPCMD_READ_DISC_INFO or GPCMD_READ_TRACK_RZONE_INFO or if
+ it doesn't give enough information or fails. then we return
+ the toc contents. */
+use_toc:
+ toc.cdte_format = CDROM_MSF;
+ toc.cdte_track = CDROM_LEADOUT;
+ if ((ret = cdi->ops->audio_ioctl(cdi, CDROMREADTOCENTRY, &toc)))
+ return ret;
+ sanitize_format(&toc.cdte_addr, &toc.cdte_format, CDROM_LBA);
+ *last_written = toc.cdte_addr.lba;
+ return 0;
+}
+
static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
void __user *arg,
struct packet_command *cgc,
@@ -3210,38 +3306,6 @@ int cdrom_ioctl(struct cdrom_device_info *cdi, struct
block_device *bdev,
return -ENOSYS;
}
-static int cdrom_get_track_info(struct cdrom_device_info *cdi, __u16 track,
__u8 type,
-track_information *ti)
-{
- struct cdrom_device_ops *cdo = cdi->ops;
- struct packet_command cgc;
- int ret, buflen;
-
- init_cdrom_command(&cgc, ti, 8, CGC_DATA_READ);
- cgc.cmd[0] = G
[PATCH 10/12] cdrom: Remove cdrom_count_tracks prototype
Move function to proper location instead.
Fix whitespace and embedded if too.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 94 +--
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 8af1307..87a74d4 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,8 +338,6 @@ do {
\
/* Not-exported routines. */
-static void cdrom_count_tracks(struct cdrom_device_info *, tracktype*);
-
static int cdrom_mrw_exit(struct cdrom_device_info *cdi);
static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di);
@@ -948,6 +946,53 @@ static int cdrom_close_write(struct cdrom_device_info *cdi)
#endif
}
+/* badly broken, I know. Is due for a fixup anytime. */
+static void cdrom_count_tracks(struct cdrom_device_info *cdi, tracktype
*tracks)
+{
+ struct cdrom_tochdr header;
+ struct cdrom_tocentry entry;
+ int ret, i;
+ tracks->data = 0;
+ tracks->audio = 0;
+ tracks->cdi = 0;
+ tracks->xa = 0;
+ tracks->error = 0;
+ cd_dbg(CD_COUNT_TRACKS, "entering cdrom_count_tracks\n");
+ /* Grab the TOC header so we can see how many tracks there are */
+ ret = cdi->ops->audio_ioctl(cdi, CDROMREADTOCHDR, &header);
+ if (ret) {
+ if (ret == -ENOMEDIUM)
+ tracks->error = CDS_NO_DISC;
+ else
+ tracks->error = CDS_NO_INFO;
+ return;
+ }
+ /* check what type of tracks are on this disc */
+ entry.cdte_format = CDROM_MSF;
+ for (i = header.cdth_trk0; i <= header.cdth_trk1; i++) {
+ entry.cdte_track = i;
+ if (cdi->ops->audio_ioctl(cdi, CDROMREADTOCENTRY, &entry)) {
+ tracks->error = CDS_NO_INFO;
+ return;
+ }
+ if (entry.cdte_ctrl & CDROM_DATA_TRACK) {
+ if (entry.cdte_format == 0x10)
+ tracks->cdi++;
+ else if (entry.cdte_format == 0x20)
+ tracks->xa++;
+ else
+ tracks->data++;
+ } else {
+ tracks->audio++;
+ }
+ cd_dbg(CD_COUNT_TRACKS, "track %d: format=%d, ctrl=%d\n",
+ i, entry.cdte_format, entry.cdte_ctrl);
+ }
+ cd_dbg(CD_COUNT_TRACKS, "disc has %d tracks: %d=audio %d=data %d=Cd-I
%d=XA\n",
+ header.cdth_trk1, tracks->audio, tracks->data,
+ tracks->cdi, tracks->xa);
+}
+
static
int open_for_data(struct cdrom_device_info *cdi)
{
@@ -1457,51 +1502,6 @@ int cdrom_media_changed(struct cdrom_device_info *cdi)
return media_changed(cdi, 0);
}
-/* badly broken, I know. Is due for a fixup anytime. */
-static void cdrom_count_tracks(struct cdrom_device_info *cdi, tracktype*
tracks)
-{
- struct cdrom_tochdr header;
- struct cdrom_tocentry entry;
- int ret, i;
- tracks->data=0;
- tracks->audio=0;
- tracks->cdi=0;
- tracks->xa=0;
- tracks->error=0;
- cd_dbg(CD_COUNT_TRACKS, "entering cdrom_count_tracks\n");
- /* Grab the TOC header so we can see how many tracks there are */
- if ((ret = cdi->ops->audio_ioctl(cdi, CDROMREADTOCHDR, &header))) {
- if (ret == -ENOMEDIUM)
- tracks->error = CDS_NO_DISC;
- else
- tracks->error = CDS_NO_INFO;
- return;
- }
- /* check what type of tracks are on this disc */
- entry.cdte_format = CDROM_MSF;
- for (i = header.cdth_trk0; i <= header.cdth_trk1; i++) {
- entry.cdte_track = i;
- if (cdi->ops->audio_ioctl(cdi, CDROMREADTOCENTRY, &entry)) {
- tracks->error=CDS_NO_INFO;
- return;
- }
- if (entry.cdte_ctrl & CDROM_DATA_TRACK) {
- if (entry.cdte_format == 0x10)
- tracks->cdi++;
- else if (entry.cdte_format == 0x20)
- tracks->xa++;
- else
- tracks->data++;
- } else
- tracks->audio++;
- cd_dbg(CD_COUNT_TRACKS, "track %d: format=%d, ctrl=%d\n",
- i, entry.cdte_format, entry.cdte_ctrl);
- }
- cd_dbg(CD_COUNT_TRACKS, "disc has %d tracks: %d=audio %d=data %d=Cd-I
%d=XA\n",
- header.cdth_trk1, tracks->audio, tracks->data,
- tracks->cdi, tracks->xa);
-}
-
/* Requests to the low-level drivers will /always/ be done in the
following format convention:
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this lis
[PATCH 05/12] cdrom: Remove unnecessary check_for_audio_disc prototype
The actual static is defined below it but not used until later.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 72720d7..546b97e 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,8 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static int check_for_audio_disc(struct cdrom_device_info * cdi,
-struct cdrom_device_ops * cdo);
static void sanitize_format(union cdrom_addr *addr,
u_char * curr, u_char requested);
static int mmc_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] cdrom: Remove unnecessary sanitize_format prototype
It's defined below without being called.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 546b97e..70ef0134 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,8 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static void sanitize_format(union cdrom_addr *addr,
- u_char * curr, u_char requested);
static int mmc_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
unsigned long arg);
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] usb,uhci: add a new tag for virtual uhci devices
On 06/28/2013 10:22 PM, Alan Stern wrote: On Fri, 28 Jun 2013, Li, Zhen-Hua (USL-China) wrote: There was a problem, the warning "Controller not stopped yet". And your last patch for this problem does a wrong thing: It prevents all HP uhci devices from auto-stop, which make HP uhci devices waste more power. Do they really waste more power? Have you measured this? Is CONFIG_PM enabled in the kernel configuration? This is another new problem. I think this should be corrected, so I want to apply it. In the last email, you said that your patch did not make the machine act different. Now you say that your patch makes the machine use less power. Which statement is correct? Alan Stern Let's make it clear: I said "I don't have a machine that this makes action different", it does not mean my patch "did not make the machine act different ". There are many kinds of machines, I have never said "my patch does not make ALL of them act different". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] cdrom: Remove cdrom_get_next_writeable prototype
Move the function to the right spot instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 101 +-
1 file changed, 51 insertions(+), 50 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 4fb9ad5..8af1307 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,7 +338,6 @@ do {
\
/* Not-exported routines. */
-static int cdrom_get_next_writable(struct cdrom_device_info *, long *);
static void cdrom_count_tracks(struct cdrom_device_info *, tracktype*);
static int cdrom_mrw_exit(struct cdrom_device_info *cdi);
@@ -2836,6 +2835,57 @@ use_toc:
return 0;
}
+/* return the next writable block. also for udf file system. */
+static int cdrom_get_next_writable(struct cdrom_device_info *cdi,
+ long *next_writable)
+{
+ disc_information di;
+ track_information ti;
+ __u16 last_track;
+ int ret, ti_size;
+
+ if (!CDROM_CAN(CDC_GENERIC_PACKET))
+ goto use_last_written;
+
+ ret = cdrom_get_disc_info(cdi, &di);
+ if (ret < 0 || ret < offsetof(typeof(di), last_track_lsb)
+ + sizeof(di.last_track_lsb))
+ goto use_last_written;
+
+ /* if unit didn't return msb, it's zeroed by cdrom_get_disc_info */
+ last_track = (di.last_track_msb << 8) | di.last_track_lsb;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
+ if (ti_size < 0 || ti_size < offsetof(typeof(ti), track_start))
+ goto use_last_written;
+
+ /* if this track is blank, try the previous. */
+ if (ti.blank) {
+ if (last_track == 1)
+ goto use_last_written;
+ last_track--;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
+ if (ti_size < 0)
+ goto use_last_written;
+ }
+
+ /* if next recordable address field is valid, use it. */
+ if (ti.nwa_v && ti_size >= offsetof(typeof(ti), next_writable)
+ + sizeof(ti.next_writable)) {
+ *next_writable = be32_to_cpu(ti.next_writable);
+ return 0;
+ }
+
+use_last_written:
+ ret = cdrom_get_last_written(cdi, next_writable);
+ if (ret) {
+ *next_writable = 0;
+ return ret;
+ } else {
+ *next_writable += 7;
+ return 0;
+ }
+}
+
static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
void __user *arg,
struct packet_command *cgc,
@@ -3339,55 +3389,6 @@ static int cdrom_get_disc_info(struct cdrom_device_info
*cdi, disc_information *
return buflen;
}
-/* return the next writable block. also for udf file system. */
-static int cdrom_get_next_writable(struct cdrom_device_info *cdi, long
*next_writable)
-{
- disc_information di;
- track_information ti;
- __u16 last_track;
- int ret, ti_size;
-
- if (!CDROM_CAN(CDC_GENERIC_PACKET))
- goto use_last_written;
-
- ret = cdrom_get_disc_info(cdi, &di);
- if (ret < 0 || ret < offsetof(typeof(di), last_track_lsb)
- + sizeof(di.last_track_lsb))
- goto use_last_written;
-
- /* if unit didn't return msb, it's zeroed by cdrom_get_disc_info */
- last_track = (di.last_track_msb << 8) | di.last_track_lsb;
- ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
- if (ti_size < 0 || ti_size < offsetof(typeof(ti), track_start))
- goto use_last_written;
-
-/* if this track is blank, try the previous. */
- if (ti.blank) {
- if (last_track == 1)
- goto use_last_written;
- last_track--;
- ti_size = cdrom_get_track_info(cdi, last_track, 1, &ti);
- if (ti_size < 0)
- goto use_last_written;
- }
-
- /* if next recordable address field is valid, use it. */
- if (ti.nwa_v && ti_size >= offsetof(typeof(ti), next_writable)
- + sizeof(ti.next_writable)) {
- *next_writable = be32_to_cpu(ti.next_writable);
- return 0;
- }
-
-use_last_written:
- if ((ret = cdrom_get_last_written(cdi, next_writable))) {
- *next_writable = 0;
- return ret;
- } else {
- *next_writable += 7;
- return 0;
- }
-}
-
EXPORT_SYMBOL(cdrom_get_last_written);
EXPORT_SYMBOL(register_cdrom);
EXPORT_SYMBOL(unregister_cdrom);
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
[PATCH 02/12] cdrom: Remove unused CHECKAUDIO macro
It's unused, make it disappear.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 4239a69..3aa51a7 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -339,9 +339,6 @@ do {
\
a lot of places. This macro makes the code more clear. */
#define CDROM_CAN(type) (cdi->ops->capability & ~cdi->mask & (type))
-/* used in the audio ioctls */
-#define CHECKAUDIO if ((ret=check_for_audio_disc(cdi, cdo))) return ret
-
/*
* Another popular OS uses 7 seconds as the hard timeout for default
* commands, so it is a good choice for us as well.
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/12] cdrom: neatening
Joe Perches (12): cdrom: convert cdinfo to cd_dbg cdrom: Remove unused CHECKAUDIO macro cdrom: Remove obfuscating IOCTL_IN and IOCTL_OUT macros cdrom: Remove prototype for open_for_data cdrom: Remove unnecessary check_for_audio_disc prototype cdrom: Remove unnecessary sanitize_format prototype cdrom: Move mmc_ioctls above cdrom_ioctl to remove unnecessary prototype cdrom: Remove cdrom_get_last_written prototype cdrom: Remove cdrom_get_next_writeable prototype cdrom: Remove cdrom_count_tracks prototype cdrom: Remove unnecessary prototype for cdrom_mrw_exit cdrom: Remove unnecessary prototype for cdrom_get_disc_info drivers/cdrom/cdrom.c | 1359 + 1 file changed, 682 insertions(+), 677 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] cdrom: Remove obfuscating IOCTL_IN and IOCTL_OUT macros
Macros with hidden control flow aren't nice.
Just use copy_to/from_user directly instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 48 +++-
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 3aa51a7..e7efa99 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -326,15 +326,6 @@ do {
\
} while (0)
#endif
-/* These are used to simplify getting data in from and back to user land */
-#define IOCTL_IN(arg, type, in)\
- if (copy_from_user(&(in), (type __user *) (arg), sizeof (in))) \
- return -EFAULT;
-
-#define IOCTL_OUT(arg, type, out) \
- if (copy_to_user((type __user *) (arg), &(out), sizeof (out))) \
- return -EFAULT;
-
/* The (cdo->capability & ~cdi->mask & CDC_XXX) construct was used in
a lot of places. This macro makes the code more clear. */
#define CDROM_CAN(type) (cdi->ops->capability & ~cdi->mask & (type))
@@ -2874,7 +2865,8 @@ static noinline int mmc_ioctl_cdrom_read_data(struct
cdrom_device_info *cdi,
blocksize = CD_FRAMESIZE_RAW0;
break;
}
- IOCTL_IN(arg, struct cdrom_msf, msf);
+ if (copy_from_user(&msf, (struct cdrom_msf __user *)arg, sizeof(msf)))
+ return -EFAULT;
lba = msf_to_lba(msf.cdmsf_min0, msf.cdmsf_sec0, msf.cdmsf_frame0);
/* FIXME: we need upper bound checking, too!! */
if (lba < 0)
@@ -2916,7 +2908,9 @@ static noinline int mmc_ioctl_cdrom_read_audio(struct
cdrom_device_info *cdi,
struct cdrom_read_audio ra;
int lba;
- IOCTL_IN(arg, struct cdrom_read_audio, ra);
+ if (copy_from_user(&ra, (struct cdrom_read_audio __user *)arg,
+ sizeof(ra)))
+ return -EFAULT;
if (ra.addr_format == CDROM_MSF)
lba = msf_to_lba(ra.addr.msf.minute,
@@ -2940,7 +2934,8 @@ static noinline int mmc_ioctl_cdrom_subchannel(struct
cdrom_device_info *cdi,
int ret;
struct cdrom_subchnl q;
u_char requested, back;
- IOCTL_IN(arg, struct cdrom_subchnl, q);
+ if (copy_from_user(&q, (struct cdrom_subchnl __user *)arg, sizeof(q)))
+ return -EFAULT;
requested = q.cdsc_format;
if (!((requested == CDROM_MSF) ||
(requested == CDROM_LBA)))
@@ -2952,7 +2947,8 @@ static noinline int mmc_ioctl_cdrom_subchannel(struct
cdrom_device_info *cdi,
back = q.cdsc_format; /* local copy */
sanitize_format(&q.cdsc_absaddr, &back, requested);
sanitize_format(&q.cdsc_reladdr, &q.cdsc_format, requested);
- IOCTL_OUT(arg, struct cdrom_subchnl, q);
+ if (copy_to_user((struct cdrom_subchnl __user *)arg, &q, sizeof(q)))
+ return -EFAULT;
/* cd_dbg(CD_DO_IOCTL, "CDROMSUBCHNL successful\n"); */
return 0;
}
@@ -2964,7 +2960,8 @@ static noinline int mmc_ioctl_cdrom_play_msf(struct
cdrom_device_info *cdi,
struct cdrom_device_ops *cdo = cdi->ops;
struct cdrom_msf msf;
cd_dbg(CD_DO_IOCTL, "entering CDROMPLAYMSF\n");
- IOCTL_IN(arg, struct cdrom_msf, msf);
+ if (copy_from_user(&msf, (struct cdrom_msf __user *)arg, sizeof(msf)))
+ return -EFAULT;
cgc->cmd[0] = GPCMD_PLAY_AUDIO_MSF;
cgc->cmd[3] = msf.cdmsf_min0;
cgc->cmd[4] = msf.cdmsf_sec0;
@@ -2983,7 +2980,8 @@ static noinline int mmc_ioctl_cdrom_play_blk(struct
cdrom_device_info *cdi,
struct cdrom_device_ops *cdo = cdi->ops;
struct cdrom_blk blk;
cd_dbg(CD_DO_IOCTL, "entering CDROMPLAYBLK\n");
- IOCTL_IN(arg, struct cdrom_blk, blk);
+ if (copy_from_user(&blk, (struct cdrom_blk __user *)arg, sizeof(blk)))
+ return -EFAULT;
cgc->cmd[0] = GPCMD_PLAY_AUDIO_10;
cgc->cmd[2] = (blk.from >> 24) & 0xff;
cgc->cmd[3] = (blk.from >> 16) & 0xff;
@@ -3008,7 +3006,9 @@ static noinline int mmc_ioctl_cdrom_volume(struct
cdrom_device_info *cdi,
cd_dbg(CD_DO_IOCTL, "entering CDROMVOLUME\n");
- IOCTL_IN(arg, struct cdrom_volctrl, volctrl);
+ if (copy_from_user(&volctrl, (struct cdrom_volctrl __user *)arg,
+ sizeof(volctrl)))
+ return -EFAULT;
cgc->buffer = buffer;
cgc->buflen = 24;
@@ -3045,7 +3045,9 @@ static noinline int mmc_ioctl_cdrom_volume(struct
cdrom_device_info *cdi,
volctrl.channel1 = buffer[offset+11];
volctrl.channel2 = buffer[offset+13];
volctrl.channel3 = buffer[offset+15];
- IOCTL_OUT(arg, struct cdrom_volctrl, volctrl);
+ if (copy_to_user((struct cdrom_volctrl __user *)arg, &volctrl,
+sizeof(volctrl)))
+ return -EFAULT;
return
[PATCH 01/12] cdrom: convert cdinfo to cd_dbg
It's a debugging message, mark it so.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 243 +-
1 file changed, 122 insertions(+), 121 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 8a3aff7..4239a69 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -312,17 +312,17 @@ static const char *mrw_format_status[] = {
static const char *mrw_address_space[] = { "DMA", "GAA" };
-#if (ERRLOGMASK!=CD_NOTHING)
-#define cdinfo(type, fmt, args...) \
+#if (ERRLOGMASK != CD_NOTHING)
+#define cd_dbg(type, fmt, ...) \
do { \
if ((ERRLOGMASK & type) || debug == 1) \
- pr_info(fmt, ##args); \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
#else
-#define cdinfo(type, fmt, args...) \
+#define cd_dbg(type, fmt, ...) \
do { \
- if (0 && (ERRLOGMASK & type) || debug == 1) \
- pr_info(fmt, ##args); \
+ if (0 && ((ERRLOGMASK & type) || debug == 1)) \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
#endif
@@ -395,7 +395,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
struct cdrom_device_ops *cdo = cdi->ops;
int *change_capability = (int *)&cdo->capability; /* hack */
- cdinfo(CD_OPEN, "entering register_cdrom\n");
+ cd_dbg(CD_OPEN, "entering register_cdrom\n");
if (cdo->open == NULL || cdo->release == NULL)
return -EINVAL;
@@ -439,7 +439,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
if (!cdo->generic_packet)
cdo->generic_packet = cdrom_dummy_generic_packet;
- cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
+ cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
mutex_lock(&cdrom_mutex);
list_add(&cdi->list, &cdrom_list);
mutex_unlock(&cdrom_mutex);
@@ -449,7 +449,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
void unregister_cdrom(struct cdrom_device_info *cdi)
{
- cdinfo(CD_OPEN, "entering unregister_cdrom\n");
+ cd_dbg(CD_OPEN, "entering unregister_cdrom\n");
mutex_lock(&cdrom_mutex);
list_del(&cdi->list);
@@ -459,7 +459,7 @@ void unregister_cdrom(struct cdrom_device_info *cdi)
cdi->exit(cdi);
cdi->ops->n_minors--;
- cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
+ cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
}
int cdrom_get_media_event(struct cdrom_device_info *cdi,
@@ -839,7 +839,7 @@ static int cdrom_ram_open_write(struct cdrom_device_info
*cdi)
else if (CDF_RWRT == be16_to_cpu(rfd.feature_code))
ret = !rfd.curr;
- cdinfo(CD_OPEN, "can open for random write\n");
+ cd_dbg(CD_OPEN, "can open for random write\n");
return ret;
}
@@ -928,12 +928,12 @@ static void cdrom_dvd_rw_close_write(struct
cdrom_device_info *cdi)
struct packet_command cgc;
if (cdi->mmc3_profile != 0x1a) {
- cdinfo(CD_CLOSE, "%s: No DVD+RW\n", cdi->name);
+ cd_dbg(CD_CLOSE, "%s: No DVD+RW\n", cdi->name);
return;
}
if (!cdi->media_written) {
- cdinfo(CD_CLOSE, "%s: DVD+RW media clean\n", cdi->name);
+ cd_dbg(CD_CLOSE, "%s: DVD+RW media clean\n", cdi->name);
return;
}
@@ -981,7 +981,7 @@ int cdrom_open(struct cdrom_device_info *cdi, struct
block_device *bdev, fmode_t
{
int ret;
- cdinfo(CD_OPEN, "entering cdrom_open\n");
+ cd_dbg(CD_OPEN, "entering cdrom_open\n");
/* open is event synchronization point, check events first */
check_disk_change(bdev);
@@ -1010,13 +1010,13 @@ int cdrom_open(struct cdrom_device_info *cdi, struct
block_device *bdev, fmode_t
if (ret)
goto err;
- cdinfo(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
- cdi->name, cdi->use_count);
+ cd_dbg(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
+ cdi->name, cdi->use_count);
return 0;
err_release:
if (CDROM_CAN(CDC_LOCK) && cdi->options & CDO_LOCK) {
cdi->ops->lock_door(cdi, 0);
- cdinfo(CD_OPEN, "door unlocked.\n");
+ cd_dbg(CD_OPEN, "door unlocked\n");
}
cdi->ops->release(cdi);
err:
@@ -1030,21 +1030,21 @@ int open_for_data(struct cdrom_device_info * cdi)
int ret;
struct cdrom_device_ops *cdo = cdi->ops;
tracktype tracks;
- cdinfo(CD_OPEN, "entering open_for_data\n");
+ cd_dbg(CD_OPEN, "entering open_for_data\n");
/* Check if the driver can report dr
[GIT PULL] (xen) stable/for-linus-3.11-rc0-tag
Hey Linus, Since the merge window opened merely three hours ago and I am sure you are addictively refreshing your email for the next set of GIT PULLs and can't wait for them - I figured I would offer you a nice little evening GIT-PULL snack to sustain you until Monday GIT-PULL-email-avalanche :-) With that in mind please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.11-rc0-tag which has bug-fixes. No new features - just fixes and fixes. The signed tag goes in more details, but the bulk is just the cleanups (use pr_* instead of printk, fix strings being split across 80 characters, etc). Please pull! arch/x86/xen/smp.c | 91 +++-- arch/x86/xen/spinlock.c | 7 ++- arch/x86/xen/time.c | 58 +- drivers/pci/xen-pcifront.c | 7 +-- drivers/xen/balloon.c | 6 +- drivers/xen/cpu_hotplug.c | 6 +- drivers/xen/events.c| 23 drivers/xen/evtchn.c| 6 +- drivers/xen/gntalloc.c | 6 +- drivers/xen/gntdev.c| 8 ++- drivers/xen/grant-table.c | 17 +++--- drivers/xen/manage.c| 25 drivers/xen/mcelog.c| 36 +--- drivers/xen/pcpu.c | 12 ++-- drivers/xen/privcmd.c | 4 +- drivers/xen/swiotlb-xen.c | 12 ++-- drivers/xen/tmem.c | 10 ++-- drivers/xen/xen-acpi-cpuhotplug.c | 2 + drivers/xen/xen-acpi-memhotplug.c | 2 + drivers/xen/xen-acpi-pad.c | 2 + drivers/xen/xen-acpi-processor.c| 25 drivers/xen/xen-balloon.c | 6 +- drivers/xen/xen-pciback/conf_space_header.c | 16 ++--- drivers/xen/xen-pciback/pci_stub.c | 35 +-- drivers/xen/xen-pciback/pciback_ops.c | 9 ++- drivers/xen/xen-pciback/vpci.c | 10 ++-- drivers/xen/xen-pciback/xenbus.c| 8 ++- drivers/xen/xen-selfballoon.c | 11 ++-- drivers/xen/xenbus/xenbus_comms.c | 13 +++-- drivers/xen/xenbus/xenbus_dev_backend.c | 4 +- drivers/xen/xenbus/xenbus_dev_frontend.c| 4 +- drivers/xen/xenbus/xenbus_probe.c | 30 +- drivers/xen/xenbus/xenbus_probe_backend.c | 8 ++- drivers/xen/xenbus/xenbus_probe_frontend.c | 35 +-- drivers/xen/xenbus/xenbus_xs.c | 22 +++ drivers/xen/xencomm.c | 2 + drivers/xen/xenfs/super.c | 4 +- include/xen/hvm.h | 4 +- 38 files changed, 321 insertions(+), 265 deletions(-) Joe Perches (1): xen: Convert printks to pr_ Konrad Rzeszutek Wilk (10): xen/smp: Coalesce the free_irq calls in one function. xen/smp: Introduce a common structure to contain the IRQ name and interrupt line. xen/smp: Set the per-cpu IRQ number to a valid default. xen/smp: Don't leak interrupt name when offlining. xen/spinlock: Don't leak interrupt name when offlining. xen/time: Encapsulate the struct clock_event_device in another structure. xen/time: Don't leak interrupt name when offlining. xen/time: Check that the per_cpu data structure has data before freeing. xen/time: Free onlined per-cpu data structure if we want to online it again. xen/pcifront: Deal with toolstack missing 'XenbusStateClosing' state. Laszlo Ersek (1): xen/time: remove blocked time accounting from xen "clockchip" Stefano Stabellini (1): xen: ifdef CONFIG_HIBERNATE_CALLBACKS xen_*_suspend Wei Yongjun (1): xen-pciback: fix error return code in pcistub_irq_handler_switch() -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.10
Hi all, On Sun, 30 Jun 2013 16:09:59 -0700 Linus Torvalds wrote: > > ... So, lets all take a deep breath, go test what's in linux-next, resist the urge to rebase/rewrite all those trees and then bury Linus under pull requests. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpZyMzQ52Pij.pgp Description: PGP signature
Re: [PATCH] regulator: max77693: Remove NULL test for rmatch[i].init_data
On 2013년 06월 30일 01:33, Axel Lin wrote:
> The implementation in of_regulator_match() already ensures match->init_data is
> not NULL for all matched cases if the return value of of_regulator_match() >
> 0.
>
> Thus remove NULL test for rmatch[i].init_data.
>
> This patch also fixes the condition for loop iteration.
> The for loop should iterate "matched" times rather than ARRAY_SIZE(regulators)
> because we only allocate "matched" number of entries for rdata.
> Though in most cases, "matched" == ARRAY_SIZE(regulators).
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/max77693.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c
> index d45a4dd..ce4b96c 100644
> --- a/drivers/regulator/max77693.c
> +++ b/drivers/regulator/max77693.c
> @@ -190,9 +190,7 @@ static int max77693_pmic_dt_parse_rdata(struct device
> *dev,
>
> tmp = *rdata;
>
> - for (i = 0; i < ARRAY_SIZE(regulators); i++) {
> - if (!rmatch[i].init_data)
> - continue;
> + for (i = 0; i < matched; i++) {
> tmp->initdata = rmatch[i].init_data;
> tmp->of_node = rmatch[i].of_node;
> tmp->id = regulators[i].id;
Looks good to me,
Acked-by : Jonghwa Lee
Thanks,
Jonghwa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] vmcore: support mmap() on /proc/vmcore
(2013/06/29 1:40), Maxim Uvarov wrote: Did test on 1TB machine. Total vmcore capture and save took 143 minutes while vmcore size increased from 9Gb to 59Gb. Will do some debug for that. Maxim. Please show me your kdump configuration file and tell me what you did in the test and how you confirmed the result. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: max77693: Fix trivial typo
On 2013년 06월 29일 12:37, Axel Lin wrote: > Fix trivial typo in the equation to check upper bound of current setting. > > Signed-off-by: Axel Lin > --- > drivers/regulator/max77693.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c > index 674ece7..d45a4dd 100644 > --- a/drivers/regulator/max77693.c > +++ b/drivers/regulator/max77693.c > @@ -97,7 +97,7 @@ static int max77693_chg_set_current_limit(struct > regulator_dev *rdev, > while (chg_min_uA + CHGIN_ILIM_STEP_20mA * sel < min_uA) > sel++; > > - if (chg_min_uA * CHGIN_ILIM_STEP_20mA * sel > max_uA) > + if (chg_min_uA + CHGIN_ILIM_STEP_20mA * sel > max_uA) > return -EINVAL; > > /* the first four codes for charger current are all 60mA */ Acked-by: Jonghwa Lee Thanks, Jonghwa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.10
So I delayed this by a day, considering whether to do another -rc, but decided that there wasn't enough upside. Sure, it hasn't been as quiet as I'd like, and we had this long discussion about an inode list locking scalability issue over the last week or two, but in the end that issue turned out to not be new, and while we may end up back-porting the eventual resolution to 3.10, it wasn't a reason to delay the release. Similarly, while I might wish for fewer pull requests during the late rc's (and particularly the ones that came in Friday evening - inconvenient for a weekend release), at some point delaying things doesn't really help things, and just makes the pent up demand for the next merge window worse. In other words, I could really have gone either way, but decided that there wasn't enough reason to break the normal pattern of "rc7 is the last rc before the release". So here goes.. The appended changelog is (as usual) just the changes since the last rc. This time mainly from the networking pull (which includes drivers and core networking, as well as bluetooth), the rest were pretty small and scattered. We've got some arch updates, some acpi/pm fixes, and a scattering of other random fixes.. In the bigger picture (ie since 3.9) this release has been pretty typical and not particularly prone to problems, despite my waffling about the exact release date. As usual, the bulk patch-wise is all drivers (pretty much exactly two thirds), while the rest is evenly split between arch updates and "misc". No major new subsystems this time around, although there are individual new features. As usual, I'm sure H-Online and kernelnewbies will do better writeups of the details.. Linus --- Aaron Lu (1): libata-acpi: add back ACPI based hotplug functionality Akira Takeuchi (2): mn10300: Allow to pass array name to get_user() mn10300: Use early_param() to parse "mem=" parameter Amir Vadai (1): net/mlx_en: Timestamping is not supported in slave mode Anderson Lizardo (1): Bluetooth: Fix crash in l2cap_build_cmd() with small MTU Arend van Spriel (2): brcmsmac: disable power-save related functions brcmfmac: free primary net_device when brcmf_bus_start() fails Artem Bityutskiy (2): UBIFS: prepare to fix a horrid bug UBIFS: fix a horrid bug Aydin Arik (1): ipv4: Fixed MD5 key lookups when adding/ removing MD5 to/ from TCP sockets. Balazs Peter Odor (1): netfilter: nf_nat_sip: fix mangling Ben Hutchings (3): Input: add missing dependencies on CONFIG_HAS_IOMEM s390/irq: Only define synchronize_irq() on SMP sfc: Remove write permission from phy_type attribute Chris Wilson (1): drm/i915: Restore fences after resume and GPU resets Dan Williams (1): qmi_wwan: add various Novatel Gobi1K IDs Daniel Drake (1): Bluetooth: btmrvl: fix thread stopping race Daniel Lezcano (1): tick: Fix tick_broadcast_pending_mask not cleared Dave Airlie (1): drm/qxl: add missing access check for execbuffer ioctl David Daney (2): netdev: octeon_mgmt: Correct tx IFG workaround. netdev: octeon_mgmt: Fix structure layout for little-endian. Emmanuel Grumbach (1): iwlwifi: mvm: correctly set the flags for BAR Eric Dumazet (2): gre: fix a possible skb leak ipv6: ip6_sk_dst_check() must not assume ipv6 dst Felix Fietkau (1): ath9k: fix an RCU issue in calling ieee80211_get_tx_rates Fernando Luis Vazquez Cao (1): vlan: restore ethtool ABI to control VLAN hardware acceleration Ferruh Yigit (2): Input: cyttsp - fix memcpy size param Input: cyttsp - add missing handshake Florian Westphal (1): netfilter: ctnetlink: send event when conntrack label was modified Gao feng (2): ipv6: don't call addrconf_dst_alloc again when enable lo netfilter: ipt_ULOG: fix incorrect setting of ulog timer Gavin Shan (2): net/tg3: Avoid delay during MMIO access powerpc/eeh: Fix fetching bus for single-dev-PE Giuseppe CAVALLARO (1): stmmac: fix EEE setup Gregory CLEMENT (1): ARM: 7773/1: PJ4B: Add support for errata 4742 Guenter Roeck (2): net: fec: Fix build for MCF5272 powerpc/pci: Improve device hotplug initialization Haiyang Zhang (1): Fix the VLAN_TAG_PRESENT in netvsc_recv_callback() Hannes Frederic Sowa (1): ipv6: check return value of ipv6_get_lladdr Heiko Carstens (1): s390/mem_detect: fix memory hole handling Herbert Xu (1): crypto: algboss - Hold ref count on larval Jacob Shin (1): cpufreq: fix NULL pointer deference at od_set_powersave_bias() Jaganath Kanakkassery (1): Bluetooth: Fix invalid length check in l2cap_information_rsp() Javier Martinez Canillas (1): gpio/omap: don't use linear domain mapping for OMAP1 Jiang Liu (2): ACPI / dock: Initialize ACPI dock subsystem upfront PCI / ACPI: Use boot-time resource allocation rules during hotplug Joha
Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume
On Monday, July 01, 2013 12:22:47 AM Srivatsa S. Bhat wrote:
> On 06/30/2013 10:35 PM, Toralf Förster wrote:
> > On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote:
> >> Toralf, can you please
> >> try out the below patch and see if it improves anything? (Don't revert
> >> anything,
> >> just apply the below diff on a problematic kernel and see if it solves your
> >> issue).
> >
> > applied on top of a66b2e5 - issue went away (either fixed or hidden now)
> >
>
> Cool! So here is the proper patch, with changelog added.
>
> Regards,
> Srivatsa S. Bhat
>
>
> -
>
> From: Srivatsa S. Bhat
> Subject: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume
>
> Toralf Förster reported that the cpufreq ondemand governor behaves erratically
> (doesn't scale well) after a suspend/resume cycle. The problem was that the
> cpufreq subsystem's idea of the cpu frequencies differed from the actual
> frequencies set in the hardware after a suspend/resume cycle. Toralf bisected
> the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across
> suspend/resume).
>
> Among other (harmless) things, that commit skipped the call to
> cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays
> an important role during resume, because it is responsible for checking if
> the BIOS changed the cpu frequencies behind our back and resynchronize the
> cpufreq subsystem's knowledge of the cpu frequencies, and update them
> accordingly.
>
> So, restore the call to cpufreq_update_policy() in the resume path to fix
> the cpufreq regression.
>
> Reported-by: Toralf Förster
> Tested-by: Toralf Förster
> Signed-off-by: Srivatsa S. Bhat
Thanks Srivatsa, I'll queue it up as 3.11 (and 3.10-stable) material.
Thanks,
Rafael
> ---
>
> drivers/cpufreq/cpufreq_stats.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index fb65dec..591b6fb 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct
> notifier_block *nfb,
>
> switch (action) {
> case CPU_ONLINE:
> + case CPU_ONLINE_FROZEN:
> cpufreq_update_policy(cpu);
> break;
> case CPU_DOWN_PREPARE:
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k/setup: Use pr_*() instead of plain printk()
On Sun, 2013-06-30 at 11:48 +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
Hi Geert, just trivial comments...
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> @@ -161,7 +161,7 @@ static void __init m68k_parse_bootinfo(const struct
> bi_record *record)
[]
> - printk("m68k_parse_bootinfo: too many memory
> chunks\n");
> + pr_warn("m68k_parse_bootinfo: too many memory
> chunks\n");
These are generally better written by
removing the hand-written function name
and using "%s: ", __func__
pr_warn("%s: too many memory chunks\n",
__func__);
> @@ -197,8 +197,8 @@ static void __init m68k_parse_bootinfo(const struct
> bi_record *record)
> - printk("m68k_parse_bootinfo: unknown tag 0x%04x
> ignored\n",
> -record->tag);
> + pr_warn("m68k_parse_bootinfo: unknown tag 0x%04x
> ignored\n",
> +record->tag);
etc.
> @@ -538,9 +538,9 @@ void check_bugs(void)
> {
> #ifndef CONFIG_M68KFPU_EMU
> if (m68k_fputype == 0) {
> - printk(KERN_EMERG "*** YOU DO NOT HAVE A FLOATING POINT UNIT, "
> + pr_emerg("*** YOU DO NOT HAVE A FLOATING POINT UNIT, "
> "WHICH IS REQUIRED BY LINUX/M68K ***\n");
> - printk(KERN_EMERG "Upgrade your hardware or join the FPU "
> + pr_emerg("Upgrade your hardware or join the FPU "
> "emulation project\n");
It would be nicer to coalesce the formats
into a single line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Use asm-goto to implement mutex fast path on x86-64
On Sat, Jun 29, 2013 at 04:56:30PM -0700, Wedson Almeida Filho wrote: > On Fri, Jun 28, 2013 at 7:09 AM, Borislav Petkov wrote: > > > Btw, do we have any perf data showing any improvements from this patch? > > I wrote a simple test the measures the time it takes to acquire and > release an uncontended mutex (i.e., we always take the fast path) > 100k times. I ran it a few times, the original code averages > 2.743436ms, and the new code averages 2.101098ms, so it's about 23% > improvement. Microbenchmark results tend to be misleading in such situations. Rather, it would be much closer to reality if you traced a real workload like a simple kernel build, for example, with and without your patch. I.e., something like perf stat --repeat 5 ./build-kernel.sh and take a look at what the perfcouters are saying in both cases. > I also think the code looks cleaner this way. No doubt. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jun 28 [ BISECTED: rsyslog/imklog: High CPU usage ]
On Sun, Jun 30, 2013 at 10:17 PM, wrote:
> On Sun, 30 Jun 2013 20:19:45 +0200, Oleg Nesterov said:
>>
>> Not only "__wait_no_timeout(tout) ?:" was wrong, I didn't bother
>> to recheck this logic even after I got the "warning: the omitted
>> middle operand in ?:" reports.
>>
>> Sedat, thanks you very much! Any chance you can try the patch below?
>
> I'm not Sedat, but I had the same problem with rsyslog going nuts,
> and I can confirm that the patch fixes the problem. (Had to hand-apply
> it, there was some difference of opinion regarding { } on an else)
>
I am... Legend :-).
Thanks for confirmation!
- Yes, it's you (every day Gmail says this to me) "Sedat" -
> Feel free to toss on a Tested-By: if this becomes a separate commit...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Kernel lock elision for TSX
On Saturday, March 23, 2013 6:11:52 PM UTC+1, Linus Torvalds wrote: > On Fri, Mar 22, 2013 at 6:24 PM, Andi Kleen wrote: > > > > > Some questions and answers: > > > > - How much does it improve performance? > > > I cannot share any performance numbers at this point unfortunately. > > Also please keep in mind that the tuning is very preliminary and > > will be revised. > > If we don't know how much it helps, we can't judge whether it's worth > even discussing this patch. It adds enough complexity that it had > better be worth it, and without knowing the performance side, all we > can see are the negatives. > > Talk to your managers about this. Tell them that without performance > numbers, any patch-series like this is totally pointless. Hello, I don't know if the thread is still actual, but I have a Core i7 4770 as my home PC, which supports TSX. I bought it *exactly* to experiment with hardware transactions. I am willing to test and benchmark kernel patches, and since I do not work for Intel I can tell all the quantitative performance differences I find. Obviously, they will be *my* results, not official Intel ones - it's up to Andi Kleen or some other Intel guy to tell if they are ok or not with this, but since CPUs with TSX are now available in shops, non-disclosure about their performance seems a bit difficult to enforce... -- I can tell from my preliminary performance results that at least for user-space RTM seems really fast. On my PC, the overhead of an empty transaction is approximately 11 nanoseconds and a minimal transaction reading and writing 2 or 3 memory addresses runs in approximately 15-20 nanoseconds. I just hope I did not violate some non-disclosure condition attached to the CPU guarantee certificate ;-) I tested it both with GCC, using inline assembler and .byte directives, and in Lisp (don't tell anybody), by writing a compiler module that defines the XBEGIN, XTEST, XABORT and XEND primitives. -- How can I help? I would start with the patches already posted by Andi, but the ones I found in LKML archives seem to belong to at least two different sets of patches: xy/31 (September 2012) and xy/29 (March 2013) and I could not find if the first ones are a prerequisite for the second. Regards, Massimiliano -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jun 28 [ BISECTED: rsyslog/imklog: High CPU usage ]
On Sun, Jun 30, 2013 at 8:19 PM, Oleg Nesterov wrote:
> Andrew, please drop these
>
> wait-introduce-wait_event_commonwq-condition-state-timeout.patch
> wait-introduce-prepare_to_wait_event.patch
>
> patches again. I'll send v3 although it really looks like I should
> never try to touch wait.h.
>
> On 06/29, Sedat Dilek wrote:
>>
>> As this all did not show me what caused the problem I started a
>> git-bisect session.
>>
>> This revealed the following culprit commit:
>>
>> commit bb1f30cb7d3ba21098f0ee7e0382160ba2599a43
>> "wait: introduce wait_event_common(wq, condition, state, timeout)"
>
> Heh. First of all, I am really sorry.
>
> Not only "__wait_no_timeout(tout) ?:" was wrong, I didn't bother
> to recheck this logic even after I got the "warning: the omitted
> middle operand in ?:" reports.
>
> Sedat, thanks you very much! Any chance you can try the patch below?
>
Thanks for the quick fix!
No worries. Good we catched the issue, now.
Yupp, the patch fixes the issue here.
Please, send a patch against reported tree (here: next-20130628) next time.
( Attached is the one which applied here. )
I have zero clue about that "tout-tout" and "?" but you should keep
coding-style within your patch?
...
+ __ret = __wait_no_timeout(tout) ? 0 : \
+ (__tout ?: 1);
\ <--- ((__tout) ?: 1) like below ((tout) ?: 1)
...
+ __ret = __wait_no_timeout(tout) ? 0 : ((tout) ?: 1);\
Feel free to give credits :-).
- Sedat -
> Oleg.
>
>
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -191,12 +191,8 @@ wait_queue_head_t *bit_waitqueue(void *, int);
> for (;;) { \
> __ret = prepare_to_wait_event(&wq, &__wait, state); \
> if (condition) {\
> - __ret = __wait_no_timeout(tout);\
> - if (!__ret) { \
> - __ret = __tout; \
> - if (!__ret) \
> - __ret = 1; \
> - } \
> + __ret = __wait_no_timeout(tout) ? 0 : \
> + (__tout ?: 1); \
> break; \
> } \
> \
> @@ -217,16 +213,10 @@ wait_queue_head_t *bit_waitqueue(void *, int);
> #define wait_event_common(wq, condition, state, tout) \
> ({ \
> long __ret; \
> - if (condition) {\
> - __ret = __wait_no_timeout(tout);\
> - if (!__ret) { \
> - __ret = tout; \
> - if (!__ret) \
> - __ret = 1; \
> - } \
> - } else {\
> + if (condition) \
> + __ret = __wait_no_timeout(tout) ? 0 : ((tout) ?: 1);\
> + else\
> __ret = __wait_event_common(wq, condition, state, tout);\
> - } \
> __ret; \
> })
>
>
3.10.0-rc7-next20130628-10-iniza-small.patch
Description: Binary data
Re: sched: context tracking demolishes pipe-test
On Sun, Jun 30, 2013 at 09:57:36AM +0200, Mike Galbraith wrote: > taskset -c 3 pipe-test 1 > > switch-rate > 3.10.0-master 426.4 KHz > 3.10.0-masterx591.8 Khz 1.387 (591=notgood, 426=omfg) > > 3.10.0-master3.10.0-masterx > 7.13% [k] __schedule9.58% [k] __schedule > !6.02% [.] __read_nocancel 8.25% [k] system_call > !5.82% [.] __write_nocancel 5.34% [k] > _raw_spin_lock_irqsave > !4.28% [k] system_call 4.26% [k] pipe_read > !4.13% [k] user_exit 3.53% [k] > copy_user_generic_string > 3.64% [k] _raw_spin_lock_irqsave3.52% [k] > native_sched_clock > 3.37% [k] pipe_read 3.43% [k] __switch_to > 2.72% [k] copy_user_generic_string 3.21% [.] main > 2.60% [.] main 2.96% [k] mutex_lock > 2.59% [k] native_sched_clock2.89% [k] mutex_unlock > 2.47% [k] __switch_to 2.86% [k] > sched_clock_local > 2.10% [k] mutex_unlock 2.63% [.] > __read_nocancel > 2.08% [k] sched_clock_local 2.47% [k] pipe_write > 2.05% [k] mutex_lock2.37% [k] > _raw_spin_unlock_irqrestore > 1.91% [k] pipe_write1.96% [.] > __write_nocancel > 1.89% [k] user_enter1.62% [k] vfs_write > 1.72% [k] _raw_spin_unlock_irqrestore 1.54% [k] do_sync_write > 1.51% [k] rcu_eqs_enter_common.isra.47 1.52% [k] fget_light > 1.41% [k] rcu_eqs_exit_common.isra.45 1.48% [k] fsnotify > 1.30% [k] tracesys 1.39% [k] > dequeue_task_fair > 1.23% [k] fsnotify 1.39% [k] update_curr > 1.23% [k] int_check_syscall_exit_worka 1.37% [k] do_sync_read > 1.20% [k] fget_light1.33% [.] > __GI___libc_write > 1.16% [k] vfs_write 1.29% [k] > try_to_wake_up > 1.05% [k] syscall_trace_enter 1.09% [k] > _raw_spin_lock_irq > 1.04% [k] do_sync_write 1.08% [k] > pipe_iov_copy_from_user > 1.03% [k] context_tracking_task_switch 1.05% [k] > finish_task_switch > 0.99% [k] update_curr 1.04% [k] > prepare_to_wait > Yeah, who'd have thought that putting stuff in the syscall path would've made syscalls more expensive ;-) But yeah, that's a _lot_ more expensive.. I'd not be surprised if more people would find that objectionable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: trouble building 'perf' for 3.9.7
Greetings --
I wrote:
> Anyway, this worked fine for 2.6.late, as well as 3.0 stable and 3.4
> stable. However, I wanted the improvements to 'usbip', so I switched
> to 3.9; currently I'm using 3.9.7.
>
> Using exactly the same scripts (see below), perf now fails to build:
I have to eat some of those words.
I tried switching back to 3.4, and the build still failed. I'm
mystified, as I thought I had done a full rebuild with that kernel,
but maybe I hadn't (and the build succeeded due to bits left over from
earlier kernels).
The final fix (for 3.4 -- testing with 3.9 now) was to *not* point the
perf build at the target ("staging") headers. Instead, perf finds the
sysroot headers installed as a part of the cross-compile toolchain.
This left issues with elfutils, but I changed that build step to put
them in a custom subdirectory. That way, I could configure perf to
use that location without pulling in the sanitized headers.
Sorry if anyone wasted their time chasing down my carelessness.
(Although, to be fair, 'perf' is the only package out of about 20 that
fails when I explicitly point the build at the target's "include"
directory.)
Thanks again!
Best regards,
Anthony Foiani
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: Faraday fotg210-hcd driver
On Tue, Jun 18, 2013 at 10:43:56AM -0400, Alan Stern wrote: > On Tue, 18 Jun 2013, Yuan-Hsin Chen wrote: > > > > In that case, no, you should be figuring out how to refactor and reuse > > > the EHCI code instead of copying it straight into your driver. > > > > I was trying to use ehci-platform.c, anonymous union/struct, and quirk > > flags to avoid copying EHCI code. > > But there are too big incompatibilities between fotg210/fusbh200 > > controller and EHCI. > > That's why Alan agreed that I could create a stand-alone driver for > > fusbh200 host controller. > > Since fotg210 and fusbh200 have the same issue, fotg210 hcd is > > supposed to be stand-alone. > > More details please refer to mail sequence > > http://www.spinics.net/lists/linux-usb/msg83812.html > > That's right. The patch's description mentions some of the > incompatibilities. In short, the Faraday controllers are a _very_ > noncompliant EHCI variant. The changes needed to make ehci-hcd work > with them were too invasive IMO. > > It's a shame, because so much of the code is the same. It makes you > want to go back and ask those Faraday engineers what they were thinking > of at the time. Ah, ok, that's too bad. I understand why the code can't be refactored. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] xhci: Compute last_ctx from complete set of configured endpoints.
On Mon, Jun 24, 2013 at 09:24:28AM -0700, Reilly Grant wrote: > On Mon, Jun 24, 2013 at 08:59AM -0700, Sarah Sharp wrote: > > On Tue, Jun 18, 2013 at 02:09:13PM -0700, Reilly Grant wrote: > > > > So, no, I can't accept this patch. If this fixes a real problem in > > some hardware, we'll add a quirk for that hardware. > > Thank you for the clarification. I was not aware of this addendum. > Could you forward me a link to it? The last revision I can find on the > Intel web site is from 05/2010. The xHCI architect hasn't done an official release on the Intel site for a while now. I think he's working on a bigger 1.1 release that includes all the errata over the past couple years. I think you can get the latest revision by emailing xhcisupp...@intel.com. If you don't hear back within a week or so, email me back and I'll send you a PDF. > This fixed a problem on VMware's virtual hardware. Assuming changing > behavior will not affect any other systems I will fix it based on this > information. Yes, please fix this in VMware's virtual hardware. Thanks, Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci-plat: Enable XHCI_SPURIOUS_SUCCESS quirk for xhci-plat
On Wed, Jun 26, 2013 at 09:53:34AM -0700, Sarah Sharp wrote: > On Wed, Jun 26, 2013 at 02:28:57PM +0530, George Cherian wrote: > > Synopsis xhci controllers with hci_version > 0.96 gives spurious success > > events on short packet completion. During webcam capture the > > "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. > > The same application works fine with synopsis controllers hci_version 0.96. > > It's a known issue. The xHCI 1.0 spec changed how hardware handles > short packets. The HW will notify SW of the TRB where the short packet, > and it will also give a successful status for the last TRB in a TD (the > one with the IOC flag set). On the second successful status, that > warning will be triggered in the driver. > > Software is now supposed to not assume the TD as done until it gets that > last successful status. That means we have a slight race condition, > although it should have little practical impact. This patch papers over > that issue. > > I will take this patch, but will add the note that is on my long-term > to-do list to fix this issue. Actually, since it applies to both xhci-plat and xhci-pci hosts, can you move setting this quirk into xhci_gen_setup? Sarah Sharp > > Signed-off-by: George Cherian > > --- > > drivers/usb/host/xhci-plat.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > > index 93ad67e..e63c6d3 100644 > > --- a/drivers/usb/host/xhci-plat.c > > +++ b/drivers/usb/host/xhci-plat.c > > @@ -25,6 +25,16 @@ static void xhci_plat_quirks(struct device *dev, struct > > xhci_hcd *xhci) > > * dev struct in order to setup MSI > > */ > > xhci->quirks |= XHCI_BROKEN_MSI; > > + > > + /* > > +* In some xhci controllers which follows xhci 1.0 spec gives a spurious > > +* success event after a short transfer. This quirk will ignore such > > +* spurious event. Hit this issue in synopsis xhci controllers with > > +* hci_version > 0.96 > > +*/ > > + > > + if (xhci->hci_version > 0x96) > > + xhci->quirks |= XHCI_SPURIOUS_SUCCESS; > > } > > > > /* called during probe() after chip reset completes */ > > -- > > 1.8.1.4 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jun 28 [ BISECTED: rsyslog/imklog: High CPU usage ]
On Sun, 30 Jun 2013 20:19:45 +0200, Oleg Nesterov said:
>
> Not only "__wait_no_timeout(tout) ?:" was wrong, I didn't bother
> to recheck this logic even after I got the "warning: the omitted
> middle operand in ?:" reports.
>
> Sedat, thanks you very much! Any chance you can try the patch below?
I'm not Sedat, but I had the same problem with rsyslog going nuts,
and I can confirm that the patch fixes the problem. (Had to hand-apply
it, there was some difference of opinion regarding { } on an else)
Feel free to toss on a Tested-By: if this becomes a separate commit...
pgpBPqMaPG0E2.pgp
Description: PGP signature
Re: cgroup: status-quo and userland efforts
Heya, On 29.06.2013 05:05, Tim Hockin wrote: Come on, now, Lennart. You put a lot of words in my mouth. I for sure am not going to make the PID 1 a client of another daemon. That's just wrong. If you have a daemon that is both conceptually the manager of another service and the client of that other service, then that's bad design and you will easily run into deadlocks and such. Just think about it: if you have some external daemon for managing cgroups, and you need cgroups for running external daemons, how are you going to start the external daemon for managing cgroups? Sure, you can hack around this, make that daemon special, and magic, and stuff -- or you can just not do such nonsense. There's no reason to repeat the fuckup that cgroup became in kernelspace a second time, but this time in userspace, with multiple manager daemons all with different and slightly incompatible definitions what a unit to manage actualy is... I forgot about the tautology of systemd. systemd is monolithic. systemd is certainly not monolithic for almost any definition of that term. I am not sure where you are taking that from, and I am not sure I want to discuss on that level. This just sounds like FUD you picked up somewhere and are repeating carelessly... But that's not my point. It seems pretty easy to make this cgroup management (in "native mode") a library that can have either a thin veneer of a main() function, while also being usable by systemd. The point is to solve all of the problems ONCE. I'm trying to make the case that systemd itself should be focusing on features and policies and awesome APIs. You know, getting this all right isn't easy. If you want to do things properly, then you need to propagate attribute changes between the units you manage. You also need something like a scheduler, since a number of controllers can only be configured under certain external conditions (for example: the blkio or devices controller use major/minor parameters for configuring per-device limits. Since major/minor assignments are pretty much unpredictable these days -- and users probably want to configure things with friendly and stable /dev/disk/by-id/* symlinks anyway -- this requires us to wait for devices to show up before we can configure the parameters.) Soo... you need a graph of units, where you can propagate things, and schedule things based on some execution/event queue. And the propagation and scheduling are closely intermingled. Now, that's pretty much exactly what systemd actually *is*. It implements a graph of units with a scheduler. And if you rip that part out of systemd to make this an "easy cgroup management library", then you simply turn what systemd is into a library without leaving anything. Which is just bogus. So no, if you say "seems pretty easy to make this cgroup management a library" then well, I have to disagree with you. We want to run fewer, simpler things on our systems, we want to reuse as Fewer and simpler are not compatible, unless you are losing functionality. Systemd is fewer, but NOT simpler. Oh, certainly it is. If we'd split up the cgroup fs access into separate daemon of some kind, then we'd need some kind of IPC for that, and so you have more daemons and you have some complex IPC between the processes. So yeah, the systemd approach is certainly both simpler and uses fewer daemons then your hypothetical one. much of the code as we can. You don't achieve that by running yet another daemon that does worse what systemd can anyway do simpler, easier and better. Considering this is all hypothetical, I find this to be a funny debate. My hypothetical idea is better than your hypothetical idea. Well, systemd is pretty real, and the code to do the unified cgroup management within systemd is pretty complete. systemd is certainly not hypothetical. The least you could grant us is to have a look at the final APIs we will have to offer before you already imply that systemd cannot be a valid implementation of any API people could ever agree on. Whoah, don't get defensive. I said nothing of the sort. The fact of the matter is that we do not run systemd, at least in part because of the monolithic nature. That's unlikely to change in this timescale. Oh, my. I am not sure what makes you think it is monolithic. What I said was that it would be a shame if we had to invent our own low-level cgroup daemon just because the "upstream" daemons was too tightly coupled with systemd. I have no interest to reimplement systemd as a library, just to make you happy... I am quite happy with what we already have This is supposed to be collaborative, not combative. It certainly sounds *very* differently in what you are writing. Lennart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read t
[PATCH 0/2] Support for 2013 Macbook Air
Hi Dmitry, Jiri, Please find enclosed two patches yielding support for the MacbookAir6,2. As usual, there is one HID and one Input patch. Given the closeness to the merge window, I suppose we could backport this to 3.10, unless Linus decides to wait another week. Backports should be fine back to v3.7, inclusive. Dmitry, would you care to take the patches, if Jiri is ok with that? Thanks, Henrik Henrik Rydberg (2): HID: apple: Add support for the 2013 Macbook Air Input: bcm5974 - Add support for the 2013 MacBook Air drivers/hid/hid-apple.c | 6 ++ drivers/hid/hid-core.c| 6 ++ drivers/hid/hid-ids.h | 3 +++ drivers/input/mouse/bcm5974.c | 36 ++-- 4 files changed, 49 insertions(+), 2 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] HID: apple: Add support for the 2013 Macbook Air
This patch adds keyboard support for MacbookAir6,2 as WELLSPRING8
(0x0291, 0x0292, 0x0293). The touchpad is handled in a separate
bcm5974 patch, as usual.
Cc: sta...@vger.kernel.org
Reported-and-tested-by: Brad Ford
Signed-off-by: Henrik Rydberg
---
drivers/hid/hid-apple.c | 6 ++
drivers/hid/hid-core.c | 6 ++
drivers/hid/hid-ids.h | 3 +++
3 files changed, 15 insertions(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index feae88b..c7710b5 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -524,6 +524,12 @@ static const struct hid_device_id apple_devices[] = {
.driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI),
+ .driver_data = APPLE_HAS_FN },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO),
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS),
+ .driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 264f550..402f486 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1547,6 +1547,9 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) },
@@ -2179,6 +2182,9 @@ static const struct hid_device_id hid_mouse_ignore_list[]
= {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
{ }
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 38535c9..2168885 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -135,6 +135,9 @@
#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS 0x023b
#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI 0x0255
#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO 0x0256
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI 0x0291
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0293
#define USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY 0x030a
#define USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY0x030b
#define USB_DEVICE_ID_APPLE_IRCONTROL 0x8240
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Input: bcm5974 - Add support for the 2013 MacBook Air
The June 2013 Macbook Air (13'') has a new trackpad protocol; four new
values are inserted in the header, and the mode switch is no longer
needed. This patch adds support for the new devices.
Cc: sta...@vger.kernel.org
Reported-and-tested-by: Brad Ford
Signed-off-by: Henrik Rydberg
---
drivers/input/mouse/bcm5974.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 2baff1b..4ef4d5e 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -88,6 +88,10 @@
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI 0x0259
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO 0x025a
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS 0x025b
+/* MacbookAir6,2 (unibody, June 2013) */
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI 0x0291
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0293
#define BCM5974_DEVICE(prod) { \
.match_flags = (USB_DEVICE_ID_MATCH_DEVICE |\
@@ -145,6 +149,10 @@ static const struct usb_device_id bcm5974_table[] = {
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS),
+ /* MacbookAir6,2 */
+ BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI),
+ BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_ISO),
+ BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_JIS),
/* Terminating entry */
{}
};
@@ -172,15 +180,18 @@ struct bt_data {
/* trackpad header types */
enum tp_type {
TYPE1, /* plain trackpad */
- TYPE2 /* button integrated in trackpad */
+ TYPE2, /* button integrated in trackpad */
+ TYPE3 /* additional header fields since June 2013 */
};
/* trackpad finger data offsets, le16-aligned */
#define FINGER_TYPE1 (13 * sizeof(__le16))
#define FINGER_TYPE2 (15 * sizeof(__le16))
+#define FINGER_TYPE3 (19 * sizeof(__le16))
/* trackpad button data offsets */
#define BUTTON_TYPE2 15
+#define BUTTON_TYPE3 23
/* list of device capability bits */
#define HAS_INTEGRATED_BUTTON 1
@@ -400,6 +411,19 @@ static const struct bcm5974_config bcm5974_config_table[]
= {
{ SN_COORD, -150, 6730 },
{ SN_ORIENT, -MAX_FINGER_ORIENTATION, MAX_FINGER_ORIENTATION }
},
+ {
+ USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI,
+ USB_DEVICE_ID_APPLE_WELLSPRING8_ISO,
+ USB_DEVICE_ID_APPLE_WELLSPRING8_JIS,
+ HAS_INTEGRATED_BUTTON,
+ 0, sizeof(struct bt_data),
+ 0x83, TYPE3, FINGER_TYPE3, FINGER_TYPE3 + SIZEOF_ALL_FINGERS,
+ { SN_PRESSURE, 0, 300 },
+ { SN_WIDTH, 0, 2048 },
+ { SN_COORD, -4620, 5140 },
+ { SN_COORD, -150, 6600 },
+ { SN_ORIENT, -MAX_FINGER_ORIENTATION, MAX_FINGER_ORIENTATION }
+ },
{}
};
@@ -557,6 +581,9 @@ static int report_tp_state(struct bcm5974 *dev, int size)
input_report_key(input, BTN_LEFT, ibt);
}
+ if (c->tp_type == TYPE3)
+ input_report_key(input, BTN_LEFT, dev->tp_data[BUTTON_TYPE3]);
+
input_sync(input);
return 0;
@@ -572,9 +599,14 @@ static int report_tp_state(struct bcm5974 *dev, int size)
static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
{
- char *data = kmalloc(8, GFP_KERNEL);
int retval = 0, size;
+ char *data;
+
+ /* Type 3 does not require a mode switch */
+ if (dev->cfg.tp_type == TYPE3)
+ return 0;
+ data = kmalloc(8, GFP_KERNEL);
if (!data) {
dev_err(&dev->intf->dev, "out of memory\n");
retval = -ENOMEM;
--
1.8.3.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] cpufreq: Fix cpufreq regression after suspend/resume
On 06/30/2013 10:35 PM, Toralf Förster wrote:
> On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote:
>> Toralf, can you please
>> try out the below patch and see if it improves anything? (Don't revert
>> anything,
>> just apply the below diff on a problematic kernel and see if it solves your
>> issue).
>
> applied on top of a66b2e5 - issue went away (either fixed or hidden now)
>
Cool! So here is the proper patch, with changelog added.
Regards,
Srivatsa S. Bhat
-
From: Srivatsa S. Bhat
Subject: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume
Toralf Förster reported that the cpufreq ondemand governor behaves erratically
(doesn't scale well) after a suspend/resume cycle. The problem was that the
cpufreq subsystem's idea of the cpu frequencies differed from the actual
frequencies set in the hardware after a suspend/resume cycle. Toralf bisected
the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across
suspend/resume).
Among other (harmless) things, that commit skipped the call to
cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays
an important role during resume, because it is responsible for checking if
the BIOS changed the cpu frequencies behind our back and resynchronize the
cpufreq subsystem's knowledge of the cpu frequencies, and update them
accordingly.
So, restore the call to cpufreq_update_policy() in the resume path to fix
the cpufreq regression.
Reported-by: Toralf Förster
Tested-by: Toralf Förster
Signed-off-by: Srivatsa S. Bhat
---
drivers/cpufreq/cpufreq_stats.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index fb65dec..591b6fb 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct
notifier_block *nfb,
switch (action) {
case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
cpufreq_update_policy(cpu);
break;
case CPU_DOWN_PREPARE:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Workman-devel] cgroup: status-quo and userland efforts
On Fri 28-06-13 14:01:55, Vivek Goyal wrote: > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote: [...] > > OK, so libcgroup's rules daemon will still work and place my tasks in > > appropriate cgroups? > > Do you use that daemon in practice? I am not but my users do. And that is why I care. > For user session logins, I think systemd has plans to put user > sessions in a cgroup (kind of making pam_cgroup redundant). > > Other functionality rulesengined was providing moving tasks automatically > in a cgroup based on executable name. I think that was racy and not > many people had liked it. It doesn't make sense for short lived processes, all right, but it can be useful for those that live for a long time. > IIUC, systemd can't disable access to cgroupfs from other utilities. The previous messages read otherwise. And that is why this rised the red flag at many fronts. > So most likely rulesengined should contine to work. But having both > systemd and libcgroup might not make much sense though. > > Thanks > Vivek -- 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: mmotm 2013-06-27-16-36 uploaded (wait event common)
On 06/29, valdis.kletni...@vt.edu wrote: > > On Thu, 27 Jun 2013 22:30:41 -0700, Randy Dunlap said: > > > + __ret = __wait_no_timeout(tout) ?: (tout) ?: 1; > > Was this trying to do a wait_ho_timeout(!!tout) or something? No, __wait_no_timeout() means that tout == MAX_SCHEDULE_TIMEOUT. But the logic is wrong, we should return zero in this case. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
On Sat 29-06-13 12:55:09, Dave Chinner wrote: > On Thu, Jun 27, 2013 at 04:54:11PM +0200, Michal Hocko wrote: > > On Thu 27-06-13 09:24:26, Dave Chinner wrote: > > > On Wed, Jun 26, 2013 at 10:15:09AM +0200, Michal Hocko wrote: > > > > On Tue 25-06-13 12:27:54, Dave Chinner wrote: > > > > > On Tue, Jun 18, 2013 at 03:50:25PM +0200, Michal Hocko wrote: > > > > > > And again, another hang. It looks like the inode deletion never > > > > > > finishes. The good thing is that I do not see any LRU related > > > > > > BUG_ONs > > > > > > anymore. I am going to test with the other patch in the thread. > > > > > > > > > > > > 2476 [] __wait_on_freeing_inode+0x9e/0xc0 <<< > > > > > > waiting for an inode to go away > > > > > > [] find_inode_fast+0xa1/0xc0 > > > > > > [] iget_locked+0x4f/0x180 > > > > > > [] ext4_iget+0x33/0x9f0 > > > > > > [] ext4_lookup+0xbc/0x160 > > > > > > [] lookup_real+0x20/0x60 > > > > > > [] lookup_open+0x175/0x1d0 > > > > > > [] do_last+0x2de/0x780<<< > > > > > > holds i_mutex > > > > > > [] path_openat+0xda/0x400 > > > > > > [] do_filp_open+0x43/0xa0 > > > > > > [] do_sys_open+0x160/0x1e0 > > > > > > [] sys_open+0x1c/0x20 > > > > > > [] system_call_fastpath+0x16/0x1b > > > > > > [] 0x > > > > > > > > > > I don't think this has anything to do with LRUs. > > > > > > > > I am not claiming that. It might be a timing issue which never mattered > > > > but it is strange I can reproduce this so easily and repeatedly with the > > > > shrinkers patchset applied. > > > > As I said earlier, this might be breakage in my -mm tree as well > > > > (missing some patch which didn't go via Andrew or misapplied patch). The > > > > situation is worsen by the state of linux-next which has some unrelated > > > > issues. > > > > > > > > I really do not want to delay the whole patchset just because of some > > > > problem on my side. Do you have any tree that I should try to test? > > > > > > No, I've just been testing Glauber's tree and sending patches for > > > problems back to him based on it. > > > > > > > > I won't have seen this on XFS stress testing, because it doesn't use > > > > > the VFS inode hashes for inode lookups. Given that XFS is not > > > > > triggering either problem you are seeing, that makes me think > > > > > > > > I haven't tested with xfs. > > > > > > That might be worthwhile if you can easily do that - another data > > > point indicating a hang or absence of a hang will help point us in > > > the right direction here... > > > > OK, still hanging (with inode_lru_isolate-fix.patch). It is not the same > > thing, though, as xfs seem to do lookup slightly differently. > > 12467 [] xfs_iget+0xbe/0x190 [xfs] > > [] xfs_lookup+0xe8/0x110 [xfs] > > [] xfs_vn_lookup+0x49/0x90 [xfs] > > [] lookup_real+0x20/0x60 > > [] lookup_open+0x175/0x1d0 > > [] do_last+0x2de/0x780 > > [] path_openat+0xda/0x400 > > [] do_filp_open+0x43/0xa0 > > [] do_sys_open+0x160/0x1e0 > > [] sys_open+0x1c/0x20 > > [] system_call_fastpath+0x16/0x1b > > [] 0x > > What are the full traces? Do you mean sysrq+t? It is attached. Btw. I was able to reproduce this again. The stuck processes were sitting in the same traces for more than 28 hours without any change so I do not think this is a temporal condition. Traces of all processes in the D state: 7561 [] xfs_iget+0xbe/0x190 [xfs] [] xfs_lookup+0xe8/0x110 [xfs] [] xfs_vn_lookup+0x49/0x90 [xfs] [] lookup_real+0x20/0x60 [] lookup_open+0x175/0x1d0 [] do_last+0x2de/0x780 [] path_openat+0xda/0x400 [] do_filp_open+0x43/0xa0 [] do_sys_open+0x160/0x1e0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b [] 0x 8156 [] do_last+0x2c4/0x780 [] path_openat+0xda/0x400 [] do_filp_open+0x43/0xa0 [] do_sys_open+0x160/0x1e0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b [] 0x 8913 [] do_last+0x2c4/0x780 [] path_openat+0xda/0x400 [] do_filp_open+0x43/0xa0 [] do_sys_open+0x160/0x1e0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b [] 0x 9100 [] xfs_iget+0xbe/0x190 [xfs] [] xfs_lookup+0xe8/0x110 [xfs] [] xfs_vn_lookup+0x49/0x90 [xfs] [] lookup_real+0x20/0x60 [] lookup_open+0x175/0x1d0 [] do_last+0x2de/0x780 [] path_openat+0xda/0x400 [] do_filp_open+0x43/0xa0 [] do_sys_open+0x160/0x1e0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b [] 0x 9158 [] do_last+0x2c4/0x780 [] path_openat+0xda/0x400 [] do_filp_open+0x43/0xa0 [] do_sys_open+0x160/0x1e0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b [] 0x 11247 [] do_last+0x2c4/0x780 [] path_openat+0xda/0x400 [] do_filp_open+0x43/0xa0 [] do_sys_open+0x160/0x1e0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b [] 0x 12161 [] path_lookupat+0x792/0x830 [] filename_lookup+0x33/0xd0 [] user_path_at_empty+0x7b/0xb0 [] user_path_at+0xc/0x10 [] vfs_fstatat+0x51/0xb0 [] vfs_stat+0x16/0x20 [] sys_newstat+0x1f/0x50 [] system_call_fastpath+0x16/0x1b [] 0x
Re: linux-next: Tree for Jun 28 [ BISECTED: rsyslog/imklog: High CPU usage ]
Andrew, please drop these
wait-introduce-wait_event_commonwq-condition-state-timeout.patch
wait-introduce-prepare_to_wait_event.patch
patches again. I'll send v3 although it really looks like I should
never try to touch wait.h.
On 06/29, Sedat Dilek wrote:
>
> As this all did not show me what caused the problem I started a
> git-bisect session.
>
> This revealed the following culprit commit:
>
> commit bb1f30cb7d3ba21098f0ee7e0382160ba2599a43
> "wait: introduce wait_event_common(wq, condition, state, timeout)"
Heh. First of all, I am really sorry.
Not only "__wait_no_timeout(tout) ?:" was wrong, I didn't bother
to recheck this logic even after I got the "warning: the omitted
middle operand in ?:" reports.
Sedat, thanks you very much! Any chance you can try the patch below?
Oleg.
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -191,12 +191,8 @@ wait_queue_head_t *bit_waitqueue(void *, int);
for (;;) { \
__ret = prepare_to_wait_event(&wq, &__wait, state); \
if (condition) {\
- __ret = __wait_no_timeout(tout);\
- if (!__ret) { \
- __ret = __tout; \
- if (!__ret) \
- __ret = 1; \
- } \
+ __ret = __wait_no_timeout(tout) ? 0 : \
+ (__tout ?: 1); \
break; \
} \
\
@@ -217,16 +213,10 @@ wait_queue_head_t *bit_waitqueue(void *, int);
#define wait_event_common(wq, condition, state, tout) \
({ \
long __ret; \
- if (condition) {\
- __ret = __wait_no_timeout(tout);\
- if (!__ret) { \
- __ret = tout; \
- if (!__ret) \
- __ret = 1; \
- } \
- } else {\
+ if (condition) \
+ __ret = __wait_no_timeout(tout) ? 0 : ((tout) ?: 1);\
+ else\
__ret = __wait_event_common(wq, condition, state, tout);\
- } \
__ret; \
})
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] proc: make high precision system boot time available
On 30 June 2013 16:10, Kay Sievers wrote: > On Sat, Jun 29, 2013 at 10:53 PM, Sami Kerola wrote: > >> BTW having a way to measure effect of suspend/resume could lead to a >> way to fix time time distortion. > >> Perhaps there is better alternative to fix user space programs. >> Unfortunately I do not have either knowledge, or imagination, to come >> up with any. Fix hints, ideas, and other proposal are most welcome. > > Stuff should just use: > clock_gettime(CLOCK_BOOTTIME, &ts); > > to get the time in better resolution, and with suspend time taken into > account? > > As a general note, the kmsg/printk() time in the raw kernel log is the > time of the CPU it runs on, especially during early init this time > might not be in sync across CPUs and stuff jumps event in the very > same stream on events from the kernel itself: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/clock.c#n329 Thank you Kay, The clock_gettime(CLOCK_BOOTTIME, &uptime); seems to be exactly what dmesg needs. A patch to fix dmesg wigging will be sent to util-linux maillist shortly. Perhaps the dmesg / journald time stamp difference issue will be fixed someday, but that discussion does not belong to linux-kernel mailist, so it is time to declare end of thread. -- Sami Kerola http://www.iki.fi/kerolasa/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 in 3.9.8
Many Thanks and my apologies. Richard Corbin 25532 Southwind Rd. Warrenton, MO 63383 racorbin2...@charter.net Original Message *Subject:* Re: A Bug in 3.9.8 *Date:* Sun 06/30/2013 at 11:11 AM *From:* Greg KH *To: * Richard Corbin *CC: * sta...@vger.kernel.org, linux-kernel@vger.kernel.org On Sat, Jun 29, 2013 at 04:52:47PM -0500, Richard Corbin wrote: Folks: I sent the indented text to gre...@linuxfoundation.org, inappropriately as I suspected. I got a polite automated response suggesting alternate destinations for my email. To my non-technical eyes, your addresses seemed most appropriate. "Mr. Kroah-Hartman, "Excuse me for bothering you, but I do not know where to report my problem and I found your name in http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9.8-saucy/BUILD.LOG. My name is there because it's the first commit, for some strange reason the Ubuntu build logs this, but I have nothing to do with their kernel builds. "I am running Linux Mint KDE v15, but I like to run the latest kernel. I have never had a problem before installing the latest "general release" kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ until yesterday. "After I installed v3.9.8-saucy, the system could no longer "read" cpu usage of my quad-core Intel q6600. Conky, "top", "mpstat -P ALL" all show ZERO CPU usage. Everything else is fine; it is just the reporting that is busted. "If you are the wrong person and cannot forward to correct destination, then I am sorry for wasting your time." I neglected to write that when I rebooted the identical system using v3.9.7-saucy as the kernel, the CPU usage for each core was registering non-zero values when appropriate as usual. As this is a Ubuntu-specific kernel, I suggest filing a bug in the Ubuntu bug tracking tool to help resolve this, ther's not much we in the community can do about this, sorry. best of luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
