On Mon, Jan 20, 2025 at 11:03 PM Link Mauve wrote:
>
> when building with today’s nightly compiler (maybe that’s relevant?).
Ah, that explains it! The type changes with beta (1.85.0), and I can
also reproduce it in CE.
We should probably try to backport the cleanups we did before the
remapping,
Hi Emmanuel,
On Mon, Jan 20, 2025 at 1:45 PM Emmanuel Gil Peyrot
wrote:
>
> In C, the char type is specified with “The implementation shall define char to
> have the same range, representation, and behavior as either signed char or
> unsigned char.”
>
> On x86 it defaults to signed char, and on A
On Tue, Jan 14, 2025 at 3:24 PM Simona Vetter wrote:
>
> Feels like trying to replicate docs in rust might be dangerous, because if
> we have to keep really detailed and nuanced docs around in two places we
> will fail.
>
> Imo would be better to just explain how this maps to the C side and link
>
On Tue, Dec 10, 2024 at 12:05 AM Jocelyn Falempe wrote:
>
> You can merge it through rust-fixes. I have another patch [1] under
> review that touches this file, but it shouldn't conflict, as the changes
> are far from this line.
Sounds good, thanks! (But of course please feel free to merge fixes
On Tue, Nov 26, 2024 at 10:04 AM Jocelyn Falempe wrote:
>
> Thanks for this patch, it looks good to me.
>
> Reviewed-by: Jocelyn Falempe
Thanks Jocelyn. I thought DRM would pick this one -- should I pick it
through rust-fixes?
Cheers,
Miguel
On Sat, Oct 19, 2024 at 10:41 AM Thomas Böhler wrote:
>
> The file drivers/gpu/drm/drm_panic_qr.rs has some lints that Clippy
> complains about. This series cleans them up by either allowing what is
> written or conforming to what Clippy expects where it makes sense.
Applied to `rust-next` -- tha
On Mon, Oct 14, 2024 at 10:54 AM Jocelyn Falempe wrote:
>
> With the suggestions from Alice Ryhl to not introduce a return, and use
> expect:
+1 to both.
`expect` (here and the other ones I suggested) require `rust-next`, so
if this goes through DRM, then we can clean this up later. Otherwise,
i
ly commit messages use newlines between paragraphs.
> Reported-by: Miguel Ojeda
> Closes: https://github.com/Rust-for-Linux/linux/issues/1123
Since each of these commits fixes part of the issue, I think these are
meant to be `Link:`s instead of `Closes:`s according to the docs:
https://
B_DEFLATE`.
Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen")
Signed-off-by: Miguel Ojeda
---
drivers/gpu/drm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1cb5a4f19293..cf5bc77e2362 100644
--- a/drivers/gpu/drm/K
On Tue, Oct 1, 2024 at 11:26 AM Jani Nikula wrote:
>
> regenerated? Should there be more granularity?
Indeed, eventually this will need to be split, like we did for `helpers.c`.
Cheers,
Miguel
On Wed, Jul 24, 2024 at 3:54 PM Steven Price wrote:
>
> I'd be quite keen for the "fork" to live in the upstream kernel. My
> preference is for the two drivers to sit side-by-side. I'm not sure
> whether that's a common view though.
It is supposed to be against the usual rules/guidelines, but we
On Sat, Jul 13, 2024 at 2:48 AM Dave Airlie wrote:
>
> I think I'm on the uapi should remain in C for now, we define uapi
> types with the kernel types and we have downstream tools to scan and
> parse them to deal with alignments and padding (I know FEX relies on
> it), so I think we should be bin
On Tue, Jul 9, 2024 at 5:10 PM Jocelyn Falempe wrote:
>
> I used to list all QR versions in an enum, but I find it a bit too much
> boilerplate to ensure the version is between 1 and 40.
> By transparent newtypes, you mean adding "#[repr(transparent)]" to a
> struct ?
> I don't plan to add more "v
Hi Jocelyn,
A quick docs-only review of the Rust side (some of these apply in
several cases -- I just wanted to give an overview for you to
consider).
On Tue, Jul 9, 2024 at 10:45 AM Jocelyn Falempe wrote:
>
> +//! This is a simple qr encoder for DRM panic.
> +//!
> +//! Due to the Panic constra
On Thu, Jul 4, 2024 at 7:03 AM Greg KH wrote:
>
> Wait, we can put .rs files in any directory now? I didn't think that
> worked properly yet.
We can put leaves of the crate graph (e.g. in-tree we have the samples
and the PHY driver), but not the rest of the graph. The former fits
just fine in Kb
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, i
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]
>
&g
fUxLkHJYqeBAhpc6YcX7bfR96gmmbF=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 10
remove 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 doubl
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 [-Werror,-Wunuse
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
.com/
[2]
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/dri
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.
T
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 le
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 `d
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 au
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 backlight_get_brightne
es `=`).
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 th
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 h
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 ke
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,
.vis
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 zero
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 w
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 list
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 con
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 the
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
> +#de
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
d 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 stil
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 to
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 program
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 s
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 tak
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 co
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 indentation
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 ~1
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
event
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 addr
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 t
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 vm_in
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, stuf
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 too b
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
> > vm_ins
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 vm_in
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
79 matches
Mail list logo
