Hi Simon, On Wed, Feb 19, 2020 at 10:21 PM Simon Glass <s...@chromium.org> wrote: > > Hi Angelo, > > On Wed, 19 Feb 2020 at 07:36, Angelo Dureghello > <angelo.dureghe...@timesys.com> wrote: > > > > Hi Simon, > > > > after this commit: > > > > commit 29f7d05a347ab7a42577c67fdfb787ef91537302 > > Author: Simon Glass <s...@chromium.org> > > Date: Sun Dec 29 21:19:17 2019 -0700 > > > > dm: core: Move ofdata_to_platdata() call earlier > > > > This method is supposed to extract platform data from the device tree. > > It > > should be done before the device itself is probed. Move it earlier in > > the > > device_probe() function. > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > stmark2 (mcf5441x based board) hangs silently. > > > > I am debugging into this, since seems to be something wrong in my arch > > files, or related dm drivers, but if you have any hint about where to > > look, welcome. > > Good to have a JTAG debugger or at least a working DEBUG_UART. > > It could be that you have one device relying on another's ofdata, but > the reading of it is in the probe() method instead of > ofdata_to_platdata(). > > Also make sure you have proper error checking in these methods since > silent failure (e.g. to read an address) can cause invalid data to be > used by the driver. > > You can also enable CONFIG_LOG_ERROR_RETURN if you are using log_ret() > or log_msg_ret() in your drivers. > > I can't actually even find the serial driver for m68k so I don't think > I will be much help... > > Regards, > Simon
thanks, so, just for y i. Looks like the issue is that my driver (mcfuart.c) uses "dev->seq" to deduce uart port is 0. And dev->seq after your commit above is now -1 (it was 0). So, looks like dev->seq can't be used now from _ofdata_to_platdata, where i was assigning plat->port = dev->seq; Will fix this in the driver. Regards, Angelo -- Angelo Dureghello Timesys e. angelo.dureghe...@timesys.com
