From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzPCs-0007zO-Me for qemu-devel@nongnu.org; Wed, 17 Jul 2013 06:43:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzPCr-00045L-Ke for qemu-devel@nongnu.org; Wed, 17 Jul 2013 06:43:38 -0400 Message-ID: <51E67539.5020008@adacore.com> Date: Wed, 17 Jul 2013 12:43:05 +0200 From: Fabien Chouteau MIME-Version: 1.0 References: <1373997013.8183.332@snotra> <51E66F22.6030202@adacore.com> <18C2B2A2-4D1A-4D23-BB6A-A8D587E014CF@suse.de> In-Reply-To: <18C2B2A2-4D1A-4D23-BB6A-A8D587E014CF@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] Add Enhanced Three-Speed Ethernet Controller (eTSEC) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Scott Wood , qemu-ppc@nongnu.org, qemu-devel@nongnu.org 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() 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