Hi Martin, as I wrote earlier, I would save the GPIO_LIB part for a driver update later on as to me there seems to be no daily use case. I think SLEEP is the preferred solution. If the device is in SLEEP after probing, the logical step would be to disable GPIO functions and configure INT0/GPIO0/XSTBY to XSTBY thus the transceiver is also sleeping. Best practice usually comes from practical usage. If there already is a reference design PCB with the mcp2517fd, it would make sense to see what the designer did connect to the optional GPIO pins and then guess what additional use cases could be of interest. Without that knowledge, you're prone to do over-engineering. Regards, Patrick Am 17.12.2017 um 15:34 schrieb kernel@xxxxxxxxxxxxxxxx: > Hi Patrick! > > So I started implementing the GPIO_LIB implementation but > I have hit an issue where I would like to get some feedback. > > So in principle the gpiolib works, but only if the device is > not asleep and the clock is enabled, which at this very moment means > that the can interface has to be up and running. > > So at this very moment the only option that I see would be to > disable the sleep mode which the device enters after probing until > the can-network interface is enabled (which enables the clock and > start the oscillator) - with SLEEP enabled when GPIOLIB support > is disabled. > > This is obviously not optimal from the power perspective… > > The other option would be starting the clock and oscillator > as soon as a set_direction* (or reques/free) function is called. > (where I would need to start using locks to avoid race conditions > as well as clock usage counters...). > > Which of the above is the preferred solution? Are there other ideas > how I could solve this dilemma? > > > Martin >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
