linux-kernel - Re: [i2c-tools PATCH v2] i2ctransfer: add new tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170313122859.GA1439@katana>
Date:   Mon, 13 Mar 2017 13:28:59 +0100
From:   Wolfram Sang <wsa@...-dreams.de>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     linux-i2c@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Jean Delvare <jdelvare@...e.de>,
        Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Subject: Re: [i2c-tools PATCH v2] i2ctransfer: add new tool


> > > > +.RI [ data ]
> > > > +.RI [ desc
> > > > +.RI [ data ]]
> > > 
> > > You could join the previous two lines.
> > 
> > Try it. You will miss some spaces, then.
> 
> It works fine with quoting:
> 
> 	.RI [ "desc " [ data "]] ..."
> 
> . But ok, it's at least arguable if this is better than your solution.

I prefer my solution ;)

> > I wonder: will another I2C master start a transfer on a repeated start?
> > Need to investigate.
> 
> I'd say it must not. It should have logic to detect bus busy and delay
> any transfers until the bus becomes idle. With a repeated start the bus
> doesn't become idle between two transfers.

I totally agree. However, I think I'll try to stress-test a little when
I use my scope next time. Just to have some real world experiences...

> ah, ok. BTW, I like tools that clean up after themselves. This way
> debugging is much easier if you look for lost memory. And yes, this
> doesn't matter much for short-living programs like i2c-tools, but I like
> being consistent here and also do the cleanup for this this type of
> program.

I see this point. And I see that the program became quite more complex
which makes future modifications more error prone. Your exit path
consolidation suggestion was a good example for that. But anayway, the
cleanup is there now, hope you'll all be happy :)


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)