Re: [PATCH] openrisc: Reserve memblock for initrd
On Tue, Sep 01, 2020 at 06:21:01AM +0900, Stafford Horne wrote:
> Recently OpenRISC added support for external initrd images, but I found
> some instability when using larger buildroot initrd images. It turned
> out that I forgot to reserve the memblock space for the initrd image.
>
> This patch fixes the instability issue by reserving memblock space.
>
> Fixes: ff6c923dbec3 ("openrisc: Add support for external initrd images")
> Signed-off-by: Stafford Horne
> ---
> arch/openrisc/kernel/setup.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
> index b18e775f8be3..2c8aa53cc7ba 100644
> --- a/arch/openrisc/kernel/setup.c
> +++ b/arch/openrisc/kernel/setup.c
> @@ -80,6 +80,15 @@ static void __init setup_memory(void)
>*/
> memblock_reserve(__pa(_stext), _end - _stext);
>
> +#ifdef CONFIG_BLK_DEV_INITRD
> + /* Then reserve the initrd, if any */
> + if (initrd_start && (initrd_end > initrd_start)) {
> + memblock_reserve(ALIGN_DOWN(__pa(initrd_start), PAGE_SIZE),
> + ALIGN(initrd_end, PAGE_SIZE) -
> + ALIGN_DOWN(initrd_start, PAGE_SIZE));
> + }
The core mm takes care of reserving the entrire pages for the memory
reserved with memblock, so it is not necessary to do it here.
> +#endif /* CONFIG_BLK_DEV_INITRD */
> +
> early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem();
>
> --
> 2.26.2
>
--
Sincerely yours,
Mike.
Re: [PATCH 2/5] input: misc: Add IBM Operation Panel driver
On Thu, 20 Aug 2020 at 16:12, Eddie James wrote: > > Add a driver to get the button events from the panel and provide > them to userspace with the input subsystem. The panel is > connected with I2C and controls the bus, so the driver registers > as an I2C slave device. > > Signed-off-by: Eddie James > --- > MAINTAINERS| 1 + > drivers/input/misc/Kconfig | 10 ++ > drivers/input/misc/Makefile| 1 + > drivers/input/misc/ibm-panel.c | 186 + > 4 files changed, 198 insertions(+) > create mode 100644 drivers/input/misc/ibm-panel.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a9fd08e9cd54..077cc79ad7fd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8283,6 +8283,7 @@ M:Eddie James > L: linux-in...@vger.kernel.org > S: Maintained > F: Documentation/devicetree/bindings/input/ibm,op-panel.yaml > +F: drivers/input/misc/ibm-panel.c > > IBM Power 842 compression accelerator > M: Haren Myneni > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig > index 362e8a01980c..88fb465a18b8 100644 > --- a/drivers/input/misc/Kconfig > +++ b/drivers/input/misc/Kconfig > @@ -708,6 +708,16 @@ config INPUT_ADXL34X_SPI > To compile this driver as a module, choose M here: the > module will be called adxl34x-spi. > > +config INPUT_IBM_PANEL > + tristate "IBM Operation Panel driver" > + depends on I2C_SLAVE || COMPILE_TEST > + help > + Supports the IBM Operation Panel as an input device. The panel is a > + controller attached to the system with some buttons and an LCD > display > + that allows someone with physical access to the system to perform > + various administrative tasks. This driver only supports the part of > + the controller that sends commands to the system. Is this always attached via a service processor/bmc? If so, mention it here so people know there's no point enabling it on a host/distro kernel. I assume you're implementing the protocol correctly. If you have a link to a specification then include that in the file. The code looks okay to me. Reviewed-by: Joel Stanley
Re: [PATCH v6 1/5] perf/jevents: Remove jevents.h file
On 8/31/20 2:31 PM, John Garry wrote:
> On 31/08/2020 09:43, Jiri Olsa wrote:
>> On Thu, Aug 27, 2020 at 06:39:54PM +0530, Kajol Jain wrote:
>>> This patch removes jevents.h file and add its data inside
>>> jevents.c as this file is only included there.
>>>
>>> Signed-off-by: Kajol Jain
>>> ---
>>> tools/perf/pmu-events/jevents.c | 9 -
>>> tools/perf/pmu-events/jevents.h | 23 ---
>>> 2 files changed, 8 insertions(+), 24 deletions(-)
>>> delete mode 100644 tools/perf/pmu-events/jevents.h
>>>
>>> diff --git a/tools/perf/pmu-events/jevents.c
>>> b/tools/perf/pmu-events/jevents.c
>>> index fa86c5f997cc..1c55cc754b5a 100644
>>> --- a/tools/perf/pmu-events/jevents.c
>>> +++ b/tools/perf/pmu-events/jevents.c
>>> @@ -48,11 +48,18 @@
>>> #include
>>> #include "jsmn.h"
>>> #include "json.h"
>>> -#include "jevents.h"
>>> int verbose;
>>> char *prog;
>>> +#ifndef min
>>> +#define min(x, y) ({ \
>>> + typeof(x) _min1 = (x); \
>>> + typeof(y) _min2 = (y); \
>>> + (void)(&_min1 == &_min2); \
>>> + _min1 < _min2 ? _min1 : _min2; })
>>> +#endif
>
> Wondering what is special about this definition of min that it's required?
> Compiled ok for me without it.
Hi John,
You are right, for me also in power it compiled without any issues, but
not sure if somewhere we have dependency,
that's why I didn't remove it.
Thanks,
Kajol Jain
>
>>> +
>>> int eprintf(int level, int var, const char *fmt, ...)
>>> {
>>> diff --git a/tools/perf/pmu-events/jevents.h
>>> b/tools/perf/pmu-events/jevents.h
>>> deleted file mode 100644
>>> index 2afc8304529e..
>>> --- a/tools/perf/pmu-events/jevents.h
>>> +++ /dev/null
>>> @@ -1,23 +0,0 @@
>>> -/* SPDX-License-Identifier: GPL-2.0 */
>>> -#ifndef JEVENTS_H
>>> -#define JEVENTS_H 1
>>> -
>>> -int json_events(const char *fn,
>>> - int (*func)(void *data, char *name, char *event, char *desc,
>>> - char *long_desc,
>>> - char *pmu,
>>> - char *unit, char *perpkg, char *metric_expr,
>>> - char *metric_name, char *metric_group,
>>> - char *deprecated, char *metric_constraint),
>>> - void *data);
>>> -char *get_cpu_str(void);
>>
>> I think you can also remove get_cpu_str from jevents.c
>>
>> thanks,
>> jirka
>>
>> .
>>
>
Re: [PATCH v7 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
On 01-09-20, 04:58, Wan Mohamad, Wan Ahmad Zainie wrote: > > > @@ -0,0 +1,44 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > > +--- > > > +$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc- > > phy.yaml#" > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > > > + > > > +title: Intel Keem Bay eMMC PHY bindings > > > > This seems same as > > Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml, why > > not add a new compatible in lgm binding, or did I miss a difference? > > AFAIK, LGM make use of syscon node, whilst KMB does not. > And LGM and KMB belongs to different SoC family. So, I prefer them to > be in separate file. > > Having said that, with few changes in wordings in title and description, > I think we can make it generic and can be used across few products. The bindings seems quite similar. We can have two drivers loaded using two compatible but binding description can be made same -- ~Vinod
Re: [PATCH v6 1/5] perf/jevents: Remove jevents.h file
On 8/31/20 2:13 PM, Jiri Olsa wrote:
> On Thu, Aug 27, 2020 at 06:39:54PM +0530, Kajol Jain wrote:
>> This patch removes jevents.h file and add its data inside
>> jevents.c as this file is only included there.
>>
>> Signed-off-by: Kajol Jain
>> ---
>> tools/perf/pmu-events/jevents.c | 9 -
>> tools/perf/pmu-events/jevents.h | 23 ---
>> 2 files changed, 8 insertions(+), 24 deletions(-)
>> delete mode 100644 tools/perf/pmu-events/jevents.h
>>
>> diff --git a/tools/perf/pmu-events/jevents.c
>> b/tools/perf/pmu-events/jevents.c
>> index fa86c5f997cc..1c55cc754b5a 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -48,11 +48,18 @@
>> #include
>> #include "jsmn.h"
>> #include "json.h"
>> -#include "jevents.h"
>>
>> int verbose;
>> char *prog;
>>
>> +#ifndef min
>> +#define min(x, y) ({\
>> +typeof(x) _min1 = (x); \
>> +typeof(y) _min2 = (y); \
>> +(void)(&_min1 == &_min2); \
>> +_min1 < _min2 ? _min1 : _min2; })
>> +#endif
>> +
>> int eprintf(int level, int var, const char *fmt, ...)
>> {
>>
>> diff --git a/tools/perf/pmu-events/jevents.h
>> b/tools/perf/pmu-events/jevents.h
>> deleted file mode 100644
>> index 2afc8304529e..
>> --- a/tools/perf/pmu-events/jevents.h
>> +++ /dev/null
>> @@ -1,23 +0,0 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> -#ifndef JEVENTS_H
>> -#define JEVENTS_H 1
>> -
>> -int json_events(const char *fn,
>> -int (*func)(void *data, char *name, char *event, char *desc,
>> -char *long_desc,
>> -char *pmu,
>> -char *unit, char *perpkg, char *metric_expr,
>> -char *metric_name, char *metric_group,
>> -char *deprecated, char *metric_constraint),
>> -void *data);
>> -char *get_cpu_str(void);
>
> I think you can also remove get_cpu_str from jevents.c
Hi Jiri,
Yes, I will check that part.
Thanks,
Kajol Jain
>
> thanks,
> jirka
>
Re: ERROR: "min_low_pfn" undefined!
On 8/31/20 10:41 PM, kernel test robot wrote: > Hi Arnd, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: b51594df17d0ce80b9f9f35394a1f42d7ac94472 > commit: 710ec38b0f633ab3e2581f07a73442d809e28ab0 mm: add dummy can_do_mlock() > helper > date: 11 months ago > config: microblaze-randconfig-r031-20200831 (attached as .config) > compiler: microblaze-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 710ec38b0f633ab3e2581f07a73442d809e28ab0 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=microblaze > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >>> ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! >ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined! Please test https://lore.kernel.org/lkml/20200829000110.2408-1-rdun...@infradead.org/ -- ~Randy
Re: [PATCH 5/6] Documentation: tracing: Add %return suffix description
On Tue, 1 Sep 2020 07:27:45 +0900 Masami Hiramatsu wrote: > On Mon, 31 Aug 2020 11:50:20 -0700 > Randy Dunlap wrote: > > > On 8/31/20 5:46 AM, Masami Hiramatsu wrote: > > > Add a description of the %return suffix option for kprobe tracer. > > > > > > Signed-off-by: Masami Hiramatsu > > > --- > > > Documentation/trace/kprobetrace.rst |2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/Documentation/trace/kprobetrace.rst > > > b/Documentation/trace/kprobetrace.rst > > > index c1709165c553..d29d1f9e6721 100644 > > > --- a/Documentation/trace/kprobetrace.rst > > > +++ b/Documentation/trace/kprobetrace.rst > > > > Check spacing: > > > > > @@ -37,6 +38,7 @@ Synopsis of kprobe_events > > > based on SYM+offs or MEMADDR. > > > MOD : Module name which has given SYM. > > > SYM[+offs] : Symbol+offset where the probe is inserted. > > > + SYM%return : Return address of the symbol > > > MEMADDR : Address where the probe is inserted. > > > MAXACTIVE : Maximum number of instances of the specified function > > > that > > > can be probed simultaneously, or 0 for the default value > > > > If I remove the '+', the ':' lines up but the SYM does not line up. > > Am I missing something? > > > > @@ -37,6 +38,7 @@ Synopsis of kprobe_events > > based on SYM+offs or MEMADDR. > > MOD : Module name which has given SYM. > > SYM[+offs]: Symbol+offset where the probe is inserted. > > SYM%return : Return address of the symbol > > MEMADDR : Address where the probe is inserted. > > MAXACTIVE : Maximum number of instances of the specified function that > > can be probed simultaneously, or 0 for the default value > > > Shouldn't we use the horizontal tab in .rst ? It seems other lines use a tab to indent, but this line doesn't (VIM converted the tab to spaces.) Thank you, -- Masami Hiramatsu
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Tue 01 Sep 03:42 UTC 2020, Rob Clark wrote:
> On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson
> wrote:
> >
> > On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> >
> > > From: Rob Clark
> > >
> > > Currently it doesn't matter, since we free the ctx immediately. But
> > > when we start refcnt'ing the ctx, we don't want old dangling list
> > > entries to hang around.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > > index a1d94be7883a..90c9d84e6155 100644
> > > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > > @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private
> > > *ctx)
> > >* No lock needed in close and there won't
> > >* be any more user ioctls coming our way
> > >*/
> > > - list_for_each_entry_safe(entry, tmp, >submitqueues, node)
> > > + list_for_each_entry_safe(entry, tmp, >submitqueues, node) {
> > > + list_del(>node);
> >
> > If you refcount ctx, what does that do for the entries in the submit
> > queue?
> >
> > "entry" here is kref'ed, but you're popping it off the list regardless
> > of the put ends up freeing the object or not - which afaict would mean
> > leaking the object.
> >
>
> What ends up happening is the submit has reference to submit-queue,
> which has reference to the ctx.. the submitqueue could be alive still
> pending in-flight submits (in a later patch), but dead from the PoV of
> userspace interface.
>
> We aren't relying (or at least aren't in the end, and I *think* I
> didn't miss anything in the middle) relying on ctx->submitqueues list
> to clean anything up in the end, just track what is still a valid
> submitqueue from userspace PoV
>
Looks reasonable, thanks for the explanation.
> BR,
> -R
>
> >
> > On the other hand, with the current implementation an object with higher
> > refcount with adjacent objects of single refcount would end up with
> > dangling pointers after the put. So in itself this change seems like a
> > net gain, but I'm wondering about the plan described in the commit
> > message.
> >
> > Regards,
> > Bjorn
> >
> > > msm_submitqueue_put(entry);
> > > + }
> > > }
> > >
> > > int msm_submitqueue_create(struct drm_device *drm, struct
> > > msm_file_private *ctx,
> > > --
> > > 2.26.2
> > >
ERROR: "min_low_pfn" undefined!
Hi Arnd, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b51594df17d0ce80b9f9f35394a1f42d7ac94472 commit: 710ec38b0f633ab3e2581f07a73442d809e28ab0 mm: add dummy can_do_mlock() helper date: 11 months ago config: microblaze-randconfig-r031-20200831 (attached as .config) compiler: microblaze-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 710ec38b0f633ab3e2581f07a73442d809e28ab0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=microblaze If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
> From: Rob Clark
>
> Currently it doesn't matter, since we free the ctx immediately. But
> when we start refcnt'ing the ctx, we don't want old dangling list
> entries to hang around.
>
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> b/drivers/gpu/drm/msm/msm_submitqueue.c
> index a1d94be7883a..90c9d84e6155 100644
> --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
>* No lock needed in close and there won't
>* be any more user ioctls coming our way
>*/
> - list_for_each_entry_safe(entry, tmp, >submitqueues, node)
> + list_for_each_entry_safe(entry, tmp, >submitqueues, node) {
> + list_del(>node);
> msm_submitqueue_put(entry);
> + }
> }
>
> int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> *ctx,
> --
> 2.26.2
>
Re: [PATCH v3 1/1] PCI/ERR: Fix reset logic in pcie_do_recovery() call
Hi Bjorn,
On 7/24/20 12:07 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
Current pcie_do_recovery() implementation has following two issues:
1. Fatal (DPC) error recovery is currently broken for non-hotplug
capable devices. Current fatal error recovery implementation relies
on PCIe hotplug (pciehp) handler for detaching and re-enumerating
the affected devices/drivers. pciehp handler listens for DLLSC state
changes and handles device/driver detachment on DLLSC_LINK_DOWN event
and re-enumeration on DLLSC_LINK_UP event. So when dealing with
non-hotplug capable devices, recovery code does not restore the state
of the affected devices correctly. Correct implementation should
restore the device state and call report_slot_reset() function after
resetting the link to restore the state of the device/driver.
You can find fatal non-hotplug related issues reported in following links:
https://lore.kernel.org/linux-pci/20200527083130.4137-1-zhiqiang@nxp.com/
https://lore.kernel.org/linux-pci/12115.1588207324@famine/
https://lore.kernel.org/linux-pci/0e6f89cd6b9e4a72293cc90fafe93487d7c2d295.158584.git.sathyanarayanan.kuppusw...@linux.intel.com/
2. For non-fatal errors if report_error_detected() or
report_mmio_enabled() functions requests PCI_ERS_RESULT_NEED_RESET then
current pcie_do_recovery() implementation does not do the requested
explicit device reset, instead just calls the report_slot_reset() on all
affected devices. Notifying about the reset via report_slot_reset()
without doing the actual device reset is incorrect.
To fix above issues, use PCI_ERS_RESULT_NEED_RESET as error state after
successful reset_link() operation. This will ensure ->slot_reset() be
called after reset_link() operation for fatal errors. Also call
pci_bus_reset() to do slot/bus reset() before triggering device specific
->slot_reset() callback. Also, using pci_bus_reset() will restore the state
of the devices after performing the reset operation.
Even though using pci_bus_reset() will do redundant reset operation after
->reset_link() for fatal errors, it should should affect the functional
behavior.
Any comment on this patch?
[original patch is from jay.vosbu...@canonical.com]
[original patch link https://lore.kernel.org/linux-pci/12115.1588207324@famine/]
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Jay Vosburgh
Signed-off-by: Kuppuswamy Sathyanarayanan
---
Changes since v2:
* Changed the subject of patch to "PCI/ERR: Fix reset logic in
pcie_do_recovery() call". v2 patch link is,
https://lore.kernel.org/linux-pci/ce417fbf81a8a46a89535f44b9224ee9fbb55a29.1591307288.git.sathyanarayanan.kuppusw...@linux.intel.com/
* Squashed "PCI/ERR: Add reset support for non fatal errors" patch.
drivers/pci/pcie/err.c | 41 +
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 14bb8f54723e..b5eb6ba65be1 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -165,8 +165,29 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, );
+ /*
+* After resetting the link using reset_link() call, the
+* possible value of error status is either
+* PCI_ERS_RESULT_DISCONNECT (failure case) or
+* PCI_ERS_RESULT_NEED_RESET (success case).
+* So ignore the return value of report_error_detected()
+* call for fatal errors.
+*
+* In EDR mode, since AER and DPC Capabilities are owned by
+* firmware, reported_error_detected() will return error
+* status PCI_ERS_RESULT_NO_AER_DRIVER. Continuing
+* pcie_do_recovery() with error status as
+* PCI_ERS_RESULT_NO_AER_DRIVER will report recovery failure
+* irrespective of recovery status. But successful reset_link()
+* call usually recovers all fatal errors. So ignoring the
+* status result of report_error_detected() also helps EDR based
+* error recovery.
+*/
status = reset_link(dev);
- if (status != PCI_ERS_RESULT_RECOVERED) {
+ if (status == PCI_ERS_RESULT_RECOVERED) {
+ status = PCI_ERS_RESULT_NEED_RESET;
+ } else {
+ status = PCI_ERS_RESULT_DISCONNECT;
pci_warn(dev, "link reset failed\n");
goto failed;
}
@@ -182,10 +203,22 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
if (status == PCI_ERS_RESULT_NEED_RESET) {
/*
-* TODO: Should call
Re: [RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev"
On 2020-08-31 22:38, Randy Dunlap wrote: > > --- linux-next-20200828.orig/Documentation/admin-guide/svga.rst > +++ linux-next-20200828/Documentation/admin-guide/svga.rst > @@ -12,7 +12,7 @@ Intro > This small document describes the "Video Mode Selection" feature which > allows the use of various special video modes supported by the video BIOS. > Due > to usage of the BIOS, the selection is limited to boot time (before the > -kernel decompression starts) and works only on 80X86 machines. > +kernel decompression starts) and works only on 32-bit 80X86 machines. > Incorrect. What controls if this is available is whether or not the kernel is booted through BIOS firmware (as opposed to UEFI, kexec, etc.) -hpa
[RFC PATCH 0/2] Documentation/admin-guide: remove use of "rdev"
Remove mention of using "rdev" to set boot device, video mode, or ramdisk information for the booting kernel. FIX patch 1/2 Subject: Cc: Karel Zak Cc: Paul Gortmaker Cc: Jens Axboe Cc: linux-bl...@vger.kernel.org Cc: Alexander Viro Cc: Martin Mares Cc: linux-vi...@atrey.karlin.mff.cuni.cz Cc: "H. Peter Anvin" Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org [RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev" [RFC PATCH 2/2] Documentation/admin-guide: blockdev/ramdisk: remove use of "rdev" Documentation/admin-guide/README.rst|6 - Documentation/admin-guide/blockdev/ramdisk.rst | 70 -- Documentation/admin-guide/kernel-parameters.txt |9 - Documentation/admin-guide/svga.rst |6 - 4 files changed, 33 insertions(+), 58 deletions(-)
[RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev"
"rdev" is considered antiquated, ancient, archaic, obsolete, deprecated
{choose any or all}.
Remove use of "rdev" and "vidmode" (a symlink to rdev) in
admin-guide/README.rst and admin-guide/svga.rst.
"rdev" was removed from util-linux in 2010:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=a3e40c14651fccf18e7954f081e601389baefe3f
Signed-off-by: Randy Dunlap
Cc: Karel Zak
Cc: Paul Gortmaker
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Cc: Alexander Viro
Cc: Martin Mares
Cc: linux-vi...@atrey.karlin.mff.cuni.cz
Cc: "H. Peter Anvin"
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
No email address for these:
nCc: Werner Almesberger
nCc: Stephen Tweedie
nCc: Peter MacDonald
Documentation/admin-guide/README.rst |6 +++---
Documentation/admin-guide/svga.rst |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--- linux-next-20200828.orig/Documentation/admin-guide/README.rst
+++ linux-next-20200828/Documentation/admin-guide/README.rst
@@ -322,9 +322,9 @@ Compiling the kernel
reboot, and enjoy!
If you ever need to change the default root device, video mode,
- ramdisk size, etc. in the kernel image, use the ``rdev`` program (or
- alternatively the LILO boot options when appropriate). No need to
- recompile the kernel to change these parameters.
+ etc. in the kernel image, use your bootloader's boot options
+ where appropriate. No need to recompile the kernel to change
+ these parameters.
- Reboot with the new kernel and enjoy.
--- linux-next-20200828.orig/Documentation/admin-guide/svga.rst
+++ linux-next-20200828/Documentation/admin-guide/svga.rst
@@ -12,7 +12,7 @@ Intro
This small document describes the "Video Mode Selection" feature which
allows the use of various special video modes supported by the video BIOS. Due
to usage of the BIOS, the selection is limited to boot time (before the
-kernel decompression starts) and works only on 80X86 machines.
+kernel decompression starts) and works only on 32-bit 80X86 machines.
.. note::
@@ -23,7 +23,7 @@ kernel decompression starts) and works o
The video mode to be used is selected by a kernel parameter which can be
specified in the kernel Makefile (the SVGA_MODE=... line) or by the "vga=..."
-option of LILO (or some other boot loader you use) or by the "vidmode" utility
+option of LILO (or some other boot loader you use) or by the "xrandr" utility
(present in standard Linux utility packages). You can use the following values
of this parameter::
@@ -41,7 +41,7 @@ of this parameter::
better to use absolute mode numbers instead.
0x - Hexadecimal video mode ID (also displayed on the menu, see below
- for exact meaning of the ID). Warning: rdev and LILO don't support
+ for exact meaning of the ID). Warning: LILO doesn't support
hexadecimal numbers -- you have to convert it to decimal manually.
Menu
[RFC PATCH 2/2] Documentation/admin-guide: blockdev/ramdisk: remove use of "rdev"
Remove use of "rdev" from blockdev/ramdisk.rst and update
admin-guide/kernel-parameters.txt.
"rdev" is considered antiquated, ancient, archaic, obsolete, deprecated
{choose any or all}.
"rdev" was removed from util-linux in 2010:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=a3e40c14651fccf18e7954f081e601389baefe3f
Signed-off-by: Randy Dunlap
Cc: Karel Zak
Cc: Paul Gortmaker
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Cc: Alexander Viro
Cc: Martin Mares
Cc: linux-vi...@atrey.karlin.mff.cuni.cz
Cc: "H. Peter Anvin"
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
No email address for these:
nCc: Werner Almesberger
nCc: Stephen Tweedie
nCc: Peter MacDonald
Documentation/admin-guide/blockdev/ramdisk.rst | 70 --
Documentation/admin-guide/kernel-parameters.txt |9 -
2 files changed, 27 insertions(+), 52 deletions(-)
--- linux-next-20200828.orig/Documentation/admin-guide/blockdev/ramdisk.rst
+++ linux-next-20200828/Documentation/admin-guide/blockdev/ramdisk.rst
@@ -6,7 +6,7 @@ Using the RAM disk block device with Lin
1) Overview
2) Kernel Command Line Parameters
- 3) Using "rdev -r"
+ 3) Using "rdev"
4) An Example of Creating a Compressed RAM Disk
@@ -59,51 +59,27 @@ default is 4096 (4 MB).
rd_size
See ramdisk_size.
-3) Using "rdev -r"
---
+3) Using "rdev"
+---
-The usage of the word (two bytes) that "rdev -r" sets in the kernel image is
-as follows. The low 11 bits (0 -> 10) specify an offset (in 1 k blocks) of up
-to 2 MB (2^11) of where to find the RAM disk (this used to be the size). Bit
-14 indicates that a RAM disk is to be loaded, and bit 15 indicates whether a
-prompt/wait sequence is to be given before trying to read the RAM disk. Since
-the RAM disk dynamically grows as data is being written into it, a size field
-is not required. Bits 11 to 13 are not currently used and may as well be zero.
-These numbers are no magical secrets, as seen below::
-
- ./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF
- ./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000
- ./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG0x4000
-
-Consider a typical two floppy disk setup, where you will have the
-kernel on disk one, and have already put a RAM disk image onto disk #2.
-
-Hence you want to set bits 0 to 13 as 0, meaning that your RAM disk
-starts at an offset of 0 kB from the beginning of the floppy.
-The command line equivalent is: "ramdisk_start=0"
-
-You want bit 14 as one, indicating that a RAM disk is to be loaded.
-The command line equivalent is: "load_ramdisk=1"
-
-You want bit 15 as one, indicating that you want a prompt/keypress
-sequence so that you have a chance to switch floppy disks.
-The command line equivalent is: "prompt_ramdisk=1"
-
-Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
-So to create disk one of the set, you would do::
-
- /usr/src/linux# cat arch/x86/boot/zImage > /dev/fd0
- /usr/src/linux# rdev /dev/fd0 /dev/fd0
- /usr/src/linux# rdev -r /dev/fd0 49152
+"rdev" is an obsolete, deprecated, antiquated utility that could be used
+to set the boot device in a Linux kernel image.
-If you make a boot disk that has LILO, then for the above, you would use::
+Instead of using rdev, just place the boot device information on the
+kernel command line and pass it to the kernel from the bootloader.
+
+You can also pass arguments to the kernel by setting FDARGS in
+arch/x86/boot/Makefile and specify in initrd image by setting FDINITRD in
+arch/x86/boot/Makefile.
- append = "ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1"
+Some of the kernel command line boot options that may apply here are::
-Since the default start = 0 and the default prompt = 1, you could use::
+ ramdisk_start=N
+ ramdisk_size=M
- append = "load_ramdisk=1"
+If you make a boot disk that has LILO, then for the above, you would use::
+ append = "ramdisk_start=N ramdisk_size=M"
4) An Example of Creating a Compressed RAM Disk
---
@@ -151,12 +127,9 @@ f) Put the RAM disk image onto the flopp
dd if=/tmp/ram_image.gz of=/dev/fd0 bs=1k seek=400
-g) Use "rdev" to set the boot device, RAM disk offset, prompt flag, etc.
- For prompt_ramdisk=1, load_ramdisk=1, ramdisk_start=400, one would
- have 2^15 + 2^14 + 400 = 49552::
-
- rdev /dev/fd0 /dev/fd0
- rdev -r /dev/fd0 49552
+g) Make sure that you have already specified the boot information in
+ FDARGS and FDINITRD or that you use a bootloader to pass kernel
+ command line boot options to the kernel.
That is it. You now have your boot/root compressed RAM disk floppy. Some
users may wish to combine steps (d) and (f) by using a pipe.
@@ -167,11 +140,14 @@ users may wish to combine steps (d) and
Changelog:
--
+09-2020 :
Re: [PATCH] Documentation/x86/boot.rst: minor improvement
If you are going to fix the language... On 2020-08-31 22:25, Cao jin wrote: > Sorry, I mis-copied 2 addresses. make sure they are CCed. > > On 9/1/20 11:41 AM, Cao jin wrote: >> Typo fix & file name update >> >> Signed-off-by: Cao jin >> --- >> Documentation/x86/boot.rst | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst >> index 7fafc7ac00d7..c04afec90486 100644 >> --- a/Documentation/x86/boot.rst >> +++ b/Documentation/x86/boot.rst >> @@ -1379,7 +1379,7 @@ can be calculated as follows:: >> In addition to read/modify/write the setup header of the struct >> boot_params as that of 16-bit boot protocol, the boot loader should >> also fill the additional fields of the struct boot_params as described >> -in zero-page.txt. >> +in zero-page.rst. >> >> After setting up the struct boot_params, the boot loader can load >> 64-bit kernel in the same way as that of 16-bit boot protocol, but >> @@ -1391,7 +1391,7 @@ In 64-bit boot protocol, the kernel is started by >> jumping to the >> >> At entry, the CPU must be in 64-bit mode with paging enabled. (Paging enabled is redundant here.) >> The range with setup_header.init_size from start address of loaded >> -kernel and zero page and command line buffer get ident mapping; >> +kernel and zero page and command line buffer get identity mapping; The range with setup_header.init_size from start address of the loaded kernel, the zero page, and the command line buffer get identity-mapped, anda GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18): both descriptors must be 4G flat segment with __BOOT_CS having execute/read permission and __BOOT_DS... Also, it might be useful to take a look to see if other data structures, like setup_data and the initrd also need to be in the identity map. -hpa
Re: [PATCH 19/19] drm/msm: show process names in gem_describe
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> In $debugfs/gem we already show any vma(s) associated with an object.
> Also show process names if the vma's address space is a per-process
> address space.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 25 +
> drivers/gpu/drm/msm/msm_gem.h | 5 +
> drivers/gpu/drm/msm/msm_gem_vma.c | 1 +
> drivers/gpu/drm/msm/msm_gpu.c | 8 +---
> drivers/gpu/drm/msm/msm_gpu.h | 2 +-
> 6 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 8e70d220bba8..8d5c4f98c332 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -597,7 +597,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> kref_init(>ref);
> msm_submitqueue_init(dev, ctx);
>
> - ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
> + ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
> file->driver_priv = ctx;
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 3cb7aeb93fd3..76a6c5271e57 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -842,11 +842,28 @@ void msm_gem_describe(struct drm_gem_object *obj,
> struct seq_file *m)
>
> seq_puts(m, " vmas:");
>
> - list_for_each_entry(vma, _obj->vmas, list)
> - seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
> - vma->aspace != NULL ? vma->aspace->name : NULL,
> - vma->iova, vma->mapped ? "mapped" : "unmapped",
> + list_for_each_entry(vma, _obj->vmas, list) {
> + const char *name, *comm;
> + if (vma->aspace) {
> + struct msm_gem_address_space *aspace =
> vma->aspace;
> + struct task_struct *task =
> + get_pid_task(aspace->pid, PIDTYPE_PID);
> + if (task) {
> + comm = kstrdup(task->comm, GFP_KERNEL);
> + } else {
> + comm = NULL;
> + }
> + name = aspace->name;
> + } else {
> + name = comm = NULL;
> + }
> + seq_printf(m, " [%s%s%s: aspace=%p,
> %08llx,%s,inuse=%d]",
> + name, comm ? ":" : "", comm ? comm : "",
> + vma->aspace, vma->iova,
> + vma->mapped ? "mapped" : "unmapped",
> vma->inuse);
> + kfree(comm);
> + }
>
> seq_puts(m, "\n");
> }
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 9c573c4269cb..7b1c7a5f8eef 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -24,6 +24,11 @@ struct msm_gem_address_space {
> spinlock_t lock; /* Protects drm_mm node allocation/removal */
> struct msm_mmu *mmu;
> struct kref kref;
> +
> + /* For address spaces associated with a specific process, this
> + * will be non-NULL:
> + */
> + struct pid *pid;
> };
>
> struct msm_gem_vma {
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
> b/drivers/gpu/drm/msm/msm_gem_vma.c
> index 29cc1305cf37..80a8a266d68f 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -17,6 +17,7 @@ msm_gem_address_space_destroy(struct kref *kref)
> drm_mm_takedown(>mm);
> if (aspace->mmu)
> aspace->mmu->funcs->destroy(aspace->mmu);
> + put_pid(aspace->pid);
> kfree(aspace);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 951850804d77..ac8961187a73 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -825,10 +825,9 @@ static int get_clocks(struct platform_device *pdev,
> struct msm_gpu *gpu)
>
> /* Return a new address space for a msm_drm_private instance */
> struct msm_gem_address_space *
> -msm_gpu_create_private_address_space(struct msm_gpu *gpu)
> +msm_gpu_create_private_address_space(struct msm_gpu *gpu, struct task_struct
> *task)
> {
> struct msm_gem_address_space *aspace = NULL;
> -
> if (!gpu)
> return NULL;
>
> @@ -836,8 +835,11 @@ msm_gpu_create_private_address_space(struct msm_gpu *gpu)
>* If the target doesn't support private address spaces then return
>* the global one
>*/
> - if (gpu->funcs->create_private_address_space)
>
Re: [PATCH 04/11] block: Add bio_for_each_thp_segment_all
On Mon, Aug 31, 2020 at 08:48:37PM +0100, Matthew Wilcox wrote:
> static void iomap_read_end_io(struct bio *bio)
> {
> int i, error = blk_status_to_errno(bio->bi_status);
>
> for (i = 0; i < bio->bi_vcnt; i++) {
> struct bio_vec *bvec = >bi_io_vec[i];
This should probably use bio_for_each_bvec_all instead of directly
poking into the bio. I'd also be tempted to move the loop body into
a separate helper, but that's just a slight stylistic preference.
> size_t offset = bvec->bv_offset;
> size_t length = bvec->bv_len;
> struct page *page = bvec->bv_page;
>
> while (length > 0) {
> size_t count = thp_size(page) - offset;
>
> if (count > length)
> count = length;
> iomap_read_page_end_io(page, offset, count, error);
> page += (offset + count) / PAGE_SIZE;
Shouldn't the page_size here be thp_size?
> Maybe I'm missing something important here, but it's significantly
> simpler code -- iomap_read_end_io() goes down from 816 bytes to 560 bytes
> (256 bytes less!) iomap_read_page_end_io is inlined into it both before
> and after.
Yes, that's exactly why I think avoiding bio_for_each_segment_all is
a good idea in general.
> There is some weirdness going on with regards to bv_offset that I don't
> quite understand. In the original bvec_advance:
>
> bv->bv_page = bvec->bv_page + (bvec->bv_offset >> PAGE_SHIFT);
> bv->bv_offset = bvec->bv_offset & ~PAGE_MASK;
>
> which I cargo-culted into bvec_thp_advance as:
>
> bv->bv_page = thp_head(bvec->bv_page +
> (bvec->bv_offset >> PAGE_SHIFT));
> page_size = thp_size(bv->bv_page);
> bv->bv_offset = bvec->bv_offset -
> (bv->bv_page - bvec->bv_page) * PAGE_SIZE;
>
> Is it possible to have a bvec with an offset that is larger than the
> size of bv_page? That doesn't seem like a useful thing to do, but
> if that needs to be supported, then the code up top doesn't do that.
> We maybe gain a little bit by counting length down to 0 instead of
> counting it up to bv_len. I dunno; reading the code over now, it
> doesn't seem like that much of a difference.
Drivers can absolutely see a bv_offset that is larger due to bio
splitting. However the submitting file system should never see one
unless it creates one, which would be stupid.
And yes, eventually bv_page and bv_offset should be replaced with a
phys_addr_t bv_phys;
and life would become simpler in many places (and the bvec would
shrink for most common setups as well).
For now I'd end up with something like:
static void iomap_read_end_bvec(struct page *page, size_t offset,
size_t length, int error)
{
while (length > 0) {
size_t page_size = thp_size(page);
size_t count = min(page_size - offset, length);
iomap_read_page_end_io(page, offset, count, error);
page += (offset + count) / page_size;
length -= count;
offset = 0;
}
}
static void iomap_read_end_io(struct bio *bio)
{
int i, error = blk_status_to_errno(bio->bi_status);
struct bio_vec *bvec;
bio_for_each_bvec_all(bvec, bio, i)
iomap_read_end_bvec(bvec->bv_page, bvec->bv_offset,
bvec->bv_len, error;
bio_put(bio);
}
and maybe even merge iomap_read_page_end_io into iomap_read_end_bvec.
Re: [PATCH 18/19] iommu/arm-smmu: add a way for implementations to influence SCTLR
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
> pending translations are not terminated on iova fault. Otherwise
> a terminated CP read could hang the GPU by returning invalid
> command-stream data.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 ++
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 +++
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 +++
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 5640d9960610..2aa6249050ff 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -127,6 +127,12 @@ static int qcom_adreno_smmu_init_context(struct
> arm_smmu_domain *smmu_domain,
> (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64))
> pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_ARM_TTBR1;
>
> + /*
> + * On the GPU device we want to process subsequent transactions after a
> + * fault to keep the GPU from hanging
> + */
> + smmu_domain->cfg.sctlr_set |= ARM_SMMU_SCTLR_HUPCF;
> +
> /*
>* Initialize private interface with GPU:
>*/
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index e63a480d7f71..bbec5793faf8 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -617,6 +617,9 @@ void arm_smmu_write_context_bank(struct arm_smmu_device
> *smmu, int idx)
> if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> reg |= ARM_SMMU_SCTLR_E;
>
> + reg |= cfg->sctlr_set;
> + reg &= ~cfg->sctlr_clr;
> +
> arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, reg);
> }
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index cd75a33967bb..2df3a70a8a41 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -144,6 +144,7 @@ enum arm_smmu_cbar_type {
> #define ARM_SMMU_CB_SCTLR0x0
> #define ARM_SMMU_SCTLR_S1_ASIDPNEBIT(12)
> #define ARM_SMMU_SCTLR_CFCFG BIT(7)
> +#define ARM_SMMU_SCTLR_HUPCF BIT(8)
> #define ARM_SMMU_SCTLR_CFIE BIT(6)
> #define ARM_SMMU_SCTLR_CFRE BIT(5)
> #define ARM_SMMU_SCTLR_E BIT(4)
> @@ -341,6 +342,8 @@ struct arm_smmu_cfg {
> u16 asid;
> u16 vmid;
> };
> + u32 sctlr_set;/* extra bits to set in
> SCTLR */
> + u32 sctlr_clr;/* bits to mask in SCTLR
> */
> enum arm_smmu_cbar_type cbar;
> enum arm_smmu_context_fmt fmt;
> };
> --
> 2.26.2
>
Re: [PATCH] Documentation: kunit: Add naming guidelines
On Tue, Sep 1, 2020 at 7:47 AM Kees Cook wrote: > > On Fri, Aug 28, 2020 at 12:17:05AM +0800, David Gow wrote: > > On Thu, Aug 27, 2020 at 9:14 PM Marco Elver wrote: > > > Just an idea: Maybe the names are also an opportunity to distinguish > > > real _unit_ style tests and then the rarer integration-style tests. I > > > personally prefer using the more generic *-test.c, at least for the > > > integration-style tests I've been working on (KUnit is still incredibly > > > valuable for integration-style tests, because otherwise I'd have to roll > > > my own poor-man's version of KUnit, so thank you!). Using *_kunit.c for > > > such tests is unintuitive, because the word "unit" hints at "unit tests" > > > -- and having descriptive (and not misleading) filenames is still > > > important. So I hope you won't mind if *-test.c are still used where > > > appropriate. > > This is a good point, and I guess not one that has really been examined. > I'm not sure what to think of some of the lib/ tests. test_user_copy > seems to be a "unit" test -- it's validating the function family vs > all kinds of arguments and conditions. But test_overflow is less unit > and more integration, which includes "do all of these allocators end up > acting the same way?" etc > > I'm not really sure what to make of that -- I don't really have a formal > testing background. > I'm not sure we need a super-precise definition here (maybe just because I don't have one), and really just need to work out what distinctions are actually useful. For example, I'm not sure there's any real advantage to treating test_user_copy and test_overflow differently. The KCSAN tests which spawn lots of threads and are both slower and less deterministic seem more obviously different, though. I guess there are two audiences to cater for: 1. Test authors, who may wish to have both unit-style and integration-style tests, and want to distinguish them. They probably have the best idea of where the line should be drawn for their subsystems, and may have some existing style/nomenclature. 2. People running "all tests", who want to broadly understand how the whole suite of tests will behave (e.g., how long they'll take to run, are they possibly nondeterministic, are there weird hardware/software dependencies). This is where some more standardisation probably makes sense. I'm not 100% the file/module name is the best place to make these distinctions (given that it's the Kconfig entries that are at least our current way of finding and running tests). An off-the-wall idea would be to have a flags field in the test suite structure to note things like "large/long-running test" or "nondeterministic", and have either a KUnit option to bypass them, note them in the output, or even something terrifying like parsing it out of a compiled module. > > As Brendan alluded to in the talk, the popularity of KUnit for these > > integration-style tests came as something of a surprise (more due to > > our lack of imagination than anything else, I suspect). It's great > > that it's working, though: I don't think anyone wants the world filled > > with more single-use test "frameworks" than is necessary! > > > > I guess the interesting thing to note is that we've to date not really > > made a distinction between KUnit the framework and the suite of all > > KUnit tests. Maybe having a separate file/module naming scheme could > > be a way of making that distinction, though it'd really only appear > > when loading tests as modules -- there'd be no indication in e.g., > > suite names or test results. The more obvious solution to me (at > > least, based on the current proposal) would be to have "integration" > > or similar be part of the suite name (and hence the filename, so > > _integration_kunit.c or similar), though even I admit that that's much > > uglier. Maybe the idea of having the subsystem/suite distinction be > > represented in the code could pave the way to having different suites > > support different suffixes like that. > > Heh, yeah, let's not call them "_integration_kunit.c" ;) _behavior.c? > _integration.c? > I think we'd really like something that says more strongly that this is a test (which is I suspect one of the reasons why _kunit.c has its detractors: it doesn't have the word "test" in it). The other thing to consider is that if there are multiple tests for the same thing (e.g., a unit test suite and an integration test suite), they'd still need separate, non-conflicting suite names if we wanted them to be able to be present in the same kernel. Maybe the right thing to do is to say that, for now, the _kunit.c naming guideline only applies to "unit-style" tests. > > Do you know of any cases where something has/would have both > > unit-style tests and integration-style tests built with KUnit where > > the distinction needs to be clear? > > This is probably the right question. :) > I had a quick look, and we don't appear to have anything quite like this yet, at least
Re: [PATCH 15/19] drm/msm: Add support for private address space instances
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add support for allocating private address space instances. Targets that
> support per-context pagetables should implement their own function to
> allocate private address spaces.
>
> The default will return a pointer to the global address space.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 13 +++--
> drivers/gpu/drm/msm/msm_drv.h | 5 +
> drivers/gpu/drm/msm/msm_gem_vma.c | 9 +
> drivers/gpu/drm/msm/msm_gpu.c | 22 ++
> drivers/gpu/drm/msm/msm_gpu.h | 5 +
> 5 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 01845a3b8d52..8e70d220bba8 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -597,7 +597,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> kref_init(>ref);
> msm_submitqueue_init(dev, ctx);
>
> - ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
> + ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
> file->driver_priv = ctx;
>
> return 0;
> @@ -780,18 +780,19 @@ static int msm_ioctl_gem_cpu_fini(struct drm_device
> *dev, void *data,
> }
>
> static int msm_ioctl_gem_info_iova(struct drm_device *dev,
> - struct drm_gem_object *obj, uint64_t *iova)
> + struct drm_file *file, struct drm_gem_object *obj,
> + uint64_t *iova)
> {
> - struct msm_drm_private *priv = dev->dev_private;
> + struct msm_file_private *ctx = file->driver_priv;
>
> - if (!priv->gpu)
> + if (!ctx->aspace)
> return -EINVAL;
>
> /*
>* Don't pin the memory here - just get an address so that userspace can
>* be productive
>*/
> - return msm_gem_get_iova(obj, priv->gpu->aspace, iova);
> + return msm_gem_get_iova(obj, ctx->aspace, iova);
> }
>
> static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
> @@ -830,7 +831,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev,
> void *data,
> args->value = msm_gem_mmap_offset(obj);
> break;
> case MSM_INFO_GET_IOVA:
> - ret = msm_ioctl_gem_info_iova(dev, obj, >value);
> + ret = msm_ioctl_gem_info_iova(dev, file, obj, >value);
> break;
> case MSM_INFO_SET_NAME:
> /* length check should leave room for terminating null: */
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 4561bfb5e745..2ca9c3c03845 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -249,6 +249,10 @@ int msm_gem_map_vma(struct msm_gem_address_space *aspace,
> void msm_gem_close_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma);
>
> +
> +struct msm_gem_address_space *
> +msm_gem_address_space_get(struct msm_gem_address_space *aspace);
> +
> void msm_gem_address_space_put(struct msm_gem_address_space *aspace);
>
> struct msm_gem_address_space *
> @@ -434,6 +438,7 @@ static inline void __msm_file_private_destroy(struct kref
> *kref)
> struct msm_file_private *ctx = container_of(kref,
> struct msm_file_private, ref);
>
> + msm_gem_address_space_put(ctx->aspace);
> kfree(ctx);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
> b/drivers/gpu/drm/msm/msm_gem_vma.c
> index 5f6a11211b64..29cc1305cf37 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -27,6 +27,15 @@ void msm_gem_address_space_put(struct
> msm_gem_address_space *aspace)
> kref_put(>kref, msm_gem_address_space_destroy);
> }
>
> +struct msm_gem_address_space *
> +msm_gem_address_space_get(struct msm_gem_address_space *aspace)
> +{
> + if (!IS_ERR_OR_NULL(aspace))
> + kref_get(>kref);
> +
> + return aspace;
> +}
> +
> /* Actually unmap memory for the vma */
> void msm_gem_purge_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma)
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index e1a3cbe25a0c..951850804d77 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -823,6 +823,28 @@ static int get_clocks(struct platform_device *pdev,
> struct msm_gpu *gpu)
> return 0;
> }
>
> +/* Return a new address space for a msm_drm_private instance */
> +struct msm_gem_address_space *
> +msm_gpu_create_private_address_space(struct msm_gpu *gpu)
> +{
> + struct msm_gem_address_space *aspace = NULL;
> +
> + if (!gpu)
> + return NULL;
> +
> + /*
> + * If the target doesn't support private address spaces then return
> + * the global one
> + */
> + if
[PATCH v11] Fixup for "powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32"
Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/vdso/gettimeofday.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h index 59a609a48b63..8da84722729b 100644 --- a/arch/powerpc/include/asm/vdso/gettimeofday.h +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h @@ -186,6 +186,8 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct __kernel_timespec *res, #else int __c_kernel_clock_gettime(clockid_t clock, struct old_timespec32 *ts, const struct vdso_data *vd); +int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts, + const struct vdso_data *vd); int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res, const struct vdso_data *vd); #endif -- 2.25.0
Re: [PATCH 14/19] drm/msm: Add support to create a local pagetable
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add support to create a io-pgtable for use by targets that support
> per-instance pagetables. In order to support per-instance pagetables the
> GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
> split pagetables enabled.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpummu.c | 2 +-
> drivers/gpu/drm/msm/msm_iommu.c | 199 ++-
> drivers/gpu/drm/msm/msm_mmu.h| 16 ++-
> 3 files changed, 214 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpummu.c
> b/drivers/gpu/drm/msm/msm_gpummu.c
> index 310a31b05faa..aab121f4beb7 100644
> --- a/drivers/gpu/drm/msm/msm_gpummu.c
> +++ b/drivers/gpu/drm/msm/msm_gpummu.c
> @@ -102,7 +102,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct
> msm_gpu *gpu)
> }
>
> gpummu->gpu = gpu;
> - msm_mmu_init(>base, dev, );
> + msm_mmu_init(>base, dev, , MSM_MMU_GPUMMU);
>
> return >base;
> }
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 1b6635504069..697cc0a059d6 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -4,15 +4,210 @@
> * Author: Rob Clark
> */
>
> +#include
> +#include
> #include "msm_drv.h"
> #include "msm_mmu.h"
>
> struct msm_iommu {
> struct msm_mmu base;
> struct iommu_domain *domain;
> + atomic_t pagetables;
> };
> +
> #define to_msm_iommu(x) container_of(x, struct msm_iommu, base)
>
> +struct msm_iommu_pagetable {
> + struct msm_mmu base;
> + struct msm_mmu *parent;
> + struct io_pgtable_ops *pgtbl_ops;
> + phys_addr_t ttbr;
> + u32 asid;
> +};
> +static struct msm_iommu_pagetable *to_pagetable(struct msm_mmu *mmu)
> +{
> + return container_of(mmu, struct msm_iommu_pagetable, base);
> +}
> +
> +static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova,
> + size_t size)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + size_t unmapped = 0;
> +
> + /* Unmap the block one page at a time */
> + while (size) {
> + unmapped += ops->unmap(ops, iova, 4096, NULL);
> + iova += 4096;
> + size -= 4096;
> + }
> +
> + iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> +
> + return (unmapped == size) ? 0 : -EINVAL;
> +}
> +
> +static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 iova,
> + struct sg_table *sgt, size_t len, int prot)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + struct scatterlist *sg;
> + size_t mapped = 0;
> + u64 addr = iova;
> + unsigned int i;
> +
> + for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> + size_t size = sg->length;
> + phys_addr_t phys = sg_phys(sg);
> +
> + /* Map the block one page at a time */
> + while (size) {
> + if (ops->map(ops, addr, phys, 4096, prot, GFP_KERNEL)) {
> + msm_iommu_pagetable_unmap(mmu, iova, mapped);
> + return -EINVAL;
> + }
> +
> + phys += 4096;
> + addr += 4096;
> + size -= 4096;
> + mapped += 4096;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void msm_iommu_pagetable_destroy(struct msm_mmu *mmu)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct msm_iommu *iommu = to_msm_iommu(pagetable->parent);
> + struct adreno_smmu_priv *adreno_smmu =
> + dev_get_drvdata(pagetable->parent->dev);
> +
> + /*
> + * If this is the last attached pagetable for the parent,
> + * disable TTBR0 in the arm-smmu driver
> + */
> + if (atomic_dec_return(>pagetables) == 0)
> + adreno_smmu->set_ttbr0_cfg(adreno_smmu->cookie, NULL);
> +
> + free_io_pgtable_ops(pagetable->pgtbl_ops);
> + kfree(pagetable);
> +}
> +
> +int msm_iommu_pagetable_params(struct msm_mmu *mmu,
> + phys_addr_t *ttbr, int *asid)
> +{
> + struct msm_iommu_pagetable *pagetable;
> +
> + if (mmu->type != MSM_MMU_IOMMU_PAGETABLE)
> + return -EINVAL;
> +
> + pagetable = to_pagetable(mmu);
> +
> + if (ttbr)
> + *ttbr = pagetable->ttbr;
> +
> + if (asid)
> + *asid = pagetable->asid;
> +
> + return 0;
> +}
> +
> +static const struct msm_mmu_funcs pagetable_funcs = {
> + .map = msm_iommu_pagetable_map,
> + .unmap = msm_iommu_pagetable_unmap,
> + .destroy = msm_iommu_pagetable_destroy,
> +};
> +
> +static void
Re: [PATCH v2 00/28] The new cgroup slab memory controller
On Fri, Aug 28, 2020 at 12:47:03PM -0400, Pavel Tatashin wrote:
> There appears to be another problem that is related to the
> cgroup_mutex -> mem_hotplug_lock deadlock described above.
>
> In the original deadlock that I described, the workaround is to
> replace crash dump from piping to Linux traditional save to files
> method. However, after trying this workaround, I still observed
> hardware watchdog resets during machine shutdown.
>
> The new problem occurs for the following reason: upon shutdown systemd
> calls a service that hot-removes memory, and if hot-removing fails for
> some reason systemd kills that service after timeout. However, systemd
> is never able to kill the service, and we get hardware reset caused by
> watchdog or a hang during shutdown:
>
> Thread #1: memory hot-remove systemd service
> Loops indefinitely, because if there is something still to be migrated
> this loop never terminates. However, this loop can be terminated via
> signal from systemd after timeout.
> __offline_pages()
> do {
> pfn = scan_movable_pages(pfn, end_pfn);
> # Returns 0, meaning there is nothing available to
> # migrate, no page is PageLRU(page)
> ...
> ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn,
> NULL, check_pages_isolated_cb);
> # Returns -EBUSY, meaning there is at least one PFN that
> # still has to be migrated.
> } while (ret);
>
> Thread #2: ccs killer kthread
>css_killed_work_fn
> cgroup_mutex <- Grab this Mutex
> mem_cgroup_css_offline
>memcg_offline_kmem.part
> memcg_deactivate_kmem_caches
> get_online_mems
> mem_hotplug_lock <- waits for Thread#1 to get read access
>
> Thread #3: systemd
> ksys_read
> vfs_read
>__vfs_read
> seq_read
>proc_single_show
> proc_cgroup_show
>mutex_lock -> wait for cgroup_mutex that is owned by Thread #2
>
> Thus, thread #3 systemd stuck, and unable to deliver timeout interrupt
> to thread #1.
>
> The proper fix for both of the problems is to avoid cgroup_mutex ->
> mem_hotplug_lock ordering that was recently fixed in the mainline but
> still present in all stable branches. Unfortunately, I do not see a
> simple fix in how to remove mem_hotplug_lock from
> memcg_deactivate_kmem_caches without using Roman's series that is too
> big for stable.
We too are seeing this on Power systems when stress-testing memory
hotplug, but with the following call trace (from hung task timer)
instead of Thread #2 above:
__switch_to
__schedule
schedule
percpu_rwsem_wait
__percpu_down_read
get_online_mems
memcg_create_kmem_cache
memcg_kmem_cache_create_func
process_one_work
worker_thread
kthread
ret_from_kernel_thread
While I understand that Roman's new slab controller patchset will fix
this, I also wonder if infinitely looping in the memory unplug path
with mem_hotplug_lock held is the right thing to do? Earlier we had
a few other exit possibilities in this path (like max retries etc)
but those were removed by commits:
72b39cfc4d75: mm, memory_hotplug: do not fail offlining too early
ecde0f3e7f9e: mm, memory_hotplug: remove timeout from __offline_memory
Or, is the user-space test is expected to induce a signal back-off when
unplug doesn't complete within a reasonable amount of time?
Regards,
Bharata.
Re: [PATCH] Documentation/x86/boot.rst: minor improvement
Sorry, I mis-copied 2 addresses. make sure they are CCed. On 9/1/20 11:41 AM, Cao jin wrote: > Typo fix & file name update > > Signed-off-by: Cao jin > --- > Documentation/x86/boot.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > index 7fafc7ac00d7..c04afec90486 100644 > --- a/Documentation/x86/boot.rst > +++ b/Documentation/x86/boot.rst > @@ -1379,7 +1379,7 @@ can be calculated as follows:: > In addition to read/modify/write the setup header of the struct > boot_params as that of 16-bit boot protocol, the boot loader should > also fill the additional fields of the struct boot_params as described > -in zero-page.txt. > +in zero-page.rst. > > After setting up the struct boot_params, the boot loader can load > 64-bit kernel in the same way as that of 16-bit boot protocol, but > @@ -1391,7 +1391,7 @@ In 64-bit boot protocol, the kernel is started by > jumping to the > > At entry, the CPU must be in 64-bit mode with paging enabled. > The range with setup_header.init_size from start address of loaded > -kernel and zero page and command line buffer get ident mapping; > +kernel and zero page and command line buffer get identity mapping; > a GDT must be loaded with the descriptors for selectors > __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat > segment; __BOOT_CS must have execute/read permission, and __BOOT_DS > -- Sincerely, Cao jin
Re: [RFC PATCH 00/22] Enhance VHOST to enable SoC-to-SoC communication
Hi, On 28/08/20 4:04 pm, Cornelia Huck wrote: On Thu, 9 Jul 2020 14:26:53 +0800 Jason Wang wrote: [Let me note right at the beginning that I first noted this while listening to Kishon's talk at LPC on Wednesday. I might be very confused about the background here, so let me apologize beforehand for any confusion I might spread.] On 2020/7/8 下午9:13, Kishon Vijay Abraham I wrote: Hi Jason, On 7/8/2020 4:52 PM, Jason Wang wrote: On 2020/7/7 下午10:45, Kishon Vijay Abraham I wrote: Hi Jason, On 7/7/2020 3:17 PM, Jason Wang wrote: On 2020/7/6 下午5:32, Kishon Vijay Abraham I wrote: Hi Jason, On 7/3/2020 12:46 PM, Jason Wang wrote: On 2020/7/2 下午9:35, Kishon Vijay Abraham I wrote: Hi Jason, On 7/2/2020 3:40 PM, Jason Wang wrote: On 2020/7/2 下午5:51, Michael S. Tsirkin wrote: On Thu, Jul 02, 2020 at 01:51:21PM +0530, Kishon Vijay Abraham I wrote: This series enhances Linux Vhost support to enable SoC-to-SoC communication over MMIO. This series enables rpmsg communication between two SoCs using both PCIe RC<->EP and HOST1-NTB-HOST2 1) Modify vhost to use standard Linux driver model 2) Add support in vring to access virtqueue over MMIO 3) Add vhost client driver for rpmsg 4) Add PCIe RC driver (uses virtio) and PCIe EP driver (uses vhost) for rpmsg communication between two SoCs connected to each other 5) Add NTB Virtio driver and NTB Vhost driver for rpmsg communication between two SoCs connected via NTB 6) Add configfs to configure the components UseCase1 : VHOST RPMSG VIRTIO RPMSG + + | | | | | | | | +-v--+ +--v---+ | Linux | | Linux | | Endpoint | | Root Complex | | <-> | | | | | | SOC1 | | SOC2 | ++ +--+ UseCase 2: VHOST RPMSG VIRTIO RPMSG + + | | | | | | | | +--v--+ +--v--+ | | | | | HOST1 | | HOST2 | | | | | +--^--+ +--^--+ | | | | +-+ | +--v--+ +--v--+ | | | | | | | | | EP | | EP | | | | CONTROLLER1 | | CONTROLLER2 | | | | <---> | | | | | | | | | | | | | | | | | SoC With Multiple EP Instances | | | | | | (Configured using NTB Function) | | | | +-+ +-+ | +-+ First of all, to clarify the terminology: Is "vhost rpmsg" acting as what the virtio standard calls the 'device', and "virtio rpmsg" as the 'driver'? Or is the "vhost" part mostly just Right, vhost_rpmsg is 'device' and virtio_rpmsg is 'driver'. virtqueues + the exiting vhost interfaces? It's implemented to provide the full 'device' functionality. Software Layering: The high-level SW layering should look something like below. This series adds support only for RPMSG VHOST, however something similar should be done for net and scsi. With that any vhost device (PCI, NTB, Platform device, user) can use any of the vhost client driver. ++ +---+ ++ +--+ | RPMSG VHOST | | NET VHOST | | SCSI VHOST | | X | +---^+ +-^-+ +-^--+ +^-+ | | | | | | | | | | |
Re: [PATCH 13/19] drm/msm: Set the global virtual address range from the IOMMU domain
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Use the aperture settings from the IOMMU domain to set up the virtual
> address range for the GPU. This allows us to transparently deal with
> IOMMU side features (like split pagetables).
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
> drivers/gpu/drm/msm/msm_iommu.c | 7 +++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 533a34b4cce2..34e6242c1767 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
> struct msm_mmu *mmu = msm_iommu_new(>dev, iommu);
> struct msm_gem_address_space *aspace;
> + u64 start, size;
>
> - aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> - 0x - SZ_16M);
> + /*
> + * Use the aperture start or SZ_16M, whichever is greater. This will
> + * ensure that we align with the allocated pagetable range while still
> + * allowing room in the lower 32 bits for GMEM and whatnot
> + */
> + start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
> + size = iommu->geometry.aperture_end - start + 1;
> +
> + aspace = msm_gem_address_space_create(mmu, "gpu",
> + start & GENMASK(48, 0), size);
>
> if (IS_ERR(aspace) && !IS_ERR(mmu))
> mmu->funcs->destroy(mmu);
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 3a381a9674c9..1b6635504069 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t
> iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> + /* The arm-smmu driver expects the addresses to be sign extended */
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> WARN_ON(!ret);
>
> @@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t
> iova, size_t len)
> {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> iommu_unmap(iommu->domain, iova, len);
>
> return 0;
> --
> 2.26.2
>
Re: [PATCH v4] iomap: fix WARN_ON_ONCE() from unprivileged users
On Mon, Aug 31, 2020 at 02:23:53PM -0400, Qian Cai wrote: > It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by > unprivileged users which would taint the kernel, or worse - panic if > panic_on_warn or panic_on_taint is set. Hence, just convert it to > pr_warn_ratelimited() to let users know their workloads are racing. > Thank Dave Chinner for the initial analysis of the racing reproducers. > > Signed-off-by: Qian Cai Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 2/2] mm/migrate: preserve soft dirty in remove_migration_pte()
On Mon, Aug 31, 2020 at 02:22:22PM -0700, Ralph Campbell wrote: > The code to remove a migration PTE and replace it with a device private > PTE was not copying the soft dirty bit from the migration entry. > This could lead to page contents not being marked dirty when faulting > the page back from device private memory. > > Signed-off-by: Ralph Campbell Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 1/2] mm/migrate: remove unnecessary is_zone_device_page() check
Looks good: Reviewed-by: Christoph Hellwig
Re: [PATCH v3 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile
Hi Konstantin, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.9-rc3 next-20200828] [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/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20200828-224323 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 15bc20c6af4ceee97a1f90b43c0e386643c071b4 config: powerpc-allyesconfig (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> powerpc64-linux-ld: fs/ntfs3/file.o:(.opd+0x1f8): multiple definition of >> `ntfs_setattr'; fs/ntfs/inode.o:(.opd+0x1b0): first defined here powerpc64-linux-ld: fs/ntfs3/file.o: in function `.ntfs_setattr': >> file.c:(.text.ntfs_setattr+0x0): multiple definition of `.ntfs_setattr'; >> fs/ntfs/inode.o:inode.c:(.text.ntfs_setattr+0x0): first defined here --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [RFC PATCH v7 08/23] sched: Add core wide task selection and scheduling.
On Sat, Aug 29, 2020 at 09:47:19AM +0200, pet...@infradead.org wrote:
> On Fri, Aug 28, 2020 at 06:02:25PM -0400, Vineeth Pillai wrote:
> > On 8/28/20 4:51 PM, Peter Zijlstra wrote:
>
> > > So where do things go side-ways?
>
> > During hotplug stress test, we have noticed that while a sibling is in
> > pick_next_task, another sibling can go offline or come online. What
> > we have observed is smt_mask get updated underneath us even if
> > we hold the lock. From reading the code, looks like we don't hold the
> > rq lock when the mask is updated. This extra logic was to take care of that.
>
> Sure, the mask is updated async, but _where_ is the actual problem with
> that?
Hi Peter,
I tried again and came up with the simple patch below which handles all
issues and does not cause any more crashes. I added elaborate commit messages
and code comments enlisting all the issues. Hope it makes sense now. IMHO any
other solutions seems unclear or overhead. The simple solution below Just
Works (Tm) and does not add overhead.
Let me know what you think, thanks.
---8<---
>From 546c5b48f372111589117f51fd79ac1e9493c7e7 Mon Sep 17 00:00:00 2001
From: "Joel Fernandes (Google)"
Date: Tue, 1 Sep 2020 00:56:36 -0400
Subject: [PATCH] sched/core: Hotplug fixes to pick_next_task()
The follow 3 cases need to be handled to avoid crashes in pick_next_task() when
CPUs in a core are going offline or coming online.
1. The stopper task is switching into idle when it is brought down by CPU
hotplug. It is not in the cpu_smt_mask so nothing need be selected for it.
Further, the current code ends up not selecting anything for it, not even idle.
This ends up causing crashes in set_next_task(). Just do the __pick_next_task()
selection which will select the idle task. No need to do core-wide selection as
other siblings will handle it for themselves when they call schedule.
2. The rq->core_pick for a sibling in a core can be NULL if no selection was
made for it because it was either offline or went offline during a sibling's
core-wide selection. In this case, do a core-wide selection. In this case, we
have to completely ignore the checks:
if (rq->core->core_pick_seq == rq->core->core_task_seq &&
rq->core->core_pick_seq != rq->core_sched_seq)
Otherwise, it would again end up crashing like #1.
3. The 'Rescheduling siblings' loop of pick_next_task() is quite fragile. It
calls various functions on rq->core_pick which could very well be NULL because:
An online sibling might have gone offline before a task could be picked for it,
or it might be offline but later happen to come online, but its too late and
nothing was picked for it. Just ignore the siblings for which nothing could be
picked. This avoids any crashes that may occur in this loop that assume
rq->core_pick is not NULL.
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/core.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 717122a3dca1..4966e9f14f39 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4610,13 +4610,24 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
if (!sched_core_enabled(rq))
return __pick_next_task(rq, prev, rf);
+ cpu = cpu_of(rq);
+
+ /* Stopper task is switching into idle, no need core-wide selection. */
+ if (cpu_is_offline(cpu))
+ return __pick_next_task(rq, prev, rf);
+
/*
* If there were no {en,de}queues since we picked (IOW, the task
* pointers are all still valid), and we haven't scheduled the last
* pick yet, do so now.
+*
+* rq->core_pick can be NULL if no selection was made for a CPU because
+* it was either offline or went offline during a sibling's core-wide
+* selection. In this case, do a core-wide selection.
*/
if (rq->core->core_pick_seq == rq->core->core_task_seq &&
- rq->core->core_pick_seq != rq->core_sched_seq) {
+ rq->core->core_pick_seq != rq->core_sched_seq &&
+ !rq->core_pick) {
WRITE_ONCE(rq->core_sched_seq, rq->core->core_pick_seq);
next = rq->core_pick;
@@ -4629,7 +4640,6 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
put_prev_task_balance(rq, prev, rf);
- cpu = cpu_of(rq);
smt_mask = cpu_smt_mask(cpu);
/*
@@ -4761,7 +4771,15 @@ next_class:;
for_each_cpu(i, smt_mask) {
struct rq *rq_i = cpu_rq(i);
- WARN_ON_ONCE(!rq_i->core_pick);
+ /*
+* An online sibling might have gone offline before a task
+* could be picked for it, or it might be offline but later
+* happen to come online, but its too late and nothing was
+* picked for it. That's Ok - it will pick tasks
Re: [PATCH 12/19] drm/msm: Drop context arg to gpu->submit()
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Now that we can get the ctx from the submitqueue, the extra arg is
> redundant.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Jordan Crouse
> [split out of previous patch to reduce churny noise]
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 +--
> drivers/gpu/drm/msm/msm_gem_submit.c| 2 +-
> drivers/gpu/drm/msm/msm_gpu.c | 9 -
> drivers/gpu/drm/msm/msm_gpu.h | 6 ++
> 7 files changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 9e63a190642c..eff2439ea57b 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -43,8 +43,7 @@ static void a5xx_flush(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
> }
>
> -static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit)
> {
> struct msm_drm_private *priv = gpu->dev->dev_private;
> struct msm_ringbuffer *ring = submit->ring;
> @@ -57,7 +56,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> @@ -103,8 +102,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> msm_gpu_retire(gpu);
> }
>
> -static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
> @@ -114,7 +112,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>
> if (IS_ENABLED(CONFIG_DRM_MSM_GPU_SUDO) && submit->in_rb) {
> priv->lastctx = NULL;
> - a5xx_submit_in_rb(gpu, submit, ctx);
> + a5xx_submit_in_rb(gpu, submit);
> return;
> }
>
> @@ -148,7 +146,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index c5a3e4d4c007..5eabb0109577 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -81,8 +81,7 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
> }
>
> -static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
> struct msm_drm_private *priv = gpu->dev->dev_private;
> @@ -115,7 +114,7 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index d2dbb6968cba..533a34b4cce2 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -457,8 +457,7 @@ void adreno_recover(struct msm_gpu *gpu)
> }
> }
>
> -void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu =
Re: [PATCH 11/19] drm/msm: Add a context pointer to the submitqueue
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Each submitqueue is attached to a context. Add a pointer to the
> context to the submitqueue at create time and refcount it so
> that it stays around through the life of the queue.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Rob Clark
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> drivers/gpu/drm/msm/msm_drv.h | 20
> drivers/gpu/drm/msm/msm_gem.h | 1 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 6 +++---
> drivers/gpu/drm/msm/msm_gpu.h | 1 +
> drivers/gpu/drm/msm/msm_submitqueue.c | 3 +++
> 6 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 7d641c7e3514..01845a3b8d52 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -594,6 +594,7 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> if (!ctx)
> return -ENOMEM;
>
> + kref_init(>ref);
> msm_submitqueue_init(dev, ctx);
>
> ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
> @@ -615,7 +616,7 @@ static int msm_open(struct drm_device *dev, struct
> drm_file *file)
> static void context_close(struct msm_file_private *ctx)
> {
> msm_submitqueue_close(ctx);
> - kfree(ctx);
> + msm_file_private_put(ctx);
> }
>
> static void msm_postclose(struct drm_device *dev, struct drm_file *file)
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index af259b0573ea..4561bfb5e745 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -57,6 +57,7 @@ struct msm_file_private {
> struct list_head submitqueues;
> int queueid;
> struct msm_gem_address_space *aspace;
> + struct kref ref;
> };
>
> enum msm_mdp_plane_property {
> @@ -428,6 +429,25 @@ void msm_submitqueue_close(struct msm_file_private *ctx);
>
> void msm_submitqueue_destroy(struct kref *kref);
>
> +static inline void __msm_file_private_destroy(struct kref *kref)
> +{
> + struct msm_file_private *ctx = container_of(kref,
> + struct msm_file_private, ref);
> +
> + kfree(ctx);
> +}
> +
> +static inline void msm_file_private_put(struct msm_file_private *ctx)
> +{
> + kref_put(>ref, __msm_file_private_destroy);
> +}
> +
> +static inline struct msm_file_private *msm_file_private_get(
> + struct msm_file_private *ctx)
> +{
> + kref_get(>ref);
> + return ctx;
> +}
>
> #define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> #define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 972490b14ba5..9c573c4269cb 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -142,6 +142,7 @@ struct msm_gem_submit {
> bool valid; /* true if no cmdstream patching needed */
> bool in_rb; /* "sudo" mode, copy cmds into RB */
> struct msm_ringbuffer *ring;
> + struct msm_file_private *ctx;
> unsigned int nr_cmds;
> unsigned int nr_bos;
> u32 ident; /* A "identifier" for the submit for logging */
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 8cb9aa15ff90..1464b04d25d3 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -27,7 +27,7 @@
> #define BO_PINNED 0x2000
>
> static struct msm_gem_submit *submit_create(struct drm_device *dev,
> - struct msm_gpu *gpu, struct msm_gem_address_space *aspace,
> + struct msm_gpu *gpu,
> struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
> uint32_t nr_cmds)
> {
> @@ -43,7 +43,7 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return NULL;
>
> submit->dev = dev;
> - submit->aspace = aspace;
> + submit->aspace = queue->ctx->aspace;
> submit->gpu = gpu;
> submit->fence = NULL;
> submit->cmd = (void *)>bos[nr_bos];
> @@ -677,7 +677,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> }
> }
>
> - submit = submit_create(dev, gpu, ctx->aspace, queue, args->nr_bos,
> + submit = submit_create(dev, gpu, queue, args->nr_bos,
> args->nr_cmds);
> if (!submit) {
> ret = -ENOMEM;
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index f91b141add75..97c527e98391 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -190,6 +190,7 @@ struct msm_gpu_submitqueue {
> u32 flags;
> u32 prio;
> int faults;
> + struct msm_file_private *ctx;
> struct list_head node;
> struct kref ref;
>
Re: [PATCH 10/19] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote: > From: Jordan Crouse > > Every Qcom Adreno GPU has an embedded SMMU for its own use. These > devices depend on unique features such as split pagetables, > different stall/halt requirements and other settings. Identify them > with a compatible string so that they can be identified in the > arm-smmu implementation specific code. > Reviewed-by: Bjorn Andersson > Signed-off-by: Jordan Crouse > Reviewed-by: Rob Herring > Signed-off-by: Rob Clark > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > index 503160a7b9a0..5ec5d0d691f6 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > @@ -40,6 +40,10 @@ properties: >- qcom,sm8150-smmu-500 >- qcom,sm8250-smmu-500 >- const: arm,mmu-500 > + - description: Qcom Adreno GPUs implementing "arm,smmu-v2" > +items: > + - const: qcom,adreno-smmu > + - const: qcom,smmu-v2 >- description: Marvell SoCs implementing "arm,mmu-500" > items: >- const: marvell,ap806-smmu-500 > -- > 2.26.2 >
[PATCH 1/2] usb: serial: option: Fix the lackage for Quectel EG95 LTE modem support
* Add reset-resume callback for resetting USB devices after MCU exits
from suspend/sleep mode.
* Because Quectel EG95 uses USB interface 4 as a USB network device, so
return from option_startup() to prevent being used as a USB serial
device.
Fixes: da6902e5b6db ("USB: serial: option: add Quectel EG95 LTE modem"
Signed-off-by: William Sung
---
drivers/usb/serial/option.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 89b3192af326..9de8aec47e5e 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2069,6 +2069,7 @@ static struct usb_serial_driver option_1port_device = {
#ifdef CONFIG_PM
.suspend = usb_wwan_suspend,
.resume= usb_wwan_resume,
+ .reset_resume = usb_wwan_resume,
#endif
};
@@ -2104,6 +2105,11 @@ static int option_probe(struct usb_serial *serial,
if (device_flags & NUMEP2 && iface_desc->bNumEndpoints != 2)
return -ENODEV;
+ /* Quectel EC25 & EC21 & EG91 & EG95 ... interface 4 can be used as USB
network device */
+ if (serial->dev->descriptor.idVendor == cpu_to_le16(0x2c7c) &&
+ serial->interface->cur_altsetting->desc.bInterfaceNumber >= 4)
+ return -ENODEV;
+
/* Store the device flags so we can use them during attach. */
usb_set_serial_data(serial, (void *)device_flags);
--
2.17.1
[PATCH 2/2] usb: serial: usb_wwan: Fix lackage for Quectel EG95 LTE modem support
As required by the USB protocol, add zero packet support for Quectel
EG95 LTE modem module.
Fixes: f815dd5cf48b ("net: usb: qmi_wwan: add support for Quectel EG95
LTE modem"
Signed-off-by: William Sung
---
drivers/usb/serial/usb_wwan.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index 4b9845807bee..75495c939ac6 100644
--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -467,6 +467,7 @@ static struct urb *usb_wwan_setup_urb(struct
usb_serial_port *port,
struct usb_serial *serial = port->serial;
struct usb_wwan_intf_private *intfdata = usb_get_serial_data(serial);
struct urb *urb;
+ struct usb_device_descriptor *desc = >dev->descriptor;
urb = usb_alloc_urb(0, GFP_KERNEL); /* No ISO */
if (!urb)
@@ -476,8 +477,15 @@ static struct urb *usb_wwan_setup_urb(struct
usb_serial_port *port,
usb_sndbulkpipe(serial->dev, endpoint) | dir,
buf, len, callback, ctx);
- if (intfdata->use_zlp && dir == USB_DIR_OUT)
- urb->transfer_flags |= URB_ZERO_PACKET;
+ if (dir == USB_DIR_OUT) {
+ if (intfdata->use_zlp)
+ urb->transfer_flags |= URB_ZERO_PACKET;
+
+ /* Add zero packet support for Quectel EG95 */
+ if (desc->idVendor == cpu_to_le16(0x2C7C) &&
+ desc->idProduct == cpu_to_le16(0x0195))
+ urb->transfer_flags |= URB_ZERO_PACKET;
+ }
return urb;
}
--
2.17.1
Re: [PATCH 09/19] iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Add a special implementation for the SMMU attached to most Adreno GPU
> target triggered from the qcom,adreno-smmu compatible string.
>
> The new Adreno SMMU implementation will enable split pagetables
> (TTBR1) for the domain attached to the GPU device (SID 0) and
> hard code it context bank 0 so the GPU hardware can implement
> per-instance pagetables.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Rob Clark
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 +
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 149 -
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
> 3 files changed, 151 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index 88f17cc33023..d199b4bff15d 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -223,6 +223,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
> arm_smmu_device *smmu)
> of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
> return qcom_smmu_impl_init(smmu);
>
> + if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
> + return qcom_adreno_smmu_impl_init(smmu);
> +
> if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
> smmu->impl = _mmu500_impl;
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index be4318044f96..5640d9960610 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> */
>
> +#include
> #include
> #include
>
> @@ -12,6 +13,132 @@ struct qcom_smmu {
> struct arm_smmu_device smmu;
> };
>
> +#define QCOM_ADRENO_SMMU_GPU_SID 0
> +
> +static bool qcom_adreno_smmu_is_gpu_device(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> + int i;
> +
> + /*
> + * The GPU will always use SID 0 so that is a handy way to uniquely
> + * identify it and configure it for per-instance pagetables
> + */
> + for (i = 0; i < fwspec->num_ids; i++) {
> + u16 sid = FIELD_GET(ARM_SMMU_SMR_ID, fwspec->ids[i]);
> +
> + if (sid == QCOM_ADRENO_SMMU_GPU_SID)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static const struct io_pgtable_cfg *qcom_adreno_smmu_get_ttbr1_cfg(
> + const void *cookie)
> +{
> + struct arm_smmu_domain *smmu_domain = (void *)cookie;
> + struct io_pgtable *pgtable =
> + io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> + return >cfg;
> +}
> +
> +/*
> + * Local implementation to configure TTBR0 with the specified pagetable
> config.
> + * The GPU driver will call this to enable TTBR0 when per-instance pagetables
> + * are active
> + */
> +
> +static int qcom_adreno_smmu_set_ttbr0_cfg(const void *cookie,
> + const struct io_pgtable_cfg *pgtbl_cfg)
> +{
> + struct arm_smmu_domain *smmu_domain = (void *)cookie;
> + struct io_pgtable *pgtable =
> io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> + struct arm_smmu_cfg *cfg = _domain->cfg;
> + struct arm_smmu_cb *cb = _domain->smmu->cbs[cfg->cbndx];
> +
> + /* The domain must have split pagetables already enabled */
> + if (cb->tcr[0] & ARM_SMMU_TCR_EPD1)
> + return -EINVAL;
> +
> + /* If the pagetable config is NULL, disable TTBR0 */
> + if (!pgtbl_cfg) {
> + /* Do nothing if it is already disabled */
> + if ((cb->tcr[0] & ARM_SMMU_TCR_EPD0))
> + return -EINVAL;
> +
> + /* Set TCR to the original configuration */
> + cb->tcr[0] = arm_smmu_lpae_tcr(>cfg);
> + cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
> + } else {
> + u32 tcr = cb->tcr[0];
> +
> + /* Don't call this again if TTBR0 is already enabled */
> + if (!(cb->tcr[0] & ARM_SMMU_TCR_EPD0))
> + return -EINVAL;
> +
> + tcr |= arm_smmu_lpae_tcr(pgtbl_cfg);
> + tcr &= ~(ARM_SMMU_TCR_EPD0 | ARM_SMMU_TCR_EPD1);
> +
> + cb->tcr[0] = tcr;
> + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
> + }
> +
> + arm_smmu_write_context_bank(smmu_domain->smmu, cb->cfg->cbndx);
> +
> + return 0;
> +}
> +
> +static int qcom_adreno_smmu_alloc_context_bank(struct arm_smmu_domain
> *smmu_domain,
> + struct device *dev, int start, int count)
> +{
> + struct arm_smmu_device *smmu = smmu_domain->smmu;
> +
> + /*
> + *
RE: [PATCH v7 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
> -Original Message-
> From: Vinod Koul
> Sent: Monday, August 31, 2020 5:10 PM
> To: Wan Mohamad, Wan Ahmad Zainie
>
> Cc: kis...@ti.com; robh...@kernel.org; Shevchenko, Andriy
> ; eswara.k...@linux.intel.com;
> vadivel.muruganx.ramuthe...@linux.intel.com; Raja Subramanian, Lakshmi
> Bai ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC
> PHY bindings
>
> On 21-08-20, 19:37, Wan Ahmad Zainie wrote:
> > Binding description for Intel Keem Bay eMMC PHY.
> >
> > Signed-off-by: Wan Ahmad Zainie
> >
> > Reviewed-by: Rob Herring
> > ---
> > .../bindings/phy/intel,keembay-emmc-phy.yaml | 44
> > +++
> > 1 file changed, 44 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-
> phy.yaml
> > b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-
> phy.yaml
> > new file mode 100644
> > index ..4cbbd3887c13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-
> phy.yam
> > +++ l
> > @@ -0,0 +1,44 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-
> phy.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Intel Keem Bay eMMC PHY bindings
>
> This seems same as
> Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml, why
> not add a new compatible in lgm binding, or did I miss a difference?
AFAIK, LGM make use of syscon node, whilst KMB does not.
And LGM and KMB belongs to different SoC family. So, I prefer them to
be in separate file.
Having said that, with few changes in wordings in title and description,
I think we can make it generic and can be used across few products.
>
> > +
> > +maintainers:
> > + - Wan Ahmad Zainie
> > +
> > +properties:
> > + compatible:
> > +const: intel,keembay-emmc-phy
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +maxItems: 1
> > +
> > + clock-names:
> > +items:
> > + - const: emmcclk
> > +
> > + "#phy-cells":
> > +const: 0
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#phy-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +phy@2029 {
> > + compatible = "intel,keembay-emmc-phy";
> > + reg = <0x2029 0x54>;
> > + clocks = <>;
> > + clock-names = "emmcclk";
> > + #phy-cells = <0>;
> > +};
> > --
> > 2.17.1
>
> --
> ~Vinod
Re: [PATCH v2 7/7] compiler-gcc: improve version error
On Mon, Aug 31, 2020 at 05:23:26PM -0700, Nick Desaulniers wrote:
> As Kees suggests, do so provides developers with two useful pieces of
> information:
> - The kernel build was attempting to use GCC.
> (Maybe they accidentally poked the wrong configs in a CI.)
> - They need 4.9 or better.
> ("Upgrade to what version?" doesn't need to be dug out of documentation,
>headers, etc.)
>
> Suggested-by: Kees Cook
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
It would be nice if there was some easy way to link the documentation
here so that patches like commit 0bddd227f3dc ("Documentation: update
for gcc 4.9 requirement") did not need to happen or be remembered.
> ---
> include/linux/compiler-gcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 7a3769040d7d..d1e3c6896b71 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -12,7 +12,7 @@
>
> /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
> #if GCC_VERSION < 40900
> -# error Sorry, your compiler is too old - please upgrade it.
> +# error Sorry, your version of GCC is too old - please use 4.9 or newer.
> #endif
>
> /* Optimization barrier */
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
Re: [PATCH v2 6/7] kasan: Remove mentions of unsupported Clang versions
On Mon, Aug 31, 2020 at 05:23:25PM -0700, Nick Desaulniers wrote: > From: Marco Elver > > Since the kernel now requires at least Clang 10.0.1, remove any mention > of old Clang versions and simplify the documentation. > > Reviewed-by: Andrey Konovalov > Signed-off-by: Marco Elver > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > Documentation/dev-tools/kasan.rst | 4 ++-- > lib/Kconfig.kasan | 9 - > 2 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/Documentation/dev-tools/kasan.rst > b/Documentation/dev-tools/kasan.rst > index 38fd5681fade..4abc84b1798c 100644 > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -13,10 +13,10 @@ KASAN uses compile-time instrumentation to insert > validity checks before every > memory access, and therefore requires a compiler version that supports that. > > Generic KASAN is supported in both GCC and Clang. With GCC it requires > version > -8.3.0 or later. With Clang it requires version 7.0.0 or later, but detection > of > +8.3.0 or later. Any supported Clang version is compatible, but detection of > out-of-bounds accesses for global variables is only supported since Clang 11. > > -Tag-based KASAN is only supported in Clang and requires version 7.0.0 or > later. > +Tag-based KASAN is only supported in Clang. > > Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and > riscv architectures, and tag-based KASAN is supported only for arm64. > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index 047b53dbfd58..033a5bc67ac4 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -54,9 +54,9 @@ config KASAN_GENERIC > Enables generic KASAN mode. > > This mode is supported in both GCC and Clang. With GCC it requires > - version 8.3.0 or later. With Clang it requires version 7.0.0 or > - later, but detection of out-of-bounds accesses for global variables > - is supported only since Clang 11. > + version 8.3.0 or later. Any supported Clang version is compatible, > + but detection of out-of-bounds accesses for global variables is > + supported only since Clang 11. > > This mode consumes about 1/8th of available memory at kernel start > and introduces an overhead of ~x1.5 for the rest of the allocations. > @@ -78,8 +78,7 @@ config KASAN_SW_TAGS > Enables software tag-based KASAN mode. > > This mode requires Top Byte Ignore support by the CPU and therefore > - is only supported for arm64. This mode requires Clang version 7.0.0 > - or later. > + is only supported for arm64. This mode requires Clang. > > This mode consumes about 1/16th of available memory at kernel start > and introduces an overhead of ~20% for the rest of the allocations. > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH 07/19] drm/msm: set adreno_smmu as gpu's drvdata
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> This will be populated by adreno-smmu, to provide a way for coordinating
> enabling/disabling TTBR0 translation.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 --
> drivers/gpu/drm/msm/msm_gpu.c | 2 +-
> drivers/gpu/drm/msm/msm_gpu.h | 6 +-
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 26664e1b30c0..58e03b20e1c7 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -417,8 +417,6 @@ static int adreno_bind(struct device *dev, struct device
> *master, void *data)
> return PTR_ERR(gpu);
> }
>
> - dev_set_drvdata(dev, gpu);
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 6aa9e04e52e7..806eb0957280 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -892,7 +892,7 @@ int msm_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> gpu->gpu_cx = NULL;
>
> gpu->pdev = pdev;
> - platform_set_drvdata(pdev, gpu);
> + platform_set_drvdata(pdev, >adreno_smmu);
>
> msm_devfreq_init(gpu);
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 8bda7beaed4b..f91b141add75 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -7,6 +7,7 @@
> #ifndef __MSM_GPU_H__
> #define __MSM_GPU_H__
>
> +#include
> #include
> #include
> #include
> @@ -73,6 +74,8 @@ struct msm_gpu {
> struct platform_device *pdev;
> const struct msm_gpu_funcs *funcs;
>
> + struct adreno_smmu_priv adreno_smmu;
> +
> /* performance counters (hw & sw): */
> spinlock_t perf_lock;
> bool perfcntr_active;
> @@ -143,7 +146,8 @@ struct msm_gpu {
>
> static inline struct msm_gpu *dev_to_gpu(struct device *dev)
> {
> - return dev_get_drvdata(dev);
> + struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(dev);
> + return container_of(adreno_smmu, struct msm_gpu, adreno_smmu);
> }
>
> /* It turns out that all targets use the same ringbuffer size */
> --
> 2.26.2
>
Re: [PATCH v2 5/7] Partial revert "ARM: 8905/1: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer"
Nit: Partially in commit message? On Mon, Aug 31, 2020 at 05:23:24PM -0700, Nick Desaulniers wrote: > This partially reverts commit b0fe66cf095016e0b238374c10ae366e1f087d11. > > The minimum supported version of clang is now clang 10.0.1. We still > want to pass -meabi=gnu. Thank you for calling this out. > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 82c197a248dd..09a7669eea1d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -83,7 +83,7 @@ config ARM > select HAVE_FAST_GUP if ARM_LPAE > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL > select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG > - select HAVE_FUNCTION_TRACER if !XIP_KERNEL && (CC_IS_GCC || > CLANG_VERSION >= 10) > + select HAVE_FUNCTION_TRACER if !XIP_KERNEL > select HAVE_GCC_PLUGINS > select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || > CPU_V7) > select HAVE_IDE if PCI || ISA || PCMCIA > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH v2 4/7] Revert "arm64: vdso: Fix compilation with clang older than 8"
On Mon, Aug 31, 2020 at 05:23:23PM -0700, Nick Desaulniers wrote: > This reverts commit 3acf4be235280f14d838581a750532219d67facc. > > The minimum supported version of clang is clang 10.0.1. > > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/arm64/kernel/vdso/Makefile | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile > index 45d5cfe46429..04021a93171c 100644 > --- a/arch/arm64/kernel/vdso/Makefile > +++ b/arch/arm64/kernel/vdso/Makefile > @@ -43,13 +43,6 @@ ifneq ($(c-gettimeofday-y),) >CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y) > endif > > -# Clang versions less than 8 do not support -mcmodel=tiny > -ifeq ($(CONFIG_CC_IS_CLANG), y) > - ifeq ($(shell test $(CONFIG_CLANG_VERSION) -lt 8; echo $$?),0) > -CFLAGS_REMOVE_vgettimeofday.o += -mcmodel=tiny > - endif > -endif > - > # Disable gcov profiling for VDSO code > GCOV_PROFILE := n > > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH v2 3/7] Revert "arm64: bti: Require clang >= 10.0.1 for in-kernel BTI support"
On Mon, Aug 31, 2020 at 05:23:22PM -0700, Nick Desaulniers wrote: > This reverts commit b9249cba25a5dce5de87e5404503a5e11832c2dd. > > The minimum supported version of clang is now 10.0.1. > > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/arm64/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 6d232837cbee..2a70b85b1a61 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1630,8 +1630,6 @@ config ARM64_BTI_KERNEL > depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697 > depends on !CC_IS_GCC || GCC_VERSION >= 100100 > - # https://reviews.llvm.org/rGb8ae3fdfa579dbf366b1bb1cbfdbf8c51db7fa55 > - depends on !CC_IS_CLANG || CLANG_VERSION >= 11 > depends on !(CC_IS_CLANG && GCOV_KERNEL) > depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS) > help > -- > 2.28.0.402.g5ffc5be6b7-goog >
Re: [PATCH 08/19] iommu/arm-smmu: constify some helpers
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> Sprinkle a few `const`s where helpers don't need write access.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 59ff3fc5c6c8..27c8fc50 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -377,7 +377,7 @@ struct arm_smmu_master_cfg {
> s16 smendx[];
> };
>
> -static inline u32 arm_smmu_lpae_tcr(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_tcr(const struct io_pgtable_cfg *cfg)
> {
> u32 tcr = FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> @@ -398,13 +398,13 @@ static inline u32 arm_smmu_lpae_tcr(struct
> io_pgtable_cfg *cfg)
> return tcr;
> }
>
> -static inline u32 arm_smmu_lpae_tcr2(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_tcr2(const struct io_pgtable_cfg *cfg)
> {
> return FIELD_PREP(ARM_SMMU_TCR2_PASIZE, cfg->arm_lpae_s1_cfg.tcr.ips) |
> FIELD_PREP(ARM_SMMU_TCR2_SEP, ARM_SMMU_TCR2_SEP_UPSTREAM);
> }
>
> -static inline u32 arm_smmu_lpae_vtcr(struct io_pgtable_cfg *cfg)
> +static inline u32 arm_smmu_lpae_vtcr(const struct io_pgtable_cfg *cfg)
> {
> return ARM_SMMU_VTCR_RES1 |
> FIELD_PREP(ARM_SMMU_VTCR_PS, cfg->arm_lpae_s2_cfg.vtcr.ps) |
> --
> 2.26.2
>
Re: [PATCH v2 2/7] Revert "kbuild: disable clang's default use of -fmerge-all-constants"
On Mon, Aug 31, 2020 at 05:23:21PM -0700, Nick Desaulniers wrote: > This reverts commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79. > > This was fixed in clang-6; the minimum supported version of clang in the > kernel is clang-10 (10.0.1). > > Link: https://reviews.llvm.org/rL329300. > Link: https://github.com/ClangBuiltLinux/linux/issues/9 > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > Makefile | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/Makefile b/Makefile > index 37739ee53f27..144ac6a073ff 100644 > --- a/Makefile > +++ b/Makefile > @@ -932,15 +932,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning, > maybe-uninitialized) > # disable invalid "can't wrap" optimizations for signed / pointers > KBUILD_CFLAGS+= $(call cc-option,-fno-strict-overflow) > > -# clang sets -fmerge-all-constants by default as optimization, but this > -# is non-conforming behavior for C and in fact breaks the kernel, so we > -# need to disable it here generally. > -KBUILD_CFLAGS+= $(call cc-option,-fno-merge-all-constants) > - > -# for gcc -fno-merge-all-constants disables everything, but it is fine > -# to have actual conforming behavior enabled. > -KBUILD_CFLAGS+= $(call cc-option,-fmerge-constants) > - > # Make sure -fstack-check isn't enabled (like gentoo apparently did) > KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) > > -- > 2.28.0.402.g5ffc5be6b7-goog >
RE: [PATCH v7 3/3] phy: intel: Add Keem Bay eMMC PHY support
Hi Vinod. Thanks for the review. > -Original Message- > From: Vinod Koul > Sent: Monday, August 31, 2020 5:20 PM > To: Wan Mohamad, Wan Ahmad Zainie > > Cc: kis...@ti.com; robh...@kernel.org; Shevchenko, Andriy > ; eswara.k...@linux.intel.com; > vadivel.muruganx.ramuthe...@linux.intel.com; Raja Subramanian, Lakshmi > Bai ; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v7 3/3] phy: intel: Add Keem Bay eMMC PHY support > > On 21-08-20, 19:37, Wan Ahmad Zainie wrote: > > > +/* From ACS_eMMC51_16nFFC_RO1100_Userguide_v1p0.pdf p17 */ > > +#define FREQSEL_200M_170M 0x0 > > +#define FREQSEL_170M_140M 0x1 > > +#define FREQSEL_140M_110M 0x2 > > +#define FREQSEL_110M_80M 0x3 > > +#define FREQSEL_80M_50M0x4 > > + > > +#define maskval(mask, val) (((val) << (ffs(mask) - 1)) & mask) > > Kernel has a macro do this for you, please use FIELD_PREP instead of I have updated to v8, to remove this macro and use FIELD_PREP. I also add changes based on Andy's comments. > > your own macro > -- > ~Vinod Best regards, Zainie
[PATCH v8 0/3] phy: intel: Add Keem Bay eMMC PHY support
Hi.
The first patch is added to rename rename
phy-intel-{combo,emmc}.c to phy-intel-lgm-{combo,emmc}.c..
The second patch is to document DT bindings for Keem Bay eMMC PHY.
The the third is the driver file, loosely based on phy-rockchip-emmc.c
and phy-intel-emmc.c. The latter is not being reused as there are
quite a number of differences i.e. registers offset, supported clock
rates, bitfield to set.
The patch was tested with Keem Bay evaluation module board.
Thank you.
Best regards,
Zainie
Changes since v7:
- Add Reviewed-by tag to 1st (Vadivel) and 3rd patch (Andy).
- In 3rd patch,
- remove maskval and use FIELD_PREP instead,
- add header,
- use return dev_err_probe(...) for devm_phy_create(...),
- rearrange depends on in Kconfig file,
Changes since v6:
- Add new patch to rename phy-intel-{combo,emmc}.c to
phy-intel-lgm-{combo,emmc}.c.
- Add Reviewed-by: Rob Herring tag to 2nd patch.
- In 3rd patch,
- add and use generic helper to update register bits,
- end module name with .ko in Kconfig help.
Changes since resend v5:
- In keembay_emmc_phy_power(), remove redundant return ret;.
Resend v5:
- Include missing changes done for phy-keembay-emmc.c (See Changes since
v3)
Changes since v4:
- In Kconfig file, add depends on ARM64 || COMPILE_TEST and
depends on OF && HAS_IOMEM.
- In Kconfig file, reword the help section to be more verbose.
Changes since v3:
- Exit keembay_emmc_phy_power() with return ret;.
- In keembay_emmc_phy_init(), use PTR_ERR_OR_ZERO(...).
- In keembay_emmc_phy_probe(), devm_regmap_init_mmio(...) in single
line.
Changes since v2:
- Modify DT example to use single cell for address and size.
Changes since v1:
- Rework phy-keembay-emmc.c to make it similar to phy-intel-emmc.c.
- Use regmap_mmio, and remove reference to intel,syscon.
- Use node name phy@
- Update license i.e. use dual license.
Wan Ahmad Zainie (3):
phy: intel: Rename phy-intel to phy-intel-lgm
dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
phy: intel: Add Keem Bay eMMC PHY support
.../bindings/phy/intel,keembay-emmc-phy.yaml | 44 +++
drivers/phy/intel/Kconfig | 22 +-
drivers/phy/intel/Makefile| 5 +-
drivers/phy/intel/phy-intel-keembay-emmc.c| 307 ++
...hy-intel-combo.c => phy-intel-lgm-combo.c} | 0
...{phy-intel-emmc.c => phy-intel-lgm-emmc.c} | 0
6 files changed, 371 insertions(+), 7 deletions(-)
create mode 100644
Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
create mode 100644 drivers/phy/intel/phy-intel-keembay-emmc.c
rename drivers/phy/intel/{phy-intel-combo.c => phy-intel-lgm-combo.c} (100%)
rename drivers/phy/intel/{phy-intel-emmc.c => phy-intel-lgm-emmc.c} (100%)
--
2.17.1
Re: [PATCH] misc: rtsx: add power saving function and bios guide options
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on soc/for-next linus/master v5.9-rc3 next-20200828]
[cannot apply to linux/master]
[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/ricky_wu-realtek-com/misc-rtsx-add-power-saving-function-and-bios-guide-options/20200901-103534
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
dd5597245d35cfbb0890b8a868028aa1d2018701
config: ia64-randconfig-r005-20200831 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from arch/ia64/include/asm/pgtable.h:154,
from include/linux/pgtable.h:6,
from arch/ia64/include/asm/uaccess.h:40,
from include/linux/uaccess.h:9,
from arch/ia64/include/asm/sections.h:11,
from include/linux/interrupt.h:20,
from include/linux/pci.h:38,
from include/linux/rtsx_pci.h:14,
from drivers/misc/cardreader/rts5249.c:12:
arch/ia64/include/asm/mmu_context.h: In function 'reload_context':
arch/ia64/include/asm/mmu_context.h:137:41: warning: variable 'old_rr4' set
but not used [-Wunused-but-set-variable]
137 | unsigned long rr0, rr1, rr2, rr3, rr4, old_rr4;
| ^~~
drivers/misc/cardreader/rts5249.c: In function
'rts52xa_save_content_from_efuse':
>> drivers/misc/cardreader/rts5249.c:157:14: warning: variable 'cv' set but not
>> used [-Wunused-but-set-variable]
157 | u8 cnt, sv, cv;
| ^~
#
https://github.com/0day-ci/linux/commit/7f37b141bf20205913d0efbf1bca25e323489b6b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
ricky_wu-realtek-com/misc-rtsx-add-power-saving-function-and-bios-guide-options/20200901-103534
git checkout 7f37b141bf20205913d0efbf1bca25e323489b6b
vim +/cv +157 drivers/misc/cardreader/rts5249.c
154
155 static void rts52xa_save_content_from_efuse(struct rtsx_pcr *pcr)
156 {
> 157 u8 cnt, sv, cv;
158 u8 j = 0;
159 u8 tmp;
160 u8 val;
161 int i;
162
163 rtsx_pci_write_register(pcr, RTS524A_PME_FORCE_CTL,
164 REG_EFUSE_BYPASS | REG_EFUSE_POR,
REG_EFUSE_POR);
165 udelay(1);
166
167 pcr_dbg(pcr, "Enable efuse por!");
168 pcr_dbg(pcr, "save efuse to autoload");
169
170 rtsx_pci_write_register(pcr, RTS525A_EFUSE_ADD,
REG_EFUSE_ADD_MASK, 0x00);
171 rtsx_pci_write_register(pcr, RTS525A_EFUSE_CTL,
172 REG_EFUSE_ENABLE | REG_EFUSE_MODE,
REG_EFUSE_ENABLE);
173 /* Wait transfer end */
174 for (j = 0; j < 1024; j++) {
175 rtsx_pci_read_register(pcr, RTS525A_EFUSE_CTL, );
176 if ((tmp & 0x80) == 0)
177 break;
178 }
179 rtsx_pci_read_register(pcr, RTS525A_EFUSE_DATA, );
180 cnt = val & 0x0F;
181 sv = val & 0x10;
182 cv = val & 0x20;
183
184 if (sv) {
185 for (i = 0; i < 4; i++) {
186 rtsx_pci_write_register(pcr, RTS525A_EFUSE_ADD,
187 REG_EFUSE_ADD_MASK, 0x04 + i);
188 rtsx_pci_write_register(pcr, RTS525A_EFUSE_CTL,
189 REG_EFUSE_ENABLE | REG_EFUSE_MODE,
REG_EFUSE_ENABLE);
190 /* Wait transfer end */
191 for (j = 0; j < 1024; j++) {
192 rtsx_pci_read_register(pcr,
RTS525A_EFUSE_CTL, );
193 if ((tmp & 0x80) == 0)
194 break;
195 }
196 rtsx_pci_read_register(pcr, RTS525A_EFUSE_DATA,
);
197 rtsx_pci_write_register(pcr, 0xFF04 + i, 0xFF,
val);
198 }
199 } else {
200
[PATCH v8 2/3] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
Binding description for Intel Keem Bay eMMC PHY.
Signed-off-by: Wan Ahmad Zainie
Reviewed-by: Rob Herring
---
.../bindings/phy/intel,keembay-emmc-phy.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
new file mode 100644
index ..4cbbd3887c13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-phy.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel Keem Bay eMMC PHY bindings
+
+maintainers:
+ - Wan Ahmad Zainie
+
+properties:
+ compatible:
+const: intel,keembay-emmc-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: emmcclk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+phy@2029 {
+ compatible = "intel,keembay-emmc-phy";
+ reg = <0x2029 0x54>;
+ clocks = <>;
+ clock-names = "emmcclk";
+ #phy-cells = <0>;
+};
--
2.17.1
[PATCH v8 1/3] phy: intel: Rename phy-intel to phy-intel-lgm
Rename phy-intel-{combo,emmc}.c to phy-intel-lgm-{combo,emmc}.c
to make drivers/phy/intel directory more generic for future use.
Signed-off-by: Wan Ahmad Zainie
Reviewed-by: Ramuthevar Vadivel Murugan
---
drivers/phy/intel/Kconfig | 10 +-
drivers/phy/intel/Makefile | 4 ++--
.../intel/{phy-intel-combo.c => phy-intel-lgm-combo.c} | 0
.../intel/{phy-intel-emmc.c => phy-intel-lgm-emmc.c} | 0
4 files changed, 7 insertions(+), 7 deletions(-)
rename drivers/phy/intel/{phy-intel-combo.c => phy-intel-lgm-combo.c} (100%)
rename drivers/phy/intel/{phy-intel-emmc.c => phy-intel-lgm-emmc.c} (100%)
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index 7b47682a4e0e..db8586c3eed8 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -1,9 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
#
-# Phy drivers for Intel Lightning Mountain(LGM) platform
+# Phy drivers for Intel platforms
#
-config PHY_INTEL_COMBO
- bool "Intel ComboPHY driver"
+config PHY_INTEL_LGM_COMBO
+ bool "Intel Lightning Mountain ComboPHY driver"
depends on X86 || COMPILE_TEST
depends on OF && HAS_IOMEM
select MFD_SYSCON
@@ -16,8 +16,8 @@ config PHY_INTEL_COMBO
chipsets which provides PHYs for various controllers, EMAC,
SATA and PCIe.
-config PHY_INTEL_EMMC
- tristate "Intel EMMC PHY driver"
+config PHY_INTEL_LGM_EMMC
+ tristate "Intel Lightning Mountain EMMC PHY driver"
depends on X86 || COMPILE_TEST
select GENERIC_PHY
help
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index 233d530dadde..662385d0a366 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_PHY_INTEL_COMBO) += phy-intel-combo.o
-obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
+obj-$(CONFIG_PHY_INTEL_LGM_COMBO) += phy-intel-lgm-combo.o
+obj-$(CONFIG_PHY_INTEL_LGM_EMMC) += phy-intel-lgm-emmc.o
diff --git a/drivers/phy/intel/phy-intel-combo.c
b/drivers/phy/intel/phy-intel-lgm-combo.c
similarity index 100%
rename from drivers/phy/intel/phy-intel-combo.c
rename to drivers/phy/intel/phy-intel-lgm-combo.c
diff --git a/drivers/phy/intel/phy-intel-emmc.c
b/drivers/phy/intel/phy-intel-lgm-emmc.c
similarity index 100%
rename from drivers/phy/intel/phy-intel-emmc.c
rename to drivers/phy/intel/phy-intel-lgm-emmc.c
--
2.17.1
[PATCH v8 3/3] phy: intel: Add Keem Bay eMMC PHY support
Add support for eMMC PHY on Intel Keem Bay SoC.
Signed-off-by: Wan Ahmad Zainie
Reviewed-by: Andy Shevchenko
---
drivers/phy/intel/Kconfig | 12 +
drivers/phy/intel/Makefile | 1 +
drivers/phy/intel/phy-intel-keembay-emmc.c | 307 +
3 files changed, 320 insertions(+)
create mode 100644 drivers/phy/intel/phy-intel-keembay-emmc.c
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index db8586c3eed8..58ec695c92ec 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -2,6 +2,18 @@
#
# Phy drivers for Intel platforms
#
+config PHY_INTEL_KEEMBAY_EMMC
+ tristate "Intel Keem Bay EMMC PHY driver"
+ depends on (OF && ARM64) || COMPILE_TEST
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Choose this option if you have an Intel Keem Bay SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called phy-keembay-emmc.ko.
+
config PHY_INTEL_LGM_COMBO
bool "Intel Lightning Mountain ComboPHY driver"
depends on X86 || COMPILE_TEST
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index 662385d0a366..a5e0af5ccd75 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_INTEL_KEEMBAY_EMMC) += phy-intel-keembay-emmc.o
obj-$(CONFIG_PHY_INTEL_LGM_COMBO) += phy-intel-lgm-combo.o
obj-$(CONFIG_PHY_INTEL_LGM_EMMC) += phy-intel-lgm-emmc.o
diff --git a/drivers/phy/intel/phy-intel-keembay-emmc.c
b/drivers/phy/intel/phy-intel-keembay-emmc.c
new file mode 100644
index ..eb7c635ed89a
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-keembay-emmc.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay eMMC PHY driver
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* eMMC/SD/SDIO core/phy configuration registers */
+#define PHY_CFG_0 0x24
+#define SEL_DLY_TXCLK_MASKBIT(29)
+#define OTAP_DLY_ENA_MASK BIT(27)
+#define OTAP_DLY_SEL_MASK GENMASK(26, 23)
+#define DLL_EN_MASK BIT(10)
+#define PWR_DOWN_MASK BIT(0)
+
+#define PHY_CFG_2 0x2c
+#define SEL_FREQ_MASK GENMASK(12, 10)
+
+#define PHY_STAT 0x40
+#define CAL_DONE_MASK BIT(6)
+#define IS_CALDONE(x) ((x) & CAL_DONE_MASK)
+#define DLL_RDY_MASK BIT(5)
+#define IS_DLLRDY(x) ((x) & DLL_RDY_MASK)
+
+/* From ACS_eMMC51_16nFFC_RO1100_Userguide_v1p0.pdf p17 */
+#define FREQSEL_200M_170M 0x0
+#define FREQSEL_170M_140M 0x1
+#define FREQSEL_140M_110M 0x2
+#define FREQSEL_110M_80M 0x3
+#define FREQSEL_80M_50M0x4
+
+struct keembay_emmc_phy {
+ struct regmap *syscfg;
+ struct clk *emmcclk;
+};
+
+static const struct regmap_config keembay_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static int keembay_emmc_phy_power(struct phy *phy, bool on_off)
+{
+ struct keembay_emmc_phy *priv = phy_get_drvdata(phy);
+ unsigned int caldone;
+ unsigned int dllrdy;
+ unsigned int freqsel;
+ unsigned int mhz;
+ int ret;
+
+ /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+ ret = regmap_update_bits(priv->syscfg, PHY_CFG_0, PWR_DOWN_MASK,
+FIELD_PREP(PWR_DOWN_MASK, 0));
+ if (ret) {
+ dev_err(>dev, "CALIO power down bar failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_update_bits(priv->syscfg, PHY_CFG_0, DLL_EN_MASK,
+FIELD_PREP(DLL_EN_MASK, 0));
+ if (ret) {
+ dev_err(>dev, "turn off the dll failed: %d\n", ret);
+ return ret;
+ }
+
+ /* Already finish power off above */
+ if (!on_off)
+ return 0;
+
+ mhz = DIV_ROUND_CLOSEST(clk_get_rate(priv->emmcclk), 100);
+ if (mhz <= 200 && mhz >= 170)
+ freqsel = FREQSEL_200M_170M;
+ else if (mhz <= 170 && mhz >= 140)
+ freqsel = FREQSEL_170M_140M;
+ else if (mhz <= 140 && mhz >= 110)
+ freqsel = FREQSEL_140M_110M;
+ else if (mhz <= 110 && mhz >= 80)
+ freqsel = FREQSEL_110M_80M;
+ else if (mhz <= 80 && mhz >= 50)
+ freqsel = FREQSEL_80M_50M;
+ else
+ freqsel = 0x0;
+
+ if (mhz < 50 || mhz > 200)
+ dev_warn(>dev, "Unsupported rate: %d MHz\n", mhz);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value, so we may need a
Re: [RFC PATCH 00/22] Enhance VHOST to enable SoC-to-SoC communication
Hi Mathieu, On 15/07/20 10:45 pm, Mathieu Poirier wrote: Hey Kishon, On Wed, Jul 08, 2020 at 06:43:45PM +0530, Kishon Vijay Abraham I wrote: Hi Jason, On 7/8/2020 4:52 PM, Jason Wang wrote: On 2020/7/7 下午10:45, Kishon Vijay Abraham I wrote: Hi Jason, On 7/7/2020 3:17 PM, Jason Wang wrote: On 2020/7/6 下午5:32, Kishon Vijay Abraham I wrote: Hi Jason, On 7/3/2020 12:46 PM, Jason Wang wrote: On 2020/7/2 下午9:35, Kishon Vijay Abraham I wrote: Hi Jason, On 7/2/2020 3:40 PM, Jason Wang wrote: On 2020/7/2 下午5:51, Michael S. Tsirkin wrote: On Thu, Jul 02, 2020 at 01:51:21PM +0530, Kishon Vijay Abraham I wrote: This series enhances Linux Vhost support to enable SoC-to-SoC communication over MMIO. This series enables rpmsg communication between two SoCs using both PCIe RC<->EP and HOST1-NTB-HOST2 1) Modify vhost to use standard Linux driver model 2) Add support in vring to access virtqueue over MMIO 3) Add vhost client driver for rpmsg 4) Add PCIe RC driver (uses virtio) and PCIe EP driver (uses vhost) for rpmsg communication between two SoCs connected to each other 5) Add NTB Virtio driver and NTB Vhost driver for rpmsg communication between two SoCs connected via NTB 6) Add configfs to configure the components UseCase1 : VHOST RPMSG VIRTIO RPMSG + + | | | | | | | | +-v--+ +--v---+ | Linux | | Linux | | Endpoint | | Root Complex | | <-> | | | | | | SOC1 | | SOC2 | ++ +--+ UseCase 2: VHOST RPMSG VIRTIO RPMSG + + | | | | | | | | +--v--+ +--v--+ | | | | | HOST1 | | HOST2 | | | | | +--^--+ +--^--+ | | | | +-+ | +--v--+ +--v--+ | | | | | | | | | EP | | EP | | | | CONTROLLER1 | | CONTROLLER2 | | | | <---> | | | | | | | | | | | | | | | | | SoC With Multiple EP Instances | | | | | | (Configured using NTB Function) | | | | +-+ +-+ | +-+ Software Layering: The high-level SW layering should look something like below. This series adds support only for RPMSG VHOST, however something similar should be done for net and scsi. With that any vhost device (PCI, NTB, Platform device, user) can use any of the vhost client driver. ++ +---+ ++ +--+ | RPMSG VHOST | | NET VHOST | | SCSI VHOST | | X | +---^+ +-^-+ +-^--+ +^-+ | | | | | | | | | | | | +---v-v--v--v--+ | VHOST CORE | +^---^^--^-+ | | | | | | | | | | | | +v---+ +v--+ +--v--+ +v-+ | PCI EPF VHOST | | NTB VHOST | |PLATFORM DEVICE VHOST| | X | ++ +---+
Re: [PATCH v4 75/78] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
Hi Maxime,
On 7/9/20 2:42 AM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109
> -
> 1 file changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id:
> https://protect2.fireeye.com/url?k=556aeb05-08b8fda0-556b604a-0cc47a31bee8-c3a0ebd1d22c3183=1=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema:
> https://protect2.fireeye.com/url?k=24fa660c-792870a9-24fbed43-0cc47a31bee8-0bf16f4fd60f0ab4=1=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt
> +
> +properties:
> + compatible:
> +enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
> +
> + reg:
> +items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> +items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> +description: The HDMI state machine clock
I'm not sure the following description is correct.
But, this description doesn't contain the information of audio clock.
description: The HDMI state machine and audio clock
> +
> + clock-names:
> +const: hdmi
This patch is missing the following clock information for audio clock.
const: clk-108M
> +
> + ddc:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> + Phandle of the I2C controller used for DDC EDID probing
> +
> + hpd-gpios:
> +description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
> +
> + dmas:
> +maxItems: 1
> +description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> +const: audio-rx
> +
> + resets:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> +"packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <_clocks 13>;
> +clock-names = "hdmi";
Also, this example doesn't include the instance of audio clock.
Need to edit them as following:
clock-names = "hdmi", "clk-108M";
clocks = <_clocks 13>, < 0>;
> +resets = < 0>;
> +ddc = <>;
> +};
> +
> +...
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 06/19] drm/msm/gpu: add dev_to_gpu() helper
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> In a later patch, the drvdata will not directly be 'struct msm_gpu *',
> so add a helper to reduce the churn.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 10 --
> drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
> drivers/gpu/drm/msm/msm_gpu.h | 5 +
> 3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 9eeb46bf2a5d..26664e1b30c0 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -282,7 +282,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> int ret;
>
> if (pdev)
> - gpu = platform_get_drvdata(pdev);
> + gpu = dev_to_gpu(>dev);
>
> if (!gpu) {
> dev_err_once(dev->dev, "no GPU device was found\n");
> @@ -425,7 +425,7 @@ static int adreno_bind(struct device *dev, struct device
> *master, void *data)
> static void adreno_unbind(struct device *dev, struct device *master,
> void *data)
> {
> - struct msm_gpu *gpu = dev_get_drvdata(dev);
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> pm_runtime_force_suspend(dev);
> gpu->funcs->destroy(gpu);
> @@ -490,16 +490,14 @@ static const struct of_device_id dt_match[] = {
> #ifdef CONFIG_PM
> static int adreno_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> return gpu->funcs->pm_resume(gpu);
> }
>
> static int adreno_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> return gpu->funcs->pm_suspend(gpu);
> }
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index d5645472b25d..6aa9e04e52e7 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -24,7 +24,7 @@
> static int msm_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> + struct msm_gpu *gpu = dev_to_gpu(dev);
> struct dev_pm_opp *opp;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> @@ -45,7 +45,7 @@ static int msm_devfreq_target(struct device *dev, unsigned
> long *freq,
> static int msm_devfreq_get_dev_status(struct device *dev,
> struct devfreq_dev_status *status)
> {
> - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> + struct msm_gpu *gpu = dev_to_gpu(dev);
> ktime_t time;
>
> if (gpu->funcs->gpu_get_freq)
> @@ -64,7 +64,7 @@ static int msm_devfreq_get_dev_status(struct device *dev,
>
> static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
> {
> - struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> + struct msm_gpu *gpu = dev_to_gpu(dev);
>
> if (gpu->funcs->gpu_get_freq)
> *freq = gpu->funcs->gpu_get_freq(gpu);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 0db117a7339b..8bda7beaed4b 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -141,6 +141,11 @@ struct msm_gpu {
> struct msm_gpu_state *crashstate;
> };
>
> +static inline struct msm_gpu *dev_to_gpu(struct device *dev)
That's a fairly generic name for a driver-global helper :)
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> +{
> + return dev_get_drvdata(dev);
> +}
> +
> /* It turns out that all targets use the same ringbuffer size */
> #define MSM_GPU_RINGBUFFER_SZ SZ_32K
> #define MSM_GPU_RINGBUFFER_BLKSIZE 32
> --
> 2.26.2
>
Re: [PATCH v4 62/78] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
Hi Maxime,
On 7/9/20 2:42 AM, Maxime Ripard wrote:
> The HSM clock needs to be setup at around 101% of the pixel rate. This
> was done previously by setting the clock rate to 163.7MHz at probe time and
> only check in mode_valid whether the mode pixel clock was under the pixel
> clock +1% or not.
>
> However, with 4k we need to change that frequency to a higher frequency
> than 163.7MHz, and yet want to have the lowest clock as possible to have a
> decent power saving.
>
> Let's change that logic a bit by setting the clock rate of the HSM clock
> to the pixel rate at encoder_enable time. This would work for the
> BCM2711 that support 4k resolutions and has a clock that can provide it,
> but we still have to take care of a 4k panel plugged on a BCM283x SoCs
> that wouldn't be able to use those modes, so let's define the limit in
> the variant.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 79 ---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +-
> 2 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 17797b14cde4..9f30fab744f2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -53,7 +53,6 @@
> #include "vc4_hdmi_regs.h"
> #include "vc4_regs.h"
>
> -#define HSM_CLOCK_FREQ 163682864
> #define CEC_CLOCK_FREQ 4
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> @@ -326,6 +325,7 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> ret = pm_runtime_put(_hdmi->pdev->dev);
> @@ -423,6 +423,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> bool debug_dump_regs = false;
> + unsigned long pixel_rate, hsm_rate;
> int ret;
>
> ret = pm_runtime_get_sync(_hdmi->pdev->dev);
> @@ -431,9 +432,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> - ret = clk_set_rate(vc4_hdmi->pixel_clock,
> -mode->clock * 1000 *
> -((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
> + pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
> ? 2 : 1);
> + ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
> if (ret) {
> DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
> return;
> @@ -445,6 +445,36 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> + /*
> + * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> + * be faster than pixel clock, infinitesimally faster, tested in
> + * simulation. Otherwise, exact value is unimportant for HDMI
> + * operation." This conflicts with bcm2835's vc4 documentation, which
> + * states HSM's clock has to be at least 108% of the pixel clock.
> + *
> + * Real life tests reveal that vc4's firmware statement holds up, and
> + * users are able to use pixel clocks closer to HSM's, namely for
> + * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> + * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> + * 162MHz.
> + *
> + * Additionally, the AXI clock needs to be at least 25% of
> + * pixel clock, but HSM ends up being the limiting factor.
> + */
> + hsm_rate = max_t(unsigned long, 12000, (pixel_rate / 100) * 101);
> + ret = clk_set_rate(vc4_hdmi->hsm_clock, hsm_rate);
> + if (ret) {
> + DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->hsm_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on HSM clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
About vc4_hdmi->hsm_clock instance, usually, we need to enable the clock
with clk_prepare_enable() and then touch the clock like clk_set_rate().
I think that need to enable the clock before calling clk_set_rate().
When I tested this patchset, it is well working because I think that
vc4_hdmi->hsm_clock was already enabled on other side.
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -559,23 +589,9 @@ static enum drm_mode_status
> vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> const struct drm_display_mode *mode)
> {
> - /*
> - * As stated in RPi's vc4 firmware
Re: [PATCH] ia64: fix min_low_pfn/max_low_pfn build errors
Tony, I can take it via the memblock tree, would appreciate an Ack. On Fri, Aug 28, 2020 at 05:01:26PM -0700, Randy Dunlap wrote: > Fix min_low_pfn/max_low_pfn build errors for arch/ia64/: (e.g.) > > ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! > ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! > ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! > ERROR: "max_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! > ERROR: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! > ERROR: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! > ERROR: "max_low_pfn" [drivers/md/dm-integrity.ko] undefined! > ERROR: "min_low_pfn" [drivers/md/dm-integrity.ko] undefined! > ERROR: "max_low_pfn" [crypto/tcrypt.ko] undefined! > ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined! > ERROR: "min_low_pfn" [security/keys/encrypted-keys/encrypted-keys.ko] > undefined! > ERROR: "max_low_pfn" [security/keys/encrypted-keys/encrypted-keys.ko] > undefined! > ERROR: "min_low_pfn" [arch/ia64/kernel/mca_recovery.ko] undefined! > ERROR: "max_low_pfn" [arch/ia64/kernel/mca_recovery.ko] undefined! > > David suggested just exporting min_low_pfn & max_low_pfn in > mm/memblock.c: > https://lore.kernel.org/lkml/alpine.deb.2.22.394.2006291911220.1118...@chino.kir.corp.google.com/ > > Reported-by: kernel test robot > Signed-off-by: Randy Dunlap > Cc: linux...@kvack.org > Cc: Andrew Morton > Cc: David Rientjes > Cc: Mike Rapoport > Cc: Tony Luck > Cc: Fenghua Yu > Cc: linux-i...@vger.kernel.org > --- > arch/ia64/kernel/ia64_ksyms.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-next-20200825.orig/arch/ia64/kernel/ia64_ksyms.c > +++ linux-next-20200825/arch/ia64/kernel/ia64_ksyms.c > @@ -3,7 +3,7 @@ > * Architecture-specific kernel symbols > */ > > -#ifdef CONFIG_VIRTUAL_MEM_MAP > +#if defined(CONFIG_VIRTUAL_MEM_MAP) || defined(CONFIG_DISCONTIGMEM) > #include > #include > #include -- Sincerely yours, Mike.
Re: [PATCH] x86/platform/intel-mid: Fix build error without CONFIG_ACPI
On 8/31/20 8:58 PM, YueHaibing wrote:
> arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
> arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function
> ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
> [-Werror=implicit-function-declaration]
> acpi_noirq_set();
> ^~
> acpi_irq_get
>
> Fixes: a912a7584ec3 ("x86/platform/intel-mid: Move PCI initialization to
> arch_init()")
> Signed-off-by: YueHaibing
Bjorn has merged my patch (or so his email says), but apparently it's not
in linux-next yet.
> ---
> arch/x86/pci/intel_mid_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
> index 00c62115f39c..0aaf31917061 100644
> --- a/arch/x86/pci/intel_mid_pci.c
> +++ b/arch/x86/pci/intel_mid_pci.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #define PCIE_CAP_OFFSET 0x100
>
>
thanks.
--
~Randy
Re: [PATCH 0/5] mm: fixes to past from future testing
On Tue, 1 Sep 2020, Alex Shi wrote: > 在 2020/8/31 上午4:57, Hugh Dickins 写道: > > Here's a set of independent fixes against 5.9-rc2: prompted by > > testing Alex Shi's "warning on !memcg" and lru_lock series, but > > I think fit for 5.9 - though maybe only the first for stable. > > > > [PATCH 1/5] ksm: reinstate memcg charge on copied pages > > [PATCH 2/5] mm: migration of hugetlbfs page skip memcg > > [PATCH 3/5] shmem: shmem_writepage() split unlikely i915 THP > > [PATCH 4/5] mm: fix check_move_unevictable_pages() on THP > > [PATCH 5/5] mlock: fix unevictable_pgs event counts on THP > > Hi Hugh, > > Thanks a lot for reporting and fix! All fixed looks fine for me. Thanks for checking. > > BTW, > I assume you already rebased lru_lock patchset on this. So I don't > need to redo rebase again, do I? :) That's right, no need for another posting: the only ones of yours which don't apply cleanly on top of mine are 20/32 and 21/32, touching check_move_unevictable_pages(); and they're easy enough to resolve. With my 5 fixes in, I'll advance to commenting on yours (but not today). Hugh
Re: [PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control
Hi Hoegeun,
It looks good to me. But, just one comment.
On 9/1/20 1:07 PM, Hoegeun Kwon wrote:
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 95ec5eedea39..eb3192d1fd86 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -80,6 +80,7 @@
> # define VC4_HD_M_ENABLE BIT(0)
>
> #define CEC_CLOCK_FREQ 4
> +#define VC4_HSM_MID_CLOCK 149985000
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> drm_encoder *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder)
> return;
> }
>
> + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
> + if (ret) {
> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
Generally, enable the clock before using clk and then change the clock rate.
I think that you better to change the order between clk_prepare_enable and
clk_set_rate.
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->audio_clock);
> }
>
> + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> + DRM_ERROR("Failed to get pixel bvb clock\n");
> + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> + }
> +
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(vc4_hdmi->reset)) {
> DRM_ERROR("Failed to get HDMI reset line\n");
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0806c6d9f24e..63c6f8bddf1d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -147,6 +147,7 @@ struct vc4_hdmi {
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> + struct clk *pixel_bvb_clock;
>
> struct reset_control *reset;
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[gustavoars-linux:testing/fam0] BUILD SUCCESS a56dbff00095f3fc2c3fcb71dab2e536d42a4ff5
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git testing/fam0 branch HEAD: a56dbff00095f3fc2c3fcb71dab2e536d42a4ff5 scsi: target: tcmu: Replace zero-length array with flexible-array member elapsed time: 726m configs tested: 116 configs skipped: 7 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm hackkit_defconfig powerpc pq2fads_defconfig arm h3600_defconfig sh se7712_defconfig powerpc64alldefconfig openrisc alldefconfig m68kmac_defconfig powerpc pmac32_defconfig sh lboxre2_defconfig sh se7751_defconfig arm u8500_defconfig pariscgeneric-32bit_defconfig m68kmvme147_defconfig powerpc allmodconfig m68k apollo_defconfig sh r7785rp_defconfig powerpc mpc83xx_defconfig powerpc allyesconfig cskydefconfig armmini2440_defconfig armcerfcube_defconfig h8300 defconfig arm spear13xx_defconfig arc defconfig m68k sun3x_defconfig armu300_defconfig parisc allyesconfig mips capcella_defconfig powerpc ppc6xx_defconfig sh rts7751r2d1_defconfig m68kq40_defconfig arm omap1_defconfig arm milbeaut_m10v_defconfig shedosk7705_defconfig mips malta_kvm_defconfig sh microdev_defconfig mips bmips_stb_defconfig armmps2_defconfig nios2 defconfig arm imx_v6_v7_defconfig mips rs90_defconfig i386 alldefconfig powerpc ppc64e_defconfig armhisi_defconfig nios2 3c120_defconfig powerpcadder875_defconfig shtitan_defconfig mips gcw0_defconfig arm bcm2835_defconfig archsdk_defconfig arm s5pv210_defconfig powerpc wii_defconfig shsh7757lcr_defconfig sh alldefconfig arm stm32_defconfig mipsjmr3927_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig sh allmodconfig parisc defconfig s390 allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a001-20200831 i386 randconfig-a002-20200831 i386 randconfig-a004-20200831 i386 randconfig-a006-20200831 i386 randconfig-a005-20200831 i386 randconfig-a003-20200831 x86_64 randconfig-a012-20200831 x86_64 randconfig-a015-20200831 x86_64 randconfig-a014-20200831 x86_64 randconfig-a011-20200831 x86_64 randconfig-a016-20200831 x86_64 randconfig-a013-20200831 i386
[PATCH v2 0/4] drm/vc4: Support HDMI QHD or higher output
Hi everyone, There is a problem that the output does not work at a resolution exceeding FHD. To solve this, we need to adjust the bvb clock at a resolution exceeding FHD. Rebased on top of next-20200708 and [1]. [1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's patchset) Changes from v1: - Added dt-bindings documents - Change patch order, first fix driver and then device tree Hoegeun Kwon (4): clk: bcm: rpi: Add register to control pixel bvb clk drm/vc4: hdmi: Add pixel bvb clock control dt-bindings: display: vc4: hdmi: Add bvb clock-names property ARM: dts: bcm2711: Add bvb clock for hdmi-pixel .../bindings/display/brcm,bcm2711-hdmi.yaml | 12 ++--- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 +++-- drivers/clk/bcm/clk-raspberrypi.c | 1 + drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +++ drivers/gpu/drm/vc4/vc4_hdmi.h| 1 + 5 files changed, 39 insertions(+), 6 deletions(-) -- 2.17.1
[PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
# define VC4_HD_M_ENABLE BIT(0)
#define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
+ clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder)
return;
}
+ ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+ (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+ if (ret) {
+ DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
+ ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+ if (ret) {
+ DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
+ vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+ if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+ DRM_ERROR("Failed to get pixel bvb clock\n");
+ return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+ struct clk *pixel_bvb_clock;
struct reset_control *reset;
--
2.17.1
[PATCH v2 4/4] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
};
{
- clocks = <_clocks 13>, < 0>;
+ clocks = <_clocks 13>, < 0>, <_clocks 14>;
+ clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
};
{
- clocks = <_clocks 13>, < 1>;
+ clocks = <_clocks 13>, < 1>, <_clocks 14>;
+ clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
};
--
2.17.1
Re: splice: infinite busy loop lockup bug
On Mon, Aug 31, 2020 at 11:32:28PM -0400, Qian Cai wrote:
> I used a new debug patch but not sure how to capture without
> printk_ratelimited() because the call sites are large,
if (!strcmp(current->comm, "bugger"))
printk(KERN_ERR
and call the binary you are running ./bugger... And I'd slap such
printk into the beginning of iterate_iovec() as well, if not into
the entry of iov_iter_copy_from_user_atomic(). That BS value of
n must've come from somewhere; it should expand to 'bytes'.
What we have in the beginning is
const struct iovec *iov;
struct iovec v;
size_t skip = i->iov_offset;
size_t left;
size_t wanted = bytes;
iov = i->iov;
__v.iov_len = min(bytes, iov->iov_len - skip);
if (likely(__v.iov_len)) {
__v.iov_base = iov->iov_base + skip;
left = copyin((p += v.iov_len) - v.iov_len, v.iov_base,
v.iov_len);
__v.iov_len -= left;
skip += __v.iov_len;
bytes -= __v.iov_len;
} else {
left = 0;
}
and something leaves you with bytes bumped to 22476968. What was in that first
iovec? Incidentally, what's in 'wanted'? And... Timestamps don't look like
that crap has come from generic_perform_write() - it's about 4 seconds later.
While we are at it, there are other users of iterate_all_kinds(), and some of
them
can very well get large sizes; they are not copying anything
(iov_iter_advance(),
for starters). There that kind of values would be just fine; are you sure those
printks came from iov_iter_copy_from_user_atomic()?
[PATCH v2 3/4] dt-bindings: display: vc4: hdmi: Add bvb clock-names property
When using a resolution exceeding FHD, bvb clock is required. Add bvb clock-names property. Signed-off-by: Hoegeun Kwon --- .../bindings/display/brcm,bcm2711-hdmi.yaml | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml index 6091fe3d315b..08cdcc579cf5 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml @@ -40,10 +40,14 @@ properties: - const: hd clocks: -description: The HDMI state machine clock +items: + - description: The HDMI state machine clock + - description: The bvb clock clock-names: -const: hdmi +items: + - const: hdmi + - const: bvb ddc: allOf: @@ -100,8 +104,8 @@ examples: "csc", "cec", "hd"; -clocks = <_clocks 13>; -clock-names = "hdmi"; +clocks = <_clocks 13>, <_clocks 14>; +clock-names = "hdmi", "bvb"; resets = < 0>; ddc = <>; }; -- 2.17.1
[PATCH v2 1/4] clk: bcm: rpi: Add register to control pixel bvb clk
To use QHD or higher, we need to modify the pixel_bvb_clk value. So add register to control this clock. Signed-off-by: Hoegeun Kwon --- drivers/clk/bcm/clk-raspberrypi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c index 5cc82954e1ce..f89b9cfc4309 100644 --- a/drivers/clk/bcm/clk-raspberrypi.c +++ b/drivers/clk/bcm/clk-raspberrypi.c @@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi, case RPI_FIRMWARE_CORE_CLK_ID: case RPI_FIRMWARE_M2MC_CLK_ID: case RPI_FIRMWARE_V3D_CLK_ID: + case RPI_FIRMWARE_PIXEL_BVB_CLK_ID: hw = raspberrypi_clk_register(rpi, clks->parent, clks->id); if (IS_ERR(hw)) -- 2.17.1
Re: [PATCH] arm64: dts: sdm845: Fixup OPP table for all qup devices
On Wed, Aug 12, 2020 at 3:23 AM Rajendra Nayak wrote:
>
> This OPP table was based on the clock VDD-FMAX tables seen in
> downstream code, however it turns out the downstream clock
> driver does update these tables based on later/production
> rev of the chip and whats seen in the tables belongs to an
> early engineering rev of the SoC.
> Fix up the OPP tables such that it now matches with the
> production rev of sdm845 SoC.
>
> Fixes: 13cadb34e593 ("arm64: dts: sdm845: Add OPP table for all qup
> devices")
> Reported-by: John Stultz
> Signed-off-by: Rajendra Nayak
> ---
Just wanted to follow up on this, as it's still missing from 5.9-rc3
and is needed to fix a bluetooth regression on db845c from 5.9-rc1.
Amit has already validated it (on PocoF1 as well), but just in case its useful:
Tested-by: John Stultz
thanks
-john
[PATCH] x86/platform/intel-mid: Fix build error without CONFIG_ACPI
arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
acpi_noirq_set();
^~
acpi_irq_get
Fixes: a912a7584ec3 ("x86/platform/intel-mid: Move PCI initialization to
arch_init()")
Signed-off-by: YueHaibing
---
arch/x86/pci/intel_mid_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 00c62115f39c..0aaf31917061 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#define PCIE_CAP_OFFSET0x100
--
2.17.1
Re: [PATCH 4/5] mm: fix check_move_unevictable_pages() on THP
On Tue, 1 Sep 2020, Alex Shi wrote:
> 在 2020/8/31 上午5:08, Hugh Dickins 写道:
> > --- 5.9-rc2/mm/vmscan.c 2020-08-16 17:32:50.721507348 -0700
> > +++ linux/mm/vmscan.c 2020-08-28 17:47:10.595580876 -0700
> > @@ -4260,8 +4260,14 @@ void check_move_unevictable_pages(struct
> > for (i = 0; i < pvec->nr; i++) {
> > struct page *page = pvec->pages[i];
> > struct pglist_data *pagepgdat = page_pgdat(page);
> > + int nr_pages;
> > +
> > + if (PageTransTail(page))
> > + continue;
> > +
> > + nr_pages = thp_nr_pages(page);
> > + pgscanned += nr_pages;
> >
> > - pgscanned++;
> > if (pagepgdat != pgdat) {
> > if (pgdat)
> > spin_unlock_irq(>lru_lock);
> > @@ -4280,7 +4286,7 @@ void check_move_unevictable_pages(struct
> > ClearPageUnevictable(page);
> > del_page_from_lru_list(page, lruvec, LRU_UNEVICTABLE);
> > add_page_to_lru_list(page, lruvec, lru);
>
> So, we might randomly del or add a thp tail page into lru?
> It's interesting to know here. :)
No, it wasn't that interesting, I'd have been more concerned if it was
like that. Amusing idea though: because the act of adding a thp tail
to lru would clear the very bit that says it's a tail.
if (!PageLRU(page) || !PageUnevictable(page))
continue;
Let's see: PageLRU and PageUnevictable are both of the PF_HEAD type,
so permitted on tails, but always redirecting to head: so typically
PageLRU(page) would be true, because head on lru; but PageUnevictable(page)
would be false on tail, because head has already been moved to an evictable
lru by this same function. So it safely went the "continue" way, but
without incrementing pgrescued.
Hugh
>
> Thanks
> Alex
>
> > - pgrescued++;
> > + pgrescued += nr_pages;
> > }
> > }
> >
[PATCH -next] staging: spmi: hisi-spmi-controller: Use proper format in call to dev_err()
The correct format string for a size_t argument should be %zu.
Signed-off-by: YueHaibing
---
drivers/staging/hikey9xx/hisi-spmi-controller.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c
b/drivers/staging/hikey9xx/hisi-spmi-controller.c
index 66a0b296e06f..34c690da09e3 100644
--- a/drivers/staging/hikey9xx/hisi-spmi-controller.c
+++ b/drivers/staging/hikey9xx/hisi-spmi-controller.c
@@ -121,7 +121,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl,
if (bc > SPMI_CONTROLLER_MAX_TRANS_BYTES) {
dev_err(>dev,
- "spmi_controller supports 1..%d bytes per trans,
but:%ld requested\n",
+ "spmi_controller supports 1..%d bytes per trans,
but:%zu requested\n",
SPMI_CONTROLLER_MAX_TRANS_BYTES, bc);
return -EINVAL;
}
@@ -175,7 +175,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl,
spin_unlock_irqrestore(_controller->lock, flags);
if (rc)
dev_err(>dev,
- "spmi read wait timeout op:0x%x slave_id:%d
slave_addr:0x%x bc:%ld\n",
+ "spmi read wait timeout op:0x%x slave_id:%d
slave_addr:0x%x bc:%zu\n",
opc, slave_id, slave_addr, bc + 1);
else
dev_dbg(>dev, "%s: id:%d slave_addr:0x%x, read value:
%*ph\n",
@@ -197,7 +197,7 @@ static int spmi_write_cmd(struct spmi_controller *ctrl,
if (bc > SPMI_CONTROLLER_MAX_TRANS_BYTES) {
dev_err(>dev,
- "spmi_controller supports 1..%d bytes per trans,
but:%ld requested\n",
+ "spmi_controller supports 1..%d bytes per trans,
but:%zu requested\n",
SPMI_CONTROLLER_MAX_TRANS_BYTES, bc);
return -EINVAL;
}
@@ -251,7 +251,7 @@ static int spmi_write_cmd(struct spmi_controller *ctrl,
spin_unlock_irqrestore(_controller->lock, flags);
if (rc)
- dev_err(>dev, "spmi write wait timeout op:0x%x
slave_id:%d slave_addr:0x%x bc:%ld\n",
+ dev_err(>dev, "spmi write wait timeout op:0x%x
slave_id:%d slave_addr:0x%x bc:%zu\n",
opc, slave_id, slave_addr, bc);
else
dev_dbg(>dev, "%s: id:%d slave_addr:0x%x, wrote value:
%*ph\n",
--
2.17.1
[PATCH -next] memory: omap-gpmc: Fix -Wunused-function warnings
drivers/memory/omap-gpmc.c:987:12: warning: ‘gpmc_cs_remap’ defined but not
used [-Wunused-function]
static int gpmc_cs_remap(int cs, u32 base)
^
drivers/memory/omap-gpmc.c:926:20: warning: ‘gpmc_cs_get_name’ defined but not
used [-Wunused-function]
static const char *gpmc_cs_get_name(int cs)
^~~~
drivers/memory/omap-gpmc.c:919:13: warning: ‘gpmc_cs_set_name’ defined but not
used [-Wunused-function]
static void gpmc_cs_set_name(int cs, const char *name)
^~~~
Make them as __maybe_unused to fix this.
Signed-off-by: YueHaibing
---
drivers/memory/omap-gpmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index ac0f577a51a1..24372254986e 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -916,14 +916,14 @@ static bool gpmc_cs_reserved(int cs)
return gpmc->flags & GPMC_CS_RESERVED;
}
-static void gpmc_cs_set_name(int cs, const char *name)
+static void __maybe_unused gpmc_cs_set_name(int cs, const char *name)
{
struct gpmc_cs_data *gpmc = _cs[cs];
gpmc->name = name;
}
-static const char *gpmc_cs_get_name(int cs)
+static const __maybe_unused char *gpmc_cs_get_name(int cs)
{
struct gpmc_cs_data *gpmc = _cs[cs];
@@ -984,7 +984,7 @@ static int gpmc_cs_delete_mem(int cs)
* "base". Returns 0 on success and appropriate negative error code
* on failure.
*/
-static int gpmc_cs_remap(int cs, u32 base)
+static int __maybe_unused gpmc_cs_remap(int cs, u32 base)
{
int ret;
u32 old_base, size;
--
2.17.1
[PATCH] ath11k: Mark two variables as __maybe_unused
Fix -Wunused-variable warnings:
drivers/net/wireless/ath/ath11k/debug.c:36:20: warning: ‘htt_bp_lmac_ring’
defined but not used [-Wunused-variable]
drivers/net/wireless/ath/ath11k/debug.c:15:20: warning: ‘htt_bp_umac_ring’
defined but not used [-Wunused-variable]
Signed-off-by: YueHaibing
---
drivers/net/wireless/ath/ath11k/debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/debug.c
b/drivers/net/wireless/ath/ath11k/debug.c
index 0a3cfa716390..0b7842e8cc58 100644
--- a/drivers/net/wireless/ath/ath11k/debug.c
+++ b/drivers/net/wireless/ath/ath11k/debug.c
@@ -12,7 +12,7 @@
#include "debug_htt_stats.h"
#include "peer.h"
-static const char *htt_bp_umac_ring[HTT_SW_UMAC_RING_IDX_MAX] = {
+static const __maybe_unused char *htt_bp_umac_ring[HTT_SW_UMAC_RING_IDX_MAX] =
{
"REO2SW1_RING",
"REO2SW2_RING",
"REO2SW3_RING",
@@ -33,7 +33,7 @@ static const char *htt_bp_umac_ring[HTT_SW_UMAC_RING_IDX_MAX]
= {
"REO_STATUS_RING",
};
-static const char *htt_bp_lmac_ring[HTT_SW_LMAC_RING_IDX_MAX] = {
+static const __maybe_unused char *htt_bp_lmac_ring[HTT_SW_LMAC_RING_IDX_MAX] =
{
"FW2RXDMA_BUF_RING",
"FW2RXDMA_STATUS_RING",
"FW2RXDMA_LINK_RING",
--
2.17.1
Re: [PATCH 05/19] iommu: add private interface for adreno-smmu
On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
> From: Rob Clark
>
> This interface will be used for drm/msm to coordinate with the
> qcom_adreno_smmu_impl to enable/disable TTBR0 translation.
>
> Once TTBR0 translation is enabled, the GPU's CP (Command Processor)
> will directly switch TTBR0 pgtables (and do the necessary TLB inv)
> synchronized to the GPU's operation. But help from the SMMU driver
> is needed to initially bootstrap TTBR0 translation, which cannot be
> done from the GPU.
>
> Since this is a very special case, a private interface is used to
> avoid adding highly driver specific things to the public iommu
> interface.
>
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> include/linux/adreno-smmu-priv.h | 36
> 1 file changed, 36 insertions(+)
> create mode 100644 include/linux/adreno-smmu-priv.h
>
> diff --git a/include/linux/adreno-smmu-priv.h
> b/include/linux/adreno-smmu-priv.h
> new file mode 100644
> index ..a889f28afb42
> --- /dev/null
> +++ b/include/linux/adreno-smmu-priv.h
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Google, Inc
> + */
> +
> +#ifndef __ADRENO_SMMU_PRIV_H
> +#define __ADRENO_SMMU_PRIV_H
> +
> +#include
> +
> +/**
> + * struct adreno_smmu_priv - private interface between adreno-smmu and GPU
> + *
> + * @cookie:An opque token provided by adreno-smmu and passed
> + * back into the callbacks
> + * @get_ttbr1_cfg: Get the TTBR1 config for the GPUs context-bank
> + * @set_ttbr0_cfg: Set the TTBR0 config for the GPUs context bank. A
> + * NULL config disables TTBR0 translation, otherwise
> + * TTBR0 translation is enabled with the specified cfg
> + *
> + * The GPU driver (drm/msm) and adreno-smmu work together for controlling
> + * the GPU's SMMU instance. This is by necessity, as the GPU is directly
> + * updating the SMMU for context switches, while on the other hand we do
> + * not want to duplicate all of the initial setup logic from arm-smmu.
> + *
> + * This private interface is used for the two drivers to coordinate. The
> + * cookie and callback functions are populated when the GPU driver attaches
> + * it's domain.
> + */
> +struct adreno_smmu_priv {
> +const void *cookie;
> +const struct io_pgtable_cfg *(*get_ttbr1_cfg)(const void *cookie);
> +int (*set_ttbr0_cfg)(const void *cookie, const struct io_pgtable_cfg
> *cfg);
> +};
> +
> +#endif /* __ADRENO_SMMU_PRIV_H */
> \ No newline at end of file
> --
> 2.26.2
>
Re: [PATCH] fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode()
On 2020/9/1 1:12, Ira Weiny wrote:
> On Mon, Aug 31, 2020 at 06:13:13PM +0800, Hao Li wrote:
>> If generic_drop_inode() returns true, it means iput_final() can evict
>> this inode regardless of whether it is dirty or not. If we check
>> I_DONTCACHE in generic_drop_inode(), any inode with this bit set will be
>> evicted unconditionally. This is not the desired behavior because
>> I_DONTCACHE only means the inode shouldn't be cached on the LRU list.
>> As for whether we need to evict this inode, this is what
>> generic_drop_inode() should do. This patch corrects the usage of
>> I_DONTCACHE.
>>
>> This patch was proposed in [1].
>>
>> [1]:
>> https://lore.kernel.org/linux-fsdevel/20200831003407.ge12...@dread.disaster.area/
>>
>> Signed-off-by: Hao Li
>
> Thanks! I think this looks good, but shouldn't we add? It seems like this is
> a bug right?
>
> Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer")
Yeah, this is more meaningful.
I'm not sure if I need to submit a v2 patch, or this tag will be added
by the maintainer when applying this patch. I have no experience with
this before. Thanks!
Regards,
Hao Li
>
>
> Reviewed-by: Ira Weiny
>
>> ---
>> fs/inode.c | 3 ++-
>> include/linux/fs.h | 3 +--
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/inode.c b/fs/inode.c
>> index 72c4c347afb7..4e45d5ea3d0f 100644
>> --- a/fs/inode.c
>> +++ b/fs/inode.c
>> @@ -1625,7 +1625,8 @@ static void iput_final(struct inode *inode)
>> else
>> drop = generic_drop_inode(inode);
>>
>> - if (!drop && (sb->s_flags & SB_ACTIVE)) {
>> + if (!drop && !(inode->i_state & I_DONTCACHE) &&
>> + (sb->s_flags & SB_ACTIVE)) {
>> inode_add_lru(inode);
>> spin_unlock(>i_lock);
>> return;
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index e019ea2f1347..93caee80ce47 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -2922,8 +2922,7 @@ extern int inode_needs_sync(struct inode *inode);
>> extern int generic_delete_inode(struct inode *inode);
>> static inline int generic_drop_inode(struct inode *inode)
>> {
>> - return !inode->i_nlink || inode_unhashed(inode) ||
>> - (inode->i_state & I_DONTCACHE);
>> + return !inode->i_nlink || inode_unhashed(inode);
>> }
>> extern void d_mark_dontcache(struct inode *inode);
>>
>> --
>> 2.28.0
>>
>>
>>
>
>
Re: Boot failure on gru-scarlet-inx with 5.9-rc2
On Mon, 31 Aug 2020 10:27:37 +0100
Marc Zyngier wrote:
>
> Ah, so actually anything that *enables pcie* kills your system.
> Great investigative work!
>
> >
> > And backed by a further bisection with this that points to
> > d84c572de1a360501d2e439ac632126f5facf59d being the actual change
> > that causes the tablet to fail to boot, as long as the pcie0 node is
> > identified as pci properly.
> >
> > I am unsure if I should add as a Cc everyone involved in that change
> > set, though the author (coincidentally) is already in the original
> > list of recipients.
>
> I've deliberately moved Rob from Cc to To... ;-)
Thanks, I don't actually know who to write to exactly.
> > Any additional thoughts from this additional information?
>
> What you could do is to start looking at which of the
> pci_is_root_bus() changes breaks PCIe on this system. The fact that
> it breaks on your system and not on mine is a bit puzzling.
Let me show you, on top of v5.9-rc3 I can successfully boot using this
partial revert / adaptation of d84c572d. In addition, it also allows
the Wi-Fi to work again, compared to how it didn't in 5.9-rc1 or
5.9-rc[23] with the dumb revert of your fix.
So, if we number each pci_is_root_bus by order appearance, it is only
the second use, in rockchip_pcie_valid_device, which seem to cause
scarlet not to boot.
The patch (not actually a patch submission) reverts only that instance
of pci_is_root_bus, while also doing some leg work to put back some
functionally equivalent code that was refactored away since.
If there's anything else you want me to try, don't hesitate.
---
drivers/pci/controller/pcie-rockchip-host.c | 8 +++-
drivers/pci/controller/pcie-rockchip.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c
b/drivers/pci/controller/pcie-rockchip-host.c
index 0bb2fb3e8a0b..5a27fa833fbd 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -79,7 +79,7 @@ static int rockchip_pcie_valid_device(struct rockchip_pcie
*rockchip,
* do not read more than one device on the bus directly attached
* to RC's downstream side.
*/
- if (pci_is_root_bus(bus->parent) && dev > 0)
+ if (bus->primary == rockchip->root_bus_nr && dev > 0)
return 0;
return 1;
@@ -944,6 +944,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
struct rockchip_pcie *rockchip;
struct device *dev = >dev;
struct pci_host_bridge *bridge;
+ struct resource *bus_res;
int err;
if (!dev->of_node)
@@ -983,6 +984,11 @@ static int rockchip_pcie_probe(struct platform_device
*pdev)
if (err < 0)
goto err_deinit_port;
+ /* HACK; ~equiv to last param of pci_parse_request_of_pci_ranges */
+ bus_res = (resource_list_first_type(>windows,
IORESOURCE_MEM))->res;
+
+ rockchip->root_bus_nr = bus_res->start;
+
err = rockchip_pcie_cfg_atu(rockchip);
if (err)
goto err_remove_irq_domain;
diff --git a/drivers/pci/controller/pcie-rockchip.h
b/drivers/pci/controller/pcie-rockchip.h
index c7d0178fc8c2..0952fec7e34d 100644
--- a/drivers/pci/controller/pcie-rockchip.h
+++ b/drivers/pci/controller/pcie-rockchip.h
@@ -298,6 +298,7 @@ struct rockchip_pcie {
struct gpio_desc *ep_gpio;
u32 lanes;
u8 lanes_map;
+ u8 root_bus_nr;
int link_gen;
struct device *dev;
struct irq_domain *irq_domain;
--
2.25.4
Thanks again!
--
Samuel Dionne-Riel
Re: [PATCH 2/2] dt-bindings: leds: Add bindings for MT6360 LED
Dan Murphy 於 2020年8月26日 週三 下午7:54寫道： > > Gene > > On 8/26/20 6:37 AM, Gene Chen wrote: > > From: Gene Chen > > > > Add bindings document for LED support on MT6360 PMIC > > Usually bindings are 1/x in the patchset. > ACK > And you should cc Rob Herring and the Device tree mail list other wise > the maintainer will not apply this patch without their ACKs > > ACK > > Signed-off-by: Gene Chen > > --- > > .../devicetree/bindings/leds/leds-mt6360.yaml | 50 > > ++ > > 1 file changed, 50 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6360.yaml > > > > diff --git a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml > > b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml > > new file mode 100644 > > index 000..4598be5 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml > > @@ -0,0 +1,50 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/leds/leds-mt6360.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: LED driver for MT6360 PMIC from MediaTek Integrated. > > + > > +maintainers: > > + - Gene Chen > > + > > +description: | > > + This module is part of the MT6360 MFD device. For more details > > + see Documentation/devicetree/bindings/mfd/mt6360.yaml. > > I think you need to include this yaml using allof tag > > I try add allOf tag allOf: - $ref: "../mfd/mt6360.yaml" then the required property contains mt6360.yaml, which leads to build dt error. /media/gene_chen/WD/upstream/linux/Documentation/devicetree/bindings/leds/leds-mt6360.example.dt.yaml: led-controller: 'reg' is a required property /media/gene_chen/WD/upstream/linux/Documentation/devicetree/bindings/leds/leds-mt6360.example.dt.yaml: led-controller: 'interrupt-controller' is a required property /media/gene_chen/WD/upstream/linux/Documentation/devicetree/bindings/leds/leds-mt6360.example.dt.yaml: led-controller: '#interrupt-cells' is a required property /media/gene_chen/WD/upstream/linux/Documentation/devicetree/bindings/leds/leds-mt6360.example.dt.yaml: led-controller: compatible:0: 'mediatek,mt6360' was expected I think I can remove this description for misread. > > + > > + The LED controller is represented as a sub-node of the PMIC node on > > + the device tree. > > + > > + This device has six current sinks. > > + > > +properties: > > + compatible: > > +const: mediatek,mt6360-led > > + > > + "#address-cells": > > +const: 1 > > + > > + "#size-cells": > > +const: 0 > > + > > +patternProperties: > > + "^led@[0-5]$": > > +type: object > > +description: | > > + Properties for a single LED. > > + > > +properties: > > + reg: > > +description: > > + Index of the LED. > > +minimum: 0 > > +maximum: 5 > > + > > +required: > > + - compatible > > + - "#address-cells" > > + - "#size-cells" > > +additionalProperties: false > > + > Need a new line > > > And an example > > > +...
[PATCH] Documentation/x86/boot.rst: minor improvement
Typo fix & file name update Signed-off-by: Cao jin --- Documentation/x86/boot.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst index 7fafc7ac00d7..c04afec90486 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -1379,7 +1379,7 @@ can be calculated as follows:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as described -in zero-page.txt. +in zero-page.rst. After setting up the struct boot_params, the boot loader can load 64-bit kernel in the same way as that of 16-bit boot protocol, but @@ -1391,7 +1391,7 @@ In 64-bit boot protocol, the kernel is started by jumping to the At entry, the CPU must be in 64-bit mode with paging enabled. The range with setup_header.init_size from start address of loaded -kernel and zero page and command line buffer get ident mapping; +kernel and zero page and command line buffer get identity mapping; a GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat segment; __BOOT_CS must have execute/read permission, and __BOOT_DS -- 2.21.0
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson
wrote:
>
> On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
>
> > From: Rob Clark
> >
> > Currently it doesn't matter, since we free the ctx immediately. But
> > when we start refcnt'ing the ctx, we don't want old dangling list
> > entries to hang around.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > index a1d94be7883a..90c9d84e6155 100644
> > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
> >* No lock needed in close and there won't
> >* be any more user ioctls coming our way
> >*/
> > - list_for_each_entry_safe(entry, tmp, >submitqueues, node)
> > + list_for_each_entry_safe(entry, tmp, >submitqueues, node) {
> > + list_del(>node);
>
> If you refcount ctx, what does that do for the entries in the submit
> queue?
>
> "entry" here is kref'ed, but you're popping it off the list regardless
> of the put ends up freeing the object or not - which afaict would mean
> leaking the object.
>
What ends up happening is the submit has reference to submit-queue,
which has reference to the ctx.. the submitqueue could be alive still
pending in-flight submits (in a later patch), but dead from the PoV of
userspace interface.
We aren't relying (or at least aren't in the end, and I *think* I
didn't miss anything in the middle) relying on ctx->submitqueues list
to clean anything up in the end, just track what is still a valid
submitqueue from userspace PoV
BR,
-R
>
> On the other hand, with the current implementation an object with higher
> refcount with adjacent objects of single refcount would end up with
> dangling pointers after the put. So in itself this change seems like a
> net gain, but I'm wondering about the plan described in the commit
> message.
>
> Regards,
> Bjorn
>
> > msm_submitqueue_put(entry);
> > + }
> > }
> >
> > int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> > *ctx,
> > --
> > 2.26.2
> >
Re: [PATCH 03/19] iommu/arm-smmu: Add support for split pagetables
On Thu 13 Aug 21:40 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Enable TTBR1 for a context bank if IO_PGTABLE_QUIRK_ARM_TTBR1 is selected
> by the io-pgtable configuration.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 21 -
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 25 +++--
> 2 files changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 37d8d49299b4..976d43a7f2ff 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -552,11 +552,15 @@ static void arm_smmu_init_context_bank(struct
> arm_smmu_domain *smmu_domain,
> cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
> cb->ttbr[1] = 0;
> } else {
> - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> - cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> - cfg->asid);
> + cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> + cfg->asid);
> cb->ttbr[1] = FIELD_PREP(ARM_SMMU_TTBRn_ASID,
> - cfg->asid);
> + cfg->asid);
The old indentation seems more appropriate.
Apart from that this looks sensible.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> +
> + if (pgtbl_cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> + cb->ttbr[1] |= pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> + else
> + cb->ttbr[0] |= pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> }
> } else {
> cb->ttbr[0] = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
> @@ -822,7 +826,14 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
>
> /* Update the domain's page sizes to reflect the page table format */
> domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
> - domain->geometry.aperture_end = (1UL << ias) - 1;
> +
> + if (pgtbl_cfg.quirks & IO_PGTABLE_QUIRK_ARM_TTBR1) {
> + domain->geometry.aperture_start = ~0UL << ias;
> + domain->geometry.aperture_end = ~0UL;
> + } else {
> + domain->geometry.aperture_end = (1UL << ias) - 1;
> + }
> +
> domain->geometry.force_aperture = true;
>
> /* Initialise the context bank with our page table cfg */
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 83294516ac08..f3e456893f28 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -169,10 +169,12 @@ enum arm_smmu_cbar_type {
> #define ARM_SMMU_CB_TCR 0x30
> #define ARM_SMMU_TCR_EAE BIT(31)
> #define ARM_SMMU_TCR_EPD1BIT(23)
> +#define ARM_SMMU_TCR_A1 BIT(22)
> #define ARM_SMMU_TCR_TG0 GENMASK(15, 14)
> #define ARM_SMMU_TCR_SH0 GENMASK(13, 12)
> #define ARM_SMMU_TCR_ORGN0 GENMASK(11, 10)
> #define ARM_SMMU_TCR_IRGN0 GENMASK(9, 8)
> +#define ARM_SMMU_TCR_EPD0BIT(7)
> #define ARM_SMMU_TCR_T0SZGENMASK(5, 0)
>
> #define ARM_SMMU_VTCR_RES1 BIT(31)
> @@ -350,12 +352,23 @@ struct arm_smmu_domain {
>
> static inline u32 arm_smmu_lpae_tcr(struct io_pgtable_cfg *cfg)
> {
> - return ARM_SMMU_TCR_EPD1 |
> -FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> -FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> -FIELD_PREP(ARM_SMMU_TCR_ORGN0, cfg->arm_lpae_s1_cfg.tcr.orgn) |
> -FIELD_PREP(ARM_SMMU_TCR_IRGN0, cfg->arm_lpae_s1_cfg.tcr.irgn) |
> -FIELD_PREP(ARM_SMMU_TCR_T0SZ, cfg->arm_lpae_s1_cfg.tcr.tsz);
> + u32 tcr = FIELD_PREP(ARM_SMMU_TCR_TG0, cfg->arm_lpae_s1_cfg.tcr.tg) |
> + FIELD_PREP(ARM_SMMU_TCR_SH0, cfg->arm_lpae_s1_cfg.tcr.sh) |
> + FIELD_PREP(ARM_SMMU_TCR_ORGN0, cfg->arm_lpae_s1_cfg.tcr.orgn) |
> + FIELD_PREP(ARM_SMMU_TCR_IRGN0, cfg->arm_lpae_s1_cfg.tcr.irgn) |
> + FIELD_PREP(ARM_SMMU_TCR_T0SZ, cfg->arm_lpae_s1_cfg.tcr.tsz);
> +
> + /*
> + * When TTBR1 is selected shift the TCR fields by 16 bits and disable
> + * translation in TTBR0
> + */
> + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1) {
> + tcr = (tcr << 16) & ~ARM_SMMU_TCR_A1;
> + tcr |= ARM_SMMU_TCR_EPD0;
> + } else
> + tcr |= ARM_SMMU_TCR_EPD1;
> +
> + return tcr;
> }
>
> static inline u32 arm_smmu_lpae_tcr2(struct io_pgtable_cfg *cfg)
> --
> 2.26.2
>
I'AM SUFFERING FROM CANCER OF THE HEART
I'AM SUFFERING FROM CANCER OF THE HEART Dear Friend. Greetings to you in the name of the Lord God Almighty am MRS RUKIA NIMINE From (Paris) France, but am based in Burkina Faso Africa for eight years now as a business woman dealing on gold exportation and cotton Sales. But I have been suffering from this deadly disease called cancer for long and the doctor just said I have just few days to leave. I know it will be difficult for you to believe my story now, but this is the situation I found myself in, it’s not my desire to be on a sick bed today but God knows best, Now that I am about to end the race like this, without any family Members and no child. I have $5.8 Million US DOLLARS in BANK OF AFRICA (B.O.A) Burkina Faso it’s all my life savings, I instructed the Bank to give it to St Andrews Missionary and Home Kizito Orphanage in Burkina Faso. But my mind is not at rest because i do not trust them, I am writing this letter now through the help of my computer beside my sick bed. I will instruct the bank to transfer this fund to you as a foreigner but you have to promise me that you will take 40 Percent(%) of the total money for your personal use While 60 Percent (%) of the money will go to charity, Orphanages and less Privileges" people in the street and helping the Needed. I grew up as an Orphan and I don't have anybody as my family member, just to Endeavour that the house of God is maintained. Am doing this so that God will forgive my sins and accept my soul because these sicknesses have suffered me so much. As soon as I receive your reply I shall give you the contact of the bank and I will also instruct my Bank Manger to issue you an authority letter that will prove you the present beneficiary of the money in the bank that is if you assure me that you will act accordingly as I Stated herein. I look forward to getting a reply from you. Thanks and God bless you, MRS RUKIA NIMINE
[PATCH v4 0/5] iommu aux-domain APIs extensions
This series aims to extend the IOMMU aux-domain API set so that it
could be more friendly to vfio/mdev usage. The interactions between
vfio/mdev and iommu during mdev creation and passthr are:
1. Create a group for mdev with iommu_group_alloc();
2. Add the device to the group with
group = iommu_group_alloc();
if (IS_ERR(group))
return PTR_ERR(group);
ret = iommu_group_add_device(group, >dev);
if (!ret)
dev_info(>dev, "MDEV: group_id = %d\n",
iommu_group_id(group));
3. Allocate an aux-domain with iommu_domain_alloc();
4. Attach the aux-domain to the iommu_group.
iommu_group_for_each_dev {
if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
return iommu_aux_attach_device(domain, iommu_device);
else
return iommu_attach_device(domain, iommu_device);
}
where, iommu_device is the aux-domain-capable device. The mdev's in
the group are all derived from it.
In the whole process, an iommu group was allocated for the mdev and an
iommu domain was attached to the group, but the group->domain leaves
NULL. As the result, iommu_get_domain_for_dev() (or other similar
interfaces) doesn't work anymore.
The iommu_get_domain_for_dev() is a necessary interface for device
drivers that want to support vfio/mdev based aux-domain. For example,
unsigned long pasid;
struct iommu_domain *domain;
struct device *dev = mdev_dev(mdev);
struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
domain = iommu_aux_get_domain_for_dev(dev);
if (!domain)
return -ENODEV;
pasid = iommu_aux_get_pasid(domain, iommu_device);
if (pasid <= 0)
return -EINVAL;
/* Program the device context */
We tried to address this by extending iommu_aux_at(de)tach_device() so that
the users could pass in an optional device pointer (for example vfio/mdev).
(v2 of this series)
https://lore.kernel.org/linux-iommu/20200707013957.23672-1-baolu...@linux.intel.com/
But that will cause a lock issue as group->mutex has been applied in
iommu_group_for_each_dev(), but has to be reapplied again in the
iommu_aux_attach_device().
We also tried to implement an equivalent iommu_attch_group() for groups
which includes subdevices derived from a single physical device. (v3 of
this series)
https://lore.kernel.org/linux-iommu/20200714055703.5510-1-baolu...@linux.intel.com/
But that's too harsh (requires that all subdevices in an iommu_group
must be derived from a same physical device) and breaks some generic
concept of iommmu_group.
This version continues to address this by introducing some new APIs into
the aux-domain API set according to comments during v3 reviewing period.
/**
* iommu_attach_subdev_group - attach domain to an iommu_group which
* contains subdevices.
*
* @domain: domain
* @group: iommu_group which contains subdevices
* @fn: callback for each subdevice in the @iommu_group to retrieve the
* physical device where the subdevice was created from.
*
* Returns 0 on success, or an error value.
*/
int iommu_attach_subdev_group(struct iommu_domain *domain,
struct iommu_group *group,
iommu_device_lookup_t fn)
/**
* iommu_detach_subdev_group - detach domain from an iommu_group which
* contains subdevices
*
* @domain: domain
* @group: iommu_group which contains subdevices
* @fn: callback for each subdevice in the @iommu_group to retrieve the
* physical device where the subdevice was created from.
*
* The domain must have been attached to @group via iommu_attach_subdev_group().
*/
void iommu_detach_subdev_group(struct iommu_domain *domain,
struct iommu_group *group,
iommu_device_lookup_t fn)
struct iommu_domain *iommu_aux_get_domain_for_dev(struct device *subdev)
This version is evolved according to feedbacks from Robin, Alex and Kevin.
I'm very appreciated to their contributions.
Best regards,
baolu
---
Change log:
- v1->v2:
-
https://lore.kernel.org/linux-iommu/20200627031532.28046-1-baolu...@linux.intel.com/
- Suggested by Robin.
- v2->v3:
-
https://lore.kernel.org/linux-iommu/20200707013957.23672-1-baolu...@linux.intel.com/
- Suggested by Alex, Kevin.
- v3->v4:
-
https://lore.kernel.org/linux-iommu/20200714055703.5510-1-baolu...@linux.intel.com/
- Evolve the aux_attach_group APIs to take an iommu_device lookup
callback.
- Add interface to check whether a domain is aux-domain for a device.
- Return domain only if the domain is aux-domain in
iommu_aux_get_domain_for_dev().
Lu Baolu (5):
iommu: Add optional subdev in aux_at(de)tach ops
iommu: Add iommu_at(de)tach_subdev_group()
[PATCH v4 3/5] iommu: Add iommu_aux_get_domain_for_dev()
The device driver needs an API to get its aux-domain. A typical usage
scenario is:
unsigned long pasid;
struct iommu_domain *domain;
struct device *dev = mdev_dev(mdev);
struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
domain = iommu_aux_get_domain_for_dev(dev);
if (!domain)
return -ENODEV;
pasid = iommu_aux_get_pasid(domain, iommu_device);
if (pasid <= 0)
return -EINVAL;
/* Program the device context */
This adds an API for such use case.
Suggested-by: Alex Williamson
Link: https://lore.kernel.org/linux-iommu/20200708130749.1b1e1...@x1.home/
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 18 ++
include/linux/iommu.h | 20
2 files changed, 38 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index fb21c2ff4861..8fd93a5b8764 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2893,6 +2893,24 @@ void iommu_detach_subdev_group(struct iommu_domain
*domain,
}
EXPORT_SYMBOL_GPL(iommu_detach_subdev_group);
+struct iommu_domain *iommu_aux_get_domain_for_dev(struct device *subdev)
+{
+ struct iommu_domain *domain = NULL;
+ struct iommu_group *group;
+
+ group = iommu_group_get(subdev);
+ if (!group || !group->domain)
+ return NULL;
+
+ if (domain_is_aux(group->domain, subdev))
+ domain = group->domain;
+
+ iommu_group_put(group);
+
+ return domain;
+}
+EXPORT_SYMBOL_GPL(iommu_aux_get_domain_for_dev);
+
/**
* iommu_sva_bind_device() - Bind a process address space to a device
* @dev: the device
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b9df8b510d4f..ea660a887dbf 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -120,6 +120,7 @@ enum iommu_attr {
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
DOMAIN_ATTR_MAX,
+ DOMAIN_ATTR_IS_AUX,
};
/* These are the possible reserved region types */
@@ -622,6 +623,12 @@ static inline void dev_iommu_priv_set(struct device *dev,
void *priv)
dev->iommu->priv = priv;
}
+static inline bool
+domain_is_aux(struct iommu_domain *domain, struct device *subdev)
+{
+ return iommu_domain_get_attr(domain, DOMAIN_ATTR_IS_AUX, subdev);
+}
+
int iommu_probe_device(struct device *dev);
void iommu_release_device(struct device *dev);
@@ -638,6 +645,7 @@ int iommu_attach_subdev_group(struct iommu_domain *domain,
void iommu_detach_subdev_group(struct iommu_domain *domain,
struct iommu_group *group,
iommu_device_lookup_t fn);
+struct iommu_domain *iommu_aux_get_domain_for_dev(struct device *subdev);
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
struct mm_struct *mm,
@@ -1039,6 +1047,18 @@ iommu_detach_subdev_group(struct iommu_domain *domain,
struct iommu_group *group
{
}
+static inline bool
+domain_is_aux(struct iommu_domain *domain, struct device *subdev)
+{
+ return false;
+}
+
+static inline struct iommu_domain *
+iommu_aux_get_domain_for_dev(struct device *subdev)
+{
+ return NULL;
+}
+
static inline struct iommu_sva *
iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata)
{
--
2.17.1
[PATCH v4 5/5] iommu/vt-d: Add is_aux_domain support
With subdevice information opt-in through iommu_ops.aux_at(de)tach_dev()
interfaces, the vendor iommu driver is able to learn the knowledge about
the relationships between the subdevices and the aux-domains. Implement
is_aux_domain() support based on the relationship knowledges.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 125 ++--
include/linux/intel-iommu.h | 17 +++--
2 files changed, 103 insertions(+), 39 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 3c12fd06856c..50431c7b2e71 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -334,6 +334,8 @@ static int intel_iommu_attach_device(struct iommu_domain
*domain,
struct device *dev);
static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova);
+static bool intel_iommu_dev_feat_enabled(struct device *dev,
+enum iommu_dev_features feat);
#ifdef CONFIG_INTEL_IOMMU_DEFAULT_ON
int dmar_disabled = 0;
@@ -1832,6 +1834,7 @@ static struct dmar_domain *alloc_domain(int flags)
domain->flags |= DOMAIN_FLAG_USE_FIRST_LEVEL;
domain->has_iotlb_device = false;
INIT_LIST_HEAD(>devices);
+ INIT_LIST_HEAD(>subdevices);
return domain;
}
@@ -2580,7 +2583,7 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
info->iommu = iommu;
info->pasid_table = NULL;
info->auxd_enabled = 0;
- INIT_LIST_HEAD(>auxiliary_domains);
+ INIT_LIST_HEAD(>subdevices);
if (dev && dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(info->dev);
@@ -5137,21 +5140,28 @@ static void intel_iommu_domain_free(struct iommu_domain
*domain)
domain_exit(to_dmar_domain(domain));
}
-/*
- * Check whether a @domain could be attached to the @dev through the
- * aux-domain attach/detach APIs.
- */
-static inline bool
-is_aux_domain(struct device *dev, struct iommu_domain *domain)
+/* Lookup subdev_info in the domain's subdevice siblings. */
+static struct subdev_info *
+subdev_lookup_domain(struct dmar_domain *domain, struct device *dev,
+struct device *subdev)
{
- struct device_domain_info *info = get_domain_info(dev);
+ struct subdev_info *sinfo = NULL, *tmp;
- return info && info->auxd_enabled &&
- domain->type == IOMMU_DOMAIN_UNMANAGED;
+ assert_spin_locked(_domain_lock);
+
+ list_for_each_entry(tmp, >subdevices, link_domain) {
+ if ((!dev || tmp->pdev == dev) && tmp->dev == subdev) {
+ sinfo = tmp;
+ break;
+ }
+ }
+
+ return sinfo;
}
-static void auxiliary_link_device(struct dmar_domain *domain,
- struct device *dev)
+static void
+subdev_link_device(struct dmar_domain *domain, struct device *dev,
+ struct subdev_info *sinfo)
{
struct device_domain_info *info = get_domain_info(dev);
@@ -5159,12 +5169,13 @@ static void auxiliary_link_device(struct dmar_domain
*domain,
if (WARN_ON(!info))
return;
- domain->auxd_refcnt++;
- list_add(>auxd, >auxiliary_domains);
+ list_add(>subdevices, >link_phys);
+ list_add(>subdevices, >link_domain);
}
-static void auxiliary_unlink_device(struct dmar_domain *domain,
- struct device *dev)
+static void
+subdev_unlink_device(struct dmar_domain *domain, struct device *dev,
+struct subdev_info *sinfo)
{
struct device_domain_info *info = get_domain_info(dev);
@@ -5172,24 +5183,30 @@ static void auxiliary_unlink_device(struct dmar_domain
*domain,
if (WARN_ON(!info))
return;
- list_del(>auxd);
- domain->auxd_refcnt--;
+ list_del(>link_phys);
+ list_del(>link_domain);
+ kfree(sinfo);
- if (!domain->auxd_refcnt && domain->default_pasid > 0)
+ if (list_empty(>subdevices) && domain->default_pasid > 0)
ioasid_free(domain->default_pasid);
}
-static int aux_domain_add_dev(struct dmar_domain *domain,
- struct device *dev)
+static int aux_domain_add_dev(struct dmar_domain *domain, struct device *dev,
+ struct device *subdev)
{
int ret;
unsigned long flags;
struct intel_iommu *iommu;
+ struct subdev_info *sinfo;
iommu = device_to_iommu(dev, NULL, NULL);
if (!iommu)
return -ENODEV;
+ sinfo = kzalloc(sizeof(*sinfo), GFP_KERNEL);
+ if (!sinfo)
+ return -ENOMEM;
+
if (domain->default_pasid <= 0) {
int pasid;
@@ -5199,7 +5216,8 @@ static int aux_domain_add_dev(struct
[PATCH v4 4/5] vfio/type1: Use iommu_aux_at(de)tach_group() APIs
Replace iommu_aux_at(de)tach_device() with iommu_at(de)tach_subdev_group().
Signed-off-by: Lu Baolu
---
drivers/vfio/vfio_iommu_type1.c | 43 +
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 5e556ac9102a..8d5eb7ce0986 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1627,45 +1627,13 @@ static struct device *vfio_mdev_get_iommu_device(struct
device *dev)
return NULL;
}
-static int vfio_mdev_attach_domain(struct device *dev, void *data)
-{
- struct iommu_domain *domain = data;
- struct device *iommu_device;
-
- iommu_device = vfio_mdev_get_iommu_device(dev);
- if (iommu_device) {
- if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
- return iommu_aux_attach_device(domain, iommu_device);
- else
- return iommu_attach_device(domain, iommu_device);
- }
-
- return -EINVAL;
-}
-
-static int vfio_mdev_detach_domain(struct device *dev, void *data)
-{
- struct iommu_domain *domain = data;
- struct device *iommu_device;
-
- iommu_device = vfio_mdev_get_iommu_device(dev);
- if (iommu_device) {
- if (iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX))
- iommu_aux_detach_device(domain, iommu_device);
- else
- iommu_detach_device(domain, iommu_device);
- }
-
- return 0;
-}
-
static int vfio_iommu_attach_group(struct vfio_domain *domain,
struct vfio_group *group)
{
if (group->mdev_group)
- return iommu_group_for_each_dev(group->iommu_group,
- domain->domain,
- vfio_mdev_attach_domain);
+ return iommu_attach_subdev_group(domain->domain,
+group->iommu_group,
+vfio_mdev_get_iommu_device);
else
return iommu_attach_group(domain->domain, group->iommu_group);
}
@@ -1674,8 +1642,9 @@ static void vfio_iommu_detach_group(struct vfio_domain
*domain,
struct vfio_group *group)
{
if (group->mdev_group)
- iommu_group_for_each_dev(group->iommu_group, domain->domain,
-vfio_mdev_detach_domain);
+ iommu_detach_subdev_group(domain->domain,
+ group->iommu_group,
+ vfio_mdev_get_iommu_device);
else
iommu_detach_group(domain->domain, group->iommu_group);
}
--
2.17.1
[PATCH v4 1/5] iommu: Add optional subdev in aux_at(de)tach ops
In the vfio/mdev use case of aux-domain, the subdevices are created from
the physical devices with IOMMU_DEV_FEAT_AUX enabled and the aux-domains
are attached to the subdevices through the iommu_ops.aux_attach_dev()
interface.
Current iommu_ops.aux_at(de)tach_dev() design only takes the aux-domain
and the physical device as the parameters, this is insufficient if we
want the vendor iommu drivers to learn the knowledge about relationships
between the aux-domains and the subdevices. Add a @subdev parameter to
iommu_ops.aux_at(de)tach_dev() interfaces so that a subdevice could be
opt-in.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 10 ++
drivers/iommu/iommu.c | 4 ++--
include/linux/iommu.h | 6 --
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index bce158468abf..3c12fd06856c 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5338,8 +5338,9 @@ static int intel_iommu_attach_device(struct iommu_domain
*domain,
return domain_add_dev_info(to_dmar_domain(domain), dev);
}
-static int intel_iommu_aux_attach_device(struct iommu_domain *domain,
-struct device *dev)
+static int
+intel_iommu_aux_attach_device(struct iommu_domain *domain,
+ struct device *dev, struct device *subdev)
{
int ret;
@@ -5359,8 +5360,9 @@ static void intel_iommu_detach_device(struct iommu_domain
*domain,
dmar_remove_one_dev_info(dev);
}
-static void intel_iommu_aux_detach_device(struct iommu_domain *domain,
- struct device *dev)
+static void
+intel_iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev,
+ struct device *subdev)
{
aux_domain_remove_dev(to_dmar_domain(domain), dev);
}
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 609bd25bf154..38cdfeb887e1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2728,7 +2728,7 @@ int iommu_aux_attach_device(struct iommu_domain *domain,
struct device *dev)
int ret = -ENODEV;
if (domain->ops->aux_attach_dev)
- ret = domain->ops->aux_attach_dev(domain, dev);
+ ret = domain->ops->aux_attach_dev(domain, dev, NULL);
if (!ret)
trace_attach_device_to_domain(dev);
@@ -2740,7 +2740,7 @@ EXPORT_SYMBOL_GPL(iommu_aux_attach_device);
void iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev)
{
if (domain->ops->aux_detach_dev) {
- domain->ops->aux_detach_dev(domain, dev);
+ domain->ops->aux_detach_dev(domain, dev, NULL);
trace_detach_device_from_domain(dev);
}
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index fee209efb756..871267104915 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -279,8 +279,10 @@ struct iommu_ops {
int (*dev_disable_feat)(struct device *dev, enum iommu_dev_features f);
/* Aux-domain specific attach/detach entries */
- int (*aux_attach_dev)(struct iommu_domain *domain, struct device *dev);
- void (*aux_detach_dev)(struct iommu_domain *domain, struct device *dev);
+ int (*aux_attach_dev)(struct iommu_domain *domain, struct device *dev,
+ struct device *subdev);
+ void (*aux_detach_dev)(struct iommu_domain *domain, struct device *dev,
+ struct device *subdev);
int (*aux_get_pasid)(struct iommu_domain *domain, struct device *dev);
struct iommu_sva *(*sva_bind)(struct device *dev, struct mm_struct *mm,
--
2.17.1
[PATCH v4 2/5] iommu: Add iommu_at(de)tach_subdev_group()
This adds two new APIs for the use cases like vfio/mdev where subdevices
derived from physical devices are created and put in an iommu_group. The
new IOMMU API interfaces mimic the vfio_mdev_at(de)tach_domain() directly,
testing whether the resulting device supports IOMMU_DEV_FEAT_AUX and using
an aux vs non-aux at(de)tach.
By doing this we could
- Set the iommu_group.domain. The iommu_group.domain is private to iommu
core (therefore vfio code cannot set it), but we need it set in order
for iommu_get_domain_for_dev() to work with a group attached to an aux
domain.
- Prefer to use the _attach_group() interfaces while the _attach_device()
interfaces are relegated to special cases.
Link: https://lore.kernel.org/linux-iommu/20200730134658.44c57...@x1.home/
Link: https://lore.kernel.org/linux-iommu/20200730151703.5daf8...@x1.home/
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 136 ++
include/linux/iommu.h | 20 +++
2 files changed, 156 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 38cdfeb887e1..fb21c2ff4861 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2757,6 +2757,142 @@ int iommu_aux_get_pasid(struct iommu_domain *domain,
struct device *dev)
}
EXPORT_SYMBOL_GPL(iommu_aux_get_pasid);
+static int __iommu_aux_attach_device(struct iommu_domain *domain,
+struct device *phys_dev,
+struct device *sub_dev)
+{
+ int ret;
+
+ if (unlikely(!domain->ops->aux_attach_dev))
+ return -ENODEV;
+
+ ret = domain->ops->aux_attach_dev(domain, phys_dev, sub_dev);
+ if (!ret)
+ trace_attach_device_to_domain(sub_dev);
+
+ return ret;
+}
+
+static void __iommu_aux_detach_device(struct iommu_domain *domain,
+ struct device *phys_dev,
+ struct device *sub_dev)
+{
+ if (unlikely(!domain->ops->aux_detach_dev))
+ return;
+
+ domain->ops->aux_detach_dev(domain, phys_dev, sub_dev);
+ trace_detach_device_from_domain(sub_dev);
+}
+
+static int __iommu_attach_subdev_group(struct iommu_domain *domain,
+ struct iommu_group *group,
+ iommu_device_lookup_t fn)
+{
+ struct group_device *device;
+ struct device *phys_dev;
+ int ret = -ENODEV;
+
+ list_for_each_entry(device, >devices, list) {
+ phys_dev = fn(device->dev);
+ if (!phys_dev) {
+ ret = -ENODEV;
+ break;
+ }
+
+ if (iommu_dev_feature_enabled(phys_dev, IOMMU_DEV_FEAT_AUX))
+ ret = __iommu_aux_attach_device(domain, phys_dev,
+ device->dev);
+ else
+ ret = __iommu_attach_device(domain, phys_dev);
+
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+static void __iommu_detach_subdev_group(struct iommu_domain *domain,
+ struct iommu_group *group,
+ iommu_device_lookup_t fn)
+{
+ struct group_device *device;
+ struct device *phys_dev;
+
+ list_for_each_entry(device, >devices, list) {
+ phys_dev = fn(device->dev);
+ if (!phys_dev)
+ break;
+
+ if (iommu_dev_feature_enabled(phys_dev, IOMMU_DEV_FEAT_AUX))
+ __iommu_aux_detach_device(domain, phys_dev,
device->dev);
+ else
+ __iommu_detach_device(domain, phys_dev);
+ }
+}
+
+/**
+ * iommu_attach_subdev_group - attach domain to an iommu_group which
+ *contains subdevices.
+ *
+ * @domain: domain
+ * @group: iommu_group which contains subdevices
+ * @fn: callback for each subdevice in the @iommu_group to retrieve the
+ * physical device where the subdevice was created from.
+ *
+ * Returns 0 on success, or an error value.
+ */
+int iommu_attach_subdev_group(struct iommu_domain *domain,
+ struct iommu_group *group,
+ iommu_device_lookup_t fn)
+{
+ int ret = -ENODEV;
+
+ mutex_lock(>mutex);
+ if (group->domain) {
+ ret = -EBUSY;
+ goto unlock_out;
+ }
+
+ ret = __iommu_attach_subdev_group(domain, group, fn);
+ if (ret)
+ __iommu_detach_subdev_group(domain, group, fn);
+ else
+ group->domain = domain;
+
+unlock_out:
+ mutex_unlock(>mutex);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_attach_subdev_group);
+
+/**
+ * iommu_detach_subdev_group - detach domain from an iommu_group which
+ *contains subdevices
+
Re: [RFC PATCH v7 08/23] sched: Add core wide task selection and scheduling.
On Sat, Aug 29, 2020 at 09:47:19AM +0200, pet...@infradead.org wrote:
> On Fri, Aug 28, 2020 at 06:02:25PM -0400, Vineeth Pillai wrote:
> > On 8/28/20 4:51 PM, Peter Zijlstra wrote:
>
> > > So where do things go side-ways?
>
> > During hotplug stress test, we have noticed that while a sibling is in
> > pick_next_task, another sibling can go offline or come online. What
> > we have observed is smt_mask get updated underneath us even if
> > we hold the lock. From reading the code, looks like we don't hold the
> > rq lock when the mask is updated. This extra logic was to take care of that.
>
> Sure, the mask is updated async, but _where_ is the actual problem with
> that?
>
> On Fri, Aug 28, 2020 at 06:23:55PM -0400, Joel Fernandes wrote:
> > Thanks Vineeth. Peter, also the "v6+" series (which were some addons on v6)
> > detail the individual hotplug changes squashed into this patch:
> > https://lore.kernel.org/lkml/20200815031908.1015049-9-j...@joelfernandes.org/
> > https://lore.kernel.org/lkml/20200815031908.1015049-11-j...@joelfernandes.org/
>
> That one looks fishy, the pick is core wide, making that pick_seq per rq
> just doesn't make sense.
>
> > https://lore.kernel.org/lkml/20200815031908.1015049-12-j...@joelfernandes.org/
>
> This one reads like tinkering, there is no description of the actual
> problem just some code that makes a symptom go away.
>
> Sure, on hotplug the smt mask can change, but only for a CPU that isn't
> actually scheduling, so who cares.
>
> /me re-reads the hotplug code...
>
> ..ooOO is the problem that we clear the cpumasks on take_cpu_down()
> instead of play_dead() ?! That should be fixable.
That is indeed the problem.
I was wondering, is there any harm in just selecting idle task if the CPU
calling schedule() is missing from cpu_smt_mask? Does it need to do a
core-wide selection?
That would be best, and avoid any unnecessary surgery of the already
complicated function. This is sort of what Tim was doing in v4 and v5.
Also what do we do if cpu_smt_mask changing while this function is running? I
tried something like the following and it solves the issues but the overhead
probably really sucks. I was thinking of doing a variation of the below that
just stored the cpu_smt_mask's rq pointers in an array of size SMTS_PER_CORE
on the stack, instead of a cpumask but I am not sure if that will keep the
code clean while still having similar storage overhead.
---8<---
>From 5e905e7e620177075a9bcf78fb0dc89a136434bb Mon Sep 17 00:00:00 2001
From: Joel Fernandes
Date: Tue, 30 Jun 2020 19:39:45 -0400
Subject: [PATCH] Fix CPU hotplug causing crashes in task selection logic
Signed-off-by: Joel Fernandes
---
kernel/sched/core.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0362102fa3d2..47a21013ba0d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4464,7 +4464,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
{
struct task_struct *next, *max = NULL;
const struct sched_class *class;
- const struct cpumask *smt_mask;
+ struct cpumask select_mask;
int i, j, cpu, occ = 0;
bool need_sync;
@@ -4499,7 +4499,13 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
finish_prev_task(rq, prev, rf);
cpu = cpu_of(rq);
- smt_mask = cpu_smt_mask(cpu);
+ cpumask_copy(_mask, cpu_smt_mask(cpu));
+
+ /*
+* Always make sure current CPU is added to smt_mask so that below
+* selection logic runs on it.
+*/
+ cpumask_set_cpu(cpu, _mask);
/*
* core->core_task_seq, core->core_pick_seq, rq->core_sched_seq
@@ -4516,7 +4522,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
/* reset state */
rq->core->core_cookie = 0UL;
- for_each_cpu(i, smt_mask) {
+ for_each_cpu(i, _mask) {
struct rq *rq_i = cpu_rq(i);
rq_i->core_pick = NULL;
@@ -4536,7 +4542,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
*/
for_each_class(class) {
again:
- for_each_cpu_wrap(i, smt_mask, cpu) {
+ for_each_cpu_wrap(i, _mask, cpu) {
struct rq *rq_i = cpu_rq(i);
struct task_struct *p;
@@ -4600,7 +4608,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
trace_printk("max: %s/%d %lx\n", max->comm,
max->pid, max->core_cookie);
if (old_max) {
- for_each_cpu(j, smt_mask) {
+ for_each_cpu(j, _mask) {
if (j == i)
Re: [PATCH] io_uring: Fix NULL pointer dereference in io_sq_wq_submit_work()
On 8/31/20 7:54 PM, Xin Yin wrote:
> the commit <1c4404efcf2c0> (" is canceled on exit>") caused a crash in io_sq_wq_submit_work().
> when io_ring-wq get a req form async_list, which may not have been
> added to task_list. Then try to delete the req from task_list will caused
> a "NULL pointer dereference".
Hmm, do you have a reproducer for this?
> @@ -2356,9 +2358,11 @@ static void io_sq_wq_submit_work(struct work_struct
> *work)
> * running. We currently only allow this if the new request is sequential
> * to the previous one we punted.
> */
> -static bool io_add_to_prev_work(struct async_list *list, struct io_kiocb
> *req)
> +static bool io_add_to_prev_work(struct async_list *list, struct io_kiocb
> *req,
> + struct io_ring_ctx *ctx)
> {
> bool ret;
> + unsigned long flags;
>
> if (!list)
> return false;
> @@ -2378,6 +2382,13 @@ static bool io_add_to_prev_work(struct async_list
> *list, struct io_kiocb *req)
> list_del_init(>list);
> ret = false;
> }
> +
> + if (ret) {
> + spin_lock_irqsave(>task_lock, flags);
> + list_add(>task_list, >task_list);
> + req->work_task = NULL;
> + spin_unlock_irqrestore(>task_lock, flags);
> + }
> spin_unlock(>lock);
> return ret;
> }
> @@ -2454,7 +2465,7 @@ static int __io_queue_sqe(struct io_ring_ctx *ctx,
> struct io_kiocb *req,
> s->sqe = sqe_copy;
> memcpy(>submit, s, sizeof(*s));
> list = io_async_list_from_req(ctx, req);
> - if (!io_add_to_prev_work(list, req)) {
> + if (!io_add_to_prev_work(list, req, ctx)) {
> if (list)
> atomic_inc(>cnt);
> INIT_WORK(>work, io_sq_wq_submit_work);
>
ctx == req->ctx, so you should not need that change.
--
Jens Axboe
Re: [PATCH 02/19] iommu/arm-smmu: Pass io-pgtable config to implementation specific function
On Thu 13 Aug 21:40 CDT 2020, Rob Clark wrote:
> From: Jordan Crouse
>
> Construct the io-pgtable config before calling the implementation specific
> init_context function and pass it so the implementation specific function
> can get a chance to change it before the io-pgtable is created.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 ++-
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 11 ++-
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 ++-
> 3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index f4ff124a1967..a9861dcd0884 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -68,7 +68,8 @@ static int cavium_cfg_probe(struct arm_smmu_device *smmu)
> return 0;
> }
>
> -static int cavium_init_context(struct arm_smmu_domain *smmu_domain)
> +static int cavium_init_context(struct arm_smmu_domain *smmu_domain,
> + struct io_pgtable_cfg *pgtbl_cfg)
> {
> struct cavium_smmu *cs = container_of(smmu_domain->smmu,
> struct cavium_smmu, smmu);
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 09c42af9f31e..37d8d49299b4 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -795,11 +795,6 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> cfg->asid = cfg->cbndx;
>
> smmu_domain->smmu = smmu;
> - if (smmu->impl && smmu->impl->init_context) {
> - ret = smmu->impl->init_context(smmu_domain);
> - if (ret)
> - goto out_unlock;
> - }
>
> pgtbl_cfg = (struct io_pgtable_cfg) {
> .pgsize_bitmap = smmu->pgsize_bitmap,
> @@ -810,6 +805,12 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> .iommu_dev = smmu->dev,
> };
>
> + if (smmu->impl && smmu->impl->init_context) {
> + ret = smmu->impl->init_context(smmu_domain, _cfg);
> + if (ret)
> + goto out_clear_smmu;
> + }
> +
> if (smmu_domain->non_strict)
> pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index d890a4a968e8..83294516ac08 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -386,7 +386,8 @@ struct arm_smmu_impl {
> u64 val);
> int (*cfg_probe)(struct arm_smmu_device *smmu);
> int (*reset)(struct arm_smmu_device *smmu);
> - int (*init_context)(struct arm_smmu_domain *smmu_domain);
> + int (*init_context)(struct arm_smmu_domain *smmu_domain,
> + struct io_pgtable_cfg *cfg);
> void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
>int status);
> int (*def_domain_type)(struct device *dev);
> --
> 2.26.2
>
Re: splice: infinite busy loop lockup bug
On Tue, Sep 01, 2020 at 02:09:28AM +0100, Al Viro wrote:
> On Mon, Aug 31, 2020 at 08:51:32PM -0400, Qian Cai wrote:
> > On Fri, Aug 07, 2020 at 09:34:08PM +0900, Tetsuo Handa wrote:
> > > On 2020/08/07 21:27, Al Viro wrote:
> > > > On Fri, Aug 07, 2020 at 07:35:08PM +0900, Tetsuo Handa wrote:
> > > >> syzbot is reporting hung task at pipe_release() [1], for
> > > >> for_each_bvec() from
> > > >> iterate_bvec() from iterate_all_kinds() from iov_iter_alignment() from
> > > >> ext4_unaligned_io() from ext4_dio_write_iter() from
> > > >> ext4_file_write_iter() from
> > > >> call_write_iter() from do_iter_readv_writev() from do_iter_write() from
> > > >> vfs_iter_write() from iter_file_splice_write() falls into infinite
> > > >> busy loop
> > > >> with pipe->mutex held.
> > > >>
> > > >> The reason of falling into infinite busy loop is that
> > > >> iter_file_splice_write()
> > > >> for some reason generates "struct bio_vec" entry with .bv_len=0 and
> > > >> .bv_offset=0
> > > >> while for_each_bvec() cannot handle .bv_len == 0.
> > > >
> > > > broken in 1bdc76aea115 "iov_iter: use bvec iterator to implement
> > > > iterate_bvec()",
> > > > unless I'm misreading it...
> >
> > I have been chasing something similar for a while as in,
> >
> > https://lore.kernel.org/linux-fsdevel/89f418a9-eb20-48cb-9ae0-52c700e6b...@lca.pw/
> >
> > In my case, it seems the endless loop happens in iterate_iovec() instead
> > where
> > I put a debug patch here,
> >
> > --- a/lib/iov_iter.c
> > +++ b/lib/iov_iter.c
> > @@ -33,6 +33,7 @@
> > if (unlikely(!__v.iov_len)) \
> > continue; \
> > __v.iov_base = __p->iov_base; \
> > + printk_ratelimited("ITER_IOVEC left = %zu, n = %zu\n",
> > left, n); \
> > left = (STEP); \
> > __v.iov_len -= left;\
> > skip = __v.iov_len; \
> >
> > and end up seeing overflows ("n" supposes to be less than PAGE_SIZE) before
> > the
> > soft-lockups and a dead system,
> >
> > [ 4300.249180][T470195] ITER_IOVEC left = 0, n = 48566423
> >
> > Thoughts?
>
> Er... Where does that size come from? If that's generic_perform_write(),
> I'd like to see pos, offset and bytes at the time of call... ->iov_offset
> would
> also be interesting to see (along with the entire iovec array, really).
I used a new debug patch but not sure how to capture without
printk_ratelimited() because the call sites are large,
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index d812eef23a32..214b93c3d8a8 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -33,6 +33,7 @@
if (unlikely(!__v.iov_len)) \
continue; \
__v.iov_base = __p->iov_base; \
+ printk_ratelimited("ITER_IOVEC left = %zu, n = %zu, iov_offset
= %zu, iov_base = %px, iov_len = %lu\n", left, n, i->iov_offset, __p->iov_base,
__p->iov_len); \
left = (STEP); \
__v.iov_len -= left;\
skip = __v.iov_len; \
diff --git a/mm/filemap.c b/mm/filemap.c
index 1aaea26556cc..202b0ab28adf 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3408,6 +3408,7 @@ ssize_t generic_perform_write(struct file *file,
if (mapping_writably_mapped(mapping))
flush_dcache_page(page);
+ printk_ratelimited("pos = %lld, offset = %ld, bytes = %ld\n",
pos, offset, bytes);
copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
flush_dcache_page(page);
Al, does it help? If not, can you cook a debug patch instead?
[ 587.765400][T21348] pos = 468152746240, offset = 256, bytes = 3840
[ 587.765424][T21348] pos = 468152750080, offset = 0, bytes = 4096
[ 587.765439][T21348] pos = 468152754176, offset = 0, bytes = 4096
[ 587.765455][T21348] pos = 468152758272, offset = 0, bytes = 4096
[ 591.235409][T22038] ITER_IOVEC left = 0, n = 22476968, iov_offset = 0,
iov_base = 7ff12570c000, iov_len = 20
[ 591.313456][T22038] ITER_IOVEC left = 0, n = 22476948, iov_offset = 0,
iov_base = 7ff12325, iov_len = 20
[ 591.363679][T22038] ITER_IOVEC left = 0, n = 22476928, iov_offset = 0,
iov_base = 7ff12365, iov_len = 6370
[ 591.413217][T22038] ITER_IOVEC left = 0, n = 22470558, iov_offset = 0,
iov_base = 7ff12385, iov_len = 20
[ 591.459754][T22038] ITER_IOVEC left = 0, n = 22470538, iov_offset = 0,
iov_base = 7ff12570c000, iov_len = 376
[ 591.507748][T22038] ITER_IOVEC left = 0, n = 22470162, iov_offset = 0,
iov_base = 7ff12570c000, iov_len = 3473
[ 591.557395][T22038] ITER_IOVEC left = 0, n = 22466689, iov_offset = 0,
iov_base = 7ff12325, iov_len = 20
[ 591.605295][T22038] ITER_IOVEC left = 0, n = 2249,
Re: [PATCH 1/5] KVM: nVMX: Fix VMX controls MSRs setup when nested VMX enabled
On 8/28/2020 4:56 PM, Chenyi Qiang wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of nested VMX controls MSR.
Signed-off-by: Chenyi Qiang
Reviewed-by: Xiaoyao Li
---
arch/x86/kvm/vmx/nested.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 23b58c28a1c9..6e0e71f4d45f 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -6310,7 +6310,8 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs
*msrs, u32 ept_caps)
#ifdef CONFIG_X86_64
VM_EXIT_HOST_ADDR_SPACE_SIZE |
#endif
- VM_EXIT_LOAD_IA32_PAT | VM_EXIT_SAVE_IA32_PAT;
+ VM_EXIT_LOAD_IA32_PAT | VM_EXIT_SAVE_IA32_PAT |
+ VM_EXIT_CLEAR_BNDCFGS | VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL;
msrs->exit_ctls_high |=
VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR |
VM_EXIT_LOAD_IA32_EFER | VM_EXIT_SAVE_IA32_EFER |
@@ -6329,7 +6330,8 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs
*msrs, u32 ept_caps)
#ifdef CONFIG_X86_64
VM_ENTRY_IA32E_MODE |
#endif
- VM_ENTRY_LOAD_IA32_PAT;
+ VM_ENTRY_LOAD_IA32_PAT | VM_ENTRY_LOAD_BNDCFGS |
+ VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
msrs->entry_ctls_high |=
(VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR | VM_ENTRY_LOAD_IA32_EFER);
Re: [PATCH] KVM: LAPIC: Reset timer_advance_ns if timer mode switch
On Mon, 31 Aug 2020 at 20:48, Vitaly Kuznetsov wrote: > > Wanpeng Li writes: > > > From: Wanpeng Li > > > > per-vCPU timer_advance_ns should be set to 0 if timer mode is not > > tscdeadline > > otherwise we waste cpu cycles in the function lapic_timer_int_injected(), > > lapic_timer_int_injected is just a test, kvm_wait_lapic_expire() > (__kvm_wait_lapic_expire()) maybe? Both the check in lapic_timer_int_injected(), the check in __kvm_wait_lapic_expire(), and these function calls, we can observe ~1.3% world switch time reduce w/ this patch by kvm-unit-tests/vmexit.flat vmcall testing on AMD server. In addition, I think we should set apic->lapic_timer.expired_tscdeadline to 0 when switching between tscdeadline mode and other modes on Intel in order that we will not waste cpu cycles to tune advance value in adjust_lapic_timer_advance() for one time. Wanpeng
Re: [PATCH v2 5/5] f2fs: support age threshold based garbage collection
Jaegeuk, I missed one ')' in this diff, thanks for fixing in upstream.
Thanks,
On 2020/9/1 2:01, Jaegeuk Kim wrote:
Hi Chao,
Applied. Thanks.
On 08/31, Chao Yu wrote:
Hi Jaegeuk,
I've changed code a bit to fix some bugs, including:
- gc_idle = 3 (GC_IDLE_AT) description
- disallow set gc_idle to 3 if atgc is off
- keep compatibility with checkpoint disabling
Could you please check and merge below diff?
From: Chao Yu
Signed-off-by: Chao Yu
---
Documentation/ABI/testing/sysfs-fs-f2fs | 3 ++-
fs/f2fs/gc.c| 12 +++-
fs/f2fs/sysfs.c | 11 ---
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 7f730c4c8df2..834d0becae6d 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -22,7 +22,8 @@ Contact: "Namjae Jeon"
Description: Controls the victim selection policy for garbage collection.
Setting gc_idle = 0(default) will disable this option. Setting
gc_idle = 1 will select the Cost Benefit approach & setting
- gc_idle = 2 will select the greedy approach.
+ gc_idle = 2 will select the greedy approach & setting
+ gc_idle = 3 will select the age-threshold based approach.
What: /sys/fs/f2fs//reclaim_segments
Date: October 2013
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 6413886e52d4..3c0edb8b4cc5 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -388,6 +388,16 @@ static void add_victim_entry(struct f2fs_sb_info *sbi,
unsigned long long mtime = 0;
unsigned int i;
+ if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)) {
+ if (p->gc_mode == GC_AT &&
+ get_valid_blocks(sbi, segno, true) == 0)
+ return;
+
+ if (p->alloc_mode == AT_SSR &&
+ get_seg_entry(sbi, segno)->ckpt_valid_blocks == 0)
+ return;
+ }
+
for (i = 0; i < sbi->segs_per_sec; i++)
mtime += get_seg_entry(sbi, start + i)->mtime;
mtime = div_u64(mtime, sbi->segs_per_sec);
@@ -721,7 +731,7 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
/* Don't touch checkpointed data */
if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED) &&
get_ckpt_valid_blocks(sbi, segno) &&
- p.alloc_mode != SSR))
+ p.alloc_mode == LFS))
goto next;
if (gc_type == BG_GC && test_bit(secno, dirty_i->victim_secmap))
goto next;
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 88ed9969cc86..bacfa9c35e6b 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -375,12 +375,17 @@ static ssize_t __sbi_store(struct f2fs_attr *a,
return count;
}
if (!strcmp(a->attr.name, "gc_idle")) {
- if (t == GC_IDLE_CB)
+ if (t == GC_IDLE_CB) {
sbi->gc_mode = GC_IDLE_CB;
- else if (t == GC_IDLE_GREEDY)
+ } else if (t == GC_IDLE_GREEDY) {
sbi->gc_mode = GC_IDLE_GREEDY;
- else
+ } else if (t == GC_IDLE_AT) {
+ if (!sbi->am.atgc_enabled)
+ return -EINVAL;
+ sbi->gc_mode = GC_AT;
+ } else {
sbi->gc_mode = GC_NORMAL;
+ }
return count;
}
--
2.26.2
.
Re: KASAN: use-after-free Read in __fput (3)
On Tue, Sep 01, 2020 at 10:35:47AM +0800, Hillf Danton wrote:
> Any light on how a9ed4a6560b8 ends up with __fput called twice is
> highly appreciated.
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index e0decff22ae2..8107e06d7f6f 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1995,9 +1995,9 @@ static int ep_loop_check_proc(void *priv, void *cookie,
int call_nests)
* during ep_insert().
*/
if (list_empty(>ffd.file->f_tfile_llink)) {
- get_file(epi->ffd.file);
- list_add(>ffd.file->f_tfile_llink,
-_check_list);
+ if (get_file_rcu(epi->ffd.file))
+ list_add(>ffd.file->f_tfile_llink,
+_check_list);
}
}
}
Re: [PATCH v8 7/7] iommu/vt-d: Check UAPI data processed by IOMMU core
Hi Jacob,
On 9/1/20 2:25 AM, Jacob Pan wrote:
IOMMU generic layer already does sanity checks on UAPI data for version
match and argsz range based on generic information.
This patch adjusts the following data checking responsibilities:
- removes the redundant version check from VT-d driver
- removes the check for vendor specific data size
- adds check for the use of reserved/undefined flags
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 3 +--
drivers/iommu/intel/svm.c | 11 +--
include/uapi/linux/iommu.h | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 43f16f0cebde..a3a0b5c8921d 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5399,8 +5399,7 @@ intel_iommu_sva_invalidate(struct iommu_domain *domain,
struct device *dev,
int ret = 0;
u64 size = 0;
- if (!inv_info || !dmar_domain ||
- inv_info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1)
+ if (!inv_info || !dmar_domain)
return -EINVAL;
if (!dev || !dev_is_pci(dev))
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 99353d6468fa..0cb9a15f1112 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -284,8 +284,15 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
if (WARN_ON(!iommu) || !data)
return -EINVAL;
- if (data->version != IOMMU_GPASID_BIND_VERSION_1 ||
- data->format != IOMMU_PASID_FORMAT_INTEL_VTD)
+ if (data->format != IOMMU_PASID_FORMAT_INTEL_VTD)
+ return -EINVAL;
+
+ /* IOMMU core ensures argsz is more than the start of the union */
+ if (data->argsz < offsetofend(struct iommu_gpasid_bind_data,
vendor.vtd))
+ return -EINVAL;
+
+ /* Make sure no undefined flags are used in vendor data */
+ if (data->vendor.vtd.flags & ~(IOMMU_SVA_VTD_GPASID_LAST - 1))
return -EINVAL;
if (!dev_is_pci(dev))
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index c64bca5af419..1ebc23df4fbc 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h
@@ -288,6 +288,7 @@ struct iommu_gpasid_bind_data_vtd {
#define IOMMU_SVA_VTD_GPASID_PWT (1 << 3) /* page-level write through */
#define IOMMU_SVA_VTD_GPASID_EMTE (1 << 4) /* extended mem type enable */
#define IOMMU_SVA_VTD_GPASID_CD (1 << 5) /* PASID-level cache
disable */
+#define IOMMU_SVA_VTD_GPASID_LAST (1 << 6)
__u64 flags;
__u32 pat;
__u32 emt;
Reviewed-by: Lu Baolu
Best regards,
baolu
[PATCH] ARM: dts: imx6qp-sabresd: enable pcie
Set vgen3 regulator always on to power up the external oscillator,
and enable PCIe on iMX6QP SABRESD board.
Signed-off-by: Richard Zhu
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
arch/arm/boot/dts/imx6qp-sabresd.dts | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index f824c9abd11a..5b09f1cb3cea 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -414,6 +414,7 @@
vgen3_reg: vgen3 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
+ regulator-always-on;
};
vgen4_reg: vgen4 {
diff --git a/arch/arm/boot/dts/imx6qp-sabresd.dts
b/arch/arm/boot/dts/imx6qp-sabresd.dts
index 480e73183f6b..f089f1347598 100644
--- a/arch/arm/boot/dts/imx6qp-sabresd.dts
+++ b/arch/arm/boot/dts/imx6qp-sabresd.dts
@@ -51,7 +51,7 @@
};
{
- status = "disabled";
+ status = "okay";
};
{
--
2.17.1
Re: [PATCH net-next] vhost: fix typo in error message
On 2020/9/1 上午10:39, Yunsheng Lin wrote:
"enable" should be "disable" when the function name is
vhost_disable_notify(), which does the disabling work.
Signed-off-by: Yunsheng Lin
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 5857d4e..b45519c 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2537,7 +2537,7 @@ void vhost_disable_notify(struct vhost_dev *dev, struct
vhost_virtqueue *vq)
if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
r = vhost_update_used_flags(vq);
if (r)
- vq_err(vq, "Failed to enable notification at %p: %d\n",
+ vq_err(vq, "Failed to disable notification at %p: %d\n",
>used->flags, r);
}
}
Acked-by: Jason Wang
[PATCH] clocksource: return negative error code
A negative error code should be returned
Signed-off-by: Xianting Tian
---
drivers/clocksource/h8300_timer8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/h8300_timer8.c
b/drivers/clocksource/h8300_timer8.c
index 1d740a8c4..47114c2a7 100644
--- a/drivers/clocksource/h8300_timer8.c
+++ b/drivers/clocksource/h8300_timer8.c
@@ -169,7 +169,7 @@ static int __init h8300_8timer_init(struct device_node
*node)
return PTR_ERR(clk);
}
- ret = ENXIO;
+ ret = -ENXIO;
base = of_iomap(node, 0);
if (!base) {
pr_err("failed to map registers for clockevent\n");
--
2.17.1
