Re: [PATCH 0/3] powerpc/powernv: Correctly detect optional OPAL calls
On 02/18/2015 05:33 AM, Stewart Smith wrote: > This series fixes three possible warnings that OPAL firmware would emit > when booting on hardware/simulator that didn't support certain functionality. > > The correct thing for Linux to do is to detect firmware capability > by using the OPAL_CHECK_TOKEN call or examining device tree. In the case > of these three warnings, it was OPAL_CHECK_TOKEN. Stewart, Sorry.. I couldn't makeout any difference between this patchset and earlier patchset which I had Acked except the update in cover page... (sub: Silence "OPAL called with invalid token" errors ). Did I miss anything ? -Vasant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport
Ping. On Wed, Feb 4, 2015 at 11:14 PM, Marek Belisko wrote: > This patches adding support for twl4030_madc_battery to use twl4030_madc iio > framework + DT support. > Patches was tested on gta04 board. twl4030_madc_battery driver is converted in > first patch to iio consumer and in next patches is added support for > devicetree > + some small fixes for module autoloading. > > Changes from V2: > - fix property names > - add MODULE_DEVICE_TABLE and MODULE_ALIAS > > Changes from V1: > - use iio_read_channel_processed instead iio_read_channel_processed > - convert probe to use devm_ as part of adding error handling for iio > - free iio channels on error and on module removal > > [1] - https://lkml.org/lkml/2014/2/26/482dd > > Marek Belisko (6): > power: twl4030-madc-battery: Convert to iio consumer. > power: twl4030_madc_battery: Add device tree support > Documentation: DT: Document twl4030-madc-battery bindings > ARM: dts: omap3-gta04: Add battery support > power: twl4030_madc_battery: Add of_twl4030_madc_match to > MODULE_DEVICE_TABLE > power: twl4030_madc_battery: Add missing MODULE_ALIAS > > .../bindings/power_supply/twl4030_madc_battery.txt | 43 + > arch/arm/boot/dts/omap3-gta04.dtsi | 30 > drivers/power/twl4030_madc_battery.c | 183 > + > 3 files changed, 221 insertions(+), 35 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > > -- > 1.9.1 > -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: [PATCH] lib/kstrtox.c Stop parsing integer on overflow
On Tue, Feb 17, 2015 at 04:17:24PM -0800, Andrew Morton wrote:
> ?
>
> Begin forwarded message:
>
> Date: Mon, 16 Feb 2015 10:48:50 -0800
> From: Anshul Garg
> To: linux-kernel@vger.kernel.org
> Cc: aksgarg1...@gmail.com, anshu...@samsung.com, torva...@linux-foundation.org
> Subject: [PATCH] lib/kstrtox.c Stop parsing integer on overflow
>
>
> From: Anshul Garg
>
> While converting string representation to integer
> break the loop if overflow is detected.
>
> Signed-off-by: Anshul Garg
> ---
> lib/kstrtox.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
> index ec8da78..6f30209 100644
> --- a/lib/kstrtox.c
> +++ b/lib/kstrtox.c
> @@ -70,8 +70,10 @@ unsigned int _parse_integer(const char *s, unsigned int
> base, unsigned long long
>* it in the max base we support (16)
>*/
> if (unlikely(res & (~0ull << 60))) {
> - if (res > div_u64(ULLONG_MAX - val, base))
> + if (res > div_u64(ULLONG_MAX - val, base)) {
> overflow = 1;
> + break;
> + }
> }
> res = res * base + val;
> rv++;
The _notion_ of a patch is OK if you want EVERY simple_strtoull() call
to stop parsing past overflow right now. It SHOULD have done so from day 1,
but it doesn't do that.
When I wrote kstrto*() code I deliberatedly didn't break this bug
because of the sheer number of call sites.
If you are OK with changing bug-for-bug compatibility,
then patch simply need to delete overflow detection code.
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] fs: record task name which froze superblock
Freezing and thawing are separate system calls, task which is supposed
to thaw filesystem/superblock can disappear due to crash or not thaw
due to a bug. Record at least task name (we can't take task_struct
reference) to make support engineer's life easier.
Hopefully 16 bytes per superblock isn't much.
Signed-off-by: Alexey Dobriyan
---
fs/block_dev.c | 12
fs/ioctl.c | 22 --
fs/super.c |2 ++
include/linux/fs.h |2 ++
4 files changed, 28 insertions(+), 10 deletions(-)
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -227,9 +227,11 @@ struct super_block *freeze_bdev(struct block_device *bdev)
sb = get_active_super(bdev);
if (!sb)
goto out;
- if (sb->s_op->freeze_super)
+ if (sb->s_op->freeze_super) {
error = sb->s_op->freeze_super(sb);
- else
+ if (error == 0)
+ get_task_comm(sb->s_writers.freeze_comm, current);
+ } else
error = freeze_super(sb);
if (error) {
deactivate_super(sb);
@@ -267,9 +269,11 @@ int thaw_bdev(struct block_device *bdev, struct
super_block *sb)
if (!sb)
goto out;
- if (sb->s_op->thaw_super)
+ if (sb->s_op->thaw_super) {
error = sb->s_op->thaw_super(sb);
- else
+ if (error == 0)
+ memset(sb->s_writers.freeze_comm, 0, TASK_COMM_LEN);
+ } else
error = thaw_super(sb);
if (error) {
bdev->bd_fsfreeze_count++;
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd, struct file
*filp,
static int ioctl_fsfreeze(struct file *filp)
{
struct super_block *sb = file_inode(filp)->i_sb;
+ int rv;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
return -EOPNOTSUPP;
/* Freeze */
- if (sb->s_op->freeze_super)
- return sb->s_op->freeze_super(sb);
- return freeze_super(sb);
+ if (sb->s_op->freeze_super) {
+ rv = sb->s_op->freeze_super(sb);
+ if (rv == 0)
+ get_task_comm(sb->s_writers.freeze_comm, current);
+ } else
+ rv = freeze_super(sb);
+ return rv;
}
static int ioctl_fsthaw(struct file *filp)
{
struct super_block *sb = file_inode(filp)->i_sb;
+ int rv;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
/* Thaw */
- if (sb->s_op->thaw_super)
- return sb->s_op->thaw_super(sb);
- return thaw_super(sb);
+ if (sb->s_op->thaw_super) {
+ rv = sb->s_op->thaw_super(sb);
+ if (rv == 0)
+ memset(sb->s_writers.freeze_comm, 0, TASK_COMM_LEN);
+ } else
+ rv = thaw_super(sb);
+ return rv;
}
/*
--- a/fs/super.c
+++ b/fs/super.c
@@ -1355,6 +1355,7 @@ int freeze_super(struct super_block *sb)
* sees write activity when frozen is set to SB_FREEZE_COMPLETE.
*/
sb->s_writers.frozen = SB_FREEZE_COMPLETE;
+ get_task_comm(sb->s_writers.freeze_comm, current);
up_write(>s_umount);
return 0;
}
@@ -1391,6 +1392,7 @@ int thaw_super(struct super_block *sb)
out:
sb->s_writers.frozen = SB_UNFROZEN;
+ memset(sb->s_writers.freeze_comm, 0, TASK_COMM_LEN);
smp_wmb();
wake_up(>s_writers.wait_unfrozen);
deactivate_locked_super(sb);
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1221,6 +1221,8 @@ struct sb_writers {
int frozen; /* Is sb frozen? */
wait_queue_head_t wait_unfrozen; /* queue for waiting for
sb to be thawed */
+ /* who froze superblock and forgot to thaw it */
+ charfreeze_comm[16];
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map lock_map[SB_FREEZE_LEVELS];
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: record task name which froze superblock
On Mon, Feb 16, 2015 at 10:38:52AM +0100, Jan Kara wrote:
> On Sat 14-02-15 21:55:24, Alexey Dobriyan wrote:
> > Freezing and thawing are separate system calls, task which is supposed
> > to thaw filesystem/superblock can disappear due to crash or not thaw
> > due to a bug. Record at least task name (we can't take task_struct
> > reference) to make support engineer's life easier.
> >
> > Hopefully 16 bytes per superblock isn't much.
> >
> > P.S.: Cc'ing GFS2 people just in case they want to correct
> > my understanding of GFS2 having async freeze code.
> >
> > Signed-off-by: Alexey Dobriyan
> Hum, and when do you show the task name? Or do you expect that customer
> takes a crashdump and support just finds it in memory?
Yeah, having at least something in crashdump is fine.
> > --- a/fs/ioctl.c
> > +++ b/fs/ioctl.c
> > @@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd, struct file
> > *filp,
> > static int ioctl_fsfreeze(struct file *filp)
> > {
> > struct super_block *sb = file_inode(filp)->i_sb;
> > + int rv;
> >
> > if (!capable(CAP_SYS_ADMIN))
> > return -EPERM;
> > @@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
> > return -EOPNOTSUPP;
> >
> > /* Freeze */
> > - if (sb->s_op->freeze_super)
> > - return sb->s_op->freeze_super(sb);
> > - return freeze_super(sb);
> > + if (sb->s_op->freeze_super) {
> > + rv = sb->s_op->freeze_super(sb);
> > + if (rv == 0)
> > + get_task_comm(sb->s_writers.freeze_comm, current);
> > + } else
> > + rv = freeze_super(sb);
> > + return rv;
> Why don't you just set the name in ioctl_fsfreeze() in both cases?
There are users of freeze_super() in GFS2 unless I'm misreading code.
> Also you seem to be missing freezing / thawing in freeze/thaw_bdev()
> functions.
You are correct. Resending patch (blockdev freezing tested with XFS).
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1221,6 +1221,8 @@ struct sb_writers {
> > int frozen; /* Is sb frozen? */
> > wait_queue_head_t wait_unfrozen; /* queue for waiting for
> >sb to be thawed */
> > + /* who froze superblock */
> > + charfreeze_comm[16];
> Here should be TASK_COMM_LEN, shouldn't it?
It will pull sched.h, dunno if we care about headers anymore.
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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, boot: Allow 64bit EFI kernel to be loaded above 4G
On Wed, Feb 4, 2015 at 10:09 PM, Dave Young wrote: > On 02/04/15 at 09:25pm, Yinghai Lu wrote: >> On Wed, Feb 4, 2015 at 7:25 PM, Dave Young wrote: >> >> After this patch, could use patched grub2-x86_64.efi to place >> >> kernel/boot_params/cmd_line/initrd all above 4G and execute the kernel >> >> above 4G. >> > >> > Can you share the grub2 patch for testing? >> >> Please check attached 5 patches. last one is for debug purpose. >> >> You need to apply them on top of >> >> git://git.savannah.gnu.org/grub.git >> >> plus >> http://pkgs.fedoraproject.org/cgit/grub2.git/plain/0091-Add-support-for-linuxefi.patch > FYI, I put those patches together with patches that extend grub2 to load kernel/initrd above 4G into github tree. https://github.com/yhlu/grub2.git Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G
On Tue, Feb 10, 2015 at 10:11 PM, Baoquan He wrote: > Hi Yinghai, > > Could you please help to have a look at a problem which I encountered? > > I am trying to make kaslr randomize on both kernel physical and virtual > address separately. Now the separate randomization has been done, > kernel physical address can be randomized to [16M, 4G], and virtual > address can be randomzed to [16M, 1G]. Below is the post. > http://thread.gmane.org/gmane.linux.kernel/1870532 > > Now I am trying to make kernel physical address randomize anywhere, not > limited to below 4G. As you know in arch/x86/boot/compressed/head_64.S a > identity mapping of 0~4G has been built, for address above 4G I added an > IDT and #PF handler. Then I hardcoded the output address of > choose_kernel_location as 5G, the #PF handler worked, however it will > reboot in arch/x86/kernel/head_64.S. For 64bit, I'd like to see bootloader could load kernel to random hw address. otherwise you will need to set another ident mapping for new range. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
W dniu 17.02.2015 o 22:02, Ruslan Bilovol pisze: Hi Andrzej, On Mon, Feb 16, 2015 at 10:07 AM, Andrzej Pietrasiewicz wrote: W dniu 15.02.2015 o 23:43, Ruslan Bilovol pisze: In my opinion all things which you have described are working out-of-box when you use configfs interface. It's mostly ready so you may create equivalent of most legacy gadgets (apart from printer and tcm) and just bind from one udc to another whenever you want. It's because legacy gadgets are easy to use and usually don't need any userspace-side configuration. Are there any plans to remove legacy drivers in the future? I'm not going to express strong opinions here, but their name implies that this can happen, some time in the future. And I also think it will not happen before the userspace part (libusbg, gt, gadgetd etc) is mature enough. My personal opinion in that matter is that it will take at least a couple of years to remove legacy gadgets entirely. OK, so it looks like there is a sense even to add new gadget/functions with legacy support I'm not sure what you mean exactly. For sure legacy gadgets are supported as long as they are a part of the mainline kernel. So any changes you make to the kernel must not affect the legacy gadgets, or you need to modify the legacy gadgets too and have them working. But adding new legacy-style gadgets is a completely different story. IMHO you need a _very_ good reason to succeed, but I remember Felipe expressing an opinion that chances or merging another legacy gadget were zero. AP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clocksource: whitelist asm9260_timer driver for ARM
On 02/10/2015 07:57 AM, Oleksij Rempel wrote: For now it is easier to allow only tested platforms, instead of fighting with different platform specific issues. This patch is fixing compile error on ARCH=SPARC and SPARC64: Building sparc64:allmodconfig ... failed -- Error log: drivers/built-in.o: In function `asm9260_timer_init': asm9260_timer.c:(.init.text+0x60d4): undefined reference to `of_io_request_and_map' Tested-by: Guenter Roeck Reported-by: Guenter Roeck Signed-off-by: Oleksij Rempel The problem solved by this patch has affected linux-next for almost a month, the problem is now in mainline, yet I have not seen feedback from anyone about it. Did the patch get lost, or is there some problem with it ? Thanks, Guenter --- drivers/clocksource/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index bfaaae4..39d5c11 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -231,7 +231,7 @@ config CLKSRC_MIPS_GIC config ASM9260_TIMER bool "Alphascale ASM9260 timer driver" - depends on GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS && ARM select CLKSRC_MMIO select CLKSRC_OF default y if MACH_ASM9260 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pty: BREAK for pseudoterminals
On Tue, 17 Feb 2015 14:03:58 -0500
Peter Hurley wrote:
> On 02/16/2015 08:04 AM, Peter Hurley wrote:
> > On 02/05/2015 02:11 PM, Nan Li wrote:
> >> This will greatly enhance the usefulness of QEMU virtual serial ports,
> >> because the Linux kernel interprets a break on the serial console as a
> >> SysRq, but there is currently no way to pass this signal over a
> >> pseudo-terminal. This patch will work for transmitting BREAK from master
> >> to slave through pseudo-terminal.
> >
> > pty is an IPC mechanism, not a virtualization driver.
> >
> > Those programs that know they're consuming from a slave pty may not
> > have bothered to set termios for BREAKs, and may not be prepared
> > for NULLs in the input stream.
>
> I'm not even seeing how this works as advertised.
>
> In QEMU, the *master* end is the source/sink for the guest VM, while the
> *slave* pty is sink/source for the host. Like this:
Yes, you're totally right. This patch implements break handling on the
"wrong" side of the pty pair. I think you have already pointed this
out in one of the previous mails, and we're waiting for a patch that
implements it on the slave side.
Regards,
Petr Tesarik
> Host <--> slave pty <===> master pty <--> qemu <==> emulated serial
> port
>
> So this patch enables the guest VM to transmit BREAK to the host.
> Why is that useful?
>
> Regards,
> Peter Hurley
>
> >> Signed-off-by: Nan Li
> >> ---
> >> drivers/tty/pty.c | 19 +++
> >> 1 file changed, 19 insertions(+)
> >>
> >> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> >> index e72ee62..ac8893a 100644
> >> --- a/drivers/tty/pty.c
> >> +++ b/drivers/tty/pty.c
> >> @@ -31,6 +31,7 @@
> >> static struct tty_driver *ptm_driver;
> >> static struct tty_driver *pts_driver;
> >> static DEFINE_MUTEX(devpts_mutex);
> >> +#define BREAK_STRING '\0'
> >> #endif
> >>
> >> static void pty_close(struct tty_struct *tty, struct file *filp)
> >> @@ -674,6 +675,23 @@ static void pty_unix98_shutdown(struct
> >> tty_struct *tty) devpts_kill_index(tty->driver_data, tty->index);
> >> }
> >>
> >> +static int pty_unix98_break_ctl(struct tty_struct *tty, int
> >> break_state) +{
> >> + int c;
> >> + struct tty_struct *to = tty->link;
> >> +
> >> + if (break_state) {
> >> + /* Stuff the break data into the input queue of
> >> the other end */
> >> + c = tty_insert_flip_char(to->port, BREAK_STRING,
> >> TTY_BREAK);
> >> + /* And shovel */
> >> + if (c)
> >> + tty_flip_buffer_push(to->port);
> >> + else
> >> + return -ENOMEM;
> >> + }
> >> + return 0;
> >> +}
> >> +
> >> static const struct tty_operations ptm_unix98_ops = {
> >>.lookup = ptm_unix98_lookup,
> >>.install = pty_unix98_install,
> >> @@ -686,6 +704,7 @@ static const struct tty_operations
> >> ptm_unix98_ops = { .chars_in_buffer = pty_chars_in_buffer,
> >>.unthrottle = pty_unthrottle,
> >>.ioctl = pty_unix98_ioctl,
> >> + .break_ctl = pty_unix98_break_ctl,
> >>.resize = pty_resize,
> >>.shutdown = pty_unix98_shutdown,
> >>.cleanup = pty_cleanup
> >>
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/13] xen: move static e820 map to global scope
Instead of using a function local static e820 map in xen_memory_setup()
and calling various functions in the same source with the map as a
parameter use a map directly accessible by all functions in the source.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 96 +++-
1 file changed, 49 insertions(+), 47 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index adad417..ab6c36e 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -38,6 +38,10 @@ struct xen_memory_region
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
/* Number of pages released from the initial allocation. */
unsigned long xen_released_pages;
+/* E820 map used during setting up memory. */
+static struct e820entry xen_e820_map[E820MAX] __initdata;
+static u32 xen_e820_map_entries __initdata;
+
/*
* Buffer used to remap identity mapped pages. We only need the virtual space.
* The physical page behind this address is remapped as needed to different
@@ -164,15 +168,13 @@ void __init xen_inv_extra_mem(void)
* This function updates min_pfn with the pfn found and returns
* the size of that range or zero if not found.
*/
-static unsigned long __init xen_find_pfn_range(
- const struct e820entry *list, size_t map_size,
- unsigned long *min_pfn)
+static unsigned long __init xen_find_pfn_range(unsigned long *min_pfn)
{
- const struct e820entry *entry;
+ const struct e820entry *entry = xen_e820_map;
unsigned int i;
unsigned long done = 0;
- for (i = 0, entry = list; i < map_size; i++, entry++) {
+ for (i = 0; i < xen_e820_map_entries; i++, entry++) {
unsigned long s_pfn;
unsigned long e_pfn;
@@ -356,9 +358,9 @@ static void __init xen_do_set_identity_and_remap_chunk(
* to Xen and not remapped.
*/
static unsigned long __init xen_set_identity_and_remap_chunk(
-const struct e820entry *list, size_t map_size, unsigned long start_pfn,
- unsigned long end_pfn, unsigned long nr_pages, unsigned long remap_pfn,
- unsigned long *released, unsigned long *remapped)
+ unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages,
+ unsigned long remap_pfn, unsigned long *released,
+ unsigned long *remapped)
{
unsigned long pfn;
unsigned long i = 0;
@@ -379,8 +381,7 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
if (cur_pfn + size > nr_pages)
size = nr_pages - cur_pfn;
- remap_range_size = xen_find_pfn_range(list, map_size,
- _pfn);
+ remap_range_size = xen_find_pfn_range(_pfn);
if (!remap_range_size) {
pr_warning("Unable to find available pfn range, not
remapping identity pages\n");
xen_set_identity_and_release_chunk(cur_pfn,
@@ -411,13 +412,12 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
return remap_pfn;
}
-static void __init xen_set_identity_and_remap(
- const struct e820entry *list, size_t map_size, unsigned long nr_pages,
- unsigned long *released, unsigned long *remapped)
+static void __init xen_set_identity_and_remap(unsigned long nr_pages,
+ unsigned long *released, unsigned long *remapped)
{
phys_addr_t start = 0;
unsigned long last_pfn = nr_pages;
- const struct e820entry *entry;
+ const struct e820entry *entry = xen_e820_map;
unsigned long num_released = 0;
unsigned long num_remapped = 0;
int i;
@@ -433,9 +433,9 @@ static void __init xen_set_identity_and_remap(
* example) the DMI tables in a reserved region that begins on
* a non-page boundary.
*/
- for (i = 0, entry = list; i < map_size; i++, entry++) {
+ for (i = 0; i < xen_e820_map_entries; i++, entry++) {
phys_addr_t end = entry->addr + entry->size;
- if (entry->type == E820_RAM || i == map_size - 1) {
+ if (entry->type == E820_RAM || i == xen_e820_map_entries - 1) {
unsigned long start_pfn = PFN_DOWN(start);
unsigned long end_pfn = PFN_UP(end);
@@ -444,9 +444,9 @@ static void __init xen_set_identity_and_remap(
if (start_pfn < end_pfn)
last_pfn = xen_set_identity_and_remap_chunk(
- list, map_size, start_pfn,
- end_pfn, nr_pages, last_pfn,
- _released, _remapped);
+ start_pfn, end_pfn, nr_pages,
+ last_pfn, _released,
+ _remapped);
start =
Re: [PATCH] led/led-class: Handle LEDs with the same name
Hi On Wed, Feb 18, 2015 at 2:36 AM, Bryan Wu wrote: >> > > I got it. In this case we need to give the leds device a unique name. > Go back to your patch, you're adding 0, 1 at the end of the name of > leds. It's better like GPIO I think you can pick up value of > leds device node and put it in front of the name of leds. like > /sys/class/leds/3004.red and /sys/class/leds/4004.red. Hmmm That will not solve the issue for every device. If I had a mmio, the gpio would be located at /sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio and /sys/devices/pci:00/:00:06.0/:01:00.0/3004.gpio Also it could be the case where the gpio is not memory mapped, then it would be something like: /sys/devices/pci:00/:00:05.0/:01:00.0/gpio and /sys/devices/pci:00/:00:06.0/:01:00.0/gpio And at any case we should respect the old api, we can only rename the second device, not the first one. What is your concern about the initial proposal? What about NAME_dup0 instead of NAME_0? We could throw a dev_info(), so the system developer will have a chance to fix it (if he can) and the user to ignore it safely. Thanks! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] dmaengine updates
Hello Linus, Here are the dmaengine contributions for 3.20. The last 8 commits had to be rebased as we had a regression so had to drop the offending commit. This update brings: - the big cleanup up by Maxime for device control and slave capabilities. This makes the API much cleaner. - new IMG MDC driver by Andrew - new Renesas R-Car Gen2 DMA Controller driver by Laurent along with bunch of fixes on rcar drivers - odd fixes and updates spread over driver The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git for-linus for you to fetch changes up to 88987d2c7534a0269f567fb101e6d71a08f0f01d: dmaengine: pl330: add DMA_PAUSE feature (2015-02-16 09:33:36 +0530) Addy Ke (1): dmaengine: pl330: fix bug that cause start the same descs in cyclic Andrew Bresticker (2): dmaengine: Add binding document for IMG MDC dmaengine: Add driver for IMG MDC Andy Shevchenko (6): dmaengine: dw: provide DMA capabilities dmaengine: dw: update MAINTAINERS file dmatest: fix indentation dmatest: move src_off, dst_off, len inside loop dmaengine: dw: amend description of dma_dev field dmaengine: dw: define DW_DMA_MAX_NR_MASTERS Arnd Bergmann (4): dmaengine: k3: fix duplicate function definition dmaengine: mmp-tdma: don't include mach/regs-icu.h dmaengine: mmp-tdma: fix terminate_all return code dmaengine: coh901318: fix function return types build warnings Asaf Vertz (1): dmaengine: imx-sdma: fix indentation Cyrille Pitchen (1): dmaengine: at_xdmac: wait for in-progress transaction to complete after pausing a channel Dan Carpenter (1): dmaengine: s3c24xx: missing unlock on an error path Dave Jiang (2): dmaengine: ioatdma: PQ err descriptors should callback with err results ioatdma: Adding support for BDX-DE ioatdma. Fabio Estevam (4): dmaengine: mxs-dma: Declare slave capabilities for the generic code dmaengine: imx-sdma: Declare slave capabilities for the generic code dmaengine: imx-sdma: Use devm functions dmaengine: imx-sdma: Return a proper error code in platform_get_irq() Jürg Billeter (1): dmaengine: rcar-dmac: Handle hardware descriptor allocation failure Kevin Hao (2): dmaengine: fsldma: declare slave capabilities for the generic code dmaengine: fsldma: remove the unused variable Krzysztof Kozlowski (1): dmaengine: k3: Fix duplicated function name and allmodconfig build Kuninori Morimoto (3): dmaengine: rcar-hpbdma: fixup WARNING of slave caps retrieval dmaengine: rcar-hpbdma: tidyup residue_granularity dmaengine: shdmac: fixup WARNING of slave caps retrieval Lad, Prabhakar (1): dmaenegine: edma: fix sparse warnings Laurent Pinchart (13): dmaengine: Add 16 bytes, 32 bytes and 64 bytes bus widths dmaengine: rcar-dmac: Remove duplicate sentence from DT bindings dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC) driver dmaengine: rcar-dmac: Implement support for hardware descriptor lists dmaengine: rcar-dmac: Cache hardware descriptors memory dmaengine: Move dma_get_slave_caps() implementation to dmaengine.c dmaengine: Add dma_get_slave_caps() inline stub when !CONFIG_DMA_ENGINE dmaengine: rcar-dmac: Fix uninitialized variable usage dmaengine: rcar-dmac: Fix spinlock issues in interrupt dmaengine: rcar-dmac: Fix oops due to unintialized list in error ISR dmaengine: rcar-dmac: Allocate hardware descriptors with DMAC device dmaengine: rcar-dmac: Work around descriptor mode IOMMU errata dmaengine: rcar-dmac: Disable channel 0 when using IOMMU Ludovic Desroches (6): dmaengine: at_xdmac: split device_control dmaengine: at_xdmac: Declare slave capabilities for the generic code dmaengine: at_hdmac: declare slave capabilities dmaengine: at_xdmac: introduce save_cc field dmaengine: at_xdmac: simplify channel configuration stuff dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers Maxime Ripard (60): crypto: ux500: Use dmaengine_terminate_all API dmaengine: Make the destination abbreviation coherent dmaengine: Rework dma_chan_get dmaengine: Make channel allocation callbacks optional dmaengine: Introduce a device_config callback dmaengine: split out pause/resume operations from device_control dmaengine: Add device_terminate_all callback dmaengine: Remove the need to declare device_control dmaengine: Create a generic dma_slave_caps callback dmaengine: pl08x: Split device_control dmaengine: hdmac: Split device_control dmaengine: bcm2835: Split device_control dmaengine: coh901318: Split
[PATCH 01/13] xen: sync with xen header
Use the newest header from the xen tree to get some new structure
layouts.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/interface.h | 96
1 file changed, 87 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h
index 3400dba..3b88eea 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -3,12 +3,38 @@
*
* Guest OS interface to x86 Xen.
*
- * Copyright (c) 2004, K A Fraser
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2004-2006, K A Fraser
*/
#ifndef _ASM_X86_XEN_INTERFACE_H
#define _ASM_X86_XEN_INTERFACE_H
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument.
+ * XEN_GUEST_HANDLE_PARAM and XEN_GUEST_HANDLE are the same on X86 but
+ * they might not be on other architectures.
+ */
#ifdef __XEN__
#define __DEFINE_GUEST_HANDLE(name, type) \
typedef struct { type *p; } __guest_handle_ ## name
@@ -88,13 +114,16 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
* start of the GDT because some stupid OSes export hard-coded selector values
* in their ABI. These hard-coded values are always near the start of the GDT,
* so Xen places itself out of the way, at the far end of the GDT.
+ *
+ * NB The LDT is set using the MMUEXT_SET_LDT op of HYPERVISOR_mmuext_op
*/
#define FIRST_RESERVED_GDT_PAGE 14
#define FIRST_RESERVED_GDT_BYTE (FIRST_RESERVED_GDT_PAGE * 4096)
#define FIRST_RESERVED_GDT_ENTRY (FIRST_RESERVED_GDT_BYTE / 8)
/*
- * Send an array of these to HYPERVISOR_set_trap_table()
+ * Send an array of these to HYPERVISOR_set_trap_table().
+ * Terminate the array with a sentinel entry, with traps[].address==0.
* The privilege level specifies which modes may enter a trap via a software
* interrupt. On x86/64, since rings 1 and 2 are unavailable, we allocate
* privilege levels as follows:
@@ -118,10 +147,41 @@ struct trap_info {
DEFINE_GUEST_HANDLE_STRUCT(trap_info);
struct arch_shared_info {
-unsigned long max_pfn; /* max pfn that appears in table */
-/* Frame containing list of mfns containing list of mfns containing p2m. */
-unsigned long pfn_to_mfn_frame_list_list;
-unsigned long nmi_reason;
+ /*
+* Number of valid entries in the p2m table(s) anchored at
+* pfn_to_mfn_frame_list_list and/or p2m_vaddr.
+*/
+ unsigned long max_pfn;
+ /*
+* Frame containing list of mfns containing list of mfns containing p2m.
+* A value of 0 indicates it has not yet been set up, ~0 indicates it
+* has been set to invalid e.g. due to the p2m being too large for the
+* 3-level p2m tree. In this case the linear mapper p2m list anchored
+* at p2m_vaddr is to be used.
+*/
+ xen_pfn_t pfn_to_mfn_frame_list_list;
+ unsigned long nmi_reason;
+ /*
+* Following three fields are valid if p2m_cr3 contains a value
+* different from 0.
+* p2m_cr3 is the root of the address space where p2m_vaddr is valid.
+* p2m_cr3 is in the same format as a cr3 value in the vcpu register
+* state and holds the folded machine frame number (via xen_pfn_to_cr3)
+* of a L3 or L4 page table.
+* p2m_vaddr holds the virtual address of the linear p2m list. All
+* entries in the range [0...max_pfn[ are accessible via this pointer.
+* p2m_generation will be incremented by the guest before and after each
+* change of the mappings of the p2m list. p2m_generation starts at 0
+* and a value with the least significant bit set indicates that a
+* mapping update is in progress. This allows guest external software
+* (e.g. in Dom0) to verify that read mappings
[PATCH 03/13] xen: eliminate scalability issues from initial mapping setup
Direct Xen to place the initial P->M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
restriction on the size of the initial mapping limits the amount
of memory a domain can be handed initially.
As the initial P->M table is copied rather early during boot to
domain private memory and it's initial virtual mapping is dropped,
the easiest way to avoid virtual address conflicts with other
addresses in the kernel is to use a user address area for the
virtual address of the initial P->M table. This allows us to just
throw away the page tables of the initial mapping after the copy
without having to care about address invalidation.
It should be noted that this patch won't enable a pv-domain to USE
more than 512 GB of RAM. It just enables it to be started with a
P->M table covering more memory. This is especially important for
being able to boot a Dom0 on a system with more than 512 GB memory.
Signed-off-by: Juergen Gross
Based-on-patch-by: Jan Beulich
---
arch/x86/xen/mmu.c | 126
arch/x86/xen/setup.c| 67 ++---
arch/x86/xen/xen-head.S | 2 +
3 files changed, 156 insertions(+), 39 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index adca9e2..1ca5197 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1114,6 +1114,77 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
xen_mc_flush();
}
+/*
+ * Make a page range writeable and free it.
+ */
+static void __init xen_free_ro_pages(unsigned long paddr, unsigned long size)
+{
+ void *vaddr = __va(paddr);
+ void *vaddr_end = vaddr + size;
+
+ for (; vaddr < vaddr_end; vaddr += PAGE_SIZE)
+ make_lowmem_page_readwrite(vaddr);
+
+ memblock_free(paddr, size);
+}
+
+static void __init xen_cleanmfnmap_free_pgtbl(void *pgtbl)
+{
+ unsigned long pa = __pa(pgtbl) & PHYSICAL_PAGE_MASK;
+
+ ClearPagePinned(virt_to_page(__va(pa)));
+ xen_free_ro_pages(pa, PAGE_SIZE);
+}
+
+/*
+ * Since it is well isolated we can (and since it is perhaps large we should)
+ * also free the page tables mapping the initial P->M table.
+ */
+static void __init xen_cleanmfnmap(unsigned long vaddr)
+{
+ unsigned long va = vaddr & PMD_MASK;
+ unsigned long pa;
+ pgd_t *pgd = pgd_offset_k(va);
+ pud_t *pud_page = pud_offset(pgd, 0);
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+ unsigned int i;
+
+ set_pgd(pgd, __pgd(0));
+ do {
+ pud = pud_page + pud_index(va);
+ if (pud_none(*pud)) {
+ va += PUD_SIZE;
+ } else if (pud_large(*pud)) {
+ pa = pud_val(*pud) & PHYSICAL_PAGE_MASK;
+ xen_free_ro_pages(pa, PUD_SIZE);
+ va += PUD_SIZE;
+ } else {
+ pmd = pmd_offset(pud, va);
+ if (pmd_large(*pmd)) {
+ pa = pmd_val(*pmd) & PHYSICAL_PAGE_MASK;
+ xen_free_ro_pages(pa, PMD_SIZE);
+ } else if (!pmd_none(*pmd)) {
+ pte = pte_offset_kernel(pmd, va);
+ for (i = 0; i < PTRS_PER_PTE; ++i) {
+ if (pte_none(pte[i]))
+ break;
+ pa = pte_pfn(pte[i]) << PAGE_SHIFT;
+ xen_free_ro_pages(pa, PAGE_SIZE);
+ }
+ xen_cleanmfnmap_free_pgtbl(pte);
+ }
+ va += PMD_SIZE;
+ if (pmd_index(va))
+ continue;
+ xen_cleanmfnmap_free_pgtbl(pmd);
+ }
+
+ } while (pud_index(va) || pmd_index(va));
+ xen_cleanmfnmap_free_pgtbl(pud_page);
+}
+
static void __init xen_pagetable_p2m_free(void)
{
unsigned long size;
@@ -1128,18 +1199,25 @@ static void __init xen_pagetable_p2m_free(void)
/* using __ka address and sticking INVALID_P2M_ENTRY! */
memset((void *)xen_start_info->mfn_list, 0xff, size);
- /* We should be in __ka space. */
- BUG_ON(xen_start_info->mfn_list < __START_KERNEL_map);
addr = xen_start_info->mfn_list;
- /* We roundup to the PMD, which means that if anybody at this stage is
-* using the __ka address of xen_start_info or
xen_start_info->shared_info
-* they are in going to crash. Fortunatly we have already revectored
-* in xen_setup_kernel_pagetable and in xen_setup_shared_info. */
+ /*
+* We could be in __ka space.
+* We roundup to the PMD, which means that if anybody at this stage is
+* using the __ka address of xen_start_info or
+*
[PATCH 07/13] xen: find unused contiguous memory area
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve it at once as this will be
required to be done in any case.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 34 ++
arch/x86/xen/xen-ops.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a0af554..9c49d71 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -732,6 +732,40 @@ void __init xen_add_reserved_area(phys_addr_t start,
phys_addr_t size,
}
/*
+ * Find a free area in physical memory not yet reserved and compliant with
+ * E820 map.
+ * Used to relocate pre-allocated areas like initrd or p2m list which are in
+ * conflict with the to be used E820 map.
+ * In case no area is found, return 0. Otherwise return the physical address
+ * of the area which is already reserved for convenience.
+ */
+phys_addr_t __init xen_find_free_area(phys_addr_t size)
+{
+ unsigned mapcnt;
+ phys_addr_t addr, start;
+ struct e820entry *entry = xen_e820_map;
+
+ for (mapcnt = 0; mapcnt < xen_e820_map_entries; mapcnt++, entry++) {
+ if (entry->type != E820_RAM || entry->size < size)
+ continue;
+ start = entry->addr;
+ for (addr = start; addr < start + size; addr += PAGE_SIZE) {
+ if (!memblock_is_reserved(addr))
+ continue;
+ start = addr + PAGE_SIZE;
+ if (start + size > entry->addr + entry->size)
+ break;
+ }
+ if (addr >= start + size) {
+ memblock_reserve(start, size);
+ return start;
+ }
+ }
+
+ return 0;
+}
+
+/*
* Reserve Xen mfn_list.
* See comment above "struct start_info" in
* We tried to make the the memblock_reserve more selective so
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index fee4f70..8181e01 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -44,6 +44,7 @@ void __init xen_inv_extra_mem(void);
void __init xen_remap_memory(void);
void __init xen_add_reserved_area(phys_addr_t start, phys_addr_t size,
int (*func)(phys_addr_t, phys_addr_t), int reserve);
+phys_addr_t __init xen_find_free_area(phys_addr_t size);
char * __init xen_memory_setup(void);
char * xen_auto_xlated_memory_setup(void);
void __init xen_arch_setup(void);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/13] xen: simplify xen_set_identity_and_remap() by using global variables
xen_set_identity_and_remap() is used to prepare remapping of memory
conflicting with the E820 map. It is tracking the pfn where to remap
new memory via a local variable which is passed to a subfunction
which in turn returns the new value for that variable.
Additionally the targeted maximum pfn is passed as a parameter to
sub functions.
Simplify that construct by using just global variables in the
source for that purpose. This will make things simpler when we need
those values later, too.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 63 +---
1 file changed, 30 insertions(+), 33 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index ab6c36e..0dda131 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -56,6 +56,9 @@ static struct {
} xen_remap_buf __initdata __aligned(PAGE_SIZE);
static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
+static unsigned long xen_remap_pfn;
+static unsigned long xen_max_pfn;
+
/*
* The maximum amount of extra memory compared to the base size. The
* main scaling factor is the size of struct page. At extreme ratios
@@ -223,7 +226,7 @@ static int __init xen_free_mfn(unsigned long mfn)
* as a fallback if the remapping fails.
*/
static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
- unsigned long end_pfn, unsigned long nr_pages, unsigned long *released)
+ unsigned long end_pfn, unsigned long *released)
{
unsigned long pfn, end;
int ret;
@@ -231,7 +234,7 @@ static void __init
xen_set_identity_and_release_chunk(unsigned long start_pfn,
WARN_ON(start_pfn > end_pfn);
/* Release pages first. */
- end = min(end_pfn, nr_pages);
+ end = min(end_pfn, xen_max_pfn);
for (pfn = start_pfn; pfn < end; pfn++) {
unsigned long mfn = pfn_to_mfn(pfn);
@@ -302,7 +305,7 @@ static void __init xen_update_mem_tables(unsigned long pfn,
unsigned long mfn)
* its callers.
*/
static void __init xen_do_set_identity_and_remap_chunk(
-unsigned long start_pfn, unsigned long size, unsigned long remap_pfn)
+ unsigned long start_pfn, unsigned long size)
{
unsigned long buf = (unsigned long)_remap_buf;
unsigned long mfn_save, mfn;
@@ -317,7 +320,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
mfn_save = virt_to_mfn(buf);
- for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
+ for (ident_pfn_iter = start_pfn, remap_pfn_iter = xen_remap_pfn;
ident_pfn_iter < ident_end_pfn;
ident_pfn_iter += REMAP_SIZE, remap_pfn_iter += REMAP_SIZE) {
chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
@@ -350,17 +353,16 @@ static void __init xen_do_set_identity_and_remap_chunk(
* This function takes a contiguous pfn range that needs to be identity mapped
* and:
*
- * 1) Finds a new range of pfns to use to remap based on E820 and remap_pfn.
+ * 1) Finds a new range of pfns to use to remap based on E820 and
+ * xen_remap_pfn.
* 2) Calls the do_ function to actually do the mapping/remapping work.
*
* The goal is to not allocate additional memory but to remap the existing
* pages. In the case of an error the underlying memory is simply released back
* to Xen and not remapped.
*/
-static unsigned long __init xen_set_identity_and_remap_chunk(
- unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages,
- unsigned long remap_pfn, unsigned long *released,
- unsigned long *remapped)
+static void __init xen_set_identity_and_remap_chunk(unsigned long start_pfn,
+ unsigned long end_pfn, unsigned long *released, unsigned long *remapped)
{
unsigned long pfn;
unsigned long i = 0;
@@ -373,30 +375,30 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
unsigned long remap_range_size;
/* Do not remap pages beyond the current allocation */
- if (cur_pfn >= nr_pages) {
+ if (cur_pfn >= xen_max_pfn) {
/* Identity map remaining pages */
set_phys_range_identity(cur_pfn, cur_pfn + size);
break;
}
- if (cur_pfn + size > nr_pages)
- size = nr_pages - cur_pfn;
+ if (cur_pfn + size > xen_max_pfn)
+ size = xen_max_pfn - cur_pfn;
- remap_range_size = xen_find_pfn_range(_pfn);
+ remap_range_size = xen_find_pfn_range(_remap_pfn);
if (!remap_range_size) {
pr_warning("Unable to find available pfn range, not
remapping identity pages\n");
xen_set_identity_and_release_chunk(cur_pfn,
- cur_pfn + left, nr_pages, released);
+
[PATCH 02/13] xen: anchor linear p2m list in shared info structure
The linear p2m list should be anchored in the shared info structure
read by the Xen tools to be able to support 64 bit pv-domains larger
than 512 MB. Additionally the linear p2m list interface includes a
generation count which is changed prior to and after each mapping
change of the p2m list. Reading the generation count the Xen tools can
detect changes of the mappings and re-read the p2m list eventually.
Signed-off-by: Juergen Gross
---
arch/x86/xen/p2m.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index f18fd1d..df73cc5 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void)
HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list =
virt_to_mfn(p2m_top_mfn);
HYPERVISOR_shared_info->arch.max_pfn = xen_max_p2m_pfn;
+ HYPERVISOR_shared_info->arch.p2m_generation = 0;
+ HYPERVISOR_shared_info->arch.p2m_vaddr = (unsigned long)xen_p2m_addr;
+ HYPERVISOR_shared_info->arch.p2m_cr3 =
+ xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
}
/* Set up p2m_top to point to the domain-builder provided p2m pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t
*pte_pg)
ptechk = lookup_address(vaddr, );
if (ptechk == pte_pg) {
+ HYPERVISOR_shared_info->arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+ HYPERVISOR_shared_info->arch.p2m_generation++;
pte_newpg[i] = NULL;
}
@@ -568,8 +574,10 @@ static bool alloc_p2m(unsigned long pfn)
spin_lock_irqsave(_update_lock, flags);
if (pte_pfn(*ptep) == p2m_pfn) {
+ HYPERVISOR_shared_info->arch.p2m_generation++;
set_pte(ptep,
pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+ HYPERVISOR_shared_info->arch.p2m_generation++;
if (mid_mfn)
mid_mfn[mididx] = virt_to_mfn(p2m);
p2m = NULL;
@@ -621,6 +629,11 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned
long mfn)
return true;
}
+ /*
+* The interface requires atomic updates on p2m elements.
+* xen_safe_write_ulong() is using __put_user which does an atomic
+* store via asm().
+*/
if (likely(!xen_safe_write_ulong(xen_p2m_addr + pfn, mfn)))
return true;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/13] xen: detect pre-allocated memory interfering with e820 map
Currently especially for dom0 guest memory with guest pfns not
matching host areas populated with RAM are remapped to areas which
are RAM native as well. This is done to be able to use identity
mappings (pfn == mfn) for I/O areas.
Up to now it is not checked whether the remapped memory is already
in use. Remapping used memory will probably result in data corruption,
as the remapped memory will no longer be reserved. Any memory
allocation after the remap can claim that memory.
Add an infrastructure to check for conflicts of reserved memory areas
and in case of a conflict to react via an area specific function.
This function has 3 options:
- Panic
- Handle the conflict by moving the data to another memory area.
This is indicated by a return value other than 0.
- Just return 0. This will delay invalidating the conflicting memory
area to just before doing the remap. This option will be usable for
cases only where the memory will no longer be needed when the remap
operation will be started, e.g. for the p2m list, which is already
copied then.
When doing the remap, check for not remapping a reserved page.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 185 +++--
arch/x86/xen/xen-ops.h | 2 +
2 files changed, 182 insertions(+), 5 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 0dda131..a0af554 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -59,6 +59,20 @@ static unsigned long xen_remap_mfn __initdata =
INVALID_P2M_ENTRY;
static unsigned long xen_remap_pfn;
static unsigned long xen_max_pfn;
+/*
+ * Areas with memblock_reserve()d memory to be checked against final E820 map.
+ * Each area has an associated function to handle conflicts (by either
+ * removing the conflict or by just crashing with an appropriate message).
+ * The array has a fixed size as there are only few areas of interest which are
+ * well known: kernel, page tables, p2m, initrd.
+ */
+#define XEN_N_RESERVED_AREAS 4
+static struct {
+ phys_addr_t start;
+ phys_addr_t size;
+ int (*func)(phys_addr_t start, phys_addr_t size);
+} xen_reserved_area[XEN_N_RESERVED_AREAS] __initdata;
+
/*
* The maximum amount of extra memory compared to the base size. The
* main scaling factor is the size of struct page. At extreme ratios
@@ -365,10 +379,10 @@ static void __init
xen_set_identity_and_remap_chunk(unsigned long start_pfn,
unsigned long end_pfn, unsigned long *released, unsigned long *remapped)
{
unsigned long pfn;
- unsigned long i = 0;
+ unsigned long i;
unsigned long n = end_pfn - start_pfn;
- while (i < n) {
+ for (i = 0; i < n; ) {
unsigned long cur_pfn = start_pfn + i;
unsigned long left = n - i;
unsigned long size = left;
@@ -411,6 +425,53 @@ static void __init
xen_set_identity_and_remap_chunk(unsigned long start_pfn,
(unsigned long)__va(pfn << PAGE_SHIFT),
mfn_pte(pfn, PAGE_KERNEL_IO), 0);
}
+/* Check to be remapped memory area for conflicts with reserved areas.
+ *
+ * Skip regions known to be reserved which are handled later. For these
+ * regions we have to increase the remapped counter in order to reserve
+ * extra memory space.
+ *
+ * In case a memory page already in use is to be remapped, just BUG().
+ */
+static void __init xen_set_identity_and_remap_chunk_chk(unsigned long
start_pfn,
+ unsigned long end_pfn, unsigned long *released, unsigned long *remapped)
+{
+ unsigned long pfn;
+ unsigned long area_start, area_end;
+ unsigned i;
+
+ for (i = 0; i < XEN_N_RESERVED_AREAS; i++) {
+
+ if (!xen_reserved_area[i].size)
+ break;
+
+ area_start = PFN_DOWN(xen_reserved_area[i].start);
+ area_end = PFN_UP(xen_reserved_area[i].start +
+ xen_reserved_area[i].size);
+ if (area_start >= end_pfn || area_end <= start_pfn)
+ continue;
+
+ if (area_start > start_pfn)
+ xen_set_identity_and_remap_chunk(start_pfn, area_start,
+released, remapped);
+
+ if (area_end < end_pfn)
+ xen_set_identity_and_remap_chunk(area_end, end_pfn,
+released, remapped);
+
+ *remapped += min(area_end, end_pfn) -
+ max(area_start, start_pfn);
+
+ return;
+ }
+
+ /* Test for memory already in use */
+ for (pfn = start_pfn; pfn < end_pfn; pfn++)
+ BUG_ON(memblock_is_reserved(PFN_PHYS(pfn)));
+
+ xen_set_identity_and_remap_chunk(start_pfn, end_pfn,
+released, remapped);
+}
static void __init
[PATCH 08/13] xen: add service function to copy physical memory areas
In case a pre-allocated memory area is to be moved in order to avoid
a conflict with the target E820 map we need a way to copy data between
physical addresses.
Add a function doing this via early_memremap().
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 29 +
arch/x86/xen/xen-ops.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 9c49d71..eb219c1 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -766,6 +766,35 @@ phys_addr_t __init xen_find_free_area(phys_addr_t size)
}
/*
+ * Like memcpy, but with physical addresses for dest and src.
+ */
+void __init xen_phys_memcpy(phys_addr_t dest, phys_addr_t src, phys_addr_t n)
+{
+ phys_addr_t dest_off, src_off, dest_len, src_len, len;
+ void *from, *to;
+
+ while (n) {
+ dest_off = dest & ~PAGE_MASK;
+ src_off = src & ~PAGE_MASK;
+ dest_len = n;
+ if (dest_len > (NR_FIX_BTMAPS << PAGE_SHIFT) - dest_off)
+ dest_len = (NR_FIX_BTMAPS << PAGE_SHIFT) - dest_off;
+ src_len = n;
+ if (src_len > (NR_FIX_BTMAPS << PAGE_SHIFT) - src_off)
+ src_len = (NR_FIX_BTMAPS << PAGE_SHIFT) - src_off;
+ len = min(dest_len, src_len);
+ to = early_memremap(dest - dest_off, dest_len + dest_off);
+ from = early_memremap(src - src_off, src_len + src_off);
+ memcpy(to, from, len);
+ early_iounmap(to, dest_len + dest_off);
+ early_iounmap(from, src_len + src_off);
+ n -= len;
+ dest += len;
+ src += len;
+ }
+}
+
+/*
* Reserve Xen mfn_list.
* See comment above "struct start_info" in
* We tried to make the the memblock_reserve more selective so
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 8181e01..9bf9df8 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -45,6 +45,7 @@ void __init xen_remap_memory(void);
void __init xen_add_reserved_area(phys_addr_t start, phys_addr_t size,
int (*func)(phys_addr_t, phys_addr_t), int reserve);
phys_addr_t __init xen_find_free_area(phys_addr_t size);
+void __init xen_phys_memcpy(phys_addr_t dest, phys_addr_t src, phys_addr_t n);
char * __init xen_memory_setup(void);
char * xen_auto_xlated_memory_setup(void);
void __init xen_arch_setup(void);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/13] xen: move initrd away from e820 non-ram area
When adapting the dom0 memory layout to that of the host make sure
the initrd isn't moved to another pfn range, as it won't be found
there any more.
The easiest way to accomplish that is by copying the initrd to an
area which is RAM according to the E820 map.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 78a881b..21c82dfd 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1530,6 +1530,25 @@ static void __init xen_pvh_early_guest_init(void)
}
#endif/* CONFIG_XEN_PVH */
+static int __init xen_initrd_mem_conflict(phys_addr_t start, phys_addr_t size)
+{
+ phys_addr_t new;
+
+ new = xen_find_free_area(size);
+ if (!new)
+ panic("initrd is located at position conflicting with E820
map!\n");
+
+ xen_phys_memcpy(new, start, size);
+ pr_info("initrd moved from [mem %#010llx-%#010llx] to [mem
%#010llx-%#010llx]\n",
+ start, start + size, new, new + size);
+ memblock_free(start, size);
+
+ boot_params.hdr.ramdisk_image = new;
+ boot_params.ext_ramdisk_image = new >> 32;
+
+ return 1;
+}
+
/* First C function to be called on Xen boot */
asmlinkage __visible void __init xen_start_kernel(void)
{
@@ -1691,6 +1710,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
boot_params.hdr.ramdisk_size = xen_start_info->mod_len;
boot_params.hdr.cmd_line_ptr = __pa(xen_start_info->cmd_line);
+ xen_add_reserved_area(initrd_start, xen_start_info->mod_len,
+ xen_initrd_mem_conflict, 0);
+
if (!xen_initial_domain()) {
add_preferred_console("xenboot", 0, NULL);
add_preferred_console("tty", 0, NULL);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/13] xen: check for kernel memory conflicting with memory layout
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index eb219c1..37a34f9 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -829,6 +829,12 @@ static void __init xen_reserve_xen_mfnlist(void)
PFN_PHYS(xen_start_info->nr_p2m_frames));
}
+static int __init xen_kernel_mem_conflict(phys_addr_t start, phys_addr_t size)
+{
+ panic("kernel is located at position conflicting with E820 map!\n");
+ return 0;
+}
+
/**
* machine_specific_memory_setup - Hook for machine specific memory setup.
**/
@@ -843,6 +849,10 @@ char * __init xen_memory_setup(void)
int i;
int op;
+ xen_add_reserved_area(__pa_symbol(_text),
+ __pa_symbol(__bss_stop) - __pa_symbol(_text),
+ xen_kernel_mem_conflict, 0);
+
xen_reserve_xen_mfnlist();
xen_max_pfn = min(MAX_DOMAIN_PAGES, xen_start_info->nr_pages);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/13] xen: check pre-allocated page tables for conflict with memory map
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Signed-off-by: Juergen Gross
---
arch/x86/xen/mmu.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1ca5197..6641459 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1863,6 +1863,12 @@ void __init xen_setup_machphys_mapping(void)
#endif
}
+static int __init xen_pt_memory_conflict(phys_addr_t start, phys_addr_t size)
+{
+ panic("page tables are located at position conflicting with E820
map!\n");
+ return 0;
+}
+
#ifdef CONFIG_X86_64
static void __init convert_pfn_mfn(void *v)
{
@@ -1998,7 +2004,9 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
check_pt_base(_base, _end, addr[i]);
/* Our (by three pages) smaller Xen pagetable that we are using */
- memblock_reserve(PFN_PHYS(pt_base), (pt_end - pt_base) * PAGE_SIZE);
+ xen_add_reserved_area(PFN_PHYS(pt_base),
+ (pt_end - pt_base) * PAGE_SIZE,
+ xen_pt_memory_conflict, 1);
/* protect xen_start_info */
memblock_reserve(__pa(xen_start_info), PAGE_SIZE);
/* Revector the xen_start_info */
@@ -2074,8 +2082,9 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
PFN_DOWN(__pa(initial_page_table)));
xen_write_cr3(__pa(initial_page_table));
- memblock_reserve(__pa(xen_start_info->pt_base),
-xen_start_info->nr_pt_frames * PAGE_SIZE);
+ xen_add_reserved_area(__pa(xen_start_info->pt_base),
+ xen_start_info->nr_pt_frames * PAGE_SIZE,
+ xen_pt_memory_conflict, 1);
}
#endif /* CONFIG_X86_64 */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/13] xen: if p2m list located in to be remapped region delay remapping
With adapting the memory layout of dom0 to that of the host care must
be taken not to remap the initial p2m list supported by the hypervisor.
If the p2m map is detected to be in a region which is going to be
remapped, delay the remapping of that area. Not doing so can either
crash the system very early, or lead to clobbered data as the target
memory area of the remap operation will no longer be reserved.
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 37a34f9..84a6473 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -794,6 +794,20 @@ void __init xen_phys_memcpy(phys_addr_t dest, phys_addr_t
src, phys_addr_t n)
}
}
+#ifdef CONFIG_X86_64
+static int __init xen_p2m_conflict(phys_addr_t start, phys_addr_t size)
+{
+ /* Delay invalidating memory. */
+ return 0;
+}
+#else
+static int __init xen_p2m_conflict(phys_addr_t start, phys_addr_t size)
+{
+ panic("p2m list is located at position conflicting with E820 map!\n");
+ return 0;
+}
+#endif
+
/*
* Reserve Xen mfn_list.
* See comment above "struct start_info" in
@@ -819,14 +833,16 @@ void __init xen_phys_memcpy(phys_addr_t dest, phys_addr_t
src, phys_addr_t n)
static void __init xen_reserve_xen_mfnlist(void)
{
if (xen_start_info->mfn_list >= __START_KERNEL_map) {
- memblock_reserve(__pa(xen_start_info->mfn_list),
-xen_start_info->pt_base -
-xen_start_info->mfn_list);
+ xen_add_reserved_area(__pa(xen_start_info->mfn_list),
+ xen_start_info->pt_base -
+ xen_start_info->mfn_list,
+ xen_p2m_conflict, 1);
return;
}
- memblock_reserve(PFN_PHYS(xen_start_info->first_p2m_pfn),
-PFN_PHYS(xen_start_info->nr_p2m_frames));
+ xen_add_reserved_area(PFN_PHYS(xen_start_info->first_p2m_pfn),
+ PFN_PHYS(xen_start_info->nr_p2m_frames),
+ xen_p2m_conflict, 1);
}
static int __init xen_kernel_mem_conflict(phys_addr_t start, phys_addr_t size)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and eventually for crash dump analysis. For this tree
the linear p2m list can serve as a replacement, too. As the kernel
can't know whether the tools are capable of dealing with the p2m list
instead of the mfn tree, the limit of 512 GB can't be dropped in all
cases.
This patch replaces the hard limit by a kernel parameter which tells
the kernel to obey the 512 GB limit or not. The default is selected by
a configuration parameter which specifies whether the 512 GB limit
should be active per default for dom0 (only crash dump analysis is
affected) and/or for domUs (additionally domain save/restore/migration
are affected).
Memory above the domain limit is returned to the hypervisor instead of
being identity mapped, which was wrong anyways.
The kernel configuration parameter to specify the maximum size of a
domain can be deleted, as it is not relevant any more.
Signed-off-by: Juergen Gross
---
Documentation/kernel-parameters.txt | 7
arch/x86/include/asm/xen/page.h | 4 ---
arch/x86/xen/Kconfig| 31 +++-
arch/x86/xen/p2m.c | 10 +++---
arch/x86/xen/setup.c| 72 ++---
5 files changed, 93 insertions(+), 31 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index a89e326..7bf6342 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3959,6 +3959,13 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
plus one apbt timer for broadcast timer.
x86_intel_mid_timer=apbt_only | lapic_and_apbt
+ xen_512gb_limit [KNL,X86-64,XEN]
+ Restricts the kernel running paravirtualized under Xen
+ to use only up to 512 GB of RAM. The reason to do so is
+ crash analysis tools and Xen tools for doing domain
+ save/restore/migration must be enabled to handle larger
+ domains.
+
xen_emul_unplug=[HW,X86,XEN]
Unplug Xen emulated devices
Format: [unplug0,][unplug1]
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 358dcd3..18a11f2 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -35,10 +35,6 @@ typedef struct xpaddr {
#define FOREIGN_FRAME(m) ((m) | FOREIGN_FRAME_BIT)
#define IDENTITY_FRAME(m) ((m) | IDENTITY_FRAME_BIT)
-/* Maximum amount of memory we can handle in a domain in pages */
-#define MAX_DOMAIN_PAGES \
-((unsigned long)((u64)CONFIG_XEN_MAX_DOMAIN_MEMORY * 1024 * 1024 * 1024 /
PAGE_SIZE))
-
extern unsigned long *machine_to_phys_mapping;
extern unsigned long machine_to_phys_nr;
extern unsigned long *xen_p2m_addr;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index e88fda8..b61a15e 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -23,14 +23,29 @@ config XEN_PVHVM
def_bool y
depends on XEN && PCI && X86_LOCAL_APIC
-config XEN_MAX_DOMAIN_MEMORY
- int
- default 500 if X86_64
- default 64 if X86_32
- depends on XEN
- help
- This only affects the sizing of some bss arrays, the unused
- portions of which are freed.
+if X86_64
+choice
+ prompt "Support pv-domains larger than 512GB"
+ default XEN_512GB_NONE
+ help
+ Support paravirtualized domains with more than 512GB of RAM.
+
+ The Xen tools and crash dump analysis tools might not support
+ pv-domains with more than 512 GB of RAM. This option controls the
+ default setting of the kernel to use only up to 512 GB or more.
+ It is always possible to change the default via specifying the
+ boot parameter "xen_512gb_limit".
+
+ config XEN_512GB_NONE
+ bool "neither dom0 nor domUs can be larger than 512GB"
+ config XEN_512GB_DOM0
+ bool "dom0 can be larger than 512GB, domUs not"
+ config XEN_512GB_DOMU
+ bool "domUs can be larger than 512GB, dom0 not"
+ config XEN_512GB_ALL
+ bool "dom0 and domUs can be larger than 512GB"
+endchoice
+endif
config XEN_SAVE_RESTORE
bool
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index df73cc5..12a1e98 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -502,7 +502,7 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t
*pte_pg)
*/
static bool alloc_p2m(unsigned long pfn)
{
- unsigned topidx, mididx;
+
[PATCH 00/13] xen: support pv-domains larger than 512GB
Support 64 bit pv-domains with more than 512GB of memory. Tested with 64 bit dom0 on machines with 8GB and 1TB and 32 bit dom0 on a 8GB machine. Conflicts between E820 map and different hypervisor populated memory areas have been tested via a fake E820 map reserved area on the 8GB machine. Juergen Gross (13): xen: sync with xen header xen: anchor linear p2m list in shared info structure xen: eliminate scalability issues from initial mapping setup xen: move static e820 map to global scope xen: simplify xen_set_identity_and_remap() by using global variables xen: detect pre-allocated memory interfering with e820 map xen: find unused contiguous memory area xen: add service function to copy physical memory areas xen: check for kernel memory conflicting with memory layout xen: check pre-allocated page tables for conflict with memory map xen: move initrd away from e820 non-ram area xen: if p2m list located in to be remapped region delay remapping xen: allow more than 512 GB of RAM for 64 bit pv-domains Documentation/kernel-parameters.txt | 7 + arch/x86/include/asm/xen/interface.h | 96 ++- arch/x86/include/asm/xen/page.h | 4 - arch/x86/xen/Kconfig | 31 +- arch/x86/xen/enlighten.c | 22 ++ arch/x86/xen/mmu.c | 141 - arch/x86/xen/p2m.c | 23 +- arch/x86/xen/setup.c | 536 --- arch/x86/xen/xen-head.S | 2 + arch/x86/xen/xen-ops.h | 4 + 10 files changed, 717 insertions(+), 149 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] powerpc: Don't force ENOSYS as error on syscall fail
On 18.02.2015 05:01, Mike Strosaker wrote:
This patch failed to build using pseries_le_defconfig. With the change
noted below in entry_64.S, the build succeeded and seccomp mode 2 worked
correctly.
Best,
Mike Strosaker
On 02/13/2015 02:22 AM, Bogdan Purcareata wrote:
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be configured to store a user-defined error code on
return from a blacklisted syscall. Don't always set ENOSYS on
do_syscall_trace_enter failure.
Delegate setting ENOSYS in case of failure, where appropriate, to
do_syscall_trace_enter.
v3:
- keep setting ENOSYS in the syscall entry assembly for scenarios without
syscall tracing
v2:
- move setting ENOSYS as errno from the syscall entry assembly to
do_syscall_trace_enter, only in the specific case
Signed-off-by: Bogdan Purcareata
---
arch/powerpc/kernel/entry_32.S | 7 ++-
arch/powerpc/kernel/entry_64.S | 5 +++--
arch/powerpc/kernel/ptrace.c | 4 +++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 46fc0f4..b2f88cd 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -333,12 +333,12 @@ _GLOBAL(DoSyscall)
lwz r11,TI_FLAGS(r10)
andi. r11,r11,_TIF_SYSCALL_DOTRACE
bne-syscall_dotrace
-syscall_dotrace_cont:
cmplwi 0,r0,NR_syscalls
lis r10,sys_call_table@h
ori r10,r10,sys_call_table@l
slwir0,r0,2
bge-66f
+syscall_dotrace_cont:
lwzxr10,r10,r0 /* Fetch system call handler [ptr] */
mtlrr10
addir9,r1,STACK_FRAME_OVERHEAD
@@ -457,6 +457,11 @@ syscall_dotrace:
lwz r7,GPR7(r1)
lwz r8,GPR8(r1)
REST_NVGPRS(r1)
+ cmplwi 0,r0,NR_syscalls
+ lis r10,sys_call_table@h
+ ori r10,r10,sys_call_table@l
+ slwir0,r0,2
+ bge-ret_from_syscall
b syscall_dotrace_cont
syscall_exit_work:
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index d180caf2..0d22fa8 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -144,7 +144,6 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
ld r10,TI_FLAGS(r11)
andi. r11,r10,_TIF_SYSCALL_DOTRACE
bne syscall_dotrace
-.Lsyscall_dotrace_cont:
cmpldi 0,r0,NR_syscalls
bge-syscall_enosys
@@ -253,7 +252,9 @@ syscall_dotrace:
addir9,r1,STACK_FRAME_OVERHEAD
CURRENT_THREAD_INFO(r10, r1)
ld r10,TI_FLAGS(r10)
- b .Lsyscall_dotrace_cont
+ cmpldi 0,r0,NR_syscalls
+ bge-syscall_exit
Shouldn't this be .Lsyscall_exit?
Thanks for testing and spotting this! The kernel I tested with didn't
have syscall_exit converted to a local label (commit
4c3b21686111e0ac6018469dacbc5549f9915cf8).
Will resend with this change.
Bogdan P.
+ b system_call
syscall_enosys:
li r3,-ENOSYS
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index f21897b..2edae06 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1775,13 +1775,15 @@ long do_syscall_trace_enter(struct pt_regs *regs)
secure_computing_strict(regs->gpr[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
- tracehook_report_syscall_entry(regs))
+ tracehook_report_syscall_entry(regs)) {
/*
* Tracing decided this syscall should not happen.
* We'll return a bogus call number to get an ENOSYS
* error, but leave the original number in regs->gpr[0].
*/
ret = -1L;
+ syscall_set_return_value(current, regs, ENOSYS, 0);
+ }
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs->gpr[0]);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] PM-Trace: add pm-trace support for suspending phase
On Sunday, February 15, 2015 10:24:07 AM Fu, Zhonghui wrote:
> Occasionally, the system can't come back up after suspend/resume
> due to problems of device suspending phase. This patch make
> PM_TRACE infrastructure cover device suspending phase of
> suspend/resume process, and the information in RTC can tell
> developers which device suspending function make system hang.
>
> Signed-off-by: Zhonghui Fu
> ---
> Changes in v2:
> - Add -M option so that the rename and changes can be reviewed much easier.
>
> arch/x86/include/asm/pm-trace.h | 36
> ++
> arch/x86/include/asm/resume-trace.h | 21 ---
> drivers/base/power/main.c| 20 +++---
> drivers/base/power/trace.c |6 ++--
> include/linux/{resume-trace.h => pm-trace.h} |9 +++---
> kernel/power/main.c |2 +-
> 6 files changed, 61 insertions(+), 33 deletions(-)
> create mode 100644 arch/x86/include/asm/pm-trace.h
> delete mode 100644 arch/x86/include/asm/resume-trace.h
> rename include/linux/{resume-trace.h => pm-trace.h} (75%)
>
> diff --git a/arch/x86/include/asm/pm-trace.h b/arch/x86/include/asm/pm-trace.h
> new file mode 100644
> index 000..09bd918
> --- /dev/null
> +++ b/arch/x86/include/asm/pm-trace.h
> @@ -0,0 +1,36 @@
> +#ifndef _ASM_X86_PM_TRACE_H
> +#define _ASM_X86_PM_TRACE_H
> +
> +#include
> +
> +#define TRACE_RESUME(user) \
> +do { \
> + if (pm_trace_enabled) { \
> + const void *tracedata; \
> + asm volatile(_ASM_MOV " $1f,%0\n" \
> + ".section .tracedata,\"a\"\n" \
> + "1:\t.word %c1\n\t"\
> + _ASM_PTR " %c2\n" \
> + ".previous"\
> + :"=r" (tracedata) \
> + : "i" (__LINE__), "i" (__FILE__)); \
> + generate_pm_trace(tracedata, user); \
> + } \
> +} while (0)
> +
> +#define TRACE_SUSPEND(user) \
> +do { \
> + if (pm_trace_enabled) { \
> + const void *tracedata; \
> + asm volatile(_ASM_MOV " $1f,%0\n" \
> + ".section .tracedata,\"a\"\n" \
> + "1:\t.word %c1\n\t"\
> + _ASM_PTR " %c2\n" \
> + ".previous"\
> + :"=r" (tracedata) \
> + : "i" (__LINE__), "i" (__FILE__)); \
> + generate_pm_trace(tracedata, user); \
> + } \
> +} while (0)
Are those macros identical or am I missing anything?
If they are identical, why do we need two identical macros?
--
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: [GIT PULL] Fix mcelog regression
* Luck, Tony wrote: > Sorry for bypassing normal channels, but this looks like > a trivial regression fix to me, but I'm getting pushback > from my co-maintainer and from Ingo. > > 1. This used to work > 2. Now it doesn't > 3. People have complained > > Previous threads: > https://lkml.org/lkml/2015/1/30/641 > https://lkml.org/lkml/2015/2/11/437 So this fix is perfectly OK to me. The primary thing I objected to (which objection you did not quote!!), was the initial approach, the ugly vendor-specific switch you added: https://lkml.org/lkml/2015/2/9/237 The latest replacement commit you added looks clean - and /dev/mcelog is certainly a legacy we have to keep. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev] [PATCH v3 06/10] f2fs: add core functions for rb-tree extent cache
Hi Chao,
On Mon, Feb 16, 2015 at 04:10:54PM +0800, Chao Yu wrote:
> Ping.
>
> Any comments on this patch now?
Please let me take some time to test them.
Thanks,
>
> > -Original Message-
> > From: Chao Yu [mailto:chao2...@samsung.com]
> > Sent: Thursday, February 05, 2015 5:55 PM
> > To: Jaegeuk Kim; Changman Lee
> > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> > Subject: [f2fs-dev] [PATCH v3 06/10] f2fs: add core functions for rb-tree
> > extent cache
> >
> > This patch adds core functions including slab cache init function and
> > init/lookup/update/shrink/destroy function for rb-tree based extent cache.
> >
> > Thank Jaegeuk Kim and Changman Lee as they gave much suggestion about detail
> > design and implementation of extent cache.
> >
> > Todo:
> > * register rb-based extent cache shrink with mm shrink interface.
> >
> > v2:
> > o move set_extent_info and __is_{extent,back,front}_mergeable into f2fs.h.
> > o introduce __{attach,detach}_extent_node for code readability.
> > o add cond_resched() when fail to invoke
> > kmem_cache_alloc/radix_tree_insert.
> > o fix some coding style and typo issues.
> >
> > v3:
> > o fix oops due to using an unassigned pointer.
> > o use list_del to remove extent node in shrink list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] cpuidle/powernv: Read target_residency value of idle states from DT if available
On 02/18/2015 11:21 AM, Rafael J. Wysocki wrote: > On Wednesday, February 18, 2015 10:13:23 AM Preeti U Murthy wrote: >> >> On 02/17/2015 11:23 PM, Rafael J. Wysocki wrote: >>> On Tuesday, February 17, 2015 01:29:10 PM Preeti U Murthy wrote: Hi Rafael, >>> >>> Hi, >>> Can you please pull this patch ? >>> >>> Sorry, I wasn't sure whether or not the patch was for me to take and then >>> I've been traveling lately. Applied now. >> >> Hi Rafael, >> >> I saw that the kbuild bot reported build issues around pr_warn() in this >> patch. >> I have fixed this and below is the corrected patch. Do let me know if I have >> to send it out as a separate version/RESEND tag. > > I've applied it, thanks! > Another patch based on top of this is waiting to be pulled: [PATCH] driver/cpuidle-powernv: Avoid endianness conversions while parsing DT >>> >>> OK, have you posted it already? >> Yes I have. https://lkml.org/lkml/2015/2/3/24. > > OK, so this one does not apply for me on top of the other. Can you rebase it > on top of my current linux-next branch and resend it, please? > > Also I'd appreciate it if someone could ACK DT-related stuff for me. Yes Ill get this done. > >> This patch is also waiting to be pulled by you. There was some confusion >> around who should pull this, but since it all the code is in the driver, we >> thought it would be best if you pulled it. > > Well, OK. If you want me to apply a patch, send it To: me and not To: someone > else. If you send it To: someone else, I'll ignore it. > > Also ask people to review and ACK things you want me to pull, especially if > that's not stuff I'm particularly familiar with (like related to DT bindings > specific to your platform etc.). > Sure Ill do that. Thanks! Regards Preeti U Murthy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] phy: usbphy: Add Broadcom Cygnus USB PHY driver
Hi,
On Wednesday 18 February 2015 12:50 AM, Arun Ramamurthy wrote:
This driver adds support for USB 2.0 host and device phy
for Broadcom's Cygnus chipset
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Signed-off-by: Arun Ramamurthy
---
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-bcm-cygnus-usb.c | 491 +++
3 files changed, 505 insertions(+)
create mode 100644 drivers/phy/phy-bcm-cygnus-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..c934090 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -277,4 +277,16 @@ config PHY_STIH41X_USB
Enable this to support the USB transceiver that is part of
STMicroelectronics STiH41x SoC series.
+config PHY_BCM_CYGNUS_USB
+ tristate "Broadcom Cygnus USB PHY support"
+ depends on OF
+ depends on ARCH_BCM_CYGNUS
+ select GENERIC_PHY
+ default ARCH_BCM_CYGNUS
+ help
+ Enable this to support the USB PHY in Broadcom's Cygnus chip.
+ The phys are capable of supporting host mode for all ports
+ and device mode for port 2. The host or device configuration is
+ read from the device tree.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..b235677 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BERLIN_USB)+= phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+= phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
+obj-$(CONFIG_PHY_BCM_CYGNUS_USB) += phy-bcm-cygnus-usb.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
@@ -34,3 +35,4 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
+
diff --git a/drivers/phy/phy-bcm-cygnus-usb.c b/drivers/phy/phy-bcm-cygnus-usb.c
new file mode 100644
index 000..e5d3e50
--- /dev/null
+++ b/drivers/phy/phy-bcm-cygnus-usb.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
2015 already :-)
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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
+
+#define CDRU_USBPHY_CLK_RST_SEL_OFFSET 0x11b4
+#define CDRU_USBPHY2_HOST_DEV_SEL_OFFSET 0x11b8
+#define CDRU_SPARE_REG_0_OFFSET0x1238
+#define CRMU_USB_PHY_AON_CTRL_OFFSET 0x00028
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_OFFSET0x1210
+#define CDRU_USBPHY_P2_STATUS_OFFSET 0x1200
+
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_DISABLE 0
+#define PHY2_DEV_HOST_CTRL_SEL_DEVICE 0
+#define PHY2_DEV_HOST_CTRL_SEL_HOST1
+#define CDRU_USBPHY_P2_STATUS__USBPHY_ILDO_ON_FLAG 1
+#define CDRU_USBPHY_P2_STATUS__USBPHY_PLL_LOCK 0
+#define CRMU_USBPHY_P0_AFE_CORERDY_VDDC1
+#define CRMU_USBPHY_P0_RESETB 2
+#define CRMU_USBPHY_P1_AFE_CORERDY_VDDC9
+#define CRMU_USBPHY_P1_RESETB 10
+#define CRMU_USBPHY_P2_AFE_CORERDY_VDDC17
+#define CRMU_USBPHY_P2_RESETB 18
+
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET 0x0408
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT__clk_enable 0
+#define USB2_IDM_IDM_RESET_CONTROL_OFFSET 0x0800
+#define USB2_IDM_IDM_RESET_CONTROL__RESET 0
+
+#define PLL_LOCK_RETRY_COUNT 1000
+#define MAX_REGULATOR_NAME_LEN 25
+
+struct bcm_phy_instance;
+
+struct bcm_phy_driver {
+ void __iomem *usbphy_regs;
+ void __iomem *usb2h_idm_regs;
+ void __iomem *usb2d_idm_regs;
+ spinlock_t lock;
+ int num_phys, idm_host_enabled;
+ struct bcm_phy_instance *instances;
+};
+
+struct bcm_phy_instance {
+ struct bcm_phy_driver *driver;
+ struct phy *generic_phy;
+ int port;
+ int host_mode; /* 1 - Host , 0 - device */
+ int power; /* 1 -powered_on 0 -powered off */
+ struct regulator *vbus_supply;
+};
+
+static inline int
Re: [PATCH] libkmod-module: Remove directory existence check for KMOD_MODULE_BUILTIN
On Wednesday 18 February 2015 09:37 AM, Rusty Russell wrote:
> Lucas De Marchi writes:
>> On Tue, Feb 17, 2015 at 10:56 AM, Harish Jenny K N
>> wrote:
>>> usecase: two sd cards are being mounted in parallel at same time on
>>> dual core. example modules which are getting loaded is nls_cp437.
>>> While one module is being loaded , it starts creating sysfs files.
>>> meanwhile on other core, modprobe might return saying the module
>>> is KMOD_MODULE_BUILTIN, which might result in not mounting sd card.
>> an {f,}init_module() call should not return until the sysfs files are
>> created and if there is /sys/module// there should be
>> /sys/module//initstate unless the module is builtin.
>>
>> Rusty, was there any changes in this area in the kernel recently?
> Not deliberately.
>
>> Or is the creation of /sys/module/ and
>> /sys/module//initstate not atomic?
> No, it's not atomic :( That makes it unreliable (it seemed like a good
> idea in 2006 I guess).
>
> Here's what happens from a kernel side:
>
> 1) Module is marked UNFORMED.
> 2) Check there's no module by same name already. If there is, and it's
>UNFORMED or COMING, we wait.
> 3) module is marked COMING
> 4) module parses arguments.
> 5) sysfs directory and attributes are created.
> 6) module's init is called.
> 7) module is marked LIVE.
These are the operations handled in kernel after syscall/init_module is called.
Here is the list of operations which happen before point number 1)
0a) __request_module/try_then_request_module gets called from kernel.
0b) call_modprobe gets called which calls usermode modprobe to see if module is
loaded.
0c) syscall init_module gets called from modprobe.
> So, the second init_module should be waiting.
>
> I tested this by putting a sleep in the nls_cp437 init, and watching
> what modprobe did. It works correctly.
Problem here is second init_module is not yet called. if it gets called , it is
handled properly. Adding a sleep in nls_cp437 is handled properly.
We need to add sleep in module_add_modinfo_attrs ( module.c ) while creating
sysfs files(sysfs_create_file) in order to reproduce the issue I mentioned.
>
> You are checking initstate, and getting caught in the race:
>
> 783 14:33:14.170205 open("/sys/module/nls_cp437/initstate",
> O_RDONLY|O_LARGEFILE|O_CLOEXEC)
>
> You should probably check initstate *after* loading fails. It's
> possible that it's unloaded in the meantime, but the race is pretty
> narrow and unloading is unusual.
Did not get the point of checking initstate after loading fails. However we
need to handle even unusual rare cases as well.
>
> Cheers,
> Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] mtd: Qualcomm NAND controller driver
Hi, On 01/16/2015 08:18 PM, Archit Taneja wrote: Add support for the NAND controller driver for SoC's that contain EBI2. For now, the only SoC upstream that has EBI2 is IPQ806x. The patchset requires the ADM dmaengine patches posted by Andy: http://thread.gmane.org/gmane.linux.ports.arm.msm/11136 I'd really appreciate if I could get some reviews on this driver from the mtd community. Please let me know if I need to do anything to make it easier to review. Thanks, Archit Archit Taneja (5): clk: qcom: Add EBI2 clocks for IPQ806x mtd: nand: Add qcom nand controller driver Documentaion: dt: add DT bindings for Qualcomm NAND controller arm: qcom: dts: Add NAND controller node for ipq806x arm: qcom: dts: Enale NAND node on IPQ8064 AP148 pplatform .../devicetree/bindings/mtd/qcom_nandc.txt | 48 + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 32 + arch/arm/boot/dts/qcom-ipq8064.dtsi| 19 +- drivers/clk/qcom/gcc-ipq806x.c | 34 + drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/qcom_nandc.c | 1995 include/dt-bindings/clock/qcom,gcc-ipq806x.h |1 + 8 files changed, 2136 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt create mode 100644 drivers/mtd/nand/qcom_nandc.c -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] tools/thermal: tmon: UI and build system improvements
On Tue, 17 Feb 2015 18:18:28 -0800 Brian Norris wrote: > Hi, > > This patch set includes a few build system improvements and a few UI > fixes. > > The last patch is ugly, and personally, I don't care if it's > included. But it's an attempt to kill a warning. Better suggestions > are welcome. > Good improvements. Acked-by: Jacob Pan > Thanks, > Brian > > Brian Norris (8): > tools/thermal: tmon: add --target-temp parameter > tools/thermal: tmon: add min/max macros > tools/thermal: tmon: tui: don't hard-code dialog window size > assumptions > tools/thermal: tmon: fixup tui windowing calculations > tools/thermal: tmon: add .gitignore > tools/thermal: tmon: support cross-compiling > tools/thermal: tmon: use pkg-config to determine library > dependencies tools/thermal: tmon: silence 'set but not used' warnings > > tools/thermal/tmon/.gitignore | 1 + > tools/thermal/tmon/Makefile | 15 --- > tools/thermal/tmon/tmon.8 | 2 ++ > tools/thermal/tmon/tmon.c | 14 -- > tools/thermal/tmon/tui.c | 45 > ++- 5 files changed, 63 > insertions(+), 14 deletions(-) create mode 100644 > tools/thermal/tmon/.gitignore > > -- > 1.9.1 > -- Jacob Pan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI / resources: Change pr_info() to pr_debug() for debug information
From: Rafael J. Wysocki
Annoying and noisy ACPI debug messages are printed with pr_info()
after the recent ACPI resources handling rework. Replace the
pr_info() with pr_debug() to reduce to noise level.
Reported-by: Borislav Petkov
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/resource.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/drivers/acpi/resource.c
===
--- linux-pm.orig/drivers/acpi/resource.c
+++ linux-pm/drivers/acpi/resource.c
@@ -46,7 +46,7 @@ static bool acpi_dev_resource_len_valid(
if (len && reslen && reslen == len && start <= end)
return true;
- pr_info("ACPI: invalid or unassigned resource %s [%016llx - %016llx]
length [%016llx]\n",
+ pr_debug("ACPI: invalid or unassigned resource %s [%016llx - %016llx]
length [%016llx]\n",
io ? "io" : "mem", start, end, len);
return false;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Remove non-standard log emphasis
On Sunday, February 15, 2015 07:43:08 PM Scot Doyle wrote:
> Remove unusual pr_info() visual emphasis introduced in ad479e7f47ca
> "ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag".
>
> Signed-off-by: Scot Doyle
Applied, thanks!
> ---
> drivers/acpi/ec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 982b67f..857175e 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -680,7 +680,7 @@ static void acpi_ec_start(struct acpi_ec *ec, bool
> resuming)
> /* Enable GPE for event processing (SCI_EVT=1) */
> if (!resuming)
> acpi_ec_submit_request(ec);
> - pr_info("+ EC started +\n");
> + pr_info("EC started\n");
> }
> spin_unlock_irqrestore(>lock, flags);
> }
> @@ -712,7 +712,7 @@ static void acpi_ec_stop(struct acpi_ec *ec, bool
> suspending)
> acpi_ec_complete_request(ec);
> clear_bit(EC_FLAGS_STARTED, >flags);
> clear_bit(EC_FLAGS_STOPPED, >flags);
> - pr_info("+ EC stopped +\n");
> + pr_info("EC stopped\n");
> }
> spin_unlock_irqrestore(>lock, flags);
> }
>
--
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 01/35] ACPI/acpi_pad: Remove the local apic nonsense
On Monday, February 16, 2015 07:54:12 PM Rafael J. Wysocki wrote:
> On Monday, February 16, 2015 01:14:36 PM Peter Zijlstra wrote:
> > From: Thomas Gleixner
> >
> > While looking through the (ab)use of the clockevents_notify() function
> > I stumbled over the following gem in the acpi_pad code:
> >
> > if (lapic_detected_unstable && !lapic_marked_unstable) {
> > /* LAPIC could halt in idle, so notify users */
> > for_each_online_cpu(i)
> >clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, );
> > lapic_marked_unstable = 1;
> > }
> >
> > This code calls on the cpu which detects the lapic unstable condition
> > first clockevents_notify() to tell the core code that the broadcast
> > should be enabled on all online cpus. Brilliant stuff that as it
> > notifies the core code a num_online_cpus() times that the broadcast
> > should be enabled on the current cpu.
> >
> > This probably has never been noticed because that code got never
> > tested with NOHZ=n and HIGHRES_TIMER=n or it just worked by chance
> > because one of the other mechanisms told the core in the right way
> > that the local apic timer is wreckaged.
> >
> > Sigh, this is:
> >
> > - The 4th incarnation of idle drivers which has their own mechanism
> >to detect and deal with X86_FEATURE_ARAT.
> >
> > - The 2nd incarnation of fake idle mechanisms with a different set of
> >brainmelting bugs.
> >
> > - Has been merged against an explicit NAK of the scheduler
> >maintainer with the promise to improve it over time.
> >
> > - Another example of featuritis driven trainwreck engineering.
> >
> > - Another pointless waste of my time.
> >
> > Fix this nonsense by removing that lapic detection and notification
> > logic and simply call into the clockevents code unconditonally. The
> > ARAT feature is marked in the lapic clockevent already so the core
> > code will just ignore the requests and return.
> >
> > Signed-off-by: Thomas Gleixner
> > Cc: "Rafael J. Wysocki"
>
> Acked-by: Rafael J. Wysocki
Or I can apply it right away if you want me to.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] phy: add phy-hi6220-usb
Hi, Kishon On 02/18/2015 01:35 PM, Kishon Vijay Abraham I wrote: Hi, On Thursday 12 February 2015 01:07 PM, Zhangfei Gao wrote: Add usb phy controller for hi6220 platform Signed-off-by: Zhangfei Gao --- drivers/phy/Kconfig | 9 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-hi6220-usb.c | 306 +++ 3 files changed, 316 insertions(+) create mode 100644 drivers/phy/phy-hi6220-usb.c why is this driver in drivers/phy when it doesn't use the generic PHY framework at all? Balbi recommended "new drivers only on drivers/phy/", including usb phy. So Move drivers/usb/phy/phy-hi6220-usb.c to drivers/phy/phy-hi6220-usb.c, required by Balbi. 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 v4 4/4] phy: add phy-hi6220-usb
Hi,
On Thursday 12 February 2015 01:07 PM, Zhangfei Gao wrote:
Add usb phy controller for hi6220 platform
Signed-off-by: Zhangfei Gao
---
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-hi6220-usb.c | 306 +++
3 files changed, 316 insertions(+)
create mode 100644 drivers/phy/phy-hi6220-usb.c
why is this driver in drivers/phy when it doesn't use the generic PHY framework
at all?
-Kishon
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..40a1ef1 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -162,6 +162,15 @@ config PHY_HIX5HD2_SATA
help
Support for SATA PHY on Hisilicon hix5hd2 Soc.
+config PHY_HI6220_USB
+ tristate "hi6220 USB PHY support"
+ select USB_PHY
+ select MFD_SYSCON
+ help
+ Enable this to support the HISILICON HI6220 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..ec43c2d 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_TI_PIPE3)+=
phy-ti-pipe3.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
obj-$(CONFIG_PHY_HIX5HD2_SATA)+= phy-hix5hd2-sata.o
+obj-$(CONFIG_PHY_HI6220_USB) += phy-hi6220-usb.o
obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
obj-$(CONFIG_PHY_SAMSUNG_USB2)+= phy-exynos-usb2.o
phy-exynos-usb2-y += phy-samsung-usb2.o
diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
new file mode 100644
index 000..0d9f5ac
--- /dev/null
+++ b/drivers/phy/phy-hi6220-usb.c
@@ -0,0 +1,306 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SC_PERIPH_CTRL40x00c
+
+#define CTRL4_PICO_SIDDQ BIT(6)
+#define CTRL4_PICO_OGDISABLE BIT(8)
+#define CTRL4_PICO_VBUSVLDEXT BIT(10)
+#define CTRL4_PICO_VBUSVLDEXTSEL BIT(11)
+#define CTRL4_OTG_PHY_SEL BIT(21)
+
+#define SC_PERIPH_CTRL50x010
+
+#define CTRL5_USBOTG_RES_SEL BIT(3)
+#define CTRL5_PICOPHY_ACAENB BIT(4)
+#define CTRL5_PICOPHY_BC_MODE BIT(5)
+#define CTRL5_PICOPHY_CHRGSEL BIT(6)
+#define CTRL5_PICOPHY_VDATSRCEND BIT(7)
+#define CTRL5_PICOPHY_VDATDETENB BIT(8)
+#define CTRL5_PICOPHY_DCDENB BIT(9)
+#define CTRL5_PICOPHY_IDDIGBIT(10)
+
+#define SC_PERIPH_CTRL80x018
+#define SC_PERIPH_RSTEN0 0x300
+#define SC_PERIPH_RSTDIS0 0x304
+
+#define RST0_USBOTG_BUSBIT(4)
+#define RST0_POR_PICOPHY BIT(5)
+#define RST0_USBOTGBIT(6)
+#define RST0_USBOTG_32KBIT(7)
+
+#define EYE_PATTERN_PARA 0x7053348c
+
+struct hi6220_priv {
+ struct usb_phy phy;
+ struct delayed_work work;
+ struct regmap *reg;
+ struct clk *clk;
+ struct regulator *vcc;
+ struct device *dev;
+ int gpio_vbus;
+ int gpio_id;
+ enum usb_otg_state state;
+};
+
+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
+{
+ struct usb_otg *otg = priv->phy.otg;
+
+ if (!otg->gadget)
+ return;
+
+ if (on)
+ usb_gadget_connect(otg->gadget);
+ else
+ usb_gadget_disconnect(otg->gadget);
+}
+
+static void hi6220_detect_work(struct work_struct *work)
+{
+ struct hi6220_priv *priv =
+ container_of(work, struct hi6220_priv, work.work);
+ int gpio_id, gpio_vbus;
+ enum usb_otg_state state;
+
+ if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
+ return;
+
+ gpio_id = gpio_get_value_cansleep(priv->gpio_id);
+ gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
+
+ if (gpio_vbus == 0) {
+ if (gpio_id == 1)
+ state = OTG_STATE_B_PERIPHERAL;
+ else
+ state = OTG_STATE_A_HOST;
+ } else {
+ state = OTG_STATE_A_HOST;
+ }
+
+ if (priv->state != state) {
+ hi6220_start_peripheral(priv, state == OTG_STATE_B_PERIPHERAL);
+
Re: [PATCH V4] cpuidle/powernv: Read target_residency value of idle states from DT if available
On Wednesday, February 18, 2015 10:13:23 AM Preeti U Murthy wrote: > > On 02/17/2015 11:23 PM, Rafael J. Wysocki wrote: > > On Tuesday, February 17, 2015 01:29:10 PM Preeti U Murthy wrote: > >> Hi Rafael, > > > > Hi, > > > >> Can you please pull this patch ? > > > > Sorry, I wasn't sure whether or not the patch was for me to take and then > > I've been traveling lately. Applied now. > > Hi Rafael, > > I saw that the kbuild bot reported build issues around pr_warn() in this > patch. > I have fixed this and below is the corrected patch. Do let me know if I have > to send it out as a separate version/RESEND tag. I've applied it, thanks! > >> Another patch based on top of this is waiting to be pulled: > >> [PATCH] driver/cpuidle-powernv: Avoid endianness conversions while parsing > >> DT > > > > OK, have you posted it already? > Yes I have. https://lkml.org/lkml/2015/2/3/24. OK, so this one does not apply for me on top of the other. Can you rebase it on top of my current linux-next branch and resend it, please? Also I'd appreciate it if someone could ACK DT-related stuff for me. > This patch is also waiting to be pulled by you. There was some confusion > around who should pull this, but since it all the code is in the driver, we > thought it would be best if you pulled it. Well, OK. If you want me to apply a patch, send it To: me and not To: someone else. If you send it To: someone else, I'll ignore it. Also ask people to review and ACK things you want me to pull, especially if that's not stuff I'm particularly familiar with (like related to DT bindings specific to your platform etc.). -- 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/
[PULL] virtio-next
The following changes since commit b97f880c8342fd6e49a02c9ef7507a678722b2b3: Merge branch 'for-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata (2015-01-21 07:54:16 +1200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/virtio-next-for-linus for you to fetch changes up to 5b40a7daf51812b35cf05d1601a779a7043f8414: virtio: don't set VIRTIO_CONFIG_S_DRIVER_OK twice. (2015-02-17 16:19:29 +1030) OK, this has the big virtio 1.0 implementation, as specified by OASIS. On top of tht is the major rework of lguest, to use PCI and virtio 1.0, to double-check the implementation. Then comes the inevitable fixes and cleanups from that work. Thanks, Rusty. Luis R. Rodriguez (1): virtual: Documentation: simplify and generalize paravirt_ops.txt Michael S. Tsirkin (23): virtio_pci: drop virtio_config dependency virtio/9p: verify device has config space virtio/blk: verify device has config space virtio/console: verify device has config space virtio/net: verify device has config space virtio/scsi: verify device has config space virtio/balloon: verify device has config space mn10300: drop dead code pci: add pci_iomap_range s390: add pci_iomap_range virtio_pci: move probe/remove code to common virtio_pci: modern driver virtio_pci_modern: reduce number of mappings virtio_pci_modern: support devices with no config virtio_balloon: coding style fixes virtio_blk: coding style fixes virtio_ring: coding style fix virtio_rng: drop extra empty line virtio_pci: Kconfig grammar fix virtio_pci: drop Kconfig warnings virtio_pci: add an option to disable legacy driver virtio_pci: add module param to force legacy mode virtio_pci_modern: drop an unused function Pawel Moll (1): virtio-mmio: Update the device to OASIS spec version Rusty Russell (53): virtio-pci: define layout for virtio 1.0 virtio_pci: macros for PCI layout offsets virtio: define VIRTIO_PCI_CAP_PCI_CFG in header. virtio: Don't expose legacy block features when VIRTIO_BLK_NO_LEGACY defined. virtio: Don't expose legacy config features when VIRTIO_CONFIG_NO_LEGACY defined. virtio_pci: use 16-bit accessor for queue_enable. virtio: don't require a config space on the console device. lguest: have --rng read from /dev/urandom not /dev/random. lguest: add operations to get/set a register from the Launcher. lguest: write more information to userspace about pending traps. lguest: add infrastructure for userspace to deliver a trap to the guest. lguest: add infrastructure to check mappings. lguest: send trap 13 through to userspace. lguest: suppress PS/2 keyboard polling. lguest: don't disable iospace. lguest: add iomem region, where guest page faults get sent to userspace. lguest: disable ACPI explicitly. lguest: Override pcibios_enable_irq/pcibios_disable_irq to our stupid PIC lguest: add MMIO region allocator in example launcher. lguest: decode mmio accesses for PCI in example launcher. lguest: add PCI config space emulation to example launcher. lguest: implement virtio-PCI MMIO accesses. lguest: fix failure to find linux/virtio_types.h lguest: add a dummy PCI host bridge. lguest: Convert block device to virtio 1.0 PCI. lguest: Convert net device to virtio 1.0 PCI. lguest: Convert entropy device to virtio 1.0 PCI. lguest: Convert console device to virtio 1.0 PCI. lguest: define VIRTIO_CONFIG_NO_LEGACY in example launcher. lguest: remove support for lguest bus. lguest: remove support for lguest bus in demonstration launcher. lguest: remove lguest bus definitions from header. lguest: support emerg_wr in console device in example launcher. lguest: support backdoor window. lguest: always put console in PCI slot #1. lguest: use the PCI console device's emerg_wr for early boot messages. lguest: remove NOTIFY facility from demonstration launcher. lguest: remove NOTIFY call and eventfd facility. tools/lguest: handle device reset correctly in example launcher. tools/lguest: fix features_accepted logic in example launcher. tools/lguest: rename virtio_pci_cfg_cap field to match spec. tools/lguest: insert device references from the 1.0 spec (4.1 Virtio Over PCI) tools/lguest: insert driver references from the 1.0 spec (4.1 Virtio Over PCI) tools/lguest: handle indirect partway through chain. tools/lguest: don't start devices until DRIVER_OK status set. lguest: don't look in console features to find emerg_wr. tools/lguest: more documentation
Re: [PATCH 3.2 082/152] virtio: use dev_to_virtio wrapper in virtio
Ben Hutchings writes: > On Tue, 2015-02-17 at 15:56 +1030, Rusty Russell wrote: >> Ben Hutchings writes: >> > 3.2.67-rc1 review patch. If anyone has any objections, please let me know. >> >> Ben, what are your criteria for putting patches into 3.2? >> >> This patch is a trivial cleanup. It doesn't fix anything, but it does >> add some churn. > > It fixes the definition of dev_to_virtio(). Argh, sorry I should have caught that. The commit message didn't actually mention that it fixed anything (and I took it). :( >> I can see that 083 and 084 follow this, but 083 needed a backport >> anyway. > > Patch 083 "virtio_pci: defer kfree until release callback" uses > dev_to_virtio(_d) which would expand to a syntax error without this. > >> And it wasn't an issue we saw in Real Life (device removal >> is rare), so it wasn't CC: stable. >> >> 084 was a comment addition. Backporting that just seems weird. > > Nevertheless, it had 'cc: stable' and is obviously harmless. Ah I see, you stripped the cc:stable in your version. The original did indeed have CC:stable, which is MST's perogative... Thanks for the explanation, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] HID: wacom: add full support of the Wacom Bamboo PAD
On Tue, Feb 17, 2015 at 02:27:13PM -0500, Benjamin Tissoires wrote:
> The stylus of this device works just fine out of the box.
> The touch is seen by default as a mouse with relative events and some
> gestures.
> Switching the default in raw mode allows us to retrieve the touch data
> and have a consistent user experience accross all the multitouch touchpads.
>
> Note that the buttons of this devices are reported through the touch
> interface. There is no 'Pad' interface. It seemed more natural to have
> the BTN_LEFT and BTN_RIGHT reported with the touch because they are
> placed under the touch interface and it looks like they belong to the
> touch part.
>
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi,
>
> several things before we can merge this:
>
> Josep, Frederic:
> Would you mind testing this patch with your Bamboo pads? I bought the wireless
> variant and the USB one has a different ProductID. Hopefully, it will go
> smoothly with the current patch.
>
> Peter, Ping, Jason:
> Given the nature of the device, I did not exported the 2 buttons as a separate
> pad device.
> Do you back me up with this choice?
yeah, agree - this looks more like a touchpad than a touch-enabled tablet.
Cheers,
Peter
> Jiri:
> As mentioned to Josep and Frederic, this has not been tested against the USB
> (wired) version of the device. So please wait at least for one tested-by
> before
> considering including this patch.
>
> Thanks everyone!
> Benjamin
>
> drivers/hid/wacom_sys.c | 23 ++
> drivers/hid/wacom_wac.c | 62
> +
> drivers/hid/wacom_wac.h | 3 +++
> 3 files changed, 88 insertions(+)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index e1ec192..ef4d147 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -410,6 +410,9 @@ static int wacom_query_tablet_data(struct hid_device
> *hdev,
> else if (features->type == WACOM_27QHDT) {
> return wacom_set_device_mode(hdev, 131, 3, 2);
> }
> + else if (features->type == BAMBOO_PAD) {
> + return wacom_set_device_mode(hdev, 2, 2, 3);
> + }
> } else if (features->device_type == BTN_TOOL_PEN) {
> if (features->type <= BAMBOO_PT && features->type != WIRELESS) {
> return wacom_set_device_mode(hdev, 2, 2, 2);
> @@ -1417,6 +1420,20 @@ static int wacom_probe(struct hid_device *hdev,
> goto fail_allocate_inputs;
> }
>
> + /*
> + * Bamboo Pad has a generic hid handling for the Pen, and we switch it
> + * into debug mode for the touch part.
> + * We ignore the other interfaces.
> + */
> + if (features->type == BAMBOO_PAD) {
> + if (features->pktlen == WACOM_PKGLEN_PENABLED) {
> + features->type = HID_GENERIC;
> + } else if (features->pktlen != WACOM_PKGLEN_BP_TOUCH) {
> + error = -ENODEV;
> + goto fail_shared_data;
> + }
> + }
> +
> /* set the default size in case we do not get them from hid */
> wacom_set_default_phy(features);
>
> @@ -1451,6 +1468,12 @@ static int wacom_probe(struct hid_device *hdev,
> features->y_max = 4096;
> }
>
> + /*
> + * Same thing for Bamboo PAD
> + */
> + if (features->type == BAMBOO_PAD)
> + features->device_type = BTN_TOOL_FINGER;
> +
> if (hdev->bus == BUS_BLUETOOTH)
> features->quirks |= WACOM_QUIRK_BATTERY;
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 1a65079..8627581 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1826,6 +1826,49 @@ static int wacom_bpt_irq(struct wacom_wac *wacom,
> size_t len)
> return 0;
> }
>
> +static int wacom_bamboo_pad_irq(struct wacom_wac *wacom, size_t len)
> +{
> + struct input_dev *input = wacom->input;
> + unsigned char *data = wacom->data;
> + unsigned char *finger_data, prefix;
> + unsigned id;
> + int x, y;
> + bool valid;
> +
> + /* bit 2 in data[1] is set when there is touch information available */
> + if ((len != WACOM_PKGLEN_BP_TOUCH) ||
> + (data[0] != WACOM_REPORT_BP_TOUCH) ||
> + !(data[1] & 0x02))
> + return 0;
> +
> + prefix = data[9];
> +
> + for (id = 0; id < wacom->features.touch_max; id++) {
> + valid = !!(prefix & BIT(id)) &&
> + !wacom->shared->stylus_in_proximity;
> +
> + input_mt_slot(input, id);
> + input_mt_report_slot_state(input, MT_TOOL_FINGER, valid);
> +
> + if (!valid)
> + continue;
> +
> + finger_data = data + 10 + id * 3;
> + x = finger_data[0] | ((finger_data[1] & 0x0f) << 8);
> + y = (finger_data[2] << 4) | (finger_data[1] >> 4);
>
Re: [PATCH 1/3] perf, x86: Add new cache events table for Haswell
On Thu, Feb 12, 2015 at 10:28:06PM +0100, Peter Zijlstra wrote:
> 1) SDM (2014-09) says in 18.9.5 (snb offcore):
>
> "software must set at least one request type bit and a valid response
> type pattern"
>
> and
>
> "A valid response type must be a non-zero value of the following
> expression:
>
> ANY | [('OR' of Supplier Info Bits) & ('OR' of Snoop Info Bits)]"
>
> Is this still valid for the HSW part?
Yes.
However they need to be set on Sandy Bridge to work around an issue.
On HSW they don't hurt at least.
> #define HSW_LLC_ACCESS(HSW_ANY_RESPONSE)
> #define HSW_LLC_MISS (HSW_L3_MISS|HSW_ANY_SNOOP)
>
> Would be the suitable helpers to use here. No need to set Supplier and
> Snoop bits for ANY_RESPONSE.
Ok.
> 2) I know I included it on SNB, but would SNOOP_HITM really be a miss?
> From what I can tell it could be a local MtoS w/ WB or so. Do we count
> it as a miss because the WB part goes to DRAM so we still get to wait
> for it (just in the 'wrong' direction)?
SNOOP_HITM is a miss because M is only present in one cache.
So it's a miss for the requester.
>
> 3) While we're there, will we get SNOOP_FWD only for Clean forwards or
> also for the HITM forwards; the SDM is vague -- it would be nice if
> SNOOP_FWD was a selector for all remote socket snoops.
It's only for clean forwards.
>
> > + [ C(NODE) ] = {
> > + [ C(OP_READ) ] = {
> > + [ C(RESULT_ACCESS) ] = HSW_DEMAND_READ|
> > + HSW_L3_MISS_LOCAL_DRAM|HSW_SUPPLIER_NONE|
> > + HSW_ANY_SNOOP,
>
> 4) SUPPLIER_NONE; I'll interpret it as specific event that lacks other
> supplier info (as opposed to _any_ supplier). What kind of events would
> this be?
Your interpretation is right.
Ok, we can drop it. It should rarely happen.
>
> I didn't include SUPPLIER_NONE in any events on SNB, its implied by
> L3_ACCESS due to ANY, but other than that I'm not sure what to do with
> it. It seems out of place for DRAM_ANY.
>
> 5) NODE-ACCESS is _any_ DRAM;
>NODE-MISS is remote DRAM.
>
> for SNB I didn't include NON_DRAM in ANY_SNOOP for this reason.
>
> #define HSW_DRAM_ANY (HSW_LLC_MISS & ~HSW_SNOOP_NON_DRAM)
> #define HSW_DRAM_REMOTE (HSW_MISS_LOCAL_DRAM|HSW_ANY_SNOOP &
> ~HSW_SNOOP_NON_DRAM)
This should be more like
HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1|HSW_L3_MISS_REMOTE_HOP2P|HSW_ANY_SNOOP
& ~HSW_SNOOP_NON_DRAM)
>
> 6) Should we maybe use
>
> (SNOOP_ANY & ~(SNOOP_HIT_NO_FWD|NON_DRAM))
>
> instead for DRAM_REMOTE? SNOOP_HIT_NO_FWD seem as inappropriate as
> NON_DRAM for REMOTE.
SNOOP_HIT_NO_FWD indicates DRAM.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v3] drivers/core/of: Add symlink to device-tree from devices with an OF node
On Wed, Feb 18, 2015 at 11:25:18AM +1100, Benjamin Herrenschmidt wrote: > So I've been annoyed lately with having a bunch of devices such as i2c > eeproms (for use by VPDs, server world !) and other bits and pieces that > I want to be able to identify from userspace, and possibly provide > additional data about from FW. > > Basically, it boils down to correlating the sysfs device with the OF > tree device node, so that user space can use device-tree info such as > additional "location" or "label" (or whatever else we can come up with) > propreties to identify a given device, or get some attributes of use > about it, etc... > > Now, so far, we've done that in some subsystem in a fairly ad-hoc basis > using "devspec" properties. For example, PCI creates them if it can > correlate the probed device with a DT node. Some powerpc specific busses > do that too. > > However, i2c doesn't and it would be nice to have something more generic > since technically any device can have a corresponding device tree node. > > This patch adds an "of_node" symlink to devices that have a non-NULL > dev->of_node pointer, the patch is pretty trivial and seems to work just > fine for me. > > Signed-off-by: Benjamin Herrenschmidt > --- > > This addresses Greg's comments. Note that I'm not 100% certain about > using device_add_class_symlinks(), I had to put the code before the > test for dev->class, maybe we should rename that function to > device_add_symlinks() > if it grows beyond the class bits ? That would probably be a good idea, but we can leave it for now. > Also there was nothing that I could find in Documentation/ABI that > documented "core" device properties, it's all in > Documentation/sysfs-rules.txt, but as suggested by Greg (on IRC) I > went for ABI anyway, so I've added a file for "generic" properties > and added that one in. I'm happy to change it if you think that's not > right, just let me know where you want things. It looks good as-is, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v3] drivers/core/of: Add symlink to device-tree from devices with an OF node
On Tue, Feb 17, 2015 at 07:07:14PM -0600, Rob Herring wrote: > On Tue, Feb 17, 2015 at 6:25 PM, Benjamin Herrenschmidt > wrote: > > So I've been annoyed lately with having a bunch of devices such as i2c > > eeproms (for use by VPDs, server world !) and other bits and pieces that > > I want to be able to identify from userspace, and possibly provide > > additional data about from FW. > > > > Basically, it boils down to correlating the sysfs device with the OF > > tree device node, so that user space can use device-tree info such as > > additional "location" or "label" (or whatever else we can come up with) > > propreties to identify a given device, or get some attributes of use > > about it, etc... > > > > Now, so far, we've done that in some subsystem in a fairly ad-hoc basis > > using "devspec" properties. For example, PCI creates them if it can > > correlate the probed device with a DT node. Some powerpc specific busses > > do that too. > > > > However, i2c doesn't and it would be nice to have something more generic > > since technically any device can have a corresponding device tree node. > > > > This patch adds an "of_node" symlink to devices that have a non-NULL > > dev->of_node pointer, the patch is pretty trivial and seems to work just > > fine for me. > > > > Signed-off-by: Benjamin Herrenschmidt > > Acked-by: Rob Herring Thanks, I'll queue these up after 3.20-rc1 is out. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] cpuidle/powernv: Read target_residency value of idle states from DT if available
On 02/17/2015 11:23 PM, Rafael J. Wysocki wrote:
> On Tuesday, February 17, 2015 01:29:10 PM Preeti U Murthy wrote:
>> Hi Rafael,
>
> Hi,
>
>> Can you please pull this patch ?
>
> Sorry, I wasn't sure whether or not the patch was for me to take and then
> I've been traveling lately. Applied now.
Hi Rafael,
I saw that the kbuild bot reported build issues around pr_warn() in this patch.
I have fixed this and below is the corrected patch. Do let me know if I have
to send it out as a separate version/RESEND tag.
>
>> Another patch based on top of this is waiting to be pulled:
>> [PATCH] driver/cpuidle-powernv: Avoid endianness conversions while parsing DT
>
> OK, have you posted it already?
Yes I have. https://lkml.org/lkml/2015/2/3/24. This patch is also waiting to
be pulled by you. There was some confusion around who should pull this, but
since it all the code is in the driver, we thought it would be best if you
pulled it.
Thanks
--- PATCH -
[PATCH V4] cpuidle/powernv: Read target_residency value of idle states from DT
if available
From: Preeti U Murthy
The device tree now exposes the residency values for different idle states. Read
these values instead of calculating residency from the latency values. The
values
exposed in the DT are validated for optimal power efficiency. However to
maintain
compatibility with the older firmware code which does not expose residency
values, use default values as a fallback mechanism. While at it, use better
APIs to parse the powermgmt device tree node.
Signed-off-by: Preeti U Murthy
Acked-by: Stewart Smith
Acked-by: Michael Ellerman
---
drivers/cpuidle/cpuidle-powernv.c | 69 +
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index aedec09..30d4229 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -159,69 +160,79 @@ static int powernv_add_idle_states(void)
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
const __be32 *idle_state_flags;
- const __be32 *idle_state_latency;
- u32 len_flags, flags, latency_ns;
- int i;
+ u32 len_flags, flags;
+ u32 *latency_ns, *residency_ns;
+ int i, rc;
/* Currently we have snooze statically defined */
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("opal: PowerMgmt Node not found\n");
- return nr_idle_states;
+ goto out;
}
- idle_state_flags = of_get_property(power_mgt,
"ibm,cpu-idle-state-flags", _flags);
+ idle_state_flags = of_get_property(power_mgt,
+ "ibm,cpu-idle-state-flags", _flags);
if (!idle_state_flags) {
- pr_warn("DT-PowerMgmt: missing ibm,cpu-idle-state-flags\n");
- return nr_idle_states;
+ pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-flags in
DT\n");
+ goto out;
}
- idle_state_latency = of_get_property(power_mgt,
- "ibm,cpu-idle-state-latencies-ns", NULL);
- if (!idle_state_latency) {
- pr_warn("DT-PowerMgmt: missing
ibm,cpu-idle-state-latencies-ns\n");
- return nr_idle_states;
+ dt_idle_states = len_flags / sizeof(u32);
+
+ latency_ns = kzalloc(sizeof(*latency_ns) * dt_idle_states, GFP_KERNEL);
+ rc = of_property_read_u32_array(power_mgt,
+ "ibm,cpu-idle-state-latencies-ns", latency_ns, dt_idle_states);
+ if (rc) {
+ pr_warn("cpuidle-powernv: missing
ibm,cpu-idle-state-latencies-ns in DT\n");
+ goto out_free_latency;
}
- dt_idle_states = len_flags / sizeof(u32);
+ residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states,
GFP_KERNEL);
+ rc = of_property_read_u32_array(power_mgt,
+ "ibm,cpu-idle-state-residency-ns", residency_ns,
dt_idle_states);
for (i = 0; i < dt_idle_states; i++) {
flags = be32_to_cpu(idle_state_flags[i]);
- /* Cpuidle accepts exit_latency in us and we estimate
-* target residency to be 10x exit_latency
+ /*
+* Cpuidle accepts exit_latency and target_residency in us.
+* Use default target_residency values if f/w does not expose
it.
*/
- latency_ns = be32_to_cpu(idle_state_latency[i]);
if (flags & OPAL_PM_NAP_ENABLED) {
/* Add NAP state */
strcpy(powernv_states[nr_idle_states].name, "Nap");
strcpy(powernv_states[nr_idle_states].desc, "Nap");
Re: [PATCH] vhost: support upto 509 memory regions
On Tue, Feb 17, 2015 at 04:53:45PM -0800, Eric Northup wrote: > On Tue, Feb 17, 2015 at 4:32 AM, Michael S. Tsirkin wrote: > > On Tue, Feb 17, 2015 at 11:59:48AM +0100, Paolo Bonzini wrote: > >> > >> > >> On 17/02/2015 10:02, Michael S. Tsirkin wrote: > >> > > Increasing VHOST_MEMORY_MAX_NREGIONS from 65 to 509 > >> > > to match KVM_USER_MEM_SLOTS fixes issue for vhost-net. > >> > > > >> > > Signed-off-by: Igor Mammedov > >> > > >> > This scares me a bit: each region is 32byte, we are talking > >> > a 16K allocation that userspace can trigger. > >> > >> What's bad with a 16K allocation? > > > > It fails when memory is fragmented. > > > >> > How does kvm handle this issue? > >> > >> It doesn't. > >> > >> Paolo > > > > I'm guessing kvm doesn't do memory scans on data path, > > vhost does. > > > > qemu is just doing things that kernel didn't expect it to need. > > > > Instead, I suggest reducing number of GPA<->HVA mappings: > > > > you have GPA 1,5,7 > > map them at HVA 11,15,17 > > then you can have 1 slot: 1->11 > > > > To avoid libc reusing the memory holes, reserve them with MAP_NORESERVE > > or something like this. > > This works beautifully when host virtual address bits are more > plentiful than guest physical address bits. Not all architectures > have that property, though. AFAIK this is pretty much a requirement for both kvm and vhost, as we require each guest page to also be mapped in qemu memory. > > We can discuss smarter lookup algorithms but I'd rather > > userspace didn't do things that we then have to > > work around in kernel. > > > > > > -- > > MST > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libkmod-module: Remove directory existence check for KMOD_MODULE_BUILTIN
Lucas De Marchi writes:
> On Tue, Feb 17, 2015 at 10:56 AM, Harish Jenny K N
> wrote:
>> usecase: two sd cards are being mounted in parallel at same time on
>> dual core. example modules which are getting loaded is nls_cp437.
>> While one module is being loaded , it starts creating sysfs files.
>> meanwhile on other core, modprobe might return saying the module
>> is KMOD_MODULE_BUILTIN, which might result in not mounting sd card.
>
> an {f,}init_module() call should not return until the sysfs files are
> created and if there is /sys/module// there should be
> /sys/module//initstate unless the module is builtin.
>
> Rusty, was there any changes in this area in the kernel recently?
Not deliberately.
> Or is the creation of /sys/module/ and
> /sys/module//initstate not atomic?
No, it's not atomic :( That makes it unreliable (it seemed like a good
idea in 2006 I guess).
Here's what happens from a kernel side:
1) Module is marked UNFORMED.
2) Check there's no module by same name already. If there is, and it's
UNFORMED or COMING, we wait.
3) module is marked COMING
4) module parses arguments.
5) sysfs directory and attributes are created.
6) module's init is called.
7) module is marked LIVE.
So, the second init_module should be waiting.
I tested this by putting a sleep in the nls_cp437 init, and watching
what modprobe did. It works correctly.
You are checking initstate, and getting caught in the race:
783 14:33:14.170205 open("/sys/module/nls_cp437/initstate",
O_RDONLY|O_LARGEFILE|O_CLOEXEC)
You should probably check initstate *after* loading fails. It's
possible that it's unloaded in the meantime, but the race is pretty
narrow and unloading is unusual.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 next] RDMA/ocrdma: ocrdma_free_pd_pool() can be static
drivers/infiniband/hw/ocrdma/ocrdma_hw.c:1510:6: sparse: symbol
'ocrdma_free_pd_pool' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
ocrdma_hw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index ec4571b..037893a 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -1507,7 +1507,7 @@ void ocrdma_alloc_pd_pool(struct ocrdma_dev *dev)
}
}
-void ocrdma_free_pd_pool(struct ocrdma_dev *dev)
+static void ocrdma_free_pd_pool(struct ocrdma_dev *dev)
{
ocrdma_mbx_dealloc_pd_range(dev);
kfree(dev->pd_mgr->pd_norm_bitmap);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[next:master 10115/10230] drivers/infiniband/hw/ocrdma/ocrdma_hw.c:1510:6: sparse: symbol 'ocrdma_free_pd_pool' was not declared. Should it be static?
tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: c26de6d26435059245babb016acb840d9e0e5d12 commit: 72278f474221abd5c09af5d3a4dff39f9d10948f [10115/10230] RDMA/ocrdma: Move PD resource management to driver. reproduce: # apt-get install sparse git checkout 72278f474221abd5c09af5d3a4dff39f9d10948f make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) drivers/infiniband/hw/ocrdma/ocrdma_hw.c:109:15: sparse: cast to restricted __le32 >> drivers/infiniband/hw/ocrdma/ocrdma_hw.c:1510:6: sparse: symbol >> 'ocrdma_free_pd_pool' was not declared. Should it be static? drivers/infiniband/hw/ocrdma/ocrdma_hw.c:1594:34: sparse: cast from restricted __le32 drivers/infiniband/hw/ocrdma/ocrdma_hw.c:1595:34: sparse: cast from restricted __le32 Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[next:master 10113/10230] drivers/infiniband/hw/ocrdma/ocrdma_stats.c:253:5: sparse: symbol 'ocrdma_sysfs_rcv_pkts' was not declared. Should it be static?
tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: c26de6d26435059245babb016acb840d9e0e5d12 commit: 8b528884f901757fb21c5900151fc294344d78f6 [10113/10230] RDMA/ocrdma: Add support for IB stack compliant stats in sysfs. reproduce: # apt-get install sparse git checkout 8b528884f901757fb21c5900151fc294344d78f6 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/infiniband/hw/ocrdma/ocrdma_stats.c:253:5: sparse: symbol >> 'ocrdma_sysfs_rcv_pkts' was not declared. Should it be static? >> drivers/infiniband/hw/ocrdma/ocrdma_stats.c:264:5: sparse: symbol >> 'ocrdma_sysfs_rcv_data' was not declared. Should it be static? >> drivers/infiniband/hw/ocrdma/ocrdma_stats.c:317:5: sparse: symbol >> 'ocrdma_sysfs_xmit_pkts' was not declared. Should it be static? >> drivers/infiniband/hw/ocrdma/ocrdma_stats.c:332:5: sparse: symbol >> 'ocrdma_sysfs_xmit_data' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 next] RDMA/ocrdma: ocrdma_sysfs_rcv_pkts() can be static
drivers/infiniband/hw/ocrdma/ocrdma_stats.c:253:5: sparse: symbol
'ocrdma_sysfs_rcv_pkts' was not declared. Should it be static?
drivers/infiniband/hw/ocrdma/ocrdma_stats.c:264:5: sparse: symbol
'ocrdma_sysfs_rcv_data' was not declared. Should it be static?
drivers/infiniband/hw/ocrdma/ocrdma_stats.c:317:5: sparse: symbol
'ocrdma_sysfs_xmit_pkts' was not declared. Should it be static?
drivers/infiniband/hw/ocrdma/ocrdma_stats.c:332:5: sparse: symbol
'ocrdma_sysfs_xmit_data' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
ocrdma_stats.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
index 9d1701f..614d1a8 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
@@ -250,7 +250,7 @@ static char *ocrdma_rx_stats(struct ocrdma_dev *dev)
return stats;
}
-u64 ocrdma_sysfs_rcv_pkts(struct ocrdma_dev *dev)
+static u64 ocrdma_sysfs_rcv_pkts(struct ocrdma_dev *dev)
{
struct ocrdma_rdma_stats_resp *rdma_stats =
(struct ocrdma_rdma_stats_resp *)dev->stats_mem.va;
@@ -261,7 +261,7 @@ u64 ocrdma_sysfs_rcv_pkts(struct ocrdma_dev *dev)
+ (u64)rx_stats->roce_frame_payload_len_drops;
}
-u64 ocrdma_sysfs_rcv_data(struct ocrdma_dev *dev)
+static u64 ocrdma_sysfs_rcv_data(struct ocrdma_dev *dev)
{
struct ocrdma_rdma_stats_resp *rdma_stats =
(struct ocrdma_rdma_stats_resp *)dev->stats_mem.va;
@@ -314,7 +314,7 @@ static char *ocrdma_tx_stats(struct ocrdma_dev *dev)
return stats;
}
-u64 ocrdma_sysfs_xmit_pkts(struct ocrdma_dev *dev)
+static u64 ocrdma_sysfs_xmit_pkts(struct ocrdma_dev *dev)
{
struct ocrdma_rdma_stats_resp *rdma_stats =
(struct ocrdma_rdma_stats_resp *)dev->stats_mem.va;
@@ -329,7 +329,7 @@ u64 ocrdma_sysfs_xmit_pkts(struct ocrdma_dev *dev)
convert_to_64bit(tx_stats->ack_pkts_lo, tx_stats->ack_pkts_hi));
}
-u64 ocrdma_sysfs_xmit_data(struct ocrdma_dev *dev)
+static u64 ocrdma_sysfs_xmit_data(struct ocrdma_dev *dev)
{
struct ocrdma_rdma_stats_resp *rdma_stats =
(struct ocrdma_rdma_stats_resp *)dev->stats_mem.va;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86, kaslr: propagate base load address calculation
On Tue, Feb 17, 2015 at 2:31 PM, Borislav Petkov wrote:
> On Tue, Feb 17, 2015 at 08:45:53AM -0800, Kees Cook wrote:
>> Maybe it should say:
>>
>> Kernel offset: disabled
>>
>> for maximum clarity?
>
> I.e.:
>
> ---
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 78c91bbf50e2..16b6043cb073 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -843,10 +843,14 @@ static void __init trim_low_memory_range(void)
> static int
> dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
> {
> - pr_emerg("Kernel Offset: 0x%lx from 0x%lx "
> -"(relocation range: 0x%lx-0x%lx)\n",
> -(unsigned long)&_text - __START_KERNEL, __START_KERNEL,
> -__START_KERNEL_map, MODULES_VADDR-1);
> + if (kaslr_enabled)
> + pr_emerg("Kernel Offset: 0x%lx from 0x%lx (relocation range:
> 0x%lx-0x%lx)\n",
> +(unsigned long)&_text - __START_KERNEL,
> +__START_KERNEL,
> +__START_KERNEL_map,
> +MODULES_VADDR-1);
> + else
> + pr_emerg("Kernel Offset: disabled\n");
>
> return 0;
> }
> ---
>
> ?
You are the best. :)
Acked-by: Kees Cook
-Kees
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASLR: fix stack randomization on 64-bit systems
On Mon, Feb 16, 2015 at 12:49 PM, Andy Lutomirski wrote:
> On 02/14/2015 09:33 AM, Kees Cook wrote:
>>
>> From: Hector Marco-Gisbert
>>
>> The issue is that the stack for processes is not properly randomized on 64
>> bit
>> architectures due to an integer overflow.
>>
>> The affected function is randomize_stack_top() in file "fs/binfmt_elf.c":
>>
>> static unsigned long randomize_stack_top(unsigned long stack_top)
>> {
>> unsigned int random_variable = 0;
>>
>> if ((current->flags & PF_RANDOMIZE) &&
>> !(current->personality & ADDR_NO_RANDOMIZE)) {
>> random_variable = get_random_int() & STACK_RND_MASK;
>> random_variable <<= PAGE_SHIFT;
>> }
>> return PAGE_ALIGN(stack_top) + random_variable;
>> return PAGE_ALIGN(stack_top) - random_variable;
>> }
>>
>> Note that, it declares the "random_variable" variable as "unsigned int".
>> Since
>> the result of the shifting operation between STACK_RND_MASK (which is
>> 0x3f on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64):
>>
>> random_variable <<= PAGE_SHIFT;
>>
>> then the two leftmost bits are dropped when storing the result in the
>> "random_variable". This variable shall be at least 34 bits long to hold
>> the
>> (22+12) result.
>>
>> These two dropped bits have an impact on the entropy of process stack.
>> Concretely, the total stack entropy is reduced by four: from 2^28 to 2^30
>> (One
>> fourth of expected entropy).
>>
>> This patch restores back the entropy by correcting the types involved in
>> the
>> operations in the functions randomize_stack_top() and
>> stack_maxrandom_size().
>>
>> The successful fix can be tested with:
>> $ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done
>> 7ffeda566000-7ffeda587000 rw-p 00:00 0
>> [stack]
>> 7fff5a332000-7fff5a353000 rw-p 00:00 0
>> [stack]
>> 7ffcdb7a1000-7ffcdb7c2000 rw-p 00:00 0
>> [stack]
>> 7ffd5e2c4000-7ffd5e2e5000 rw-p 00:00 0
>> [stack]
>> ...
>>
>> Once corrected, the leading bytes should be between 7ffc and 7fff, rather
>> than always being 7fff.
>>
>> CVE-2015-1593
>
>
> Awesome. So the vdso randomization *and* the stack randomization
> implementations were buggy. Anyone want to check the mmap and brk
> randomization implementations?
Both appear to use randomize_range() ... which, after looking at it,
is buggy. But we've just not hit it yet. It uses get_random_int() but
is modulo an unsigned long. If anything were ever to call it with a
range > MAX_INT, it would truncate...
-Kees
>
> --Andy
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: hid-sony: Prevent LED overrun
If the value written to led1 is larger than 1 (for SixAxis or Intec
controllers),
it can effect other leds on the device.
For example:
# echo 3 > /sys/class/leds/0003\:054C\:0268.0013\:\:sony1/brightness
turns on both led1 and led2, led2 does not then behave as expected through it's
own interface.
Patch limits the LEDs 'value' to the 'max brightness', thus preventing bug.
Tested with SixAxis DS3, DS4 and Intec (3rd party) controllers, via USB
connection.
Signed-off-by: Simon Wood
---
drivers/hid/hid-sony.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 31e9d25..385fa1f 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1296,6 +1296,9 @@ static void sony_led_set_brightness(struct led_classdev
*led,
drv_data->led_delay_on[n] ||
drv_data->led_delay_off[n]))) {
+ if (value > led->max_brightness)
+ value = led->max_brightness;
+
drv_data->led_state[n] = value;
/* Setting the brightness stops the blinking */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Feb 18
Hi all, Please do not add any material destined for v3.21 to your linux-next included trees until after v3.20-rc1 has been released. Changes since 20150217: The infiniband tree gained a conflict against Linus' tree. The akpm tree lost lots of patches that turned up elsewhere. Non-merge commits (relative to Linus' tree): 1637 1179 files changed, 51345 insertions(+), 21955 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 206 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (cc4f9c2a91b7 Merge tag '64bit-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the debian/ directory) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (8e6480667246 ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover) Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet bridging) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (19334920eaf7 net: dsa: Set valid phy interface type) Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in xfrm_lookup()) Merging sound-current/for-linus (9fd37810daa5 ASoC: Intel: add SNDRV_PCM_INFO_DRAIN_TRIGGER flag) Merging pci-current/for-linus (feb28979c137 of/pci: Remove duplicate kfree in of_pci_get_host_bridge_resources()) Merging wireless-drivers/master (aeb2d2a4c0ae rtlwifi: Remove logging statement that is no longer needed) Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6) Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5) Merging usb.current/usb-linus (e36f014edff7 Linux 3.19-rc7) Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in non-OF case) Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for RUGGEDCOM USB Serial Console) Merging staging.current/staging-linus (e36f014edff7 Linux 3.19-rc7) Merging char-misc.current/char-misc-linus (e36f014edff7 Linux 3.19-rc7) Merging input-current/for-linus (4ba24fef3eb3 Merge branch 'next' into for-linus) Merging crypto-current/master (96692a7305c4 crypto: tcrypt - do not allocate iv on stack for aead speed tests) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (dc4515ea26d6 scsi: always increment reference count) Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci device type in vfio_pci_probe()) Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for transhuge-stress test) Merging drm-intel-fixes/for-linux-next-fixes (bfa76d495765 Linux 3.19) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/
Re: [PATCH v2 0/2] Add epoll round robin wakeup mode
On 02/17/2015 04:09 PM, Andy Lutomirski wrote: > On Tue, Feb 17, 2015 at 12:33 PM, Jason Baron wrote: >> On 02/17/2015 02:46 PM, Andy Lutomirski wrote: >>> On Tue, Feb 17, 2015 at 11:33 AM, Jason Baron wrote: When we are sharing a wakeup source among multiple epoll fds, we end up with thundering herd wakeups, since there is currently no way to add to the wakeup source exclusively. This series introduces 2 new epoll flags, EPOLLEXCLUSIVE for adding to a wakeup source exclusively. And EPOLLROUNDROBIN which is to be used in conjunction to EPOLLEXCLUSIVE to evenly distribute the wakeups. This patch was originally motivated by a desire to improve wakeup balance and cpu usage for a listen socket() shared amongst multiple epoll fd sets. See: http://lwn.net/Articles/632590/ for previous test program and testing resutls. Epoll manpage text: EPOLLEXCLUSIVE Provides exclusive wakeups when attaching multiple epoll fds to a shared wakeup source. Must be specified with an EPOLL_CTL_ADD operation. EPOLLROUNDROBIN Provides balancing for exclusive wakeups when attaching multiple epoll fds to a shared wakeup soruce. Depends on EPOLLEXCLUSIVE being set and must be specified with an EPOLL_CTL_ADD operation. Thanks, >>> What permissions do you need on the file descriptor to do this? This >>> will be the first case where a poll-like operation has side effects, >>> and that's rather weird IMO. >>> >> So in the case where you have both non-exclusive and exclusive >> waiters, all of the non-exclusive waiters will continue to get woken >> up. However, I think you're getting at having multiple exclusive >> waiters and potentially 'starving' out other exclusive waiters. >> >> In general, I think wait queues are associated with a 'struct file', >> so I think unless you are sharing your fd table, this isn't an issue. >> However, there may be cases where this is not true? In which >> case, perhaps, we could limit this to CAP_SYS_ADMIN... > There's also SCM_RIGHTS, which can be used in conjunction with file > sealing and such. > > In general, I feel like this patch series solves a problem that isn't > well understood and does it by adding a rather strange new mechanism. > Is there really a problem that can't be addressed by more normal epoll > features? > > --Andy hmmso I dug through some of the Linux archives a bit and this problem seems to crop up every so often without resolution. So I do believe that its an issue that ppl are more generally interested in. See: http://lkml.iu.edu/hypermail/linux/kernel/1201.1/02620.html http://marc.info/?l=linux-kernel=128638781921073=2 In the latter thread, Linus suggests adding it to the "requested events" field to poll: http://marc.info/?l=linux-kernel=128639416832335=2 So, I think that this series at least moves in that suggested direction. 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/
Re: [PATCH 32/35] clockevents: Fix cpu down race for hrtimer based broadcasting
On 02/17/2015 04:09 PM, Peter Zijlstra wrote: >> [PATCH 11/35] clockevents: Cleanup dead cpu explicitely n Tue, Feb 17, 2015 at 09:33:45AM +0530, Preeti U Murthy wrote: >> On 02/16/2015 05:45 PM, Peter Zijlstra wrote: >> From: Thomas Gleixner >> @@ -428,7 +428,7 @@ static int __ref _cpu_down(unsigned int __cpu_die(cpu); /* CPU is completely dead: tell everyone. Too late to complain. */ - tick_cleanup_dead_cpu(cpu); + tick_takeover(cpu); >> >> Why is tick_handover() called after __cpu_die()? > See: [PATCH 11/35] clockevents: Cleanup dead cpu explicitely > it used to be a CPU_DEAD notifier. > But, I think, the actual reason would be that you cannot be sure its not > still ticking until its actually proper dead and buried, so trying to > take over a tick from a cpu that's still ticking is... well, suspect. Look at the changelog, it explains why tick_takeover must be called *before* __cpu_die(). The above hunk is not solving the issue, it is equivalent to the scenario where we took over broadcast duty in the CPU_DEAD phase as a consequence of which the cpu doing the hotplug operation is stuck sleeping forever. Cleanup functions can be handled after __cpu_die() for the reason that you mention above. Regards Preeti U Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 infiniband tree
On Tue, Feb 17, 2015 at 6:32 PM, Stephen Rothwell wrote: > After merging the livepatching tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0: > drivers/infiniband/hw/qib/qib.h: In function 'qib_flush_wc': > drivers/infiniband/hw/qib/qib.h:1470:1: error: expected ';' before '}' token > } > ^ > > and it went badly down hill from there :-( Weird, I could have sworn I fixed that before I pushed the tree out. Anyway I'll try adding the missing ';' again and push it out again :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/3] powerpc: Don't force ENOSYS as error on syscall fail
This patch failed to build using pseries_le_defconfig. With the change
noted below in entry_64.S, the build succeeded and seccomp mode 2 worked
correctly.
Best,
Mike Strosaker
On 02/13/2015 02:22 AM, Bogdan Purcareata wrote:
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be configured to store a user-defined error code on
return from a blacklisted syscall. Don't always set ENOSYS on
do_syscall_trace_enter failure.
Delegate setting ENOSYS in case of failure, where appropriate, to
do_syscall_trace_enter.
v3:
- keep setting ENOSYS in the syscall entry assembly for scenarios without
syscall tracing
v2:
- move setting ENOSYS as errno from the syscall entry assembly to
do_syscall_trace_enter, only in the specific case
Signed-off-by: Bogdan Purcareata
---
arch/powerpc/kernel/entry_32.S | 7 ++-
arch/powerpc/kernel/entry_64.S | 5 +++--
arch/powerpc/kernel/ptrace.c | 4 +++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 46fc0f4..b2f88cd 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -333,12 +333,12 @@ _GLOBAL(DoSyscall)
lwz r11,TI_FLAGS(r10)
andi. r11,r11,_TIF_SYSCALL_DOTRACE
bne-syscall_dotrace
-syscall_dotrace_cont:
cmplwi 0,r0,NR_syscalls
lis r10,sys_call_table@h
ori r10,r10,sys_call_table@l
slwir0,r0,2
bge-66f
+syscall_dotrace_cont:
lwzxr10,r10,r0 /* Fetch system call handler [ptr] */
mtlrr10
addir9,r1,STACK_FRAME_OVERHEAD
@@ -457,6 +457,11 @@ syscall_dotrace:
lwz r7,GPR7(r1)
lwz r8,GPR8(r1)
REST_NVGPRS(r1)
+ cmplwi 0,r0,NR_syscalls
+ lis r10,sys_call_table@h
+ ori r10,r10,sys_call_table@l
+ slwir0,r0,2
+ bge-ret_from_syscall
b syscall_dotrace_cont
syscall_exit_work:
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index d180caf2..0d22fa8 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -144,7 +144,6 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
ld r10,TI_FLAGS(r11)
andi. r11,r10,_TIF_SYSCALL_DOTRACE
bne syscall_dotrace
-.Lsyscall_dotrace_cont:
cmpldi 0,r0,NR_syscalls
bge-syscall_enosys
@@ -253,7 +252,9 @@ syscall_dotrace:
addir9,r1,STACK_FRAME_OVERHEAD
CURRENT_THREAD_INFO(r10, r1)
ld r10,TI_FLAGS(r10)
- b .Lsyscall_dotrace_cont
+ cmpldi 0,r0,NR_syscalls
+ bge-syscall_exit
Shouldn't this be .Lsyscall_exit?
+ b system_call
syscall_enosys:
li r3,-ENOSYS
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index f21897b..2edae06 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1775,13 +1775,15 @@ long do_syscall_trace_enter(struct pt_regs *regs)
secure_computing_strict(regs->gpr[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
- tracehook_report_syscall_entry(regs))
+ tracehook_report_syscall_entry(regs)) {
/*
* Tracing decided this syscall should not happen.
* We'll return a bogus call number to get an ENOSYS
* error, but leave the original number in regs->gpr[0].
*/
ret = -1L;
+ syscall_set_return_value(current, regs, ENOSYS, 0);
+ }
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs->gpr[0]);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On 02/17/15 13:48, Bjorn Andersson wrote:
> On Fri, Feb 13, 2015 at 2:13 PM, Andy Gross wrote:
>> On Thu, Jan 29, 2015 at 05:51:06PM -0800, Bjorn Andersson wrote:
>>> Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.
>>>
>>> Signed-off-by: Bjorn Andersson
>>> ---
>>> #include
>>> @@ -66,5 +237,18 @@ frequencies.
>>>
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> +
>>> + pm8921_smps1: pm8921-smps1 {
>>> + compatible = "qcom,rpm-pm8921-smps";
>>> + reg = ;
>>> +
>>> + regulator-min-microvolt = <1225000>;
>>> + regulator-max-microvolt = <1225000>;
>>> + regulator-always-on;
>>> +
>>> + bias-pull-down;
>>> +
>>> + qcom,switch-mode-frequency = <320>;
>>> + };
>>> };
>> My only comment here is that most (all but one) of the other mfd regulator
>> devices use regulators {}. Still wonder if that's what we should do.
>>
> Looking at the existing mfds they all have a list in the code of the
> regulators supported on a certain mfd. Through the use of
> regulator_desc.{of_match,regulators_node} these regulators are
> populated with properties from of_nodes matched by name (of_match)
> under the specified node (regulators_node).
> But as we've discussed in other cases it's not desirable to maintain
> these lists for the various variants of Qualcomm platforms, so I did
> choose to go with "standalone" platform devices - with matching
> through compatible and all.
>
> But that's all implementation, looking at the binding itself a
> regulator {} (clocks{} and msm_bus{}) would serve as a sort of
> grouping of children based on type. Except for the implications this
> has on the implementation I don't see much benefit of this (and in our
> case the implementation would suffer from the extra grouping).
>
>
> Let me know what you think, I based these ideas on just reading the
> existing code and bindings, and might very well have missed something.
>
The main benefit I can think of is we cut down on runtime memory bloat.
(gdb) p sizeof(struct platform_device)
$1 = 624
Multiply that by 20 regulators and you get 624 * 20 = 12480 bytes in
platform devices. If we had one platform_device for all RPM controlled
regulators that would reduce this number from ~12k to ~0.5K. It would
require of_regulator_match() and the (undesirable) lists of regulator
names for all the different pmic variants, or we would need to pick out
the regulator nodes based on compatible matching. Is that so bad? In the
other cases we were putting lots of data in the driver purely for
debugging, whereas in this case we're doing it to find nodes that we
need to hook up with regulators in software and any associated data for
that regulator.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
On 02/17/15 15:02, Bjorn Andersson wrote:
> On Thu, Feb 12, 2015 at 8:26 PM, Stephen Boyd wrote:
>> On 01/23/15 16:54, Bjorn Andersson wrote:
>>> +
>>> +static int pm8941_wled_set(struct led_classdev *cdev,
>>> +enum led_brightness value)
>>> +{
>>> + struct pm8941_wled *wled;
>>> + u8 ctrl = 0;
>>> + u16 val;
>>> + int rc;
>>> + int i;
>>> +
>>> + wled = container_of(cdev, struct pm8941_wled, cdev);
>>> +
>>> + if (value != 0)
>>> + ctrl = PM8941_WLED_REG_MOD_EN_BIT;
>>> +
>>> + val = value * PM8941_WLED_REG_VAL_MAX / LED_FULL;
>>> +
>>> + rc = regmap_update_bits(wled->regmap,
>>> + wled->addr + PM8941_WLED_REG_MOD_EN,
>>> + PM8941_WLED_REG_MOD_EN_MASK, ctrl);
>>> + if (rc)
>>> + return rc;
>>> +
>>> + for (i = 0; i < wled->cfg.num_strings; ++i) {
>>> + u8 v[2] = { val & 0xff, (val >> 8) & 0xf };
>>> +
>>> + rc = regmap_bulk_write(wled->regmap,
>>> + wled->addr + PM8941_WLED_REG_VAL_BASE + 2 * i,
>>> + v, 2);
>>> + if (rc)
>>> + return rc;
>>> + }
>>> +
>>> + rc = regmap_update_bits(wled->regmap,
>>> + wled->addr + PM8941_WLED_REG_SYNC,
>>> + PM8941_WLED_REG_SYNC_MASK, PM8941_WLED_REG_SYNC_ALL);
>>> + if (rc)
>>> + return rc;
>>> +
>>> + rc = regmap_update_bits(wled->regmap,
>>> + wled->addr + PM8941_WLED_REG_SYNC,
>>> + PM8941_WLED_REG_SYNC_MASK,
>>> PM8941_WLED_REG_SYNC_CLEAR);
>>> + return rc;
>>> +}
>> This doesn't seem to do anything for the OVP spike mentioned in this
>> patch[1]. Do you see that problem on your device? I imagine the PMIC is
>> the same.
>>
>> [1]
>> https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/?id=fef9e15072562f0f28dc7066dcdd69388df81ed3
>>
> That's odd, I can't find that fix in any officially supported releases
> for 8974 - which Courtney used as reference for this driver.
>
> Just to make sure I understand the solution; when disabling the sinks
> the over-voltage-protection sometimes triggers, so we should detect
> that and reset the ovp configuration?
>
> I presume the side effect would be that the sinks would not give any
> output until this is done?
>
It seems that commit is not very good at describing the problem. From
what I can tell, the inductor current may spike when the WLED is turned
off and the switch is stuck on (the circuit is a boost convertor). To
make sure this doesn't happen, we force an OVP so that the switch is
known to be open (i.e. off) and thus can't cause the current spike when
we disable.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 infiniband tree
Hi all,
After merging the livepatching tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0:
drivers/infiniband/hw/qib/qib.h: In function 'qib_flush_wc':
drivers/infiniband/hw/qib/qib.h:1470:1: error: expected ';' before '}' token
}
^
and it went badly down hill from there :-(
Caused by commit f72c1c08efbc ("IB/qib: Fix checkpatch warnings").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpBl1Jm5xQ7J.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 0/7] platform/chrome: Add user-space dev inferface support
Hi, On 16 February 2015 at 01:19, Javier Martinez Canillas wrote: > Hello Olof, > > On 02/02/2015 12:26 PM, Javier Martinez Canillas wrote: >> Hello, >> >> The mainline ChromeOS Embedded Controller (EC) driver is still missing some >> features that are present in the downstream ChromiumOS tree. These are: >> >> - Low Pin Count (LPC) interface >> - User-space device interface >> - Access to vboot context stored on a block device >> - Access to vboot context stored on EC's nvram >> - Power Delivery Device >> - Support for multiple EC in a system >> >> This is a fifth version of a series that adds support for the first two of >> the missing features: the EC LPC and EC character device interfaces that >> are used by user-space to access the ChromeOS EC. The support patches were >> taken from the downstream ChromiumOS 3.14 tree with the fixes and cleanups >> squashed to have a minimal patch-set. >> > > Any comments on this series? The last version was posted a couple of weeks > ago but the series have been in the list for months. Lee has already acked > the mfd changes so you can merge all through your chrome-platform tree if > you want. > > It wold be great if this series get in to have the EC user-space interface > supported and to minimize the delta with the Chromemium OS kernel since it > still has other features that needs to be upstreamed like multiple EC in a > system and access to vboot context stored in block device or EC's nvram. Are you sure Olof is the right maintainer for this going to mainline? I do feel for you trying to get all this in and have seen your many attempts. It has been in U-Boot for 18 months...I hope you get there in the end. Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] HID: hid-lg4ff: Improve handling of Logitech multimode gaming wheels
> This patch series improves handling of various Logitech gaming wheels and > allows switching between various compatibility modes which might be useful > to improve compatibility with very old games and testing purposes. > > Signed-off-by: Michal Malý > > v2: - Rebased against latest linux-next > - Document the newly introduced sysfs interfaces in appropriate > commits > - Assume that we are targeting kernel version 4.1 > - Fix a misleading error message regarding unsupported wheel mode This version looks good to me; tested with WiiWheel, DFP and G27. Thanks, Simon -- tested-by: Simon Wood -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] tools/thermal: tmon: tui: don't hard-code dialog window size assumptions
We can use the ncurses API to get the number of rows.
Signed-off-by: Brian Norris
---
tools/thermal/tmon/tui.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/thermal/tmon/tui.c b/tools/thermal/tmon/tui.c
index 43c5aecf71da..2779573a53cb 100644
--- a/tools/thermal/tmon/tui.c
+++ b/tools/thermal/tmon/tui.c
@@ -274,11 +274,14 @@ const char DIAG_TITLE[] = "[ TUNABLES ]";
void show_dialogue(void)
{
int j, x = 0, y = 0;
+ int rows, cols;
WINDOW *w = dialogue_window;
if (tui_disabled || !w)
return;
+ getmaxyx(w, rows, cols);
+
werase(w);
box(w, 0, 0);
mvwprintw(w, 0, maxx/4, DIAG_TITLE);
@@ -297,10 +300,8 @@ void show_dialogue(void)
wattron(w, A_BOLD);
mvwprintw(w, DIAG_DEV_ROWS+1, 1, "Enter Choice [A-Z]?");
wattroff(w, A_BOLD);
- /* y size of dialogue win is nr cdev + 5, so print legend
-* at the bottom line
-*/
- mvwprintw(w, ptdata.nr_cooling_dev+3, 1,
+ /* print legend at the bottom line */
+ mvwprintw(w, rows - 2, 1,
"Legend: A=Active, P=Passive, C=Critical");
wrefresh(dialogue_window);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] tools/thermal: tmon: add --target-temp parameter
If we launch in daemon mode (--daemon), we don't have the ncurses UI,
but we might want to set the target temperature still. For example,
someone might stick the following in their boot script:
tmon --control intel_powerclamp --target-temp 90 --log --daemon
This would turn on CPU idle injection when we're around 90 degrees
celsius, and would log temperature and throttling info to
/var/tmp/tmon.log.
Signed-off-by: Brian Norris
---
tools/thermal/tmon/tmon.8 | 2 ++
tools/thermal/tmon/tmon.c | 14 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/tools/thermal/tmon/tmon.8 b/tools/thermal/tmon/tmon.8
index 0be727cb9892..02d5179803aa 100644
--- a/tools/thermal/tmon/tmon.8
+++ b/tools/thermal/tmon/tmon.8
@@ -55,6 +55,8 @@ The \fB-l --log\fP option write data to /var/tmp/tmon.log
.PP
The \fB-t --time-interval\fP option sets the polling interval in seconds
.PP
+The \fB-T --target-temp\fP option sets the initial target temperature
+.PP
The \fB-v --version\fP option shows the version of \fBtmon \fP
.PP
The \fB-z --zone\fP option sets the target therma zone instance to be
controlled
diff --git a/tools/thermal/tmon/tmon.c b/tools/thermal/tmon/tmon.c
index 09b7c3218334..9aa19652e8e8 100644
--- a/tools/thermal/tmon/tmon.c
+++ b/tools/thermal/tmon/tmon.c
@@ -64,6 +64,7 @@ void usage()
printf(" -h, --helpshow this help message\n");
printf(" -l, --log log data to /var/tmp/tmon.log\n");
printf(" -t, --time-interval sampling time interval, > 1 sec.\n");
+ printf(" -T, --target-temp initial target temperature\n");
printf(" -v, --version show version\n");
printf(" -z, --zonetarget thermal zone id\n");
@@ -219,6 +220,7 @@ static struct option opts[] = {
{ "control", 1, NULL, 'c' },
{ "daemon", 0, NULL, 'd' },
{ "time-interval", 1, NULL, 't' },
+ { "target-temp", 1, NULL, 'T' },
{ "log", 0, NULL, 'l' },
{ "help", 0, NULL, 'h' },
{ "version", 0, NULL, 'v' },
@@ -231,7 +233,7 @@ int main(int argc, char **argv)
{
int err = 0;
int id2 = 0, c;
- double yk = 0.0; /* controller output */
+ double yk = 0.0, temp; /* controller output */
int target_tz_index;
if (geteuid() != 0) {
@@ -239,7 +241,7 @@ int main(int argc, char **argv)
exit(EXIT_FAILURE);
}
- while ((c = getopt_long(argc, argv, "c:dlht:vgz:", opts, )) != -1) {
+ while ((c = getopt_long(argc, argv, "c:dlht:T:vgz:", opts, )) !=
-1) {
switch (c) {
case 'c':
no_control = 0;
@@ -254,6 +256,14 @@ int main(int argc, char **argv)
if (ticktime < 1)
ticktime = 1;
break;
+ case 'T':
+ temp = strtod(optarg, NULL);
+ if (temp < 0) {
+ fprintf(stderr, "error: temperature must be
positive\n");
+ return 1;
+ }
+ target_temp_user = temp;
+ break;
case 'l':
printf("Logging data to /var/tmp/tmon.log\n");
logging = 1;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] tools/thermal: tmon: UI and build system improvements
Hi, This patch set includes a few build system improvements and a few UI fixes. The last patch is ugly, and personally, I don't care if it's included. But it's an attempt to kill a warning. Better suggestions are welcome. Thanks, Brian Brian Norris (8): tools/thermal: tmon: add --target-temp parameter tools/thermal: tmon: add min/max macros tools/thermal: tmon: tui: don't hard-code dialog window size assumptions tools/thermal: tmon: fixup tui windowing calculations tools/thermal: tmon: add .gitignore tools/thermal: tmon: support cross-compiling tools/thermal: tmon: use pkg-config to determine library dependencies tools/thermal: tmon: silence 'set but not used' warnings tools/thermal/tmon/.gitignore | 1 + tools/thermal/tmon/Makefile | 15 --- tools/thermal/tmon/tmon.8 | 2 ++ tools/thermal/tmon/tmon.c | 14 -- tools/thermal/tmon/tui.c | 45 ++- 5 files changed, 63 insertions(+), 14 deletions(-) create mode 100644 tools/thermal/tmon/.gitignore -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] tools/thermal: tmon: add min/max macros
Signed-off-by: Brian Norris
---
tools/thermal/tmon/tui.c | 12
1 file changed, 12 insertions(+)
diff --git a/tools/thermal/tmon/tui.c b/tools/thermal/tmon/tui.c
index 89f8ef0e15c8..43c5aecf71da 100644
--- a/tools/thermal/tmon/tui.c
+++ b/tools/thermal/tmon/tui.c
@@ -30,6 +30,18 @@
#include "tmon.h"
+#define min(x, y) ({ \
+ typeof(x) _min1 = (x); \
+ typeof(y) _min2 = (y); \
+ (void) (&_min1 == &_min2); \
+ _min1 < _min2 ? _min1 : _min2; })
+
+#define max(x, y) ({ \
+ typeof(x) _max1 = (x); \
+ typeof(y) _max2 = (y); \
+ (void) (&_max1 == &_max2); \
+ _max1 > _max2 ? _max1 : _max2; })
+
static PANEL *data_panel;
static PANEL *dialogue_panel;
static PANEL *top;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] tools/thermal: tmon: fixup tui windowing calculations
The number of rows in the dialog vary according to the number of cooling
devices. However, some of the windowing computations were assuming a
fixed number of rows. This computation is OK when we have between 4 and
9 cooling devices (and they wrap to the next column), but with fewer
devices, we end up printing off the end of the window.
This unifies the row computation into a single function and uses that
throughout the TUI code. This also accounts for increasing the number of
rows when there are more than 9 total cooling devices.
Signed-off-by: Brian Norris
---
tools/thermal/tmon/tui.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tools/thermal/tmon/tui.c b/tools/thermal/tmon/tui.c
index 2779573a53cb..36e1f86c8452 100644
--- a/tools/thermal/tmon/tui.c
+++ b/tools/thermal/tmon/tui.c
@@ -110,6 +110,18 @@ void write_status_bar(int x, char *line)
wrefresh(status_bar_window);
}
+/* wrap at 5 */
+#define DIAG_DEV_ROWS 5
+/*
+ * list cooling devices + "set temp" entry; wraps after 5 rows, if they fit
+ */
+static int diag_dev_rows(void)
+{
+ int entries = ptdata.nr_cooling_dev + 1;
+ int rows = max(DIAG_DEV_ROWS, (entries + 1) / 2);
+ return min(rows, entries);
+}
+
void setup_windows(void)
{
int y_begin = 1;
@@ -134,7 +146,7 @@ void setup_windows(void)
* dialogue window is a pop-up, when needed it lays on top of cdev win
*/
- dialogue_window = subwin(stdscr, ptdata.nr_cooling_dev+5, maxx-50,
+ dialogue_window = subwin(stdscr, diag_dev_rows() + 5, maxx-50,
DIAG_Y, DIAG_X);
thermal_data_window = subwin(stdscr, ptdata.nr_tz_sensor *
@@ -270,7 +282,6 @@ void show_cooling_device(void)
}
const char DIAG_TITLE[] = "[ TUNABLES ]";
-#define DIAG_DEV_ROWS 5
void show_dialogue(void)
{
int j, x = 0, y = 0;
@@ -287,7 +298,7 @@ void show_dialogue(void)
mvwprintw(w, 0, maxx/4, DIAG_TITLE);
/* list all the available tunables */
for (j = 0; j <= ptdata.nr_cooling_dev; j++) {
- y = j % DIAG_DEV_ROWS;
+ y = j % diag_dev_rows();
if (y == 0 && j != 0)
x += 20;
if (j == ptdata.nr_cooling_dev)
@@ -298,7 +309,7 @@ void show_dialogue(void)
ptdata.cdi[j].type, ptdata.cdi[j].instance);
}
wattron(w, A_BOLD);
- mvwprintw(w, DIAG_DEV_ROWS+1, 1, "Enter Choice [A-Z]?");
+ mvwprintw(w, diag_dev_rows()+1, 1, "Enter Choice [A-Z]?");
wattroff(w, A_BOLD);
/* print legend at the bottom line */
mvwprintw(w, rows - 2, 1,
@@ -450,7 +461,7 @@ static void handle_input_choice(int ch)
snprintf(buf, sizeof(buf), "New Value for %.10s-%2d: ",
ptdata.cdi[cdev_id].type,
ptdata.cdi[cdev_id].instance);
- write_dialogue_win(buf, DIAG_DEV_ROWS+2, 2);
+ write_dialogue_win(buf, diag_dev_rows() + 2, 2);
handle_input_val(cdev_id);
} else {
snprintf(buf, sizeof(buf), "Invalid selection %d", ch);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] tools/thermal: tmon: support cross-compiling
We might want to prepare CFLAGS outside of this Makefile, so don't
overwrite its initial value.
Then, support $(CROSS_COMPILE), so we can use a cross-compile toolchain.
Signed-off-by: Brian Norris
---
tools/thermal/tmon/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index e775adcbd29f..13d1876c7889 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -2,8 +2,8 @@ VERSION = 1.0
BINDIR=usr/bin
WARNFLAGS=-Wall -Wshadow -W -Wformat -Wimplicit-function-declaration
-Wimplicit-int
-CFLAGS= -O1 ${WARNFLAGS} -fstack-protector
-CC=gcc
+CFLAGS+= -O1 ${WARNFLAGS} -fstack-protector
+CC=$(CROSS_COMPILE)gcc
CFLAGS+=-D VERSION=\"$(VERSION)\"
LDFLAGS+=
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] tools/thermal: tmon: silence 'set but not used' warnings
gcc complains about the 'cols' variable being unused. This is unavoidable, given the ncurses getmaxyx() macro-based API, which wants to assign to a variable directly, even when we're not going to use it. Warning: gcc -O1 -Wall -Wshadow -W -Wformat -Wimplicit-function-declaration -Wimplicit-int -fstack-protector -D VERSION=\"1.0\" -c -o tui.o tui.c tui.c: In function ‘show_dialogue’: tui.c:288:12: warning: variable ‘cols’ set but not used [-Wunused-but-set-variable] int rows, cols; ^ So, add a hack to get rid of that warning. Signed-off-by: Brian Norris --- This patch is ugly and of little value IMO, but it does squash the warning. Take it or leave it. tools/thermal/tmon/tui.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/thermal/tmon/tui.c b/tools/thermal/tmon/tui.c index 36e1f86c8452..b5d1c6b22dd3 100644 --- a/tools/thermal/tmon/tui.c +++ b/tools/thermal/tmon/tui.c @@ -293,6 +293,9 @@ void show_dialogue(void) getmaxyx(w, rows, cols); + /* Silence compiler 'unused' warnings */ + (void)cols; + werase(w); box(w, 0, 0); mvwprintw(w, 0, maxx/4, DIAG_TITLE); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] tools/thermal: tmon: use pkg-config to determine library dependencies
Some distros (e.g., Arch Linux) don't package the tinfo library
separately from ncurses, so don't unconditionally include it. Instead,
use pkg-config.
The $(STATIC) ugliness is to handle the reported build case from commit
6b533269fb25 ("tools/thermal: tmon: fix compilation errors when building
statically"), where a developer wants to be able to build with:
make LDFLAGS=-static
which requires an additional pkg-config flag.
Finally, support a lowest common denominator fallback (-lpanel
-lncurses) for build systems that don't have pkg-config entries for
ncurses.
Signed-off-by: Brian Norris
---
tools/thermal/tmon/Makefile | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 13d1876c7889..0788621c8d76 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -16,12 +16,21 @@ INSTALL_CONFIGFILE=install -m 644 -p
CONFIG_FILE=
CONFIG_PATH=
+# Static builds might require -ltinfo, for instance
+ifneq ($(findstring -static, $(LDFLAGS)),)
+STATIC := --static
+endif
+
+TMON_LIBS=-lm -lpthread
+TMON_LIBS += $(shell pkg-config --libs $(STATIC) panelw ncursesw 2> /dev/null
|| \
+pkg-config --libs $(STATIC) panel ncurses 2> /dev/null || \
+echo -lpanel -lncurses)
OBJS = tmon.o tui.o sysfs.o pid.o
OBJS +=
tmon: $(OBJS) Makefile tmon.h
- $(CC) ${CFLAGS} $(LDFLAGS) $(OBJS) -o $(TARGET) -lm -lpanel -lncursesw
-ltinfo -lpthread
+ $(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) -o $(TARGET) $(TMON_LIBS)
valgrind: tmon
sudo valgrind -v --track-origins=yes --tool=memcheck --leak-check=yes
--show-reachable=yes --num-callers=20 --track-fds=yes ./$(TARGET) 1> /dev/null
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] tools/thermal: tmon: add .gitignore
Signed-off-by: Brian Norris --- tools/thermal/tmon/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/thermal/tmon/.gitignore diff --git a/tools/thermal/tmon/.gitignore b/tools/thermal/tmon/.gitignore new file mode 100644 index ..06e96be65276 --- /dev/null +++ b/tools/thermal/tmon/.gitignore @@ -0,0 +1 @@ +/tmon -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] perf, x86: Add INST_RETIRED.ALL workarounds
From: Andi Kleen
On Broadwell INST_RETIRED.ALL cannot be used with any period
that doesn't have the lowest 6 bits cleared. And the period
should not be smaller than 128.
Add a new callback to enforce this, and set it for Broadwell.
This is erratum BDM57 and BDM11.
How does this handle the case when an app requests a specific
period with some of the bottom bits set
The apps thinks it is sampling at X occurences per sample, when it is
in fact at X - 63 (worst case).
Short answer:
Any useful instruction sampling period needs to be 4-6 orders
of magnitude larger than 128, as an PMI every 128 instructions
would instantly overwhelm the system and be throttled.
So the +-64 error from this is really small compared to the
period, much smaller than normal system jitter.
Long answer:
IFF we guarantee perf_event_attr::sample_period >= 128.
Suppose we start out with sample_period=192; then we'll set period_left
to 192, we'll end up with left = 128 (we truncate the lower bits). We
get an interrupt, find that period_left = 64 (>0 so we return 0 and
don't get an overflow handler), up that to 128. Then we trigger again,
at n=256. Then we find period_left = -64 (<=0 so we return 1 and do get
an overflow). We increment with sample_period so we get left = 128. We
fire again, at n=384, period_left = 0 (<=0 so we return 1 and get an
overflow). And on and on.
So while the individual interrupts are 'wrong' we get then with
interval=256,128 in exactly the right ratio to average out at 192. And
this works for everything >=128.
So the num_samples*fixed_period thing is still entirely correct +- 127,
which is good enough I'd say, as you already have that error anyhow.
So no need to 'fix' the tools, al we need to do is refuse to create
INST_RETIRED:ALL events with sample_period < 128.
v2: Use correct event name in description. Use EVENT() macro.
v3: Use INTEL_ARCH_EVENT_MASK. Error out for events with too small period.
v4: Expand description.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event.c | 9 +
arch/x86/kernel/cpu/perf_event.h | 1 +
arch/x86/kernel/cpu/perf_event_intel.c | 19 +++
3 files changed, 29 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 143e5f5..66451a6 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -445,6 +445,12 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.type == PERF_TYPE_RAW)
event->hw.config |= event->attr.config & X86_RAW_EVENT_MASK;
+ if (event->attr.sample_period && x86_pmu.limit_period) {
+ if (x86_pmu.limit_period(event, event->attr.sample_period) >
+ event->attr.sample_period)
+ return -EINVAL;
+ }
+
return x86_setup_perfctr(event);
}
@@ -982,6 +988,9 @@ int x86_perf_event_set_period(struct perf_event *event)
if (left > x86_pmu.max_period)
left = x86_pmu.max_period;
+ if (x86_pmu.limit_period)
+ left = x86_pmu.limit_period(event, left);
+
per_cpu(pmc_prev_left[idx], smp_processor_id()) = left;
/*
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 4e6cdb0..6ce77bd 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -449,6 +449,7 @@ struct x86_pmu {
struct x86_pmu_quirk *quirks;
int perfctr_second_write;
boollate_ack;
+ unsigned(*limit_period)(struct perf_event *event, unsigned l);
/*
* sysfs attrs
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 259e06b..74c 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2111,6 +2111,24 @@ hsw_get_event_constraints(struct cpu_hw_events *cpuc,
struct perf_event *event)
return c;
}
+/*
+ * Broadwell:
+ * The INST_RETIRED.ALL period always needs to have lowest
+ * 6bits cleared (BDM57). It shall not use a period smaller
+ * than 100 (BDM11). We combine the two to enforce
+ * a min-period of 128.
+ */
+static unsigned bdw_limit_period(struct perf_event *event, unsigned left)
+{
+ if ((event->hw.config & INTEL_ARCH_EVENT_MASK) ==
+ X86_CONFIG(.event=0xc0, .umask=0x01)) {
+ if (left < 128)
+ left = 128;
+ left &= ~0x3fu;
+ }
+ return left;
+}
+
PMU_FORMAT_ATTR(event, "config:0-7");
PMU_FORMAT_ATTR(umask, "config:8-15" );
PMU_FORMAT_ATTR(edge, "config:18" );
@@ -2801,6 +2819,7 @@ __init int intel_pmu_init(void)
x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
x86_pmu.cpu_events = hsw_events_attrs;
+ x86_pmu.limit_period = bdw_limit_period;
[PATCH 1/3] perf, x86: Add new cache events table for Haswell
From: Andi Kleen
Haswell offcore events are quite different from Sandy Bridge.
Add a new table to handle Haswell properly.
Note that the offcore bits listed in the SDM are not quite correct
(this is currently being fixed). An uptodate list of bits is
in the patch.
The basic setup is similar to Sandy Bridge. The prefetch columns
have been removed, as prefetch counting is not very reliable
on Haswell. One L1 event that is not in the event list anymore
has been also removed.
- data reads do not include code reads (comparable to earlier Sandy
Bridge tables)
- data counts include speculative execution (except L1 write, dtlb, bpu)
- remote node access includes both remote memory, remote cache, remote mmio.
- prefetches are not included in the counts for consistency
(different from Sandy Bridge, which includes prefetches in the remote node)
The events with additional caveats have references to the specification update.
v2: Change name of variable.
v3: Based on older Broadwell patch, but now just for Haswell.
Various fixes with events being more similar to the older
Sandy Bridge tables.
v4: Add aliases. Drop two PF bits.
v5: Don't use SUPPLIER_NONE. Remote node is DRAM only. More aliases.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel.c | 195 -
1 file changed, 193 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 498b6d9..5cd7e2b 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -415,6 +415,197 @@ static __initconst const u64 snb_hw_cache_event_ids
};
+/*
+ * Notes on the events:
+ * - data reads do not include code reads (comparable to earlier tables)
+ * - data counts include speculative execution (except L1 write, dtlb, bpu)
+ * - remote node access includes remote memory, remote cache, remote mmio.
+ * - prefetches are not included in the counts because they are not
+ * reliably counted.
+ * The events with additional caveats have references to the specification
update.
+ */
+
+#define HSW_DEMAND_DATA_RD BIT_ULL(0)
+#define HSW_DEMAND_RFO BIT_ULL(1)
+#define HSW_ANY_RESPONSE BIT_ULL(16)
+#define HSW_SUPPLIER_NONE BIT_ULL(17)
+#define HSW_L3_MISS_LOCAL_DRAM BIT_ULL(22)
+#define HSW_L3_MISS_REMOTE_HOP0BIT_ULL(27)
+#define HSW_L3_MISS_REMOTE_HOP1BIT_ULL(28)
+#define HSW_L3_MISS_REMOTE_HOP2P BIT_ULL(29)
+#define HSW_L3_MISS(HSW_L3_MISS_LOCAL_DRAM| \
+
HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1| \
+HSW_L3_MISS_REMOTE_HOP2P)
+#define HSW_SNOOP_NONE BIT_ULL(31)
+#define HSW_SNOOP_NOT_NEEDED BIT_ULL(32)
+#define HSW_SNOOP_MISS BIT_ULL(33)
+#define HSW_SNOOP_HIT_NO_FWD BIT_ULL(34)
+#define HSW_SNOOP_HIT_WITH_FWD BIT_ULL(35)
+#define HSW_SNOOP_HITM BIT_ULL(36)
+#define HSW_SNOOP_NON_DRAM BIT_ULL(37)
+#define HSW_ANY_SNOOP (HSW_SNOOP_NONE| \
+HSW_SNOOP_NOT_NEEDED|HSW_SNOOP_MISS| \
+
HSW_SNOOP_HIT_NO_FWD|HSW_SNOOP_HIT_WITH_FWD| \
+HSW_SNOOP_HITM|HSW_SNOOP_NON_DRAM)
+#define HSW_SNOOP_DRAM (HSW_ANY_SNOOP & ~HSW_SNOOP_NON_DRAM)
+#define HSW_DEMAND_READHSW_DEMAND_DATA_RD
+#define HSW_DEMAND_WRITE HSW_DEMAND_RFO
+#define HSW_L3_MISS_REMOTE (HSW_L3_MISS_REMOTE_HOP0|\
+
HSW_L3_MISS_REMOTE_HOP1|HSW_L3_MISS_REMOTE_HOP2P)
+#define HSW_LLC_ACCESS HSW_ANY_RESPONSE
+
+static __initconst const u64 hsw_hw_cache_event_ids
+ [PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] =
+{
+ [ C(L1D ) ] = {
+ [ C(OP_READ) ] = {
+ [ C(RESULT_ACCESS) ] = 0x81d0, /* MEM_UOPS_RETIRED.ALL_LOADS,
HSM30 */
+ [ C(RESULT_MISS) ] = 0x151, /* L1D.REPLACEMENT */
+ },
+ [ C(OP_WRITE) ] = {
+ [ C(RESULT_ACCESS) ] = 0x82d0, /* MEM_UOPS_RETIRED.ALL_STORES,
HSM30 */
+ [ C(RESULT_MISS) ] = 0x0,
+ },
+ [ C(OP_PREFETCH) ] = {
+ [ C(RESULT_ACCESS) ] = 0x0,
+ [ C(RESULT_MISS) ] = 0x0,
+ },
+ },
+ [ C(L1I ) ] = {
+ [ C(OP_READ) ] = {
+ [ C(RESULT_ACCESS) ] = 0x0,
+ [ C(RESULT_MISS) ] = 0x280, /* ICACHE.MISSES */
+ },
+ [ C(OP_WRITE) ] = {
+ [ C(RESULT_ACCESS) ] = -1,
+ [ C(RESULT_MISS) ] = -1,
+ },
+ [ C(OP_PREFETCH) ] = {
+ [ C(RESULT_ACCESS) ] = 0x0,
+
[PATCH 2/3] perf, x86: Add Broadwell core support
From: Andi Kleen
Add Broadwell support for Broadwell to perf.
The basic support is very similar to Haswell. We use the new cache
event list added for Haswell earlier. The only differences
are a few bits related to remote nodes. To avoid an extra,
mostly identical, table these are patched up in the initialization code.
The constraint list has one new event that needs to be handled over Haswell.
Includes code and testing from Kan Liang.
v2: Remove unnamed model numbers.
v3: Rename cache event list to hsw_*. Change names.
v4: Use symbolic names for cache events. Improve comments and description.
Fix sparse warnings (Fengguang Wu)
Add Xeon D model number.
Remove cache event table (in separate patch)
Patch up remote node differences (Kan Liang)
v5: Update offcore bits
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel.c | 47 ++
1 file changed, 47 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 5cd7e2b..259e06b 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -220,6 +220,15 @@ static struct event_constraint
intel_hsw_event_constraints[] = {
EVENT_CONSTRAINT_END
};
+struct event_constraint intel_bdw_event_constraints[] = {
+ FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
+ FIXED_EVENT_CONSTRAINT(0x003c, 1), /* CPU_CLK_UNHALTED.CORE */
+ FIXED_EVENT_CONSTRAINT(0x0300, 2), /* CPU_CLK_UNHALTED.REF */
+ INTEL_UEVENT_CONSTRAINT(0x148, 0x4),/* L1D_PEND_MISS.PENDING */
+ INTEL_EVENT_CONSTRAINT(0xa3, 0x4), /* CYCLE_ACTIVITY.* */
+ EVENT_CONSTRAINT_END
+};
+
static u64 intel_pmu_event_map(int hw_event)
{
return intel_perfmon_event_map[hw_event];
@@ -454,6 +463,12 @@ static __initconst const u64 snb_hw_cache_event_ids
HSW_L3_MISS_REMOTE_HOP1|HSW_L3_MISS_REMOTE_HOP2P)
#define HSW_LLC_ACCESS HSW_ANY_RESPONSE
+#define BDW_L3_MISS_LOCAL BIT(26)
+#define BDW_L3_MISS(BDW_L3_MISS_LOCAL| \
+
HSW_L3_MISS_REMOTE_HOP0|HSW_L3_MISS_REMOTE_HOP1| \
+HSW_L3_MISS_REMOTE_HOP2P)
+
+
static __initconst const u64 hsw_hw_cache_event_ids
[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
@@ -2757,6 +2772,38 @@ __init int intel_pmu_init(void)
pr_cont("Haswell events, ");
break;
+ case 61: /* 14nm Broadwell Core-M */
+ case 86: /* 14nm Broadwell Xeon D */
+ x86_pmu.late_ack = true;
+ memcpy(hw_cache_event_ids, hsw_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
+ memcpy(hw_cache_extra_regs, hsw_hw_cache_extra_regs,
sizeof(hw_cache_extra_regs));
+
+ /* L3_MISS_LOCAL_DRAM is BIT(26) in Broadwell */
+ hw_cache_extra_regs[C(LL)][C(OP_READ)][C(RESULT_MISS)] =
HSW_DEMAND_READ |
+
BDW_L3_MISS|HSW_SNOOP_DRAM;
+ hw_cache_extra_regs[C(LL)][C(OP_WRITE)][C(RESULT_MISS)] =
HSW_DEMAND_WRITE|BDW_L3_MISS|
+
HSW_SNOOP_DRAM;
+ hw_cache_extra_regs[C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] =
HSW_DEMAND_READ|
+
BDW_L3_MISS_LOCAL|HSW_SNOOP_DRAM;
+ hw_cache_extra_regs[C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] =
HSW_DEMAND_WRITE|
+
BDW_L3_MISS_LOCAL|HSW_SNOOP_DRAM;
+
+ intel_pmu_lbr_init_snb();
+
+ x86_pmu.event_constraints = intel_bdw_event_constraints;
+ x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
+ x86_pmu.extra_regs = intel_snbep_extra_regs;
+ x86_pmu.pebs_aliases = intel_pebs_aliases_snb;
+ /* all extra regs are per-cpu when HT is on */
+ x86_pmu.er_flags |= ERF_HAS_RSP_1;
+ x86_pmu.er_flags |= ERF_NO_HT_SHARING;
+
+ x86_pmu.hw_config = hsw_hw_config;
+ x86_pmu.get_event_constraints = hsw_get_event_constraints;
+ x86_pmu.cpu_events = hsw_events_attrs;
+ pr_cont("Broadwell events, ");
+ break;
+
default:
switch (x86_pmu.version) {
case 1:
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] leds: Introduce devres helper for led_classdev_register
Suggested-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
drivers/leds/led-class.c | 28
include/linux/leds.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index dbeebac..7233f30 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -285,6 +285,34 @@ void led_classdev_unregister(struct led_classdev *led_cdev)
}
EXPORT_SYMBOL_GPL(led_classdev_unregister);
+static void devm_led_classdev_release(struct device *dev, void *res)
+{
+ led_classdev_unregister(*(struct led_classdev **)res);
+}
+
+int devm_led_classdev_register(struct device *parent,
+ struct led_classdev *led_cdev)
+{
+ struct led_classdev **dr;
+ int rc;
+
+ dr = devres_alloc(devm_led_classdev_release, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ rc = led_classdev_register(parent, led_cdev);
+ if (rc) {
+ devres_free(dr);
+ return rc;
+ }
+
+ *dr = led_cdev;
+ devres_add(parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_register);
+
static int __init leds_init(void)
{
leds_class = class_create(THIS_MODULE, "leds");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index cfceef3..9ed7dec 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -102,6 +102,8 @@ struct led_classdev {
extern int led_classdev_register(struct device *parent,
struct led_classdev *led_cdev);
+extern int devm_led_classdev_register(struct device *parent,
+ struct led_classdev *led_cdev);
extern void led_classdev_unregister(struct led_classdev *led_cdev);
extern void led_classdev_suspend(struct led_classdev *led_cdev);
extern void led_classdev_resume(struct led_classdev *led_cdev);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/8] kmod - teach call_usermodehelper() to use a namespace
On Mon, 2015-02-16 at 19:24 +0100, Oleg Nesterov wrote:
> On 02/16, Oleg Nesterov wrote:
> >
> > On 02/16, Ian Kent wrote:
> > >
> > > On Tue, 2015-02-10 at 17:55 +0100, Oleg Nesterov wrote:
> > > > On 02/10, Ian Kent wrote:
> > > > >
> > > > > On Mon, 2015-02-09 at 17:03 +0100, Oleg Nesterov wrote:
> > > > > >
> > > > > > I understand. but I still can't understand why we can't implement
> > > > > > something
> > > > > > like
> > > > > > enter_ns(struct nsproxy *p)
> > > > > > {
> > > > > > new_nsproxy = create_new_namespaces(...);
> > > > > >
> > > > > > p->mnt_ns->ns->ops->install(new_nsproxy, ...);
> > > > > > p->pid_ns_for_children->ns->ops->install(new_nsproxy,
> > > > > > ...);
> > > > > > ...
> > > > > >
> > > > > > switch_task_namespaces(new_nsproxy);
> > > > > > }
> > > > > >
> > > > > > Why we should abuse fs/proc ?
> > > > >
> > > > > That sounds like a much better approach.
> > > > > Your saying just take a reference to the nsproxy from the located
> > > > > process and use it instead, right?
> > > >
> > > > Yes,
> > >
> > > I'm still not sure if this can be done (at least without surgery to the
> > > namespace implementation) and I think I've been here before which is
> > > what lead to the file_open_root() approach.
> > >
> > > The difficulty is the second parameter to the install() call above, the
> > > struct ns_common. In setns() it's obtained from the procfs file inode
> > > and the file open is what's used to obtain each namespace type (in the
> > > form of a struct ns_common) from a process context different from
> > > current, current being the thread runner process.
> > >
> > > I might still be able to work out a (viable) way to obtain the
> > > appropriate ns_common struct in each case without a file open but it's
> > > hard to see how.
> >
> > Not sure I understand... Every "namespace" pointer "struct nsproxy" has
> > the "struct ns_common ns" you need? So you can do (for example)
> >
> > p->mnt_ns->ns->ops->install(new_nsproxy, >mnt_ns->ns);
> >
> > or I missed something? (userns differs, you need cred->user_ns, of course).
> >
> >
> > Perhaps I missed something, but this doesn't look like a problem...
>
> And in case this wasn't clear we obviously need to pass nsproxy/cred to
> sub_info->init().
>
> There is nothing magical in /proc or I am totally confused. Look at
> ns_get_path(),
> it (to simplify) does
>
> inode->i_private = ns_ops->get(task);
>
> and every ->get() method returns >ns.
Yep, my confusion was with which nsproxy is the needed nsproxy and your
right, there isn't anything special about setting the inode nsproxy.
It looks like your comments expose the file open as a really complicated
way of getting back the nsproxy(->ns) that we (will) already have from
the located task. I should look a little further to confirm that but, in
hindsight, it seems obvious now.
And I think that's what your trying so hard to get through to me, ;)
>
>
> But again, again:
>
> > The real problem is that , let me repeat, is that pidns_install() does not
> > and can't change active_pid_ns. So I think that kernel_thread_in_ns()
> > probably
> > make more sense.
>
> Yes...
Yes, fortunately I got that when you first mentioned it.
Your point here was easy to verify and understand.
Thanks for your persistence.
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/8] kmod - teach call_usermodehelper() to use a namespace
On Mon, 2015-02-16 at 18:13 +0100, Oleg Nesterov wrote:
> On 02/16, Ian Kent wrote:
> >
> > On Tue, 2015-02-10 at 17:55 +0100, Oleg Nesterov wrote:
> > > On 02/10, Ian Kent wrote:
> > > >
> > > > On Mon, 2015-02-09 at 17:03 +0100, Oleg Nesterov wrote:
> > > > >
> > > > > I understand. but I still can't understand why we can't implement
> > > > > something
> > > > > like
> > > > > enter_ns(struct nsproxy *p)
> > > > > {
> > > > > new_nsproxy = create_new_namespaces(...);
> > > > >
> > > > > p->mnt_ns->ns->ops->install(new_nsproxy, ...);
> > > > > p->pid_ns_for_children->ns->ops->install(new_nsproxy,
> > > > > ...);
> > > > > ...
> > > > >
> > > > > switch_task_namespaces(new_nsproxy);
> > > > > }
> > > > >
> > > > > Why we should abuse fs/proc ?
> > > >
> > > > That sounds like a much better approach.
> > > > Your saying just take a reference to the nsproxy from the located
> > > > process and use it instead, right?
> > >
> > > Yes,
> >
> > I'm still not sure if this can be done (at least without surgery to the
> > namespace implementation) and I think I've been here before which is
> > what lead to the file_open_root() approach.
> >
> > The difficulty is the second parameter to the install() call above, the
> > struct ns_common. In setns() it's obtained from the procfs file inode
> > and the file open is what's used to obtain each namespace type (in the
> > form of a struct ns_common) from a process context different from
> > current, current being the thread runner process.
> >
> > I might still be able to work out a (viable) way to obtain the
> > appropriate ns_common struct in each case without a file open but it's
> > hard to see how.
>
> Not sure I understand... Every "namespace" pointer "struct nsproxy" has
> the "struct ns_common ns" you need? So you can do (for example)
>
> p->mnt_ns->ns->ops->install(new_nsproxy, >mnt_ns->ns);
>
> or I missed something? (userns differs, you need cred->user_ns, of course).
I didn't see that when I looked so I missed it, thanks for pointing it
out.
>
>
> Perhaps I missed something, but this doesn't look like a problem...
>
> The real problem is that , let me repeat, is that pidns_install() does not
> and can't change active_pid_ns. So I think that kernel_thread_in_ns() probably
> make more sense.
Right, I didn't miss that when you mentioned it.
Changing the execution order using your kernel_thread_in_ns() suggestion
is clearly what needs to be done.
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] led/led-class: Handle LEDs with the same name
> Thanks!
On Tue, Feb 17, 2015 at 5:11 PM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> On Wed, Feb 18, 2015 at 1:52 AM, Bryan Wu wrote:
>>>
>>> Lets say that we have a type of add-on card. Described by this DT
>>> overlay (card.dtb):
>>>
>>
>> I think who write this card.dtb should understand this issue. And
>> choose the right name.
>
> card.dtb just describe the hardware in the card, and it is not be
> aware of the rest of the system.
>
> I dont think it is practical to have card_HOST0_PCI1.dtb,
> card_HOST0_PCI2.dtb to HOST0_PCI16.dtb and then HOST1_, HOST2
>
>>> gpio_0: gpio_0 {
>>What happen if you just use name 'gpio: gpio {' here.? Any conflicts
>>or kernel oops?
>
> No problem here, one will create the device
>
> /sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio
>
> and the other:
>
> /sys/devices/pci:00/:00:06.0/:01:00.0/4004.gpio
>
> Name is created with hierarnchy
>
> /sys/class/gpio/ will also work fine, because the gpiochip id is
> created dynamically
>
> On the other hand all the leds are under,
>
> /sys/class/leds/NAME
>
> Do not have any dynamic naming or hierarchical name.
>
I got it. In this case we need to give the leds device a unique name.
Go back to your patch, you're adding 0, 1 at the end of the name of
leds. It's better like GPIO I think you can pick up value of
leds device node and put it in front of the name of leds. like
/sys/class/leds/3004.red and /sys/class/leds/4004.red.
Thanks,
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] colons are invalid characters in netdev names
On 02/17/2015 07:28 PM, Stephen Hemminger wrote: > On Tue, 17 Feb 2015 17:15:42 -0600 > Matthew Thode wrote: > >> colons are used as a separator in netdev device lookup in dev_ioctl.c >> >> Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME >> >> Signed-off-by: Matthew Thode > > What is the exact sequence that causes the problem? > SIOCSIFNAME already strips of colon. > > It strips the name one access, not creation. You can create a dummy device and not access it, escaping doesn't seem to help. ip link add name foo:asdasd type dummy ip link del dev foo:asdasd # will not be deleted -- Matthew Thode signature.asc Description: OpenPGP digital signature
[GIT PULL REQUEST] some more bugfixes for md.
hi Linus, Please pull these three fixes, one tagged for -stable. Thanks, NeilBrown The following changes since commit 53a6ab4d3f6d6dc87ec8f14998b4b5536ee2968c: md/raid10: fix conversion from RAID0 to RAID10 (2015-02-12 14:09:57 +1100) are available in the git repository at: git://neil.brown.name/md/ tags/md/3.20-fixes for you to fetch changes up to 26ac107378c4742978216be1005b7291b799c7b2: md/raid5: Fix livelock when array is both resyncing and degraded. (2015-02-18 11:35:14 +1100) 3 bug md fixes for 3.20 yet-another-livelock in raid5, and a problem with write errors to 4K-block devices. Nate Dailey (1): md/raid1: round up to bdev_logical_block_size in narrow_write_error NeilBrown (2): md/raid10: round up to bdev_logical_block_size in narrow_write_error. md/raid5: Fix livelock when array is both resyncing and degraded. drivers/md/raid1.c | 3 ++- drivers/md/raid10.c | 3 ++- drivers/md/raid5.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) pgpSP01FSfzcb.pgp Description: OpenPGP digital signature
Re: [PATCH] colons are invalid characters in netdev names
On Tue, 17 Feb 2015 17:15:42 -0600 Matthew Thode wrote: > colons are used as a separator in netdev device lookup in dev_ioctl.c > > Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME > > Signed-off-by: Matthew Thode What is the exact sequence that causes the problem? SIOCSIFNAME already strips of colon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next] netfilter: Remove uses of return value of seq_printf/puts/putc
On Mon, 2015-02-16 at 17:25 -0800, Joe Perches wrote: > These functions are soon going to return void so remove the > return value uses. > > Convert the return value to test seq_has_overflowed() instead. (sorry 'bout that, overly sensitive mouse) Please do not apply. These need conversions to "return 0" not "return seq_has_overflowed()"; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next] netfilter: Remove uses of return value of seq_printf/puts/putc
On Mon, 2015-02-16 at 17:25 -0800, Joe Perches wrote:
> These functions are soon going to return void so remove the
> return value uses.
>
> Convert the return value to test seq_has_overflowed() instead.
Please do not apply.
These need conversions not to "return seq_has_
> Signed-off-by: Joe Perches
> ---
> net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.c | 4 +++-
> net/netfilter/nf_conntrack_acct.c | 8 +---
> net/netfilter/nf_conntrack_expect.c | 4 +++-
> net/netfilter/nfnetlink_log.c | 12 +++-
> 4 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.c
> b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.c
> index a460a87..b03b801 100644
> --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.c
> +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.c
> @@ -300,7 +300,9 @@ static int exp_seq_show(struct seq_file *s, void *v)
> __nf_ct_l3proto_find(exp->tuple.src.l3num),
> __nf_ct_l4proto_find(exp->tuple.src.l3num,
>exp->tuple.dst.protonum));
> - return seq_putc(s, '\n');
> + seq_putc(s, '\n');
> +
> + return seq_has_overflowed(s);
> }
>
> static const struct seq_operations exp_seq_ops = {
> diff --git a/net/netfilter/nf_conntrack_acct.c
> b/net/netfilter/nf_conntrack_acct.c
> index a4b5e2a..4d291dc 100644
> --- a/net/netfilter/nf_conntrack_acct.c
> +++ b/net/netfilter/nf_conntrack_acct.c
> @@ -47,9 +47,11 @@ seq_print_acct(struct seq_file *s, const struct nf_conn
> *ct, int dir)
> return 0;
>
> counter = acct->counter;
> - return seq_printf(s, "packets=%llu bytes=%llu ",
> - (unsigned long
> long)atomic64_read([dir].packets),
> - (unsigned long
> long)atomic64_read([dir].bytes));
> + seq_printf(s, "packets=%llu bytes=%llu ",
> +(unsigned long long)atomic64_read([dir].packets),
> +(unsigned long long)atomic64_read([dir].bytes));
> +
> + return seq_has_overflowed(s);
> };
> EXPORT_SYMBOL_GPL(seq_print_acct);
>
> diff --git a/net/netfilter/nf_conntrack_expect.c
> b/net/netfilter/nf_conntrack_expect.c
> index 91a1837..1abf92f 100644
> --- a/net/netfilter/nf_conntrack_expect.c
> +++ b/net/netfilter/nf_conntrack_expect.c
> @@ -561,7 +561,9 @@ static int exp_seq_show(struct seq_file *s, void *v)
> helper->expect_policy[expect->class].name);
> }
>
> - return seq_putc(s, '\n');
> + seq_putc(s, '\n');
> +
> + return seq_has_overflowed(s);
> }
>
> static const struct seq_operations exp_seq_ops = {
> diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
> index 11d85b3..3e016ff 100644
> --- a/net/netfilter/nfnetlink_log.c
> +++ b/net/netfilter/nfnetlink_log.c
> @@ -998,11 +998,13 @@ static int seq_show(struct seq_file *s, void *v)
> {
> const struct nfulnl_instance *inst = v;
>
> - return seq_printf(s, "%5d %6d %5d %1d %5d %6d %2d\n",
> - inst->group_num,
> - inst->peer_portid, inst->qlen,
> - inst->copy_mode, inst->copy_range,
> - inst->flushtimeout, atomic_read(>use));
> + seq_printf(s, "%5d %6d %5d %1d %5d %6d %2d\n",
> +inst->group_num,
> +inst->peer_portid, inst->qlen,
> +inst->copy_mode, inst->copy_range,
> +inst->flushtimeout, atomic_read(>use));
> +
> + return seq_has_overflowed(s);
> }
>
> static const struct seq_operations nful_seq_ops = {
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] staging: lustre: Remove use of return val of seq_printf
On Mon, 2015-02-16 at 11:24 -0800, Joe Perches wrote: > seq_printf should eventually be converted to a void function. > > Remove the uses of seq_printf return values and use seq_has_overflowed() > instead. Please do not apply. These need conversions not to "return seq_has_overflowed()" but to "return 0". > Joe Perches (3): > staging: lustre: Convert return seq_printf(...) uses to seq_has_overflowed > staging: lustre: Convert uses of "int rc = seq_printf(...)" > staging: lustre: Convert remaining uses of "= seq_printf(...)" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] led/led-class: Handle LEDs with the same name
Hello Bryan
On Wed, Feb 18, 2015 at 1:52 AM, Bryan Wu wrote:
>>
>> Lets say that we have a type of add-on card. Described by this DT
>> overlay (card.dtb):
>>
>
> I think who write this card.dtb should understand this issue. And
> choose the right name.
card.dtb just describe the hardware in the card, and it is not be
aware of the rest of the system.
I dont think it is practical to have card_HOST0_PCI1.dtb,
card_HOST0_PCI2.dtb to HOST0_PCI16.dtb and then HOST1_, HOST2
>> gpio_0: gpio_0 {
>What happen if you just use name 'gpio: gpio {' here.? Any conflicts
>or kernel oops?
No problem here, one will create the device
/sys/devices/pci:00/:00:05.0/:01:00.0/3004.gpio
and the other:
/sys/devices/pci:00/:00:06.0/:01:00.0/4004.gpio
Name is created with hierarnchy
/sys/class/gpio/ will also work fine, because the gpiochip id is
created dynamically
On the other hand all the leds are under,
/sys/class/leds/NAME
Do not have any dynamic naming or hierarchical name.
> So you're supposed to get 2 card.dtb files for 2 PCI cards, right?
> They should be different and you need to choose different name for the
> hardware.
There is only one card.dtb because both cards are identical cards,
they are just connected to different ports
>
> From device tree point of view, I believe different device should got
> different name although they can match to same compatible string. Let
> me invite DT folks for help.
Another example of duplicated names could be partitions on an mtd. You
can have two devices with a partition called Golden.
If my memory is right, you can even have two partition with the same
name on the same device. The offset of the partition will be part of
the name in that case.
>
> Thanks,
> -Bryan
Thanks!
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RAID1 might_sleep() warning on 3.19-rc7
On Fri, 13 Feb 2015 15:48:03 +0100 Peter Zijlstra wrote: > On Fri, Feb 13, 2015 at 11:27:46AM +0100, Peter Zijlstra wrote: > > > > I've moved blk_flush_plug to the beginning of the function. > > > > > I wondered if it really make sense to call blk_flush_plug with nr_iowait > > > elevated and delayacct_blkio active. blk_flush_plug() could call > > > schedule() > > > for non-"io" reasons and maybe that could upset stuff??? > > > > Yeah, good question that. Lemme ponder that a bit. > > Yes, I thikn your version makes most sense as, you say, even regular > schedule() call nested in my version would go towards blk delayacct -- > and I doubt that was the intent; even though the current kernel works > that way. > > I'll move the now rudimentary io_schedule() into sched.h as an inline. Thanks. Are you OK with this going to -stable for 3.19? NeilBrown pgpK0djNX_H55.pgp Description: OpenPGP digital signature
Re: [PATCH v2] mm, hugetlb: set PageLRU for in-use/active hugepages
On Tue, Feb 17, 2015 at 04:02:49PM -0800, Andrew Morton wrote: > On Tue, 17 Feb 2015 15:57:44 -0800 Andrew Morton > wrote: > > > So if I'm understanding this correctly, hugepages never have PG_lru set > > and so you are overloading that bit on hugepages to indicate that the > > page is present on hstate->hugepage_activelist? > > And maybe we don't need to overload PG_lru at all? There's plenty of > free space in the compound page's *(page + 1). Right, that's not necessary. So I'll use PG_private in *(page + 1), that's unused now and no worry about conflicting with other usage. Thanks, Naoya Horiguchi-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v3] drivers/core/of: Add symlink to device-tree from devices with an OF node
On Tue, Feb 17, 2015 at 6:25 PM, Benjamin Herrenschmidt
wrote:
> So I've been annoyed lately with having a bunch of devices such as i2c
> eeproms (for use by VPDs, server world !) and other bits and pieces that
> I want to be able to identify from userspace, and possibly provide
> additional data about from FW.
>
> Basically, it boils down to correlating the sysfs device with the OF
> tree device node, so that user space can use device-tree info such as
> additional "location" or "label" (or whatever else we can come up with)
> propreties to identify a given device, or get some attributes of use
> about it, etc...
>
> Now, so far, we've done that in some subsystem in a fairly ad-hoc basis
> using "devspec" properties. For example, PCI creates them if it can
> correlate the probed device with a DT node. Some powerpc specific busses
> do that too.
>
> However, i2c doesn't and it would be nice to have something more generic
> since technically any device can have a corresponding device tree node.
>
> This patch adds an "of_node" symlink to devices that have a non-NULL
> dev->of_node pointer, the patch is pretty trivial and seems to work just
> fine for me.
>
> Signed-off-by: Benjamin Herrenschmidt
Acked-by: Rob Herring
> ---
>
> This addresses Greg's comments. Note that I'm not 100% certain about
> using device_add_class_symlinks(), I had to put the code before the
> test for dev->class, maybe we should rename that function to
> device_add_symlinks()
> if it grows beyond the class bits ?
>
> Also there was nothing that I could find in Documentation/ABI that
> documented "core" device properties, it's all in
> Documentation/sysfs-rules.txt, but as suggested by Greg (on IRC) I
> went for ABI anyway, so I've added a file for "generic" properties
> and added that one in. I'm happy to change it if you think that's not
> right, just let me know where you want things.
>
> I'm not resending patch 1/2, it should still be fine. Let me know if
> you want a new copy.
>
> Documentation/ABI/stable/sysfs-devices | 10 ++
> drivers/base/core.c| 16 ++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/stable/sysfs-devices
>
> diff --git a/Documentation/ABI/stable/sysfs-devices
> b/Documentation/ABI/stable/sysfs-devices
> new file mode 100644
> index 000..43f78b88d
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-devices
> @@ -0,0 +1,10 @@
> +# Note: This documents additional properties of any device beyond what
> +# is documented in Documentation/sysfs-rules.txt
> +
> +What: /sys/devices/*/of_path
> +Date: February 2015
> +Contact: Device Tree mailing list
> +Description:
> + Any device associated with a device-tree node will have
> + an of_path symlink pointing to the corresponding device
> + node in /sys/firmware/devicetree/
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 97e2baf..2549805 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -805,8 +805,16 @@ static void cleanup_device_parent(struct device *dev)
>
> static int device_add_class_symlinks(struct device *dev)
> {
> + struct device_node *of_node = dev_of_node(dev);
> int error;
>
> + if (of_node) {
> + error = sysfs_create_link(>kobj,
> _node->kobj,"of_node");
> + if (error)
> + dev_warn(dev, "Error %d creating of_node
> link\n",error);
> + /* An error here doesn't warrant bringing down the device */
> + }
> +
> if (!dev->class)
> return 0;
>
> @@ -814,7 +822,7 @@ static int device_add_class_symlinks(struct device *dev)
> >class->p->subsys.kobj,
> "subsystem");
> if (error)
> - goto out;
> + goto out_devnode;
>
> if (dev->parent && device_is_not_partition(dev)) {
> error = sysfs_create_link(>kobj, >parent->kobj,
> @@ -842,12 +850,16 @@ out_device:
>
> out_subsys:
> sysfs_remove_link(>kobj, "subsystem");
> -out:
> +out_devnode:
> + sysfs_remove_link(>kobj, "of_node");
> return error;
> }
>
> static void device_remove_class_symlinks(struct device *dev)
> {
> + if (dev_of_node(dev))
> + sysfs_remove_link(>kobj, "of_node");
> +
> if (!dev->class)
> return;
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] device: Add dev_of_node() accessor
+Greg KH
On Sun, Feb 15, 2015 at 9:59 PM, Benjamin Herrenschmidt
wrote:
> Suggested by Arnd Bergmann, this gives a practical accessor for
> the of_node field of struct device while instructing the compiler
> that it will be NULL if CONFIG_OF is not set.
>
> Signed-off-by: Benjamin Herrenschmidt
> ---
I'll let Greg take this with the other patch:
Acked-by: Rob Herring
>
> This is what we discussed back in November and I had forgotten
> to finish :)
>
> include/linux/device.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index fb50673..08128288 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -916,6 +916,13 @@ static inline void device_lock_assert(struct device *dev)
> lockdep_assert_held(>mutex);
> }
>
> +static inline struct device_node *dev_of_node(struct device *dev)
> +{
> + if (!IS_ENABLED(CONFIG_OF))
> + return NULL;
> + return dev->of_node;
> +}
> +
> void driver_init(void);
>
> /*
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipc: Remove uses of return value of seq_printf/seq_puts
On Wed, 2015-02-18 at 00:27 +, Al Viro wrote:
> On Tue, Feb 17, 2015 at 04:09:44PM -0800, Joe Perches wrote:
> > On Tue, 2015-02-17 at 23:16 +, Al Viro wrote:
> > > Most of the time checking return value of seq_...() is better replaced
> > > with
> > > not doing that. And "must check return value and Do Something(tm)" is too
> > > strong habit for enough people to cause recurring trouble.
> >
> > Does SEQ_SKIP still have value?
>
> Yes, it does, but it's not an error - it's an equivalent of "empty the buffer
> before returning". Basically, it's "I've decided that this entry shouldn't
> produce anything". Look at the caller:
Yeah.
I should have looked at the traverse function first.
> error = m->op->show(m, p);
> if (error < 0)
> break;
> if (unlikely(error)) {
> error = 0;
> m->count = 0;
> }
Basically all the show functions that I converted
to use seq_has_overflowed() should just return 0.
There are only 3 current uses of SEQ_SKIP
drivers/infiniband/hw/qib/qib_debugfs.c:119:return SEQ_SKIP;
drivers/infiniband/hw/qib/qib_debugfs.c:177:return SEQ_SKIP;
drivers/infiniband/hw/qib/qib_debugfs.c:183:return SEQ_SKIP;
As far as I can tell, these uses would be fine
not using SEQ_SKIP and just emitting 0 instead
of nothing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 082/152] virtio: use dev_to_virtio wrapper in virtio
On Tue, 2015-02-17 at 15:56 +1030, Rusty Russell wrote: > Ben Hutchings writes: > > 3.2.67-rc1 review patch. If anyone has any objections, please let me know. > > Ben, what are your criteria for putting patches into 3.2? > > This patch is a trivial cleanup. It doesn't fix anything, but it does > add some churn. It fixes the definition of dev_to_virtio(). > I can see that 083 and 084 follow this, but 083 needed a backport > anyway. Patch 083 "virtio_pci: defer kfree until release callback" uses dev_to_virtio(_d) which would expand to a syntax error without this. > And it wasn't an issue we saw in Real Life (device removal > is rare), so it wasn't CC: stable. > > 084 was a comment addition. Backporting that just seems weird. Nevertheless, it had 'cc: stable' and is obviously harmless. Ben. -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
[PATCH] locks: fix list insertion when lock is split in two
Al reported that he had seen some LTP fcntl11 and fcntl21 test
failures since the merge window had opened.
In the case where we're splitting a lock in two, the current code
the new "left" lock in the incorrect spot. It's inserted just
before "right" when it should instead be inserted just before the
new lock.
When we add a new lock, set "fl" to that value so that we can
add "left" before it.
Reported-by: Al Viro
Signed-off-by: Jeff Layton
---
fs/locks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/locks.c b/fs/locks.c
index 90b652ad306f..365c82e1b3a9 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1107,6 +1107,7 @@ static int __posix_lock_file(struct inode *inode, struct
file_lock *request, str
}
locks_copy_lock(new_fl, request);
locks_insert_lock_ctx(new_fl, >fl_list);
+ fl = new_fl;
new_fl = NULL;
}
if (right) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vhost: support upto 509 memory regions
On Tue, Feb 17, 2015 at 4:32 AM, Michael S. Tsirkin wrote: > On Tue, Feb 17, 2015 at 11:59:48AM +0100, Paolo Bonzini wrote: >> >> >> On 17/02/2015 10:02, Michael S. Tsirkin wrote: >> > > Increasing VHOST_MEMORY_MAX_NREGIONS from 65 to 509 >> > > to match KVM_USER_MEM_SLOTS fixes issue for vhost-net. >> > > >> > > Signed-off-by: Igor Mammedov >> > >> > This scares me a bit: each region is 32byte, we are talking >> > a 16K allocation that userspace can trigger. >> >> What's bad with a 16K allocation? > > It fails when memory is fragmented. > >> > How does kvm handle this issue? >> >> It doesn't. >> >> Paolo > > I'm guessing kvm doesn't do memory scans on data path, > vhost does. > > qemu is just doing things that kernel didn't expect it to need. > > Instead, I suggest reducing number of GPA<->HVA mappings: > > you have GPA 1,5,7 > map them at HVA 11,15,17 > then you can have 1 slot: 1->11 > > To avoid libc reusing the memory holes, reserve them with MAP_NORESERVE > or something like this. This works beautifully when host virtual address bits are more plentiful than guest physical address bits. Not all architectures have that property, though. > We can discuss smarter lookup algorithms but I'd rather > userspace didn't do things that we then have to > work around in kernel. > > > -- > MST > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] led/led-class: Handle LEDs with the same name
On Tue, Feb 17, 2015 at 4:32 PM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu wrote:
>>
>> DT just describe the hardware, so if it's a different hardware, they
>> should have different name.
>> red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and
>> 1.
>
> I think I have not managed to explain myself properly.
>
> We have a host computer. with 2 pcie slots. The host is described with
> a DT that looks like:
>
> {
>
> pci0{
> reg = < 0x2000 0x1000 >
> }
>
> pci1{
> reg = < 0x3000 0x1000 >
> }
> }
>
> The user can connect anything to the pci slots. (pci0 and pci1)
>
>
> Lets say that we have a type of add-on card. Described by this DT
> overlay (card.dtb):
>
I think who write this card.dtb should understand this issue. And
choose the right name.
> {
>
> gpio_0: gpio_0 {
What happen if you just use name 'gpio: gpio {' here.? Any conflicts
or kernel oops?
> #gpio-cells = <2>;
> compatible = "xlnx,xps-gpio-1.00.a";
> reg = < 0x3004 01 >;
> };
>
>
> /*Leds*/
> leds {
> reg = < 0x3004 01 >;
> compatible = "gpio-leds";
> red {
> gpios = <_0 0 0>;
> linux,default-trigger = "drop-qt5023_video0";
> };
> }
>
> }
>
> The user connects two of those cards to the system (at locations pci0 and
> pci1).
>
> Then we have TWO gpios chip. Each of them have a led named red. When
> the second gpio-led is probed we have an error. Everything else
> (address offset, phandle, device renaming) is handled properly already
> by the kernel.
>
> On this system I cannot control card.dtb, or which type of cards will
> the user connect to the system. The DT is generated in run-time based
> on the hardware connected to the pci slots.
>
So you're supposed to get 2 card.dtb files for 2 PCI cards, right?
They should be different and you need to choose different name for the
hardware.
> I humbly believe that the issue here is that the subsystem does not
> protect ourselves against name collisions, because a month ago a
> device tree was considered immutable and in full control of the system
> designer, unfortunately this is not the case anymore.
>
>From device tree point of view, I believe different device should got
different name although they can match to same compatible string. Let
me invite DT folks for help.
Thanks,
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] led/led-class: Handle LEDs with the same name
Hello Bryan
On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu wrote:
>
> DT just describe the hardware, so if it's a different hardware, they
> should have different name.
> red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and 1.
I think I have not managed to explain myself properly.
We have a host computer. with 2 pcie slots. The host is described with
a DT that looks like:
{
pci0{
reg = < 0x2000 0x1000 >
}
pci1{
reg = < 0x3000 0x1000 >
}
}
The user can connect anything to the pci slots. (pci0 and pci1)
Lets say that we have a type of add-on card. Described by this DT
overlay (card.dtb):
{
gpio_0: gpio_0 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x3004 01 >;
};
/*Leds*/
leds {
reg = < 0x3004 01 >;
compatible = "gpio-leds";
red {
gpios = <_0 0 0>;
linux,default-trigger = "drop-qt5023_video0";
};
}
}
The user connects two of those cards to the system (at locations pci0 and pci1).
Then we have TWO gpios chip. Each of them have a led named red. When
the second gpio-led is probed we have an error. Everything else
(address offset, phandle, device renaming) is handled properly already
by the kernel.
On this system I cannot control card.dtb, or which type of cards will
the user connect to the system. The DT is generated in run-time based
on the hardware connected to the pci slots.
I humbly believe that the issue here is that the subsystem does not
protect ourselves against name collisions, because a month ago a
device tree was considered immutable and in full control of the system
designer, unfortunately this is not the case anymore.
Thanks!
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
