Improved NULL check, nulled bus_data, clear some status variables during init

[fedefrancescon]

When kree(sdio_priv) we should also null the bus_data probably

[fedefrancescon]

TLDR

I'm testing and, as of now, the results seems to be on par with the previous versions (with sleeps). To be honest I don't know why.
But seems promising. I'm still a bit in doubt about readding the sleep. Let's see tomorrow how the tests go.
The problem seems to be still present, with the same rate as with the sleep.
A tester could be:

for i in {1..100}; do
  for act in up down; do
    ip link set wlan-sta $act && continue
    echo "[$i] $act Failed"
    sleep 30
  done
done

close / quit

In some places I've added the reset for wilc->close and wilc->quit, as far as I get these are used as "status" flags, but looks like in some code/event flows this is not always properly resetted at deinit/init.
Adjusting these seems to have greatly reduced the "broken" status

wilc_bt_power_down

I've added this function call because, it's twin is called on init and seems to be doing some interesting thing. I'm not sure if it's really needed and if it's in the correct place

rssi !initialized

I've added an init check as the rssi function seems to be called in a very early step when the module is not fully initialized and always fails, I'm not sure it's a real problem but anyway seems pointless to query something that I'm sure it's not going to work.
At first I returned an error instead of 0, but seems better to leave the init continue. What do you think?

bus_data = NULL

Added some Nulling of bus_data, looking at the code seems that this should never be needed as seems to be intended that it's freed only on module unloading. Maybe better safe than sorry?

[fedefrancescon]

Summary for PR commit message

wilc1000 SDIO device has some issues while doing down/up interface operations.
The problem presents with failure loading the device firmware and driver initialization fails.
This issue seems to affect only wilc1000, even though we have access to only one wilc3000 evaluation board.

The issue seems to be triggered by the down operation which, probably, leaves the chip firmware in a kind of broken state.
This PR DOES NOT FIX the problem but, at least, greatly reduces its occurrence.
As an (hugly) workaround multiple subsequent call to ip link set [interface] up seems to restore the wilc1000 in a working state.

Example:

ip link set wlan0 down
for i in {1..20}; do
  ip link set wlan0 up && break
  echo "Failed $i"
done

Changes

close / quit / initialized

The wilc structure uses some flags to represent the current status of the driver/interface: close, quit, initialized.
Some other similar flags are used in more specific steps.
The usage of this flags withing the chip state flow is not very clear and missing reset of this flags could have left the device in an "inconsistent" state.

wilc_bt_power_down

It's twin function is called on init and seems to be doing something useful on power-down too.

rssi !initialized

RSSI function seems to be called in a very early step when the module is not fully initialized and always fails, seems not a real problem but is pointless to query something that it's not going to work.

Nulling bus_data

Added some Nulling of bus_data, looking at the code seems that this should never be needed as seems to be intended that it's freed only on module unloading, anyway looks safer to explicitly set to NULL.