Re: linux-next: Fixes tag needs some work in the i2c tree
> This triggered because the "space" after the ":" is a Unicode non-breaking > space (U+0x00a0, UTF8 0xc2 0xa0). I am not sure if this is a problem > or not. This is the forst time I have seen this. Thanks for reporting, I obviously didn't notice. Well, technically, commit messages can be UTF8, so not really an error. However, it will probably break lots of homebrew scripts, so a checkpatch warning it is, then? I'll fix it nonetheless. signature.asc Description: PGP signature
Re: [PATCH v3 0/9] Add a new LOOP_SET_FD_AND_STATUS ioctl
On Mon, Apr 27, 2020 at 10:34:35PM +0200, Martijn Coenen wrote: > > Also maybe an explicit direct I/O flag, and maybe > > enough padding with a future proof flags bitmap that we can easily > > extend it for new features if they pop up? > > Sounds good. I'm thinking these flags should be separate from > LO_FLAGS_; even though there is already a LO_FLAGS_DIRECT_IO, as far > as I can tell it can only be used to tell whether it's enabled, not to > actually enable it. And it would just get confusing if we add more > flags later. Maybe something like LO_FD_STATUS_FLAG_DIRECT_IO ? I think reusing LO_FLAGS_DIRECT_IO makes sense to me - we have 32 flags in the existing flags field (at least for loop_info64), so we might as well use the field and the flags. Then we need flags validation in that we don't accept new flags through the old interface, and the new one validates that no unknown flags are passed. E.g. in the LOOP_SET_STATUS / LOOP_SET_STATUS64 handler do: lo->lo_flags &= ~(LO_LEGACY_FLAGS); and then in the main function reject anything not known. And then maybe add something like 64 bytes of padding to the end of the new structure, so that we can use flags to expand to it.
Re: linux-next: build failure after merge of the mac80211-next tree
On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mac80211-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> Caused by commit
>
> 6cd536fe62ef ("cfg80211: change internal management frame registration API")
Yeah. I forgot about staging. I guess I'll throw in a quick fix.
johannes
Re: [PATCH 1/2] drivers/clocksource/timer-of: Remove __init markings
Hi Saravana, On 28/04/2020 00:17, Sandeep Patil wrote: > Hi Daniel, > > On Mon, Apr 27, 2020 at 10:50:24PM +0200, Daniel Lezcano wrote: >> On 27/04/2020 22:12, Saravana Kannan wrote: >>> On Mon, Apr 27, 2020 at 1:09 PM Daniel Lezcano >>> wrote: On 27/04/2020 21:04, Saravana Kannan wrote: > On Mon, Apr 27, 2020 at 10:13 AM Daniel Lezcano > wrote: >> >> On 13/04/2020 04:55, Baolin Wang wrote: >>> Hi Daniel, >>> >>> On Tue, Mar 24, 2020 at 1:59 PM Baolin Wang >>> wrote: From: Saravana Kannan This allows timer drivers to be compiled as modules. Signed-off-by: Saravana Kannan Signed-off-by: Baolin Wang >>> >>> Do you have any comments for this patch set? Thanks. >> >> If my understanding is correct, this patch is part of the GKI picture >> where hardware drivers are converted to modules. >> >> But do we really want to convert timer drivers to modules ? >> >> Is the core time framework able to support that (eg. load + unload ) > > So this will mainly be used for secondary timers that the system > supports. Not for the main one that's set up during early boot for > sched timer to work. For the primary timer during boot up, we still > expect that to be the default ARM timer and don't want/expect that to > be a module (it can't be). My question is about clockevents_config_and_register() for instance, is there a function to unregister in the core framework ? >>> >>> We can just have these modules be "permanent" modules that can't be >>> unloaded. They just need to not implement module_exit(). >> >> You are right. >> >> I can understand the goal of making everything as much modular as possible. >> >> But TBH, I have a bad feeling about this. Sounds like GKI will give the >> opportunity to companies to stop upstreaming their drivers and favoring >> fragmentation like what we had several years ago. Not sure it is a good >> thing, especially for upstream SoC support. > > ... and that is a very valid concern too IMO. > > However, the way we see it, as things stand today, we don't even know what > goes into Linux on all android phones out there. We know what we add, as part > of the AOSP kernel, however, what actually runs on the device is normally > about a million lines of code changes on top of what we do. > > So, for the GKI parts, we are doing the following > > 1. Making the peripheral drivers modules also means the GKI must have all the > core framework changes built-in. This gets us the list of core kernel changes > that ship on Android devices so we can work on upstreaming them OR find the > appropriate alternative. For Android, that answers the canonical > - "Where is the use case?" question coming from anyone. > > You can see the list of these out-of-tree changes is growing by the day in > AOSP right now[1]. Its there for everyone to find in exactly *one place*. > Note that, almost all of those patches have been posted on the list already. > That's the first pre-requisite for any change that goes into AOSP kernel[2]. > > 2. Once we have a core kernel that *truly* works on all Android devices, we > will have built up list of changes we want to upstream (or anyone can pick > them from our public tree). Android will still continue to move to newer > kernel versions easily (may be at a difference cadence ..) > > 3. About the incentive for upstream SoC support: As part of GKI, we are not > promising a forever stable kernel<->module interface. We still change it each > year. The *best way* for anyone to have their SoC / peripheral supported is > _still_ "going upstream". In fact, we advertise it as such[2]. The modularity > aspect just brings a much needed flexibility for execution. The flexibility > is needed given the number of stakeholders involved just in the kernel as of > today. (Its a mix of Upstream, Google, SoC manufacturer, device maker and > many other small parts). > > > 4. We also haven't been so keen on the "unloading" of a module. We know there > were subsystems where unloading may not work as expected. Then again, to my > knowledge, nobody has been stress testing with 500+ different modules that > register to all core frameworks being loaded and unloaded at random times. > Even if someone did, we just didn't think its worth the hassle or time at > this moment. Unloading the module didn't buy us anything. (Although, I do get > the point about "correctness" -- so it shouldn't also be obviously broken) That was my understanding of the GKI, thanks for confirming. Putting apart the non-technical aspect of these changes, the benefit I see is the memory usage optimization regarding the single kernel image. With the ARM64 defconfig, multiple platforms and their corresponding drivers are compiled-in. It results in a big kernel image which fails to load because of overlapping on DT load address (or something el
[PATCH] net: usb: ax88179_178a: Implement ethtool_ops set_eeprom
The vendor driver does upon failing to read a valid MAC address from
EEPROM write the netdev's address back to EEPROM and invoking a EEPROM
reload operation. Based on this we can implement the ethtool_ops
set_eeprom and provide the means to populate the EEPROM from within
Linux.
It's worth noting that ax88179_get_eeprom() will return some default
data unless the content of the EEPROM is deemed "complete", so until the
EEPROM is fully populated (e.g. by running ethtool -e | ethtool -E)
data written with ax88179_set_eeprom() will appear not to stick.
The implementation is based on asix_set_eeprom(), from asix_common.c
Signed-off-by: Bjorn Andersson
---
drivers/net/usb/ax88179_178a.c | 77 ++
1 file changed, 77 insertions(+)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 93044cf1417a..b05bb11a02cb 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -31,6 +31,7 @@
#define AX_ACCESS_PHY 0x02
#define AX_ACCESS_EEPROM 0x04
#define AX_ACCESS_EFUS 0x05
+#define AX_RELOAD_EEPROM_EFUSE 0x06
#define AX_PAUSE_WATERLVL_HIGH 0x54
#define AX_PAUSE_WATERLVL_LOW 0x55
@@ -611,6 +612,81 @@ ax88179_get_eeprom(struct net_device *net, struct
ethtool_eeprom *eeprom,
return 0;
}
+static int
+ax88179_set_eeprom(struct net_device *net, struct ethtool_eeprom *eeprom,
+ u8 *data)
+{
+ struct usbnet *dev = netdev_priv(net);
+ u16 *eeprom_buff;
+ int first_word;
+ int last_word;
+ int ret;
+ int i;
+
+ netdev_dbg(net, "write EEPROM len %d, offset %d, magic 0x%x\n",
+ eeprom->len, eeprom->offset, eeprom->magic);
+
+ if (eeprom->len == 0)
+ return -EINVAL;
+
+ if (eeprom->magic != AX88179_EEPROM_MAGIC)
+ return -EINVAL;
+
+ first_word = eeprom->offset >> 1;
+ last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+
+ eeprom_buff = kmalloc_array(last_word - first_word + 1, sizeof(u16),
+ GFP_KERNEL);
+ if (!eeprom_buff)
+ return -ENOMEM;
+
+ /* align data to 16 bit boundaries, read the missing data from
+ the EEPROM */
+ if (eeprom->offset & 1) {
+ ret = ax88179_read_cmd(dev, AX_ACCESS_EEPROM, first_word, 1, 2,
+ &eeprom_buff[0]);
+ if (ret < 0) {
+ netdev_err(net, "Failed to read EEPROM at offset
0x%02x.\n", first_word);
+ goto free;
+ }
+ }
+
+ if ((eeprom->offset + eeprom->len) & 1) {
+ ret = ax88179_read_cmd(dev, AX_ACCESS_EEPROM, last_word, 1, 2,
+ &eeprom_buff[last_word - first_word]);
+ if (ret < 0) {
+ netdev_err(net, "Failed to read EEPROM at offset
0x%02x.\n", last_word);
+ goto free;
+ }
+ }
+
+ memcpy((u8 *)eeprom_buff + (eeprom->offset & 1), data, eeprom->len);
+
+ for (i = first_word; i <= last_word; i++) {
+ netdev_dbg(net, "write to EEPROM at offset 0x%02x, data
0x%04x\n",
+ i, eeprom_buff[i - first_word]);
+ ret = ax88179_write_cmd(dev, AX_ACCESS_EEPROM, i, 1, 2,
+ &eeprom_buff[i - first_word]);
+ if (ret < 0) {
+ netdev_err(net, "Failed to write EEPROM at offset
0x%02x.\n", i);
+ goto free;
+ }
+ msleep(20);
+ }
+
+ /* reload EEPROM data */
+ ret = ax88179_write_cmd(dev, AX_RELOAD_EEPROM_EFUSE, 0x, 0, 0,
NULL);
+ if (ret < 0) {
+ netdev_err(net, "Failed to reload EEPROM data\n");
+ goto free;
+ }
+
+ ret = 0;
+free:
+ kfree(eeprom_buff);
+ return ret;
+}
+
static int ax88179_get_link_ksettings(struct net_device *net,
struct ethtool_link_ksettings *cmd)
{
@@ -822,6 +898,7 @@ static const struct ethtool_ops ax88179_ethtool_ops = {
.set_wol= ax88179_set_wol,
.get_eeprom_len = ax88179_get_eeprom_len,
.get_eeprom = ax88179_get_eeprom,
+ .set_eeprom = ax88179_set_eeprom,
.get_eee= ax88179_get_eee,
.set_eee= ax88179_set_eee,
.nway_reset = usbnet_nway_reset,
--
2.24.0
Re: [PATCH RT 10/30] hrtimer: Prevent using hrtimer_grab_expiry_lock() on migration_base
On 23/01/2020 21.39, Steven Rostedt wrote:
> 4.19.94-rt39-rc2 stable review patch.
> If anyone has any objections, please let me know.
>
> --
>
> From: Julien Grall
>
> [ Upstream commit cef1b87f98823af923a386f3f69149acb212d4a1 ]
>
> As tglx puts it:
> |If base == migration_base then there is no point to lock soft_expiry_lock
> |simply because the timer is not executing the callback in soft irq context
> |and the whole lock/unlock dance can be avoided.
Hold on a second. This patch (hrtimer: Prevent using
hrtimer_grab_expiry_lock() on migration_base) indeed seems to implement
the optimization implied by the above, namely avoid the lock/unlock in
case base == migration_base:
> - if (timer->is_soft && base && base->cpu_base) {
> + if (timer->is_soft && base != &migration_base) {
But the followup patch (hrtimer: Add a missing bracket and hide
`migration_base on !SMP) to fix the build on !SMP [the missing bracket
part seems to have been fixed when backporting the above to 4.19-rt]
replaces that logic by
+static inline bool is_migration_base(struct hrtimer_clock_base *base)
+{
+ return base == &migration_base;
+}
+
...
- if (timer->is_soft && base != &migration_base) {
+ if (timer->is_soft && is_migration_base(base)) {
in the SMP case, i.e. the exact opposite condition. One of these can't
be correct.
Assuming the followup patch was wrong and the condition should have read
timer->is_soft && !is_migration_base(base)
while keeping is_migration_base() false on !SMP might explain the
problem I see. But I'd like someone who knows this code to chime in.
Thanks,
Rasmus
Re: [PATCH 1/2] arm: dt-bindings: mfd: stm32f-rcc: Add missing DSI clock
On Mon, 27 Apr 2020, Adrian Pop wrote: > On Mon, Apr 27, 2020 at 9:49 AM Lee Jones wrote: > > > > On Fri, 24 Apr 2020, Adrian Pop wrote: > > > > > Add missing clock. > > > > > > Signed-off-by: Adrian Pop > > > --- > > > include/dt-bindings/mfd/stm32f7-rcc.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > I assume patch 2 depends on this? > > Yes, second patch depends on this. > > > > > If so, where is it? Why isn't it in my inbox? > > > > Here it is: > > STM32f769-disco features a 4" MIPI DSI display: add support for it. > > Signed-off-by: Adrian Pop > --- > arch/arm/boot/dts/stm32f746.dtsi | 34 ++ > arch/arm/boot/dts/stm32f769-disco.dts | 50 +++ > 2 files changed, 84 insertions(+) When you resubmit this, please add all recipients to all patches. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] scripts: gtags_files_generator.sh
On Tue, Apr 28, 2020 at 01:35:08PM +0800, xujialu wrote: > > Yes, please, just do proper email responses, like all the other > > conversations on the mailing lists :) > > Nice of you :) > > > Perhaps you should read the email client documentation in the kernel > > tree? > > Also watched your interesting video: > > > > I still don't know what is wrong with 'make gtags'. If it does not work > > properly for you, why not fix that up instead of creating something > > totally new that is not even hooked up to the kernel build system? > > As you suggested, i walk through scripts/tags.sh, and suddenly found > flag COMPILED_SOURCE, so i throw away my lasted stupid script, and tried > to improve this 'compiled only' feature, seems much better now. > > And about 'make gtags': > 1. It picks up so many files, do you think 'all sources' is good for us? When you modify kernel code, yes, you have to fix it up everywhere, you can not ignore other architectures or drivers that your machine happens to not use. An "average" laptop only runs about 2-3 million lines of code or so, a small percentage of the 25+ million lines that are in the kernel source tree. > 2. Seems gtags does not support source files from parrent directories, > it gives warnning out of tree (global-6.6.3) or just segmentation fault > (global-5.7.3) when we 'make gtags O=blabla', cause gtags.files is > generated in dir 'blabla' but source files are out of dir 'blabla'. Then fix that as a stand-alone patch please, do not mix it in with other changes. thanks, greg k-h
Re: x86 entry perf unwinding failure (missing IRET_REGS annotation on stack switch?)
On Mon, Mar 02, 2020 at 09:52:40AM -0600, Josh Poimboeuf wrote:
> On Mon, Mar 02, 2020 at 09:18:29AM -0600, Josh Poimboeuf wrote:
> > > So I think on machines without X86_FEATURE_SMAP, trying to unwind from
> > > the two NOPs at f41 and f42 will cause the unwinder to report an
> > > error? Looking at unwind_next_frame(), "sp:(und)" without the "end:1"
> > > marker seems to be reserved for errors.
>
> I think we can blame this one on Peter ;-)
>
> 764eef4b109a ("objtool: Rewrite alt->skip_orig")
>
> With X86_FEATURE_SMAP, alt->skip_orig gets set, which tells objtool to
> skip validation of the NOPs. That has the side effect of not
> propagating the ORC state to the NOPs as well.
I almost forgot about this one, until I rediscovered it just now...
Peter, I just realized you weren't CCed on the original email, oops.
I'm thinking something like this should fix it. Peter, does this look
ok?
(I should probably split it into two patches: STAC/CLAC fix and then
revert 764eef4b109a.)
From: Josh Poimboeuf
Subject: [PATCH] objtool: Fix ORC gap in STAC/CLAC alternatives
Since commit 764eef4b109a ("objtool: Rewrite alt->skip_orig"), the new
skip_orig actually skips objtool validation of the original instruction,
resulting in an empty gap in the ORC data.
Revert the skip_orig logic to how it was before, which is to convert the
original instruction to a NOP.
For the SMAP case, convert the original instruction to a matching
STAC/CLAC, so that it doesn't matter which path is taken.
Fixes: 764eef4b109a ("objtool: Rewrite alt->skip_orig")
Reported-by: Jann Horn
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 60 -
tools/objtool/special.c | 16 ---
tools/objtool/special.h | 1 -
3 files changed, 35 insertions(+), 42 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 0c732d586924..541fcf16283c 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -23,7 +23,6 @@
struct alternative {
struct list_head list;
struct instruction *insn;
- bool skip_orig;
};
const char *objname;
@@ -773,12 +772,26 @@ static int handle_group_alt(struct objtool_file *file,
struct instruction *last_orig_insn, *last_new_insn, *insn, *fake_jump =
NULL;
unsigned long dest_off;
+ /*
+* For uaccess checking, propagate the STAC/CLAC from the alternative
+* to the original insn to avoid paths where we see the STAC but then
+* take the NOP instead of CLAC (and vice versa).
+*/
+ if (!orig_insn->ignore_alts && orig_insn->type == INSN_NOP &&
+ *new_insn &&
+ ((*new_insn)->type == INSN_STAC ||
+(*new_insn)->type == INSN_CLAC))
+ orig_insn->type = (*new_insn)->type;
+
last_orig_insn = NULL;
insn = orig_insn;
sec_for_each_insn_from(file, insn) {
if (insn->offset >= special_alt->orig_off +
special_alt->orig_len)
break;
+ if (special_alt->skip_orig)
+ insn->type = INSN_NOP;
+
insn->alt_group = true;
last_orig_insn = insn;
}
@@ -970,8 +983,6 @@ static int add_special_section_alts(struct objtool_file
*file)
}
alt->insn = new_insn;
- alt->skip_orig = special_alt->skip_orig;
- orig_insn->ignore_alts |= special_alt->skip_alt;
list_add_tail(&alt->list, &orig_insn->alts);
list_del(&special_alt->list);
@@ -2221,12 +2232,7 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
insn->visited |= visited;
if (!insn->ignore_alts) {
- bool skip_orig = false;
-
list_for_each_entry(alt, &insn->alts, list) {
- if (alt->skip_orig)
- skip_orig = true;
-
ret = validate_branch(file, func, alt->insn,
state);
if (ret) {
if (backtrace)
@@ -2234,9 +2240,6 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
return ret;
}
}
-
- if (skip_orig)
- return 0;
}
switch (insn->type) {
@@ -2325,26 +2328,33 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
break;
case INSN_STAC:
- if (state.uaccess) {
- WARN_FUNC("recursive UACCESS enable", sec,
insn->offset);
- return 1;
- }
+ if (uaccess) {
+ if (state.uaccess) {
+
Re: [PATCH v3] mfd: syscon: Add Spreadtrum physical regmap bus support
On Mon, Apr 27, 2020 at 5:05 PM Lee Jones wrote: > > On Mon, 27 Apr 2020, Baolin Wang wrote: > > > Hi Arnd and Lee, > > > > On Tue, Apr 21, 2020 at 10:13 PM Baolin Wang wrote: > > > > > > Some platforms such as Spreadtrum platform, define a special method to > > > update bits of the registers instead of read-modify-write, which means > > > we should use a physical regmap bus to define the reg_update_bits() > > > operation instead of the MMIO regmap bus. Thus we can register a new > > > physical regmap bus into syscon core to support this. > > > > > > Signed-off-by: Baolin Wang > > > > Do you have any comments for this patch? Thanks. > > Yes. I'm not accepting it, sorry. > > I'd rather you duplicate the things you need from of_syscon_register() > in your own driver than taint this one. Thanks for your comments and I can understand your concern. But we still want to use the standard syscon APIs in syscon.c, which means we still need insert an callback or registration or other similar methods to support vendor specific regmap bus. Otherwise we should invent some similar syscon APIs in our vendor syscon driver, like sprd_syscon_regmap_lookup_by_phandle/sprd_syscon_regmap_lookup_by_compatible. Arnd, what do you think? Thanks. > > > --- > > > Changes from v2: > > > - Fix building errors without enabling CONFIG_ARCH_SPRD. > > > > > > Changes from v1: > > > - Add WARN_ONCE() for seting bits and clearing bits at the same time. > > > - Remove the Spreadtrum SoC syscon driver, instead moving the regmap_bus > > > instance into syscon.c driver. > > > > > > Changes from RFC v2: > > > - Drop regmap change, which was applied by Mark. > > > - Add more information about how to use set/clear. > > > - Add checking to ensure the platform is compatible with > > > using a new physical regmap bus. > > > > > > Changes from RFC v1: > > > - Add new helper to registers a physical regmap bus instead of > > > using the MMIO bus. > > > --- > > > drivers/mfd/syscon.c | 83 ++-- > > > 1 file changed, 81 insertions(+), 2 deletions(-) > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- Baolin Wang
Re: [PATCH v2] scripts: scripts/tags.sh
On Tue, Apr 28, 2020 at 01:35:09PM +0800, xujialu wrote:
> Update function all_compiled_sources for only compiled source files.
Your subject line needs a lot of work. Please read the section entitled
"The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to properly
describe the change.
>
> Usage:
> 1) COMPILED_SOURCE=1 make {cscope,gtags}
> 2) COMPILED_SOURCE=1 KBUILD_ABS_SRCTREE=1 make {cscope,gtags}
> 3) COMPILED_SOURCE=1 ./scripts/tags.sh {cscope,gtags}
> 4) COMPILED_SOURCE=1 ABSPWD=$PWD/ ./scripts/tags.sh {cscope,gtags}
And you did not document this somewhere for people to be able to find
out? Also not good :(
greg k-h
Re: [PATCH] nvme: prevent double free in nvme_alloc_ns() error handling
On 27.04.2020 18:22, Niklas Cassel wrote:
On Mon, Apr 27, 2020 at 08:03:11PM +0200, Javier González wrote:
On 27.04.2020 14:34, Niklas Cassel wrote:
> When jumping to the out_put_disk label, we will call put_disk(), which will
> trigger a call to disk_release(), which calls blk_put_queue().
>
> Later in the cleanup code, we do blk_cleanup_queue(), which will also call
> blk_put_queue().
>
> Putting the queue twice is incorrect, and will generate a KASAN splat.
>
> Set the disk->queue pointer to NULL, before calling put_disk(), so that the
> first call to blk_put_queue() will not free the queue.
>
> The second call to blk_put_queue() uses another pointer to the same queue,
> so this call will still free the queue.
>
> Fixes: 85136c010285 ("lightnvm: simplify geometry enumeration")
> Signed-off-by: Niklas Cassel
> ---
> drivers/nvme/host/core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 91c1bd659947..f2adea96b04c 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -3642,6 +3642,8 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,
unsigned nsid)
>
> return;
> out_put_disk:
> + /* prevent double queue cleanup */
> + ns->disk->queue = NULL;
> put_disk(ns->disk);
> out_unlink_ns:
> mutex_lock(&ctrl->subsys->lock);
> --
> 2.25.3
>
What about delaying the assignment of ns->disk?
diff --git i/drivers/nvme/host/core.c w/drivers/nvme/host/core.c
index a4d8c90ee7cc..6da4a9ced945 100644
--- i/drivers/nvme/host/core.c
+++ w/drivers/nvme/host/core.c
@@ -3541,7 +3541,6 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl, unsigned
nsid)
disk->queue = ns->queue;
disk->flags = flags;
memcpy(disk->disk_name, disk_name, DISK_NAME_LEN);
- ns->disk = disk;
__nvme_revalidate_disk(disk, id);
@@ -3553,6 +3552,8 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl, unsigned
nsid)
}
}
+ ns->disk = disk;
+
Hello Javier!
The only case where we jump to the out_put_disk label, is if the
nvme_nvm_register() call failed.
In that case, we want to undo the alloc_disk_node() operation, i.e.,
decrease the refcount.
If we don't set "ns->disk = disk;" before the call to nvme_nvm_register(),
then, if register fails, and we jump to the put_disk(ns->disk) label,
ns->disk will be NULL, so the recount will not be decreased, so I assume
that this memory would then be a memory leak.
I think that the problem is that the block functions are a bit messy.
Most drivers seem to do blk_cleanup_queue() first and then do put_disk(),
but some drivers do it in the opposite way, so I think that we might have
some more use-after-free bugs in some of these drivers that do it in the
opposite way.
Hi Niklas,
Yes, the out_put_disk label was introduced at the same time as the
LightNVM entry point. We can do a better job at separating the cleanup
functions, but as far as I can see ns->disk is not used in the LightNVM
initialization, so delaying the initialization should be ok. Part of
this should be also changing the out_put_disk to put_disk(disk).
Note that initializing other namespace types here do not require
ns->disk either, so delaying initialization should be ok. We have been
running with this patch locally for some time.
This said, this is an alternative as your fix works.
Javier
Re: [PATCH v3] module: Allow to disable modsign in kernel cmdline
On 2020/4/28 14:35, Greg KH wrote: On Tue, Apr 28, 2020 at 02:00:08PM +0800, Tianjia Zhang wrote: This option allows to disable modsign completely at the beginning, and turn off by set the kernel cmdline `no_modsig_enforce` when `CONFIG_MODULE_SIG_FORCE` is enabled. Yet another change allows to always show the current status of modsign through `/sys/module/module/parameters/sig_enforce`. Signed-off-by: Jia Zhang Signed-off-by: Tianjia Zhang --- v3 change: Beautify the document description according to the recommendation. v2 change: document this new option. Documentation/admin-guide/kernel-parameters.txt | 6 ++ kernel/module.c | 8 2 files changed, 14 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 7bc83f3d9bdf..b30f013fb8c5 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3190,6 +3190,12 @@ noirqdebug [X86-32] Disables the code which attempts to detect and disable unhandled interrupt sources. + no_modsig_enforce + [KNL] When CONFIG_MODULE_SIG_FORCE is set, this option + allows to disable modsign completely at the beginning. + This means that modules without (valid) signatures will + be loaded successfully. + So now we have module.sig_enforce and this one? That feels really confusing, why can't you just use the existing option? And why would you want to allow the bootloader to override a kernel build option like this? That feels risky. thanks, greg k-h If CONFIG_MODULE_SIG_FORCE is set, `module.sig_enforce` is always true and read-only. There is indeed a risk in doing this, but it will allow the system to boot normally in some emergency situations, such as certificate expiration. On the other hand, would it be a good solution to make `module.sig_enforce` readable and writable? Thanks and best, Tianjia
Re: [PATCH 2/7] signal: factor copy_siginfo_to_external32 from copy_siginfo_to_user32
On Mon, Apr 27, 2020 at 03:40:50PM -0700, Andrew Morton wrote:
> > https://www.spinics.net/lists/kernel/msg3473847.html
> > https://www.spinics.net/lists/kernel/msg3473840.html
> > https://www.spinics.net/lists/kernel/msg3473843.html
>
> OK, but that doesn't necessitate the above monstrosity? How about
>
> static int __copy_siginfo_to_user32(struct compat_siginfo __user *to,
>const struct kernel_siginfo *from, bool x32_ABI)
> {
> struct compat_siginfo new;
> copy_siginfo_to_external32(&new, from);
> ...
> }
>
> int copy_siginfo_to_user32(struct compat_siginfo __user *to,
> const struct kernel_siginfo *from)
> {
> #if defined(CONFIG_X86_X32_ABI) || defined(CONFIG_IA32_EMULATION)
> return __copy_siginfo_to_user32(to, from, in_x32_syscall());
> #else
> return __copy_siginfo_to_user32(to, from, 0);
> #endif
> }
>
> Or something like that - I didn't try very hard. We know how to do
> this stuff, and surely this thing isn't how!
I guess that might be a worthwhile middle ground. Still not a fan of
all these ifdefs..
Re: [PATCH] backlight: lp855x: Ensure regulators are disabled on probe failure
On Mon, 24 Feb 2020, Jon Hunter wrote: > If probing the LP885x backlight fails after the regulators have been > enabled, then the following warning is seen when releasing the > regulators ... > > WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051 > _regulator_put.part.28+0x158/0x160 > Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables > x_tables ipv6 nf_defrag_ipv6 > CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1 > Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) > > ... > > Call trace: > _regulator_put.part.28+0x158/0x160 > regulator_put+0x34/0x50 > devm_regulator_release+0x10/0x18 > release_nodes+0x12c/0x230 > devres_release_all+0x34/0x50 > really_probe+0x1c0/0x370 > driver_probe_device+0x58/0x100 > device_driver_attach+0x6c/0x78 > __driver_attach+0xb0/0xf0 > bus_for_each_dev+0x68/0xc8 > driver_attach+0x20/0x28 > bus_add_driver+0x160/0x1f0 > driver_register+0x60/0x110 > i2c_register_driver+0x40/0x80 > lp855x_driver_init+0x20/0x1000 [lp855x_bl] > do_one_initcall+0x58/0x1a0 > do_init_module+0x54/0x1d0 > load_module+0x1d80/0x21c8 > __do_sys_finit_module+0xe8/0x100 > __arm64_sys_finit_module+0x18/0x20 > el0_svc_common.constprop.3+0xb0/0x168 > do_el0_svc+0x20/0x98 > el0_sync_handler+0xf4/0x1b0 > el0_sync+0x140/0x180 > > Fix this by ensuring that the regulators are disabled, if enabled, on > probe failure. > > Finally, ensure that the vddio regulator is disabled in the driver > remove handler. > > Signed-off-by: Jon Hunter > --- > drivers/video/backlight/lp855x_bl.c | 20 > 1 file changed, 16 insertions(+), 4 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v1 0/2] Add support to get/set PHY attributes using
This patch series adds support to use kernel PHY subsystem APIs to get/set PHY attributes like number of lanes and maximum link rate. It includes following patches: 1. v1-0001-phy-Add-max_link_rate-as-a-PHY-attribute-along-wi.patch This patch adds max_link_rate as a PHY attribute along with a pair of APIs that allow the generic PHY subsystem to provide information on the maximum value of link rate supported by the PHY. The PHY provider driver may use phy_set_max_link_rate() to set the value that PHY supports. The controller driver may then use phy_get_max_link_rate() to fetch the PHY link rate in order to properly configure the controller. 2. v1-0002-phy-phy-cadence-torrent-Use-PHY-kernel-APIs-to-se.patch This patch uses kernel PHY APIs phy_set_bus_width() and phy_set_max_link_rate() to set corresponding PHY properties in Cadence Torrent PHY driver. This will enable drivers using this PHY to read these properties using PHY framework. The get API's will be used in the Cadence MHDP DRM bridge driver [1] which is under review for upstreaming. [1] https://lkml.org/lkml/2020/2/26/263 Swapnil Jakhade (1): phy: phy-cadence-torrent: Use PHY kernel APIs to set PHY attributes Yuti Amonkar (1): phy: Add max_link_rate as a PHY attribute along with APIs to get/set its value drivers/phy/cadence/phy-cadence-torrent.c | 3 +++ include/linux/phy/phy.h | 21 + 2 files changed, 24 insertions(+) -- 2.26.1
[PATCH v1 1/2] phy: Add max_link_rate as a PHY attribute along with APIs to get/set its value
The patch adds a pair of APIs that allow the generic PHY subsystem to
provide information on the maximum value of link rate supported by the
PHY. The PHY provider driver may use phy_set_max_link_rate() to set the
maximum link rate that the PHY supports. The controller driver may then
use phy_get_max_link_rate() to fetch the PHY link rate in order to
properly configure the controller.
Signed-off-by: Yuti Amonkar
---
include/linux/phy/phy.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index bcee8eba62b3..a8b7b4a2b8de 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -119,6 +119,7 @@ struct phy_ops {
*/
struct phy_attrs {
u32 bus_width;
+ u32 max_link_rate;
enum phy_mode mode;
};
@@ -231,6 +232,16 @@ static inline void phy_set_bus_width(struct phy *phy, int
bus_width)
{
phy->attrs.bus_width = bus_width;
}
+
+static inline int phy_get_max_link_rate(struct phy *phy)
+{
+ return phy->attrs.max_link_rate;
+}
+
+static inline void phy_set_max_link_rate(struct phy *phy, int link_rate)
+{
+ phy->attrs.max_link_rate = link_rate;
+}
struct phy *phy_get(struct device *dev, const char *string);
struct phy *phy_optional_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
@@ -389,6 +400,16 @@ static inline void phy_set_bus_width(struct phy *phy, int
bus_width)
return;
}
+static inline int phy_get_max_link_rate(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
+static inline void phy_set_max_link_rate(struct phy *phy, int link_rate)
+{
+ return;
+}
+
static inline struct phy *phy_get(struct device *dev, const char *string)
{
return ERR_PTR(-ENOSYS);
--
2.26.1
[PATCH v1 2/2] phy: phy-cadence-torrent: Use PHY kernel APIs to set PHY attributes
From: Swapnil Jakhade
Use generic PHY framework function phy_set_bus_width() to set number
of lanes and function phy_set_max_link_rate() to set maximum link rate
supported by PHY.
Signed-off-by: Swapnil Jakhade
---
drivers/phy/cadence/phy-cadence-torrent.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c
b/drivers/phy/cadence/phy-cadence-torrent.c
index 7116127358ee..b914e5ddf93c 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -1852,6 +1852,9 @@ static int cdns_torrent_phy_probe(struct platform_device
*pdev)
cdns_phy->phys[node].num_lanes,
cdns_phy->max_bit_rate / 1000,
cdns_phy->max_bit_rate % 1000);
+
+ phy_set_bus_width(gphy, cdns_phy->phys[node].num_lanes);
+ phy_set_max_link_rate(gphy, cdns_phy->max_bit_rate);
} else {
dev_err(dev, "Driver supports only PHY_TYPE_DP\n");
ret = -ENOTSUPP;
--
2.26.1
Re: [PATCH v3] mfd: syscon: Add Spreadtrum physical regmap bus support
On Tue, 28 Apr 2020, Baolin Wang wrote: > On Mon, Apr 27, 2020 at 5:05 PM Lee Jones wrote: > > > > On Mon, 27 Apr 2020, Baolin Wang wrote: > > > > > Hi Arnd and Lee, > > > > > > On Tue, Apr 21, 2020 at 10:13 PM Baolin Wang > > > wrote: > > > > > > > > Some platforms such as Spreadtrum platform, define a special method to > > > > update bits of the registers instead of read-modify-write, which means > > > > we should use a physical regmap bus to define the reg_update_bits() > > > > operation instead of the MMIO regmap bus. Thus we can register a new > > > > physical regmap bus into syscon core to support this. > > > > > > > > Signed-off-by: Baolin Wang > > > > > > Do you have any comments for this patch? Thanks. > > > > Yes. I'm not accepting it, sorry. > > > > I'd rather you duplicate the things you need from of_syscon_register() > > in your own driver than taint this one. > > Thanks for your comments and I can understand your concern. But we > still want to use the standard syscon APIs in syscon.c, which means we > still need insert an callback or registration or other similar methods > to support vendor specific regmap bus. Otherwise we should invent some > similar syscon APIs in our vendor syscon driver, like > sprd_syscon_regmap_lookup_by_phandle/sprd_syscon_regmap_lookup_by_compatible. So long as the generic driver stays generic. Providing a registration function sounds cleaner than tainting the code with vendor specifics. > Arnd, what do you think? Thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] x86/unwind/orc: Move ORC sorting variables under CONFIG_MODULE
Fix the following warnings seen with !CONFIG_MODULE:
arch/x86/kernel/unwind_orc.c:29:26: warning: 'cur_orc_table' defined but not
used [-Wunused-variable]
29 | static struct orc_entry *cur_orc_table = __start_orc_unwind;
| ^
arch/x86/kernel/unwind_orc.c:28:13: warning: 'cur_orc_ip_table' defined but
not used [-Wunused-variable]
28 | static int *cur_orc_ip_table = __start_orc_unwind_ip;
| ^~~~
Fixes: 153eb2223c79 ("x86/unwind/orc: Convert global variables to static")
Reported-by: Stephen Rothwell
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/unwind_orc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 0ebc11a8bb45..5b0bd8581fe6 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -24,10 +24,6 @@ extern struct orc_entry __stop_orc_unwind[];
static bool orc_init __ro_after_init;
static unsigned int lookup_num_blocks __ro_after_init;
-static DEFINE_MUTEX(sort_mutex);
-static int *cur_orc_ip_table = __start_orc_unwind_ip;
-static struct orc_entry *cur_orc_table = __start_orc_unwind;
-
static inline unsigned long orc_ip(const int *ip)
{
return (unsigned long)ip + *ip;
@@ -192,6 +188,10 @@ static struct orc_entry *orc_find(unsigned long ip)
#ifdef CONFIG_MODULES
+static DEFINE_MUTEX(sort_mutex);
+static int *cur_orc_ip_table = __start_orc_unwind_ip;
+static struct orc_entry *cur_orc_table = __start_orc_unwind;
+
static void orc_sort_swap(void *_a, void *_b, int size)
{
struct orc_entry *orc_a, *orc_b;
--
2.21.1
Re: [PATCH v3 2/5] KVM: X86: Introduce need_cancel_enter_guest helper
On Tue, 28 Apr 2020 at 02:30, Sean Christopherson
wrote:
>
> On Fri, Apr 24, 2020 at 02:22:41PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Introduce need_cancel_enter_guest() helper, we need to check some
> > conditions before doing CONT_RUN, in addition, it can also catch
> > the case vmexit occurred while another event was being delivered
> > to guest software since vmx_complete_interrupts() adds the request
> > bit.
> >
> > Tested-by: Haiwei Li
> > Cc: Haiwei Li
> > Signed-off-by: Wanpeng Li
> > ---
> > arch/x86/kvm/vmx/vmx.c | 12 +++-
> > arch/x86/kvm/x86.c | 10 --
> > arch/x86/kvm/x86.h | 1 +
> > 3 files changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index f1f6638..5c21027 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6577,7 +6577,7 @@ bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned
> > long *regs, bool launched);
> >
> > static enum exit_fastpath_completion vmx_vcpu_run(struct kvm_vcpu *vcpu)
> > {
> > - enum exit_fastpath_completion exit_fastpath;
> > + enum exit_fastpath_completion exit_fastpath = EXIT_FASTPATH_NONE;
> > struct vcpu_vmx *vmx = to_vmx(vcpu);
> > unsigned long cr3, cr4;
> >
> > @@ -6754,10 +6754,12 @@ static enum exit_fastpath_completion
> > vmx_vcpu_run(struct kvm_vcpu *vcpu)
> > vmx_recover_nmi_blocking(vmx);
> > vmx_complete_interrupts(vmx);
> >
> > - exit_fastpath = vmx_exit_handlers_fastpath(vcpu);
> > - /* static call is better with retpolines */
> > - if (exit_fastpath == EXIT_FASTPATH_CONT_RUN)
> > - goto cont_run;
> > + if (!kvm_need_cancel_enter_guest(vcpu)) {
> > + exit_fastpath = vmx_exit_handlers_fastpath(vcpu);
> > + /* static call is better with retpolines */
> > + if (exit_fastpath == EXIT_FASTPATH_CONT_RUN)
> > + goto cont_run;
> > + }
> >
> > return exit_fastpath;
> > }
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 59958ce..4561104 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -1581,6 +1581,13 @@ int kvm_emulate_wrmsr(struct kvm_vcpu *vcpu)
> > }
> > EXPORT_SYMBOL_GPL(kvm_emulate_wrmsr);
> >
> > +bool kvm_need_cancel_enter_guest(struct kvm_vcpu *vcpu)
>
> What about kvm_vcpu__pending()? Not sure what a good ??? would be.
> The "cancel_enter_guest" wording is a bit confusing when this is called
> from the VM-Exit path.
>
> > +{
> > + return (vcpu->mode == EXITING_GUEST_MODE || kvm_request_pending(vcpu)
> > + || need_resched() || signal_pending(current));
>
> Parantheses around the whole statement are unnecessary. Personal preference
> is to put the || before the newline.
Handle the comments in v4.
Wanpeng
RE: [PATCH v2 3/6] ima: Fix ima digest hash table key calculation
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Monday, April 27, 2020 4:28 PM
> To: Roberto Sassu ; zo...@linux.ibm.com;
> rgold...@suse.de
> Cc: linux-integr...@vger.kernel.org; linux-security-mod...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Silviu Vlasceanu
> ; Krzysztof Struczynski
> ; sta...@vger.kernel.org
> Subject: RE: [PATCH v2 3/6] ima: Fix ima digest hash table key calculation
>
> From: Roberto Sassu
> > Sent: 27 April 2020 13:51
> ...
> > > > -static inline unsigned long ima_hash_key(u8 *digest)
> > > > +static inline unsigned int ima_hash_key(u8 *digest)
> > > > {
> > > > - return hash_long(*digest, IMA_HASH_BITS);
> > > > + return (*(unsigned int *)digest % IMA_MEASURE_HTABLE_SIZE);
> > >
> > > That almost certainly isn't right.
> > > It falls foul of the *(integer_type *)ptr being almost always wrong.
> >
> > I didn't find the problem. Can you please explain?
>
> The general problem with *(int_type *)ptr is that it does completely
> the wrong thing if 'ptr' is the address of a larger integer type on
> a big-endian system.
> You may also get a misaligned access trap.
>
> In this case I guess that digest is actually u8[SHA1_DIGEST_SIZE].
> Maybe what you should return is:
> (digest[0] | digest[1] << 8) % IMA_MEASURE_HTABLE_SIZE;
> and comment that there is no point taking a hash of part of
> a SHA1 digest.
Ok, thanks.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)
Re: [PATCH] x86/unwind/orc: Move ORC sorting variables under CONFIG_MODULE
On Tue, Apr 28, 2020 at 02:16:43AM -0500, Josh Poimboeuf wrote: > Fix the following warnings seen with !CONFIG_MODULE: s/MODULE/MODULES/ here and $SUBJECT. -- Josh
Re: linux-next: build failure after merge of the mac80211-next tree
On Tue, Apr 28, 2020 at 09:01:30AM +0200, Johannes Berg wrote:
> On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the mac80211-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > Caused by commit
> >
> > 6cd536fe62ef ("cfg80211: change internal management frame registration
> > API")
>
> Yeah. I forgot about staging. I guess I'll throw in a quick fix.
>
> johannes
Hello Johannes,
Could you please take a look at the following fix for this issue:
https://patchwork.kernel.org/patch/11509497/
Regards,
Sergey
Re: linux-next: build failure after merge of the mac80211-next tree
On Tue, 2020-04-28 at 10:25 +0300, Sergey Matyukevich wrote:
> On Tue, Apr 28, 2020 at 09:01:30AM +0200, Johannes Berg wrote:
> > On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the mac80211-next tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > Caused by commit
> > >
> > > 6cd536fe62ef ("cfg80211: change internal management frame registration
> > > API")
> >
> > Yeah. I forgot about staging. I guess I'll throw in a quick fix.
> >
> > johannes
>
> Hello Johannes,
>
> Could you please take a look at the following fix for this issue:
> https://patchwork.kernel.org/patch/11509497/
Heh. I was just fixing it too, missed your patch. How do you like this
fix?
https://p.sipsolutions.net/0638ee56c2e48a30.txt
johannes
Re: [PATCH] arm64/mm: Reject invalid NUMA option
On Tue, Apr 28, 2020 at 02:35:20PM +1000, Gavin Shan wrote:
> On 4/28/20 1:09 PM, Steven Rostedt wrote:
>
> [...]
>
> >
> > Could this be a bug in the implementation of strncmp() in
> > arch/arm64/lib/strncmp.S. As I don't know arm64 assembly, I have no idea
> > what it is trying to do.
> >
> > But strncmp("o","off",3) returning zero *is* a bug.
> >
>
> I think it's false alarm. The patch has been in my local repo for a while.
> I checked out 5.7.rc3 and tried passing "numa=o" to the kernel, @numa_off
> is unchanged and its value is false. I also check the return value from
> strncmp() as below, it's correct. Nothing is broken. I should have retested
> before posting it. Sorry for the noise. Please ignore the crap patch :)
Hmm, it's still worrying that you had that patch kicking around though, as
it sounds like it /used/ to be broken. Would you be able to test the LTS
kernels (5.4, 4.19, 4.14, 4.9, 4.4) to check that we're not missing a
backport, please? Sorry to be a pain, but I'd like to get to the bottom of
this!
Thanks,
Will
Re: [BISECTED] bug/regression, x86-64: completely unbootable machine
On Sat, 25 Apr 2020 at 17:01, Giovanni Gherdovich wrote: > > There is an easy way to tell (besides compiling with those patches on top and > check if it works): run the command "turbostat --interval 1 sleep 0", the > output should tell you the content of the register MSR_TURBO_RATIO_LIMIT. > > If bits 31:24 are zero, you see the bug (the code divides by that value), > otherwise you don't. Some 2 cores / 4 threads CPU have a non-zero value there > (even if it doesn't mean much), some others have zero instead. > > The Intel Software Developer Manual (SDM) says the register content is like > this: > > Bit Fields Bit Description > 7:0 Maximum turbo ratio limit of 1 core active. > 15:8Maximum turbo ratio limit of 2 core active. > 23:16 Maximum turbo ratio limit of 3 core active. > 31:24 Maximum turbo ratio limit of 4 core active. > 39:32 Maximum turbo ratio limit of 5 core active. > 47:40 Maximum turbo ratio limit of 6 core active. > 55:48 Maximum turbo ratio limit of 7 core active. > 63:56 Maximum turbo ratio limit of 8 core active. > > As I wrote above, some 2c/4t CPUs will say (correctly) their 4 cores turbo > frequency is zero, such as this Intel Core i5-430M (Arrandale) where I've seen > turbostat saying: > > cpu1: MSR_TURBO_RATIO_LIMIT: 0x1313 > 19 * 133.3 = 2533.3 MHz max turbo 2 active cores > 19 * 133.3 = 2533.3 MHz max turbo 1 active cores > > On the contrary, my laptop has an Intel Core i5-5300U (Broadwell, also > 2 cores / 4 threads) and it has: > > cpu3: MSR_TURBO_RATIO_LIMIT: 0x1b1b1b1b1b1d > 27 * 100.0 = 2700.0 MHz max turbo 6 active cores > 27 * 100.0 = 2700.0 MHz max turbo 5 active cores > 27 * 100.0 = 2700.0 MHz max turbo 4 active cores > 27 * 100.0 = 2700.0 MHz max turbo 3 active cores > 27 * 100.0 = 2700.0 MHz max turbo 2 active cores > 29 * 100.0 = 2900.0 MHz max turbo 1 active cores > > You can see above that the 4 cores turbo freq is declared as 2.7GHz even if > it's nonsense because there aren't 4 cores. In any case, this cpu wouldn't > trigger the bug, just as your skylake. > > > Thanks, > Giovanni Hi again, Giovanni, Thanks for the detailed and insightful explanation and sorry for not replying earlier. This was indeed the bug I was hitting, as my Arrandale laptop is now booting 5.7-rc3 just fine. Best regards, Rui
Re: [PATCH v3] module: Allow to disable modsign in kernel cmdline
On Tue, Apr 28, 2020 at 03:07:10PM +0800, Tianjia Zhang wrote: > > > On 2020/4/28 14:35, Greg KH wrote: > > On Tue, Apr 28, 2020 at 02:00:08PM +0800, Tianjia Zhang wrote: > > > This option allows to disable modsign completely at the beginning, > > > and turn off by set the kernel cmdline `no_modsig_enforce` when > > > `CONFIG_MODULE_SIG_FORCE` is enabled. > > > > > > Yet another change allows to always show the current status of > > > modsign through `/sys/module/module/parameters/sig_enforce`. > > > > > > Signed-off-by: Jia Zhang > > > Signed-off-by: Tianjia Zhang > > > --- > > > > > > v3 change: > > >Beautify the document description according to the recommendation. > > > > > > v2 change: > > >document this new option. > > > > > > Documentation/admin-guide/kernel-parameters.txt | 6 ++ > > > kernel/module.c | 8 > > > 2 files changed, 14 insertions(+) > > > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > > b/Documentation/admin-guide/kernel-parameters.txt > > > index 7bc83f3d9bdf..b30f013fb8c5 100644 > > > --- a/Documentation/admin-guide/kernel-parameters.txt > > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > > @@ -3190,6 +3190,12 @@ > > > noirqdebug [X86-32] Disables the code which attempts to > > > detect and > > > disable unhandled interrupt sources. > > > + no_modsig_enforce > > > + [KNL] When CONFIG_MODULE_SIG_FORCE is set, this option > > > + allows to disable modsign completely at the beginning. > > > + This means that modules without (valid) signatures will > > > + be loaded successfully. > > > + > > > > So now we have module.sig_enforce and this one? That feels really > > confusing, why can't you just use the existing option? > > > > And why would you want to allow the bootloader to override a kernel > > build option like this? That feels risky. > > > > thanks, > > > > greg k-h > > > > If CONFIG_MODULE_SIG_FORCE is set, `module.sig_enforce` is always true and > read-only. There is indeed a risk in doing this, but it will allow the > system to boot normally in some emergency situations, such as certificate > expiration. > > On the other hand, would it be a good solution to make `module.sig_enforce` > readable and writable? Readable is fine :) And you really can't modify the existing option to change how it works, but my question is, why would you want to override CONFIG_MODULE_SIG_FORCE at all? I wouldn't want my bootloader to have the ability to change the kernel's protection model, that's a huge security hole you are adding to the kernel that it can not protect itself from at all. thanks, greg k-h
[PATCH V2] cpufreq: imx-cpufreq-dt: support i.MX7ULP
From: Peng Fan
i.MX7ULP's ARM core clock design is totally different compared
with i.MX7D/8M SoCs which supported by imx-cpufreq-dt. It needs
get_intermediate and target_intermedate to configure clk MUX ready,
before let OPP configure ARM core clk.
|---FIRC
|--RUN---...---SCS(MUX2) |
ARM --(MUX1) |---SPLL_PFD0(CLK_SET_RATE_GATE)
|--HSRUN--...--HSRUN_SCS(MUX3)---|
|---SRIC
FIRC is step clk, SPLL_PFD0 is the normal clk driving ARM core.
MUX2 and MUX3 share same inputs. So if MUX2/MUX3 both sources from
SPLL_PFD0, both MUXes will lose input when configure SPLL_PFD0.
So the target_intermediate will configure MUX2/MUX3 to FIRC, to avoid
ARM core lose clk when configure SPLL_PFD0.
Signed-off-by: Peng Fan
---
V2:
Fix boot break. Tested on i.MX8MN DDR4 EVK.
drivers/cpufreq/imx-cpufreq-dt.c | 84 +++-
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/imx-cpufreq-dt.c b/drivers/cpufreq/imx-cpufreq-dt.c
index de206d2745fe..3fe9125156b4 100644
--- a/drivers/cpufreq/imx-cpufreq-dt.c
+++ b/drivers/cpufreq/imx-cpufreq-dt.c
@@ -3,7 +3,9 @@
* Copyright 2019 NXP
*/
+#include
#include
+#include
#include
#include
#include
@@ -12,8 +14,11 @@
#include
#include
#include
+#include
#include
+#include "cpufreq-dt.h"
+
#define OCOTP_CFG3_SPEED_GRADE_SHIFT 8
#define OCOTP_CFG3_SPEED_GRADE_MASK(0x3 << 8)
#define IMX8MN_OCOTP_CFG3_SPEED_GRADE_MASK (0xf << 8)
@@ -22,20 +27,92 @@
#define IMX8MP_OCOTP_CFG3_MKT_SEGMENT_SHIFT5
#define IMX8MP_OCOTP_CFG3_MKT_SEGMENT_MASK (0x3 << 5)
+#define IMX7ULP_MAX_RUN_FREQ 528000
+
/* cpufreq-dt device registered by imx-cpufreq-dt */
static struct platform_device *cpufreq_dt_pdev;
static struct opp_table *cpufreq_opp_table;
+static struct device *cpu_dev;
+
+enum IMX7ULP_CPUFREQ_CLKS {
+ ARM,
+ CORE,
+ SCS_SEL,
+ HSRUN_CORE,
+ HSRUN_SCS_SEL,
+ FIRC,
+};
+
+static struct clk_bulk_data imx7ulp_clks[] = {
+ { .id = "arm" },
+ { .id = "core" },
+ { .id = "scs_sel" },
+ { .id = "hsrun_core" },
+ { .id = "hsrun_scs_sel" },
+ { .id = "firc" },
+};
+
+static unsigned int imx7ulp_get_intermediate(struct cpufreq_policy *policy,
+unsigned int index)
+{
+ return clk_get_rate(imx7ulp_clks[FIRC].clk);
+}
+
+static int imx7ulp_target_intermediate(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ unsigned int newfreq = policy->freq_table[index].frequency;
+
+ clk_set_parent(imx7ulp_clks[SCS_SEL].clk, imx7ulp_clks[FIRC].clk);
+ clk_set_parent(imx7ulp_clks[HSRUN_SCS_SEL].clk, imx7ulp_clks[FIRC].clk);
+
+ if (newfreq > IMX7ULP_MAX_RUN_FREQ)
+ clk_set_parent(imx7ulp_clks[ARM].clk,
+ imx7ulp_clks[HSRUN_CORE].clk);
+ else
+ clk_set_parent(imx7ulp_clks[ARM].clk, imx7ulp_clks[CORE].clk);
+
+ return 0;
+}
+
+static struct cpufreq_dt_platform_data imx7ulp_data = {
+ .target_intermediate = imx7ulp_target_intermediate,
+ .get_intermediate = imx7ulp_get_intermediate,
+};
static int imx_cpufreq_dt_probe(struct platform_device *pdev)
{
- struct device *cpu_dev = get_cpu_device(0);
+ struct platform_device *dt_pdev;
u32 cell_value, supported_hw[2];
int speed_grade, mkt_segment;
int ret;
+ cpu_dev = get_cpu_device(0);
+
if (!of_find_property(cpu_dev->of_node, "cpu-supply", NULL))
return -ENODEV;
+ if (of_machine_is_compatible("fsl,imx7ulp")) {
+ ret = clk_bulk_get(cpu_dev, ARRAY_SIZE(imx7ulp_clks),
+ imx7ulp_clks);
+ if (ret)
+ return ret;
+
+ dt_pdev = platform_device_register_data(NULL, "cpufreq-dt",
+ -1, &imx7ulp_data,
+ sizeof(imx7ulp_data));
+ if (IS_ERR(dt_pdev)) {
+ clk_bulk_put(ARRAY_SIZE(imx7ulp_clks), imx7ulp_clks);
+ ret = PTR_ERR(dt_pdev);
+ dev_err(&pdev->dev, "Failed to register cpufreq-dt:
%d\n", ret);
+ return ret;
+ }
+
+ cpufreq_dt_pdev = dt_pdev;
+
+ return 0;
+ }
+
ret = nvmem_cell_read_u32(cpu_dev, "speed_grade", &cell_value);
if (ret)
return ret;
@@ -98,7 +175,10 @@ static int imx_cpufreq_dt_probe(struct platform_device
*pdev)
static int imx_cpufreq_dt_remove(struct platform_device *pdev)
{
platform_device_unregister(cpufreq_dt_pdev);
- dev_pm_opp_put_supported_hw(cpufreq_opp_table);
+ if (!of_machin
Re: arm64: imx8qm: tlb SW workaround for IMX8QM
On Mon, Apr 27, 2020 at 03:03:28PM +0200, Oliver Graute wrote: > On 27/04/20, Oliver Graute wrote: > > Hello, > > > > is this nxp software workaround already proposed to linux community? can > > someone point me to the discussion if available. > > > > https://source.codeaurora.org/external/imx/linux-imx/commit/?h=3Dimx_5.4.3_= > > 2.0.0&id=3D593bea4e36d8c8a4fd65ef4f07fb8144dab2de1c > > sry for the broken link. Here the right one: > > https://source.codeaurora.org/external/imx/linux-imx/commit/?h=imx_5.4.3_2.0.0&id=593bea4e36d8c8a4fd65ef4f07fb8144dab2de1c Hey, if we're trading links then it should be fixed by: https://www.hobbytronics.co.uk/jumper-kit-140 Unfortunately, I don't think there's a gift-wrap option for the hardware folks ;) Will
[RESEND][PATCH v2 3/6] ima: Fix ima digest hash table key calculation
From: Krzysztof Struczynski
Function hash_long() accepts unsigned long, while currently only one byte
is passed from ima_hash_key(), which calculates a key for ima_htable.
Given that hashing the digest does not give clear benefits compared to
using the digest itself, remove hash_long() and return the modulus
calculated on the first two bytes of the digest with the number of slots.
Also reduce the depth of the hash table by doubling the number of slots.
Changelog
v2: directly access the first two bytes of the digest to avoid memory
access issues on big endian systems (suggested by David Laight)
Cc: sta...@vger.kernel.org
Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Co-developed-by: Roberto Sassu
Signed-off-by: Roberto Sassu
Signed-off-by: Krzysztof Struczynski
---
security/integrity/ima/ima.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 467dfdbea25c..02796473238b 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -36,7 +36,7 @@ enum tpm_pcrs { TPM_PCR0 = 0, TPM_PCR8 = 8 };
#define IMA_DIGEST_SIZESHA1_DIGEST_SIZE
#define IMA_EVENT_NAME_LEN_MAX 255
-#define IMA_HASH_BITS 9
+#define IMA_HASH_BITS 10
#define IMA_MEASURE_HTABLE_SIZE (1 << IMA_HASH_BITS)
#define IMA_TEMPLATE_FIELD_ID_MAX_LEN 16
@@ -179,9 +179,10 @@ struct ima_h_table {
};
extern struct ima_h_table ima_htable;
-static inline unsigned long ima_hash_key(u8 *digest)
+static inline unsigned int ima_hash_key(u8 *digest)
{
- return hash_long(*digest, IMA_HASH_BITS);
+ /* there is no point in taking a hash of part of a digest */
+ return (digest[0] | digest[1] << 8) % IMA_MEASURE_HTABLE_SIZE;
}
#define __ima_hooks(hook) \
--
2.17.1
[PATCH v12 00/17] KVM RISC-V Support
This series adds initial KVM RISC-V support. Currently, we are able to boot RISC-V 64bit Linux Guests with multiple VCPUs. Few key aspects of KVM RISC-V added by this series are: 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs. 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure. 3. KVM ONE_REG interface for VCPU register access from user-space. 4. PLIC emulation is done in user-space. 5. Timer and IPI emuation is done in-kernel. 6. MMU notifiers supported. 7. FP lazy save/restore supported. 8. SBI v0.1 emulation for KVM Guest available. 9. Forward unhandled SBI calls to KVM userspace. 10. Hugepage support for Guest/VM Here's a brief TODO list which we will work upon after this series: 1. SBI v0.2 emulation in-kernel 2. SBI v0.2 hart state management emulation in-kernel 3. In-kernel PLIC emulation 4. . and more . This series can be found in riscv_kvm_v12 branch at: https//github.com/avpatel/linux.git Our work-in-progress KVMTOOL RISC-V port can be found in riscv_v3 branch at: https//github.com/avpatel/kvmtool.git The QEMU RISC-V hypervisor emulation is done by Alistair and is available in mainline/anup/riscv-hyp-ext-v0.6 branch at: https://github.com/kvm-riscv/qemu.git To play around with KVM RISC-V, refer KVM RISC-V wiki at: https://github.com/kvm-riscv/howto/wiki https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-QEMU Changes since v11: - Rebased patches on Linux-5.7-rc3 - Fixed typo in typecast of stage2_map_size define - Introduced struct kvm_cpu_trap to represent trap details and use it as function parameter wherever applicable - Pass memslot to kvm_riscv_stage2_map() for supporing dirty page logging in future - RISC-V H-Extension v0.6 spec support - Send-out first three patches as separate series so that it can be taken by Palmer for Linux RISC-V Changes since v10: - Rebased patches on Linux-5.6-rc5 - Reduce RISCV_ISA_EXT_MAX from 256 to 64 - Separate PATCH for removing N-extension related defines - Added comments as requested by Palmer - Fixed HIDELEG CSR programming Changes since v9: - Rebased patches on Linux-5.5-rc3 - Squash PATCH19 and PATCH20 into PATCH5 - Squash PATCH18 into PATCH11 - Squash PATCH17 into PATCH16 - Added ONE_REG interface for VCPU timer in PATCH13 - Use HTIMEDELTA for VCPU timer in PATCH13 - Updated KVM RISC-V mailing list in MAINTAINERS entry - Update KVM kconfig option to depend on RISCV_SBI and MMU - Check for SBI v0.2 and SBI v0.2 RFENCE extension at boot-time - Use SBI v0.2 RFENCE extension in VMID implementation - Use SBI v0.2 RFENCE extension in Stage2 MMU implementation - Use SBI v0.2 RFENCE extension in SBI implementation - Moved to RISC-V Hypervisor v0.5 draft spec - Updated Documentation/virt/kvm/api.txt for timer ONE_REG interface Changes since v8: - Rebased series on Linux-5.4-rc3 and Atish's SBI v0.2 patches - Use HRTIMER_MODE_REL instead of HRTIMER_MODE_ABS in timer emulation - Fixed kvm_riscv_stage2_map() to handle hugepages - Added patch to forward unhandled SBI calls to user-space - Added patch for iterative/recursive stage2 page table programming - Added patch to remove per-CPU vsip_shadow variable - Added patch to fix race-condition in kvm_riscv_vcpu_sync_interrupts() Changes since v7: - Rebased series on Linux-5.4-rc1 and Atish's SBI v0.2 patches - Removed PATCH1, PATCH3, and PATCH20 because these already merged - Use kernel doc style comments for ISA bitmap functions - Don't parse X, Y, and Z extension in riscv_fill_hwcap() because it will be added in-future - Mark KVM RISC-V kconfig option as EXPERIMENTAL - Typo fix in commit description of PATCH6 of v7 series - Use separate structs for CORE and CSR registers of ONE_REG interface - Explicitly include asm/sbi.h in kvm/vcpu_sbi.c - Removed implicit switch-case fall-through in kvm_riscv_vcpu_exit() - No need to set VSSTATUS.MXR bit in kvm_riscv_vcpu_unpriv_read() - Removed register for instruction length in kvm_riscv_vcpu_unpriv_read() - Added defines for checking/decoding instruction length - Added separate patch to forward unhandled SBI calls to userspace tool Changes since v6: - Rebased patches on Linux-5.3-rc7 - Added "return_handled" in struct kvm_mmio_decode to ensure that kvm_riscv_vcpu_mmio_return() updates SEPC only once - Removed trap_stval parameter from kvm_riscv_vcpu_unpriv_read() - Updated git repo URL in MAINTAINERS entry Changes since v5: - Renamed KVM_REG_RISCV_CONFIG_TIMEBASE register to KVM_REG_RISCV_CONFIG_TBFREQ register in ONE_REG interface - Update SPEC in kvm_riscv_vcpu_mmio_return() for MMIO exits - Use switch case instead of illegal instruction opcode table for simplicity - Improve comments in stage2_remote_tlb_flush() for a potential remote TLB flush optimization - Handle all unsupported SBI calls in default case of kvm_riscv_vcpu_sbi_ecall() function - Fixed kvm_riscv_vcpu_sync_interrupts() for software interrupts - Improved unprivilege reads to handle traps due t
[PATCH v12 02/17] RISC-V: Add initial skeletal KVM support
This patch adds initial skeletal KVM RISC-V support which has:
1. A simple implementation of arch specific VM functions
except kvm_vm_ioctl_get_dirty_log() which will implemeted
in-future as part of stage2 page loging.
2. Stubs of required arch specific VCPU functions except
kvm_arch_vcpu_ioctl_run() which is semi-complete and
extended by subsequent patches.
3. Stubs for required arch specific stage2 MMU functions.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/Kconfig| 2 +
arch/riscv/Makefile | 2 +
arch/riscv/include/asm/kvm_host.h | 89 +
arch/riscv/include/uapi/asm/kvm.h | 47 +
arch/riscv/kvm/Kconfig| 33 +++
arch/riscv/kvm/Makefile | 13 ++
arch/riscv/kvm/main.c | 93 +
arch/riscv/kvm/mmu.c | 86
arch/riscv/kvm/vcpu.c | 321 ++
arch/riscv/kvm/vcpu_exit.c| 35
arch/riscv/kvm/vm.c | 79
11 files changed, 800 insertions(+)
create mode 100644 arch/riscv/include/asm/kvm_host.h
create mode 100644 arch/riscv/include/uapi/asm/kvm.h
create mode 100644 arch/riscv/kvm/Kconfig
create mode 100644 arch/riscv/kvm/Makefile
create mode 100644 arch/riscv/kvm/main.c
create mode 100644 arch/riscv/kvm/mmu.c
create mode 100644 arch/riscv/kvm/vcpu.c
create mode 100644 arch/riscv/kvm/vcpu_exit.c
create mode 100644 arch/riscv/kvm/vm.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e9dbfd7d7738..e4b33939d1c7 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -386,3 +386,5 @@ menu "Power management options"
source "kernel/power/Kconfig"
endmenu
+
+source "arch/riscv/kvm/Kconfig"
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index fb6e37db836d..fc189284b245 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -79,6 +79,8 @@ head-y := arch/riscv/kernel/head.o
core-y += arch/riscv/
+core-$(CONFIG_KVM) += arch/riscv/kvm/
+
libs-y += arch/riscv/lib/
PHONY += vdso_install
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
new file mode 100644
index ..ad4a5e1a6cd3
--- /dev/null
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Anup Patel
+ */
+
+#ifndef __RISCV_KVM_HOST_H__
+#define __RISCV_KVM_HOST_H__
+
+#include
+#include
+#include
+
+#ifdef CONFIG_64BIT
+#define KVM_MAX_VCPUS (1U << 16)
+#else
+#define KVM_MAX_VCPUS (1U << 9)
+#endif
+
+#define KVM_USER_MEM_SLOTS 512
+#define KVM_HALT_POLL_NS_DEFAULT 50
+
+#define KVM_VCPU_MAX_FEATURES 0
+
+#define KVM_REQ_SLEEP \
+ KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
+#define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(1)
+
+struct kvm_vm_stat {
+ ulong remote_tlb_flush;
+};
+
+struct kvm_vcpu_stat {
+ u64 halt_successful_poll;
+ u64 halt_attempted_poll;
+ u64 halt_poll_invalid;
+ u64 halt_wakeup;
+ u64 ecall_exit_stat;
+ u64 wfi_exit_stat;
+ u64 mmio_exit_user;
+ u64 mmio_exit_kernel;
+ u64 exits;
+};
+
+struct kvm_arch_memory_slot {
+};
+
+struct kvm_arch {
+ /* stage2 page table */
+ pgd_t *pgd;
+ phys_addr_t pgd_phys;
+};
+
+struct kvm_cpu_trap {
+ unsigned long sepc;
+ unsigned long scause;
+ unsigned long stval;
+ unsigned long htval;
+ unsigned long htinst;
+};
+
+struct kvm_vcpu_arch {
+ /* Don't run the VCPU (blocked) */
+ bool pause;
+
+ /* SRCU lock index for in-kernel run loop */
+ int srcu_idx;
+};
+
+static inline void kvm_arch_hardware_unsetup(void) {}
+static inline void kvm_arch_sync_events(struct kvm *kvm) {}
+static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
+static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
+static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
+
+void kvm_riscv_stage2_flush_cache(struct kvm_vcpu *vcpu);
+int kvm_riscv_stage2_alloc_pgd(struct kvm *kvm);
+void kvm_riscv_stage2_free_pgd(struct kvm *kvm);
+void kvm_riscv_stage2_update_hgatp(struct kvm_vcpu *vcpu);
+
+int kvm_riscv_vcpu_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
+ struct kvm_cpu_trap *trap);
+
+static inline void __kvm_riscv_switch_to(struct kvm_vcpu_arch *vcpu_arch) {}
+
+#endif /* __RISCV_KVM_HOST_H__ */
diff --git a/arch/riscv/include/uapi/asm/kvm.h
b/arch/riscv/include/uapi/asm/kvm.h
new file mode 100644
index ..d15875818b6e
--- /dev/null
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 20
[PATCH v12 01/17] RISC-V: Add hypervisor extension related CSR defines
This patch extends asm/csr.h by adding RISC-V hypervisor extension related defines. Signed-off-by: Anup Patel Acked-by: Paolo Bonzini Reviewed-by: Paolo Bonzini Reviewed-by: Alexander Graf --- arch/riscv/include/asm/csr.h | 85 1 file changed, 85 insertions(+) diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h index cec462e198ce..ec6a1917bb0d 100644 --- a/arch/riscv/include/asm/csr.h +++ b/arch/riscv/include/asm/csr.h @@ -30,6 +30,8 @@ #define SR_XS_CLEAN_AC(0x0001, UL) #define SR_XS_DIRTY_AC(0x00018000, UL) +#define SR_MXR _AC(0x0008, UL) + #ifndef CONFIG_64BIT #define SR_SD _AC(0x8000, UL) /* FS/XS dirty */ #else @@ -52,22 +54,31 @@ /* Interrupt causes (minus the high bit) */ #define IRQ_S_SOFT 1 +#define IRQ_VS_SOFT2 #define IRQ_M_SOFT 3 #define IRQ_S_TIMER5 +#define IRQ_VS_TIMER 6 #define IRQ_M_TIMER7 #define IRQ_S_EXT 9 +#define IRQ_VS_EXT 10 #define IRQ_M_EXT 11 /* Exception causes */ #define EXC_INST_MISALIGNED0 #define EXC_INST_ACCESS1 +#define EXC_INST_ILLEGAL 2 #define EXC_BREAKPOINT 3 #define EXC_LOAD_ACCESS5 #define EXC_STORE_ACCESS 7 #define EXC_SYSCALL8 +#define EXC_HYPERVISOR_SYSCALL 9 +#define EXC_SUPERVISOR_SYSCALL 10 #define EXC_INST_PAGE_FAULT12 #define EXC_LOAD_PAGE_FAULT13 #define EXC_STORE_PAGE_FAULT 15 +#define EXC_INST_GUEST_PAGE_FAULT 20 +#define EXC_LOAD_GUEST_PAGE_FAULT 21 +#define EXC_STORE_GUEST_PAGE_FAULT 23 /* PMP configuration */ #define PMP_R 0x01 @@ -79,6 +90,55 @@ #define PMP_A_NAPOT0x18 #define PMP_L 0x80 +/* HSTATUS flags */ +#ifdef CONFIG_64BIT +#define HSTATUS_VSXL _AC(0x3, UL) +#define HSTATUS_VSXL_SHIFT 32 +#endif +#define HSTATUS_VTSR _AC(0x0040, UL) +#define HSTATUS_VTVM _AC(0x0010, UL) +#define HSTATUS_VGEIN _AC(0x0003f000, UL) +#define HSTATUS_VGEIN_SHIFT12 +#define HSTATUS_HU _AC(0x0200, UL) +#define HSTATUS_SPVP _AC(0x0100, UL) +#define HSTATUS_SPV_AC(0x0080, UL) +#define HSTATUS_GVA_AC(0x0040, UL) +#define HSTATUS_VSBE _AC(0x0020, UL) + +/* HGATP flags */ +#define HGATP_MODE_OFF _AC(0, UL) +#define HGATP_MODE_SV32X4 _AC(1, UL) +#define HGATP_MODE_SV39X4 _AC(8, UL) +#define HGATP_MODE_SV48X4 _AC(9, UL) + +#define HGATP32_MODE_SHIFT 31 +#define HGATP32_VMID_SHIFT 22 +#define HGATP32_VMID_MASK _AC(0x1FC0, UL) +#define HGATP32_PPN_AC(0x003F, UL) + +#define HGATP64_MODE_SHIFT 60 +#define HGATP64_VMID_SHIFT 44 +#define HGATP64_VMID_MASK _AC(0x03FFF000, UL) +#define HGATP64_PPN_AC(0x0FFF, UL) + +#ifdef CONFIG_64BIT +#define HGATP_PPN HGATP64_PPN +#define HGATP_VMID_SHIFT HGATP64_VMID_SHIFT +#define HGATP_VMID_MASKHGATP64_VMID_MASK +#define HGATP_MODE (HGATP_MODE_SV39X4 << HGATP64_MODE_SHIFT) +#else +#define HGATP_PPN HGATP32_PPN +#define HGATP_VMID_SHIFT HGATP32_VMID_SHIFT +#define HGATP_VMID_MASKHGATP32_VMID_MASK +#define HGATP_MODE (HGATP_MODE_SV32X4 << HGATP32_MODE_SHIFT) +#endif + +/* VSIP & HVIP relation */ +#define VSIP_TO_HVIP_SHIFT (IRQ_VS_SOFT - IRQ_S_SOFT) +#define VSIP_VALID_MASK((_AC(1, UL) << IRQ_S_SOFT) | \ +(_AC(1, UL) << IRQ_S_TIMER) | \ +(_AC(1, UL) << IRQ_S_EXT)) + /* symbolic CSR names: */ #define CSR_CYCLE 0xc00 #define CSR_TIME 0xc01 @@ -98,6 +158,31 @@ #define CSR_SIP0x144 #define CSR_SATP 0x180 +#define CSR_VSSTATUS 0x200 +#define CSR_VSIE 0x204 +#define CSR_VSTVEC 0x205 +#define CSR_VSSCRATCH 0x240 +#define CSR_VSEPC 0x241 +#define CSR_VSCAUSE0x242 +#define CSR_VSTVAL 0x243 +#define CSR_VSIP 0x244 +#define CSR_VSATP 0x280 + +#define CSR_HSTATUS0x600 +#define CSR_HEDELEG0x602 +#define CSR_HIDELEG0x603 +#define CSR_HIE0x604 +#define CSR_HTIMEDELTA 0x605 +#define CSR_HCOUNTERNEN0x606 +#define CSR_HGEIE 0x607 +#define CSR_HTIMEDELTAH0x615 +#define CSR_HTVAL 0x643 +#define CSR_HIP0x644 +#define CSR_HVIP 0x645 +#define CSR_HTINST 0x64a +#define CSR_HGATP 0x680 +#define CSR_HGEIP 0xe12 + #define CSR_MSTATUS0x300 #define CSR_MISA 0x301 #define CSR_MIE
[PATCH v12 04/17] RISC-V: KVM: Implement VCPU interrupts and requests handling
This patch implements VCPU interrupts and requests which are both
asynchronous events.
The VCPU interrupts can be set/unset using KVM_INTERRUPT ioctl from
user-space. In future, the in-kernel IRQCHIP emulation will use
kvm_riscv_vcpu_set_interrupt() and kvm_riscv_vcpu_unset_interrupt()
functions to set/unset VCPU interrupts.
Important VCPU requests implemented by this patch are:
KVM_REQ_SLEEP - set whenever VCPU itself goes to sleep state
KVM_REQ_VCPU_RESET - set whenever VCPU reset is requested
The WFI trap-n-emulate (added later) will use KVM_REQ_SLEEP request
and kvm_riscv_vcpu_has_interrupt() function.
The KVM_REQ_VCPU_RESET request will be used by SBI emulation (added
later) to power-up a VCPU in power-off state. The user-space can use
the GET_MPSTATE/SET_MPSTATE ioctls to get/set power state of a VCPU.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 23
arch/riscv/include/uapi/asm/kvm.h | 3 +
arch/riscv/kvm/vcpu.c | 182 +++---
3 files changed, 195 insertions(+), 13 deletions(-)
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 51bdd6fe05c7..822b580d96a9 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -130,6 +130,21 @@ struct kvm_vcpu_arch {
/* CPU CSR context upon Guest VCPU reset */
struct kvm_vcpu_csr guest_reset_csr;
+ /*
+* VCPU interrupts
+*
+* We have a lockless approach for tracking pending VCPU interrupts
+* implemented using atomic bitops. The irqs_pending bitmap represent
+* pending interrupts whereas irqs_pending_mask represent bits changed
+* in irqs_pending. Our approach is modeled around multiple producer
+* and single consumer problem where the consumer is the VCPU itself.
+*/
+ unsigned long irqs_pending;
+ unsigned long irqs_pending_mask;
+
+ /* VCPU power-off state */
+ bool power_off;
+
/* Don't run the VCPU (blocked) */
bool pause;
@@ -154,4 +169,12 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct
kvm_run *run,
static inline void __kvm_riscv_switch_to(struct kvm_vcpu_arch *vcpu_arch) {}
+int kvm_riscv_vcpu_set_interrupt(struct kvm_vcpu *vcpu, unsigned int irq);
+int kvm_riscv_vcpu_unset_interrupt(struct kvm_vcpu *vcpu, unsigned int irq);
+void kvm_riscv_vcpu_flush_interrupts(struct kvm_vcpu *vcpu);
+void kvm_riscv_vcpu_sync_interrupts(struct kvm_vcpu *vcpu);
+bool kvm_riscv_vcpu_has_interrupts(struct kvm_vcpu *vcpu, unsigned long mask);
+void kvm_riscv_vcpu_power_off(struct kvm_vcpu *vcpu);
+void kvm_riscv_vcpu_power_on(struct kvm_vcpu *vcpu);
+
#endif /* __RISCV_KVM_HOST_H__ */
diff --git a/arch/riscv/include/uapi/asm/kvm.h
b/arch/riscv/include/uapi/asm/kvm.h
index d15875818b6e..6dbc056d58ba 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -18,6 +18,9 @@
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+#define KVM_INTERRUPT_SET -1U
+#define KVM_INTERRUPT_UNSET-2U
+
/* for KVM_GET_REGS and KVM_SET_REGS */
struct kvm_regs {
};
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index c37745bd3dbd..97585aeec207 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -50,6 +51,9 @@ static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu)
memcpy(csr, reset_csr, sizeof(*csr));
memcpy(cntx, reset_cntx, sizeof(*cntx));
+
+ WRITE_ONCE(vcpu->arch.irqs_pending, 0);
+ WRITE_ONCE(vcpu->arch.irqs_pending_mask, 0);
}
int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
@@ -97,8 +101,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
{
- /* TODO: */
- return 0;
+ return kvm_riscv_vcpu_has_interrupts(vcpu, 1UL << IRQ_VS_TIMER);
}
void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
@@ -111,20 +114,18 @@ void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu)
int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
{
- /* TODO: */
- return 0;
+ return (kvm_riscv_vcpu_has_interrupts(vcpu, -1UL) &&
+ !vcpu->arch.power_off && !vcpu->arch.pause);
}
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
- /* TODO: */
- return 0;
+ return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
}
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
{
- /* TODO: */
- return false;
+ return (vcpu->arch.guest_context.sstatus & SR_SPP) ? true : false;
}
bool kvm_arch_has_vcpu_debugfs(void)
@@ -145,7 +146,21 @@ vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu,
struct vm_fault *vmf)
long kvm_arch_vcpu_async_ioctl(struct file *filp,
unsigned i
[PATCH v12 03/17] RISC-V: KVM: Implement VCPU create, init and destroy functions
This patch implements VCPU create, init and destroy functions
required by generic KVM module. We don't have much dynamic
resources in struct kvm_vcpu_arch so these functions are quite
simple for KVM RISC-V.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 68 +++
arch/riscv/kvm/vcpu.c | 54
2 files changed, 113 insertions(+), 9 deletions(-)
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index ad4a5e1a6cd3..51bdd6fe05c7 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -61,7 +61,75 @@ struct kvm_cpu_trap {
unsigned long htinst;
};
+struct kvm_cpu_context {
+ unsigned long zero;
+ unsigned long ra;
+ unsigned long sp;
+ unsigned long gp;
+ unsigned long tp;
+ unsigned long t0;
+ unsigned long t1;
+ unsigned long t2;
+ unsigned long s0;
+ unsigned long s1;
+ unsigned long a0;
+ unsigned long a1;
+ unsigned long a2;
+ unsigned long a3;
+ unsigned long a4;
+ unsigned long a5;
+ unsigned long a6;
+ unsigned long a7;
+ unsigned long s2;
+ unsigned long s3;
+ unsigned long s4;
+ unsigned long s5;
+ unsigned long s6;
+ unsigned long s7;
+ unsigned long s8;
+ unsigned long s9;
+ unsigned long s10;
+ unsigned long s11;
+ unsigned long t3;
+ unsigned long t4;
+ unsigned long t5;
+ unsigned long t6;
+ unsigned long sepc;
+ unsigned long sstatus;
+ unsigned long hstatus;
+};
+
+struct kvm_vcpu_csr {
+ unsigned long vsstatus;
+ unsigned long hie;
+ unsigned long vstvec;
+ unsigned long vsscratch;
+ unsigned long vsepc;
+ unsigned long vscause;
+ unsigned long vstval;
+ unsigned long hvip;
+ unsigned long vsatp;
+};
+
struct kvm_vcpu_arch {
+ /* VCPU ran atleast once */
+ bool ran_atleast_once;
+
+ /* ISA feature bits (similar to MISA) */
+ unsigned long isa;
+
+ /* CPU context of Guest VCPU */
+ struct kvm_cpu_context guest_context;
+
+ /* CPU CSR context of Guest VCPU */
+ struct kvm_vcpu_csr guest_csr;
+
+ /* CPU context upon Guest VCPU reset */
+ struct kvm_cpu_context guest_reset_context;
+
+ /* CPU CSR context upon Guest VCPU reset */
+ struct kvm_vcpu_csr guest_reset_csr;
+
/* Don't run the VCPU (blocked) */
bool pause;
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index b238592db2ba..c37745bd3dbd 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -31,6 +31,27 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
{ NULL }
};
+#define KVM_RISCV_ISA_ALLOWED (riscv_isa_extension_mask(a) | \
+riscv_isa_extension_mask(c) | \
+riscv_isa_extension_mask(d) | \
+riscv_isa_extension_mask(f) | \
+riscv_isa_extension_mask(i) | \
+riscv_isa_extension_mask(m) | \
+riscv_isa_extension_mask(s) | \
+riscv_isa_extension_mask(u))
+
+static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vcpu_csr *csr = &vcpu->arch.guest_csr;
+ struct kvm_vcpu_csr *reset_csr = &vcpu->arch.guest_reset_csr;
+ struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
+ struct kvm_cpu_context *reset_cntx = &vcpu->arch.guest_reset_context;
+
+ memcpy(csr, reset_csr, sizeof(*csr));
+
+ memcpy(cntx, reset_cntx, sizeof(*cntx));
+}
+
int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
{
return 0;
@@ -38,7 +59,24 @@ int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
{
- /* TODO: */
+ struct kvm_cpu_context *cntx;
+
+ /* Mark this VCPU never ran */
+ vcpu->arch.ran_atleast_once = false;
+
+ /* Setup ISA features available to VCPU */
+ vcpu->arch.isa = riscv_isa_extension_base(NULL) & KVM_RISCV_ISA_ALLOWED;
+
+ /* Setup reset state of shadow SSTATUS and HSTATUS CSRs */
+ cntx = &vcpu->arch.guest_reset_context;
+ cntx->sstatus = SR_SPP | SR_SPIE;
+ cntx->hstatus = 0;
+ cntx->hstatus |= HSTATUS_SPVP;
+ cntx->hstatus |= HSTATUS_SPV;
+
+ /* Reset VCPU */
+ kvm_riscv_reset_vcpu(vcpu);
+
return 0;
}
@@ -51,15 +89,10 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
{
}
-int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
-{
- /* TODO: */
- return 0;
-}
-
void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
{
- /* TODO: */
+ /* Flush the pages pre-allocated
[PATCH v12 08/17] RISC-V: KVM: Handle WFI exits for VCPU
We get illegal instruction trap whenever Guest/VM executes WFI
instruction.
This patch handles WFI trap by blocking the trapped VCPU using
kvm_vcpu_block() API. The blocked VCPU will be automatically
resumed whenever a VCPU interrupt is injected from user-space
or from in-kernel IRQCHIP emulation.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
---
arch/riscv/kvm/vcpu_exit.c | 76 ++
1 file changed, 76 insertions(+)
diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
index 35101ba8814d..2384b4bf4939 100644
--- a/arch/riscv/kvm/vcpu_exit.c
+++ b/arch/riscv/kvm/vcpu_exit.c
@@ -12,6 +12,13 @@
#include
#include
+#define INSN_OPCODE_MASK 0x007c
+#define INSN_OPCODE_SHIFT 2
+#define INSN_OPCODE_SYSTEM 28
+
+#define INSN_MASK_WFI 0xff00
+#define INSN_MATCH_WFI 0x1050
+
#define INSN_MATCH_LB 0x3
#define INSN_MASK_LB 0x707f
#define INSN_MATCH_LH 0x1003
@@ -116,6 +123,71 @@
(s32)(((insn) >> 7) & 0x1f))
#define MASK_FUNCT30x7000
+static int truly_illegal_insn(struct kvm_vcpu *vcpu,
+ struct kvm_run *run,
+ ulong insn)
+{
+ struct kvm_cpu_trap utrap = { 0 };
+
+ /* Redirect trap to Guest VCPU */
+ utrap.sepc = vcpu->arch.guest_context.sepc;
+ utrap.scause = EXC_INST_ILLEGAL;
+ utrap.stval = insn;
+ kvm_riscv_vcpu_trap_redirect(vcpu, &utrap);
+
+ return 1;
+}
+
+static int system_opcode_insn(struct kvm_vcpu *vcpu,
+ struct kvm_run *run,
+ ulong insn)
+{
+ if ((insn & INSN_MASK_WFI) == INSN_MATCH_WFI) {
+ vcpu->stat.wfi_exit_stat++;
+ if (!kvm_arch_vcpu_runnable(vcpu)) {
+ srcu_read_unlock(&vcpu->kvm->srcu, vcpu->arch.srcu_idx);
+ kvm_vcpu_block(vcpu);
+ vcpu->arch.srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
+ kvm_clear_request(KVM_REQ_UNHALT, vcpu);
+ }
+ vcpu->arch.guest_context.sepc += INSN_LEN(insn);
+ return 1;
+ }
+
+ return truly_illegal_insn(vcpu, run, insn);
+}
+
+static int illegal_inst_fault(struct kvm_vcpu *vcpu, struct kvm_run *run,
+ struct kvm_cpu_trap *trap)
+{
+ unsigned long insn = trap->stval;
+ struct kvm_cpu_trap utrap = { 0 };
+ struct kvm_cpu_context *ct;
+
+ if (unlikely(INSN_IS_16BIT(insn))) {
+ if (insn == 0) {
+ ct = &vcpu->arch.guest_context;
+ insn = kvm_riscv_vcpu_unpriv_read(vcpu, true,
+ ct->sepc,
+ &utrap);
+ if (utrap.scause) {
+ utrap.sepc = ct->sepc;
+ kvm_riscv_vcpu_trap_redirect(vcpu, &utrap);
+ return 1;
+ }
+ }
+ if (INSN_IS_16BIT(insn))
+ return truly_illegal_insn(vcpu, run, insn);
+ }
+
+ switch ((insn & INSN_OPCODE_MASK) >> INSN_OPCODE_SHIFT) {
+ case INSN_OPCODE_SYSTEM:
+ return system_opcode_insn(vcpu, run, insn);
+ default:
+ return truly_illegal_insn(vcpu, run, insn);
+ }
+}
+
static int emulate_load(struct kvm_vcpu *vcpu, struct kvm_run *run,
unsigned long fault_addr, unsigned long htinst)
{
@@ -549,6 +621,10 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct
kvm_run *run,
ret = -EFAULT;
run->exit_reason = KVM_EXIT_UNKNOWN;
switch (trap->scause) {
+ case EXC_INST_ILLEGAL:
+ if (vcpu->arch.guest_context.hstatus & HSTATUS_SPV)
+ ret = illegal_inst_fault(vcpu, run, trap);
+ break;
case EXC_INST_GUEST_PAGE_FAULT:
case EXC_LOAD_GUEST_PAGE_FAULT:
case EXC_STORE_GUEST_PAGE_FAULT:
--
2.25.1
[PATCH v12 05/17] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls
For KVM RISC-V, we use KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls to access
VCPU config and registers from user-space.
We have three types of VCPU registers:
1. CONFIG - these are VCPU config and capabilities
2. CORE - these are VCPU general purpose registers
3. CSR- these are VCPU control and status registers
The CONFIG register available to user-space is ISA. The ISA register is
a read and write register where user-space can only write the desired
VCPU ISA capabilities before running the VCPU.
The CORE registers available to user-space are PC, RA, SP, GP, TP, A0-A7,
T0-T6, S0-S11 and MODE. Most of these are RISC-V general registers except
PC and MODE. The PC register represents program counter whereas the MODE
register represent VCPU privilege mode (i.e. S/U-mode).
The CSRs available to user-space are SSTATUS, SIE, STVEC, SSCRATCH, SEPC,
SCAUSE, STVAL, SIP, and SATP. All of these are read/write registers.
In future, more VCPU register types will be added (such as FP) for the
KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
---
arch/riscv/include/uapi/asm/kvm.h | 52 ++-
arch/riscv/kvm/vcpu.c | 246 +-
2 files changed, 294 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/include/uapi/asm/kvm.h
b/arch/riscv/include/uapi/asm/kvm.h
index 6dbc056d58ba..3a20327242f1 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -41,10 +41,60 @@ struct kvm_guest_debug_arch {
struct kvm_sync_regs {
};
-/* dummy definition */
+/* for KVM_GET_SREGS and KVM_SET_SREGS */
struct kvm_sregs {
};
+/* CONFIG registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_config {
+ unsigned long isa;
+};
+
+/* CORE registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_core {
+ struct user_regs_struct regs;
+ unsigned long mode;
+};
+
+/* Possible privilege modes for kvm_riscv_core */
+#define KVM_RISCV_MODE_S 1
+#define KVM_RISCV_MODE_U 0
+
+/* CSR registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_csr {
+ unsigned long sstatus;
+ unsigned long sie;
+ unsigned long stvec;
+ unsigned long sscratch;
+ unsigned long sepc;
+ unsigned long scause;
+ unsigned long stval;
+ unsigned long sip;
+ unsigned long satp;
+};
+
+#define KVM_REG_SIZE(id) \
+ (1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
+
+/* If you need to interpret the index values, here is the key: */
+#define KVM_REG_RISCV_TYPE_MASK0xFF00
+#define KVM_REG_RISCV_TYPE_SHIFT 24
+
+/* Config registers are mapped as type 1 */
+#define KVM_REG_RISCV_CONFIG (0x01 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_CONFIG_REG(name) \
+ (offsetof(struct kvm_riscv_config, name) / sizeof(unsigned long))
+
+/* Core registers are mapped as type 2 */
+#define KVM_REG_RISCV_CORE (0x02 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_CORE_REG(name) \
+ (offsetof(struct kvm_riscv_core, name) / sizeof(unsigned long))
+
+/* Control and status registers are mapped as type 3 */
+#define KVM_REG_RISCV_CSR (0x03 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_CSR_REG(name)\
+ (offsetof(struct kvm_riscv_csr, name) / sizeof(unsigned long))
+
#endif
#endif /* __LINUX_KVM_RISCV_H */
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index 97585aeec207..30806f36c996 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#define VCPU_STAT(x) { #x, offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU }
@@ -143,6 +142,225 @@ vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu,
struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+static int kvm_riscv_vcpu_get_reg_config(struct kvm_vcpu *vcpu,
+const struct kvm_one_reg *reg)
+{
+ unsigned long __user *uaddr =
+ (unsigned long __user *)(unsigned long)reg->addr;
+ unsigned long reg_num = reg->id & ~(KVM_REG_ARCH_MASK |
+ KVM_REG_SIZE_MASK |
+ KVM_REG_RISCV_CONFIG);
+ unsigned long reg_val;
+
+ if (KVM_REG_SIZE(reg->id) != sizeof(unsigned long))
+ return -EINVAL;
+
+ switch (reg_num) {
+ case KVM_REG_RISCV_CONFIG_REG(isa):
+ reg_val = vcpu->arch.isa;
+ break;
+ default:
+ return -EINVAL;
+ };
+
+ if (copy_to_user(uaddr, ®_val, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int kvm_riscv_vcpu_set_reg_config(struct kvm_vcpu *vcpu,
+const struct kvm_one_reg *reg)
+{
+ unsigned long
[PATCH v12 06/17] RISC-V: KVM: Implement VCPU world-switch
This patch implements the VCPU world-switch for KVM RISC-V.
The KVM RISC-V world-switch (i.e. __kvm_riscv_switch_to()) mostly
switches general purpose registers, SSTATUS, STVEC, SSCRATCH and
HSTATUS CSRs. Other CSRs are switched via vcpu_load() and vcpu_put()
interface in kvm_arch_vcpu_load() and kvm_arch_vcpu_put() functions
respectively.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 9 +-
arch/riscv/kernel/asm-offsets.c | 76
arch/riscv/kvm/Makefile | 2 +-
arch/riscv/kvm/vcpu.c | 30 -
arch/riscv/kvm/vcpu_switch.S | 194 ++
5 files changed, 307 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/kvm/vcpu_switch.S
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 822b580d96a9..74d4ff6af0a5 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -118,6 +118,13 @@ struct kvm_vcpu_arch {
/* ISA feature bits (similar to MISA) */
unsigned long isa;
+ /* SSCRATCH and STVEC of Host */
+ unsigned long host_sscratch;
+ unsigned long host_stvec;
+
+ /* CPU context of Host */
+ struct kvm_cpu_context host_context;
+
/* CPU context of Guest VCPU */
struct kvm_cpu_context guest_context;
@@ -167,7 +174,7 @@ int kvm_riscv_vcpu_mmio_return(struct kvm_vcpu *vcpu,
struct kvm_run *run);
int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
struct kvm_cpu_trap *trap);
-static inline void __kvm_riscv_switch_to(struct kvm_vcpu_arch *vcpu_arch) {}
+void __kvm_riscv_switch_to(struct kvm_vcpu_arch *vcpu_arch);
int kvm_riscv_vcpu_set_interrupt(struct kvm_vcpu *vcpu, unsigned int irq);
int kvm_riscv_vcpu_unset_interrupt(struct kvm_vcpu *vcpu, unsigned int irq);
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
index 07cb9c10de4e..3a230882b91e 100644
--- a/arch/riscv/kernel/asm-offsets.c
+++ b/arch/riscv/kernel/asm-offsets.c
@@ -7,7 +7,9 @@
#define GENERATING_ASM_OFFSETS
#include
+#include
#include
+#include
#include
#include
@@ -109,6 +111,80 @@ void asm_offsets(void)
OFFSET(PT_BADADDR, pt_regs, badaddr);
OFFSET(PT_CAUSE, pt_regs, cause);
+ OFFSET(KVM_ARCH_GUEST_ZERO, kvm_vcpu_arch, guest_context.zero);
+ OFFSET(KVM_ARCH_GUEST_RA, kvm_vcpu_arch, guest_context.ra);
+ OFFSET(KVM_ARCH_GUEST_SP, kvm_vcpu_arch, guest_context.sp);
+ OFFSET(KVM_ARCH_GUEST_GP, kvm_vcpu_arch, guest_context.gp);
+ OFFSET(KVM_ARCH_GUEST_TP, kvm_vcpu_arch, guest_context.tp);
+ OFFSET(KVM_ARCH_GUEST_T0, kvm_vcpu_arch, guest_context.t0);
+ OFFSET(KVM_ARCH_GUEST_T1, kvm_vcpu_arch, guest_context.t1);
+ OFFSET(KVM_ARCH_GUEST_T2, kvm_vcpu_arch, guest_context.t2);
+ OFFSET(KVM_ARCH_GUEST_S0, kvm_vcpu_arch, guest_context.s0);
+ OFFSET(KVM_ARCH_GUEST_S1, kvm_vcpu_arch, guest_context.s1);
+ OFFSET(KVM_ARCH_GUEST_A0, kvm_vcpu_arch, guest_context.a0);
+ OFFSET(KVM_ARCH_GUEST_A1, kvm_vcpu_arch, guest_context.a1);
+ OFFSET(KVM_ARCH_GUEST_A2, kvm_vcpu_arch, guest_context.a2);
+ OFFSET(KVM_ARCH_GUEST_A3, kvm_vcpu_arch, guest_context.a3);
+ OFFSET(KVM_ARCH_GUEST_A4, kvm_vcpu_arch, guest_context.a4);
+ OFFSET(KVM_ARCH_GUEST_A5, kvm_vcpu_arch, guest_context.a5);
+ OFFSET(KVM_ARCH_GUEST_A6, kvm_vcpu_arch, guest_context.a6);
+ OFFSET(KVM_ARCH_GUEST_A7, kvm_vcpu_arch, guest_context.a7);
+ OFFSET(KVM_ARCH_GUEST_S2, kvm_vcpu_arch, guest_context.s2);
+ OFFSET(KVM_ARCH_GUEST_S3, kvm_vcpu_arch, guest_context.s3);
+ OFFSET(KVM_ARCH_GUEST_S4, kvm_vcpu_arch, guest_context.s4);
+ OFFSET(KVM_ARCH_GUEST_S5, kvm_vcpu_arch, guest_context.s5);
+ OFFSET(KVM_ARCH_GUEST_S6, kvm_vcpu_arch, guest_context.s6);
+ OFFSET(KVM_ARCH_GUEST_S7, kvm_vcpu_arch, guest_context.s7);
+ OFFSET(KVM_ARCH_GUEST_S8, kvm_vcpu_arch, guest_context.s8);
+ OFFSET(KVM_ARCH_GUEST_S9, kvm_vcpu_arch, guest_context.s9);
+ OFFSET(KVM_ARCH_GUEST_S10, kvm_vcpu_arch, guest_context.s10);
+ OFFSET(KVM_ARCH_GUEST_S11, kvm_vcpu_arch, guest_context.s11);
+ OFFSET(KVM_ARCH_GUEST_T3, kvm_vcpu_arch, guest_context.t3);
+ OFFSET(KVM_ARCH_GUEST_T4, kvm_vcpu_arch, guest_context.t4);
+ OFFSET(KVM_ARCH_GUEST_T5, kvm_vcpu_arch, guest_context.t5);
+ OFFSET(KVM_ARCH_GUEST_T6, kvm_vcpu_arch, guest_context.t6);
+ OFFSET(KVM_ARCH_GUEST_SEPC, kvm_vcpu_arch, guest_context.sepc);
+ OFFSET(KVM_ARCH_GUEST_SSTATUS, kvm_vcpu_arch, guest_context.sstatus);
+ OFFSET(KVM_ARCH_GUEST_HSTATUS, kvm_vcpu_arch, guest_context.hstatus);
+
+ OFFSET(KVM_ARCH_HOST_ZERO, kvm_vcpu_arch, host_context.zero);
+ OFFSET(KVM_ARCH_HOST_RA, kvm_vcpu_arch, host_context.ra);
+ OFFSET(KVM_ARCH_HOST_SP, kvm_vcpu_arch, host_cont
[PATCH v12 07/17] RISC-V: KVM: Handle MMIO exits for VCPU
We will get stage2 page faults whenever Guest/VM access SW emulated
MMIO device or unmapped Guest RAM.
This patch implements MMIO read/write emulation by extracting MMIO
details from the trapped load/store instruction and forwarding the
MMIO read/write to user-space. The actual MMIO emulation will happen
in user-space and KVM kernel module will only take care of register
updates before resuming the trapped VCPU.
The handling for stage2 page faults for unmapped Guest RAM will be
implemeted by a separate patch later.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 21 ++
arch/riscv/kernel/asm-offsets.c | 6 +
arch/riscv/kvm/mmu.c | 8 +
arch/riscv/kvm/vcpu_exit.c| 545 +-
arch/riscv/kvm/vcpu_switch.S | 23 ++
5 files changed, 600 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 74d4ff6af0a5..05c84c745c61 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -53,6 +53,13 @@ struct kvm_arch {
phys_addr_t pgd_phys;
};
+struct kvm_mmio_decode {
+ unsigned long insn;
+ int len;
+ int shift;
+ int return_handled;
+};
+
struct kvm_cpu_trap {
unsigned long sepc;
unsigned long scause;
@@ -149,6 +156,9 @@ struct kvm_vcpu_arch {
unsigned long irqs_pending;
unsigned long irqs_pending_mask;
+ /* MMIO instruction details */
+ struct kvm_mmio_decode mmio_decode;
+
/* VCPU power-off state */
bool power_off;
@@ -165,11 +175,22 @@ static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu
*vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
+int kvm_riscv_stage2_map(struct kvm_vcpu *vcpu,
+struct kvm_memory_slot *memslot,
+gpa_t gpa, unsigned long hva, bool is_write);
void kvm_riscv_stage2_flush_cache(struct kvm_vcpu *vcpu);
int kvm_riscv_stage2_alloc_pgd(struct kvm *kvm);
void kvm_riscv_stage2_free_pgd(struct kvm *kvm);
void kvm_riscv_stage2_update_hgatp(struct kvm_vcpu *vcpu);
+void __kvm_riscv_unpriv_trap(void);
+
+unsigned long kvm_riscv_vcpu_unpriv_read(struct kvm_vcpu *vcpu,
+bool read_insn,
+unsigned long guest_addr,
+struct kvm_cpu_trap *trap);
+void kvm_riscv_vcpu_trap_redirect(struct kvm_vcpu *vcpu,
+ struct kvm_cpu_trap *trap);
int kvm_riscv_vcpu_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
struct kvm_cpu_trap *trap);
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
index 3a230882b91e..f7e43fe55335 100644
--- a/arch/riscv/kernel/asm-offsets.c
+++ b/arch/riscv/kernel/asm-offsets.c
@@ -185,6 +185,12 @@ void asm_offsets(void)
OFFSET(KVM_ARCH_HOST_SSCRATCH, kvm_vcpu_arch, host_sscratch);
OFFSET(KVM_ARCH_HOST_STVEC, kvm_vcpu_arch, host_stvec);
+ OFFSET(KVM_ARCH_TRAP_SEPC, kvm_cpu_trap, sepc);
+ OFFSET(KVM_ARCH_TRAP_SCAUSE, kvm_cpu_trap, scause);
+ OFFSET(KVM_ARCH_TRAP_STVAL, kvm_cpu_trap, stval);
+ OFFSET(KVM_ARCH_TRAP_HTVAL, kvm_cpu_trap, htval);
+ OFFSET(KVM_ARCH_TRAP_HTINST, kvm_cpu_trap, htinst);
+
/*
* THREAD_{F,X}* might be larger than a S-type offset can handle, but
* these are used in performance-sensitive assembly so we can't resort
diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
index ec13507e8a18..8fb356e68cc5 100644
--- a/arch/riscv/kvm/mmu.c
+++ b/arch/riscv/kvm/mmu.c
@@ -64,6 +64,14 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
return 0;
}
+int kvm_riscv_stage2_map(struct kvm_vcpu *vcpu,
+struct kvm_memory_slot *memslot,
+gpa_t gpa, unsigned long hva, bool is_write)
+{
+ /* TODO: */
+ return 0;
+}
+
void kvm_riscv_stage2_flush_cache(struct kvm_vcpu *vcpu)
{
/* TODO: */
diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
index 4484e9200fe4..35101ba8814d 100644
--- a/arch/riscv/kvm/vcpu_exit.c
+++ b/arch/riscv/kvm/vcpu_exit.c
@@ -6,9 +6,471 @@
* Anup Patel
*/
+#include
#include
#include
#include
+#include
+
+#define INSN_MATCH_LB 0x3
+#define INSN_MASK_LB 0x707f
+#define INSN_MATCH_LH 0x1003
+#define INSN_MASK_LH 0x707f
+#define INSN_MATCH_LW 0x2003
+#define INSN_MASK_LW 0x707f
+#define INSN_MATCH_LD 0x3003
+#define INSN_MASK_LD 0x707f
+#define INSN_MATCH_LBU 0x4003
+#define INSN_MASK_LBU 0x707f
+#define INS
[PATCH v12 09/17] RISC-V: KVM: Implement VMID allocator
We implement a simple VMID allocator for Guests/VMs which:
1. Detects number of VMID bits at boot-time
2. Uses atomic number to track VMID version and increments
VMID version whenever we run-out of VMIDs
3. Flushes Guest TLBs on all host CPUs whenever we run-out
of VMIDs
4. Force updates HW Stage2 VMID for each Guest VCPU whenever
VMID changes using VCPU request KVM_REQ_UPDATE_HGATP
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 25 +++
arch/riscv/kvm/Makefile | 3 +-
arch/riscv/kvm/main.c | 4 +
arch/riscv/kvm/tlb.S | 43 +++
arch/riscv/kvm/vcpu.c | 9 +++
arch/riscv/kvm/vm.c | 6 ++
arch/riscv/kvm/vmid.c | 120 ++
7 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/kvm/tlb.S
create mode 100644 arch/riscv/kvm/vmid.c
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 05c84c745c61..296a5b13b3a6 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -27,6 +27,7 @@
#define KVM_REQ_SLEEP \
KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
#define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(1)
+#define KVM_REQ_UPDATE_HGATP KVM_ARCH_REQ(2)
struct kvm_vm_stat {
ulong remote_tlb_flush;
@@ -47,7 +48,19 @@ struct kvm_vcpu_stat {
struct kvm_arch_memory_slot {
};
+struct kvm_vmid {
+ /*
+* Writes to vmid_version and vmid happen with vmid_lock held
+* whereas reads happen without any lock held.
+*/
+ unsigned long vmid_version;
+ unsigned long vmid;
+};
+
struct kvm_arch {
+ /* stage2 vmid */
+ struct kvm_vmid vmid;
+
/* stage2 page table */
pgd_t *pgd;
phys_addr_t pgd_phys;
@@ -175,6 +188,12 @@ static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu
*vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
+void __kvm_riscv_hfence_gvma_vmid_gpa(unsigned long vmid,
+ unsigned long gpa);
+void __kvm_riscv_hfence_gvma_vmid(unsigned long vmid);
+void __kvm_riscv_hfence_gvma_gpa(unsigned long gpa);
+void __kvm_riscv_hfence_gvma_all(void);
+
int kvm_riscv_stage2_map(struct kvm_vcpu *vcpu,
struct kvm_memory_slot *memslot,
gpa_t gpa, unsigned long hva, bool is_write);
@@ -183,6 +202,12 @@ int kvm_riscv_stage2_alloc_pgd(struct kvm *kvm);
void kvm_riscv_stage2_free_pgd(struct kvm *kvm);
void kvm_riscv_stage2_update_hgatp(struct kvm_vcpu *vcpu);
+void kvm_riscv_stage2_vmid_detect(void);
+unsigned long kvm_riscv_stage2_vmid_bits(void);
+int kvm_riscv_stage2_vmid_init(struct kvm *kvm);
+bool kvm_riscv_stage2_vmid_ver_changed(struct kvm_vmid *vmid);
+void kvm_riscv_stage2_vmid_update(struct kvm_vcpu *vcpu);
+
void __kvm_riscv_unpriv_trap(void);
unsigned long kvm_riscv_vcpu_unpriv_read(struct kvm_vcpu *vcpu,
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 845579273727..c0f57f26c13d 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -8,6 +8,7 @@ ccflags-y := -Ivirt/kvm -Iarch/riscv/kvm
kvm-objs := $(common-objs-y)
-kvm-objs += main.o vm.o mmu.o vcpu.o vcpu_exit.o vcpu_switch.o
+kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
+kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/arch/riscv/kvm/main.c b/arch/riscv/kvm/main.c
index 4dee84f5c440..6915ac6888a7 100644
--- a/arch/riscv/kvm/main.c
+++ b/arch/riscv/kvm/main.c
@@ -77,8 +77,12 @@ int kvm_arch_init(void *opaque)
return -ENODEV;
}
+ kvm_riscv_stage2_vmid_detect();
+
kvm_info("hypervisor extension available\n");
+ kvm_info("host has %ld VMID bits\n", kvm_riscv_stage2_vmid_bits());
+
return 0;
}
diff --git a/arch/riscv/kvm/tlb.S b/arch/riscv/kvm/tlb.S
new file mode 100644
index ..453fca8d7940
--- /dev/null
+++ b/arch/riscv/kvm/tlb.S
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Anup Patel
+ */
+
+#include
+#include
+
+ .text
+ .altmacro
+ .option norelax
+
+ /*
+* Instruction encoding of hfence.gvma is:
+* 0110001 rs2(5) rs1(5) 000 0 1110011
+*/
+
+ENTRY(__kvm_riscv_hfence_gvma_vmid_gpa)
+ /* hfence.gvma a1, a0 */
+ .word 0x62a60073
+ ret
+ENDPROC(__kvm_riscv_hfence_gvma_vmid_gpa)
+
+ENTRY(__kvm_riscv_hfence_gvma_vmid)
+ /* hfence.gvma zero, a0 */
+ .word 0x62a00073
+ ret
+ENDPROC(__kvm_riscv_hfence_gvma_vmid)
+
+ENTRY(__kvm_riscv_hfence_gvma_gpa)
+ /* hfence.gvma a0 */
+
[PATCH v12 10/17] RISC-V: KVM: Implement stage2 page table programming
This patch implements all required functions for programming
the stage2 page table for each Guest/VM.
At high-level, the flow of stage2 related functions is similar
from KVM ARM/ARM64 implementation but the stage2 page table
format is quite different for KVM RISC-V.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
---
arch/riscv/include/asm/kvm_host.h | 10 +
arch/riscv/include/asm/pgtable-bits.h | 1 +
arch/riscv/kvm/mmu.c | 574 +-
3 files changed, 575 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 296a5b13b3a6..a75778665546 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -73,6 +73,13 @@ struct kvm_mmio_decode {
int return_handled;
};
+#define KVM_MMU_PAGE_CACHE_NR_OBJS 32
+
+struct kvm_mmu_page_cache {
+ int nobjs;
+ void *objects[KVM_MMU_PAGE_CACHE_NR_OBJS];
+};
+
struct kvm_cpu_trap {
unsigned long sepc;
unsigned long scause;
@@ -172,6 +179,9 @@ struct kvm_vcpu_arch {
/* MMIO instruction details */
struct kvm_mmio_decode mmio_decode;
+ /* Cache pages needed to program page tables with spinlock held */
+ struct kvm_mmu_page_cache mmu_page_cache;
+
/* VCPU power-off state */
bool power_off;
diff --git a/arch/riscv/include/asm/pgtable-bits.h
b/arch/riscv/include/asm/pgtable-bits.h
index bbaeb5d35842..be49d62fcc2b 100644
--- a/arch/riscv/include/asm/pgtable-bits.h
+++ b/arch/riscv/include/asm/pgtable-bits.h
@@ -26,6 +26,7 @@
#define _PAGE_SPECIAL _PAGE_SOFT
#define _PAGE_TABLE _PAGE_PRESENT
+#define _PAGE_LEAF (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC)
/*
* _PAGE_PROT_NONE is set on not-present pages (and ignored by the hardware) to
diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
index 8fb356e68cc5..9daeb4a051e7 100644
--- a/arch/riscv/kvm/mmu.c
+++ b/arch/riscv/kvm/mmu.c
@@ -17,6 +17,357 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_64BIT
+#define stage2_have_pmdtrue
+#define stage2_gpa_size((gpa_t)(1ULL << 39))
+#define stage2_pgd_levels 3
+#define stage2_index_bits 9
+#else
+#define stage2_have_pmdfalse
+#define stage2_gpa_size((gpa_t)(1ULL << 32))
+#define stage2_pgd_levels 2
+#define stage2_index_bits 10
+#endif
+
+#define stage2_pte_index(addr, level) \
+(((addr) >> (PAGE_SHIFT + stage2_index_bits * (level))) & (PTRS_PER_PTE - 1))
+
+static inline unsigned long stage2_pte_page_vaddr(pte_t pte)
+{
+ return (unsigned long)pfn_to_virt(pte_val(pte) >> _PAGE_PFN_SHIFT);
+}
+
+static int stage2_page_size_to_level(unsigned long page_size, u32 *out_level)
+{
+ if (page_size == PAGE_SIZE)
+ *out_level = 0;
+ else if (page_size == PMD_SIZE)
+ *out_level = 1;
+ else if (page_size == PGDIR_SIZE)
+ *out_level = (stage2_have_pmd) ? 2 : 1;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static int stage2_level_to_page_size(u32 level, unsigned long *out_pgsize)
+{
+ switch (level) {
+ case 0:
+ *out_pgsize = PAGE_SIZE;
+ break;
+ case 1:
+ *out_pgsize = (stage2_have_pmd) ? PMD_SIZE : PGDIR_SIZE;
+ break;
+ case 2:
+ *out_pgsize = PGDIR_SIZE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int stage2_cache_topup(struct kvm_mmu_page_cache *pcache,
+ int min, int max)
+{
+ void *page;
+
+ BUG_ON(max > KVM_MMU_PAGE_CACHE_NR_OBJS);
+ if (pcache->nobjs >= min)
+ return 0;
+ while (pcache->nobjs < max) {
+ page = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+ if (!page)
+ return -ENOMEM;
+ pcache->objects[pcache->nobjs++] = page;
+ }
+
+ return 0;
+}
+
+static void stage2_cache_flush(struct kvm_mmu_page_cache *pcache)
+{
+ while (pcache && pcache->nobjs)
+ free_page((unsigned long)pcache->objects[--pcache->nobjs]);
+}
+
+static void *stage2_cache_alloc(struct kvm_mmu_page_cache *pcache)
+{
+ void *p;
+
+ if (!pcache)
+ return NULL;
+
+ BUG_ON(!pcache->nobjs);
+ p = pcache->objects[--pcache->nobjs];
+
+ return p;
+}
+
+static bool stage2_get_leaf_entry(struct kvm *kvm, gpa_t addr,
+ pte_t **ptepp, u32 *ptep_level)
+{
+ pte_t *ptep;
+ u32 current_level = stage2_pgd_levels - 1;
+
+ *ptep_level = current_level;
+ ptep = (pte_t *)kvm->arch.pgd;
+ ptep = &ptep[stage2_pte_index(addr, current_level)];
+ while (ptep && pte_val(*ptep)) {
+ if (pte_val(*ptep) & _PAGE_LEAF) {
+
Re: [PATCH RFC 01/15] drivers/base: Introduce platform_msi_ops
On Mon, Apr 27, 2020 at 02:38:12PM -0700, Dave Jiang wrote: > > > On 4/26/2020 12:01 AM, Greg KH wrote: > > On Tue, Apr 21, 2020 at 04:33:53PM -0700, Dave Jiang wrote: > > > From: Megha Dey > > > > > > This is a preparatory patch to introduce Interrupt Message Store (IMS). > > > > > > Until now, platform-msi.c provided a generic way to handle non-PCI MSI > > > interrupts. Platform-msi uses its parent chip's mask/unmask routines > > > and only provides a way to write the message in the generating device. > > > > > > Newly creeping non-PCI complaint MSI-like interrupts (Intel's IMS for > > > instance) might need to provide a device specific mask and unmask callback > > > as well, apart from the write function. > > > > > > Hence, introduce a new structure platform_msi_ops, which would provide > > > device specific write function as well as other device specific callbacks > > > (mask/unmask). > > > > > > Signed-off-by: Megha Dey > > > > As this is not following the Intel-specific rules for sending me new > > code, I am just deleting it all from my inbox. > > That is my fault. As the aggregator of the patches, I should've signed off > Megha's patches. That is NOT the Intel-specific rules I am talking about. Please go work with the "Linux group" at Intel to find out what I am referring to, they know what I mean. The not-signing-off is just a normal kernel community rule, everyone has to follow that. greg k-h
[PATCH v12 11/17] RISC-V: KVM: Implement MMU notifiers
This patch implements MMU notifiers for KVM RISC-V so that Guest
physical address space is in-sync with Host physical address space.
This will allow swapping, page migration, etc to work transparently
with KVM RISC-V.
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 7 ++
arch/riscv/kvm/Kconfig| 1 +
arch/riscv/kvm/mmu.c | 129 +-
arch/riscv/kvm/vm.c | 1 +
4 files changed, 137 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index a75778665546..642fd817c29b 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -198,6 +198,13 @@ static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu
*vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
+#define KVM_ARCH_WANT_MMU_NOTIFIER
+int kvm_unmap_hva_range(struct kvm *kvm,
+ unsigned long start, unsigned long end);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
+int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
+
void __kvm_riscv_hfence_gvma_vmid_gpa(unsigned long vmid,
unsigned long gpa);
void __kvm_riscv_hfence_gvma_vmid(unsigned long vmid);
diff --git a/arch/riscv/kvm/Kconfig b/arch/riscv/kvm/Kconfig
index 88edd477b3a8..2356dc52ebb3 100644
--- a/arch/riscv/kvm/Kconfig
+++ b/arch/riscv/kvm/Kconfig
@@ -20,6 +20,7 @@ if VIRTUALIZATION
config KVM
tristate "Kernel-based Virtual Machine (KVM) support (EXPERIMENTAL)"
depends on RISCV_SBI && MMU
+ select MMU_NOTIFIER
select PREEMPT_NOTIFIERS
select ANON_INODES
select KVM_MMIO
diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
index 9daeb4a051e7..692141ce9bfc 100644
--- a/arch/riscv/kvm/mmu.c
+++ b/arch/riscv/kvm/mmu.c
@@ -369,6 +369,38 @@ int stage2_ioremap(struct kvm *kvm, gpa_t gpa, phys_addr_t
hpa,
}
+static int handle_hva_to_gpa(struct kvm *kvm,
+unsigned long start,
+unsigned long end,
+int (*handler)(struct kvm *kvm,
+ gpa_t gpa, u64 size,
+ void *data),
+void *data)
+{
+ struct kvm_memslots *slots;
+ struct kvm_memory_slot *memslot;
+ int ret = 0;
+
+ slots = kvm_memslots(kvm);
+
+ /* we only care about the pages that the guest sees */
+ kvm_for_each_memslot(memslot, slots) {
+ unsigned long hva_start, hva_end;
+ gfn_t gpa;
+
+ hva_start = max(start, memslot->userspace_addr);
+ hva_end = min(end, memslot->userspace_addr +
+ (memslot->npages << PAGE_SHIFT));
+ if (hva_start >= hva_end)
+ continue;
+
+ gpa = hva_to_gfn_memslot(hva_start, memslot) << PAGE_SHIFT;
+ ret |= handler(kvm, gpa, (u64)(hva_end - hva_start), data);
+ }
+
+ return ret;
+}
+
void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
{
}
@@ -504,6 +536,95 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
return ret;
}
+static int kvm_unmap_hva_handler(struct kvm *kvm,
+gpa_t gpa, u64 size, void *data)
+{
+ stage2_unmap_range(kvm, gpa, size);
+ return 0;
+}
+
+int kvm_unmap_hva_range(struct kvm *kvm,
+ unsigned long start, unsigned long end)
+{
+ if (!kvm->arch.pgd)
+ return 0;
+
+ handle_hva_to_gpa(kvm, start, end,
+ &kvm_unmap_hva_handler, NULL);
+ return 0;
+}
+
+static int kvm_set_spte_handler(struct kvm *kvm,
+ gpa_t gpa, u64 size, void *data)
+{
+ pte_t *pte = (pte_t *)data;
+
+ WARN_ON(size != PAGE_SIZE);
+ stage2_set_pte(kvm, 0, NULL, gpa, pte);
+
+ return 0;
+}
+
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+{
+ unsigned long end = hva + PAGE_SIZE;
+ kvm_pfn_t pfn = pte_pfn(pte);
+ pte_t stage2_pte;
+
+ if (!kvm->arch.pgd)
+ return 0;
+
+ stage2_pte = pfn_pte(pfn, PAGE_WRITE_EXEC);
+ handle_hva_to_gpa(kvm, hva, end,
+ &kvm_set_spte_handler, &stage2_pte);
+
+ return 0;
+}
+
+static int kvm_age_hva_handler(struct kvm *kvm,
+ gpa_t gpa, u64 size, void *data)
+{
+ pte_t *ptep;
+ u32 ptep_level = 0;
+
+ WARN_ON(size != PAGE_SIZE && size != PMD_SIZE && size != PGDIR_SIZE);
+
+ if (!stag
[PATCH v12 13/17] RISC-V: KVM: FP lazy save/restore
From: Atish Patra
This patch adds floating point (F and D extension) context save/restore
for guest VCPUs. The FP context is saved and restored lazily only when
kernel enter/exits the in-kernel run loop and not during the KVM world
switch. This way FP save/restore has minimal impact on KVM performance.
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/asm/kvm_host.h | 5 +
arch/riscv/kernel/asm-offsets.c | 72 +
arch/riscv/kvm/vcpu.c | 81 ++
arch/riscv/kvm/vcpu_switch.S | 174 ++
4 files changed, 332 insertions(+)
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 8bf3e7250ce9..0677b5a70ac1 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -128,6 +128,7 @@ struct kvm_cpu_context {
unsigned long sepc;
unsigned long sstatus;
unsigned long hstatus;
+ union __riscv_fp_state fp;
};
struct kvm_vcpu_csr {
@@ -245,6 +246,10 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct
kvm_run *run,
struct kvm_cpu_trap *trap);
void __kvm_riscv_switch_to(struct kvm_vcpu_arch *vcpu_arch);
+void __kvm_riscv_fp_f_save(struct kvm_cpu_context *context);
+void __kvm_riscv_fp_f_restore(struct kvm_cpu_context *context);
+void __kvm_riscv_fp_d_save(struct kvm_cpu_context *context);
+void __kvm_riscv_fp_d_restore(struct kvm_cpu_context *context);
int kvm_riscv_vcpu_set_interrupt(struct kvm_vcpu *vcpu, unsigned int irq);
int kvm_riscv_vcpu_unset_interrupt(struct kvm_vcpu *vcpu, unsigned int irq);
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
index f7e43fe55335..80673f7ef5cf 100644
--- a/arch/riscv/kernel/asm-offsets.c
+++ b/arch/riscv/kernel/asm-offsets.c
@@ -191,6 +191,78 @@ void asm_offsets(void)
OFFSET(KVM_ARCH_TRAP_HTVAL, kvm_cpu_trap, htval);
OFFSET(KVM_ARCH_TRAP_HTINST, kvm_cpu_trap, htinst);
+ /* F extension */
+
+ OFFSET(KVM_ARCH_FP_F_F0, kvm_cpu_context, fp.f.f[0]);
+ OFFSET(KVM_ARCH_FP_F_F1, kvm_cpu_context, fp.f.f[1]);
+ OFFSET(KVM_ARCH_FP_F_F2, kvm_cpu_context, fp.f.f[2]);
+ OFFSET(KVM_ARCH_FP_F_F3, kvm_cpu_context, fp.f.f[3]);
+ OFFSET(KVM_ARCH_FP_F_F4, kvm_cpu_context, fp.f.f[4]);
+ OFFSET(KVM_ARCH_FP_F_F5, kvm_cpu_context, fp.f.f[5]);
+ OFFSET(KVM_ARCH_FP_F_F6, kvm_cpu_context, fp.f.f[6]);
+ OFFSET(KVM_ARCH_FP_F_F7, kvm_cpu_context, fp.f.f[7]);
+ OFFSET(KVM_ARCH_FP_F_F8, kvm_cpu_context, fp.f.f[8]);
+ OFFSET(KVM_ARCH_FP_F_F9, kvm_cpu_context, fp.f.f[9]);
+ OFFSET(KVM_ARCH_FP_F_F10, kvm_cpu_context, fp.f.f[10]);
+ OFFSET(KVM_ARCH_FP_F_F11, kvm_cpu_context, fp.f.f[11]);
+ OFFSET(KVM_ARCH_FP_F_F12, kvm_cpu_context, fp.f.f[12]);
+ OFFSET(KVM_ARCH_FP_F_F13, kvm_cpu_context, fp.f.f[13]);
+ OFFSET(KVM_ARCH_FP_F_F14, kvm_cpu_context, fp.f.f[14]);
+ OFFSET(KVM_ARCH_FP_F_F15, kvm_cpu_context, fp.f.f[15]);
+ OFFSET(KVM_ARCH_FP_F_F16, kvm_cpu_context, fp.f.f[16]);
+ OFFSET(KVM_ARCH_FP_F_F17, kvm_cpu_context, fp.f.f[17]);
+ OFFSET(KVM_ARCH_FP_F_F18, kvm_cpu_context, fp.f.f[18]);
+ OFFSET(KVM_ARCH_FP_F_F19, kvm_cpu_context, fp.f.f[19]);
+ OFFSET(KVM_ARCH_FP_F_F20, kvm_cpu_context, fp.f.f[20]);
+ OFFSET(KVM_ARCH_FP_F_F21, kvm_cpu_context, fp.f.f[21]);
+ OFFSET(KVM_ARCH_FP_F_F22, kvm_cpu_context, fp.f.f[22]);
+ OFFSET(KVM_ARCH_FP_F_F23, kvm_cpu_context, fp.f.f[23]);
+ OFFSET(KVM_ARCH_FP_F_F24, kvm_cpu_context, fp.f.f[24]);
+ OFFSET(KVM_ARCH_FP_F_F25, kvm_cpu_context, fp.f.f[25]);
+ OFFSET(KVM_ARCH_FP_F_F26, kvm_cpu_context, fp.f.f[26]);
+ OFFSET(KVM_ARCH_FP_F_F27, kvm_cpu_context, fp.f.f[27]);
+ OFFSET(KVM_ARCH_FP_F_F28, kvm_cpu_context, fp.f.f[28]);
+ OFFSET(KVM_ARCH_FP_F_F29, kvm_cpu_context, fp.f.f[29]);
+ OFFSET(KVM_ARCH_FP_F_F30, kvm_cpu_context, fp.f.f[30]);
+ OFFSET(KVM_ARCH_FP_F_F31, kvm_cpu_context, fp.f.f[31]);
+ OFFSET(KVM_ARCH_FP_F_FCSR, kvm_cpu_context, fp.f.fcsr);
+
+ /* D extension */
+
+ OFFSET(KVM_ARCH_FP_D_F0, kvm_cpu_context, fp.d.f[0]);
+ OFFSET(KVM_ARCH_FP_D_F1, kvm_cpu_context, fp.d.f[1]);
+ OFFSET(KVM_ARCH_FP_D_F2, kvm_cpu_context, fp.d.f[2]);
+ OFFSET(KVM_ARCH_FP_D_F3, kvm_cpu_context, fp.d.f[3]);
+ OFFSET(KVM_ARCH_FP_D_F4, kvm_cpu_context, fp.d.f[4]);
+ OFFSET(KVM_ARCH_FP_D_F5, kvm_cpu_context, fp.d.f[5]);
+ OFFSET(KVM_ARCH_FP_D_F6, kvm_cpu_context, fp.d.f[6]);
+ OFFSET(KVM_ARCH_FP_D_F7, kvm_cpu_context, fp.d.f[7]);
+ OFFSET(KVM_ARCH_FP_D_F8, kvm_cpu_context, fp.d.f[8]);
+ OFFSET(KVM_ARCH_FP_D_F9, kvm_cpu_context, fp.d.f[9]);
+ OFFSET(KVM_ARCH_FP_D_F10, kvm_cpu_context, fp.d.f[10]);
+ OFFSET(KVM_ARCH_FP_D_F11, kvm_cpu_context, fp.d.f[11]);
+ OFFS
[PATCH v12 14/17] RISC-V: KVM: Implement ONE REG interface for FP registers
From: Atish Patra
Add a KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctl interface for floating
point registers such as F0-F31 and FCSR. This support is added for
both 'F' and 'D' extensions.
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Reviewed-by: Alexander Graf
---
arch/riscv/include/uapi/asm/kvm.h | 10 +++
arch/riscv/kvm/vcpu.c | 104 ++
2 files changed, 114 insertions(+)
diff --git a/arch/riscv/include/uapi/asm/kvm.h
b/arch/riscv/include/uapi/asm/kvm.h
index 8f15eee35a1e..f4274c2e5cdc 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -112,6 +112,16 @@ struct kvm_riscv_timer {
#define KVM_REG_RISCV_TIMER_REG(name) \
(offsetof(struct kvm_riscv_timer, name) / sizeof(u64))
+/* F extension registers are mapped as type 5 */
+#define KVM_REG_RISCV_FP_F (0x05 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_FP_F_REG(name) \
+ (offsetof(struct __riscv_f_ext_state, name) / sizeof(u32))
+
+/* D extension registers are mapped as type 6 */
+#define KVM_REG_RISCV_FP_D (0x06 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_FP_D_REG(name) \
+ (offsetof(struct __riscv_d_ext_state, name) / sizeof(u64))
+
#endif
#endif /* __LINUX_KVM_RISCV_H */
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index 0f4b6b7165aa..a52180404271 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -416,6 +416,98 @@ static int kvm_riscv_vcpu_set_reg_csr(struct kvm_vcpu
*vcpu,
return 0;
}
+static int kvm_riscv_vcpu_get_reg_fp(struct kvm_vcpu *vcpu,
+const struct kvm_one_reg *reg,
+unsigned long rtype)
+{
+ struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
+ unsigned long isa = vcpu->arch.isa;
+ unsigned long __user *uaddr =
+ (unsigned long __user *)(unsigned long)reg->addr;
+ unsigned long reg_num = reg->id & ~(KVM_REG_ARCH_MASK |
+ KVM_REG_SIZE_MASK |
+ rtype);
+ void *reg_val;
+
+ if ((rtype == KVM_REG_RISCV_FP_F) &&
+ riscv_isa_extension_available(&isa, f)) {
+ if (KVM_REG_SIZE(reg->id) != sizeof(u32))
+ return -EINVAL;
+ if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
+ reg_val = &cntx->fp.f.fcsr;
+ else if ((KVM_REG_RISCV_FP_F_REG(f[0]) <= reg_num) &&
+ reg_num <= KVM_REG_RISCV_FP_F_REG(f[31]))
+ reg_val = &cntx->fp.f.f[reg_num];
+ else
+ return -EINVAL;
+ } else if ((rtype == KVM_REG_RISCV_FP_D) &&
+ riscv_isa_extension_available(&isa, d)) {
+ if (reg_num == KVM_REG_RISCV_FP_D_REG(fcsr)) {
+ if (KVM_REG_SIZE(reg->id) != sizeof(u32))
+ return -EINVAL;
+ reg_val = &cntx->fp.d.fcsr;
+ } else if ((KVM_REG_RISCV_FP_D_REG(f[0]) <= reg_num) &&
+ reg_num <= KVM_REG_RISCV_FP_D_REG(f[31])) {
+ if (KVM_REG_SIZE(reg->id) != sizeof(u64))
+ return -EINVAL;
+ reg_val = &cntx->fp.d.f[reg_num];
+ } else
+ return -EINVAL;
+ } else
+ return -EINVAL;
+
+ if (copy_to_user(uaddr, reg_val, KVM_REG_SIZE(reg->id)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int kvm_riscv_vcpu_set_reg_fp(struct kvm_vcpu *vcpu,
+const struct kvm_one_reg *reg,
+unsigned long rtype)
+{
+ struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
+ unsigned long isa = vcpu->arch.isa;
+ unsigned long __user *uaddr =
+ (unsigned long __user *)(unsigned long)reg->addr;
+ unsigned long reg_num = reg->id & ~(KVM_REG_ARCH_MASK |
+ KVM_REG_SIZE_MASK |
+ rtype);
+ void *reg_val;
+
+ if ((rtype == KVM_REG_RISCV_FP_F) &&
+ riscv_isa_extension_available(&isa, f)) {
+ if (KVM_REG_SIZE(reg->id) != sizeof(u32))
+ return -EINVAL;
+ if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
+ reg_val = &cntx->fp.f.fcsr;
+ else if ((KVM_REG_RISCV_FP_F_REG(f[0]) <= reg_num) &&
+ reg_num <= KVM_REG_RISCV_FP_F_REG(f[31]))
+ reg_val = &cntx->fp.f.f[reg_num];
+ else
+ return -EINVAL;
+ } else if ((rtype == KVM_REG_RISCV_FP_D) &&
+ riscv_isa_extension_available(&i
[PATCH v12 15/17] RISC-V: KVM: Add SBI v0.1 support
From: Atish Patra
The KVM host kernel is running in HS-mode needs so we need to handle
the SBI calls coming from guest kernel running in VS-mode.
This patch adds SBI v0.1 support in KVM RISC-V. Almost all SBI v0.1
calls are implemented in KVM kernel module except GETCHAR and PUTCHART
calls which are forwarded to user space because these calls cannot be
implemented in kernel space. In future, when we implement SBI v0.2 for
Guest, we will forward SBI v0.2 experimental and vendor extension calls
to user space.
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
---
arch/riscv/include/asm/kvm_host.h | 10 ++
arch/riscv/kvm/Makefile | 2 +-
arch/riscv/kvm/vcpu.c | 9 ++
arch/riscv/kvm/vcpu_exit.c| 4 +
arch/riscv/kvm/vcpu_sbi.c | 172 ++
include/uapi/linux/kvm.h | 8 ++
6 files changed, 204 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/kvm/vcpu_sbi.c
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 0677b5a70ac1..f7520d4e0b43 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -77,6 +77,10 @@ struct kvm_mmio_decode {
int return_handled;
};
+struct kvm_sbi_context {
+ int return_handled;
+};
+
#define KVM_MMU_PAGE_CACHE_NR_OBJS 32
struct kvm_mmu_page_cache {
@@ -187,6 +191,9 @@ struct kvm_vcpu_arch {
/* MMIO instruction details */
struct kvm_mmio_decode mmio_decode;
+ /* SBI context */
+ struct kvm_sbi_context sbi_context;
+
/* Cache pages needed to program page tables with spinlock held */
struct kvm_mmu_page_cache mmu_page_cache;
@@ -259,4 +266,7 @@ bool kvm_riscv_vcpu_has_interrupts(struct kvm_vcpu *vcpu,
unsigned long mask);
void kvm_riscv_vcpu_power_off(struct kvm_vcpu *vcpu);
void kvm_riscv_vcpu_power_on(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_sbi_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu, struct kvm_run *run);
+
#endif /* __RISCV_KVM_HOST_H__ */
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 3e0c7558320d..b56dc1650d2c 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -9,6 +9,6 @@ ccflags-y := -Ivirt/kvm -Iarch/riscv/kvm
kvm-objs := $(common-objs-y)
kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
-kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o
+kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o vcpu_sbi.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index a52180404271..567804268c39 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -866,6 +866,15 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
}
}
+ /* Process SBI value returned from user-space */
+ if (run->exit_reason == KVM_EXIT_RISCV_SBI) {
+ ret = kvm_riscv_vcpu_sbi_return(vcpu, vcpu->run);
+ if (ret) {
+ srcu_read_unlock(&vcpu->kvm->srcu, vcpu->arch.srcu_idx);
+ return ret;
+ }
+ }
+
if (run->immediate_exit) {
srcu_read_unlock(&vcpu->kvm->srcu, vcpu->arch.srcu_idx);
return -EINTR;
diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
index 2384b4bf4939..d826ce6f1e98 100644
--- a/arch/riscv/kvm/vcpu_exit.c
+++ b/arch/riscv/kvm/vcpu_exit.c
@@ -631,6 +631,10 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct
kvm_run *run,
if (vcpu->arch.guest_context.hstatus & HSTATUS_SPV)
ret = stage2_page_fault(vcpu, run, trap);
break;
+ case EXC_SUPERVISOR_SYSCALL:
+ if (vcpu->arch.guest_context.hstatus & HSTATUS_SPV)
+ ret = kvm_riscv_vcpu_sbi_ecall(vcpu, run);
+ break;
default:
break;
};
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
new file mode 100644
index ..b04e2b175fbc
--- /dev/null
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SBI_VERSION_MAJOR 0
+#define SBI_VERSION_MINOR 1
+
+static void kvm_sbi_system_shutdown(struct kvm_vcpu *vcpu,
+ struct kvm_run *run, u32 type)
+{
+ int i;
+ struct kvm_vcpu *tmp;
+
+ kvm_for_each_vcpu(i, tmp, vcpu->kvm)
+ tmp->arch.power_off = true;
+ kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_SLEEP);
+
+ memset(&run->system_event, 0, sizeof(run->system_event));
+ run->system_event.type = ty
[PATCH v12 12/17] RISC-V: KVM: Add timer functionality
From: Atish Patra
The RISC-V hypervisor specification doesn't have any virtual timer
feature.
Due to this, the guest VCPU timer will be programmed via SBI calls.
The host will use a separate hrtimer event for each guest VCPU to
provide timer functionality. We inject a virtual timer interrupt to
the guest VCPU whenever the guest VCPU hrtimer event expires.
This patch adds guest VCPU timer implementation along with ONE_REG
interface to access VCPU timer state from user space.
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
Acked-by: Daniel Lezcano
---
arch/riscv/include/asm/kvm_host.h | 7 +
arch/riscv/include/asm/kvm_vcpu_timer.h | 44 +
arch/riscv/include/uapi/asm/kvm.h | 17 ++
arch/riscv/kvm/Makefile | 2 +-
arch/riscv/kvm/vcpu.c | 14 ++
arch/riscv/kvm/vcpu_timer.c | 225
arch/riscv/kvm/vm.c | 2 +-
drivers/clocksource/timer-riscv.c | 8 +
include/clocksource/timer-riscv.h | 16 ++
9 files changed, 333 insertions(+), 2 deletions(-)
create mode 100644 arch/riscv/include/asm/kvm_vcpu_timer.h
create mode 100644 arch/riscv/kvm/vcpu_timer.c
create mode 100644 include/clocksource/timer-riscv.h
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 642fd817c29b..8bf3e7250ce9 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_64BIT
#define KVM_MAX_VCPUS (1U << 16)
@@ -64,6 +65,9 @@ struct kvm_arch {
/* stage2 page table */
pgd_t *pgd;
phys_addr_t pgd_phys;
+
+ /* Guest Timer */
+ struct kvm_guest_timer timer;
};
struct kvm_mmio_decode {
@@ -176,6 +180,9 @@ struct kvm_vcpu_arch {
unsigned long irqs_pending;
unsigned long irqs_pending_mask;
+ /* VCPU Timer */
+ struct kvm_vcpu_timer timer;
+
/* MMIO instruction details */
struct kvm_mmio_decode mmio_decode;
diff --git a/arch/riscv/include/asm/kvm_vcpu_timer.h
b/arch/riscv/include/asm/kvm_vcpu_timer.h
new file mode 100644
index ..375281eb49e0
--- /dev/null
+++ b/arch/riscv/include/asm/kvm_vcpu_timer.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra
+ */
+
+#ifndef __KVM_VCPU_RISCV_TIMER_H
+#define __KVM_VCPU_RISCV_TIMER_H
+
+#include
+
+struct kvm_guest_timer {
+ /* Mult & Shift values to get nanoseconds from cycles */
+ u32 nsec_mult;
+ u32 nsec_shift;
+ /* Time delta value */
+ u64 time_delta;
+};
+
+struct kvm_vcpu_timer {
+ /* Flag for whether init is done */
+ bool init_done;
+ /* Flag for whether timer event is configured */
+ bool next_set;
+ /* Next timer event cycles */
+ u64 next_cycles;
+ /* Underlying hrtimer instance */
+ struct hrtimer hrt;
+};
+
+int kvm_riscv_vcpu_timer_next_event(struct kvm_vcpu *vcpu, u64 ncycles);
+int kvm_riscv_vcpu_get_reg_timer(struct kvm_vcpu *vcpu,
+const struct kvm_one_reg *reg);
+int kvm_riscv_vcpu_set_reg_timer(struct kvm_vcpu *vcpu,
+const struct kvm_one_reg *reg);
+int kvm_riscv_vcpu_timer_init(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_timer_deinit(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_timer_reset(struct kvm_vcpu *vcpu);
+void kvm_riscv_vcpu_timer_restore(struct kvm_vcpu *vcpu);
+int kvm_riscv_guest_timer_init(struct kvm *kvm);
+
+#endif
diff --git a/arch/riscv/include/uapi/asm/kvm.h
b/arch/riscv/include/uapi/asm/kvm.h
index 3a20327242f1..8f15eee35a1e 100644
--- a/arch/riscv/include/uapi/asm/kvm.h
+++ b/arch/riscv/include/uapi/asm/kvm.h
@@ -73,6 +73,18 @@ struct kvm_riscv_csr {
unsigned long satp;
};
+/* TIMER registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_timer {
+ u64 frequency;
+ u64 time;
+ u64 compare;
+ u64 state;
+};
+
+/* Possible states for kvm_riscv_timer */
+#define KVM_RISCV_TIMER_STATE_OFF 0
+#define KVM_RISCV_TIMER_STATE_ON 1
+
#define KVM_REG_SIZE(id) \
(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
@@ -95,6 +107,11 @@ struct kvm_riscv_csr {
#define KVM_REG_RISCV_CSR_REG(name)\
(offsetof(struct kvm_riscv_csr, name) / sizeof(unsigned long))
+/* Timer registers are mapped as type 4 */
+#define KVM_REG_RISCV_TIMER(0x04 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_TIMER_REG(name) \
+ (offsetof(struct kvm_riscv_timer, name) / sizeof(u64))
+
#endif
#endif /* __LINUX_KVM_RISCV_H */
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index c0f57f26c13d..3e0c7558320d 100644
--- a/arch/riscv/kvm/Makefile
[PATCH v12 16/17] RISC-V: KVM: Document RISC-V specific parts of KVM API
Document RISC-V specific parts of the KVM API, such as:
- The interrupt numbers passed to the KVM_INTERRUPT ioctl.
- The states supported by the KVM_{GET,SET}_MP_STATE ioctls.
- The registers supported by the KVM_{GET,SET}_ONE_REG interface
and the encoding of those register ids.
- The exit reason KVM_EXIT_RISCV_SBI for SBI calls forwarded to
userspace tool.
CC: Jonathan Corbet
CC: linux-...@vger.kernel.org
Signed-off-by: Anup Patel
---
Documentation/virt/kvm/api.rst | 193 +++--
1 file changed, 184 insertions(+), 9 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index efbbe570aa9b..c2f9a535993f 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -513,7 +513,7 @@ translation mode.
--
:Capability: basic
-:Architectures: x86, ppc, mips
+:Architectures: x86, ppc, mips, riscv
:Type: vcpu ioctl
:Parameters: struct kvm_interrupt (in)
:Returns: 0 on success, negative on failure.
@@ -582,6 +582,23 @@ interrupt number dequeues the interrupt.
This is an asynchronous vcpu ioctl and can be invoked from any thread.
+RISC-V:
+^^^
+
+Queues an external interrupt to be injected into the virutal CPU. This ioctl
+is overloaded with 2 different irq values:
+
+a) KVM_INTERRUPT_SET
+
+ This sets external interrupt for a virtual CPU and it will receive
+ once it is ready.
+
+b) KVM_INTERRUPT_UNSET
+
+ This clears pending external interrupt for a virtual CPU.
+
+This is an asynchronous vcpu ioctl and can be invoked from any thread.
+
4.17 KVM_DEBUG_GUEST
@@ -1360,7 +1377,7 @@ for vm-wide capabilities.
-
:Capability: KVM_CAP_MP_STATE
-:Architectures: x86, s390, arm, arm64
+:Architectures: x86, s390, arm, arm64, riscv
:Type: vcpu ioctl
:Parameters: struct kvm_mp_state (out)
:Returns: 0 on success; -1 on error
@@ -1377,7 +1394,8 @@ uniprocessor guests).
Possible values are:
==
===
- KVM_MP_STATE_RUNNABLE the vcpu is currently running [x86,arm/arm64]
+ KVM_MP_STATE_RUNNABLE the vcpu is currently running
+ [x86,arm/arm64,riscv]
KVM_MP_STATE_UNINITIALIZEDthe vcpu is an application processor (AP)
which has not yet received an INIT signal
[x86]
KVM_MP_STATE_INIT_RECEIVEDthe vcpu has received an INIT signal, and is
@@ -1386,7 +1404,7 @@ Possible values are:
is waiting for an interrupt [x86]
KVM_MP_STATE_SIPI_RECEIVEDthe vcpu has just received a SIPI (vector
accessible via KVM_GET_VCPU_EVENTS) [x86]
- KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm/arm64]
+ KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm/arm64,riscv]
KVM_MP_STATE_CHECK_STOP the vcpu is in a special error state [s390]
KVM_MP_STATE_OPERATINGthe vcpu is operating (running or halted)
[s390]
@@ -1398,8 +1416,8 @@ On x86, this ioctl is only useful after
KVM_CREATE_IRQCHIP. Without an
in-kernel irqchip, the multiprocessing state must be maintained by userspace on
these architectures.
-For arm/arm64:
-^^
+For arm/arm64/riscv:
+
The only states that are valid are KVM_MP_STATE_STOPPED and
KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not.
@@ -1408,7 +1426,7 @@ KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused
or not.
-
:Capability: KVM_CAP_MP_STATE
-:Architectures: x86, s390, arm, arm64
+:Architectures: x86, s390, arm, arm64, riscv
:Type: vcpu ioctl
:Parameters: struct kvm_mp_state (in)
:Returns: 0 on success; -1 on error
@@ -1420,8 +1438,8 @@ On x86, this ioctl is only useful after
KVM_CREATE_IRQCHIP. Without an
in-kernel irqchip, the multiprocessing state must be maintained by userspace on
these architectures.
-For arm/arm64:
-^^
+For arm/arm64/riscv:
+
The only states that are valid are KVM_MP_STATE_STOPPED and
KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not.
@@ -2532,6 +2550,144 @@ following id bit patterns::
0x7020 0003 02 <0:3>
+RISC-V registers are mapped using the lower 32 bits. The upper 8 bits of
+that is the register group type.
+
+RISC-V config registers are meant for configuring a Guest VCPU and it has
+the following id bit patterns::
+
+ 0x8020 01 (32bit Host)
+ 0x8030 01 (64bit Host)
+
+Following are the RISC-V config registers:
+
+=== = =
+EncodingRegister Description
+=== = =
+ 0x80x0 0100 isa ISA feature bitmap of Guest VCPU
+=== = ===
[PATCH v12 17/17] RISC-V: KVM: Add MAINTAINERS entry
Add myself as maintainer for KVM RISC-V and Atish as designated reviewer. Signed-off-by: Atish Patra Signed-off-by: Anup Patel Acked-by: Paolo Bonzini Reviewed-by: Paolo Bonzini Reviewed-by: Alexander Graf --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 26f281d9f32a..ad3f37a8bdb1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9324,6 +9324,17 @@ F: arch/powerpc/include/uapi/asm/kvm* F: arch/powerpc/kernel/kvm* F: arch/powerpc/kvm/ +KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv) +M: Anup Patel +R: Atish Patra +L: k...@vger.kernel.org +L: kvm-ri...@lists.infradead.org +T: git git://github.com/kvm-riscv/linux.git +S: Maintained +F: arch/riscv/include/uapi/asm/kvm* +F: arch/riscv/include/asm/kvm* +F: arch/riscv/kvm/ + KERNEL VIRTUAL MACHINE for s390 (KVM/s390) M: Christian Borntraeger M: Janosch Frank -- 2.25.1
Re: [PATCH] arm: dts: am33xx-l4: add gpio-line-names to gpio controllers
On 28/04/2020 02:31, Drew Fustini wrote: Add gpio-line-names properties to the gpio controller nodes. The names correspond to the AM335x pin names which are also the muxmode 0 signal names. Refer to "Table 4-2. Pin Attributes" in the TI AM335x Sitara Processors datasheet: http://www.ti.com/lit/ds/symlink/am3358.pdf Signed-off-by: Drew Fustini --- arch/arm/boot/dts/am33xx-l4.dtsi | 134 +++ 1 file changed, 134 insertions(+) diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi index 5ed7f3c58c0f..1ac574ebfe74 100644 --- a/arch/arm/boot/dts/am33xx-l4.dtsi +++ b/arch/arm/boot/dts/am33xx-l4.dtsi @@ -157,6 +157,39 @@ #interrupt-cells = <2>; reg = <0x0 0x1000>; interrupts = <96>; + gpio-line-names = + "MDIO_DATA", + "MDIO_CLK", + "SPI0_SCLK", + "SPI0_D0", + "SPI0_D1", + "SPI0_CS0", + "SPI0_CS1", + "ECAP0_IN_PWM0_OUT", + "LCD_DATA12", + "LCD_DATA13", + "LCD_DATA14", + "LCD_DATA15", + "UART1_CTSN", + "UART1_RTSN", + "UART1_RXD", + "UART1_TXD", + "GMII1_TXD3", + "GMII1_TXD2", + "USB0_DRVVBUS", + "XDMA_EVENT_INTR0", + "XDMA_EVENT_INTR1", + "GMII1_TXD1", + "GPMC_AD8", + "GPMC_AD9", + "NC", + "NC", + "GPMC_AD10", + "GPMC_AD11", + "GMII1_TXD0", + "RMII1_REFCLK", + "GPMC_WAIT0", + "GPMC_WPN"; }; This misuse GPIO DT bindings: " Optionally, a GPIO controller may have a "gpio-line-names" property. This is an array of strings defining the names of the GPIO lines going out of the GPIO controller. This name should be the most meaningful producer name for the system, such as a rail name indicating the usage. Package names such as pin name are discouraged: such lines have opaque names (since they are by definition generic purpose) and such names are usually not very helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are reasonable line names as they describe what the line is used for. "GPIO0" is not a good name to give to a GPIO line. Placeholders are discouraged: rather use the "" (blank string) if the use of the GPIO line is undefined in your design. The names are assigned starting from line offset 0 from left to right from the passed array. An incomplete array (where the number of passed named are less than ngpios) will still be used up until the last provided valid line index. " Additional note. On other TI SoCs like am437x the same gpio line can be routed to more than one pin (but only one pin can be used). gpio0_0 GPIO IO -> A17, D16 -- Best regards, grygorii
Re: [RFC PATCH v1 0/5] media: tegra: Tegra video driver follow-up patches
On 28/04/2020 06:20, Sowjanya Komatineni wrote: > This is a fllow-up to some last feedback received for Tegra VI driver RFC > v10 patches. > https://patchwork.linuxtv.org/cover/63334/ > > > Sowjanya Komatineni (5): > MAINTAINERS: Rename Tegra Video driver path > media: tegra: Rename driver path to tegra-video > media: tegra-video: Move PM runtime handle to streaming > media: tegra-video: Rearrange SoC specific to Tegra210 and cleanup > files > media: tegra-video: Remove module macros for vi and csi driver > > MAINTAINERS |2 +- > drivers/staging/media/Kconfig|2 +- > drivers/staging/media/Makefile |2 +- > drivers/staging/media/tegra-video/Kconfig| 12 + > drivers/staging/media/tegra-video/Makefile |8 + > drivers/staging/media/tegra-video/TODO | 10 + > drivers/staging/media/tegra-video/csi.c | 536 > drivers/staging/media/tegra-video/csi.h | 146 > drivers/staging/media/tegra-video/tegra210.c | 1080 > drivers/staging/media/tegra-video/vi.c | 1082 + > drivers/staging/media/tegra-video/vi.h | 258 ++ > drivers/staging/media/tegra-video/video.c| 155 > drivers/staging/media/tegra-video/video.h| 29 + > drivers/staging/media/tegra/Kconfig | 12 - > drivers/staging/media/tegra/Makefile |8 - > drivers/staging/media/tegra/TODO | 10 - > drivers/staging/media/tegra/common.h | 259 -- > drivers/staging/media/tegra/csi.c| 604 -- > drivers/staging/media/tegra/csi.h| 144 > drivers/staging/media/tegra/tegra210.c | 708 > drivers/staging/media/tegra/tegra210.h | 190 - > drivers/staging/media/tegra/vi.c | 1127 > -- > drivers/staging/media/tegra/vi.h | 72 -- > drivers/staging/media/tegra/video.c | 153 > drivers/staging/media/tegra/video.h | 29 - > 25 files changed, 3319 insertions(+), 3319 deletions(-) I thought that the follow-up series was just a rename of a directory and perhaps one or two smaller changes, but this is too much change. I prefer to have a v11 instead with all these changes incorporated. Sorry about that, Hans > create mode 100644 drivers/staging/media/tegra-video/Kconfig > create mode 100644 drivers/staging/media/tegra-video/Makefile > create mode 100644 drivers/staging/media/tegra-video/TODO > create mode 100644 drivers/staging/media/tegra-video/csi.c > create mode 100644 drivers/staging/media/tegra-video/csi.h > create mode 100644 drivers/staging/media/tegra-video/tegra210.c > create mode 100644 drivers/staging/media/tegra-video/vi.c > create mode 100644 drivers/staging/media/tegra-video/vi.h > create mode 100644 drivers/staging/media/tegra-video/video.c > create mode 100644 drivers/staging/media/tegra-video/video.h > delete mode 100644 drivers/staging/media/tegra/Kconfig > delete mode 100644 drivers/staging/media/tegra/Makefile > delete mode 100644 drivers/staging/media/tegra/TODO > delete mode 100644 drivers/staging/media/tegra/common.h > delete mode 100644 drivers/staging/media/tegra/csi.c > delete mode 100644 drivers/staging/media/tegra/csi.h > delete mode 100644 drivers/staging/media/tegra/tegra210.c > delete mode 100644 drivers/staging/media/tegra/tegra210.h > delete mode 100644 drivers/staging/media/tegra/vi.c > delete mode 100644 drivers/staging/media/tegra/vi.h > delete mode 100644 drivers/staging/media/tegra/video.c > delete mode 100644 drivers/staging/media/tegra/video.h >
Re: linux-next: build failure after merge of the mac80211-next tree
On Tue, Apr 28, 2020 at 09:24:16AM +0200, Johannes Berg wrote:
> On Tue, 2020-04-28 at 10:25 +0300, Sergey Matyukevich wrote:
> > On Tue, Apr 28, 2020 at 09:01:30AM +0200, Johannes Berg wrote:
> > > On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > After merging the mac80211-next tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > Caused by commit
> > > >
> > > > 6cd536fe62ef ("cfg80211: change internal management frame
> > > > registration API")
> > >
> > > Yeah. I forgot about staging. I guess I'll throw in a quick fix.
> > >
> > > johannes
> >
> > Hello Johannes,
> >
> > Could you please take a look at the following fix for this issue:
> > https://patchwork.kernel.org/patch/11509497/
>
> Heh. I was just fixing it too, missed your patch. How do you like this
> fix?
>
> https://p.sipsolutions.net/0638ee56c2e48a30.txt
Looks good. But I have a couple of questions:
- why cleanup vif->mgmt_frame_reg in wilc_mac_open ?
- previously wilc_wfi_p2p_rx was called only for PROBE_REQ and ACTION,
now it will be called for all the other registred frames as well
Regards,
Sergey
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Vadivel MuruganX,
"Ramuthevar, Vadivel MuruganX"
wrote on Tue, 28 Apr 2020
14:50:35 +0800:
> Hi Boris,
>
> On 28/4/2020 2:47 pm, Boris Brezillon wrote:
> > On Tue, 28 Apr 2020 14:40:58 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > wrote:
> >
> >> Hi Boris,
> >>
> >> On 28/4/2020 2:27 pm, Boris Brezillon wrote:
> >>> On Tue, 28 Apr 2020 14:17:30 +0800
> >>> "Ramuthevar, Vadivel MuruganX"
> >>> wrote:
> >>> Hi Miquel,
>
> Thank you very much for the review comments and your time...
>
> On 27/4/2020 11:51 pm, Miquel Raynal wrote:
> > Hi Ramuthevar,
> > >>> +static int ebu_nand_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct device *dev = &pdev->dev;
> >>> + struct ebu_nand_controller *ebu_host;
> >>> + struct nand_chip *nand;
> >>> + phys_addr_t nandaddr_pa;
> >>> + struct mtd_info *mtd;
> >>> + struct resource *res;
> >>> + int ret;
> >>> + u32 cs;
> >>> +
> >>> + ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
> >>> + if (!ebu_host)
> >>> + return -ENOMEM;
> >>> +
> >>> + ebu_host->dev = dev;
> >>> + nand_controller_init(&ebu_host->controller);
> >>> +
> >>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >>> "ebunand");
> >>> + ebu_host->ebu_addr = devm_ioremap_resource(&pdev->dev, res);
> >>> + if (IS_ERR(ebu_host->ebu_addr))
> >>> + return PTR_ERR(ebu_host->ebu_addr);
> >>> +
> >>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >>> "hsnand");
> >>> + ebu_host->nand_addr = devm_ioremap_resource(&pdev->dev, res);
> >>> + if (IS_ERR(ebu_host->nand_addr))
> >>> + return PTR_ERR(ebu_host->nand_addr);
> >>> +
> >>> + ret = device_property_read_u32(dev, "nand,cs", &cs);
> >>
> >> CS ids should be encoded in the reg property (see [1]).
> >
> > Is it your choice to only support a single CS or is it actually a
> > controller limitation?
>
> Yes , its controller limitation to support only one CS
> >>>
> >>> I'm pretty sure that's not true, otherwise you wouldn't have to select
> >>> the CS you want to use :P.
> >>
> >> At a time it supports only one chip select.
> >
> > Yes, like 99% of the NAND controllers, but that doesn't mean you can't
> > support multi-CS chips. All you have to do is attach an array of
> > ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I
> > pointed to). nand_operation.cs tells you which CS (index in your
> > ebu_nand_cs array) a specific operation is targeting, and you can pick
> > the right MMIO range/reg value based on that.
>
> Agreed, sure I will add that and update next series of patches .
There are also many other places where you assume blindly that there
is only one CS. You can check the Atmel NAND controller driver as Boris
said and we will probably propose more little changes to be more
generic.
Thanks,
Miquèl
[PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region
From: Peng Fan When booting xen on i.MX8QM, met: " [3.602128] Unable to handle kernel paging request at virtual address 00272d40 [3.610804] Mem abort info: [3.613905] ESR = 0x9604 [3.617332] EC = 0x25: DABT (current EL), IL = 32 bits [3.623211] SET = 0, FnV = 0 [3.626628] EA = 0, S1PTW = 0 [3.630128] Data abort info: [3.633362] ISV = 0, ISS = 0x0004 [3.637630] CM = 0, WnR = 0 [3.640955] [00272d40] user address but active_mm is swapper [3.647983] Internal error: Oops: 9604 [#1] PREEMPT SMP [3.654137] Modules linked in: [3.677285] Hardware name: Freescale i.MX8QM MEK (DT) [3.677302] Workqueue: events deferred_probe_work_func [3.684253] imx6q-pcie 5f00.pcie: PCI host bridge to bus :00 [3.688297] pstate: 6005 (nZCv daif -PAN -UAO) [3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0 [3.693993] pci_bus :00: root bus resource [bus 00-ff] [3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0 " In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or range_straddles_page_boundary(phys, size) are true, it will create contiguous region. So when free, we need to free contiguous region use upper check condition. Signed-off-by: Peng Fan --- drivers/xen/swiotlb-xen.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index b6d27762c6f8..ab96e468584f 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, /* Convert the size to actually allocated. */ size = 1UL << (order + XEN_PAGE_SHIFT); - if (!WARN_ON((dev_addr + size - 1 > dma_mask) || -range_straddles_page_boundary(phys, size)) && + if (((dev_addr + size - 1 > dma_mask) || + range_straddles_page_boundary(phys, size)) && TestClearPageXenRemapped(virt_to_page(vaddr))) xen_destroy_contiguous_region(phys, order); -- 2.16.4
Re: [patch] mm, oom: stop reclaiming if GFP_ATOMIC will start failing soon
On Mon 27-04-20 16:35:58, Andrew Morton wrote: [...] > No consumer of GFP_ATOMIC memory should consume an unbounded amount of > it. > Subsystems such as networking will consume a certain amount and > will then start recycling it. The total amount in-flight will vary > over the longer term as workloads change. A dynamically tuning > threshold system will need to adapt rapidly enough to sudden load > shifts, which might require unreasonable amounts of headroom. I do agree. __GFP_HIGH/__GFP_ATOMIC are bound by the size of the reserves under memory pressure. Then allocatios start failing very quickly and users have to cope with that, usually by deferring to a sleepable context. Tuning reserves dynamically for heavy reserves consumers would be possible but I am worried that this is far from trivial. We definitely need to understand what is going on here. Why doesn't kswapd + N*direct reclaimers do not provide enough memory to satisfy both N threads + reserves consumers? How many times those direct reclaimers have to retry? We used to have the allocation stall warning as David mentioned in the patch description and I have seen it triggering without heavy reserves consumers (aka reported free pages corresponded to the min watermark). The underlying problem was usually kswapd being stuck on some FS locks, direct reclaimers stuck in shrinkers or way too overloaded system with dozens if not hundreds of processes stuck in the page allocator each racing with the reclaim and betting on luck. The last problem was the most annoying because it is really hard to tune for. -- Michal Hocko SUSE Labs
Re: boot failure: stack-protector: Kernel stack is corrupted in: start_secondary
On Tue, Apr 21, 2020 at 03:32:34AM +0200, Adam Borowski wrote: > Hi! > With kernels compiled with gcc-10, on two different machines (AMD Phenom2, > AMD 2990WX) I get the following panic during boot: Welcome to the party: https://git.kernel.org/tip/f670269a42bfdd2c83a1118cc3d1b475547eac22 Try this branch to check whether it works for ya: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/build Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v2] clk: renesas: cpg-mssr: Add R8A7742 support
Hi Prabhakar,
On Mon, Apr 27, 2020 at 4:41 PM Lad Prabhakar
wrote:
> Add RZ/G1H (R8A7742) Clock Pulse Generator / Module Standby and Software
> Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
> (and RZ/G) code.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
> ---
> Changes for v2:
> * Dropped zt* clocks
> * lb clock is now a base clock
> * Fixed clock-sources for scif2/sdhi1/iic2
> * Dropped setting div to 3 for zg clock
Thanks for the update
> --- /dev/null
> +++ b/drivers/clk/renesas/r8a7742-cpg-mssr.c
> +static struct cpg_core_clk r8a7742_core_clks[] __initdata = {
Missing "const".
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v5.8, with the above fixed (i.e. no need to
resend).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/7] signal: factor copy_siginfo_to_external32 from copy_siginfo_to_user32
Le 28/04/2020 à 09:09, Christoph Hellwig a écrit :
On Mon, Apr 27, 2020 at 03:40:50PM -0700, Andrew Morton wrote:
https://www.spinics.net/lists/kernel/msg3473847.html
https://www.spinics.net/lists/kernel/msg3473840.html
https://www.spinics.net/lists/kernel/msg3473843.html
OK, but that doesn't necessitate the above monstrosity? How about
static int __copy_siginfo_to_user32(struct compat_siginfo __user *to,
const struct kernel_siginfo *from, bool x32_ABI)
{
struct compat_siginfo new;
copy_siginfo_to_external32(&new, from);
...
}
int copy_siginfo_to_user32(struct compat_siginfo __user *to,
const struct kernel_siginfo *from)
{
#if defined(CONFIG_X86_X32_ABI) || defined(CONFIG_IA32_EMULATION)
return __copy_siginfo_to_user32(to, from, in_x32_syscall());
#else
return __copy_siginfo_to_user32(to, from, 0);
#endif
}
Or something like that - I didn't try very hard. We know how to do
this stuff, and surely this thing isn't how!
I guess that might be a worthwhile middle ground. Still not a fan of
all these ifdefs..
Can't we move the small X32 specific part out of
__copy_siginfo_to_user32(), in an arch specific helper that voids for
other architectures ?
Something like:
if (!arch_special_something(&new, from)) {
new.si_utime = from->si_utime;
new.si_stime = from->si_stime;
}
Then the arch_special_something() does what it wants in x86 and returns
1, and for architectures not implementating it, a generic version return
0 all the time.
Christophe
Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall
On Tue, Apr 28, 2020 at 08:39:35AM +0200, Hagen Paul Pfeifer wrote: > * Linus Torvalds | 2020-04-27 21:28:14 [-0700]: > > >> I hate to say this, but I’m not convinced that asking the gdb folks is > >> the right approach. GDB has an ancient architecture and is > >> *incredibly* buggy. I’m sure ptrace is somewhere on the pain point > >> list, but I suspect it’s utterly dwarfed by everything else. > > > >You may be right. However, if gdbn isn't going to use it, then I > >seriously don't think it's worth changing much. > > > >It might be worth looking at people who don't use ptrace() for > >debugging, but for "incidental" reasons. IOW sandboxing, tracing, > >things like that. > > > >Maybe those people want things that are simpler and don't actually > >need the kinds of hard serialization that ptrace() wants. > > > >I'd rather add a few really simple things that might not be a full > >complement of operations for a debugger, but exactly because they > >aren't a full debugger, maybe they are things that we can tell are > >obviously secure and simple? > > Okay, to sum up the the whole discussion: we go forward with Jann's proposal > by simple adding PTRACE_ATTACH_PIDFD and friends. This is the minimal invasive > solution and the risk of an potenial security problem is almost not > present[TM]. > > Changing the whole ptrace API is a different beast. I rather believe that I > see Linus Linux successor rather than a ptrace successor. > > I am fine with PTRACE_ATTACH_PIDFD! If this is enough for you use-case then we should make due with my initial suggestion, yes. I'd be fine with adding this variant. I initially thought that we'd likely would need to support a few more but I don't think we want to actually; there's a bunch of crazy stuff in there. Christian
Re: [PATCH v3 3/3] media: vimc: deb: Add support for {RGB,BGR,GBR}888 bus formats on source pad
hi,
Thanks for the patches!
On 28.04.20 01:03, Nícolas F. R. A. Prado wrote:
Add support for RGB888_*, BGR888_* and GBR888_* media bus formats on
the source pad of debayer subdevices.
Co-developed-by: Vitor Massaru Iha
Signed-off-by: Vitor Massaru Iha
Signed-off-by: Nícolas F. R. A. Prado
---
Changes in v3:
- Rename vimc_deb_is_src_code_invalid() to vimc_deb_src_code_is_valid()
- Change vimc_deb_src_code_is_valid() to return bool
Changes in v2:
- Change commit message to reflect v2 changes
- Rename variables
- Fix array formatting
- Add vimc_deb_is_src_code_valid function
- Add other BGR888 and RGB888 formats to debayer source pad supported
formats
.../media/test-drivers/vimc/vimc-debayer.c| 61 +++
1 file changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/media/test-drivers/vimc/vimc-debayer.c
b/drivers/media/test-drivers/vimc/vimc-debayer.c
index d10aee9f84c4..7e87706d417e 100644
--- a/drivers/media/test-drivers/vimc/vimc-debayer.c
+++ b/drivers/media/test-drivers/vimc/vimc-debayer.c
@@ -51,6 +51,19 @@ static const struct v4l2_mbus_framefmt sink_fmt_default = {
.colorspace = V4L2_COLORSPACE_DEFAULT,
};
+static const u32 vimc_deb_src_mbus_codes[] = {
+ MEDIA_BUS_FMT_GBR888_1X24,
+ MEDIA_BUS_FMT_BGR888_1X24,
+ MEDIA_BUS_FMT_BGR888_3X8,
+ MEDIA_BUS_FMT_RGB888_1X24,
+ MEDIA_BUS_FMT_RGB888_2X12_BE,
+ MEDIA_BUS_FMT_RGB888_2X12_LE,
+ MEDIA_BUS_FMT_RGB888_3X8,
+ MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
+ MEDIA_BUS_FMT_RGB888_1X32_PADHI,
+};
+
static const struct vimc_deb_pix_map vimc_deb_pix_map_list[] = {
{
.code = MEDIA_BUS_FMT_SBGGR8_1X8,
@@ -125,6 +138,17 @@ static const struct vimc_deb_pix_map
*vimc_deb_pix_map_by_code(u32 code)
return NULL;
}
+static bool vimc_deb_src_code_is_valid(u32 code)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(vimc_deb_src_mbus_codes); i++)
+ if (vimc_deb_src_mbus_codes[i] == code)
+ return true;
+
+ return false;
+}
+
static int vimc_deb_init_cfg(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg)
{
@@ -148,14 +172,11 @@ static int vimc_deb_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code)
{
- /* We only support one format for source pads */
if (VIMC_IS_SRC(code->pad)) {
- struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
-
- if (code->index)
+ if (code->index >= ARRAY_SIZE(vimc_deb_src_mbus_codes))
return -EINVAL;
- code->code = vdeb->src_code;
+ code->code = vimc_deb_src_mbus_codes[code->index];
} else {
if (code->index >= ARRAY_SIZE(vimc_deb_pix_map_list))
return -EINVAL;
@@ -170,8 +191,6 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_frame_size_enum *fse)
{
- struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
-
if (fse->index)
return -EINVAL;
@@ -181,7 +200,7 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev *sd,
if (!vpix)
return -EINVAL;
- } else if (fse->code != vdeb->src_code) {
+ } else if (!vimc_deb_src_code_is_valid(fse->code)) {
return -EINVAL;
}
@@ -237,6 +256,7 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
{
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
struct v4l2_mbus_framefmt *sink_fmt;
+ u32 *src_code;
if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
/* Do not change the format while stream is on */
@@ -244,8 +264,10 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
return -EBUSY;
sink_fmt = &vdeb->sink_fmt;
+ src_code = &vdeb->src_code;
} else {
sink_fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+ src_code = &v4l2_subdev_get_try_format(sd, cfg, 1)->code;
}
/*
@@ -253,9 +275,14 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
* it is propagated from the sink
*/
if (VIMC_IS_SRC(fmt->pad)) {
+ u32 code = fmt->format.code;
+
fmt->format = *sink_fmt;
- /* TODO: Add support for other formats */
- fmt->format.code = vdeb->src_code;
+
+ if (vimc_deb_src_code_is_valid(code))
+ *src_code = code;
+
+ fmt->format.code = *src_code;
} else {
/* Set the new format in the sink pad */
vimc_deb_adjust_si
Re: linux-next: build failure after merge of the mac80211-next tree
On Tue, 2020-04-28 at 10:45 +0300, Sergey Matyukevich wrote: > > Looks good. But I have a couple of questions: > > - why cleanup vif->mgmt_frame_reg in wilc_mac_open ? Otherwise wilc_update_mgmt_frame_registrations() will think there are no changes whatsoever, and do nothing. > - previously wilc_wfi_p2p_rx was called only for PROBE_REQ and ACTION, > now it will be called for all the other registred frames as well Huh, good catch. How about this? https://p.sipsolutions.net/51183f5492f05ea6.txt johannes
Re: exfat upcase table for code points above U+FFFF (Was: Re: [PATCH] staging: exfat: add exfat filesystem code to staging)
On Monday 27 April 2020 11:49:13 Sasha Levin wrote: > On Tue, Apr 21, 2020 at 11:30:45PM +0200, Pali Rohár wrote: > > On Thursday 13 February 2020 16:18:47 Sasha Levin wrote: > > > On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote: > > > > In released exFAT specification is not written how are Unicode code > > > > points above U+ represented in exFAT upcase table. Normally in > > > > UTF-16 are Unicode code points above U+ represented by surrogate > > > > pairs but compression format of exFAT upcase table is not clear how to > > > > do it there. > > > > > > > > Are you able to send question about this problem to relevant MS people? > > > > > > > > New Linux implementation of exfat which is waiting on mailing list just > > > > do not support Unicode code points above U+ in exFAT upcase table. > > > > > > Sure, I'll forward this question on. I'll see if I can get someone from > > > their team who could be available to answer questions such as these in > > > the future - Microsoft is interested in maintaining compatiblity between > > > Linux and Windows exFAT implementations. > > > > Hello Sasha! Have you got any answer from exfat MS team about upcase > > table for Unicode code points above U+? > > Sorry for taking so long. This is my understanding from the Windows > folks: Windows filesystems just don't support variable encoding length, > and expect UCS-2 strings. Ok, so should I understand your answer as exFAT upcase table does not support representing Unicode code points above U+ and therefore exFAT implementation should expect that toupper(u) = u and tolower(u) = u for any Unicode code point u in range [U+1, U+10]? This is how current exfat linux driver behave.
Re: [PATCH] crypto: caam - fix use after free issue in *_crypt_done
On 4/28/2020 8:14 AM, Zhenzhong Duan wrote: > In both aead_crypt_done and skcipher_crypt_done, edesc->bklog is > referenced after the structure pointed by edesc is freed. > > Fix them by moving kfree(edesc) to the end of function call. > > Signed-off-by: Zhenzhong Duan These issues were already fixed, and applied on cryptodev, by this series: https://patchwork.kernel.org/cover/11476799/ Regards, Iulia > --- > drivers/crypto/caam/caamalg.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c > index b7bb7c30adeb..6d746ef5e650 100644 > --- a/drivers/crypto/caam/caamalg.c > +++ b/drivers/crypto/caam/caamalg.c > @@ -973,8 +973,6 @@ static void aead_crypt_done(struct device *jrdev, u32 > *desc, u32 err, > > aead_unmap(jrdev, edesc, req); > > - kfree(edesc); > - > /* >* If no backlog flag, the completion of the request is done >* by CAAM, not crypto engine. > @@ -983,6 +981,8 @@ static void aead_crypt_done(struct device *jrdev, u32 > *desc, u32 err, > aead_request_complete(req, ecode); > else > crypto_finalize_aead_request(jrp->engine, req, ecode); > + > + kfree(edesc); > } > > static void skcipher_crypt_done(struct device *jrdev, u32 *desc, u32 err, > @@ -1022,8 +1022,6 @@ static void skcipher_crypt_done(struct device *jrdev, > u32 *desc, u32 err, >DUMP_PREFIX_ADDRESS, 16, 4, req->dst, >edesc->dst_nents > 1 ? 100 : req->cryptlen, 1); > > - kfree(edesc); > - > /* >* If no backlog flag, the completion of the request is done >* by CAAM, not crypto engine. > @@ -1032,6 +1030,8 @@ static void skcipher_crypt_done(struct device *jrdev, > u32 *desc, u32 err, > skcipher_request_complete(req, ecode); > else > crypto_finalize_skcipher_request(jrp->engine, req, ecode); > + > + kfree(edesc); > } > > /* >
Re: [PATCH 2/7] signal: factor copy_siginfo_to_external32 from copy_siginfo_to_user32
On Tue, Apr 28, 2020 at 09:45:46AM +0200, Christophe Leroy wrote:
>> I guess that might be a worthwhile middle ground. Still not a fan of
>> all these ifdefs..
>>
>
> Can't we move the small X32 specific part out of
> __copy_siginfo_to_user32(), in an arch specific helper that voids for other
> architectures ?
>
> Something like:
>
> if (!arch_special_something(&new, from)) {
> new.si_utime = from->si_utime;
> new.si_stime = from->si_stime;
> }
>
> Then the arch_special_something() does what it wants in x86 and returns 1,
> and for architectures not implementating it, a generic version return 0 all
> the time.
The main issue is that we need an explicit paramter to select x32,
as it can't just be discovered from the calling context otherwise.
The rest is just sugarcoating.
Re: [PATCH] nvme: prevent double free in nvme_alloc_ns() error handling
On Tue, Apr 28, 2020 at 09:06:51AM +0200, Javier González wrote:
> CAUTION: This email originated from outside of Western Digital. Do not click
> on links or open attachments unless you recognize the sender and know that
> the content is safe.
>
>
> On 27.04.2020 18:22, Niklas Cassel wrote:
> > On Mon, Apr 27, 2020 at 08:03:11PM +0200, Javier González wrote:
> > > On 27.04.2020 14:34, Niklas Cassel wrote:
> > > > When jumping to the out_put_disk label, we will call put_disk(), which
> > > > will
> > > > trigger a call to disk_release(), which calls blk_put_queue().
> > > >
> > > > Later in the cleanup code, we do blk_cleanup_queue(), which will also
> > > > call
> > > > blk_put_queue().
> > > >
> > > > Putting the queue twice is incorrect, and will generate a KASAN splat.
> > > >
> > > > Set the disk->queue pointer to NULL, before calling put_disk(), so that
> > > > the
> > > > first call to blk_put_queue() will not free the queue.
> > > >
> > > > The second call to blk_put_queue() uses another pointer to the same
> > > > queue,
> > > > so this call will still free the queue.
> > > >
> > > > Fixes: 85136c010285 ("lightnvm: simplify geometry enumeration")
> > > > Signed-off-by: Niklas Cassel
> > > > ---
> > > > drivers/nvme/host/core.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > > > index 91c1bd659947..f2adea96b04c 100644
> > > > --- a/drivers/nvme/host/core.c
> > > > +++ b/drivers/nvme/host/core.c
> > > > @@ -3642,6 +3642,8 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,
> > > > unsigned nsid)
> > > >
> > > > return;
> > > > out_put_disk:
> > > > + /* prevent double queue cleanup */
> > > > + ns->disk->queue = NULL;
> > > > put_disk(ns->disk);
> > > > out_unlink_ns:
> > > > mutex_lock(&ctrl->subsys->lock);
> > > > --
> > > > 2.25.3
> > > >
> > > What about delaying the assignment of ns->disk?
> > >
> > > diff --git i/drivers/nvme/host/core.c w/drivers/nvme/host/core.c
> > > index a4d8c90ee7cc..6da4a9ced945 100644
> > > --- i/drivers/nvme/host/core.c
> > > +++ w/drivers/nvme/host/core.c
> > > @@ -3541,7 +3541,6 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl,
> > > unsigned nsid)
> > > disk->queue = ns->queue;
> > > disk->flags = flags;
> > > memcpy(disk->disk_name, disk_name, DISK_NAME_LEN);
> > > - ns->disk = disk;
> > >
> > > __nvme_revalidate_disk(disk, id);
> > >
> > > @@ -3553,6 +3552,8 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl,
> > > unsigned nsid)
> > > }
> > > }
> > >
> > > + ns->disk = disk;
> > > +
> >
> > Hello Javier!
> >
> >
> > The only case where we jump to the out_put_disk label, is if the
> > nvme_nvm_register() call failed.
> >
> > In that case, we want to undo the alloc_disk_node() operation, i.e.,
> > decrease the refcount.
> >
> > If we don't set "ns->disk = disk;" before the call to nvme_nvm_register(),
> > then, if register fails, and we jump to the put_disk(ns->disk) label,
> > ns->disk will be NULL, so the recount will not be decreased, so I assume
> > that this memory would then be a memory leak.
> >
> >
> > I think that the problem is that the block functions are a bit messy.
> > Most drivers seem to do blk_cleanup_queue() first and then do put_disk(),
> > but some drivers do it in the opposite way, so I think that we might have
> > some more use-after-free bugs in some of these drivers that do it in the
> > opposite way.
> >
>
> Hi Niklas,
>
> Yes, the out_put_disk label was introduced at the same time as the
> LightNVM entry point. We can do a better job at separating the cleanup
> functions, but as far as I can see ns->disk is not used in the LightNVM
> initialization, so delaying the initialization should be ok. Part of
> this should be also changing the out_put_disk to put_disk(disk).
Hello Javier,
If I understand correctly, you are suggesting this:
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3616,7 +3616,6 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,
unsigned nsid)
disk->queue = ns->queue;
disk->flags = flags;
memcpy(disk->disk_name, disk_name, DISK_NAME_LEN);
- ns->disk = disk;
__nvme_revalidate_disk(disk, id);
@@ -3628,6 +3627,8 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,
unsigned nsid)
}
}
+ ns->disk = disk;
+
down_write(&ctrl->namespaces_rwsem);
list_add_tail(&ns->list, &ctrl->namespaces);
up_write(&ctrl->namespaces_rwsem);
@@ -3642,7 +3643,7 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,
unsigned nsid)
return;
out_put_disk:
- put_disk(ns->disk);
+ put_disk(disk);
out_unlink_ns:
mutex_lock(&ctrl->subsys->lock);
list_del_rcu(&ns->siblings);
That would not solve the double free error when the registration fails,
since disk->queue is still set, so this call will
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Miquel,
On 28/4/2020 3:40 pm, Miquel Raynal wrote:
Hi Vadivel MuruganX,
"Ramuthevar, Vadivel MuruganX"
wrote on Tue, 28 Apr 2020
14:50:35 +0800:
Hi Boris,
On 28/4/2020 2:47 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:40:58 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 28/4/2020 2:27 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:17:30 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Miquel,
Thank you very much for the review comments and your time...
On 27/4/2020 11:51 pm, Miquel Raynal wrote:
Hi Ramuthevar,
>>> +static int ebu_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ebu_nand_controller *ebu_host;
+ struct nand_chip *nand;
+ phys_addr_t nandaddr_pa;
+ struct mtd_info *mtd;
+ struct resource *res;
+ int ret;
+ u32 cs;
+
+ ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
+ if (!ebu_host)
+ return -ENOMEM;
+
+ ebu_host->dev = dev;
+ nand_controller_init(&ebu_host->controller);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
+ ebu_host->ebu_addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(ebu_host->ebu_addr))
+ return PTR_ERR(ebu_host->ebu_addr);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
+ ebu_host->nand_addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(ebu_host->nand_addr))
+ return PTR_ERR(ebu_host->nand_addr);
+
+ ret = device_property_read_u32(dev, "nand,cs", &cs);
CS ids should be encoded in the reg property (see [1]).
Is it your choice to only support a single CS or is it actually a
controller limitation?
Yes , its controller limitation to support only one CS
I'm pretty sure that's not true, otherwise you wouldn't have to select
the CS you want to use :P.
At a time it supports only one chip select.
Yes, like 99% of the NAND controllers, but that doesn't mean you can't
support multi-CS chips. All you have to do is attach an array of
ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I
pointed to). nand_operation.cs tells you which CS (index in your
ebu_nand_cs array) a specific operation is targeting, and you can pick
the right MMIO range/reg value based on that.
Agreed, sure I will add that and update next series of patches .
There are also many other places where you assume blindly that there
is only one CS. You can check the Atmel NAND controller driver as Boris
said and we will probably propose more little changes to be more
generic.
since LGM EBU_NAND controller supports only one chip select at a time,
so assumed like that, will change as generic way if consider like more
chip select supports, Thanks!
Sure , I will do the changes as per your review comments.
Thanks,
Miquèl
Re: [RFC 1/5] soundwire: bus_type: add sdw_master_device support
On 28-04-20, 08:55, Greg KH wrote: > On Tue, Apr 28, 2020 at 12:19:51PM +0530, Vinod Koul wrote: > > On 28-04-20, 08:37, Greg KH wrote: > > > On Tue, Apr 28, 2020 at 10:01:44AM +0530, Vinod Koul wrote: > > > > > > That is not true for everyone, it is only true for Intel, pls call > > > > > > that > > > > > > out as well... > > > > > > > > > > Why is it not true for everyone? How else do you get the pm stuff > > > > > back > > > > > to your hardware? > > > > > > > > The rest of the world would do using the real controller device. For > > > > example the soundwire controller on Qualcomm devices is enumerated as a > > > > DT device and is using these... > > > > > > > > If Intel had a standalone controller or enumerated as individual > > > > functions, it would have been a PCI device and would manage as such > > > > > > If it is not a standalone controller, what exactly is it? I thought it > > > was an acpi device, am I mistaken? > > > > > > What is the device that the proper soundwire controller driver binds to > > > on an Intel-based system? > > > > The HDA controller which is a PCI device. The device represent HDA > > function, DSP and Soundwire controller instances (yes it is typically > > more than one instance) > > Then those "instances" should be split up into individual devices that a > driver can bind to. See the work happening on the "virtual" bus for > examples of how that can be done. Yes removing platform devices is the goal for Intel now :) Pierre & Bard have been diligently trying to solve this. Only difference is the means to end goal. I am not convinced that this should be in soundwire subsystem. Looks like folks are trying to review and port to use this bus. Makes sense to me.. https://lore.kernel.org/netdev/c5197d2f-3840-d304-6b09-d334cae81...@linux.intel.com/ > A platform device better not be being used here, I'm afraid to look at > the code now... Well if the plan for 'virtual-bus' goes well, it should be a simple replacement of platform->virtual for Intel driver. Rest of the driver should not be impacted :) Thanks -- ~Vinod
Re: [PATCH] arm64: dts: allwinner: h6: Use dedicated CPU OPP table for Tanix TX6
On Sun, Apr 26, 2020 at 02:17:09PM +0200, Clément Péron wrote:
> Tanix TX6 has a fixed regulator. As DVFS is instructed to change
> voltage to meet OPP table. The DVFS is not working as expected.
>
> Introduce a dedicated OPP Table where voltage are equals to
> the fixed regulator.
>
> Reported-by: Piotr Oniszczuk
> Fixes: add1e27fb703 ("arm64: dts: allwinner: h6: Enable CPU opp tables for
> Tanix TX6")
> Signed-off-by: Clément Péron
I'm not really a big fan of duplicating the OPPs, since that would make an
update of those very likely to be overlooked for that particular board (and
since it's a board that not a lot of people have, it would be harder to notice
too).
IIRC, removing the cpu-supply property should work as well?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH] arm: remove unneeded semicolon in board-artpec6.c
On Tue, Apr 28, 2020 at 08:32:13AM +0200, Jason Yan wrote: > Fix the following coccicheck warning: > > arch/arm/mach-artpec/board-artpec6.c:42:2-3: Unneeded semicolon Acked-by: Jesper Nilsson > Signed-off-by: Jason Yan > --- > arch/arm/mach-artpec/board-artpec6.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-artpec/board-artpec6.c > b/arch/arm/mach-artpec/board-artpec6.c > index d3cf3e8603e8..c27e7bbcd7bc 100644 > --- a/arch/arm/mach-artpec/board-artpec6.c > +++ b/arch/arm/mach-artpec/board-artpec6.c > @@ -39,7 +39,7 @@ static void __init artpec6_init_machine(void) >*/ > regmap_write(regmap, ARTPEC6_DMACFG_REGNUM, >ARTPEC6_DMACFG_UARTS_BURST); > - }; > + } > } > > static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg) > -- > 2.21.1 > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] scripts: gtags_files_generator.sh
On Sun, Apr 26, 2020 at 11:48 AM xujialu wrote:
>
> Add a script to generate a more precise gtags.files from *.cmd files.
>
> For navigating linux sources, it will be more efficient if gtags/cscope
> just collects source files that needed for compilation. The kernel
> makefiles already create *.cmd files that contain the files we needed,
> then just extracts files list from them and into gtags.files cause it's
> the the default name list file for gtags.
This is unneeded.
scripts/tags.sh supports COMPILED_SOURCE=1
to collect tags only from compiled sources.
Please do not reinvent the wheel
to achieve similar things.
$ time make COMPILED_SOURCE=1 gtags
GEN gtags
real 0m7.623s
user 0m7.459s
sys 0m1.124s
is fine for me.
If the existing code is problematic,
we need to improve it,
not add the second one.
>
> make defconfig
> make
> scripts/gtags_files_generator.sh
> gtags [-f gtags.files]
>
> Enjoy with vim+gtags. :)
>
> Here is a log for comparison with 'make gtags':
>
> $ time make ARCH=arm cscope
> GEN cscope
>
> real1m20.600s
> user1m36.004s
> sys 0m8.192s
> $ wc -l cscope.files
> 31201 cscope.files #collected too many files we don't care
>
> $ time ./scripts/gtags_files_generator.sh
>
> Succeed, 3716 gtags.files listed!
>
> real0m1.593s#collected files only we care
> user0m1.704s
> sys 0m0.256s
> #collected also dts and dtsi
Why do you need to collect dts and dtsi?
> $ grep dts gtags.files
> arch/arm/boot/dts/xx-clocks.dtsi
> arch/arm/boot/dts/xx.dtsi
> arch/arm/boot/dts/.dts
> arch/arm/boot/dts/.dtsi
>
> Signed-off-by: xujialu
> ---
> scripts/gtags_files_generator.sh | 48
> 1 file changed, 48 insertions(+)
> create mode 100755 scripts/gtags_files_generator.sh
>
> diff --git a/scripts/gtags_files_generator.sh
> b/scripts/gtags_files_generator.sh
> new file mode 100755
> index ..04698d9234a7
> --- /dev/null
> +++ b/scripts/gtags_files_generator.sh
> @@ -0,0 +1,48 @@
> +#!/bin/bash -e
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Author: xujialu
> +#
> +# A script for generating gtags.files after compilation.
> +#
> +# Usage:
> +# make defconfig
> +# make
> +# scripts/gtags_files_generator.sh
> +# gtags [-f gtags.files]
> +
> +
> +gtags_files_list()
> +{
> + ls ${AUTOCONF_H} $(realpath -e --relative-to=. \
> + $(find ${KBUILD_OUTPUT} -name "*$1.cmd" -exec \
> + grep -Poh '(?(?=^source_.* \K).*|(?=^ \K\S).*(?= \\))' {} \+
> |
> + awk '!a[$0]++' | sed "s,^,${KBUILD_OUTPUT},") |
> + sed -e '/\.\./d' | awk '!a[$0]++'
> + )
> +}
> +
> +gtags_files_generator()
> +{
> + GTAGS_FILES=$PWD/gtags.files
> +
> + echo && [ $# = 1 ] && cd $1
> +
> + SYSTEM_MAP=$(find -name System.map -print -quit)
> +
> + [ -z "${SYSTEM_MAP}" ] && echo "Failed, please compile first!" &&
> exit 1
> +
> + KBUILD_OUTPUT=${SYSTEM_MAP%/*}/
> + KBUILD_OUTPUT=${KBUILD_OUTPUT#*/}
> +
> + AUTOCONF_H=${KBUILD_OUTPUT}include/generated/autoconf.h
> +
> + grep Configuration ${AUTOCONF_H} | sed 's/ \* //'
> + gtags_files_list > ${GTAGS_FILES}
> +
> + echo && [ $# = 1 ] && sed -i "s|^|$1|" ${GTAGS_FILES}
> +
> + echo "Succeed, $(wc -l ${GTAGS_FILES}) listed!"
> +}
> +
> +gtags_files_generator $1 2>/dev/null
> --
> 2.20.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/6] iio: chemical: scd30: add core driver
On Sat, Apr 25, 2020 at 07:55:34PM +0100, Jonathan Cameron wrote:
> On Wed, 22 Apr 2020 16:11:30 +0200
> Tomasz Duszynski wrote:
>
> > Add Sensirion SCD30 carbon dioxide core driver.
> >
> > Signed-off-by: Tomasz Duszynski
> Hi Tomasz
>
> As you've probably guessed the big questions are around the custom ABI.
>
> Few other things inline.
>
> Jonathan
>
> > ---
> > drivers/iio/chemical/Kconfig | 11 +
> > drivers/iio/chemical/Makefile | 1 +
> > drivers/iio/chemical/scd30.h | 72 +++
> > drivers/iio/chemical/scd30_core.c | 796 ++
> > 4 files changed, 880 insertions(+)
> > create mode 100644 drivers/iio/chemical/scd30.h
> > create mode 100644 drivers/iio/chemical/scd30_core.c
> >
> > diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> > index 0b91de4df8f4..55f249333fa2 100644
> > --- a/drivers/iio/chemical/Kconfig
> > +++ b/drivers/iio/chemical/Kconfig
> > @@ -74,6 +74,17 @@ config PMS7003
> > To compile this driver as a module, choose M here: the module will
> > be called pms7003.
> >
> > +config SCD30_CORE
> > + tristate "SCD30 carbon dioxide sensor driver"
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > + help
> > + Say Y here to build support for the Sensirion SCD30 sensor with carbon
> > + dioxide, relative humidity and temperature sensing capabilities.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called scd30_core.
> > +
> > config SENSIRION_SGP30
> > tristate "Sensirion SGPxx gas sensors"
> > depends on I2C
> > diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> > index 33d3a595dda9..54abcb641262 100644
> > --- a/drivers/iio/chemical/Makefile
> > +++ b/drivers/iio/chemical/Makefile
> > @@ -11,6 +11,7 @@ obj-$(CONFIG_BME680_SPI) += bme680_spi.o
> > obj-$(CONFIG_CCS811) += ccs811.o
> > obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
> > obj-$(CONFIG_PMS7003) += pms7003.o
> > +obj-$(CONFIG_SCD30_CORE) += scd30_core.o
> > obj-$(CONFIG_SENSIRION_SGP30) += sgp30.o
> > obj-$(CONFIG_SPS30) += sps30.o
> > obj-$(CONFIG_VZ89X)+= vz89x.o
> > diff --git a/drivers/iio/chemical/scd30.h b/drivers/iio/chemical/scd30.h
> > new file mode 100644
> > index ..814782f5e71a
> > --- /dev/null
> > +++ b/drivers/iio/chemical/scd30.h
> > @@ -0,0 +1,72 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _SCD30_H
> > +#define _SCD30_H
> > +
> > +#include
> > +#include
> > +#include
>
> Doesn't make much sense to have an i2c header included here.
>
Will drop.
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +enum scd30_cmd {
> > + /* start continuous measurement with pressure compensation */
> > + CMD_START_MEAS,
> > + /* stop continuous measurement */
> > + CMD_STOP_MEAS,
> > + /* set/get measurement interval */
> > + CMD_MEAS_INTERVAL,
> > + /* check whether new measurement is ready */
> > + CMD_MEAS_READY,
> > + /* get measurement */
> > + CMD_READ_MEAS,
> > + /* turn on/off automatic self calibration */
> > + CMD_ASC,
> > + /* set/get forced recalibration value */
> > + CMD_FRC,
> > + /* set/get temperature offset */
> > + CMD_TEMP_OFFSET,
> > + /* get firmware version */
> > + CMD_FW_VERSION,
> > + /* reset sensor */
> > + CMD_RESET,
> > + /*
> > +* Command for altitude compensation was omitted intentionally because
> > +* the same can be achieved by means of CMD_START_MEAS which takes
> > +* pressure above the sea level as an argument.
> > +*/
> > +};
> > +
> > +#define SCD30_MEAS_COUNT 3
> > +
> > +struct scd30_state {
> > + /* serialize access to the device */
> > + struct mutex lock;
> > + struct device *dev;
> > + struct regulator *vdd;
> > + struct completion meas_ready;
> > + void *priv;
> > + int irq;
> > + /*
> > +* no way to retrieve current ambient pressure compensation value from
> > +* the sensor so keep one around
> > +*/
> > + u16 pressure_comp;
> > + u16 meas_interval;
> > + int meas[SCD30_MEAS_COUNT];
> > +
> > + int (*command)(struct scd30_state *state, enum scd30_cmd cmd, u16 arg,
> > + char *rsp, int size);
> > +};
> > +
> > +int scd30_suspend(struct device *dev);
> > +int scd30_resume(struct device *dev);
> > +
> > +static SIMPLE_DEV_PM_OPS(scd30_pm_ops, scd30_suspend, scd30_resume);
> > +
> > +int scd30_probe(struct device *dev, int irq, const char *name, void *priv,
> > + int (*command)(struct scd30_state *state, enum scd30_cmd cmd,
> > + u16 arg, char *rsp, int size));
> > +
> > +#endif
> > diff --git a/drivers/iio/chemical/scd30_core.c
> > b/drivers/iio/chemical/scd30_core.c
> > new file mode 100644
> > index ..4dc7e8f9a4f1
> > --- /dev/null
> > +++ b/drivers/iio/chemical/scd30_core.c
> > @@ -0,0 +1,796 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> >
[PATCH] net: Protect INET_ADDR_COOKIE on 32-bit architectures
Commit c7228317441f ("net: Use a more standard macro for
INET_ADDR_COOKIE") added a __deprecated marker to the cookie name on
32-bit architectures, with the intent that the compiler would flag
uses of the name. However since commit 771c035372a0 ("deprecate the
'__deprecated' attribute warnings entirely and for good"),
__deprecated doesn't do anything and should be avoided.
This patch changes INET_ADDR_COOKIE to declare a dummy typedef (so it
makes checkpatch.pl complain, sorry...) so that any subsequent use of
the cookie's name will in all likelihood break the build. It also
removes the __deprecated marker.
Signed-off-by: Stephen Kitt
---
include/net/inet_hashtables.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index ad64ba6a057f..8a1391d82406 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -301,8 +301,9 @@ static inline struct sock *inet_lookup_listener(struct net
*net,
((__sk)->sk_bound_dev_if == (__sdif)))&& \
net_eq(sock_net(__sk), (__net)))
#else /* 32-bit arch */
+/* Break the build if anything tries to use the cookie's name. */
#define INET_ADDR_COOKIE(__name, __saddr, __daddr) \
- const int __name __deprecated __attribute__((unused))
+ typedef void __name __attribute__((unused))
#define INET_MATCH(__sk, __net, __cookie, __saddr, __daddr, __ports, __dif,
__sdif) \
(((__sk)->sk_portpair == (__ports)) && \
--
2.20.1
Re: [PATCH] pwm: sun4i: direct clock output support for Allwinner A64
Hi,
On Sun, Apr 26, 2020 at 12:11:22PM +0200, Peter Vasil wrote:
> Allwinner A64 is capable of a direct clock output on PWM (see A64
> User Manual chapter 3.10). Add support for this in the sun4i PWM
> driver and adjust compatibility in sun50i-a64 base device tree.
>
> Signed-off-by: Peter Vasil
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++
> drivers/pwm/pwm-sun4i.c | 9 +
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 31143fe64d91..c334fd106854 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -1069,8 +1069,7 @@ gic: interrupt-controller@1c81000 {
> };
>
> pwm: pwm@1c21400 {
> - compatible = "allwinner,sun50i-a64-pwm",
> - "allwinner,sun5i-a13-pwm";
> + compatible = "allwinner,sun50i-a64-pwm";
> reg = <0x01c21400 0x400>;
> clocks = <&osc24M>;
> pinctrl-names = "default";
> @@ -1252,8 +1251,7 @@ r_ir: ir@1f02000 {
> };
>
> r_pwm: pwm@1f03800 {
> - compatible = "allwinner,sun50i-a64-pwm",
> - "allwinner,sun5i-a13-pwm";
> + compatible = "allwinner,sun50i-a64-pwm";
There's no need to remove that compatible, it's actually working as intended..
> reg = <0x01f03800 0x400>;
> clocks = <&osc24M>;
> pinctrl-names = "default";
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 5c677c563349..18fbbe3277d0 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -352,6 +352,12 @@ static const struct sun4i_pwm_data
> sun4i_pwm_single_bypass = {
> .npwm = 1,
> };
>
> +static const struct sun4i_pwm_data sun50i_a64_pwm_data = {
> + .has_prescaler_bypass = true,
> + .has_direct_mod_clk_output = true,
> + .npwm = 1,
> +};
> +
> static const struct sun4i_pwm_data sun50i_h6_pwm_data = {
> .has_prescaler_bypass = true,
> .has_direct_mod_clk_output = true,
> @@ -374,6 +380,9 @@ static const struct of_device_id sun4i_pwm_dt_ids[] = {
> }, {
> .compatible = "allwinner,sun8i-h3-pwm",
> .data = &sun4i_pwm_single_bypass,
> + }, {
> + .compatible = "allwinner,sun50i-a64-pwm",
> + .data = &sun50i_a64_pwm_data,
Ie, if the OS only has support for the A13, then it will use it as an A13, and
if it has support for the A64 variant, then it can use some more advanced
features.
Maxime
signature.asc
Description: PGP signature
[PATCH net-next v3 0/2] provide support for PHY master/slave configuration
changes v3: - provide separate field for config and state. - make state rejected on set - add validation changes v2: - change names. Use MASTER_PREFERRED instead of MULTIPORT - configure master/slave only on request. Default configuration can be provided by PHY or eeprom - status and configuration to the user space. Oleksij Rempel (2): ethtool: provide UAPI for PHY master/slave configuration. net: phy: tja11xx: add support for master-slave configuration Documentation/networking/ethtool-netlink.rst | 3 + drivers/net/phy/nxp-tja11xx.c| 58 - drivers/net/phy/phy.c| 7 +- drivers/net/phy/phy_device.c | 89 include/linux/phy.h | 3 + include/uapi/linux/ethtool.h | 29 ++- include/uapi/linux/ethtool_netlink.h | 2 + include/uapi/linux/mii.h | 2 + net/ethtool/linkmodes.c | 15 +++- 9 files changed, 204 insertions(+), 4 deletions(-) -- 2.26.2
[PATCH net-next v3 2/2] net: phy: tja11xx: add support for master-slave configuration
The TJA11xx PHYs have a vendor specific Master/Slave configuration bit,
which is not compatible with IEEE 803.2-2018 spec for 100Base-T1
devices. So, provide a custom config_ange call back to solve this
problem.
Signed-off-by: Oleksij Rempel
---
drivers/net/phy/nxp-tja11xx.c | 58 ++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/nxp-tja11xx.c b/drivers/net/phy/nxp-tja11xx.c
index cc766b2d4136e..c316d22ea7530 100644
--- a/drivers/net/phy/nxp-tja11xx.c
+++ b/drivers/net/phy/nxp-tja11xx.c
@@ -30,6 +30,7 @@
#define MII_ECTRL_WAKE_REQUEST BIT(0)
#define MII_CFG1 18
+#define MII_CFG1_MASTER_SLAVE BIT(15)
#define MII_CFG1_AUTO_OP BIT(14)
#define MII_CFG1_SLEEP_CONFIRM BIT(6)
#define MII_CFG1_LED_MODE_MASK GENMASK(5, 4)
@@ -167,6 +168,33 @@ static int tja11xx_soft_reset(struct phy_device *phydev)
return genphy_soft_reset(phydev);
}
+static int tja11xx_config_aneg(struct phy_device *phydev)
+{
+ u16 ctl = 0;
+ int ret;
+
+ switch (phydev->master_slave_set) {
+ case PORT_MODE_CFG_MASTER_FORCE:
+ case PORT_MODE_CFG_MASTER_PREFERRED:
+ ctl |= MII_CFG1_MASTER_SLAVE;
+ break;
+ case PORT_MODE_CFG_SLAVE_FORCE:
+ case PORT_MODE_CFG_SLAVE_PREFERRED:
+ break;
+ case PORT_MODE_CFG_UNKNOWN:
+ return 0;
+ default:
+ phydev_warn(phydev, "Unsupported Master/Slave mode\n");
+ return -ENOTSUPP;
+ }
+
+ ret = phy_modify_changed(phydev, MII_CFG1, MII_CFG1_MASTER_SLAVE, ctl);
+ if (ret < 0)
+ return ret;
+
+ return __genphy_config_aneg(phydev, ret);
+}
+
static int tja11xx_config_init(struct phy_device *phydev)
{
int ret;
@@ -222,12 +250,24 @@ static int tja11xx_config_init(struct phy_device *phydev)
static int tja11xx_read_status(struct phy_device *phydev)
{
- int ret;
+ int cfg, state = 0;
+ int ret, cfg1;
+
+ phydev->master_slave_get = 0;
ret = genphy_update_link(phydev);
if (ret)
return ret;
+ cfg1 = phy_read(phydev, MII_CFG1);
+ if (cfg1 < 0)
+ return cfg1;
+
+ if (cfg1 & MII_CFG1_MASTER_SLAVE)
+ cfg = PORT_MODE_CFG_MASTER_FORCE;
+ else
+ cfg = PORT_MODE_CFG_SLAVE_FORCE;
+
if (phydev->link) {
ret = phy_read(phydev, MII_COMMSTAT);
if (ret < 0)
@@ -235,8 +275,20 @@ static int tja11xx_read_status(struct phy_device *phydev)
if (!(ret & MII_COMMSTAT_LINK_UP))
phydev->link = 0;
+
+ ret = phy_read(phydev, MII_CFG1);
+ if (ret < 0)
+ return ret;
+
+ if (cfg1 & MII_CFG1_MASTER_SLAVE)
+ state = PORT_MODE_STATE_MASTER;
+ else
+ state = PORT_MODE_STATE_SLAVE;
}
+ phydev->master_slave_get = cfg;
+ phydev->master_slave_state = state;
+
return 0;
}
@@ -504,6 +556,7 @@ static struct phy_driver tja11xx_driver[] = {
.features = PHY_BASIC_T1_FEATURES,
.probe = tja11xx_probe,
.soft_reset = tja11xx_soft_reset,
+ .config_aneg= tja11xx_config_aneg,
.config_init= tja11xx_config_init,
.read_status= tja11xx_read_status,
.suspend= genphy_suspend,
@@ -519,6 +572,7 @@ static struct phy_driver tja11xx_driver[] = {
.features = PHY_BASIC_T1_FEATURES,
.probe = tja11xx_probe,
.soft_reset = tja11xx_soft_reset,
+ .config_aneg= tja11xx_config_aneg,
.config_init= tja11xx_config_init,
.read_status= tja11xx_read_status,
.suspend= genphy_suspend,
@@ -533,6 +587,7 @@ static struct phy_driver tja11xx_driver[] = {
.features = PHY_BASIC_T1_FEATURES,
.probe = tja1102_p0_probe,
.soft_reset = tja11xx_soft_reset,
+ .config_aneg= tja11xx_config_aneg,
.config_init= tja11xx_config_init,
.read_status= tja11xx_read_status,
.match_phy_device = tja1102_p0_match_phy_device,
@@ -551,6 +606,7 @@ static struct phy_driver tja11xx_driver[] = {
.features = PHY_BASIC_T1_FEATURES,
/* currently no probe for Port 1 is need */
.soft_reset = tja11xx_soft_reset,
+ .config_aneg= tja11xx_config_aneg,
.config_init= tja11xx_config_init,
.read_status= tja11xx_read_status,
.match_phy_device = tja1102_p1_match_phy_device,
--
2.26.2
[PATCH net-next v3 1/2] ethtool: provide UAPI for PHY master/slave configuration.
This UAPI is needed for BroadR-Reach 100BASE-T1 devices. Due to lack of auto-negotiation support, we needed to be able to configure the MASTER-SLAVE role of the port manually or from an application in user space. The same UAPI can be used for 1000BASE-T or MultiGBASE-T devices to force MASTER or SLAVE role. See IEEE 802.3-2018: 22.2.4.3.7 MASTER-SLAVE control register (Register 9) 22.2.4.3.8 MASTER-SLAVE status register (Register 10) 40.5.2 MASTER-SLAVE configuration resolution 45.2.1.185.1 MASTER-SLAVE config value (1.2100.14) 45.2.7.10 MultiGBASE-T AN control 1 register (Register 7.32) The MASTER-SLAVE role affects the clock configuration: --- When the PHY is configured as MASTER, the PMA Transmit function shall source TX_TCLK from a local clock source. When configured as SLAVE, the PMA Transmit function shall source TX_TCLK from the clock recovered from data stream provided by MASTER. iMX6Q KSZ9031XXX --\/---\/\ || ||| MAC || PHY Slave |<-->| PHY Master | |<--- 125 MHz ---+-<--/ || \ | --/\---/\/ ^ \-TX_TCLK --- Since some clock or link related issues are only reproducible in a specific MASTER-SLAVE-role, MAC and PHY configuration, it is beneficial to provide generic (not 100BASE-T1 specific) interface to the user space for configuration flexibility and trouble shooting. Signed-off-by: Oleksij Rempel --- Documentation/networking/ethtool-netlink.rst | 3 + drivers/net/phy/phy.c| 7 +- drivers/net/phy/phy_device.c | 89 include/linux/phy.h | 3 + include/uapi/linux/ethtool.h | 29 ++- include/uapi/linux/ethtool_netlink.h | 2 + include/uapi/linux/mii.h | 2 + net/ethtool/linkmodes.c | 15 +++- 8 files changed, 147 insertions(+), 3 deletions(-) diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 567326491f80b..c32b109ebe1b3 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -399,6 +399,8 @@ Kernel response contents: ``ETHTOOL_A_LINKMODES_PEER`` bitset partner link modes ``ETHTOOL_A_LINKMODES_SPEED`` u32 link speed (Mb/s) ``ETHTOOL_A_LINKMODES_DUPLEX``u8 duplex mode + ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG`` u8 Master/slave port mode + ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_STATE`` u8 Master/slave port mode == == For ``ETHTOOL_A_LINKMODES_OURS``, value represents advertised modes and mask @@ -421,6 +423,7 @@ Request contents: ``ETHTOOL_A_LINKMODES_PEER`` bitset partner link modes ``ETHTOOL_A_LINKMODES_SPEED`` u32 link speed (Mb/s) ``ETHTOOL_A_LINKMODES_DUPLEX``u8 duplex mode + ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG`` u8 Master/slave port mode == == ``ETHTOOL_A_LINKMODES_OURS`` bit set allows setting advertised link modes. If diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 72c69a9c8a98a..a6a774beb2f90 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -285,6 +285,9 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev, duplex != DUPLEX_FULL))) return -EINVAL; + if (!ethtool_validate_master_slave_cfg(cmd->base.master_slave_cfg)) + return -EINVAL; + phydev->autoneg = autoneg; phydev->speed = speed; @@ -295,7 +298,7 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev, phydev->advertising, autoneg == AUTONEG_ENABLE); phydev->duplex = duplex; - + phydev->master_slave_set = cmd->base.master_slave_cfg; phydev->mdix_ctrl = cmd->base.eth_tp_mdix_ctrl; /* Restart the PHY */ @@ -314,6 +317,8 @@ void phy_ethtool_ksettings_get(struct phy_device *phydev, cmd->base.speed = phydev->speed; cmd->base.duplex = phydev->duplex; + cmd->base.master_slave_cfg = phydev->master_slave_get; + cmd->base.master_slave_state = phydev->master_slave_state; if (phydev->interface == PHY_INTERFACE_MODE_MOCA) cmd->base.port = PORT_BNC; else diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index ac2784192472f..756c3642d0f8e 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/p
Re: [PATCH v7 1/3] media: dt-bindings: ov8856: Document YAML bindings
On Mon, Apr 27, 2020 at 05:13:42PM +0200, Robert Foss wrote: > On Wed, 15 Apr 2020 at 18:21, Marco Felsch wrote: > > > > On 20-04-15 11:07, Rob Herring wrote: > > > On Wed, Apr 08, 2020 at 01:08:14PM +0200, Robert Foss wrote: > > > > From: Dongchun Zhu > > > > > > > > This patch adds documentation of device tree in YAML schema for the > > > > OV8856 CMOS image sensor. > > > > > > > > Signed-off-by: Dongchun Zhu > > > > Signed-off-by: Robert Foss > > > > --- > > > > > > > > - Changes since v6: > > > > * Marco: remove qcom specifics from DT example > > > > > > > > - Changes since v5: > > > > * Add assigned-clocks and assigned-clock-rates > > > > * robher: dt-schema errors > > > > > > > > - Changes since v4: > > > > * Fabio: Change reset-gpio to GPIO_ACTIVE_LOW, explain in description > > > > * Add clock-lanes property to example > > > > * robher: Fix syntax error in devicetree example > > > > > > > > - Changes since v3: > > > > * robher: Fix syntax error > > > > * robher: Removed maxItems > > > > * Fixes yaml 'make dt-binding-check' errors > > > > > > > > - Changes since v2: > > > > Fixes comments from from Andy, Tomasz, Sakari, Rob. > > > > * Convert text documentation to YAML schema. > > > > > > > > - Changes since v1: > > > > Fixes comments from Sakari, Tomasz > > > > * Add clock-frequency and link-frequencies in DT > > > > > > > > .../devicetree/bindings/media/i2c/ov8856.yaml | 143 ++ > > > > MAINTAINERS | 1 + > > > > 2 files changed, 144 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > > b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > > new file mode 100644 > > > > index ..96bef5403d7e > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml > > > > @@ -0,0 +1,143 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > > +# Copyright (c) 2019 MediaTek Inc. > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/media/i2c/ov8856.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Omnivision OV8856 CMOS Sensor Device Tree Bindings > > > > + > > > > +maintainers: > > > > + - Ben Kao > > > > + - Dongchun Zhu > > > > + > > > > +description: |- > > > > + The Omnivision OV8856 is a high performance, 1/4-inch, 8 megapixel, > > > > CMOS > > > > + image sensor that delivers 3264x2448 at 30fps. It provides > > > > full-frame, > > > > + sub-sampled, and windowed 10-bit MIPI images in various formats via > > > > the > > > > + Serial Camera Control Bus (SCCB) interface. This chip is programmable > > > > + through I2C and two-wire SCCB. The sensor output is available via > > > > CSI-2 > > > > + serial data output (up to 4-lane). > > > > + > > > > +properties: > > > > + compatible: > > > > +const: ovti,ov8856 > > > > + > > > > + reg: > > > > +maxItems: 1 > > > > + > > > > + clocks: > > > > +maxItems: 1 > > > > + > > > > + clock-names: > > > > +description: > > > > + Input clock for the sensor. > > > > +items: > > > > + - const: xvclk > > > > + > > > > + assigned-clocks: > > > > +description: > > > > + Input clock for the sensor. > > > > + > > > > + assigned-clock-rates: > > > > +description: > > > > + Frequency of the xvclk clock in Hertz. > > > > > > These 2 should have a 'maxItems: 1' > > > > Don't know why those properties are needed here.. IMHO this shouldn't be > > part of the binding or at least it should be optional and not required. > > All we need is the clocks and the clock-names property. > > Thanks Marco, I'll make it optional for the next revision. Well, the whole discussion we had was about removing them entirely? Maxime signature.asc Description: PGP signature
Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)
On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > I have a somewhat serious question: should we use IST for #VC at all? > As I understand it, Rome and Naples make it mandatory for hypervisors > to intercept #DB, which means that, due to the MOV SS mess, it's sort > of mandatory to use IST for #VC. But Milan fixes the #DB issue, so, > if we're running under a sufficiently sensible hypervisor, we don't > need IST for #VC. The reason for #VC being IST is not only #DB, but also SEV-SNP. SNP adds page ownership tracking between guest and host, so that the hypervisor can't remap guest pages without the guest noticing. If there is a violation of ownership, which can happen at any memory access, there will be a #VC exception to notify the guest. And as this can happen anywhere, for example on a carefully crafted stack page set by userspace before doing SYSCALL, the only robust choice for #VC is to use IST. Regards, Joerg
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hello,
"Ramuthevar, Vadivel MuruganX"
wrote on Tue, 28 Apr 2020
15:50:06 +0800:
> Hi Miquel,
>
> On 28/4/2020 3:40 pm, Miquel Raynal wrote:
> > Hi Vadivel MuruganX,
> >
> > "Ramuthevar, Vadivel MuruganX"
> > wrote on Tue, 28 Apr 2020
> > 14:50:35 +0800:
> >
> >> Hi Boris,
> >>
> >> On 28/4/2020 2:47 pm, Boris Brezillon wrote:
> >>> On Tue, 28 Apr 2020 14:40:58 +0800
> >>> "Ramuthevar, Vadivel MuruganX"
> >>> wrote:
> >>> Hi Boris,
>
> On 28/4/2020 2:27 pm, Boris Brezillon wrote:
> > On Tue, 28 Apr 2020 14:17:30 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > wrote:
> > Hi Miquel,
> >>
> >>Thank you very much for the review comments and your time...
> >>
> >> On 27/4/2020 11:51 pm, Miquel Raynal wrote:
> >>> Hi Ramuthevar,
> >>>>>> +static int ebu_nand_probe(struct platform_device
> >>> *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct ebu_nand_controller *ebu_host;
> > + struct nand_chip *nand;
> > + phys_addr_t nandaddr_pa;
> > + struct mtd_info *mtd;
> > + struct resource *res;
> > + int ret;
> > + u32 cs;
> > +
> > + ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
> > + if (!ebu_host)
> > + return -ENOMEM;
> > +
> > + ebu_host->dev = dev;
> > + nand_controller_init(&ebu_host->controller);
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "ebunand");
> > + ebu_host->ebu_addr = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(ebu_host->ebu_addr))
> > + return PTR_ERR(ebu_host->ebu_addr);
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "hsnand");
> > + ebu_host->nand_addr = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(ebu_host->nand_addr))
> > + return PTR_ERR(ebu_host->nand_addr);
> > +
> > + ret = device_property_read_u32(dev, "nand,cs", &cs);
>
> CS ids should be encoded in the reg property (see [1]).
> >>>
> >>> Is it your choice to only support a single CS or is it actually a
> >>> controller limitation?
> >>
> >> Yes , its controller limitation to support only one CS
> >
> > I'm pretty sure that's not true, otherwise you wouldn't have to select
> > the CS you want to use :P.
>
> At a time it supports only one chip select.
> >>>
> >>> Yes, like 99% of the NAND controllers, but that doesn't mean you can't
> >>> support multi-CS chips. All you have to do is attach an array of
> >>> ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I
> >>> pointed to). nand_operation.cs tells you which CS (index in your
> >>> ebu_nand_cs array) a specific operation is targeting, and you can pick
> >>> the right MMIO range/reg value based on that.
> >>
> >> Agreed, sure I will add that and update next series of patches .
> >
> > There are also many other places where you assume blindly that there
> > is only one CS. You can check the Atmel NAND controller driver as Boris
> > said and we will probably propose more little changes to be more
> > generic.
> since LGM EBU_NAND controller supports only one chip select at a time, so
> assumed like that, will change as generic way if consider like more chip
> select supports, Thanks!
What do you mean "at a time"?
Do we have access to the spec or a register map? We could tell you very
quickly if it is worth the trouble. But I am pretty sure as well that
the controller supports more than 1 CS.
> Sure , I will do the changes as per your review comments.
> >
> > Thanks,
> > Miquèl
> >
Thanks,
Miquèl
Re: [PATCH 0/1] Fiji GPU audio register timeout when in BACO state
On Mon, 27 Apr 2020 20:43:54 +0200,
Alex Deucher wrote:
>
> On Mon, Apr 27, 2020 at 2:39 PM Takashi Iwai wrote:
> >
> > On Mon, 27 Apr 2020 20:28:12 +0200,
> > Alex Deucher wrote:
> > >
> > > On Mon, Apr 27, 2020 at 2:07 PM Nicholas Johnson
> > > wrote:
> > > >
> > > > On Mon, Apr 27, 2020 at 05:15:55PM +0200, Takashi Iwai wrote:
> > > > > On Mon, 27 Apr 2020 16:22:21 +0200,
> > > > > Deucher, Alexander wrote:
> > > > > >
> > > > > > [AMD Public Use]
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Nicholas Johnson
> > > > > > >
> > > > > > > Sent: Sunday, April 26, 2020 12:02 PM
> > > > > > > To: linux-kernel@vger.kernel.org
> > > > > > > Cc: Deucher, Alexander ; Koenig,
> > > > > > > Christian
> > > > > > > ; Zhou, David(ChunMing)
> > > > > > > ; Nicholas Johnson > > > > > > opensou...@outlook.com.au>
> > > > > > > Subject: [PATCH 0/1] Fiji GPU audio register timeout when in BACO
> > > > > > > state
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Since Linux v5.7-rc1 / commit 4fdda2e66de0 ("drm/amdgpu/runpm:
> > > > > > > enable
> > > > > > > runpm on baco capable VI+ asics"), my AMD R9 Nano has been using
> > > > > > > runpm /
> > > > > > > BACO. You can tell visually when it sleeps, because the fan on
> > > > > > > the graphics
> > > > > > > card is switched off to save power. It did not spin down the fan
> > > > > > > in v5.6.x.
> > > > > > >
> > > > > > > This is great (I love it), except that when it is sleeping, the
> > > > > > > PCIe audio function
> > > > > > > of the GPU has issues if anything tries to access it. You get
> > > > > > > dmesg errors such
> > > > > > > as these:
> > > > > > >
> > > > > > > snd_hda_intel :08:00.1: spurious response 0x0:0x0, last
> > > > > > > cmd=0x170500
> > > > > > > snd_hda_intel :08:00.1: azx_get_response timeout, switching
> > > > > > > to polling
> > > > > > > mode: last cmd=0x001f0500 snd_hda_intel :08:00.1: No response
> > > > > > > from
> > > > > > > codec, disabling MSI: last cmd=0x001f0500 snd_hda_intel
> > > > > > > :08:00.1: No
> > > > > > > response from codec, resetting bus: last cmd=0x001f0500
> > > > > > > snd_hda_codec_hdmi hdaudioC1D0: Unable to sync register 0x2f0d00.
> > > > > > > -11
> > > > > > >
> > > > > > > The above is with the Fiji XT GPU at :08:00.0 in a
> > > > > > > Thunderbolt enclosure
> > > > > > > (not that Thunderbolt should affect it, but I feel I should
> > > > > > > mention it just in
> > > > > > > case). I dropped a lot of duplicate dmesg lines, as some of them
> > > > > > > repeated a
> > > > > > > lot of times before the driver gave up.
> > > > > > >
> > > > > > > I offer this patch to disable runpm for Fiji while a fix is
> > > > > > > found, if you decide
> > > > > > > that is the best approach. Regardless, I will gladly test any
> > > > > > > patches you come
> > > > > > > up with instead and confirm that the above issue has been fixed.
> > > > > > >
> > > > > > > I cannot tell if any other GPUs are affected. The only other
> > > > > > > cards to which I
> > > > > > > have access are a couple of AMD R9 280X (Tahiti XT), which use
> > > > > > > radeon driver
> > > > > > > instead of amdgpu driver.
> > > > > >
> > > > > > Adding a few more people. Do you know what is accessing the audio?
> > > > > > The audio should have a dependency on the GPU device. The GPU
> > > > > > won't enter runtime pm until the audio has entered runtime pm and
> > > > > > vice versa on resume. Please attach a copy of your dmesg output and
> > > > > > lspci output.
> > > >
> > > > pci :08:00.1: D0 power state depends on :08:00.0
> > > > The above must be the dependency of which you speak from dmesg.
> > > >
> > > > Accessing the audio? I did not have a single method for triggering it.
> > > > Sometimes it happened on shutdown. Sometimes when restarting gdm.
> > > > Sometimes when playing with audio settings in Cinnamon Desktop. But most
> > > > often when changing displays. It might have something to do with the
> > > > audio device associated with a monitor being created when the monitor is
> > > > found. If an audio device is created, then pulseaudio might touch it.
> > > > Sorry, this is a very verbose "not quite sure".
> > > >
> > > > To trigger the bug, this time I did the following:
> > > >
> > > > 1. Boot laptop without Fiji and log in
> > > >
> > > > 2. Attach Fiji via Thunderbolt (no displays attached to Fiji) and
> > > > approve Thunderbolt device
> > > >
> > > > 3. Log in again because the session gets killed when GPU is hot-added
> > > >
> > > > 4. Wait for Fiji to fall asleep (fan stops)
> > > >
> > > > 5. Open "dmesg -w" on laptop display
> > > >
> > > > 6. Attach display to DisplayPort on Fiji (it should still stay asleep)
> > > >
> > > > 7. Do WindowsKey+P to activate external display. The error appears in
> > > > dmesg window that instant.
> > > >
> > > > Could it be a race condition when waking the card up?
> > > >
> > > > I cannot
Re: [PATCH 1/6] iio: chemical: scd30: add core driver
On Sat, Apr 25, 2020 at 09:52:25PM +0300, Andy Shevchenko wrote: > On Sat, Apr 25, 2020 at 9:42 PM Tomasz Duszynski > wrote: > > On Sat, Apr 25, 2020 at 02:43:35PM +0300, Andy Shevchenko wrote: > > > On Fri, Apr 24, 2020 at 10:05 PM Tomasz Duszynski > > > wrote: > > > > On Wed, Apr 22, 2020 at 10:49:44PM +0300, Andy Shevchenko wrote: > > > > > On Wed, Apr 22, 2020 at 5:22 PM Tomasz Duszynski > > > > > wrote: > > ... > > > > > As for ABI that's in > > > > a separate patch. > > > > > > It's not good from bisectability point of view. If by some reason this > > > patch or documentation patch gets reverted, the other one will be > > > dangling. > > > Please, unify them. > > > > > > > Huh? Reverting core and leaving leftovers would be wrong and pointless. > > Exactly my point why it should be one patch. To secure impossibility > to do pointless reverts. > But the same applies to other driver parts like i2c or serial interfaces. I don't buy it. > > -- > With Best Regards, > Andy Shevchenko
Re: [PATCH 2/7] arm: dts: sunxi: h3/h5: Add HDMI audio
Hi,
On Sun, Apr 26, 2020 at 02:04:37PM +0200, Clément Péron wrote:
> From: Marcus Cooper
>
> Add a simple-soundcard to link audio between HDMI and I2S.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Marcus Cooper
> Signed-off-by: Clément Péron
> ---
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 9be13378d4df..3a4262294950 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -105,6 +105,25 @@
> status = "disabled";
> };
>
> + hdmi_sound: hdmi-sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "allwinner,hdmi";
> + simple-audio-card,mclk-fs = <128>;
> + simple-audio-card,frame-inversion;
> + status = "disabled";
> +
> + simple-audio-card,codec {
> + sound-dai = <&hdmi>;
> + };
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s2>;
> + dai-tdm-slot-num = <2>;
> + dai-tdm-slot-width = <32>;
> + };
> + };
> +
> soc {
> compatible = "simple-bus";
> #address-cells = <1>;
> @@ -672,6 +691,7 @@
> dmas = <&dma 27>;
> resets = <&ccu RST_BUS_I2S2>;
> dma-names = "tx";
> + allwinner,playback-channels = <8>;
This property doesn't exist in the binding
Maxime
signature.asc
Description: PGP signature
Re: [mm/debug] fa6726c1e7: kernel_BUG_at_include/linux/mm.h
> On Apr 28, 2020, at 2:12 AM, Christophe Leroy wrote: > > Yes but Qian was saying: "Also, it is not very nice to introduce regressions > for robots when testing PAE because they always select CONFIG__EXPERT and > CONFIG_DEBUG_VM" > > Here we see that the said regression is not introduced because they select > CONFIG__EXPERT and CONFIG_DEBUG_VM. This is because the robots explicitely > select DEBUG_VM_PGTABLE. Right, the robot just tried to be helpful, but never figured out this was a minefield.
Re: [PATCH 4/7] arm64: dts: allwinner: a64: Add HDMI audio
On Sun, Apr 26, 2020 at 02:04:39PM +0200, Clément Péron wrote:
> From: Marcus Cooper
>
> Add a simple-soundcard to link audio between HDMI and I2S.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Marcus Cooper
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e56e1e3d4b73..08ab6b5e72a5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -102,6 +102,25 @@
> status = "disabled";
> };
>
> + hdmi_sound: hdmi-sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "allwinner,hdmi";
I'm not sure what the usual card name should be like though. I would assume that
this should be something specific enough so that you're able to differentiate
between boards / SoC so that the userspace can choose a different configuration
based on it?
If so, it's really too generic.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v7 06/12] ARM: DTS: omap4: add sgx gpu child node
Hi Paul,
> Am 26.04.2020 um 14:50 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller a
> écrit :
>> Add SGX GPU node with interrupt. Tested on PandaBoard ES.
>> Since omap4420/30/60 and omap4470 come with different SGX variants
>> we need to introduce a new omap4470.dtsi. If an omap4470 board
>> does not want to use SGX it is no problem to still include
>> omap4460.dtsi.
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> arch/arm/boot/dts/omap4.dtsi | 11 ++-
>> arch/arm/boot/dts/omap4470.dts | 15 +++
>> 2 files changed, 21 insertions(+), 5 deletions(-)
>> create mode 100644 arch/arm/boot/dts/omap4470.dts
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 763bdea8c829..15ff3d7146af 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -389,7 +389,7 @@ abb_iva: regulator-abb-iva {
>> status = "disabled";
>> };
>> -target-module@5600 {
>> +sgx_module: target-module@5600 {
>> compatible = "ti,sysc-omap4", "ti,sysc";
>> reg = <0x5600fe00 0x4>,
>><0x5600fe10 0x4>;
>> @@ -408,10 +408,11 @@ target-module@5600 {
>> #size-cells = <1>;
>> ranges = <0 0x5600 0x200>;
>> -/*
>> - * Closed source PowerVR driver, no child device
>> - * binding or driver in mainline
>> - */
>> +gpu: gpu@0 {
>> +compatible = "ti,omap4-sgx540-120",
>> "img,sgx540-120", "img,sgx540";
>> +reg = <0x0 0x200>; /* 32MB */
>> +interrupts = ;
>> +};
>> };
>> /*
>> diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
>> new file mode 100644
>> index ..f29c581300bf
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap4470.dts
^^^ there is also a missing "i" in the file name
>> @@ -0,0 +1,15 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Device Tree Source for OMAP4470 SoC
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This file is licensed under the terms of the GNU General Public License
>> + * version 2. This program is licensed "as is" without any warranty of any
>> + * kind, whether express or implied.
>> + */
>> +#include "omap4460.dtsi"
>> +
>> +&sgx {
>
> Does this even compile?
Good question.
So far there is no well known eval board in mainline that #includes this .dtsi
(because it is new) and therefore it passes any compile tests.
DTC arch/arm/boot/dts/omap4470-test.dtb - due to target missing
Error: arch/arm/boot/dts/omap4470.dtsi:13.1-5 Label or path sgx not found
I have now added a dummy board (not to be mainlined) for my own compile test...
>
> The node's handle is named sgx_module, not sgx.
Indeed. A fix is queued for v8.
BR and thanks,
Nikolaus
Re: [PATCH v2 1/2] i2c: tegra: Better handle case where CPU0 is busy for a long time
On 27/04/2020 16:18, Dmitry Osipenko wrote: > 27.04.2020 18:12, Thierry Reding пишет: >> On Mon, Apr 27, 2020 at 05:21:30PM +0300, Dmitry Osipenko wrote: >>> 27.04.2020 14:00, Thierry Reding пишет: On Mon, Apr 27, 2020 at 12:52:10PM +0300, Dmitry Osipenko wrote: > 27.04.2020 10:48, Thierry Reding пишет: > ... >>> Maybe but all these other problems appear to have existed for sometime >>> now. We need to fix all, but for the moment we need to figure out what's >>> best for v5.7. >> >> To me it doesn't sound like we have a good handle on what exactly is >> going on here and we're mostly just poking around. >> >> And even if things weren't working quite properly before, it sounds to >> me like this patch actually made things worse. > > There is a plenty of time to work on the proper fix now. To me it sounds > like you're giving up on fixing the root of the problem, sorry. We're at -rc3 now and I haven't seen any promising progress in the last week. All the while suspend/resume is now broken on at least one board and that may end up hiding any other issues that could creep in in the meantime. Furthermore we seem to have a preexisting issue that may very well interfere with this patch, so I think the cautious thing is to revert for now and then fix the original issue first. We can always come back to this once everything is back to normal. Also, people are now looking at backporting this to v5.6. Unless we revert this from v5.7 it may get picked up for backports to other kernels and then I have to notify stable kernel maintainers that they shouldn't and they have to back things out again. That's going to cause a lot of wasted time for a lot of people. So, sorry, I disagree. I don't think we have "plenty of time". >>> >>> There is about a month now before the 5.7 release. It's a bit too early >>> to start the panic, IMO :) >> >> There's no panic. A patch got merged and it broken something, so we >> revert it and try again. It's very much standard procedure. >> >>> Jon already proposed a reasonable simple solution: to keep PCIe >>> regulators always-ON. In a longer run we may want to have I2C atomic >>> transfers supported for a late suspend phase. >> >> That's not really a solution, though, is it? It's just papering over >> an issue that this patch introduced or uncovered. I'm much more in >> favour of fixing problems at the root rather than keep papering over >> until we loose track of what the actual problems are. > > It's not "papering over an issue". The bug can't be fixed properly > without introducing I2C atomic transfers support for a late suspend > phase, I don't see any other solutions for now. Stable kernels do not > support atomic transfers at all, that proper solution won't be backportable. There are a few issues here, but the issue Thierry and I are referring to is the regression introduced by this change. Yes this exposes other problems, but we first need to understand why this breaks resume in general, regardless of what the PCIe driver is doing. I will look at this a bit more later this week. Cheers Jon -- nvpublic
Re: [PATCH v2 1/2] i2c: tegra: Better handle case where CPU0 is busy for a long time
On 27/04/2020 16:38, Dmitry Osipenko wrote: > 27.04.2020 17:45, Dmitry Osipenko пишет: >> 27.04.2020 17:13, Dmitry Osipenko пишет: >>> 27.04.2020 15:46, Dmitry Osipenko пишет: 23.04.2020 13:56, Jon Hunter пишет: >>> So I think that part of the problem already existed prior to these >>> patches. Without your patches I see ... >>> >>> [ 59.543528] tegra-i2c 7000d000.i2c: i2c transfer timed out >>> [ 59.549036] vdd_sata,avdd_plle: failed to disable >>> [ 59.553778] Failed to disable avdd-plle: -110 >>> [ 59.558150] tegra-pcie 3000.pcie: failed to disable regulators: -110 >> Does this I2C timeout happen with my patches? Could you please post full >> logs of an older and the recent kernel versions? > I believe that it does, but I need to check. > Jon, could you please confirm that you're seeing those regulator-disable errors with my patch? I don't see those errors in yours original log [1]. [1] https://lore.kernel.org/lkml/1e259e22-c300-663a-e537-18d854e0f...@nvidia.com/ Again, could you please post the *full* logs? If regulator's disabling was "failing" before without my patch because of the I2C interrupt being force-disabled during of NOIRQ phase, and now regulator's disabling succeeds with my patch because IRQ is manually handled after the timeout, then this could be bad. It means that regulator was actually getting disabled, but I2C driver was timing out because interrupt couldn't be handled in NOIRQ phase, which should result in a dead PCIe on a resume from suspend since regulator's core thinks that regulator is enabled (I2C said it failed to disable), while it is actually disabled. Do you have anything plugged into the PCIe slot in yours testing farm? It wouldn't surprise me if the plugged card isn't functional after resume from suspend on a stable kernels. >>> >>> I actually now see that interrupt is not allowed to be enabled during >>> the NOIRQ phase: >>> >>> https://elixir.bootlin.com/linux/v5.7-rc3/source/kernel/irq/manage.c#L640 >>> >>> it should be worthwhile to turn it into a WARN_ON. >>> >> >> Oh, wait! There is already a warning there.. hmm. >> > > Aha, the disable depth for the I2C interrupt is 2 after > suspend_device_irq(), that's why there is no warning. > > This should catch the bug and trigger the warning: > > --- >8 --- > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c > index 453a8a0f4804..fe25104d8b22 100644 > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -653,6 +653,8 @@ void __enable_irq(struct irq_desc *desc) > break; > } > default: > + if (desc->istate & IRQS_SUSPENDED) > + goto err_out; > desc->depth--; > } > } > --- >8 --- > > Jon could you please give it a try? Will this change produce a warning > for the I2C driver on a PCIe suspend for the v5.6 kernel? Yes I can test, but I still want to know why resume is currently broken. Jon -- nvpublic
Re: [PATCH v3 1/7] ASoC: sun4i-i2s: Adjust LRCLK width
On Sun, Apr 26, 2020 at 12:41:09PM +0200, Clément Péron wrote: > From: Marcus Cooper > > Some codecs such as i2s based HDMI audio and the Pine64 DAC require > a different amount of bit clocks per frame than what is calculated > by the sample width. Use the values obtained by the tdm slot bindings > to adjust the LRCLK width accordingly. > > Signed-off-by: Marcus Cooper > Signed-off-by: Clément Péron > --- > sound/soc/sunxi/sun4i-i2s.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index d0a8d5810c0a..4198a5410bf9 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -455,6 +455,9 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s > *i2s, > return -EINVAL; > } > > + if (i2s->slot_width) > + lrck_period = i2s->slot_width; > + Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [RFC PATCH v2 1/7] block: Extand commit_rqs() to do batch processing
On Mon, Apr 27, 2020 at 11:46 PM Christoph Hellwig wrote:
>
> extand in the subject really shpuld be 'extend'
Sorry for typo, and will fix in next version.
>
> On Sun, Apr 26, 2020 at 05:38:54PM +0800, Baolin Wang wrote:
> > From: Ming Lei
> >
> > Now some SD/MMC host controllers can support packed command or packed
> > request,
> > that means we can package several requests to host controller at one time
> > to improve performence.
> >
> > But the blk-mq always takes one request from the scheduler and dispatch it
> > to
> > the device, regardless of the driver or the scheduler, so there should only
> > ever be one request in the local list in blk_mq_dispatch_rq_list(), that
> > means
> > the bd.last is always true and the driver can not use bd.last to decide if
> > there are requests are pending now in hardware queue to help to package
> > requests.
> >
> > Thus this patch introduces a new 'BLK_MQ_F_FORCE_COMMIT_RQS' flag to call
> > .commit_rqs() to do batch processing if necessary.
> >
> > Signed-off-by: Ming Lei
> > Tested-by: Baolin Wang
> > Signed-off-by: Baolin Wang
> > ---
> > block/blk-mq-sched.c | 29 -
> > block/blk-mq.c | 15 ++-
> > include/linux/blk-mq.h | 1 +
> > 3 files changed, 31 insertions(+), 14 deletions(-)
> >
> > diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> > index 74cedea56034..3429a71a7364 100644
> > --- a/block/blk-mq-sched.c
> > +++ b/block/blk-mq-sched.c
> > @@ -85,11 +85,12 @@ void blk_mq_sched_restart(struct blk_mq_hw_ctx *hctx)
> > * its queue by itself in its completion handler, so we don't need to
> > * restart queue if .get_budget() returns BLK_STS_NO_RESOURCE.
> > */
> > -static void blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
> > +static bool blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
>
> This function already returns an int in the current for-5.8/block tree.
Thanks for pointing this out, and seems I should re-modify the return
values of the functions.
>
> > + if (!(hctx->flags & BLK_MQ_F_FORCE_COMMIT_RQS)) {
> > + if (list_empty(list)) {
> > + bd.last = true;
> > + } else {
> > + nxt = list_first_entry(list, struct request,
> > +queuelist);
> > + bd.last = !blk_mq_get_driver_tag(nxt);
> > + }
> > + } else {
> > + bd.last = false;
> > }
>
> This seems a little odd in terms of code flow. Why not:
>
> if (hctx->flags & BLK_MQ_F_FORCE_COMMIT_RQS) {
> bd.last = false;
> } else if (list_empty(list)) {
> bd.last = true;
> } else {
> nxt = list_first_entry(list, struct request,
> queuelist);
> bd.last = !blk_mq_get_driver_tag(nxt);
> }
Yes, looks better.
> > diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> > index f389d7c724bd..6a20f8e8eb85 100644
> > --- a/include/linux/blk-mq.h
> > +++ b/include/linux/blk-mq.h
> > @@ -391,6 +391,7 @@ struct blk_mq_ops {
> > enum {
> > BLK_MQ_F_SHOULD_MERGE = 1 << 0,
> > BLK_MQ_F_TAG_SHARED = 1 << 1,
> > + BLK_MQ_F_FORCE_COMMIT_RQS = 1 << 3,
>
> Maybe BLK_MQ_F_ALWAYS_COMMIT might be a better name? Also this
Looks reasonable to me, and will do.
> flag (just like the existing ones..) could really use a comment
> explaining it.
OK, will add some comments. Thanks for your comments.
--
Baolin Wang
Re: [PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region
On Tue, Apr 28, 2020 at 03:33:45PM +0800, peng@nxp.com wrote:
>
> In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or
> range_straddles_page_boundary(phys, size) are true, it will
> create contiguous region. So when free, we need to free contiguous
> region use upper check condition.
>
> Signed-off-by: Peng Fan
> ---
> drivers/xen/swiotlb-xen.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b6d27762c6f8..ab96e468584f 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
> size, void *vaddr,
> /* Convert the size to actually allocated. */
> size = 1UL << (order + XEN_PAGE_SHIFT);
>
> - if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> - range_straddles_page_boundary(phys, size)) &&
> + if (((dev_addr + size - 1 > dma_mask) ||
> + range_straddles_page_boundary(phys, size)) &&
> TestClearPageXenRemapped(virt_to_page(vaddr)))
No need for the inner braces.
But more importantly please factor our a helper that can be used by
alloc and free to make sure that they always stay in sync. Something
like:
static inline bool xen_swiotlb_need_contiguous_region(struct device *dev,
phys_addr_t phys, size_t size)
{
return xen_phys_to_bus(phys) + size - 1 > dev->coherent_dma_mask ||
range_straddles_page_boundary(phys, size))
}
Re: linux-next: build failure after merge of the mac80211-next tree
> > Looks good. But I have a couple of questions: > > > > - why cleanup vif->mgmt_frame_reg in wilc_mac_open ? > > Otherwise wilc_update_mgmt_frame_registrations() will think there are no > changes whatsoever, and do nothing. > > > - previously wilc_wfi_p2p_rx was called only for PROBE_REQ and ACTION, > > now it will be called for all the other registred frames as well > > > Huh, good catch. How about this? > > https://p.sipsolutions.net/51183f5492f05ea6.txt Ok, this one looks good to me. Regards, Sergey
Re: [PATCH v3 2/7] dt-bindings: ASoC: sun4i-i2s: Add H6 compatible
On Sun, Apr 26, 2020 at 12:41:10PM +0200, Clément Péron wrote: > From: Jernej Skrabec > > H6 I2S is very similar to H3, except that it supports up to 16 channels > and thus few registers have fields on different position. > > Signed-off-by: Jernej Skrabec > Signed-off-by: Marcus Cooper > Signed-off-by: Clément Péron Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v3 1/5] kernel/sysctl: support setting sysctl parameters from kernel command line
On 4/27/20 8:33 PM, Andrew Morton wrote: On Mon, 27 Apr 2020 20:04:29 +0200 Vlastimil Babka wrote: ... + sysctl.*= [KNL] + Set a sysctl parameter, right before loading the init + process, as if the value was written to the respective + /proc/sys/... file. Both '.' and '/' are recognized as + separators. Unrecognized parameters and invalid values + are reported in the kernel log. Sysctls registered + later by a loaded module cannot be set this way. + Example: sysctl.vm.swappiness=40 Why support "."? I think only supporting "/" is perfectly adequate and simplifies documentation. It aligns the command-line syntax with the rest of the sysctl documentation. I'm not seeing the need to provide two ways of doing the same thing? AFAIK the "." is traditional, and "/" is a newer artefact of moving from the binary syscall form to procfs based form. So by "command-line syntax" you mean echo and cat, not sysctl tool? Because "man sysctl" says: variable The name of a key to read from. An example is kernel.ostype. The '/' separator is also accepted in place of a '.'. So I'm not strongly against supporting only / but I expect most people are used to the . and it will take them two attempts to pass the sysctl boot parameter correctly if they don't use it regularly - first trying . form, wonder why it doesn't work, then read the doc and realize it's not supported? Vlastimil
Re: [PATCH v3] mfd: syscon: Add Spreadtrum physical regmap bus support
On Tue, Apr 28, 2020 at 3:14 PM Lee Jones wrote: > > On Tue, 28 Apr 2020, Baolin Wang wrote: > > > On Mon, Apr 27, 2020 at 5:05 PM Lee Jones wrote: > > > > > > On Mon, 27 Apr 2020, Baolin Wang wrote: > > > > > > > Hi Arnd and Lee, > > > > > > > > On Tue, Apr 21, 2020 at 10:13 PM Baolin Wang > > > > wrote: > > > > > > > > > > Some platforms such as Spreadtrum platform, define a special method to > > > > > update bits of the registers instead of read-modify-write, which means > > > > > we should use a physical regmap bus to define the reg_update_bits() > > > > > operation instead of the MMIO regmap bus. Thus we can register a new > > > > > physical regmap bus into syscon core to support this. > > > > > > > > > > Signed-off-by: Baolin Wang > > > > > > > > Do you have any comments for this patch? Thanks. > > > > > > Yes. I'm not accepting it, sorry. > > > > > > I'd rather you duplicate the things you need from of_syscon_register() > > > in your own driver than taint this one. > > > > Thanks for your comments and I can understand your concern. But we > > still want to use the standard syscon APIs in syscon.c, which means we > > still need insert an callback or registration or other similar methods > > to support vendor specific regmap bus. Otherwise we should invent some > > similar syscon APIs in our vendor syscon driver, like > > sprd_syscon_regmap_lookup_by_phandle/sprd_syscon_regmap_lookup_by_compatible. > > So long as the generic driver stays generic. Providing a registration > function sounds cleaner than tainting the code with vendor specifics. So seems my V1 patch set [1] was on the direction as you suggested, but Arnd did not like that. [1] https://lore.kernel.org/patchwork/patch/1226161/ https://lore.kernel.org/patchwork/patch/1226162/ -- Baolin Wang
Re: [PATCH v7 03/15] s390/zcrypt: driver callback to indicate resource in use
On 2020-04-28 00:24, Tony Krowiak wrote: On 4/27/20 4:20 AM, Pierre Morel wrote: On 2020-04-07 21:20, Tony Krowiak wrote: Introduces a new driver callback to prevent a root user from unbinding an AP queue from its device driver if the queue is in use. The intent of this callback is to provide a driver with the means to prevent a root user from inadvertently taking a queue away from a guest and giving it to the host while the guest is still using it. ...snip... This functionality is valid for the host as for the guests and is handled automatically by the firmware with the CRYCB. The AP bus uses QCI to retrieve the host CRYCB and build the hosts AP queues. If instead to mix VFIO CRYCB matrix handling and queues at the same level inside the AP bus we separate these different firmware entities in two different software entities. If we make the AP bus sit above a CRYCB/Matrix bus, and in the way virtualize the QCI and test AP queue instructions: - we can directly pass a matrix device to the guest though a VFIO matrix device - the consistence will be automatic - the VFIO device and parent device will be of the same kind which would make the design much more clearer. - there will be no need for these callback because the consistence of the matrix will be guaranteed by firmware As stated in my response above, the issue here is not consistency. While the design you describe may be reasonable, it is a major departure from what is out in the field. In other words, that ship has sailed. The current VFIO-AP driver works as before, without any change, above the Matrix device I suggest. Aside the old scheme which can continue, the Matrix device can be used directly to build a VFIO Matrix device, usable by QEMU without any modification. Once the dynamic extensions proposed in this series and the associated tools are out on the field, then yes the ship is really far. For now, the existing user's API do not change, the existing tools do not need modifications and we can repair the ship for its long journey. The inconsistency between device and VFIO device and the resulting complexity is not going to ease future enhancement. Regards, Pierre -- Pierre Morel IBM Lab Boeblingen
Re: [PATCH] xen/swiotlb: correct the check for xen_destroy_contiguous_region
On 28.04.20 09:33, peng@nxp.com wrote: From: Peng Fan When booting xen on i.MX8QM, met: " [3.602128] Unable to handle kernel paging request at virtual address 00272d40 [3.610804] Mem abort info: [3.613905] ESR = 0x9604 [3.617332] EC = 0x25: DABT (current EL), IL = 32 bits [3.623211] SET = 0, FnV = 0 [3.626628] EA = 0, S1PTW = 0 [3.630128] Data abort info: [3.633362] ISV = 0, ISS = 0x0004 [3.637630] CM = 0, WnR = 0 [3.640955] [00272d40] user address but active_mm is swapper [3.647983] Internal error: Oops: 9604 [#1] PREEMPT SMP [3.654137] Modules linked in: [3.677285] Hardware name: Freescale i.MX8QM MEK (DT) [3.677302] Workqueue: events deferred_probe_work_func [3.684253] imx6q-pcie 5f00.pcie: PCI host bridge to bus :00 [3.688297] pstate: 6005 (nZCv daif -PAN -UAO) [3.688310] pc : xen_swiotlb_free_coherent+0x180/0x1c0 [3.693993] pci_bus :00: root bus resource [bus 00-ff] [3.701002] lr : xen_swiotlb_free_coherent+0x44/0x1c0 " In xen_swiotlb_alloc_coherent, if !(dev_addr + size - 1 <= dma_mask) or range_straddles_page_boundary(phys, size) are true, it will create contiguous region. So when free, we need to free contiguous region use upper check condition. No, this will break PV guests on x86. I think there is something wrong with your setup in combination with the ARM xen_create_contiguous_region() implementation. Stefano? Juergen Signed-off-by: Peng Fan --- drivers/xen/swiotlb-xen.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index b6d27762c6f8..ab96e468584f 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -346,8 +346,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, /* Convert the size to actually allocated. */ size = 1UL << (order + XEN_PAGE_SHIFT); - if (!WARN_ON((dev_addr + size - 1 > dma_mask) || -range_straddles_page_boundary(phys, size)) && + if (((dev_addr + size - 1 > dma_mask) || + range_straddles_page_boundary(phys, size)) && TestClearPageXenRemapped(virt_to_page(vaddr))) xen_destroy_contiguous_region(phys, order);
linux-next: Tree for Apr 28
Hi all, Changes since 20200424: The qcom tree still had its build failure for which I reverted a commit. The hwmon-staging tree gained a build failure for which I reverted a commit. The mac80211-next tree gained a build failure so I used the version from next-20200424. The drm-misc tree still had its build failure for which I disabled a COMPILE_TEST setting. The akpm-current tree gained a conflict against the risc-v tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 4451 5474 files changed, 151275 insertions(+), 63274 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 htmldocs. 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 318 trees (counting Linus' and 78 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 (51184ae37e05 Merge tag 'for-5.7-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux) Merging fixes/master (8f3d9f354286 Linux 5.7-rc1) Merging kbuild-current/fixes (ab51cac00ef2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging arc-current/for-curr (799587d5731d ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT) Merging arm-current/fixes (8f3d9f354286 Linux 5.7-rc1) Merging arm-soc-fixes/arm/fixes (f42ae4cd4cae Merge tag 'arm-soc/for-5.7/devicetree-fixes' of https://github.com/Broadcom/stblinux into arm/fixes) Merging arm64-fixes/for-next/fixes (59bff30ad6ce Documentation: arm64: fix amu.rst doc warnings) Merging m68k-current/for-linus (86cded5fc525 m68k: defconfig: Update defconfigs for v5.6-rc4) Merging powerpc-fixes/fixes (5990cdee689c lib/mpi: Fix building for powerpc with clang) Merging s390-fixes/fixes (673deb0beba5 s390/protvirt: fix compilation issue) Merging sparc/master (63bef48fd6c9 Merge branch 'akpm' (patches from Andrew)) Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty inodes after removing key) Merging net/master (37255e7a8f47 Merge tag 'batadv-net-for-davem-20200427' of git://git.open-mesh.org/linux-merge) Merging bpf/master (18f02ad19e2c bpf: Fix sk_psock refcnt leak when receiving message) Merging ipsec/master (c95c5f58b35e xfrm interface: fix oops when deleting a x-netns interface) Merging netfilter/master (ea64d8d6c675 netfilter: nat: never update the UDP checksum when it's 0) Merging ipvs/master (0141317611ab Merge branch 'hns3-fixes') Merging wireless-drivers/master (10e41f34a019 MAINTAINERS: update mt76 reviewers) Merging mac80211/master (4a3de90b1184 mac80211: sta_info: Add lockdep condition for RCU list usage) Merging rdma-fixes/for-rc (47c370c1a5ee IB/rdmavt: Always return ERR_PTR from rvt_create_mmap_info()) Merging sound-current/for-linus (ef0b3203c758 ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter) Merging sound-asoc-fixes/for-linus (880f36ba4782 Merge remote-tracking branch 'asoc/for-5.7' into asoc-linus) Merging regmap-fixes/for-linus (cef570d20922 Merge remote-tracking branch 'regmap/for-5.7' into regmap-linus) Merging regulator-fixes/for-linus (659bdf42e912 Merge remote-tracking branch 'regulator/for-5.7' into regulator-linus) Merging spi-fixes/for-linus (ce8438e67dc0 Merge remote-tracking branch 'spi/for-5.7' into spi-linus) Merging pci-current/for-linus (ef46738cc47a MAINTAINERS: Add Rob Herring and remove Andy Murray as PCI reviewers) Merging driver-core.c
Re: [PATCH v3 0/7] perf: Stream comparison
Hi Jiri, On 4/27/2020 6:10 PM, Jiri Olsa wrote: On Mon, Apr 20, 2020 at 09:04:44AM +0800, Jin Yao wrote: SNIP compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39* [ Hot chains in old perf data only ] hot chain 1: cycles: 2, hits: 4.08% -- main div.c:42 compute_flag div.c:28 [ Hot chains in new perf data only ] hot chain 1: cycles: 36, hits: 3.36% -- __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 main div.c:40 Now we can see, following streams pair is moved to another section "[ Hot chains in old perf data but source line changed (*) in new perf data ]" cycles: 1, hits: 26.80% cycles: 1, hits: 27.30% --- -- main div.c:39 main div.c:39* main div.c:44 main div.c:44 so I tried following: # ./perf record -e cycles:u -b ./perf bench sched pipe # ./perf record -e cycles:u -b ./perf bench sched pipe # ./perf diff -f --stream --before $PWD --after $PWD >out 2>&1 and the out file looks like this: [ Matched hot chains between old perf data and new perf data ] [ Hot chains in old perf data but source line changed (*) in new perf data ] [ Hot chains in old perf data only ] hot chain 1: cycles: 0, hits: 4.20% -- 0x89c00163 hot chain 2: cycles: 0, hits: 4.11% -- 0x89c00163 hot chain 3: cycles: 0, hits: 8.22% -- 0x89c00163 hot chain 4: cycles: 0, hits: 5.54% -- 0x89c00163 hot chain 5: cycles: 0, hits: 6.10% -- 0x89c00163 [ Hot chains in new perf data only ] hot chain 1: cycles: 0, hits: 5.21% -- 0x89c00163 hot chain 2: cycles: 0, hits: 4.79% -- 0x89c00163 hot chain 3: cycles: 0, hits: 5.44% -- 0x89c00163 hot chain 4: cycles: 0, hits: 5.50% -- 0x89c00163 hot chain 5: cycles: 0, hits: 7.14% -- 0x89c00163 I'd expected more common paths, from what I can see from 'perf
[PATCH] net/x25: Fix null-ptr-deref in x25_disconnect
We should check null before do x25_neigh_put in x25_disconnect,
otherwise may cause null-ptr-deref like this:
#include
#include
int main() {
int sck_x25;
sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
close(sck_x25);
return 0;
}
BUG: kernel NULL pointer dereference, address: 00d8
CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
RIP: 0010:x25_disconnect+0x91/0xe0
Call Trace:
x25_release+0x18a/0x1b0
__sock_release+0x3d/0xc0
sock_close+0x13/0x20
__fput+0x107/0x270
fput+0x9/0x10
task_work_run+0x6d/0xb0
exit_to_usermode_loop+0x102/0x110
do_syscall_64+0x23c/0x260
entry_SYSCALL_64_after_hwframe+0x49/0xb3
Reported-by: syzbot+6db548b615e5aeefd...@syzkaller.appspotmail.com
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Signed-off-by: YueHaibing
---
net/x25/x25_subr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/x25/x25_subr.c b/net/x25/x25_subr.c
index 8b1b06cabcbf..0285aaa1e93c 100644
--- a/net/x25/x25_subr.c
+++ b/net/x25/x25_subr.c
@@ -357,10 +357,12 @@ void x25_disconnect(struct sock *sk, int reason, unsigned
char cause,
sk->sk_state_change(sk);
sock_set_flag(sk, SOCK_DEAD);
}
- read_lock_bh(&x25_list_lock);
- x25_neigh_put(x25->neighbour);
- x25->neighbour = NULL;
- read_unlock_bh(&x25_list_lock);
+ if (x25->neighbour) {
+ read_lock_bh(&x25_list_lock);
+ x25_neigh_put(x25->neighbour);
+ x25->neighbour = NULL;
+ read_unlock_bh(&x25_list_lock);
+ }
}
/*
--
2.17.1
