On 07/17/2013 12:22 PM, Alexander Graf wrote: > > On 17.07.2013, at 12:17, Fabien Chouteau wrote: > >> On 07/16/2013 07:50 PM, Scott Wood wrote: >>> On 07/16/2013 10:28:28 AM, Fabien Chouteau wrote: >>>> On 07/16/2013 04:06 AM, Scott Wood wrote: >>>>> On 07/10/2013 12:10:02 PM, Fabien Chouteau wrote: >>>>>> + /* ring_base = (etsec->regs[RBASEH].value & 0xF) << 32; */ >>>>>> + ring_base += etsec->regs[RBASE0 + ring_nbr].value & ~0x7; >>>>>> + start_bd_addr = bd_addr = etsec->regs[RBPTR0 + ring_nbr].value & >>>>>> ~0x7; >>>>> >>>>> What about RBDBPH (upper bits of physical address)? Likewise for TX. >>>>> >>>> >>>> I'm only interested in 32bits address spaces, so RBASEH, TBASEH, RBDBPH or >>>> TBDBPH. >>> >>> When adding code to mainline, it's about more than what you're personally >>> interested in... >>> >> >> If I'm not "personally" interested, I will not have time to develop or >> test a feature. If someone wants to do 36bit addressing, feel free to do >> it, that's why I send the patch on QEMU-devel, but I won't implement >> full support of eTSEC myself... >> >>> Could you at least have a way to diagnose when the guest OS tries to >>> use some functionality that you don't support, rather than silently >>> doing the wrong thing? >>> >> >> This device is so complex, detecting unsupported features would take too >> much work. > > In this case a simple if(<upper bits of addresses>) hw_error(...) would be > good enough :). It's just to make sure that all this valuable knowledge > doesn't get lost any someone who eventually does run into 36bit addressing > doesn't have to debug for a week to figure out who randomly overwrites his > kernel ;). >
Since hwaddr is 64bits, I will add RBASEH, TBASEH, RBDBPH and TBDBPH support... -- Fabien Chouteau
