mjhjmtu

How firmware binary file is identified by any device like the binary file is meant for that device.. What is the role of kernel in this?

The hardware device won't specify the name of the firmware file; the device driver does that.

In general terms, the kernel may detect the hardware based on standardized identifiers (like vendor/product IDs on PCI/PCIe or USB buses, or DMI information), or it may already know the device is supposed to be there (platform devices; based on device-tree information on some architectures like ARM), or the administrator or system start-up scripts may explicitly tell the kernel to load a certain driver (still used with some x86 legacy devices based on the old ISA architecture which is not fully auto-detectable).

The driver will then attempt to confirm that the device exists and ascertain the state of the device, using some method that is either documented by the hardware vendor or reverse-engineered. If the device requires firmware, the driver will include the necessary kernel calls to load the appropriate firmware file. Once the firmware data is loaded in memory, the driver will send it to the hardware device, using whatever method is appropriate for that particular hardware.

The hardware device itself may or may not validate that the firmware data is correct. The simplest hardware designs may simply trust that the firmware provided by the driver is correct, and might hang if that isn't true, possibly requiring a device-specific reset sequence or even a power-down/unplug to make the device usable again. At the other extreme, the firmware might be cryptographically signed or even encrypted, with the appropriate keys and functionality to verify/decrypt it embedded in the device hardware.

Adding firmware verification/decryption logic in the hardware itself will increase the price and complexity of the hardware device, so generally the manufacturers will do that only if the use of non-standard firmware might cause something more significant than just the device itself not working: for example, a WiFi device firmware may regulate the frequencies and power levels used, so an incorrect firmware might cause the device to transmit on forbidden frequencies, potentially causing interference to air traffic control radars (either civilian or military). That might have very serious consequences, so hardware manufacturers have an incentive to ensure that only the firmware versions that have been certified to comply with the appropriate regulations can be used.