platform/board removal update

platform/board removal update

[Kumar Gala]

All,

I'm going to be sending a series of patches to remove the following  
board/platforms (as discussed earlier):

adir
ash
beech
cedar
ep405
k2
mcpn765
menf1
oak
pcore
rainier
redwood
sm850
spd823ts

The following board/platforms are currently not building:
apus
gemini
lite5200
prpmc750
radstone_ppc7d
rpxcllf
TQM8260

At OLS, Paul and the various sub-arch maintainers (in attendance)  
discussed that if the set of board/platforms that are not building  
are not fixed by the release of 2.6.15 we will be removing support  
for them.  Some of the build issues are trivial and I may look at  
fixing them myself.  For all of the systems that I dont fix I'll be  
sending a patch marking them BROKEN in the Kconfig file.  If these  
systems are still BROKEN after 2.6.15 we will be removing them.

- kumar

Re: platform/board removal update

[Kumar Gala]

> The following board/platforms are currently not building:
> apus
> gemini
> lite5200

lite5200 seems to be running into a pci.h issue between asm-ppc and  
linux.  Sent patch to akpm and gregkh to look at.

> prpmc750
> radstone_ppc7d

I've fixed up prpmc750 (include issue) and radstone_ppc7d (defconfig  
update)

> rpxcllf
> TQM8260

the TQM8260 needs a slightly reorder of includes.  I'll push this  
change today.

All the other systems (apus, gemini, rpxcllf) were more effort than I  
was wanting to deal with.  I'll be sending a patch to list them as  
CONFIG_BROKEN and let the various board maintainers look at fixing  
them up.

- kumar

Re: platform/board removal update

[Dan Malek]

On Jul 26, 2005, at 9:01 AM, Kumar Gala wrote:

> All the other systems (apus, gemini, rpxcllf) were more effort than I 
> was wanting to deal with.

Why?  The rpxcllf worked not long ago.  What happened to the courtesy of
the past when such updates were applied to all platforms such they
would at least build?  After such changes, if there is still a problem, 
the
person should at least contact the maintainer to get it resolved.  I 
don't
appreciate being demanded to fix something within a short period of
time that someone else broke or else everything I've done in the past
will be discarded.

Thanks.


	-- Dan

Re: platform/board removal update

[Kumar Gala]

On Jul 26, 2005, at 9:35 AM, Dan Malek wrote:

>
> On Jul 26, 2005, at 9:01 AM, Kumar Gala wrote:
>
>
>> All the other systems (apus, gemini, rpxcllf) were more effort than I
>> was wanting to deal with.
>>
>
> Why?  The rpxcllf worked not long ago.  What happened to the  
> courtesy of
> the past when such updates were applied to all platforms such they
> would at least build?  After such changes, if there is still a  
> problem,
> the
> person should at least contact the maintainer to get it resolved.  I
> don't
> appreciate being demanded to fix something within a short period of
> time that someone else broke or else everything I've done in the past
> will be discarded.

Well, I think its reasonable amount of time.  We are talking about  
4-6 months between now and when a 2.6.15 is likely to get released.   
I'm not 100% sure who broken rpxcllf, but the issue seems to be with  
the 8xx_io/fec.c driver so it should be resolved with panto's updated  
driver.

I'm just trying to get us back into a sane state and hopefully we  
will regress building of all our defconfigs more often to catch  
things sooner.

- kumar

Re: platform/board removal update

[Marcelo Tosatti]

