"Enrico Weigelt, metux IT consult" <[email protected]> writes:
> On 27.04.19 10:58, Esben Haabendal wrote: > > Hi folks, > >> That said, the purpose of UPF_BOOT_AUTOCONF (for 8250 driver) is to >> request and map the register memory. So when that is already done by >> the parent MFD driver, I think it is silly to workaround problems >> caused by UPF_BOOT_AUTOCONF being force setted, when it really >> shouldn't. > I tend to agree. Maybe we should give serial8250_register_8250_port() > some flags for controlling this, or add another function for those > cases. Changing serial8250_register_8250_port() would break existing drivers, as I have seen that some explicitly rely on the automtic addition of UPF_BOOT_AUTOCONF. > A minimal-invasive approach could be introducing an > serial8250_register_8250_port_ext() with extra parameters, and let > serial8250_register_8250_port() just call it. So basically a rename of __serial8250_register_8250_port() in my patch to serial8250_register_8250_port_ext()? Fine with me. Should we give it an EXPORT_SYMBOL() also, as it is just as valid to use in modules as the current serial8250_register_8250_port()? /Esben
