From owner-freebsd-hackers@freebsd.org Wed Mar 28 20:34:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E286BF72812 for ; Wed, 28 Mar 2018 20:34:21 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71982819AA; Wed, 28 Mar 2018 20:34:21 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-ot0-x232.google.com with SMTP id r30-v6so4114498otr.2; Wed, 28 Mar 2018 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=leJvwKVoACIiywTwxNYDOV6xyZcBrC6MJzZUagNsGBk=; b=kxd295h3V3oP6KzJMDTKDfvmBk1ZmKCI3zy5lhXQPRNjm1kkGMvynMysyVaNguJEIT d6OjcUp21wtxSnLGerE3oCQkkZILV+BX2+rl8LdgeYtVVpwkDDtUkraW6rXeu307KnKw CztRDzvvMHXA77d3YBKNr/GjZCS7RNMwzCmrjO4iTBiVeZkN6zRYza5EMWzleWtNmHhi 8br3IQ8KGXPLwifZPOOF/GMER7U6TG7Jzok3It3Vq2wvf64skZPefOjKhaNJKRA1bmLZ j89FvRzqH7ET/c1pxQoDjbatd9C+TE8aSf5rm5AQ4hSaJTZAzgvBMawS6sl1vE56RjbJ zG2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=leJvwKVoACIiywTwxNYDOV6xyZcBrC6MJzZUagNsGBk=; b=oCRBUJDKhCjNMk8fsaSKxD+zm+94SN4E15UVMV6b4Rwn7i5AAML4/KzVKEV/rmqSYk AU6jWBsr/QjhcWouH1X8OegdDbcKmrSGTZeNT7bL675wSQZkMejkShXhNMVw6HFUGcMJ EVtGMRnQloX+n8oUTa+qYGo2VF+s701ORXJ9+s3yCfVvqTESPGupMvu7f82lubOxFkzg UKGlJdVHxAasTUCef6KMvu/+/hG2knnJPPFjeYWbuFhxRlk1R9xnQp9rTJ5Y3+SRAspU ICg4ONoDR4w2JwXNKYS2x7z1pYDnbRbqgjyc4glAzpvl6Qp5uoxC6Olmxqt4QnPPzUhY RUbw== X-Gm-Message-State: AElRT7Hhk2JUeu4NdbS3afDyvPM2IZ/5cSmdm39RKUXH7mkV5zMIeAMi fw5gvFljvAW2FggqxxCyGhg6M+OVcWDP55p8wYXbYQ== X-Google-Smtp-Source: AIpwx4/MFSx28BezsOqGyLJfWpPK3nrZUsIOTVdl2jDeJ7EnXXkC/FBvd+KasEv7+TFirRGLBf5L74vNLn1uzLRIHy8= X-Received: by 2002:a9d:5e06:: with SMTP id d6-v6mr3021702oti.148.1522269260660; Wed, 28 Mar 2018 13:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4292:0:0:0:0:0 with HTTP; Wed, 28 Mar 2018 13:33:40 -0700 (PDT) In-Reply-To: <1521383420.99081.87.camel@freebsd.org> References: <1521383420.99081.87.camel@freebsd.org> From: Lee D Date: Wed, 28 Mar 2018 16:33:40 -0400 Message-ID: Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? To: Ian Lepore Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 20:34:22 -0000 On Sun, Mar 18, 2018 at 10:30 AM, Ian Lepore wrote: > Nostop is an ivar of the child device, so iicbus_get_nostop() is formed > by the IICBUS_ACCESSOR macro in iicbus.h. > > Now for the bad news: don't use it. It doesn't work. It's 100% a bug > in the code that maybe kinda-sorta seemed to work for whoever added it, > because accidentally the right garbage was on the stack in the local > nostop var. The generic transfer code doesn't check that the accessor > failed so it ends up using stack garbage for nostop. The reason > there's g'teed to be no such ivar is because the code is asking the > wrong device, and it doesn't even have a handle to the right child > device to get the info it wants. > > So the bottom line is, write your transfer routine to work however it > has to work. That might mean ignoring the stop/nostop flags and just > doing whatever your hardware does. Like if a write transaction is > handled by the hardware by putting the slave address and the offse- > within-slave values into registers and it does a write of the offset > then a read from the slave and you get no control over whether it does > that as two transactions or as 1 transaction with a repeat-start > between the read and write, then just silently do it that way. > > I had forgotten about the nostop mess, which I discovered some time > last year. It really needs to be fixed the right way, which is to > remove the nostop hack, remove all uses of the NOSTOP flag everywhere > in the code, and make the default behavior that all back-to-back > operations in the same array of cmds handed to a single transfer call > have implicit repeat-start behavior when changing slave or direction. > We could add a specific STOP flag to force a stop/start between two > commands, but even that's not really needed. > > The only example of a transfer-only driver I know of offhand is the rpi > driver (arm/broadcom/bcm2835/bcm2835_bsc.c). Unfortunately, bugs in > the rpi silicon complicate the code and make it a messy example. > > -- Ian > First let me apologize for taking so long to respond. What you've told me is actually good news as far as I am concerned, that I can just do what needs to be done in my driver. So thanks! Lee