On Mon, May 12, 2025 at 2:09 PM Danilo Krummrich wrote:
>
> Lyude's series [1] should address this and the other one you pointed out.
Great, thanks!
Cheers,
Miguel
On Mon, May 12, 2025 at 1:41 PM Miguel Ojeda
wrote:
>
> Doing something unrelated, I got a Clippy warning about this public
By the way, this call (and another one here) to `container_of!` goes
through `Opaque`, so it will not pass the future `assert_same_type`
test we want to have:
error
On Fri, Apr 11, 2025 at 1:56 AM Danilo Krummrich wrote:
>
> +fn from_gem_obj(obj: *mut bindings::drm_gem_object) -> *mut Self {
> +// SAFETY: All of our objects are Object.
> +unsafe { crate::container_of!(obj, Object, obj).cast_mut() }
> +}
Doing something unrelated, I go
On Fri, Apr 18, 2025 at 5:09 PM Boqun Feng wrote:
>
> I'm leaning towards to 2 and then 3, because using `as` can sometimes
> surprise you when you change the type. Thoughts?
Having explicit functions sounds good to me, and would also help
migrating later easily to anything else (because all case
On Fri, Apr 18, 2025 at 6:51 PM Jocelyn Falempe wrote:
>
> Link:
> https://lore.kernel.org/dri-devel/caniq72ke45eowckmhwhvmwxc03dxr4rnxxkvx+hvwdblopz...@mail.gmail.com/
> [1]
Thanks for fixing that -- some tags for your consideration:
Reported-by: Miguel Ojeda
Cl
On Wed, Apr 16, 2025 at 2:21 PM Miguel Ojeda wrote:
>
> `///` should still be used for private items [1]. Some of the items in
> this file do so already, so do it for a few other clear candidates in
> the file.
>
> Link:
> https://lore.kernel.org/rust-for-linux/202504
`///` should still be used for private items [1]. Some of the items in
this file do so already, so do it for a few other clear candidates in
the file.
Link:
https://lore.kernel.org/rust-for-linux/20250416112454.2503872-1-oj...@kernel.org/
[1]
Signed-off-by: Miguel Ojeda
---
Not sure if you
On Mon, Apr 14, 2025 at 8:14 PM Miguel Ojeda
wrote:
>
> operator with some support from upstream Rust. Or do you have
Or, probably something that makes more sense: just forbidding its use.
Cheers,
Miguel
Hi Jocelyn, Christian,
I started build-testing arm 32-bit within my other usual routine
tests, and I hit:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by drm_panic_qr.rs:417 (drivers/gpu/drm/drm_panic_qr.rs:417)
>>> drivers/gpu/drm/drm_panic_qr.o:(::next) in archiv
Hi Daniel,
A few quick notes for future versions on style/docs to try to keep
things consistent upstream -- not an actual review.
On Mon, Mar 24, 2025 at 4:14 PM Daniel Almeida
wrote:
>
> +#[allow(type_alias_bounds)]
The documentation says this is highly discouraged -- it may be good to
mention
On Tue, Mar 25, 2025 at 10:05 AM Jocelyn Falempe wrote:
>
> Thanks, it looks good to me.
>
> Reviewed-by: Jocelyn Falempe
>
> You want to take the whole series in the rust tree?
>
> Otherwise I can push the patch 1-2 to drm-misc-next if needed.
Please take them if possible, since others may want
On Fri, Mar 28, 2025 at 11:27 PM Lyude Paul wrote:
>
> So - it actually does protect us to a limited extent on the rust side of
> things. With CONFIG_RUST_OVERFLOW_CHECKS=y, arithematic checks are builtin to
> the language. This isn't the default config of course, but it's better then
> nothing.
On Wed, Mar 26, 2025 at 11:39 AM Jani Nikula
wrote:
>
> That is largely the point, though. You know something fishy is going on
> when you have a negative resolution. Nobody blinks an eye when you ask
> for 4294963K telly, but it's still just as bonkers as that negative 4K.
>
> I think the change
On Tue, Mar 25, 2025 at 9:07 PM Tamir Duberstein wrote:
>
> Changes in v7:
> - Add patch to enable `clippy::ref_as_ptr`.
> - Link to v6:
> https://lore.kernel.org/r/20250324-ptr-as-ptr-v6-0-49d1b7fd4...@gmail.com
Please slow down -- at least wait a few days between revisions (unless
there is a p
Add missing space in sentence.
This was found using the Clippy `doc_markdown` lint, which we may want
to enable.
Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen")
Signed-off-by: Miguel Ojeda
---
drivers/gpu/drm/drm_panic_qr.rs | 2 +-
1 file changed, 1 insertion(+),
On Mon, Mar 24, 2025 at 8:38 PM Miguel Ojeda
wrote:
>
> Yeah, I asked upstream if we could have something that at least
> detects what could have been intra-doc links, because that should not
> have too many false positives since it is a subset:
>
> https://github.com/rus
Add missing Markdown code span.
This was found using the Clippy `doc_markdown` lint, which we may want
to enable.
Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen")
Signed-off-by: Miguel Ojeda
---
drivers/gpu/drm/drm_panic_qr.rs | 2 +-
1 file changed, 1 insertion(+),
On Mon, Mar 24, 2025 at 8:25 PM Daniel Almeida
wrote:
>
> By the way, maybe we should have a lint for CamelCase in docs? I tried my
> best to
> cover all of these, but some slip through :/
>
> i.e.: if you write something in CamelCase somewhere in the docs, there's a
> high
> chance that you sho
On Mon, Mar 24, 2025 at 4:14 PM Daniel Almeida
wrote:
>
> -const blk_features_t RUST_CONST_HELPER_BLK_FEAT_ROTATIONAL =
> BLK_FEAT_ROTATIONAL;
> +const blk_features_t RUST_CONST_HELPER_BLK_FEAT_ROTATIONAL =
> + BLK_FEAT_ROTATIONAL;
Spurious change?
Ah, this is probably the result of apply
On Wed, Mar 19, 2025 at 5:13 PM Tamir Duberstein wrote:
>
> No, I meant avoiding the check. The existing code already explicitly
> checks `new_len > self.len()` before evaluating `new_len -
> self.len()`. This means the check occurs twice. `checked_sub` reduces
> the number of checks by 1. Perhaps
On Wed, Mar 19, 2025 at 4:59 PM Tamir Duberstein wrote:
>
> If we're talking about the same thing then I think we're both wrong
> and the correct phrasing would have been: "you can avoid underflow
> checking when CONFIG_RUST_OVERFLOW_CHECKS=y by using `checked_sub`". I
> was referring to the under
On Sat, Mar 15, 2025 at 3:43 AM Andrew Ballance
wrote:
>
> +/// # Example
Nit: please use the plural for section headers.
Thanks!
Cheers,
Miguel
On Thu, Mar 13, 2025 at 5:58 PM Benjamin Tissoires wrote:
>
> skeletons are good for documentation, but not really for code review as
> they can not compile.
>
> You should make this patch part of a documentation in
> Documentation/hid/, and squash it with the next one (having a minimal
> full dri
On Tue, Mar 11, 2025 at 10:17 AM Stephen Rothwell wrote:
>
> I fixed it up (I guess - see below) and can carry the fix as necessary.
Looks good to me, thanks!
Cheers,
Miguel
On Mon, Mar 3, 2025 at 9:45 AM Alice Ryhl wrote:
>
> Rust has two different tools for generating function declarations to
> call across the FFI boundary:
>
> * bindgen. Generates Rust declarations from a C header.
> * cbindgen. Generates C headers from Rust declarations.
>
> However, we only use b
macros, provide an alias.
>
> This is first used by the `module_firmware!` macro introduced in a
> subsequent patch.
>
> Suggested-by: Alice Ryhl
> Signed-off-by: Danilo Krummrich
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Sun, Mar 2, 2025 at 7:31 PM Jarkko Sakkinen wrote:
>
> Ah, ok, I guessed that you might have some backing idea on what you put
> :-) Thanks for the explanation.
You're welcome!
Cheers,
Miguel
On Sun, Mar 2, 2025 at 5:50 PM Jarkko Sakkinen wrote:
>
> (cosmetic) Nit:
>
> I think you could just:
>
> Cc: sta...@vger.kernel.org # v6.12+
Thanks Jarkko -- I did something similar in the past, but sometimes
patches got backported too much because they could be applied.
Normally they don't hur
On Fri, Feb 28, 2025 at 4:41 PM Tamir Duberstein wrote:
>
> This needs an update given Miguel's comments on the cover letter. I
> wonder if the code should also justify the choice (over cbindgen).
`cbindgen` is a longer term thing and more complex, assuming we use it
in the end, so I think it is
On Fri, Feb 28, 2025 at 1:40 PM Alice Ryhl wrote:
>
> This is because cbindgen assumes a
> cargo-based buildsystem, so it is not compatible with the kernel's build
> system.
I don't think this is true (checking is already a very good
justification, so we don't need this to justify the series):
On Wed, Feb 5, 2025 at 2:57 PM Zhi Wang wrote:
>
> It would be also helpful to make the process explicit. E.g. sharing your
> command lines used to checking the patches. So folks can align with the
> expected outcome, e.g. command line parameters.
These two guidelines (and generally the few other
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
1 - 100 of 110 matches
Mail list logo
