Re: [PATCH v3] checkpatch: fix false positives in REPEATED_WORD warning
On Sat, 24 Oct 2020, Joe Perches wrote: > On Sat, 2020-10-24 at 18:54 +0530, Aditya wrote: > > > Would you like to work on > > > further rules that can be improved with your evaluation approach? > > > > Yes, I would like work on further rules. > > Some generic ideas: > > How about working to reduce runtime and complexity by > making the rules extensible or separable at startup. > > Maybe move each existing rules into a separate > directory as an individual file and aggregate them at > checkpatch startup. > > Maybe look at the existing rules that do not have a > $fix option and add them as appropriate. > I certainly support working on fixes. I have this crazy dream that: We can identify a set of rules and clear automatic fixes that maintainers can simply run this script over the patches they pick up when they pick them up. Realistically in an easy interactive mode that works with the maintainers' workflow, so they simply confirm the automatic fixes where the script cannot be 100% sure that the quick fix is the right thing to do. I think for commit message fixes that would be very nice. E.g., correcting URLs, normalizing tags, correcting obvious typos. > You could fix the multiline indentation where the > current warning and fix is only for a single line > > value = function(arg1, > arg2, > arg3); > > where checkpatch emits only single warning and fix > for the line with arg2, but not the line with arg3); > > Maybe try to make the coding styles supported more > flexible: > > Allow braces in different places, support different > tab indentation sizes, spacing rules around operators, > function definition layouts, etc. > > This is a nice idea as well. And I recommend to do this kind of research looking at checkpatch and clang-format; both will not be the 'final tools' but I think if you can identify a good mix and combination of those two tools, we will get a good step forward of documenting the commonalities and differences of coding styles in the different subcommunities (the preferences of specific maintainers and subsystems). A last nice idea to consider: I would like to have an interactive checkpatch.pl mode where an authors can say that they ran checkpatch.pl, seen the warning and errors reported, but disagree and comment why they disagree. Then this kind of information is added to the patch in a non-disturbing area of the patch and we can pick up and aggregate that information from the patches to see the complaints, false positives to address or suggestions which rules should be disabled for some subcommunities. Aditya, your task is now to make those ideas more specific and write down a one to two page project proposal for the mentorship. It can be to some extent in bullet points as long as it is roughly understandable to all of us what you plan and would like to do. With that proposal accepted, you have shown to be applicable to the mentorship program here and we take care of the last organisational points before the start. Lukas
Re: [PATCH 1/2] perf test: Use generic event for expand_libpfm_events()
On Sat, Oct 24, 2020 at 11:59:17AM +0900, Namhyung Kim wrote:
> I found that the UNHALTED_CORE_CYCLES event is only available in the
> Intel machines and it makes other vendors/archs fail on the test. As
> libpfm4 can parse the generic events like cycles, let's use them.
>
> Fixes: 40b74c30ffb9 ("perf test: Add expand cgroup event test")
> Signed-off-by: Namhyung Kim
So would the test still fail when libpfm is not compiled in?
-Andi
[RFC] Removing b_end_io
On my laptop, I have about 31MB allocated to buffer_heads.
buffer_head 182728 299910104 391 : tunables000 :
slabdata 7690 7690 0
Reducing the size of the buffer_head by 8 bytes gets us to 96 bytes,
which means we get 42 per page instead of 39 and saves me 2MB of memory.
I think b_end_io() is ripe for removal. It's only used while the I/O
is in progress, and it's always set to end_bio_bh_io_sync() which
may set the quiet bit, calls ->b_end_io and calls bio_put().
So how about this as an approach? Only another 40 or so call-sites
to take care of to eliminate b_end_io from the buffer_head. Yes, this
particular example should be entirely rewritten to do away with buffer
heads, but that's been true since 2006. I'm looking for an approach
which can be implemented quickly since the buffer_head does not appear
to be going away any time soon.
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index d61b524ae440..7f985b138372 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -314,14 +314,16 @@ static void write_page(struct bitmap *bitmap, struct page
*page, int wait)
md_bitmap_file_kick(bitmap);
}
-static void end_bitmap_write(struct buffer_head *bh, int uptodate)
+static void end_bitmap_write(struct bio *bio)
{
+ struct buffer_head *bh = bio->bi_private;
struct bitmap *bitmap = bh->b_private;
- if (!uptodate)
+ if (bio->bi_status != BLK_STS_OK)
set_bit(BITMAP_WRITE_ERROR, >flags);
if (atomic_dec_and_test(>pending_writes))
wake_up(>write_wait);
+ bio_put(bio);
}
static void free_buffers(struct page *page)
@@ -388,12 +390,11 @@ static int read_page(struct file *file, unsigned long
index,
else
count -= (1b_end_io = end_bitmap_write;
bh->b_private = bitmap;
atomic_inc(>pending_writes);
set_buffer_locked(bh);
set_buffer_mapped(bh);
- submit_bh(REQ_OP_READ, 0, bh);
+ bh_submit(bh, REQ_OP_READ, end_bitmap_write);
}
blk_cur++;
bh = bh->b_this_page;
diff --git a/fs/buffer.c b/fs/buffer.c
index d468ed9981e0..668c586b2ed1 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3022,8 +3022,9 @@ static void end_bio_bh_io_sync(struct bio *bio)
bio_put(bio);
}
-static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
-enum rw_hint write_hint, struct writeback_control *wbc)
+static void __bh_submit(struct buffer_head *bh, unsigned req_flags,
+ enum rw_hint write_hint, struct writeback_control *wbc,
+ bio_end_io_t end_bio)
{
struct bio *bio;
@@ -3036,7 +3037,7 @@ static int submit_bh_wbc(int op, int op_flags, struct
buffer_head *bh,
/*
* Only clear out a write error when rewriting
*/
- if (test_set_buffer_req(bh) && (op == REQ_OP_WRITE))
+ if (test_set_buffer_req(bh) && (op_is_write(req_flags)))
clear_buffer_write_io_error(bh);
bio = bio_alloc(GFP_NOIO, 1);
@@ -3050,14 +3051,14 @@ static int submit_bh_wbc(int op, int op_flags, struct
buffer_head *bh,
bio_add_page(bio, bh->b_page, bh->b_size, bh_offset(bh));
BUG_ON(bio->bi_iter.bi_size != bh->b_size);
- bio->bi_end_io = end_bio_bh_io_sync;
+ bio->bi_end_io = end_bio;
bio->bi_private = bh;
if (buffer_meta(bh))
- op_flags |= REQ_META;
+ req_flags |= REQ_META;
if (buffer_prio(bh))
- op_flags |= REQ_PRIO;
- bio_set_op_attrs(bio, op, op_flags);
+ req_flags |= REQ_PRIO;
+ bio->bi_opf = req_flags;
/* Take care of bh's that straddle the end of the device */
guard_bio_eod(bio);
@@ -3068,6 +3069,12 @@ static int submit_bh_wbc(int op, int op_flags, struct
buffer_head *bh,
}
submit_bio(bio);
+}
+
+static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
+enum rw_hint write_hint, struct writeback_control *wbc)
+{
+ __bh_submit(bh, op | op_flags, write_hint, wbc, end_bio_bh_io_sync);
return 0;
}
@@ -3077,6 +3084,11 @@ int submit_bh(int op, int op_flags, struct buffer_head
*bh)
}
EXPORT_SYMBOL(submit_bh);
+void bh_submit(struct buffer_head *bh, unsigned req_flags, bio_end_io_t end_io)
+{
+ __bh_submit(bh, req_flags, 0, NULL, end_io);
+}
+
/**
* ll_rw_block: low-level access to block devices (DEPRECATED)
* @op: whether to %READ or %WRITE
diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
index 6b47f94378c5..cc9113befe15 100644
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -203,6 +203,7 @@ int sync_dirty_buffer(struct
RE: [kbuild-all] Re: ld.lld: warning: fs/built-in.a(afs/cell.o):(.data..L__unnamed_8) is being placed in '.data..L__unnamed_8'
> Subject: [kbuild-all] Re: ld.lld: warning: fs/built- > in.a(afs/cell.o):(.data..L__unnamed_8) is being placed in > '.data..L__unnamed_8' > > https://github.com/ClangBuiltLinux/linux/issues/1185 sorry for false positive, we will ignore all lld warning related to "being placed in", the initial ignore of similar warning is kind too specific for known issue. Thanks > > On Fri, Oct 23, 2020 at 10:24 AM kernel test robot wrote: > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > > head: f9893351acaecf0a414baf9942b48d5bb5c688c6 > > commit: 88c853c3f5c0a07c5db61b494ee25152535cfeee afs: Fix cell refcounting > by splitting the usage counter > > date: 7 days ago > > config: powerpc64-randconfig-r004-20201022 (attached as .config) > > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project > ee6abef5323d59b983129bf3514ef6775d1d6cd5) > > reproduce (this is a W=1 build): > > wget https://raw.githubusercontent.com/intel/lkp- > tests/master/sbin/make.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # install powerpc64 cross compiling tool for clang build > > # apt-get install binutils-powerpc64-linux-gnu > > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i > d=88c853c3f5c0a07c5db61b494ee25152535cfeee > > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > git fetch --no-tags linus master > > git checkout 88c853c3f5c0a07c5db61b494ee25152535cfeee > > # save the attached .config to linux build tree > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross > ARCH=powerpc64 > > > > If you fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot > > > > All warnings (new ones prefixed by >>): > > > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_3) is > being placed in '.data..L__unnamed_3' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_20) is > being placed in '.data..L__unnamed_20' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_21) is > being placed in '.data..L__unnamed_21' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_23) is > being placed in '.data..L__unnamed_23' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_22) is > being placed in '.data..L__unnamed_22' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_26) is > being placed in '.data..L__unnamed_26' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_25) is > being placed in '.data..L__unnamed_25' > >ld.lld: warning: fs/built-in.a(jffs2/wbuf.o):(.data..L__unnamed_24) is > being placed in '.data..L__unnamed_24' > >ld.lld: warning: fs/built-in.a(ubifs/journal.o):(.data..L__unnamed_1) > is being placed in '.data..L__unnamed_1' > >ld.lld: warning: fs/built-in.a(ubifs/dir.o):(.data..L__unnamed_1) is > being placed in '.data..L__unnamed_1' > >ld.lld: warning: fs/built-in.a(ubifs/dir.o):(.data..L__unnamed_2) is > being placed in '.data..L__unnamed_2' > >ld.lld: warning: fs/built-in.a(ubifs/super.o):(.data..L__unnamed_4) is > being placed in '.data..L__unnamed_4' > >ld.lld: warning: fs/built-in.a(ubifs/super.o):(.data..L__unnamed_1) is > being placed in '.data..L__unnamed_1' > >ld.lld: warning: fs/built-in.a(ubifs/super.o):(.data..L__unnamed_2) is > being placed in '.data..L__unnamed_2' > >ld.lld: warning: fs/built-in.a(ubifs/super.o):(.data..L__unnamed_3) is > being placed in '.data..L__unnamed_3' > >ld.lld: warning: fs/built-in.a(ubifs/sb.o):(.data..L__unnamed_2) is > being placed in '.data..L__unnamed_2' > >ld.lld: warning: fs/built-in.a(ubifs/sb.o):(.data..L__unnamed_1) is > being placed in '.data..L__unnamed_1' > >ld.lld: warning: fs/built-in.a(ubifs/sb.o):(.data..L__unnamed_3) is > being placed in '.data..L__unnamed_3' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_1) is > being placed in '.data..L__unnamed_1' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_2) is > being placed in '.data..L__unnamed_2' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_3) is > being placed in '.data..L__unnamed_3' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_4) is > being placed in '.data..L__unnamed_4' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_5) is > being placed in '.data..L__unnamed_5' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_6) is > being placed in '.data..L__unnamed_6' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_7) is > being placed in '.data..L__unnamed_7' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_8) is > being placed in '.data..L__unnamed_8' > >ld.lld: warning: fs/built-in.a(ubifs/io.o):(.data..L__unnamed_9) is > being
Re: [PATCH v4 0/6] IMA: Infrastructure for measurement of critical kernel data
Hi Tushar, On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote: > There are several kernel components that contain critical data which if > accidentally or maliciously altered, can compromise the security of the > kernel. Example of such components would include LSMs like SELinux, or > AppArmor; or device-mapper targets like dm-crypt, dm-verity etc. ^"the integrity of the system." This cover letter needs to be re-written from a higher perspective, explaining what is meant by "critical data" (e.g. kernel subsystem specific information only stored in kernel memory). > > Many of these components do not use the capabilities provided by kernel > integrity subsystem (IMA), and thus they don't use the benefits of > extended TPM PCR quotes and ultimately the benefits of remote attestation. True, up until recently IMA only measured files, nothing else. Why is this paragraph needed? What new information is provided? > This series bridges this gap, so that potential kernel components that > contain data critical to the security of the kernel could take advantage > of IMA's measuring and quoting abilities - thus ultimately enabling > remote attestation for their specific data. Perhaps, something more along the lines, "This patch set defines a new IMA hook named ... to measure critical data." > > System administrators may want to pick and choose which kernel > components they would want to enable for measurements, quoting, and > remote attestation. To enable that, a new IMA policy is introduced. Reverse the order of this paragraph and the following one, describing the new feature and only afterwards explaining how it may be constrained. > > And lastly, the functionality is exposed through a function > ima_measure_critical_data(). The functionality is generic enough to > measure the data of any kernel component at run-time. To ensure that > only data from supported sources are measured, the kernel component > needs to be added to a compile-time list of supported sources (an > "allowed list of components"). IMA validates the source passed to > ima_measure_critical_data() against this allowed list at run-time. This patch set must include at least one example of measuring critical data, before it can be upstreamed. Tushar, please coordinate with Lakshmi and Raphael. thanks, Mimi
Re: RFC x86/boot/64: BOOT_PGT_SIZE definition for compressed kernel
On Sat, Oct 24, 2020 at 08:41:58PM -0400, Arvind Sankar wrote:
> Hi, I think the definition of BOOT_PGT_SIZE in
> arch/x86/include/asm/boot.h is insufficient, especially after
> ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
>
> Currently, it allocates 6 pages if KASLR is disabled, and either 17 or
> 19 pages depending on X86_VERBOSE_BOOTUP if KASLR is enabled.
>
> - The X86_VERBOSE_BOOTUP test shouldn't be done: that only disables
> debug messages, but warnings/errors are always output to VGA memory,
> so the two extra pages for mapping video RAM are always needed.
>
> - The calculation wasn't updated for X86_5LEVEL, which requires at least
> one more page for the P4D level, and in theory could require two extra
> pages for each of the 4 mappings (compressed kernel, output kernel,
> boot_params and command line), though that would require a system with
> truly ginormous amounts of RAM.
>
> - If KASLR is disabled, there are only 6 pages, but now that we're
> always setting up our own page table, we need 1+(2+2)*3 (one PGD, and
> two PUD and two PMD pages for kernel, boot_params and command line),
> and 2 more pages for the video RAM, and more for 5-level. Even for
> !RELOCATABLE, 13 pages might be needed.
>
> - SEV-ES needs one more page because it needs to do a PTE-level mapping
> for the GHCB page.
>
> - The static calculation is also busted because
> boot/compressed/{kaslr.c,acpi.c} can scan the setup data, EFI
> configuration tables and the EFI memmap, and none of these are
> accounted for. They used to be scanned while still on the
> firmware/bootloader page tables, but now our page tables have to cover
> them as well. Trying to add up the worst case for all of these, and
> anything else the compressed kernel might potentially access seems
> like a lost cause.
>
> We could do something similar to what the main kernel does with
> early_dynamic_pgts: map the compressed kernel at a fixed virtual
> address (in negative address space, say); recycle all the other mappings
> until we're done with decompression, and then map the output,
> boot_params and command line. The number of pages needed for this can be
> statically calculated, for 4-level paging we'd need 2 pages for the
> fixed mapping, 12 pages for the other three, and one PGD page.
>
> Thoughts?
Or just bump BOOT_PGT_SIZE to some largeish number?
Greetings,With due respect
Greetings I am Katie Brianna Taylor and I am American soldier attached to the UN peacekeeping force in Afghanistan. I am the commanding officer of the third Battalion soldier regime. As you may know, everyday there are several cases of insurgent attacks and suicide bombs going on here. We have managed to move funds belonging to some demised persons who were attacked and killed through these attacks. The total amount is US$196 Million dollars in cash, which we shared among ourselves and I got US$8.5 million dollars as my own share of the fund. Now my mission here in Afghanistan will expire in the middle of next month for me to leave this camp and if I do not ship out the fund; I might end up losing it, because as an army officer, we have no right to take anything from the War zone, nor we are allowed to make calls or to make financial transactions. I want to move this money to you, so that you can help keep my share for me until when I shall come over to meet you. I will take 70%, while you take 30%. No strings attached! Just to help me move it out of Afghanistan; which is a war zone right now. I plan on using Diplomatic courier and shipping the money out in a wrapped big envelope, using diplomatic immunity. If you are interested, I will send you the full details. Can I trust you for this? Please signify your interest including your most confidential telephone/fax numbers, home address, city with identity card or passport picture. Note that this business is risk free. The wrapped envelope can be placed in a box or briefcase and shipped out to reach you within 72 hours. Please If you are Interested in assisting, kindly reply through this my PRIVATE and CONFIDENTIAL Email (katiebtaylo...@gmail.com) for further details. PLEASE, TREAT THIS PROPOSAL AS TOP SECRET. Regards, Sergeant Katie B. Taylor.
WARNING in try_to_wake_up
Hello, syzbot found the following issue on: HEAD commit:d7691390 Merge tag 'block-5.10-2020-10-24' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=161d04b050 kernel config: https://syzkaller.appspot.com/x/.config?x=65e86ae741289c65 dashboard link: https://syzkaller.appspot.com/bug?extid=dd74984384afdb86e904 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+dd74984384afdb86e...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 2 PID: 19299 at include/linux/cpumask.h:137 ttwu_stat include/linux/rcupdate.h:779 [inline] WARNING: CPU: 2 PID: 19299 at include/linux/cpumask.h:137 try_to_wake_up+0xd5e/0x1300 kernel/sched/core.c:2979 Modules linked in: CPU: 2 PID: 19299 Comm: io_wq_manager Not tainted 5.9.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:cpu_max_bits_warn include/linux/cpumask.h:137 [inline] RIP: 0010:cpumask_check include/linux/cpumask.h:144 [inline] RIP: 0010:cpumask_check include/linux/cpumask.h:142 [inline] RIP: 0010:cpumask_test_cpu include/linux/cpumask.h:367 [inline] RIP: 0010:is_cpu_allowed kernel/sched/core.c:1705 [inline] RIP: 0010:select_task_rq kernel/sched/core.c:2370 [inline] RIP: 0010:try_to_wake_up+0xd5e/0x1300 kernel/sched/core.c:2964 Code: 70 02 00 00 65 ff 0d d1 97 b5 7e 4c 8d 75 40 0f 85 da f8 ff ff e8 61 ed b3 ff e9 d0 f8 ff ff 41 bd 01 00 00 00 e9 6e f3 ff ff <0f> 0b e9 2d f6 ff ff 48 8d bd 98 01 00 00 48 b8 00 00 00 00 00 fc RSP: 0018:c900014b7d50 EFLAGS: 00010002 RAX: dc00 RBX: 192000296faf RCX: 88805e6e1330 RDX: 11100bcdc265 RSI: 83b4fecb RDI: 0006 RBP: 88805e6e0fc0 R08: 0008 R09: 8cecd34f R10: 0040 R11: R12: 0206 R13: 88805e6e17f0 R14: 88805e6e1000 R15: 88805e6e1328 FS: () GS:88802cc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00b60004 CR3: 67ffb000 CR4: 00350ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: create_io_worker+0x590/0x8d0 fs/io-wq.c:716 io_wq_manager+0x16b/0xb80 fs/io-wq.c:781 kthread+0x3af/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v6 3/6] drivers: hwmon: Add the iEi WT61P803 PUZZLE HWMON driver
Hello Andy,
On Fri, Oct 23, 2020 at 11:47 PM Luka Kovacic wrote:
>
> Hi Andy,
>
> On Tue, Oct 20, 2020 at 10:59 AM Andy Shevchenko
> wrote:
> >
> > On Tue, Oct 20, 2020 at 1:19 AM Luka Kovacic
> > wrote:
> > >
> > > Add the iEi WT61P803 PUZZLE HWMON driver, that handles the fan speed
> > > control via PWM, reading fan speed and reading on-board temperature
> > > sensors.
> > >
> > > The driver registers a HWMON device and a simple thermal cooling device to
> > > enable in-kernel fan management.
> > >
> > > This driver depends on the iEi WT61P803 PUZZLE MFD driver.
> >
> > ...
> >
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/* iEi WT61P803 PUZZLE MCU HWMON Driver
> >
> > Shouldn't be
> > /*
> > * IEI ...
> >
> > ?
> >
> > ...
> >
> > > +/**
> > > + * struct iei_wt61p803_puzzle_thermal_cooling_device - Thermal cooling
> > > device instance
> >
> > > + *
> >
> > Please, remove all these blank lines in kernel doc descriptions.
> >
> > > + * @mcu_hwmon: MCU HWMON struct pointer
> > > + * @tcdev: Thermal cooling device pointer
> > > + * @name: Thermal cooling device name
> > > + * @pwm_channel: PWM channel (0 or 1)
> > > + * @cooling_levels:Thermal cooling device cooling levels
> > > + */
> >
> > ...
> >
> > > +struct iei_wt61p803_puzzle_hwmon {
> > > + struct iei_wt61p803_puzzle *mcu;
> > > + unsigned char *response_buffer;
> > > + bool
> > > thermal_cooling_dev_present[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM];
> > > + struct iei_wt61p803_puzzle_thermal_cooling_device
> > > + *cdev[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM];
> >
> > Isn't this constant a bit too long? Perhaps drop NUM (MAX would
> > suffice I think) for a starter.
>
> Okay, I'll drop NUM.
>
> >
> > > +};
> >
> > ...
> >
> > > + static unsigned char temp_sensor_ntc_cmd[4] = {
> > > + IEI_WT61P803_PUZZLE_CMD_HEADER_START,
> > > + IEI_WT61P803_PUZZLE_CMD_TEMP,
> > > + IEI_WT61P803_PUZZLE_CMD_TEMP_ALL
> >
> > + comma.
> >
> > > + };
> >
> > Why not to be consistent with the rest assignments, choose either
> > above form, or like you have done in the below functions.
>
> Assignments, where the array content will not be modified with custom
> values are done as above.
> Although I could change these to the other form, if that makes it clearer.
I sent out a new patchset that fixes all of the mentioned points,
except this one.
I'd like to keep the assignments, which aren't changed later in the
code assigned,
when the variable is defined.
Kind regards,
Luka
>
> > Also, why 4?
>
> 1 additional character is always required, as this array is passed by
> reference
> to the iei_wt61p803_puzzle_write_command() function, which requires it to
> store a calculated checksum of the array content.
>
> This is done to avoid unnecessary copying of the array inside the MFD driver.
>
> The checksum is a part of the command, so the driver and the MCU can check
> the integrity of the sent data.
>
> >
> > > + size_t reply_size = 0;
> >
> > How is it used in all these functions?
>
> I will add an additional check for the size of the received reply, as
> it should be fixed.
>
> >
> > > + int ret;
> > > +
> > > + ret = iei_wt61p803_puzzle_write_command(mcu_hwmon->mcu,
> > > temp_sensor_ntc_cmd,
> > > +
> > > sizeof(temp_sensor_ntc_cmd), resp_buf,
> > > + _size);
> > > +
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Check the number of NTC values (should be 0x32/'2') */
> >
> > > + if (resp_buf[3] != 0x32)
> >
> > Instead of comment in the parentheses, just do it here
> > " != '2')"
> >
> > > + return -EIO;
> >
> > ...
> >
> > > +static int iei_wt61p803_puzzle_read(struct device *dev, enum
> > > hwmon_sensor_types type,
> > > + u32 attr, int channel, long *val)
> > > +{
> > > + struct iei_wt61p803_puzzle_hwmon *mcu_hwmon =
> > > dev_get_drvdata(dev->parent);
> > > + int ret;
> > > +
> > > + switch (type) {
> > > + case hwmon_pwm:
> >
> > > + ret = iei_wt61p803_puzzle_read_pwm_channel(mcu_hwmon,
> > > channel, val);
> > > + return ret;
> >
> > return iei_...(...);
> > in all such cases.
> >
> > > + case hwmon_fan:
> > > + ret = iei_wt61p803_puzzle_read_fan_speed(mcu_hwmon,
> > > channel, val);
> > > + return ret;
> > > + case hwmon_temp:
> > > + ret = iei_wt61p803_puzzle_read_temp_sensor(mcu_hwmon,
> > > channel, val);
> > > + return ret;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +}
> >
> > ...
> >
> > > +static umode_t iei_wt61p803_puzzle_is_visible(const void *data, enum
> > > hwmon_sensor_types type,
> > > + u32
[PATCH v2 1/1] arm64: dts: marvell: Add a device tree for the IEI Puzzle-M801 board
Add initial support for the IEI Puzzle-M801 1U Rackmount Network
Appliance board.
The board is based on the quad-core Marvell Armada 8040 SoC and supports
up to 16 GB of DDR4 2400 MHz ECC RAM. It has a PCIe x16 slot (x2 lanes
only) and an M.2 type B slot.
Main system hardware:
2x USB 3.0
4x Gigabit Ethernet
2x SFP+
1x SATA 3.0
1x M.2 type B
1x RJ45 UART
1x SPI flash
1x IEI WT61P803 PUZZLE Microcontroller
1x EPSON RX8010 RTC (used instead of the integrated Marvell RTC controller)
6x SFP+ LED
1x HDD LED
All of the hardware listed above is supported and tested in this port.
Signed-off-by: Luka Kovacic
Acked-by: Andrew Lunn
Cc: Luka Perkov
Cc: Robert Marko
---
Changes for v2:
- Use the correct vendor title (IEI instead of iEi)
- Sync the device tree with dt-bindings
This patch is now sent separately from the IEI WT61P803 PUZZLE MCU
patchset. Go to the following link for reference:
https://lore.kernel.org/linux-hwmon/20201025005916.64747-1-luka.kova...@sartura.hr/
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../dts/marvell/armada-8040-puzzle-m801.dts | 523 ++
2 files changed, 524 insertions(+)
create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
diff --git a/arch/arm64/boot/dts/marvell/Makefile
b/arch/arm64/boot/dts/marvell/Makefile
index 3e5f2e7a040c..e413c3261792 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-clearfog-gt-8k.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin-singleshot.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-puzzle-m801.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8080-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += cn9130-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += cn9131-db.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
b/arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
new file mode 100644
index ..dac85fa748de
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040-puzzle-m801.dts
@@ -0,0 +1,523 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ * Copyright (C) 2020 Sartura Ltd.
+ *
+ * Device Tree file for IEI Puzzle-M801
+ */
+
+#include "armada-8040.dtsi"
+
+#include
+#include
+
+/ {
+ model = "IEI-Puzzle-M801";
+ compatible = "marvell,armada8040", "marvell,armada-ap806-quad",
"marvell,armada-ap806";
+
+ aliases {
+ ethernet0 = _eth0;
+ ethernet1 = _eth0;
+ ethernet2 = _eth1;
+ ethernet3 = _eth2;
+ ethernet4 = _eth1;
+ ethernet5 = _eth2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+
+ /* Regulator labels correspond with schematics */
+ v_3_3: regulator-3-3v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_3_3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <_gpio2 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_xhci_vbus_pins>;
+ regulator-name = "v_5v0_usb3_hst_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ status = "okay";
+ };
+
+ v_vddo_h: regulator-1-8v {
+ compatible = "regulator-fixed";
+ regulator-name = "v_vddo_h";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ status = "okay";
+ };
+
+ sfp_cp0_eth0: sfp-cp0-eth0 {
+ compatible = "sff,sfp";
+ i2c-bus = <_i2c>;
+ los-gpio = <_gpio 11 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpio = <_gpio 10 GPIO_ACTIVE_LOW>;
+ tx-disable-gpio = <_gpio 9 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpio = <_gpio 8 GPIO_ACTIVE_HIGH>;
+ maximum-power-milliwatt = <3000>;
+ };
+
+ sfp_cp1_eth0: sfp-cp1-eth0 {
+ compatible = "sff,sfp";
+ i2c-bus = <_i2c>;
+ los-gpio = <_gpio 3 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpio = <_gpio 2 GPIO_ACTIVE_LOW>;
+ tx-disable-gpio = <_gpio 1 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpio = <_gpio 0 GPIO_ACTIVE_HIGH>;
+ maximum-power-milliwatt = <3000>;
+ };
+
+ leds {
+
ld.lld: warning: fs/built-in.a(cifs/fs_context.o):(.data..L__unnamed_1) is being placed in '.data..L__unnamed_1'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d76913908102044f14381df865bb74df17a538cb commit: 555782aa556af869d4f390996607abd356513ba4 cifs: move smb version mount options into fs_context.c date: 2 days ago config: powerpc64-randconfig-r004-20201022 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 147b9497e79a98a8614b2b5eb4ba653b44f6b6f0) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=555782aa556af869d4f390996607abd356513ba4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 555782aa556af869d4f390996607abd356513ba4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_27) is being placed in '.data..L__unnamed_27' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_28) is being placed in '.data..L__unnamed_28' ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_1) is being placed in '.data..L__unnamed_1' ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_2) is being placed in '.data..L__unnamed_2' ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_3) is being placed in '.data..L__unnamed_3' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_1) is being placed in '.data..L__unnamed_1' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_4) is being placed in '.data..L__unnamed_4' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_7) is being placed in '.data..L__unnamed_7' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_8) is being placed in '.data..L__unnamed_8' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_11) is being placed in '.data..L__unnamed_11' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_12) is being placed in '.data..L__unnamed_12' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_3) is being placed in '.data..L__unnamed_3' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_5) is being placed in '.data..L__unnamed_5' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_6) is being placed in '.data..L__unnamed_6' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_9) is being placed in '.data..L__unnamed_9' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_10) is being placed in '.data..L__unnamed_10' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_14) is being placed in '.data..L__unnamed_14' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_13) is being placed in '.data..L__unnamed_13' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_15) is being placed in '.data..L__unnamed_15' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_16) is being placed in '.data..L__unnamed_16' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_18) is being placed in '.data..L__unnamed_18' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_17) is being placed in '.data..L__unnamed_17' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_20) is being placed in '.data..L__unnamed_20' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_19) is being placed in '.data..L__unnamed_19' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_21) is being placed in '.data..L__unnamed_21' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_22) is being placed in '.data..L__unnamed_22' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_2) is being placed in '.data..L__unnamed_2' ld.lld: warning: fs/built-in.a(cifs/inode.o):(.data..L__unnamed_2) is being placed in '.data..L__unnamed_2' ld.lld: warning: fs/built-in.a(cifs/inode.o):(.data..L__unnamed_1) is being placed in '.data..L__unnamed_1' ld.lld: warning: fs/built-in.a(cifs/inode.o):(.data..L__unnamed_3) is being placed in '.data..L__unnamed_3' ld.lld: warning: fs/built-in.a(cifs/inode.o):(.data..L__unnamed_4) is being placed in '.data..L__unnamed_4' ld.lld: warning: fs/built-in.a(cifs/inode.o):(.data..L__unnamed_5) is being placed in '.data..L__unnamed_5' ld.lld: warning: fs/built-in.a(cifs/inode.o):(.data..L__unnamed_6) is
[PATCH v7 3/6] drivers: hwmon: Add the IEI WT61P803 PUZZLE HWMON driver
Add the IEI WT61P803 PUZZLE HWMON driver, that handles the fan speed
control via PWM, reading fan speed and reading on-board temperature
sensors.
The driver registers a HWMON device and a simple thermal cooling device to
enable in-kernel fan management.
This driver depends on the IEI WT61P803 PUZZLE MFD driver.
Signed-off-by: Luka Kovacic
Cc: Luka Perkov
Cc: Robert Marko
---
drivers/hwmon/Kconfig | 8 +
drivers/hwmon/Makefile| 1 +
drivers/hwmon/iei-wt61p803-puzzle-hwmon.c | 412 ++
3 files changed, 421 insertions(+)
create mode 100644 drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 8dc28b26916e..e0469384af2a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -722,6 +722,14 @@ config SENSORS_IBMPOWERNV
This driver can also be built as a module. If so, the module
will be called ibmpowernv.
+config SENSORS_IEI_WT61P803_PUZZLE_HWMON
+ tristate "IEI WT61P803 PUZZLE MFD HWMON Driver"
+ depends on MFD_IEI_WT61P803_PUZZLE
+ help
+ The IEI WT61P803 PUZZLE MFD HWMON Driver handles reading fan speed
+ and writing fan PWM values. It also supports reading on-board
+ temperature sensors.
+
config SENSORS_IIO_HWMON
tristate "Hwmon driver that uses channels specified via iio maps"
depends on IIO
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index a8f4b35b136b..b0afb2d6896f 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_SENSORS_HIH6130) += hih6130.o
obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
obj-$(CONFIG_SENSORS_I5500)+= i5500_temp.o
obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
+obj-$(CONFIG_SENSORS_IEI_WT61P803_PUZZLE_HWMON) += iei-wt61p803-puzzle-hwmon.o
obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
diff --git a/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
b/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
new file mode 100644
index ..61b06c9e61df
--- /dev/null
+++ b/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* IEI WT61P803 PUZZLE MCU HWMON Driver
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IEI_WT61P803_PUZZLE_HWMON_MAX_TEMP 2
+#define IEI_WT61P803_PUZZLE_HWMON_MAX_FAN 5
+#define IEI_WT61P803_PUZZLE_HWMON_MAX_PWM 2
+#define IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_VAL 255
+
+/**
+ * struct iei_wt61p803_puzzle_thermal_cooling_device - Thermal cooling device
instance
+ * @mcu_hwmon: Parent driver struct pointer
+ * @tcdev: Thermal cooling device pointer
+ * @name: Thermal cooling device name
+ * @pwm_channel: Controlled PWM channel (0 or 1)
+ * @cooling_levels:Thermal cooling device cooling levels (DT)
+ */
+struct iei_wt61p803_puzzle_thermal_cooling_device {
+ struct iei_wt61p803_puzzle_hwmon *mcu_hwmon;
+ struct thermal_cooling_device *tcdev;
+ char name[THERMAL_NAME_LENGTH];
+ int pwm_channel;
+ u8 *cooling_levels;
+};
+
+/**
+ * struct iei_wt61p803_puzzle_hwmon - MCU HWMON Driver
+ * @mcu: MCU struct pointer
+ * @response_bufferGlobal MCU response buffer allocation
+ * @thermal_cooling_dev_present: Per-channel thermal cooling device
control indicator
+ * @cdev: Per-channel thermal cooling device
private structure
+ */
+struct iei_wt61p803_puzzle_hwmon {
+ struct iei_wt61p803_puzzle *mcu;
+ unsigned char *response_buffer;
+ bool thermal_cooling_dev_present[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM];
+ struct iei_wt61p803_puzzle_thermal_cooling_device
+ *cdev[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM];
+};
+
+#define raw_temp_to_milidegree_celsius(x) (((x) - 0x80) * 1000)
+static int iei_wt61p803_puzzle_read_temp_sensor(struct
iei_wt61p803_puzzle_hwmon *mcu_hwmon,
+ int channel, long *value)
+{
+ unsigned char *resp_buf = mcu_hwmon->response_buffer;
+ static unsigned char temp_sensor_ntc_cmd[4] = {
+ IEI_WT61P803_PUZZLE_CMD_HEADER_START,
+ IEI_WT61P803_PUZZLE_CMD_TEMP,
+ IEI_WT61P803_PUZZLE_CMD_TEMP_ALL,
+ };
+ size_t reply_size = 0;
+ int ret;
+
+ ret = iei_wt61p803_puzzle_write_command(mcu_hwmon->mcu,
temp_sensor_ntc_cmd,
+ sizeof(temp_sensor_ntc_cmd),
resp_buf,
+ _size);
+
+ if (ret)
+ return ret;
+
+ if (reply_size != 7)
+ return -EIO;
+
+
[PATCH v7 5/6] Documentation/ABI: Add iei-wt61p803-puzzle driver sysfs interface documentation
Add the iei-wt61p803-puzzle driver sysfs interface documentation to allow monitoring and control of the microcontroller from user space. Signed-off-by: Luka Kovacic Cc: Luka Perkov Cc: Robert Marko --- .../testing/sysfs-driver-iei-wt61p803-puzzle | 55 +++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-iei-wt61p803-puzzle diff --git a/Documentation/ABI/testing/sysfs-driver-iei-wt61p803-puzzle b/Documentation/ABI/testing/sysfs-driver-iei-wt61p803-puzzle new file mode 100644 index ..6e71d85f3296 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-iei-wt61p803-puzzle @@ -0,0 +1,55 @@ +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/mac_address_* +Date: September 2020 +Contact: Luka Kovacic +Description: (RW) Internal factory assigned MAC address values + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/serial_number +Date: September 2020 +Contact: Luka Kovacic +Description: (RW) Internal factory assigned serial number + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/version +Date: September 2020 +Contact: Luka Kovacic +Description: (RO) Internal MCU firmware version + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/protocol_version +Date: September 2020 +Contact: Luka Kovacic +Description: (RO) Internal MCU communication protocol version + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/power_loss_recovery +Date: September 2020 +Contact: Luka Kovacic +Description: (RW) Host platform power loss recovery settings + Value mapping: 0 - Always-On, 1 - Always-Off, 2 - Always-AC, 3 - Always-WA + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/bootloader_mode +Date: September 2020 +Contact: Luka Kovacic +Description: (RO) Internal MCU bootloader mode status + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/power_status +Date: September 2020 +Contact: Luka Kovacic +Description: (RO) Power status indicates the host platform power on method. + Value mapping (bitwise list): + 0x80 - Null + 0x40 - Firmware flag + 0x20 - Power loss detection flag (powered off) + 0x10 - Power loss detection flag (AC mode) + 0x08 - Button power on + 0x04 - WOL power on + 0x02 - RTC alarm power on + 0x01 - AC recover power on + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/build_info +Date: September 2020 +Contact: Luka Kovacic +Description: (RO) Internal MCU firmware build date + Format: /mm/dd hh:mm + +What: /sys/bus/serial/devices/.../iei_wt61p803_puzzle_core/ac_recovery_status +Date: September 2020 +Contact: Luka Kovacic +Description: (RO) Host platform AC recovery status value -- 2.26.2
[PATCH v7 4/6] drivers: leds: Add the IEI WT61P803 PUZZLE LED driver
Add support for the IEI WT61P803 PUZZLE LED driver.
Currently only the front panel power LED is supported,
since it is the only LED on this board wired through the
MCU.
The LED is wired directly to the on-board MCU controller
and is toggled using an MCU command.
Support for more LEDs is going to be added in case more
boards implement this microcontroller, as LEDs use many
different GPIOs.
This driver depends on the IEI WT61P803 PUZZLE MFD driver.
Signed-off-by: Luka Kovacic
Cc: Luka Perkov
Cc: Robert Marko
---
drivers/leds/Kconfig| 8 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-iei-wt61p803-puzzle.c | 161
3 files changed, 170 insertions(+)
create mode 100644 drivers/leds/leds-iei-wt61p803-puzzle.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c181df24eae..9028d9bb90b8 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -332,6 +332,14 @@ config LEDS_IPAQ_MICRO
Choose this option if you want to use the notification LED on
Compaq/HP iPAQ h3100 and h3600.
+config LEDS_IEI_WT61P803_PUZZLE
+ tristate "LED Support for the IEI WT61P803 PUZZLE MCU"
+ depends on LEDS_CLASS
+ depends on MFD_IEI_WT61P803_PUZZLE
+ help
+ This option enables support for LEDs controlled by the IEI WT61P803
+ M801 MCU.
+
config LEDS_HP6XX
tristate "LED Support for the HP Jornada 6xx"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index c2c7d7ade0d0..cd362437fefd 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
obj-$(CONFIG_LEDS_INTEL_SS4200)+= leds-ss4200.o
obj-$(CONFIG_LEDS_IP30)+= leds-ip30.o
obj-$(CONFIG_LEDS_IPAQ_MICRO) += leds-ipaq-micro.o
+obj-$(CONFIG_LEDS_IEI_WT61P803_PUZZLE) += leds-iei-wt61p803-puzzle.o
obj-$(CONFIG_LEDS_IS31FL319X) += leds-is31fl319x.o
obj-$(CONFIG_LEDS_IS31FL32XX) += leds-is31fl32xx.o
obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
diff --git a/drivers/leds/leds-iei-wt61p803-puzzle.c
b/drivers/leds/leds-iei-wt61p803-puzzle.c
new file mode 100644
index ..e52394b9d96c
--- /dev/null
+++ b/drivers/leds/leds-iei-wt61p803-puzzle.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* IEI WT61P803 PUZZLE MCU LED Driver
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum iei_wt61p803_puzzle_led_state {
+ IEI_LED_OFF = 0x30,
+ IEI_LED_ON = 0x31,
+ IEI_LED_BLINK_5HZ = 0x32,
+ IEI_LED_BLINK_1HZ = 0x33,
+};
+
+/**
+ * struct iei_wt61p803_puzzle_led - MCU LED Driver
+ * @cdev: LED classdev
+ * @mcu: MCU struct pointer
+ * @response_bufferGlobal MCU response buffer allocation
+ * @lock: General mutex lock to protect simultaneous R/W access
to led_power_state
+ * @led_power_state: State of the front panel power LED
+ */
+struct iei_wt61p803_puzzle_led {
+ struct led_classdev cdev;
+ struct iei_wt61p803_puzzle *mcu;
+ unsigned char *response_buffer;
+ struct mutex lock;
+ int led_power_state;
+};
+
+static inline struct iei_wt61p803_puzzle_led *cdev_to_iei_wt61p803_puzzle_led
+ (struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct iei_wt61p803_puzzle_led, cdev);
+}
+
+static int iei_wt61p803_puzzle_led_brightness_set_blocking(struct led_classdev
*cdev,
+ enum led_brightness
brightness)
+{
+ struct iei_wt61p803_puzzle_led *priv =
cdev_to_iei_wt61p803_puzzle_led(cdev);
+ unsigned char *resp_buf = priv->response_buffer;
+ unsigned char led_power_cmd[5] = {};
+ size_t reply_size;
+ int ret;
+
+ led_power_cmd[0] = IEI_WT61P803_PUZZLE_CMD_HEADER_START;
+ led_power_cmd[1] = IEI_WT61P803_PUZZLE_CMD_LED;
+ led_power_cmd[2] = IEI_WT61P803_PUZZLE_CMD_LED_POWER;
+ led_power_cmd[3] = brightness == LED_OFF ? IEI_LED_OFF : IEI_LED_ON;
+
+ ret = iei_wt61p803_puzzle_write_command(priv->mcu, led_power_cmd,
+ sizeof(led_power_cmd),
+ resp_buf,
+ _size);
+ if (ret)
+ return ret;
+
+ if (reply_size != 3)
+ return -EIO;
+
+ if (!(resp_buf[0] == IEI_WT61P803_PUZZLE_CMD_HEADER_START &&
+ resp_buf[1] == IEI_WT61P803_PUZZLE_CMD_RESPONSE_OK &&
+ resp_buf[2] == IEI_WT61P803_PUZZLE_CHECKSUM_RESPONSE_OK))
+ return -EIO;
+
+ mutex_lock(>lock);
+ priv->led_power_state = brightness;
+ mutex_unlock(>lock);
+
+ return 0;
+}
+
+static enum led_brightness
[PATCH v7 2/6] drivers: mfd: Add a driver for IEI WT61P803 PUZZLE MCU
Add a driver for the IEI WT61P803 PUZZLE microcontroller, used in some
IEI Puzzle series devices. The microcontroller controls system power,
temperature sensors, fans and LEDs.
This driver implements the core functionality for device communication
over the system serial (serdev bus). It handles MCU messages and the
internal MCU properties. Some properties can be managed over sysfs.
Signed-off-by: Luka Kovacic
Cc: Luka Perkov
Cc: Robert Marko
---
drivers/mfd/Kconfig |8 +
drivers/mfd/Makefile|1 +
drivers/mfd/iei-wt61p803-puzzle.c | 1039 +++
include/linux/mfd/iei-wt61p803-puzzle.h | 66 ++
4 files changed, 1114 insertions(+)
create mode 100644 drivers/mfd/iei-wt61p803-puzzle.c
create mode 100644 include/linux/mfd/iei-wt61p803-puzzle.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 33df0837ab41..77afdb633466 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2118,5 +2118,13 @@ config SGI_MFD_IOC3
If you have an SGI Origin, Octane, or a PCI IOC3 card,
then say Y. Otherwise say N.
+config MFD_IEI_WT61P803_PUZZLE
+ tristate "IEI WT61P803 PUZZLE MCU driver"
+ depends on SERIAL_DEV_BUS
+ help
+ IEI WT61P803 PUZZLE is a system power management microcontroller
+ used for fan control, temperature sensor reading, LED control
+ and system identification.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a60e5f835283..33b88023a68d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -236,6 +236,7 @@ obj-$(CONFIG_MFD_HI655X_PMIC) += hi655x-pmic.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
obj-$(CONFIG_MFD_SKY81452) += sky81452.o
+obj-$(CONFIG_MFD_IEI_WT61P803_PUZZLE) += iei-wt61p803-puzzle.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/iei-wt61p803-puzzle.c
b/drivers/mfd/iei-wt61p803-puzzle.c
new file mode 100644
index ..1bb456ff02ef
--- /dev/null
+++ b/drivers/mfd/iei-wt61p803-puzzle.c
@@ -0,0 +1,1039 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* IEI WT61P803 PUZZLE MCU Driver
+ * System management microcontroller for fan control, temperature sensor
reading,
+ * LED control and system identification on IEI Puzzle series ARM-based
appliances.
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IEI_WT61P803_PUZZLE_MAX_COMMAND_LENGTH (20 + 2)
+#define IEI_WT61P803_PUZZLE_RESP_BUF_SIZE 512
+
+#define IEI_WT61P803_PUZZLE_VERSION_MAC_LENGTH 17
+#define IEI_WT61P803_PUZZLE_VERSION_SN_LENGTH 36
+#define IEI_WT61P803_PUZZLE_VERSION_VERSION_LENGTH 6
+#define IEI_WT61P803_PUZZLE_VERSION_BUILD_INFO_LENGTH 16
+#define IEI_WT61P803_PUZZLE_VERSION_PROTOCOL_VERSION_LENGTH8
+
+/* Use HZ as a timeout value throughout the driver */
+#define IEI_WT61P803_PUZZLE_GENERAL_TIMEOUT HZ
+
+/**
+ * struct iei_wt61p803_puzzle_mcu_status - MCU flags state
+ * @ac_recovery_status_flag: AC Recovery Status Flag
+ * @power_loss_recovery: System recovery after power loss
+ * @power_status: System Power-on Method
+ */
+struct iei_wt61p803_puzzle_mcu_status {
+ u8 ac_recovery_status_flag;
+ u8 power_loss_recovery;
+ u8 power_status;
+};
+
+/**
+ * enum iei_wt61p803_puzzle_reply_state - State of the reply
+ * @FRAME_OK: The frame was completely processed/received
+ * @FRAME_PROCESSING: First bytes were received, but the frame isn't complete
+ * @FRAME_STRUCT_EMPTY:The frame struct is empty, no data was received
+ * @FRAME_TIMEOUT: The frame processing timed out, communication failed
+ *
+ * Describes the general state of the frame that is currently being received.
+ */
+enum iei_wt61p803_puzzle_reply_state {
+ FRAME_OK = 0x00,
+ FRAME_PROCESSING = 0x01,
+ FRAME_STRUCT_EMPTY = 0xFF,
+ FRAME_TIMEOUT = 0xFE
+};
+
+/**
+ * struct iei_wt61p803_puzzle_reply - MCU reply
+ * @size: Size of the MCU reply
+ * @data: Full MCU reply buffer
+ * @state: Current state of the packet
+ * @received: Was the response fullfilled
+ */
+struct iei_wt61p803_puzzle_reply {
+ size_t size;
+ unsigned char *data;
+ u8 state;
+ struct completion received;
+};
+
+/**
+ * struct iei_wt61p803_puzzle_mcu_version - MCU version status
+ * @version: Primary firmware version
+ * @build_info:Build date and time
+ * @bootloader_mode: Status of the MCU operation
+ * @protocol_version: MCU communication protocol version
+ * @serial_number: Device factory serial number
+ *
[PATCH v7 0/6] Add support for the IEI WT61P803 PUZZLE MCU
This patchset adds support for the IEI WT61P803 PUZZLE microcontroller, which enables some board specific features like fan and LED control, system power management and temperature sensor reading on some IEI Puzzle series boards. The first board to use this functionality is IEI Puzzle-M801 1U Rackmount Network Appliance and is since v4 sent separately, as a standalone patch. Changes for v2: - Use LAAs for local-mac-address and match reg values - Code styling changes - Error handling moved to the end of the function - Define all magic numbers in the main header file - Convert the driver to make it OF independent - Refactor hwmon to use devm_hwmon_device_register_with_info() - Reduce the number of mutex locks - Allocate memory once for the response buffer - Reduce managed memory allocations Changes for v3: - Move iei-wt61p803-puzzle driver sysfs interface documentation to testing - Change some internal functions to static - Sync dt-bindings examples with the IEI Puzzle-M801 board dts - Remove obsolete device tree properties and correct LED functions - Reverse christmas tree variable declaration order, where possible - MAC address sysfs function rewrite - Fixed struct members size, where reasonable (MFD driver) - Add an error check for hwmon_dev - Use devm_led_classdev_register_ext() in the LED driver Changes for v4: - Clean up sensible checks reported by checkpatch --strict - Document the mutex lock usage in the LED driver - Fix error handling and code styling issues in the HWMON driver - Break up the patchset and send the IEI Puzzle-M801 board support patch separately Changes for v5: - Remove the return before goto to also fwnode_handle_put(child) when ret is 0 (LED driver) - Change unsigned char arrays to static where applicable - Fix unconventional line indentations - Remove unnecessary checks in the HWMON driver - Remove unnecessary type casts - Clear up command array assignments, where the command array is modified before it is sent - Resolve a checksum calculation issue - Add Luka Perkov to MAINTAINERS Changes for v6: - Use the container_of() macro to get the led_cdev parent struct - Use %u instead of %lu in a printf() (LED driver) Changes for v7: - Use the correct vendor title (IEI instead of iEi) - Add missing properties to dt-bindings and fix styling issues - Styling changes in the IEI WT61P803 PUZZLE HWMON driver - Add missing commas in array definitions - Check reply_size, where possible - Clean up kernel-doc comments Luka Kovacic (6): dt-bindings: Add IEI vendor prefix and IEI WT61P803 PUZZLE driver bindings drivers: mfd: Add a driver for IEI WT61P803 PUZZLE MCU drivers: hwmon: Add the IEI WT61P803 PUZZLE HWMON driver drivers: leds: Add the IEI WT61P803 PUZZLE LED driver Documentation/ABI: Add iei-wt61p803-puzzle driver sysfs interface documentation MAINTAINERS: Add an entry for the IEI WT61P803 PUZZLE driver .../testing/sysfs-driver-iei-wt61p803-puzzle | 55 + .../hwmon/iei,wt61p803-puzzle-hwmon.yaml | 53 + .../leds/iei,wt61p803-puzzle-leds.yaml| 45 + .../bindings/mfd/iei,wt61p803-puzzle.yaml | 83 ++ .../devicetree/bindings/vendor-prefixes.yaml |2 + MAINTAINERS | 14 + drivers/hwmon/Kconfig |8 + drivers/hwmon/Makefile|1 + drivers/hwmon/iei-wt61p803-puzzle-hwmon.c | 412 +++ drivers/leds/Kconfig |8 + drivers/leds/Makefile |1 + drivers/leds/leds-iei-wt61p803-puzzle.c | 161 +++ drivers/mfd/Kconfig |8 + drivers/mfd/Makefile |1 + drivers/mfd/iei-wt61p803-puzzle.c | 1039 + include/linux/mfd/iei-wt61p803-puzzle.h | 66 ++ 16 files changed, 1957 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-iei-wt61p803-puzzle create mode 100644 Documentation/devicetree/bindings/hwmon/iei,wt61p803-puzzle-hwmon.yaml create mode 100644 Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml create mode 100644 Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml create mode 100644 drivers/hwmon/iei-wt61p803-puzzle-hwmon.c create mode 100644 drivers/leds/leds-iei-wt61p803-puzzle.c create mode 100644 drivers/mfd/iei-wt61p803-puzzle.c create mode 100644 include/linux/mfd/iei-wt61p803-puzzle.h -- 2.26.2
[PATCH v7 6/6] MAINTAINERS: Add an entry for the IEI WT61P803 PUZZLE driver
Add an entry for the IEI WT61P803 PUZZLE driver (MFD, HWMON, LED drivers). Signed-off-by: Luka Kovacic Cc: Luka Perkov Cc: Robert Marko --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 867157311dc8..d56fdc300066 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8460,6 +8460,20 @@ F: include/net/nl802154.h F: net/ieee802154/ F: net/mac802154/ +IEI WT61P803 M801 MFD DRIVER +M: Luka Kovacic +M: Luka Perkov +L: linux-kernel@vger.kernel.org +S: Maintained +F: Documentation/ABI/stable/sysfs-driver-iei-wt61p803-puzzle +F: Documentation/devicetree/bindings/hwmon/iei,wt61p803-puzzle-hwmon.yaml +F: Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml +F: Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml +F: drivers/hwmon/iei-wt61p803-puzzle-hwmon.c +F: drivers/leds/leds-iei-wt61p803-puzzle.c +F: drivers/mfd/iei-wt61p803-puzzle.c +F: include/linux/mfd/iei-wt61p803-puzzle.h + IFE PROTOCOL M: Yotam Gigi M: Jamal Hadi Salim -- 2.26.2
[PATCH v7 1/6] dt-bindings: Add IEI vendor prefix and IEI WT61P803 PUZZLE driver bindings
Add the IEI WT61P803 PUZZLE Device Tree bindings for MFD, HWMON and LED drivers. A new vendor prefix is also added accordingly for IEI Integration Corp. Signed-off-by: Luka Kovacic Cc: Luka Perkov Cc: Robert Marko --- .../hwmon/iei,wt61p803-puzzle-hwmon.yaml | 53 .../leds/iei,wt61p803-puzzle-leds.yaml| 45 ++ .../bindings/mfd/iei,wt61p803-puzzle.yaml | 83 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + 4 files changed, 183 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/iei,wt61p803-puzzle-hwmon.yaml create mode 100644 Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml create mode 100644 Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml diff --git a/Documentation/devicetree/bindings/hwmon/iei,wt61p803-puzzle-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iei,wt61p803-puzzle-hwmon.yaml new file mode 100644 index ..c24a24e90495 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/iei,wt61p803-puzzle-hwmon.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/iei,wt61p803-puzzle-hwmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IEI WT61P803 PUZZLE MCU HWMON module from IEI Integration Corp. + +maintainers: + - Luka Kovacic + +description: | + This module is a part of the IEI WT61P803 PUZZLE MFD device. For more details + see Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml. + + The HWMON module is a sub-node of the MCU node in the Device Tree. + +properties: + compatible: +const: iei,wt61p803-puzzle-hwmon + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + +patternProperties: + "^fan-group@[0-1]$": +type: object +properties: + reg: +minimum: 0 +maximum: 1 +description: + Fan group ID + + cooling-levels: +minItems: 1 +maxItems: 255 +description: + Cooling levels for the fans (PWM value mapping) +description: | + Properties for each fan group. +required: + - reg + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml b/Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml new file mode 100644 index ..bbf264c13189 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/iei,wt61p803-puzzle-leds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IEI WT61P803 PUZZLE MCU LED module from IEI Integration Corp. + +maintainers: + - Luka Kovacic + +description: | + This module is a part of the IEI WT61P803 PUZZLE MFD device. For more details + see Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml. + + The LED module is a sub-node of the MCU node in the Device Tree. + +properties: + compatible: +const: iei,wt61p803-puzzle-leds + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + + "led@0": +type: object +$ref: common.yaml +description: | + Properties for a single LED. +properties: + reg: +description: + Index of the LED. Only one LED is supported at the moment. +minimum: 0 +maximum: 0 + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml b/Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml new file mode 100644 index ..64264c664c48 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/iei,wt61p803-puzzle.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/iei,wt61p803-puzzle.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IEI WT61P803 PUZZLE MCU from IEI Integration Corp. + +maintainers: + - Luka Kovacic + +description: | + IEI WT61P803 PUZZLE MCU is embedded in some IEI Puzzle series boards. + It's used for controlling system power states, fans, LEDs and temperature + sensors. + + For Device Tree bindings of other sub-modules (HWMON, LEDs) refer to the + binding documents under the respective subsystem directories. + +properties: + compatible: +const: iei,wt61p803-puzzle + + current-speed: +description: + Serial bus speed in bps +maxItems: 1 + + enable-beep: true + + hwmon: +$ref: ../hwmon/iei,wt61p803-puzzle-hwmon.yaml + + leds: +$ref: ../leds/iei,wt61p803-puzzle-leds.yaml + +required: + - compatible + - current-speed + +additionalProperties: false + +examples: + - | +
RFC x86/boot/64: BOOT_PGT_SIZE definition for compressed kernel
Hi, I think the definition of BOOT_PGT_SIZE in
arch/x86/include/asm/boot.h is insufficient, especially after
ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
Currently, it allocates 6 pages if KASLR is disabled, and either 17 or
19 pages depending on X86_VERBOSE_BOOTUP if KASLR is enabled.
- The X86_VERBOSE_BOOTUP test shouldn't be done: that only disables
debug messages, but warnings/errors are always output to VGA memory,
so the two extra pages for mapping video RAM are always needed.
- The calculation wasn't updated for X86_5LEVEL, which requires at least
one more page for the P4D level, and in theory could require two extra
pages for each of the 4 mappings (compressed kernel, output kernel,
boot_params and command line), though that would require a system with
truly ginormous amounts of RAM.
- If KASLR is disabled, there are only 6 pages, but now that we're
always setting up our own page table, we need 1+(2+2)*3 (one PGD, and
two PUD and two PMD pages for kernel, boot_params and command line),
and 2 more pages for the video RAM, and more for 5-level. Even for
!RELOCATABLE, 13 pages might be needed.
- SEV-ES needs one more page because it needs to do a PTE-level mapping
for the GHCB page.
- The static calculation is also busted because
boot/compressed/{kaslr.c,acpi.c} can scan the setup data, EFI
configuration tables and the EFI memmap, and none of these are
accounted for. They used to be scanned while still on the
firmware/bootloader page tables, but now our page tables have to cover
them as well. Trying to add up the worst case for all of these, and
anything else the compressed kernel might potentially access seems
like a lost cause.
We could do something similar to what the main kernel does with
early_dynamic_pgts: map the compressed kernel at a fixed virtual
address (in negative address space, say); recycle all the other mappings
until we're done with decompression, and then map the output,
boot_params and command line. The number of pages needed for this can be
statically calculated, for 4-level paging we'd need 2 pages for the
fixed mapping, 12 pages for the other three, and one PGD page.
Thoughts?
arch/mips/kernel/signal.c:141: undefined reference to `_restore_fp_context'
Hi Thomas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d76913908102044f14381df865bb74df17a538cb
commit: 7505576d1c1ac0cfe85fdf90999433dd8b673012 MIPS: add support for SGI
Octane (IP30)
date: 12 months ago
config: mips-randconfig-r024-20201025 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7505576d1c1ac0cfe85fdf90999433dd8b673012
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7505576d1c1ac0cfe85fdf90999433dd8b673012
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
mips64-linux-ld: arch/mips/kernel/signal.o: in function
`restore_hw_fp_context':
>> arch/mips/kernel/signal.c:141: undefined reference to `_restore_fp_context'
mips64-linux-ld: arch/mips/kernel/signal.o: in function `save_hw_fp_context':
>> arch/mips/kernel/signal.c:132: undefined reference to `_save_fp_context'
mips64-linux-ld: arch/mips/kernel/traps.o: in function `trap_init':
>> arch/mips/kernel/traps.c:2408: undefined reference to `handle_fpe'
>> mips64-linux-ld: arch/mips/kernel/traps.c:2412: undefined reference to
>> `handle_fpe'
>> mips64-linux-ld: arch/mips/kernel/traps.c:2412: undefined reference to
>> `handle_fpe'
>> mips64-linux-ld: arch/mips/kernel/traps.c:2412: undefined reference to
>> `handle_fpe'
>> mips64-linux-ld: arch/mips/kernel/traps.c:2412: undefined reference to
>> `handle_fpe'
vim +141 arch/mips/kernel/signal.c
4eec81d7d8b2127 Paul Burton 2018-11-07 122
2db9ca0a355100c Paul Burton 2015-07-27 123 /*
2db9ca0a355100c Paul Burton 2015-07-27 124 * Wrappers for the assembly
_{save,restore}_fp_context functions.
2db9ca0a355100c Paul Burton 2015-07-27 125 */
2db9ca0a355100c Paul Burton 2015-07-27 126 static int save_hw_fp_context(void
__user *sc)
2db9ca0a355100c Paul Burton 2015-07-27 127 {
2db9ca0a355100c Paul Burton 2015-07-27 128 struct mips_abi *abi =
current->thread.abi;
2db9ca0a355100c Paul Burton 2015-07-27 129 uint64_t __user *fpregs = sc +
abi->off_sc_fpregs;
2db9ca0a355100c Paul Burton 2015-07-27 130 uint32_t __user *csr = sc +
abi->off_sc_fpc_csr;
2db9ca0a355100c Paul Burton 2015-07-27 131
2db9ca0a355100c Paul Burton 2015-07-27 @132 return _save_fp_context(fpregs,
csr);
2db9ca0a355100c Paul Burton 2015-07-27 133 }
2db9ca0a355100c Paul Burton 2015-07-27 134
2db9ca0a355100c Paul Burton 2015-07-27 135 static int
restore_hw_fp_context(void __user *sc)
2db9ca0a355100c Paul Burton 2015-07-27 136 {
2db9ca0a355100c Paul Burton 2015-07-27 137 struct mips_abi *abi =
current->thread.abi;
2db9ca0a355100c Paul Burton 2015-07-27 138 uint64_t __user *fpregs = sc +
abi->off_sc_fpregs;
2db9ca0a355100c Paul Burton 2015-07-27 139 uint32_t __user *csr = sc +
abi->off_sc_fpc_csr;
2db9ca0a355100c Paul Burton 2015-07-27 140
2db9ca0a355100c Paul Burton 2015-07-27 @141 return
_restore_fp_context(fpregs, csr);
2db9ca0a355100c Paul Burton 2015-07-27 142 }
2db9ca0a355100c Paul Burton 2015-07-27 143
:: The code at line 141 was first introduced by commit
:: 2db9ca0a355100c40d1bef2aae3b9d9cf199cd04 MIPS: Use struct mips_abi
offsets to save FP context
:: TO: Paul Burton
:: CC: Ralf Baechle
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH 3/3] KVM: arm64: Failback on unsupported huge page sizes
The huge page could be mapped through multiple contiguous PMDs or PTEs.
The corresponding huge page sizes aren't supported by the page table
walker currently.
This fails the unsupported huge page sizes to the near one. Otherwise,
the guest can't boot successfully: CONT_PMD_SHIFT and CONT_PTE_SHIFT
fail back to PMD_SHIFT and PAGE_SHIFT separately.
Signed-off-by: Gavin Shan
---
arch/arm64/kvm/mmu.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0f51585adc04..81cbdc368246 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -793,12 +793,20 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
vma_shift = PMD_SHIFT;
#endif
+ if (vma_shift == CONT_PMD_SHIFT)
+ vma_shift = PMD_SHIFT;
+
if (vma_shift == PMD_SHIFT &&
!fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE)) {
force_pte = true;
vma_shift = PAGE_SHIFT;
}
+ if (vma_shift == CONT_PTE_SHIFT) {
+ force_pte = true;
+ vma_shift = PAGE_SHIFT;
+ }
+
vma_pagesize = 1UL << vma_shift;
if (vma_pagesize == PMD_SIZE || vma_pagesize == PUD_SIZE)
fault_ipa &= ~(vma_pagesize - 1);
--
2.23.0
[PATCH 0/3] KVM: arm64: Failback on unsupported huge pages
Guest fails to boot when the memory is backed up by hugetlbfs regions, which correspond to contiguous PMDs or PTEs. For example, the guest fails to boot when its memory is backed up by 64KB hugetlbfs pages. The first two patches are sorts of cleanup, not introducing any logical changes. The last patch resolves the issue by fail the unsupported huge page sizes back to nearby one. Ideally, we teach the stage-2 page table to use contiguous mapping in this case, but the page-table walker doesn't it well and needs some sort of reworks and I will do that in the future. Gavin Shan (3): KVM: arm64: Check if 52-bits PA is enabled KVM: arm64: Don't map PUD huge page if it's not available KVM: arm64: Failback on unsupported huge page sizes arch/arm64/kvm/hyp/pgtable.c | 10 ++ arch/arm64/kvm/mmu.c | 12 +++- 2 files changed, 17 insertions(+), 5 deletions(-) -- 2.23.0
[PATCH 1/3] KVM: arm64: Check if 52-bits PA is enabled
The 52-bits physical address is disabled until CONFIG_ARM64_PA_BITS_52
is chosen. This uses option for that check, to avoid the unconditional
check on PAGE_SHIFT in the hot path and thus save some CPU cycles.
Signed-off-by: Gavin Shan
---
arch/arm64/kvm/hyp/pgtable.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 0cdf6e461cbd..fd850353ee89 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -132,8 +132,9 @@ static u64 kvm_pte_to_phys(kvm_pte_t pte)
{
u64 pa = pte & KVM_PTE_ADDR_MASK;
- if (PAGE_SHIFT == 16)
- pa |= FIELD_GET(KVM_PTE_ADDR_51_48, pte) << 48;
+#ifdef CONFIG_ARM64_PA_BITS_52
+ pa |= FIELD_GET(KVM_PTE_ADDR_51_48, pte) << 48;
+#endif
return pa;
}
@@ -142,8 +143,9 @@ static kvm_pte_t kvm_phys_to_pte(u64 pa)
{
kvm_pte_t pte = pa & KVM_PTE_ADDR_MASK;
- if (PAGE_SHIFT == 16)
- pte |= FIELD_PREP(KVM_PTE_ADDR_51_48, pa >> 48);
+#ifdef CONFIG_ARM64_PA_BITS_52
+ pte |= FIELD_PREP(KVM_PTE_ADDR_51_48, pa >> 48);
+#endif
return pte;
}
--
2.23.0
[PATCH 2/3] KVM: arm64: Don't map PUD huge page if it's not available
PUD huge page isn't available when CONFIG_ARM64_4K_PAGES is disabled.
In this case, we needn't try to map the memory through PUD huge pages
to save some CPU cycles in the hot path.
This also corrects the code style issue, which was introduced by
commit <523b3999e5f6> ("KVM: arm64: Try PMD block mappings if PUD mappings
are not supported").
Signed-off-by: Gavin Shan
---
arch/arm64/kvm/mmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index a816cb8e619b..0f51585adc04 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -787,9 +787,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
vma_shift = PAGE_SHIFT;
}
+#ifdef CONFIG_ARM64_4K_PAGES
if (vma_shift == PUD_SHIFT &&
!fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
- vma_shift = PMD_SHIFT;
+ vma_shift = PMD_SHIFT;
+#endif
if (vma_shift == PMD_SHIFT &&
!fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE)) {
--
2.23.0
[PATCH] ibmvscsi: fix race potential race after loss of transport
After a loss of tranport due to an adatper migration or crash/disconnect from
the host partner there is a tiny window where we can race adjusting the
request_limit of the adapter. The request limit is atomically inc/dec to track
the number of inflight requests against the allowed limit of our VIOS partner.
After a transport loss we set the request_limit to zero to reflect this state.
However, there is a window where the adapter may attempt to queue a command
because the transport loss event hasn't been fully processed yet and
request_limit is still greater than zero. The hypercall to send the event will
fail and the error path will increment the request_limit as a result. If the
adapter processes the transport event prior to this increment the request_limit
becomes out of sync with the adapter state and can result in scsi commands being
submitted on the now reset connection prior to an SRP Login resulting in a
protocol violation.
Fix this race by protecting request_limit with the host lock when changing the
value via atomic_set() to indicate no transport.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 36 +++-
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index b1f3017b6547..188ed75417a5 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -806,6 +806,22 @@ static void purge_requests(struct ibmvscsi_host_data
*hostdata, int error_code)
spin_unlock_irqrestore(hostdata->host->host_lock, flags);
}
+/**
+ * ibmvscsi_set_request_limit - Set the adapter request_limit in response to
+ * an adapter failure, reset, or SRP Login. Done under host lock to prevent
+ * race with scsi command submission.
+ * @hostdata: adapter to adjust
+ * @limit: new request limit
+ */
+static void ibmvscsi_set_request_limit(struct ibmvscsi_host_data *hostdata,
int limit)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(hostdata->host->host_lock, flags);
+ atomic_set(>request_limit, limit);
+ spin_unlock_irqrestore(hostdata->host->host_lock, flags);
+}
+
/**
* ibmvscsi_reset_host - Reset the connection to the server
* @hostdata: struct ibmvscsi_host_data to reset
@@ -813,7 +829,7 @@ static void purge_requests(struct ibmvscsi_host_data
*hostdata, int error_code)
static void ibmvscsi_reset_host(struct ibmvscsi_host_data *hostdata)
{
scsi_block_requests(hostdata->host);
- atomic_set(>request_limit, 0);
+ ibmvscsi_set_request_limit(hostdata, 0);
purge_requests(hostdata, DID_ERROR);
hostdata->action = IBMVSCSI_HOST_ACTION_RESET;
@@ -1146,13 +1162,13 @@ static void login_rsp(struct srp_event_struct
*evt_struct)
dev_info(hostdata->dev, "SRP_LOGIN_REJ reason %u\n",
evt_struct->xfer_iu->srp.login_rej.reason);
/* Login failed. */
- atomic_set(>request_limit, -1);
+ ibmvscsi_set_request_limit(hostdata, -1);
return;
default:
dev_err(hostdata->dev, "Invalid login response typecode
0x%02x!\n",
evt_struct->xfer_iu->srp.login_rsp.opcode);
/* Login failed. */
- atomic_set(>request_limit, -1);
+ ibmvscsi_set_request_limit(hostdata, -1);
return;
}
@@ -1163,7 +1179,7 @@ static void login_rsp(struct srp_event_struct *evt_struct)
* This value is set rather than added to request_limit because
* request_limit could have been set to -1 by this client.
*/
- atomic_set(>request_limit,
+ ibmvscsi_set_request_limit(hostdata,
be32_to_cpu(evt_struct->xfer_iu->srp.login_rsp.req_lim_delta));
/* If we had any pending I/Os, kick them */
@@ -1195,13 +1211,13 @@ static int send_srp_login(struct ibmvscsi_host_data
*hostdata)
login->req_buf_fmt = cpu_to_be16(SRP_BUF_FORMAT_DIRECT |
SRP_BUF_FORMAT_INDIRECT);
- spin_lock_irqsave(hostdata->host->host_lock, flags);
/* Start out with a request limit of 0, since this is negotiated in
* the login request we are just sending and login requests always
* get sent by the driver regardless of request_limit.
*/
- atomic_set(>request_limit, 0);
+ ibmvscsi_set_request_limit(hostdata, 0);
+ spin_lock_irqsave(hostdata->host->host_lock, flags);
rc = ibmvscsi_send_srp_event(evt_struct, hostdata, login_timeout * 2);
spin_unlock_irqrestore(hostdata->host->host_lock, flags);
dev_info(hostdata->dev, "sent SRP login\n");
@@ -1781,7 +1797,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
return;
case VIOSRP_CRQ_XPORT_EVENT:/* Hypervisor telling us the connection
is closed */
scsi_block_requests(hostdata->host);
-
WARNING: modpost: vmlinux.o(.text.unlikely+0x11494): Section mismatch in reference from the function bcm2836_arm_irqchip_smp_init() to the function .init.text:set_smp_ipi_range()
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d76913908102044f14381df865bb74df17a538cb commit: 0809ae724904c3c5dbdddf4169d48aac9c6fcdc8 irqchip/bcm2836: Configure mailbox interrupts as standard interrupts date: 5 weeks ago config: arm64-randconfig-p001-20201025 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0809ae724904c3c5dbdddf4169d48aac9c6fcdc8 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 0809ae724904c3c5dbdddf4169d48aac9c6fcdc8 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" version generation failed, symbol will not be versioned. >> WARNING: modpost: vmlinux.o(.text.unlikely+0x11494): Section mismatch in >> reference from the function bcm2836_arm_irqchip_smp_init() to the function >> .init.text:set_smp_ipi_range() The function bcm2836_arm_irqchip_smp_init() references the function __init set_smp_ipi_range(). This is often because bcm2836_arm_irqchip_smp_init lacks a __init annotation or the annotation of set_smp_ipi_range is wrong. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v8 -tip 02/26] sched: Introduce sched_class::pick_task()
On 2020/10/24 20:27, Vineeth Pillai wrote:
>
>
> On 10/24/20 7:10 AM, Vineeth Pillai wrote:
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 93a3b874077d..4cae5ac48b60 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4428,12 +4428,14 @@ pick_next_entity(struct cfs_rq *cfs_rq, struct
>> sched_entity *curr)
>> Â Â Â se = second;
>> Â Â Â }
>>
>> -Â Â if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) {
>> +Â Â if (left && cfs_rq->next &&
>> +Â Â wakeup_preempt_entity(cfs_rq->next, left) < 1) {
>> Â Â Â /*
>> * Someone really wants this to run. If it's not unfair, run
>> it.
>> */
>> Â Â Â se = cfs_rq->next;
>> -Â Â } else if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, left)
>> < 1) {
>> +Â Â } else if (left && cfs_rq->last &&
>> +Â Â wakeup_preempt_entity(cfs_rq->last, left) < 1) {
>> Â Â Â /*
>> * Prefer last buddy, try to return the CPU to a preempted
>> task.
>>
>>
>> There reason for left being NULL needs to be investigated. This was
>> there from v1 and we did not yet get to it. I shall try to debug later
>> this week.
>
> Thinking more about it and looking at the crash, I think that
> 'left == NULL' can happen in pick_next_entity for core scheduling.
> If a cfs_rq has only one task that is running, then it will be
> dequeued and 'left = __pick_first_entity()' will be NULL as the
> cfs_rq will be empty. This would not happen outside of coresched
> because we never call pick_tack() before put_prev_task() which
> will enqueue the task back.
>
> With core scheduling, a cpu can call pick_task() for its sibling while
> the sibling is still running the active task and put_prev_task has yet
> not been called. This can result in 'left == NULL'. So I think the
> above fix is appropriate when core scheduling is active. It could be
> cleaned up a bit though.
This patch works, thanks Vineeth for the quick fix!
Re: [PATCH v3] checkpatch: extend attributes check to handle more patterns
On 10/24/20 4:21 PM, Joe Perches wrote:
>> +if (exists($attr_list{$curr_attr})) {
>> +my $new = $attr_list{$curr_attr};
>> +WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
>> + "$new$params is preffered over
>> __attribute__(($attr))\n" . $herecurr);
preferred
Sorry if that has already been mentioned.
--
~Randy
Re: [PATCH v3] checkpatch: extend attributes check to handle more patterns
On Sat, 2020-10-24 at 14:35 +0530, Dwaipayan Ray wrote:
> It is generally preferred that the macros from
> include/linux/compiler_attributes.h are used, unless there
> is a reason not to.
>
> checkpatch currently checks __attribute__ for each of
> packed, aligned, printf, scanf, and weak. Other declarations
> in compiler_attributes.h are not handled.
>
> Add a generic test to check the presence of such attributes.
> Some attributes require more specific handling and are kept
> separate.
[]
> - }
> + $line =~ /__attribute__\s*\(\s*($balanced_parens)\s*\)/) {
> + my $attr = $1;
> + $attr =~ s/\s*\(\s*(.*)\)\s*/$1/;
> +
> + my %attr_list = (
> + "alias" => "__alias",
> + "aligned" => "__aligned",
> + "always_inline" =>
> "__always_inline",
> + "assume_aligned"=>
> "__assume_aligned",
> + "cold" => "__cold",
> + "const" => "__const",
> + "copy" => "__copy",
> + "designated_init" =>
> "__designated_init",
> + "externally_visible"=> "__visible",
> + "fallthrough" =>
> "fallthrough",
I'd remove fallthrough.
It doesn't make sense as the attribute could be in any line
of a switch/case block and fallthrough; must be the last line
of the block.
> + if ($attr =~ /^(\w+)\s*(${balanced_parens})?/) {
> + my $curr_attr = $1;
> + my $params = '';
> + $params = $2 if defined($2);
> + $curr_attr =~ s/^[\s_]+|[\s_]+$//g;
> +
> + if (exists($attr_list{$curr_attr})) {
> + my $new = $attr_list{$curr_attr};
> + WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
> + "$new$params is preffered over
> __attribute__(($attr))\n" . $herecurr);
Be nice to have a $fix option here
> + # Check for __attribute__ format(printf, prefer __printf
> + if ($attr =~ /^_*format_*\s*\(\s*printf/) {
> + if (WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
> + "__printf(string-index,
> first-to-check) is preferred over __attribute__((format(printf, string-index,
> first-to-check)))\n" . $herecurr) &&
> + $fix) {
> + $fixed[$fixlinenr] =~
> s/\b__attribute__\s*\(\s*\(\s*format\s*\(\s*printf\s*,\s*(.*)\)\s*\)\s*\)/"__printf("
> . trim($1) . ")"/ex;
like for format(printf, index, pos)
and format(scanf, index, pos)
[PATCH v3 1/1] sched: watchdog: Touch kernel watchdog with sched count
Instead of periodically resetting watchdogs from thread context,
this patch simply forces resched and checks rq->sched_count.
Watchdog is reset if the sched count increases. If the same thread
is picked by pick_next_task during resched, there is no context
switch.
With the new method we lose coverage on: a migration/n thread
actually gets picked and we actually context switch to the
migration/n thread. These steps are unlikely to silently fail.
The change would provide nearly the same level of protection with
less latency / jitter.
Suggested-by: Paul Turner
Suggested-by: Peter Zijlstra
Signed-off-by: Xi Wang
---
include/linux/sched.h | 4
kernel/sched/core.c | 23 +++--
kernel/sched/sched.h | 6 +-
kernel/watchdog.c | 47 +--
4 files changed, 44 insertions(+), 36 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d383cf09e78f..1e3bef9a9cdb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1662,6 +1662,10 @@ extern int sched_setattr(struct task_struct *, const
struct sched_attr *);
extern int sched_setattr_nocheck(struct task_struct *, const struct sched_attr
*);
extern struct task_struct *idle_task(int cpu);
+#ifdef CONFIG_SOFTLOCKUP_DETECTOR
+extern unsigned int sched_get_count(int cpu);
+#endif
+
/**
* is_idle_task - is the specified task an idle task?
* @p: the task in question.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8160ab5263f8..378f0f36c402 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4293,8 +4293,6 @@ static inline void schedule_debug(struct task_struct
*prev, bool preempt)
rcu_sleep_check();
profile_hit(SCHED_PROFILING, __builtin_return_address(0));
-
- schedstat_inc(this_rq()->sched_count);
}
static void put_prev_task_balance(struct rq *rq, struct task_struct *prev,
@@ -4492,6 +4490,12 @@ static void __sched notrace __schedule(bool preempt)
clear_tsk_need_resched(prev);
clear_preempt_need_resched();
+#ifdef CONFIG_SOFTLOCKUP_DETECTOR
+ this_rq()->sched_count++; /* sched count is also used by watchdog */
+#else
+ schedstat_inc(this_rq()->sched_count);
+#endif
+
if (likely(prev != next)) {
rq->nr_switches++;
/*
@@ -5117,6 +5121,21 @@ struct task_struct *idle_task(int cpu)
return cpu_rq(cpu)->idle;
}
+#ifdef CONFIG_SOFTLOCKUP_DETECTOR
+
+/**
+ * sched_get_count - get the sched count of a CPU.
+ * @cpu: the CPU in question.
+ *
+ * Return: sched count.
+ */
+unsigned int sched_get_count(int cpu)
+{
+ return cpu_rq(cpu)->sched_count;
+}
+
+#endif
+
/**
* find_process_by_pid - find a process with a matching PID value.
* @pid: the pid in question.
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 28709f6b0975..f23255981d52 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -959,6 +959,11 @@ struct rq {
u64 clock_pelt;
unsigned long lost_idle_time;
+#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_SOFTLOCKUP_DETECTOR)
+ /* Also used by watchdog - no longer grouping with other sched stats */
+ unsigned intsched_count;
+#endif
+
atomic_tnr_iowait;
#ifdef CONFIG_MEMBARRIER
@@ -1036,7 +1041,6 @@ struct rq {
unsigned intyld_count;
/* schedule() stats */
- unsigned intsched_count;
unsigned intsched_goidle;
/* try_to_wake_up() stats */
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 5abb5b22ad13..22f87aded95a 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -170,6 +170,7 @@ static bool softlockup_initialized __read_mostly;
static u64 __read_mostly sample_period;
static DEFINE_PER_CPU(unsigned long, watchdog_touch_ts);
+static DEFINE_PER_CPU(unsigned int, watchdog_sched_prev);
static DEFINE_PER_CPU(struct hrtimer, watchdog_hrtimer);
static DEFINE_PER_CPU(bool, softlockup_touch_sync);
static DEFINE_PER_CPU(bool, soft_watchdog_warn);
@@ -239,6 +240,7 @@ static void set_sample_period(void)
static void __touch_watchdog(void)
{
__this_cpu_write(watchdog_touch_ts, get_timestamp());
+ __this_cpu_write(watchdog_sched_prev,
sched_get_count(smp_processor_id()));
}
/**
@@ -318,25 +320,6 @@ static void watchdog_interrupt_count(void)
__this_cpu_inc(hrtimer_interrupts);
}
-static DEFINE_PER_CPU(struct completion, softlockup_completion);
-static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
-
-/*
- * The watchdog thread function - touches the timestamp.
- *
- * It only runs once every sample_period seconds (4 seconds by
- * default) to reset the softlockup timestamp. If this gets delayed
- * for more than 2*watchdog_thresh seconds then the debug-printout
- * triggers in watchdog_timer_fn().
- */
-static int softlockup_fn(void *data)
-{
- __touch_watchdog();
-
gFrom 9667d5ddbb1dc230653e5f8cedb778e9c562d46c Mon Sep 17 00:00:00 2001
Instead of periodically resetting watchdogs from thread context, this patch simply forces resched and checks rq->sched_count. Watchdog is reset if the sched count increases. If the same thread is picked by pick_next_task during resched, there is no context switch. With the new method we lose coverage on: a migration/n thread actually gets picked and we actually context switch to the migration/n thread. These steps are unlikely to silently fail. The change would provide nearly the same level of protection with less latency / jitter. v3: - Removed the old method and boot option - Still need to check resched v2: - Use sched_count instead of having sched calling into watchdog code - Remove the sysctl and add a boot option, which can be removed later - Changed the subject line Xi Wang (1): sched: watchdog: Touch kernel watchdog with sched count include/linux/sched.h | 4 kernel/sched/core.c | 23 +++-- kernel/sched/sched.h | 6 +- kernel/watchdog.c | 47 +-- 4 files changed, 44 insertions(+), 36 deletions(-) -- 2.29.0.rc2.309.g374f81d7ae-goog
Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows
Hi Laurent On 24/10/2020 23:36, Laurent Pinchart wrote: > Hi Dan, > > On Sat, Oct 24, 2020 at 11:28:06PM +0100, Daniel Scally wrote: >> On 24/10/2020 10:37, Laurent Pinchart wrote: >> > I wonder if we could avoid depending on the I2C device being created by > getting the fwnode from adev, and setting ->secondary manually. adev > would need to be passed to get_acpi_ssdb_sensor_data() instead of dev. Let me try that; I initially wanted to do set_secondary_fwnode(>dev, fwnode) to avoid depending on the I2C dev being created but it turns out >dev isn't the same pointer. I shall try it and see. >> Actually, thinking on this further I think maybe we can't avoid that - >> it's not actually in this patch series but during assigning GPIO >> resources parsed from PMIC's ACPI node to the sensor, I'm using >> dev_name() on the i2c dev to pass to .dev_id member of gpiod_lookup_table > Any chance we can construct the I2C device name from the ACPI device, > the same way that the ACPI/I2C core does ? It may be a dead end, but if > we could avoid depending on the I2C device, I think it will make > initialization easier. I have a feeling that will be difficult though, > as we'll need the I2C bus number, which won't be readily available. I'd have to look into how the ACPI/I2C core does it to be confident, but I think it would be ok. Doesn't look to me like the bus number is involved; my sensor's device names come through as "i2c-OVTI2680:00"; that's just a prefix tacked on to dev_name(adev->dev). I'm sure there's something that will stop it being quite so easy, but hopefully not insurmountable. > Maybe this calls for extending the gpiod lookup API, but that would then > likely be something we would build on top. I'm thinking about a way to > specify the GPIO mapping in the software node, and retrieving it from > there, the same way this is done for GPIOs in OF-based systems. Yeah that's an option too; I had had the same thought actually. Probably an extensive piece of work in its own right though
Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows
Hi Dan, On Sat, Oct 24, 2020 at 11:28:06PM +0100, Daniel Scally wrote: > On 24/10/2020 10:37, Laurent Pinchart wrote: > > > >>> I wonder if we could avoid depending on the I2C device being created by > >>> getting the fwnode from adev, and setting ->secondary manually. adev > >>> would need to be passed to get_acpi_ssdb_sensor_data() instead of dev. > >> Let me try that; I initially wanted to do > >> set_secondary_fwnode(>dev, fwnode) to avoid depending on the I2C > >> dev being created but it turns out >dev isn't the same pointer. I > >> shall try it and see. > > Actually, thinking on this further I think maybe we can't avoid that - > it's not actually in this patch series but during assigning GPIO > resources parsed from PMIC's ACPI node to the sensor, I'm using > dev_name() on the i2c dev to pass to .dev_id member of gpiod_lookup_table Any chance we can construct the I2C device name from the ACPI device, the same way that the ACPI/I2C core does ? It may be a dead end, but if we could avoid depending on the I2C device, I think it will make initialization easier. I have a feeling that will be difficult though, as we'll need the I2C bus number, which won't be readily available. Maybe this calls for extending the gpiod lookup API, but that would then likely be something we would build on top. I'm thinking about a way to specify the GPIO mapping in the software node, and retrieving it from there, the same way this is done for GPIOs in OF-based systems. -- Regards, Laurent Pinchart
Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows
Hi Laurent On 24/10/2020 10:37, Laurent Pinchart wrote: > >>> I wonder if we could avoid depending on the I2C device being created by >>> getting the fwnode from adev, and setting ->secondary manually. adev >>> would need to be passed to get_acpi_ssdb_sensor_data() instead of dev. >> Let me try that; I initially wanted to do >> set_secondary_fwnode(>dev, fwnode) to avoid depending on the I2C >> dev being created but it turns out >dev isn't the same pointer. I >> shall try it and see. Actually, thinking on this further I think maybe we can't avoid that - it's not actually in this patch series but during assigning GPIO resources parsed from PMIC's ACPI node to the sensor, I'm using dev_name() on the i2c dev to pass to .dev_id member of gpiod_lookup_table
Re: [PATCH v3 14/56] IB: fix kernel-doc markups
Thanks Mauro, small fix for iser On 10/23/2020 7:33 PM, Mauro Carvalho Chehab wrote: Some functions have different names between their prototypes and the kernel-doc markup. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c b/drivers/infiniband/ulp/iser/iscsi_iser.c index 3690e28cc7ea..84cebf937680 100644 --- a/drivers/infiniband/ulp/iser/iscsi_iser.c +++ b/drivers/infiniband/ulp/iser/iscsi_iser.c @@ -739,7 +739,7 @@ iscsi_iser_set_param(struct iscsi_cls_conn *cls_conn, } /** - * iscsi_iser_set_param() - set class connection parameter + * iscsi_iser_conn_get_stats() - set class connection parameter iscsi_iser_conn_get_stats() - get iscsi connection statistics * @cls_conn:iscsi class connection * @stats: iscsi stats to output *
[PATCH v3 04/35] x86/devicetree: Fix the ioapic interrupt type table
From: Thomas Gleixner
The ioapic interrupt type table is wrong as it assumes that polarity in
IO/APIC context means active high when set. But the IO/APIC polarity is
working the other way round. This works because the ordering of the entries
is consistent with the device tree and the type information is not used by
the IO/APIC interrupt chip.
The whole trigger and polarity business of IO/APIC is misleading and the
corresponding constants which are defined as 0/1 are not used consistently
and are going to be removed.
Rename the type table members to 'is_level' and 'active_low' and adjust the
type information for consistency sake.
No functional change.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/kernel/devicetree.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index ddffd80f5c52..6a4cb71c2498 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -184,31 +184,31 @@ static unsigned int ioapic_id;
struct of_ioapic_type {
u32 out_type;
- u32 trigger;
- u32 polarity;
+ u32 is_level;
+ u32 active_low;
};
static struct of_ioapic_type of_ioapic_type[] =
{
{
- .out_type = IRQ_TYPE_EDGE_RISING,
- .trigger= IOAPIC_EDGE,
- .polarity = 1,
+ .out_type = IRQ_TYPE_EDGE_FALLING,
+ .is_level = 0,
+ .active_low = 1,
},
{
- .out_type = IRQ_TYPE_LEVEL_LOW,
- .trigger= IOAPIC_LEVEL,
- .polarity = 0,
+ .out_type = IRQ_TYPE_LEVEL_HIGH,
+ .is_level = 1,
+ .active_low = 0,
},
{
- .out_type = IRQ_TYPE_LEVEL_HIGH,
- .trigger= IOAPIC_LEVEL,
- .polarity = 1,
+ .out_type = IRQ_TYPE_LEVEL_LOW,
+ .is_level = 1,
+ .active_low = 1,
},
{
- .out_type = IRQ_TYPE_EDGE_FALLING,
- .trigger= IOAPIC_EDGE,
- .polarity = 0,
+ .out_type = IRQ_TYPE_EDGE_RISING,
+ .is_level = 0,
+ .active_low = 0,
},
};
@@ -228,7 +228,7 @@ static int dt_irqdomain_alloc(struct irq_domain *domain,
unsigned int virq,
return -EINVAL;
it = _ioapic_type[type_index];
- ioapic_set_alloc_attr(, NUMA_NO_NODE, it->trigger, it->polarity);
+ ioapic_set_alloc_attr(, NUMA_NO_NODE, it->is_level, it->active_low);
tmp.devid = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
tmp.ioapic.pin = fwspec->param[0];
--
2.26.2
[PATCH v3 00/35] Fix x2apic enablement and allow more CPUs, clean up I/OAPIC and MSI bitfields
Fix the conditions for enabling x2apic on guests without interrupt remapping, and support 15-bit Extended Destination ID to allow 32768 CPUs without IR on hypervisors that support it. Make the I/OAPIC code generate its RTE directly from the MSI message created by the parent irqchip, and fix up a bunch of magic mask/shift macros to use bitfields for MSI messages and I/OAPIC RTEs while we're at it. v3: • Lots of bitfield cleanups from Thomas. • Disable hyperv-iommu if 15-bit extension is present. • Fix inconsistent CONFIG_PCI_MSI/CONFIG_GENERIC_MSI_IRQ in hpet.c • Split KVM_FEATURE_MSI_EXT_DEST_ID patch, half of which is going upstream through KVM tree (and the other half needs to wait, or have an #ifdef) so is left at the top of the tree. v2: • Minor cleanups. • Move __irq_msi_compose_msg() to apic.c, make virt_ext_dest_id static. • Generate I/OAPIC RTE directly from parent irqchip's MSI messages. • Clean up HPET MSI support into hpet.c now that we can. David Woodhouse (19): x86/apic: Fix x2apic enablement without interrupt remapping x86/msi: Only use high bits of MSI address for DMAR unit x86/apic: Always provide irq_compose_msi_msg() method for vector domain x86/hpet: Move MSI support into hpet.c x86/ioapic: Generate RTE directly from parent irqchip's MSI message genirq/irqdomain: Implement get_name() method on irqchip fwnodes x86/apic: Add select() method on vector irqdomain iommu/amd: Implement select() method on remapping irqdomain iommu/vt-d: Implement select() method on remapping irqdomain iommu/hyper-v: Implement select() method on remapping irqdomain x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain x86: Kill all traces of irq_remapping_get_irq_domain() iommu/vt-d: Simplify intel_irq_remapping_select() x86/ioapic: Handle Extended Destination ID field in RTE x86/apic: Support 15 bits of APIC ID in MSI where available iommu/hyper-v: Disable IRQ pseudo-remapping if 15 bit APIC IDs are available x86/kvm: Reserve KVM_FEATURE_MSI_EXT_DEST_ID x86/kvm: Enable 15-bit extension when KVM_FEATURE_MSI_EXT_DEST_ID detected Thomas Gleixner (16): x86/apic/uv: Fix inconsistent destination mode x86/devicetree: Fix the ioapic interrupt type table x86/apic: Cleanup delivery mode defines x86/apic: Replace pointless apic::dest_logical usage x86/apic: Get rid of apic::dest_logical x86/apic: Cleanup destination mode genirq/msi: Allow shadow declarations of msi_msg::$member x86/msi: Provide msi message shadow structs iommu/intel: Use msi_msg shadow structs iommu/amd: Use msi_msg shadow structs PCI: vmd: Use msi_msg shadow structs x86/kvm: Use msi_msg shadow structs x86/pci/xen: Use msi_msg shadow structs x86/msi: Remove msidef.h x86/io_apic: Cleanup trigger/polarity helpers x86/ioapic: Cleanup IO/APIC route entry structs Documentation/virt/kvm/cpuid.rst | 4 + arch/x86/include/asm/apic.h | 16 +- arch/x86/include/asm/apicdef.h| 16 +- arch/x86/include/asm/hpet.h | 11 - arch/x86/include/asm/hw_irq.h | 13 +- arch/x86/include/asm/io_apic.h| 79 ++ arch/x86/include/asm/irq_remapping.h | 9 - arch/x86/include/asm/irqdomain.h | 3 + arch/x86/include/asm/msi.h| 50 arch/x86/include/asm/msidef.h | 57 arch/x86/include/asm/x86_init.h | 2 + arch/x86/include/uapi/asm/kvm_para.h | 1 + arch/x86/kernel/apic/apic.c | 73 - arch/x86/kernel/apic/apic_flat_64.c | 18 +- arch/x86/kernel/apic/apic_noop.c | 10 +- arch/x86/kernel/apic/apic_numachip.c | 16 +- arch/x86/kernel/apic/bigsmp_32.c | 9 +- arch/x86/kernel/apic/io_apic.c| 503 ++ arch/x86/kernel/apic/ipi.c| 6 +- arch/x86/kernel/apic/msi.c| 153 +-- arch/x86/kernel/apic/probe_32.c | 9 +- arch/x86/kernel/apic/vector.c | 49 arch/x86/kernel/apic/x2apic_cluster.c | 10 +- arch/x86/kernel/apic/x2apic_phys.c| 17 +- arch/x86/kernel/apic/x2apic_uv_x.c| 12 +- arch/x86/kernel/devicetree.c | 30 +- arch/x86/kernel/hpet.c| 122 - arch/x86/kernel/kvm.c | 6 + arch/x86/kernel/smpboot.c | 8 +- arch/x86/kernel/x86_init.c| 1 + arch/x86/kvm/irq_comm.c | 31 +-- arch/x86/pci/intel_mid_pci.c | 8 +- arch/x86/pci/xen.c| 26 +- arch/x86/platform/uv/uv_irq.c | 4 +- arch/x86/xen/apic.c | 7 +- drivers/iommu/amd/amd_iommu_types.h | 2 +- drivers/iommu/amd/init.c | 46 ++-- drivers/iommu/amd/iommu.c | 93 +++ drivers/iommu/hyperv-iommu.c
[PATCH v3 03/35] x86/apic/uv: Fix inconsistent destination mode
From: Thomas Gleixner
The UV x2apic is strictly using physical destination mode, but
apic::dest_logical is initialized with APIC_DEST_LOGICAL.
This does not matter much because UV does not use any of the generic
functions which use apic::dest_logical, but is still inconsistent.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/kernel/apic/x2apic_uv_x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 714233cee0b5..9ade9e6a95ff 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -811,7 +811,7 @@ static struct apic apic_x2apic_uv_x __ro_after_init = {
.irq_dest_mode = 0, /* Physical */
.disable_esr= 0,
- .dest_logical = APIC_DEST_LOGICAL,
+ .dest_logical = APIC_DEST_PHYSICAL,
.check_apicid_used = NULL,
.init_apic_ldr = uv_init_apic_ldr,
--
2.26.2
[PATCH v3 02/35] x86/msi: Only use high bits of MSI address for DMAR unit
From: David Woodhouse
The Intel IOMMU has an MSI-like configuration for its interrupt, but it
isn't really MSI. So it gets to abuse the high 32 bits of the address, and
puts the high 24 bits of the extended APIC ID there.
This isn't something that can be used in the general case for real MSIs,
since external devices using the high bits of the address would be
performing writes to actual memory space above 4GiB, not targeted at the
APIC.
Factor the hack out and allow it only to be used when appropriate, adding a
WARN_ON_ONCE() if other MSIs are targeted at an unreachable APIC ID. That
should never happen since the compatibility MSI messages are not used when
Interrupt Remapping is enabled.
The x2apic_enabled() check isn't needed because Linux won't bring up CPUs
with higher APIC IDs unless IR and x2apic are enabled anyway.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/msi.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 6313f0a05db7..516df47bde73 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -23,13 +23,11 @@
struct irq_domain *x86_pci_msi_default_domain __ro_after_init;
-static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg)
+static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
+ bool dmar)
{
msg->address_hi = MSI_ADDR_BASE_HI;
- if (x2apic_enabled())
- msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid);
-
msg->address_lo =
MSI_ADDR_BASE_LO |
((apic->irq_dest_mode == 0) ?
@@ -43,18 +41,29 @@ static void __irq_msi_compose_msg(struct irq_cfg *cfg,
struct msi_msg *msg)
MSI_DATA_LEVEL_ASSERT |
MSI_DATA_DELIVERY_FIXED |
MSI_DATA_VECTOR(cfg->vector);
+
+ /*
+* Only the IOMMU itself can use the trick of putting destination
+* APIC ID into the high bits of the address. Anything else would
+* just be writing to memory if it tried that, and needs IR to
+* address higher APIC IDs.
+*/
+ if (dmar)
+ msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid);
+ else
+ WARN_ON_ONCE(MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid));
}
void x86_vector_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
{
- __irq_msi_compose_msg(irqd_cfg(data), msg);
+ __irq_msi_compose_msg(irqd_cfg(data), msg, false);
}
static void irq_msi_update_msg(struct irq_data *irqd, struct irq_cfg *cfg)
{
struct msi_msg msg[2] = { [1] = { }, };
- __irq_msi_compose_msg(cfg, msg);
+ __irq_msi_compose_msg(cfg, msg, false);
irq_data_get_irq_chip(irqd)->irq_write_msi_msg(irqd, msg);
}
@@ -276,6 +285,17 @@ struct irq_domain *arch_create_remap_msi_irq_domain(struct
irq_domain *parent,
#endif
#ifdef CONFIG_DMAR_TABLE
+/*
+ * The Intel IOMMU (ab)uses the high bits of the MSI address to contain the
+ * high bits of the destination APIC ID. This can't be done in the general
+ * case for MSIs as it would be targeting real memory above 4GiB not the
+ * APIC.
+ */
+static void dmar_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ __irq_msi_compose_msg(irqd_cfg(data), msg, true);
+}
+
static void dmar_msi_write_msg(struct irq_data *data, struct msi_msg *msg)
{
dmar_msi_write(data->irq, msg);
@@ -288,6 +308,7 @@ static struct irq_chip dmar_msi_controller = {
.irq_ack= irq_chip_ack_parent,
.irq_set_affinity = msi_domain_set_affinity,
.irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_compose_msi_msg= dmar_msi_compose_msg,
.irq_write_msi_msg = dmar_msi_write_msg,
.flags = IRQCHIP_SKIP_SET_WAKE,
};
--
2.26.2
[PATCH v3 11/35] genirq/msi: Allow shadow declarations of msi_msg::$member
From: Thomas Gleixner
Architectures like x86 have their MSI messages in various bits of the data,
address_lo and address_hi field. Composing or decomposing these messages
with bitmasks and shifts is possible, but unreadable gunk.
Allow architectures to provide an architecture specific representation for
each member of msi_msg. Provide empty defaults for each and stick them into
an union.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
include/asm-generic/msi.h | 4
include/linux/msi.h | 46 +++
2 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/include/asm-generic/msi.h b/include/asm-generic/msi.h
index e6795f088bdd..25344de0e8f9 100644
--- a/include/asm-generic/msi.h
+++ b/include/asm-generic/msi.h
@@ -4,6 +4,8 @@
#include
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+
#ifndef NUM_MSI_ALLOC_SCRATCHPAD_REGS
# define NUM_MSI_ALLOC_SCRATCHPAD_REGS 2
#endif
@@ -30,4 +32,6 @@ typedef struct msi_alloc_info {
#define GENERIC_MSI_DOMAIN_OPS 1
+#endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
+
#endif
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 6b584cc4757c..360a0a7e7341 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -4,11 +4,50 @@
#include
#include
+#include
+
+/* Dummy shadow structures if an architecture does not define them */
+#ifndef arch_msi_msg_addr_lo
+typedef struct arch_msi_msg_addr_lo {
+ u32 address_lo;
+} __attribute__ ((packed)) arch_msi_msg_addr_lo_t;
+#endif
+
+#ifndef arch_msi_msg_addr_hi
+typedef struct arch_msi_msg_addr_hi {
+ u32 address_hi;
+} __attribute__ ((packed)) arch_msi_msg_addr_hi_t;
+#endif
+
+#ifndef arch_msi_msg_data
+typedef struct arch_msi_msg_data {
+ u32 data;
+} __attribute__ ((packed)) arch_msi_msg_data_t;
+#endif
+/**
+ * msi_msg - Representation of a MSI message
+ * @address_lo:Low 32 bits of msi message address
+ * @arch_addrlo: Architecture specific shadow of @address_lo
+ * @address_hi:High 32 bits of msi message address
+ * (only used when device supports it)
+ * @arch_addrhi: Architecture specific shadow of @address_hi
+ * @data: MSI message data (usually 16 bits)
+ * @arch_data: Architecture specific shadow of @data
+ */
struct msi_msg {
- u32 address_lo; /* low 32 bits of msi message address */
- u32 address_hi; /* high 32 bits of msi message address */
- u32 data; /* 16 bits of msi message data */
+ union {
+ u32 address_lo;
+ arch_msi_msg_addr_lo_t arch_addr_lo;
+ };
+ union {
+ u32 address_hi;
+ arch_msi_msg_addr_hi_t arch_addr_hi;
+ };
+ union {
+ u32 data;
+ arch_msi_msg_data_t arch_data;
+ };
};
extern int pci_msi_ignore_mask;
@@ -243,7 +282,6 @@ struct msi_controller {
#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
#include
-#include
struct irq_domain;
struct irq_domain_ops;
--
2.26.2
[PATCH v3 06/35] x86/apic: Replace pointless apic::dest_logical usage
From: Thomas Gleixner All these functions are only used for logical destination mode. So reading the destination mode mask from the apic structure is a pointless exercise. Just hand in the proper constant: APIC_DEST_LOGICAL. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/kernel/apic/apic_flat_64.c | 2 +- arch/x86/kernel/apic/ipi.c| 6 +++--- arch/x86/kernel/apic/x2apic_cluster.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/apic/apic_flat_64.c b/arch/x86/kernel/apic/apic_flat_64.c index fdd38a17f835..6df837fd5081 100644 --- a/arch/x86/kernel/apic/apic_flat_64.c +++ b/arch/x86/kernel/apic/apic_flat_64.c @@ -53,7 +53,7 @@ static void _flat_send_IPI_mask(unsigned long mask, int vector) unsigned long flags; local_irq_save(flags); - __default_send_IPI_dest_field(mask, vector, apic->dest_logical); + __default_send_IPI_dest_field(mask, vector, APIC_DEST_LOGICAL); local_irq_restore(flags); } diff --git a/arch/x86/kernel/apic/ipi.c b/arch/x86/kernel/apic/ipi.c index 387154e39e08..d1fb874fbe64 100644 --- a/arch/x86/kernel/apic/ipi.c +++ b/arch/x86/kernel/apic/ipi.c @@ -260,7 +260,7 @@ void default_send_IPI_mask_sequence_logical(const struct cpumask *mask, for_each_cpu(query_cpu, mask) __default_send_IPI_dest_field( early_per_cpu(x86_cpu_to_logical_apicid, query_cpu), - vector, apic->dest_logical); + vector, APIC_DEST_LOGICAL); local_irq_restore(flags); } @@ -279,7 +279,7 @@ void default_send_IPI_mask_allbutself_logical(const struct cpumask *mask, continue; __default_send_IPI_dest_field( early_per_cpu(x86_cpu_to_logical_apicid, query_cpu), - vector, apic->dest_logical); + vector, APIC_DEST_LOGICAL); } local_irq_restore(flags); } @@ -297,7 +297,7 @@ void default_send_IPI_mask_logical(const struct cpumask *cpumask, int vector) local_irq_save(flags); WARN_ON(mask & ~cpumask_bits(cpu_online_mask)[0]); - __default_send_IPI_dest_field(mask, vector, apic->dest_logical); + __default_send_IPI_dest_field(mask, vector, APIC_DEST_LOGICAL); local_irq_restore(flags); } diff --git a/arch/x86/kernel/apic/x2apic_cluster.c b/arch/x86/kernel/apic/x2apic_cluster.c index 82fb43d807f7..f77e9fb7aac1 100644 --- a/arch/x86/kernel/apic/x2apic_cluster.c +++ b/arch/x86/kernel/apic/x2apic_cluster.c @@ -61,7 +61,7 @@ __x2apic_send_IPI_mask(const struct cpumask *mask, int vector, int apic_dest) if (!dest) continue; - __x2apic_send_IPI_dest(dest, vector, apic->dest_logical); + __x2apic_send_IPI_dest(dest, vector, APIC_DEST_LOGICAL); /* Remove cluster CPUs from tmpmask */ cpumask_andnot(tmpmsk, tmpmsk, >mask); } -- 2.26.2
[PATCH v3 09/35] x86/apic: Always provide irq_compose_msi_msg() method for vector domain
From: David Woodhouse
This shouldn't be dependent on PCI_MSI. HPET and I/O-APIC can deliver
interrupts through MSI without having any PCI in the system at all.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/apic.h | 8 +++-
arch/x86/kernel/apic/apic.c | 32 ++
arch/x86/kernel/apic/msi.c| 37 ---
arch/x86/kernel/apic/vector.c | 6 ++
4 files changed, 41 insertions(+), 42 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 652f62252349..b489bb9894ae 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -520,12 +520,10 @@ static inline void apic_smt_update(void) { }
#endif
struct msi_msg;
+struct irq_cfg;
-#ifdef CONFIG_PCI_MSI
-void x86_vector_msi_compose_msg(struct irq_data *data, struct msi_msg *msg);
-#else
-# define x86_vector_msi_compose_msg NULL
-#endif
+extern void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
+ bool dmar);
extern void ioapic_zap_locks(void);
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 54f04355aaa2..4c15bf29ea2c 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2480,6 +2481,37 @@ int hard_smp_processor_id(void)
return read_apic_id();
}
+void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
+ bool dmar)
+{
+ msg->address_hi = MSI_ADDR_BASE_HI;
+
+ msg->address_lo =
+ MSI_ADDR_BASE_LO |
+ (apic->dest_mode_logical ?
+ MSI_ADDR_DEST_MODE_LOGICAL :
+ MSI_ADDR_DEST_MODE_PHYSICAL) |
+ MSI_ADDR_REDIRECTION_CPU |
+ MSI_ADDR_DEST_ID(cfg->dest_apicid);
+
+ msg->data =
+ MSI_DATA_TRIGGER_EDGE |
+ MSI_DATA_LEVEL_ASSERT |
+ MSI_DATA_DELIVERY_FIXED |
+ MSI_DATA_VECTOR(cfg->vector);
+
+ /*
+* Only the IOMMU itself can use the trick of putting destination
+* APIC ID into the high bits of the address. Anything else would
+* just be writing to memory if it tried that, and needs IR to
+* address higher APIC IDs.
+*/
+ if (dmar)
+ msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid);
+ else
+ WARN_ON_ONCE(MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid));
+}
+
/*
* Override the generic EOI implementation with an optimized version.
* Only called during early boot when only one CPU is active and with
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 46ffd41a4238..4eda617eda1e 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -23,42 +22,6 @@
struct irq_domain *x86_pci_msi_default_domain __ro_after_init;
-static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
- bool dmar)
-{
- msg->address_hi = MSI_ADDR_BASE_HI;
-
- msg->address_lo =
- MSI_ADDR_BASE_LO |
- (apic->dest_mode_logical ?
- MSI_ADDR_DEST_MODE_LOGICAL :
- MSI_ADDR_DEST_MODE_PHYSICAL) |
- MSI_ADDR_REDIRECTION_CPU |
- MSI_ADDR_DEST_ID(cfg->dest_apicid);
-
- msg->data =
- MSI_DATA_TRIGGER_EDGE |
- MSI_DATA_LEVEL_ASSERT |
- MSI_DATA_DELIVERY_FIXED |
- MSI_DATA_VECTOR(cfg->vector);
-
- /*
-* Only the IOMMU itself can use the trick of putting destination
-* APIC ID into the high bits of the address. Anything else would
-* just be writing to memory if it tried that, and needs IR to
-* address higher APIC IDs.
-*/
- if (dmar)
- msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid);
- else
- WARN_ON_ONCE(MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid));
-}
-
-void x86_vector_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
-{
- __irq_msi_compose_msg(irqd_cfg(data), msg, false);
-}
-
static void irq_msi_update_msg(struct irq_data *irqd, struct irq_cfg *cfg)
{
struct msi_msg msg[2] = { [1] = { }, };
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 1eac53632786..bb2e2a2488a5 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -818,6 +818,12 @@ void apic_ack_edge(struct irq_data *irqd)
apic_ack_irq(irqd);
}
+static void x86_vector_msi_compose_msg(struct irq_data *data,
+ struct msi_msg *msg)
+{
+ __irq_msi_compose_msg(irqd_cfg(data), msg, false);
+}
+
static struct
[PATCH v3 01/35] x86/apic: Fix x2apic enablement without interrupt remapping
From: David Woodhouse
Currently, Linux as a hypervisor guest will enable x2apic only if there are
no CPUs present at boot time with an APIC ID above 255.
Hotplugging a CPU later with a higher APIC ID would result in a CPU which
cannot be targeted by external interrupts.
Add a filter in x2apic_apic_id_valid() which can be used to prevent such
CPUs from coming online, and allow x2apic to be enabled even if they are
present at boot time.
Fixes: ce69a784504 ("x86/apic: Enable x2APIC without interrupt remapping under
KVM")
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/apic.h| 1 +
arch/x86/kernel/apic/apic.c| 14 --
arch/x86/kernel/apic/x2apic_phys.c | 9 +
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 1c129abb7f09..b0fd204e0023 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -259,6 +259,7 @@ static inline u64 native_x2apic_icr_read(void)
extern int x2apic_mode;
extern int x2apic_phys;
+extern void __init x2apic_set_max_apicid(u32 apicid);
extern void __init check_x2apic(void);
extern void x2apic_setup(void);
static inline int x2apic_enabled(void)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b3eef1d5c903..113f6ca7b828 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1841,20 +1841,22 @@ static __init void try_to_enable_x2apic(int remap_mode)
return;
if (remap_mode != IRQ_REMAP_X2APIC_MODE) {
- /* IR is required if there is APIC ID > 255 even when running
-* under KVM
+ /*
+* Using X2APIC without IR is not architecturally supported
+* on bare metal but may be supported in guests.
*/
- if (max_physical_apicid > 255 ||
- !x86_init.hyper.x2apic_available()) {
+ if (!x86_init.hyper.x2apic_available()) {
pr_info("x2apic: IRQ remapping doesn't support X2APIC
mode\n");
x2apic_disable();
return;
}
/*
-* without IR all CPUs can be addressed by IOAPIC/MSI
-* only in physical mode
+* Without IR, all CPUs can be addressed by IOAPIC/MSI only
+* in physical mode, and CPUs with an APIC ID that cannnot
+* be addressed must not be brought online.
*/
+ x2apic_set_max_apicid(255);
x2apic_phys = 1;
}
x2apic_enable();
diff --git a/arch/x86/kernel/apic/x2apic_phys.c
b/arch/x86/kernel/apic/x2apic_phys.c
index bc9693841353..e14eae6d6ea7 100644
--- a/arch/x86/kernel/apic/x2apic_phys.c
+++ b/arch/x86/kernel/apic/x2apic_phys.c
@@ -8,6 +8,12 @@
int x2apic_phys;
static struct apic apic_x2apic_phys;
+static u32 x2apic_max_apicid __ro_after_init;
+
+void __init x2apic_set_max_apicid(u32 apicid)
+{
+ x2apic_max_apicid = apicid;
+}
static int __init set_x2apic_phys_mode(char *arg)
{
@@ -98,6 +104,9 @@ static int x2apic_phys_probe(void)
/* Common x2apic functions, also used by x2apic_cluster */
int x2apic_apic_id_valid(u32 apicid)
{
+ if (x2apic_max_apicid && apicid > x2apic_max_apicid)
+ return 0;
+
return 1;
}
--
2.26.2
[PATCH v3 16/35] x86/kvm: Use msi_msg shadow structs
From: Thomas Gleixner
Use the bitfields in the x86 shadow structs instead of decomposing the
32bit value with macros.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/kvm/irq_comm.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
index 4aa1c2e00e2a..8a4de3f12820 100644
--- a/arch/x86/kvm/irq_comm.c
+++ b/arch/x86/kvm/irq_comm.c
@@ -16,8 +16,6 @@
#include
-#include
-
#include "irq.h"
#include "ioapic.h"
@@ -104,22 +102,19 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
kvm_lapic *src,
void kvm_set_msi_irq(struct kvm *kvm, struct kvm_kernel_irq_routing_entry *e,
struct kvm_lapic_irq *irq)
{
- trace_kvm_msi_set_irq(e->msi.address_lo | (kvm->arch.x2apic_format ?
-(u64)e->msi.address_hi << 32 : 0),
- e->msi.data);
-
- irq->dest_id = (e->msi.address_lo &
- MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
- if (kvm->arch.x2apic_format)
- irq->dest_id |= MSI_ADDR_EXT_DEST_ID(e->msi.address_hi);
- irq->vector = (e->msi.data &
- MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
- irq->dest_mode = kvm_lapic_irq_dest_mode(
- !!((1 << MSI_ADDR_DEST_MODE_SHIFT) & e->msi.address_lo));
- irq->trig_mode = (1 << MSI_DATA_TRIGGER_SHIFT) & e->msi.data;
- irq->delivery_mode = e->msi.data & 0x700;
- irq->msi_redir_hint = ((e->msi.address_lo
- & MSI_ADDR_REDIRECTION_LOWPRI) > 0);
+ struct msi_msg msg = { .address_lo = e->msi.address_lo,
+ .address_hi = e->msi.address_hi,
+ .data = e->msi.data };
+
+ trace_kvm_msi_set_irq(msg.address_lo | (kvm->arch.x2apic_format ?
+ (u64)msg.address_hi << 32 : 0), msg.data);
+
+ irq->dest_id = x86_msi_msg_get_destid(, kvm->arch.x2apic_format);
+ irq->vector = msg.arch_data.vector;
+ irq->dest_mode =
kvm_lapic_irq_dest_mode(msg.arch_addr_lo.dest_mode_logical);
+ irq->trig_mode = msg.arch_data.is_level;
+ irq->delivery_mode = msg.arch_data.delivery_mode << 8;
+ irq->msi_redir_hint = msg.arch_addr_lo.redirect_hint;
irq->level = 1;
irq->shorthand = APIC_DEST_NOSHORT;
}
--
2.26.2
[PATCH v3 08/35] x86/apic: Cleanup destination mode
From: Thomas Gleixner
apic::irq_dest_mode is actually a boolean, but defined as u32 and named in
a way which does not explain what it means.
Make it a boolean and rename it to 'dest_mode_logical'
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/apic.h | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apic/apic_flat_64.c | 4 ++--
arch/x86/kernel/apic/apic_noop.c | 4 +---
arch/x86/kernel/apic/apic_numachip.c | 4 ++--
arch/x86/kernel/apic/bigsmp_32.c | 3 +--
arch/x86/kernel/apic/io_apic.c| 2 +-
arch/x86/kernel/apic/msi.c| 6 +++---
arch/x86/kernel/apic/probe_32.c | 3 +--
arch/x86/kernel/apic/x2apic_cluster.c | 2 +-
arch/x86/kernel/apic/x2apic_phys.c| 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c| 2 +-
arch/x86/kernel/smpboot.c | 7 ++-
arch/x86/platform/uv/uv_irq.c | 2 +-
arch/x86/xen/apic.c | 3 +--
drivers/iommu/amd/amd_iommu_types.h | 2 +-
drivers/iommu/amd/iommu.c | 8
drivers/iommu/intel/irq_remapping.c | 2 +-
18 files changed, 26 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 019d7ac3b16e..652f62252349 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -309,7 +309,7 @@ struct apic {
u32 disable_esr;
enum apic_delivery_modes delivery_mode;
- u32 irq_dest_mode;
+ booldest_mode_logical;
u32 (*calc_dest_apicid)(unsigned int cpu);
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 29d28b34cb2f..54f04355aaa2 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1591,7 +1591,7 @@ static void setup_local_APIC(void)
apic->init_apic_ldr();
#ifdef CONFIG_X86_32
- if (apic->irq_dest_mode == 1) {
+ if (apic->dest_mode_logical) {
int logical_apicid, ldr_apicid;
/*
diff --git a/arch/x86/kernel/apic/apic_flat_64.c
b/arch/x86/kernel/apic/apic_flat_64.c
index bbb1b89fe711..8f72b4351c9f 100644
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -114,7 +114,7 @@ static struct apic apic_flat __ro_after_init = {
.apic_id_registered = flat_apic_id_registered,
.delivery_mode = APIC_DELIVERY_MODE_FIXED,
- .irq_dest_mode = 1, /* logical */
+ .dest_mode_logical = true,
.disable_esr= 0,
@@ -205,7 +205,7 @@ static struct apic apic_physflat __ro_after_init = {
.apic_id_registered = flat_apic_id_registered,
.delivery_mode = APIC_DELIVERY_MODE_FIXED,
- .irq_dest_mode = 0, /* physical */
+ .dest_mode_logical = false,
.disable_esr= 0,
diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c
index 38f167ce5031..fe78319e0f7a 100644
--- a/arch/x86/kernel/apic/apic_noop.c
+++ b/arch/x86/kernel/apic/apic_noop.c
@@ -96,8 +96,7 @@ struct apic apic_noop __ro_after_init = {
.apic_id_registered = noop_apic_id_registered,
.delivery_mode = APIC_DELIVERY_MODE_FIXED,
- /* logical delivery broadcast to all CPUs: */
- .irq_dest_mode = 1,
+ .dest_mode_logical = true,
.disable_esr= 0,
@@ -105,7 +104,6 @@ struct apic apic_noop __ro_after_init = {
.init_apic_ldr = noop_init_apic_ldr,
.ioapic_phys_id_map = default_ioapic_phys_id_map,
.setup_apic_routing = NULL,
-
.cpu_present_to_apicid = default_cpu_present_to_apicid,
.apicid_to_cpu_present = physid_set_mask_of_physid,
diff --git a/arch/x86/kernel/apic/apic_numachip.c
b/arch/x86/kernel/apic/apic_numachip.c
index 4ebf9fe2c95d..a54d817eb4b6 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -247,7 +247,7 @@ static const struct apic apic_numachip1 __refconst = {
.apic_id_registered = numachip_apic_id_registered,
.delivery_mode = APIC_DELIVERY_MODE_FIXED,
- .irq_dest_mode = 0, /* physical */
+ .dest_mode_logical = false,
.disable_esr= 0,
@@ -294,7 +294,7 @@ static const struct apic apic_numachip2 __refconst = {
.apic_id_registered = numachip_apic_id_registered,
.delivery_mode = APIC_DELIVERY_MODE_FIXED,
- .irq_dest_mode = 0, /* physical */
+ .dest_mode_logical = false,
.disable_esr= 0,
diff --git a/arch/x86/kernel/apic/bigsmp_32.c b/arch/x86/kernel/apic/bigsmp_32.c
[PATCH v3 12/35] x86/msi: Provide msi message shadow structs
From: Thomas Gleixner
Create shadow structs with named bitfields for msi_msg data, address_lo and
address_hi and use them in the MSI message composer.
Provide a function to retrieve the destination ID. This could be inline,
but that'd create a circular header dependency.
[dwmw2: fix bitfields not all to be a union]
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/msi.h | 49 +
arch/x86/kernel/apic/apic.c | 35 ++
2 files changed, 68 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index cd30013d15d3..322fd905da9c 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -9,4 +9,53 @@ typedef struct irq_alloc_info msi_alloc_info_t;
int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
msi_alloc_info_t *arg);
+/* Structs and defines for the X86 specific MSI message format */
+
+typedef struct x86_msi_data {
+ u32 vector : 8,
+ delivery_mode : 3,
+ dest_mode_logical : 1,
+ reserved: 2,
+ active_low : 1,
+ is_level: 1;
+
+ u32 dmar_subhandle;
+} __attribute__ ((packed)) arch_msi_msg_data_t;
+#define arch_msi_msg_data x86_msi_data
+
+typedef struct x86_msi_addr_lo {
+ union {
+ struct {
+ u32 reserved_0 : 2,
+ dest_mode_logical : 1,
+ redirect_hint : 1,
+ reserved_1 : 8,
+ destid_0_7 : 8,
+ base_address: 12;
+ };
+ struct {
+ u32 dmar_reserved_0 : 2,
+ dmar_index_15 : 1,
+ dmar_subhandle_valid: 1,
+ dmar_format : 1,
+ dmar_index_0_14 : 15,
+ dmar_base_address : 12;
+ };
+ };
+} __attribute__ ((packed)) arch_msi_msg_addr_lo_t;
+#define arch_msi_msg_addr_lo x86_msi_addr_lo
+
+#define X86_MSI_BASE_ADDRESS_LOW (0xfee0 >> 20)
+
+typedef struct x86_msi_addr_hi {
+ u32 reserved: 8,
+ destid_8_31 : 24;
+} __attribute__ ((packed)) arch_msi_msg_addr_hi_t;
+#define arch_msi_msg_addr_hi x86_msi_addr_hi
+
+#define X86_MSI_BASE_ADDRESS_HIGH (0)
+
+struct msi_msg;
+u32 x86_msi_msg_get_destid(struct msi_msg *msg, bool extid);
+
#endif /* _ASM_X86_MSI_H */
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 4c15bf29ea2c..f7196ee0f005 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -50,7 +50,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -2484,22 +2483,16 @@ int hard_smp_processor_id(void)
void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
bool dmar)
{
- msg->address_hi = MSI_ADDR_BASE_HI;
+ memset(msg, 0, sizeof(*msg));
- msg->address_lo =
- MSI_ADDR_BASE_LO |
- (apic->dest_mode_logical ?
- MSI_ADDR_DEST_MODE_LOGICAL :
- MSI_ADDR_DEST_MODE_PHYSICAL) |
- MSI_ADDR_REDIRECTION_CPU |
- MSI_ADDR_DEST_ID(cfg->dest_apicid);
+ msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW;
+ msg->arch_addr_lo.dest_mode_logical = apic->dest_mode_logical;
+ msg->arch_addr_lo.destid_0_7 = cfg->dest_apicid & 0xFF;
- msg->data =
- MSI_DATA_TRIGGER_EDGE |
- MSI_DATA_LEVEL_ASSERT |
- MSI_DATA_DELIVERY_FIXED |
- MSI_DATA_VECTOR(cfg->vector);
+ msg->arch_data.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+ msg->arch_data.vector = cfg->vector;
+ msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
/*
* Only the IOMMU itself can use the trick of putting destination
* APIC ID into the high bits of the address. Anything else would
@@ -2507,11 +2500,21 @@ void __irq_msi_compose_msg(struct irq_cfg *cfg, struct
msi_msg *msg,
* address higher APIC IDs.
*/
if (dmar)
- msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid);
+ msg->arch_addr_hi.destid_8_31 = cfg->dest_apicid >> 8;
else
- WARN_ON_ONCE(MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid));
+ WARN_ON_ONCE(cfg->dest_apicid > 0xFF);
}
+u32 x86_msi_msg_get_destid(struct msi_msg *msg, bool extid)
+{
+ u32 dest = msg->arch_addr_lo.destid_0_7;
+
+
[PATCH v3 28/35] x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain
From: David Woodhouse
All possible parent domains have a select method now. Make use of it.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/io_apic.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index ea983da1a57f..443d2c9086b9 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2320,36 +2320,37 @@ static inline void __init check_timer(void)
static int mp_irqdomain_create(int ioapic)
{
- struct irq_alloc_info info;
struct irq_domain *parent;
int hwirqs = mp_ioapic_pin_count(ioapic);
struct ioapic *ip = [ioapic];
struct ioapic_domain_cfg *cfg = >irqdomain_cfg;
struct mp_ioapic_gsi *gsi_cfg = mp_ioapic_gsi_routing(ioapic);
struct fwnode_handle *fn;
- char *name = "IO-APIC";
+ struct irq_fwspec fwspec;
if (cfg->type == IOAPIC_DOMAIN_INVALID)
return 0;
- init_irq_alloc_info(, NULL);
- info.type = X86_IRQ_ALLOC_TYPE_IOAPIC_GET_PARENT;
- info.devid = mpc_ioapic_id(ioapic);
- parent = irq_remapping_get_irq_domain();
- if (!parent)
- parent = x86_vector_domain;
- else
- name = "IO-APIC-IR";
-
/* Handle device tree enumerated APICs proper */
if (cfg->dev) {
fn = of_node_to_fwnode(cfg->dev);
} else {
- fn = irq_domain_alloc_named_id_fwnode(name, ioapic);
+ fn = irq_domain_alloc_named_id_fwnode("IO-APIC", ioapic);
if (!fn)
return -ENOMEM;
}
+ fwspec.fwnode = fn;
+ fwspec.param_count = 1;
+ fwspec.param[0] = ioapic;
+
+ parent = irq_find_matching_fwspec(, DOMAIN_BUS_ANY);
+ if (!parent) {
+ if (!cfg->dev)
+ irq_domain_free_fwnode(fn);
+ return -ENODEV;
+ }
+
ip->irqdomain = irq_domain_create_linear(fn, hwirqs, cfg->ops,
(void *)(long)ioapic);
--
2.26.2
[PATCH v3 05/35] x86/apic: Cleanup delivery mode defines
From: Thomas Gleixner
The enum ioapic_irq_destination_types and the enumerated constants starting
with 'dest_' are gross misnomers because they describe the delivery mode.
Rename then enum and the constants so they actually make sense.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/apic.h | 3 ++-
arch/x86/include/asm/apicdef.h| 16 +++-
arch/x86/kernel/apic/apic_flat_64.c | 4 ++--
arch/x86/kernel/apic/apic_noop.c | 2 +-
arch/x86/kernel/apic/apic_numachip.c | 4 ++--
arch/x86/kernel/apic/bigsmp_32.c | 2 +-
arch/x86/kernel/apic/io_apic.c| 11 ++-
arch/x86/kernel/apic/probe_32.c | 2 +-
arch/x86/kernel/apic/x2apic_cluster.c | 2 +-
arch/x86/kernel/apic/x2apic_phys.c| 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c| 6 +++---
arch/x86/platform/uv/uv_irq.c | 2 +-
drivers/iommu/amd/iommu.c | 4 ++--
drivers/iommu/intel/irq_remapping.c | 2 +-
drivers/pci/controller/pci-hyperv.c | 6 +++---
15 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index b0fd204e0023..53bb62e0fdd5 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -309,7 +309,8 @@ struct apic {
/* dest_logical is used by the IPI functions */
u32 dest_logical;
u32 disable_esr;
- u32 irq_delivery_mode;
+
+ enum apic_delivery_modes delivery_mode;
u32 irq_dest_mode;
u32 (*calc_dest_apicid)(unsigned int cpu);
diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
index 05e694ed8386..5716f22f81ac 100644
--- a/arch/x86/include/asm/apicdef.h
+++ b/arch/x86/include/asm/apicdef.h
@@ -432,15 +432,13 @@ struct local_apic {
#define BAD_APICID 0xu
#endif
-enum ioapic_irq_destination_types {
- dest_Fixed = 0,
- dest_LowestPrio = 1,
- dest_SMI= 2,
- dest__reserved_1= 3,
- dest_NMI= 4,
- dest_INIT = 5,
- dest__reserved_2= 6,
- dest_ExtINT = 7
+enum apic_delivery_modes {
+ APIC_DELIVERY_MODE_FIXED= 0,
+ APIC_DELIVERY_MODE_LOWESTPRIO = 1,
+ APIC_DELIVERY_MODE_SMI = 2,
+ APIC_DELIVERY_MODE_NMI = 4,
+ APIC_DELIVERY_MODE_INIT = 5,
+ APIC_DELIVERY_MODE_EXTINT = 7,
};
#endif /* _ASM_X86_APICDEF_H */
diff --git a/arch/x86/kernel/apic/apic_flat_64.c
b/arch/x86/kernel/apic/apic_flat_64.c
index 7862b152a052..fdd38a17f835 100644
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -113,7 +113,7 @@ static struct apic apic_flat __ro_after_init = {
.apic_id_valid = default_apic_id_valid,
.apic_id_registered = flat_apic_id_registered,
- .irq_delivery_mode = dest_Fixed,
+ .delivery_mode = APIC_DELIVERY_MODE_FIXED,
.irq_dest_mode = 1, /* logical */
.disable_esr= 0,
@@ -206,7 +206,7 @@ static struct apic apic_physflat __ro_after_init = {
.apic_id_valid = default_apic_id_valid,
.apic_id_registered = flat_apic_id_registered,
- .irq_delivery_mode = dest_Fixed,
+ .delivery_mode = APIC_DELIVERY_MODE_FIXED,
.irq_dest_mode = 0, /* physical */
.disable_esr= 0,
diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c
index 780c702969b7..4fc934b11851 100644
--- a/arch/x86/kernel/apic/apic_noop.c
+++ b/arch/x86/kernel/apic/apic_noop.c
@@ -95,7 +95,7 @@ struct apic apic_noop __ro_after_init = {
.apic_id_valid = default_apic_id_valid,
.apic_id_registered = noop_apic_id_registered,
- .irq_delivery_mode = dest_Fixed,
+ .delivery_mode = APIC_DELIVERY_MODE_FIXED,
/* logical delivery broadcast to all CPUs: */
.irq_dest_mode = 1,
diff --git a/arch/x86/kernel/apic/apic_numachip.c
b/arch/x86/kernel/apic/apic_numachip.c
index 35edd57f064a..db715d082ec9 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -246,7 +246,7 @@ static const struct apic apic_numachip1 __refconst = {
.apic_id_valid = numachip_apic_id_valid,
.apic_id_registered = numachip_apic_id_registered,
- .irq_delivery_mode = dest_Fixed,
+ .delivery_mode = APIC_DELIVERY_MODE_FIXED,
.irq_dest_mode = 0, /* physical */
.disable_esr= 0,
@@ -295,7 +295,7 @@ static const struct apic apic_numachip2 __refconst = {
.apic_id_valid
[PATCH v3 10/35] x86/hpet: Move MSI support into hpet.c
From: David Woodhouse
This isn't really dependent on PCI MSI; it's just generic MSI which is now
supported by the generic x86_vector_domain. Move the HPET MSI support back
into hpet.c with the rest of the HPET support.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hpet.h | 11
arch/x86/kernel/apic/msi.c | 111 -
arch/x86/kernel/hpet.c | 118 ++--
3 files changed, 112 insertions(+), 128 deletions(-)
diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
index 6352dee37cda..ab9f3dd87c80 100644
--- a/arch/x86/include/asm/hpet.h
+++ b/arch/x86/include/asm/hpet.h
@@ -74,17 +74,6 @@ extern void hpet_disable(void);
extern unsigned int hpet_readl(unsigned int a);
extern void force_hpet_resume(void);
-struct irq_data;
-struct hpet_channel;
-struct irq_domain;
-
-extern void hpet_msi_unmask(struct irq_data *data);
-extern void hpet_msi_mask(struct irq_data *data);
-extern void hpet_msi_write(struct hpet_channel *hc, struct msi_msg *msg);
-extern struct irq_domain *hpet_create_irq_domain(int hpet_id);
-extern int hpet_assign_irq(struct irq_domain *domain,
- struct hpet_channel *hc, int dev_num);
-
#ifdef CONFIG_HPET_EMULATE_RTC
#include
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 4eda617eda1e..44ebe25e7703 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -340,114 +340,3 @@ void dmar_free_hwirq(int irq)
irq_domain_free_irqs(irq, 1);
}
#endif
-
-/*
- * MSI message composition
- */
-#ifdef CONFIG_HPET_TIMER
-static inline int hpet_dev_id(struct irq_domain *domain)
-{
- struct msi_domain_info *info = msi_get_domain_info(domain);
-
- return (int)(long)info->data;
-}
-
-static void hpet_msi_write_msg(struct irq_data *data, struct msi_msg *msg)
-{
- hpet_msi_write(irq_data_get_irq_handler_data(data), msg);
-}
-
-static struct irq_chip hpet_msi_controller __ro_after_init = {
- .name = "HPET-MSI",
- .irq_unmask = hpet_msi_unmask,
- .irq_mask = hpet_msi_mask,
- .irq_ack = irq_chip_ack_parent,
- .irq_set_affinity = msi_domain_set_affinity,
- .irq_retrigger = irq_chip_retrigger_hierarchy,
- .irq_write_msi_msg = hpet_msi_write_msg,
- .flags = IRQCHIP_SKIP_SET_WAKE,
-};
-
-static int hpet_msi_init(struct irq_domain *domain,
-struct msi_domain_info *info, unsigned int virq,
-irq_hw_number_t hwirq, msi_alloc_info_t *arg)
-{
- irq_set_status_flags(virq, IRQ_MOVE_PCNTXT);
- irq_domain_set_info(domain, virq, arg->hwirq, info->chip, NULL,
- handle_edge_irq, arg->data, "edge");
-
- return 0;
-}
-
-static void hpet_msi_free(struct irq_domain *domain,
- struct msi_domain_info *info, unsigned int virq)
-{
- irq_clear_status_flags(virq, IRQ_MOVE_PCNTXT);
-}
-
-static struct msi_domain_ops hpet_msi_domain_ops = {
- .msi_init = hpet_msi_init,
- .msi_free = hpet_msi_free,
-};
-
-static struct msi_domain_info hpet_msi_domain_info = {
- .ops= _msi_domain_ops,
- .chip = _msi_controller,
- .flags = MSI_FLAG_USE_DEF_DOM_OPS,
-};
-
-struct irq_domain *hpet_create_irq_domain(int hpet_id)
-{
- struct msi_domain_info *domain_info;
- struct irq_domain *parent, *d;
- struct irq_alloc_info info;
- struct fwnode_handle *fn;
-
- if (x86_vector_domain == NULL)
- return NULL;
-
- domain_info = kzalloc(sizeof(*domain_info), GFP_KERNEL);
- if (!domain_info)
- return NULL;
-
- *domain_info = hpet_msi_domain_info;
- domain_info->data = (void *)(long)hpet_id;
-
- init_irq_alloc_info(, NULL);
- info.type = X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT;
- info.devid = hpet_id;
- parent = irq_remapping_get_irq_domain();
- if (parent == NULL)
- parent = x86_vector_domain;
- else
- hpet_msi_controller.name = "IR-HPET-MSI";
-
- fn = irq_domain_alloc_named_id_fwnode(hpet_msi_controller.name,
- hpet_id);
- if (!fn) {
- kfree(domain_info);
- return NULL;
- }
-
- d = msi_create_irq_domain(fn, domain_info, parent);
- if (!d) {
- irq_domain_free_fwnode(fn);
- kfree(domain_info);
- }
- return d;
-}
-
-int hpet_assign_irq(struct irq_domain *domain, struct hpet_channel *hc,
- int dev_num)
-{
- struct irq_alloc_info info;
-
- init_irq_alloc_info(, NULL);
- info.type = X86_IRQ_ALLOC_TYPE_HPET;
- info.data = hc;
- info.devid = hpet_dev_id(domain);
- info.hwirq = dev_num;
-
- return irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, );
-}
-#endif
diff --git
[PATCH v3 22/35] genirq/irqdomain: Implement get_name() method on irqchip fwnodes
From: David Woodhouse
Prerequesite to make x86 more irqdomain compliant.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdomain.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index cf8b374b892d..673fa64c1c44 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -42,7 +42,16 @@ static inline void debugfs_add_domain_dir(struct irq_domain
*d) { }
static inline void debugfs_remove_domain_dir(struct irq_domain *d) { }
#endif
-const struct fwnode_operations irqchip_fwnode_ops;
+static const char *irqchip_fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+ struct irqchip_fwid *fwid = container_of(fwnode, struct irqchip_fwid,
fwnode);
+
+ return fwid->name;
+}
+
+const struct fwnode_operations irqchip_fwnode_ops = {
+ .get_name = irqchip_fwnode_get_name,
+};
EXPORT_SYMBOL_GPL(irqchip_fwnode_ops);
/**
--
2.26.2
[PATCH v3 15/35] PCI: vmd: Use msi_msg shadow structs
From: Thomas Gleixner Use the x86 shadow structs in msi_msg instead of the macros. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- drivers/pci/controller/vmd.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index aa1b12bac9a1..72de3c6f644e 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -18,7 +18,6 @@ #include #include #include -#include #define VMD_CFGBAR 0 #define VMD_MEMBAR12 @@ -131,10 +130,10 @@ static void vmd_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) struct vmd_irq_list *irq = vmdirq->irq; struct vmd_dev *vmd = irq_data_get_irq_handler_data(data); - msg->address_hi = MSI_ADDR_BASE_HI; - msg->address_lo = MSI_ADDR_BASE_LO | - MSI_ADDR_DEST_ID(index_from_irqs(vmd, irq)); - msg->data = 0; + memset(, 0, sizeof(*msg); + msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH; + msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW; + msg->arch_addr_lo.destid_0_7 = index_from_irqs(vmd, irq); } /* -- 2.26.2
[PATCH v3 13/35] iommu/intel: Use msi_msg shadow structs
From: Thomas Gleixner
Use the bitfields in the x86 shadow struct to compose the MSI message.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
drivers/iommu/intel/irq_remapping.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index 5628d43b795e..30269b738fa5 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include "../irq_remapping.h"
@@ -1260,6 +1259,21 @@ static struct irq_chip intel_ir_chip = {
.irq_set_vcpu_affinity = intel_ir_set_vcpu_affinity,
};
+static void fill_msi_msg(struct msi_msg *msg, u32 index, u32 subhandle)
+{
+ memset(msg, 0, sizeof(*msg));
+
+ msg->arch_addr_lo.dmar_base_address = X86_MSI_BASE_ADDRESS_LOW;
+ msg->arch_addr_lo.dmar_subhandle_valid = true;
+ msg->arch_addr_lo.dmar_format = true;
+ msg->arch_addr_lo.dmar_index_0_14 = index & 0x7FFF;
+ msg->arch_addr_lo.dmar_index_15 = !!(index & 0x8000);
+
+ msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
+
+ msg->arch_data.dmar_subhandle = subhandle;
+}
+
static void intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
struct irq_cfg *irq_cfg,
struct irq_alloc_info *info,
@@ -1267,7 +1281,6 @@ static void intel_irq_remapping_prepare_irte(struct
intel_ir_data *data,
{
struct IR_IO_APIC_route_entry *entry;
struct irte *irte = >irte_entry;
- struct msi_msg *msg = >msi_entry;
prepare_irte(irte, irq_cfg->vector, irq_cfg->dest_apicid);
switch (info->type) {
@@ -1308,12 +1321,7 @@ static void intel_irq_remapping_prepare_irte(struct
intel_ir_data *data,
else
set_msi_sid(irte, msi_desc_to_pci_dev(info->desc));
- msg->address_hi = MSI_ADDR_BASE_HI;
- msg->data = sub_handle;
- msg->address_lo = MSI_ADDR_BASE_LO | MSI_ADDR_IR_EXT_INT |
- MSI_ADDR_IR_SHV |
- MSI_ADDR_IR_INDEX1(index) |
- MSI_ADDR_IR_INDEX2(index);
+ fill_msi_msg(>msi_entry, index, sub_handle);
break;
default:
--
2.26.2
[PATCH v3 24/35] iommu/amd: Implement select() method on remapping irqdomain
From: David Woodhouse
Preparatory change to remove irq_remapping_get_irq_domain().
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 9744cdbefd88..31b22244e9c2 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3882,7 +3882,26 @@ static void irq_remapping_deactivate(struct irq_domain
*domain,
irte_info->index);
}
+static int irq_remapping_select(struct irq_domain *d, struct irq_fwspec
*fwspec,
+ enum irq_domain_bus_token bus_token)
+{
+ struct amd_iommu *iommu;
+ int devid = -1;
+
+ if (x86_fwspec_is_ioapic(fwspec))
+ devid = get_ioapic_devid(fwspec->param[0]);
+ else if (x86_fwspec_is_hpet(fwspec))
+ devid = get_hpet_devid(fwspec->param[0]);
+
+ if (devid < 0)
+ return 0;
+
+ iommu = amd_iommu_rlookup_table[devid];
+ return iommu && iommu->ir_domain == d;
+}
+
static const struct irq_domain_ops amd_ir_domain_ops = {
+ .select = irq_remapping_select,
.alloc = irq_remapping_alloc,
.free = irq_remapping_free,
.activate = irq_remapping_activate,
--
2.26.2
[PATCH v3 17/35] x86/pci/xen: Use msi_msg shadow structs
From: Thomas Gleixner
Use the msi_msg shadow structs and compose the message with named bitfields
instead of the unreadable macro maze.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/pci/xen.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index c552cd2d0632..3d41a09c2c14 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -152,7 +152,6 @@ static int acpi_register_gsi_xen(struct device *dev, u32
gsi,
#if defined(CONFIG_PCI_MSI)
#include
-#include
struct xen_pci_frontend_ops *xen_pci_frontend;
EXPORT_SYMBOL_GPL(xen_pci_frontend);
@@ -210,23 +209,20 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
return ret;
}
-#define XEN_PIRQ_MSI_DATA (MSI_DATA_TRIGGER_EDGE | \
- MSI_DATA_LEVEL_ASSERT | (3 << 8) | MSI_DATA_VECTOR(0))
-
static void xen_msi_compose_msg(struct pci_dev *pdev, unsigned int pirq,
struct msi_msg *msg)
{
- /* We set vector == 0 to tell the hypervisor we don't care about it,
-* but we want a pirq setup instead.
-* We use the dest_id field to pass the pirq that we want. */
- msg->address_hi = MSI_ADDR_BASE_HI | MSI_ADDR_EXT_DEST_ID(pirq);
- msg->address_lo =
- MSI_ADDR_BASE_LO |
- MSI_ADDR_DEST_MODE_PHYSICAL |
- MSI_ADDR_REDIRECTION_CPU |
- MSI_ADDR_DEST_ID(pirq);
-
- msg->data = XEN_PIRQ_MSI_DATA;
+ /*
+* We set vector == 0 to tell the hypervisor we don't care about
+* it, but we want a pirq setup instead. We use the dest_id fields
+* to pass the pirq that we want.
+*/
+ memset(msg, 0, sizeof(*msg));
+ msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
+ msg->arch_addr_hi.destid_8_31 = pirq >> 8;
+ msg->arch_addr_lo.destid_0_7 = pirq & 0xFF;
+ msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW;
+ msg->arch_data.delivery_mode = APIC_DELIVERY_MODE_EXTINT;
}
static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
--
2.26.2
[PATCH v3 21/35] x86/ioapic: Generate RTE directly from parent irqchip's MSI message
From: David Woodhouse
The I/O-APIC generates an MSI cycle with address/data bits taken from its
Redirection Table Entry in some combination which used to make sense, but
now is just a bunch of bits which get passed through in some seemingly
arbitrary order.
Instead of making IRQ remapping drivers directly frob the I/OA-PIC RTE, let
them just do their job and generate an MSI message. The bit swizzling to
turn that MSI message into the I/O-APIC's RTE is the same in all cases,
since it's a function of the I/O-APIC hardware. The IRQ remappers have no
real need to get involved with that.
The only slight caveat is that the I/OAPIC is interpreting some of those
fields too, and it does want the 'vector' field to be unique to make EOI
work. The AMD IOMMU happens to put its IRTE index in the bits that the
I/O-APIC thinks are the vector field, and accommodates this requirement by
reserving the first 32 indices for the I/O-APIC. The Intel IOMMU doesn't
actually use the bits that the I/O-APIC thinks are the vector field, so it
fills in the 'pin' value there instead.
[ tglx: Replaced the unreadably macro maze with the cleaned up RTE/msi_msg
bitfields and added commentry to explain the mapping magic ]
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h | 11 ++-
arch/x86/kernel/apic/io_apic.c | 103 +++-
drivers/iommu/amd/iommu.c | 12
drivers/iommu/hyperv-iommu.c| 31 -
drivers/iommu/intel/irq_remapping.c | 31 ++---
5 files changed, 83 insertions(+), 105 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 517847a94dbe..83a69f62637e 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -45,12 +45,11 @@ enum irq_alloc_type {
};
struct ioapic_alloc_info {
- int pin;
- int node;
- u32 is_level: 1;
- u32 active_low : 1;
- u32 valid : 1;
- struct IO_APIC_route_entry *entry;
+ int pin;
+ int node;
+ u32 is_level: 1;
+ u32 active_low : 1;
+ u32 valid : 1;
};
struct uv_alloc_info {
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 07e754131854..ea983da1a57f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -48,6 +48,7 @@
#include /* time_after() */
#include
#include
+#include
#include
#include
@@ -63,7 +64,6 @@
#include
#include
#include
-
#include
#definefor_each_ioapic(idx)\
@@ -1848,21 +1848,58 @@ static void ioapic_ir_ack_level(struct irq_data
*irq_data)
eoi_ioapic_pin(data->entry.vector, data);
}
+/*
+ * The I/OAPIC is just a device for generating MSI messages from legacy
+ * interrupt pins. Various fields of the RTE translate into bits of the
+ * resulting MSI which had a historical meaning.
+ *
+ * With interrupt remapping, many of those bits have different meanings
+ * in the underlying MSI, but the way that the I/OAPIC transforms them
+ * from its RTE to the MSI message is the same. This function allows
+ * the parent IRQ domain to compose the MSI message, then takes the
+ * relevant bits to put them in the appropriate places in the RTE in
+ * order to generate that message when the IRQ happens.
+ *
+ * The setup here relies on a preconfigured route entry (is_level,
+ * active_low, masked) because the parent domain is merely composing the
+ * generic message routing information which is used for the MSI.
+ */
+static void ioapic_setup_msg_from_msi(struct irq_data *irq_data,
+ struct IO_APIC_route_entry *entry)
+{
+ struct msi_msg msg;
+
+ /* Let the parent domain compose the MSI message */
+ irq_chip_compose_msi_msg(irq_data, );
+
+ /*
+* - Real vector
+* - DMAR/IR: 8bit subhandle (ioapic.pin)
+* - AMD/IR: 8bit IRTE index
+*/
+ entry->vector = msg.arch_data.vector;
+ /* Delivery mode (for DMAR/IR all 0) */
+ entry->delivery_mode= msg.arch_data.delivery_mode;
+ /* Destination mode or DMAR/IR index bit 15 */
+ entry->dest_mode_logical= msg.arch_addr_lo.dest_mode_logical;
+ /* DMAR/IR: 1, 0 for all other modes */
+ entry->ir_format= msg.arch_addr_lo.dmar_format;
+ /*
+* DMAR/IR: index bit 0-14.
+*
+* All other modes have bit 0-6 of dmar_index_0_14 cleared and the
+* topmost 8 bits are destination id bit 0-7 (entry::destid_0_7).
+*/
+ entry->ir_index_0_14= msg.arch_addr_lo.dmar_index_0_14;
+}
+
static void
[PATCH v3 30/35] iommu/vt-d: Simplify intel_irq_remapping_select()
From: David Woodhouse
Now that the old get_irq_domain() method has gone, consolidate on just the
map_XXX_to_iommu() functions.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/irq_remapping.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index bca44015bc1d..aeffda92b10b 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -203,13 +203,13 @@ static int modify_irte(struct irq_2_iommu *irq_iommu,
return rc;
}
-static struct irq_domain *map_hpet_to_ir(u8 hpet_id)
+static struct intel_iommu *map_hpet_to_iommu(u8 hpet_id)
{
int i;
for (i = 0; i < MAX_HPET_TBS; i++) {
if (ir_hpet[i].id == hpet_id && ir_hpet[i].iommu)
- return ir_hpet[i].iommu->ir_domain;
+ return ir_hpet[i].iommu;
}
return NULL;
}
@@ -225,13 +225,6 @@ static struct intel_iommu *map_ioapic_to_iommu(int apic)
return NULL;
}
-static struct irq_domain *map_ioapic_to_ir(int apic)
-{
- struct intel_iommu *iommu = map_ioapic_to_iommu(apic);
-
- return iommu ? iommu->ir_domain : NULL;
-}
-
static struct irq_domain *map_dev_to_ir(struct pci_dev *dev)
{
struct dmar_drhd_unit *drhd = dmar_find_matched_drhd_unit(dev);
@@ -1418,12 +1411,14 @@ static int intel_irq_remapping_select(struct irq_domain
*d,
struct irq_fwspec *fwspec,
enum irq_domain_bus_token bus_token)
{
+ struct intel_iommu *iommu = NULL;
+
if (x86_fwspec_is_ioapic(fwspec))
- return d == map_ioapic_to_ir(fwspec->param[0]);
+ iommu = map_ioapic_to_iommu(fwspec->param[0]);
else if (x86_fwspec_is_hpet(fwspec))
- return d == map_hpet_to_ir(fwspec->param[0]);
+ iommu = map_hpet_to_iommu(fwspec->param[0]);
- return 0;
+ return iommu && d == iommu->ir_domain;
}
static const struct irq_domain_ops intel_ir_domain_ops = {
--
2.26.2
[PATCH v3 31/35] x86/ioapic: Handle Extended Destination ID field in RTE
From: David Woodhouse
Bits 63-48 of the I/OAPIC Redirection Table Entry map directly to bits 19-4
of the address used in the resulting MSI cycle.
Historically, the x86 MSI format only used the top 8 of those 16 bits as
the destination APIC ID, and the "Extended Destination ID" in the lower 8
bits was unused.
With interrupt remapping, the lowest bit of the Extended Destination ID
(bit 48 of RTE, bit 4 of MSI address) is now used to indicate a remappable
format MSI.
A hypervisor can use the other 7 bits of the Extended Destination ID to
permit guests to address up to 15 bits of APIC IDs, thus allowing 32768
vCPUs before having to expose a vIOMMU and interrupt remapping to the
guest.
No behavioural change in this patch, since nothing yet permits APIC IDs
above 255 to be used with the non-IR I/OAPIC domain.
[ tglx: Converted it to the cleaned up entry/msi_msg format and added
commentry ]
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/io_apic.h | 3 ++-
arch/x86/kernel/apic/io_apic.c | 20 +++-
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 73da644b2f0d..437aa8d00e53 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -67,7 +67,8 @@ struct IO_APIC_route_entry {
is_level: 1,
masked : 1,
reserved_0 : 15,
- reserved_1 : 24,
+ reserved_1 : 17,
+ virt_destid_8_14: 7,
destid_0_7 : 8;
};
struct {
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 443d2c9086b9..1cfd65ef295b 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1238,9 +1238,10 @@ static void io_apic_print_entries(unsigned int apic,
unsigned int nr_entries)
(entry.ir_index_15 << 15) | entry.ir_index_0_14,
entry.ir_zero);
} else {
- printk(KERN_DEBUG "%s, %s, D(%02X), M(%1d)\n", buf,
+ printk(KERN_DEBUG "%s, %s, D(%02X%02X), M(%1d)\n", buf,
entry.dest_mode_logical ? "logical " :
"physical",
- entry.destid_0_7, entry.delivery_mode);
+ entry.virt_destid_8_14, entry.destid_0_7,
+ entry.delivery_mode);
}
}
}
@@ -1409,6 +1410,7 @@ void native_restore_boot_irq_mode(void)
*/
if (ioapic_i8259.pin != -1) {
struct IO_APIC_route_entry entry;
+ u32 apic_id = read_apic_id();
memset(, 0, sizeof(entry));
entry.masked= false;
@@ -1416,7 +1418,8 @@ void native_restore_boot_irq_mode(void)
entry.active_low= false;
entry.dest_mode_logical = false;
entry.delivery_mode = APIC_DELIVERY_MODE_EXTINT;
- entry.destid_0_7= read_apic_id();
+ entry.destid_0_7= apic_id & 0xFF;
+ entry.virt_destid_8_14 = apic_id >> 8;
/*
* Add it to the IO-APIC irq-routing table:
@@ -1885,7 +1888,11 @@ static void ioapic_setup_msg_from_msi(struct irq_data
*irq_data,
/* DMAR/IR: 1, 0 for all other modes */
entry->ir_format= msg.arch_addr_lo.dmar_format;
/*
-* DMAR/IR: index bit 0-14.
+* - DMAR/IR: index bit 0-14.
+*
+* - Virt: If the host supports x2apic without a virtualized IR
+* unit then bit 0-6 of dmar_index_0_14 are providing bit
+* 8-14 of the destination id.
*
* All other modes have bit 0-6 of dmar_index_0_14 cleared and the
* topmost 8 bits are destination id bit 0-7 (entry::destid_0_7).
@@ -2063,6 +2070,7 @@ static inline void __init unlock_ExtINT_logic(void)
int apic, pin, i;
struct IO_APIC_route_entry entry0, entry1;
unsigned char save_control, save_freq_select;
+ u32 apic_id;
pin = find_isa_irq_pin(8, mp_INT);
if (pin == -1) {
@@ -2078,11 +2086,13 @@ static inline void __init unlock_ExtINT_logic(void)
entry0 = ioapic_read_entry(apic, pin);
clear_IO_APIC_pin(apic, pin);
+ apic_id = hard_smp_processor_id();
memset(, 0, sizeof(entry1));
entry1.dest_mode_logical= true;
entry1.masked = false;
- entry1.destid_0_7 = hard_smp_processor_id();
+ entry1.destid_0_7 = apic_id & 0xFF;
+
[PATCH v3 20/35] x86/ioapic: Cleanup IO/APIC route entry structs
From: Thomas Gleixner
Having two seperate structs for the I/O-APIC RTE entries (non-remapped and
DMAR remapped) requires type casts and makes it hard to map.
Combine them in IO_APIC_routing_entry by defining a union of two 64bit
bitfields. Use naming which reflects which bits are shared and which bits
are actually different for the operating modes.
[dwmw2: Fix it up and finish the job, pulling the 32-bit w1,w2 words for
register access into the same union and eliminating a few more
places where bits were accessed through masks and shifts.]
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/io_apic.h | 78 ++-
arch/x86/kernel/apic/io_apic.c | 144 +---
drivers/iommu/amd/iommu.c | 8 +-
drivers/iommu/hyperv-iommu.c| 4 +-
drivers/iommu/intel/irq_remapping.c | 19 ++--
5 files changed, 108 insertions(+), 145 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index a1a26f6d3aa4..73da644b2f0d 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -13,15 +13,6 @@
* Copyright (C) 1997, 1998, 1999, 2000 Ingo Molnar
*/
-/* I/O Unit Redirection Table */
-#define IO_APIC_REDIR_VECTOR_MASK 0x000FF
-#define IO_APIC_REDIR_DEST_LOGICAL 0x00800
-#define IO_APIC_REDIR_DEST_PHYSICAL0x0
-#define IO_APIC_REDIR_SEND_PENDING (1 << 12)
-#define IO_APIC_REDIR_REMOTE_IRR (1 << 14)
-#define IO_APIC_REDIR_LEVEL_TRIGGER(1 << 15)
-#define IO_APIC_REDIR_MASKED (1 << 16)
-
/*
* The structure of the IO-APIC:
*/
@@ -65,52 +56,39 @@ union IO_APIC_reg_03 {
};
struct IO_APIC_route_entry {
- __u32 vector : 8,
- delivery_mode : 3, /* 000: FIXED
-* 001: lowest prio
-* 111: ExtINT
-*/
- dest_mode : 1, /* 0: physical, 1: logical */
- delivery_status : 1,
- polarity: 1,
- irr : 1,
- trigger : 1, /* 0: edge, 1: level */
- mask: 1, /* 0: enabled, 1: disabled */
- __reserved_2: 15;
-
- __u32 __reserved_3: 24,
- dest: 8;
-} __attribute__ ((packed));
-
-struct IR_IO_APIC_route_entry {
- __u64 vector : 8,
- zero: 3,
- index2 : 1,
- delivery_status : 1,
- polarity: 1,
- irr : 1,
- trigger : 1,
- mask: 1,
- reserved: 31,
- format : 1,
- index : 15;
+ union {
+ struct {
+ u64 vector : 8,
+ delivery_mode : 3,
+ dest_mode_logical : 1,
+ delivery_status : 1,
+ active_low : 1,
+ irr : 1,
+ is_level: 1,
+ masked : 1,
+ reserved_0 : 15,
+ reserved_1 : 24,
+ destid_0_7 : 8;
+ };
+ struct {
+ u64 ir_shared_0 : 8,
+ ir_zero : 3,
+ ir_index_15 : 1,
+ ir_shared_1 : 5,
+ ir_reserved_0 : 31,
+ ir_format : 1,
+ ir_index_0_14 : 15;
+ };
+ struct {
+ u64 w1 : 32,
+ w2 : 32;
+ };
+ };
} __attribute__ ((packed));
struct irq_alloc_info;
struct ioapic_domain_cfg;
-#define IOAPIC_EDGE0
-#define IOAPIC_LEVEL 1
-
-#define IOAPIC_MASKED 1
-#define IOAPIC_UNMASKED0
-
-#define IOAPIC_POL_HIGH0
-#define IOAPIC_POL_LOW 1
-
-#define IOAPIC_DEST_MODE_PHYSICAL 0
-#define IOAPIC_DEST_MODE_LOGICAL 1
-
#defineIOAPIC_MAP_ALLOC0x1
#defineIOAPIC_MAP_CHECK0x2
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 24a7bba7cbf4..07e754131854 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++
[PATCH v3 18/35] x86/msi: Remove msidef.h
From: Thomas Gleixner Nothing uses the macro maze anymore. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/include/asm/msidef.h | 57 --- 1 file changed, 57 deletions(-) delete mode 100644 arch/x86/include/asm/msidef.h diff --git a/arch/x86/include/asm/msidef.h b/arch/x86/include/asm/msidef.h deleted file mode 100644 index ee2f8ccc32d0.. --- a/arch/x86/include/asm/msidef.h +++ /dev/null @@ -1,57 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef _ASM_X86_MSIDEF_H -#define _ASM_X86_MSIDEF_H - -/* - * Constants for Intel APIC based MSI messages. - */ - -/* - * Shifts for MSI data - */ - -#define MSI_DATA_VECTOR_SHIFT 0 -#define MSI_DATA_VECTOR_MASK 0x00ff -#define MSI_DATA_VECTOR(v) (((v) << MSI_DATA_VECTOR_SHIFT) & \ -MSI_DATA_VECTOR_MASK) - -#define MSI_DATA_DELIVERY_MODE_SHIFT 8 -#define MSI_DATA_DELIVERY_FIXED (0 << MSI_DATA_DELIVERY_MODE_SHIFT) -#define MSI_DATA_DELIVERY_LOWPRI (1 << MSI_DATA_DELIVERY_MODE_SHIFT) - -#define MSI_DATA_LEVEL_SHIFT 14 -#define MSI_DATA_LEVEL_DEASSERT(0 << MSI_DATA_LEVEL_SHIFT) -#define MSI_DATA_LEVEL_ASSERT (1 << MSI_DATA_LEVEL_SHIFT) - -#define MSI_DATA_TRIGGER_SHIFT 15 -#define MSI_DATA_TRIGGER_EDGE (0 << MSI_DATA_TRIGGER_SHIFT) -#define MSI_DATA_TRIGGER_LEVEL(1 << MSI_DATA_TRIGGER_SHIFT) - -/* - * Shift/mask fields for msi address - */ - -#define MSI_ADDR_BASE_HI 0 -#define MSI_ADDR_BASE_LO 0xfee0 - -#define MSI_ADDR_DEST_MODE_SHIFT 2 -#define MSI_ADDR_DEST_MODE_PHYSICAL (0 << MSI_ADDR_DEST_MODE_SHIFT) -#define MSI_ADDR_DEST_MODE_LOGICAL (1 << MSI_ADDR_DEST_MODE_SHIFT) - -#define MSI_ADDR_REDIRECTION_SHIFT 3 -#define MSI_ADDR_REDIRECTION_CPU (0 << MSI_ADDR_REDIRECTION_SHIFT) - /* dedicated cpu */ -#define MSI_ADDR_REDIRECTION_LOWPRI (1 << MSI_ADDR_REDIRECTION_SHIFT) - /* lowest priority */ - -#define MSI_ADDR_DEST_ID_SHIFT 12 -#define MSI_ADDR_DEST_ID_MASK 0x000 -#define MSI_ADDR_DEST_ID(dest)(((dest) << MSI_ADDR_DEST_ID_SHIFT) & \ -MSI_ADDR_DEST_ID_MASK) -#define MSI_ADDR_EXT_DEST_ID(dest) ((dest) & 0xff00) - -#define MSI_ADDR_IR_EXT_INT(1 << 4) -#define MSI_ADDR_IR_SHV(1 << 3) -#define MSI_ADDR_IR_INDEX1(index) ((index & 0x8000) >> 13) -#define MSI_ADDR_IR_INDEX2(index) ((index & 0x7fff) << 5) -#endif /* _ASM_X86_MSIDEF_H */ -- 2.26.2
[PATCH v3 26/35] iommu/hyper-v: Implement select() method on remapping irqdomain
From: David Woodhouse
Preparatory for removing irq_remapping_get_irq_domain()
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/hyperv-iommu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
index 37dd485a5640..78a264ad9405 100644
--- a/drivers/iommu/hyperv-iommu.c
+++ b/drivers/iommu/hyperv-iommu.c
@@ -101,7 +101,16 @@ static void hyperv_irq_remapping_free(struct irq_domain
*domain,
irq_domain_free_irqs_common(domain, virq, nr_irqs);
}
+static int hyperv_irq_remapping_select(struct irq_domain *d,
+ struct irq_fwspec *fwspec,
+ enum irq_domain_bus_token bus_token)
+{
+ /* Claim only the first (and only) I/OAPIC */
+ return x86_fwspec_is_ioapic(fwspec) && fwspec->param[0] == 0;
+}
+
static const struct irq_domain_ops hyperv_ir_domain_ops = {
+ .select = hyperv_irq_remapping_select,
.alloc = hyperv_irq_remapping_alloc,
.free = hyperv_irq_remapping_free,
};
--
2.26.2
[PATCH v3 29/35] x86: Kill all traces of irq_remapping_get_irq_domain()
From: David Woodhouse
All users are converted to use the fwspec based parent domain lookup.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h| 2 --
arch/x86/include/asm/irq_remapping.h | 9
drivers/iommu/amd/iommu.c| 34
drivers/iommu/hyperv-iommu.c | 9
drivers/iommu/intel/irq_remapping.c | 17 --
drivers/iommu/irq_remapping.c| 14
drivers/iommu/irq_remapping.h| 3 ---
7 files changed, 88 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 83a69f62637e..458f5a676402 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -40,8 +40,6 @@ enum irq_alloc_type {
X86_IRQ_ALLOC_TYPE_PCI_MSIX,
X86_IRQ_ALLOC_TYPE_DMAR,
X86_IRQ_ALLOC_TYPE_UV,
- X86_IRQ_ALLOC_TYPE_IOAPIC_GET_PARENT,
- X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT,
};
struct ioapic_alloc_info {
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index af4a151d70b3..7cc49432187f 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -44,9 +44,6 @@ extern int irq_remapping_reenable(int);
extern int irq_remap_enable_fault_handling(void);
extern void panic_if_irq_remap(const char *msg);
-extern struct irq_domain *
-irq_remapping_get_irq_domain(struct irq_alloc_info *info);
-
/* Create PCI MSI/MSIx irqdomain, use @parent as the parent irqdomain. */
extern struct irq_domain *
arch_create_remap_msi_irq_domain(struct irq_domain *par, const char *n, int
id);
@@ -71,11 +68,5 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline struct irq_domain *
-irq_remapping_get_irq_domain(struct irq_alloc_info *info)
-{
- return NULL;
-}
-
#endif /* CONFIG_IRQ_REMAP */
#endif /* __X86_IRQ_REMAPPING_H */
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 31b22244e9c2..463d322a4f3b 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3601,10 +3601,8 @@ static int get_devid(struct irq_alloc_info *info)
{
switch (info->type) {
case X86_IRQ_ALLOC_TYPE_IOAPIC:
- case X86_IRQ_ALLOC_TYPE_IOAPIC_GET_PARENT:
return get_ioapic_devid(info->devid);
case X86_IRQ_ALLOC_TYPE_HPET:
- case X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT:
return get_hpet_devid(info->devid);
case X86_IRQ_ALLOC_TYPE_PCI_MSI:
case X86_IRQ_ALLOC_TYPE_PCI_MSIX:
@@ -3615,44 +3613,12 @@ static int get_devid(struct irq_alloc_info *info)
}
}
-static struct irq_domain *get_irq_domain_for_devid(struct irq_alloc_info *info,
- int devid)
-{
- struct amd_iommu *iommu = amd_iommu_rlookup_table[devid];
-
- if (!iommu)
- return NULL;
-
- switch (info->type) {
- case X86_IRQ_ALLOC_TYPE_IOAPIC_GET_PARENT:
- case X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT:
- return iommu->ir_domain;
- default:
- WARN_ON_ONCE(1);
- return NULL;
- }
-}
-
-static struct irq_domain *get_irq_domain(struct irq_alloc_info *info)
-{
- int devid;
-
- if (!info)
- return NULL;
-
- devid = get_devid(info);
- if (devid < 0)
- return NULL;
- return get_irq_domain_for_devid(info, devid);
-}
-
struct irq_remap_ops amd_iommu_irq_ops = {
.prepare= amd_iommu_prepare,
.enable = amd_iommu_enable,
.disable= amd_iommu_disable,
.reenable = amd_iommu_reenable,
.enable_faulting= amd_iommu_enable_faulting,
- .get_irq_domain = get_irq_domain,
};
static void fill_msi_msg(struct msi_msg *msg, u32 index)
diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
index 78a264ad9405..a629a6be65c7 100644
--- a/drivers/iommu/hyperv-iommu.c
+++ b/drivers/iommu/hyperv-iommu.c
@@ -160,18 +160,9 @@ static int __init hyperv_enable_irq_remapping(void)
return IRQ_REMAP_X2APIC_MODE;
}
-static struct irq_domain *hyperv_get_irq_domain(struct irq_alloc_info *info)
-{
- if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC_GET_PARENT)
- return ioapic_ir_domain;
- else
- return NULL;
-}
-
struct irq_remap_ops hyperv_irq_remap_ops = {
.prepare= hyperv_prepare_irq_remapping,
.enable = hyperv_enable_irq_remapping,
- .get_irq_domain = hyperv_get_irq_domain,
};
#endif
diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index b3b079c0b51e..bca44015bc1d 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -1127,29 +1127,12 @@ static void prepare_irte(struct irte *irte,
[PATCH v3 25/35] iommu/vt-d: Implement select() method on remapping irqdomain
From: David Woodhouse
Preparatory for removing irq_remapping_get_irq_domain()
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/irq_remapping.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index 96c84b19940e..b3b079c0b51e 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -1431,7 +1431,20 @@ static void intel_irq_remapping_deactivate(struct
irq_domain *domain,
modify_irte(>irq_2_iommu, );
}
+static int intel_irq_remapping_select(struct irq_domain *d,
+ struct irq_fwspec *fwspec,
+ enum irq_domain_bus_token bus_token)
+{
+ if (x86_fwspec_is_ioapic(fwspec))
+ return d == map_ioapic_to_ir(fwspec->param[0]);
+ else if (x86_fwspec_is_hpet(fwspec))
+ return d == map_hpet_to_ir(fwspec->param[0]);
+
+ return 0;
+}
+
static const struct irq_domain_ops intel_ir_domain_ops = {
+ .select = intel_irq_remapping_select,
.alloc = intel_irq_remapping_alloc,
.free = intel_irq_remapping_free,
.activate = intel_irq_remapping_activate,
--
2.26.2
[PATCH v3 07/35] x86/apic: Get rid of apic::dest_logical
From: Thomas Gleixner
struct apic has two members which store information about the destination
mode: dest_logical and irq_dest_mode.
dest_logical contains a mask which was historically used to set the
destination mode in IPI messages. Over time the usage was reduced and the
logical/physical functions were seperated.
There are only a few places which still use 'dest_logical' but they can
ues 'irq_dest_mode' instead.
irq_dest_mode is actually a boolean where 0 means physical destination mode
and 1 means logical destination mode. Of course the name does not reflect
the functionality. This will be cleaned up in a subsequent change.
Remove apic::dest_logical and fixup the remaining users.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/apic.h | 2 --
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apic/apic_flat_64.c | 8 ++--
arch/x86/kernel/apic/apic_noop.c | 4 +---
arch/x86/kernel/apic/apic_numachip.c | 8 ++--
arch/x86/kernel/apic/bigsmp_32.c | 4 +---
arch/x86/kernel/apic/probe_32.c | 4 +---
arch/x86/kernel/apic/x2apic_cluster.c | 4 +---
arch/x86/kernel/apic/x2apic_phys.c| 4 +---
arch/x86/kernel/apic/x2apic_uv_x.c| 4 +---
arch/x86/kernel/smpboot.c | 5 +++--
arch/x86/xen/apic.c | 4 +---
12 files changed, 15 insertions(+), 38 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 53bb62e0fdd5..019d7ac3b16e 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -306,8 +306,6 @@ struct apic {
void(*send_IPI_all)(int vector);
void(*send_IPI_self)(int vector);
- /* dest_logical is used by the IPI functions */
- u32 dest_logical;
u32 disable_esr;
enum apic_delivery_modes delivery_mode;
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 113f6ca7b828..29d28b34cb2f 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1591,7 +1591,7 @@ static void setup_local_APIC(void)
apic->init_apic_ldr();
#ifdef CONFIG_X86_32
- if (apic->dest_logical) {
+ if (apic->irq_dest_mode == 1) {
int logical_apicid, ldr_apicid;
/*
diff --git a/arch/x86/kernel/apic/apic_flat_64.c
b/arch/x86/kernel/apic/apic_flat_64.c
index 6df837fd5081..bbb1b89fe711 100644
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -117,11 +117,9 @@ static struct apic apic_flat __ro_after_init = {
.irq_dest_mode = 1, /* logical */
.disable_esr= 0,
- .dest_logical = APIC_DEST_LOGICAL,
- .check_apicid_used = NULL,
+ .check_apicid_used = NULL,
.init_apic_ldr = flat_init_apic_ldr,
-
.ioapic_phys_id_map = NULL,
.setup_apic_routing = NULL,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
@@ -210,11 +208,9 @@ static struct apic apic_physflat __ro_after_init = {
.irq_dest_mode = 0, /* physical */
.disable_esr= 0,
- .dest_logical = 0,
- .check_apicid_used = NULL,
+ .check_apicid_used = NULL,
.init_apic_ldr = physflat_init_apic_ldr,
-
.ioapic_phys_id_map = NULL,
.setup_apic_routing = NULL,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c
index 4fc934b11851..38f167ce5031 100644
--- a/arch/x86/kernel/apic/apic_noop.c
+++ b/arch/x86/kernel/apic/apic_noop.c
@@ -100,11 +100,9 @@ struct apic apic_noop __ro_after_init = {
.irq_dest_mode = 1,
.disable_esr= 0,
- .dest_logical = APIC_DEST_LOGICAL,
- .check_apicid_used = default_check_apicid_used,
+ .check_apicid_used = default_check_apicid_used,
.init_apic_ldr = noop_init_apic_ldr,
-
.ioapic_phys_id_map = default_ioapic_phys_id_map,
.setup_apic_routing = NULL,
diff --git a/arch/x86/kernel/apic/apic_numachip.c
b/arch/x86/kernel/apic/apic_numachip.c
index db715d082ec9..4ebf9fe2c95d 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -250,11 +250,9 @@ static const struct apic apic_numachip1 __refconst = {
.irq_dest_mode = 0, /* physical */
.disable_esr= 0,
- .dest_logical = 0,
- .check_apicid_used = NULL,
+ .check_apicid_used = NULL,
.init_apic_ldr = flat_init_apic_ldr,
-
[PATCH v3 23/35] x86/apic: Add select() method on vector irqdomain
From: David Woodhouse
This will be used to select the irqdomain for I/O-APIC and HPET.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irqdomain.h | 3 +++
arch/x86/kernel/apic/vector.c| 43
2 files changed, 46 insertions(+)
diff --git a/arch/x86/include/asm/irqdomain.h b/arch/x86/include/asm/irqdomain.h
index cd684d45cb5f..125c23b7bad3 100644
--- a/arch/x86/include/asm/irqdomain.h
+++ b/arch/x86/include/asm/irqdomain.h
@@ -12,6 +12,9 @@ enum {
X86_IRQ_ALLOC_LEGACY= 0x2,
};
+extern int x86_fwspec_is_ioapic(struct irq_fwspec *fwspec);
+extern int x86_fwspec_is_hpet(struct irq_fwspec *fwspec);
+
extern struct irq_domain *x86_vector_domain;
extern void init_irq_alloc_info(struct irq_alloc_info *info,
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index bb2e2a2488a5..b9b05caa28a4 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -636,7 +636,50 @@ static void x86_vector_debug_show(struct seq_file *m,
struct irq_domain *d,
}
#endif
+int x86_fwspec_is_ioapic(struct irq_fwspec *fwspec)
+{
+ if (fwspec->param_count != 1)
+ return 0;
+
+ if (is_fwnode_irqchip(fwspec->fwnode)) {
+ const char *fwname = fwnode_get_name(fwspec->fwnode);
+ return fwname && !strncmp(fwname, "IO-APIC-", 8) &&
+ simple_strtol(fwname+8, NULL, 10) == fwspec->param[0];
+ }
+ return to_of_node(fwspec->fwnode) &&
+ of_device_is_compatible(to_of_node(fwspec->fwnode),
+ "intel,ce4100-ioapic");
+}
+
+int x86_fwspec_is_hpet(struct irq_fwspec *fwspec)
+{
+ if (fwspec->param_count != 1)
+ return 0;
+
+ if (is_fwnode_irqchip(fwspec->fwnode)) {
+ const char *fwname = fwnode_get_name(fwspec->fwnode);
+ return fwname && !strncmp(fwname, "HPET-MSI-", 9) &&
+ simple_strtol(fwname+9, NULL, 10) == fwspec->param[0];
+ }
+ return 0;
+}
+
+static int x86_vector_select(struct irq_domain *d, struct irq_fwspec *fwspec,
+enum irq_domain_bus_token bus_token)
+{
+ /*
+* HPET and I/OAPIC cannot be parented in the vector domain
+* if IRQ remapping is enabled. APIC IDs above 15 bits are
+* only permitted if IRQ remapping is enabled, so check that.
+*/
+ if (apic->apic_id_valid(32768))
+ return 0;
+
+ return x86_fwspec_is_ioapic(fwspec) || x86_fwspec_is_hpet(fwspec);
+}
+
static const struct irq_domain_ops x86_vector_domain_ops = {
+ .select = x86_vector_select,
.alloc = x86_vector_alloc_irqs,
.free = x86_vector_free_irqs,
.activate = x86_vector_activate,
--
2.26.2
[PATCH v3 14/35] iommu/amd: Use msi_msg shadow structs
From: Thomas Gleixner
Get rid of the macro mess and use the shadow structs for the x86 specific
MSI message format. Convert the intcapxt setup to use named bitfields as
well while touching it anyway.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
drivers/iommu/amd/init.c | 46 ++-
drivers/iommu/amd/iommu.c | 14 +++-
2 files changed, 35 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 82e4af8f09bb..263670d36fed 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1966,10 +1965,16 @@ static int iommu_setup_msi(struct amd_iommu *iommu)
return 0;
}
-#define XT_INT_DEST_MODE(x)(((x) & 0x1ULL) << 2)
-#define XT_INT_DEST_LO(x) (((x) & 0xFFULL) << 8)
-#define XT_INT_VEC(x) (((x) & 0xFFULL) << 32)
-#define XT_INT_DEST_HI(x) x) >> 24) & 0xFFULL) << 56)
+union intcapxt {
+ u64 capxt;
+ u64 reserved_0 : 2,
+ dest_mode_logical : 1,
+ reserved_1 : 5,
+ destid_0_23 : 24,
+ vector : 8,
+ reserved_2 : 16,
+ destid_24_31: 8;
+} __attribute__ ((packed));
/*
* Setup the IntCapXT registers with interrupt routing information
@@ -1978,28 +1983,29 @@ static int iommu_setup_msi(struct amd_iommu *iommu)
*/
static void iommu_update_intcapxt(struct amd_iommu *iommu)
{
- u64 val;
- u32 addr_lo = readl(iommu->mmio_base + MMIO_MSI_ADDR_LO_OFFSET);
- u32 addr_hi = readl(iommu->mmio_base + MMIO_MSI_ADDR_HI_OFFSET);
- u32 data= readl(iommu->mmio_base + MMIO_MSI_DATA_OFFSET);
- bool dm = (addr_lo >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
- u32 dest= ((addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xFF);
+ struct msi_msg msg;
+ union intcapxt xt;
+ u32 destid;
- if (x2apic_enabled())
- dest |= MSI_ADDR_EXT_DEST_ID(addr_hi);
+ msg.address_lo = readl(iommu->mmio_base + MMIO_MSI_ADDR_LO_OFFSET);
+ msg.address_hi = readl(iommu->mmio_base + MMIO_MSI_ADDR_HI_OFFSET);
+ msg.data = readl(iommu->mmio_base + MMIO_MSI_DATA_OFFSET);
- val = XT_INT_VEC(data & 0xFF) |
- XT_INT_DEST_MODE(dm) |
- XT_INT_DEST_LO(dest) |
- XT_INT_DEST_HI(dest);
+ destid = x86_msi_msg_get_destid(, x2apic_enabled());
+
+ xt.capxt = 0ULL;
+ xt.dest_mode_logical = msg.arch_data.dest_mode_logical;
+ xt.vector = msg.arch_data.vector;
+ xt.destid_0_23 = destid & GENMASK(23, 0);
+ xt.destid_24_31 = destid >> 24;
/**
* Current IOMMU implemtation uses the same IRQ for all
* 3 IOMMU interrupts.
*/
- writeq(val, iommu->mmio_base + MMIO_INTCAPXT_EVT_OFFSET);
- writeq(val, iommu->mmio_base + MMIO_INTCAPXT_PPR_OFFSET);
- writeq(val, iommu->mmio_base + MMIO_INTCAPXT_GALOG_OFFSET);
+ writeq(xt.capxt, iommu->mmio_base + MMIO_INTCAPXT_EVT_OFFSET);
+ writeq(xt.capxt, iommu->mmio_base + MMIO_INTCAPXT_PPR_OFFSET);
+ writeq(xt.capxt, iommu->mmio_base + MMIO_INTCAPXT_GALOG_OFFSET);
}
static void _irq_notifier_notify(struct irq_affinity_notify *notify,
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index d7f0c8908602..473de0920b64 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -35,7 +35,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -3656,13 +3655,20 @@ struct irq_remap_ops amd_iommu_irq_ops = {
.get_irq_domain = get_irq_domain,
};
+static void fill_msi_msg(struct msi_msg *msg, u32 index)
+{
+ msg->data = index;
+ msg->address_lo = 0;
+ msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW;
+ msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
+}
+
static void irq_remapping_prepare_irte(struct amd_ir_data *data,
struct irq_cfg *irq_cfg,
struct irq_alloc_info *info,
int devid, int index, int sub_handle)
{
struct irq_2_irte *irte_info = >irq_2_irte;
- struct msi_msg *msg = >msi_entry;
struct IO_APIC_route_entry *entry;
struct amd_iommu *iommu = amd_iommu_rlookup_table[devid];
@@ -3693,9 +3699,7 @@ static void irq_remapping_prepare_irte(struct amd_ir_data
*data,
case X86_IRQ_ALLOC_TYPE_HPET:
case X86_IRQ_ALLOC_TYPE_PCI_MSI:
case X86_IRQ_ALLOC_TYPE_PCI_MSIX:
- msg->address_hi = MSI_ADDR_BASE_HI;
- msg->address_lo = MSI_ADDR_BASE_LO;
- msg->data = irte_info->index;
+ fill_msi_msg(>msi_entry, irte_info->index);
break;
[PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers
From: Thomas Gleixner
'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
the trigger type (edge/level) and the active low/high configuration. While
there are defines for initializing these variables and struct members, they
are not used consequently and the meaning of 'trigger' and 'polarity' is
opaque and confusing at best.
Rename them to 'is_level' and 'active_low' and make them boolean in various
structs so it's entirely clear what the meaning is.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/hw_irq.h | 6 +-
arch/x86/kernel/apic/io_apic.c | 244 +---
arch/x86/pci/intel_mid_pci.c| 8 +-
drivers/iommu/amd/iommu.c | 10 +-
drivers/iommu/intel/irq_remapping.c | 9 +-
5 files changed, 130 insertions(+), 147 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index a4aeeaace040..517847a94dbe 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -47,9 +47,9 @@ enum irq_alloc_type {
struct ioapic_alloc_info {
int pin;
int node;
- u32 trigger : 1;
- u32 polarity : 1;
- u32 valid : 1;
+ u32 is_level: 1;
+ u32 active_low : 1;
+ u32 valid : 1;
struct IO_APIC_route_entry *entry;
};
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c6d92d2570d0..24a7bba7cbf4 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -89,12 +89,12 @@ struct irq_pin_list {
};
struct mp_chip_data {
- struct list_head irq_2_pin;
- struct IO_APIC_route_entry entry;
- int trigger;
- int polarity;
+ struct list_headirq_2_pin;
+ struct IO_APIC_route_entry entry;
+ boolis_level;
+ boolactive_low;
+ boolisa_irq;
u32 count;
- bool isa_irq;
};
struct mp_ioapic_gsi {
@@ -745,44 +745,7 @@ static int __init find_isa_irq_apic(int irq, int type)
return -1;
}
-#ifdef CONFIG_EISA
-/*
- * EISA Edge/Level control register, ELCR
- */
-static int EISA_ELCR(unsigned int irq)
-{
- if (irq < nr_legacy_irqs()) {
- unsigned int port = 0x4d0 + (irq >> 3);
- return (inb(port) >> (irq & 7)) & 1;
- }
- apic_printk(APIC_VERBOSE, KERN_INFO
- "Broken MPtable reports ISA irq %d\n", irq);
- return 0;
-}
-
-#endif
-
-/* ISA interrupts are always active high edge triggered,
- * when listed as conforming in the MP table. */
-
-#define default_ISA_trigger(idx) (IOAPIC_EDGE)
-#define default_ISA_polarity(idx) (IOAPIC_POL_HIGH)
-
-/* EISA interrupts are always polarity zero and can be edge or level
- * trigger depending on the ELCR value. If an interrupt is listed as
- * EISA conforming in the MP table, that means its trigger type must
- * be read in from the ELCR */
-
-#define default_EISA_trigger(idx) (EISA_ELCR(mp_irqs[idx].srcbusirq))
-#define default_EISA_polarity(idx) default_ISA_polarity(idx)
-
-/* PCI interrupts are always active low level triggered,
- * when listed as conforming in the MP table. */
-
-#define default_PCI_trigger(idx) (IOAPIC_LEVEL)
-#define default_PCI_polarity(idx) (IOAPIC_POL_LOW)
-
-static int irq_polarity(int idx)
+static bool irq_active_low(int idx)
{
int bus = mp_irqs[idx].srcbus;
@@ -791,90 +754,139 @@ static int irq_polarity(int idx)
*/
switch (mp_irqs[idx].irqflag & MP_IRQPOL_MASK) {
case MP_IRQPOL_DEFAULT:
- /* conforms to spec, ie. bus-type dependent polarity */
- if (test_bit(bus, mp_bus_not_pci))
- return default_ISA_polarity(idx);
- else
- return default_PCI_polarity(idx);
+ /*
+* Conforms to spec, ie. bus-type dependent polarity. PCI
+* defaults to low active. [E]ISA defaults to high active.
+*/
+ return !test_bit(bus, mp_bus_not_pci);
case MP_IRQPOL_ACTIVE_HIGH:
- return IOAPIC_POL_HIGH;
+ return false;
case MP_IRQPOL_RESERVED:
pr_warn("IOAPIC: Invalid polarity: 2, defaulting to low\n");
fallthrough;
case MP_IRQPOL_ACTIVE_LOW:
default: /* Pointless default required due to do gcc stupidity */
- return IOAPIC_POL_LOW;
+ return true;
}
}
#ifdef CONFIG_EISA
-static int eisa_irq_trigger(int idx, int bus, int trigger)
+/*
+ * EISA Edge/Level control register,
[PATCH v3 35/35] x86/kvm: Enable 15-bit extension when KVM_FEATURE_MSI_EXT_DEST_ID detected
From: David Woodhouse
This allows the host to indicate that MSI emulation supports 15-bit
destination IDs, allowing up to 32768 CPUs without interrupt remapping.
cf. https://patchwork.kernel.org/patch/11816693/ for qemu
Signed-off-by: David Woodhouse
Acked-by: Paolo Bonzini
---
arch/x86/kernel/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 1c0f2560a41c..b82de2843814 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -740,6 +740,11 @@ static void __init kvm_apic_init(void)
#endif
}
+static bool __init kvm_msi_ext_dest_id(void)
+{
+ return kvm_para_has_feature(KVM_FEATURE_MSI_EXT_DEST_ID);
+}
+
static void __init kvm_init_platform(void)
{
kvmclock_init();
@@ -769,6 +774,7 @@ const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.type = X86_HYPER_KVM,
.init.guest_late_init = kvm_guest_init,
.init.x2apic_available = kvm_para_available,
+ .init.msi_ext_dest_id = kvm_msi_ext_dest_id,
.init.init_platform = kvm_init_platform,
#if defined(CONFIG_AMD_MEM_ENCRYPT)
.runtime.sev_es_hcall_prepare = kvm_sev_es_hcall_prepare,
--
2.26.2
[PATCH v3 27/35] x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain
From: David Woodhouse
All possible parent domains have a select method now. Make use of it.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/hpet.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 3b8b12769f3b..08651a4e6aa0 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -543,8 +543,8 @@ static struct irq_domain *hpet_create_irq_domain(int
hpet_id)
{
struct msi_domain_info *domain_info;
struct irq_domain *parent, *d;
- struct irq_alloc_info info;
struct fwnode_handle *fn;
+ struct irq_fwspec fwspec;
if (x86_vector_domain == NULL)
return NULL;
@@ -556,15 +556,6 @@ static struct irq_domain *hpet_create_irq_domain(int
hpet_id)
*domain_info = hpet_msi_domain_info;
domain_info->data = (void *)(long)hpet_id;
- init_irq_alloc_info(, NULL);
- info.type = X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT;
- info.devid = hpet_id;
- parent = irq_remapping_get_irq_domain();
- if (parent == NULL)
- parent = x86_vector_domain;
- else
- hpet_msi_controller.name = "IR-HPET-MSI";
-
fn = irq_domain_alloc_named_id_fwnode(hpet_msi_controller.name,
hpet_id);
if (!fn) {
@@ -572,6 +563,19 @@ static struct irq_domain *hpet_create_irq_domain(int
hpet_id)
return NULL;
}
+ fwspec.fwnode = fn;
+ fwspec.param_count = 1;
+ fwspec.param[0] = hpet_id;
+
+ parent = irq_find_matching_fwspec(, DOMAIN_BUS_ANY);
+ if (!parent) {
+ irq_domain_free_fwnode(fn);
+ kfree(domain_info);
+ return NULL;
+ }
+ if (parent != x86_vector_domain)
+ hpet_msi_controller.name = "IR-HPET-MSI";
+
d = msi_create_irq_domain(fn, domain_info, parent);
if (!d) {
irq_domain_free_fwnode(fn);
--
2.26.2
[PATCH v3 34/35] x86/kvm: Reserve KVM_FEATURE_MSI_EXT_DEST_ID
From: David Woodhouse No functional change; just reserve the feature bit for now so that VMMs can start to implement it. This will allow the host to indicate that MSI emulation supports 15-bit destination IDs, allowing up to 32768 CPUs without interrupt remapping. cf. https://patchwork.kernel.org/patch/11816693/ for qemu Signed-off-by: David Woodhouse Acked-by: Paolo Bonzini --- Documentation/virt/kvm/cpuid.rst | 4 arch/x86/include/uapi/asm/kvm_para.h | 1 + 2 files changed, 5 insertions(+) diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst index 9150e9d1c39b..f70b655821d5 100644 --- a/Documentation/virt/kvm/cpuid.rst +++ b/Documentation/virt/kvm/cpuid.rst @@ -92,6 +92,10 @@ KVM_FEATURE_ASYNC_PF_INT 14 guest checks this feature bit async pf acknowledgment msr 0x4b564d07. +KVM_FEATURE_MSI_EXT_DEST_ID 15 guest checks this feature bit + before using extended destination + ID bits in MSI address bits 11-5. + KVM_FEATURE_CLOCSOURCE_STABLE_BIT 24 host will warn if no guest-side per-cpu warps are expeced in kvmclock diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h index 812e9b4c1114..950afebfba88 100644 --- a/arch/x86/include/uapi/asm/kvm_para.h +++ b/arch/x86/include/uapi/asm/kvm_para.h @@ -32,6 +32,7 @@ #define KVM_FEATURE_POLL_CONTROL 12 #define KVM_FEATURE_PV_SCHED_YIELD 13 #define KVM_FEATURE_ASYNC_PF_INT 14 +#define KVM_FEATURE_MSI_EXT_DEST_ID15 #define KVM_HINTS_REALTIME 0 -- 2.26.2
[PATCH v3 32/35] x86/apic: Support 15 bits of APIC ID in MSI where available
From: David Woodhouse
Some hypervisors can allow the guest to use the Extended Destination ID
field in the MSI address to address up to 32768 CPUs.
This applies to all downstream devices which generate MSI cycles,
including HPET, I/OAPIC and PCI MSI.
HPET and PCI MSI use the same __irq_msi_compose_msg() function, while
I/OAPIC generates its own and had support for the extended bits added in
a previous commit.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
Link: https://lore.kernel.org/r/20201009104616.1314746-6-dw...@infradead.org
---
arch/x86/include/asm/msi.h | 3 ++-
arch/x86/include/asm/x86_init.h | 2 ++
arch/x86/kernel/apic/apic.c | 26 --
arch/x86/kernel/x86_init.c | 1 +
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index 322fd905da9c..b85147d75626 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -29,7 +29,8 @@ typedef struct x86_msi_addr_lo {
u32 reserved_0 : 2,
dest_mode_logical : 1,
redirect_hint : 1,
- reserved_1 : 8,
+ reserved_1 : 1,
+ virt_destid_8_14: 7,
destid_0_7 : 8,
base_address: 12;
};
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index dde5b3f1e7cd..5c69f7eb5d47 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -116,6 +116,7 @@ struct x86_init_pci {
* @init_platform: platform setup
* @guest_late_init: guest late init
* @x2apic_available: X2APIC detection
+ * @msi_ext_dest_id: MSI supports 15-bit APIC IDs
* @init_mem_mapping: setup early mappings during init_mem_mapping()
* @init_after_bootmem:guest init after boot allocator is
finished
*/
@@ -123,6 +124,7 @@ struct x86_hyper_init {
void (*init_platform)(void);
void (*guest_late_init)(void);
bool (*x2apic_available)(void);
+ bool (*msi_ext_dest_id)(void);
void (*init_mem_mapping)(void);
void (*init_after_bootmem)(void);
};
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index f7196ee0f005..6bd20c0de8bc 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -93,6 +93,11 @@ static unsigned int disabled_cpu_apicid __ro_after_init =
BAD_APICID;
*/
static int apic_extnmi __ro_after_init = APIC_EXTNMI_BSP;
+/*
+ * Hypervisor supports 15 bits of APIC ID in MSI Extended Destination ID
+ */
+static bool virt_ext_dest_id __ro_after_init;
+
/*
* Map cpu index to physical APIC ID
*/
@@ -1841,6 +1846,8 @@ static __init void try_to_enable_x2apic(int remap_mode)
return;
if (remap_mode != IRQ_REMAP_X2APIC_MODE) {
+ u32 apic_limit = 255;
+
/*
* Using X2APIC without IR is not architecturally supported
* on bare metal but may be supported in guests.
@@ -1851,12 +1858,22 @@ static __init void try_to_enable_x2apic(int remap_mode)
return;
}
+ /*
+* If the hypervisor supports extended destination ID in
+* MSI, that increases the maximum APIC ID that can be
+* used for non-remapped IRQ domains.
+*/
+ if (x86_init.hyper.msi_ext_dest_id()) {
+ virt_ext_dest_id = 1;
+ apic_limit = 32767;
+ }
+
/*
* Without IR, all CPUs can be addressed by IOAPIC/MSI only
* in physical mode, and CPUs with an APIC ID that cannnot
* be addressed must not be brought online.
*/
- x2apic_set_max_apicid(255);
+ x2apic_set_max_apicid(apic_limit);
x2apic_phys = 1;
}
x2apic_enable();
@@ -2497,10 +2514,15 @@ void __irq_msi_compose_msg(struct irq_cfg *cfg, struct
msi_msg *msg,
* Only the IOMMU itself can use the trick of putting destination
* APIC ID into the high bits of the address. Anything else would
* just be writing to memory if it tried that, and needs IR to
-* address higher APIC IDs.
+* address APICs which can't be addressed in the normal 32-bit
+* address range at 0xFFEx. That is typically just 8 bits, but
+* some hypervisors allow the extended destination ID field in bits
+* 5-11 to be used, giving support for 15 bits of APIC IDs in total.
*/
if (dmar)
msg->arch_addr_hi.destid_8_31 =
[PATCH v3 33/35] iommu/hyper-v: Disable IRQ pseudo-remapping if 15 bit APIC IDs are available
From: David Woodhouse If the 15-bit APIC ID support is present in emulated MSI then there's no need for the pseudo-remapping support. Signed-off-by: David Woodhouse --- drivers/iommu/hyperv-iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c index a629a6be65c7..9438daa24fdb 100644 --- a/drivers/iommu/hyperv-iommu.c +++ b/drivers/iommu/hyperv-iommu.c @@ -121,6 +121,7 @@ static int __init hyperv_prepare_irq_remapping(void) int i; if (!hypervisor_is_type(X86_HYPER_MS_HYPERV) || + x86_init.hyper.msi_ext_dest_id() || !x2apic_supported()) return -ENODEV; -- 2.26.2
BUSINESS PROPOSITION
Good Day, I know this email might come as a surprise to you considering the number of junk emails we all receive on a daily basis. I can assure you that this email is authentic and I would appreciate it if the content of this letter is kept strictly confidential and respects the integrity of the information. Nevertheless, I have decided to contact you due to the urgency of this transaction. Let me start by introducing myself, I am Mr. James Phillip Owen, an account manager in one of the banks here in the United Kingdom. I have worked a little more than 15 years now. I am contacting you concerning an abandoned consignment containing the sum of £10 million British Pounds. I was the account manager to Late Mr. Philemon Juan Smith, a foreign contractor with the department of works and housing who has an investment account with my bank; I encouraged him to consider various growths of funds with prime ratings, then he invested £10million, based on my advice, we were able to spin the money around various opportunities and made attractive margins for the first few months of our operation. The accrued profit and interest plus capital amount to £17,352,110 (Seventeen million, three hundred and fifty-two thousand, one hundred and ten British Pounds). In mid-2007, he instructed that the principal sum of (£10M) be liquidated and made available in cash because he needed to make an urgent investment requiring cash payment of (£10M), we, however, assisted him and made the cash available in a consignment for him. After a few months; the management of my bank sent several notices to inform him about the cash but without response, on further inquiries we found out that my client was poisoned by the same people he wanted to do business with, that made his request for cash payment for the business. He died without leaving a WILL and several efforts were made to find his extended family but without success. Because of the sensitive nature of private banking, most customers do not nominate next of kin in their investment, also usually in most cases leave their WILLS in our care, in this case; the deceased client died intestate. It is quite clear now that our dear client died with no identifiable family member. According to practice, the Private banking sector will by the end of the year of 2020 broadcast a request for a statement of claim to my Bank, failing to receive viable claims they will probably revert the deposit to the ownership of the UK Government Treasury department according to United Kingdom Banking and financial law. I am proposing that you stand as the business associate/next of kin to the late deceased (Mr. Philemon Juan Smith) and after the successful execution of the business deal, the funds will be shared in the ratio of 50/50. I want you to know that I have done my homework already before contacting you. Although the project is CAPITAL INTENSIVE, I will be able to pull it through following proper banking and legal Channels with your assistance on your end. This claim will be executed without breaching any UK laws and success is guaranteed if we cooperate on this. An opportunity like this only comes once in a lifetime. I would want you to think about this and let me know your decision because such a deal happens in the banking industry but only the outside world is not aware. If you give me a positive response, I will give you the relevant INFORMATION for the successful completion of this deal and we both enjoy it in peace. All I require from you is honesty/sincerity; I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law. If you give me positive signals, I will initiate this process towards a conclusion. Kindly treat this proposal with utmost confidentiality and urgency for a 100% success. Sincerely, James Phillip Owen
RE: [PATCH] char: ppdev: check if ioctl argument is present and valid
From: Arnd Bergmann
> Sent: 24 October 2020 20:21
> To: harshal chaudhari
> Cc: David Laight ; Greg KH
> ; Sudip Mukherjee
> ; linux-kernel
> Subject: Re: [PATCH] char: ppdev: check if ioctl argument is present and valid
>
> On Sat, Oct 24, 2020 at 5:54 PM harshal chaudhari
> wrote:
> > On Tue, Oct 13, 2020 at 4:42 PM David Laight
> > wrote:
>
> > So I am a little bit confused about this check whether it's required or not
> > Please could you point me in the right direction?
> >
> > In any case, thanks for your help ...
> >
> > Here is a driver source located in: linux/drivers/misc/xilinx_sdfec.c
> >
> > static long xsdfec_dev_ioctl(struct file *fptr, unsigned int cmd,
> > unsigned long data)
> > {
> > struct xsdfec_dev *xsdfec;
> > void __user *arg = NULL;
> > int rval = -EINVAL;
> >
> > if (_IOC_TYPE(cmd) != XSDFEC_MAGIC)
> >return -ENOTTY;
> >
> > /* check if ioctl argument is present and valid */
> > if (_IOC_DIR(cmd) != _IOC_NONE)
> > {
> > arg = (void __user *)data;
> > if (!arg)
> >return rval;
> > }
> >
>
> All of this can be removed, and replaced with unconditional
>
> void __user *arg = (void __user *)data;
> int rval;
>
> with an "rval = -ENOTTY" added in the 'default' case. This will
> make it behave more like other drivers, returning -ENOTTY for
> any unknown ioctl command, and returning -EFAULT for all
> invalid pointers, including NULL.
Yep, the thing to remember is that even if you actually
verified that the user buffer could be accessed on entry
to the ioctl code another application thread could unmap
the memory area before you do a later access.
What you may want to do is copy the user buffer into a
kernel buffer at the top of the ioctl code and write it
back at the bottom.
But do make absolutely sure you don't overflow the kernel
buffer of access beyond its end.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: Segher Boessenkool > Sent: 24 October 2020 18:29 > > On Fri, Oct 23, 2020 at 09:28:59PM +, David Laight wrote: > > From: Segher Boessenkool > > > Sent: 23 October 2020 19:27 > > > On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote: > > > > On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote: > > > > On arm64 when callee expects a 32bit argument, the caller is *not* > > > > responsible > > > > for clearing the upper half of 64bit register used to pass the value - > > > > it only > > > > needs to store the actual value into the lower half. The callee must > > > > consider > > > > the contents of the upper half of that register as undefined. See > > > > AAPCS64 (e.g. > > > > https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#parameter-passing-rules > > > > ); AFAICS, the relevant bit is > > > > "Unlike in the 32-bit AAPCS, named integral values must be > > > > narrowed by > > > > the callee rather than the caller." > > > > > > Or the formal rule: > > > > > > C.9 If the argument is an Integral or Pointer Type, the size of the > > > argument is less than or equal to 8 bytes and the NGRN is less > > > than 8, the argument is copied to the least significant bits in > > > x[NGRN]. The NGRN is incremented by one. The argument has now > > > been allocated. > > > > So, in essence, if the value is in a 64bit register the calling > > code is independent of the actual type of the formal parameter. > > Clearly a value might need explicit widening. > > No, this says that if you pass a 32-bit integer in a 64-bit register, > then the top 32 bits of that register hold an undefined value. That's sort of what I meant. The 'normal' junk in the hight bits will there because the variable in the calling code is wider. > > I've found a copy of the 64 bit arm instruction set. > > Unfortunately it is alpha sorted and repetitive so shows none > > of the symmetry and makes things difficult to find. > > All of this is ABI, not ISA. Look at the AAPCS64 pointed to above. > > > But, contrary to what someone suggested most register writes > > (eg from arithmetic) seem to zero/extend the high bits. > > Everything that writes a "w" does, yes. But that has nothing to do with > the parameter passing rules, that is ABI. It just means that very often > a 32-bit integer will be passed zero-extended in a 64-bit register, but > that is just luck (or not, it makes finding bugs harder ;-) ) Working out why the code is wrong is more of an ISA issue than an ABI one. It may be an ABI one, but the analysis is ISA. I've written a lot of asm over the years - decoding compiler generated asm isn't that hard. At least ARM doesn't have annulled delay slots. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] ARM: dts: Add empty "chosen" node to WM8xxx device trees
On Fri, Oct 09, 2020 at 10:57:42AM -0600, Brigham Campbell wrote:
> The following patch is a bug fix for an issue introduced by commit
> abe60a3a7afb4058278864aa18c5faf62094c11a which removed the deprecated
> device tree skeletons.
>
> For the devices corresponding to these device trees, an updated version
> of U-Boot is not available. Therefore, we must append DTBs to the kernel
> instead of counting on the bootloader to load one into memory and pass
> the pointer to the kernel during init.
>
> For some reason, when this method of appending DTBs to the kernel is
> used with any revision after abe60a3a7, the DTB seems to load correctly,
> but the kernel parameters aren't loaded correctly. Regardless of whether
> the kernel parameters are built into the kernel or passed in via U-Boot,
> they simply aren't registered by the running kernel.
>
> Adding an empty "chosen" node to the device tree fixes this issue. I've
> tested this with a WM8650-based laptop. Regrettably, I'd be lying if I
> said that I know exactly why this fixes the problem. However, I know
> that this solution works. I'm happy to hear suggestions/ridicule
> regarding these changes.
>
> Finally, I have my suspicions that the WM8xxx series devices aren't the
> only ones affected by this issue. I think this solution, if acceptable,
> could be applied to other devices which may or may not be having issues
> related to appended DTBs and kernel parameters. Perhaps other devices
> which commit abe60a3a7 changed?
>
> This is my first patch submission to the Linux kernel, so please tear it
> apart. Let me know what I've done incorrectly. And thanks, Alexey, for
> helping me along. I have much to learn and I wouldn't have made it half
> as far without his patience.
>
> Thanks,
> Brigham Campbell
>
> Signed-off-by: Brigham Campbell
>
> ---
> arch/arm/boot/dts/wm8505.dtsi | 2 ++
> arch/arm/boot/dts/wm8650.dtsi | 2 ++
> arch/arm/boot/dts/wm8850.dtsi | 2 ++
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> index 168cd12b07bc..2b814b48b458 100644
> --- a/arch/arm/boot/dts/wm8505.dtsi
> +++ b/arch/arm/boot/dts/wm8505.dtsi
> @@ -10,6 +10,8 @@ / {
> #size-cells = <1>;
> compatible = "wm,wm8505";
>
> + chosen {};
> +
> cpus {
> #address-cells = <0>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
> index bc057b6f7d16..a68c82c8035e 100644
> --- a/arch/arm/boot/dts/wm8650.dtsi
> +++ b/arch/arm/boot/dts/wm8650.dtsi
> @@ -10,6 +10,8 @@ / {
> #size-cells = <1>;
> compatible = "wm,wm8650";
>
> + chosen {};
> +
> cpus {
> #address-cells = <0>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
> index 65c9271050e6..c864883ae777 100644
> --- a/arch/arm/boot/dts/wm8850.dtsi
> +++ b/arch/arm/boot/dts/wm8850.dtsi
> @@ -10,6 +10,8 @@ / {
> #size-cells = <1>;
> compatible = "wm,wm8850";
>
> + chosen {};
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.28.0
>
Sorry to generate another notification, but I don't believe I've
recieved a response on this patch in the ~two weeks it's been up. Did I
format something incorrectly or have I sent it to the wrong addresses?
Maybe the relevant maintainer has just been busy?
Thanks,
Brigham Campbell
Re: [RFC 0/3] clk: imx: Implement blk-ctl driver for i.MX8MN
On Sat, Oct 24, 2020 at 3:23 PM Abel Vesa wrote:
>
> On 20-10-24 11:20:12, Adam Ford wrote:
> > There are some less-documented registers which control clocks and
> > resets for the multimedia block which controls the LCDIF, ISI, MIPI
> > CSI, and MIPI DSI.
> >
> > The i.Mx8M Nano appears to have a subset of the i.MX8MP registers with
> > a couple shared registers with the i.MX8MM. This series builds on the
> > series that have been submitted for both of those other two platforms.
> >
> > This is an RFC because when enabling the corresponding DTS node, the
> > system freezes on power on. There are a couple of clocks that don't
> > correspond to either the imx8mp nor the imx8mm, so I might have something
> > wrong, and I was hoping for some constructive feedback in order to get
> > the imx8m Nano to a similar point of the Mini and Plus.
> >
>
> Thanks for the effort.
Sure thing!
>
> I'm assuming this relies on the following patchset, right ?
> https://lkml.org/lkml/2020/10/24/139
Abell,
Your link points right back to this e-mail. ;-)
I based this work off:
https://www.spinics.net/lists/arm-kernel/msg843906.html from Marek
which I beleive is based on
https://www.spinics.net/lists/arm-kernel/msg836165.html from you.
I also have a GPC patch series located:
https://www.spinics.net/lists/arm-kernel/msg847925.html
Together, both the GPC and the clk-blk driver should be able to pull
the multimedia block out of reset. Currently, the GPC can handle the
USB OTG and the GPU, but the LCDIF and MIPI DSI appear to be gated by
the clock block
My original patch RFC didn't include the imx8mn node, because it
hangs, but the node I added looks like:
media_blk_ctl: clock-controller@32e28000 {
compatible = "fsl,imx8mn-media-blk-ctl", "syscon";
reg = <0x32e28000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
I was hoping you might have some feedback on the 8mn clk-blk driver
since you did the 8mp clk-blk drive and they appear to be very
similar.
adam
>
> > Adam Ford (3):
> > dt-bindings: clock: imx8mn: Add media blk_ctl clock IDs
> > dt-bindings: reset: imx8mn: Add media blk_ctl reset IDs
> > clk: imx: Add blk-ctl driver for i.MX8MN
> >
> > drivers/clk/imx/clk-blk-ctl-imx8mn.c | 80
> > include/dt-bindings/clock/imx8mn-clock.h | 11
> > include/dt-bindings/reset/imx8mn-reset.h | 22 +++
> > 3 files changed, 113 insertions(+)
> > create mode 100644 drivers/clk/imx/clk-blk-ctl-imx8mn.c
> > create mode 100644 include/dt-bindings/reset/imx8mn-reset.h
> >
> > --
> > 2.25.1
> >
PROBLEM: Reiser4 hard lockup
Hello, # Intro Pardon my tardiness in reporting this, I was stalling my disk upgrade to help test a fix for a reiserfs problem. I needed to get my life going again before taking the time to report this. This is a heads up for a serious problem. I no longer use reiser4 anymore because I can't have my kernel hard and soft locking up within hours of booting and I don't use the 5.7.13. Therefore, I can't test a fix for this, but I am willing to test future releases of reiser4 on a test partition. The problem might lie elsewhere in the Linux kernel considering how many panics it threw before hard locking up, but I am starting with the reiser4 maintainer and ML because kernel 5.8.X without loading the reiser4 module has been quite stable. # 2. Description The Linux kernel hard and/or soft locks up only hours after booting when using reiser4. It throws several panics before hand. The applications that trigger this bug are rtorrent + dar + sync. # 3. Keywords hard lockup, soft lockup, reiser4, rcu # 4. Kernel information. 5.7.13 x86_64 # 5. Kernel without bug. NA # 6. Oops message. Way too big. See attached. Here's something to wet your tongue: [ 4483.173140] NMI backtrace for cpu 0 [ 4483.173143] CPU: 0 PID: 21593 Comm: dar Not tainted 5.7.13-nopreempt-Radeon-SI-dav10 #4 [ 4483.173144] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970A-DS3P, BIOS FD 02/26/2016 [ 4483.173145] Call Trace: [ 4483.173148] [ 4483.173153] dump_stack+0x66/0x8b [ 4483.173155] nmi_cpu_backtrace+0x89/0x90 [ 4483.173157] ? lapic_can_unplug_cpu+0x90/0x90 ... [ 4483.173213] jput_final+0x303/0x320 [reiser4] [ 4483.173220] reiser4_invalidate_list+0x3e/0x50 [reiser4] [ 4483.173228] reiser4_write_logs+0x76/0x560 [reiser4] ... [ 4557.097894] NMI watchdog: Watchdog detected hard LOCKUP on cpu 2 ... [ 4557.600871] __schedule+0x288/0x5d0 [ 4557.600874] schedule+0x4a/0xb0 [ 4557.600875] schedule_timeout+0x14a/0x300 ... # 7. Shell script to trigger the problem. I tried to create an artificial workload using dd, cp, sync, and other programs to cause the fault without success. # 8. Enviroment. % dar --version dar version 2.5.17, Copyright (C) 2002-2052 Denis Corbin Long options support : YES Using libdar 5.13.0 built with compilation time options: Libz compression (gzip) : YES Libbz2 compression (bzip2) : YES Liblzo2 compression (lzo): YES Liblzma compression (xz) : YES Strong encryption (libgcrypt): YES Public key ciphers (gpgme) : NO Extended Attributes support : YES Large files support (> 2GB) : YES ext2fs NODUMP flag support : YES Special allocation scheme: NO Integer size used: unlimited Thread safe support : YES Furtive read mode support: YES Linux ext2/3/4 FSA support : YES Mac OS X HFS+ FSA support: NO Detected system/CPU endian : little Posix fadvise support: YES Large dir. speed optimi. : YES Timestamp read accuracy : 1 microsecond Timestamp write accuracy : 1 microsecond Restores dates of symlinks : YES compiled the Nov 23 2018 with GNUC version 6.3.0 20170516 dar is part of the Disk ARchive suite (Release 2.5.17) % rtorrent -h Rakshasa's BitTorrent client version 0.9.6. % sync --version sync (GNU coreutils) 8.26 % mkfs.reiser4 --version mkfs.reiser4 1.1.0 Format release: 4.0.1 % fsck.reiser4 --version fsck.reiser4 1.1.0 Format release: 4.0.1 % head -n28 /proc/cpuinfo # The info in just repeated for all the% cores. processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping: 0 microcode : 0x1bf cpu MHz : 2011.953 cache size : 512 KB physical id : 0 siblings: 5 core id : 0 cpu cores : 5 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter bugs: tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2 bogomips: 7368.27 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate cpb [8.3.] Module information (from /proc/modules): Not available. If you really need this I can boot the old kernel and insert mod. Here's the linked in modules, I it's probably equivalent: nls_iso8859_1 nls_cp437 fuse snd_emu10k1_synth
Re: [RFC PATCH 4/6] ethernet: m10-retimer: add support for retimers on Intel MAX 10 BMC
On Sat, Oct 24, 2020 at 10:36:36AM -0700, Tom Rix wrote: > > On 10/24/20 9:39 AM, Andrew Lunn wrote: > > On Sat, Oct 24, 2020 at 08:03:51AM -0700, Tom Rix wrote: > >> On 10/23/20 1:45 AM, Xu Yilun wrote: > >>> This driver supports the ethernet retimers (Parkvale) for the Intel PAC > >>> (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC. > >> Parkvale is a code name, it would be better if the public name was used. > >> > >> As this is a physical chip that could be used on other cards, > >> > >> I think the generic parts should be split out of intel-m10-bmc-retimer.c > >> > >> into a separate file, maybe retimer-c827.c > > This driver is not really a driver for the Parkvale. That driver is > > hidden away in the BMC. So we need to be a bit careful with the name, > > leaving it available for when somebody writes a real Linux driver for > > retimer. > > Then the parkvale verbage should be removed. > > And the doc ascii diagram be updated with a > > +-+ > > |Â BMCÂ Â Â | > > | retimer | > > +-+ Yes, i would like to get a better understanding of what the BMC is actually doing, particularly the SFP. Given my current limited understanding of the driver architecture, i'm not sure it is flexiable enough to handle other cards where Linux is controlling the SFPs, the retimer, the host side PCS of the Arria 10, etc. Once Linux is driving all that, you need phylink, not phylib. The proposed phylib driver/mdio bus driver actually looks like a hack. Andrew
Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows
On 24/10/2020 16:14, Sakari Ailus wrote:
> Hi Daniel,
>
> Thanks for the update.
Thanks for the comments as always
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Author: Dan Scally
> /* Author: ... */
>
> But not the SPDX tag.
Weird - okedokey
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "cio2-bridge.h"
>> +
>> +/*
>> + * Extend this array with ACPI Hardware ID's of devices known to be
>> + * working
>> + */
>> +static const char * const supported_devices[] = {
>> +"INT33BE",
>> +"OVTI2680",
>> +};
>> +
>> +static struct software_node cio2_hid_node = { CIO2_HID };
>> +
>> +static struct cio2_bridge bridge;
>> +
>> +static const char * const port_names[] = {
>> +"port0", "port1", "port2", "port3"
>> +};
>> +
>> +static const struct property_entry remote_endpoints[] = {
> How about another dimension, for local and remote? Or make it a struct with
> local and remote fields. Perhaps a struct would be better?
>
> This could also be nicer to initialise in a function.
Sure; a struct probably would be cleaner I agree. I shall make that change
>> +static int create_fwnode_properties(struct sensor *sensor,
>> +struct sensor_bios_data *ssdb)
>> +{
>> +struct property_entry *cio2_properties = sensor->cio2_properties;
>> +struct property_entry *dev_properties = sensor->dev_properties;
>> +struct property_entry *ep_properties = sensor->ep_properties;
>> +int i;
>> +
>> +/* device fwnode properties */
>> +memset(dev_properties, 0, sizeof(struct property_entry) * 3);
> I'd put them all to the struct itself. Then the compiler will be able to
> check array indices.
Makes sense; I think I was just trying to save line length in the rest
of that function by that.
>> +
>> +dev_properties[0] = PROPERTY_ENTRY_U32("clock-frequency",
>> + ssdb->mclkspeed);
>> +dev_properties[1] = PROPERTY_ENTRY_U8("rotation", ssdb->degree);
>> +
>> +/* endpoint fwnode properties */
>> +memset(ep_properties, 0, sizeof(struct property_entry) * 4);
>> +
>> +sensor->data_lanes = kmalloc_array(ssdb->lanes, sizeof(u32),
>> + GFP_KERNEL);
>> +
>> +if (!sensor->data_lanes)
>> +return -ENOMEM;
>> +
>> +for (i = 0; i < ssdb->lanes; i++)
>> +sensor->data_lanes[i] = i + 1;
>> +
>> +ep_properties[0] = PROPERTY_ENTRY_U32("bus-type", 5);
>> +ep_properties[1] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> +sensor->data_lanes,
>> +ssdb->lanes);
>> +ep_properties[2] = remote_endpoints[(bridge.n_sensors * 2) +
>> ENDPOINT_SENSOR];
>> +
>> +/* cio2 endpoint props */
>> +memset(cio2_properties, 0, sizeof(struct property_entry) * 3);
>> +
>> +cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> + sensor->data_lanes,
>> + ssdb->lanes);
>> +cio2_properties[1] = remote_endpoints[(bridge.n_sensors * 2) +
>> ENDPOINT_CIO2];
>> +
>> +return 0;
>> +}
>> +
>> +static int create_connection_swnodes(struct sensor *sensor,
>> + struct sensor_bios_data *ssdb)
>> +{
>> +struct software_node *nodes = sensor->swnodes;
>> +
>> +memset(nodes, 0, sizeof(struct software_node) * 6);
> Could you make the index an enum, and add an item to the end used to tell
> the number of entries. It could be called e.g. NR_OF_SENSOR_SWNODES.
Ooh I like that, it's neat; thanks - will do.
>> +int cio2_bridge_build(struct pci_dev *cio2)
>> +{
>> +struct fwnode_handle *fwnode;
>> +int ret;
>> +
>> +pci_dev_get(cio2);
> Could you check that this isn't used by more than one user? The current
> implementation assumes that. I'm not sure if there could be more instances
> of CIO2 but if there were, that'd be an issue currently.
I can check; can't think of anything better than just failing out if it
turns out to be in use already though - any ideas or is that appropriate?
>> +struct sensor {
> How about calling this e.g. cio2_sensor? sensor is rather generic.
Yup, will probably prefix all such generically named vars with cio2_*
and functions with cio2_bridge_*().
>> +char name[ACPI_ID_LEN];
>> +struct device *dev;
>> +struct acpi_device *adev;
>> +struct software_node swnodes[6];
>> +struct property_entry dev_properties[3];
>> +struct property_entry ep_properties[4];
>> +struct property_entry cio2_properties[3];
>> +u32 *data_lanes;
> The maximum is four so you could as well make this static.
Ack
>> +};
>> +
>> +struct cio2_bridge {
>> +int n_sensors;
> Do you need negative values? %u, too, if not.
I do not, I will switch to using unsigned.
>> diff --git
Re: [RFC 0/3] clk: imx: Implement blk-ctl driver for i.MX8MN
On 20-10-24 11:20:12, Adam Ford wrote: > There are some less-documented registers which control clocks and > resets for the multimedia block which controls the LCDIF, ISI, MIPI > CSI, and MIPI DSI. > > The i.Mx8M Nano appears to have a subset of the i.MX8MP registers with > a couple shared registers with the i.MX8MM. This series builds on the > series that have been submitted for both of those other two platforms. > > This is an RFC because when enabling the corresponding DTS node, the > system freezes on power on. There are a couple of clocks that don't > correspond to either the imx8mp nor the imx8mm, so I might have something > wrong, and I was hoping for some constructive feedback in order to get > the imx8m Nano to a similar point of the Mini and Plus. > Thanks for the effort. I'm assuming this relies on the following patchset, right ? https://lkml.org/lkml/2020/10/24/139 > Adam Ford (3): > dt-bindings: clock: imx8mn: Add media blk_ctl clock IDs > dt-bindings: reset: imx8mn: Add media blk_ctl reset IDs > clk: imx: Add blk-ctl driver for i.MX8MN > > drivers/clk/imx/clk-blk-ctl-imx8mn.c | 80 > include/dt-bindings/clock/imx8mn-clock.h | 11 > include/dt-bindings/reset/imx8mn-reset.h | 22 +++ > 3 files changed, 113 insertions(+) > create mode 100644 drivers/clk/imx/clk-blk-ctl-imx8mn.c > create mode 100644 include/dt-bindings/reset/imx8mn-reset.h > > -- > 2.25.1 >
Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION
On Sat, Oct 24, 2020 at 08:47:28AM -0700, Andy Lutomirski wrote: > On Sat, Oct 24, 2020 at 4:34 AM Jarkko Sakkinen wrote: > > > > On Fri, Oct 23, 2020 at 07:19:05AM -0700, Dave Hansen wrote: > > > On 10/23/20 3:17 AM, Jarkko Sakkinen wrote: > > > > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave Hansen wrote: > > > >> On 10/2/20 9:50 PM, Jarkko Sakkinen wrote: > > > >>> + * Failure to explicitly request access to a restricted attribute > > > >>> will cause > > > >>> + * sgx_ioc_enclave_init() to fail. Currently, the only restricted > > > >>> attribute > > > >>> + * is access to the PROVISION_KEY. > > > >> Could we also justify why access is restricted, please? Maybe: > > > >> > > > >>Access is restricted because PROVISION_KEY is burned uniquely > > > >>into each each processor, making it a perfect unique identifier > > > >>with privacy and fingerprinting implications. > > > >> > > > >> Are there any other reasons for doing it this way? > > > > AFAIK, if I interperet the SDM correctl, PROVISION_KEY and > > > > PROVISION_SEALING_KEY also have random salt added, i.e. they change > > > > every boot cycle. > > > > > > > > There is "RAND = yes" on those keys in Table 40-64 of Intel SDM volume > > > > 3D :-) > > > > > > Does that mean there are no privacy implications from access to the > > > provisioning keys? If that's true, why do we need a separate permission > > > framework for creating provisioning enclaves? > > > > As I've understood it, the key material for those keys is not even > > required in the current SGX architecture, it was used in the legacy EPID > > scheme, but the attribute itself is useful. > > > > Let's assume that we have some sort of quoting enclave Q, which guards a > > public key pair, which signs quotes of other enclaves. Let's assume we > > have an attestation server A, which will enable some capabilities [*], > > if it receives a quote signed with that public key pair. > > > > 1. E gets the report key with EGETKEY. > > 2. E constructs REPORTDATA (37.16) and TARGETINFO (37.17) structures. > >The former describes the enclaves contents and attributes and latter > >the target, i.e. Q in this artitificial example. > > 3. E calls EREPORT to generate a structure called REPORT MAC'd with the > >*targets* report key. It knows, which key to usue from REPORTDATA. > > 4. The runtime will then pass this to Q. > > 5. Q will check if ATTRIBUTE.PROVISION_KEY is set. If it is, Q will > >know that the enclave is allowed to get attested. Then it will > >sign the report with the guarded public key pair and send it to > >the attestation server. > > I think you have this a little bit off. AIUI E won't have > ATTRIBUTE.PROVISION_KEY set -- Q will. Q uses the provisioning key to > convince an Intel server that it's running on a genuine Intel CPU, and > the Intel server will return a signed certificate that Q can chain off > of to generate attestations for E. Right, I was confused by that RAND column, until Jethro corrected me. Actually, quoting enclave (QE) authorizes itself with a provisioning certification enclave (PCE), which holds certificates and revocation lists for provisioning secrets unique to a CPU. And the sequence that I described happens between PCE and QE. It accepts requests from enclaves with ATTRIBUTES.PROVISION key bits set to 1 according to: https://software.intel.com/content/dam/develop/external/us/en/documents/intel-sgx-support-for-third-party-attestation-801017.pdf The source code for the reference is available here: https://github.com/intel/SGXDataCenterAttestationPrimitives And binaries are here: https://01.org/intel-softwareguard-extensions/downloads/intel-sgx-dcap-1.6-release They are provided for the inevitable reason that, it is the way bind to the hardware, i.e. proof that you are running on a genuine CPU. The network part is that PCE and QE can certify to an application, if an enclave running in a different computer is an enclave. > Dave, I would rephrase what you're saying a bit. The PROVISION_KEY > attribute allows enclaves to access keys that are unique to a > processor and unchangeable. Unlike other SGX keys, these keys are not > affected by OWNER_EPOCH changes and therefore cannot be reset. /Jarkko
Re: [PATCH v3] checkpatch: extend attributes check to handle more patterns
On Sat, Oct 24, 2020 at 2:36 PM Dwaipayan Ray wrote:
>
> It is generally preferred that the macros from
> include/linux/compiler_attributes.h are used, unless there
> is a reason not to.
>
> checkpatch currently checks __attribute__ for each of
> packed, aligned, printf, scanf, and weak. Other declarations
> in compiler_attributes.h are not handled.
>
> Add a generic test to check the presence of such attributes.
> Some attributes require more specific handling and are kept
> separate.
>
> New attributes which are now handled are:
>
> __alias__(#symbol)
> __always_inline__
> __assume_aligned__(a, ## __VA_ARGS__)
> __cold__
> __const__
> __copy__(symbol)
> __designated_init__
> __externally_visible__
> __gnu_inline__
> __malloc__
> __mode__(x)
> __no_caller_saved_registers__
> __noclone__
> __fallthrough__
> __noinline__
> __nonstring__
> __noreturn__
> __pure__
> __unused__
> __used__
>
> Link:
> https://lore.kernel.org/linux-kernel-mentees/3ec15b41754b01666d94b76ce51b9832c2dd577a.ca...@perches.com/
> Suggested-by: Joe Perches
> Signed-off-by: Dwaipayan Ray
> ---
> scripts/checkpatch.pl | 105 +++---
> 1 file changed, 69 insertions(+), 36 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 7e505688257a..01d83d345b4c 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -6155,50 +6155,83 @@ sub process {
> }
> }
>
> -# Check for __attribute__ packed, prefer __packed
> +# Check for compiler attributes
> if ($realfile !~ m@\binclude/uapi/@ &&
> - $line =~ /\b__attribute__\s*\(\s*\(.*\bpacked\b/) {
> - WARN("PREFER_PACKED",
> -"__packed is preferred over
> __attribute__((packed))\n" . $herecurr);
> - }
> + $line =~ /__attribute__\s*\(\s*($balanced_parens)\s*\)/) {
> + my $attr = $1;
> + $attr =~ s/\s*\(\s*(.*)\)\s*/$1/;
> +
> + my %attr_list = (
> + "alias" => "__alias",
> + "aligned" =>
> "__aligned",
> + "always_inline" =>
> "__always_inline",
> + "assume_aligned"=>
> "__assume_aligned",
> + "cold" => "__cold",
> + "const" => "__const",
> + "copy" => "__copy",
> + "designated_init" =>
> "__designated_init",
> + "externally_visible"=>
> "__visible",
> + "fallthrough" =>
> "fallthrough",
> + "gnu_inline"=>
> "__gnu_inline",
> + "malloc"=> "__malloc",
> + "mode" => "__mode",
> + "no_caller_saved_registers" =>
> "__no_caller_saved_registers",
> + "noclone" =>
> "__noclone",
> + "noinline" => "noinline",
> + "nonstring" =>
> "__nonstring",
> + "noreturn" =>
> "__noreturn",
> + "packed"=> "__packed",
> + "pure" => "__pure",
> + "used" => "__used"
> + );
> +
> + if ($attr =~ /^(\w+)\s*(${balanced_parens})?/) {
> + my $curr_attr = $1;
> + my $params = '';
> + $params = $2 if defined($2);
> + $curr_attr =~ s/^[\s_]+|[\s_]+$//g;
> +
> + if (exists($attr_list{$curr_attr})) {
> + my $new = $attr_list{$curr_attr};
> + WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
> +"$new$params is preffered over
> __attribute__(($attr))\n" . $herecurr);
> + }
> + }
>
> -# Check for __attribute__ aligned, prefer __aligned
> - if ($realfile !~ m@\binclude/uapi/@ &&
> - $line =~ /\b__attribute__\s*\(\s*\(.*aligned/) {
> - WARN("PREFER_ALIGNED",
> -"__aligned(size) is preferred over
> __attribute__((aligned(size)))\n" . $herecurr);
> -
Re: [PATCH] char: ppdev: check if ioctl argument is present and valid
On Sun, Oct 25, 2020 at 12:51 AM Arnd Bergmann wrote:
>
> On Sat, Oct 24, 2020 at 5:54 PM harshal chaudhari
> wrote:
> > On Tue, Oct 13, 2020 at 4:42 PM David Laight
> > wrote:
>
> > So I am a little bit confused about this check whether it's required or not
> > Please could you point me in the right direction?
> >
> > In any case, thanks for your help ...
> >
> > Here is a driver source located in: linux/drivers/misc/xilinx_sdfec.c
> >
> > static long xsdfec_dev_ioctl(struct file *fptr, unsigned int cmd,
> > unsigned long data)
> > {
> > struct xsdfec_dev *xsdfec;
> > void __user *arg = NULL;
> > int rval = -EINVAL;
> >
> > if (_IOC_TYPE(cmd) != XSDFEC_MAGIC)
> >return -ENOTTY;
> >
> > /* check if ioctl argument is present and valid */
> > if (_IOC_DIR(cmd) != _IOC_NONE)
> > {
> > arg = (void __user *)data;
> > if (!arg)
> >return rval;
> > }
> >
>
> All of this can be removed, and replaced with unconditional
>
> void __user *arg = (void __user *)data;
> int rval;
>
> with an "rval = -ENOTTY" added in the 'default' case. This will
> make it behave more like other drivers, returning -ENOTTY for
> any unknown ioctl command, and returning -EFAULT for all
> invalid pointers, including NULL.
>
> xsdfec_dev_compat_ioctl() can removed as well, with the file operations
> changed to an unconditional (removing the #ifdef)
>
> .compat_ioctl = compat_ptr_ioctl(),
>
> This will not affect behavior, it's just another simplification.
Thanks a lot Arnd. Got the point. and i will make the change
and i will send it to relevant maintainers of that driver file.
Once again thanks!
> Arnd
Re: [RFC net-next 0/5] net: phy: add support for shared interrupts
On Sat, Oct 24, 2020 at 07:09:53PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, Oct 24, 2020 at 07:17:05PM +0200, Andrew Lunn wrote:
> > > - Every PHY driver gains a .handle_interrupt() implementation that, for
> > > the most part, would look like below:
> > >
> > > irq_status = phy_read(phydev, INTR_STATUS);
> > > if (irq_status < 0) {
> > > phy_error(phydev);
> > > return IRQ_NONE;
> > > }
> > >
> > > if (irq_status == 0)
> > > return IRQ_NONE;
> > >
> > > phy_trigger_machine(phydev);
> > >
> > > return IRQ_HANDLED;
> >
> > Hi Ioana
> >
> > It looks like phy_trigger_machine(phydev) could be left in the core,
> > phy_interrupt(). It just needs to look at the return code, IRQ_HANDLED
> > means trigger the state machine.
>
> Is this appropriate for things such as the existing user of
> handle_interrupt - vsc8584_handle_interrupt() ?
Ah, yes, you are likely to get a lot more ptp interrupts than link
up/down interrupts, and there is no point running the phy state
machine after each ptp interrupt. So Ioana's structure is better.
And now that phy_trigger_machine is exported, that driver can swap
from phy_mac_interrupt() to phy_trigger_machine().
Andrew
[PATCH v5 2/2] regulator: mt6392: Add support for MT6392 regulator
The MT6392 is a regulator found on boards based on the MediaTek
MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
connectcts as a slave to a SoC using SPI, wrapped inside PWRAP.
Signed-off-by: Fabien Parent
---
V5:
* Removed unneeded code
* Fix indentation
* Rebased
* Switched some regulator to be linear
* Use C++ style header style
* Fix copyrights
V4:
* No change
V3:
* fix regulator's of_match following the renaming of the of nodes.
V2:
* no changes
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6392-regulator.c | 454 +
include/linux/regulator/mt6392-regulator.h | 40 ++
4 files changed, 504 insertions(+)
create mode 100644 drivers/regulator/mt6392-regulator.c
create mode 100644 include/linux/regulator/mt6392-regulator.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 020a00d6696b..e689c5a85197 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -739,6 +739,15 @@ config REGULATOR_MT6380
This driver supports the control of different power rails of device
through regulator interface.
+config REGULATOR_MT6392
+ tristate "MediaTek MT6392 PMIC"
+ depends on MFD_MT6397
+ help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6392 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
config REGULATOR_MT6397
tristate "MediaTek MT6397 PMIC"
depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6ebae516258e..1bac57a5bfcf 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
+obj-$(CONFIG_REGULATOR_MT6392) += mt6392-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
diff --git a/drivers/regulator/mt6392-regulator.c
b/drivers/regulator/mt6392-regulator.c
new file mode 100644
index ..25e620944b2a
--- /dev/null
+++ b/drivers/regulator/mt6392-regulator.c
@@ -0,0 +1,454 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2020 MediaTek Inc.
+// Copyright (c) 2020 BayLibre, SAS.
+// Author: Chen Zhong
+// Author: Fabien Parent
+//
+// Based on mt6397-regulator.c
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MT6392_BUCK_MODE_AUTO 0
+#define MT6392_BUCK_MODE_FORCE_PWM 1
+#define MT6392_LDO_MODE_NORMAL 0
+#define MT6392_LDO_MODE_LP 1
+
+/*
+ * MT6392 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6392_regulator_info {
+ struct regulator_desc desc;
+ u32 qi;
+ u32 vselon_reg;
+ u32 vselctrl_reg;
+ u32 vselctrl_mask;
+ u32 modeset_reg;
+ u32 modeset_mask;
+};
+
+#define MT6392_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \
+ vosel, vosel_mask, voselon, vosel_ctrl, \
+ _modeset_reg, _modeset_mask)\
+[MT6392_ID_##vreg] = { \
+ .desc = { \
+ .name = #vreg, \
+ .of_match = of_match_ptr(match),\
+ .ops = _volt_range_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6392_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = (max - min)/step + 1, \
+ .linear_ranges = volt_ranges, \
+ .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
+ .vsel_reg = vosel, \
+ .vsel_mask = vosel_mask,\
+ .enable_reg = enreg,\
+ .enable_mask = BIT(0), \
+ },
[PATCH v5 1/2] dt-bindings: regulator: add support for MT6392
Add binding documentation of the regulator for MT6392 SoCs.
Signed-off-by: Fabien Parent
Reviewed-by: Rob Herring
---
v5:
* No change
v4:
* No change
v3:
* No change
v2:
* Use 'pmic' as node name for the pmic.
* Use 'regulators' as node name for the regulators
* use dash instead of underscore for regulator's node names.
.../bindings/regulator/mt6392-regulator.txt | 220 ++
1 file changed, 220 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/mt6392-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/mt6392-regulator.txt
b/Documentation/devicetree/bindings/regulator/mt6392-regulator.txt
new file mode 100644
index ..d03c0707fabc
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6392-regulator.txt
@@ -0,0 +1,220 @@
+Mediatek MT6392 Regulator
+
+Required properties:
+- compatible: "mediatek,mt6392-regulator"
+- mt6392regulator: List of regulators provided by this controller. It is named
+ according to its regulator type, buck_ and ldo_.
+ The definition for each of these nodes is defined using the standard binding
+ for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+ buck_vproc, buck_vsys, buck_vcore
+LDO:
+ ldo_vxo22, ldo_vaud22, ldo_vcama, ldo_vaud28, ldo_vadc18, ldo_vcn35,
+ ldo_vio28. ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+ ldo_vcn18, ldo_vcamaf, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio, ldo_vm25,
+ ldo_vefuse
+
+Example:
+ pmic {
+ compatible = "mediatek,mt6392", "mediatek,mt6323";
+ mediatek,system-power-controller;
+
+ regulator {
+ compatible = "mediatek,mt6392-regulator";
+
+ mt6392_vproc_reg: buck-vproc {
+ regulator-name = "buck_vproc";
+ regulator-min-microvolt = < 70>;
+ regulator-max-microvolt = <135>;
+ regulator-ramp-delay = <12500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6392_vsys_reg: buck-vsys {
+ regulator-name = "buck_vsys";
+ regulator-min-microvolt = <140>;
+ regulator-max-microvolt = <2987500>;
+ regulator-ramp-delay = <25000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6392_vcore_reg: buck-vcore {
+ regulator-name = "buck_vcore";
+ regulator-min-microvolt = < 70>;
+ regulator-max-microvolt = <135>;
+ regulator-ramp-delay = <12500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6392_vxo22_reg: ldo-vxo22 {
+ regulator-name = "ldo_vxo22";
+ regulator-min-microvolt = <220>;
+ regulator-max-microvolt = <220>;
+ regulator-enable-ramp-delay = <110>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6392_vaud22_reg: ldo-vaud22 {
+ regulator-name = "ldo_vaud22";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <220>;
+ regulator-enable-ramp-delay = <264>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6392_vcama_reg: ldo-vcama {
+ regulator-name = "ldo_vcama";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-enable-ramp-delay = <264>;
+ };
+
+ mt6392_vaud28_reg: ldo-vaud28 {
+ regulator-name = "ldo_vaud28";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-enable-ramp-delay = <264>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6392_vadc18_reg: ldo-vadc18 {
+
Re: [linux-sunxi] [PATCH 10/10] arm64: dts: allwinner: a64: bananapi-m64: Enable RGMII RX/TX delay on PHY
On Sun, Oct 25, 2020 at 12:25:15AM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Bananapi M64 has the RX and TX delays
> enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
>
> Fix the phy-mode description to correct reflect this so that the
> implementation doesn't reconfigure the delays incorrectly. This
> happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
> rx/tx delay config").
>
> Fixes: e7295499903d ("arm64: allwinner: bananapi-m64: Enable dwmac-sun8i")
> Fixes: 94f442886711 ("arm64: dts: allwinner: A64: Restore EMAC changes")
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> index 3ea5182ca489..e5e840b9fbb4 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> @@ -105,7 +105,7 @@ {
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> phy-handle = <_rgmii_phy>;
> phy-supply = <_dc1sw>;
> status = "okay";
> --
> 2.28.0
Tested-by: Corentin Labbe
Thanks
Re: [GIT PULL] libata fixes for 5.10-rc1
The pull request you sent on Sat, 24 Oct 2020 09:13:29 -0600: > git://git.kernel.dk/linux-block.git tags/libata-5.10-2020-10-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cb6b2897b9b425433ae31dc01f4e1d549f0028c8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] io_uring fixes for 5.10-rc1
The pull request you sent on Sat, 24 Oct 2020 09:13:33 -0600: > git://git.kernel.dk/linux-block.git tags/io_uring-5.10-2020-10-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/af0041875ce7f5a05362b884e90cf82c27876096 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v4 3/3] random32: add a selftest for the prandom32 code
Given that this code is new, let's add a selftest for it as well.
It doesn't rely on fixed sets, instead it picks 1024 numbers and
verifies that they're not more correlated than desired.
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
Cc: George Spelvin
Cc: Amit Klein
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Signed-off-by: Willy Tarreau
---
lib/random32.c | 56 ++
1 file changed, 56 insertions(+)
diff --git a/lib/random32.c b/lib/random32.c
index 7f047844e494..4d0e05e471d7 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -556,6 +557,61 @@ static void prandom_timer_start(struct
random_ready_callback *unused)
mod_timer(_timer, jiffies);
}
+#ifdef CONFIG_RANDOM32_SELFTEST
+/* Principle: True 32-bit random numbers will all have 16 differing bits on
+ * average. For each 32-bit number, there are 601M numbers differing by 16
+ * bits, and 89% of the numbers differ by at least 12 bits. Note that more
+ * than 16 differing bits also implies a correlation with inverted bits. Thus
+ * we take 1024 random numbers and compare each of them to the other ones,
+ * counting the deviation of correlated bits to 16. Constants report 32,
+ * counters 32-log2(TEST_SIZE), and pure randoms, around 6 or lower. With the
+ * u32 total, TEST_SIZE may be as large as 4096 samples.
+ */
+#define TEST_SIZE 1024
+static int __init prandom32_state_selftest(void)
+{
+ unsigned int x, y, bits, samples;
+ u32 xor, flip;
+ u32 total;
+ u32 *data;
+
+ data = kmalloc(sizeof(*data) * TEST_SIZE, GFP_KERNEL);
+ if (!data)
+ return 0;
+
+ for (samples = 0; samples < TEST_SIZE; samples++)
+ data[samples] = prandom_u32();
+
+ flip = total = 0;
+ for (x = 0; x < samples; x++) {
+ for (y = 0; y < samples; y++) {
+ if (x == y)
+ continue;
+ xor = data[x] ^ data[y];
+ flip |= xor;
+ bits = hweight32(xor);
+ total += (bits - 16) * (bits - 16);
+ }
+ }
+
+ /* We'll return the average deviation as 2*sqrt(corr/samples), which
+* is also sqrt(4*corr/samples) which provides a better resolution.
+*/
+ bits = int_sqrt(total / (samples * (samples - 1)) * 4);
+ if (bits > 6)
+ pr_warn("prandom32: self test failed (at least %u bits"
+ " correlated, fixed_mask=%#x fixed_value=%#x\n",
+ bits, ~flip, data[0] & ~flip);
+ else
+ pr_info("prandom32: self test passed (less than %u bits"
+ " correlated)\n",
+ bits+1);
+ kfree(data);
+ return 0;
+}
+core_initcall(prandom32_state_selftest);
+#endif /* CONFIG_RANDOM32_SELFTEST */
+
/*
* Start periodic full reseeding as soon as strong
* random numbers are available.
--
2.28.0
[PATCH v4 1/3] random32: make prandom_u32() output unpredictable
From: George Spelvin
Non-cryptographic PRNGs may have great statistical properties, but
are usually trivially predictable to someone who knows the algorithm,
given a small sample of their output. An LFSR like prandom_u32() is
particularly simple, even if the sample is widely scattered bits.
It turns out the network stack uses prandom_u32() for some things like
random port numbers which it would prefer are *not* trivially predictable.
Predictability led to a practical DNS spoofing attack. Oops.
This patch replaces the LFSR with a homebrew cryptographic PRNG based
on the SipHash round function, which is in turn seeded with 128 bits
of strong random key. (The authors of SipHash have *not* been consulted
about this abuse of their algorithm.) Speed is prioritized over security;
attacks are rare, while performance is always wanted.
Replacing all callers of prandom_u32() is the quick fix.
Whether to reinstate a weaker PRNG for uses which can tolerate it
is an open question.
Commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity") was an earlier attempt at a solution. This patch replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and
activity")
Signed-off-by: George Spelvin
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
[ willy: partial reversal of f227e3ec3b5c; moved SIPROUND definitions
to prandom.h for later use; merged George's prandom_seed() proposal;
inlined siprand_u32(); replaced the net_rand_state[] array with 4
members to fix a build issue; cosmetic cleanups to make checkpatch
happy; fixed RANDOM32_SELFTEST build ]
Signed-off-by: Willy Tarreau
---
drivers/char/random.c | 1 -
include/linux/prandom.h | 36 +++-
kernel/time/timer.c | 7 -
lib/random32.c | 464
4 files changed, 318 insertions(+), 190 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d20ba1b104ca..2a41b21623ae 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1277,7 +1277,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
fast_mix(fast_pool);
add_interrupt_bench(cycles);
- this_cpu_add(net_rand_state.s1, fast_pool->pool[cycles & 3]);
if (unlikely(crng_init == 0)) {
if ((fast_pool->count >= 64) &&
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index aa16e6468f91..cc1e71334e53 100644
--- a/include/linux/prandom.h
+++ b/include/linux/prandom.h
@@ -16,12 +16,44 @@ void prandom_bytes(void *buf, size_t nbytes);
void prandom_seed(u32 seed);
void prandom_reseed_late(void);
+#if BITS_PER_LONG == 64
+/*
+ * The core SipHash round function. Each line can be executed in
+ * parallel given enough CPU resources.
+ */
+#define PRND_SIPROUND(v0, v1, v2, v3) ( \
+ v0 += v1, v1 = rol64(v1, 13), v2 += v3, v3 = rol64(v3, 16), \
+ v1 ^= v0, v0 = rol64(v0, 32), v3 ^= v2, \
+ v0 += v3, v3 = rol64(v3, 21), v2 += v1, v1 = rol64(v1, 17), \
+ v3 ^= v0, v1 ^= v2, v2 = rol64(v2, 32) \
+)
+
+#define PRND_K0 (0x736f6d6570736575 ^ 0x6c7967656e657261)
+#define PRND_K1 (0x646f72616e646f6d ^ 0x7465646279746573)
+
+#elif BITS_PER_LONG == 32
+/*
+ * On 32-bit machines, we use HSipHash, a reduced-width version of SipHash.
+ * This is weaker, but 32-bit machines are not used for high-traffic
+ * applications, so there is less output for an attacker to analyze.
+ */
+#define PRND_SIPROUND(v0, v1, v2, v3) ( \
+ v0 += v1, v1 = rol32(v1, 5), v2 += v3, v3 = rol32(v3, 8), \
+ v1 ^= v0, v0 = rol32(v0, 16), v3 ^= v2, \
+ v0 += v3, v3 = rol32(v3, 7), v2 += v1, v1 = rol32(v1, 13), \
+ v3 ^= v0, v1 ^= v2, v2 = rol32(v2, 16) \
+)
+#define PRND_K0 0x6c796765
+#define PRND_K1 0x74656462
+
+#else
+#error Unsupported BITS_PER_LONG
+#endif
+
struct rnd_state {
__u32 s1, s2, s3, s4;
};
-DECLARE_PER_CPU(struct rnd_state, net_rand_state);
-
u32 prandom_u32_state(struct rnd_state *state);
void prandom_bytes_state(struct rnd_state *state, void *buf, size_t nbytes);
void prandom_seed_full_state(struct rnd_state __percpu *pcpu_state);
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index dda05f4b7a1f..3e341af741b9 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1717,13 +1717,6 @@ void update_process_times(int user_tick)
scheduler_tick();
if (IS_ENABLED(CONFIG_POSIX_TIMERS))
run_posix_cpu_timers();
-
- /* The current CPU might make use of net randoms without receiving IRQs
-* to renew them often enough. Let's update the net_rand_state from a
-*
[PATCH v4 2/3] random32: add noise from network and scheduling activity
With the removal of the interrupt perturbations in previous random32
change (random32: make prandom_u32() output unpredictable), the PRNG
has become 100% deterministic again. While SipHash is expected to be
way more robust against brute force than the previous Tausworthe LFSR,
there's still the risk that whoever has even one temporary access to
the PRNG's internal state is able to predict all subsequent draws till
the next reseed (roughly every minute). This may happen through a side
channel attack or any data leak.
This patch restores the spirit of commit f227e3ec3b5c ("random32: update
the net random state on interrupt and activity") in that it will perturb
the internal PRNG's statee using externally collected noise, except that
it will not pick that noise from the random pool's bits nor upon
interrupt, but will rather combine a few elements along the Tx path
that are collectively hard to predict, such as dev, skb and txq
pointers, packet length and jiffies values. These ones are combined
using a single round of SipHash into a single long variable that is
mixed with the net_rand_state upon each invocation.
The operation was inlined because it produces very small and efficient
code, typically 3 xor, 2 add and 2 rol. The performance was measured
to be the same (even very slightly better) than before the switch to
SipHash; on a 6-core 12-thread Core i7-8700k equipped with a 40G NIC
(i40e), the connection rate dropped from 556k/s to 555k/s while the
SYN cookie rate grew from 5.38 Mpps to 5.45 Mpps.
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
Cc: George Spelvin
Cc: Amit Klein
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Tested-by: Sedat Dilek
Signed-off-by: Willy Tarreau
---
include/linux/prandom.h | 19 +++
kernel/time/timer.c | 2 ++
lib/random32.c | 5 +
net/core/dev.c | 4
4 files changed, 30 insertions(+)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index cc1e71334e53..bbf4b4ad61df 100644
--- a/include/linux/prandom.h
+++ b/include/linux/prandom.h
@@ -16,6 +16,12 @@ void prandom_bytes(void *buf, size_t nbytes);
void prandom_seed(u32 seed);
void prandom_reseed_late(void);
+DECLARE_PER_CPU(unsigned long, net_rand_noise);
+
+#define PRANDOM_ADD_NOISE(a, b, c, d) \
+ prandom_u32_add_noise((unsigned long)(a), (unsigned long)(b), \
+ (unsigned long)(c), (unsigned long)(d))
+
#if BITS_PER_LONG == 64
/*
* The core SipHash round function. Each line can be executed in
@@ -50,6 +56,18 @@ void prandom_reseed_late(void);
#error Unsupported BITS_PER_LONG
#endif
+static inline void prandom_u32_add_noise(unsigned long a, unsigned long b,
+unsigned long c, unsigned long d)
+{
+ /*
+* This is not used cryptographically; it's just
+* a convenient 4-word hash function. (3 xor, 2 add, 2 rol)
+*/
+ a ^= raw_cpu_read(net_rand_noise);
+ PRND_SIPROUND(a, b, c, d);
+ raw_cpu_write(net_rand_noise, d);
+}
+
struct rnd_state {
__u32 s1, s2, s3, s4;
};
@@ -99,6 +117,7 @@ static inline void prandom_seed_state(struct rnd_state
*state, u64 seed)
state->s2 = __seed(i, 8U);
state->s3 = __seed(i, 16U);
state->s4 = __seed(i, 128U);
+ PRANDOM_ADD_NOISE(state, i, 0, 0);
}
/* Pseudo random number generator from numerical recipes. */
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 3e341af741b9..de37e33a868d 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1706,6 +1706,8 @@ void update_process_times(int user_tick)
{
struct task_struct *p = current;
+ PRANDOM_ADD_NOISE(jiffies, user_tick, p, 0);
+
/* Note: this timer irq context must be accounted for as well. */
account_process_tick(p, user_tick);
run_local_timers();
diff --git a/lib/random32.c b/lib/random32.c
index be9f242a4207..7f047844e494 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -337,6 +337,8 @@ struct siprand_state {
};
static DEFINE_PER_CPU(struct siprand_state, net_rand_state) __latent_entropy;
+DEFINE_PER_CPU(unsigned long, net_rand_noise);
+EXPORT_PER_CPU_SYMBOL(net_rand_noise);
/*
* This is the core CPRNG function. As "pseudorandom", this is not used
@@ -360,9 +362,12 @@ static DEFINE_PER_CPU(struct siprand_state,
net_rand_state) __latent_entropy;
static inline u32 siprand_u32(struct siprand_state *s)
{
unsigned long v0 = s->v0, v1 = s->v1, v2 = s->v2, v3 = s->v3;
+ unsigned long n = raw_cpu_read(net_rand_noise);
+ v3 ^= n;
PRND_SIPROUND(v0, v1, v2, v3);
PRND_SIPROUND(v0, v1, v2, v3);
+ v0 ^= n;
s->v0 = v0; s->v1 = v1; s->v2 = v2; s->v3 = v3;
return v1 + v3;
}
diff --git a/net/core/dev.c
[PATCH v4 0/3] random32: make prandom_u32() less predictable
This is the cleanup of the latest series of prandom_u32 experimentations consisting in using SipHash instead of Tausworthe to produce the randoms used by the network stack. The changes to the files were kept minimal, and the controversial commit that used to take noise from the fast_pool (f227e3ec3b5c) was reverted. Instead, a dedicated "net_rand_noise" per_cpu variable is fed from various sources of activities (networking, scheduling) to perturb the SipHash state using fast, non-trivially predictable data, instead of keeping it fully deterministic. The goal is essentially to make any occasional memory leakage or brute-force attempt useless. The resulting code was verified to be very slightly faster on x86_64 than what is was with the controversial commit above, though this remains barely above measurement noise. It was also tested on i386 and arm, and build- tested only on arm64. The whole discussion around this is archived here: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/ The code is also available for you to pull at: git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandom.git tags/20201024-v4-5.10 --- v4: - access noise using raw_cpu_read() instead of this_cpu_read() - fixed build with CONFIG_RANDOM32_SELFTEST - added a selftest for the prandom32 code v3: This v3 is a rebase on top of 5.9-final, and switches __this_cpu_read() for this_cpu_read() to address a crash on i386+SMP+PREEMPT reported by LKP. Nothing else was changed. George Spelvin (1): random32: make prandom_u32() output unpredictable Willy Tarreau (2): random32: add noise from network and scheduling activity random32: add a selftest for the prandom32 code drivers/char/random.c | 1 - include/linux/prandom.h | 55 - kernel/time/timer.c | 9 +- lib/random32.c | 525 ++-- net/core/dev.c | 4 + 5 files changed, 404 insertions(+), 190 deletions(-) -- 2.28.0
Re: [git pull] vfs misc pile
The pull request you sent on Sat, 24 Oct 2020 19:46:56 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0eac1102e94807023e57d032bbba51830928b78e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] x86/seves fixes for v5.10-rc1
The pull request you sent on Sat, 24 Oct 2020 11:23:23 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > tags/x86_seves_fixes_for_v5.10_rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c51ae1247262d4b19451ded1107d9b1b69c57541 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] dma-mapping fixes for 5.10
The pull request you sent on Sat, 24 Oct 2020 16:19:35 +0200: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.10-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1b307ac87075c3207c345822ea276fe4f28481d7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] KVM fixes for Linux 5.10-rc1
The pull request you sent on Sat, 24 Oct 2020 05:01:57 -0400: > https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9bf8d8bcf3cebe44863188f1f2d822214e84f5b1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[GIT PULL] prandom32 changes for v5.10
Hi Linus, I've addressed the build issues when CONFIG_RANDOM32_SELFTEST is enabled, and also added a self-test for the new code (last patch of the series). As I previously questionned, I finally replaced this_cpu_read(noise) with raw_cpu_read(noise) as it it's pointless to deal with interrupts here since we're just collecting noise. Last point, I kept George as the author despite not being his real name, as I saw he already signed-off other commits. Please let me know if you have any question or comment. The following changes since commit f11901ed723d1351843771c3a84b03a253bbf8b2: Merge tag 'xfs-5.10-merge-7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux (2020-10-23 17:15:06 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandom.git tags/20201024-v4-5.10 for you to fetch changes up to c6e169bc146a76d5ccbf4d3825f705414352bd03: random32: add a selftest for the prandom32 code (2020-10-24 20:21:57 +0200) random32: make prandom_u32() less predictable This is the cleanup of the latest series of prandom_u32 experimentations consisting in using SipHash instead of Tausworthe to produce the randoms used by the network stack. The changes to the files were kept minimal, and the controversial commit that used to take noise from the fast_pool (f227e3ec3b5c) was reverted. Instead, a dedicated "net_rand_noise" per_cpu variable is fed from various sources of activities (networking, scheduling) to perturb the SipHash state using fast, non-trivially predictable data, instead of keeping it fully deterministic. The goal is essentially to make any occasional memory leakage or brute-force attempt useless. The resulting code was verified to be very slightly faster on x86_64 than what is was with the controversial commit above, though this remains barely above measurement noise. It was also tested on i386 and arm, and build- tested only on arm64. The whole discussion around this is archived here: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/ --- v4: - access noise using raw_cpu_read() instead of this_cpu_read() - fixed build with CONFIG_RANDOM32_SELFTEST - added a selftest for the prandom32 code v3: This v3 is a rebase on top of 5.9-final, and switches __this_cpu_read() for this_cpu_read() to address a crash on i386+SMP+PREEMPT reported by LKP. Nothing else was changed. George Spelvin (1): random32: make prandom_u32() output unpredictable Willy Tarreau (2): random32: add noise from network and scheduling activity random32: add a selftest for the prandom32 code drivers/char/random.c | 1 - include/linux/prandom.h | 55 - kernel/time/timer.c | 9 +- lib/random32.c | 525 +++- net/core/dev.c | 4 + 5 files changed, 404 insertions(+), 190 deletions(-)
IMF PAYMENT NOTIFICATION
International Monetary Fund (IMF) Office of the Special Representative to the UN. Head quarters, Attn: Beneficiary, This is to intimate you of a very important information which will be of great help to redeem you from all the difficulties you have been experiencing in getting your long overdue payment due to excessive demand for money from you by both corrupt Bank officials and Courier Companies after which your fund remains unpaid to you. I am Mr. Alfredo Vezina a highly placed official of the International Monetary Fund (IMF) It may interest you to know that reports have reached our office by so many correspondence on the uneasy way which people like you are being treated by Various Banks and Courier Companies across Europe to Africa and Asia and we have decided to put a stop to that and that is why i am appointed to handle your transaction. Note; All Governmental and Non-Governmental parasites, NGOs, Finance Companies, Banks, Security Companies and Courier companies which have been in contact with you of late have been instructed to back off from your transaction and you have been advised NOT to respond to them anymore since my office is now directly in charge of your payment. You are hereby advised NOT to remit further payment to any institutions with respect to your transaction as your fund will be released to you directly from our source. I hope this is clear. Any action contrary to these instructions is at your own risk. I'm using this medium to promise you that immediately you provide the information below for reconfirmation of your personal information i shall direct you to the paying bank where your fund (US$10,500,000.00) is currently deposited and separately operating on your name but your wrong dealings did not make you know the right offices to deal with. Most important note that you are not require to pay any upfront fee as regards to receiving your Fund payment as we the Committee of the I.M.F and the African Government has reached to a conclusion that 0.6% will be deducted from your total valued Fund of US$10,500,000.00 to be used as fund transfer expenses by the paying bank which will not require you to pay any fee in receiving your Fund. In view of the above you are advised to provide the information below to facilitate the immediate release of your fund. 1) Your Full Name: 2) Phone, Fax and Mobile: 3) Company\'S Name, Position and Address: 4) Profession, Age and Marital Status Kindly send the above required information to us via (alfredovez...@gmail.com) and upon the receipt of the above mentioned information we shall proceed in filing a claim with the bank and get back to you with further details on how your fund will be released. Awaiting your earliest response. Best Regards, Mr. Alfredo Vezina Senior Resident Representative in USA. International Monetary Fund (IMF).
Re: [PATCH 1/2] i2c: imx: use devm_request_threaded_irq to simplify code
On Sat, Oct 24, 2020 at 07:39:47AM +, Peng Fan wrote:
> > Subject: Re: [PATCH 1/2] i2c: imx: use devm_request_threaded_irq to simplify
> > code
> >
> > On Fri, 23 Oct 2020 at 10:27, wrote:
> > >
> > > From: Peng Fan
> > >
> > > Use devm_request_threaded_irq to simplify code
> > >
> > > Signed-off-by: Peng Fan
> > > ---
> > > drivers/i2c/busses/i2c-imx.c | 10 +++---
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-imx.c
> > > b/drivers/i2c/busses/i2c-imx.c index e6f8d6e45a15..ba9d639223ec 100644
> > > --- a/drivers/i2c/busses/i2c-imx.c
> > > +++ b/drivers/i2c/busses/i2c-imx.c
> > > @@ -1216,8 +1216,8 @@ static int i2c_imx_probe(struct platform_device
> > *pdev)
> > > goto rpm_disable;
> > >
> > > /* Request IRQ */
> > > - ret = request_threaded_irq(irq, i2c_imx_isr, NULL, IRQF_SHARED,
> > > - pdev->name, i2c_imx);
> > > + ret = devm_request_threaded_irq(>dev, irq, i2c_imx_isr,
> > NULL, IRQF_SHARED,
> > > + pdev->name, i2c_imx);
> >
> > Really? You silently revert commit e50e4f0b85be ("i2c: imx: Fix external
> > abort
> > on interrupt in exit paths"). This is not a simplification but serious
> > change. NAK.
> > At least without proper reasoning of why this is suddenly safe.
>
> Oh, I need look at git history before. But
> Is it because i2c interrupt enabled too early? I'll try your case on i.MX8M
> platform.
Shortly, it is because shared interrupts do not go well or at all with
devm-managed interrupt handlers. Probably they could be made working
with additional code, e.g. devm_free_irq() call or some additional
checks in interrupt handlers. But in that case there won't be much of
simplification.
Best regards,
Krzysztof
