On 12/19/23 9:39 AM, Jonathan Cameron wrote: > On Mon, 18 Dec 2023 15:59:12 -0800 > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > >> Ben Cheatham wrote: >>> The CXL core module should be able to load regardless of whether the >>> EINJ module initializes correctly. Instead of porting the EINJ module to >>> a library module, add a wrapper __init function around einj_init() to >> >> Small quibble with this wording... the larger EINJ module refactoring >> would be separating module_init() from EINJ probe(). As is this simple >> introduction of an einit_init() wrapper *is* refactoring this module to >> be used as a module dependency. >> >>> pin the EINJ module even if it does not initialize correctly. This >>> should be fine since the EINJ module is only ever unloaded manually. >>> >>> One note: since the CXL core will be calling into the EINJ module >>> directly, even though it may not have initialized, all CXL helper >>> functions *have* to check if the EINJ module is initialized before >>> doing any work. >> >> Another small quibble here, perhaps s/may not have initialized/may not >> have successfully initialized/? Because initialization will have >> definitely completed one way or the other, but callers need to abort if >> it completed in error. >> >>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> >> >> Did Jonathan really get in and review this new patch in the series >> before me? If yes, apologies I missed it, if no I think it is best >> practice to not carry forward series Reviewed-by's if new patches appear >> in the series between revisions. > > I'm not keen on the solution as it's esoteric and to me seems fragile. > I've looked at discussion on v7 and can see why you ended up with this > but I'd have preferred to see the 'violent' approach :) > > I don't mind if there is consensus on this, but not reviewed by from > me for this one. > Gotcha, I'll go ahead on drop your reviewed-by. >> >> >>> Signed-off-by: Ben Cheatham <Benjamin.Cheatham@xxxxxxx> >> >> With above fixups, feel free to add: >> >> Co-developed-by: Dan Williams <dan.j.williams@xxxxxxxxx> >> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> >
