On 25.06.2024 22:56, Paul Barker wrote: > On 17/06/2024 13:02, Geert Uytterhoeven wrote: >> Hi Paul, >> >> On Tue, Jun 11, 2024 at 1:33 PM Paul Barker >> <paul.barker.ct@xxxxxxxxxxxxxx> wrote: >>> -static u8 rzg3s_pin_to_oen_bit(u32 offset, u8 pin, u8 max_port) >>> +static u32 rzg3s_read_oen(struct rzg2l_pinctrl *pctrl, u32 caps, unsigned int _pin) >>> { >>> - if (pin) >>> - pin *= 2; >>> + u32 port = RZG2L_PIN_ID_TO_PORT(_pin); >>> + u8 pin = RZG2L_PIN_ID_TO_PIN(_pin); >> >> It's OK to use RZG2L_PIN_ID_TO_PIN() unconditionally, as RZ/G3S does >> not have any dedicated pins with the OEN capability, right? > > I thought about this a bit and came to the conclusion that no, it's not > ok. > > For RZ/G2L, only mux'd pins have OEN capability (Ethernet TXC/TX_CLK > only). > > For RZ/G3S, OEN capability also exists on XSPI/OCTA pins which are > dedicated pins. We don't currently support OEN for these pins in the > driver, but we should put a check in place now to be safe. Just my preference: I would avoid adding code that is not currently used or cannot be properly tested. Thank you, Claudiu Beznea > I've done > this in v3 which I'm about to send... > > Thanks, >