linux-kernel - Re: amd5536udc interrupts bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <496737E1.1090607@arcor.de>
Date:	Fri, 09 Jan 2009 12:41:21 +0100
From:	Thomas Dahlmann <dahlmann.thomas@...or.de>
To:	Vadim Lobanov <vlobanov@...akeasy.net>
CC:	linux-kernel@...r.kernel.org
Subject: Re: amd5536udc interrupts bug

Vadim Lobanov schrieb:
> On Thursday 08 January 2009 08:40:28 Thomas Dahlmann wrote:
>   
>> Maybe you want to try this. It should work to place the register init
>> from udc_probe()
>>
>> /* udc csr registers base */
>> dev->csr = dev->virt_addr + UDC_CSR_ADDR;
>> /* dev registers base */
>> dev->regs = dev->virt_addr + UDC_DEVCFG_ADDR;
>> /* ep registers base */spin_lock_init(&dev->lock);
>> dev->ep_regs = dev->virt_addr + UDC_EPREGS_ADDR;
>> /* fifo's base */
>> dev->rxfifo = (u32 __iomem *)(dev->virt_addr + UDC_RXFIFO_ADDR);
>> dev->txfifo = (u32 __iomem *)(dev->virt_addr + UDC_TXFIFO_ADDR);
>>
>> just before request_irq(...) to allow the interrupt handler to read the
>> interrupt status
>> registers.
>>     
>
> I did this. Actually, I also yanked the "spin_lock_init(&dev->lock)" bit 
> before the request_irq() as well, since that field was also obviously 
> needed for the irq routine. (I didn't check for any other necessary but 
> less-obvious fields.) With these changes, the module modprobes just 
> fine.
>   

Thanks for the test!

> Alas, the hardware doesn't work. When I try plugging in the other end of 
> the USB cable, absolutely nothing happens. Not even an interrupt: 
> /proc/interrupts for the amd5536udc line stays at zero. Any thoughts on 
> possible ways to tackle this / what could be going wrong / etc?
>   

Is there any output in the kernel messages on the host side complaining 
about that device is
not answering? If not than USB device port is probably not connected to 
UDC PHY. Please
check in BIOS setup that port 4 is assigned to UDC.

This will set bits PAD_EN and APU in UOC controller (DEVID 0x2097):
http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33238G_cs5536_db.pdf

Thomas
> -- Vadim Lobanov
>
>   


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/