* Re: [PATCH] MIPS: jz4740: Bump zload address
From: Paul Burton @ 2018-07-24 0:48 UTC (permalink / raw)
To: Paul Cercueil; +Cc: Ralf Baechle, James Hogan, linux-mips, linux-kernel
In-Reply-To: <20180708150712.7404-1-paul@crapouillou.net>
Hi Paul,
On Sun, Jul 08, 2018 at 05:07:12PM +0200, Paul Cercueil wrote:
> Having the zload address at 0x8060.0000 means the size of the
> uncompressed kernel cannot be bigger than around 6 MiB, as it is
> deflated at address 0x8001.0000.
>
> This limit is too small; a kernel with some built-in drivers and things
> like debugfs enabled will already be over 6 MiB in size, and so will
> fail to extract properly.
>
> To fix this, we bump the zload address from 0x8060.0000 to 0x8100.0000.
>
> This is fine, as all the boards featuring Ingenic JZ SoCs have at least
> 32 MiB of RAM, and use u-boot or compatible bootloaders which won't
> hardcode the load address but read it from the uImage's header.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> arch/mips/jz4740/Platform | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks - applied to mips-next for 4.19 (and tested on Ci20).
Paul
^ permalink raw reply
* Re: [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 23:42 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: James Bottomley, Jarkko Sakkinen, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <20180723220822.GJ532@ziepe.ca>
On 07/23/2018 03:08 PM, Jason Gunthorpe wrote:
> On Mon, Jul 23, 2018 at 03:00:20PM -0700, Tadeusz Struk wrote:
>> On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
>>> The proposed patch doesn't clear the data_pending if the entire buffer
>>> is not consumed, so of course it is ABI breaking, that really isn't OK.
>> The data_pending will be cleared by the timeout handler if the user doesn't
>> read the response fully before the timeout expires. The is the same situation
>> if the user would not read the response at all.
> That causes write() to fail with EBUSY
>
> NAK from me on breaking the ABI like this
What if we introduce this new behavior only for the non-blocking mode
as James suggested? Or do you have some other suggestions?
Thanks,
--
Tadeusz
^ permalink raw reply
* [U-Boot] [PATCH V2 29/32] fsl_esdhc: Update usdhc driver to support i.MX8
From: Peng Fan @ 2018-07-24 0:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAOMZO5AZvA7xvyZmAx-5tndVtpT62Hc+_x6tWy3Oh9dniaBs0w@mail.gmail.com>
Hi Fabio,
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: 2018年7月24日 3:27
> To: Peng Fan <peng.fan@nxp.com>
> Cc: Stefano Babic <sbabic@denx.de>; Fabio Estevam
> <fabio.estevam@nxp.com>; U-Boot-Denx <u-boot@lists.denx.de>; dl-linux-imx
> <linux-imx@nxp.com>
> Subject: Re: [U-Boot] [PATCH V2 29/32] fsl_esdhc: Update usdhc driver to
> support i.MX8
>
> Hi Peng,
>
> On Thu, Jul 19, 2018 at 11:04 AM, Peng Fan <peng.fan@nxp.com> wrote:
>
> > There is i.MX8/8X/8M, 8M is for i.MX8MQ and i.MX8MM i.MX8/8X has
> > different SoC architecture compared with i.MX8M, such as there is SCU
> > inside i.MX8/8X.
> > So add a new macro dedicated for i.MX8/8X.
>
> Yes, I understand the differences between the MX8 family.
>
> Couldn't you make CONFIG_IMX8 instead of CONFIG_ARCH_IMX8 for
> consistency?
In V1, I use CONFIG_IMX8, but I think there is no need to use it, because
CONFIG_ARCH_IMX8 could do same thing.
I could revert to use CONFIG_IMX8, since you prefer it.
>
> Also, for consistency: should CONFIG_MX8M be changed to CONFIG_IMX8M?
Yes. CONFIG_MX8M also need to be changed to CONFIG_IMX8M, but not in this patchset.
Thanks,
Peng.
>
> Thanks
^ permalink raw reply
* [PATCH net v2] ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull
From: Willem de Bruijn @ 2018-07-23 23:36 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Syzbot reported a read beyond the end of the skb head when returning
IPV6_ORIGDSTADDR:
BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1219
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1261
copy_to_user include/linux/uaccess.h:184 [inline]
put_cmsg+0x5ef/0x860 net/core/scm.c:242
ip6_datagram_recv_specific_ctl+0x1cf3/0x1eb0 net/ipv6/datagram.c:719
ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
[..]
This logic and its ipv4 counterpart read the destination port from
the packet at skb_transport_offset(skb) + 4.
With MSG_MORE and a local SOCK_RAW sender, syzbot was able to cook a
packet that stores headers exactly up to skb_transport_offset(skb) in
the head and the remainder in a frag.
Call pskb_may_pull before accessing the pointer to ensure that it lies
in skb head.
Link: http://lkml.kernel.org/r/CAF=yD-LEJwZj5a1-bAAj2Oy_hKmGygV6rsJ_WOrAYnv-fnayiQ@mail.gmail.com
Reported-by: syzbot+9adb4b567003cac781f0@syzkaller.appspotmail.com
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/ip_sockglue.c | 7 +++++--
net/ipv6/datagram.c | 7 +++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 64c76dcf7386..c0fe5ad996f2 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -150,15 +150,18 @@ static void ip_cmsg_recv_dstaddr(struct msghdr *msg, struct sk_buff *skb)
{
struct sockaddr_in sin;
const struct iphdr *iph = ip_hdr(skb);
- __be16 *ports = (__be16 *)skb_transport_header(skb);
+ __be16 *ports;
+ int end;
- if (skb_transport_offset(skb) + 4 > (int)skb->len)
+ end = skb_transport_offset(skb) + 4;
+ if (end > 0 && !pskb_may_pull(skb, end))
return;
/* All current transport protocols have the port numbers in the
* first four bytes of the transport header and this function is
* written with this assumption in mind.
*/
+ ports = (__be16 *)skb_transport_header(skb);
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = iph->daddr;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2ee08b6a86a4..1a1f876f8e28 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -700,13 +700,16 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
}
if (np->rxopt.bits.rxorigdstaddr) {
struct sockaddr_in6 sin6;
- __be16 *ports = (__be16 *) skb_transport_header(skb);
+ __be16 *ports;
+ int end;
- if (skb_transport_offset(skb) + 4 <= (int)skb->len) {
+ end = skb_transport_offset(skb) + 4;
+ if (end <= 0 || pskb_may_pull(skb, end)) {
/* All current transport protocols have the port numbers in the
* first four bytes of the transport header and this function is
* written with this assumption in mind.
*/
+ ports = (__be16 *)skb_transport_header(skb);
sin6.sin6_family = AF_INET6;
sin6.sin6_addr = ipv6_hdr(skb)->daddr;
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* Re: [patch net-next v4 00/12] sched: introduce chain templates support with offloading to mlxsw
From: Jakub Kicinski @ 2018-07-23 23:36 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, simon.horman, john.hurley,
dsahern, mlxsw, sridhar.samudrala
In-Reply-To: <20180723072312.4153-1-jiri@resnulli.us>
On Mon, 23 Jul 2018 09:23:03 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> For the TC clsact offload these days, some of HW drivers need
> to hold a magic ball. The reason is, with the first inserted rule inside
> HW they need to guess what fields will be used for the matching. If
> later on this guess proves to be wrong and user adds a filter with a
> different field to match, there's a problem. Mlxsw resolves it now with
> couple of patterns. Those try to cover as many match fields as possible.
> This aproach is far from optimal, both performance-wise and scale-wise.
> Also, there is a combination of filters that in certain order won't
> succeed.
>
> Most of the time, when user inserts filters in chain, he knows right away
> how the filters are going to look like - what type and option will they
> have. For example, he knows that he will only insert filters of type
> flower matching destination IP address. He can specify a template that
> would cover all the filters in the chain.
>
> This patchset is providing the possibility to user to provide such
> template to kernel and propagate it all the way down to device
> drivers.
LGTM, thanks for the changes!
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 0:40 UTC (permalink / raw)
To: Alex Williamson, linux-pci; +Cc: linux-kernel, linux-nvme
In-Reply-To: <20180724001310.7671.41243.stgit@gimli.home>
On 7/23/2018 5:13 PM, Alex Williamson wrote:
> + * The NVMe specification requires that controllers support PCIe FLR, but
> + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> + * config space) unless the device is quiesced prior to FLR.
Does disabling the memory bit in PCI config space as part of the FLR
reset function help? (like the very first thing)
Can we do that in the pcie_flr() function to cover other endpoint types
that might be pushing traffic while code is trying to do a reset?
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 0:40 UTC (permalink / raw)
To: Alex Williamson, linux-pci; +Cc: linux-kernel, linux-nvme
In-Reply-To: <20180724001310.7671.41243.stgit@gimli.home>
On 7/23/2018 5:13 PM, Alex Williamson wrote:
> + * The NVMe specification requires that controllers support PCIe FLR, but
> + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> + * config space) unless the device is quiesced prior to FLR.
Does disabling the memory bit in PCI config space as part of the FLR
reset function help? (like the very first thing)
Can we do that in the pcie_flr() function to cover other endpoint types
that might be pushing traffic while code is trying to do a reset?
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 0:40 UTC (permalink / raw)
In-Reply-To: <20180724001310.7671.41243.stgit@gimli.home>
On 7/23/2018 5:13 PM, Alex Williamson wrote:
> + * The NVMe specification requires that controllers support PCIe FLR, but
> + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> + * config space) unless the device is quiesced prior to FLR.
Does disabling the memory bit in PCI config space as part of the FLR
reset function help? (like the very first thing)
Can we do that in the pcie_flr() function to cover other endpoint types
that might be pushing traffic while code is trying to do a reset?
^ permalink raw reply
* [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications
From: Ian Kent @ 2018-07-24 0:37 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <675e5c24-36ef-4cc5-846c-1414c1195d85@schaufler-ca.com>
On Mon, 2018-07-23 at 09:31 -0700, Casey Schaufler wrote:
> On 7/23/2018 8:25 AM, David Howells wrote:
> > Hi Al,
> >
> > Here's a set of patches to add a general variable-length notification queue
> > concept and to add sources of events for:
>
> Overall I approve. The interface is a bit clunky. Some concerns below.
>
> >
> > (1) Mount topology and reconfiguration change events.
>
> With the possibility of unprivileged mounting you're
> going to have to address access control on events.
> If root in a user namespace mounts a filesystem you
> may have a case where the "real" user wouldn't want the
> listener to receive a notification.
>
> > (2) Superblocks EIO, ENOSPC and EDQUOT events (not complete yet).
>
> Here, too. If SELinux (for example) policy says you can't see
> anything on a filesystem you shouldn't get notifications about
> things that happen to that filesystem.
>
> > (3) Key/keyring changes events
>
> And again, I should only get notifications about keys and
> keyrings I have access to.
>
> I expect that you intentionally left off
>
> (4) User injected events
>
> at this point, but it's an obvious extension. That is going
> to require access controls (remember kdbus) so I think you'd
> do well to design them in now rather than have some security
> module hack like me come along later and "fix" it.
I thought mount name space should be considered too even
though I wasn't considering the cloning of file handles
into a user mount name space.
But can this happen in other ways besides user mount name
space creation (I'm fishing here)?
And nsenter(1) doesn't require an exec for anything other
than a pid name space change so a forced close on exec
wouldn't be enough. Or am I mistaken in that nsenter(1)
actually requires running a program (even though the man
page implies it's optional) ...
Are there other consideration my limited understanding is
missing?
>
> > One of the reasons for this is so that we can remove the issue of processes
> > having to repeatedly and regularly scan /proc/mounts, which has proven to be
> > a
> > system performance problem.
> >
> >
> > Design decisions:
> >
> > (1) A misc chardev is used to create and open a ring buffer:
> >
> > fd = open("/dev/watch_queue", O_RDWR);
> >
> > which is then configured and mmap'd into userspace:
> >
> > ioctl(fd, IOC_WATCH_QUEUE_SET_SIZE, BUF_SIZE);
> > ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter);
> > buf = mmap(NULL, BUF_SIZE * page_size, PROT_READ | PROT_WRITE,
> > MAP_SHARED, fd, 0);
> >
> > The fd cannot be read or written (though there is a facility to use
> > write
> > to inject records for debugging) and userspace just pulls data directly
> > out of the buffer.
> >
> > (2) The ring index pointers are stored inside the ring and are thus
> > accessible to userspace. Userspace should only update the tail pointer
> > and never the head pointer or risk breaking the buffer. The kernel
> > checks that the pointers appear valid before trying to use them. A
> > 'skip' record is maintained around the pointers.
> >
> > (3) poll() can be used to wait for data to appear in the buffer.
> >
> > (4) Records in the buffer are binary, typed and have a length so that they
> > can be of varying size.
> >
> > This means that multiple heterogeneous sources can share a common
> > buffer. Tags may be specified when a watchpoint is created to help
> > distinguish the sources.
> >
> > (5) The queue is reusable as there are 16 million types available, of which
> > I've used 4, so there is scope for others to be used.
> >
> > (6) Records are filterable as types have up to 256 subtypes that can be
> > individually filtered. Other filtration is also available.
> >
> > (7) Each time the buffer is opened, a new buffer is created - this means
> > that
> > there's no interference between watchers.
> >
> > (8) When recording a notification, the kernel will not sleep, but will
> > rather
> > mark a queue as overrun if there's insufficient space, thereby avoiding
> > userspace causing the kernel to hang.
> >
> > (9) The 'watchpoint' should be specific where possible, meaning that you
> > specify the object that you want to watch.
> >
> > (10) The buffer is created and then watchpoints are attached to it, using
> > one
> > of:
> >
> > keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fd, 0x01);
> > mount_notify(AT_FDCWD, "/", 0, fd, 0x02);
> > sb_notify(AT_FDCWD, "/mnt", 0, fd, 0x03);
> >
> > where in all three cases, fd indicates the queue and the number after
> > is
> > a tag between 0 and 255.
> >
> > (11) The watch must be removed if either the watch buffer is destroyed or
> > the
> > watched object is destroyed.
> >
> >
> > Things I want to avoid:
> >
> > (1) Introducing features that make the core VFS dependent on the network
> > stack or networking namespaces (ie. usage of netlink).
> >
> > (2) Dumping all this stuff into dmesg and having a daemon that sits there
> > parsing the output and distributing it as this then puts the
> > responsibility for security into userspace and makes handling
> > namespaces
> > tricky. Further, dmesg might not exist or might be inaccessible inside
> > a
> > container.
> >
> > (3) Letting users see events they shouldn't be able to see.
> >
> >
> > Further things that need to be done:
> >
> > (1) fsinfo() syscall needs to find superblocks by ID as well as by path so
> > that it can query a superblock for information without the need to try
> > and work out how to reach it - if the calling process even can.
> >
> > (2) A mount_info() syscall is needed that can enumerate all the children of
> > a
> > mount. This is necessary because mountpoints can hide each other by
> > stacking, so paths are not unique keys. This will require the ability
> > to
> > look up a mount by ID. This avoids the need to parse /proc/mounts.
> >
> > (3) A keyctl call is needed to allow a watch on a keyring to be extended to
> > "children" of that keyring, such that the watch is removed from the
> > child
> > if it is unlinked from the keyring.
> >
> > (4) A global superblock event queue maybe?
> >
> > (5) Propagating watches to child superblock over automounts?
> >
> >
> > The patches can be found here also:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h
> > =notifications
> >
> > David
> > ---
> > David Howells (5):
> > General notification queue with user mmap()'able ring buffer
> > KEYS: Add a notification facility
> > vfs: Add a mount-notification facility
> > vfs: Add superblock notifications
> > Add sample notification program
> >
> >
> > Documentation/security/keys/core.rst | 59 ++
> > Documentation/watch_queue.rst | 305 ++++++++++++
> > arch/x86/entry/syscalls/syscall_32.tbl | 2
> > arch/x86/entry/syscalls/syscall_64.tbl | 2
> > drivers/misc/Kconfig | 9
> > drivers/misc/Makefile | 1
> > drivers/misc/watch_queue.c | 835
> > ++++++++++++++++++++++++++++++++
> > fs/Kconfig | 21 +
> > fs/Makefile | 1
> > fs/fs_context.c | 1
> > fs/mount.h | 26 +
> > fs/mount_notify.c | 178 +++++++
> > fs/namespace.c | 18 +
> > fs/super.c | 116 ++++
> > include/linux/dcache.h | 1
> > include/linux/fs.h | 77 +++
> > include/linux/key.h | 4
> > include/linux/syscalls.h | 4
> > include/linux/watch_queue.h | 87 +++
> > include/uapi/linux/keyctl.h | 1
> > include/uapi/linux/watch_queue.h | 156 ++++++
> > kernel/sys_ni.c | 6
> > mm/interval_tree.c | 2
> > mm/memory.c | 1
> > samples/Kconfig | 6
> > samples/Makefile | 2
> > samples/watch_queue/Makefile | 9
> > samples/watch_queue/watch_test.c | 232 +++++++++
> > security/keys/Kconfig | 10
> > security/keys/compat.c | 3
> > security/keys/gc.c | 5
> > security/keys/internal.h | 29 +
> > security/keys/key.c | 37 +
> > security/keys/keyctl.c | 90 +++
> > security/keys/keyring.c | 17 -
> > security/keys/request_key.c | 4
> > 36 files changed, 2332 insertions(+), 25 deletions(-)
> > create mode 100644 Documentation/watch_queue.rst
> > create mode 100644 drivers/misc/watch_queue.c
> > create mode 100644 fs/mount_notify.c
> > create mode 100644 include/linux/watch_queue.h
> > create mode 100644 include/uapi/linux/watch_queue.h
> > create mode 100644 samples/watch_queue/Makefile
> > create mode 100644 samples/watch_queue/watch_test.c
> >
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications
From: Ian Kent @ 2018-07-24 0:37 UTC (permalink / raw)
To: Casey Schaufler, David Howells, viro
Cc: linux-fsdevel, linux-kernel, keyrings, linux-security-module
In-Reply-To: <675e5c24-36ef-4cc5-846c-1414c1195d85@schaufler-ca.com>
On Mon, 2018-07-23 at 09:31 -0700, Casey Schaufler wrote:
> On 7/23/2018 8:25 AM, David Howells wrote:
> > Hi Al,
> >
> > Here's a set of patches to add a general variable-length notification queue
> > concept and to add sources of events for:
>
> Overall I approve. The interface is a bit clunky. Some concerns below.
>
> >
> > (1) Mount topology and reconfiguration change events.
>
> With the possibility of unprivileged mounting you're
> going to have to address access control on events.
> If root in a user namespace mounts a filesystem you
> may have a case where the "real" user wouldn't want the
> listener to receive a notification.
>
> > (2) Superblocks EIO, ENOSPC and EDQUOT events (not complete yet).
>
> Here, too. If SELinux (for example) policy says you can't see
> anything on a filesystem you shouldn't get notifications about
> things that happen to that filesystem.
>
> > (3) Key/keyring changes events
>
> And again, I should only get notifications about keys and
> keyrings I have access to.
>
> I expect that you intentionally left off
>
> (4) User injected events
>
> at this point, but it's an obvious extension. That is going
> to require access controls (remember kdbus) so I think you'd
> do well to design them in now rather than have some security
> module hack like me come along later and "fix" it.
I thought mount name space should be considered too even
though I wasn't considering the cloning of file handles
into a user mount name space.
But can this happen in other ways besides user mount name
space creation (I'm fishing here)?
And nsenter(1) doesn't require an exec for anything other
than a pid name space change so a forced close on exec
wouldn't be enough. Or am I mistaken in that nsenter(1)
actually requires running a program (even though the man
page implies it's optional) ...
Are there other consideration my limited understanding is
missing?
>
> > One of the reasons for this is so that we can remove the issue of processes
> > having to repeatedly and regularly scan /proc/mounts, which has proven to be
> > a
> > system performance problem.
> >
> >
> > Design decisions:
> >
> > (1) A misc chardev is used to create and open a ring buffer:
> >
> > fd = open("/dev/watch_queue", O_RDWR);
> >
> > which is then configured and mmap'd into userspace:
> >
> > ioctl(fd, IOC_WATCH_QUEUE_SET_SIZE, BUF_SIZE);
> > ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter);
> > buf = mmap(NULL, BUF_SIZE * page_size, PROT_READ | PROT_WRITE,
> > MAP_SHARED, fd, 0);
> >
> > The fd cannot be read or written (though there is a facility to use
> > write
> > to inject records for debugging) and userspace just pulls data directly
> > out of the buffer.
> >
> > (2) The ring index pointers are stored inside the ring and are thus
> > accessible to userspace. Userspace should only update the tail pointer
> > and never the head pointer or risk breaking the buffer. The kernel
> > checks that the pointers appear valid before trying to use them. A
> > 'skip' record is maintained around the pointers.
> >
> > (3) poll() can be used to wait for data to appear in the buffer.
> >
> > (4) Records in the buffer are binary, typed and have a length so that they
> > can be of varying size.
> >
> > This means that multiple heterogeneous sources can share a common
> > buffer. Tags may be specified when a watchpoint is created to help
> > distinguish the sources.
> >
> > (5) The queue is reusable as there are 16 million types available, of which
> > I've used 4, so there is scope for others to be used.
> >
> > (6) Records are filterable as types have up to 256 subtypes that can be
> > individually filtered. Other filtration is also available.
> >
> > (7) Each time the buffer is opened, a new buffer is created - this means
> > that
> > there's no interference between watchers.
> >
> > (8) When recording a notification, the kernel will not sleep, but will
> > rather
> > mark a queue as overrun if there's insufficient space, thereby avoiding
> > userspace causing the kernel to hang.
> >
> > (9) The 'watchpoint' should be specific where possible, meaning that you
> > specify the object that you want to watch.
> >
> > (10) The buffer is created and then watchpoints are attached to it, using
> > one
> > of:
> >
> > keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fd, 0x01);
> > mount_notify(AT_FDCWD, "/", 0, fd, 0x02);
> > sb_notify(AT_FDCWD, "/mnt", 0, fd, 0x03);
> >
> > where in all three cases, fd indicates the queue and the number after
> > is
> > a tag between 0 and 255.
> >
> > (11) The watch must be removed if either the watch buffer is destroyed or
> > the
> > watched object is destroyed.
> >
> >
> > Things I want to avoid:
> >
> > (1) Introducing features that make the core VFS dependent on the network
> > stack or networking namespaces (ie. usage of netlink).
> >
> > (2) Dumping all this stuff into dmesg and having a daemon that sits there
> > parsing the output and distributing it as this then puts the
> > responsibility for security into userspace and makes handling
> > namespaces
> > tricky. Further, dmesg might not exist or might be inaccessible inside
> > a
> > container.
> >
> > (3) Letting users see events they shouldn't be able to see.
> >
> >
> > Further things that need to be done:
> >
> > (1) fsinfo() syscall needs to find superblocks by ID as well as by path so
> > that it can query a superblock for information without the need to try
> > and work out how to reach it - if the calling process even can.
> >
> > (2) A mount_info() syscall is needed that can enumerate all the children of
> > a
> > mount. This is necessary because mountpoints can hide each other by
> > stacking, so paths are not unique keys. This will require the ability
> > to
> > look up a mount by ID. This avoids the need to parse /proc/mounts.
> >
> > (3) A keyctl call is needed to allow a watch on a keyring to be extended to
> > "children" of that keyring, such that the watch is removed from the
> > child
> > if it is unlinked from the keyring.
> >
> > (4) A global superblock event queue maybe?
> >
> > (5) Propagating watches to child superblock over automounts?
> >
> >
> > The patches can be found here also:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h
> > =notifications
> >
> > David
> > ---
> > David Howells (5):
> > General notification queue with user mmap()'able ring buffer
> > KEYS: Add a notification facility
> > vfs: Add a mount-notification facility
> > vfs: Add superblock notifications
> > Add sample notification program
> >
> >
> > Documentation/security/keys/core.rst | 59 ++
> > Documentation/watch_queue.rst | 305 ++++++++++++
> > arch/x86/entry/syscalls/syscall_32.tbl | 2
> > arch/x86/entry/syscalls/syscall_64.tbl | 2
> > drivers/misc/Kconfig | 9
> > drivers/misc/Makefile | 1
> > drivers/misc/watch_queue.c | 835
> > ++++++++++++++++++++++++++++++++
> > fs/Kconfig | 21 +
> > fs/Makefile | 1
> > fs/fs_context.c | 1
> > fs/mount.h | 26 +
> > fs/mount_notify.c | 178 +++++++
> > fs/namespace.c | 18 +
> > fs/super.c | 116 ++++
> > include/linux/dcache.h | 1
> > include/linux/fs.h | 77 +++
> > include/linux/key.h | 4
> > include/linux/syscalls.h | 4
> > include/linux/watch_queue.h | 87 +++
> > include/uapi/linux/keyctl.h | 1
> > include/uapi/linux/watch_queue.h | 156 ++++++
> > kernel/sys_ni.c | 6
> > mm/interval_tree.c | 2
> > mm/memory.c | 1
> > samples/Kconfig | 6
> > samples/Makefile | 2
> > samples/watch_queue/Makefile | 9
> > samples/watch_queue/watch_test.c | 232 +++++++++
> > security/keys/Kconfig | 10
> > security/keys/compat.c | 3
> > security/keys/gc.c | 5
> > security/keys/internal.h | 29 +
> > security/keys/key.c | 37 +
> > security/keys/keyctl.c | 90 +++
> > security/keys/keyring.c | 17 -
> > security/keys/request_key.c | 4
> > 36 files changed, 2332 insertions(+), 25 deletions(-)
> > create mode 100644 Documentation/watch_queue.rst
> > create mode 100644 drivers/misc/watch_queue.c
> > create mode 100644 fs/mount_notify.c
> > create mode 100644 include/linux/watch_queue.h
> > create mode 100644 include/uapi/linux/watch_queue.h
> > create mode 100644 samples/watch_queue/Makefile
> > create mode 100644 samples/watch_queue/watch_test.c
> >
> >
>
>
^ permalink raw reply
* [PATCH] USB: option: add support for DW5821e
From: Aleksander Morgado @ 2018-07-23 23:34 UTC (permalink / raw)
To: johan; +Cc: gregkh, bjorn, linux-usb, Aleksander Morgado, stable
The device exposes AT, NMEA and DIAG ports in both USB configurations.
The patch explicitly ignores interfaces 0 and 1, as they're bound to
other drivers already; and also interface 6, which is a GNSS interface
for which we don't have a driver yet.
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 18 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
---
drivers/usb/serial/option.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 664e61f16b6a..0215b70c4efc 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -196,6 +196,8 @@ static void option_instat_callback(struct urb *urb);
#define DELL_PRODUCT_5800_V2_MINICARD_VZW 0x8196 /* Novatel E362 */
#define DELL_PRODUCT_5804_MINICARD_ATT 0x819b /* Novatel E371 */
+#define DELL_PRODUCT_5821E 0x81d7
+
#define KYOCERA_VENDOR_ID 0x0c88
#define KYOCERA_PRODUCT_KPC650 0x17da
#define KYOCERA_PRODUCT_KPC680 0x180a
@@ -1030,6 +1032,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5800_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5800_V2_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5804_MINICARD_ATT, 0xff, 0xff, 0xff) },
+ { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5821E),
+ .driver_info = RSVD(0) | RSVD(1) | RSVD(6) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) }, /* ADU-E100, ADU-310 */
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
--
2.18.0
^ permalink raw reply related
* [PATCH] Documentation/diff-options: explain different diff algorithms
From: Stefan Beller @ 2018-07-24 0:36 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
As a user I wondered what the diff algorithms are about. Offer at least
a basic explanation on the differences of the diff algorithms.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Documentation/diff-options.txt | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index f466600972f..0d765482027 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -94,16 +94,34 @@ diff" algorithm internally.
Choose a diff algorithm. The variants are as follows:
+
--
-`default`, `myers`;;
- The basic greedy diff algorithm. Currently, this is the default.
`minimal`;;
- Spend extra time to make sure the smallest possible diff is
- produced.
+ A diff as produced by the basic greedy algorithm described in
+ link:http://www.xmailserver.org/diff2.pdf[An O(ND) Difference Algorithm and its Variations]
+`default`, `myers`;;
+ The same algorithm as `minimal`, extended with a heuristic to
+ reduce extensive searches. Currently, this is the default.
`patience`;;
- Use "patience diff" algorithm when generating patches.
+ Use "patience diff" algorithm when generating patches. This
+ matches the longest common subsequence of unique lines on
+ both sides, recursively. It obtained its name by the way the
+ longest subsequence is found, as that is a byproduct of the
+ patience sorting algorithm. If there are no unique lines left
+ it falls back to `myers`. Empirically this algorithm produces
+ a more readable output for code, but it does not garantuee
+ the shortest output.
`histogram`;;
- This algorithm extends the patience algorithm to "support
- low-occurrence common elements".
+ This algorithm re-implements the `patience` algorithm with
+ "support of low-occurrence common elements" and only picks
+ one element of the LCS for the recursion. It is often the
+ fastest, but in cornercases (when there are many longest
+ common subsequences of the same length) it produces bad
+ results as seen in:
+
+ seq 1 100 >one
+ echo 99 > two
+ seq 1 2 98 >>two
+ git diff --no-index --histogram one two
+
--
+
For instance, if you configured diff.algorithm variable to a
--
2.18.0.345.g5c9ce644c3-goog
^ permalink raw reply related
* Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface
From: Bjorn Andersson @ 2018-07-24 0:35 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, David Lechner, Baolin Wang, Mark Brown,
Linux LED Subsystem, LKML
In-Reply-To: <20180716215616.GB10734@amd>
On Mon 16 Jul 14:56 PDT 2018, Pavel Machek wrote:
> Hi!
>
> > >>>echo pattern > trigger
> > >>>echo "1 2 3 4 5 6 7 8" > somewhere
> > >>
> > >>s/somewhere/pattern/
> > >>
> > >>pattern trigger should create "pattern" file similarly how ledtrig-timer
> > >>creates delay_{on|off} files.
> > >>
> > >
> > >I don't think this is the best way. For example, if you want more than one
> > >LED to have the same pattern, then the patterns will not be synchronized
> > >between the LEDs. The same things happens now with many of the existing
> > >triggers. For example, if I have two LEDs side-by-side using the heartbeat
> > >trigger, they may blink at the same time or they may not, which is not
> > >very nice. I think we can make something better.
>
> Yes, synchronization would be nice -- it is really a must for RGB LEDs
> -- but I believe it is too much to ask from Baolin at the moment.
>
In my work on the Qualcomm LPG (which I should finish up and resend) I
described the RGB as a single LED, with the color configured by Pavel's
suggested HSV interface. This single LED would be given one pattern.
This works fine for the typical use cases we've seen so far, but would
not be enough to describe transitions between colors.
I believe that a reasonable solution to this would be to extend the
pattern to allow each value in the list to contain data for more than
one channel - something that should be reasonable to add on top of this
suggestion.
> > It is virtually impossible to enforce synchronous blinking for the
> > LEDs driven by different hardware due to:
> >
> > - different hardware means via which brightness is set (MMIO, I2C, SPI,
> > PWM and other pulsed fashion based protocols),
> > - the need for deferring brightness setting to a workqueue task to
> > allow for setting LED brightness from atomic context,
> > - contention on locks
>
> I disagree here. Yes, it would be hard to synchronize blinking down to
> microseconds, but it would be easy to get synchronization right down
> to miliseconds and humans will not be able to tell the difference.
>
I like the HSV approach for exposing multi color LEDs and we should be
able to provide a "virtual" LED that groups some number of LEDs into
one, to represent this use case when the hardware doesn't do directly.
In such cases it would work quite weel to use the proposed pattern
interface for setting the pattern of this virtual LED and having it
cascade the pattern into the individual LEDs and then start them at
about the same time...
> > For the LEDs driven by the same chip it would make more sense
> > to allow for synchronization, but it can be achieved on driver
> > level, with help of some subsystem level interface to indicate
> > which LEDs should be synchronized.
> >
> > However, when we start to pretend that we can synchronize the
> > devices, we must answer how accurate we can be. The accuracy
> > will decrease as blink frequency rises. We'd need to define
> > reliability limit.
>
> We don't need _that_ ammount of overengineering. We just need to
> synchronize them well enough :-).
>
> > We've had few attempts of approaching the subject of synchronized
> > blinking but none of them proved to be good enough to be merged.
>
> I'm sure interested person could do something like that in less than
> two weeks fulltime... It is not rocket science, just a lot of work in
> kernel...
>
With the Qualcomm LPG driver I expect the hardware description to group
the channels of a RGB and as such the driver will synchronize the
pattern execution when the output is enabled.
> But patterns are few years overdue and I believe we should not delay
> them any further.
>
Sorry for not prioritizing reworking this patch based on your suggestion
of describing it as a trigger, I still think this sounds reasonable.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver
From: Paul Burton @ 2018-07-24 0:34 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <20180721191358.13952-4-hauke@hauke-m.de>
Hi Hauke,
On Sat, Jul 21, 2018 at 09:13:57PM +0200, Hauke Mehrtens wrote:
> diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
> index e0af39b33e28..c704312ef7d5 100644
> --- a/arch/mips/lantiq/xway/sysctrl.c
> +++ b/arch/mips/lantiq/xway/sysctrl.c
> @@ -536,7 +536,7 @@ void __init ltq_soc_init(void)
> clkdev_add_pmu(NULL, "ahb", 1, 0, PMU_AHBM | PMU_AHBS);
>
> clkdev_add_pmu("1da00000.usif", "NULL", 1, 0, PMU_USIF);
> - clkdev_add_pmu("1e108000.eth", NULL, 0, 0,
> + clkdev_add_pmu("1e10b308.eth", NULL, 0, 0,
> PMU_SWITCH | PMU_PPE_DPLUS | PMU_PPE_DPLUM |
> PMU_PPE_EMA | PMU_PPE_TC | PMU_PPE_SLL01 |
> PMU_PPE_QSB | PMU_PPE_TOP);
Is this intentional?
Why is it needed? Was the old address wrong? Does it change anything
functionally?
If it is needed it seems like a separate change - unless there's some
reason it's tied to adding this driver?
Should this really apply only to the lantiq,vr9 case or also to the
similar lantiq,grx390 & lantiq,ar10 paths?
Whatever the answers to these questions it would be good to include them
in the commit message.
Thanks,
Paul
^ permalink raw reply
* [PATCH] qmi_wwan: fix interface number for DW5821e production firmware
From: Aleksander Morgado @ 2018-07-23 23:31 UTC (permalink / raw)
To: bjorn; +Cc: davem, netdev, linux-usb, Aleksander Morgado, stable
The original mapping for the DW5821e was done using a development
version of the firmware. Confirmed with the vendor that the final
USB layout ends up exposing the QMI control/data ports in USB
config #1, interface #0, not in interface #1 (which is now a HID
interface).
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
Fixes: e7e197edd09c25 ("qmi_wwan: add support for the Dell Wireless 5821e module")
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8fac8e132c5b..0ed06d670a5f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1246,7 +1246,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)}, /* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
- {QMI_FIXED_INTF(0x413c, 0x81d7, 1)}, /* Dell Wireless 5821e */
+ {QMI_FIXED_INTF(0x413c, 0x81d7, 0)}, /* Dell Wireless 5821e */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
{QMI_FIXED_INTF(0x03f0, 0x9d1d, 1)}, /* HP lt4120 Snapdragon X5 LTE */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
--
2.18.0
^ permalink raw reply related
* Re: [PATCH RFC] debugobjects: Make stack check warning more informative
From: Waiman Long @ 2018-07-24 0:33 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: kernel-team, Thomas Gleixner, Yang Shi, Arnd Bergmann, astrachan
In-Reply-To: <20180723212531.202328-1-joel@joelfernandes.org>
On 07/23/2018 05:25 PM, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
>
> Recently we debugged an issue where debugobject tracking was telling
> us of an annotation issue. Turns out the issue was due to the object in
> concern being on a different stack which was due to another issue.
>
> Discussing with tglx, he suggested printing the pointers and the
> location of the stack for the currently running task. This helped find
> the object was on the wrong stack. I turned the resulting patch into
> something upstreamable, so that the error message is more informative
> and can help in debugging for similar issues in the future.
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> lib/debugobjects.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index 994be4805cec..24c1df0d7466 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -360,9 +360,12 @@ static void debug_object_is_on_stack(void *addr, int onstack)
>
> limit++;
> if (is_on_stack)
> - pr_warn("object is on stack, but not annotated\n");
> + pr_warn("object %p is on stack %p, but NOT annotated.\n", addr,
> + task_stack_page(current));
> else
> - pr_warn("object is not on stack, but annotated\n");
> + pr_warn("object %p is NOT on stack %p, but annotated.\n", addr,
> + task_stack_page(current));
> +
> WARN_ON(1);
> }
>
Acked-by: Waiman Long <longman@redhat.com>
^ permalink raw reply
* 答复：一网打尽晦涩难懂的贸易知识和制度设计
From: 崔女士 @ 2018-07-24 0:33 UTC (permalink / raw)
To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw
亲：linux-nvdimm
07 详...情···阅...读···附...件
8:33:34
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [Fuego] [PATCH] busybox: add support for command head/hexdump/hostname/id/ifconfig/install
From: Tim.Bird @ 2018-07-24 0:31 UTC (permalink / raw)
To: Tim.Bird, wangmy, fuego
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF7C1B5810@USCULXMSG01.am.sony.com>
> -----Original Message-----
> From Tim.Bird@sony.com
> > +echo "This is the 1st line.">test_dir/test1
> > +echo "This is the 2nd line.">>test_dir/test1
> > +echo "This is the 3rd line.">>test_dir/test1
That comment about the space was supposed to go here.
That is, put a space before the '>' or '>>' in the above lines.
> > +busybox head -n 2 test_dir/test1 > log
> Please use a space before the redirection operator.
>
^ permalink raw reply
* Re: In-Band Firmware Update
From: Sai Dasari @ 2018-07-24 0:13 UTC (permalink / raw)
To: Vernon Mauery, Patrick Venture; +Cc: OpenBMC Maillist
In-Reply-To: <20180723221837.GI105329@mauery>
On 7/23/18, 3:19 PM, "openbmc on behalf of Vernon Mauery" <openbmc-bounces+sdasari=fb.com@lists.ozlabs.org on behalf of vernon.mauery@linux.intel.com> wrote:
On 23-Jul-2018 11:13 AM, Patrick Venture wrote:
>I've started to implement the host-tool outside of google3, and
>started splitting up the OEM handler that corresponds with it.
>However, firstly, I've submitted the design for the protocol for
>review, please let me know if you're interested and I'll add you to
>the review. IIRC, there was at least one interested party outside of
>us.
I am interested in coming up with a common (OpenBMC OEM level) set of
Firmware NetFn commands that will allow all users of OpenBMC to be able
to use common, open-source utilities to do firmware updates. If they are
IPMI commands, this would include in-band (with KCS/BT for
command/control and USB for transfer) or out-of-band (over RMCP+).
Rather than use the OEM NetFn, for firmware updates, we should be using
the Firmware NetFn. The entire Firmware NetFn is considered to be OEM
per the IPMI spec. I would propose that we simply provide a common
implementation for OpenBMC (as a provider library, of course, so it
could be replaced if a downstream OEM doesn't want it).
Any thoughts on reusing/leveraging the PICMG's hpm spec @ https://www.picmg.org/openstandards/hardware-platform-management/ .
One of the benefit would be the standard 'ipmitool' has native support for the update and changes are limited to BMC f/w.
On a downside, the firmware binary has to be repackaged as .hpm format for this protocol to do some preparation steps as it support multiple f/w components in a single package.
--Vernon
^ permalink raw reply
* Re: [PATCH 2/2 v2] Add support for CPCAP regulators on Tegra devices.
From: Dmitry Osipenko @ 2018-07-24 0:27 UTC (permalink / raw)
To: Peter Geis
Cc: broonie, lgirdwood, robh+dt, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <20180723193848.32491-3-pgwipeout@gmail.com>
On Monday, 23 July 2018 22:38:48 MSK Peter Geis wrote:
> Added support for the CPCAP power management regulator functions on
> Tegra devices.
> Added sw2_sw4 value tables, which provide power to the Tegra core and
> aux devices.
> Added the Tegra init tables and device tree compatibility match.
>
> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> ---
> .../bindings/regulator/cpcap-regulator.txt | 1 +
> drivers/regulator/cpcap-regulator.c | 80 +++++++++++++++++++
> 2 files changed, 81 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt index
> 675f4437ce92..3e2d33ab1731 100644
> --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> @@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
> Requires node properties:
> - "compatible" value one of:
> "motorola,cpcap-regulator"
> + "motorola,tegra-cpcap-regulator"
> "motorola,mapphone-cpcap-regulator"
>
> Required regulator properties:
> diff --git a/drivers/regulator/cpcap-regulator.c
> b/drivers/regulator/cpcap-regulator.c index c0b1e04bd90f..cb3774be445d
> 100644
> --- a/drivers/regulator/cpcap-regulator.c
> +++ b/drivers/regulator/cpcap-regulator.c
> @@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
> { /* sentinel */ },
> };
>
> +static struct cpcap_regulator tegra_regulators[] = {
> + CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_SW1_SEL, unknown_val_tbl,
> + 0, 0, 0, 0, 0, 0),
> + CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
> + 0xf00, 0x7f, 0, 0x800, 0, 120),
> + CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_SW3_SEL, unknown_val_tbl,
> + 0, 0, 0, 0, 0, 0),
> + CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
> + 0xf00, 0x7f, 0, 0x900, 0, 100),
> + CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_SW5_SEL, sw5_val_tbl,
> + 0x2a, 0, 0, 0x22, 0, 0),
> + CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_SW6_SEL, unknown_val_tbl,
> + 0, 0, 0, 0, 0, 0),
> + CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
> + 0x87, 0x30, 4, 0x7, 0, 420),
> + CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
> + 0x47, 0x10, 4, 0x7, 0, 350),
> + CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
> + 0x87, 0x30, 4, 0x3, 0, 420),
> + CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
> + 0x87, 0x30, 4, 0x5, 0, 420),
> + CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
> + 0x80, 0xf, 0, 0x80, 0, 420),
> + CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
> + 0x17, 0, 0, 0x2, 0, 0),
> + CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
> + CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
> + 0x87, 0x38, 3, 0x2, 0, 420),
> + CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
> + 0x43, 0x18, 3, 0x1, 0, 420),
> + CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
> + 0xac, 0x2, 1, 0xc, 0, 10),
> + CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
> + 0x23, 0x8, 3, 0x3, 0, 10),
> + CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
> + 0x23, 0x8, 3, 0x3, 0, 420),
> + CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
> + 0x47, 0x10, 4, 0x5, 0, 420),
> + CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
> + 0x20c, 0xc0, 6, 0x8, 0, 420),
> + CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
> + 0xffff, vsim_val_tbl,
> + 0x23, 0x8, 3, 0x3, 0, 420),
> + CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
> + 0xffff, vsimcard_val_tbl,
> + 0x1e80, 0x8, 3, 0x1e00, 0, 420),
> + CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
> + 0x1, 0xc, 2, 0, 0x1, 500),
> + CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
> + CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
> + 0x11c, 0x40, 6, 0xc, 0, 0),
> + CPCAP_REG(VAUDIO, CPCAP_REG_VAUDIOC, CPCAP_REG_ASSIGN4,
> + CPCAP_BIT_VAUDIO_SEL, vaudio_val_tbl,
> + 0x16, 0x1, 0, 0x4, 0, 0),
> + { /* sentinel */ },
> +};
> +
> static const struct of_device_id cpcap_regulator_id_table[] = {
> {
> .compatible = "motorola,cpcap-regulator",
> @@ -420,6 +496,10 @@ static const struct of_device_id
> cpcap_regulator_id_table[] = { .compatible =
> "motorola,mapphone-cpcap-regulator",
> .data = omap4_regulators,
> },
> + {
> + .compatible = "motorola,tegra-cpcap-regulator",
> + .data = tegra_regulators,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, cpcap_regulator_id_table);
Are those cpcap_regulator values really common for all Tegra's? Probably
better to name the DT compatible like "motorola,xoom-cpcap-regulator" or
"motorola,mz602-cpcap-regulator".
The DT binding documentation should be updated with the new compatible value
in the Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
^ permalink raw reply
* Re: linux-next: build warning after merge of the arm64 tree
From: AKASHI Takahiro @ 2018-07-24 0:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Catalin Marinas, Will Deacon, Linux-Next Mailing List,
Linux Kernel Mailing List, Ard Biesheuvel
In-Reply-To: <20180724090545.2270d975@canb.auug.org.au>
On Tue, Jul 24, 2018 at 09:05:45AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the arm64 tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
Where can I find this specific branch?
> drivers/acpi/Kconfig:6:error: recursive dependency detected!
> drivers/acpi/Kconfig:6: symbol ACPI depends on EFI
My patch created an additional dependency like:
menu ACPI
...
depends on IA64 || X86 || (ARM64 && EFI)
> arch/x86/Kconfig:1920: symbol EFI depends on ACPI
So I don't understand why this change makes a warning on x86_64 build.
Is this a real recursive dependency?
Thanks,
-Takahiro AKASHI
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
>
> Introduced by commit
>
> 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply
* Re: [PATCH bpf] bpf: btf: Ensure the member->offset is in the right order
From: Daniel Borkmann @ 2018-07-23 23:22 UTC (permalink / raw)
To: Yonghong Song, Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <0e0a30fe-e1af-681c-2ccd-e9db91d5246f@fb.com>
On 07/23/2018 08:45 PM, Yonghong Song wrote:
> On 7/20/18 5:38 PM, Martin KaFai Lau wrote:
>> This patch ensures the member->offset of a struct
>> is in the correct order (i.e the later member's offset cannot
>> go backward).
>>
>> The current "pahole -J" BTF encoder does not generate something
>> like this. However, checking this can ensure future encoder
>> will not violate this.
>>
>> Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
>> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Acked-by: Yonghong Song <yhs@fb.com>
Applied to bpf, thanks!
^ permalink raw reply
* Re: [PATCH v2] fs: ceph: Adding new return type vm_fault_t
From: Yan, Zheng @ 2018-07-24 0:20 UTC (permalink / raw)
To: Souptick Joarder
Cc: willy, Sage Weil, Ilya Dryomov, Ceph Development, LKML,
ajitn.linux, brajeswar.linux, sabyasachi.linux
In-Reply-To: <20180723160224.GA6942@jordon-HP-15-Notebook-PC>
> On Jul 24, 2018, at 00:02, Souptick Joarder <jrdr.linux@gmail.com> wrote:
>
> Use new return type vm_fault_t for page_mkwrite
> and fault handler.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
> ---
> v2: Fixed kbuild warning
>
> fs/ceph/addr.c | 62 ++++++++++++++++++++++++++++++----------------------------
> 1 file changed, 32 insertions(+), 30 deletions(-)
>
> diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> index 292b3d7..26beebe 100644
> --- a/fs/ceph/addr.c
> +++ b/fs/ceph/addr.c
> @@ -1431,7 +1431,7 @@ static void ceph_restore_sigs(sigset_t *oldset)
> /*
> * vm ops
> */
> -static int ceph_filemap_fault(struct vm_fault *vmf)
> +static vm_fault_t ceph_filemap_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct inode *inode = file_inode(vma->vm_file);
> @@ -1439,8 +1439,9 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
> struct ceph_file_info *fi = vma->vm_file->private_data;
> struct page *pinned_page = NULL;
> loff_t off = vmf->pgoff << PAGE_SHIFT;
> - int want, got, ret;
> + int want, got, err;
> sigset_t oldset;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
>
> ceph_block_sigs(&oldset);
>
> @@ -1452,8 +1453,8 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
> want = CEPH_CAP_FILE_CACHE;
>
> got = 0;
> - ret = ceph_get_caps(ci, CEPH_CAP_FILE_RD, want, -1, &got, &pinned_page);
> - if (ret < 0)
> + err = ceph_get_caps(ci, CEPH_CAP_FILE_RD, want, -1, &got, &pinned_page);
> + if (err < 0)
> goto out_restore;
>
> dout("filemap_fault %p %llu~%zd got cap refs on %s\n",
> @@ -1465,16 +1466,17 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
> ceph_add_rw_context(fi, &rw_ctx);
> ret = filemap_fault(vmf);
> ceph_del_rw_context(fi, &rw_ctx);
> + dout("filemap_fault %p %llu~%zd drop cap refs %s ret %x\n",
> + inode, off, (size_t)PAGE_SIZE,
> + ceph_cap_string(got), ret);
> } else
> - ret = -EAGAIN;
> + err = -EAGAIN;
>
> - dout("filemap_fault %p %llu~%zd dropping cap refs on %s ret %d\n",
> - inode, off, (size_t)PAGE_SIZE, ceph_cap_string(got), ret);
> if (pinned_page)
> put_page(pinned_page);
> ceph_put_cap_refs(ci, got);
>
> - if (ret != -EAGAIN)
> + if (err != -EAGAIN)
> goto out_restore;
>
> /* read inline data */
> @@ -1482,7 +1484,6 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
> /* does not support inline data > PAGE_SIZE */
> ret = VM_FAULT_SIGBUS;
> } else {
> - int ret1;
> struct address_space *mapping = inode->i_mapping;
> struct page *page = find_or_create_page(mapping, 0,
> mapping_gfp_constraint(mapping,
> @@ -1491,32 +1492,32 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
> ret = VM_FAULT_OOM;
> goto out_inline;
> }
> - ret1 = __ceph_do_getattr(inode, page,
> + err = __ceph_do_getattr(inode, page,
> CEPH_STAT_CAP_INLINE_DATA, true);
> - if (ret1 < 0 || off >= i_size_read(inode)) {
> + if (err < 0 || off >= i_size_read(inode)) {
> unlock_page(page);
> put_page(page);
> - if (ret1 < 0)
> - ret = ret1;
> + if (err == -ENOMEM)
> + ret = VM_FAULT_OOM;
> else
> ret = VM_FAULT_SIGBUS;
> goto out_inline;
> }
> - if (ret1 < PAGE_SIZE)
> - zero_user_segment(page, ret1, PAGE_SIZE);
> + if (err < PAGE_SIZE)
> + zero_user_segment(page, err, PAGE_SIZE);
> else
> flush_dcache_page(page);
> SetPageUptodate(page);
> vmf->page = page;
> ret = VM_FAULT_MAJOR | VM_FAULT_LOCKED;
> out_inline:
> - dout("filemap_fault %p %llu~%zd read inline data ret %d\n",
> + dout("filemap_fault %p %llu~%zd read inline data ret %x\n",
> inode, off, (size_t)PAGE_SIZE, ret);
> }
> out_restore:
> ceph_restore_sigs(&oldset);
> - if (ret < 0)
> - ret = (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
> + if (err < 0)
> + ret = vmf_error(err);
>
> return ret;
> }
> @@ -1524,7 +1525,7 @@ static int ceph_filemap_fault(struct vm_fault *vmf)
> /*
> * Reuse write_begin here for simplicity.
> */
> -static int ceph_page_mkwrite(struct vm_fault *vmf)
> +static vm_fault_t ceph_page_mkwrite(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct inode *inode = file_inode(vma->vm_file);
> @@ -1535,8 +1536,9 @@ static int ceph_page_mkwrite(struct vm_fault *vmf)
> loff_t off = page_offset(page);
> loff_t size = i_size_read(inode);
> size_t len;
> - int want, got, ret;
> + int want, got, err;
> sigset_t oldset;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
>
> prealloc_cf = ceph_alloc_cap_flush();
> if (!prealloc_cf)
> @@ -1550,10 +1552,10 @@ static int ceph_page_mkwrite(struct vm_fault *vmf)
> lock_page(page);
> locked_page = page;
> }
> - ret = ceph_uninline_data(vma->vm_file, locked_page);
> + err = ceph_uninline_data(vma->vm_file, locked_page);
> if (locked_page)
> unlock_page(locked_page);
> - if (ret < 0)
> + if (err < 0)
> goto out_free;
> }
>
> @@ -1570,9 +1572,9 @@ static int ceph_page_mkwrite(struct vm_fault *vmf)
> want = CEPH_CAP_FILE_BUFFER;
>
> got = 0;
> - ret = ceph_get_caps(ci, CEPH_CAP_FILE_WR, want, off + len,
> + err = ceph_get_caps(ci, CEPH_CAP_FILE_WR, want, off + len,
> &got, NULL);
> - if (ret < 0)
> + if (err < 0)
> goto out_free;
>
> dout("page_mkwrite %p %llu~%zd got cap refs on %s\n",
> @@ -1590,13 +1592,13 @@ static int ceph_page_mkwrite(struct vm_fault *vmf)
> break;
> }
>
> - ret = ceph_update_writeable_page(vma->vm_file, off, len, page);
> - if (ret >= 0) {
> + err = ceph_update_writeable_page(vma->vm_file, off, len, page);
> + if (err >= 0) {
> /* success. we'll keep the page locked. */
> set_page_dirty(page);
> ret = VM_FAULT_LOCKED;
> }
> - } while (ret == -EAGAIN);
> + } while (err == -EAGAIN);
>
> if (ret == VM_FAULT_LOCKED ||
> ci->i_inline_version != CEPH_INLINE_NONE) {
> @@ -1610,14 +1612,14 @@ static int ceph_page_mkwrite(struct vm_fault *vmf)
> __mark_inode_dirty(inode, dirty);
> }
>
> - dout("page_mkwrite %p %llu~%zd dropping cap refs on %s ret %d\n",
> + dout("page_mkwrite %p %llu~%zd dropping cap refs on %s ret %x\n",
> inode, off, len, ceph_cap_string(got), ret);
> ceph_put_cap_refs(ci, got);
> out_free:
> ceph_restore_sigs(&oldset);
> ceph_free_cap_flush(prealloc_cf);
> - if (ret < 0)
> - ret = (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
> + if (err < 0)
> + ret = vmf_error(err);
> return ret;
> }
>
Applied, Thanks
Yan, Zheng
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 1/4] MIPS: lantiq: Do not enable IRQs in dma open
From: Paul Burton @ 2018-07-24 0:19 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <20180721191358.13952-2-hauke@hauke-m.de>
Hi Hauke,
On Sat, Jul 21, 2018 at 09:13:55PM +0200, Hauke Mehrtens wrote:
> When a DMA channel is opened the IRQ should not get activated
> automatically, this allows it to pull data out manually without the help
> of interrupts. This is needed for a workaround in the vrx200 Ethernet
> driver.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> arch/mips/lantiq/xway/dma.c | 1 -
> drivers/net/ethernet/lantiq_etop.c | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
If you'd like this to go via the netdev tree to keep it with the rest of
the series:
Acked-by: Paul Burton <paul.burton@mips.com>
Though I'd be happier if we didn't have DMA code seemingly used only by
an ethernet driver in arch/mips/ :)
Thanks,
Paul
^ permalink raw reply
* Re: [PATCH 1/5] mfd: rk808: Add RK817 and RK809 support
From: kbuild test robot @ 2018-07-23 23:13 UTC (permalink / raw)
To: Tony Xie
Cc: kbuild-all, heiko, broonie, lee.jones, a.zummo, alexandre.belloni,
sboyd, linux-clk, linux-rtc, linux-arm-kernel, linux-rockchip,
devicetree, linux-kernel, chenjh, xsf, zhangqing, huangtao,
tony.xie
In-Reply-To: <1532315945-1094-2-git-send-email-tony.xie@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Hi Tony,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.18-rc6 next-20180723]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Tony-Xie/mfd-rk808-Add-RK817-and-RK809-support/20180724-040547
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: i386-randconfig-a0-201829 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "pm_power_off_prepare" [drivers/mfd/rk808.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28749 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.