MC7455 in X220 with ModemManager 1.6.4

[Dominik Strnad]

Hello Bjorn, thank you for reply

On Fri, Jun 9, 2017 at 10:28 PM, Bjørn Mork <bjorn at mork.no> wrote:

> Dan Williams <dcbw at redhat.com> writes:
>
> > On Fri, 2017-06-09 at 01:25 +0200, Dominik Strnad wrote:
> >> Hello Bjorn,
> >>
> >> thank you. I meanwhile succeeded to get car into online mode by
> >> isolating
> >> pin20 on minPCIe card. But I at least confirm, that after using
> >> ENTERCND
> >> the PCOFFEN do not report error anymore (but the card was already not
> >> in
> >> disable state because of pin isolation. But I have a question - what
> >> is
> >> better? To use your command (probably as part of some udev rule?) or
> >> keep
> >> that pin isolated? Thank you.
> >
> > Ideally figure out why BIOS isn't letting the card be enabled :)
>
> I still think this is a BIOS flag which needs to be set or cleared, but
> I don't know the exact magic spell.  Looking at the thinkpad_acpi driver
> now, I get a distinct deja vu feeling...  If I only had taken some notes
> :-(
>

I maybe remembered something.... I think the key was to:

1. reload BIOS default, save boot
2. disable WWAN or WIMAX? card in Security I/O ports, save BIOS, boot
3. enable WWAN or WIMAX? card in Security I/O ports, save BIOS, boot


> I wonder if I simply might have temporarily disabled the "HWPRESENT"
> test in the driver, and let the default wan_shutdown() just update the
> state?  In any case, I do believe the solution is hidden somewhere here:
>
>
>
> static void wan_shutdown(void)
> {
>         /* Order firmware to save current state to NVRAM */
>         if (!acpi_evalf(NULL, NULL, "\\WGSV", "vd",
>                         TP_ACPI_WGSV_SAVE_STATE))
>                 pr_notice("failed to save WWAN state to NVRAM\n");
>         else
>                 vdbg_printk(TPACPI_DBG_RFKILL,
>                         "WWAN state saved to NVRAM\n");
> }
>
> static void wan_exit(void)
> {
>         sysfs_remove_group(&tpacpi_pdev->dev.kobj,
>                 &wan_attr_group);
>
>         tpacpi_destroy_rfkill(TPACPI_RFK_WWAN_SW_ID);
>
>         wan_shutdown();
> }
>
> static int __init wan_init(struct ibm_init_struct *iibm)
> {
>         int res;
>         int status = 0;
>
>         vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_RFKILL,
>                         "initializing wan subdriver\n");
>
>         TPACPI_ACPIHANDLE_INIT(hkey);
>
>         tp_features.wan = hkey_handle &&
>             acpi_evalf(hkey_handle, &status, "GWAN", "qd");
>
>         vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_RFKILL,
>                 "wan is %s, status 0x%02x\n",
>                 str_supported(tp_features.wan),
>                 status);
>
> #ifdef CONFIG_THINKPAD_ACPI_DEBUGFACILITIES
>         if (dbg_wwanemul) {
>                 tp_features.wan = 1;
>                 pr_info("wwan switch emulation enabled\n");
>         } else
> #endif
>         if (tp_features.wan &&
>             !(status & TP_ACPI_WANCARD_HWPRESENT)) {
>                 /* no wan hardware present in system */
>                 tp_features.wan = 0;
>                 dbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_RFKILL,
>                            "wan hardware not installed\n");
>         }
>
>         if (!tp_features.wan)
>                 return 1;
>
> ..
>
>
> > But failing that, either PCOFFEN or the taping of pin20 are probably
> > fine.  PCOFFEN is likely the better solution, though that may be reset
> > on firmware updates.
>
> I don't think it will be reset. NVRAM settings are usually kept, unless
> the firmware upgrade includes a specific setting. And they normally
> don't touch PCOFFEN.
>

So it seems that time comes to remove isolation on PIN20 and test again:

- BIOS hack (Should I revert somehow PCOFFEN to previous value to be able
to see if bios enabling card now? Which value?)
- PCOFFEN only

Dominik



>
>
> Bjørn
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170610/c0c7e44f/attachment.html>