* Re: [PATCH v1 2/2] pinctrl: lynxpoint: drop runtime PM support
From: Raag Jadav @ 2023-10-03 9:08 UTC (permalink / raw)
To: linus.walleij, mika.westerberg, andriy.shevchenko
Cc: linux-gpio, linux-kernel, mallikarjunappa.sangannavar,
bala.senthil
In-Reply-To: <20231003081519.27524-2-raag.jadav@intel.com>
On Tue, Oct 03, 2023 at 01:45:19PM +0530, Raag Jadav wrote:
> Since Lynxpoint pinctrl device is not attached to acpi_lpss_pm_domain,
> runtime PM serves no purpose here. Drop it and switch to pm_sleep_ptr()
> as now we only have resume handle in place.
>
> No functional impact.
>
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> drivers/pinctrl/intel/pinctrl-lynxpoint.c | 31 ++---------------------
> 1 file changed, 2 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/pinctrl/intel/pinctrl-lynxpoint.c b/drivers/pinctrl/intel/pinctrl-lynxpoint.c
> index c3732a9f0658..18ea1c3fa7bb 100644
> --- a/drivers/pinctrl/intel/pinctrl-lynxpoint.c
> +++ b/drivers/pinctrl/intel/pinctrl-lynxpoint.c
> @@ -15,7 +15,6 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/platform_device.h>
> -#include <linux/pm_runtime.h>
> #include <linux/seq_file.h>
> #include <linux/slab.h>
> #include <linux/types.h>
Same as baytrail.
Raag
^ permalink raw reply
* Re: [PATCH v1] pinctrl: intel: refine intel_config_set_pull() function
From: Andy Shevchenko @ 2023-10-03 9:08 UTC (permalink / raw)
To: Raag Jadav
Cc: linus.walleij, mika.westerberg, linux-gpio, linux-kernel,
mallikarjunappa.sangannavar, bala.senthil
In-Reply-To: <20231003081824.28810-1-raag.jadav@intel.com>
On Tue, Oct 03, 2023 at 01:48:24PM +0530, Raag Jadav wrote:
> Improve intel_config_set_pull() implementation in Intel pinctrl driver by:
>
> - Reducing scope of spinlock by moving unneeded operations out of it.
> - Utilizing temporary variables for common operations.
> - Limiting IO operations to positive cases.
Pushed to my review and testing queue, thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix Boot
From: Roger Quadros @ 2023-10-03 9:07 UTC (permalink / raw)
To: Nishanth Menon, trini
Cc: vigneshr, m-chawdhry, sjg, jonas, afd, bb, praneeth, u-boot,
Robert Nelson
In-Reply-To: <20231002150053.2930710-1-nm@ti.com>
On 02/10/2023 18:00, Nishanth Menon wrote:
> Since commit [1] A53 u-boot proper is broken. This is because nodes
> marked as 'bootph-pre-ram' are not available at u-boot proper before
> relocation.
>
> To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
>
> [1]
> 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation")
>
> Reported-by: Roger Quadros <rogerq@kernel.org>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
> ---
>
> Based on Roger's series:
> https://lore.kernel.org/all/20230929134646.214781-1-rogerq@kernel.org/
>
> Based on:
> next e29b932aa07f Merge branch '2023-09-30-Kconfig-updates' into next
>
> See discussion thread:
> https://lore.kernel.org/all/CAPnjgZ3MgWX8T0A0SofphEr_Xd77pE3hte9DNye1RuBVeB9N8Q@mail.gmail.com/
>
--
cheers,
-roger
^ permalink raw reply
* Re: [PATCH v2 5/5] hw: turn off ramfb migration for machines <= 8.1
From: Marc-André Lureau @ 2023-10-03 9:07 UTC (permalink / raw)
To: Laszlo Ersek
Cc: qemu-devel, kraxel, Eduardo Habkost, Marcel Apfelbaum,
Philippe Mathieu-Daudé, Yanan Wang
In-Reply-To: <33b5425f-8e8c-5bde-99ed-41f28097e4e4@redhat.com>
Hi
On Mon, Oct 2, 2023 at 6:42 PM Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 10/2/23 13:11, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > For compatibility reasons.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> > hw/core/machine.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 68cb556197..2fa7647422 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -30,7 +30,10 @@
> > #include "hw/virtio/virtio-pci.h"
> > #include "hw/virtio/virtio-net.h"
> >
> > -GlobalProperty hw_compat_8_1[] = {};
> > +GlobalProperty hw_compat_8_1[] = {
> > + { "ramfb", "migrate", "off" },
> > + { "vfio-pci-nohotplug", "ramfb-migrate", "off" }
> > +};
> > const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1);
> >
> > GlobalProperty hw_compat_8_0[] = {
>
> In the other discussion, you mentioned the concrete reason for this -- I
> think if we don't do this, then the ramfb vmstate blocks backward
> migration? Can you document the reason here explicitly (commit message,
> I mean, doesn't have to be a code comment)?
By using device section/subsection in v3, I changed a little bit the
reasons for the properties. Now it falls under the common issue
documented in migration.rst "Changing migration data structure".
From v3, let me know if you still think we should document that better
in the commit message.
thanks
--
Marc-André Lureau
^ permalink raw reply
* Re: [PATCH v2] hw/i386: changes towards enabling -Wshadow=local
From: Ani Sinha @ 2023-10-03 9:05 UTC (permalink / raw)
To: Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, Peter Xu, Jason Wang
Cc: Markus Armbruster, Philippe Mathieu-Daude,
"Daniel P . Berrangé", qemu-devel
In-Reply-To: <20231003054306.4372-1-anisinha@redhat.com>
> On 03-Oct-2023, at 11:13 AM, Ani Sinha <anisinha@redhat.com> wrote:
>
> Code changes that addresses all compiler complaints coming from enabling
> -Wshadow flags. Enabling -Wshadow catches cases of local variables shadowing
> other local variables or parameters. These makes the code confusing and/or adds
> bugs that are difficult to catch.
>
> CC: Markus Armbruster <armbru@redhat.com>
> CC: Philippe Mathieu-Daude <philmd@linaro.org>
> CC: mst@redhat.com
> Message-Id: <87r0mqlf9x.fsf@pond.sub.org>
> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Reviewed-by: Peter Xu <peterx@redhat.com>
> ---
> hw/i386/acpi-microvm.c | 4 ++--
> hw/i386/intel_iommu.c | 8 ++++----
> hw/i386/pc.c | 1 -
> hw/i386/x86.c | 2 --
> 4 files changed, 6 insertions(+), 9 deletions(-)
>
> changelog:
> v2: addressed suggestion from mst.
Please ignore this. This was supposed to be v3. I will re-send. Will split-up intel_iommu into a separate patch.
>
> diff --git a/hw/i386/acpi-microvm.c b/hw/i386/acpi-microvm.c
> index a075360d85..6ddcfb0419 100644
> --- a/hw/i386/acpi-microvm.c
> +++ b/hw/i386/acpi-microvm.c
> @@ -55,8 +55,8 @@ static void acpi_dsdt_add_virtio(Aml *scope,
>
> bus = sysbus_get_default();
> QTAILQ_FOREACH(kid, &bus->children, sibling) {
> - DeviceState *dev = kid->child;
> - Object *obj = object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MMIO);
> + Object *obj = object_dynamic_cast(OBJECT(kid->child),
> + TYPE_VIRTIO_MMIO);
>
> if (obj) {
> VirtIOMMIOProxy *mmio = VIRTIO_MMIO(obj);
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index c0ce896668..2c832ab68b 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3744,7 +3744,7 @@ VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
> /* Unmap the whole range in the notifier's scope. */
> static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
> {
> - hwaddr size, remain;
> + hwaddr total, remain;
> hwaddr start = n->start;
> hwaddr end = n->end;
> IntelIOMMUState *s = as->iommu_state;
> @@ -3765,7 +3765,7 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
> }
>
> assert(start <= end);
> - size = remain = end - start + 1;
> + total = remain = end - start + 1;
>
> while (remain >= VTD_PAGE_SIZE) {
> IOMMUTLBEvent event;
> @@ -3793,10 +3793,10 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
> trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
> VTD_PCI_SLOT(as->devfn),
> VTD_PCI_FUNC(as->devfn),
> - n->start, size);
> + n->start, total);
>
> map.iova = n->start;
> - map.size = size - 1; /* Inclusive */
> + map.size = total - 1; /* Inclusive */
> iova_tree_remove(as->iova_tree, map);
> }
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 3db0743f31..e7a233e886 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1116,7 +1116,6 @@ void pc_memory_init(PCMachineState *pcms,
>
> if (machine->device_memory) {
> uint64_t *val = g_malloc(sizeof(*val));
> - PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
> uint64_t res_mem_end = machine->device_memory->base;
>
> if (!pcmc->broken_reserved_end) {
> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> index f034df8bf6..b3d054889b 100644
> --- a/hw/i386/x86.c
> +++ b/hw/i386/x86.c
> @@ -365,8 +365,6 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
>
> cpu_slot = x86_find_cpu_slot(MACHINE(x86ms), cpu->apic_id, &idx);
> if (!cpu_slot) {
> - MachineState *ms = MACHINE(x86ms);
> -
> x86_topo_ids_from_apicid(cpu->apic_id, &topo_info, &topo_ids);
> error_setg(errp,
> "Invalid CPU [socket: %u, die: %u, core: %u, thread: %u] with"
> --
> 2.42.0
>
^ permalink raw reply
* Re: [PATCH v2 4/7] thermal: exynos: simplify regulator (de)initialization
From: Krzysztof Kozlowski @ 2023-10-03 9:06 UTC (permalink / raw)
To: Marek Szyprowski, Daniel Lezcano, m.majewski2,
linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Amit Kucheria,
Zhang Rui, ALIM AKHTAR, Liam Girdwood, Mark Brown
In-Reply-To: <2e688177-7a69-051f-2d2c-c8067c38f3be@samsung.com>
On 29/09/2023 14:00, Marek Szyprowski wrote:
> On 29.09.2023 13:45, Daniel Lezcano wrote:
>> On 29/09/2023 13:03, Marek Szyprowski wrote:
>>> On 29.09.2023 12:46, Daniel Lezcano wrote:
>>>> On 26/09/2023 13:02, Mateusz Majewski wrote:
>>>>> Hi,
>>>>>
>>>>>> This is not equivalent. If regulator is provided and enable fails,
>>>>>> the
>>>>>> old code is nicely returning error. Now, it will print misleading
>>>>>> message - failed to get regulator - and continue.
>>>>>>
>>>>>> While this simplifies the code, it ignores important running
>>>>>> condition -
>>>>>> having regulator enabled.
>>>>>
>>>>> Would doing this be correct?
>>>>>
>>>>> ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
>>>>> switch (ret) {
>>>>> case 0:
>>>>> case -ENODEV:
>>>>
>>>> Not sure to understand why -NODEV is not an error
>>>
>>>
>>> Because this what devm_regulator_get_enable_optional() returns if no
>>> regulator is defined. I also got confused by this a few times.
>>
>> The code before this change calls devm_regulator_get_optional() which
>> returns -ENODEV too, right ? But there is no special case for this error.
>>
>> So this change uses devm_regulator_get_enable_optional() and handle
>> the ENODEV as a non-error, so there is a change in the behavior.
>
>
> It looks that the original code ignores any non-EPROBE_DEFER errors from
> devm_regulator_get_optional(). That's a bug, indeed.
How about separate change fixing it? I know the same code will be
changed twice, but it will be easier to backport and analyze in case of
issues.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/7] thermal: exynos: simplify regulator (de)initialization
From: Krzysztof Kozlowski @ 2023-10-03 9:06 UTC (permalink / raw)
To: Marek Szyprowski, Daniel Lezcano, m.majewski2,
linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Amit Kucheria,
Zhang Rui, ALIM AKHTAR, Liam Girdwood, Mark Brown
In-Reply-To: <2e688177-7a69-051f-2d2c-c8067c38f3be@samsung.com>
On 29/09/2023 14:00, Marek Szyprowski wrote:
> On 29.09.2023 13:45, Daniel Lezcano wrote:
>> On 29/09/2023 13:03, Marek Szyprowski wrote:
>>> On 29.09.2023 12:46, Daniel Lezcano wrote:
>>>> On 26/09/2023 13:02, Mateusz Majewski wrote:
>>>>> Hi,
>>>>>
>>>>>> This is not equivalent. If regulator is provided and enable fails,
>>>>>> the
>>>>>> old code is nicely returning error. Now, it will print misleading
>>>>>> message - failed to get regulator - and continue.
>>>>>>
>>>>>> While this simplifies the code, it ignores important running
>>>>>> condition -
>>>>>> having regulator enabled.
>>>>>
>>>>> Would doing this be correct?
>>>>>
>>>>> ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
>>>>> switch (ret) {
>>>>> case 0:
>>>>> case -ENODEV:
>>>>
>>>> Not sure to understand why -NODEV is not an error
>>>
>>>
>>> Because this what devm_regulator_get_enable_optional() returns if no
>>> regulator is defined. I also got confused by this a few times.
>>
>> The code before this change calls devm_regulator_get_optional() which
>> returns -ENODEV too, right ? But there is no special case for this error.
>>
>> So this change uses devm_regulator_get_enable_optional() and handle
>> the ENODEV as a non-error, so there is a change in the behavior.
>
>
> It looks that the original code ignores any non-EPROBE_DEFER errors from
> devm_regulator_get_optional(). That's a bug, indeed.
How about separate change fixing it? I know the same code will be
changed twice, but it will be easier to backport and analyze in case of
issues.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v2 2/4] mm/mempolicy: Implement set_mempolicy2 and
From: kernel test robot @ 2023-10-03 9:05 UTC (permalink / raw)
To: Gregory Price; +Cc: oe-kbuild-all
In-Reply-To: <20231003002156.740595-3-gregory.price@memverge.com>
Hi Gregory,
[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/Gregory-Price/mm-mempolicy-refactor-do_set_mempolicy-for-code-re-use/20231003-082354
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20231003002156.740595-3-gregory.price%40memverge.com
patch subject: [RFC PATCH v2 2/4] mm/mempolicy: Implement set_mempolicy2 and
config: sh-defconfig (https://download.01.org/0day-ci/archive/20231003/202310031608.fouTeKWe-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231003/202310031608.fouTeKWe-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202310031608.fouTeKWe-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from mm/mempolicy.c:99:
>> include/linux/syscalls.h:244:25: error: conflicting types for 'sys_set_mempolicy2'; have 'long int(const struct mempolicy_args *, size_t)' {aka 'long int(const struct mempolicy_args *, unsigned int)'}
244 | asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
| ^~~
include/linux/syscalls.h:230:9: note: in expansion of macro '__SYSCALL_DEFINEx'
230 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
| ^~~~~~~~~~~~~~~~~
include/linux/syscalls.h:220:36: note: in expansion of macro 'SYSCALL_DEFINEx'
220 | #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
mm/mempolicy.c:1683:1: note: in expansion of macro 'SYSCALL_DEFINE2'
1683 | SYSCALL_DEFINE2(set_mempolicy2, const struct mempolicy_args __user *, args,
| ^~~~~~~~~~~~~~~
include/linux/syscalls.h:818:17: note: previous declaration of 'sys_set_mempolicy2' with type 'long int(struct mempolicy_args *, size_t)' {aka 'long int(struct mempolicy_args *, unsigned int)'}
818 | asmlinkage long sys_set_mempolicy2(struct mempolicy_args __user *args,
| ^~~~~~~~~~~~~~~~~~
vim +244 include/linux/syscalls.h
1bd21c6c21e848 Dominik Brodowski 2018-04-05 233
e145242ea0df6b Dominik Brodowski 2018-04-09 234 /*
e145242ea0df6b Dominik Brodowski 2018-04-09 235 * The asmlinkage stub is aliased to a function named __se_sys_*() which
e145242ea0df6b Dominik Brodowski 2018-04-09 236 * sign-extends 32-bit ints to longs whenever needed. The actual work is
e145242ea0df6b Dominik Brodowski 2018-04-09 237 * done within __do_sys_*().
e145242ea0df6b Dominik Brodowski 2018-04-09 238 */
1bd21c6c21e848 Dominik Brodowski 2018-04-05 239 #ifndef __SYSCALL_DEFINEx
bed1ffca022cc8 Frederic Weisbecker 2009-03-13 240 #define __SYSCALL_DEFINEx(x, name, ...) \
bee20031772af3 Arnd Bergmann 2018-06-19 241 __diag_push(); \
bee20031772af3 Arnd Bergmann 2018-06-19 242 __diag_ignore(GCC, 8, "-Wattribute-alias", \
bee20031772af3 Arnd Bergmann 2018-06-19 243 "Type aliasing is used to sanitize syscall arguments");\
83460ec8dcac14 Andi Kleen 2013-11-12 @244 asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
e145242ea0df6b Dominik Brodowski 2018-04-09 245 __attribute__((alias(__stringify(__se_sys##name)))); \
c9a211951c7c79 Howard McLauchlan 2018-03-21 246 ALLOW_ERROR_INJECTION(sys##name, ERRNO); \
e145242ea0df6b Dominik Brodowski 2018-04-09 247 static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
e145242ea0df6b Dominik Brodowski 2018-04-09 248 asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)); \
e145242ea0df6b Dominik Brodowski 2018-04-09 249 asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
1a94bc34768e46 Heiko Carstens 2009-01-14 250 { \
e145242ea0df6b Dominik Brodowski 2018-04-09 251 long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
07fe6e00f6cca6 Al Viro 2013-01-21 252 __MAP(x,__SC_TEST,__VA_ARGS__); \
2cf0966683430b Al Viro 2013-01-21 253 __PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__)); \
2cf0966683430b Al Viro 2013-01-21 254 return ret; \
1a94bc34768e46 Heiko Carstens 2009-01-14 255 } \
bee20031772af3 Arnd Bergmann 2018-06-19 256 __diag_pop(); \
e145242ea0df6b Dominik Brodowski 2018-04-09 257 static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
1bd21c6c21e848 Dominik Brodowski 2018-04-05 258 #endif /* __SYSCALL_DEFINEx */
1a94bc34768e46 Heiko Carstens 2009-01-14 259
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 1/2] pinctrl: baytrail: drop runtime PM support
From: Raag Jadav @ 2023-10-03 9:05 UTC (permalink / raw)
To: linus.walleij, mika.westerberg, andriy.shevchenko
Cc: linux-gpio, linux-kernel, mallikarjunappa.sangannavar,
bala.senthil
In-Reply-To: <20231003081519.27524-1-raag.jadav@intel.com>
On Tue, Oct 03, 2023 at 01:45:18PM +0530, Raag Jadav wrote:
> Since Baytrail pinctrl device is not attached to acpi_lpss_pm_domain,
> runtime PM serves no purpose here. Drop it and switch to pm_sleep_ptr()
> as now we only have suspend and resume handles in place.
>
> No functional impact.
>
> TODO:
> Consider moving to DEFINE_LATE_DEV_PM_OPS() in the future once we have
> enough users to account for its introduction.
>
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> drivers/pinctrl/intel/pinctrl-baytrail.c | 18 +-----------------
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c
> index ec76e43527c5..14a61a262be1 100644
> --- a/drivers/pinctrl/intel/pinctrl-baytrail.c
> +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
> @@ -16,7 +16,6 @@
> #include <linux/module.h>
> #include <linux/types.h>
> #include <linux/platform_device.h>
> -#include <linux/pm_runtime.h>
> #include <linux/property.h>
> #include <linux/seq_file.h>
> #include <linux/string_helpers.h>
I just realized I forgot to add pm.h here.
I'll send out a v2.
Raag
^ permalink raw reply
* [PATCH] QA, ptest: Add documentation of unimplemented-ptest QA check
From: Yoann Congal @ 2023-10-03 9:04 UTC (permalink / raw)
To: docs; +Cc: Jérémy Rosen, Yoann Congal
From: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
---
NB: This is the documentation part of this not merged yet patch series :
https://lists.openembedded.org/g/openembedded-core/message/188448
documentation/ref-manual/classes.rst | 3 +++
documentation/ref-manual/qa-checks.rst | 11 +++++++++++
2 files changed, 14 insertions(+)
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 3f0d4844e..3eede8c7b 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1480,6 +1480,9 @@ Here are the tests you can list with the :term:`WARN_QA` and
also inherits :ref:`ref-classes-features_check` in order for the
requirement to actually work.
+- ``unimplemented-ptest:`` Checks that ptest are implemented for upstream
+ tests.
+
- ``unlisted-pkg-lics:`` Checks that all declared licenses applying
for a package are also declared on the recipe level (i.e. any license
in ``LICENSE:*`` should appear in :term:`LICENSE`).
diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst
index 4a02e7206..cc9afeb7c 100644
--- a/documentation/ref-manual/qa-checks.rst
+++ b/documentation/ref-manual/qa-checks.rst
@@ -789,6 +789,17 @@ Errors and Warnings
use a relative path rather than an absolute one, or to pick up the path from
runtime configuration or environment variables.
+.. _qa-check-unimplemented-ptest:
+
+- ``<tool> tests detected [unimpemented-ptest]``
+
+ This check will detect if the source of the package contains some upstream-
+ provided tests and, if such tests are detected, that ptests are implemented
+ for this recipe. see the ":ref:`dev-manual/packages:testing packages with ptest`"
+ section in the Yocto Project Development Tasks Manual. See also the
+ ":ref:`ref-classes-ptest`" section.
+
+
Configuring and Disabling QA Checks
===================================
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 11/12] PCI/CMA: Expose in sysfs whether devices are authenticated
From: Ilpo Järvinen @ 2023-10-03 9:04 UTC (permalink / raw)
To: Lukas Wunner
Cc: Bjorn Helgaas, David Howells, David Woodhouse, Herbert Xu,
David S. Miller, Alex Williamson, linux-pci, linux-cxl,
linux-coco, keyrings, linux-crypto, kvm, Jonathan Cameron,
linuxarm, David Box, Dan Williams, Dave Jiang, Li, Ming, Zhi Wang,
Alistair Francis, Wilfred Mallawa, Alexey Kardashevskiy,
Tom Lendacky, Sean Christopherson, Alexander Graf
In-Reply-To: <821682573e57e0384162f365652171e5ee1e6611.1695921657.git.lukas@wunner.de>
On Thu, 28 Sep 2023, Lukas Wunner wrote:
> The PCI core has just been amended to authenticate CMA-capable devices
> on enumeration and store the result in an "authenticated" bit in struct
> pci_dev->spdm_state.
>
> Expose the bit to user space through an eponymous sysfs attribute.
>
> Allow user space to trigger reauthentication (e.g. after it has updated
> the CMA keyring) by writing to the sysfs attribute.
>
> Subject to further discussion, a future commit might add a user-defined
> policy to forbid driver binding to devices which failed authentication,
> similar to the "authorized" attribute for USB.
>
> Alternatively, authentication success might be signaled to user space
> through a uevent, whereupon it may bind a (blacklisted) driver.
> A uevent signaling authentication failure might similarly cause user
> space to unbind or outright remove the potentially malicious device.
>
> Traffic from devices which failed authentication could also be filtered
> through ACS I/O Request Blocking Enable (PCIe r6.1 sec 7.7.11.3) or
> through Link Disable (PCIe r6.1 sec 7.5.3.7). Unlike an IOMMU, that
> will not only protect the host, but also prevent malicious peer-to-peer
> traffic to other devices.
IMO it would be good to mention the DOE stuff also in the changelog (it's
currently only in the sysfs docs).
--
i.
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
> Documentation/ABI/testing/sysfs-bus-pci | 27 +++++++++
> drivers/pci/Kconfig | 3 +
> drivers/pci/Makefile | 1 +
> drivers/pci/cma-sysfs.c | 73 +++++++++++++++++++++++++
> drivers/pci/cma.c | 2 +
> drivers/pci/doe.c | 2 +
> drivers/pci/pci-sysfs.c | 3 +
> drivers/pci/pci.h | 1 +
> include/linux/pci.h | 2 +
> 9 files changed, 114 insertions(+)
> create mode 100644 drivers/pci/cma-sysfs.c
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
> index ecf47559f495..2ea9b8deffcc 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci
> +++ b/Documentation/ABI/testing/sysfs-bus-pci
> @@ -500,3 +500,30 @@ Description:
> console drivers from the device. Raw users of pci-sysfs
> resourceN attributes must be terminated prior to resizing.
> Success of the resizing operation is not guaranteed.
> +
> +What: /sys/bus/pci/devices/.../authenticated
> +Date: September 2023
> +Contact: Lukas Wunner <lukas@wunner.de>
> +Description:
> + This file contains 1 if the device authenticated successfully
> + with CMA-SPDM (PCIe r6.1 sec 6.31). It contains 0 if the
> + device failed authentication (and may thus be malicious).
> +
> + Writing anything to this file causes reauthentication.
> + That may be opportune after updating the .cma keyring.
> +
> + The file is not visible if authentication is unsupported
> + by the device.
> +
> + If the kernel could not determine whether authentication is
> + supported because memory was low or DOE communication with
> + the device was not working, the file is visible but accessing
> + it fails with error code ENOTTY.
> +
> + This prevents downgrade attacks where an attacker consumes
> + memory or disturbs DOE communication in order to create the
> + appearance that a device does not support authentication.
> +
> + The reason why authentication support could not be determined
> + is apparent from "dmesg". To probe for authentication support
> + again, exercise the "remove" and "rescan" attributes.
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index c9aa5253ac1f..51df3be3438e 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -129,6 +129,9 @@ config PCI_CMA
> A PCI DOE mailbox is used as transport for DMTF SPDM based
> attestation, measurement and secure channel establishment.
>
> +config PCI_CMA_SYSFS
> + def_bool PCI_CMA && SYSFS
> +
> config PCI_DOE
> bool
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index a18812b8832b..612ae724cd2d 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_PCI_DOE) += doe.o
> obj-$(CONFIG_PCI_DYNAMIC_OF_NODES) += of_property.o
>
> obj-$(CONFIG_PCI_CMA) += cma.o cma-x509.o cma.asn1.o
> +obj-$(CONFIG_PCI_CMA_SYSFS) += cma-sysfs.o
> $(obj)/cma-x509.o: $(obj)/cma.asn1.h
> $(obj)/cma.asn1.o: $(obj)/cma.asn1.c $(obj)/cma.asn1.h
>
> diff --git a/drivers/pci/cma-sysfs.c b/drivers/pci/cma-sysfs.c
> new file mode 100644
> index 000000000000..b2d45f96601a
> --- /dev/null
> +++ b/drivers/pci/cma-sysfs.c
> @@ -0,0 +1,73 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Component Measurement and Authentication (CMA-SPDM, PCIe r6.1 sec 6.31)
> + *
> + * Copyright (C) 2023 Intel Corporation
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/spdm.h>
> +#include <linux/sysfs.h>
> +
> +#include "pci.h"
> +
> +static ssize_t authenticated_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + ssize_t rc;
> +
> + if (!pdev->cma_capable &&
> + (pdev->cma_init_failed || pdev->doe_init_failed))
> + return -ENOTTY;
> +
> + rc = pci_cma_reauthenticate(pdev);
> + if (rc)
> + return rc;
> +
> + return count;
> +}
> +
> +static ssize_t authenticated_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (!pdev->cma_capable &&
> + (pdev->cma_init_failed || pdev->doe_init_failed))
> + return -ENOTTY;
> +
> + return sysfs_emit(buf, "%u\n", spdm_authenticated(pdev->spdm_state));
> +}
> +static DEVICE_ATTR_RW(authenticated);
> +
> +static struct attribute *pci_cma_attrs[] = {
> + &dev_attr_authenticated.attr,
> + NULL
> +};
> +
> +static umode_t pci_cma_attrs_are_visible(struct kobject *kobj,
> + struct attribute *a, int n)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + /*
> + * If CMA or DOE initialization failed, CMA attributes must be visible
> + * and return an error on access. This prevents downgrade attacks
> + * where an attacker disturbs memory allocation or DOE communication
> + * in order to create the appearance that CMA is unsupported.
> + * The attacker may achieve that by simply hogging memory.
> + */
> + if (!pdev->cma_capable &&
> + !pdev->cma_init_failed && !pdev->doe_init_failed)
> + return 0;
> +
> + return a->mode;
> +}
> +
> +const struct attribute_group pci_cma_attr_group = {
> + .attrs = pci_cma_attrs,
> + .is_visible = pci_cma_attrs_are_visible,
> +};
> diff --git a/drivers/pci/cma.c b/drivers/pci/cma.c
> index 89d23fdc37ec..c539ad85a28f 100644
> --- a/drivers/pci/cma.c
> +++ b/drivers/pci/cma.c
> @@ -52,6 +52,7 @@ void pci_cma_init(struct pci_dev *pdev)
> int rc;
>
> if (!pci_cma_keyring) {
> + pdev->cma_init_failed = true;
> return;
> }
>
> @@ -67,6 +68,7 @@ void pci_cma_init(struct pci_dev *pdev)
> PCI_DOE_MAX_PAYLOAD, pci_cma_keyring,
> pci_cma_validate);
> if (!pdev->spdm_state) {
> + pdev->cma_init_failed = true;
> return;
> }
>
> diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
> index 79f0336eb0c3..fabbda68edac 100644
> --- a/drivers/pci/doe.c
> +++ b/drivers/pci/doe.c
> @@ -686,6 +686,7 @@ void pci_doe_init(struct pci_dev *pdev)
> PCI_EXT_CAP_ID_DOE))) {
> doe_mb = pci_doe_create_mb(pdev, offset);
> if (IS_ERR(doe_mb)) {
> + pdev->doe_init_failed = true;
> pci_err(pdev, "[%x] failed to create mailbox: %ld\n",
> offset, PTR_ERR(doe_mb));
> continue;
> @@ -693,6 +694,7 @@ void pci_doe_init(struct pci_dev *pdev)
>
> rc = xa_insert(&pdev->doe_mbs, offset, doe_mb, GFP_KERNEL);
> if (rc) {
> + pdev->doe_init_failed = true;
> pci_err(pdev, "[%x] failed to insert mailbox: %d\n",
> offset, rc);
> pci_doe_destroy_mb(doe_mb);
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index d9eede2dbc0e..7024e08e1b9a 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1655,6 +1655,9 @@ static const struct attribute_group *pci_dev_attr_groups[] = {
> #endif
> #ifdef CONFIG_PCIEASPM
> &aspm_ctrl_attr_group,
> +#endif
> +#ifdef CONFIG_PCI_CMA_SYSFS
> + &pci_cma_attr_group,
> #endif
> NULL,
> };
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 71092ccf4fbd..d80cc06be0cc 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -328,6 +328,7 @@ void pci_cma_destroy(struct pci_dev *pdev);
> int pci_cma_reauthenticate(struct pci_dev *pdev);
> struct x509_certificate;
> int pci_cma_validate(struct device *dev, struct x509_certificate *leaf_cert);
> +extern const struct attribute_group pci_cma_attr_group;
> #else
> static inline void pci_cma_init(struct pci_dev *pdev) { }
> static inline void pci_cma_destroy(struct pci_dev *pdev) { }
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2bc11d8b567e..2c5fde81bb85 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -516,10 +516,12 @@ struct pci_dev {
> #endif
> #ifdef CONFIG_PCI_DOE
> struct xarray doe_mbs; /* Data Object Exchange mailboxes */
> + unsigned int doe_init_failed:1;
> #endif
> #ifdef CONFIG_PCI_CMA
> struct spdm_state *spdm_state; /* Security Protocol and Data Model */
> unsigned int cma_capable:1; /* Authentication supported */
> + unsigned int cma_init_failed:1;
> #endif
> u16 acs_cap; /* ACS Capability offset */
> phys_addr_t rom; /* Physical address if not from BAR */
>
^ permalink raw reply
* Re: [Intel-xe] [PATCH] drm/i915: Abstract display info away during probe
From: Jani Nikula @ 2023-10-03 9:04 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, intel-xe
In-Reply-To: <ZRseAWK0mm0qpfRl@intel.com>
On Mon, 02 Oct 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> On Mon, Oct 02, 2023 at 07:58:30PM +0300, Jani Nikula wrote:
>> On Mon, 02 Oct 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> > On Mon, Oct 02, 2023 at 10:41:14AM +0300, Jani Nikula wrote:
>> >> On Fri, 29 Sep 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> >> > The goal is to have this function ready for Xe to use
>> >> > directly. So, let's use the available macro.
>> >>
>> >> Seesm wrong to use DISPLAY_INFO() as an lvalue
>> >
>> > to be really honestly I don't like that either.
>> > I barely like macros, specially used like this.
>> >
>> >> and I'm not sure why
>> >> this wouldn't work as-is.
>> >
>> > I should probably had collected some logs and added to the
>> > commit message. But the thing was that without this assignment,
>> > (xe)->info.display was NULL and the memcpy below was exploding
>> > with NULL dereference.
>>
>> Aww crap. That's because both DISPLAY_INFO() and DISPLAY_RUNTIME_INFO()
>> in xe are completely bogus.
>>
>> They should be
>>
>> #define DISPLAY_INFO(i915) ((i915)->display.info.__device_info)
>> #define DISPLAY_RUNTIME_INFO(i915) (&(i915)->display.info.__runtime_info)
>>
>> instead of
>>
>> #define DISPLAY_INFO(xe) ((xe)->info.display)
>> #define DISPLAY_RUNTIME_INFO(xe) (&(xe)->info.display_runtime)
>>
>> and these should be removed from struct xe_device info member:
>>
>> const struct intel_display_device_info *display;
>> struct intel_display_runtime_info display_runtime;
>
> but in this case we would need the macros in Xe to resolve the access
> to these items anyway right?!
>
> or how should we handle cases like 'if (xe->info.display_runtime.pipe_mask)' ?
Hrmh, we should *not* have code doing direct dereference chases like
that to begin with. :(
I sent a series addressing this. But discovered a bunch of weirdness
around the concepts of "have display" and "display enabled" in xe that
I'm not sure what to do with. It took years to crystallize those
concepts in i915, and xe confuses them again. :(
BR,
Jani.
>
>
>
>>
>> BR,
>> Jani.
>>
>>
>> >
>> >>
>> >> But *shrug*.
>> >>
>> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> >
>> > thanks, pushed as is.
>> >
>> >>
>> >> for merging to i915. (xe should come as a backport with cherry-pick -x.)
>> >
>> > and sent the proper backported cherry-pick to intel-xe ml.
>> >
>> >>
>> >> BR,
>> >> Jani
>> >>
>> >>
>> >> >
>> >> > Cc: Jani Nikula <jani.nikula@intel.com>
>> >> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> >> > ---
>> >> > drivers/gpu/drm/i915/display/intel_display_device.c | 2 +-
>> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
>> >> > index a6a18eae7ae8..ce55b968e658 100644
>> >> > --- a/drivers/gpu/drm/i915/display/intel_display_device.c
>> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
>> >> > @@ -926,7 +926,7 @@ void intel_display_device_probe(struct drm_i915_private *i915)
>> >> > else
>> >> > info = probe_display(i915);
>> >> >
>> >> > - i915->display.info.__device_info = info;
>> >> > + DISPLAY_INFO(i915) = info;
>> >> >
>> >> > memcpy(DISPLAY_RUNTIME_INFO(i915),
>> >> > &DISPLAY_INFO(i915)->__runtime_defaults,
>> >>
>> >> --
>> >> Jani Nikula, Intel
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: Abstract display info away during probe
From: Jani Nikula @ 2023-10-03 9:04 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, intel-xe
In-Reply-To: <ZRseAWK0mm0qpfRl@intel.com>
On Mon, 02 Oct 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> On Mon, Oct 02, 2023 at 07:58:30PM +0300, Jani Nikula wrote:
>> On Mon, 02 Oct 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> > On Mon, Oct 02, 2023 at 10:41:14AM +0300, Jani Nikula wrote:
>> >> On Fri, 29 Sep 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> >> > The goal is to have this function ready for Xe to use
>> >> > directly. So, let's use the available macro.
>> >>
>> >> Seesm wrong to use DISPLAY_INFO() as an lvalue
>> >
>> > to be really honestly I don't like that either.
>> > I barely like macros, specially used like this.
>> >
>> >> and I'm not sure why
>> >> this wouldn't work as-is.
>> >
>> > I should probably had collected some logs and added to the
>> > commit message. But the thing was that without this assignment,
>> > (xe)->info.display was NULL and the memcpy below was exploding
>> > with NULL dereference.
>>
>> Aww crap. That's because both DISPLAY_INFO() and DISPLAY_RUNTIME_INFO()
>> in xe are completely bogus.
>>
>> They should be
>>
>> #define DISPLAY_INFO(i915) ((i915)->display.info.__device_info)
>> #define DISPLAY_RUNTIME_INFO(i915) (&(i915)->display.info.__runtime_info)
>>
>> instead of
>>
>> #define DISPLAY_INFO(xe) ((xe)->info.display)
>> #define DISPLAY_RUNTIME_INFO(xe) (&(xe)->info.display_runtime)
>>
>> and these should be removed from struct xe_device info member:
>>
>> const struct intel_display_device_info *display;
>> struct intel_display_runtime_info display_runtime;
>
> but in this case we would need the macros in Xe to resolve the access
> to these items anyway right?!
>
> or how should we handle cases like 'if (xe->info.display_runtime.pipe_mask)' ?
Hrmh, we should *not* have code doing direct dereference chases like
that to begin with. :(
I sent a series addressing this. But discovered a bunch of weirdness
around the concepts of "have display" and "display enabled" in xe that
I'm not sure what to do with. It took years to crystallize those
concepts in i915, and xe confuses them again. :(
BR,
Jani.
>
>
>
>>
>> BR,
>> Jani.
>>
>>
>> >
>> >>
>> >> But *shrug*.
>> >>
>> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> >
>> > thanks, pushed as is.
>> >
>> >>
>> >> for merging to i915. (xe should come as a backport with cherry-pick -x.)
>> >
>> > and sent the proper backported cherry-pick to intel-xe ml.
>> >
>> >>
>> >> BR,
>> >> Jani
>> >>
>> >>
>> >> >
>> >> > Cc: Jani Nikula <jani.nikula@intel.com>
>> >> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> >> > ---
>> >> > drivers/gpu/drm/i915/display/intel_display_device.c | 2 +-
>> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
>> >> > index a6a18eae7ae8..ce55b968e658 100644
>> >> > --- a/drivers/gpu/drm/i915/display/intel_display_device.c
>> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
>> >> > @@ -926,7 +926,7 @@ void intel_display_device_probe(struct drm_i915_private *i915)
>> >> > else
>> >> > info = probe_display(i915);
>> >> >
>> >> > - i915->display.info.__device_info = info;
>> >> > + DISPLAY_INFO(i915) = info;
>> >> >
>> >> > memcpy(DISPLAY_RUNTIME_INFO(i915),
>> >> > &DISPLAY_INFO(i915)->__runtime_defaults,
>> >>
>> >> --
>> >> Jani Nikula, Intel
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
^ permalink raw reply
* Re: update element timeout support [was Re: [PATCH nf 1/2] netfilter: nft_set_rbtree: move sync GC from insert path to set->ops->commit]
From: Florian Westphal @ 2023-10-03 9:04 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Florian Westphal, netfilter-devel
In-Reply-To: <ZRvPSw5PGFyt7S10@calendula>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Hi Florian,
>
> I am collecting here your comments for the model we are defining for
> set elements:
>
> https://people.netfilter.org/pablo/setelems-timeout.txt
LGTM. I think your proposal to snapshot current time and
remove the "moving target" is key.
> Let me know if you have more possible scenarios that you think that
> might not be address by this model:
>
> - Annotate current time at the beginning of the transaction, use it
> in _expired() check (=> timeout is not a moving target anymore).
> - Annotate element timeout update in transaction, update timeout from
> _commit() path not to refresh it.
Right, I think that will work.
For rbtree, sync gc is kept in place, elements are not zapped,
they get tagged as DEAD, including the end element.
Then from commit, do full scan and remove any and all elements
that are flagged as DEAD or have expired.
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file
From: Bryan O'Donoghue @ 2023-10-03 9:03 UTC (permalink / raw)
To: Komal Bajaj, agross, andersson, konrad.dybcio, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, luca.weiss
In-Reply-To: <20231003055655.30994-3-quic_kbajaj@quicinc.com>
On 03/10/2023 06:56, Komal Bajaj wrote:
> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
> platform. QCM6490 is derived from SC7280 meant for various
> form factor including IoT.
>
> Supported features are, as of now:
> * Debug UART
> * eMMC
> * USB
>
> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 335 +++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/qcm6490.dtsi | 94 +++++++
> 3 files changed, 430 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> create mode 100644 arch/arm64/boot/dts/qcom/qcm6490.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 73c3be0f8872..3a2d9dbaacce 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -82,6 +82,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-maple.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-poplar.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-xiaomi-sagit.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-4000.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> new file mode 100644
> index 000000000000..ab9fa9197fe3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include "qcm6490.dtsi"
This include should go last
> +#include "pm7325.dtsi"
> +#include "pm8350c.dtsi"
> +#include "pmk8350.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCM6490 IDP";
> + compatible = "qcom,qcm6490-idp", "qcom,qcm6490";
> +
> + aliases {
> + serial0 = &uart5;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&apps_rsc {
> + regulators-0 {
> + compatible = "qcom,pm7325-rpmh-regulators";
> + qcom,pmic-id = "b";
> +
> + vreg_s1b_1p8: smps1 {
> + regulator-min-microvolt = <1856000>;
> + regulator-max-microvolt = <2040000>;
> + };
> +
> + vreg_s7b_0p9: smps7 {
> + regulator-min-microvolt = <535000>;
> + regulator-max-microvolt = <1120000>;
> + };
> +
> + vreg_s8b_1p2: smps8 {
> + regulator-min-microvolt = <1256000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
> + };
> +
> + vreg_l1b_0p8: ldo1 {
> + regulator-min-microvolt = <825000>;
> + regulator-max-microvolt = <925000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l2b_3p0: ldo2 {
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <3544000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l6b_1p2: ldo6 {
> + regulator-min-microvolt = <1140000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7b_2p9: ldo7 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2960000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l8b_0p9: ldo8 {
> + regulator-min-microvolt = <870000>;
> + regulator-max-microvolt = <970000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l9b_1p2: ldo9 {
> + regulator-min-microvolt = <1080000>;
> + regulator-max-microvolt = <1304000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l11b_1p7: ldo11 {
> + regulator-min-microvolt = <1504000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l12b_0p8: ldo12 {
> + regulator-min-microvolt = <751000>;
> + regulator-max-microvolt = <824000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l13b_0p8: ldo13 {
> + regulator-min-microvolt = <530000>;
> + regulator-max-microvolt = <824000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l14b_1p2: ldo14 {
> + regulator-min-microvolt = <1080000>;
> + regulator-max-microvolt = <1304000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l15b_0p8: ldo15 {
> + regulator-min-microvolt = <765000>;
> + regulator-max-microvolt = <1020000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l16b_1p2: ldo16 {
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l17b_1p8: ldo17 {
> + regulator-min-microvolt = <1700000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l18b_1p8: ldo18 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l19b_1p8: ldo19 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> + };
> +
> + regulators-1 {
> + compatible = "qcom,pm8350c-rpmh-regulators";
> + qcom,pmic-id = "c";
> +
> + vreg_s1c_2p2: smps1 {
> + regulator-min-microvolt = <2190000>;
> + regulator-max-microvolt = <2210000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_s9c_1p0: smps9 {
> + regulator-min-microvolt = <1010000>;
> + regulator-max-microvolt = <1170000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l1c_1p8: ldo1 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1980000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l2c_1p8: ldo2 {
> + regulator-min-microvolt = <1620000>;
> + regulator-max-microvolt = <1980000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l3c_3p0: ldo3 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3540000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l4c_1p8: ldo4 {
> + regulator-min-microvolt = <1620000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l5c_1p8: ldo5 {
> + regulator-min-microvolt = <1620000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l6c_2p9: ldo6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2950000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7c_3p0: ldo7 {
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3544000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l8c_1p8: ldo8 {
> + regulator-min-microvolt = <1620000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l9c_2p9: ldo9 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2960000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l10c_0p8: ldo10 {
> + regulator-min-microvolt = <720000>;
> + regulator-max-microvolt = <1050000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l11c_2p8: ldo11 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3544000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l12c_1p8: ldo12 {
> + regulator-min-microvolt = <1650000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l13c_3p0: ldo13 {
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <3544000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_bob: bob {
> + regulator-min-microvolt = <3008000>;
> + regulator-max-microvolt = <3960000>;
> + };
> + };
> +};
> +
> +&gpi_dma0 {
> + status = "okay";
> +};
> +
> +&gpi_dma1 {
> + status = "okay";
> +};
> +
> +&qupv3_id_0 {
> + status = "okay";
> +};
> +
> +&qupv3_id_1 {
> + status = "okay";
> +};
> +
> +&sdhc_1 {
> + non-removable;
> + no-sd;
> + no-sdio;
> +
> + vmmc-supply = <&vreg_l7b_2p9>;
> + vqmmc-supply = <&vreg_l19b_1p8>;
> +
> + status = "okay";
> +};
> +
> +&uart5 {
> + compatible = "qcom,geni-debug-uart";
> + status = "okay";
> +};
> +
> +&usb_1 {
> + status = "okay";
> +};
> +
> +&usb_1_dwc3 {
> + dr_mode = "peripheral";
> +};
> +
> +&usb_1_hsphy {
> + vdda-pll-supply = <&vreg_l10c_0p8>;
> + vdda33-supply = <&vreg_l2b_3p0>;
> + vdda18-supply = <&vreg_l1c_1p8>;
> + qcom,hs-rise-fall-time-bp = <0>;
> + qcom,squelch-detector-bp = <(-2090)>;
> + qcom,hs-disconnect-bp = <1743>;
> + qcom,hs-amplitude-bp = <1780>;
> + qcom,hs-crossover-voltage-microvolt = <(-31000)>;
> + qcom,hs-output-impedance-micro-ohms = <2600000>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_qmpphy {
> + vdda-phy-supply = <&vreg_l6b_1p2>;
> + vdda-pll-supply = <&vreg_l1b_0p8>;
> +
> + status = "okay";
> +};
> +
> +/* PINCTRL - additions to nodes defined in sc7280.dtsi */
> +
> +&pm8350c_pwm {
> + status = "okay";
> +};
> +
> +&qup_uart5_tx {
> + drive-strength = <2>;
> + bias-disable;
> +};
> +
> +&qup_uart5_rx {
> + drive-strength = <2>;
> + bias-pull-up;
> +};
> +
> +&sdc1_clk {
> + bias-disable;
> + drive-strength = <16>;
> +};
> +
> +&sdc1_cmd {
> + bias-pull-up;
> + drive-strength = <10>;
> +};
> +
> +&sdc1_data {
> + bias-pull-up;
> + drive-strength = <10>;
> +};
> +
> +&sdc1_rclk {
> + bias-pull-down;
> +};
These nodes are out-of-order too, you should sort these in
alphanumerically. q before r before s etc.
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
> new file mode 100644
> index 000000000000..b93270cae9ae
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "sc7280.dtsi"
> +
> +/*
> + * Delete unused sc7280 memory nodes and define the memory regions
> + * required by qcm6490
> + */
> +/delete-node/ &rmtfs_mem;
> +/delete-node/ &wlan_ce_mem;
> +
> +/{
> + reserved-memory {
> + cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
> + reg = <0x0 0x81800000 0x0 0x1e00000>;
> + no-map;
> + };
> +
> + camera_mem: camera@84300000 {
> + reg = <0x0 0x84300000 0x0 0x500000>;
> + no-map;
> + };
> +
> + wpss_mem: wpss@0x84800000 {
> + reg = <0x0 0x84800000 0x0 0x1900000>;
> + no-map;
> + };
> +
> + adsp_mem: adsp@86100000 {
> + reg = <0x0 0x86100000 0x0 0x2800000>;
> + no-map;
> + };
> +
> + cdsp_mem: cdsp@88900000 {
> + reg = <0x0 0x88900000 0x0 0x1e00000>;
> + no-map;
> + };
> +
> + cvp_mem: cvp@8ac00000 {
> + reg = <0x0 0x8ac00000 0x0 0x500000>;
> + no-map;
> + };
> +
> + ipa_gsi_mem: ipa-gsi@8b110000 {
> + reg = <0x0 0x8b110000 0x0 0xa000>;
> + no-map;
> + };
> +
> + gpu_microcode_mem: gpu-microcode@8b11a000 {
> + reg = <0x0 0x8b11a000 0x0 0x2000>;
> + no-map;
> + };
> +
> + mpss_mem: mpss@8b800000 {
> + reg = <0x0 0x8b800000 0x0 0xf600000>;
> + no-map;
> + };
> +
> + tz_stat_mem: tz-stat@c0000000 {
> + reg = <0x0 0xc0000000 0x0 0x100000>;
> + no-map;
> + };
> +
> + tags_mem: tags@c0100000 {
> + reg = <0x0 0xc0100000 0x0 0x1200000>;
> + no-map;
> + };
> +
> + qtee_mem: qtee@c1300000 {
> + reg = <0x0 0xc1300000 0x0 0x500000>;
> + no-map;
> + };
> +
> + trusted_apps_mem: trusted_apps@c1800000 {
> + reg = <0x0 0xc1800000 0x0 0x3900000>;
> + no-map;
> + };
> + };
> +};
> +
> +&video_mem {
> + reg = <0x0 0x8a700000 0x0 0x500000>;
> +};
> +
> +&wifi {
> + memory-region = <&wlan_fw_mem>;
> +};
> +
> +&xbl_mem {
> + reg = <0x0 0x80700000 0x0 0x100000>;
> +};
> --
> 2.42.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: xilinx: xdma: Support cyclic transfers
From: Miquel Raynal @ 2023-10-03 9:02 UTC (permalink / raw)
To: Vinod Koul
Cc: Lizhi Hou, Brian Xu, Raj Kumar Rampelli, Michal Simek, dmaengine,
linux-arm-kernel, Thomas Petazzoni, linux-kernel
In-Reply-To: <ZRVbZwQz13hL2QfY@matsya>
Hi Vinod,
Thanks for the feedback.
vkoul@kernel.org wrote on Thu, 28 Sep 2023 16:24:31 +0530:
> On 22-09-23, 18:20, Miquel Raynal wrote:
>
> > @@ -583,7 +690,36 @@ static int xdma_alloc_chan_resources(struct dma_chan *chan)
> > static enum dma_status xdma_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
> > struct dma_tx_state *state)
> > {
> > - return dma_cookie_status(chan, cookie, state);
> > + struct xdma_chan *xdma_chan = to_xdma_chan(chan);
> > + struct xdma_desc *desc = NULL;
> > + struct virt_dma_desc *vd;
> > + enum dma_status ret;
> > + unsigned long flags;
> > + unsigned int period_idx;
> > + u32 residue = 0;
> > +
> > + ret = dma_cookie_status(chan, cookie, state);
> > + if (ret == DMA_COMPLETE)
> > + return ret;
> > +
> > + spin_lock_irqsave(&xdma_chan->vchan.lock, flags);
> > +
> > + vd = vchan_find_desc(&xdma_chan->vchan, cookie);
> > + if (vd)
> > + desc = to_xdma_desc(vd);
>
> vd is not used in below check, so should be done after below checks, why
> do this for cyclic case?
I'm not sure I get this comment. vd is my way to get the descriptor,
and I need the descriptor to know whether we are in a cyclic transfer
or not. If the transfer is not cyclic, I just return the value from
dma_cookie_status() like before, otherwise I update the residue based
on the content of desc.
Maybe I don't understand what you mean, would you mind explaining it
again?
> Otherwise series lgtm, just fix the error reported by test bot
I will.
>
> > + if (!desc || !desc->cyclic) {
> > + spin_unlock_irqrestore(&xdma_chan->vchan.lock, flags);
> > + return ret;
> > + }
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: xilinx: xdma: Support cyclic transfers
From: Miquel Raynal @ 2023-10-03 9:02 UTC (permalink / raw)
To: Vinod Koul
Cc: Lizhi Hou, Brian Xu, Raj Kumar Rampelli, Michal Simek, dmaengine,
linux-arm-kernel, Thomas Petazzoni, linux-kernel
In-Reply-To: <ZRVbZwQz13hL2QfY@matsya>
Hi Vinod,
Thanks for the feedback.
vkoul@kernel.org wrote on Thu, 28 Sep 2023 16:24:31 +0530:
> On 22-09-23, 18:20, Miquel Raynal wrote:
>
> > @@ -583,7 +690,36 @@ static int xdma_alloc_chan_resources(struct dma_chan *chan)
> > static enum dma_status xdma_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
> > struct dma_tx_state *state)
> > {
> > - return dma_cookie_status(chan, cookie, state);
> > + struct xdma_chan *xdma_chan = to_xdma_chan(chan);
> > + struct xdma_desc *desc = NULL;
> > + struct virt_dma_desc *vd;
> > + enum dma_status ret;
> > + unsigned long flags;
> > + unsigned int period_idx;
> > + u32 residue = 0;
> > +
> > + ret = dma_cookie_status(chan, cookie, state);
> > + if (ret == DMA_COMPLETE)
> > + return ret;
> > +
> > + spin_lock_irqsave(&xdma_chan->vchan.lock, flags);
> > +
> > + vd = vchan_find_desc(&xdma_chan->vchan, cookie);
> > + if (vd)
> > + desc = to_xdma_desc(vd);
>
> vd is not used in below check, so should be done after below checks, why
> do this for cyclic case?
I'm not sure I get this comment. vd is my way to get the descriptor,
and I need the descriptor to know whether we are in a cyclic transfer
or not. If the transfer is not cyclic, I just return the value from
dma_cookie_status() like before, otherwise I update the residue based
on the content of desc.
Maybe I don't understand what you mean, would you mind explaining it
again?
> Otherwise series lgtm, just fix the error reported by test bot
I will.
>
> > + if (!desc || !desc->cyclic) {
> > + spin_unlock_irqrestore(&xdma_chan->vchan.lock, flags);
> > + return ret;
> > + }
Thanks,
Miquèl
^ permalink raw reply
* [PATCH] test/py: net: Add a TFTP put test
From: Love Kumar @ 2023-10-03 9:02 UTC (permalink / raw)
To: u-boot
Cc: michal.simek, git, rfried.dev, v.v.mitrofanov, seanedmond,
emohandesi
Execute tftpput command for uploading files to a server and validate its
size & CRC32.
Signed-off-by: Love Kumar <love.kumar@amd.com>
---
test/py/tests/test_net.py | 69 +++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index cd4b4dc53cbc..f69e3ea2dbba 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -6,6 +6,7 @@
import pytest
import u_boot_utils
+import datetime
"""
Note: This test relies on boardenv_* containing configuration values to define
@@ -50,6 +51,7 @@ env__net_tftp_readable_file = {
'addr': 0x10000000,
'size': 5058624,
'crc32': 'c2244b26',
+ 'timeout': 50000,
}
# Details regarding a file that may be read from a NFS server. This variable
@@ -260,3 +262,70 @@ def test_net_nfs(u_boot_console):
output = u_boot_console.run_command('crc32 %x $filesize' % addr)
assert expected_crc in output
+
+@pytest.mark.buildconfigspec("cmd_crc32")
+@pytest.mark.buildconfigspec("cmd_net")
+def test_net_tftpput(u_boot_console):
+ """Test the tftpput command.
+ A file is downloaded from the TFTP server and then uploaded to the TFTP
+ server, its size and its CRC32 are validated.
+ The details of the file to download are provided by the boardenv_* file;
+ see the comment at the beginning of this file.
+ """
+
+ if not net_set_up:
+ pytest.skip("Network not initialized")
+
+ f = u_boot_console.config.env.get("env__net_tftp_readable_file", None)
+ if not f:
+ pytest.skip("No TFTP readable file to read")
+
+ addr = f.get("addr", None)
+ if not addr:
+ addr = u_boot_utils.find_ram_base(u_boot_console)
+
+ sz = f.get("size", None)
+ timeout = f.get("timeout", u_boot_console.p.timeout)
+ fn = f["fn"]
+ fnu = "_".join([datetime.datetime.now().strftime("%y%m%d%H%M%S"), fn])
+ expected_text = "Bytes transferred = "
+ if sz:
+ expected_text += "%d" % sz
+
+ with u_boot_console.temporary_timeout(timeout):
+ output = u_boot_console.run_command("tftpboot %x %s" % (addr, fn))
+
+ assert "TIMEOUT" not in output
+ assert expected_text in output
+
+ expected_tftpb_crc = f.get("crc32", None)
+
+ output = u_boot_console.run_command("crc32 $fileaddr $filesize")
+ assert expected_tftpb_crc in output
+
+ with u_boot_console.temporary_timeout(timeout):
+ output = u_boot_console.run_command(
+ "tftpput $fileaddr $filesize $serverip:%s" % (fnu)
+ )
+
+ expected_text = "Bytes transferred = "
+ if sz:
+ expected_text += "%d" % sz
+ addr = addr + sz
+ assert "TIMEOUT" not in output
+ assert "Access violation" not in output
+ assert expected_text in output
+
+ with u_boot_console.temporary_timeout(timeout):
+ output = u_boot_console.run_command("tftpboot %x %s" % (addr, fnu))
+
+ expected_text = "Bytes transferred = "
+ if sz:
+ expected_text += "%d" % sz
+ assert "TIMEOUT" not in output
+ assert expected_text in output
+
+ expected_tftpp_crc = expected_tftpb_crc
+
+ output = u_boot_console.run_command("crc32 $fileaddr $filesize")
+ assert expected_tftpp_crc in output
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v1 1/2] pinctrl: baytrail: drop runtime PM support
From: Andy Shevchenko @ 2023-10-03 9:01 UTC (permalink / raw)
To: Raag Jadav
Cc: linus.walleij, mika.westerberg, linux-gpio, linux-kernel,
mallikarjunappa.sangannavar, bala.senthil
In-Reply-To: <ZRvX9GUXbJksmSIP@smile.fi.intel.com>
On Tue, Oct 03, 2023 at 11:59:33AM +0300, Andy Shevchenko wrote:
> On Tue, Oct 03, 2023 at 01:45:18PM +0530, Raag Jadav wrote:
> > Since Baytrail pinctrl device is not attached to acpi_lpss_pm_domain,
> > runtime PM serves no purpose here. Drop it and switch to pm_sleep_ptr()
> > as now we only have suspend and resume handles in place.
> >
> > No functional impact.
>
> > TODO:
> > Consider moving to DEFINE_LATE_DEV_PM_OPS() in the future once we have
> > enough users to account for its introduction.
>
> This is not related to the commit message.
> I'll drop it.
Ah, and next time, please do a cover letter for the series, it can be
better managed from maintainer perspective.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [libgpiod][PATCH v2 3/3] bindings: rust: allow cloning line::InfoRef -> line::Info
From: Viresh Kumar @ 2023-10-03 9:01 UTC (permalink / raw)
To: Erik Schilling; +Cc: Linux-GPIO, Manos Pitsidianakis, Kent Gibson
In-Reply-To: <20230929-rust-line-info-soundness-v2-3-9782b7f20f26@linaro.org>
On 29-09-23, 15:18, Erik Schilling wrote:
> While one would usually use the ToOwned [1] contract in rust, libgpipd's
> API only allows copying that may fail.
>
> Thus, we cannot implement the existing trait and roll our own method. I
> went with `try_clone` since that seems to be used in similar cases across
> the `std` crate [2].
>
> It also closes the gap of not having any way to clone owned instances.
> Though - again - not through the Clone trait which may not fail [3].
>
> [1] https://doc.rust-lang.org/std/borrow/trait.ToOwned.html
> [2] https://doc.rust-lang.org/std/index.html?search=try_clone
> [3] https://doc.rust-lang.org/std/clone/trait.Clone.html
>
> Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
> ---
> bindings/rust/libgpiod/src/lib.rs | 1 +
> bindings/rust/libgpiod/src/line_info.rs | 16 ++++++++++
> bindings/rust/libgpiod/tests/line_info.rs | 53 +++++++++++++++++++++++++++++++
> 3 files changed, 70 insertions(+)
>
> diff --git a/bindings/rust/libgpiod/src/lib.rs b/bindings/rust/libgpiod/src/lib.rs
> index 3acc98c..fd95ed2 100644
> --- a/bindings/rust/libgpiod/src/lib.rs
> +++ b/bindings/rust/libgpiod/src/lib.rs
> @@ -74,6 +74,7 @@ pub enum OperationType {
> LineConfigSetOutputValues,
> LineConfigGetOffsets,
> LineConfigGetSettings,
> + LineInfoCopy,
> LineRequestReconfigLines,
> LineRequestGetVal,
> LineRequestGetValSubset,
> diff --git a/bindings/rust/libgpiod/src/line_info.rs b/bindings/rust/libgpiod/src/line_info.rs
> index e3ea5e1..c9dd379 100644
> --- a/bindings/rust/libgpiod/src/line_info.rs
> +++ b/bindings/rust/libgpiod/src/line_info.rs
> @@ -58,6 +58,22 @@ impl InfoRef {
> self as *const _ as *mut _
> }
>
> + /// Clones the line info object.
> + pub fn try_clone(&self) -> Result<Info> {
> + // SAFETY: `gpiod_line_info` is guaranteed to be valid here.
> + let copy = unsafe { gpiod::gpiod_line_info_copy(self.as_raw_ptr()) };
> + if copy.is_null() {
> + return Err(Error::OperationFailed(
> + crate::OperationType::LineInfoCopy,
> + errno::errno(),
> + ));
> + }
> +
> + // SAFETY: The copy succeeded, we are the owner and stop using the
> + // pointer after this.
> + Ok(unsafe { Info::from_raw_owned(copy) })
> + }
> +
> /// Get the offset of the line within the GPIO chip.
> ///
> /// The offset uniquely identifies the line on the chip. The combination of the chip and offset
> diff --git a/bindings/rust/libgpiod/tests/line_info.rs b/bindings/rust/libgpiod/tests/line_info.rs
> index ce66a60..d02c9ea 100644
> --- a/bindings/rust/libgpiod/tests/line_info.rs
> +++ b/bindings/rust/libgpiod/tests/line_info.rs
> @@ -19,6 +19,10 @@ mod line_info {
> const NGPIO: usize = 8;
>
> mod properties {
> + use std::thread;
> +
> + use libgpiod::{line, request};
> +
> use super::*;
>
> #[test]
> @@ -271,5 +275,54 @@ mod line_info {
> assert!(info.is_debounced());
> assert_eq!(info.debounce_period(), Duration::from_millis(100));
> }
> +
> + fn generate_line_event(chip: &Chip) {
> + let mut line_config = line::Config::new().unwrap();
> + line_config
> + .add_line_settings(&[0], line::Settings::new().unwrap())
> + .unwrap();
> +
> + let mut request = chip
> + .request_lines(Some(&request::Config::new().unwrap()), &line_config)
> + .unwrap();
> +
> + let mut new_line_config = line::Config::new().unwrap();
> + let mut settings = line::Settings::new().unwrap();
> + settings.set_direction(Direction::Output).unwrap();
> + new_line_config.add_line_settings(&[0], settings).unwrap();
> + request.reconfigure_lines(&new_line_config).unwrap();
> + }
> +
> + #[test]
> + fn ownership() {
> + let sim = Sim::new(Some(1), None, false).unwrap();
> + sim.set_line_name(0, "Test line").unwrap();
> + sim.enable().unwrap();
> +
> + let chip = Chip::open(&sim.dev_path()).unwrap();
> +
> + // start watching line
> + chip.watch_line_info(0).unwrap();
> +
> + generate_line_event(&chip);
> +
> + // read generated event
> + let event = chip.read_info_event().unwrap();
> + let info = event.line_info().unwrap();
> + assert_eq!(info.name().unwrap(), "Test line");
> +
> + // clone info and move to separate thread
> + let info = info.try_clone().unwrap();
> +
> + // drop the original event with the associated line_info
> + drop(event);
> +
> + // assert that we can still read the name
> + thread::scope(|s| {
> + s.spawn(move || {
> + assert_eq!(info.name().unwrap(), "Test line");
> + });
> + });
> + }
> }
> }
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v17 13/18] drm/shmem-helper: Add memory shrinker
From: Boris Brezillon @ 2023-10-03 9:00 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: David Airlie, Gerd Hoffmann, Gurchetan Singh, Chia-I Wu,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Christian König, Qiang Yu, Steven Price,
Emma Anholt, Melissa Wen, dri-devel, linux-kernel, kernel,
virtualization
In-Reply-To: <bbbd82a5-41bf-4ca3-476d-e5039e94631b@collabora.com>
Hello Dmitry,
On Tue, 3 Oct 2023 03:31:32 +0300
Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
> On 9/26/23 10:35, Boris Brezillon wrote:
> >>>> + __drm_gem_shmem_release_pages(shmem);
> >>> Make sure you drop the implicit pages_use_count ref the sgt had, this
> >>> way you can still tie the necessity to drop the pages to sgt != NULL in
> >>> drm_gem_shmem_free().
> >> This will require further refcnt re-initialization when pages are
> >> restored if it's dropped to zero. I don't see how this will improve
> >> anything.
> > Sorry to disagree, but I do think it matters to have a clear ownership
> > model, and if I look at the code (drm_gem_shmem_get_pages_sgt_locked()),
> > the sgt clearly owns a reference to the pages it points to.
>
> It creates too much unnecessary trouble because, again, pages_use_count
> can't drop to zero easily.
Not saying pages_use_count should drop to zero, I'm just saying the
reference that was owned by the sgt should be released when this sgt is
freed, no matter if this sgt destruction is triggered by a GEM eviction,
or because the GEM object is freed entirely.
> Shrinker doesn't own the refcnt and not
> allowed to touch it.
I'm not asking the shrinker to own a reference on the pages either.
It's really the sgt that owns this reference.
> The pages_use_count is then used by things like
> mmap() and etc that use get_pages(), which can be invoked for evicted GEM.
Yes, and I still have a hard time seeing how this interferes with what
I'm suggesting to be honest.
>
> I'd prefer to keep refcounting as is, don't see how to implement your
> suggestion.
Can you be more specific? I don't really see what the problem is with
decrementing pages_use_count when you free the sgt (eviction), and
re-incrementing it when the sgt is restored (swapin).
Regards,
Boris
^ permalink raw reply
* Re: [PATCH v17 13/18] drm/shmem-helper: Add memory shrinker
From: Boris Brezillon @ 2023-10-03 9:00 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: kernel, Thomas Zimmermann, Emma Anholt, Christian König,
dri-devel, linux-kernel, Maxime Ripard, Gurchetan Singh,
Melissa Wen, Gerd Hoffmann, Steven Price, virtualization,
Qiang Yu
In-Reply-To: <bbbd82a5-41bf-4ca3-476d-e5039e94631b@collabora.com>
Hello Dmitry,
On Tue, 3 Oct 2023 03:31:32 +0300
Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
> On 9/26/23 10:35, Boris Brezillon wrote:
> >>>> + __drm_gem_shmem_release_pages(shmem);
> >>> Make sure you drop the implicit pages_use_count ref the sgt had, this
> >>> way you can still tie the necessity to drop the pages to sgt != NULL in
> >>> drm_gem_shmem_free().
> >> This will require further refcnt re-initialization when pages are
> >> restored if it's dropped to zero. I don't see how this will improve
> >> anything.
> > Sorry to disagree, but I do think it matters to have a clear ownership
> > model, and if I look at the code (drm_gem_shmem_get_pages_sgt_locked()),
> > the sgt clearly owns a reference to the pages it points to.
>
> It creates too much unnecessary trouble because, again, pages_use_count
> can't drop to zero easily.
Not saying pages_use_count should drop to zero, I'm just saying the
reference that was owned by the sgt should be released when this sgt is
freed, no matter if this sgt destruction is triggered by a GEM eviction,
or because the GEM object is freed entirely.
> Shrinker doesn't own the refcnt and not
> allowed to touch it.
I'm not asking the shrinker to own a reference on the pages either.
It's really the sgt that owns this reference.
> The pages_use_count is then used by things like
> mmap() and etc that use get_pages(), which can be invoked for evicted GEM.
Yes, and I still have a hard time seeing how this interferes with what
I'm suggesting to be honest.
>
> I'd prefer to keep refcounting as is, don't see how to implement your
> suggestion.
Can you be more specific? I don't really see what the problem is with
decrementing pages_use_count when you free the sgt (eviction), and
re-incrementing it when the sgt is restored (swapin).
Regards,
Boris
^ permalink raw reply
* Re: [PATCH net-next 1/1] net/sched: Disambiguate verdict from return code
From: Daniel Borkmann @ 2023-10-03 9:00 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Victor Nogueira, xiyou.wangcong, jiri, davem, edumazet, kuba,
pabeni, paulb, netdev, kernel, martin.lau, bpf
In-Reply-To: <CAM0EoM=SH8i_-veiyUtT6Wd4V7DxNm-tF9sP2BURqN5B2yRRVQ@mail.gmail.com>
On 10/2/23 9:54 PM, Jamal Hadi Salim wrote:
> On Fri, Sep 29, 2023 at 11:48 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 9/26/23 1:01 AM, Jamal Hadi Salim wrote:
>>> On Fri, Sep 22, 2023 at 4:12 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>> On 9/20/23 1:20 AM, Jamal Hadi Salim wrote:
>>>>> On Tue, Sep 19, 2023 at 6:15 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>>>> On 9/19/23 4:59 PM, Victor Nogueira wrote:
>> [...]
>>>>
>>>> In the above case we don't have 'internal' errors which you want to trace, so I would
>>>> also love to avoid the cost of zeroing struct tcf_result res which should be 3x 8b for
>>>> every packet.
>>>
>>> We can move the zeroing inside tc_run() but we declare it in the same
>>> spot as we do right now. You will still need to set res.verdict as
>>> above.
>>> Would that work for you?
>>
>> What I'm not following is that with the below you can avoid the unnecessary
>> fast path cost (which is only for corner case which is almost never hit) and
>> get even better visibility. Are you saying it doesn't work?
>
> I am probably missing something:
> -1/UNSPEC is a legit errno. And the main motivation here for this
> patch is to disambiguate if it was -EPERM vs UNSPEC
> Maybe that is what you are calling a "corner case"?
Yes, but what is the use-case to ever return a -EPERM from the fast-path? This can
be audited for the code in the tree and therefore avoided so that you never run into
this problem.
> There are two options in my mind right now (since you are guaranteed
> in tcx_run you will never return anything below UNSPEC):
> 1) we just have the switch statement invocation inside an inline
> function and you can pass it sch_ret (for tcx case) and we'll pass it
> res.verdit for tc_run() case.
> 2) is something is we leave tcx_run alone and we have something along
> the lines of:
>
> --------------
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 1450f4741d9b..93613bce647c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3985,7 +3985,7 @@ sch_handle_ingress(struct sk_buff *skb, struct
> packet_type **pt_prev, int *ret,
> struct net_device *orig_dev, bool *another)
> {
> struct bpf_mprog_entry *entry =
> rcu_dereference_bh(skb->dev->tcx_ingress);
> - struct tcf_result res = {0};
> + struct tcf_result res;
> int sch_ret;
>
> if (!entry)
> @@ -4003,14 +4003,16 @@ sch_handle_ingress(struct sk_buff *skb, struct
> packet_type **pt_prev, int *ret,
> if (sch_ret != TC_ACT_UNSPEC)
> goto ingress_verdict;
> }
> +
> + res.verdict = 0;
> sch_ret = tc_run(tcx_entry(entry), skb, &res);
> if (sch_ret < 0) {
> kfree_skb_reason(skb, SKB_DROP_REASON_TC_INGRESS_ERROR);
> *ret = NET_RX_DROP;
> return NULL;
> }
> + sch_ret = res.verdict;
> ingress_verdict:
> - switch (res.verdict) {
> + switch (sch_ret) {
> case TC_ACT_REDIRECT:
> /* skb_mac_header check was done by BPF, so we can
> safely
> * push the L2 header back before redirecting to another
> -----------
>
> on the drop reason - our thinking is to support drop_watch alongside
> tracepoint given kfree_skb_reason exists already; if i am not mistaken
> what you suggested would require us to create a new tracepoint?
So if the only thing you really care about is the different drop reason for
kfree_skb_reason, then I still don't follow why you need to drag this into
struct tcf_result. This can be done in a much simpler and more efficient way
like the following:
diff --git a/include/net/dropreason-core.h b/include/net/dropreason-core.h
index a587e83fc169..b1c069c8e7f2 100644
--- a/include/net/dropreason-core.h
+++ b/include/net/dropreason-core.h
@@ -80,6 +80,8 @@
FN(IPV6_NDISC_BAD_OPTIONS) \
FN(IPV6_NDISC_NS_OTHERHOST) \
FN(QUEUE_PURGE) \
+ FN(TC_EGRESS_ERROR) \
+ FN(TC_INGRESS_ERROR) \
FNe(MAX)
/**
@@ -345,6 +347,10 @@ enum skb_drop_reason {
SKB_DROP_REASON_IPV6_NDISC_NS_OTHERHOST,
/** @SKB_DROP_REASON_QUEUE_PURGE: bulk free. */
SKB_DROP_REASON_QUEUE_PURGE,
+ /** @SKB_DROP_REASON_TC_EGRESS_ERROR: dropped in TC egress HOOK due to error */
+ SKB_DROP_REASON_TC_EGRESS_ERROR,
+ /** @SKB_DROP_REASON_TC_INGRESS_ERROR: dropped in TC ingress HOOK due to error */
+ SKB_DROP_REASON_TC_INGRESS_ERROR,
/**
* @SKB_DROP_REASON_MAX: the maximum of core drop reasons, which
* shouldn't be used as a real 'reason' - only for tracing code gen
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index f308e8268651..cd2444dd3745 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -10,6 +10,7 @@
/* TC action not accessible from user space */
#define TC_ACT_CONSUMED (TC_ACT_VALUE_MAX + 1)
+#define TC_ACT_ABORT (TC_ACT_VALUE_MAX + 2)
/* Basic packet classifier frontend definitions. */
diff --git a/net/core/dev.c b/net/core/dev.c
index 85df22f05c38..3abb4d71c170 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4011,7 +4011,10 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
*ret = NET_RX_SUCCESS;
return NULL;
case TC_ACT_SHOT:
- kfree_skb_reason(skb, SKB_DROP_REASON_TC_INGRESS);
+ case TC_ACT_ABORT:
+ kfree_skb_reason(skb, likely(sch_ret == TC_ACT_SHOT) ?
+ SKB_DROP_REASON_TC_INGRESS :
+ SKB_DROP_REASON_TC_INGRESS_ERROR);
*ret = NET_RX_DROP;
return NULL;
/* used by tc_run */
@@ -4054,7 +4057,10 @@ sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
*ret = NET_XMIT_SUCCESS;
return NULL;
case TC_ACT_SHOT:
- kfree_skb_reason(skb, SKB_DROP_REASON_TC_EGRESS);
+ case TC_ACT_ABORT:
+ kfree_skb_reason(skb, likely(sch_ret == TC_ACT_SHOT) ?
+ SKB_DROP_REASON_TC_EGRESS :
+ SKB_DROP_REASON_TC_EGRESS_ERROR);
*ret = NET_XMIT_DROP;
return NULL;
/* used by tc_run */
Then you just return the internal TC_ACT_ABORT code for internal 'exceptions',
and you'll get the same result to make it observable for dropwatch.
Thanks,
Daniel
^ permalink raw reply related
* Re: [libgpiod][PATCH v2 2/3] bindings: rust: rename {event,settings}_clone to try_clone
From: Viresh Kumar @ 2023-10-03 9:00 UTC (permalink / raw)
To: Erik Schilling; +Cc: Linux-GPIO, Manos Pitsidianakis, Kent Gibson
In-Reply-To: <20230929-rust-line-info-soundness-v2-2-9782b7f20f26@linaro.org>
On 29-09-23, 15:18, Erik Schilling wrote:
> What is getting cloned is already clear from the type. This also aligns
> a bit better with similar methods from the `std` crate [1].
>
> [1] https://doc.rust-lang.org/std/index.html?search=try_clone
>
> Link: https://lore.kernel.org/r/CVUKC1HXG1P8.13XIUCCXN95F0@ablu-work
> Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
> ---
> bindings/rust/libgpiod/examples/buffered_event_lifetimes.rs | 2 +-
> bindings/rust/libgpiod/src/edge_event.rs | 3 ++-
> bindings/rust/libgpiod/src/line_settings.rs | 4 ++--
> bindings/rust/libgpiod/tests/line_request.rs | 2 +-
> 4 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/bindings/rust/libgpiod/examples/buffered_event_lifetimes.rs b/bindings/rust/libgpiod/examples/buffered_event_lifetimes.rs
> index ad90d7b..8dbb496 100644
> --- a/bindings/rust/libgpiod/examples/buffered_event_lifetimes.rs
> +++ b/bindings/rust/libgpiod/examples/buffered_event_lifetimes.rs
> @@ -34,7 +34,7 @@ fn main() -> libgpiod::Result<()> {
> let event = events.next().unwrap()?;
>
> // This will out live `event` and the next read_edge_events().
> - let cloned_event = libgpiod::request::Event::event_clone(event)?;
> + let cloned_event = libgpiod::request::Event::try_clone(event)?;
>
> let events = request.read_edge_events(&mut buffer)?;
> for event in events {
> diff --git a/bindings/rust/libgpiod/src/edge_event.rs b/bindings/rust/libgpiod/src/edge_event.rs
> index 0c0cfbc..4c940ba 100644
> --- a/bindings/rust/libgpiod/src/edge_event.rs
> +++ b/bindings/rust/libgpiod/src/edge_event.rs
> @@ -25,7 +25,8 @@ use super::{
> pub struct Event(*mut gpiod::gpiod_edge_event);
>
> impl Event {
> - pub fn event_clone(event: &Event) -> Result<Event> {
> + /// Makes a copy of the event object.
> + pub fn try_clone(event: &Event) -> Result<Event> {
> // SAFETY: `gpiod_edge_event` is guaranteed to be valid here.
> let event = unsafe { gpiod::gpiod_edge_event_copy(event.0) };
> if event.is_null() {
> diff --git a/bindings/rust/libgpiod/src/line_settings.rs b/bindings/rust/libgpiod/src/line_settings.rs
> index f0b3e9c..41b27e2 100644
> --- a/bindings/rust/libgpiod/src/line_settings.rs
> +++ b/bindings/rust/libgpiod/src/line_settings.rs
> @@ -52,8 +52,8 @@ impl Settings {
> unsafe { gpiod::gpiod_line_settings_reset(self.settings) }
> }
>
> - /// Makes copy of the settings object.
> - pub fn settings_clone(&self) -> Result<Self> {
> + /// Makes a copy of the settings object.
> + pub fn try_clone(&self) -> Result<Self> {
> // SAFETY: `gpiod_line_settings` is guaranteed to be valid here.
> let settings = unsafe { gpiod::gpiod_line_settings_copy(self.settings) };
> if settings.is_null() {
> diff --git a/bindings/rust/libgpiod/tests/line_request.rs b/bindings/rust/libgpiod/tests/line_request.rs
> index 9af5226..8731719 100644
> --- a/bindings/rust/libgpiod/tests/line_request.rs
> +++ b/bindings/rust/libgpiod/tests/line_request.rs
> @@ -272,7 +272,7 @@ mod line_request {
> for offset in offsets {
> lsettings.set_debounce_period(Duration::from_millis((100 + offset).into()));
> lconfig
> - .add_line_settings(&[offset as Offset], lsettings.settings_clone().unwrap())
> + .add_line_settings(&[offset as Offset], lsettings.try_clone().unwrap())
> .unwrap();
> }
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH] firmware: arm_ffa: Assign the missing IDR allocation ID to the FFA device
From: Sudeep Holla @ 2023-10-03 8:59 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Sudeep Holla, linux-kernel
Commit 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical
partitions") added an ID to the FFA device using ida_alloc() and append
the same to "arm-ffa" to make up a unique device name. However it missed
to stash the id value in ffa_dev to help freeing the ID later when the
device is destroyed.
Due to the missing/unassigned ID in FFA device, we get the following
warning when the FF-A device is unregistered. Fix the same by actually
assigning the ID in the FFA device this time for real.
Fixes: 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical partitions")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_ffa/bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_ffa/bus.c b/drivers/firmware/arm_ffa/bus.c
index 2b8bfcd010f5..7865438b3696 100644
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -193,6 +193,7 @@ struct ffa_device *ffa_device_register(const uuid_t *uuid, int vm_id,
dev->release = ffa_release_device;
dev_set_name(&ffa_dev->dev, "arm-ffa-%d", id);
+ ffa_dev->id = id;
ffa_dev->vm_id = vm_id;
ffa_dev->ops = ops;
uuid_copy(&ffa_dev->uuid, uuid);
--
2.42.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.