On Thu, Mar 28, 2024 at 11:18 AM Maxime Ripard wrote:
>
> "a while ago" here being 2 hours before your message :)
Ah, I meant the original reports that Nathan mentioned in his message.
Yeah, the message itself from Nathan happened right before :)
> I've added a Closes tag for that report too.
>
On Wed, Mar 27, 2024 at 6:56 PM Miguel Ojeda wrote:
>
> Closes:
> https://lore.kernel.org/lkml/caniq72mjc5t4n25sqvysroehxxpxypz4ppznesjhenc3qap...@mail.gmail.com/
Should have a [1] at the end.
> Signed-off-by: Miguel Ojeda
> ---
> Given there is a loop going on here
On Wed, Mar 27, 2024 at 3:43 PM Miguel Ojeda
wrote:
>
> Will do -- I found another one when running the CI with the above one fixed:
>
> drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: error: variable
> 'num_relocs' set but not used [-Werror,-Wunused-but-set-variable]
>
>
BAhpc6YcX7bfR96gmmbF=j8heoy...@mail.gmail.com/
[1]
Signed-off-by: Miguel Ojeda
---
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index dd0f834d881c..506ae1f5e099 100644
--- a
the unused variable.
Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Closes:
https://lore.kernel.org/lkml/caniq72mjc5t4n25sqvysroehxxpxypz4ppznesjhenc3qap...@mail.gmail.com/
Signed-off-by: Miguel Ojeda
---
Given there is a loop going on here, it would be good to double-che
On Wed, Mar 27, 2024 at 8:59 AM Maxime Ripard wrote:
>
> It looks reasonable to me, can you send a formal patch?
Will do -- I found another one when running the CI with the above one fixed:
drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: error: variable
'num_relocs' set but not used
On Tue, Mar 26, 2024 at 8:56 PM Abhinav Kumar wrote:
>
> Alright, in that case, Miguel can you please repost this with the Fixes
> tags and in a patch form.
Done at https://lore.kernel.org/lkml/20240326212324.185832-1-oj...@kernel.org/
Thanks all!
Cheers,
Miguel
Link:
https://lore.kernel.org/lkml/20240307093727.1978126-1-colin.i.k...@gmail.com/
[3]
Signed-off-by: Miguel Ojeda
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
b/drivers/gpu/d
On Tue, Mar 26, 2024 at 7:31 PM Abhinav Kumar wrote:
>
> This should be fixed with https://patchwork.freedesktop.org/patch/581853/.
Ah, so in that case the `CRASHDUMP_READ` target should really be
constant, unlike in other cases in that file?
> We can pickup that one with a Fixes tag applied.
Hi,
In today's next, I got:
drivers/gpu/drm/qxl/qxl_cmd.c:424:6: error: variable 'count' set
but not used [-Werror,-Wunused-but-set-variable]
`count` seems to be there since commit f64122c1f6ad ("drm: add new QXL
driver. (v1.4)").
Untested diff below -- if you want a formal patch, please
Hi,
In today's next, I got:
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error: variable
'out' set but not used [-Werror,-Wunused-but-set-variable]
`out` seems to be there since commit 64d6255650d4 ("drm/msm: More
fully implement devcoredump for a7xx").
Untested diff below assuming
On Mon, Mar 25, 2024 at 3:25 PM Hans de Goede wrote:
>
> +Cc: Bentiss, Jiri
Cc'ing Andy and Geert as well who recently became the
maintainers/reviewers of auxdisplay, in case they are interested in
these threads (one of the initial solutions discussed in a past thread
a while ago was to extend
On Thu, Mar 14, 2024 at 9:09 AM Thomas Zimmermann wrote:
>
> As Sam already said, it doesn't seem to make different in practice. I'd
> mention it in the commit message and that's it. Ok?
Yeah, that is what I meant -- thanks a lot!
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Wed, Mar 13, 2024 at 6:54 PM Sam Ravnborg wrote:
>
> The driver does not set BL_CORE_SUSPENDRESUME so that part is a nop.
The driver may not set it now, but it is still not the same logic (and
unless I am missing something it would not generate the same code
either, so not sure I would say it
On Wed, Mar 13, 2024 at 6:11 PM Dan Carpenter wrote:
>
> Is there an advantage to making this const?
Not much in this case -- it is more about trying to be const-correct
where possible.
Cheers,
Miguel
Hi Thomas,
Thanks for this!
Cc'ing Andy and Geert -- the new maintainer and reviewer.
Also, a couple quick notes below since I am here...
On Wed, Mar 13, 2024 at 4:49 PM Thomas Zimmermann wrote:
>
> Replace the use of struct backlight_properties.fb_blank with a
> call to
patches uses `=`).
In any case, if that is intended:
Acked-by: Miguel Ojeda
Cheers,
Miguel
tly will allow to make the I/O
> helpers optional. This benefits systems that do not use these
> functions.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Miguel Ojeda
> Cc: Robin van der Gracht
Acked-by: Miguel Ojeda
Cheers,
Miguel
tly will allow to make the I/O
> helpers optional. This benefits systems that do not use these
> functions.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Miguel Ojeda
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Wed, Nov 15, 2023 at 11:30 AM Thomas Zimmermann wrote:
>
> The cfag12864bfb driver operates on system memory. Mark the framebuffer
> accordingly. Helpers operating on the framebuffer memory will test for
> the presence of this flag.
>
> Signed-off-by: Thomas Zimmermann
On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula wrote:
>
> One could also reasonably make the argument that controlling the
> individual keyboard key backlights should be part of the input
> subsystem. It's not a display per se. (Unless you actually have small
> displays on the keycaps, and I think
On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek wrote:
>
> So... a bit of rationale. The keyboard does not really fit into the
> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> a matrix of them.
Makes sense.
> We do see various strange displays these days -- they commonly
On Sat, Jul 22, 2023 at 2:50 AM Javier Martinez Canillas
wrote:
>
> Got it. Then that's yet another argument for adding the auxdisplay
> drivers under the same "Graphics support" menu.
Just in case it matters for Helge/you: these may also register an
input device, e.g. the ht16k33 has a matrix
On Sat, Jul 22, 2023 at 2:13 AM Javier Martinez Canillas
wrote:
>
> Oh, interesting. I wonder why that couldn't had been a fbdev driver then
> using FB_VISUAL_MONO01? I'll reword then the commit message before apply
> to the following instead:
It is :)
.type = FB_TYPE_PACKED_PIXELS,
On Sat, Jul 22, 2023 at 12:46 AM Javier Martinez Canillas
wrote:
>
> Javier Martinez Canillas writes:
>
> [adding Miguel Ojeda who was not in the Cc list]
>
> Hello Miguel, could you please ack this patch so that I can take the whole
> patch-set through the drm-mis
On Thu, Jul 13, 2023 at 3:03 PM Thomas Zimmermann wrote:
>
> Most fbdev drivers depend on framebuffer_alloc() to initialize the
> allocated memory to 0. Document this guarantee.
>
> Suggested-by: Miguel Ojeda
> Signed-off-by: Thomas Zimmermann
> Cc: Helge Deller
Thanks fo
On Tue, Jul 11, 2023 at 8:10 AM Thomas Zimmermann wrote:
>
> I'd like to take the patchset into drm-misc. It's part of a larger
> cleanup of the fbdev modules and its interfaces.
Sounds good, thanks!
Cheers,
Miguel
On Mon, Jul 10, 2023 at 5:22 PM Thomas Zimmermann wrote:
>
> I'll append a patch to the series that documents this.
>
> Sure.
Thanks!
If you are planning to take it into some other tree:
Acked-by: Miguel Ojeda
Otherwise, I can take it into the `auxdisplay` tree.
Cheers,
Miguel
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
>
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
`framebuffer_alloc()` does indeed use `kzalloc()`, but the docs do not
mention the
On Thu, Apr 6, 2023 at 5:45 PM Daniel Vetter wrote:
>
> Yeah this all looks great and very hyperlinked.
>
> I think the only nit I have is that for types with two or more type
> variables (like the rbtree) what each of them should represent in the top
> intro. I can guess it's and not the other
On Thu, Apr 6, 2023 at 4:15 PM Daniel Vetter wrote:
>
> Documentation:
>
> In drm we try to document all the interfaces that drivers use with formal
> docs. Yes there's some areas that are not great for historical reasons,
> but for new stuff and new wrappers we're really trying:
>
> - This helps
On Wed, Apr 5, 2023 at 1:23 PM Daniel Vetter wrote:
>
> Ok if this is just interim I think it's fine. Would still be good to have
> the MAINTAINERS entry though even just to cover the interim state. Least
> because I'm assuming that when things are split up you'd still want to
> keep the rust
On Wed, Apr 5, 2023 at 1:08 PM Daniel Vetter wrote:
>
> Uh all the rust helper wrappers for all the kernel in a single file does
> not sound good. Can we not split these up into each subsystem, and then
> maybe instead of sprinkling #ifdef all over a .c file Make the compilation
> of that file
On Tue, Mar 21, 2023 at 12:38 AM Rob Herring wrote:
>
> .../bindings/auxdisplay/holtek,ht16k33.yaml | 2 +-
Acked-by: Miguel Ojeda
Cheers,
Miguel
is always nice); and then he sent yesterday
v2 [1] (to mention the functional change with `BL_CORE_SUSPENDED`
[2]).
Anyway, if it goes via drm-misc, feel free to have my:
Acked-by: Miguel Ojeda
Though it would be nice to have Robin test the change.
Thanks!
[1] https://lore.kernel
On Thu, Sep 22, 2022 at 5:56 PM Kees Cook wrote:
>
> I wasn't sure if this "composite macro" was sane there, especially since
> it would be using __malloc before it was defined, etc. Would you prefer
> I move it?
Hmm... On one hand, they end up being attributes, so it could make
sense to have
On Thu, Sep 22, 2022 at 5:10 AM Kees Cook wrote:
>
> -#ifdef __alloc_size__
> -# define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
> -#else
> -# define __alloc_size(x, ...) __malloc
> -#endif
> +#define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
>
On Tue, Jun 28, 2022 at 4:08 PM Uwe Kleine-König
wrote:
>
> drivers/auxdisplay/ht16k33.c | 4 +---
> drivers/auxdisplay/lcd2s.c| 3 +--
Acked-by: Miguel Ojeda
Cheers,
Miguel
(and GNU extensions apply equally to both, I would assume).
When I wrote the "(including some C99 features)" I meant that GCC
implemented some C99 features as extensions in C90 mode, and the
kernel used some of those (e.g. the now gone VLAs).
With that changed, for `programming-langua
On Wed, Oct 27, 2021 at 3:28 PM Arnd Bergmann wrote:
>
> Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> make any driver that needs it have a dependency on the class device
> being available, to prevent circular dependencies.
Acked-by: Miguel Ojeda
Cheers,
Miguel
s good to me, the indirection is making things more complex than
they need to be.
Reviewed-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote:
>
> The maintainer is not necessarily the owner/author of the code, and
> thus may not know the intent of the code.
Agreed, I was not blaming maintainers -- just trying to point out that
the problem is there :-)
In those cases, it is
On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
>
> To make the intent clear, you have to first be certain that you
> understand the intent; otherwise by adding either a break or a
> fallthrough to suppress the warning you are just destroying the
> information that "the intent of this code
On Wed, Nov 25, 2020 at 5:24 PM Jakub Kicinski wrote:
>
> And just to spell it out,
>
> case ENUM_VALUE1:
> bla();
> break;
> case ENUM_VALUE2:
> bla();
> default:
> break;
>
> is a fairly idiomatic way of indicating that not all values of the enum
> are expected
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote:
>
> What I meant was that you've used pessimism as if it was fact.
"future mistakes that it might prevent" is neither pessimism nor states a fact.
> For example, "There is no way to guess what the effect would be if the
> compiler trained
On Wed, Nov 25, 2020 at 12:53 AM Finn Thain wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)
Making the kernel strictly conforming is a ship that
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.
No, I have not said that. Please don't put words in my mouth (again).
I have said *authoring* lines of *this* kind
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.
There is no "language spec" the kernel adheres to. Even if it did,
kernel
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.
Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches. Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> Well, I used git. It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.
I can see ~10k insertions over
On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it? All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions
Hi Gustavo,
On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
Thanks for this.
Since this warning is reliable in both/all compilers and we are
On Mon, Dec 9, 2019 at 3:04 PM Jani Nikula wrote:
>
> On Tue, 03 Dec 2019, Jani Nikula wrote:
> > Now that the fbops member of struct fb_info is const, we can start
> > making the ops const as well.
> >
> > Cc: Miguel Ojeda Sandonis
> > Cc: Robin van der Gr
On Fri, Nov 29, 2019 at 9:30 PM Daniel Vetter wrote:
>
> Well we do have very small lcd display drivers in drm, and before that in
> fbdev. And you have a fbdev framebuffer driver in there, which looks a bit
> misplaced ...
>
> Afaiui you also have some even tinier lcd drivers where you don't
On Fri, Nov 29, 2019 at 4:24 PM Daniel Vetter wrote:
>
> Oh, another display subsystem? Intriguing ...
>
> Reviewed-by: Daniel Vetter
It is intended for displays that are not intended as the usual/main
display, e.g. very small LCDs :)
Reviewed-by: Miguel Ojeda
Ch
On Thu, Feb 7, 2019 at 11:28 PM Jason Gunthorpe wrote:
>
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> backing pages") introduced the sg_page_iter_dma_address() function without
> providing a way to use it in the general case. If the sg_dma_len() is not
> equal to
Hi Souptick,
On Fri, Oct 5, 2018 at 12:01 PM Souptick Joarder wrote:
>
> The final goal is to remove vm_insert_page by converting it to
> vmf_insert_page. But to do that we have to first introduce the
> new API which is similar to vm_insert_page (for non #PF). I tried this by
> introducing
Hi Souptick,
On Fri, Oct 5, 2018 at 7:51 AM Souptick Joarder wrote:
>
> On Fri, Oct 5, 2018 at 1:16 AM Miguel Ojeda
> wrote:
> >
> >
> > Also, not sure if you saw my comments/review: if the interface is not
> > going to change, why the name chang
On Sat, Oct 6, 2018 at 7:11 AM Souptick Joarder wrote:
>
> On Fri, Oct 5, 2018 at 11:39 PM Miguel Ojeda
> wrote:
> > They are not supposed to be "steps". You did it with 70+ commits (!!)
> > over the course of several months. Why a tree wasn't created, stuff
>
On Fri, Oct 5, 2018 at 2:11 PM Souptick Joarder wrote:
>
> On Fri, Oct 5, 2018 at 4:19 PM Miguel Ojeda
> wrote:
> >
> > 1. Introduce the vmf_* API
> > 2. Change all PF-users users to that (leaving all non-PF ones
> > untouched!) -- if this is
Hi Souptick,
On Thu, Oct 4, 2018 at 8:49 PM Souptick Joarder wrote:
>
> On Thu, Oct 4, 2018 at 11:47 PM Matthew Wilcox wrote:
> >
> > I think this is a bad plan. What we should rather do is examine the current
> > users of vm_insert_page() and ask "What interface would better replace
> >
Hi Souptick,
On Wed, Oct 3, 2018 at 8:55 PM Souptick Joarder wrote:
>
> vm_insert_kmem_page is similar to vm_insert_page and will
> be used by drivers to map kernel (kmalloc/vmalloc/pages)
> allocated memory to user vma.
>
> Going forward, the plan is to restrict future drivers not
> to use
Hi Sam,
On Thu, Aug 2, 2018 at 9:39 PM, Sam Ravnborg wrote:
> This is an RFC - to get some responses on the overall design.
> The code builds but has not yet been tested on any HW.
> Before investing more time into this I would like some feedback
> if this is the right way forward or a different
64 matches
Mail list logo
