- iounmap(port->membase);
> + devm_iounmap(port->dev, port->membase);
> }
>
> - release_mem_region(dev->hpa.start + MUX_OFFSET, port_count *
> MUX_LINE_OFFSET);
> + devm_release_mem_region(&dev->dev,
> + dev->hpa.start + MUX_OFFSET,
> + port_count * MUX_LINE_OFFSET);
> return 0;
> }
--
With Best Regards,
Andy Shevchenko
and anounce
here as an RFC, since this was neither tested nor correct.
And selling point for many of them is not true: it doesn't make any
difference in the size in code, but increases a time to run
(devm_ioremap_resource() does more than plain devm_iomap() call).
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 15, 2019 at 11:12 AM Andy Shevchenko
wrote:
> On Fri, Mar 15, 2019 at 12:40 AM Enrico Weigelt, metux IT consult
> wrote:
>
> > here's v2 of my serial cleanups queue - part I:
> >
> > essentially using helpers to code more compact and switching to
On Fri, Mar 15, 2019 at 11:36:04AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 15.03.19 10:12, Andy Shevchenko wrote:
>
> >> Part II will be about moving the mmio range from mapbase and
> >> mapsize (which are used quite inconsistently) to a struct resource
&g
On Fri, Mar 15, 2019 at 8:44 PM Enrico Weigelt, metux IT consult
wrote:
> On 15.03.19 19:11, Andy Shevchenko wrote:
> OTOH, the name, IMHO, is a bit misleading. Any chance of ever changing
> it to a more clear name (eg. devm_request_and_ioremap_resource()) ?
Compare iomap vs
ifs: find.c: replace swap function with built-in one
> Lib: sort.h: replace int size with size_t size in the swap function
You have to do something about Cc list.
50 people is complete overkill. Seems as your series is a set of
independent fixes. Why not to split and Cc based on individual case?
--
With Best Regards,
Andy Shevchenko
gt; else
> - swap_func(a, b, (int)size);
> + swap_func(a, b, size);
> }
>
> /**
> @@ -187,7 +187,7 @@ static size_t parent(size_t i, unsigned int lsbit, size_t
> size)
> */
> void sort(void *base, size_t num, size_t size,
>
On Mon, Apr 01, 2019 at 09:56:07AM +, George Spelvin wrote:
> On Mon, 1 Apr 2019 at 12:35:55 +0300, Andy Shevchenko wrote:
> > Hmm... If (*swap)() is called recursively it means the change might increase
> > stack usage on 64-bit platforms.
> >
> > Am I missing
; Signed-off-by: Andrey Abramov
> Reviewed by: George Spelvin
FWIW,
Reviewed-by: Andy Shevchenko
> ---
> arch/x86/kernel/unwind_orc.c | 2 +-
> include/linux/sort.h | 2 +-
> kernel/jump_label.c | 2 +-
> lib/extable.c| 2 +-
> lib/sort.c
is_32bit_task()) {
if (sp & 0x03)
return 0;
if (sp > STACK_TOP - 16)
return 0;
} else {
...
}
return 1;
Other possibility:
unsigned long align = is_32bit_task() ? 3 : 7;
unsigned long top = STACK_TOP - (is_32bit_task() ? 16 : 32);
return !(!sp || (sp & align) || sp > top);
--
With Best Regards,
Andy Shevchenko
/*/*
> F: arch/*/events/*
> F: arch/*/events/*/*
> F: tools/perf/
Had you run parse-maintainers.pl?
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 19, 2020 at 03:00:08PM +0100, Michal Suchánek wrote:
> On Thu, Mar 19, 2020 at 03:37:03PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 19, 2020 at 2:21 PM Michal Suchanek wrote:
> > >
> > > Signed-off-by: Michal Suchanek
> > > ---
> > >
nt.h
> F: arch/*/kernel/perf_callchain.c
> -F: arch/*/events/*
> -F: arch/*/events/*/*
> +F: arch/*/events/
> +F: arch/*/perf/
> F: tools/perf/
>
> PERFORMANCE EVENTS SUBSYSTEM ARM64 PMU EVENTS
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote:
> > > While at it also simplify the existing perf patterns.
> > And
On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > > >
On Fri, Mar 20, 2020 at 05:42:04PM +0100, Michal Suchánek wrote:
> On Fri, Mar 20, 2020 at 06:31:57PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> > > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > > >
On Sat, Mar 21, 2020 at 1:34 PM Thomas Gleixner wrote:
>
> From: Peter Zijlstra
>
> In order to avoid future header hell, remove the inclusion of
> proc_fs.h from acpi_bus.h. All it needs is a forward declaration of a
> struct.
>
Acked-by: Andy Shevchenko # for PDx86
&
is used
> through the fsp2 platform,
> and can not be deprecated at least until that is known to have stopped
> getting kernel
> updates.
>
> Arnd
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
> > wrote:
> > >
> > > recently we wanted to update xilinx intc driver and we f
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
> wrote:
> > On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > >
.$}.4...1.L...C...'
> [ 16.786763] test_hexdump: failed 801 out of 1184 tests
>
> This patch fixes it.
I like this approach because in the future we might introduce something
to print be data on le cpu or otherwise and thus test data will be used
independently of cpu endianess.
R
> it because you never merged it :P
Hmm... I (as an author of the test case) never saw that patch.
> Sorry, I wasn't sure who should merge it, and never followed up.
lib/* most of the time under Andrew's responsibility, though since it's
orphaned in MAINTAINERS, anyone can
On Sat, Aug 18, 2018 at 4:26 PM Rasmus Villemoes
wrote:
>
> There are quite a few callers of seq_open that could be simplified by
> setting the ->private member via the seq_open call instead of fetching
> file->private_data afterwards.
>
I like this series,
Reviewed-by:
return 0;
> + if (strncmp(np, "i2s-", 4))
> return 0;
Shouldn't be node_name here?
--
With Best Regards,
Andy Shevchenko
mp;pdev->dev, "%pOFn sync own reference\n",
> + np);
One line?
--
With Best Regards,
Andy Shevchenko
; If that patch is not accepted or other pciehp-related patches are merged
> before this series, I'll have to rebase patch [4/9] ("PCI: pciehp: Unify
> controller and slot structs"). No big deal, just a heads-up.
>
Acked-by: Andy Shevchenko
for PDx86 bits
> Thanks,
8250/8250_omap.c | 6 +++-
> drivers/tty/serial/8250/8250_port.c | 8 ++---
> drivers/tty/serial/qcom_geni_serial.c | 10 --
> include/linux/kgdb.h| 9 ++---
> include/linux/serial_core.h | 38 -
> kernel/debug/debug_core.c | 2 +-
> kernel/smp.c| 4 ++-
> 18 files changed, 80 insertions(+), 53 deletions(-)
>
> --
> 2.19.1.568.g152ad8e336-goog
>
--
With Best Regards,
Andy Shevchenko
match_string() returns the index of an array for a matching string,
which can be used intead of open coded implementation.
Signed-off-by: Andy Shevchenko
---
drivers/pci/pcie/aer.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci
/* not completely contained */
Usually we are expecting real eeror codes.
> + if (firstpp == NULL)
> + firstpp = pp;
> + }
> + if (firstpp == NULL)
> + return -1; /* didn't find any conflicting entries? */
Ditto.
> +}
> +EXPORT_SYMBOL(reparent_resources);
--
With Best Regards,
Andy Shevchenko
On Tue, Jun 12, 2018 at 12:38 PM, Baoquan He wrote:
> On 06/12/18 at 11:29am, Andy Shevchenko wrote:
>> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
>> > +{
>>
>> > + for (pp = &parent->child; (p = *pp) != NULL; pp = &p->sibling)
On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
wrote:
> On Tue, Jun 12, 2018 at 12:38 PM, Baoquan He wrote:
>> On 06/12/18 at 11:29am, Andy Shevchenko wrote:
>>> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
>
>>> > +{
>>>
>>> > +
; + device_for_each_child_shutdown(dev);
> }
> spin_unlock(&devices_kset->list_lock);
> + device_links_read_unlock(idx);
> }
>
> /*
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 055a69d..8a0f784 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -1003,6 +1003,7 @@ struct device {
> booloffline:1;
> boolof_node_reused:1;
> booldma_32bit_limit:1;
> + boolshutdown:1; /* one direction: false->true */
> };
>
> static inline struct device *kobj_to_dev(struct kobject *kobj)
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote:
> On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
>> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
>> wrote:
>> > I briefly looked at the code and error codes we have, so, my proposal
>> > is one of the followi
On Wed, Jul 4, 2018 at 7:10 AM, Baoquan He wrote:
> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> so that it's shared.
With couple of comments below,
Reviewed-by: Andy Shevchenko
pci_mem2
>> 73b4390f Ralf Baechle 2008-07-16 58 };
>> 73b4390f Ralf Baechle 2008-07-16 59
>>
>> :: The code at line 57 was first introduced by commit
>> :: 73b4390fb23456964201abda79f1210fe337d01a [MIPS] Routerboard 532:
>> Support for base system
>>
>> :: TO: Ralf Baechle
>> :: CC: Ralf Baechle
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
>
--
With Best Regards,
Andy Shevchenko
;,
> +p->name, p, res->name);
Now, PCI is a bit confusing here.
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(reparent_resources);
> +
> static void __init __reserve_region_with_split(struct resource *root,
> resource_size_t start, resource_size_t end,
> const char *name)
> --
> 2.13.6
>
--
With Best Regards,
Andy Shevchenko
On Wed, Jul 18, 2018 at 7:36 PM, Andy Shevchenko
wrote:
> On Wed, Jul 18, 2018 at 5:49 AM, Baoquan He wrote:
>> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
>> and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
>> so that it'
This simplifies and standardizes slot manipulation code
by using for_each_set_bit() library function.
Signed-off-by: Andy Shevchenko
---
drivers/pci/pcie/aer.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie
ter or member 'context' not described in
'aer_isr'
aer.c:1209: warning: Excess function parameter 'work' description in 'aer_isr'
Fix the above accordingly.
Signed-off-by: Andy Shevchenko
---
drivers/pci/pcie/aer.c | 4 +++-
1 file changed, 3 insertions(+), 1
On Tue, Aug 27, 2019 at 10:06:54AM -0700, Kuppuswamy Sathyanarayanan wrote:
>
> On 8/27/19 8:18 AM, Andy Shevchenko wrote:
> > Kernel-doc validator complains:
> >
> > aer.c:207: warning: Function parameter or member 'str' not described in
> > '
On Fri, Sep 27, 2019 at 07:39:13AM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 27, 2019 at 06:18:22PM +0300, Andy Shevchenko wrote:
> > This simplifies and standardizes slot manipulation code
> > by using for_each_set_bit() library function.
> > + unsigned long status = info-
e == PCI_DEVICE_ID_MOTOROLA_MPC5200B)) {
Also note, you can move this to use pci_match_id().
That kind of patch might be approved.
--
With Best Regards,
Andy Shevchenko
d671ebbaebfc2 ("[PATCH v7 3/6] PCI: Allow
> pci_bus_for_each_resource() to take less arguments")
> url:
> https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/kernel-h-Split-out-COUNT_ARGS-and-CONCATENATE/20230324-013857
> base: https://git.kernel.org/cgit/
pcmcia patch (Dominik)
Changelog v2:
- refactor to have two macros
- refactor existing pci_bus_for_each_resource() in the same way and
convert users
Andy Shevchenko (6):
kernel.h: Split out COUNT_ARGS() and CONCATENATE()
PCI: Introduce pci_resource_n()
PCI: Document pci_bus_for_each_resource
Introduce pci_resource_n() and replace open-coded implementations of it
in pci.h.
Signed-off-by: Andy Shevchenko
Reviewed-by: Philippe Mathieu-Daudé
---
include/linux/pci.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/pci.h b/include/linux
kernel.h is being used as a dump for all kinds of stuff for a long time.
The COUNT_ARGS() and CONCATENATE() macros may be used in some places
without need of the full kernel.h dependency train with it.
Here is the attempt on cleaning it up by splitting out these macros().
Signed-off-by: Andy
.
Suggested-by: Andy Shevchenko
Signed-off-by: Mika Westerberg
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
---
.clang-format | 1 +
arch/alpha/kernel/pci.c | 5 ++--
arch/arm/kernel/bios32.c | 16 ++---
arch
There might be a confusion with the implementation of the
pci_bus_for_each_resources() due to side effect of Logical
OR. Document entire macro and explain how it works and why
the conditional needs to be like that.
Signed-off-by: Andy Shevchenko
---
include/linux/pci.h | 20
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
Reviewed-by: Philippe Mathieu-Daudé
---
drivers/eisa/pci_eisa.c | 4 ++--
1
Refactor pci_bus_for_each_resource() in the same way as it's done in
pci_dev_for_each_resource() case. This will allow to hide iterator
inside the loop, where it's not used otherwise.
No functional changes intended.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
R
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
Acked-by: Dominik Brodowski
---
drivers/pcmcia/rsrc_nonstatic.c | 9
On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > Provide two new helper macros to iterate over PCI device resources and
> > convert users.
> >
> > Looking at it, refactor existing pci_
On Thu, Mar 30, 2023 at 07:24:34PM +0300, Andy Shevchenko wrote:
...
> @@ -960,12 +960,9 @@ static int nonstatic_autoadd_resources(struct
> pcmcia_socket *s)
>*/
> if (s->cb_dev->bus->number == 0)
> return -EINVAL;
> -
> - for (i =
On Thu, Mar 30, 2023 at 07:24:32PM +0300, Andy Shevchenko wrote:
> Refactor pci_bus_for_each_resource() in the same way as it's done in
> pci_dev_for_each_resource() case. This will allow to hide iterator
> inside the loop, where it's not used otherwise.
>
> No functional
On Wed, Apr 05, 2023 at 03:18:32PM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 05, 2023 at 11:28:27AM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
..
On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > Provide two new helper macros to iterate over PCI device resources and
&
On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote:
> On Tue, 30 May 2023 at 23:34, Bjorn Helgaas wrote:
> > On Fri, May 12, 2023 at 02:48:51PM -0500, Bjorn Helgaas wrote:
> > > On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> > > > On T
On Thu, Jun 01, 2023 at 07:25:46PM +0300, Andy Shevchenko wrote:
> On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote:
> > On Tue, 30 May 2023 at 23:34, Bjorn Helgaas wrote:
> > > On Fri, May 12, 2023 at 02:48:51PM -0500, Bjorn Helgaas wrote:
...
> > > Whe
sl.o[1].
> > So in my book a bool SERIAL_8250_FSL that modifies 8250_base.ko (with
> > SERIAL_8250=m) is fine.
> > [1] 8250_port.o uses fsl8250_handle_irq() from 8250_fsl.o
>
> Is that after some fix which isn't in tty-next? I see only these:
>
> $ git grep -l fsl8250_handle_irq
> arch/powerpc/kernel/legacy_serial.c
> drivers/tty/serial/8250/8250_fsl.c
> drivers/tty/serial/8250/8250_of.c
> include/linux/serial_8250.h
>
> No users of fsl8250_handle_irq in 8250_port.c.
> >, and 8250_fsl.o uses serial8250_modem_status from 8250_port.o.
I don't like 8250_base to be fattened by some stuff that has no
generic meaning. Can we avoid putting every quirk there?
--
With Best Regards,
Andy Shevchenko
looking into this! I think you're right, and I think
> the rewritten expression is more logical as well. Do you want to post
> a patch for it?
Gimme some time, I was on a long leave and now it's a pile to handle.
--
With Best Regards,
Andy Shevchenko
e, the kernel has always
> assumed if there is a device described, then there is or will be a
> driver for it. The result is you can't use new DTs (if they add
> providers) with older kernels.
>
> We've ended up with a timeout because no one has come up with a better
> way to handle it. What the kernel needs is userspace saying "I'm done
> loading modules", but it's debatable whether that's a good solution
> too.
In my opinion the deferred probe is a big hack and that is the root
cause of the issues we have here and there. It has to be redesigned
to be mathematically robust. It was an attempt by Andrzej Hajda to
solve this [1].
[1]:
https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Deferred-Problem-Issues-With-Complex-Dependencies-Between-Devices-in-Linux-Kernel-Andrzej-Hajda-Samsung.pdf
--
With Best Regards,
Andy Shevchenko
The OF node in the GPIO library is deprecated and soon
will be removed.
GPIO library now accepts fwnode as a firmware node, so
switch the driver to use it.
Signed-off-by: Andy Shevchenko
---
drivers/soc/fsl/qe/gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a
The fwnode_device_is_compatible() helper searches for the
given string in the "compatible" string array property and,
if found, returns true.
Signed-off-by: Andy Shevchenko
---
include/linux/property.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/property.h
On Wed, Oct 05, 2022 at 05:38:11PM +0300, Andy Shevchenko wrote:
> The fwnode_device_is_compatible() helper searches for the
> given string in the "compatible" string array property and,
> if found, returns true.
Scratch this, it has some flaws.
--
With Best Regards,
Andy Shevchenko
of_device_is_compatible()
with analogous fwnode API.
Changelog v2:
- placed new helper correctly in the property.h
Andy Shevchenko (2):
device property: Introduce fwnode_device_is_compatible() helper
soc: fsl: qe: Switch to use fwnode instead of of_node
drivers/soc/fsl/qe/gpio.c | 4
The fwnode_device_is_compatible() helper searches for the
given string in the "compatible" string array property and,
if found, returns true.
Signed-off-by: Andy Shevchenko
---
include/linux/property.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/inc
The OF node in the GPIO library is deprecated and soon
will be removed.
GPIO library now accepts fwnode as a firmware node, so
switch the driver to use it.
Signed-off-by: Andy Shevchenko
---
drivers/soc/fsl/qe/gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a
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#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/device-property-Introdu
On Wed, Oct 05, 2022 at 09:05:54PM +, Sakari Ailus wrote:
> On Wed, Oct 05, 2022 at 06:29:46PM +0300, Andy Shevchenko wrote:
...
> fwnode_property_match_string() returns zero on success, therefore >= 0 is
> not needed. I'd just use !fwnode_property_match_string(...).
No
at'd work, but again it's not more clear. Authors here are going for
> a 24-bit number, and masking seems like a clear way to express that.
We have some 24-bit APIs (and 48-bit) already in kernel, why not to have
get_random_u24() ?
--
With Best Regards,
Andy Shevchenko
. I'll move these to patch #1.
I believe coccinelle is able to handle this kind of code as well, so Kees'
proposal to use it seems more plausible since it's less error prone and more
flexible / powerful.
--
With Best Regards,
Andy Shevchenko
e stuff can
> have a chance to flow through subsystem trees.
+1 to all arguments for the splitting.
I looked a bit into the code I have the interest to, but I won't spam people
with not-so-important questions / comments / tags, etc.
--
With Best Regards,
Andy Shevchenko
gt; expression add_one.RESULT;
> >> identifier FUNC;
> >> @@
> >>
> >> - (FUNC()@p & (LITERAL))
> >> + prandom_u32_max(RESULT)
> >
> >Oh that's pretty cool. I can do the saturation check in python, since
> >`value` holds the parsed result. Neat.
>
> It is (at least how I have it here) just the string, so YMMV.
...
> >Thanks a bunch for the guidance.
>
> Sure thing! I was pleased to figure out how to do the python bit.
I believe it can be optimized
--
With Best Regards,
Andy Shevchenko
On Wed, Oct 05, 2022 at 06:29:45PM +0300, Andy Shevchenko wrote:
> One more user outside of GPIO library and pin control folders needs
> to be updated to use fwnode instead of of_node. To make this easier
> introduce a helper in property.h and convert the user.
>
> Note, the helper
On Fri, Oct 21, 2022 at 10:01:34PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 05, 2022 at 06:29:45PM +0300, Andy Shevchenko wrote:
> > One more user outside of GPIO library and pin control folders needs
> > to be updated to use fwnode instead of of_node. To make this easier
> &g
uickly reading it seems to be a wrong approach (or wrong end to
start solving the issue from).
--
With Best Regards,
Andy Shevchenko
_unregister() and put a warning to dmesg if it's not.
> Actually in many cases it doesn't really need to turn off the leds manually
> one-by-one
> if driver shutdowns whole led controller. For the last case to disable the
> warning
> new flag can be brought in e.g LE
On Sat, Nov 25, 2023 at 03:47:41AM +0300, George Stark wrote:
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> > > Lots of drivers use devm_led_classdev_register() to register their led
> > > objects
&g
ed when driver is detached.
the driver
Have you run scripts/kernel-doc -v -Wall -none ... against this file?
I'm pretty sure it will complain.
> + */
--
With Best Regards,
Andy Shevchenko
ee to add
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
be
ret = devm_mutex_init(&client->dev, &chip->mutex);
if (ret)
return ret;
?
> + return -ENOMEM;
--
With Best Regards,
Andy Shevchenko
->dev, &chip->mutex))
> + return -ENOMEM;
Do not shadow the real error code.
--
With Best Regards,
Andy Shevchenko
our compilers are sane and generate better code against
> properly annotated data, the above discrepancy doesn't look weird. When
> running on non-volatile bitmaps, plain find_bit() outperforms atomic
> find_and_bit(), and vice-versa.
...
In some cases the better improvements can be achieved by switching
the (very) old code to utilise IDA framework.
--
With Best Regards,
Andy Shevchenko
https://lore.kernel.org/lkml/070c174c-057a-46de-ae8e-836e9e20e...@salutedevices.com/T/#mb42e1d7760816b0cedd3130e08f29690496b5ac2
> >
> > Looking at it closer, I have the feeling that you want to do similar to
> > devm_gpio_request() in linux/gpio.h :
> >
> > In linux/mutex.h, add a prototype for devm_mutex_init() when
> > CONFIG_DEBUG_MUTEXES is defined and an empty static inline otherwise.
> > Then define devm_mutex_init() in kernel/locking/mutex-debug.c
>
> Yes, this would be almost perfect decision. BTW just as in linux/gpio.h
> we wouldn't have to include whole "linux/device.h" into mutex.h, only
> add forward declaration of struct device;
>
> > Wouldn't that work ?
No. It will require inclusion of device.h (which is a twisted hell
from the header perspective) into mutex.h. Completely unappreciated
move.
--
With Best Regards,
Andy Shevchenko
in linux/gpio.h
> we wouldn't have to include whole "linux/device.h" into mutex.h, only
> add forward declaration of struct device;
In case you place it into a C-file. Otherwise you need a header for
the API and that is not acceptable for mutex.h.
--
With Best Regards,
Andy Shevchenko
On Thu, Dec 7, 2023 at 2:31 PM Christophe Leroy
wrote:
> Le 07/12/2023 à 12:59, Andy Shevchenko a écrit :
> > On Thu, Dec 7, 2023 at 1:23 AM George Stark
> > wrote:
> >> On 12/7/23 01:37, Christophe Leroy wrote:
> >>> Le 06/12/2023 à 23:14, Christophe Leroy
dev, struct mutex *lock)
> +{
> + mutex_init(lock);
> +#ifdef mutex_destroy
> + return devm_add_action_or_reset(dev, devm_mutex_release, lock);
> +#else
> + return 0;
> +#endif
> +}
If this is going to be accepted, you may decrease the amount of ifdeffery.
#
On Thu, Dec 14, 2023 at 12:36 AM Andy Shevchenko
wrote:
> On Thu, Dec 14, 2023 at 12:30 AM George Stark
> wrote:
> >
> > Using of devm API leads to a certain order of releasing resources.
> > So all dependent resources which are not devm-wrapped should be deleted
ementation to be in the
very same _C_-file where mutex_destroy() is defined. mutex.h in this
case indeed requires the only forward declaration and hence doesn't
need to include device.h.
--
With Best Regards,
Andy Shevchenko
series #3 are online.
Nikita is right. This patch was the last in the mailing lists. Fix your mail
gateways, it quite likely the mail server in your organisation filters out
some mails as spam or so. I highly recommend to escalate this with your IT
department.
--
With Best Regards,
Andy Shevchenko
utex *lock);
> +int devm_mutex_init(struct device *dev, struct mutex *lock);
> +#else
> +static inline void mutex_destroy(struct mutex *lock) {}
> +
> +static inline int devm_mutex_init(struct device *dev, struct mutex *lock)
> +{
> + mutex_init(lock);
> + return 0;
> +}
> +#endif
--
With Best Regards,
Andy Shevchenko
2f895...@salutedevices.com/T/
> > [2]
> > https://lore.kernel.org/lkml/8704539b-ed3b-44e6-aa82-586e2f895...@salutedevices.com/T/#mc132b9b350fa51931b4fcfe14705d9f06e91421f
> > [3]
> > https://lore.kernel.org/lkml/8704539b-ed3b-44e6-aa82-586e2f895...@salutedevices.com/
14705d9f06e91421f
> [3]
> https://lore.kernel.org/lkml/8704539b-ed3b-44e6-aa82-586e2f895...@salutedevices.com/T/#mdbf572a85c33f869a553caf986b6228bb65c8383
Are you going to send an updated version with the amended second patch?
--
With Best Regards,
Andy Shevchenko
updated
version into your series. Am I wrong?
> Sure I can single out the fix-only patch I'll do it tomorrow.
I believe it can be handled without issuing it separately. `b4` tool
is capable of selective choices. It was rather Q to Lee if he can/want
to apply it right away.
> On 2/
these are being used, am I right?
What's is missing OTOH is the mod_devicetable.h.
> +#include
> +#include
+ Blank line?
> +#include
--
With Best Regards,
Andy Shevchenko
d exporting for
> modules.
Wondering if you are trying to have something like
https://lore.kernel.org/lkml/20230926052007.3917389-1-andriy.shevche...@linux.intel.com/
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 12, 2024 at 02:37:53PM +0100, Herve Codina wrote:
> On Mon, 12 Feb 2024 14:27:16 +0200
> Andy Shevchenko wrote:
> > On Mon, Feb 12, 2024 at 08:56:31AM +0100, Herve Codina wrote:
> > > Currently the bitmap_onto() is available only for CONFIG_NUMA=y case,
>
On Mon, Feb 12, 2024 at 03:20:22PM +0100, Herve Codina wrote:
> On Mon, 12 Feb 2024 16:01:38 +0200
> Andy Shevchenko wrote:
...
> Agree, the bitmap_onto() code is simpler to understand than its help.
>
> I introduced bitmap_off() to be the "reverse" bitmap_onto() ope
On Tue, Feb 13, 2024 at 2:14 AM George Stark wrote:
>
> Hello Andy
>
> On 2/12/24 12:53, Andy Shevchenko wrote:
> > On Mon, Feb 12, 2024 at 1:52 AM George Stark
> > wrote:
> >> I haven't lose hope for the devm_mutex thing and keep pinging those guys
&
), perhaps in a separate patch we can
replace it with bitmap_scatter() (IIUC) with explanation that the former
1) uses atomic ops while being non-atomic as a whole, and b) having quite
hard to get documentation. At least that's how I see it, I mean that I would
like to leave bitmap_onto() alone and address it separately.
> Yury, any preferences ?
--
With Best Regards,
Andy Shevchenko
101 - 200 of 474 matches
Mail list logo
