All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Ben Dooks (embedded platforms)"
	<ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
	Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 07/12] i2cdev: move compat_ioctl handling into driver
Date: Mon, 14 Dec 2009 16:31:45 +0100	[thread overview]
Message-ID: <200912141631.46300.arnd@arndb.de> (raw)
In-Reply-To: <20091214152307.5ba3ea4d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>

On Monday 14 December 2009, Jean Delvare wrote:
> This patch no longer applies so I can't test it. I do not have any
> objection about it though.

The patch is part of a longer series of patches moving code out
of fs/compat_ioctl.c. If you want to test it, you can just apply the
half adding it to i2c-dev.c and that version will be used.

That part has gained a trivial conflict against an #include cleanup.

> I'm also not sure what I am supposed to comment on. As far as I can
> see, most of this patch is merely moving code from one file to another,
> so there's little point in reviewing that code. Is there any part in
> particular which needs my attention?

No, nothing particular. I was just running the whole series by the
maintainers (or the closest approximation of that) in order to
collect Acked-by and/or have people include the patches in their
trees, especially the ones that I didn't have a test case for.
The patches I got an Ack for were merged now, and I'll repost
the rest after -rc1 to prepare them for the next merge window.

A good way to avoid conflicts would be if you take the i2c-dev.c
parts into a tree of yours and let me follow up with removing the
code from fs/compat_ioctl.c once your tree is merged.

If everyone does that, I can just remove half of fs/compat_ioctl.c
at once.

> If you want to test your patch yourself, it is fairly easy using the
> i2c-stub driver, which is a software-only i2c bus driver. Install the
> i2c-tools package on your system, and then:
> 
> # modprobe i2c-stub chip_addr=0x6d
> # modprobe i2c-dev
> # i2cdetect -l
> # i2cbus=$(i2cdetect -l | grep stub | cut -f1 | cut -d- -f2)
> # i2cdetect -F $i2cbus
> Functionalities implemented by /dev/i2c-x:
> I2C                              no
> SMBus Quick Command              yes
> SMBus Send Byte                  yes
> SMBus Receive Byte               yes
> SMBus Write Byte                 yes
> SMBus Read Byte                  yes
> SMBus Write Word                 yes
> SMBus Read Word                  yes
> SMBus Process Call               no
> SMBus Block Write                no
> SMBus Block Read                 no
> SMBus Block Process Call         no
> SMBus PEC                        no
> I2C Block Write                  no
> I2C Block Read                   no
> # i2cset -y $i2cbus 0x6d 0x00 0x42 b
> Value 0x42 written, readback matched
> # i2cget -y $i2cbus 0x6d 0x00 b
> 0x42
> #
> 
> The last 3 commands will generate i2c-dev ioctls.

Ok, I'll try that, thanks!

	Arnd <><

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: linux-kernel@vger.kernel.org,
	"Ben Dooks (embedded platforms)" <ben-linux@fluff.org>,
	Wolfram Sang <w.sang@pengutronix.de>,
	linux-i2c@vger.kernel.org
Subject: Re: [PATCH 07/12] i2cdev: move compat_ioctl handling into driver
Date: Mon, 14 Dec 2009 16:31:45 +0100	[thread overview]
Message-ID: <200912141631.46300.arnd@arndb.de> (raw)
In-Reply-To: <20091214152307.5ba3ea4d@hyperion.delvare>

On Monday 14 December 2009, Jean Delvare wrote:
> This patch no longer applies so I can't test it. I do not have any
> objection about it though.

The patch is part of a longer series of patches moving code out
of fs/compat_ioctl.c. If you want to test it, you can just apply the
half adding it to i2c-dev.c and that version will be used.

That part has gained a trivial conflict against an #include cleanup.

> I'm also not sure what I am supposed to comment on. As far as I can
> see, most of this patch is merely moving code from one file to another,
> so there's little point in reviewing that code. Is there any part in
> particular which needs my attention?

No, nothing particular. I was just running the whole series by the
maintainers (or the closest approximation of that) in order to
collect Acked-by and/or have people include the patches in their
trees, especially the ones that I didn't have a test case for.
The patches I got an Ack for were merged now, and I'll repost
the rest after -rc1 to prepare them for the next merge window.

A good way to avoid conflicts would be if you take the i2c-dev.c
parts into a tree of yours and let me follow up with removing the
code from fs/compat_ioctl.c once your tree is merged.

