Re: linux-next: Signed-off-by missing for commit in the bluetooth tree
Hi,
On Sat, Dec 30, 2017, Stephen Rothwell wrote:
> On Sat, 30 Dec 2017 10:25:52 +1100 Stephen Rothwell
> wrote:
> > Commit
> >
> > 0a03f98b98c2 ("Bluetooth: Add a new 04ca:3015 QCA_ROME device")
> >
> > is missing a Signed-off-by from its .
> ^
> committer
It was me who originally committed and pushed this to the bluetooth-next
tree, and the commit does have a signed-off-by from me. However, it
looks like Marcel did some reshuffling/rebasing of the tree and now the
commit shows him in the committer field.
Johan
Re: general protection fault in skb_segment
> syzkaller hit the following crash on
> 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
Reproduced with the C reproducer on v4.15-rc1 and mainline
going back at least to v4.8, but not v4.7. SCTP GSO was
introduced in v4.8-rc1, so a patch in this set is likely the starting
point. Indeed crashes at 90017accff61 ("sctp: Add GSO support"),
but not at 90017accff61~4.
The reproducer with its sandbox removed shows this invocation in strace -f
# strace -f ./repro2
[... skipped ...]
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
open("/dev/net/tun", O_RDONLY) = 4
fcntl(4, F_DUPFD, 3)= 5
socket(PF_PACKET, SOCK_RAW|SOCK_CLOEXEC, 8) = 6
ioctl(4, TUNSETIFF, 0x20e63000) = 0
ioctl(3, SIOCSIFFLAGS, {ifr_name="syz0",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI}) = 0
setsockopt(6, SOL_PACKET, 0xf /* PACKET_??? */, [4096], 4) = 0
ioctl(6, SIOCGIFINDEX, {ifr_name="syz0", ifr_index=24}) = 0
bind(6, {sa_family=AF_PACKET, proto=, if24, pkttype=PACKET_HOST,
addr(6)={1, aa00}, 20) = 0
dup2(6, 5) = 5
write(5, "\0\201\1\0\350\367\0\0\3\0E\364\0 \0d\0\0\7\2042\342\0\0\0
\177\0\0\1\0\t"..., 42
where 0xf in setsockopt is PACKET_VNET_HDR
So this is a packet socket writing something that apparently looks
like an SCTP packet, is only 42 bytes long, but has GSO set in its
virtio_net_hdr struct.
It crashes in skb_segment seemingly on a NULL list_skb.
(gdb) list *(skb_segment+0x2a4)
0x8167cc24 is in skb_segment (net/core/skbuff.c:3566).
3561if (hsize < 0)
3562hsize = 0;
3563if (hsize > len || !sg)
3564hsize = len;
3565
3566if (!hsize && i >= nfrags && skb_headlen(list_skb) &&
3567(skb_headlen(list_skb) == len || sg)) {
3568BUG_ON(skb_headlen(list_skb) > len);
3569
3570i = 0;
Likely there is a hidden assumption about SCTP GSO packets that does
not hold for such packets generated by PF_PACKET.
SCTP GSO introduced the GSO_BY_FRAGS mss value, so the code
takes a different path for SCTP packets generated by the SCTP stack.
PF_PACKET does not necessarily set gso_size to GSO_BY_FRAGS, so
does not take the branch that requires list_skb to be non-zero here:
if (unlikely(mss == GSO_BY_FRAGS)) {
len = list_skb->len;
} else {
len = head_skb->len - offset;
if (len > mss)
len = mss;
}
hsize = skb_headlen(head_skb) - offset;
if (hsize < 0)
hsize = 0;
if (hsize > len || !sg)
hsize = len;
if (!hsize && i >= nfrags && skb_headlen(list_skb) &&
(skb_headlen(list_skb) == len || sg)) {
Somewhat tangential, but any PF_PACKET socket can set this
magic gso_size value in its virtio_net_hdr, so if it is assumed to
be an SCTP GSO specific option, setting it for a TCP GSO packet
may also cause unexpected results.
The crash requires a kernel with CONFIG_IP_SCTP enabled.
[PATCH] f2fs: check segment type before recover data
In some case, the node blocks has wrong blkaddr whose segment type is
NODE, e.g., recover inode has missing xattr flag and the blkaddr is in
the xattr range. Since fsck.f2fs does not check the recovery nodes, this
will cause __f2fs_replace_block change the curseg of node and do the
update_sit_entry(sbi, new_blkaddr, 1) with no next_blkoff refresh, as a
result, when recovery process write checkpoint and sync nodes, the
next_blkoff of curseg is used in the segment bit map, then it will
cause f2fs_bug_on. So let's check the segment type before recover data,
and stop recover if it is not in DATA segment.
Signed-off-by: Yunlong Song
---
fs/f2fs/recovery.c | 3 ++-
fs/f2fs/segment.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 7d63faf..e8fee4a 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -478,7 +478,8 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct
inode *inode,
}
/* dest is valid block, try to recover from src to dest */
- if (is_valid_blkaddr(sbi, dest, META_POR)) {
+ if (is_valid_blkaddr(sbi, dest, META_POR) &&
+ is_data_blkaddr(sbi, dest)) {
if (src == NULL_ADDR) {
err = reserve_new_block(&dn);
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 71a2aaa..5c5a215 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -115,6 +115,9 @@
#define SECTOR_TO_BLOCK(sectors) \
((sectors) >> F2FS_LOG_SECTORS_PER_BLOCK)
+#define is_data_blkaddr(sbi, blkaddr) \
+ (IS_DATASEG(get_seg_entry(sbi, GET_SEGNO(sbi, blkaddr))->type))
+
/*
* indicate a block allocation direction: RIGHT and LEFT.
* RIGHT means allocating new sections towards the end of volume.
--
1.8.5.2
Re: [PATCH] futex: use fault_in to avoid infinite loop
Peter,
On Wed, Dec 6, 2017 at 10:40 PM, Peter Zijlstra wrote:
> On Wed, Dec 06, 2017 at 05:04:00PM +0100, Peter Zijlstra wrote:
>> On Wed, Dec 06, 2017 at 10:21:07PM +0800, Cheng Jian wrote:
>> > It will cause softlockup(infinite loop) in kernel
>> > space when we use SYS_set_robust_list in futex which
>> > incoming a misaligned address from user space.
>>
>> Urgh, we should not allow that in the first place.
>>
>> See how get_futex_key() does:
>>
>> if (unlikely(address % sizeof(u32)))
>> return -EINVAL;
>>
>> That same should also be true for the robust list. Using unaligned
>> variables is insane.
>
> Something a little like so perhaps..
>
> ---
> Subject: futex: Sanitize user address in set_robust_list()
>
> Passing in unaligned variables messes up cmpxchg on a whole bunch of
> architectures. Also, not respecting the natural alignment of data
> structures is pretty dumb to begin with.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> include/uapi/asm-generic/errno.h | 1 +
> kernel/futex.c | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/include/uapi/asm-generic/errno.h
> b/include/uapi/asm-generic/errno.h
> index cf9c51ac49f9..4cb80d4ac160 100644
> --- a/include/uapi/asm-generic/errno.h
> +++ b/include/uapi/asm-generic/errno.h
> @@ -119,5 +119,6 @@
> #define ERFKILL132 /* Operation not possible due to
> RF-kill */
>
> #define EHWPOISON 133 /* Memory page has hardware error */
> +#define EMORON 134 /* User did something particularly silly */
>
> #endif
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 76ed5921117a..e2c1a818f88f 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -3262,6 +3262,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
> unsigned int flags,
> SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head,
> size_t, len)
> {
> + unsigned long address = (unsigned long)head;
> +
> if (!futex_cmpxchg_enabled)
> return -ENOSYS;
> /*
> @@ -3270,6 +3272,9 @@ SYSCALL_DEFINE2(set_robust_list, struct
> robust_list_head __user *, head,
> if (unlikely(len != sizeof(*head)))
> return -EINVAL;
>
> + if (unlikely(address % __alignof__(*head)))
> + return -EMORON;
> +
Do we really need to make these sorts of minor insults to user-space
programmers?
Can we make this -EINVAL, please? (EINVAL in the standard error for
misaligned on calls such as mmap(), mremap(), clone(), read(),
write(), seccomp(), shmat(), and **other futex() operations**.)
Thanks,
Michael
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
Re: [PATCH 2/2] Introduce __cond_lock_err
On Wed, Dec 27, 2017 at 03:28:54PM +0100, Luc Van Oostenryck wrote:
> On Fri, Dec 22, 2017 at 04:31:12AM -0800, Matthew Wilcox wrote:
> > On Thu, Dec 21, 2017 at 08:21:20PM -0800, Josh Triplett wrote:
> >
> > While I've got you, I've been looking at some other sparse warnings from
> > this file. There are several caused by sparse being unable to handle
> > the following construct:
> >
> > if (foo)
> > x = NULL;
> > else {
> > x = bar;
> > __acquire(bar);
> > }
> > if (!x)
> > return -ENOMEM;
> >
> > Writing it as:
> >
> > if (foo)
> > return -ENOMEM;
> > else {
> > x = bar;
> > __acquire(bar);
> > }
> >
> > works just fine. ie this removes the warning:
>
> It must be noted that these two versions are not equivalent
> (in the first version, it also returns with -ENOMEM if bar
> is NULL/zero).
They happen to be equivalent in the original; I was providing a simplified
version. Here's the construct sparse can't understand:
dst_pte = pte_alloc_map_lock(dst_mm, dst_pmd, addr, &dst_ptl);
if (!dst_pte)
return -ENOMEM;
with:
#define pte_alloc(mm, pmd, address) \
(unlikely(pmd_none(*(pmd))) && __pte_alloc(mm, pmd, address))
#define pte_offset_map_lock(mm, pmd, address, ptlp) \
({ \
spinlock_t *__ptl = pte_lockptr(mm, pmd); \
pte_t *__pte = pte_offset_map(pmd, address);\
*(ptlp) = __ptl;\
spin_lock(__ptl); \
__pte; \
})
#define pte_alloc_map_lock(mm, pmd, address, ptlp) \
(pte_alloc(mm, pmd, address) ? \
NULL : pte_offset_map_lock(mm, pmd, address, ptlp))
If pte_alloc() succeeds, pte_offset_map_lock() will return non-NULL.
Manually inlining pte_alloc_map_lock() into the caller like so:
if (pte_alloc(dst_mm, dst_pmd, addr)
return -ENOMEM;
dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, addr, ptlp);
causes sparse to not warn.
> > Is there any chance sparse's dataflow analysis will be improved in the
> > near future?
>
> A lot of functions in the kernel have this context imbalance,
> really a lot. For example, any function doing conditional locking
> is a problem here. Happily when these functions are inlined,
> sparse, thanks to its optimizations, can remove some paths and
> merge some others.
> So yes, by adding some smartness to sparse, some of the false
> warnings will be removed, however:
> 1) some __must_hold()/__acquires()/__releases() annotations are
>missing, making sparse's job impossible.
Partly there's a documentation problem here. I'd really like to see a
document explaining how to add sparse annotations to a function which
intentionally does conditional locking. For example, should we be
annotating the function as __acquires, and then marking the exits which
don't acquire the lock with __acquire(), or should we not annotate
the function, and annotate the exits which _do_ acquire the lock as
__release() with a comment like /* Caller will release */
> 2) a lot of the 'false warnings' are not so false because there is
>indeed two possible paths with different lock state
> 3) it has its limits (at the end, giving the correct warning is
>equivalent to the halting problem).
>
> Now, to answer to your question, I'm not aware of any effort that would
> make a significant differences (it would need, IMO, code hoisting &
> value range propagation).
That's fair. I wonder if we were starting from scratch whether we'd
choose to make sparse a GCC plugin today.
Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
On Wed, Dec 27, 2017 at 10:10:34AM +0100, Brice Goglin wrote: > > Perhaps we can enlist /proc/iomem or a similar enumeration interface > > to tell userspace the NUMA node and whether the kernel thinks it has > > better or worse performance characteristics relative to base > > system-RAM, i.e. new IORES_DESC_* values. I'm worried that if we start > > publishing absolute numbers in sysfs userspace will default to looking > > for specific magic numbers in sysfs vs asking the kernel for memory > > that has performance characteristics relative to base "System RAM". In > > other words the absolute performance information that the HMAT > > publishes is useful to the kernel, but it's not clear that userspace > > needs that vs a relative indicator for making NUMA node preference > > decisions. > > Some HPC users will benchmark the machine to discovery actual > performance numbers anyway. > However, most users won't do this. They will want to know relative > performance of different nodes. If you normalize HMAT values by dividing > them with system-RAM values, that's likely OK. If you just say "that > node is faster than system RAM", it's not precise enough. So "this memory has 800% bandwidth of normal" and "this memory has 70% bandwidth of normal"?
[no subject]
Hello ; I have a proposal for you,kindly get back to me soon. Mrs Christy Walton.
Re: [PATCH 11/20] nvmem: meson-efuse: Convert to use devm_nvmem_register()
Hi Andrey,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc5]
[cannot apply to next-20171222]
[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/Andrey-Smirnov/Verbatim-device-names-and-devm_nvmem_-un-register/20171230-114930
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> drivers/nvmem/meson-efuse.c:72:12: error: 'meson_efuse_remove' undeclared
>> here (not in a function); did you mean 'meson_efuse_probe'?
.remove = meson_efuse_remove,
^~
meson_efuse_probe
vim +72 drivers/nvmem/meson-efuse.c
ad855eae Carlo Caione 2016-08-27 69
ad855eae Carlo Caione 2016-08-27 70 static struct platform_driver
meson_efuse_driver = {
ad855eae Carlo Caione 2016-08-27 71.probe = meson_efuse_probe,
ad855eae Carlo Caione 2016-08-27 @72.remove = meson_efuse_remove,
ad855eae Carlo Caione 2016-08-27 73.driver = {
ad855eae Carlo Caione 2016-08-27 74.name = "meson-efuse",
ad855eae Carlo Caione 2016-08-27 75.of_match_table =
meson_efuse_match,
ad855eae Carlo Caione 2016-08-27 76},
ad855eae Carlo Caione 2016-08-27 77 };
ad855eae Carlo Caione 2016-08-27 78
:: The code at line 72 was first introduced by commit
:: ad855eae6caf0d1dd17bce5bcd8e07759adc9903 nvmem: amlogic: Add Amlogic
Meson EFUSE driver
:: TO: Carlo Caione
:: CC: Kevin Hilman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: About the try to remove cross-release feature entirely by Ingo
On Fri, Dec 29, 2017 at 04:28:51PM +0900, Byungchul Park wrote: > On Thu, Dec 28, 2017 at 10:51:46PM -0500, Theodore Ts'o wrote: > > On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote: > > > > > >(1) The best way: To classify all waiters correctly. > > > > It's really not all waiters, but all *locks*, no? > > Thanks for your opinion. I will add my opinion on you. > > I meant *waiters*. Locks are only a sub set of potential waiters, which > actually cause deadlocks. Cross-release was designed to consider the > super set including all general waiters such as typical locks, > wait_for_completion(), and lock_page() and so on.. I think this is a terminology problem. To me (and, I suspect Ted), a waiter is a subject of a verb while a lock is an object. So Ted is asking whether we have to classify the users, while I think you're saying we have extra objects to classify. I'd be comfortable continuing to refer to completions as locks. We could try to come up with a new object name like waitpoints though? > > In addition, the lock classification system is not documented at all, > > so now you also need someone who understands the lockdep code. And > > since some of these classifications involve transient objects, and > > lockdep doesn't have a way of dealing with transient locks, and has a > > hard compile time limit of the number of locks that it supports, to > > expect a subsystem maintainer to figure out all of the interactions, > > plus figure out lockdep, and work around lockdep's limitations > > seems not realistic. > > I have to think it more to find out how to solve it simply enough to be > acceptable. The only solution I come up with for now is too complex. I want to amplify Ted's point here. How to use the existing lockdep functionality is undocumented. And that's not your fault. We have Documentation/locking/lockdep-design.txt which I'm sure is great for someone who's willing to invest a week understanding it, but we need a "here's how to use it" guide. > > Given that once Lockdep reports a locking violation, it doesn't report > > any more lockdep violations, if there are a large number of false > > positives, people will not want to turn on cross-release, since it > > will report the false positive and then turn itself off, so it won't > > report anything useful. So if no one turns it on because of the false > > positives, how does the bitrot problem get resolved? > > The problems come from wrong classification. Waiters either classfied > well or invalidated properly won't bitrot. I disagree here. As Ted says, it's the interactions between the subsystems that leads to problems. Everything's goig to work great until somebody does something in a way that's never been tried before.
RE: [PATCH v3] igb: Free IRQs when device is hotplugged
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Lyude Paul
> Sent: Tuesday, December 12, 2017 11:32 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Fujinaka, Todd ; Stephen Hemminger
> ; sta...@vger.kernel.org; Kirsher, Jeffrey T
> ; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v3] igb: Free IRQs when device is hotplugged
>
> Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
> hotplugging my kernel would immediately crash due to igb:
>
> [ 680.825801] kernel BUG at drivers/pci/msi.c:352!
> [ 680.828388] invalid opcode: [#1] SMP
> [ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat
> fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi
> sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl
> x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms
> mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis
> psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad
> rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core
> xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
> [ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O
> 4.15.0-rc3Lyude-Test+ #6
> [ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver.
> 01.03 06/09/2017
> [ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> [ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
> [ 680.833271] RSP: 0018:c930fbf0 EFLAGS: 00010286
> [ 680.833761] RAX: 8803405f9c00 RBX: 88033e3d2e40 RCX:
> 002c
> [ 680.834278] RDX: RSI: 00ac RDI:
> 880340be2178
> [ 680.834832] RBP: R08: 880340be1ff0 R09:
> 8803405f9c00
> [ 680.835342] R10: R11: 0040 R12:
> 88033d63a298
> [ 680.835822] R13: 88033d63a000 R14: 0060 R15:
> 880341959000
> [ 680.836332] FS: () GS:88034f44()
> knlGS:
> [ 680.836817] CS: 0010 DS: ES: CR0: 80050033
> [ 680.837360] CR2: 55e64044afdf CR3: 01c09002 CR4:
> 003606e0
> [ 680.837954] Call Trace:
> [ 680.838853] pci_disable_msix+0xce/0xf0
> [ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
> [ 680.840278] igb_remove+0x9d/0x110 [igb]
> [ 680.840764] pci_device_remove+0x36/0xb0
> [ 680.841279] device_release_driver_internal+0x157/0x220
> [ 680.841739] pci_stop_bus_device+0x7d/0xa0
> [ 680.842255] pci_stop_bus_device+0x2b/0xa0
> [ 680.842722] pci_stop_bus_device+0x3d/0xa0
> [ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
> [ 680.843627] trim_stale_devices+0xf3/0x140
> [ 680.844086] trim_stale_devices+0x94/0x140
> [ 680.844532] trim_stale_devices+0xa6/0x140
> [ 680.845031] ? get_slot_status+0x90/0xc0
> [ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
> [ 680.846021] acpiphp_hotplug_notify+0x175/0x200
> [ 680.846581] ? free_bridge+0x100/0x100
> [ 680.847113] acpi_device_hotplug+0x8a/0x490
> [ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
> [ 680.848076] process_one_work+0x182/0x3a0
> [ 680.848543] worker_thread+0x2e/0x380
> [ 680.848963] ? process_one_work+0x3a0/0x3a0
> [ 680.849373] kthread+0x111/0x130
> [ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
> [ 680.850188] ret_from_fork+0x1f/0x30
> [ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b
> 14 0f
> 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49
> 8d b5
> a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
> [ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: c930fbf0
>
> As it turns out, normally the freeing of IRQs that would fix this is called
> inside of the scope of __igb_close(). However, since the device is
> already gone by the point we try to unregister the netdevice from the
> driver due to a hotplug we end up seeing that the netif isn't present
> and thus, forget to free any of the device IRQs.
>
> So: make sure that if we're in the process of dismantling the netdev, we
> always allow __igb_close() to be called so that IRQs may be freed
> normally. Additionally, only allow igb_close() to be called from
> __igb_close() if it hasn't already been called for the given adapter.
>
> Signed-off-by: Lyude Paul
> Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
> Cc: Todd Fujinaka
> Cc: Stephen Hemminger
> Cc: sta...@vger.kernel.org
> ---
> Changes since v2:
> - Remove hunk in __igb_close() that was left over by accident, it's
> not needed
>
> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Tested-by: Aaron Brown
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, Dec 29, 2017 at 11:17:54PM +0100, Philippe Ombredanne wrote: > > As far as I know, none of the licenses explicitly say > > copyright license must be on each file. Just that the distribution of > > source must include the copyright and license statement. Exactly how > > that is done is not explicitly specified. > > This is also my take. What is done here is not much different than > refactoring duplicated code so it leaves in a single place: > > - by "value" at the root in COPYING and in the Documentation. > - by "reference" in the code proper as SPDX ids. > > Therefore essential and common requirements to include the license > text is fulfilled in the kernel. > > Note that there are a few offenders that will need to clean up their > acts as they came up will both long and "un-removable and > un-alterable" crazy legalese blurbs [1] prefix this: > > "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER" > > These will have to be taken care on a case by case basis. These are > pretty stupid and IMHO should have never been allowed to be added to > the kernel in the first place and are ugly warts. It could very well > be that these are not really GPL-compliant notices FWIW: keeping > notices and copyrights is quite different from a restriction of > altering things by moving them around which is exactly what is > happening with the SPDX-ification here. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5 Lustre is now owned by Intel so I suspect that some throat clearing noises in the right direction could easily take care of the issue with those files - Ted
Re: [PATCH v2 2/4] PCI/DPC/AER: Address Concurrency between AER and DPC
On 2017-12-29 23:43, Keith Busch wrote: On Fri, Dec 29, 2017 at 11:30:02PM +0530, p...@codeaurora.org wrote: On 2017-12-29 22:53, Keith Busch wrote: > 2. A DPC event suppresses the error message required for the Linux > AER driver to run. How can AER and DPC run concurrently? I afraid I could not grasp the first line completely. A DPC capable and enabled port discards error messages; the ERR_FATAL or ERR_NONFATAL message required to trigger AER handling won't exist in such a setup. This behavior is defined in the specification 6.2.10 for Downstream Port Containment: When DPC is triggered due to receipt of an uncorrectable error Message, the Requester ID from the Message is recorded in the DPC Error Source ID register and that Message is discarded and not forwarded Upstream. When DPC is triggered by an unmasked uncorrectable error, that error will not be signaled with an uncorrectable error Message, even if otherwise enabled. In my understanding, thiis talks about DPC enabled switch. this case is taken care as well. if you look at patchset-3, when AER is triggered, AER's pci_dev is of endpoint will traverse all the way up until it finds associated DPC service enabled. pdev = pcie_port_upstream_bridge(dev); if AER is not triggered, then at switch level DPC will take care/suppress the msg and entire SW will not come into picture then. But specifically the patches attempts to bring in some sort of coordination and understanding between AER and DPC. as I mentioned in my previous mail. Regards, Oza.
[PATCH net-next 2/2] net: stmmac: Allow debug prints of frame_len/COE
There is no reason not to allow printing the frame_len/COE value and put
that under a check for ETH_FRAME_LEN, drop it so we can see what the
descriptor reports.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0323d672e1c5..d9c98fd810bb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3436,9 +3436,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit,
u32 queue)
if (netif_msg_rx_status(priv)) {
netdev_dbg(priv->dev, "\tdesc: %p [entry %d]
buff=0x%x\n",
p, entry, des);
- if (frame_len > ETH_FRAME_LEN)
- netdev_dbg(priv->dev, "frame size %d,
COE: %d\n",
- frame_len, status);
+ netdev_dbg(priv->dev, "frame size %d, COE:
%d\n",
+ frame_len, status);
}
/* The zero-copy is always used for all the sizes
--
2.14.1
[PATCH net-next 1/2] net: stmmac: Pad ring number with zeroes in display_ring()
Make the printing of the ring number consistent and properly aligned by
padding the ring number with up to 3 zeroes, which covers the maximum
ring size. This makes it a lot easier to see outliers in debug prints.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 7e089bf906b4..2fd8456999f6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -406,7 +406,7 @@ static void dwmac4_display_ring(void *head, unsigned int
size, bool rx)
pr_info("%s descriptor ring:\n", rx ? "RX" : "TX");
for (i = 0; i < size; i++) {
- pr_info("%d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
+ pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
i, (unsigned int)virt_to_phys(p),
le32_to_cpu(p->des0), le32_to_cpu(p->des1),
le32_to_cpu(p->des2), le32_to_cpu(p->des3));
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 2a828a312814..b47cb5c4da51 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -428,7 +428,7 @@ static void enh_desc_display_ring(void *head, unsigned int
size, bool rx)
u64 x;
x = *(u64 *)ep;
- pr_info("%d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
+ pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
i, (unsigned int)virt_to_phys(ep),
(unsigned int)x, (unsigned int)(x >> 32),
ep->basic.des2, ep->basic.des3);
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index db4cee57bb24..ebd9e5e00f16 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -288,7 +288,7 @@ static void ndesc_display_ring(void *head, unsigned int
size, bool rx)
u64 x;
x = *(u64 *)p;
- pr_info("%d [0x%x]: 0x%x 0x%x 0x%x 0x%x",
+ pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x",
i, (unsigned int)virt_to_phys(p),
(unsigned int)x, (unsigned int)(x >> 32),
p->des2, p->des3);
--
2.14.1
[PATCH net-next 0/2] net: stmmac: Couple of debug prints improvements
Hi all, While working on a particular problem, I had to turn on debug prints and found them to be useful, but could deserve some improvements in order to help debug situations. Florian Fainelli (2): net: stmmac: Pad ring number with zeroes in display_ring() net: stmmac: Allow debug prints of frame_len/COE drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +- drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +- drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 2 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++--- 4 files changed, 5 insertions(+), 6 deletions(-) -- 2.14.1
[PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload
When a CPU runs in full dynticks mode, a 1Hz tick remains in order to
keep the scheduler stats alive. However this residual tick is a burden
for bare metal tasks that can't stand no interruption at all, or want
to minimize them.
Adding the boot parameter "isolcpus=nohz_offload" will now outsource
these scheduler ticks to the global workqueue so that a housekeeping CPU
handles that tick remotely.
Note it's still up to the user to affine the global workqueues to the
housekeeping CPUs through /sys/devices/virtual/workqueue/cpumask or
domains isolation.
Signed-off-by: Frederic Weisbecker
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Ingo Molnar
---
kernel/sched/core.c | 88 ++--
kernel/sched/isolation.c | 4 +++
kernel/sched/sched.h | 2 ++
3 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d72d0e9..b964890 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3052,9 +3052,14 @@ void scheduler_tick(void)
*/
u64 scheduler_tick_max_deferment(void)
{
- struct rq *rq = this_rq();
- unsigned long next, now = READ_ONCE(jiffies);
+ struct rq *rq;
+ unsigned long next, now;
+ if (!housekeeping_cpu(smp_processor_id(), HK_FLAG_TICK_SCHED))
+ return ktime_to_ns(KTIME_MAX);
+
+ rq = this_rq();
+ now = READ_ONCE(jiffies);
next = rq->last_sched_tick + HZ;
if (time_before_eq(next, now))
@@ -3062,7 +3067,82 @@ u64 scheduler_tick_max_deferment(void)
return jiffies_to_nsecs(next - now);
}
-#endif
+
+struct tick_work {
+ int cpu;
+ struct delayed_work work;
+};
+
+static struct tick_work __percpu *tick_work_cpu;
+
+static void sched_tick_remote(struct work_struct *work)
+{
+ struct delayed_work *dwork = to_delayed_work(work);
+ struct tick_work *twork = container_of(dwork, struct tick_work, work);
+ int cpu = twork->cpu;
+ struct rq *rq = cpu_rq(cpu);
+ struct rq_flags rf;
+
+ /*
+* Handle the tick only if it appears the remote CPU is running
+* in full dynticks mode. The check is racy by nature, but
+* missing a tick or having one too much is no big deal.
+*/
+ if (!idle_cpu(cpu) && tick_nohz_tick_stopped_cpu(cpu)) {
+ rq_lock_irq(rq, &rf);
+ update_rq_clock(rq);
+ rq->curr->sched_class->task_tick(rq, rq->curr, 0);
+ rq_unlock_irq(rq, &rf);
+ }
+
+ queue_delayed_work(system_unbound_wq, dwork, HZ);
+}
+
+static void sched_tick_start(int cpu)
+{
+ struct tick_work *twork;
+
+ if (housekeeping_cpu(cpu, HK_FLAG_TICK_SCHED))
+ return;
+
+ WARN_ON_ONCE(!tick_work_cpu);
+
+ twork = per_cpu_ptr(tick_work_cpu, cpu);
+ twork->cpu = cpu;
+ INIT_DELAYED_WORK(&twork->work, sched_tick_remote);
+ queue_delayed_work(system_unbound_wq, &twork->work, HZ);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+static void sched_tick_stop(int cpu)
+{
+ struct tick_work *twork;
+
+ if (housekeeping_cpu(cpu, HK_FLAG_TICK_SCHED))
+ return;
+
+ WARN_ON_ONCE(!tick_work_cpu);
+
+ twork = per_cpu_ptr(tick_work_cpu, cpu);
+ cancel_delayed_work_sync(&twork->work);
+}
+#endif /* CONFIG_HOTPLUG_CPU */
+
+int __init sched_tick_offload_init(void)
+{
+ tick_work_cpu = alloc_percpu(struct tick_work);
+ if (!tick_work_cpu) {
+ pr_err("Can't allocate remote tick struct\n");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+#else
+static void sched_tick_start(int cpu) { }
+static void sched_tick_stop(int cpu) { }
+#endif /* CONFIG_NO_HZ_FULL */
#if defined(CONFIG_PREEMPT) && (defined(CONFIG_DEBUG_PREEMPT) || \
defined(CONFIG_PREEMPT_TRACER))
@@ -5713,6 +5793,7 @@ int sched_cpu_starting(unsigned int cpu)
{
set_cpu_rq_start_time(cpu);
sched_rq_cpu_starting(cpu);
+ sched_tick_start(cpu);
return 0;
}
@@ -5724,6 +5805,7 @@ int sched_cpu_dying(unsigned int cpu)
/* Handle pending wakeups and then migrate everything off */
sched_ttwu_pending();
+ sched_tick_stop(cpu);
rq_lock_irqsave(rq, &rf);
if (rq->rd) {
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 264ddcd..c5e7e90a 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include "sched.h"
DEFINE_STATIC_KEY_FALSE(housekeeping_overriden);
EXPORT_SYMBOL_GPL(housekeeping_overriden);
@@ -60,6 +61,9 @@ void __init housekeeping_init(void)
static_branch_enable(&housekeeping_overriden);
+ if (housekeeping_flags & HK_FLAG_TICK_SCHED)
+ sched_tick_o
[PATCH 1/5] sched: Rename init_rq_hrtick to hrtick_rq_init
Do that rename in order to normalize the hrtick namespace.
Signed-off-by: Frederic Weisbecker
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Ingo Molnar
---
kernel/sched/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 644fa2e..d72d0e9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -333,7 +333,7 @@ void hrtick_start(struct rq *rq, u64 delay)
}
#endif /* CONFIG_SMP */
-static void init_rq_hrtick(struct rq *rq)
+static void hrtick_rq_init(struct rq *rq)
{
#ifdef CONFIG_SMP
rq->hrtick_csd_pending = 0;
@@ -351,7 +351,7 @@ static inline void hrtick_clear(struct rq *rq)
{
}
-static inline void init_rq_hrtick(struct rq *rq)
+static inline void hrtick_rq_init(struct rq *rq)
{
}
#endif /* CONFIG_SCHED_HRTICK */
@@ -5955,7 +5955,7 @@ void __init sched_init(void)
rq->last_sched_tick = 0;
#endif
#endif /* CONFIG_SMP */
- init_rq_hrtick(rq);
+ hrtick_rq_init(rq);
atomic_set(&rq->nr_iowait, 0);
}
--
2.7.4
[PATCH 5/5] sched/isolation: Document "nohz_offload" flag
Document the interface to offload the 1Hz scheduler tick in full dynticks mode. Also improve the comment about the existing "nohz" flag in order to differentiate its behaviour. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Christoph Lameter Cc: Luiz Capitulino Cc: Mike Galbraith Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Wanpeng Li Cc: Ingo Molnar --- Documentation/admin-guide/kernel-parameters.txt | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1683107..fcc5fd9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1745,7 +1745,12 @@ specified in the flag list (default: domain): nohz - Disable the tick when a single task runs. + Disable the tick when a single task runs. A residual 1Hz + tick remains to maintain scheduler stats alive. + nohz_offload + Like nohz but the residual 1Hz tick is offloaded to + housekeeping CPUs, leaving the CPU free of any tick if + nothing else requests it. domain Isolate from the general SMP balancing and scheduling algorithms. Note that performing domain isolation this way -- 2.7.4
[PATCH 0/5] isolation: 1Hz residual tick offloading v3
No big change in this row, just a build failure fix on patch 4/5 due to sched_tick_start()/sched_tick_stop() not having off cases. If no more comment arise, I'll do a pull request in a few days. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git timers/0z-v3 HEAD: 4b07980eaca4012852b5f02c2a55b1114c475804 Thanks, Frederic --- Frederic Weisbecker (5): sched: Rename init_rq_hrtick to hrtick_rq_init sched/isolation: Add scheduler tick offloading interface nohz: Allow to check if remote CPU tick is stopped sched/isolation: Residual 1Hz scheduler tick offload sched/isolation: Document "nohz_offload" flag Documentation/admin-guide/kernel-parameters.txt | 7 +- include/linux/sched/isolation.h | 3 +- include/linux/tick.h| 2 + kernel/sched/core.c | 94 +++-- kernel/sched/isolation.c| 10 +++ kernel/sched/sched.h| 2 + kernel/time/tick-sched.c| 7 ++ 7 files changed, 117 insertions(+), 8 deletions(-)
[PATCH 3/5] nohz: Allow to check if remote CPU tick is stopped
This check is racy but provides a good heuristic to determine whether
a CPU may need a remote tick or not.
Signed-off-by: Frederic Weisbecker
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Ingo Molnar
---
include/linux/tick.h | 2 ++
kernel/time/tick-sched.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index f442d1a..417f8d2 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -114,6 +114,7 @@ enum tick_dep_bits {
#ifdef CONFIG_NO_HZ_COMMON
extern bool tick_nohz_enabled;
extern int tick_nohz_tick_stopped(void);
+extern int tick_nohz_tick_stopped_cpu(int cpu);
extern void tick_nohz_idle_enter(void);
extern void tick_nohz_idle_exit(void);
extern void tick_nohz_irq_exit(void);
@@ -124,6 +125,7 @@ extern u64 get_cpu_iowait_time_us(int cpu, u64
*last_update_time);
#else /* !CONFIG_NO_HZ_COMMON */
#define tick_nohz_enabled (0)
static inline int tick_nohz_tick_stopped(void) { return 0; }
+static inline int tick_nohz_tick_stopped_cpu(int cpu) { return 0; }
static inline void tick_nohz_idle_enter(void) { }
static inline void tick_nohz_idle_exit(void) { }
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 99578f0..ad07d6e 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -486,6 +486,13 @@ int tick_nohz_tick_stopped(void)
return __this_cpu_read(tick_cpu_sched.tick_stopped);
}
+int tick_nohz_tick_stopped_cpu(int cpu)
+{
+ struct tick_sched *ts = per_cpu_ptr(&tick_cpu_sched, cpu);
+
+ return ts->tick_stopped;
+}
+
/**
* tick_nohz_update_jiffies - update jiffies when idle was interrupted
*
--
2.7.4
[PATCH 2/5] sched/isolation: Add scheduler tick offloading interface
Add the boot option that will allow us to offload the 1Hz scheduler tick
to the housekeeping CPU.
Signed-off-by: Frederic Weisbecker
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Wanpeng Li
Cc: Ingo Molnar
---
include/linux/sched/isolation.h | 3 ++-
kernel/sched/isolation.c| 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched/isolation.h b/include/linux/sched/isolation.h
index d849431..c831855 100644
--- a/include/linux/sched/isolation.h
+++ b/include/linux/sched/isolation.h
@@ -11,7 +11,8 @@ enum hk_flags {
HK_FLAG_MISC= (1 << 2),
HK_FLAG_SCHED = (1 << 3),
HK_FLAG_TICK= (1 << 4),
- HK_FLAG_DOMAIN = (1 << 5),
+ HK_FLAG_TICK_SCHED = (1 << 5),
+ HK_FLAG_DOMAIN = (1 << 6),
};
#ifdef CONFIG_CPU_ISOLATION
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index b71b436..264ddcd 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -136,6 +136,12 @@ static int __init housekeeping_isolcpus_setup(char *str)
continue;
}
+ if (!strncmp(str, "nohz_offload,", 13)) {
+ str += 13;
+ flags |= HK_FLAG_TICK | HK_FLAG_TICK_SCHED;
+ continue;
+ }
+
if (!strncmp(str, "domain,", 7)) {
str += 7;
flags |= HK_FLAG_DOMAIN;
--
2.7.4
Re: [PATCH] Staging: ncpfs: dir: fixed a bracket coding style issue
On Fri, 29 Dec 2017 15:27:13 -0800 Santha Meena Ramamoorthy wrote: > Fixed a coding style issue. > > Signed-off-by: Santha Meena Ramamoorthy Read the TODO please
Re: 4.14.9 doesn't boot (regression)
On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote:
> (Also, Josh, the oops code should have printed the contents of the
> struct pt_regs at the top of the DF stack. Any idea why it didn't?)
Looking at one of the dumps:
[ 392.774879] NMI backtrace for cpu 0
[ 392.774881] CPU: 0 PID: 1 Comm: init Not tainted 4.14.9-gentoo #1
[ 392.774881] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 392.774882] task: 8802368b8000 task.stack: c900c000
[ 392.774885] RIP: 0010:double_fault+0x0/0x30
[ 392.774886] RSP: :ff527fd0 EFLAGS: 0086
[ 392.774887] RAX: 3fc0 RBX: 0001 RCX:
c101
[ 392.774887] RDX: 8802 RSI: RDI:
ff527f58
[ 392.774887] RBP: R08: R09:
[ 392.774888] R10: R11: R12:
816ae726
[ 392.774888] R13: R14: R15:
[ 392.774889] FS: () GS:88023fc0()
knlGS:
[ 392.774889] CS: 0010 DS: ES: CR0: 80050033
[ 392.774890] CR2: ff526f08 CR3: 000235b48002 CR4:
001606f0
[ 392.774892] Call Trace:
[ 392.774894] <#DF>
[ 392.774897] do_double_fault+0xb/0x140
[ 392.774898]
It should have at least printed the #DF iret frame registers, which I
recently added support for in "x86/unwinder: Handle stack overflows more
gracefully", which is in both 4.14.9 and 4.15-rc5.
I think the missing iret regs are due to a bug in show_trace_log_lvl(),
where if the unwind starts with two regs frames in a row, the second
regs don't get printed.
Alexander, would you mind reproducing again with the below patch? It
should still fail, but this time it should hopefully show another
RIP/RSP/EFLAGS instead of the "do_double_fault+0xb/0x140" line.
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 36b17e0febe8..39a320d077aa 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -103,6 +103,7 @@ void show_trace_log_lvl(struct task_struct *task, struct
pt_regs *regs,
unwind_start(&state, task, regs, stack);
stack = stack ? : get_stack_pointer(task, regs);
+ regs = unwind_get_entry_regs(&state);
/*
* Iterate through the stacks, starting with the current stack pointer.
@@ -120,7 +121,7 @@ void show_trace_log_lvl(struct task_struct *task, struct
pt_regs *regs,
* - hardirq stack
* - entry stack
*/
- for (regs = NULL; stack; stack = PTR_ALIGN(stack_info.next_sp,
sizeof(long))) {
+ for ( ; stack; stack = PTR_ALIGN(stack_info.next_sp, sizeof(long))) {
const char *stack_name;
if (get_stack_info(stack, task, &stack_info, &visit_mask)) {
Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator
Hi Mylène, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.15-rc5 next-20171222] [cannot apply to input/next] [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/Myl-ne-Josserand/sun8i-a83t-Add-touchscreen-support-on-TBS-A711/20171230-091331 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next coccinelle warnings: (new ones prefixed by >>) >> drivers/input/touchscreen/edt-ft5x06.c:1004:2-3: Unneeded semicolon Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] Input: fix semicolon.cocci warnings
From: Fengguang Wu
drivers/input/touchscreen/edt-ft5x06.c:1004:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: 5969d946e8aa ("Input: edt-ft5x06 - Add support for regulator")
CC: Mylène Josserand
Signed-off-by: Fengguang Wu
---
edt-ft5x06.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1001,7 +1001,7 @@ static int edt_ft5x06_ts_probe(struct i2
dev_err(&client->dev, "failed to request regulator: %d\n",
error);
return error;
- };
+ }
if (tsdata->vcc) {
error = regulator_enable(tsdata->vcc);
Re: linux-next: Signed-off-by missing for commit in the tpmdd tree
On Sat, Dec 30, 2017 at 10:32:13AM +1100, Stephen Rothwell wrote:
> Hi Jarkko,
>
> Commit
>
> c01386d6129f ("tpm: Update MAINTAINERS for Jason Gunthorpe")
>
> is missing a Signed-off-by from its committer.
Thanks Stephen,
Jarkko, it started out OK, so you can probably just add it back in?
https://www.spinics.net/lists/linux-integrity/msg00581.html
Jason
[RFC PATCH Resend] ksm: allow dedup all tasks memory
ksm by default working only on memory that added by
madvice().
And only way get that work on other applications:
- Use LD_PRELOAD and libraries
- Patch kernel
Lets use kernel task list in ksm_scan_thread and add logic to allow ksm
import VMA from tasks.
That behaviour controlled by new attribute: mode
I try mimic hugepages attribute, so mode have two states:
- normal - old default behaviour
- always [new] - allow ksm to get tasks vma and try working on that.
To reduce CPU load & tasklist locking time,
ksm try import VMAs from one task per loop.
So add new attribute "mode"
Two passible values:
- normal [default] - ksm use only madvice
- always [new] - ksm will search vma over all processes memory and
add it to the dedup list
Signed-off-by: Timofey Titovets
---
Documentation/vm/ksm.txt | 3 +
mm/ksm.c | 139 ---
2 files changed, 121 insertions(+), 21 deletions(-)
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index 6686bd267dc9..3ba6a558c48e 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -84,6 +84,9 @@ run - set 0 to stop ksmd from running but keep
merged pages,
Default: 0 (must be changed to 1 to activate KSM,
except if CONFIG_SYSFS is disabled)
+mode - set always to allow ksm dedup whole memory
+ set normal to use only madvice [default]
+
use_zero_pages - specifies whether empty pages (i.e. allocated pages
that only contain zeroes) should be treated specially.
When set to 1, empty pages are merged with the kernel
diff --git a/mm/ksm.c b/mm/ksm.c
index 15dd7415f7b3..78ecb62ad7e6 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -276,6 +276,10 @@ static int ksm_nr_node_ids = 1;
static unsigned long ksm_run = KSM_RUN_STOP;
static void wait_while_offlining(void);
+#define KSM_MODE_NORMAL 0
+#define KSM_MODE_ALWAYS1
+static unsigned long ksm_mode = KSM_MODE_NORMAL;
+
static DECLARE_WAIT_QUEUE_HEAD(ksm_thread_wait);
static DEFINE_MUTEX(ksm_thread_mutex);
static DEFINE_SPINLOCK(ksm_mmlist_lock);
@@ -284,6 +288,11 @@ static DEFINE_SPINLOCK(ksm_mmlist_lock);
sizeof(struct __struct), __alignof__(struct __struct),\
(__flags), NULL)
+static inline int ksm_mode_always(void)
+{
+ return (ksm_mode == KSM_MODE_ALWAYS);
+}
+
static int __init ksm_slab_init(void)
{
rmap_item_cache = KSM_KMEM_CACHE(rmap_item, 0);
@@ -2314,17 +2323,91 @@ static void ksm_do_scan(unsigned int scan_npages)
static int ksmd_should_run(void)
{
- return (ksm_run & KSM_RUN_MERGE) && !list_empty(&ksm_mm_head.mm_list);
+ return (ksm_run & KSM_RUN_MERGE) &&
+ (!list_empty(&ksm_mm_head.mm_list) || ksm_mode_always());
+}
+
+
+int ksm_enter(struct mm_struct *mm, unsigned long *vm_flags)
+{
+ int err;
+
+ if (*vm_flags & (VM_MERGEABLE | VM_SHARED | VM_MAYSHARE |
+VM_PFNMAP| VM_IO | VM_DONTEXPAND |
+VM_HUGETLB | VM_MIXEDMAP))
+ return 0;
+
+#ifdef VM_SAO
+ if (*vm_flags & VM_SAO)
+ return 0;
+#endif
+
+ if (!test_bit(MMF_VM_MERGEABLE, &mm->flags)) {
+ err = __ksm_enter(mm);
+ if (err)
+ return err;
+ }
+
+ *vm_flags |= VM_MERGEABLE;
+
+ return 0;
+}
+
+/*
+ * Register all vmas for all processes in the system with KSM.
+ * Note that every call to ksm_madvise, for a given vma, after the first
+ * does nothing but set flags.
+ */
+void ksm_import_task_vma(struct task_struct *task)
+{
+ struct vm_area_struct *vma;
+ struct mm_struct *mm;
+ int error;
+
+ mm = get_task_mm(task);
+ if (!mm)
+ return;
+ down_write(&mm->mmap_sem);
+ vma = mm->mmap;
+ while (vma) {
+ error = ksm_enter(vma->vm_mm, &vma->vm_flags);
+ vma = vma->vm_next;
+ }
+ up_write(&mm->mmap_sem);
+ mmput(mm);
+ return;
}
static int ksm_scan_thread(void *nothing)
{
+ pid_t last_pid = 1;
+ pid_t curr_pid;
+ struct task_struct *task;
+
set_freezable();
set_user_nice(current, 5);
while (!kthread_should_stop()) {
mutex_lock(&ksm_thread_mutex);
wait_while_offlining();
+ if (ksm_mode_always()) {
+ /*
+* import one task's vma per run
+*/
+ read_lock(&tasklist_lock);
+
+ for_each_process(task) {
+ curr_pid = task_pid_nr(task);
+ if (curr_pid == last_pid)
+ break;
+ }
+
+ task = next_task(task);
+
Re: [GIT pull] x86/pti: The real thing
On Thu, Dec 28, 2017 at 12:34 PM, Thomas Gleixner wrote: > > please pull the latest x86-pti-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus > > This is the final set of enabling page table isolation on x86: Ok, after that late MCORE2 scare that held things up, this is now merged in my tree and pushed out. "WorksForMe(tm)". Linus
Re: 4.14.9 doesn't boot (regression)
On Fri, Dec 29, 2017 at 5:00 PM, Linus Torvalds wrote: > > Good. I was not feeling so happy about this bug report, but now I can > firmly just blame the gentoo compiler for having some shit-for-brains > "feature". Looks like I can generate similar bad code with the F26 version of gcc, it's just not enabled by default. So all gentoo did was change the default options. I suspect we should just add a KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) somewhere to the main Makefile, just to make sure. Maybe like the appended? Toralf, Alexander, does this make things JustWork(tm) for you? Linus Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index ac8c441866b7..92b74bcd3c2a 100644 --- a/Makefile +++ b/Makefile @@ -789,6 +789,9 @@ KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign) # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow) +# Make sure -fstack-check isn't enabled (like gentoo apparently did) +KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) + # conserve stack if available KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
Re: 4.14.9 with CONFIG_MCORE2 fails to boot
В Пт, 29/12/2017 в 17:04 -0800, Dave Hansen пишет: > On 12/29/2017 10:46 AM, Alexander Tsoy wrote: > > В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет: > > > Does anyone have the results of build that they can > > > share? (vmlinux, > > > vmlinuz/bzImage, System.map, .config). That, plus a > > > corresponding > > > serial log with an oops would be helpful. > > > > Here you are: > > https://www.dropbox.com/s/yesupqgig3uxf73/linux-4.15-rc5%2B.tar.xz? > > dl=0 > > Alexander, thanks a bunch for the quick turnaround on this. It is > much > appreciated! Dave, it turned out that the issue was caused by -fstack-check. See the thread "4.14.9 doesn't boot (regression)".
[PATCH 01/33] clk_ops: change round_rate() to return unsigned long
Right now it is not possible to return a value larger than LONG_MAX on 32 bit systems. You can pass a rate of ULONG_MAX but can't return anything past LONG_MAX due to the fact both the rounded_rate and negative error codes are represented in the return value of round_rate(). Most implementations either return zero on error or don't return error codes at all. A minority of implementations do return a negative number - typically -EINVAL or -ENODEV. At the higher level then callers of round_rate() typically and rightly check for a value of <= 0. It is possible then to convert round_rate() to an unsigned long return value and change error code indication for the minority from -ERRORCODE to a simple 0. This patch is the first step in making it possible to scale round_rate past LONG_MAX, later patches will change the previously mentioned minority of round_rate() implementations to return zero only on error if those implementations currently return a negative error number. Implementations that do not return an error code of < 0 will be left as-is. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-o...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: linux-...@vger.kernel.org Cc: linux-rpi-ker...@lists.infradead.org Cc: patc...@opensource.cirrus.com Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: freedr...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linux-...@vger.kernel.org --- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c| 4 ++-- arch/arm/mach-omap2/clock2xxx.h | 4 ++-- arch/arm/mach-vexpress/spc.c| 4 ++-- arch/mips/alchemy/common/clock.c| 2 +- drivers/clk/at91/clk-audio-pll.c| 10 ++ drivers/clk/at91/clk-h32mx.c| 5 +++-- drivers/clk/at91/clk-peripheral.c | 6 +++--- drivers/clk/at91/clk-pll.c | 2 +- drivers/clk/at91/clk-plldiv.c | 5 +++-- drivers/clk/at91/clk-smd.c | 5 +++-- drivers/clk/at91/clk-usb.c | 5 +++-- drivers/clk/axs10x/i2s_pll_clock.c | 4 ++-- drivers/clk/axs10x/pll_clock.c | 5 +++-- drivers/clk/bcm/clk-bcm2835.c | 11 ++- drivers/clk/bcm/clk-iproc-asiu.c| 5 +++-- drivers/clk/bcm/clk-iproc-pll.c | 8 drivers/clk/clk-axi-clkgen.c| 5 +++-- drivers/clk/clk-cdce706.c | 15 +-- drivers/clk/clk-cdce925.c | 15 +-- drivers/clk/clk-composite.c | 5 +++-- drivers/clk/clk-cs2000-cp.c | 4 ++-- drivers/clk/clk-divider.c | 5 +++-- drivers/clk/clk-fixed-factor.c | 5 +++-- drivers/clk/clk-fractional-divider.c| 4 ++-- drivers/clk/clk-gemini.c| 5 +++-- drivers/clk/clk-highbank.c | 10 ++ drivers/clk/clk-hsdk-pll.c | 4 ++-- drivers/clk/clk-multiplier.c| 5 +++-- drivers/clk/clk-scpi.c | 8 drivers/clk/clk-si514.c | 4 ++-- drivers/clk/clk-si5351.c| 15 +-- drivers/clk/clk-si570.c | 4 ++-- drivers/clk/clk-stm32f4.c | 15 +-- drivers/clk/clk-u300.c | 4 ++-- drivers/clk/clk-versaclock5.c | 12 ++-- drivers/clk/clk-vt8500.c| 9 + drivers/clk/clk-wm831x.c| 5 +++-- drivers/clk/clk-xgene.c | 9 + drivers/clk/h8300/clk-h8s2678.c | 4 ++-- drivers/clk/hisilicon/clk-hi6220-stub.c | 5 +++-- drivers/clk/hisilicon/clkdivider-hi6220.c | 5 +++-- drivers/clk/imx/clk-busy.c | 5 +++-- drivers/clk/imx/clk-cpu.c | 4 ++-- drivers/clk/imx/clk-fixup-div.c | 5 +++-- drivers/clk/imx/clk-pfd.c | 4 ++-- drivers/clk/imx/clk-pllv2.c | 4 ++-- drivers/clk/imx/clk-pllv3.c | 19 +++ drivers/clk/ingenic/cgu.c | 4 ++-- drivers/clk/ingenic/jz4780-cgu.c| 5 +++-- drivers/clk/mediatek/clk-pll.c | 4 ++-- drivers/clk/meson/clk-audio-divider.c | 6 +++--- drivers/clk/meson/clk-c
[PATCH 02/33] clk: core: update divider_round_rate functions to return unsigned long
Returning a long from round_rate() class functions is rooted in the notion
that we will propagate a negative number on some class of failure to round
a clock rate; however this approach does not scale to 32 bit systems which
legitimately round a clock over LONG_MAX as the returned clock rate is
indistinguishable from an error number.
A better approach is to return zero when we cannot round a clock and
non-zero when we can - thus supporting the full range of the unsigned long
rate input value to round_rate() functions.
Update the signature of divider_round_rate functions to do this now.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/clk-divider.c| 10 ++
include/linux/clk-provider.h | 19 +++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index a26ec7c..e827304 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -332,10 +332,12 @@ static int clk_divider_bestdiv(struct clk_hw *hw, struct
clk_hw *parent,
return bestdiv;
}
-long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
- unsigned long rate, unsigned long *prate,
- const struct clk_div_table *table,
- u8 width, unsigned long flags)
+unsigned long divider_round_rate_parent(struct clk_hw *hw,
+ struct clk_hw *parent,
+ unsigned long rate,
+ unsigned long *prate,
+ const struct clk_div_table *table,
+ u8 width, unsigned long flags)
{
int div;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 79b1d6e..e763d94 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -413,10 +413,12 @@ extern const struct clk_ops clk_divider_ro_ops;
unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
unsigned int val, const struct clk_div_table *table,
unsigned long flags);
-long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
- unsigned long rate, unsigned long *prate,
- const struct clk_div_table *table,
- u8 width, unsigned long flags);
+unsigned long divider_round_rate_parent(struct clk_hw *hw,
+ struct clk_hw *parent,
+ unsigned long rate,
+ unsigned long *prate,
+ const struct clk_div_table *table,
+ u8 width, unsigned long flags);
int divider_get_val(unsigned long rate, unsigned long parent_rate,
const struct clk_div_table *table, u8 width,
unsigned long flags);
@@ -762,10 +764,11 @@ static inline void __clk_hw_set_clk(struct clk_hw *dst,
struct clk_hw *src)
dst->core = src->core;
}
-static inline long divider_round_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long *prate,
- const struct clk_div_table *table,
- u8 width, unsigned long flags)
+static inline unsigned long divider_round_rate(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long *prate,
+ const struct clk_div_table
*table,
+ u8 width, unsigned long flags)
{
return divider_round_rate_parent(hw, clk_hw_get_parent(hw),
rate, prate, table, width, flags);
--
2.7.4
[PATCH 08/33] clk: bcm2835: change bcm2835_pll_rate_from_divisors to return unsigned long
bcm2835_pll_rate_from_divisors() returns a value directly as the return
value to round_rate(). clk_ops->round_rate() has been changed to an
unsigned long so for the sake of completeness and neatness this patch
updates the helper function to return the same data-type.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Eric Anholt
Cc: Stefan Wahren
Cc: Florian Fainelli
Cc: Ray Jui
Cc: Scott Branden
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: Boris Brezillon
Cc: Phil Elwell
Cc: linux-...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/bcm/clk-bcm2835.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index c215dc9..fb2b012 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -541,8 +541,9 @@ static void bcm2835_pll_choose_ndiv_and_fdiv(unsigned long
rate,
*fdiv = div & ((1 << A2W_PLL_FRAC_BITS) - 1);
}
-static long bcm2835_pll_rate_from_divisors(unsigned long parent_rate,
- u32 ndiv, u32 fdiv, u32 pdiv)
+static unsigned long bcm2835_pll_rate_from_divisors(unsigned long parent_rate,
+ u32 ndiv, u32 fdiv,
+ u32 pdiv)
{
u64 rate;
--
2.7.4
[PATCH 09/33] clk: bcm2835: change clk_get_rate() helper return type
bcm2835_pll_rate_from_divisor returns a long but the function calling it
returns an unsigned long. There's no reason to have a type disparity here
so tidy up the return type of bcm2835_pll_rate_from_divisor() from signed
to unsigned long.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Eric Anholt
Cc: Stefan Wahren
Cc: Florian Fainelli
Cc: Ray Jui
Cc: Scott Branden
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: Boris Brezillon
Cc: Phil Elwell
Cc: linux-...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/bcm/clk-bcm2835.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index fb2b012..cde2cf1 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -955,9 +955,9 @@ static u32 bcm2835_clock_choose_div(struct clk_hw *hw,
return div;
}
-static long bcm2835_clock_rate_from_divisor(struct bcm2835_clock *clock,
- unsigned long parent_rate,
- u32 div)
+static unsigned long bcm2835_clock_rate_from_divisor(struct bcm2835_clock
*clock,
+unsigned long parent_rate,
+u32 div)
{
const struct bcm2835_clock_data *data = clock->data;
u64 temp;
--
2.7.4
[PATCH 07/33] clk: axs10x: change i2s_pll_round_rate return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Eugeniy Paltsev
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/axs10x/i2s_pll_clock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c
b/drivers/clk/axs10x/i2s_pll_clock.c
index 061260c..20f7ebf 100644
--- a/drivers/clk/axs10x/i2s_pll_clock.c
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -119,14 +119,14 @@ static unsigned long i2s_pll_round_rate(struct clk_hw
*hw, unsigned long rate,
if (!pll_cfg) {
dev_err(clk->dev, "invalid parent rate=%ld\n", *prate);
- return -EINVAL;
+ return 0;
}
for (i = 0; pll_cfg[i].rate != 0; i++)
if (pll_cfg[i].rate == rate)
return rate;
- return -EINVAL;
+ return 0;
}
static int i2s_pll_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.7.4
[PATCH 06/33] clk: at91: change clk_pll_get_best_div_mul() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Boris Brezillon
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/at91/clk-pll.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 630203e..1c90ae7 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -157,14 +157,14 @@ static unsigned long clk_pll_get_best_div_mul(struct
clk_pll *pll,
pll->characteristics;
unsigned long bestremainder = ULONG_MAX;
unsigned long maxdiv, mindiv, tmpdiv;
- long bestrate = -ERANGE;
+ unsigned long bestrate = 0;
unsigned long bestdiv;
unsigned long bestmul;
int i = 0;
/* Check if parent_rate is a valid input rate */
if (parent_rate < characteristics->input.min)
- return -ERANGE;
+ return 0;
/*
* Calculate minimum divider based on the minimum multiplier, the
@@ -179,7 +179,7 @@ static unsigned long clk_pll_get_best_div_mul(struct
clk_pll *pll,
if (parent_rate > characteristics->input.max) {
tmpdiv = DIV_ROUND_UP(parent_rate, characteristics->input.max);
if (tmpdiv > PLL_DIV_MAX)
- return -ERANGE;
+ return 0;
if (tmpdiv > mindiv)
mindiv = tmpdiv;
@@ -234,8 +234,8 @@ static unsigned long clk_pll_get_best_div_mul(struct
clk_pll *pll,
break;
}
- /* We haven't found any multiplier/divider pair => return -ERANGE */
- if (bestrate < 0)
+ /* We haven't found any multiplier/divider pair => return 0 */
+ if (bestrate == 0)
return bestrate;
/* Check if bestrate is a valid output rate */
@@ -246,7 +246,7 @@ static unsigned long clk_pll_get_best_div_mul(struct
clk_pll *pll,
}
if (i >= characteristics->num_output)
- return -ERANGE;
+ return 0;
if (div)
*div = bestdiv;
@@ -271,15 +271,15 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned
long rate,
unsigned long parent_rate)
{
struct clk_pll *pll = to_clk_pll(hw);
- long ret;
+ unsigned long ret;
u32 div;
u32 mul;
u32 index;
ret = clk_pll_get_best_div_mul(pll, rate, parent_rate,
&div, &mul, &index);
- if (ret < 0)
- return ret;
+ if (ret == 0)
+ return -ERANGE;
pll->range = index;
pll->div = div;
--
2.7.4
[PATCH 04/33] clk: omap2: change omap2_round_to_table_rate return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Tony Lindgren
Cc: Russell King
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index e024600..ce3a33f 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -75,9 +75,9 @@ unsigned long omap2_round_to_table_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long *parent_rate)
{
const struct prcm_config *ptr;
- long highest_rate;
+ unsigned long highest_rate;
- highest_rate = -EINVAL;
+ highest_rate = 0;
for (ptr = rate_table; ptr->mpu_speed; ptr++) {
if (!(ptr->flags & cpu_mask))
--
2.7.4
[PATCH 05/33] clk: at91: update clk_pll_get_best_div_mul to return unsigned long
clk_pll_get_best_div_mul() returns a value directly as the return
value to round_rate(). clk_ops->round_rate() has been changed to an
unsigned long so for the sake of completeness and neatness this patch
updates the helper function to return the same data-type.
Signed-off-by: Bryan O'Donoghue
Cc: Boris Brezillon
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/at91/clk-pll.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 4e7da3e..630203e 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -147,10 +147,11 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw
*hw,
return (parent_rate / div) * (mul + 1);
}
-static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
-unsigned long parent_rate,
-u32 *div, u32 *mul,
-u32 *index) {
+static unsigned long clk_pll_get_best_div_mul(struct clk_pll *pll,
+ unsigned long rate,
+ unsigned long parent_rate,
+ u32 *div, u32 *mul, u32 *index)
+{
const struct clk_pll_layout *layout = pll->layout;
const struct clk_pll_characteristics *characteristics =
pll->characteristics;
--
2.7.4
[PATCH 10/33] clk: bcm: iproc: change iproc_asiu_clk_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: Ray Jui Cc: Scott Branden Cc: Jon Mason Cc: bcm-kernel-feedback-l...@broadcom.com Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/bcm/clk-iproc-asiu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/bcm/clk-iproc-asiu.c b/drivers/clk/bcm/clk-iproc-asiu.c index ae40d08..f89872e 100644 --- a/drivers/clk/bcm/clk-iproc-asiu.c +++ b/drivers/clk/bcm/clk-iproc-asiu.c @@ -115,7 +115,7 @@ static unsigned long iproc_asiu_clk_round_rate(struct clk_hw *hw, unsigned int div; if (rate == 0 || *parent_rate == 0) - return -EINVAL; + return 0; if (rate == *parent_rate) return *parent_rate; -- 2.7.4
[PATCH 17/33] clk: mvebu: change dove_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Russell King --- drivers/clk/mvebu/dove-divider.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/mvebu/dove-divider.c b/drivers/clk/mvebu/dove-divider.c index 234ba0a..7704b5e 100644 --- a/drivers/clk/mvebu/dove-divider.c +++ b/drivers/clk/mvebu/dove-divider.c @@ -117,7 +117,7 @@ static unsigned long dove_round_rate(struct clk_hw *hw, unsigned long rate, divider = dove_calc_divider(dc, rate, parent_rate, false); if (divider < 0) - return divider; + return 0; rate = DIV_ROUND_CLOSEST(parent_rate, divider); -- 2.7.4
[PATCH 18/33] clk: mxs: change clk_frac_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Shawn Guo --- drivers/clk/mxs/clk-frac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/mxs/clk-frac.c b/drivers/clk/mxs/clk-frac.c index f57281f..9debf86 100644 --- a/drivers/clk/mxs/clk-frac.c +++ b/drivers/clk/mxs/clk-frac.c @@ -59,7 +59,7 @@ static unsigned long clk_frac_round_rate(struct clk_hw *hw, unsigned long rate, u64 tmp, tmp_rate, result; if (rate > parent_rate) - return -EINVAL; + return 0; tmp = rate; tmp <<= frac->width; @@ -67,7 +67,7 @@ static unsigned long clk_frac_round_rate(struct clk_hw *hw, unsigned long rate, div = tmp; if (!div) - return -EINVAL; + return 0; tmp_rate = (u64)parent_rate * div; result = tmp_rate >> frac->width; -- 2.7.4
[PATCH 19/33] clk: nxp: change lpc18xx_pll0_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Joachim Eastwood
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/nxp/clk-lpc18xx-cgu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc18xx-cgu.c
b/drivers/clk/nxp/clk-lpc18xx-cgu.c
index e08bad9..396d4f7 100644
--- a/drivers/clk/nxp/clk-lpc18xx-cgu.c
+++ b/drivers/clk/nxp/clk-lpc18xx-cgu.c
@@ -381,13 +381,13 @@ static unsigned long lpc18xx_pll0_round_rate(struct
clk_hw *hw,
if (*prate < rate) {
pr_warn("%s: pll dividers not supported\n", __func__);
- return -EINVAL;
+ return 0;
}
m = DIV_ROUND_UP_ULL(*prate, rate * 2);
if (m <= 0 && m > LPC18XX_PLL0_MSEL_MAX) {
pr_warn("%s: unable to support rate %lu\n", __func__, rate);
- return -EINVAL;
+ return 0;
}
return 2 * *prate * m;
--
2.7.4
[PATCH 20/33] clk: lpc32xx: change clk_hclk_pll_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Vladimir Zapolskiy
Cc: Sylvain Lemieux
Cc: Gabriel Fernandez
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/nxp/clk-lpc32xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index 81ab57d..76c17f4 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -595,7 +595,7 @@ static unsigned long clk_hclk_pll_round_rate(struct clk_hw
*hw,
pr_debug("%s: %lu/%lu\n", clk_hw_get_name(hw), *parent_rate, rate);
if (rate > 26650)
- return -EINVAL;
+ return 0;
/* Have to check all 20 possibilities to find the minimal M */
for (p_i = 4; p_i >= 0; p_i--) {
@@ -622,7 +622,7 @@ static unsigned long clk_hclk_pll_round_rate(struct clk_hw
*hw,
if (d == (u64)rate << 6) {
pr_err("%s: %lu: no valid PLL parameters are found\n",
clk_hw_get_name(hw), rate);
- return -EINVAL;
+ return 0;
}
clk->m_div = m;
--
2.7.4
[PATCH 14/33] clk: vc5: change vc5_mux_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Marek Vasut Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Vladimir Barinov Cc: Alexey Firago --- drivers/clk/clk-versaclock5.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c index 2b8ea89..5e8a050 100644 --- a/drivers/clk/clk-versaclock5.c +++ b/drivers/clk/clk-versaclock5.c @@ -351,7 +351,7 @@ static unsigned long vc5_pfd_round_rate(struct clk_hw *hw, unsigned long rate, /* PLL cannot operate with input clock above 50 MHz. */ if (rate > 5000) - return -EINVAL; + return 0; /* CLKIN within range of PLL input, feed directly to PLL. */ if (*parent_rate <= 5000) @@ -359,7 +359,7 @@ static unsigned long vc5_pfd_round_rate(struct clk_hw *hw, unsigned long rate, idiv = DIV_ROUND_UP(*parent_rate, rate); if (idiv > 127) - return -EINVAL; + return 0; return *parent_rate / idiv; } -- 2.7.4
[PATCH 13/33] clk: si514: change si514_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Mike Looijmans --- drivers/clk/clk-si514.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-si514.c b/drivers/clk/clk-si514.c index 8d940d0..042ae39 100644 --- a/drivers/clk/clk-si514.c +++ b/drivers/clk/clk-si514.c @@ -220,7 +220,7 @@ static unsigned long si514_round_rate(struct clk_hw *hw, unsigned long rate, err = si514_calc_muldiv(&settings, rate); if (err) - return err; + return 0; return si514_calc_rate(&settings); } -- 2.7.4
[PATCH] Staging: pi433 - fix ccheckpatch issue, updated include line.
Updated the include of compat.h to fix checkpatch error Signed-off-by: Derek Robson --- drivers/staging/pi433/pi433_if.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index 1d7c50c1ac23..0555c76cea49 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -48,7 +48,7 @@ #include #include #ifdef CONFIG_COMPAT -#include +#include #endif #include "pi433_if.h" -- 2.15.1
[PATCH 21/33] clk: qcom: ipq4019: change clk_cpu_div_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Andy Gross Cc: David Brown Cc: Abhishek Sahu Cc: Varadarajan Narayanan Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-arm-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/qcom/gcc-ipq4019.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c index 804231b..943acbc 100644 --- a/drivers/clk/qcom/gcc-ipq4019.c +++ b/drivers/clk/qcom/gcc-ipq4019.c @@ -1268,7 +1268,7 @@ static unsigned long clk_cpu_div_round_rate(struct clk_hw *hw, f = qcom_find_freq(pll->freq_tbl, rate); if (!f) - return -EINVAL; + return 0; p_hw = clk_hw_get_parent_by_index(hw, f->src); *p_rate = clk_hw_get_rate(p_hw); -- 2.7.4
[PATCH 23/33] clk: tegra: change clk_sync_source_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Peter De Schrijver Cc: Prashant Gaikwad Cc: Michael Turquette Cc: Stephen Boyd Cc: Thierry Reding Cc: Jonathan Hunter Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/tegra/clk-audio-sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/tegra/clk-audio-sync.c b/drivers/clk/tegra/clk-audio-sync.c index 9784d58..5fd825b 100644 --- a/drivers/clk/tegra/clk-audio-sync.c +++ b/drivers/clk/tegra/clk-audio-sync.c @@ -35,7 +35,7 @@ static unsigned long clk_sync_source_round_rate(struct clk_hw *hw, struct tegra_clk_sync_source *sync = to_clk_sync_source(hw); if (rate > sync->max_rate) - return -EINVAL; + return 0; else return rate; } -- 2.7.4
[PATCH 24/33] clk: tegra: bpmp: change tegra_bpmp_clk_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Peter De Schrijver Cc: Prashant Gaikwad Cc: Michael Turquette Cc: Stephen Boyd Cc: Thierry Reding Cc: Jonathan Hunter Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/tegra/clk-bpmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c index 0c1197b..4297bb2 100644 --- a/drivers/clk/tegra/clk-bpmp.c +++ b/drivers/clk/tegra/clk-bpmp.c @@ -190,7 +190,7 @@ static unsigned long tegra_bpmp_clk_round_rate(struct clk_hw *hw, err = tegra_bpmp_clk_transfer(clk->bpmp, &msg); if (err < 0) - return err; + return 0; return response.rate; } -- 2.7.4
[PATCH 12/33] clk: cdce925: remove unnecessary long casts on return
Due to the old function signature of clk_ops->round_rate the cdce925 round_rate functions end up doing a cast of an internal unsigned long to a long. After updating clk_ops->round_rate() to be an unsigned long though the cast isn't necessary. Remove the extraneous cast from: - cdce925_pll_round_rate - cdce925_clk_round_rate - cdce925_clk_y1_round_rate Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: Akinobu Mita Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/clk-cdce925.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/clk/clk-cdce925.c b/drivers/clk/clk-cdce925.c index 341e744..eecc262 100644 --- a/drivers/clk/clk-cdce925.c +++ b/drivers/clk/clk-cdce925.c @@ -149,7 +149,7 @@ static unsigned long cdce925_pll_round_rate(struct clk_hw *hw, u16 n, m; cdce925_pll_find_rate(rate, *parent_rate, &n, &m); - return (long)cdce925_pll_calculate_rate(*parent_rate, n, m); + return cdce925_pll_calculate_rate(*parent_rate, n, m); } static int cdce925_pll_set_rate(struct clk_hw *hw, unsigned long rate, @@ -449,7 +449,7 @@ static unsigned long cdce925_clk_round_rate(struct clk_hw *hw, } if (divider) - return (long)(l_parent_rate / divider); + return l_parent_rate / divider; return 0; } @@ -497,7 +497,7 @@ static unsigned long cdce925_clk_y1_round_rate(struct clk_hw *hw, u16 divider = cdce925_y1_calc_divider(rate, l_parent_rate); if (divider) - return (long)(l_parent_rate / divider); + return l_parent_rate / divider; return 0; } -- 2.7.4
[PATCH 22/33] clk: sirf: remove unnecessary long cast on return
Due to the old function signature of clk_ops->round_rate pll_clk_round_rate does a cast of an internal unsigned long to a long. After updating clk_ops->round_rate() to be an unsigned long though the cast isn't necessary. Remove the cast now. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: Barry Song Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Barry Song --- drivers/clk/sirf/clk-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/sirf/clk-common.c b/drivers/clk/sirf/clk-common.c index 3ce6741..bfa3f4b 100644 --- a/drivers/clk/sirf/clk-common.c +++ b/drivers/clk/sirf/clk-common.c @@ -121,7 +121,7 @@ static unsigned long pll_clk_round_rate(struct clk_hw *hw, unsigned long rate, dividend = (u64)fin * nf; do_div(dividend, nr * od); - return (long)dividend; + return dividend; } static int pll_clk_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.7.4
[PATCH 26/33] clk: ti: composite: change clk_pll_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Tero Kristo
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-o...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/ti/composite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/composite.c b/drivers/clk/ti/composite.c
index 2477cf1..0e82b61 100644
--- a/drivers/clk/ti/composite.c
+++ b/drivers/clk/ti/composite.c
@@ -38,7 +38,7 @@ static unsigned long ti_composite_round_rate(struct clk_hw
*hw,
unsigned long rate,
unsigned long *prate)
{
- return -EINVAL;
+ return 0;
}
static int ti_composite_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.7.4
[PATCH 27/33] clk: ti: fapll: change round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Tero Kristo
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Tony Lindgren
Cc: linux-o...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/ti/fapll.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/ti/fapll.c b/drivers/clk/ti/fapll.c
index 2e74437..f435a8c 100644
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -227,12 +227,12 @@ static unsigned long ti_fapll_round_rate(struct clk_hw
*hw, unsigned long rate,
int error;
if (!rate)
- return -EINVAL;
+ return 0;
error = ti_fapll_set_div_mult(rate, *parent_rate,
&pre_div_p, &mult_n);
if (error)
- return error;
+ return 0;
rate = *parent_rate / pre_div_p;
rate *= mult_n;
@@ -414,7 +414,7 @@ static unsigned long ti_fapll_synth_round_rate(struct
clk_hw *hw,
unsigned long r;
if (ti_fapll_clock_is_bypass(fd) || !synth->div || !rate)
- return -EINVAL;
+ return 0;
/* Only post divider m available with no fractional divider? */
if (!synth->freq) {
--
2.7.4
[PATCH 15/33] clk: vt8500: change vtwm_pll_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Tony Prisk
---
drivers/clk/clk-vt8500.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index 43c88f6..750c087 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -610,7 +610,7 @@ static unsigned long vtwm_pll_round_rate(struct clk_hw *hw,
unsigned long rate,
struct clk_pll *pll = to_clk_pll(hw);
u32 filter, mul, div1, div2;
long round_rate;
- int ret;
+ int ret = 1;
switch (pll->type) {
case PLL_TYPE_VT8500:
@@ -634,11 +634,11 @@ static unsigned long vtwm_pll_round_rate(struct clk_hw
*hw, unsigned long rate,
round_rate = WM8850_BITS_TO_FREQ(*prate, mul, div1,
div2);
break;
default:
- ret = -EINVAL;
+ break;
}
if (ret)
- return ret;
+ return 0;
return round_rate;
}
--
2.7.4
[PATCH 25/33] clk: tegra: pll: change clk_pll_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Peter De Schrijver Cc: Prashant Gaikwad Cc: Michael Turquette Cc: Stephen Boyd Cc: Thierry Reding Cc: Jonathan Hunter Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Rhyland Klein Cc: Bill Huang --- drivers/clk/tegra/clk-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c index b4a7d30..0a3edb0 100644 --- a/drivers/clk/tegra/clk-pll.c +++ b/drivers/clk/tegra/clk-pll.c @@ -839,7 +839,7 @@ static unsigned long clk_pll_round_rate(struct clk_hw *hw, unsigned long rate, if (_get_table_rate(hw, &cfg, rate, *prate) && pll->params->calc_rate(hw, &cfg, rate, *prate)) - return -EINVAL; + return 0; return cfg.output_rate; } -- 2.7.4
[PATCH 28/33] clk: zte: change zx_audio_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Jun Nie Cc: Baoyou Xie Cc: Shawn Guo Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/zte/clk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/zte/clk.c b/drivers/clk/zte/clk.c index df91842..6afdc4a 100644 --- a/drivers/clk/zte/clk.c +++ b/drivers/clk/zte/clk.c @@ -247,7 +247,7 @@ static unsigned long zx_audio_round_rate(struct clk_hw *hw, unsigned long rate, u32 reg; if (rate * 2 > *prate) - return -EINVAL; + return 0; reg = calc_reg(*prate, rate); return calc_rate(reg, *prate); -- 2.7.4
[PATCH 29/33] clk: axs10x: change axs10x_pll_round_rate return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Eugeniy Paltsev Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/axs10x/pll_clock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/axs10x/pll_clock.c b/drivers/clk/axs10x/pll_clock.c index 27498eb..e90ae9e 100644 --- a/drivers/clk/axs10x/pll_clock.c +++ b/drivers/clk/axs10x/pll_clock.c @@ -162,7 +162,7 @@ static unsigned long axs10x_pll_round_rate(struct clk_hw *hw, const struct axs10x_pll_cfg *pll_cfg = clk->pll_cfg; if (pll_cfg[0].rate == 0) - return -EINVAL; + return 0; best_rate = pll_cfg[0].rate; -- 2.7.4
[PATCH 11/33] clk: bcm: iproc: change iproc_pll_round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Ray Jui
Cc: Scott Branden
Cc: Jon Mason
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/bcm/clk-iproc-pll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
index b5399b2..54e914c 100644
--- a/drivers/clk/bcm/clk-iproc-pll.c
+++ b/drivers/clk/bcm/clk-iproc-pll.c
@@ -439,7 +439,7 @@ static unsigned long iproc_pll_round_rate(struct clk_hw
*hw, unsigned long rate,
struct iproc_pll *pll = clk->pll;
if (rate == 0 || *parent_rate == 0 || !pll->vco_param)
- return -EINVAL;
+ return 0;
for (i = 0; i < pll->num_vco_entries; i++) {
if (rate <= pll->vco_param[i].rate)
@@ -541,7 +541,7 @@ static unsigned long iproc_clk_round_rate(struct clk_hw
*hw, unsigned long rate,
unsigned int div;
if (rate == 0 || *parent_rate == 0)
- return -EINVAL;
+ return 0;
if (rate == *parent_rate)
return *parent_rate;
--
2.7.4
[PATCH 30/33] clk: at91: change round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a
negative number on error.
In conjunction with higher-level changes associated with acting on the
return value of clk_ops->round_rate() it is then possible to have
clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of
the current limitation of 1 Hz to LONG_MAX Hz.
Signed-off-by: Bryan O'Donoghue
Cc: Boris Brezillon
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Quentin Schulz
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/at91/clk-audio-pll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/at91/clk-audio-pll.c b/drivers/clk/at91/clk-audio-pll.c
index 56227cb..48231e3 100644
--- a/drivers/clk/at91/clk-audio-pll.c
+++ b/drivers/clk/at91/clk-audio-pll.c
@@ -278,7 +278,7 @@ static unsigned long clk_audio_pll_pad_round_rate(struct
clk_hw *hw,
unsigned long *parent_rate)
{
struct clk_hw *pclk = clk_hw_get_parent(hw);
- long best_rate = -EINVAL;
+ unsigned long best_rate = 0;
unsigned long best_parent_rate;
unsigned long tmp_qd;
u32 div;
@@ -330,7 +330,7 @@ static unsigned long clk_audio_pll_pmc_round_rate(struct
clk_hw *hw,
unsigned long *parent_rate)
{
struct clk_hw *pclk = clk_hw_get_parent(hw);
- long best_rate = -EINVAL;
+ unsigned long best_rate = 0;
unsigned long best_parent_rate = 0;
u32 tmp_qd = 0, div;
long tmp_rate;
--
2.7.4
[PATCH 32/33] clk: lpc32xx: change round_rate() return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Michael Turquette Cc: Stephen Boyd Cc: Vladimir Zapolskiy Cc: Sylvain Lemieux Cc: Gabriel Fernandez Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/nxp/clk-lpc32xx.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c index 76c17f4..0e0d258 100644 --- a/drivers/clk/nxp/clk-lpc32xx.c +++ b/drivers/clk/nxp/clk-lpc32xx.c @@ -664,17 +664,17 @@ static unsigned long clk_usb_pll_round_rate(struct clk_hw *hw, * USB divider, USB PLL N and M parameters. */ if (rate != 4800) - return -EINVAL; + return 0; /* USB divider clock */ usb_div_hw = clk_hw_get_parent_by_index(hw, 0); if (!usb_div_hw) - return -EINVAL; + return 0; /* Main oscillator clock */ osc_hw = clk_hw_get_parent_by_index(usb_div_hw, 0); if (!osc_hw) - return -EINVAL; + return 0; o = clk_hw_get_rate(osc_hw);/* must be in range 1..20 MHz */ /* Check if valid USB divider and USB PLL parameters exists */ @@ -697,7 +697,7 @@ static unsigned long clk_usb_pll_round_rate(struct clk_hw *hw, } } - return -EINVAL; + return 0; } #define LPC32XX_DEFINE_PLL_OPS(_name, _rc, _sr, _rr) \ -- 2.7.4
[PATCH 33/33] clk: change handling of round_rate() such that only zero is an error
Change the handling of clk_ops->round_rate() return values such that only
zero is treated as an error. All implementations of clk_ops->round_rate()
will have previously been updated to match this change.
Using zero as the determinant for an error means its possible to pass an
unsigned long as req->rate to a clk_ops->round_rate() function and return a
rounded clock which is as high as the original req->rate. This allows us on
32 bit systems to return rounded rates of (2^32)-1 Hz or ULONG_MAX Hz -
whereas without this change and the associated clk_ops->round_rate() change
the maximum value that can be returned via clk_ops->round_rate() is
LONG_MAX Hz - after which a higher-frequency clock looks like a negative
error code - due to sign extension.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/clk.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8a1860a..6af2ece 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -909,7 +909,6 @@ static int clk_core_round_rate_nolock(struct clk_core *core,
struct clk_rate_request *req)
{
struct clk_core *parent;
- long rate;
lockdep_assert_held(&prepare_lock);
@@ -928,12 +927,8 @@ static int clk_core_round_rate_nolock(struct clk_core
*core,
if (core->ops->determine_rate) {
return core->ops->determine_rate(core->hw, req);
} else if (core->ops->round_rate) {
- rate = core->ops->round_rate(core->hw, req->rate,
+ req->rate = core->ops->round_rate(core->hw, req->rate,
&req->best_parent_rate);
- if (rate < 0)
- return rate;
-
- req->rate = rate;
} else if (core->flags & CLK_SET_RATE_PARENT) {
return clk_core_round_rate_nolock(parent, req);
} else {
@@ -1454,12 +1449,8 @@ static struct clk_core *clk_calc_new_rates(struct
clk_core *core,
new_rate = req.rate;
parent = req.best_parent_hw ? req.best_parent_hw->core : NULL;
} else if (core->ops->round_rate) {
- ret = core->ops->round_rate(core->hw, rate,
- &best_parent_rate);
- if (ret < 0)
- return NULL;
-
- new_rate = ret;
+ new_rate = core->ops->round_rate(core->hw, rate,
+&best_parent_rate);
if (new_rate < min_rate || new_rate > max_rate)
return NULL;
} else if (!parent || !(core->flags & CLK_SET_RATE_PARENT)) {
--
2.7.4
Re: 4.14.9 doesn't boot (regression)
В Пт, 29/12/2017 в 17:10 -0700, Andy Lutomirski пишет: > > Also, you wouldn't happen to be using Gentoo perchance? I already > have two reports of a Gentoo system miscompiling the vDSO due to > Gentoo enabling -fstack-check and GCC generating stack check code > that is highly suboptimal, actively incorrect, and doesn't even > manage to check the stack in a particularly helpful way. > > If this is indeed what's going on, I'm going to try to come up with a > patch to outright fail the build on these buggy systems. We could > probably fudge the build options to avoid the problem, but Gentoo > really just needs fix its toolchain. You are right, It's due to fstack-check enabled in gentoo's gcc spec. "-fstack-check=no" in KBUILD_CFLAGS fixed this problem for me. =/
[PATCH 31/33] clk: ARC: change hsdk_pll_round_rate () return logic
This patch updates the round_rate() logic here to return zero instead of a negative number on error. In conjunction with higher-level changes associated with acting on the return value of clk_ops->round_rate() it is then possible to have clk_ops->round_rate() return values from 1 Hz to ULONG_MAX Hz instead of the current limitation of 1 Hz to LONG_MAX Hz. Signed-off-by: Bryan O'Donoghue Cc: Eugeniy Paltsev Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/clk/clk-hsdk-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-hsdk-pll.c b/drivers/clk/clk-hsdk-pll.c index 62c8e18..7bff5e3 100644 --- a/drivers/clk/clk-hsdk-pll.c +++ b/drivers/clk/clk-hsdk-pll.c @@ -201,7 +201,7 @@ static unsigned long hsdk_pll_round_rate(struct clk_hw *hw, unsigned long rate, const struct hsdk_pll_cfg *pll_cfg = clk->pll_devdata->pll_cfg; if (pll_cfg[0].rate == 0) - return -EINVAL; + return 0; best_rate = pll_cfg[0].rate; -- 2.7.4
[PATCH 03/33] clk: composite: allow round_rate to scale past LONG_MAX on 32 bit systems
Defining the return value of round_rate as a long and returning error codes
as well as the rounded-clock value in the return value of a
clk_ops->round_rate callback means that its not possible to return a clock
greater than LONG_MAX Hz on a 32 bit system.
This patch changes the handling of the return value from round_rate() such
that zero indicates an unusable clock and non-zero indicates a successfully
rounded clock giving us a full range of 1 Hz to ULONG_MAX Hz on 32 bit
systems.
Implementations of round_rate() must either return a rounded-clock or zero
to indicate error.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/clk-composite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index f3707c3..2090b74 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -66,7 +66,7 @@ static int clk_composite_determine_rate(struct clk_hw *hw,
long tmp_rate, best_rate = 0;
unsigned long rate_diff;
unsigned long best_rate_diff = ULONG_MAX;
- long rate;
+ unsigned long rate;
int i;
if (rate_hw && rate_ops && rate_ops->determine_rate) {
@@ -83,8 +83,8 @@ static int clk_composite_determine_rate(struct clk_hw *hw,
rate = rate_ops->round_rate(rate_hw, req->rate,
&req->best_parent_rate);
- if (rate < 0)
- return rate;
+ if (!rate)
+ return -EINVAL;
req->rate = rate;
return 0;
@@ -99,7 +99,7 @@ static int clk_composite_determine_rate(struct clk_hw *hw,
tmp_rate = rate_ops->round_rate(rate_hw, req->rate,
&parent_rate);
- if (tmp_rate < 0)
+ if (tmp_rate == 0)
continue;
rate_diff = abs(req->rate - tmp_rate);
--
2.7.4
[PATCH 00/33] change clk_ops->round_rate to scale past LONG_MAX
Working with a 32 bit MIPS system on a 4.11 kernel its has been noticed
that passing a 2.4GHz clock value to clk_ops->round_rate() is resulting in
an error.
Looking into this a bit it seems its currently possible to pass an unsigned
long with a value larger than LONG_MAX but not possible to return a value
higher than LONG_MAX because the return type is a signed long and that
return type is checked for negative error numbers.
Interestingly inside of clk.c when dealing with clk_ops->round_rate()
return values, error numbers aren't fed up the call chain, so changing the
interpretation of error from <=0 to simply 0 appears to be low-enough
impact.
This series aims to modify clk_ops->round_rate(); such that it will be
possible to return the full range of a ULONG on 32 bit systems when doing
round_rate(). There are various references to doing this in some of the
commits for example the following commits for clk_ops->round_rate and
clk_round_rate().
commit 4408c26bc37f ("ARM: davinci: clock: return 0 upon error from
clk_round_rate()")
This series has been run through a few compilations and tested it on the
afore mentioned (unreleased MIPS SoC) an i.MX7Solo WaRP7 board, an x86
Quark X1000 with the original error on the MIPS getting fixed - we can now
do a round_rate() on a 2.4 GHz clock and there's no obvious breakage with
the compilations run nor on the other boards tested.
Bryan O'Donoghue (33):
clk_ops: change round_rate() to return unsigned long
clk: core: update divider_round_rate functions to return unsigned long
clk: composite: allow round_rate to scale past LONG_MAX on 32 bit
systems
clk: omap2: change omap2_round_to_table_rate return logic
clk: at91: update clk_pll_get_best_div_mul to return unsigned long
clk: at91: change clk_pll_get_best_div_mul() return logic
clk: axs10x: change i2s_pll_round_rate return logic
clk: bcm2835: change bcm2835_pll_rate_from_divisors to return unsigned
long
clk: bcm2835: change clk_get_rate() helper return type
clk: bcm: iproc: change iproc_asiu_clk_round_rate() return logic
clk: bcm: iproc: change iproc_pll_round_rate() return logic
clk: cdce925: remove unnecessary long casts on return
clk: si514: change si514_round_rate() return logic
clk: vc5: change vc5_mux_round_rate() return logic
clk: vt8500: change vtwm_pll_round_rate() return logic
clk: vt8500: match temp holder variable to fn return type
clk: mvebu: change dove_round_rate() return logic
clk: mxs: change clk_frac_round_rate() return logic
clk: nxp: change lpc18xx_pll0_round_rate() return logic
clk: lpc32xx: change clk_hclk_pll_round_rate() return logic
clk: qcom: ipq4019: change clk_cpu_div_round_rate() return logic
clk: sirf: remove unnecessary long cast on return
clk: tegra: change clk_sync_source_round_rate() return logic
clk: tegra: bpmp: change tegra_bpmp_clk_round_rate() return logic
clk: tegra: pll: change clk_pll_round_rate() return logic
clk: ti: composite: change clk_pll_round_rate() return logic
clk: ti: fapll: change round_rate() return logic
clk: zte: change zx_audio_round_rate() return logic
clk: axs10x: change axs10x_pll_round_rate return logic
clk: at91: change round_rate() return logic
clk: ARC: change hsdk_pll_round_rate () return logic
clk: lpc32xx: change round_rate() return logic
clk: change handling of round_rate() such that only zero is an error
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c| 8 +++
arch/arm/mach-omap2/clock2xxx.h | 4 ++--
arch/arm/mach-vexpress/spc.c| 4 ++--
arch/mips/alchemy/common/clock.c| 2 +-
drivers/clk/at91/clk-audio-pll.c| 14 +++-
drivers/clk/at91/clk-h32mx.c| 5 +++--
drivers/clk/at91/clk-peripheral.c | 6 ++---
drivers/clk/at91/clk-pll.c | 29 +
drivers/clk/at91/clk-plldiv.c | 5 +++--
drivers/clk/at91/clk-smd.c | 5 +++--
drivers/clk/at91/clk-usb.c | 5 +++--
drivers/clk/axs10x/i2s_pll_clock.c | 8 +++
drivers/clk/axs10x/pll_clock.c | 7 +++---
drivers/clk/bcm/clk-bcm2835.c | 22 ++-
drivers/clk/bcm/clk-iproc-asiu.c| 7 +++---
drivers/clk/bcm/clk-iproc-pll.c | 12 +-
drivers/clk/clk-axi-clkgen.c| 5 +++--
drivers/clk/clk-cdce706.c | 15 -
drivers/clk/clk-cdce925.c | 21 ++
drivers/clk/clk-composite.c | 13 ++-
drivers/clk/clk-cs2000-cp.c | 4 ++--
drivers/clk/clk-divider.c | 15 -
drivers/clk/clk-fixed-factor.c | 5 +++--
drivers/clk/clk-fractional-divider.c| 4 ++--
drivers/clk/clk-gemini.c| 5 +++--
drivers/clk/clk-hi
[PATCH 16/33] clk: vt8500: match temp holder variable to fn return type
vtwm_pll_round_rate() returns an unsigned long. This patch changes the
internal holder variable from signed to unsigned long for the sake of
completeness and neatness.
Signed-off-by: Bryan O'Donoghue
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Tony Prisk
---
drivers/clk/clk-vt8500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index 750c087..a4aa0bf 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -609,7 +609,7 @@ static unsigned long vtwm_pll_round_rate(struct clk_hw *hw,
unsigned long rate,
{
struct clk_pll *pll = to_clk_pll(hw);
u32 filter, mul, div1, div2;
- long round_rate;
+ unsigned long round_rate;
int ret = 1;
switch (pll->type) {
--
2.7.4
Re: 4.14.9 with CONFIG_MCORE2 fails to boot
On 12/29/2017 10:46 AM, Alexander Tsoy wrote: > В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет: >> Does anyone have the results of build that they can share? (vmlinux, >> vmlinuz/bzImage, System.map, .config). That, plus a corresponding >> serial log with an oops would be helpful. > > Here you are: > https://www.dropbox.com/s/yesupqgig3uxf73/linux-4.15-rc5%2B.tar.xz?dl=0 Alexander, thanks a bunch for the quick turnaround on this. It is much appreciated! With your binary, I can reproduce this in a KVM guest. Seems we manage to get to paranoid_entry with a kernel GS value, but the user page tables in place. We don't smash the #DF stack because we reset the stack at each new #DF. I think the loop that we get stuck in goes something like this: 1. Hardware does #DF, calls double_fault 2. call paranoid_entry 3. check MSR for GSBASE, see it has kernel value, skip SWAPGS and switch to kernel page tables 4. touch stack, try to #PF, but can't touch stack, so #DF and goto 1 The real question is where we double-faulted from in the first place with a kernel GSBASE and user CR3. I think I just need to disable KASLR and do a little work in gdb to look at the stack on the first double-fault, but we'll see.
Re: 4.14.9 doesn't boot (regression)
f On Fri, Dec 29, 2017 at 4:10 PM, Andy Lutomirski wrote: > > Double faults use IST, so a double fault that double faults will effectively > just start over rather than eventually running out of stack and triple > faulting. > > But check out the registers. We have RSP = ...28fd8 and CR2 = ...27f08. > IOW the double fault stack is ...28000 - ...28fff and we're somehow getting > a failed page fault a couple hundred bytes below the bottom of the IST stack. > IOW, I think we're just stuck in a neverending loop of stack overflows. Ahh, good catch. This feels like it might finally be explaining things. > (Also, Josh, the oops code should have printed the contents of the struct > pt_regs at the top of the DF stack. Any idea why it didn't?) > > Toralf, can you send the complete output of: > > objdump -dr arch/x86/kernel/traps.o > > From the build tree of a nonworking kernel? Alexander made one of his failing kernels available earlier: https://www.dropbox.com/s/yesupqgig3uxf73/linux-4.15-rc5%2B.tar.xz?dl=0 and yes, there's something seriously wrong there. Doing a disassembly on "do_double_fault()" shows: 8101bda0 : 8101bda0: 41 54 push %r12 8101bda2: 55 push %rbp 8101bda3: 53 push %rbx 8101bda4: 48 81 ec 20 10 00 00sub$0x1020,%rsp 8101bdab: 48 83 0c 24 00 orq$0x0,(%rsp) 8101bdb0: 48 81 c4 20 10 00 00add$0x1020,%rsp WTF? That's bogus crap, and not ok in the kernel. Doing a stack probe below the stack by subtracting 4128rom the stack pointer and then oring it, and then resetting the stack pointer again is just crazy. And it's definitely not ever going to work for the kernel that has a limited stack. So yes, It's a terminally broken compiler from hell. I assume gentoo has applied some completely broken security patch to their compiler, turning said compiler into complete garbage. Doing some trivial grepping on the disassembly in that vmlinux file, there's tons of those "let's probe more than a page below the stack" issues. The biggest offset I found was 0x1400. That one happened to be in do_sys_poll(). > Also, you wouldn't happen to be using Gentoo perchance? Yes, several people involved are using gentoo. Maybe everybody. > I already have two reports of a Gentoo system miscompiling the vDSO > due to Gentoo enabling -fstack-check and GCC generating stack check > code that is highly suboptimal, actively incorrect, and doesn't even > manage to check the stack in a particularly helpful way. Yes. Good. I think you root-caused it. Good. I was not feeling so happy about this bug report, but now I can firmly just blame the gentoo compiler for having some shit-for-brains "feature". Linus
Re: [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
Hi Mathieu, On Fri, Dec 15, 2017 at 09:44:49AM -0700, Mathieu Poirier wrote: > This patchset adds support for per-thread CoreSight trace decoding from the > "perf report" interface. It is largely modelled on what has been done for > intelPT traces and currently targets the ETMv4 architecture. Support for > cpu-wide scenarios and ETMv3/PTMv1.1 will follow shortly. > > The trace decoding support is done using the Open CoreSight Decoding > Library (openCSD), a stand alone open source project available here [1]. > Integration of the openCSD library with the perf tools follow what has > been done for other support libraries. If the library has been installed > on a system the build scripts will include support for CoreSight trace > decoding: > > ... zlib: [ on ] > ... lzma: [ OFF ] > ... get_cpuid: [ on ] > ... bpf: [ on ] > ...libopencsd: [ on ] <-- > > Instructions on how to build and install the openCSD library are provided > in the HOWTO.md of the project repository. We elected to keep the decoder > library independent of the kernel tree as it is also used outside of the > perf toolset and various non-linux projects. > > The work applies cleanly to [2] and proper functionning of the feature > depends on this patch [3]. With latest perf code, it reports another error when analyse perf data: "0x3e0 [0x50]: failed to process type: 1". After roughly analysis, I found this is caused by one dummy event (in the binary from offset 0xf8 to offset 0x178). Because this event type is not set for 'PERF_SAMPLE_TIME', so the function perf_evsel__parse_sample_timestamp() checks the event has not set 'PERF_SAMPLE_TIME' then directly bail out with error. 00f0: 0800 0100 7000 p... 0100: 0900 0100 0110: 0300 0100 0400 0120: 6133 8401 a3.. 0130: 0140: 0150: 0160: 7000 p... 0170: 0800 4600 6802 F.h. You could check the perf binary from [1]. Please note, this perf data I capatured from kernel 4.14-rc6, so is it might be compatible issue between 4.14-rc6 and 4.15? [1] http://people.linaro.org/~leo.yan/binaries/perf_4.15_r4/perf.data Thanks, Leo Yan > Review and comments would be greatly appreciated. > > Regards, > Mathieu > > [1]. https://github.com/Linaro/OpenCSD > [2]. git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core > [3]. https://lkml.org/lkml/2017/12/14/612 > > Mathieu Poirier (8): > perf tools: Integrating the CoreSight decoding library > perf tools: Add initial entry point for decoder CoreSight traces > perf tools: Add decoder mechanic to support dumping trace data > perf tools: Add support for decoding CoreSight trace data > perf tools: Add functionality to communicate with the openCSD decoder > pert tools: Add queue management functionality > perf tools: Add full support for CoreSight trace decoding > perf tools: Add mechanic to synthesise CoreSight trace packets > > Tor Jeremiassen (2): > perf tools: Add processing of coresight metadata > MAINTAINERS: Adding entry for CoreSight trace decoding > > MAINTAINERS |3 +- > tools/build/Makefile.feature|6 +- > tools/build/feature/Makefile|6 +- > tools/build/feature/test-all.c |5 + > tools/build/feature/test-libopencsd.c |8 + > tools/perf/Makefile.config | 13 + > tools/perf/util/Build |6 + > tools/perf/util/auxtrace.c |2 + > tools/perf/util/cs-etm-decoder/Build|1 + > tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 513 > tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 105 +++ > tools/perf/util/cs-etm.c| 1023 > +++ > tools/perf/util/cs-etm.h| 18 + > 13 files changed, 1705 insertions(+), 4 deletions(-) > create mode 100644 tools/build/feature/test-libopencsd.c > create mode 100644 tools/perf/util/cs-etm-decoder/Build > create mode 100644 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c > create mode 100644 tools/perf/util/cs-etm-decoder/cs-etm-decoder.h > create mode 100644 tools/perf/util/cs-etm.c > > -- > 2.7.4 >
Re: [PATCH 05/10] perf tools: Add support for decoding CoreSight trace data
Hi Mathieu, Mike,
On Fri, Dec 15, 2017 at 09:44:54AM -0700, Mathieu Poirier wrote:
> Adding functionality to create a CoreSight trace decoder capable
> of decoding trace data pushed by a client application.
>
> Co-authored-by: Tor Jeremiassen
> Signed-off-by: Mathieu Poirier
> ---
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 119
>
> 1 file changed, 119 insertions(+)
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index 6a4c86b1431f..57b020b0b36f 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -200,6 +200,121 @@ static void cs_etm_decoder__clear_buffer(struct
> cs_etm_decoder *decoder)
> }
> }
>
> +static ocsd_datapath_resp_t
> +cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
> + const ocsd_generic_trace_elem *elem,
> + const u8 trace_chan_id,
> + enum cs_etm_sample_type sample_type)
> +{
> + u32 et = 0;
> + struct int_node *inode = NULL;
> +
> + if (decoder->packet_count >= MAX_BUFFER - 1)
> + return OCSD_RESP_FATAL_SYS_ERR;
> +
> + /* Search the RB tree for the cpu associated with this traceID */
> + inode = intlist__find(traceid_list, trace_chan_id);
> + if (!inode)
> + return OCSD_RESP_FATAL_SYS_ERR;
> +
> + et = decoder->tail;
> + decoder->packet_buffer[et].sample_type = sample_type;
> + decoder->packet_buffer[et].start_addr = elem->st_addr;
> + decoder->packet_buffer[et].end_addr = elem->en_addr;
> + decoder->packet_buffer[et].exc = false;
> + decoder->packet_buffer[et].exc_ret = false;
> + decoder->packet_buffer[et].cpu = *((int *)inode->priv);
> +
> + /* Wrap around if need be */
> + et = (et + 1) & (MAX_BUFFER - 1);
> +
> + decoder->tail = et;
> + decoder->packet_count++;
> +
> + if (decoder->packet_count == MAX_BUFFER - 1)
> + return OCSD_RESP_WAIT;
> +
> + return OCSD_RESP_CONT;
> +}
> +
> +static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
> + const void *context,
> + const ocsd_trc_index_t indx __maybe_unused,
> + const u8 trace_chan_id __maybe_unused,
> + const ocsd_generic_trace_elem *elem)
> +{
> + ocsd_datapath_resp_t resp = OCSD_RESP_CONT;
> + struct cs_etm_decoder *decoder = (struct cs_etm_decoder *) context;
After apply this patch set and build 'perf' tool with linking
OpenCSDv0.8.0 libs, I can everytime OpenCSD parses 'elem->elem_type'
is OCSD_GEN_TRC_ELEM_ADDR_NACC but not OCSD_GEN_TRC_ELEM_INSTR_RANGE.
As result, the 'perf' tool can dump the raw data with '-D' option but
it cannot analyze the symbol and symbol offset with below command:
./perf script -v -a -F cpu,event,ip,sym,symoff -i ./perf.data -k vmlinux
--kallsyms ./System.map
Have uploaded perf.data/vmlinux/System.map in the folder:
http://people.linaro.org/~leo.yan/binaries/perf_4.15_r4/
Thanks,
Leo Yan
> + switch (elem->elem_type) {
> + case OCSD_GEN_TRC_ELEM_UNKNOWN:
> + break;
> + case OCSD_GEN_TRC_ELEM_NO_SYNC:
> + decoder->trace_on = false;
> + break;
> + case OCSD_GEN_TRC_ELEM_TRACE_ON:
> + decoder->trace_on = true;
> + break;
> + case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
> + resp = cs_etm_decoder__buffer_packet(decoder, elem,
> + trace_chan_id,
> + CS_ETM_RANGE);
> + break;
> + case OCSD_GEN_TRC_ELEM_EXCEPTION:
> + decoder->packet_buffer[decoder->tail].exc = true;
> + break;
> + case OCSD_GEN_TRC_ELEM_EXCEPTION_RET:
> + decoder->packet_buffer[decoder->tail].exc_ret = true;
> + break;
> + case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
> + case OCSD_GEN_TRC_ELEM_EO_TRACE:
> + case OCSD_GEN_TRC_ELEM_ADDR_NACC:
> + case OCSD_GEN_TRC_ELEM_TIMESTAMP:
> + case OCSD_GEN_TRC_ELEM_CYCLE_COUNT:
> + case OCSD_GEN_TRC_ELEM_ADDR_UNKNOWN:
> + case OCSD_GEN_TRC_ELEM_EVENT:
> + case OCSD_GEN_TRC_ELEM_SWTRACE:
> + case OCSD_GEN_TRC_ELEM_CUSTOM:
> + default:
> + break;
> + }
> +
> + return resp;
> +}
> +
> +static int cs_etm_decoder__create_etm_packet_decoder(
> + struct cs_etm_trace_params *t_params,
> + struct cs_etm_decoder *decoder)
> +{
> + const char *decoder_name;
> + ocsd_etmv4_cfg trace_config_etmv4;
> + void *trace_config;
> + u8 csid;
> +
> + switch (t_params->protocol) {
> + case CS_ETM_PROTO_ETMV4i:
> + cs_etm_decoder__gen_etmv4_config(t_params, &trace_config_etmv4);
> + decoder_n
Re: [RFC PATCH v12 1/5] dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
On Sat, Dec 30, 2017 at 12:50 AM, Rafael J. Wysocki wrote: > On Fri, Dec 29, 2017 at 6:57 PM, Tony Lindgren wrote: >> * Jeffy Chen [171226 02:11]: >>> We are going to handle PCIe WAKE# pin for PCI devices in the pci core, >>> so add definitions of the optional PCIe WAKE# pin for PCI devices. >>> >>> Also add an definition of the optional PCI interrupt pin for PCI >>> devices to distinguish it from the PCIe WAKE# pin. >> >>> --- a/Documentation/devicetree/bindings/pci/pci.txt >>> +++ b/Documentation/devicetree/bindings/pci/pci.txt >>> @@ -24,3 +24,13 @@ driver implementation may support the following >>> properties: >>> unsupported link speed, for instance, trying to do training for >>> unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2' >>> for gen2, and '1' for gen1. Any other values are invalid. >>> + >>> +PCI devices may support the following properties: >> >> This should say PCI ports instead of PCI devices. > > No, it is more accurate to say "PCI devices". > > Well, it actually gets somewhat confusing, because in the PCI > terminology a "PCI device" means a physical piece of hardware that can > be put into a single "slot" (think socket on a board) and may consist > up to 8 functional units called "functions" which are each represented > by a struct pci_dev. So there may be up to 8 struct pci_dev objects > per "PCI device" (as per the standard language) and, BTW, drivers bind > to functions (via the struct pci_dev objects). > > Now, WAKE# is shared by all functions within the same "PCI device" > (I'm not sure if the standard specifies that directly, but at least it > appears to be treated as an obvious physical limitation), so it may be > useful to represent the "slot" or "device" level in the DT even though > it has no struct device based representation in the kernel. Within the convention that bridges represent "everything below them" as far as WAKE# is concerned, it can say "The following properties may be provided for PCI bridges:" and the description below should explain the convention. Thanks, Rafael
Re: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
On Sat, Dec 30, 2017 at 12:39 AM, Rafael J. Wysocki wrote: > On Fri, Dec 29, 2017 at 6:15 PM, Tony Lindgren wrote: >> * Rafael J. Wysocki [171228 17:33]: >>> On Thursday, December 28, 2017 5:51:34 PM CET Tony Lindgren wrote: >>> > >>> > Well Brian had a concern where we would have to implement PM runtime >>> > for all device drivers for PCI devices. >>> >>> Why would we? >> >> Seems at least I was a bit confused. In the PCIe case the WAKE# is >> owned by the PCIe slot, not the child PCIe device. > > Well, it depends on what you mean by "slot" and "child device", but if > my understanding of it is correct, WAKE# actually is "owned" by the > latter. > > First, let me clarify the terminology. PCI slots are not really > represented in the device hierarchy in Linux. They are represented by > kernel objects for hotplug purposes, but these objects are not based > on struct device. > > Generally, there are two kinds of PCI entities represented by struct > pci_dev, bridges and endpoints (functions). Bridges may represent > physical devices, like PCI-to-PCI bridges, or parts of physical > devices, like PCIe ports. In PCIe, every port is logically > represented by a bridge (and a PCI config space region with a Type 1 > header). However, ports do not take actions like generating > interrupts; the pieces of hardware containing them (switches, Root > Complex) do that. > > Endpoints (functions) are children of bridges (e.g. PCIe ports) and > bridges may be children of other bridges (like in a switch that is > represented by a bus segment with one upstream bridge - the upstream > port - and possibly multiple downstream bridges - downstream ports). > So in PCI a parent always is a bridge (either a PCI bridge - a bridge > between to PCI bus segments - or a host bridge) and if that is a PCIe > port, it cannot "own" anything like WAKE#, because it is not affected > by it in any way and doesn't take part in the handling of it. > > In the context of "Figure 5-4" in the spec, Case 1, what matters is > that every "Slot" in the figure represents a bunch (up to 8) of > endpoints (functions), but the "Slot" is not the parent of them. The > port of the switch the "Slot" is connected to is the parent. WAKE# > basically comes from one of the endpoints belonging to the "Slot" and > you need to look into the config space regions for all of these > endpoints to check which one has PME Status set and clear it (to > acknowledge the PME and make the hardware stop asserting the WAKE# > signal). So, from the software perspective, the endpoint (child) is > the source of WAKE# and that should be reflected by DT properties IMO. > >> So you're right, there should be no need for the child PCIe device drivers to >> implement runtime PM. > > There should be no need for that regardless. You only need an > interrupt handler that will look for the endpoint with PME Status set, > acknowledge it and possibly invoke runtime PM for the endpoint in > question (if supported). All of that is standard and can happen at > the bus type level and the interrupt handler I'm talking about may be > based on pci_pme_wakeup() or pci_acpi_wake_dev(). > >> I was thinking the wakeirq case with WLAN on SDIO bus. Some WLAN >> devices can have a hardwired OOB wakeirq wired to a GPIO controller. >> In that case the wakeirq is owned by the child device driver >> (WLAN controller) and not by the SDIO slot. I was earlier >> thinking this is the same as the "Figure 5-4" case 1, but it's >> not. > > Well, it is not in the sense that the endpoint driver is not expected > to handle the wakeup interrupt by itself. The PCI bus type is > responsible for that, but technically WAKE# comes from the endpoint > (child). > >> So in the PCIe WAKE# case for device tree, we must have the >> wakeirq property for the PCIe slot for the struct device managing >> that slot, > > Which doesn't exist. > >> and not for the child device driver. I think it's >> already this way in the most recent set of patches, I need to >> look again. > > No, you need a wakeirq properly for the child *device* and that > property will be consumed by the PCI layer. Or, if you use the convention mentioned in another message in this thread, you can make the wakeirq be a property of a bridge (port) with the clarification of the assumption that WAKE# is shared by all functions below the bridge. So the presence of the "wakeirq" property for a bridge (in addition to providing the wakeup IRQ) will mean that it applies to all devices below the bridge. In the case of parallel PCI (not PCIe), there may be multiple "slots" (or "PCI devices" consisting each of multiple functions) under one bridge and in theory each of them may use a different IRQ for WAKE# signaling, so the above convention will not work then. Thanks, Rafael
Re: [PATCH v3 bpf-next 1/2] tools/bpftool: use version from the kernel source tree
On 12/27/2017 08:16 PM, Roman Gushchin wrote: > Bpftool determines it's own version based on the kernel > version, which is picked from the linux/version.h header. > > It's strange to use the version of the installed kernel > headers, and makes much more sense to use the version > of the actual source tree, where bpftool sources are. > > Fix this by building kernelversion target and use > the resulting string as bpftool version. Series applied to bpf-next, thanks everyone!
Re: 4.14.9 doesn't boot (regression)
> On Dec 29, 2017, at 3:53 PM, Linus Torvalds > wrote: > >> On Fri, Dec 29, 2017 at 2:30 PM, Toralf Förster >> wrote: >> >> The bad news - the issue is not solved with the changed cflags. >> The good news - I could compile eventually a working config for my desktop >> (works fine with 4.14.10 with generic CPU) having a higher screen resolution >> during boot. >> >> So I made a "make distclean", followed by a "sudo zcat /proc/config.gz > >> .config", changed the .config to use MCORE2 instead of GENERIC and defined >> the string "-local" to ensure that the modules directory is really unique. >> Then I run "time make -j4 && sudo make modules_install && sudo cp >> arch/x86_64/boot/bzImage /boot/vmlinuz-0 && sudo grub-mkconfig -o >> /boot/grub/grub.cfg", booted and made 3 fotos which were uploaded to [1], >> look for IMG_* > > Ok, so what does seem to be consistent for everybody is that > double-fault in the NMI backtrace. > > So the fact that the NMI always hits on a double-fault does make me > suspect that it's a infinite stream of double-faults, and that is > presumably also what causes the RCU timeout. > > And as I pointed out elsewhere (damn two threads), I think that it > would help to simply catch the *first* double-fault. > > And I *think* that the only thing that can make a double-fault > silently be re-tried is the CONFIG_X86_ESPFIX64 case, so if you can > build a failing kernel with the CONFIG_X86_ESPFIX64 case disabled in > arch/x86/kernel/traps.c do_double_fault(), that would be interesting. Double faults use IST, so a double fault that double faults will effectively just start over rather than eventually running out of stack and triple faulting. But check out the registers. We have RSP = ...28fd8 and CR2 = ...27f08. IOW the double fault stack is ...28000 - ...28fff and we're somehow getting a failed page fault a couple hundred bytes below the bottom of the IST stack. IOW, I think we're just stuck in a neverending loop of stack overflows. (Also, Josh, the oops code should have printed the contents of the struct pt_regs at the top of the DF stack. Any idea why it didn't?) Toralf, can you send the complete output of: objdump -dr arch/x86/kernel/traps.o From the build tree of a nonworking kernel? Also, you wouldn't happen to be using Gentoo perchance? I already have two reports of a Gentoo system miscompiling the vDSO due to Gentoo enabling -fstack-check and GCC generating stack check code that is highly suboptimal, actively incorrect, and doesn't even manage to check the stack in a particularly helpful way. If this is indeed what's going on, I'm going to try to come up with a patch to outright fail the build on these buggy systems. We could probably fudge the build options to avoid the problem, but Gentoo really just needs fix its toolchain.
Re: [RFC PATCH v12 5/5] arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru
On Fri, Dec 29, 2017 at 6:55 PM, Tony Lindgren wrote:
> * Jeffy Chen [171226 02:41]:
>> Currently we are handling PCIe WAKE# irq in mrvl wifi driver.
>>
>> Move it to rockchip pcie port since we are going to handle it in the
>> pci core.
>
> Yes in the PCIe case, the pcie port node is the right place for
> the wakeirq instead of the child the mvl_wifi node. So one
> question further down below to verify this..
You seem to be using a convention by which the port represents the
whole "slot" or "PCI device" (as an entity consisting of up to 8
functions) connected to it.
That is fair enough as long as the port is not the top of a more
complex branch of the PCIe hierarchy, so maybe that case needs to be
made special somehow?
Also, I would document the convention by mentioning that the wakeup
signaled via that interrupt doesn't apply to the port itself, but to
the functions (endpoints) below it.
>> Also avoid this irq been considered as the PCI interrupt pin in the
>> of_irq_parse_pci().
>
> The above paragraph needs a bit more clarification to be
> readable :)
>
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> @@ -719,15 +719,16 @@ ap_i2c_audio: &i2c8 {
>> #size-cells = <2>;
>> ranges;
>>
>> + interrupts-extended = <&pcie0 1>, <&gpio0 8
>> IRQ_TYPE_LEVEL_LOW>;
>> + interrupt-names = "pci", "wakeup";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&wlan_host_wake_l>;
>> + wakeup-source;
>> +
>> mvl_wifi: wifi@0,0 {
>> compatible = "pci1b4b,2b42";
>> reg = <0x8301 0x0 0x 0x0 0x0010
>> 0x8301 0x0 0x0010 0x0 0x0010>;
>> - interrupt-parent = <&gpio0>;
>> - interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
>> - pinctrl-names = "default";
>> - pinctrl-0 = <&wlan_host_wake_l>;
>> - wakeup-source;
>> };
>> };
>> };
>
> So the above modifies pcie@0,0 node. And that node describes
> the particular PCIe port that the WLAN is connected to instead
> of describing the whole PCIe controller device, right?
>
> If so, then yeah it's totally where the wakeirq should be
> defined for a PCIe device in the dts file :)
As long as the convention used here is clear to everybody, that is.
Thanks,
Rafael
Re: 4.14.9 with CONFIG_MCORE2 fails to boot
On Fri, Dec 29, 2017 at 3:15 PM, Alexander Tsoy wrote: > В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет: >> >> What happens if you take a failing kernel, and then in >> arch/x86/kernel/traps.c do_double_fault(), you change the >> >> #ifdef CONFIG_X86_ESPFIX64 >> >> to just a >> >> #if 0 >> >> do you then get an actual double-fault oops report instead of the >> stall (and NMI oops)? > > This is what I get after disabling ESPFIX64 (see attachment). Ok, looks like it made no difference for you or for Toralf. So that was a waste of time. Damn. Also very strange how there's that double fault in the call trace, but no actual output from any double fault. Without the ESPFIX64 code, I don't see how that happens, but since I have no idea what is going on here, I'm obviously missing a lot. Hopefully somebody else has a clue or sees something I'm missing. Linus
Re: [RFC PATCH v12 1/5] dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
On Fri, Dec 29, 2017 at 6:57 PM, Tony Lindgren wrote: > * Jeffy Chen [171226 02:11]: >> We are going to handle PCIe WAKE# pin for PCI devices in the pci core, >> so add definitions of the optional PCIe WAKE# pin for PCI devices. >> >> Also add an definition of the optional PCI interrupt pin for PCI >> devices to distinguish it from the PCIe WAKE# pin. > >> --- a/Documentation/devicetree/bindings/pci/pci.txt >> +++ b/Documentation/devicetree/bindings/pci/pci.txt >> @@ -24,3 +24,13 @@ driver implementation may support the following >> properties: >> unsupported link speed, for instance, trying to do training for >> unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2' >> for gen2, and '1' for gen1. Any other values are invalid. >> + >> +PCI devices may support the following properties: > > This should say PCI ports instead of PCI devices. No, it is more accurate to say "PCI devices". Well, it actually gets somewhat confusing, because in the PCI terminology a "PCI device" means a physical piece of hardware that can be put into a single "slot" (think socket on a board) and may consist up to 8 functional units called "functions" which are each represented by a struct pci_dev. So there may be up to 8 struct pci_dev objects per "PCI device" (as per the standard language) and, BTW, drivers bind to functions (via the struct pci_dev objects). Now, WAKE# is shared by all functions within the same "PCI device" (I'm not sure if the standard specifies that directly, but at least it appears to be treated as an obvious physical limitation), so it may be useful to represent the "slot" or "device" level in the DT even though it has no struct device based representation in the kernel. >> +- interrupts: Interrupt specifier for each name in interrupt-names. >> +- interrupt-names: >> +May contain "wakeup" for PCIe WAKE# interrupt and "pci" for PCI >> interrupt. >> +The PCI devices may optionally include an 'interrupts' property that >> +represents the legacy PCI interrupt. And when we try to specify the PCIe >> +WAKE# pin, a corresponding 'interrupt-names' property is required to >> +distinguish them. >> -- >> 2.11.0 >> >>
linux-next: Signed-off-by missing for commit in the tip tree
Hi all,
Commit
113702e96dc7 ("x86/insn-eval: Add utility functions to get segment selector")
is missing a Signed-off-by from its author and committer.
It's possible its author and committer were both changed by the
cherry-pick ... Also, the commit message does not seem to describe what
this patch does.
--
Cheers,
Stephen Rothwell
Re: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
On Fri, Dec 29, 2017 at 6:15 PM, Tony Lindgren wrote: > * Rafael J. Wysocki [171228 17:33]: >> On Thursday, December 28, 2017 5:51:34 PM CET Tony Lindgren wrote: >> > >> > Well Brian had a concern where we would have to implement PM runtime >> > for all device drivers for PCI devices. >> >> Why would we? > > Seems at least I was a bit confused. In the PCIe case the WAKE# is > owned by the PCIe slot, not the child PCIe device. Well, it depends on what you mean by "slot" and "child device", but if my understanding of it is correct, WAKE# actually is "owned" by the latter. First, let me clarify the terminology. PCI slots are not really represented in the device hierarchy in Linux. They are represented by kernel objects for hotplug purposes, but these objects are not based on struct device. Generally, there are two kinds of PCI entities represented by struct pci_dev, bridges and endpoints (functions). Bridges may represent physical devices, like PCI-to-PCI bridges, or parts of physical devices, like PCIe ports. In PCIe, every port is logically represented by a bridge (and a PCI config space region with a Type 1 header). However, ports do not take actions like generating interrupts; the pieces of hardware containing them (switches, Root Complex) do that. Endpoints (functions) are children of bridges (e.g. PCIe ports) and bridges may be children of other bridges (like in a switch that is represented by a bus segment with one upstream bridge - the upstream port - and possibly multiple downstream bridges - downstream ports). So in PCI a parent always is a bridge (either a PCI bridge - a bridge between to PCI bus segments - or a host bridge) and if that is a PCIe port, it cannot "own" anything like WAKE#, because it is not affected by it in any way and doesn't take part in the handling of it. In the context of "Figure 5-4" in the spec, Case 1, what matters is that every "Slot" in the figure represents a bunch (up to 8) of endpoints (functions), but the "Slot" is not the parent of them. The port of the switch the "Slot" is connected to is the parent. WAKE# basically comes from one of the endpoints belonging to the "Slot" and you need to look into the config space regions for all of these endpoints to check which one has PME Status set and clear it (to acknowledge the PME and make the hardware stop asserting the WAKE# signal). So, from the software perspective, the endpoint (child) is the source of WAKE# and that should be reflected by DT properties IMO. > So you're right, there should be no need for the child PCIe device drivers to > implement runtime PM. There should be no need for that regardless. You only need an interrupt handler that will look for the endpoint with PME Status set, acknowledge it and possibly invoke runtime PM for the endpoint in question (if supported). All of that is standard and can happen at the bus type level and the interrupt handler I'm talking about may be based on pci_pme_wakeup() or pci_acpi_wake_dev(). > I was thinking the wakeirq case with WLAN on SDIO bus. Some WLAN > devices can have a hardwired OOB wakeirq wired to a GPIO controller. > In that case the wakeirq is owned by the child device driver > (WLAN controller) and not by the SDIO slot. I was earlier > thinking this is the same as the "Figure 5-4" case 1, but it's > not. Well, it is not in the sense that the endpoint driver is not expected to handle the wakeup interrupt by itself. The PCI bus type is responsible for that, but technically WAKE# comes from the endpoint (child). > So in the PCIe WAKE# case for device tree, we must have the > wakeirq property for the PCIe slot for the struct device managing > that slot, Which doesn't exist. > and not for the child device driver. I think it's > already this way in the most recent set of patches, I need to > look again. No, you need a wakeirq properly for the child *device* and that property will be consumed by the PCI layer. >> > So isn't my option 1 above similar to the PCIe spec "Figure 5-4" >> > case 2? >> >> No, it isn't, because in that case there is no practical difference >> between WAKE# and an in-band PME message sent by the device (Beacon) >> from the software perspective. >> >> WAKE# causes the switch to send a PME message upstream and that is >> handled by the Root Complex through the standard mechanism already >> supported by our existing PME driver (drivers/pci/pcie/pme.c). > > OK. So if "Figure 5-4" case 2 is already handled then and we need > to just deal with "Figure 5-4" case 1 :) Right. >> > Yeah. FYI, for the dedicated wakeirq cases I have, we need to keep >> > them masked during runtime to avoid tons of interrupts as they >> > are often wired to the RX pins. >> >> OK >> >> BTW, enable_irq_wake() should take care of the sharing, shouldn't it? > > That can be used to tell us which device has wakeirq enabled for > wake-up events, but only for resume not runtiem PM. We still have the > shared IRQ problem to deal with. And the PCIe subsy
Re: linux-next: Signed-off-by missing for commit in the bluetooth tree
Hi all,
On Sat, 30 Dec 2017 10:25:52 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> Commit
>
> 0a03f98b98c2 ("Bluetooth: Add a new 04ca:3015 QCA_ROME device")
>
> is missing a Signed-off-by from its .
^
committer
--
Cheers,
Stephen Rothwell
linux-next: Signed-off-by missing for commit in the tpmdd tree
Hi Jarkko,
Commit
c01386d6129f ("tpm: Update MAINTAINERS for Jason Gunthorpe")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[PATCH] Staging: ncpfs: dir: fixed a bracket coding style issue
Fixed a coding style issue.
Signed-off-by: Santha Meena Ramamoorthy
---
drivers/staging/ncpfs/dir.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ncpfs/dir.c b/drivers/staging/ncpfs/dir.c
index 0c57c5c..62a770f 100644
--- a/drivers/staging/ncpfs/dir.c
+++ b/drivers/staging/ncpfs/dir.c
@@ -46,8 +46,7 @@ extern int ncp_symlink(struct inode *, struct dentry *, const
char *);
#define ncp_symlink NULL
#endif
-const struct file_operations ncp_dir_operations =
-{
+const struct file_operations ncp_dir_operations = {
.llseek = generic_file_llseek,
.read = generic_read_dir,
.iterate= ncp_readdir,
@@ -57,8 +56,7 @@ const struct file_operations ncp_dir_operations =
#endif
};
-const struct inode_operations ncp_dir_inode_operations =
-{
+const struct inode_operations ncp_dir_inode_operations = {
.create = ncp_create,
.lookup = ncp_lookup,
.unlink = ncp_unlink,
--
2.7.4
linux-next: Signed-off-by missing for commit in the bluetooth tree
Hi all,
Commit
0a03f98b98c2 ("Bluetooth: Add a new 04ca:3015 QCA_ROME device")
is missing a Signed-off-by from its .
--
Cheers,
Stephen Rothwell
linux-next: Signed-off-by missing for commit in the v4l-dvb tree
Hi Mauro,
Commit
201b56737f4e ("media: fix semicolon.cocci warnings")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks
On Tue, 2017-12-26 at 17:32 -0800, Stephen Boyd wrote: > > I noticed we do have a few i2c based clock drivers... how are they ever > > supposed to work ? i2c bus controllers are allowed to sleep and the i2c > > core takes mutexes... > > We have clk_prepare()/clk_unprepare() for sleeping suckage. You > can use that, and i2c based clk drivers do that today. "suckage" ? Hehe ... the suckage should rather be stuff that cannot sleep. Arbitrary latencies and jitter caused by too much code wanting to be "atomic" when unnecessary are a bad thing. In the case of clocks like the aspeed where we have to wait for a rather long stabilization delay, way too long to legitimately do a non- sleepable delay with a lock held, do we need to do everything in prepare() then ? Ben.
Re: 4.14.9 with CONFIG_MCORE2 fails to boot
В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет: > ... > The fact that double faults seem to be implicated does make me want > to > try to disable that ESPFIX64 code in the #DF handler. > > What happens if you take a failing kernel, and then in > arch/x86/kernel/traps.c do_double_fault(), you change the > > #ifdef CONFIG_X86_ESPFIX64 > > to just a > > #if 0 > > do you then get an actual double-fault oops report instead of the > stall (and NMI oops)? This is what I get after disabling ESPFIX64 (see attachment). [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/64 (20170831/tbfadt-603) [0.00] ACPI BIOS Warning (bug): Incorrect checksum in table [TCPA] - 0x00, should be 0x7F (20170831/tbprint-211) [0.499855] Expanded resource Reserved due to conflict with PCI Bus :00 [0.506002] Expanded resource Reserved due to conflict with PCI Bus :00 [ 21.777011] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 21.778008] 0-...!: (0 ticks this GP) idle=b0a/140/0 softirq=158/158 fqs=0 [ 21.778008] (detected by 1, t=21002 jiffies, g=-254, c=-255, q=4) [0.776477] NMI backtrace for cpu 0 [0.776477] CPU: 0 PID: 114 Comm: modprobe Not tainted 4.15.0-rc5+ #6 [0.776477] Hardware name: Dell Inc. OptiPlex 760 /0M858N, BIOS A16 08/06/2013 [0.776477] RIP: 0010:paranoid_entry+0x0/0x70 [0.776477] RSP: :fe807f50 EFLAGS: 0083 [0.776477] RAX: b7c0 RBX: 0001 RCX: c101 [0.776477] RDX: 951a RSI: RDI: fe807f58 [0.776477] RBP: R08: R09: [0.776477] R10: R11: R12: a28b5b36 [0.776477] R13: R14: R15: [0.776477] FS: () GS:951ab7c0() knlGS: [0.776477] CS: 0010 DS: ES: CR0: 80050033 [0.776477] CR2: fe806f08 CR3: 00022d232000 CR4: 000406f0 [0.776477] Call Trace: [0.776477] <#DF> [0.776477] double_fault+0xc/0x30 [0.776477] RIP: 0010:do_double_fault+0xb/0xb0 [0.776477] RSP: :fe806f18 EFLAGS: 00010086 ORIG_RAX: [0.776477] RAX: b7c0 RBX: 0001 RCX: c101 [0.776477] RDX: 951a RSI: RDI: fe807f58 [0.776477] RBP: R08: R09: [0.776477] R10: R11: R12: a28b5b36 [0.776477] R13: R14: R15: [0.776477] ? page_fault+0x36/0x60 [0.776477] [0.776477] Code: 00 00 00 48 89 e7 31 f6 ff 15 45 02 57 00 e9 88 00 00 00 e8 93 00 00 00 48 89 e7 31 f6 ff 15 30 02 57 00 e9 43 01 00 00 0f 1f 00 4c 89 5c 24 38 4c 89 54 24 40 4c 89 4c 24 48 4c 89 44 24 50 [ 21.778008] rcu_preempt kthread starved for 21002 jiffies! g18446744073709551362 c18446744073709551361 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x402 ->cpu=0 [ 21.778008] Call Trace: [ 21.778008] ? __schedule+0x37f/0x7b0 [ 21.778008] ? preempt_count_add+0x64/0xa0 [ 21.778008] schedule+0x4a/0xa0 [ 21.778008] schedule_timeout+0x179/0x380 [ 21.778008] ? __next_timer_interrupt+0xd0/0xd0 [ 21.778008] rcu_gp_kthread+0x96b/0x1050 [ 21.778008] ? calc_global_load_tick+0x61/0x70 [ 21.778008] kthread+0xff/0x130 [ 21.778008] ? force_qs_rnp+0x1d0/0x1d0 [ 21.778008] ? kthread_create_worker_on_cpu+0x70/0x70 [ 21.778008] ret_from_fork+0x1f/0x30 [ 84.782011] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 84.783008] 0-...0: (0 ticks this GP) idle=b0a/140/0 softirq=158/158 fqs=15691 [ 84.783008] (detected by 1, t=84007 jiffies, g=-254, c=-255, q=4) [0.776477] NMI backtrace for cpu 0 [0.776477] CPU: 0 PID: 114 Comm: modprobe Not tainted 4.15.0-rc5+ #6 [0.776477] Hardware name: Dell Inc. OptiPlex 760 /0M858N, BIOS A16 08/06/2013 [0.776477] RIP: 0010:double_fault+0x0/0x30 [0.776477] RSP: :fe807fd0 EFLAGS: 0086 [0.776477] RAX: b7c0 RBX: 0001 RCX: c101 [0.776477] RDX: 951a RSI: RDI: fe807f58 [0.776477] RBP: R08: R09: [0.776477] R10: R11: R12: a28b5b36 [0.776477] R13: R14: R15: [0.776477] FS: () GS:951ab7c0() knlGS: [0.776477] CS: 0010 DS: ES: CR0: 80050033 [0.776477] CR2: fe806f08 CR3: 00022d232000 CR4: 000406f0 [0.776477] Call Trace: [0.776477] <#DF> [0.776477] do_double_fault+0xb/0xb0 [0.776477] [0.776477] Code: 05 00 00 48
Re: 4.14.9 doesn't boot (regression)
On 12/29/2017 11:53 PM, Linus Torvalds wrote: > So just change the > > #ifdef CONFIG_X86_ESPFIX64 > > into a > > #if 0 > > and see if instead of the RCU stall after 20 seconds, you get an > immediate double fault error report instead? well, 3 IMG_20171230_0008* should show the results https://zwiebeltoralf.de/pub/ -- Toralf PGP C4EACDDE 0076E94E
Re: 4.14.9 doesn't boot (regression)
On Fri, Dec 29, 2017 at 2:30 PM, Toralf Förster wrote: > > The bad news - the issue is not solved with the changed cflags. > The good news - I could compile eventually a working config for my desktop > (works fine with 4.14.10 with generic CPU) having a higher screen resolution > during boot. > > So I made a "make distclean", followed by a "sudo zcat /proc/config.gz > > .config", changed the .config to use MCORE2 instead of GENERIC and defined > the string "-local" to ensure that the modules directory is really unique. > Then I run "time make -j4 && sudo make modules_install && sudo cp > arch/x86_64/boot/bzImage /boot/vmlinuz-0 && sudo grub-mkconfig -o > /boot/grub/grub.cfg", booted and made 3 fotos which were uploaded to [1], > look for IMG_* Ok, so what does seem to be consistent for everybody is that double-fault in the NMI backtrace. So the fact that the NMI always hits on a double-fault does make me suspect that it's a infinite stream of double-faults, and that is presumably also what causes the RCU timeout. And as I pointed out elsewhere (damn two threads), I think that it would help to simply catch the *first* double-fault. And I *think* that the only thing that can make a double-fault silently be re-tried is the CONFIG_X86_ESPFIX64 case, so if you can build a failing kernel with the CONFIG_X86_ESPFIX64 case disabled in arch/x86/kernel/traps.c do_double_fault(), that would be interesting. So just change the #ifdef CONFIG_X86_ESPFIX64 into a #if 0 and see if instead of the RCU stall after 20 seconds, you get an immediate double fault error report instead? I'm still entirely confused about why that MCORE2 would make _any_ difference what-so-ever, so this is all fishing for random clues in the dark. Linus
[PATCH] objtool: fix segfault when missing '.shstrtab' section
This segfault happens when an input file provided to 'objtool orc generate' doesn't have a '.shstrtab' section (for instance, object files produced by clang don't have this section). Signed-off-by: Simon Ser --- tools/objtool/orc_gen.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c index e5ca31429..188f18185 100644 --- a/tools/objtool/orc_gen.c +++ b/tools/objtool/orc_gen.c @@ -165,7 +165,8 @@ int create_orc_sections(struct objtool_file *file) /* create .orc_unwind_ip and .rela.orc_unwind_ip sections */ sec = elf_create_section(file->elf, ".orc_unwind_ip", sizeof(int), idx); - + if (!sec) + return -1; ip_relasec = elf_create_rela_section(file->elf, sec); if (!ip_relasec) return -1; -- 2.15.1
[tip:timers/urgent] timerqueue: Document return values of timerqueue_add/del()
Commit-ID: 9f4533cd7334235cd4c9b9fb1b0b8791e2ba01a7
Gitweb: https://git.kernel.org/tip/9f4533cd7334235cd4c9b9fb1b0b8791e2ba01a7
Author: Thomas Gleixner
AuthorDate: Fri, 22 Dec 2017 15:51:15 +0100
Committer: Thomas Gleixner
CommitDate: Fri, 29 Dec 2017 23:13:10 +0100
timerqueue: Document return values of timerqueue_add/del()
The return values of timerqueue_add/del() are not documented in the kernel doc
comment. Add proper documentation.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Sebastian Siewior
Cc: r...@linutronix.de
Cc: Paul McKenney
Cc: Anna-Maria Gleixner
Link: https://lkml.kernel.org/r/20171222145337.872681...@linutronix.de
---
lib/timerqueue.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/timerqueue.c b/lib/timerqueue.c
index 4a720ed..0d54bcb 100644
--- a/lib/timerqueue.c
+++ b/lib/timerqueue.c
@@ -33,8 +33,9 @@
* @head: head of timerqueue
* @node: timer node to be added
*
- * Adds the timer node to the timerqueue, sorted by the
- * node's expires value.
+ * Adds the timer node to the timerqueue, sorted by the node's expires
+ * value. Returns true if the newly added timer is the first expiring timer in
+ * the queue.
*/
bool timerqueue_add(struct timerqueue_head *head, struct timerqueue_node *node)
{
@@ -70,7 +71,8 @@ EXPORT_SYMBOL_GPL(timerqueue_add);
* @head: head of timerqueue
* @node: timer node to be removed
*
- * Removes the timer node from the timerqueue.
+ * Removes the timer node from the timerqueue. Returns true if the queue is
+ * not empty after the remove.
*/
bool timerqueue_del(struct timerqueue_head *head, struct timerqueue_node *node)
{
[tip:timers/urgent] nohz: Prevent a timer interrupt storm in tick_nohz_stop_sched_tick()
Commit-ID: 5d62c183f9e9df1deeea0906d099a94e8a43047a
Gitweb: https://git.kernel.org/tip/5d62c183f9e9df1deeea0906d099a94e8a43047a
Author: Thomas Gleixner
AuthorDate: Fri, 22 Dec 2017 15:51:13 +0100
Committer: Thomas Gleixner
CommitDate: Fri, 29 Dec 2017 23:13:10 +0100
nohz: Prevent a timer interrupt storm in tick_nohz_stop_sched_tick()
The conditions in irq_exit() to invoke tick_nohz_irq_exit() which
subsequently invokes tick_nohz_stop_sched_tick() are:
if ((idle_cpu(cpu) && !need_resched()) || tick_nohz_full_cpu(cpu))
If need_resched() is not set, but a timer softirq is pending then this is
an indication that the softirq code punted and delegated the execution to
softirqd. need_resched() is not true because the current interrupted task
takes precedence over softirqd.
Invoking tick_nohz_irq_exit() in this case can cause an endless loop of
timer interrupts because the timer wheel contains an expired timer, but
softirqs are not yet executed. So it returns an immediate expiry request,
which causes the timer to fire immediately again. Lather, rinse and
repeat
Prevent that by adding a check for a pending timer soft interrupt to the
conditions in tick_nohz_stop_sched_tick() which avoid calling
get_next_timer_interrupt(). That keeps the tick sched timer on the tick and
prevents a repetitive programming of an already expired timer.
Reported-by: Sebastian Siewior
Signed-off-by: Thomas Gleixner
Acked-by: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Paul McKenney
Cc: Anna-Maria Gleixner
Cc: Sebastian Siewior
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1712272156050.2431@nanos
---
kernel/time/tick-sched.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 77555fa..f7cc7ab 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -650,6 +650,11 @@ static void tick_nohz_restart(struct tick_sched *ts,
ktime_t now)
ts->next_tick = 0;
}
+static inline bool local_timer_softirq_pending(void)
+{
+ return local_softirq_pending() & TIMER_SOFTIRQ;
+}
+
static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
ktime_t now, int cpu)
{
@@ -666,8 +671,18 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
} while (read_seqretry(&jiffies_lock, seq));
ts->last_jiffies = basejiff;
- if (rcu_needs_cpu(basemono, &next_rcu) ||
- arch_needs_cpu() || irq_work_needs_cpu()) {
+ /*
+* Keep the periodic tick, when RCU, architecture or irq_work
+* requests it.
+* Aside of that check whether the local timer softirq is
+* pending. If so its a bad idea to call get_next_timer_interrupt()
+* because there is an already expired timer, so it will request
+* immeditate expiry, which rearms the hardware timer with a
+* minimal delta which brings us back to this place
+* immediately. Lather, rinse and repeat...
+*/
+ if (rcu_needs_cpu(basemono, &next_rcu) || arch_needs_cpu() ||
+ irq_work_needs_cpu() || local_timer_softirq_pending()) {
next_tick = basemono + TICK_NSEC;
} else {
/*
Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
Hi Russell, On Thu, Dec 28, 2017 at 06:59:21PM +, Russell King - ARM Linux wrote: > On Thu, Dec 28, 2017 at 11:04:16AM +0100, Antoine Tenart wrote: > > > > That's not what I remembered. You had some valid points, and others > > related to PHY modes the driver wasn't supporting before the phylink > > transition. My understanding of this was that you wanted a full > > featured support while I only wanted to convert the already supported > > modes. > > You are mistaken - you can get a full refresher on where things were > at via https://patchwork.kernel.org/patch/9963971/ I read it again and still have the same feeling. There's been a misunderstanding at some point. Anyway, let's move forward :) > 1. I asked for details about what mvpp2.c supports that phylink does >not (as you indicated that there were certain things that mvpp2 >supports that phylink does not.) I'm still awaiting a response. I don't remember PHY modes supported in the PPv2 driver that aren't supported in PHYLINK. I think this point is the main misunderstanding. I thought you wanted me to support modes unsupported in the PPv2 driver before. But you explained quite well what these comments were about below. So I guess this point is resolved (aka I'll have to take your comments into account for the v2). > 2. 25th Sept, you indicated that you would get someone to test >an issue related to in-band AN. No results of that testing have >been forthcoming. That's right. I asked someone to make a test, but did not get an answer. And because the PHYLINK patch stalled on my side I kinda forget about it. I'll try again to have this test made. > I am not after a full featured support, what I'm after is ensuring > that phylink is (a) used correctly and (b) implementations using it > are correct. Part of that is ensuring that users don't introduce > unexpected failure conditions. > > So, when you do this in the validate() callback: > > + phylink_set(mask, 1000baseX_Full); > > and then do this in the mac_config() callback: > > + if (!phy_interface_mode_is_rgmii(port->phy_interface) && > + port->phy_interface != PHY_INTERFACE_MODE_SGMII) > + return; > > and this in the link_state() callback: > > + if (!phy_interface_mode_is_rgmii(port->phy_interface) && > + port->phy_interface != PHY_INTERFACE_MODE_SGMII) > + return 0; > > the result is that phylink thinks that you support 1000base-X modes, > and it will call mac_config() asking for 1000base-X, but you silently > ignore that, leaving the hardware configured in whatever state it was. > That leads to a silent failure as far as the user is concerned. > > So, if you do not intend to support 1000base-X initially, don't > allow it in the validate callback until you do. > > It gets worse, because the return in link_state() means that phylink > thinks that the link is up if it has requested 1000base-X, which it > won't be unless you've properly configured it. > > It's this kind of unreliability that I was concerned about in your > patch. I'm not demanding "full featured implementation" but I do > want you to use it correctly. Thanks for the detailed explanations! > > > What I'm most concerned about, given the bindings for comphy that > > > have been merged, is that Free Electrons is pushing forward seemingly > > > with no regard to the requirement that the serdes lanes are dynamically > > > reconfigurable, and that's a basic requirement for SFP, and for the > > > 88x3310 PHYs on the Macchiatobin platform. > > > > The main idea behind the comphy driver is to provide a way to > > reconfigure the serdes lanes at runtime. Could you develop what are > > blocking points to properly support SFP, regarding the current comphy > > support? > > If it supports serdes lane mode reconfiguration (iow, switching between > 1000base-X, 2500base-X, SGMII, 10G-KR), then that's all that's required. It does, and the PPv2 driver already ask the COMPHY driver to perform these reconfigurations (when using the 10G/1G interface on the mcbin for example). Thanks! Antoine -- Antoine Ténart, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[tip:timers/urgent] timers: Invoke timer_start_debug() where it makes sense
Commit-ID: fd45bb77ad682be728d1002431d77b8c73342836
Gitweb: https://git.kernel.org/tip/fd45bb77ad682be728d1002431d77b8c73342836
Author: Thomas Gleixner
AuthorDate: Fri, 22 Dec 2017 15:51:14 +0100
Committer: Thomas Gleixner
CommitDate: Fri, 29 Dec 2017 23:13:10 +0100
timers: Invoke timer_start_debug() where it makes sense
The timer start debug function is called before the proper timer base is
set. As a consequence the trace data contains the stale CPU and flags
values.
Call the debug function after setting the new base and flags.
Fixes: 500462a9de65 ("timers: Switch to a non-cascading wheel")
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Sebastian Siewior
Cc: sta...@vger.kernel.org
Cc: r...@linutronix.de
Cc: Paul McKenney
Cc: Anna-Maria Gleixner
Link: https://lkml.kernel.org/r/20171222145337.792907...@linutronix.de
---
kernel/time/timer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 6be576e..89a9e1b 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1007,8 +1007,6 @@ __mod_timer(struct timer_list *timer, unsigned long
expires, unsigned int option
if (!ret && (options & MOD_TIMER_PENDING_ONLY))
goto out_unlock;
- debug_activate(timer, expires);
-
new_base = get_target_base(base, timer->flags);
if (base != new_base) {
@@ -1032,6 +1030,8 @@ __mod_timer(struct timer_list *timer, unsigned long
expires, unsigned int option
}
}
+ debug_activate(timer, expires);
+
timer->expires = expires;
/*
* If 'idx' was calculated above and the base time did not advance
[tip:timers/urgent] timers: Reinitialize per cpu bases on hotplug
Commit-ID: 26456f87aca7157c057de65c9414b37f1ab881d1
Gitweb: https://git.kernel.org/tip/26456f87aca7157c057de65c9414b37f1ab881d1
Author: Thomas Gleixner
AuthorDate: Wed, 27 Dec 2017 21:37:25 +0100
Committer: Thomas Gleixner
CommitDate: Fri, 29 Dec 2017 23:13:09 +0100
timers: Reinitialize per cpu bases on hotplug
The timer wheel bases are not (re)initialized on CPU hotplug. That leaves
them with a potentially stale clk and next_expiry valuem, which can cause
trouble then the CPU is plugged.
Add a prepare callback which forwards the clock, sets next_expiry to far in
the future and reset the control flags to a known state.
Set base->must_forward_clk so the first timer which is queued will try to
forward the clock to current jiffies.
Fixes: 500462a9de65 ("timers: Switch to a non-cascading wheel")
Reported-by: Paul E. McKenney
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Sebastian Siewior
Cc: Anna-Maria Gleixner
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1712272152200.2431@nanos
---
include/linux/cpuhotplug.h | 2 +-
include/linux/timer.h | 4 +++-
kernel/cpu.c | 4 ++--
kernel/time/timer.c| 15 +++
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 201ab72..1a32e55 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -86,7 +86,7 @@ enum cpuhp_state {
CPUHP_MM_ZSWP_POOL_PREPARE,
CPUHP_KVM_PPC_BOOK3S_PREPARE,
CPUHP_ZCOMP_PREPARE,
- CPUHP_TIMERS_DEAD,
+ CPUHP_TIMERS_PREPARE,
CPUHP_MIPS_SOC_PREPARE,
CPUHP_BP_PREPARE_DYN,
CPUHP_BP_PREPARE_DYN_END= CPUHP_BP_PREPARE_DYN + 20,
diff --git a/include/linux/timer.h b/include/linux/timer.h
index 04af640..2448f9c 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -207,9 +207,11 @@ unsigned long round_jiffies_up(unsigned long j);
unsigned long round_jiffies_up_relative(unsigned long j);
#ifdef CONFIG_HOTPLUG_CPU
+int timers_prepare_cpu(unsigned int cpu);
int timers_dead_cpu(unsigned int cpu);
#else
-#define timers_dead_cpu NULL
+#define timers_prepare_cpu NULL
+#define timers_dead_cpuNULL
#endif
#endif
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 41376c3..9785847 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1277,9 +1277,9 @@ static struct cpuhp_step cpuhp_bp_states[] = {
* before blk_mq_queue_reinit_notify() from notify_dead(),
* otherwise a RCU stall occurs.
*/
- [CPUHP_TIMERS_DEAD] = {
+ [CPUHP_TIMERS_PREPARE] = {
.name = "timers:dead",
- .startup.single = NULL,
+ .startup.single = timers_prepare_cpu,
.teardown.single= timers_dead_cpu,
},
/* Kicks the plugged cpu into life */
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 19a9c3d..6be576e 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1853,6 +1853,21 @@ static void migrate_timer_list(struct timer_base
*new_base, struct hlist_head *h
}
}
+int timers_prepare_cpu(unsigned int cpu)
+{
+ struct timer_base *base;
+ int b;
+
+ for (b = 0; b < NR_BASES; b++) {
+ base = per_cpu_ptr(&timer_bases[b], cpu);
+ base->clk = jiffies;
+ base->next_expiry = base->clk + NEXT_TIMER_MAX_DELTA;
+ base->is_idle = false;
+ base->must_forward_clk = true;
+ }
+ return 0;
+}
+
int timers_dead_cpu(unsigned int cpu)
{
struct timer_base *old_base;
[tip:timers/urgent] timers: Use deferrable base independent of base::nohz_active
Commit-ID: ced6d5c11d3e7b342f1a80f908e6756ebd4b8ddd
Gitweb: https://git.kernel.org/tip/ced6d5c11d3e7b342f1a80f908e6756ebd4b8ddd
Author: Anna-Maria Gleixner
AuthorDate: Fri, 22 Dec 2017 15:51:12 +0100
Committer: Thomas Gleixner
CommitDate: Fri, 29 Dec 2017 23:13:09 +0100
timers: Use deferrable base independent of base::nohz_active
During boot and before base::nohz_active is set in the timer bases, deferrable
timers are enqueued into the standard timer base. This works correctly as
long as base::nohz_active is false.
Once it base::nohz_active is set and a timer which was enqueued before that
is accessed the lock selector code choses the lock of the deferred
base. This causes unlocked access to the standard base and in case the
timer is removed it does not clear the pending flag in the standard base
bitmap which causes get_next_timer_interrupt() to return bogus values.
To prevent that, the deferrable timers must be enqueued in the deferrable
base, even when base::nohz_active is not set. Those deferrable timers also
need to be expired unconditional.
Fixes: 500462a9de65 ("timers: Switch to a non-cascading wheel")
Signed-off-by: Anna-Maria Gleixner
Signed-off-by: Thomas Gleixner
Reviewed-by: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Sebastian Siewior
Cc: sta...@vger.kernel.org
Cc: r...@linutronix.de
Cc: Paul McKenney
Link: https://lkml.kernel.org/r/20171222145337.633328...@linutronix.de
---
kernel/time/timer.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index ffebcf8..19a9c3d 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -823,11 +823,10 @@ static inline struct timer_base *get_timer_cpu_base(u32
tflags, u32 cpu)
struct timer_base *base = per_cpu_ptr(&timer_bases[BASE_STD], cpu);
/*
-* If the timer is deferrable and nohz is active then we need to use
-* the deferrable base.
+* If the timer is deferrable and NO_HZ_COMMON is set then we need
+* to use the deferrable base.
*/
- if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active &&
- (tflags & TIMER_DEFERRABLE))
+ if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && (tflags & TIMER_DEFERRABLE))
base = per_cpu_ptr(&timer_bases[BASE_DEF], cpu);
return base;
}
@@ -837,11 +836,10 @@ static inline struct timer_base
*get_timer_this_cpu_base(u32 tflags)
struct timer_base *base = this_cpu_ptr(&timer_bases[BASE_STD]);
/*
-* If the timer is deferrable and nohz is active then we need to use
-* the deferrable base.
+* If the timer is deferrable and NO_HZ_COMMON is set then we need
+* to use the deferrable base.
*/
- if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active &&
- (tflags & TIMER_DEFERRABLE))
+ if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && (tflags & TIMER_DEFERRABLE))
base = this_cpu_ptr(&timer_bases[BASE_DEF]);
return base;
}
@@ -1684,7 +1682,7 @@ static __latent_entropy void run_timer_softirq(struct
softirq_action *h)
base->must_forward_clk = false;
__run_timers(base);
- if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active)
+ if (IS_ENABLED(CONFIG_NO_HZ_COMMON))
__run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]));
}
[PATCH] objtool: fix segfault when missing parameter
Fixes a segfault when no parameter is provided to 'objtool orc'.
Signed-off-by: Simon Ser
---
tools/objtool/builtin-orc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/builtin-orc.c b/tools/objtool/builtin-orc.c
index 4c6b5c9ef..91e8e19ff 100644
--- a/tools/objtool/builtin-orc.c
+++ b/tools/objtool/builtin-orc.c
@@ -44,6 +44,9 @@ int cmd_orc(int argc, const char **argv)
const char *objname;
argc--; argv++;
+ if (argc <= 0)
+ usage_with_options(orc_usage, check_options);
+
if (!strncmp(argv[0], "gen", 3)) {
argc = parse_options(argc, argv, check_options, orc_usage, 0);
if (argc != 1)
@@ -52,7 +55,6 @@ int cmd_orc(int argc, const char **argv)
objname = argv[0];
return check(objname, no_fp, no_unreachable, true);
-
}
if (!strcmp(argv[0], "dump")) {
--
2.15.1
Re: [PATCH] staging: irda: net: Fix warning for incomplete Declarations in irlap.c
Hi Vaibhav, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.15-rc5 next-20171222] [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/Vaibhav-Kothari/staging-irda-net-Fix-warning-for-incomplete-Declarations-in-irlap-c/20171230-023604 config: x86_64-allyesdebian (attached as .config) compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/staging/irda/net/timer.o: In function `irlap_start_query_timer': timer.c:(.text+0xcb): undefined reference to `sysctl_slot_timeout' >> drivers/staging/irda/net/irsysctl.o:(.data+0x148): undefined reference to >> `sysctl_slot_timeout' >> drivers/staging/irda/net/irsysctl.o:(.data+0x2c8): undefined reference to >> `sysctl_warn_noreply_time' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: 4.14.9 doesn't boot (regression)
On 12/29/2017 10:17 PM, Linus Torvalds wrote: > On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster > wrote: >> On 12/29/2017 09:12 PM, Linus Torvalds wrote: >>> instead, and see if that makes a difference, that would narrow down >>> the possible root cause of this problem. >> >> not at this ThinkPad T440s (didn't test at the server with an i7-3930). >> >> Boot stops just at: >> >> tsc: Refined TSC clocksource calibration: 2494.225 MHz >> clocksource: tsc: mask: 0x max_cycles: >> 0x23f3ea95b09, max_idle_ns: 440795287034 ns > > Uhhuh. So for Alexander Troy, just getting rid of the -march=core2 > fixed the boot. > > But not for you. > > Strange. It really looked like the exact same thing. > >> This is a "Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz" with gcc-6.4 > > Yeah, other reporters of this have used gcc-6.4.0 too. > > But there's been some muddying of the waters there too - changing > compilers have fixed it for some cases, but there's at least one > report that a kernel build with gcc-7.2.0 still had the issue (and > another that said it didn't). > > But the MCORE2 was consistent for several people - including you. > Until this point. > > Strange. > > The only other thing (apart from the compiler flag) that MCORE2 > results in is to enable > > CONFIG_X86_INTEL_USERCOPY > CONFIG_X86_USE_PPRO_CHECKSUM > CONFIG_X86_P6_NOP > > and the two first of those shouldn't even matter on x86-64, and I > don't see that last one making any difference either. > > So because it looks so impossible that the "-march=core2" didn't make > a difference for you, I'll ask you to please double-check that you > actually booted into the right kernel. > > Sorry for doubting you, but your report just broke the _one_ > consistent thing we've seen about this bug. > > Linus > I double-checked it. The bad news - the issue is not solved with the changed cflags. The good news - I could compile eventually a working config for my desktop (works fine with 4.14.10 with generic CPU) having a higher screen resolution during boot. So I made a "make distclean", followed by a "sudo zcat /proc/config.gz > .config", changed the .config to use MCORE2 instead of GENERIC and defined the string "-local" to ensure that the modules directory is really unique. Then I run "time make -j4 && sudo make modules_install && sudo cp arch/x86_64/boot/bzImage /boot/vmlinuz-0 && sudo grub-mkconfig -o /boot/grub/grub.cfg", booted and made 3 fotos which were uploaded to [1], look for IMG_* [1] https://zwiebeltoralf.de/pub/ -- Toralf PGP C4EACDDE 0076E94E
Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
On Fri, Dec 29, 2017 at 7:54 PM, Theodore Ts'o wrote: > On Fri, Dec 29, 2017 at 08:19:59AM -0800, Joe Perches wrote: >> >> Has it been legally reviewed and accepted that removal >> of the BSD license text from individual source files is >> appropriate and meets the legal requirements of >> following the BSD license on a per-file basis? >> >> And if so, who did this review? >> >> Is there any license that does not allow removal of the >> license text and does not allow simple substitution of >> the SPDX license identifier in each individual file? > > The work to use SPDX lines instead of individual licenses was done by > Greg K-H in close consultation with Linux Foundation counsels, so I > would assume that they did look at that particular issue. This is correct. And this is in addition to the discussion in the SPDX group at the LF (that includes several FOSS-savvy and prominent FOSS lawyers) that did design the SPDX spec. > IANAL, but I've talked to lawyers about this issue, and in my > experience if you talk to three lawyers you will easily get six > opinions. And that's on a good day: you may get more than six on a bad one. But on the other hand, they tend also to defer to standards, and established community norms. > As far as I know, none of the licenses explicitly say > copyright license must be on each file. Just that the distribution of > source must include the copyright and license statement. Exactly how > that is done is not explicitly specified. This is also my take. What is done here is not much different than refactoring duplicated code so it leaves in a single place: - by "value" at the root in COPYING and in the Documentation. - by "reference" in the code proper as SPDX ids. Therefore essential and common requirements to include the license text is fulfilled in the kernel. Note that there are a few offenders that will need to clean up their acts as they came up will both long and "un-removable and un-alterable" crazy legalese blurbs [1] prefix this: "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER" These will have to be taken care on a case by case basis. These are pretty stupid and IMHO should have never been allowed to be added to the kernel in the first place and are ugly warts. It could very well be that these are not really GPL-compliant notices FWIW: keeping notices and copyrights is quite different from a restriction of altering things by moving them around which is exactly what is happening with the SPDX-ification here. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5 -- Cordially Philippe Ombredanne
[PATCH] fs: coding style requires spaces around < and =
The coding style states that one space around = and < are required. This is consistent and more nice to read. Signed-off-by: Hugh Sipière --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index a062d75109cb..5dc7b549d2ed 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -1665,7 +1665,7 @@ static long do_io_submit(aio_context_t ctx_id, long nr, * AKPM: should this return a partial result if some of the IOs were * successfully submitted? */ - for (i=0; i
