linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Volf <martin.volf.42@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jean Delvare <jdelvare@suse.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, linux-hwmon@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [regression] nct6775 does not load in 5.4 and 5.5, bisected to b84398d6d7f90080
Date: Sat, 22 Feb 2020 21:49:09 +0100	[thread overview]
Message-ID: <CAM1AHpSpEFshpUGxKdhLV3XuThQg_XVaPgOWzvrTv6YtzHyO+A@mail.gmail.com> (raw)
In-Reply-To: <85356d1a-f90d-e94d-16eb-1071d4e94753@roeck-us.net>

Hello,

On Sat, Feb 22, 2020 at 8:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 2/22/20 9:55 AM, Martin Volf wrote:
> > On Sat, Feb 22, 2020 at 4:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >> On 2/22/20 3:13 AM, Martin Volf wrote:
> >>> hardware monitoring sensors NCT6796D on my Asus PRIME Z390M-PLUS
> >>> motherboard with Intel i7-9700 CPU don't work with 5.4 and newer linux
> >>> kernels, the driver nct6775 does not load.
> >>>
> >>> It is working OK in version 5.3. I have used almost all released stable
> >>> versions from 5.3.8 to 5.3.16; I didn't try older kernels.
> > ...
> >> My wild guess would be that the i801 driver is a bit aggressive with
> >> reserving memory spaces, but I don't immediately see what it does
> >> differently in that regard after the offending patch. Does it work
> >> if you unload the i2c_i801 driver first ?
> >
> > Yes, after unloading i2c_i801, the nct6775 works.
...
> > This is diff of /proc/ioports in 5.3.18 with loaded nct6775 and in
> > 5.4.21 without:
> >
> > --- ioports-5.3.18
> > +++ ioports-5.4.21
> > @@ -2,6 +2,7 @@
> >     0000-001f : dma1
> >     0020-0021 : pic1
> >     002e-0031 : iTCO_wdt
> > +    002e-0031 : iTCO_wdt
> >     0040-0043 : timer0
> >     0050-0053 : timer1
...
> > So 0x2e is the resource the two drivers are fighting for.
...
> Yes, and it should not do that, since the range can be used to access
> different segments of the same chip from multiple drivers. This region
> should only be reserved temporarily, using request_muxed_region() when
> needed and release_region() after the access is complete. Either case,
> I don't immediately see why that region would be interesting for the
> iTCO watchdog driver.
>
> Can you add some debugging into the i801 driver to see what memory regions
> it reserves, and how it gets to reserve 0x2e..0x31 ? That range really
> doesn't make any sense to me.

in the function i801_add_tco() in drivers/i2c/busses/i2c-i801.c
(line 1601 in 5.4.21), there is this code:

        /*
         * Power Management registers.
         */
        devfn = PCI_DEVFN(PCI_SLOT(pci_dev->devfn), 2);
        pci_bus_read_config_dword(pci_dev->bus, devfn, ACPIBASE, &base_addr);

        res = &tco_res[ICH_RES_IO_SMI];
        res->start = (base_addr & ~1) + ACPIBASE_SMI_OFF;
        res->end = res->start + 3;
        res->flags = IORESOURCE_IO;

base_addr is 0xffffffff after pci_bus_read_config_dword() call.
ACPIBASE_SMI_OFF is 0x030, therefore res->start is 0x2e.
Not that I understand even a bit of this...

Martin

  reply	other threads:[~2020-02-22 20:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-22 11:13 [regression] nct6775 does not load in 5.4 and 5.5, bisected to b84398d6d7f90080 Martin Volf
2020-02-22 11:51 ` Wolfram Sang
2020-02-22 15:41 ` Guenter Roeck
2020-02-22 17:55   ` Martin Volf
2020-02-22 19:05     ` Guenter Roeck
2020-02-22 20:49       ` Martin Volf [this message]
2020-02-22 21:26         ` Guenter Roeck
2020-02-23  7:06           ` Martin Volf
2020-02-23 16:39           ` Wolfram Sang
2020-02-24 10:18           ` Mika Westerberg
2020-02-24 10:37             ` Andy Shevchenko
2020-02-24 10:51               ` Mika Westerberg
2020-02-24 11:27                 ` Mika Westerberg
2020-02-24 17:30                   ` Martin Volf
2020-02-25 12:13                     ` Mika Westerberg
2020-02-24 18:27                   ` Guenter Roeck
2020-02-25 12:14                     ` Mika Westerberg
2020-02-23 17:56 ` Gabriel C

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM1AHpSpEFshpUGxKdhLV3XuThQg_XVaPgOWzvrTv6YtzHyO+A@mail.gmail.com \
    --to=martin.volf.42@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mika.westerberg@linux.intel.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).