Re: [PATCH resend] eventfd: make eventfd files distinguishable in /proc/$PID/fd
On Tue, 11 Dec 2018 17:09:14 -0600, "Serge E. Hallyn" wrote:
> On Mon, Dec 10, 2018 at 03:35:46AM +0900, Masatake YAMATO wrote:
>> Finding endpoints of an IPC channel is one of essential task to
>> understand how a user program works. Procfs and netlink socket provide
>> enough hints to find endpoints for IPC channels like pipes, unix
>> sockets, and pseudo terminals. However, there is no simple way to find
>> endpoints for an eventfd file from userland. An inode number doesn't
>> hint. Unlike pipe, all eventfd files shares one inode object.
>>
>> To provide the way to find endpoints of an eventfd file, this patch
>> adds eventfd identifiers to the output of 'ls -l /proc/$pid/fd' like:
>>
>> ...
>> lrwx--. 1 qemu qemu 64 May 20 04:49 93 -> 'anon_inode:[eventfd:130]'
>> lrwx--. 1 qemu qemu 64 May 20 04:49 94 -> 'anon_inode:[eventfd:131]'
>> ...
>>
>> Here "130" and "131" are added as identifiers newly added.
>> In the case that ida_simple_get returns an error, this change doesn't add
>> an identifier; just use "[eventfd]" as before.
>>
>> Signed-off-by: Masatake YAMATO
>
> I'm going to love this when I need it :) Thanks.
>
> Acked-by: Serge Hallyn
>
Thank you for replying.
This is the first time getting replying since my first post,
Mon, 21 May 2018 05:18:23 +0900.
Can I expect my patch is merged to the mainline?
Or should I do something more?
Masatake YAMATO
>> ---
>> fs/eventfd.c | 14 +-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/eventfd.c b/fs/eventfd.c
>> index 08d3bd602f73..c18952948110 100644
>> --- a/fs/eventfd.c
>> +++ b/fs/eventfd.c
>> @@ -21,6 +21,11 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +/* Worst case buffer size needed for holding an integer. */
>> +#define ITOA_MAX_LEN 12
>> +DEFINE_IDA(eventfd_ida);
>>
>> struct eventfd_ctx {
>> struct kref kref;
>> @@ -35,6 +40,7 @@ struct eventfd_ctx {
>> */
>> __u64 count;
>> unsigned int flags;
>> +int id;
>> };
>>
>> /**
>> @@ -69,6 +75,8 @@ EXPORT_SYMBOL_GPL(eventfd_signal);
>>
>> static void eventfd_free_ctx(struct eventfd_ctx *ctx)
>> {
>> +if (ctx->id >= 0)
>> +ida_simple_remove(&eventfd_ida, ctx->id);
>> kfree(ctx);
>> }
>>
>> @@ -384,6 +392,7 @@ static int do_eventfd(unsigned int count, int flags)
>> {
>> struct eventfd_ctx *ctx;
>> int fd;
>> +char name[1 + 8 + ITOA_MAX_LEN + 1 + 1] = "[eventfd]";
>>
>> /* Check the EFD_* constants for consistency. */
>> BUILD_BUG_ON(EFD_CLOEXEC != O_CLOEXEC);
>> @@ -400,8 +409,11 @@ static int do_eventfd(unsigned int count, int flags)
>> init_waitqueue_head(&ctx->wqh);
>> ctx->count = count;
>> ctx->flags = flags;
>> +ctx->id = ida_simple_get(&eventfd_ida, 0, 0, GFP_KERNEL);
>>
>> -fd = anon_inode_getfd("[eventfd]", &eventfd_fops, ctx,
>> +if (ctx->id >= 0)
>> +snprintf(name, sizeof(name), "[eventfd:%d]", ctx->id);
>> +fd = anon_inode_getfd(name, &eventfd_fops, ctx,
>>O_RDWR | (flags & EFD_SHARED_FCNTL_FLAGS));
>> if (fd < 0)
>> eventfd_free_ctx(ctx);
>> --
>> 2.17.0
[PATCH v1 1/3] perf record: allocate affinity masks
Allocate affinity option and masks for mmap data buffers and
record thread as well as initialize allocated objects.
Signed-off-by: Alexey Budankov
---
tools/perf/builtin-record.c | 11 ++-
tools/perf/perf.h | 5 +
tools/perf/util/evlist.c| 6 +++---
tools/perf/util/evlist.h| 2 +-
tools/perf/util/mmap.c | 2 ++
tools/perf/util/mmap.h | 3 ++-
6 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 882285fb9f64..4979719e54ae 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -81,6 +81,7 @@ struct record {
booltimestamp_boundary;
struct switch_outputswitch_output;
unsigned long long samples;
+ cpu_set_t affinity_mask;
};
static volatile int auxtrace_record__snapshot_started;
@@ -533,7 +534,8 @@ static int record__mmap_evlist(struct record *rec,
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode,
opts->nr_cblocks) < 0) {
+opts->auxtrace_snapshot_mode,
+opts->nr_cblocks, opts->affinity) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
"Consider increasing "
@@ -1980,6 +1982,9 @@ int cmd_record(int argc, const char **argv)
# undef REASON
#endif
+ CPU_ZERO(&rec->affinity_mask);
+ rec->opts.affinity = PERF_AFFINITY_SYS;
+
rec->evlist = perf_evlist__new();
if (rec->evlist == NULL)
return -ENOMEM;
@@ -2143,6 +2148,10 @@ int cmd_record(int argc, const char **argv)
if (verbose > 0)
pr_info("nr_cblocks: %d\n", rec->opts.nr_cblocks);
+ pr_debug("affinity (UNSET:%d, NODE:%d, CPU:%d) = %d\n",
+PERF_AFFINITY_SYS, PERF_AFFINITY_NODE,
+PERF_AFFINITY_CPU, rec->opts.affinity);
+
err = __cmd_record(&record, argc, argv);
out:
perf_evlist__delete(rec->evlist);
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 388c6dd128b8..08e75815de2f 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -83,8 +83,13 @@ struct record_opts {
clockid_tclockid;
u64 clockid_res_ns;
int nr_cblocks;
+ int affinity;
};
+#define PERF_AFFINITY_SYS 0
+#define PERF_AFFINITY_NODE 1
+#define PERF_AFFINITY_CPU 2
+
struct option;
extern const char * const *record_usage;
extern struct option *record_options;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e90575192209..60e825be944a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1018,7 +1018,7 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
*/
int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks)
+bool auxtrace_overwrite, int nr_cblocks, int affinity)
{
struct perf_evsel *evsel;
const struct cpu_map *cpus = evlist->cpus;
@@ -1028,7 +1028,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* Its value is decided by evsel's write_backward.
* So &mp should not be passed through const pointer.
*/
- struct mmap_params mp = { .nr_cblocks = nr_cblocks };
+ struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
affinity };
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
@@ -1060,7 +1060,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
int perf_evlist__mmap(struct perf_evlist *evlist, unsigned int pages)
{
- return perf_evlist__mmap_ex(evlist, pages, 0, false, 0);
+ return perf_evlist__mmap_ex(evlist, pages, 0, false, 0,
PERF_AFFINITY_SYS);
}
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 868294491194..72728d7f4432 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -162,7 +162,7 @@ unsigned long perf_event_mlock_kb_in_pages(void);
int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks);
+bool auxtrace_overwrite, int nr_cblocks, int affinity);
int perf_evlist__mmap(struct perf_evlist *evlist, unsigned int pages);
void perf_evlist__munmap(struct perf_evlist *evlist);
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index 8fc39311a30d..e68ba754a8e2 100644
--- a/tools/perf/util
Re: [PATCH] scatterlist: Update size type to support greater then 4GB size.
On Wed, 12 Dec 2018 at 07:25, Ashish Mhetre wrote:
>
> From: Krishna Reddy
>
> In the cases where greater than 4GB allocations are required, current
> definition of scatterlist doesn't support it. For example, Tegra devices
> have more than 4GB of system memory available. So they are expected to
> support larger allocation requests.
> This patch updates the type of scatterlist members to support creating
> scatterlist for allocations of size greater than 4GB size.
Can you explain what the use case is? We have had systems with more
than 4 GB for a while now, so where does this new requirement come
from?
Also, you are changing 'length' to size_t and 'offset' to unsigned
long. What is the rationale behind that? Did you consider 32-bit
architectures with PAE at all?
> Updated the files that are necessary to fix compilation issues with updated
> type of variables.
>
> With definition of scatterlist changed in this patch, size of sg has
> increased from 28 bytes to 40 bytes because of which allocations in nvme
> driver are crossing order-0( as sizeof(struct scatterlist) is used in nvme
> driver allocations ) i.e. they are not able to fit into single page.
>
> Recently a patch to limit the nvme allocations to order-0 is mergerd.
> 'commit 943e942e6266f22babee5efeb00f8f672fbff5bd ("nvme-pci: limit
> max IO size and segments to avoid high order allocations")'
> Because of that patch, WARN log is getting printed in our case as
> definition of scatterlist has changed. Alloc size of nvme is calculated as
> NVME_MAX_SEGS * sizeof(struct scatterlist). As sizeof(struct scatterlist)
> has changed from 28 bytes to 40 bytes, so updating NVME_MAX_SEGS from 127
> to 88 to correspond to original nvme alloc size value.
>
> Signed-off-by: Krishna Reddy
> Signed-off-by: Ashish Mhetre
> ---
> crypto/shash.c| 2 +-
> drivers/ata/libata-sff.c | 2 +-
> drivers/mmc/host/sdhci.c | 2 +-
> drivers/mmc/host/toshsd.c | 2 +-
> drivers/mmc/host/usdhi6rol0.c | 14 +++---
> drivers/nvme/host/pci.c | 8
> include/linux/nvme.h | 2 +-
> include/linux/scatterlist.h | 8
> 8 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/crypto/shash.c b/crypto/shash.c
> index d21f04d..434970e 100644
> --- a/crypto/shash.c
> +++ b/crypto/shash.c
> @@ -298,7 +298,7 @@ int shash_ahash_digest(struct ahash_request *req, struct
> shash_desc *desc)
>
> if (nbytes &&
> (sg = req->src, offset = sg->offset,
> -nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)))
> {
> +nbytes < min(sg->length, ((size_t)(PAGE_SIZE)) - offset))) {
> void *data;
>
> data = kmap_atomic(sg_page(sg));
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index c5ea0fc..675def6 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -810,7 +810,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc,
> unsigned int bytes)
> offset %= PAGE_SIZE;
>
> /* don't overrun current sg */
> - count = min(sg->length - qc->cursg_ofs, bytes);
> + count = min(sg->length - qc->cursg_ofs, (size_t)bytes);
>
> /* don't cross page boundaries */
> count = min(count, (unsigned int)PAGE_SIZE - offset);
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 99bdae5..bd84c0c 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1025,7 +1025,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
> struct mmc_command *cmd)
> if (unlikely(length_mask | offset_mask)) {
> for_each_sg(data->sg, sg, data->sg_len, i) {
> if (sg->length & length_mask) {
> - DBG("Reverting to PIO because of
> transfer size (%d)\n",
> + DBG("Reverting to PIO because of
> transfer size (%zd)\n",
> sg->length);
> host->flags &= ~SDHCI_REQ_USE_DMA;
> break;
> diff --git a/drivers/mmc/host/toshsd.c b/drivers/mmc/host/toshsd.c
> index dd961c5..af00936 100644
> --- a/drivers/mmc/host/toshsd.c
> +++ b/drivers/mmc/host/toshsd.c
> @@ -479,7 +479,7 @@ static void toshsd_start_data(struct toshsd_host *host,
> struct mmc_data *data)
> {
> unsigned int flags = SG_MITER_ATOMIC;
>
> - dev_dbg(&host->pdev->dev, "setup data transfer: blocksize %08x
> nr_blocks %d, offset: %08x\n",
> + dev_dbg(&host->pdev->dev, "setup data transfer: blocksize %08x
> nr_blocks %d, offset: %08lx\n",
> data->blksz, data->blocks, data->sg->offset);
>
> host->data = data;
> diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
> index cd8b1b9..5fce5ff 100644
> --- a/drivers/mmc/host/usdhi6rol0.c
> +++ b/drivers/mmc/
Re: MMC driver programming help request
Hello, On Wed, Dec 12, 2018 at 11:09:31AM +0330, Hossein Radhasani wrote: > I need some help. > I have device with eMMC storage and wnat to write on specific page of it. > I was trying to use MMC driver, but unfortunately have some problems. > Would you please help me? The usual approach to get help in the FOSS world is to start describing the problem you want to solve including the motivation for it. Then show the things you did to solve the problem including a description how they failed. And then choose the recipents of the resuling mail carefully and don't put everyone on Cc who might have mentioned a relevant keyword once. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v13 1/6] x86/boot: Introduce kstrtoull() to boot directory instead of simple_strtoull()
On 12/12/18 at 11:10am, Chao Fan wrote:
> Introduce kstrtoull() from lib/kstrtox.c to boot directory so that code
It's not introducing kstrtoull(), just copying kstrtoull() from
lib/kstrtox.c to boot.
> in boot/ can use kstrtoull() and the old simple_strtoull() can be
> replaced.
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/string.c | 137 +
> arch/x86/boot/string.h | 2 +
> 2 files changed, 139 insertions(+)
>
> diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
> index c4428a176973..e02405f20f98 100644
> --- a/arch/x86/boot/string.c
> +++ b/arch/x86/boot/string.c
> @@ -12,7 +12,10 @@
> * Very basic string functions
> */
>
> +#define _LINUX_CTYPE_H
> #include
> +#include
> +#include
> #include
> #include "ctype.h"
> #include "string.h"
> @@ -187,3 +190,137 @@ char *strchr(const char *s, int c)
> return NULL;
> return (char *)s;
> }
> +
> +static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
> +{
> + union {
> + u64 v64;
> + u32 v32[2];
> + } d = { dividend };
> + u32 upper;
> +
> + upper = d.v32[1];
> + d.v32[1] = 0;
> + if (upper >= divisor) {
> + d.v32[1] = upper / divisor;
> + upper %= divisor;
> + }
> + asm ("divl %2" : "=a" (d.v32[0]), "=d" (*remainder) :
> + "rm" (divisor), "0" (d.v32[0]), "1" (upper));
> + return d.v64;
> +}
> +
> +static inline u64 div_u64(u64 dividend, u32 divisor)
> +{
> + u32 remainder;
> + return div_u64_rem(dividend, divisor, &remainder);
> +}
> +
> +static inline char _tolower(const char c)
> +{
> + return c | 0x20;
> +}
> +
> +const char *_parse_integer_fixup_radix(const char *s, unsigned int *base)
> +{
> + if (*base == 0) {
> + if (s[0] == '0') {
> + if (_tolower(s[1]) == 'x' && isxdigit(s[2]))
> + *base = 16;
> + else
> + *base = 8;
> + } else
> + *base = 10;
> + }
> + if (*base == 16 && s[0] == '0' && _tolower(s[1]) == 'x')
> + s += 2;
> + return s;
> +}
> +
> +/*
> + * Convert non-negative integer string representation in explicitly given
> radix
> + * to an integer.
> + * Return number of characters consumed maybe or-ed with overflow bit.
> + * If overflow occurs, result integer (incorrect) is still returned.
> + *
> + * Don't you dare use this function.
> + */
> +unsigned int _parse_integer(const char *s, unsigned int base, unsigned long
> long *p)
> +{
> + unsigned long long res;
> + unsigned int rv;
> +
> + res = 0;
> + rv = 0;
> + while (1) {
> + unsigned int c = *s;
> + unsigned int lc = c | 0x20; /* don't tolower() this line */
> + unsigned int val;
> +
> + if ('0' <= c && c <= '9')
> + val = c - '0';
> + else if ('a' <= lc && lc <= 'f')
> + val = lc - 'a' + 10;
> + else
> + break;
> +
> + if (val >= base)
> + break;
> + /*
> + * Check for overflow only if we are within range of
> + * it in the max base we support (16)
> + */
> + if (unlikely(res & (~0ull << 60))) {
> + if (res > div_u64(ULLONG_MAX - val, base))
> + rv |= KSTRTOX_OVERFLOW;
> + }
> + res = res * base + val;
> + rv++;
> + s++;
> + }
> + *p = res;
> + return rv;
> +}
> +
> +static int _kstrtoull(const char *s, unsigned int base, unsigned long long
> *res)
> +{
> + unsigned long long _res;
> + unsigned int rv;
> +
> + s = _parse_integer_fixup_radix(s, &base);
> + rv = _parse_integer(s, base, &_res);
> + if (rv & KSTRTOX_OVERFLOW)
> + return -ERANGE;
> + if (rv == 0)
> + return -EINVAL;
> + s += rv;
> + if (*s == '\n')
> + s++;
> + if (*s)
> + return -EINVAL;
> + *res = _res;
> + return 0;
> +}
> +
> +/**
> + * kstrtoull - convert a string to an unsigned long long
> + * @s: The start of the string. The string must be null-terminated, and may
> also
> + * include a single newline before its terminating null. The first character
> + * may also be a plus sign, but not a minus sign.
> + * @base: The number base to use. The maximum supported base is 16. If base
> is
> + * given as 0, then the base of the string is automatically detected with
> the
> + * conventional semantics - If it begins with 0x the number will be parsed
> as a
> + * hexadecimal (case insensitive), if it otherwise begins with 0, it will be
> + * parsed as an octal number. Otherwise it will be parsed as a decimal.
> + * @res: Where to write the result of the conversion on success.
> + *
> +
Re: [PATCH] scatterlist: Update size type to support greater then 4GB size.
On 12/12/18 12:19 PM, Sagi Grimberg wrote:
struct nvme_sgl_desc {
__le64 addr;
- __le32 length;
+ __le64 length;
__u8 rsvd[3];
__u8 type;
};
Isn't this a device or protocol defined datastructure? You can't just
change it like this.
You're correct, we can't...
[Replied before seeing this issue was already highlighted]
The positive side is that it can safely be removed without affecting the
rest of the patch...
Ohh, I am not aware of this protocol defined data-structures. But it
seems that this need not be changed as Sagi is saying sg length for NVME
will never cross 32 bit size.
I'll send a new version removing this change. Thanks.
[PATCH v1 3/3] perf record: implement --affinity=node|cpu option
Implement --affinity=node|cpu option for the record mode defaulting
to system affinity mask bouncing.
Signed-off-by: Alexey Budankov
---
tools/perf/Documentation/perf-record.txt | 5 +
tools/perf/builtin-record.c | 18 ++
2 files changed, 23 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index d232b13ea713..efb839784f32 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -440,6 +440,11 @@ Use control blocks in asynchronous (Posix AIO) trace
writing mode (default:
Asynchronous mode is supported only when linking Perf tool with libc library
providing implementation for Posix AIO API.
+--affinity=mode::
+Set affinity mask of trace reading thread according to the policy defined by
'mode' value:
+ node - thread affinity mask is set to NUMA node cpu mask of the processed
mmap buffer
+ cpu - thread affinity mask is set to cpu of the processed mmap buffer
+
--all-kernel::
Configure all used events to run in kernel space.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 1a1438c73f96..3b4b47055aa1 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1649,6 +1649,21 @@ static int parse_clockid(const struct option *opt, const
char *str, int unset)
ui__warning("unknown clockid %s, check man page\n", ostr);
return -1;
}
+static int record__parse_affinity(const struct option *opt, const char *str,
int unset)
+{
+ struct record_opts *opts = (struct record_opts *)opt->value;
+
+ if (!unset) {
+ if (str) {
+ if (!strcasecmp(str, "node"))
+ opts->affinity = PERF_AFFINITY_NODE;
+ else if (!strcasecmp(str, "cpu"))
+ opts->affinity = PERF_AFFINITY_CPU;
+ }
+ }
+
+ return 0;
+}
static int record__parse_mmap_pages(const struct option *opt,
const char *str,
@@ -1957,6 +1972,9 @@ static struct option __record_options[] = {
&nr_cblocks_default, "n", "Use control blocks in
asynchronous trace writing mode (default: 1, max: 4)",
record__aio_parse),
#endif
+ OPT_CALLBACK(0, "affinity", &record.opts, "node|cpu",
+"Set affinity mask of trace reading thread to NUMA node
cpu mask or cpu of processed mmap buffer",
+record__parse_affinity),
OPT_END()
};
Re: linux-next: manual merge of the sparc-next tree with the dma-mapping tree
On Wed, Dec 12, 2018 at 09:30:42AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the sparc-next tree got a conflict in:
>
> arch/sparc/kernel/ioport.c
>
> between commit:
>
> 53b7670e5735 ("sparc: factor the dma coherent mapping into helper")
>
> from the dma-mapping tree and commit:
>
> 86ef771ed543 ("sparc: Use DT node full_name instead of name for resources")
>
> from the sparc-next tree.
Dave, Sam:
should I just apply a version of Rob's tree that takes the refactoring
into account to the dma-mapping tree? That way we should get the right
result independent of the merge order.
[PATCH v4 3/3] regulator: mcp16502: add regulator driver for MCP16502
This patch adds a regulator driver for the MCP16502 PMIC.
This drivers supports basic operations through the
regulator interface such as:
- setting/reading voltage
- setting/reading operating mode
- reading current status
- transitioning to/from suspend-to-ram and standby
power states
Signed-off-by: Andrei Stefanescu
---
drivers/regulator/Kconfig| 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mcp16502.c | 553 +++
3 files changed, 563 insertions(+)
create mode 100644 drivers/regulator/mcp16502.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 926cee0..719d9d6 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -567,6 +567,15 @@ config REGULATOR_MC13892
Say y here to support the regulators found on the Freescale MC13892
PMIC.
+config REGULATOR_MCP16502
+ tristate "Microchip MCP16502 PMIC"
+ depends on I2C && OF
+ help
+ Say y here to support the MCP16502 PMIC. This driver supports
+ basic operations (get/set voltage, get/set operating mode)
+ through the regulator interface. In addition it enables
+ suspend-to-ram/standby transition.
+
config REGULATOR_MT6311
tristate "MediaTek MT6311 PMIC"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 72488ef..b12e1c9 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_REGULATOR_MAX77802) += max77802-regulator.o
obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
+obj-$(CONFIG_REGULATOR_MCP16502) += mcp16502.o
obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
new file mode 100644
index 000..bde3172
--- /dev/null
+++ b/drivers/regulator/mcp16502.c
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// MCP16502 PMIC driver
+//
+// Copyright (C) 2018 Microchip Technology Inc. and its subsidiaries
+//
+// Author: Andrei Stefanescu
+//
+// Inspired from tps65086-regulator.c
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VDD_LOW_SEL 0x0D
+#define VDD_HIGH_SEL 0x3F
+
+#define MCP16502_FLT BIT(7)
+#define MCP16502_ENS BIT(0)
+
+/*
+ * The PMIC has four sets of registers corresponding to four power modes:
+ * Performance, Active, Low-power, Hibernate.
+ *
+ * Registers:
+ * Each regulator has a register for each power mode. To access a register
+ * for a specific regulator and mode BASE_* and OFFSET_* need to be added.
+ *
+ * Operating modes:
+ * In order for the PMIC to transition to operating modes it has to be
+ * controlled via GPIO lines called LPM and HPM.
+ *
+ * The registers are fully configurable such that you can put all regulators in
+ * a low-power state while the PMIC is in Active mode. They are supposed to be
+ * configured at startup and then simply transition to/from a global low-power
+ * state by setting the GPIO lpm pin high/low.
+ *
+ * This driver keeps the PMIC in Active mode, Low-power state is set for the
+ * regulators by enabling/disabling operating mode (FPWM or Auto PFM).
+ *
+ * The PMIC's Low-power and Hibernate modes are used during standby/suspend.
+ * To enter standby/suspend the PMIC will go to Low-power mode. From there, it
+ * will transition to Hibernate when the PWRHLD line is set to low by the MPU.
+ */
+
+/*
+ * This function is useful for iterating over all regulators and accessing
their
+ * registers in a generic way or accessing a regulator device by its id.
+ */
+#define MCP16502_BASE(i) (((i) + 1) << 4)
+#define MCP16502_STAT_BASE(i) ((i) + 5)
+
+#define MCP16502_OFFSET_MODE_A 0
+#define MCP16502_OFFSET_MODE_LPM 1
+#define MCP16502_OFFSET_MODE_HIB 2
+
+#define MCP16502_OPMODE_ACTIVE REGULATOR_MODE_NORMAL
+#define MCP16502_OPMODE_LPM REGULATOR_MODE_IDLE
+#define MCP16502_OPMODE_HIB REGULATOR_MODE_STANDBY
+
+#define MCP16502_MODE_AUTO_PFM 0
+#define MCP16502_MODE_FPWM BIT(6)
+
+#define MCP16502_VSEL 0x3F
+#define MCP16502_EN BIT(7)
+#define MCP16502_MODE BIT(6)
+
+#define MCP16502_MIN_REG 0x0
+#define MCP16502_MAX_REG 0x65
+
+static unsigned int mcp16502_of_map_mode(unsigned int mode)
+{
+ if (mode == REGULATOR_MODE_NORMAL || mode == REGULATOR_MODE_IDLE)
+ return mode;
+
+ return REGULATOR_MODE_INVALID;
+}
+
+#define MCP16502_REGULATOR(_name, _id, _ranges, _ops) \
+ [_id] = { \
+ .name = _name,\
+ .regulators_node= of_match_ptr("regulators"), \
+ .id
[PATCH v4 2/3] MAINTAINERS: add maintainer for MCP16502 PMIC driver
This patch adds a maintainer for the MCP16502 PMIC driver. Signed-off-by: Andrei Stefanescu --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b755a89..6a74a65 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9730,6 +9730,13 @@ M: Ludovic Desroches S: Maintained F: drivers/mmc/host/atmel-mci.c +MICROCHIP MCP16502 PMIC DRIVER +M: Andrei Stefanescu +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt +F: drivers/regulator/mcp16502.c + MICROCHIP MCP3911 ADC DRIVER M: Marcus Folkesson M: Kent Gustavsson -- 2.7.4
[PATCH v4 1/3] regulator: dt-bindings: add MCP16502 regulator bindings
This patch describes the compatible and the device tree
bindings necessary for the MCP16502 PMIC.
Signed-off-by: Andrei Stefanescu
Reviewed-by: Rob Herring
---
.../bindings/regulator/mcp16502-regulator.txt | 143 +
1 file changed, 143 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
new file mode 100644
index 000..b8f843f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
@@ -0,0 +1,143 @@
+MCP16502 PMIC
+
+Required properties:
+- compatible: "microchip,mcp16502"
+- reg: I2C slave address
+- lpm-gpios: GPIO for LPM pin. Note that this GPIO *must* remain high during
+suspend-to-ram, keeping the PMIC into HIBERNATE mode.
+- regulators: A node that houses a sub-node for each regulator within
+ the device. Each sub-node is identified using the node's
+ name. The content of each sub-node is defined by the
+ standard binding for regulators; see regulator.txt.
+
+Regualtors of MCP16502 PMIC:
+1) VDD_IO - Buck (1.2 - 3.7 V)
+2) VDD_DDR - Buck (0.6 - 1.85 V)
+3) VDD_CORE- Buck (0.6 - 1.85 V)
+4) VDD_OTHER - BUCK (0.6 - 1.85 V)
+5) LDO1- LDO (1.2 - 3.7 V)
+6) LDO2- LDO (1.2 - 3.7 V)
+
+Regulator modes:
+2 - FPWM: higher precision, higher consumption
+4 - AutoPFM: lower precision, lower consumption
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+mcp16502@5b {
+ compatible = "microchip,mcp16502";
+ reg = <0x5b>;
+ status = "okay";
+ lpm-gpios = <&pioBU 7 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ VDD_IO {
+ regulator-name = "VDD_IO";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <370>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ VDD_DDR {
+ regulator-name = "VDD_DDR";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <185>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ VDD_CORE {
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <185>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ VDD_OTHER {
+ regulator-name = "VDD_OTHER";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <185>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <12000
[PATCH v4 0/3] add support for MCP16502 PMIC
MCP16502 is a Power Management IC from Microchip. It has 4 Buck outputs and 2 LDOs. The buck regulators can be used in two modes: normal(FPWM) and low-power(Auto PFM). This patch series adds support for the MCP16502 PMIC. v4: - make entire intial comment a C++ comment v3: - use CONFIG_SUSPEND and CONFIG_PM to fix compile errors for some configs v2: - use lpm-gpios instead of lpm-gpio in devicetree bindings documentation - describe the regulators present on the PMIC in the devicetree bindings documentation - add SPDX license inside a C++ comment - prefix macro - remove mcp16502_update_regulator and mcp16502_read - replace ?: with if-else - change some if-else with switch statements for legibility - use regmap helpers for regultor settings during runtime - make mcp16502_get_status read the status from the PMIC STS registers - use module_i2c_driver - use the PMIC's Hibernate registers for suspend-to-mem, the PMIC's Low-power registers for standby and the PMIC's Active registers for normal runtime Note about mcp16502_suspend: - mcp16502_gpio_set_mode(mcp, MCP16502_OPMODE_HIB) has now been changed to mcp16502_gpio_set_mode(mcp, MCP16502_OPMODE_LPM) for legibility. Note that the function call only sets the LPM pin of the PMIC to high. This puts the PMIC in Low-power operating mode. Hibernate operating mode is reached when the MPU sets the PWRHLD line to zero (typically when entering suspend-to-ram). Andrei Stefanescu (3): regulator: dt-bindings: add MCP16502 regulator bindings MAINTAINERS: add maintainer for MCP16502 PMIC driver regulator: mcp16502: add regulator driver for MCP16502 .../bindings/regulator/mcp16502-regulator.txt | 143 ++ MAINTAINERS| 7 + drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/mcp16502.c | 553 + 5 files changed, 713 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt create mode 100644 drivers/regulator/mcp16502.c -- 2.7.4
Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD
On Tue, Dec 11, 2018 at 06:22:27PM +, Parshuram Raju Thombare wrote: > One reason of using device mapper here is to use existing tools like > 'dmsetup', otherwise some user space application is needed and may be > some changes in block layer to pass the crypto information (crypto > algorithm, key etc) till ufs driver. Yes, so what? We also don't use dmsetup to set up TCG OPAL based encryption either. > Another reason is supporting multiple UFS devices. I think, as you said > UFS crypto support can be added by some change in ufs driver and block > layer glue. But to support multiple UFS crypto devices having different > crypto configs (crypto algorithms, key size etc), crypto context need to > be saved per crypto device which may need some changes in block layer code. I don't think we need device mapper for that. We can hav the crypto state hanging off the ufs host, or request_queue if we decide to implement it generic in the block layer.
[PATCH v1 2/3] perf record: apply affinity masks when reading mmap buffers
Build node cpu masks for mmap data buffers. Bind AIO data buffers
to nodes according to kernel data buffers location. Apply node cpu
masks to trace reading thread every time it references memory cross
node or cross cpu.
Signed-off-by: Alexey Budankov
---
tools/perf/builtin-record.c | 9 +
tools/perf/util/evlist.c| 6 +-
tools/perf/util/mmap.c | 38 -
tools/perf/util/mmap.h | 1 +
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4979719e54ae..1a1438c73f96 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -532,6 +532,9 @@ static int record__mmap_evlist(struct record *rec,
struct record_opts *opts = &rec->opts;
char msg[512];
+ if (opts->affinity != PERF_AFFINITY_SYS)
+ cpu__setup_cpunode_map();
+
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
opts->auxtrace_snapshot_mode,
@@ -751,6 +754,12 @@ static int record__mmap_read_evlist(struct record *rec,
struct perf_evlist *evli
struct perf_mmap *map = &maps[i];
if (map->base) {
+ if (rec->opts.affinity != PERF_AFFINITY_SYS &&
+ !CPU_EQUAL(&rec->affinity_mask,
&map->affinity_mask)) {
+ CPU_ZERO(&rec->affinity_mask);
+ CPU_OR(&rec->affinity_mask,
&rec->affinity_mask, &map->affinity_mask);
+ sched_setaffinity(0,
sizeof(rec->affinity_mask), &rec->affinity_mask);
+ }
if (!record__aio_enabled(rec)) {
if (perf_mmap__push(map, rec, record__pushfn)
!= 0) {
rc = -1;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 60e825be944a..5ca5bb5ea0db 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1028,7 +1028,11 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* Its value is decided by evsel's write_backward.
* So &mp should not be passed through const pointer.
*/
- struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
affinity };
+ struct mmap_params mp = {
+ .nr_cblocks = nr_cblocks,
+ .affinity = affinity,
+ .cpu_map= cpus
+ };
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index e68ba754a8e2..0d017ea85dcb 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -10,6 +10,9 @@
#include
#include
#include
+#ifdef HAVE_LIBNUMA_SUPPORT
+#include
+#endif
#include "debug.h"
#include "event.h"
#include "mmap.h"
@@ -177,11 +180,27 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map,
struct mmap_params *mp)
}
delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
for (i = 0; i < map->aio.nr_cblocks; ++i) {
+#ifndef HAVE_LIBNUMA_SUPPORT
map->aio.data[i] = malloc(perf_mmap__mmap_len(map));
+#else
+ size_t mmap_len = perf_mmap__mmap_len(map);
+ map->aio.data[i] = mmap(NULL, mmap_len,
+ PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
+#endif
if (!map->aio.data[i]) {
pr_debug2("failed to allocate data buffer area,
error %m");
return -1;
}
+#ifdef HAVE_LIBNUMA_SUPPORT
+ if (mp->affinity != PERF_AFFINITY_SYS &&
cpu__max_node() > 1) {
+ unsigned long node_mask = 1UL <<
cpu__get_node(map->cpu);
+ if (mbind(map->aio.data[i], mmap_len,
MPOL_BIND, &node_mask, 1, 0)) {
+ pr_debug2("failed to bind [%p-%p] to
node %d\n",
+ map->aio.data[i],
map->aio.data[i] + mmap_len,
+ cpu__get_node(map->cpu));
+ }
+ }
+#endif
/*
* Use cblock.aio_fildes value different from -1
* to denote started aio write operation on the
@@ -209,8 +228,13 @@ static void perf_mmap__aio_munmap(struct perf_mmap *map)
{
int i;
- for (i = 0; i < map->aio.nr_cblocks; ++i)
+ for (i = 0; i < map->aio.nr_cblocks; ++i) {
+#ifndef HAVE_LIBNUMA_SUPPORT
zfree(&map->aio.data[i]);
+#else
+ munmap(map->aio.data[i], perf_mmap__mmap_len(map));
+#endif
+ }
if (map-
RE: [PATCH v1 2/2] usb:cdns3 Add Cadence USB3 DRD Driver
> >> >> + USB_CMD_STMODE | > >> >> + > >> >> + USB_STS_TMODE_SEL(tmode - 1)); > >> > > >> >I'm 90% sure this won't work. There's a reason why we only enter the > >> >requested test mode from status stage. How have you tested this? > >> > > > > What's the reason? > > It can work although the code is a little different with above, I > > tested it using USBxHSETT tool at Windows. > > put a sniffer. Status stage won't complete > Ok, you mean sending test packet during the status completion handler? I will see whether the status stage can complete next time when doing test. > >> >> +irqreturn_t ret = IRQ_NONE; > >> >> +unsigned long flags; > >> >> +u32 reg; > >> >> + > >> >> +priv_dev = cdns->gadget_dev; > >> >> +spin_lock_irqsave(&priv_dev->lock, flags); > >> > > >> >you're already running in hardirq context. Why do you need this lock > >> >at all? I would be better to use the hardirq handler to mask your > >> >interrupts, so they don't fire again, then used the top-half > >> >(softirq) handler to actually handle the interrupts. > >> > > > > This controller may be ran at SMP environment, register and flag > > access needs to be protected among CPUs running. > > in hardirq context? When interrupts are already disabled? Interrupt handler (hardirq context) at CPU0, and process at CPU1, eg role switch, unload module, etc. Peter
Re: working toolchain for c-sky
On Tue, Dec 11, 2018 at 11:57:15AM -0800, Guenter Roeck wrote: > Hi, > > can someone point me to a working c-sky toolchain ? > > I tried several from https://github.com/c-sky/tools/, but they all fail > to build csky:defconfig with various error messages. Try this: https://gitlab.com/c-sky/buildroot/-/jobs/131973812/artifacts/browse/output/images/ See readme.txt for run. Best Regards Guo Ren
[PATCH v1 0/3] Reduce NUMA related overhead in perf record profiling on large server systems
It has been observed that trace reading thread runs on the same hw thread most of the time during perf record sampling collection. This scheduling layout leads up to 30% profiling overhead in case when some cpu intensive workload fully utilizes a large server system with NUMA. Overhead usually arises from remote (cross node) HW and memory references that have much longer latencies than local ones [1]. This patch set implements --affinity option that lowers 30% overhead completely for serial trace streaming (--affinity=cpu) and from 30% to 10% for AIO1 (--aio=1) trace streaming (--affinity=node|cpu). See OVERHEAD section below for more details. Implemented extension provides users with capability to instruct Perf tool to bounce trace reading thread's affinity mask between NUMA nodes (--affinity=node) or assign the thread to the exact cpu (--affinity=cpu) that trace buffer being processed belongs to. The extension brings improvement in case of full system utilization when Perf tool process contends with workload process on cpu cores. In case a system has free cores to execute Perf tool process during profiling the default system scheduling layout induces the lowest overhead. The patch set has been validated on BT benchmark from NAS Parallel Benchmarks [2] running on dual socket, 44 cores, 88 hw threads Broadwell system with kernels v4.4-21-generic (Ubuntu 16.04) and v4.20.0-rc5 (tip perf/core). OVERHEAD: BENCH REPORT BASED ELAPSED TIME BASED v4.20.0-rc5 (tip perf/core): (current) SERIAL-SYS / BASE : 1.27x (14.37/11.31), 1.29x (15.19/11.69) SERIAL-NODE / BASE : 1.15x (13.04/11.31), 1.17x (13.79/11.69) SERIAL-CPU / BASE : 1.00x (11.32/11.31), 1.01x (11.89/11.69) AIO1-SYS/ BASE : 1.29x (14.58/11.31), 1.29x (15.26/11.69) AIO1-NODE / BASE : 1.08x (12.23/11.31), 1,11x (13.01/11.69) AIO1-CPU/ BASE : 1.07x (12.14/11.31), 1.08x (12.83/11.69) v4.4.0-21-generic (Ubuntu 16.04 LTS): (current) SERIAL-SYS / BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) SERIAL-NODE / BASE : 1.19x (13.02/10.87), 1.23x (14.03/11.32) SERIAL-CPU / BASE : 1.03x (11.21/10.87), 1.07x (12.18/11.32) AIO1-SYS/ BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) AIO1-NODE / BASE : 1.10x (12.04/10.87), 1.15x (13.03/11.32) AIO1-CPU/ BASE : 1.12x (12.20/10.87), 1.15x (13.09/11.32) The patch set is generated for acme perf/core repository. --- Alexey Budankov (3): perf record: allocate affinity masks perf record: apply affinity masks when reading mmap buffers perf record: implement --affinity=node|cpu option tools/perf/Documentation/perf-record.txt | 5 +++ tools/perf/builtin-record.c | 38 +- tools/perf/perf.h| 5 +++ tools/perf/util/evlist.c | 10 -- tools/perf/util/evlist.h | 2 +- tools/perf/util/mmap.c | 40 +++- tools/perf/util/mmap.h | 4 ++- 7 files changed, 97 insertions(+), 7 deletions(-) --- [1] https://en.wikipedia.org/wiki/Non-uniform_memory_access [2] https://www.nas.nasa.gov/publications/npb.html [3] http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html [4] http://man7.org/linux/man-pages/man2/mbind.2.html --- ENVIRONMENT AND MEASUREMENTS: MACHINE: broadwell, dual socket, 44 core, 88 threads /proc/cpuinfo processor : 87 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz stepping: 1 microcode : 0xb19 cpu MHz : 1200.117 cache size : 56320 KB physical id : 1 siblings: 44 core id : 28 cpu cores : 22 apicid : 121 initial apicid : 121 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts bugs: bogomips: 4391.42 clflush size: 64 cache_al
RE: [PATCH] dt-bindings: timer: gpt: update binding doc
Hi, Rob
Best Regards!
Anson Huang
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2018年12月12日 5:35
> To: Anson Huang
> Cc: daniel.lezc...@linaro.org; t...@linutronix.de; mark.rutl...@arm.com;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; dl-linux-imx
>
> Subject: Re: [PATCH] dt-bindings: timer: gpt: update binding doc
>
> On Fri, Nov 23, 2018 at 09:10:09AM +, Anson Huang wrote:
> > The i.MX GPT timer driver binding doc is out of date, the
> > "interrupts", "clocks" and "clock-names" do NOT match current GPT
> > driver implementation, update it and use i.MX6SX as example.
> >
> > Signed-off-by: Anson Huang
> > ---
> > .../devicetree/bindings/timer/fsl,imxgpt.txt | 22
> +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> > b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> > index 9809b11..4e9fa16 100644
> > --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> > +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> > @@ -2,17 +2,21 @@ Freescale i.MX General Purpose Timer (GPT)
> >
> > Required properties:
> >
> > -- compatible : should be "fsl,-gpt"
> > -- reg : Specifies base physical address and size of the registers.
> > -- interrupts : A list of 4 interrupts; one per timer channel.
> > -- clocks : The clocks provided by the SoC to drive the timer.
> > +- compatible : should be "fsl,-gpt".
>
> This should enumerate valid values.
Agree, I list all the available compatible strings in GPT driver here in V2
patch.
>
> > +- reg : specifies base physical address and size of the registers.
> > +- interrupts : should be the clock event device interrupt.
> > +- clocks : the clocks provided by the SoC to drive the timer, must contain
> > + an entry for each entry in clock-names.
> > +- clock-names : must include an "per" or "osc_per" entry, and "ipg" entry
> > +is optional according to SoC design.
>
> Need to define the order. Ideally the optional clock should be last, but
> that's
> not what the example has.
Current GPT driver does NOT have the order requirement since it all gets clk by
name, but
I think specifying the order is better, I update it in V2 patch.
>
> >
> > Example:
> >
> > -gpt1: timer@10003000 {
> > - compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
> > - reg = <0x10003000 0x1000>;
> > - interrupts = <26>;
> > - clocks = <&clks 46>, <&clks 61>;
> > +gpt: gpt@2098000 {
>
> timer@...
>
> > + compatible = "fsl,imx6sx-gpt", "fsl,imx31-gpt";
>
> You haven't documented "fsl,imx31-gpt" is a valid fallback. Is the old example
> not still valid for imx27?
>
> > + reg = <0x02098000 0x4000>;
>
> Using a size > 4KB just wastes virtual space which is valuable on 32-bit
> systems
> with >= 1GB RAM.
I forgot that old example is still valid, so I will just use old example here,
but the old
example of i.MX27 GPT already NOT match with latest i.MX27 dtsi GPT node, I
update
it with latest GPT node in i.MX27 dtsi in V2 patch, please help review it,
thanks.
Anson.
>
> > + interrupts = ;
> > + clocks = <&clks IMX6SX_CLK_GPT_BUS>,
> > +<&clks IMX6SX_CLK_GPT_3M>;
> > clock-names = "ipg", "per";
> > };
> > --
> > 2.7.4
> >
[PATCH V2] dt-bindings: timer: gpt: update binding doc
The i.MX GPT timer driver binding doc is out of date,
update it according to current GPT timer driver.
Signed-off-by: Anson Huang
---
.../devicetree/bindings/timer/fsl,imxgpt.txt | 28 +-
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
index 9809b11..2ed84ad 100644
--- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
@@ -2,17 +2,33 @@ Freescale i.MX General Purpose Timer (GPT)
Required properties:
-- compatible : should be "fsl,-gpt"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : A list of 4 interrupts; one per timer channel.
-- clocks : The clocks provided by the SoC to drive the timer.
+- compatible : must be one of following:
+ - "fsl,imx1-gpt",
+ - "fsl,imx21-gpt",
+ - "fsl,imx27-gpt",
+ - "fsl,imx31-gpt",
+ - "fsl,imx25-gpt",
+ - "fsl,imx50-gpt",
+ - "fsl,imx51-gpt",
+ - "fsl,imx53-gpt",
+ - "fsl,imx6q-gpt",
+ - "fsl,imx6dl-gpt",
+ - "fsl,imx6sl-gpt",
+ - "fsl,imx6sx-gpt".
+- reg : specifies base physical address and size of the registers.
+- interrupts : should be the clock event device interrupt.
+- clocks : the clocks provided by the SoC to drive the timer, must contain
+ an entry for each entry in clock-names.
+- clock-names : must include "ipg" entry first, then "per" entry, "osc_per"
+can be a substitute of "per" entry on some SoCs.
Example:
gpt1: timer@10003000 {
- compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+ compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
reg = <0x10003000 0x1000>;
interrupts = <26>;
- clocks = <&clks 46>, <&clks 61>;
+ clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
+<&clks IMX27_CLK_PER1_GATE>;
clock-names = "ipg", "per";
};
--
2.7.4
Re: [PATCH v3] powerpc: implement CONFIG_DEBUG_VIRTUAL
Le 12/12/2018 à 01:23, Michael Ellerman a écrit :
Christophe Leroy writes:
This patch implements CONFIG_DEBUG_VIRTUAL to warn about
incorrect use of virt_to_phys() and page_to_phys()
Below is the result of test_debug_virtual:
[1.438746] WARNING: CPU: 0 PID: 1 at ./arch/powerpc/include/asm/io.h:808
test_debug_virtual_init+0x3c/0xd4
[1.448156] CPU: 0 PID: 1 Comm: swapper Not tainted
4.20.0-rc5-00560-g6bfb52e23a00-dirty #532
[1.457259] NIP: c066c550 LR: c0650ccc CTR: c066c514
[1.462257] REGS: c900bdb0 TRAP: 0700 Not tainted
(4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[1.471184] MSR: 00029032 CR: 48000422 XER: 2000
[1.477811]
[1.477811] GPR00: c0650ccc c900be60 c60d 006000c0 c900
9032 c7fa0020
[1.477811] GPR08: 2400 0001 0900 c07b5d04
c00037d8
[1.477811] GPR16: c076 c074
0092 c0685bb0
[1.477811] GPR24: c065042c c068a734 c0685b8c 0006 c076
c075c3c0
[1.512711] NIP [c066c550] test_debug_virtual_init+0x3c/0xd4
[1.518315] LR [c0650ccc] do_one_initcall+0x8c/0x1cc
[1.523163] Call Trace:
[1.525595] [c900be60] [c0567340] 0xc0567340 (unreliable)
[1.530954] [c900be90] [c0650ccc] do_one_initcall+0x8c/0x1cc
[1.536551] [c900bef0] [c0651000] kernel_init_freeable+0x1f4/0x2cc
[1.542658] [c900bf30] [c00037ec] kernel_init+0x14/0x110
[1.547913] [c900bf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[1.553971] Instruction dump:
[1.556909] 3ca50100 bfa10024 54a5000e 3fa0c076 7c0802a6 3d454000 813dc204
554893be
[1.564566] 7d294010 7d294910 90010034 39290001 <0f09> 7c3e0b78 955e0008
3fe0c062
[1.572425] ---[ end trace 6f6984225b280ad6 ]---
[1.577467] PA: 0x0900 for VA: 0xc900
[1.581799] PA: 0x061e8f50 for VA: 0xc61e8f50
Signed-off-by: Christophe Leroy
---
v3: Added missing linux/mm.h
I realised that a driver may use DMA on stack after checking with
virt_addr_valid(), so the new
verification might induce false positives. I remove it for now, will add
it again later in a more
controled way.
What is this comment referring to?
I can't see any difference to v2 except the linux/mm.h include.
v2 was:
@@ -804,6 +806,11 @@ extern void __iounmap_at(void *ea, unsigned long size);
*/
static inline unsigned long virt_to_phys(volatile void * address)
{
+ if (IS_ENABLED(CONFIG_DEBUG_VIRTUAL) &&
+ !WARN_ON(IS_ENABLED(CONFIG_HAVE_ARCH_VMAP_STACK) && current->pid &&
+object_is_on_stack((const void*)address)))
+ WARN_ON(!virt_addr_valid(address));
+
return __pa((unsigned long)address);
}
v3 is: (same as v1)
@@ -804,6 +806,8 @@ extern void __iounmap_at(void *ea, unsigned long size);
*/
static inline unsigned long virt_to_phys(volatile void * address)
{
+ WARN_ON(IS_ENABLED(CONFIG_DEBUG_VIRTUAL) && !virt_addr_valid(address));
+
return __pa((unsigned long)address);
}
The idea in v2 was to detect objects on stack used for DMA before
activating CONFIG_VMAP_STACK, but if the driver uses virt_addr_valid()
to decide if it can DMA map it, then we'll get false positives.
So I think this should be added with a dedicated DEBUG CONFIG option,
not implicitely.
Christophe
Re: [PATCH 5/5] i2c: mediatek: Add i2c compatible for MediaTek MT8183
On Mon, 2018-12-03 at 21:49 -0800, Sean Wang wrote:
> 於 2018年12月3日 週一 上午5:34寫道：
> >
> > From: qii wang
> >
> > Add i2c compatible for MT8183. Compare to 2712 i2c controller, MT8183 has
> > different registers, offsets, clock, and multi-user function.
> >
> > Signed-off-by: qii wang
> > ---
> > drivers/i2c/busses/i2c-mt65xx.c | 136
> > +--
> > 1 file changed, 130 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-mt65xx.c
> > b/drivers/i2c/busses/i2c-mt65xx.c
> > index 428ac99..6b979ab 100644
> > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > @@ -35,17 +35,23 @@
> > #include
> >
> > #define I2C_RS_TRANSFER(1 << 4)
> > +#define I2C_ARB_LOST (1 << 3)
>
> it seems no one refers to the macro in the patch so it should be
> better to be removed
>
ok, I miss it, I will use it in the next patch.
> > #define I2C_HS_NACKERR (1 << 2)
> > #define I2C_ACKERR (1 << 1)
> > #define I2C_TRANSAC_COMP (1 << 0)
> > #define I2C_TRANSAC_START (1 << 0)
> > +#define I2C_RESUME_ARBIT (1 << 1)
> > #define I2C_RS_MUL_CNFG(1 << 15)
> > #define I2C_RS_MUL_TRIG(1 << 14)
> > +#define I2C_HS_TIME_EN (1 << 7)
> > #define I2C_DCM_DISABLE0x
> > #define I2C_IO_CONFIG_OPEN_DRAIN 0x0003
> > #define I2C_IO_CONFIG_PUSH_PULL0x
> > #define I2C_SOFT_RST 0x0001
> > #define I2C_FIFO_ADDR_CLR 0x0001
> > +#define I2C_FIFO_ADDR_CLRH 0x0002
> > +#define I2C_FIFO_ADDR_CLR_MCH 0x0004
> > +#define I2C_HFIFO_DATA 0x8208
> > #define I2C_DELAY_LEN 0x0002
> > #define I2C_ST_START_CON 0x8001
> > #define I2C_FS_START_CON 0x1800
> > @@ -76,6 +82,8 @@
> > #define I2C_CONTROL_DIR_CHANGE (0x1 << 4)
> > #define I2C_CONTROL_ACKERR_DET_EN (0x1 << 5)
> > #define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
> > +#define I2C_CONTROL_DMAACK_EN (0x1 << 8)
> > +#define I2C_CONTROL_ASYNC_MODE (0x1 << 9)
> > #define I2C_CONTROL_WRAPPER (0x1 << 0)
> >
> > #define I2C_DRV_NAME "i2c-mt65xx"
> > @@ -130,6 +138,15 @@ enum I2C_REGS_OFFSET {
> > OFFSET_DEBUGCTRL,
> > OFFSET_TRANSFER_LEN_AUX,
> > OFFSET_CLOCK_DIV,
> > + /* MT8183 only regs */
> > + OFFSET_LTIMING,
> > + OFFSET_DATA_TIMING,
> > + OFFSET_MCU_INTR,
> > + OFFSET_HW_TIMEOUT,
> > + OFFSET_HFIFO_DATA,
> > + OFFSET_HFIFO_STAT,
> > + OFFSET_MULTI_DMA,
> > + OFFSET_ROLLBACK,
> > };
> >
> > static const u16 mt_i2c_regs_v1[] = {
> > @@ -159,6 +176,39 @@ enum I2C_REGS_OFFSET {
> > [OFFSET_CLOCK_DIV] = 0x70,
> > };
> >
> > +static const u16 mt_i2c_regs_v2[] = {
> > + [OFFSET_DATA_PORT] = 0x0,
> > + [OFFSET_SLAVE_ADDR] = 0x4,
> > + [OFFSET_INTR_MASK] = 0x8,
> > + [OFFSET_INTR_STAT] = 0xc,
> > + [OFFSET_CONTROL] = 0x10,
> > + [OFFSET_TRANSFER_LEN] = 0x14,
> > + [OFFSET_TRANSAC_LEN] = 0x18,
> > + [OFFSET_DELAY_LEN] = 0x1c,
> > + [OFFSET_TIMING] = 0x20,
> > + [OFFSET_START] = 0x24,
> > + [OFFSET_EXT_CONF] = 0x28,
> > + [OFFSET_LTIMING] = 0x2c,
> > + [OFFSET_HS] = 0x30,
> > + [OFFSET_IO_CONFIG] = 0x34,
> > + [OFFSET_FIFO_ADDR_CLR] = 0x38,
> > + [OFFSET_DATA_TIMING] = 0x3c,
> > + [OFFSET_MCU_INTR] = 0x40,
> > + [OFFSET_TRANSFER_LEN_AUX] = 0x44,
> > + [OFFSET_CLOCK_DIV] = 0x48,
> > + [OFFSET_HW_TIMEOUT] = 0x4c,
> > + [OFFSET_SOFTRESET] = 0x50,
> > + [OFFSET_HFIFO_DATA] = 0x70,
> > + [OFFSET_DEBUGSTAT] = 0xe0,
> > + [OFFSET_DEBUGCTRL] = 0xe8,
> > + [OFFSET_FIFO_STAT] = 0xf4,
> > + [OFFSET_FIFO_THRESH] = 0xf8,
> > + [OFFSET_HFIFO_STAT] = 0xfc,
> > + [OFFSET_DCM_EN] = 0xf88,
> > + [OFFSET_MULTI_DMA] = 0xf8c,
> > + [OFFSET_ROLLBACK] = 0xf98,
> > +};
> > +
> > struct mtk_i2c_compatible {
> > const struct i2c_adapter_quirks *quirks;
> > const u16 *regs;
> > @@ -168,6 +218,7 @@ struct mtk_i2c_compatible {
> > unsigned char aux_len_reg: 1;
> > unsigned char support_33bits: 1;
> > unsigned char timing_adjust: 1;
> > + unsigned char dma_sync: 1;
> > };
> >
> > struct mtk_i2c {
> > @@ -181,8 +232,11 @@ struct mtk_i2c {
> > struct clk *clk_main; /* main clock for i2c bus */
> > struct clk *clk_dma;/* DMA clock for i2c via DMA */
> > struct clk *clk_pmic; /* PMIC clock for i2c from PMIC */
> > + struct clk *clk_arb;/* Arbitrator clock for i2c */
> > bool have_pmic; /* can use i2c pins from PMIC */
> > bool use_pus
Re: [PATCH 4.4 00/91] 4.4.167-stable review
On Tue, 11 Dec 2018 at 21:15, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.167 release. > There are 91 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 13 15:15:44 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.167-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Simon Guo > mm: mlock: avoid increase mm->locked_vm on mlock() when already > mlock2(,MLOCK_ONFAULT) Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. NOTE: LTP syscalls: mlock203 is been fixed on all devices. Summary kernel: 4.4.167-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 216a0be637b7dbf8db4aaad9810aba4ab15bb09c git describe: v4.4.166-92-g216a0be637b7 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.166-92-g216a0be637b7 No regressions (compared to build v4.4.166) Fixes (compared to build v4.4.166) --- LTP syscalls: mlock203 is been fixed on all devices. Ran 16912 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * install-android-platform-tools-r2600 * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.167-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.167-rc1-hikey-20181211-336 git commit: 904b62a2cb83665c4b38251201582a4f55649b7f git describe: 4.4.167-rc1-hikey-20181211-336 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.167-rc1-hikey-20181211-336 No regressions (compared to build 4.4.167-rc1-hikey-20181209-335) No fixes (compared to build 4.4.167-rc1-hikey-20181209-335) Ran 2748 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.19 051/118] flexfiles: use per-mirror specified stateid for IO
On Tue, Dec 11, 2018 at 07:49:27PM +0100, Mkrtchyan, Tigran wrote: > > > Hi Greg, > > Thanks for pushing this into sable as well. However, I think patch makes more > sense > with 320f35b7bf8cccf1997ca3126843535e1b95e9c4 I need an ack from the nfs maintainer before I can do that...
Re: [PATCH 4.19 000/118] 4.19.9-stable review
On Tue, Dec 11, 2018 at 05:03:49PM -0700, shuah wrote: > On 12/11/18 8:40 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.9 release. > > There are 118 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Dec 13 15:16:10 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.9-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.19.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: use generic DMA mapping code in powerpc V4
> On 12. Dec 2018, at 01:47, Benjamin Herrenschmidt > wrote: > >> On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote: >> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the >> kernel starts but it doesn't find any hard disks (partitions). That >> means this is also the bad commit for the P5020 board. > > What are the disks hanging off ? A PCIe device of some sort ? > > Can you send good & bad dmesg logs ? > > Ben. > > Unfortunately not. It doesn’t detect any hard disk. That means the kernel ring buffer won’t save to log files. I don’t have a serial null modem cable for seeing all output. We use SATA disks. I will investigate more in this problem with rollback the files in the bad commit. — Christian
[PATCH v3] lzo: fix ip overrun during compress.
It`s possible ip overrun in lzo1x_1_do_compress() when compressed page is
point to the end of memory and which virtual address is 0xf000.
Leading to a NULL pointer access during the get_unaligned_le32(ip).
Fix this panic:
[ 2738.034508] Unable to handle kernel NULL pointer dereference at virtual
address 0009
[ 2738.034515] Mem abort info:
[ 2738.034518] Exception class = DABT (current EL), IL = 32 bits
[ 2738.034520] SET = 0, FnV = 0
[ 2738.034523] EA = 0, S1PTW = 0
[ 2738.034524] FSC = 5
[ 2738.034526] Data abort info:
[ 2738.034528] ISV = 0, ISS = 0x0005
[ 2738.034530] CM = 0, WnR = 0
[ 2738.034533] user pgtable: 4k pages, 39-bit VAs, pgd = 94cee000
[ 2738.034535] [0009] *pgd=, *pud=
...
[ 2738.034592] pc : lzo1x_1_do_compress+0x198/0x610
[ 2738.034595] lr : lzo1x_1_compress+0x98/0x3d8
[ 2738.034597] sp : ff801caa3470 pstate : 00c00145
[ 2738.034598] x29: ff801caa3500 x28: 1000
[ 2738.034601] x27: 1000 x26: f000
[ 2738.034604] x25: 4ebc x24:
[ 2738.034607] x23: 004c x22: f7b8
[ 2738.034610] x21: 2e2ee0b3 x20: 2e2ee0bb
[ 2738.034612] x19: 0fcc x18: f84a
[ 2738.034615] x17: 801b03d6 x16: 0782
[ 2738.034618] x15: 2e2ee0bf x14: fff0
[ 2738.034620] x13: 000f x12: 0020
[ 2738.034623] x11: 1824429d x10: ffec
[ 2738.034626] x9 : 0009 x8 :
[ 2738.034628] x7 : 0868 x6 : 0434
[ 2738.034631] x5 : 4ebc x4 :
[ 2738.034633] x3 : ff801caa3510 x2 : 2e2ee000
[ 2738.034636] x1 : x0 : f000
...
[ 2738.034717] Process kworker/u16:1 (pid: 8705, stack limit =
0xff801caa)
[ 2738.034720] Call trace:
[ 2738.034722] lzo1x_1_do_compress+0x198/0x610
[ 2738.034725] lzo_compress+0x48/0x88
[ 2738.034729] crypto_compress+0x14/0x20
[ 2738.034733] zcomp_compress+0x2c/0x38
[ 2738.034736] zram_bvec_rw+0x3d0/0x860
[ 2738.034738] zram_rw_page+0x88/0xe0
[ 2738.034742] bdev_write_page+0x70/0xc0
[ 2738.034745] __swap_writepage+0x58/0x3f8
[ 2738.034747] swap_writepage+0x40/0x50
[ 2738.034750] shrink_page_list+0x4fc/0xe58
[ 2738.034753] reclaim_pages_from_list+0xa0/0x150
[ 2738.034756] reclaim_pte_range+0x18c/0x1f8
[ 2738.034759] __walk_page_range+0xf8/0x1e0
[ 2738.034762] walk_page_range+0xf8/0x130
[ 2738.034765] reclaim_task_anon+0xcc/0x168
[ 2738.034767] swap_fn+0x438/0x668
[ 2738.034771] process_one_work+0x1fc/0x460
[ 2738.034773] worker_thread+0x2d0/0x478
[ 2738.034775] kthread+0x110/0x120
[ 2738.034778] ret_from_fork+0x10/0x18
[ 2738.034781] Code: 3800167f 54a8 d100066f 1431 (b9400131)
[ 2738.034784] ---[ end trace 9b5cca106f0e54d1 ]---
[ 2738.035473] Kernel panic - not syncing: Fatal exception
crash> dis lzo1x_1_do_compress+100 3 -l
../kernel/msm-4.14/lib/lzo/lzo1x_compress.c: 44
0xff8dec8c6af4 : cmp x9, x10
0xff8dec8c6af8 : b.cc0xff8dec8c6c28
0xff8dec8c6afc : b 0xff8dec8c7094
crash> dis lzo1x_1_do_compress+0x198
0xff8dec8c6c28 : ldr w17, [x9]
ip = x9 = 0x0009 is overflow.
Signed-off-by: liyueyi
---
Changes in v3: Check overflow in lzo1x_1_compress.
Changes in v2: Re-define OVERFLOW_ADD_CHEK.
lib/lzo/lzo1x_compress.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c
index 236eb21..959dec4 100644
--- a/lib/lzo/lzo1x_compress.c
+++ b/lib/lzo/lzo1x_compress.c
@@ -224,8 +224,8 @@ int lzo1x_1_compress(const unsigned char *in, size_t in_len,
while (l > 20) {
size_t ll = l <= (M4_MAX_OFFSET + 1) ? l : (M4_MAX_OFFSET + 1);
- uintptr_t ll_end = (uintptr_t) ip + ll;
- if ((ll_end + ((t + ll) >> 5)) <= ll_end)
+ // check for address space wraparound
+ if (((uintptr_t) ip + ll + ((t + ll) >> 5)) <= (uintptr_t) ip)
break;
BUILD_BUG_ON(D_SIZE * sizeof(lzo_dict_t) >
LZO1X_1_MEM_COMPRESS);
memset(wrkmem, 0, D_SIZE * sizeof(lzo_dict_t));
--
2.7.4
Re: [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device
On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>>> I find some pass-thru devices don't work any more across guest reboot.
>>> Assigning it to another guest also meets the same issue. And the only
>>> way to make it work again is un-binding and binding it to pciback.
>>> Someone reported this issue one year ago [1]. More detail also can be
>>> found in [2].
>>>
>>> The root-cause is Xen's internal MSI-X state isn't reset properly
>>> during reboot or re-assignment. In the above case, Xen set maskall bit
>>> to mask all MSI interrupts after it detected a potential security
>>> issue. Even after device reset, Xen didn't reset its internal maskall
>>> bit. As a result, maskall bit would be set again in next write to
>>> MSI-X message control register.
>>>
>>> Given that PHYSDEVOPS_prepare_msix() also triggers Xen resetting MSI-X
>>> internal state of a device, we employ it to fix this issue rather than
>>> introducing another dedicated sub-hypercall.
>>>
>>> Note that PHYSDEVOPS_release_msix() will fail if the mapping between
>>> the device's msix and pirq has been created. This limitation prevents
>>> us calling this function when detaching a device from a guest during
>>> guest shutdown. Thus it is called right before calling
>>> PHYSDEVOPS_prepare_msix().
>> s/PHYSDEVOPS/PHYSDEVOP/ (no final S). And then I would also drop the
>> () at the end of the hypercall name since it's not a function.
>>
>> I'm also wondering why the release can't be done when the device is
>> detached from the guest (or the guest has been shut down). This makes
>> me worry about the raciness of the attach/detach procedure: if there's
>> a state where pciback assumes the device has been detached from the
>> guest, but there are still pirqs bound, an attempt to attach to
>> another guest in such state will fail.
>
>I wonder whether this additional reset functionality could be done out
>of xen_pcibk_xenbus_remove(). We first do a (best effort) device reset
>and then do the extra things that are not properly done there.
No. It cannot be done in xen_pcibk_xenbus_remove() without modifying
the handler of PHYSDEVOP_release_msix. To do a successful Xen internal
MSI-X state reset, PHYSDEVOP_{release, prepare}_msix should be finished
without error. But ATM, xen expects that no msi is bound to pirq when
doing PHYSDEVOP_release_msix. Otherwise it fails with error code -EBUSY.
However, the expectation isn't guaranteed in xen_pcibk_xenbus_remove().
In some cases, if qemu fails to unmap MSIs, MSIs are unmapped by Xen
at last minute, which happens after device reset in xen_pcibk_xenbus_remove().
Thanks
Chao
Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple endpoints per port
Hi Tony, again
> > > https://patchwork.kernel.org/patch/10712877/
> >
> > Hmm, so do you have multiple separate ports at the "&sound" node
> > hardware? If so then yeah multiple ports make sense.
> >
> > But if you only a single physical (I2S?) port at the
> > "&sound" node hardware, then IMO you should only have one
> > port and multiple endpoints there according to the graph.txt
> > binding doc.
> >
> > In my McBSP case there is only a single physical I2S port
> > that can be TDM split into timeslots.
>
> Mine has 4 DAIs. Each DAI can output 2ch.
> These will be merged and wil be 8ch TDM and goes to Codec.
> But hmm.. it is 4 DAIs, but 1 "physical" interface...
>
> So, your patch seems correct, but will breaks DPCM...
> I will confirm it.
I thought "port" = "DAI", but yeah, "port" = "physical interface".
Then, my issue is that we can't judge DAI size from DT.
For example, MIXer case, 2 CPU DAIs are connected to 1 Codec.
DAI0 --- CPU --- Codec
DAI1 /
In this case, CPU side needs 2 DAIs,
Codec side needs 1 DAI only.
For both CPU/Codec case, OF graph will be like below,
and we can't judge DAIs size from this.
port {
ep0: endpint@0 {
remote-endpoint = ;
};
ep1: endpint@1 {
remote-endpoint = ;
};
}
To solve this issue, we need to use "reg" for it.
Then, we can get correct DAI ID.
/* CPU has 2 DAIs */
CPU {
port {
ep0: endpint@0 {
reg = <0>;
remote-endpoint = ;
};
ep1: endpint@1 {
reg = <1>;
remote-endpoint = ;
};
};
}
/* Codec has 1 DAI */
Codec {
port {
reg = <0>;
ep0: endpint@0 {
remote-endpoint = ;
};
ep1: endpint@1 {
remote-endpoint = ;
};
};
}
Can you agree this ? we need extra patch,
but it can solve your / my problem.
Now I'm posting patches to merging
"audio-graph-card" and "DPCM ver audio-graph-card".
If you are OK, I will include above solution patch
to this patch-set.
Current audio-graph doesn't expect your use-case,
and I want to avoid conflict.
So, "merged" audio-graph should solve your use-case.
If you can agree about this, I will post patch-set.
Best regards
---
Kuninori Morimoto
Re: [PATCH v1 2/2] usb:cdns3 Add Cadence USB3 DRD Driver
Peter Chen writes:
>> >> +tmode = le16_to_cpu(ctrl->wIndex);
>> >> +
>> >> +if (!set || (tmode & 0xff) != 0)
>> >> +return -EINVAL;
>> >> +
>> >> +switch (tmode >> 8) {
>> >> +case TEST_J:
>> >> +case TEST_K:
>> >> +case TEST_SE0_NAK:
>> >> +case TEST_PACKET:
>> >> +cdns3_set_register_bit(&priv_dev->regs->usb_cmd,
>> >> + USB_CMD_STMODE |
>> >> + USB_STS_TMODE_SEL(tmode - 1));
>> >
>> >I'm 90% sure this won't work. There's a reason why we only enter the
>> >requested test mode from status stage. How have you tested this?
>>
>
> What's the reason?
> It can work although the code is a little different with above, I
> tested it using USBxHSETT tool at Windows.
put a sniffer. Status stage won't complete
>> >> +irqreturn_t ret = IRQ_NONE;
>> >> +unsigned long flags;
>> >> +u32 reg;
>> >> +
>> >> +priv_dev = cdns->gadget_dev;
>> >> +spin_lock_irqsave(&priv_dev->lock, flags);
>> >
>> >you're already running in hardirq context. Why do you need this lock at
>> >all? I would be better to use the hardirq handler to mask your
>> >interrupts, so they don't fire again, then used the top-half (softirq)
>> >handler to actually handle the interrupts.
>>
>
> This controller may be ran at SMP environment, register and flag access
> needs to be protected among CPUs running.
in hardirq context? When interrupts are already disabled?
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v10 2/3] x86: add support for Huawei WMI hotkeys.
On Tue, 11 Dec 2018 21:10:07 +0100, wrote: > > > Do I need to resubmit? Yes, please. Andy, I think it's better to merge the series through my tree, as it uses the new leds audio trigger stuff. Could you give ACK if the revised one is OK? Then I'll merge them to the immutable branch topic/leds-trigger, so that you can merge to your tree cleanly, too. thanks, Takashi
RE: [PATCH v1 2/2] usb:cdns3 Add Cadence USB3 DRD Driver
Hi
Pawel Laszczak writes:
>>> + cdns->phy = devm_phy_get(dev, "cdns3,usbphy");
>>> + if (IS_ERR(cdns->phy)) {
>>> + ret = PTR_ERR(cdns->phy);
>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>
>>Are you sure you can get ENOSYS here? Have you checked output of
>>checkpatch --strict?
>>-:852: WARNING: ENOSYS means 'invalid syscall nr' and nothing else
>
> Yes this error code can be returned by related to phy function if
> CONFIG_GENERIC_PHY is disabled.
>
> I have seen this warning in output of checkpatch --strict .
Kishon, seems like you shouldn't be using that error value.
>>> + case USB_REQ_SET_ISOCH_DELAY:
>>> + sprintf(str, "Set Isochronous Delay Delay: %d ns", wValue);
>>> + break;
>>> + default:
>>> + sprintf(str,
>>> + "SETUP BRT: %02x BR: %02x V: %04x I: %04x L: %04x\n",
>>> + bRequestType, bRequest,
>>> + wValue, wIndex, wLength);
>>> + }
>>> +
>>> + return str;
>>> +}
>>
>>All of these are a flat out copy of dwc3's implementation. It's much,
>>much better to turn dwc3's implementation into a generic, reusable
>>library function then spinning your own as a duplicated effort.
> I agree,
> It would be nice to have a set of decoding function in some generic library.
> It could be used
> also by other drivers.
> Who should do this ?
since you're the first to reuse it, then it should be you :-)
>>> +static int cdns3_req_ep0_set_configuration(struct cdns3_device *priv_dev,
>>> + struct usb_ctrlrequest *ctrl_req)
>>> +{
>>> + enum usb_device_state device_state = priv_dev->gadget.state;
>>> + struct cdns3_endpoint *priv_ep;
>>> + u32 config = le16_to_cpu(ctrl_req->wValue);
>>> + int result = 0;
>>> + int i;
>>> +
>>> + switch (device_state) {
>>> + case USB_STATE_ADDRESS:
>>> + /* Configure non-control EPs */
>>> + for (i = 0; i < CDNS3_ENDPOINTS_MAX_COUNT; i++) {
>>> + priv_ep = priv_dev->eps[i];
>>> + if (!priv_ep)
>>> + continue;
>>> +
>>> + if (priv_ep->flags & EP_CLAIMED)
>>> + cdns3_ep_config(priv_ep);
>>> + }
>>> +
>>> + result = cdns3_ep0_delegate_req(priv_dev, ctrl_req);
>>> +
>>> + if (result)
>>> + return result;
>>> +
>>> + if (config) {
>>> + cdns3_set_hw_configuration(priv_dev);
>>> + } else {
>>> + cdns3_gadget_unconfig(priv_dev);
>>> + usb_gadget_set_state(&priv_dev->gadget,
>>> +USB_STATE_ADDRESS);
>>
>>this is wrong. If address is zero, state should be default, not
>>addressed. Addressed would be used on the other branch here, when you
>>have a non-zero address
>
> If address is zero then state should be USB_STATE_DEFAULT. Driver
> enters to this branch only if gadget.state = USB_STATE_ADDRESS
> (address != 0). This state can be changed in composite.c file after
> delegating request to gadget driver. Because this state could be
> changed driver simple restore USB_STATE_ADDRESS if config = 0.
nevermind, I read this as being the handler for Set Address. This is Set
Config, instead.
>>> + }
>>> + break;
>>> + case USB_STATE_CONFIGURED:
>>
>>where do you set this state?
> It's set in set_config in composite.c file.
indeed
>>> + case USB_DEVICE_TEST_MODE:
>>> + if (state != USB_STATE_CONFIGURED || speed > USB_SPEED_HIGH)
>>> + return -EINVAL;
>>> +
>>> + tmode = le16_to_cpu(ctrl->wIndex);
>>> +
>>> + if (!set || (tmode & 0xff) != 0)
>>> + return -EINVAL;
>>> +
>>> + switch (tmode >> 8) {
>>> + case TEST_J:
>>> + case TEST_K:
>>> + case TEST_SE0_NAK:
>>> + case TEST_PACKET:
>>> + cdns3_set_register_bit(&priv_dev->regs->usb_cmd,
>>> + USB_CMD_STMODE |
>>> + USB_STS_TMODE_SEL(tmode - 1));
>>
>>I'm 90% sure this won't work. There's a reason why we only enter the
>>requested test mode from status stage. How have you tested this?
>
> From USB spec:
> "The transition to test mode must be complete no later than 3 ms after the
> completion of the status stage of the
> request."
exactly, _after_ completion of status stage :-)
> But I don't remember any issues with this test on other ours
> drivers. Maybe status stage is armed in this case by controller. I
> have to confirm how it works with hardware team. Driver doesn't know
> when status stage was completed. We don't have any event on status
> stage completion. I haven't checked it yet with tester on this
> driver.
Let's consider the scenario where you're requesting Test_Packet mode. If
you start transmitting the test pattern from setup stage, how c
Re: [PATCHv2 net 0/3] net: add support for flex_array_resize in flex_array
From: Xin Long Date: Fri, 7 Dec 2018 14:30:32 +0800 > Without the support for the total_nr_elements's growing or shrinking > dynamically, flex_array is not that 'flexible'. Like when users want > to change the size, they have to redo flex_array_alloc and copy all > the elements from the old to the new one. The worse thing is every > element's memory gets changed. > > To implement flex_array_resize based on current code, the difficult > thing is to process the size border of FLEX_ARRAY_BASE_BYTES_LEFT, > where the base data memory may change to an array for the 2nd level > data memory for growing, likewise for shrinking. > > To make this part easier, we separate the base data memory and define > FLEX_ARRAY_BASE_SIZE as a same value of FLEX_ARRAY_PART_SIZE, as Neil > suggested. When new size is crossing the border, the base memory is > allocated as the array for the 2nd level data memory and its part[0] > is pointed to the old base memory, and do the opposite for shrinking. > > But it doesn't do any memory allocation or shrinking for elements in > flex_array_resize, as which should be done by flex_array_prealloc or > flex_array_shrink called by users. No memory leaks can be caused by > that. > > SCTP has benefited a lot from flex_array_resize() for managing its > stream memory so far. > > v1->v2: > Cc LKML and more developers. So I don't know what to do about this series. One of the responses stated that it has been proposed to remove flex_array and I don't know what to make of that, nor can I tell if that makes this series inappropriate or not.
Re: [PATCH] scatterlist: Update size type to support greater then 4GB size.
struct nvme_sgl_desc {
__le64 addr;
- __le32 length;
+ __le64 length;
__u8rsvd[3];
__u8type;
};
Isn't this a device or protocol defined datastructure? You can't just
change it like this.
You're correct, we can't...
[Replied before seeing this issue was already highlighted]
The positive side is that it can safely be removed without affecting the
rest of the patch...
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
On Wed, Dec 12, 2018 at 03:28:41PM +0900, Sergey Senozhatsky wrote: On (12/11/18 22:08), Daniel Wang wrote: I've been meaning to try it but kept getting distracted by other things. I'll try to find some time for it this week or next. Right now my intent is to get Steven's patch into 4.14 stable as it evidently fixed the particular issue I was seeing, and as Steven said it has been in upstream since 4.16 so it's not like backporting it will raise any red flags. I will start another thread on -stable for it. OK. > I guess we still don't have a really clear understanding of what exactly is going in your system I would also like to get to the bottom of it. Unfortunately I haven't got the expertise in this area nor the time to do it yet. Hence the intent to take a step back and backport Steven's patch to fix the issue that has resurfaced in our production recently. No problem. I just meant that -stable people can be a bit "unconvinced". The -stable people tried adding this patch back in April, but ended up getting complaints up the wazoo (https://lkml.org/lkml/2018/4/9/154) about how this is not -stable material. So yes, testing/acks welcome :) -- Thanks, Sasha
Re: [PATCH] scatterlist: Update size type to support greater then 4GB size.
struct nvme_sgl_desc {
__le64 addr;
- __le32 length;
+ __le64 length;
__u8rsvd[3];
__u8type;
};
in what world changing a wire protocol for this make sense?
please get rid of this hunk, NVMe will never cross the 32 bit sg element
size.
[PATCH] can: flexcan: add TX support for variable payload size
Now the FlexCAN driver always use last mailbox for TX, it will work well
when MB payload size is 8/16 bytes.
TX mailbox would change to 13 when MB payload size is 64 bytes to
support CANFD. So we may need to set iflag register to add support for
variable payload size.
Signed-off-by: Joakim Zhang
---
drivers/net/can/flexcan.c | 42 +--
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 0f36eafe3ac1..13fd085fcf84 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -141,7 +141,9 @@
#define FLEXCAN_TX_MB_RESERVED_OFF_FIFO8
#define FLEXCAN_TX_MB_RESERVED_OFF_TIMESTAMP 0
#define FLEXCAN_RX_MB_OFF_TIMESTAMP_FIRST
(FLEXCAN_TX_MB_RESERVED_OFF_TIMESTAMP + 1)
-#define FLEXCAN_IFLAG_MB(x)BIT((x) & 0x1f)
+#define FLEXCAN_IFLAG1_MB_NUM 32
+#define FLEXCAN_IFLAG1_MB(x) BIT(x)
+#define FLEXCAN_IFLAG2_MB(x) BIT((x) & 0x1f)
#define FLEXCAN_IFLAG_RX_FIFO_OVERFLOW BIT(7)
#define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)
#define FLEXCAN_IFLAG_RX_FIFO_AVAILABLEBIT(5)
@@ -822,9 +824,15 @@ static inline u64 flexcan_read_reg_iflag_rx(struct
flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->regs;
u32 iflag1, iflag2;
- iflag2 = priv->read(®s->iflag2) & priv->reg_imask2_default &
- ~FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
- iflag1 = priv->read(®s->iflag1) & priv->reg_imask1_default;
+ if (priv->tx_mb_idx >= FLEXCAN_IFLAG1_MB_NUM) {
+ iflag2 = priv->read(®s->iflag2) & priv->reg_imask2_default &
+ ~FLEXCAN_IFLAG2_MB(priv->tx_mb_idx);
+ iflag1 = priv->read(®s->iflag1) & priv->reg_imask1_default;
+ } else {
+ iflag2 = priv->read(®s->iflag2) & priv->reg_imask2_default;
+ iflag1 = priv->read(®s->iflag1) & priv->reg_imask1_default &
+ ~FLEXCAN_IFLAG1_MB(priv->tx_mb_idx);
+ }
return (u64)iflag2 << 32 | iflag1;
}
@@ -836,7 +844,8 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->regs;
irqreturn_t handled = IRQ_NONE;
- u32 reg_iflag2, reg_esr;
+ u32 reg_tx_iflag, tx_iflag_idx, reg_esr;
+ void __iomem *reg_iflag;
enum can_state last_state = priv->can.state;
/* reception interrupt */
@@ -870,10 +879,18 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
}
}
- reg_iflag2 = priv->read(®s->iflag2);
+ if (priv->tx_mb_idx >= FLEXCAN_IFLAG1_MB_NUM) {
+ reg_tx_iflag = priv->read(®s->iflag2);
+ tx_iflag_idx = FLEXCAN_IFLAG2_MB(priv->tx_mb_idx);
+ reg_iflag = ®s->iflag2;
+ } else {
+ reg_tx_iflag = priv->read(®s->iflag1);
+ tx_iflag_idx = FLEXCAN_IFLAG1_MB(priv->tx_mb_idx);
+ reg_iflag = ®s->iflag1;
+ }
/* transmission complete interrupt */
- if (reg_iflag2 & FLEXCAN_IFLAG_MB(priv->tx_mb_idx)) {
+ if (reg_tx_iflag & tx_iflag_idx) {
u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
handled = IRQ_HANDLED;
@@ -885,7 +902,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
/* after sending a RTR frame MB is in RX mode */
priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
&priv->tx_mb->can_ctrl);
- priv->write(FLEXCAN_IFLAG_MB(priv->tx_mb_idx), ®s->iflag2);
+ priv->write(tx_iflag_idx, reg_iflag);
netif_wake_queue(dev);
}
@@ -1244,8 +1261,13 @@ static int flexcan_open(struct net_device *dev)
priv->tx_mb_idx = priv->mb_count - 1;
priv->tx_mb = flexcan_get_mb(priv, priv->tx_mb_idx);
- priv->reg_imask1_default = 0;
- priv->reg_imask2_default = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
+ if (priv->tx_mb_idx >= FLEXCAN_IFLAG1_MB_NUM) {
+ priv->reg_imask1_default = 0;
+ priv->reg_imask2_default = FLEXCAN_IFLAG2_MB(priv->tx_mb_idx);
+ } else {
+ priv->reg_imask1_default = FLEXCAN_IFLAG1_MB(priv->tx_mb_idx);
+ priv->reg_imask2_default = 0;
+ }
priv->offload.mailbox_read = flexcan_mailbox_read;
--
2.17.1
Re: [PATCH 4.9 00/51] 4.9.145-stable review
On Tue, 11 Dec 2018 at 21:19, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.145 release. > There are 51 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 13 15:15:52 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.145-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.145-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 8705173bd0fed9cbde3a23f8b1680e9f997d7019 git describe: v4.9.144-52-g8705173bd0fe Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.144-52-g8705173bd0fe No regressions (compared to build v4.9.144) No fixes (compared to build v4.9.144) Ran 21410 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-filecaps-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH V2] kmemleak: Add config to select auto scan
Hi Catalin, Can you mark this patch as acknowledged so that it can be picked up by the maintainer. Adding Andrew. Thanks, On 10/29/2018 4:13 PM, Catalin Marinas wrote: On Mon, Oct 22, 2018 at 11:38:43PM +0530, Prateek Patel wrote: From: Sri Krishna chowdary Kmemleak scan can be cpu intensive and can stall user tasks at times. To prevent this, add config DEBUG_KMEMLEAK_AUTO_SCAN to enable/disable auto scan on boot up. Also protect first_run with DEBUG_KMEMLEAK_AUTO_SCAN as this is meant for only first automatic scan. Signed-off-by: Sri Krishna chowdary Signed-off-by: Sachin Nikam Signed-off-by: Prateek Looks fine to me. Reviewed-by: Catalin Marinas
Re: [PATCH net-next] rhashtable: further improve stability of rhashtable_walk
On Wed, Dec 12 2018, Herbert Xu wrote: > On Wed, Dec 12, 2018 at 11:02:35AM +1100, NeilBrown wrote: >> >> So I think this is a real bug - it is quite unlikely to hit, but >> possibly. >> You need a chain with at least 2 objects, you need >> rhashtable_walk_stop() to be called after visiting an object other than >> the last object, and you need some thread (this or some other) to remove >> that object from the table. >> >> The patch that I posted aims to fix that bug, and only that bug. >> The only alternative that I can think of is to document that this can >> happen and advise that a reference should be held to the last visited >> object when stop/start is called, or in some other way ensure that it >> doesn't get removed. > > Thanks for reminding me of the issue you were trying to fix. > > So going back into the email archives, I suggested at the very > start that we could just insert the walker objects into the actual > hash table. That would solve the issue for both rhashtable and > rhlist. > > Could we do that rather than using this ordered list that only > works for rhashtable? No. that doesn't work. When you remove the walker object from the hash chain, you need to wait for the RCU grace period to expire before you can safely insert back into the chain. Inserting into a different chain isn't quite so bad now that the nulls-marker stuff is working, a lookup thread will notice the move and retry the lookup. So you would substantially slow down the rhashtable_walk_start() step. I've tried to think of various ways to over come this problem, such as walking backwards through each chain - it is fairly safe to move and object earlier in the chain - but all the approaches I have tried make the code much more complex. Thanks, NeilBrown > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt signature.asc Description: PGP signature
[PATCH] platform/x86: dell-wmi: Ignore new keyboard backlight change event
There's a new wmi event generated by dell-wmi when pressing keyboard
backlight hotkey:
[ 3285.474172] dell_wmi: Unknown key with type 0x0010 and code 0x003f pressed
This event is for notification purpose, let's ignore it. The keyboard
backlight hotkey uses another event so it still works without event
0x3f.
Signed-off-by: Kai-Heng Feng
---
drivers/platform/x86/dell-wmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 16c7f3d9a335..c3166ba73e9a 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -267,6 +267,9 @@ static const struct key_entry dell_wmi_keymap_type_0010[] =
{
/* Fn-lock switched to multimedia keys */
{ KE_IGNORE, 0x1, { KEY_RESERVED } },
+ /* Keyboard backlight change notification */
+ { KE_IGNORE, 0x3f, { KEY_RESERVED } },
+
/* Mic mute */
{ KE_KEY, 0x150, { KEY_MICMUTE } },
--
2.17.1
Re: [PATCH 4.14 00/67] 4.14.88-stable review
On Tue, 11 Dec 2018 at 21:22, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.88 release. > There are 67 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 13 15:16:01 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.88-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.14.88-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 9557e80a8f28e6bae4083dcc7dc6c2d1cb38d758 git describe: v4.14.87-68-g9557e80a8f28 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.87-68-g9557e80a8f28 No regressions (compared to build v4.14.87) No fixes (compared to build v4.14.87) Ran 21572 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
linux-next: Tree for Dec 12
Hi all, Changes since 20181211: The sparc-next tree gained a conflict against the dma-mapping tree. The rdma tree still had its build failure so I used the version from next-20181203. The net-next tree gained a conflict against the char-misc.current tree. The phy-next tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 7936 8593 files changed, 370996 insertions(+), 216177 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 68 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (f5d582777bcb Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid) Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (4c567a448b30 ARC: perf: remove useless ifdefs) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (b4aecf78083d arm64: hibernate: Avoid sending cross-calling with interrupts disabled) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (a225f1567405 powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call) Merging sparc/master (cf76c364a1e1 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (2f1a9f666751 Merge branch 'ieee802154-for-davem-2018-12-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan) Merging bpf/master (aca1a80ebe3e selftests/bpf: use proper type when passing prog_type) Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on acquire) Merging netfilter/master (530aad77010b netfilter: seqadj: re-load tcp header pointer after possible head reallocation) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4) Merging mac80211/master (312ca38ddda6 cfg80211: Fix busy loop regression in ieee80211_ie_split_ric()) Merging rdma-fixes/for-rc (47f07f03b5ee IB/mlx5: Block DEVX umem from the non applicable cases) Merging sound-current/for-linus (0bea4cc83835 ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294) Merging sound-asoc-fixes/for-linus (043eb516967a Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3) Merging regulator-fixes/for-linus (d407c81adae5 Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (a31e8df3efaa Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (b07b864ee423 Revert "PCI/ASPM: Do not initialize link state when aspm_disabled is set") Merging driver-core.current/driver-core-linus (2595646791c3 Linux 4.20-rc5) Merging tty.current/tty-linus (40e020c129cf Linux 4.20-rc6) Merging usb.current/usb-linus (40e020c129cf Linux 4.20-rc6) Merging usb-gadget-fixes/fixes (069caf5950df USB: omap_udc: fix rejection of out transfers when
Re: [PATCH v2 4/4] x86/vmalloc: Add TLB efficient x86 arch_vunmap
> On Dec 11, 2018, at 4:03 PM, Rick Edgecombe > wrote: > > This adds a more efficient x86 architecture specific implementation of > arch_vunmap, that can free any type of special permission memory with only 1 > TLB > flush. > > In order to enable this, _set_pages_p and _set_pages_np are made non-static > and > renamed set_pages_p_noflush and set_pages_np_noflush to better communicate > their different (non-flushing) behavior from the rest of the set_pages_* > functions. > > The method for doing this with only 1 TLB flush was suggested by Andy > Lutomirski. > [snip] > + /* > + * If the vm being freed has security sensitive capabilities such as > + * executable we need to make sure there is no W window on the directmap > + * before removing the X in the TLB. So we set not present first so we > + * can flush without any other CPU picking up the mapping. Then we reset > + * RW+P without a flush, since NP prevented it from being cached by > + * other cpus. > + */ > + set_area_direct_np(area); > + vm_unmap_aliases(); Does vm_unmap_aliases() flush in the TLB the direct mapping range as well? I can only find the flush of the vmalloc range.
Re: [PATCH] scatterlist: Update size type to support greater then 4GB size.
From: Ashish Mhetre
Date: Wed, 12 Dec 2018 11:54:13 +0530
> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
> index 68e91ef..0a07a29 100644
> --- a/include/linux/nvme.h
> +++ b/include/linux/nvme.h
> @@ -587,7 +587,7 @@ enum {
>
> struct nvme_sgl_desc {
> __le64 addr;
> - __le32 length;
> + __le64 length;
> __u8rsvd[3];
> __u8type;
> };
Isn't this a device or protocol defined datastructure? You can't just
change it like this.
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
On (12/11/18 22:08), Daniel Wang wrote: > > I've been meaning to try it but kept getting distracted by other > things. I'll try to find some time for it this week or next. Right now > my intent is to get Steven's patch into 4.14 stable as it evidently > fixed the particular issue I was seeing, and as Steven said it has > been in upstream since 4.16 so it's not like backporting it will raise > any red flags. I will start another thread on -stable for it. OK. > > I guess we still don't have a really clear understanding of what exactly > is going in your system > > I would also like to get to the bottom of it. Unfortunately I haven't > got the expertise in this area nor the time to do it yet. Hence the > intent to take a step back and backport Steven's patch to fix the > issue that has resurfaced in our production recently. No problem. I just meant that -stable people can be a bit "unconvinced". > Which two sets are you referring to specifically? I guess I used the wrong word: The first set (actually just one patch) is the one that makes consoles re-entrant from panic(). The other set - those 4 patches (Steven's patch, + Petr's patch + a patch that makes printk() atomic again). -ss
[PATCH] scatterlist: Update size type to support greater then 4GB size.
From: Krishna Reddy
In the cases where greater than 4GB allocations are required, current
definition of scatterlist doesn't support it. For example, Tegra devices
have more than 4GB of system memory available. So they are expected to
support larger allocation requests.
This patch updates the type of scatterlist members to support creating
scatterlist for allocations of size greater than 4GB size.
Updated the files that are necessary to fix compilation issues with updated
type of variables.
With definition of scatterlist changed in this patch, size of sg has
increased from 28 bytes to 40 bytes because of which allocations in nvme
driver are crossing order-0( as sizeof(struct scatterlist) is used in nvme
driver allocations ) i.e. they are not able to fit into single page.
Recently a patch to limit the nvme allocations to order-0 is mergerd.
'commit 943e942e6266f22babee5efeb00f8f672fbff5bd ("nvme-pci: limit
max IO size and segments to avoid high order allocations")'
Because of that patch, WARN log is getting printed in our case as
definition of scatterlist has changed. Alloc size of nvme is calculated as
NVME_MAX_SEGS * sizeof(struct scatterlist). As sizeof(struct scatterlist)
has changed from 28 bytes to 40 bytes, so updating NVME_MAX_SEGS from 127
to 88 to correspond to original nvme alloc size value.
Signed-off-by: Krishna Reddy
Signed-off-by: Ashish Mhetre
---
crypto/shash.c| 2 +-
drivers/ata/libata-sff.c | 2 +-
drivers/mmc/host/sdhci.c | 2 +-
drivers/mmc/host/toshsd.c | 2 +-
drivers/mmc/host/usdhi6rol0.c | 14 +++---
drivers/nvme/host/pci.c | 8
include/linux/nvme.h | 2 +-
include/linux/scatterlist.h | 8
8 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/crypto/shash.c b/crypto/shash.c
index d21f04d..434970e 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -298,7 +298,7 @@ int shash_ahash_digest(struct ahash_request *req, struct
shash_desc *desc)
if (nbytes &&
(sg = req->src, offset = sg->offset,
-nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset))) {
+nbytes < min(sg->length, ((size_t)(PAGE_SIZE)) - offset))) {
void *data;
data = kmap_atomic(sg_page(sg));
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index c5ea0fc..675def6 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -810,7 +810,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc,
unsigned int bytes)
offset %= PAGE_SIZE;
/* don't overrun current sg */
- count = min(sg->length - qc->cursg_ofs, bytes);
+ count = min(sg->length - qc->cursg_ofs, (size_t)bytes);
/* don't cross page boundaries */
count = min(count, (unsigned int)PAGE_SIZE - offset);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 99bdae5..bd84c0c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1025,7 +1025,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
if (unlikely(length_mask | offset_mask)) {
for_each_sg(data->sg, sg, data->sg_len, i) {
if (sg->length & length_mask) {
- DBG("Reverting to PIO because of
transfer size (%d)\n",
+ DBG("Reverting to PIO because of
transfer size (%zd)\n",
sg->length);
host->flags &= ~SDHCI_REQ_USE_DMA;
break;
diff --git a/drivers/mmc/host/toshsd.c b/drivers/mmc/host/toshsd.c
index dd961c5..af00936 100644
--- a/drivers/mmc/host/toshsd.c
+++ b/drivers/mmc/host/toshsd.c
@@ -479,7 +479,7 @@ static void toshsd_start_data(struct toshsd_host *host,
struct mmc_data *data)
{
unsigned int flags = SG_MITER_ATOMIC;
- dev_dbg(&host->pdev->dev, "setup data transfer: blocksize %08x
nr_blocks %d, offset: %08x\n",
+ dev_dbg(&host->pdev->dev, "setup data transfer: blocksize %08x
nr_blocks %d, offset: %08lx\n",
data->blksz, data->blocks, data->sg->offset);
host->data = data;
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
index cd8b1b9..5fce5ff 100644
--- a/drivers/mmc/host/usdhi6rol0.c
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -316,7 +316,7 @@ static void usdhi6_blk_bounce(struct usdhi6_host *host,
struct mmc_data *data = host->mrq->data;
size_t blk_head = host->head_len;
- dev_dbg(mmc_dev(host->mmc), "%s(): CMD%u of %u SG: %ux%u @ 0x%x\n",
+ dev_dbg(mmc_dev(host->mmc), "%s(): CMD%u of %u SG: %ux%u @ 0x%lx\n",
__func__, host->mrq->cmd->opcode, data->sg_len,
data->blksz, data->blocks, sg->offset);
@@ -360,7 +360,7 @@ static void *usdhi6_sg_map(struct usdhi6_host *host)
WARN(ho
Re: [PATCH 4.19 000/118] 4.19.9-stable review
On Tue, 11 Dec 2018 at 21:25, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.9 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 13 15:16:10 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.9-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.9-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 6a09e212b52e5edf398ca6296a183187d7343863 git describe: v4.19.8-119-g6a09e212b52e Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.8-119-g6a09e212b52e No regressions (compared to build v4.19.8) No fixes (compared to build v4.19.8) Ran 20670 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: KMSAN: uninit-value in __inet6_bind
On Tue, Dec 11, 2018 at 1:04 AM Dmitry Vyukov wrote: > > On Tue, Dec 11, 2018 at 1:41 AM syzbot > wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:3f06bda61398 kmsan: remove excessive KMSAN wrappers from a.. > > git tree: https://github.com/google/kmsan.git/master > > console output: https://syzkaller.appspot.com/x/log.txt?x=13ca6b0540 > > kernel config: https://syzkaller.appspot.com/x/.config?x=9b071100dcf8e641 > > dashboard link: https://syzkaller.appspot.com/bug?extid=c56449ed3652e6720f30 > > compiler: clang version 8.0.0 (trunk 348261) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+c56449ed3652e6720...@syzkaller.appspotmail.com > > This looks like a bug in TIPC, +TIPC maintainers. > It looks more like udp_sock_create6() doesn't initialize udp6_addr.sin6_scope_id.
RE: [PATCH V3 1/2] dt-bindings: iio: light: isl29018: update power supply name
Hi, Fabio
Obviously, some of the dts files (such as
arch/arm/boot/dts/exynos5420-peach-pit.dts) using "vcc" as isl29018's power
supply name, they are NOT matched with datasheet, so should we update those dts
files with "vdd" as well or just using the "vcc" in isl29018 driver? Which
solution is better?
Best Regards!
Anson Huang
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2018年12月11日 23:19
> To: Anson Huang
> Cc: Jonathan Cameron ; Hartmut Knaack
> ; Lars-Peter Clausen ; Peter Meerwald
> ; Mark Rutland ;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx
> Subject: Re: [PATCH V3 1/2] dt-bindings: iio: light: isl29018: update power
> supply name
>
> On Mon, Dec 10, 2018 at 7:40 PM Anson Huang
> wrote:
> >
> > Hi, Rob
> >
> > Best Regards!
> > Anson Huang
> >
> > > -Original Message-
> > > From: Rob Herring [mailto:r...@kernel.org]
> > > Sent: 2018年12月11日 7:24
> > > To: Anson Huang
> > > Cc: ji...@kernel.org; knaac...@gmx.de; l...@metafoo.de;
> > > pme...@pmeerw.net; mark.rutl...@arm.com; linux-...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > dl-linux-imx
> > > Subject: Re: [PATCH V3 1/2] dt-bindings: iio: light: isl29018:
> > > update power supply name
> > >
> > > On Mon, Dec 10, 2018 at 07:11:19AM +, Anson Huang wrote:
> > > > According to datasheet, the isl29018 has "vddd/vdda" power supply,
> > > > and
> > > > isl29023/isl29035 ONLY has "vdd" power supply, update the power
> > > > supply name with "vdd" and "vdda" according to datasheet to cover
> > > > all devices and avoid confusion.
> > > >
> > > > Signed-off-by: Anson Huang
> > > > ---
> > > > Documentation/devicetree/bindings/iio/light/isl29018.txt | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/iio/light/isl29018.txt
> > > > b/Documentation/devicetree/bindings/iio/light/isl29018.txt
> > > > index b9bbde3..36f737d 100644
> > > > --- a/Documentation/devicetree/bindings/iio/light/isl29018.txt
> > > > +++ b/Documentation/devicetree/bindings/iio/light/isl29018.txt
> > > > @@ -15,7 +15,9 @@ Optional properties:
> > > >Refer to interrupt-controller/interrupts.txt for generic interrupt
> > > > client
> > > >node bindings.
> > > >
> > > > - - vcc-supply: phandle to the regulator that provides power to the
> sensor.
> > > > + - vdd-supply: phandle to the regulator that provides vdd power
> > > > + to the
> > > sensor.
> > > > +
> > > > + - vdda-supply: phandle to the regulator that provides vdda
> > > > + power to the
> > > sensor.
> > >
> > > Is this in use? You can't just change things if it is.
> >
> > I did NOT see any "vcc" in folder drivers/iio/light/, so I think it is
> > NOT used at all, so I take this chance to update it according to datasheet.
> Thanks.
>
> arch/arm/boot/dts/exynos5420-peach-pit.dts-629- light-sensor@44 {
> arch/arm/boot/dts/exynos5420-peach-pit.dts:630: compatible =
> "isil,isl29018";
> arch/arm/boot/dts/exynos5420-peach-pit.dts-631- reg = <0x44>;
> arch/arm/boot/dts/exynos5420-peach-pit.dts-632- vcc-supply =
> <&tps65090_fet5>;
> arch/arm/boot/dts/exynos5420-peach-pit.dts-633- };
>
> arch/arm/boot/dts/exynos5800-peach-pi.dts-629- light-sensor@44 {
> arch/arm/boot/dts/exynos5800-peach-pi.dts:630: compatible =
> "isil,isl29018";
> arch/arm/boot/dts/exynos5800-peach-pi.dts-631- reg = <0x44>;
> arch/arm/boot/dts/exynos5800-peach-pi.dts-632- vcc-supply =
> <&tps65090_fet5>;
> arch/arm/boot/dts/exynos5800-peach-pi.dts-633- };
>
> The rest of the dts files using this don't have a supply it seems. So you need
> permission from the Exynos folks if you want to just drop this. And also
> update
> their dts files.
>
> Rob
Re: [PATCH v2] mm, memory_hotplug: Don't bail out in do_migrate_range prematurely
On Wed, 2018-12-12 at 03:35 +, Wei Yang wrote:
> I see the above code is wrapped with CONFIG_DEBUG_VM on current Linus
> tree.
> This is removed by someone else?
Yes, e8abbd69957288 ("mm, memory_hotplug: be more verbose for memory
offline failures") got rid of the CONFIG_DEBUG_VM.
This commit is sitting in the -mmotm tree.
>
> > - put_page(page);
> > - /* Because we don't have big zone->lock.
> > we should
> > - check this again here. */
> > - if (page_count(page)) {
> > - not_managed++;
> > - ret = -EBUSY;
> > - break;
> > - }
> > }
> > + put_page(page);
> > }
> > if (!list_empty(&source)) {
> > - if (not_managed) {
> > - putback_movable_pages(&source);
> > - goto out;
> > - }
> > -
> > /* Allocate a new page from the nearest neighbor node
> > */
> > ret = migrate_pages(&source, new_node_page, NULL, 0,
> > MIGRATE_SYNC,
> > MR_MEMORY_HOTPLUG);
> > @@ -1426,7 +1412,7 @@ do_migrate_range(unsigned long start_pfn,
> > unsigned long end_pfn)
> > putback_movable_pages(&source);
> > }
> > }
> > -out:
> > +
> > return ret;
> > }
> >
> > --
> > 2.13.7
>
>
--
Oscar Salvador
SUSE L3
Re: [RESEND PATCH v3] backlight: pwm_bl: Fix brightness levels for non-DT case.
On Mon, 10 Dec 2018, Enric Balletbo i Serra wrote:
> Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> linearly to human eye")' allows the possibility to compute a default
> brightness table when there isn't the brightness-levels property in the
> DT. Unfortunately the changes made broke the pwm backlight for the
> non-DT boards.
>
> Usually, the non-DT boards don't pass the brightness levels via platform
> data, instead, it sets the max_brightness in their platform data and the
> driver calculates the level without a table. The offending patch assumed
> that when there is no brightness levels table we should create one, but this
> is clearly wrong for the non-DT case.
>
> After this patch the code handles the DT and the non-DT case taking in
> consideration also if max_brightness is set or not.
>
> Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly
> to human eye")
> Cc:
> Reported-by: Robert Jarzmik
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Robert Jarzmik
> Acked-by: Daniel Thompson
> ---
>
> Changes in v3:
> - Fixed some typos in commit message.
> - Removed ' in Fixes tag.
>
> Changes in v2:
> - Rebase on top of mainline
> - Add Tested-by and Acked-by tags.
>
> drivers/video/backlight/pwm_bl.c | 41 +++-
> 1 file changed, 35 insertions(+), 6 deletions(-)
FYI, this patch is now in Mainline.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
Got it. Thank you. On Tue, Dec 11, 2018 at 10:06 PM Sergey Senozhatsky wrote: > > On (12/11/18 21:59), Daniel Wang wrote: > > No worries. I will follow up. You would recommend that all four > > patches in this set to be backported though, right? > > Just the last one, which makes consoles re-entrant > > panic: avoid deadlocks in re-entrant console drivers > > Because only this one was applied so far. The reset got stuck. > > -ss -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
> So... did my patch address the deadlock you are seeing or it didn't? I've been meaning to try it but kept getting distracted by other things. I'll try to find some time for it this week or next. Right now my intent is to get Steven's patch into 4.14 stable as it evidently fixed the particular issue I was seeing, and as Steven said it has been in upstream since 4.16 so it's not like backporting it will raise any red flags. I will start another thread on -stable for it. > I guess we still don't have a really clear understanding of what exactly is going in your system I would also like to get to the bottom of it. Unfortunately I haven't got the expertise in this area nor the time to do it yet. Hence the intent to take a step back and backport Steven's patch to fix the issue that has resurfaced in our production recently. > If it's uart_port->lock and there will be 2 patch sets to choose from for -stable, then -stable guys can pick up the one that requires less effort: 1 two-liner patch vs. 3 or 4 bigger patches. Which two sets are you referring to specifically? On Tue, Dec 11, 2018 at 9:21 PM Sergey Senozhatsky wrote: > > On (12/11/18 17:16), Daniel Wang wrote: > > > Let's first figure out if it works. > > > > I would still like to try applying your patches that went into > > printk.git, but for now I wonder if we can get Steven's patch into > > 4.14 first, for at least we know it mitigated the issue if not > > fundamentally addressed it, and we've agreed it's an innocuous change > > that doesn't risk breaking stable. > > So... did my patch address the deadlock you are seeing or it didn't? > > > I haven't done this before so I'll need your help. What's the next > > step to actually get Steven's patch *in* linux-4.14.y? According to > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > I am supposed to send an email with the patch ID and subject, which > > are both mentioned in this email. Should I send another one? What's > > the process like? Thanks! > > I'm not doing any -stable releases, so can't really answer, sorry. > Probably would be better to re-address this question to 4.14 -stable > maintainers. > > > --- > I guess we still don't have a really clear understanding of what exactly > is going in your system. We don't even know for sure which one of the locks > is deadlocking the system. And why exactly Steven's patch helps. If it > is uart_port->lock, then it's one thing; if it's console_sem ->lock then > it's another thing. But those two are just theories, not supported by any > logs/backtraces from your systems. > > If it's uart_port->lock and there will be 2 patch sets to choose from > for -stable, then -stable guys can pick up the one that requires less > effort: 1 two-liner patch vs. 3 or 4 bigger patches. > > -ss -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
On (12/11/18 21:59), Daniel Wang wrote: > No worries. I will follow up. You would recommend that all four > patches in this set to be backported though, right? Just the last one, which makes consoles re-entrant panic: avoid deadlocks in re-entrant console drivers Because only this one was applied so far. The reset got stuck. -ss
Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
No worries. I will follow up. You would recommend that all four patches in this set to be backported though, right? On Tue, Dec 11, 2018 at 9:23 PM Sergey Senozhatsky wrote: > > On (12/11/18 16:53), Daniel Wang wrote: > > Is it okay to tag this commit with `Cc: sta...@vger.kernel.org` so > > that it'll get applied to the stable trees once merged into Linux's > > tree, if it's not too late? Otherwise I'll follow up on the stable > > merges separately. Thanks for making the changes anyway. > > My bad! I should have Cc-ed stable on that one, sorry. I guess now it > would be easier to wait and follow up once it gets merged. > > -ss -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2 0/4] Static calls
> On Dec 11, 2018, at 10:05 AM, Josh Poimboeuf wrote:
>
> On Fri, Dec 07, 2018 at 04:06:32PM +, Edward Cree wrote:
>> Sorry if this has been pointed out before (it's a very long thread), but
>> in the out-of-line implementation, it appears that static_call_update()
>> never alters key->func. Am I right in thinking that this should be
>> fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
>> arch_static_call_transform() on line 159 of include/linux/static_call.h?
>
> Yes, you're right about both bugs in the out-of-line case: key->func
> needs to be written, and __static_call_update() needs to be called by
> static_call_update. I was so focused on getting the inline case working
> that I overlooked those.
>
>> Some background (why does key->func matter for the
>> CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with
>> combining these static calls with the 'indirect call wrappers' notion
>> that Paolo Abeni has been working on [1], using runtime instrumentation
>> to determine a list of potential callees. (This allows us to cope with
>> cases where the callees are in modules, or where different workloads may
>> use different sets of callees for a given call site, neither of which is
>> handled by Paolo's approach).
>> The core of my design looks something like:
>>
>> static int dynamic_call_xyz(int (*func)(some_args), some_args)
>> {
>> if (func == dynamic_call_xyz_1.func)
>> return static_call(dynamic_call_xyz_1, some_args);
>> if (func == dynamic_call_xyz_2.func)
>> return static_call(dynamic_call_xyz_2, some_args);
>> return (*func)(some_args);
>> }
>>
>> albeit with a bunch of extra (and currently rather ugly) stuff to collect
>> the statistics needed to decide what to put in the static call keys, and
>> mechanisms (RCU in my current case) to ensure that the static call isn't
>> changed between checking its .func and actually calling it.
>>
>> -Ed
>>
>> PS: not on list, please keep me in CC.
>>
>> [1]
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F773985%2F&data=02%7C01%7Cnamit%40vmware.com%7C147894d6c56d4ce6c1fc08d65f933adf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636801483286688490&sdata=QOZcfWXjvPqoR0oujtf1QTQLenv%2BiEu6jUA5fiav6Mo%3D&reserved=0
>
> Thanks, this sounds very interesting. Adding Nadav to CC, as he has
> been looking at a different approach to solving the same problem:
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.kernel.org%2Fr%2F20181018005420.82993-1-namit%40vmware.com&data=02%7C01%7Cnamit%40vmware.com%7C147894d6c56d4ce6c1fc08d65f933adf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636801483286688490&sdata=bCI2N2xKUVyyyPAnWDH3mC3DsSk%2Bzy5nmI0DV%2F%2FaYYw%3D&reserved=0
Thanks for cc’ing me. (I didn’t know about the other patch-sets.)
Allow me to share my experience, because I was studying this issue for some
time and have implemented more than I shared, since the code need more
cleanup. Some of the proposed approaches are things we either considered or
actually implemented (and later dropped). Eventually, our design was guided
by performance profiling and a grain of “what’s academic” consideration.
I think that eventually you would want to go with one central mechanism for
the various situations:
1. Registered targets (static) and automatically learnt targets (dynamic).
Registration does not work in some cases (e.g., file-system function
pointers, there are too many of those). On the other hand, if you know your
target it is obviously simpler/better.
2. With/without retpoline fallback. We’ve have always had the retpoline as
fallback, but if you use a registration mechanism, it’s not necessary.
3. Single and multiple targets. For multiple targets we decided to use
outline block in order not to inflate the code for no reason. There were
over 1 indirect branches in our kernel build, but in our workloads only
~500 were actually run.
If you got with the approach that Edward mentioned, you may want to
associate each “function" with identifier (think about file_operations
having an additional field that holds a unique ID, or using the struct
address). This would allow you to use a “binary search” to find the right
target, which would be slightly more efficient. We actually used a
binary-search for a different reason - learning the most frequent syscalls
per process and calling them in this manner (we actually had an indirection
table to choose the right one).
3. Call-chains which are mostly fixed (next). You want to unroll those.
4. Per-process calls. The case that bothered us the most is seccomp. On our
setup, systemd installed 17(!) BPF seccomp programs on Redis server, causing
every syscall to go through 17 indirect branches to invoke them. But
similarly you have mmu-notifiers and others. We used a per-process
trampoline page for this matter.
Now there is of course the question of whether to go through automatic
RE: [PATCH 2/2] scsi: ufs: add inline crypto support to UFS HCD
Hello Eric,
Thank you for a comment.
>-Original Message-
>From: Eric Biggers
>Sent: Tuesday, December 11, 2018 11:47 PM
>To: Parshuram Raju Thombare
>Cc: ax...@kernel.dk; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com; mchehab+sams...@kernel.org;
>gre...@linuxfoundation.org; da...@davemloft.net; akpm@linux-
>foundation.org; nicolas.fe...@microchip.com; a...@arndb.de; linux-
>ker...@vger.kernel.org; linux-bl...@vger.kernel.org; linux-
>s...@vger.kernel.org; Alan Douglas ; Janek Kotas
>; Rafal Ciepiela ; AnilKumar
>Chimata ; Ladvine D Almeida ;
>Satya Tangirala ; Paul Crowley
>
>Subject: Re: [PATCH 2/2] scsi: ufs: add inline crypto support to UFS HCD
>
>EXTERNAL MAIL
>
>
>[+Cc other people who have been working on this]
>
>
>
>Hi Parshuram,
>
>
>
>On Tue, Dec 11, 2018 at 09:50:27AM +, Parshuram Thombare wrote:
>
>> Add real time crypto support to UFS HCD using new device
>
>> mapper 'crypto-ufs'. dmsetup tool can be used to enable
>
>> real time / inline crypto support using device mapper
>
>> 'crypt-ufs'.
>
>>
>
>> Signed-off-by: Parshuram Thombare
>
>> ---
>
>> MAINTAINERS |7 +
>
>> block/Kconfig|5 +
>
>> drivers/scsi/ufs/Kconfig | 12 +
>
>> drivers/scsi/ufs/Makefile|1 +
>
>> drivers/scsi/ufs/ufshcd-crypto.c | 453
>++
>
>> drivers/scsi/ufs/ufshcd-crypto.h | 102 +
>
>> drivers/scsi/ufs/ufshcd.c| 27 +++-
>
>> drivers/scsi/ufs/ufshcd.h|6 +
>
>> drivers/scsi/ufs/ufshci.h|1 +
>
>> 9 files changed, 613 insertions(+), 1 deletions(-)
>
>> create mode 100644 drivers/scsi/ufs/ufshcd-crypto.c
>
>> create mode 100644 drivers/scsi/ufs/ufshcd-crypto.h
>
>>
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>
>> index f485597..3a68126 100644
>
>> --- a/MAINTAINERS
>
>> +++ b/MAINTAINERS
>
>> @@ -15340,6 +15340,13 @@ S: Supported
>
>> F: Documentation/scsi/ufs.txt
>
>> F: drivers/scsi/ufs/
>
>>
>
>> +UNIVERSAL FLASH STORAGE HOST CONTROLLER CRYPTO DRIVER
>
>> +M: Parshuram Thombare
>
>> +L: linux-s...@vger.kernel.org
>
>> +S: Supported
>
>> +F: drivers/scsi/ufs/ufshcd-crypto.c
>
>> +F: drivers/scsi/ufs/ufshcd-crypto.h
>
>> +
>
>> UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS
>
>> M: Joao Pinto
>
>> L: linux-s...@vger.kernel.org
>
>> diff --git a/block/Kconfig b/block/Kconfig
>
>> index f7045aa..6afe131 100644
>
>> --- a/block/Kconfig
>
>> +++ b/block/Kconfig
>
>> @@ -224,4 +224,9 @@ config BLK_MQ_RDMA
>
>> config BLK_PM
>
>> def_bool BLOCK && PM
>
>>
>
>> +config BLK_DEV_HW_RT_ENCRYPTION
>
>> +bool
>
>> +depends on SCSI_UFSHCD_RT_ENCRYPTION
>
>> +default n
>
>> +
>
>> source block/Kconfig.iosched
>
>> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
>
>> index 2ddbb26..09a3ec0 100644
>
>> --- a/drivers/scsi/ufs/Kconfig
>
>> +++ b/drivers/scsi/ufs/Kconfig
>
>> @@ -136,3 +136,15 @@ config SCSI_UFS_BSG
>
>>
>
>>Select this if you need a bsg device node for your UFS controller.
>
>>If unsure, say N.
>
>> +
>
>> +config SCSI_UFSHCD_RT_ENCRYPTION
>
>> +bool "Universal Flash Storage Controller RT encryption support"
>
>> +depends on SCSI_UFSHCD
>
>> +default n
>
>> +select BLK_DEV_HW_RT_ENCRYPTION if SCSI_UFSHCD_RT_ENCRYPTION
>
>> +select BLK_DEV_DM if SCSI_UFSHCD_RT_ENCRYPTION
>
>> +help
>
>> +Universal Flash Storage Controller RT encryption support
>
>> +
>
>> +Select this if you want to enable real time encryption on UFS controller
>
>> +If unsure, say N.
>
>> diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
>
>> index a3bd70c..6169096 100644
>
>> --- a/drivers/scsi/ufs/Makefile
>
>> +++ b/drivers/scsi/ufs/Makefile
>
>> @@ -7,6 +7,7 @@ obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
>
>> obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
>
>> ufshcd-core-y += ufshcd.o ufs-sysfs.o
>
>> ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
>
>> +ufshcd-core-$(CONFIG_SCSI_UFSHCD_RT_ENCRYPTION) += ufshcd-crypto.o
>
>> obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
>
>> obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
>
>> obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
>
>> diff --git a/drivers/scsi/ufs/ufshcd-crypto.c
>> b/drivers/scsi/ufs/ufshcd-crypto.c
>
>> new file mode 100644
>
>> index 000..9c95ff3
>
>> --- /dev/null
>
>> +++ b/drivers/scsi/ufs/ufshcd-crypto.c
>
>> @@ -0,0 +1,453 @@
>
>> +// SPDX-License-Identifier: GPL-2.0
>
>> +/*
>
>> + * UFS Host controller crypto driver
>
>> + *
>
>> + * Copyright (C) 2018 Cadence Design Systems, Inc.
>
>> + *
>
>> + * Authors:
>
>> + * Parshuram Thombare
>
>> + *
>
>> + */
>
>> +
>
>> +#include
>
>> +#include
>
>> +#include
>
>> +#include
>
>> +#include "ufshcd.h"
>
>> +#include "ufshcd-crypto.h"
>
>> +#include "scsi/scsi_device.h"
>
>> +#include "scsi/scsi_host.h"
>
>> +
>
>> +struct ufshcd_dm_ctx {
>
>> +struct dm_dev *dev;
Re: [PATCH net-next] rhashtable: further improve stability of rhashtable_walk
On Wed, Dec 12, 2018 at 11:02:35AM +1100, NeilBrown wrote: > > So I think this is a real bug - it is quite unlikely to hit, but > possibly. > You need a chain with at least 2 objects, you need > rhashtable_walk_stop() to be called after visiting an object other than > the last object, and you need some thread (this or some other) to remove > that object from the table. > > The patch that I posted aims to fix that bug, and only that bug. > The only alternative that I can think of is to document that this can > happen and advise that a reference should be held to the last visited > object when stop/start is called, or in some other way ensure that it > doesn't get removed. Thanks for reminding me of the issue you were trying to fix. So going back into the email archives, I suggested at the very start that we could just insert the walker objects into the actual hash table. That would solve the issue for both rhashtable and rhlist. Could we do that rather than using this ordered list that only works for rhashtable? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[RFC PATCH 2/3] iommu/dma: IOVA reserve for PCI host reserve address list
PCI host has list of resource entries contain memory
address range for which IOVA address mapping has to
be reserve.
These address ranges are the address holes in
dma-ranges property.
It is similar to PCI IO resources address range
reserving in IOMMU for each EP connected to
corresponding host.
Signed-off-by: Srinath Mannam
---
drivers/iommu/dma-iommu.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 511ff9a..346da81 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -220,6 +220,14 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+ /* Get reserved DMA windows from host bridge */
+ resource_list_for_each_entry(window, &bridge->dma_resv) {
+
+ lo = iova_pfn(iovad, window->res->start - window->offset);
+ hi = iova_pfn(iovad, window->res->end - window->offset);
+ reserve_iova(iovad, lo, hi);
+ }
}
static int iova_reserve_iommu_regions(struct device *dev,
--
2.7.4
[RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host
IPROC host has the limitation that it can use
only those address ranges given by dma-ranges
property as inbound address.
So that the memory address holes in dma-ranges
should be reserved to allocate as DMA address.
All such reserved addresses are created as resource
entries and add to dma_resv list of pci host bridge.
These dma reserve resources created by parsing
dma-ranges parameter.
Ex:
dma-ranges = < \
0x4300 0x00 0x8000 0x00 0x8000 0x00 0x8000 \
0x4300 0x08 0x 0x08 0x 0x08 0x \
0x4300 0x80 0x 0x80 0x 0x40 0x>
In the above example of dma-ranges, memory address from
0x0 - 0x8000,
0x1 - 0x8,
0x10 - 0x80 and
0x100 - 0x.
are not allowed to use as inbound addresses.
So that we need to add these address range to dma_resv
list to reserve their IOVA address ranges.
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index 3160e93..43e465a 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1154,25 +1154,74 @@ static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
return ret;
}
+static int
+iproc_pcie_add_dma_resv_range(struct device *dev, struct list_head *resources,
+ uint64_t start, uint64_t end)
+{
+ struct resource *res;
+
+ res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
+ if (!res)
+ return -ENOMEM;
+
+ res->start = (resource_size_t)start;
+ res->end = (resource_size_t)end;
+ pci_add_resource_offset(resources, res, 0);
+
+ return 0;
+}
+
static int iproc_pcie_map_dma_ranges(struct iproc_pcie *pcie)
{
+ struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
struct of_pci_range range;
struct of_pci_range_parser parser;
int ret;
+ uint64_t start, end;
+ LIST_HEAD(resources);
/* Get the dma-ranges from DT */
ret = of_pci_dma_range_parser_init(&parser, pcie->dev->of_node);
if (ret)
return ret;
+ start = 0;
for_each_of_pci_range(&parser, &range) {
+ end = range.pci_addr;
+ /* dma-ranges list expected in sorted order */
+ if (end < start) {
+ ret = -EINVAL;
+ goto out;
+ }
/* Each range entry corresponds to an inbound mapping region */
ret = iproc_pcie_setup_ib(pcie, &range, IPROC_PCIE_IB_MAP_MEM);
if (ret)
return ret;
+
+ if (end - start) {
+ ret = iproc_pcie_add_dma_resv_range(pcie->dev,
+ &resources,
+ start, end);
+ if (ret)
+ goto out;
+ }
+ start = range.pci_addr + range.size;
}
+ end = ~0;
+ if (end - start) {
+ ret = iproc_pcie_add_dma_resv_range(pcie->dev, &resources,
+ start, end);
+ if (ret)
+ goto out;
+ }
+
+ list_splice_init(&resources, &host->dma_resv);
+
return 0;
+out:
+ pci_free_resource_list(&resources);
+ return ret;
}
static int iproce_pcie_get_msi(struct iproc_pcie *pcie,
--
2.7.4
[RFC PATCH 1/3] PCI: Add dma-resv window list
Add a dma_resv parameter in pci host bridge structure
to hold resource entries list of memory regions for
which IOVAs has to reserve.
IOMMU framework reserve IOVA for this list of address
range while initializing IOMMU domain of corresponding
PCI EP connected to the HOST.
PCIe host driver will add resource entries to this
list based on requirements.
Few hosts can't use all inbound address, so those
address regions will be add to this list to avoid
IOMMU mapping.
Signed-off-by: Srinath Mannam
---
drivers/pci/probe.c | 3 +++
include/linux/pci.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ec78400..bbed0e7 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -544,6 +544,7 @@ struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
return NULL;
INIT_LIST_HEAD(&bridge->windows);
+ INIT_LIST_HEAD(&bridge->dma_resv);
bridge->dev.release = pci_release_host_bridge_dev;
/*
@@ -572,6 +573,7 @@ struct pci_host_bridge *devm_pci_alloc_host_bridge(struct
device *dev,
return NULL;
INIT_LIST_HEAD(&bridge->windows);
+ INIT_LIST_HEAD(&bridge->dma_resv);
bridge->dev.release = devm_pci_release_host_bridge_dev;
return bridge;
@@ -581,6 +583,7 @@ EXPORT_SYMBOL(devm_pci_alloc_host_bridge);
void pci_free_host_bridge(struct pci_host_bridge *bridge)
{
pci_free_resource_list(&bridge->windows);
+ pci_free_resource_list(&bridge->dma_resv);
kfree(bridge);
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e72ca8d..1f0a32a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -472,6 +472,7 @@ struct pci_host_bridge {
void*sysdata;
int busnr;
struct list_head windows; /* resource_entry */
+ struct list_head dma_resv; /* reserv dma ranges */
u8 (*swizzle_irq)(struct pci_dev *, u8 *); /* Platform IRQ swizzler */
int (*map_irq)(const struct pci_dev *, u8, u8);
void (*release_fn)(struct pci_host_bridge *);
--
2.7.4
[RFC PATCH 0/3] PCIe Host request to reserve IOVA
Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those SOCs has to list all address ranges which have to reserve their IOVA address into PCIe host bridge resource entry list. IOMMU framework will reserve these IOVAs while initializing IOMMU domain. This patch set is based on Linux-4.19-rc1. Srinath Mannam (3): PCI: Add dma-resv window list iommu/dma: IOVA reserve for PCI host reserve address list PCI: iproc: Add dma reserve resources to host drivers/iommu/dma-iommu.c | 8 ++ drivers/pci/controller/pcie-iproc.c | 49 + drivers/pci/probe.c | 3 +++ include/linux/pci.h | 1 + 4 files changed, 61 insertions(+) -- 2.7.4
Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629
On Fri, 2018-12-07 at 20:56 +0800, Jianjun Wang wrote:
> On Thu, 2018-12-06 at 13:53 +0800, Honghui Zhang wrote:
> > On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> > > MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> > >
> > > The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> > > in arm64 but bogus alignment values at arm32, the pcie device and devices
> >
> > :s /the pcie device /the bridge device
> >
> > > behind this bridge will not be enabled. Fix it's BAR0 resource size to
> > > guarantee the pcie devices will be enabled correctly.
> > >
> > > The HW default value of its device id is invalid, fix it's device id to
> > > match the hardware implementation.
> > >
> > > Signed-off-by: Jianjun Wang
> > > ---
> > > drivers/pci/controller/pcie-mediatek.c | 26 ++
> > > include/linux/pci_ids.h| 1 +
> > > 2 files changed, 27 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index d20cf461ba00..f8937cc3c87c 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -73,6 +73,7 @@
> > > #define PCIE_MSI_VECTOR 0x0c0
> > >
> > > #define PCIE_CONF_VEND_ID0x100
> > > +#define PCIE_CONF_DEVICE_ID 0x102
> > > #define PCIE_CONF_CLASS_ID 0x106
> > >
> > > #define PCIE_INT_MASK0x420
> > > @@ -135,12 +136,14 @@ struct mtk_pcie_port;
> > > /**
> > > * struct mtk_pcie_soc - differentiate between host generations
> > > * @need_fix_class_id: whether this host's class ID needed to be fixed
> > > or not
> > > + * @need_fix_device_id: whether this host's device ID needed to be fixed
> > > or not
> > > * @ops: pointer to configuration access functions
> > > * @startup: pointer to controller setting functions
> > > * @setup_irq: pointer to initialize IRQ functions
> > > */
> > > struct mtk_pcie_soc {
> > > bool need_fix_class_id;
> > > + bool need_fix_device_id;
> > > struct pci_ops *ops;
> > > int (*startup)(struct mtk_pcie_port *port);
> > > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > > @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct
> > > mtk_pcie_port *port)
> > > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > > }
> > >
> > > + if (soc->need_fix_device_id) {
> > > + val = PCI_DEVICE_ID_MEDIATEK_7629;
> > > + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> > > + }
> > > +
> > > /* 100ms timeout value should be enough for Gen1/2 training */
> > > err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > >!!(val & PCIE_PORT_LINKUP_V2), 20,
> > > @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc
> > > mtk_pcie_soc_mt7622 = {
> > > .setup_irq = mtk_pcie_setup_irq,
> > > };
> > >
> > > +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> > > + .need_fix_class_id = true,
> > > + .need_fix_device_id = true,
> > > + .ops = &mtk_pcie_ops_v2,
> > > + .startup = mtk_pcie_startup_port_v2,
> > > + .setup_irq = mtk_pcie_setup_irq,
> > > +};
> > > +
> > > +static void mtk_fixup_bar_size(struct pci_dev *dev)
> > > +{
> > > + struct resource *dev_res = &dev->resource[0];
> > > + /* 32bit resource length will calculate size to 0, set it smaller */
> > > + dev_res->end = 0xfffe;
> > > +}
> >
> > I'm not sure assign the BAR0 size in driver to fit in the bogus
> > alignment is a good idea. Seems the size value of 0x_fffe also is an
> > arbitrary value.
> > Do we have a chance to change the resource framework code to make it
> > adopt this scenario?
I have take a look at the resource assign routine, it's better keep it
in current way.
Thanks.
> >
> > Thanks.
>
> I'm afraid not, the resource size length defined by phys_addr_t, which
> related to the hardware's physical address length.
> It will be much more better if the BAR0 size is not related with the
> pcie to axi window, when we set the window to 4GB, the BAR0 size still
> have initial value, and we can set the BAR0 size value or just disable
> it independently.
> The BAR0 size value need bigger than the MMIO space size, so the
> software will think it's a invalid resource but not a bogus alignment
> one, since we can't disable the BAR0 by hardware, and the flow of enable
> devices will keep going.
> >
> > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK,
> > > PCI_DEVICE_ID_MEDIATEK_7629,
> > > + mtk_fixup_bar_size);
> > > +
> > > static const struct of_device_id mtk_pcie_ids[] = {
> > > { .compatible = "mediatek,mt2701-pcie", .data = &mtk_pcie_soc_v1 },
> > > { .compatible = "mediatek,mt7623-pcie", .data = &mtk_pcie_soc_v1 },
> > > { .compatible = "mediatek,mt2712-pcie", .data = &mtk_pcie_soc_mt2712 },
> > > { .compatible = "mediatek,mt7622-pcie", .data = &mtk_pcie_soc_mt7622 },
> > > + {
Hi friend
-- Hi friend I am a banker in ADB BANK. I want to transfer an abandoned sum of USD27.5Million to your Bank account. 40/percent will be your share. Further details of the transaction shall be forward to you as soon as I receive your response indicating your interest in handling the transaction. No risk involved but keeps it as secret. Your sincere concern,obedience and speedy reply are needed for the success of our cooperation. Yours Dr.Imala Okagafsa, --
RE: [PATCH 1/2] block: add bi_crypto_ctx variable in struct bio
Hello Jens,
Thank you for a comment.
>-Original Message-
>From: Jens Axboe
>Sent: Tuesday, December 11, 2018 7:07 PM
>To: Parshuram Raju Thombare ; t...@kernel.org;
>jba...@fb.com; michaelcalla...@fb.com; snit...@redhat.com;
>osan...@fb.com; keith.bu...@intel.com; ming@redhat.com; s...@fb.com;
>dennissz...@gmail.com; linux-kernel@vger.kernel.org
>Cc: Alan Douglas ; Janek Kotas ;
>Rafal Ciepiela
>Subject: Re: [PATCH 1/2] block: add bi_crypto_ctx variable in struct bio
>
>EXTERNAL MAIL
>
>
>On 12/11/18 2:50 AM, Parshuram Thombare wrote:
>> Add variable 'void *bi_crypt_ctx' in 'struct bio'. This will be used
>> to associate bio with crypto configuration of controller supporting
>> real time / inline encryption/decryption.
>>
>> Signed-off-by: Parshuram Thombare
>> ---
>> include/linux/blk_types.h |4
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
>> index 1dcf652..bd77603 100644
>> --- a/include/linux/blk_types.h
>> +++ b/include/linux/blk_types.h
>> @@ -188,6 +188,10 @@ struct bio {
>> #endif
>> };
>>
>> +#ifdef CONFIG_BLK_DEV_HW_RT_ENCRYPTION
>> +void *bi_crypto_ctx;
>> +#endif
>> +
>> unsigned short bi_vcnt;/* how many bio_vec's */
>>
>> /*
>
>Pretty sure I mentioned this last time, but in case I didn't, don't add bio
>members
>for random drivers. Can you imagine how huge this thing would be if we allowed
>that?
>
>If you need per-io storage, put it in the payload for the blk-mq request. That
>way
>you are only bloating your own IO related data structures, not everyones.
Ok, I will look into using payload for the blk-mq request instead of adding
variable
in struct bio.
I thought this filed would be useful in enabling inline encryption for other
type of
devices too.
>
>--
>Jens Axboe
Regards,
Parshuram Thombare
RE: [PATCH 2/2] scsi: ufs: add inline crypto support to UFS HCD
Hello Greg,
Thank you for comments.
>-Original Message-
>From: Greg KH
>Sent: Tuesday, December 11, 2018 5:34 PM
>To: Parshuram Raju Thombare
>Cc: ax...@kernel.dk; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com; mchehab+sams...@kernel.org;
>da...@davemloft.net; a...@linux-foundation.org;
>nicolas.fe...@microchip.com; a...@arndb.de; linux-kernel@vger.kernel.org;
>linux-bl...@vger.kernel.org; linux-s...@vger.kernel.org; Alan Douglas
>; Janek Kotas ; Rafal Ciepiela
>
>Subject: Re: [PATCH 2/2] scsi: ufs: add inline crypto support to UFS HCD
>
>EXTERNAL MAIL
>
>
>On Tue, Dec 11, 2018 at 09:50:27AM +, Parshuram Thombare wrote:
>> Add real time crypto support to UFS HCD using new device mapper
>> 'crypto-ufs'. dmsetup tool can be used to enable real time / inline
>> crypto support using device mapper 'crypt-ufs'.
>>
>> Signed-off-by: Parshuram Thombare
>
>As you cc:ed me, I'll provide some minor review comments:
>
>> +config BLK_DEV_HW_RT_ENCRYPTION
>> +bool
>> +depends on SCSI_UFSHCD_RT_ENCRYPTION
>> +default n
>
>n is always the default, you never need to list that.
Ok, I will remove it.
>
>> +
>> source block/Kconfig.iosched
>> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index
>> 2ddbb26..09a3ec0 100644
>> --- a/drivers/scsi/ufs/Kconfig
>> +++ b/drivers/scsi/ufs/Kconfig
>> @@ -136,3 +136,15 @@ config SCSI_UFS_BSG
>>
>>Select this if you need a bsg device node for your UFS controller.
>>If unsure, say N.
>> +
>> +config SCSI_UFSHCD_RT_ENCRYPTION
>> +bool "Universal Flash Storage Controller RT encryption support"
>> +depends on SCSI_UFSHCD
>> +default n
>
>Same here.
>
Ok, I will remove it.
>> +select BLK_DEV_HW_RT_ENCRYPTION if SCSI_UFSHCD_RT_ENCRYPTION
>> +select BLK_DEV_DM if SCSI_UFSHCD_RT_ENCRYPTION
>> +help
>> +Universal Flash Storage Controller RT encryption support
>> +
>> +Select this if you want to enable real time encryption on UFS controller
>> +If unsure, say N.
>
>Don't you need to indent the help lines?
>
Sorry, missed indentation check here. I will indent this.
>> +int ufshcd_crypto_init(struct ufs_hba *hba); void
>> +ufshcd_crypto_remove(struct ufs_hba *hba); void
>> +ufshcd_prepare_for_crypto(struct ufs_hba *hba, struct ufshcd_lrb
>> +*lrbp); #endif
>
>You need to provide inline functions for when your config option is not enabled
>here.
>
>That way you don't have to do this mess:
>
Do you mean empty inline function (which are exported) in #else to avoid
#ifdef
around each call for these functions ?
>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>> index 86fe114..a96b038 100644
>> --- a/drivers/scsi/ufs/ufshcd.c
>> +++ b/drivers/scsi/ufs/ufshcd.c
>> @@ -47,6 +47,9 @@
>> #include "unipro.h"
>> #include "ufs-sysfs.h"
>> #include "ufs_bsg.h"
>> +#ifdef CONFIG_SCSI_UFSHCD_RT_ENCRYPTION #include "ufshcd-crypto.h"
>> +#endif
>
>No need for #ifdefs in .c files at all. Always include the .h file, and then
>since your
>functions are all inline void functions, the code just compiles away into
>nothing.
>
>
Ok, I will remove it.
>>
>> #define CREATE_TRACE_POINTS
>> #include
>> @@ -2198,6 +2201,14 @@ static void ufshcd_prepare_req_desc_hdr(struct
>> ufshcd_lrb *lrbp,
>>
>> dword_0 = data_direction | (lrbp->command_type
>> << UPIU_COMMAND_TYPE_OFFSET);
>> +#ifdef CONFIG_SCSI_UFSHCD_RT_ENCRYPTION
>> +if (lrbp->cci >= 0) {
>> +dword_0 |= (1 <<
>CRYPTO_UTP_REQ_DESC_DWORD0_CE_SHIFT);
>> +dword_0 |= ((lrbp->cci <<
>CRYPTO_UTP_REQ_DESC_DWORD0_CCI_SHIFT)
>> +&
>CRYPTO_UTP_REQ_DESC_DWORD0_CCI_MASK);
>> +} else
>> +dword_0 &= ~CRYPTO_UTP_REQ_DESC_DWORD0_CE_MASK;
>> +#endif
>
>Some comments on what this is trying to do here?
>
>
This is to enable encryption by setting CCI (crypto config index) and CE crypto
enable bit.
I will add comment here.
>> if (lrbp->intr_cmd)
>> dword_0 |= UTP_REQ_DESC_INT_CMD;
>>
>> @@ -2462,6 +2473,12 @@ static int ufshcd_queuecommand(struct Scsi_Host
>*host, struct scsi_cmnd *cmd)
>> lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba) ? true : false;
>> lrbp->req_abort_skip = false;
>>
>> +#ifdef CONFIG_SCSI_UFSHCD_RT_ENCRYPTION
>> +lrbp->cci = -1;
>
>What does -1 mean? You should have a type for it if it is something "special".
>
-1 means crypto is not enabled or supported by hardware. I think this need a
comment.
I will add it.
>> +/* prepare block for crypto */
>> +if (hba->capabilities & MASK_CRYPTO_SUPPORT)
>> +ufshcd_prepare_for_crypto(hba, lrbp); #endif
>
>Again, no #ifdefs needed please.
>
>
Ok, I will remove it.
>> ufshcd_comp_scsi_upiu(hba, lrbp);
>>
>> err = ufshcd_map_sg(hba, lrbp);
>> @@ -8119,6 +8136,11 @@ void ufshcd_remove(struct ufs_hba *hba)
>> ufs_bsg_remove(hba);
>> ufs_sysfs_remove_nodes(hba->dev);
>> scsi_remove_host(hb
Re: linux-next: manual merge of the phy-next tree with Linus' tree
Hi, On 12/12/18 10:42 AM, Stephen Rothwell wrote: > Hi Kishon, > > On Wed, 12 Dec 2018 10:37:37 +0530 Kishon Vijay Abraham I > wrote: >> >> I've rebased by 'next' branch on top of my 'fixes' branch to avoid this >> conflict. > > Why didn't you just merge them? Merging will create a new merge commit which I can avoid by rebasing. Also the patches in next branch will be above the patches in fixes branch. Thanks Kishon >
[PATCH v5 4/5] PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set
We are compiling PCI code today for systems with ACPI and no PCI
device present. Remove the useless code and reduce the tight
dependency.
Signed-off-by: Sinan Kaya
---
arch/x86/include/asm/pci_x86.h | 7 +++
drivers/acpi/Kconfig | 1 -
drivers/acpi/Makefile | 2 +-
drivers/acpi/internal.h| 5 +
drivers/pci/Makefile | 2 +-
include/acpi/acpi_drivers.h| 7 +++
include/linux/acpi.h | 7 +++
include/linux/pci.h| 4
8 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 959d618dbb17..73bb404f4d2a 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -121,7 +121,14 @@ extern void __init dmi_check_pciprobe(void);
extern void __init dmi_check_skip_isa_align(void);
/* some common used subsys_initcalls */
+#ifdef CONFIG_PCI
extern int __init pci_acpi_init(void);
+#else
+static inline int __init pci_acpi_init(void)
+{
+ return -EINVAL;
+}
+#endif
extern void __init pcibios_irq_init(void);
extern int __init pcibios_init(void);
extern int pci_legacy_init(void);
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7cea769c37df..a0abcb3bd673 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -9,7 +9,6 @@ config ARCH_SUPPORTS_ACPI
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on ARCH_SUPPORTS_ACPI
- depends on PCI
select PNP
default y if X86
help
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index edc039313cd6..7c6afc111d76 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
-acpi-y += pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI) += pci_root.o pci_link.o pci_irq.o
obj-$(CONFIG_ACPI_MCFG)+= pci_mcfg.o
acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 530a3f675490..b7060dae2789 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -25,8 +25,13 @@ int acpi_osi_init(void);
acpi_status acpi_os_initialize1(void);
void init_acpi_device_notify(void);
int acpi_scan_init(void);
+#ifdef CONFIG_PCI
void acpi_pci_root_init(void);
void acpi_pci_link_init(void);
+#else
+static inline void acpi_pci_root_init(void) {}
+static inline void acpi_pci_link_init(void) {}
+#endif
void acpi_processor_init(void);
void acpi_platform_init(void);
void acpi_pnp_init(void);
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index f2bda77a2df1..657d642fcc67 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -11,6 +11,7 @@ ifdef CONFIG_PCI
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_SYSFS)+= slot.o
obj-$(CONFIG_OF) += of.o
+obj-$(CONFIG_ACPI) += pci-acpi.o
endif
obj-$(CONFIG_PCI_QUIRKS) += quirks.o
@@ -20,7 +21,6 @@ obj-$(CONFIG_PCI_MSI) += msi.o
obj-$(CONFIG_PCI_ATS) += ats.o
obj-$(CONFIG_PCI_IOV) += iov.o
obj-$(CONFIG_PCI_BRIDGE_EMUL) += pci-bridge-emul.o
-obj-$(CONFIG_ACPI) += pci-acpi.o
obj-$(CONFIG_PCI_LABEL)+= pci-label.o
obj-$(CONFIG_X86_INTEL_MID)+= pci-mid.o
obj-$(CONFIG_PCI_SYSCALL) += syscall.o
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index 14499757338f..de1804aeaf69 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -88,7 +88,14 @@ int acpi_pci_link_free_irq(acpi_handle handle);
struct pci_bus;
+#ifdef CONFIG_PCI
struct pci_dev *acpi_get_pci_dev(acpi_handle);
+#else
+static inline struct pci_dev *acpi_get_pci_dev(acpi_handle handle)
+{
+ return NULL;
+}
+#endif
/* Arch-defined function to add a bus to the system */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index ed80f147bd50..eb1fdf4c196a 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -340,7 +340,14 @@ struct pci_dev;
int acpi_pci_irq_enable (struct pci_dev *dev);
void acpi_penalize_isa_irq(int irq, int active);
bool acpi_isa_irq_available(int irq);
+#ifdef CONFIG_PCI
void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
+#else
+static inline void acpi_penalize_sci_irq(int irq, int trigger,
+ int polarity)
+{
+}
+#endif
void acpi_pci_irq_disable (struct pci_dev *dev);
extern int ec_read(u8 addr, u8 *val);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 11c71c4ecf75..51a5a5217667 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1960,7 +1960,11 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev
[PATCH v5 2/5] ACPI / OSL: Stub out acpi_os_read_pci_configuration when CONFIG_PCI is unset
Getting ready to allow PCI to be disabled with ACPI enabled. Stub out
acpi_os_read_pci_configuration function that depend on PCI.
Signed-off-by: Sinan Kaya
---
drivers/acpi/osl.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index b48874b8e1ea..3e82b50ba811 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -773,6 +773,7 @@ acpi_status
acpi_os_read_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
u64 *value, u32 width)
{
+#ifdef CONFIG_PCI
int result, size;
u32 value32;
@@ -799,6 +800,9 @@ acpi_os_read_pci_configuration(struct acpi_pci_id * pci_id,
u32 reg,
*value = value32;
return (result ? AE_ERROR : AE_OK);
+#else
+ return pr_warn_once("CONFIG_PCI is disabled\n") ? AE_SUPPORT : AE_OK;
+#endif
}
acpi_status
--
2.19.0
[PATCH v5 5/5] ACPI / OSL: Remove PCI bits from ACPICA when CONFIG_PCI is unset
Now that we allow CONFIG_PCI to be unset, remove useless code from ACPICA
too.
Signed-off-by: Sinan Kaya
---
drivers/acpi/acpica/Makefile | 2 +-
drivers/acpi/osl.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index b14621da5413..59700433a96e 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -77,13 +77,13 @@ acpi-y += \
hwacpi.o\
hwesleep.o \
hwgpe.o \
- hwpci.o \
hwregs.o\
hwsleep.o \
hwvalid.o \
hwxface.o \
hwxfsleep.o
+acpi-$(CONFIG_PCI) += hwpci.o
acpi-$(ACPI_FUTURE_USAGE) += hwtimer.o
acpi-y += \
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 7b1e58f93f37..8b8eb17df3f2 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1837,3 +1837,12 @@ acpi_status acpi_os_enter_sleep(u8 sleep_state,
reg_a_value, reg_b_value);
return status;
}
+
+#ifndef CONFIG_PCI
+acpi_status acpi_hw_derive_pci_id(struct acpi_pci_id *pci_id,
+ acpi_handle root_pci_device, acpi_handle pci_region)
+{
+ return AE_SUPPORT;
+}
+#endif
+
--
2.19.0
[PATCH v2 1/2] Doc: bindings: Add binding doc for nxp system counter timer
Add the binding doc for nxp system counter timer module.
Signed-off-by: Bai Ping
---
change v1->v2
- remove the blank line at EOF
---
.../devicetree/bindings/timer/nxp,sysctr_timer.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr_timer.txt
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr_timer.txt
b/Documentation/devicetree/bindings/timer/nxp,sysctr_timer.txt
new file mode 100644
index 000..21f1527
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,sysctr_timer.txt
@@ -0,0 +1,26 @@
+NXP System Counter Module(sys_ctr)
+
+The system counter(sys_ctr) is a programmable system counter which provides
+a shared time base to Cortex A15, A7, A53, A73, etc. it is intended for use in
+applications where the counter is always powered and support multiple,
+unrelated clocks.
+
+Required properties:
+
+- compatible : should be "nxp,sysctr-timer"
+- reg : Specifies the base physical address and size of the comapre
+frame and the counter control, read & compare.
+- interrupts : should be the compare frames' interrupt
+- clock-frequency : Specifies the counter clock frequency.
+
+Example:
+
+ system_counter: timer@306a {
+ compatible = "nxp,sysctr-timer";
+ reg = <0x0 0x306a 0x0 0x1>, /* system-counter-rd base */
+ <0x0 0x306b 0x0 0x1>, /* system-counter-cmp base
*/
+ <0x0 0x306c 0x0 0x1>; /* system-counter-ctrl base
*/
+ clock-frequency = <800>;
+ interrupts = ,
+;
+ };
--
1.9.1
[PATCH v5 3/5] ACPI / OSL: Stub out acpi_os_write_pci_configuration when CONFIG_PCI is unset
Getting ready to allow PCI to be disabled with ACPI enabled. Stub out
acpi_os_write_pci_configuration function that depend on PCI.
Signed-off-by: Sinan Kaya
---
drivers/acpi/osl.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3e82b50ba811..7b1e58f93f37 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -809,6 +809,7 @@ acpi_status
acpi_os_write_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
u64 value, u32 width)
{
+#ifdef CONFIG_PCI
int result, size;
switch (width) {
@@ -830,6 +831,9 @@ acpi_os_write_pci_configuration(struct acpi_pci_id *
pci_id, u32 reg,
reg, size, value);
return (result ? AE_ERROR : AE_OK);
+#else
+ return pr_warn_once("CONFIG_PCI is disabled\n") ? AE_SUPPORT : AE_OK;
+#endif
}
static void acpi_os_execute_deferred(struct work_struct *work)
--
2.19.0
[PATCH v2 2/2] driver: clocksource: Add nxp system counter timer driver support
The system counter (sys_ctr) is a programmable system counter
which provides a shared time base to the Cortex A15, A7, A53 etc cores.
It is intended for use in applications where the counter is always
powered on and supports multiple, unrelated clocks. The sys_ctr hardware
supports:
- 56-bit counter width (roll-over time greater than 40 years)
- compare frame(64-bit compare value) contains programmable interrupt
generation
Signed-off-by: Bai Ping
---
change v1->v2:
- no change
---
drivers/clocksource/Kconfig| 8 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-imx-sysctr.c | 204 +
3 files changed, 213 insertions(+)
create mode 100644 drivers/clocksource/timer-imx-sysctr.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index c57b156..7e5f2de 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -579,6 +579,14 @@ config CLKSRC_IMX_TPM
Enable this option to use IMX Timer/PWM Module (TPM) timer as
clocksource.
+config CLKSRC_IMX_SYS_CTR
+ bool "Clocksource using i.MX system counter" if COMPILE_TEST
+ depends on (ARM || ARM64) && CLKDEV_LOOKUP
+ select CLKSRC_MMIO
+ help
+ Enable this option to use IMX system counter timer as
+ clocksource.
+
config CLKSRC_ST_LPC
bool "Low power clocksource found in the LPC" if COMPILE_TEST
select TIMER_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dd91381..372bf4e 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
obj-$(CONFIG_CLKSRC_TANGO_XTAL)+= tango_xtal.o
obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
+obj-$(CONFIG_CLKSRC_IMX_SYS_CTR) += timer-imx-sysctr.o
obj-$(CONFIG_ASM9260_TIMER)+= asm9260_timer.o
obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
diff --git a/drivers/clocksource/timer-imx-sysctr.c
b/drivers/clocksource/timer-imx-sysctr.c
new file mode 100644
index 000..ad3c27f
--- /dev/null
+++ b/drivers/clocksource/timer-imx-sysctr.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2017-2018 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CNTCV_LO 0x8
+#define CNTCV_HI 0xc
+#define CMPCV_LO 0x20
+#define CMPCV_HI 0x24
+#define CMPCR 0x2c
+
+#define SYS_CTR_EN 0x1
+#define SYS_CTR_IRQ_MASK 0x2
+
+static void __iomem *sys_ctr_rd_base;
+static void __iomem *sys_ctr_cmp_base;
+static struct clock_event_device clockevent_sysctr;
+
+static inline void sysctr_timer_enable(bool enable)
+{
+ u32 val;
+
+ val = readl(sys_ctr_cmp_base + CMPCR);
+ val &= ~SYS_CTR_EN;
+ if (enable)
+ val |= SYS_CTR_EN;
+
+ writel(val, sys_ctr_cmp_base + CMPCR);
+}
+
+static void sysctr_irq_acknowledge(void)
+{
+ u32 val;
+
+ /* clear th enable bit(EN=0) to clear the ISTAT */
+ val = readl(sys_ctr_cmp_base + CMPCR);
+ val &= ~SYS_CTR_EN;
+ writel(val, sys_ctr_cmp_base + CMPCR);
+}
+
+static inline u64 sysctr_read_counter(void)
+{
+ u32 cnt_hi, tmp_hi, cnt_lo;
+
+ do {
+ cnt_hi = readl_relaxed(sys_ctr_rd_base + CNTCV_HI);
+ cnt_lo = readl_relaxed(sys_ctr_rd_base + CNTCV_LO);
+ tmp_hi = readl_relaxed(sys_ctr_rd_base + CNTCV_HI);
+ } while (tmp_hi != cnt_hi);
+
+ return ((u64) cnt_hi << 32) | cnt_lo;
+}
+
+static u64 notrace sysctr_read_sched_clock(void)
+{
+ return sysctr_read_counter();
+}
+
+static u64 sysctr_clocksource_read(struct clocksource *cs)
+{
+ return sysctr_read_counter();
+}
+
+static int __init sysctr_clocksource_init(unsigned int rate)
+{
+ sched_clock_register(sysctr_read_sched_clock, 56, rate);
+ return clocksource_mmio_init(sys_ctr_rd_base, "i.MX sys_ctr",
+rate, 200, 56, sysctr_clocksource_read);
+}
+
+static int sysctr_set_next_event(unsigned long delta,
+struct clock_event_device *evt)
+{
+ u32 cmp_hi, cmp_lo;
+ u64 next;
+
+ sysctr_timer_enable(false);
+
+ next = sysctr_read_counter();
+
+ next += delta;
+
+ cmp_hi = (next >> 32) & 0x00f;
+ cmp_lo = next & 0x;
+
+ writel_relaxed(cmp_hi, sys_ctr_cmp_base + CMPCV_HI);
+ writel_relaxed(cmp_lo, sys_ctr_cmp_base + CMPCV_LO);
+
+ sysctr_timer_enable(true);
+
+ return 0;
+}
+
+static int sysctr_set_state_oneshot(struct clock_event_device *evt)
+{
+ /* enable timer */
+ sysctr_timer_enable(true);
+
+ return 0;
+}
+
+static int sysctr_set_state_shutdown(struct clock_
[PATCH v5 1/5] ACPI: Allow CONFIG_PCI to be unset for reboot
Make PCI reboot conditional on PCI support being present on the kernel
configuration.
Signed-off-by: Sinan Kaya
---
drivers/acpi/reboot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index 6fa9c2a4cfe9..d75e637ee36a 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -7,8 +7,6 @@
void acpi_reboot(void)
{
struct acpi_generic_address *rr;
- struct pci_bus *bus0;
- unsigned int devfn;
u8 reset_value;
if (acpi_disabled)
@@ -33,6 +31,11 @@ void acpi_reboot(void)
* on a device on bus 0. */
switch (rr->space_id) {
case ACPI_ADR_SPACE_PCI_CONFIG:
+ {
+#ifdef CONFIG_PCI
+ unsigned int devfn;
+ struct pci_bus *bus0;
+
/* The reset register can only live on bus 0. */
bus0 = pci_find_bus(0, 0);
if (!bus0)
@@ -44,8 +47,9 @@ void acpi_reboot(void)
/* Write the value that resets us. */
pci_bus_write_config_byte(bus0, devfn,
(rr->address & 0x), reset_value);
+#endif
break;
-
+ }
case ACPI_ADR_SPACE_SYSTEM_MEMORY:
case ACPI_ADR_SPACE_SYSTEM_IO:
printk(KERN_DEBUG "ACPI MEMORY or I/O RESET_REG.\n");
--
2.19.0
RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Hi Boris & Miquel, An update to my comments on thread https://lkml.org/lkml/2018/11/15/656. In this I said, will take a default error count value as 16 and during page read, will check the error count Register value with this and if it is equal to or greater than the default count(16) then I am checking for Erased pages. But bit[7:0] in ECC_Error_Count_Register(0x38) will update for each error occurred. Link: https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html and check for NAND module, ECC_Error_Count_Register. I mean previously I dependent on Total error count value (bit[16:8]), but we can simply check for bit[7:0] To see the error occurred or not. I tried with this approach and I don't see any issues with that. I ran ubifs with this and I am able to see the bit[7:0] count is updated for erased page read and then will Use nand_chech_erased_ecc_chunk() to see the bitflips. If it is ok, I will update the driver and will send new patch, but do you have any other comments on v12? Thanks, Naga Sureshkumar Relli > -Original Message- > From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of > Naga > Sureshkumar Relli > Sent: Friday, November 23, 2018 7:24 PM > To: Miquel Raynal ; Boris Brezillon > > Cc: r...@kernel.org; rich...@nod.at; linux-kernel@vger.kernel.org; > marek.va...@gmail.com; > linux-...@lists.infradead.org; nagasures...@gmail.com; Michal Simek > ; computersforpe...@gmail.com; dw...@infradead.org > Subject: RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for > Arasan > NAND Flash Controller > > Hi Boris & Miquel, > > > -Original Message- > > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > > Sent: Tuesday, November 20, 2018 6:06 PM > > To: Boris Brezillon > > Cc: Naga Sureshkumar Relli ; rich...@nod.at; > > dw...@infradead.org; computersforpe...@gmail.com; marek.va...@gmail.com; > > linux- > > m...@lists.infradead.org; linux-kernel@vger.kernel.org; > > nagasures...@gmail.com; > > r...@kernel.org; Michal Simek > > Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for > > Arasan > > NAND Flash Controller > > > > Hi Naga, > > > > Boris Brezillon wrote on Tue, 20 Nov 2018 > > 12:02:44 +0100: > > > > > On Tue, 20 Nov 2018 07:02:08 + > > > Naga Sureshkumar Relli wrote: > > > > > > > > > > > > > > > > Can you please run nandbiterrs (availaible in mtd-utils). I fear your > > > > > device won't pass the test. > > > > Yes, nandbiterror test is passing till 24bit, after that it is failing. > > > > > > Can you paste the output of nandbiterrs please? > > > > Apparently 'nandbiterrs -i 'just crashes the kernel because of a > > segmentation fault. Please > run > > this test (from the mtd-utils package) and fix this issue. Then we would > > like to see the > output. > Here is the output of mtd_nandbiterrs, > [ 1830.546807] mtd_nandbiterrs: verify_page > [ 1830.551924] mtd_nandbiterrs: Successfully corrected 8 bit errors per > subpage > [ 1830.558961] mtd_nandbiterrs: Inserted biterror @ 2/5 > [ 1830.563917] mtd_nandbiterrs: rewrite page > [ 1830.568216] mtd_nandbiterrs: read_page > [ 1830.572155] mtd_nandbiterrs: verify_page > [ 1830.576531] mtd_nandbiterrs: Successfully corrected 9 bit errors per > subpage > [ 1830.583568] mtd_nandbiterrs: Inserted biterror @ 2/2 > [ 1830.588527] mtd_nandbiterrs: rewrite page > [ 1830.592881] mtd_nandbiterrs: read_page > [ 1830.596825] mtd_nandbiterrs: verify_page > [ 1830.601197] mtd_nandbiterrs: Successfully corrected 10 bit errors per > subpage > [ 1830.608326] mtd_nandbiterrs: Inserted biterror @ 2/0 > [ 1830.613279] mtd_nandbiterrs: rewrite page > [ 1830.617585] mtd_nandbiterrs: read_page > [ 1830.621524] mtd_nandbiterrs: verify_page > [ 1830.625900] mtd_nandbiterrs: Successfully corrected 11 bit errors per > subpage > [ 1830.633027] mtd_nandbiterrs: Inserted biterror @ 3/7 > [ 1830.637984] mtd_nandbiterrs: rewrite page > [ 1830.642281] mtd_nandbiterrs: read_page > [ 1830.646223] mtd_nandbiterrs: verify_page > [ 1830.650595] mtd_nandbiterrs: Successfully corrected 12 bit errors per > subpage > [ 1830.657724] mtd_nandbiterrs: Inserted biterror @ 3/6 > [ 1830.662677] mtd_nandbiterrs: rewrite page > [ 1830.666983] mtd_nandbiterrs: read_page > [ 1830.670922] mtd_nandbiterrs: verify_page > [ 1830.675296] mtd_nandbiterrs: Successfully corrected 13 bit errors per > subpage > [ 1830.682417] mtd_nandbiterrs: Inserted biterror @ 3/5 > [ 1830.687373] mtd_nandbiterrs: rewrite page > [ 1830.691671] mtd_nandbiterrs: read_page > [ 1830.695610] mtd_nandbiterrs: verify_page > [ 1830.699983] mtd_nandbiterrs: Successfully corrected 14 bit errors per > subpage > [ 1830.707113] mtd_nandbiterrs: Inserted biterror @ 3/2 > [ 1830.712067] mtd_nandbiterrs: rewrite page > [ 1830.716494] mtd_nandbiterrs: read_page > [ 1830.720459] mtd_nandbiterrs: verify_page > [ 1830.724841] mtd_nandbiterrs: Successfully corrected 15 bit errors per > subpage > [ 1830.
[PATCH v4 3/4] PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set
We are compiling PCI code today for systems with ACPI and no PCI
device present. Remove the useless code and reduce the tight
dependency.
Signed-off-by: Sinan Kaya
---
arch/x86/include/asm/pci_x86.h | 7 +++
drivers/acpi/Kconfig | 1 -
drivers/acpi/Makefile | 2 +-
drivers/acpi/internal.h| 5 +
drivers/pci/Makefile | 2 +-
include/acpi/acpi_drivers.h| 7 +++
include/linux/acpi.h | 7 +++
include/linux/pci.h| 4
8 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 959d618dbb17..73bb404f4d2a 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -121,7 +121,14 @@ extern void __init dmi_check_pciprobe(void);
extern void __init dmi_check_skip_isa_align(void);
/* some common used subsys_initcalls */
+#ifdef CONFIG_PCI
extern int __init pci_acpi_init(void);
+#else
+static inline int __init pci_acpi_init(void)
+{
+ return -EINVAL;
+}
+#endif
extern void __init pcibios_irq_init(void);
extern int __init pcibios_init(void);
extern int pci_legacy_init(void);
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7cea769c37df..a0abcb3bd673 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -9,7 +9,6 @@ config ARCH_SUPPORTS_ACPI
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on ARCH_SUPPORTS_ACPI
- depends on PCI
select PNP
default y if X86
help
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index edc039313cd6..7c6afc111d76 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
-acpi-y += pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI) += pci_root.o pci_link.o pci_irq.o
obj-$(CONFIG_ACPI_MCFG)+= pci_mcfg.o
acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 530a3f675490..b7060dae2789 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -25,8 +25,13 @@ int acpi_osi_init(void);
acpi_status acpi_os_initialize1(void);
void init_acpi_device_notify(void);
int acpi_scan_init(void);
+#ifdef CONFIG_PCI
void acpi_pci_root_init(void);
void acpi_pci_link_init(void);
+#else
+static inline void acpi_pci_root_init(void) {}
+static inline void acpi_pci_link_init(void) {}
+#endif
void acpi_processor_init(void);
void acpi_platform_init(void);
void acpi_pnp_init(void);
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index f2bda77a2df1..657d642fcc67 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -11,6 +11,7 @@ ifdef CONFIG_PCI
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_SYSFS)+= slot.o
obj-$(CONFIG_OF) += of.o
+obj-$(CONFIG_ACPI) += pci-acpi.o
endif
obj-$(CONFIG_PCI_QUIRKS) += quirks.o
@@ -20,7 +21,6 @@ obj-$(CONFIG_PCI_MSI) += msi.o
obj-$(CONFIG_PCI_ATS) += ats.o
obj-$(CONFIG_PCI_IOV) += iov.o
obj-$(CONFIG_PCI_BRIDGE_EMUL) += pci-bridge-emul.o
-obj-$(CONFIG_ACPI) += pci-acpi.o
obj-$(CONFIG_PCI_LABEL)+= pci-label.o
obj-$(CONFIG_X86_INTEL_MID)+= pci-mid.o
obj-$(CONFIG_PCI_SYSCALL) += syscall.o
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index 14499757338f..de1804aeaf69 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -88,7 +88,14 @@ int acpi_pci_link_free_irq(acpi_handle handle);
struct pci_bus;
+#ifdef CONFIG_PCI
struct pci_dev *acpi_get_pci_dev(acpi_handle);
+#else
+static inline struct pci_dev *acpi_get_pci_dev(acpi_handle handle)
+{
+ return NULL;
+}
+#endif
/* Arch-defined function to add a bus to the system */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index ed80f147bd50..eb1fdf4c196a 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -340,7 +340,14 @@ struct pci_dev;
int acpi_pci_irq_enable (struct pci_dev *dev);
void acpi_penalize_isa_irq(int irq, int active);
bool acpi_isa_irq_available(int irq);
+#ifdef CONFIG_PCI
void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
+#else
+static inline void acpi_penalize_sci_irq(int irq, int trigger,
+ int polarity)
+{
+}
+#endif
void acpi_pci_irq_disable (struct pci_dev *dev);
extern int ec_read(u8 addr, u8 *val);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 11c71c4ecf75..51a5a5217667 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1960,7 +1960,11 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev
[PATCH v4 4/4] ACPI / OSL: Remove PCI bits from ACPICA when CONFIG_PCI is unset
Now that we allow CONFIG_PCI to be unset, remove useless code from ACPICA
too.
Signed-off-by: Sinan Kaya
---
drivers/acpi/acpica/Makefile | 2 +-
drivers/acpi/osl.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index b14621da5413..59700433a96e 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -77,13 +77,13 @@ acpi-y += \
hwacpi.o\
hwesleep.o \
hwgpe.o \
- hwpci.o \
hwregs.o\
hwsleep.o \
hwvalid.o \
hwxface.o \
hwxfsleep.o
+acpi-$(CONFIG_PCI) += hwpci.o
acpi-$(ACPI_FUTURE_USAGE) += hwtimer.o
acpi-y += \
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 7b1e58f93f37..8b8eb17df3f2 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1837,3 +1837,12 @@ acpi_status acpi_os_enter_sleep(u8 sleep_state,
reg_a_value, reg_b_value);
return status;
}
+
+#ifndef CONFIG_PCI
+acpi_status acpi_hw_derive_pci_id(struct acpi_pci_id *pci_id,
+ acpi_handle root_pci_device, acpi_handle pci_region)
+{
+ return AE_SUPPORT;
+}
+#endif
+
--
2.19.0
[PATCH v4 2/4] ACPI / OSL: Stub out acpi_os_write_pci_configuration when CONFIG_PCI is unset
Getting ready to allow PCI to be disabled with ACPI enabled. Stub out
acpi_os_write_pci_configuration function that depend on PCI.
Signed-off-by: Sinan Kaya
---
drivers/acpi/osl.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3e82b50ba811..7b1e58f93f37 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -809,6 +809,7 @@ acpi_status
acpi_os_write_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
u64 value, u32 width)
{
+#ifdef CONFIG_PCI
int result, size;
switch (width) {
@@ -830,6 +831,9 @@ acpi_os_write_pci_configuration(struct acpi_pci_id *
pci_id, u32 reg,
reg, size, value);
return (result ? AE_ERROR : AE_OK);
+#else
+ return pr_warn_once("CONFIG_PCI is disabled\n") ? AE_SUPPORT : AE_OK;
+#endif
}
static void acpi_os_execute_deferred(struct work_struct *work)
--
2.19.0
[PATCH v4 1/4] ACPI / OSL: Stub out acpi_os_read_pci_configuration when CONFIG_PCI is unset
Getting ready to allow PCI to be disabled with ACPI enabled. Stub out
acpi_os_read_pci_configuration function that depend on PCI.
Signed-off-by: Sinan Kaya
---
drivers/acpi/osl.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index b48874b8e1ea..3e82b50ba811 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -773,6 +773,7 @@ acpi_status
acpi_os_read_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
u64 *value, u32 width)
{
+#ifdef CONFIG_PCI
int result, size;
u32 value32;
@@ -799,6 +800,9 @@ acpi_os_read_pci_configuration(struct acpi_pci_id * pci_id,
u32 reg,
*value = value32;
return (result ? AE_ERROR : AE_OK);
+#else
+ return pr_warn_once("CONFIG_PCI is disabled\n") ? AE_SUPPORT : AE_OK;
+#endif
}
acpi_status
--
2.19.0
Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
On (12/11/18 16:53), Daniel Wang wrote: > Is it okay to tag this commit with `Cc: sta...@vger.kernel.org` so > that it'll get applied to the stable trees once merged into Linux's > tree, if it's not too late? Otherwise I'll follow up on the stable > merges separately. Thanks for making the changes anyway. My bad! I should have Cc-ed stable on that one, sorry. I guess now it would be easier to wait and follow up once it gets merged. -ss
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
On (12/11/18 17:16), Daniel Wang wrote: > > Let's first figure out if it works. > > I would still like to try applying your patches that went into > printk.git, but for now I wonder if we can get Steven's patch into > 4.14 first, for at least we know it mitigated the issue if not > fundamentally addressed it, and we've agreed it's an innocuous change > that doesn't risk breaking stable. So... did my patch address the deadlock you are seeing or it didn't? > I haven't done this before so I'll need your help. What's the next > step to actually get Steven's patch *in* linux-4.14.y? According to > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > I am supposed to send an email with the patch ID and subject, which > are both mentioned in this email. Should I send another one? What's > the process like? Thanks! I'm not doing any -stable releases, so can't really answer, sorry. Probably would be better to re-address this question to 4.14 -stable maintainers. --- I guess we still don't have a really clear understanding of what exactly is going in your system. We don't even know for sure which one of the locks is deadlocking the system. And why exactly Steven's patch helps. If it is uart_port->lock, then it's one thing; if it's console_sem ->lock then it's another thing. But those two are just theories, not supported by any logs/backtraces from your systems. If it's uart_port->lock and there will be 2 patch sets to choose from for -stable, then -stable guys can pick up the one that requires less effort: 1 two-liner patch vs. 3 or 4 bigger patches. -ss
Re: [PATCH v2] lzo: fix ip overrun during compress.
Hi Markus,
OK, thanks. I`ll change it in v3.
Thanks,
Yueyi
On 2018/12/6 23:03, Markus F.X.J. Oberhumer wrote:
> Hi Yueyi,
>
> yes, my LZO patch works for all cases.
>
> The reason behind the issue in the first place is that if KASLR
> includes the very last page 0xf000 then we do not have a
> valid C "pointer to an object" anymore because of address wraparound.
>
> Unrelated to my patch I'd argue that KASLR should *NOT* include the
> very last page - indeed that might cause similar wraparound problems
> in lots of code.
>
> Eg, look at this simple clear_memory() implementation:
>
> void clear_memory(char *p, size_t len) {
> char *end = p + len;
> while (p < end)
> *p++= 0;
> }
>
> Valid code like this will fail horribly when (p, len) is the very
> last virtual page (because end will be the NULL pointer in this case).
>
> Cheers,
> Markus
>
>
>
> On 2018-12-05 04:07, Yueyi Li wrote:
>> Hi Markus,
>>
>> Thanks for your review.
>>
>> On 2018/12/4 18:20, Markus F.X.J. Oberhumer wrote:
>>> Hi,
>>>
>>> I don't think that address space wraparound is legal in C, but I
>>> understand that we are in kernel land and if you really want to
>>> compress the last virtual page 0xf000 the following
>>> small patch should fix that dubious case.
>> I guess the VA 0xf000 is available because KASLR be
>> enabled. For this case we can see:
>>
>> crash> kmem 0xf000
>> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>> ffbfffc01f000 1655ecb9 7181fd5 2
>> 80064209 locked,uptodate,owner_priv_1,writeback,reclaim,swapbacked
>>
>>> This also avoids slowing down the the hot path of the compression
>>> core function.
>>>
>>> Cheers,
>>> Markus
>>>
>>>
>>>
>>> diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c
>>> index 236eb21167b5..959dec45f6fe 100644
>>> --- a/lib/lzo/lzo1x_compress.c
>>> +++ b/lib/lzo/lzo1x_compress.c
>>> @@ -224,8 +224,8 @@ int lzo1x_1_compress(const unsigned char *in, size_t
>>> in_len,
>>>
>>> while (l > 20) {
>>> size_t ll = l <= (M4_MAX_OFFSET + 1) ? l : (M4_MAX_OFFSET
>>> + 1);
>>> - uintptr_t ll_end = (uintptr_t) ip + ll;
>>> - if ((ll_end + ((t + ll) >> 5)) <= ll_end)
>>> + // check for address space wraparound
>>> + if (((uintptr_t) ip + ll + ((t + ll) >> 5)) <= (uintptr_t)
>>> ip)
>>> break;
>>> BUILD_BUG_ON(D_SIZE * sizeof(lzo_dict_t) >
>>> LZO1X_1_MEM_COMPRESS);
>>> memset(wrkmem, 0, D_SIZE * sizeof(lzo_dict_t));
>> I parsed panic ramdump and loaded CPU register values, can see:
>>
>> -000|lzo1x_1_do_compress(
>> |in = 0xF000,
>> | ?,
>> |out = 0x2E2EE000,
>> |out_len = 0xFF801CAA3510,
>> | ?,
>> |wrkmem = 0x4EBC)
>> | dict = 0x4EBC
>> | op = 0x1
>> | ip = 0x9
>> | ii = 0x9
>> | in_end = 0x0
>> | ip_end = 0xFFEC
>> | m_len = 0
>> | m_off = 1922
>> -001|lzo1x_1_compress(
>> |in = 0xF000,
>> |in_len = 0,
>> |out = 0x2E2EE000,
>> |out_len = 0x0001616FB7D0,
>> |wrkmem = 0x4EBC)
>> | ip = 0xF000
>> | op = 0x2E2EE000
>> | l = 4096
>> | t = 0
>> | ll = 4096
>>
>> ll = l = in_len = 4096 in lzo1x_1_compress, so your patch is working
>> for this panic case, but, I`m
>> not sure, is it possible that in = 0xF000 and in_len < 4096?
>>
>>
>> Thanks,
>> Yueyi
>>
[PATCH] arm64: dts: ti: k3-am654: Populate power-domain property for UART nodes
Populate power-domain property for UART nodes, this is required for
Linux to enable UART clocks via PM calls. Without this UART instances
not initialized by bootloader (like main_uart1) fails to work in Linux.
Also, drop current-speed property from main_uart1 and main_uart2 nodes
as these UARTs are not initialized before Linux boots up and current
speed is unknown.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi| 1 +
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 6c71e67b8988..272cf8fc8d30 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -48,6 +48,7 @@
interrupts = ;
clock-frequency = <4800>;
current-speed = <115200>;
+ power-domains = <&k3_pds 146>;
};
main_uart1: serial@281 {
@@ -57,7 +58,7 @@
reg-io-width = <4>;
interrupts = ;
clock-frequency = <4800>;
- current-speed = <115200>;
+ power-domains = <&k3_pds 147>;
};
main_uart2: serial@282 {
@@ -67,7 +68,7 @@
reg-io-width = <4>;
interrupts = ;
clock-frequency = <4800>;
- current-speed = <115200>;
+ power-domains = <&k3_pds 148>;
};
main_pmx0: pinmux@11c000 {
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 1aeae52fb239..593f718e8fb5 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -14,6 +14,7 @@
interrupts = ;
clock-frequency = <9600>;
current-speed = <115200>;
+ power-domains = <&k3_pds 149>;
};
mcu_i2c0: i2c@40b0 {
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index 9e8467ce7ad8..7cbdc0912ab7 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -50,6 +50,7 @@
interrupts = ;
clock-frequency = <4800>;
current-speed = <115200>;
+ power-domains = <&k3_pds 150>;
};
wkup_i2c0: i2c@4212 {
--
2.19.2
Re: [PATCH v2] mm: thp: fix flags for pmd migration when split
On Tue, Dec 11, 2018 at 11:21:44AM +0300, Konstantin Khlebnikov wrote:
> On 11.12.2018 8:12, Peter Xu wrote:
> > When splitting a huge migrating PMD, we'll transfer all the existing
> > PMD bits and apply them again onto the small PTEs. However we are
> > fetching the bits unconditionally via pmd_soft_dirty(), pmd_write()
> > or pmd_yound() while actually they don't make sense at all when it's
> > a migration entry. Fix them up by make it conditional.
> >
> > Note that if my understanding is correct about the problem then if
> > without the patch there is chance to lose some of the dirty bits in
> > the migrating pmd pages (on x86_64 we're fetching bit 11 which is part
> > of swap offset instead of bit 2) and it could potentially corrupt the
> > memory of an userspace program which depends on the dirty bit.
> >
> > CC: Andrea Arcangeli
> > CC: Andrew Morton
> > CC: "Kirill A. Shutemov"
> > CC: Matthew Wilcox
> > CC: Michal Hocko
> > CC: Dave Jiang
> > CC: "Aneesh Kumar K.V"
> > CC: Souptick Joarder
> > CC: Konstantin Khlebnikov
> > CC: linux...@kvack.org
> > CC: linux-kernel@vger.kernel.org
> > Signed-off-by: Peter Xu
> > ---
> > v2:
> > - fix it up for young/write/dirty bits too [Konstantin]
> > ---
> > mm/huge_memory.c | 15 ++-
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index f2d19e4fe854..b00941b3d342 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2157,11 +2157,16 @@ static void __split_huge_pmd_locked(struct
> > vm_area_struct *vma, pmd_t *pmd,
> > page = pmd_page(old_pmd);
> > VM_BUG_ON_PAGE(!page_count(page), page);
> > page_ref_add(page, HPAGE_PMD_NR - 1);
> > - if (pmd_dirty(old_pmd))
> > - SetPageDirty(page);
> > - write = pmd_write(old_pmd);
> > - young = pmd_young(old_pmd);
> > - soft_dirty = pmd_soft_dirty(old_pmd);
> > + if (unlikely(pmd_migration)) {
> > + soft_dirty = pmd_swp_soft_dirty(old_pmd);
> > + young = write = false;
> > + } else {
> > + if (pmd_dirty(old_pmd))
> > + SetPageDirty(page);
> > + write = pmd_write(old_pmd);
> > + young = pmd_young(old_pmd);
> > + soft_dirty = pmd_soft_dirty(old_pmd);
> > + }
>
> Write/read-only is encoded into migration entry.
> I suppose there should be something like this:
>
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2151,16 +2151,21 @@ static void __split_huge_pmd_locked(struct
> vm_area_struct *vma, pmd_t *pmd,
>
> entry = pmd_to_swp_entry(old_pmd);
> page = pfn_to_page(swp_offset(entry));
> + write = is_write_migration_entry(entry);
> + young = false;
> + soft_dirty = pmd_swp_soft_dirty(old_pmd);
> } else
> #endif
> + {
> page = pmd_page(old_pmd);
> + if (pmd_dirty(old_pmd))
> + SetPageDirty(page);
> + write = pmd_write(old_pmd);
> + young = pmd_young(old_pmd);
> + soft_dirty = pmd_soft_dirty(old_pmd);
> + }
> VM_BUG_ON_PAGE(!page_count(page), page);
> page_ref_add(page, HPAGE_PMD_NR - 1);
> - if (pmd_dirty(old_pmd))
> - SetPageDirty(page);
> - write = pmd_write(old_pmd);
> - young = pmd_young(old_pmd);
> - soft_dirty = pmd_soft_dirty(old_pmd);
>
> /*
> * Withdraw the table only after we mark the pmd entry invalid.
>
Oops yes, I missed the write bit. Thanks for pointing it out.
Should I repost with your authorship and your sign-off? Or even I'll
consider to directly drop the CONFIG_ARCH_ENABLE_THP_MIGRATION if with
that since I don't see much gain to keep it:
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f2d19e4fe854..aebade83cec9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2145,23 +2145,25 @@ static void __split_huge_pmd_locked(struct
vm_area_struct *vma, pmd_t *pmd,
*/
old_pmd = pmdp_invalidate(vma, haddr, pmd);
-#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
pmd_migration = is_pmd_migration_entry(old_pmd);
- if (pmd_migration) {
+ if (unlikely(pmd_migration)) {
swp_entry_t entry;
entry = pmd_to_swp_entry(old_pmd);
page = pfn_to_page(swp_offset(entry));
- } else
-#endif
+ write = is_write_migration_entry(entry);
+ young = false;
+ soft_dirty = pmd_swp_soft_dirty(old_pmd);
+ } else {
page = pmd_page(old_pmd);
+ if (pmd_dirty(old_pmd))
+ SetPageDirty(page);
+ write = pmd_write(old_pmd);
+ young = pmd_young(old_pmd);
+ soft_dirty = pmd_soft_dirty(old_pmd);
+ }
VM_BUG_ON_PAGE(!page
[PATCH] rtlwifi: Fix non-working BSS STA mode
Once BSS STA mode gets started, it can be scanned by other clients but cannot entablish a connection. Turns out the set_bcn_reg() and its *_set_beacon_related_registers() callbacks never get called so it has problem beaconing. Enable the function in rtl_op_bss_info_changed() can make BSS STA mode start to work. Signed-off-by: Kai-Heng Feng --- drivers/net/wireless/realtek/rtlwifi/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c index 4bf7967590ca..11d27a5cc576 100644 --- a/drivers/net/wireless/realtek/rtlwifi/core.c +++ b/drivers/net/wireless/realtek/rtlwifi/core.c @@ -1054,7 +1054,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw *hw, "BSS_CHANGED_BEACON_ENABLED\n"); /*start hw beacon interrupt. */ - /*rtlpriv->cfg->ops->set_bcn_reg(hw); */ + rtlpriv->cfg->ops->set_bcn_reg(hw); mac->beacon_enabled = 1; rtlpriv->cfg->ops->update_interrupt_mask(hw, rtlpriv->cfg->maps -- 2.17.1
Re: linux-next: manual merge of the phy-next tree with Linus' tree
Hi Kishon, On Wed, 12 Dec 2018 10:37:37 +0530 Kishon Vijay Abraham I wrote: > > I've rebased by 'next' branch on top of my 'fixes' branch to avoid this > conflict. Why didn't you just merge them? -- Cheers, Stephen Rothwell pgpz6d1Bd0Tqx.pgp Description: OpenPGP digital signature
[GIT PULL] PHY: for 4.21
Hi Greg, Please find the pull request for 4.21 merge window below. The major changes are, the set_mode ops now takes 2 arguments (mode and submode) instead of just 'mode'. The value in 'submode' will be specific to 'mode'. The other major change is PHY framework now gets 2 new APIs phy_configure() and phy_validate(). This will help MIPI D-PHYs and its consumers to use PHY framework. The MIPI PHY drivers and the GPU driver changes will be merged later. Apart from these, there are a couple of new PHY drivers: a freescale USB PHY driver and a TI Ethernet PHY driver. Please see the tag message for the list of changes. Let me know If I have to make any changes. Thanks Kishon The following changes since commit c88520db18ba0b9a41326c3b8680e7c09eb4c381: phy: qcom-qusb2: Fix HSTX_TRIM tuning with fused value for SDM845 (2018-11-21 13:13:58 +0530) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git tags/phy-for-4.21_v1 for you to fetch changes up to 2e38c2e7026a9846b5bdadf0bf82808ec2c2f446: phy: qcom-qmp: Expose provided clocks to DT (2018-12-12 10:02:12 +0530) phy: for 4.21 *) Change phy set_mode ops to take both mode and setmode as arguments *) Add phy_configure() and phy_validate() API's mostly used for MIPI D-PHY *) Add helpers to get default values of parameters define in MIPI D-PHY spec *) Add driver for TI's CPSW Port PHY Interface Mode selection *) Add driver for Cadence Sierra PHY used with USB and PCIe *) Add driver for Freescale i.MX8MQ USB3 PHY *) Fixes QMP PHY bindings to allow the clocks provided by the PHY to be pointed at in device tree *) Fix for using fully specified regions (in device tree) for configuring the second lane in dual lane PHYs in QMP PHY *) Add support for Allwinner H6 USB2 PHY in phy-sun4i-usb driver *) Update phy-rcar-gen3-usb driver to follow the hardware manual *) Add support for fine grained power management in mapphone-mdm6600 driver Signed-off-by: Kishon Vijay Abraham I Alan Douglas (2): dt-bindings: phy: Document cadence Sierra PHY bindings phy: cadence: Add driver for Sierra PHY Evan Green (4): dt-bindings: phy-qcom-qmp: Fix register underspecification phy: qcom-qmp: Utilize fully-specified DT registers dt-bindings: phy-qcom-qmp: Move #clock-cells to child phy: qcom-qmp: Expose provided clocks to DT Grygorii Strashko (9): phy: core: rework phy_set_mode to accept phy mode and submode phy: core: add PHY_MODE_ETHERNET phy: ocelot-serdes: convert to use eth phy mode and submode phy: mvebu-cp110-comphy: convert to use eth phy mode and submode phy: core: clean up unused ethernet specific phy modes dt-bindings: phy: add cpsw port interface mode selection phy bindings phy: ti: introduce phy-gmii-sel driver dt-bindings: net: ti: cpsw: switch to use phy-gmii-sel phy net: ethernet: ti: cpsw: add support for port interface mode selection phy Icenowy Zheng (3): dt-bindings: phy: add binding for Allwinner H6 USB2 PHY phy: sun4i-usb: add support for missing USB PHY index phy: sun4i-usb: add support for H6 USB2 PHY Li Jun (1): phy: add driver for Freescale i.MX8MQ USB3 PHY Lucas Stach (1): dt-bindings: phy: add binding for Freescale i.MX8MQ USB3 PHY Maxime Ripard (4): phy: Add MIPI D-PHY mode phy: Add configuration interface phy: Add MIPI D-PHY configuration options phy: dphy: Add configuration helpers Miquel Raynal (1): phy: mvebu-cp110-comphy: fix spelling in structure name Rob Herring (2): MAINTAINERS: Add Kishon as maintainer of PHY bindings phy: Use of_node_name_eq for node name comparisons Tony Lindgren (1): phy: mapphone-mdm6600: Improve phy related runtime PM calls Yoshihiro Shimoda (1): phy: renesas: rcar-gen3-usb2: follow the hardware manual procedure kbuild test robot (1): phy: ti: fix semicolon.cocci warnings Documentation/devicetree/bindings/net/cpsw.txt | 8 ++- Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt | 17 ++ Documentation/devicetree/bindings/phy/phy-cadence-sierra.txt | 67 +++ Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 77 ++- Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 8 +-- Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt| 68 MAINTAINERS | 1 + drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-- drivers/net/ethernet/mscc/ocelot.c | 9 +--- drivers/net/ethernet/ti/cpsw.c | 19 ++- drivers/phy/Kconfig | 9 dri
Re: linux-next: manual merge of the phy-next tree with Linus' tree
Hi,
On 12/12/18 9:46 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the phy-next tree got a conflict in:
>
> Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>
> between commit:
>
> 7243ec72b902 ("dt-bindings: phy-qcom-qmp: Fix several mistakes from prior
> commits")
>
> from Linus' tree and commit:
>
> 91fdc9b127c9 ("dt-bindings: phy-qcom-qmp: Fix register underspecification")
>
> from the phy-next tree.
>
> I fixed it up (I just used the latter veriosn of the conflicting line)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
I've rebased by 'next' branch on top of my 'fixes' branch to avoid this
conflict.
Thanks
Kishon
>
Re: [PATCH v6 06/10] soc: qcom: rpmhpd: Add RPMh power domain driver
On 12/12/2018 3:31 AM, Stephen Boyd wrote:
Quoting Rajendra Nayak (2018-12-11 01:49:34)
The RPMh power domain driver aggregates the corner votes from various
consumers for the ARC resources and communicates it to RPMh.
With RPMh we use 2 different numbering space for corners, one used
by the clients to express their performance needs, and another used
to communicate to RPMh hardware.
The clients express their performance requirements using a sparse
numbering space which are mapped to meaningful levels like RET, SVS,
NOMINAL, TURBO etc which then get mapped to another number space
between 0 and 15 which is communicated to RPMh. The sparse number space,
also referred to as vlvl is mapped to the continuous number space of 0
to 15, also referred to as hlvl, using command DB.
Some power domain clients could request a performance state only while
the CPU is active, while some others could request for a certain
performance state all the time regardless of the state of the CPU.
We handle this by internally aggregating the votes from both type of
clients and then send the aggregated votes to RPMh.
There are also 3 different types of Votes that are comunicated to RPMh
Why capitalize vote?
will fix,
for every resource.
1. ACTIVE_ONLY: This specifies the requirement for the resource when the
CPU is active
2. SLEEP: This specifies the requirement for the resource when the CPU
is going to sleep
3. WAKE_ONLY: This specifies the requirement for the resource when the
CPU is coming out of sleep to active state
Can you tab these in?
sure, will do
We add data for all power domains on sdm845 SoC as part of the patch.
The driver can be extended to support other SoCs which support RPMh
Signed-off-by: Rajendra Nayak
Reviewed-by: Ulf Hansson
Just minor nitpicks ahead and a warning.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f1b25fdcf2ad..dd6ca92985ee 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_QCOM_APR) += apr.o
obj-$(CONFIG_QCOM_LLCC) += llcc-slice.o
obj-$(CONFIG_QCOM_SDM845_LLCC) += llcc-sdm845.o
obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
+obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
Put this before RPMPD? At least it would be semi-sorted then.
okay, will do
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
new file mode 100644
index ..f993a86be48c
--- /dev/null
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -0,0 +1,417 @@
[..]
+
+static int rpmhpd_update_level_mapping(struct rpmhpd *rpmhpd)
+{
+ u8 buf[RPMH_ARC_MAX_LEVELS * RPMH_ARC_LEVEL_SIZE];
+ int i, j, len, ret;
+
+ len = cmd_db_read_aux_data_len(rpmhpd->res_name);
+ if (len <= 0)
+ return len;
+ else if (len > RPMH_ARC_MAX_LEVELS * RPMH_ARC_LEVEL_SIZE)
+ return -EINVAL;
+
+ ret = cmd_db_read_aux_data(rpmhpd->res_name, buf, len);
+ if (ret < 0)
+ return ret;
I've changed cmd_db_read_aux_data() and that change is winding through
the arm-soc tree. This will break in the compilation phase in
linux-next.
will resend these based on Andy's for-next
+
+ rpmhpd->level_count = len / RPMH_ARC_LEVEL_SIZE;
+
+ for (i = 0; i < rpmhpd->level_count; i++) {
+ rpmhpd->level[i] = 0;
+ for (j = 0; j < RPMH_ARC_LEVEL_SIZE; j++)
+ rpmhpd->level[i] |=
+ buf[i * RPMH_ARC_LEVEL_SIZE + j] << (8 * j);
+
+ /*
+* The AUX data may be zero padded. These 0 valued entries at
+* the end of the map must be ignored.
+*/
+ if (i > 0 && rpmhpd->level[i] == 0) {
+ rpmhpd->level_count = i;
+ break;
+ }
+ pr_debug("%s: ARC hlvl=%2d --> vlvl=%4u\n", rpmhpd->res_name, i,
+rpmhpd->level[i]);
+ }
+
+ return 0;
+}
+
+static int rpmhpd_probe(struct platform_device *pdev)
+{
+ int i, ret;
+ size_t num_pds;
+ struct device *dev = &pdev->dev;
+ struct genpd_onecell_data *data;
+ struct rpmhpd **rpmhpds;
+ const struct rpmhpd_desc *desc;
+
+ desc = of_device_get_match_data(dev);
+ if (!desc)
+ return -EINVAL;
+
+ rpmhpds = desc->rpmhpds;
+ num_pds = desc->num_pds;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->domains = devm_kcalloc(dev, num_pds, sizeof(*data->domains),
+GFP_KERNEL);
+ if (!data->domains)
+ return -ENOMEM;
+
+ data->num_domains = num_pds;
+
+ ret = cmd_db_ready();
Does this matter? I thought we forced cmd_db_ready() in the rpmh driver
probe, and that was the parent of all rpmh devices so we should be fine
to not need to check it again here?
sure, will remove.
thanks for the review
Re: [LKP] [tty] c96cf923a9: WARNING:possible_circular_locking_dependency_detected
On (12/12/18 12:42), Sergey Senozhatsky wrote: [..] > > >> [ 87.255156]CPU0CPU1 > > >> [ 87.255813] > > >> [ 87.256460] lock(&port_lock_key); > > >> [ 87.256973]lock(console_owner); > > >> [ 87.257829]lock(&port_lock_key); > > >> [ 87.258680] lock(&obj_hash[i].lock); > > So it's like > > CPU0CPU1 > > uart_shutdown() db->lock >uart_port->lock debug_print_object() > free_page() printk > debug_check_no_obj_freeduart_port->lock > db->lock > > > In this particular case we probably can just move free_page() > out of uart_port lock scope. Note that free_page()->MM can printk() > on its own. > [..] > > [1] > https://lore.kernel.org/lkml/1542653726-5655-8-git-send-email-long...@redhat.com/T/#u That said, I'd first try Waiman's patch. The one I suggested is more of a defense move - there are too many things happening under uart_port->lock. This is not the first time we see lockdep complaining about the way uart and the rest of the kernel interact. -ss
Re: [Resend PATCH V5 7/10] KVM: Make kvm_set_spte_hva() return int
On Thu, Dec 06, 2018 at 09:21:10PM +0800, lantianyu1...@gmail.com wrote: > From: Lan Tianyu > > The patch is to make kvm_set_spte_hva() return int and caller can > check return value to determine flush tlb or not. It would be helpful if the patch description told the reader which return value(s) mean that the caller should flush the tlb. I would guess that non-zero means to do the flush, but you should make that explicit. > Signed-off-by: Lan Tianyu For the powerpc bits: Acked-by: Paul Mackerras
RE: [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor
From: Marc Zyngier Sent: Friday, December 7, 2018 6:43 AM > > Add ARM64-specific code to enable Hyper-V. This code includes: > > * Detecting Hyper-V and initializing the guest/Hyper-V interface > > * Setting up Hyper-V's synthetic clocks > > * Making hypercalls using the HVC instruction > > * Setting up VMbus and stimer0 interrupts > > * Setting up kexec and crash handlers > > This commit message is a clear indication that this should be split in > at least 5 different patches. OK, I'll work on separating into multiple layered patches in the next version. > > > This code is architecture dependent code and is mostly driven by > > architecture independent code in the VMbus driver in drivers/hv/hv.c > > and drivers/hv/vmbus_drv.c. > > > > This code is built only when CONFIG_HYPERV is enabled. > > > > Signed-off-by: Michael Kelley > > Signed-off-by: K. Y. Srinivasan > > --- > > MAINTAINERS | 1 + > > arch/arm64/Makefile | 1 + > > arch/arm64/hyperv/Makefile | 2 + > > arch/arm64/hyperv/hv_hvc.S | 54 + > > arch/arm64/hyperv/hv_init.c | 441 +++ > > arch/arm64/hyperv/mshyperv.c | 178 ++ > > 6 files changed, 677 insertions(+) > > create mode 100644 arch/arm64/hyperv/Makefile > > create mode 100644 arch/arm64/hyperv/hv_hvc.S > > create mode 100644 arch/arm64/hyperv/hv_init.c > > create mode 100644 arch/arm64/hyperv/mshyperv.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 72f19cef4c48..326eeb32a0cd 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6837,6 +6837,7 @@ F:arch/x86/kernel/cpu/mshyperv.c > > F: arch/x86/hyperv > > F: arch/arm64/include/asm/hyperv-tlfs.h > > F: arch/arm64/include/asm/mshyperv.h > > +F: arch/arm64/hyperv > > F: drivers/hid/hid-hyperv.c > > F: drivers/hv/ > > F: drivers/input/serio/hyperv-keyboard.c > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > > index 6cb9fc7e9382..ad9ec0579553 100644 > > --- a/arch/arm64/Makefile > > +++ b/arch/arm64/Makefile > > @@ -106,6 +106,7 @@ core-y += arch/arm64/kernel/ arch/arm64/mm/ > > core-$(CONFIG_NET) += arch/arm64/net/ > > core-$(CONFIG_KVM) += arch/arm64/kvm/ > > core-$(CONFIG_XEN) += arch/arm64/xen/ > > +core-$(CONFIG_HYPERV) += arch/arm64/hyperv/ > > core-$(CONFIG_CRYPTO) += arch/arm64/crypto/ > > libs-y := arch/arm64/lib/ $(libs-y) > > core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile > > new file mode 100644 > > index ..988eda55330c > > --- /dev/null > > +++ b/arch/arm64/hyperv/Makefile > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +obj-y := hv_init.o hv_hvc.o mshyperv.o > > diff --git a/arch/arm64/hyperv/hv_hvc.S b/arch/arm64/hyperv/hv_hvc.S > > new file mode 100644 > > index ..82636969b4f2 > > --- /dev/null > > +++ b/arch/arm64/hyperv/hv_hvc.S > > @@ -0,0 +1,54 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > + > > +/* > > + * Microsoft Hyper-V hypervisor invocation routines > > + * > > + * Copyright (C) 2018, Microsoft, Inc. > > + * > > + * Author : Michael Kelley > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License version 2 as published > > + * by the Free Software Foundation. > > + * > > + * This program is distributed in the hope that it will be useful, but > > + * WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or > > + * NON INFRINGEMENT. See the GNU General Public License for more > > + * details. > > + */ > > + > > +#include > > + > > + .text > > +/* > > + * Do the HVC instruction. For Hyper-V the argument is always 1. > > + * x0 contains the hypercall control value, while additional registers > > + * vary depending on the hypercall, and whether the hypercall arguments > > + * are in memory or in registers (a "fast" hypercall per the Hyper-V > > + * TLFS). When the arguments are in memory x1 is the guest physical > > + * address of the input arguments, and x2 is the guest physical > > + * address of the output arguments. When the arguments are in > > + * registers, the register values depends on the hypercall. Note > > + * that this version cannot return any values in registers. > > + */ > > +ENTRY(hv_do_hvc) > > + hvc #1 > > + ret > > +ENDPROC(hv_do_hvc) > > + > > +/* > > + * This variant of HVC invocation is for hv_get_vpreg and > > + * hv_get_vpreg_128. The input parameters are passed in registers > > + * along with a pointer in x4 to where the output result should > > + * be stored. The output is returned in x15 and x16. x18 is used as > > + * scratch space to avoid buildng a stack frame, as Hyper-V does > > + * not preserve registers x0-x17. > > + */ > > +ENTRY(hv_do_hvc_fast_get) > > + mov x18, x4 > > + hvc #1 > > + str x1
Re: [PATCHv2 12/12] doc/mm: New documentation for memory performance
On 12/11/18 6:33 AM, Keith Busch wrote:
Platforms may provide system memory where some physical address ranges
perform differently than others, or is side cached by the system.
Add documentation describing a high level overview of such systems and the
performance and caching attributes the kernel provides for applications
wishing to query this information.
The series looks good with the examples in the commit messages
Signed-off-by: Keith Busch
---
Documentation/admin-guide/mm/numaperf.rst | 171 ++
1 file changed, 171 insertions(+)
create mode 100644 Documentation/admin-guide/mm/numaperf.rst
diff --git a/Documentation/admin-guide/mm/numaperf.rst
b/Documentation/admin-guide/mm/numaperf.rst
new file mode 100644
index ..846b3f991e7f
--- /dev/null
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -0,0 +1,171 @@
+.. _numaperf:
+
+=
+NUMA Locality
+=
+
+Some platforms may have multiple types of memory attached to a single
+CPU. These disparate memory ranges share some characteristics, such as
+CPU cache coherence, but may have different performance. For example,
+different media types and buses affect bandwidth and latency.
+
+A system supporting such heterogeneous memory by grouping each memory
+type under different "nodes" based on similar CPU locality and performance
+characteristics. Some memory may share the same node as a CPU, and others
+are provided as memory only nodes. While memory only nodes do not provide
+CPUs, they may still be directly accessible, or local, to one or more
+compute nodes. The following diagram shows one such example of two compute
+noes with local memory and a memory only node for each of compute node:
+
+ +--+ +--+
+ | Compute Node 0 +-+ Compute Node 1 |
+ | Local Node0 Mem | | Local Node1 Mem |
+ ++-+ ++-+
+ ||
+ ++-+ ++-+
+ | Slower Node2 Mem | | Slower Node3 Mem |
+ +--+ ++-+
+
+A "memory initiator" is a node containing one or more devices such as
+CPUs or separate memory I/O devices that can initiate memory requests. A
+"memory target" is a node containing one or more accessible physical
+address ranges from one or more memory initiators.
+
+When multiple memory initiators exist, they may not all have the same
+performance when accessing a given memory target. The highest performing
+initiator to a given target is considered to be one of that target's
+local initiators. Any given target may have one or more local initiators,
+and any given initiator may have multiple local memory targets.
+
Can you also add summary here suggesting node X is compute and Node y is
memory target
+To aid applications matching memory targets with their initiators,
+the kernel provide symlinks to each other like the following example::
+
+ # ls -l /sys/devices/system/node/nodeX/local_target*
+ /sys/devices/system/node/nodeX/local_targetY -> ../nodeY
+
+ # ls -l /sys/devices/system/node/nodeY/local_initiator*
+ /sys/devices/system/node/nodeY/local_initiatorX -> ../nodeX
+
the patch series had primary_target and primary_initiator
+The linked nodes will also have their node number set in the local_mem
+and local_cpu node list and maps.
+
+An example showing how this may be used to run a particular task on CPUs
+and memory that are both local to a particular PCI device can be done
+using existing 'numactl' as follows::
+
+ # NODE=$(cat /sys/devices/pci::00/.../numa_node)
+ # numactl --membind=$(cat /sys/devices/node/node${NODE}/local_mem_nodelist) \
+ --cpunodebind=$(cat /sys/devices/node/node${NODE}/local_cpu_nodelist) \
+ --
+
+
+NUMA Performance
+
+
+Applications may wish to consider which node they want their memory to
+be allocated from based on the node's performance characteristics. If the
+system provides these attributes, the kernel exports them under the node
+sysfs hierarchy by appending the local_initiator_access directory under
+the memory node as follows::
+
+ /sys/devices/system/node/nodeY/local_initiator_access/
+
Same here s/local/primary?
+The kernel does not provide performance attributes for non-local memory
+initiators. These attributes apply only to the memory initiator nodes that
+have a local_initiatorX link, or are set in the local_cpu_nodelist. A
+memory initiator node is considered local to itself if it also is
+a memory target and will be set it its node list and map, but won't
+contain a symlink to itself.
+
+The performance characteristics the kernel provides for the local initiators
+are exported are as follows::
+
+ # tree /sys/devices/system/node/nodeY/local_initiator_access
+ /sys/devices/system/node/nodeY/local_initiator_access
+ |-- read_bandwidth
+ |-- read_latency
+ |-- w
Re: [PATCH 10/10] perf/doc: update design.txt for exclude_{host|guest} flags
Andrew Murray writes:
> On Tue, Dec 11, 2018 at 10:06:53PM +1100, Michael Ellerman wrote:
>> [ Reviving old thread. ]
>>
>> Andrew Murray writes:
>> > On Tue, Nov 20, 2018 at 10:31:36PM +1100, Michael Ellerman wrote:
>> >> Andrew Murray writes:
>> >>
>> >> > Update design.txt to reflect the presence of the exclude_host
>> >> > and exclude_guest perf flags.
>> >> >
>> >> > Signed-off-by: Andrew Murray
>> >> > ---
>> >> > tools/perf/design.txt | 4
>> >> > 1 file changed, 4 insertions(+)
>> >> >
>> >> > diff --git a/tools/perf/design.txt b/tools/perf/design.txt
>> >> > index a28dca2..7de7d83 100644
>> >> > --- a/tools/perf/design.txt
>> >> > +++ b/tools/perf/design.txt
>> >> > @@ -222,6 +222,10 @@ The 'exclude_user', 'exclude_kernel' and
>> >> > 'exclude_hv' bits provide a
>> >> > way to request that counting of events be restricted to times when the
>> >> > CPU is in user, kernel and/or hypervisor mode.
>> >> >
>> >> > +Furthermore the 'exclude_host' and 'exclude_guest' bits provide a way
>> >> > +to request counting of events restricted to guest and host contexts
>> >> > when
>> >> > +using virtualisation.
>> >>
>> >> How does exclude_host differ from exclude_hv ?
>> >
>> > I believe exclude_host / exclude_guest are intented to distinguish
>> > between host and guest in the hosted hypervisor context (KVM).
>>
>> OK yeah, from the perf-list man page:
>>
>>u - user-space counting
>>k - kernel counting
>>h - hypervisor counting
>>I - non idle counting
>>G - guest counting (in KVM guests)
>>H - host counting (not in KVM guests)
>>
>> > Whereas exclude_hv allows to distinguish between guest and
>> > hypervisor in the bare-metal type hypervisors.
>>
>> Except that's exactly not how we use them on powerpc :)
>>
>> We use exclude_hv to exclude "the hypervisor", regardless of whether
>> it's KVM or PowerVM (which is a bare-metal hypervisor).
>>
>> We don't use exclude_host / exclude_guest at all, which I guess is a
>> bug, except I didn't know they existed until this thread.
>>
>> eg, in a KVM guest:
>>
>> $ perf record -e cycles:G /bin/bash -c "for i in {0..10}; do :;done"
>> $ perf report -D | grep -Fc "dso: [hypervisor]"
>> 16
>>
>>
>> > In the case of arm64 - if VHE extensions are present then the host
>> > kernel will run at a higher privilege to the guest kernel, in which
>> > case there is no distinction between hypervisor and host so we ignore
>> > exclude_hv. But where VHE extensions are not present then the host
>> > kernel runs at the same privilege level as the guest and we use a
>> > higher privilege level to switch between them - in this case we can
>> > use exclude_hv to discount that hypervisor role of switching between
>> > guests.
>>
>> I couldn't find any arm64 perf code using exclude_host/guest at all?
>
> Correct - but this is in flight as I am currently adding support for this
> see [1].
OK, so at least that will be consistent across arm64 & x86.
>> And I don't see any x86 code using exclude_hv.
>
> I can't find any either.
I think that's because they don't need it, because they don't let guests
program the PMU directly. It's all handled by the host and the host
doesn't let the guest count host cycles anyway. But I could be wrong I'm
no x86 expert.
>> But maybe that's OK, I just worry this is confusing for users.
>
> There is some extra context regarding this where exclude_guest/exclude_host
> was added, see [2]
Good find. I had looked at that commit, but the thread on the list is
more informative.
In fact there was even a man page update! Never occurred to me look
there :P
http://man7.org/linux/man-pages/man2/perf_event_open.2.html
exclude_host (since Linux 3.2)
When conducting measurements that include processes running VM
instances (i.e., have executed a KVM_RUN ioctl(2)), only mea‐
sure events happening inside a guest instance. This is only
meaningful outside the guests; this setting does not change
counts gathered inside of a guest. Currently, this function‐
ality is x86 only.
exclude_guest (since Linux 3.2)
When conducting measurements that include processes running VM
instances (i.e., have executed a KVM_RUN ioctl(2)), do not
measure events happening inside guest instances. This is only
meaningful outside the guests; this setting does not change
counts gathered inside of a guest. Currently, this function‐
ality is x86 only.
Which makes things much clearer.
Perhaps you want to add a reference to the man page in your text,
something like?
Furthermore the 'exclude_host' and 'exclude_guest' bits provide a way
to request counting of events restricted to guest and host contexts when
using virtualisation. See the perf_event_open(2) man page for more
detail.
cheers
Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On 11-12-18, 19:05, Taniya Das wrote: > The design here assumes that there would not be any per-cpu/per-cluster > based SW requirement for the HW during frequency transitions, which again > makes me think that we would require to re-introduce these structures again > in case we have such requirements in near future. Firstly, even in such cases we can go ahead with the design we proposed. And I am not at all concerned about some hardware which we don't have right now. We will see what to do when such hardware comes, maybe reintroduce the structures, but that doesn't matter right now. > Also I think leaving the structures also helps us debug any boot up issues > looking at the ram contents of the per-(cpu/cluster) structures with the > contents from the firmware. I don't see how debugging would be hard without those structures in place. > Hope these above helps us to go ahead with the current SW design. Sorry, but I don't see any satisfactory reason on why you shouldn't make the suggested changes. We are trying to make your (and any other developer who will work on that driver) life simple by simplifying the code. Nothing beyond that :) -- viresh
Re: [PATCH 2/2] OPP: Fix missing debugfs supply directory for OPPs
On 11-12-18, 13:48, Quentin Perret wrote: > On Tuesday 11 Dec 2018 at 16:56:29 (+0530), Viresh Kumar wrote: > > There is one case where we may end up with no "supply" directory for the > > OPPs in debugfs. That happens when the OPP core isn't managing the > > regulators for the device and the device's OPP do have microvolt > > property. It happens because the opp_table->regulator_count remains set > > to 0 and the debugfs routines don't add any supply directory in such a > > case. > > > > This commit fixes that by setting opp_table->regulator_count to 1 in > > that particular case. But to make everything work nicely and not break > > other parts of the core, regulator_count is defined as "int" now instead > > of "unsigned int" and it can have different special values now. It is > > set to -1 initially to mark it "uninitialized" and later only we set it > > to 0 or positive values after checking how many supplies are there. > > > > This also helps in finding the bugs where only few of the OPPs have the > > "opp-microvolt" property set and not all. > > Tested on Juno r0 and Hikey960 successfully. The 'supply' directory is > now correctly exposed. > > Feel free to add Tested-by: Quentin Perret Thanks. -- viresh
Re: [PATCH v4 3/7] mips: rename macros and files from '64' to 'n64'
Hi Paul, On Wed, 12 Dec 2018 at 00:29, Paul Burton wrote: > > Will this below change will help? > > > > #define _MIPS_SIM_ABI32 1 > > #define _MIPS_SIM_NABI322 > > #define _MIPS_SIM_ABI64 3 > > +#define _MIPS_SIM_ABIN64 _MIPS_SIM_ABI64 > > Hmm, I think I'd prefer that we just keep using _MIPS_SIM_ABI64. Sure, I think '64' to 'n64' conversion must be remove it from this patch series.I can send v5 without '64' to 'n64' conversion. If we rename '64' to 'n64' in half of the place and this _MIPS_SIM_ABI64 if we half to keep it in same looks not good (according to me). (FYI, This macro name - _MIPS_SIM_ABIN64 must be _MIPS_SIM_NABI64 and defintion will be: +#define _MIPS_SIM_NABI64 _MIPS_SIM_ABI64) So If you confirm I can send v5 without '64' to 'n64' conversion (not just above one, completely from this patch series). Or uou can take a call just keep this macro - _MIPS_SIM_ABI64 as it is and change it rest of the place. Thanks Firoz
Re: [PATCH v6 00/10] Add power domain driver for corners on msm8996/sdm845
On 12/12/2018 3:21 AM, Stephen Boyd wrote: Quoting Rajendra Nayak (2018-12-11 01:49:28) Changes in v6: * OPP binding updates for qcom,level reviewed by Rob * DT bindings for rpmpd and rpmhpd updated to specify the OPP tables as child nodes of the power-controller itself * Removed some module specific remains from the drivers, now that they can only be built-in * Added a simple_opp_to_performance_state() helper Is the idea that it can be squashed into the patches that use it by reordering the series? But otherwise left at the end of the series to make things simpler to merge without it? Yes, I left them at the end so its easier to merge. The PM domains change would need to go via Ulf/Viresh while the SoC drivers using them would go via Andy. So now its only 09/10 that's dependent on 08/10 and not the entire series.
Re: Regression in next-20181211 with fsverity changes
On Wednesday, December 12, 2018 12:42:20 AM IST Tony Lindgren wrote:
> Hi,
>
> Looks like commit 4de97efb578a ("fsverity: Move verity status check
> to fsverity_file_open") causes a boot regression for me with root
> on ext4 SDIO card, see below.
>
fsverity_file_open() used to incorrectly return -EOPNOTSUPP for non-fsverity
files on kernels built without fsverity support. This bug has been fixed in
the V4 patchset .
--
chandan
linux-next: manual merge of the phy-next tree with Linus' tree
Hi all,
Today's linux-next merge of the phy-next tree got a conflict in:
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
between commit:
7243ec72b902 ("dt-bindings: phy-qcom-qmp: Fix several mistakes from prior
commits")
from Linus' tree and commit:
91fdc9b127c9 ("dt-bindings: phy-qcom-qmp: Fix register underspecification")
from the phy-next tree.
I fixed it up (I just used the latter veriosn of the conflicting line)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index fbc198d5dd39,68c67eeef775..
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@@ -82,19 -66,23 +78,23 @@@ Required nodes
- Each device node of QMP phy is required to have as many child nodes as
the number of lanes the PHY has.
- Required properties for child node:
+ Required properties for child nodes of PCIe PHYs (one child per lane):
- reg: list of offset and length pairs of register sets for PHY blocks -
- - index 0: tx
- - index 1: rx
- - index 2: pcs
- - index 3: pcs_misc (optional)
+ tx, rx, pcs, and pcs_misc (optional).
+ - #phy-cells: must be 0
+ Required properties for a single "lanes" child node of non-PCIe PHYs:
+ - reg: list of offset and length pairs of register sets for PHY blocks
+ For 1-lane devices:
+ tx, rx, pcs, and (optionally) pcs_misc
+ For 2-lane devices:
+ tx0, rx0, pcs, tx1, rx1, and (optionally) pcs_misc
- #phy-cells: must be 0
- Required properties child node of pcie and usb3 qmp phys:
+ Required properties for child node of PCIe and USB3 qmp phys:
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- - clock-names: Must contain following for pcie and usb qmp phys:
+ - clock-names: Must contain following:
"pipe" for pipe clock specific to each lane.
- clock-output-names: Name of the PHY clock that will be the parent for
the above pipe clock.
@@@ -103,12 -90,13 +102,15 @@@
- "pcie20_phy0_pipe_clk"Pipe Clock parent
(or)
"pcie20_phy1_pipe_clk"
+ - #clock-cells: must be 0
+ - Phy pll outputs pipe clocks for pipe based PHYs. These clocks are then
+ gate-controlled by the gcc.
+Required properties for child node of PHYs with lane reset, AKA:
+ "qcom,msm8996-qmp-pcie-phy"
- resets: a list of phandles and reset controller specifier pairs,
one for each entry in reset-names.
- - reset-names: Must contain following for pcie qmp phys:
+ - reset-names: Must contain following:
"lane" for reset specific to each lane.
Example:
pgpYcGsKFCuR8.pgp
Description: OpenPGP digital signature
