Discussion:
[PATCH] fix prism2_cs.c to compile on 2.6.28
Tormod Volden
2009-01-08 23:34:58 UTC
Permalink
This is untested, but at least it compiles.
* pcmcia_get_configuration_info() was removed
(http://www.mail-archive.com/linux-***@lists.infradead.org/msg01909.html)
* dropped an unused argument from pcmcia_parse_tuple()
(http://www.mail-archive.com/linux-***@lists.infradead.org/msg01915.html)
* CS_SUCCESS was removed
(http://www.mail-archive.com/linux-***@lists.infradead.org/msg01890.html)

---
src/prism2/driver/prism2_cs.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/src/prism2/driver/prism2_cs.c b/src/prism2/driver/prism2_cs.c
index 2ba1176..aa05cca 100644
--- a/src/prism2/driver/prism2_cs.c
+++ b/src/prism2/driver/prism2_cs.c
@@ -4,6 +4,10 @@
#include "prism2mib.c"
#include "prism2sta.c"

+#if !defined(CS_SUCCESS)
+#define CS_SUCCESS 0x00
+#endif
+
#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,21) )
#if (WLAN_CPU_FAMILY == WLAN_Ix86)
#ifndef CONFIG_ISA
@@ -357,7 +361,11 @@ static int prism2_cs_probe(struct pcmcia_device *pdev)
tuple.TupleOffset = 0;
CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(pdev, &tuple));
CS_CHECK(GetTupleData, pcmcia_get_tuple_data(pdev, &tuple));
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
CS_CHECK(ParseTuple, pcmcia_parse_tuple(pdev, &tuple, parse));
+#else
+ CS_CHECK(ParseTuple, pcmcia_parse_tuple(&tuple, parse));
+#endif
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,16)
pdev->conf.ConfigBase = parse->config.base;
pdev->conf.Present = parse->config.rmask[0];
@@ -367,8 +375,10 @@ static int prism2_cs_probe(struct pcmcia_device *pdev)

link->conf.Vcc = socketconf.Vcc;
#endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
CS_CHECK(GetConfigurationInfo,
pcmcia_get_configuration_info(pdev, &socketconf));
+#endif

tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(pdev, &tuple));
@@ -377,7 +387,11 @@ static int prism2_cs_probe(struct pcmcia_device *pdev)
CFG_CHECK(GetTupleData,
pcmcia_get_tuple_data(pdev, &tuple));
CFG_CHECK(ParseTuple,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
pcmcia_parse_tuple(pdev, &tuple, parse));
+#else
+ pcmcia_parse_tuple(&tuple, parse));
+#endif

if (cfg->flags & CISTPL_CFTABLE_DEFAULT)
dflt = *cfg;
@@ -908,7 +922,11 @@ void prism2sta_config(dev_link_t *link)
tuple.TupleOffset = 0;
CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(handle, &tuple));
CS_CHECK(GetTupleData, pcmcia_get_tuple_data(handle, &tuple));
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
CS_CHECK(ParseTuple, pcmcia_parse_tuple(handle, &tuple, &parse));
+#else
+ CS_CHECK(ParseTuple, pcmcia_parse_tuple(&tuple, &parse));
+#endif

