Am Dienstag, den 18.08.2015, 22:02 +0200 schrieb Petr Cvek: > Dne 18.8.2015 v 20:31 Robert Jarzmik napsal(a): > > Petr Cvek <petr.cvek@xxxxxx> writes: > > > > > The htc-egpio driver should be always included in the kernel as > > > it > > > controls MMC/charging/IrDA power, which is the only way to get > > > an useful rootfs. > > > > > > Signed-off-by: Petr Cvek <petr.cvek@xxxxxx> > > It's already defined in magician_defconfig, why enforce it in > > Kconfig ? > > Good remark, I did not use defconfig at all (as I had to fix from > zero configuration + I did not know if defconfig works and will be > supported in the future). > > I will check if magician_defconfig needs to be updated (probably for > leds). > > > > > And if it's enforced and I want to build a kernel for magician > > without > > MMC/charging/IrDA, why should I be forced to build in HTC_EGPIO ? > > > > Or said differently, does a kernel without HTC_EGPIO is proven to > > fail 100% > > without this option ? > > Kernel will probably run OK, but the phone will be unusable (for any > practical purposes). The EGPIO chip (CPLD) will stay in the state > programmed from the previous environment (bootloader or WinCE/Mobile) > and drivers fail to init because of the missing EGPIO (and if they > init, they will be without any idea about state of the peripherals > (no charger detection/charging current stuck on the previous > settings, no LCD backlight control, no IrDA, no rootfs, no GSM, no > sound, no LEDs). > > Different PCB revisions probably use EGPIO pin for LCD power (and at > least on my phone, LCD power must have very specific order). > > For future (when ROM XIP will work) I would like to be able boot > kernel from flash, which itself uses EGPIO for Vpp control (another > initial EGPIO configuration). Last possible boot is from JTAG and > there will be no previous EGPIO initialization. > > Petr I agree with Robert, let's drop this patch. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html