From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753864AbdCPV1Z (ORCPT ); Thu, 16 Mar 2017 17:27:25 -0400 Received: from mail-yw0-f173.google.com ([209.85.161.173]:36634 "EHLO mail-yw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752582AbdCPV1X (ORCPT ); Thu, 16 Mar 2017 17:27:23 -0400 Date: Thu, 16 Mar 2017 17:26:54 -0400 From: Tejun Heo To: Bartlomiej Zolnierkiewicz Cc: Russell King , Sergei Shtylyov , Sekhar Nori , Arnd Bergmann , Dmitry Eremin-Solenikov , Kevin Hilman , Olof Johansson , linux-ide@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] pata_pcmcia: add EBSA110's PCMCIA slot support Message-ID: <20170316212654.GD1480@htj.duckdns.org> References: <3458240.9SL7iGif3L@amdc3058> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3458240.9SL7iGif3L@amdc3058> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Tue, Mar 14, 2017 at 06:50:43PM +0100, Bartlomiej Zolnierkiewicz wrote: > +static struct ata_port_operations pcmcia_ebsa110_port_ops = { > + .inherits = &ata_sff_port_ops, > + .sff_dev_select = pmcmia_ebsa110_dev_select, ^^^^^^ > + .sff_set_devctl = pcmcia_ebsa110_set_devctl, > + .sff_check_status = pcmcia_ebsa110_check_status, > + .sff_check_altstatus = pcmcia_ebsa110_check_altstatus, > + .sff_tf_load = pcmcia_ebsa110_tf_load, > + .sff_tf_read = pcmcia_ebsa110_tf_read, > + .sff_exec_command = pcmcia_ebsa110_exec_command, > + .sff_data_xfer = ata_sff_data_xfer_noirq, > + .softreset = pata_pcmcia_ebsa110_softreset, > + .cable_detect = ata_cable_40wire, > + .set_mode = pcmcia_set_mode, > +}; Heh, that's a fat driver for a sff device. I suppose this is mostly copied from the matching ide driver but it'd be nice to explain why it needs duplicate most standard functions. Is it because PCMCIA assigned address doesn't fall under the usual read/io boundary on the arch? Thanks. -- tejun