link->conf.ConfigBase = parse.config.base;
link->conf.Present = parse.config.rmask[0];
@@ -926,7 +944,11 @@ void prism2sta_config(dev_link_t *link)
while (1) {
cistpl_cftable_entry_t *cfg = &(parse.cftable_entry);
CFG_CHECK(GetTupleData, pcmcia_get_tuple_data(handle, &tuple));
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
CFG_CHECK(ParseTuple, pcmcia_parse_tuple(handle, &tuple, &parse));
+#else
+ CFG_CHECK(ParseTuple, pcmcia_parse_tuple(&tuple, &parse));
+#endif

if (cfg->index == 0) goto next_entry;
link->conf.ConfigIndex = cfg->index;
--
1.5.6.3
Pavel Roskin
2009-01-09 00:02:15 UTC
Permalink
Post by Tormod Volden
This is untested, but at least it compiles.
* pcmcia_get_configuration_info() was removed
Maybe we should stop developing a standalone package and concentrate on
the staging driver and the tools?
Post by Tormod Volden
+#if !defined(CS_SUCCESS)
I think #ifndef is more readable and common.
Post by Tormod Volden
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
CS_CHECK(ParseTuple, pcmcia_parse_tuple(pdev, &tuple, parse));
+#else
+ CS_CHECK(ParseTuple, pcmcia_parse_tuple(&tuple, parse));
+#endif
Since it's used more than once, maybe it's better to redefine
pcmcia_parse_tuple() for older kernels? Something like:

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
#define pcmcia_parse_tuple(_tuple, _parse) \
pcmcia_parse_tuple(pdev, _tuple, _parse)
#endif

It's not very nice to use local variables in macros. On the other hand,
coding for the new API usually keeps the code more maintainable.

Actually, you'll need to adjust wlan_compat.h so that Linux 2.4 support
is preserved. Maybe the changes should be in that header.
--
Regards,
Pavel Roskin
Tormod Volden
2009-01-10 23:15:47 UTC
Permalink
Post by Pavel Roskin
Post by Tormod Volden
This is untested, but at least it compiles.
* pcmcia_get_configuration_info() was removed
Maybe we should stop developing a standalone package and concentrate on
the staging driver and the tools?
Hi Pavel,
Thanks for your comments! I fully agree on the "concentrate" part.
However, until we have a stable, tested version in a released kernel,
we need something to give our users (or distributions) who use 2.6.28.
Granted, few or no people uses the prism2_cs part, but I thought it
would be nice if the whole package could compile at least.
Post by Pavel Roskin
Post by Tormod Volden
+#if !defined(CS_SUCCESS)
I think #ifndef is more readable and common.
Absolutely.
Post by Pavel Roskin
Since it's used more than once, maybe it's better to redefine
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
#define pcmcia_parse_tuple(_tuple, _parse) \
pcmcia_parse_tuple(pdev, _tuple, _parse)
#endif
It's not very nice to use local variables in macros. On the other hand,
coding for the new API usually keeps the code more maintainable.
I think it is really bad to have local variables hidden in a macro. So
I'll do it the other way around. This sacrifices "coding for the new
API", but back to your first point, maybe we don't care so much :)
Post by Pavel Roskin
Actually, you'll need to adjust wlan_compat.h so that Linux 2.4 support
is preserved. Maybe the changes should be in that header.
I'll move it to wlan_compat.h as far as possible. But technically,
does one "need" to put it in there?

Thanks,
Tormod

---
This is untested, but at least it compiles.
* pcmcia_get_configuration_info() was removed
(http://www.mail-archive.com/linux-***@lists.infradead.org/msg01909.html)
* dropped an unused argument from pcmcia_parse_tuple()
(http://www.mail-archive.com/linux-***@lists.infradead.org/msg01915.html)
* CS_SUCCESS was removed
(http://www.mail-archive.com/linux-***@lists.infradead.org/msg01890.html)

---
src/include/wlan/wlan_compat.h | 9 +++++++++
src/prism2/driver/prism2_cs.c | 2 ++
2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/src/include/wlan/wlan_compat.h b/src/include/wlan/wlan_compat.h
index d920318..b7e4ebe 100644
--- a/src/include/wlan/wlan_compat.h
+++ b/src/include/wlan/wlan_compat.h
@@ -715,6 +715,15 @@ typedef u32 pm_message_t;
CardServices(ReportError, handle, err)
#endif

+#ifndef CS_SUCCESS
+#define CS_SUCCESS 0x00
+#endif
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
+#define pcmcia_parse_tuple(_pdev, _tuple, _parse) \
+ pcmcia_parse_tuple(_tuple, _parse)
+#endif
+
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20))
#define round_jiffies(a) (a)
#endif
diff --git a/src/prism2/driver/prism2_cs.c b/src/prism2/driver/prism2_cs.c
index 2ba1176..2115f01 100644
--- a/src/prism2/driver/prism2_cs.c
+++ b/src/prism2/driver/prism2_cs.c
@@ -367,8 +367,10 @@ static int prism2_cs_probe(struct pcmcia_device *pdev)

link->conf.Vcc = socketconf.Vcc;
#endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
CS_CHECK(GetConfigurationInfo,
pcmcia_get_configuration_info(pdev, &socketconf));
+#endif

tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
CS_CHECK(GetFirstTuple, pcmcia_get_first_tuple(pdev, &tuple));
--
1.6.0.4
Pavel Roskin
2009-01-11 04:26:01 UTC
Permalink
Post by Tormod Volden
Post by Pavel Roskin
Post by Tormod Volden
This is untested, but at least it compiles.
* pcmcia_get_configuration_info() was removed
Maybe we should stop developing a standalone package and concentrate on
the staging driver and the tools?
Hi Pavel,
Thanks for your comments! I fully agree on the "concentrate" part.
However, until we have a stable, tested version in a released kernel,
we need something to give our users (or distributions) who use 2.6.28.
Granted, few or no people uses the prism2_cs part, but I thought it
would be nice if the whole package could compile at least.
I see.
Post by Tormod Volden
Post by Pavel Roskin
It's not very nice to use local variables in macros. On the other hand,
coding for the new API usually keeps the code more maintainable.
I think it is really bad to have local variables hidden in a macro. So
I'll do it the other way around. This sacrifices "coding for the new
API", but back to your first point, maybe we don't care so much :)
OK, I see you managed to make the patch really small, so I guess it's
indeed a better approach. Especially if we are not going to maintain
the driver for many more years.
Post by Tormod Volden
I'll move it to wlan_compat.h as far as possible. But technically,
does one "need" to put it in there?
It's better to have compatibility code in one place rather than all
over the place.
--
Regards,
Pavel Roskin
Loading...