Re: [RFC PATCH v0 00/19] x86/insn: Add an insn_decode() API
On Tue, 24 Nov 2020 18:46:47 +0100 Borislav Petkov wrote: > On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote: > > In any case, at least the case where I give it > > > > 0x48 0xcf 0x48 0x83 > > > > and say that buf size is 4, should return an error because the second > > insn is incomplete. So I need to go look at that now. > > Ok, got it: > > ./arch/x86/tools/insn_sanity: Success: decoded and checked 1 random > instructions with 0 errors (seed:0x826fdf9c) > insn buffer: > 0x48 0xcf 0x48 0x83 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 > supplied buf size: 15, ret 0 > supplied buf size: 2, ret 0 > supplied buf size: 3, ret 0 > supplied buf size: 4, ret 0 > supplied buf size: 1, ret -22 > > the current decoder simply decodes the *first* insn in the buffer it > encounters and that's it. Yes, currently the buf_size is only for checking the maximum length of the buffer, because we expect the user doesn't know the actual length of the instruction before calling insn_get_length(). But yes, for the insn_sanity.c, the return length should be compared. Thank you, > > When you give it a buffer of size smaller than the first instruction: > > supplied buf size: 1, ret -22 > > while the first insn is 2 bytes long: > > 0x48 0xcf (IRETQ) > > then it signals an error. > > Andy, does that work for your use cases? > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette -- Masami Hiramatsu
Re: [PATCH v1 1/2] PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
On Tue, Nov 24, 2020 at 08:44:00PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to > be reference counted for wakeup enabling, because they may be enabled > to signal wakeup on behalf of their subordinate devices and that > may happen for multiple times in a row, whereas for the other devices > it only makes sense to enable wakeup signaling once. > > However, this becomes problematic if the bridge itself is suspended, > because it is treated as a "regular" device in that case and the > reference counting doesn't work. > > For instance, suppose that there are two devices below a bridge and > they both can signal wakeup. Every time one of them is suspended, > wakeup signaling is enabled for the bridge, so when they both have > been suspended, the bridge's wakeup reference counter value is 2. > > Say that the bridge is suspended subsequently and acpi_pci_wakeup() > is called for it. Because the bridge can signal wakeup, that > function will invoke acpi_pm_set_device_wakeup() to configure it > and __acpi_pm_set_device_wakeup() will be called with the last > argument equal to 1. This causes __acpi_device_wakeup_enable() > invoked by it to omit the reference counting, because the reference > counter of the target device (the bridge) is 2 at that time. > > Now say that the bridge resumes and one of the device below it > resumes too, so the bridge's reference counter becomes 0 and > wakeup signaling is disabled for it, but there is still the other > suspended device which may need the bridge to signal wakeup on its > behalf and that is not going to work. > > To address this scenario, use wakeup enable reference counting for > all devices, not just for bridges, so drop the last argument from > __acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(), > which causes acpi_pm_set_device_wakeup() and > acpi_pm_set_bridge_wakeup() to become identical, so drop the latter > and use the former instead of it everywhere. > > Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg
[GIT PULL for v5.10-rc6] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.10-2 For: - a rand Kconfig fixup for mtk-vcodec; - a fix at h264 handling at cedrus codec driver; - some warning fixes when config PM is not enabled at marvell-ccic; - two fixes at venus codec driver: one related to codec profile and the other one related to a bad error path which causes an OOPS on module re-bind. Regards, Mauro The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891: Linux 5.10-rc2 (2020-11-01 14:43:51 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.10-2 for you to fetch changes up to 9215f6bb4705ffe205885411394732bfc439dee0: media: venus: pm_helpers: Fix kernel module reload (2020-11-16 19:06:10 +0100) media fixes for v5.10-rc6 Alexandre Courbot (2): media: mtk-vcodec: move firmware implementations into their own files media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled Jernej Skrabec (1): media: cedrus: h264: Fix check for presence of scaling matrix Randy Dunlap (1): media: media/platform/marvell-ccic: fix warnings when CONFIG_PM is not enabled Stanimir Varbanov (2): media: venus: venc: Fix setting of profile and level media: venus: pm_helpers: Fix kernel module reload drivers/media/platform/Kconfig | 28 +++- drivers/media/platform/marvell-ccic/mmp-driver.c | 2 + drivers/media/platform/mtk-vcodec/Makefile | 10 +- .../media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 2 +- .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 2 +- drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c | 174 + drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h | 7 +- .../media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h | 52 ++ .../media/platform/mtk-vcodec/mtk_vcodec_fw_scp.c | 73 + .../media/platform/mtk-vcodec/mtk_vcodec_fw_vpu.c | 110 + drivers/media/platform/qcom/venus/core.h | 15 +- drivers/media/platform/qcom/venus/pm_helpers.c | 4 +- drivers/media/platform/qcom/venus/venc.c | 31 +++- drivers/media/platform/qcom/venus/venc_ctrls.c | 14 +- drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 2 +- 15 files changed, 338 insertions(+), 188 deletions(-) create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_scp.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_vpu.c
Re: [PATCH] mmc: sdhci: Use more concise device_property_read_u64
On 25/11/20 5:36 am, Jeremy Linton wrote: > Since we only need a single u64 the _array form is > unnecessarily. Use device_property_read_u64 instead. > > Signed-off-by: Jeremy Linton Thank you :-) Acked-by: Adrian Hunter > --- > drivers/mmc/host/sdhci.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index feba64fbde16..ad4ae88a7f74 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -3992,10 +3992,10 @@ void __sdhci_read_caps(struct sdhci_host *host, const > u16 *ver, > if (host->v4_mode) > sdhci_do_enable_v4_mode(host); > > - device_property_read_u64_array(mmc_dev(host->mmc), > -"sdhci-caps-mask", &dt_caps_mask, 1); > - device_property_read_u64_array(mmc_dev(host->mmc), > -"sdhci-caps", &dt_caps, 1); > + device_property_read_u64(mmc_dev(host->mmc), > + "sdhci-caps-mask", &dt_caps_mask); > + device_property_read_u64(mmc_dev(host->mmc), > + "sdhci-caps", &dt_caps); > > v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION); > host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT; >
Re: [PATCH v1 2/2] PM: ACPI: Refresh wakeup device power configuration every time
On Tue, Nov 24, 2020 at 08:46:38PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > When wakeup signaling is enabled for a bridge for the second (or every > next) time in a row, its existing device wakeup power configuration > may not match the new conditions. For example, some devices below > it may have been put into low-power states and that changes the > device wakeup power conditions or similar. This causes functional > problems to appear on some systems (for example, because of it the > Thunderbolt port on Dell Precision 5550 cannot detect devices plugged > in after it has been suspended). > > For this reason, modify __acpi_device_wakeup_enable() to refresh the > device wakeup power configuration of the target device on every > invocation, not just when it is called for that device first time > in a row. > > Signed-off-by: Rafael J. Wysocki > Reported-by: Kai-Heng Feng > Tested-by: Kai-Heng Feng Reviewed-by: Mika Westerberg
Re: [PATCH 3/3] media: hfi_venus: Request interrupt for sync cmds
On Fri, Nov 20, 2020 at 9:12 AM Stanimir Varbanov
wrote:
>
> From: Vikash Garodia
>
> For synchronous commands, update the message queue variable.
> This would inform video firmware to raise interrupt on host
> CPU whenever there is a response for such commands.
>
> Signed-off-by: Vikash Garodia
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/hfi_venus.c | 74 ++-
> 1 file changed, 41 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c
> b/drivers/media/platform/qcom/venus/hfi_venus.c
> index 4be4a75ddcb6..b8fdb464ba9c 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -372,7 +372,7 @@ static void venus_soft_int(struct venus_hfi_device *hdev)
> }
>
> static int venus_iface_cmdq_write_nolock(struct venus_hfi_device *hdev,
> -void *pkt)
> +void *pkt, bool sync)
> {
> struct device *dev = hdev->core->dev;
> struct hfi_pkt_hdr *cmd_packet;
> @@ -397,15 +397,23 @@ static int venus_iface_cmdq_write_nolock(struct
> venus_hfi_device *hdev,
> if (rx_req)
> venus_soft_int(hdev);
>
> + /* Inform video firmware to raise interrupt for synchronous commands
> */
> + queue = &hdev->queues[IFACEQ_MSG_IDX];
> + if (sync) {
> + queue->qhdr->rx_req = 1;
> + /* ensure rx_req is updated in memory */
> + wmb();
> + }
Wouldn't it be safer to do this before calling venus_soft_int()? I
don't know what the firmware is supposed to do with rx_req but
intuitively it looks like it should be set before we signal it.
> +
> return 0;
> }
>
> -static int venus_iface_cmdq_write(struct venus_hfi_device *hdev, void *pkt)
> +static int venus_iface_cmdq_write(struct venus_hfi_device *hdev, void *pkt,
> bool sync)
> {
> int ret;
>
> mutex_lock(&hdev->lock);
> - ret = venus_iface_cmdq_write_nolock(hdev, pkt);
> + ret = venus_iface_cmdq_write_nolock(hdev, pkt, sync);
> mutex_unlock(&hdev->lock);
>
> return ret;
> @@ -428,7 +436,7 @@ static int venus_hfi_core_set_resource(struct venus_core
> *core, u32 id,
> if (ret)
> return ret;
>
> - ret = venus_iface_cmdq_write(hdev, pkt);
> + ret = venus_iface_cmdq_write(hdev, pkt, false);
> if (ret)
> return ret;
>
> @@ -778,7 +786,7 @@ static int venus_sys_set_debug(struct venus_hfi_device
> *hdev, u32 debug)
>
> pkt_sys_debug_config(pkt, HFI_DEBUG_MODE_QUEUE, debug);
>
> - ret = venus_iface_cmdq_write(hdev, pkt);
> + ret = venus_iface_cmdq_write(hdev, pkt, false);
> if (ret)
> return ret;
>
> @@ -795,7 +803,7 @@ static int venus_sys_set_coverage(struct venus_hfi_device
> *hdev, u32 mode)
>
> pkt_sys_coverage_config(pkt, mode);
>
> - ret = venus_iface_cmdq_write(hdev, pkt);
> + ret = venus_iface_cmdq_write(hdev, pkt, false);
> if (ret)
> return ret;
>
> @@ -816,7 +824,7 @@ static int venus_sys_set_idle_message(struct
> venus_hfi_device *hdev,
>
> pkt_sys_idle_indicator(pkt, enable);
>
> - ret = venus_iface_cmdq_write(hdev, pkt);
> + ret = venus_iface_cmdq_write(hdev, pkt, false);
> if (ret)
> return ret;
>
> @@ -834,7 +842,7 @@ static int venus_sys_set_power_control(struct
> venus_hfi_device *hdev,
>
> pkt_sys_power_control(pkt, enable);
>
> - ret = venus_iface_cmdq_write(hdev, pkt);
> + ret = venus_iface_cmdq_write(hdev, pkt, false);
> if (ret)
> return ret;
>
> @@ -885,14 +893,14 @@ static int venus_sys_set_default_properties(struct
> venus_hfi_device *hdev)
> return ret;
> }
>
> -static int venus_session_cmd(struct venus_inst *inst, u32 pkt_type)
> +static int venus_session_cmd(struct venus_inst *inst, u32 pkt_type, bool
> sync)
> {
> struct venus_hfi_device *hdev = to_hfi_priv(inst->core);
> struct hfi_session_pkt pkt;
>
> pkt_session_cmd(&pkt, pkt_type, inst);
>
> - return venus_iface_cmdq_write(hdev, &pkt);
> + return venus_iface_cmdq_write(hdev, &pkt, sync);
> }
>
> static void venus_flush_debug_queue(struct venus_hfi_device *hdev)
> @@ -922,7 +930,7 @@ static int venus_prepare_power_collapse(struct
> venus_hfi_device *hdev,
>
> pkt_sys_pc_prep(&pkt);
>
> - ret = venus_iface_cmdq_write(hdev, &pkt);
> + ret = venus_iface_cmdq_write(hdev, &pkt, false);
> if (ret)
> return ret;
>
> @@ -1064,13 +1072,13 @@ static int venus_core_init(struct venus_core *core)
>
> venus_set_state(hdev, VENUS_STATE_INIT);
>
> - ret = venus_iface_cmdq_write(hdev, &pkt);
> + ret = venus_iface_cmdq_write(hdev, &pkt, false);
> if (ret)
> return ret;
>
>
Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events
Namhyung Kim writes:
> Hello,
>
> On Mon, Nov 23, 2020 at 8:00 PM Michael Ellerman wrote:
>>
>> Namhyung Kim writes:
>> > Hi Peter and Kan,
>> >
>> > (Adding PPC folks)
>> >
>> > On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan
>> >> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
>> >> > > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
>> >> > >
>> >> > >> - When the large PEBS was introduced (9c964efa4330), the
>> >> > >> sched_task() should
>> >> > >> be invoked to flush the PEBS buffer in each context switch. However,
>> >> > >> The
>> >> > >> perf_sched_events in account_event() is not updated accordingly. The
>> >> > >> perf_event_task_sched_* never be invoked for a pure per-CPU context.
>> >> > >> Only
>> >> > >> per-task event works.
>> >> > >> At that time, the perf_pmu_sched_task() is outside of
>> >> > >> perf_event_context_sched_in/out. It means that perf has to double
>> >> > >> perf_pmu_disable() for per-task event.
>> >> > >
>> >> > >> - The patch 1 tries to fix broken per-CPU events. The CPU context
>> >> > >> cannot be
>> >> > >> retrieved from the task->perf_event_ctxp. So it has to be tracked in
>> >> > >> the
>> >> > >> sched_cb_list. Yes, the code is very similar to the original codes,
>> >> > >> but it
>> >> > >> is actually the new code for per-CPU events. The optimization for
>> >> > >> per-task
>> >> > >> events is still kept.
>> >> > >>For the case, which has both a CPU context and a task context,
>> >> > >> yes, the
>> >> > >> __perf_pmu_sched_task() in this patch is not invoked. Because the
>> >> > >> sched_task() only need to be invoked once in a context switch. The
>> >> > >> sched_task() will be eventually invoked in the task context.
>> >> > >
>> >> > > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
>> >> > > only set that for large pebs. Are you sure the other users (Intel LBR
>> >> > > and PowerPC BHRB) don't need it?
>> >> >
>> >> > I didn't set it for LBR, because the perf_sched_events is always enabled
>> >> > for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
>> >> > for LBR.
>> >> >
>> >> > if (has_branch_stack(event))
>> >> > inc = true;
>> >> >
>> >> > >
>> >> > > If they indeed do not require the pmu::sched_task() callback for CPU
>> >> > > events, then I still think the whole perf_sched_cb_{inc,dec}()
>> >> > > interface
>> >> >
>> >> > No, LBR requires the pmu::sched_task() callback for CPU events.
>> >> >
>> >> > Now, The LBR registers have to be reset in sched in even for CPU events.
>> >> >
>> >> > To fix the shorter LBR callstack issue for CPU events, we also need to
>> >> > save/restore LBRs in pmu::sched_task().
>> >> > https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.li...@linux.intel.com/
>> >> >
>> >> > > is confusing at best.
>> >> > >
>> >> > > Can't we do something like this instead?
>> >> > >
>> >> > I think the below patch may have two issues.
>> >> > - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well)
>> >> > now.
>> >> > - We may disable the large PEBS later if not all PEBS events support
>> >> > large PEBS. The PMU need a way to notify the generic code to decrease
>> >> > the nr_sched_task.
>> >>
>> >> Any updates on this? I've reviewed and tested Kan's patches
>> >> and they all look good.
>> >>
>> >> Maybe we can talk to PPC folks to confirm the BHRB case?
>> >
>> > Can we move this forward? I saw patch 3/3 also adds PERF_ATTACH_SCHED_CB
>> > for PowerPC too. But it'd be nice if ppc folks can confirm the change.
>>
>> Sorry I've read the whole thread, but I'm still not entirely sure I
>> understand the question.
>
> Thanks for your time and sorry about not being clear enough.
>
> We found per-cpu events are not calling pmu::sched_task()
> on context switches. So PERF_ATTACH_SCHED_CB was
> added to indicate the core logic that it needs to invoke the
> callback.
OK. TBH I've never thought of using branch stack with a per-cpu event,
but I guess you can do it.
I think the same logic applies as LBR, we need to read the BHRB entries
in the context of the task that they were recorded for.
> The patch 3/3 added the flag to PPC (for BHRB) with other
> changes (I think it should be split like in the patch 2/3) and
> want to get ACKs from the PPC folks.
If you post a new version with Maddy's comments addressed then he or I
can ack it.
cheers
Re: [PATCH RESEND 1/2] MIPS: cacheinfo: Add missing VCache
On 11/03/2020 01:40 PM, Jiaxun Yang wrote:
在 2020/8/22 0:55, Thomas Bogendoerfer 写道:
On Thu, Aug 20, 2020 at 08:42:49AM +0800, Jiaxun Yang wrote:
Victim Cache is defined by Loongson as per-core unified
private Cache.
Add this into cacheinfo and make cache levels selfincrement
instead of hardcode levels.
Signed-off-by: Jiaxun Yang
---
arch/mips/kernel/cacheinfo.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/arch/mips/kernel/cacheinfo.c
b/arch/mips/kernel/cacheinfo.c
index 47312c529410..83548331ee94 100644
--- a/arch/mips/kernel/cacheinfo.c
+++ b/arch/mips/kernel/cacheinfo.c
@@ -35,6 +35,11 @@ static int __init_cache_level(unsigned int cpu)
leaves += (c->icache.waysize) ? 2 : 1;
+if (c->vcache.waysize) {
+levels++;
+leaves++;
+}
+
if (c->scache.waysize) {
levels++;
leaves++;
@@ -74,25 +79,38 @@ static int __populate_cache_leaves(unsigned int
cpu)
struct cpuinfo_mips *c = ¤t_cpu_data;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf = this_cpu_ci->info_list;
+int level = 1;
if (c->icache.waysize) {
-/* L1 caches are per core */
+/* D/I caches are per core */
fill_cpumask_siblings(cpu, &this_leaf->shared_cpu_map);
-populate_cache(dcache, this_leaf, 1, CACHE_TYPE_DATA);
+populate_cache(dcache, this_leaf, level, CACHE_TYPE_DATA);
fill_cpumask_siblings(cpu, &this_leaf->shared_cpu_map);
-populate_cache(icache, this_leaf, 1, CACHE_TYPE_INST);
+populate_cache(icache, this_leaf, level, CACHE_TYPE_INST);
+level++;
} else {
-populate_cache(dcache, this_leaf, 1, CACHE_TYPE_UNIFIED);
+populate_cache(dcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+level++;
+}
+
+if (c->vcache.waysize) {
why can't we insert vcache as level 4 and leave the rest of the file
alone ?
Hi Thomas,
Oops I forgot this patch.
Because VCache is physicaly placed between Scache and I/D Cache as per
core chahe, it will confuse userspace program otherwise.
Also I do think the level should be continues.
With this patch, we can see the vcache info as L2 cache
and scache info as L3 cache on the Loongson 3A3000
and 3A4000 platform.
Tested-by: Tiezhu Yang
Thanks
- Jiaxun
Thomas.
Re: [PATCH] riscv: defconfig: k210: Disable CONFIG_VT
Hi Damien,
On Wed, Nov 25, 2020 at 7:14 AM Damien Le Moal wrote:
> On 2020/11/25 3:57, Geert Uytterhoeven wrote:
> > There is no need to enable Virtual Terminal support in the Canaan
> > Kendryte K210 defconfigs, as no terminal devices are supported and
> > enabled. Hence disable CONFIG_VT, and remove the no longer needed
> > override for CONFIG_VGA_CONSOLE.
> >
> > This reduces kernel size by ca. 65 KiB.
>
> Indeed, nice saving. Just tested, and all is good.
>
> Can I squash this patch into the 2 defconfig update patches of the series,
> adding your signed-off-by ? Or would you prefer that I keep it as a separate
> patch ?
Feel free to squash it into your queued updates.
No need to add my SoB, as the full updates don't pass through me.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] efi: EFI_EARLYCON should depend on EFI
On Tue, 2020-11-24 at 20:16 +0100, Geert Uytterhoeven wrote:
> CONFIG_EFI_EARLYCON defaults to yes, and thus is enabled on systems that
> do not support EFI, or do not have EFI support enabled, but do satisfy
> the symbol's other dependencies.
>
> While drivers/firmware/efi/ won't be entered during the build phase if
> CONFIG_EFI=n, and drivers/firmware/efi/earlycon.c itself thus won't be
> built, enabling EFI_EARLYCON does force-enable CONFIG_FONT_SUPPORT and
> CONFIG_ARCH_USE_MEMREMAP_PROT, and CONFIG_FONT_8x16, which is
> undesirable.
>
> Fix this by making CONFIG_EFI_EARLYCON depend on CONFIG_EFI.
>
> This reduces kernel size on headless systems by more than 4 KiB.
>
> Fixes: 69c1f396f25b805a ("efi/x86: Convert x86 EFI earlyprintk into generic
> earlycon implementation")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/firmware/efi/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index b452cfa2100b401c..1dd1f7784f0888ff 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -270,7 +270,7 @@ config EFI_DEV_PATH_PARSER
>
>
> config EFI_EARLYCON
> def_bool y
> - depends on SERIAL_EARLYCON && !ARM && !IA64
> + depends on EFI && SERIAL_EARLYCON && !ARM && !IA64
> select FONT_SUPPORT
> select ARCH_USE_MEMREMAP_PROT
>
>
Looks good to me.
Reviewed-by: Damien Le Moal
--
Damien Le Moal
Western Digital
Re: [PATCH] efi: EFI_EARLYCON should depend on EFI
On Wed, 25 Nov 2020 at 09:21, Damien Le Moal wrote:
>
> On Tue, 2020-11-24 at 20:16 +0100, Geert Uytterhoeven wrote:
> > CONFIG_EFI_EARLYCON defaults to yes, and thus is enabled on systems that
> > do not support EFI, or do not have EFI support enabled, but do satisfy
> > the symbol's other dependencies.
> >
> > While drivers/firmware/efi/ won't be entered during the build phase if
> > CONFIG_EFI=n, and drivers/firmware/efi/earlycon.c itself thus won't be
> > built, enabling EFI_EARLYCON does force-enable CONFIG_FONT_SUPPORT and
> > CONFIG_ARCH_USE_MEMREMAP_PROT, and CONFIG_FONT_8x16, which is
> > undesirable.
> >
> > Fix this by making CONFIG_EFI_EARLYCON depend on CONFIG_EFI.
> >
> > This reduces kernel size on headless systems by more than 4 KiB.
> >
> > Fixes: 69c1f396f25b805a ("efi/x86: Convert x86 EFI earlyprintk into generic
> > earlycon implementation")
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > drivers/firmware/efi/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> > index b452cfa2100b401c..1dd1f7784f0888ff 100644
> > --- a/drivers/firmware/efi/Kconfig
> > +++ b/drivers/firmware/efi/Kconfig
> > @@ -270,7 +270,7 @@ config EFI_DEV_PATH_PARSER
> >
> >
> > config EFI_EARLYCON
> > def_bool y
> > - depends on SERIAL_EARLYCON && !ARM && !IA64
> > + depends on EFI && SERIAL_EARLYCON && !ARM && !IA64
> > select FONT_SUPPORT
> > select ARCH_USE_MEMREMAP_PROT
> >
> >
>
> Looks good to me.
> Reviewed-by: Damien Le Moal
>
Thanks all
I'll queue this as a fix.
Re: Linux 5.10-rc4; graphics alignment
Hi
Am 24.11.20 um 17:27 schrieb David Laight:
From: David Laight
Sent: 20 November 2020 15:39
From: Thomas Zimmermann
Sent: 20 November 2020 13:42
...
I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
Some candidates are
8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
plane's color format")
Ok, that one fixes the screen colours (etc).
So 8e3784dfef8a was good and then HEAD^ was bad.
I might try to bisect the breakage.
The stack splat is entirely different.
I'll try to bisect that on Linus's tree.
The good news is I'm not getting the stack splat on rc5.
I'm not sure I can be bothered to find out when :-)
Applying 8e3784dfef8a to rc5 by hand also fixes the display colours.
I've added this commit to drm-misc-fixes and it should show up in the
upstream kernel soonish.
Best regards
Thomas
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Yangbo, Hi Shawn,
Am 2020-11-25 03:59, schrieb Y.b. Lu:
-Original Message-
From: Vladimir Oltean
Sent: Tuesday, November 24, 2020 7:28 PM
To: Y.b. Lu
Cc: Michael Walle ; Shawn Guo ;
Leo Li ; Rob Herring ;
linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
Adrian
Hunter ; Ulf Hansson
;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ashish Kumar
Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
controllers use fixed indices
On Tue, Nov 24, 2020 at 11:15:19AM +, Y.b. Lu wrote:
> > > Not matter it's SD card or eMMC card, if it's on esdhc0, use
/dev/mmcblk0.
> > > Not matter it's SD card or eMMC card, if it's on esdhc1, use
/dev/mmcblk1.
> >
> > With the note here that you can't actually connect an SD card to eSDHC1,
> > due to the lack of pins for CD/WP.
>
> CD/WP is not essential to support SD card. Both SD/eMMC are supported on
both eSDHC controllers.
Let's keep that discussion separate. While in theory you might be
right,
I think the real-life complications associated with connecting an eMMC
to eSDHC0 and an SD card to eSDHC1 will make everyone avoid that. So
in
practice they are still single-purpose.
You may refer to Layerscape QDS boards. 5 types SDHC adapters with
PCIe connecter supporting SD or eMMC could be used on each esdhc
interface.
Just for completeness, on the LS1028A there is definetly one for eMMC
and one for SD card. One supports voltage switching and one has a 8bit
data bus. But as Vladimir already said, this doesn't matter for this
discussion.
Another reason using default mmc0 for esdhc0 and mmc1 for esdhc1, is
because that's also the order before esdhc driver introducing
asynchronous probe.
No if there was
&esdhc { status = "disabled" };
this would change the block device from /dev/mmcblk0 to /dev/mmcblk1
for the remaining &esdhc1.
We are going cirlces here. I guess Shawn (as the soc maintainer) has to
step in and decide if a common soc include should contain aliases for
nodes which are disabled. That is what it boils down to.
All other arguments against having aliases in the common include can be
found in this thread.
Distros, bootloaders, and users' cases using fixed index before could
avoid issues, and been used as they were.
Nobody argue against having these alias. We are arguing against having
them in the common soc include.
-michael
Re: [PATCH] riscv: defconfig: k210: Disable CONFIG_VT
On Wed, 2020-11-25 at 09:20 +0100, Geert Uytterhoeven wrote:
> Hi Damien,
>
> On Wed, Nov 25, 2020 at 7:14 AM Damien Le Moal wrote:
> > On 2020/11/25 3:57, Geert Uytterhoeven wrote:
> > > There is no need to enable Virtual Terminal support in the Canaan
> > > Kendryte K210 defconfigs, as no terminal devices are supported and
> > > enabled. Hence disable CONFIG_VT, and remove the no longer needed
> > > override for CONFIG_VGA_CONSOLE.
> > >
> > > This reduces kernel size by ca. 65 KiB.
> >
> > Indeed, nice saving. Just tested, and all is good.
> >
> > Can I squash this patch into the 2 defconfig update patches of the series,
> > adding your signed-off-by ? Or would you prefer that I keep it as a
> > separate patch ?
>
> Feel free to squash it into your queued updates.
> No need to add my SoB, as the full updates don't pass through me.
Done. Thanks !
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Damien Le Moal
Western Digital
[PATCH] nfsd: Fix error return code in nfsd_file_cache_init()
Fix to return PTR_ERR() error code from the error handling case instead of
0 in function nfsd_file_cache_init(), as done elsewhere in this function.
Fixes: 65294c1f2c5e7("nfsd: add a new struct file caching facility to nfsd")
Signed-off-by: Huang Guobin
---
fs/nfsd/filecache.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
index c8b9d2667ee6..a8a5b555f08b 100644
--- a/fs/nfsd/filecache.c
+++ b/fs/nfsd/filecache.c
@@ -686,6 +686,7 @@ nfsd_file_cache_init(void)
pr_err("nfsd: unable to create fsnotify group: %ld\n",
PTR_ERR(nfsd_file_fsnotify_group));
nfsd_file_fsnotify_group = NULL;
+ ret = PTR_ERR(nfsd_file_fsnotify_group);
goto out_notifier;
}
--
2.22.0
Re: [RFC PATCH v5] sched/fair: select idle cpu from idle cpumask for task wakeup
On Wed, 25 Nov 2020 at 03:03, Li, Aubrey wrote: > > On 2020/11/25 1:01, Vincent Guittot wrote: > > Hi Aubrey, > > > > Le mardi 24 nov. 2020 à 15:01:38 (+0800), Li, Aubrey a écrit : > >> Hi Vincent, > >> > >> On 2020/11/23 17:27, Vincent Guittot wrote: > >>> Hi Aubrey, > >>> > >>> On Thu, 19 Nov 2020 at 13:15, Aubrey Li wrote: > > Add idle cpumask to track idle cpus in sched domain. When a CPU > enters idle, if the idle driver indicates to stop tick, this CPU > is set in the idle cpumask to be a wakeup target. And if the CPU > is not in idle, the CPU is cleared in idle cpumask during scheduler > tick to ratelimit idle cpumask update. > > When a task wakes up to select an idle cpu, scanning idle cpumask > has low cost than scanning all the cpus in last level cache domain, > especially when the system is heavily loaded. > > Benchmarks were tested on a x86 4 socket system with 24 cores per > socket and 2 hyperthreads per core, total 192 CPUs. Hackbench and > schbench have no notable change, uperf has: > > uperf throughput: netperf workload, tcp_nodelay, r/w size = 90 > > threads baseline-avg%stdpatch-avg %std > 961 0.831.233.27 > 144 1 1.031.672.67 > 192 1 0.691.813.59 > 240 1 2.841.512.67 > > v4->v5: > - add update_idle_cpumask for s2idle case > - keep the same ordering of tick_nohz_idle_stop_tick() and update_ > idle_cpumask() everywhere > > v3->v4: > - change setting idle cpumask from every idle entry to tickless idle > if cpu driver is available. > >>> > >>> Could you remind me why you did this change ? Clearing the cpumask is > >>> done during the tick to rate limit the number of updates of the > >>> cpumask but It's not clear for me why you have associated the set with > >>> the tick stop condition too. > >> > >> I found the current implementation has better performance at a more > >> suitable load range. > >> > >> The two kinds of implementions(v4 and v5) have the same rate(scheduler > >> tick) to shrink idle cpumask when the system is busy, but > > > > I'm ok with the part above > > > >> > >> - Setting the idle mask everytime the cpu enters idle requires a much > >> heavier load level to preserve the idle cpumask(not call into idle), > >> otherwise the bits cleared in scheduler tick will be restored when the > >> cpu enters idle. That is, idle cpumask is almost equal to the domain > >> cpumask during task wakeup if the system load is not heavy enough. > > > > But setting the idle cpumask is useful because it helps to select an idle > > cpu at wake up instead of waiting ifor ILB to fill the empty CPU. IMO, > > the idle cpu mask is useful in heavy cases because a system, which is > > already fully busy with work, doesn't want to waste time looking for an > > idle cpu that doesn't exist. > > Yes, this is what v3 does. > > > But if there is an idle cpu, we should still looks for it. > > IMHO, this is a potential opportunity can be improved. The idle cpu could be > in different idle state, the idle duration could be long or could be very > short. > For example, if there are two idle cpus: > > - CPU1 is very busy, the pattern is 50us idle and 950us work. > - CPU2 is in idle for a tick length and wake up to do the regular work > > If both added to the idle cpumask, we want the latter one, or we can just add > the later one into the idle cpumask. That's why I want to associate tick stop > signal with it. > > > > >> > >> > >> - Associating with tick stop tolerates idle to preserve the idle cpumask > >> but only short idle, which causes tick retains. This is more fitable for > >> the real workload. > > > > I don't agree with this and real use cases with interaction will probably > > not agree as well as they want to run on an idle cpu if any but not wait > > on an already busy one. > > The problem is scan overhead, scanning idle cpu need time. If an idle cpu > is in the short idle mode, it's very likely that when it's picked up for a > wakeup task, it goes back to work again, and the wakeup task has to wait too, > maybe longer because the running task just starts. > > One benefit of waiting on the previous one is warm cache. > > > Also keep in mind that a tick can be up to 10ms long > > Right, but the point here is, if this 10ms tick retains, the CPU should be > in the short idle mode. But 10, 4 or even 1ms is quite long for a system and that's even more true compared to scanning the idle cpu mask > > > > >> > >>> > >>> This change means that a cpu will not be part of the idle mask if the > >>> tick is not stopped. On some arm/arm64 platforms, the tick stops only > >>> if the idle duration is expected to be higher than 1-2ms which starts > >>> to be significantly
Re: Oops (probably) unmounting /oldroot/firmware/efi/efivars.
On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote: > Hi. > > On 24.11.2020 15:23, Ard Biesheuvel wrote: > > Surely caused by > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/efivarfs?id=fe5186cf12e30facfe261e9be6c7904a170bd822 > > This also soaked through the stable queue into v5.9.11, and now the same BUG > is triggered in the latest stable kernel. > > /cc Greg cc: me for what? /me has no context as to what to do here... thanks, greg k-h
Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Sat, Nov 21, 2020 at 06:42:28AM -0600, Rob Herring wrote: > On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote: > > On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote: > > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote: > > > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > > > > Controller schema, but with additional vendor-specific properties, the > > > > controller-specific reference clocks and PHYs. So let's convert the > > > > currently available legacy text-based DWC USB3 bindings to the DT schema > > > > and make sure the DWC USB3 nodes are also validated against the > > > > usb-xhci.yaml schema. > > > > > > > > Note we have to discard the nodename restriction of being prefixed with > > > > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB > > > > nodes > > > > are supposed to be named as "^usb(@.*)". > > > > > > > > Signed-off-by: Serge Semin > > > > > > > > --- > > > > > > > > Changelog v2: > > > > - Discard '|' from the descriptions, since we don't need to preserve > > > > the text formatting in any of them. > > > > - Drop quotes from around the string constants. > > > > - Fix the "clock-names" prop description to be referring the enumerated > > > > clock-names instead of the ones from the Databook. > > > > > > > > Changelog v3: > > > > - Apply usb-xhci.yaml# schema only if the controller is supposed to work > > > > as either host or otg. > > > > > > > > Changelog v4: > > > > - Apply usb-drd.yaml schema first. If the controller is configured > > > > to work in a gadget mode only, then apply the usb.yaml schema too, > > > > otherwise apply the usb-xhci.yaml schema. > > > > - Discard the Rob'es Reviewed-by tag. Please review the patch one more > > > > time. > > > > --- > > > > .../devicetree/bindings/usb/dwc3.txt | 125 > > > > .../devicetree/bindings/usb/snps,dwc3.yaml| 303 ++ > > > > 2 files changed, 303 insertions(+), 125 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > > > > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > new file mode 100644 > > > > index ..079617891da6 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > > > > @@ -0,0 +1,303 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/usb/snps,dwc3.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Synopsys DesignWare USB3 Controller > > > > + > > > > +maintainers: > > > > + - Felipe Balbi > > > > + > > > > +description: > > > > + This is usually a subnode to DWC3 glue to which it is connected, but > > > > can also > > > > + be presented as a standalone DT node with an optional vendor-specific > > > > + compatible string. > > > > + > > > > > > +allOf: > > > > + - $ref: usb-drd.yaml# > > > > + - if: > > > > + properties: > > > > +dr_mode: > > > > + const: peripheral > > Another thing, this evaluates to true if dr_mode is not present. You > need to add 'required'? Right. Will something like this do that? + allOf: + - $ref: usb-drd.yaml# + - if: + properties: +dr_mode: + const: peripheral + + required: +- dr_mode +then: + $ref: usb.yaml# +else + $ref: usb-xhci.yaml# > If dr_mode is otg, then don't you need to apply > both usb.yaml and usb-xhci.yaml? No I don't. Since there is no peripheral-specific DT schema, then the only schema any USB-gadget node needs to pass is usb.yaml, which is already included into the usb-xhci.yaml schema. So for pure OTG devices with xHCI host and gadget capabilities it's enough to evaluate: allOf: [$ref: usb-drd.yaml#, $ref: usb-xhci.yaml#]. Please see the sketch/ASCII-figure below and the following text for details. -Sergey > > > > > +then: > > > > + $ref: usb.yaml# > > > > > > This part could be done in usb-drd.yaml? > > > > Originally I was thinking about that, but then in order to minimize > > the properties validation I've decided to split the properties in > > accordance with the USB controllers functionality: > > > > +- USB Gadget/Peripheral Controller. There is no > > | specific schema for the gadgets since there is no > > | common gadget properties (at least I failed to find > > | ones). So the pure gadget controllers need to be > > | validated just against usb.yaml schema. > > | > > usb.yaml <--+-- usb-hcd.yaml - Generic USB Host Controller. The schema > > ^ turns out to include the OHCI/UHCI/EHCI > > | properties, which AFAICS a
Re: [PATCH v3 1/4] pwm: pca9685: Switch to atomic API
On Tue, Nov 24, 2020 at 10:49:27PM -0500, Sven Van Asbroeck wrote:
> Hi Clemens, I checked the patch against the datasheet register definitions.
> More constructive feedback below.
>
> On Tue, Nov 24, 2020 at 1:10 PM Clemens Gruber
> wrote:
> >
> > The switch to the atomic API goes hand in hand with a few fixes to
> > previously experienced issues:
> > - The duty cycle is no longer lost after disable/enable (previously the
> > OFF registers were cleared in disable and the user was required to
> > call config to restore the duty cycle settings)
> > - If one sets a period resulting in the same prescale register value,
> > the sleep and write to the register is now skipped
> > - The prescale register is now set to the default value in probe. On
> > systems without CONFIG_PM, the chip is woken up at probe time.
> >
> > The hardware readout may return slightly different values than those
> > that were set in apply due to the limited range of possible prescale and
> > counter register values. If one channel is reconfigured with new duty
> > cycle and period, the others will keep the same relative duty cycle to
> > period ratio as they had before, even though the per-chip / global
> > frequency changed. (The PCA9685 has only one prescaler!)
> >
> > Note that although the datasheet mentions 200 Hz as default frequency
> > when using the internal 25 MHz oscillator, the calculated period from
> > the default prescaler register setting of 30 is 5079040ns.
> >
> > Signed-off-by: Clemens Gruber
> > ---
> > Changes since v2:
> > - Always set default prescale value in probe
> > - Simplified probe code
> > - Inlined functions with one callsite
> >
> > Changes since v1:
> > - Fixed a logic error
> > - Impoved PM runtime handling and fixed !CONFIG_PM
> > - Write default prescale reg value if invalid in probe
> > - Reuse full_off/_on functions throughout driver
> > - Use cached prescale value whenever possible
> >
> > drivers/pwm/pwm-pca9685.c | 251 +++---
> > 1 file changed, 128 insertions(+), 123 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> > index 4a55dc18656c..4cfbf1467f15 100644
> > --- a/drivers/pwm/pwm-pca9685.c
> > +++ b/drivers/pwm/pwm-pca9685.c
> > @@ -47,11 +47,11 @@
> > #define PCA9685_ALL_LED_OFF_H 0xFD
> > #define PCA9685_PRESCALE 0xFE
> >
> > +#define PCA9685_PRESCALE_DEF 0x1E/* => default frequency of ~200 Hz
> > */
> > #define PCA9685_PRESCALE_MIN 0x03/* => max. frequency of 1526 Hz */
> > #define PCA9685_PRESCALE_MAX 0xFF/* => min. frequency of 24 Hz */
> >
> > #define PCA9685_COUNTER_RANGE 4096
> > -#define PCA9685_DEFAULT_PERIOD 500 /* Default period_ns = 1/200 Hz */
> > #define PCA9685_OSC_CLOCK_MHZ 25 /* Internal oscillator with 25 MHz
> > */
> >
> > #define PCA9685_NUMREGS0xFF
> > @@ -74,7 +74,7 @@
> > struct pca9685 {
> > struct pwm_chip chip;
> > struct regmap *regmap;
> > - int period_ns;
> > + int prescale;
> > #if IS_ENABLED(CONFIG_GPIOLIB)
> > struct mutex lock;
> > struct gpio_chip gpio;
> > @@ -87,6 +87,54 @@ static inline struct pca9685 *to_pca(struct pwm_chip
> > *chip)
> > return container_of(chip, struct pca9685, chip);
> > }
> >
> > +static void pca9685_pwm_full_off(struct pca9685 *pca, int index)
> > +{
> > + int reg;
> > +
> > + /*
> > +* Set the full OFF bit to cause the PWM channel to be always off.
> > +* The full OFF bit has precedence over the other register values.
> > +*/
> > +
> > + if (index >= PCA9685_MAXCHAN)
> > + reg = PCA9685_ALL_LED_OFF_H;
> > + else
> > + reg = LED_N_OFF_H(index);
> > +
> > + regmap_write(pca->regmap, reg, LED_FULL);
> > +}
> > +
> > +static void pca9685_pwm_full_on(struct pca9685 *pca, int index)
> > +{
> > + int reg;
> > +
> > + /*
> > +* Clear the OFF registers (including the full OFF bit) and set
> > +* the full ON bit to cause the PWM channel to be always on.
> > +*/
> > +
> > + if (index >= PCA9685_MAXCHAN)
> > + reg = PCA9685_ALL_LED_OFF_L;
> > + else
> > + reg = LED_N_OFF_L(index);
> > +
> > + regmap_write(pca->regmap, reg, 0);
> > +
> > + if (index >= PCA9685_MAXCHAN)
> > + reg = PCA9685_ALL_LED_OFF_H;
> > + else
> > + reg = LED_N_OFF_H(index);
> > +
> > + regmap_write(pca->regmap, reg, 0);
> > +
> > + if (index >= PCA9685_MAXCHAN)
> > + reg = PCA9685_ALL_LED_ON_H;
> > + else
> > + reg = LED_N_ON_H(index);
> > +
> > + regmap_write(pca->regmap, reg, LED_FULL);
> > +}
> > +
> > #if IS_ENABLED(CONFIG_GPIOLIB)
> > static bool pca9685_pwm_test_and_set_inuse(struct pca9685 *pca, int
> > pwm_idx)
> > {
> > @@ -141,31 +189,27 @@ static int pca9685_pwm_gpio_get(struct gpio_chip
> > *gpio, unsigne
Re: linux-next: manual merge of the rdma tree with the arm-soc tree
On Wed, Nov 25, 2020 at 12:33:51PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> include/linux/dma-mapping.h
>
> between commit:
>
> 16fee29b0735 ("dma-mapping: remove the dma_direct_set_offset export")
>
> from the arm-soc tree and commit:
>
> 172292be01db ("dma-mapping: remove dma_virt_ops")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks, the trivial fixup looks obviously good.
Re: [PATCH -tip 12/32] sched: Simplify the core pick loop for optimized case
On Tue, Nov 24, 2020 at 12:04:30PM -0500, Joel Fernandes wrote:
> Hi Peter,
>
> On Tue, Nov 24, 2020 at 01:04:38PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 17, 2020 at 06:19:42PM -0500, Joel Fernandes (Google) wrote:
> > > + /*
> > > + * Optimize for common case where this CPU has no cookies
> > > + * and there are no cookied tasks running on siblings.
> > > + */
> > > + if (!need_sync) {
> > > + for_each_class(class) {
> > > + next = class->pick_task(rq);
> > > + if (next)
> > > + break;
> > > + }
> > > +
> > > + if (!next->core_cookie) {
> > > + rq->core_pick = NULL;
> > > + goto done;
> > > + }
> > > need_sync = true;
> > > }
> >
> > This isn't what I send you here:
> >
> >
> > https://lkml.kernel.org/r/20201026093131.gf2...@hirez.programming.kicks-ass.net
>
> I had replied to it here with concerns about the effects of newly idle
> balancing not being reverseable, it was only a theoretical concern:
> http://lore.kernel.org/r/20201105185019.ga2771...@google.com
Gah, missed that. I don't think that matters much see:
put_prev_task_balance() calling balance_fair().
> > Specifically, you've lost the whole cfs-cgroup optimization.
>
> Are you referring to this optimization in pick_next_task_fair() ?
>
> /*
> * Since we haven't yet done put_prev_entity and if the
> * selected task
> * is a different task than we started out with, try
> * and touch the
> * least amount of cfs_rqs.
> */
Yep, that. The giant FAIR_GROUP_SCHED hunk. The thing that makes
all of pick_next_task() more complicated than it really wants to be.
> You are right, we wouldn't get that with just calling pick_task_fair(). We
> did not have this in v8 series either though.
>
> Also, if the task is a cookied task, then I think you are doing more work
> with your patch due to the extra put_prev_task().
Yes, but only if you mix cookie tasks with non-cookie tasks and schedule
two non-cookie tasks back-to-back. I don't think we care overly much
about that.
I think it makes more sense to ensure that if you have core-sched
enabled on your machine and have a (core-aligned) parition with
non-cookie tasks, scheduling has works as 'normal' as possible.
> > What was wrong/not working with the below?
>
> Other than the new idle balancing, IIRC it was also causing instability.
> Maybe we can considering this optimization in the future if that's Ok with
> you?
Hurmph.. you don't happen to remember what went splat?
Re: [PATCH v3 3/4] pwm: pca9685: Support staggered output ON times
On Tue, Nov 24, 2020 at 10:51:23PM -0500, Sven Van Asbroeck wrote:
> On Tue, Nov 24, 2020 at 1:10 PM Clemens Gruber
> wrote:
> >
> > The PCA9685 supports staggered LED output ON times to minimize current
> > surges and reduce EMI.
> > When this new option is enabled, the ON times of each channel are
> > delayed by channel number x counter range / 16, which avoids asserting
> > all enabled outputs at the same counter value while still maintaining
> > the configured duty cycle of each output.
> >
> > Signed-off-by: Clemens Gruber
> > ---
> >
> > Changes since v1:
> > - Rebased
> >
> > drivers/pwm/pwm-pca9685.c | 35 ++-
> > 1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> > index 2b82b35ff0de..37c80bc8edcf 100644
> > --- a/drivers/pwm/pwm-pca9685.c
> > +++ b/drivers/pwm/pwm-pca9685.c
> > @@ -75,6 +75,7 @@ struct pca9685 {
> > struct pwm_chip chip;
> > struct regmap *regmap;
> > int prescale;
> > + bool staggered_outputs;
> > #if IS_ENABLED(CONFIG_GPIOLIB)
> > struct mutex lock;
> > struct gpio_chip gpio;
> > @@ -329,7 +330,7 @@ static int pca9685_pwm_apply(struct pwm_chip *chip,
> > struct pwm_device *pwm,
> > {
> > struct pca9685 *pca = to_pca(chip);
> > unsigned long long duty, prescale;
> > - unsigned int reg;
> > + unsigned int on, off, reg;
> >
> > if (state->polarity != PWM_POLARITY_NORMAL)
> > return -EOPNOTSUPP;
> > @@ -375,6 +376,32 @@ static int pca9685_pwm_apply(struct pwm_chip *chip,
> > struct pwm_device *pwm,
> > duty = (PCA9685_COUNTER_RANGE - 1) * state->duty_cycle;
> > duty = DIV_ROUND_UP_ULL(duty, state->period);
> >
> > + if (pca->staggered_outputs) {
> > + if (pwm->hwpwm < PCA9685_MAXCHAN) {
> > + /*
> > +* To reduce EMI, the ON times of each channel are
> > +* spread out evenly within the counter range, while
> > +* still maintaining the configured duty cycle
> > +*/
> > + on = pwm->hwpwm * PCA9685_COUNTER_RANGE /
> > + PCA9685_MAXCHAN;
> > + off = (on + duty) % PCA9685_COUNTER_RANGE;
>
> Will pwm_get_state() still return the correct duty cycle in case
> of staggered outputs?
No, but it should. I will improve the get_state function in the next
version to cover all cases.
Thanks for your input. This would have been a mess without your feedback
;)
>
> > + regmap_write(pca->regmap, LED_N_ON_L(pwm->hwpwm),
> > +on & 0xff);
> > + regmap_write(pca->regmap, LED_N_ON_H(pwm->hwpwm),
> > +(on >> 8) & 0xf);
> > + regmap_write(pca->regmap, LED_N_OFF_L(pwm->hwpwm),
> > +off & 0xff);
> > + regmap_write(pca->regmap, LED_N_OFF_H(pwm->hwpwm),
> > +(off >> 8) & 0xf);
> > + return 0;
> > + }
> > +
> > + /* No staggering possible if "all LEDs" channel is used */
> > + regmap_write(pca->regmap, PCA9685_ALL_LED_ON_L, 0);
> > + regmap_write(pca->regmap, PCA9685_ALL_LED_ON_H, 0);
> > + }
> > +
> > if (pwm->hwpwm >= PCA9685_MAXCHAN)
> > reg = PCA9685_ALL_LED_OFF_L;
> > else
> > @@ -470,6 +497,9 @@ static int pca9685_pwm_probe(struct i2c_client *client,
> >
> > regmap_write(pca->regmap, PCA9685_MODE2, reg);
> >
> > + pca->staggered_outputs = device_property_read_bool(
> > + &client->dev, "staggered-outputs");
> > +
> > /* Disable all LED ALLCALL and SUBx addresses to avoid bus
> > collisions */
> > regmap_read(pca->regmap, PCA9685_MODE1, ®);
> > reg &= ~(MODE1_ALLCALL | MODE1_SUB1 | MODE1_SUB2 | MODE1_SUB3);
> > @@ -478,6 +508,9 @@ static int pca9685_pwm_probe(struct i2c_client *client,
> > /* Reset OFF registers to HW default (only full OFF bit is set) */
> > regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_L, 0);
> > regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_H, LED_FULL);
> > + /* Reset ON registers to HW default */
> > + regmap_write(pca->regmap, PCA9685_ALL_LED_ON_L, 0);
> > + regmap_write(pca->regmap, PCA9685_ALL_LED_ON_H, 0);
> >
> > pca->chip.ops = &pca9685_pwm_ops;
> > /* Add an extra channel for ALL_LED */
> > --
> > 2.29.2
> >
Re: [PATCH -tip 15/32] sched: Improve snapshotting of min_vruntime for CGroups
On Tue, Nov 24, 2020 at 12:07:44PM -0500, Joel Fernandes wrote: > Either way would be Ok with me, I would suggest retaining the history though > so that the details in the changelog are preserved of the issues we faced, > and in the future we can refer back to them. Well, in part that's what we have mail archives for. My main concern is that there's a lot of back and forth in the patches as presented and that makes review really awkward. I've done some of the patch munging proposed, I might do more if I find the motivation. But first I should probably go read all that API crud you did on top, I've not read that before...
Re: [PATCH 1/2] sparc: Fix handling of page table constructor failure
On 25.11.20 04:46, Matthew Wilcox (Oracle) wrote:
> The page has just been allocated, so its refcount is 1. free_unref_page()
> is for use on pages which have a zero refcount. Use __free_page()
> like the other implementations of pte_alloc_one().
>
> Fixes: 1ae9ae5f7df7 ("sparc: handle pgtable_page_ctor() fail")
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> arch/sparc/mm/init_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 96edf64d4fb3..182bb7bdaa0a 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -2894,7 +2894,7 @@ pgtable_t pte_alloc_one(struct mm_struct *mm)
> if (!page)
> return NULL;
> if (!pgtable_pte_page_ctor(page)) {
> - free_unref_page(page);
> + __free_page(page);
> return NULL;
> }
> return (pte_t *) page_address(page);
>
I wonder if reusing __pte_alloc_one() - e.g., internally - would be even
cleaner.
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH 2/2] mm: Move free_unref_page to mm/internal.h
On 25.11.20 04:46, Matthew Wilcox (Oracle) wrote: > Code outside mm/ should not be calling free_unref_page(). Also > move free_unref_page_list(). > > Signed-off-by: Matthew Wilcox (Oracle) > --- > include/linux/gfp.h | 2 -- > mm/internal.h | 3 +++ > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index c603237e006c..6e479e9c48ce 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -580,8 +580,6 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t > size, gfp_t gfp_mask); > > extern void __free_pages(struct page *page, unsigned int order); > extern void free_pages(unsigned long addr, unsigned int order); > -extern void free_unref_page(struct page *page); > -extern void free_unref_page_list(struct list_head *list); > > struct page_frag_cache; > extern void __page_frag_cache_drain(struct page *page, unsigned int count); > diff --git a/mm/internal.h b/mm/internal.h > index 75ae680d0a2c..5864815947fe 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -201,6 +201,9 @@ extern void post_alloc_hook(struct page *page, unsigned > int order, > gfp_t gfp_flags); > extern int user_min_free_kbytes; > > +extern void free_unref_page(struct page *page); > +extern void free_unref_page_list(struct list_head *list); > + > extern void zone_pcp_update(struct zone *zone); > extern void zone_pcp_reset(struct zone *zone); > extern void zone_pcp_disable(struct zone *zone); > Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb
[PATCH v5 2/2] usb: typec: Expose Product Type VDOs via sysfs
A PD-capable device can return up to 3 Product Type VDOs as part of its
DiscoverIdentity Response (USB PD Spec, Rev 3.0, Version 2.0, Section
6.4.4.3.1). Add sysfs attributes to expose these to userspace.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Heikki Krogerus
---
Changes in v5:
- No changes.
Changes in v4:
- Added Reviewed-by tag from v3's review.
- Rebased on top of usb-next + Patch 1/2
Changes in v3:
- Split each product type VDO into a separate attribute.
- Changed sprintf() to sysfs_emit().
- Changed ABI documentation based on consolidation of identity VDO
descriptions in the previous patch (1/2).
Changes in v2:
- Added sysfs_notify() call for the attribute.
- Added description for the attribute in
Documentation/ABI/testing/sysfs-class-typec.
Documentation/ABI/testing/sysfs-class-typec | 24 +++
drivers/usb/typec/class.c | 33 +
2 files changed, 57 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index 88ffc14d4cd2..619c4c67432b 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -228,6 +228,30 @@ Description:
will show 0 until Discover Identity command result becomes
available. The value can be polled.
+What:
/sys/class/typec/-{partner|cable}/identity/product_type_vdo1
+Date: October 2020
+Contact: Prashant Malani
+Description:
+ 1st Product Type VDO of Discover Identity command result.
+ The value will show 0 until Discover Identity command result
becomes
+ available and a valid Product Type VDO is returned.
+
+What:
/sys/class/typec/-{partner|cable}/identity/product_type_vdo2
+Date: October 2020
+Contact: Prashant Malani
+Description:
+ 2nd Product Type VDO of Discover Identity command result.
+ The value will show 0 until Discover Identity command result
becomes
+ available and a valid Product Type VDO is returned.
+
+What:
/sys/class/typec/-{partner|cable}/identity/product_type_vdo3
+Date: October 2020
+Contact: Prashant Malani
+Description:
+ 3rd Product Type VDO of Discover Identity command result.
+ The value will show 0 until Discover Identity command result
becomes
+ available and a valid Product Type VDO is returned.
+
USB Type-C port alternate mode devices.
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index cb1362187a7c..df4478baf95b 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -124,10 +124,40 @@ static ssize_t product_show(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_RO(product);
+static ssize_t product_type_vdo1_show(struct device *dev, struct
device_attribute *attr,
+ char *buf)
+{
+ struct usb_pd_identity *id = get_pd_identity(dev);
+
+ return sysfs_emit(buf, "0x%08x\n", id->vdo[0]);
+}
+static DEVICE_ATTR_RO(product_type_vdo1);
+
+static ssize_t product_type_vdo2_show(struct device *dev, struct
device_attribute *attr,
+ char *buf)
+{
+ struct usb_pd_identity *id = get_pd_identity(dev);
+
+ return sysfs_emit(buf, "0x%08x\n", id->vdo[1]);
+}
+static DEVICE_ATTR_RO(product_type_vdo2);
+
+static ssize_t product_type_vdo3_show(struct device *dev, struct
device_attribute *attr,
+ char *buf)
+{
+ struct usb_pd_identity *id = get_pd_identity(dev);
+
+ return sysfs_emit(buf, "0x%08x\n", id->vdo[2]);
+}
+static DEVICE_ATTR_RO(product_type_vdo3);
+
static struct attribute *usb_pd_id_attrs[] = {
&dev_attr_id_header.attr,
&dev_attr_cert_stat.attr,
&dev_attr_product.attr,
+ &dev_attr_product_type_vdo1.attr,
+ &dev_attr_product_type_vdo2.attr,
+ &dev_attr_product_type_vdo3.attr,
NULL
};
@@ -146,6 +176,9 @@ static void typec_report_identity(struct device *dev)
sysfs_notify(&dev->kobj, "identity", "id_header");
sysfs_notify(&dev->kobj, "identity", "cert_stat");
sysfs_notify(&dev->kobj, "identity", "product");
+ sysfs_notify(&dev->kobj, "identity", "product_type_vdo1");
+ sysfs_notify(&dev->kobj, "identity", "product_type_vdo2");
+ sysfs_notify(&dev->kobj, "identity", "product_type_vdo3");
}
/* - */
--
2.29.2.454.gaff20da3a2-goog
[PATCH v5 1/2] usb: typec: Consolidate sysfs ABI documentation
Both partner and cable have identity VDOs. These are listed separately
in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
into a common location to avoid the duplication.
Signed-off-by: Prashant Malani
Acked-by: Heikki Krogerus
---
Changes in v5:
- Corrected the email address in the Acked-by tag.
Changes in v4:
- Rebased on top of the usb-next tree.
- Added Acked-by tag from pevious version's review.
- Corrected a typo ('syfs' -> 'sysfs') in the subject line.
Patch first introduced in v3.
Documentation/ABI/testing/sysfs-class-typec | 59 ++---
1 file changed, 17 insertions(+), 42 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index 4eccb343fc7b..88ffc14d4cd2 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -147,42 +147,6 @@ Description:
during Power Delivery discovery. This file remains hidden until
a value
greater than or equal to 0 is set by Type C port driver.
-What: /sys/class/typec/-partner>/identity/
-Date: April 2017
-Contact: Heikki Krogerus
-Description:
- This directory appears only if the port device driver is capable
- of showing the result of Discover Identity USB power delivery
- command. That will not always be possible even when USB power
- delivery is supported, for example when USB power delivery
- communication for the port is mostly handled in firmware. If the
- directory exists, it will have an attribute file for every VDO
- in Discover Identity command result.
-
-What: /sys/class/typec/-partner/identity/id_header
-Date: April 2017
-Contact: Heikki Krogerus
-Description:
- ID Header VDO part of Discover Identity command result. The
- value will show 0 until Discover Identity command result becomes
- available. The value can be polled.
-
-What: /sys/class/typec/-partner/identity/cert_stat
-Date: April 2017
-Contact: Heikki Krogerus
-Description:
- Cert Stat VDO part of Discover Identity command result. The
- value will show 0 until Discover Identity command result becomes
- available. The value can be polled.
-
-What: /sys/class/typec/-partner/identity/product
-Date: April 2017
-Contact: Heikki Krogerus
-Description:
- Product VDO part of Discover Identity command result. The value
- will show 0 until Discover Identity command result becomes
- available. The value can be polled.
-
USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
@@ -219,17 +183,28 @@ Description:
This file remains hidden until a value greater than or equal to 0
is set by Type C port driver.
-What: /sys/class/typec/-cable/identity/
+
+USB Type-C partner/cable Power Delivery Identity objects
+
+NOTE: The following attributes will be applicable to both
+partner (e.g /sys/class/typec/port0-partner/) and
+cable (e.g /sys/class/typec/port0-cable/) devices. Consequently, the example
file
+paths below are prefixed with "/sys/class/typec/-{partner|cable}/" to
+reflect this.
+
+What: /sys/class/typec/-{partner|cable}/identity/
Date: April 2017
Contact: Heikki Krogerus
Description:
This directory appears only if the port device driver is capable
of showing the result of Discover Identity USB power delivery
command. That will not always be possible even when USB power
- delivery is supported. If the directory exists, it will have an
- attribute for every VDO returned by Discover Identity command.
+ delivery is supported, for example when USB power delivery
+ communication for the port is mostly handled in firmware. If the
+ directory exists, it will have an attribute file for every VDO
+ in Discover Identity command result.
-What: /sys/class/typec/-cable/identity/id_header
+What: /sys/class/typec/-{partner|cable}/identity/id_header
Date: April 2017
Contact: Heikki Krogerus
Description:
@@ -237,7 +212,7 @@ Description:
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
-What: /sys/class/typec/-cable/identity/cert_stat
+What: /sys/class/typec/-{partner|cable}/identity/cert_stat
Date: April 2017
Contact: Heikki Krogerus
Description:
@@ -245,7 +220,7 @@ Description:
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
-What: /sys/class/typec/-cable/i
Re: Ubuntu mainline kernel builds now failing not able to find module.lds file
+++ Salvatore Bonaccorso [25/11/20 07:01 +0100]:
Hi Steve,
On Fri, Oct 30, 2020 at 12:43:24AM -0500, Steve French wrote:
I typically build cifs.ko for testing using the latest Ubuntu mainline
build - but building a module in the 5.10-rc1 kernel - while booted to
the 5.10-rc1 ubuntu mainlinekerel - e.g. "make C=1 -C
/usr/src/linux-headers-`uname -r` M=`pwd` modules
CF=-D__CHECK_ENDIAN__"
which has worked for years - no longer works.
make: Entering directory '/usr/src/linux-headers-5.10.0-051000rc1-generic'
make[2]: *** No rule to make target 'scripts/module.lds', needed by
'/home/smfrench/cifs-2.6/fs/cifs/cifs.ko'. Stop.
make[1]: *** [scripts/Makefile.modpost:117: __modpost] Error 2
make: *** [Makefile:1703: modules] Error 2
make: Leaving directory '/usr/src/linux-headers-5.10.0-051000rc1-generic'
I don't see a file in scripts/module.lds in
/usr/src/linux-headers-5.10.0-051000rc1-generic/scripts directory
copying from scripts/module.lds in the 5.10-rc1 git tree to
/usr/src/linux-headers-5.10.0-051000rc1-generic/scripts fixed the
problem but was wondering if this is just a packaging problem with
Ubuntu (missing a file in the kernel headers package for their
mainline daily builds?)
There is 596b0474d3d9 ("kbuild: preprocess module linker script") in
v5.10-rc1 causing this. So likely the packaging will need some
adjustment to cope with that change?
Yeah, likely it's a distro packaging issue. We had to account for
scripts/module.lds recently on openSUSE for example:
https://github.com/openSUSE/kernel-source/commit/fe37c160c33dc09edff1781810aa098a2c316e20
Jessica
Re: [PATCH 1/5] memory: renesas-rpc-if: Return correct value to the caller of rpcif_manual_xfer()
Hello!
On 24.11.2020 14:25, Lad Prabhakar wrote:
In the error path of rpcif_manual_xfer() the value of ret is overwritten
by value returned by reset_control_reset() function and thus returning
incorrect value to the caller.
This patch makes sure the correct value is returned to the caller of
rpcif_manual_xfer() by dropping the overwrite of ret in error path.
Also now we ignore the value returned by reset_control_reset() in the
error path and instead print a error message when it fails.
Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
Reported-by: Pavel Machek
Signed-off-by: Lad Prabhakar
Cc: sta...@vger.kernel.org
Reviewed-by: Sergei Shtylyov
MBR, Sergei
Re: [PATCH -tip 19/32] entry/idle: Enter and exit kernel protection during idle entry and exit
On Tue, Nov 24, 2020 at 01:03:43PM -0500, Joel Fernandes wrote:
> On Tue, Nov 24, 2020 at 05:13:35PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 17, 2020 at 06:19:49PM -0500, Joel Fernandes (Google) wrote:
> > > +static inline void generic_idle_enter(void)
> > > +static inline void generic_idle_exit(void)
> > That naming is terrible..
>
> Yeah sorry :-\. The naming I chose was to be aligned with the
> CONFIG_GENERIC_ENTRY naming. I am open to ideas on that.
entry_idle_{enter,exit}() ?
> > I'm confused.. arch_cpu_idle_{enter,exit}() weren't conveniently placed
> > for you?
>
> The way this patch series works, it does not depend on arch code as much as
> possible. Since there are other arch that may need this patchset such as ARM,
> it may be better to keep it in the generic entry code. Thoughts?
I didn't necessarily mean using those hooks, even placing your new hooks
right next to them would've covered the exact same code with less lines
modified.
Re: [PATCH v4 1/2] usb: typec: Consolidate sysfs ABI documentation
Hi Heikki, On Tue, Nov 24, 2020 at 11:53 PM Heikki Krogerus wrote: > > On Wed, Nov 25, 2020 at 09:46:06AM +0200, Heikki Krogerus wrote: > > On Tue, Nov 24, 2020 at 12:32:35PM -0800, Prashant Malani wrote: > > > Hi, > > > > > > On Tue, Nov 24, 2020 at 12:10:31PM -0800, Prashant Malani wrote: > > > > Both partner and cable have identity VDOs. These are listed separately > > > > in the Documentation/ABI/testing/sysfs-class-typec. Factor these out > > > > into a common location to avoid the duplication. > > > > > > > > Signed-off-by: Prashant Malani > > > > Acked-by: Heikki Krogerus > > > I copied the Acked-by line from v3 [1] as is, but looks like there was a > > > typo there and the email address should be > > > "heikki.kroge...@linux.intel.com". > > > > > > Please let me know if it's fine as is or whether I should send another > > > patchset. > > > > It is fine. Thanks for taking care of that :-) > > Arch, no. It's not fine (I don't know what I'm talking about there). I > think it would be better that you do resend. Got it. v5 sent [1] [1] https://lore.kernel.org/linux-usb/20201125084911.1077462-1-pmal...@chromium.org/ Thanks, -Prashant
Re: nwl-dsi: fixup mode only for LCDIF input, not DCSS
Hi Lukas,
On Tue, Nov 24, 2020 at 06:12:17PM +0100, Lukas F. Hartmann wrote:
> The fixup of HSYNC and VSYNC should not be done when the input source is
> DCSS, or internal display does not work on MNT Reform 2 (open hardware
> laptop based on NXP i.MX8M using DCSS->DSI->eDP for internal display).
>
> Signed-off-by: Lukas F. Hartmann
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 66b67402f..6735ab2a2 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -807,10 +807,16 @@ static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge
> *bridge,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> - /* At least LCDIF + NWL needs active high sync */
> - adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> - adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> + struct device_node *remote;
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
> + NWL_DSI_ENDPOINT_LCDIF);
> + if (remote) {
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> + }
When submitting the NWL driver i was told to not change properties based
on the endpoint. The argument is that this breaks when putting the
bridge into another chain and that there might be other bridges in
between. Maybe Laurent and Andrzej have a suggetion?
I intend to respin the input mux bridge
(https://lore.kernel.org/dri-devel/cover.1589548223.git@sigxcpu.org/)
at some point but even then we need to carry over the flags, so any
input on how that should best be done would be welcome.
Cheers,
-- Guido
>
> return true;
> }
> --
> 2.28.0
>
Re: [PATCH] riscv: defconfig: k210: Disable CONFIG_VT
Hi Damien,
On Wed, Nov 25, 2020 at 7:14 AM Damien Le Moal wrote:
> On 2020/11/25 3:57, Geert Uytterhoeven wrote:
> > There is no need to enable Virtual Terminal support in the Canaan
> > Kendryte K210 defconfigs, as no terminal devices are supported and
> > enabled. Hence disable CONFIG_VT, and remove the no longer needed
> > override for CONFIG_VGA_CONSOLE.
> >
> > This reduces kernel size by ca. 65 KiB.
>
> Indeed, nice saving. Just tested, and all is good.
I used my old script[1] to check the impact of disabling config options.
I don't see any other low-hanging fruits:
Disabling CONFIG_BLOCK saves 492890 bytes
Disabling CONFIG_EXT4_FS saves 322528 bytes
Disabling CONFIG_PRINTK saves 214612 bytes
Disabling CONFIG_SMP saves 214486 bytes
Disabling CONFIG_FRAME_POINTER saves 166368 bytes
Disabling CONFIG_TTY saves 156618 bytes
Disabling CONFIG_PROC_FS saves 110274 bytes
Disabling CONFIG_MMC saves 87656 bytes
Disabling CONFIG_VT saves 70350 bytes
Disabling CONFIG_SYSFS saves 62298 bytes
Disabling CONFIG_BUG saves 50882 bytes
Disabling CONFIG_SPI saves 34420 bytes
Disabling CONFIG_SOC_CANAAN saves 34286 bytes
Disabling CONFIG_I2C saves 34086 bytes
Disabling CONFIG_PROC_SYSCTL saves 23890 bytes
Disabling CONFIG_POSIX_TIMERS saves 18388 bytes
Disabling CONFIG_I2C_DESIGNWARE_PLATFORM saves 17530 bytes
Disabling CONFIG_MMC_BLOCK saves 17200 bytes
Disabling CONFIG_UNIX98_PTYS saves 16360 bytes
Disabling CONFIG_MULTIUSER saves 16148 bytes
Disabling CONFIG_NEW_LEDS saves 15964 bytes
Disabling CONFIG_SPI_DESIGNWARE saves 15434 bytes
Disabling CONFIG_GPIO_CDEV saves 15352 bytes
Disabling CONFIG_MMC_SPI saves 14754 bytes
Disabling CONFIG_SOC_CANAAN_K210_DTB_BUILTIN saves 13864 bytes
(Yes, I have ext4 enabled ;-)
I haven't done enough riscv kernel development yet to assess if I need
CONFIG_FRAME_POINTER or not.
[1]
https://github.com/geertu/linux-scripts/blob/master/linux-analyze-marginal-sizes
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages
On Wed, Nov 25, 2020 at 07:45:30AM +0100, David Hildenbrand wrote:
>
> > Am 25.11.2020 um 06:34 schrieb Andrea Arcangeli :
> >
> > Hello,
> >
> >> On Mon, Nov 23, 2020 at 02:01:16PM +0100, Vlastimil Babka wrote:
> >>> On 11/21/20 8:45 PM, Andrea Arcangeli wrote:
> >>> A corollary issue was fixed in
> >>> 39639000-39814fff : Unknown E820 type
> >>>
> >>> pfn 0x7a200 -> 0x7a20 min_pfn hit non-RAM:
> >>>
> >>> 7a17b000-7a216fff : Unknown E820 type
> >>
> >> It would be nice to also provide a /proc/zoneinfo and how exactly the
> >> "zone_spans_pfn" was violated. I assume we end up below zone's
> >> start_pfn, but is it true?
> >
> > Agreed, I was about to grab that info along with all page struct
> > around the pfn 0x7a200 and phys address 0x7a216fff.
> >
> > # grep -A1 E820 /proc/iomem
> > 7a17b000-7a216fff : Unknown E820 type
> > 7a217000-7bff : System RAM
> >
> > DMA zone_start_pfn 1zone_end_pfn() 4096 contiguous
> > 1
> > DMA32zone_start_pfn 4096 zone_end_pfn() 1048576 contiguous
> > 0
> > Normal zone_start_pfn 1048576 zone_end_pfn() 4715392 contiguous
> > 1
> > Movable zone_start_pfn 0zone_end_pfn() 0contiguous
> > 0
> >
> > 500222 0x7a1fe000 0x1fff1000 reserved True
> > 500223 0x7a1ff000 0x1fff1000 reserved True
> >
> > # I suspect "highest pfn" was somewhere in the RAM range
> > # 0x7a217000-0x7a40 and the pageblock_start_pfn(pfn)
> > # made highest point to pfn 0x7a200 physaddr 0x7a20
> > # below, which is reserved indeed since it's non-RAM
> > # first number is pfn hex(500224) == 0x7a200
> >
> > pfnphysaddr page->flags
> > 500224 0x7a20 0x1fff1000 reserved True
> > 500225 0x7a201000 0x1fff1000 reserved True
> > *snip*
> > 500245 0x7a215000 0x1fff1000 reserved True
> > 500246 0x7a216000 0x1fff1000 reserved True
> > 500247 0x7a217000 0x3fff reserved False
> > 500248 0x7a218000 0x3fff reserved False
> >
> > All RAM pages non-reserved are starting at 0x7a217000 as expected.
> >
> > The non-RAM page_zonenum(pfn_to_page(0x7a200)) points to ZONE_DMA and
> > page_zone(page) below was the DMA zone despite the pfn of 0x7a200 is
> > in DMA32.
> >
> >VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
> >
> > So the patch I sent earlier should prevent the above BUG_ON by not
> > setting highest to 0x7a200 when pfn is in the phys RAM range
> > 0x7a217000-0x7a40, because pageblock_pfn_to_page will notice that
> > the zone is the wrong one.
> >
> >if (page_zone(start_page) != zone)
> >return NULL;
> >
> > However the real bug seems that reserved pages have a zero zone_id in
> > the page->flags when it should have the real zone id/nid. The patch I
> > sent earlier to validate highest would only be needed to deal with
> > pfn_valid.
> >
> > Something must have changed more recently than v5.1 that caused the
> > zoneid of reserved pages to be wrong, a possible candidate for the
> > real would be this change below:
> >
> > + __init_single_page(pfn_to_page(pfn), pfn, 0, 0);
> >
>
> Before that change, the memmap of memory holes were only zeroed out.
> So the zones/nid was 0, however, pages were not reserved and had a
> refcount of zero - resulting in other issues.
>
> Most pfn walkers shouldn‘t mess with reserved pages and simply skip
> them. That would be the right fix here.
My guest would be that it is me and Baoquan:
73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather that check
each PFN")
Until then reserved pages were traversed in memmap_init_zone() and after
the change they are not because on x86 reserved memory is not considered
memory for some reason.
Can you please check if this untested patch helps:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index eaa227a479e4..be3c85a6714e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6191,7 +6191,9 @@ void __meminit __weak memmap_init(unsigned long size, int
nid,
{
unsigned long start_pfn, end_pfn;
unsigned long range_end_pfn = range_start_pfn + size;
+ phys_addr_t start, end;
int i;
+ u64 j;
for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
@@ -6203,6 +6205,19 @@ void __meminit __weak memmap_init(unsigned long size,
int nid,
MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
}
}
+
+ __for_each_mem_range(j, &memblock.reserved, NULL, nid, MEMBLOCK_NONE,
+&start, &end, NULL) {
+ start_pfn = clamp(PHYS_PFN(start), range_start_pfn,
+ range_end_pfn);
+ end_pfn = clamp(PHYS_PFN(end), range_start_pfn, range_end_pfn);
+
+ if (end_pfn > start_pfn) {
+ size = end_pfn -
Finanziamenti per la realizzazione di progetti redditizi
Mi chiamo Kenneth Scott, sono un finanziere privato e sono disposto a concederti prestiti da 5.000 euro a 50.000.000 euro con un tasso di interesse del 2% sull'intero periodo di rimborso. Ecco le aree in cui posso aiutarti: 1- Finanziamenti per la realizzazione di progetti redditizi. 2- Finanziamento di progetto per la creazione di un'impresa dove sei amministratore di un'azienda in difficoltà di finanziamento privato. 3- Finanziamenti per creare un'organizzazione di prestiti pubblici. 4- Finanziamento per creare o rilevare un hotel o qualsiasi progetto di svago. 5- Finanziamento di proficui progetti di solidarietà, ospedali, cliniche, bar, ristorante, sala giochi, sala cinema ecc ... 6- Finanziamento di qualsiasi immobile, trasporto o altro progetto. 7- Finanziamento di qualsiasi azienda di import-export, logistica o altro. 8- Finanziamento di un'azienda o di un progetto attualmente in fallimento. Faccio prestiti con un tasso di interesse del 2% su tutta la durata, infatti è fondamentale che ci diamo una spinta e torniamo ad avere un profitto per questo metto a vostra disposizione tutti i tipi di prestito. Non esitate a contattarci, questo non vi impegna in nulla ed è garantita la massima riservatezza e approvazione. kennethscott12...@gmail.com
Re: [PATCH 1/2] sparc: Fix handling of page table constructor failure
On Wed, Nov 25, 2020 at 03:46:54AM +, Matthew Wilcox (Oracle) wrote:
> The page has just been allocated, so its refcount is 1. free_unref_page()
> is for use on pages which have a zero refcount. Use __free_page()
> like the other implementations of pte_alloc_one().
>
> Fixes: 1ae9ae5f7df7 ("sparc: handle pgtable_page_ctor() fail")
> Signed-off-by: Matthew Wilcox (Oracle)
Reviewed-by: Mike Rapoport
> ---
> arch/sparc/mm/init_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 96edf64d4fb3..182bb7bdaa0a 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -2894,7 +2894,7 @@ pgtable_t pte_alloc_one(struct mm_struct *mm)
> if (!page)
> return NULL;
> if (!pgtable_pte_page_ctor(page)) {
> - free_unref_page(page);
> + __free_page(page);
> return NULL;
> }
> return (pte_t *) page_address(page);
> --
> 2.29.2
>
--
Sincerely yours,
Mike.
Re: [PATCH 2/2] mm: Move free_unref_page to mm/internal.h
On Wed, Nov 25, 2020 at 03:46:55AM +, Matthew Wilcox (Oracle) wrote: > Code outside mm/ should not be calling free_unref_page(). Also > move free_unref_page_list(). > > Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Mike Rapoport > --- > include/linux/gfp.h | 2 -- > mm/internal.h | 3 +++ > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index c603237e006c..6e479e9c48ce 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -580,8 +580,6 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t > size, gfp_t gfp_mask); > > extern void __free_pages(struct page *page, unsigned int order); > extern void free_pages(unsigned long addr, unsigned int order); > -extern void free_unref_page(struct page *page); > -extern void free_unref_page_list(struct list_head *list); > > struct page_frag_cache; > extern void __page_frag_cache_drain(struct page *page, unsigned int count); > diff --git a/mm/internal.h b/mm/internal.h > index 75ae680d0a2c..5864815947fe 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -201,6 +201,9 @@ extern void post_alloc_hook(struct page *page, unsigned > int order, > gfp_t gfp_flags); > extern int user_min_free_kbytes; > > +extern void free_unref_page(struct page *page); > +extern void free_unref_page_list(struct list_head *list); > + > extern void zone_pcp_update(struct zone *zone); > extern void zone_pcp_reset(struct zone *zone); > extern void zone_pcp_disable(struct zone *zone); > -- > 2.29.2 > -- Sincerely yours, Mike.
Re: [PATCH 3/5] memory: renesas-rpc-if: Export symbols as GPL
On 24.11.2020 14:25, Lad Prabhakar wrote: Renesas RPC-IF driver is licensed under GPL2.0, to be in sync export the symbols as GPL. Didn't know there's a connection... Suggested-by: Pavel Machek Signed-off-by: Lad Prabhakar Reviewed-by: Sergei Shtylyov [...] MBR, Sergei
Re: [PATCH v6 17/17] RFC: mm: add mmu_notifier argument to follow_pfn
On Wed, Nov 25, 2020 at 9:13 AM Jason Gunthorpe wrote:
>
> On Tue, Nov 24, 2020 at 03:28:14PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 20, 2020 at 02:30:29PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> > > > @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> > > > * Return: zero and the pfn at @pfn on success, -ve otherwise.
> > > > */
> > > > int follow_pfn(struct vm_area_struct *vma, unsigned long address,
> > > > - unsigned long *pfn)
> > > > + unsigned long *pfn, struct mmu_notifier *subscription)
> > > > {
> > > > - int ret = -EINVAL;
> > > > - spinlock_t *ptl;
> > > > - pte_t *ptep;
> > > > + if (WARN_ON(!subscription->mm))
> > > > + return -EINVAL;
> > > >
> > > > + if (WARN_ON(subscription->mm != vma->vm_mm))
> > > > + return -EINVAL;
> > >
> > > These two things are redundant right? vma->vm_mm != NULL?
> >
> > Yup, will remove.
> >
> > > BTW, why do we even have this for nommu? If the only caller is kvm,
> > > can you even compile kvm on nommu??
> >
> > Kinda makes sense, but I have no idea how to make sure with compile
> > testing this is really the case. And I didn't see any hard evidence in
> > Kconfig or Makefile that mmu notifiers requires CONFIG_MMU. So not sure
> > what to do here.
>
> It looks like only some arches have selectable CONFIG_MMU: arm,
> m68k, microblaze, riscv, sh
>
> If we look at arches that work with HAVE_KVM, I only see: arm64, mips,
> powerpc, s390, x86
>
> So my conclusion is there is no intersection between !MMU and HAVE_KVM?
>
> > Should I just remove the nommu version of follow_pfn and see what happens?
> > We can't remove it earlier since it's still used by other
> > subsystems.
>
> This is what I was thinking might work
Makes sense, I'll do that for the next round.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote: > On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > > wrote: > > > It's not about the risk of the changes it's about the cost of > > > implementing them. Even if you discount the producer time (which > > > someone gets to pay for, and if I were the engineering manager, I'd > > > be unhappy about), the review/merge/rework time is pretty > > > significant in exchange for six minor bug fixes. Fine, when a new > > > compiler warning comes along it's certainly reasonable to see if we > > > can benefit from it and the fact that the compiler people think > > > it's worthwhile is enough evidence to assume this initially. But > > > at some point you have to ask whether that assumption is supported > > > by the evidence we've accumulated over the time we've been using > > > it. And if the evidence doesn't support it perhaps it is time to > > > stop the experiment. > > > > Maintainers routinely review 1-line trivial patches, not to mention > > internal API changes, etc. > > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 > > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches ... I'm pushing back > on that assumption in two places, firstly the valulessness of the time > and secondly that all trivial patches are valuable. You're assuming burn out or recruitment problems is due to patch workload or too many "trivial" patches. In my experience, "other maintainers" is by far the biggest cause of burn out for my kernel maintenance work. Certainly arguing with a maintainer about some obviously-correct patch series must be a good example of this. Sean
Re: [PATCH] riscv: defconfig: k210: Disable CONFIG_VT
On 2020/11/25 17:51, Geert Uytterhoeven wrote:
> Hi Damien,
>
> On Wed, Nov 25, 2020 at 7:14 AM Damien Le Moal wrote:
>> On 2020/11/25 3:57, Geert Uytterhoeven wrote:
>>> There is no need to enable Virtual Terminal support in the Canaan
>>> Kendryte K210 defconfigs, as no terminal devices are supported and
>>> enabled. Hence disable CONFIG_VT, and remove the no longer needed
>>> override for CONFIG_VGA_CONSOLE.
>>>
>>> This reduces kernel size by ca. 65 KiB.
>>
>> Indeed, nice saving. Just tested, and all is good.
>
> I used my old script[1] to check the impact of disabling config options.
>
> I don't see any other low-hanging fruits:
>
> Disabling CONFIG_BLOCK saves 492890 bytes
> Disabling CONFIG_EXT4_FS saves 322528 bytes
> Disabling CONFIG_PRINTK saves 214612 bytes
> Disabling CONFIG_SMP saves 214486 bytes
> Disabling CONFIG_FRAME_POINTER saves 166368 bytes
> Disabling CONFIG_TTY saves 156618 bytes
> Disabling CONFIG_PROC_FS saves 110274 bytes
> Disabling CONFIG_MMC saves 87656 bytes
> Disabling CONFIG_VT saves 70350 bytes
> Disabling CONFIG_SYSFS saves 62298 bytes
> Disabling CONFIG_BUG saves 50882 bytes
> Disabling CONFIG_SPI saves 34420 bytes
> Disabling CONFIG_SOC_CANAAN saves 34286 bytes
> Disabling CONFIG_I2C saves 34086 bytes
> Disabling CONFIG_PROC_SYSCTL saves 23890 bytes
> Disabling CONFIG_POSIX_TIMERS saves 18388 bytes
> Disabling CONFIG_I2C_DESIGNWARE_PLATFORM saves 17530 bytes
> Disabling CONFIG_MMC_BLOCK saves 17200 bytes
> Disabling CONFIG_UNIX98_PTYS saves 16360 bytes
> Disabling CONFIG_MULTIUSER saves 16148 bytes
> Disabling CONFIG_NEW_LEDS saves 15964 bytes
> Disabling CONFIG_SPI_DESIGNWARE saves 15434 bytes
> Disabling CONFIG_GPIO_CDEV saves 15352 bytes
> Disabling CONFIG_MMC_SPI saves 14754 bytes
> Disabling CONFIG_SOC_CANAAN_K210_DTB_BUILTIN saves 13864 bytes
>
> (Yes, I have ext4 enabled ;-)
>
> I haven't done enough riscv kernel development yet to assess if I need
> CONFIG_FRAME_POINTER or not.
Disabling it significantly reduced code size for me. Since the series is more
stable now, it is not really needed, so I disabled it in the defconfig.
I was just fiddling with CONFIG_UNIX98_PTYS. Disabling it is OK with the simple
busybox userspace (no telnet/xterm like app running). But it saves only about
1KB with my toolchain (gcc 9.3). So I left that one enabled. I am surprised that
you see 16K size impact... How big is your image ?
For me, it is 1.768 MB right now for the sdcard defconfig, with CONFIG_VT
disabled and ext2 enabled.
Disabling the block layer, ext2 and mmc driver, the size goes down to 1.511 MB
without any intramfs cpio file embedded.
>
> [1]
> https://github.com/geertu/linux-scripts/blob/master/linux-analyze-marginal-sizes
Thanks ! I will try to run this on my end.
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Damien Le Moal
Western Digital Research
Re: [REGRESSION] omapdrm/N900 display broken
On Tue, Aug 25, 2020 at 3:16 PM Tomi Valkeinen wrote: > > Hi Laurent, > > On 23/08/2020 19:26, Aaro Koskinen wrote: > > Hi, > > > > On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote: > >> On 04/08/2020 15:13, Tomi Valkeinen wrote: > > > >>> Can you try to pinpoint a bit where the hang happens? Maybe add > >>> DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock > >>> that's in deadlock. > >> > >> Also, one data point would be to disable venc, e.g. set venc status to > >> "disabled" in dts. > > > > Disabling venc makes no difference. > > > > The hang happens in drm_fb_helper_initial_config(). I followed the > > "HANG DEBUGGING" tips in the function comment text and enabled > > fb.lockless_register_fb=1 to get more (serial) console output. > > > > Now I get this: > > > > [6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using > > dummy regulator > > [6.566375] DSS: OMAP DSS rev 2.0 > > [6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops > > dispc_component_ops) > > [6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support > > [6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [6.626617] [ cut here ] > > [6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 > > drm_atomic_helper_commit_modeset_enables+0x134/0x268 > > [6.643768] Modules linked in: > > [6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U > > 5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2 > > [6.658966] Hardware name: Nokia RX-51 board > > [6.663635] Workqueue: events deferred_probe_work_func > > [6.669097] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > [6.677429] [] (show_stack) from [] > > (__warn+0xbc/0xd4) > > [6.684844] [] (__warn) from [] > > (warn_slowpath_fmt+0x60/0xb8) > > [6.692901] [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_commit_modeset_enables+0x134/0x268) > > [6.704254] [] (drm_atomic_helper_commit_modeset_enables) from > > [] (omap_atomic_commit_tail+0xb4/0xc0) > > [6.715972] [] (omap_atomic_commit_tail) from [] > > (commit_tail+0x9c/0x1a8) > > [6.725128] [] (commit_tail) from [] > > (drm_atomic_helper_commit+0x134/0x158) > > [6.734466] [] (drm_atomic_helper_commit) from [] > > (drm_client_modeset_commit_atomic+0x16c/0x208) > > [6.745727] [] (drm_client_modeset_commit_atomic) from > > [] (drm_client_modeset_commit_locked+0x58/0x184) > > [6.757629] [] (drm_client_modeset_commit_locked) from > > [] (drm_client_modeset_commit+0x24/0x40) > > [6.768798] [] (drm_client_modeset_commit) from [] > > (__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8) > > [6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) > > from [] (drm_fb_helper_set_par+0x38/0x64) > > [6.792785] [] (drm_fb_helper_set_par) from [] > > (fbcon_init+0x3d4/0x568) > > [6.801757] [] (fbcon_init) from [] > > (visual_init+0xb8/0xfc) > > [6.809631] [] (visual_init) from [] > > (do_bind_con_driver+0x1e0/0x3bc) > > [6.818267] [] (do_bind_con_driver) from [] > > (do_take_over_console+0x138/0x1d8) > > [6.827880] [] (do_take_over_console) from [] > > (do_fbcon_takeover+0x74/0xd4) > > [6.837219] [] (do_fbcon_takeover) from [] > > (register_framebuffer+0x204/0x2d8) > > [6.846740] [] (register_framebuffer) from [] > > (__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554) > > [6.858459] [] (__drm_fb_helper_initial_config_and_unlock) > > from [] (omap_fbdev_init+0x84/0xbc) > > [6.869537] [] (omap_fbdev_init) from [] > > (pdev_probe+0x580/0x7d8) > > [6.877807] [] (pdev_probe) from [] > > (platform_drv_probe+0x48/0x98) > > Laurent, does this ring any bells? The WARN comes in > drm_atomic_bridge_chain_enable() when > drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge. > > I'm not sure why the bridge state would not be there. Lack of state on first modeset usually means your drm_mode_config_reset didn't create one. Or whatever it is you're using. I didn't look whether you're wiring this up correctly or not. We might even want to add a ->reset function to drm_private_state_funcs to make this work for everyone. -Daniel > Aaro, you can probably debug easier if you disable > CONFIG_FRAMEBUFFER_CONSOLE, or even > CONFIG_DRM_FBDEV_EMULATION. > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/ast: Fixed CVE for DP501
[Bug][DP501]
1. For security concerning, P2A have to be disabled by CVE regulation.
2. FrameBuffer reverses last 2MB used for the image of DP501.
3. If P2A is disallowed, the default "ioremap()" behavior is non-cached
and could be an alternative accessing on the image of DP501.
---
drivers/gpu/drm/ast/ast_dp501.c | 131 +++-
drivers/gpu/drm/ast/ast_drv.h | 2 +
drivers/gpu/drm/ast/ast_main.c | 12 +++
drivers/gpu/drm/ast/ast_mm.c| 1 +
4 files changed, 110 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index 88121c0e0d05..7640364ef2bc 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -189,6 +189,8 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32
size)
u32 i, data;
u32 boot_address;
+ if (ast->config_mode != ast_use_p2a) return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (data) {
boot_address = get_fw_base(ast);
@@ -207,6 +209,8 @@ static bool ast_launch_m68k(struct drm_device *dev)
u8 *fw_addr = NULL;
u8 jreg;
+ if (ast->config_mode != ast_use_p2a) return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (!data) {
@@ -272,24 +276,51 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev)
u32 boot_address, offset, data;
u8 linkcap[4], linkrate, linklanes, maxclk = 0xff;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10) /* version: 1x */
- return maxclk;
-
- /* Read Link Capability */
- offset = 0xf014;
- *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
- if (linkcap[2] == 0) {
- linkrate = linkcap[0];
- linklanes = linkcap[1];
- data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * linklanes);
- if (data > 0xff)
- data = 0xff;
- maxclk = (u8)data;
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
+
+ /* validate FW version */
+ offset = 0xf000;
+ data = ast_mindwm(ast, boot_address + offset);
+ if ((data & 0xf0) != 0x10) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = 0xf014;
+ *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
+ }
+ else {
+ if (!ast->reservedbuffer) return 65;/* 1024x768 as default
*/
+
+ /* dummy read */
+ offset = 0x;
+ data = *(u32 *) (ast->reservedbuffer + offset);
+
+ /* validate FW version */
+ offset = 0xf000;
+ data = *(u32 *) (ast->reservedbuffer + offset);
+ if ((data & 0xf0) != 0x10) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = 0xf014;
+ *(u32 *)linkcap = *(u32 *) (ast->reservedbuffer + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
}
return maxclk;
}
@@ -299,25 +330,53 @@ bool ast_dp501_read_edid(struct drm_device *dev, u8
*ediddata)
struct ast_private *ast = to_ast_private(dev);
u32 i, boot_address, offset, data;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10)
- return false;
-
- /* validate PnP Monitor */
- offset = 0xf010;
- data = ast_mindwm(ast, boot_address + offset);
- if (!(data & 0x01))
- return false;
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
- /* Read EDID */
- offset = 0xf020;
- for (i = 0; i < 128; i += 4) {
- data = ast_mindwm(ast, boot_address + offset + i);
- *(u32 *)(ediddata + i) = data;
+ /* validate FW version */
+
Re: [PATCH v1] spi: fix client driver breakages when using GPIO descriptors
On 11/11/2020 13:36, Linus Walleij wrote: On Wed, Nov 11, 2020 at 1:33 PM Mark Brown wrote: On Wed, Nov 11, 2020 at 02:05:19AM +0100, Linus Walleij wrote: I would say that anything that has: spi->mode = ... is essentially broken. This is not clear to me, most of these settings are things that are constant for the device so it's not clear that they should be being set by the device tree in the first place. This was added initially with some two properties in drivers/of/of_spi.c in 2008: commit 284b01897340974000bcc84de87a4e1becc8a83d "spi: Add OF binding support for SPI busses" This was around the time ARM was first starting to migrate to device tree, so I suppose it made sense to them/us back then. Some properties were the accumulated over time. commit d57a4282d04810417c4ed2a49cbbeda8b3569b18 "spi/devicetree: Move devicetree support code into spi directory" made this part of the SPI subsystem. This seems as simple as nobody was there to push back and say "wait the devices can specify that with code, don't put it as properties in device tree". To be honest we have kind of moved back and forward on that topic over time. :/ The idea that the chip select might be being inverted like it is by this whole gpiolib/DT/new binding thing is breaking expectations too. OK I think you're right, then this patch probably brings the behaviour back to expectations and it's how I should have done it in the first place. My bad code :/ Reviewed-by: Linus Walleij The core sets up vital things in .mode from e.g. device tree in of_spi_parse_dt(): /* Mode (clock phase/polarity/etc.) */ if (of_property_read_bool(nc, "spi-cpha")) spi->mode |= SPI_CPHA; if (of_property_read_bool(nc, "spi-cpol")) spi->mode |= SPI_CPOL; if (of_property_read_bool(nc, "spi-3wire")) spi->mode |= SPI_3WIRE; if (of_property_read_bool(nc, "spi-lsb-first")) spi->mode |= SPI_LSB_FIRST; if (of_property_read_bool(nc, "spi-cs-high")) spi->mode |= SPI_CS_HIGH; All this gets overwritten and ignored when a client just assigns mode like that. Not just SPI_CS_HIGH. I doubt things are different with ACPI. OTOH most of these are things the device driver should just get right without needing any input from DT, there's a few where there's plausible options (eg, you can imagine pin strap configuration for 3 wire mode) Yes I actually ran into a case where the same Samsung display support both 4 and 3-wire mode so that needs to be configured in the device tree depending on the layout of the electronics. Arguably we should have just standardized the device tree bindings and let the individual SPI drivers parse that themselves in such cases. so generally it's not clear how many of these make sense for anything other than spidev. This binding all predates my involvement so I don't know the thought process here. I dug out some details, let's see if Grant has some historical anecdotes to add. The usage document from back then doesn't really say what device properties should be encoded in the device tree and what should just be assigned by code and e.g. determined from the compatible-string. It was later that especially Rob pointed out that random properties on device nodes was overused and that simply knowing the compatible is often enough. I think your analysis is correct. When this was done we were still figuring stuff out and the abstraction between device and bus in SPI isn't exactly clean. I don't have anything to add. g. I don't know if we ever formalized it, there is nowadays a rule akin to "if a property can be determined from the compatible-string, and if the compatible-string is identifying the variant of the electronic component, then do not add this property to the device tree description. Just deduce it from the compatible-string, assign it with code to the device model of the operating system and handle it inside the operating system." I think this, while clear and intuitive, wasn't at all clear and intuitive in the recent past. Yours, Linus Walleij IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH 1/2] firmware: arm_scmi: Add power_scale_mw_get() interface
On 11/24/20 4:56 PM, Sudeep Holla wrote: On Tue, Nov 24, 2020 at 10:43:45AM +, Lukasz Luba wrote: Add a new interface to the existing perf_ops and export the information about the power values scale. This would be used by the cpufreq driver and Energy Model framework to set the performance domains scale: milli-Watts or abstract scale. Looks good to me. I saw this after I sent pull request this afternoon. In case you want to take it via PM tree: Acked-by: Sudeep Holla Thank you Sudeep! Regards, Lukasz
Re: [PATCH v1] spi: fix client driver breakages when using GPIO descriptors
On 18/11/2020 11:40, Mark Brown wrote: On Wed, Nov 18, 2020 at 02:03:41AM +0100, Linus Walleij wrote: On Mon, Nov 16, 2020 at 10:06 PM Mark Brown wrote: I think the main push in the other direction has always been people who want to not have to write a driver at all and put absolutely everything into DT which has scaling issues :/ What I can't understand is what gave them that idea. This thing looks like a dream to these people for example: https://gist.github.com/Minecrell/56c2b20118ba00a9723f0785301bc5ec#file-dsi_panel_s6e88a0_ams452ef01_qhd_octa_video-dtsi And it looks like a nightmare to me. (There is even a tool to convert this description into a proper display driver now.) It just seems to be one of those golden hammer things: everything start to look like nails. What people think they were sold was the idea that they shouldn't have to write driver code or upstream things, something with more AML like capabilities (not realising that AML works partly because ACPI hugely constrains system design). And is also untrue. AML only provides an API abstraction for a specific power management model. All the actual driving of the device still requires driver code and requires reading devices-specific properties out of the ACPI node. g.
Re: kernel BUG at fs/ext4/inode.c:LINE!
On Tue 24-11-20 12:19:12, Matthew Wilcox wrote: > On Mon, Nov 23, 2020 at 08:07:24PM -0800, Hugh Dickins wrote: > > Twice now, when exercising ext4 looped on shmem huge pages, I have crashed > > on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling > > end_page_writeback() calling wake_up_page() on tail of a shmem huge page, > > no longer an ext4 page at all. > > > > The problem is that PageWriteback is not accompanied by a page reference > > (as the NOTE at the end of test_clear_page_writeback() acknowledges): as > > soon as TestClearPageWriteback has been done, that page could be removed > > from page cache, freed, and reused for something else by the time that > > wake_up_page() is reached. > > > > https://lore.kernel.org/linux-mm/20200827122019.gc14...@casper.infradead.org/ > > Matthew Wilcox suggested avoiding or weakening the PageWaiters() tail > > check; but I'm paranoid about even looking at an unreferenced struct page, > > lest its memory might itself have already been reused or hotremoved (and > > wake_up_page_bit() may modify that memory with its ClearPageWaiters()). > > > > Then on crashing a second time, realized there's a stronger reason against > > that approach. If my testing just occasionally crashes on that check, > > when the page is reused for part of a compound page, wouldn't it be much > > more common for the page to get reused as an order-0 page before reaching > > wake_up_page()? And on rare occasions, might that reused page already be > > marked PageWriteback by its new user, and already be waited upon? What > > would that look like? > > > > It would look like BUG_ON(PageWriteback) after wait_on_page_writeback() > > in write_cache_pages() (though I have never seen that crash myself). > > I don't think this is it. write_cache_pages() holds a reference to the > page -- indeed, it holds the page lock! So this particular race cannot > cause the page to get recycled. I still have no good ideas what this > is :-( But does it really matter what write_cache_pages() does? I mean we start page writeback. I mean struct bio holds no reference to the page it writes. The only thing that prevents the page from being freed under bio's hands is PageWriteback bit. So when the bio is completing we do (e.g. in ext4_end_bio()), we usually walk all pages in a bio bio_for_each_segment_all() and for each page call end_page_writeback(), now once end_page_writeback() calls test_clear_page_writeback() which clears PageWriteback(), the page can get freed. And that can happen before the wake_up_page() call in end_page_writeback(). So a race will be like: CPU1CPU2 ext4_end_bio() ... end_page_writeback(page) test_clear_page_writeback(page) free page reallocate page for something else we can even dirty & start to writeback 'page' wake_up_page(page) and we have a "spurious" wake up on 'page'. Honza -- Jan Kara SUSE Labs, CR
[PATCH v12 00/10] mm: introduce memfd_secret system call to create "secret" memory areas
From: Mike Rapoport Hi, This is an implementation of "secret" mappings backed by a file descriptor. The file descriptor backing secret memory mappings is created using a dedicated memfd_secret system call The desired protection mode for the memory is configured using flags parameter of the system call. The mmap() of the file descriptor created with memfd_secret() will create a "secret" memory mapping. The pages in that mapping will be marked as not present in the direct map and will be present only in the page table of the owning mm. Although normally Linux userspace mappings are protected from other users, such secret mappings are useful for environments where a hostile tenant is trying to trick the kernel into giving them access to other tenants mappings. Additionally, in the future the secret mappings may be used as a mean to protect guest memory in a virtual machine host. For demonstration of secret memory usage we've created a userspace library https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloader.git that does two things: the first is act as a preloader for openssl to redirect all the OPENSSL_malloc calls to secret memory meaning any secret keys get automatically protected this way and the other thing it does is expose the API to the user who needs it. We anticipate that a lot of the use cases would be like the openssl one: many toolkits that deal with secret keys already have special handling for the memory to try to give them greater protection, so this would simply be pluggable into the toolkits without any need for user application modification. Hiding secret memory mappings behind an anonymous file allows (ab)use of the page cache for tracking pages allocated for the "secret" mappings as well as using address_space_operations for e.g. page migration callbacks. The anonymous file may be also used implicitly, like hugetlb files, to implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm ABIs in the future. To limit fragmentation of the direct map to splitting only PUD-size pages, I've added an amortizing cache of PMD-size pages to each file descriptor that is used as an allocation pool for the secret memory areas. As the memory allocated by secretmem becomes unmovable, we use CMA to back large page caches so that page allocator won't be surprised by failing attempt to migrate these pages. v12: * Add detection of whether set_direct_map has actual effect on arm64 and bail out of CMA allocation for secretmem and the memfd_secret() syscall if pages would not be removed from the direct map v11: https://lore.kernel.org/lkml/20201124092556.12009-1-r...@kernel.org * Drop support for uncached mappings v10: https://lore.kernel.org/lkml/20201123095432.5860-1-r...@kernel.org * Drop changes to arm64 compatibility layer * Add Roman's Ack for memcg accounting v9: https://lore.kernel.org/lkml/20201117162932.13649-1-r...@kernel.org * Fix build with and without CONFIG_MEMCG * Update memcg accounting to avoid copying memcg_data, per Roman comments * Fix issues in secretmem_fault(), thanks Matthew * Do not wire up syscall in arm64 compatibility layer v8: https://lore.kernel.org/lkml/20201110151444.20662-1-r...@kernel.org * Use CMA for all secretmem allocations as David suggested * Update memcg accounting after transtion to CMA * Prevent hibernation when there are active secretmem users * Add zeroing of the memory before releasing it back to cma/page allocator * Rebase on v5.10-rc2-mmotm-2020-11-07-21-40 Older history: v7: https://lore.kernel.org/lkml/20201026083752.13267-1-r...@kernel.org v6: https://lore.kernel.org/lkml/20200924132904.1391-1-r...@kernel.org v5: https://lore.kernel.org/lkml/20200916073539.3552-1-r...@kernel.org v4: https://lore.kernel.org/lkml/20200818141554.13945-1-r...@kernel.org v3: https://lore.kernel.org/lkml/20200804095035.18778-1-r...@kernel.org v2: https://lore.kernel.org/lkml/20200727162935.31714-1-r...@kernel.org v1: https://lore.kernel.org/lkml/20200720092435.17469-1-r...@kernel.org Mike Rapoport (10): mm: add definition of PMD_PAGE_ORDER mmap: make mlock_future_check() global set_memory: allow set_direct_map_*_noflush() for multiple pages set_memory: allow querying whether set_direct_map_*() is actually enabled mm: introduce memfd_secret system call to create "secret" memory areas secretmem: use PMD-size pages to amortize direct map fragmentation secretmem: add memcg accounting PM: hibernate: disable when there are active secretmem users arch, mm: wire up memfd_secret system call were relevant secretmem: test: add basic selftest for memfd_secret(2) arch/arm64/include/asm/Kbuild | 1 - arch/arm64/include/asm/cacheflush.h | 6 - arch/arm64/include/asm/set_memory.h | 17 + arch/arm64/include/uapi/asm/unistd.h | 1 + arch/arm64/kernel/machine_kexec.c | 1 + arch/arm64/mm/mmu.c | 6 +- arch/arm64/mm/pageattr.c | 23 +-
Re: [PATCH 1/9] regulator: Update DA9121 dt-bindings
On Fri, Nov 20, 2020 at 02:47:42PM +0100, Vincent Whitchurch wrote: > On Fri, Nov 20, 2020 at 01:14:50PM +0100, Adam Ward wrote: > > - buck1: > > -description: > > - Initial data for the Buck1 regulator. > > -$ref: "regulator.yaml#" > > + interrupt-parent: > > +maxItems: 1 > > +description: Specifies the reference to the interrupt controller. > > + > > + interrupts: > > +maxItems: 1 > > +description: IRQ line information. > > + > > + dlg,irq-polling-delay-passive: > > +maxItems: 1 > > +description: | > > + Specify the polling period, measured in milliseconds, between > > interrupt status > > + update checks. Range 1000-1 ms. > > + > > + regulators: > > type: object > > +$ref: regulator.yaml# > > +description: | > > + This node defines the settings for the BUCK. The content of the > > + sub-node is defined by the standard binding for regulators; see > > regulator.yaml. > > + The DA9121 regulator is bound using their names listed below > > + buck1 - BUCK1 > > + buck2 - BUCK2 //DA9122, DA9220, DA9131, DA9132 only > > This move to a sub-node means that older devicetrees won't work. I > assume that's fine since the driver is only in linux-next at the moment, > but perhaps it's worth mentioning this in the commit message? Actually, perhaps I'm missing something, but I don't quite see why this move to a sub-node is needed. There is some flexibility in the regulator framework for this as I noted earlier (https://lore.kernel.org/lkml/20201102154848.tm5nsydaukyd7...@axis.com/). For the case of an MFD it certainly makes sense to have a "regulators" sub-node but for these chips it seems rather redundant. Also, perhaps you could split this patch into logical pieces too as Mark has suggested for some of the other patches in this series?
[PATCH v12 03/10] set_memory: allow set_direct_map_*_noflush() for multiple pages
From: Mike Rapoport
The underlying implementations of set_direct_map_invalid_noflush() and
set_direct_map_default_noflush() allow updating multiple contiguous pages
at once.
Add numpages parameter to set_direct_map_*_noflush() to expose this ability
with these APIs.
Signed-off-by: Mike Rapoport
Acked-by: Catalin Marinas # arm64
---
arch/arm64/include/asm/cacheflush.h | 4 ++--
arch/arm64/mm/pageattr.c| 10 ++
arch/riscv/include/asm/set_memory.h | 4 ++--
arch/riscv/mm/pageattr.c| 8
arch/x86/include/asm/set_memory.h | 4 ++--
arch/x86/mm/pat/set_memory.c| 8
include/linux/set_memory.h | 4 ++--
kernel/power/snapshot.c | 4 ++--
mm/vmalloc.c| 5 +++--
9 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/include/asm/cacheflush.h
b/arch/arm64/include/asm/cacheflush.h
index 45217f21f1fe..d3598419a284 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -138,8 +138,8 @@ static __always_inline void __flush_icache_all(void)
int set_memory_valid(unsigned long addr, int numpages, int enable);
-int set_direct_map_invalid_noflush(struct page *page);
-int set_direct_map_default_noflush(struct page *page);
+int set_direct_map_invalid_noflush(struct page *page, int numpages);
+int set_direct_map_default_noflush(struct page *page, int numpages);
bool kernel_page_present(struct page *page);
#include
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 92eccaf595c8..b53ef37bf95a 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -148,34 +148,36 @@ int set_memory_valid(unsigned long addr, int numpages,
int enable)
__pgprot(PTE_VALID));
}
-int set_direct_map_invalid_noflush(struct page *page)
+int set_direct_map_invalid_noflush(struct page *page, int numpages)
{
struct page_change_data data = {
.set_mask = __pgprot(0),
.clear_mask = __pgprot(PTE_VALID),
};
+ unsigned long size = PAGE_SIZE * numpages;
if (!debug_pagealloc_enabled() && !rodata_full)
return 0;
return apply_to_page_range(&init_mm,
(unsigned long)page_address(page),
- PAGE_SIZE, change_page_range, &data);
+ size, change_page_range, &data);
}
-int set_direct_map_default_noflush(struct page *page)
+int set_direct_map_default_noflush(struct page *page, int numpages)
{
struct page_change_data data = {
.set_mask = __pgprot(PTE_VALID | PTE_WRITE),
.clear_mask = __pgprot(PTE_RDONLY),
};
+ unsigned long size = PAGE_SIZE * numpages;
if (!debug_pagealloc_enabled() && !rodata_full)
return 0;
return apply_to_page_range(&init_mm,
(unsigned long)page_address(page),
- PAGE_SIZE, change_page_range, &data);
+ size, change_page_range, &data);
}
#ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/arch/riscv/include/asm/set_memory.h
b/arch/riscv/include/asm/set_memory.h
index d690b08dff2a..92b9bb26bf5e 100644
--- a/arch/riscv/include/asm/set_memory.h
+++ b/arch/riscv/include/asm/set_memory.h
@@ -22,8 +22,8 @@ static inline int set_memory_x(unsigned long addr, int
numpages) { return 0; }
static inline int set_memory_nx(unsigned long addr, int numpages) { return 0; }
#endif
-int set_direct_map_invalid_noflush(struct page *page);
-int set_direct_map_default_noflush(struct page *page);
+int set_direct_map_invalid_noflush(struct page *page, int numpages);
+int set_direct_map_default_noflush(struct page *page, int numpages);
bool kernel_page_present(struct page *page);
#endif /* __ASSEMBLY__ */
diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
index 87ba5a68bbb8..0454f2d052c4 100644
--- a/arch/riscv/mm/pageattr.c
+++ b/arch/riscv/mm/pageattr.c
@@ -150,11 +150,11 @@ int set_memory_nx(unsigned long addr, int numpages)
return __set_memory(addr, numpages, __pgprot(0), __pgprot(_PAGE_EXEC));
}
-int set_direct_map_invalid_noflush(struct page *page)
+int set_direct_map_invalid_noflush(struct page *page, int numpages)
{
int ret;
unsigned long start = (unsigned long)page_address(page);
- unsigned long end = start + PAGE_SIZE;
+ unsigned long end = start + PAGE_SIZE * numpages;
struct pageattr_masks masks = {
.set_mask = __pgprot(0),
.clear_mask = __pgprot(_PAGE_PRESENT)
@@ -167,11 +167,11 @@ int set_direct_map_invalid_noflush(struct page *page)
return ret;
}
-int set_direct_map_default_noflush(struct page *page)
+int set_direct_map_default_noflush(struct page *page, int numpages)
{
int ret;
unsigned long start = (un
[PATCH v12 01/10] mm: add definition of PMD_PAGE_ORDER
From: Mike Rapoport
The definition of PMD_PAGE_ORDER denoting the number of base pages in the
second-level leaf page is already used by DAX and maybe handy in other
cases as well.
Several architectures already have definition of PMD_ORDER as the size of
second level page table, so to avoid conflict with these definitions use
PMD_PAGE_ORDER name and update DAX respectively.
Signed-off-by: Mike Rapoport
Reviewed-by: David Hildenbrand
---
fs/dax.c| 11 ---
include/linux/pgtable.h | 3 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 26d5dcd2d69e..0f109eb16196 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -49,9 +49,6 @@ static inline unsigned int pe_order(enum page_entry_size
pe_size)
#define PG_PMD_COLOUR ((PMD_SIZE >> PAGE_SHIFT) - 1)
#define PG_PMD_NR (PMD_SIZE >> PAGE_SHIFT)
-/* The order of a PMD entry */
-#define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
-
static wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];
static int __init init_dax_wait_table(void)
@@ -98,7 +95,7 @@ static bool dax_is_locked(void *entry)
static unsigned int dax_entry_order(void *entry)
{
if (xa_to_value(entry) & DAX_PMD)
- return PMD_ORDER;
+ return PMD_PAGE_ORDER;
return 0;
}
@@ -1470,7 +1467,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct vm_fault
*vmf, pfn_t *pfnp,
{
struct vm_area_struct *vma = vmf->vma;
struct address_space *mapping = vma->vm_file->f_mapping;
- XA_STATE_ORDER(xas, &mapping->i_pages, vmf->pgoff, PMD_ORDER);
+ XA_STATE_ORDER(xas, &mapping->i_pages, vmf->pgoff, PMD_PAGE_ORDER);
unsigned long pmd_addr = vmf->address & PMD_MASK;
bool write = vmf->flags & FAULT_FLAG_WRITE;
bool sync;
@@ -1529,7 +1526,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct vm_fault
*vmf, pfn_t *pfnp,
* entry is already in the array, for instance), it will return
* VM_FAULT_FALLBACK.
*/
- entry = grab_mapping_entry(&xas, mapping, PMD_ORDER);
+ entry = grab_mapping_entry(&xas, mapping, PMD_PAGE_ORDER);
if (xa_is_internal(entry)) {
result = xa_to_internal(entry);
goto fallback;
@@ -1695,7 +1692,7 @@ dax_insert_pfn_mkwrite(struct vm_fault *vmf, pfn_t pfn,
unsigned int order)
if (order == 0)
ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn);
#ifdef CONFIG_FS_DAX_PMD
- else if (order == PMD_ORDER)
+ else if (order == PMD_PAGE_ORDER)
ret = vmf_insert_pfn_pmd(vmf, pfn, FAULT_FLAG_WRITE);
#endif
else
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 71125a4676c4..7f718b8dc789 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -28,6 +28,9 @@
#define USER_PGTABLES_CEILING 0UL
#endif
+/* Number of base pages in a second level leaf page */
+#define PMD_PAGE_ORDER (PMD_SHIFT - PAGE_SHIFT)
+
/*
* A page table page can be thought of an array like this: pXd_t[PTRS_PER_PxD]
*
--
2.28.0
[PATCH v12 05/10] mm: introduce memfd_secret system call to create "secret" memory areas
From: Mike Rapoport
Introduce "memfd_secret" system call with the ability to create memory
areas visible only in the context of the owning process and not mapped not
only to other processes but in the kernel page tables as well.
The user will create a file descriptor using the memfd_secret() system
call. The memory areas created by mmap() calls from this file descriptor
will be unmapped from the kernel direct map and they will be only mapped in
the page table of the owning mm.
The secret memory remains accessible in the process context using uaccess
primitives, but it is not accessible using direct/linear map addresses.
Functions in the follow_page()/get_user_page() family will refuse to return
a page that belongs to the secret memory area.
A page that was a part of the secret memory area is cleared when it is
freed.
The following example demonstrates creation of a secret mapping (error
handling is omitted):
fd = memfd_secret(0);
ftruncate(fd, MAP_SIZE);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Signed-off-by: Mike Rapoport
Acked-by: Hagen Paul Pfeifer
---
arch/x86/Kconfig | 2 +-
include/linux/secretmem.h | 24
include/uapi/linux/magic.h | 1 +
kernel/sys_ni.c| 2 +
mm/Kconfig | 3 +
mm/Makefile| 1 +
mm/gup.c | 10 ++
mm/secretmem.c | 273 +
8 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 include/linux/secretmem.h
create mode 100644 mm/secretmem.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 34d5fb82f674..7d781fea79c2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -41,7 +41,7 @@ config FORCE_DYNAMIC_FTRACE
in order to test the non static function tracing in the
generic code, as other architectures still use it. But we
only need to keep it around for x86_64. No need to keep it
-for x86_32. For x86_32, force DYNAMIC_FTRACE.
+for x86_32. For x86_32, force DYNAMIC_FTRACE.
#
# Arch settings
#
diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
new file mode 100644
index ..70e7db9f94fe
--- /dev/null
+++ b/include/linux/secretmem.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _LINUX_SECRETMEM_H
+#define _LINUX_SECRETMEM_H
+
+#ifdef CONFIG_SECRETMEM
+
+bool vma_is_secretmem(struct vm_area_struct *vma);
+bool page_is_secretmem(struct page *page);
+
+#else
+
+static inline bool vma_is_secretmem(struct vm_area_struct *vma)
+{
+ return false;
+}
+
+static inline bool page_is_secretmem(struct page *page)
+{
+ return false;
+}
+
+#endif /* CONFIG_SECRETMEM */
+
+#endif /* _LINUX_SECRETMEM_H */
diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index f3956fc11de6..35687dcb1a42 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -97,5 +97,6 @@
#define DEVMEM_MAGIC 0x454d444d /* "DMEM" */
#define Z3FOLD_MAGIC 0x33
#define PPC_CMM_MAGIC 0xc7571590
+#define SECRETMEM_MAGIC0x5345434d /* "SECM" */
#endif /* __LINUX_MAGIC_H__ */
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 2dd6cbb8cabc..805fd7a668be 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -353,6 +353,8 @@ COND_SYSCALL(pkey_mprotect);
COND_SYSCALL(pkey_alloc);
COND_SYSCALL(pkey_free);
+/* memfd_secret */
+COND_SYSCALL(memfd_secret);
/*
* Architecture specific weak syscall entries.
diff --git a/mm/Kconfig b/mm/Kconfig
index c89c5444924b..d8d170fa5210 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -884,4 +884,7 @@ config ARCH_HAS_HUGEPD
config MAPPING_DIRTY_HELPERS
bool
+config SECRETMEM
+ def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
+
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index 6eeb4b29efb8..dfda14c48a75 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -121,3 +121,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
+obj-$(CONFIG_SECRETMEM) += secretmem.o
diff --git a/mm/gup.c b/mm/gup.c
index 5ec98de1e5de..71164fa83114 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -793,6 +794,9 @@ struct page *follow_page(struct vm_area_struct *vma,
unsigned long address,
struct follow_page_context ctx = { NULL };
struct page *page;
+ if (vma_is_secretmem(vma))
+ return NULL;
+
page = follow_page_mask(vma, address, foll_flags, &ctx);
if (ctx.pgmap)
put_dev_pagemap(ctx.pgmap);
@@ -923,6 +927,9 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
if (gup_flags & FOLL_ANON && !vma_is_anonymous(vma))
return -EFAULT;
+ if (v
[PATCH v12 04/10] set_memory: allow querying whether set_direct_map_*() is actually enabled
From: Mike Rapoport
On arm64, set_direct_map_*() functions may return 0 without actually
changing the linear map. This behaviour can be controlled using kernel
parameters, so we need a way to determine at runtime whether calls to
set_direct_map_invalid_noflush() and set_direct_map_default_noflush() have
any effect.
Extend set_memory API with can_set_direct_map() function that allows
checking if calling set_direct_map_*() will actually change the page table,
replace several occurrences of open coded checks in arm64 with the new
function and provide a generic stub for architectures that always modify
page tables upon calls to set_direct_map APIs.
Signed-off-by: Mike Rapoport
---
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/cacheflush.h | 6 --
arch/arm64/include/asm/set_memory.h | 17 +
arch/arm64/kernel/machine_kexec.c | 1 +
arch/arm64/mm/mmu.c | 6 +++---
arch/arm64/mm/pageattr.c| 13 +
include/linux/set_memory.h | 12
7 files changed, 42 insertions(+), 14 deletions(-)
create mode 100644 arch/arm64/include/asm/set_memory.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index ff9cbb631212..4306136ef329 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -4,5 +4,4 @@ generic-y += local64.h
generic-y += mcs_spinlock.h
generic-y += qrwlock.h
generic-y += qspinlock.h
-generic-y += set_memory.h
generic-y += user.h
diff --git a/arch/arm64/include/asm/cacheflush.h
b/arch/arm64/include/asm/cacheflush.h
index d3598419a284..b1bdf83a73db 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -136,12 +136,6 @@ static __always_inline void __flush_icache_all(void)
dsb(ish);
}
-int set_memory_valid(unsigned long addr, int numpages, int enable);
-
-int set_direct_map_invalid_noflush(struct page *page, int numpages);
-int set_direct_map_default_noflush(struct page *page, int numpages);
-bool kernel_page_present(struct page *page);
-
#include
#endif /* __ASM_CACHEFLUSH_H */
diff --git a/arch/arm64/include/asm/set_memory.h
b/arch/arm64/include/asm/set_memory.h
new file mode 100644
index ..ecb6b0f449ab
--- /dev/null
+++ b/arch/arm64/include/asm/set_memory.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_ARM64_SET_MEMORY_H
+#define _ASM_ARM64_SET_MEMORY_H
+
+#include
+
+bool can_set_direct_map(void);
+#define can_set_direct_map can_set_direct_map
+
+int set_memory_valid(unsigned long addr, int numpages, int enable);
+
+int set_direct_map_invalid_noflush(struct page *page, int numpages);
+int set_direct_map_default_noflush(struct page *page, int numpages);
+bool kernel_page_present(struct page *page);
+
+#endif /* _ASM_ARM64_SET_MEMORY_H */
diff --git a/arch/arm64/kernel/machine_kexec.c
b/arch/arm64/kernel/machine_kexec.c
index a0b144cfaea7..0cbc50c4fa5a 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 86be6d1a78ab..aa5ec08cb902 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -477,7 +478,7 @@ static void __init map_mem(pgd_t *pgdp)
int flags = 0;
u64 i;
- if (rodata_full || debug_pagealloc_enabled())
+ if (can_set_direct_map())
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
/*
@@ -1453,8 +1454,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
* KFENCE requires linear map to be mapped at page granularity, so that
* it is possible to protect/unprotect single pages in the KFENCE pool.
*/
- if (rodata_full || debug_pagealloc_enabled() ||
- IS_ENABLED(CONFIG_KFENCE))
+ if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE))
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index b53ef37bf95a..d505172265b0 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -19,6 +19,11 @@ struct page_change_data {
bool rodata_full __ro_after_init =
IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED);
+bool can_set_direct_map(void)
+{
+ return rodata_full || debug_pagealloc_enabled();
+}
+
static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
{
struct page_change_data *cdata = data;
@@ -156,7 +161,7 @@ int set_direct_map_invalid_noflush(struct page *page, int
numpages)
};
unsigned long size = PAGE_SIZE * numpages;
- if (!debug_pagealloc_enabled() && !rodata_full)
+ if (!can_set_direct_map())
return 0;
return apply_to_page_rang
[PATCH v12 02/10] mmap: make mlock_future_check() global
From: Mike Rapoport
It will be used by the upcoming secret memory implementation.
Signed-off-by: Mike Rapoport
---
mm/internal.h | 3 +++
mm/mmap.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index c43ccdddb0f6..ae146a260b14 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -348,6 +348,9 @@ static inline void munlock_vma_pages_all(struct
vm_area_struct *vma)
extern void mlock_vma_page(struct page *page);
extern unsigned int munlock_vma_page(struct page *page);
+extern int mlock_future_check(struct mm_struct *mm, unsigned long flags,
+ unsigned long len);
+
/*
* Clear the page's PageMlocked(). This can be useful in a situation where
* we want to unconditionally remove a page from the pagecache -- e.g.,
diff --git a/mm/mmap.c b/mm/mmap.c
index 61f72b09d990..c481f088bd50 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1348,9 +1348,8 @@ static inline unsigned long round_hint_to_min(unsigned
long hint)
return hint;
}
-static inline int mlock_future_check(struct mm_struct *mm,
-unsigned long flags,
-unsigned long len)
+int mlock_future_check(struct mm_struct *mm, unsigned long flags,
+ unsigned long len)
{
unsigned long locked, lock_limit;
--
2.28.0
[PATCH v12 08/10] PM: hibernate: disable when there are active secretmem users
From: Mike Rapoport
It is unsafe to allow saving of secretmem areas to the hibernation snapshot
as they would be visible after the resume and this essentially will defeat
the purpose of secret memory mappings.
Prevent hibernation whenever there are active secret memory users.
Signed-off-by: Mike Rapoport
---
include/linux/secretmem.h | 6 ++
kernel/power/hibernate.c | 5 -
mm/secretmem.c| 15 +++
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
index 70e7db9f94fe..907a6734059c 100644
--- a/include/linux/secretmem.h
+++ b/include/linux/secretmem.h
@@ -6,6 +6,7 @@
bool vma_is_secretmem(struct vm_area_struct *vma);
bool page_is_secretmem(struct page *page);
+bool secretmem_active(void);
#else
@@ -19,6 +20,11 @@ static inline bool page_is_secretmem(struct page *page)
return false;
}
+static inline bool secretmem_active(void)
+{
+ return false;
+}
+
#endif /* CONFIG_SECRETMEM */
#endif /* _LINUX_SECRETMEM_H */
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index da0b41914177..559acef3fddb 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include "power.h"
@@ -81,7 +82,9 @@ void hibernate_release(void)
bool hibernation_available(void)
{
- return nohibernate == 0 && !security_locked_down(LOCKDOWN_HIBERNATION);
+ return nohibernate == 0 &&
+ !security_locked_down(LOCKDOWN_HIBERNATION) &&
+ !secretmem_active();
}
/**
diff --git a/mm/secretmem.c b/mm/secretmem.c
index eb6628390444..f7398eb810c5 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -45,6 +45,13 @@ struct secretmem_ctx {
static struct cma *secretmem_cma;
+static atomic_t secretmem_users;
+
+bool secretmem_active(void)
+{
+ return !!atomic_read(&secretmem_users);
+}
+
static int secretmem_account_pages(struct page *page, gfp_t gfp, int order)
{
int err;
@@ -179,6 +186,12 @@ static const struct vm_operations_struct secretmem_vm_ops
= {
.fault = secretmem_fault,
};
+static int secretmem_release(struct inode *inode, struct file *file)
+{
+ atomic_dec(&secretmem_users);
+ return 0;
+}
+
static int secretmem_mmap(struct file *file, struct vm_area_struct *vma)
{
unsigned long len = vma->vm_end - vma->vm_start;
@@ -201,6 +214,7 @@ bool vma_is_secretmem(struct vm_area_struct *vma)
}
static const struct file_operations secretmem_fops = {
+ .release= secretmem_release,
.mmap = secretmem_mmap,
};
@@ -318,6 +332,7 @@ SYSCALL_DEFINE1(memfd_secret, unsigned long, flags)
file->f_flags |= O_LARGEFILE;
fd_install(fd, file);
+ atomic_inc(&secretmem_users);
return fd;
err_put_fd:
--
2.28.0
[PATCH v12 09/10] arch, mm: wire up memfd_secret system call were relevant
From: Mike Rapoport Wire up memfd_secret system call on architectures that define ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86. Signed-off-by: Mike Rapoport Acked-by: Palmer Dabbelt Acked-by: Arnd Bergmann --- arch/arm64/include/uapi/asm/unistd.h | 1 + arch/riscv/include/asm/unistd.h| 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 6 +- mm/secretmem.c | 3 +++ scripts/checksyscalls.sh | 4 8 files changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h index f83a70e07df8..ce2ee8f1e361 100644 --- a/arch/arm64/include/uapi/asm/unistd.h +++ b/arch/arm64/include/uapi/asm/unistd.h @@ -20,5 +20,6 @@ #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS #define __ARCH_WANT_SYS_CLONE3 +#define __ARCH_WANT_MEMFD_SECRET #include diff --git a/arch/riscv/include/asm/unistd.h b/arch/riscv/include/asm/unistd.h index 977ee6181dab..6c316093a1e5 100644 --- a/arch/riscv/include/asm/unistd.h +++ b/arch/riscv/include/asm/unistd.h @@ -9,6 +9,7 @@ */ #define __ARCH_WANT_SYS_CLONE +#define __ARCH_WANT_MEMFD_SECRET #include diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index c52ab1c4a755..109e6681b8fa 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -446,3 +446,4 @@ 439i386faccessat2 sys_faccessat2 440i386process_madvise sys_process_madvise 441i386watch_mount sys_watch_mount +442i386memfd_secretsys_memfd_secret diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index f3270a9ef467..742cf17d7725 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -363,6 +363,7 @@ 439common faccessat2 sys_faccessat2 440common process_madvise sys_process_madvise 441common watch_mount sys_watch_mount +442common memfd_secretsys_memfd_secret # # Due to a historical design error, certain syscalls are numbered differently diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 6d55324363ab..f9d93fbf9b69 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -1010,6 +1010,7 @@ asmlinkage long sys_pidfd_send_signal(int pidfd, int sig, asmlinkage long sys_pidfd_getfd(int pidfd, int fd, unsigned int flags); asmlinkage long sys_watch_mount(int dfd, const char __user *path, unsigned int at_flags, int watch_fd, int watch_id); +asmlinkage long sys_memfd_secret(unsigned long flags); /* * Architecture-specific system calls diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 5df46517260e..51151888f330 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -861,9 +861,13 @@ __SYSCALL(__NR_faccessat2, sys_faccessat2) __SYSCALL(__NR_process_madvise, sys_process_madvise) #define __NR_watch_mount 441 __SYSCALL(__NR_watch_mount, sys_watch_mount) +#ifdef __ARCH_WANT_MEMFD_SECRET +#define __NR_memfd_secret 442 +__SYSCALL(__NR_memfd_secret, sys_memfd_secret) +#endif #undef __NR_syscalls -#define __NR_syscalls 442 +#define __NR_syscalls 443 /* * 32 bit systems traditionally used different diff --git a/mm/secretmem.c b/mm/secretmem.c index f7398eb810c5..6ee378852482 100644 --- a/mm/secretmem.c +++ b/mm/secretmem.c @@ -415,6 +415,9 @@ static int __init secretmem_setup(char *str) unsigned long reserved_size; int err; + if (!can_set_direct_map()) + return 0; + reserved_size = memparse(str, NULL); if (!reserved_size) return 0; diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh index a18b47695f55..b7609958ee36 100755 --- a/scripts/checksyscalls.sh +++ b/scripts/checksyscalls.sh @@ -40,6 +40,10 @@ cat << EOF #define __IGNORE_setrlimit /* setrlimit */ #endif +#ifndef __ARCH_WANT_MEMFD_SECRET +#define __IGNORE_memfd_secret +#endif + /* Missing flags argument */ #define __IGNORE_renameat /* renameat2 */ -- 2.28.0
[PATCH v12 06/10] secretmem: use PMD-size pages to amortize direct map fragmentation
From: Mike Rapoport
Removing a PAGE_SIZE page from the direct map every time such page is
allocated for a secret memory mapping will cause severe fragmentation of
the direct map. This fragmentation can be reduced by using PMD-size pages
as a pool for small pages for secret memory mappings.
Add a gen_pool per secretmem inode and lazily populate this pool with
PMD-size pages.
As pages allocated by secretmem become unmovable, use CMA to back large
page caches so that page allocator won't be surprised by failing attempt to
migrate these pages.
The CMA area used by secretmem is controlled by the "secretmem=" kernel
parameter. This allows explicit control over the memory available for
secretmem and provides upper hard limit for secretmem consumption.
Signed-off-by: Mike Rapoport
---
mm/Kconfig | 2 +
mm/secretmem.c | 152 ++---
2 files changed, 135 insertions(+), 19 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index d8d170fa5210..e0e789398421 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -886,5 +886,7 @@ config MAPPING_DIRTY_HELPERS
config SECRETMEM
def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
+ select GENERIC_ALLOCATOR
+ select CMA
endmenu
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 781aaaca8c70..52a900a135a5 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -7,12 +7,15 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -35,25 +38,80 @@
#define SECRETMEM_FLAGS_MASK SECRETMEM_MODE_MASK
struct secretmem_ctx {
+ struct gen_pool *pool;
unsigned int mode;
};
-static struct page *secretmem_alloc_page(gfp_t gfp)
+static struct cma *secretmem_cma;
+
+static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
{
+ unsigned long nr_pages = (1 << PMD_PAGE_ORDER);
+ struct gen_pool *pool = ctx->pool;
+ unsigned long addr;
+ struct page *page;
+ int err;
+
+ page = cma_alloc(secretmem_cma, nr_pages, PMD_SIZE, gfp & __GFP_NOWARN);
+ if (!page)
+ return -ENOMEM;
+
+ err = set_direct_map_invalid_noflush(page, nr_pages);
+ if (err)
+ goto err_cma_release;
+
+ addr = (unsigned long)page_address(page);
+ err = gen_pool_add(pool, addr, PMD_SIZE, NUMA_NO_NODE);
+ if (err)
+ goto err_set_direct_map;
+
+ flush_tlb_kernel_range(addr, addr + PMD_SIZE);
+
+ return 0;
+
+err_set_direct_map:
/*
-* FIXME: use a cache of large pages to reduce the direct map
-* fragmentation
+* If a split of PUD-size page was required, it already happened
+* when we marked the pages invalid which guarantees that this call
+* won't fail
*/
- return alloc_page(gfp);
+ set_direct_map_default_noflush(page, nr_pages);
+err_cma_release:
+ cma_release(secretmem_cma, page, nr_pages);
+ return err;
+}
+
+static struct page *secretmem_alloc_page(struct secretmem_ctx *ctx,
+gfp_t gfp)
+{
+ struct gen_pool *pool = ctx->pool;
+ unsigned long addr;
+ struct page *page;
+ int err;
+
+ if (gen_pool_avail(pool) < PAGE_SIZE) {
+ err = secretmem_pool_increase(ctx, gfp);
+ if (err)
+ return NULL;
+ }
+
+ addr = gen_pool_alloc(pool, PAGE_SIZE);
+ if (!addr)
+ return NULL;
+
+ page = virt_to_page(addr);
+ get_page(page);
+
+ return page;
}
static vm_fault_t secretmem_fault(struct vm_fault *vmf)
{
+ struct secretmem_ctx *ctx = vmf->vma->vm_file->private_data;
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
struct inode *inode = file_inode(vmf->vma->vm_file);
pgoff_t offset = vmf->pgoff;
vm_fault_t ret = 0;
- unsigned long addr;
struct page *page;
int err;
@@ -62,8 +120,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
page = find_get_page(mapping, offset);
if (!page) {
-
- page = secretmem_alloc_page(vmf->gfp_mask);
+ page = secretmem_alloc_page(ctx, vmf->gfp_mask);
if (!page)
return vmf_error(-ENOMEM);
@@ -71,14 +128,8 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
if (unlikely(err))
goto err_put_page;
- err = set_direct_map_invalid_noflush(page, 1);
- if (err)
- goto err_del_page_cache;
-
- addr = (unsigned long)page_address(page);
- flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
-
__SetPageUptodate(page);
+ set_page_private(page, (unsigned long)ctx);
ret = VM_FAULT_LOCKED;
}
@@ -86,8 +137,6 @@ static vm_f
[PATCH v12 10/10] secretmem: test: add basic selftest for memfd_secret(2)
From: Mike Rapoport
The test verifies that file descriptor created with memfd_secret does
not allow read/write operations, that secret memory mappings respect
RLIMIT_MEMLOCK and that remote accesses with process_vm_read() and
ptrace() to the secret memory fail.
Signed-off-by: Mike Rapoport
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 3 +-
tools/testing/selftests/vm/memfd_secret.c | 298 ++
tools/testing/selftests/vm/run_vmtests| 17 ++
4 files changed, 318 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/vm/memfd_secret.c
diff --git a/tools/testing/selftests/vm/.gitignore
b/tools/testing/selftests/vm/.gitignore
index 9a35c3f6a557..c8deddc81e7a 100644
--- a/tools/testing/selftests/vm/.gitignore
+++ b/tools/testing/selftests/vm/.gitignore
@@ -21,4 +21,5 @@ va_128TBswitch
map_fixed_noreplace
write_to_hugetlbfs
hmm-tests
+memfd_secret
local_config.*
diff --git a/tools/testing/selftests/vm/Makefile
b/tools/testing/selftests/vm/Makefile
index 62fb15f286ee..9ab98946fbf2 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -34,6 +34,7 @@ TEST_GEN_FILES += khugepaged
TEST_GEN_FILES += map_fixed_noreplace
TEST_GEN_FILES += map_hugetlb
TEST_GEN_FILES += map_populate
+TEST_GEN_FILES += memfd_secret
TEST_GEN_FILES += mlock-random-test
TEST_GEN_FILES += mlock2-tests
TEST_GEN_FILES += mremap_dontunmap
@@ -129,7 +130,7 @@ warn_32bit_failure:
endif
endif
-$(OUTPUT)/mlock-random-test: LDLIBS += -lcap
+$(OUTPUT)/mlock-random-test $(OUTPUT)/memfd_secret: LDLIBS += -lcap
$(OUTPUT)/gup_test: ../../../../mm/gup_test.h
diff --git a/tools/testing/selftests/vm/memfd_secret.c
b/tools/testing/selftests/vm/memfd_secret.c
new file mode 100644
index ..79578dfd13e6
--- /dev/null
+++ b/tools/testing/selftests/vm/memfd_secret.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright IBM Corporation, 2020
+ *
+ * Author: Mike Rapoport
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "../kselftest.h"
+
+#define fail(fmt, ...) ksft_test_result_fail(fmt, ##__VA_ARGS__)
+#define pass(fmt, ...) ksft_test_result_pass(fmt, ##__VA_ARGS__)
+#define skip(fmt, ...) ksft_test_result_skip(fmt, ##__VA_ARGS__)
+
+#ifdef __NR_memfd_secret
+
+#include
+
+#define PATTERN0x55
+
+static const int prot = PROT_READ | PROT_WRITE;
+static const int mode = MAP_SHARED;
+
+static unsigned long page_size;
+static unsigned long mlock_limit_cur;
+static unsigned long mlock_limit_max;
+
+static int memfd_secret(unsigned long flags)
+{
+ return syscall(__NR_memfd_secret, flags);
+}
+
+static void test_file_apis(int fd)
+{
+ char buf[64];
+
+ if ((read(fd, buf, sizeof(buf)) >= 0) ||
+ (write(fd, buf, sizeof(buf)) >= 0) ||
+ (pread(fd, buf, sizeof(buf), 0) >= 0) ||
+ (pwrite(fd, buf, sizeof(buf), 0) >= 0))
+ fail("unexpected file IO\n");
+ else
+ pass("file IO is blocked as expected\n");
+}
+
+static void test_mlock_limit(int fd)
+{
+ size_t len;
+ char *mem;
+
+ len = mlock_limit_cur;
+ mem = mmap(NULL, len, prot, mode, fd, 0);
+ if (mem == MAP_FAILED) {
+ fail("unable to mmap secret memory\n");
+ return;
+ }
+ munmap(mem, len);
+
+ len = mlock_limit_max * 2;
+ mem = mmap(NULL, len, prot, mode, fd, 0);
+ if (mem != MAP_FAILED) {
+ fail("unexpected mlock limit violation\n");
+ munmap(mem, len);
+ return;
+ }
+
+ pass("mlock limit is respected\n");
+}
+
+static void try_process_vm_read(int fd, int pipefd[2])
+{
+ struct iovec liov, riov;
+ char buf[64];
+ char *mem;
+
+ if (read(pipefd[0], &mem, sizeof(mem)) < 0) {
+ fail("pipe write: %s\n", strerror(errno));
+ exit(KSFT_FAIL);
+ }
+
+ liov.iov_len = riov.iov_len = sizeof(buf);
+ liov.iov_base = buf;
+ riov.iov_base = mem;
+
+ if (process_vm_readv(getppid(), &liov, 1, &riov, 1, 0) < 0) {
+ if (errno == ENOSYS)
+ exit(KSFT_SKIP);
+ exit(KSFT_PASS);
+ }
+
+ exit(KSFT_FAIL);
+}
+
+static void try_ptrace(int fd, int pipefd[2])
+{
+ pid_t ppid = getppid();
+ int status;
+ char *mem;
+ long ret;
+
+ if (read(pipefd[0], &mem, sizeof(mem)) < 0) {
+ perror("pipe write");
+ exit(KSFT_FAIL);
+ }
+
+ ret = ptrace(PTRACE_ATTACH, ppid, 0, 0);
+ if (ret) {
+ perror("ptrace_attach");
+ exit(KSFT_FAIL);
+ }
+
+ ret = waitpid(ppid, &status, WUNTRACED);
+ if ((ret != ppid) || !(WIFSTOPPED(status))) {
+ fpr
Re: [PATCH] fpga: dfl: add missing platform_device_put in build_info_create_dev
Hi Qinglang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.10-rc5 next-20201124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Qinglang-Miao/fpga-dfl-add-missing-platform_device_put-in-build_info_create_dev/20201125-145159
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
127c501a03d5db8b833e953728d3bcf53c8832a9
config: arc-randconfig-m031-20201125 (attached as .config)
compiler: arc-elf-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://github.com/0day-ci/linux/commit/86dbfca89da921d0c3c9682ea35cdb3b2e40e6be
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Qinglang-Miao/fpga-dfl-add-missing-platform_device_put-in-build_info_create_dev/20201125-145159
git checkout 86dbfca89da921d0c3c9682ea35cdb3b2e40e6be
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/fpga/dfl.c: In function 'build_info_create_dev':
>> drivers/fpga/dfl.c:880:2: warning: ISO C90 forbids mixed declarations and
>> code [-Wdeclaration-after-statement]
880 | int tmp_id = dfl_id_alloc(type, &fdev->dev);
| ^~~
vim +880 drivers/fpga/dfl.c
857
858 static int
859 build_info_create_dev(struct build_feature_devs_info *binfo,
860enum dfl_id_type type)
861 {
862 struct platform_device *fdev;
863
864 if (type >= DFL_ID_MAX)
865 return -EINVAL;
866
867 /*
868 * we use -ENODEV as the initialization indicator which
indicates
869 * whether the id need to be reclaimed
870 */
871 fdev = platform_device_alloc(dfl_devs[type].name, -ENODEV);
872 if (!fdev)
873 return -ENOMEM;
874
875 binfo->feature_dev = fdev;
876 binfo->feature_num = 0;
877
878 INIT_LIST_HEAD(&binfo->sub_features);
879
> 880 int tmp_id = dfl_id_alloc(type, &fdev->dev);
881 if (tmp_id < 0) {
882 platform_device_put(fdev);
883 return tmp_id;
884 }
885
886 fdev->id = tmp_id;
887 fdev->dev.parent = &binfo->cdev->region->dev;
888 fdev->dev.devt = dfl_get_devt(dfl_devs[type].devt_type,
fdev->id);
889
890 return 0;
891 }
892
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v12 07/10] secretmem: add memcg accounting
From: Mike Rapoport
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
Acked-by: Roman Gushchin
---
mm/filemap.c | 3 ++-
mm/secretmem.c | 36 +++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 249cf489f5df..cf7f1dc9f4b8 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "internal.h"
#define CREATE_TRACE_POINTS
@@ -844,7 +845,7 @@ static noinline int __add_to_page_cache_locked(struct page
*page,
page->mapping = mapping;
page->index = offset;
- if (!huge) {
+ if (!huge && !page_is_secretmem(page)) {
error = mem_cgroup_charge(page, current->mm, gfp);
if (error)
goto error;
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 52a900a135a5..eb6628390444 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,32 @@ struct secretmem_ctx {
static struct cma *secretmem_cma;
+static int secretmem_account_pages(struct page *page, gfp_t gfp, int order)
+{
+ int err;
+
+ err = memcg_kmem_charge_page(page, gfp, order);
+ if (err)
+ return err;
+
+ /*
+* seceremem caches are unreclaimable kernel allocations, so treat
+* them as unreclaimable slab memory for VM statistics purposes
+*/
+ mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
+ PAGE_SIZE << order);
+
+ return 0;
+}
+
+static void secretmem_unaccount_pages(struct page *page, int order)
+{
+
+ mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
+ -PAGE_SIZE << order);
+ memcg_kmem_uncharge_page(page, order);
+}
+
static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
{
unsigned long nr_pages = (1 << PMD_PAGE_ORDER);
@@ -56,10 +83,14 @@ static int secretmem_pool_increase(struct secretmem_ctx
*ctx, gfp_t gfp)
if (!page)
return -ENOMEM;
- err = set_direct_map_invalid_noflush(page, nr_pages);
+ err = secretmem_account_pages(page, gfp, PMD_PAGE_ORDER);
if (err)
goto err_cma_release;
+ err = set_direct_map_invalid_noflush(page, nr_pages);
+ if (err)
+ goto err_memcg_uncharge;
+
addr = (unsigned long)page_address(page);
err = gen_pool_add(pool, addr, PMD_SIZE, NUMA_NO_NODE);
if (err)
@@ -76,6 +107,8 @@ static int secretmem_pool_increase(struct secretmem_ctx
*ctx, gfp_t gfp)
* won't fail
*/
set_direct_map_default_noflush(page, nr_pages);
+err_memcg_uncharge:
+ secretmem_unaccount_pages(page, PMD_PAGE_ORDER);
err_cma_release:
cma_release(secretmem_cma, page, nr_pages);
return err;
@@ -302,6 +335,7 @@ static void secretmem_cleanup_chunk(struct gen_pool *pool,
int i;
set_direct_map_default_noflush(page, nr_pages);
+ secretmem_unaccount_pages(page, PMD_PAGE_ORDER);
for (i = 0; i < nr_pages; i++)
clear_highpage(page + i);
--
2.28.0
Re: [PATCH] riscv: defconfig: k210: Disable CONFIG_VT
Hi Damien,
On Wed, Nov 25, 2020 at 10:02 AM Damien Le Moal wrote:
> On 2020/11/25 17:51, Geert Uytterhoeven wrote:
> > On Wed, Nov 25, 2020 at 7:14 AM Damien Le Moal
> > wrote:
> >> On 2020/11/25 3:57, Geert Uytterhoeven wrote:
> >>> There is no need to enable Virtual Terminal support in the Canaan
> >>> Kendryte K210 defconfigs, as no terminal devices are supported and
> >>> enabled. Hence disable CONFIG_VT, and remove the no longer needed
> >>> override for CONFIG_VGA_CONSOLE.
> >>>
> >>> This reduces kernel size by ca. 65 KiB.
> >>
> >> Indeed, nice saving. Just tested, and all is good.
> >
> > I used my old script[1] to check the impact of disabling config options.
> > I haven't done enough riscv kernel development yet to assess if I need
> > CONFIG_FRAME_POINTER or not.
>
> Disabling it significantly reduced code size for me. Since the series is more
> stable now, it is not really needed, so I disabled it in the defconfig.
>
> I was just fiddling with CONFIG_UNIX98_PTYS. Disabling it is OK with the
> simple
> busybox userspace (no telnet/xterm like app running). But it saves only about
> 1KB with my toolchain (gcc 9.3). So I left that one enabled. I am surprised
> that
> you see 16K size impact... How big is your image ?
>
> For me, it is 1.768 MB right now for the sdcard defconfig, with CONFIG_VT
> disabled and ext2 enabled.
It might depend on how you measure. "size" says 15 KiB impact for UNIX98
ptys, while bloat-o-meter reported less than 7 (my script uses "size").
I'm at 1.88 MiB, with ext4 and without frame pointers.
I also got rid of the EFI partition support, and a few I/O schedulers:
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_EFI_PARTITION is not set
+# CONFIG_MQ_IOSCHED_DEADLINE is not set
+# CONFIG_MQ_IOSCHED_KYBER is not set
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/2] SCMI performance protocol power scale interface
Hi Rafael, On 11/24/20 10:43 AM, Lukasz Luba wrote: Hi all, The Energy Model (EM) supports power values expressed in an abstract scale via new API. The SCMI performance protocol provides the information about power scale. This patch set implements the needed interface and updates cpufreq driver to set the right scale in the EM. It is based on top of patch series adding milli-Watts flag in EM [1] (next-20201124 was used as a base). Regards, Lukasz [1] https://lore.kernel.org/linux-pm/20201103090600.29053-1-lukasz.l...@arm.com/ Lukasz Luba (2): firmware: arm_scmi: Add power_scale_mw_get() interface cpufreq: arm_scmi: Discover the power scale in performance protocol drivers/cpufreq/scmi-cpufreq.c | 4 +++- drivers/firmware/arm_scmi/perf.c | 8 include/linux/scmi_protocol.h| 1 + 3 files changed, 12 insertions(+), 1 deletion(-) Could you take this patch set, please? Patch 1/2, which is ARM firmware protocol change, got ACK from Sudeep in case it would go via your PM tree. The patch series is a follow up to the EM changes, which you have taken recently into your PM tree (link in the cover letter above). Regards, Lukasz
Re: [PATCH v3] vhost-vdpa: fix page pinning leakage in error path (rework)
On Thu, Nov 05, 2020 at 06:26:33PM -0500, Si-Wei Liu wrote:
> Pinned pages are not properly accounted particularly when
> mapping error occurs on IOTLB update. Clean up dangling
> pinned pages for the error path.
>
> The memory usage for bookkeeping pinned pages is reverted
> to what it was before: only one single free page is needed.
> This helps reduce the host memory demand for VM with a large
> amount of memory, or in the situation where host is running
> short of free memory.
>
> Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend")
> Signed-off-by: Si-Wei Liu
Not sure which tree this is against, I had to apply this with
minor tweaks. Pls take a look at the vhost tree and
let me know whether it looks ok to you.
> ---
> Changes in v3:
> - Turn explicit last_pfn check to a WARN_ON() (Jason)
>
> Changes in v2:
> - Drop the reversion patch
> - Fix unhandled page leak towards the end of page_list
>
> drivers/vhost/vdpa.c | 80
>
> 1 file changed, 62 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index b6d9016..5b13dfd 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -560,6 +560,8 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
>
> if (r)
> vhost_iotlb_del_range(dev->iotlb, iova, iova + size - 1);
> + else
> + atomic64_add(size >> PAGE_SHIFT, &dev->mm->pinned_vm);
>
> return r;
> }
> @@ -591,14 +593,16 @@ static int vhost_vdpa_process_iotlb_update(struct
> vhost_vdpa *v,
> unsigned long list_size = PAGE_SIZE / sizeof(struct page *);
> unsigned int gup_flags = FOLL_LONGTERM;
> unsigned long npages, cur_base, map_pfn, last_pfn = 0;
> - unsigned long locked, lock_limit, pinned, i;
> + unsigned long lock_limit, sz2pin, nchunks, i;
> u64 iova = msg->iova;
> + long pinned;
> int ret = 0;
>
> if (vhost_iotlb_itree_first(iotlb, msg->iova,
> msg->iova + msg->size - 1))
> return -EEXIST;
>
> + /* Limit the use of memory for bookkeeping */
> page_list = (struct page **) __get_free_page(GFP_KERNEL);
> if (!page_list)
> return -ENOMEM;
> @@ -607,52 +611,75 @@ static int vhost_vdpa_process_iotlb_update(struct
> vhost_vdpa *v,
> gup_flags |= FOLL_WRITE;
>
> npages = PAGE_ALIGN(msg->size + (iova & ~PAGE_MASK)) >> PAGE_SHIFT;
> - if (!npages)
> - return -EINVAL;
> + if (!npages) {
> + ret = -EINVAL;
> + goto free;
> + }
>
> mmap_read_lock(dev->mm);
>
> - locked = atomic64_add_return(npages, &dev->mm->pinned_vm);
> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> -
> - if (locked > lock_limit) {
> + if (npages + atomic64_read(&dev->mm->pinned_vm) > lock_limit) {
> ret = -ENOMEM;
> - goto out;
> + goto unlock;
> }
>
> cur_base = msg->uaddr & PAGE_MASK;
> iova &= PAGE_MASK;
> + nchunks = 0;
>
> while (npages) {
> - pinned = min_t(unsigned long, npages, list_size);
> - ret = pin_user_pages(cur_base, pinned,
> - gup_flags, page_list, NULL);
> - if (ret != pinned)
> + sz2pin = min_t(unsigned long, npages, list_size);
> + pinned = pin_user_pages(cur_base, sz2pin,
> + gup_flags, page_list, NULL);
> + if (sz2pin != pinned) {
> + if (pinned < 0) {
> + ret = pinned;
> + } else {
> + unpin_user_pages(page_list, pinned);
> + ret = -ENOMEM;
> + }
> goto out;
> + }
> + nchunks++;
>
> if (!last_pfn)
> map_pfn = page_to_pfn(page_list[0]);
>
> - for (i = 0; i < ret; i++) {
> + for (i = 0; i < pinned; i++) {
> unsigned long this_pfn = page_to_pfn(page_list[i]);
> u64 csize;
>
> if (last_pfn && (this_pfn != last_pfn + 1)) {
> /* Pin a contiguous chunk of memory */
> csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
> - if (vhost_vdpa_map(v, iova, csize,
> -map_pfn << PAGE_SHIFT,
> -msg->perm))
> + ret = vhost_vdpa_map(v, iova, csize,
> + map_pfn << PAGE_SHIFT,
> + msg->perm);
> + if (ret) {
> + /*
> + * Un
[PATCH v3 1/2] siox: Use bus_type functions for probe, remove and shutdown
The eventual goal is to get rid of the callbacks in struct
device_driver.
Acked-by: Thorsten Scherer
Signed-off-by: Uwe Kleine-König
---
drivers/siox/siox-core.c | 49
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index f8c08fb9891d..b56cdcb52967 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -512,41 +512,48 @@ static int siox_match(struct device *dev, struct
device_driver *drv)
return 1;
}
-static struct bus_type siox_bus_type = {
- .name = "siox",
- .match = siox_match,
-};
-
-static int siox_driver_probe(struct device *dev)
+static int siox_probe(struct device *dev)
{
struct siox_driver *sdriver = to_siox_driver(dev->driver);
struct siox_device *sdevice = to_siox_device(dev);
- int ret;
- ret = sdriver->probe(sdevice);
- return ret;
+ return sdriver->probe(sdevice);
}
-static int siox_driver_remove(struct device *dev)
+static int siox_remove(struct device *dev)
{
struct siox_driver *sdriver =
container_of(dev->driver, struct siox_driver, driver);
struct siox_device *sdevice = to_siox_device(dev);
- int ret;
+ int ret = 0;
+
+ if (sdriver->remove)
+ ret = sdriver->remove(sdevice);
- ret = sdriver->remove(sdevice);
return ret;
}
-static void siox_driver_shutdown(struct device *dev)
+static void siox_shutdown(struct device *dev)
{
- struct siox_driver *sdriver =
- container_of(dev->driver, struct siox_driver, driver);
struct siox_device *sdevice = to_siox_device(dev);
+ struct siox_driver *sdriver;
- sdriver->shutdown(sdevice);
+ if (!dev->driver)
+ return;
+
+ sdriver = container_of(dev->driver, struct siox_driver, driver);
+ if (sdriver->shutdown)
+ sdriver->shutdown(sdevice);
}
+static struct bus_type siox_bus_type = {
+ .name = "siox",
+ .match = siox_match,
+ .probe = siox_probe,
+ .remove = siox_remove,
+ .shutdown = siox_shutdown,
+};
+
static ssize_t active_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -882,7 +889,8 @@ int __siox_driver_register(struct siox_driver *sdriver,
struct module *owner)
if (unlikely(!siox_is_registered))
return -EPROBE_DEFER;
- if (!sdriver->set_data && !sdriver->get_data) {
+ if (!sdriver->probe ||
+ (!sdriver->set_data && !sdriver->get_data)) {
pr_err("Driver %s doesn't provide needed callbacks\n",
sdriver->driver.name);
return -EINVAL;
@@ -891,13 +899,6 @@ int __siox_driver_register(struct siox_driver *sdriver,
struct module *owner)
sdriver->driver.owner = owner;
sdriver->driver.bus = &siox_bus_type;
- if (sdriver->probe)
- sdriver->driver.probe = siox_driver_probe;
- if (sdriver->remove)
- sdriver->driver.remove = siox_driver_remove;
- if (sdriver->shutdown)
- sdriver->driver.shutdown = siox_driver_shutdown;
-
ret = driver_register(&sdriver->driver);
if (ret)
pr_err("Failed to register siox driver %s (%d)\n",
--
2.29.2
[PATCH v3 0/2] siox: two cleanups
Hello, compared to v2 sent starting with Message-Id: 20201124141834.3096325-1-u.kleine-koe...@pengutronix.de: - fix typo in commit log of patch 1 - add Ack by Thorsten for patch 1 Uwe Kleine-König (2): siox: Use bus_type functions for probe, remove and shutdown siox: Make remove callback return void drivers/siox/siox-core.c | 50 include/linux/siox.h | 2 +- 2 files changed, 26 insertions(+), 26 deletions(-) base-commit: 418baf2c28f3473039f2f7377760bd8f6897ae18 -- 2.29.2
[PATCH v3 2/2] siox: Make remove callback return void
The driver core ignores the return value of the remove callback, so
don't give siox drivers the chance to provide a value.
All siox drivers only allocate devm-managed resources in
.probe, so there is no .remove callback to fix.
Signed-off-by: Uwe Kleine-König
---
drivers/siox/siox-core.c | 5 ++---
include/linux/siox.h | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index b56cdcb52967..1794ff0106bc 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -525,12 +525,11 @@ static int siox_remove(struct device *dev)
struct siox_driver *sdriver =
container_of(dev->driver, struct siox_driver, driver);
struct siox_device *sdevice = to_siox_device(dev);
- int ret = 0;
if (sdriver->remove)
- ret = sdriver->remove(sdevice);
+ sdriver->remove(sdevice);
- return ret;
+ return 0;
}
static void siox_shutdown(struct device *dev)
diff --git a/include/linux/siox.h b/include/linux/siox.h
index da7225bf1877..6bfbda3f634c 100644
--- a/include/linux/siox.h
+++ b/include/linux/siox.h
@@ -36,7 +36,7 @@ bool siox_device_connected(struct siox_device *sdevice);
struct siox_driver {
int (*probe)(struct siox_device *sdevice);
- int (*remove)(struct siox_device *sdevice);
+ void (*remove)(struct siox_device *sdevice);
void (*shutdown)(struct siox_device *sdevice);
/*
--
2.29.2
Re: [PATCH v4] i2c: virtio: add a virtio i2c frontend driver
On Mon, Oct 12, 2020 at 09:55:55AM +0800, Jie Deng wrote:
> Add an I2C bus driver for virtio para-virtualization.
>
> The controller can be emulated by the backend driver in
> any device model software by following the virtio protocol.
>
> This driver communicates with the backend driver through a
> virtio I2C message structure which includes following parts:
>
> - Header: i2c_msg addr, flags, len.
> - Data buffer: the pointer to the I2C msg data.
> - Status: the processing result from the backend.
>
> People may implement different backend drivers to emulate
> different controllers according to their needs. A backend
> example can be found in the device model of the open source
> project ACRN. For more information, please refer to
> https://projectacrn.org.
>
> The virtio device ID 34 is used for this I2C adpter since IDs
> before 34 have been reserved by other virtio devices.
>
> Co-developed-by: Conghui Chen
> Signed-off-by: Conghui Chen
> Signed-off-by: Jie Deng
> Reviewed-by: Shuo Liu
> Reviewed-by: Andy Shevchenko
I assume this will be updated once the specification is acked
by the virtio tc. Holding off on this one for now since
we know there will be host/guest ABI changes.
> ---
> The device ID request:
> https://github.com/oasis-tcs/virtio-spec/issues/85
>
> The specification:
>
> https://lists.oasis-open.org/archives/virtio-comment/202009/msg00021.html
>
> Changes in v4:
> - Use (!(vmsg && vmsg == &vi->vmsg)) instead of ((!vmsg) || (vmsg !=
> &vi->vmsg))
>
> Changes in v3:
> - Move the interface into uAPI according to Jason.
> - Fix issues reported by Dan Carpenter.
> - Fix typo reported by Randy.
>
> Changes in v2:
> - Addressed comments received from Michael, Andy and Jason.
>
> drivers/i2c/busses/Kconfig | 11 ++
> drivers/i2c/busses/Makefile | 3 +
> drivers/i2c/busses/i2c-virtio.c | 256
>
> include/uapi/linux/virtio_i2c.h | 31 +
> include/uapi/linux/virtio_ids.h | 1 +
> 5 files changed, 302 insertions(+)
> create mode 100644 drivers/i2c/busses/i2c-virtio.c
> create mode 100644 include/uapi/linux/virtio_i2c.h
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 293e7a0..f2f6543 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -21,6 +21,17 @@ config I2C_ALI1535
> This driver can also be built as a module. If so, the module
> will be called i2c-ali1535.
>
> +config I2C_VIRTIO
> + tristate "Virtio I2C Adapter"
> + depends on VIRTIO
> + help
> + If you say yes to this option, support will be included for the virtio
> + I2C adapter driver. The hardware can be emulated by any device model
> + software according to the virtio protocol.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-virtio.
> +
> config I2C_ALI1563
> tristate "ALI 1563"
> depends on PCI
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 19aff0e..821acfa 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -6,6 +6,9 @@
> # ACPI drivers
> obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
>
> +# VIRTIO I2C host controller driver
> +obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
> +
> # PC SMBus host controller drivers
> obj-$(CONFIG_I2C_ALI1535)+= i2c-ali1535.o
> obj-$(CONFIG_I2C_ALI1563)+= i2c-ali1563.o
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> new file mode 100644
> index 000..36d8c68
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-virtio.c
> @@ -0,0 +1,256 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Virtio I2C Bus Driver
> + *
> + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +/**
> + * struct virtio_i2c_msg - the virtio I2C message structure
> + * @hdr: the virtio I2C message header
> + * @buf: virtio I2C message data buffer
> + * @status: the processing result from the backend
> + */
> +struct virtio_i2c_msg {
> + struct virtio_i2c_hdr hdr;
> + u8 *buf;
> + u8 status;
> +};
> +
> +/**
> + * struct virtio_i2c - virtio I2C data
> + * @vdev: virtio device for this controller
> + * @completion: completion of virtio I2C message
> + * @vmsg: the virtio I2C message for communication
> + * @adap: I2C adapter for this controller
> + * @i2c_lock: lock for virtqueue processing
> + * @vq: the virtio virtqueue for communication
> + */
> +struct virtio_i2c {
> + struct virtio_device *vdev;
> + struct completion completion;
> + struct virtio_i2c_msg vmsg;
> + struct i2c_adapter adap;
> + struct mutex i2c_lock;
> + struct virtqueue *vq;
> +};
> +
> +static void virtio_i2c_msg_
Re: [PATCH -tip 18/32] kernel/entry: Add support for core-wide protection of kernel-mode
On Tue, Nov 17, 2020 at 06:19:48PM -0500, Joel Fernandes (Google) wrote: > Core-scheduling prevents hyperthreads in usermode from attacking each > other, but it does not do anything about one of the hyperthreads > entering the kernel for any reason. This leaves the door open for MDS > and L1TF attacks with concurrent execution sequences between > hyperthreads. > > This patch therefore adds support for protecting all syscall and IRQ > kernel mode entries. Care is taken to track the outermost usermode exit > and entry using per-cpu counters. In cases where one of the hyperthreads > enter the kernel, no additional IPIs are sent. Further, IPIs are avoided > when not needed - example: idle and non-cookie HTs do not need to be > forced into kernel mode. > > More information about attacks: > For MDS, it is possible for syscalls, IRQ and softirq handlers to leak > data to either host or guest attackers. For L1TF, it is possible to leak > to guest attackers. There is no possible mitigation involving flushing > of buffers to avoid this since the execution of attacker and victims > happen concurrently on 2 or more HTs. > .../admin-guide/kernel-parameters.txt | 11 + > include/linux/entry-common.h | 12 +- > include/linux/sched.h | 12 + > kernel/entry/common.c | 28 +- > kernel/sched/core.c | 241 ++ > kernel/sched/sched.h | 3 + > 6 files changed, 304 insertions(+), 3 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index bd1a5b87a5e2..b185c6ed4aba 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -4678,6 +4678,17 @@ > > sbni= [NET] Granch SBNI12 leased line adapter > > + sched_core_protect_kernel= > + [SCHED_CORE] Pause SMT siblings of a core running in > + user mode, if at least one of the siblings of the core > + is running in kernel mode. This is to guarantee that > + kernel data is not leaked to tasks which are not trusted > + by the kernel. A value of 0 disables protection, 1 > + enables protection. The default is 1. Note that > protection > + depends on the arch defining the _TIF_UNSAFE_RET flag. > + Further, for protecting VMEXIT, arch needs to call > + KVM entry/exit hooks. > + > sched_debug [KNL] Enables verbose scheduler debug messages. > > schedstats= [KNL,X86] Enable or disable scheduled statistics. So I don't like the parameter name, it's too long. Also I don't like it because its a boolean. You're adding syscall,irq,kvm under a single knob where they're all due to different flavours of broken. Different hardware might want/need different combinations. Hardware without MDS but with L1TF wouldn't need the syscall hook, but you're not givng a choice here. And this is generic code, you can't assume stuff like this.
Re: linux-next: stall warnings and deadlock on Arm64 (was: [PATCH] kfence: Avoid stalling...)
On Tue, Nov 24, 2020 at 07:30PM +, Mark Rutland wrote:
[...]
> > > I've just updated that branch with a new version which I hope covers
> > > kernel<->kernel transitions too. If you get a chance, would you mind
> > > giving that a spin?
> > >
> > > The HEAD commit should be:
> > >
> > > a51334f033f8ee88 ("HACK: check IRQ tracing has RCU watching")
> >
> > Thank you! Your series appears to work and fixes the stalls and
> > deadlocks (3 trials)!
>
> Thanks for testing! I'm glad that appears to work, as it suggests
> there's not another massive problem lurking in this area.
>
> While cleaning/splitting that up today, I spotted a couple of new
> problems I introduced, and I'm part-way through sorting that out, but
> it's not quite ready today after all. :/
>
> Fingers crossed for tomorrow...
>
> > I noticed there are a bunch of warnings in the log
> > that might be relevant (see attached).
>
> > [ 91.184432] =
> > [ 91.188301] WARNING: suspicious RCU usage
> > [ 91.192316] 5.10.0-rc4-next-20201119-2-g51c2bf0ac853 #25 Tainted: G
> > W
> > [ 91.197536] -
> > [ 91.201431] kernel/trace/trace_preemptirq.c:78 RCU not watching
> > trace_hardirqs_off()!
> > [ 91.206546]
> > [ 91.206546] other info that might help us debug this:
> > [ 91.206546]
> > [ 91.211790]
> > [ 91.211790] rcu_scheduler_active = 2, debug_locks = 0
> > [ 91.216454] RCU used illegally from extended quiescent state!
> > [ 91.220890] no locks held by swapper/0/0.
> > [ 91.224712]
> > [ 91.224712] stack backtrace:
> > [ 91.228794] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW
> > 5.10.0-rc4-next-20201119-2-g51c2bf0ac853 #25
> > [ 91.234877] Hardware name: linux,dummy-virt (DT)
> > [ 91.239032] Call trace:
> > [ 91.242587] dump_backtrace+0x0/0x240
> > [ 91.246500] show_stack+0x34/0x88
> > [ 91.250295] dump_stack+0x140/0x1bc
> > [ 91.254159] lockdep_rcu_suspicious+0xe4/0xf8
> > [ 91.258332] trace_hardirqs_off+0x214/0x330
> > [ 91.262462] trace_graph_return+0x1ac/0x1d8
> > [ 91.266564] ftrace_return_to_handler+0xa4/0x170
> > [ 91.270809] return_to_handler+0x1c/0x38
> > [ 91.274826] default_idle_call+0x94/0x38c
> > [ 91.278869] do_idle+0x240/0x290
> > [ 91.282633] rest_init+0x1e8/0x2dc
> > [ 91.286529] arch_call_rest_init+0x1c/0x28
> > [ 91.290585] start_kernel+0x638/0x670
>
> Hmm... I suspect that arch_cpu_idle() is being traced here, and I reckon
> we have to mark that and its callees as noinstr, since it doesn't seem
> sane to have ftrace check whether RCU is watching for every function
> call. Maybe Paul or Steve can correct me. ;)
Yes, it's arch_cpu_idle().
> If you still have the binary lying around, can you check whether
> default_idle_call+0x94/0x38c is just after the call to arch_cpu_idle()?
> If you could dump the asm around that, along with whatever faddr2line
> tells you, that'd be a great help.
I reran to be sure, with similar results. I've attached a
syz-symbolize'd version of the warnings.
Thanks,
-- Marco
sched: DL replenish lagged too much
PASSED
Testing tracer wakeup_dl: PASSED
Testing tracer function_graph:
=
WARNING: suspicious RCU usage
5.10.0-rc4-next-20201119-2-g51c2bf0ac853 #25 Tainted: GW
-
kernel/trace/trace_preemptirq.c:78 RCU not watching trace_hardirqs_off()!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW
5.10.0-rc4-next-20201119-2-g51c2bf0ac853 #25
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x240 arch/arm64/kernel/stacktrace.c:100
show_stack+0x34/0x88 arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x140/0x1bc lib/dump_stack.c:120
lockdep_rcu_suspicious+0xe4/0xf8 kernel/locking/lockdep.c:6353
trace_hardirqs_off+0x214/0x330 kernel/trace/trace_preemptirq.c:78
trace_graph_return+0x1ac/0x1d8 kernel/trace/trace_functions_graph.c:253
ftrace_return_to_handler+0xa4/0x170 kernel/trace/fgraph.c:239
return_to_handler+0x1c/0x38 arch/arm64/kernel/entry-ftrace.S:333
default_idle_call+0x94/0x38c kernel/sched/idle.c:112
cpuidle_idle_call kernel/sched/idle.c:194 [inline]
do_idle+0x240/0x290 kernel/sched/idle.c:299
rest_init+0x1e8/0x2dc init/main.c:722
arch_call_rest_init+0x1c/0x28
start_kernel+0x638/0x670 init/main.c:1066
WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:5279
check_flags.part.0+0x1d4/0x1f8 kernel/locking/lockdep.c:5279
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.10.0-rc4-next-20201119-2-g51c2bf0ac853 #25
Hardware name: linux,dummy-virt (DT)
pstate: 8085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
pc : check_flags.part.0+0x1d4/0x1f8 kernel/locking/lockdep.c:5279
lr
Re: [PATCH v4 07/13] media: controls: Validate H264 stateless controls
On 23/11/2020 15:39, Ezequiel Garcia wrote:
> Check that all the fields that correspond or are related
> to a H264 specification syntax element have legal values.
>
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 128 +++
> include/media/h264-ctrls.h | 9 ++
> 2 files changed, 137 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 88ad475bd716..7b4f5ca91b86 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1775,6 +1775,9 @@ static int std_validate_compound(const struct v4l2_ctrl
> *ctrl, u32 idx,
> {
> struct v4l2_ctrl_mpeg2_slice_params *p_mpeg2_slice_params;
> struct v4l2_ctrl_vp8_frame_header *p_vp8_frame_header;
> + struct v4l2_ctrl_h264_sps *p_h264_sps;
> + struct v4l2_ctrl_h264_pps *p_h264_pps;
> + struct v4l2_ctrl_h264_pred_weights *p_h264_pred_weights;
> struct v4l2_ctrl_h264_slice_params *p_h264_slice_params;
> struct v4l2_ctrl_h264_decode_params *p_h264_dec_params;
> struct v4l2_ctrl_hevc_sps *p_hevc_sps;
> @@ -1834,20 +1837,145 @@ static int std_validate_compound(const struct
> v4l2_ctrl *ctrl, u32 idx,
> break;
>
> case V4L2_CTRL_TYPE_H264_SPS:
> + p_h264_sps = p;
> +
> + /* Some syntax elements are only conditionally valid */
> + if (p_h264_sps->pic_order_cnt_type != 0) {
> + p_h264_sps->log2_max_pic_order_cnt_lsb_minus4 = 0;
> + } else if (p_h264_sps->pic_order_cnt_type != 1) {
> + p_h264_sps->num_ref_frames_in_pic_order_cnt_cycle = 0;
> + p_h264_sps->offset_for_non_ref_pic = 0;
> + p_h264_sps->offset_for_top_to_bottom_field = 0;
> + memset(&p_h264_sps->offset_for_ref_frame, 0,
> +sizeof(p_h264_sps->offset_for_ref_frame));
> + }
> +
> + if (!V4L2_H264_SPS_HAS_CHROMA_FORMAT(p_h264_sps)) {
> + p_h264_sps->chroma_format_idc = 1;
> + p_h264_sps->bit_depth_luma_minus8 = 0;
> + p_h264_sps->bit_depth_chroma_minus8 = 0;
> +
> + p_h264_sps->flags &=
> +
> ~V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS;
> +
> + if (p_h264_sps->chroma_format_idc < 3)
> + p_h264_sps->flags &=
> +
> ~V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE;
> + }
> +
> + if (p_h264_sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY)
> + p_h264_sps->flags &=
> + ~V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD;
> +
> + /* Only monochrome and 4:2:0 allowed for these profiles */
> + if (p_h264_sps->profile_idc < V4L2_H264_PROFILE_IDC_HIGH_422 &&
> + p_h264_sps->chroma_format_idc > 1)
> + return -EINVAL;
> + /* 4:2:2 allowed */
> + if (p_h264_sps->profile_idc < V4L2_H264_PROFILE_IDC_HIGH_444 &&
> + p_h264_sps->chroma_format_idc > 2)
> + return -EINVAL;
> + if (p_h264_sps->chroma_format_idc > 3)
> + return -EINVAL;
> +
> + if (p_h264_sps->bit_depth_luma_minus8 > 6)
> + return -EINVAL;
> + if (p_h264_sps->bit_depth_chroma_minus8 > 6)
> + return -EINVAL;
> + if (p_h264_sps->log2_max_frame_num_minus4 > 12)
> + return -EINVAL;
> + if (p_h264_sps->pic_order_cnt_type > 2)
> + return -EINVAL;
> + if (p_h264_sps->log2_max_pic_order_cnt_lsb_minus4 > 12)
> + return -EINVAL;
> + if (p_h264_sps->max_num_ref_frames > V4L2_H264_REF_LIST_LEN)
> + return -EINVAL;
> + break;
> +
> case V4L2_CTRL_TYPE_H264_PPS:
> + p_h264_pps = p;
> +
> + if (p_h264_pps->num_slice_groups_minus1 > 7)
> + return -EINVAL;
> + if (p_h264_pps->num_ref_idx_l0_default_active_minus1 >
> + (V4L2_H264_REF_LIST_LEN - 1))
> + return -EINVAL;
> + if (p_h264_pps->num_ref_idx_l1_default_active_minus1 >
> + (V4L2_H264_REF_LIST_LEN - 1))
> + return -EINVAL;
> + if (p_h264_pps->weighted_bipred_idc > 2)
> + return -EINVAL;
> + /*
> + * pic_init_qp_minus26 shall be in the range of
> + * -(26 + QpBdOffset_y) to +25, inclusive,
> + * where QpBdOffset_y is 6 * bit_depth_luma_minus8
> + */
> + if (p_h264_pps->pic_init_qp_minus26 < -62 ||
> + p_h264_pps->pic_init_qp_minus26 > 25)
Re: [PATCH] Revert "usb: cdns3: core: quit if it uses role switch class"
On 25/11/2020 02:36, Peter Chen wrote:
On 20-11-24 14:22:25, Roger Quadros wrote:
Peter,
On 24/11/2020 13:47, Peter Chen wrote:
On 20-11-24 12:33:34, Roger Quadros wrote:
I am sorry about that. Do you use role switch /sys entry, if you have
used, I prefer using "usb-role-switch" property at dts to judge if SoC
OTG signals or external signals for role switch. If you have not used
it, I prefer only setting cdns->role_sw for role switch use cases.
We use both hardware role switch and /sys entries for manually forcing a
certain role.
We do not set any "usb-role-switch" property at DTS.
Currently cdns->role_sw is being always set by driver irrespective of any DT
property, so this patch is clearly wrong and needs to be reverted.
What do you think?
Could you accept below fix?
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 2e469139769f..fdd52e87a7b2 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -280,8 +280,8 @@ int cdns3_hw_role_switch(struct cdns3 *cdns)
enum usb_role real_role, current_role;
int ret = 0;
- /* Depends on role switch class */
- if (cdns->role_sw)
+ /* quit if switch role through external signals */
+ if (device_property_read_bool(cdns->dev, "usb-role-switch"))
return 0;
pm_runtime_get_sync(cdns->dev);
Although this will fix the issue I don't think this is making the driver to
behave
as expected with usb-role-switch property.
Now, even if usb-role-switch property is not present the driver will still
register
the role switch driver.
I think we need to register the role switch driver only if usb-role-switch
property
is present. We would also need to set the default role if
role-switch-default-mode is present.
How about the following? It still doesn't handle role-switch-default-mode
property though.
Roger, you said you also use /sys entries (I suppose it means through role
switch class) to do role switch, with your change, there will be no /sys
entry for role switch.
Sorry for the confusion. Although we do need both features (SW role switch + HW
role switch)
I don't think it is required to operate simultaneously. If users need SW
control they can set the DT flag.
I see. I prefer embracing all things related to role switch under the
firmware entry condition. Besides, I find another issue that devm_request_irq
for wakeup_irq does not call usb_role_switch_unregister if it has
failed. So, probably, two patches are needed. I am OK you send the
patches to fix both.
Pawel, can you please confirm that if you are ok with either h/w role switching
or s/w role switching but not both working at the same time?
It would have been nice by user to to know the current role even for h/w based
swithcing but it looks like now that won't be possible.
cheers,
-roger
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 2e469139769f..fc6a8152406c 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -427,7 +427,6 @@ static irqreturn_t cdns3_wakeup_irq(int irq, void *data)
*/
static int cdns3_probe(struct platform_device *pdev)
{
- struct usb_role_switch_desc sw_desc = { };
struct device *dev = &pdev->dev;
struct resource *res;
struct cdns3 *cdns;
@@ -529,18 +528,21 @@ static int cdns3_probe(struct platform_device *pdev)
if (ret)
goto err2;
- sw_desc.set = cdns3_role_set;
- sw_desc.get = cdns3_role_get;
- sw_desc.allow_userspace_control = true;
- sw_desc.driver_data = cdns;
- if (device_property_read_bool(dev, "usb-role-switch"))
+ if (device_property_read_bool(dev, "usb-role-switch")) {
+ struct usb_role_switch_desc sw_desc = { };
+
+ sw_desc.set = cdns3_role_set;
+ sw_desc.get = cdns3_role_get;
+ sw_desc.allow_userspace_control = true;
+ sw_desc.driver_data = cdns;
sw_desc.fwnode = dev->fwnode;
- cdns->role_sw = usb_role_switch_register(dev, &sw_desc);
- if (IS_ERR(cdns->role_sw)) {
- ret = PTR_ERR(cdns->role_sw);
- dev_warn(dev, "Unable to register Role Switch\n");
- goto err3;
+ cdns->role_sw = usb_role_switch_register(dev, &sw_desc);
+ if (IS_ERR(cdns->role_sw)) {
+ ret = PTR_ERR(cdns->role_sw);
+ dev_warn(dev, "Unable to register Role Switch\n");
+ goto err3;
+ }
}
if (cdns->wakeup_irq) {
@@ -583,7 +585,8 @@ static int cdns3_probe(struct platform_device *pdev)
return 0;
err4:
cdns3_drd_exit(cdns);
- usb_role_switch_unregister(cdns->role_sw);
+ if (cdns->role_sw)
+ usb_role_switch_unregister(cdns->role_sw);
err3:
set_phy_power_off(cdns);
err2:
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki
Re: [PATCH RESEND 0/5] iommu/tegra-smmu: Some pending reviewed changes
On Tue, Nov 24, 2020 at 03:12:16PM -0800, Nicolin Chen wrote: > On Wed, Nov 25, 2020 at 02:05:14AM +0300, Dmitry Osipenko wrote: > > 25.11.2020 00:21, Nicolin Chen пишет: > > > These five patches were acked by Thierry and acked-n-tested by > > > Dmitry a while ago. Would it be possible for you to apply them? > > > > > > Thanks! > > > > You probably should try to ping Will Deacon. > > > > https://lkml.org/lkml/2020/11/17/243 > > Thank you, Dmitry. > -- > > Will, would it be possible for you to take these changes? > > I sent them on Nov 11 to the following lists: > linux-kernel@vger.kernel.org > io...@lists.linux-foundation.org > > If you need me to resend it again by adding you in To line, > please kindly let me know. Weird, this ended up in my spam. If you wouldn't mind resending with me on To: then please do that. Then I know I'm looking at the correct version. Thanks, Will
Re: [PATCH] slimbus: qcom-ngd-ctrl: Avoid sending power requests without QMI
On 25/11/2020 05:42, Bjorn Andersson wrote:
Attempting to send a power request during PM operations, when the QMI
handle isn't initialized results in a NULL pointer dereference. So check
if the QMI handle has been initialized before attempting to post the
power requests.
Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
Signed-off-by: Bjorn Andersson
Applied thanks,
--srini
[PATCH] mmc: sdhci-pci-gli: Disable slow mode in HS400 mode for GL9763E
From: Ben Chuang
The GL9763E uses 150Mhz (slow mode) by default in HS400 mode. In order
to make HS400 mode run at 200Mhz, the slow mode needs to be turned off.
Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support")
Signed-off-by: Ben Chuang
---
drivers/mmc/host/sdhci-pci-gli.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index 9887485a4134..d45d7e529150 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -87,6 +87,9 @@
#define PCIE_GLI_9763E_SCR 0x8E0
#define GLI_9763E_SCR_AXI_REQ BIT(9)
+#define PCIE_GLI_9763E_MMC_CTRL 0x960
+#define GLI_9763E_HS400_SLOW BIT(3)
+
#define SDHCI_GLI_9763E_CQE_BASE_ADDR 0x200
#define GLI_9763E_CQE_TRNS_MODE (SDHCI_TRNS_MULTI | \
SDHCI_TRNS_BLK_CNT_EN | \
@@ -764,6 +767,10 @@ static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
value |= GLI_9763E_SCR_AXI_REQ;
pci_write_config_dword(pdev, PCIE_GLI_9763E_SCR, value);
+ pci_read_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, &value);
+ value &= ~GLI_9763E_HS400_SLOW;
+ pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value);
+
pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, &value);
value &= ~GLI_9763E_VHS_REV;
value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R);
--
2.29.2
Re: [PATCH] mmc: sdhci-pci-gli: Disable slow mode in HS400 mode for GL9763E
On Wed, 25 Nov 2020 at 10:59, Ben Chuang wrote:
>
> From: Ben Chuang
>
> The GL9763E uses 150Mhz (slow mode) by default in HS400 mode. In order
> to make HS400 mode run at 200Mhz, the slow mode needs to be turned off.
>
> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support")
Why a fixes tag? This patch looks like an improvement and not a fix, right?
Kind regards
Uffe
> Signed-off-by: Ben Chuang
> ---
> drivers/mmc/host/sdhci-pci-gli.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pci-gli.c
> b/drivers/mmc/host/sdhci-pci-gli.c
> index 9887485a4134..d45d7e529150 100644
> --- a/drivers/mmc/host/sdhci-pci-gli.c
> +++ b/drivers/mmc/host/sdhci-pci-gli.c
> @@ -87,6 +87,9 @@
> #define PCIE_GLI_9763E_SCR 0x8E0
> #define GLI_9763E_SCR_AXI_REQ BIT(9)
>
> +#define PCIE_GLI_9763E_MMC_CTRL 0x960
> +#define GLI_9763E_HS400_SLOW BIT(3)
> +
> #define SDHCI_GLI_9763E_CQE_BASE_ADDR 0x200
> #define GLI_9763E_CQE_TRNS_MODE (SDHCI_TRNS_MULTI | \
> SDHCI_TRNS_BLK_CNT_EN | \
> @@ -764,6 +767,10 @@ static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
> value |= GLI_9763E_SCR_AXI_REQ;
> pci_write_config_dword(pdev, PCIE_GLI_9763E_SCR, value);
>
> + pci_read_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, &value);
> + value &= ~GLI_9763E_HS400_SLOW;
> + pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value);
> +
> pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, &value);
> value &= ~GLI_9763E_VHS_REV;
> value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R);
> --
> 2.29.2
>
[v1] drm/msm/dpu: consider vertical front porch in the prefill bw calculation
In case of panels with low vertical back porch, the prefill bw requirement will be high as we will have less time(vbp+pw) to fetch and fill the hw latency buffers before start of first line in active period. For ex: Say hw_latency_line_buffers = 24, and if blanking vbp+pw = 10 Here we need to fetch 24 lines of data in 10 line times. This will increase the bw to the ratio of linebuffers to blanking. DPU hw can also fetch data during vertical front porch provided interface prefetch is enabled. Use vfp in the prefill calculation as dpu driver enables prefetch if the blanking is not sufficient to fill the latency lines. Signed-off-by: Kalyan Thota --- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index 7ea90d2..315b999 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -151,7 +151,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, u64 plane_bw; u32 hw_latency_lines; u64 scale_factor; - int vbp, vpw; + int vbp, vpw, vfp; pstate = to_dpu_plane_state(plane->state); mode = &plane->state->crtc->mode; @@ -164,6 +164,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, fps = drm_mode_vrefresh(mode); vbp = mode->vtotal - mode->vsync_end; vpw = mode->vsync_end - mode->vsync_start; + vfp = mode->vsync_start - mode->vdisplay; hw_latency_lines = dpu_kms->catalog->perf.min_prefill_lines; scale_factor = src_height > dst_height ? mult_frac(src_height, 1, dst_height) : 1; @@ -176,7 +177,13 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, src_width * hw_latency_lines * fps * fmt->bpp * scale_factor * mode->vtotal; - do_div(plane_prefill_bw, (vbp+vpw)); + if ((vbp+vpw) > hw_latency_lines) + do_div(plane_prefill_bw, (vbp+vpw)); + else if ((vbp+vpw+vfp) < hw_latency_lines) + do_div(plane_prefill_bw, (vbp+vpw+vfp)); + else + do_div(plane_prefill_bw, hw_latency_lines); + pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw); } -- 2.7.4
Re: [PATCH v4 12/13] media: uapi: move H264 stateless controls out of staging
On 23/11/2020 15:39, Ezequiel Garcia wrote: > The H264 stateless controls is ready to be part > of the stable uAPI. > > Re-number the control IDs, move them to the newly > created stateless control class, and updates all > the drivers accordingly. > > Signed-off-by: Ezequiel Garcia > --- > drivers/media/v4l2-core/v4l2-ctrls.c | 36 +- > drivers/staging/media/hantro/hantro_drv.c | 26 +- > drivers/staging/media/hantro/hantro_h264.c| 8 +- > drivers/staging/media/rkvdec/rkvdec-h264.c| 8 +- > drivers/staging/media/rkvdec/rkvdec.c | 26 +- > drivers/staging/media/sunxi/cedrus/cedrus.c | 24 +- > .../staging/media/sunxi/cedrus/cedrus_dec.c | 12 +- > include/media/h264-ctrls.h| 411 -- > include/media/v4l2-ctrls.h| 1 - > include/uapi/linux/v4l2-controls.h| 388 + > 10 files changed, 458 insertions(+), 482 deletions(-) > delete mode 100644 include/media/h264-ctrls.h > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c > b/drivers/media/v4l2-core/v4l2-ctrls.c > index badcca73d424..ded16596392c 100644 > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > @@ -693,9 +693,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id) > return h264_fp_arrangement_type; > case V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE: > return h264_fmo_map_type; > - case V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE: > + case V4L2_CID_STATELESS_H264_DECODE_MODE: > return h264_decode_mode; > - case V4L2_CID_MPEG_VIDEO_H264_START_CODE: > + case V4L2_CID_STATELESS_H264_START_CODE: > return h264_start_code; > case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL: > return mpeg_mpeg2_level; > @@ -920,14 +920,6 @@ const char *v4l2_ctrl_get_name(u32 id) > case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP: return "H264 > I-Frame Maximum QP Value"; > case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP: return "H264 > P-Frame Minimum QP Value"; > case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP: return "H264 > P-Frame Maximum QP Value"; > - case V4L2_CID_MPEG_VIDEO_H264_SPS: return "H264 > Sequence Parameter Set"; > - case V4L2_CID_MPEG_VIDEO_H264_PPS: return "H264 > Picture Parameter Set"; > - case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX: return "H264 > Scaling Matrix"; > - case V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS: return "H264 > Slice Parameters"; > - case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS:return "H264 > Decode Parameters"; > - case V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE: return "H264 > Decode Mode"; > - case V4L2_CID_MPEG_VIDEO_H264_START_CODE: return "H264 > Start Code"; > - case V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS: return "H264 > Prediction Weight Table"; > case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL: return "MPEG2 > Level"; > case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE: return "MPEG2 > Profile"; > case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4 > I-Frame QP Value"; > @@ -1185,6 +1177,14 @@ const char *v4l2_ctrl_get_name(u32 id) > /* Stateless Codec controls */ > /* Keep the order of the 'case's the same as in v4l2-controls.h! */ > case V4L2_CID_CODEC_STATELESS_CLASS:return "Stateless Codec > Controls"; > + case V4L2_CID_STATELESS_H264_DECODE_MODE: return "H264 > Decode Mode"; > + case V4L2_CID_STATELESS_H264_START_CODE:return "H264 > Start Code"; > + case V4L2_CID_STATELESS_H264_SPS: return "H264 > Sequence Parameter Set"; > + case V4L2_CID_STATELESS_H264_PPS: return "H264 > Picture Parameter Set"; > + case V4L2_CID_STATELESS_H264_SCALING_MATRIX:return "H264 > Scaling Matrix"; > + case V4L2_CID_STATELESS_H264_PRED_WEIGHTS: return "H264 > Prediction Weight Table"; > + case V4L2_CID_STATELESS_H264_SLICE_PARAMS: return "H264 > Slice Parameters"; > + case V4L2_CID_STATELESS_H264_DECODE_PARAMS: return "H264 > Decode Parameters"; > default: > return NULL; > } > @@ -1310,8 +1310,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum > v4l2_ctrl_type *type, > case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC: > case V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE: > case V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE: > - case V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE: > - case V4L2_CID_MPEG_VIDEO_H264_START_CODE: > case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL: > case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE: > case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL: > @@ -1342,6 +1340,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum > v4l2_ctrl_type
RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken
I do have also other problems with this unit, when IOMMU is enabled and pci=noats is not set as kernel parameter. [ 2004.265906] amdgpu :0b:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110). [ 2004.266024] [drm:amdgpu_device_delayed_init_work_handler [amdgpu]] *ERROR* ib ring test failed (-110). -Original Message- From: Merger, Edgar [AUTOSOL/MAS/AUGS] Sent: Mittwoch, 25. November 2020 10:16 To: 'Deucher, Alexander' ; 'Huang, Ray' ; 'Kuehling, Felix' Cc: 'Will Deacon' ; 'linux-kernel@vger.kernel.org' ; 'linux-...@vger.kernel.org' ; 'io...@lists.linux-foundation.org' ; 'Bjorn Helgaas' ; 'Joerg Roedel' ; 'Zhu, Changfeng' Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken Remark: Systems with R1305G APU (which show the issue) have the following VGA-Controller: 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev cf) Systems with V1404I APU (which do not show the issue) have the following VGA-Controller: 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev 83) "rev cf" vs. "ref 83" is probably what you where referring to with PCI Revision ID. -Original Message- From: Merger, Edgar [AUTOSOL/MAS/AUGS] Sent: Mittwoch, 25. November 2020 07:05 To: 'Deucher, Alexander' ; Huang, Ray ; Kuehling, Felix Cc: Will Deacon ; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; io...@lists.linux-foundation.org; Bjorn Helgaas ; Joerg Roedel ; Zhu, Changfeng Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken I see that problem only on systems that use a R1305G APU sudo cat /sys/kernel/debug/dri/0/amdgpu_firmware_info shows VCE feature version: 0, firmware version: 0x UVD feature version: 0, firmware version: 0x MC feature version: 0, firmware version: 0x ME feature version: 50, firmware version: 0x00a3 PFP feature version: 50, firmware version: 0x00bb CE feature version: 50, firmware version: 0x004f RLC feature version: 1, firmware version: 0x0049 RLC SRLC feature version: 1, firmware version: 0x0001 RLC SRLG feature version: 1, firmware version: 0x0001 RLC SRLS feature version: 1, firmware version: 0x0001 MEC feature version: 50, firmware version: 0x01b5 MEC2 feature version: 50, firmware version: 0x01b5 SOS feature version: 0, firmware version: 0x ASD feature version: 0, firmware version: 0x2130 TA XGMI feature version: 0, firmware version: 0x TA RAS feature version: 0, firmware version: 0x SMC feature version: 0, firmware version: 0x2527 SDMA0 feature version: 41, firmware version: 0x00a9 VCN feature version: 0, firmware version: 0x0110901c DMCU feature version: 0, firmware version: 0x0001 VBIOS version: 113-RAVEN2-117 We are also using V1404I APU on the same boards and I haven´t seen the issue on those boards These boards give me slightly different info: sudo cat /sys/kernel/debug/dri/0/amdgpu_firmware_info VCE feature version: 0, firmware version: 0x UVD feature version: 0, firmware version: 0x MC feature version: 0, firmware version: 0x ME feature version: 47, firmware version: 0x00a2 PFP feature version: 47, firmware version: 0x00b9 CE feature version: 47, firmware version: 0x004e RLC feature version: 1, firmware version: 0x0213 RLC SRLC feature version: 1, firmware version: 0x0001 RLC SRLG feature version: 1, firmware version: 0x0001 RLC SRLS feature version: 1, firmware version: 0x0001 MEC feature version: 47, firmware version: 0x01ab MEC2 feature version: 47, firmware version: 0x01ab SOS feature version: 0, firmware version: 0x ASD feature version: 0, firmware version: 0x2113 TA XGMI feature version: 0, firmware version: 0x TA RAS feature version: 0, firmware version: 0x SMC feature version: 0, firmware version: 0x1e5b SDMA0 feature version: 41, firmware version: 0x00a9 VCN feature version: 0, firmware version: 0x0110901c DMCU feature version: 0, firmware version: 0x VBIOS version: 113-RAVEN-116 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Zeppelin Switch Upstream (PCIE SW.US) 00:01.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] 00:01.5 PCI bridge: Advanced Micro Devices, Inc. [AMD] Zeppelin Switch Upstream (PCIE SW.US) 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:08.1 PCI
linux-next: manual merge of the akpm-current tree with the kspp tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/Kconfig
between commit:
5a3a47bf8367 ("orphans: Hoist '--orphan-handling' into Kconfig")
from the kspp tree and commits:
84d8b3661cc9 ("arm, arm64: move free_unused_memmap() to generic mm")
46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on
DEBUG_PAGEALLOC")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/Kconfig
index 313b2bc0c475,9ebdab3d0ca2..
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -1062,15 -1035,12 +1069,21 @@@ config HAVE_STATIC_CALL_INLIN
bool
depends on HAVE_STATIC_CALL
+config ARCH_WANT_LD_ORPHAN_WARN
+ bool
+ help
+An arch should select this symbol once all linker sections are
explicitly
+included, size-asserted, or discarded in the linker scripts. This is
+important because we never want expected sections to be placed
heuristically
+by the linker, since the locations of such sections can change
between linker
+versions.
+
+ config HAVE_ARCH_PFN_VALID
+ bool
+
+ config ARCH_SUPPORTS_DEBUG_PAGEALLOC
+ bool
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
pgpt8Mv9NkHnB.pgp
Description: OpenPGP digital signature
RE: [PATCH] fpga: dfl: add missing platform_device_put in build_info_create_dev
> Subject: [PATCH] fpga: dfl: add missing platform_device_put in
> build_info_create_dev
>
> platform_device_put is missing when it fails to set fdev->id. Set
> a temp value to do sanity check.
will this case be covered already by build_info_free()?
Hao
>
> Fixes: 543be3d8c999 ("fpga: add device feature list support")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
> ---
> drivers/fpga/dfl.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index b450870b7..8958f0860 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -877,10 +877,13 @@ build_info_create_dev(struct
> build_feature_devs_info *binfo,
>
> INIT_LIST_HEAD(&binfo->sub_features);
>
> - fdev->id = dfl_id_alloc(type, &fdev->dev);
> - if (fdev->id < 0)
> - return fdev->id;
> + int tmp_id = dfl_id_alloc(type, &fdev->dev);
> + if (tmp_id < 0) {
> + platform_device_put(fdev);
> + return tmp_id;
> + }
>
> + fdev->id = tmp_id;
> fdev->dev.parent = &binfo->cdev->region->dev;
> fdev->dev.devt = dfl_get_devt(dfl_devs[type].devt_type, fdev->id);
>
> --
> 2.23.0
[PATCH v2 0/2] IPS: Fix up apply_r_mips_26_rel and add KASLR support for Loongson64
Abandon the third patch in v1. There are many other factors that should be considered. If possible, I'll fix it later. Jinyang He (2): MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel() MIPS: Loongson64: Add KASLR support arch/mips/Kconfig | 5 - arch/mips/kernel/relocate.c | 11 +-- 2 files changed, 13 insertions(+), 3 deletions(-) -- 2.1.0
[PATCH v2 1/2] MIPS: KASLR: Correcte valid bits in apply_r_mips_26_rel()
Apply_r_mips_26_rel() relocates instructions like j, jal and etc. These instructions consist of 6bits function field and 26bits address field. The value of target_addr as follows, = | high 4bits |low 28bits | = |the high 4bits of this PC | the low 26bits of instructions << 2| = Thus, loc_orig and log_new both need high 4bits rather than high 6bits. Signed-off-by: Jinyang He --- v2: Replace ~0x0fff with 0xf000 arch/mips/kernel/relocate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c index 3d80a51..8561c7a 100644 --- a/arch/mips/kernel/relocate.c +++ b/arch/mips/kernel/relocate.c @@ -95,7 +95,7 @@ static int __init apply_r_mips_26_rel(u32 *loc_orig, u32 *loc_new, long offset) /* Original target address */ target_addr <<= 2; - target_addr += (unsigned long)loc_orig & ~0x03ff; + target_addr += (unsigned long)loc_orig & 0xf000; /* Get the new target address */ target_addr += offset; @@ -105,7 +105,7 @@ static int __init apply_r_mips_26_rel(u32 *loc_orig, u32 *loc_new, long offset) return -ENOEXEC; } - target_addr -= (unsigned long)loc_new & ~0x03ff; + target_addr -= (unsigned long)loc_new & 0xf000; target_addr >>= 2; *loc_new = (*loc_new & ~0x03ff) | (target_addr & 0x03ff); -- 2.1.0
[PATCH v2 2/2] MIPS: Loongson64: Add KASLR support
Provide a weak plat_get_fdt() in relocate.c in case some platform enable
USE_OF while plat_get_fdt() is useless.
1MB RELOCATION_TABLE_SIZE is small for Loongson64 because too many
instructions should be relocated. 2MB is enough in present.
Add KASLR support for Loongson64.
KASLR(kernel address space layout randomization)
To enable KASLR on Loongson64:
First, make loongson3_defconfig.
Then, enable CONFIG_RELOCATABLE and CONFIG_RANDOMIZE_BASE.
Finally, compile the kernel.
To test KASLR on Loongson64:
Start machine with KASLR kernel.
The first time:
# cat /proc/iomem
0020-0eff : System RAM
02f3-03895e9f : Kernel code
03895ea0-03bc7fff : Kernel data
03e3-04f43f7f : Kernel bss
The second time:
# cat /proc/iomem
0020-0eff : System RAM
022f-02c55e9f : Kernel code
02c55ea0-02f87fff : Kernel data
031f-04303f7f : Kernel bss
We see that code, data and bss sections become randomize.
Signed-off-by: Jinyang He
---
v2:
- Define weak plat_get_fdt() in relocate.c
- Add default RELOCATION_TABLE_SIZE for Loongson64
arch/mips/Kconfig | 5 -
arch/mips/kernel/relocate.c | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0f638bf..44a47ad 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -488,6 +488,7 @@ config MACH_LOONGSON64
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_ZBOOT
+ select SYS_SUPPORTS_RELOCATABLE
select ZONE_DMA32
select NUMA
select SMP
@@ -2778,7 +2779,8 @@ config RELOCATABLE
depends on CPU_MIPS32_R2 || CPU_MIPS64_R2 || \
CPU_MIPS32_R5 || CPU_MIPS64_R5 || \
CPU_MIPS32_R6 || CPU_MIPS64_R6 || \
- CPU_P5600 || CAVIUM_OCTEON_SOC
+ CPU_P5600 || CAVIUM_OCTEON_SOC || \
+ CPU_LOONGSON64
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
@@ -2789,6 +2791,7 @@ config RELOCATION_TABLE_SIZE
hex "Relocation table size"
depends on RELOCATABLE
range 0x0 0x0100
+ default "0x0020" if CPU_LOONGSON64
default "0x0010"
help
A table of relocation data will be appended to the kernel binary
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 8561c7a..57bdd276 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -294,6 +294,13 @@ static inline int __init relocation_addr_valid(void
*loc_new)
return 1;
}
+#if defined(CONFIG_USE_OF)
+void __weak *plat_get_fdt(void)
+{
+ return NULL;
+}
+#endif
+
void *__init relocate_kernel(void)
{
void *loc_new;
--
2.1.0
Re: [PATCH RESEND 0/5] iommu/tegra-smmu: Some pending reviewed changes
On Wed, Nov 25, 2020 at 09:55:10AM +, Will Deacon wrote: > On Tue, Nov 24, 2020 at 03:12:16PM -0800, Nicolin Chen wrote: > > On Wed, Nov 25, 2020 at 02:05:14AM +0300, Dmitry Osipenko wrote: > > > 25.11.2020 00:21, Nicolin Chen пишет: > > > > These five patches were acked by Thierry and acked-n-tested by > > > > Dmitry a while ago. Would it be possible for you to apply them? > > > > > > > > Thanks! > > > > > > You probably should try to ping Will Deacon. > > > > > > https://lkml.org/lkml/2020/11/17/243 > > > > Thank you, Dmitry. > > -- > > > > Will, would it be possible for you to take these changes? > > > > I sent them on Nov 11 to the following lists: > > linux-kernel@vger.kernel.org > > io...@lists.linux-foundation.org > > > > If you need me to resend it again by adding you in To line, > > please kindly let me know. > > Weird, this ended up in my spam. If you wouldn't mind resending with me > on To: then please do that. Then I know I'm looking at the correct version. Resending. Thanks!
[PATCH platform 1/2] platform/x86: mlx-platform: Remove PSU EEPROM from default platform configuration
Remove PSU EEPROM configuration for systems class equipped with
Mellanox chip Spectrum and Celeron CPU - system types MSN2700, MSN2100.
Till now all the systems from this class used few types of power units,
all equipped with EEPROM device with address space two bytes. Thus, all
these devices have been handled by EEPROM driver "24c02".
There is a new requirement is to support power unit replacement by "off
the shelf" device, matching electrical required parameters. Such device
can be equipped with different EEPROM type, which could be one byte
address space addressing or even could be not equipped with EEPROM.
In such case "24c02" will not work.
Fixes: c6acad68e ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap
interface")
Fixes: ba814fdd0 ("platform/x86: mlx-platform: Use defines for bus assignment")
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 986ad3dda1c1..623e7f737d4a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -383,15 +383,13 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_default_psu_items_data[] = {
.label = "psu1",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(0),
- .hpdev.brdinfo = &mlxplat_mlxcpld_psu[0],
- .hpdev.nr = MLXPLAT_CPLD_PSU_DEFAULT_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
{
.label = "psu2",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(1),
- .hpdev.brdinfo = &mlxplat_mlxcpld_psu[1],
- .hpdev.nr = MLXPLAT_CPLD_PSU_DEFAULT_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
};
--
2.11.0
Re: Oops (probably) unmounting /oldroot/firmware/efi/efivars.
Hello. On 25.11.2020 09:32, Greg Kroah-Hartman wrote: On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote: Hi. On 24.11.2020 15:23, Ard Biesheuvel wrote: > Surely caused by > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/efivarfs?id=fe5186cf12e30facfe261e9be6c7904a170bd822 This also soaked through the stable queue into v5.9.11, and now the same BUG is triggered in the latest stable kernel. /cc Greg cc: me for what? /me has no context as to what to do here... This was a precursor to https://lore.kernel.org/stable/x74vbej49scpv...@kroah.com/ and you already jumped in there. Thanks. -- Oleksandr Natalenko (post-factum)
[PATCH platform 0/2] platform/x86: mlx-platform: Remove PSU EEPROM configuration
Remove PSU EEPROM configuration for systems MSN2700, MSN2100, MSN274x to support the requirement of power unit replacement by "off the shelf" device, matching electrical required parameters. Such device can be equipped with different EEPROM types or even could be not equipped with EEPROM. Patch set contains two bug fixes: - For MSN2700 and MSN2100 system types. - For MSN274x system types. Vadim Pasternak (2): platform/x86: mlx-platform: Remove PSU EEPROM from default platform configuration platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration drivers/platform/x86/mlx-platform.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) -- 2.11.0
[PATCH platform 2/2] platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration
Remove PSU EEPROM configuration for systems class equipped with
Mellanox chip Spectrum and ATOM CPU - system types MSN274x. Till now
all the systems from this class used few types of power units, all
equipped with EEPROM device with address space two bytes. Thus, all
these devices have been handled by EEPROM driver "24c02".
There is a new requirement is to support power unit replacement by "off
the shelf" device, matching electrical required parameters. Such device
can be equipped with different EEPROM type, which could be one byte
address space addressing or even could be not equipped with EEPROM.
In such case "24c02" will not work.
Fixes: ef08e14a3 ("platform/x86: mlx-platform: Add support for new msn274x
system type")
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 623e7f737d4a..598f44558764 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -601,15 +601,13 @@ static struct mlxreg_core_data
mlxplat_mlxcpld_msn274x_psu_items_data[] = {
.label = "psu1",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(0),
- .hpdev.brdinfo = &mlxplat_mlxcpld_psu[0],
- .hpdev.nr = MLXPLAT_CPLD_PSU_MSN_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
{
.label = "psu2",
.reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
.mask = BIT(1),
- .hpdev.brdinfo = &mlxplat_mlxcpld_psu[1],
- .hpdev.nr = MLXPLAT_CPLD_PSU_MSN_NR,
+ .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
},
};
--
2.11.0
[PATCH] MIPS: Loongson64: Fix up reserving kernel memory range
Reserve memory from &_text to &_end. Otherwise if kernel address
was modified, the memory range of start_pfn to kernel_start_pfn
would be reserved. Then we could not use this range.
Signed-off-by: Jinyang He
---
arch/mips/loongson64/numa.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
index 509b360..c6f0c48 100644
--- a/arch/mips/loongson64/numa.c
+++ b/arch/mips/loongson64/numa.c
@@ -151,6 +151,9 @@ static void __init node_mem_init(unsigned int node)
NODE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
if (node == 0) {
+ /* kernel start address */
+ unsigned long kernel_start_pfn = PFN_DOWN(__pa_symbol(&_text));
+
/* kernel end address */
unsigned long kernel_end_pfn = PFN_UP(__pa_symbol(&_end));
@@ -158,8 +161,8 @@ static void __init node_mem_init(unsigned int node)
max_low_pfn = end_pfn;
/* Reserve the kernel text/data/bss */
- memblock_reserve(start_pfn << PAGE_SHIFT,
-((kernel_end_pfn - start_pfn) << PAGE_SHIFT));
+ memblock_reserve(kernel_start_pfn << PAGE_SHIFT,
+((kernel_end_pfn - kernel_start_pfn) <<
PAGE_SHIFT));
/* Reserve 0xfe00~0x for RS780E integrated GPU */
if (node_end_pfn(0) >= (0x >> PAGE_SHIFT))
--
2.1.0
[PATCH RESEND v2 2/5] iommu/tegra-smmu: Expand mutex protection range
This is used to protect potential race condition at use_count.
since probes of client drivers, calling attach_dev(), may run
concurrently.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index ec4c9dafff95..6a3ecc334481 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -256,26 +256,19 @@ static int tegra_smmu_alloc_asid(struct tegra_smmu *smmu,
unsigned int *idp)
{
unsigned long id;
- mutex_lock(&smmu->lock);
-
id = find_first_zero_bit(smmu->asids, smmu->soc->num_asids);
- if (id >= smmu->soc->num_asids) {
- mutex_unlock(&smmu->lock);
+ if (id >= smmu->soc->num_asids)
return -ENOSPC;
- }
set_bit(id, smmu->asids);
*idp = id;
- mutex_unlock(&smmu->lock);
return 0;
}
static void tegra_smmu_free_asid(struct tegra_smmu *smmu, unsigned int id)
{
- mutex_lock(&smmu->lock);
clear_bit(id, smmu->asids);
- mutex_unlock(&smmu->lock);
}
static bool tegra_smmu_capable(enum iommu_cap cap)
@@ -420,17 +413,21 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu,
struct tegra_smmu_as *as)
{
u32 value;
- int err;
+ int err = 0;
+
+ mutex_lock(&smmu->lock);
if (as->use_count > 0) {
as->use_count++;
- return 0;
+ goto unlock;
}
as->pd_dma = dma_map_page(smmu->dev, as->pd, 0, SMMU_SIZE_PD,
DMA_TO_DEVICE);
- if (dma_mapping_error(smmu->dev, as->pd_dma))
- return -ENOMEM;
+ if (dma_mapping_error(smmu->dev, as->pd_dma)) {
+ err = -ENOMEM;
+ goto unlock;
+ }
/* We can't handle 64-bit DMA addresses */
if (!smmu_dma_addr_valid(smmu, as->pd_dma)) {
@@ -453,24 +450,35 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu,
as->smmu = smmu;
as->use_count++;
+ mutex_unlock(&smmu->lock);
+
return 0;
err_unmap:
dma_unmap_page(smmu->dev, as->pd_dma, SMMU_SIZE_PD, DMA_TO_DEVICE);
+unlock:
+ mutex_unlock(&smmu->lock);
+
return err;
}
static void tegra_smmu_as_unprepare(struct tegra_smmu *smmu,
struct tegra_smmu_as *as)
{
- if (--as->use_count > 0)
+ mutex_lock(&smmu->lock);
+
+ if (--as->use_count > 0) {
+ mutex_unlock(&smmu->lock);
return;
+ }
tegra_smmu_free_asid(smmu, as->id);
dma_unmap_page(smmu->dev, as->pd_dma, SMMU_SIZE_PD, DMA_TO_DEVICE);
as->smmu = NULL;
+
+ mutex_unlock(&smmu->lock);
}
static int tegra_smmu_attach_dev(struct iommu_domain *domain,
--
2.17.1
[PATCH] MIPS: No need to check CPU 0 in {loongson3,bmips,octeon}_cpu_disable()
After commit 9cce844abf07 ("MIPS: CPU#0 is not hotpluggable"),
c->hotpluggable is 0 for CPU 0 and it will not generate a control
file in sysfs for this CPU:
[root@linux loongson]# cat /sys/devices/system/cpu/cpu0/online
cat: /sys/devices/system/cpu/cpu0/online: No such file or directory
[root@linux loongson]# echo 0 > /sys/devices/system/cpu/cpu0/online
bash: /sys/devices/system/cpu/cpu0/online: Permission denied
So no need to check CPU 0 in {loongson3,bmips,octeon}_cpu_disable(),
just remove them.
Signed-off-by: Tiezhu Yang
---
arch/mips/cavium-octeon/smp.c | 3 ---
arch/mips/kernel/smp-bmips.c | 3 ---
arch/mips/loongson64/smp.c| 3 ---
3 files changed, 9 deletions(-)
diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 076db9a..66ce552 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -290,9 +290,6 @@ static int octeon_cpu_disable(void)
{
unsigned int cpu = smp_processor_id();
- if (cpu == 0)
- return -EBUSY;
-
if (!octeon_bootloader_entry_addr)
return -ENOTSUPP;
diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 1dbfb5a..359b176 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -362,9 +362,6 @@ static int bmips_cpu_disable(void)
{
unsigned int cpu = smp_processor_id();
- if (cpu == 0)
- return -EBUSY;
-
pr_info("SMP: CPU%d is offline\n", cpu);
set_cpu_online(cpu, false);
diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index aa0cd72..b8c1fc3 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -544,9 +544,6 @@ static int loongson3_cpu_disable(void)
unsigned long flags;
unsigned int cpu = smp_processor_id();
- if (cpu == 0)
- return -EBUSY;
-
set_cpu_online(cpu, false);
calculate_cpu_foreign_map();
local_irq_save(flags);
--
2.1.0
[PATCH RESEND v2 1/5] iommu/tegra-smmu: Unwrap tegra_smmu_group_get
The tegra_smmu_group_get was added to group devices in different
SWGROUPs and it'd return a NULL group pointer upon a mismatch at
tegra_smmu_find_group(), so for most of clients/devices, it very
likely would mismatch and need a fallback generic_device_group().
But now tegra_smmu_group_get handles devices in same SWGROUP too,
which means that it would allocate a group for every new SWGROUP
or would directly return an existing one upon matching a SWGROUP,
i.e. any device will go through this function.
So possibility of having a NULL group pointer in device_group()
is upon failure of either devm_kzalloc() or iommu_group_alloc().
In either case, calling generic_device_group() no longer makes a
sense. Especially for devm_kzalloc() failing case, it'd cause a
problem if it fails at devm_kzalloc() yet succeeds at a fallback
generic_device_group(), because it does not create a group->list
for other devices to match.
This patch simply unwraps the function to clean it up.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 0becdbfea306..ec4c9dafff95 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -903,10 +903,12 @@ static void tegra_smmu_group_release(void *iommu_data)
mutex_unlock(&smmu->lock);
}
-static struct iommu_group *tegra_smmu_group_get(struct tegra_smmu *smmu,
- unsigned int swgroup)
+static struct iommu_group *tegra_smmu_device_group(struct device *dev)
{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
const struct tegra_smmu_group_soc *soc;
+ unsigned int swgroup = fwspec->ids[0];
struct tegra_smmu_group *group;
struct iommu_group *grp;
@@ -950,19 +952,6 @@ static struct iommu_group *tegra_smmu_group_get(struct
tegra_smmu *smmu,
return group->group;
}
-static struct iommu_group *tegra_smmu_device_group(struct device *dev)
-{
- struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
- struct iommu_group *group;
-
- group = tegra_smmu_group_get(smmu, fwspec->ids[0]);
- if (!group)
- group = generic_device_group(dev);
-
- return group;
-}
-
static int tegra_smmu_of_xlate(struct device *dev,
struct of_phandle_args *args)
{
--
2.17.1
[PATCH RESEND v2 5/5] iommu/tegra-smmu: Add PCI support
This patch simply adds support for PCI devices.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index f45ed43cf8db..4a3f095a1c26 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -865,7 +866,11 @@ static struct iommu_group *tegra_smmu_device_group(struct
device *dev)
group->smmu = smmu;
group->soc = soc;
- group->group = iommu_group_alloc();
+ if (dev_is_pci(dev))
+ group->group = pci_device_group(dev);
+ else
+ group->group = generic_device_group(dev);
+
if (IS_ERR(group->group)) {
devm_kfree(smmu->dev, group);
mutex_unlock(&smmu->lock);
@@ -1075,22 +1080,32 @@ struct tegra_smmu *tegra_smmu_probe(struct device *dev,
iommu_device_set_fwnode(&smmu->iommu, dev->fwnode);
err = iommu_device_register(&smmu->iommu);
- if (err) {
- iommu_device_sysfs_remove(&smmu->iommu);
- return ERR_PTR(err);
- }
+ if (err)
+ goto remove_sysfs;
err = bus_set_iommu(&platform_bus_type, &tegra_smmu_ops);
- if (err < 0) {
- iommu_device_unregister(&smmu->iommu);
- iommu_device_sysfs_remove(&smmu->iommu);
- return ERR_PTR(err);
- }
+ if (err < 0)
+ goto unregister;
+
+#ifdef CONFIG_PCI
+ err = bus_set_iommu(&pci_bus_type, &tegra_smmu_ops);
+ if (err < 0)
+ goto unset_platform_bus;
+#endif
if (IS_ENABLED(CONFIG_DEBUG_FS))
tegra_smmu_debugfs_init(smmu);
return smmu;
+
+unset_platform_bus: __maybe_unused;
+ bus_set_iommu(&platform_bus_type, NULL);
+unregister:
+ iommu_device_unregister(&smmu->iommu);
+remove_sysfs:
+ iommu_device_sysfs_remove(&smmu->iommu);
+
+ return ERR_PTR(err);
}
void tegra_smmu_remove(struct tegra_smmu *smmu)
--
2.17.1
[PATCH RESEND v2 4/5] iommu/tegra-smmu: Rework tegra_smmu_probe_device()
The bus_set_iommu() in tegra_smmu_probe() enumerates all clients
to call in tegra_smmu_probe_device() where each client searches
its DT node for smmu pointer and swgroup ID, so as to configure
an fwspec. But this requires a valid smmu pointer even before mc
and smmu drivers are probed. So in tegra_smmu_probe() we added a
line of code to fill mc->smmu, marking "a bit of a hack".
This works for most of clients in the DTB, however, doesn't work
for a client that doesn't exist in DTB, a PCI device for example.
Actually, if we return ERR_PTR(-ENODEV) in ->probe_device() when
it's called from bus_set_iommu(), iommu core will let everything
carry on. Then when a client gets probed, of_iommu_configure() in
iommu core will search DTB for swgroup ID and call ->of_xlate()
to prepare an fwspec, similar to tegra_smmu_probe_device() and
tegra_smmu_configure(). Then it'll call tegra_smmu_probe_device()
again, and this time we shall return smmu->iommu pointer properly.
So we can get rid of tegra_smmu_find() and tegra_smmu_configure()
along with DT polling code by letting the iommu core handle every
thing, except a problem that we search iommus property in DTB not
only for swgroup ID but also for mc node to get mc->smmu pointer
to call dev_iommu_priv_set() and return the smmu->iommu pointer.
So we'll need to find another way to get smmu pointer.
Referencing the implementation of sun50i-iommu driver, of_xlate()
has client's dev pointer, mc node and swgroup ID. This means that
we can call dev_iommu_priv_set() in of_xlate() instead, so we can
simply get smmu pointer in ->probe_device().
This patch reworks tegra_smmu_probe_device() by:
1) Removing mc->smmu hack in tegra_smmu_probe() so as to return
ERR_PTR(-ENODEV) in tegra_smmu_probe_device() during stage of
tegra_smmu_probe/tegra_mc_probe().
2) Moving dev_iommu_priv_set() to of_xlate() so we can get smmu
pointer in tegra_smmu_probe_device() to replace DTB polling.
3) Removing tegra_smmu_configure() accordingly since iommu core
takes care of it.
This also fixes a problem that previously we could add clients to
iommu groups before iommu core initializes its default domain:
ubuntu@jetson:~$ dmesg | grep iommu
platform 5000.host1x: Adding to iommu group 1
platform 5700.gpu: Adding to iommu group 2
iommu: Default domain type: Translated
platform 5420.dc: Adding to iommu group 3
platform 5424.dc: Adding to iommu group 3
platform 5434.vic: Adding to iommu group 4
Though it works fine with IOMMU_DOMAIN_UNMANAGED, but will have
warnings if switching to IOMMU_DOMAIN_DMA:
iommu: Failed to allocate default IOMMU domain of type 0 for
group (null) - Falling back to IOMMU_DOMAIN_DMA
iommu: Failed to allocate default IOMMU domain of type 0 for
group (null) - Falling back to IOMMU_DOMAIN_DMA
Now, bypassing the first probe_device() call from bus_set_iommu()
fixes the sequence:
ubuntu@jetson:~$ dmesg | grep iommu
iommu: Default domain type: Translated
tegra-host1x 5000.host1x: Adding to iommu group 0
tegra-dc 5420.dc: Adding to iommu group 1
tegra-dc 5424.dc: Adding to iommu group 1
tegra-vic 5434.vic: Adding to iommu group 2
nouveau 5700.gpu: Adding to iommu group 3
Note that dmesg log above is testing with IOMMU_DOMAIN_UNMANAGED.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 96 ++
1 file changed, 15 insertions(+), 81 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 297d49f3f80e..f45ed43cf8db 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -797,75 +797,9 @@ static phys_addr_t tegra_smmu_iova_to_phys(struct
iommu_domain *domain,
return SMMU_PFN_PHYS(pfn) + SMMU_OFFSET_IN_PAGE(iova);
}
-static struct tegra_smmu *tegra_smmu_find(struct device_node *np)
-{
- struct platform_device *pdev;
- struct tegra_mc *mc;
-
- pdev = of_find_device_by_node(np);
- if (!pdev)
- return NULL;
-
- mc = platform_get_drvdata(pdev);
- if (!mc)
- return NULL;
-
- return mc->smmu;
-}
-
-static int tegra_smmu_configure(struct tegra_smmu *smmu, struct device *dev,
- struct of_phandle_args *args)
-{
- const struct iommu_ops *ops = smmu->iommu.ops;
- int err;
-
- err = iommu_fwspec_init(dev, &dev->of_node->fwnode, ops);
- if (err < 0) {
- dev_err(dev, "failed to initialize fwspec: %d\n", err);
- return err;
- }
-
- err = ops->of_xlate(dev, args);
- if (err < 0) {
- dev_err(dev, "failed to parse SW group ID: %d\n", err);
- iommu_fwspec_free(dev);
- return err;
- }
-
- return 0;
-}
-
static struct iommu_device *tegra_smmu_probe_device(struct dev
[PATCH RESEND v2 0/5] iommu/tegra-smmu: Some pending reviewed changes
Changelog v1->v2: * Added Thierry's acks to PATCH-3~5 This is a merged set of resend for previously two series of patches that were reviewed/acked a month ago yet have not got applied. Series-1: https://lkml.org/lkml/2020/9/29/73 "[PATCH v4 0/2] iommu/tegra-smmu: Two followup changes" Series-2: https://lkml.org/lkml/2020/10/9/808 "[PATCH v7 0/3] iommu/tegra-smmu: Add PCI support" Nicolin Chen (5): iommu/tegra-smmu: Unwrap tegra_smmu_group_get iommu/tegra-smmu: Expand mutex protection range iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev iommu/tegra-smmu: Rework tegra_smmu_probe_device() iommu/tegra-smmu: Add PCI support drivers/iommu/tegra-smmu.c | 240 ++--- 1 file changed, 88 insertions(+), 152 deletions(-) -- 2.17.1
Re: [Intel-wired-lan] [PATCH] e1000e: Assign DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME to speed up s2ram
Hi Paul, On Tue, Nov 24, 2020 at 04:47:30PM +0100, Paul Menzel wrote: > Dear Chen, > > > Thank you for the patch. > Thanks for reviewing this change. > Am 24.11.20 um 16:32 schrieb Chen Yu: > > The NIC is put in runtime suspend status when there is no wire connected. > > As a result, it is safe to keep this NIC in runtime suspended during s2ram > > because the system does not rely on the NIC plug event nor WOL to wake up > > the system. Unlike the s2idle, s2ram does not need to manipulate S0ix > > settings > > during suspend. > > what happens, when I plug in a cable, when the suspend is in ACPI S3 state? > I guess it’s ignored? > I think it depends on the platform(or BIOS implementation). On my platform it is ignored. When the system is running, the plug event would generate a SCI, but if it is in S3, whether to generate wake up event or not depends on the BIOS and the sysfs whether the device is device_may_wakeup(). In summary, whether the NIC is in runtime_suspend() or system_suspended does not impact the wake up from S3 by plug event. > > This patch assigns DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME > > to the e1000e driver so that the s2ram could skip the .suspend_late(), > > .suspend_noirq() and .resume_noirq() .resume_early() when possible. > > Also skip .suspend() and .resume() if dev_pm_skip_suspend() and > > dev_pm_skip_resume() return true, so as to speed up the s2ram. > > What is sped up? Suspend or resume? > Both suspend and resume. > Please also document, what system you tested this on, and what the numbers > before and after are. The platform I'm testing on a laptop with i5-8300H CPU and I219-LM NIC. Before this change: [ 203.391465] e1000e :00:1f.6: pci_pm_suspend+0x0/0x170 returned 0 after 323186 usecs [ 203.598307] e1000e :00:1f.6: pci_pm_suspend_late+0x0/0x40 returned 0 after 4 usecs [ 203.654026] e1000e :00:1f.6: pci_pm_suspend_noirq+0x0/0x290 returned 0 after 20915 usecs [ 203.714464] e1000e :00:1f.6: pci_pm_resume_noirq+0x0/0x120 returned 0 after 19952 usecs [ 203.716208] e1000e :00:1f.6: pci_pm_resume_early+0x0/0x30 returned 0 after 0 usecs [ 203.934399] e1000e :00:1f.6: pci_pm_resume+0x0/0x90 returned 0 after 211437 usecs After this change: [ 150.455612] e1000e :00:1f.6: pci_pm_suspend+0x0/0x170 returned 0 after 14 usecs [ 150.987627] e1000e :00:1f.6: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs [ 151.021659] e1000e :00:1f.6: pci_pm_suspend_noirq+0x0/0x290 returned 0 after 1 usecs [ 151.087303] e1000e :00:1f.6: pci_pm_resume_noirq+0x0/0x120 returned 0 after 0 usecs [ 151.112056] e1000e :00:1f.6: pci_pm_resume_early+0x0/0x30 returned 0 after 0 usecs [ 151.136508] e1000e :00:1f.6: pci_pm_resume+0x0/0x90 returned 0 after 3030 usecs > > If there is a bug report, please note it too. > This is an optimization for scenario when cable is unpluged, so there's no dedicated bug report on this. > > Signed-off-by: Chen Yu > > --- > > drivers/base/power/main.c | 2 ++ > > drivers/net/ethernet/intel/e1000e/netdev.c | 14 +- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > > index c7ac49042cee..9cd8abba8612 100644 > > --- a/drivers/base/power/main.c > > +++ b/drivers/base/power/main.c > > @@ -580,6 +580,7 @@ bool dev_pm_skip_resume(struct device *dev) > > return !dev->power.must_resume; > > } > > +EXPORT_SYMBOL_GPL(dev_pm_skip_resume); > > /** > >* device_resume_noirq - Execute a "noirq resume" callback for given > > device. > > @@ -2010,3 +2011,4 @@ bool dev_pm_skip_suspend(struct device *dev) > > return dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) && > > pm_runtime_status_suspended(dev); > > } > > +EXPORT_SYMBOL_GPL(dev_pm_skip_suspend); > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c > > b/drivers/net/ethernet/intel/e1000e/netdev.c > > index b30f00891c03..d79fddabc553 100644 > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > > @@ -6965,6 +6965,14 @@ static __maybe_unused int e1000e_pm_suspend(struct > > device *dev) > > struct e1000_hw *hw = &adapter->hw; > > int rc; > > + /* Runtime suspended means that there is no wired connection > > Maybe explicitly use *cable* in here to avoid confusion? > Okay. > > +* and it has nothing to do with WOL that, we don't need to > > Move the comma before *that*? > Okay. > > +* adjust the WOL settings. So it is safe to put NIC in > > +* runtime suspend while doing system suspend. > > I understood, that the NIC is already in runtime suspend? Could you please > clarify the comment? > Yes, it is already runtime suspended, I'll revise the comment. Thanks, Chenyu > > +*/ > > + if (dev_pm_skip_suspend(dev)) > > + return 0; > > + > > e1000e_flush_lpic(pdev); > > e1000e_pm_freeze(dev); > > @@ -69
[PATCH RESEND v2 3/5] iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev
In tegra_smmu_(de)attach_dev() functions, we poll DTB for each
client's iommus property to get swgroup ID in order to prepare
"as" and enable smmu. Actually tegra_smmu_configure() prepared
an fwspec for each client, and added to the fwspec all swgroup
IDs of client DT node in DTB.
So this patch uses fwspec in tegra_smmu_(de)attach_dev() so as
to replace the redundant DT polling code.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 56 --
1 file changed, 23 insertions(+), 33 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 6a3ecc334481..297d49f3f80e 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -484,60 +484,50 @@ static void tegra_smmu_as_unprepare(struct tegra_smmu
*smmu,
static int tegra_smmu_attach_dev(struct iommu_domain *domain,
struct device *dev)
{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
struct tegra_smmu_as *as = to_smmu_as(domain);
- struct device_node *np = dev->of_node;
- struct of_phandle_args args;
- unsigned int index = 0;
- int err = 0;
-
- while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
- &args)) {
- unsigned int swgroup = args.args[0];
-
- if (args.np != smmu->dev->of_node) {
- of_node_put(args.np);
- continue;
- }
+ unsigned int index;
+ int err;
- of_node_put(args.np);
+ if (!fwspec)
+ return -ENOENT;
+ for (index = 0; index < fwspec->num_ids; index++) {
err = tegra_smmu_as_prepare(smmu, as);
- if (err < 0)
- return err;
+ if (err)
+ goto disable;
- tegra_smmu_enable(smmu, swgroup, as->id);
- index++;
+ tegra_smmu_enable(smmu, fwspec->ids[index], as->id);
}
if (index == 0)
return -ENODEV;
return 0;
+
+disable:
+ while (index--) {
+ tegra_smmu_disable(smmu, fwspec->ids[index], as->id);
+ tegra_smmu_as_unprepare(smmu, as);
+ }
+
+ return err;
}
static void tegra_smmu_detach_dev(struct iommu_domain *domain, struct device
*dev)
{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct tegra_smmu_as *as = to_smmu_as(domain);
- struct device_node *np = dev->of_node;
struct tegra_smmu *smmu = as->smmu;
- struct of_phandle_args args;
- unsigned int index = 0;
-
- while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
- &args)) {
- unsigned int swgroup = args.args[0];
+ unsigned int index;
- if (args.np != smmu->dev->of_node) {
- of_node_put(args.np);
- continue;
- }
-
- of_node_put(args.np);
+ if (!fwspec)
+ return;
- tegra_smmu_disable(smmu, swgroup, as->id);
+ for (index = 0; index < fwspec->num_ids; index++) {
+ tegra_smmu_disable(smmu, fwspec->ids[index], as->id);
tegra_smmu_as_unprepare(smmu, as);
- index++;
}
}
--
2.17.1
RE: [PATCH] Revert "usb: cdns3: core: quit if it uses role switch class"
>
>On 25/11/2020 02:36, Peter Chen wrote:
>> On 20-11-24 14:22:25, Roger Quadros wrote:
>>> Peter,
>>>
>>> On 24/11/2020 13:47, Peter Chen wrote:
On 20-11-24 12:33:34, Roger Quadros wrote:
I am sorry about that. Do you use role switch /sys entry, if you have
used, I prefer using "usb-role-switch" property at dts to judge if SoC
OTG signals or external signals for role switch. If you have not used
it, I prefer only setting cdns->role_sw for role switch use cases.
>>>
>>> We use both hardware role switch and /sys entries for manually forcing a
>>> certain role.
>>>
>>> We do not set any "usb-role-switch" property at DTS.
>>>
>>> Currently cdns->role_sw is being always set by driver irrespective of
>>> any DT
>>> property, so this patch is clearly wrong and needs to be reverted.
>>>
>>> What do you think?
>>>
>>
>> Could you accept below fix?
>>
>> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> index 2e469139769f..fdd52e87a7b2 100644
>> --- a/drivers/usb/cdns3/core.c
>> +++ b/drivers/usb/cdns3/core.c
>> @@ -280,8 +280,8 @@ int cdns3_hw_role_switch(struct cdns3 *cdns)
>>enum usb_role real_role, current_role;
>>int ret = 0;
>>
>> - /* Depends on role switch class */
>> - if (cdns->role_sw)
>> + /* quit if switch role through external signals */
>> + if (device_property_read_bool(cdns->dev, "usb-role-switch"))
>>return 0;
>>
>>pm_runtime_get_sync(cdns->dev);
>
> Although this will fix the issue I don't think this is making the driver
> to behave
> as expected with usb-role-switch property.
>
> Now, even if usb-role-switch property is not present the driver will
> still register
> the role switch driver.
>
> I think we need to register the role switch driver only if
> usb-role-switch property
> is present. We would also need to set the default role if
> role-switch-default-mode is present.
>
> How about the following? It still doesn't handle role-switch-default-mode
> property though.
>
Roger, you said you also use /sys entries (I suppose it means through role
switch class) to do role switch, with your change, there will be no /sys
entry for role switch.
>>>
>>> Sorry for the confusion. Although we do need both features (SW role switch
>>> + HW role switch)
>>> I don't think it is required to operate simultaneously. If users need SW
>>> control they can set the DT flag.
>>>
>>
>> I see. I prefer embracing all things related to role switch under the
>> firmware entry condition. Besides, I find another issue that devm_request_irq
>> for wakeup_irq does not call usb_role_switch_unregister if it has
>> failed. So, probably, two patches are needed. I am OK you send the
>> patches to fix both.
>
>Pawel, can you please confirm that if you are ok with either h/w role switching
>or s/w role switching but not both working at the same time?
>
>It would have been nice by user to to know the current role even for h/w based
>swithcing but it looks like now that won't be possible.
For the moment it's ok for me, but form testing point of view it could be nice
to have possibility to easy choose between these two modes in dynamically way.
For PCI based on platform probably I will have to add some parameter to
cdns3-pci.ko
module to allow selecting modes. I don't use DTS.
Don't worry about it now. You can post this fix.
Cheers,
Pawel
>
>cheers,
>-roger
>>
>> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> index 2e469139769f..fc6a8152406c 100644
>> --- a/drivers/usb/cdns3/core.c
>> +++ b/drivers/usb/cdns3/core.c
>> @@ -427,7 +427,6 @@ static irqreturn_t cdns3_wakeup_irq(int irq, void *data)
>>*/
>> static int cdns3_probe(struct platform_device *pdev)
>> {
>> -struct usb_role_switch_desc sw_desc = { };
>> struct device *dev = &pdev->dev;
>> struct resource *res;
>> struct cdns3 *cdns;
>> @@ -529,18 +528,21 @@ static int cdns3_probe(struct platform_device *pdev)
>> if (ret)
>> goto err2;
>>
>> -sw_desc.set = cdns3_role_set;
>> -sw_desc.get = cdns3_role_get;
>> -sw_desc.allow_userspace_control = true;
>> -sw_desc.driver_data = cdns;
>> -if (device_property_read_bool(dev, "usb-role-switch"))
>> +if (device_property_read_bool(dev, "usb-role-switch")) {
>> +struct usb_role_switch_desc sw_desc = { };
>> +
>> +sw_desc.set = cdns3_role_set;
>> +sw_desc.get = cdns3_role_get;
>> +sw_desc.allow_userspace_control = true;
>> +sw_desc.driver_data = cdns;
>> sw_desc.fwnode = dev->fwnode;
>>
>> -cdns->role_sw = usb_role_switch_register(dev, &sw_desc);
>> -if (IS_ERR(cdns->role_sw)) {
>> -ret
Re: [PATCH v8 3/3] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
On Tue, Nov 24, 2020 at 05:20:37PM -0600, Bjorn Helgaas wrote:
> On Wed, Oct 28, 2020 at 10:31:43AM +0900, Kunihiko Hayashi wrote:
> > This patch adds misc interrupt handler to detect and invoke PME/AER event.
> >
> > In UniPhier PCIe controller, PME/AER signals are assigned to the same
> > signal as MSI by the internal logic. These signals should be detected by
> > the internal register, however, DWC MSI handler can't handle these signals.
>
> I don't know what "PME/AER signals are assigned to the same signal as
> MSI" means.
The host controller embeds an interrupt-controller whose IRQ wire output
is cascaded into the main interrupt controller.
The host-bridge embedded controller receives MSI writes from devices
and it turns them into an edge IRQ into the main interrupt controller.
To ack/mask the MSIs at host contoller interrupt controller level, there
is a control register in the host controller that needs handling upon
IRQ reception.
The *RP* (and AFAIU the RP *only*) signals the PME/AER MSI using the
same wire to the main interrupt controller but its ack/mask is handled
by a different bit in the host bridge control register above, therefore
the cascaded IRQ isr needs to know which virq it is actually handling
to ack/mask accordingly.
IMO this should be modelled with a separate IRQ domain and chip for
the root port (yes this implies describing the root port in the dts
file with a separate msi-parent).
This series as it stands is a kludge.
Lorenzo
> I'm trying to figure out if this is talking about PME/AER MSI vector
> numbers (probably not) or some internal wire that's not
> architecturally visible or what.
>
> Probably also not related to the fact that PME, hotplug, and bandwidth
> notifications share the same MSI/MSI-X vector.
>
> Is this something that's going to be applicable to all the DWC-based
> drivers?
>
> > DWC MSI handler calls .msi_host_isr() callback function, that detects
> > PME/AER signals with the internal register and invokes the interrupt
> > with PME/AER vIRQ numbers.
> >
> > These vIRQ numbers is obtained from portdrv in uniphier_add_pcie_port()
> > function.
> >
> > Cc: Marc Zyngier
> > Cc: Jingoo Han
> > Cc: Gustavo Pimentel
> > Cc: Lorenzo Pieralisi
> > Signed-off-by: Kunihiko Hayashi
> > Reviewed-by: Rob Herring
> > ---
> > drivers/pci/controller/dwc/pcie-uniphier.c | 77
> > +-
> > 1 file changed, 66 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c
> > b/drivers/pci/controller/dwc/pcie-uniphier.c
> > index 4817626..237537a 100644
> > --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> > +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> > @@ -21,6 +21,7 @@
> > #include
> >
> > #include "pcie-designware.h"
> > +#include "../../pcie/portdrv.h"
> >
> > #define PCL_PINCTRL0 0x002c
> > #define PCL_PERST_PLDN_REGEN BIT(12)
> > @@ -44,7 +45,9 @@
> > #define PCL_SYS_AUX_PWR_DETBIT(8)
> >
> > #define PCL_RCV_INT0x8108
> > +#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
> > #define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
> > +#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
> > #define PCL_CFG_BW_MGT_STATUS BIT(4)
> > #define PCL_CFG_LINK_AUTO_BW_STATUSBIT(3)
> > #define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
> > @@ -68,6 +71,8 @@ struct uniphier_pcie_priv {
> > struct reset_control *rst;
> > struct phy *phy;
> > struct irq_domain *legacy_irq_domain;
> > + int aer_irq;
> > + int pme_irq;
> > };
> >
> > #define to_uniphier_pcie(x)dev_get_drvdata((x)->dev)
> > @@ -167,7 +172,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie
> > *pci)
> >
> > static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
> > {
> > - writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
> > + u32 val;
> > +
> > + val = PCL_RCV_INT_ALL_ENABLE;
> > + if (pci_msi_enabled())
> > + val |= PCL_RCV_INT_ALL_INT_MASK;
> > + else
> > + val |= PCL_RCV_INT_ALL_MSI_MASK;
>
> I'm confused about how this works. Root Ports can signal AER errors
> with either INTx or MSI. This is controlled by the architected
> Interrupt Disable bit and the MSI/MSI-X enable bits (I'm looking at
> PCIe r5.0, sec 6.2.4.1.2).
>
> The code here doesn't look related to those bits. Does this code mean
> that if pci_msi_enabled(), the Root Port will always signal with MSI
> (if MSI Enable is set) and will *never* signal with INTx?
>
> > + writel(val, priv->base + PCL_RCV_INT);
> > writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
> > }
> >
> > @@ -231,28 +244,52 @@ static const struct irq_domain_ops
> > uniphier_intx_domain_ops = {
> > .map = uniphier_pcie_intx_map,
> > };
> >
> > -static void uniphier_pcie_irq_handler(struct irq_desc *desc)
> > +static void uniphier_pcie_misc_isr(struct pcie_port *pp, bool
[PATCH] clocksource/drivers/ingenic: Fix section mismatch
The function ingenic_tcu_get_clock() is annotated for the __init
section but it is actually called from the online cpu callback.
That will lead to a crash if a CPU is hotplugged after boot time.
Remove the __init annotatation for the ingenic_tcu_get_clock()
function.
Fixes: f19d838d08fc (clocksource/drivers/ingenic: Add high resolution timer
support for SMP/SMT)
Reported-by: kernel test robot
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/ingenic-timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/ingenic-timer.c
b/drivers/clocksource/ingenic-timer.c
index 58fd9189fab7..905fd6b163a8 100644
--- a/drivers/clocksource/ingenic-timer.c
+++ b/drivers/clocksource/ingenic-timer.c
@@ -127,7 +127,7 @@ static irqreturn_t ingenic_tcu_cevt_cb(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static struct clk * __init ingenic_tcu_get_clock(struct device_node *np, int
id)
+static struct clk *ingenic_tcu_get_clock(struct device_node *np, int id)
{
struct of_phandle_args args;
--
2.25.1
