Re: [PATCH 1/3] Revert "clk: rockchip: mark noc and some special clk as critical on rk3288"
Hi,
On Tue, Apr 9, 2019 at 11:23 PM elaine.zhang wrote:
>
> hi,
>
> 在 2019/4/10 上午4:47, Douglas Anderson 写道:
> > This reverts commit 55bb6a633c33caf68ab470907ecf945289cb733d.
> >
> > The clocks that were enabled by that patch are pretty questionable.
> > Specifically looking at what has been shipping on rk3288-veyron
> > Chromebooks almost all of these clocks are safely turned off and cause
> > no apparent problems. If some boards need these clocks turned on for
> > some reason then it seems like we should figure out how to do that at
> > a board level.
> >
> > NOTE: turning these clocks off doesn't seem to do a whole lot in terms
> > of power savings (checking the power on the logic rail). It appears
> > to save maybe 1-2mW. ...but still it seems like we should turn the
> > clocks off if they aren't needed.
> >
> > Digging into the clocks here to describe why they shouldn't need to be
> > left on:
> >
> > atclk: No documentation about this clock other than that it goes to
> > the CPU. CPU functions fine without it on.
> >
> > jtag: Presumably this clock is only needed if you're debugging with
> > JTAG. It doesn't seem like it makes sense to waste power for every
> > rk3288 user. Perhaps this could be turned on with a CONFIG option?
> >
> > pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two
> > clocks on only during kernel panics in order to access some coresight
> > registers. Since nothing in the upstream kernel does this we should
> > be able to leave them off safely.
> >
> > hsicphy12m_xin12m: There is no indication of why this clock would need
> > to be turned on for boards that don't use HSIC.
> >
> > pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn
> > these 4 clocks on only when doing DDR transitions and they are off
> > otherwise. I see no reason why they'd need to be on in the upstream
> > kernel which doesn't support DDRFreq.
> >
> > pmu_hclk_otg0: A "chip design defect" is mentioned in the original
> > patch but no details. This clock has always been gated in shipping
> > veyron Chromebooks so presumably this chip defect doesn't affect all
> > boards.
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > drivers/clk/rockchip/clk-rk3288.c | 14 --
> > 1 file changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/clk/rockchip/clk-rk3288.c
> > b/drivers/clk/rockchip/clk-rk3288.c
> > index 5a67b7869960..06287810474e 100644
> > --- a/drivers/clk/rockchip/clk-rk3288.c
> > +++ b/drivers/clk/rockchip/clk-rk3288.c
> > @@ -313,13 +313,13 @@ static struct rockchip_clk_branch
> > rk3288_clk_branches[] __initdata = {
> > COMPOSITE_NOMUX(0, "aclk_core_mp", "armclk", CLK_IGNORE_UNUSED,
> > RK3288_CLKSEL_CON(0), 4, 4, DFLAGS |
> > CLK_DIVIDER_READ_ONLY,
> > RK3288_CLKGATE_CON(12), 6, GFLAGS),
> > - COMPOSITE_NOMUX(0, "atclk", "armclk", CLK_IGNORE_UNUSED,
> > + COMPOSITE_NOMUX(0, "atclk", "armclk", 0,
> > RK3288_CLKSEL_CON(37), 4, 5, DFLAGS |
> > CLK_DIVIDER_READ_ONLY,
> > RK3288_CLKGATE_CON(12), 7, GFLAGS),
> > COMPOSITE_NOMUX(0, "pclk_dbg_pre", "armclk", CLK_IGNORE_UNUSED,
> > RK3288_CLKSEL_CON(37), 9, 5, DFLAGS |
> > CLK_DIVIDER_READ_ONLY,
> > RK3288_CLKGATE_CON(12), 8, GFLAGS),
> > - GATE(0, "pclk_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED,
> > + GATE(0, "pclk_dbg", "pclk_dbg_pre", 0,
> > RK3288_CLKGATE_CON(12), 9, GFLAGS),
> > GATE(0, "cs_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED,
> > RK3288_CLKGATE_CON(12), 10, GFLAGS),
> > @@ -647,7 +647,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> > __initdata = {
> > INVERTER(SCLK_HSADC, "sclk_hsadc", "sclk_hsadc_out",
> > RK3288_CLKSEL_CON(22), 7, IFLAGS),
> >
> > - GATE(0, "jtag", "ext_jtag", CLK_IGNORE_UNUSED,
> > + GATE(0, "jtag", "ext_jtag", 0,
> > RK3288_CLKGATE_CON(4), 14, GFLAGS),
> CLK_IGNORE_UNUSED:
> Whether to close the unused clk after clk init complete. not affect
> there own enable/disable.
> JTAG is not have device node, when need jtag to debug, may be the system
> is crashed, there is no way to turn on this clk.
As I mentioned in the commit message this seems like the kind of thing
that should be controlled by a CONFIG_ option. It's a debug option
that's fine to have on all the time but consumes resources so some
people might want to turn it off.
> > COMPOSITE_NODIV(SCLK_USBPHY480M_SRC, "usbphy480m_src",
> > mux_usbphy480m_p, 0,
> > @@ -656,7 +656,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> > __initdata = {
> > COMPOSITE_NODIV(SCLK_HSICPHY480M, "sclk_hsicphy480m",
> > mux_hsicphy480m_p, 0,
> > RK3288_CLKSEL_CON(29), 0, 2, MFLAGS,
> > RK3288_CLKGATE_CON(3), 6, GFLAGS),
> > - GATE(0, "hsicphy12m_xin12m", "xin12m"
[PATCH v2] panic: add an option to replay all the printk message in buffer
Currently on panic, kernel will lower the loglevel and print out
new printk msg only with console_flush_on_panic().
Add an option for users to configure the "panic_print" to see
all dmesg in buffer, some of which they may have never seen due
to the loglevel setting, which will help debugging too.
Thanks to Petr Mladek as somes codes come directly from the sample
code in his review comments.
Signed-off-by: Feng Tang
---
Changelog:
v2:
- Add a new func in printk.c dedicated for the replaying, as
suggested by Petr Mladekand
- Combine the 2 patches in v1 into one suggested by both Petr
and Sergey
Documentation/admin-guide/kernel-parameters.txt | 1 +
include/linux/console.h | 1 +
kernel/panic.c | 5 +++
kernel/printk/printk.c | 46 -
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2b8ee90bb644..7b15c9442325 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3135,6 +3135,7 @@
bit 2: print timer info
bit 3: print locks info if CONFIG_LOCKDEP is on
bit 4: print ftrace buffer
+ bit 5: print all printk messages in buffer
panic_on_warn panic() instead of WARN(). Useful to cause kdump
on a WARN().
diff --git a/include/linux/console.h b/include/linux/console.h
index ec9bdb3d7bab..42f611a6b7ea 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -176,6 +176,7 @@ extern void console_unlock(void);
extern void console_conditional_schedule(void);
extern void console_unblank(void);
extern void console_flush_on_panic(void);
+extern void console_replay_on_panic(void);
extern struct tty_driver *console_device(int *);
extern void console_stop(struct console *);
extern void console_start(struct console *);
diff --git a/kernel/panic.c b/kernel/panic.c
index 0ae0d7332f12..5a3b7e302c8e 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -51,6 +51,7 @@ EXPORT_SYMBOL_GPL(panic_timeout);
#define PANIC_PRINT_TIMER_INFO 0x0004
#define PANIC_PRINT_LOCK_INFO 0x0008
#define PANIC_PRINT_FTRACE_INFO0x0010
+#define PANIC_PRINT_ALL_PRINTK_MSG 0x0020
unsigned long panic_print;
ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
@@ -134,6 +135,10 @@ EXPORT_SYMBOL(nmi_panic);
static void panic_print_sys_info(void)
{
+ /* Replay existing messages before adding other sys info. */
+ if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
+ console_replay_on_panic();
+
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02ca827b8fac..97aab099d22a 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -269,6 +269,9 @@ EXPORT_SYMBOL(console_set_on_cmdline);
/* Flag: console code may call schedule() */
static int console_may_schedule;
+/* Whether to print all messages in buffer */
+static int console_replay;
+
enum con_msg_format_flags {
MSG_FORMAT_DEFAULT = 0,
MSG_FORMAT_SYSLOG = (1 << 0),
@@ -2386,21 +2389,32 @@ void console_unlock(void)
for (;;) {
struct printk_log *msg;
+ int reset_idx = 0;
size_t ext_len = 0;
- size_t len;
+ size_t len = 0;
printk_safe_enter_irqsave(flags);
raw_spin_lock(&logbuf_lock);
+
if (console_seq < log_first_seq) {
len = sprintf(text,
"** %llu printk messages dropped **\n",
log_first_seq - console_seq);
/* messages are gone, move to first one */
+ reset_idx = 1;
+ }
+
+ if (console_replay) {
+ len += sprintf(text + len,
+ "Replaying the entire log:\n");
+ reset_idx = 1;
+ console_replay = 0;
+ }
+
+ if (reset_idx) {
console_seq = log_first_seq;
console_idx = log_first_idx;
- } else {
- len = 0;
}
skip:
if (console_seq == log_next_seq)
@@ -2523,12 +2537,7 @@ void console_unblank(void)
console_unlock();
}
-/**
- * console_flush_on_panic - flush console content on panic
- *
- * Immediately output all pending messages no matter what.
- */
-void console_flush_on_panic(void)
+static void __flush_on_panic(int replay)
{
/*
* If someone else is holding the console lock, trylock
[PATCH -next] PCI: mvebu: Make mvebu_pci_bridge_emul_ops static
From: YueHaibing
Fix sparse warning:
drivers/pci/controller/pci-mvebu.c:557:28: warning:
symbol 'mvebu_pci_bridge_emul_ops' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/pci/controller/pci-mvebu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c
b/drivers/pci/controller/pci-mvebu.c
index d3a0419..ed032e9 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -554,7 +554,7 @@ mvebu_pci_bridge_emul_pcie_conf_write(struct
pci_bridge_emul *bridge,
}
}
-struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
+static struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
.write_base = mvebu_pci_bridge_emul_base_conf_write,
.read_pcie = mvebu_pci_bridge_emul_pcie_conf_read,
.write_pcie = mvebu_pci_bridge_emul_pcie_conf_write,
--
2.7.4
[PATCH REBASED] mm: Throttle allocators when failing reclaim over memory.high
We're trying to use memory.high to limit workloads, but have found that containment can frequently fail completely and cause OOM situations outside of the cgroup. This happens especially with swap space -- either when none is configured, or swap is full. These failures often also don't have enough warning to allow one to react, whether for a human or for a daemon monitoring PSI. Here is output from a simple program showing how long it takes in μsec (column 2) to allocate a megabyte of anonymous memory (column 1) when a cgroup is already beyond its memory high setting, and no swap is available: [root@ktst ~]# systemd-run -p MemoryHigh=100M -p MemorySwapMax=1 \ > --wait -t timeout 300 /root/mdf [...] 95 1035 96 1038 97 1000 98 1036 99 1048 100 1590 101 1968 102 1776 103 1863 104 1757 105 1921 106 1893 107 1760 108 1748 109 1843 110 1716 111 1924 112 1776 113 1831 114 1766 115 1836 116 1588 117 1912 118 1802 119 1857 120 1731 [...] [System OOM in 2-3 seconds] The delay does go up extremely marginally past the 100MB memory.high threshold, as now we spend time scanning before returning to usermode, but it's nowhere near enough to contain growth. It also doesn't get worse the more pages you have, since it only considers nr_pages. The current situation goes against both the expectations of users of memory.high, and our intentions as cgroup v2 developers. In cgroup-v2.txt, we claim that we will throttle and only under "extreme conditions" will memory.high protection be breached. Likewise, cgroup v2 users generally also expect that memory.high should throttle workloads as they exceed their high threshold. However, as seen above, this isn't always how it works in practice -- even on banal setups like those with no swap, or where swap has become exhausted, we can end up with memory.high being breached and us having no weapons left in our arsenal to combat runaway growth with, since reclaim is futile. It's also hard for system monitoring software or users to tell how bad the situation is, as "high" events for the memcg may in some cases be benign, and in others be catastrophic. The current status quo is that we fail containment in a way that doesn't provide any advance warning that things are about to go horribly wrong (for example, we are about to invoke the kernel OOM killer). This patch introduces explicit throttling when reclaim is failing to keep memcg size contained at the memory.high setting. It does so by applying an exponential delay curve derived from the memcg's overage compared to memory.high. In the normal case where the memcg is either below or only marginally over its memory.high setting, no throttling will be performed. This composes well with system health monitoring and remediation, as these allocator delays are factored into PSI's memory pressure calculations. This both creates a mechanism system administrators or applications consuming the PSI interface to trivially see that the memcg in question is struggling and use that to make more reasonable decisions, and permits them enough time to act. Either of these can act with significantly more nuance than that we can provide using the system OOM killer. This is a similar idea to memory.oom_control in cgroup v1 which would put the cgroup to sleep if the threshold was violated, but it's also significantly improved as it results in visible memory pressure, and also doesn't schedule indefinitely, which previously made tracing and other introspection difficult. Contrast the previous results with a kernel with this patch: [root@ktst ~]# systemd-run -p MemoryHigh=100M -p MemorySwapMax=1 \ > --wait -t timeout 300 /root/mdf [...] 95 1002 96 1000 97 1002 98 1003 99 1000 100 1043 101 84724 102 330628 103 610511 104 1016265 105 1503969 106 2391692 107 2872061 108 3248003 109 4791904 110 5759832 111 6912509 112 8127818 113 9472203 114 12287622 115 12480079 116 14144008 117 15808029 118 16384500 119 16383242 120 16384979 [...] As you can see, in the normal case, memory allocation takes around 1000 μsec. However, as we exceed our memory.high, things start to increase exponentially, but fairly leniently at first. Our first megabyte over memory.high takes us 0.16 seconds, then the next is 0.46 seconds, then the next is almost an entire second. This gets worse until we reach our eventual 2*HZ clamp per batch, resulting in 16 seconds per megabyte. However, this is still making forward progress, so permits tracing or further analysis with programs like GDB. This patch expands on earlier work by Johannes Weiner. Thanks! Signed-off-by: Chris Down Cc: Andrew Morton Cc: Johannes Weiner Cc: Tejun Heo Cc: Roman Gushchin Cc: linux-kernel@vger.kernel.org Cc: cgro...@vger.kernel.org Cc: linux...@kvack.org Cc: ke
Re: [PATCH v3] platform: chrome: Add ChromeOS EC ISHTP driver
Reviewed-by: Jett Rink
Tested-by: Jett Rink
On Sun, Apr 7, 2019 at 6:10 AM Rushikesh S Kadam
wrote:
>
> This driver implements a slim layer to enable the ChromeOS
> EC kernel stack (cros_ec) to communicate with ChromeOS EC
> firmware running on the Intel Integrated Sensor Hub (ISH).
>
> The driver registers a ChromeOS EC MFD device to connect
> with cros_ec kernel stack (upper layer), and it registers a
> client with the ISH Transport Protocol bus (lower layer) to
> talk with the ISH firwmare. See description of the ISHTP
> protocol at Documentation/hid/intel-ish-hid.txt
>
> Signed-off-by: Rushikesh S Kadam
> ---
>
> v3
> - Made several changes to improve code readability. Replaced
>multiple cl_data_to_dev(client_data) with dev variable. Use
>reverse Xmas tree for variable defintion where it made sense.
>Dropped few debug prints. Add docstring for function
>prepare_cros_ec_rx().
> - Fix code in function prepare_cros_ec_rx() under label
>end_cros_ec_dev_init_error.
> - Recycle buffer in process_recv() on failing to obtain the
>semaphore.
> - Increase ISHTP TX/RX ring buffer size to 8.
> - Alphabetically ordered CROS_EC_ISHTP entries in Makefile and
>Kconfig.
> - Updated commit message.
>
> v2
> - Dropped unused "reset" parameter in function cros_ec_init()
> - Change driver name to cros_ec_ishtp to be consistent with other
>references in the code.
> - Fixed a few typos.
>
> v1
> - Initial version
>
> drivers/platform/chrome/Kconfig | 13 +
> drivers/platform/chrome/Makefile| 1 +
> drivers/platform/chrome/cros_ec_ishtp.c | 765
>
> 3 files changed, 779 insertions(+)
> create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c
>
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index 16b1615..5848179 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -62,6 +62,19 @@ config CROS_EC_I2C
> a checksum. Failing accesses will be retried three times to
> improve reliability.
>
> +config CROS_EC_ISHTP
> + tristate "ChromeOS Embedded Controller (ISHTP)"
> + depends on MFD_CROS_EC
> + depends on INTEL_ISH_HID
> + help
> + If you say Y here, you get support for talking to the ChromeOS EC
> + firmware running on Intel Integrated Sensor Hub (ISH), using the
> + ISH Transport protocol (ISH-TP). This uses a simple byte-level
> + protocol with a checksum.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec_ishtp.
> +
> config CROS_EC_SPI
> tristate "ChromeOS Embedded Controller (SPI)"
> depends on MFD_CROS_EC && SPI
> diff --git a/drivers/platform/chrome/Makefile
> b/drivers/platform/chrome/Makefile
> index cd591bf..4efe102 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -7,6 +7,7 @@ cros_ec_ctl-objs:= cros_ec_sysfs.o
> cros_ec_lightbar.o \
>cros_ec_vbc.o cros_ec_debugfs.o
> obj-$(CONFIG_CROS_EC_CTL) += cros_ec_ctl.o
> obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
> +obj-$(CONFIG_CROS_EC_ISHTP)+= cros_ec_ishtp.o
> obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
> cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o
> cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
> diff --git a/drivers/platform/chrome/cros_ec_ishtp.c
> b/drivers/platform/chrome/cros_ec_ishtp.c
> new file mode 100644
> index 000..b1d19c4
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_ec_ishtp.c
> @@ -0,0 +1,765 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ISHTP client driver for talking to the Chrome OS EC firmware running
> + * on Intel Integrated Sensor Hub (ISH) using the ISH Transport protocol
> + * (ISH-TP).
> + *
> + * Copyright (c) 2019, Intel Corporation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * ISH TX/RX ring buffer pool size
> + *
> + * The AP->ISH messages and corresponding ISH->AP responses are
> + * serialized. We need 1 TX and 1 RX buffer for these.
> + *
> + * The MKBP ISH->AP events are serialized. We need one additional RX
> + * buffer for them.
> + */
> +#define CROS_ISH_CL_TX_RING_SIZE 8
> +#define CROS_ISH_CL_RX_RING_SIZE 8
> +
> +/* ISH CrOS EC Host Commands */
> +enum cros_ec_ish_channel {
> + CROS_EC_COMMAND = 1,/* AP->ISH message */
> + CROS_MKBP_EVENT = 2,/* ISH->AP events */
> +};
> +
> +/*
> + * ISH firmware timeout for 1 message send failure is 1Hz, and the
> + * firmware will retry 2 times, so 3Hz is used for timeout.
> + */
> +#define ISHTP_SEND_TIMEOUT (3 * HZ)
> +
> +/* ISH Transport CrOS EC ISH client unique GUID *
Applied "spi: spi-mem: Make spi_mem_default_supports_op() static inline" to the spi tree
The patch
spi: spi-mem: Make spi_mem_default_supports_op() static inline
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d4a91044e241d8f87fb990b673549a7d2f9cacc4 Mon Sep 17 00:00:00 2001
From: YueHaibing
Date: Wed, 10 Apr 2019 21:18:28 +0800
Subject: [PATCH] spi: spi-mem: Make spi_mem_default_supports_op() static
inline
Stub helper spi_mem_default_supports_op() should
be set to static inline
Signed-off-by: YueHaibing
Signed-off-by: Mark Brown
---
include/linux/spi/spi-mem.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 1941b845aa15..af9ff2f0f1b2 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -315,6 +315,7 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller
*ctlr,
{
}
+static inline
bool spi_mem_default_supports_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
--
2.20.1
Re: [PATCH-tip v2 02/12] locking/rwsem: Implement lock handoff to prevent lock starvation
On 04/10/2019 11:10 AM, Peter Zijlstra wrote: > On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote: >> +#define RWSEM_WAIT_TIMEOUT ((HZ - 1)/200 + 1) > Given the choices in HZ, the above seems fairly 'optimistic'. I can tighten it up and make it less "optimistic" :-) Cheers, Longman
Re: [PATCH] PM / core: Propagate dev->power.wakeup_path when no callbacks
Hi Ulf
On 4/10/19 11:55 AM, Ulf Hansson wrote:
The dev->power.direct_complete flag may become set in device_prepare() in
case the device don't have any PM callbacks (dev->power.no_pm_callbacks is
set). This leads to a broken behaviour, when there is child having wakeup
enabled and relies on its parent to be used in the wakeup path.
More precisely, when the direct complete path becomes selected for the
child in __device_suspend(), the propagation of the dev->power.wakeup_path
becomes skipped as well.
Let's address this problem, by checking if the device is a part the wakeup
path or has wakeup enabled, then prevent the direct complete path from
being used.
Reported-by: Loic Pallardy
Signed-off-by: Ulf Hansson
---
Thanks Ulf for this patch. It'll avoid to have dirty hack in serial
suspend callback (at least for stm32). I just tested it on stm32 kernel
v4.19 (which embeds all our genpd based power features). Replacing
device_may_wakeup(dev) by
device_may_wakeup(dev) || dev->power.wakeup_path) then dirty hack to
test ttydev wakeup flag in stm32 usart driver is no more needed.
So you can add my Tested-by
Regards
Alex
More background:
This problem was reported by Loic Pallardy, offlist, while he was working
on enabling wakeup for a tty serial console driver.
When I looked more closely, I noticed that uart_suspend_port() calls
device_may_wakeup() for the tty child devices, and then also the used serial
driver check its device (parent) for device_may_wakeup(). To me this looks like
workarounds to fix a behaviour that really should be dealt with from the PM
core, no matter of whether the child have PM callbacks assigned or not.
In other words, it seems like the serial driver(s) should be checking the
wakeup_path flag for the parent, solely, instead.
I haven't digested further behaviours for other subsystem, but recently
reviewed a patch for a gpio driver [1], that seems to be suffering from the
similar problems.
Kind regards
Ulf Hansson
[1]
https://lkml.org/lkml/2019/4/4/1283
---
drivers/base/power/main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 41eba82ee7b9..f9cfdeee8288 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1747,6 +1747,10 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
if (dev->power.syscore)
goto Complete;
+ /* Avoid direct_complete, to let wakeup_path being propagated. */
+ if (device_may_wakeup(dev) || dev->power.wakeup_path)
+ dev->power.direct_complete = false;
+
if (dev->power.direct_complete) {
if (pm_runtime_status_suspended(dev)) {
pm_runtime_disable(dev);
Re: [PATCH-tip v2 02/12] locking/rwsem: Implement lock handoff to prevent lock starvation
On 04/10/2019 11:07 AM, Peter Zijlstra wrote: > On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote: >> Because of writer lock stealing, it is possible that a constant >> stream of incoming writers will cause a waiting writer or reader to >> wait indefinitely leading to lock starvation. >> >> The mutex code has a lock handoff mechanism to prevent lock starvation. >> This patch implements a similar lock handoff mechanism to disable >> lock stealing and force lock handoff to the first waiter in the queue >> after at least a 5ms waiting period. The waiting period is used to >> avoid discouraging lock stealing too much to affect performance. > So the mutex code doesn't have that timeout, it foces the handoff if the > top waiter fails to acquire. > > I don't find the above sufficiently justifies the additional complexity. > What were the numbers with the simple scheme vs this etc.. When the handoff bit is set, it stops the lock from being acquired by anyone else until the front waiter is woken up, scheduled and take the lock. Doing that too frequently will impede the throughput when the rwsem is highly contended. I can ran some performance test to show the difference it can make. I have also been thinking about having the front waiter set the handoff bit and then spin on owner so that it can acquire the lock immediately after it is freed. It will be a follow up patch. Cheers, Longman
Re: [PATCH 2/2] spi: pxa2xx: use a module softdep for dw_dmac
On Wed, Apr 10, 2019 at 02:05:38PM +, Flavio Suligoi wrote:
> Hi Mark,
> > While this isn't going to hurt anything and might actually help so it's
> > fine doesn't this also suggest that there's an issue with deferred probe
> > going on as well?
> I think that the problem could be related to how the DMA channel is requested.
> At the moment the function used are:
> pxa2xx_spi_dma_setup --> dma_request_slave_channel_compat -->
> --> __dma_request_slave_channel_compat --> dma_request_slave_channel -->
> --> dma_request_chan
> Actually the final function "dma_request_chan" return
> the channel number or "-EPROBE_DEFER" if it's not ready.
> But this information ("-EPROBE_DEFER") is lost in the penultimate function
> "dma_request_slave_channel", which return only the chann, if all is ok, or
> NULL, in case of errors.
> So the deferral mechanism is not used.
Right, yes - that analysis seems correct. The interfaces seem a bit
weird here but fixing them looks like the most complete and robust fix.
signature.asc
Description: PGP signature
[PATCH v2 03/12] software node: Add support for references
Introducing functions that can be used for adding and
removing references to other software nodes. The goal is to
support fwnode_property_get_reference_args() also with
software nodes, however, get_reference_args fwnode operation
callback is not yet implemented in this commit for the
software nodes. This commit will only add support for
reference addition/removal.
The next example shows how to add references to GPIOs using the
format described in Documentation/acpi/gpio-properties.txt:
/* Array with two GPIOs */
static struct fwnode_reference_args gpioargs[] __initdata = {
{
.nargs = 3,
.args[0]= 19, /* index */
.args[1]= 0, /* pin */
.args[2]= 0, /* active_low */
},
{
.nargs = 3,
.args[0]= 20, /* index */
.args[1]= 0, /* pin */
.args[2]= 0, /* active_low */
},
{ }
};
static int myinit(void)
{
struct software_node_reference *ref;
struct fwnode_handle *gpio_node;
struct fwnode_handle *my_node;
/* Creating the nodes */
gpio_node = fwnode_create_software_node(gpio_props, NULL);
...
my_node = fwnode_create_software_node(my_props, NULL);
...
/* gpio_node is associated with a GPIO/Pin controller in this example */
...
/* Assigning the actual node references */
gpioargs[0].fwnode = gpio_node;
gpioargs[1].fwnode = gpio_node;
/* my_node will now have a named ("gpios") reference to the two GPIOs */
ref = fwnode_create_software_node_reference(my_node, "gpios", gpioargs);
...
return 0;
}
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c| 101 +++
include/linux/property.h | 8
2 files changed, 109 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 7b321bf8424c..39b8f8f35cfe 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -11,10 +11,19 @@
#include
#include
+struct software_node_reference {
+ struct list_head list;
+ const char *name;
+ int nrefs;
+ struct fwnode_reference_args *args;
+};
+
struct software_node {
int id;
struct kobject kobj;
struct fwnode_handle fwnode;
+ struct list_head references;
+ struct mutex lock; /* node lock */
/* hierarchy */
struct ida child_ids;
@@ -598,9 +607,11 @@ fwnode_create_software_node(const struct property_entry
*properties,
swnode->kobj.kset = swnode_kset;
swnode->fwnode.ops = &software_node_ops;
+ mutex_init(&swnode->lock);
ida_init(&swnode->child_ids);
INIT_LIST_HEAD(&swnode->entry);
INIT_LIST_HEAD(&swnode->children);
+ INIT_LIST_HEAD(&swnode->references);
swnode->parent = p;
ret = kobject_init_and_add(&swnode->kobj, &software_node_type,
@@ -631,6 +642,11 @@ void fwnode_remove_software_node(struct fwnode_handle
*fwnode)
if (!swnode)
return;
+ mutex_lock(&swnode->lock);
+ WARN(!list_empty(&swnode->references),
+"\"%s\" has still references", kobject_name(&swnode->kobj));
+ mutex_unlock(&swnode->lock);
+
if (swnode->parent) {
ida_simple_remove(&swnode->parent->child_ids, swnode->id);
list_del(&swnode->entry);
@@ -642,6 +658,91 @@ void fwnode_remove_software_node(struct fwnode_handle
*fwnode)
}
EXPORT_SYMBOL_GPL(fwnode_remove_software_node);
+/**
+ * fwnode_create_software_node_reference - Create named reference description
+ * @fwnode: The software node to have the references
+ * @name: Name given to reference description
+ * @args: Zero terminated array of software node references with arguments
+ *
+ * Associates software nodes listed in @args with @fwnode. The association is
+ * named @name. The reference count is incremented for the nodes in @args.
+ *
+ * Returns pointer to software node reference description on success, or
ERR_PTR
+ * on failure.
+ */
+struct software_node_reference *
+fwnode_create_software_node_reference(const struct fwnode_handle *fwnode,
+ const char *name,
+ const struct fwnode_reference_args *args)
+{
+ struct software_node *swnode = to_software_node(fwnode);
+ struct software_node_reference *ref;
+ int n;
+
+ if (!swnode)
+ return ERR_PTR(-EINVAL);
+
+ for (n = 0; args[n].fwnode; n++)
+ if (!is_software_node(args[n].fwnode))
+ return ERR_PTR(-EINVAL);
+
+ ref = kzalloc(sizeof(*ref), GFP_KERNEL);
+ if (!ref)
+ return ERR_PTR(-ENOMEM);
+
+ ref->nrefs = n;
+
+ ref->name = kstrdup(name, GFP_KERNEL);
+ if (!ref->name) {
+ kfree(ref);
+ return ERR_PTR(-ENOMEM);
+ }
+
Re: [PATCH 21/21] docs: hwmon: Add an index file and rename docs to *.rst
Hello, On Wed, Apr 10, 2019 at 08:12:11AM -0300, Mauro Carvalho Chehab wrote: > Now that all files were converted to ReST format, rename them > and add an index. > > Signed-off-by: Mauro Carvalho Chehab > --- [...] > diff --git a/Documentation/hwmon/submitting-patches > b/Documentation/hwmon/submitting-patches.rst > similarity index 99% > rename from Documentation/hwmon/submitting-patches > rename to Documentation/hwmon/submitting-patches.rst > index 12540b7d9b50..6120db7556aa 100644 > --- a/Documentation/hwmon/submitting-patches > +++ b/Documentation/hwmon/submitting-patches.rst I'd additionally suggest: diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches.rst index f88221b46153..a86be4b9 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches.rst @@ -38,7 +38,7 @@ increase the chances of your change being accepted. 2. Adding functionality to existing drivers --- -* Make sure the documentation in Documentation/hwmon/ is up to +* Make sure the documentation in Documentation/hwmon/.rst is up to date. * Make sure the information in Kconfig is up to date. @@ -60,7 +60,7 @@ increase the chances of your change being accepted. * Consider adding yourself to MAINTAINERS. -* Document the driver in Documentation/hwmon/. +* Document the driver in Documentation/hwmon/.rst. * Add the driver to Kconfig and Makefile in alphabetical order. Thanks, Jonathan Neuschäfer signature.asc Description: PGP signature
[PATCH v2 09/12] platform/x86: intel_cht_int33fe: Provide software nodes for the devices
Software nodes provide two features that we will need later.
1) Software nodes can have references to other software nodes.
2) Software nodes can exist before a device entry is created.
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 124 +--
1 file changed, 93 insertions(+), 31 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 657b8d61554c..a9abc77fffa7 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -21,18 +21,28 @@
#include
#include
#include
+#include
#include
#include
#include
#define EXPECTED_PTYPE 4
+enum {
+ INT33FE_NODE_FUSB302,
+ INT33FE_NODE_MAX17047,
+ INT33FE_NODE_PI3USB30532,
+ INT33FE_NODE_MAX,
+};
+
struct cht_int33fe_data {
struct i2c_client *max17047;
struct i2c_client *fusb302;
struct i2c_client *pi3usb30532;
/* Contain a list-head must be per device */
struct device_connection connections[4];
+
+ struct fwnode_handle *node[INT33FE_NODE_MAX];
};
/*
@@ -63,14 +73,6 @@ static int cht_int33fe_check_for_max17047(struct device
*dev, void *data)
return 1;
}
-static struct i2c_client *cht_int33fe_find_max17047(void)
-{
- struct i2c_client *max17047 = NULL;
-
- i2c_for_each_dev(&max17047, cht_int33fe_check_for_max17047);
- return max17047;
-}
-
static const char * const max17047_suppliers[] = { "bq24190-charger" };
static const struct property_entry max17047_props[] = {
@@ -78,6 +80,36 @@ static const struct property_entry max17047_props[] = {
{ }
};
+static int
+cht_int33fe_find_max17047(struct device *dev, struct cht_int33fe_data *data)
+{
+ struct fwnode_handle *fwnode = data->node[INT33FE_NODE_MAX17047];
+ struct i2c_client *max17047 = NULL;
+ struct i2c_board_info board_info;
+ int ret;
+
+ i2c_for_each_dev(&max17047, cht_int33fe_check_for_max17047);
+ if (max17047) {
+ /* Pre-existing i2c-client for the max17047, add device-props */
+ max17047->dev.fwnode->secondary = fwnode;
+ /* And re-probe to get the new device-props applied. */
+ ret = device_reprobe(&max17047->dev);
+ if (ret)
+ dev_warn(dev, "Reprobing max17047 error: %d\n", ret);
+ return 0;
+ }
+
+ memset(&board_info, 0, sizeof(board_info));
+ strlcpy(board_info.type, "max17047", I2C_NAME_SIZE);
+ board_info.dev_name = "max17047";
+ board_info.fwnode = fwnode;
+ data->max17047 = i2c_acpi_new_device(dev, 1, &board_info);
+ if (IS_ERR(data->max17047))
+ return PTR_ERR(data->max17047);
+
+ return 0;
+}
+
static const struct property_entry fusb302_props[] = {
PROPERTY_ENTRY_STRING("linux,extcon-name", "cht_wcove_pwrsrc"),
PROPERTY_ENTRY_U32("fcs,max-sink-microvolt", 1200),
@@ -86,12 +118,50 @@ static const struct property_entry fusb302_props[] = {
{ }
};
+static const struct property_entry *props[] = {
+ [INT33FE_NODE_FUSB302] = fusb302_props,
+ [INT33FE_NODE_MAX17047] = max17047_props,
+ [INT33FE_NODE_PI3USB30532] = NULL,
+};
+
+static void cht_int33fe_remove_nodes(struct cht_int33fe_data *data)
+{
+ int i;
+
+ for (i = 0; i < INT33FE_NODE_MAX; i++) {
+ fwnode_remove_software_node(data->node[i]);
+ data->node[i] = NULL;
+ }
+}
+
+static int cht_int33fe_add_nodes(struct cht_int33fe_data *data)
+{
+ struct fwnode_handle *fwnode;
+ int ret;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(props); i++) {
+ fwnode = fwnode_create_software_node(props[i], NULL);
+ if (IS_ERR(fwnode)) {
+ ret = PTR_ERR(fwnode);
+ goto err_remove_nodes;
+ }
+ data->node[i] = fwnode;
+ }
+
+ return 0;
+
+err_remove_nodes:
+ cht_int33fe_remove_nodes(data);
+
+ return ret;
+}
+
static int cht_int33fe_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct i2c_board_info board_info;
struct cht_int33fe_data *data;
- struct i2c_client *max17047;
struct regulator *regulator;
unsigned long long ptyp;
acpi_status status;
@@ -151,26 +221,14 @@ static int cht_int33fe_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
- /* Work around BIOS bug, see comment on cht_int33fe_find_max17047 */
- max17047 = cht_int33fe_find_max17047();
- if (max17047) {
- /* Pre-existing i2c-client for the max17047, add device-props */
- ret = device_add_properties(&max17047->dev, max17047_props);
- if (ret)
- return ret;
-
Re: [PATCH 2/3] clk: rockchip: Make rkpwm a critical clock on rk3288
Hi,
On Tue, Apr 9, 2019 at 11:42 PM elaine.zhang wrote:
>
> hi,
>
> 在 2019/4/10 上午4:47, Douglas Anderson 写道:
> > Most rk3288-based boards are derived from the EVB and thus use a PWM
> > regulator for the logic rail. However, most rk3288-based boards don't
> > specify the PWM regulator in their device tree. We'll deal with that
> > by making it critical.
> >
> > NOTE: it's important to make it critical and not just IGNORE_UNUSED
> > because all PWMs in the system share the same clock. We don't want
> > another PWM user to turn the clock on and off and kill the logic rail.
> >
> > This change is in preparation for actually having the PWMs in the
> > rk3288 device tree actually point to the proper PWM clock. Up until
> > now they've all pointed to the clock for the old IP block and they've
> > all worked due to the fact that rkpwm was IGNORE_UNUSED and that the
> > clock rates for both clocks were the same.
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > drivers/clk/rockchip/clk-rk3288.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/rockchip/clk-rk3288.c
> > b/drivers/clk/rockchip/clk-rk3288.c
> > index 06287810474e..c3321eade23e 100644
> > --- a/drivers/clk/rockchip/clk-rk3288.c
> > +++ b/drivers/clk/rockchip/clk-rk3288.c
> > @@ -697,7 +697,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> > __initdata = {
> > GATE(PCLK_TZPC, "pclk_tzpc", "pclk_cpu", 0, RK3288_CLKGATE_CON(11),
> > 3, GFLAGS),
> > GATE(PCLK_UART2, "pclk_uart2", "pclk_cpu", 0, RK3288_CLKGATE_CON(11),
> > 9, GFLAGS),
> > GATE(PCLK_EFUSE256, "pclk_efuse_256", "pclk_cpu", 0,
> > RK3288_CLKGATE_CON(11), 10, GFLAGS),
> > - GATE(PCLK_RKPWM, "pclk_rkpwm", "pclk_cpu", CLK_IGNORE_UNUSED,
> > RK3288_CLKGATE_CON(11), 11, GFLAGS),
> > + GATE(PCLK_RKPWM, "pclk_rkpwm", "pclk_cpu", 0, RK3288_CLKGATE_CON(11),
> > 11, GFLAGS),
> >
> > /* ddrctrl [DDR Controller PHY clock] gates */
> > GATE(0, "nclk_ddrupctl0", "ddrphy", CLK_IGNORE_UNUSED,
> > RK3288_CLKGATE_CON(11), 4, GFLAGS),
> > @@ -837,6 +837,7 @@ static const char *const rk3288_critical_clocks[]
> > __initconst = {
> > "pclk_alive_niu",
> > "pclk_pd_pmu",
> > "pclk_pmu_niu",
> > + "pclk_rkpwm",
>
> pwm have device node, can enable and disable it in the pwm drivers.
>
> pwm regulator use pwm node as:
>
> pwms = <&pwm2 0 25000 1>
>
> when set Logic voltage:
>
> pwm_regulator_set_voltage()
>
> --> pwm_apply_state()
>
> -->clk_enable()
>
> -->pwm_enable()
>
> -->pwm_config()
>
> -->pinctrl_select()
>
> --
>
> For mark pclk_rkpwm as critical,do you have any questions, or provides
> some log or more information.
Right, if we actually specify the PWM used for the PWM regulator in
the device tree then there is no need to mark it as a critical clock.
In fact rk3288-veyron devices boot absolutely fine without marking
this clock as critical. Actually, it seems like the way the PWM
framework works (IIRC it was designed this way specifically to support
PWM regulators) is that even just specifying that pwm1 is "okay" is
enough to keep the clock on even if the PWM regulator isn't specified.
...however...
Take a look at, for instance, the rk3288-evb device tree file.
Nowhere in there does it specify that the PWM used for the PWM
regulator should be on. Presumably that means that if we don't mark
the clock as critical then rk3288-evb will fail to boot. That's easy
for me to fix since I have the rk3288-evb schematics, but what about
other rk3288 boards? We could make educated guesses about each of
them and/or fix things are we hear about breakages.
...but...
All the above would only be worth doing if we thought someone would
get some benefit out of it. I'd bet that pretty much all rk3288-based
boards use a PWM regulator. Thus, in reality, everyone will want the
rkpwm clock on all the time anyway. In that case going through all
that extra work / potentially breaking other boards doesn't seem worth
it. Just mark the clock as critical.
-Doug
[PATCH v2 11/12] platform/x86: intel_cht_int33fe: Link with external dependencies using fwnodes
Supplying also external devices - the DisplayPort connector
and the USB role switch - software fwnodes. After this the
driver has access to all the components tied to the USB
Type-C connector and can start creating software node
references to actually associate them with the USB Type-C
connector device.
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 92
1 file changed, 92 insertions(+)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 0707afd39ca5..0687aa23fcfe 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -33,6 +33,8 @@ enum {
INT33FE_NODE_FUSB302,
INT33FE_NODE_MAX17047,
INT33FE_NODE_PI3USB30532,
+ INT33FE_NODE_DISPLAYPORT,
+ INT33FE_NODE_ROLE_SWITCH,
INT33FE_NODE_USB_CONNECTOR,
INT33FE_NODE_MAX,
};
@@ -44,6 +46,7 @@ struct cht_int33fe_data {
/* Contain a list-head must be per device */
struct device_connection connections[4];
+ struct fwnode_handle *dp;
struct fwnode_handle *node[INT33FE_NODE_MAX];
};
@@ -144,8 +147,71 @@ static const struct property_entry *props[] = {
[INT33FE_NODE_FUSB302] = fusb302_props,
[INT33FE_NODE_MAX17047] = max17047_props,
[INT33FE_NODE_PI3USB30532] = NULL,
+ [INT33FE_NODE_DISPLAYPORT] = NULL,
+ [INT33FE_NODE_ROLE_SWITCH] = NULL,
};
+static int cht_int33fe_setup_mux(struct cht_int33fe_data *data)
+{
+ struct fwnode_handle *fwnode = data->node[INT33FE_NODE_ROLE_SWITCH];
+ struct pci_dev *pdev;
+ struct device *dev;
+ struct device *p;
+
+ /* First let's find xHCI PCI device */
+ pdev = pci_get_class(PCI_CLASS_SERIAL_USB_XHCI, NULL);
+ if (!pdev || (pdev->vendor != PCI_VENDOR_ID_INTEL))
+ return -ENODEV;
+
+ /* Then the child platform device */
+ p = device_find_child_by_name(&pdev->dev, "intel_xhci_usb_sw");
+ pci_dev_put(pdev);
+ if (!p)
+ return -EPROBE_DEFER;
+
+ /* Finally the mux device */
+ dev = device_find_child_by_name(p, "intel_xhci_usb_sw-role-switch");
+ put_device(p);
+ if (!dev)
+ return -EPROBE_DEFER;
+
+ /* If there already is a node for the mux, using that one. */
+ if (dev->fwnode) {
+ fwnode_handle_get(dev->fwnode);
+ fwnode_remove_software_node(fwnode);
+ data->node[INT33FE_NODE_ROLE_SWITCH] = dev->fwnode;
+ } else {
+ /* The node can be tied to the lifetime of the device. */
+ dev->fwnode = fwnode_handle_get(dev->fwnode);
+ }
+
+ put_device(dev);
+
+ return 0;
+}
+
+static int cht_int33fe_setup_dp(struct cht_int33fe_data *data)
+{
+ struct fwnode_handle *fwnode = data->node[INT33FE_NODE_DISPLAYPORT];
+ struct pci_dev *pdev;
+
+ /* First let's find the GPU PCI device */
+ pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, NULL);
+ if (!pdev || (pdev->vendor != PCI_VENDOR_ID_INTEL))
+ return -ENODEV;
+
+ /* Then the DP child device node */
+ data->dp = device_get_named_child_node(&pdev->dev, "DD02");
+ pci_dev_put(pdev);
+ if (!data->dp)
+ return -ENODEV;
+
+ fwnode->secondary = ERR_PTR(-ENODEV);
+ data->dp->secondary = fwnode;
+
+ return 0;
+}
+
static void cht_int33fe_remove_nodes(struct cht_int33fe_data *data)
{
int i;
@@ -154,6 +220,12 @@ static void cht_int33fe_remove_nodes(struct
cht_int33fe_data *data)
fwnode_remove_software_node(data->node[i]);
data->node[i] = NULL;
}
+
+ if (data->dp) {
+ data->dp->secondary = NULL;
+ fwnode_handle_put(data->dp);
+ data->dp = NULL;
+ }
}
static int cht_int33fe_add_nodes(struct cht_int33fe_data *data)
@@ -180,6 +252,26 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data
*data)
}
data->node[INT33FE_NODE_USB_CONNECTOR] = fwnode;
+ /* The devices that are not created in this driver need extra steps. */
+
+ /*
+* There is no ACPI device node for the USB role mux, so we need to find
+* the mux device and assign our node directly to it. That means we
+* depend on the mux driver. This function will return -PROBE_DEFER
+* until the mux device is registered.
+*/
+ ret = cht_int33fe_setup_mux(data);
+ if (ret)
+ goto err_remove_nodes;
+
+ /*
+* The DP connector does have ACPI device node. In this case we can just
+* find that ACPI node and assing our node as the secondary node to it.
+*/
+ ret = cht_int33fe_setup_dp(data);
+ if (ret)
+ goto err_remove_nodes;
+
return 0;
err_remove_nodes:
--
2.20.1
[PATCH v2 12/12] platform/x86: intel_cht_int33fe: Replacing the old connections with references
Now that the software nodes support references, and the
device connection API support parsing fwnode references,
replacing the old connection descriptions with software node
references. Relying on device names when matching the
connection would not have been possible to link the USB
Type-C connector and the DisplayPort connector together, but
with real references it's not problem.
The DisplayPort ACPI node is dag up, and the drivers own
software node for the DisplayPort is set as the secondary
node for it. The USB Type-C connector refers the software
node, but it is now tied to the ACPI node, and therefore any
device entry (struct drm_connector in practice) that the
node combo is assigned to.
The USB role switch device does not have ACPI node, so we
have to wait for the device to appear. Then we can simply
assign our software node for the to the device.
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 94 +++-
1 file changed, 77 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 0687aa23fcfe..8d9f890ec000 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -39,15 +39,22 @@ enum {
INT33FE_NODE_MAX,
};
+enum {
+ INT33FE_REF_ORIENTATION,
+ INT33FE_REF_MODE_MUX,
+ INT33FE_REF_DISPLAYPORT,
+ INT33FE_REF_ROLE_SWITCH,
+ INT33FE_REF_MAX,
+};
+
struct cht_int33fe_data {
struct i2c_client *max17047;
struct i2c_client *fusb302;
struct i2c_client *pi3usb30532;
- /* Contain a list-head must be per device */
- struct device_connection connections[4];
struct fwnode_handle *dp;
struct fwnode_handle *node[INT33FE_NODE_MAX];
+ struct software_node_reference *ref[INT33FE_REF_MAX];
};
/*
@@ -280,6 +287,65 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data
*data)
return ret;
}
+static void cht_int33fe_remove_references(struct cht_int33fe_data *data)
+{
+ int i;
+
+ for (i = 0; i < INT33FE_REF_MAX; i++)
+ fwnode_remove_software_node_reference(data->ref[i]);
+}
+
+static int cht_int33fe_add_references(struct cht_int33fe_data *data)
+{
+ struct fwnode_reference_args args[2] = { };
+ struct software_node_reference *ref;
+ struct fwnode_handle *con;
+
+ con = data->node[INT33FE_NODE_USB_CONNECTOR];
+
+ /* USB Type-C muxes */
+ args[0].fwnode = data->node[INT33FE_NODE_PI3USB30532];
+ args[1].fwnode = NULL;
+
+ ref = fwnode_create_software_node_reference(con, "orientation-switch",
+ args);
+ if (IS_ERR(ref))
+ return PTR_ERR(ref);
+ data->ref[INT33FE_REF_ORIENTATION] = ref;
+
+ ref = fwnode_create_software_node_reference(con, "mode-switch", args);
+ if (IS_ERR(ref)) {
+ cht_int33fe_remove_references(data);
+ return PTR_ERR(ref);
+ }
+ data->ref[INT33FE_REF_MODE_MUX] = ref;
+
+ /* USB role switch */
+ args[0].fwnode = data->node[INT33FE_NODE_ROLE_SWITCH];
+ args[1].fwnode = NULL;
+
+ ref = fwnode_create_software_node_reference(con, "usb-role-switch",
+ args);
+ if (IS_ERR(ref)) {
+ cht_int33fe_remove_references(data);
+ return PTR_ERR(ref);
+ }
+ data->ref[INT33FE_REF_ROLE_SWITCH] = ref;
+
+ /* DisplayPort */
+ args[0].fwnode = data->node[INT33FE_NODE_DISPLAYPORT];
+ args[1].fwnode = NULL;
+
+ ref = fwnode_create_software_node_reference(con, "displayport", args);
+ if (IS_ERR(ref)) {
+ cht_int33fe_remove_references(data);
+ return PTR_ERR(ref);
+ }
+ data->ref[INT33FE_REF_DISPLAYPORT] = ref;
+
+ return 0;
+}
+
static int cht_int33fe_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -348,22 +414,14 @@ static int cht_int33fe_probe(struct platform_device *pdev)
if (ret)
return ret;
- /* Work around BIOS bug, see comment on cht_int33fe_check_for_max17047
*/
- ret = cht_int33fe_find_max17047(dev, data);
+ ret = cht_int33fe_add_references(data);
if (ret)
goto out_remove_nodes;
- data->connections[0].endpoint[0] = "port0";
- data->connections[0].endpoint[1] = "i2c-pi3usb30532-switch";
- data->connections[0].id = "orientation-switch";
- data->connections[1].endpoint[0] = "port0";
- data->connections[1].endpoint[1] = "i2c-pi3usb30532-mux";
- data->connections[1].id = "mode-switch";
- data->connections[2].endpoint[0] = "i2c-fusb302";
- data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
- data->connections[2].id = "usb-role-switch";
-
- device_connections_add(data-
[PATCH v2 10/12] platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector
In ACPI, and now also in DT, the USB connectors usually have
their own device nodes. In case of USB Type-C, those
connector (port) nodes are child nodes of the controller or
PHY device, in our case the fusb302. The software fwnodes
allow us to create a similar child node for fusb302 that
represents the connector also on Intel CHT.
This makes it possible replace the fusb302 specific device
properties which were deprecated with the common USB
connector properties that tcpm.c is able to use directly.
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 37 ++--
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index a9abc77fffa7..0707afd39ca5 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#define EXPECTED_PTYPE 4
@@ -32,6 +33,7 @@ enum {
INT33FE_NODE_FUSB302,
INT33FE_NODE_MAX17047,
INT33FE_NODE_PI3USB30532,
+ INT33FE_NODE_USB_CONNECTOR,
INT33FE_NODE_MAX,
};
@@ -112,9 +114,29 @@ cht_int33fe_find_max17047(struct device *dev, struct
cht_int33fe_data *data)
static const struct property_entry fusb302_props[] = {
PROPERTY_ENTRY_STRING("linux,extcon-name", "cht_wcove_pwrsrc"),
- PROPERTY_ENTRY_U32("fcs,max-sink-microvolt", 1200),
- PROPERTY_ENTRY_U32("fcs,max-sink-microamp", 300),
- PROPERTY_ENTRY_U32("fcs,max-sink-microwatt", 3600),
+ { }
+};
+
+#define PDO_FIXED_FLAGS \
+ (PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP | PDO_FIXED_USB_COMM)
+
+static const u32 src_pdo[] = {
+ PDO_FIXED(5000, 1500, PDO_FIXED_FLAGS),
+};
+
+static const u32 snk_pdo[] = {
+ PDO_FIXED(5000, 400, PDO_FIXED_FLAGS),
+ PDO_VAR(5000, 12000, 3000),
+};
+
+static const struct property_entry usb_connector_props[] = {
+ PROPERTY_ENTRY_STRING("name", "connector"),
+ PROPERTY_ENTRY_STRING("data-role", "dual"),
+ PROPERTY_ENTRY_STRING("power-role", "dual"),
+ PROPERTY_ENTRY_STRING("try-power-role", "sink"),
+ PROPERTY_ENTRY_U32_ARRAY("source-pdos", src_pdo),
+ PROPERTY_ENTRY_U32_ARRAY("sink-pdos", snk_pdo),
+ PROPERTY_ENTRY_U32("op-sink-microwatt", 3600),
{ }
};
@@ -149,6 +171,15 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data
*data)
data->node[i] = fwnode;
}
+ /* Node for the USB connector (FUSB302 is the parent) */
+ fwnode = fwnode_create_software_node(usb_connector_props,
+data->node[INT33FE_NODE_FUSB302]);
+ if (IS_ERR(fwnode)) {
+ ret = PTR_ERR(fwnode);
+ goto err_remove_nodes;
+ }
+ data->node[INT33FE_NODE_USB_CONNECTOR] = fwnode;
+
return 0;
err_remove_nodes:
--
2.20.1
[PATCH v2 05/12] driver core: Add helper device_find_child_by_name()
It looks like the child device is often matched with a name.
This introduces a helper that does it automatically.
Signed-off-by: Heikki Krogerus
---
drivers/base/core.c| 31 +++
include/linux/device.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4aeaa0c92bda..5819ba4c9d4c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2469,6 +2469,37 @@ struct device *device_find_child(struct device *parent,
void *data,
}
EXPORT_SYMBOL_GPL(device_find_child);
+/**
+ * device_find_child_by_name - device iterator for locating a child device.
+ * @parent: parent struct device
+ * @name: name of the child device
+ *
+ * This is similar to the device_find_child() function above, but it
+ * returns a reference to a device that has the name @name.
+ *
+ * The callback should return NULL if the child is not found and a reference to
+ * the child device if it is found.
+ *
+ * NOTE: you will need to drop the reference with put_device() after use.
+ */
+struct device *device_find_child_by_name(struct device *parent,
+const char *name)
+{
+ struct klist_iter i;
+ struct device *child;
+
+ if (!parent)
+ return NULL;
+
+ klist_iter_init(&parent->p->klist_children, &i);
+ while ((child = next_device(&i)))
+ if (!strcmp(dev_name(child), name) && get_device(child))
+ break;
+ klist_iter_exit(&i);
+ return child;
+}
+EXPORT_SYMBOL_GPL(device_find_child_by_name);
+
int __init devices_init(void)
{
devices_kset = kset_create_and_add("devices", &device_uevent_ops, NULL);
diff --git a/include/linux/device.h b/include/linux/device.h
index 4457e560bc2b..fadb84dd07f9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1250,6 +1250,8 @@ extern int device_for_each_child_reverse(struct device
*dev, void *data,
int (*fn)(struct device *dev, void *data));
extern struct device *device_find_child(struct device *dev, void *data,
int (*match)(struct device *dev, void *data));
+extern struct device *device_find_child_by_name(struct device *parent,
+ const char *name);
extern int device_rename(struct device *dev, const char *new_name);
extern int device_move(struct device *dev, struct device *new_parent,
enum dpm_order dpm_order);
--
2.20.1
[PATCH v2 07/12] device connection: Find connections also by checking the references
We can also use this API to find named references that the
device nodes have by using fwnode_property_get_reference_args()
function.
Signed-off-by: Heikki Krogerus
---
drivers/base/devcon.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index 04db9ae235e4..4cdf95532b63 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -38,6 +38,30 @@ fwnode_graph_devcon_match(struct fwnode_handle *fwnode,
const char *con_id,
return NULL;
}
+static void *
+fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
+ void *data, devcon_match_fn_t match)
+{
+ struct device_connection con = { };
+ struct fwnode_reference_args args;
+ void *ret;
+ int i;
+
+ for (i = 0; ; i++) {
+ if (fwnode_property_get_reference_args(fwnode, con_id, NULL, 0,
+ i, &args))
+ break;
+
+ con.fwnode = args.fwnode;
+ ret = match(&con, -1, data);
+ fwnode_handle_put(args.fwnode);
+ if (ret)
+ return ret;
+ }
+
+ return NULL;
+}
+
/**
* device_connection_find_match - Find physical connection to a device
* @dev: Device with the connection
@@ -65,6 +89,10 @@ void *device_connection_find_match(struct device *dev, const
char *con_id,
ret = fwnode_graph_devcon_match(fwnode, con_id, data, match);
if (ret)
return ret;
+
+ ret = fwnode_devcon_match(fwnode, con_id, data, match);
+ if (ret)
+ return ret;
}
mutex_lock(&devcon_lock);
--
2.20.1
[PATCH v2 06/12] ACPI / property: Don't limit named child node matching to data nodes
There is no reason why we should limit the use of
fwnode_get_named_child_node() to data nodes only.
Signed-off-by: Heikki Krogerus
---
drivers/acpi/property.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 77abe0ec4043..c3fb52c387a6 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -602,15 +602,29 @@ static struct fwnode_handle *
acpi_fwnode_get_named_child_node(const struct fwnode_handle *fwnode,
const char *childname)
{
+ char name[ACPI_PATH_SEGMENT_LENGTH];
struct fwnode_handle *child;
+ struct acpi_buffer path;
+ acpi_status status;
- /*
-* Find first matching named child node of this fwnode.
-* For ACPI this will be a data only sub-node.
-*/
- fwnode_for_each_child_node(fwnode, child)
- if (acpi_data_node_match(child, childname))
+ path.length = sizeof(name);
+ path.pointer = name;
+
+ fwnode_for_each_child_node(fwnode, child) {
+ if (is_acpi_data_node(child)) {
+ if (acpi_data_node_match(child, childname))
+ return child;
+ continue;
+ }
+
+ status = acpi_get_name(ACPI_HANDLE_FWNODE(child),
+ ACPI_SINGLE_NAME, &path);
+ if (ACPI_FAILURE(status))
+ break;
+
+ if (!strncmp(name, childname, ACPI_NAME_SIZE))
return child;
+ }
return NULL;
}
--
2.20.1
[PATCH v2 08/12] usb: typec: Registering real device entries for the muxes
Registering real device entries (struct device) for the mode
muxes as well as for the orientation switches.
The Type-C mux code was deliberately attempting to avoid
creation of separate device entries for the orientation
switch and the mode switch (alternate modes) because they
are not physical devices. They are functions of a single
physical multiplexer/demultiplexer switch device.
Unfortunately because of the dependency we still have on the
underlying mux device driver, we had to put in hacks like
the one in the commit 3e3b81965cbf ("usb: typec: mux: Take
care of driver module reference counting") to make sure the
driver does not disappear from underneath us. Even with
those hacks we were still left with a potential NUll pointer
dereference scenario, so just creating the device entries,
and letting the core take care of the dependencies. No more
hacks needed.
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 4 +-
drivers/usb/typec/bus.h | 15 ++
drivers/usb/typec/class.c| 17 +-
drivers/usb/typec/mux.c | 221 ---
drivers/usb/typec/mux/pi3usb30532.c | 46 +++--
include/linux/usb/typec_mux.h| 62 +++
6 files changed, 242 insertions(+), 123 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 6fa3cced6f8e..657b8d61554c 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -173,10 +173,10 @@ static int cht_int33fe_probe(struct platform_device *pdev)
}
data->connections[0].endpoint[0] = "port0";
- data->connections[0].endpoint[1] = "i2c-pi3usb30532";
+ data->connections[0].endpoint[1] = "i2c-pi3usb30532-switch";
data->connections[0].id = "orientation-switch";
data->connections[1].endpoint[0] = "port0";
- data->connections[1].endpoint[1] = "i2c-pi3usb30532";
+ data->connections[1].endpoint[1] = "i2c-pi3usb30532-mux";
data->connections[1].id = "mode-switch";
data->connections[2].endpoint[0] = "i2c-fusb302";
data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
diff --git a/drivers/usb/typec/bus.h b/drivers/usb/typec/bus.h
index db40e61d8b72..0c9661c96473 100644
--- a/drivers/usb/typec/bus.h
+++ b/drivers/usb/typec/bus.h
@@ -35,4 +35,19 @@ extern const struct device_type typec_port_dev_type;
#define is_typec_altmode(_dev_) (_dev_->type == &typec_altmode_dev_type)
#define is_typec_port(_dev_) (_dev_->type == &typec_port_dev_type)
+extern struct class typec_mux_class;
+
+struct typec_switch {
+ struct device dev;
+ typec_switch_set_fn_t set;
+};
+
+struct typec_mux {
+ struct device dev;
+ typec_mux_set_fn_t set;
+};
+
+#define to_typec_switch(_dev_) container_of(_dev_, struct typec_switch, dev)
+#define to_typec_mux(_dev_) container_of(_dev_, struct typec_mux, dev)
+
#endif /* __USB_TYPEC_ALTMODE_H__ */
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 2eb623841847..a18285a990a8 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -1646,13 +1646,25 @@ static int __init typec_init(void)
if (ret)
return ret;
+ ret = class_register(&typec_mux_class);
+ if (ret)
+ goto err_unregister_bus;
+
typec_class = class_create(THIS_MODULE, "typec");
if (IS_ERR(typec_class)) {
- bus_unregister(&typec_bus);
- return PTR_ERR(typec_class);
+ ret = PTR_ERR(typec_class);
+ goto err_unregister_mux_class;
}
return 0;
+
+err_unregister_mux_class:
+ class_unregister(&typec_mux_class);
+
+err_unregister_bus:
+ bus_unregister(&typec_bus);
+
+ return ret;
}
subsys_initcall(typec_init);
@@ -1661,6 +1673,7 @@ static void __exit typec_exit(void)
class_destroy(typec_class);
ida_destroy(&typec_index_ida);
bus_unregister(&typec_bus);
+ class_unregister(&typec_mux_class);
}
module_exit(typec_exit);
diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
index 2ce54f3fc79c..15a0e76f792c 100644
--- a/drivers/usb/typec/mux.c
+++ b/drivers/usb/typec/mux.c
@@ -15,35 +15,35 @@
#include
#include
-static DEFINE_MUTEX(switch_lock);
-static DEFINE_MUTEX(mux_lock);
-static LIST_HEAD(switch_list);
-static LIST_HEAD(mux_list);
+#include "bus.h"
+
+static int name_match(struct device *dev, const void *name)
+{
+ return !strcmp((const char *)name, dev_name(dev));
+}
+
+static int fwnode_match(struct device *dev, const void *fwnode)
+{
+ return dev_fwnode(dev) == fwnode;
+}
static void *typec_switch_match(struct device_connection *con, int ep,
void *data)
{
- struct typec_switch *sw;
+ struct device *dev;
- if (!con->fwnode) {
- list_for_each_entry(sw, &switch_list, e
[PATCH v2 02/12] software node: Simplify software_node_release() function
It's possible to release the node ID immediately when
fwnode_remove_software_node() is called, no need to wait for
software_node_release() with that. This change has no
functional effect.
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 30077454eb68..7b321bf8424c 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -557,13 +557,6 @@ static void software_node_release(struct kobject *kobj)
{
struct software_node *swnode = kobj_to_swnode(kobj);
- if (swnode->parent) {
- ida_simple_remove(&swnode->parent->child_ids, swnode->id);
- list_del(&swnode->entry);
- } else {
- ida_simple_remove(&swnode_root_ids, swnode->id);
- }
-
ida_destroy(&swnode->child_ids);
property_entries_free(swnode->properties);
kfree(swnode);
@@ -610,9 +603,6 @@ fwnode_create_software_node(const struct property_entry
*properties,
INIT_LIST_HEAD(&swnode->children);
swnode->parent = p;
- if (p)
- list_add_tail(&swnode->entry, &p->children);
-
ret = kobject_init_and_add(&swnode->kobj, &software_node_type,
p ? &p->kobj : NULL, "node%d", swnode->id);
if (ret) {
@@ -626,6 +616,9 @@ fwnode_create_software_node(const struct property_entry
*properties,
return ERR_PTR(ret);
}
+ if (p)
+ list_add_tail(&swnode->entry, &p->children);
+
kobject_uevent(&swnode->kobj, KOBJ_ADD);
return &swnode->fwnode;
}
@@ -638,6 +631,13 @@ void fwnode_remove_software_node(struct fwnode_handle
*fwnode)
if (!swnode)
return;
+ if (swnode->parent) {
+ ida_simple_remove(&swnode->parent->child_ids, swnode->id);
+ list_del(&swnode->entry);
+ } else {
+ ida_simple_remove(&swnode_root_ids, swnode->id);
+ }
+
kobject_put(&swnode->kobj);
}
EXPORT_SYMBOL_GPL(fwnode_remove_software_node);
--
2.20.1
[PATCH v2 04/12] software node: Implement .get_reference_args fwnode operation
This makes it possible to support drivers that use
fwnode_property_get_reference_args() function.
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c | 56 +++
1 file changed, 56 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 39b8f8f35cfe..d6a9b56cb073 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -534,6 +534,61 @@ software_node_get_named_child_node(const struct
fwnode_handle *fwnode,
return NULL;
}
+static int
+software_node_get_reference_args(const struct fwnode_handle *fwnode,
+const char *propname, const char *nargs_prop,
+unsigned int nargs, unsigned int index,
+struct fwnode_reference_args *args)
+{
+ struct software_node *swnode = to_software_node(fwnode);
+ struct software_node_reference *ref;
+ const struct property_entry *prop;
+ int ret = -ENOENT;
+ int i;
+
+ mutex_lock(&swnode->lock);
+
+ if (!swnode || list_empty(&swnode->references))
+ goto err_unlock;
+
+ if (nargs_prop) {
+ prop = property_entry_get(swnode->properties, nargs_prop);
+ if (!prop) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
+ nargs = prop->value.u32_data;
+ }
+
+ if (nargs > NR_FWNODE_REFERENCE_ARGS) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
+ list_for_each_entry(ref, &swnode->references, list) {
+ if (strcmp(ref->name, propname))
+ continue;
+
+ if (index > (ref->nrefs - 1))
+ break;
+
+ args->nargs = nargs;
+ args->fwnode = software_node_get(ref->args[index].fwnode);
+
+ for (i = 0; i < nargs; i++)
+ args->args[i] = ref->args[index].args[i];
+
+ ret = 0;
+ break;
+ }
+
+err_unlock:
+ mutex_unlock(&swnode->lock);
+
+ return ret;
+}
+
static const struct fwnode_operations software_node_ops = {
.get = software_node_get,
.put = software_node_put,
@@ -543,6 +598,7 @@ static const struct fwnode_operations software_node_ops = {
.get_parent = software_node_get_parent,
.get_next_child_node = software_node_get_next_child,
.get_named_child_node = software_node_get_named_child_node,
+ .get_reference_args = software_node_get_reference_args,
};
/* --
*/
--
2.20.1
[PATCH 00/12] Software fwnode references
Hi, This is the second version of this series. In this version I'm introducing a new helper device_find_child_by_name() as proposed by Andy. Andy requested also another helper that could be used for chaining the fwnodes, but I decided not to add that now. I would like to still think about how we should handle exceptions like if there already is a secondary node assigned for a node. The v1 commit message: This series adds support for software fwnode reference handling. In practice it means making fwnode_property_get_reference_args() function usable in the drivers also with software nodes. I send the series originally as RFC [1]. As the first user for the software node references, I'm converting intel_cht_int33fe.c to use them as part of the series. [1] https://lkml.org/lkml/2019/3/15/457 thanks, Heikki Krogerus (12): software node: Allow node creation without properties software node: Simplify software_node_release() function software node: Add support for references software node: Implement .get_reference_args fwnode operation driver core: Add helper device_find_child_by_name() ACPI / property: Don't limit named child node matching to data nodes device connection: Find connections also by checking the references usb: typec: Registering real device entries for the muxes platform/x86: intel_cht_int33fe: Provide software nodes for the devices platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector platform/x86: intel_cht_int33fe: Link with external dependencies using fwnodes platform/x86: intel_cht_int33fe: Replacing the old connections with references drivers/acpi/property.c | 26 +- drivers/base/core.c | 31 +++ drivers/base/devcon.c| 28 ++ drivers/base/swnode.c| 180 +++- drivers/platform/x86/intel_cht_int33fe.c | 339 +++ drivers/usb/typec/bus.h | 15 + drivers/usb/typec/class.c| 17 +- drivers/usb/typec/mux.c | 221 ++- drivers/usb/typec/mux/pi3usb30532.c | 46 +-- include/linux/device.h | 2 + include/linux/property.h | 8 + include/linux/usb/typec_mux.h| 62 ++--- 12 files changed, 791 insertions(+), 184 deletions(-) -- 2.20.1
[PATCH v2 01/12] software node: Allow node creation without properties
Software nodes are not forced to have device properties. Adding check to property_entries_dup() to make it possible to create software nodes that don't have any properties. Signed-off-by: Heikki Krogerus --- drivers/base/swnode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c index 7fc5a18e02ad..30077454eb68 100644 --- a/drivers/base/swnode.c +++ b/drivers/base/swnode.c @@ -383,6 +383,9 @@ property_entries_dup(const struct property_entry *properties) int i, n = 0; int ret; + if (!properties) + return NULL; + while (properties[n].name) n++; -- 2.20.1
Re: Device Description for FPGA Components on x86 system
Hi Alan, thanks for your answer On Wednesday, April 10, 2019 4:21:09 PM CEST Alan Tull wrote: > On Wed, Apr 10, 2019 at 7:50 AM Federico Vaga wrote: > > Hi Federico, > > I wish I could point you to a complete solution, but there is a lot of > work to be done in this area. Most of what is in the kernel is a low > level in-kernel API [4]. As you correctly state, the hardest part of > this is doing the enumerating if you are on x86 and aren't using > devicetree. > > > Hi, > > > > P.S. sorry if I'm too verbose, hopefully it is useful > > > > thanks for the answer > > > > On Wednesday, April 10, 2019 12:30:14 PM CEST Eric Schwarz wrote: > > > Hi, > > > > > > everything you want is already available and on the way to mainline > > > concerning support for various FPGA loading modes or available for > > > checkout from a git repository. > > > All that has already been discussed on the mailing list. > > > > > > FPGA loading interface is available here [1]. > > > Patchset missing for FPGA loading has been sent to the mailing list from > > > Anatolij Gustschin for various Linux kernel versions. Link to the most > > > recent patchset version [2]. > > > FPGA Manager mailing list archive link [3] - Please read up the story > > > here around those patches and also the replies of the others. > > > > This does not answer the problem, which perhaps need to be clarified. > > > > Loading FPGA is **not** the problem, I listed it in the things I want to > > achieve because it is a pre-requirement for the real problem and because > > the two processes are linked (or could be). > > > > I continue by commenting myself below, trying to make the use case > > clearer. > > > > > Cheers > > > Eric > > > > > > [1] https://github.com/vdsao/fpga-cfg > > > [2] https://marc.info/?l=linux-fpga&m=155078072107199&w=2 > > > [3] https://marc.info/?l=linux-fpga > > > > > > Am 10.04.2019 12:01, schrieb Federico Vaga: > > > > Hello, > > > > > > > > sorry to push for an answer but I do not want to take the risk of > > > > designing > > > > something useless. I do not know how should I interpret a no-answer. > > > > > > > > If the solution really does not exist today, then I would like to > > > > collect > > > > opinions/arguments/requirements on the topic so that I can write > > > > something > > > > useful not only for CERN but for the entire community. > > > > > > > > Thank you > > > > > > > > On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote: > > > >> Hello, > > > >> > > > >> I'm looking for guidance > > > >> > > > >> What I have: > > > >> * Intel x86_64 computer > > > >> * PCIe card with FPGA on it > > > >> > > > >> What I want to achieve: > > > >> * load an FPGA bitstream on the card > > > >> * load a device-tree like description for the FPGA devices contained > > > >> in the bitstream > > > > Let me first elaborate on my knowledge to avoid misunderstandings. > > > > On ARM, nowadays, we boot with a device tree. Later we program an FPGA in > > which there are other devices described by a device tree overlay. This can > > be done easily. > > > > A typical PC (x86/x86_64) does not boot with DeviceTree (it is possible, > > but it is not common and probably not even suggested, not sure), instead > > it uses ACPI. > > I have heard it suggested that we work on using DT overlays on x86*. > It's clear there's work to be done to make that work. I don't know if > anybody has really tried. It seems impractical to map or translate a > x86 systems ACPI into a DT and go from there. > One suggestion a few > years ago was adding a partial DT that had nodes that could serve as > overlay targets and have that running in parallel with ACPI. This is also one of my ideas for a solution to our problems. Are you able to easily retrieve that conversation? Perhaps this is something on which I can work on. > > The FPGA Manager has support only for DeviceTree (there are patching > > floating around to load a bitstream with configfs, debugfs or a > > chardevice (guilty)) > There's one other interface in the kernel upstream. The DFL (device > feature list) framework built on the FPGA manager/bridge/region stuff > [5]. It's probably not what you specifically are looking for, I'm > mentioning as it exists in upstream. It has a limited type of > enumeration and appears to mostly be geared for acceleration rather > than adding and enumerating any random hardware block. Also it > requires specific bitstreams as the feature list is in fpga fabric. > > > Most drivers foresee a DeviceTree loading but not an ACPI one (my feeling, > > I did not extract exact numbers from the sources) > > > > DeviceTree overlay requires that the system boots with DeviceTree. > > > > DeviceTree and ACPI do not work together > > > > So, this is the state of art that I am aware of. Correct me if, and where, > > I am wrong. > > > > > > Restarting from this point. I have a PC (x86_64) with a PCIe FPGA card > > (e.g. sis8160, spec, links belo
Re: [PATCH-tip v2 02/12] locking/rwsem: Implement lock handoff to prevent lock starvation
On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote: > +#define RWSEM_WAIT_TIMEOUT ((HZ - 1)/200 + 1) Given the choices in HZ, the above seems fairly 'optimistic'.
Re: [PATCH-tip v2 02/12] locking/rwsem: Implement lock handoff to prevent lock starvation
On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote: > Because of writer lock stealing, it is possible that a constant > stream of incoming writers will cause a waiting writer or reader to > wait indefinitely leading to lock starvation. > > The mutex code has a lock handoff mechanism to prevent lock starvation. > This patch implements a similar lock handoff mechanism to disable > lock stealing and force lock handoff to the first waiter in the queue > after at least a 5ms waiting period. The waiting period is used to > avoid discouraging lock stealing too much to affect performance. So the mutex code doesn't have that timeout, it foces the handoff if the top waiter fails to acquire. I don't find the above sufficiently justifies the additional complexity. What were the numbers with the simple scheme vs this etc..
Re: [PATCH 1/2] drm: panel-simple: Add simple-panel driver.
Hi Heiko,
> On 10.04.2019, at 16:50, Heiko Stübner wrote:
>
> Hi Christoph,
>
> Am Mittwoch, 10. April 2019, 16:10:44 CEST schrieb Christoph Muellner:
>> On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
>> monitor via DP cable. The actual monitor is therefore not known in advance.
>> This means, we don't have any panel information besides the EDID
>> data from the device itself.
>
> Just so I understand correctly, you have a real dp-connector wired to
> the Analogix dp-controller, and therefore want to connect actual
> monitors to it.
>
> So the problem you're trying to work around is probably that the
> rockchip-driver of the analogix controller explictly expects a bridge
> to be present during probe, right?
>
> I think hacking up the panel-driver is not an ideal approach:
> (1) bridges/panels do expect to stay connected all the time
>and are meant for devices with actual hard-wired displays with specific
>power-sequence requirements
> (2) devicetree is expected to describe the real hardware, therefore the
>dt should not describe one thing while the actual hardware is really
>different
>
> So, I guess a more ideal approach could perhaps be to:
> (1) define a "dp-connector" devicetree binding, see
>Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
>for a similar one
> (2) steal an idea from drivers/gpu/drm/mediatek/mtk_hdmi.c and check
>for that new compatible:
> if (!of_device_is_compatible(remote, "hdmi-connector")) {
> //move bridge handling here
> }
>
>and modify both the rockchip-part and the generic analogix bridge code
>to work with the connector declared instead of a panel?
Thank's for you input on this.
Modelling the connector instead of the panel is indeed a better approach,
since we can then also react to connect/disconnect events (after probe).
Thanks,
Christoph
>
>> The functionality for a 'simple-panel' has been remove a couple
>> of years ago with 81cf32b. This patch brings this feature back.
>>
>> Signed-off-by: Christoph Muellner
>> ---
>> drivers/gpu/drm/panel/panel-simple.c | 24
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index 9e8218f6a3f2..1f69283f3e4b 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
>> backlight_update_status(p->backlight);
>> }
>>
>> -if (p->desc->delay.disable)
>> +if (p->desc && p->desc->delay.disable)
>> msleep(p->desc->delay.disable);
>>
>> p->enabled = false;
>> @@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel
>> *panel)
>>
>> regulator_disable(p->supply);
>>
>> -if (p->desc->delay.unprepare)
>> +if (p->desc && p->desc->delay.unprepare)
>> msleep(p->desc->delay.unprepare);
>>
>> p->prepared = false;
>> @@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel
>> *panel)
>>
>> gpiod_set_value_cansleep(p->enable_gpio, 1);
>>
>> -delay = p->desc->delay.prepare;
>> -if (p->no_hpd)
>> -delay += p->desc->delay.hpd_absent_delay;
>> -if (delay)
>> -msleep(delay);
>> +if (p->desc) {
>> +delay = p->desc->delay.prepare;
>> +if (p->no_hpd)
>> +delay += p->desc->delay.hpd_absent_delay;
>> +if (delay)
>> +msleep(delay);
>> +}
>>
>> p->prepared = true;
>>
>> @@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
>> if (p->enabled)
>> return 0;
>>
>> -if (p->desc->delay.enable)
>> +if (p->desc && p->desc->delay.enable)
>> msleep(p->desc->delay.enable);
>>
>> if (p->backlight) {
>> @@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel
>> *panel,
>> struct panel_simple *p = to_panel_simple(panel);
>> unsigned int i;
>>
>> +if (!p->desc)
>> +return 0;
>> +
>> if (p->desc->num_timings < num_timings)
>> num_timings = p->desc->num_timings;
>>
>> @@ -2536,6 +2541,9 @@ static const struct panel_desc arm_rtsm = {
>>
>> static const struct of_device_id platform_of_match[] = {
>> {
>> +.compatible = "simple-panel",
>> +.data = NULL,
>> +}, {
>> .compatible = "ampire,am-480272h3tmqw-t01h",
>> .data = &ire_am_480272h3tmqw_t01h,
>> }, {
>>
>
>
>
>
Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
On 2019/4/10 22:29, Boris Brezillon wrote:
> On Wed, 10 Apr 2019 22:22:16 +0800
> YueHaibing wrote:
>
>> On 2019/4/10 21:58, Boris Brezillon wrote:
>>> On Wed, 10 Apr 2019 15:39:28 +0200
>>> Boris Brezillon wrote:
>>>
On Wed, 10 Apr 2019 21:07:47 +0800
Yue Haibing wrote:
> From: YueHaibing
>
> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> is set to module:
>
> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> (.text+0xef6): undefined reference to `nand_bch_free'
> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> nand_base.c:(.text+0xa101): undefined reference to
> `nand_bch_calculate_ecc'
> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
>
> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> because MTD_RAW_NAND need it while linked.
>
> Reported-by: Hulk Robot
> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
Nope, it's not this one that introduced the regression.
> Signed-off-by: YueHaibing
> ---
> drivers/mtd/nand/raw/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index 615d738..0500c42 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> if MTD_RAW_NAND
>
> config MTD_NAND_ECC_SW_BCH
> - tristate "Support software BCH ECC"
> + bool "Support software BCH ECC"
> select BCH
> default n
> help
Should be fixed with the following diff squashed into:
51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC
algorithm")
--->8---
diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index b8106651f807..06ce2b655c13 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -15,7 +15,7 @@ struct mtd_info;
struct nand_chip;
struct nand_bch_control;
-#if defined(CONFIG_MTD_NAND_ECC_BCH)
+#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
static inline int mtd_nand_has_bch(void) { return 1; }
@@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
*mtd);
*/
void nand_bch_free(struct nand_bch_control *nbc);
-#else /* !CONFIG_MTD_NAND_ECC_BCH */
+#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
static inline int mtd_nand_has_bch(void) { return 0; }
@@ -64,6 +64,6 @@ static inline struct nand_bch_control
*nand_bch_init(struct mtd_info *mtd)
static inline void nand_bch_free(struct nand_bch_control *nbc) {}
-#endif /* CONFIG_MTD_NAND_ECC_BCH */
+#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
#endif /* __MTD_NAND_BCH_H__ */
>>>
>>> Sorry, I didn't look at the right branch, this part of the code was
>>> correct, but we still have a problem to express the RAW_NAND(y) ->
>>> SW_BCH(y) dependency.
>>
>> It seems this dependency is not always need,
>>
>> case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is
>> not set.
>
> Yes, I know, but forcing nand_bch to a be a boolean is not the right
> solution either, hence my suggestion to use 'imply'.
Got it, Thanks, will send v2 as your suggestion.
>
> .
>
Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
On Tue, Apr 09, 2019 at 02:38:55PM -0400, Julien Desfossez wrote:
> We found the source of the major performance regression we discussed
> previously. It turns out there was a pattern where a task (a kworker in this
> case) could be woken up, but the core could still end up idle before that
> task had a chance to run.
>
> Example sequence, cpu0 and cpu1 and siblings on the same core, task1 and
> task2 are in the same cgroup with the tag enabled (each following line
> happens in the increasing order of time):
> - task1 running on cpu0, task2 running on cpu1
> - sched_waking(kworker/0, target_cpu=cpu0)
> - task1 scheduled out of cpu0
> - kworker/0 cannot run on cpu0 because of task2 is still running on cpu1
> cpu0 is idle
> - task2 scheduled out of cpu1
But at this point core_cookie is still set; we don't clear it when the
last task goes away.
> - cpu1 doesn’t select kworker/0 for cpu0, because the optimization path ends
> the task selection if core_cookie is NULL for currently selected process
> and the cpu1’s runqueue.
But at this point core_cookie is still set, we only (re)set it later to
p->core_cookie.
What I suspect happens is that you hit the 'again' clause due to a
higher prio @max on the second sibling. And at that point we've
destroyed core_cookie.
> - cpu1 is idle
> --> both siblings are idle but kworker/0 is still in the run queue of cpu0.
> Cpu0 may stay idle for longer if it goes deep idle.
>
> With the fix below, we ensure to send an IPI to the sibling if it is idle
> and has tasks waiting in its runqueue.
> This fixes the performance issue we were seeing.
>
> Now here is what we can measure with a disk write-intensive benchmark:
> - no performance impact with enabling core scheduling without any tagged
> task,
> - 5% overhead if one tagged task is competing with an untagged task,
> - 10% overhead if 2 tasks tagged with a different tag are competing
> against each other.
>
> We are starting more scaling tests, but this is very encouraging !
>
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e1fa10561279..02c862a5e973 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3779,7 +3779,22 @@ pick_next_task(struct rq *rq, struct task_struct
> *prev, struct rq_flags *rf)
>
> trace_printk("unconstrained pick: %s/%d %lx\n",
> next->comm, next->pid,
> next->core_cookie);
> + rq->core_pick = NULL;
>
> + /*
> + * If the sibling is idling, we might want to
> wake it
> + * so that it can check for any runnable but
> blocked tasks
> + * due to previous task matching.
> + */
> + for_each_cpu(j, smt_mask) {
> + struct rq *rq_j = cpu_rq(j);
> + rq_j->core_pick = NULL;
> + if (j != cpu &&
> is_idle_task(rq_j->curr) && rq_j->nr_running) {
> + resched_curr(rq_j);
> + trace_printk("IPI(%d->%d[%d])
> idle preempt\n",
> + cpu, j,
> rq_j->nr_running);
> + }
> + }
> goto done;
> }
I'm thinking there is a more elegant solution hiding in there; possibly
saving/restoring that core_cookie on the again loop should do, but I've
always had the nagging suspicion that whole selection loop could be done
better.
Re: [PATCH] KVM: x86: clear VM_EXIT_SAVE_IA32_PAT
On Wed, Apr 10, 2019 at 11:55:21AM +0200, Paolo Bonzini wrote: > This is not needed, PAT writes always take an MSR vmexit. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Sean Christopherson
Re: [PATCH] KVM: x86: optimize check for valid PAT value
On Wed, Apr 10, 2019 at 11:55:26AM +0200, Paolo Bonzini wrote: > This check will soon be done on every nested vmentry and vmexit, > "parallelize" it using bitwise operations. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Sean Christopherson
Re: [PATCH] KVM: x86: optimize check for valid PAT value
On Wed, Apr 10, 2019 at 12:55:53PM +, David Laight wrote:
> From: Paolo Bonzini
> > Sent: 10 April 2019 10:55
> >
> > This check will soon be done on every nested vmentry and vmexit,
> > "parallelize" it using bitwise operations.
> >
> > Signed-off-by: Paolo Bonzini
> > ---
> ...
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index 28406aa1136d..7bc7ac9d2a44 100644
> > --- a/arch/x86/kvm/x86.h
> > +++ b/arch/x86/kvm/x86.h
> > @@ -347,4 +347,12 @@ static inline void kvm_after_interrupt(struct kvm_vcpu
> > *vcpu)
> > __this_cpu_write(current_vcpu, NULL);
> > }
> >
> > +static inline bool kvm_pat_valid(u64 data)
> > +{
> > + if (data & 0xF8F8F8F8F8F8F8F8)
> > + return false;
> > + /* 0, 1, 4, 5, 6, 7 are valid values. */
> > + return (data | ((data & 0x0202020202020202) << 1)) == data;
> > +}
> > +
>
> How about:
> /*
>* Each byte must be 0, 1, 4, 5, 6 or 7.
>* Convert 001x to 011x then 100x so 2 and 3 fail the test.
>*/
> data |= (data ^ 0x0404040404040404ULL)) + 0x0202020202020202ULL;
> if (data & 0xF8F8F8F8F8F8F8F8ULL)
> return false;
Woah. My vote is for Paolo's version as the separate checks allow the
reader to walk through step-by-step. The generated assembly isn't much
different from a performance perspective since the TEST+JNE will be not
taken in the fast path.
Fancy:
0x0004844f <+255>: movabs $0xf8f8f8f8f8f8f8f8,%rcx
0x00048459 <+265>: xor%eax,%eax
0x0004845b <+267>: test %rcx,%rdx
0x0004845e <+270>: jne0x4848b
0x00048460 <+272>: movabs $0x202020202020202,%rax
0x0004846a <+282>: and%rdx,%rax
0x0004846d <+285>: add%rax,%rax
0x00048470 <+288>: or %rdx,%rax
0x00048473 <+291>: cmp%rdx,%rax
0x00048476 <+294>: sete %al
0x00048479 <+297>: retq
Really fancy:
0x00048447 <+247>: movabs $0x404040404040404,%rcx
0x00048451 <+257>: movabs $0x202020202020202,%rax
0x0004845b <+267>: xor%rdx,%rcx
0x0004845e <+270>: add%rax,%rcx
0x00048461 <+273>: movabs $0xf8f8f8f8f8f8f8f8,%rax
0x0004846b <+283>: or %rcx,%rdx
0x0004846e <+286>: test %rax,%rdx
0x00048471 <+289>: sete %al
0x00048474 <+292>: retq
Re: [PATCH v2 2/2] dt-bindings: cpufreq: Document operating-points-v2-sunxi-cpu
On Tue, Apr 09, 2019 at 01:25:58PM -0400, Yangtao Li wrote: > Allwinner Process Voltage Scaling Tables defines the voltage and > frequency value based on the speedbin blown in the efuse combination. > The sunxi-cpufreq-nvmem driver reads the efuse value from the SoC to > provide the OPP framework with required information. > This is used to determine the voltage and frequency value for each > OPP of operating-points-v2 table when it is parsed by the OPP framework. > > The "operating-points-v2-sunxi-cpu" DT extends the "operating-points-v2" > with following parameters: > - nvmem-cells (NVMEM area containig the speedbin information) > - opp-microvolt-: voltage in micro Volts. > At runtime, the platform can pick a and matching > opp-microvolt- property > > Signed-off-by: Yangtao Li > --- > .../bindings/opp/sunxi-nvmem-cpufreq.txt | 166 ++ > 1 file changed, 166 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > > diff --git a/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > b/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > new file mode 100644 > index ..c81a2075b974 > --- /dev/null > +++ b/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > @@ -0,0 +1,166 @@ > +Allwinner Technologies, Inc. NVMEM CPUFreq and OPP bindings > +=== > + > +For some SoCs, the CPU frequency subset and voltage value of each OPP > +varies based on the silicon variant in use. Allwinner Process Voltage > +Scaling Tables defines the voltage and frequency value based on the > +speedbin blown in the efuse combination. The sunxi-cpufreq-nvmem driver > +reads the efuse value from the SoC to provide the OPP framework with > +required information. > + > +Required properties: > + > +In 'cpus' nodes: > +- operating-points-v2: Phandle to the operating-points-v2 table to use. > + > +In 'operating-points-v2' table: > +- compatible: Should be > + - 'operating-points-v2-sunxi-cpu'. Vendor-specific compatibles should have the vendor mentionned. Also, even though the H6 is the only SoC so far that has needed this, we can't really assume that it will be the only SoC to use it, or that it will always behave like that. So having something like allwinner,sun50i-h6-operating-points would be great. > +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the > + efuse registers that has information about the > + speedbin that is used to select the right frequency/voltage > + value pair. > + Please refer the for nvmem-cells > + bindings Documentation/devicetree/bindings/nvmem/nvmem.txt > + and also examples below. > + > +In every OPP node: > +- opp-microvolt-: Voltage in micro Volts. > + At runtime, the platform can pick a and > + matching opp-microvolt- property. > + [See: opp.txt] You need to document the valid names here. Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v8 00/20] Convert x86 & arm64 to use generic page walk
Hi all, Gentle ping: who can take this? Is there anything blocking this series? Thanks, Steve On 03/04/2019 15:16, Steven Price wrote: > Most architectures current have a debugfs file for dumping the kernel > page tables. Currently each architecture has to implement custom > functions for walking the page tables because the generic > walk_page_range() function is unable to walk the page tables used by the > kernel. > > This series extends the capabilities of walk_page_range() so that it can > deal with the page tables of the kernel (which have no VMAs and can > contain larger huge pages than exist for user space). x86 and arm64 are > then converted to make use of walk_page_range() removing the custom page > table walkers. > > To enable a generic page table walker to walk the unusual mappings of > the kernel we need to implement a set of functions which let us know > when the walker has reached the leaf entry. Since arm, powerpc, s390, > sparc and x86 all have p?d_large macros lets standardise on that and > implement those that are missing. > > Potentially future changes could unify the implementations of the > debugfs walkers further, moving the common functionality into common > code. This would require a common way of handling the effective > permissions (currently implemented only for x86) along with a per-arch > way of formatting the page table information for debugfs. One > immediate benefit would be getting the KASAN speed up optimisation in > arm64 (and other arches) which is currently only implemented for x86. > > Also available as a git tree: > git://linux-arm.org/linux-sp.git walk_page_range/v8 > > Changes since v7: > https://lore.kernel.org/lkml/20190328152104.23106-1-steven.pr...@arm.com/T/ > * Updated commit message in patch 2 to clarify that we rely on the page >tables being walked to be the same page size/depth as the kernel's >(since this confused me earlier today). > > Changes since v6: > https://lore.kernel.org/lkml/20190326162624.20736-1-steven.pr...@arm.com/T/ > * Split the changes for powerpc. pmd_large() is now added in patch 4 >patch, and pmd_is_leaf() removed in patch 5. > > Changes since v5: > https://lore.kernel.org/lkml/20190321141953.31960-1-steven.pr...@arm.com/T/ > * Updated comment for struct mm_walk based on Mike Rapoport's >suggestion > > Changes since v4: > https://lore.kernel.org/lkml/20190306155031.4291-1-steven.pr...@arm.com/T/ > * Correctly force result to a boolean in p?d_large for powerpc. > * Added Acked-bys > * Rebased onto v5.1-rc1 > > Changes since v3: > https://lore.kernel.org/lkml/20190227170608.27963-1-steven.pr...@arm.com/T/ > * Restored the generic macros, only implement p?d_large() for >architectures that have support for large pages. This also means >adding dummy #defines for architectures that define p?d_large as >static inline to avoid picking up the generic macro. > * Drop the 'depth' argument from pte_hole > * Because we no longer have the depth for holes, we also drop support >in x86 for showing missing pages in debugfs. See discussion below: >https://lore.kernel.org/lkml/26df02dd-c54e-ea91-bdd1-0a4aad3a3...@arm.com/ > * mips: only define p?d_large when _PAGE_HUGE is defined. > > Changes since v2: > https://lore.kernel.org/lkml/20190221113502.54153-1-steven.pr...@arm.com/T/ > * Rather than attemping to provide generic macros, actually implement >p?d_large() for each architecture. > > Changes since v1: > https://lore.kernel.org/lkml/20190215170235.23360-1-steven.pr...@arm.com/T/ > * Added p4d_large() macro > * Comments to explain p?d_large() macro semantics > * Expanded comment for pte_hole() callback to explain mapping between >depth and P?D > * Handle folded page tables at all levels, so depth from pte_hole() >ignores folding at any level (see real_depth() function in >mm/pagewalk.c) > > Steven Price (20): > arc: mm: Add p?d_large() definitions > arm64: mm: Add p?d_large() definitions > mips: mm: Add p?d_large() definitions > powerpc: mm: Add p?d_large() definitions > KVM: PPC: Book3S HV: Remove pmd_is_leaf() > riscv: mm: Add p?d_large() definitions > s390: mm: Add p?d_large() definitions > sparc: mm: Add p?d_large() definitions > x86: mm: Add p?d_large() definitions > mm: Add generic p?d_large() macros > mm: pagewalk: Add p4d_entry() and pgd_entry() > mm: pagewalk: Allow walking without vma > mm: pagewalk: Add test_p?d callbacks > arm64: mm: Convert mm/dump.c to use walk_page_range() > x86: mm: Don't display pages which aren't present in debugfs > x86: mm: Point to struct seq_file from struct pg_state > x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct > x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct > x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct > x86: mm: Convert dump_pagetables to use walk_page_range > > arch/arc/include/asm/pgtable.h | 1 + > arch/
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On Tue, Apr 9, 2019 at 8:40 PM Li, Aubrey wrote:
>
> On 2019/4/10 10:36, Li, Aubrey wrote:
> > On 2019/4/10 10:25, Andy Lutomirski wrote:
> >> On Tue, Apr 9, 2019 at 7:20 PM Li, Aubrey
> >> wrote:
> >>>
> >>> On 2019/4/10 9:58, Andy Lutomirski wrote:
> On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li
> wrote:
> >
> > The architecture specific information of the running processes could
> > be useful to the userland. Add support to examine process architecture
> > specific information externally.
> >
> > Signed-off-by: Aubrey Li
> > Cc: Peter Zijlstra
> > Cc: Andi Kleen
> > Cc: Tim Chen
> > Cc: Dave Hansen
> > Cc: Arjan van de Ven
> > Cc: Linux API
> > Cc: Alexey Dobriyan
> > Cc: Andrew Morton
> > ---
> > fs/proc/array.c | 5 +
> > include/linux/proc_fs.h | 2 ++
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index 2edbb657f859..331592a61718 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file
> > *m, struct mm_struct *mm)
> > seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
> > }
> >
> > +void __weak arch_proc_pid_status(struct seq_file *m, struct
> > task_struct *task)
> > +{
> > +}
>
> This pointlessly bloats other architectures. Do this instead in an
> appropriate header:
>
> #ifndef arch_proc_pid_status
> static inline void arch_proc_pid_status(...)
> {
> }
> #endif
>
> >>>
> >>> I saw a bunch of similar weak functions, is it not acceptable?
> >>>
> >>> fs/proc$ grep weak *.c
> >>> cpuinfo.c:__weak void arch_freq_prepare_all(void)
> >>> meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file
> >>> *m)
> >>> vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned
> >>> long long *size)
> >>> vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
> >>> vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64
> >>> *ppos)
> >>> vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count,
> >>> u64 *ppos)
> >>> vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
> >>> vmcore.c:ssize_t __weak
> >>
> >> I think they're acceptable, but I don't personally like them.
> >>
> >
> > okay, let me try to see if I can refine it in an appropriate way.
>
> Hi Andy,
>
> Is this what you want?
>
> Thanks,
> -Aubrey
>
>
> diff --git a/arch/x86/include/asm/processor.h
> b/arch/x86/include/asm/processor.h
> index 2bb3a648fc12..82d77d3aefff 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -990,5 +990,8 @@ enum l1tf_mitigations {
> };
>
> extern enum l1tf_mitigations l1tf_mitigation;
> +/* Add support for architecture specific output in /proc/pid/status */
> +void arch_proc_pid_status(struct seq_file *m, struct task_struct *task);
> +#define arch_proc_pid_status arch_proc_pid_status
>
> #endif /* _ASM_X86_PROCESSOR_H */
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 2edbb657f859..fd65a6ba2864 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -401,6 +401,11 @@ static inline void task_thp_status(struct seq_file *m,
> struct mm_struct *mm)
> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
> }
>
> +/* Add support for architecture specific output in /proc/pid/status */
> +#ifndef arch_proc_pid_status
> +#define arch_proc_pid_status(m, task)
> +#endif
> +
> int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *task)
> {
> @@ -424,6 +429,7 @@ int proc_pid_status(struct seq_file *m, struct
> pid_namespace *ns,
> task_cpus_allowed(m, task);
> cpuset_task_status_allowed(m, task);
> task_context_switch_counts(m, task);
> + arch_proc_pid_status(m, task);
> return 0;
> }
>
Yes. But I still think it would be nicer to separate the arch stuff
into its own file. Others might reasonably disagree with me.
Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
On Wed, Apr 10, 2019 at 3:24 AM Reshetova, Elena
wrote:
>
>
> > > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > > index 7bc105f47d21..38ddc213a5e9 100644
> > > > > --- a/arch/x86/entry/common.c
> > > > > +++ b/arch/x86/entry/common.c
> > > > > @@ -35,6 +35,12 @@
> > > > > #define CREATE_TRACE_POINTS
> > > > > #include
> > > > >
> > > > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > > > > +#include
> > > > > +
> > > > > +void *alloca(size_t size);
> > > > > +#endif
> > > > > +
> > > > > #ifdef CONFIG_CONTEXT_TRACKING
> > > > > /* Called on entry from user mode with IRQs off. */
> > > > > __visible inline void enter_from_user_mode(void)
> > > > > @@ -273,6 +279,13 @@ __visible void do_syscall_64(unsigned long nr,
> > > > > struct
> > > pt_regs *regs)
> > > > > {
> > > > > struct thread_info *ti;
> > > > >
> > > > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > > > > + size_t offset = ((size_t)prandom_u32()) % 256;
> > > > > + char *ptr = alloca(offset);
> > > > > +
> > > > > + asm volatile("":"=m"(*ptr));
> > > > > +#endif
> > > > > +
> > > > > enter_from_user_mode();
> > > > > local_irq_enable();
> > > > > ti = current_thread_info();
> > > >
> > > > Would it make sense to also do this for the compat syscalls
> > > > (do_fast_syscall_32, do_int80_syscall_32)?
> > >
> > > Could someone please include the full patch, with justification and
> > > performance impact analysis etc.? Can only find the code part of the
> > > thread on lkml, which leaves out this context.
> > >
> >
> > Sorry, this is very weird, I cannot find it either from lkml, but it was
> > sent there
> > to begin with (and as visible from reply-to headers).
> >
> > Do you want me to resent original version or with "do_fast_syscall_32,
> > do_int80_syscall_32" additions (I am finishing testing them now).
>
> I will resend the original x86_64 now since this is the one I tested and
> measured properly. The 32 bit changes seem to work fine inside my 32 bit VM,
> but since I don't have any real 32 bit HW, I am hesitant to send them out
> without
> real HW testing and measuring.
>
> This is the asm code for 32 bits (note it requires __builtin_alloca
> definition and not just alloca,
> so I will change the 64 bit version to use it also):
>
> #ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> size_t offset = ((size_t)prandom_u32()) % 256;
> 0xc10025b6 call 0xc146f7d0
> 0xc10025bb movzbl %al,%eax
> char *ptr = __builtin_alloca(offset);
> 0xc10025be add$0x12,%eax
> 0xc10025c1 and$0x1fc,%eax
> 0xc10025c6 sub%eax,%esp
> 0xc10025c8 lea0x27(%esp),%eax
> 0xc10025cc and$0xfff0,%eax
>
> Also, the result is 47 different random offsets produced,
> which is slightly better than 33 offsets for x86_64.
>
I would suggest that you macro-ify this thing:
#ifdef WHATEVER
#define add_random_stack_offset() do { void *addr = ... } while (0)
#else
#define add_random_stack_offset() do {} while (0)
#endif
since you'll end up with more than one call site.
Re: [PATCH 1/1] x86/entry/64: randomize kernel stack offset upon syscall
On Wed, Apr 10, 2019 at 4:43 AM Ingo Molnar wrote:
>
>
> * Elena Reshetova wrote:
>
> > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys
> > base:1000 loops in 1.62224s
> > = 162.22 nsec / loop
> > random_offset (prandom_u32() every syscall): 1000 loops in 1.64660s
> > = 166.26 nsec / loop
>
> Stupid question, how did you manage to buil timing_test_64? Here it fails
> with a bog standard gcc 7.3.0 x86-64 distro toolchain:
>
> dagon:~/luto-misc-tests.git> make timing_test_64
> g++ -m64 -o timing_test_64 -O2 -g -std=gnu++11 -pthread -Wall
> timing_test.cc -lrt -ldl
> /usr/bin/ld: /tmp/cc8VRkuV.o: relocation R_X86_64_32S against
> `.text.startup' can not be used when making a PIE object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on outputcollect2:
> error: ld returned 1 exit status
> Makefile:39: recipe for target 'timing_test_64' failed
>
I think your toolchain is screwy. If I create this file as ingo.c:
#include
int main(int argc, char **argv)
{
printf("Hello world!");
return 0;
}
And build it like this, it fails:
$ gcc -o ingo -g ingo.c -pie
/usr/bin/ld: /tmp/ccofYU9N.o: relocation R_X86_64_32 against `.rodata'
can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
Which I assume means that -pie requires -fPIC, and your toolchain is
screwed up and is defaulting to useless options. I'm guessing you
should file a bug against your distro gcc package. For me, it works
if I remove -pie.
RE: [PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs
> -Original Message- > From: Bjorn Helgaas > Sent: Tuesday, April 9, 2019 5:59 PM > To: Nikolai Kostrigin > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > jroe...@suse.de; Deucher, Alexander > Subject: Re: [PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon > R7 GPUs > > [+cc Alex] > > This claims to be a resend, but I don't see a previous posting. > > There *was* discussion when the quirk was added two years ago for a > different device. As part of that, Alex thought only that device would be > affected and ATS was validated on other GPUs: > > > https://lore.kernel.org/lkml/BN6PR12MB165278346BE8A76B1E4412AFF7EA0 > @BN6PR12MB1652.namprd12.prod.outlook.com/ > > On Mon, Apr 08, 2019 at 01:37:25PM +0300, Nikolai Kostrigin wrote: > > ATS is broken on this hardware (at least for Stoney Ridge based > > laptop) and causes IOMMU stalls and system failure. Disable ATS on > > these devices to make them usable again with IOMMU enabled Thanks to > > Joerg Roedel for help. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=194521 > > + a few AMD people Seeing this bug makes it more clear. I don't think this is a problem with the GPU. I think it's a problem with either the sbios or iommu. I think the original quirk added for stoney (0x98e4) is probably wrong as well. I suspect we need a quirk for a particular laptop or sbios versions. We validated ATS extensively with Carrizo based systems (the system in the bug report above is Carrizo based) since it is the basis of our ROCm support on APUs. We have also been involved in tons of Linux OEM preloads with both Carrizo and Stoney based APUs in combination with TOPAZ dGPUs (0x6900) and haven't seen this issue in those programs. We also have TOPAZ dGPUs used in OEM programs with Intel chipsets and haven't seen the issue. I suspect since windows does not use the IOMMU by default, the sbios settings may not be well validated on certain windows only skus. I'd rather make these DMI matches or something like that for the platform or at the very least match the SSIDs as well. Alex > > Signed-off-by: Nikolai Kostrigin > > Joerg, I'm happy to merge this if you would review or ack it. I don't know > enough to conclude that this is the root cause. It'd be nice to have an > actual > AMD erratum. Maybe it would even have a list of affected devices so we > could get them all at once so people wouldn't have to trip over them one by > one. > > > --- > > drivers/pci/quirks.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index > > 4700d24e5d55..abb2532e16bf 100644 > > --- a/drivers/pci/quirks.c > > +++ b/drivers/pci/quirks.c > > @@ -4876,6 +4876,7 @@ static void quirk_no_ats(struct pci_dev *pdev) > > > > /* AMD Stoney platform GPU */ > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats); > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900, > quirk_no_ats); > > #endif /* CONFIG_PCI_ATS */ > > > > /* Freescale PCIe doesn't support MSI in RC mode */ > > -- > > 2.21.0 > >
Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
On Wed, Apr 10, 2019 at 12:36:33PM +0800, Aaron Lu wrote: > On Tue, Apr 09, 2019 at 11:09:45AM -0700, Tim Chen wrote: > > Now that we have accumulated quite a number of different fixes to your > > orginal > > posted patches. Would you like to post a v2 of the core scheduler with the > > fixes? > > One more question I'm not sure: should a task with cookie=0, i.e. tasks > that are untagged, be allowed to scheduled on the the same core with > another tagged task? That was not meant to be possible. > The current patch seems to disagree on this, e.g. in pick_task(), > if max is already chosen but max->core_cookie == 0, then we didn't care > about cookie and simply use class_pick for the other cpu. This means we > could schedule two tasks with different cookies(one is zero and the > other can be tagged). When core_cookie==0 we shouldn't schedule the other siblings at all. > But then sched_core_find() only allow idle task to match with any tagged > tasks(we didn't place untagged tasks to the core tree of course :-). > > Thoughts? Do I understand this correctly? If so, I think we probably > want to make this clear before v2. I personally feel, we shouldn't allow > untagged tasks(like kernel threads) to match with tagged tasks. Agreed, cookie should always match or idle.
[PATCH RT] bpf: Guard bpf_prog_active with a locallock
The bpf_prog_active counter is used to avoid recursion on the same CPU.
On RT we can't keep it with the preempt-disable part because the syscall
may need to acquire locks or allocate memory.
Use a locallock() to avoid recursion on the same CPU.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/bpf.h | 2 ++
kernel/bpf/hashtab.c | 4 ++--
kernel/bpf/syscall.c | 13 +++--
kernel/events/core.c | 3 ++-
kernel/trace/bpf_trace.c | 5 ++---
5 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e734f163bd0b9..667f45de65be8 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
struct bpf_verifier_env;
struct perf_event;
@@ -467,6 +468,7 @@ _out:
\
#ifdef CONFIG_BPF_SYSCALL
DECLARE_PER_CPU(int, bpf_prog_active);
+DECLARE_LOCAL_IRQ_LOCK(bpf_prog_active_lock);
extern const struct file_operations bpf_map_fops;
extern const struct file_operations bpf_prog_fops;
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index b4f903a5ef36e..15120d2d8b659 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -668,11 +668,11 @@ static void htab_elem_free_rcu(struct rcu_head *head)
* we're calling kfree, otherwise deadlock is possible if kprobes
* are placed somewhere inside of slub
*/
- preempt_disable();
+ local_lock(bpf_prog_active_lock);
__this_cpu_inc(bpf_prog_active);
htab_elem_free(htab, l);
__this_cpu_dec(bpf_prog_active);
- preempt_enable();
+ local_unlock(bpf_prog_active_lock);
}
static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 84470d1480aa4..73f2edbe3b28c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -42,6 +42,7 @@
#define BPF_OBJ_FLAG_MASK (BPF_F_RDONLY | BPF_F_WRONLY)
DEFINE_PER_CPU(int, bpf_prog_active);
+DEFINE_LOCAL_IRQ_LOCK(bpf_prog_active_lock);
static DEFINE_IDR(prog_idr);
static DEFINE_SPINLOCK(prog_idr_lock);
static DEFINE_IDR(map_idr);
@@ -716,7 +717,7 @@ static int map_lookup_elem(union bpf_attr *attr)
goto done;
}
- preempt_disable();
+ local_lock(bpf_prog_active_lock);
this_cpu_inc(bpf_prog_active);
if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH) {
@@ -750,7 +751,7 @@ static int map_lookup_elem(union bpf_attr *attr)
rcu_read_unlock();
}
this_cpu_dec(bpf_prog_active);
- preempt_enable();
+ local_unlock(bpf_prog_active_lock);
done:
if (err)
@@ -845,7 +846,7 @@ static int map_update_elem(union bpf_attr *attr)
/* must increment bpf_prog_active to avoid kprobe+bpf triggering from
* inside bpf map update or delete otherwise deadlocks are possible
*/
- preempt_disable();
+ local_lock(bpf_prog_active_lock);
__this_cpu_inc(bpf_prog_active);
if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH) {
@@ -878,7 +879,7 @@ static int map_update_elem(union bpf_attr *attr)
rcu_read_unlock();
}
__this_cpu_dec(bpf_prog_active);
- preempt_enable();
+ local_unlock(bpf_prog_active_lock);
maybe_wait_bpf_programs(map);
out:
free_value:
@@ -925,13 +926,13 @@ static int map_delete_elem(union bpf_attr *attr)
goto out;
}
- preempt_disable();
+ local_lock(bpf_prog_active_lock);
__this_cpu_inc(bpf_prog_active);
rcu_read_lock();
err = map->ops->map_delete_elem(map, key);
rcu_read_unlock();
__this_cpu_dec(bpf_prog_active);
- preempt_enable();
+ local_unlock(bpf_prog_active_lock);
maybe_wait_bpf_programs(map);
out:
kfree(key);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b3155a155a645..6facb80af7c0e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8546,7 +8546,7 @@ static void bpf_overflow_handler(struct perf_event *event,
int ret = 0;
ctx.regs = perf_arch_bpf_user_pt_regs(regs);
- preempt_disable();
+ local_lock(bpf_prog_active_lock);
if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1))
goto out;
rcu_read_lock();
@@ -8555,6 +8555,7 @@ static void bpf_overflow_handler(struct perf_event *event,
out:
__this_cpu_dec(bpf_prog_active);
preempt_enable();
+ local_unlock(bpf_prog_active_lock);
if (!ret)
return;
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f1a86a0d881dd..bb92cf31481b4 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -78,8 +78,7 @@ unsigned int trace_call_bpf(struct trace_ev
Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
On Wed, Apr 10, 2019 at 03:51:24PM +0200, Thomas-Mich Richter wrote:
> Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5.
>
> However doing an fgrep on the pending_disable member of struct perf_event
> reveals two more hits in file kernel/events/ringbuffer.c when events
> have auxiliary data.
>
> Not sure if this needs to be addresses too, just wanted to let you know.
*groan* indeed, and yes that would need fixing too. I completely missed
the AUX stuff using that too.
I think we can simply do the below on top, Alexander?
---
kernel/events/ring_buffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index 678ccec60d8f..ab2b7b38adc5 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -392,7 +392,7 @@ void *perf_aux_output_begin(struct perf_output_handle
*handle,
* store that will be enabled on successful return
*/
if (!handle->size) { /* A, matches D */
- event->pending_disable = 1;
+ event->pending_disable = smp_processor_id();
perf_output_wakeup(handle);
local_set(&rb->aux_nest, 0);
goto err_put;
@@ -480,7 +480,7 @@ void perf_aux_output_end(struct perf_output_handle *handle,
unsigned long size)
if (wakeup) {
if (handle->aux_flags & PERF_AUX_FLAG_TRUNCATED)
- handle->event->pending_disable = 1;
+ handle->event->pending_disable = smp_processor_id();
perf_output_wakeup(handle);
}
Re: [PATCH] ASoC: wcd9335: Fix missing regmap requirement
On 10/04/2019 15:23, Marc Gonzalez wrote: wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip' Signed-off-by: Marc Gonzalez --- Thanks for Fix, Acked-by: Srinivas Kandagatla sound/soc/codecs/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 419142111b6d..33778dc99108 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -1162,6 +1162,7 @@ config SND_SOC_WCD9335 tristate "WCD9335 Codec" depends on SLIMBUS select REGMAP_SLIMBUS + select REGMAP_IRQ help The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports Qualcomm Technologies, Inc. (QTI) multimedia solutions,
Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
On Wed, 10 Apr 2019 22:22:16 +0800
YueHaibing wrote:
> On 2019/4/10 21:58, Boris Brezillon wrote:
> > On Wed, 10 Apr 2019 15:39:28 +0200
> > Boris Brezillon wrote:
> >
> >> On Wed, 10 Apr 2019 21:07:47 +0800
> >> Yue Haibing wrote:
> >>
> >>> From: YueHaibing
> >>>
> >>> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> >>> is set to module:
> >>>
> >>> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> >>> (.text+0xef6): undefined reference to `nand_bch_free'
> >>> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> >>> nand_base.c:(.text+0xa101): undefined reference to
> >>> `nand_bch_calculate_ecc'
> >>> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> >>> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> >>>
> >>> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> >>> because MTD_RAW_NAND need it while linked.
> >>>
> >>> Reported-by: Hulk Robot
> >>> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
> >>
> >> Nope, it's not this one that introduced the regression.
> >>
> >>
> >>
> >>> Signed-off-by: YueHaibing
> >>> ---
> >>> drivers/mtd/nand/raw/Kconfig | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> >>> index 615d738..0500c42 100644
> >>> --- a/drivers/mtd/nand/raw/Kconfig
> >>> +++ b/drivers/mtd/nand/raw/Kconfig
> >>> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> >>> if MTD_RAW_NAND
> >>>
> >>> config MTD_NAND_ECC_SW_BCH
> >>> - tristate "Support software BCH ECC"
> >>> + bool "Support software BCH ECC"
> >>> select BCH
> >>> default n
> >>> help
> >>
> >> Should be fixed with the following diff squashed into:
> >>
> >> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC
> >> algorithm")
> >>
> >> --->8---
> >> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> >> index b8106651f807..06ce2b655c13 100644
> >> --- a/include/linux/mtd/nand_bch.h
> >> +++ b/include/linux/mtd/nand_bch.h
> >> @@ -15,7 +15,7 @@ struct mtd_info;
> >> struct nand_chip;
> >> struct nand_bch_control;
> >>
> >> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> >> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
> >>
> >> static inline int mtd_nand_has_bch(void) { return 1; }
> >>
> >> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
> >> *mtd);
> >> */
> >> void nand_bch_free(struct nand_bch_control *nbc);
> >>
> >> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> >> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
> >>
> >> static inline int mtd_nand_has_bch(void) { return 0; }
> >>
> >> @@ -64,6 +64,6 @@ static inline struct nand_bch_control
> >> *nand_bch_init(struct mtd_info *mtd)
> >>
> >> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> >>
> >> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> >> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
> >>
> >> #endif /* __MTD_NAND_BCH_H__ */
> >
> > Sorry, I didn't look at the right branch, this part of the code was
> > correct, but we still have a problem to express the RAW_NAND(y) ->
> > SW_BCH(y) dependency.
>
> It seems this dependency is not always need,
>
> case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is not
> set.
Yes, I know, but forcing nand_bch to a be a boolean is not the right
solution either, hence my suggestion to use 'imply'.
RE: [PATCH 1/1] x86/entry/64: randomize kernel stack offset upon syscall
> * Elena Reshetova wrote: > > > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys > > base:1000 loops in 1.62224s > > = 162.22 nsec / loop > > random_offset (prandom_u32() every syscall): 1000 loops in 1.64660s > > = > 166.26 nsec / loop > > Stupid question, how did you manage to buil timing_test_64? Here it fails > with a bog standard gcc 7.3.0 x86-64 distro toolchain: > > dagon:~/luto-misc-tests.git> make timing_test_64 > g++ -m64 -o timing_test_64 -O2 -g -std=gnu++11 -pthread -Wall > timing_test.cc -lrt - > ldl > /usr/bin/ld: /tmp/cc8VRkuV.o: relocation R_X86_64_32S against > `.text.startup' can > not be used when making a PIE object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on outputcollect2: > error: ld > returned 1 exit status > Makefile:39: recipe for target 'timing_test_64' failed I used -no-pie on CFLAGS/CCFLAGS for the whole set of tools. Unfortunately, this was only the first problem. After it complains about rdwrgsbase asm case... That one I didn't quite understand, but because I could see that this case wasn't used for particular measurements I was doing, I just commented that particular case out. > > > I'm using cb7f9f0592f8, which is like 1.5 years old - is this still the > latest and greatest: > > git://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git Yes, same for me. Best Regards, Elena.
[PATCH] ASoC: wcd9335: Fix missing regmap requirement
wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip' Signed-off-by: Marc Gonzalez --- sound/soc/codecs/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 419142111b6d..33778dc99108 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -1162,6 +1162,7 @@ config SND_SOC_WCD9335 tristate "WCD9335 Codec" depends on SLIMBUS select REGMAP_SLIMBUS + select REGMAP_IRQ help The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports Qualcomm Technologies, Inc. (QTI) multimedia solutions, -- 2.17.1
Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
On 2019/4/10 21:58, Boris Brezillon wrote:
> On Wed, 10 Apr 2019 15:39:28 +0200
> Boris Brezillon wrote:
>
>> On Wed, 10 Apr 2019 21:07:47 +0800
>> Yue Haibing wrote:
>>
>>> From: YueHaibing
>>>
>>> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
>>> is set to module:
>>>
>>> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
>>> (.text+0xef6): undefined reference to `nand_bch_free'
>>> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
>>> nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
>>> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
>>> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
>>>
>>> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
>>> because MTD_RAW_NAND need it while linked.
>>>
>>> Reported-by: Hulk Robot
>>> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
>>
>> Nope, it's not this one that introduced the regression.
>>
>>
>>
>>> Signed-off-by: YueHaibing
>>> ---
>>> drivers/mtd/nand/raw/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
>>> index 615d738..0500c42 100644
>>> --- a/drivers/mtd/nand/raw/Kconfig
>>> +++ b/drivers/mtd/nand/raw/Kconfig
>>> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
>>> if MTD_RAW_NAND
>>>
>>> config MTD_NAND_ECC_SW_BCH
>>> - tristate "Support software BCH ECC"
>>> + bool "Support software BCH ECC"
>>> select BCH
>>> default n
>>> help
>>
>> Should be fixed with the following diff squashed into:
>>
>> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC
>> algorithm")
>>
>> --->8---
>> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
>> index b8106651f807..06ce2b655c13 100644
>> --- a/include/linux/mtd/nand_bch.h
>> +++ b/include/linux/mtd/nand_bch.h
>> @@ -15,7 +15,7 @@ struct mtd_info;
>> struct nand_chip;
>> struct nand_bch_control;
>>
>> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
>> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
>>
>> static inline int mtd_nand_has_bch(void) { return 1; }
>>
>> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
>> *mtd);
>> */
>> void nand_bch_free(struct nand_bch_control *nbc);
>>
>> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
>> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>>
>> static inline int mtd_nand_has_bch(void) { return 0; }
>>
>> @@ -64,6 +64,6 @@ static inline struct nand_bch_control
>> *nand_bch_init(struct mtd_info *mtd)
>>
>> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
>>
>> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
>> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>>
>> #endif /* __MTD_NAND_BCH_H__ */
>
> Sorry, I didn't look at the right branch, this part of the code was
> correct, but we still have a problem to express the RAW_NAND(y) ->
> SW_BCH(y) dependency.
It seems this dependency is not always need,
case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is not
set.
>
> .
>
Re: Device Description for FPGA Components on x86 system
On Wed, Apr 10, 2019 at 7:50 AM Federico Vaga wrote: Hi Federico, I wish I could point you to a complete solution, but there is a lot of work to be done in this area. Most of what is in the kernel is a low level in-kernel API [4]. As you correctly state, the hardest part of this is doing the enumerating if you are on x86 and aren't using devicetree. > > Hi, > > P.S. sorry if I'm too verbose, hopefully it is useful > > thanks for the answer > > On Wednesday, April 10, 2019 12:30:14 PM CEST Eric Schwarz wrote: > > Hi, > > > > everything you want is already available and on the way to mainline > > concerning support for various FPGA loading modes or available for > > checkout from a git repository. > > All that has already been discussed on the mailing list. > > > > FPGA loading interface is available here [1]. > > Patchset missing for FPGA loading has been sent to the mailing list from > > Anatolij Gustschin for various Linux kernel versions. Link to the most > > recent patchset version [2]. > > FPGA Manager mailing list archive link [3] - Please read up the story > > here around those patches and also the replies of the others. > > This does not answer the problem, which perhaps need to be clarified. > > Loading FPGA is **not** the problem, I listed it in the things I want to > achieve because it is a pre-requirement for the real problem and because the > two processes are linked (or could be). > > I continue by commenting myself below, trying to make the use case clearer. > > > > > Cheers > > Eric > > > > [1] https://github.com/vdsao/fpga-cfg > > [2] https://marc.info/?l=linux-fpga&m=155078072107199&w=2 > > [3] https://marc.info/?l=linux-fpga > > > > Am 10.04.2019 12:01, schrieb Federico Vaga: > > > Hello, > > > > > > sorry to push for an answer but I do not want to take the risk of > > > designing > > > something useless. I do not know how should I interpret a no-answer. > > > > > > If the solution really does not exist today, then I would like to > > > collect > > > opinions/arguments/requirements on the topic so that I can write > > > something > > > useful not only for CERN but for the entire community. > > > > > > Thank you > > > > > > On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote: > > >> Hello, > > >> > > >> I'm looking for guidance > > >> > > >> What I have: > > >> * Intel x86_64 computer > > >> * PCIe card with FPGA on it > > >> > > >> What I want to achieve: > > >> * load an FPGA bitstream on the card > > >> * load a device-tree like description for the FPGA devices contained > > >> in the bitstream > > Let me first elaborate on my knowledge to avoid misunderstandings. > > On ARM, nowadays, we boot with a device tree. Later we program an FPGA in > which there are other devices described by a device tree overlay. This can be > done easily. > > A typical PC (x86/x86_64) does not boot with DeviceTree (it is possible, but > it is not common and probably not even suggested, not sure), instead it uses > ACPI. I have heard it suggested that we work on using DT overlays on x86*. It's clear there's work to be done to make that work. I don't know if anybody has really tried. It seems impractical to map or translate a x86 systems ACPI into a DT and go from there. One suggestion a few years ago was adding a partial DT that had nodes that could serve as overlay targets and have that running in parallel with ACPI. > > The FPGA Manager has support only for DeviceTree (there are patching floating > around to load a bitstream with configfs, debugfs or a chardevice (guilty)) There's one other interface in the kernel upstream. The DFL (device feature list) framework built on the FPGA manager/bridge/region stuff [5]. It's probably not what you specifically are looking for, I'm mentioning as it exists in upstream. It has a limited type of enumeration and appears to mostly be geared for acceleration rather than adding and enumerating any random hardware block. Also it requires specific bitstreams as the feature list is in fpga fabric. > > Most drivers foresee a DeviceTree loading but not an ACPI one (my feeling, I > did not extract exact numbers from the sources) > > DeviceTree overlay requires that the system boots with DeviceTree. > > DeviceTree and ACPI do not work together > > So, this is the state of art that I am aware of. Correct me if, and where, I > am wrong. > > > Restarting from this point. I have a PC (x86_64) with a PCIe FPGA card (e.g. > sis8160, spec, links below). How to load the FPGA bitstream (not really a > problem as you correctly pointed out) **and** load all the IP-core instances > in that FPGA bitstream so that drivers will start running? > > - Is there a recommendation for such use case? > - ACPI SSDT overlay? > - DT overlay? > - is there a standard way to load FPGA IP-core devices which is architecture > independent? > > A simple and practical example. The i2c-ocore.c is a platform_driver for an > HDL I2C Master from open cores. I synthesize it and then load
Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
On Wed, Apr 10, 2019 at 12:36 PM Aaron Lu wrote: > > On Tue, Apr 09, 2019 at 11:09:45AM -0700, Tim Chen wrote: > > Now that we have accumulated quite a number of different fixes to your > > orginal > > posted patches. Would you like to post a v2 of the core scheduler with the > > fixes? > > One more question I'm not sure: should a task with cookie=0, i.e. tasks > that are untagged, be allowed to scheduled on the the same core with > another tagged task? > > The current patch seems to disagree on this, e.g. in pick_task(), > if max is already chosen but max->core_cookie == 0, then we didn't care > about cookie and simply use class_pick for the other cpu. This means we > could schedule two tasks with different cookies(one is zero and the > other can be tagged). > > But then sched_core_find() only allow idle task to match with any tagged > tasks(we didn't place untagged tasks to the core tree of course :-). > > Thoughts? Do I understand this correctly? If so, I think we probably > want to make this clear before v2. I personally feel, we shouldn't allow > untagged tasks(like kernel threads) to match with tagged tasks. Does it make sense if we take untagged tasks as hypervisor, and different cookie tasks as different VMs? Isolation is done between VMs, not between VM and hypervisor. Did you see anything harmful if an untagged task and a tagged task run simultaneously on the same core? Thanks, -Aubrey
Re: [PATCH v3 1/4] perf: Add a 'percore' event qualifier
On 4/10/2019 8:54 PM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 10, 2019 at 09:36:41AM -0300, Arnaldo Carvalho de Melo escreveu: Em Tue, Mar 19, 2019 at 04:56:53PM +0800, Jin Yao escreveu: Add a 'percore' event qualifier, like cpu/event=0,umask=0x3,percore=1/, that sums up the event counts for both hardware threads in a core. We can already do this with --per-core, but it's often useful to do this together with other metrics that are collected per hardware thread. So we need to support this per-core counting on a event level. This can be implemented in only the user tool, no kernel support needed. v3: --- Simplify the code according to Jiri's comments. Before: "return term->val.percore ? true : false;" Now: "return term->val.percore;" v2: --- Change the qualifier name from 'coresum' to 'percore' according to comments from Jiri and Andi. I'm applying this, but please, don't forget to, when adding a new qualifier, to update the documentation... I'm doing this for you this time. The first patch didn't apply with 'git am', I did it manually, and added the patch below But then the second doesn't apply to my perf/core branch as well, please refresh and resend a v4, thanks. - Arnaldo Thanks Arnaldo! I will rebase the patch to latest perf/core branch and then send v4. Thanks Jin Yao diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt index 138fb6e94b3c..18ed1b0fceb3 100644 --- a/tools/perf/Documentation/perf-list.txt +++ b/tools/perf/Documentation/perf-list.txt @@ -199,6 +199,18 @@ also be supplied. For example: perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ... +EVENT QUALIFIERS: + +It is also possible to add extra qualifiers to an event: + +percore: + +Sums up the event counts for all hardware threads in a core, e.g.: + + + perf stat -e cpu/event=0,umask=0x3,percore=1/ + + EVENT GROUPS
Re: [PATCH] ARM: dts: stm32: enable cec on stm32mp157a-dk1 board
Hi Yannick On 3/29/19 1:29 PM, Yannick Fertré wrote: Enable CEC (Consumer Electronics Control) device. Signed-off-by: Yannick Fertré --- arch/arm/boot/dts/stm32mp157a-dk1.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts index 1b1886d..61bc23a 100644 --- a/arch/arm/boot/dts/stm32mp157a-dk1.dts +++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts @@ -46,6 +46,13 @@ }; }; Applied on stm32-next. Thanks. Alex
Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
On Wed, 10 Apr 2019 15:58:56 +0200
Boris Brezillon wrote:
> On Wed, 10 Apr 2019 15:39:28 +0200
> Boris Brezillon wrote:
>
> > On Wed, 10 Apr 2019 21:07:47 +0800
> > Yue Haibing wrote:
> >
> > > From: YueHaibing
> > >
> > > Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> > > is set to module:
> > >
> > > drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> > > (.text+0xef6): undefined reference to `nand_bch_free'
> > > drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> > > nand_base.c:(.text+0xa101): undefined reference to
> > > `nand_bch_calculate_ecc'
> > > nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> > > nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> > >
> > > CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> > > because MTD_RAW_NAND need it while linked.
> > >
> > > Reported-by: Hulk Robot
> > > Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
> >
> > Nope, it's not this one that introduced the regression.
> >
> >
> >
> > > Signed-off-by: YueHaibing
> > > ---
> > > drivers/mtd/nand/raw/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > > index 615d738..0500c42 100644
> > > --- a/drivers/mtd/nand/raw/Kconfig
> > > +++ b/drivers/mtd/nand/raw/Kconfig
> > > @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> > > if MTD_RAW_NAND
> > >
> > > config MTD_NAND_ECC_SW_BCH
> > > - tristate "Support software BCH ECC"
> > > + bool "Support software BCH ECC"
> > > select BCH
> > > default n
> > > help
> >
> > Should be fixed with the following diff squashed into:
> >
> > 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC
> > algorithm")
> >
> > --->8---
> > diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> > index b8106651f807..06ce2b655c13 100644
> > --- a/include/linux/mtd/nand_bch.h
> > +++ b/include/linux/mtd/nand_bch.h
> > @@ -15,7 +15,7 @@ struct mtd_info;
> > struct nand_chip;
> > struct nand_bch_control;
> >
> > -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> > +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
> >
> > static inline int mtd_nand_has_bch(void) { return 1; }
> >
> > @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
> > *mtd);
> > */
> > void nand_bch_free(struct nand_bch_control *nbc);
> >
> > -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> > +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
> >
> > static inline int mtd_nand_has_bch(void) { return 0; }
> >
> > @@ -64,6 +64,6 @@ static inline struct nand_bch_control
> > *nand_bch_init(struct mtd_info *mtd)
> >
> > static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> >
> > -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> > +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
> >
> > #endif /* __MTD_NAND_BCH_H__ */
>
> Sorry, I didn't look at the right branch, this part of the code was
> correct, but we still have a problem to express the RAW_NAND(y) ->
> SW_BCH(y) dependency.
This one should do the trick, though imply means MTD_NAND_ECC_SW_BCH will
now be selected by default.
--->8---
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 7fcdaf6c279d..f9258d666846 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -207,7 +207,7 @@ comment "Disk-On-Chip Device Drivers"
config MTD_DOCG3
tristate "M-Systems Disk-On-Chip G3"
select BCH
- select BCH_CONST_PARAMS if !CONFIG_MTD_NAND_ECC_SW_BCH
+ select BCH_CONST_PARAMS if !MTD_NAND_ECC_SW_BCH
select BITREVERSE
help
This provides an MTD device driver for the M-Systems DiskOnChip
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 615d738be411..65c85fc53c41 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -9,18 +9,6 @@ config MTD_NAND_ECC_SW_HAMMING_SMC
Software ECC according to the Smart Media Specification.
The original Linux implementation had byte 0 and 1 swapped.
-menuconfig MTD_RAW_NAND
- tristate "Raw/Parallel NAND Device Support"
- depends on MTD
- select MTD_NAND_CORE
- select MTD_NAND_ECC_SW_HAMMING
- help
- This enables support for accessing all type of raw/parallel
- NAND flash devices. For further information see
- .
-
-if MTD_RAW_NAND
-
config MTD_NAND_ECC_SW_BCH
tristate "Support software BCH ECC"
select BCH
@@ -31,6 +19,19 @@ config MTD_NAND_ECC_SW_BCH
ECC codes. They are used with NAND devices requiring more than 1 bit
of error correction.
+menuconfig MTD_RAW_NAND
+ tristate "Raw/Parallel NAND Device Support"
+ depends on MTD
+ select MTD_NAND_CORE
+ select MTD_NAND_ECC_SW_HAMMING
+ imply MTD_NAND_ECC_SW_BCH
+ help
+
Re: [PATCH v2 1/2] dt-bindings: thermal: al-thermal: Add binding documentation
On Thu, Apr 04, 2019 at 01:16:55PM +0300, Talel Shenhar wrote:
> Add thermal binding documentation for Amazon's Annapurna Labs Thermal
> Sensor.
>
> Signed-off-by: Talel Shenhar
> Reviewed-by: David Woodhouse
> ---
> .../bindings/thermal/amazon,al-thermal.txt | 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> new file mode 100644
> index 000..af8cf18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> @@ -0,0 +1,33 @@
> +Amazon's Annapurna Labs Thermal Sensor
> +
> +Simple thermal device that allows temperature reading by a single MMIO
> +transaction.
> +
> +Required properties:
> +- compatible: "amazon,al-thermal".
> +- reg: The physical base address and length of the sensor's registers.
> +- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description.
> +
> +Example:
> + thermal: thermal {
> + compatible = "amazon,al-thermal";
> + reg = <0x0 0x05002860 0x0 0x1>;
> + #thermal-sensor-cells = <0x1>;
> + };
> +
> + thermal-zones {
> + thermal_z0 {
thermal-z0 {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&thermal 0>;
> + trips {
> + thermalz0_crit {
critical {
With that,
Reviewed-by: Rob Herring
> + temperature = <105000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + };
> + };
> +
> --
> 2.7.4
>
Re: [PATCH v1 0/2] add cec pins muxing
Hi Yannick On 3/29/19 1:41 PM, Yannick Fertré wrote: Add cec pins muxing Yannick Fertré (2): ARM: dts: stm32: add cec pins muxing on stm32mp157 ARM: dts: stm32: add sleep pinctrl for cec on stm32mp157c arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 21 + 1 file changed, 21 insertions(+) Series applied on stm32-next. Note that I squashed the both patches as they deal only with pins muxing group definition. Regards Alex
Re: [PATCH 23/23] watchdog: tangox_wdt: Convert to use device managed functions and other improvements
On 10/04/2019 15:37, Guenter Roeck wrote: > On 4/10/19 6:04 AM, Marc Gonzalez wrote: > >> On 09/04/2019 19:24, Guenter Roeck wrote: >> >>> Use device managed functions to simplify error handling, reduce >>> source code size, improve readability, and reduce the likelihood of bugs. >>> Other improvements as listed below. >>> >>> The conversion was done automatically with coccinelle using the >>> following semantic patches. The semantic patches and the scripts >>> used to generate this commit log are available at >>> https://github.com/groeck/coccinelle-patches >>> >>> - Drop assignments to otherwise unused variables >>> - Drop unnecessary braces around conditional return statements >>> - Drop empty remove function >>> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare >>> - Replace stop on remove with call to watchdog_stop_on_unregister() >>> - Use devm_watchdog_register_driver() to register watchdog device >> >> No devm_clk_prepare() in mainline? :-( >> >> https://lore.kernel.org/patchwork/patch/755487/ > > We went through that several times and never succeeded. This was the major > reason why I didn't submit this series earlier since I was hoping for it > to appear at some point. Unfortunately, someone always objected, typically > with comments along the line that it could be misused, or citing individual > examples where the current code in some driver is wrong and should be fixed > instead. > > This isn't really a technical argument: Everything can be misused, and all > code has bugs. Neither is a reason to reject a new useful API. As such, one > has to assume that after refuting such arguments, and even after fixing all > bugs in existing code, the opponents of the new API will come up with other > reasons to reject it. > > At the end, I gave up trying. Feel free to try yourself; I most definitely > won't try it anymore. Using devm_add_action_or_reset() is a bit more clumsy, > but works just as well. Hello Guenter, I am saddened to read about your frustration. I might give it a try, if Dmitry doesn't feel like giving it another shot. Regards.
Re: [PATCH] of: Improve of_phandle_iterator_next() error message
On Wed, Apr 03, 2019 at 10:56:33AM -0700, Florian Fainelli wrote: > Understanding why of_phandle_iterator_next() returns an error can > sometimes be hard to decipher based solely on the error message, a > typical error example is that #foo-cells = and the phandle property > used has a smaller number of cells specified, e.g.: > > #thermal-sensor-cells = <1>; > phandle = <&scmi_sensor> > > instead of: > > phandle <&scmi_sensor 0>; > > Instead, make it clear what the expectations are towards debugging > incorrect Device Tree faster: > > OF: /thermal-zones/scmi-thermal: #thermal-sensor-cells = 1, found 0 instead > > Signed-off-by: Florian Fainelli > --- > drivers/of/base.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Applied. Rob
[PATCH -next] memory: tegra: Make terga20_mc_reset_ops static
From: YueHaibing
Fix sparse warning:
drivers/memory/tegra/tegra20.c:277:33: warning:
symbol 'terga20_mc_reset_ops' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/memory/tegra/tegra20.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/tegra/tegra20.c b/drivers/memory/tegra/tegra20.c
index 7119e53..b786aec 100644
--- a/drivers/memory/tegra/tegra20.c
+++ b/drivers/memory/tegra/tegra20.c
@@ -274,7 +274,7 @@ static int terga20_mc_unblock_dma(struct tegra_mc *mc,
return 0;
}
-const struct tegra_mc_reset_ops terga20_mc_reset_ops = {
+static const struct tegra_mc_reset_ops terga20_mc_reset_ops = {
.hotreset_assert = terga20_mc_hotreset_assert,
.hotreset_deassert = terga20_mc_hotreset_deassert,
.block_dma = terga20_mc_block_dma,
--
2.7.4
RE: [PATCH 2/2] spi: pxa2xx: use a module softdep for dw_dmac
Hi Mark,
> On Wed, Apr 10, 2019 at 02:51:36PM +0200, Flavio Suligoi wrote:
> > With dw_dmac, sometimes the request of a DMA channel fails because
> > the DMA driver is not ready, so an explicit dependency request
> > is necessary.
>
> While this isn't going to hurt anything and might actually help so it's
> fine doesn't this also suggest that there's an issue with deferred probe
> going on as well?
I think that the problem could be related to how the DMA channel is requested.
At the moment the function used are:
pxa2xx_spi_dma_setup --> dma_request_slave_channel_compat -->
--> __dma_request_slave_channel_compat --> dma_request_slave_channel -->
--> dma_request_chan
Actually the final function "dma_request_chan" return
the channel number or "-EPROBE_DEFER" if it's not ready.
But this information ("-EPROBE_DEFER") is lost in the penultimate function
"dma_request_slave_channel", which return only the chann, if all is ok, or
NULL, in case of errors.
So the deferral mechanism is not used.
Flavio
Re: [PATCH] ARM: dts: stm32: add ltdc pins muxing on stm32mp157
Hi Yannick On 3/29/19 1:28 PM, Yannick Fertré wrote: Add ltdc pins muxing on stm32mp157. Signed-off-by: Yannick Fertré --- arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 138 ++ 1 file changed, 138 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi index 9104896..da4b411 100644 --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi @@ -233,6 +233,144 @@ Applied on stm32-next. Thanks. Alex
[PATCH -next] mtd: rawnand: ingenic: Make jz4725b_ooblayout_ops static
From: YueHaibing
Fix sparse warning:
drivers/mtd/nand/raw/ingenic/ingenic_nand.c:140:32: warning:
symbol 'jz4725b_ooblayout_ops' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/mtd/nand/raw/ingenic/ingenic_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
b/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
index ad0c905..d7b7c0f 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_nand.c
@@ -137,7 +137,7 @@ static int jz4725b_ooblayout_free(struct mtd_info *mtd, int
section,
return 0;
}
-const struct mtd_ooblayout_ops jz4725b_ooblayout_ops = {
+static const struct mtd_ooblayout_ops jz4725b_ooblayout_ops = {
.ecc = jz4725b_ooblayout_ecc,
.free = jz4725b_ooblayout_free,
};
--
2.7.4
Re: [PATCH v1 1/4] platform/x86: intel_pmc_ipc: Use BIT() macro
On Tue, Apr 09, 2019 at 08:39:39PM +0300, Andy Shevchenko wrote: > On Tue, Apr 09, 2019 at 10:07:35AM -0700, sathyanarayanan kuppuswamy wrote: > > On 4/9/19 4:25 AM, Andy Shevchenko wrote: > > > Use BIT() and BIT_MASK() macros for definitions. > > Looks good to me. > > Thanks! If you have no further comments, can you provide your tag here? > > > > /* PMC register bit definitions */ > > > /* PMC_CFG_REG bit masks */ > > > -#define PMC_CFG_NO_REBOOT_MASK (1 << 4) > > > +#define PMC_CFG_NO_REBOOT_MASK BIT_MASK(4) > > > #define PMC_CFG_NO_REBOOT_EN(1 << 4) > > > #define PMC_CFG_NO_REBOOT_DIS (0 << 4) > > Do we need 0 << 4 ? > > Yes, to explicitly show that this is a value for NO_REBOOT masked bit(s) > (single bit in this case). > > -- > With Best Regards, > Andy Shevchenko > > -- With Best Regards, Andy Shevchenko
Re: [PATCH] of: use correct function prototype for of_overlay_fdt_apply()
On Fri, Mar 22, 2019 at 01:23:41PM +1300, Chris Packham wrote:
> When CONFIG_OF_OVERLAY is not enabled the fallback stub for
> of_overlay_fdt_apply() does not match the prototype for the case when
> CONFIG_OF_OVERLAY is enabled. Update the stub to use the correct
> function prototype.
>
> Fixes: commit 39a751a4cb7e ("of: change overlay apply input data from
> unflattened to FDT")
> Signed-off-by: Chris Packham
> ---
> include/linux/of.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied.
Rob
Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
On Wed, 10 Apr 2019 15:39:28 +0200
Boris Brezillon wrote:
> On Wed, 10 Apr 2019 21:07:47 +0800
> Yue Haibing wrote:
>
> > From: YueHaibing
> >
> > Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> > is set to module:
> >
> > drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> > (.text+0xef6): undefined reference to `nand_bch_free'
> > drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> > nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> > nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> > nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> >
> > CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> > because MTD_RAW_NAND need it while linked.
> >
> > Reported-by: Hulk Robot
> > Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
>
> Nope, it's not this one that introduced the regression.
>
>
>
> > Signed-off-by: YueHaibing
> > ---
> > drivers/mtd/nand/raw/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > index 615d738..0500c42 100644
> > --- a/drivers/mtd/nand/raw/Kconfig
> > +++ b/drivers/mtd/nand/raw/Kconfig
> > @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> > if MTD_RAW_NAND
> >
> > config MTD_NAND_ECC_SW_BCH
> > - tristate "Support software BCH ECC"
> > + bool "Support software BCH ECC"
> > select BCH
> > default n
> > help
>
> Should be fixed with the following diff squashed into:
>
> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC
> algorithm")
>
> --->8---
> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> index b8106651f807..06ce2b655c13 100644
> --- a/include/linux/mtd/nand_bch.h
> +++ b/include/linux/mtd/nand_bch.h
> @@ -15,7 +15,7 @@ struct mtd_info;
> struct nand_chip;
> struct nand_bch_control;
>
> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
>
> static inline int mtd_nand_has_bch(void) { return 1; }
>
> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
> *mtd);
> */
> void nand_bch_free(struct nand_bch_control *nbc);
>
> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>
> static inline int mtd_nand_has_bch(void) { return 0; }
>
> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct
> mtd_info *mtd)
>
> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
>
> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>
> #endif /* __MTD_NAND_BCH_H__ */
Sorry, I didn't look at the right branch, this part of the code was
correct, but we still have a problem to express the RAW_NAND(y) ->
SW_BCH(y) dependency.
Re: [PATCH 2/2] perf/x86/intel: Add Tremont core PMU support
On 4/10/2019 3:51 AM, Peter Zijlstra wrote:
On Tue, Apr 09, 2019 at 06:10:00PM -0700, kan.li...@linux.intel.com wrote:
The generic purpose counter 0 and fixed counter 0 have less skid.
Force :ppp events on generic purpose counter 0.
Force instruction:ppp always on fixed counter 0.
+static struct event_constraint *
+tnt_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event *event)
+{
+ struct event_constraint *c;
+
+ /*
+* :ppp means to do reduced skid PEBS,
+* which is available at PMC0 and fixed counter 0.
+*/
+ if (event->attr.precise_ip == 3) {
+ /* Force instruction:ppp in Fixed counter 0 */
+ if (event->hw.config == X86_CONFIG(.event=0xc0))
+ return &fixed_counter0_constraint;
+
+ return &counter0_constraint;
I'm confused, 0xc0 is the architectural 'instructions' event, surely we
can program that on pmc0 too?
Did we want a fixed0_counter0_constraint for that?
Yes, I will send out V2 shortly to fix it.
Thanks,
Kan
Re: [PATCH] ARM: dts: stm32: add I2C sleep pins muxing on stm32mp157
Hi Yannick On 3/29/19 11:48 AM, Yannick Fertré wrote: Add I2C sleep pins muxing for low power mode. Signed-off-by: Pierre-Yves MORDRET Signed-off-by: Yannick Fertré --- arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 29 + 1 file changed, 29 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi index 9104896..b04899f 100644 --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi @@ -213,6 +213,13 @@ }; Applied on stm32-next. Thanks. Alex
Re: [PATCH 1/2] perf/x86/intel: Support adaptive PEBS for fixed counters
On 4/10/2019 3:41 AM, Peter Zijlstra wrote:
On Tue, Apr 09, 2019 at 06:09:59PM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
Fixed counters can also generate adaptive PEBS record, if the
corresponding bit in IA32_FIXED_CTR_CTRL is set.
Otherwise, only basic record is generated.
Unconditionally set the bit when PEBS is enabled on fixed counters.
Let MSR_PEBS_CFG decide which format of PEBS record should be generated.
There is no harmful to leave the bit set.
I'll merge this back into:
Subject: perf/x86/intel: Support adaptive PEBSv4
such that this bug never existed, ok?
Yes, please.
Thanks,
Kan
Signed-off-by: Kan Liang
---
arch/x86/events/intel/core.c | 5 +
arch/x86/include/asm/perf_event.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 56df0f6..f34d92b 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2174,6 +2174,11 @@ static void intel_pmu_enable_fixed(struct perf_event
*event)
bits <<= (idx * 4);
mask = 0xfULL << (idx * 4);
+ if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip) {
+ bits |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
+ mask |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
+ }
+
rdmsrl(hwc->config_base, ctrl_val);
ctrl_val &= ~mask;
ctrl_val |= bits;
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index dcb8bac..ce0dc88 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -33,6 +33,7 @@
#define HSW_IN_TX (1ULL << 32)
#define HSW_IN_TX_CHECKPOINTED(1ULL << 33)
#define ICL_EVENTSEL_ADAPTIVE (1ULL << 34)
+#define ICL_FIXED_0_ADAPTIVE (1ULL << 32)
#define AMD64_EVENTSEL_INT_CORE_ENABLE (1ULL << 36)
#define AMD64_EVENTSEL_GUESTONLY (1ULL << 40)
--
2.7.4
Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak
On Tue, Feb 19, 2019 at 03:45:00PM +0800, pierre Kuo wrote: > The __reserved_mem_init_node will call region specific reserved memory > init codes, but once all compatibled init codes failed, the memory region > will left in memory.reserved and cause leakage. > > Take cma reserve memory DTS for example, if user declare 1MB size, > which is not align to (PAGE_SIZE << max(MAX_ORDER - 1, > pageblock_order)), rmem_cma_setup will return -EINVAL. > Meanwhile, rmem_dma_setup will also return -EINVAL since "reusable" > property is not set. If finally there is no reserved memory init pick up > this memory, kernel will left the 1MB leak in memory.reserved. > > This patch will remove this kind of memory from memory.reserved, only > when __reserved_mem_init_node return neither 0 nor -ENOENT. > > Signed-off-by: pierre Kuo > --- > drivers/of/of_reserved_mem.c | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) As no one else seems to have any comments, I've applied it. Rob
Re: [PATCH 12/12] [PROBABLY WRONG] s390: void '0' constraint in inline assembly
On Mon, 8 Apr 2019 23:26:25 +0200
Arnd Bergmann wrote:
> clang does not understand the contraint "0" in the CALL_ON_STACK()
> macro:
>
> ../arch/s390/mm/maccess.c:117:10: error: invalid input constraint '0' in asm
> return CALL_ON_STACK(_memcpy_real, S390_lowcore.nodat_stack,
>^
> ../arch/s390/include/asm/processor.h:292:20: note: expanded from macro
> 'CALL_ON_STACK'
> [_fn] "X" (fn) CALL_FMT_##nr : CALL_CLOBBER_##nr);\
> ^
> :207:1: note: expanded from here
> CALL_FMT_3
> ^
> ../arch/s390/include/asm/processor.h:267:20: note: expanded from macro
> 'CALL_FMT_3'
> #define CALL_FMT_3 CALL_FMT_2, "d" (r4)
>^
> ../arch/s390/include/asm/processor.h:266:20: note: expanded from macro
> 'CALL_FMT_2'
> #define CALL_FMT_2 CALL_FMT_1, "d" (r3)
>^
> ../arch/s390/include/asm/processor.h:265:32: note: expanded from macro
> 'CALL_FMT_1'
> #define CALL_FMT_1 CALL_FMT_0, "0" (r2)
>^
>
> I don't know what the correct fix here would be, changing it to "d" made
> it build, since clang does understand this one.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/s390/include/asm/processor.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/include/asm/processor.h
> b/arch/s390/include/asm/processor.h
> index 700c650ffd4f..84c59c99668a 100644
> --- a/arch/s390/include/asm/processor.h
> +++ b/arch/s390/include/asm/processor.h
> @@ -262,7 +262,7 @@ static __no_kasan_or_inline unsigned short stap(void)
> register unsigned long r4 asm("6") = (unsigned long)(arg5)
>
> #define CALL_FMT_0
> -#define CALL_FMT_1 CALL_FMT_0, "0" (r2)
> +#define CALL_FMT_1 CALL_FMT_0, "d" (r2)
> #define CALL_FMT_2 CALL_FMT_1, "d" (r3)
> #define CALL_FMT_3 CALL_FMT_2, "d" (r4)
> #define CALL_FMT_4 CALL_FMT_3, "d" (r5)
This is (slightly) wrong. %r2 is used as the input register for the first
argument
and the result value for the call. With your patch you force the compiler to
load
the first argument in two registers. One solution would be to CALL_FMT1 as
#define CALL_FMT1 CALL_FMT_0
It still is not optimal though as for CALL_FMT_0 the "+&d" (r2) indicates an
input but CALL_ARGS_0 does not initialize r2.
I am thinking about the following patch to cover all cases:
--
>From 91a4abbec91a9f26f84f7386f2c0f96de669b0eb Mon Sep 17 00:00:00 2001
From: Martin Schwidefsky
Date: Wed, 10 Apr 2019 15:48:43 +0200
Subject: [PATCH] s390: fine-tune stack switch helper
The CALL_ON_STACK helper currently does not work with clang and for
calls without arguments it does not initialize r2 although the contraint
is "+&d". Rework the CALL_FMT_x and the CALL_ON_STACK macros to work
with clang and produce optimal code in all cases.
Reported-by: Arnd Bergmann
Signed-off-by: Martin Schwidefsky
---
arch/s390/include/asm/processor.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/s390/include/asm/processor.h
b/arch/s390/include/asm/processor.h
index 81038ab357ce..0ee022247580 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -261,12 +261,12 @@ static __no_kasan_or_inline unsigned short stap(void)
CALL_ARGS_4(arg1, arg2, arg3, arg4);\
register unsigned long r4 asm("6") = (unsigned long)(arg5)
-#define CALL_FMT_0
-#define CALL_FMT_1 CALL_FMT_0, "0" (r2)
-#define CALL_FMT_2 CALL_FMT_1, "d" (r3)
-#define CALL_FMT_3 CALL_FMT_2, "d" (r4)
-#define CALL_FMT_4 CALL_FMT_3, "d" (r5)
-#define CALL_FMT_5 CALL_FMT_4, "d" (r6)
+#define CALL_FMT_0 "=&d" (r2) :
+#define CALL_FMT_1 "+&d" (r2) :
+#define CALL_FMT_2 CALL_FMT_1 "d" (r3),
+#define CALL_FMT_3 CALL_FMT_2 "d" (r4),
+#define CALL_FMT_4 CALL_FMT_3 "d" (r5),
+#define CALL_FMT_5 CALL_FMT_4 "d" (r6),
#define CALL_CLOBBER_5 "0", "1", "14", "cc", "memory"
#define CALL_CLOBBER_4 CALL_CLOBBER_5
@@ -286,10 +286,10 @@ static __no_kasan_or_inline unsigned short stap(void)
" stg %[_prev],%[_bc](15)\n" \
" brasl 14,%[_fn]\n"\
" la 15,0(%[_prev])\n" \
- : "+&d" (r2), [_prev] "=&a" (prev) \
- : [_stack] "a" (stack), \
+ : [_prev] "=&a" (prev), CALL_FMT_##nr \
+ [_stack] "a" (stack), \
[_bc] "i" (offsetof(struct stack_frame, back_chain)), \
- [_fn] "X" (fn) CALL_FMT_##nr : CALL_CLOBBER_##nr);\
+ [_fn] "X" (fn) : CALL_CLOBBER_##nr); \
r2; \
})
--
2.16.4
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH] ARM: dts: stm32: add power supply of otm8009a on stm32mp157c-dk2
Hi Yannick
On 3/29/19 11:13 AM, Yannick Fertré wrote:
This patch adds a new property (power-supply) to panel otm8009a (orisetech)
on stm32mp157c-dk2 & regulator v3v3 which is always set on until the
implementation of regulator driver.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 363aeb9..20ea601 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -50,6 +50,7 @@
compatible = "orisetech,otm8009a";
reg = <0>;
reset-gpios = <&gpioe 4 GPIO_ACTIVE_LOW>;
+ power-supply = <&v3v3>;
status = "okay";
port {
Applied on stm32-next. I just updated the commit message as regulator
fixed hook is no more used due to stpmic1 merge.
Thanks.
Alex
Re: [PATCH RESEND V11 4/4] arm64: dts: imx: add i.MX8QXP thermal support
:u?w]
Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
On 4/9/19 10:53 AM, Mark Rutland wrote: > On Mon, Apr 08, 2019 at 11:50:31AM +0200, Peter Zijlstra wrote: >> On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote: >>> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote: >> . >> >> Instead encode the CPU number in @pending_disable, such that we can >> tell which CPU requested the disable. This then allows us to detect >> the above scenario and even redirect the IPI to make up for the failed >> queue. >> >> Cc: Heiko Carstens >> Cc: Kees Cook >> Cc: Hendrik Brueckner >> Cc: a...@redhat.com >> Cc: Martin Schwidefsky >> Cc: Mark Rutland >> Cc: Jiri Olsa >> Reported-by: Thomas-Mich Richter >> Signed-off-by: Peter Zijlstra (Intel) > > I can't think of a nicer way of handling this, so FWIW: > > Acked-by: Mark Rutland > > Mark. > >> --- Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5. However doing an fgrep on the pending_disable member of struct perf_event reveals two more hits in file kernel/events/ringbuffer.c when events have auxiliary data. Not sure if this needs to be addresses too, just wanted to let you know. -- Thomas Richter, Dept 3252, IBM s390 Linux Development, Boeblingen, Germany -- Vorsitzender des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: [RFC patch 41/41] lib/stackdepot: Remove obsolete functions
On Wed, Apr 10, 2019 at 1:06 PM Thomas Gleixner wrote:
>
> No more users of the struct stack_trace based interfaces.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Alexander Potapenko
> ---
> include/linux/stackdepot.h |4
> lib/stackdepot.c | 20
> 2 files changed, 24 deletions(-)
>
> --- a/include/linux/stackdepot.h
> +++ b/include/linux/stackdepot.h
> @@ -23,13 +23,9 @@
>
> typedef u32 depot_stack_handle_t;
>
> -struct stack_trace;
> -
> -depot_stack_handle_t depot_save_stack(struct stack_trace *trace, gfp_t
> flags);
> depot_stack_handle_t stack_depot_save(unsigned long *entries,
> unsigned int nr_entries, gfp_t
> gfp_flags);
>
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace
> *trace);
> unsigned int stack_depot_fetch(depot_stack_handle_t handle,
>unsigned long **entries);
>
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -212,14 +212,6 @@ unsigned int stack_depot_fetch(depot_sta
> }
> EXPORT_SYMBOL_GPL(stack_depot_fetch);
>
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace
> *trace)
> -{
> - unsigned int nent = stack_depot_fetch(handle, &trace->entries);
> -
> - trace->max_entries = trace->nr_entries = nent;
> -}
> -EXPORT_SYMBOL_GPL(depot_fetch_stack);
> -
> /**
> * stack_depot_save - Save a stack trace from an array
> *
> @@ -314,15 +306,3 @@ depot_stack_handle_t stack_depot_save(un
> return retval;
> }
> EXPORT_SYMBOL_GPL(stack_depot_save);
> -
> -/**
> - * depot_save_stack - save stack in a stack depot.
> - * @trace - the stacktrace to save.
> - * @alloc_flags - flags for allocating additional memory if required.
> - */
> -depot_stack_handle_t depot_save_stack(struct stack_trace *trace,
> - gfp_t alloc_flags)
> -{
> - return stack_depot_save(trace->entries, trace->nr_entries,
> alloc_flags);
> -}
> -EXPORT_SYMBOL_GPL(depot_save_stack);
>
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Re: [PATCH RESEND V11 1/4] dt-bindings: fsl: scu: add thermal binding
On Wed, Apr 10, 2019 at 07:43:04AM +, Anson Huang wrote: > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as > system controller, the system controller is in charge of system > power, clock and thermal sensors etc. management, Linux kernel > has to communicate with system controller via MU (message unit) > IPC to get temperature from thermal sensors, this patch adds > binding doc for i.MX system controller thermal driver. > > Signed-off-by: Anson Huang > --- > Changes since V10: > - remove property "imx,sensor-resource-id". > --- > .../devicetree/bindings/arm/freescale/fsl,scu.txt| 16 > > 1 file changed, 16 insertions(+) Reviewed-by: Rob Herring
[PATCH] rtc: sirfsoc: Make sysrtc_regmap_config static
From: YueHaibing
Fix sparse warning:
drivers/rtc/rtc-sirfsoc.c:282:28: warning:
symbol 'sysrtc_regmap_config' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/rtc/rtc-sirfsoc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-sirfsoc.c b/drivers/rtc/rtc-sirfsoc.c
index 2a9e151..9ba28d1 100644
--- a/drivers/rtc/rtc-sirfsoc.c
+++ b/drivers/rtc/rtc-sirfsoc.c
@@ -279,7 +279,7 @@ static const struct of_device_id sirfsoc_rtc_of_match[] = {
{},
};
-const struct regmap_config sysrtc_regmap_config = {
+static const struct regmap_config sysrtc_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.fast_io = true,
--
2.7.4
Re: [PATCH 2/2] ARM: dts: stm32: Enable STM32F769 clock driver
Hi Gabriel
On 4/5/19 9:53 AM, Gabriel Fernandez wrote:
This patch enables clocks for STM32F769 boards.
Signed-off-by: Gabriel Fernandez
---
arch/arm/boot/dts/stm32f769-disco.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts
b/arch/arm/boot/dts/stm32f769-disco.dts
index 3c7216844a9b..6f1d0ac8c31c 100644
--- a/arch/arm/boot/dts/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -102,6 +102,10 @@
};
};
+&rcc {
+ compatible = "st,stm32f769-rcc", "st,stm32f746-rcc", "st,stm32-rcc";
+};
+
&cec {
pinctrl-0 = <&cec_pins_a>;
pinctrl-names = "default";
Even if driver part is not yet merged, this DT part can be taken as we
will run with "st,stm32f746-rcc" compatible (the current one).
So:
Applied on stm32-next.
Thanks.
Alex
[PATCH v4 10/36] thunderbolt: Configure lanes when switch is initialized
Thunderbolt 2 devices and beyond need to have additional bits set in
link controller specific registers. This includes two bits in LC_SX_CTRL
that tell the link controller which lane is connected and whether it is
upstream facing or not.
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/lc.c | 114 ++
drivers/thunderbolt/switch.c | 9 +++
drivers/thunderbolt/tb.h | 2 +
drivers/thunderbolt/tb_regs.h | 11
4 files changed, 136 insertions(+)
diff --git a/drivers/thunderbolt/lc.c b/drivers/thunderbolt/lc.c
index 2134a55ed837..a5dddf176546 100644
--- a/drivers/thunderbolt/lc.c
+++ b/drivers/thunderbolt/lc.c
@@ -19,3 +19,117 @@ int tb_lc_read_uuid(struct tb_switch *sw, u32 *uuid)
return -EINVAL;
return tb_sw_read(sw, uuid, TB_CFG_SWITCH, sw->cap_lc + TB_LC_FUSE, 4);
}
+
+static int read_lc_desc(struct tb_switch *sw, u32 *desc)
+{
+ if (!sw->cap_lc)
+ return -EINVAL;
+ return tb_sw_read(sw, desc, TB_CFG_SWITCH, sw->cap_lc + TB_LC_DESC, 1);
+}
+
+static int find_port_lc_cap(struct tb_port *port)
+{
+ struct tb_switch *sw = port->sw;
+ int start, phys, ret, size;
+ u32 desc;
+
+ ret = read_lc_desc(sw, &desc);
+ if (ret)
+ return ret;
+
+ /* Start of port LC registers */
+ start = (desc & TB_LC_DESC_SIZE_MASK) >> TB_LC_DESC_SIZE_SHIFT;
+ size = (desc & TB_LC_DESC_PORT_SIZE_MASK) >> TB_LC_DESC_PORT_SIZE_SHIFT;
+ phys = tb_phy_port_from_link(port->port);
+
+ return sw->cap_lc + start + phys * size;
+}
+
+static int tb_lc_configure_lane(struct tb_port *port, bool configure)
+{
+ bool upstream = tb_is_upstream_port(port);
+ struct tb_switch *sw = port->sw;
+ u32 ctrl, lane;
+ int cap, ret;
+
+ if (sw->generation < 2)
+ return 0;
+
+ cap = find_port_lc_cap(port);
+ if (cap < 0)
+ return cap;
+
+ ret = tb_sw_read(sw, &ctrl, TB_CFG_SWITCH, cap + TB_LC_SX_CTRL, 1);
+ if (ret)
+ return ret;
+
+ /* Resolve correct lane */
+ if (port->port % 2)
+ lane = TB_LC_SX_CTRL_L1C;
+ else
+ lane = TB_LC_SX_CTRL_L2C;
+
+ if (configure) {
+ ctrl |= lane;
+ if (upstream)
+ ctrl |= TB_LC_SX_CTRL_UPSTREAM;
+ } else {
+ ctrl &= ~lane;
+ if (upstream)
+ ctrl &= ~TB_LC_SX_CTRL_UPSTREAM;
+ }
+
+ return tb_sw_write(sw, &ctrl, TB_CFG_SWITCH, cap + TB_LC_SX_CTRL, 1);
+}
+
+/**
+ * tb_lc_configure_link() - Let LC know about configured link
+ * @sw: Switch that is being added
+ *
+ * Informs LC of both parent switch and @sw that there is established
+ * link between the two.
+ */
+int tb_lc_configure_link(struct tb_switch *sw)
+{
+ struct tb_port *up, *down;
+ int ret;
+
+ if (!sw->config.enabled || !tb_route(sw))
+ return 0;
+
+ up = tb_upstream_port(sw);
+ down = tb_port_at(tb_route(sw), tb_to_switch(sw->dev.parent));
+
+ /* Configure parent link toward this switch */
+ ret = tb_lc_configure_lane(down, true);
+ if (ret)
+ return ret;
+
+ /* Configure upstream link from this switch to the parent */
+ ret = tb_lc_configure_lane(up, true);
+ if (ret)
+ tb_lc_configure_lane(down, false);
+
+ return ret;
+}
+
+/**
+ * tb_lc_unconfigure_link() - Let LC know about unconfigured link
+ * @sw: Switch to unconfigure
+ *
+ * Informs LC of both parent switch and @sw that the link between the
+ * two does not exist anymore.
+ */
+void tb_lc_unconfigure_link(struct tb_switch *sw)
+{
+ struct tb_port *up, *down;
+
+ if (sw->is_unplugged || !sw->config.enabled || !tb_route(sw))
+ return;
+
+ up = tb_upstream_port(sw);
+ down = tb_port_at(tb_route(sw), tb_to_switch(sw->dev.parent));
+
+ tb_lc_configure_lane(up, false);
+ tb_lc_configure_lane(down, false);
+}
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 63ff4c753d89..dd218dc4781b 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1276,6 +1276,10 @@ int tb_switch_configure(struct tb_switch *sw)
if (ret)
return ret;
+ ret = tb_lc_configure_link(sw);
+ if (ret)
+ return ret;
+
return tb_plug_events_active(sw, true);
}
@@ -1486,6 +1490,7 @@ void tb_switch_remove(struct tb_switch *sw)
if (!sw->is_unplugged)
tb_plug_events_active(sw, false);
+ tb_lc_unconfigure_link(sw);
tb_switch_nvm_remove(sw);
@@ -1545,6 +1550,10 @@ int tb_switch_resume(struct tb_switch *sw)
if (err)
return err;
+ err = tb_lc_configure_link(sw);
+ if (err)
+ return err;
+
err = tb_plug_events_active(sw, true);
if
[PATCH v4 01/36] net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
The XDomain protocol messages may start as soon as Thunderbolt control
channel is started. This means that if the other host starts sending
ThunderboltIP packets early enough they will be passed to the network
driver which then gets confused because its resume hook is not called
yet.
Fix this by unregistering the ThunderboltIP protocol handler when
suspending and registering it back on resume.
Signed-off-by: Mika Westerberg
Acked-by: David S. Miller
---
drivers/net/thunderbolt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/thunderbolt.c b/drivers/net/thunderbolt.c
index c48c3a1eb1f8..fcf31335a8b6 100644
--- a/drivers/net/thunderbolt.c
+++ b/drivers/net/thunderbolt.c
@@ -1282,6 +1282,7 @@ static int __maybe_unused tbnet_suspend(struct device
*dev)
tbnet_tear_down(net, true);
}
+ tb_unregister_protocol_handler(&net->handler);
return 0;
}
@@ -1290,6 +1291,8 @@ static int __maybe_unused tbnet_resume(struct device *dev)
struct tb_service *svc = tb_to_service(dev);
struct tbnet *net = tb_service_get_drvdata(svc);
+ tb_register_protocol_handler(&net->handler);
+
netif_carrier_off(net->dev);
if (netif_running(net->dev)) {
netif_device_attach(net->dev);
--
2.20.1
[PATCH v4 06/36] thunderbolt: Do not allocate switch if depth is greater than 6
Maximum depth in Thunderbolt topology is 6 so make sure it is not
possible to allocate switches that exceed the depth limit.
While at it update tb_switch_alloc() to use upper/lower_32_bits()
following tb_switch_alloc_safe_mode().
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/icm.c| 5 ++---
drivers/thunderbolt/switch.c | 18 --
drivers/thunderbolt/tb.h | 1 +
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
index 7c923e16a7d8..bec360eef6cf 100644
--- a/drivers/thunderbolt/icm.c
+++ b/drivers/thunderbolt/icm.c
@@ -42,7 +42,6 @@
#define ICM_TIMEOUT5000/* ms */
#define ICM_APPROVE_TIMEOUT1 /* ms */
#define ICM_MAX_LINK 4
-#define ICM_MAX_DEPTH 6
/**
* struct icm - Internal connection manager private data
@@ -714,7 +713,7 @@ icm_fr_device_disconnected(struct tb *tb, const struct
icm_pkg_header *hdr)
depth = (pkg->link_info & ICM_LINK_INFO_DEPTH_MASK) >>
ICM_LINK_INFO_DEPTH_SHIFT;
- if (link > ICM_MAX_LINK || depth > ICM_MAX_DEPTH) {
+ if (link > ICM_MAX_LINK || depth > TB_SWITCH_MAX_DEPTH) {
tb_warn(tb, "invalid topology %u.%u, ignoring\n", link, depth);
return;
}
@@ -744,7 +743,7 @@ icm_fr_xdomain_connected(struct tb *tb, const struct
icm_pkg_header *hdr)
depth = (pkg->link_info & ICM_LINK_INFO_DEPTH_MASK) >>
ICM_LINK_INFO_DEPTH_SHIFT;
- if (link > ICM_MAX_LINK || depth > ICM_MAX_DEPTH) {
+ if (link > ICM_MAX_LINK || depth > TB_SWITCH_MAX_DEPTH) {
tb_warn(tb, "invalid topology %u.%u, ignoring\n", link, depth);
return;
}
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 7fa4ab076404..1e29c06947af 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1130,10 +1130,16 @@ static int tb_switch_get_generation(struct tb_switch
*sw)
struct tb_switch *tb_switch_alloc(struct tb *tb, struct device *parent,
u64 route)
{
- int i;
- int cap;
struct tb_switch *sw;
- int upstream_port = tb_cfg_get_upstream_port(tb->ctl, route);
+ int upstream_port;
+ int i, cap, depth;
+
+ /* Make sure we do not exceed maximum topology limit */
+ depth = tb_route_length(route);
+ if (depth > TB_SWITCH_MAX_DEPTH)
+ return NULL;
+
+ upstream_port = tb_cfg_get_upstream_port(tb->ctl, route);
if (upstream_port < 0)
return NULL;
@@ -1150,9 +1156,9 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct
device *parent,
/* configure switch */
sw->config.upstream_port_number = upstream_port;
- sw->config.depth = tb_route_length(route);
- sw->config.route_lo = route;
- sw->config.route_hi = route >> 32;
+ sw->config.depth = depth;
+ sw->config.route_hi = upper_32_bits(route);
+ sw->config.route_lo = lower_32_bits(route);
sw->config.enabled = 0;
/* initialize ports */
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index f7b0c43c29a7..93c1ea21feeb 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -43,6 +43,7 @@ struct tb_switch_nvm {
};
#define TB_SWITCH_KEY_SIZE 32
+#define TB_SWITCH_MAX_DEPTH6
/**
* struct tb_switch - a thunderbolt switch
--
2.20.1
Re: [RFC patch 19/41] lib/stackdepot: Provide functions which operate on plain storage arrays
On Wed, Apr 10, 2019 at 1:05 PM Thomas Gleixner wrote:
>
> The struct stack_trace indirection in the stack depot functions is a truly
> pointless excercise which requires horrible code at the callsites.
>
> Provide interfaces based on plain storage arrays.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Alexander Potapenko
> ---
> include/linux/stackdepot.h |4 ++
> lib/stackdepot.c | 66
> -
> 2 files changed, 51 insertions(+), 19 deletions(-)
>
> --- a/include/linux/stackdepot.h
> +++ b/include/linux/stackdepot.h
> @@ -26,7 +26,11 @@ typedef u32 depot_stack_handle_t;
> struct stack_trace;
>
> depot_stack_handle_t depot_save_stack(struct stack_trace *trace, gfp_t
> flags);
> +depot_stack_handle_t stack_depot_save(unsigned long *entries,
> + unsigned int nr_entries, gfp_t
> gfp_flags);
>
> void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace
> *trace);
> +unsigned int stack_depot_fetch(depot_stack_handle_t handle,
> + unsigned long **entries);
>
> #endif
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -194,40 +194,56 @@ static inline struct stack_record *find_
> return NULL;
> }
>
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace
> *trace)
> +/**
> + * stack_depot_fetch - Fetch stack entries from a depot
> + *
> + * @entries: Pointer to store the entries address
> + */
> +unsigned int stack_depot_fetch(depot_stack_handle_t handle,
> + unsigned long **entries)
> {
> union handle_parts parts = { .handle = handle };
> void *slab = stack_slabs[parts.slabindex];
> size_t offset = parts.offset << STACK_ALLOC_ALIGN;
> struct stack_record *stack = slab + offset;
>
> - trace->nr_entries = trace->max_entries = stack->size;
> - trace->entries = stack->entries;
> - trace->skip = 0;
> + *entries = stack->entries;
> + return stack->size;
> +}
> +EXPORT_SYMBOL_GPL(stack_depot_fetch);
> +
> +void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace
> *trace)
> +{
> + unsigned int nent = stack_depot_fetch(handle, &trace->entries);
> +
> + trace->max_entries = trace->nr_entries = nent;
> }
> EXPORT_SYMBOL_GPL(depot_fetch_stack);
>
> /**
> - * depot_save_stack - save stack in a stack depot.
> - * @trace - the stacktrace to save.
> - * @alloc_flags - flags for allocating additional memory if required.
> + * stack_depot_save - Save a stack trace from an array
> *
> - * Returns the handle of the stack struct stored in depot.
> + * @entries: Pointer to storage array
> + * @nr_entries:Size of the storage array
> + * @alloc_flags: Allocation gfp flags
> + *
> + * Returns the handle of the stack struct stored in depot
> */
> -depot_stack_handle_t depot_save_stack(struct stack_trace *trace,
> - gfp_t alloc_flags)
> +depot_stack_handle_t stack_depot_save(unsigned long *entries,
> + unsigned int nr_entries,
> + gfp_t alloc_flags)
> {
> - u32 hash;
> - depot_stack_handle_t retval = 0;
> struct stack_record *found = NULL, **bucket;
> - unsigned long flags;
> + depot_stack_handle_t retval = 0;
> struct page *page = NULL;
> void *prealloc = NULL;
> + unsigned long flags;
> + u32 hash;
>
> - if (unlikely(trace->nr_entries == 0))
> + if (unlikely(nr_entries == 0))
> goto fast_exit;
>
> - hash = hash_stack(trace->entries, trace->nr_entries);
> + hash = hash_stack(entries, nr_entries);
> bucket = &stack_table[hash & STACK_HASH_MASK];
>
> /*
> @@ -235,8 +251,8 @@ depot_stack_handle_t depot_save_stack(st
> * The smp_load_acquire() here pairs with smp_store_release() to
> * |bucket| below.
> */
> - found = find_stack(smp_load_acquire(bucket), trace->entries,
> - trace->nr_entries, hash);
> + found = find_stack(smp_load_acquire(bucket), entries,
> + nr_entries, hash);
> if (found)
> goto exit;
>
> @@ -264,10 +280,10 @@ depot_stack_handle_t depot_save_stack(st
>
> spin_lock_irqsave(&depot_lock, flags);
>
> - found = find_stack(*bucket, trace->entries, trace->nr_entries, hash);
> + found = find_stack(*bucket, entries, nr_entries, hash);
> if (!found) {
> struct stack_record *new =
> - depot_alloc_stack(trace->entries, trace->nr_entries,
> + depot_alloc_stack(entries, nr_entries,
> hash, &prealloc, alloc_flags);
> if (new) {
> new->next = *bucket;
> @@ -297,4 +313,16 @@ depot_stack_handle_t depot_sav
[PATCH v2 5/6] dt-bindings: leds: Add LED bindings for the LM36274
Add the LM36274 LED specific bindings.
Signed-off-by: Dan Murphy
---
v2 - Changed 29-V to 29V - https://lore.kernel.org/patchwork/patch/1058779/
.../devicetree/bindings/leds/leds-lm36274.txt | 82 +++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm36274.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm36274.txt
b/Documentation/devicetree/bindings/leds/leds-lm36274.txt
new file mode 100644
index ..329393700191
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm36274.txt
@@ -0,0 +1,82 @@
+* Texas Instruments LM36274 4-Channel LCD Backlight Driver w/Integrated Bias
+
+The LM36274 is an integrated four-channel WLED driver and LCD bias supply.
+The backlight boost provides the power to bias four parallel LED strings with
+up to 29V total output voltage. The 11-bit LED current is programmable via
+the I2C bus and/or controlled via a logic level PWM input from 60 μA to 30 mA.
+
+Parent device properties are documented in ../mfd/ti_lmu.txt
+Regulator properties are documented in ../regulator/lm363x-regulator.txt
+
+Required backlight properties:
+ - compatible:
+ "ti,lm36274-backlight"
+ - reg : 0
+ - #address-cells : 1
+ - #size-cells : 0
+ - led-sources : Indicates which LED strings will be enabled.
+ Values from 0-3, sources is 0 based so strings will be
+ source value + 1.
+
+Optional backlight properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger :
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+HVLED string 1 and 3 are controlled by control bank A and HVLED 2 string is
+controlled by control bank B.
+
+lm36274@11 {
+ compatible = "ti,lm36274";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x11>;
+
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lm363x-regulator";
+
+ enable-gpios = <&pioC 0 GPIO_ACTIVE_HIGH>,
+ <&pioC 1 GPIO_ACTIVE_HIGH>;
+
+ vboost {
+ regulator-name = "lcd_boost";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <715>;
+ regulator-always-on;
+ };
+
+ vpos {
+ regulator-name = "lcd_vpos";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <650>;
+ };
+
+ vneg {
+ regulator-name = "lcd_vneg";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <650>;
+ };
+ };
+
+ backlight {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lm36274-backlight";
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 2>;
+ label = "white:backlight_cluster";
+ linux,default-trigger = "backlight";
+ };
+ };
+};
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/symlink/lm36274.pdf
--
2.21.0.5.gaeb582a983
[PATCH v4 29/36] thunderbolt: Add XDomain UUID exchange support
Currently ICM has been handling XDomain UUID exchange so there was no
need to have it in the driver yet. However, since now we are going to
add the same capabilities to the software connection manager it needs to
be handled properly.
For this reason modify the driver XDomain protocol handling so that if
the remote domain UUID is not filled in the core will query it first and
only then start the normal property exchange flow.
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/tb_msgs.h | 11 +++
drivers/thunderbolt/xdomain.c | 136 +++---
include/linux/thunderbolt.h | 8 ++
3 files changed, 145 insertions(+), 10 deletions(-)
diff --git a/drivers/thunderbolt/tb_msgs.h b/drivers/thunderbolt/tb_msgs.h
index 02c84aa3d018..afbe1d29bb03 100644
--- a/drivers/thunderbolt/tb_msgs.h
+++ b/drivers/thunderbolt/tb_msgs.h
@@ -492,6 +492,17 @@ struct tb_xdp_header {
u32 type;
};
+struct tb_xdp_uuid {
+ struct tb_xdp_header hdr;
+};
+
+struct tb_xdp_uuid_response {
+ struct tb_xdp_header hdr;
+ uuid_t src_uuid;
+ u32 src_route_hi;
+ u32 src_route_lo;
+};
+
struct tb_xdp_properties {
struct tb_xdp_header hdr;
uuid_t src_uuid;
diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
index 44d3b2e486cd..5118d46702d5 100644
--- a/drivers/thunderbolt/xdomain.c
+++ b/drivers/thunderbolt/xdomain.c
@@ -18,6 +18,7 @@
#include "tb.h"
#define XDOMAIN_DEFAULT_TIMEOUT5000 /* ms */
+#define XDOMAIN_UUID_RETRIES 10
#define XDOMAIN_PROPERTIES_RETRIES 60
#define XDOMAIN_PROPERTIES_CHANGED_RETRIES 10
@@ -222,6 +223,50 @@ static int tb_xdp_handle_error(const struct tb_xdp_header
*hdr)
return 0;
}
+static int tb_xdp_uuid_request(struct tb_ctl *ctl, u64 route, int retry,
+ uuid_t *uuid)
+{
+ struct tb_xdp_uuid_response res;
+ struct tb_xdp_uuid req;
+ int ret;
+
+ memset(&req, 0, sizeof(req));
+ tb_xdp_fill_header(&req.hdr, route, retry % 4, UUID_REQUEST,
+ sizeof(req));
+
+ memset(&res, 0, sizeof(res));
+ ret = __tb_xdomain_request(ctl, &req, sizeof(req),
+ TB_CFG_PKG_XDOMAIN_REQ, &res, sizeof(res),
+ TB_CFG_PKG_XDOMAIN_RESP,
+ XDOMAIN_DEFAULT_TIMEOUT);
+ if (ret)
+ return ret;
+
+ ret = tb_xdp_handle_error(&res.hdr);
+ if (ret)
+ return ret;
+
+ uuid_copy(uuid, &res.src_uuid);
+ return 0;
+}
+
+static int tb_xdp_uuid_response(struct tb_ctl *ctl, u64 route, u8 sequence,
+ const uuid_t *uuid)
+{
+ struct tb_xdp_uuid_response res;
+
+ memset(&res, 0, sizeof(res));
+ tb_xdp_fill_header(&res.hdr, route, sequence, UUID_RESPONSE,
+ sizeof(res));
+
+ uuid_copy(&res.src_uuid, uuid);
+ res.src_route_hi = upper_32_bits(route);
+ res.src_route_lo = lower_32_bits(route);
+
+ return __tb_xdomain_response(ctl, &res, sizeof(res),
+TB_CFG_PKG_XDOMAIN_RESP);
+}
+
static int tb_xdp_error_response(struct tb_ctl *ctl, u64 route, u8 sequence,
enum tb_xdp_error error)
{
@@ -512,7 +557,14 @@ static void tb_xdp_handle_request(struct work_struct *work)
break;
}
+ case UUID_REQUEST_OLD:
+ case UUID_REQUEST:
+ ret = tb_xdp_uuid_response(ctl, route, sequence, uuid);
+ break;
+
default:
+ tb_xdp_error_response(ctl, route, sequence,
+ ERROR_NOT_SUPPORTED);
break;
}
@@ -839,6 +891,55 @@ static void tb_xdomain_restore_paths(struct tb_xdomain *xd)
}
}
+static void tb_xdomain_get_uuid(struct work_struct *work)
+{
+ struct tb_xdomain *xd = container_of(work, typeof(*xd),
+get_uuid_work.work);
+ struct tb *tb = xd->tb;
+ uuid_t uuid;
+ int ret;
+
+ ret = tb_xdp_uuid_request(tb->ctl, xd->route, xd->uuid_retries, &uuid);
+ if (ret < 0) {
+ if (xd->uuid_retries-- > 0) {
+ queue_delayed_work(xd->tb->wq, &xd->get_uuid_work,
+ msecs_to_jiffies(100));
+ } else {
+ dev_dbg(&xd->dev, "failed to read remote UUID\n");
+ }
+ return;
+ }
+
+ if (uuid_equal(&uuid, xd->local_uuid)) {
+ dev_dbg(&xd->dev, "intra-domain loop detected\n");
+ return;
+ }
+
+ /*
+* If the UUID is different, there is another domain connected
+* so mark this one unplugged and wait for the connection
+* manager to replace it.
+*/
+ if (xd->remote_uui
Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
On Wed, 10 Apr 2019 21:07:47 +0800
Yue Haibing wrote:
> From: YueHaibing
>
> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> is set to module:
>
> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> (.text+0xef6): undefined reference to `nand_bch_free'
> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
>
> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> because MTD_RAW_NAND need it while linked.
>
> Reported-by: Hulk Robot
> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
Nope, it's not this one that introduced the regression.
> Signed-off-by: YueHaibing
> ---
> drivers/mtd/nand/raw/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index 615d738..0500c42 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> if MTD_RAW_NAND
>
> config MTD_NAND_ECC_SW_BCH
> - tristate "Support software BCH ECC"
> + bool "Support software BCH ECC"
> select BCH
> default n
> help
Should be fixed with the following diff squashed into:
51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
--->8---
diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index b8106651f807..06ce2b655c13 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -15,7 +15,7 @@ struct mtd_info;
struct nand_chip;
struct nand_bch_control;
-#if defined(CONFIG_MTD_NAND_ECC_BCH)
+#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
static inline int mtd_nand_has_bch(void) { return 1; }
@@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
*/
void nand_bch_free(struct nand_bch_control *nbc);
-#else /* !CONFIG_MTD_NAND_ECC_BCH */
+#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
static inline int mtd_nand_has_bch(void) { return 0; }
@@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct
mtd_info *mtd)
static inline void nand_bch_free(struct nand_bch_control *nbc) {}
-#endif /* CONFIG_MTD_NAND_ECC_BCH */
+#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
#endif /* __MTD_NAND_BCH_H__ */
[PATCH v4 31/36] thunderbolt: Make tb_switch_alloc() return ERR_PTR()
In order to detect possible connections to other domains we need to be
able to find out why tb_switch_alloc() fails so make it return ERR_PTR()
instead. This allows the caller to differentiate between errors such as
-ENOMEM which comes from the kernel and for instance -EIO which comes
from the hardware when trying to access the possible switch.
Convert all the current call sites to handle this properly.
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/icm.c| 6 +++---
drivers/thunderbolt/switch.c | 36
drivers/thunderbolt/tb.c | 6 +++---
3 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
index 805958e53c58..d1f6ec89763c 100644
--- a/drivers/thunderbolt/icm.c
+++ b/drivers/thunderbolt/icm.c
@@ -468,7 +468,7 @@ static void add_switch(struct tb_switch *parent_sw, u64
route,
pm_runtime_get_sync(&parent_sw->dev);
sw = tb_switch_alloc(parent_sw->tb, &parent_sw->dev, route);
- if (!sw)
+ if (IS_ERR(sw))
goto out;
sw->uuid = kmemdup(uuid, sizeof(*uuid), GFP_KERNEL);
@@ -1848,8 +1848,8 @@ static int icm_start(struct tb *tb)
tb->root_switch = tb_switch_alloc_safe_mode(tb, &tb->dev, 0);
else
tb->root_switch = tb_switch_alloc(tb, &tb->dev, 0);
- if (!tb->root_switch)
- return -ENODEV;
+ if (IS_ERR(tb->root_switch))
+ return PTR_ERR(tb->root_switch);
/*
* NVM upgrade has not been tested on Apple systems and they
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index ecf53d986a5c..460f2bcad40a 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1450,30 +1450,32 @@ static int tb_switch_get_generation(struct tb_switch
*sw)
* separately. The returned switch should be released by calling
* tb_switch_put().
*
- * Return: Pointer to the allocated switch or %NULL in case of failure
+ * Return: Pointer to the allocated switch or ERR_PTR() in case of
+ * failure.
*/
struct tb_switch *tb_switch_alloc(struct tb *tb, struct device *parent,
u64 route)
{
struct tb_switch *sw;
int upstream_port;
- int i, cap, depth;
+ int i, ret, depth;
/* Make sure we do not exceed maximum topology limit */
depth = tb_route_length(route);
if (depth > TB_SWITCH_MAX_DEPTH)
- return NULL;
+ return ERR_PTR(-EADDRNOTAVAIL);
upstream_port = tb_cfg_get_upstream_port(tb->ctl, route);
if (upstream_port < 0)
- return NULL;
+ return ERR_PTR(upstream_port);
sw = kzalloc(sizeof(*sw), GFP_KERNEL);
if (!sw)
- return NULL;
+ return ERR_PTR(-ENOMEM);
sw->tb = tb;
- if (tb_cfg_read(tb->ctl, &sw->config, route, 0, TB_CFG_SWITCH, 0, 5))
+ ret = tb_cfg_read(tb->ctl, &sw->config, route, 0, TB_CFG_SWITCH, 0, 5);
+ if (ret)
goto err_free_sw_ports;
tb_dbg(tb, "current switch config:\n");
@@ -1489,8 +1491,10 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct
device *parent,
/* initialize ports */
sw->ports = kcalloc(sw->config.max_port_number + 1, sizeof(*sw->ports),
GFP_KERNEL);
- if (!sw->ports)
+ if (!sw->ports) {
+ ret = -ENOMEM;
goto err_free_sw_ports;
+ }
for (i = 0; i <= sw->config.max_port_number; i++) {
/* minimum setup for tb_find_cap and tb_drom_read to work */
@@ -1500,16 +1504,16 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct
device *parent,
sw->generation = tb_switch_get_generation(sw);
- cap = tb_switch_find_vse_cap(sw, TB_VSE_CAP_PLUG_EVENTS);
- if (cap < 0) {
+ ret = tb_switch_find_vse_cap(sw, TB_VSE_CAP_PLUG_EVENTS);
+ if (ret < 0) {
tb_sw_warn(sw, "cannot find TB_VSE_CAP_PLUG_EVENTS aborting\n");
goto err_free_sw_ports;
}
- sw->cap_plug_events = cap;
+ sw->cap_plug_events = ret;
- cap = tb_switch_find_vse_cap(sw, TB_VSE_CAP_LINK_CONTROLLER);
- if (cap > 0)
- sw->cap_lc = cap;
+ ret = tb_switch_find_vse_cap(sw, TB_VSE_CAP_LINK_CONTROLLER);
+ if (ret > 0)
+ sw->cap_lc = ret;
/* Root switch is always authorized */
if (!route)
@@ -1528,7 +1532,7 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct
device *parent,
kfree(sw->ports);
kfree(sw);
- return NULL;
+ return ERR_PTR(ret);
}
/**
@@ -1543,7 +1547,7 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct
device *parent,
*
* The returned switch must be released by calling tb_switch_put().
*
- * Return: Pointer to the allocated switch or %NULL in case of failure
+
[PATCH v2 3/6] mfd: ti-lmu: Add LM36274 support to the ti-lmu
Add the LM36274 register support to the ti-lmu MFD driver.
Signed-off-by: Dan Murphy
---
v2 - No changes - https://lore.kernel.org/patchwork/patch/1058780/
drivers/mfd/Kconfig | 5 ++---
drivers/mfd/ti-lmu.c| 14 ++
include/linux/mfd/ti-lmu-register.h | 23 +++
include/linux/mfd/ti-lmu.h | 4
4 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fcae244229b3..5606411038bb 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1311,9 +1311,8 @@ config MFD_TI_LMU
select REGMAP_I2C
help
Say yes here to enable support for TI LMU chips.
-
- TI LMU MFD supports LM3532, LM3631, LM3632, LM3633, and LM3695.
- It consists of backlight, LED and regulator driver.
+ TI LMU MFD supports LM3532, LM3631, LM3632, LM3633, LM3695 and
+ LM36274. It consists of backlight, LED and regulator driver.
It provides consistent device controls for lighting functions.
config MFD_OMAP_USB_HOST
diff --git a/drivers/mfd/ti-lmu.c b/drivers/mfd/ti-lmu.c
index 89b1c5b584af..691ab9dd6236 100644
--- a/drivers/mfd/ti-lmu.c
+++ b/drivers/mfd/ti-lmu.c
@@ -111,6 +111,17 @@ static const struct mfd_cell lm3695_devices[] = {
},
};
+static const struct mfd_cell lm36274_devices[] = {
+ LM363X_REGULATOR(LM36274_BOOST),
+ LM363X_REGULATOR(LM36274_LDO_POS),
+ LM363X_REGULATOR(LM36274_LDO_NEG),
+ {
+ .name = "lm36274-leds",
+ .id= LM36274,
+ .of_compatible = "ti,lm36274-backlight",
+ },
+};
+
#define TI_LMU_DATA(chip, max_reg) \
static const struct ti_lmu_data chip##_data = \
{ \
@@ -123,6 +134,7 @@ TI_LMU_DATA(lm3631, LM3631_MAX_REG);
TI_LMU_DATA(lm3632, LM3632_MAX_REG);
TI_LMU_DATA(lm3633, LM3633_MAX_REG);
TI_LMU_DATA(lm3695, LM3695_MAX_REG);
+TI_LMU_DATA(lm36274, LM36274_MAX_REG);
static int ti_lmu_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
@@ -191,6 +203,7 @@ static const struct of_device_id ti_lmu_of_match[] = {
{ .compatible = "ti,lm3632", .data = &lm3632_data },
{ .compatible = "ti,lm3633", .data = &lm3633_data },
{ .compatible = "ti,lm3695", .data = &lm3695_data },
+ { .compatible = "ti,lm36274", .data = &lm36274_data },
{ }
};
MODULE_DEVICE_TABLE(of, ti_lmu_of_match);
@@ -200,6 +213,7 @@ static const struct i2c_device_id ti_lmu_ids[] = {
{ "lm3632", LM3632 },
{ "lm3633", LM3633 },
{ "lm3695", LM3695 },
+ { "lm36274", LM36274 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ti_lmu_ids);
diff --git a/include/linux/mfd/ti-lmu-register.h
b/include/linux/mfd/ti-lmu-register.h
index 76998b01764b..076d8dea38fd 100644
--- a/include/linux/mfd/ti-lmu-register.h
+++ b/include/linux/mfd/ti-lmu-register.h
@@ -189,4 +189,27 @@
#define LM3695_REG_BRT_MSB 0x14
#define LM3695_MAX_REG 0x14
+
+/* LM36274 */
+#define LM36274_REG_REV0x01
+#define LM36274_REG_BL_CFG_1 0x02
+#define LM36274_REG_BL_CFG_2 0x03
+#define LM36274_REG_BRT_LSB0x04
+#define LM36274_REG_BRT_MSB0x05
+#define LM36274_REG_BL_EN 0x08
+
+#define LM36274_REG_BIAS_CONFIG_1 0x09
+#define LM36274_EXT_EN_MASKBIT(0)
+#define LM36274_EN_VNEG_MASK BIT(1)
+#define LM36274_EN_VPOS_MASK BIT(2)
+
+#define LM36274_REG_BIAS_CONFIG_2 0x0a
+#define LM36274_REG_BIAS_CONFIG_3 0x0b
+#define LM36274_REG_VOUT_BOOST 0x0c
+#define LM36274_REG_VOUT_POS 0x0d
+#define LM36274_REG_VOUT_NEG 0x0e
+#define LM36274_VOUT_MASK 0x3F
+
+#define LM36274_MAX_REG0x13
+
#endif
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index 54e9d272e81c..0957598c7d41 100644
--- a/include/linux/mfd/ti-lmu.h
+++ b/include/linux/mfd/ti-lmu.h
@@ -26,6 +26,7 @@ enum ti_lmu_id {
LM3632,
LM3633,
LM3695,
+ LM36274,
LMU_MAX_ID,
};
@@ -67,6 +68,9 @@ enum lm363x_regulator_id {
LM3632_BOOST, /* Boost output */
LM3632_LDO_POS, /* Positive display bias output */
LM3632_LDO_NEG, /* Negative display bias output */
+ LM36274_BOOST, /* Boost output */
+ LM36274_LDO_POS,/* Positive display bias output */
+ LM36274_LDO_NEG,/* Negative display bias output */
};
/**
--
2.21.0.5.gaeb582a983
[PATCH v2 2/6] dt-bindings: mfd: Add lm36274 bindings to ti-lmu
Add the LM36274 backlight driver with regulator support.
This is a multi-function device for backlight applications.
Backlight properties will be documented in it's a supplemental
bindings document.
Regulator support is documented in the regulator/lm363x-regulator.txt
http://www.ti.com/lit/ds/symlink/lm36274.pdf
Signed-off-by: Dan Murphy
---
v2 - No changes - https://lore.kernel.org/patchwork/patch/1058776/
.../devicetree/bindings/mfd/ti-lmu.txt| 54 +++
1 file changed, 54 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
index a948a8f41b2c..6ada671c1038 100644
--- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
+++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
@@ -8,6 +8,7 @@ TI LMU driver supports lighting devices below.
LM3632 Backlight and regulator
LM3633 Backlight, LED and fault monitor
LM3695 Backlight
+ LM36274 Backlight and regulator
Required properties:
- compatible: Should be one of:
@@ -15,11 +16,13 @@ Required properties:
"ti,lm3632"
"ti,lm3633"
"ti,lm3695"
+ "ti,lm36274"
- reg: I2C slave address.
0x11 for LM3632
0x29 for LM3631
0x36 for LM3633
0x63 for LM3695
+ 0x11 for LM36274
Optional property:
- enable-gpios: A GPIO specifier for hardware enable pin.
@@ -50,12 +53,14 @@ Optional nodes:
- compatible: Should be one of:
"ti,lm3633-fault-monitor"
- leds: LED properties for LM3633. Please refer to [2].
+ LED properties for LM36274. Please refer to [4].
- regulators: Regulator properties for LM3631 and LM3632.
Please refer to [3].
[1] ../leds/backlight/ti-lmu-backlight.txt
[2] ../leds/leds-lm3633.txt
[3] ../regulator/lm363x-regulator.txt
+[4] ../leds/leds-lm36274.txt
lm3631@29 {
compatible = "ti,lm3631";
@@ -213,3 +218,52 @@ lm3695@63 {
};
};
};
+
+lm36274@11 {
+ compatible = "ti,lm36274";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x11>;
+
+ enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lm363x-regulator";
+
+ enable-gpios = <&pioC 0 GPIO_ACTIVE_HIGH>,
+ <&pioC 1 GPIO_ACTIVE_HIGH>;
+
+ vboost {
+ regulator-name = "lcd_boost";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <715>;
+ regulator-always-on;
+ };
+
+ vpos {
+ regulator-name = "lcd_vpos";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <650>;
+ };
+
+ vneg {
+ regulator-name = "lcd_vneg";
+ regulator-min-microvolt = <400>;
+ regulator-max-microvolt = <650>;
+ };
+ };
+
+ backlight {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lm36274-backlight";
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 2>;
+ label = "white:backlight_cluster";
+ linux,default-trigger = "backlight";
+ };
+ };
+};
--
2.21.0.5.gaeb582a983
[PATCH v2 6/6] leds: lm36274: Introduce the TI LM36274 LED driver
Introduce the LM36274 LED driver. This driver uses the ti-lmu
MFD driver to probe this LED driver. The driver configures only the
LED registers and enables the outputs according to the config file.
The driver utilizes the ti-lmu-led-common framework to set the brightness
bits.
Signed-off-by: Dan Murphy
---
v2 - No changes - https://lore.kernel.org/patchwork/patch/1058778/
drivers/leds/Kconfig| 9 +-
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm36274.c | 174
3 files changed, 183 insertions(+), 1 deletion(-)
create mode 100644 drivers/leds/leds-lm36274.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2d1576f4d5d6..c0bf59544886 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -783,12 +783,19 @@ config LEDS_LM3697
Say Y to enable the LM3697 LED driver for TI LMU devices.
This supports the LED device LM3697.
+config LEDS_LM36274
+ tristate "LED driver for LM36274"
+ depends on LEDS_TI_LMU_COMMON
+ help
+ Say Y to enable the LM36274 LED driver for TI LMU devices.
+ This supports the LED device LM36274.
+
config LEDS_TI_LMU_COMMON
tristate "LED driver for TI LMU"
help
Say Y to enable the LED driver for TI LMU devices.
This supports common features between the TI LM3532, LM3631, LM3632,
- LM3633, LM3695 and LM3697.
+ LM3633, LM3695, LM3697 and LM36274
comment "LED Triggers"
source "drivers/leds/trigger/Kconfig"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2eb0225d8dc6..7ff67215b38c 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_LEDS_LM3692X)+= leds-lm3692x.o
obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o
+obj-$(CONFIG_LEDS_LM36274) += leds-lm36274.o
obj-$(CONFIG_LEDS_TI_LMU_COMMON) += ti-lmu-led-common.o
# LED SPI Drivers
diff --git a/drivers/leds/leds-lm36274.c b/drivers/leds/leds-lm36274.c
new file mode 100644
index ..6a419c47c47f
--- /dev/null
+++ b/drivers/leds/leds-lm36274.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0
+// TI LM36274 LED chip family driver
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define LM36274_MAX_STRINGS4
+#define LM36274_BL_EN BIT(4)
+
+/**
+ * struct lm36274
+ * @pdev: platform device
+ * @led_dev: led class device
+ * @lmu_data: Register and setting values for common code
+ * @regmap: Devices register map
+ * @dev: Pointer to the devices device struct
+ * @led_sources - The LED strings supported in this array
+ * @num_leds - Number of LED strings are supported in this array
+ */
+struct lm36274 {
+ struct platform_device *pdev;
+ struct led_classdev led_dev;
+ struct ti_lmu_bank lmu_data;
+ struct regmap *regmap;
+ struct device *dev;
+
+ u32 led_sources[LM36274_MAX_STRINGS];
+ int num_leds;
+};
+
+static int lm36274_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brt_val)
+{
+ struct lm36274 *led = container_of(led_cdev, struct lm36274, led_dev);
+
+ return ti_lmu_common_set_brightness(&led->lmu_data, brt_val);
+}
+
+static int lm36274_init(struct lm36274 *lm36274_data)
+{
+ int enable_val = 0;
+ int i;
+
+ for (i = 0; i < lm36274_data->num_leds; i++)
+ enable_val |= (1 << lm36274_data->led_sources[i]);
+
+ if (!enable_val) {
+ dev_err(lm36274_data->dev, "No LEDs were enabled\n");
+ return -EINVAL;
+ }
+
+ enable_val |= LM36274_BL_EN;
+
+ return regmap_write(lm36274_data->regmap, LM36274_REG_BL_EN,
+ enable_val);
+}
+
+static int lm36274_parse_dt(struct lm36274 *lm36274_data)
+{
+ struct fwnode_handle *child = NULL;
+ char label[LED_MAX_NAME_SIZE];
+ struct device *dev = &lm36274_data->pdev->dev;
+ const char *name;
+ int child_cnt;
+ int ret = -EINVAL;
+
+ /* There should only be 1 node */
+ child_cnt = device_get_child_node_count(dev);
+ if (child_cnt != 1)
+ return ret;
+
+ device_for_each_child_node(dev, child) {
+ ret = fwnode_property_read_string(child, "label", &name);
+ if (ret)
+ snprintf(label, sizeof(label),
+ "%s::", lm36274_data->pdev->name);
+ else
+ snprintf(label, sizeof(label),
+"%s:%s", lm36274_data->pdev->name, name);
+
+ lm36274_data->num_leds = fwnode_property_read_u32_array(child,
+
[PATCH v2 4/6] regulator: lm363x: Add support for LM36274
Adding regulator support for the LM36274 backlight driver.
This device can leverage this existing code as the functionality
and registers are common enough between the LM36274 and the LM363x
series of devices.
Signed-off-by: Dan Murphy
---
v2 - No changes - https://lore.kernel.org/patchwork/patch/1058781/
drivers/regulator/Kconfig| 2 +-
drivers/regulator/lm363x-regulator.c | 52
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index b7f249ee5e68..23252ae81fdf 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -362,7 +362,7 @@ config REGULATOR_LM363X
tristate "TI LM363X voltage regulators"
depends on MFD_TI_LMU
help
- This driver supports LM3631 and LM3632 voltage regulators for
+ This driver supports LM3631, LM3632 and LM36274 voltage regulators for
the LCD bias.
One boost output voltage is configurable and always on.
Other LDOs are used for the display module.
diff --git a/drivers/regulator/lm363x-regulator.c
b/drivers/regulator/lm363x-regulator.c
index 382b1cecdd93..1944677b1448 100644
--- a/drivers/regulator/lm363x-regulator.c
+++ b/drivers/regulator/lm363x-regulator.c
@@ -37,6 +37,11 @@
#define LM3632_VBOOST_MIN 450
#define LM3632_VLDO_MIN400
+/* LM36274 */
+#define LM36274_BOOST_VSEL_MAX 0x3f
+#define LM36274_LDO_VSEL_MAX 0x34
+#define LM36274_VOLTAGE_MIN400
+
/* Common */
#define LM363X_STEP_50mV 5
#define LM363X_STEP_500mV 50
@@ -217,6 +222,51 @@ static const struct regulator_desc lm363x_regulator_desc[]
= {
.enable_reg = LM3632_REG_BIAS_CONFIG,
.enable_mask= LM3632_EN_VNEG_MASK,
},
+
+ /* LM36274 */
+ {
+ .name = "vboost",
+ .of_match = "vboost",
+ .id = LM36274_BOOST,
+ .ops= &lm363x_boost_voltage_table_ops,
+ .n_voltages = LM36274_BOOST_VSEL_MAX,
+ .min_uV = LM36274_VOLTAGE_MIN,
+ .uV_step= LM363X_STEP_50mV,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .vsel_reg = LM36274_REG_VOUT_BOOST,
+ .vsel_mask = LM36274_VOUT_MASK,
+ },
+ {
+ .name = "ldo_vpos",
+ .of_match = "vpos",
+ .id = LM36274_LDO_POS,
+ .ops= &lm363x_regulator_voltage_table_ops,
+ .n_voltages = LM36274_LDO_VSEL_MAX,
+ .min_uV = LM36274_VOLTAGE_MIN,
+ .uV_step= LM363X_STEP_50mV,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .vsel_reg = LM36274_REG_VOUT_POS,
+ .vsel_mask = LM36274_VOUT_MASK,
+ .enable_reg = LM36274_REG_BIAS_CONFIG_1,
+ .enable_mask= LM36274_EN_VPOS_MASK,
+ },
+ {
+ .name = "ldo_vneg",
+ .of_match = "vneg",
+ .id = LM36274_LDO_NEG,
+ .ops= &lm363x_regulator_voltage_table_ops,
+ .n_voltages = LM36274_LDO_VSEL_MAX,
+ .min_uV = LM36274_VOLTAGE_MIN,
+ .uV_step= LM363X_STEP_50mV,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .vsel_reg = LM36274_REG_VOUT_NEG,
+ .vsel_mask = LM36274_VOUT_MASK,
+ .enable_reg = LM36274_REG_BIAS_CONFIG_1,
+ .enable_mask= LM36274_EN_VNEG_MASK,
+ },
};
static struct gpio_desc *lm363x_regulator_of_get_enable_gpio(struct device
*dev, int id)
@@ -229,9 +279,11 @@ static struct gpio_desc
*lm363x_regulator_of_get_enable_gpio(struct device *dev,
*/
switch (id) {
case LM3632_LDO_POS:
+ case LM36274_LDO_POS:
return gpiod_get_index_optional(dev, "enable", 0,
GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_NONEXCLUSIVE);
case LM3632_LDO_NEG:
+ case LM36274_LDO_NEG:
return gpiod_get_index_optional(dev, "enable", 1,
GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_NONEXCLUSIVE);
default:
--
2.21.0.5.gaeb582a983
[PATCH v4 22/36] thunderbolt: Add support for full PCIe daisy chains
Currently the software connection manager (tb.c) has only supported
creating a single PCIe tunnel, no PCIe device daisy chaining has been
supported so far. This updates the software connection manager so that
it now can create PCIe tunnels for full chain of six devices.
Because PCIe allows DMA and opens possibility for DMA attacks we change
security level to "user" meaning that PCIe tunneling requires that the
userspace authorizes the devices first. This makes it possible to block
PCIe tunneling completely while still allowing other types of tunnels to
be automatically created.
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/tb.c | 174 +++
drivers/thunderbolt/tb.h | 27 ++
2 files changed, 129 insertions(+), 72 deletions(-)
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index a62695a99835..cfc451c938fd 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -1,8 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Thunderbolt Cactus Ridge driver - bus logic (NHI independent)
+ * Thunderbolt driver - bus logic (NHI independent)
*
* Copyright (c) 2014 Andreas Noever
+ * Copyright (C) 2019, Intel Corporation
*/
#include
@@ -84,6 +85,7 @@ static void tb_scan_switch(struct tb_switch *sw)
*/
static void tb_scan_port(struct tb_port *port)
{
+ struct tb_cm *tcm = tb_priv(port->sw->tb);
struct tb_port *upstream_port;
struct tb_switch *sw;
@@ -112,7 +114,13 @@ static void tb_scan_port(struct tb_port *port)
return;
}
- sw->authorized = true;
+ /*
+* Do not send uevents until we have discovered all existing
+* tunnels and know which switches were authorized already by
+* the boot firmware.
+*/
+ if (!tcm->hotplug_active)
+ dev_set_uevent_suppress(&sw->dev, true);
if (tb_switch_add(sw)) {
tb_switch_put(sw);
@@ -212,72 +220,78 @@ static struct tb_port *tb_find_unused_down_port(struct
tb_switch *sw)
return NULL;
}
-/**
- * tb_activate_pcie_devices() - scan for and activate PCIe devices
- *
- * This method is somewhat ad hoc. For now it only supports one device
- * per port and only devices at depth 1.
- */
-static void tb_activate_pcie_devices(struct tb *tb)
+static struct tb_port *tb_find_pcie_down(struct tb_switch *sw,
+const struct tb_port *port)
{
- int i;
- int cap;
- u32 data;
- struct tb_switch *sw;
- struct tb_port *up_port;
- struct tb_port *down_port;
- struct tb_tunnel *tunnel;
- struct tb_cm *tcm = tb_priv(tb);
+ /*
+* To keep plugging devices consistently in the same PCIe
+* hierarchy, do mapping here for root switch downstream PCIe
+* ports.
+*/
+ if (!tb_route(sw)) {
+ int phy_port = tb_phy_port_from_link(port->port);
+ int index;
- /* scan for pcie devices at depth 1*/
- for (i = 1; i <= tb->root_switch->config.max_port_number; i++) {
- if (tb_is_upstream_port(&tb->root_switch->ports[i]))
- continue;
- if (tb->root_switch->ports[i].config.type != TB_TYPE_PORT)
- continue;
- if (!tb->root_switch->ports[i].remote)
- continue;
- sw = tb->root_switch->ports[i].remote->sw;
- up_port = tb_find_pci_up_port(sw);
- if (!up_port) {
- tb_sw_info(sw, "no PCIe devices found, aborting\n");
- continue;
- }
+ /*
+* Hard-coded Thunderbolt port to PCIe down port mapping
+* per controller.
+*/
+ if (tb_switch_is_cr(sw))
+ index = !phy_port ? 6 : 7;
+ else if (tb_switch_is_fr(sw))
+ index = !phy_port ? 6 : 8;
+ else
+ goto out;
+
+ /* Validate the hard-coding */
+ if (WARN_ON(index > sw->config.max_port_number))
+ goto out;
+ if (WARN_ON(!tb_port_is_pcie_down(&sw->ports[index])))
+ goto out;
+ if (WARN_ON(tb_pci_port_is_enabled(&sw->ports[index])))
+ goto out;
+
+ return &sw->ports[index];
+ }
- /* check whether port is already activated */
- cap = up_port->cap_adap;
- if (!cap)
- continue;
- if (tb_port_read(up_port, &data, TB_CFG_PORT, cap, 1))
- continue;
- if (data & 0x8000) {
- tb_port_info(up_port,
-"PCIe port already activated, aborting\n");
- continue;
- }
+out:
+ retur
Re: [PATCH] watchdog: wdat_wdt: fix get_timeleft call for wdat_wdt
On 4/10/19 5:49 AM, Bryan Tan wrote: The get_timeleft call for wdat_wdt was using ACPI_WDAT_GET_COUNTDOWN when running an action on the device, which would return the configured countdown, instead of ACPI_WDAT_GET_CURRENT_COUNTDOWN, which returns the time left before the watchdog will fire. This change corrects that. Signed-off-by: Bryan Tan Reviewed-by: Guenter Roeck --- drivers/watchdog/wdat_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/wdat_wdt.c b/drivers/watchdog/wdat_wdt.c index 56ad196..387892f 100644 --- a/drivers/watchdog/wdat_wdt.c +++ b/drivers/watchdog/wdat_wdt.c @@ -287,7 +287,7 @@ static unsigned int wdat_wdt_get_timeleft(struct watchdog_device *wdd) struct wdat_wdt *wdat = to_wdat_wdt(wdd); u32 periods = 0; - wdat_wdt_run_action(wdat, ACPI_WDAT_GET_COUNTDOWN, 0, &periods); + wdat_wdt_run_action(wdat, ACPI_WDAT_GET_CURRENT_COUNTDOWN, 0, &periods); return periods * wdat->period / 1000; }
[PATCH v2 1/6] regulator: lm363x: Make the gpio register enable flexible
The use of and enablement of the GPIO can be used across devices.
Use the enable_reg in the regulator descriptor for the register to
write.
Signed-off-by: Dan Murphy
---
v2 - No changes - https://lore.kernel.org/patchwork/patch/1058777/
drivers/regulator/lm363x-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/lm363x-regulator.c
b/drivers/regulator/lm363x-regulator.c
index c876e161052a..382b1cecdd93 100644
--- a/drivers/regulator/lm363x-regulator.c
+++ b/drivers/regulator/lm363x-regulator.c
@@ -263,8 +263,8 @@ static int lm363x_regulator_probe(struct platform_device
*pdev)
if (gpiod) {
cfg.ena_gpiod = gpiod;
-
- ret = regmap_update_bits(regmap, LM3632_REG_BIAS_CONFIG,
+ ret = regmap_update_bits(regmap,
+lm363x_regulator_desc[id].enable_reg,
LM3632_EXT_EN_MASK,
LM3632_EXT_EN_MASK);
if (ret) {
--
2.21.0.5.gaeb582a983
Re: [PATCH 23/23] watchdog: tangox_wdt: Convert to use device managed functions and other improvements
On 4/10/19 6:04 AM, Marc Gonzalez wrote: On 09/04/2019 19:24, Guenter Roeck wrote: Use device managed functions to simplify error handling, reduce source code size, improve readability, and reduce the likelyhood of bugs. Other improvements as listed below. The conversion was done automatically with coccinelle using the following semantic patches. The semantic patches and the scripts used to generate this commit log are available at https://github.com/groeck/coccinelle-patches - Drop assignments to otherwise unused variables - Drop unnecessary braces around conditional return statements - Drop empty remove function - Use devm_add_action_or_reset() for calls to clk_disable_unprepare - Replace stop on remove with call to watchdog_stop_on_unregister() - Use devm_watchdog_register_driver() to register watchdog device No devm_clk_prepare() in mainline? :-( https://lore.kernel.org/patchwork/patch/755487/ We went through that several times and never succeeded. This was the major reason why I didn't submit this series earlier since I was hoping for it to appear at some point. Unfortunately, someone always objected, typically with comments along the line that it could be misused, or citing individual examples where the current code in some driver is wrong and should be fixed instead. This isn't really a technical argument: Everything can be misused, and all code has bugs. Neither is a reason to reject a new useful API. As such, one has to assume that after refuting such arguments, and even after fixing all bugs in existing code, the opponents of the new API will come up with other reasons to reject it. At the end, I gave up trying. Feel free to try yourself; I most definitely won't try it anymore. Using devm_add_action_or_reset() is a bit more clumsy, but works just as well. Guenter
Re: [PATCH v2 0/3] Add support for STPMIC1
Hi Pascal On 4/9/19 11:07 AM, Pascal PAILLET-LME wrote: Add support for STPMIC1 on: - stm32mp157c ed1 board - stm32mp157a dk1 board - arm multi_v7_defconfig Pascal Paillet (3): changes in v2: * Describe why we disable the DMAs for PMIC ARM: dts: stm32: add stpmic1 support on stm32mp157c ed1 board ARM: dts: stm32: add stpmic1 support on stm32mp157a dk1 board ARM: multi_v7_defconfig: Enable support for STPMIC1 arch/arm/boot/dts/stm32mp157a-dk1.dts | 158 -- arch/arm/boot/dts/stm32mp157c-ed1.dts | 156 + arch/arm/configs/multi_v7_defconfig | 4 + 3 files changed, 294 insertions(+), 24 deletions(-) -- 1.9.1 Series applied on stm32-next. Linus, I saw that you made a comment on first version which has been fixed by Pascal in v2. Sorry if I don't wait for your ack (I don't have much time to finish my PR). Regards Alex
Re: [PATCH v3 1/3] perf: use hweight64 instead of hweight_long
Em Wed, Apr 10, 2019 at 10:10:42AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Apr 10, 2019 at 10:08:41AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Apr 10, 2019 at 04:16:43PM +0800, Mao Han escreveu:
> > > On 32-bits platform with more than 32 registers, the 64 bits mask is
> > > truncate to the lower 32 bits and the return value of hweight_long will
> > > always smaller than 32. When kernel outputs more than 32 registers, but
> > > the user perf program only counts 32, there will be a data mismatch
> > > result to overflow check fail.
> > >
> > > CC: Peter Zijlstra
> > > CC: Ingo Molnar
> > > CC: Arnaldo Carvalho de Melo
> > > CC: Alexander Shishkin
> > > CC: Jiri Olsa
> > > CC: Namhyung Kim
> > >
> > > Signed-off-by: Mao Han
> > > ---
> > > tools/perf/util/evsel.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > > index 7835e05..73c78be 100644
> > > --- a/tools/perf/util/evsel.c
> > > +++ b/tools/perf/util/evsel.c
> > > @@ -2322,7 +2322,7 @@ int perf_evsel__parse_sample(struct perf_evsel
> > > *evsel, union perf_event *event,
> > > if (data->user_regs.abi) {
> > > u64 mask = evsel->attr.sample_regs_user;
> > >
> > > - sz = hweight_long(mask) * sizeof(u64);
> > > + sz = hweight64(mask) * sizeof(u64);
> > > OVERFLOW_CHECK(array, sz, max_size);
> > > data->user_regs.mask = mask;
> > > data->user_regs.regs = (u64 *)array;
> >
> > Later on, in the same function, perf_evsel__parse_sample() we have:
> >
> > data->intr_regs.abi = PERF_SAMPLE_REGS_ABI_NONE;
> > if (type & PERF_SAMPLE_REGS_INTR) {
> > OVERFLOW_CHECK_u64(array);
> > data->intr_regs.abi = *array;
> > array++;
> >
> > if (data->intr_regs.abi != PERF_SAMPLE_REGS_ABI_NONE) {
> > u64 mask = evsel->attr.sample_regs_intr;
> >
> > sz = hweight_long(mask) * sizeof(u64);
> > OVERFLOW_CHECK(array, sz, max_size);
> > data->intr_regs.mask = mask;
> > data->intr_regs.regs = (u64 *)array;
> > array = (void *)array + sz;
> > }
> > }
> >
> > You forgot to convert that one, doing it for you,
>
> Also in perf_event__sample_event_size() we need to do the same thing,
> right?
and perf_event__synthesize_sample()
Done, resulting patch is at the end of this messages, and matches the
kernel, that uses only hweight64().
I've also added Fixes tags to the patches that used hweight_long() in
various places, to help with the stable trees backporting process,
please consider doing it next time.
- Arnaldo
commit 21e6dfe04861c2c1b529f2759850bc62a80ca050
Author: Mao Han
Date: Wed Apr 10 16:16:43 2019 +0800
perf evsel: Use hweight64() instead of hweight_long(attr.sample_regs_user)
On 32-bits platform with more than 32 registers, the 64 bits mask is
truncate to the lower 32 bits and the return value of hweight_long will
always smaller than 32. When kernel outputs more than 32 registers, but
the user perf program only counts 32, there will be a data mismatch
result to overflow check fail.
Signed-off-by: Mao Han
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Fixes: 6a21c0b5c2ab ("perf tools: Add core support for sampling intr
machine state regs")
Fixes: d03f2170546d ("perf tools: Expand perf_event__synthesize_sample()")
Fixes: 0f6a30150ca2 ("perf tools: Support user regs and stack in sample
parsing")
Link:
http://lkml.kernel.org/r/29ad7947dc8fd1ff0abd2093a72cc27a2446be9f.1554883878.git.han_...@c-sky.com
Signed-off-by: Arnaldo Carvalho de Melo
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 66d066f18b5b..966360844fff 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2368,7 +2368,7 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
if (data->user_regs.abi) {
u64 mask = evsel->attr.sample_regs_user;
- sz = hweight_long(mask) * sizeof(u64);
+ sz = hweight64(mask) * sizeof(u64);
OVERFLOW_CHECK(array, sz, max_size);
data->user_regs.mask = mask;
data->user_regs.regs = (u64 *)array;
@@ -2424,7 +2424,7 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
if (data->intr_regs.abi != PERF_SAMPLE_REGS_ABI_NONE) {
u64 mask = evsel->attr.sample_regs_intr;
- sz = hweight_long(mask) * sizeof(u64);
+ sz = hweight
[tip:timers/urgent] alarmtimer: Return correct remaining time
Commit-ID: 07d7e12091f4ab869cc6a4bb276399057e73b0b3
Gitweb: https://git.kernel.org/tip/07d7e12091f4ab869cc6a4bb276399057e73b0b3
Author: Andrei Vagin
AuthorDate: Sun, 7 Apr 2019 21:15:42 -0700
Committer: Thomas Gleixner
CommitDate: Wed, 10 Apr 2019 15:23:26 +0200
alarmtimer: Return correct remaining time
To calculate a remaining time, it's required to subtract the current time
from the expiration time. In alarm_timer_remaining() the arguments of
ktime_sub are swapped.
Fixes: d653d8457c76 ("alarmtimer: Implement remaining callback")
Signed-off-by: Andrei Vagin
Signed-off-by: Thomas Gleixner
Reviewed-by: Mukesh Ojha
Cc: Stephen Boyd
Cc: John Stultz
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190408041542.26338-1-ava...@gmail.com
---
kernel/time/alarmtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 2c97e8c2d29f..0519a8805aab 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -594,7 +594,7 @@ static ktime_t alarm_timer_remaining(struct k_itimer *timr,
ktime_t now)
{
struct alarm *alarm = &timr->it.alarm.alarmtimer;
- return ktime_sub(now, alarm->node.expires);
+ return ktime_sub(alarm->node.expires, now);
}
/**
3b4ba6643d ("locking/rwsem: Enhance DEBUG_RWSEMS_WARN_ON() .."): WARNING: CPU: 0 PID: 0 at kernel/locking/rwsem.h:273 up_write
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.locking/core commit 3b4ba6643d26a95e08067fca9a5da1828f9afabf Author: Waiman Long AuthorDate: Thu Apr 4 13:43:15 2019 -0400 Commit: Ingo Molnar CommitDate: Wed Apr 10 10:56:03 2019 +0200 locking/rwsem: Enhance DEBUG_RWSEMS_WARN_ON() macro Currently, the DEBUG_RWSEMS_WARN_ON() macro just dumps a stack trace when the rwsem isn't in the right state. It does not show the actual states of the rwsem. This may not be that helpful in the debugging process. Enhance the DEBUG_RWSEMS_WARN_ON() macro to also show the current content of the rwsem count and owner fields to give more information about what is wrong with the rwsem. The debug_locks_off() function is called as is done inside DEBUG_LOCKS_WARN_ON(). Signed-off-by: Waiman Long Acked-by: Peter Zijlstra Acked-by: Davidlohr Bueso Cc: Andrew Morton Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Davidlohr Bueso Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: Will Deacon Link: http://lkml.kernel.org/r/20190404174320.22416-7-long...@redhat.com Signed-off-by: Ingo Molnar a68e2c4c63 locking/rwsem: Add debug check for __down_read*() 3b4ba6643d locking/rwsem: Enhance DEBUG_RWSEMS_WARN_ON() macro 5c587ed687 locking/rwsem: Remove redundant computation of writer lock word 31437a258f Merge branch 'perf/urgent' +-+++++ | | a68e2c4c63 | 3b4ba6643d | 5c587ed687 | 31437a258f | +-+++++ | boot_successes | 40 | 0 | 0 | 11 | | boot_failures | 0 | 11 | 13 || | WARNING:at_kernel/locking/rwsem.h:#up_write | 0 | 11 | 13 || | EIP:up_write| 0 | 11 | 13 || +-+++++ [0.191085] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.197274] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.203483] double unlock: ok | ok | ok | ok | [0.205265] [ cut here ] [0.206323] DEBUG_RWSEMS_WARN_ON(sem->owner != current): count = 0x0, owner = 0x0, curr 0xd4657d00, list empty [0.207250] WARNING: CPU: 0 PID: 0 at kernel/locking/rwsem.h:273 up_write+0x9f/0xb0 [0.208118] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT 5.1.0-rc4-00065-g3b4ba66 #1 [0.208930] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [0.209691] EIP: up_write+0x9f/0xb0 [0.210021] Code: 05 b3 66 79 d4 01 39 ce be 3d af 51 d4 b9 8c cd 52 d4 0f 45 ce 8b 33 51 52 50 56 68 42 af 51 d4 68 b8 af 51 d4 e8 51 16 fb ff <0f> 0b 83 c4 18 eb b3 8d 76 00 8d bc 27 00 00 00 00 3e 8d 74 26 00 [0.211716] EAX: 0062 EBX: d46c49e0 ECX: d36c6044 EDX: 0002 [0.212294] ESI: EDI: d3990d40 EBP: d464bf34 ESP: d464bf14 [0.212874] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210286 [0.213495] CR0: 80050033 CR2: CR3: 14a12000 CR4: 000406b0 [0.214076] DR0: DR1: DR2: DR3: [0.214657] DR6: fffe0ff0 DR7: 0400 [0.215018] Call Trace: [0.215253] double_unlock_wsem+0x21/0x30 [0.215626] dotest+0x2a/0x5c0 [0.215918] locking_selftest+0x4d6/0x1cc0 [0.216301] start_kernel+0x358/0x42c [0.216642] i386_start_kernel+0xac/0xb0 [0.217013] startup_32_smp+0x164/0x170 [0.217371] irq event stamp: 385 [0.217675] hardirqs last enabled at (385): [] vprintk_emit+0x135/0x370 [0.218373] hardirqs last disabled at (384): [] vprintk_emit+0x4c/0x370 [0.219063] softirqs last enabled at (0): [<>] (null) [0.219615] softirqs last disabled at (0): [<>] (null) [0.220173] random: get_random_bytes called from print_oops_end_marker+0x4f/0x60 with crng_init=0 [0.220988] ---[ end trace 7d35dc4b16298f6a ]--- [0.221416] ok | ok | ok | # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 5c587ed687faed2eb0afdd669ddd167d0d940236 5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539 -- git bisect bad fb346fd9fc081c3d978c3f3d26d39334527a2662 # 20:06 B 0 11 35 10 locking/lock_events: Make lock_events available for all archs & other locks git bisect good eecec78
[PATCH] spi: spi-mem: Make spi_mem_default_supports_op() static inline
From: YueHaibing
Stub helper spi_mem_default_supports_op() should
be set to static inline
Signed-off-by: YueHaibing
---
include/linux/spi/spi-mem.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 1941b84..af9ff2f 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -315,6 +315,7 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller
*ctlr,
{
}
+static inline
bool spi_mem_default_supports_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
--
2.7.4
[PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: YueHaibing
Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
is set to module:
drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
(.text+0xef6): undefined reference to `nand_bch_free'
drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
because MTD_RAW_NAND need it while linked.
Reported-by: Hulk Robot
Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
Signed-off-by: YueHaibing
---
drivers/mtd/nand/raw/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 615d738..0500c42 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
if MTD_RAW_NAND
config MTD_NAND_ECC_SW_BCH
- tristate "Support software BCH ECC"
+ bool "Support software BCH ECC"
select BCH
default n
help
--
2.7.4
Re: [PATCH 12/22] watchdog: da9063_wdt: Use 'dev' instead of dereferencing it repeatedly
Hi Steve,
On 4/10/19 5:50 AM, Steve Twiss wrote:
Hi Guenter,
On 08 April 2019 20:39, Guenter Roeck:
Subject: [PATCH 12/22] watchdog: da9063_wdt: Use 'dev' instead of
dereferencing it repeatedly
Introduce local variable 'struct device *dev' and use it instead of
dereferencing it repeatedly.
The conversion was done automatically with coccinelle using the
following semantic patches. The semantic patches and the scripts
used to generate this commit log are available at
https://github.com/groeck/coccinelle-patches
Cc: Support Opensource
Signed-off-by: Guenter Roeck
---
drivers/watchdog/da9063_wdt.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/da9063_wdt.c b/drivers/watchdog/da9063_wdt.c
index 384dca16af8b..06eb9070203c 100644
--- a/drivers/watchdog/da9063_wdt.c
+++ b/drivers/watchdog/da9063_wdt.c
@@ -188,17 +188,18 @@ static const struct watchdog_ops
da9063_watchdog_ops = {
static int da9063_wdt_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct da9063 *da9063;
struct watchdog_device *wdd;
- if (!pdev->dev.parent)
+ if (!dev->parent)
return -EINVAL;
None of my previous Acked e-mails in this patch set considered whether the
dev->parent was NULL. But this DA9063 driver does.
Logically, this is correct to check, but ... any thoughts?
The check is not really necessary. All da90xx drivers are instantiated from
mfd drivers and do provide a parent. Anyone changing that code or trying
to instantiate the drivers from some other place without providing a parent
really deserves the resulting crash (it would be a bug).
Either case, I don't think this warrants changing this driver to drop
the check, or changing the other drivers to add unnecessary checks
just to make the code consistent.
Otherwise,
Acked-by: Steve Twiss
Thanks,
Guenter
Re: [LINUX PATCH v3] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
On 2019/4/10 20:35, Mark Brown wrote: > On Wed, Apr 10, 2019 at 12:30:37PM +, Naga Sureshkumar Relli wrote: > >>> Yeah, I'm surprised that builds... > >> Sorry, I tested with CONFIG_SPI_MEM enabled. It's my bad. > > I also see that I'd queued an earlier version for application. I've > lost track of whatever issues there were with that, sorry - could one of > you please post an incremental patch for them? IIRC they were nice to > haves and the patch that was applied fixes the correctness issue. Ok, there just make the stub helper to static inline I can post a new patch based my initial patch. >