If everyone does that, I can just remove half of fs/compat_ioctl.c
at once.

> If you want to test your patch yourself, it is fairly easy using the
> i2c-stub driver, which is a software-only i2c bus driver. Install the
> i2c-tools package on your system, and then:
> 
> # modprobe i2c-stub chip_addr=0x6d
> # modprobe i2c-dev
> # i2cdetect -l
> # i2cbus=$(i2cdetect -l | grep stub | cut -f1 | cut -d- -f2)
> # i2cdetect -F $i2cbus
> Functionalities implemented by /dev/i2c-x:
> I2C                              no
> SMBus Quick Command              yes
> SMBus Send Byte                  yes
> SMBus Receive Byte               yes
> SMBus Write Byte                 yes
> SMBus Read Byte                  yes
> SMBus Write Word                 yes
> SMBus Read Word                  yes
> SMBus Process Call               no
> SMBus Block Write                no
> SMBus Block Read                 no
> SMBus Block Process Call         no
> SMBus PEC                        no
> I2C Block Write                  no
> I2C Block Read                   no
> # i2cset -y $i2cbus 0x6d 0x00 0x42 b
> Value 0x42 written, readback matched
> # i2cget -y $i2cbus 0x6d 0x00 b
> 0x42
> #
> 
> The last 3 commands will generate i2c-dev ioctls.

Ok, I'll try that, thanks!

	Arnd <><

  parent reply	other threads:[~2009-12-14 15:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-16  0:26 [uml-user] [PATCH 00/12] move compat_ioctl handling into drivers Arnd Bergmann
2009-11-16  0:26 ` [uml-devel] " Arnd Bergmann
2009-11-16  0:26 ` [PATCH 01/12] arch/um: handle compat_ioctl in tty line driver Arnd Bergmann
2009-11-16  0:26 ` [PATCH 02/12] scsi/sg: move compat_ioctl handling into sg driver Arnd Bergmann
2009-11-16  0:26 ` [PATCH 03/12] autofs/autofs4: move compat_ioctl handling into fs Arnd Bergmann
2009-11-16  0:26 ` [PATCH 04/12] raw: partly fix compat_ioctl handling on non-x86 Arnd Bergmann
2009-11-16  0:27 ` [PATCH 05/12] nbd: add compat_ioctl method Arnd Bergmann
2009-11-16  0:27 ` [PATCH 06/12] smbfs: do compat_ioctl handling in place Arnd Bergmann
2009-11-16  0:27 ` [PATCH 07/12] i2cdev: move compat_ioctl handling into driver Arnd Bergmann
     [not found]   ` <1258331227-1694-8-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
2009-12-14 14:23     ` Jean Delvare
2009-12-14 14:23       ` Jean Delvare
     [not found]       ` <20091214152307.5ba3ea4d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-12-14 15:31         ` Arnd Bergmann [this message]
2009-12-14 15:31           ` Arnd Bergmann
2010-06-03 12:31           ` Jean Delvare
2009-11-16  0:27 ` [PATCH 08/12] md: move compat_ioctl handling into md.c Arnd Bergmann
2009-11-16  8:39   ` Andre Noll
2009-11-16  0:27 ` [PATCH 09/12] lp: move compat_ioctl handling into lp.c Arnd Bergmann
2009-11-17  1:38   ` Greg KH
2009-11-16  0:27 ` [PATCH 10/12] usbdevfs: move compat_ioctl handling to devio.c Arnd Bergmann
2009-11-17  1:38   ` Greg KH
2009-11-16  0:27 ` [PATCH 11/12] hamradio/mkiss: fix typo in compat_ioctl Arnd Bergmann
2009-11-16  5:13   ` David Miller
2009-11-16  0:27 ` [PATCH 12/12] compat_ioctl: remove unused handlers Arnd Bergmann
2009-11-16  0:57 ` [uml-user] [PATCH 00/12] move compat_ioctl handling into drivers Neil Brown
2009-11-16  0:57   ` [uml-devel] " Neil Brown
2009-11-16  0:57   ` [uml-user] " Neil Brown
2009-11-16  1:02   ` Arnd Bergmann
2009-11-16  1:02     ` [uml-devel] " Arnd Bergmann
2009-11-16  1:02     ` [uml-user] " Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200912141631.46300.arnd@arndb.de \
    --to=arnd-r2ngtmty4d4@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.