scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()

The following call trace was observed:

localhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete

localhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092

localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"

localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]

localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1

localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022

localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]

localhost kernel: Call Trace:

localhost kernel: dump_stack_lvl+0x57/0x7d

localhost kernel: check_preemption_disabled+0xc8/0xd0

localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]

Use raw_smp_processor_id() instead of smp_processor_id().

Also use queue_work() across the driver instead of queue_work_on() thus

avoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.