Hi, List
I enabled an ax88796 Ethernet driver in the kernel configuration menu.
Kernel version is 3.4.19. The arch is ARM and the system type is
Samsung S3C2410.
In my debugging, I found the probe function of the driver did not get
invoked.
This driver is declared as platform_driver
static struct platform_driver axdrv = {
.driver = {
.name = "ax88796",
.owner = THIS_MODULE,
},
.probe = ax_probe,
.remove = ax_remove,
.suspend = ax_suspend,
.resume = ax_resume,
};
module_platform_driver(axdrv);
So, its driver init function actually goes through
platform_driver_register() and then driver_register(), which eventually
call driver_attach() trying to attach the driver to the "platform" bus.
But, on the platform bus, there is no any device that can match the
ax88796 driver, hence the driver failed in attaching.
I discovered the full list of devices found on the platform bus:
s3c2410-ohci,
s3c2410-lcd,
s3c2410-wdt,
s3c2410-i2c,
s3c24xx-iis,
s3c2410-nand,
s3c24xx_led,
s3c2410-uart,
You see, in the list, there is no a device looks like ax88796. All these
already existed devices on the platform bus are build-in peripherals on
the SoC of s3c2410, they are compiled into the code by enabling some
kernel configuration options.
My question is, in terms of Linux driver technology, how to enable a
non-PCI and not on-chip device driver? I think the ax_probe function
must be called somehow, is this thinking right? If yes, I think before
the driver get initialized, the corresponding device has to appear on
the bus, but now it seems not.
Thanks in advance.
--
woody
I can't go back to yesterday - because I was a different person then.
On Mon, Nov 26, 2012 at 7:59 AM, Woody Wu <[email protected]> wrote:
> Hi, List
>
> I enabled an ax88796 Ethernet driver in the kernel configuration menu.
> Kernel version is 3.4.19. The arch is ARM and the system type is
> Samsung S3C2410.
>
> In my debugging, I found the probe function of the driver did not get
> invoked.
Did you define platform data and platform device in board file?
See: arch/arm/mach-pxa/colibri-pxa300.c (line ~87)
>
> This driver is declared as platform_driver
>
> static struct platform_driver axdrv = {
> .driver = {
> .name = "ax88796",
> .owner = THIS_MODULE,
> },
> .probe = ax_probe,
> .remove = ax_remove,
> .suspend = ax_suspend,
> .resume = ax_resume,
> };
>
> module_platform_driver(axdrv);
>
> So, its driver init function actually goes through
> platform_driver_register() and then driver_register(), which eventually
> call driver_attach() trying to attach the driver to the "platform" bus.
> But, on the platform bus, there is no any device that can match the
> ax88796 driver, hence the driver failed in attaching.
>
> I discovered the full list of devices found on the platform bus:
>
> s3c2410-ohci,
> s3c2410-lcd,
> s3c2410-wdt,
> s3c2410-i2c,
> s3c24xx-iis,
> s3c2410-nand,
> s3c24xx_led,
> s3c2410-uart,
>
> You see, in the list, there is no a device looks like ax88796. All these
> already existed devices on the platform bus are build-in peripherals on
> the SoC of s3c2410, they are compiled into the code by enabling some
> kernel configuration options.
>
> My question is, in terms of Linux driver technology, how to enable a
> non-PCI and not on-chip device driver? I think the ax_probe function
> must be called somehow, is this thinking right? If yes, I think before
> the driver get initialized, the corresponding device has to appear on
> the bus, but now it seems not.
>
> Thanks in advance.
>
> --
> woody
> I can't go back to yesterday - because I was a different person then.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Cheers,
mbe
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
First you should run "lspci -n" to check your device ID and vendor
ID, and make sure they are in the map list in
/lib/modules/<your-version>/modules.alias .
On Mon, Nov 26, 2012 at 3:47 PM, Belisko Marek <[email protected]> wrote:
> On Mon, Nov 26, 2012 at 7:59 AM, Woody Wu <[email protected]> wrote:
>> Hi, List
>>
>> I enabled an ax88796 Ethernet driver in the kernel configuration menu.
>> Kernel version is 3.4.19. The arch is ARM and the system type is
>> Samsung S3C2410.
>>
>> In my debugging, I found the probe function of the driver did not get
>> invoked.
> Did you define platform data and platform device in board file?
> See: arch/arm/mach-pxa/colibri-pxa300.c (line ~87)
>>
>> This driver is declared as platform_driver
>>
>> static struct platform_driver axdrv = {
>> .driver = {
>> .name = "ax88796",
>> .owner = THIS_MODULE,
>> },
>> .probe = ax_probe,
>> .remove = ax_remove,
>> .suspend = ax_suspend,
>> .resume = ax_resume,
>> };
>>
>> module_platform_driver(axdrv);
>>
>> So, its driver init function actually goes through
>> platform_driver_register() and then driver_register(), which eventually
>> call driver_attach() trying to attach the driver to the "platform" bus.
>> But, on the platform bus, there is no any device that can match the
>> ax88796 driver, hence the driver failed in attaching.
>>
>> I discovered the full list of devices found on the platform bus:
>>
>> s3c2410-ohci,
>> s3c2410-lcd,
>> s3c2410-wdt,
>> s3c2410-i2c,
>> s3c24xx-iis,
>> s3c2410-nand,
>> s3c24xx_led,
>> s3c2410-uart,
>>
>> You see, in the list, there is no a device looks like ax88796. All these
>> already existed devices on the platform bus are build-in peripherals on
>> the SoC of s3c2410, they are compiled into the code by enabling some
>> kernel configuration options.
>>
>> My question is, in terms of Linux driver technology, how to enable a
>> non-PCI and not on-chip device driver? I think the ax_probe function
>> must be called somehow, is this thinking right? If yes, I think before
>> the driver get initialized, the corresponding device has to appear on
>> the bus, but now it seems not.
>>
>> Thanks in advance.
>>
>> --
>> woody
>> I can't go back to yesterday - because I was a different person then.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> Cheers,
>
> mbe
>
> --
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Nov 26, 2012 at 08:47:57AM +0100, Belisko Marek wrote:
> On Mon, Nov 26, 2012 at 7:59 AM, Woody Wu <[email protected]> wrote:
> > Hi, List
> >
> > I enabled an ax88796 Ethernet driver in the kernel configuration menu.
> > Kernel version is 3.4.19. The arch is ARM and the system type is
> > Samsung S3C2410.
> >
> > In my debugging, I found the probe function of the driver did not get
> > invoked.
> Did you define platform data and platform device in board file?
> See: arch/arm/mach-pxa/colibri-pxa300.c (line ~87)
No. After read the colibri-pxa300.c, now I understand I must do it!
Great! Thanks!
But some details in the file I need your help.
In pxa300,
static struct resource colibri_asix_resource[] = {
[0] = {
.start = PXA3xx_CS2_PHYS,
.end = PXA3xx_CS2_PHYS + (0x20 * 2) - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = PXA_GPIO_TO_IRQ(COLIBRI_ETH_IRQ_GPIO),
.end = PXA_GPIO_TO_IRQ(COLIBRI_ETH_IRQ_GPIO),
.flags = IORESOURCE_IRQ | IRQF_TRIGGER_FALLING,
}
};
On my board, I only know the below information about the ax88786
controllers::
eth0: AX88796B found at 0x11000000, using IRQ 52, MAC 00:30:61:00:55:38
eth1: AX88796B found at 0x19000000, using IRQ 53, MAC 00:30:61:00:55:39
Do you think how should I specify resources for it? Especially in the
IRQ part, I don't understand whether I should use the GPIO_TO_IRQ
macros as that in the pxa300.
Also, for the chip selection logic appearing in the pxa300,
static mfp_cfg_t colibri_pxa300_eth_pin_config[] __initdata = {
GPIO1_nCS2, /* AX88796 chip select */
GPIO26_GPIO | MFP_PULL_HIGH /* AX88796 IRQ */
};
I also have no ideal whether I should use it. I don't have schematics
for the board, I only have some kernel logs from an old version of
running linux, for which I don't have source code.
Really hope you can give me some help! Thanks in advance.
> >
> > This driver is declared as platform_driver
> >
> > static struct platform_driver axdrv = {
> > .driver = {
> > .name = "ax88796",
> > .owner = THIS_MODULE,
> > },
> > .probe = ax_probe,
> > .remove = ax_remove,
> > .suspend = ax_suspend,
> > .resume = ax_resume,
> > };
> >
> > module_platform_driver(axdrv);
> >
> > So, its driver init function actually goes through
> > platform_driver_register() and then driver_register(), which eventually
> > call driver_attach() trying to attach the driver to the "platform" bus.
> > But, on the platform bus, there is no any device that can match the
> > ax88796 driver, hence the driver failed in attaching.
> >
> > I discovered the full list of devices found on the platform bus:
> >
> > s3c2410-ohci,
> > s3c2410-lcd,
> > s3c2410-wdt,
> > s3c2410-i2c,
> > s3c24xx-iis,
> > s3c2410-nand,
> > s3c24xx_led,
> > s3c2410-uart,
> >
> > You see, in the list, there is no a device looks like ax88796. All these
> > already existed devices on the platform bus are build-in peripherals on
> > the SoC of s3c2410, they are compiled into the code by enabling some
> > kernel configuration options.
> >
> > My question is, in terms of Linux driver technology, how to enable a
> > non-PCI and not on-chip device driver? I think the ax_probe function
> > must be called somehow, is this thinking right? If yes, I think before
> > the driver get initialized, the corresponding device has to appear on
> > the bus, but now it seems not.
> >
> > Thanks in advance.
> >
> > --
> > woody
> > I can't go back to yesterday - because I was a different person then.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> Cheers,
>
> mbe
>
> --
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
--
woody
I can't go back to yesterday - because I was a different person then.
On 2012-11-26, Li, Zhen-Hua <[email protected]> wrote:
> First you should run "lspci -n" to check your device ID and vendor
> ID, and make sure they are in the map list in
> /lib/modules/<your-version>/modules.alias .
>
For some reasons, I cannot build the driver as loadable modules since I
have to get network before mount the root filesystem. And, this
ethernet controller is not PCI interface, so probabaly the lspci won't
help. Is there any other way to get the device ID and vendor ID?
Thanks.
>
> On Mon, Nov 26, 2012 at 3:47 PM, Belisko Marek
> <[email protected]> wrote:
>> On Mon, Nov 26, 2012 at 7:59 AM, Woody Wu <[email protected]>
>> wrote:
>>> Hi, List
>>>
>>> I enabled an ax88796 Ethernet driver in the kernel configuration
>>> menu. Kernel version is 3.4.19. The arch is ARM and the system type
>>> is Samsung S3C2410.
>>>
>>> In my debugging, I found the probe function of the driver did not
>>> get invoked.
>> Did you define platform data and platform device in board file? See:
>> arch/arm/mach-pxa/colibri-pxa300.c (line ~87)
>>>
>>> This driver is declared as platform_driver
>>>
>>> static struct platform_driver axdrv = { .driver = { .name
>>> = "ax88796", .owner = THIS_MODULE, }, .probe =
>>> ax_probe, .remove = ax_remove, .suspend = ax_suspend,
>>> .resume = ax_resume, };
>>>
>>> module_platform_driver(axdrv);
>>>
>>> So, its driver init function actually goes through
>>> platform_driver_register() and then driver_register(), which
>>> eventually call driver_attach() trying to attach the driver to the
>>> "platform" bus. But, on the platform bus, there is no any device
>>> that can match the ax88796 driver, hence the driver failed in
>>> attaching.
>>>
>>> I discovered the full list of devices found on the platform bus:
>>>
>>> s3c2410-ohci, s3c2410-lcd, s3c2410-wdt, s3c2410-i2c,
>>> s3c24xx-iis, s3c2410-nand, s3c24xx_led, s3c2410-uart,
>>>
>>> You see, in the list, there is no a device looks like ax88796. All
>>> these already existed devices on the platform bus are build-in
>>> peripherals on the SoC of s3c2410, they are compiled into the code
>>> by enabling some kernel configuration options.
>>>
>>> My question is, in terms of Linux driver technology, how to enable a
>>> non-PCI and not on-chip device driver? I think the ax_probe function
>>> must be called somehow, is this thinking right? If yes, I think
>>> before the driver get initialized, the corresponding device has to
>>> appear on the bus, but now it seems not.
>>>
>>> Thanks in advance.
>>>
>>> -- woody I can't go back to yesterday - because I was a different
>>> person then.
>>>
>>> -- To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>
>> Cheers,
>>
>> mbe
>>
>> -- as simple and primitive as possible
>> ------------------------------------------------- Marek Belisko -
>> OPEN-NANDRA Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052
>> 184 skype: marekwhite twitter: #opennandra web:
>> http://open-nandra.com -- To unsubscribe from this list: send the
>> line "unsubscribe linux-kernel" in the body of a message to
>> [email protected] More majordomo info at
>> http://vger.kernel.org/majordomo-info.html Please read the FAQ at
>> http://www.tux.org/lkml/
-- woody I can't go back to yesterday - because I was a different person
then.
Goto /sys/ to find it. The devices are listed in it.
On Mon, Nov 26, 2012 at 5:06 PM, Woody Wu <[email protected]> wrote:
> On 2012-11-26, Li, Zhen-Hua <[email protected]> wrote:
>> First you should run "lspci -n" to check your device ID and vendor
>> ID, and make sure they are in the map list in
>> /lib/modules/<your-version>/modules.alias .
>>
>
> For some reasons, I cannot build the driver as loadable modules since I
> have to get network before mount the root filesystem. And, this
> ethernet controller is not PCI interface, so probabaly the lspci won't
> help. Is there any other way to get the device ID and vendor ID?
> Thanks.
>
>>
>> On Mon, Nov 26, 2012 at 3:47 PM, Belisko Marek
>> <[email protected]> wrote:
>>> On Mon, Nov 26, 2012 at 7:59 AM, Woody Wu <[email protected]>
>>> wrote:
>>>> Hi, List
>>>>
>>>> I enabled an ax88796 Ethernet driver in the kernel configuration
>>>> menu. Kernel version is 3.4.19. The arch is ARM and the system type
>>>> is Samsung S3C2410.
>>>>
>>>> In my debugging, I found the probe function of the driver did not
>>>> get invoked.
>>> Did you define platform data and platform device in board file? See:
>>> arch/arm/mach-pxa/colibri-pxa300.c (line ~87)
>>>>
>>>> This driver is declared as platform_driver
>>>>
>>>> static struct platform_driver axdrv = { .driver = { .name
>>>> = "ax88796", .owner = THIS_MODULE, }, .probe =
>>>> ax_probe, .remove = ax_remove, .suspend = ax_suspend,
>>>> .resume = ax_resume, };
>>>>
>>>> module_platform_driver(axdrv);
>>>>
>>>> So, its driver init function actually goes through
>>>> platform_driver_register() and then driver_register(), which
>>>> eventually call driver_attach() trying to attach the driver to the
>>>> "platform" bus. But, on the platform bus, there is no any device
>>>> that can match the ax88796 driver, hence the driver failed in
>>>> attaching.
>>>>
>>>> I discovered the full list of devices found on the platform bus:
>>>>
>>>> s3c2410-ohci, s3c2410-lcd, s3c2410-wdt, s3c2410-i2c,
>>>> s3c24xx-iis, s3c2410-nand, s3c24xx_led, s3c2410-uart,
>>>>
>>>> You see, in the list, there is no a device looks like ax88796. All
>>>> these already existed devices on the platform bus are build-in
>>>> peripherals on the SoC of s3c2410, they are compiled into the code
>>>> by enabling some kernel configuration options.
>>>>
>>>> My question is, in terms of Linux driver technology, how to enable a
>>>> non-PCI and not on-chip device driver? I think the ax_probe function
>>>> must be called somehow, is this thinking right? If yes, I think
>>>> before the driver get initialized, the corresponding device has to
>>>> appear on the bus, but now it seems not.
>>>>
>>>> Thanks in advance.
>>>>
>>>> -- woody I can't go back to yesterday - because I was a different
>>>> person then.
>>>>
>>>> -- To unsubscribe from this list: send the line "unsubscribe
>>>> linux-kernel" in the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>> Cheers,
>>>
>>> mbe
>>>
>>> -- as simple and primitive as possible
>>> ------------------------------------------------- Marek Belisko -
>>> OPEN-NANDRA Freelance Developer
>>>
>>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052
>>> 184 skype: marekwhite twitter: #opennandra web:
>>> http://open-nandra.com -- To unsubscribe from this list: send the
>>> line "unsubscribe linux-kernel" in the body of a message to
>>> [email protected] More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html Please read the FAQ at
>>> http://www.tux.org/lkml/
>
>
> -- woody I can't go back to yesterday - because I was a different person
> then.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/