Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1599262

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

From Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Newsgroups linux.kernel
Subject Re: [i2c-tools PATCH v2] i2ctransfer: add new tool
Date 2017-03-13 13:10 +0100
Message-ID <tkwXw-jQ-7@gated-at.bofh.it> (permalink)
References <ti1XQ-146-31@gated-at.bofh.it> <ti7qx-53n-7@gated-at.bofh.it> <tkw1s-852-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello,

On Mon, Mar 13, 2017 at 12:01:40PM +0100, Wolfram Sang wrote:
> Hi Uwe,
> 
> thanks for the review!
> 
> > > +.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.

> > > +Also, you cannot be interrupted by another I2C master during one transfer, but it might happen between multiple transfers.
> > 
> > Well, unless you loose arbitration. Maybe this is too picky to be
> > relevant here?
> 
> 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.

> > > +	for (i = 0; i <= nmsgs; i++)
> > > +		free(msgs[i].buf);
> > > +
> > > +	exit(1);
> > 
> > return EXIT_FAILURE; ?
> > 
> > Apart from the exit code this is exactly the trailer of the good path,
> > so these could share code.
> 
> No! One has '< nmsgs', the other one '<= nmsgs'. Friendly rant: It was
> all easier and less subtle before Jean wanted the 'don't rely on the OS
> for cleanup' additions ;)

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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[i2c-tools PATCH v2] i2ctransfer: add new tool Wolfram Sang <wsa@the-dreams.de> - 2017-03-06 15:40 +0100
  Re: [i2c-tools PATCH v2] i2ctransfer: add new tool Geert Uytterhoeven <geert@linux-m68k.org> - 2017-03-06 16:40 +0100
    Re: [i2c-tools PATCH v2] i2ctransfer: add new tool Wolfram Sang <wsa@the-dreams.de> - 2017-03-06 20:20 +0100
  Re: [i2c-tools PATCH v2] i2ctransfer: add new tool Uwe Kleine-König          <u.kleine-koenig@pengutronix.de> - 2017-03-06 21:30 +0100
    Re: [i2c-tools PATCH v2] i2ctransfer: add new tool Wolfram Sang <wsa@the-dreams.de> - 2017-03-13 12:10 +0100
      Re: [i2c-tools PATCH v2] i2ctransfer: add new tool Uwe Kleine-König          <u.kleine-koenig@pengutronix.de> - 2017-03-13 13:10 +0100
        Re: [i2c-tools PATCH v2] i2ctransfer: add new tool Wolfram Sang <wsa@the-dreams.de> - 2017-03-13 13:30 +0100

csiph-web