On Thu, Aug 25, 2016 at 12:55:44AM +0100, André Przywara wrote: > On 24/08/16 20:28, maxime.ripard wrote: > > Hi, > > > On Sun, Aug 14, 2016 at 06:16:16PM +0800, Icenowy Zheng wrote: > >> Hi, > >> I currently want to work on more peripherals on A64. > >> However, many features needs clocks and regulators support. > >> Maxime have sent out a series of clock driver based on sunxi-ng, and Andre > >> sent out a RFC series of clock driver based on firmware-based SCPI. > >> It's said that SCPI can also hold regulators. > >> > >> Here're some questions: > >> - Can SCPI handle all the functions on AXP803? Or can a private protocol > >> be used to handle the other functions that SCPI do not support? > > > > SCPI is defined here: > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922g/index.html > > > > Basically, it supports: > > - Clocks > > - Regulators (named power supplies) > > - Resets? (seems like we could implement them as device power states) > > - DVFS > > - Sensors (for voltage, current, temperature, energy and power) > > > > However, the AXP803 has the following features: > > - Regulators: ok > > - GPIOs: not supported > > - Power supplies (the Linux ones, ie which power source is connected > > to the PMIC, the voltage, current they deliver, etc.): not supported > > Why can't we model this with some sensors? Since you mention voltage and > current....
There's really more to it. We need maximum, minimum and current voltages and current, if the power supply is connected or not, etc. > > - Battery Charger: not supported > > - VBUS monitoring: not supported > > Both look like sensors to me. Energy and voltage. Again, this is not just a sensor. The battery charger can adjust the charge voltage and current, and the thresholds it uses to switch between the various charging modes (constant current, constant voltage). And the same thing goes for VBUS. We want to adjust the current limit drawn on VBUS, but we also use the PMIC to... > > > - ADCs: I guess that could fall in the sensors category > > - Timers: not supported > > - IRQs for all of the above: as far as I understand, SCPI is on the > > kernel initiative, so that wouldn't work (but I might very well be > > wrong on this one) > > SCPI normally uses a mailbox, which allows perfect asynchronous > communication from both sides. With the current implementation (not > using the actual mailbox, but SMC calls) the lack of IRQs is sadly true, > although I could envision (ab-)using some interrupt (for instance the > mailbox one) for ATF to tell Linux about updates. And SCPI supports > sensor alerts using those asynchronous notifications. ... get an interrupt when VBUS changes in USB OTG, faster than the GPIO polling to reduce the possible damages. So interrupts are mandatory. > > So even though we might ignore some of them (I'm not seeing the > > relevance of implementing the timers support for example), some > > critical features already used are missing. > > > >> - Which one will be more easy to implement? (I think it's the kernel-side > >> drivers, as there're mature frameworks in the kernel now) > > > > We even have most of the infrastructure thanks to the previous PMIC we > > support, so it should be rather easy to get in the kernel. > > > >> - Is it really valuable for a generalized driver? (As different Allwinner > >> SoCs features usually different IP blocks) > > > > I guess it's just moving the same stuff to different locations: either > > in the kernel or in the firmware. Doing it in the kernel would be at > > almost no cost, it is yet to be entirely implemented in the firmware > > (including the missing parts of the spec). > > So yes, technically SCPI does not cover every feature that the AXP > provides, but I am quite wary of exposing this chip to Linux - since one > can play really nasty tricks with it, probably frying a board easily. There will always be easy damage to a board. I mean, you can even fry a board only by poking at the wrong GPIO through sysfs (first hand experience). The only user you have here is the kernel itself. And if you expose all these features to Linux (that we want!), you'll have exactly the same attack surface. > Combine this with the occasional local root exploit and see unhappy users. For how long exactly have we been using that design? How many people complained of this? (Answer, for sunxi, in almost 4 years now, 0). > So this is actually a good example of how firmware abstraction can > improve security. I'd implement regulators with boundary checks, for > instance: since the firmware is aware of a particular board, it can deny > setting wrong voltages for devices which cannot cope with it. We already do that. And you don't have access to the regulators voltage from the userspace. So the security argument doesn't stand (unless you would have some malicious code running in the kernel, but then the autodestruction would actually be a nice feature to have.) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
