problem with WLAN_ATTRIB_PACK

rajan
2004-09-20
2013-02-17
  • rajan

    rajan - 2004-09-20

    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

     
    • Andreas Mohr

      Andreas Mohr - 2004-09-20

      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!

       
    • rajan

      rajan - 2004-09-22

      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

       
      • Oliver Mihatsch

        Oliver Mihatsch - 2004-09-22

        > 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

         
    • rajan

      rajan - 2004-09-24

      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

       
    • Oliver Mihatsch

      Oliver Mihatsch - 2004-09-26

      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

       
    • rajan

      rajan - 2004-09-27

      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

       
      • Oliver Mihatsch

        Oliver Mihatsch - 2004-09-27

        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

         
    • rajan

      rajan - 2004-09-27

      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

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks