From: Philipp Hortmann <philipp.g.hortmann@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [BUG] staging: rtl8192e: oops occurs when finding hardware rtl8192se
Date: Wed, 5 Apr 2023 23:19:25 +0200 [thread overview]
Message-ID: <d0642a21-4675-76f7-a470-b0dc1ef37cec@gmail.com> (raw)
In-Reply-To: <2023040521-angelic-emptier-1367@gregkh>
On 4/5/23 16:37, Greg Kroah-Hartman wrote:
> On Sun, Apr 02, 2023 at 05:00:13PM +0200, Philipp Hortmann wrote:
>> Hi,
>>
>> when I use the hardware rtl8192se the driver
>> drivers/staging/rtl8192e/rtl8192e/r8192e_pci.ko detects that it should not
>> run on this hardware and aborts.
>> But when the driver is freeing the resources an oops occures. Find oops at
>> the end of this Email.
>>
>> When I comment out the following lines those errors disappear:
>> cancel_delayed_work_sync(&ieee->hw_wakeup_wq);
>> cancel_delayed_work_sync(&ieee->hw_sleep_wq);
>> cancel_work_sync(&ieee->ips_leave_wq);
>>
>> When I do an init before the cancel:
>> INIT_DELAYED_WORK(&priv->rtllib->hw_wakeup_wq, (void *)rtl92e_hw_wakeup_wq);
>> The oops are gone as well.
>>
>> When I use cancel_delayed_work() instead of cancel_delayed_work_sync() it
>> also works.
>>
>> Can somebody give me a hint what the expected way is to solve this?
>
> Is this a new thing, or has it always been there?
I would need to check in several places.
It seems to me that it was an issue in kernel 4.0 already.
>
> Why is the driver loading if you don't have hardware for it? Or are you
> manually loading it?
Reason why they two drivers are loaded is that realtek managed to have
two different devices with the same vid and did.
from rtl8192se/sw.c:
static const struct pci_device_id rtl92se_pci_ids[] = {
{RTL_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8192, rtl92se_hal_cfg)},
...
from rtl8192e/rtl8192e/rtl_core.c
static struct pci_device_id rtl8192_pci_id_tbl[] = {
{RTL_PCI_DEVICE(0x10ec, 0x8192, rtl819xp_ops)},
#define PCI_VENDOR_ID_REALTEK 0x10ec
The drivers are loaded both and find out with the pci revision_id if
they are in charge.
>
> thanks,
>
> greg k-h
May be I should mention that I do have an rtl8192se. But it does use a
different device id.
I am simulating the driver that it is rtl8192se hardware by changing the
revision_id.
Thanks for your response.
Bye Philipp
next prev parent reply other threads:[~2023-04-05 21:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-02 15:00 [BUG] staging: rtl8192e: oops occurs when finding hardware rtl8192se Philipp Hortmann
2023-04-05 14:37 ` Greg Kroah-Hartman
2023-04-05 21:19 ` Philipp Hortmann [this message]
2023-04-07 21:02 ` [BUG] staging: rtl8192e: W_DISABLE# does not work after stop/start Philipp Hortmann
2023-04-13 9:34 ` Dan Carpenter
2023-04-13 22:17 ` Philipp Hortmann
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=d0642a21-4675-76f7-a470-b0dc1ef37cec@gmail.com \
--to=philipp.g.hortmann@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/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