From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BCC3C433E0 for ; Mon, 1 Jun 2020 23:49:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5641D2073B for ; Mon, 1 Jun 2020 23:49:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728905AbgFAXtl (ORCPT ); Mon, 1 Jun 2020 19:49:41 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:51858 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725841AbgFAXtl (ORCPT ); Mon, 1 Jun 2020 19:49:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 2472C27449; Mon, 1 Jun 2020 19:49:37 -0400 (EDT) Date: Tue, 2 Jun 2020 09:49:36 +1000 (AEST) From: Finn Thain To: Geert Uytterhoeven cc: Benjamin Herrenschmidt , Joshua Thompson , linux-m68k , Linux Kernel Mailing List , linuxppc-dev Subject: Re: [PATCH 8/8] macintosh/adb-iop: Implement SRQ autopolling In-Reply-To: Message-ID: References: <0fb7fdcd99d7820bb27faf1f27f7f6f1923914ef.1590880623.git.fthain@telegraphics.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Jun 2020, Geert Uytterhoeven wrote: > > > > Sure, it could be absorbed by both asm/mac_iop.h and > > drivers/macintosh/adb-iop.c [...] > > asm/mac_iop.h doesn't include asm/adb_iop.h (at least not in my tree, > but perhaps you have plans to change that?), so there's only a single > user. What I meant by "both" was that part of asm/adb_iop.h could be absorbed by drivers/macintosh.adb-iop.c and the rest by asm/mac_iop.h. (And some of it could be tossed out.) I suspect that much of arch/m68k/include/asm could get the same treatment. But I doubt that there is any pay off, because the headers rarely change where they relate to hardware characteristics.