RTS522A PCI Express Card Reader under openSUSE Leap 42.1 (x86_64)

Hi folks

I am running openSUSE Leap 42.1 (x86_64) and have to set up my SD card reader

I have the following card reader:

computer:/home/user # lspci |grep Card
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)

So I found the website http://cateee.net/lkddb/web-lkddb/MFD_RTSX_PCI.html which states that you need the module rtsx_pci.
I loaded the module, which looks good to me:

computer:/home/user # lsmod |grep rtsx
rtsx_pci               57344  0 
mfd_core               16384  1 rtsx_pci

But then if I issue

fdisk -l

it does not show up. What am I missing here?

Thanks a lot!

Post:

lspci -nnk |grep -iA3 card

That gives me

02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader [10ec:522a] (rev 01)
        Subsystem: Lenovo Device [17aa:2233]
04:00.0 Network controller [0280]: Intel Corporation Wireless 8260 [8086:24f3] (rev 3a)
        Subsystem: Intel Corporation Device [8086:0130]

lkddb pci 10ec 522a … … ff… : CONFIG_MFD_RTSX_PCI : drivers/mfd/rtsx_pcr.c # in 4.4–4.6, 4.7-rc+HEAD

http://cateee.net/lkddb/web-lkddb/MFD_RTSX_PCI.html

In Kernel 4.4 and above.

Please excuse my ignorance, but my knowledge ends here. I don’t know how to interpret that line…
Do I have to compile that C file? Or which command do I have to issue?

thanks

Your Card Reader only works with Kernel 4.4 and higher.

In openSUSE leap, Kernel 4.1 is working.

Ok, great, I upgraded to Kernel 4.7.0 and now it works out of the box.
Thanks!

Am Fri, 08 Jul 2016 18:46:01 GMT
schrieb checkfrogger <checkfrogger@no-mx.forums.microfocus.com>:

> Ok, great, I upgraded to Kernel 4.7.0 and now it works out of the box.
> Thanks!
>
>

If you still have kernel 4.1.x installed and are interested in testing for the
benefit of other users not willing/being able to install a newer kernel, please
respond.

AK


Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

Yes, I still have the 4.1 kernel along with 4.7.0.
My kernel knowledge is certainly very limited, but if I can be of any help, let me know.

Am Sat, 09 Jul 2016 08:46:02 GMT
schrieb checkfrogger <checkfrogger@no-mx.forums.microfocus.com>:

> Yes, I still have the 4.1 kernel along with 4.7.0.
> My kernel knowledge is certainly very limited, but if I can be of any
> help, let me know.
>
>

Well, then let’s start.

I need to know exactly which kernel 4.1 is installed.

rpm -qa “kernel

Before going into great detail, let me just elaborate the idea in a nutshell.

  • Use the code from kernel >= 4.4 and make it run with 4.1.

  • I have already done this, so you will not need to build/compile anything,

  • Before telling you “try this package here” I need to know what “this package”
    will be (i.e exact kernel version and flavor), that’s why I need the output of
    the rpm command above.

AK


Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

Sorry, I am traveling right now without access to my machine. I will come back to you next weekend.

Am Mon, 11 Jul 2016 10:16:01 GMT
schrieb checkfrogger <checkfrogger@no-mx.forums.microfocus.com>:

>
> Sorry, I am traveling right now without access to my machine. I will
> come back to you next weekend.
>
>

Very well, the packages are built but not published yet.

The idea is only to publish the packages if there is somebody to test if they
work.

If someone else with the same hardware (PCI-ID 10ec:522a) wants to step up in
the meantime, be my guest and respond in this thread with the output of rpm
-qa “kernel”.

Otherwise I will just wait for the thread starter to show up again.

AK

Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

I have the following two kernels:


user@machine:~$ rpm -qa "*kernel*" |grep -v texlive
kernel-default-4.7.rc6-3.1.g27cce0c.x86_64
kernel-firmware-20160503-3.1.noarch
kernel-default-4.1.26-21.1.x86_64

Am Wed, 13 Jul 2016 18:26:02 GMT
schrieb checkfrogger <checkfrogger@no-mx.forums.microfocus.com>:

> kernel-default-4.1.26-21.1.x86_64

OK, so you will need this package:

http://download.opensuse.org/repositories/home:/Akoellh:/Kernelmodules/openSUSE_Leap_42.1_Update/x86_64/rtsx-kmp-default-4.6.3_k4.1.26_21-1.2.x86_64.rpm

I would suggest to do the following

  1. Boot your machine with the 4.1.26 kernel

  2. Run

/usr/sbin/modinfo rtsx_pci

Check the line starting with “filename” it will look something likes this:

/lib/modules/VERSION_OF_RUNNING_KERNEL-default/kernel/drivers/mfd/rtsx_pci.ko

  1. Download/install the rpm package manually (as root using rpm)

  2. Now again run

/usr/sbin/modinfo rtsx_pci

The output of the line starting with “filename” should have change to something
like this:

/lib/modules/VERSION_OF_RUNNING_KERNEL-default/updates/drivers/mfd/rtsx_pci.ko

Notice the difference? The idea of building kmp packages containing modules
already existing in the kernel tree is to use a sub folder with higher priority
than the standard sub folder “kernel”, “updates” is one of them.

  1. Now, as root run