On Tue, Jul 26, 2005 at 09:43:43AM -0500, Kumar Gala wrote:
> 
> On Jul 26, 2005, at 9:35 AM, Dan Malek wrote:
> 
> >
> >On Jul 26, 2005, at 9:01 AM, Kumar Gala wrote:
> >
> >
> >>All the other systems (apus, gemini, rpxcllf) were more effort than I
> >>was wanting to deal with.
> >>
> >
> >Why?  The rpxcllf worked not long ago.  What happened to the  
> >courtesy of
> >the past when such updates were applied to all platforms such they
> >would at least build?  After such changes, if there is still a  
> >problem,
> >the
> >person should at least contact the maintainer to get it resolved.  I
> >don't
> >appreciate being demanded to fix something within a short period of
> >time that someone else broke or else everything I've done in the past
> >will be discarded.
> 
> Well, I think its reasonable amount of time.  We are talking about  
> 4-6 months between now and when a 2.6.15 is likely to get released.   
> I'm not 100% sure who broken rpxcllf, but the issue seems to be with  
> the 8xx_io/fec.c driver so it should be resolved with panto's updated  
> driver.

8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
that its working fine. 

The fix will be pushed upstream ASAP.

BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to 
test all supported PHY's on the new driver.

Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
by Panto's driver again? We should build a list of those and ask around for
testers.

> I'm just trying to get us back into a sane state and hopefully we  
> will regress building of all our defconfigs more often to catch  
> things sooner.

Re: platform/board removal update

[Dan Malek]

On Jul 26, 2005, at 6:05 AM, Marcelo Tosatti wrote:

> 8xx_io/fec.c is still using v2.4's workqueue infrastructure but other 
> than
> that its working fine.

I talked to panto about this earlier today.

> The fix will be pushed upstream ASAP.

That's OK, I'm just glad I know what it is :-)

> BTW, we should schedule 8xx_io/fec.c for removal, but before that we 
> ought to
> test all supported PHY's on the new driver.

It will be around in old kernels if we need it for reference.

Thanks, and good luck with the new job :-)

	-- Dan

Re: platform/board removal update

[Marcelo Tosatti]

On Tue, Jul 26, 2005 at 06:14:00PM -0400, Dan Malek wrote:
> 
> On Jul 26, 2005, at 6:05 AM, Marcelo Tosatti wrote:
> 
> >8xx_io/fec.c is still using v2.4's workqueue infrastructure but other 
> >than
> >that its working fine.
> 
> I talked to panto about this earlier today.
> 
> >The fix will be pushed upstream ASAP.
> 
> That's OK, I'm just glad I know what it is :-)
> 
> >BTW, we should schedule 8xx_io/fec.c for removal, but before that we 
> >ought to
> >test all supported PHY's on the new driver.
> 
> It will be around in old kernels if we need it for reference.

Indeed.

> Thanks, and good luck with the new job :-)

Thanks! Be prepared to handle my questions :-)

Re: platform/board removal update

['Aristeu Sergio Rozanski Filho']

> 8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
> that its working fine. 
> 
> The fix will be pushed upstream ASAP.
> 
> BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to 
> test all supported PHY's on the new driver.
> 
> Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
> by Panto's driver again? We should build a list of those and ask around for
> testers.
I think that with Andy Fleming's PHY abstraction layer, the best thing to be done
is change fec_8xx to use this abstraction layer and then look for
testers. what you think?

-- 
Aristeu

Re: platform/board removal update

[Pantelis Antoniou]

'Aristeu Sergio Rozanski Filho' wrote:
>>8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
>>that its working fine. 
>>
>>The fix will be pushed upstream ASAP.
>>
>>BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to 
>>test all supported PHY's on the new driver.
>>
>>Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
>>by Panto's driver again? We should build a list of those and ask around for
>>testers.
> 
> I think that with Andy Fleming's PHY abstraction layer, the best thing to be done
> is change fec_8xx to use this abstraction layer and then look for
> testers. what you think?
> 

There's a fs_enet driver in the works which will use Andy's work.

Please refrain from doing anything :)

Regards

Pantelis

Re: platform/board removal update

['Aristeu Sergio Rozanski Filho']

> There's a fs_enet driver in the works which will use Andy's work.
> 
> Please refrain from doing anything :)
great! 8)

-- 
Aristeu