Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp631662ybz; Wed, 29 Apr 2020 06:42:40 -0700 (PDT) X-Google-Smtp-Source: APiQypKiWJ/0n06c6ZTUjuLvcNylUSkAmqqAxZagssFxFpy+BxOnX3/xithoxee0iAWIPZ8XpYHg X-Received: by 2002:aa7:dd95:: with SMTP id g21mr2479040edv.148.1588167759945; Wed, 29 Apr 2020 06:42:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588167759; cv=none; d=google.com; s=arc-20160816; b=RwIlVjZZ+NOQ3O7UgmBqpzVlhDa7I8YgMp4DpWXLWs2WqmQ6zDIdjqxgA9XhUSyQtH sDBZMUVkHeEx3RPRinOzAGUgzGuDwHlZU4Anu/70Uy/n8qcvWn2F0khVych1exGTAFox 8zKCJHEeItrvIE1iJDtdg1xfCPhDenyM5ZDqQZbBAbL5AHzwaMWkuASe/mn2HX6hTCLL 19GO5tF1F8OQUt9IHZhT+o7fDef9vuUob2aGV9BxmwlrRmkB6HNU3yvDJ4y5ZPsJhjXz wDQ9ob5HVfvCt2XxICX6fEdRIRr3w45TjMQZ1TM5gl7oS5InLNY5+9PNOl22Sexsm9K/ d98A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=O6xD5lscw2DChnmJ5g3OwBufYT4RviNzg3q6tGS9Or4=; b=XtnUiEXv9jz/AirH6zSrb5c5CUxAnXXM3TUkpUj5BqO0Kjg6q8TLmpYqgCp7U8iwBi J7hwoZbLuhKQ20X8wHEG9rn0/I6N/LFsUoUBIQQEyYwMLAjJ59ojSF1+nPmLOt38slza z9x/66fAEp3N1KazCEMwyWY/kAvFNfQyZhEN4F7W6j/Zo2klKmhyYN08gkRow2EW4Pms opXbXSmlTlJblzWXjHFd4/r7iH9vpXwBGyngRFXlZstdLp7sT7RHno936AcQzoIW/ASr rvN7x8XmJ0fKLiEwW4rQtpqKoPSQ22ZgMd1kHoB0Tlwp0it/uW+SP8TY5phyI4KZ9L2y SiAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u4si3530445edo.126.2020.04.29.06.42.16; Wed, 29 Apr 2020 06:42:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726599AbgD2Njg (ORCPT + 99 others); Wed, 29 Apr 2020 09:39:36 -0400 Received: from asavdk4.altibox.net ([109.247.116.15]:52230 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727798AbgD2Nje (ORCPT ); Wed, 29 Apr 2020 09:39:34 -0400 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk4.altibox.net (Postfix) with ESMTPS id 49B6580507; Wed, 29 Apr 2020 15:39:29 +0200 (CEST) Date: Wed, 29 Apr 2020 15:39:23 +0200 From: Sam Ravnborg To: Christoph Hellwig Cc: Bartlomiej Zolnierkiewicz , Stephen Rothwell , kbuild test robot , Daniel Vetter , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y && PPC32=n Message-ID: <20200429133923.GA18115@ravnborg.org> References: <20200429125101.GA21275@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200429125101.GA21275@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=MOBOZvRl c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=kj9zAlcOel0A:10 a=_B__PoOuIxrDVYIAAIsA:9 a=CjuIK1q_8ugA:10 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph On Wed, Apr 29, 2020 at 05:51:01AM -0700, Christoph Hellwig wrote: > Why do we even bother allocing the driver to compile for !ppc32 > given that it clearly needs ppc-specific infrastructure? The whole > idea of needing magic stubs for the COMPILE_TEST case seems rather > counterproduction. All the usual good arguments. If this driver only builds for 32bit powerpc then we will seldom build it and every time we do some refactoring we risk introducing build errros in this driver that is triggered much later. So a few hacks are preferred to actually make it build. But hacks should not paper over missing abstractions in the general ioremap handlign and such. I recall someone said the other day that drm folks had a tendency to workaround rather than fixing this. So this is "drm folks" reaching out and asking if this is a case where we have a workaround and need a fix? I will - after some testing - apply the fix from Bartlomiej. But would like to know if this is a workarond or a fix. Dropping COMPILE_TEST is not an option as explained above. Sam