[PATCH] spi: sun6i: disable/unprepare clocks on remove
sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable
clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure
that sun6i_spi_runtime_suspend() is called if needed.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 3558fe900e8af spi: sunxi: Add Allwinner A31 SPI controller driver
Signed-off-by: Tobias Jordan
---
Found by LDV and discussed as RFC before; compile-tested.
drivers/spi/spi-sun6i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index fb38234249a8..8533f4edd00a 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -541,7 +541,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
static int sun6i_spi_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_force_suspend(&pdev->dev);
return 0;
}
--
2.11.0
[PATCH 4.9 034/109] dax: Avoid page invalidation races and unnecessary radix tree traversals
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
[ Upstream commit e3fce68cdbed297d927e993b3ea7b8b1cee545da ]
Currently dax_iomap_rw() takes care of invalidating page tables and
evicting hole pages from the radix tree when write(2) to the file
happens. This invalidation is only necessary when there is some block
allocation resulting from write(2). Furthermore in current place the
invalidation is racy wrt page fault instantiating a hole page just after
we have invalidated it.
So perform the page invalidation inside dax_iomap_actor() where we can
do it only when really necessary and after blocks have been allocated so
nobody will be instantiating new hole pages anymore.
Reviewed-by: Christoph Hellwig
Reviewed-by: Ross Zwisler
Signed-off-by: Jan Kara
Signed-off-by: Dan Williams
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/dax.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1265,6 +1265,17 @@ iomap_dax_actor(struct inode *inode, lof
if (WARN_ON_ONCE(iomap->type != IOMAP_MAPPED))
return -EIO;
+ /*
+* Write can allocate block for an area which has a hole page mapped
+* into page tables. We have to tear down these mappings so that data
+* written by write(2) is visible in mmap.
+*/
+ if ((iomap->flags & IOMAP_F_NEW) && inode->i_mapping->nrpages) {
+ invalidate_inode_pages2_range(inode->i_mapping,
+ pos >> PAGE_SHIFT,
+ (end - 1) >> PAGE_SHIFT);
+ }
+
while (pos < end) {
unsigned offset = pos & (PAGE_SIZE - 1);
struct blk_dax_ctl dax = { 0 };
@@ -1329,23 +1340,6 @@ iomap_dax_rw(struct kiocb *iocb, struct
if (iov_iter_rw(iter) == WRITE)
flags |= IOMAP_WRITE;
- /*
-* Yes, even DAX files can have page cache attached to them: A zeroed
-* page is inserted into the pagecache when we have to serve a write
-* fault on a hole. It should never be dirtied and can simply be
-* dropped from the pagecache once we get real data for the page.
-*
-* XXX: This is racy against mmap, and there's nothing we can do about
-* it. We'll eventually need to shift this down even further so that
-* we can check if we allocated blocks over a hole first.
-*/
- if (mapping->nrpages) {
- ret = invalidate_inode_pages2_range(mapping,
- pos >> PAGE_SHIFT,
- (pos + iov_iter_count(iter) - 1) >> PAGE_SHIFT);
- WARN_ON_ONCE(ret);
- }
-
while (iov_iter_count(iter)) {
ret = iomap_apply(inode, pos, iov_iter_count(iter), flags, ops,
iter, iomap_dax_actor);
[PATCH 4.9 031/109] kprobes/x86: Disable preemption in ftrace-based jprobes
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
[ Upstream commit 5bb4fc2d8641219732eb2bb654206775a4219aca ]
Disable preemption in ftrace-based jprobe handlers as
described in Documentation/kprobes.txt:
"Probe handlers are run with preemption disabled."
This will fix jprobes behavior when CONFIG_PREEMPT=y.
Signed-off-by: Masami Hiramatsu
Cc: Alexei Starovoitov
Cc: Alexei Starovoitov
Cc: Ananth N Mavinakayanahalli
Cc: Linus Torvalds
Cc: Paul E . McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/150581530024.32348.9863783558598926771.stgit@devbox
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kprobes/ftrace.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -26,7 +26,7 @@
#include "common.h"
static nokprobe_inline
-int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+void __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb, unsigned long orig_ip)
{
/*
@@ -41,20 +41,21 @@ int __skip_singlestep(struct kprobe *p,
__this_cpu_write(current_kprobe, NULL);
if (orig_ip)
regs->ip = orig_ip;
- return 1;
}
int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
- if (kprobe_ftrace(p))
- return __skip_singlestep(p, regs, kcb, 0);
- else
- return 0;
+ if (kprobe_ftrace(p)) {
+ __skip_singlestep(p, regs, kcb, 0);
+ preempt_enable_no_resched();
+ return 1;
+ }
+ return 0;
}
NOKPROBE_SYMBOL(skip_singlestep);
-/* Ftrace callback handler for kprobes */
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct pt_regs *regs)
{
@@ -77,13 +78,17 @@ void kprobe_ftrace_handler(unsigned long
/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
regs->ip = ip + sizeof(kprobe_opcode_t);
+ /* To emulate trap based kprobes, preempt_disable here */
+ preempt_disable();
__this_cpu_write(current_kprobe, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (!p->pre_handler || !p->pre_handler(p, regs))
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
__skip_singlestep(p, regs, kcb, orig_ip);
+ preempt_enable_no_resched();
+ }
/*
* If pre_handler returns !0, it sets regs->ip and
-* resets current kprobe.
+* resets current kprobe, and keep preempt count +1.
*/
}
end:
Re: [PATCH v4 2/2] dt-bindings: add eeprom "at24,no-read-rollover" property
> at24 is not a vendor prefix. Either this is atmel specific and you want > atmel,no-read-rollover or it is for all vendors at24 compatible eeproms > and you want at24-no-read-rollover. Or just drop the at24 if this > binding is in fact for just at24 eeproms as none of the other properties > has at24 in them. Bartosz, shall I rename at24,no-read-rollover -> no-read-rollover ?
[PATCH 4.9 028/109] sysrq : fix Show Regs call trace on ARM
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jibin Xu
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[] dump_backtrace+0x0/0x1d0
[] show_stack+0x24/0x30
[] dump_stack+0x90/0xb0
[] check_preemption_disabled+0x100/0x108
[] __this_cpu_preempt_check+0x18/0x20
[] sysrq_handle_showregs+0x1c/0x40
[] __handle_sysrq+0x12c/0x1a0
[] write_sysrq_trigger+0x60/0x70
[] proc_reg_write+0x90/0xd0
[] __vfs_write+0x48/0x90
[] vfs_write+0xa4/0x190
[] SyS_write+0x54/0xb0
[] el0_svc_naked+0x24/0x28
This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.
Signed-off-by: Jibin Xu
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/sysrq.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -243,8 +243,10 @@ static void sysrq_handle_showallcpus(int
* architecture has no support for it:
*/
if (!trigger_all_cpu_backtrace()) {
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+ if (in_irq())
+ regs = get_irq_regs();
if (regs) {
pr_info("CPU%d:\n", smp_processor_id());
show_regs(regs);
@@ -263,7 +265,10 @@ static struct sysrq_key_op sysrq_showall
static void sysrq_handle_showregs(int key)
{
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+
+ if (in_irq())
+ regs = get_irq_regs();
if (regs)
show_regs(regs);
perf_event_print_debug();
[PATCH 4.9 036/109] l2tp: take remote address into account in l2tp_ip and l2tp_ip6 socket lookups
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Guillaume Nault
[ Upstream commit a9b2dff80be979432484afaf7f8d8e73f9e8838a ]
For connected sockets, __l2tp_ip{,6}_bind_lookup() needs to check the
remote IP when looking for a matching socket. Otherwise a connected
socket can receive traffic not originating from its peer.
Drop l2tp_ip_bind_lookup() and l2tp_ip6_bind_lookup() instead of
updating their prototype, as these functions aren't used.
Signed-off-by: Guillaume Nault
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/l2tp/l2tp_ip.c | 19 ++-
net/l2tp/l2tp_ip6.c | 20 ++--
2 files changed, 12 insertions(+), 27 deletions(-)
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -48,7 +48,8 @@ static inline struct l2tp_ip_sock *l2tp_
return (struct l2tp_ip_sock *)sk;
}
-static struct sock *__l2tp_ip_bind_lookup(struct net *net, __be32 laddr, int
dif, u32 tunnel_id)
+static struct sock *__l2tp_ip_bind_lookup(const struct net *net, __be32 laddr,
+ __be32 raddr, int dif, u32 tunnel_id)
{
struct sock *sk;
@@ -62,6 +63,7 @@ static struct sock *__l2tp_ip_bind_looku
if ((l2tp->conn_id == tunnel_id) &&
net_eq(sock_net(sk), net) &&
!(inet->inet_rcv_saddr && inet->inet_rcv_saddr != laddr) &&
+ (!inet->inet_daddr || !raddr || inet->inet_daddr == raddr)
&&
(!sk->sk_bound_dev_if || !dif ||
sk->sk_bound_dev_if == dif))
goto found;
@@ -72,15 +74,6 @@ found:
return sk;
}
-static inline struct sock *l2tp_ip_bind_lookup(struct net *net, __be32 laddr,
int dif, u32 tunnel_id)
-{
- struct sock *sk = __l2tp_ip_bind_lookup(net, laddr, dif, tunnel_id);
- if (sk)
- sock_hold(sk);
-
- return sk;
-}
-
/* When processing receive frames, there are two cases to
* consider. Data frames consist of a non-zero session-id and an
* optional cookie. Control frames consist of a regular L2TP header
@@ -186,8 +179,8 @@ pass_up:
struct iphdr *iph = (struct iphdr *) skb_network_header(skb);
read_lock_bh(&l2tp_ip_lock);
- sk = __l2tp_ip_bind_lookup(net, iph->daddr, inet_iif(skb),
- tunnel_id);
+ sk = __l2tp_ip_bind_lookup(net, iph->daddr, iph->saddr,
+ inet_iif(skb), tunnel_id);
if (!sk) {
read_unlock_bh(&l2tp_ip_lock);
goto discard;
@@ -289,7 +282,7 @@ static int l2tp_ip_bind(struct sock *sk,
inet->inet_saddr = 0; /* Use device */
write_lock_bh(&l2tp_ip_lock);
- if (__l2tp_ip_bind_lookup(net, addr->l2tp_addr.s_addr,
+ if (__l2tp_ip_bind_lookup(net, addr->l2tp_addr.s_addr, 0,
sk->sk_bound_dev_if, addr->l2tp_conn_id)) {
write_unlock_bh(&l2tp_ip_lock);
ret = -EADDRINUSE;
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -59,12 +59,14 @@ static inline struct l2tp_ip6_sock *l2tp
static struct sock *__l2tp_ip6_bind_lookup(struct net *net,
struct in6_addr *laddr,
+ const struct in6_addr *raddr,
int dif, u32 tunnel_id)
{
struct sock *sk;
sk_for_each_bound(sk, &l2tp_ip6_bind_table) {
const struct in6_addr *sk_laddr = inet6_rcv_saddr(sk);
+ const struct in6_addr *sk_raddr = &sk->sk_v6_daddr;
struct l2tp_ip6_sock *l2tp = l2tp_ip6_sk(sk);
if (l2tp == NULL)
@@ -73,6 +75,7 @@ static struct sock *__l2tp_ip6_bind_look
if ((l2tp->conn_id == tunnel_id) &&
net_eq(sock_net(sk), net) &&
(!sk_laddr || ipv6_addr_any(sk_laddr) ||
ipv6_addr_equal(sk_laddr, laddr)) &&
+ (!raddr || ipv6_addr_any(sk_raddr) ||
ipv6_addr_equal(sk_raddr, raddr)) &&
(!sk->sk_bound_dev_if || !dif ||
sk->sk_bound_dev_if == dif))
goto found;
@@ -83,17 +86,6 @@ found:
return sk;
}
-static inline struct sock *l2tp_ip6_bind_lookup(struct net *net,
- struct in6_addr *laddr,
- int dif, u32 tunnel_id)
-{
- struct sock *sk = __l2tp_ip6_bind_lookup(net, laddr, dif, tunnel_id);
- if (sk)
- sock_hold(sk);
-
- return sk;
-}
-
/* When processing receive frames, there are two cases to
* consider. Data frames consist of a non-zero session-id and an
* optional cookie. Control frames consist of a regular L2TP header
@@ -20
[PATCH 4.9 037/109] dmaengine: stm32-dma: Set correct args number for DMA request from DT
4.9-stable review patch. If anyone has any objections, please let me know. -- From: M'boumba Cedric Madianga [ Upstream commit 7e96304d99477de1f70db42035071e56439da817 ] This patch sets the right number of arguments to be used for DMA clients which request channels from DT. Signed-off-by: M'boumba Cedric Madianga Reviewed-by: Ludovic BARRE Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/dma/stm32-dma.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/drivers/dma/stm32-dma.c +++ b/drivers/dma/stm32-dma.c @@ -976,21 +976,18 @@ static struct dma_chan *stm32_dma_of_xla struct stm32_dma_chan *chan; struct dma_chan *c; - if (dma_spec->args_count < 3) + if (dma_spec->args_count < 4) return NULL; cfg.channel_id = dma_spec->args[0]; cfg.request_line = dma_spec->args[1]; cfg.stream_config = dma_spec->args[2]; - cfg.threshold = 0; + cfg.threshold = dma_spec->args[3]; if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >= STM32_DMA_MAX_REQUEST_ID)) return NULL; - if (dma_spec->args_count > 3) - cfg.threshold = dma_spec->args[3]; - chan = &dmadev->chan[cfg.channel_id]; c = dma_get_slave_channel(&chan->vchan.chan);
[PATCH 4.9 013/109] s390/pci: do not require AIS facility
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Christian Borntraeger
[ Upstream commit 48070c73058be6de9c0d754d441ed7092dfc8f12 ]
As of today QEMU does not provide the AIS facility to its guest. This
prevents Linux guests from using PCI devices as the ais facility is
checked during init. As this is just a performance optimization, we can
move the ais check into the code where we need it (calling the SIC
instruction). This is used at initialization and on interrupt. Both
places do not require any serialization, so we can simply skip the
instruction.
Since we will now get all interrupts, we can also avoid the 2nd scan.
As we can have multiple interrupts in parallel we might trigger spurious
irqs more often for the non-AIS case but the core code can handle that.
Signed-off-by: Christian Borntraeger
Reviewed-by: Pierre Morel
Reviewed-by: Halil Pasic
Acked-by: Sebastian Ott
Signed-off-by: Heiko Carstens
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/include/asm/pci_insn.h |2 +-
arch/s390/pci/pci.c |5 +++--
arch/s390/pci/pci_insn.c |6 +-
3 files changed, 9 insertions(+), 4 deletions(-)
--- a/arch/s390/include/asm/pci_insn.h
+++ b/arch/s390/include/asm/pci_insn.h
@@ -81,6 +81,6 @@ int zpci_refresh_trans(u64 fn, u64 addr,
int zpci_load(u64 *data, u64 req, u64 offset);
int zpci_store(u64 data, u64 req, u64 offset);
int zpci_store_block(const u64 *data, u64 req, u64 offset);
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
#endif
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -354,7 +354,8 @@ static void zpci_irq_handler(struct airq
/* End of second scan with interrupts on. */
break;
/* First scan complete, reenable interrupts. */
- zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC);
+ if (zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL,
PCI_ISC))
+ break;
si = 0;
continue;
}
@@ -928,7 +929,7 @@ static int __init pci_base_init(void)
if (!s390_pci_probe)
return 0;
- if (!test_facility(69) || !test_facility(71) || !test_facility(72))
+ if (!test_facility(69) || !test_facility(71))
return 0;
rc = zpci_debug_init();
--- a/arch/s390/pci/pci_insn.c
+++ b/arch/s390/pci/pci_insn.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -91,11 +92,14 @@ int zpci_refresh_trans(u64 fn, u64 addr,
}
/* Set Interruption Controls */
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
{
+ if (!test_facility(72))
+ return -EIO;
asm volatile (
" .insn rsy,0xebd1,%[ctl],%[isc],%[u]\n"
: : [ctl] "d" (ctl), [isc] "d" (isc << 27), [u] "Q" (*unused));
+ return 0;
}
/* PCI Load */
[PATCH 4.9 021/109] mmc: sdhci-msm: fix issue with power irq
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Subhash Jadavani
[ Upstream commit c7ccee224d2d551f712752c4a16947f6529d6506 ]
SDCC controller reset (SW_RST) during probe may trigger power irq if
previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
enable the power irq interrupt in GIC (by registering the interrupt
handler), we need to ensure that any pending power irq interrupt status
is acknowledged otherwise power irq interrupt handler would be fired
prematurely.
Signed-off-by: Subhash Jadavani
Signed-off-by: Vijay Viswanath
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-msm.c | 18 ++
1 file changed, 18 insertions(+)
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -642,6 +642,21 @@ static int sdhci_msm_probe(struct platfo
CORE_VENDOR_SPEC_CAPABILITIES0);
}
+ /*
+* Power on reset state may trigger power irq if previous status of
+* PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
+* interrupt in GIC, any pending power irq interrupt should be
+* acknowledged. Otherwise power irq interrupt handler would be
+* fired prematurely.
+*/
+ sdhci_msm_voltage_switch(host);
+
+ /*
+* Ensure that above writes are propogated before interrupt enablement
+* in GIC.
+*/
+ mb();
+
/* Setup IRQ for handling power/voltage tasks with PMIC */
msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
if (msm_host->pwr_irq < 0) {
@@ -651,6 +666,9 @@ static int sdhci_msm_probe(struct platfo
goto clk_disable;
}
+ /* Enable pwr irq interrupts */
+ writel_relaxed(INT_MASK, msm_host->core_mem + CORE_PWRCTL_MASK);
+
ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq, NULL,
sdhci_msm_pwr_irq, IRQF_ONESHOT,
dev_name(&pdev->dev), host);
[PATCH 4.9 020/109] spi: spi-axi: fix potential use-after-free after deregistration
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
[ Upstream commit 4d5e0689dc9d5640ad46cdfbe1896b74d8df1661 ]
Take an extra reference to the controller before deregistering it to
prevent use-after-free in the interrupt handler in case an interrupt
fires before the line is disabled.
Fixes: b1353d1c1d45 ("spi: Add Analog Devices AXI SPI Engine controller
support")
Acked-by: Lars-Peter Clausen
Signed-off-by: Johan Hovold
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/spi/spi-axi-spi-engine.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -553,7 +553,7 @@ err_put_master:
static int spi_engine_remove(struct platform_device *pdev)
{
- struct spi_master *master = platform_get_drvdata(pdev);
+ struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct spi_engine *spi_engine = spi_master_get_devdata(master);
int irq = platform_get_irq(pdev, 0);
@@ -561,6 +561,8 @@ static int spi_engine_remove(struct plat
free_irq(irq, master);
+ spi_master_put(master);
+
writel_relaxed(0xff, spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
writel_relaxed(0x00, spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
writel_relaxed(0x01, spi_engine->base + SPI_ENGINE_REG_RESET);
[PATCH 4.9 018/109] staging: rtl8188eu: avoid a null dereference on pmlmepriv
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Colin Ian King
[ Upstream commit 123c0aab0050cd0e07ce18e453389fbbb0a5a425 ]
There is a check on pmlmepriv before dereferencing it when
vfree'ing pmlmepriv->free_bss_buf however the previous call
to rtw_free_mlme_priv_ie_data deferences pmlmepriv causing
a null pointer deference if it is null. Avoid this by also
calling rtw_free_mlme_priv_ie_data if the pointer is non-null.
Detected by CoverityScan, CID#1230262 ("Dereference before null check")
Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Signed-off-by: Colin Ian King
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/rtl8188eu/core/rtw_mlme.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -107,10 +107,10 @@ void rtw_free_mlme_priv_ie_data(struct m
void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)
{
- rtw_free_mlme_priv_ie_data(pmlmepriv);
-
- if (pmlmepriv)
+ if (pmlmepriv) {
+ rtw_free_mlme_priv_ie_data(pmlmepriv);
vfree(pmlmepriv->free_bss_buf);
+ }
}
struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv)
[PATCH 4.9 015/109] staging: greybus: loopback: Fix iteration count on async path
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Bryan O'Donoghue
[ Upstream commit 44b02da39210e6dd67e39ff1f48d30c56d384240 ]
Commit 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support") does what it says on the tin - namely, adds support for
asynchronous bi-directional loopback operations.
What it neglects to do though is increment the per-connection
gb->iteration_count on an asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support")
Signed-off-by: Bryan O'Donoghue
Reported-by: Mitch Tasman
Reviewed-by: Johan Hovold
Cc: Alex Elder
Cc: Mitch Tasman
Cc: greybus-...@lists.linaro.org
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/greybus/loopback.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1034,8 +1034,10 @@ static int gb_loopback_fn(void *data)
error = gb_loopback_async_sink(gb, size);
}
- if (error)
+ if (error) {
gb->error++;
+ gb->iteration_count++;
+ }
} else {
/* We are effectively single threaded here */
if (type == GB_LOOPBACK_TYPE_PING)
[PATCH 4.9 024/109] usb: phy: tahvo: fix error handling in tahvo_usb_probe()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Alexey Khoroshilov
[ Upstream commit ce035409bfa892a2fabb89720b542e1b335c3426 ]
If devm_extcon_dev_allocate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Fixes: 860d2686fda7 ("usb: phy: tahvo: Use
devm_extcon_dev_[allocate|register]() and replace deprecated API")
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/phy/phy-tahvo.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -368,7 +368,8 @@ static int tahvo_usb_probe(struct platfo
tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
if (IS_ERR(tu->extcon)) {
dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
- return -ENOMEM;
+ ret = PTR_ERR(tu->extcon);
+ goto err_disable_clk;
}
ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
[PATCH 4.9 014/109] selftests/x86/ldt_get: Add a few additional tests for limits
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski [ Upstream commit fec8f5ae1715a01c72ad52cb2ecd8aacaf142302 ] We weren't testing the .limit and .limit_in_pages fields very well. Add more tests. This addition seems to trigger the "bits 16:19 are undefined" issue that was fixed in an earlier patch. I think that, at least on my CPU, the high nibble of the limit ends in LAR bits 16:19. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/5601c15ea9b3113d288953fd2838b18bedf6bc67.1509794321.git.l...@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- tools/testing/selftests/x86/ldt_gdt.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/ldt_gdt.c +++ b/tools/testing/selftests/x86/ldt_gdt.c @@ -360,9 +360,24 @@ static void do_simple_tests(void) install_invalid(&desc, false); desc.seg_not_present = 0; - desc.read_exec_only = 0; desc.seg_32bit = 1; + desc.read_exec_only = 0; + desc.limit = 0xf; + install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB); + + desc.limit_in_pages = 1; + + install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB | AR_G); + desc.read_exec_only = 1; + install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA | AR_S | AR_P | AR_DB | AR_G); + desc.contents = 1; + desc.read_exec_only = 0; + install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G); + desc.read_exec_only = 1; + install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G); + + desc.limit = 0; install_invalid(&desc, true); }
[PATCH 4.9 006/109] mm, oom_reaper: gather each vma to prevent leaking TLB entry
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Wang Nan
commit 687cb0884a714ff484d038e9190edc874edcf146 upstream.
tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory
space. In this case, tlb->fullmm is true. Some archs like arm64
doesn't flush TLB when tlb->fullmm is true:
commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1").
Which causes leaking of tlb entries.
Will clarifies his patch:
"Basically, we tag each address space with an ASID (PCID on x86) which
is resident in the TLB. This means we can elide TLB invalidation when
pulling down a full mm because we won't ever assign that ASID to
another mm without doing TLB invalidation elsewhere (which actually
just nukes the whole TLB).
I think that means that we could potentially not fault on a kernel
uaccess, because we could hit in the TLB"
There could be a window between complete_signal() sending IPI to other
cores and all threads sharing this mm are really kicked off from cores.
In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to
flush TLB then frees pages. However, due to the above problem, the TLB
entries are not really flushed on arm64. Other threads are possible to
access these pages through TLB entries. Moreover, a copy_to_user() can
also write to these pages without generating page fault, causes
use-after-free bugs.
This patch gathers each vma instead of gathering full vm space. In this
case tlb->fullmm is not true. The behavior of oom reaper become similar
to munmapping before do_exit, which should be safe for all archs.
Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangn...@huawei.com
Fixes: aac453635549 ("mm, oom: introduce oom reaper")
Signed-off-by: Wang Nan
Acked-by: Michal Hocko
Acked-by: David Rientjes
Cc: Minchan Kim
Cc: Will Deacon
Cc: Bob Liu
Cc: Ingo Molnar
Cc: Roman Gushchin
Cc: Konstantin Khlebnikov
Cc: Andrea Arcangeli
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[backported to 4.9 stable tree]
Signed-off-by: Michal Hocko
Signed-off-by: Greg Kroah-Hartman
---
mm/oom_kill.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -524,7 +524,6 @@ static bool __oom_reap_task_mm(struct ta
*/
set_bit(MMF_UNSTABLE, &mm->flags);
- tlb_gather_mmu(&tlb, mm, 0, -1);
for (vma = mm->mmap ; vma; vma = vma->vm_next) {
if (is_vm_hugetlb_page(vma))
continue;
@@ -546,11 +545,13 @@ static bool __oom_reap_task_mm(struct ta
* we do not want to block exit_mmap by keeping mm ref
* count elevated without a good reason.
*/
- if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED))
+ if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) {
+ tlb_gather_mmu(&tlb, mm, vma->vm_start, vma->vm_end);
unmap_page_range(&tlb, vma, vma->vm_start, vma->vm_end,
&details);
+ tlb_finish_mmu(&tlb, vma->vm_start, vma->vm_end);
+ }
}
- tlb_finish_mmu(&tlb, 0, -1);
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
[PATCH v5 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint
The TCP/IP transition from TCP_LISTEN to TCP_SYN_RECV and some other
transitions are not traced with tcp_set_state tracepoint.
In order to trace the whole tcp lifespans, two helpers are introduced,
void sk_set_state(struct sock *sk, int state);
void sk_state_store(struct sock *sk, int newstate);
When do TCP/IP state transition, we should use these two helpers or use
tcp_set_state() other than assigning a value to sk_state directly.
Signed-off-by: Yafang Shao
Acked-by: Song Liu
Reviewed-by: Marcelo Ricardo Leitner
Signed-off-by: Yafang Shao
---
v4->v5: Trace only TCP sockets, whatever it is stream socket or raw socket.
v3->v4: Do not trace DCCP socket
v2->v3: Per suggestion from Marcelo Ricardo Leitner, inverting __
to sk_state_store.
---
include/net/sock.h | 8 ++--
net/core/sock.c | 15 +++
net/ipv4/inet_connection_sock.c | 5 +++--
net/ipv4/inet_hashtables.c | 2 +-
net/ipv4/tcp.c | 2 +-
5 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 79e1a2c..1cf7685 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2349,18 +2349,22 @@ static inline int sk_state_load(const struct sock *sk)
}
/**
- * sk_state_store - update sk->sk_state
+ * __sk_state_store - update sk->sk_state
* @sk: socket pointer
* @newstate: new state
*
* Paired with sk_state_load(). Should be used in contexts where
* state change might impact lockless readers.
*/
-static inline void sk_state_store(struct sock *sk, int newstate)
+static inline void __sk_state_store(struct sock *sk, int newstate)
{
smp_store_release(&sk->sk_state, newstate);
}
+/* For tcp_set_state tracepoint */
+void sk_state_store(struct sock *sk, int newstate);
+void sk_set_state(struct sock *sk, int state);
+
void sock_enable_timestamp(struct sock *sk, int flag);
int sock_get_timestamp(struct sock *, struct timeval __user *);
int sock_get_timestampns(struct sock *, struct timespec __user *);
diff --git a/net/core/sock.c b/net/core/sock.c
index c0b5b2f..61841a2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -138,6 +138,7 @@
#include
#include
+#include
#include
#include
@@ -2859,6 +2860,20 @@ int sock_get_timestampns(struct sock *sk, struct
timespec __user *userstamp)
}
EXPORT_SYMBOL(sock_get_timestampns);
+void sk_state_store(struct sock *sk, int newstate)
+{
+ if (sk->sk_protocol == IPPROTO_TCP)
+ trace_tcp_set_state(sk, sk->sk_state, newstate);
+ __sk_state_store(sk, newstate);
+}
+
+void sk_set_state(struct sock *sk, int state)
+{
+ if (sk->sk_protocol == IPPROTO_TCP)
+ trace_tcp_set_state(sk, sk->sk_state, state);
+ sk->sk_state = state;
+}
+
void sock_enable_timestamp(struct sock *sk, int flag)
{
if (!sock_flag(sk, flag)) {
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4ca46dc..41f9c87 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -783,7 +783,7 @@ struct sock *inet_csk_clone_lock(const struct sock *sk,
if (newsk) {
struct inet_connection_sock *newicsk = inet_csk(newsk);
- newsk->sk_state = TCP_SYN_RECV;
+ sk_set_state(newsk, TCP_SYN_RECV);
newicsk->icsk_bind_hash = NULL;
inet_sk(newsk)->inet_dport = inet_rsk(req)->ir_rmt_port;
@@ -888,7 +888,8 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
return 0;
}
- sk->sk_state = TCP_CLOSE;
+ sk_set_state(sk, TCP_CLOSE);
+
return err;
}
EXPORT_SYMBOL_GPL(inet_csk_listen_start);
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index f6f5810..5973693 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -544,7 +544,7 @@ bool inet_ehash_nolisten(struct sock *sk, struct sock *osk)
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
} else {
percpu_counter_inc(sk->sk_prot->orphan_count);
- sk->sk_state = TCP_CLOSE;
+ sk_set_state(sk, TCP_CLOSE);
sock_set_flag(sk, SOCK_DEAD);
inet_csk_destroy_sock(sk);
}
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1803116..ac98dc6 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2065,7 +2065,7 @@ void tcp_set_state(struct sock *sk, int state)
/* Change state AFTER socket is unhashed to avoid closed
* socket sitting in hash tables.
*/
- sk_state_store(sk, state);
+ __sk_state_store(sk, state);
#ifdef STATE_TRACE
SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n", sk, statename[oldstate],
statename[state]);
--
1.8.3.1
[PATCH 4.9 007/109] uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Hans de Goede
commit 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 upstream.
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/storage/uas-detect.h |4
1 file changed, 4 insertions(+)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -111,6 +111,10 @@ static int uas_use_uas_driver(struct usb
}
}
+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
[PATCH][next] ASoC: pcm186x: make pcm186x_dai_ops and pcm186x_adc_input_channel_sel_value static
From: Colin Ian King
pcm186x_dai_ops and pcm186x_adc_input_channel_sel_value are local to the
source and do not need to be in global scope, so make them static.
Cleans up sparse warnings:
symbol 'pcm186x_dai_ops' was not declared. Should it be static?
symbol 'pcm186x_adc_input_channel_sel_value' was not declared. Should it
be static?
Signed-off-by: Colin Ian King
---
sound/soc/codecs/pcm186x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/pcm186x.c b/sound/soc/codecs/pcm186x.c
index f7aa56e20169..cdb51427facc 100644
--- a/sound/soc/codecs/pcm186x.c
+++ b/sound/soc/codecs/pcm186x.c
@@ -59,7 +59,7 @@ static const struct snd_kcontrol_new pcm1865_snd_controls[] =
{
pcm186x_pga_tlv),
};
-const unsigned int pcm186x_adc_input_channel_sel_value[] = {
+static const unsigned int pcm186x_adc_input_channel_sel_value[] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
0x10, 0x20, 0x30
@@ -475,7 +475,7 @@ static int pcm186x_set_dai_sysclk(struct snd_soc_dai *dai,
int clk_id,
return 0;
}
-const struct snd_soc_dai_ops pcm186x_dai_ops = {
+static const struct snd_soc_dai_ops pcm186x_dai_ops = {
.set_sysclk = pcm186x_set_dai_sysclk,
.set_tdm_slot = pcm186x_set_tdm_slot,
.set_fmt = pcm186x_set_fmt,
--
2.14.1
Re: [RFC PATCH] mm: unclutter THP migration
Hi Michal, Thanks for sending this out. Michal Hocko wrote: > From: Michal Hocko > > THP migration is hacked into the generic migration with rather > surprising semantic. The migration allocation callback is supposed to > check whether the THP can be migrated at once and if that is not the > case then it allocates a simple page to migrate. unmap_and_move then > fixes that up by spliting the THP into small pages while moving the > head page to the newly allocated order-0 page. Remaning pages are moved > to the LRU list by split_huge_page. The same happens if the THP > allocation fails. This is really ugly and error prone [1]. > > I also believe that split_huge_page to the LRU lists is inherently > wrong because all tail pages are not migrated. Some callers will just I agree with you that we should try to migrate all tail pages if the THP needs to be split. But this might not be compatible with "getting migration results" in unmap_and_move(), since a caller of migrate_pages() may want to know the status of each page in the migration list via int **result in get_new_page() (e.g. new_page_node()). The caller has no idea whether a THP in its migration list will be split or not, thus, storing migration results might be quite tricky if tail pages are added into the migration list. We need to consider this when we clean up migrate_pages(). > work around that by retrying (e.g. memory hotplug). There are other > pfn walkers which are simply broken though. e.g. madvise_inject_error > will migrate head and then advances next pfn by the huge page size. > do_move_page_to_node_array, queue_pages_range (migrate_pages, mbind), > will simply split the THP before migration if the THP migration is not > supported then falls back to single page migration but it doesn't handle > tail pages if the THP migration path is not able to allocate a fresh > THP so we end up with ENOMEM and fail the whole migration which is > a questionable behavior. Page compaction doesn't try to migrate large > pages so it should be immune. > > This patch tries to unclutter the situation by moving the special THP > handling up to the migrate_pages layer where it actually belongs. We > simply split the THP page into the existing list if unmap_and_move fails > with ENOMEM and retry. So we will _always_ migrate all THP subpages and > specific migrate_pages users do not have to deal with this case in a > special way. > > [1] > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flkml.kernel.org%2Fr%2F20171121021855.50525-1-zi.yan%40sent.com&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7C1eb88428b6a24e774ee108d53d70cf1f%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636482477084480449&sdata=q5nY%2Fe%2F8peEiR1YdcdE3PBGBhC%2B4VsCwadBpQGMeBCo%3D&reserved=0 > > Signed-off-by: Michal Hocko > --- > Hi, > this is a follow up for [2]. I find this approach much less hackish and > easier to maintain as well. It also fixes few bugs. I didn't really go > deeply into each migration path and evaluate the user visible bugs but > at least the explicit migration is suboptimal to say the least > > # A simple 100M mmap with MADV_HUGEPAGE and explicit migrate from node 0 > # to node 1 with results displayed "After pause" > root@test1:~# numactl -m 0 ./map_thp > 7f749d0aa000 bind:0 anon=25600 dirty=25600 N0=25600 kernelpagesize_kB=4 > 7f749d0aa000-7f74a34aa000 rw-p 00:00 0 > Size: 102400 kB > Rss: 102400 kB > AnonHugePages:100352 kB > > After pause > 7f749d0aa000 bind:0 anon=25600 dirty=25600 N0=18602 N1=6998 > kernelpagesize_kB=4 > 7f749d0aa000-7f74a34aa000 rw-p 00:00 0 > Size: 102400 kB > Rss: 102400 kB > AnonHugePages:100352 kB > > root@test1:~# migratepages $(pgrep map_thp) 0 1 > migrate_pages: Cannot allocate memory > > While the migration succeeds with the patch applied even though some THP > had to be split and migrated page by page. > > I believe that thp_migration_supported shouldn't be spread outside > of the migration code but I've left few assertion in place. Maybe > they should go as well. I haven't spent too much time on those. My > testing was quite limited and this might still blow up so I would really > appreciate a careful review. > > Thanks! > > [2] > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flkml.kernel.org%2Fr%2F20171122130121.ujp6qppa7nhahazh%40dhcp22.suse.cz&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7C1eb88428b6a24e774ee108d53d70cf1f%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636482477084480449&sdata=9W%2FW3zgu8lKXEZLoXRi%2BQd9xr1PuuSI%2FRZZrl2ylkdQ%3D&reserved=0 > > include/linux/migrate.h | 6 -- > mm/huge_memory.c| 6 ++ > mm/memory_hotplug.c | 2 +- > mm/mempolicy.c | 29 ++--- > mm/migrate.c| 31 --- > 5 files changed, 33 insertions(+), 41 deletions(-) > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > index a224
[PATCH 4.9 012/109] ima: fix hash algorithm initialization
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Boshi Wang [ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ] The hash_setup function always sets the hash_setup_done flag, even when the hash algorithm is invalid. This prevents the default hash algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used. This patch sets hash_setup_done flag only for valid hash algorithms. Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms" Signed-off-by: Boshi Wang Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- security/integrity/ima/ima_main.c |4 1 file changed, 4 insertions(+) --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -51,6 +51,8 @@ static int __init hash_setup(char *str) ima_hash_algo = HASH_ALGO_SHA1; else if (strncmp(str, "md5", 3) == 0) ima_hash_algo = HASH_ALGO_MD5; + else + return 1; goto out; } @@ -60,6 +62,8 @@ static int __init hash_setup(char *str) break; } } + if (i == HASH_ALGO__LAST) + return 1; out: hash_setup_done = 1; return 1;
[PATCH 4.9 002/109] bcache: recover data from backing when data is clean
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Rui Hua
commit e393aa2446150536929140739f09c6ecbcbea7f0 upstream.
When we send a read request and hit the clean data in cache device, there
is a situation called cache read race in bcache(see the commit in the tail
of cache_look_up(), the following explaination just copy from there):
The bucket we're reading from might be reused while our bio is in flight,
and we could then end up reading the wrong data. We guard against this
by checking (in bch_cache_read_endio()) if the pointer is stale again;
if so, we treat it as an error (s->iop.error = -EINTR) and reread from
the backing device (but we don't pass that error up anywhere)
It should be noted that cache read race happened under normal
circumstances, not the circumstance when SSD failed, it was counted
and shown in /sys/fs/bcache/XXX/internal/cache_read_races.
Without this patch, when we use writeback mode, we will never reread from
the backing device when cache read race happened, until the whole cache
device is clean, because the condition
(s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in
cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR)
will be passed up, at last, user will receive -EINTR when it's bio end,
this is not suitable, and wield to up-application.
In this patch, we use s->read_dirty_data to judge whether the read
request hit dirty data in cache device, it is safe to reread data from
the backing device when the read request hit clean data. This can not
only handle cache read race, but also recover data when failed read
request from cache device.
[edited by mlyle to fix up whitespace, commit log title, comment
spelling]
Fixes: d59b23795933 ("bcache: only permit to recovery read error when cache
device is clean")
Signed-off-by: Hua Rui
Reviewed-by: Michael Lyle
Reviewed-by: Coly Li
Signed-off-by: Michael Lyle
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/bcache/request.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -702,16 +702,15 @@ static void cached_dev_read_error(struct
{
struct search *s = container_of(cl, struct search, cl);
struct bio *bio = &s->bio.bio;
- struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
/*
-* If cache device is dirty (dc->has_dirty is non-zero), then
-* recovery a failed read request from cached device may get a
-* stale data back. So read failure recovery is only permitted
-* when cache device is clean.
+* If read request hit dirty data (s->read_dirty_data is true),
+* then recovery a failed read request from cached device may
+* get a stale data back. So read failure recovery is only
+* permitted when read request hit clean data in cache device,
+* or when cache read race happened.
*/
- if (s->recoverable &&
- (dc && !atomic_read(&dc->has_dirty))) {
+ if (s->recoverable && !s->read_dirty_data) {
/* Retry from the backing device: */
trace_bcache_read_retry(s->orig_bio);
[PATCH 4.9 011/109] USB: serial: option: add Quectel BG96 id
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Sjoholm
commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/option.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_BG96 0x0296
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1185,6 +1186,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
[PATCH 4.9 010/109] s390/runtime instrumentation: simplify task exit handling
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Heiko Carstens
commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 upstream.
Free data structures required for runtime instrumentation from
arch_release_task_struct(). This allows to simplify the code a bit,
and also makes the semantics a bit easier: arch_release_task_struct()
is never called from the task that is being removed.
In addition this allows to get rid of exit_thread() in a later patch.
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/include/asm/runtime_instr.h |4 +++-
arch/s390/kernel/process.c|3 +--
arch/s390/kernel/runtime_instr.c | 30 +++---
3 files changed, 19 insertions(+), 18 deletions(-)
--- a/arch/s390/include/asm/runtime_instr.h
+++ b/arch/s390/include/asm/runtime_instr.h
@@ -85,6 +85,8 @@ static inline void restore_ri_cb(struct
load_runtime_instr_cb(&runtime_instr_empty_cb);
}
-void exit_thread_runtime_instr(void);
+struct task_struct;
+
+void runtime_instr_release(struct task_struct *tsk);
#endif /* _RUNTIME_INSTR_H */
--- a/arch/s390/kernel/process.c
+++ b/arch/s390/kernel/process.c
@@ -70,8 +70,6 @@ extern void kernel_thread_starter(void);
*/
void exit_thread(struct task_struct *tsk)
{
- if (tsk == current)
- exit_thread_runtime_instr();
}
void flush_thread(void)
@@ -84,6 +82,7 @@ void release_thread(struct task_struct *
void arch_release_task_struct(struct task_struct *tsk)
{
+ runtime_instr_release(tsk);
}
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
--- a/arch/s390/kernel/runtime_instr.c
+++ b/arch/s390/kernel/runtime_instr.c
@@ -18,11 +18,24 @@
/* empty control block to disable RI by loading it */
struct runtime_instr_cb runtime_instr_empty_cb;
+void runtime_instr_release(struct task_struct *tsk)
+{
+ kfree(tsk->thread.ri_cb);
+}
+
static void disable_runtime_instr(void)
{
- struct pt_regs *regs = task_pt_regs(current);
+ struct task_struct *task = current;
+ struct pt_regs *regs;
+ if (!task->thread.ri_cb)
+ return;
+ regs = task_pt_regs(task);
+ preempt_disable();
load_runtime_instr_cb(&runtime_instr_empty_cb);
+ kfree(task->thread.ri_cb);
+ task->thread.ri_cb = NULL;
+ preempt_enable();
/*
* Make sure the RI bit is deleted from the PSW. If the user did not
@@ -43,19 +56,6 @@ static void init_runtime_instr_cb(struct
cb->valid = 1;
}
-void exit_thread_runtime_instr(void)
-{
- struct task_struct *task = current;
-
- preempt_disable();
- if (!task->thread.ri_cb)
- return;
- disable_runtime_instr();
- kfree(task->thread.ri_cb);
- task->thread.ri_cb = NULL;
- preempt_enable();
-}
-
SYSCALL_DEFINE1(s390_runtime_instr, int, command)
{
struct runtime_instr_cb *cb;
@@ -64,7 +64,7 @@ SYSCALL_DEFINE1(s390_runtime_instr, int,
return -EOPNOTSUPP;
if (command == S390_RUNTIME_INSTR_STOP) {
- exit_thread_runtime_instr();
+ disable_runtime_instr();
return 0;
}
[PATCH] drm/i915: add FTRACE dependency for DRM_I915_TRACE_GEM
The new trace option gratuitously added a 'select TRACING' statement,
which now causes build failures in other code that assumed tracepoints
were only available with FTRACE:
ERROR: "__tracepoint_ucsi_command" [drivers/usb/typec/ucsi/typec_ucsi.ko]
undefined!
ERROR: "__tracepoint_ucsi_register_port" [drivers/usb/typec/ucsi/typec_ucsi.ko]
undefined!
ERROR: "__tracepoint_ucsi_notify" [drivers/usb/typec/ucsi/typec_ucsi.ko]
undefined!
ERROR: "__tracepoint_ucsi_reset_ppm" [drivers/usb/typec/ucsi/typec_ucsi.ko]
undefined!
ERROR: "__tracepoint_ucsi_run_command" [drivers/usb/typec/ucsi/typec_ucsi.ko]
undefined!
drivers/usb/dwc3/gadget.o: In function `__dwc3_prepare_one_trb':
gadget.c:(.text+0x1c5): undefined reference to `__tracepoint_dwc3_prepare_trb'
drivers/usb/dwc3/gadget.o: In function `__dwc3_cleanup_done_trbs':
gadget.c:(.text+0x3f0): undefined reference to `__tracepoint_dwc3_complete_trb'
drivers/usb/dwc3/gadget.o: In function `dwc3_gadget_ep_free_request':
gadget.c:(.text+0x666): undefined reference to `__tracepoint_dwc3_free_request'
This adds an explicit FTRACE dependency here, to ensure this is already
the case. This matches what the other drivers have that select TRACING.
Generally speaking, there is a bigger problem with CONFIG_DRM_I915_DEBUG
though, it selects several other partially related symbols (DEBUGFS,
I2C_CHARDEV, PREEMPT_COUNT, X86_MSR, etc that are each user-visible and
that other symbols in turn depend on. This can easily lead to circular
dependencies and should be avoided. I tried turning those all into
'depends on', which is normally a good strategy, but that seems to
completely defeat the intention of CONFIG_DRM_I915_DEBUG. It might
be better to just remove this completely, possibly replace it with a
Kconfig fragment.
Fixes: bccd3b831185 ("drm/i915: Use trace_printk to provide a death rattle for
GEM")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index fa36491495b1..1a1b9732f657 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -18,6 +18,7 @@ config DRM_I915_WERROR
config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
+ depends on FTRACE # for DRM_I915_TRACE_GEM
select DEBUG_FS
select PREEMPT_COUNT
select I2C_CHARDEV
@@ -53,6 +54,7 @@ config DRM_I915_DEBUG_GEM
config DRM_I915_TRACE_GEM
bool "Insert extra ftrace output from the GEM internals"
+ depends on FTRACE
select TRACING
default n
help
--
2.9.0
Re: [PATCH v3 2/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks
On 07-Dec 10:35, Viresh Kumar wrote:
> On 30-11-17, 11:47, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 67339ccb5595..448f49de5335 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -262,6 +262,7 @@ static void sugov_update_single(struct update_util_data
> > *hook, u64 time,
> > struct cpufreq_policy *policy = sg_policy->policy;
> > unsigned long util, max;
> > unsigned int next_f;
> > + bool rt_mode;
> > bool busy;
> >
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > @@ -272,7 +273,15 @@ static void sugov_update_single(struct
> > update_util_data *hook, u64 time,
> >
> > busy = sugov_cpu_is_busy(sg_cpu);
> >
> > - if (flags & SCHED_CPUFREQ_RT_DL) {
> > + /*
> > +* While RT/DL tasks are running we do not want FAIR tasks to
> > +* overvrite this CPU's flags, still we can update utilization and
> > +* frequency (if required/possible) to be fair with these tasks.
> > +*/
> > + rt_mode = task_has_dl_policy(current) ||
> > + task_has_rt_policy(current) ||
> > + (flags & SCHED_CPUFREQ_RT_DL);
> > + if (rt_mode) {
> > next_f = policy->cpuinfo.max_freq;
> > } else {
> > sugov_get_util(&util, &max, sg_cpu->cpu);
> > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct update_util_data
> > *hook, u64 time,
> > struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> > unsigned long util, max;
> > unsigned int next_f;
> > + bool rt_mode;
> >
> > sugov_get_util(&util, &max, sg_cpu->cpu);
> >
> > @@ -353,17 +363,27 @@ static void sugov_update_shared(struct
> > update_util_data *hook, u64 time,
> > sg_cpu->flags = 0;
> > goto done;
> > }
> > - sg_cpu->flags = flags;
> > +
> > + /*
> > +* While RT/DL tasks are running we do not want FAIR tasks to
> > +* overwrite this CPU's flags, still we can update utilization and
> > +* frequency (if required/possible) to be fair with these tasks.
> > +*/
> > + rt_mode = task_has_dl_policy(current) ||
> > + task_has_rt_policy(current) ||
> > + (flags & SCHED_CPUFREQ_RT_DL);
> > + if (rt_mode)
> > + sg_cpu->flags |= flags;
> > + else
> > + sg_cpu->flags = flags;
> >
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > sg_cpu->last_update = time;
> >
> > if (sugov_should_update_freq(sg_policy, time)) {
> > - if (flags & SCHED_CPUFREQ_RT_DL)
> > - next_f = sg_policy->policy->cpuinfo.max_freq;
> > - else
> > - next_f = sugov_next_freq_shared(sg_cpu, time);
> > -
> > + next_f = rt_mode
> > + ? sg_policy->policy->cpuinfo.max_freq
> > + : sugov_next_freq_shared(sg_cpu, time);
> > sugov_update_commit(sg_policy, time, next_f);
> > }
>
> Same here. There are pending comments from V2 which no one objected to
> and I was looking to see those modifications here.
So, your proposal here was actually to add additional flags to clear
the RT and DL ones.
My past comment was instead that we never had a "clear bit" semantics
for flags updates. However, it seems that the most common optinion was
that we should try to add such flags.
Thus, I think I have to refresh this patch by adding in the new flags
as you proposed and give it a try.
--
#include
Patrick Bellasi
[PATCH] clk: qcom: gcc-msm8996: always enable aggre0_noc gdsc
From: Srinivas Kandagatla
bus clks which depend on this gdsc are marked as critical,
so this patch flags this gdsc ALWAYS_ON so that bus clks status
does not get stuck at on or off.
Signed-off-by: Srinivas Kandagatla
---
drivers/clk/qcom/gcc-msm8996.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 0146d8853488..b2be77469693 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -3101,7 +3101,7 @@ static struct gdsc aggre0_noc_gdsc = {
.name = "aggre0_noc",
},
.pwrsts = PWRSTS_OFF_ON,
- .flags = VOTABLE,
+ .flags = VOTABLE | ALWAYS_ON,
};
static struct gdsc hlos1_vote_aggre0_noc_gdsc = {
--
2.15.0
Re: [PATCH v3 3/6] cpufreq: schedutil: update CFS util only if used
On 07-Dec 10:45, Viresh Kumar wrote: > On 30-11-17, 15:57, Patrick Bellasi wrote: > > Yes, that's a pretty trivial update with a confusing changelog. > > > > If we think it's worth to keep (and correct as well) I'll update the > > commit message. > > We also need to update the commit log based on feedback from Vikram on > V2. Which said that the utilization can't change around the lock here > as we are within rq lock section, though max can change (maybe). So > this patch only takes care of locking before reading max. Ok, right... will do. Thus you are still of the opinion to keep this patch in the series? -- #include Patrick Bellasi
Re: [PATCH 0/1] About MIPS/Loongson maintainance
On Thu, Dec 07, 2017 at 09:10:10PM +0800, Jiaxun Yang wrote: > On 2017-12-07 Thu 11:05 +，James Hogan Wrote： > > On Thu, Dec 07, 2017 at 07:57:59AM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote: > > > > Hi, Linus, Stephen, Greg, Ralf and James, > > > > > > > > We are kernel developers from Lemote Inc. and Loongson community. > > > > We > > > > have already made some contributions in Linux kernel, but we hope > > > > we > > > > can do more works. > > > > > > > > Of course Loongson is a sub-arch in MIPS, but linux-mips > > > > community is > > > > so inactive (Maybe maintainers are too busy?) that too many > > > > patches ( > > > > Not only for Loongson, but also for other sub-archs) were delayed > > > > for > > > > a long time. So we are seeking a more efficient way to make > > > > Loongson > > > > patches be merged in upstream. > > > > > > > > Now we have a github organization for collaboration: > > > > https://github.com/linux-loongson/linux-loongson.git > > > > > > Ick, why not get a kernel.org account for your git tree? > > > > > > > We don't want to replace linux-mips, we just want to find a way > > > > to co- > > > > operate with linux-mips. So we will still use the maillist and > > > > patchwork > > > > of linux-mips, but we hope we can send pull requests from our > > > > github to > > > > linux-next and linux-mainline by ourselves (if there is no > > > > objections > > > > to our patches from linux-mips community). > > > > > > What does the mips maintainers think about this? > > > > > > Odds are a linux-next tree is fine, but they probably want to merge > > > the > > > trees into their larger mips one for the pulls to Linus, much like > > > the > > > arm-core tree works, right? > > > > I'm not officially a MIPS maintainer but I have donned the hat > > unofficially a few times lately, so FWIW I think the Loongson stuff > > should go through the MIPS tree, since it so often touches core > > architecture code. > Yes we are always touching architecture code. For that part, we'll > still submit our patches to linux-mips tree. But we're also maintaining > many platform code under /arch/mips/loongson64 and also platform > drivers such as hwmon, cpufreq and YeeLoong Laptop driver I'm trying to > submit recently. The drivers at least can always go in via the relevant driver subsystem anyway, though of course if they're tightly bound to arch headers that could still be painful, as I found out here when trying to fix some build errors there: https://lkml.kernel.org/r/20171115211755.25102-1-james.ho...@mips.com Cheers James > For that part, make a pull request might be more > efficient than apply patches to linux-mips for many times. Just as what > arm architecture did. signature.asc Description: Digital signature
Re: [PATCH v3] leds: trigger: Introduce a NETDEV trigger
Philippe, On 7 December 2017 at 13:01, Philippe Ombredanne wrote: > Ben, > > On Thu, Dec 7, 2017 at 12:46 PM, Ben Whitten wrote: >> From: Ben Whitten >> >> This commit introduces a NETDEV trigger for named device >> activity. Available triggers are link, rx, and tx. >> >> Signed-off-by: Ben Whitten > [] >> --- /dev/null >> +++ b/drivers/leds/trigger/ledtrig-netdev.c >> @@ -0,0 +1,503 @@ >> +/* >> + * LED Kernel Netdev Trigger >> + * >> + * Toggles the LED to reflect the link and traffic state of a named net >> device >> + * >> + * Copyright 2017 Ben Whitten >> + * >> + * Copyright 2007 Oliver Jowett >> + * >> + * Derived from ledtrig-timer.c which is: >> + * Copyright 2005-2006 Openedhand Ltd. >> + * Author: Richard Purdie >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + */ > > Have you considered using the new SPDX id instead ? See Thomas doc > patches and Greg and Linus comments on the topic > Here this would likely come out this way (yes, using a C++ comment at the > top): > >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * LED Kernel Netdev Trigger >> + * >> + * Toggles the LED to reflect the link and traffic state of a named net >> device >> + * >> + * Copyright 2017 Ben Whitten >> + * >> + * Copyright 2007 Oliver Jowett >> + * >> + * Derived from ledtrig-timer.c which is: >> + * Copyright 2005-2006 Openedhand Ltd. >> + * Author: Richard Purdie >> + * >> + */ > > > This is cleaner and simpler, don't you think? Much cleaner. Thank you for the suggestion, I was unaware of this. Kind regards, Ben Whitten
Re: [PATCH v4 2/2] dt-bindings: add eeprom "at24,no-read-rollover" property
2017-12-07 15:06 GMT+01:00 Sven Van Asbroeck : >> at24 is not a vendor prefix. Either this is atmel specific and you want >> atmel,no-read-rollover or it is for all vendors at24 compatible eeproms >> and you want at24-no-read-rollover. Or just drop the at24 if this >> binding is in fact for just at24 eeproms as none of the other properties >> has at24 in them. > > Bartosz, shall I rename > at24,no-read-rollover -> no-read-rollover ? Yes, please. Thanks, Bartosz
Re: ath10k: use 64-bit crash dump timestamps
Arnd Bergmann wrote: > The dump format uses 64-bit timestamps already, but calling > getnstimeofday() only returns a 32-bit number on 32-bit architectures, > so that will overflow in y2038. > > This changes it to use ktime_get_real_ts64() instead. > > Signed-off-by: Arnd Bergmann > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. dafa42036012 ath10k: use 64-bit crash dump timestamps -- https://patchwork.kernel.org/patch/10076697/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: PI futexes + lock stealing woes
On Thu, Dec 07, 2017 at 11:45:16AM +0100, Peter Zijlstra wrote:
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 76ed5921117a..8ad5221fbd84 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2303,14 +2303,35 @@ static void unqueue_me_pi(struct futex_q *q)
> static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
> struct task_struct *newowner)
> {
> - u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
> struct futex_pi_state *pi_state = q->pi_state;
> u32 uval, uninitialized_var(curval), newval;
> struct task_struct *oldowner;
> + u32 newtid;
> int ret;
>
> raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
>
> + if (!newowner) {
> + if (__rt_mutex_futex_trylock(&pi_state->pi_mutex)) {
> + ret = 0;
> + goto out_unlock;
> + }
> +
> + newowner = rt_mutex_owner(&pi_state->pi_mutex);
> + if (WARN_ON_ONCE(!newowner)) {
> + /*
> + * We just attempted a trylock; since that failed there
> + * must be an owner, right?
> + */
> + ret = -EFUCKED; /* XXX: check return paths */
> + goto out_unlock;
> + }
> +
> + /* OK we have a newowner, fixup uval */
> + }
> +
> + newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
> +
> oldowner = pi_state->owner;
> /* Owner died? */
> if (!pi_state->owner)
OK, this is broken because it needs to be inside the retry label,
because we drop the locks when we take a fault. And if we drop the lock,
the rt_mutex owner can change etc..
> @@ -2443,6 +2464,16 @@ static int fixup_owner(u32 __user *uaddr, struct
> futex_q *q, int locked)
> goto out;
> }
>
> + /*
> + * If we didn't get the lock; check if nobody stole it from us.
> + * In that case, we need to fix up the uval to point to them
> + * instead of us, otherwise bad things happen.
> + */
> + if (q->pi_state->owner == current) {
> + ret = fixup_pi_state_owner(uaddr, q, NULL);
> + goto out;
> + }
And this had me read the comment just above here that stated the
unlocked access of ->owner is fine, because only the rt_mutex owner
changes pi_state, except of course, this just changed that.
So now we need double check the state after we've taken the lock in
fixup_pi_state_owner().
The below compiles and boots, but is otherwise untested. Could you give
it a spin?
---
kernel/futex.c | 83 +
kernel/locking/rtmutex.c| 26 +
kernel/locking/rtmutex_common.h | 1 +
3 files changed, 87 insertions(+), 23 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 76ed5921117a..29ac5b64e7c7 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2294,21 +2294,17 @@ static void unqueue_me_pi(struct futex_q *q)
spin_unlock(q->lock_ptr);
}
-/*
- * Fixup the pi_state owner with the new owner.
- *
- * Must be called with hash bucket lock held and mm->sem held for non
- * private futexes.
- */
static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
- struct task_struct *newowner)
+ struct task_struct *argowner)
{
- u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
struct futex_pi_state *pi_state = q->pi_state;
u32 uval, uninitialized_var(curval), newval;
- struct task_struct *oldowner;
+ struct task_struct *oldowner, *newowner;
+ u32 newtid;
int ret;
+ lockdep_assert_held(q->lock_ptr);
+
raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
oldowner = pi_state->owner;
@@ -2317,11 +2313,17 @@ static int fixup_pi_state_owner(u32 __user *uaddr,
struct futex_q *q,
newtid |= FUTEX_OWNER_DIED;
/*
-* We are here either because we stole the rtmutex from the
-* previous highest priority waiter or we are the highest priority
-* waiter but have failed to get the rtmutex the first time.
+* We are here because either:
+*
+* - we stole the lock and pi_state->owner needs updating to reflect
+*that (@argowner == current),
*
-* We have to replace the newowner TID in the user space variable.
+* or:
+*
+* - someone stole our lock and we need to fix things to point to the
+*new owner (@argowner == NULL).
+*
+* Either way, we have to replace the TID in the user space variable.
* This must be atomic as we have to preserve the owner died bit here.
*
* Note: We write the user space value _before_ changing the pi_state
@@ -2334,6 +2336,42 @@ static int fixup_pi_state_owner(u32 __user *uaddr,
struct futex_q *q,
*
[PATCH net-next v2 8/8] net: phy: meson-gxl: join the authors
Following previous changes, join the other authors of this driver and
take the blame with them
Signed-off-by: Jerome Brunet
---
drivers/net/phy/meson-gxl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 861b021b9758..4cd5b2622ae1 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -256,4 +256,5 @@ MODULE_DEVICE_TABLE(mdio, meson_gxl_tbl);
MODULE_DESCRIPTION("Amlogic Meson GXL Internal PHY driver");
MODULE_AUTHOR("Baoqi wang");
MODULE_AUTHOR("Neil Armstrong ");
+MODULE_AUTHOR("Jerome Brunet ");
MODULE_LICENSE("GPL");
--
2.14.3
Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
On Tue, 5 Dec 2017 18:01:46 +0800 Gary Lin wrote: > The series of patches introduce Security Version to EFI stub. > > Security Version is a monotonically increasing number and designed to > prevent the user from loading an insecure kernel accidentally. The > bootloader maintains a list of security versions corresponding to > different distributions. After fixing a critical vulnerability, the > distribution kernel maintainer bumps the "version", and the bootloader > updates the list automatically. This seems a mindbogglingly complicated way to implement something you could do with a trivial script in the package that updates the list of iffy kernels and when generating the new grub.conf puts them in a menu of 'old insecure' kernels. Why do you even need this in the EFI stub ? What happens if you want to invalidate an old kernel but not push a new one ? Today if you've got a package that maintains the list of 'iffy' kernels you can push a tiny package, under your scheme you've got to push new kernels which is an un-necessary and high risk OS change. It just feels like an attempt to solve the problem in completely the wrong place. Alan
[PATCH net-next v2 2/8] net: phy: meson-gxl: define control registers
Define registers and bits in meson-gxl PHY driver to make a bit
more human friendly. No functional change.
Signed-off-by: Neil Armstrong
Signed-off-by: Jerome Brunet
---
drivers/net/phy/meson-gxl.c | 64 -
1 file changed, 51 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 7ddb709f69fc..d82aa8cea401 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -22,54 +22,92 @@
#include
#include
#include
+#include
+
+#define TSTCNTL20
+#define TSTCNTL_READ BIT(15)
+#define TSTCNTL_WRITE BIT(14)
+#define TSTCNTL_REG_BANK_SEL GENMASK(12, 11)
+#define TSTCNTL_TEST_MODE BIT(10)
+#define TSTCNTL_READ_ADDRESS GENMASK(9, 5)
+#define TSTCNTL_WRITE_ADDRESS GENMASK(4, 0)
+#define TSTREAD1 21
+#define TSTWRITE 23
+
+#define BANK_ANALOG_DSP0
+#define BANK_BIST 3
+
+/* Analog/DSP Registers */
+#define A6_CONFIG_REG 0x17
+
+/* BIST Registers */
+#define FR_PLL_CONTROL 0x1b
+#define FR_PLL_DIV00x1c
+#define FR_PLL_DIV10x1d
static int meson_gxl_config_init(struct phy_device *phydev)
{
int ret;
/* Enable Analog and DSP register Bank access by */
- ret = phy_write(phydev, 0x14, 0x);
+ ret = phy_write(phydev, TSTCNTL, 0);
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x0400);
+ ret = phy_write(phydev, TSTCNTL, TSTCNTL_TEST_MODE);
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x);
+ ret = phy_write(phydev, TSTCNTL, 0);
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x0400);
+ ret = phy_write(phydev, TSTCNTL, TSTCNTL_TEST_MODE);
if (ret)
return ret;
- /* Write Analog register 23 */
- ret = phy_write(phydev, 0x17, 0x8E0D);
+ /* Write CONFIG_A6*/
+ ret = phy_write(phydev, TSTWRITE, 0x8e0d)
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x4417);
+ ret = phy_write(phydev, TSTCNTL,
+ TSTCNTL_WRITE
+ | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_ANALOG_DSP)
+ | TSTCNTL_TEST_MODE
+ | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, A6_CONFIG_REG));
if (ret)
return ret;
/* Enable fractional PLL */
- ret = phy_write(phydev, 0x17, 0x0005);
+ ret = phy_write(phydev, TSTWRITE, 0x0005);
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x5C1B);
+ ret = phy_write(phydev, TSTCNTL,
+ TSTCNTL_WRITE
+ | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_BIST)
+ | TSTCNTL_TEST_MODE
+ | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, FR_PLL_CONTROL));
if (ret)
return ret;
/* Program fraction FR_PLL_DIV1 */
- ret = phy_write(phydev, 0x17, 0x029A);
+ ret = phy_write(phydev, TSTWRITE, 0x029a);
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x5C1D);
+ ret = phy_write(phydev, TSTCNTL,
+ TSTCNTL_WRITE
+ | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_BIST)
+ | TSTCNTL_TEST_MODE
+ | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, FR_PLL_DIV1));
if (ret)
return ret;
/* Program fraction FR_PLL_DIV1 */
- ret = phy_write(phydev, 0x17, 0x);
+ ret = phy_write(phydev, TSTWRITE, 0x);
if (ret)
return ret;
- ret = phy_write(phydev, 0x14, 0x5C1C);
+ ret = phy_write(phydev, TSTCNTL,
+ TSTCNTL_WRITE
+ | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_BIST)
+ | TSTCNTL_TEST_MODE
+ | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, FR_PLL_DIV0));
if (ret)
return ret;
--
2.14.3
[PATCH net-next v2 7/8] net: phy: meson-gxl: add interrupt support
Enable interrupt support in meson-gxl PHY driver
Signed-off-by: Jerome Brunet
---
drivers/net/phy/meson-gxl.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 5325940fe899..861b021b9758 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -33,6 +33,14 @@
#define TSTCNTL_WRITE_ADDRESS GENMASK(4, 0)
#define TSTREAD1 21
#define TSTWRITE 23
+#define INTSRC_FLAG29
+#define INTSRC_ANEG_PRBIT(1)
+#define INTSRC_PARALLEL_FAULT BIT(2)
+#define INTSRC_ANEG_LP_ACKBIT(3)
+#define INTSRC_LINK_DOWN BIT(4)
+#define INTSRC_REMOTE_FAULT BIT(5)
+#define INTSRC_ANEG_COMPLETE BIT(6)
+#define INTSRC_MASK30
#define BANK_ANALOG_DSP0
#define BANK_WOL 1
@@ -193,17 +201,44 @@ int meson_gxl_read_status(struct phy_device *phydev)
return genphy_read_status(phydev);
}
+static int meson_gxl_ack_interrupt(struct phy_device *phydev)
+{
+ int ret = phy_read(phydev, INTSRC_FLAG);
+
+ return ret < 0 ? ret : 0;
+}
+
+static int meson_gxl_config_intr(struct phy_device *phydev)
+{
+ u16 val;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED) {
+ val = INTSRC_ANEG_PR
+ | INTSRC_PARALLEL_FAULT
+ | INTSRC_ANEG_LP_ACK
+ | INTSRC_LINK_DOWN
+ | INTSRC_REMOTE_FAULT
+ | INTSRC_ANEG_COMPLETE;
+ } else {
+ val = 0;
+ }
+
+ return phy_write(phydev, INTSRC_MASK, val);
+}
+
static struct phy_driver meson_gxl_phy[] = {
{
.phy_id = 0x01814400,
.phy_id_mask= 0xfff0,
.name = "Meson GXL Internal PHY",
.features = PHY_BASIC_FEATURES,
- .flags = PHY_IS_INTERNAL,
+ .flags = PHY_IS_INTERNAL | PHY_HAS_INTERRUPT,
.config_init= meson_gxl_config_init,
.config_aneg= genphy_config_aneg,
.aneg_done = genphy_aneg_done,
.read_status= meson_gxl_read_status,
+ .ack_interrupt = meson_gxl_ack_interrupt,
+ .config_intr= meson_gxl_config_intr,
.suspend= genphy_suspend,
.resume = genphy_resume,
},
--
2.14.3
[PATCH net-next v2 6/8] net: phy: meson-gxl: leave CONFIG_A6 untouched
The PHY performs just as well when left in its default configuration and
it makes senses because this poke gets reset just after init.
According to the documentation, all registers in the Analog/DSP bank are
reset when there is a mode switch from 10BT to 100BT.
In the end, we have used the default configuration so far and there is no
reason to change now. Remove CONFIG_A6 poke to make this clear.
Signed-off-by: Jerome Brunet
---
Out of curiosity, I tried to re-apply the ANALOG/DSP settings on speed
changes (patch available here [0] if someone wants to try) but I did
not notice any change as a result. In the end, I thought it was safer
to keep on using the ANALOG settings we have been actually using so far,
everybody seems to be happy with them
[0]:
https://github.com/jeromebrunet/linux/commit/b594288e629a61574e76112497474fd3cf46c781
drivers/net/phy/meson-gxl.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 726e0eeed475..5325940fe899 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -38,9 +38,6 @@
#define BANK_WOL 1
#define BANK_BIST 3
-/* Analog/DSP Registers */
-#define A6_CONFIG_REG 0x17
-
/* WOL Registers */
#define LPI_STATUS 0xc
#define LPI_STATUS_RSV12 BIT(12)
@@ -126,12 +123,6 @@ static int meson_gxl_config_init(struct phy_device *phydev)
{
int ret;
- /* Write CONFIG_A6*/
- ret = meson_gxl_write_reg(phydev, BANK_ANALOG_DSP, A6_CONFIG_REG,
- 0x8e0d);
- if (ret)
- return ret;
-
/* Enable fractional PLL */
ret = meson_gxl_write_reg(phydev, BANK_BIST, FR_PLL_CONTROL, 0x5);
if (ret)
--
2.14.3
Re: [PATCH v4 6/8] staging: octeon: Remove USE_ASYNC_IOBDMA macro.
On Tue, Nov 28, 2017 at 04:55:38PM -0800, David Daney wrote: > Previous patch sets USE_ASYNC_IOBDMA to 1 unconditionally. Remove > USE_ASYNC_IOBDMA from all if statements. Remove dead code caused by > the change. > > Signed-off-by: David Daney Acked-by: Greg Kroah-Hartman
[PATCH net-next v2 1/8] net: phy: meson-gxl: check phy_write return value
Always check phy_write return values. Better to be safe than sorry
Signed-off-by: Jerome Brunet
---
drivers/net/phy/meson-gxl.c | 50 ++---
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 1ea69b7585d9..7ddb709f69fc 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -25,27 +25,53 @@
static int meson_gxl_config_init(struct phy_device *phydev)
{
+ int ret;
+
/* Enable Analog and DSP register Bank access by */
- phy_write(phydev, 0x14, 0x);
- phy_write(phydev, 0x14, 0x0400);
- phy_write(phydev, 0x14, 0x);
- phy_write(phydev, 0x14, 0x0400);
+ ret = phy_write(phydev, 0x14, 0x);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0400);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0400);
+ if (ret)
+ return ret;
/* Write Analog register 23 */
- phy_write(phydev, 0x17, 0x8E0D);
- phy_write(phydev, 0x14, 0x4417);
+ ret = phy_write(phydev, 0x17, 0x8E0D);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x4417);
+ if (ret)
+ return ret;
/* Enable fractional PLL */
- phy_write(phydev, 0x17, 0x0005);
- phy_write(phydev, 0x14, 0x5C1B);
+ ret = phy_write(phydev, 0x17, 0x0005);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1B);
+ if (ret)
+ return ret;
/* Program fraction FR_PLL_DIV1 */
- phy_write(phydev, 0x17, 0x029A);
- phy_write(phydev, 0x14, 0x5C1D);
+ ret = phy_write(phydev, 0x17, 0x029A);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1D);
+ if (ret)
+ return ret;
/* Program fraction FR_PLL_DIV1 */
- phy_write(phydev, 0x17, 0x);
- phy_write(phydev, 0x14, 0x5C1C);
+ ret = phy_write(phydev, 0x17, 0x);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1C);
+ if (ret)
+ return ret;
return 0;
}
--
2.14.3
[PATCH net-next v2 3/8] net: phy: meson-gxl: add read and write helpers for bank registers
Add read and write helpers to manipulate banked registers on this PHY
This helps clarify the settings applied to these registers in the init
function and upcoming changes.
Signed-off-by: Jerome Brunet
---
drivers/net/phy/meson-gxl.c | 103
1 file changed, 67 insertions(+), 36 deletions(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index d82aa8cea401..05054770aefb 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -45,11 +45,13 @@
#define FR_PLL_DIV00x1c
#define FR_PLL_DIV10x1d
-static int meson_gxl_config_init(struct phy_device *phydev)
+static int meson_gxl_open_banks(struct phy_device *phydev)
{
int ret;
- /* Enable Analog and DSP register Bank access by */
+ /* Enable Analog and DSP register Bank access by
+* toggling TSTCNTL_TEST_MODE bit in the TSTCNTL register
+*/
ret = phy_write(phydev, TSTCNTL, 0);
if (ret)
return ret;
@@ -59,55 +61,84 @@ static int meson_gxl_config_init(struct phy_device *phydev)
ret = phy_write(phydev, TSTCNTL, 0);
if (ret)
return ret;
- ret = phy_write(phydev, TSTCNTL, TSTCNTL_TEST_MODE);
- if (ret)
- return ret;
+ return phy_write(phydev, TSTCNTL, TSTCNTL_TEST_MODE);
+}
- /* Write CONFIG_A6*/
- ret = phy_write(phydev, TSTWRITE, 0x8e0d)
+static void meson_gxl_close_banks(struct phy_device *phydev)
+{
+ phy_write(phydev, TSTCNTL, 0);
+}
+
+static int meson_gxl_read_reg(struct phy_device *phydev,
+ unsigned int bank, unsigned int reg)
+{
+ int ret;
+
+ ret = meson_gxl_open_banks(phydev);
if (ret)
- return ret;
- ret = phy_write(phydev, TSTCNTL,
- TSTCNTL_WRITE
- | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_ANALOG_DSP)
- | TSTCNTL_TEST_MODE
- | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, A6_CONFIG_REG));
+ goto out;
+
+ ret = phy_write(phydev, TSTCNTL, TSTCNTL_READ |
+ FIELD_PREP(TSTCNTL_REG_BANK_SEL, bank) |
+ TSTCNTL_TEST_MODE |
+ FIELD_PREP(TSTCNTL_READ_ADDRESS, reg));
if (ret)
- return ret;
+ goto out;
- /* Enable fractional PLL */
- ret = phy_write(phydev, TSTWRITE, 0x0005);
+ ret = phy_read(phydev, TSTREAD1);
+out:
+ /* Close the bank access on our way out */
+ meson_gxl_close_banks(phydev);
+ return ret;
+}
+
+static int meson_gxl_write_reg(struct phy_device *phydev,
+ unsigned int bank, unsigned int reg,
+ uint16_t value)
+{
+ int ret;
+
+ ret = meson_gxl_open_banks(phydev);
if (ret)
- return ret;
- ret = phy_write(phydev, TSTCNTL,
- TSTCNTL_WRITE
- | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_BIST)
- | TSTCNTL_TEST_MODE
- | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, FR_PLL_CONTROL));
+ goto out;
+
+ ret = phy_write(phydev, TSTWRITE, value);
if (ret)
- return ret;
+ goto out;
- /* Program fraction FR_PLL_DIV1 */
- ret = phy_write(phydev, TSTWRITE, 0x029a);
+ ret = phy_write(phydev, TSTCNTL, TSTCNTL_WRITE |
+ FIELD_PREP(TSTCNTL_REG_BANK_SEL, bank) |
+ TSTCNTL_TEST_MODE |
+ FIELD_PREP(TSTCNTL_WRITE_ADDRESS, reg));
+
+out:
+ /* Close the bank access on our way out */
+ meson_gxl_close_banks(phydev);
+ return ret;
+}
+
+static int meson_gxl_config_init(struct phy_device *phydev)
+{
+ int ret;
+
+ /* Write CONFIG_A6*/
+ ret = meson_gxl_write_reg(phydev, BANK_ANALOG_DSP, A6_CONFIG_REG,
+ 0x8e0d);
if (ret)
return ret;
- ret = phy_write(phydev, TSTCNTL,
- TSTCNTL_WRITE
- | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_BIST)
- | TSTCNTL_TEST_MODE
- | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, FR_PLL_DIV1));
+
+ /* Enable fractional PLL */
+ ret = meson_gxl_write_reg(phydev, BANK_BIST, FR_PLL_CONTROL, 0x5);
if (ret)
return ret;
/* Program fraction FR_PLL_DIV1 */
- ret = phy_write(phydev, TSTWRITE, 0x);
+ ret = meson_gxl_write_reg(phydev, BANK_BIST, FR_PLL_DIV1, 0x029a);
if (ret)
return ret;
- ret = phy_write(phydev, TSTCNTL,
- TSTCNTL_WRITE
- | FIELD_PREP(TSTCNTL_REG_BANK_SEL, BANK_BIST)
- | TSTCNTL_TEST_MODE
- | FIELD_PREP(TSTCNTL_WRITE_ADDRESS, FR_PLL_DIV0));
+
+ /
[PATCH net-next v2 5/8] net: phy: meson-gxl: detect LPA corruption
The purpose of this change is to fix the incorrect detection of the link
partner (LP) advertised capabilities which sometimes happens with this PHY
(roughly 1 time in a dozen)
This issue may cause the link to be negotiated at 10Mbps/Full or
10Mbps/Half when 100MBps/Full is actually possible. In some case, the link
is even completely broken and no communication is possible.
To detect the corruption, we must look for a magic undocumented bit in the
WOL bank (hint given by the SoC vendor kernel) but this is not enough to
cover all cases. We also have to look at the LPA ack. If the LP supports
Aneg but did not ack our base code when aneg is completed, we assume
something went wrong.
The detection of a corrupted LPA triggers a restart of the aneg process.
This solves the problem but may take up to 6 retries to complete.
Fixes: 7334b3e47aee ("net: phy: Add Meson GXL Internal PHY driver")
Signed-off-by: Jerome Brunet
---
I suppose this patch probably seems a bit hacky, especially the part
about the link partner acknowledge. I'm trying to figure out if the
value in MII_LPA makes sense but I don't have such a deep knowledge
of the ethernet spec.
To me, it does not makes sense for the LP to support ANEG (Bit 1 in
MII_EXPENSION), the aneg to have successfully complete and, at the
same time, LP does not ACK our base code word, which we should have
sent during this aneg.
If you think this may have unintended consequences or if you have
an idea to this differently, feel free to let me know.
drivers/net/phy/meson-gxl.c | 59 -
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 2e8c40df33c2..726e0eeed475 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -35,11 +35,16 @@
#define TSTWRITE 23
#define BANK_ANALOG_DSP0
+#define BANK_WOL 1
#define BANK_BIST 3
/* Analog/DSP Registers */
#define A6_CONFIG_REG 0x17
+/* WOL Registers */
+#define LPI_STATUS 0xc
+#define LPI_STATUS_RSV12 BIT(12)
+
/* BIST Registers */
#define FR_PLL_CONTROL 0x1b
#define FR_PLL_DIV00x1c
@@ -145,6 +150,58 @@ static int meson_gxl_config_init(struct phy_device *phydev)
return genphy_config_init(phydev);
}
+/* This specific function is provided to cope with the possible failures of
+ * this phy during aneg process. When aneg fails, the PHY reports that aneg
+ * is done but the value found in MII_LPA is wrong:
+ * - Early failures: MII_LPA is just 0x0001. if MII_EXPANSION reports that
+ *the link partner (LP) supports aneg but the LP never acked our base
+ *code word, it is likely that we never sent it to begin with.
+ * - Late failures: MII_LPA is filled with a value which seems to make sense
+ *but it actually is not what the LP is advertising. It seems that we
+ *can detect this using a magic bit in the WOL bank (reg 12 - bit 12).
+ *If this particular bit is not set when aneg is reported being done,
+ *it means MII_LPA is likely to be wrong.
+ *
+ * In both case, forcing a restart of the aneg process solve the problem.
+ * When this failure happens, the first retry is usually successful but,
+ * in some cases, it may take up to 6 retries to get a decent result
+ */
+int meson_gxl_read_status(struct phy_device *phydev)
+{
+ int ret, wol, lpa, exp;
+
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ ret = genphy_aneg_done(phydev);
+ if (ret < 0)
+ return ret;
+ else if (!ret)
+ goto read_status_continue;
+
+ /* Aneg is done, let's check everything is fine */
+ wol = meson_gxl_read_reg(phydev, BANK_WOL, LPI_STATUS);
+ if (wol < 0)
+ return wol;
+
+ lpa = phy_read(phydev, MII_LPA);
+ if (lpa < 0)
+ return lpa;
+
+ exp = phy_read(phydev, MII_EXPANSION);
+ if (exp < 0)
+ return exp;
+
+ if (!(wol & LPI_STATUS_RSV12) ||
+ ((exp & EXPANSION_NWAY) && !(lpa & LPA_LPACK))) {
+ /* Looks like aneg failed after all */
+ phydev_dbg(phydev, "LPA corruption - aneg restart\n");
+ return genphy_restart_aneg(phydev);
+ }
+ }
+
+read_status_continue:
+ return genphy_read_status(phydev);
+}
+
static struct phy_driver meson_gxl_phy[] = {
{
.phy_id = 0x01814400,
@@ -155,7 +212,7 @@ static struct phy_driver meson_gxl_phy[] = {
.config_init= meson_gxl_config_init,
.config_aneg= genphy_config_aneg,
.aneg_done = genphy_aneg_done,
- .read_status= genphy_read_status,
+ .read_status= meson_gxl_read_status,
[PATCH net-next v2 4/8] net: phy: meson-gxl: use genphy_config_init
Use the generic init function to populate some of the phydev
structure fields
Signed-off-by: Jerome Brunet
---
drivers/net/phy/meson-gxl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 05054770aefb..2e8c40df33c2 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -142,7 +142,7 @@ static int meson_gxl_config_init(struct phy_device *phydev)
if (ret)
return ret;
- return 0;
+ return genphy_config_init(phydev);
}
static struct phy_driver meson_gxl_phy[] = {
--
2.14.3
Re: [PATCH 2/2] i2c: fix piix4 aux port number
Hi Andrew,
On Thu, 23 Nov 2017 13:09:38 +1000, Andrew Cooks wrote:
> Let the aux port use port number one (not zero), to match the AMD
> documentation and enable mapping ACPI _ADR to port number.
>
> This fixes ACPI-based enumeration of I2C slave peripherals that are
> defined for the aux SMBus port.
>
> Signed-off-by: Andrew Cooks
> ---
> drivers/i2c/busses/i2c-piix4.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
> index 9260cfa..f980f0b 100644
> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -975,7 +975,7 @@ static int piix4_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> if (retval > 0) {
> /* Try to add the aux adapter if it exists,
>* piix4_add_adapter will clean up if this fails */
> - piix4_add_adapter(dev, retval, false, 0, false,
> + piix4_add_adapter(dev, retval, false, 1, false,
> is_sb800 ? piix4_aux_port_name_sb800 : "",
> &piix4_aux_adapter);
> }
The port number has consequences. In piix4_adap_remove, port 0 is
handled differently. We assume that for each controller (main or aux)
exactly one adapter has port number 0. Your change above breaks this
assumption.
Also, if the port numbers are supposed to match the documentation, and
the aux controller is port 1, then I wonder how are the muxed ports of
the main controller numbered? The driver numbers them from 1 to 3, but
I guess the documentation numbers them from 2 to 4 to avoid colliding
with the aux controller? I have vague memories of discussion this
before... If it is important that aux port number matches the
documentation then I guess the same holds for the muxed ports on the
main controller.
If we number muxed ports from 2 to 4 then the test in piix4_adap_remove
could be simply changed to check for adapdata->port <= 1.
Please note that I just sent a fix for this specific function, so any
patch touching the same area should go on top of it. I'll bounce it to
you.
--
Jean Delvare
SUSE L3 Support
Re: [PATCH 1/3] ath9k: remove stray backslash in Makefile
Jakub Kicinski writes: > On Mon, 27 Nov 2017 18:56:21 +0100, Matthias Schiffer wrote: >> Signed-off-by: Matthias Schiffer >> --- >> drivers/net/wireless/ath/ath9k/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/wireless/ath/ath9k/Makefile >> b/drivers/net/wireless/ath/ath9k/Makefile >> index 36a40ffdce15..90e4a341076c 100644 >> --- a/drivers/net/wireless/ath/ath9k/Makefile >> +++ b/drivers/net/wireless/ath/ath9k/Makefile >> @@ -59,7 +59,7 @@ obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o >> obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o >> ath9k_common-y:=common.o \ >> common-init.o \ >> -common-beacon.o \ >> +common-beacon.o >> > > It's not necessarily stray, there is nothing on the next line so it's > OK, and if you add \ at the end of all lines, you don't have to touch > the last line every time you add/remove something. Sort of like > putting a , after last enum value. I agree with Jakub, I think the backslash is there on purpose so I dropped this patch. -- Kalle Valo
Re: [PATCH v6 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver
Hi Brian,
On 12/06/2017 10:52 PM, Brian Norris wrote:
> Hi Nickey, others,
>
> I just want to highlight a thing or two here. Otherwise, my
> 'Reviewed-by' still basically stands (FWIW).
>
> On Wed, Dec 06, 2017 at 05:08:21PM +0800, Nickey Yang wrote:
>> Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
>> MIPI DSI host controller bridge.
>>
>> Signed-off-by: Nickey Yang
>> Signed-off-by: Brian Norris
>> Reviewed-by: Brian Norris
>> Reviewed-by: Sean Paul
>> ---
>> change:
>>
>> v2:
>> add err_pllref, remove unnecessary encoder.enable & disable
>> correct spelling mistakes
>> v3:
>> call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
>> fix typo, use of_device_get_match_data(),
>> change some ‘bind()’ logic into 'probe()'
>> add 'dev_set_drvdata()'
>> v4:
>>return -EINVAL when can not get best_freq
>>add a clarifying comment when get vco
>>add review tag
>> v5:
>>keep our power domain enabled while touching GRF
>> v6:
>>change func dw_mipi_encoder_disable name to
>>dw_mipi_dsi_encoder_disable
>
> We noticed a regression w.r.t. pm_runtime_*() handling using this patch,
> hence the pm_runtime changes in v5/v6. We actually need to keep our
> power domain enabled in the mode_set() function, where we start to
> configure some Rockchip-specific registers (GRF). More on that below.
>
>>
>> drivers/gpu/drm/rockchip/Kconfig|2 +-
>> drivers/gpu/drm/rockchip/Makefile |2 +-
>> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349
>> ---
>> drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c | 785 +
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
>> 6 files changed, 789 insertions(+), 1353 deletions(-)
>> delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>> create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>>
>
> ...
>
>> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>> b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>> new file mode 100644
>> index 000..66ab6fe
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>> @@ -0,0 +1,785 @@
>
> ...
>
>> +static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted)
>> +{
>> +struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
>> +const struct rockchip_dw_dsi_chip_data *cdata = dsi->cdata;
>> +int val, ret, mux;
>> +
>> +mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node,
>> +&dsi->encoder);
>> +if (mux < 0)
>> +return;
>> +/*
>> + * For the RK3399, the clk of grf must be enabled before writing grf
>> + * register. And for RK3288 or other soc, this grf_clk must be NULL,
>> + * the clk_prepare_enable return true directly.
>> + */
>> +ret = clk_prepare_enable(dsi->grf_clk);
>> +if (ret) {
>> +DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
>> +return;
>> +}
>> +pm_runtime_get_sync(dsi->dev);
>
> What happens if there's a clk_prepare_enable() failure or failure to
> retrieve the endpoint ID earlier in this function? You won't call
> pm_runtime_get_*()...but might we still see a call to
> dw_mipi_dsi_encoder_disable(), which would mean we get unbalanced
> runtime PM status?
>
> Also (and more importantly), is it fair to do all of this in mode_set()?
> I believe Archit asked about this before, and the reason we're doing
> this stuff in mode_set() now (where previously, the Rockchip driver was
> doing it in ->enable()) is because when Philippe extracted the synopsys
> bridge driver, that code migrated to ->mode_set().
Regarding mode_set(), let's me explain more what I did:
- transform the original code from Rockchip (encoder + connector drm
api) to a generic bridge (bridge drm api).
- add panel-bridge interface
- ... (more details in the change log
https://www.spinics.net/lists/dri-devel/msg147167.html)
So we have:
crtc -> dw mipi dsi bridge -> panel-bridge "bridge next" -> panel
The bridge pre_enable() calls first the "bridge next" pre_enable() (ie
the panel-bridge pre-enable) before calling the bridge pre_enable (ie
the dw mipi dsi bridge pre-enable (not used here). see in
drm_bridge_pre_enable() in drm_bridge.c for details
The panel-bridge pre_enable() calls drm_panel_prepare(). See in
bridge/panel.c for details.
So in the dw mipi dsi bridge, we need to configure and start
"everything" before the bridge pre_enable so I put the "former" encoder
enable() source code into the new bridge mode_set().
Tell me if I am not clear enough as it is not so easy to explain : )
Thanks,
Philippe :-)
>
> But, I'm reading the comments on drm_encoder_helpe
[PATCH net-next v2 0/8] phy: net: meson-gxl: clean-up and improvements
The patchset is a v2 of the previous single clean-up patch [0] which was part of larger series. I initially to send these patches separately but adding helper function without using them did not make much sense after all. So, here is the complete patchset. This patchset add defines for the control registers and helpers to access the banked registers. The goal being to make it easier to understand what the driver actually does. Then there is fix for the incorrect sampling of the MII LPA register which is often breaking the auto-negotiation with this PHY. More details on this in the related patch CONFIG_A6 settings is removed since this statement was without effect Finally interrupt support is added, speeding things up a little This series has been tested on the libretech-cc and khadas VIM Jerome Brunet (8): net: phy: meson-gxl: check phy_write return value net: phy: meson-gxl: define control registers net: phy: meson-gxl: add read and write helpers for bank registers net: phy: meson-gxl: use genphy_config_init net: phy: meson-gxl: detect LPA corruption net: phy: meson-gxl: leave CONFIG_A6 untouched net: phy: meson-gxl: add interrupt support net: phy: meson-gxl: join the authors drivers/net/phy/meson-gxl.c | 215 1 file changed, 197 insertions(+), 18 deletions(-) -- 2.14.3
Re: [RFC PATCH 1/6] drm: Add Content Protection property
> If you want to actually lock down a machine to implement content > protection, then you need secure boot without unlockable boot-loader and a > pile more bits in userspace. So let me take my Intel hat off for a moment. The upstream policy has always been that we don't merge things which don't have an open usable user space. Is the HDCP encryption feature useful on its own ? What do users get from it ? If this is just an enabler for a lump of binary stuff in ChromeOS then I don't think it belongs, if it is useful standalone then it seems it does belong ? Alan
Re: [RFC PATCH 1/6] drm: Add Content Protection property
> How about for sensitive video streams in government offices where you > want to avoid a spy potentially tapping the cable to see the video > stream? Last time I checked HDCP did not meet government security requirements - which is hardly surprising since you can buy $10 boxes from China to de-hdcp video streams 8) Alan
Re: [2/3] ath9k: move spectral scan support under a separate config symbol
Matthias Schiffer wrote: > At the moment, spectral scan support, and with it RELAY, is always enabled > with ATH9K[_HTC]_DEBUGFS. Spectral scan support is currently the only user > of RELAY in ath9k, and it unconditionally reserves a relay channel. > > Having debugfs support in ath9k is often useful even on very small embedded > routers, where we'd rather like to avoid the code size and RAM usage of the > relay support. > > Signed-off-by: Matthias Schiffer > Signed-off-by: Kalle Valo 2 patches applied to ath-next branch of ath.git, thanks. 9df7ddc3ed25 ath9k: move spectral scan support under a separate config symbol 42e01cb9cb10 ath10k: move spectral scan support under a separate config symbol -- https://patchwork.kernel.org/patch/10077735/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times
Hi gengdongjiu, Will,
On 07/12/17 05:55, gengdongjiu wrote:
> On 2017/12/7 0:15, Will Deacon wrote:
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr,
>>> struct pt_regs *regs)
>>> {
>>> struct siginfo info;
>>> const struct fault_info *inf;
>>> - int ret = 0;
>>>
>>> inf = esr_to_fault_info(esr);
>>> pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>>> @@ -585,7 +584,7 @@ static int do_sea(unsigned long addr, unsigned int esr,
>>> struct pt_regs *regs)
>>> if (interrupts_enabled(regs))
>>> nmi_enter();
>>>
>>> - ret = ghes_notify_sea();
>>> + ghes_notify_sea();
>>>
>>> if (interrupts_enabled(regs))
>>> nmi_exit();
>>> @@ -600,7 +599,7 @@ static int do_sea(unsigned long addr, unsigned int esr,
>>> struct pt_regs *regs)
>>> info.si_addr = (void __user *)addr;
>>> arm64_notify_die("", regs, &info, esr);
>>>
>>> - return ret;
>>> + return 0;
>> Hmm, so this code is a bit of mess.
>>
>> Wouldn't it be better to have the signal dispatching code in do_mem_abort
>> check ESR.ESR_ELx_FnV, so then do_sea wouldn't have to, and we could just
>> return an error instead?
FnV only applies to one of the Synchronous External Abort ESRs, hence it ended
up in here.
> Regardless ghes_notify_sea()'s return value, it always needs to deliver
> signal,
> because ghes_notify_sea()'s return value does not reflect whether the memory
> error
> handler(memory_failure()) handle the error successfully or failed. If let
> do_mem_abort()
> delivers the signal, we should always let do_sea() return error, then the
> do_mem_abort() can
> always deliver signal. Then we will see the strange log as shown below when
> happen Synchronous External Abort.
>
> [ 676.700652] Synchronous External Abort: synchronous external abort
> (0x96000410) at 0x33ff7008
> [ 676.723301] Unhandled fault: synchronous external abort (0x96000410) at
> 0x33ff7008
>
> so I think it is better send the signal in the do_sea(), not send it in the
> do_mem_abort().
I agree: I think improving the commit message would help here, something like:
-
do_sea() calls arm64_notify_die() which will always signal user-space.
It also returns whether APEI claimed the external abort as a RAS notification.
If it returns failure do_mem_abort() will signal user-space too.
do_mem_abort() wants to know if we handled the error, we always call
arm64_notify_die() so can always return success.
-
APEI's return value matters for KVM, and it will matter here too if we support
kernel-first.
> do_mem_abort() only send the signal when the exception does not defined in
> fault_info[]. Another benefit
> is that do_sea() can send different signal according to the Synchronous
> External Abort type, such as SIGBUS or SIGKILL.
> the do_mem_abort() can only send one kind signal.
(I'm not convinced we want to do this other than via the firwmare/kernel RAS
code, but that is a separate issue)
Thanks,
James
Re: [RFC PATCH] mm: unclutter THP migration
On Thu 07-12-17 22:10:47, Zi Yan wrote:
> Hi Michal,
>
> Thanks for sending this out.
>
> Michal Hocko wrote:
> > From: Michal Hocko
> >
> > THP migration is hacked into the generic migration with rather
> > surprising semantic. The migration allocation callback is supposed to
> > check whether the THP can be migrated at once and if that is not the
> > case then it allocates a simple page to migrate. unmap_and_move then
> > fixes that up by spliting the THP into small pages while moving the
> > head page to the newly allocated order-0 page. Remaning pages are moved
> > to the LRU list by split_huge_page. The same happens if the THP
> > allocation fails. This is really ugly and error prone [1].
> >
> > I also believe that split_huge_page to the LRU lists is inherently
> > wrong because all tail pages are not migrated. Some callers will just
>
> I agree with you that we should try to migrate all tail pages if the THP
> needs to be split. But this might not be compatible with "getting
> migration results" in unmap_and_move(), since a caller of
> migrate_pages() may want to know the status of each page in the
> migration list via int **result in get_new_page() (e.g.
> new_page_node()). The caller has no idea whether a THP in its migration
> list will be split or not, thus, storing migration results might be
> quite tricky if tail pages are added into the migration list.
Ouch. I wasn't aware of this "beauty". I will try to wrap my head around
this code and think about what to do about it. Thanks for point me to
it.
> We need to consider this when we clean up migrate_pages().
>
[...]
> > diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> > index a2246cf670ba..ec9503e5f2c2 100644
> > --- a/include/linux/migrate.h
> > +++ b/include/linux/migrate.h
> > @@ -43,9 +43,11 @@ static inline struct page *new_page_nodemask(struct page
> > *page,
> > return
> > alloc_huge_page_nodemask(page_hstate(compound_head(page)),
> > preferred_nid, nodemask);
> >
> > - if (thp_migration_supported() && PageTransHuge(page)) {
> > - order = HPAGE_PMD_ORDER;
> > + if (PageTransHuge(page)) {
> > + if (!thp_migration_supported())
> > + return NULL;
> We may not need these two lines, since if thp_migration_supported() is
> false, unmap_and_move() returns -ENOMEM in your code below, which has
> the same result of returning NULL here.
yes, this is a left over after rebase. Originally I used to have
thp_migration_supported in allocation callbacks but then moved it to
unmap_and_move to reduce the code duplication and also it makes much
more sense to have this up in the migration layer. I've fixed this up in
my local copy now.
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm: terminate shrink_slab loop if signal is pending
On 2017/12/07 17:34, Michal Hocko wrote: > On Wed 06-12-17 11:20:26, Suren Baghdasaryan wrote: >> Slab shrinkers can be quite time consuming and when signal >> is pending they can delay handling of the signal. If fatal >> signal is pending there is no point in shrinking that process >> since it will be killed anyway. This change checks for pending >> fatal signals inside shrink_slab loop and if one is detected >> terminates this loop early. > > This is not enough. You would have to make sure the direct reclaim will > bail out immeditally which is not at all that simple. We do check fatal > signals in throttle_direct_reclaim and conditionally in shrink_inactive_list > so even if you bail out from shrinkers we could still finish the full > reclaim cycle. > > Besides that shrinkers shouldn't really take very long so this looks > like it papers over a real bug somewhere else. I am not saying the patch > is wrong but it would deserve much more details to judge wether this is > the right way to go for your particular problem. > I wish that normal threads do not invoke direct reclaim operation. Only dedicated kernel threads (such as filesystem's writeback) invoke direct reclaim operation. Then, we can implement __GFP_KILLABLE for normal threads, and hopefully get rid of distinction between GFP_NOIO/ GFP_NOFS/GFP_KERNEL because reclaim (and locking) dependency becomes simpler.
Re: [PATCH] integrity: get rid of unneeded initializations in integrity_iint_cache entries
On Thu, 2017-12-07 at 07:01 -0500, Jeff Layton wrote: > On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote: > > On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote: > > > Quoting Jeff Layton (jlay...@kernel.org): > > > > From: Jeff Layton > > > > > > > > The init_once routine memsets the whole object to 0, and then > > > > explicitly sets some of the fields to 0 again. Just remove the explicit > > > > initializations. > > > > > > > > Signed-off-by: Jeff Layton > > > > > > Reviewed-by: Serge Hallyn > > > > Thanks, queued. > > > > Mimi > > > > Hi Mimi, > > I notice that this patch hasn't made the last couple of releases. Was it > dropped for some reason? Thanks for the reminder. I accidentally dropped it (and Sascha Hauer's patch). The subject line is too long. Assuming you don't object, I'll replace the "get rid of" with "removed" and queue the patch in the next-queued-testing branch. Mimi
[PATCH v5 0/2] at24: support eeproms that do not auto-rollover reads.
v5: at Rob Herring's request, renamed devicetree property: at24,no-read-rollover -> no-read-rollover v4: renamed devicetree property: no-read-rollover -> at24,no-read-rollover dt-bindings update now a separate patch v3: rebased against at24 maintainer's devel staging branch: git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git at24/devel clarified some of the comments and wording v2: kbuild test robot feedback: correct "warning: comparison of distinct pointer types lacks a cast" build warning on some compilers / architectures. v1: original patch Sven Van Asbroeck (2): at24: support eeproms that do not auto-rollover reads. dt-bindings: add eeprom "at24,no-read-rollover" property .../devicetree/bindings/eeprom/eeprom.txt | 5 +++ drivers/misc/eeprom/at24.c | 37 +++--- include/linux/platform_data/at24.h | 2 ++ 3 files changed, 32 insertions(+), 12 deletions(-) -- 1.9.1
[PATCH v5 2/2] dt-bindings: add eeprom "no-read-rollover" property
Adds an optional property for at24 eeproms.
This parameterless property indicates that the multi-address eeprom
does not automatically roll over reads to the next slave address.
Signed-off-by: Sven Van Asbroeck
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 27f2bc1..5bfc0ac 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -38,6 +38,11 @@ Optional properties:
- size: total eeprom size in bytes
+ - no-read-rollover:
+ This parameterless property indicates that the
multi-address
+ eeprom does not automatically roll over reads to the
next
+ slave address. Please consult the manual of your device.
+
Example:
eeprom@52 {
--
1.9.1
[PATCH v5 1/2] at24: support eeproms that do not auto-rollover reads.
Some multi-address eeproms in the at24 family may not automatically
roll-over reads to the next slave address. On those eeproms, reads
that straddle slave boundaries will not work correctly.
Solution:
Mark such eeproms with a flag that prevents reads straddling
slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom
entry in the device_id table, or add 'no-read-rollover' to the
eeprom devicetree entry.
Note that I have not personally enountered an at24 chip that
does not support read rollovers. They may or may not exist.
However, my hardware requires this functionality because of
a quirk.
It's up to the Linux community to decide if this patch is useful/
general enough to warrant merging.
Signed-off-by: Sven Van Asbroeck
---
drivers/misc/eeprom/at24.c | 37 +
include/linux/platform_data/at24.h | 2 ++
2 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 625b001..8c93ed0 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -251,15 +251,6 @@ struct at24_data {
* Slave address and byte offset derive from the offset. Always
* set the byte address; on a multi-master board, another master
* may have changed the chip's "current" address pointer.
- *
- * REVISIT some multi-address chips don't rollover page reads to
- * the next slave address, so we may need to truncate the count.
- * Those chips might need another quirk flag.
- *
- * If the real hardware used four adjacent 24c02 chips and that
- * were misconfigured as one 24c08, that would be a similar effect:
- * one "eeprom" file not four, but larger reads would fail when
- * they crossed certain pages.
*/
static struct at24_client *at24_translate_offset(struct at24_data *at24,
unsigned int *offset)
@@ -277,6 +268,28 @@ static struct at24_client *at24_translate_offset(struct
at24_data *at24,
return &at24->client[i];
}
+static size_t at24_adjust_read_count(struct at24_data *at24,
+ unsigned int offset, size_t count)
+{
+ unsigned int bits;
+ size_t remainder;
+ /*
+* In case of multi-address chips that don't rollover reads to
+* the next slave address: truncate the count to the slave boundary,
+* so that the read never straddles slaves.
+*/
+ if (at24->chip.flags & AT24_FLAG_NO_RDROL) {
+ bits = (at24->chip.flags & AT24_FLAG_ADDR16) ? 16 : 8;
+ remainder = BIT(bits) - offset;
+ if (count > remainder)
+ count = remainder;
+ }
+ if (count > io_limit)
+ count = io_limit;
+
+ return count;
+}
+
static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
unsigned int offset, size_t count)
{
@@ -289,9 +302,7 @@ static ssize_t at24_regmap_read(struct at24_data *at24,
char *buf,
at24_client = at24_translate_offset(at24, &offset);
regmap = at24_client->regmap;
client = at24_client->client;
-
- if (count > io_limit)
- count = io_limit;
+ count = at24_adjust_read_count(at24, offset, count);
/* adjust offset for mac and serial read ops */
offset += at24->offset_adj;
@@ -457,6 +468,8 @@ static void at24_get_pdata(struct device *dev, struct
at24_platform_data *chip)
if (device_property_present(dev, "read-only"))
chip->flags |= AT24_FLAG_READONLY;
+ if (device_property_present(dev, "no-read-rollover"))
+ chip->flags |= AT24_FLAG_NO_RDROL;
err = device_property_read_u32(dev, "size", &val);
if (!err)
diff --git a/include/linux/platform_data/at24.h
b/include/linux/platform_data/at24.h
index 271a4e2..841bb28 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -50,6 +50,8 @@ struct at24_platform_data {
#define AT24_FLAG_TAKE8ADDRBIT(4) /* take always 8 addresses (24c00) */
#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
+#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
+ /* the next slave address */
void(*setup)(struct nvmem_device *nvmem, void *context);
void*context;
--
1.9.1
Re: [PATCH 1/2] i2c: add ACPI support for i2c-piix4
Hi Andrew,
On Thu, 23 Nov 2017 13:09:37 +1000, Andrew Cooks wrote:
> This enables the i2c-piix4 SMBus controller driver to enumerate I2C
> slave devices using ACPI. It builds on the related I2C mux device work
> in commit 8eb5c87a92c0 ("i2c: add ACPI support for I2C mux ports")
>
> Signed-off-by: Andrew Cooks
> ---
> drivers/i2c/busses/i2c-piix4.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
> index 174579d..9260cfa 100644
> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -837,6 +837,12 @@ static int piix4_add_adapter(struct pci_dev *dev,
> unsigned short smba,
> /* set up the sysfs linkage to our parent device */
> adap->dev.parent = &dev->dev;
>
> + if (has_acpi_companion(&dev->dev)) {
> + acpi_preset_companion(&adap->dev,
> + ACPI_COMPANION(&dev->dev),
> + port);
> + }
> +
> snprintf(adap->name, sizeof(adap->name),
> "SMBus PIIX4 adapter%s at %04x", name, smba);
>
Looks good to me but I think you have the patches in the wrong order.
First we must get the port number right, and then you can instantiate
the devices from the ACPI data. If you do it the other way around then
you have a transient situation where you instantiate a device where it
does not exist.
--
Jean Delvare
SUSE L3 Support
Re: [PATCH 1/6] staging: pi433: Split rf69_set_crc_enabled into two functions
On Wed, Dec 06, 2017 at 09:42:19PM +0100, Simon Sandström wrote: > Splits rf69_set_crc_enabled(dev, enabled) into > rf69_enable_crc(dev) and rf69_disable_crc(dev). > > Signed-off-by: Simon Sandström > --- > drivers/staging/pi433/pi433_if.c | 22 -- > drivers/staging/pi433/rf69.c | 18 ++ > drivers/staging/pi433/rf69.h | 4 ++-- > 3 files changed, 28 insertions(+), 16 deletions(-) This series did not apply at all. What tree and branch did you make it against? Please redo it against my staging.git tree, the staging-next branch should be fine, or the staging-testing will work as well. thanks, greg k-h
[PATCH net-next v4 1/4] phylib: Add device reset delay support
From: Richard Leitner
Some PHYs need a minimum time after the reset gpio was asserted and/or
deasserted. To ensure we meet these timing requirements add two new
optional devicetree parameters for the phy: reset-delay-us and
reset-post-delay-us.
Signed-off-by: Richard Leitner
Reviewed-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/net/phy.txt | 10 ++
drivers/net/phy/mdio_device.c | 13 +++--
drivers/of/of_mdio.c | 4
include/linux/mdio.h | 2 ++
4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt
b/Documentation/devicetree/bindings/net/phy.txt
index c05479f5ac7c..72860ce7f610 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -55,6 +55,12 @@ Optional Properties:
- reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
+- reset-delay-us: Delay after the reset was asserted in microseconds.
+ If this property is missing the delay will be skipped.
+
+- reset-post-delay-us: Delay after the reset was deasserted in microseconds.
+ If this property is missing the delay will be skipped.
+
Example:
ethernet-phy@0 {
@@ -62,4 +68,8 @@ ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <35 IRQ_TYPE_EDGE_RISING>;
reg = <0>;
+
+ reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <1000>;
+ reset-post-delay-us = <2000>;
};
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index 75d97dd9fb28..0423280c88fe 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
void mdio_device_free(struct mdio_device *mdiodev)
{
@@ -118,8 +119,16 @@ EXPORT_SYMBOL(mdio_device_remove);
void mdio_device_reset(struct mdio_device *mdiodev, int value)
{
- if (mdiodev->reset)
- gpiod_set_value(mdiodev->reset, value);
+ unsigned int d;
+
+ if (!mdiodev->reset)
+ return;
+
+ gpiod_set_value(mdiodev->reset, value);
+
+ d = value ? mdiodev->reset_delay : mdiodev->reset_post_delay;
+ if (d)
+ usleep_range(d, d + min_t(unsigned int, d / 10, 100));
}
EXPORT_SYMBOL(mdio_device_reset);
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 98258583abb0..7c8767176315 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -77,6 +77,10 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
if (of_property_read_bool(child, "broken-turn-around"))
mdio->phy_ignore_ta_mask |= 1 << addr;
+ of_property_read_u32(child, "reset-delay-us", &phy->mdio.reset_delay);
+ of_property_read_u32(child, "reset-post-delay-us",
+&phy->mdio.reset_post_delay);
+
/* Associate the OF node with the device structure so it
* can be looked up later */
of_node_get(child);
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index 92d4e55ffe67..e37c21d8eb19 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -41,6 +41,8 @@ struct mdio_device {
int addr;
int flags;
struct gpio_desc *reset;
+ unsigned int reset_delay;
+ unsigned int reset_post_delay;
};
#define to_mdio_device(d) container_of(d, struct mdio_device, dev)
--
2.11.0
Re: [PATCH] watchdog: core: make sure the watchdog_worker always works
On 12/07/2017 02:38 AM, Christophe Leroy wrote:
When running a command like 'chrt -f 99 dd if=/dev/zero of=/dev/null',
the watchdog_worker fails to service the HW watchdog and the
HW watchdog fires long before the watchdog soft timeout.
At the moment, the watchdog_worker is invoked as a delayed work.
Delayed works are handled by non realtime kernel threads. The
WQ_HIGHPRI flag only increases the niceness of that threads.
This patchs replaces the delayed work logic by hrtimer, in order to
s/patchs/patch/
ensure that the watchdog_worker will already have priority.
always ?
Signed-off-by: Christophe Leroy
---
drivers/watchdog/watchdog_dev.c | 87 +++--
1 file changed, 41 insertions(+), 46 deletions(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 1e971a50d7fb..e9b234c4ff67 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -36,7 +36,7 @@
#include /* For the -ENODEV/... values */
#include/* For file operations */
#include /* For __init/__exit/... */
-#include/* For timeout functions */
+#include
#include/* For printk/panic/... */
#include /* For data references */
#include/* For handling misc devices */
@@ -46,7 +46,6 @@
#include /* For memory functions */
#include /* For standard types (like size_t) */
#include /* For watchdog specific items */
-#include /* For workqueue */
#include /* For copy_to_user/put_user/... */
#include "watchdog_core.h"
@@ -65,9 +64,9 @@ struct watchdog_core_data {
struct cdev cdev;
struct watchdog_device *wdd;
struct mutex lock;
- unsigned long last_keepalive;
- unsigned long last_hw_keepalive;
- struct delayed_work work;
+ ktime_t last_keepalive;
+ ktime_t last_hw_keepalive;
+ struct hrtimer timer;
unsigned long status; /* Internal status bits */
#define _WDOG_DEV_OPEN0 /* Opened ? */
#define _WDOG_ALLOW_RELEASE 1 /* Did we receive the magic char ? */
@@ -79,8 +78,6 @@ static dev_t watchdog_devt;
/* Reference to watchdog device behind /dev/watchdog */
static struct watchdog_core_data *old_wd_data;
-static struct workqueue_struct *watchdog_wq;
-
static bool handle_boot_enabled =
IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
@@ -107,18 +104,19 @@ static inline bool watchdog_need_worker(struct watchdog_device *wdd)
(t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
}
-static long watchdog_next_keepalive(struct watchdog_device *wdd)
+static ktime_t watchdog_next_keepalive(struct watchdog_device *wdd)
{
struct watchdog_core_data *wd_data = wdd->wd_data;
unsigned int timeout_ms = wdd->timeout * 1000;
- unsigned long keepalive_interval;
- unsigned long last_heartbeat;
- unsigned long virt_timeout;
+ ktime_t keepalive_interval;
+ ktime_t last_heartbeat, latest_heartbeat;
+ ktime_t virt_timeout;
unsigned int hw_heartbeat_ms;
- virt_timeout = wd_data->last_keepalive + msecs_to_jiffies(timeout_ms);
+ virt_timeout = ktime_add(wd_data->last_keepalive,
+ms_to_ktime(timeout_ms));
hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms);
- keepalive_interval = msecs_to_jiffies(hw_heartbeat_ms / 2);
+ keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2);
if (!watchdog_active(wdd))
return keepalive_interval;
@@ -128,8 +126,11 @@ static long watchdog_next_keepalive(struct watchdog_device
*wdd)
* after the most recent ping from userspace, the last
* worker ping has to come in hw_heartbeat_ms before this timeout.
*/
- last_heartbeat = virt_timeout - msecs_to_jiffies(hw_heartbeat_ms);
- return min_t(long, last_heartbeat - jiffies, keepalive_interval);
+ last_heartbeat = ktime_sub(virt_timeout, ms_to_ktime(hw_heartbeat_ms));
+ latest_heartbeat = ktime_sub(last_heartbeat, ktime_get());
+ if (ktime_before(latest_heartbeat, keepalive_interval))
+ return latest_heartbeat;
+ return keepalive_interval;
}
static inline void watchdog_update_worker(struct watchdog_device *wdd)
@@ -137,29 +138,33 @@ static inline void watchdog_update_worker(struct
watchdog_device *wdd)
struct watchdog_core_data *wd_data = wdd->wd_data;
if (watchdog_need_worker(wdd)) {
- long t = watchdog_next_keepalive(wdd);
+ ktime_t t = watchdog_next_keepalive(wdd);
if (t > 0)
- mod_delayed_work(watchdog_wq, &wd_data->work, t);
+ hrtimer_start(&wd_data->timer, t, HRTIMER_MODE_REL);
} else {
- cancel_delayed_work(&wd_data->work);
+ hrtimer_cancel(&wd_data->timer);
Re: [PATCH v3] serial: 8250: convert to threaded IRQ
On Mon, 4 Dec 2017 17:26:27 +0200 Denys Zagorui wrote: > During using virtualization it is common to see > many "too much work for irq*" messages. Your emulator is buggy. NAK You are adding a ton of overhead to an absolutely performance critical path on real hardware. We absolutely cannot have 16450 or 16550A UARTS being serviced via a threaded IRQ. Fix your emulator. You are getting the problem because your serial port emulation isn't doing timing correct queueing of characters. If you are modelling 115,200 baud then don't queue characters faster than that or batch them excessively. We went to 512 as the pass limit to allow virtualization layers to get this right more easily as you don't have to do timing on tiny batches. (And if you need performance of any kind stop using the uart emulation and use virtio) Alan
Re: [PATCH v2] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
On Wed, Dec 6, 2017 at 11:04 PM, Tony Lindgren wrote:
> * Arnd Bergmann [171206 21:52]:
>> In configurations without CONFIG_OMAP3 but with secure RAM support,
>> we now run into a link failure:
>>
>> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
>> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
>>
>> The omap3_save_secure_ram() function is only called from the OMAP34xx
>> power management code, so we can simply hide that function in the
>> appropriate #ifdef.
>>
>> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for
>> save_secure_ram_context")
>> Signed-off-by: Arnd Bergmann
>> ---
>> v2: also check for CONFIG_PM
>
> Acked-by: Tony Lindgren
Applied now
Arnd
Re: [PATCH V6 4/7] OF: properties: Implement get_match_data() callback
On 12/7/2017 8:10 AM, Lothar Waßmann wrote: >> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode, >> + struct device *dev) > Shouldn't this be 'const void *of_fwnode_get_match_data OF keeps the driver data as a (const void*) internally. ACPI keeps the driver data as kernel_ulong_t in struct acpi_device_id. I tried to find the middle ground here by converting output to void* but not keeping const. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support
On Wed, Dec 06, 2017 at 01:55:37AM +, Chen, Kenji wrote: > https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf With all due respect, this doesn't seem to add any new information. For example, the L1 PM Substates Control 1 register description from the above is basically identical to the published PCIe r3.1, sec 7.33.3. So it doesn't answer the questions of: 1) Why coreboot sets the L1.2 threshold to a fixed value, and 2) How "(1 << 21) | (1 << 23) | (1 << 30)" relates to the Control 1 register > Pls also check My Intel Doc# 545845 for the bits fields description. I don't have access to this document. The Linux code I'm proposing is based on the PCIe spec and is intended to work on all hardware that conforms to that spec. I'm not very familiar with coreboot, but maybe the L1 Substates code there is only intended to work on certain Intel chipsets and doesn't need to work on other hardware? Bjorn > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Wednesday, December 6, 2017 3:41 AM > To: linux-...@vger.kernel.org > Cc: Chen, Kenji ; Thierry Reding ; > Manikanta Maddireddy ; David Daney > ; Krishna Kishore ; > linux-kernel@vger.kernel.org; Vidya Sagar ; Julia Lawall > ; linux-te...@vger.kernel.org; Patrick Georgi > ; Rajat Jain ; Yinghai Lu > ; Stefan Reinauer ; Duncan > Laurie > Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support > > On Sat, Dec 02, 2017 at 03:45:38PM -0600, Bjorn Helgaas wrote: > > The PCIe active link power state is L0. ASPM defines two low-power > > states: L0s and L1. The L1 PM Substates feature defines two > > additional low-power states: L1.1 and L2.2. > > > > The L1.2 state may have substantial entry/exit latency. Downstream > > devices can use the Latency Tolerance Reporting (LTR) feature to > > report how much latency they can tolerate. The L1 PM Substates > > capability includes a programmable L1.2 threshold register. If the > > downstream devices can tolerate the latency indicated by the > > threshold, L1.2 may be used. > > > > If LTR is not enabled, the L1.2 threshold is ignored and L1.2 can be > > used whenever it is enabled and CLKREQ# is de-asserted. Linux > > currently never enables LTR, but firmware may have done so. > > > > The current L1 PM substates support in Linux sets the L1.2 threshold > > to a fixed value (163.84us) copied from coreboot [1]. I don't know > > where that value came from, and it is incorrect for some platforms, > > e.g., Tegra [2]. > > > > These patches change that so we calculate the L1.2 threshold based on > > values reported by the hardware, and we enable LTR whenever possible. > > > > This is all just my understanding from reading the spec. I'd be glad > > to be corrected if I'm going wrong. > > > > I'm particularly puzzled about the coreboot code in > > pciexp_L1_substate_commit() that sets LTR_L1.2_THRESHOLD: > > > > + pcie_update_cfg(root, root_cap + 0x08, ~0xe3ff, > > + (1 << 21) | (1 << 23) | (1 << 30)); > > > > This is writing the L1 PM Substates Control 1 register, but the shifts > > don't match up with any of the fields in the register, so this is an > > awfully funny way to write the threshold. > > > > [1] > > https://mail.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134. > > html [2] > > https://lkml.kernel.org/r/1510492674-12786-1-git-send-email-vidyas@nvi > > dia.com > > > > --- > > > > Bjorn Helgaas (2): > > PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device characteristics > > PCI/ASPM: Enable Latency Tolerance Reporting when supported > > > > > > drivers/pci/pcie/aspm.c | 71 > > +++ > > drivers/pci/probe.c | 33 ++ > > include/linux/pci.h |2 + > > 3 files changed, 82 insertions(+), 24 deletions(-) > > I applied these with Vidya's Reviewed-by to pci/aspm for v4.16. > > I'd still really like to hear from the coreboot folks about the rationale for > the current coreboot code. You folks are in a much better position to > actually understand the hardware details. > > Bjorn
[PATCH net-next v4 2/4] phylib: add reset after clk enable support
From: Richard Leitner
Some PHYs need the refclk to be a continuous clock. Therefore they don't
allow turning it off and on again during operation. Nonetheless such a
clock switching is performed by some ETH drivers (namely FEC [1]) for
power saving reasons. An example for an affected PHY is the
SMSC/Microchip LAN8720 in "REF_CLK In Mode".
In order to provide a uniform method to overcome this problem this patch
adds a new phy_driver flag (PHY_RST_AFTER_CLK_EN) and corresponding
function phy_reset_after_clk_enable() to the phylib. These should be
used to trigger reset of the PHY after the refclk is switched on again.
[1] commit e8fcfcd5684a ("net: fec: optimize the clock management to save
power")
Signed-off-by: Richard Leitner
Reviewed-by: Andrew Lunn
---
drivers/net/phy/phy_device.c | 24
include/linux/phy.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1de5e242b8b4..462c17ed87b8 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1218,6 +1218,30 @@ int phy_loopback(struct phy_device *phydev, bool enable)
}
EXPORT_SYMBOL(phy_loopback);
+/**
+ * phy_reset_after_clk_enable - perform a PHY reset if needed
+ * @phydev: target phy_device struct
+ *
+ * Description: Some PHYs are known to need a reset after their refclk was
+ * enabled. This function evaluates the flags and perform the reset if it's
+ * needed. Returns < 0 on error, 0 if the phy wasn't reset and 1 if the phy
+ * was reset.
+ */
+int phy_reset_after_clk_enable(struct phy_device *phydev)
+{
+ if (!phydev || !phydev->drv)
+ return -ENODEV;
+
+ if (phydev->drv->flags & PHY_RST_AFTER_CLK_EN) {
+ phy_device_reset(phydev, 1);
+ phy_device_reset(phydev, 0);
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(phy_reset_after_clk_enable);
+
/* Generic PHY support and helper functions */
/**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index d3037e2ffbc4..c4b4715caa21 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -59,6 +59,7 @@
#define PHY_HAS_INTERRUPT 0x0001
#define PHY_IS_INTERNAL0x0002
+#define PHY_RST_AFTER_CLK_EN 0x0004
#define MDIO_DEVICE_IS_PHY 0x8000
/* Interface Mode definitions */
@@ -853,6 +854,7 @@ int phy_aneg_done(struct phy_device *phydev);
int phy_stop_interrupts(struct phy_device *phydev);
int phy_restart_aneg(struct phy_device *phydev);
+int phy_reset_after_clk_enable(struct phy_device *phydev);
static inline void phy_device_reset(struct phy_device *phydev, int value)
{
--
2.11.0
[PATCH net-next v4 4/4] net: fec: add phy_reset_after_clk_enable() support
From: Richard Leitner
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock management
to save power").
Therefore add support for the phy_reset_after_clk_enable function from
phylib to mitigate this issue.
Generally speaking this issue is only relevant if the ref clk for the
PHY is generated by the SoC and therefore the PHY is configured to
"REF_CLK In Mode". In our specific case (PCB) this problem does occur at
about every 10th to 50th POR of an LAN8710 connected to an i.MX6SOLO
SoC. The typical symptom of this problem is a "swinging" ethernet link.
Similar issues were reported by users of the NXP forum:
https://community.nxp.com/thread/389902
https://community.nxp.com/message/309354
With this patch applied the issue didn't occur for at least a few
hundret PORs of our board.
Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power")
Signed-off-by: Richard Leitner
---
drivers/net/ethernet/freescale/fec_main.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 610573855213..2d1b06579c1a 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1862,6 +1862,8 @@ static int fec_enet_clk_enable(struct net_device *ndev,
bool enable)
ret = clk_prepare_enable(fep->clk_ref);
if (ret)
goto failed_clk_ref;
+
+ phy_reset_after_clk_enable(ndev->phydev);
} else {
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_enet_out);
@@ -2834,6 +2836,7 @@ fec_enet_open(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
int ret;
+ bool reset_again;
ret = pm_runtime_get_sync(&fep->pdev->dev);
if (ret < 0)
@@ -2844,6 +2847,17 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto clk_enable;
+ /* During the first fec_enet_open call the PHY isn't probed at this
+* point. Therefore the phy_reset_after_clk_enable() call within
+* fec_enet_clk_enable() fails. As we need this reset in order to be
+* sure the PHY is working correctly we check if we need to reset again
+* later when the PHY is probed
+*/
+ if (ndev->phydev && ndev->phydev->drv)
+ reset_again = false;
+ else
+ reset_again = true;
+
/* I should reset the ring buffers here, but I don't yet know
* a simple way to do that.
*/
@@ -2860,6 +2874,12 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto err_enet_mii_probe;
+ /* Call phy_reset_after_clk_enable() again if it failed during
+* phy_reset_after_clk_enable() before because the PHY wasn't probed.
+*/
+ if (reset_again)
+ phy_reset_after_clk_enable(ndev->phydev);
+
if (fep->quirks & FEC_QUIRK_ERR006687)
imx6q_cpuidle_fec_irqs_used();
--
2.11.0
[PATCH net-next v4 0/4] net: fec: fix refclk enable for SMSC LAN8710/20
From: Richard Leitner
This patch series fixes the use of the SMSC LAN8710/20 with a Freescale ETH
when the refclk is generated by the FSL.
This patchset depends on the "phylib: Add device reset GPIO support" patch
submitted by Geert Uytterhoeven/Sergei Shtylyov, which was merged to
net-next as commit bafbdd527d56 ("phylib: Add device reset GPIO support").
Changes v4:
- simplify dts parsing
- simplify reset delay evaluation and execution
- fec: ensure to only reset once during fec_enet_open()
- remove dependency notes from commit message
- add reviews and acks
Changes v3:
- use phylib to hard-reset the PHY
- implement reset delays in phylib
- add new phylib API & flag (PHY_RST_AFTER_CLK_EN) to determine if
a PHY is affected
Changes v2:
- simplify and fix fec_reset_phy function to support multiple calls
- include: linux: phy: harmonize phy_id{,_mask} type
- reset the phy instead of not turning the clock on and off
(which would have caused a power consumption regression)
Richard Leitner (4):
phylib: Add device reset delay support
phylib: add reset after clk enable support
net: phy: smsc: LAN8710/20: add PHY_RST_AFTER_CLK_EN flag
net: fec: add phy_reset_after_clk_enable() support
Documentation/devicetree/bindings/net/phy.txt | 10 ++
drivers/net/ethernet/freescale/fec_main.c | 20
drivers/net/phy/mdio_device.c | 13 +++--
drivers/net/phy/phy_device.c | 24
drivers/net/phy/smsc.c| 2 +-
drivers/of/of_mdio.c | 4
include/linux/mdio.h | 2 ++
include/linux/phy.h | 2 ++
8 files changed, 74 insertions(+), 3 deletions(-)
--
2.11.0
[PATCH net-next v4 3/4] net: phy: smsc: LAN8710/20: add PHY_RST_AFTER_CLK_EN flag
From: Richard Leitner
The Microchip/SMSC LAN8710/LAN8720 PHYs need (according to their
datasheet [1]) a continuous REF_CLK when configured to "REF_CLK In Mode".
Therefore set the PHY_RST_AFTER_CLK_EN flag for those PHYs to let the
ETH driver reset them after the REF_CLK is enabled.
[1] http://ww1.microchip.com/downloads/en/DeviceDoc/2165B.pdf
Signed-off-by: Richard Leitner
Reviewed-by: Andrew Lunn
---
drivers/net/phy/smsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index a1961ba87e2b..be399d645224 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -312,7 +312,7 @@ static struct phy_driver smsc_phy_driver[] = {
.name = "SMSC LAN8710/LAN8720",
.features = PHY_BASIC_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
+ .flags = PHY_HAS_INTERRUPT | PHY_RST_AFTER_CLK_EN,
.probe = smsc_phy_probe,
--
2.11.0
[PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation
Create Documentation portion of UIO driver with Generic Interrupt Handler.
This patch creates a dt-binding documentation portion of the UIO Driver.
In addition to definition of standard required properties, new optional
property defined:
- no-threaded-irq: when present, request_irq() is called with
IRQF_NO_THREAD flag set, effectively skipping threaded interrupt
handler and taking bottom-half into irq_handler
Signed-off-by: Andrey Zhizhikin
diff --git a/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
b/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
new file mode 100644
index 000..dfcc362
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt
@@ -0,0 +1,46 @@
+* Userspace I/O platform driver with generic IRQ handling code.
+
+Platform driver for User-space IO handling with generic IRQ code.
+This driver is very similar to the regular UIO platform driver, but is
+only suitable for devices that are connected to the interrupt
+controller using unique interrupt lines.
+
+Required properties:
+- compatible: Driver compatible string. For UIO device with generic IRQ
+ handling code this property is defined in device tree to any desired
+ name, and then set via module parameters passed to Kernel command line
+ in a form:
+ uio_pdrv_genirq.of_id=
+
+- reg: Physical base address and size for memory mapped region to be accessed
+ via UIO driver.
+
+- interrupts: Platform IRQ standard definition. For details on defining this
+ property, see interrupt-controller/interrupts.txt
+
+- interrupt-parent: Parent interrupt controller node.
+ For details, see interrupt-controller/interrupts.txt
+
+Optional properties:
+- no-threaded-irq: when present, request_irq() is called with IRQF_NO_THREAD
+ flag set, effectively skipping threaded interrupt handler and taking
+ bottom-half into irq_handler
+
+
+Examples:
+
+base-uio {
+ compatible = "platform-uio";
+ reg = < 0xC000 0x0002 >;
+ interrupts = < 0 10 1 >;
+ interrupt-parent = <&intc>;
+};
+
+nothreaded-uio {
+ compatible = "platform-uio";
+ reg = < 0xC004 0x0002 >;
+ interrupts = < 0 27 1 >;
+ interrupt-parent = <&intc>;
+ no-threaded-irq;
+};
+
--
2.7.4
[PATCH v2 0/2] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding
This patch series aimed to introduce additional feature for UIO driver with generic interrupt handler to allow IRQ bottom half to be executed in irq_handler context rather than as threaded IRQ. Andrey Zhizhikin (2): uio: Allow to take irq bottom-half into irq_handler with additional dt-binding uio: Introduce UIO driver dt-binding documentation .../devicetree/bindings/uio/uio-pdrv-genirq.txt| 46 ++ drivers/uio/uio_pdrv_genirq.c | 15 +++ 2 files changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/uio/uio-pdrv-genirq.txt -- 2.7.4
[PATCH v2 1/2] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding
Certain Kernel preemption models are using threaded interrupt handlers,
which is in general quite beneficial. However, threaded handlers
introducing additional scheduler overhead, when the bottom-half thread
should be woken up and scheduled for execution. This can result is
additional latency, which in certain cases is not desired.
UIO driver with Generic IRQ handler, that wraps a HW block might suffer
a small degradation when it's bottom half is executed, since it needs
its bottom half to be woken up by the scheduler every time INT is
delivered. For high rate INT signals, this also bring additional
undesired load on the scheduler itself.
Since the actual ACK is performed in the top-half, and bottom-half of
the UIO driver with Generic IRQ handler is relatively slick (only flag
is set based on the INT reception), it might be beneficial to move this
bottom-half to the irq_handler itself, rather than to have a separate
thread to service it.
This patch aims to address the task above by supplying IRQF_NO_THREAD to
request_irq(), based on dt-binding which could be configured on a per-node
basis. That means developers utilizing the UIO driver could decide which
UIO instance is critical in terms of interrupt processing, and move their
corresponding bottom-halves to the irq_handler to fight additional
scheduling latency. When additional property is not found in corresponding
dt-node, then instance behavior is not amended and overall system stays
with default configuration for threaded IRQ (depending on how they are
configured by Preemption model).
Patch was originated on the ARM-based system with Kernel configuration
CONFIG_PREEMPT_RT_FULL set, which effectively promotes all bottom-halves
to threaded interrupt handlers. Once this patch has been enabled on 2
individual uio device nodes (out of around 20 registered in the system),
no additional negative impact has been noted on the system overall.
Having this patch enabled for individual UIO node allowed to have a
latency reduction of around 20-30 usec from INT trigger to the user space
IRQ handler. Those results can vary based on the platform and CPU
architecture, but could be quite beneficial if above gain in comparable
to the worst-case latency figures.
This modification also brings several additional benefits:
- It eliminates few re-scheduling operations, making INT ACK code more
robust and relieves the pressure from the scheduler when HW interrupt
for this IRQ is signaled at a high-enough frequency;
- It makes top and bottom half to be executed back-to-back with IRQ
OFF, making operation pseudo-atomic;
- Above gain might be significant when average latency times for the
systems are comparable
Signed-off-by: Andrey Zhizhikin
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index f598ecd..86427a4 100644
--- a/drivers/uio/uio_pdrv_genirq.c
+++ b/drivers/uio/uio_pdrv_genirq.c
@@ -108,6 +108,7 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
struct uio_pdrv_genirq_platdata *priv;
struct uio_mem *uiomem;
int ret = -EINVAL;
+ int no_threaded_irq = 0;
int i;
if (pdev->dev.of_node) {
@@ -121,6 +122,14 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
uioinfo->name = pdev->dev.of_node->name;
uioinfo->version = "devicetree";
/* Multiple IRQs are not supported */
+
+ /* read additional property (if exists) and decide whether
+* to have IRQ bottom half to be executed in a separate
+* thread, or to have it executed in the irq_handler
+* context
+*/
+ if (of_property_read_bool(pdev->dev.of_node, "no-threaded-irq"))
+ no_threaded_irq = 1;
}
if (!uioinfo || !uioinfo->name || !uioinfo->version) {
@@ -134,6 +143,12 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
return ret;
}
+ /* execute BH in irq_handler if property set in FDT */
+ if ((no_threaded_irq > 0) && !(uioinfo->irq_flags & IRQF_NO_THREAD)) {
+ dev_info(&pdev->dev, "promoting INT with IRQF_NO_THREAD\n");
+ uioinfo->irq_flags |= IRQF_NO_THREAD;
+ }
+
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(&pdev->dev, "unable to kmalloc\n");
--
2.7.4
Re: [PATCH] kconfig: Warn if choice default is not in choice
2017-10-04 8:25 GMT+09:00 Ulf Magnusson : > This will catch mistakes like in the following real-world example, where > a "CONFIG_" prefix snuck in, making an undefined symbol the default: > > choice > prompt "Compiler optimization level" > default CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE > > config CC_OPTIMIZE_FOR_PERFORMANCE > ... > > config CC_OPTIMIZE_FOR_SIZE > ... > > endchoice > > This now prints the following warning: > > init/Kconfig:1036:warning: choice default symbol > 'CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE' is not contained in the choice > > Cases where the default symbol belongs to the wrong choice are also > detected. > > (The mistake is harmless here: Since the default symbol is not visible, > the choice falls back on using the first visible symbol as the default, > which is CC_OPTIMIZE_FOR_PERFORMANCE, as intended.) > > Discovered while playing around with Kconfiglib > (https://github.com/ulfalizer/Kconfiglib). > > Signed-off-by: Ulf Magnusson > --- Applied to linux-kbuild/kconfig. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH] ACPI / GED: unregister interrupts during shutdown
Rafael, On 12/7/2017 8:00 AM, Rafael J. Wysocki wrote: >> Just don't use devm_request_threaded_irq()? :) >> >> Seriously, those are just "helper" functions if your code happens to >> follow the pattern they provide, if not, then don't use them, it's not >> that hard to provide the correct code to unwind things properly by "open >> coding" this logic as needed. >> >> The devm_*irq() functions are known for not being able to be used all of >> the time for lots of shutdown and cleanup issues, this isn't the first >> time it has happened, which is why we are very careful when taking >> "cleanup" patches that use those functions. > I see, thanks for the clarification. > > OK, we'll need to rework the driver somewhat, then. Even if we got rid of devm_*irq() functions, I see that the free_irq() function requires dev_id argument. * There can be multiple actions per IRQ descriptor, find the right * one based on the dev_id: I still need to keep track of the dev_ids attached to request_irq() functions. My take away from the discussion is: 1. don't use devm family of functions for IRQ registration/free 2. still keep track of the events 3. call free_irq on shutdown. Do you have something else on your mind? Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH net-next v4 1/4] phylib: Add device reset delay support
Hi Richard,
On Thu, Dec 7, 2017 at 3:43 PM, Richard Leitner wrote:
> --- a/drivers/net/phy/mdio_device.c
> +++ b/drivers/net/phy/mdio_device.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> void mdio_device_free(struct mdio_device *mdiodev)
> {
> @@ -118,8 +119,16 @@ EXPORT_SYMBOL(mdio_device_remove);
>
> void mdio_device_reset(struct mdio_device *mdiodev, int value)
> {
> - if (mdiodev->reset)
> - gpiod_set_value(mdiodev->reset, value);
> + unsigned int d;
> +
> + if (!mdiodev->reset)
> + return;
> +
> + gpiod_set_value(mdiodev->reset, value);
> +
> + d = value ? mdiodev->reset_delay : mdiodev->reset_post_delay;
> + if (d)
> + usleep_range(d, d + min_t(unsigned int, d / 10, 100));
Oops, I meant "max_t", not "min_t", else the upper limit can be "d + 0",
which is not what we want.
Sorry, my fault.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 1/6] ARM: davinci: clean up map_io functions
On Saturday 02 December 2017 08:04 AM, David Lechner wrote:
> This cleans up the map_io functions in the board init files for
> mach-davinci.
>
> Most of the boards had a wrapper function around _init(). This
> wrapper is removed and the function is used directly. Additionally, the
> _init() functions are renamed to _map_io() to match the
> field name.
>
> Signed-off-by: David Lechner
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
> b/arch/arm/mach-davinci/board-dm646x-evm.c
> index cb0a41e..f0e2762 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -716,16 +716,6 @@ static void __init evm_init_i2c(void)
> }
> #endif
>
> -#define DM6467T_EVM_REF_FREQ 3300
> -
> -static void __init davinci_map_io(void)
> -{
> - dm646x_init();
The call to dm646x_init() is dropped here, but I don't see it added
back, at least in this patch.
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index da21353..b3be5c8 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -17,6 +17,7 @@
> #include
> #include
>
> +#include
> #include
>
> #include
> @@ -952,11 +953,16 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv)
> return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
> }
>
> -void __init dm646x_init(void)
> +#define DM6467T_EVM_REF_FREQ 3300
> +
> +void __init dm646x_map_io(void)
> {
> davinci_common_init(&davinci_soc_info_dm646x);
> davinci_map_sysmod();
> davinci_clk_init(davinci_soc_info_dm646x.cpu_clks);
> +
> + if (machine_is_davinci_dm6467tevm())
> + davinci_set_refclk_rate(DM6467T_EVM_REF_FREQ);
> }
I think we should leave the DM646x case out of this since there are
additional issues like introducing these EVM specific defines in a file
meant for SoC.
Is this clean-up a must for you to implement rest of the series (haven't
looked at other patches yet).
Thanks,
Sekhar
Re: [PATCH] media: s5p-jpeg: Fix off-by-one problem
W dniu 06.12.2017 o 17:37, Flavio Ceolin pisze:
s5p_jpeg_runtime_resume() does not call clk_disable_unprepare() for
jpeg->clocks[0] when one of the clk_prepare_enable() fails.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Flavio Ceolin
Acked-by: Andrzej Pietrasiewicz
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index faac816..79b63da 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -3086,7 +3086,7 @@ static int s5p_jpeg_runtime_resume(struct device *dev)
for (i = 0; i < jpeg->variant->num_clocks; i++) {
ret = clk_prepare_enable(jpeg->clocks[i]);
if (ret) {
- while (--i > 0)
+ while (--i >= 0)
clk_disable_unprepare(jpeg->clocks[i]);
return ret;
}
Re: [PATCH] kconfig: Document the 'menu' struct
2017-10-04 12:37 GMT+09:00 Ulf Magnusson : > Understanding what it represents helps a lot when reading the code, and > it's not obvious, so document it. > > The ROOT_MENU flag is only set and tested by the gconf and qconf front > ends, so leave it undocumented here. The obvious guess for what it means > is correct. > > Signed-off-by: Ulf Magnusson Applied to linux-kbuild/kconfig. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH] kconfig: Document the 'symbol' struct
2017-10-04 14:48 GMT+09:00 Ulf Magnusson : > Visibility and choices in particular might be a bit tricky to figure > out. > > Also fix existing comment to point out that P_MENU is also used for > menus. > > Signed-off-by: Ulf Magnusson Applied to linux-kbuild/kconfig. Thanks! -- Best Regards Masahiro Yamada
[PATCH] drivers/scsi/qla2xxx: fix double free bug after firmware timeout
When the qla2xxx firmware is unavailable, eventually qla2x00_sp_timeout() is reached, which calls the timeout function and frees the srb_t instance. The timeout function always resolves to qla2x00_async_iocb_timeout(), which invokes another callback function called "done". All of these qla2x00_*_sp_done() callbacks also free the srb_t instance; after returning to qla2x00_sp_timeout(), it is freed again. The fix is to remove the "sp->free(sp)" call from qla2x00_sp_timeout() and add it to those code paths in qla2x00_async_iocb_timeout() which do not already free the object. This is how it looks like with KASAN: BUG: KASAN: use-after-free in qla2x00_sp_timeout+0x228/0x250 Read of size 8 at addr 88278147a590 by task swapper/2/0 Allocated by task 1502: save_stack+0x33/0xa0 kasan_kmalloc+0xa0/0xd0 kmem_cache_alloc+0xb8/0x1c0 mempool_alloc+0xd6/0x260 qla24xx_async_gnl+0x3c5/0x1100 Freed by task 0: save_stack+0x33/0xa0 kasan_slab_free+0x72/0xc0 kmem_cache_free+0x75/0x200 qla24xx_async_gnl_sp_done+0x556/0x9e0 qla2x00_async_iocb_timeout+0x1c7/0x420 qla2x00_sp_timeout+0x16d/0x250 call_timer_fn+0x36/0x200 The buggy address belongs to the object at 88278147a440 which belongs to the cache qla2xxx_srbs of size 344 The buggy address is located 336 bytes inside of 344-byte region [88278147a440, 88278147a598) Signed-off-by: Max Kellermann --- drivers/scsi/qla2xxx/qla_init.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c index b5b48ddca962..801890564e00 100644 --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -58,7 +58,6 @@ qla2x00_sp_timeout(unsigned long __data) req->outstanding_cmds[sp->handle] = NULL; iocb = &sp->u.iocb_cmd; iocb->timeout(sp); - sp->free(sp); spin_unlock_irqrestore(&vha->hw->hardware_lock, flags); } @@ -121,9 +120,11 @@ qla2x00_async_iocb_timeout(void *data) ea.data[1] = lio->u.logio.data[1]; ea.sp = sp; qla24xx_handle_plogi_done_event(fcport->vha, &ea); + sp->free(sp); break; case SRB_LOGOUT_CMD: qlt_logo_completion_handler(fcport, QLA_FUNCTION_TIMEOUT); + sp->free(sp); break; case SRB_CT_PTHRU_CMD: case SRB_MB_IOCB:
RE: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel Software Guard Extensions
Jarkko Sakkinen wrote:
> +static void sgx_ewb(struct sgx_encl *encl, struct sgx_encl_page *entry)
> +{
> + struct sgx_va_page *va_page;
> + unsigned int va_offset;
> + int ret;
> + int i;
> +
> + for (i = 0; i < 2; i++) {
> + va_page = list_first_entry(&encl->va_pages,
> +struct sgx_va_page, list);
> + va_offset = sgx_alloc_va_slot(va_page);
> + if (va_offset < PAGE_SIZE)
> + break;
> +
> + list_move_tail(&va_page->list, &encl->va_pages);
> + }
This is broken, there is no guarantee that the next VA page will have
a free slot. You have to walk over all VA pages to guarantee a slot
is found, e.g. this caused EWB and ELDU errors.
> +
> + ret = __sgx_ewb(encl, entry, va_page, va_offset);
> + if (ret == SGX_NOT_TRACKED) {
> + /* slow path, IPI needed */
> + sgx_flush_cpus(encl);
> + ret = __sgx_ewb(encl, entry, va_page, va_offset);
> + }
> +
> + if (ret) {
> + sgx_invalidate(encl, true);
> + if (ret > 0)
> + sgx_err(encl, "EWB returned %d, enclave invalidated\n",
> + ret);
> + }
> +
> + sgx_free_page(entry->epc_page, encl);
> + entry->desc |= va_offset;
> + entry->va_page = va_page;
> + entry->desc &= ~SGX_ENCL_PAGE_RESERVED;
> +}
[...]
> +
> + /* Legal race condition, page is already faulted. */
> + if (entry->list.next != LIST_POISON1) {
Querying list.next to determine if an encl_page is resident in the EPC
is ugly and unintuitive, and depending on list's internal state seems
dangerous. Why not use a flag in the encl_page, e.g. as in the patch
I submitted almost 8 months ago for combining epc_page and va_page into
a union? And, the encl's SGX_ENCL_SECS_EVICTED flag can be dropped if
a flag is added to indicate whether or not any encl_page is resident in
the EPC.
https://lists.01.org/pipermail/intel-sgx-kernel-dev/2017-April/000570.html
> + if (reserve)
> + entry->desc |= SGX_ENCL_PAGE_RESERVED;
> + goto out;
> + }
> +
> + epc_page = sgx_alloc_page(SGX_ALLOC_ATOMIC);
> + if (IS_ERR(epc_page)) {
> + rc = PTR_ERR(epc_page);
> + epc_page = NULL;
> + goto out;
> + }
> +
> + /* If SECS is evicted then reload it first */
> + if (encl->flags & SGX_ENCL_SECS_EVICTED) {
> + secs_epc_page = sgx_alloc_page(SGX_ALLOC_ATOMIC);
> + if (IS_ERR(secs_epc_page)) {
> + rc = PTR_ERR(secs_epc_page);
> + secs_epc_page = NULL;
> + goto out;
> + }
> +
> + rc = sgx_eldu(encl, &encl->secs, secs_epc_page, true);
> + if (rc)
> + goto out;
> +
> + encl->secs.epc_page = secs_epc_page;
> + encl->flags &= ~SGX_ENCL_SECS_EVICTED;
> +
> + /* Do not free */
> + secs_epc_page = NULL;
> + }
> +
> + rc = sgx_eldu(encl, entry, epc_page, false /* is_secs */);
> + if (rc)
> + goto out;
> +
> + /* Track the EPC page even if vm_insert_pfn fails; we need to ensure
> + * the EPC page is properly freed and we can't do EREMOVE right away
> + * because EREMOVE may fail due to an active cpu in the enclave. We
> + * can't call vm_insert_pfn before sgx_eldu because SKL signals #GP
> + * instead of #PF if the EPC page is invalid.
> + */
> + encl->secs_child_cnt++;
> +
> + entry->epc_page = epc_page;
> +
> + if (reserve)
> + entry->desc |= SGX_ENCL_PAGE_RESERVED;
> +
> + /* Do not free */
> + epc_page = NULL;
> + list_add_tail(&entry->list, &encl->load_list);
> +
> + rc = vm_insert_pfn(vma, addr, SGX_EPC_PFN(entry->epc_page));
> + if (rc) {
> + /* Kill the enclave if vm_insert_pfn fails; failure only occurs
> + * if there is a driver bug or an unrecoverable issue, e.g. OOM.
> + */
> + sgx_crit(encl, "vm_insert_pfn returned %d\n", rc);
> + sgx_invalidate(encl, true);
> + goto out;
> + }
> +
> + sgx_test_and_clear_young(entry, encl);
> +out:
> + mutex_unlock(&encl->lock);
> + if (epc_page)
> + sgx_free_page(epc_page, encl);
> + if (secs_epc_page)
> + sgx_free_page(secs_epc_page, encl);
> + return rc ? ERR_PTR(rc) : entry;
> +}
>
Re: [PATCH 1/6] staging: pi433: Split rf69_set_crc_enabled into two functions
On Thu, Dec 07, 2017 at 03:38:57PM +0100, Greg KH wrote: > On Wed, Dec 06, 2017 at 09:42:19PM +0100, Simon Sandström wrote: > > Splits rf69_set_crc_enabled(dev, enabled) into > > rf69_enable_crc(dev) and rf69_disable_crc(dev). > > > > Signed-off-by: Simon Sandström > > --- > > drivers/staging/pi433/pi433_if.c | 22 -- > > drivers/staging/pi433/rf69.c | 18 ++ > > drivers/staging/pi433/rf69.h | 4 ++-- > > 3 files changed, 28 insertions(+), 16 deletions(-) > > This series did not apply at all. > > What tree and branch did you make it against? > > Please redo it against my staging.git tree, the staging-next branch > should be fine, or the staging-testing will work as well. > > thanks, > > greg k-h Hmm. Haven't you already applied these? https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=39252a4bcf63d9dbc168b9ef56eb4ca42e045b9d >patch "staging: pi433: Split rf69_set_crc_enabled into two functions" added to >staging-testing > >This is a note to let you know that I've just added the patch titled > >staging: pi433: Split rf69_set_crc_enabled into two functions > > ... Regards, Simon
Re: [PATCH] kthread: finer-grained lockdep/cross-release completion
On Thu, Dec 07, 2017 at 01:22:56PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> > Since -rc1 we're hitting a bunch of lockdep splats using the new
> > cross-release stuff around the 2 kthread completions. In all cases
> > they are because totally independent uses of kthread are mixed up by
> > lockdep into the same locking class, creating artificial deadlocks.
> >
> > Fix this by converting kthread code in the same way as e.g.
> > alloc_workqueue already works: Use macros for the public api so we can
> > have a callsite specific lockdep key, then pass that through the
> > entire callchain. Due to the many entry points this is slightly
> > tedious.
>
> Do you have a splat somewhere? I'm having trouble seeing how all this
> comes together. That is, I've no real idea what you're actual problem is
> and if this is the right solution.
The bugzilla link is full of them. One below as example - it ties entirely
unrelated locking chains from i915 memory management together with other
stuff, with the only common bit that the kthread completions are somewhere
in there. But neither can i915 code ever get at the cpu kthread nor the
other way round, so it's flat out impossible to ever hit a deadlock this
way. Same reasons why not all workqueues share their lockdep map either.
-Daniel
[ 85.062523] Setting dangerous option reset - tainting kernel
[ 85.068934] i915 :00:02.0: Resetting chip after gpu hang
[ 85.069408] ==
[ 85.069410] WARNING: possible circular locking dependency detected
[ 85.069413] 4.15.0-rc1-CI-CI_DRM_3397+ #1 Tainted: G U
[ 85.069415] --
[ 85.069417] gem_exec_captur/2810 is trying to acquire lock:
[ 85.069419] ((completion)&self->parked){+.+.}, at: []
kthread_park+0x3d/0x50
[ 85.069426]
but task is already holding lock:
[ 85.069428] (&dev->struct_mutex){+.+.}, at: []
i915_reset_device+0x1bd/0x230 [i915]
[ 85.069448]
which lock already depends on the new lock.
[ 85.069451]
the existing dependency chain (in reverse order) is:
[ 85.069454]
-> #3 (&dev->struct_mutex){+.+.}:
[ 85.069460]__mutex_lock+0x81/0x9b0
[ 85.069481]i915_mutex_lock_interruptible+0x47/0x130 [i915]
[ 85.069502]i915_gem_fault+0x201/0x760 [i915]
[ 85.069507]__do_fault+0x15/0x70
[ 85.069509]__handle_mm_fault+0x7bf/0xda0
[ 85.069512]handle_mm_fault+0x14f/0x2f0
[ 85.069515]__do_page_fault+0x2d1/0x560
[ 85.069518]page_fault+0x22/0x30
[ 85.069520]
-> #2 (&mm->mmap_sem){}:
[ 85.069525]__might_fault+0x63/0x90
[ 85.069529]_copy_to_user+0x1e/0x70
[ 85.069532]perf_read+0x21d/0x290
[ 85.069534]__vfs_read+0x1e/0x120
[ 85.069536]vfs_read+0xa1/0x150
[ 85.069539]SyS_read+0x40/0xa0
[ 85.069541]entry_SYSCALL_64_fastpath+0x1c/0x89
[ 85.069543]
-> #1 (&cpuctx_mutex){+.+.}:
[ 85.069547]perf_event_ctx_lock_nested+0xbc/0x1d0
[ 85.069549]
-> #0 ((completion)&self->parked){+.+.}:
[ 85.069555]lock_acquire+0xaf/0x200
[ 85.069558]wait_for_common+0x54/0x210
[ 85.069560]kthread_park+0x3d/0x50
[ 85.069579]i915_gem_reset_prepare_engine+0x1d/0x90 [i915]
[ 85.069600]i915_gem_reset_prepare+0x2c/0x60 [i915]
[ 85.069617]i915_reset+0x66/0x230 [i915]
[ 85.069635]i915_reset_device+0x1cb/0x230 [i915]
[ 85.069651]i915_handle_error+0x2d3/0x430 [i915]
[ 85.069670]i915_wedged_set+0x79/0xc0 [i915]
[ 85.069673]simple_attr_write+0xab/0xc0
[ 85.069677]full_proxy_write+0x4b/0x70
[ 85.069679]__vfs_write+0x1e/0x130
[ 85.069682]vfs_write+0xc0/0x1b0
[ 85.069684]SyS_write+0x40/0xa0
[ 85.069686]entry_SYSCALL_64_fastpath+0x1c/0x89
[ 85.069688]
other info that might help us debug this:
[ 85.069692] Chain exists of:
(completion)&self->parked --> &mm->mmap_sem -->
&dev->struct_mutex
[ 85.069698] Possible unsafe locking scenario:
[ 85.069701]CPU0CPU1
[ 85.069703]
[ 85.069705] lock(&dev->struct_mutex);
[ 85.069707]lock(&mm->mmap_sem);
[ 85.069710]lock(&dev->struct_mutex);
[ 85.069713] lock((completion)&self->parked);
[ 85.069715]
*** DEADLOCK ***
[ 85.069718] 3 locks held by gem_exec_captur/2810:
[ 85.069722] #0: (sb_writers#10){.+.+}, at: []
vfs_write+0x15e/0x1b0
[ 85.069727] #1: (&attr->mutex){+.+.}, at: []
simple_attr_write+0x36/0xc0
[ 85.069732] #2: (&dev->struct_mutex){+.+.}, at: []
i915_reset_device+0x1bd/0x230 [i915]
[ 85.069751]
Re: PI futexes + lock stealing woes
Peter Zijlstra writes:
> The below compiles and boots, but is otherwise untested. Could you give
> it a spin?
Thank you! Yes, I'll start a test now.
-Gratian
> ---
> kernel/futex.c | 83
> +
> kernel/locking/rtmutex.c| 26 +
> kernel/locking/rtmutex_common.h | 1 +
> 3 files changed, 87 insertions(+), 23 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 76ed5921117a..29ac5b64e7c7 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2294,21 +2294,17 @@ static void unqueue_me_pi(struct futex_q *q)
> spin_unlock(q->lock_ptr);
> }
>
> -/*
> - * Fixup the pi_state owner with the new owner.
> - *
> - * Must be called with hash bucket lock held and mm->sem held for non
> - * private futexes.
> - */
> static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
> - struct task_struct *newowner)
> + struct task_struct *argowner)
> {
> - u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
> struct futex_pi_state *pi_state = q->pi_state;
> u32 uval, uninitialized_var(curval), newval;
> - struct task_struct *oldowner;
> + struct task_struct *oldowner, *newowner;
> + u32 newtid;
> int ret;
>
> + lockdep_assert_held(q->lock_ptr);
> +
> raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
>
> oldowner = pi_state->owner;
> @@ -2317,11 +2313,17 @@ static int fixup_pi_state_owner(u32 __user *uaddr,
> struct futex_q *q,
> newtid |= FUTEX_OWNER_DIED;
>
> /*
> - * We are here either because we stole the rtmutex from the
> - * previous highest priority waiter or we are the highest priority
> - * waiter but have failed to get the rtmutex the first time.
> + * We are here because either:
> + *
> + * - we stole the lock and pi_state->owner needs updating to reflect
> + *that (@argowner == current),
>*
> - * We have to replace the newowner TID in the user space variable.
> + * or:
> + *
> + * - someone stole our lock and we need to fix things to point to the
> + *new owner (@argowner == NULL).
> + *
> + * Either way, we have to replace the TID in the user space variable.
>* This must be atomic as we have to preserve the owner died bit here.
>*
>* Note: We write the user space value _before_ changing the pi_state
> @@ -2334,6 +2336,42 @@ static int fixup_pi_state_owner(u32 __user *uaddr,
> struct futex_q *q,
>* in the PID check in lookup_pi_state.
>*/
> retry:
> + if (!argowner) {
> + if (oldowner != current) {
> + /*
> + * We raced against a concurrent self; things are
> + * already fixed up. Nothing to do.
> + */
> + ret = 0;
> + goto out_unlock;
> + }
> +
> + if (__rt_mutex_futex_trylock(&pi_state->pi_mutex)) {
> + /* We got the lock after all, nothing to fix. */
> + ret = 0;
> + goto out_unlock;
> + }
> +
> + /*
> + * Since we just failed the trylock; there must be an owner.
> + */
> + newowner = rt_mutex_owner(&pi_state->pi_mutex);
> + BUG_ON(!newowner);
> + } else {
> + WARN_ON_ONCE(argowner != current);
> + if (oldowner == current) {
> + /*
> + * We raced against a concurrent self; things are
> + * already fixed up. Nothing to do.
> + */
> + ret = 0;
> + goto out_unlock;
> + }
> + newowner = argowner;
> + }
> +
> + newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
> +
> if (get_futex_value_locked(&uval, uaddr))
> goto handle_fault;
>
> @@ -2434,15 +2472,28 @@ static int fixup_owner(u32 __user *uaddr, struct
> futex_q *q, int locked)
>* Got the lock. We might not be the anticipated owner if we
>* did a lock-steal - fix up the PI-state in that case:
>*
> - * We can safely read pi_state->owner without holding wait_lock
> - * because we now own the rt_mutex, only the owner will attempt
> - * to change it.
> + * Speculative pi_state->owner read (we don't hold wait_lock);
> + * since we own the lock pi_state->owner == current is the
> + * stable state, anything else needs more attention.
>*/
> if (q->pi_state->owner != current)
> ret = fixup_pi_state_owner(uaddr, q, current);
> goto out;
> }
>
> + /*
> + * If we didn't get the lock; check if anybody s
Re: [PATCH] Makefile: .PHONY is not a variable, but PHONY is
Hi Ulf, 2015-09-02 22:11 GMT+09:00 : > From: Ulf Magnusson > > .PHONY is a target, not a variable. > > Signed-off-by: Ulf Magnusson > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 24c9e3d..4835d24 100644 > --- a/Makefile > +++ b/Makefile > @@ -1609,6 +1609,6 @@ endif # skip-makefile > PHONY += FORCE > FORCE: > > -# Declare the contents of the .PHONY variable as phony. We keep that > +# Declare the contents of the PHONY variable as phony. We keep that > # information in a variable so we can use it in if_changed and friends. > .PHONY: $(PHONY) > -- I found this patch by chance. Can you fix other files in scripts/ as well? I see the same pattern in Makefile.build Makefile.clean Makefile.modbuiltin Makefile.modinst Makefile.modpost Makefile.modsign Then, I will apply it quickly. -- Best Regards Masahiro Yamada
Re: Timer refuses to expire
On Thu, Dec 07, 2017 at 03:03:50PM +0800, Boqun Feng wrote: > Hi Paul, > > On Wed, Dec 06, 2017 at 02:04:21PM -0800, Paul E. McKenney wrote: > > On Tue, Dec 05, 2017 at 03:37:44PM -0800, Paul E. McKenney wrote: > > > On Mon, Dec 04, 2017 at 09:42:08AM -0800, Paul E. McKenney wrote: > > > > On Fri, Dec 01, 2017 at 10:25:29AM -0800, Paul E. McKenney wrote: > > > > > Hello, Anna-Maria, > > > > > > > > > > It turned out that one set of problems was due to NO_HZ_FULL issues, > > > > > which are addressed with a pair of patches. However, there is still > > > > > one > > > > > case of a timer refusing to expire in rcutorture's TREE01 test > > > > > scenario. > > > > > The takes from two to four hours to trigger, and the most recent one > > > > > gives the following diagnostic (see patch at the very end of this > > > > > email): > > > > > > > > > > [13166.127458] schedule_timeout: Waylayed timer base->clk: > > > > > 0x100c40004 jiffies: 0x100c4524e base->next_expiry: 0x100c40004 > > > > > timer->flags: 0x103 timer->expires 0x100c40003 idx: 4 idx_now: ea > > > > > base->pending_map > > > > > 0010001080040204 > > > > > > > > > > The message appears any time a timer for less than five jiffies takes > > > > > more than eight seconds to expire. In all cases, this expiry did not > > > > > happen naturally, but rather via an unsolicited wakeup from the RCU > > > > > CPU > > > > > stall code. If I am interpreting this message correctly, base->clk > > > > > has advanced past this timer, and the timer is correctly flagged in > > > > > base->pending_map. This seems like part of the problem because the > > > > > timer's timeout was only three jiffies. However, base->clk has not > > > > > advanced for more than 20 seconds, which seems like another problem. > > > > > > > > > > What additional diagnostics would be helpful? I can capture data > > > > > at the beginning of the schedule_timeout in the timer_list structure, > > > > > and of course can print more information at the time of the wakeup. > > > > > > > > And on the off-chance that the following messages from this weekend's > > > > runs are at all helpful. One interesting point is that starting at > > > > time 4731.872311, there are repeated enqueues to CPU 5's timer wheel, > > > > but CPU 5's ->clk does not advance. Things seem to advance at > > > > time 4891.721190. > > > > > > Another layer on the onion... For at least some of the failures, there > > > is a stalled CPU-hotplug operation. This of course can mean that the > > > timers are stuck on the partially offlined CPU. So I dumped the stack > > > of the task that is taking the CPU offline. Please see below for console > > > output and patch. > > > > > > I am considering doing an unsolicited wakeup of the task doing the > > > hotplug operation, but I am not convinced that the entirely of the CPU > > > hotplug code is willing to put up with that sort of thing. > > > > What I did instead was to dump out the state of the task that > > __cpuhp_kick_ap() waits on, please see the patch at the very end of this > > email. This triggered as shown below, and you guessed it, that task is > > waiting on a grace period. Which I am guessing won't happen until the > > outgoing CPU reaches CPUHP_TIMERS_DEAD state and calls timers_dead_cpu(). > > Which will prevent RCU's grace-period kthread from ever awakening, which > > will prevent the task that __cpuhp_kick_ap() waits on from ever awakening, > > which will prevent the outgoing CPU from reaching CPUHP_TIMERS_DEAD state. > > > > Deadlock. > > There is one thing I'm confused here. Sure, this is a deadlock, but the > timer should still work in such a deadlock, right? I mean, the timer of > schedule_timeout() should be able to wake up rcu_gp_kthread() even in > this case? And yes, the gp kthread will continue to wait due to the > deadlock, but the deadlock can not explain the "Waylayed timer", right? My belief is that the timer cannot fire because it is still on the offlined CPU, and that CPU has not yet reached timers_dead_cpu(). But I might be missing something subtle in either the timers code or the CPU-hotplug code, so please do check my reasoning here. (I am relying on the "timer->flags: 0x4007" and the "cpuhp/7" below, which I believe means that the timer is on CPU 7 and that it is CPU 7 that is in the process of going offline.) The "Waylayed timer" happens because the RCU CPU stall warning code wakes up the grace-period kthread. This is driven out of the scheduling-clock tick, so is unaffected by timers, though it does rely on the jiffies counter continuing to be incremented. So what am I missing here? Thanx, Paul > Regards, > Boqun > > > Does that make sense, or am I missing a trick here? > > > > I tried invoking timers_dead_cpu() from sched_cpu_
Re: linux-next: build warnings after merge of the gpio tree
On Wed, Dec 6, 2017 at 9:51 PM, Rob Herring wrote:
> On Tue, Dec 5, 2017 at 4:48 PM, Stephen Rothwell
> wrote:
> These 2 aren't in -next and seem to have been missed:
>
> arm: dts: qcom: fix missing #phy-cells for apq8064
Apparently this is a subsect of 3191b5b332f8 ("ARM: dts: qcom-apq8064: Fix dsi
and hdmi phy cells"), which we already have
> arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Picked this one up now.
Arnd
RE: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support
For Intel Broadwell, SKylake, and KabyLake PCIe Root Port, the threshold is recommended as it is in the commit. If the BIOS/Coreboot porting between platforms is taken into consideration, using a build definition or variables from somewhere of customizable zone is preferred. Let Coreboot guys make the call since I am working for Intel Only. -Original Message- From: Bjorn Helgaas [mailto:helg...@kernel.org] Sent: Thursday, December 7, 2017 10:45 PM To: Chen, Kenji Cc: linux-...@vger.kernel.org; Thierry Reding ; Manikanta Maddireddy ; David Daney ; Krishna Kishore ; linux-kernel@vger.kernel.org; Vidya Sagar ; Julia Lawall ; linux-te...@vger.kernel.org; Patrick Georgi ; Rajat Jain ; Yinghai Lu ; Stefan Reinauer ; Duncan Laurie Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support On Wed, Dec 06, 2017 at 01:55:37AM +, Chen, Kenji wrote: > https://pcisig.com/sites/default/files/specification_documents/ECN_L1_ > PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf With all due respect, this doesn't seem to add any new information. For example, the L1 PM Substates Control 1 register description from the above is basically identical to the published PCIe r3.1, sec 7.33.3. So it doesn't answer the questions of: 1) Why coreboot sets the L1.2 threshold to a fixed value, and 2) How "(1 << 21) | (1 << 23) | (1 << 30)" relates to the Control 1 register > Pls also check My Intel Doc# 545845 for the bits fields description. I don't have access to this document. The Linux code I'm proposing is based on the PCIe spec and is intended to work on all hardware that conforms to that spec. I'm not very familiar with coreboot, but maybe the L1 Substates code there is only intended to work on certain Intel chipsets and doesn't need to work on other hardware? Bjorn > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Wednesday, December 6, 2017 3:41 AM > To: linux-...@vger.kernel.org > Cc: Chen, Kenji ; Thierry Reding > ; Manikanta Maddireddy ; > David Daney ; Krishna Kishore > ; linux-kernel@vger.kernel.org; Vidya Sagar > ; Julia Lawall ; > linux-te...@vger.kernel.org; Patrick Georgi ; > Rajat Jain ; Yinghai Lu ; > Stefan Reinauer ; Duncan Laurie > > Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support > > On Sat, Dec 02, 2017 at 03:45:38PM -0600, Bjorn Helgaas wrote: > > The PCIe active link power state is L0. ASPM defines two low-power > > states: L0s and L1. The L1 PM Substates feature defines two > > additional low-power states: L1.1 and L2.2. > > > > The L1.2 state may have substantial entry/exit latency. Downstream > > devices can use the Latency Tolerance Reporting (LTR) feature to > > report how much latency they can tolerate. The L1 PM Substates > > capability includes a programmable L1.2 threshold register. If the > > downstream devices can tolerate the latency indicated by the > > threshold, L1.2 may be used. > > > > If LTR is not enabled, the L1.2 threshold is ignored and L1.2 can be > > used whenever it is enabled and CLKREQ# is de-asserted. Linux > > currently never enables LTR, but firmware may have done so. > > > > The current L1 PM substates support in Linux sets the L1.2 threshold > > to a fixed value (163.84us) copied from coreboot [1]. I don't know > > where that value came from, and it is incorrect for some platforms, > > e.g., Tegra [2]. > > > > These patches change that so we calculate the L1.2 threshold based > > on values reported by the hardware, and we enable LTR whenever possible. > > > > This is all just my understanding from reading the spec. I'd be > > glad to be corrected if I'm going wrong. > > > > I'm particularly puzzled about the coreboot code in > > pciexp_L1_substate_commit() that sets LTR_L1.2_THRESHOLD: > > > > + pcie_update_cfg(root, root_cap + 0x08, ~0xe3ff, > > + (1 << 21) | (1 << 23) | (1 << 30)); > > > > This is writing the L1 PM Substates Control 1 register, but the > > shifts don't match up with any of the fields in the register, so > > this is an awfully funny way to write the threshold. > > > > [1] > > https://mail.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134. > > html [2] > > https://lkml.kernel.org/r/1510492674-12786-1-git-send-email-vidyas@n > > vi > > dia.com > > > > --- > > > > Bjorn Helgaas (2): > > PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device characteristics > > PCI/ASPM: Enable Latency Tolerance Reporting when supported > > > > > > drivers/pci/pcie/aspm.c | 71 > > +++ > > drivers/pci/probe.c | 33 ++ > > include/linux/pci.h |2 + > > 3 files changed, 82 insertions(+), 24 deletions(-) > > I applied these with Vidya's Reviewed-by to pci/aspm for v4.16. > > I'd still really like to hear from the coreboot folks about the rationale for > the current coreboot code. You folks are in a much better p
Re: [PATCH] btrfs: tree-checker: use %zu format string for size_t
On Thu, Dec 07, 2017 at 08:32:04AM +0800, Qu Wenruo wrote:
>
>
> On 2017年12月06日 22:18, Arnd Bergmann wrote:
> > The return value of sizeof() is of type size_t, so we must print it
> > using the %z format modifier rather than %l to avoid this warning
> > on some architectures:
> >
> > fs/btrfs/tree-checker.c: In function 'check_dir_item':
> > fs/btrfs/tree-checker.c:273:50: error: format '%lu' expects argument of
> > type 'long unsigned int', but argument 5 has type 'u32' {aka 'unsigned
> > int'} [-Werror=format=]
>
> Any idea about which architecture will cause such warning?
> On x86_64 I always fail to get such warning.
The intel 0-day build bot compiles on various architectures and 32/64
setups, I'm not sure if this warning has been reported, no such mail in
my mboxes.
Re: [PATCH net-next v4 1/4] phylib: Add device reset delay support
Hi Geert,
On 12/07/2017 03:52 PM, Geert Uytterhoeven wrote:
> Hi Richard,
>
> On Thu, Dec 7, 2017 at 3:43 PM, Richard Leitner wrote:
>> --- a/drivers/net/phy/mdio_device.c
>> +++ b/drivers/net/phy/mdio_device.c
>> @@ -24,6 +24,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> void mdio_device_free(struct mdio_device *mdiodev)
>> {
>> @@ -118,8 +119,16 @@ EXPORT_SYMBOL(mdio_device_remove);
>>
>> void mdio_device_reset(struct mdio_device *mdiodev, int value)
>> {
>> - if (mdiodev->reset)
>> - gpiod_set_value(mdiodev->reset, value);
>> + unsigned int d;
>> +
>> + if (!mdiodev->reset)
>> + return;
>> +
>> + gpiod_set_value(mdiodev->reset, value);
>> +
>> + d = value ? mdiodev->reset_delay : mdiodev->reset_post_delay;
>> + if (d)
>> + usleep_range(d, d + min_t(unsigned int, d / 10, 100));
>
> Oops, I meant "max_t", not "min_t", else the upper limit can be "d + 0",
> which is not what we want.
You're right...
> Sorry, my fault.
I just copied it over from you suggestion without thinking about it...
So it's definitely my fault too ;-)
I'll wait for some more comments and send a new version next week.
regards;Richard.L
Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()
On Thu, 7 Dec 2017, Geert Uytterhoeven wrote: > Hi Alan, > > On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern wrote: > > On Wed, 6 Dec 2017, SF Markus Elfring wrote: > >> >>> Does the existing memory allocation error message include the > >> >>> &udev->dev device name and driver name? If it doesn't, there will be > >> >>> no way for the user to tell that the error message is related to the > >> >>> device failure. > >> >> > >> >> No, but the effect is similar. > >> >> > >> >> OOM does a dump_stack() so this function's call tree is shown. > >> > > >> > A call stack doesn't tell you which device was being handled. > >> > >> Do you find a default Linux allocation failure report insufficient then? > >> > >> Would you like to to achieve that the requested information can be > >> determined > >> from a backtrace? > > > > It is not practical to do this. The memory allocation routines do not > > for what purpose the memory is being allocated; hence when a failure > > occurs they cannot tell what device (or other part of the system) will > > be affected. > > If even allocation of 24 bytes fails, lots of other devices and other parts of > the system will start failing really soon... In fact, one wonders if the allocation routine's own error message and stack trace would actually appear anywhere... > > That's why we have a secondary error message. > > ... and the secondary error message would still be useless. Well, there is still a difference between GFP_ATOMIC and GFP_KERNEL allocations. Failure of the first doesn't necessarily imply failure of the second, so perhaps the system could recover. The real problem is that the kernel development community doesn't have a fixed policy on how to handle memory allocation errors. There are several possibilities: Ignore them on the grounds that they will never happen. (Really? And what is the size limit above which they might happen?) Ignore them on the grounds that the machine will hang or crash in the near future. (Is this guaranteed?) Treat them like other errors: try to press forward (perhaps in a degraded mode). Treat them like other errors: log an error message and try to press forward. And probably a few more that haven't occurred to me. No doubt there are examples of each at various places in the kernel. Nobody seems able to agree on a single course of action. Maybe not even Linus. If there was one agreed-upon policy, then we could definitively point to old code and say "That's wrong, and here is how it should be fixed." But currently this is not possible, and we end up with repetitive discussions like this one that aren't of general use. Alan Stern
Re: [PATCH] integrity: get rid of unneeded initializations in integrity_iint_cache entries
On Thu, 2017-12-07 at 09:35 -0500, Mimi Zohar wrote: > On Thu, 2017-12-07 at 07:01 -0500, Jeff Layton wrote: > > On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote: > > > On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote: > > > > Quoting Jeff Layton (jlay...@kernel.org): > > > > > From: Jeff Layton > > > > > > > > > > The init_once routine memsets the whole object to 0, and then > > > > > explicitly sets some of the fields to 0 again. Just remove the > > > > > explicit > > > > > initializations. > > > > > > > > > > Signed-off-by: Jeff Layton > > > > > > > > Reviewed-by: Serge Hallyn > > > > > > Thanks, queued. > > > > > > Mimi > > > > > > > Hi Mimi, > > > > I notice that this patch hasn't made the last couple of releases. Was it > > dropped for some reason? > > Thanks for the reminder. I accidentally dropped it (and Sascha > Hauer's patch). The subject line is too long. Assuming you don't > object, I'll replace the "get rid of" with "removed" and queue the > patch in the next-queued-testing branch. > > Mimi > Sounds good. Thanks, -- Jeff Layton
[PATCH v2 02/10] arm64: dts: qcom: msm8916-pins: remove assignments to bias-disable
Drop assignments to bias-disable as the documentation [1] states that
this property doesn't take a value. Other occurrences of this property
respect that.
[1] Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
Signed-off-by: Damien Riegel
Reviewed-by: Bjorn Andersson
---
Changes in v2:
- Added Reviewed-by Bjorn Andersson
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 4cb0b5834143..c67ad8ed8b60 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -278,7 +278,7 @@
pinconf {
pins = "gpio6", "gpio7";
drive-strength = <16>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -290,7 +290,7 @@
pinconf {
pins = "gpio6", "gpio7";
drive-strength = <2>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -302,7 +302,7 @@
pinconf {
pins = "gpio14", "gpio15";
drive-strength = <16>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -314,7 +314,7 @@
pinconf {
pins = "gpio14", "gpio15";
drive-strength = <2>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -326,7 +326,7 @@
pinconf {
pins = "gpio22", "gpio23";
drive-strength = <16>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -338,7 +338,7 @@
pinconf {
pins = "gpio22", "gpio23";
drive-strength = <2>;
- bias-disable = <0>;
+ bias-disable;
};
};
--
2.15.0
[PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically
Also, it was using whitespaces for indentation on some lines, fix that
while moving it.
Signed-off-by: Damien Riegel
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index d4b35d81a282..981450f50e10 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -544,14 +544,6 @@
};
};
-&wcd_codec {
-status = "okay";
-clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
-clock-names = "mclk";
- qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
- qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
-};
-
&smd_rpm_regulators {
vdd_l1_l2_l3-supply = <&pm8916_s3>;
vdd_l5-supply = <&pm8916_s3>;
@@ -671,3 +663,11 @@
regulator-max-microvolt = <3337000>;
};
};
+
+&wcd_codec {
+ status = "okay";
+ clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "mclk";
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+};
--
2.15.0
[PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings
Nodes relative to the first sdhc node were interlaced with node of the
second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also
rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as
"pmx_sdc" is the prefix used by other nodes.
Signed-off-by: Damien Riegel
---
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index c79301f204b7..7704ddecb6c4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -194,21 +194,6 @@
};
};
- sdhc2_cd_pin {
- sdc2_cd_on: cd_on {
- pinmux {
- function = "gpio";
- pins = "gpio38";
- };
- };
- sdc2_cd_off: cd_off {
- pinmux {
- function = "gpio";
- pins = "gpio38";
- };
- };
- };
-
pmx_sdc1_clk {
sdc1_clk_on: clk_on {
pinmux {
@@ -287,6 +272,21 @@
};
};
+ pmx_sdc2_cd_pin {
+ sdc2_cd_on: cd_on {
+ pinmux {
+ function = "gpio";
+ pins = "gpio38";
+ };
+ };
+ sdc2_cd_off: cd_off {
+ pinmux {
+ function = "gpio";
+ pins = "gpio38";
+ };
+ };
+ };
+
cdc-pdm-lines {
cdc_pdm_lines_act: pdm_lines_on {
pinmux {
--
2.15.0
[PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs
This commit drops pin configs that cannot be moved to board files as
no boards use them.
Signed-off-by: Damien Riegel
---
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 33 --
1 file changed, 33 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 0790232c4654..c79301f204b7 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -311,26 +311,13 @@
pins = "gpio113", "gpio114", "gpio115",
"gpio116";
};
- pinconf {
- pins = "gpio113", "gpio114", "gpio115",
- "gpio116";
- drive-strength = <8>;
- bias-pull-none;
- };
};
-
ext_pri_tlmm_lines_sus: ext_pa_off {
pinmux {
function = "pri_mi2s";
pins = "gpio113", "gpio114", "gpio115",
"gpio116";
};
- pinconf {
- pins = "gpio113", "gpio114", "gpio115",
- "gpio116";
- drive-strength = <2>;
- bias-disable;
- };
};
};
@@ -340,23 +327,12 @@
function = "pri_mi2s_ws";
pins = "gpio110";
};
- pinconf {
- pins = "gpio110";
- drive-strength = <8>;
- bias-pull-none;
- };
};
-
ext_pri_ws_sus: ext_pa_off {
pinmux {
function = "pri_mi2s_ws";
pins = "gpio110";
};
- pinconf {
- pins = "gpio110";
- drive-strength = <2>;
- bias-disable;
- };
};
};
@@ -403,10 +379,6 @@
function = "dmic0_data";
pins = "gpio1";
};
- pinconf {
- pins = "gpio0", "gpio1";
- drive-strength = <8>;
- };
};
cdc_dmic_lines_sus: dmic_lines_off {
pinmux_dmic0_clk {
@@ -417,11 +389,6 @@
function = "dmic0_data";
pins = "gpio1";
};
- pinconf {
- pins = "gpio0", "gpio1";
- drive-strength = <2>;
- bias-disable;
- };
};
};
--
2.15.0
Re: [PATCH V6 4/7] OF: properties: Implement get_match_data() callback
Hi, On Thu, 7 Dec 2017 09:45:31 -0500 Sinan Kaya wrote: > On 12/7/2017 8:10 AM, Lothar Waßmann wrote: > >> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode, > >> + struct device *dev) > > Shouldn't this be 'const void *of_fwnode_get_match_data > > OF keeps the driver data as a (const void*) internally. ACPI keeps the > driver data as kernel_ulong_t in struct acpi_device_id. > > I tried to find the middle ground here by converting output to void* > but not keeping const. > It should be no problem to cast a (const void *) to an unsigned long data type (without const qualifier). Lothar Waßmann
[PATCH v2 00/10] arm64: dts: qcom: dts improvements
The goal of this series was to add missing I2C bindings for BLSP_I2C1, BLSP_I2C3, and BLSP_I2C5. But while working on this, I noticed some styling issues and decided to tackle them in the same patchset, mostly because they touch the same files and the same people will be involved for the review. In this second version, I followed the recommandation of Bjorn Andersson and splitted pinmuxing and pinconf. The reason behind that is that the pinmuxing is common as functions cannot be routed to other pins, but pinconfs are board-specific. Damien Riegel (10): arm64: dts: qcom: pm8916: fix wcd_codec indentation arm64: dts: qcom: msm8916-pins: remove assignments to bias-disable arm64: dts: qcom: msm8916-pins: keep cdc_dmic pins in suspend mode arm64: dts: qcom: msm8916: drop unused board-specific nodes arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically arm64: dts: qcom: msm8916: move pinconfs to board files arm64: dts: qcom: msm8916: drop remaining unused pinconfs arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings arm64: dts: qcom: msm8916: normalize I2C and SPI nodes arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 446 - arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 17 ++ arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 393 - arch/arm64/boot/dts/qcom/msm8916.dtsi | 69 - arch/arm64/boot/dts/qcom/pm8916.dtsi | 82 +++--- 5 files changed, 604 insertions(+), 403 deletions(-) -- 2.15.0
[PATCH v2 01/10] arm64: dts: qcom: pm8916: fix wcd_codec indentation
Indentation did not respect kernel standards, so fix that for the usual
indent with tabs, align with spaces. While at it, remove some empty
lines before and after the closing parenthesis of this block.
Signed-off-by: Damien Riegel
Reviewed-by: Bjorn Andersson
---
Changes in v2:
- Added Reviewed-by Bjorn Andersson
arch/arm64/boot/dts/qcom/pm8916.dtsi | 82 ++--
1 file changed, 40 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/pm8916.dtsi
b/arch/arm64/boot/dts/qcom/pm8916.dtsi
index 53deebf9f515..d19f4cb9a5f3 100644
--- a/arch/arm64/boot/dts/qcom/pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8916.dtsi
@@ -96,47 +96,45 @@
#address-cells = <1>;
#size-cells = <0>;
-wcd_codec: codec@f000 {
- compatible = "qcom,pm8916-wcd-analog-codec";
- reg = <0xf000 0x200>;
- reg-names = "pmic-codec-core";
- clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
- clock-names = "mclk";
- interrupt-parent = <&spmi_bus>;
- interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
- interrupt-names = "cdc_spk_cnp_int",
-"cdc_spk_clip_int",
-"cdc_spk_ocp_int",
-"mbhc_ins_rem_det1",
-"mbhc_but_rel_det",
-"mbhc_but_press_det",
-"mbhc_ins_rem_det",
-"mbhc_switch_int",
-"cdc_ear_ocp_int",
-"cdc_hphr_ocp_int",
-"cdc_hphl_ocp_det",
-"cdc_ear_cnp_int",
-"cdc_hphr_cnp_int",
-"cdc_hphl_cnp_int";
- vdd-cdc-io-supply = <&pm8916_l5>;
- vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
- vdd-micbias-supply = <&pm8916_l13>;
- #sound-dai-cells = <1>;
-
-};
-
+ wcd_codec: codec@f000 {
+ compatible = "qcom,pm8916-wcd-analog-codec";
+ reg = <0xf000 0x200>;
+ reg-names = "pmic-codec-core";
+ clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "mclk";
+ interrupt-parent = <&spmi_bus>;
+ interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x1 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x2 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x3 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x4 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x5 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x6 IRQ_TYPE_NONE>,
+<0x1 0xf0 0x7 IRQ_TYPE_NONE>,
+<0x1 0xf1 0x0 IRQ_TYPE_NONE>,
+<0x1 0xf1 0x1 IRQ_TYPE_NONE>,
+<0x1 0xf1 0x2 IRQ_TYPE_NONE>,
+<0x1 0xf1 0x3 IRQ_TYPE_NONE>,
+<0x1 0xf1 0x4 IRQ_TYPE_NONE>,
+<0x1 0xf1 0x5 IRQ_TYPE_NONE>;
+ interrupt-names = "cdc_spk_cnp_int",
+ "cdc_spk_clip_int",
+ "cdc_spk_ocp_int",
+ "mbhc_ins_rem_det1",
+ "mbhc_but_rel_det",
+ "mbhc_but_press_det",
+ "mbhc_ins_rem_det",
+ "mbhc_switch_int",
+
Re: [PATCH] mm/huge_memory: fix comment in __split_huge_pmd_locked
On Thu, Dec 07, 2017 at 01:49:05PM +0800, Yisheng Xie wrote: > pmd_trans_splitting has been remove after THP refcounting redesign, > therefore related comment should be updated. > > Signed-off-by: Yisheng Xie Looks good to me. Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov
[PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes
The QUP core can be used either for I2C or SPI, so the same IP is mapped
by a driver or the other. SPI bindings use a leading 0 for the start
address and a size of 0x600, I2C bindings don't have the leading 0 and
have a size 0x1000.
To make them more similar, add the leading 0 to I2C bindings and changes
the size to 0x500 for all of them, as this is the actual size of these
blocks. Also align the second entry of the clocks array.
Signed-off-by: Damien Riegel
---
Changes in v2:
- Set size to 0x500
arch/arm64/boot/dts/qcom/msm8916.dtsi | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index e16ba8334518..ac440f287633 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -355,7 +355,7 @@
blsp_spi1: spi@78b5000 {
compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x078b5000 0x600>;
+ reg = <0x078b5000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -372,7 +372,7 @@
blsp_spi2: spi@78b6000 {
compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x078b6000 0x600>;
+ reg = <0x078b6000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -389,7 +389,7 @@
blsp_spi3: spi@78b7000 {
compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x078b7000 0x600>;
+ reg = <0x078b7000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_QUP3_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -406,7 +406,7 @@
blsp_spi4: spi@78b8000 {
compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x078b8000 0x600>;
+ reg = <0x078b8000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_QUP4_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -423,7 +423,7 @@
blsp_spi5: spi@78b9000 {
compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x078b9000 0x600>;
+ reg = <0x078b9000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_QUP5_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -440,7 +440,7 @@
blsp_spi6: spi@78ba000 {
compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x078ba000 0x600>;
+ reg = <0x078ba000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_QUP6_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -457,10 +457,10 @@
blsp_i2c2: i2c@78b6000 {
compatible = "qcom,i2c-qup-v2.2.1";
- reg = <0x78b6000 0x1000>;
+ reg = <0x078b6000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
- <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+<&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
clock-names = "iface", "core";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&i2c2_default>;
@@ -472,10 +472,10 @@
blsp_i2c4: i2c@78b8000 {
compatible = "qcom,i2c-qup-v2.2.1";
- reg = <0x78b8000 0x1000>;
+ reg = <0x078b8000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
- <&gcc GCC_BLSP1_QUP4_I2C_APPS_CLK>;
+<&gcc GCC_BLSP1_QUP4_I2C_APPS_CLK>;
clock-names = "iface", "core";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&i2c4_default>;
@@ -487,10 +487,10 @@
blsp_i2c6: i2c@78ba000 {
compatible = "qcom,i2c-qup-v2.2.1";
- reg = <0x78ba000 0x1000>;
+ reg = <0x078ba000 0x500>;
interrupts = ;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
- <&gcc GCC_BLSP1_QUP6_I2C_APPS_CLK>;
+<&gcc GCC_BLSP1_QUP6_I2C_APPS_CLK>;
clock-names = "iface", "core";
pinctrl-names =
