array(fences, i,
> + sizeof(*fences), GFP_KERNEL);
On 80 position is closing parenthesis, which, I think, makes it okay to put on
one line.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.fre
y voice here is to ignore for the same reasons: respect
realloc(3) and making common sense with the idea of REallocating
(capital letters on purpose).
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
ber(p, output + sizeof(output) - 2, *fourcc,
> +sizeof(u32));
I would go with one line here.
The (theoretical) problem is here that the case when buffer size is not enough
to print a value will be like '(0xabc)' but should be rather '
On Tue, Nov 03, 2020 at 04:56:16PM +0200, Sakari Ailus wrote:
> On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> > On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
&
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
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 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
te |= BIT(i);
> > }
> > *dst++ = byte;
> > }
--
With Best Regards,
Andy Shevchenko
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
On Tue, Mar 15, 2022 at 12:07:07PM +0100, Geert Uytterhoeven wrote:
> As the temporary buffer is no longer used to store 8-bit grayscale data,
> its size can be reduced to the size needed to store the monochrome
> bitmap data.
bitmap API?
--
With Best Regards,
Andy Shevchenko
> clk_prepare_enable() and devm_add_action()) convinces me, that introducing the
> function family is sensible. (And if you want to work on these drivers,
> grepping for devm_clk_get_enabled gives you a few candidates once the
> series is in :-)
FWIW,
Reviewed-by: Andy Shevchenko
for d
On Mon, Mar 14, 2022 at 06:28:41PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
...
> Any reason you didn't test build this?
My test build doesn't include the WERROR for this driver, so I missed the
warning. Sorry for
It's obvious that we don't and shouldn't modify buffer that
is about to be dumped. Constify parameter in fbtft_dbg_hex()
to make it clear.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Andy Shevchenko
---
v2: new patch to fix a warning (Greg)
dr
ging/fbtft: Remove all strcpy() uses")
Signed-off-by: Andy Shevchenko
---
v2: no changes, just based on prerequisite
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/fbt
ally work? I tried and no one replied to request.
Keeping silent is a bad service. If people don't want a person
to have such access it should be well communicated.
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 18, 2022 at 03:21:45PM +0100, Maxime Ripard wrote:
> On Fri, Mar 18, 2022 at 03:42:48PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 17, 2022 at 12:39:57PM +0100, Javier Martinez Canillas wrote:
> > > On 3/17/22 09:18, Geert Uytterhoeven wrote:
> >
>
uffer, addr, n);
...
> +int iio_dma_buffer_write(struct iio_buffer *buffer, size_t n,
> +const char __user *user_buffer)
> +{
> + return iio_dma_buffer_io(buffer, n, (__force char *)user_buffer,
> true);
Why do you drop address space markers?
> +}
--
With Best Regards,
Andy Shevchenko
ilable right now?
...
> + * @bytes_used:number of bytes used in this DMABUF for the data
> transfer.
> + * If zero, the full buffer is used.
Wouldn't be error prone to have 0 defined like this?
--
With Best Regards,
Andy Shevchenko
gt;> + kfree(dba);
> >> + return ERR_PTR(ret);
> >> + }
Missed DMA mapping error check.
> >> +
> >> + return &dba->sg_table;
> >> +}
...
> >> - /* Must not be accessed outside the core. */
> >> - struct kref kref;
> >> + struct dma_buf *dmabuf;
Is it okay to access outside the core? If no, why did you remove
(actually not modify) the comment?
--
With Best Regards,
Andy Shevchenko
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
+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
(Rockchip
> RK3326) and it appears to work well. However, this change will affect
> all Rockchip SoCs that use this driver so I believe further testing
> is warranted. Please note that without this change I can confirm
> at least all PX30s with DSI panels will stop working with the 5.15
it return void instead which makes it easier to see in the callers
> that there is no error to handle.
>
> Also the return value of platform and spi remove callbacks is ignored
> anyway and not freeing resources in .remove() is a bad idea.
Acked-by: Andy Shevchenko
> S
rivers that
> rely on FB_DDC to have an appropriate I2C dependency as well.
No objections from me.
Acked-by: Andy Shevchenko
> Signed-off-by: Arnd Bergmann
> ---
> drivers/video/fbdev/Kconfig | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> d
c/mei/hdcp/mei_hdcp.c | 22 +-
> drivers/power/supply/ab8500_charger.c | 22 +-
> drivers/video/fbdev/omap2/omapfb/dss/dss.c| 20 +-
> include/drm/drm_of.h | 9 +-
> include/linux/component.h | 92 ++-
> sound/hda/hdac_component.c| 21 +-
> sound/soc/codecs/wcd938x.c| 20 +-
> 33 files changed, 780 insertions(+), 488 deletions(-)
>
>
> base-commit: e4e737bb5c170df6135a127739a9e6148ee3da82
> --
> https://chromeos.dev
>
>
--
With Best Regards,
Andy Shevchenko
MOD_INVALID
+ Comma?
> + };
Why not enum?
--
With Best Regards,
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
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
> > >
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 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
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
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
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
>
> 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
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
o\0\0yes" + v * 4' works a bit better.
Is it a C code obfuscation contest?
--
With Best Regards,
Andy Shevchenko
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
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
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
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
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
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
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
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 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
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
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
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
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
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
> > >
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 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
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
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
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
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
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:
> >>>
RM driver supports parallel interface for these devices.
--
With Best Regards,
Andy Shevchenko
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
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
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 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: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
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
(DRM driver in drivers/gpu/drm/tiny/ili9341.c)
They both fit.
--
With Best Regards,
Andy Shevchenko
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
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: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: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 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 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 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 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
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
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
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
.
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
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
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
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 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
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
When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.
Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: Andy Shevchenko
---
include/drm/drm_gem_ttm_helper.h | 2 +-
include/drm
When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.
Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: Andy Shevchenko
---
include/drm/intel-gtt.h | 5 -
1 file changed, 4
On Wed, Nov 10, 2021 at 3:55 PM Thomas Zimmermann wrote:
> Am 10.11.21 um 11:24 schrieb Andy Shevchenko:
> > When kernel.h is used in the headers it adds a lot into dependency hell,
> > especially when there are circular dependencies are involved.
> >
> > Replace kerne
On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helper
On Wed, Nov 10, 2021 at 05:39:33PM +0100, Thomas Zimmermann wrote:
> Am 10.11.21 um 17:34 schrieb Andy Shevchenko:
> > On Wed, Nov 10, 2021 at 3:55 PM Thomas Zimmermann
> > wrote:
> > > Am 10.11.21 um 11:24 schrieb Andy Shevchenko:
...
> > > > +#include
On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko
> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >>
On Mon, Nov 15, 2021 at 01:53:10PM +0200, Jani Nikula wrote:
> Took Andy's patch [1] and expanded on it a bit.
Thank you!
It's always good to have cleanups in the headers,
Acked-by: Andy Shevchenko
for your changes (including ones that you've done against my patch
101", .driver_data = (kernel_ulong_t)&tegra210_i2c_hw},
> + {.id = "NVDA0201", .driver_data = (kernel_ulong_t)&tegra186_i2c_hw},
> + {.id = "NVDA0301", .driver_data = (kernel_ulong_t)&tegra194_i2c_hw},
> + { },
No comma for the terminator entry.
> +};
--
With Best Regards,
Andy Shevchenko
On Mon, Nov 15, 2021 at 01:35:47PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 10, 2021 at 05:39:33PM +0100, Thomas Zimmermann wrote:
> > Am 10.11.21 um 17:34 schrieb Andy Shevchenko:
> > > On Wed, Nov 10, 2021 at 3:55 PM Thomas Zimmermann
> > > wrote:
> > >
f (ACPI_HANDLE(i2c_dev->dev))
> + return 0;
Ditto.
P.S> Sorry if I missed something in the previous reviews.
--
With Best Regards,
Andy Shevchenko
On Tue, Nov 23, 2021 at 06:32:46PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 15, 2021 at 01:35:47PM +0200, Andy Shevchenko wrote:
> > On Wed, Nov 10, 2021 at 05:39:33PM +0100, Thomas Zimmermann wrote:
> > > Am 10.11.21 um 17:34 schrieb Andy Shevchenko:
> > > > O
ctures where it might be possible to
have valid vIRQ 0, but this is not the case (at least I never heard of
a such) for GPIO controllers on such platforms. So, looking at the
above code I may tell that the '=' part is redundant.
--
With Best Regards,
Andy Shevchenko
On Thu, Dec 9, 2021 at 3:48 PM Akhil R wrote:
>
> Use i2c_timings struct and corresponding methods to get bus clock frequency
Thanks!
A couple of comments below, after addressing them, FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Akhil R
> ---
> drivers/i2c/busses/i
n plural form, the singular is a legacy one)
> + It will be used only if optional smbus-alert property is present.
--
With Best Regards,
Andy Shevchenko
dif
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
;line,
> + line + irq_first,
>num_interrupts[line],
> num_wake_interrupts[line]);
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sat, Dec 12, 2020 at 12:07 AM Thomas Gleixner wrote:
>
> On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
>
> > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
> >
> >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner
> >> wrote:
> >
acpi_dev_get_resources() does perform the NULL pointer check against
ACPI companion device which is given as function parameter. Thus,
there is no need to duplicate this check in the caller.
Signed-off-by: Andy Shevchenko
---
v2: used LIST_HEAD() (Ville), initialized lookup directly on stack
101 - 200 of 1134 matches
Mail list logo
