On Fri Oct 10, 2025 at 5:24 PM JST, Alexandre Courbot wrote: > On Fri Oct 10, 2025 at 12:41 AM JST, Joel Fernandes wrote: >> >> >>> On Oct 9, 2025, at 11:17 AM, Joel Fernandes <[email protected]> wrote: >>> >>> Hi Alex, >>> >>>> On 10/9/2025 8:37 AM, Alexandre Courbot wrote: >>>> The getter method of a field works with the field type, but its setter >>>> expects the type of the register. This leads to an asymmetry in the >>>> From/Into implementations required for a field with a dedicated type. >>>> For instance, a field declared as >>>> >>>> pub struct ControlReg(u32) { >>>> 3:0 mode as u8 ?=> Mode; >>>> ... >>>> } >>>> >>>> currently requires the following implementations: >>>> >>>> impl TryFrom<u8> for Mode { >>>> ... >>>> } >>>> >>>> impl From<Mode> for u32 { >>>> ... >>>> } >>>> >>>> Change this so the `From<Mode>` now needs to be implemented for `u8`, >>>> i.e. the primitive type of the field. This is more consistent, and will >>>> become a requirement once we start using the TryFrom/Into derive macros >>>> to implement these automatically. >>>> >>>> Reported-by: Edwin Peer <[email protected]> >>>> Signed-off-by: Alexandre Courbot <[email protected]> >>> >>> As these are incremental improvements, could you please rebase on top of >>> the v6 >>> bitfield series so it does not conflict? >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/log/?h=nova.dev.bitfield.submitted.v6 >> >> On second thought, I could just carry this patch on top of my v6 series and >> avoid too much conflict. >> >> So if it is ok with you, please only carry the last 2 patches of this series >> whenever applying. >> >> For this patch: >> Reviewed-by: Joel Fernandes <[email protected]> >> >> I will review the other two patches as well. Thanks. > > The idea is for this patch to go *before* your series, to avoid the > asymmetry in the From/Into implementions of bitfields. We could also put > it after, but it would become larger as a result and I think it can be > merge soon after -rc1 is tagged anyway.
I forgot to mention that this patch is not really part of the series ; it's just here to allow it to apply on top of drm-rust-next should anyone want to try it.
