* microchip soc maintainance change proposal
@ 2024-09-24 11:46 Conor Dooley
2024-09-24 14:05 ` Nicolas Ferre
0 siblings, 1 reply; 9+ messages in thread
From: Conor Dooley @ 2024-09-24 11:46 UTC (permalink / raw)
To: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
Cc: Daire McNamara, conor, soc
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
Hey folks,
I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
that, but I would like to propose some changes to how the Microchip soc
support is maintained - mostly affecting the riscv side of things that
I've been maintaining in my personal tree, alongside other platforms.
I'd like to propose moving those from my tree, into the at91 tree.
While the dts bits for the arm and riscv platforms have no overlap
and nothing is particularly gained from me moving which tree
location they're in, I'm far more interested in disambiguating the tree
that soc and/or firmware bindings and drivers end up in.
I was going to add the bindings/soc/microchip directory to the
maintainers entry I have for drivers/soc/microchip, but while doing
that, I noticed that there have been recent patches for sam and sparx5
bits that have added files to that bindings directory that went via at91
and I figure it's almost certain that there'll be drivers added before
too long. Having a single location, like we do at the moment for clocks,
would make the route upstream for things a bit clearer - and I figured
that while moving one thing, might as well move the firmware and dts
stuff too.
My assumption is that the riscv dts bits would retain their own branch,
and that I'd still send the PRs for them and for the firmware stuff given
that there's no !riscv soc content in that directory yet - and I don't
want to saddle Claudiu with more work for devices he probably doesn't
care about...
Seem reasonable?
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-24 11:46 microchip soc maintainance change proposal Conor Dooley
@ 2024-09-24 14:05 ` Nicolas Ferre
2024-09-24 14:24 ` Alexandre Belloni
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Ferre @ 2024-09-24 14:05 UTC (permalink / raw)
To: Conor Dooley, Alexandre Belloni, Claudiu Beznea; +Cc: Daire McNamara, soc
On 24/09/2024 at 13:46, Conor Dooley wrote:
> Hey folks,
>
> I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> that, but I would like to propose some changes to how the Microchip soc
> support is maintained - mostly affecting the riscv side of things that
> I've been maintaining in my personal tree, alongside other platforms.
> I'd like to propose moving those from my tree, into the at91 tree.
I don't know if the "at91" naming will remain a right designation of
what we're doing in the future, but well, let's stick to it for now.
Some find it a little too much tight to the old Atmel brand...
> While the dts bits for the arm and riscv platforms have no overlap
> and nothing is particularly gained from me moving which tree
> location they're in, I'm far more interested in disambiguating the tree
> that soc and/or firmware bindings and drivers end up in.
>
> I was going to add the bindings/soc/microchip directory to the
> maintainers entry I have for drivers/soc/microchip, but while doing
> that, I noticed that there have been recent patches for sam and sparx5
FYI: and we have the older drivers/soc/atmel directory (which is caught
by "ARM/Microchip (AT91) SoC support" entry).
> bits that have added files to that bindings directory that went via at91
> and I figure it's almost certain that there'll be drivers added before
> too long. Having a single location, like we do at the moment for clocks,
> would make the route upstream for things a bit clearer - and I figured
> that while moving one thing, might as well move the firmware and dts
> stuff too.
>
> My assumption is that the riscv dts bits would retain their own branch,
> and that I'd still send the PRs for them and for the firmware stuff given
> that there's no !riscv soc content in that directory yet - and I don't
> want to saddle Claudiu with more work for devices he probably doesn't
> care about...
>
> Seem reasonable?
That's fine with me Conor. It makes a lot of sense as we're working on
more and more topics together.
Best regards,
Nicolas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-24 14:05 ` Nicolas Ferre
@ 2024-09-24 14:24 ` Alexandre Belloni
2024-09-25 7:34 ` claudiu beznea
0 siblings, 1 reply; 9+ messages in thread
From: Alexandre Belloni @ 2024-09-24 14:24 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Conor Dooley, Claudiu Beznea, Daire McNamara, soc
On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
> On 24/09/2024 at 13:46, Conor Dooley wrote:
> > Hey folks,
> >
> > I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> > that, but I would like to propose some changes to how the Microchip soc
> > support is maintained - mostly affecting the riscv side of things that
> > I've been maintaining in my personal tree, alongside other platforms.
> > I'd like to propose moving those from my tree, into the at91 tree.
>
> I don't know if the "at91" naming will remain a right designation of what
> we're doing in the future, but well, let's stick to it for now.
> Some find it a little too much tight to the old Atmel brand...
>
We could take this opportunity to rename the tree microchip or mchp.
> > While the dts bits for the arm and riscv platforms have no overlap
> > and nothing is particularly gained from me moving which tree
> > location they're in, I'm far more interested in disambiguating the tree
> > that soc and/or firmware bindings and drivers end up in.
> >
> > I was going to add the bindings/soc/microchip directory to the
> > maintainers entry I have for drivers/soc/microchip, but while doing
> > that, I noticed that there have been recent patches for sam and sparx5
>
> FYI: and we have the older drivers/soc/atmel directory (which is caught by
> "ARM/Microchip (AT91) SoC support" entry).
>
> > bits that have added files to that bindings directory that went via at91
> > and I figure it's almost certain that there'll be drivers added before
> > too long. Having a single location, like we do at the moment for clocks,
> > would make the route upstream for things a bit clearer - and I figured
> > that while moving one thing, might as well move the firmware and dts
> > stuff too.
> >
> > My assumption is that the riscv dts bits would retain their own branch,
> > and that I'd still send the PRs for them and for the firmware stuff given
> > that there's no !riscv soc content in that directory yet - and I don't
> > want to saddle Claudiu with more work for devices he probably doesn't
> > care about...
> >
> > Seem reasonable?
>
> That's fine with me Conor. It makes a lot of sense as we're working on more
> and more topics together.
Looks good to me.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-24 14:24 ` Alexandre Belloni
@ 2024-09-25 7:34 ` claudiu beznea
2024-09-25 16:16 ` Conor Dooley
0 siblings, 1 reply; 9+ messages in thread
From: claudiu beznea @ 2024-09-25 7:34 UTC (permalink / raw)
To: Alexandre Belloni, Nicolas Ferre; +Cc: Conor Dooley, Daire McNamara, soc
On 24.09.2024 17:24, Alexandre Belloni wrote:
> On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
>> On 24/09/2024 at 13:46, Conor Dooley wrote:
>>> Hey folks,
>>>
>>> I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
>>> that, but I would like to propose some changes to how the Microchip soc
>>> support is maintained - mostly affecting the riscv side of things that
>>> I've been maintaining in my personal tree, alongside other platforms.
>>> I'd like to propose moving those from my tree, into the at91 tree.
>>
>> I don't know if the "at91" naming will remain a right designation of what
>> we're doing in the future, but well, let's stick to it for now.
>> Some find it a little too much tight to the old Atmel brand...
>>
>
> We could take this opportunity to rename the tree microchip or mchp.
+1
>
>>> While the dts bits for the arm and riscv platforms have no overlap
>>> and nothing is particularly gained from me moving which tree
>>> location they're in, I'm far more interested in disambiguating the tree
>>> that soc and/or firmware bindings and drivers end up in.
>>>
>>> I was going to add the bindings/soc/microchip directory to the
>>> maintainers entry I have for drivers/soc/microchip, but while doing
>>> that, I noticed that there have been recent patches for sam and sparx5
>>
>> FYI: and we have the older drivers/soc/atmel directory (which is caught by
>> "ARM/Microchip (AT91) SoC support" entry).
>>
>>> bits that have added files to that bindings directory that went via at91
>>> and I figure it's almost certain that there'll be drivers added before
>>> too long. Having a single location, like we do at the moment for clocks,
>>> would make the route upstream for things a bit clearer - and I figured
>>> that while moving one thing, might as well move the firmware and dts
>>> stuff too.
>>>
>>> My assumption is that the riscv dts bits would retain their own branch,
>>> and that I'd still send the PRs for them and for the firmware stuff given
>>> that there's no !riscv soc content in that directory yet - and I don't
>>> want to saddle Claudiu with more work for devices he probably doesn't
>>> care about...
>>>
>>> Seem reasonable?
>>
>> That's fine with me Conor. It makes a lot of sense as we're working on more
>> and more topics together.
>
> Looks good to me.
Looks good to me, too.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-25 7:34 ` claudiu beznea
@ 2024-09-25 16:16 ` Conor Dooley
2024-09-25 17:59 ` Alexandre Belloni
0 siblings, 1 reply; 9+ messages in thread
From: Conor Dooley @ 2024-09-25 16:16 UTC (permalink / raw)
To: claudiu beznea; +Cc: Alexandre Belloni, Nicolas Ferre, Daire McNamara, soc
[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]
On Wed, Sep 25, 2024 at 10:34:10AM +0300, claudiu beznea wrote:
>
>
> On 24.09.2024 17:24, Alexandre Belloni wrote:
> > On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
> >> On 24/09/2024 at 13:46, Conor Dooley wrote:
> >>> Hey folks,
> >>>
> >>> I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> >>> that, but I would like to propose some changes to how the Microchip soc
> >>> support is maintained - mostly affecting the riscv side of things that
> >>> I've been maintaining in my personal tree, alongside other platforms.
> >>> I'd like to propose moving those from my tree, into the at91 tree.
> >>
> >> I don't know if the "at91" naming will remain a right designation of what
> >> we're doing in the future, but well, let's stick to it for now.
> >> Some find it a little too much tight to the old Atmel brand...
> >>
> >
> > We could take this opportunity to rename the tree microchip or mchp.
>
> +1
I personally don't care at all about the tree being called at91 or w/e,
but I wouldn't object to a rename to either. I can whip up a mail to the
helpdesk if yous like.
>
> >
> >>> While the dts bits for the arm and riscv platforms have no overlap
> >>> and nothing is particularly gained from me moving which tree
> >>> location they're in, I'm far more interested in disambiguating the tree
> >>> that soc and/or firmware bindings and drivers end up in.
> >>>
> >>> I was going to add the bindings/soc/microchip directory to the
> >>> maintainers entry I have for drivers/soc/microchip, but while doing
> >>> that, I noticed that there have been recent patches for sam and sparx5
> >>
> >> FYI: and we have the older drivers/soc/atmel directory (which is caught by
> >> "ARM/Microchip (AT91) SoC support" entry).
> >>
> >>> bits that have added files to that bindings directory that went via at91
> >>> and I figure it's almost certain that there'll be drivers added before
> >>> too long. Having a single location, like we do at the moment for clocks,
> >>> would make the route upstream for things a bit clearer - and I figured
> >>> that while moving one thing, might as well move the firmware and dts
> >>> stuff too.
> >>>
> >>> My assumption is that the riscv dts bits would retain their own branch,
> >>> and that I'd still send the PRs for them and for the firmware stuff given
> >>> that there's no !riscv soc content in that directory yet - and I don't
> >>> want to saddle Claudiu with more work for devices he probably doesn't
> >>> care about...
> >>>
> >>> Seem reasonable?
> >>
> >> That's fine with me Conor. It makes a lot of sense as we're working on more
> >> and more topics together.
> >
> > Looks good to me.
>
> Looks good to me, too.
Cool. I'll take a look at what makes the most sense in terms of
maintainers entries then. Thanks guys.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-25 16:16 ` Conor Dooley
@ 2024-09-25 17:59 ` Alexandre Belloni
2024-09-26 17:19 ` Conor Dooley
0 siblings, 1 reply; 9+ messages in thread
From: Alexandre Belloni @ 2024-09-25 17:59 UTC (permalink / raw)
To: Conor Dooley; +Cc: claudiu beznea, Nicolas Ferre, Daire McNamara, soc
On 25/09/2024 17:16:10+0100, Conor Dooley wrote:
> On Wed, Sep 25, 2024 at 10:34:10AM +0300, claudiu beznea wrote:
> >
> >
> > On 24.09.2024 17:24, Alexandre Belloni wrote:
> > > On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
> > >> On 24/09/2024 at 13:46, Conor Dooley wrote:
> > >>> Hey folks,
> > >>>
> > >>> I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> > >>> that, but I would like to propose some changes to how the Microchip soc
> > >>> support is maintained - mostly affecting the riscv side of things that
> > >>> I've been maintaining in my personal tree, alongside other platforms.
> > >>> I'd like to propose moving those from my tree, into the at91 tree.
> > >>
> > >> I don't know if the "at91" naming will remain a right designation of what
> > >> we're doing in the future, but well, let's stick to it for now.
> > >> Some find it a little too much tight to the old Atmel brand...
> > >>
> > >
> > > We could take this opportunity to rename the tree microchip or mchp.
> >
> > +1
>
> I personally don't care at all about the tree being called at91 or w/e,
> but I wouldn't object to a rename to either. I can whip up a mail to the
> helpdesk if yous like.
Yeah, I guess you can ask for the rename and be added to the list of
users that can push to the repo. At the same time, you can send a patch
to update the MAINTAINER entry so we can ack it.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-25 17:59 ` Alexandre Belloni
@ 2024-09-26 17:19 ` Conor Dooley
2024-09-27 8:03 ` Nicolas Ferre
0 siblings, 1 reply; 9+ messages in thread
From: Conor Dooley @ 2024-09-26 17:19 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: claudiu beznea, Nicolas Ferre, Daire McNamara, soc
[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]
On Wed, Sep 25, 2024 at 07:59:52PM +0200, Alexandre Belloni wrote:
> On 25/09/2024 17:16:10+0100, Conor Dooley wrote:
> > On Wed, Sep 25, 2024 at 10:34:10AM +0300, claudiu beznea wrote:
> > >
> > >
> > > On 24.09.2024 17:24, Alexandre Belloni wrote:
> > > > On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
> > > >> On 24/09/2024 at 13:46, Conor Dooley wrote:
> > > >>> Hey folks,
> > > >>>
> > > >>> I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> > > >>> that, but I would like to propose some changes to how the Microchip soc
> > > >>> support is maintained - mostly affecting the riscv side of things that
> > > >>> I've been maintaining in my personal tree, alongside other platforms.
> > > >>> I'd like to propose moving those from my tree, into the at91 tree.
> > > >>
> > > >> I don't know if the "at91" naming will remain a right designation of what
> > > >> we're doing in the future, but well, let's stick to it for now.
> > > >> Some find it a little too much tight to the old Atmel brand...
> > > >>
> > > >
> > > > We could take this opportunity to rename the tree microchip or mchp.
> > >
> > > +1
> >
> > I personally don't care at all about the tree being called at91 or w/e,
> > but I wouldn't object to a rename to either. I can whip up a mail to the
> > helpdesk if yous like.
>
> Yeah, I guess you can ask for the rename and be added to the list of
> users that can push to the repo. At the same time, you can send a patch
> to update the MAINTAINER entry so we can ack it.
I'm actually already in the group ;) Do we want there to be a redirect
from the at91 url to whatever the new one is? Konstantin said that it is
possible, it'll take him about 5 mins to set one up.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-26 17:19 ` Conor Dooley
@ 2024-09-27 8:03 ` Nicolas Ferre
2024-09-30 16:51 ` Conor Dooley
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Ferre @ 2024-09-27 8:03 UTC (permalink / raw)
To: Conor Dooley, Alexandre Belloni; +Cc: claudiu beznea, Daire McNamara, soc
On 26/09/2024 at 19:19, Conor Dooley wrote:
> On Wed, Sep 25, 2024 at 07:59:52PM +0200, Alexandre Belloni wrote:
>> On 25/09/2024 17:16:10+0100, Conor Dooley wrote:
>>> On Wed, Sep 25, 2024 at 10:34:10AM +0300, claudiu beznea wrote:
>>>>
>>>> On 24.09.2024 17:24, Alexandre Belloni wrote:
>>>>> On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
>>>>>> On 24/09/2024 at 13:46, Conor Dooley wrote:
>>>>>>> Hey folks,
>>>>>>>
>>>>>>> I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
>>>>>>> that, but I would like to propose some changes to how the Microchip soc
>>>>>>> support is maintained - mostly affecting the riscv side of things that
>>>>>>> I've been maintaining in my personal tree, alongside other platforms.
>>>>>>> I'd like to propose moving those from my tree, into the at91 tree.
>>>>>> I don't know if the "at91" naming will remain a right designation of what
>>>>>> we're doing in the future, but well, let's stick to it for now.
>>>>>> Some find it a little too much tight to the old Atmel brand...
>>>>>>
>>>>> We could take this opportunity to rename the tree microchip or mchp.
I'm voting for "microchip" so it's very explicit.
>>>> +1
>>> I personally don't care at all about the tree being called at91 or w/e,
>>> but I wouldn't object to a rename to either. I can whip up a mail to the
>>> helpdesk if yous like.
>> Yeah, I guess you can ask for the rename and be added to the list of
>> users that can push to the repo. At the same time, you can send a patch
>> to update the MAINTAINER entry so we can ack it.
> I'm actually already in the group 😉 Do we want there to be a redirect
> from the at91 url to whatever the new one is? Konstantin said that it is
> possible, it'll take him about 5 mins to set one up.
Fine so that we can use whichever URI that we prefer and can continue to
have the link to linux-next established (even if it's easy to modify
with Stephen).
Let's go for this if everybody agrees.
Best regards,
Nicolas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: microchip soc maintainance change proposal
2024-09-27 8:03 ` Nicolas Ferre
@ 2024-09-30 16:51 ` Conor Dooley
0 siblings, 0 replies; 9+ messages in thread
From: Conor Dooley @ 2024-09-30 16:51 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Alexandre Belloni, claudiu beznea, Daire McNamara, soc
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
On Fri, Sep 27, 2024 at 10:03:02AM +0200, Nicolas Ferre wrote:
> On 26/09/2024 at 19:19, Conor Dooley wrote:
> > On Wed, Sep 25, 2024 at 07:59:52PM +0200, Alexandre Belloni wrote:
> > > On 25/09/2024 17:16:10+0100, Conor Dooley wrote:
> > > > On Wed, Sep 25, 2024 at 10:34:10AM +0300, claudiu beznea wrote:
> > > > >
> > > > > On 24.09.2024 17:24, Alexandre Belloni wrote:
> > > > > > On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
> > > > > > > On 24/09/2024 at 13:46, Conor Dooley wrote:
> > > > > > > > Hey folks,
> > > > > > > >
> > > > > > > > I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> > > > > > > > that, but I would like to propose some changes to how the Microchip soc
> > > > > > > > support is maintained - mostly affecting the riscv side of things that
> > > > > > > > I've been maintaining in my personal tree, alongside other platforms.
> > > > > > > > I'd like to propose moving those from my tree, into the at91 tree.
> > > > > > > I don't know if the "at91" naming will remain a right designation of what
> > > > > > > we're doing in the future, but well, let's stick to it for now.
> > > > > > > Some find it a little too much tight to the old Atmel brand...
> > > > > > >
> > > > > > We could take this opportunity to rename the tree microchip or mchp.
>
> I'm voting for "microchip" so it's very explicit.
Cool, I went for that. Sent an email to the helpdesk just a few minutes
ago. I'll send some MAINTAINERS patches once that's complete.
>
> > > > > +1
> > > > I personally don't care at all about the tree being called at91 or w/e,
> > > > but I wouldn't object to a rename to either. I can whip up a mail to the
> > > > helpdesk if yous like.
> > > Yeah, I guess you can ask for the rename and be added to the list of
> > > users that can push to the repo. At the same time, you can send a patch
> > > to update the MAINTAINER entry so we can ack it.
>
> > I'm actually already in the group 😉 Do we want there to be a redirect
> > from the at91 url to whatever the new one is? Konstantin said that it is
> > possible, it'll take him about 5 mins to set one up.
>
> Fine so that we can use whichever URI that we prefer and can continue to
> have the link to linux-next established (even if it's easy to modify with
> Stephen).
>
> Let's go for this if everybody agrees.
>
> Best regards,
> Nicolas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2024-09-30 16:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-24 11:46 microchip soc maintainance change proposal Conor Dooley
2024-09-24 14:05 ` Nicolas Ferre
2024-09-24 14:24 ` Alexandre Belloni
2024-09-25 7:34 ` claudiu beznea
2024-09-25 16:16 ` Conor Dooley
2024-09-25 17:59 ` Alexandre Belloni
2024-09-26 17:19 ` Conor Dooley
2024-09-27 8:03 ` Nicolas Ferre
2024-09-30 16:51 ` Conor Dooley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.