[PATCH v5 3/5] gpio: spacemit: add support for K1 SoC
Bartosz Golaszewski
brgl at bgdev.pl
Fri Feb 21 04:33:26 PST 2025
On Fri, Feb 21, 2025 at 1:21 PM Yixun Lan <dlan at gentoo.org> wrote:
>
> Hi Bartosz Golaszewski:
>
> On 09:37 Fri 21 Feb , Bartosz Golaszewski wrote:
> > On Fri, Feb 21, 2025 at 12:36 AM Chen Wang <unicorn_wang at outlook.com> wrote:
> > >
> > >
> > > On 2025/2/20 21:34, Bartosz Golaszewski wrote:
> > > > On Mon, Feb 17, 2025 at 1:58 PM Yixun Lan <dlan at gentoo.org> wrote:
> > > [......]
> > > >> +#define to_spacemit_gpio_bank(x) container_of((x), struct spacemit_gpio_bank, gc)
> > > >> +
> > > >> +struct spacemit_gpio;
> > > >> +
> > > >> +struct spacemit_gpio_bank {
> > > >> + struct gpio_chip gc;
> > > >> + struct spacemit_gpio *sg;
> > > >> + void __iomem *base;
> > > >> + u32 index;
> > > >> + u32 irq_mask;
> > > >> + u32 irq_rising_edge;
> > > >> + u32 irq_falling_edge;
> > > >> +};
> > > >> +
> > > >> +struct spacemit_gpio {
> > > >> + struct device *dev;
> > > >> + struct spacemit_gpio_bank sgb[NR_BANKS];
> > > >> +};
> > > > Please don't use tabs in struct definitions.
> > >
> > > Why not?I see
> > > https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#struct-declarations-and-initializers
> > >
> >
> > This is for the tip tree, not treewide.
> >
> > It's my personal maintainer preference. We do use both under
> > drivers/gpio/ but I prefer no-tabs in new code.
> >
>
> thanks for this explanation..
>
> my intention was trying to keep struct members aligned
> if tabs is a no-go, would using multi blank spaces to align be acceptable?
>
> something like:
>
> struct spacemit_gpio_bank {
> struct gpio_chip gc;
> struct spacemit_gpio *sg;
> void __iomem *base;
> ...
> }
>
No, that's even worse. :/
Why are we even wasting time arguing, can you just use a single space?
You'll get a driver merged and may just disappear from kernel
development, Linus and I will have to maintain the code so we do get
some degree of discretion when it comes to coding style.
Bart
More information about the linux-riscv
mailing list