ssb: Make extif driver compilation depend on extif config
PATCH 1/1 ssb: Make extif driver compilation depend on extif config
Compilation of the extif driver must depend onCONFIG_SSB_DRIVER_EXTIF.
Sorry, my fault.
--
John, please apply to wireless-dev
Andrew, please apply to -mm after applying the other ssb patches.
drivers/ssb/Makefile +2 -1
@@ -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
Signature · 1 line
Greetings Michael.
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/
Andrew Morton a =E9crit :
Quoted 4 lines
mips allmodconfig:
=20drivers/ssb/driver_pcicore.c: In function `ssb_fixup_pcibridge':drivers/ssb/driver_pcicore.c:98: error: implicit declaration of funct=
ion `pcibios_enable_device'
Quoted 2 lines
drivers/ssb/driver_pcicore.c: At top level:drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expres=
sion
Quoted 1 line
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expres=
sion
Those looks like real errors.
Quoted 2 lines
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
Quoted 1 line
drivers/ssb/driver_extif.c:130: error: redefinition of 'extif_write32=
'
Quoted 1 line
drivers/ssb/driver_extif.c:26: error: previous definition of 'extif_w=
rite32' was here
Quoted 1 line
drivers/ssb/driver_extif.c:136: error: redefinition of 'serial_exists=
'
Quoted 1 line
drivers/ssb/driver_extif.c:32: error: previous definition of 'serial_=
exists' was here
Quoted 1 line
drivers/ssb/driver_extif.c:150: error: redefinition of 'ssb_extif_ser=
ial_init'
Quoted 1 line
drivers/ssb/driver_extif.c:46: error: previous definition of 'ssb_ext=
if_serial_init' was here
Quoted 1 line
drivers/ssb/driver_extif.c:181: error: redefinition of 'ssb_extif_tim=
ing_init'
Quoted 1 line
drivers/ssb/driver_extif.c:77: error: previous definition of 'ssb_ext=
if_timing_init' was here
Quoted 1 line
drivers/ssb/driver_extif.c:203: error: redefinition of 'ssb_extif_get=
_clockcontrol'
Quoted 1 line
drivers/ssb/driver_extif.c:99: error: previous definition of 'ssb_ext=
if_get_clockcontrol' was here
Quoted 1 line
=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 | www.aurel32.net
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · On Thu, 09 Aug 2007 01:13:40 +0200 Aurelien Jarno <[email protected]> wrote:
Andrew Morton a
__crit:Quoted 7 lines
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 expressiondrivers/ssb/driver_pcicore.c:278: warning: integer overflow in expressionThose looks like real errors.
They seems to have gone away after I droped the duplicated patches.
Quoted 14 lines
Quoted 4 lines
drivers/ssb/driver_extif.c:125: error: redefinition of 'extif_read32'drivers/ssb/driver_extif.c:21: error: previous definition of 'extif_read32' was heredrivers/ssb/driver_extif.c:130: error: redefinition of 'extif_write32'drivers/ssb/driver_extif.c:26: error: previous definition of 'extif_write32' was hereQuoted 9 lines
drivers/ssb/driver_extif.c:136: error: redefinition of 'serial_exists'drivers/ssb/driver_extif.c:32: error: previous definition of 'serial_exists' was heredrivers/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 heredrivers/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 heredrivers/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
Quoted 3 lines
All the versions of
driver_extif.cI 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?
Quoted 3 lines · On Wed, 8 Aug 2007 16:43:27 -0700 Andrew Morton <[email protected]>…
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..
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 19 lines · On Thu, 9 Aug 2007 02:02:19 +0200 Michael Buesch <[email protected]> wrote:
Quoted 3 lines
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.Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 13 lines · Andrew Morton
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.
Quoted 5 lines
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).
Quoted 20 lines · On Thu, 9 Aug 2007 02:20:32 +0200 Michael Buesch <[email protected]> wrote:
Quoted 13 lines · Andrew Morton
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.Quoted 5 lines
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.
Quoted 8 lines
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.
Quoted 3 lines
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.
Quoted 35 lines · On Thursday 09 August 2007 02:28:43 Andrew Morton wrote:
Quoted 20 lines · On Thu, 9 Aug 2007 02:20:32 +0200 Michael Buesch <[email protected]> wrote:
Quoted 13 lines · Andrew Morton
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.Quoted 5 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Signature · 1 line
Greetings Michael.
Michael Buesch a =E9crit :
Quoted 5 lines · Andrew Morton
Quoted 4 lines
Still confused.
I pull git+ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wirele=
ss-dev.git#mm-master
Quoted 1 line
Quoted 1 line
into -mm. Could be that John puts other things into other trees whi=
ch do
Quoted 3 lines
Quoted 3 lines
not appear in #mm-master, I don't know.
Given that you are the developer and maintainer of ssb it is appropr=
iate
Quoted 1 line
Quoted 1 line
(especially at this stage) that you run a tree. Just a plain old qu=
ilt
Quoted 2 lines
Quoted 2 lines
tree like
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/greg=
kh-01-driver/
Quoted 3 lines
Quoted 3 lines
would be fine.
If that tree is relative to some tree which John is running then tha=
t's OK,
Quoted 3 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 1 line
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 | www.aurel32.net
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 19 lines · On Thu, 9 Aug 2007 02:02:19 +0200 Michael Buesch <[email protected]> wrote:
Quoted 3 lines
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.Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 5 lines · Andrew Morton
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
Signature · 2 lines
John W. Linville [email protected]
Quoted 3 lines · 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.
Quoted 1 line
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.
Signature · 1 line
Greetings Michael.
Quoted 3 lines · Andrew Morton
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
Signature · 2 lines
John W. Linville [email protected]
Quoted 11 lines · On Thursday 09 August 2007 15:53:26 John W. Linville wrote:
Quoted 3 lines · Andrew Morton
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?
Signature · 1 line
Greetings Michael.
Quoted 10 lines · Michael Buesch
Quoted 9 lines · On Thursday 09 August 2007 15:53:26 John W. Linville wrote:
Quoted 3 lines · Andrew Morton
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.
Quoted 6 lines
Quoted 2 lines
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
Signature · 2 lines
John W. Linville [email protected]