fine PIO_RESERVED 0x4UL
> +#endif
--
With Best Regards,
Andy Shevchenko
On Mon, Apr 14, 2025 at 07:47:26PM +0300, Avizrat, Yaron wrote:
> On 14/04/2025 13:07, Andy Shevchenko wrote:
> > On Sun, Mar 30, 2025 at 02:15:50PM +0300, Avizrat, Yaron wrote:
> >> On 26/03/2025 11:55, Jani Nikula wrote:
> >>> On Wed, 26 Mar 2025, Andy Shevchenko
sed host ordering")
>
There shouldn't be blank lines in the tag block.
> Signed-off-by: Aditya Garg
--
With Best Regards,
Andy Shevchenko
er to have cache working if it's possible. The only BUT here is
that users should not suffer from it.
> So, ideally, we should move to (b). For Spinx, the easiest solution
> is just to place it under Documentation/output, but this is not
> generic enough: ideally, we should revert patch 3 and set
> PYTHONCACHEPREFIX when O is used. Eventually, we can apply my
> patch for Documentation/output, while we craft such logic.
--
With Best Regards,
Andy Shevchenko
The custom definition of PCI vendor ID in video/mach64.h is unused.
Remove it. Note, that the proper one is available in pci_ids.h.
Signed-off-by: Andy Shevchenko
---
include/video/mach64.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/video/mach64.h b/include/video/mach64.h
On Thu, Apr 24, 2025 at 11:07:05AM +0900, Akira Yokosawa wrote:
> On Wed, 23 Apr 2025 19:31:36 +0300, Andy Shevchenko wrote:
> > On Wed, Apr 23, 2025 at 06:30:48PM +0900, Akira Yokosawa wrote:
> >> On Tue, 22 Apr 2025 10:57:33 +0300, Andy Shevchenko wrote:
> >>> On M
On Wed, Apr 23, 2025 at 06:30:48PM +0900, Akira Yokosawa wrote:
> On Tue, 22 Apr 2025 10:57:33 +0300, Andy Shevchenko wrote:
> > On Mon, Apr 21, 2025 at 10:35:29AM -0600, Jonathan Corbet wrote:
> >> Dmitry Baryshkov writes:
[...]
> >> > Would it be possible to prop
it is for IPv4 case?
> > Avoid the confusion by replacing the "n" modifier with "hR", aka
> > reverse host ordering.
Not ideal, but better than 'h'ost / 'r'everse pair. Not giving a tag and not
objecting either if there is a consensus.
--
With Best Regards,
Andy Shevchenko
On Tue, Apr 22, 2025 at 08:45:31PM +0530, Aditya Garg wrote:
> On 22-04-2025 04:02 pm, Geert Uytterhoeven wrote:
> > On Tue, 22 Apr 2025 at 12:16, Andy Shevchenko
> > wrote:
...
> > I am not against h/n in se, but I am against bad/confusing naming.
> > The big q
On Tue, Apr 22, 2025 at 12:32:42PM +0200, Geert Uytterhoeven wrote:
> On Tue, 22 Apr 2025 at 12:16, Andy Shevchenko
> wrote:
> > On Tue, Apr 22, 2025 at 10:43:59AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, 22 Apr 2025 at 10:30, Aditya Garg wrote:
> > > &
onally, I like "%p4r" (reverse) more...
> (and "%p4ch" might mean human-readable ;-)
It will confuse the reader. h/r is not very established pair. If you really
wont see h/n, better to drop them completely for now then. Because I'm against
h/r pair.
> [1] https://lore.kernel.org/all/z8b6dwcrbv-8d...@smile.fi.intel.com
--
With Best Regards,
Andy Shevchenko
ples for a big-endian machine, given &(u32)0x67503030::
> > +
> > + %p4ch gP00 (0x67503030)
> > + %p4cn 00Pg (0x30305067)
>
> This doesn't look right to me, as network byte order is big endian?
> Note that I didn't check the code.
Yes, network is big endian and this seems right to me. What is the confusion?
> > + %p4cl 00Pg (0x30305067)
> > + %p4cb gP00 (0x67503030)
--
With Best Regards,
Andy Shevchenko
sy. The Python is written in a way that it thinks it will never
runs object files separately from the source. Hence that variable sets only
the folder per script as _home_ for the cache. It's completely unusable. They
took it wrong. It still can be _painfully_ used, but it will make Makefiles
uglier.
--
With Best Regards,
Andy Shevchenko
ensure that the entire Kbuild
> will use KERNELDOC var for the location of kernel-doc;
> - patch 4 adds *.pyc at the list of object files to be ignored.
This one works for me, thanks!
Tested-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
ow.
Take your time, we still have a couple or so weeks to address this.
--
With Best Regards,
Andy Shevchenko
On Wed, Apr 16, 2025 at 05:29:01PM +0800, Mauro Carvalho Chehab wrote:
> Em Wed, 16 Apr 2025 17:19:17 +0800
> Mauro Carvalho Chehab escreveu:
...
> could you please check if this patch solves the issue?
Doesn't work for me.
--
With Best Regards,
Andy Shevchenko
ile
> +++ b/Makefile
> @@ -458,6 +458,8 @@ endif
> HOSTRUSTC = rustc
> HOSTPKG_CONFIG = pkg-config
>
> +KERNELDOC = $(srctree)/scripts/kernel-doc.py
> +
> KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
>-O2 -fomit-frame-pointer -std=gnu11
> KBUILD_USERCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS)
--
With Best Regards,
Andy Shevchenko
>
> $ grep KERNELDOC Documentation/Makefile
> KERNELDOC = $(srctree)/scripts/kernel-doc.py
> ...
>
> drivers/gpu/drm/Makefile should be able to see this variable there...
Does it work in the case of `make drivers/gpu/drm` ? This is probably how Jani
tried it.
> > > touch $@
--
With Best Regards,
Andy Shevchenko
> scripts/find-unused-docs.sh.
Nope, still have it.
I used today's Linux Next with some local code patches (unrelated
to any scripts or kernel doc or python).
To confirm, I even done again a clean build.
--
With Best Regards,
Andy Shevchenko
On Sun, Mar 30, 2025 at 02:15:50PM +0300, Avizrat, Yaron wrote:
>
> On 26/03/2025 11:55, Jani Nikula wrote:
> > On Wed, 26 Mar 2025, Andy Shevchenko
> > wrote:
> >> +Cc: Jani (sorry, forgot to add you in the first place).
> >>
> >> Do you think
t as it has more cons than more invasive
solutions. In particular, it makes build time increase with a lot of work to
be made at link time, and also it might hide the real bugs when somebody simply
forgot to use it (depending on the configuration options) or so.
--
With Best Regards,
Andy Shevchenko
printing FourCCs. But the disadvange was that
> they were being printed in a reverse order. %p4cl should correct this
> issue.
--
With Best Regards,
Andy Shevchenko
On Tue, Apr 08, 2025 at 08:52:10AM +, Aditya Garg wrote:
> > On 8 Apr 2025, at 2:11 PM, Andy Shevchenko
> > wrote:
> > On Tue, Apr 08, 2025 at 12:17:13PM +0530, Aditya Garg wrote:
> >> The vsprint patch was originally being sent as a seperate patch [1], and
> &
w it's patch 3 threaded to patch 1, while the rest, including cover letter,
seems okay.
--
With Best Regards,
Andy Shevchenko
On Mon, Apr 07, 2025 at 07:57:08PM +0530, Aditya Garg wrote:
> On 07-04-2025 07:52 pm, Andy Shevchenko wrote:
> > On Mon, Apr 07, 2025 at 02:17:00PM +, Aditya Garg wrote:
> >>> On 7 Apr 2025, at 7:26 PM, Andy Shevchenko
> >>> wrote:
> >>> On Mon,
On Mon, Apr 07, 2025 at 02:17:00PM +, Aditya Garg wrote:
> > On 7 Apr 2025, at 7:26 PM, Andy Shevchenko
> > wrote:
> > On Mon, Apr 07, 2025 at 07:05:13PM +0530, Aditya Garg wrote:
> >> The vsprint patch was originally being sent as a seperate patch [1], and
> &
b7e9...@live.com/ [1]
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 26, 2025 at 11:55:33AM +0200, Jani Nikula wrote:
> On Wed, 26 Mar 2025, Andy Shevchenko
> wrote:
> > +Cc: Jani (sorry, forgot to add you in the first place).
> >
> > Do you think it's applicable now?
>
> Cc: Yaron, Koby, and Konstantin who are s
+Cc: Jani (sorry, forgot to add you in the first place).
Do you think it's applicable now?
On Wed, Mar 05, 2025 at 01:00:25PM +0200, Andy Shevchenko wrote:
> Use %ptTs instead of open-coded variant to print contents of time64_t type
> in human readable form.
>
> This changes N
value matches the expected type. Since
> those are known at build time, use static_assert() instead of normal
> kunit tests.
New tests always have a green light to go from my point of view,
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 26, 2025 at 12:59:58AM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Lucas De Marchi
>
> Implement fixed-type BIT_U*() to help drivers add stricter checks,
> like it was done for GENMASK_U*().
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
d-by: Lucas De Marchi
New tests always have a green light to go from my point of view,
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
et the correct type, but rather to enforce more checks at
> compile time.
>
> While GENMASK_TYPE() is crafted to cover all variants, including the
> already existing GENMASK(), GENMASK_ULL() and GENMASK_U128(), for the
> moment, only use it for the newly introduced GENMASK_U*(). The
&g
endif.
>
> Add a comment to the #else and #endif preprocessor macros to help keep
> track of which context we are in. Also, add new lines to better
> visually separate the non-asm and asm sections.
Reviewed-by: Andy Shevchenko
Thanks!
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 24, 2025 at 11:16:30PM +0900, Vincent Mailhol wrote:
> On 24/03/2025 at 22:41, Andy Shevchenko wrote:
> > On Sat, Mar 22, 2025 at 06:23:13PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
...
> >> +/*
> >> + * Fixed-type variants of B
gt; + * - BIT_U32(40)
> + */
--
With Best Regards,
Andy Shevchenko
ate patch (prerequisite) or dropped them at all.
These are not big but unneeded churn,
--
With Best Regards,
Andy Shevchenko
g/doc/ (once applied, of course).
I am all to support the idea, but in some cases I would think of a bit
more work to be done to get rid of the of_fwnode_handle(np) in favour
of dev_fwnode(dev). Note, this is based on a brief look, I haven't any
example at hand right now.
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 07, 2025 at 01:08:15AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 22:11, Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 08:29:58PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> From: Vincent Mailhol
> >>
> >> Add some additi
On Thu, Mar 13, 2025 at 11:06:54AM +, Aditya Garg wrote:
> > On 13 Mar 2025, at 4:18 PM, Petr Mladek wrote:
> > On Thu 2025-03-13 09:13:23, Aditya Garg wrote:
> >>> On 13 Mar 2025, at 2:27 PM, Andy Shevchenko
> >>> wrote:
> >>> On Thu, Mar
On Thu, Mar 13, 2025 at 08:53:28AM +, Aditya Garg wrote:
> > On 13 Mar 2025, at 2:19 PM, Andy Shevchenko
> > wrote:
> > On Thu, Mar 13, 2025 at 07:26:05AM +, Aditya Garg wrote:
> >>>> On 13 Mar 2025, at 12:58 AM, Andy Shevchenko
> >>>>
On Thu, Mar 13, 2025 at 07:26:05AM +, Aditya Garg wrote:
> > On 13 Mar 2025, at 12:58 AM, Andy Shevchenko
> > wrote:
> > On Wed, Mar 12, 2025 at 07:14:36PM +, Aditya Garg wrote:
> >>> On 12 Mar 2025, at 9:05 PM, Sven Peter wrote:
> >>> On Wed,
On Wed, Mar 12, 2025 at 07:35:54PM +, Aditya Garg wrote:
> > On 13 Mar 2025, at 12:58 AM, Andy Shevchenko
> > wrote:
> > On Wed, Mar 12, 2025 at 07:14:36PM +, Aditya Garg wrote:
> >>>> On 12 Mar 2025, at 9:05 PM, Sven Peter wrote:
> >>> On W
t for the vsprintf.c?
> > which are then used like this:
> >
> >dev_info(dev,
> >"Initialized (%d keys " SMC_KEY_FMT " .. " SMC_KEY_FMT ")\n",
> > smc->key_count, SMC_KEY_ARG(smc->first_key),
> > SMC_KEY_ARG(smc->last_key));
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 07, 2025 at 12:07:45AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 22:05, Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 08:29:52PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> From: Vincent Mailhol
...
> >> -/*
> >> - * BUI
n the immediate followup. Can you come up in a better text
here and/or there so it will give only + LoCs (or minimizes - to 1:ish)?
--
With Best Regards,
Andy Shevchenko
o review the changes and see that the first line is kept
the same.
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 07, 2025 at 12:48:36PM -0500, Yury Norov wrote:
> On Fri, Mar 07, 2025 at 07:43:57PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 07, 2025 at 12:18:02PM -0500, Yury Norov wrote:
> > > No rush, please allow your reviewers a week or two before submitting
> > >
On Fri, Mar 07, 2025 at 07:48:01PM +0200, Andy Shevchenko wrote:
> On Sat, Mar 08, 2025 at 01:48:50AM +0900, Vincent Mailhol via B4 Relay wrote:
...
> > /*
> > * Missing asm support
> > *
> > - * GENMASK_U*() depends on BITS_PER_TYPE() which relies on size
ays.
>
> So, what should I do? Go through the v5 and all discussions in there,
> or just jump on this?
There is also question to you. Are we going to leave with U128 variants or is
it subject to remove? If the latter, can you issue a formal patch?
--
With Best Regards,
Andy Shevchenko
reasons with previous implementation
> */
--
With Best Regards,
Andy Shevchenko
hertheless, fixed width integers
> + * is a C concept. Assembly code can rely on the long and long long
> + * versions instead.
> */
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 07, 2025 at 07:11:42PM +0900, Vincent Mailhol wrote:
> On 07/03/2025 at 02:55, Andy Shevchenko wrote:
> > On Fri, Mar 07, 2025 at 01:08:15AM +0900, Vincent Mailhol wrote:
> >> On 06/03/2025 at 22:11, Andy Shevchenko wrote:
> >>> On Thu, Mar 06, 2025 at 08:
379 376 -3
> Total: Before=22723481, After=22723482, chg +0.00%
>
> (done with GCC 12.4.1 on a defconfig)
What defconfig? x86_64_defconfig?
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 07, 2025 at 01:08:01AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 à 22:08, Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 08:29:53PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
...
> Does this mean I get your Reviewed-by tag? Or will you wait the v6 to
K*() as they
went split and it will be a good regression test in case somebody decides to
unify both without much thinking..
--
With Best Regards,
Andy Shevchenko
r example:
>
> GENMASK_U16(16, 0)
>
> will raise a build bug.
This version LGTM, just a couple of comments that you may find
in the individual replies.
--
With Best Regards,
Andy Shevchenko
51 | type_max(t) >> (BITS_PER_TYPE(t) - 1 - (h)
> | ^~
Code LGTM, but just to be sure: you prepared your series using histogram
diff algo, right?
--
With Best Regards,
Andy Shevchenko
..
> +#else /* defined(__ASSEMBLY__) */
...here.
Otherwise justify its removal in the commit message.
> +#define GENMASK(h, l)__GENMASK(h, l)
> +#define GENMASK_ULL(h, l)__GENMASK_ULL(h, l)
> +
> +#endif /* !defined(__ASSEMBLY__) */
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 06, 2025 at 06:22:33PM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 04:45, Andy Shevchenko wrote:
> >>> But GENMASK_U128() becomes a special case now.
> >>> The 128-bit GENMASK is unsued, but it's exported in uapi. Is there any
> >
On Wed, Mar 05, 2025 at 09:50:27PM +, David Laight wrote:
> On Wed, 5 Mar 2025 21:56:22 +0200
> Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 02:17:18AM +0900, Vincent Mailhol wrote:
> > > On 06/03/2025 at 00:48, Andy Shevchenko wrote:
> > > > On Wed,
On Thu, Mar 06, 2025 at 02:17:18AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 00:48, Andy Shevchenko wrote:
> > On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> >> On 05/03/2025 at 23:33, Andy Shevchenko wrote:
> >>> On Wed, Mar 05, 2025 at 10:
28 bits integers.
>
> This is where I am stuck. If someone can guide me on how to write a
> robust U128() macro, then I think the common implementation could be
> feasible.
I think we may leave that U128 stuff alone for now.
--
With Best Regards,
Andy Shevchenko
If you can't find it
there, you may remove from uAPI with a little chance of the ABI regression.
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> On 05/03/2025 at 23:33, Andy Shevchenko wrote:
> > On Wed, Mar 05, 2025 at 10:00:16PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
...
> >> +#define BIT_U8(b) (BIT_INPUT_CHECK(u8, b) + (unsigned i
On Wed, Mar 05, 2025 at 11:38:19PM +0900, Vincent Mailhol wrote:
> On 05/03/2025 at 23:30, Andy Shevchenko wrote:
> > On Wed, Mar 05, 2025 at 10:00:15PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
...
> > Perhaps T or TYPE will suffice. Or perhaps we want
> > __GEN
each driver to use
> the generic macros are left for later, when/if other driver-specific
> macros are also generalized.
--
With Best Regards,
Andy Shevchenko
gt; Thanks for respinning the series. I'll take this fix in bitmap-for-next, so
> if you need v2, you'll not have to bear this thing too.
Before doing that, please read my comment first.
--
With Best Regards,
Andy Shevchenko
i/linux/const.h
tools/include/linux/bits.h
tools/include/uapi/linux/const.h
--
With Best Regards,
Andy Shevchenko
tified.
> +#define BIT_U32(b) (BIT_INPUT_CHECK(u32, b) + (u32)BIT(b))
> +#define BIT_U64(b) (BIT_INPUT_CHECK(u64, b) + (u64)BIT_ULL(b))
Can you also use a TAB between the parentheses for better readability?
E.g.,
#define BIT_U64(b)r (BIT_INPUT_CHECK(u64, b) + (u64)BIT_ULL(b))
--
With Best Regards,
Andy Shevchenko
gt; + * __GENMASK_U*() depends on BITS_PER_TYPE() which would not work in the asm
Where are the double underscore variants? I see it only for U128.
> + * code as BITS_PER_TYPE() relies on sizeof(), something not available in
> + * asm. Nethertheless, the concept of fixed width integers is a C thing which
> + * does not apply to assembly code.
--
With Best Regards,
Andy Shevchenko
Use %ptTs instead of open-coded variant to print contents of time64_t type
in human readable form.
This changes N/A output to 1970-01-01 00:00:00 for zero timestamps,
but it's used only in the dev_err() output and won't break anything.
Signed-off-by: Andy Shevchenko
---
v3: exp
On Tue, Mar 04, 2025 at 09:01:59PM +0200, Jani Nikula wrote:
> On Thu, 06 Feb 2025, Andy Shevchenko
> wrote:
> > Use %ptTs instead of open-coded variant to print contents of time64_t type
> > in human readable form.
...
> > - char pq_time_str[64] = "N/A", eq
On Thu, Feb 06, 2025 at 09:20:43PM +0200, Andy Shevchenko wrote:
> Use %ptTs instead of open-coded variant to print contents of time64_t type
> in human readable form.
Any comments on this, please? If no, can it be applied?
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 21, 2025 at 06:15:30PM +0100, Arnd Bergmann wrote:
> On Fri, Feb 21, 2025, at 17:50, Andy Shevchenko wrote:
> > On Fri, Feb 21, 2025 at 11:15:47AM +0100, Arnd Bergmann wrote:
> >> As you already found, removing an old indirect #include that is
> >> no lon
ters;
> int no_hash_pointers_enable(char *str);
>
> +/* Used for Rust formatting ('%pA'). */
In case you need a new version, please drop a period at the end as this is the
style used in the sprintf.h already.
> +char *rust_fmt_argument(char *buf, char *end, const void *ptr);
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 03, 2025 at 09:31:06AM +0100, Arnd Bergmann wrote:
> On Mon, Mar 3, 2025, at 08:48, Andy Shevchenko wrote:
> > On Fri, Feb 28, 2025 at 09:08:15PM +0200, Raag Jadav wrote:
> >> > > > Ah, you mean devres related?
> >> > >
> >> > &g
On Fri, Feb 28, 2025 at 09:08:15PM +0200, Raag Jadav wrote:
> On Fri, Feb 28, 2025 at 08:52:51PM +0200, Andy Shevchenko wrote:
> > On Fri, Feb 28, 2025 at 08:45:26PM +0200, Raag Jadav wrote:
> > > On Fri, Feb 28, 2025 at 08:42:10PM +0200, Andy Shevchenko wrote:
> > > &
On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote:
> On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote:
> > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote:
> > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote:
> > > > On T
On Fri, Feb 28, 2025 at 08:45:26PM +0200, Raag Jadav wrote:
> On Fri, Feb 28, 2025 at 08:42:10PM +0200, Andy Shevchenko wrote:
> > On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote:
> > > On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote:
> > > &
On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote:
> On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote:
> > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote:
> > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote:
> > >> This series
le to put this in. Any advice?
I believe you found the right place.
--
With Best Regards,
Andy Shevchenko
e(const char *url, u8 *data, size_t data_len,
> size_t data_size,
> + u8 *tmp, size_t tmp_size);
Is extern needed?
> +#endif
--
With Best Regards,
Andy Shevchenko
hen have rustc verify that the function pointers have the same type.
>
> The main commit of this series is "rust: add #[export] macro". Please
> see its commit message for more details.
Thanks for the cover letter, makes much more sense now!
--
With Best Regards,
Andy Shevchenko
s one?
>
> It's empty.
So, it means nothing to review, sorry.
--
With Best Regards,
Andy Shevchenko
On Thu, Feb 27, 2025 at 05:01:58PM +, Alice Ryhl wrote:
This is unfortunate. What does this mean?
Can you, please, provide a meaningful cover letter?
> Signed-off-by: Alice Ryhl
--
With Best Regards,
Andy Shevchenko
0e770...@app.fastmail.com
I believe Arnd can take it through his tree for headers as DRM part is Acked
already.
--
With Best Regards,
Andy Shevchenko
an take them into
account.
--
With Best Regards,
Andy Shevchenko
e is a replacement to the low
level ones, it's also an improvement in my opinion and won't be harmful in
the future. But I agree, that the stuff is way too tangled already and requires
an enormous work to untangle it, even if doing it structurally.
...
Do you have your scripts for the showed statistics being published somewhere?
--
With Best Regards,
Andy Shevchenko
On Thu, Feb 20, 2025 at 12:02:51AM +0800, kernel test robot wrote:
> Hi Svyatoslav,
>
> kernel test robot noticed the following build errors:
It a second time you send not even compiled code.
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 19, 2025 at 07:39:29PM +0200, Svyatoslav Ryhel wrote:
> ср, 19 лют. 2025 р. о 17:56 Andy Shevchenko
> пише:
> > On Wed, Feb 19, 2025 at 05:13:15PM +0200, Svyatoslav Ryhel wrote:
> > > ср, 19 лют. 2025 р. о 17:07 Andy Shevchenko
> > > пише:
> > &g
On Wed, Feb 19, 2025 at 05:13:15PM +0200, Svyatoslav Ryhel wrote:
> ср, 19 лют. 2025 р. о 17:07 Andy Shevchenko
> пише:
> > On Wed, Feb 19, 2025 at 04:36:38PM +0200, Svyatoslav Ryhel wrote:
> > > ср, 19 лют. 2025 р. о 16:27 Andy Shevchenko
> > > пише:
...
>
On Wed, Feb 19, 2025 at 04:36:38PM +0200, Svyatoslav Ryhel wrote:
> ср, 19 лют. 2025 р. о 16:27 Andy Shevchenko
> пише:
> > On Tue, Feb 18, 2025 at 03:27:00PM +0200, Svyatoslav Ryhel wrote:
> > > Remove platform data and fully relay on OF and device tree
> > &g
...
if (IS_ERR(bd))
return dev_err_probe(dev, PTR_ERR(bd), "failed to register
backlight device\n");
...
> +static const struct of_device_id lm3533_bl_match_table[] = {
> + { .compatible = "ti,lm3533-backlight" },
> + { },
As per above.
> +};
--
With Best Regards,
Andy Shevchenko
On Thu, Feb 13, 2025 at 08:48:02PM +0200, Jani Nikula wrote:
> On Thu, 13 Feb 2025, Andy Shevchenko
> wrote:
> > Other subsystem(s) may want to reuse the for_each_if() macro.
> > Move it to util_macros.h to make it globally available.
> Acked-by: Jani Nikula
Thanks!
>
On Thu, Feb 13, 2025 at 07:36:38PM +0100, Bartosz Golaszewski wrote:
> On Thu, Feb 13, 2025 at 7:25 PM Andy Shevchenko
> wrote:
> >
> > Other subsystem(s) may want to reuse the for_each_if() macro.
> > Move it to util_macros.h to make it globally available.
> Revie
Instead of opencoding with long lines, use for_each_if() macro
which makes intention clearer and less error prone.
In v2:
- moved original for_each_if() implementation to the global header (Bart)
Andy Shevchenko (2):
drm: Move for_each_if() to util_macros.h for wider use
gpiolib: Switch to
The for_each_*() APIs that are conditional can be written shorter and
less error prone with for_each_if() helper in use. Switch them to use
this helper.
Signed-off-by: Andy Shevchenko
---
include/linux/gpio/driver.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a
Other subsystem(s) may want to reuse the for_each_if() macro.
Move it to util_macros.h to make it globally available.
Suggested-by: Bartosz Golaszewski
Signed-off-by: Andy Shevchenko
---
include/drm/drm_util.h | 16 +---
include/linux/util_macros.h | 15 +++
2
t; +{
3rd dup?
> +}
...
> pdata = dev_get_platdata(&pdev->dev);
> if (!pdata) {
> - dev_err(&pdev->dev, "no platform data\n");
> - return -EINVAL;
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + ret = lm3533_pass_of_node(pdev, pdata);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to get backlight device
> node\n");
> +
> + lm3533_parse_backlight(pdev, pdata);
> }
Ditto.
> - bd = devm_backlight_device_register(&pdev->dev, pdata->name,
> - pdev->dev.parent, bl, &lm3533_bl_ops,
> - &props);
> + bd = devm_backlight_device_register(&pdev->dev, dev_name(&pdev->dev),
I'm not sure the dev_name() is a good idea. We usually try to rely on the
predictable outcome, something like what "%pfw" prints against a certain fwnode.
> + pdev->dev.parent, bl,
> + &lm3533_bl_ops, &props);
...
Also I feel that this change may be split to a few separate logical changes.
--
With Best Regards,
Andy Shevchenko
1 - 100 of 1130 matches
Mail list logo
