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 3DD86C433DF for ; Fri, 5 Jun 2020 04:23:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 15D97206E6 for ; Fri, 5 Jun 2020 04:23:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726040AbgFEEX4 (ORCPT ); Fri, 5 Jun 2020 00:23:56 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:37800 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbgFEEX4 (ORCPT ); Fri, 5 Jun 2020 00:23:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 5CFDD22953; Fri, 5 Jun 2020 00:23:52 -0400 (EDT) Date: Fri, 5 Jun 2020 14:23:50 +1000 (AEST) From: Finn Thain To: Brad Boyer cc: Geert Uytterhoeven , Joshua Thompson , linux-m68k Subject: Re: [PATCH 0/4] Mac IOP driver fixes In-Reply-To: Message-ID: References: <20200601060915.GA8450@allandria.com> <20200602022157.GA3216@allandria.com> <20200604031938.GA25970@allandria.com> <20200604074314.GA800@allandria.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-m68k-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org On Fri, 5 Jun 2020, Finn Thain wrote: > On Thu, 4 Jun 2020, Brad Boyer wrote: > > > I have a list of structures and one of them appears to be the bypass > > command. The outbound message is 3 bytes (the command code:4, a byte > > for a flag with 0 meaning off and 1 meaning on, and an ID byte). The > > reply is a byte of error (0 is success) followed by extra bytes > > depending on the error value. > > > > One of the listed error values is "driver in use", so it's possible it > > will reject the request. We are just taking advantage of the existing > > drivers, so probably both the SWIM and ADB drivers are still running > > on the IOP. > > > > It looks like shutting down a driver is another command. The command > > byte for that is 2, and the second byte is which driver to stop (0/1). > > I'm not sure if there's a way to restart the driver after that other > > than reloading everything. > > > > I think we need to be able to restart the IOP's internal ADB driver. > Otherwise it's impossible to have ADB input resume when the floppy > drives go idle for a while or when the swim module exits. > > The alternative is to revive swip_iop.c, and the downside there is that > the block layer API has completely changed, meaning that the driver > needs a rewrite on the block layer side, as well as needing more work on > the IOP protocol side. > I should also mention that swim.c has some pretty serious limitations: no write support and no GCR support. These features could be added much more easily to swim_iop.c than swim.c because the IOP supports them internally.