byte per pixel for the whole frame buffer, while it only needs to hold
> one bit per pixel for the part that is to be updated.
> Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already
> calculated it anyway.
Can we use bitmap API? bitmap_zalloc() / etc ?
--
With Best Regards,
Andy Shevchenko
te |= BIT(i);
> > }
> > *dst++ = byte;
> > }
--
With Best Regards,
Andy Shevchenko
on a text console with a font
> that is 8 pixels wide.
>
> Drop the confusing comment about scanlines, as a pitch in bytes always
> contains a multiple of 8 pixels.
>
> While at it, use the drm_rect_height() helper instead of open-coding the
> same operation.
>
> Update the
ng.
W/ or w/o the below remark being addressed
Reviewed-by: Andy Shevchenko
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/drm_format_helper.c | 32 ++-
On Tue, Mar 08, 2022 at 11:46:32AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 08, 2022 at 12:18:25PM +0200, Andy Shevchenko wrote:
> > +Cc: Helge
> >
> > Maybe you can pick this up?
> >
> > On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
&g
+Cc: Helge
Maybe you can pick this up?
On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
> In the fbtft_init_display() the init sequence is printed for
> the debug purposes. Unfortunately the current code doesn't take
> into account that values in the buffer are o
ging/fbtft: Remove all strcpy() uses")
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fbtft-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 4a35347b3020..b28a059ad3
On Tue, Feb 15, 2022 at 07:14:49PM +0200, Jani Nikula wrote:
> On Tue, 15 Feb 2022, Andy Shevchenko
> wrote:
> > It's hard to parse for-loop which has some magic calculations inside.
> > Much cleaner to use while-loop directly.
>
> I assume you're trying to
It's hard to parse for-loop which has some magic calculations inside.
Much cleaner to use while-loop directly.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/selftests/i915_syncmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm
On Mon, Feb 14, 2022 at 01:12:48PM +0100, Thomas Zimmermann wrote:
> Am 14.02.22 um 11:38 schrieb Andy Shevchenko:
> > On Mon, Feb 14, 2022 at 10:03:53AM +0100, Thomas Zimmermann wrote:
> > > Am 11.02.22 um 16:41 schrieb Andy Shevchenko:
...
> > > > > IMO *always
On Mon, Feb 14, 2022 at 10:03:53AM +0100, Thomas Zimmermann wrote:
> Am 11.02.22 um 16:41 schrieb Andy Shevchenko:
...
> > > IMO *always* prefer a for loop over while or do-while.
> > >
> > > The for (i = 0; i < N; i++) is such a strong paradigm in C. You
&g
On Mon, Feb 14, 2022 at 11:17:11AM +0200, Pekka Paalanen wrote:
> On Fri, 11 Feb 2022 19:27:12 +0200
> Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 06:25:17PM +0200, Jani Nikula wrote:
> > > On Fri, 11 Feb 2022, Andy Shevchenko
> > > wrote:
> > &g
--
With Best Regards,
Andy Shevchenko
all your fbtft patches to fbdev maintainer as well.
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 11, 2022 at 06:25:17PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Andy Shevchenko
> wrote:
> > On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
> >> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> >> > Am 11.02.22 um 12:12 schrie
be(dev, PTR_ERR(ssd130x),
> + "Failed to allocate DRM device\n");
> + return ssd130x;
This...
> + }
...
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> + &ssd130xfb_bl_ops, NULL);
> + if (IS_ERR(bl))
> + return ERR_PTR(dev_err_probe(dev, PTR_ERR(bl),
> + "Unable to register backlight
> device\n"));
Can be consistent with this then.
--
With Best Regards,
Andy Shevchenko
nditionals from the loop), but since it's almost a direct copy
of the existing code let's improve it later on.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
> ---
>
> Changes in v5:
> - Use drm_WARN_ON*
critical, so
Reviewed-by: Andy Shevchenko
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
> ---
>
> Changes in v5:
> - Add Thomas Zimmermann's Reviewed-by to patch #1.
>
> Changes in v3:
> - Add a drm_fb_x
On Fri, Feb 11, 2022 at 12:50:04PM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 12:10, Andy Shevchenko wrote:
...
> >> + for (xb = 0; xb < pixels; xb++) {
> >> + unsigned int start = 0, end = 8;
> >> + u8 byte = 0x00;
> >
>
On Fri, Feb 11, 2022 at 01:05:57PM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 12:33, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
...
> >> + * Helper to write command (SSD130X_COMMAND). The fist variadic argume
On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> > Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
> >> On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> >>> On 2/11/22 11:28, An
intainer of the binding, to make sure that I will
> be on Cc when patches are proposed for it.
Reviewed-by: Andy Shevchenko
> Suggested-by: Sam Ravnborg
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Rob Herring
> ---
>
> Changes in v4:
> - Add Rob Herring Acked-
nce the new DRM driver was made compatible with the existing binding.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Sam Ravnborg
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Adapt MAINTAINERS entry to point to the n
lt; k;
> + }
> + data_array[array_idx++] = data;
> + }
> + }
...
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> + &ssd130xfb_bl_ops, NULL);
> + if (IS_ERR(bl)) {
> + ret = PTR_ERR(bl);
> + dev_err_probe(dev, ret, "Unable to register backlight
> device\n");
> + return ERR_PTR(ret);
dev_err_probe(dev, PTR_ERR(bl), "Unable to register backlight
device\n");
return bl;
?
> + }
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 11, 2022 at 10:19:25AM +0100, Javier Martinez Canillas wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over I2C.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier
On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 11:28, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
...
> >> +static void drm_fb_xrgb_to_gray8_line(u8 *dst, const u32 *src,
art and end pixels that
> + * are not aligned to multiple of 8.
> + *
> + * Calculate if the start and end pixels are not aligned and set the
> + * offsets for the reversed mono line conversion function to adjust.
> + */
> + start_offset = clip->x1 % 8;
> + end_len = clip->x2 % 8;
ALIGN() ?
--
With Best Regards,
Andy Shevchenko
8 b = *src & 0x00ff;
> +
> + /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
> + *dst++ = (3 * r + 6 * g + b) / 10;
> + src++;
> + }
Can be done as
while (pixels--) {
...
}
or
do {
= 100.%
>
> With unsorted page lists:
>
> BENCHMARKs: VC: 31.005s VO: 42.889s A: 0.000s Sys: 2.256s = 76.150s
> BENCHMARK%: VC: 40.7156% VO: 56.3219% A: 0.% Sys: 2.9625% = 100.%
>
> VC shows the overhead of video decoding, VO shows the overhead of the
On Wed, Feb 09, 2022 at 05:26:00PM +0100, Javier Martinez Canillas wrote:
> On 2/9/22 17:08, Andy Shevchenko wrote:
...
> On that topic, I even typed a SPI driver because of your feedback :)
Much appreciated, makes me much easier to test.
Thank you for doing all this!
--
With Best R
are different buses, can't clash).
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 09, 2022 at 05:07:03PM +0100, Javier Martinez Canillas wrote:
> On 2/9/22 16:17, Andy Shevchenko wrote:
> > On Wed, Feb 09, 2022 at 01:25:46PM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Feb 9, 2022 at 10:12 AM Javier Martinez Ca
On Wed, Feb 09, 2022 at 04:54:01PM +0100, Javier Martinez Canillas wrote:
> On 2/9/22 16:12, Andy Shevchenko wrote:
> > On Wed, Feb 09, 2022 at 10:03:10AM +0100, Javier Martinez Canillas wrote:
...
> >> + do {
> >> + value = va_arg(ap, int);
> >> +
t resurrection discussion I can send a new version
to unorphan it, route via fbdev, and leave under staging, so it will be a
compromise between all stakeholders.
--
With Best Regards,
Andy Shevchenko
if nobody keep an eye each rc cycle. It might take time to return it in shape
first.
*) Speaking out of my own experience with device(s) that I possess.
--
With Best Regards,
Andy Shevchenko
be a good time to deprecate the existing
> "solomon,ssd130*fb-i2c" compatible values, and switch to
> "solomon,ssd130*fb" instead, for both I2C and SPI.
Agree!
> Of course the I2C subdriver still has to bind against the old values,
> too, for backwards compatibility.
--
With Best Regards,
Andy Shevchenko
h Best Regards,
Andy Shevchenko
illas
s?!
...
> +#include
> +#include
regmap.h ?
err.h?
...
> + ssd130x = ssd130x_probe(&client->dev, regmap);
> +
Redundant blank line.
> + if (IS_ERR(ssd130x))
> + return PTR_ERR(ssd130x);
...
> + { /* sentinel */ },
No comma for terminator
ed to allocate DRM device: %d\n", ret);
> + return ssd130x;
return dev_err_probe() ?
> + }
...
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> + &ssd130xfb_bl_ops, NULL);
> + if (IS_ERR(bl)) {
> + ret = PTR_ERR(bl);
> + dev_err(dev, "Unable to register backlight device: %d\n", ret);
> + return ERR_PTR(ret);
Ditto.
> + }
...
> + ret = drm_dev_register(drm, 0);
> + if (ret) {
> + dev_err(dev, "DRM device register failed: %d\n", ret);
> + return ERR_PTR(ret);
Ditto.
> + }
...
I have feelings that half of my comments were ignored...
Maybe I missed the discussion(s).
--
With Best Regards,
Andy Shevchenko
, Geert, for testing and reporting this issue in particular.
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 04, 2022 at 08:19:12PM +0100, Javier Martinez Canillas wrote:
> On 2/4/22 15:26, Andy Shevchenko wrote:
> > On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
...
> >> +struct ssd130x_device {
> >> + struct drm
On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote:
> On 2/4/22 14:57, Andy Shevchenko wrote:
> > On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote:
...
> > Stray change?
>
> Sigh, I'm not sure how added that change. Just i
.
...
> + if (IS_ERR(bl)) {
> + ret = PTR_ERR(bl);
> + dev_err(dev, "Unable to register backlight device: %d\n", ret);
> + return ret;
return dev_err_probe();
> + }
...
> + ret = drm_dev_register(drm, 0);
> + if (ret) {
> + dev_err(dev, "DRM device register failed: %d\n", ret);
> + return ret;
> + }
Ditto.
...
> + {},
Comma is not needed in terminator entry.
...
> +static struct i2c_driver ssd130x_i2c_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = ssd130x_of_match,
> + },
> + .probe_new = ssd130x_probe,
> + .remove = ssd130x_remove,
> + .shutdown = ssd130x_shutdown,
> +};
> +
Redundant blank line.
> +module_i2c_driver(ssd130x_i2c_driver);
--
With Best Regards,
Andy Shevchenko
nce the new DRM driver was made compatible with the existing binding.
...
> drivers/gpu/drm/drm_format_helper.c | 2 +-
Nothing about this in the commit message...
Stray change?
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 02, 2022 at 12:54:32PM +0100, Javier Martinez Canillas wrote:
> On 2/2/22 12:50, Andy Shevchenko wrote:
> >> What's your suggestion then to solve the issue mentioned above ? With my
> >> distro
> >> maintainer hat I don't care that much, since
On Wed, Feb 02, 2022 at 12:39:29PM +0100, Javier Martinez Canillas wrote:
> On 2/2/22 12:06, Andy Shevchenko wrote:
> > On Wed, Feb 02, 2022 at 09:38:51AM +0100, Javier Martinez Canillas wrote:
> >> On 2/1/22 21:40, Sam Ravnborg wrote:
> > And how will distros choose &q
this case?
What to do when I wan to see a regression and I want to change drivers w/o
recompilation?
NAK from me to that proposal.
--
With Best Regards,
Andy Shevchenko
On Tue, Feb 01, 2022 at 12:45:53PM +0100, Javier Martinez Canillas wrote:
> On 2/1/22 10:44, Andy Shevchenko wrote:
> > On Tue, Feb 01, 2022 at 01:14:22AM +0100, Javier Martinez Canillas wrote:
...
> > The problem with no backward compatibility means that removal of old driver
p" of Kconfig.
Also here is the question, should we keep backward compatibility or not?
If not, we never can remove the old driver (until last user gone).
--
With Best Regards,
Andy Shevchenko
.
After all module name is not so important as compatibility strings.
The problem with no backward compatibility means that removal of old driver
makes users unhappy since DT is kinda ABI and we do not break it.
--
With Best Regards,
Andy Shevchenko
KLIGHT_CLASS_DEVICE
> > + help
> > + DRM driver for the SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
> > + OLED controllers that can be programmed via an I2C interface.
> > +
> > + If M is selected the module will be called ssd1307.
--
With Best Regards,
Andy Shevchenko
ns.
It depends if the binding is going to be preserved. Also this series doesn't
answer to the question what to do with the old driver.
If you leave it, I would expect the backward compatibility, otherwise the
series misses removal of the old driver.
--
With Best Regards,
Andy Shevchenko
sktop.org/drm/drm-misc
> +F: Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> +F: drivers/gpu/drm/tiny/ssd1307.c
I think it makes sense to add ssd1307fb as well. At least you may point out
people patching old driver about new one until it's gone completely.
--
With Best Regards,
Andy Shevchenko
On Mon, Jan 31, 2022 at 02:55:21PM +0100, Javier Martinez Canillas wrote:
> On 1/31/22 14:23, Andy Shevchenko wrote:
> > On Mon, Jan 31, 2022 at 01:08:32PM +0100, Javier Martinez Canillas wrote:
...
> > The tricky part is the PRP0001
> > ACPI PNP ID that allows to r
On Mon, Jan 31, 2022 at 03:23:13PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 31, 2022 at 01:08:32PM +0100, Javier Martinez Canillas wrote:
> > On 1/31/22 12:36, Andy Shevchenko wrote:
...
> > I actually added this dependency deliberative. It's true that the driver is
>
On Mon, Jan 31, 2022 at 01:08:32PM +0100, Javier Martinez Canillas wrote:
> On 1/31/22 12:36, Andy Shevchenko wrote:
...
> >> +config TINYDRM_SSD130X
> >> + tristate "DRM support for Solomon SSD130X OLED displays"
> >> + depends on DRM && OF &a
On Mon, Jan 31, 2022 at 09:29:33AM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 15:15, Javier Martinez Canillas wrote:
> > On 1/26/22 15:10, Andy Shevchenko wrote:
> >> On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
> >>> On Wed, Jan 26, 20
On Wed, Jan 26, 2022 at 04:02:23PM +0100, Thomas Zimmermann wrote:
> Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
> > On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
> > > Am 26.01.22 um 11:59 schrieb Helge Deller:
> > > It's always for the sam
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 14:27, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
> >> On 1/26/22 11:59, Helge Deller wrote:
> >>> On 1/26/2
On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
> > On 1/26/22 14:12, Andy Shevchenko wrote:
...
> > I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
>
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 14:12, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
> >>> O
(DRM driver in drivers/gpu/drm/tiny/ili9341.c)
They both fit.
--
With Best Regards,
Andy Shevchenko
ity gives a shit about because simply they are not in
the same boat. Try to be on the people's position...
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 12:38:09PM +0100, Helge Deller wrote:
> On 1/26/22 12:24, Daniel Vetter wrote:
> > On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas
> > wrote:
> >> On 1/26/22 11:59, Helge Deller wrote:
> >>> On 1/26/22 11:02, Andy Shevche
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 11:59, Helge Deller wrote:
> > On 1/26/22 11:02, Andy Shevchenko wrote:
>
> [snip]
>
> >> P.S. For the record, I will personally NAK any attempts to remove that
> >> driver
On Wed, Jan 26, 2022 at 12:15:48PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
> > wrote:
> > > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote
On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote:
> On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
> wrote:
> > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
> > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> > > wrote
pport is missing.
> Here's a status report I wrote 2 years ago:
>
> fbtft: 5 years in staging
> https://lore.kernel.org/dri-devel/a6cef26c-0f4b-47f0-d249-71f538915...@tronnes.org/
Thanks for sharing!
--
With Best Regards,
Andy Shevchenko
RM driver supports parallel interface for these devices.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 11:28, Dan Carpenter wrote:
> > On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
> >> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
> >> wrote:
> >>>
ere?
I have bought myself (for other purposes, I mean not to convert the driver(s))
SSD1306 based display (SPI), SSD1331 (SPI), HX88347d (parallel).
Each of them costed less than $10 with delivery to EU (nowadays maybe a bit
more expensive). I believe it's very easy to find the links on AliExpress.
--
With Best Regards,
Andy Shevchenko
existing support.
>
> This is about adding new drivers to a subsystem where consensus the
> past 6 years or so was that it's closed for new drivers.
You mean fbdev?
--
With Best Regards,
Andy Shevchenko
gain.
Fine, write a driver or accept existing solution.
While there is no other solution, let's go with the existing.
--
With Best Regards,
Andy Shevchenko
e describing a transitioning over to DRM - which is Ok.
> But on that way there is no need to ignore, deny or even kill usage scenarios
> which are different compared to your usage scenarios (e.g. embedded devices,
> old platforms, slow devices, slow busses, no 3D hardware features,
> low-color devices, ...).
Exactly, I am on the same side here.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 11:31:45AM +0100, Daniel Vetter wrote:
> On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
> wrote:
> > On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
...
> > I'm ok with the files moving if the dri developers agree with it. I
On Wed, Jan 26, 2022 at 12:54:13AM -0800, Joe Perches wrote:
> On Tue, 2022-01-25 at 22:21 +0200, Andy Shevchenko wrote:
> > Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
> > for the sake of deduplication.
> []
> > diff --git a/drivers/video
On Wed, Jan 26, 2022 at 02:43:45AM -0800, Lucas De Marchi wrote:
> On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
> > wrote:
...
> > > 411986 104906176 428652 68a6c drm.ko.old
> > >
11 +-
> drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 +-
> .../ethernet/chelsio/cxgb4/cxgb4_debugfs.c| 249 ++
> include/linux/string_helpers.h| 20 ++
> security/tomoyo/audit.c | 2 +-
> security/tomoyo/common.c | 19 +-
> security/tomoyo/common.h | 1 -
> 60 files changed, 482 insertions(+), 373 deletions(-)
>
> --
> 2.34.1
>
--
With Best Regards,
Andy Shevchenko
ge for modules, but if you compile in the
linker may try to optimize it. Would be nice to see the old-new for
`make allyesconfig` or equivalent.
...
> seq_printf(m, "\tDP branch device present: %s\n",
> - branch_device ? "yes" : "no");
> + str_yes_no(branch_device));
Can it be now on one line? Same Q for all similar cases in the entire series.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
wrote:
> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> wrote:
> > Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
...
> > But why? We already have DRM drivers for some of these devices.
>
> No, we do not (only a fe
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
> > Since we got a maintainer for fbdev, I would like to
> > unorphan fbtft (with the idea of sending PRs to Helge)
> > and move it out of staging since
The driver is in maintenance mode, i.e. no new drivers will be accepted,
and for a long time it is part of the kernel, means no need to clone any
separate sources.
Signed-off-by: Andy Shevchenko
---
drivers/video/fbtft/README | 32
drivers/video/fbtft/TODO
Let's maintain occasional fixes to the fbtft driver.
Signed-off-by: Andy Shevchenko
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..16e614606ac1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7372,9 +73
The driver is under maintenance mode, but some of the devices supported
by it are not going to be converted to (tiny) DRM in the feasible future.
In order to support them, move driver out from staging.
Signed-off-by: Andy Shevchenko
---
MAINTAINERS | 2
Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
for the sake of deduplication.
Signed-off-by: Andy Shevchenko
---
drivers/video/fbtft/Kconfig | 33 -
1 file changed, 4 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbtft/Kco
Since we got a maintainer for fbdev, I would like to
unorphan fbtft (with the idea of sending PRs to Helge)
and move it out of staging since there is no more clean
up work expected and no more drivers either.
Thoughts?
Andy Shevchenko (4):
fbtft: Unorphan the driver
fbtft: Move driver out
unction to return no value. This
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
Acked-by: Andy
E.g. yesno() to me doesn't sound too bad to misunderstand its meaning,
esp.when it's used as an argument to the printf() functions.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 19, 2022 at 04:00:17PM -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko wrote:
>
> > > I say keep it one line!
> > >
> > > Reviewed-by: Steven Rostedt (Google)
> >
> > I believe
yesno(ident1 & V3D_HUB_IDENT1_WITH_TSY));
> seq_printf(m, "MSO:%s\n",
> -(ident1 & V3D_HUB_IDENT1_WITH_MSO) ? "yes" : "no");
> +yesno(ident1 & V3D_HUB_IDENT1_WITH_MSO));
> seq_printf(m, "L3C:%s (%dkb)\n",
> -(ident1 & V3D_HUB_IDENT1_WITH_L3C) ? "yes" : "no",
> +yesno(ident1 & V3D_HUB_IDENT1_WITH_L3C),
> V3D_GET_FIELD(ident2, V3D_HUB_IDENT2_L3C_NKB));
I believe it's fine to join back to have less LOCs (yes, it will be 83 or so,
but I believe in these cases it's very much okay).
--
With Best Regards,
Andy Shevchenko
o\0\0yes" + v * 4' works a bit better.
Is it a C code obfuscation contest?
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 19, 2022 at 11:35:22AM +0900, Esaki Tomohito wrote:
> On 2022/01/18 18:53, Andy Shevchenko wrote:
> > On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
> > > On 2022/01/14 23:16, Andy Shevchenko wrote:
> > > > On Fri, Jan 14, 2022 at 07:17:52
>
> I say keep it one line!
>
> Reviewed-by: Steven Rostedt (Google)
I believe Sakari strongly follows the 80 rule, which means...
> > Reviewed-by: Sakari Ailus
...chose either of these tags and be happy with :-)
--
With Best Regards,
Andy Shevchenko
red starting with drm/ since this is "closer to home".
>
> I hope this is a good summary of the previous attempts and a way we can
> move forward.
>
> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my
> proposal is to take first 2 patches either t
inline const char *enabledisable(bool v) { return v ? "enable" :
> "disable"; }
> +static inline const char *enableddisabled(bool v) { return v ? "enabled"
> : "disabled"; }
Looks not readable even if takes 80 characters. Please, keep original style.
I believe you wanted to have nice negative statistics from day 1, then you
may add more patches in the series to cleanup more users.
>
> #endif
> --
> 2.34.1
>
>
--
With Best Regards,
Andy Shevchenko
TLOG_YES));
> +yesno(cond->grant_log ==
> TOMOYO_GRANTLOG_YES));
> tomoyo_set_lf(head);
> return true;
> }
> diff --git a/security/tomoyo/common.h b/security/tomoyo/common.h
> index 85246b9df7ca..ca285f362705 100644
> --- a/security/tomoyo/common.h
> +++ b/security/tomoyo/common.h
> @@ -959,7 +959,6 @@ char *tomoyo_read_token(struct tomoyo_acl_param
> *param);
> char *tomoyo_realpath_from_path(const struct path *path);
> char *tomoyo_realpath_nofollow(const char *pathname);
> const char *tomoyo_get_exe(void);
> -const char *tomoyo_yesno(const unsigned int value);
> const struct tomoyo_path_info *tomoyo_compare_name_union
> (const struct tomoyo_path_info *name, const struct tomoyo_name_union
> *ptr);
> const struct tomoyo_path_info *tomoyo_get_domainname
> --
> 2.34.1
>
>
--
With Best Regards,
Andy Shevchenko
On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
> On 2022/01/14 23:16, Andy Shevchenko wrote:
> > On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
> > > The LINEAR modifier is advertised as default if a driver doesn't
remove the mode_config.allow_fb_modifiers hook and always
> > advertise modifier support, unless
> > mode_config.cannot_support_modifiers is set
FWIW,
Reviewed-by: Andy Shevchenko
> [1]
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@ige
On Fri, Jan 14, 2022 at 03:42:54PM +, Simon Ser wrote:
> On Friday, January 14th, 2022 at 16:17, Andy Shevchenko
> wrote:
>
> > On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> > > On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> > >
On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> wrote:
>
> > Why not enum?
>
> There is no enum for DRM format modifiers.
I'm not sure how this prevents to use enum in the code instead of const u6
501 - 600 of 1005 matches
Mail list logo
