Skip to contentSkip to conversation

imx53qsb: Remove firmware and features list

PATCH In review Fabio Estevam 4 participants 6 messages May 19, 2015 Arm i.MX and Layerscape

lore
Share & tools
lore

Fabio Estevam

author reviewer
#0 lore raw

PATCH 1/1 imx53qsb: Remove firmware and features list

From: Fabio Estevam <[email protected]>

imx53qsb does not have any Wifi and Bluetooth devices on-board, so remove the firmware and features list.

---
 conf/machine/imx53qsb.conf | 4 ----
 1 file changed, 4 deletions(-)
conf/machine/imx53qsb.conf +0 -4
index 0e7349e..5fadd6e 100644
@@ -15,7 +15,3 @@ PERF_FEATURES_ENABLE = ""
 KERNEL_DEVICETREE = "imx53-qsb.dtb imx53-qsrb.dtb"
 
 UBOOT_MACHINE = "mx53loco_config"
-
-MACHINE_FIRMWARE = "linux-firmware-ar3k \
-                     linux-firmware-ath6k"
-MACHINE_FEATURES += " wifi bluetooth"
Signature · 1 line
1.9.1
#1 lore raw
Quoted 6 lines · Fabio Estevam

From: Fabio Estevam <[email protected]>

imx53qsb does not have any Wifi and Bluetooth devices on-board, so remove the firmware and features list.

This has been added, at that time, because Freescale used the adaptor to do tests. I am not against removing this but several boards we have included list the 'capability' of using WiFi / Bluetooth, not strictly if it is at board or not.

Let me know your thoughts on this.

Signature · 3 lines
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
author reviewer
#2 lore raw

Hi Otavio,

Quoted 6 lines · Otavio Salvador

This has been added, at that time, because Freescale used the adaptor to do tests. I am not against removing this but several boards we have included list the 'capability' of using WiFi / Bluetooth, not strictly if it is at board or not.

Let me know your thoughts on this.

I would prefer to pass in MACHINE_FEATURES only the features that the boards support natively.

Otherwise, every board with a USB port, SDIO or PCIe port could list many possible features of devices that could be potentially attached to it.

If we restrict MACHINE_FEATURES to only the devices that are built-in, then we have a more common approach to the various supported machines.

Regards,

Fabio Estevam

#3 lore raw
Quoted 15 lines · Fabio Estevam

Hi Otavio,

Quoted 6 lines · Otavio Salvador

This has been added, at that time, because Freescale used the adaptor to do tests. I am not against removing this but several boards we have included list the 'capability' of using WiFi / Bluetooth, not strictly if it is at board or not.

Let me know your thoughts on this.

I would prefer to pass in MACHINE_FEATURES only the features that the boards support natively.

Quoted 6 lines

Otherwise, every board with a USB port, SDIO or PCIe port could list many possible features of devices that could be potentially attached to it.

If we restrict MACHINE_FEATURES to only the devices that are built-in, then we have a more common approach to the various supported machines.

It is weird to see ~once again~ an old conversation taking place in mailing list.

I remember to have discussed about this few years ago.

In my opinion, we have basically 2 kinds of boards: the products and the references.

And, in my opinion, the reference boards should include WIFI in MACHINE_FEATURES even if they don't have it physically in the board.

I mean, if board has a PCIe, it is one of the board goals to ~have thing attached to it~, and one of the most often attached stuff is WIFI or/and Bluetooth.

For products, it's straightforward that the board maintainer decides which is the best, as this is a gray area.

Daiane

Quoted 9 lines

Regards,

Fabio Estevam
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale

#4 lore raw

Hi Daiane,

Quoted 28 lines · Daiane Angolini
Quoted 15 lines · Fabio Estevam

Hi Otavio,

Quoted 6 lines · Otavio Salvador

This has been added, at that time, because Freescale used the adaptor to do tests. I am not against removing this but several boards we have included list the 'capability' of using WiFi / Bluetooth, not strictly if it is at board or not.

Let me know your thoughts on this.

I would prefer to pass in MACHINE_FEATURES only the features that the boards support natively.

Quoted 7 lines

Otherwise, every board with a USB port, SDIO or PCIe port could list many possible features of devices that could be potentially attached to it.

If we restrict MACHINE_FEATURES to only the devices that are built-in, then we have a more common approach to the various supported machines.

It is weird to see ~once again~ an old conversation taking place in mailing list.

Quoted 7 lines

I remember to have discussed about this few years ago.

In my opinion, we have basically 2 kinds of boards: the products and the references.

And, in my opinion, the reference boards should include WIFI in MACHINE_FEATURES even if they don't have it physically in the board.

In order to support all kinds of WIFI devices, it will also require all kernel drivers for these devices to be enabled, and currently this is not the case.

Another issue is that leaving/setting the WIFI feature and kernel drivers enabled implies that Freescale or the community board maintainer has tested all these devices on the reference builds, which I doubt is possible.

In general, I tend to agree with Fabio that what's physically available on the board should be supported out of the box.

Just kindly sharing my thoughts, please feel to disagree with me.

Quoted 6 lines

I mean, if board has a PCIe, it is one of the board goals to ~have thing attached to it~, and one of the most often attached stuff is WIFI or/and Bluetooth.

For products, it's straightforward that the board maintainer decides which is the best, as this is a gray area.

Kind regards,
Nikolay

#5 lore raw
Quoted 54 lines · Nikolay Dimitrov

Hi Daiane,

Quoted 32 lines · Daiane Angolini
Quoted 17 lines · Fabio Estevam

Hi Otavio,

Quoted 6 lines · Otavio Salvador

This has been added, at that time, because Freescale used the adaptor to do tests. I am not against removing this but several boards we have included list the 'capability' of using WiFi / Bluetooth, not strictly if it is at board or not.

Let me know your thoughts on this.

I would prefer to pass in MACHINE_FEATURES only the features that the boards support natively.

Quoted 7 lines

Otherwise, every board with a USB port, SDIO or PCIe port could list many possible features of devices that could be potentially attached to it.

If we restrict MACHINE_FEATURES to only the devices that are built-in, then we have a more common approach to the various supported machines.

It is weird to see ~once again~ an old conversation taking place in mailing list.

Quoted 7 lines

I remember to have discussed about this few years ago.

In my opinion, we have basically 2 kinds of boards: the products and the references.

And, in my opinion, the reference boards should include WIFI in MACHINE_FEATURES even if they don't have it physically in the board.

In order to support all kinds of WIFI devices, it will also require all kernel drivers for these devices to be enabled, and currently this is not the case.

Another issue is that leaving/setting the WIFI feature and kernel drivers enabled implies that Freescale or the community board maintainer has tested all these devices on the reference builds, which I doubt is possible.

Quoted 4 lines

In general, I tend to agree with Fabio that what's physically available on the board should be supported out of the box.

Just kindly sharing my thoughts, please feel to disagree with me.

Well, I don't have strong feelings about it.

Let's decide which are the best way to document it so. This way we get it clear in the source code or documentation.

Daiane

Quoted 11 lines
Quoted 7 lines

I mean, if board has a PCIe, it is one of the board goals to ~have thing attached to it~, and one of the most often attached stuff is WIFI or/and Bluetooth.

For products, it's straightforward that the board maintainer decides which is the best, as this is a gray area.

Kind regards,
Nikolay