I am trying to port the driver of this site to a RTOS called VDK. I've the folowing queries related to pragma packing.
1)I had earlier posted a problem related to
'priv->bssid'. The following statement in acx100_helper.c is failing
MAC_COPY(bcn->hdr.a3, priv->bssid);
Now I could find the reason to be 'pragma packing' but i am unable to solve it. I would like to know the importance of pragma packing.I understand that it's done to tightly pack the data in the memory.
2) I am using the acx100-0.2.0pre8_plus_fixes_14 as my reference.I find that in 'acx100-0.2.0pre8_plus_fixes_30' some more structures have been pragma packed. How to decide on pragma packing i.e. when and which structures should be pragma packed?
Can the forum members/driver code developers help me plz..It's really urgent.
Thanks in Advance,
rajan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
struct packing is needed for ALL structs exchanged with acx1xx firmware (or, more generally speaking, basically for ALL bus communication with other devices, if they're smart).
There are two ways to achieve packing:
a) pragma pack
Said to be "not portable" across compilers, so avoid it
b) __attribute__ ((packed))
(via #define __WLAN_ATTRIB_PACK__ __attribute__ ((packed)))
b) often seems to apply to individual members only, not to whole structs:
My compiler accepted a full-scale
struct __WLAN_ATTRIB_PACK__ foo {
...;
...;
} foo_t;
, but on AMD64 gcc printed "invalid packing ignored" or similar.
So the proper solution is to:
#define ACXPACK __attribute__ ((packed))
(short define)
and add that to ALL struct members that are "misaligned" (and will thus get aligned to the next data size boundary if you don't prevent it). If in doubt, simply add it to ALL members of a struct, whether they're "misaligned" or not... (that's where the shortness of the ACXPACK macro name comes into play).
(I haven't done this properly in my driver yet, should do so soon; but it's working properly already anyway)
Good luck!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again.I could solve the problem but i am not sure if it's correct because the packing is not uniform (not 2 bytes always) and is dependent on the structure.So, I've got some more queries.
>>So the proper solution is to:
#define ACXPACK __attribute__ ((packed))
(short define)
1) Does that mean the default packing is 2 bytes?Does that also mean that the packing the structures is uniform throughout the driver code and is not dependent on the actual size of the structure?
2) What is the importance of 'acx100_after_interrupt_task' routine?When does that get called?
rajan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 2) What is the importance of 'acx100_after_interrupt_task' routine?When does that get called?
Some interrupts (at the moment only scan finished, I think) need to configure the card and wait for the ack interrupt (after scan finished perform the associate cmd). So you have to get out of Interrupt Context when you get such an interrupt. Thats what the 'acx100_after_interrupt_task' does.
Hope that helps,
Olli
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now i am able to associate my card to a AP but still i've got some more problems.
>>2) What is the importance of 'acx100_after_interrupt_task' routine?When does that get called?
Although i can sense the purpose of 'acx100_after_interrupt_task' routine i am unable to get a clear picture of the events that lead to this routine.Sorry to bug you.Can you plz elaborate it further?
3)I have another one.What's the purpose of 'INIT_WORK' routine in 'acx100_open'?
Thanks,
rajan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you get an HOST_INT_SCAN_COMPLETE interrupt, you want to associate with an access point you found. So you have to do an associate configure cmd (ACX1xx_CMD_JOIN) to tell it the card. The configure cmd sends an CMD_CMP interrupt, but you can't receive this because you already process an interrupt. So you have to leave the interrupt context and execute the associate configure cmd in user context so you can receive the CMD_CMP interrupt.
The solution was to set up a small job queue and call it by using task queues (or worker tasks in Linux-2.4).
To use the job queue you have to set the specific job bit in priv->after_interrupt_jobs to high and tell the kernel to call the acx100_after_interrupt task. You do that by calling acx_schedule_after_interrupt_task.
This job queue is used not only for association but also for the reclibration of the card.
The INIT_WORK routine is used to set up worker tasks in Linux-2.4.
Cu,
Olli
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot Mr.Olli. That has cleared the air surrounding the scan_complete interrupt.
As i've mentioned iam trying to port this driver to a RTOS for my DSP.My RTOS does not have the luxuries of Linux job queues.
So, I guess i can safely come out of the interrupt context and appropriately call the 'acx100_after_interrupt_task' without replicating the Linux queues.Plz correct me if i am wrong anywhere.
rajan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know the details from your DSP, but if you don't have the problem with first leaving the interrupt context the easiest way for you should be to change only the acx_schedule_after_interrupt_task method.
Something like that should work for you and your are still compatible to the old interface...
void acx_schedule_after_interrupt_task(wlandevice_t *priv)
{
/* we don't need the job scheduler, call directly */
acx_after_interrupt_task(priv->netdev);
}
Cu,
Olli
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to port the driver of this site to a RTOS called VDK. I've the folowing queries related to pragma packing.
1)I had earlier posted a problem related to
'priv->bssid'. The following statement in acx100_helper.c is failing
MAC_COPY(bcn->hdr.a3, priv->bssid);
Now I could find the reason to be 'pragma packing' but i am unable to solve it. I would like to know the importance of pragma packing.I understand that it's done to tightly pack the data in the memory.
2) I am using the acx100-0.2.0pre8_plus_fixes_14 as my reference.I find that in 'acx100-0.2.0pre8_plus_fixes_30' some more structures have been pragma packed. How to decide on pragma packing i.e. when and which structures should be pragma packed?
Can the forum members/driver code developers help me plz..It's really urgent.
Thanks in Advance,
rajan
Hi,
struct packing is needed for ALL structs exchanged with acx1xx firmware (or, more generally speaking, basically for ALL bus communication with other devices, if they're smart).
There are two ways to achieve packing:
a) pragma pack
Said to be "not portable" across compilers, so avoid it
b) __attribute__ ((packed))
(via #define __WLAN_ATTRIB_PACK__ __attribute__ ((packed)))
b) often seems to apply to individual members only, not to whole structs:
My compiler accepted a full-scale
struct __WLAN_ATTRIB_PACK__ foo {
...;
...;
} foo_t;
, but on AMD64 gcc printed "invalid packing ignored" or similar.
So the proper solution is to:
#define ACXPACK __attribute__ ((packed))
(short define)
and add that to ALL struct members that are "misaligned" (and will thus get aligned to the next data size boundary if you don't prevent it). If in doubt, simply add it to ALL members of a struct, whether they're "misaligned" or not... (that's where the shortness of the ACXPACK macro name comes into play).
(I haven't done this properly in my driver yet, should do so soon; but it's working properly already anyway)
Good luck!
Hi,
Thanks again.I could solve the problem but i am not sure if it's correct because the packing is not uniform (not 2 bytes always) and is dependent on the structure.So, I've got some more queries.
>>So the proper solution is to:
#define ACXPACK __attribute__ ((packed))
(short define)
1) Does that mean the default packing is 2 bytes?Does that also mean that the packing the structures is uniform throughout the driver code and is not dependent on the actual size of the structure?
2) What is the importance of 'acx100_after_interrupt_task' routine?When does that get called?
rajan
> 2) What is the importance of 'acx100_after_interrupt_task' routine?When does that get called?
Some interrupts (at the moment only scan finished, I think) need to configure the card and wait for the ack interrupt (after scan finished perform the associate cmd). So you have to get out of Interrupt Context when you get such an interrupt. Thats what the 'acx100_after_interrupt_task' does.
Hope that helps,
Olli
Thanks Mr.Olli.
Now i am able to associate my card to a AP but still i've got some more problems.
>>2) What is the importance of 'acx100_after_interrupt_task' routine?When does that get called?
Although i can sense the purpose of 'acx100_after_interrupt_task' routine i am unable to get a clear picture of the events that lead to this routine.Sorry to bug you.Can you plz elaborate it further?
3)I have another one.What's the purpose of 'INIT_WORK' routine in 'acx100_open'?
Thanks,
rajan
Ok, I try to explain more details...
When you get an HOST_INT_SCAN_COMPLETE interrupt, you want to associate with an access point you found. So you have to do an associate configure cmd (ACX1xx_CMD_JOIN) to tell it the card. The configure cmd sends an CMD_CMP interrupt, but you can't receive this because you already process an interrupt. So you have to leave the interrupt context and execute the associate configure cmd in user context so you can receive the CMD_CMP interrupt.
The solution was to set up a small job queue and call it by using task queues (or worker tasks in Linux-2.4).
To use the job queue you have to set the specific job bit in priv->after_interrupt_jobs to high and tell the kernel to call the acx100_after_interrupt task. You do that by calling acx_schedule_after_interrupt_task.
This job queue is used not only for association but also for the reclibration of the card.
The INIT_WORK routine is used to set up worker tasks in Linux-2.4.
Cu,
Olli
Thanks a lot Mr.Olli. That has cleared the air surrounding the scan_complete interrupt.
As i've mentioned iam trying to port this driver to a RTOS for my DSP.My RTOS does not have the luxuries of Linux job queues.
So, I guess i can safely come out of the interrupt context and appropriately call the 'acx100_after_interrupt_task' without replicating the Linux queues.Plz correct me if i am wrong anywhere.
rajan
I don't know the details from your DSP, but if you don't have the problem with first leaving the interrupt context the easiest way for you should be to change only the acx_schedule_after_interrupt_task method.
Something like that should work for you and your are still compatible to the old interface...
void acx_schedule_after_interrupt_task(wlandevice_t *priv)
{
/* we don't need the job scheduler, call directly */
acx_after_interrupt_task(priv->netdev);
}
Cu,
Olli
Thanks again.
I've tried something similar,seems to be working.My code looks like this
void acx_schedule_after_interrupt_task(wlandevice_t *priv)
{
disable_interupt(); // specific to my DSP
acx_after_interrupt_task(priv->netdev);
enable_interrupt();// specific to my DSP
}
I shall update the correctness of my code soon.
Cheers,
rajan