Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push
- To: debian-68k@lists.debian.org
- Cc: debian-68k@lists.debian.org
- Subject: Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push
- From: "Frank P. Szymanski" <frank_peter.szymanski@freenet.de>
- Date: Wed, 05 Nov 2008 21:14:30 +0100
- Message-id: <[🔎] 4911FEA6.3030304@freenet.de>
- In-reply-to: <alpine.DEB.1.00.0810302112230.572@zirkon.biophys.uni-duesseldorf.de>
- References: <20080903073629.GD4104@cs181140183.pp.htv.fi> <20080916231907.GA16451@marenka.net> <48E3B617.4050904@freenet.de> <alpine.DEB.1.00.0810021020150.1527@zirkon.biophys.uni-duesseldorf.de> <48E7A5D6.3020903@freenet.de> <alpine.DEB.1.00.0810050511390.32397@zirkon.biophys.uni-duesseldorf.de> <48EB266E.3070708@freenet.de> <48ECE5DA.2090302@freenet.de> <alpine.DEB.1.00.0810090428170.19738@zirkon.biophys.uni-duesseldorf.de> <48EF9ECE.40505@freenet.de> <alpine.DEB.1.00.0810110330110.10175@zirkon.biophys.uni-duesseldorf.de> <48F0ECC9.6050902@freenet.de> <alpine.DEB.1.00.0810122141540.26363@zirkon.biophys.uni-duesseldorf.de> <48F679D1.60709@freenet.de> <alpine.DEB.1.00.0810281959240.8885@zirkon.biophys.uni-duesseldorf.de> <49085A7A.3030006@freenet.de> <alpine.DEB.1.00.0810292124320.22819@zirkon.biophys.uni-duesseldorf.de> <4909C12C.4020009@freenet.de> <Pine.LNX.4.64.0810301800270.30686@anakin> <alpine.DEB.1.00.0810302112230.572@zirkon.biophys.uni-duesseldorf.de>
Hi,
> > The reasons for this are:
> > EtherNEC needs to be rewritten based on the current ne.c code. I'm
not sure if
> > ...
> > processing before the ethernet device has been opened.
> > I did recently rewrite the EtherNAT driver based on the current
smc91x.c one.
> > ...
> > work out.
> >
> > SCSI needs to be rewritten and merged with the Mac 5380 driver (and
perhaps a
> > ...
> > case. Given that the lock handling of IDE may be dodgy, that scares
me a bit.
> > Reasons enough for you?
Oops. It was not my intention to offend anyone. Excuses if I did.
I just thought that the reasons were more or less because of the process
of submitting patches to linux/m68k. Now I see that it were just
technical reasons. Thanks for explaining.
> > I'll focus on getting SCSI fixed, first and foremost. First stab at
this is
> > attached (not fudging with the timeouts, but failing the request
instead if the
> > lock cannot be obtained).
That would be great because in that case I could start to test the
installation procedure again.
Regards,
Frank
Reply to: