Extending k_work safe?

[pauleffect90]

Hi, guys!
Complete noob here on his first zephyr attempt, so kindly bear with him.

I'd like to use Workqueue threads to port my filesystem to zephyr. And I'm a little miffed by the k_work not having any user data fields.
I read the docs, I got the CONTAINER_OF part (pretty neat, never did occur to me to use offsets to get the parent element).

But that basically means I need to hold valid references to enclosing types, which means overhead for message queues (either zephyr's or my own, but in terms of CPU time and RAM). And my functions have 3 args and a callback, at most.

Now, to get to my question. How messed up would the following scenario be?

struct k_work {
	sys_snode_t node;
	k_work_handler_t handler;
	struct k_work_q *queue;
	uint32_t flags;
        void (*Callback)(uint8_t ErrorCode);
        uint32_t Argument1;
        uint32_t Argument2;
        void*    Argument3;
};

A caller requests access to the nand flash chip via:

void COMPONENT_STORAGE_RequestAccess(uint8_t componentId, void (*callback)(byte errorCode))
{
    requestWork.Argument1 = componentId;
    requestWork.Callback  = callback;
    k_work_submit_to_queue(&filesystemWorkQueue, &requestWork);
}

The work handler:

void RequestNand(struct k_work* work)
{
    // CHECK IF FLASH IS POWERED UP
    if(activeComponents == 0)
    {
        // FLASH POWERED DOWN ~ POWER IT UP
        if(DRIVER_NAND_PowerUp() == RESULT_OK)
        {
            // MARK FLASH AS POWERED UP
            int key = irq_lock();
            activeComponents |= work->Argument1;
            irq_unlock(key);
            RAISE_CALLBACK(RESULT_OK);
            return;
        }
        RAISE_CALLBACK(RESULT_NO_FLASH);
        return;
    }
    // FLASH ALREADY POWERED UP
    int key = irq_lock();
    activeComponents |= work->Argument1;
    irq_unlock(key);
    RAISE_CALLBACK(RESULT_OK);
}

UPDATE: Included RAISE_CALLBACK definition
#define RAISE_CALLBACK(ERROR_CODE) do { if(work->Callback) work->Callback(ERROR_CODE); } while(0)