On Tue, 21 Jul 2020 15:53:56 +0200 Jiri Pirko wrote: > Mon, Jul 20, 2020 at 05:51:59PM CEST, kubak...@wp.pl wrote: > >On Mon, 20 Jul 2020 12:09:53 +0200 Jiri Pirko wrote: > >> This looks odd. You have a single image yet you somehow divide it > >> into "program" and "config" areas. We already have infra in place to > >> take care of this. See DEVLINK_ATTR_FLASH_UPDATE_COMPONENT. > >> You should have 2 components: > >> 1) "program" > >> 2) "config" > >> > >> Then it is up to the user what he decides to flash. > > > >99.9% of the time users want to flash "all". To achieve "don't flash > >config" with current infra users would have to flash each component > > Well you can have multiple component what would overlap: > 1) "program" + "config" (default) > 2) "program" > 3) "config"
Say I have FW component and UNDI driver. Now I'll have 4 components? fw.prog, fw.config, undi.prog etc? Are those extra ones visible or just "implied"? If they are visible what version does the config have? Also (3) - flashing config from one firmware version and program from another - makes a very limited amount of sense to me. > >one by one and then omit the one(s) which is config (guessing which > >one that is based on the name). > > > >Wouldn't this be quite inconvenient? > > I see it as an extra knob that is actually somehow provides degradation > of components. Hm. We have the exact opposite view on the matter. To me components currently correspond to separate fw/hw entities, that's a very clear meaning. PHY firmware, management FW, UNDI. Now we would add a completely orthogonal meaning to the same API. Why? In the name of "field reuse"? > >In case of MLX is PSID considered config? > > Nope.
