> On Mon, Jul 6, 2015 at 9:59 AM, Samuel Ortiz <sameo@xxxxxxxxxxxxxxx> wrote:
> >
> > Ok, if you can suspend after this modprobe we're looking at some
> > potential mei bus or mei core issues.
>
> Just looking at the mei/bus.c code to match the driver, and it looks just odd.
The major part of the bus was rejected by Greg and I'm still waiting for him to like be me back and review the resend.
>
> Before the commit that breaks for me, it used to have this loop:
>
> - while (id->name[0]) {
>
> and now it has
>
> + while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
The is the major change in bus, instead of inventing names for each device
we do PnP by matching to UUIDs which are fetched from the parent mei device at initialization.
Looks like there is some conflict between UUID and the driver (pn544) that binds to it and probably didn't before.
I'll be smarter when we have the HW info.
>
> which seems to mean that together with my change to make a working
> kernel (just removing the UUID entirely) means that now the
> device_driver isn't matched against anything at all any more.
>
> So I'm not sure "modprobe pn544_mei" ends up actually triggering
> anything at all with my change to make it not lock up for me.
If you removed the UUID it would just be loaded, I guess
Thanks
Tomas
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
