[tip:x86/urgent] x86: Use $(OBJDUMP) instead of plain objdump
Commit-ID: e2e68ae688b0a3766cd75aedf4ed4e39be402009 Gitweb: http://git.kernel.org/tip/e2e68ae688b0a3766cd75aedf4ed4e39be402009 Author: Chris Clayton AuthorDate: Sat, 22 Nov 2014 09:51:10 + Committer: Thomas Gleixner CommitDate: Sun, 23 Nov 2014 21:21:53 +0100 x86: Use $(OBJDUMP) instead of plain objdump commit e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd' broke the cross compile of x86. It added a objdump invocation, which invokes the host native objdump and ignores an active cross tool chain. Use $(OBJDUMP) instead which takes the CROSS_COMPILE prefix into account. [ tglx: Massage changelog and use $(OBJDUMP) ] Fixes: e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd' Signed-off-by: Chris Clayton Acked-by: Kees Cook Acked-by: Borislav Petkov Cc: Junjie Mao Cc: Ingo Molnar Cc: H. Peter Anvin Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/54705c8e.1080...@googlemail.com Signed-off-by: Thomas Gleixner --- arch/x86/boot/compressed/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile index be1e07d..45abc36 100644 --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -76,7 +76,7 @@ suffix-$(CONFIG_KERNEL_XZ):= xz suffix-$(CONFIG_KERNEL_LZO):= lzo suffix-$(CONFIG_KERNEL_LZ4):= lz4 -RUN_SIZE = $(shell objdump -h vmlinux | \ +RUN_SIZE = $(shell $(OBJDUMP) -h vmlinux | \ perl $(srctree)/arch/x86/tools/calc_run_size.pl) quiet_cmd_mkpiggy = MKPIGGY $@ cmd_mkpiggy = $(obj)/mkpiggy $< $(RUN_SIZE) > $@ || ( rm -f $@ ; 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/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
On Mon, Nov 24, 2014 at 11:42 AM, Paul E. McKenney wrote: > > OK, how about the following? Ugh. Disgusting. Why the heck isn't it just "sizeof(*__vp) <= sizeof(long)"? If the architecture has a 3-byte scalar type, then it probably has a 3-byte load. > It complains if the variable is too large, for example, long long on > 32-bit systems or large structures. It is OK loading from and storing > to small structures as well, which I am having a hard time thinking of > as a disadvantage. .. but that's *exactly* the gcc bug in question. It's a word-sized struct that gcc loads twice. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kdbus: add documentation
Hi Andy!
On Fri, Nov 21, 2014 at 6:12 PM, Andy Lutomirski wrote:
> On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
> wrote:
>> From: Daniel Mack
>>
>> kdbus is a system for low-latency, low-overhead, easy to use
>> interprocess communication (IPC).
>>
>> The interface to all functions in this driver is implemented through
>> ioctls on files exposed through the mount point of a kdbusfs. This
>> patch adds detailed documentation about the kernel level API design.
>>
>> Signed-off-by: Daniel Mack
>> Signed-off-by: David Herrmann
>> Signed-off-by: Djalal Harouni
>> Signed-off-by: Greg Kroah-Hartman
>> ---
>
>> + Pool:
>> +Each connection allocates a piece of shmem-backed memory that is used
>> +to receive messages and answers to ioctl command from the kernel. It is
>> +never used to send anything to the kernel. In order to access that
>> memory,
>> +userspace must mmap() it into its task.
>> +See section 12 for more details.
>
> At the risk of opening a can of worms, wouldn't this be much more
> useful if you could share a pool between multiple connections?
Within a process it could theoretically be possible to share the same
memory pool between multiple connections made by the process. However,
note that normally a process only has a single connection to the bus
open (possibly two, if it opens a connection to both the system and
the user bus). Now, sharing the receiver buffer could certainly be
considered an optimization, but it would have no effect on
"usefulness", though, as just allocating space from a single shared
per-process receiver won't give you any new possibilities...
We have thought about this, but decided to delay it for now. Shared
pools can easily be added as an extension later on.
[snip]
>> +KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
>> +struct kdbus_cmd_make argument.
>> +
>> +struct kdbus_cmd_make {
>> + __u64 size;
>> +The overall size of the struct, including its items.
>> +
>> + __u64 flags;
>> +The flags for creation.
>> +
>> +KDBUS_MAKE_ACCESS_GROUP
>> + Make the device file group-accessible
>> +
>> +KDBUS_MAKE_ACCESS_WORLD
>> + Make the device file world-accessible
>
> This thing is a file. What's wrong with using a normal POSIX mode?
> (And what to the read, write, and exec modes do?)
Domains and buses are directories, endpoints are files. Domains also
create control-files implicitly.
For kdbus clients there is just access or no access, but not
distinction between read, write and execute access. Due to that we
just break this down to per-group and world access bits, since doing
more is pointless, and we shouldn't allow shoehorning more stuff into
the access mode.
[snip]
>> + KDBUS_ITEM_CREDS
>> + KDBUS_ITEM_SECLABEL
>> +Privileged bus users may submit these types in order to create
>> +connections with faked credentials. The only real use case for this
>> +is a proxy service which acts on behalf of some other tasks. For a
>> +connection that runs in that mode, the message's metadata items will
>> +be limited to what's specified here. See section 13 for more
>> +information.
>
> This is still confusing. There are multiple places in which metadata
> is attached. Which does this apply to? And why are only creds and
> seclabel listed?
Yes, and there are multiple places where metadata is *gathered*. This
ioctl creates connections, so only the items that are actually
*gathered* by that ioctl are documented here. These items are not part
of any messages, but are used as identification of the connection
owner (and in this particular case, to allow privileged proxies to
overwrite the items so they can properly proxy a legacy-dbus peer
connection).
[snip]
>> +6.5 Getting information about a connection's bus creator
>> +
>> +
>> +The KDBUS_CMD_BUS_CREATOR_INFO ioctl takes the same struct as
>> +KDBUS_CMD_CONN_INFO but is used to retrieve information about the creator of
>> +the bus the connection is attached to. The metadata returned by this call is
>> +collected during the creation of the bus and is never altered afterwards, so
>> +it provides pristine information on the task that created the bus, at the
>> +moment when it did so.
>
> What's this for? I understand the need for the creator of busses to
> be authenticated, but doing it like this mean that anyone who will
> *fail* authentication can DoS the authentic creator.
This returns information on a bus owner, to determine whether a
connection is connected to a system, user or session bus. Note that
the bus-creator itself is not a valid peer on the bus, so you cannot
send messages to them. Which kind of DoS do you have in mind?
>> +
>> +7.3 Passing of Payload Data
>> +---
>> +
>> +When connecting to the bus, receivers request a memory pool of a given size,
>> +large enough to carry all backlog of data enqueued for
Re: [PATCH RFC 0/3] Add "Simple" / Renesas Bus State Controller Driver
On Monday 24 November 2014 21:10:05 Geert Uytterhoeven wrote: > As this minimal BSC driver isn't hardware-specific at all, I'm wondering > if there's a simpler way to do this? > - Should the driver be renamed to "simple-bus", and match "simple-bus"? > - Should this be moved to core code, without an explicit driver for > "simple-bus"? I.e. should the driver core just enable runtime PM for > all devices not bound to a driver, as they may represent buses with > child devices that do rely on runtime PM? > > Thanks for your comments and suggestions! My understanding of simple-bus is that it's something that does not have any power-management capabilities, and I'd rather not add clocks or interrupts to it. What I think makes more sense is to have a bus driver for it in drivers/bus, remove the "simple-bus" compatibility value and have the driver take care of registering the power domain and probing the child devices using of_platform_populate on itself. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
On Mon, Nov 24, 2014 at 11:34:12AM -0800, Greg KH wrote:
> On Mon, Nov 24, 2014 at 08:05:10AM -0800, Josh Triplett wrote:
> > On Mon, Nov 24, 2014 at 10:49:31AM +0100, Pieter Smith wrote:
> > > On Sun, Nov 23, 2014 at 03:23:02PM -0800, Josh Triplett wrote:
> > > > On Sun, Nov 23, 2014 at 11:29:08PM +0100, Richard Weinberger wrote:
> > > > > On Sun, Nov 23, 2014 at 3:20 PM, Pieter Smith
> > > > > wrote:
> > > > > > To implement splice support, fs/fuse makes use of
> > > > > > nosteal_pipe_buf_ops. This
> > > > > > struct is exported by fs/splice. The goal of the larger patch set
> > > > > > is to
> > > > > > completely compile out fs/splice, so uses of the exported struct
> > > > > > need to be
> > > > > > compiled out along with fs/splice.
> > > > > >
> > > > > > This patch therefore compiles out splice support in fs/fuse when
> > > > > > CONFIG_SYSCALL_SPLICE is undefined.
> > > > > >
> > > > > > Signed-off-by: Pieter Smith
> > > > > > ---
> > > > > > fs/fuse/dev.c | 4 ++--
> > > > > > include/linux/fs.h | 6 ++
> > > > > > 2 files changed, 8 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > > > > index ca88731..f8f92a4 100644
> > > > > > --- a/fs/fuse/dev.c
> > > > > > +++ b/fs/fuse/dev.c
> > > > > > @@ -1291,7 +1291,7 @@ static ssize_t fuse_dev_read(struct kiocb
> > > > > > *iocb, const struct iovec *iov,
> > > > > > return fuse_dev_do_read(fc, file, , iov_length(iov,
> > > > > > nr_segs));
> > > > > > }
> > > > > >
> > > > > > -static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > > > > > +static ssize_t __maybe_unused fuse_dev_splice_read(struct file
> > > > > > *in, loff_t *ppos,
> > > > > > struct pipe_inode_info *pipe,
> > > > > > size_t len, unsigned int flags)
> > > > > > {
> > > > > > @@ -2144,7 +2144,7 @@ const struct file_operations
> > > > > > fuse_dev_operations = {
> > > > > > .llseek = no_llseek,
> > > > > > .read = do_sync_read,
> > > > > > .aio_read = fuse_dev_read,
> > > > > > - .splice_read= fuse_dev_splice_read,
> > > > > > + .splice_read= __splice_p(fuse_dev_splice_read),
> > > > > > .write = do_sync_write,
> > > > > > .aio_write = fuse_dev_write,
> > > > > > .splice_write = fuse_dev_splice_write,
> > > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > > > > index a957d43..04c0975 100644
> > > > > > --- a/include/linux/fs.h
> > > > > > +++ b/include/linux/fs.h
> > > > > > @@ -2443,6 +2443,12 @@ extern int blkdev_fsync(struct file *filp,
> > > > > > loff_t start, loff_t end,
> > > > > > int datasync);
> > > > > > extern void block_sync_page(struct page *page);
> > > > > >
> > > > > > +#ifdef CONFIG_SYSCALL_SPLICE
> > > > > > +#define __splice_p(x) x
> > > > > > +#else
> > > > > > +#define __splice_p(x) NULL
> > > > > > +#endif
> > > > > > +
> > > > >
> > > > > This needs to go into a different patch.
> > > > > One logical change per patch please. :-)
> > > >
> > > > Easy enough to merge this one into the patch introducing
> > > > CONFIG_SYSCALL_SPLICE, then.
> > > >
> > > > - Josh Triplett
> > >
> > > The patch introducing CONFIG_SYSCALL_SPLICE (PATCH 3) only compiles out
> > > the
> > > syscalls. PATCH 6 on the other hand, compiles out fs/splice.c. This patch
> > > allows fs/fuse to be compiled when fs/splice.c is compiled out. If I am to
> > > squash it, it would be logical to include it in PATCH 6, not 3.
> >
> > The suggestion wasn't to move the fs/fuse/dev.c bits; those should
> > definitely stay in this patch. The suggestion was just to move the bit
> > of the patch defining __splice_p from this patch to patch 3. (Note that
> > you need to define it before you use it, so it can't go in patch 6.)
>
> I would, again, argue that stuff like __splice_p() not be implemented at
> all please. It will only cause a huge proliferation of stuff like this
> that will not make any sense, and only cause a trivial, if any, amount
> of code savings.
>
> I thought you were going to not do this type of thing until you got the
> gcc optimizer working for function callbacks.
Compared to the previous patchset, there are now only two instances of
ifdefs outside of the splice code for this, and this is one of them. In
this case, the issue is no longer about making the code for this
splice_read function disappear, but rather to eliminate a reference to a
bit of splice functionality (used *inside* the FUSE splice code) that
will not work without SPLICE_SYSCALL.
Would you prefer to see this specific case handled via an #ifdef in
fs/fuse/dev.c rather than introducing a __splice_p that people might be
inclined to propagate? That'd be fine; the code could simply wrap
fuse_dev_splice_read in an #ifdef and have the #else define a NULL
fuse_dev_splice_read.
- Josh Triplett
--
To
Re: [PATCH v2 net-net 0/4] Increase the limit of tuntap queues
Your header message says "0/4" as if there will be 4 patches, but then you posted a 3 patch series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND v8] iopoll: Introduce memory-mapped IO polling macros
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its value
satisfies some condition. Introduce a family of convenience macros that do
this. Tight-looping, sleeping, and timing out can all be accomplished using
these macros.
Cc: Thierry Reding
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: Andrew Morton
Signed-off-by: Matt Wagantall
Signed-off-by: Mitchel Humpherys
---
This patch was originally part of a series [1] for adding support for IOMMU
address translations through an ARM SMMU hardware register. The other
patch in the series (the one that actually uses these macros and implements
said hardware address translations) was Ack'd by the driver maintainer
there (Will Deacon) so I've pulled this patch out to avoid resending an
already Ack'd patch over and over again.
In short, please see [1] for previous discussion and the first user of
these macros.
This patch has been resent previously here [2], here [3], and here [4] on
2014-10-30, 2014-11-06, and 2014-11-17, respectively. It has not changed
since [2] and has not received any comments since [1] on 2014-10-19.
Thanks to everyone who has taken a look at this.
[1] http://thread.gmane.org/gmane.linux.kernel.iommu/7140
[2] http://thread.gmane.org/gmane.linux.kernel/1818213
[3] http://thread.gmane.org/gmane.linux.kernel/1823422
[4] http://thread.gmane.org/gmane.linux.kernel.iommu/7394
Changes since v7:
- sorted helper macros by size (b, w, l, q)
- removed some of the more esoteric (or flat-out bogus) helper macros
---
include/linux/iopoll.h | 140 +
1 file changed, 140 insertions(+)
create mode 100644 include/linux/iopoll.h
diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
new file mode 100644
index 00..bd161dae2d
--- /dev/null
+++ b/include/linux/iopoll.h
@@ -0,0 +1,140 @@
+/*
+ * Copyright (c) 2012-2014 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_IOPOLL_H
+#define _LINUX_IOPOLL_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * readx_poll_timeout - Periodically poll an address until a condition is met
or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @sleep_us: Maximum time to sleep between reads in us (0 tight-loops)
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val. Must not
+ * be called from atomic context if sleep_us or timeout_us are used.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ might_sleep_if(sleep_us); \
+ for (;;) { \
+ (val) = op(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+ (val) = op(addr); \
+ break; \
+ } \
+ if (sleep_us) \
+ usleep_range((sleep_us >> 2) + 1, sleep_us); \
+ } \
+ (cond) ? 0 : -ETIMEDOUT; \
+})
+
+/**
+ * readx_poll_timeout_atomic - Periodically poll an address until a condition
is met or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @delay_us: Time to udelay between reads in us (0 tight-loops)
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout_atomic(op, addr, val, cond, delay_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ for (;;) { \
+ (val) = op(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+ (val) =
Re: [PATCH 1/2] exit: reparent: fix/update the comments in zap_pid_ns_processes()
On 11/24, Oleg Nesterov wrote: > > + * sys_wait4() above can't reap the TASK_DEAD children but we do not > + * really care, we could reparent them to the global init. We could > + * exit and reap ->child_reaper even if it is not the last thread in > + * this pid_ns, free_pid(nr_hashed == 0) calls proc_cleanup_work(), > + * pid_ns can not go away until proc_kill_sb() drops the reference. > + * > + * But this namespace can also have other tasks injected by setns(). ^ I meant setns() + fork(), but I hope this is clear. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: user - add MODULE_ALIAS
To allow automatic loading of the crypto_user kernel module, the netlink
MODULE_ALIAS is added.
Signed-off-by: Stephan Mueller
---
crypto/crypto_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index e2a34fe..255df95 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -537,3 +537,4 @@ module_exit(crypto_user_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Steffen Klassert ");
MODULE_DESCRIPTION("Crypto userspace configuration API");
+MODULE_ALIAS("net-pf-16-proto-21");
--
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: For the problem when using swiotlb
On Friday 21 November 2014 18:09:25 Catalin Marinas wrote: > On Fri, Nov 21, 2014 at 05:51:19PM +, Catalin Marinas wrote: > > On Fri, Nov 21, 2014 at 05:04:28PM +, Arnd Bergmann wrote: > > > On Friday 21 November 2014 16:57:09 Catalin Marinas wrote: > > > > There is a scenario where smaller mask would work on arm64. For example > > > > Juno, you can have 2GB of RAM in the 32-bit phys range (starting at > > > > 0x8000). A device with 31-bit mask and a dma_pfn_offset of > > > > 0x8000 would still work (there isn't any but just as an example). So > > > > the check in dma_alloc_coherent() would be something like: > > > > > > > > phys_to_dma(top of ZONE_DMA) - dma_pfn_offset <= > > > > coherent_dma_mask > > > > > > > > (or assuming RAM starts at 0 and ignoring dma_pfn_offset for now) > > > > > > > > If the condition above fails, dma_alloc_coherent() would no longer fall > > > > back to swiotlb but issue a dev_warn() and return NULL. > > > > > > Ah, that looks like it should work on all architectures, very nice. > > > How about checking this condition, and then printing a small warning > > > (dev_warn, not WARN_ON) and setting the dma_mask pointer to NULL? > > > > I would not add the above ZONE_DMA check to of_dma_configure(). For > > example on arm64, we may not support a small coherent_dma_mask but the > > same value for dma_mask could be fine via swiotlb bouncing (or IOMMU). > > However, that's an arch-specific decision. Maybe after the above setting > > of dev->coherent_dma_mask in of_dma_configure(), we could add: > > You seem to implement the opposite: > + /* > + * If the bus dma-ranges property specifies a size smaller than 4GB, > + * the device would not be capable of accessing the whole 32-bit > + * space, so reduce the default coherent_dma_mask accordingly. > + */ > + if (size && size < (1ULL << 32)) > + dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(size)); > + > + /* > + * Set dma_mask to coherent_dma_mask by default if the architecture > + * code has not set it and DMA on such mask is supported. > + */ > + if (!dev->dma_mask && dma_supported(dev, dev->coherent_dma_mask)) > + dev->dma_mask = >coherent_dma_mask; > } > Here, coherent_dma_mask wouldn't work while dma_mask might be fine in case of swiotlb, but you set a nonzero coherent_dma_mask and an invalid dma_mask. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC 1/3] ARM: shmobile: sh73a0 dtsi: Add Bus State Controller node
Add a node for the Bus State Controller (BSC) on sh73a0, to which
multiple external devices can be connected.
The BSC is driven by the ZB clock, and located in PM domain A4S.
For now no device tree bindings have been defined yet. All of its
properties follow standard conventions.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/sh73a0.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 87e7d5ef904bde89..b8d4c557c85eca0c 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -997,4 +997,15 @@
"intca0";
};
};
+
+ bsc: bus@fec1 {
+ compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfec1 0x400>;
+ ranges = <0 0 0x2000>;
+ interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <_clk>;
+ power-domains = <_a4s>;
+ };
};
--
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/RFC 2/3] ARM: shmobile: kzm9g-reference dts: Move Ethernet node to BSC
Move the Ethernet node from the root of the device tree to the BSC node,
as it is connected to the Bus State Controller. This allows the system
to know the right position of the Ethernet node in the clock and PM
domain hierarchy.
Also rename the node's name from "lan9220" to "ethernet", to confirm to
ePAPR generic name recomendations.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/sh73a0-kzm9g.dts | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts
b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 45e2bc60ba9676ff..f80d411696da6b40 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -84,19 +84,6 @@
enable-active-high;
};
- lan9220@1000 {
- compatible = "smsc,lan9220", "smsc,lan9115";
- reg = <0x1000 0x100>;
- phy-mode = "mii";
- interrupt-parent = <>;
- interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
- reg-io-width = <4>;
- smsc,irq-push-pull;
- smsc,save-mac-address;
- vddvario-supply = <_1p8v>;
- vdd33a-supply = <_3p3v>;
- };
-
leds {
compatible = "gpio-leds";
led1 {
@@ -179,6 +166,21 @@
};
};
+ {
+ ethernet@1000 {
+ compatible = "smsc,lan9220", "smsc,lan9115";
+ reg = <0x1000 0x100>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reg-io-width = <4>;
+ smsc,irq-push-pull;
+ smsc,save-mac-address;
+ vddvario-supply = <_1p8v>;
+ vdd33a-supply = <_3p3v>;
+ };
+};
+
{
status = "ok";
};
--
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 RFC 0/3] Add "Simple" / Renesas Bus State Controller Driver
Hi all,
The Renesas Bus State Controller (BSC) provides an external bus for
connecting multiple external devices to an SoC, driving several chip
select lines, for e.g. NOR FLASH, Ethernet and USB.
On the kzm9g development board, an smsc9220 Ethernet controller is
connnected to the BSC of the SH-Mobile AG5 (sh73a0) SoC.
The BSC is a fairly simple memory-mapped bus, hence a "simple-bus"
compatibility seems suitable. However, the BSC is special in two ways:
1. It is part of a PM domain (A4S),
2. It has a gateable functional clock (ZB).
Before a device connected to the BSC can be accessed, the PM domain
containing the BSC must be powered on, and the functional clock driving
the BSC must be enabled.
Both special properties can be described in DT in a standardized way
("power-domains = <_a4s>" and "clocks = <_clk>", cfr. patch 1).
Externally connected devices are described as children of the BSC node
(cfr. patch 2).
Unfortunately this doesn't mean everything will work out-of-the-box.
There are two problems:
1. Without a device driver bound to the BSC device, this device is not
attached to the PM domain. And although a child device is present
and active, the PM domain may be powered down, as it's considered
unused by the PM domain core.
2. Without a device driver calling pm_runtime_enable(), its functional
clock is not enabled. Once runtime PM is enabled, the R-Mobile PM
domain platform driver manages the functional clock using runtime
PM.
Hence patch 3 adds a very simple BSC driver, matching against
"renesas-bsc", and enabling runtime PM for the BSC device.
Due to the child-parent relationship of devices connected to the BSC, as
long as the device drivers for the child devices are runtime PM enabled
(see dependency 1), the BSC's PM domain will be powered, and the BSC's
clock will be enabled automatically when needed.
If any child device driver lacks runtime PM support, the BSC driver also
has to call pm_runtime_get_sync() in its .probe() function.
System suspend and resume (s2ram) also works fine.
As this minimal BSC driver isn't hardware-specific at all, I'm wondering
if there's a simpler way to do this?
- Should the driver be renamed to "simple-bus", and match "simple-bus"?
- Should this be moved to core code, without an explicit driver for
"simple-bus"? I.e. should the driver core just enable runtime PM for
all devices not bound to a driver, as they may represent buses with
child devices that do rely on runtime PM?
Thanks for your comments and suggestions!
Dependencies:
1. [PATCH] net/smsc911x: Add minimal runtime PM support
(https://lkml.org/lkml/2014/11/24/610),
2. [PATCH] clk: shmobile: div6: Avoid changing divisor in .disable()
(http://marc.info/?l=linux-sh=141684607012727=2),
3. [PATCH v6 0/6] sh73a0 common clock framework implementation
(http://marc.info/?l=linux-sh=141650048308960=2),
4. sh73a0 DT PM domain support (not yet posted),
5. Alphabetical sorting of drivers/bus/{Kconfig,Makefile) (not yet
posted).
References:
1. [PATCH v3 7/7] ARM: shmobile: kzm9g-reference: require ZB clock for
Ethernet controller (http://www.spinics.net/lists/linux-sh/msg36601.html)
is an earlier workaround for getting the functional clock enabled, by
letting the smc911x driver handle it. This predates sh73a0 PM domain
support.
Patches:
1. ARM: shmobile: sh73a0 dtsi: Add Bus State Controller node
2. ARM: shmobile: kzm9g-reference dts: Move Ethernet node to BSC
3. drivers: bus: Add Renesas Bus State Controller Driver
arch/arm/boot/dts/sh73a0-kzm9g.dts | 28 +++--
arch/arm/boot/dts/sh73a0.dtsi | 11
drivers/bus/Kconfig| 8 ++
drivers/bus/Makefile | 1 +
drivers/bus/renesas-bsc.c | 51 ++
5 files changed, 86 insertions(+), 13 deletions(-)
create mode 100644 drivers/bus/renesas-bsc.c
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC 3/3] drivers: bus: Add Renesas Bus State Controller Driver
Add a driver for the Renesas Bus State Controller (BSC, sometimes called
"LBSC within Bus Bridge", or "External Bus Interface") found on several
Renesas ARM SoCs.
The sole purpose of this driver is to enable its clock and PM domain (if
exist(s)), which are specified in the DT and managed from platform and
PM domain code. The BSC clock and PM domain must be enabled for
external devices connected to the BSC (e.g. NOR FLASH or Ethernet) to
work.
Due to the child-parent relationship with devices connected to the BSC,
PM domain and clock state transitions are handled in the correct order.
Signed-off-by: Geert Uytterhoeven
---
- Is there a simpler way to do this?
- As none of this code is really hardware-specific, should the driver
be renamed to simple-bus, and match against "simple-bus"?
- Should this be moved to core code, without an explicit driver for
"simple-bus"?
Please reply to the cover letter!
Signed-off-by: Geert Uytterhoeven
---
drivers/bus/Kconfig | 8
drivers/bus/Makefile | 1 +
drivers/bus/renesas-bsc.c | 51 +++
3 files changed, 60 insertions(+)
create mode 100644 drivers/bus/renesas-bsc.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 7697fc8903f62d07..7e901480ba67dcad 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -58,6 +58,14 @@ config OMAP_OCP2SCP
OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
OCP2SCP.
+config RENESAS_BSC
+ bool "Renesas Bus State Controller"
+ depends on ARCH_SHMOBILE && OF
+ help
+ Driver for the Renesas Bus State Controller (BSC, sometimes called
+ "LBSC within Bus Bridge", or "External Bus Interface") found on
+ several Renesas ARM SoCs.
+
config VEXPRESS_CONFIG
bool "Versatile Express configuration bus"
default y if ARCH_VEXPRESS
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 2eb1f668c7fbc00d..b1ac67cfa9d5663c 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
obj-$(CONFIG_OMAP_INTERCONNECT)+= omap_l3_smx.o omap_l3_noc.o
obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
+obj-$(CONFIG_RENESAS_BSC) += renesas-bsc.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
diff --git a/drivers/bus/renesas-bsc.c b/drivers/bus/renesas-bsc.c
new file mode 100644
index ..ca35aae266d3365a
--- /dev/null
+++ b/drivers/bus/renesas-bsc.c
@@ -0,0 +1,51 @@
+/*
+ * Renesas Bus State Controller Driver
+ *
+ * Copyright (C) 2014 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include
+#include
+#include
+
+
+static int renesas_bsc_probe(struct platform_device *pdev)
+{
+ dev_dbg(>dev, "%s\n", __func__);
+
+ pm_runtime_enable(>dev);
+ return 0;
+}
+
+static int renesas_bsc_remove(struct platform_device *pdev)
+{
+ dev_dbg(>dev, "%s\n", __func__);
+
+ pm_runtime_disable(>dev);
+ return 0;
+}
+
+static const struct of_device_id renesas_bsc_of_match[] = {
+ { .compatible = "renesas,bsc", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, renesas_bsc_of_match);
+
+static struct platform_driver renesas_bsc_driver = {
+ .probe = renesas_bsc_probe,
+ .remove = renesas_bsc_remove,
+ .driver = {
+ .name = "renesas-bsc",
+ .of_match_table = renesas_bsc_of_match,
+ },
+};
+
+module_platform_driver(renesas_bsc_driver);
+
+MODULE_DESCRIPTION("Renesas Bus State Controller Driver");
+MODULE_AUTHOR("Geert Uytterhoeven ");
+MODULE_LICENSE("GPL");
--
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: [PATCH 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Sun, Nov 23, 2014 at 04:09:19PM +0100, Pali Rohár wrote: > + /* NOTE: rbtn controls all radio devices, not only WLAN > + but rfkill interface does not support "ANY" type > + so "WLAN" type is used > + */ If it controls multiple radio types then you should register multiple rfkill devices. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 05/12] mm: slub: introduce virt_to_obj function.
On Mon, 24 Nov 2014, Andrey Ryabinin wrote: > virt_to_obj takes kmem_cache address, address of slab page, > address x pointing somewhere inside slab object, > and returns address of the begging of object. Acked-by: Christoph Lameter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [4/5] i2c: davinci: use bus recovery infrastructure
Hi Grygorii, On Mon, Nov 24, 2014 at 03:26:10PM +0200, Grygorii Strashko wrote: > On 11/23/2014 10:36 PM, Uwe Kleine-König wrote: > > On Fri, Nov 21, 2014 at 09:33:22PM +0200, Grygorii Strashko wrote: > >> On 11/21/2014 09:07 PM, Uwe Kleine-König wrote: > >>> On Thu, Nov 20, 2014 at 12:03:07PM +0200, Grygorii Strashko wrote: > >>> Just another general comment about the driver that doesn't influence the > >>> correctness of this patch: The i2c-davinci driver is quite quick to > >>> reset the bus. I wonder how often this reset triggers. Is the bus in > >>> question less "stable" than others? > >> > >> In comparison to ..? :) > > In comparison to other bus drivers in other SoCs. I know this might be > > hard to answer. I just wonder where the reason for this has to be > > located. Strange hardware? Software bug? Or is this SoC just operating > > with strange slaves more often than others? > > Davinci driver does reset in two cases: > - when I2C transaction isn't completed due to timeout (no irq received) > - when BB is detected > both cases are reasonable, because in 1st case HW state is undefined > in 2d case - Davinci I2C supports only master mode and if BB detected > we need perform some recovery procedure. note that for multi-master scenarios bus recovery might be bad. So that has not necessarily something to do with "master mode only". > Also, this patch doesn't introduce functional changes - it's just code > reworking intended to reuse I2C bus recovery infrastructure Yeah this is fine, and my concern shouldn't stop your patch from getting in as it is an improvement for sure. Still I only had to handle BB once in my linux lifetime, and that was for a different reason. (Machine doing massive i2c transfers and so a client was often holding the bus busy when the watchdog resetted the cpu.) So I just wondered how often the need for recovery arises. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] exit: reparent: fix/update the comments in zap_pid_ns_processes()
The comments in zap_pid_ns_processes() are simply wrong, we need
to explain how this code actually works.
1. "Ignore SIGCHLD" looks like optimization but it is not, we also
need this for correctness.
2. The comment above sys_wait4() could be more clear.
3. The comment about TASK_DEAD children is outdated. Contrary to
what it says we do not need to make sure they all go away.
At the same time, we do need to wait for nr_hashed == init_pids,
but the reason is quite different and not obvious.
Signed-off-by: Oleg Nesterov
---
kernel/pid_namespace.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index db95d8e..1519b02 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -190,7 +190,11 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
/* Don't allow any more processes into the pid namespace */
disable_pid_allocation(pid_ns);
- /* Ignore SIGCHLD causing any terminated children to autoreap */
+ /*
+* Ignore SIGCHLD causing any terminated children to autoreap.
+* This speeds up the namespace shutdown, plus see the comment
+* below.
+*/
spin_lock_irq(>sighand->siglock);
me->sighand->action[SIGCHLD - 1].sa.sa_handler = SIG_IGN;
spin_unlock_irq(>sighand->siglock);
@@ -223,15 +227,26 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
}
read_unlock(_lock);
- /* Firstly reap the EXIT_ZOMBIE children we may have. */
+ /* Reap the EXIT_ZOMBIE children we had before we ignored SIGCHLD */
do {
clear_thread_flag(TIF_SIGPENDING);
rc = sys_wait4(-1, NULL, __WALL, NULL);
} while (rc != -ECHILD);
/*
-* sys_wait4() above can't reap the TASK_DEAD children.
-* Make sure they all go away, see free_pid().
+* sys_wait4() above can't reap the TASK_DEAD children but we do not
+* really care, we could reparent them to the global init. We could
+* exit and reap ->child_reaper even if it is not the last thread in
+* this pid_ns, free_pid(nr_hashed == 0) calls proc_cleanup_work(),
+* pid_ns can not go away until proc_kill_sb() drops the reference.
+*
+* But this namespace can also have other tasks injected by setns().
+* Again, we do not really need to wait until they are all reaped,
+* but they can be reparented to us and thus we need to ensure that
+* pid->child_reaper is valid until they all go away.
+*
+* We rely on ignored SIGCHLD, an injected zombie must be autoreaped
+* if reparented.
*/
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting
alloc_pid() does get_pid_ns() beforehand but forgets to put_pid_ns() if it fails because disable_pid_allocation() was called by the exiting child_reaper. We can move get_pid_ns() down to successful return. While at it, simplify/cleanup the "goto out" mess, no need to confuse the success/error return paths. Signed-off-by: Oleg Nesterov --- kernel/pid.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/kernel/pid.c b/kernel/pid.c index 9b9a266..dfc2f3b 100644 --- a/kernel/pid.c +++ b/kernel/pid.c @@ -320,7 +320,6 @@ struct pid *alloc_pid(struct pid_namespace *ns) goto out_free; } - get_pid_ns(ns); atomic_set(>count, 1); for (type = 0; type < PIDTYPE_MAX; ++type) INIT_HLIST_HEAD(>tasks[type]); @@ -336,7 +335,7 @@ struct pid *alloc_pid(struct pid_namespace *ns) } spin_unlock_irq(_lock); -out: + get_pid_ns(ns); return pid; out_unlock: @@ -346,8 +345,8 @@ out_free: free_pidmap(pid->numbers + i); kmem_cache_free(ns->pid_cachep, pid); - pid = NULL; - goto out; +out: + return NULL; } void disable_pid_allocation(struct pid_namespace *ns) -- 1.5.5.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/2] exit/pid_ns: comments + simple fix
Eric, Pavel, could you review 1/2 ? (documentation only). It is based on the code inspection, I didn't bother to verify that my understanding matches the reality ;) On 11/20, Oleg Nesterov wrote: > > > Probably this is not the last series... in particular it seems that we > have some problems with sys_setns() in this area, but I need to recheck. So far only the documentation fix. I'll write another email (hopefully with the patch), afaics at least setns() doesn't play well with PR_SET_CHILD_SUBREAPER. Contrary to what I thought zap_pid_ns_processes() looks fine, but it seems only by accident. Unless I am totally confused, wait for "nr_hashed == init_pids" could be removed after 0a01f2cc390e10633a "pidns: Make the pidns proc mount/ umount logic obvious". However, now that setns() + fork() can inject a task into a child namespace, we need this code again for another reason. I _think_ we can actually remove it and simplify free_pid() as well, but lets discuss this later and fix the wrong/confusing documentation first. 2/2 looks "obviously correct", but I'll appreciate your review anyway. Oleg. kernel/pid.c |7 +++ kernel/pid_namespace.c | 23 +++ 2 files changed, 22 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
Guys, I really sorry for that :( > Just try to boot it with your patch? :) Yes, may be two-three times (max). Something (u-boot, may be) leave the bus in the wrong state. Really strange. > But the test function should not loop forever in any case I take? It doesn't loop forever. It finish with message: "[3.046691] omap_i2c 4807.i2c: timeout waiting for bus ready" > So I doubt we just want to change the test for for a higher rev number > for OMAP_I2C_REV_ON_3430_3530. Yes, I'll do it within 15 minutes. And later, if it possible, I'd try to see what happens. Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
Christian Borntraeger wrote: > Looks really nice, but does not work with ACCESS_ONCE is on the left-hand > side: > > > include/linux/rculist.h: In function 'hlist_add_before_rcu': > ./arch/x86/include/asm/barrier.h:127:18: error: lvalue required as left > operand of assignment > ACCESS_ONCE(*p) = (v); \ > > Alexei's variant is also broken: > > include/linux/cgroup.h: In function 'task_css': > include/linux/compiler.h:381:40: error: invalid operands to binary + (have > 'struct css_set *' and 'struct css_set * volatile') > #define ACCESS_ONCE(x) (((typeof(x))0) + *(volatile typeof(x) *)&(x)) > > Anyone with a new propopal? ;-)^ Reserve ACCESS_ONCE() for reading and add an ASSIGN_ONCE() or something like that for writing? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/5] i2c: davinci: query STP always when NACK is received
Hello Grygorii, On Mon, Nov 24, 2014 at 03:34:35PM +0200, Grygorii Strashko wrote: > On 11/23/2014 10:33 PM, Uwe Kleine-König wrote: > > A call to .master_xfer with a message sequence implicitly expects ACKs > > from the slave and doesn't tell anything about what should be done on a > > NAK. So IMHO you must not send a P when the slave responds with a NAK, > > but error out and let the sender decide if it wants to reply with P or > > Sr. > > Sry, but what should be done is defined by I2C/SMbus specs? Does it? > For SMBus devices, the specification states (http://smbus.org/specs/) > "4.2.Acknowledge (ACK) and not acknowledge (NACK)": > - "The slave device detects an invalid command or invalid data. In this > case the slave device must not acknowledge the received byte. The master > upon detection of this condition must generate a STOP condition and > retry the transaction" > For I2C devices, the specification states > [http://www.nxp.com/documents/user_manual/UM10204.pdf]: > "3.1.6 Acknowledge (ACK) and Not Acknowledge (NACK)" > "When SDA remains HIGH during this ninth clock pulse, this is defined as the > Not > Acknowledge signal. The master can then generate either a STOP condition to > abort the transfer, or a repeated START condition to start a new transfer." Yes, that's exactly what I meant. The master has the choice, and the driver should not eliminate options here. > Let take a look on i2c/smbus xfer: > i2c_lock_adapter(adap) > adap->algo->master_xfer/smbus_xfer() > i2c_unlock_adapter(adap); > |- rt_mutex_unlock(>bus_lock); > |- task switch > > So, there is no guarantee that next xfer will address the same I2C client > device, > which, in turn, may lead to BB detection (will lead to BB detection if > previous > transfer has been not acknowledged by SMbus client device). That's a valid concern. > Small summary, I2C core + Davinci I2C driver provide ability to use repeated > start (Sr) only within one I2C transaction - which is a number of write/read > operations specified by i2c_msg array. NACK always interrupts transaction > with -EREMOTEIO. > > Also, the I2C core doesn't provide ability to manually send P. Hmm, Wolfram, what do you think? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/11] MIPS: Add multiplatform BMIPS target
On Mon, Nov 24, 2014 at 11:29 AM, Andrew Bresticker wrote:
>> diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
>
>> +void __init plat_time_init(void)
>> +{
>> + struct device_node *np;
>> + u32 freq;
>> +
>> + np = of_find_node_by_name(NULL, "cpus");
>> + if (!np)
>> + panic("missing 'cpus' DT node");
>> + if (of_property_read_u32(np, "mips-hpt-frequency", ) < 0)
>> + panic("missing 'mips-hpt-frequency' property");
>> + of_node_put(np);
>> +
>> + mips_hpt_frequency = freq;
>> +}
>
> Could you use common clock framework for this? Isn't the HPT just a
> fixed factor of the CPU clock? I'm planning on doing something very
> similar for ImgTec MIPS SoCs, so perhaps this could go in a common
> place, like the r4k clocksource driver?
Jonas and I had tossed some ideas around earlier, and I included a few
random thoughts in the cover letter.
One concern is that this currently has to be set pretty early in the
boot process (prior to jiffies calibration IIRC), so it might still
need to be handled as a special case.
Regarding the "fixed factor" question: that is true on all of the
chips I've seen, with a few additional caveats:
- Most MIPS cores use cpu_clk/2, but BMIPS5000 uses cpu_clk/8.
- Some MIPS cores scale the CP0 counter frequency when the cpu_clk is
changed, but others do not. Sometimes this depends on the core rev
(e.g. 65nm BMIPS438x cores do scale, but 40nm BMIPS438x cores do not).
- We might not necessarily have a good way to determine cpu_clk on
every platform, either.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] x86, traps: Add ist_begin_non_atomic and ist_end_non_atomic
On Mon, Nov 24, 2014 at 7:54 AM, Borislav Petkov wrote:
> On Fri, Nov 21, 2014 at 01:26:11PM -0800, Andy Lutomirski wrote:
>> In some IST handlers, if the interrupt came from user mode,
>> we can safely enable preemption. Add helpers to do it safely.
>>
>> This is intended to be used my the memory failure code in
>> do_machine_check.
>>
>> Signed-off-by: Andy Lutomirski
>> ---
>> arch/x86/include/asm/traps.h | 2 ++
>> arch/x86/kernel/traps.c | 38 ++
>> 2 files changed, 40 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
>> index eb16a61bfd06..04ba537fc721 100644
>> --- a/arch/x86/include/asm/traps.h
>> +++ b/arch/x86/include/asm/traps.h
>> @@ -112,6 +112,8 @@ asmlinkage void mce_threshold_interrupt(void);
>>
>> extern enum ctx_state ist_enter(struct pt_regs *regs);
>> extern void ist_exit(struct pt_regs *regs, enum ctx_state prev_state);
>> +extern void ist_begin_non_atomic(struct pt_regs *regs);
>> +extern void ist_end_non_atomic(void);
>>
>> /* Interrupts/Exceptions */
>> enum {
>> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
>> index 6a02760df7b4..2b5f2e038e3f 100644
>> --- a/arch/x86/kernel/traps.c
>> +++ b/arch/x86/kernel/traps.c
>> @@ -140,6 +140,44 @@ void ist_exit(struct pt_regs *regs, enum ctx_state
>> prev_state)
>> rcu_nmi_exit();
>> }
>>
>> +/**
>> + * ist_begin_non_atomic() - begin a non-atomic section in an IST exception
>> + * @regs:regs passed to the IST exception handler
>> + *
>> + * IST exception handlers normally cannot schedule. As a special
>> + * exception, if the exception interrupted userspace code (i.e.
>> + * user_mode_vm(regs) would return true) and the exception was not
>> + * a double fault, it can be safe to schedule. ist_begin_non_atomic()
>> + * begins a non-atomic section within an ist_enter()/ist_exit() region.
>> + * Callers are responsible for enabling interrupts themselves inside
>> + * the non-atomic section, and callers must call is_end_non_atomic()
>> + * before ist_exit().
>> + */
>
> Ok, I guess this is is fine, albeit a bit circumstantial:
>
> I need to do
>
> ist_enter()
> ist_begin_non_atomic()
>
> In here, I still need to do
>
> if (user_mode_vm()) {
> # do non-atomic stuff
> }
>
> AFAICT, right?
>
> ist_end_non_atomic()
> ist_exit()
>
> and this whole fun for the context tracking exception_enter/_exit()
> calls.
Not quite. This fun stuff is to satisfy Linus' request to make the
atomicness of the IST entries unconditional instead of depending on
the weird user_space_vm thing and to make the escape to non-atomicness
be clearly a special case.
So your code above should OOPS instead of working. The code should be:
ist_enter()
if (user_mode_vm()) {
ist_begin_non_atomic();
local_irq_enable();
# do non-atomic stuff
local_irq_disable();
ist_end_non_atomic();
}
ist_exit().
Although that user_mode_vm() check might be subsumed by the mce_severity stuff.
NB: This series is going to look a bit different once I rebase it.
This part is the same, but Linus merged some patches that change some
of the same code over the weekend.
--Andy
>
> Acked-by: Borislav Petkov
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Alexander Kochetkov [141124 11:41]: > > 24 нояб. 2014 г., в 22:08, Kevin Hilman написал(а): > > > This patch recently hit linux-next (as commit 903c3859f77f) and boot > > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > > was bisected down to this commit. > > > > Kevin > > > > [1] http://status.armcloud.us/boot/?next-20141124 > > > Could someone advice with debugging on OMAP3530? Just try to boot it with your patch? :) > I'd like to apply one one more commit to see events during boot and > see actual signals on wire (during of timeout)? If you post a patch, I can test boot with it. Looks like the failing ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx. But the test function should not loop forever in any case I take? So I doubt we just want to change the test for for a higher rev number for OMAP_I2C_REV_ON_3430_3530. > Otherwise, commit must dropped (or rewritten such way it is disabled by > default). > > > 24 нояб. 2014 г., в 22:13, Wolfram Sang написал(а): > > > OK, giving Alexander some time for a fix. If it can't be found, I'll > > revert this patch. Thanks! > > What deadline? I'd say by Tuesday as we have multiple automated test systems failing as soon as people update their trees. And when they are failing, we may miss other breakage happening in linux next. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] iio: add driver for the TI DAC8554
The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
interface.
Changes in v2:
* Use DMA-safe buffer for SPI transfer
* Normalize powerdown_mode name "hi-z" to "three_state" as per
ABI/testing/sysfs-bus-iio
* Register device late in probe function
* Avoid powerdown broadcast update, which touches all DAC on the bus
Signed-off-by: Nikolaus Schulz
---
drivers/iio/dac/Kconfig | 10 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ti-dac8554.c | 374 +++
3 files changed, 385 insertions(+)
create mode 100644 drivers/iio/dac/ti-dac8554.c
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 2236ea2..1689260 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -181,4 +181,14 @@ config MCP4922
To compile this driver as a module, choose M here: the module
will be called mcp4922.
+config TI_DAC8554
+ tristate "TI DAC8554 driver"
+ depends on SPI
+ depends on OF
+ help
+ Say yes here to build the driver for the TI DAC8554.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ti-dac8554.
+
endmenu
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 52be7e1..b98d79a 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
obj-$(CONFIG_MAX5821) += max5821.o
obj-$(CONFIG_MCP4725) += mcp4725.o
obj-$(CONFIG_MCP4922) += mcp4922.o
+obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
new file mode 100644
index 000..fca751f
--- /dev/null
+++ b/drivers/iio/dac/ti-dac8554.c
@@ -0,0 +1,374 @@
+/*
+ * TI DAC8554 Digital to Analog Converter SPI driver
+ *
+ * Copyright (C) 2014 Avionic Design GmbH
+ *
+ * Based on ad5446r_spi.c
+ * Copyright (C) 2010,2011 Analog Devices Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DAC8554_DRIVERNAME "ti-dac8554"
+#define DAC8554_DAC_CHANNELS 4
+
+/* Load commands */
+#define DAC8554_CMD_STORE_DAC_N0x0
+#define DAC8554_CMD_UPDATE_DAC_N 0x1
+#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL 0x2
+#define DAC8554_CMD_UPDATE_BROADCAST 0x3
+
+#define DAC8554_BROADCAST_USE_SRDATA 0x2
+/* Powerdown modes (ORed PD1|PD2 bits) */
+#define DAC8554_PWRDN_HIZ 0x0
+#define DAC8554_PWRDN_1K 0x1
+#define DAC8554_PWRDN_100K 0x2
+
+#define DAC8554_PWRDN_TO_SR(mode) (BIT(16) | (mode) << 14)
+
+/**
+ * struct dac8554_state - driver instance specific data
+ * @spi: spi_device
+ * @reg: supply regulator
+ * @addr: two-bit chip address
+ * @vref_mv: reference voltage in millivolt
+ * @valDAC/channel data
+ * @powerdown channel powerdown flag
+ * @powerdown_mode channel powerdown mode
+ * @xfer SPI transfer buffer
+ */
+struct dac8554_state {
+ struct spi_device *spi;
+ struct regulator*reg;
+ unsignedaddr;
+ unsignedvref_mv;
+ u16 val[DAC8554_DAC_CHANNELS];
+ boolpowerdown[DAC8554_DAC_CHANNELS];
+ u8 powerdown_mode[DAC8554_DAC_CHANNELS];
+
+ /*
+* DMA (thus cache coherency maintenance) requires the
+* transfer buffers to live in their own cache lines.
+*/
+ u8 xfer[3] cacheline_aligned;
+};
+
+static int dac8554_spi_write(struct dac8554_state *st,
+unsigned cmd,
+unsigned chan_addr,
+unsigned val)
+{
+ u32 data;
+
+ /*
+* The input shift register is 24 bits wide. The 8 MSB are
+* control bits, followed by 16 data bits.
+* The first two bits A1 and A0 address a DAC8554 chip.
+* The next two are the command bits, LD1 and LD0.
+* After a don't-care-bit, the next two bits select the channel.
+* The final control bit PD0 is a flag signalling if the data
+* bits encode a powerdown mode. We merge PD0 with the adjacent
+* data bits.
+*/
+
+ if (cmd > 3 || chan_addr > 3 ||
+ (val > 0x && (val & ~DAC8554_PWRDN_TO_SR(3
+ return -EINVAL;
+
+ data = (st->addr << 22) | (cmd << 20) | (chan_addr << 17) | val;
+ st->xfer[0] = data >> 16;
+ st->xfer[1] = data >> 8;
+ st->xfer[2] =
[PATCH v2 1/2] iio: document ti-dac8554 devicetree bindings
Signed-off-by: Nikolaus Schulz
---
.../devicetree/bindings/iio/dac/ti-dac8554.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/dac/ti-dac8554.txt
diff --git a/Documentation/devicetree/bindings/iio/dac/ti-dac8554.txt
b/Documentation/devicetree/bindings/iio/dac/ti-dac8554.txt
new file mode 100644
index 000..16f7178
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ti-dac8554.txt
@@ -0,0 +1,22 @@
+TI DAC8554 Digital to Analog Converter
+
+This driver supports the SPI bus.
+
+Required properties:
+ - compatible: must be "ti,dac8554"
+ - vref-supply: the vref power supply
+ - address: the additional 2-bit chip address
+
+For required properties on SPI, please consult
+Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+ dac8554@0 {
+ compatible = "ti,dac8554";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+
+ vref-supply = <_vref>;
+ address = <0>;
+ };
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/5] x86, traps: Track entry into and exit from IST context
On Sat, Nov 22, 2014 at 9:20 AM, Borislav Petkov wrote:
> On Fri, Nov 21, 2014 at 01:26:08PM -0800, Andy Lutomirski wrote:
>> We currently pretend that IST context is like standard exception
>> context, but this is incorrect. IST entries from userspace are like
>> standard exceptions except that they use per-cpu stacks, so they are
>> atomic. IST entries from kernel space are like NMIs from RCU's
>> perspective -- they are not quiescent states even if they
>> interrupted the kernel during a quiescent state.
>>
>> Add and use ist_enter and ist_exit to track IST context. Even
>> though x86_32 has no IST stacks, we track these interrupts the same
>> way.
>>
>> This fixes two issues:
>>
>> - Scheduling from an IST interrupt handler will now warn. It would
>>previously appear to work as long as we got lucky and nothing
>>overwrote the stack frame. (I don't know of any bugs in this
>>that would trigger the warning, but it's good to be on the safe
>>side.)
>>
>> - RCU handling in IST context was dangerous. As far as I know,
>>only machine checks were likely to trigger this, but it's good to
>>be on the safe side.
>>
>> Note that the machine check handlers appears to have been missing
>> any context tracking at all before this patch.
>>
>> Cc: "Paul E. McKenney"
>> Cc: Josh Triplett
>> Cc: Frédéric Weisbecker
>> Signed-off-by: Andy Lutomirski
>> ---
>> arch/x86/include/asm/traps.h | 4 +++
>> arch/x86/kernel/cpu/mcheck/mce.c | 5
>> arch/x86/kernel/cpu/mcheck/p5.c | 6 +
>> arch/x86/kernel/cpu/mcheck/winchip.c | 5
>> arch/x86/kernel/traps.c | 49
>> ++--
>> 5 files changed, 61 insertions(+), 8 deletions(-)
>
> ...
>
>> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
>> index 0d0e922fafc1..f5c4b8813774 100644
>> --- a/arch/x86/kernel/traps.c
>> +++ b/arch/x86/kernel/traps.c
>> @@ -107,6 +107,39 @@ static inline void preempt_conditional_cli(struct
>> pt_regs *regs)
>> preempt_count_dec();
>> }
>>
>> +enum ctx_state ist_enter(struct pt_regs *regs)
>> +{
>> + /*
>> + * We are atomic because we're on the IST stack (or we're on x86_32,
>> + * in which case we still shouldn't schedule.
>> + */
>> + preempt_count_add(HARDIRQ_OFFSET);
>> +
>> + if (user_mode_vm(regs)) {
>> + /* Other than that, we're just an exception. */
>> + return exception_enter();
>> + } else {
>> + /*
>> + * We might have interrupted pretty much anything. In
>> + * fact, if we're a machine check, we can even interrupt
>> + * NMI processing. We don't want in_nmi() to return true,
>> + * but we need to notify RCU.
>> + */
>> + rcu_nmi_enter();
>> + return IN_KERNEL; /* the value is irrelevant. */
>> + }
>
> I guess dropping the explicit else-branch could make it look a bit nicer
> with the curly braces gone and all...
>
> enum ctx_state ist_enter(struct pt_regs *regs)
> {
> /*
> * We are atomic because we're on the IST stack (or we're on x86_32,
> * in which case we still shouldn't schedule.
> */
> preempt_count_add(HARDIRQ_OFFSET);
>
> if (user_mode_vm(regs))
> /* Other than that, we're just an exception. */
> return exception_enter();
>
Two indented lines w/o curly braces makes me think of goto fail; :-/
TBH, when there are clearly two options, I tend to prefer the braces
that make it very obvious what's going on. I had some memorable bugs
several years ago that would have been impossible if I has used braces
more liberally.
--Andy
> /*
> * We might have interrupted pretty much anything. In fact, if we're
> a
> * machine check, we can even interrupt NMI processing. We don't want
> * in_nmi() to return true, but we need to notify RCU.
> */
> rcu_nmi_enter();
> return IN_KERNEL; /* the value is irrelevant. */
> }
>
>> +}
>> +
>> +void ist_exit(struct pt_regs *regs, enum ctx_state prev_state)
>> +{
>> + preempt_count_sub(HARDIRQ_OFFSET);
>> +
>> + if (user_mode_vm(regs))
>> + return exception_exit(prev_state);
>> + else
>> + rcu_nmi_exit();
>> +}
>
> Ditto here.
>
>> +
>> static nokprobe_inline int
>> do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str,
>> struct pt_regs *regs, long error_code)
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
Hi Grygorii, On Mon, Nov 24, 2014 at 03:15:58PM +0200, Grygorii Strashko wrote: > On 11/23/2014 07:04 PM, Uwe Kleine-König wrote: > > On Thu, Nov 20, 2014 at 12:03:08PM +0200, Grygorii Strashko wrote: > >> @@ -664,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device > >> *pdev) > >>if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", > >>)) > >>dev->pdata->bus_freq = prop / 1000; > >> + dev->pdata->has_pfunc = true; > > I don't understand this. Why does this ICPFUNC recovery work if the bus > > is probed by oftree, but doesn't if not? > > I've mentioned this in commit message: > Allow platforms to indicate the presence of the ICPFUNC registers with a > has_pfunc > platform data flag and enable this mode for platforms which supports DT > (da850 and > Keystone 2 are two SoCs which support DT now and they also support ICPFUNC > registers). Ah, so you assume that in the dt case the pfunc functionality is available. I didn't understand if it's bad or not if this assumption is wrong, but I suggest to only use the pfunc stuff if the device node has a given property (e.g. ti,has_pfunc). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net/ping: handle protocol mismatching scenario
ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
sock will be returned.
the fix is to "continue" the searching, if no matching, return NULL.
Cc: "David S. Miller"
Cc: Alexey Kuznetsov
Cc: James Morris
Cc: Hideaki YOSHIFUJI
Cc: Patrick McHardy
Cc: net...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Jane Zhou
Signed-off-by: Yiwei Zhao
---
net/ipv4/ping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index fc1c4b1..8892913 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -214,6 +214,8 @@ static struct sock *ping_lookup(struct net *net, struct
sk_buff *skb, u16 ident)
_hdr(skb)->daddr))
continue;
#endif
+ } else {
+ continue;
}
if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif)
--
1.8.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/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
On Mon, Nov 24, 2014 at 11:14:42AM -0800, Linus Torvalds wrote:
> On Mon, Nov 24, 2014 at 11:07 AM, Christian Borntraeger
> wrote:
> >
> > Looks really nice, but does not work with ACCESS_ONCE is on the left-hand
> > side:
>
> Oh, I forgot about that. And that was indeed why I had done that whole
> helper macro originally, with ACCESS_ONCE() itself just being the
> dereference of the pointer.
OK, how about the following?
It complains if the variable is too large, for example, long long on
32-bit systems or large structures. It is OK loading from and storing
to small structures as well, which I am having a hard time thinking of
as a disadvantage.
Thanx, Paul
#define get_scalar_volatile_pointer(x) ({ \
volatile typeof(x) *__vp = &(x); \
BUILD_BUG_ON(sizeof(*__vp) != sizeof(char) && \
sizeof(*__vp) != sizeof(short) && \
sizeof(*__vp) != sizeof(int) && \
sizeof(*__vp) != sizeof(long)); \
__vp; })
#define ACCESS_ONCE(x) (*get_scalar_volatile_pointer(x))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] platform: x86: Deletion of checks before backlight_device_unregister()
From: Markus Elfring
Date: Mon, 24 Nov 2014 20:30:29 +0100
The backlight_device_unregister() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/platform/x86/asus-laptop.c| 3 +--
drivers/platform/x86/asus-wmi.c | 3 +--
drivers/platform/x86/eeepc-laptop.c | 3 +--
drivers/platform/x86/fujitsu-laptop.c | 6 ++
drivers/platform/x86/ideapad-laptop.c | 3 +--
drivers/platform/x86/intel_oaktrail.c | 3 +--
drivers/platform/x86/msi-wmi.c| 3 +--
drivers/platform/x86/sony-laptop.c| 3 +--
drivers/platform/x86/toshiba_acpi.c | 3 +--
9 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 7f4dc6f..11fac1a 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -843,8 +843,7 @@ static int asus_backlight_init(struct asus_laptop *asus)
static void asus_backlight_exit(struct asus_laptop *asus)
{
- if (asus->backlight_device)
- backlight_device_unregister(asus->backlight_device);
+ backlight_device_unregister(asus->backlight_device);
asus->backlight_device = NULL;
}
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 21fc932..7543a56 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1308,8 +1308,7 @@ static int asus_wmi_backlight_init(struct asus_wmi *asus)
static void asus_wmi_backlight_exit(struct asus_wmi *asus)
{
- if (asus->backlight_device)
- backlight_device_unregister(asus->backlight_device);
+ backlight_device_unregister(asus->backlight_device);
asus->backlight_device = NULL;
}
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index bd533c2..9bc7eb7 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1158,8 +1158,7 @@ static int eeepc_backlight_init(struct eeepc_laptop
*eeepc)
static void eeepc_backlight_exit(struct eeepc_laptop *eeepc)
{
- if (eeepc->backlight_device)
- backlight_device_unregister(eeepc->backlight_device);
+ backlight_device_unregister(eeepc->backlight_device);
eeepc->backlight_device = NULL;
}
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 87aa28c..f1a670b 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -1147,8 +1147,7 @@ fail_hotkey1:
fail_hotkey:
platform_driver_unregister(_driver);
fail_backlight:
- if (fujitsu->bl_device)
- backlight_device_unregister(fujitsu->bl_device);
+ backlight_device_unregister(fujitsu->bl_device);
fail_sysfs_group:
sysfs_remove_group(>pf_device->dev.kobj,
_attribute_group);
@@ -1172,8 +1171,7 @@ static void __exit fujitsu_cleanup(void)
platform_driver_unregister(_driver);
- if (fujitsu->bl_device)
- backlight_device_unregister(fujitsu->bl_device);
+ backlight_device_unregister(fujitsu->bl_device);
sysfs_remove_group(>pf_device->dev.kobj,
_attribute_group);
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index ed494f3..3163061 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -729,8 +729,7 @@ static int ideapad_backlight_init(struct ideapad_private
*priv)
static void ideapad_backlight_exit(struct ideapad_private *priv)
{
- if (priv->blightdev)
- backlight_device_unregister(priv->blightdev);
+ backlight_device_unregister(priv->blightdev);
priv->blightdev = NULL;
}
diff --git a/drivers/platform/x86/intel_oaktrail.c
b/drivers/platform/x86/intel_oaktrail.c
index 4bc9604..0dd72cf 100644
--- a/drivers/platform/x86/intel_oaktrail.c
+++ b/drivers/platform/x86/intel_oaktrail.c
@@ -271,8 +271,7 @@ static int oaktrail_backlight_init(void)
static void oaktrail_backlight_exit(void)
{
- if (oaktrail_bl_device)
- backlight_device_unregister(oaktrail_bl_device);
+ backlight_device_unregister(oaktrail_bl_device);
}
static int oaktrail_probe(struct platform_device *pdev)
diff --git a/drivers/platform/x86/msi-wmi.c b/drivers/platform/x86/msi-wmi.c
index 70222f2..6d2bac0 100644
--- a/drivers/platform/x86/msi-wmi.c
+++ b/drivers/platform/x86/msi-wmi.c
@@ -354,8 +354,7 @@ static void __exit msi_wmi_exit(void)
sparse_keymap_free(msi_wmi_input_dev);
input_unregister_device(msi_wmi_input_dev);
}
- if (backlight)
- backlight_device_unregister(backlight);
+ backlight_device_unregister(backlight);
}
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
24 нояб. 2014 г., в 22:08, Kevin Hilman написал(а): > This patch recently hit linux-next (as commit 903c3859f77f) and boot > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > was bisected down to this commit. > > Kevin > > [1] http://status.armcloud.us/boot/?next-20141124 Could someone advice with debugging on OMAP3530? I'd like to apply one one more commit to see events during boot and see actual signals on wire (during of timeout)? Otherwise, commit must dropped (or rewritten such way it is disabled by default). 24 нояб. 2014 г., в 22:13, Wolfram Sang написал(а): > OK, giving Alexander some time for a fix. If it can't be found, I'll > revert this patch. Thanks! What deadline? Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tty: serial: msm_serial: document DT alias
On Fri, Nov 14, 2014 at 02:07:15PM -0800, Frank Rowand wrote:
> From: Frank Rowand
>
> Update devicetree binding for msm_serial to reflect msm_serial_probe()
> getting line id (port number) from the serialN alias.
>
> Signed-off-by: Frank Rowand
> ---
> Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt | 15
> +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> Index: linux/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> ===
> --- linux.orig/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> +++ linux/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> @@ -27,27 +27,52 @@ Optional properties:
> - dmas: Should contain dma specifiers for transmit and receive channels
> - dma-names: Should contain "tx" for transmit and "rx" for receive channels
>
> +Note: Aliases may be defined to ensure the correct ordering of the UARTs.
> +The alias serialN will result in the UART being assigned port N. If any
> +serialN alias exists, then an alias must exist for each enabled UART. The
> +serialN aliases should be in a .dts file instead of in a .dtsi file.
> +
> Examples:
>
> -A uartdm v1.4 device with dma capabilities.
> +- A uartdm v1.4 device with dma capabilities.
> +
> + serial@f991e000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0xf991e000 0x1000>;
> + interrupts = <0 108 0x0>;
> + clocks = <_uart2_apps_cxc>, <_ahb_cxc>;
> + clock-names = "core", "iface";
> + dmas = < 0>, < 1>;
> + dma-names = "tx", "rx";
> + };
> +
> +- A uartdm v1.3 device without dma capabilities and part of a GSBI complex.
> +
> + serial@19c4 {
> + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
> + reg = <0x19c4 0x1000>,
> + <0x19c0 0x1000>;
> + interrupts = <0 195 0x0>;
> + clocks = <_uart_cxc>, <_ahb_cxc>;
> + clock-names = "core", "iface";
> + };
> +
> +- serialN alias.
> +
> + aliases {
> + serial0 =
> + serial1 =
> + serial2 =
> + };
> +
> + uarta: serial@1249 {
> + status = "ok";
> + };
> +
> + uartb: serial@1634 {
> + status = "ok";
> + };
>
> -serial@f991e000 {
> - compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> - reg = <0xf991e000 0x1000>;
> - interrupts = <0 108 0x0>;
> - clocks = <_uart2_apps_cxc>, <_ahb_cxc>;
> - clock-names = "core", "iface";
> - dmas = < 0>, < 1>;
> - dma-names = "tx", "rx";
> -};
> -
> -A uartdm v1.3 device without dma capabilities and part of a GSBI complex.
> -
> -serial@19c4 {
> - compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
> - reg = <0x19c4 0x1000>,
> - <0x19c0 0x1000>;
> - interrupts = <0 195 0x0>;
> - clocks = <_uart_cxc>, <_ahb_cxc>;
> - clock-names = "core", "iface";
> -};
> + uartc: serial@1a24 {
> + status = "ok";
> + };
Git complained about a whitespace issue in this patch, which I fixed up
by hand. Please be more careful...
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/
[PATCH v2 net-next 3/3] tuntap: reduce the size of tun_struct by using flex array.
This patch switches to flex array to implement the flow caches, it brings
several advantages:
- Reduce the size of the tun_struct structure, which allows us to increase the
upper limit of queues in future.
- Avoid higher order memory allocation. It will be useful when switching to
pure hashing in flow cache which may demand a larger size array in future.
After this patch, the size of tun_struct on x86_64 reduced from 8512 to
328
Signed-off-by: Jason Wang
Signed-off-by: Pankaj Gupta
Reviewed-by: David Gibson
---
drivers/net/tun.c | 49 +
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e3fa65a..bd07a6d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -188,7 +189,7 @@ struct tun_struct {
int debug;
#endif
spinlock_t lock;
- struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
+ struct flex_array *flows;
struct timer_list flow_gc_timer;
unsigned long ageing_time;
unsigned int numdisabled;
@@ -249,10 +250,11 @@ static void tun_flow_flush(struct tun_struct *tun)
spin_lock_bh(>lock);
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
+ struct hlist_head *h = flex_array_get(tun->flows, i);
struct tun_flow_entry *e;
struct hlist_node *n;
- hlist_for_each_entry_safe(e, n, >flows[i], hash_link)
+ hlist_for_each_entry_safe(e, n, h, hash_link)
tun_flow_delete(tun, e);
}
spin_unlock_bh(>lock);
@@ -264,10 +266,11 @@ static void tun_flow_delete_by_queue(struct tun_struct
*tun, u16 queue_index)
spin_lock_bh(>lock);
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
+ struct hlist_head *h = flex_array_get(tun->flows, i);
struct tun_flow_entry *e;
struct hlist_node *n;
- hlist_for_each_entry_safe(e, n, >flows[i], hash_link) {
+ hlist_for_each_entry_safe(e, n, h, hash_link) {
if (e->queue_index == queue_index)
tun_flow_delete(tun, e);
}
@@ -287,10 +290,11 @@ static void tun_flow_cleanup(unsigned long data)
spin_lock_bh(>lock);
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
+ struct hlist_head *h = flex_array_get(tun->flows, i);
struct tun_flow_entry *e;
struct hlist_node *n;
- hlist_for_each_entry_safe(e, n, >flows[i], hash_link) {
+ hlist_for_each_entry_safe(e, n, h, hash_link) {
unsigned long this_timer;
count++;
this_timer = e->updated + delay;
@@ -317,7 +321,7 @@ static void tun_flow_update(struct tun_struct *tun, u32
rxhash,
if (!rxhash)
return;
else
- head = >flows[tun_hashfn(rxhash)];
+ head = flex_array_get(tun->flows, tun_hashfn(rxhash));
rcu_read_lock();
@@ -380,7 +384,8 @@ static u16 tun_select_queue(struct net_device *dev, struct
sk_buff *skb,
txq = skb_get_hash(skb);
if (txq) {
- e = tun_flow_find(>flows[tun_hashfn(txq)], txq);
+ e = tun_flow_find(flex_array_get(tun->flows,
+tun_hashfn(txq)), txq);
if (e) {
tun_flow_save_rps_rxhash(e, txq);
txq = e->queue_index;
@@ -760,8 +765,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct
net_device *dev)
rxhash = skb_get_hash(skb);
if (rxhash) {
struct tun_flow_entry *e;
- e = tun_flow_find(>flows[tun_hashfn(rxhash)],
- rxhash);
+ e = tun_flow_find(flex_array_get(tun->flows,
+tun_hashfn(rxhash)),
rxhash);
if (e)
tun_flow_save_rps_rxhash(e, rxhash);
}
@@ -896,23 +901,40 @@ static const struct net_device_ops tap_netdev_ops = {
#endif
};
-static void tun_flow_init(struct tun_struct *tun)
+static int tun_flow_init(struct tun_struct *tun)
{
- int i;
+ struct flex_array *buckets;
+ int i, err;
+
+ buckets = flex_array_alloc(sizeof(struct hlist_head),
+ TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
+ if (!buckets)
+ return -ENOMEM;
+
+ err = flex_array_prealloc(buckets, 0, TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
+ if (err) {
+ flex_array_free(buckets);
+ return -ENOMEM;
+ }
+ tun->flows = buckets;
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++)
-
Re: [Keyrings] [PATCH 2/5] X.509: Support X.509 lookup by Issuer+Serial form AuthorityKeyIdentifier
Mimi Zohar wrote: > I would assume so, but the original code looked like "id->data" could > have been null. It can't be - it's an embedded array. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: include crypto- module prefix in template
On 24 November 2014 at 20:17, Kees Cook wrote: > This adds the module loading prefix "crypto-" to the template lookup > as well. > > For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly > includes the "crypto-" prefix at every level, correctly rejecting "vfat": > > net-pf-38 > algif-hash > crypto-vfat(blowfish) > crypto-vfat(blowfish)-all > crypto-vfat > > Reported-by: Mathias Krause > Signed-off-by: Kees Cook > --- > crypto/algapi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) That commit will break the user API again as ciphers like 'cbc(aes)' won't work any more -- as the cbc module won't be loaded. You're missing the MODULE_ALIAS_CRYPTO() annotaions for all the crypto templates -- cbc, ctr, xts, hmac, ... Regards, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
On Mon, Nov 24, 2014 at 08:05:10AM -0800, Josh Triplett wrote:
> On Mon, Nov 24, 2014 at 10:49:31AM +0100, Pieter Smith wrote:
> > On Sun, Nov 23, 2014 at 03:23:02PM -0800, Josh Triplett wrote:
> > > On Sun, Nov 23, 2014 at 11:29:08PM +0100, Richard Weinberger wrote:
> > > > On Sun, Nov 23, 2014 at 3:20 PM, Pieter Smith wrote:
> > > > > To implement splice support, fs/fuse makes use of
> > > > > nosteal_pipe_buf_ops. This
> > > > > struct is exported by fs/splice. The goal of the larger patch set is
> > > > > to
> > > > > completely compile out fs/splice, so uses of the exported struct need
> > > > > to be
> > > > > compiled out along with fs/splice.
> > > > >
> > > > > This patch therefore compiles out splice support in fs/fuse when
> > > > > CONFIG_SYSCALL_SPLICE is undefined.
> > > > >
> > > > > Signed-off-by: Pieter Smith
> > > > > ---
> > > > > fs/fuse/dev.c | 4 ++--
> > > > > include/linux/fs.h | 6 ++
> > > > > 2 files changed, 8 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > > > index ca88731..f8f92a4 100644
> > > > > --- a/fs/fuse/dev.c
> > > > > +++ b/fs/fuse/dev.c
> > > > > @@ -1291,7 +1291,7 @@ static ssize_t fuse_dev_read(struct kiocb
> > > > > *iocb, const struct iovec *iov,
> > > > > return fuse_dev_do_read(fc, file, , iov_length(iov,
> > > > > nr_segs));
> > > > > }
> > > > >
> > > > > -static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > > > > +static ssize_t __maybe_unused fuse_dev_splice_read(struct file *in,
> > > > > loff_t *ppos,
> > > > > struct pipe_inode_info *pipe,
> > > > > size_t len, unsigned int flags)
> > > > > {
> > > > > @@ -2144,7 +2144,7 @@ const struct file_operations
> > > > > fuse_dev_operations = {
> > > > > .llseek = no_llseek,
> > > > > .read = do_sync_read,
> > > > > .aio_read = fuse_dev_read,
> > > > > - .splice_read= fuse_dev_splice_read,
> > > > > + .splice_read= __splice_p(fuse_dev_splice_read),
> > > > > .write = do_sync_write,
> > > > > .aio_write = fuse_dev_write,
> > > > > .splice_write = fuse_dev_splice_write,
> > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > > > index a957d43..04c0975 100644
> > > > > --- a/include/linux/fs.h
> > > > > +++ b/include/linux/fs.h
> > > > > @@ -2443,6 +2443,12 @@ extern int blkdev_fsync(struct file *filp,
> > > > > loff_t start, loff_t end,
> > > > > int datasync);
> > > > > extern void block_sync_page(struct page *page);
> > > > >
> > > > > +#ifdef CONFIG_SYSCALL_SPLICE
> > > > > +#define __splice_p(x) x
> > > > > +#else
> > > > > +#define __splice_p(x) NULL
> > > > > +#endif
> > > > > +
> > > >
> > > > This needs to go into a different patch.
> > > > One logical change per patch please. :-)
> > >
> > > Easy enough to merge this one into the patch introducing
> > > CONFIG_SYSCALL_SPLICE, then.
> > >
> > > - Josh Triplett
> >
> > The patch introducing CONFIG_SYSCALL_SPLICE (PATCH 3) only compiles out the
> > syscalls. PATCH 6 on the other hand, compiles out fs/splice.c. This patch
> > allows fs/fuse to be compiled when fs/splice.c is compiled out. If I am to
> > squash it, it would be logical to include it in PATCH 6, not 3.
>
> The suggestion wasn't to move the fs/fuse/dev.c bits; those should
> definitely stay in this patch. The suggestion was just to move the bit
> of the patch defining __splice_p from this patch to patch 3. (Note that
> you need to define it before you use it, so it can't go in patch 6.)
I would, again, argue that stuff like __splice_p() not be implemented at
all please. It will only cause a huge proliferation of stuff like this
that will not make any sense, and only cause a trivial, if any, amount
of code savings.
I thought you were going to not do this type of thing until you got the
gcc optimizer working for function callbacks.
Again, don't do this please.
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] drivers:block Remove unneeded Fix me message in xsyace.c
On Mon, 2014-11-24 at 08:31PM +0100, Michal Simek wrote:
> On 11/24/2014 08:25 PM, Nicholas Krause wrote:
> > Removes unneeded FIXME message related to using a hard coded value for
> > ACE_BUS_WIDTH
> > due to it needing to be 8 bits, this is wrong as this function here needs
> > all 16 bits
> > of the bus width and not just the lower or higher 16 depending on the
> > machine's bit
> > order.
> >
> > Signed-off-by: Nicholas Krause
> > ---
> > drivers/block/xsysace.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> > index c4328d9..1b807ed 100644
> > --- a/drivers/block/xsysace.c
> > +++ b/drivers/block/xsysace.c
> > @@ -1152,7 +1152,7 @@ static void ace_free(struct device *dev)
> > static int ace_probe(struct platform_device *dev)
> > {
> > resource_size_t physaddr = 0;
> > - int bus_width = ACE_BUS_WIDTH_16; /* FIXME: should not be hard coded */
> > + int bus_width = ACE_BUS_WIDTH_16;
> > u32 id = dev->id;
> > int irq = 0;
> > int i;
> >
>
> Reviewed-by: Michal Simek
I find the commit message rather misleading, but the change is OK.
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers:block Remove unneeded Fix me message in xsyace.c
On 11/24/2014 08:25 PM, Nicholas Krause wrote:
> Removes unneeded FIXME message related to using a hard coded value for
> ACE_BUS_WIDTH
> due to it needing to be 8 bits, this is wrong as this function here needs all
> 16 bits
> of the bus width and not just the lower or higher 16 depending on the
> machine's bit
> order.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/block/xsysace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> index c4328d9..1b807ed 100644
> --- a/drivers/block/xsysace.c
> +++ b/drivers/block/xsysace.c
> @@ -1152,7 +1152,7 @@ static void ace_free(struct device *dev)
> static int ace_probe(struct platform_device *dev)
> {
> resource_size_t physaddr = 0;
> - int bus_width = ACE_BUS_WIDTH_16; /* FIXME: should not be hard coded */
> + int bus_width = ACE_BUS_WIDTH_16;
> u32 id = dev->id;
> int irq = 0;
> int i;
>
Reviewed-by: Michal Simek
Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/4] irqchip: gic: Support hierarchy irq domain.
On 21/11/14 15:51, Yingjoe Chen wrote:
>
> Hi,
>
> On Thu, 2014-11-20 at 10:07 +, Marc Zyngier wrote:
>> On Thu, Nov 20 2014 at 4:26:10 am GMT, Jiang Liu
>> wrote:
>>
>> Hi Jiang,
>>
>>> On 2014/11/20 1:18, Marc Zyngier wrote:
Hi Yingjoe,
On Wed, Nov 19 2014 at 2:14:08 pm GMT, Yingjoe Chen
wrote:
> +
> +static const struct irq_domain_ops gic_irq_domain_hierarchy_ops = {
> + .xlate = gic_irq_domain_xlate,
> + .alloc = gic_irq_domain_alloc,
> + .free = irq_domain_free_irqs_top,
I'm convinced that irq_domain_free_irqs_top is the wrong function to
call here, because you're calling it from the bottom, not the top-level
(it has no parent).
I cannot verify this with your code as I don't a working platform with
GICv2m, but if I enable something similar on GICv3, it dies a very
painful way:
Unable to handle kernel NULL pointer dereference at virtual address
0018
pgd = ffc03d059000
[0018] *pgd=81356003, *pud=81356003,
*pmd=
Internal error: Oops: 9606 [#1] SMP
Modules linked in:
CPU: 4 PID: 1052 Comm: sh Not tainted 3.18.0-rc4+ #3311
task: ffc03e32 ti: ffc00139 task.ti: ffc00139
PC is at irq_domain_free_irqs_recursive+0x1c/0x80
LR is at irq_domain_free_irqs_common+0x88/0x9c
pc : [] lr : [] pstate: 6145
[...]
[] irq_domain_free_irqs_recursive+0x1c/0x80
[] irq_domain_free_irqs_common+0x84/0x9c
[] irq_domain_free_irqs_top+0x64/0x7c <--
gic_domain.free()
[] irq_domain_free_irqs_recursive+0x24/0x80
[] irq_domain_free_irqs_parent+0x14/0x20
[] its_irq_domain_free+0xc8/0x250
[] irq_domain_free_irqs_recursive+0x24/0x80
[] irq_domain_free_irqs_common+0x84/0x9c
[] irq_domain_free_irqs_top+0x64/0x7c
[] msi_domain_free+0x70/0x88
[] irq_domain_free_irqs_recursive+0x24/0x80
[] irq_domain_free_irqs+0x108/0x17c
[] msi_domain_free_irqs+0x28/0x4c
[] free_msi_irqs+0xb4/0x1c0
[] pci_disable_msix+0x3c/0x4c
[...]
and I cannot see how this could work on the standard GIC either.
Thomas, Jiang: could you please confirm or infirm my suspicions? My
understanding is that irq_domain_free_irqs_top can only be called from
the top-level domain.
>>> Hi Marc,
>>> It indicates that irq_domain_free_irqs_top() is not a good name.
>>> We have:
>>> 1) irq_domain_set_hwirq_and_chip() to set irq_chip and chip_data
>>> 2) irq_domain_set_info() to set irq_chip, chip_data, flow_handler and
>>>handler_data;
>>> 3) irq_domain_reset_irq_data() resets irq_chip and chip_data.
>>> 4) irq_domain_free_irqs_common() resets irq_chip, chip_data and calls
>>>parent domain's domain_ops.free() callback.
>>> 5) irq_domain_free_irqs_top() resets irq_chip, chip_data, flow handler,
>>>handler_data and call parent domain's domain_ops.free() callback.
>>
>> Yes, and this "call parent domain's free callback" is where the problem
>> lies. Here, it is called from the innermost domain, with no parent.
>>
>>> So there two possible improvements here:
>>> 1) Rename irq_domain_free_irqs_top() with better name, any suggestions?
>>>It's named as is because it's always called by the outer-most
>>>irqdomains on x86.
>>> 2) Change irq_domain_free_irqs_common() and irq_domain_free_irqs_top()
>>>to call parent domain's domain_ops.free() callback only if parent
>>>exists. By this way, they could be used for inner-most irqdomains.
>>> If OK, I will respin a version 4 patch set based on tip/irq/irqdomain.
>>> Thoughts?
>>
>> Checking the parent is probably a safe solution (this is not a hot path
>> anyway). I don't care much about the name though, and I the only thing I
>> can think of is irq_domain_free_irqs_reset_flow, which looks so bad it's
>> not even funny. I'll let the matter rest in your capable hands! ;-)
>
> I've applied Jiang's "irqdomain: Enhance irq_domain_free_irqs_common()
> to support parentless irqdomain" patch and it did fix the crash.
Excellent. I think this is pretty much getting there now. Any chance
you could repost this series with the various fixes?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] MIPS: Add multiplatform BMIPS target
> diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
> +void __init plat_time_init(void)
> +{
> + struct device_node *np;
> + u32 freq;
> +
> + np = of_find_node_by_name(NULL, "cpus");
> + if (!np)
> + panic("missing 'cpus' DT node");
> + if (of_property_read_u32(np, "mips-hpt-frequency", ) < 0)
> + panic("missing 'mips-hpt-frequency' property");
> + of_node_put(np);
> +
> + mips_hpt_frequency = freq;
> +}
Could you use common clock framework for this? Isn't the HPT just a
fixed factor of the CPU clock? I'm planning on doing something very
similar for ImgTec MIPS SoCs, so perhaps this could go in a common
place, like the r4k clocksource driver?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Wolfram Sang [141124 11:14]: > On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote: > > On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: > > > On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov > > > wrote: > > > > In a multimaster environment, after IP software reset, BB-bit value > > > > doesn't > > > > correspond to the current bus state. It may happen what BB-bit will be > > > > 0, > > > > while the bus is busy due to another I2C master activity. > > > > > > > > Any transfer started when BB=0 and bus is busy wouldn't be completed by > > > > IP > > > > and results in controller timeout. More over, in some cases IP could > > > > interrupt another master's transfer and corrupt data on wire. > > > > > > > > The commit implement method allowing to prevent IP from entering into > > > > "controller timeout" state and from "data corruption" state. > > > > > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > > > > > Tested on Beagleboard XM C. > > > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > > > > > Signed-off-by: Alexander Kochetkov > > > > Tested-by: Felipe Balbi > > > > Reviewed-by: Felipe Balbi > > > > > > This patch recently hit linux-next (as commit 903c3859f77f) and boot > > > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > > > was bisected down to this commit. > > > > > > Kevin > > > > > > [1] http://status.armcloud.us/boot/?next-20141124 > > > > btw, based on Kevin's boot test, only OMAP3530 is failing. > > OK, giving Alexander some time for a fix. If it can't be found, I'll > revert this patch. Thanks! I can confirm reverting it fixes things for me as well thanks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
On 11/24/2014 08:13 PM, Mike Looijmans wrote: > On 24-11-2014 14:15, Grygorii Strashko wrote: >> Hi Uwe, >> On 11/23/2014 07:04 PM, Uwe Kleine-König wrote: >>> On Thu, Nov 20, 2014 at 12:03:08PM +0200, Grygorii Strashko wrote: @@ -664,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev) if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", )) dev->pdata->bus_freq = prop / 1000; +dev->pdata->has_pfunc = true; >>> I don't understand this. Why does this ICPFUNC recovery work if the bus >>> is probed by oftree, but doesn't if not? >> I've mentioned this in commit message: >> Allow platforms to indicate the presence of the ICPFUNC registers >> with a has_pfunc >> platform data flag and enable this mode for platforms which supports >> DT (da850 and >> Keystone 2 are two SoCs which support DT now and they also support >> ICPFUNC registers). >> >> I'll add proper comment here. > > Just thinking: What happens if you try to use the ICPFUNC registers on > platforms that don't support it? If the answer is "nothing bad", then > you might as well assume that if the platform doesn't specify its own > GPIOs, you can always try using the ICPFUNC registers to shake the I2C > bus. Better to try and fail than to never try at all... > I think the right answer is !"nothing bad". My intention was to enable this feature by default, because current DT-compatible SoCs support it and the possibility that older SoCs will migrate to DT is low. But now I think that the right way will be to add proper compatible strings and use them to detect if ICPFUNC registers are supported or not. [...] regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
On Mon, Nov 24, 2014 at 11:07 AM, Christian Borntraeger wrote: > > Looks really nice, but does not work with ACCESS_ONCE is on the left-hand > side: Oh, I forgot about that. And that was indeed why I had done that whole helper macro originally, with ACCESS_ONCE() itself just being the dereference of the pointer. Duh. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/41] linux: towards virtio-1 guest support
On Mon, Nov 24, 2014 at 07:48:31PM +0100, Cornelia Huck wrote: > On Mon, 24 Nov 2014 13:52:32 +0200 > "Michael S. Tsirkin" wrote: > > > Based on patches by Cornelia Rusty and others, but > > with an API that should allow better static checking of code, > > and slightly more concervative changes in vring,net and blk. > > > > Based on patches by Cornelia and others, but > > with an API that should allow better static checking of code, > > slightly more concervative changes in vring and drivers, > > and compatibility for existing drivers so that > > this series be applied before all drivers are converted. > > > > virtio net,blk and scsi drivers have been converted. > > They now pass sparse without warnings. > > > > net and blk patches have been tested on s390. > > vring_transport_features() seems to knock off the version 1 bit (I > wonder why I did not see that before, maybe VIRTIO_TRANSPORT_F_END had > not been increased before?). If I add VIRTIO_F_VERSION_1 in this > function, virtio-net and virtio-blk seem to work fine with version 1 on > virtio-ccw (tested with my old virtio-1 qemu branch). What if we just move VIRTIO_TRANSPORT_F_END back for now? Does patch below fix it for you? > I'll try to do a bit of reviewing tomorrow. BTW could you post your latest qemu bits please? diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h index a6d0cde..0071de9 100644 --- a/include/uapi/linux/virtio_config.h +++ b/include/uapi/linux/virtio_config.h @@ -47,7 +47,7 @@ * transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 33 +#define VIRTIO_TRANSPORT_F_END 32 /* Do we get callbacks when the ring is completely used, even if we've * suppressed them? */ -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote: > On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: > > On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov > > wrote: > > > In a multimaster environment, after IP software reset, BB-bit value > > > doesn't > > > correspond to the current bus state. It may happen what BB-bit will be 0, > > > while the bus is busy due to another I2C master activity. > > > > > > Any transfer started when BB=0 and bus is busy wouldn't be completed by IP > > > and results in controller timeout. More over, in some cases IP could > > > interrupt another master's transfer and corrupt data on wire. > > > > > > The commit implement method allowing to prevent IP from entering into > > > "controller timeout" state and from "data corruption" state. > > > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > > > Tested on Beagleboard XM C. > > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > > > Signed-off-by: Alexander Kochetkov > > > Tested-by: Felipe Balbi > > > Reviewed-by: Felipe Balbi > > > > This patch recently hit linux-next (as commit 903c3859f77f) and boot > > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > > was bisected down to this commit. > > > > Kevin > > > > [1] http://status.armcloud.us/boot/?next-20141124 > > btw, based on Kevin's boot test, only OMAP3530 is failing. OK, giving Alexander some time for a fix. If it can't be found, I'll revert this patch. Thanks! signature.asc Description: Digital signature
Re: [PATCH v2] ASoC: rockchip: i2s: Fix Kconfig for I2S device driver
On Fri, Nov 21, 2014 at 08:50:46PM +0100, Andreas Ruprecht wrote: > Currently, CONFIG_SND_SOC_ROCKCHIP_I2S could also be selected > without having CONFIG_SND_SOC_ROCKCHIP enabled. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] mm, gfp: escalatedly define GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE
On Tue, Nov 25, 2014 at 12:43:47AM +0800, Jianyu Zhan wrote: > GFP_USER, GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE are escalatedly > confined defined, also implied by their names: > > GFP_USER = GFP_USER > GFP_USER + __GFP_HIGHMEM = GFP_HIGHUSER > GFP_USER + __GFP_HIGHMEM + __GFP_MOVABLE = GFP_HIGHUSER_MOVABLE Looks reasonable. Acked-by: Kirill A. Shutemov But I would prefer to have GPF_HIGHUSER movable by default and GFP_HIGHUSER_UNMOVABLE to opt out. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v3] SPI: spi-pxa2xx: Add helpers for regiseters' accessing
On Wed, Oct 08, 2014 at 08:50:22AM -0700, Weike Chen wrote: > There are several registers for SPI, and the registers of 'SSCR0' and 'SSCR1' > are accessed frequently. This path is to introduce helper functions to > simplify the accessing of 'SSCR0' and 'SSCR1'. Applied both, thanks. signature.asc Description: Digital signature
[PATCH] crypto: include crypto- module prefix in template
This adds the module loading prefix "crypto-" to the template lookup
as well.
For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":
net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause
Signed-off-by: Kees Cook
---
crypto/algapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index e8d3a7dca8c4..71a8143e23b1 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -509,8 +509,8 @@ static struct crypto_template
*__crypto_lookup_template(const char *name)
struct crypto_template *crypto_lookup_template(const char *name)
{
- return try_then_request_module(__crypto_lookup_template(name), "%s",
- name);
+ return try_then_request_module(__crypto_lookup_template(name),
+ "crypto-%s", name);
}
EXPORT_SYMBOL_GPL(crypto_lookup_template);
--
1.9.1
--
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 1/2] [drivers] staging/lustre: fix sparse warnings
This patch fixes the following sparse warnings:
lib-lnet.h:787:47: warning: incorrect type in initializer (different address
spaces)
lib-lnet.h:787:47:expected void [noderef] *iov_base
lib-lnet.h:787:47:got void *dest
Signed-off-by: Zahari Doychev
---
drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 7e89b3b..ec70f40 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -784,7 +784,8 @@ lnet_copy_iov2flat(int dlen, void *dest, unsigned int
doffset,
unsigned int nsiov, struct iovec *siov, unsigned int soffset,
unsigned int nob)
{
- struct iovec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
+ struct iovec diov = {/*.iov_base = */ (void __user *)dest,
+/*.iov_len = */ dlen};
lnet_copy_iov2iov(1, , doffset,
nsiov, siov, soffset, nob);
@@ -795,7 +796,8 @@ lnet_copy_kiov2flat(int dlen, void *dest, unsigned int
doffset,
unsigned int nsiov, lnet_kiov_t *skiov,
unsigned int soffset, unsigned int nob)
{
- struct iovec diov = {/* .iov_base = */ dest, /* .iov_len = */ dlen};
+ struct iovec diov = {/* .iov_base = */ (void __user *)dest,
+/* .iov_len = */ dlen};
lnet_copy_kiov2iov(1, , doffset,
nsiov, skiov, soffset, nob);
@@ -803,9 +805,10 @@ lnet_copy_kiov2flat(int dlen, void *dest, unsigned int
doffset,
static inline void
lnet_copy_flat2iov(unsigned int ndiov, struct iovec *diov, unsigned int
doffset,
- int slen, void *src, unsigned int soffset, unsigned int nob)
+ int slen, void *src, unsigned int soffset, unsigned int nob)
{
- struct iovec siov = {/*.iov_base = */ src, /*.iov_len = */slen};
+ struct iovec siov = {/*.iov_base = */ (void __user *)src,
+/*.iov_len = */ slen};
lnet_copy_iov2iov(ndiov, diov, doffset,
1, , soffset, nob);
@@ -816,7 +819,8 @@ lnet_copy_flat2kiov(unsigned int ndiov, lnet_kiov_t *dkiov,
unsigned int doffset, int slen, void *src,
unsigned int soffset, unsigned int nob)
{
- struct iovec siov = {/* .iov_base = */ src, /* .iov_len = */ slen};
+ struct iovec siov = {/* .iov_base = */ (void __user *)src,
+/* .iov_len = */ slen};
lnet_copy_iov2kiov(ndiov, dkiov, doffset,
1, , soffset, nob);
--
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 v3 2/4] spi: meson: Add device tree bindings documentation for SPIFC
On Sat, Nov 22, 2014 at 04:21:40PM +0100, Beniamino Galvani wrote: > This adds documentation of device tree bindings for the Amlogic Meson > SPIFC (SPI Flash Controller). Applied, thanks. signature.asc Description: Digital signature
[PATCH 0/2] fix some sparse warnings in lustre
The two patches fix several sparse warning in the lustre module. Zahari Doychev (2): [drivers] staging/lustre: fix sparse warnings [drivers] staging/lustre: fix sparse warnings drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 14 +- drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 15 ++- 2 files changed, 19 insertions(+), 10 deletions(-) -- 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 v3 1/4] spi: core: Add spi_transfer_is_last() helper
On Sat, Nov 22, 2014 at 04:21:39PM +0100, Beniamino Galvani wrote: > This adds the function spi_transfer_is_last() which can be used by > drivers to know whether a given transfer is the last one in the > current message. Applied, thanks. signature.asc Description: Digital signature
[PATCH] net/smsc911x: Add minimal runtime PM support
Add minimal runtime PM support (enable on probe, disable on remove), to ensure proper operation with a parent device that uses runtime PM. This is needed on systems where the external bus controller module of the SoC is contained in a PM domain and/or has a gateable functional clock. In such cases, before accessing any device connected to the external bus, the PM domain must be powered up, and/or the functional clock must be enabled, which is typically handled through runtime PM by the bus controller driver. An example of this is the kzm9g development board, where an smsc9220 Ethernet controller is connected to the Bus State Controller (BSC) of a Renesas sh73a0 SoC. Signed-off-by: Geert Uytterhoeven --- drivers/net/ethernet/smsc/smsc911x.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c index 77ed74561e5fe815..f9c87624a0afb08b 100644 --- a/drivers/net/ethernet/smsc/smsc911x.c +++ b/drivers/net/ethernet/smsc/smsc911x.c @@ -59,6 +59,8 @@ #include #include #include +#include + #include "smsc911x.h" #define SMSC_CHIPNAME "smsc911x" @@ -2338,6 +2340,9 @@ static int smsc911x_drv_remove(struct platform_device *pdev) free_netdev(dev); + pm_runtime_put(>dev); + pm_runtime_disable(>dev); + return 0; } @@ -2491,6 +2496,9 @@ static int smsc911x_drv_probe(struct platform_device *pdev) if (pdata->config.shift) pdata->ops = _smsc911x_ops; + pm_runtime_enable(>dev); + pm_runtime_get_sync(>dev); + retval = smsc911x_init(dev); if (retval < 0) goto out_disable_resources; @@ -2572,6 +2580,8 @@ out_unregister_netdev_5: out_free_irq: free_irq(dev->irq, dev); out_disable_resources: + pm_runtime_put(>dev); + pm_runtime_disable(>dev); (void)smsc911x_disable_resources(pdev); out_enable_resources_fail: smsc911x_free_resources(pdev); -- 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: [PATCH v3 3/4] spi: meson: Add support for Amlogic Meson SPIFC
On Sat, Nov 22, 2014 at 04:21:41PM +0100, Beniamino Galvani wrote: > This is a driver for the Amlogic Meson SPIFC (SPI flash controller), > which is one of the two SPI controllers available on the SoC. It > doesn't support DMA and has a 64-byte unified transmit/receive buffer. Applied, thanks. signature.asc Description: Digital signature
[PATCH 2/2] [drivers] staging/lustre: fix sparse warnings
This patch fixes the following warnings:
socklnd_cb.c:134:39: warning: incorrect type in assignment (different address
spaces)
socklnd_cb.c:134:39:expected void [noderef] *iov_base
socklnd_cb.c:134:39:got void *
Signed-off-by: Zahari Doychev
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index d29f5f1..971b877 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -131,7 +131,8 @@ ksocknal_send_iov (ksock_conn_t *conn, ksock_tx_t *tx)
LASSERT (tx->tx_niov > 0);
if (nob < (int) iov->iov_len) {
- iov->iov_base = (void *)((char *)iov->iov_base + nob);
+ iov->iov_base =
+ (void __user *)((char *)iov->iov_base + nob);
iov->iov_len -= nob;
return rc;
}
@@ -1052,7 +1053,8 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
case KSOCK_PROTO_V3:
conn->ksnc_rx_state = SOCKNAL_RX_KSM_HEADER;
conn->ksnc_rx_iov = (struct iovec
*)>ksnc_rx_iov_space;
- conn->ksnc_rx_iov[0].iov_base = (char *)>ksnc_msg;
+ conn->ksnc_rx_iov[0].iov_base =
+ (void __user *)>ksnc_msg;
conn->ksnc_rx_nob_wanted = offsetof(ksock_msg_t, ksm_u);
conn->ksnc_rx_nob_left = offsetof(ksock_msg_t, ksm_u);
@@ -1066,7 +1068,8 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_nob_left = sizeof(lnet_hdr_t);
conn->ksnc_rx_iov = (struct iovec
*)>ksnc_rx_iov_space;
- conn->ksnc_rx_iov[0].iov_base = (char
*)>ksnc_msg.ksm_u.lnetmsg;
+ conn->ksnc_rx_iov[0].iov_base =
+ (void __user *)>ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len = sizeof (lnet_hdr_t);
break;
@@ -1093,7 +1096,8 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
do {
nob = MIN (nob_to_skip, sizeof (ksocknal_slop_buffer));
- conn->ksnc_rx_iov[niov].iov_base = ksocknal_slop_buffer;
+ conn->ksnc_rx_iov[niov].iov_base =
+ (void __user *)ksocknal_slop_buffer;
conn->ksnc_rx_iov[niov].iov_len = nob;
niov++;
skipped += nob;
@@ -1218,7 +1222,8 @@ ksocknal_process_receive (ksock_conn_t *conn)
conn->ksnc_rx_nob_left = sizeof(ksock_lnet_msg_t);
conn->ksnc_rx_iov = (struct iovec *)>ksnc_rx_iov_space;
- conn->ksnc_rx_iov[0].iov_base = (char
*)>ksnc_msg.ksm_u.lnetmsg;
+ conn->ksnc_rx_iov[0].iov_base =
+ (void __user *)>ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len = sizeof(ksock_lnet_msg_t);
conn->ksnc_rx_niov = 1;
--
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: [PATCHv10 2/5] x86: Hook up execveat system call.
On Mon, 24 Nov 2014, Dan Carpenter wrote: > On Mon, Nov 24, 2014 at 11:53:56AM +, David Drysdale wrote: > > Hook up x86-64, i386 and x32 ABIs. > > > > Signed-off-by: David Drysdale > > This one has been breaking my linux-next build for the past week. I'm > not sure what's going on. I build with a script: > > make allmodconfig > > cat << EOF >> .config > CONFIG_DYNAMIC_DEBUG=n > CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=n > CONFIG_DYNAMIC_DEBUG=y > EOF > > make oldconfig > > Here are the errors: > > CHK include/generated/compile.h > CHECK arch/x86/ia32/audit.c > CC arch/x86/ia32/audit.o > arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’: > arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in > this function) > arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported only > once for each function it appears in > make[2]: *** [arch/x86/ia32/audit.o] Error 1 > make[2]: Target `__build' not remade because of errors. > make[1]: *** [arch/x86/ia32] Error 2 > CHECK arch/x86/kernel/audit_64.c > CHK kernel/config_data.h > CC arch/x86/kernel/audit_64.o > arch/x86/kernel/audit_64.c: In function ‘audit_classify_syscall’: > arch/x86/kernel/audit_64.c:53:7: error: ‘__NR_execveat’ undeclared (first use > in this function) > arch/x86/kernel/audit_64.c:53:7: note: each undeclared identifier is reported > only once for each function it appears in > make[2]: *** [arch/x86/kernel/audit_64.o] Error 1 > make[2]: Target `__build' not remade because of errors. > make[1]: *** [arch/x86/kernel] Error 2 > make[1]: Target `__build' not remade because of errors. I don't know what you're doing. Tried the above and it rebuilds the relevant unistd*.h files and compiles happily. Thanks, tglx
Re: v3.18-rc1: n900 battery discharged down to 2.97V
On Monday 24 November 2014 19:31:30 Pavel Machek wrote: > Hi! > > I left the machine on usb-networking for extended period of > time. Unfortunately, Xfce screensaver kept screen busy, and > kernel failed to kill the machine. > > At the end, hardware protections worked (I guess), but result > is battery discharged down to 2.97V. > > Best regards, > Pavel So you need some program which will monitor battery status and when battery status is empty it should turn of device. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH/RFC 6/7] arm64: Replace ACCESS_ONCE for spinlock code with barriers
Am 24.11.2014 um 14:03 schrieb Christian Borntraeger:
> ACCESS_ONCE does not work reliably on non-scalar types. For
> example gcc 4.6 and 4.7 might remove the volatile tag for such
> accesses during the SRA (scalar replacement of aggregates) step
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
>
> Change the spinlock code to access the lock with a barrier.
>
> Signed-off-by: Christian Borntraeger
> ---
> arch/arm64/include/asm/spinlock.h | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/spinlock.h
> b/arch/arm64/include/asm/spinlock.h
> index c45b7b1..f72dc64 100644
> --- a/arch/arm64/include/asm/spinlock.h
> +++ b/arch/arm64/include/asm/spinlock.h
> @@ -99,12 +99,15 @@ static inline int
> arch_spin_value_unlocked(arch_spinlock_t lock)
>
> static inline int arch_spin_is_locked(arch_spinlock_t *lock)
> {
> - return !arch_spin_value_unlocked(ACCESS_ONCE(*lock));
> + arch_spinlock_t lockval = *lock;
> + barrier();
> + return !arch_spin_value_unlocked(lockval);
> }
>
> static inline int arch_spin_is_contended(arch_spinlock_t *lock)
> {
> - arch_spinlock_t lockval = ACCESS_ONCE(*lock);
> + arch_spinlock_t lockval = *lock;
> + barrier();
> return (lockval.next - lockval.owner) > 1;
> }
> #define arch_spin_is_contended arch_spin_is_contended
>
FWIW,
we could also make this with ACCESS_ONCE, but this requires to change the
definition of arch_spinlock_t for arm64 to be a union. I am a bit reluctant to
do these changes without being able to test. Let me know if this is preferred
and if somebody else can test.
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/41] linux: towards virtio-1 guest support
On Mon, 24 Nov 2014 13:52:32 +0200 "Michael S. Tsirkin" wrote: > Based on patches by Cornelia Rusty and others, but > with an API that should allow better static checking of code, > and slightly more concervative changes in vring,net and blk. > > Based on patches by Cornelia and others, but > with an API that should allow better static checking of code, > slightly more concervative changes in vring and drivers, > and compatibility for existing drivers so that > this series be applied before all drivers are converted. > > virtio net,blk and scsi drivers have been converted. > They now pass sparse without warnings. > > net and blk patches have been tested on s390. vring_transport_features() seems to knock off the version 1 bit (I wonder why I did not see that before, maybe VIRTIO_TRANSPORT_F_END had not been increased before?). If I add VIRTIO_F_VERSION_1 in this function, virtio-net and virtio-blk seem to work fine with version 1 on virtio-ccw (tested with my old virtio-1 qemu branch). I'll try to do a bit of reviewing tomorrow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] i2c: omap: implement workaround for handling invalid BB-bit values
Hi,
On Fri, Nov 21, 2014 at 01:28:43AM +0400, Alexander Kochetkov wrote:
> In a multimaster environment, after IP software reset, BB-bit value doesn't
> correspond to the current bus state. It may happen what BB-bit will be 0,
> while the bus is busy due to another I2C master activity.
>
> Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
> and results in controller timeout. More over, in some cases IP could
> interrupt another master's transfer and corrupt data on wire.
>
> The commit implement method allowing to prevent IP from entering into
> "controller timeout" state and from "data corruption" state.
>
> The one drawback is the need to wait for 10ms before the first transfer.
>
> Tested on Beagleboard XM C.
>
> Signed-off-by: Alexander Kochetkov
we have a report from Kevin Hilman that this commit breaks OMAP3530, see
[1]
[1]
http://storage.armcloud.us/kernel-ci/next/next-20141124/arm-omap2plus_defconfig/boot-omap3-overo-tobi.log
> ---
> drivers/i2c/busses/i2c-omap.c | 103
> +
> 1 file changed, 103 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a021733..3ffb9c0 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -58,6 +58,9 @@
> /* timeout for pm runtime autosuspend */
> #define OMAP_I2C_PM_TIMEOUT 1000/* ms */
>
> +/* timeout for making decision on bus free status */
> +#define OMAP_I2C_BUS_FREE_TIMEOUT (msecs_to_jiffies(10))
> +
> /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
> enum {
> OMAP_I2C_REV_REG = 0,
> @@ -210,6 +213,9 @@ struct omap_i2c_dev {
>*/
> u32 rev;
> unsignedb_hw:1; /* bad h/w fixes */
> + unsignedbb_valid:1; /* true when BB-bit reflects
> + * the I2C bus state
> + */
> unsignedreceiver:1; /* true when we're in receiver
> mode */
> u16 iestate;/* Saved interrupt register */
> u16 pscstate;
> @@ -336,7 +342,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
> /* SYSC register is cleared by the reset; rewrite it */
> omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
>
> + /* Schedule I2C-bus monitoring on the next transfer */
> + dev->bb_valid = 0;
> }
> +
> return 0;
> }
>
> @@ -449,6 +458,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> dev->scllstate = scll;
> dev->sclhstate = sclh;
>
> + if (dev->rev < OMAP_I2C_OMAP1_REV_2) {
> + /* Not implemented */
> + dev->bb_valid = 1;
> + }
> +
> __omap_i2c_init(dev);
>
> return 0;
> @@ -473,6 +487,91 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
> return 0;
> }
>
> +/*
> + * Wait while BB-bit doesn't reflect the I2C bus state
> + *
> + * In a multimaster environment, after IP software reset, BB-bit value
> doesn't
> + * correspond to the current bus state. It may happen what BB-bit will be 0,
> + * while the bus is busy due to another I2C master activity.
> + * Here are BB-bit values after reset:
> + * SDA SCL BB NOTES
> + * 0 00 1, 2
> + * 1 00 1, 2
> + * 0 11
> + * 1 10 3
> + * Later, if IP detect SDA=0 and SCL=1 (ACK) or SDA 1->0 while SCL=1 (START)
> + * combinations on the bus, it set BB-bit to 1.
> + * If IP detect SDA 0->1 while SCL=1 (STOP) combination on the bus,
> + * it set BB-bit to 0 and BF to 1.
> + * BB and BF bits correctly tracks the bus state while IP is suspended
> + * BB bit became valid on the next FCLK clock after CON_EN bit set
> + *
> + * NOTES:
> + * 1. Any transfer started when BB=0 and bus is busy wouldn't be
> + *completed by IP and results in controller timeout.
> + * 2. Any transfer started when BB=0 and SCL=0 results in IP
> + *starting to drive SDA low. In that case IP corrupt data
> + *on the bus.
> + * 3. Any transfer started in the middle of another master's transfer
> + *results in unpredictable results and data corruption
> + */
> +static int omap_i2c_wait_for_bb_valid(struct omap_i2c_dev *dev)
> +{
> + unsigned long bus_free_timeout = 0;
> + unsigned long timeout;
> + int bus_free = 0;
> + u16 stat, systest;
> +
> + if (dev->bb_valid)
>
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: > On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov > wrote: > > In a multimaster environment, after IP software reset, BB-bit value doesn't > > correspond to the current bus state. It may happen what BB-bit will be 0, > > while the bus is busy due to another I2C master activity. > > > > Any transfer started when BB=0 and bus is busy wouldn't be completed by IP > > and results in controller timeout. More over, in some cases IP could > > interrupt another master's transfer and corrupt data on wire. > > > > The commit implement method allowing to prevent IP from entering into > > "controller timeout" state and from "data corruption" state. > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > Tested on Beagleboard XM C. > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > Signed-off-by: Alexander Kochetkov > > Tested-by: Felipe Balbi > > Reviewed-by: Felipe Balbi > > This patch recently hit linux-next (as commit 903c3859f77f) and boot > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > was bisected down to this commit. > > Kevin > > [1] http://status.armcloud.us/boot/?next-20141124 btw, based on Kevin's boot test, only OMAP3530 is failing. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov wrote: > In a multimaster environment, after IP software reset, BB-bit value doesn't > correspond to the current bus state. It may happen what BB-bit will be 0, > while the bus is busy due to another I2C master activity. > > Any transfer started when BB=0 and bus is busy wouldn't be completed by IP > and results in controller timeout. More over, in some cases IP could > interrupt another master's transfer and corrupt data on wire. > > The commit implement method allowing to prevent IP from entering into > "controller timeout" state and from "data corruption" state. > > The one drawback is the need to wait for 10ms before the first transfer. > > Tested on Beagleboard XM C. > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > Signed-off-by: Alexander Kochetkov > Tested-by: Felipe Balbi > Reviewed-by: Felipe Balbi This patch recently hit linux-next (as commit 903c3859f77f) and boot breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards was bisected down to this commit. Kevin [1] http://status.armcloud.us/boot/?next-20141124 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/41] virtio: memory access APIs
On Mon, Nov 24, 2014 at 01:58:43PM +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 24, 2014 at 1:15 PM, Michael S. Tsirkin wrote:
> > On Mon, Nov 24, 2014 at 01:03:24PM +0100, Geert Uytterhoeven wrote:
> >> On Mon, Nov 24, 2014 at 12:52 PM, Michael S. Tsirkin
> >> wrote:
> >> > virtio 1.0 makes all memory structures LE, so
> >> > we need APIs to conditionally do a byteswap on BE
> >> > architectures.
> >> >
> >> > To make it easier to check code statically,
> >> > add virtio specific types for multi-byte integers
> >> > in memory.
> >> >
> >> > Add low level wrappers that do a byteswap conditionally, these will be
> >> > useful e.g. for vhost. Add high level wrappers that
> >> > query device endian-ness and act accordingly.
> >>
> >> > diff --git a/include/linux/virtio_byteorder.h
> >> > b/include/linux/virtio_byteorder.h
> >> > new file mode 100644
> >> > index 000..824ed0b
> >> > --- /dev/null
> >> > +++ b/include/linux/virtio_byteorder.h
> >>
> >> > +static inline u16 __virtio16_to_cpu(bool little_endian, __virtio16 val)
> >> > +{
> >> > + if (little_endian)
> >> > + return le16_to_cpu((__force __le16)val);
> >> > + else
> >> > + return (__force u16)val;
> >> > +}
> >>
> >> What's wrong with just using le16-to_cpu() ...
> >
> > le16-to_cpu() is simply wrong: virtio needs to be
> > LE or native endian, depending on whether it's running
> > in 0.9 or 1.0 mode.
>
> IC, that was not clear from the description for this patch.
> I thought it was dependent on BE architectures.
>
> Nevertheless, any chance you can get rid of the "conditional"?
I don't see how - this is fundamental to any virtio device
that wants to support both 0.9 and 1.0 from the same
codebase.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4
On Fri, Nov 21, 2014 at 03:23:13PM -0500, Josh Boyer wrote: > On Fri, Nov 21, 2014 at 3:16 PM, Andy Lutomirski wrote: > > On Fri, Nov 21, 2014 at 12:14 PM, Josh Boyer > > wrote: > >> On Fri, Nov 21, 2014 at 2:52 PM, Andy Lutomirski > >> wrote: > >>> On Fri, Nov 21, 2014 at 11:46 AM, Linus Torvalds > >>> wrote: > On Fri, Nov 21, 2014 at 11:34 AM, Linus Torvalds > wrote: > > > > So I kind of agree, but it wouldn't be my primary worry. My primary > > worry is actually paravirt doing something insane. > > Btw, on that tangent, does anybody actually care about paravirt any more? > > >>> > >>> Amazon, for better or for worse. And distros: Oracle and Novell. > >>> > I'd love to start moving away from it. It makes a lot of the low-level > code completely impossible to follow due to the random indirection > through "native" vs "paravirt op table". Not just the page table > handling, it's all over. > > Anybody who seriously does virtualization uses hw virtualization that > is much better than it used to be. And the non-serious users aren't > that performance-sensitive by definition. I would point out that the PV paravirt spinlock gives an huge boost for virtualization guests (this is for both KVM and Xen). > > I note that the Fedora kernel config seems to include paravirt by > default, so you get a lot of the crazy overheads.. Not that much. We ran benchmarks and it was in i-cache overhead - and the numbers came out to be sub-1% percent. > >>> > >>> I think that there is a move toward deprecating Xen PV in favor of > >>> PVH, but we're not there yet. > >> > >> A move where? The Xen stuff in Fedora is ... not paid attention to > >> very much. If there's something we should be looking at turning off > >> (or on), we're happy to take suggestions. > > > > A move in the Xen project. As I understand it, Xen wants to deprecate > > PV in favor of PVH, but PVH is still experimental. > > OK. > > > I think that dropping PARAVIRT in Fedora might be a bad idea for > > several more releases, since that's likely to break the EC2 images. > > Yes, that's essentially the only reason we haven't looked at disabling > Xen completely for a while now, so . Heh. Didn't know you could play on a trombone! As I had mentioned in the past - if there are Xen related bugs on Fedora please CC me on them. Or perhaps CC xen-de...@lists.xenproject.org if that is possible. And as Andy has mentioned - we are moving towards using PVH as a way to not use the PV MMU ops. But that is still off (). > > josh > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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 3.18-rc3 v8 1/4] irqchip: gic: Make gic_raise_softirq() FIQ-safe
On Mon, 24 Nov 2014, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Daniel Thompson wrote:
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index 38493ff28fa5..0db62a6f1ee3 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -73,6 +73,13 @@ struct gic_chip_data {
> > static DEFINE_RAW_SPINLOCK(irq_controller_lock);
> >
> > /*
> > + * This lock may be locked for reading by FIQ handlers. Thus although
> > + * read locking may be used liberally, write locking must only take
> > + * place only when local FIQ handling is disabled.
> > + */
> > +static DEFINE_RWLOCK(fiq_safe_cpu_map_lock);
> > +
> > +/*
> > * The GIC mapping of CPU interfaces does not necessarily match
> > * the logical CPU numbering. Let's use a mapping as returned
> > * by the GIC itself.
> > @@ -624,7 +631,7 @@ static void gic_raise_softirq(const struct cpumask
> > *mask, unsigned int irq)
> > int cpu;
> > unsigned long flags, map = 0;
> >
> > - raw_spin_lock_irqsave(_controller_lock, flags);
> > + read_lock_irqsave(_safe_cpu_map_lock, flags);
>
> Just for the record:
>
> You might have noticed that you replace a raw lock with a non raw
> one. That's not an issue on mainline, but that pretty much renders
> that code broken for RT.
>
> Surely nothing I worry too much about given the current state of RT.
And having a second thought here. Looking at the protection scope
independent of the spin vs. rw lock
gic_raise_softirq()
lock();
/* Does not need any protection */
for_each_cpu(cpu, mask)
map |= gic_cpu_map[cpu];
/*
* Can be outside the lock region as well as it makes sure
* that previous writes (usually the IPI data) are visible
* before the write to the SOFTINT register.
*/
dmb(ishst);
/* Why needs this protection? */
write(map, gic_data_dist_base(_data[0]) + GIC_DIST_SOFTINT));
unlock();
gic_migrate_target()
lock();
/* Migrate all peripheral interrupts */
unlock();
So what's the point of that protection?
gic_raise_softirq() is used to send IPIs, which are PPIs on the target
CPUs so they are not affected from the migration of the peripheral
interrupts at all.
The write to the SOFTINT register in gic_migrate_target() is not
inside the lock region. So what's serialized by the lock in
gic_raise_softirq() at all?
Either I'm missing something really important here or this locking
exercise in gic_raise_softirq() and therefor the rwlock conversion is
completely pointless.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 3/3] tuntap: Increase the number of queues in tun.
Adding Michael to CC.
>
> Networking under kvm works best if we allocate a per-vCPU RX and TX
> queue in a virtual NIC. This requires a per-vCPU queue on the host side.
>
> It is now safe to increase the maximum number of queues.
> Preceding patches:
> net: allow large number of rx queues
> tuntap: Reduce the size of tun_struct by using flex array
>
> made sure this won't cause failures due to high order memory
> allocations. Increase it to 256: this is the max number of vCPUs
> KVM supports.
>
> Signed-off-by: Pankaj Gupta
> Reviewed-by: David Gibson
> ---
> drivers/net/tun.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index e3fa65a..a19dc5f8 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -113,10 +113,11 @@ struct tap_filter {
> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
> };
>
> -/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues allocated
> for
> - * the netdevice to be fit in one page. So we can make sure the success of
> - * memory allocation. TODO: increase the limit. */
> -#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
> +/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
> + * to max number of vCPUS in guest. Also, we are making sure here
> + * queue memory allocation do not fail.
> + */
> +#define MAX_TAP_QUEUES 256
> #define MAX_TAP_FLOWS 4096
>
> #define TUN_FLOW_EXPIRE (3 * HZ)
> --
> 1.8.3.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cgroups: Documentation: fix wrong cgroupfs paths
On Tue, Nov 25, 2014 at 2:45 AM, Jonathan Corbet wrote: > On Tue, 25 Nov 2014 01:39:19 +0900 > SeongJae Park wrote: > >> 6) Attach that task to the new cgroup by writing its PID to the >> -/sys/fs/cgroup/cpuset/tasks file for that cgroup. >> +/sys/fs/cgroup/cpuset tasks file for that cgroup. > > That one looks like it was correct before the change...? What am I > missing here? It should represents /sys/fs/cgroup/cpuset/<*new cgroup name*>/tasks, not /sys/fs/cgroup/cpuset/tasks. If there are better suggestions or anything I am missing, please let me know. Thanks, SeongJae Park > > Thanks, > > jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-net 0/3] Increase the limit of tuntap queues
Sorry! forgot to add Michael, adding now. > Networking under KVM works best if we allocate a per-vCPU rx and tx > queue in a virtual NIC. This requires a per-vCPU queue on the host side. > Modern physical NICs have multiqueue support for large number of queues. > To scale vNIC to run multiple queues parallel to maximum number of vCPU's > we need to increase number of queues support in tuntap. > > Changes from v1 > PATCH 2: David Miller - sysctl changes to limit number of queues > not required for unprivileged users(dropped). > > Changes from RFC > PATCH 1: Sergei Shtylyov - Add an empty line after declarations. > PATCH 2: Jiri Pirko - Do not introduce new module paramaters. >Michael.S.Tsirkin- We can use sysctl for limiting max number > of queues. > > This series is to increase the limit of tuntap queues. Original work is being > done by 'jasow...@redhat.com'. I am taking this > 'https://lkml.org/lkml/2013/6/19/29' > patch series as a reference. As per discussion in the patch series: > > There were two reasons which prevented us from increasing number of tun > queues: > > - The netdev_queue array in netdevice were allocated through kmalloc, which > may > cause a high order memory allocation too when we have several queues. > E.g. sizeof(netdev_queue) is 320, which means a high order allocation would > happens when the device has more than 16 queues. > > - We store the hash buckets in tun_struct which results a very large size of > tun_struct, this high order memory allocation fail easily when the memory > is > fragmented. > > The patch 60877a32bce00041528576e6b8df5abe9251fa73 increases the number of tx > queues. Memory allocation fallback to vzalloc() when kmalloc() fails. > > This series tries to address following issues: > > - Increase the number of netdev_queue queues for rx similarly its done for tx > queues by falling back to vzalloc() when memory allocation with kmalloc() > fails. > > - Switches to use flex array to implement the flow caches to avoid higher > order > allocations. > > - Increase number of queues to 256, maximum number is equal to maximum number > of vCPUS allowed in a guest. > > I have done some testing to test any regression with sample program which > creates > tun/tap for single queue / multiqueue device. I have also done testing with > multiple > parallel Netperf sessions from guest to host for different combination of > queues > and CPU's. It seems to be working fine without much increase in cpu load with > the > increase in number of queues. > > For this test vhost threads are pinned to separate CPU's. Below are the > results: > Host kernel: 3.18.rc4, Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 4 CPUS > NIC : Ethernet controller: Intel Corporation 82579LM Gigabit Network > > 1] Before patch applied limit: Single Queue > Guest, smp=2, > 19:57:44 CPU%usr %nice%sys %iowait%irq %soft %steal > %guest %gnice %idle > 19:57:44 all2.900.003.680.980.130.610.00 > 4.640.00 87.06 > > 2] Patch applied, Tested with 2 queues, with vhost threads pinned to > different physical cpus > Guest, smp=2, queues =2 > 23:21:59 CPU%usr %nice%sys %iowait%irq %soft %steal > %guest %gnice %idle > 23:21:59 all1.800.001.571.490.180.230.00 > 1.410.00 93.32 > > 3] Tested with 4 queues, with vhost threads pinned to different physical cpus > --- > Guest, smp=4, queues =4 > 23:09:43 CPU%usr %nice%sys %iowait%irq %soft %steal > %guest %gnice %idle > 23:09:43 all1.890.001.631.350.190.230.00 > 1.330.00 93.37 > > Patches Summary: > net: allow large number of rx queues > tuntap: Reduce the size of tun_struct by using flex array > tuntap: Increase the number of queues in tun > > drivers/net/tun.c | 58 > +++--- > net/core/dev.c| 19 - > 2 files changed, 55 insertions(+), 22 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 03/12] x86_64: add KASan support
On 11/24/2014 01:02 PM, Andrey Ryabinin wrote:
> +static int kasan_die_handler(struct notifier_block *self,
> + unsigned long val,
> + void *data)
> +{
> + if (val == DIE_GPF) {
> + pr_emerg("CONFIG_KASAN_INLINE enabled\n");
> + pr_emerg("GPF could be caused by NULL-ptr deref or user memory
> access\n");
> + }
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block kasan_die_notifier = {
> + .notifier_call = kasan_die_handler,
> +};
This part fails to compile:
CC arch/x86/mm/kasan_init_64.o
arch/x86/mm/kasan_init_64.c: In function ‘kasan_die_handler’:
arch/x86/mm/kasan_init_64.c:72:13: error: ‘DIE_GPF’ undeclared (first use in
this function)
if (val == DIE_GPF) {
^
arch/x86/mm/kasan_init_64.c:72:13: note: each undeclared identifier is reported
only once for each function it appears in
arch/x86/mm/kasan_init_64.c: In function ‘kasan_init’:
arch/x86/mm/kasan_init_64.c:89:2: error: implicit declaration of function
‘register_die_notifier’ [-Werror=implicit-function-declaration]
register_die_notifier(_die_notifier);
^
cc1: some warnings being treated as errors
make[1]: *** [arch/x86/mm/kasan_init_64.o] Error 1
Simple fix:
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 70041fd..c8f7f3e 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -5,6 +5,7 @@
#include
#include
+#include
extern pgd_t early_level4_pgt[PTRS_PER_PGD];
extern struct range pfn_mapped[E820_X_MAX];
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.18-rc3 v8 1/4] irqchip: gic: Make gic_raise_softirq() FIQ-safe
On 24/11/14 18:20, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Daniel Thompson wrote:
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 38493ff28fa5..0db62a6f1ee3 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -73,6 +73,13 @@ struct gic_chip_data {
>> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> /*
>> + * This lock may be locked for reading by FIQ handlers. Thus although
>> + * read locking may be used liberally, write locking must only take
>> + * place only when local FIQ handling is disabled.
>> + */
>> +static DEFINE_RWLOCK(fiq_safe_cpu_map_lock);
>> +
>> +/*
>> * The GIC mapping of CPU interfaces does not necessarily match
>> * the logical CPU numbering. Let's use a mapping as returned
>> * by the GIC itself.
>> @@ -624,7 +631,7 @@ static void gic_raise_softirq(const struct cpumask
>> *mask, unsigned int irq)
>> int cpu;
>> unsigned long flags, map = 0;
>>
>> -raw_spin_lock_irqsave(_controller_lock, flags);
>> +read_lock_irqsave(_safe_cpu_map_lock, flags);
>
> Just for the record:
>
> You might have noticed that you replace a raw lock with a non raw
> one. That's not an issue on mainline, but that pretty much renders
> that code broken for RT.
Indeed. For that reason I've been pretty anxious to hear your views on
this one.
Older versions of this patch did retain the raw lock but the code ends
up looking a bit weird and resulted in negative comments during review:
if (in_nmi())
raw_spin_lock(_exclusive_cpu_map_lock);
else
raw_spin_lock_irqsave(_controller_lock, flags);
The above form relies for correctness on the fact the b.L switcher code
can take both locks and already runs with FIQ disabled.
> Surely nothing I worry too much about given the current state of RT.
Hobby or not, I don't want to make your work here any harder. I could go
back to the old form.
Alternatively I could provide a patch to go in -rt that converts the rw
locks to spin locks but that just sounds like a maintenance hassle for you.
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 2/3] tuntap: reduce the size of tun_struct by using flex array.
Sorry! forgot to cc Michael, doing now.
>
> This patch switches to flex array to implement the flow caches, it brings
> several advantages:
>
> - Reduce the size of the tun_struct structure, which allows us to increase
> the
> upper limit of queues in future.
> - Avoid higher order memory allocation. It will be useful when switching to
> pure hashing in flow cache which may demand a larger size array in future.
>
> After this patch, the size of tun_struct on x86_64 reduced from 8512 to
> 328
>
> Signed-off-by: Jason Wang
> Signed-off-by: Pankaj Gupta
> Reviewed-by: David Gibson
> ---
> drivers/net/tun.c | 49 +
> 1 file changed, 37 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index e3fa65a..bd07a6d 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -65,6 +65,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -188,7 +189,7 @@ struct tun_struct {
> int debug;
> #endif
> spinlock_t lock;
> - struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
> + struct flex_array *flows;
> struct timer_list flow_gc_timer;
> unsigned long ageing_time;
> unsigned int numdisabled;
> @@ -249,10 +250,11 @@ static void tun_flow_flush(struct tun_struct *tun)
>
> spin_lock_bh(>lock);
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
> + struct hlist_head *h = flex_array_get(tun->flows, i);
> struct tun_flow_entry *e;
> struct hlist_node *n;
>
> - hlist_for_each_entry_safe(e, n, >flows[i], hash_link)
> + hlist_for_each_entry_safe(e, n, h, hash_link)
> tun_flow_delete(tun, e);
> }
> spin_unlock_bh(>lock);
> @@ -264,10 +266,11 @@ static void tun_flow_delete_by_queue(struct tun_struct
> *tun, u16 queue_index)
>
> spin_lock_bh(>lock);
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
> + struct hlist_head *h = flex_array_get(tun->flows, i);
> struct tun_flow_entry *e;
> struct hlist_node *n;
>
> - hlist_for_each_entry_safe(e, n, >flows[i], hash_link) {
> + hlist_for_each_entry_safe(e, n, h, hash_link) {
> if (e->queue_index == queue_index)
> tun_flow_delete(tun, e);
> }
> @@ -287,10 +290,11 @@ static void tun_flow_cleanup(unsigned long data)
>
> spin_lock_bh(>lock);
> for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++) {
> + struct hlist_head *h = flex_array_get(tun->flows, i);
> struct tun_flow_entry *e;
> struct hlist_node *n;
>
> - hlist_for_each_entry_safe(e, n, >flows[i], hash_link) {
> + hlist_for_each_entry_safe(e, n, h, hash_link) {
> unsigned long this_timer;
> count++;
> this_timer = e->updated + delay;
> @@ -317,7 +321,7 @@ static void tun_flow_update(struct tun_struct *tun, u32
> rxhash,
> if (!rxhash)
> return;
> else
> - head = >flows[tun_hashfn(rxhash)];
> + head = flex_array_get(tun->flows, tun_hashfn(rxhash));
>
> rcu_read_lock();
>
> @@ -380,7 +384,8 @@ static u16 tun_select_queue(struct net_device *dev,
> struct sk_buff *skb,
>
> txq = skb_get_hash(skb);
> if (txq) {
> - e = tun_flow_find(>flows[tun_hashfn(txq)], txq);
> + e = tun_flow_find(flex_array_get(tun->flows,
> + tun_hashfn(txq)), txq);
> if (e) {
> tun_flow_save_rps_rxhash(e, txq);
> txq = e->queue_index;
> @@ -760,8 +765,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb,
> struct net_device *dev)
> rxhash = skb_get_hash(skb);
> if (rxhash) {
> struct tun_flow_entry *e;
> - e = tun_flow_find(>flows[tun_hashfn(rxhash)],
> - rxhash);
> + e = tun_flow_find(flex_array_get(tun->flows,
> + tun_hashfn(rxhash)),
> rxhash);
> if (e)
> tun_flow_save_rps_rxhash(e, rxhash);
> }
> @@ -896,23 +901,40 @@ static const struct net_device_ops tap_netdev_ops = {
> #endif
> };
>
> -static void tun_flow_init(struct tun_struct *tun)
> +static int tun_flow_init(struct tun_struct *tun)
> {
> - int i;
> + struct flex_array *buckets;
> + int i, err;
> +
> + buckets = flex_array_alloc(sizeof(struct hlist_head),
> +TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
> + if (!buckets)
> + return -ENOMEM;
> +
> + err = flex_array_prealloc(buckets, 0, TUN_NUM_FLOW_ENTRIES, GFP_KERNEL);
> + if (err) {
> +
Re: frequent lockups in 3.18rc4
On Mon, Nov 24, 2014 at 1:48 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Nov 21, 2014 at 03:23:13PM -0500, Josh Boyer wrote: >> On Fri, Nov 21, 2014 at 3:16 PM, Andy Lutomirski wrote: >> > On Fri, Nov 21, 2014 at 12:14 PM, Josh Boyer >> > wrote: >> >> On Fri, Nov 21, 2014 at 2:52 PM, Andy Lutomirski >> >> wrote: >> >>> On Fri, Nov 21, 2014 at 11:46 AM, Linus Torvalds >> >>> wrote: >> On Fri, Nov 21, 2014 at 11:34 AM, Linus Torvalds >> wrote: >> > >> > So I kind of agree, but it wouldn't be my primary worry. My primary >> > worry is actually paravirt doing something insane. >> >> Btw, on that tangent, does anybody actually care about paravirt any >> more? >> >> >>> >> >>> Amazon, for better or for worse. > > And distros: Oracle and Novell. > >> >>> >> I'd love to start moving away from it. It makes a lot of the low-level >> code completely impossible to follow due to the random indirection >> through "native" vs "paravirt op table". Not just the page table >> handling, it's all over. >> >> Anybody who seriously does virtualization uses hw virtualization that >> is much better than it used to be. And the non-serious users aren't >> that performance-sensitive by definition. > > I would point out that the PV paravirt spinlock gives an huge boost > for virtualization guests (this is for both KVM and Xen). >> >> I note that the Fedora kernel config seems to include paravirt by >> default, so you get a lot of the crazy overheads.. > > Not that much. We ran benchmarks and it was in i-cache overhead - and > the numbers came out to be sub-1% percent. >> >>> >> >>> I think that there is a move toward deprecating Xen PV in favor of >> >>> PVH, but we're not there yet. >> >> >> >> A move where? The Xen stuff in Fedora is ... not paid attention to >> >> very much. If there's something we should be looking at turning off >> >> (or on), we're happy to take suggestions. >> > >> > A move in the Xen project. As I understand it, Xen wants to deprecate >> > PV in favor of PVH, but PVH is still experimental. >> >> OK. >> >> > I think that dropping PARAVIRT in Fedora might be a bad idea for >> > several more releases, since that's likely to break the EC2 images. >> >> Yes, that's essentially the only reason we haven't looked at disabling >> Xen completely for a while now, so . > > Heh. Didn't know you could play on a trombone! It's sad because I can't really play the trombone and it sounds horrible. > As I had mentioned in the past - if there are Xen related bugs on > Fedora please CC me on them. Or perhaps CC xen-de...@lists.xenproject.org > if that is possible. Indeed, you have been massively helpful. My comment on it being not well paid attention to was a reflection on the distro maintainers, not you. You've been great once we notice the Xen issue, but that takes a while on our part and it isn't the best of user experiences :\. > And as Andy has mentioned - we are moving towards using PVH as a way > to not use the PV MMU ops. But that is still off ( from YouTube>). OK. I'll try and do better at keeping up with things. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Sun, Nov 23, 2014 at 04:18:40PM +0300, Alexander Kochetkov wrote: > > 23 нояб. 2014 г., в 7:43, Felipe Balbi написал(а): > > > maybe there was a typo? I tested on v3.18-rc3 :-) > > I do my tests on kernel from angstrom with almost all i2c-omap patches > backported from linux/master. > Then I rebased them to wrong (old) kernel version and posted to the > list. > > Angstrom kernel is from meta-ti layer. It's the same kernel as for arago. > http://arago-project.org/wiki/index.php/Main_Page > > I would really like to switch to the recent kernel, but I don't know > how good codec engine (CE) is supported on it. > Initially all ti drivers for codec engine was done for 2.6.x kernels > and later some of them was ported for 3.2.x. > > Felipe, do you know how CE is supported on v3.18-rc3? what's CE ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 net-next 1/3] net: allow large number of rx queues
Sorry! forgot to CC Michael, doing now.
> netif_alloc_rx_queues() uses kcalloc() to allocate memory
> for "struct netdev_queue *_rx" array.
> If we are doing large rx queue allocation kcalloc() might
> fail, so this patch does a fallback to vzalloc().
> Similar implementation is done for tx queue allocation in
> netif_alloc_netdev_queues().
>
> We avoid failure of high order memory allocation
> with the help of vzalloc(), this allows us to do large
> rx and tx queue allocation which in turn helps us to
> increase the number of queues in tun.
>
> As vmalloc() adds overhead on a critical network path,
> __GFP_REPEAT flag is used with kzalloc() to do this fallback
> only when really needed.
>
> Signed-off-by: Pankaj Gupta
> Reviewed-by: Michael S. Tsirkin
> Reviewed-by: David Gibson
> ---
> net/core/dev.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index e916ba8..abe9560 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6059,17 +6059,25 @@ void netif_stacked_transfer_operstate(const struct
> net_device *rootdev,
> EXPORT_SYMBOL(netif_stacked_transfer_operstate);
>
> #ifdef CONFIG_SYSFS
> +static void netif_free_rx_queues(struct net_device *dev)
> +{
> + kvfree(dev->_rx);
> +}
> +
> static int netif_alloc_rx_queues(struct net_device *dev)
> {
> unsigned int i, count = dev->num_rx_queues;
> struct netdev_rx_queue *rx;
> + size_t sz = count * sizeof(*rx);
>
> BUG_ON(count < 1);
>
> - rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
> - if (!rx)
> - return -ENOMEM;
> -
> + rx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> + if (!rx) {
> + rx = vzalloc(sz);
> + if (!rx)
> + return -ENOMEM;
> + }
> dev->_rx = rx;
>
> for (i = 0; i < count; i++)
> @@ -6698,9 +6706,8 @@ void free_netdev(struct net_device *dev)
>
> netif_free_tx_queues(dev);
> #ifdef CONFIG_SYSFS
> - kfree(dev->_rx);
> + netif_free_rx_queues(dev);
> #endif
> -
> kfree(rcu_dereference_protected(dev->ingress_queue, 1));
>
> /* Flush device addresses */
> --
> 1.8.3.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
Am 24.11.2014 um 19:35 schrieb Linus Torvalds: > On Mon, Nov 24, 2014 at 10:02 AM, Alexei Starovoitov > wrote: >> >> If the goal is to catch non-scalar users, the following is shorter: >> #define ACCESS_ONCE(x) (((typeof(x))0) + *(volatile typeof(x) *)&(x)) > > Me likey. It probably works well in practice, although I think > > - the "(typeof(x))0)" seems unnecessary and wrong. Why not just "0"? > The typeof is not just longer, but it is incorrect for pointer types > (you can add 0 to a pointer, but you cannot add two pointers together) > > - it does mean that the resulting type ends up being upgraded to > "int", for the usual C type reasons. > > Note that the "upgraded to 'int'" is true with or without the > "(typeof(x))0". If you add two 'char' values, the addition is still > done in 'int'. > > Maybe you *meant* that typeof to fix the second problem, like so: > > (typeof(x)) (0 + *(volatile typeof(x) *)&(x)) > > Hmm? That casts the result of the addition, not the zero. Looks really nice, but does not work with ACCESS_ONCE is on the left-hand side: include/linux/rculist.h: In function 'hlist_add_before_rcu': ./arch/x86/include/asm/barrier.h:127:18: error: lvalue required as left operand of assignment ACCESS_ONCE(*p) = (v); \ Alexei's variant is also broken: include/linux/cgroup.h: In function 'task_css': include/linux/compiler.h:381:40: error: invalid operands to binary + (have 'struct css_set *' and 'struct css_set * volatile') #define ACCESS_ONCE(x) (((typeof(x))0) + *(volatile typeof(x) *)&(x)) Anyone with a new propopal? ;-)^ Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] s390/pci: Deletion of unnecessary checks before the function call "debug_unregister"
On Sat, 22 Nov 2014, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 22 Nov 2014 15:00:55 +0100
>
> The debug_unregister() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> arch/s390/pci/pci_debug.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/s390/pci/pci_debug.c b/arch/s390/pci/pci_debug.c
> index eec598c..18403a7 100644
> --- a/arch/s390/pci/pci_debug.c
> +++ b/arch/s390/pci/pci_debug.c
> @@ -158,10 +158,8 @@ int __init zpci_debug_init(void)
>
> void zpci_debug_exit(void)
> {
> - if (pci_debug_msg_id)
> - debug_unregister(pci_debug_msg_id);
> - if (pci_debug_err_id)
> - debug_unregister(pci_debug_err_id);
> + debug_unregister(pci_debug_msg_id);
> + debug_unregister(pci_debug_err_id);
>
> debugfs_remove(debugfs_root);
> }
Applied.
Thanks,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: v3.18-rc1: n900 battery discharged down to 2.97V
On Mon 2014-11-24 19:58:34, Pali Rohár wrote: > On Monday 24 November 2014 19:31:30 Pavel Machek wrote: > > Hi! > > > > I left the machine on usb-networking for extended period of > > time. Unfortunately, Xfce screensaver kept screen busy, and > > kernel failed to kill the machine. > > > > At the end, hardware protections worked (I guess), but result > > is battery discharged down to 2.97V. > > So you need some program which will monitor battery status and > when battery status is empty it should turn of device. And that program should be part of the kernel, because kernel should protect hardware from damage. (And it should be perfectly ok to boot into init=/bin/bash...) Anyway, this was just friendly warning, so that you don't unneccessarily damage your battery... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCHv10 4/5] sparc: Hook up execveat system call.
From: David Drysdale Date: Mon, 24 Nov 2014 11:53:58 + > Signed-off-by: David Drysdale Acked-by: David S. Miller > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
On Mon, Nov 24, 2014 at 10:02 AM, Alexei Starovoitov wrote: > > If the goal is to catch non-scalar users, the following is shorter: > #define ACCESS_ONCE(x) (((typeof(x))0) + *(volatile typeof(x) *)&(x)) Me likey. It probably works well in practice, although I think - the "(typeof(x))0)" seems unnecessary and wrong. Why not just "0"? The typeof is not just longer, but it is incorrect for pointer types (you can add 0 to a pointer, but you cannot add two pointers together) - it does mean that the resulting type ends up being upgraded to "int", for the usual C type reasons. Note that the "upgraded to 'int'" is true with or without the "(typeof(x))0". If you add two 'char' values, the addition is still done in 'int'. Maybe you *meant* that typeof to fix the second problem, like so: (typeof(x)) (0 + *(volatile typeof(x) *)&(x)) Hmm? That casts the result of the addition, not the zero. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] net: wireless: rtlwifi: Do not always include drivers in obj-m
In four of the rtlwifi drivers, the Makefile contains superfluous statements indicating the compilation of the driver as an LKM regardless of the corresponding Kconfig option. If the corresponding option is set to 'y', the build system will then see the object file in obj-m and obj-y, which leads to a compilation as a built-in only. Even though this leads to the desired behavior, the unconditional appearance in obj-m is confusing for someone reading the Makefile. This patch removes the superfluous Makefile statements. Signed-off-by: Andreas Ruprecht --- drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 3 --- drivers/net/wireless/rtlwifi/rtl8723ae/Makefile | 3 --- drivers/net/wireless/rtlwifi/rtl8723be/Makefile | 3 --- drivers/net/wireless/rtlwifi/rtl8821ae/Makefile | 3 --- 4 files changed, 12 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile index 11952b9..6bd46a9 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile +++ b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile @@ -1,6 +1,3 @@ -obj-m := rtl8192ee.o - - rtl8192ee-objs := \ dm.o\ fw.o\ diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile b/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile index 9c34a85..6220672 100644 --- a/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile +++ b/drivers/net/wireless/rtlwifi/rtl8723ae/Makefile @@ -1,6 +1,3 @@ -obj-m := rtl8723ae.o - - rtl8723ae-objs := \ dm.o\ fw.o\ diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/Makefile b/drivers/net/wireless/rtlwifi/rtl8723be/Makefile index 59e416a..a77c341 100644 --- a/drivers/net/wireless/rtlwifi/rtl8723be/Makefile +++ b/drivers/net/wireless/rtlwifi/rtl8723be/Makefile @@ -1,6 +1,3 @@ -obj-m := rtl8723be.o - - rtl8723be-objs := \ dm.o\ fw.o\ diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile b/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile index 87ad604..f7a26f7 100644 --- a/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile +++ b/drivers/net/wireless/rtlwifi/rtl8821ae/Makefile @@ -1,6 +1,3 @@ -obj-m := rtl8821ae.o - - rtl8821ae-objs := \ dm.o\ fw.o\ -- 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: [PATCH v3 00/41] linux: towards virtio-1 guest support
From: "Michael S. Tsirkin" Date: Mon, 24 Nov 2014 13:52:32 +0200 > Based on patches by Cornelia Rusty and others, but > with an API that should allow better static checking of code, > and slightly more concervative changes in vring,net and blk. > > Based on patches by Cornelia and others, but > with an API that should allow better static checking of code, > slightly more concervative changes in vring and drivers, Some cut and paste duplication happening here :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] net: wireless: rtlwifi: rtl8192ee: Fix compilation of the driver
In the Makefile for this driver, the wrong Kconfig option is used to trigger the compilation of the object file. This leads to the driver only being included into the kernel when both CONFIG_RTL8821AE and CONFIG_RTL8192AE are set to "y". Signed-off-by: Andreas Ruprecht --- drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile index 6bd46a9..0315eed 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile +++ b/drivers/net/wireless/rtlwifi/rtl8192ee/Makefile @@ -11,6 +11,6 @@ rtl8192ee-objs := \ trx.o \ -obj-$(CONFIG_RTL8821AE) += rtl8192ee.o +obj-$(CONFIG_RTL8192EE) += rtl8192ee.o ccflags-y += -D__CHECK_ENDIAN__ -- 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: [PATCH V3 11/11] MIPS: Add multiplatform BMIPS target
Hi, On Mon, Nov 24, 2014 at 6:00 AM, Arnd Bergmann wrote: >> --- >> .../devicetree/bindings/mips/brcm/bmips.txt| 8 + >> .../devicetree/bindings/mips/brcm/soc.txt | 12 ++ >> arch/mips/Kbuild.platforms | 1 + >> arch/mips/Kconfig | 36 >> arch/mips/bmips/Kconfig| 50 ++ >> arch/mips/bmips/Makefile | 1 + >> arch/mips/bmips/Platform | 7 + >> arch/mips/bmips/dma.c | 141 +++ >> arch/mips/bmips/irq.c | 38 >> arch/mips/bmips/setup.c| 195 >> + >> arch/mips/boot/dts/Makefile| 9 + >> arch/mips/boot/dts/bcm3384_viper.dtsi | 108 >> arch/mips/boot/dts/bcm3384_zephyr.dtsi | 126 + >> arch/mips/boot/dts/bcm6328.dtsi| 87 + >> arch/mips/boot/dts/bcm6368.dtsi| 94 ++ >> arch/mips/boot/dts/bcm7125.dtsi| 107 +++ >> arch/mips/boot/dts/bcm7346.dtsi| 192 >> >> arch/mips/boot/dts/bcm7360.dtsi| 129 ++ >> arch/mips/boot/dts/bcm7420.dtsi| 151 >> arch/mips/boot/dts/bcm7425.dtsi| 191 >> > > I hadn't noticed before that the dts files are now all in one > directory on MIPS, apparently after a patch from Andrew Brewsticker. > We should really coordinate these things better, we have just merged > an arm64 patch to split out the files into multiple directories. FWIW, I'm planning on sending a patch once 3.19-rc1 is released to move the DTs into per-vendor sub-directories. I was expecting to do it for 3.19, but Robert Richter's series which added kbuild support for the vendor sub-directories did not end up landing in 3.18. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v3.18-rc1: n900 battery discharged down to 2.97V
Hi! I left the machine on usb-networking for extended period of time. Unfortunately, Xfce screensaver kept screen busy, and kernel failed to kill the machine. At the end, hardware protections worked (I guess), but result is battery discharged down to 2.97V. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [CFT PATCH 0/2] KVM: support XSAVES usage in the host
> On Nov 24, 2014, at 19:53, Paolo Bonzini wrote: > > > > On 24/11/2014 16:28, Nadav Amit wrote: >> >> Since kvm_load_guest_fpu is called before the guest_fpu is ever stored, >> there are 2 more problems that currently cause #GP: >> 1. XCOMP_BV[63] = 0 >> 2. XSTATE_BV sets a bit (including bit 63) that is not set in XCOMP_BV >> (XCOMP_BV is initialised to zero). >> >> [see SDM 13.11 "OPERATION OF XRSTORS”] >> >> Once I initialise XCOMP_BV to (1ull << 63) | XSTATE_BV, the guest runs >> successfully. >> I have not checked any other qemu functionality that might be affected by >> the patch. > > I posted patches that assume that QEMU calls KVM_SET_XSAVE early enough. > If this is not the case, can you cook up and post a patch to > kvm_arch_vcpu_init that fixes the remaining problem? Sure. I will try to do so tomorrow. Nadav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH, RESEND] spi, spidev: Add support for long SPI transfers
SPI controllers found on modern SoCs have rather large SPI FIFOs and
allow for uninterrupted SPI transaction that are more then 255 bits
long. This commit adds necessary plumbing for such SPI transfers.
Signed-off-by: Andrey Smirnov
---
Changes:
- Fixed commit message
- Ditched the cover letter
- Used correct address for linux-kernel mailing list
Hi,
This patch is a very first, very preliminary version of the feature I
am implementing for niche usecase of SPI in a system I am working
on. It by no means contains production code and is purely RFC to "test
the water" and see if there would be any interest in including this in
mainline tree.
The system I am working with implements a lion's share of its
functionality in an extrenal FPGA connected to an ARM SoC via SPI
bus. In my use-case SPI bus used both for initial bitfile programming
of the FPGA and sending/fetching data to/from FPGA as well. Both use
cases, can benefit greatly from ability to send very long bit streams
over SPI as a single transaction during which CS line stays low the
whole time. The use-case of programming the FPGA is the most important
for me, since it is mandatory to program the FPGA before the rest of
the system can proceed to a functioning state and therefore my
"Applied power -> Functional State" time is greatly influenced by that
operation.
As things are right now both SPI subsystem and SPIDEV driver are
limited by their APIs to SPI transactions that are no longer than 255
bits and that problem is exacerbated by the fact that transction
length validity verification code does not have provisions for
anything bigger than 32 bits.
The code in this RFC deals only with the first problem, as I am not
sure what would best way to tackle the second one.
So I guess my two maing questions for this RFC are the following:
- Is this work seem like a good fit to be included in the mainline
kernel, or should I just keep doing it as my system specifica hack
and not bother with upsteaming?
- If the idea is good for upstreaming what would be a good way to
improve length checking code? I was thinking of ditching the
bitmask in favour of driver provided function that would take
transfer length as an argument, are there any better options?
Thank you.
Andrey Smirnov
drivers/spi/spidev.c| 7 ++-
include/linux/spi/spi.h | 4 ++--
include/uapi/linux/spi/spidev.h | 2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index d7c6e36..45d8905 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -265,7 +265,12 @@ static int spidev_message(struct spidev_data *spidev,
buf += k_tmp->len;
k_tmp->cs_change = !!u_tmp->cs_change;
- k_tmp->bits_per_word = u_tmp->bits_per_word;
+
+ if (!u_tmp->bits_per_word && u_tmp->bits_per_burst)
+ k_tmp->bits_per_word = u_tmp->bits_per_burst;
+ else
+ k_tmp->bits_per_word = u_tmp->bits_per_word;
+
k_tmp->delay_usecs = u_tmp->delay_usecs;
k_tmp->speed_hz = u_tmp->speed_hz;
#ifdef VERBOSE
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 4203c66..a0c34c1 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -75,7 +75,7 @@ struct spi_device {
struct spi_master *master;
u32 max_speed_hz;
u8 chip_select;
- u8 bits_per_word;
+ u32 bits_per_word;
u16 mode;
#defineSPI_CPHA0x01/* clock phase */
#defineSPI_CPOL0x02/* clock polarity */
@@ -586,7 +586,7 @@ struct spi_transfer {
#defineSPI_NBITS_SINGLE0x01 /* 1bit transfer */
#defineSPI_NBITS_DUAL 0x02 /* 2bits transfer */
#defineSPI_NBITS_QUAD 0x04 /* 4bits transfer */
- u8 bits_per_word;
+ u32 bits_per_word;
u16 delay_usecs;
u32 speed_hz;
diff --git a/include/uapi/linux/spi/spidev.h b/include/uapi/linux/spi/spidev.h
index 52d9ed0..b70f3d4 100644
--- a/include/uapi/linux/spi/spidev.h
+++ b/include/uapi/linux/spi/spidev.h
@@ -92,7 +92,7 @@ struct spi_ioc_transfer {
__u16 delay_usecs;
__u8bits_per_word;
__u8cs_change;
- __u32 pad;
+ __u32 bits_per_burst;
/* If the contents of 'struct spi_ioc_transfer' ever change
* incompatibly, then the ioctl number (currently 0) must change;
--
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
[PATCH 0/2] net: wireless: rtlwifi: Fix issues with Makefiles
This patch series fixes two issues in the Makefiles for different rtlwifi drivers. The first one lead to object files for the drivers always being included in obj-m even if the corresponding Kconfig option is set to 'y'. The second one is likely to be a copy-and-paste mistake, which prevents compilation of the rtl8192ee driver unless the completely unrelated Kconfig option for the rtl8821ae driver (CONFIG_RTL8821AE) is also enabled. Andreas Ruprecht (2): net: wireless: rtlwifi: Do not always include drivers in obj-m net: wireless: rtlwifi: rtl8192ee: Fix compilation of the driver drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 5 + drivers/net/wireless/rtlwifi/rtl8723ae/Makefile | 3 --- drivers/net/wireless/rtlwifi/rtl8723be/Makefile | 3 --- drivers/net/wireless/rtlwifi/rtl8821ae/Makefile | 3 --- 4 files changed, 1 insertion(+), 13 deletions(-) -- 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: [GIT PULL] Btrfs deadlock fix
On Mon, Nov 24, 2014 at 01:01:10PM -0500, Chris Mason wrote: > > I've retested it again including this pull and still deadlocks > > reliably > > at btrfs/070. > > This wasn't a new problem, so I had it queued for the merge window. Well, I don't remember seeing this problem with anything 3.17 based but I can check. I know this does not mean that it was introduced in 3.18, only that other changes exposed the problem, but this still IMHO qualifies as a bug to be fixed within 3.18. Besides, it makes testing 3.18-rc slightly more annoying (either skip the test or manually pick the patch after each pull). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv10 2/5] x86: Hook up execveat system call.
On Mon, Nov 24, 2014 at 5:06 PM, Dan Carpenter wrote: > On Mon, Nov 24, 2014 at 11:53:56AM +, David Drysdale wrote: >> Hook up x86-64, i386 and x32 ABIs. >> >> Signed-off-by: David Drysdale > > This one has been breaking my linux-next build for the past week. I'm > not sure what's going on. Hi Dan, Sorry if this has been causing you problems -- I've not had any errors from the kbuild robots or my local builds. > I build with a script: > > make allmodconfig > > cat << EOF >> .config > CONFIG_DYNAMIC_DEBUG=n > CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=n > CONFIG_DYNAMIC_DEBUG=y > EOF > > make oldconfig > > Here are the errors: > > CHK include/generated/compile.h > CHECK arch/x86/ia32/audit.c > CC arch/x86/ia32/audit.o > arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’: > arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in > this function) > arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported only > once for each function it appears in > make[2]: *** [arch/x86/ia32/audit.o] Error 1 > make[2]: Target `__build' not remade because of errors. > make[1]: *** [arch/x86/ia32] Error 2 > CHECK arch/x86/kernel/audit_64.c > CHK kernel/config_data.h > CC arch/x86/kernel/audit_64.o > arch/x86/kernel/audit_64.c: In function ‘audit_classify_syscall’: > arch/x86/kernel/audit_64.c:53:7: error: ‘__NR_execveat’ undeclared (first use > in this function) > arch/x86/kernel/audit_64.c:53:7: note: each undeclared identifier is reported > only once for each function it appears in > make[2]: *** [arch/x86/kernel/audit_64.o] Error 1 > make[2]: Target `__build' not remade because of errors. > make[1]: *** [arch/x86/kernel] Error 2 > make[1]: Target `__build' not remade because of errors. That seems odd -- the generic definition of __NR_execveat is in the first patch in the series, and the various x86-specific definitions should get generated from the table entries in the second patch in the series (at least since the v9 set I sent on 19 Nov, which split out the x86 wiring from the general implementation). Are the syscall table generation steps happening in your build? And does __NR_execveat appear in the various generated x86 unistd*.h headers? As an aside, I've just built next-20141124 (a4cfa44aa26a) fine from scratch with your config steps. The build output included the header generation steps: SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_64.h SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h HOSTCC scripts/basic/bin2c SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_x32.h and the resulting files did include the __NR_execveat constant: % grep execveat usr/include/asm*/*.h arch/x86/include/generated/uapi/asm/*.h usr/include/asm-generic/unistd.h:#define __NR_execveat 281 usr/include/asm-generic/unistd.h:__SC_COMP(__NR_execveat, sys_execveat, compat_sys_execveat) usr/include/asm/unistd_32.h:#define __NR_execveat 358 usr/include/asm/unistd_64.h:#define __NR_execveat 322 usr/include/asm/unistd_x32.h:#define __NR_execveat (__X32_SYSCALL_BIT + 545) arch/x86/include/generated/uapi/asm/unistd_32.h:#define __NR_execveat 358 arch/x86/include/generated/uapi/asm/unistd_64.h:#define __NR_execveat 322 arch/x86/include/generated/uapi/asm/unistd_x32.h:#define __NR_execveat (__X32_SYSCALL_BIT + 545) So I can't (yet) reproduce your problem I'm afraid... > regards, > dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.18-rc3 v8 1/4] irqchip: gic: Make gic_raise_softirq() FIQ-safe
On Fri, 14 Nov 2014, Daniel Thompson wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 38493ff28fa5..0db62a6f1ee3 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -73,6 +73,13 @@ struct gic_chip_data {
> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>
> /*
> + * This lock may be locked for reading by FIQ handlers. Thus although
> + * read locking may be used liberally, write locking must only take
> + * place only when local FIQ handling is disabled.
> + */
> +static DEFINE_RWLOCK(fiq_safe_cpu_map_lock);
> +
> +/*
> * The GIC mapping of CPU interfaces does not necessarily match
> * the logical CPU numbering. Let's use a mapping as returned
> * by the GIC itself.
> @@ -624,7 +631,7 @@ static void gic_raise_softirq(const struct cpumask *mask,
> unsigned int irq)
> int cpu;
> unsigned long flags, map = 0;
>
> - raw_spin_lock_irqsave(_controller_lock, flags);
> + read_lock_irqsave(_safe_cpu_map_lock, flags);
Just for the record:
You might have noticed that you replace a raw lock with a non raw
one. That's not an issue on mainline, but that pretty much renders
that code broken for RT.
Surely nothing I worry too much about given the current state of RT.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm, gfp: escalatedly define GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE
On Tue, Nov 25, 2014 at 12:43:47AM +0800, Jianyu Zhan wrote: > GFP_USER, GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE are escalatedly > confined defined, also implied by their names: > > GFP_USER = GFP_USER > GFP_USER + __GFP_HIGHMEM = GFP_HIGHUSER > GFP_USER + __GFP_HIGHMEM + __GFP_MOVABLE = GFP_HIGHUSER_MOVABLE > > So just make GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE escalatedly defined > to reflect this fact. It also makes the definition clear and texturally > warn on any furture break-up of this escalated relastionship. > > Signed-off-by: Jianyu Zhan Acked-by: Johannes Weiner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Changes from v2:
- add return values to print routines
- add .gitignore file
Changes from v1:
- use more correct Copyright string in get_size.c
Signed-off-by: Tim Bird
---
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 21 +++
tools/testing/selftests/size/get_size.c | 105
4 files changed, 128 insertions(+)
create mode 100644 tools/testing/selftests/size/.gitignore
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/.gitignore
b/tools/testing/selftests/size/.gitignore
new file mode 100644
index 000..189b781
--- /dev/null
+++ b/tools/testing/selftests/size/.gitignore
@@ -0,0 +1 @@
+get_size
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..51e5fbd
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,21 @@
+#ifndef CC
+ CC = $(CROSS_COMPILE)gcc
+#endif
+
+#ifndef STRIP
+ STRIP = $(CROSS_COMPILE)strip
+#endif
+
+all: get_size
+
+get_size: get_size.c
+ $(CC) --static -ffreestanding -nostartfiles \
+ -Wl,--entry=main get_size.c -o get_size \
+ `cc -print-libgcc-file-name`
+ $(STRIP) -s get_size
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..9c8d3cd
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2014 Sony
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing its own
+ * strlen(), number output and print() routines.
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+int my_strlen(const char *s)
+{
+ int len = 0;
+
+ while (*s++)
+ len++;
+ return len;
+}
+
+/*
+ * num_to_str - put digits from num into *s, left to right
+ * do this by dividing the number by powers of 10
+ * the tricky part is to omit leading zeros
+ * don't print zeros until we've started printing any numbers at all
+ */
+void num_to_str(unsigned long num, char *s)
+{
+ unsigned long long temp, div;
+ int started;
+
+ temp = num;
+ div = 100LL;
+ started = 0;
+ while (div) {
+ if (temp/div || started) {
+ *s++ = (unsigned char)(temp/div + '0');
+ started = 1;
+ }
+ temp -= (temp/div)*div;
+ div /= 10;
+ }
+ *s = 0;
+}
+
+int print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ num_to_str(num, num_buf);
+ return write(STDOUT_FILENO, num_buf, my_strlen(num_buf));
+}
+
+int print(char *s)
+{
+ return write(STDOUT_FILENO, s, my_strlen(s));
+}
+
+void main(int argc, char **argv)
+{
+ int ccode;
+ unsigned long used;
+ struct sysinfo info;
+ unsigned long long temp;
+
+ print("Testing system size.\n");
+ print("1..1\n");
+
+ ccode = sysinfo();
+ if (ccode < 0) {
+ print("not ok 1 get size runtime size\n");
+ print("# could not get sysinfo\n");
+ _exit(ccode);
+ }
+
+ /* ignore cache complexities for now */
+ temp = info.totalram - info.freeram - info.bufferram;
+ temp = temp *
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On Mon, Nov 24, 2014 at 06:49:50PM +0100, Sebastian Andrzej Siewior wrote: > On 11/18/2014 10:17 PM, Felipe Balbi wrote: > > I think the driver is mis-detecting Babble. A babble only occurs when > > the device side tries to move data without the host asking for anything. > > It also occurs if the device moves more than packet_size bytes. Not > really helping, I know… hmm, why would the device move more than wMaxPacketSize at a time ? That's certainly babble :-) We *must* move data in the wire in <=wMaxPacketSize chunks. -- balbi signature.asc Description: Digital signature
Re: [5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery
On 24-11-2014 14:15, Grygorii Strashko wrote:
Hi Uwe,
On 11/23/2014 07:04 PM, Uwe Kleine-König wrote:
On Thu, Nov 20, 2014 at 12:03:08PM +0200, Grygorii Strashko wrote:
@@ -664,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
))
dev->pdata->bus_freq = prop / 1000;
+ dev->pdata->has_pfunc = true;
I don't understand this. Why does this ICPFUNC recovery work if the bus
is probed by oftree, but doesn't if not?
I've mentioned this in commit message:
Allow platforms to indicate the presence of the ICPFUNC registers with a
has_pfunc
platform data flag and enable this mode for platforms which supports DT
(da850 and
Keystone 2 are two SoCs which support DT now and they also support ICPFUNC
registers).
I'll add proper comment here.
Just thinking: What happens if you try to use the ICPFUNC registers on
platforms that don't support it? If the answer is "nothing bad", then
you might as well assume that if the platform doesn't specify its own
GPIOs, you can always try using the ICPFUNC registers to shake the I2C
bus. Better to try and fail than to never try at all...
} else if (!dev->pdata) {
dev->pdata = _i2c_platform_data_default;
}
@@ -705,7 +801,9 @@ static int davinci_i2c_probe(struct platform_device *pdev)
adap->timeout = DAVINCI_I2C_TIMEOUT;
adap->dev.of_node = pdev->dev.of_node;
- if (dev->pdata->scl_pin) {
+ if (dev->pdata->has_pfunc)
+ adap->bus_recovery_info = _i2c_scl_recovery_info;
+ else if (dev->pdata->scl_pin) {
adap->bus_recovery_info = _i2c_gpio_recovery_info;
adap->bus_recovery_info->scl_gpio = dev->pdata->scl_pin;
adap->bus_recovery_info->sda_gpio = dev->pdata->sda_pin;
diff --git a/include/linux/platform_data/i2c-davinci.h
b/include/linux/platform_data/i2c-davinci.h
index 2312d19..89fd347 100644
--- a/include/linux/platform_data/i2c-davinci.h
+++ b/include/linux/platform_data/i2c-davinci.h
@@ -18,6 +18,7 @@ struct davinci_i2c_platform_data {
unsigned intbus_delay; /* post-transaction delay (usec) */
unsigned intsda_pin;/* GPIO pin ID to use for SDA */
unsigned intscl_pin;/* GPIO pin ID to use for SCL */
+ boolhas_pfunc; /*chip has a ICPFUNC register */
Space after /* please
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 02/12] x86_64: load_percpu_segment: read irq_stack_union.gs_base before load_segment
Reading irq_stack_union.gs_base after load_segment creates troubles for kasan. Compiler inserts __asan_load in between load_segment and wrmsrl. If kernel built with stackprotector this will result in boot failure because __asan_load has stackprotector. To avoid this irq_stack_union.gs_base stored to temporary variable before load_segment, so __asan_load will be called before load_segment(). There are two alternative ways to fix this: a) Add __attribute__((no_sanitize_address)) to load_percpu_segment(), which tells compiler to not instrument this function. However this will result in build failure with CONFIG_KASAN=y and CONFIG_OPTIMIZE_INLINING=y. b) Add -fno-stack-protector for mm/kasan/kasan.c Signed-off-by: Andrey Ryabinin --- arch/x86/kernel/cpu/common.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 8779d63..97f56f6 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -389,8 +389,10 @@ void load_percpu_segment(int cpu) #ifdef CONFIG_X86_32 loadsegment(fs, __KERNEL_PERCPU); #else + void *gs_base = per_cpu(irq_stack_union.gs_base, cpu); + loadsegment(gs, 0); - wrmsrl(MSR_GS_BASE, (unsigned long)per_cpu(irq_stack_union.gs_base, cpu)); + wrmsrl(MSR_GS_BASE, (unsigned long)gs_base); #endif load_stack_canary_segment(); } -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] backlight: lp8788: Deletion of a check before backlight_device_unregister()
From: Markus Elfring
The backlight_device_unregister() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/backlight/lp8788_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lp8788_bl.c
b/drivers/video/backlight/lp8788_bl.c
index d6c4f6a..24a055c 100644
--- a/drivers/video/backlight/lp8788_bl.c
+++ b/drivers/video/backlight/lp8788_bl.c
@@ -221,8 +221,7 @@ static void lp8788_backlight_unregister(struct lp8788_bl
*bl)
{
struct backlight_device *bl_dev = bl->bl_dev;
- if (bl_dev)
- backlight_device_unregister(bl_dev);
+ backlight_device_unregister(bl_dev);
}
static ssize_t lp8788_get_bl_ctl_mode(struct device *dev,
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