/usr/sbin/modprobe -v rtsx_pci

and see if your card reader is now working under 4.1.x

Please report back, especially if it is not working as I will have to remove
the packages because I don’t want to publish non-functional drivers.

AK

Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

Good news, everything is working fine.

modinfo says

filename:       /lib/modules/4.1.26-21-default/updates/drivers/mfd/rtsx_pci.ko

and modprobe says

insmod /lib/modules/4.1.26-21-default/kernel/drivers/mfd/mfd-core.ko 
insmod /lib/modules/4.1.26-21-default/updates/drivers/mfd/rtsx_pci.ko 

and then everything works with automount.

Thank you for providing this package!

Am Wed, 13 Jul 2016 20:16:01 GMT
schrieb checkfrogger <checkfrogger@no-mx.forums.microfocus.com>:

> Good news, everything is working fine.
>

Nice.

> modinfo says
>
> Code:
> --------------------
> filename: /lib/modules/4.1.26-21-default/updates/drivers/mfd/rtsx_pci.ko
>
> --------------------
>

As expected and just to explain briefly what I did:

  • I took the source code from kernel 4.6.3 (as you can see in the package name)
    and made it compile against the sources/headers of kernel 4.1.X.

  • This needed a rather simple patch but that was just in order to define some
    new constant values unknown to the 4.1.x kernel, some of them being
    parameters for the new hardware being added (i.e. your card reader).

So I was pretty optimistic that at least this part would be OK,
but …

> and modprobe says
>
> Code:
> --------------------
> insmod /lib/modules/4.1.26-21-default/kernel/drivers/mfd/mfd-core.ko
> insmod /lib/modules/4.1.26-21-default/updates/drivers/mfd/rtsx_pci.ko
>
> --------------------
>

… that was the main reason for me being very cautious about publishing.

As you can see there is a second module being loaded as a dependency and that
module (as you might guess by its name) is most likely used by many other
(card reader) drivers.

Now if it would not have worked due to an incompatibility of the “old” mfd-core
with the “new” rtsx_pci, I would have been at loss, because I am not really
keen on also packaging the mfd-core module in a KMP-package and by that changing
this core module (and all of its dependencies) for kernel 4.1.x.

This might have worked in making perhaps one or two new devices work but
possibly might have broken many other drivers at the same time.

THAT’s why I needed someone to test ASAP after publishing the packages.

>
> and then everything works with automount.

Evil laughter

“I love it, when a plan works”

Evil laughter

But seriously, there might be still a little step to ensure the driver will
“survive” a kernel upgrade of the openSUSE 42.1 kernel 4.1.x as long as that is
the default distro kernel.

So these are the steps:

  1. Add repo

zypper ar -f -c -r

http://download.opensuse.org/repositories/home:/Akoellh:/Kernelmodules/openSUSE_Leap_42.1_Update/home:Akoellh:Kernelmodules.repo

Adding repository ‘Kernel Modules for openSUSE
(openSUSE_Leap_42.1_Update)’ …[done]
Repository ‘Kernel Modules for openSUSE (openSUSE_Leap_42.1_Update)’
successfully added Enabled : Yes Autorefresh :
Yes GPG Check :
Yes Priority :
99 URI :
http://download.opensuse.org/repositories/home:/Akoellh:/Kernelmodules/openSUSE_Leap_42.1_Update/

  1. Refresh repo & accept signing key

zypper ref -r home_Akoellh_Kernelmodules

Retrieving repository ‘Kernel Modules for openSUSE (openSUSE_Leap_42.1_Update)’
metadata
---------------------------------------------------------------------------------------------------------------------]

New repository or package signing key received:

Repository: Kernel Modules for openSUSE (openSUSE_Leap_42.1_Update)
Key Name: home:Akoellh OBS Project
<home:Akoellh<AT>build.opensuse.org> Key Fingerprint: 40423C5F B92D61F3
19E51D74 C1EFE4F9 639EA1F1 Key Created: Sun Jan 11 13:09:15
2015 Key Expires: Tue Mar 21 13:09:15
2017 Rpm Name:
gpg-pubkey-639ea1f1-54b267eb

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?
shows all options] (r): a Retrieving repository ‘Kernel Modules for openSUSE
(openSUSE_Leap_42.1_Update)’
metadata …[done]
Building repository ‘Kernel Modules for openSUSE (openSUSE_Leap_42.1_Update)’
cache …[done]
Specified repositories have been refreshed.

And you’re done as from now on you will receive updates to the package via zypper.

Notes for other people reading this thread:

  1. Why are there no packages for openSUSE 13.1/13.2?
  • Because for the much older kernels 3.16.x/3.12.x/3.11.x I was not able to get that stuff to compile, so sorry, no packages for 13.1/13.2.
  1. Will there be packages for upcoming openSUSE 42.2 (or Tumbleweed)?
  • No, as 42.2 will have kernel 4.4.x and Tumbleweed is at 4.6.x at the moment, so these packages won’t be necessary any more.
  1. What do I have to do before upgrading to 42.2?
  • Delete my repo or update its url accordingly (to point to the -most likely then existing- URL for openSUSE_Leap_42.2_Update).

AK


Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)