[GIT PULL 1/3] Keystone SOC driver updates for 4.4

[Murali Karicheri]

Arnd,

On 10/08/2015 11:41 AM, Arnd Bergmann wrote:
> On Tuesday 06 October 2015 10:19:18 Santosh Shilimkar wrote:
>> Couple of patches for ARM Keystone SOC drivers
>>          - irq affinity bug fix
>>          - display the firmware name
>>
>> ----------------------------------------------------------------
>> Murali Karicheri (2):
>>        soc: ti: reset irq affinity before freeing irq
>>        soc: ti: display firmware file name as part of boot log
>>
>>   .../bindings/soc/ti/keystone-navigator-qmss.txt      | 20 +++++++++++++++++++-
>>   drivers/soc/ti/knav_qmss_acc.c                       |  4 ++++
>>   drivers/soc/ti/knav_qmss_queue.c                     |  3 +++
>>   3 files changed, 26 insertions(+), 1 deletion(-)
>
> The new text you add to the binding document doesn't really seem to
> belong in there, so I'm not pulling this until we've discussed how
> this should be better handled.
>
> Ideally, the firmware should just get merged into the linux-firmware.git
> tree.

I have got the firmware merged to the linux-firmware.git. I will post a 
patch to change the document to reflect that. Will it suffice?

>
> Regarding the method of storing the firmware file name in DT, we
> recently had a longer discussion about that and basically concluded
> that this doesn't work for most devices, in particular when the
> communication between the driver and the firmware uses an interface
> that is not 100% stable and can change depending on the firmware
> blob.
>
> Can you guarantee that there will never be changes to the interface?
This firmware is in use for almost 3 years for now on K2 SoCs, but in a 
different kernel version. The interface itself is used not only by Linux 
OS, but other OS as well. So it is not expected to change in the future 
as backward compatibility will be an issue for other OS as well.
> If not, we should try to come up with a better mechanism here, and
> only provide the current method for backwards compatibility.
Assuming we need to change interface in the future, How is this handled 
in other devices? Do they have something like a version to check 
compatibility between software and firmware? As this firmware has been 
frozen for almost 3 years, I wouldn't expect any change to it. Could you 
point me to the thread where this was discussed in the past. Also in my 
experience, mostly changes are to the firmware itself, but not to the 
interface. In such cases, do we keep the name of firmware in DT without 
version information so that in the file system, user could  create a 
soft link to the firmware matching with the DT name. So this way as long 
as interface doesn't change, firmware upgrade is possible. If you agree, 
I can send an incremental patch to rename the firmware to exclude the 
version information.

W.r.t to the patch for documentation update, can I send an incremental 
patch to the update the linux-firmware.git reference as well?

Thanks

Murali

>
> 	Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone