[PATCH v2 net] net: ena: Select DIMLIB for ENA_ETHERNET
If CONFIG_ENA_ETHERNET=y and CONFIG_DIMLIB=n,
below erros can be found:
drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_dim_work':
ena_netdev.c:(.text+0x21cc): undefined reference to `net_dim_get_rx_moderation'
ena_netdev.c:(.text+0x21cc): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `net_dim_get_rx_moderation'
drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_io_poll':
ena_netdev.c:(.text+0x7bd4): undefined reference to `net_dim'
ena_netdev.c:(.text+0x7bd4): relocation truncated to fit:
R_AARCH64_CALL26 against undefined symbol `net_dim'
After commit 282faf61a053 ("net: ena: switch to dim algorithm for rx adaptive
interrupt moderation"), it introduces dim algorithm, which configured by
CONFIG_DIMLIB.
So, this patch is to select DIMLIB for ENA_ETHERNET.
Fixes: 282faf61a053 ("net: ena: switch to dim algorithm for rx adaptive
interrupt moderation")
Signed-off-by: Mao Wenan
---
v2: change subject of patch, use the "select" keyword instead of "depends".
drivers/net/ethernet/amazon/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/amazon/Kconfig
b/drivers/net/ethernet/amazon/Kconfig
index 69ca99d8ac26..cca72a75f551 100644
--- a/drivers/net/ethernet/amazon/Kconfig
+++ b/drivers/net/ethernet/amazon/Kconfig
@@ -19,6 +19,7 @@ if NET_VENDOR_AMAZON
config ENA_ETHERNET
tristate "Elastic Network Adapter (ENA) support"
depends on PCI_MSI && !CPU_BIG_ENDIAN
+ select DIMLIB
---help---
This driver supports Elastic Network Adapter (ENA)"
--
2.20.1
Re: [PATCH net] net: ena: Add dependency for ENA_ETHERNET
On 2019/9/22 11:07, Jakub Kicinski wrote:
> On Fri, 20 Sep 2019 16:44:05 +0800, Mao Wenan wrote:
>> If CONFIG_ENA_ETHERNET=y and CONFIG_DIMLIB=n,
>> below erros can be found:
>> drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_dim_work':
>> ena_netdev.c:(.text+0x21cc): undefined reference to
>> `net_dim_get_rx_moderation'
>> ena_netdev.c:(.text+0x21cc): relocation truncated to
>> fit: R_AARCH64_CALL26 against undefined symbol `net_dim_get_rx_moderation'
>> drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_io_poll':
>> ena_netdev.c:(.text+0x7bd4): undefined reference to `net_dim'
>> ena_netdev.c:(.text+0x7bd4): relocation truncated to fit:
>> R_AARCH64_CALL26 against undefined symbol `net_dim'
>>
>> After commit 282faf61a053 ("net: ena: switch to dim algorithm for rx adaptive
>> interrupt moderation"), it introduces dim algorithm, which configured by
>> CONFIG_DIMLIB.
>>
>> Fixes: 282faf61a053 ("net: ena: switch to dim algorithm for rx adaptive
>> interrupt moderation")
>> Signed-off-by: Mao Wenan
>
> Thank you Mao, shortly after you posted your patch Uwe proposed to make
> DIMLIB a hidden symbol:
>
> https://lore.kernel.org/netdev/a85be675-ce56-f7ba-29e9-b749073aa...@kleine-koenig.org/T/#t
>
> That patch will likely be applied soon, could you please rework your
> patch to use the "select" keyword instead of "depends". That's what
> other users do.
Ok, I will send v2.
>
>> diff --git a/drivers/net/ethernet/amazon/Kconfig
>> b/drivers/net/ethernet/amazon/Kconfig
>> index 69ca99d..fe46df4 100644
>> --- a/drivers/net/ethernet/amazon/Kconfig
>> +++ b/drivers/net/ethernet/amazon/Kconfig
>> @@ -18,7 +18,7 @@ if NET_VENDOR_AMAZON
>>
>> config ENA_ETHERNET
>> tristate "Elastic Network Adapter (ENA) support"
>> -depends on PCI_MSI && !CPU_BIG_ENDIAN
>> +depends on PCI_MSI && !CPU_BIG_ENDIAN && DIMLIB
>> ---help---
>>This driver supports Elastic Network Adapter (ENA)"
>>
>
>
> .
>
Re: [for-next][PATCH 3/8] tracing: Make sure variable reference alias has correct var_ref_idx
On September 21, 2019 3:21:08 PM EDT, Sasha Levin wrote: >On Sat, Sep 21, 2019 at 08:20:35AM -0400, Steven Rostedt wrote: >>On Sat, 21 Sep 2019 12:06:18 + >>Sasha Levin wrote: >> >>> Hi, >>> >>> [This is an automated email] >>> >>> This commit has been processed because it contains a "Fixes:" tag, >>> fixing commit: . >>> >>> The bot has tested the following trees: v5.2.16, v4.19.74, >v4.14.145, v4.9.193, v4.4.193. >> >> >>The fixes tag is 7e8b88a30b085 which was added to mainline in 4.17. >>According to this email, it applies fine to 5.2 and 4.19, but fails on >>4.14 and earlier. As the commit was added in 4.17 that makes perfect >>sense. Can you update your scripts to test when the fixes commit was >>added, and not send spam about it not applying to stable trees where >>it's not applicable. > >The script already does that. What happened here is that it got >confused >with your previous "Fixes:" statement in the commit message and went >haywire. > >I thought that something like this shouldn't happen because I grep for >"^fixes:", but looks like something is broken. I'll go fix that... Thanks! -- Steve -- Sent from my Android device with K-9 Mail. Please excuse my brevity and top posting.
Re: [PATCH] qede: qede_fp: simplify a bit 'qede_rx_build_skb()'
On Fri, 20 Sep 2019 06:56:56 +0200, Christophe JAILLET wrote: > Use 'skb_put_data()' instead of rewritting it. > This improves readability. > > Signed-off-by: Christophe JAILLET Applied, thank you.
Re: [PATCH net] net: ena: Add dependency for ENA_ETHERNET
On Fri, 20 Sep 2019 16:44:05 +0800, Mao Wenan wrote:
> If CONFIG_ENA_ETHERNET=y and CONFIG_DIMLIB=n,
> below erros can be found:
> drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_dim_work':
> ena_netdev.c:(.text+0x21cc): undefined reference to
> `net_dim_get_rx_moderation'
> ena_netdev.c:(.text+0x21cc): relocation truncated to
> fit: R_AARCH64_CALL26 against undefined symbol `net_dim_get_rx_moderation'
> drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_io_poll':
> ena_netdev.c:(.text+0x7bd4): undefined reference to `net_dim'
> ena_netdev.c:(.text+0x7bd4): relocation truncated to fit:
> R_AARCH64_CALL26 against undefined symbol `net_dim'
>
> After commit 282faf61a053 ("net: ena: switch to dim algorithm for rx adaptive
> interrupt moderation"), it introduces dim algorithm, which configured by
> CONFIG_DIMLIB.
>
> Fixes: 282faf61a053 ("net: ena: switch to dim algorithm for rx adaptive
> interrupt moderation")
> Signed-off-by: Mao Wenan
Thank you Mao, shortly after you posted your patch Uwe proposed to make
DIMLIB a hidden symbol:
https://lore.kernel.org/netdev/a85be675-ce56-f7ba-29e9-b749073aa...@kleine-koenig.org/T/#t
That patch will likely be applied soon, could you please rework your
patch to use the "select" keyword instead of "depends". That's what
other users do.
> diff --git a/drivers/net/ethernet/amazon/Kconfig
> b/drivers/net/ethernet/amazon/Kconfig
> index 69ca99d..fe46df4 100644
> --- a/drivers/net/ethernet/amazon/Kconfig
> +++ b/drivers/net/ethernet/amazon/Kconfig
> @@ -18,7 +18,7 @@ if NET_VENDOR_AMAZON
>
> config ENA_ETHERNET
> tristate "Elastic Network Adapter (ENA) support"
> - depends on PCI_MSI && !CPU_BIG_ENDIAN
> + depends on PCI_MSI && !CPU_BIG_ENDIAN && DIMLIB
> ---help---
> This driver supports Elastic Network Adapter (ENA)"
>
Re: [PATCH] dimlib: make DIMLIB a hidden symbol
On Fri, 20 Sep 2019 15:31:15 +0200, Uwe Kleine-König wrote: > According to Tal Gilboa the only benefit from DIM comes from a driver > that uses it. So it doesn't make sense to make this symbol user visible, > instead all drivers that use it should select it (as is already the case > AFAICT). > > Signed-off-by: Uwe Kleine-König > --- > lib/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/lib/Kconfig b/lib/Kconfig > index cc04124ed8f7..9fe8a21fd183 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -555,8 +555,7 @@ config SIGNATURE > Implementation is done using GnuPG MPI library > > config DIMLIB > - bool "DIM library" > - default y > + bool > help > Dynamic Interrupt Moderation library. > Implements an algorithm for dynamically change CQ moderation values Hi Uwe! Looks like in the net tree there is a spelling mistake and moderation is spelled "modertion": https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/tree/lib/Kconfig#n562 I'm not seeing any patch to fix that anywhere, is it possible you have some local change in your tree?
Re: [PATCH] [v2] net: stmmac: selftest: avoid large stack usage
On Thu, 19 Sep 2019 14:33:43 +0200, Arnd Bergmann wrote:
> Putting a struct stmmac_rss object on the stack is a bad idea,
> as it exceeds the warning limit for a stack frame on 32-bit architectures:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1221:12: error: stack
> frame size of 1208 bytes in function '__stmmac_test_l3filt'
> [-Werror,-Wframe-larger-than=]
> drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1338:12: error: stack
> frame size of 1208 bytes in function '__stmmac_test_l4filt'
> [-Werror,-Wframe-larger-than=]
>
> As the object is the trivial empty case, change the called function
> to accept a NULL pointer to mean the same thing and remove the
> large variable in the two callers.
>
> Fixes: 4647e021193d ("net: stmmac: selftests: Add selftest for L3/L4 Filters")
> Signed-off-by: Arnd Bergmann
Applied, thank you!
Re: [PATCH] rtc: r7301: Use devm_platform_ioremap_resource() in rtc7301_rtc_probe()
2019年9月21日(土) 20:49 Markus Elfring : > > From: Markus Elfring > Date: Sat, 21 Sep 2019 13:43:07 +0200 > > Simplify this function implementation by using a known wrapper function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Reviewed-by: Akinobu Mita
Re: [PATCH net] net: dsa: sja1105: Add dependency for NET_DSA_SJA1105_TAS
On Thu, 19 Sep 2019 14:38:19 +0800, Mao Wenan wrote:
> If CONFIG_NET_DSA_SJA1105_TAS=y and CONFIG_NET_SCH_TAPRIO=n,
> below error can be found:
> drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_setup_tc_taprio':
> sja1105_tas.c:(.text+0x318): undefined reference to `taprio_offload_free'
> sja1105_tas.c:(.text+0x590): undefined reference to `taprio_offload_get'
> drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_tas_teardown':
> sja1105_tas.c:(.text+0x610): undefined reference to `taprio_offload_free'
> make: *** [vmlinux] Error 1
>
> sja1105_tas needs tc-taprio, so this patch add the dependency for it.
>
> Fixes: 317ab5b86c8e ("net: dsa: sja1105: Configure the Time-Aware Scheduler
> via tc-taprio offload")
> Signed-off-by: Mao Wenan
Applied, thank you!
[PATCH v2 2/2] perf: add support for logging debug messages to file
When in TUI mode, it is impossible to show all the debug messages to
console. This make it hard to debug perf issues using debug messages.
This patch adds support for logging debug messages to file to resolve
this problem.
The usage is:
perf -debug verbose=2,file=~/perf.log COMMAND
Signed-off-by: Changbin Du
---
tools/perf/Documentation/perf.txt | 14 --
tools/perf/util/debug.c | 22 +-
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/perf.txt
b/tools/perf/Documentation/perf.txt
index c05a94b2488e..b2084a93210d 100644
--- a/tools/perf/Documentation/perf.txt
+++ b/tools/perf/Documentation/perf.txt
@@ -16,14 +16,16 @@ OPTIONS
Setup debug variable (see list below) in value
range (0, 10). Use like:
--debug verbose # sets verbose = 1
- --debug verbose=2 # sets verbose = 2
+ --debug verbose=2,file=~/perf.log
+ # sets verbose = 2 and save log to file
List of debug variables allowed to set:
- verbose=level - general debug messages
- ordered-events=level - ordered events object debug messages
- data-convert=level- data convert command debug messages
- stderr- write debug output (option -v) to stderr
- in browser mode
+ verbose=level - general debug messages
+ ordered-events=level - ordered events object debug messages
+ data-convert=level- data convert command debug messages
+ stderr- write debug output (option -v) to stderr
+ in browser mode
+ file=path - write debug output to log file
--buildid-dir::
Setup buildid cache directory. It has higher priority than
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index ae6eb6d1c695..f62d87ab79d5 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,6 +29,7 @@ int verbose;
bool dump_trace = false, quiet = false;
int debug_ordered_events;
static bool redirect_to_stderr;
+static FILE *log_file;
int debug_data_convert;
int veprintf(int level, int var, const char *fmt, va_list args)
@@ -39,6 +41,9 @@ int veprintf(int level, int var, const char *fmt, va_list
args)
ui_helpline__vshow(fmt, args);
else
ret = vfprintf(stderr, fmt, args);
+
+ if (log_file)
+ vfprintf(log_file, fmt, args);
}
return ret;
@@ -220,7 +225,22 @@ int perf_debug_option(const char *str)
debug_data_convert = str2loglevel(vstr);
else if (!strcmp(opt, "stderr"))
redirect_to_stderr = true;
- else {
+ else if (!strcmp(opt, "file")) {
+ if (!vstr)
+ vstr = (char *)"perf.log";
+
+ if (log_file)
+ fclose(log_file);
+
+ log_file = fopen(vstr, "a");
+ if (!log_file) {
+ pr_err("Can not create log file: %s\n",
+ strerror(errno));
+ free(dstr);
+ return -1;
+ }
+ fprintf(log_file, "\n===perf log===\n");
+ } else {
fprintf(stderr, "unkown debug option '%s'\n", opt);
free(dstr);
return -1;
--
2.20.1
[PATCH v2 0/2] perf: add support for logging debug messages to file
When in TUI mode, it is impossible to show all the debug messages to console. This make it hard to debug perf issues using debug messages. This patch adds support for logging debug messages to file to resolve this problem. v2: o specific all debug options one time. Changbin Du (2): perf: support multiple debug options separated by ',' perf: add support for logging debug messages to file tools/perf/Documentation/perf.txt | 14 ++-- tools/perf/util/debug.c | 106 ++ 2 files changed, 73 insertions(+), 47 deletions(-) -- 2.20.1
Re: [PATCH RESEND] nbd: avoid losing pointer to reallocated config->socks in nbd_add_socket
On 2019/9/21 0:06, Eugene Syromiatnikov wrote:
In the (very unlikely) case of config->socks reallocation success
and nsock allocation failure config->nsock will not get updated
with the new pointer to socks array. Fix it by updating config->socks
right after reallocation successfulness check.
Fixes: 9561a7ade0c2 ("nbd: add multi-connection support")
Signed-off-by: Eugene Syromiatnikov
Cc: sta...@vger.kernel.org # 4.10+
---
drivers/block/nbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index a8e3815..a04c686 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -987,14 +987,14 @@ static int nbd_add_socket(struct nbd_device *nbd,
unsigned long arg,
sockfd_put(sock);
return -ENOMEM;
}
+ config->socks = socks;
+
nsock = kzalloc(sizeof(struct nbd_sock), GFP_KERNEL);
if (!nsock) {
sockfd_put(sock);
return -ENOMEM;
}
- config->socks = socks;
-
This makes sense.
If the socks allocating successes, then the old config->socks will be
freed by krealloc() and return the new one, but if the nsock allocating
fails, the config->socks will hold the released memory, which may cause
the kernel crash.
Thanks
BRs
nsock->fallback_index = -1;
nsock->dead = false;
mutex_init(>tx_lock);
[PATCH v2 1/2] perf: support multiple debug options separated by ','
This patch adds support for multiple debug options separated by ',' and
non-int values.
--debug verbose=2,stderr
Signed-off-by: Changbin Du
---
tools/perf/Documentation/perf.txt | 10 ++--
tools/perf/util/debug.c | 86 ---
2 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/tools/perf/Documentation/perf.txt
b/tools/perf/Documentation/perf.txt
index 401f0ed67439..c05a94b2488e 100644
--- a/tools/perf/Documentation/perf.txt
+++ b/tools/perf/Documentation/perf.txt
@@ -19,11 +19,11 @@ OPTIONS
--debug verbose=2 # sets verbose = 2
List of debug variables allowed to set:
- verbose - general debug messages
- ordered-events - ordered events object debug messages
- data-convert - data convert command debug messages
- stderr - write debug output (option -v) to stderr
-in browser mode
+ verbose=level - general debug messages
+ ordered-events=level - ordered events object debug messages
+ data-convert=level- data convert command debug messages
+ stderr- write debug output (option -v) to stderr
+ in browser mode
--buildid-dir::
Setup buildid cache directory. It has higher priority than
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index a1b59bd35519..ae6eb6d1c695 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -27,7 +27,7 @@
int verbose;
bool dump_trace = false, quiet = false;
int debug_ordered_events;
-static int redirect_to_stderr;
+static bool redirect_to_stderr;
int debug_data_convert;
int veprintf(int level, int var, const char *fmt, va_list args)
@@ -173,41 +173,18 @@ void trace_event(union perf_event *event)
trace_event_printer, event);
}
-static struct debug_variable {
- const char *name;
- int *ptr;
-} debug_variables[] = {
- { .name = "verbose",.ptr = },
- { .name = "ordered-events", .ptr = _ordered_events},
- { .name = "stderr", .ptr = _to_stderr},
- { .name = "data-convert", .ptr = _data_convert },
- { .name = NULL, }
-};
-
-int perf_debug_option(const char *str)
+static int str2loglevel(const char *vstr)
{
- struct debug_variable *var = _variables[0];
- char *vstr, *s = strdup(str);
int v = 1;
-
- vstr = strchr(s, '=');
- if (vstr)
- *vstr++ = 0;
-
- while (var->name) {
- if (!strcmp(s, var->name))
- break;
- var++;
- }
-
- if (!var->name) {
- pr_err("Unknown debug variable name '%s'\n", s);
- free(s);
- return -1;
- }
+ char *endptr;
if (vstr) {
- v = atoi(vstr);
+ v = strtol(vstr, ,0);
+ if (vstr == endptr) {
+ fprintf(stderr, "warning: '%s' is not a digit\n", vstr);
+ return -1;
+ }
+
/*
* Allow only values in range (0, 10),
* otherwise set 0.
@@ -218,20 +195,47 @@ int perf_debug_option(const char *str)
if (quiet)
v = -1;
- *var->ptr = v;
- free(s);
+ return v;
+}
+
+int perf_debug_option(const char *str)
+{
+ char *sep, *vstr;
+ char *dstr = strdup(str);
+ char *opt = dstr;
+
+ do {
+ if ((sep = strchr(opt, ',')) != NULL)
+ *sep = '\0';
+
+ vstr = strchr(opt, '=');
+ if (vstr)
+ *vstr++ = 0;
+
+ if (!strcmp(opt, "verbose"))
+ verbose = str2loglevel(vstr);
+ else if (!strcmp(opt, "ordered-events"))
+ debug_ordered_events = str2loglevel(vstr);
+ else if (!strcmp(opt, "data-convert"))
+ debug_data_convert = str2loglevel(vstr);
+ else if (!strcmp(opt, "stderr"))
+ redirect_to_stderr = true;
+ else {
+ fprintf(stderr, "unkown debug option '%s'\n", opt);
+ free(dstr);
+ return -1;
+ }
+
+ opt = sep + 1;
+ } while (sep && sep[1]);
+
+ free(dstr);
return 0;
}
int perf_quiet_option(void)
{
- struct debug_variable *var = _variables[0];
-
- /* disable all debug messages */
- while (var->name) {
- *var->ptr = -1;
- var++;
- }
+ verbose = debug_ordered_events = debug_data_convert = -1;
return 0;
}
--
2.20.1
[PATCH] regulator: fixed: Prevent NULL pointer dereference when !CONFIG_OF
Use of_device_get_match_data which has NULL test for match before
dereference match->data. Add NULL test for drvtype so it still works
for fixed_voltage_ops when !CONFIG_OF.
Signed-off-by: Axel Lin
---
drivers/regulator/fixed.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index d90a6fd8cbc7..f81533070058 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -144,8 +144,7 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct fixed_voltage_config *config;
struct fixed_voltage_data *drvdata;
- const struct fixed_dev_type *drvtype =
- of_match_device(dev->driver->of_match_table, dev)->data;
+ const struct fixed_dev_type *drvtype = of_device_get_match_data(dev);
struct regulator_config cfg = { };
enum gpiod_flags gflags;
int ret;
@@ -177,7 +176,7 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
drvdata->desc.type = REGULATOR_VOLTAGE;
drvdata->desc.owner = THIS_MODULE;
- if (drvtype->has_enable_clock) {
+ if (drvtype && drvtype->has_enable_clock) {
drvdata->desc.ops = _voltage_clkenabled_ops;
drvdata->enable_clock = devm_clk_get(dev, NULL);
--
2.20.1
Re: [PATCH] net: remove netx ethernet driver
On Wed, 18 Sep 2019 22:21:24 +0200, Arnd Bergmann wrote: > The ARM netx platform got removed in 5.3, so this driver > is now useless. > > Reported-by: Uwe Kleine-König > Cc: Sascha Hauer > Signed-off-by: Arnd Bergmann Applied, thank you! FWIW there seems to be a lone mention of something called netx_timer in linux-next, not sure if that's related too.. linux $ git grep netx_timer Documentation/admin-guide/kernel-parameters.txt:[ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
Re: [PATCH] net: qrtr: Stop rx_worker before freeing node
On Wed, 18 Sep 2019 10:21:17 -0700, Bjorn Andersson wrote:
> As the endpoint is unregistered there might still be work pending to
> handle incoming messages, which will result in a use after free
> scenario. The plan is to remove the rx_worker, but until then (and for
> stable@) ensure that the work is stopped before the node is freed.
>
> Fixes: bdabad3e363d ("net: Add Qualcomm IPC router")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Bjorn Andersson
Thanks! Applied, and queued for 4.9+.
FWIW Dave handles the stable submission himself, so no need to CC
stable on networking patches:
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html#q-i-see-a-network-patch-and-i-think-it-should-be-backported-to-stable
Re: [PATCH] drivers/net/fjes: fix a potential NULL pointer dereference
On Wed, 18 Sep 2019 22:03:15 +0530, Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais
If I'm looking at this right you are jumping to err_free_netdev without
setting the err variable. It must had been set to 0 from the return of
fjes_sw_init(). This means we will free the netdev, and return 0. This
means probe will not fail and driver's remove function will be run
at some point. fjes_remove it will try to free the netdev again.
Looks like there's another existing bug here in that the work queues
are not free when something fails in fjes_probe, just the netdev.
Once you untangle that, and before you post a v2, could you please try
to identify which commit introduced the regression and provide an
appropriate "Fixes" tag?
> diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
> index bbbc1dc..2d04104 100644
> --- a/drivers/net/fjes/fjes_main.c
> +++ b/drivers/net/fjes/fjes_main.c
> @@ -1237,8 +1237,15 @@ static int fjes_probe(struct platform_device *plat_dev)
> adapter->open_guard = false;
>
> adapter->txrx_wq = alloc_workqueue(DRV_NAME "/txrx", WQ_MEM_RECLAIM, 0);
> + if (unlikely(!adapter->txrx_wq))
> + goto err_free_netdev;
> +
> adapter->control_wq = alloc_workqueue(DRV_NAME "/control",
> WQ_MEM_RECLAIM, 0);
> + if (unlikely(!adapter->control_wq)) {
> + destroy_workqueue(adapter->txrx_wq);
> + goto err_free_netdev;
> + }
>
> INIT_WORK(>tx_stall_task, fjes_tx_stall_task);
> INIT_WORK(>raise_intr_rxdata_task,
Re: [PATCH net v3] net/phy: fix DP83865 10 Mbps HDX loopback disable function
On Wed, 18 Sep 2019 19:27:55 +0300, Peter Mamonov wrote:
> According to the DP83865 datasheet "the 10 Mbps HDX loopback can be
> disabled in the expanded memory register 0x1C0.1". The driver erroneously
> used bit 0 instead of bit 1.
>
> Fixes: 4621bf129856 ("phy: Add file missed in previous commit.")
> Signed-off-by: Peter Mamonov
Applied, queued, thank you!
[GIT PULL] MIPS changes
Hi Linus,
Here are the main MIPS changes for v5.4; please pull.
My apologies that this is arriving at the end of the week; a combination
of travel & discovering a MIPS32 page table handling issue later than
would have been ideal delayed things.
There are a number of minor merge conflicts with current master, my
suggested resolutions are as follows:
diff --cc Documentation/mips/index.rst
index fd9023c8a89f,321b4794f3b8..3616fb872af3
--- a/Documentation/mips/index.rst
+++ b/Documentation/mips/index.rst
@@@ -1,17 -1,11 +1,18 @@@
.. SPDX-License-Identifier: GPL-2.0
-===
-MIPS-specific Documentation
-===
+=
+MIPS architecture
+=
.. toctree::
- :maxdepth: 1
- :numbered:
+ :maxdepth: 2
+ au1xxx_ide
+ingenic-tcu
+
+.. only:: subproject and html
+
+ Indices
+ ===
+
+ * :ref:`genindex`
diff --cc arch/mips/Kconfig
index 904c096fa4da,2f7c050e8cde..cc8e2b1032a5
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@@ -43,8 -44,7 +44,8 @@@ config MIP
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
- select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES
+ select HAVE_ASM_MODVERSIONS
select HAVE_EBPF_JIT if (!CPU_MICROMIPS)
select HAVE_CONTEXT_TRACKING
select HAVE_COPY_THREAD_TLS
diff --cc drivers/video/fbdev/Makefile
index aab7155884ea,49502d6256cb..aa6352798cf4
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@@ -116,7 -116,7 +116,6 @@@ obj-y += om
obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o
obj-$(CONFIG_FB_CARMINE) += carminefb.o
obj-$(CONFIG_FB_MB862XX)+= mb862xx/
- obj-$(CONFIG_FB_JZ4740) += jz4740_fb.o
-obj-$(CONFIG_FB_NUC900) += nuc900fb.o
obj-$(CONFIG_FB_PUV3_UNIGFX) += fb-puv3.o
obj-$(CONFIG_FB_HYPERV) += hyperv_fb.o
obj-$(CONFIG_FB_OPENCORES) += ocfb.o
Thanks,
Paul
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_5.4
for you to fetch changes up to 05d013a0366d50f4f0dbebf8c1b22b42020bf49a:
MIPS: Detect bad _PFN_SHIFT values (2019-09-20 14:55:07 -0700)
Main MIPS changes for v5.4:
- boot_mem_map is removed, providing a nice cleanup made possible by the
recent removal of bootmem.
- Some fixes to atomics, in general providing compiler barriers for
smp_mb__{before,after}_atomic plus fixes specific to Loongson CPUs or
MIPS32 systems using cmpxchg64().
- Conversion to the new generic VDSO infrastructure courtesy of Vincenzo
Frascino.
- Removal of undefined behavior in set_io_port_base(), fixing the
behavior of some MIPS kernel configurations when built with recent
clang versions.
- Initial MIPS32 huge page support, functional on at least Ingenic SoCs.
- pte_special() is now supported for some configurations, allowing among
other things generic fast GUP to be used.
- Miscellaneous fixes & cleanups.
And platform specific changes:
- Major improvements to Ingenic SoC support from Paul Cercueil, mostly
enabled by the inclusion of the new TCU (timer-counter unit) drivers
he's spent a very patient year or so working on. Plus some fixes for
X1000 SoCs from Zhou Yanjie.
- Netgear R6200 v1 systems are now supported by the bcm47xx platform.
- DT updates for BMIPS, Lantiq & Microsemi Ocelot systems.
Antoine Tenart (2):
MIPS: dts: mscc: describe the PTP register range
MIPS: dts: mscc: describe the PTP ready interrupt
Arnd Bergmann (1):
mips: fix vdso32 build, again
Christoph Hellwig (1):
mips: remove ioremap_cachable
Christophe JAILLET (1):
MIPS: Octeon: Fix a typo in #define OCTOEN_SERIAL_LEN
Daniel Silsby (5):
MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA
MIPS: Add partial 32-bit huge page support
MIPS: Decouple CPU_SUPPORTS_HUGEPAGES from 64BIT
MIPS: ingenic: Add support for huge pages
MIPS: Undefine PMD_ORDER for 32-bit builds
Dmitry Korotin (1):
MIPS: pte_special()/pte_mkspecial() support
Edward Matijević (1):
MIPS: BCM47XX: Add support for Netgear R6200 V1
Fabian Mewes (1):
MIPS: Kconfig: remove HAVE_LATENCYTOP_SUPPORT
Firoz Khan (1):
mips: remove nargs from __SYSCALL
Florian Fainelli (2):
firmware: bcm47xx_nvram: Correct size_t printf format
firmware: bcm47xx_nvram: Allow COMPILE_TEST
Hauke Mehrtens (1):
MIPS: ralink: deactivate PCI support for SOC_MT7621
Jiaxun Yang (9):
Re: [PATCH] ocxl: Use the correct style for SPDX License Identifier
On 20/9/19 6:18 pm, Nishad Kamdar wrote: This patch corrects the SPDX License Identifier style in header files for Open Coherent Accelerator (OCXL) compatible device drivers. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar Thanks. Acked-by: Andrew Donnellan --- drivers/misc/ocxl/ocxl_internal.h | 2 +- drivers/misc/ocxl/trace.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h index 97415afd79f3..345bf843a38e 100644 --- a/drivers/misc/ocxl/ocxl_internal.h +++ b/drivers/misc/ocxl/ocxl_internal.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +/* SPDX-License-Identifier: GPL-2.0+ */ // Copyright 2017 IBM Corp. #ifndef _OCXL_INTERNAL_H_ #define _OCXL_INTERNAL_H_ diff --git a/drivers/misc/ocxl/trace.h b/drivers/misc/ocxl/trace.h index 024f417e7e01..17e21cb2addd 100644 --- a/drivers/misc/ocxl/trace.h +++ b/drivers/misc/ocxl/trace.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +/* SPDX-License-Identifier: GPL-2.0+ */ // Copyright 2017 IBM Corp. #undef TRACE_SYSTEM #define TRACE_SYSTEM ocxl -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: build_path_from_dentry_optional_prefix() may schedule from invalid context
On Thu, Sep 19, 2019 at 05:11:54PM -0700, Pavel Shilovsky wrote:
> Good catch. I think we should have another version of
> build_path_from_dentry() which takes pre-allocated (probably on stack)
> full_path as an argument. This would allow us to avoid allocations
> under the spin lock.
On _stack_? For relative pathname? Er... You do realize that
kernel stack is small, right? And said relative pathname can
bloody well be up to 4Kb (i.e. the half of said stack already,
on top of whatever the call chain has already eaten up)...
BTW, looking at build_path_from_dentry()... WTF is this?
temp = temp->d_parent;
if (temp == NULL) {
cifs_dbg(VFS, "corrupt dentry\n");
rcu_read_unlock();
return NULL;
}
Why not check for any number of other forms of memory corruption?
Like, say it, if (temp == (void *)0xf0adf0adf0adf0ad)?
IOW, kindly lose that nonsense. More importantly, why bother
with that kmalloc()? Just __getname() in the very beginning
and __putname() on failure (and for freeing the result afterwards).
What's more, you are open-coding dentry_path_raw(), badly.
The only differences are
* use of dirsep instead of '/' and
* a prefix slapped in the beginning.
I'm fairly sure that
char *buf = __getname();
char *s;
*to_free = NULL;
if (unlikely(!buf))
return NULL;
s = dentry_path_raw(dentry, buf, PATH_MAX);
if (IS_ERR(s) || s < buf + prefix_len)
__putname(buf);
return NULL; // assuming that you don't care about details
}
if (dirsep != '/') {
char *p = s;
while ((p = strchr(p, '/')) != NULL)
*p++ = dirsep;
}
s -= prefix_len;
memcpy(s, prefix, prefix_len);
*to_free = buf;
return s;
would end up being faster, not to mention much easier to understand.
With the caller expected to pass _free among the arguments and
__putname() it once it's done.
Or just do __getname() in the caller and pass it to the function -
in that case freeing (in all cases) would be up to the caller.
Re: [GIT PULL] ext4 updates for 5.4
The pull request you sent on Thu, 19 Sep 2019 16:56:41 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git > tags/ext4_for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/70cb0d02b58128db07fc39b5e87a2873e2c16bde Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] f2fs for 5.4
The pull request you sent on Fri, 20 Sep 2019 13:01:07 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > tags/f2fs-for-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fbc246a12aac27f7b25a37f9398bb3bc552cec92 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 4.19 32/79] fpga: altera-ps-spi: Fix getting of optional confd gpio
Hi!
> Currently the driver does not handle EPROBE_DEFER for the confd gpio.
> Use devm_gpiod_get_optional() instead of devm_gpiod_get() and return
> error codes from altera_ps_probe().
> @@ -265,10 +265,13 @@ static int altera_ps_probe(struct spi_device *spi)
> return PTR_ERR(conf->status);
> }
>
> - conf->confd = devm_gpiod_get(>dev, "confd", GPIOD_IN);
> + conf->confd = devm_gpiod_get_optional(>dev, "confd", GPIOD_IN);
> if (IS_ERR(conf->confd)) {
> - dev_warn(>dev, "Not using confd gpio: %ld\n",
> - PTR_ERR(conf->confd));
> + dev_err(>dev, "Failed to get confd gpio: %ld\n",
> + PTR_ERR(conf->confd));
> + return PTR_ERR(conf->confd);
Will this result in repeated errors in dmesg in case of EPROBE_DEFER?
We often avoid printing such messages in EPROBE_DEFER case.
> + } else if (!conf->confd) {
> + dev_warn(>dev, "Not using confd gpio");
> }
>
> /* Register manager with unique name */
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 2/2] soc: ti: move 2 driver config options into the TI SOC drivers menu
Hi Santosh,
Would you also pick up patch 2/2, which I didn't Cc: you on?:(
Do I need to resend it?
Thanks.
On 9/19/19 3:33 PM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Move the AM654 and J721E SOC config options inside the "TI SOC drivers"
> menu with the other TI SOC drivers.
>
> Fixes: a869b7b30dac ("soc: ti: Add Support for AM654 SoC config option")
> Fixes: cff377f7897a ("soc: ti: Add Support for J721E SoC config option")
> Signed-off-by: Randy Dunlap
> Cc: Olof Johansson
> Cc: Nishanth Menon
> Cc: Benjamin Fair
> Cc: Tony Lindgren
> Cc: Tero Kristo
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> drivers/soc/ti/Kconfig | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> --- lnx-53.orig/drivers/soc/ti/Kconfig
> +++ lnx-53/drivers/soc/ti/Kconfig
> @@ -1,4 +1,12 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +
> +# TI SOC drivers
> +#
> +menuconfig SOC_TI
> + bool "TI SOC drivers support"
> +
> +if SOC_TI
> +
> # 64-bit ARM SoCs from TI
> if ARM64
>
> @@ -14,17 +22,9 @@ config ARCH_K3_J721E_SOC
> help
> Enable support for TI's J721E SoC Family.
>
> -endif
> +endif # ARCH_K3
>
> -endif
> -
> -#
> -# TI SOC drivers
> -#
> -menuconfig SOC_TI
> - bool "TI SOC drivers support"
> -
> -if SOC_TI
> +endif # ARM64
>
> config KEYSTONE_NAVIGATOR_QMSS
> tristate "Keystone Queue Manager Subsystem"
>
>
>
--
~Randy
Re: [PATCH 4.19 10/79] udp: correct reuseport selection with connected sockets
On Fri 2019-09-20 00:02:55, Greg Kroah-Hartman wrote:
> From: Willem de Bruijn
>
> [ Upstream commit acdcecc61285faed359f1a3568c32089cc3a8329 ]
>
> UDP reuseport groups can hold a mix unconnected and connected sockets.
> Ensure that connections only receive all traffic to their 4-tuple.
>
> Fast reuseport returns on the first reuseport match on the assumption
> that all matches are equal. Only if connections are present, return to
> the previous behavior of scoring all sockets.
>
> Record if connections are present and if so (1) treat such connected
> sockets as an independent match from the group, (2) only return
> 2-tuple matches from reuseport and (3) do not return on the first
> 2-tuple reuseport match to allow for a higher scoring match later.
>
> New field has_conns is set without locks. No other fields in the
> bitmap are modified at runtime and the field is only ever set
> unconditionally, so an RMW cannot miss a change.
That's an ... extremely tricky game with concurrent access. I'm pretty
sure it is not valid C, but maybe it is acceptable for kernel.
> --- a/include/net/sock_reuseport.h
> +++ b/include/net/sock_reuseport.h
> @@ -21,7 +21,8 @@ struct sock_reuseport {
> unsigned intsynq_overflow_ts;
> /* ID stays the same even after the size of socks[] grows. */
> unsigned intreuseport_id;
> - boolbind_inany;
> + unsigned intbind_inany:1;
> + unsigned inthas_conns:1;
But should it at least be commented here? If someone adds another int :1,
he may get a surprise...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 4.19 03/79] RDMA/restrack: Release task struct which was hold by CM_ID object
Hi! > commit ed7a01fd3fd77f40b4ef2562b966a5decd8928d2 upstream. > > Tracking CM_ID resource is performed in two stages: creation of cm_id > and connecting it to the cma_dev. It is needed because rdma-cm protocol > exports two separate user-visible calls rdma_create_id and > rdma_accept. ... Mainline says this needs additional fix, fe9bc1644918aa1d, see below. > --- a/drivers/infiniband/core/restrack.c > +++ b/drivers/infiniband/core/restrack.c > @@ -209,7 +209,7 @@ void rdma_restrack_del(struct rdma_restr > struct ib_device *dev; > > if (!res->valid) > - return; > + goto out; > > dev = res_to_dev(res); > if (!dev) # return; This test does return, does it need to go through 'goto out', too? (I see it should not happen, but...) > @@ -222,8 +222,10 @@ void rdma_restrack_del(struct rdma_restr > down_write(>res.rwsem); > hash_del(>node); > res->valid = false; > + up_write(>res.rwsem); > + > +out: > if (res->task) > put_task_struct(res->task); > - up_write(>res.rwsem); > } Mainline says res->task = NULL is needed there, see fe9bc1644918aa1d. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] net: dsa: Use the correct style for SPDX License Identifier
On 9/21/2019 6:45 AM, Nishad Kamdar wrote: > This patch corrects the SPDX License Identifier style > in header file for Distributed Switch Architecture drivers. > For C header files Documentation/process/license-rules.rst > mandates C-like comments (opposed to C source files where > C++ style should be used) > > Changes made by using a script provided by Joe Perches here: > https://lkml.org/lkml/2019/2/7/46. > > Suggested-by: Joe Perches > Signed-off-by: Nishad Kamdar Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH] net: dsa: b53: Use the correct style for SPDX License Identifier
On 9/21/2019 6:30 AM, Nishad Kamdar wrote: > This patch corrects the SPDX License Identifier style > in header file for Broadcom BCM53xx managed switch driver. > For C header files Documentation/process/license-rules.rst > mandates C-like comments (opposed to C source files where > C++ style should be used) > > Changes made by using a script provided by Joe Perches here: > https://lkml.org/lkml/2019/2/7/46. > > Suggested-by: Joe Perches > Signed-off-by: Nishad Kamdar Reviewed-by: Florian Fainelli -- Florian
Re: [for-next][PATCH 3/8] tracing: Make sure variable reference alias has correct var_ref_idx
On Sat, Sep 21, 2019 at 08:20:35AM -0400, Steven Rostedt wrote: On Sat, 21 Sep 2019 12:06:18 + Sasha Levin wrote: Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: . The bot has tested the following trees: v5.2.16, v4.19.74, v4.14.145, v4.9.193, v4.4.193. The fixes tag is 7e8b88a30b085 which was added to mainline in 4.17. According to this email, it applies fine to 5.2 and 4.19, but fails on 4.14 and earlier. As the commit was added in 4.17 that makes perfect sense. Can you update your scripts to test when the fixes commit was added, and not send spam about it not applying to stable trees where it's not applicable. The script already does that. What happened here is that it got confused with your previous "Fixes:" statement in the commit message and went haywire. I thought that something like this shouldn't happen because I grep for "^fixes:", but looks like something is broken. I'll go fix that... -- Thanks, Sasha
Re: [PATCH 3.16 114/132] ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term
On Fri, 2019-09-20 at 21:26 -0400, Hui Peng wrote: > I want to confirm the patches. > > Which version of GCC do you use to compile 3.16? > > I tried gcc-4.8, it seems that the built kernel can not be boot by qemu. [...] For my own limited testing, I build for x86 with gcc 4.9. Debian's packages are built with gcc 4.8 (arm) or 4.9 (x86). Guenter Roeck does build and boot tests on multiple architectures using a variety of (mostly quite recent) compiler versions. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
On Fri, 20 Sep 2019 20:02:58 -0700, Florian Fainelli wrote: > On 9/20/2019 6:11 PM, Jakub Kicinski wrote: > > On Tue, 17 Sep 2019 13:30:52 +0300, Alexandru Ardelean wrote: > >> The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type', > >> which are enums of mode strings. > >> > >> The 'dwmac' driver supports almost all modes declared in the 'phy-mode' > >> enum (except for 1 or 2). But in general, there may be a case where > >> 'mac-mode' becomes more generic and is moved as part of phylib or netdev. > >> > >> In any case, the 'mac-mode' field should be made an enum, and it also makes > >> sense to just reference the 'phy-connection-type' from > >> 'ethernet-controller.yaml'. That will also make it more future-proof for > >> new > >> modes. > >> > >> Signed-off-by: Alexandru Ardelean > > > > Applied, thank you! > > > > FWIW I had to add the Fixes tag by hand, either ozlabs patchwork or my > > git-pw doesn't have the automagic handling there, yet. > > AFAICT the ozlabs patchwork instance does not do it, but if you have > patchwork administrative rights (the jango administration panel I mean) > then it is simple to add the regular expression to the list of tags that > patchwork already recognized. Had tried getting that included by > default, but it also counted all of those tags and therefore was not > particularly fine grained: > > https://lists.ozlabs.org/pipermail/patchwork/2017-January/003910.html Curious, it did seem to have counted the Fixes in the 'F' field on the web UI but git-pw didn't pull it down 樂 linux$ git checkout 92974a1d006ad8b30d53047c70974c9e065eb7df Note: checking out '92974a1d006ad8b30d53047c70974c9e065eb7df'. [...] linux$ git pw patch apply 1163199 --signoff 11:41 linux$ git show commit ac964661384b93ff3c9839c6d56f293195d54b4e (HEAD) Author: Alexandru Ardelean Date: Tue Sep 17 13:30:52 2019 +0300 dt-bindings: net: dwmac: fix 'mac-mode' type The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type', which are enums of mode strings. The 'dwmac' driver supports almost all modes declared in the 'phy-mode' enum (except for 1 or 2). But in general, there may be a case where 'mac-mode' becomes more generic and is moved as part of phylib or netdev. In any case, the 'mac-mode' field should be made an enum, and it also makes sense to just reference the 'phy-connection-type' from 'ethernet-controller.yaml'. That will also make it more future-proof for new modes. Signed-off-by: Alexandru Ardelean Reviewed-by: Andrew Lunn Reviewed-by: Rob Herring Signed-off-by: Jakub Kicinski 11:41 linux$
Re: [PATCH v5 1/1] platform/x86/intel_cht_int33fe: Split code to USB Micro-B and Type-C variants
Hi,
On 21-09-2019 00:33, Yauhen Kharuzhy wrote:
Existing intel_cht_int33fe ACPI pseudo-device driver assumes that
hardware has Type-C connector and register related devices described as
I2C connections in the _CRS resource.
There is at least one hardware (Lenovo Yoga Book YB1-91L/F) with Micro-B
USB connector exists. It has INT33FE device in the DSDT table but
there are only two I2C connection described: PMIC and BQ27452 battery
fuel gauge.
Splitting existing INT33FE driver allow to maintain code for USB Micro-B
(or AB) connector variant separately and make it simpler.
Split driver to intel_cht_int33fe_common.c and
intel_cht_int33fe_{microb,typec}.c. Compile all this sources to one .ko
module to make user experience easier.
Signed-off-by: Yauhen Kharuzhy
This version still works for me on my typec device:
Tested-by: Hans de Goede
The code also looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/platform/x86/Kconfig | 10 +-
drivers/platform/x86/Makefile | 4 +
.../platform/x86/intel_cht_int33fe_common.c | 147 ++
.../platform/x86/intel_cht_int33fe_common.h | 41 +
.../platform/x86/intel_cht_int33fe_microb.c | 57 +++
...ht_int33fe.c => intel_cht_int33fe_typec.c} | 78 +-
6 files changed, 265 insertions(+), 72 deletions(-)
create mode 100644 drivers/platform/x86/intel_cht_int33fe_common.c
create mode 100644 drivers/platform/x86/intel_cht_int33fe_common.h
create mode 100644 drivers/platform/x86/intel_cht_int33fe_microb.c
rename drivers/platform/x86/{intel_cht_int33fe.c =>
intel_cht_int33fe_typec.c} (82%)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1b67bb578f9f..e9e5aa791caf 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -930,14 +930,20 @@ config INTEL_CHT_INT33FE
This driver add support for the INT33FE ACPI device found on
some Intel Cherry Trail devices.
+ There are two kinds of INT33FE ACPI device possible: for hardware
+ with USB Type-C and Micro-B connectors. This driver supports both.
+
The INT33FE ACPI device has a CRS table with I2cSerialBusV2
- resources for 3 devices: Maxim MAX17047 Fuel Gauge Controller,
+ resources for Fuel Gauge Controller and (in the Type-C variant)
FUSB302 USB Type-C Controller and PI3USB30532 USB switch.
This driver instantiates i2c-clients for these, so that standard
i2c drivers for these chips can bind to the them.
If you enable this driver it is advised to also select
- CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m.
+ CONFIG_BATTERY_BQ27XXX=m or CONFIG_BATTERY_BQ27XXX_I2C=m for Micro-B
+ device and CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m
+ for Type-C device.
+
config INTEL_INT0002_VGPIO
tristate "Intel ACPI INT0002 Virtual GPIO driver"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 415104033060..216d3b6fd6a7 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -61,6 +61,10 @@ obj-$(CONFIG_TOSHIBA_BT_RFKILL) += toshiba_bluetooth.o
obj-$(CONFIG_TOSHIBA_HAPS)+= toshiba_haps.o
obj-$(CONFIG_TOSHIBA_WMI) += toshiba-wmi.o
obj-$(CONFIG_INTEL_CHT_INT33FE) += intel_cht_int33fe.o
+intel_cht_int33fe-objs := intel_cht_int33fe_common.o \
+ intel_cht_int33fe_typec.o \
+ intel_cht_int33fe_microb.o
+
obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o
obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o
diff --git a/drivers/platform/x86/intel_cht_int33fe_common.c
b/drivers/platform/x86/intel_cht_int33fe_common.c
new file mode 100644
index ..42dd11623f56
--- /dev/null
+++ b/drivers/platform/x86/intel_cht_int33fe_common.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common code for Intel Cherry Trail ACPI INT33FE pseudo device drivers
+ * (USB Micro-B and Type-C connector variants).
+ *
+ * Copyright (c) 2019 Yauhen Kharuzhy
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "intel_cht_int33fe_common.h"
+
+#define EXPECTED_PTYPE 4
+
+static int cht_int33fe_i2c_res_filter(struct acpi_resource *ares, void *data)
+{
+ struct acpi_resource_i2c_serialbus *sb;
+ int *count = data;
+
+ if (i2c_acpi_get_i2c_resource(ares, ))
+ (*count)++;
+
+ return 1;
+}
+
+static int cht_int33fe_count_i2c_clients(struct device *dev)
+{
+ struct acpi_device *adev;
+ LIST_HEAD(resource_list);
+ int count = 0;
+
+ adev = ACPI_COMPANION(dev);
+ if (!adev)
+ return -EINVAL;
+
+ acpi_dev_get_resources(adev, _list,
+ cht_int33fe_i2c_res_filter, );
+
+
Re: [GIT PULL] MTD updates for 5.4-rc1
The pull request you sent on Sat, 21 Sep 2019 09:36:35 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4553d469d6f88028f185de57e771dd29aba10d90 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] libnvdimm for 5.4
The pull request you sent on Fri, 20 Sep 2019 16:57:31 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-for-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6cb2e9ee51b5f1539f027346a02904e282b87d4d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2] iio: imu: adis16400: fix memory leak
On Fri, 20 Sep 2019 06:46:05 +
"Ardelean, Alexandru" wrote:
> On Thu, 2019-09-19 at 10:56 -0500, Navid Emamdoost wrote:
> > In adis_update_scan_mode_burst, if adis->buffer allocation fails release
> > the adis->xfer.
> >
> > v2: set adis->xfer = NULL to avoid any potential double free.
> >
>
> Reviewed-by: Alexandru Ardelean
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
>
> > Signed-off-by: Navid Emamdoost
> > ---
> > drivers/iio/imu/adis_buffer.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/imu/adis_buffer.c
> > b/drivers/iio/imu/adis_buffer.c
> > index 9ac8356d9a95..78fe83c1f4fe 100644
> > --- a/drivers/iio/imu/adis_buffer.c
> > +++ b/drivers/iio/imu/adis_buffer.c
> > @@ -35,8 +35,11 @@ static int adis_update_scan_mode_burst(struct iio_dev
> > *indio_dev,
> > return -ENOMEM;
> >
> > adis->buffer = kzalloc(burst_length + sizeof(u16), GFP_KERNEL);
> > - if (!adis->buffer)
> > + if (!adis->buffer) {
> > + kfree(adis->xfer);
> > + adis->xfer = NULL;
> > return -ENOMEM;
> > + }
> >
> > tx = adis->buffer + burst_length;
> > tx[0] = ADIS_READ_REG(adis->burst->reg_cmd);
Re: [GIT PULL] UML updates for 5.4-rc1
The pull request you sent on Sat, 21 Sep 2019 09:36:39 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git > tags/for-linus-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9dca3432ee063b70a4cfb3f0857d0aeef7b84fa8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] first round of SCSI updates for the 5.3+ merge window
The pull request you sent on Thu, 19 Sep 2019 15:47:29 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/10fd71780f7d155f4e35fecfad0ebd4a725a244b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] UBI/UBIFS/JFFS2 updates for 5.4-rc1
The pull request you sent on Sat, 21 Sep 2019 09:36:42 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git > tags/upstream-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/104c0d6bc43e10ba84931c45b67e2c76c9c67f68 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2] iio: imu: adis16400: release allocated memory on failure
On Fri, 20 Sep 2019 06:46:37 +
"Ardelean, Alexandru" wrote:
> On Thu, 2019-09-19 at 10:50 -0500, Navid Emamdoost wrote:
> > In adis_update_scan_mode, if allocation for adis->buffer fails,
> > previously allocated adis->xfer needs to be released.
> >
> > v2: added adis->xfer = NULL to avoid any potential double free.
Version changes go below the --- so they don't get recorded in the
git tree log when it's applied.
>
> Reviewed-by: Alexandru Ardelean
Applied to the fixes-togreg branch of iio.git. Thanks,
Jonathan
>
> > Signed-off-by: Navid Emamdoost
> > ---
> > drivers/iio/imu/adis_buffer.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/imu/adis_buffer.c
> > b/drivers/iio/imu/adis_buffer.c
> > index 9ac8356d9a95..f446ff497809 100644
> > --- a/drivers/iio/imu/adis_buffer.c
> > +++ b/drivers/iio/imu/adis_buffer.c
> > @@ -78,8 +78,11 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
> > return -ENOMEM;
> >
> > adis->buffer = kcalloc(indio_dev->scan_bytes, 2, GFP_KERNEL);
> > - if (!adis->buffer)
> > + if (!adis->buffer) {
> > + kfree(adis->xfer);
> > + adis->xfer = NULL;
> > return -ENOMEM;
> > + }
> >
> > rx = adis->buffer;
> > tx = rx + scan_count;
Re: [PATCH v8 6/9] leds: multicolor: Introduce a multicolor class definition
Dan,
One more remark below.
On 9/20/19 7:41 PM, Dan Murphy wrote:
> Introduce a multicolor class that groups colored LEDs
> within a LED node.
>
> The framework allows for dynamically setting individual LEDs
> or setting brightness levels of LEDs and updating them virtually
> simultaneously.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/leds/Kconfig | 10 +
> drivers/leds/Makefile| 1 +
> drivers/leds/led-class-multicolor.c | 316 +++
> include/linux/led-class-multicolor.h | 76 +++
> 4 files changed, 403 insertions(+)
> create mode 100644 drivers/leds/led-class-multicolor.c
> create mode 100644 include/linux/led-class-multicolor.h
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 6e7703fd03d0..cfb1ebb6517f 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH
[...]
> +static int led_multicolor_init_color_dir(struct led_classdev_mc_data *data,
> + struct led_classdev_mc *mcled_cdev)
> +{
> + struct led_classdev *led_cdev = mcled_cdev->led_cdev;
> + u32 color_id;
> + int ret;
> + int i, j = 0;
> +
> + data->mcled_cdev = mcled_cdev;
> +
> + ret = sysfs_create_group(_cdev->dev->kobj, _color_group);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < LED_COLOR_ID_MAX; i++) {
> + color_id = (mcled_cdev->available_colors & (1 << i));
Please use bitops for accessing available_colors.
> + if (color_id) {
Here you need: if (test_bit(i, _cdev->available_colors))
> + ret = led_multicolor_init_color(data, mcled_cdev, i, j);
> + if (ret)
> + break;
> +
> + j++;
> + }
> + }
> +
> + return ret;
> +}
--
Best regards,
Jacek Anaszewski
Re: [PATCH v8 9/9] leds: Update the lp55xx to use the multi color framework
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
> Update the lp5523 to use the multi color framework.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/leds/leds-lp5523.c| 13 +++
> drivers/leds/leds-lp55xx-common.c | 131 ++
> drivers/leds/leds-lp55xx-common.h | 9 ++
> include/linux/platform_data/leds-lp55xx.h | 6 +
> 4 files changed, 137 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
> index d0b931a136b9..8b2cdb98fed6 100644
> --- a/drivers/leds/leds-lp5523.c
> +++ b/drivers/leds/leds-lp5523.c
> @@ -791,6 +791,18 @@ static ssize_t store_master_fader_leds(struct device
> *dev,
> return ret;
> }
>
> +static int lp5523_led_intensity(struct lp55xx_led *led, int chan_num)
> +{
> + struct lp55xx_chip *chip = led->chip;
> + int ret;
> +
> + mutex_lock(>lock);
> + ret = lp55xx_write(chip, LP5523_REG_LED_PWM_BASE + chan_num,
> + led->brightness);
> + mutex_unlock(>lock);
> + return ret;
> +}
> +
> static int lp5523_led_brightness(struct lp55xx_led *led)
> {
> struct lp55xx_chip *chip = led->chip;
> @@ -857,6 +869,7 @@ static struct lp55xx_device_config lp5523_cfg = {
> .max_channel = LP5523_MAX_LEDS,
> .post_init_device = lp5523_post_init_device,
> .brightness_fn = lp5523_led_brightness,
> + .color_intensity_fn = lp5523_led_intensity,
> .set_led_current= lp5523_set_led_current,
> .firmware_cb= lp5523_firmware_loaded,
> .run_engine = lp5523_run_engine,
> diff --git a/drivers/leds/leds-lp55xx-common.c
> b/drivers/leds/leds-lp55xx-common.c
> index 44ced02b49f9..a5efe2407832 100644
> --- a/drivers/leds/leds-lp55xx-common.c
> +++ b/drivers/leds/leds-lp55xx-common.c
> @@ -136,9 +136,26 @@ static int lp55xx_set_brightness(struct led_classdev
> *cdev,
> {
> struct lp55xx_led *led = cdev_to_lp55xx_led(cdev);
> struct lp55xx_device_config *cfg = led->chip->cfg;
> + int adj_value[LED_COLOR_ID_MAX];
This looks suboptimal. This array should have only the number
of elements equal to the number of requested colors.
> + int ret;
> + int i;
> +
> + if (led->mc_cdev.num_leds > 1) {
> + led_mc_calc_brightness(>mc_cdev,
> +brightness, adj_value);
I still feel uncomfortable with the name of the third
argument for led_mc_calc_brightness().
In the function definition I proposed brightness_val instead of
adj_value, but this is not too informative either.
How about brightness_dimmed ? If you agree then let's change it
also in the definition. Also the type should be enum led_brightness.
Here we would have the following call:
led_mc_calc_brightness(>mc_cdev, brightness, brightness_dimmed);
> + for (i = 0; i < led->mc_cdev.num_leds; i++) {
> + led->brightness = adj_value[i];
> + ret = cfg->color_intensity_fn(led,
> + led->grouped_channels[i]);
> + if (ret)
> + break;
> + }
> + } else {
> + led->brightness = (u8)brightness;
> + ret = cfg->brightness_fn(led);
> + }
>
> - led->brightness = (u8)brightness;
> - return cfg->brightness_fn(led);
> + return ret;
> }
>
> static int lp55xx_init_led(struct lp55xx_led *led,
> @@ -147,9 +164,9 @@ static int lp55xx_init_led(struct lp55xx_led *led,
> struct lp55xx_platform_data *pdata = chip->pdata;
> struct lp55xx_device_config *cfg = chip->cfg;
> struct device *dev = >cl->dev;
> + int max_channel = cfg->max_channel;
> char name[32];
> int ret;
> - int max_channel = cfg->max_channel;
>
> if (chan >= max_channel) {
> dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
> @@ -159,10 +176,35 @@ static int lp55xx_init_led(struct lp55xx_led *led,
> if (pdata->led_config[chan].led_current == 0)
> return 0;
>
> + if (pdata->led_config[chan].name) {
> + led->cdev.name = pdata->led_config[chan].name;
> + } else {
> + snprintf(name, sizeof(name), "%s:channel%d",
> + pdata->label ? : chip->cl->name, chan);
> + led->cdev.name = name;
> + }
> +
> + if (pdata->led_config[chan].num_colors > 1) {> +
> led->mc_cdev.led_cdev = >cdev;
> + led->cdev.brightness_set_blocking = lp55xx_set_brightness;
> + led->cdev.groups = lp55xx_led_groups;
> + led->mc_cdev.num_leds = pdata->led_config[chan].num_colors;
> + led->mc_cdev.available_colors =
> pdata->led_config[chan].available_colors;
> + memcpy(led->channel_color,
> +pdata->led_config[chan].channel_color,
> +sizeof(led->channel_color));
> +
Re: [PATCH] iio: adc: stm32-adc: fix kernel-doc warnings
On Fri, 20 Sep 2019 13:50:06 +0200
Fabrice Gasnier wrote:
> Fix the following warnings when documentation is built:
> drivers/iio/adc/stm32-adc-core.c:62: warning: cannot understand function
> prototype: 'struct stm32_adc_common_regs '
> drivers/iio/adc/stm32-adc-core.c:78: warning: cannot understand function
> prototype: 'struct stm32_adc_priv_cfg '
> drivers/iio/adc/stm32-adc-core.c:123: warning: Function parameter or
> member 'pdev' not described in 'stm32f4_adc_clk_sel'
> drivers/iio/adc/stm32-adc.c:219: warning: cannot understand function
> prototype: 'struct stm32_adc_regs '
> drivers/iio/adc/stm32-adc.c:237: warning: cannot understand function
> prototype: 'struct stm32_adc_regspec '
> drivers/iio/adc/stm32-adc.c:264: warning: cannot understand function
> prototype: 'struct stm32_adc_cfg '
> drivers/iio/adc/stm32-adc.c:323: warning: Function parameter or member
> 'difsel' not described in 'N'
> drivers/iio/adc/stm32-adc.c:323: warning: Function parameter or member
> 'pcsel' not described in 'stm32_adc'
> drivers/iio/adc/stm32-adc.c:371: warning: cannot understand function
> prototype: 'const struct stm32_adc_regs stm32f4_sq[STM32_ADC_MAX_SQ + 1]
> drivers/iio/adc/stm32-adc.c:417: warning: cannot understand function
> prototype: 'const struct stm32_adc_regs stm32f4_smp_bits[] = '
> drivers/iio/adc/stm32-adc.c:508: warning: cannot understand function
> prototype: 'const struct stm32_adc_regs stm32h7_smp_bits[] = '
> drivers/iio/adc/stm32-adc.c:1112: warning: Function parameter or member
> 'indio_dev' not described in 'stm32_adc_get_trig_extsel'
> drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
> 'indio_dev' not described in 'stm32_adc_debugfs_reg_access'
> drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
> 'reg' not described in 'stm32_adc_debugfs_reg_access'
> drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
> 'writeval' not described in 'stm32_adc_debugfs_reg_access'
> drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
> 'readval' not described in 'stm32_adc_debugfs_reg_access'
>
> Signed-off-by: Fabrice Gasnier
As I don't think we build these particular docs by default, I'm not going
to take this as a fix. Hence it'll have to wait for the below to be
upstream of my togreg branch.
Give me a poke if that's true and I seem to have missed it.
Thanks,
Jonathan
> ---
> Note: this applies on top of "iio: adc: stm32-adc: fix a race when using
> several adcs with dma and irq"
> ---
> drivers/iio/adc/stm32-adc-core.c | 11 ++-
> drivers/iio/adc/stm32-adc.c | 21 +
> 2 files changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc-core.c
> b/drivers/iio/adc/stm32-adc-core.c
> index 93a096a..20c626c 100644
> --- a/drivers/iio/adc/stm32-adc-core.c
> +++ b/drivers/iio/adc/stm32-adc-core.c
> @@ -38,12 +38,12 @@
> #define HAS_ANASWVDD BIT(1)
>
> /**
> - * stm32_adc_common_regs - stm32 common registers, compatible dependent data
> + * struct stm32_adc_common_regs - stm32 common registers
> * @csr: common status register offset
> * @ccr: common control register offset
> - * @eoc1:adc1 end of conversion flag in @csr
> - * @eoc2:adc2 end of conversion flag in @csr
> - * @eoc3:adc3 end of conversion flag in @csr
> + * @eoc1_msk:adc1 end of conversion flag in @csr
> + * @eoc2_msk:adc2 end of conversion flag in @csr
> + * @eoc3_msk:adc3 end of conversion flag in @csr
> * @ier: interrupt enable register offset for each adc
> * @eocie_msk: end of conversion interrupt enable mask in @ier
> */
> @@ -60,7 +60,7 @@ struct stm32_adc_common_regs {
> struct stm32_adc_priv;
>
> /**
> - * stm32_adc_priv_cfg - stm32 core compatible configuration data
> + * struct stm32_adc_priv_cfg - stm32 core compatible configuration data
> * @regs:common registers for all instances
> * @clk_sel: clock selection routine
> * @max_clk_rate_hz: maximum analog clock rate (Hz, from datasheet)
> @@ -117,6 +117,7 @@ static int stm32f4_pclk_div[] = {2, 4, 6, 8};
>
> /**
> * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
> + * @pdev: platform device
> * @priv: stm32 ADC core private data
> * Select clock prescaler used for analog conversions, before using ADC.
> */
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 663f8a5..76a247b 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -102,7 +102,7 @@ struct stm32_adc_calib {
> };
>
> /**
> - * stm32_adc_regs - stm32 ADC misc registers & bitfield desc
> + * struct stm32_adc_regs - stm32 ADC misc registers & bitfield desc
> * @reg: register offset
> * @mask:bitfield mask
> * @shift: left shift
> @@ -114,7 +114,7 @@ struct stm32_adc_regs {
> };
>
> /**
> - * stm32_adc_regspec - stm32 registers definition,
Re: [PATCH v2 2/2] iio: adc: stm32-adc: fix a race when using several adcs with dma and irq
On Tue, 17 Sep 2019 14:38:16 +0200
Fabrice Gasnier wrote:
> End of conversion may be handled by using IRQ or DMA. There may be a
> race when two conversions complete at the same time on several ADCs.
> EOC can be read as 'set' for several ADCs, with:
> - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally
> called in this case.
> - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA
> request instead. It's then automatically cleared by DMA read. But the
> handler gets called due to status bit is temporarily set (IRQ triggered
> by the other ADC).
> So both EOC status bit in CSR and EOCIE control bit must be checked
> before invoking the interrupt handler (e.g. call ISR only for
> IRQ-enabled ADCs).
>
> Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
>
> Signed-off-by: Fabrice Gasnier
Both applied to the fixes-togreg branch of iio.git and marked for
stable.
Thanks,
Jonathan
> ---
> Changes in v2:
> - Keep registers definitions as a whole block to ease readability (add
> a precursor patch to move them to header file)
> ---
> drivers/iio/adc/stm32-adc-core.c | 43
> +---
> drivers/iio/adc/stm32-adc-core.h | 1 +
> 2 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc-core.c
> b/drivers/iio/adc/stm32-adc-core.c
> index 84ac326..93a096a 100644
> --- a/drivers/iio/adc/stm32-adc-core.c
> +++ b/drivers/iio/adc/stm32-adc-core.c
> @@ -44,6 +44,8 @@
> * @eoc1:adc1 end of conversion flag in @csr
> * @eoc2:adc2 end of conversion flag in @csr
> * @eoc3:adc3 end of conversion flag in @csr
> + * @ier: interrupt enable register offset for each adc
> + * @eocie_msk: end of conversion interrupt enable mask in @ier
> */
> struct stm32_adc_common_regs {
> u32 csr;
> @@ -51,6 +53,8 @@ struct stm32_adc_common_regs {
> u32 eoc1_msk;
> u32 eoc2_msk;
> u32 eoc3_msk;
> + u32 ier;
> + u32 eocie_msk;
> };
>
> struct stm32_adc_priv;
> @@ -276,6 +280,8 @@ static const struct stm32_adc_common_regs
> stm32f4_adc_common_regs = {
> .eoc1_msk = STM32F4_EOC1,
> .eoc2_msk = STM32F4_EOC2,
> .eoc3_msk = STM32F4_EOC3,
> + .ier = STM32F4_ADC_CR1,
> + .eocie_msk = STM32F4_EOCIE,
> };
>
> /* STM32H7 common registers definitions */
> @@ -284,8 +290,24 @@ static const struct stm32_adc_common_regs
> stm32h7_adc_common_regs = {
> .ccr = STM32H7_ADC_CCR,
> .eoc1_msk = STM32H7_EOC_MST,
> .eoc2_msk = STM32H7_EOC_SLV,
> + .ier = STM32H7_ADC_IER,
> + .eocie_msk = STM32H7_EOCIE,
> };
>
> +static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS] = {
> + 0, STM32_ADC_OFFSET, STM32_ADC_OFFSET * 2,
> +};
> +
> +static unsigned int stm32_adc_eoc_enabled(struct stm32_adc_priv *priv,
> + unsigned int adc)
> +{
> + u32 ier, offset = stm32_adc_offset[adc];
> +
> + ier = readl_relaxed(priv->common.base + offset + priv->cfg->regs->ier);
> +
> + return ier & priv->cfg->regs->eocie_msk;
> +}
> +
> /* ADC common interrupt for all instances */
> static void stm32_adc_irq_handler(struct irq_desc *desc)
> {
> @@ -296,13 +318,28 @@ static void stm32_adc_irq_handler(struct irq_desc *desc)
> chained_irq_enter(chip, desc);
> status = readl_relaxed(priv->common.base + priv->cfg->regs->csr);
>
> - if (status & priv->cfg->regs->eoc1_msk)
> + /*
> + * End of conversion may be handled by using IRQ or DMA. There may be a
> + * race here when two conversions complete at the same time on several
> + * ADCs. EOC may be read 'set' for several ADCs, with:
> + * - an ADC configured to use DMA (EOC triggers the DMA request, and
> + * is then automatically cleared by DR read in hardware)
> + * - an ADC configured to use IRQs (EOCIE bit is set. The handler must
> + * be called in this case)
> + * So both EOC status bit in CSR and EOCIE control bit must be checked
> + * before invoking the interrupt handler (e.g. call ISR only for
> + * IRQ-enabled ADCs).
> + */
> + if (status & priv->cfg->regs->eoc1_msk &&
> + stm32_adc_eoc_enabled(priv, 0))
> generic_handle_irq(irq_find_mapping(priv->domain, 0));
>
> - if (status & priv->cfg->regs->eoc2_msk)
> + if (status & priv->cfg->regs->eoc2_msk &&
> + stm32_adc_eoc_enabled(priv, 1))
> generic_handle_irq(irq_find_mapping(priv->domain, 1));
>
> - if (status & priv->cfg->regs->eoc3_msk)
> + if (status & priv->cfg->regs->eoc3_msk &&
> + stm32_adc_eoc_enabled(priv, 2))
> generic_handle_irq(irq_find_mapping(priv->domain, 2));
>
> chained_irq_exit(chip, desc);
> diff --git a/drivers/iio/adc/stm32-adc-core.h
> b/drivers/iio/adc/stm32-adc-core.h
> index 94aa2d2..2579d51 100644
> --- a/drivers/iio/adc/stm32-adc-core.h
> +++
Re: KASAN: use-after-free Read in rxrpc_release_call
syzbot has bisected this bug to:
commit 2baec2c3f854d1f79c7bb28386484e144e864a14
Author: David Howells
Date: Wed May 24 16:02:32 2017 +
rxrpc: Support network namespacing
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16240b0960
start commit: f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=15240b0960
console output: https://syzkaller.appspot.com/x/log.txt?x=11240b0960
kernel config: https://syzkaller.appspot.com/x/.config?x=61f948934213449f
dashboard link: https://syzkaller.appspot.com/bug?extid=eed305768ece6682bb7f
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf8ea160
Reported-by: syzbot+eed305768ece6682b...@syzkaller.appspotmail.com
Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Thu, 19 Sep 2019 16:34:46 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/018c6837f3e63b45163d55a1668d9f8e6fdecf6e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: bringing back media/zoran driver
Hi Corentin, On Sat, Sep 21, 2019 at 07:03:57PM +0200, Corentin Labbe wrote: > hello > > I am the owner of a zoran based DC10+ card. > I am in the need of using it since yesterday and I found that its driver was > removed. > > Reverting the removing patch made to a temporary working situation. Sorry the the unpleasant surprise caused by the driver removal. > If I understand correctly, it was removed due to lack of vb2 convertion. > If I am able to do this vb2 conversion, does bring it back in mainline will > be posssible ? > In that case I am ready to assume to be the maintainer if needed. That would be great ! I used to own a DC10 a long time ago, and the zoran driver was the first one I tried to hack when I moved to Linux. I'd love to see it getting maintained. Please let us know if you need any help getting started. -- Regards, Laurent Pinchart
Re: bringing back media/zoran driver
Em Sat, 21 Sep 2019 19:03:57 +0200 Corentin Labbe escreveu: > hello > > I am the owner of a zoran based DC10+ card. > I am in the need of using it since yesterday and I found that its driver was > removed. > > Reverting the removing patch made to a temporary working situation. > > If I understand correctly, it was removed due to lack of vb2 convertion. > If I am able to do this vb2 conversion, does bring it back in mainline will > be posssible ? Yes. > In that case I am ready to assume to be the maintainer if needed. Yeah, if we're willing to re-add it, the best is if you can also maintain it. Thanks, Mauro
drivers/net/wireless/mediatek/mt76/mt7615/mac.c:18:10: note: in expansion of macro 'FIELD_GET'
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git master head: f97c81dc6ca5996560b3944064f63fc87eb18d00 commit: bf92e76851009e6bf082db9e9de9b0ab9320cf26 mt76: mt7615: add support for per-chain signal strength reporting date: 3 months ago config: x86_64-randconfig-g003-201938 (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: git checkout bf92e76851009e6bf082db9e9de9b0ab9320cf26 # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All error/warnings (new ones prefixed by >>): Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit Cyclomatic Complexity 1 arch/x86/include/asm/arch_hweight.h:__arch_hweight32 Cyclomatic Complexity 1 arch/x86/include/asm/arch_hweight.h:__arch_hweight8 Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_bh Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_bh Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_lock Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_unlock Cyclomatic Complexity 1 include/linux/rcutiny.h:rcu_is_watching Cyclomatic Complexity 1 include/linux/dma-debug.h:debug_dma_unmap_page Cyclomatic Complexity 1 include/linux/dma-mapping.h:valid_dma_direction Cyclomatic Complexity 1 arch/x86/include/asm/dma-mapping.h:get_arch_dma_ops Cyclomatic Complexity 2 include/linux/dma-mapping.h:get_dma_ops Cyclomatic Complexity 1 include/linux/skbuff.h:skb_get_queue_mapping Cyclomatic Complexity 1 include/linux/etherdevice.h:is_multicast_ether_addr Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_has_a4 Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_is_mgmt Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_is_data Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_is_data_qos Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_is_beacon Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_is_back_req Cyclomatic Complexity 1 include/linux/ieee80211.h:ieee80211_is_qos_nullfunc Cyclomatic Complexity 2 include/linux/ieee80211.h:ieee80211_get_qos_ctl Cyclomatic Complexity 1 include/net/mac80211.h:ieee80211_rate_get_vht_mcs Cyclomatic Complexity 1 include/net/mac80211.h:ieee80211_rate_get_vht_nss Cyclomatic Complexity 1 include/net/mac80211.h:IEEE80211_SKB_CB Cyclomatic Complexity 1 drivers/net/wireless/mediatek/mt76/mt7615/../mt76.h:mt76_get_txwi_ptr Cyclomatic Complexity 3 drivers/net/wireless/mediatek/mt76/mt7615/../mt76.h:wcid_to_sta Cyclomatic Complexity 2 include/net/mac80211.h:ieee80211_tx_info_clear_status Cyclomatic Complexity 21 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_fill_txs Cyclomatic Complexity 8 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_rx_get_wcid Cyclomatic Complexity 4 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:to_rssi Cyclomatic Complexity 1 include/linux/netdevice.h:dev_kfree_skb_any Cyclomatic Complexity 1 include/linux/dma-mapping.h:dma_is_direct Cyclomatic Complexity 3 include/linux/dma-mapping.h:dma_unmap_page_attrs Cyclomatic Complexity 1 include/linux/dma-mapping.h:dma_unmap_single_attrs Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_lock_acquire Cyclomatic Complexity 4 include/linux/rcupdate.h:rcu_read_lock Cyclomatic Complexity 6 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_add_txs_skb Cyclomatic Complexity 1 include/net/mac80211.h:ieee80211_tx_status_noskb Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_lock_release Cyclomatic Complexity 4 include/linux/rcupdate.h:rcu_read_unlock Cyclomatic Complexity 37 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_fill_rx Cyclomatic Complexity 1 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_sta_ps Cyclomatic Complexity 5 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_tx_complete_skb Cyclomatic Complexity 16 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_tx_rate_val Cyclomatic Complexity 47 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_write_txwi Cyclomatic Complexity 2 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_txp_skb_unmap Cyclomatic Complexity 8 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_tx_prepare_skb Cyclomatic Complexity 10 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_add_txs Cyclomatic Complexity 4 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_tx_free Cyclomatic Complexity 1 drivers/net/wireless/mediatek/mt76/mt7615/mac.c:mt7615_mac_work Cyclomatic Complexity 1
Re: [GIT PULL] compiler-attributes for v5.4
The pull request you sent on Thu, 19 Sep 2019 23:54:21 +0200: > https://github.com/ojeda/linux.git tags/compiler-attributes-for-linus-v5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/227c3e9eb5cf3552c2cc83225df6d14adb05f8e8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] gcc-plugins update for v5.4-rc1
The pull request you sent on Mon, 16 Sep 2019 14:44:54 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > tags/gcc-plugins-v5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/56c631f5aec35117b0b5862a09a447a72dfbd678 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] printk for 5.4
The pull request you sent on Mon, 16 Sep 2019 13:24:31 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk > tags/printk-for-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/56c1e8343494f0a315c99964ea1a952478394a8d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mm: slub: print_hex_dump() with DUMP_PREFIX_OFFSET
On Sat, 21 Sep 2019, David Rientjes wrote: > I agree it looks nicer for poisoning, I'm not sure that every caller of > print_section() is the same, however. For example trace() seems better > off as DUMP_PREFIX_ADDRESS since it already specifies the address of the > object being allocated or freed and offset here wouldn't really be useful, > no? The address is printed earlier before the object dump. Maybe that is sufficient and we could even reduce the number of digits further to have the display more compact? In this case two hex digits would do the trick.
Re: [RFC] microoptimizing hlist_add_{before,behind}
On Fri, Sep 20, 2019 at 8:11 PM Al Viro wrote: > > My apologies ;-/ Correct diff follows: This is similar to what we do for the regular list_add(), so I have no objections to the micro-optimization. Of course, for list_add() we do it by using a helper function and passing those prev/next pointers to it instead, so it _looks_ very different. But the logic is the same: do the loads of next/prev early and once, so that gcc doesn't think they might alias with the updates. However, I *really* don't like this syntax: struct hlist_node *p = n->next = prev->next; What, what? That's illegible. Both for the double assignment within a declaration, but also for the naming. Yeah, I assume you mean 'p' just for pointer. Fine. But when we are explicitly playing with multiple pointers, just give them a name. In this case, 'next'. So just do hlist_add_behind: struct hlist_node *next = prev->next; n->next = next; prev->next = n; n->pprev = >next; if (next) next->pprev = >next; And honestly, I'd rename 'n' with 'new' too while at it. We're not using C++, so we can use sane names (and already do in other places). That way each statement makes sense on its own, rather than being a mess of "what does 'p' and 'n' mean?" Linus
[PATCH] EDAC: BlueField: Use devm_platform_ioremap_resource() in bluefield_edac_mc_probe()
From: Markus Elfring
Date: Sat, 21 Sep 2019 18:56:54 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/edac/bluefield_edac.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/edac/bluefield_edac.c b/drivers/edac/bluefield_edac.c
index e4736eb37bfb..0d09add30460 100644
--- a/drivers/edac/bluefield_edac.c
+++ b/drivers/edac/bluefield_edac.c
@@ -245,7 +245,6 @@ static int bluefield_edac_mc_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct edac_mc_layer layers[1];
struct mem_ctl_info *mci;
- struct resource *emi_res;
unsigned int mc_idx, dimm_count;
int rc, ret;
@@ -266,10 +265,6 @@ static int bluefield_edac_mc_probe(struct platform_device
*pdev)
return -EINVAL;
}
- emi_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!emi_res)
- return -EINVAL;
-
layers[0].type = EDAC_MC_LAYER_SLOT;
layers[0].size = dimm_count;
layers[0].is_virt_csrow = true;
@@ -281,7 +276,7 @@ static int bluefield_edac_mc_probe(struct platform_device
*pdev)
priv = mci->pvt_info;
priv->dimm_per_mc = dimm_count;
- priv->emi_base = devm_ioremap_resource(dev, emi_res);
+ priv->emi_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->emi_base)) {
dev_err(dev, "failed to map EMI IO resource\n");
ret = PTR_ERR(priv->emi_base);
--
2.23.0
bringing back media/zoran driver
hello I am the owner of a zoran based DC10+ card. I am in the need of using it since yesterday and I found that its driver was removed. Reverting the removing patch made to a temporary working situation. If I understand correctly, it was removed due to lack of vb2 convertion. If I am able to do this vb2 conversion, does bring it back in mainline will be posssible ? In that case I am ready to assume to be the maintainer if needed. Regards
[RFT v3 6/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos5250
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Signed-off-by: Krzysztof Kozlowski
---
Not tested.
---
arch/arm/boot/dts/exynos5250.dtsi | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 7a01349317a3..e0fcf3c2f537 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -233,28 +233,22 @@
power-domains = <_mau>;
};
- timer@101c {
+ mct: timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101C 0x800>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <_map>;
- interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
-<4 0>, <5 0>;
clocks = < CLK_FIN_PLL>, < CLK_MCT>;
clock-names = "fin_pll", "mct";
-
- mct_map: mct-map {
- #interrupt-cells = <2>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = <0x0 0 23 3>,
- <0x1 0 23 4>,
- <0x2 0 25 2>,
- <0x3 0 25 3>,
- <0x4 0 0 120
IRQ_TYPE_LEVEL_HIGH>,
- <0x5 0 0 121
IRQ_TYPE_LEVEL_HIGH>;
- };
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
+ interrupt-map = <0 23 3>,
+ <1 23 4>,
+ <2 25 2>,
+ <3 25 3>,
+ <4 0 120 IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 121 IRQ_TYPE_LEVEL_HIGH>;
};
pinctrl_0: pinctrl@1140 {
--
2.17.1
[PATCH v3 3/8] arm64: dts: exynos: Rename Multi Core Timer node to "timer"
The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer". This will be also in
sync with upcoming DT schema. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index a76f620f7f35..8baf3c645eae 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -754,7 +754,7 @@
status = "disabled";
};
- mct@101c {
+ timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101c 0x800>;
interrupts = ,
--
2.17.1
[PATCH v3 8/8] ARM: dts: exynos: Use defines for MCT interrupt GIC SPI/PPI specifier
Replace hard-coded number with appropriate define for GIC SPI or PPI
specifier in interrupt. This makes code easier to read. No expected
functionality change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210.dtsi | 8
arch/arm/boot/dts/exynos4412.dtsi | 4 ++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
arch/arm/boot/dts/exynos54xx.dtsi | 16
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 38c49ab8c733..650bee6355e4 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -116,12 +116,12 @@
#interrupt-cells = <1>;
interrupt-parent = <>;
interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
- interrupt-map = <0 0 57 IRQ_TYPE_LEVEL_HIGH>,
- <1 0 69 IRQ_TYPE_LEVEL_HIGH>,
+ interrupt-map = <0 GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <1 GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
<2 12 6>,
<3 12 7>,
- <4 0 42 IRQ_TYPE_LEVEL_HIGH>,
- <5 0 48 IRQ_TYPE_LEVEL_HIGH>;
+ <4 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <5 GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@1006 {
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 7e2dabefd53f..0810c14bf424 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -253,11 +253,11 @@
#interrupt-cells = <1>;
interrupt-parent = <>;
interrupts = <0>, <1>, <2>, <3>, <4>;
- interrupt-map = <0 0 57 IRQ_TYPE_LEVEL_HIGH>,
+ interrupt-map = <0 GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
<1 12 5>,
<2 12 6>,
<3 12 7>,
- <4 1 12 IRQ_TYPE_LEVEL_HIGH>;
+ <4 GIC_PPI 12 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@1006 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index e0fcf3c2f537..61f22feefda9 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -247,8 +247,8 @@
<1 23 4>,
<2 25 2>,
<3 25 3>,
- <4 0 120 IRQ_TYPE_LEVEL_HIGH>,
- <5 0 121 IRQ_TYPE_LEVEL_HIGH>;
+ <4 GIC_SPI 120
IRQ_TYPE_LEVEL_HIGH>,
+ <5 GIC_SPI 121
IRQ_TYPE_LEVEL_HIGH>;
};
pinctrl_0: pinctrl@1140 {
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index a1c10a9a86f8..f52c7ce5d320 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -77,14 +77,14 @@
<1 23 4>,
<2 25 2>,
<3 25 3>,
- <4 0 120 IRQ_TYPE_LEVEL_HIGH>,
- <5 0 121 IRQ_TYPE_LEVEL_HIGH>,
- <6 0 122 IRQ_TYPE_LEVEL_HIGH>,
- <7 0 123 IRQ_TYPE_LEVEL_HIGH>,
- <8 0 128 IRQ_TYPE_LEVEL_HIGH>,
- <9 0 129 IRQ_TYPE_LEVEL_HIGH>,
- <10 0 130 IRQ_TYPE_LEVEL_HIGH>,
- <11 0 131 IRQ_TYPE_LEVEL_HIGH>;
+ <4 GIC_SPI 120
IRQ_TYPE_LEVEL_HIGH>,
+ <5 GIC_SPI 121
IRQ_TYPE_LEVEL_HIGH>,
+ <6 GIC_SPI 122
IRQ_TYPE_LEVEL_HIGH>,
+ <7 GIC_SPI 123
IRQ_TYPE_LEVEL_HIGH>,
+ <8 GIC_SPI 128
IRQ_TYPE_LEVEL_HIGH>,
+ <9 GIC_SPI 129
IRQ_TYPE_LEVEL_HIGH>,
+ <10 GIC_SPI 130
IRQ_TYPE_LEVEL_HIGH>,
+ <11 GIC_SPI 131
IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@101d {
--
2.17.1
[RFT v3 4/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4210
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Signed-off-by: Krzysztof Kozlowski
---
Not tested.
---
arch/arm/boot/dts/exynos4210.dtsi | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 6d3f19562aab..38c49ab8c733 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -109,23 +109,19 @@
mct: timer@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
- interrupt-parent = <_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
clocks = < CLK_FIN_PLL>, < CLK_MCT>;
clock-names = "fin_pll", "mct";
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map =
- <0 0 57 IRQ_TYPE_LEVEL_HIGH>,
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
+ interrupt-map = <0 0 57 IRQ_TYPE_LEVEL_HIGH>,
<1 0 69 IRQ_TYPE_LEVEL_HIGH>,
<2 12 6>,
<3 12 7>,
<4 0 42 IRQ_TYPE_LEVEL_HIGH>,
<5 0 48 IRQ_TYPE_LEVEL_HIGH>;
- };
};
watchdog: watchdog@1006 {
--
2.17.1
[PATCH v3 1/8] dt-bindings: timer: Convert Exynos MCT bindings to json-schema
Convert Samsung Exynos Soc Multi Core Timer bindings to DT schema format
using json-schema.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Indent example with four spaces (more readable),
2. Rename nodes in example to timer,
3. Remove mct-map subnode.
---
.../bindings/timer/samsung,exynos4210-mct.txt | 88 --
.../timer/samsung,exynos4210-mct.yaml | 113 ++
2 files changed, 113 insertions(+), 88 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
create mode 100644
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
deleted file mode 100644
index 8f78640ad64c..
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Samsung's Multi Core Timer (MCT)
-
-The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
-global timer and CPU local timers. The global timer is a 64-bit free running
-up-counter and can generate 4 interrupts when the counter reaches one of the
-four preset counter values. The CPU local timers are 32-bit free running
-down-counters and generate an interrupt when the counter expires. There is
-one CPU local timer instantiated in MCT for every CPU in the system.
-
-Required properties:
-
-- compatible: should be "samsung,exynos4210-mct".
- (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
- (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
-
-- reg: base address of the mct controller and length of the address space
- it occupies.
-
-- interrupts: the list of interrupts generated by the controller. The following
- should be the order of the interrupts specified. The local timer interrupts
- should be specified after the four global timer interrupts have been
- specified.
-
- 0: Global Timer Interrupt 0
- 1: Global Timer Interrupt 1
- 2: Global Timer Interrupt 2
- 3: Global Timer Interrupt 3
- 4: Local Timer Interrupt 0
- 5: Local Timer Interrupt 1
- 6: ..
- 7: ..
- i: Local Timer Interrupt n
-
- For MCT block that uses a per-processor interrupt for local timers, such
- as ones compatible with "samsung,exynos4412-mct", only one local timer
- interrupt might be specified, meaning that all local timers use the same
- per processor interrupt.
-
-Example 1: In this example, the IP contains two local timers, using separate
- interrupts, so two local timer interrupts have been specified,
- in addition to four global timer interrupts.
-
- mct@1005 {
- compatible = "samsung,exynos4210-mct";
- reg = <0x1005 0x800>;
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-<0 42 0>, <0 48 0>;
- };
-
-Example 2: In this example, the timer interrupts are connected to two separate
- interrupt controllers. Hence, an interrupt-map is created to map
- the interrupts to the respective interrupt controllers.
-
- mct@101c {
- compatible = "samsung,exynos4210-mct";
- reg = <0x101C 0x800>;
- interrupt-parent = <_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = <0 0 57 0>,
- <1 0 69 0>,
- <2 12 6>,
- <3 12 7>,
- <4 0 42 0>,
- <5 0 48 0>;
- };
- };
-
-Example 3: In this example, the IP contains four local timers, but using
- a per-processor interrupt to handle them. Either all the local
- timer interrupts can be specified, with the same interrupt specifier
- value or just the first one.
-
- mct@1005 {
- compatible = "samsung,exynos4412-mct";
- reg = <0x1005 0x800>;
-
- /* Both ways are possible in this case. Either: */
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-<0 42 0>;
- /* or: */
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-<0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
- };
diff --git
a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
new file mode 100644
index ..5d6db1ddd7f6
--- /dev/null
+++
[RFT v3 5/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4412
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Tested on Odroid U3 (Exynos4412).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412.dtsi | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 8b6d5875c75d..7e2dabefd53f 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -243,25 +243,21 @@
clock-names = "aclk200", "aclk400_mcuisp";
};
- timer@1005 {
+ mct: timer@1005 {
compatible = "samsung,exynos4412-mct";
reg = <0x1005 0x800>;
- interrupt-parent = <_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>;
clocks = < CLK_FIN_PLL>, < CLK_MCT>;
clock-names = "fin_pll", "mct";
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map =
- <0 0 57 IRQ_TYPE_LEVEL_HIGH>,
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = <0>, <1>, <2>, <3>, <4>;
+ interrupt-map = <0 0 57 IRQ_TYPE_LEVEL_HIGH>,
<1 12 5>,
<2 12 6>,
<3 12 7>,
<4 1 12 IRQ_TYPE_LEVEL_HIGH>;
- };
};
watchdog: watchdog@1006 {
--
2.17.1
[RFT v3 7/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos54xx
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Tested on Odroid XU (Exynos5410), Odroid HC1 (Exynos5422) and Arndale
Octa (Exynos5420).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos54xx.dtsi | 37 ++-
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index 247d23872384..a1c10a9a86f8 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -67,27 +67,24 @@
mct: timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101c 0xb00>;
- interrupt-parent = <_map>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>,
- <8>, <9>, <10>, <11>;
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = <0 23 3>,
- <1 23 4>,
- <2 25 2>,
- <3 25 3>,
- <4 0 120
IRQ_TYPE_LEVEL_HIGH>,
- <5 0 121
IRQ_TYPE_LEVEL_HIGH>,
- <6 0 122
IRQ_TYPE_LEVEL_HIGH>,
- <7 0 123
IRQ_TYPE_LEVEL_HIGH>,
- <8 0 128
IRQ_TYPE_LEVEL_HIGH>,
- <9 0 129
IRQ_TYPE_LEVEL_HIGH>,
- <10 0 130
IRQ_TYPE_LEVEL_HIGH>,
- <11 0 131
IRQ_TYPE_LEVEL_HIGH>;
- };
+<8>, <9>, <10>, <11>;
+ interrupt-map = <0 23 3>,
+ <1 23 4>,
+ <2 25 2>,
+ <3 25 3>,
+ <4 0 120 IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 121 IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 122 IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 123 IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 128 IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 129 IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 130 IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 131 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@101d {
--
2.17.1
[PATCH v3 2/8] ARM: dts: exynos: Rename Multi Core Timer node to "timer"
The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer". This will be also in
sync with upcoming DT schema. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos4210.dtsi | 2 +-
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos54xx.dtsi | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 784818490376..d122fb52d3d4 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -265,7 +265,7 @@
(GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
};
- mct@1005 {
+ timer@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
interrupts = ,
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index f220716239db..6d3f19562aab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -106,7 +106,7 @@
arm,data-latency = <2 2 1>;
};
- mct: mct@1005 {
+ mct: timer@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
interrupt-parent = <_map>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index d20db2dfe8e2..8b6d5875c75d 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -243,7 +243,7 @@
clock-names = "aclk200", "aclk400_mcuisp";
};
- mct@1005 {
+ timer@1005 {
compatible = "samsung,exynos4412-mct";
reg = <0x1005 0x800>;
interrupt-parent = <_map>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index fc966c10cf49..7a01349317a3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -233,7 +233,7 @@
power-domains = <_mau>;
};
- mct@101c {
+ timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101C 0x800>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index 3581b57fbbf7..b0811dbbb362 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -180,7 +180,7 @@
reg = <0x1000 0x100>;
};
- mct: mct@100b {
+ mct: timer@100b {
compatible = "samsung,exynos4210-mct";
reg = <0x100B 0x1000>;
clocks = <_pll>, <_peri PERI_CLK_MCT>;
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index 9c3b63b7cac6..247d23872384 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -64,7 +64,7 @@
};
};
- mct: mct@101c {
+ mct: timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101c 0xb00>;
interrupt-parent = <_map>;
--
2.17.1
[GIT PULL] rpmsg updates for v5.4
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc tags/rpmsg-v5.4 for you to fetch changes up to 9fe69a725e238ac279027f0132e50617a63b847d: rpmsg: glink-smem: Name the edge based on parent remoteproc (2019-09-17 15:33:31 -0700) rpmsg updates for v5.4 This contains updates to make the rpmsg sample driver more useful, fixes the naming of GLINK devices to avoid naming collisions and a few minor bug fixes. It also updates MAINTAINERS to reflect the move to kernel.org. Bjorn Andersson (1): rpmsg: glink-smem: Name the edge based on parent remoteproc Gustavo A. R. Silva (1): rpmsg: glink: Use struct_size() helper Pierre-Louis Bossart (2): rpmsg: core: fix comments MAINTAINERS: rpmsg: fix git tree location Suman Anna (3): samples/rpmsg: Replace print_hex_dump() with print_hex_dump_debug() samples/rpmsg: Introduce a module parameter for message count rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK" MAINTAINERS | 2 +- drivers/rpmsg/qcom_glink_native.c | 2 +- drivers/rpmsg/qcom_glink_smem.c | 2 +- drivers/rpmsg/rpmsg_core.c | 8 drivers/rpmsg/rpmsg_internal.h | 5 +++-- drivers/rpmsg/virtio_rpmsg_bus.c| 2 +- samples/rpmsg/rpmsg_client_sample.c | 10 ++ 7 files changed, 17 insertions(+), 14 deletions(-)
[GIT PULL] remoteproc updates for v5.4
Hi Linus, I've finally moved my trees to kernel.org, please pull this and the coming rpmsg request from their new location. Regards, Bjorn The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc tags/rproc-v5.4 for you to fetch changes up to 150997fac770c37b12459ec52fdf67a5dc1366f5: MAINTAINERS: remoteproc: update git tree location (2019-08-26 23:16:44 -0700) remoteproc updates for v5.4 This exposes the remoteproc's name in sysfs, allows stm32 to enter platform standby and provides bug fixes for stm32 and Qualcomm's modem remoteproc drivers. Finally it updates MAINTAINERS to reflect the move to kernel.org. Bjorn Andersson (2): remoteproc: qcom: Move glink_ssr notification after stop MAINTAINERS: remoteproc: update git tree location Fabien Dessenne (2): remoteproc: stm32: clear MCU PDDS at firmware start remoteproc: stm32: manage the get_irq probe defer case Sibi Sankar (1): remoteproc: qcom: q6v5-mss: fixup q6v5_pds_enable error handling Stephen Boyd (1): remoteproc: Remove dev_err() usage after platform_get_irq() Suman Anna (1): remoteproc: Add a sysfs interface for name Documentation/ABI/testing/sysfs-class-remoteproc | 10 +++ MAINTAINERS | 2 +- drivers/remoteproc/da8xx_remoteproc.c| 4 +-- drivers/remoteproc/keystone_remoteproc.c | 4 --- drivers/remoteproc/qcom_common.c | 4 +-- drivers/remoteproc/qcom_q6v5.c | 35 drivers/remoteproc/qcom_q6v5_mss.c | 4 +-- drivers/remoteproc/remoteproc_sysfs.c| 11 drivers/remoteproc/stm32_rproc.c | 14 ++ 9 files changed, 46 insertions(+), 42 deletions(-)
[PATCH] EDAC: Aspeed: Use devm_platform_ioremap_resource() in aspeed_probe()
From: Markus Elfring Date: Sat, 21 Sep 2019 18:32:46 +0200 Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/edac/aspeed_edac.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c index 5634437bb39d..09a9e3de9595 100644 --- a/drivers/edac/aspeed_edac.c +++ b/drivers/edac/aspeed_edac.c @@ -281,16 +281,11 @@ static int aspeed_probe(struct platform_device *pdev) struct device *dev = >dev; struct edac_mc_layer layers[2]; struct mem_ctl_info *mci; - struct resource *res; void __iomem *regs; u32 reg04; int rc; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) - return -ENOENT; - - regs = devm_ioremap_resource(dev, res); + regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(regs)) return PTR_ERR(regs); -- 2.23.0
Re: INFO: task hung in p9_fd_close
syzbot has found a reproducer for the following crash on:
HEAD commit:f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=171a155560
kernel config: https://syzkaller.appspot.com/x/.config?x=61f948934213449f
dashboard link: https://syzkaller.appspot.com/bug?extid=8b41a1365f1106fd0f33
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1641d42960
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11eff9ad60
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8b41a1365f1106fd0...@syzkaller.appspotmail.com
INFO: task syz-executor635:8085 blocked for more than 143 seconds.
Not tainted 5.3.0+ #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor635 D27848 8085 8070 0x4004
Call Trace:
context_switch kernel/sched/core.c:3384 [inline]
__schedule+0x82e/0xc50 kernel/sched/core.c:4056
schedule+0x131/0x1e0 kernel/sched/core.c:4123
schedule_timeout+0x46/0x240 kernel/time/timer.c:1869
do_wait_for_common+0x2e7/0x4d0 kernel/sched/completion.c:83
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x47/0x60 kernel/sched/completion.c:136
__flush_work+0xd4/0x150 kernel/workqueue.c:3040
__cancel_work_timer+0x420/0x570 kernel/workqueue.c:3127
cancel_work_sync+0x17/0x20 kernel/workqueue.c:3163
p9_conn_destroy net/9p/trans_fd.c:868 [inline]
p9_fd_close+0x297/0x3c0 net/9p/trans_fd.c:898
p9_client_create+0x974/0xee0 net/9p/client.c:1068
v9fs_session_init+0x192/0x18e0 fs/9p/v9fs.c:406
v9fs_mount+0x82/0x860 fs/9p/vfs_super.c:124
legacy_get_tree+0xf9/0x1a0 fs/fs_context.c:659
vfs_get_tree+0x8f/0x380 fs/super.c:1542
do_new_mount fs/namespace.c:2825 [inline]
do_mount+0x16c7/0x2510 fs/namespace.c:3145
ksys_mount+0xcc/0x100 fs/namespace.c:3354
__do_sys_mount fs/namespace.c:3368 [inline]
__se_sys_mount fs/namespace.c:3365 [inline]
__x64_sys_mount+0xbf/0xd0 fs/namespace.c:3365
do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447909
Code: e8 5c 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 9b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7eff1aea0db8 EFLAGS: 0246 ORIG_RAX: 00a5
RAX: ffda RBX: 006ddc78 RCX: 00447909
RDX: 25c0 RSI: 2540 RDI:
RBP: 006ddc70 R08: 2680 R09:
R10: R11: 0246 R12: 006ddc7c
R13: 7ffc4e6377ef R14: 7eff1aea19c0 R15: 002d
Showing all locks held in the system:
2 locks held by kworker/1:1/22:
#0: 8880aa4278e8 ((wq_completion)events){+.+.}, at: spin_unlock_irq
include/linux/spinlock.h:388 [inline]
#0: 8880aa4278e8 ((wq_completion)events){+.+.}, at:
process_one_work+0x75d/0x10e0 kernel/workqueue.c:2242
#1: 8880a9a3fd78 ((work_completion)(>wq)){+.+.}, at:
process_one_work+0x79f/0x10e0 kernel/workqueue.c:2244
1 lock held by khungtaskd/1053:
#0: 888d3900 (rcu_read_lock){}, at: rcu_lock_acquire+0x4/0x30
include/linux/rcupdate.h:207
1 lock held by rsyslogd/7959:
#0: 8880a99f1e20 (>f_pos_lock){+.+.}, at: __fdget_pos+0x243/0x2e0
fs/file.c:801
2 locks held by getty/8049:
#0: 8880a602d450 (>ldisc_sem){}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: c90005f212e0 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8050:
#0: 8880a902ac50 (>ldisc_sem){}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: c90005f092e0 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8051:
#0: 88809c0f1750 (>ldisc_sem){}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: c90005f312e0 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8052:
#0: 88809e344b90 (>ldisc_sem){}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: c90005f152e0 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8053:
#0: 88809e344310 (>ldisc_sem){}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: c90005f1d2e0 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00 drivers/tty/n_tty.c:2156
2 locks held by getty/8054:
#0: 88809c8aa410 (>ldisc_sem){}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: c90005f2d2e0 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x221/0x1b00
Re: [GIT PULL] libnvdimm for 5.4
On Fri, Sep 20, 2019 at 4:57 PM Dan Williams wrote: > > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-for-5.4 > > ...to receive some reworks to better support nvdimms on powerpc and an > nvdimm security interface update. Btw, minor conflict with your tree due to a fix that went into v5.3-rc8. Here's my resolution: diff --cc drivers/nvdimm/pfn_devs.c index cb98b8fe786e,ce9ef18282dd..bb9cc5cf0873 --- a/drivers/nvdimm/pfn_devs.c +++ b/drivers/nvdimm/pfn_devs.c @@@ -724,9 -751,10 +753,11 @@@ static int nd_pfn_init(struct nd_pfn *n memcpy(pfn_sb->uuid, nd_pfn->uuid, 16); memcpy(pfn_sb->parent_uuid, nd_dev_to_uuid(>dev), 16); pfn_sb->version_major = cpu_to_le16(1); - pfn_sb->version_minor = cpu_to_le16(3); + pfn_sb->version_minor = cpu_to_le16(4); + pfn_sb->end_trunc = cpu_to_le32(end_trunc); pfn_sb->align = cpu_to_le32(nd_pfn->align); + pfn_sb->page_struct_size = cpu_to_le16(MAX_STRUCT_PAGE_SIZE); + pfn_sb->page_size = cpu_to_le32(PAGE_SIZE); checksum = nd_sb_checksum((struct nd_gen_sb *) pfn_sb); pfn_sb->checksum = cpu_to_le64(checksum);
Re: [PATCH v4 1/3] led: make led_set_brightness_sync() use led_set_brightness_nosleep()
Hi Jean-Jacques,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jean-Jacques-Hiblot/leds-Add-control-of-the-voltage-current-regulator-to-the-LED-core/20190920-220416
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
:: branch date: 2 hours ago
:: commit date: 2 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers//leds/led-core.c: In function 'led_set_brightness_sync':
>> drivers//leds/led-core.c:302:6: error: void value not ignored as it ought to
>> be
ret = led_set_brightness_nosleep(led_cdev, value);
^
#
https://github.com/0day-ci/linux/commit/54301e6f4e910f292045a1afa62ef732791e1bb5
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 54301e6f4e910f292045a1afa62ef732791e1bb5
vim +302 drivers//leds/led-core.c
81fe8e5b73e3f4 Jacek Anaszewski2015-10-07 293
13ae79bbe4c214 Jacek Anaszewski2015-10-07 294 int
led_set_brightness_sync(struct led_classdev *led_cdev,
13ae79bbe4c214 Jacek Anaszewski2015-10-07 295
enum led_brightness value)
13ae79bbe4c214 Jacek Anaszewski2015-10-07 296 {
54301e6f4e910f Jean-Jacques Hiblot 2019-09-20 297 int ret;
54301e6f4e910f Jean-Jacques Hiblot 2019-09-20 298
13ae79bbe4c214 Jacek Anaszewski2015-10-07 299 if
(led_cdev->blink_delay_on || led_cdev->blink_delay_off)
13ae79bbe4c214 Jacek Anaszewski2015-10-07 300 return -EBUSY;
13ae79bbe4c214 Jacek Anaszewski2015-10-07 301
54301e6f4e910f Jean-Jacques Hiblot 2019-09-20 @302 ret =
led_set_brightness_nosleep(led_cdev, value);
54301e6f4e910f Jean-Jacques Hiblot 2019-09-20 303 if (!ret)
54301e6f4e910f Jean-Jacques Hiblot 2019-09-20 304 return ret;
13ae79bbe4c214 Jacek Anaszewski2015-10-07 305
54301e6f4e910f Jean-Jacques Hiblot 2019-09-20 306
flush_work(_cdev->set_brightness_work);
13ae79bbe4c214 Jacek Anaszewski2015-10-07 307 return 0;
13ae79bbe4c214 Jacek Anaszewski2015-10-07 308 }
13ae79bbe4c214 Jacek Anaszewski2015-10-07 309
EXPORT_SYMBOL_GPL(led_set_brightness_sync);
13ae79bbe4c214 Jacek Anaszewski2015-10-07 310
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: .config.gz
Re: [PATCH] net: dsa: b53: Use the correct style for SPDX License Identifier
On Sat, 21 Sep 2019 19:00:16 +0530, Nishad Kamdar wrote: > This patch corrects the SPDX License Identifier style > in header file for Broadcom BCM53xx managed switch driver. > For C header files Documentation/process/license-rules.rst > mandates C-like comments (opposed to C source files where > C++ style should be used) > > Changes made by using a script provided by Joe Perches here: > https://lkml.org/lkml/2019/2/7/46. > > Suggested-by: Joe Perches > Signed-off-by: Nishad Kamdar Reviewed-by: Vivien Didelot
Re: [PATCH] net: dsa: Use the correct style for SPDX License Identifier
On Sat, 21 Sep 2019 19:15:25 +0530, Nishad Kamdar wrote: > This patch corrects the SPDX License Identifier style > in header file for Distributed Switch Architecture drivers. > For C header files Documentation/process/license-rules.rst > mandates C-like comments (opposed to C source files where > C++ style should be used) > > Changes made by using a script provided by Joe Perches here: > https://lkml.org/lkml/2019/2/7/46. > > Suggested-by: Joe Perches > Signed-off-by: Nishad Kamdar Reviewed-by: Vivien Didelot
Re: [PATCH] mm: slub: print_hex_dump() with DUMP_PREFIX_OFFSET
On Sat, Sep 21, 2019 at 02:08:59AM -0700, David Rientjes wrote:
> On Fri, 20 Sep 2019, Miles Chen wrote:
>
> > Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
> > The use DUMP_PREFIX_OFFSET instead of DUMP_PREFIX_ADDRESS with
> > print_hex_dump() can generate more useful messages.
> >
> > In the following example, it's easier get the offset of incorrect poison
> > value with DUMP_PREFIX_OFFSET.
> >
> > Before:
> > Object e817b73b: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 816f4601: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 169d2bb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object f4c38716: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 917e3491: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object c0e33738: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 1755ddd1: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > After:
> > Object : 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 0010: 63 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 0020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 0030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
>
> I agree it looks nicer for poisoning, I'm not sure that every caller of
> print_section() is the same, however. For example trace() seems better
> off as DUMP_PREFIX_ADDRESS since it already specifies the address of the
> object being allocated or freed and offset here wouldn't really be useful,
> no?
While it looks nicer, it might be less useful for debugging. The point of
obfuscated %p is that you can compare two "pointer" values for equality.
So if you know that you freed object e817b73b from an earlier
printk, then you can match it up to this dump. It's obviously not
perfect since we're only getting the pointers at addresses that are
multiples of 16, but it's a help.
[PATCH] EDAC: Armada XP: Use devm_platform_ioremap_resource() in two functions
From: Markus Elfring
Date: Sat, 21 Sep 2019 17:50:17 +0200
Simplify these function implementations by using a known function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/edac/armada_xp_edac.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index 7f227bdcbc84..096d8de3893e 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -286,17 +286,10 @@ static int axp_mc_probe(struct platform_device *pdev)
struct edac_mc_layer layers[1];
const struct of_device_id *id;
struct mem_ctl_info *mci;
- struct resource *r;
void __iomem *base;
uint32_t config;
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- dev_err(>dev, "Unable to get mem resource\n");
- return -ENODEV;
- }
-
- base = devm_ioremap_resource(>dev, r);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base)) {
dev_err(>dev, "Unable to map regs\n");
return PTR_ERR(base);
@@ -516,15 +509,8 @@ static int aurora_l2_probe(struct platform_device *pdev)
const struct of_device_id *id;
uint32_t l2x0_aux_ctrl;
void __iomem *base;
- struct resource *r;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- dev_err(>dev, "Unable to get mem resource\n");
- return -ENODEV;
- }
- base = devm_ioremap_resource(>dev, r);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base)) {
dev_err(>dev, "Unable to map regs\n");
return PTR_ERR(base);
--
2.23.0
Re: [PATCH v3 2/2] usb: typec: tcpm: AMS for PD2.0
Hi Kyle,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3 next-20190919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Kyle-Tso/usb-typec-tcpm-AMS-and-Collision-Avoidance/20190920-112652
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
:: branch date: 7 hours ago
:: commit date: 7 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/usb/typec/tcpm/tcpm.c: In function 'tcpm_ams_start':
>> drivers/usb/typec/tcpm/tcpm.c:1144:5: warning: 'cc_req' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
tcpm_set_state(port, AMS_START,
^~~
cc_req == SINK_TX_OK ?
~~
PD_T_SINK_TX : 0);
~
#
https://github.com/0day-ci/linux/commit/59e8594ebb63b2f2f6d8ec5a9c9c914f6c476cae
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 59e8594ebb63b2f2f6d8ec5a9c9c914f6c476cae
vim +/cc_req +1144 drivers/usb/typec/tcpm/tcpm.c
0ea47e4d06fe89 Kyle Tso 2019-09-20 1095
0ea47e4d06fe89 Kyle Tso 2019-09-20 1096 static int tcpm_ams_start(struct
tcpm_port *port, enum tcpm_ams ams)
0ea47e4d06fe89 Kyle Tso 2019-09-20 1097 {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1098int ret = 0;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1099
0ea47e4d06fe89 Kyle Tso 2019-09-20 1100tcpm_log(port, "AMS %s start",
tcpm_ams_str[ams]);
0ea47e4d06fe89 Kyle Tso 2019-09-20 1101
0ea47e4d06fe89 Kyle Tso 2019-09-20 1102if
(!tcpm_ams_interruptible(port) && ams != HARD_RESET) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1103port->upcoming_state =
INVALID_STATE;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1104tcpm_log(port, "AMS %s
not interruptible, aborting",
0ea47e4d06fe89 Kyle Tso 2019-09-20 1105
tcpm_ams_str[port->ams]);
0ea47e4d06fe89 Kyle Tso 2019-09-20 1106return -EAGAIN;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1107}
0ea47e4d06fe89 Kyle Tso 2019-09-20 1108
0ea47e4d06fe89 Kyle Tso 2019-09-20 1109if (port->pwr_role ==
TYPEC_SOURCE) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1110enum typec_cc_status
cc_req;
0ea47e4d06fe89 Kyle Tso 2019-09-20
0ea47e4d06fe89 Kyle Tso 2019-09-20 1112port->ams = ams;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1113
0ea47e4d06fe89 Kyle Tso 2019-09-20 1114if (ams == HARD_RESET) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1115
tcpm_set_cc(port, tcpm_rp_cc(port));
0ea47e4d06fe89 Kyle Tso 2019-09-20 1116
tcpm_pd_transmit(port, TCPC_TX_HARD_RESET, NULL);
0ea47e4d06fe89 Kyle Tso 2019-09-20 1117
tcpm_set_state(port, HARD_RESET_START, 0);
0ea47e4d06fe89 Kyle Tso 2019-09-20 1118return ret;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1119} else if (ams ==
SOFT_RESET_AMS) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1120if
(!port->explicit_contract) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1121
port->upcoming_state = INVALID_STATE;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1122
tcpm_set_cc(port, tcpm_rp_cc(port));
0ea47e4d06fe89 Kyle Tso 2019-09-20 1123return
ret;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1124}
0ea47e4d06fe89 Kyle Tso 2019-09-20 1125} else if
(tcpm_vdm_ams(port)) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1126/* tSinkTx is
enforced in vdm_run_state_machine */
59e8594ebb63b2 Kyle Tso 2019-09-20 1127if
(port->negotiated_rev >= PD_REV30)
0ea47e4d06fe89 Kyle Tso 2019-09-20 1128
tcpm_set_cc(port, SINK_TX_NG);
0ea47e4d06fe89 Kyle Tso 2019-09-20 1129return ret;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1130}
0ea47e4d06fe89 Kyle Tso 2019-09-20 1131
59e8594ebb63b2 Kyle Tso 2019-09-20 1132if
(port->negotiated_rev >= PD_REV30) {
0ea47e4d06fe89 Kyle Tso 2019-09-20 1133cc_req =
port->cc_req;
0ea47e4d06fe89 Kyle Tso 2019-09-20 1134
tcpm_set_cc(port, SINK_TX_NG);
59e8594ebb63b2 Kyle Tso 2019-09-20
Re: [PATCH V3 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
Hi Anshuman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-for-architecture-exported-page-table-helpers/20190920-143746
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
:: branch date: 3 hours ago
:: commit date: 3 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
In file included from include/asm-generic/pgtable-nopud.h:8:0,
from arch/ia64/include/asm/pgtable.h:591,
from include/linux/mm.h:99,
from include/linux/highmem.h:8,
from mm/arch_pgtable_test.c:14:
mm/arch_pgtable_test.c: In function 'pud_clear_tests':
>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration
>> of function '__pgd'; did you mean '__p4d'?
>> [-Werror=implicit-function-declaration]
#define __pud(x)((pud_t) { __pgd(x) })
^
>> mm/arch_pgtable_test.c:162:8: note: in expansion of macro '__pud'
pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
^
>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces
>> around initializer [-Wmissing-braces]
#define __pud(x)((pud_t) { __pgd(x) })
^
>> mm/arch_pgtable_test.c:162:8: note: in expansion of macro '__pud'
pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
^
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/49047f93b076974eefa5b019311bd3b734d61f8c
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 49047f93b076974eefa5b019311bd3b734d61f8c
vim +47 include/asm-generic/pgtable-nop4d-hack.h
30ec842660bd0d Kirill A. Shutemov 2017-03-09 45
30ec842660bd0d Kirill A. Shutemov 2017-03-09 46 #define pud_val(x)
(pgd_val((x).pgd))
30ec842660bd0d Kirill A. Shutemov 2017-03-09 @47 #define __pud(x)
((pud_t) { __pgd(x) })
30ec842660bd0d Kirill A. Shutemov 2017-03-09 48
:: The code at line 47 was first introduced by commit
:: 30ec842660bd0d056d4a7028ac5bd4a82b113d4f asm-generic: introduce
__ARCH_USE_5LEVEL_HACK
:: TO: Kirill A. Shutemov
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: .config.gz
WARNING: locking bug in selinux_netlbl_socket_connect
Hello, syzbot found the following crash on: HEAD commit:f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=127b709d60 kernel config: https://syzkaller.appspot.com/x/.config?x=10283c2b00ab4cd7 dashboard link: https://syzkaller.appspot.com/bug?extid=5fa07e4e18e4eb1ccb12 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1299684160 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5fa07e4e18e4eb1cc...@syzkaller.appspotmail.com WARNING: CPU: 0 PID: 10315 at kernel/locking/lockdep.c:840 look_up_lock_class kernel/locking/lockdep.c:840 [inline] WARNING: CPU: 0 PID: 10315 at kernel/locking/lockdep.c:840 register_lock_class+0x206/0x1850 kernel/locking/lockdep.c:1185 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 10315 Comm: syz-executor.0 Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 panic+0x2dc/0x755 kernel/panic.c:219 __warn.cold+0x20/0x4c kernel/panic.c:576 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028 RIP: 0010:look_up_lock_class kernel/locking/lockdep.c:840 [inline] RIP: 0010:register_lock_class+0x206/0x1850 kernel/locking/lockdep.c:1185 Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 aa 10 00 00 4c 3b 7b 18 44 8b 35 d5 de 55 09 74 0b 48 81 3b a0 65 06 8a 74 02 <0f> 0b 45 85 ed 0f 84 71 03 00 00 f6 85 70 ff ff ff 01 0f 85 64 03 RSP: 0018:888096777a48 EFLAGS: 00010002 RAX: dc00 RBX: 888093ff78e0 RCX: RDX: 1110127fef1f RSI: RDI: 888093ff78f8 RBP: 888096777b10 R08: 111012ceef51 R09: 8aaea0e0 R10: 8a7753c8 R11: R12: 8a7b5d20 R13: R14: R15: 884766e0 __lock_acquire+0xf4/0x4e70 kernel/locking/lockdep.c:3837 lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x33/0x50 kernel/locking/spinlock.c:175 spin_lock_bh include/linux/spinlock.h:343 [inline] lock_sock_nested+0x41/0x120 net/core/sock.c:2929 lock_sock include/net/sock.h:1522 [inline] selinux_netlbl_socket_connect+0x20/0xc0 security/selinux/netlabel.c:607 selinux_socket_connect+0x6a/0x90 security/selinux/hooks.c:4745 security_socket_connect+0x77/0xc0 security/security.c:1958 __sys_connect+0x19d/0x330 net/socket.c:1824 __do_sys_connect net/socket.c:1839 [inline] __se_sys_connect net/socket.c:1836 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:1836 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459a09 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc302ec5c78 EFLAGS: 0246 ORIG_RAX: 002a RAX: ffda RBX: 0003 RCX: 00459a09 RDX: 001c RSI: 2080 RDI: 0005 RBP: 0075bf20 R08: R09: R10: R11: 0246 R12: 7fc302ec66d4 R13: 004bff42 R14: 004d1eb0 R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v7 8/9] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-updates/20190920-023813
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
:: branch date: 10 hours ago
:: commit date: 10 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/leds/leds-lp50xx.c:383:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5012_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:383:27: note: (near initialization for
'lp50xx_chip_info_tbl[0].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:392:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5012_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:392:27: note: (near initialization for
'lp50xx_chip_info_tbl[1].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:401:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5024_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:401:27: note: (near initialization for
'lp50xx_chip_info_tbl[2].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:410:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5024_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:410:27: note: (near initialization for
'lp50xx_chip_info_tbl[3].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:419:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5036_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:419:27: note: (near initialization for
'lp50xx_chip_info_tbl[4].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:428:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5036_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:428:27: note: (near initialization for
'lp50xx_chip_info_tbl[5].lp50xx_regmap_config')
#
https://github.com/0day-ci/linux/commit/20af6fb696d0e121b6d3cdcb1aabece15fd070ec
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 20af6fb696d0e121b6d3cdcb1aabece15fd070ec
vim +383 drivers/leds/leds-lp50xx.c
20af6fb696d0e1 Dan Murphy 2019-09-19 374
20af6fb696d0e1 Dan Murphy 2019-09-19 375 static const struct lp50xx_chip_info
lp50xx_chip_info_tbl[] = {
20af6fb696d0e1 Dan Murphy 2019-09-19 376 [LP5009] = {
20af6fb696d0e1 Dan Murphy 2019-09-19 377 .num_leds =
LP5009_MAX_LED_MODULES,
20af6fb696d0e1 Dan Murphy 2019-09-19 378 .led_brightness0_reg =
LP5012_LED0_BRT,
20af6fb696d0e1 Dan Murphy 2019-09-19 379 .mix_out0_reg =
LP5012_OUT0_CLR,
20af6fb696d0e1 Dan Murphy 2019-09-19 380 .bank_brt_reg =
LP5012_BNK_BRT,
20af6fb696d0e1 Dan Murphy 2019-09-19 381 .bank_mix_reg =
LP5012_BNKA_CLR,
20af6fb696d0e1 Dan Murphy 2019-09-19 382 .reset_reg =
LP5012_RESET,
20af6fb696d0e1 Dan Murphy 2019-09-19 @383 .lp50xx_regmap_config =
lp5012_regmap_config,
20af6fb696d0e1 Dan Murphy 2019-09-19 384 },
20af6fb696d0e1 Dan Murphy 2019-09-19 385 [LP5012] = {
20af6fb696d0e1 Dan Murphy 2019-09-19 386 .num_leds =
LP5012_MAX_LED_MODULES,
20af6fb696d0e1 Dan Murphy 2019-09-19 387 .led_brightness0_reg =
LP5012_LED0_BRT,
20af6fb696d0e1 Dan Murphy 2019-09-19 388 .mix_out0_reg =
LP5012_OUT0_CLR,
20af6fb696d0e1 Dan Murphy 2019-09-19 389 .bank_brt_reg =
LP5012_BNK_BRT,
20af6fb696d0e1 Dan Murphy 2019-09-19 390 .bank_mix_reg =
LP5012_BNKA_CLR,
20af6fb696d0e1 Dan Murphy 2019-09-19 391 .reset_reg =
LP5012_RESET,
20af6fb696d0e1 Dan Murphy 2019-09-19 392 .lp50xx_regmap_config =
lp5012_regmap_config,
20af6fb696d0e1 Dan Murphy 2019-09-19 393 },
20af6fb696d0e1 Dan Murphy 2019-09-19 394 [LP5018] = {
20af6fb696d0e1 Dan Murphy 2019-09-19 395 .num_leds =
LP5018_MAX_LED_MODULES,
20af6fb696d0e1 Dan Murphy 2019-09-19 396 .led_brightness0_reg =
LP5024_LED0_BRT,
20af6fb696d0e1 Dan Murphy 2019-09-19 397 .mix_out0_reg =
LP5024_OUT0_CLR,
20af6fb696d0e1 Dan Murphy 2019-09-19 398
Re: [PATCH v7 9/9] leds: Update the lp55xx to use the multi color framework
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-updates/20190920-023813
config: i386-randconfig-b003-201937 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
:: branch date: 4 hours ago
:: commit date: 4 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_set_brightness':
>> drivers/leds/leds-lp55xx-common.c:144: undefined reference to
>> `led_mc_calc_brightness'
ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_init_led':
>> drivers/leds/leds-lp55xx-common.c:216: undefined reference to
>> `led_classdev_multicolor_register_ext'
#
https://github.com/0day-ci/linux/commit/d907bc23f70b4ca46747f42ec24a2066fa4602b0
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout d907bc23f70b4ca46747f42ec24a2066fa4602b0
vim +144 drivers/leds/leds-lp55xx-common.c
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 133)
95b2af637e283e Andrew Lunn 2015-08-20 134 static int
lp55xx_set_brightness(struct led_classdev *cdev,
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 135)
enum led_brightness brightness)
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 136) {
a6e4679a09a0a2 Milo(Woogyom Kim 2013-02-05 137) struct lp55xx_led *led
= cdev_to_lp55xx_led(cdev);
95b2af637e283e Andrew Lunn 2015-08-20 138struct
lp55xx_device_config *cfg = led->chip->cfg;
d907bc23f70b4c Dan Murphy2019-09-19 139int
adj_value[LED_COLOR_ID_MAX];
d907bc23f70b4c Dan Murphy2019-09-19 140int ret;
d907bc23f70b4c Dan Murphy2019-09-19 141int i;
a6e4679a09a0a2 Milo(Woogyom Kim 2013-02-05 142)
d907bc23f70b4c Dan Murphy2019-09-19 143if
(led->mc_cdev.num_leds > 1) {
d907bc23f70b4c Dan Murphy2019-09-19 @144
led_mc_calc_brightness(>mc_cdev,
d907bc23f70b4c Dan Murphy2019-09-19 145
brightness, adj_value);
d907bc23f70b4c Dan Murphy2019-09-19 146for (i = 0; i <
led->mc_cdev.num_leds; i++) {
d907bc23f70b4c Dan Murphy2019-09-19 147
led->brightness = adj_value[i];
d907bc23f70b4c Dan Murphy2019-09-19 148ret =
cfg->color_intensity_fn(led,
d907bc23f70b4c Dan Murphy2019-09-19 149
led->grouped_channels[i]);
d907bc23f70b4c Dan Murphy2019-09-19 150if (ret)
d907bc23f70b4c Dan Murphy2019-09-19 151
break;
d907bc23f70b4c Dan Murphy2019-09-19 152}
d907bc23f70b4c Dan Murphy2019-09-19 153} else {
a6e4679a09a0a2 Milo(Woogyom Kim 2013-02-05 154) led->brightness
= (u8)brightness;
d907bc23f70b4c Dan Murphy2019-09-19 155ret =
cfg->brightness_fn(led);
d907bc23f70b4c Dan Murphy2019-09-19 156}
d907bc23f70b4c Dan Murphy2019-09-19 157
d907bc23f70b4c Dan Murphy2019-09-19 158return ret;
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 159) }
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 160)
9e9b3db1b2f725 Milo(Woogyom Kim 2013-02-05 161) static int
lp55xx_init_led(struct lp55xx_led *led,
9e9b3db1b2f725 Milo(Woogyom Kim 2013-02-05 162) struct
lp55xx_chip *chip, int chan)
9e9b3db1b2f725 Milo(Woogyom Kim 2013-02-05 163) {
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 164) struct
lp55xx_platform_data *pdata = chip->pdata;
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 165) struct
lp55xx_device_config *cfg = chip->cfg;
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 166) struct device *dev =
>cl->dev;
d907bc23f70b4c Dan Murphy2019-09-19 167int max_channel =
cfg->max_channel;
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 168) char name[32];
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 169) int ret;
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 170)
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 171) if (chan >=
max_channel) {
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 172) dev_err(dev,
"invalid channel: %d / %d\n", chan, max_channel);
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05 173) return -EINVAL;
0e2023463a3c94 Milo(Woogyom Kim 2013-02-05
Re: [PATCH] jffs2:freely allocate memory when parameters are invalid
Tao, - Ursprüngliche Mail - > Von: "Hou Tao" > In Huawei we use jffs2 broadly in our products to support filesystem on raw > NOR flash and NAND flash, so fixing the bugs in jffs2 means a lot to us. > > Although I have not read all of jffs2 code thoroughly, I had find and "fixed" > some bugs in jffs2 and I am willing to do any help in the jffs2 community. > Maybe > we can start by testing and reviewing the pending patches in patch work ? yes, this is a good idea. In MTD's patchwork the jffs2 queue is in bad shape. I tried to catch up but failed to find enough time. So with more eyeballs I think we can bring it in shape again. Basically we need to classify which patches fix important stuff and which do not. Some time ago I make xfstests work with jffs2, I can share (and upstream) these patches too. One of my goals is making sure that we don't break jffs2. xfstests can help. Are you on the OFTC IRC network? On #mtd you can find us MTD guys. Thanks, //richard
Re: [PATCH v7 9/9] leds: Update the lp55xx to use the multi color framework
Hi Dan, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3 next-20190919] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-updates/20190920-023813 config: i386-randconfig-b002-201937 (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 :: branch date: 3 hours ago :: commit date: 3 hours ago If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "led_classdev_multicolor_register_ext" >> [drivers/leds/leds-lp55xx-common.ko] undefined! >> ERROR: "led_mc_calc_brightness" [drivers/leds/leds-lp55xx-common.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: .config.gz
Re: [PATCH v8 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote: > When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there > will be a double page fault in __copy_from_user_inatomic of cow_user_page. > > Below call trace is from arm64 do_page_fault for debugging purpose > [ 110.016195] Call trace: > [ 110.016826] do_page_fault+0x5a4/0x690 > [ 110.017812] do_mem_abort+0x50/0xb0 > [ 110.018726] el1_da+0x20/0xc4 > [ 110.019492] __arch_copy_from_user+0x180/0x280 > [ 110.020646] do_wp_page+0xb0/0x860 > [ 110.021517] __handle_mm_fault+0x994/0x1338 > [ 110.022606] handle_mm_fault+0xe8/0x180 > [ 110.023584] do_page_fault+0x240/0x690 > [ 110.024535] do_mem_abort+0x50/0xb0 > [ 110.025423] el0_da+0x20/0x24 > > The pte info before __copy_from_user_inatomic is (PTE_AF is cleared): > [9b007000] pgd=00023d4f8003, pud=00023da9b003, > pmd=00023d4b3003, pte=36298607bd3 > > As told by Catalin: "On arm64 without hardware Access Flag, copying from > user will fail because the pte is old and cannot be marked young. So we > always end up with zeroed page after fork() + CoW for pfn mappings. we > don't always have a hardware-managed access flag on arm64." > > This patch fix it by calling pte_mkyoung. Also, the parameter is > changed because vmf should be passed to cow_user_page() > > Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error > in case there can be some obscure use-case.(by Kirill) > > [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork > > Reported-by: Yibo Cai > Signed-off-by: Jia He Reviewed-by: Matthew Wilcox (Oracle)
Re: [PATCH v3 1/2] edac: Add an API for edac device to report for multiple errors
Hi Hanna, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3 next-20190919] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Hanna-Hawa/Add-an-API-for-edac-device-for-mulriple-errors/20190920-012316 reproduce: make htmldocs :: branch date: 2 hours ago :: commit date: 2 hours ago If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quotactl' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quota_on' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_free_mnt_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_eat_lsm_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_kern_mount' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_show_options' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_add_mnt_opt' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'd_instantiate' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'getprocattr' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'setprocattr' not described in 'security_list_options' >> drivers/edac/edac_device.h:332: warning: Function parameter or member >> 'count' not described in '__edac_device_handle_ue' drivers/edac/edac_device.h:332: warning: Excess function parameter 'error_count' description in '__edac_device_handle_ue' >> drivers/edac/edac_device.h:345: warning: Function parameter or member >> 'count' not described in '__edac_device_handle_ce' drivers/edac/edac_device.h:345: warning: Excess function parameter 'error_count' description in '__edac_device_handle_ce' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' fs/fs-writeback.c:913: warning: Excess function parameter 'nr_pages' description in 'cgroup_writeback_by_id' fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found include/linux/w1.h:277: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/skbuff.h:888: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning:
[PATCH 5/6] ARM: dts: meson8: add the DDR clock controller
Add the DDR clock controller and pass it's DDR_CLKID_DDR_PLL to the main
(HHI) clock controller as "ddr_clk". The "ddr_clk" is used as one of the
inputs for the audio clock muxes.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8.dtsi | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 4f59a4c8f036..257c1364864c 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -3,6 +3,7 @@
* Copyright 2014 Carlo Caione
*/
+#include
#include
#include
#include
@@ -195,6 +196,14 @@
#size-cells = <1>;
ranges = <0x0 0xc800 0x8000>;
+ ddr_clkc: clock-controller@400 {
+ compatible = "amlogic,meson8-ddr-clkc";
+ reg = <0x400 0x20>;
+ clocks = <>;
+ clock-names = "xtal";
+ #clock-cells = <1>;
+ };
+
dmcbus: bus@6000 {
compatible = "simple-bus";
reg = <0x6000 0x400>;
@@ -455,8 +464,8 @@
{
clkc: clock-controller {
compatible = "amlogic,meson8-clkc";
- clocks = <>;
- clock-names = "xtal";
+ clocks = <>, <_clkc DDR_CLKID_DDR_PLL>;
+ clock-names = "xtal", "ddr_pll";
#clock-cells = <1>;
#reset-cells = <1>;
};
--
2.23.0
[PATCH 6/6] ARM: dts: meson8b: add the DDR clock controller
Add the DDR clock controller and pass it's DDR_CLKID_DDR_PLL to the main
(HHI) clock controller as "ddr_clk". The "ddr_clk" is used as one of the
inputs for the audio clock muxes.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b.dtsi | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 1934666ff60f..8ac8bdfaf58f 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -4,6 +4,7 @@
* Author: Carlo Caione
*/
+#include
#include
#include
#include
@@ -172,6 +173,14 @@
#size-cells = <1>;
ranges = <0x0 0xc800 0x8000>;
+ ddr_clkc: clock-controller@400 {
+ compatible = "amlogic,meson8b-ddr-clkc";
+ reg = <0x400 0x20>;
+ clocks = <>;
+ clock-names = "xtal";
+ #clock-cells = <1>;
+ };
+
dmcbus: bus@6000 {
compatible = "simple-bus";
reg = <0x6000 0x400>;
@@ -434,8 +443,8 @@
{
clkc: clock-controller {
compatible = "amlogic,meson8-clkc";
- clocks = <>;
- clock-names = "xtal";
+ clocks = <>, <_clkc DDR_CLKID_DDR_PLL>;
+ clock-names = "xtal", "ddr_pll";
#clock-cells = <1>;
#reset-cells = <1>;
};
--
2.23.0
[PATCH 3/6] clk: meson: meson8b: use of_clk_hw_register to register the clocks
Switch from clk_hw_register to of_clk_hw_register so we can use clk_parent_data.fw_name. This will be used to get the "xtal", "ddr_pll" and possibly others from the .dtb. Signed-off-by: Martin Blumenstingl --- drivers/clk/meson/meson8b.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c index 15ec14fde2a0..fefb4b7185d0 100644 --- a/drivers/clk/meson/meson8b.c +++ b/drivers/clk/meson/meson8b.c @@ -3696,7 +3696,7 @@ static void __init meson8b_clkc_init_common(struct device_node *np, if (!clk_hw_onecell_data->hws[i]) continue; - ret = clk_hw_register(NULL, clk_hw_onecell_data->hws[i]); + ret = of_clk_hw_register(np, clk_hw_onecell_data->hws[i]); if (ret) return; } -- 2.23.0
[PATCH 1/6] dt-bindings: clock: add the Amlogic Meson8 DDR clock controller binding
Amlogic Meson8, Meson8b and Meson8m2 SoCs have a DDR clock controller in
the MMCBUS registers. There is no public documentation on this, but the
GPL u-boot sources from the Amlogic BSP show that:
- it uses the same XTAL input as the main clock controller
- it contains a PLL which seems to be implemented just like the other
PLLs in this SoC
- there is a power-of-two PLL post-divider
Add the documentation and header file for this DDR clock controller.
Signed-off-by: Martin Blumenstingl
---
.../clock/amlogic,meson8-ddr-clkc.yaml| 50 +++
include/dt-bindings/clock/meson8-ddr-clkc.h | 4 ++
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
create mode 100644 include/dt-bindings/clock/meson8-ddr-clkc.h
diff --git
a/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
b/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
new file mode 100644
index ..bf3ca5888485
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,meson8-ddr-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic DDR Clock Controller Device Tree Bindings
+
+maintainers:
+ - Martin Blumenstingl
+
+properties:
+ compatible:
+enum:
+ - amlogic,meson8-ddr-clkc
+ - amlogic,meson8b-ddr-clkc
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: xtal
+
+ "#clock-cells":
+const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ddr_clkc: clock-controller@400 {
+ compatible = "amlogic,meson8-ddr-clkc";
+ reg = <0x400 0x20>;
+ clocks = <>;
+ clock-names = "xtal";
+ #clock-cells = <1>;
+};
+
+...
diff --git a/include/dt-bindings/clock/meson8-ddr-clkc.h
b/include/dt-bindings/clock/meson8-ddr-clkc.h
new file mode 100644
index ..a8e0fa2987ab
--- /dev/null
+++ b/include/dt-bindings/clock/meson8-ddr-clkc.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#define DDR_CLKID_DDR_PLL_DCO 0
+#define DDR_CLKID_DDR_PLL 1
--
2.23.0
[PATCH 2/6] clk: meson: add a driver for the Meson8/8b/8m2 DDR clock controller
The Meson8/Meson8b/Meson8m2 SoCs embed a DDR clock controller in the
MMCBUS registers. There is no public documentation, but the u-boot GPL
sources from the Amlogic BSP show that the DDR clock controller is
identical on all three SoCs:
#define CFG_DDR_CLK 792
#define CFG_PLL_M (((CFG_DDR_CLK/12)*12)/24)
#define CFG_PLL_N 1
#define CFG_PLL_OD 1
// from set_ddr_clock:
t_ddr_pll_cntl= (CFG_PLL_OD << 16)|(CFG_PLL_N<<9)|(CFG_PLL_M<<0)
writel(timing_reg->t_ddr_pll_cntl|(1<<29),AM_DDR_PLL_CNTL);
writel(readl(AM_DDR_PLL_CNTL) & (~(1<<29)),AM_DDR_PLL_CNTL);
// from hx_ddr_power_down_enter: shut down DDR PLL
writel(readl(AM_DDR_PLL_CNTL)|(1<<30),AM_DDR_PLL_CNTL);
do { ... } while((readl(AM_DDR_PLL_CNTL)&(1<<31))==0)
This translates to:
- AM_DDR_PLL_CNTL[29] is the reset bit
- AM_DDR_PLL_CNTL[30] is the enable bit
- AM_DDR_PLL_CNTL[31] is the lock bit
- AM_DDR_PLL_CNTL[8:0] is the m value (assuming the width is 9 bits
based on the start of the n value)
- AM_DDR_PLL_CNTL[13:9] is the n value (assuming the width is 5 bits
based on the start of the od)
- AM_DDR_PLL_CNTL[17:16] is the od (assuming the width is 2 bits based
on other PLLs on this SoC)
Add a driver for this PLL setup because it's used as one of the inputs
of the audio clocks. There may be more clocks inside that clock
controller - those can be added in subsequent patches.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/Makefile | 2 +-
drivers/clk/meson/meson8-ddr.c | 153 +
2 files changed, 154 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/meson/meson8-ddr.c
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 3939f218587a..6eca2a406ee3 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -18,4 +18,4 @@ obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
obj-$(CONFIG_COMMON_CLK_G12A) += g12a.o g12a-aoclk.o
-obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
+obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o meson8-ddr.o
diff --git a/drivers/clk/meson/meson8-ddr.c b/drivers/clk/meson/meson8-ddr.c
new file mode 100644
index ..64ab4c27cce0
--- /dev/null
+++ b/drivers/clk/meson/meson8-ddr.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Amlogic Meson8 DDR clock controller
+ *
+ * Copyright (C) 2019 Martin Blumenstingl
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include "clk-regmap.h"
+#include "clk-pll.h"
+
+#define AM_DDR_PLL_CNTL0x00
+#define AM_DDR_PLL_CNTL1 0x04
+#define AM_DDR_PLL_CNTL2 0x08
+#define AM_DDR_PLL_CNTL3 0x0c
+#define AM_DDR_PLL_CNTL4 0x10
+#define AM_DDR_PLL_STS 0x14
+#define DDR_CLK_CNTL 0x18
+#define DDR_CLK_STS0x1c
+
+static struct clk_regmap meson8_ddr_pll_dco = {
+ .data = &(struct meson_clk_pll_data){
+ .en = {
+ .reg_off = AM_DDR_PLL_CNTL,
+ .shift = 30,
+ .width = 1,
+ },
+ .m = {
+ .reg_off = AM_DDR_PLL_CNTL,
+ .shift = 0,
+ .width = 9,
+ },
+ .n = {
+ .reg_off = AM_DDR_PLL_CNTL,
+ .shift = 9,
+ .width = 5,
+ },
+ .l = {
+ .reg_off = AM_DDR_PLL_CNTL,
+ .shift = 31,
+ .width = 1,
+ },
+ .rst = {
+ .reg_off = AM_DDR_PLL_CNTL,
+ .shift = 29,
+ .width = 1,
+ },
+ },
+ .hw.init = &(struct clk_init_data){
+ .name = "ddr_pll_dco",
+ .ops = _clk_pll_ro_ops,
+ .parent_data = &(const struct clk_parent_data) {
+ .fw_name = "xtal",
+ },
+ .num_parents = 1,
+ },
+};
+
+static struct clk_regmap meson8_ddr_pll = {
+ .data = &(struct clk_regmap_div_data){
+ .offset = AM_DDR_PLL_CNTL,
+ .shift = 16,
+ .width = 2,
+ .flags = CLK_DIVIDER_POWER_OF_TWO,
+ },
+ .hw.init = &(struct clk_init_data){
+ .name = "ddr_pll",
+ .ops = _regmap_divider_ro_ops,
+ .parent_hws = (const struct clk_hw *[]) {
+ _ddr_pll_dco.hw
+ },
+ .num_parents = 1,
+ },
+};
+
+static struct clk_hw_onecell_data meson8_ddr_clk_hw_onecell_data = {
+ .hws = {
+ [DDR_CLKID_DDR_PLL_DCO] = _ddr_pll_dco.hw,
+ [DDR_CLKID_DDR_PLL] = _ddr_pll.hw,
+ },
+
[PATCH 0/6] add the DDR clock controller on Meson8 and Meson8b
Meson8 and Meson8b SoCs embed a DDR clock controller in their MMCBUS registers. This series: - adds support for this DDR clock controller (patches 0 and 1) - wires up the DDR PLL as input for two audio clocks (patches 2 and 3) - adds the DDR clock controller to meson8.dtsi and meson8b.dtsi Special thanks go out to Alexandre Mergnat for switching the Amlogic clock drivers over to parent_hws and parent_data. That made this series a lot easier for me! This series depends on my other series from [0]: "provide the XTAL clock via OF on Meson8/8b/8m2" [0] https://patchwork.kernel.org/cover/11155515/ Martin Blumenstingl (6): dt-bindings: clock: add the Amlogic Meson8 DDR clock controller binding clk: meson: add a driver for the Meson8/8b/8m2 DDR clock controller clk: meson: meson8b: use of_clk_hw_register to register the clocks clk: meson: meson8b: add the ddr_pll input for the audio clocks ARM: dts: meson8: add the DDR clock controller ARM: dts: meson8b: add the DDR clock controller .../clock/amlogic,meson8-ddr-clkc.yaml| 50 ++ arch/arm/boot/dts/meson8.dtsi | 13 +- arch/arm/boot/dts/meson8b.dtsi| 13 +- drivers/clk/meson/Makefile| 2 +- drivers/clk/meson/meson8-ddr.c| 153 ++ drivers/clk/meson/meson8b.c | 36 ++--- include/dt-bindings/clock/meson8-ddr-clkc.h | 4 + 7 files changed, 245 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml create mode 100644 drivers/clk/meson/meson8-ddr.c create mode 100644 include/dt-bindings/clock/meson8-ddr-clkc.h -- 2.23.0
[PATCH 4/6] clk: meson: meson8b: add the ddr_pll input for the audio clocks
The two audio muxes cts_amclk_sel and cts_mclk_i958_sel use ddr_pll as
input at index 0. Update the muxes to use clk_parent_data and add
"ddr_pll" as input using clk_parent_data.fw_name because the DDR clock
controller is actually separate from the main clock controller.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index fefb4b7185d0..3987f4ea7378 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -2429,28 +2429,25 @@ static struct clk_regmap meson8b_vdec_hevc = {
},
};
-/* TODO: the clock at index 0 is "DDR_PLL" which we don't support yet */
-static const struct clk_hw *meson8b_cts_amclk_parent_hws[] = {
- _mpll0.hw,
- _mpll1.hw,
- _mpll2.hw
+static const struct clk_parent_data meson8b_cts_amclk_parent_data[] = {
+ { .fw_name = "ddr_pll", },
+ { .hw = _mpll0.hw, },
+ { .hw = _mpll1.hw, },
+ { .hw = _mpll2.hw, },
};
-static u32 meson8b_cts_amclk_mux_table[] = { 1, 2, 3 };
-
static struct clk_regmap meson8b_cts_amclk_sel = {
.data = &(struct clk_regmap_mux_data){
.offset = HHI_AUD_CLK_CNTL,
.mask = 0x3,
.shift = 9,
- .table = meson8b_cts_amclk_mux_table,
.flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cts_amclk_sel",
.ops = _regmap_mux_ops,
- .parent_hws = meson8b_cts_amclk_parent_hws,
- .num_parents = ARRAY_SIZE(meson8b_cts_amclk_parent_hws),
+ .parent_data = meson8b_cts_amclk_parent_data,
+ .num_parents = ARRAY_SIZE(meson8b_cts_amclk_parent_data),
},
};
@@ -2488,28 +2485,25 @@ static struct clk_regmap meson8b_cts_amclk = {
},
};
-/* TODO: the clock at index 0 is "DDR_PLL" which we don't support yet */
-static const struct clk_hw *meson8b_cts_mclk_i958_parent_hws[] = {
- _mpll0.hw,
- _mpll1.hw,
- _mpll2.hw
+static const struct clk_parent_data meson8b_cts_mclk_i958_parent_data[] = {
+ { .fw_name = "ddr_pll", },
+ { .hw = _mpll0.hw, },
+ { .hw = _mpll1.hw, },
+ { .hw = _mpll2.hw, },
};
-static u32 meson8b_cts_mclk_i958_mux_table[] = { 1, 2, 3 };
-
static struct clk_regmap meson8b_cts_mclk_i958_sel = {
.data = &(struct clk_regmap_mux_data){
.offset = HHI_AUD_CLK_CNTL2,
.mask = 0x3,
.shift = 25,
- .table = meson8b_cts_mclk_i958_mux_table,
.flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data) {
.name = "cts_mclk_i958_sel",
.ops = _regmap_mux_ops,
- .parent_hws = meson8b_cts_mclk_i958_parent_hws,
- .num_parents = ARRAY_SIZE(meson8b_cts_mclk_i958_parent_hws),
+ .parent_data = meson8b_cts_mclk_i958_parent_data,
+ .num_parents = ARRAY_SIZE(meson8b_cts_mclk_i958_parent_data),
},
};
--
2.23.0
Re: [PATCH v8 7/9] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
> Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
> LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
> can control RGB LEDs individually or as part of a control bank group.
> These devices have the ability to adjust the mixing control for the RGB
> LEDs to obtain different colors independent of the overall brightness of
> the LED grouping.
>
> Datasheet:
> http://www.ti.com/lit/ds/symlink/lp5012.pdf
> http://www.ti.com/lit/ds/symlink/lp5024.pdf
> http://www.ti.com/lit/ds/symlink/lp5036.pdf
>
> Signed-off-by: Dan Murphy
> ---
> .../devicetree/bindings/leds/leds-lp50xx.txt | 148 ++
> 1 file changed, 148 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.txt
> b/Documentation/devicetree/bindings/leds/leds-lp50xx.txt
> new file mode 100644
> index ..9d05f43042e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.txt
> @@ -0,0 +1,148 @@
> +* Texas Instruments - LP5009/12/18/24/30/36 RGB LED driver
> +
> +The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
> +a LED group or control them individually.
> +
> +The difference in these RGB LED drivers is the number of supported RGB
> modules.
> +
> +Required parent properties:
> + - compatible:
> + "ti,lp5009"
> + "ti,lp5012"
> + "ti,lp5018"
> + "ti,lp5024"
> + "ti,lp5030"
> + "ti,lp5036"
> + - reg : I2C slave address
> + lp5009/12 - 0x28
> + lp5018/24 - 0x28
> + lp5030/36 - 0x30
> + - #address-cells : 1
> + - #size-cells : 0
> +
> +Optional parent properties:
> + - enable-gpios : gpio pin to enable/disable the device.
> + - vled-supply : LED supply
> +
> +Required child properties:
> + - #address-cells : 1
> + - #size-cells : 0
> + - reg : This is the LED module number.
> + - color : see Documentation/devicetree/bindings/leds/common.txt
> + - function : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Required child properties only is LED modules will be banked:
> + - ti,led-bank : This property denotes the LED module numbers that will
> + be controlled as a single RGB cluster. Each LED module
> + number will be controlled by a single LED class
> instance.
> + There can only be one instance of the ti,led-bank
> + property for each device node.
> +
> +Required grandchildren properties:
> + - reg : A single entry denoting the LED module that controls
> + the RGB cluster.
> + - color : see Documentation/devicetree/bindings/leds/leds-multicolor.txt
> + - led-sources : see Documentation/devicetree/bindings/leds/common.txt
> +
> +The LED outputs associated with the LED modules are defined in Table 1 of the
> +corresponding data sheets.
We must enclose this information here.
> +
> +LP5009 - 2 Total RGB cluster LED outputs 0-1
> +LP5012 - 4 Total RGB cluster LED outputs 0-3
> +LP5018 - 6 Total RGB cluster LED outputs 0-5
> +LP5024 - 8 Total RGB cluster LED outputs 0-7
> +LP5030 - 10 Total RGB cluster LED outputs 0-9
> +LP5036 - 12 Total RGB cluster LED outputs 0-11
> +
> +Optional child properties:
> + - label : see Documentation/devicetree/bindings/leds/common.txt
> + - linux,default-trigger :
> +see Documentation/devicetree/bindings/leds/common.txt
> +
> +Examples:
> +led-controller@29 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "ti,lp5024";
> + reg = <0x29>;
> + enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
> + vled-supply = <_fixed>;
> +
> + multi-led@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + color = ;
> + function = LED_FUNCTION_STATUS;
> +
> + led@3 {
> + reg = <3>;
> + color = ;
> + };
> +
> + led@4 {
> + reg = <4>;
> + color = ;
> + };
> +
> + led@5 {
> + reg = <5>;
> + color = ;
> + };
> + };
> +
> + multi-led@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> + color = ;
> + function = LED_FUNCTION_STANDBY;
> + ti,led-bank = <2 3 5>;
> +
> + led@6 {
> + reg = <0x6>;
> + color = ;
> + led-sources = <6 9 15>;
> + };
> +
> + led@7 {
> + reg = <0x7>;
> + color = ;
> + led-sources = <7 10 16>;
> + };
> +
> +
Re: [PATCH 5/5] lib/math: remove int_pow()
Hi Rasmus,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Rasmus-Villemoes/backlight-pwm_bl-fix-cie1913-comments-and-constant/20190919-225123
config: x86_64-randconfig-s0-201937 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
:: branch date: 2 hours ago
:: commit date: 2 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/iio/common/hid-sensors/hid-sensor-attributes.c: In function
'simple_div':
>> drivers/iio/common/hid-sensors/hid-sensor-attributes.c:94:35: error:
>> implicit declaration of function 'int_pow'
>> [-Werror=implicit-function-declaration]
*micro_frac = (rem / divisor) * int_pow(10, 6 - exp);
^
Cyclomatic Complexity 3
include/linux/hid-sensor-hub.h:hid_sensor_convert_exponent
Cyclomatic Complexity 1
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_convert_timestamp
Cyclomatic Complexity 3
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_batch_mode_supported
Cyclomatic Complexity 4
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_read_poll_value
Cyclomatic Complexity 2
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_get_report_latency
Cyclomatic Complexity 4
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:simple_div
Cyclomatic Complexity 5
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_read_samp_freq_value
Cyclomatic Complexity 1
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:split_micro_fraction
Cyclomatic Complexity 4
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:convert_from_vtf_format
Cyclomatic Complexity 3
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_read_raw_hyst_value
Cyclomatic Complexity 4
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:convert_to_vtf_format
Cyclomatic Complexity 7
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:adjust_exponent_nano
Cyclomatic Complexity 4
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_format_scale
Cyclomatic Complexity 9
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_write_samp_freq_value
Cyclomatic Complexity 6
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_write_raw_hyst_value
Cyclomatic Complexity 1
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_set_report_latency
Cyclomatic Complexity 2
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_get_reporting_interval
Cyclomatic Complexity 2
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_get_report_latency_info
Cyclomatic Complexity 6
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:hid_sensor_parse_common_attributes
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/d89cf2c7a3840d1691169c9e099c7def0dc16c46
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout d89cf2c7a3840d1691169c9e099c7def0dc16c46
vim +/int_pow +94 drivers/iio/common/hid-sensors/hid-sensor-attributes.c
5d02edfc395744 Srinivas Pandruvada 2014-04-19 75
73c6768b710a16 srinivas pandruvada 2012-09-05 76 static void simple_div(int
dividend, int divisor, int *whole,
73c6768b710a16 srinivas pandruvada 2012-09-05 77
int *micro_frac)
73c6768b710a16 srinivas pandruvada 2012-09-05 78 {
73c6768b710a16 srinivas pandruvada 2012-09-05 79 int rem;
73c6768b710a16 srinivas pandruvada 2012-09-05 80 int exp = 0;
73c6768b710a16 srinivas pandruvada 2012-09-05 81
73c6768b710a16 srinivas pandruvada 2012-09-05 82 *micro_frac = 0;
73c6768b710a16 srinivas pandruvada 2012-09-05 83 if (divisor == 0) {
73c6768b710a16 srinivas pandruvada 2012-09-05 84 *whole = 0;
73c6768b710a16 srinivas pandruvada 2012-09-05 85 return;
73c6768b710a16 srinivas pandruvada 2012-09-05 86 }
73c6768b710a16 srinivas pandruvada 2012-09-05 87 *whole =
dividend/divisor;
73c6768b710a16 srinivas pandruvada 2012-09-05 88 rem = dividend %
divisor;
73c6768b710a16 srinivas pandruvada 2012-09-05 89 if (rem) {
73c6768b710a16 srinivas pandruvada 2012-09-05 90 while (rem <=
divisor) {
73c6768b710a16 srinivas pandruvada 2012-09-05 91 rem *=
10;
73c6768b710a16 srinivas pandruvada
[PATCH 3/5] clk: meson: meson8b: change references to the XTAL clock to use the name
The XTAL clock is an actual crystal which is mounted on the PCB. Thus
the meson8b clock controller driver should not provide the XTAL clock.
The meson8b clock controller driver must not use references to
the meson8b_xtal clock anymore before we can provide the XTAL clock
via OF. Replace the references to the meson8b_xtal.hw by using
clk_parent_data.name = "xtal" (along with index = -1) because this works
regardless how the XTAL clock is registered (either as fixed-clock in
the .dtb or - if missing - when registered in the meson8b clock
controller driver).
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 73 -
1 file changed, 39 insertions(+), 34 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index d376f80e806d..b785b67baf2b 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -97,8 +97,9 @@ static struct clk_regmap meson8b_fixed_pll_dco = {
.hw.init = &(struct clk_init_data){
.name = "fixed_pll_dco",
.ops = _clk_pll_ro_ops,
- .parent_hws = (const struct clk_hw *[]) {
- _xtal.hw
+ .parent_data = &(const struct clk_parent_data) {
+ .name = "xtal",
+ .index = -1,
},
.num_parents = 1,
},
@@ -162,8 +163,9 @@ static struct clk_regmap meson8b_hdmi_pll_dco = {
/* sometimes also called "HPLL" or "HPLL PLL" */
.name = "hdmi_pll_dco",
.ops = _clk_pll_ro_ops,
- .parent_hws = (const struct clk_hw *[]) {
- _xtal.hw
+ .parent_data = &(const struct clk_parent_data) {
+ .name = "xtal",
+ .index = -1,
},
.num_parents = 1,
},
@@ -237,8 +239,9 @@ static struct clk_regmap meson8b_sys_pll_dco = {
.hw.init = &(struct clk_init_data){
.name = "sys_pll_dco",
.ops = _clk_pll_ops,
- .parent_hws = (const struct clk_hw *[]) {
- _xtal.hw
+ .parent_data = &(const struct clk_parent_data) {
+ .name = "xtal",
+ .index = -1,
},
.num_parents = 1,
},
@@ -631,9 +634,9 @@ static struct clk_regmap meson8b_cpu_in_sel = {
.hw.init = &(struct clk_init_data){
.name = "cpu_in_sel",
.ops = _regmap_mux_ops,
- .parent_hws = (const struct clk_hw *[]) {
- _xtal.hw,
- _sys_pll.hw,
+ .parent_data = (const struct clk_parent_data[]) {
+ { .name = "xtal", .index = -1, },
+ { .hw = _sys_pll.hw, },
},
.num_parents = 2,
.flags = (CLK_SET_RATE_PARENT |
@@ -736,9 +739,9 @@ static struct clk_regmap meson8b_cpu_clk = {
.hw.init = &(struct clk_init_data){
.name = "cpu_clk",
.ops = _regmap_mux_ops,
- .parent_hws = (const struct clk_hw *[]) {
- _xtal.hw,
- _cpu_scale_out_sel.hw,
+ .parent_data = (const struct clk_parent_data[]) {
+ { .name = "xtal", .index = -1, },
+ { .hw = _cpu_scale_out_sel.hw, },
},
.num_parents = 2,
.flags = (CLK_SET_RATE_PARENT |
@@ -758,12 +761,12 @@ static struct clk_regmap meson8b_nand_clk_sel = {
.name = "nand_clk_sel",
.ops = _regmap_mux_ops,
/* FIXME all other parents are unknown: */
- .parent_hws = (const struct clk_hw *[]) {
- _fclk_div4.hw,
- _fclk_div3.hw,
- _fclk_div5.hw,
- _fclk_div7.hw,
- _xtal.hw,
+ .parent_data = (const struct clk_parent_data[]) {
+ { .hw = _fclk_div4.hw, },
+ { .hw = _fclk_div3.hw, },
+ { .hw = _fclk_div5.hw, },
+ { .hw = _fclk_div7.hw, },
+ { .name = "xtal", .index = -1, },
},
.num_parents = 5,
.flags = CLK_SET_RATE_PARENT,
@@ -1721,8 +1724,9 @@ static struct clk_regmap meson8b_hdmi_sys_sel = {
.name = "hdmi_sys_sel",
.ops = _regmap_mux_ro_ops,
/* FIXME: all other parents are unknown */
- .parent_hws = (const struct clk_hw *[]) {
- _xtal.hw
+ .parent_data = &(const struct clk_parent_data) {
+ .name = "xtal",
+ .index = -1,
},
.num_parents = 1,
.flags
[PATCH 4/5] clk: meson: meson8b: don't register the XTAL clock when provided via OF
The XTAL clock is an actual crystal on the PCB. Thus the meson8b clock
driver should not register the XTAL clock - instead it should be
provided via .dts and then passed to the clock controller.
Skip the registration of the XTAL clock if a parent clock is provided
via OF. Fall back to registering the XTAL clock if this is not the case
to keep support for old .dtbs.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index b785b67baf2b..15ec14fde2a0 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -3682,10 +3682,16 @@ static void __init meson8b_clkc_init_common(struct
device_node *np,
meson8b_clk_regmaps[i]->map = map;
/*
-* register all clks
-* CLKID_UNUSED = 0, so skip it and start with CLKID_XTAL = 1
+* always skip CLKID_UNUSED and also skip XTAL if the .dtb provides the
+* XTAL clock as input.
*/
- for (i = CLKID_XTAL; i < CLK_NR_CLKS; i++) {
+ if (of_clk_get_parent_count(np))
+ i = CLKID_PLL_FIXED;
+ else
+ i = CLKID_XTAL;
+
+ /* register all clks */
+ for (; i < CLK_NR_CLKS; i++) {
/* array might be sparse */
if (!clk_hw_onecell_data->hws[i])
continue;
--
2.23.0
[PATCH 2/5] clk: meson: meson8b: use clk_hw_set_parent in the CPU clock notifier
Switch from clk_set_parent() to clk_hw_set_parent() now that we have a
way to configure a mux clock based on clk_hw pointers. This simplifies
the meson8b_cpu_clk_notifier_cb logic. No functional changes.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 67e6691e080c..d376f80e806d 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -3585,7 +3585,7 @@ static const struct reset_control_ops
meson8b_clk_reset_ops = {
struct meson8b_nb_data {
struct notifier_block nb;
- struct clk_hw_onecell_data *onecell_data;
+ struct clk_hw *cpu_clk;
};
static int meson8b_cpu_clk_notifier_cb(struct notifier_block *nb,
@@ -3593,30 +3593,25 @@ static int meson8b_cpu_clk_notifier_cb(struct
notifier_block *nb,
{
struct meson8b_nb_data *nb_data =
container_of(nb, struct meson8b_nb_data, nb);
- struct clk_hw **hws = nb_data->onecell_data->hws;
- struct clk_hw *cpu_clk_hw, *parent_clk_hw;
- struct clk *cpu_clk, *parent_clk;
+ struct clk_hw *parent_clk;
int ret;
switch (event) {
case PRE_RATE_CHANGE:
- parent_clk_hw = hws[CLKID_XTAL];
+ /* xtal */
+ parent_clk = clk_hw_get_parent_by_index(nb_data->cpu_clk, 0);
break;
case POST_RATE_CHANGE:
- parent_clk_hw = hws[CLKID_CPU_SCALE_OUT_SEL];
+ /* cpu_scale_out_sel */
+ parent_clk = clk_hw_get_parent_by_index(nb_data->cpu_clk, 1);
break;
default:
return NOTIFY_DONE;
}
- cpu_clk_hw = hws[CLKID_CPUCLK];
- cpu_clk = __clk_lookup(clk_hw_get_name(cpu_clk_hw));
-
- parent_clk = __clk_lookup(clk_hw_get_name(parent_clk_hw));
-
- ret = clk_set_parent(cpu_clk, parent_clk);
+ ret = clk_hw_set_parent(nb_data->cpu_clk, parent_clk);
if (ret)
return notifier_from_errno(ret);
@@ -3695,7 +3690,7 @@ static void __init meson8b_clkc_init_common(struct
device_node *np,
return;
}
- meson8b_cpu_nb_data.onecell_data = clk_hw_onecell_data;
+ meson8b_cpu_nb_data.cpu_clk = clk_hw_onecell_data->hws[CLKID_CPUCLK];
/*
* FIXME we shouldn't program the muxes in notifier handlers. The
--
2.23.0
[PATCH 0/5] provide the XTAL clock via OF on Meson8/8b/8m2
So far the HHI clock controller has been providing the XTAL clock on Amlogic Meson8/Meson8b/Meson8m2 SoCs. This is not correct because the XTAL is actually a crystal on the boards and the SoC has a dedicated input for it. This updates the dt-bindings of the HHI clock controller and defines a fixed-clock in meson.dtsi (along with switching everything over to use this clock). The clock driver needs three updates to use this: - patch #2 uses clk_hw_set_parent in the CPU clock notifier. This drops the explicit reference to CLKID_XTAL while at the same time making the code much easier (thanks to Neil for providing this new method as part of the G12A CPU clock bringup!) - patch #3 ensures that the clock driver doesn't rely on it's internal XTAL clock while not losing support for older .dtbs that don't have the XTAL clock input yet - with patch #4 the clock controller's own XTAL clock is not registered anymore when a clock input is provided via OF This series is a functional no-op. It's main goal is to better represent how the actual hardware looks like. Martin Blumenstingl (5): dt-bindings: clock: meson8b: add the clock inputs clk: meson: meson8b: use clk_hw_set_parent in the CPU clock notifier clk: meson: meson8b: change references to the XTAL clock to use the name clk: meson: meson8b: don't register the XTAL clock when provided via OF ARM: dts: meson: provide the XTAL clock using a fixed-clock .../bindings/clock/amlogic,meson8b-clkc.txt | 5 + arch/arm/boot/dts/meson.dtsi | 7 ++ arch/arm/boot/dts/meson6.dtsi | 7 -- arch/arm/boot/dts/meson8.dtsi | 15 +-- arch/arm/boot/dts/meson8b-ec100.dts | 2 +- arch/arm/boot/dts/meson8b-mxq.dts | 2 +- arch/arm/boot/dts/meson8b-odroidc1.dts| 2 +- arch/arm/boot/dts/meson8b.dtsi| 15 +-- drivers/clk/meson/meson8b.c | 106 +- 9 files changed, 87 insertions(+), 74 deletions(-) -- 2.23.0
[PATCH 5/5] ARM: dts: meson: provide the XTAL clock using a fixed-clock
The clock controller driver has provided the XTAL clock so far. This
does not match how the hardware actually works because the XTAL clock is
an actual crystal which is mounted on the PCB.
Add the "xtal" clock to meson.dtsi and replace all references to the
clock controller's CLKID_XTAL with the new xtal clock node.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson.dtsi | 7 +++
arch/arm/boot/dts/meson6.dtsi | 7 ---
arch/arm/boot/dts/meson8.dtsi | 15 ---
arch/arm/boot/dts/meson8b-ec100.dts| 2 +-
arch/arm/boot/dts/meson8b-mxq.dts | 2 +-
arch/arm/boot/dts/meson8b-odroidc1.dts | 2 +-
arch/arm/boot/dts/meson8b.dtsi | 15 ---
7 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index c4447f6c8b2c..5d198309058a 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -282,4 +282,11 @@
};
};
};
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ clock-output-names = "xtal";
+ #clock-cells = <0>;
+ };
}; /* end of / */
diff --git a/arch/arm/boot/dts/meson6.dtsi b/arch/arm/boot/dts/meson6.dtsi
index 2d31b7ce3f8c..4716030a48d0 100644
--- a/arch/arm/boot/dts/meson6.dtsi
+++ b/arch/arm/boot/dts/meson6.dtsi
@@ -36,13 +36,6 @@
ranges = <0x0 0xd000 0x4>;
};
- xtal: xtal-clk {
- compatible = "fixed-clock";
- clock-frequency = <2400>;
- clock-output-names = "xtal";
- #clock-cells = <0>;
- };
-
clk81: clk@0 {
#clock-cells = <0>;
compatible = "fixed-clock";
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 5a7e3e5caebe..4f59a4c8f036 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -455,6 +455,8 @@
{
clkc: clock-controller {
compatible = "amlogic,meson8-clkc";
+ clocks = <>;
+ clock-names = "xtal";
#clock-cells = <1>;
#reset-cells = <1>;
};
@@ -529,8 +531,7 @@
{
compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
- clocks = < CLKID_XTAL>,
- < CLKID_SAR_ADC>;
+ clocks = <>, < CLKID_SAR_ADC>;
clock-names = "clkin", "core";
amlogic,hhi-sysctrl = <>;
nvmem-cells = <_calib>;
@@ -548,31 +549,31 @@
};
_abcde {
- clocks = < CLKID_XTAL>, < CLKID_CLK81>;
+ clocks = <>, < CLKID_CLK81>;
clock-names = "xtal", "pclk";
};
_AO {
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = < CLKID_CLK81>, < CLKID_XTAL>, < CLKID_CLK81>;
+ clocks = < CLKID_CLK81>, <>, < CLKID_CLK81>;
clock-names = "baud", "xtal", "pclk";
};
_A {
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = < CLKID_CLK81>, < CLKID_XTAL>, < CLKID_UART0>;
+ clocks = < CLKID_CLK81>, <>, < CLKID_UART0>;
clock-names = "baud", "xtal", "pclk";
};
_B {
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = < CLKID_CLK81>, < CLKID_XTAL>, < CLKID_UART1>;
+ clocks = < CLKID_CLK81>, <>, < CLKID_UART1>;
clock-names = "baud", "xtal", "pclk";
};
_C {
compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = < CLKID_CLK81>, < CLKID_XTAL>, < CLKID_UART2>;
+ clocks = < CLKID_CLK81>, <>, < CLKID_UART2>;
clock-names = "baud", "xtal", "pclk";
};
diff --git a/arch/arm/boot/dts/meson8b-ec100.dts
b/arch/arm/boot/dts/meson8b-ec100.dts
index bed1dfef1985..163a200d5a7b 100644
--- a/arch/arm/boot/dts/meson8b-ec100.dts
+++ b/arch/arm/boot/dts/meson8b-ec100.dts
@@ -377,7 +377,7 @@
status = "okay";
pinctrl-0 = <_c1_pins>, <_d_pins>;
pinctrl-names = "default";
- clocks = < CLKID_XTAL>, < CLKID_XTAL>;
+ clocks = <>, <>;
clock-names = "clkin0", "clkin1";
};
diff --git a/arch/arm/boot/dts/meson8b-mxq.dts
b/arch/arm/boot/dts/meson8b-mxq.dts
index 6e39ad52e42d..33037ef62d0a 100644
--- a/arch/arm/boot/dts/meson8b-mxq.dts
+++ b/arch/arm/boot/dts/meson8b-mxq.dts
@@ -165,7 +165,7 @@
status = "okay";
pinctrl-0 = <_c1_pins>, <_d_pins>;
pinctrl-names = "default";
- clocks = < CLKID_XTAL>, < CLKID_XTAL>;
+ clocks = <>, <>;
clock-names = "clkin0", "clkin1";
};
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts
b/arch/arm/boot/dts/meson8b-odroidc1.dts
index a24eccc354b9..a2a47804fc4a 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -340,7 +340,7 @@
status = "okay";
pinctrl-0 = <_c1_pins>, <_d_pins>;
pinctrl-names = "default";
-
[PATCH 1/5] dt-bindings: clock: meson8b: add the clock inputs
The clock controller on Meson8/Meson8b/Meson8m2 has three (known) inputs: - "xtal": the main 24MHz crystal - "ddr_pll": some of the audio clocks use the output of the DDR PLL as input - "clk_32k": an optional clock signal which can be connected to GPIOAO_6 (which then has to be switched to the CLK_32K_IN function) Add the inputs to the documentation so we can wire up these inputs in a follow-up patch. Signed-off-by: Martin Blumenstingl --- .../devicetree/bindings/clock/amlogic,meson8b-clkc.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt index 4d94091c1d2d..cc51e4746b3b 100644 --- a/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt +++ b/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt @@ -11,6 +11,11 @@ Required Properties: - "amlogic,meson8m2-clkc" for Meson8m2 (S812) SoCs - #clock-cells: should be 1. - #reset-cells: should be 1. +- clocks: list of clock phandles, one for each entry in clock-names +- clock-names: should contain the following: + * "xtal": the 24MHz system oscillator + * "ddr_pll": the DDR PLL clock + * "clk_32k": (if present) the 32kHz clock signal from GPIOAO_6 (CLK_32K_IN) Parent node should have the following properties : - compatible: "amlogic,meson-hhi-sysctrl", "simple-mfd", "syscon" -- 2.23.0
Re: [PATCH v8 8/9] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Dan, On 9/20/19 7:41 PM, Dan Murphy wrote: > Introduce the LP5036/30/24/18/12/9 RGB LED driver. > The difference in these parts are the number of > LED outputs where the: > > LP5036 can control 36 LEDs > LP5030 can control 30 LEDs > LP5024 can control 24 LEDs > LP5018 can control 18 LEDs > LP5012 can control 12 LEDs > LP509 can control 9 LEDs > > The device has the ability to group LED output into control banks > so that multiple LED banks can be controlled with the same mixing and > brightness. Inversely the LEDs can also be controlled independently. > > Signed-off-by: Dan Murphy > --- > drivers/leds/Kconfig | 7 + > drivers/leds/Makefile | 1 + > drivers/leds/leds-lp50xx.c | 785 + > 3 files changed, 793 insertions(+) > create mode 100644 drivers/leds/leds-lp50xx.c > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index cfb1ebb6517f..1c0cacb100e6 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -363,6 +363,13 @@ config LEDS_LP3952 > To compile this driver as a module, choose M here: the > module will be called leds-lp3952. > > +config LEDS_LP50XX > + tristate "LED Support for TI LP5036/30/24/18 LED driver chip" > + depends on LEDS_CLASS && REGMAP_I2C && OF > + help > + If you say yes here you get support for the Texas Instruments > + LP5036, LP5030, LP5024 and LP5018 LED driver. Please add also this standard sentence for a module. > + > config LEDS_LP55XX_COMMON > tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501" > depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501 > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > index 841038cfe35b..7a208a0f7b84 100644 > --- a/drivers/leds/Makefile > +++ b/drivers/leds/Makefile > @@ -34,6 +34,7 @@ obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o > obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o > obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o > obj-$(CONFIG_LEDS_LP3952)+= leds-lp3952.o > +obj-$(CONFIG_LEDS_LP50XX)+= leds-lp50xx.o > obj-$(CONFIG_LEDS_LP55XX_COMMON) += leds-lp55xx-common.o > obj-$(CONFIG_LEDS_LP5521)+= leds-lp5521.o > obj-$(CONFIG_LEDS_LP5523)+= leds-lp5523.o > diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c > new file mode 100644 > index ..3ddc14f53eae > --- /dev/null > +++ b/drivers/leds/leds-lp50xx.c > @@ -0,0 +1,785 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// TI LP50XX LED chip family driver > +// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define LP50XX_DEV_CFG0 0x00 > +#define LP50XX_DEV_CFG1 0x01 > +#define LP50XX_LED_CFG0 0x02 > + > +/* LP5009 and LP5012 registers */ > +#define LP5012_BNK_BRT 0x03 > +#define LP5012_BNKA_CLR 0x04 > +#define LP5012_BNKB_CLR 0x05 > +#define LP5012_BNKC_CLR 0x06 > +#define LP5012_LED0_BRT 0x07 > +#define LP5012_LED1_BRT 0x08 > +#define LP5012_LED2_BRT 0x09 > +#define LP5012_LED3_BRT 0x0a > +#define LP5012_OUT0_CLR 0x0b > +#define LP5012_OUT1_CLR 0x0c > +#define LP5012_OUT2_CLR 0x0d > +#define LP5012_OUT3_CLR 0x0e > +#define LP5012_OUT4_CLR 0x0f > +#define LP5012_OUT5_CLR 0x10 > +#define LP5012_OUT6_CLR 0x11 > +#define LP5012_OUT7_CLR 0x12 > +#define LP5012_OUT8_CLR 0x13 > +#define LP5012_OUT9_CLR 0x14 > +#define LP5012_OUT10_CLR 0x15 > +#define LP5012_OUT11_CLR 0x16 > +#define LP5012_RESET 0x17 > + > +/* LP5018 and LP5024 registers */ > +#define LP5024_BNK_BRT 0x03 > +#define LP5024_BNKA_CLR 0x04 > +#define LP5024_BNKB_CLR 0x05 > +#define LP5024_BNKC_CLR 0x06 > +#define LP5024_LED0_BRT 0x07 > +#define LP5024_LED1_BRT 0x08 > +#define LP5024_LED2_BRT 0x09 > +#define LP5024_LED3_BRT 0x0a > +#define LP5024_LED4_BRT 0x0b > +#define LP5024_LED5_BRT 0x0c > +#define LP5024_LED6_BRT 0x0d > +#define LP5024_LED7_BRT 0x0e > + > +#define LP5024_OUT0_CLR 0x0f > +#define LP5024_OUT1_CLR 0x10 > +#define LP5024_OUT2_CLR 0x11 > +#define LP5024_OUT3_CLR 0x12 > +#define LP5024_OUT4_CLR 0x13 > +#define LP5024_OUT5_CLR 0x14 > +#define LP5024_OUT6_CLR 0x15 > +#define LP5024_OUT7_CLR 0x16 > +#define LP5024_OUT8_CLR 0x17 > +#define LP5024_OUT9_CLR
Re: [PATCH v2 1/3] dmaengine: imx-sdma: fix buffer ownership
Hi Philipp,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Philipp-Puschmann/dmaengine-imx-sdma-fix-buffer-ownership/20190919-182516
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
:: branch date: 4 hours ago
:: commit date: 4 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/dma/imx-sdma.c: In function 'sdma_update_channel_loop':
>> drivers/dma/imx-sdma.c:819:3: error: implicit declaration of function
>> 'dma_wb'; did you mean 'dma_wmb'? [-Werror=implicit-function-declaration]
dma_wb();
^~
dma_wmb
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/750aab0984840c5966a75794c457c1e79e88d34e
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 750aab0984840c5966a75794c457c1e79e88d34e
vim +819 drivers/dma/imx-sdma.c
57b772b86871e0 Robin Gong 2018-06-20 774
d1a792f3b4072b Russell King - ARM Linux 2014-06-25 775 static void
sdma_update_channel_loop(struct sdma_channel *sdmac)
d1a792f3b4072b Russell King - ARM Linux 2014-06-25 776 {
1ec1e82f2510e2 Sascha Hauer 2010-09-30 777 struct
sdma_buffer_descriptor *bd;
5881826ded79cf Nandor Han 2016-08-08 778 int error = 0;
5881826ded79cf Nandor Han 2016-08-08 779 enum dma_status
old_status = sdmac->status;
1ec1e82f2510e2 Sascha Hauer 2010-09-30 780
1ec1e82f2510e2 Sascha Hauer 2010-09-30 781 /*
1ec1e82f2510e2 Sascha Hauer 2010-09-30 782 * loop mode.
Iterate over descriptors, re-setup them and
1ec1e82f2510e2 Sascha Hauer 2010-09-30 783 * call
callback function.
1ec1e82f2510e2 Sascha Hauer 2010-09-30 784 */
57b772b86871e0 Robin Gong 2018-06-20 785 while
(sdmac->desc) {
76c33d27073e29 Sascha Hauer 2018-06-20 786 struct
sdma_desc *desc = sdmac->desc;
76c33d27073e29 Sascha Hauer 2018-06-20 787
76c33d27073e29 Sascha Hauer 2018-06-20 788 bd =
>bd[desc->buf_tail];
1ec1e82f2510e2 Sascha Hauer 2010-09-30 789
1ec1e82f2510e2 Sascha Hauer 2010-09-30 790 if
(bd->mode.status & BD_DONE)
1ec1e82f2510e2 Sascha Hauer 2010-09-30 791
break;
1ec1e82f2510e2 Sascha Hauer 2010-09-30 792
5881826ded79cf Nandor Han 2016-08-08 793 if
(bd->mode.status & BD_RROR) {
5881826ded79cf Nandor Han 2016-08-08 794
bd->mode.status &= ~BD_RROR;
1ec1e82f2510e2 Sascha Hauer 2010-09-30 795
sdmac->status = DMA_ERROR;
5881826ded79cf Nandor Han 2016-08-08 796
error = -EIO;
5881826ded79cf Nandor Han 2016-08-08 797 }
1ec1e82f2510e2 Sascha Hauer 2010-09-30 798
5881826ded79cf Nandor Han 2016-08-08 799/*
5881826ded79cf Nandor Han 2016-08-08 800 * We
use bd->mode.count to calculate the residue, since contains
5881826ded79cf Nandor Han 2016-08-08 801 * the
number of bytes present in the current buffer descriptor.
5881826ded79cf Nandor Han 2016-08-08 802 */
5881826ded79cf Nandor Han 2016-08-08 803
76c33d27073e29 Sascha Hauer 2018-06-20 804
desc->chn_real_count = bd->mode.count;
76c33d27073e29 Sascha Hauer 2018-06-20 805
bd->mode.count = desc->period_len;
76c33d27073e29 Sascha Hauer 2018-06-20 806
desc->buf_ptail = desc->buf_tail;
76c33d27073e29 Sascha Hauer 2018-06-20 807
desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
15f30f51311152 Nandor Han 2016-08-08 808
15f30f51311152 Nandor Han 2016-08-08 809 /*
15f30f51311152 Nandor Han 2016-08-08 810 * The
callback is called from the interrupt context in order
15f30f51311152 Nandor Han
