Compilation of the extif driver must depend on
CONFIG_SSB_DRIVER_EXTIF.
Sorry, my fault.
Signed-off-by: Michael Buesch <[email protected]>
--
John, please apply to wireless-dev
Andrew, please apply to -mm after applying the other ssb patches.
diff --git a/drivers/ssb/Makefile b/drivers/ssb/Makefile
index 811343d..bcde58d 100644
--- a/drivers/ssb/Makefile
+++ b/drivers/ssb/Makefile
@@ -7,7 +7,8 @@ ssb-$(CONFIG_SSB_PCMCIAHOST) += pcmcia.
# built-in drivers
ssb-y += driver_chipcommon.o
-ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver_mipscore.o driver_extif.o
+ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver_mipscore.o
+ssb-$(CONFIG_SSB_DRIVER_EXTIF) += driver_extif.o
ssb-$(CONFIG_SSB_DRIVER_PCICORE) += driver_pcicore.o
obj-$(CONFIG_SSB) += ssb.o
--
Greetings Michael.
Michael Buesch a =E9crit :
> On Thursday 09 August 2007, Andrew Morton wrote:
>> Still confused.
>>
>> I pull
>> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wirele=
ss-dev.git#mm-master
>> into -mm. Could be that John puts other things into other trees whi=
ch do
>> not appear in #mm-master, I don't know.
>>
>> Given that you are the developer and maintainer of ssb it is appropr=
iate
>> (especially at this stage) that you run a tree. Just a plain old qu=
ilt
>> tree like
>> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/greg=
kh-01-driver/
>> would be fine.
>>
>> If that tree is relative to some tree which John is running then tha=
t's OK,
>> as long as someone tells me where to get that tree from.
>>
>> Or just merge all of SSB via John's tree. I don't think it matters =
that
>> it's not strictly a wireless thing. =20
>=20
> I can live with doing it through John.
> And as bcm43xx depends on ssb we are doomed to go through
> John's tree.
> So if you always pull John's tree, you'll be up to date with
> wireless + ssb.
>=20
> So if you drop everything b44, bcm43xx and ssb related
> and pull John's tree, it will compile again.
I have compared the branches master and mm-master in John's tree. Only
drivers/ssb/driver_extif.c is present in mm-master, other files from th=
e
same directory and files from include/linux/ssb/* are missing. Also the
changes to drivers/Kconfig and drivers/Makefile are also missing in
mm-master.
So in short there is only one file concerning SSB drivers in the
mm-master branch and it is useless without the other files.
On the other side b44 and bcm43xx drivers that use the SSB drivers are
present in the mm-master branch.
--=20
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [email protected] | [email protected]
`- people.debian.org/~aurel32 | http://www.aurel32.net
mips allmodconfig:
drivers/ssb/driver_pcicore.c: In function `ssb_fixup_pcibridge':
drivers/ssb/driver_pcicore.c:98: error: implicit declaration of function `pcibios_enable_device'
drivers/ssb/driver_pcicore.c: At top level:
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
drivers/ssb/driver_extif.c:125: error: redefinition of 'extif_read32'
drivers/ssb/driver_extif.c:21: error: previous definition of 'extif_read32' was here
drivers/ssb/driver_extif.c:130: error: redefinition of 'extif_write32'
drivers/ssb/driver_extif.c:26: error: previous definition of 'extif_write32' was here
drivers/ssb/driver_extif.c:136: error: redefinition of 'serial_exists'
drivers/ssb/driver_extif.c:32: error: previous definition of 'serial_exists' was here
drivers/ssb/driver_extif.c:150: error: redefinition of 'ssb_extif_serial_init'
drivers/ssb/driver_extif.c:46: error: previous definition of 'ssb_extif_serial_init' was here
drivers/ssb/driver_extif.c:181: error: redefinition of 'ssb_extif_timing_init'
drivers/ssb/driver_extif.c:77: error: previous definition of 'ssb_extif_timing_init' was here
drivers/ssb/driver_extif.c:203: error: redefinition of 'ssb_extif_get_clockcontrol'
drivers/ssb/driver_extif.c:99: error: previous definition of 'ssb_extif_get_clockcontrol' was here
There are a bunch of cross-compiler binaries and instructions at
http://userweb.kernel.org/~akpm/cross-compilers/
On Thursday 09 August 2007 15:53:26 John W. Linville wrote:
> On Wed, Aug 08, 2007 at 04:43:27PM -0700, Andrew Morton wrote:
>
> > I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> > right stuff, all the latest stuff and I don't understand why some is going
> > into git-wireless and some is not.
>
> Once you added ssb patches to -mm, I dropped the ssb stuff from the
> mm-master branch of wireless-dev in hopes of avoiding conflicts.
>
> Ugh, it looks like some new stuff has leaked-through -- I'll get rid
> of it.
I think we decided that it was not a good idea to maintain ssb in
the -mm tree, so I think we'll have to maintain it in a seperate
branch of wireless-dev. Any idea?
--
Greetings Michael.
On Thu, 9 Aug 2007 02:20:32 +0200
Michael Buesch <[email protected]> wrote:
> On Thursday 09 August 2007, Andrew Morton wrote:
> > Still confused.
> >
> > I pull
> > git+ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git#mm-master
> > into -mm. Could be that John puts other things into other trees which do
> > not appear in #mm-master, I don't know.
> >
> > Given that you are the developer and maintainer of ssb it is appropriate
> > (especially at this stage) that you run a tree. Just a plain old quilt
> > tree like
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/
> > would be fine.
> >
> > If that tree is relative to some tree which John is running then that's OK,
> > as long as someone tells me where to get that tree from.
> >
> > Or just merge all of SSB via John's tree. I don't think it matters that
> > it's not strictly a wireless thing.
>
> I can live with doing it through John.
> And as bcm43xx depends on ssb we are doomed to go through
> John's tree.
> So if you always pull John's tree, you'll be up to date with
> wireless + ssb.
>
> So if you drop everything b44, bcm43xx and ssb related
> and pull John's tree, it will compile again.
But I pull John's tree daily, and I don't receive all that ssb stuff. I
assume his is not including it in the #mm-master branch.
> So, my question: How is the mainline merge going to happen?
> Do you handle that, or do I have to generate some split-out
> patches for ssb (I have a script for that).
If the master version of ssb is in one of John's branches then he can ask
Linus to merge that branch into mainline.
Andrew Morton a =E9crit :
> mips allmodconfig:
>=20
> drivers/ssb/driver_pcicore.c: In function `ssb_fixup_pcibridge':
> drivers/ssb/driver_pcicore.c:98: error: implicit declaration of funct=
ion `pcibios_enable_device'
> drivers/ssb/driver_pcicore.c: At top level:
> drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expres=
sion
> drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expres=
sion
Those looks like real errors.
> drivers/ssb/driver_extif.c:125: error: redefinition of 'extif_read32'
> drivers/ssb/driver_extif.c:21: error: previous definition of 'extif_r=
ead32' was here
> drivers/ssb/driver_extif.c:130: error: redefinition of 'extif_write32=
'
> drivers/ssb/driver_extif.c:26: error: previous definition of 'extif_w=
rite32' was here
> drivers/ssb/driver_extif.c:136: error: redefinition of 'serial_exists=
'
> drivers/ssb/driver_extif.c:32: error: previous definition of 'serial_=
exists' was here
> drivers/ssb/driver_extif.c:150: error: redefinition of 'ssb_extif_ser=
ial_init'
> drivers/ssb/driver_extif.c:46: error: previous definition of 'ssb_ext=
if_serial_init' was here
> drivers/ssb/driver_extif.c:181: error: redefinition of 'ssb_extif_tim=
ing_init'
> drivers/ssb/driver_extif.c:77: error: previous definition of 'ssb_ext=
if_timing_init' was here
> drivers/ssb/driver_extif.c:203: error: redefinition of 'ssb_extif_get=
_clockcontrol'
> drivers/ssb/driver_extif.c:99: error: previous definition of 'ssb_ext=
if_get_clockcontrol' was here
>=20
All the versions of driver_extif.c I have seen have at maximum around
100 lines. It looks like a patch applied twice, which make the same cod=
e
appearing twice in the .c file.
--=20
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [email protected] | [email protected]
`- people.debian.org/~aurel32 | http://www.aurel32.net
On Thursday 09 August 2007 16:01:57 John W. Linville wrote:
> Michael, as you mentioned I'm (still) planning a wireless-dev rebase.
> If you could send me a clean "add ssb to mainline" patchset to seed
> a new ssb branch, that would be great.
Sure, give me a second or two.
> I apologize for the confusion!
It's really me who created the mess :)
But we got a lot of good fixes out of it, so it was worth it.
--
Greetings Michael.
On Wed, Aug 08, 2007 at 04:43:27PM -0700, Andrew Morton wrote:
> I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> right stuff, all the latest stuff and I don't understand why some is going
> into git-wireless and some is not.
Once you added ssb patches to -mm, I dropped the ssb stuff from the
mm-master branch of wireless-dev in hopes of avoiding conflicts.
Ugh, it looks like some new stuff has leaked-through -- I'll get rid
of it.
John
--
John W. Linville
[email protected]
On Thu, 09 Aug 2007 01:13:40 +0200
Aurelien Jarno <[email protected]> wrote:
> Andrew Morton a __crit :
> > mips allmodconfig:
> >
> > drivers/ssb/driver_pcicore.c: In function `ssb_fixup_pcibridge':
> > drivers/ssb/driver_pcicore.c:98: error: implicit declaration of function `pcibios_enable_device'
> > drivers/ssb/driver_pcicore.c: At top level:
> > drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
> > drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
>
> Those looks like real errors.
They seems to have gone away after I droped the duplicated patches.
> > drivers/ssb/driver_extif.c:125: error: redefinition of 'extif_read32'
> > drivers/ssb/driver_extif.c:21: error: previous definition of 'extif_read32' was here
> > drivers/ssb/driver_extif.c:130: error: redefinition of 'extif_write32'
> > drivers/ssb/driver_extif.c:26: error: previous definition of 'extif_write32' was here
> > drivers/ssb/driver_extif.c:136: error: redefinition of 'serial_exists'
> > drivers/ssb/driver_extif.c:32: error: previous definition of 'serial_exists' was here
> > drivers/ssb/driver_extif.c:150: error: redefinition of 'ssb_extif_serial_init'
> > drivers/ssb/driver_extif.c:46: error: previous definition of 'ssb_extif_serial_init' was here
> > drivers/ssb/driver_extif.c:181: error: redefinition of 'ssb_extif_timing_init'
> > drivers/ssb/driver_extif.c:77: error: previous definition of 'ssb_extif_timing_init' was here
> > drivers/ssb/driver_extif.c:203: error: redefinition of 'ssb_extif_get_clockcontrol'
> > drivers/ssb/driver_extif.c:99: error: previous definition of 'ssb_extif_get_clockcontrol' was here
> >
>
> All the versions of driver_extif.c I have seen have at maximum around
> 100 lines. It looks like a patch applied twice, which make the same code
> appearing twice in the .c file.
Yeah. I dropped a bunch of things which seemed to help.
I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
right stuff, all the latest stuff and I don't understand why some is going
into git-wireless and some is not.
I'd prefer to be dumbly pulling a tree which Michael controls rather than
trying to master it all in -mm, if possible. A git tree or a quilt tree in
some open dir somewhere would suit?
On Wed, 8 Aug 2007 16:43:27 -0700
Andrew Morton <[email protected]> wrote:
> I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> right stuff, all the latest stuff and I don't understand why some is going
> into git-wireless and some is not.
So I dropped the duplicated patch, then a few other things which appeared to depend
on it and now...
drivers/ssb/main.c: In function 'ssb_clockspeed':
drivers/ssb/main.c:823: error: implicit declaration of function 'ssb_extif_get_clockcontrol'
So I shall now drop use-ssb-extif-in-ssb-mips-core-driver.patch
But the confidence level is really low. Michael, I think it's time to
do a reset, drop everything and start again. I trust you have a copy
of everything. You'll be cc'ed as they drop..
On Thursday 09 August 2007, Andrew Morton wrote:
> Still confused.
>
> I pull
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git#mm-master
> into -mm. Could be that John puts other things into other trees which do
> not appear in #mm-master, I don't know.
>
> Given that you are the developer and maintainer of ssb it is appropriate
> (especially at this stage) that you run a tree. Just a plain old quilt
> tree like
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/
> would be fine.
>
> If that tree is relative to some tree which John is running then that's OK,
> as long as someone tells me where to get that tree from.
>
> Or just merge all of SSB via John's tree. I don't think it matters that
> it's not strictly a wireless thing.
I can live with doing it through John.
And as bcm43xx depends on ssb we are doomed to go through
John's tree.
So if you always pull John's tree, you'll be up to date with
wireless + ssb.
So if you drop everything b44, bcm43xx and ssb related
and pull John's tree, it will compile again.
So, my question: How is the mainline merge going to happen?
Do you handle that, or do I have to generate some split-out
patches for ssb (I have a script for that).
On Thursday 09 August 2007 02:28:43 Andrew Morton wrote:
> On Thu, 9 Aug 2007 02:20:32 +0200
> Michael Buesch <[email protected]> wrote:
>
> > On Thursday 09 August 2007, Andrew Morton wrote:
> > > Still confused.
> > >
> > > I pull
> > > git+ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git#mm-master
> > > into -mm. Could be that John puts other things into other trees which do
> > > not appear in #mm-master, I don't know.
> > >
> > > Given that you are the developer and maintainer of ssb it is appropriate
> > > (especially at this stage) that you run a tree. Just a plain old quilt
> > > tree like
> > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/
> > > would be fine.
> > >
> > > If that tree is relative to some tree which John is running then that's OK,
> > > as long as someone tells me where to get that tree from.
> > >
> > > Or just merge all of SSB via John's tree. I don't think it matters that
> > > it's not strictly a wireless thing.
> >
> > I can live with doing it through John.
> > And as bcm43xx depends on ssb we are doomed to go through
> > John's tree.
> > So if you always pull John's tree, you'll be up to date with
> > wireless + ssb.
> >
> > So if you drop everything b44, bcm43xx and ssb related
> > and pull John's tree, it will compile again.
>
> But I pull John's tree daily, and I don't receive all that ssb stuff. I
> assume his is not including it in the #mm-master branch.
>
> > So, my question: How is the mainline merge going to happen?
> > Do you handle that, or do I have to generate some split-out
> > patches for ssb (I have a script for that).
>
> If the master version of ssb is in one of John's branches then he can ask
> Linus to merge that branch into mainline.
Ok, I see. A rebase of wireless-dev is needed anyway, so this
should not be a problem.
So John, when you rebase your tree, can you make a seperate branch
for the ssb stuff? I can supply you with the initial broken out
patch to start it.
--
Greetings Michael.
On Thu, 9 Aug 2007 02:02:19 +0200
Michael Buesch <[email protected]> wrote:
> > I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> > right stuff, all the latest stuff and I don't understand why some is going
> > into git-wireless and some is not.
>
> Everything is going into git-wireless.
> git-wireless contains latest ssb. _but_ John complained
> about that. And he is right. SSB is not strictly wireless core.
> So I thought it was best to get ssb into mainline as soon as
> possible. So -mm is really the way to go into mainline.
> My plan was to merge mainline with the next merge window.
>
> > I'd prefer to be dumbly pulling a tree which Michael controls rather than
> > trying to master it all in -mm, if possible. A git tree or a quilt tree in
> > some open dir somewhere would suit?
>
> It's a bit difficult, as bcm43xx depends on it. Which again depends
> on the wireless tree. :)
> So basically we are stuck with maintaining it in wireless-dev.
>
> I don't know what your policy is with pulling from wireless-dev.
> So wireless-dev currently contains latest SSB. So if you pull from
> wireless-dev, you'll also get latest SSB. Though, if we want to
> merge SSB soon, we need it broken-out. That is what I was trying
> to do.
Yeah, after dropping all the ssb stuff, my build is now busted because
the bit of git-wireless which I have wants SSB bits for BCM43XX.
argh. I'll try disabling b44 so I can get a release out the door.
Please, just give me some internally-consistent tree(s) to pull??
Thanks.
On Thu, 9 Aug 2007 02:02:19 +0200
Michael Buesch <[email protected]> wrote:
> > I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> > right stuff, all the latest stuff and I don't understand why some is going
> > into git-wireless and some is not.
>
> Everything is going into git-wireless.
> git-wireless contains latest ssb. _but_ John complained
> about that. And he is right. SSB is not strictly wireless core.
> So I thought it was best to get ssb into mainline as soon as
> possible. So -mm is really the way to go into mainline.
> My plan was to merge mainline with the next merge window.
>
> > I'd prefer to be dumbly pulling a tree which Michael controls rather than
> > trying to master it all in -mm, if possible. A git tree or a quilt tree in
> > some open dir somewhere would suit?
>
> It's a bit difficult, as bcm43xx depends on it. Which again depends
> on the wireless tree. :)
> So basically we are stuck with maintaining it in wireless-dev.
>
> I don't know what your policy is with pulling from wireless-dev.
> So wireless-dev currently contains latest SSB. So if you pull from
> wireless-dev, you'll also get latest SSB. Though, if we want to
> merge SSB soon, we need it broken-out. That is what I was trying
> to do.
Still confused.
I pull
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git#mm-master
into -mm. Could be that John puts other things into other trees which do
not appear in #mm-master, I don't know.
Given that you are the developer and maintainer of ssb it is appropriate
(especially at this stage) that you run a tree. Just a plain old quilt
tree like
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/
would be fine.
If that tree is relative to some tree which John is running then that's OK,
as long as someone tells me where to get that tree from.
Or just merge all of SSB via John's tree. I don't think it matters that
it's not strictly a wireless thing.
> I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> right stuff, all the latest stuff and I don't understand why some is going
> into git-wireless and some is not.
Everything is going into git-wireless.
git-wireless contains latest ssb. _but_ John complained
about that. And he is right. SSB is not strictly wireless core.
So I thought it was best to get ssb into mainline as soon as
possible. So -mm is really the way to go into mainline.
My plan was to merge mainline with the next merge window.
> I'd prefer to be dumbly pulling a tree which Michael controls rather than
> trying to master it all in -mm, if possible. A git tree or a quilt tree in
> some open dir somewhere would suit?
It's a bit difficult, as bcm43xx depends on it. Which again depends
on the wireless tree. :)
So basically we are stuck with maintaining it in wireless-dev.
I don't know what your policy is with pulling from wireless-dev.
So wireless-dev currently contains latest SSB. So if you pull from
wireless-dev, you'll also get latest SSB. Though, if we want to
merge SSB soon, we need it broken-out. That is what I was trying
to do.
On Wed, Aug 08, 2007 at 05:13:30PM -0700, Andrew Morton wrote:
> Yeah, after dropping all the ssb stuff, my build is now busted because
> the bit of git-wireless which I have wants SSB bits for BCM43XX.
>
> argh. I'll try disabling b44 so I can get a release out the door.
> Please, just give me some internally-consistent tree(s) to pull??
I'm sorry, I seem to have made a hash of this. I was trying to get
out of the way of Michael's ssb stuff going to -mm, but instead I
seem to have confused things.
Based on the other messages in this thread, I'm going to recreate
the mm-master branch to include the ssb stuff so Andrew can get on
with his life.
Michael, as you mentioned I'm (still) planning a wireless-dev rebase.
If you could send me a clean "add ssb to mainline" patchset to seed
a new ssb branch, that would be great.
I apologize for the confusion!
John
--
John W. Linville
[email protected]
On Thu, Aug 09, 2007 at 04:08:43PM +0200, Michael Buesch wrote:
> On Thursday 09 August 2007 15:53:26 John W. Linville wrote:
> > On Wed, Aug 08, 2007 at 04:43:27PM -0700, Andrew Morton wrote:
> >
> > > I'm hopelessly confused by the ssb stuff. I'm not sure if I have all the
> > > right stuff, all the latest stuff and I don't understand why some is going
> > > into git-wireless and some is not.
> >
> > Once you added ssb patches to -mm, I dropped the ssb stuff from the
> > mm-master branch of wireless-dev in hopes of avoiding conflicts.
> >
> > Ugh, it looks like some new stuff has leaked-through -- I'll get rid
> > of it.
>
> I think we decided that it was not a good idea to maintain ssb in
> the -mm tree, so I think we'll have to maintain it in a seperate
> branch of wireless-dev. Any idea?
Responded later in the thread -- you've probably seen them by the
time you get this... :-)
John
--
John W. Linville
[email protected]