On Wed, 16 Sep 2015 11:59:55 +0200 Bernhard Nortmann <bernhard.nortm...@web.de> wrote:
> Am 16.09.2015 um 03:15 schrieb Siarhei Siamashka: > > Yes, caching the pointer inside of aw_fel_get_sram_info() function and > > avoiding repeated usb requests is a good idea. Just make it a static > > variable instead of global. > > Retrieving the version information (struct aw_fel_version) involves a > USB operation, but is 'safe' even for unknown SoCs. So main() is doing > that only once, and as soon as it got a usable USB endpoint. > > It's a question of visibility. I'd like aw_fel_get_sram_info() to work > with that existing data - so we either need it within global scope, or > have to pass it as parameter to the function. The latter once again > tends to make the function calls more complicated / less readable. > > I could work around it by applying a similar "caching" logic to > aw_fel_get_version(), but my impression is that we might be trying > (too?) hard to 'hide' data that actually is of "global" nature. What kind of problem are you trying to solve in the first place? Is it just for suppressing multiple prints of the "unsupported soc type" warning? Getting rid of a few extra USB requests is unlikely to improve performance. If you are really worried about the performance, then we should preferably focus on trying to get rid of the 250ms sleep and improving data transfer speeds. Global variables are not nice. It's not always easy to track when they are already initialized and safe to use. Regarding the "global" nature of this data. Just as a theoretical example, we may consider adding support for handling multiple connected devices at once. Of course not in the "fel" command line tool. But as some sort of a daemon, which waits for connected Allwinner devices in FEL mode, retrieves the unique SID value from each device and uploads appropriate bootloader images to them. With the accessor function, reusing the existing code would be easy. But with global variables, more significant changes would be needed. Anyway, I really don't care and will just push your pending patches to the sunxi-tools repository after some minimal testing. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
