On Tue, Jun 11, 2024 at 06:46:12AM -0700, Jeff Johnson wrote:
> On 4/25/24 05:56, Andy Shevchenko wrote:
...
> I'll remove this from my series
No need, Maxime already applied, and I see
665415092eca ("drm: add missing MODULE_DESCRIPTION() macros")
> Reviewed-by: Jeff J
On Wed, Jun 05, 2024 at 11:38:31PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 25, 2024 at 03:56:26PM +0300, Andy Shevchenko wrote:
> > The modpost script is not happy
> >
> > WARNING: modpost: missing MODULE_DESCRIPTION() in
> > drivers/gpu/drm/drm_
a/v4l/vidioc-g-selection.rst
> > [1]
> > Signed-off-by: Devarsh Thakkar
>
> Acked-by: Sebastian Fricke
>
> Can, whoever picks up the math changes, pick up this change as well?
> I will send 1-6 via the media subsystem.
math.h is orphaned, meaning any Tier-1 maintainer may push this through.
So, there is nobody behind it.
--
With Best Regards,
Andy Shevchenko
On Thu, Apr 25, 2024 at 03:56:26PM +0300, Andy Shevchenko wrote:
> The modpost script is not happy
>
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/drm_mipi_dbi.o
>
> because there is a missing module description.
>
> Add it to t
Make two APIs look similar. Hence convert match_string() to be
a 2-argument macro. In order to avoid unneeded churn, convert
all users as well. There is no functional change intended.
Signed-off-by: Andy Shevchenko
---
Compile tested with `make allyesconfig` and `make allmodconfig`
on x86_64
On Sun, Jun 02, 2024 at 05:21:03PM +0300, Andy Shevchenko wrote:
> Compilation fails on arm with:
>
> link_factory.c:743:1: error: the frame size of 1032 bytes is larger than
> 1024 bytes [-Werror=frame-larger-than=]
>
> Fix the frame size by allocation one of the big struc
Compilation fails on arm with:
link_factory.c:743:1: error: the frame size of 1032 bytes is larger than 1024
bytes [-Werror=frame-larger-than=]
Fix the frame size by allocation one of the big structures.
Signed-off-by: Andy Shevchenko
---
.../gpu/drm/amd/display/dc/link/link_factory.c
On Sat, Jun 01, 2024 at 02:05:08PM +0100, Jonathan Cameron wrote:
> On Fri, 31 May 2024 19:56:14 +0300
> Andy Shevchenko wrote:
>
> > The driver has no in kernel users and requires a board file
> > to be instantiated. Remove basically a dead code.
> >
On Fri, May 31, 2024 at 02:31:45PM -0700, Chia-I Wu wrote:
> On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko <
> andriy.shevche...@linux.intel.com> wrote:
> > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote:
...
> > P.S> I'm not so sure about this change. It
ub.com/devarsht/3f9042825be3da4e133b8f4eda067876
Make it a tag...
>
...here
Link: ... [1]
> Signed-off-by: Devarsh Thakkar
With the same caveat as per patch 1,
Acked-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
* round_closest_down(14, 4) = 12
> * roundclosest(21, 5) = 20
> * roundclosest(19, 5) = 20
> * roundclosest(17, 5) = 15
I don't know the estimation on how these will really useful or not, but I'm not
objecting if people think it's needed API.
Acked-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
On Fri, May 31, 2024 at 10:42:20PM +0530, Devarsh Thakkar wrote:
> Add documentation for rounding, scaling, absolute value and difference,
> 32-bit division related macros and functions exported by math.h header
> file.
As long as it renders correctly, fine to me
Reviewed-by: Andy S
adding new test cases to cover edge cases should be
> easy
> * looking at code coverage, we hit all the branches in the .c files
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
On Fri, May 31, 2024 at 06:15:46PM +0100, Lee Jones wrote:
> On Fri, 31 May 2024, Andy Shevchenko wrote:
> > On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> > > Driver is quite outdated from the Linux kernel internal APIs
> > > perspective. In pa
+Cc: Johan (via kernel.org)
On Fri, May 31, 2024 at 08:14:43PM +0300, Andy Shevchenko wrote:
> On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> > Driver is quite outdated from the Linux kernel internal APIs
> > perspective. In particular GPIO code is usi
On Fri, May 31, 2024 at 06:14:25PM +0100, Lee Jones wrote:
> Making sure Johan is aware of this with his new address.
Right, in any case this is not the final version (a couple of leftovers).
I have mentioned this series in the original thread.
--
With Best Regards,
Andy Shevchenko
On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> Driver is quite outdated from the Linux kernel internal APIs
> perspective. In particular GPIO code is using legacy calls,
> that started being replaced by a new API ca. 2014, i.e. ten
> years ago.
>
> Suggested
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/leds/Kconfig | 13 -
drivers/leds
Driver is quite outdated from the Linux kernel internal APIs
perspective. In particular GPIO code is using legacy calls,
that started being replaced by a new API ca. 2014, i.e. ten
years ago.
Suggested-by: Linus Walleij
Andy Shevchenko (4):
backlight: lm3533_bl: Remove the driver
iio: light
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/video/backlight/Kconfig | 11
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/iio/light/Kconfig | 17 -
drivers/iio
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/lm3533-core.c | 645
ata from cpu memory into amdgpu
> bo, the throughput goes from 5.1GB/s to 6.6GB/s. perf report says
Also in the $Subj (and pay attention to the prefix)
"resource: ... find_next_iomem_res()"
--
With Best Regards,
Andy Shevchenko
way they
needs to be added / expanded).
P.S> I'm not so sure about this change. It needs a thoroughly testing, esp.
in PCI case. Cc'ing to Ilpo.
--
With Best Regards,
Andy Shevchenko
date the inclusion bloc in accordance with IWYU principle.
I see a few headers are missing.
--
With Best Regards,
Andy Shevchenko
on functions
> +--
> +
> +.. kernel-doc:: include/linux/math.h
> + :internal:
Please, double check that this is correct keyword in this case.
Otherwise LGTM.
--
With Best Regards,
Andy Shevchenko
+ *
> + * round_closest_down(15, 4) = 16
> + *
> + * round_closest_down(14, 4) = 12
As per above
...
> + * Examples :
> + *
> + * roundclosest(21, 5) = 20
> + *
> + * roundclosest(19, 5) = 20
> + *
> + * roundclosest(17, 5) = 15
As per above.
--
With Best Regards,
Andy Shevchenko
On Tue, May 28, 2024 at 05:01:31PM +0530, Devarsh Thakkar wrote:
> On 28/05/24 02:08, Andy Shevchenko wrote:
> > On Mon, May 27, 2024 at 11:37:20PM +0300, Andy Shevchenko wrote:
> >> On Sun, May 26, 2024 at 11:39:33PM +0530, Devarsh Thakkar wrote:
...
> >
On Tue, May 28, 2024 at 04:51:46PM +0530, Devarsh Thakkar wrote:
> On 28/05/24 02:07, Andy Shevchenko wrote:
[..]
> >> +#include
> >> +#include
> >> +#include
> >
> > + math.h (where abs()/DIV_ROUND_*()/etc come from?)
> > I believe I mentioned
On Tue, May 28, 2024 at 04:02:30PM +0530, Devarsh Thakkar wrote:
> On 28/05/24 02:02, Andy Shevchenko wrote:
> > On Sun, May 26, 2024 at 11:38:56PM +0530, Devarsh Thakkar wrote:
...
> >> +/**
> >> + * round_closest_up - round closest to be multiple of s
gt;dev, "fck");
devm_ approach can help a lot in case of platform device code.
> + if (IS_ERR(tmu->clk)) {
> + dev_err(>pdev->dev, "cannot get clock\n");
> + return PTR_ERR(tmu->clk);
return dev_err_probe() ?
> + }
--
With Best Regards,
Andy Shevchenko
On Mon, May 27, 2024 at 11:37:20PM +0300, Andy Shevchenko wrote:
> On Sun, May 26, 2024 at 11:39:33PM +0530, Devarsh Thakkar wrote:
...
> > +MODULE_LICENSE("GPL");
>
> modpost validator won't be happy about this, i.e. missing
> MODULE_DESCRIPTION().
And obviously
+MODULE_LICENSE("GPL");
modpost validator won't be happy about this, i.e. missing MODULE_DESCRIPTION().
--
With Best Regards,
Andy Shevchenko
7, 4) = 16
> + * round_closest_up(15, 4) = 16
> + * round_closest_up(14, 4) = 16
Btw, is kernel-doc validator happy about all kernel docs you added?
> + */
--
With Best Regards,
Andy Shevchenko
ing to have a new function per byte in question, or do we
come up with a common denominator, like mem_is_all_of(mem, byte)?
--
With Best Regards,
Andy Shevchenko
([0], , sizeof(u64));
> memcpy([8], , sizeof(u64));
What is the type of guid? Shouldn't it be guid_t with the respective
guid_is_null()
...
> - if (memchr_inv(guid, 0, 16))
> + if (!mem_is_zero(guid, 16))
> return true;
Ditto.
--
With Best Regards,
Andy Shevchenko
On Mon, May 20, 2024 at 07:51:24PM +0530, Devarsh Thakkar wrote:
> On 20/05/24 17:52, Andy Shevchenko wrote:
> > On Mon, May 20, 2024 at 05:11:18PM +0530, Devarsh Thakkar wrote:
> >> On 18/05/24 01:44, Andy Shevchenko wrote:
> >>> On Fri, May 17, 2024 at 11:06:07P
On Mon, May 20, 2024 at 05:11:18PM +0530, Devarsh Thakkar wrote:
> On 18/05/24 01:44, Andy Shevchenko wrote:
> > On Fri, May 17, 2024 at 11:06:07PM +0530, Devarsh Thakkar wrote:
[..]
> >> +#include
> >> +#include
> >
> >> +#include
> &
On Fri, May 17, 2024 at 01:53:47PM -0700, Daniel Latypov wrote:
> On Fri, May 17, 2024 at 1:14 PM Andy Shevchenko
> wrote:
...
> > > [devarsht: Rebase to 6.9 and change license to GPL]
> >
> > I'm not sure that you may change license. It needs the author's
>
viously
+ module.h
> +#include
+ types.h
...
Other than above, LGTM.
--
With Best Regards,
Andy Shevchenko
On Mon, May 13, 2024 at 06:34:19PM +0530, Devarsh Thakkar wrote:
> On 13/05/24 17:55, Andy Shevchenko wrote:
> > On Mon, May 13, 2024 at 04:55:58PM +0530, Devarsh Thakkar wrote:
> >> On 13/05/24 14:29, Andy Shevchenko wrote:
> >>> On Sat, May 11, 2024 at 11:11:14P
On Mon, May 13, 2024 at 04:55:58PM +0530, Devarsh Thakkar wrote:
> On 13/05/24 14:29, Andy Shevchenko wrote:
> > On Sat, May 11, 2024 at 11:11:14PM +0530, Devarsh Thakkar wrote:
> >> On 10/05/24 20:45, Jani Nikula wrote:
[...]
> >>> Moreover, I think the namin
ar
why you can't use one of them in your case.
The patch that changes those to a new one are doubtful to begin with.
I.e. need a careful review on the arithmetics side of the change
including HW capabilities of handling "closest" results.
--
With Best Regards,
Andy Shevchenko
On Sun, May 12, 2024 at 07:46:58AM +0300, Alexey Dobriyan wrote:
> I think
>
> roundup(x, 1 << n)
Since it's about power-of-two, round_up() is better.
> is more readable.
--
With Best Regards,
Andy Shevchenko
On Fri, May 10, 2024 at 06:16:42PM +0300, Laurent Pinchart wrote:
> On Fri, May 10, 2024 at 06:03:52PM +0300, Andy Shevchenko wrote:
> > On Fri, May 10, 2024 at 12:10:10AM +0530, Devarsh Thakkar wrote:
> > > Use generic macro round_closest_up for rounding to nearest multi
On Fri, May 10, 2024 at 06:15:34PM +0300, Jani Nikula wrote:
> On Fri, 10 May 2024, Andy Shevchenko
> wrote:
> > On Fri, May 10, 2024 at 12:09:52AM +0530, Devarsh Thakkar wrote:
> >> Add macros to round to nearest specified power of 2.
> >
> > This is not what
is to go smaller than bigger.
--
With Best Regards,
Andy Shevchenko
v4l2-jpeg.c as suggested in mailing list [1].
> - Add macros to round to closest integer (either higher or lower) while
>rounding in order of 2.
Nice, now it's chained!
But all my comments to the previous mails are still applicable here.
--
With Best Regards,
Andy Shevchenko
f 8192 is?
--
With Best Regards,
Andy Shevchenko
aragraph should go to the comment/changelog area below.
> Signed-off-by: Devarsh Thakkar
> ---
> V1->V6 (No change, patch introduced in V7)
> ---
--
With Best Regards,
Andy Shevchenko
On Fri, May 03, 2024 at 12:57:33PM +0800, Sui Jingfeng wrote:
> On 2024/5/3 01:28, Andy Shevchenko wrote:
> > On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
> > > On 2024/5/2 16:32, Andy Shevchenko wrote:
> > > > On Wed, May 01, 2024 at 12:27:
> > > > > On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
> > > > > > On 2024/4/26 14:23, Maxime Ripard wrote:
> > > > > > > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> > > > > > > >
On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
> On 2024/5/2 16:32, Andy Shevchenko wrote:
> > On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/30 22:13, Andy Shevchenko wrote:
> > > > On Fri, Apr 26, 2024 at 05:13:
On Thu, May 02, 2024 at 09:43:42AM +0200, Neil Armstrong wrote:
> Hi,
>
> On Thu, 25 Apr 2024 17:26:16 +0300, Andy Shevchenko wrote:
> > A few obvious fixes to the driver.
> >
> > Andy Shevchenko (3):
> > drm/panel: ili9341: Correct use of device property APIs
On Thu, May 02, 2024 at 09:34:17AM +0200, Neil Armstrong wrote:
> On 30/04/2024 11:34, Maxime Ripard wrote:
...
> Anyway since the rant is finished I'll land the patches.
Thank you all for the review and discussion!
--
With Best Regards,
Andy Shevchenko
On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> On 2024/4/30 22:13, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
...
> > the former might be subdivided to "is it swnode backed or real fwnode one?"
> >
&g
On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:10, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > It seems driver missed the point of
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:12, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 02:08, Sui Jingfeng wrote:
...
> > Are you speaking to yourself? I'm total
On Mon, Apr 29, 2024 at 01:39:06PM +0200, Maxime Ripard wrote:
> On Thu, Apr 25, 2024 at 06:04:50PM +0300, Andy Shevchenko wrote:
> > On Thu, Apr 25, 2024 at 04:58:06PM +0200, Maxime Ripard wrote:
> > > On Thu, Apr 25, 2024 at 03:42:07PM +0300, Andy Shevchenko wrote:
&g
ess it.
--
With Best Regards,
Andy Shevchenko
On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> On 2024/4/25 22:26, Andy Shevchenko wrote:
> > It seems driver missed the point of proper use of device property APIs.
> > Correct this by updating headers and calls respectively.
>
> You are using the 'seems
On Mon, Apr 22, 2024 at 09:49:04PM +0300, Jani Nikula wrote:
> On Mon, 22 Apr 2024, Andy Shevchenko
> wrote:
> > Update header inclusions to follow IWYU (Include What You Use)
> > principle.
> >
> > Signed-off-by: Andy Shevchenko
>
> Assuming it builds, and
On Thu, Apr 25, 2024 at 05:26:16PM +0300, Andy Shevchenko wrote:
> A few obvious fixes to the driver.
Note, despite the desire of removal Adafruit support from this driver,
the older (read: stable) kernels will need this.
--
With Best Regards,
Andy Shevchenko
On Thu, Apr 25, 2024 at 04:58:06PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, Apr 25, 2024 at 03:42:07PM +0300, Andy Shevchenko wrote:
> > First of all, the driver was introduced when it was already
> > two drivers available for Ilitek 9341 panels.
> >
> >
spamming the logs.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drive
to make it clear what's going
on there.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/pa
A few obvious fixes to the driver.
Andy Shevchenko (3):
drm/panel: ili9341: Correct use of device property APIs
drm/panel: ili9341: Respect deferred probe
drm/panel: ili9341: Use predefined error codes
drivers/gpu/drm/panel/Kconfig| 2 +-
drivers/gpu/drm/panel/panel
It seems driver missed the point of proper use of device property APIs.
Correct this by updating headers and calls respectively.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/panel/Kconfig| 2 +-
d
On Thu, Apr 25, 2024 at 09:42:53PM +0800, Sui Jingfeng wrote:
> On 2024/4/25 00:44, Andy Shevchenko wrote:
> > On Wed, Apr 24, 2024 at 07:34:54PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, Apr 24, 2024 at 05:52:03PM +0300, Andy Shevchenko wrote:
> > > > On Wed, Ap
The modpost script is not happy
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/drm_mipi_dbi.o
because there is a missing module description.
Add it to the module.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/drm_mipi_dbi.c | 1 +
1 file changed, 1 insertion
and make
maintenance and support eaiser for everybody.
Also see discussion [1] for details about Ilitek 9341 duplication
code.
Link: https://lore.kernel.org/r/zxm9pg-53v4s8...@smile.fi.intel.com [1]
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/Kconfig | 13 --
drivers/gpu/drm/tiny
On Wed, Apr 24, 2024 at 07:34:54PM +0300, Dmitry Baryshkov wrote:
> On Wed, Apr 24, 2024 at 05:52:03PM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 24, 2024 at 04:34:39PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, 24 Apr 2024 at 16:11, Andy Shevchenko
> > > wrote:
&
On Wed, Apr 24, 2024 at 04:34:39PM +0300, Dmitry Baryshkov wrote:
> On Wed, 24 Apr 2024 at 16:11, Andy Shevchenko
> wrote:
> >
> > On Wed, Apr 24, 2024 at 12:37:16AM +0300, Dmitry Baryshkov wrote:
> > > On Wed, Apr 24, 2024 at 12:49:18AM +0800, Sui Jingfeng wrote:
>
On Wed, Apr 24, 2024 at 12:37:16AM +0300, Dmitry Baryshkov wrote:
> On Wed, Apr 24, 2024 at 12:49:18AM +0800, Sui Jingfeng wrote:
> > On 2024/4/23 21:28, Andy Shevchenko wrote:
> > > On Tue, Apr 23, 2024 at 12:46:58AM +0800, Sui Jingfeng wrote:
...
> But let me throw an ar
Update header inclusions to follow IWYU (Include What You Use)
principle.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fb_seps525.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fb_seps525.c
b/drivers/staging/fbtft/fb_seps525.c
ndependent")
How is it a fix?
> Closes: https://lore.kernel.org/lkml/20230223203713.hcse3mkbq3m6sogb@skbuf/
Yes, and then Reported-by, which is missing here.
> Cc: Andy Shevchenko
> Cc: Daniel Scally
> Cc: Heikki Krogerus
> Cc: Sakari Ailus
> Cc: Greg Kroah-Hartman
> Cc: &
Update header inclusions to follow IWYU (Include What You Use)
principle.
Signed-off-by: Andy Shevchenko
---
include/drm/drm_fixed.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 81572d32db0c..387fb81d5b81 100644
not any comples RGB or so devices. If
those devices are capable of representing characters/digits in similar
way, we may export linedisp library for them to utilise.
--
With Best Regards,
Andy Shevchenko
fbtft_framebuffer_release(info);
> return -EINVAL;
ret = dev_err_probe(dev, -EINVAL, "buswidth is not set\n");
goto out_release;
> }
--
With Best Regards,
Andy Shevchenko
On Sat, Mar 23, 2024 at 02:30:08AM +0800, Sui Jingfeng wrote:
> On 2024/3/23 02:16, Andy Shevchenko wrote:
> > On Sat, Mar 23, 2024 at 02:12:14AM +0800, Sui Jingfeng wrote:
> > > On 2024/3/23 02:05, Andy Shevchenko wrote:
> > > >Besides that, the kernel
On Sat, Mar 23, 2024 at 02:12:14AM +0800, Sui Jingfeng wrote:
> On 2024/3/23 02:05, Andy Shevchenko wrote:
> > Besides that, the kernel project rule is "we do not add
> > the dead (unused) code".
>
> This rule is good an correct and I admit.
>
> But the
On Sat, Mar 23, 2024 at 01:43:56AM +0800, Sui Jingfeng wrote:
> On 2024/3/23 00:14, Andy Shevchenko wrote:
> > On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
> > > On 2024/3/21 04:28, Andy Shevchenko wrote:
...
> > > > > > > By
On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
> On 2024/3/21 04:28, Andy Shevchenko wrote:
...
> > > > > By replacing it with device_get_match_data() and creating a software
> > > > > graph that mimics the OF graph, e
quired, has to be addressed elsewhere.
So, formal NAK for the changes like above.
--
With Best Regards,
Andy Shevchenko
irection. Let's address the other drivers and
> drop the OF-based calls in the same series :-)
+1. BUT, please use device_set_node() instead of both lines.
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 21, 2024 at 03:22:05AM +0800, Sui Jingfeng wrote:
> On 2024/3/20 18:39, Andy Shevchenko wrote:
> > On Tue, Mar 19, 2024 at 07:42:22AM +0800, Sui Jingfeng wrote:
> > > This makes it possible to support (and/or test) a few drivers that
> > > originates
id table. Which
> is consistent with the original usage style.
Why do you need to implement the graph in the board file?
...
Have you seen this discussion?
https://lore.kernel.org/lkml/20230223203713.hcse3mkbq3m6sogb@skbuf/
--
With Best Regards,
Andy Shevchenko
sizes. However, it's still worth fixing.
Agree.
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
intel-mid.h is providing some core parts of the South Complex PM,
which are usually are not used by individual drivers. In particular,
this driver doesn't use it, so simply remove the unused header.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/gma500/oaktrail_lvds.c | 2 --
1 file changed
of_gpio.h is deprecated and subject to remove.
The driver doesn't use it directly, replace it
with what is really being used.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b
On Thu, Feb 29, 2024 at 12:21:34PM -0600, Lucas De Marchi wrote:
> On Thu, Feb 29, 2024 at 12:49:57PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 28, 2024 at 05:39:21PM -0600, Lucas De Marchi wrote:
> > > On Thu, Feb 22, 2024 at 06:49:59AM -0800, Yury Norov wrote:
...
&g
On Wed, Feb 28, 2024 at 05:39:21PM -0600, Lucas De Marchi wrote:
> On Thu, Feb 22, 2024 at 06:49:59AM -0800, Yury Norov wrote:
> > On Wed, Feb 21, 2024 at 03:59:06PM -0600, Lucas De Marchi wrote:
> > > On Wed, Feb 21, 2024 at 11:04:22PM +0200, Andy Shevchenko wrote:
> >
> + /*
> + * mutex_destroy() is an empty function if CONFIG_DEBUG_MUTEXES is
> + * disabled. No need to allocate an action in that case.
> + */
> + if (IS_ENABLED(CONFIG_DEBUG_MUTEXES))
> + return devm_add_action_or_reset(dev, devm_mutex_drop, lock);
> + else
> + return 0;
> +}
Cc: George Stark
--
With Best Regards,
Andy Shevchenko
untouched for asm case, no?
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 21, 2024 at 11:06:10PM +0200, Andy Shevchenko wrote:
> On Wed, Feb 21, 2024 at 10:37:30PM +0200, Dmitry Baryshkov wrote:
> > On Wed, 21 Feb 2024 at 22:30, Dmitry Baryshkov
> > wrote:
...
> > Excuse me, it seems a c from gitlab didn't work as expected.
>
rong. Has to be dropped. If somebody wants that, it will
be material for v6.10 cycle.
--
With Best Regards,
Andy Shevchenko
ed characters
> following instruction at operand 3 -- `bic x2,x1,(0+(((unsigned
> long)~0ULL-((unsigned long)(1)<<(0))+1)&((unsigned
> long)~0ULL>>((sizeof(unsigned long)*8)-1-(3)'
> 484arch/arm64/kernel/entry-fpsimd.S:98: Info: macro invoked from here
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 21, 2024 at 5:45 PM Thomas Zimmermann wrote:
> Am 21.02.24 um 15:34 schrieb Andy Shevchenko:
> > On Wed, Feb 21, 2024 at 10:41:28AM +0100, Thomas Zimmermann wrote:
> >> Framebuffer drivers for devices with dedicated backlight are supposed
> >> t
acklight_ops.
check_fb()
Acked-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
'?
> goto out;
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> + else if (info->bl_dev && info->bl_dev != bd)
Ditto.
> + goto out;
> +#endif
--
With Best Regards,
Andy Shevchenko
1 - 100 of 959 matches
Mail list logo
