RE extremely lazy but clever workaround (just add this preprocessor
code right after the
headers includes):
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,21)
#define pci_find_device pci_get_device
#endif
-------------
Thanks Philippe, will do tonight.
MarvS
On Wed, Jul 8, 2009 at 12:27 PM, Philippe
Vouters<Philippe.Vouters@xxxxxxxxxxx> wrote:
> Dear Antonio,
>
> The .c code looks to essentially be acting as the code I added to
> workaround the kernel's 8250_pci.c code issue for the Intel 537 modem
> boards.
>
> Here is the relevant code part I recently added (in coredrv/coredrv.c)
> "
> int softcore_init_struct(struct softcore_struct* s)
> {
> register struct pci_dev *pdev;
> if ((pdev=get_pci_info(s)) == NULL){
> #ifdef DEBUG_LINUX
> printk(KERN_ERR"%s:softcore: get_pci_info failed. Returning -1\n",
> SOFTSERIAL_DEVICE_NAME);
> #endif
> return -ENODEV;
> }
> if (pdev->driver)
> {
> printk(KERN_ERR"%s:softcore_init_struct: driver %s already
> allocated devi
> ce.\n",
> SOFTSERIAL_DEVICE_NAME,
> dev_driver_string(&pdev->dev));
> if (!strcmp(dev_driver_string(&pdev->dev),"serial"))
> {
> printk(KERN_WARNING"%s:softcore_init_struct: Unregistering %s
> driver.
> \n",
> SOFTSERIAL_DEVICE_NAME,
> dev_driver_string(&pdev->dev));
> pci_unregister_driver(pdev->driver);
> }
> else
> return -ENODEV;
> }
> #ifdef DEBUG_LINUX
> else
> {
> printk (KERN_INFO"%s:softcore_init_struct: pdev->driver is NULL\n",
> SOFTSERIAL_DEVICE_NAME);
> }
> #endif
> "
> Note that the pci_find_device call used in the
> ungrab-winmodem-20080126/ungrab-winmodem.c code is currently obsoleted
> and produces a compile-time warning since some kernels back. The very
> simplest way to have the code very up to date with a clean compilation
> under many kernels is to use the following bastard, extremely lazy but
> clever workaround (just add this preprocessor code right after the
> headers includes):
> "
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,21)
> #define pci_find_device pci_get_device
> #endif
> "
> The kind of code you sent me and my above code are just workarounds to
> unintentional mistakes in the Linux kernel. The actual correction ought
> to be performed by the Linux kernel guys. Concerning the 537 driver
> interaction with the serial driver, the 8250_pci.c code ought to really
> blacklist the Winmodems he inadvertently recognizes and fails to
> correctly handle. This is quite understandable as this part of the Linux
> kernel has never been designed to handle proprietary closed source code.
> This is definitely not Linux spirit.
>
> Yours very sincerely,
> -
> http://vouters.dyndns.org:8080/
> Philippe Vouters (Fontainebleau/France)
>
>
> Le mercredi 08 juillet 2009 à 09:47 -0500, Antonio Olivares a écrit :
>> Phillipe,
>>
>> This makes me wonder about the ungrab-windmodem that is used in
>> smartlink modems. Could users that are encountering this problem try
>> it out here and see if it helps them resolve this issue?
>>
>> http://linmodems.technion.ac.il/packages/smartlink/ungrab-winmodem-20080126.tar.gz
>>
>> I have seen the serial driver try to claim the spot on PCTEL 789
>> Chipset, and of course it does grab it with smartlink modems, but the
>> ungrab-winmodem is designed for that. In the pctel modem, it does not
>> affect a connection, I can still connect, but not under kernels >=
>> 2.6.30, and thanks to your new driver I am using the Intel 536 modem
>> without any problems.
>>
>> Just a thought, it might help here.
>>
>> Regards,
>>
>> Antonio
>>
>> On 7/8/09, Philippe Vouters <Philippe.Vouters@xxxxxxxxxxx> wrote:
>> > Hi Bjorn,
>> >
>> > If you carefully read the lspci information you just sent me, your 537
>> > board suffers from the exact same odd problem as the two 537 modem
>> > owners (in Ireland and in India). You can read in your data this line:
>> >
>> > Kernel driver in use: serial
>> >
>> > The "serial" driver is nothing but the 8250_pci.c kernel code, which
>> > conflicted with the 537 driver. This is something I did rule out in my
>> > latest 536EP/537EP code. As of today, this "serial" driver gets
>> > unregistered by the 537 driver.
>> >
>> > You do get this above information because your 537 board is a
>> > "Communication controller" and has exactly one or zero memory region and
>> > one I/O region. The 536EP board has exactly one memory region and zero
>> > I/O region, hence the 8250_pci.c code not thinking he has to handle the
>> > board.
>> >
>> > The 8250_pci.c kernel code does lack blacklisting many Winmodems boards.
>> > It just blacklists the AC'97 ALI modem which happens to be also handled
>> > by 537 driver.
>> >
>> > Yours truly,
>> > -
>> > http://vouters.dyndns.org:8080/
>> > Philippe Vouters (Fontainebleau/France)
>> >
>> >
>> > Le mardi 07 juillet 2009 à 18:54 -0300, Bjorn Wielens a écrit :
>> >> Kernel driver in use: serial
>> >
>> >
>> >
>>
>
>
>
