On 26/08/16 22:18, maxime.ripard wrote: > 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).
I think there is a misunderstanding here. I don't suggest to model the AXP through SCPI in a way that covers every kind of functionality that the AXP offers. In fact I never considered to let Linux take care of charging the battery, for instance. If I understand the Allwinner design idea correctly, charging is taken care of in firmware (arisc in their case, but could be ATF as well in our case). > 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. If this is really critical, wouldn't firmware be a better place to deal with this? If we configure an SPI to be taken to EL3, then ATF would be able to immediately react to it, without any possible delay that (the non-RT capable) Linux has to fight with. >>> 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). The fact that we don't know of any reports doesn't mean that this is a good idea. I am really worried about those issues in a more server-like environment, where for instance people rent out boards to customers or people have otherwise access to a command line. >> 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.) Yes, malicious code (sneaked in via a module, for instance) or just a bug in the kernel driver. It seems to me that more people play with Linux than with firmware, so the danger of damaging a board is bigger when the AXP registers are exposed to Linux. If the RSB is tagged secure, we wouldn't need to worry about this. >From reading the manual and looking at the design I think this is what Allwinner also had in mind - although their implementation of this idea is horribly broken, unfortunately (direct access to the RSB is forbidden, but the AXP registers can still be accessed freely via the firmware interface). >From thinking more about this I think we can have both approaches implemented: - An embedded design for people who either want full control or who don't care too much about the potential danger. - A server design which hides those bits from Linux, instead offers abstracted firmware interfaces to monitor (or control, if necessary) AXP functionality. The DT would then ultimately describe which version is used: A "server firmware" would switch the RSB to secure and would expose SCPI regulators and sensors in the DT. People in favour of the embedded design could load a different firmware (or somehow switch over) and use the "embedded" DT with a RSB node and have full control. I don't see how those should clash from a Linux perspective, as we just use different drivers and describe the wanted one in the DT, without having conflicting bindings. Yes, having different DTs for the same hardware may rise some eyebrows, but in the end we just describe firmware interfaces (like PSCI) and avoid describing some hardware (RSB). I really want to depart from this all-embedded approach which exposes every bit to Linux. So why not use the first 64-bit Allwinner chip as a test vehicle to prototype this? Could you live with a different approach living in parallel with the classic sunxi way? Cheers, Andre. -- 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.
