All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: linux-i2c@vger.kernel.org, Corey Minyard <cminyard@mvista.com>
Subject: Re: [PATCH 5/5] i2c-i801: Remove redundant code and event-drive
Date: Thu, 26 May 2016 07:15:28 -0500	[thread overview]
Message-ID: <5746E8E0.7060301@acm.org> (raw)
In-Reply-To: <20160526091733.53821092@endymion>

On 05/26/2016 02:17 AM, Jean Delvare wrote:
> Hi Corey,
>
snip
>
>>> This is unfortunate because some of the changes would still be good to
>>> have. In particular having a single call to i801_check_post() would be
>>> a nice clean-up.
>> Yes, looking over this some more, several of the issues have been
>> addressed that these patches originally targeted.
>>
>> This was originally part of a set of patches that allowed access to
>> I2C devices when the system couldn't schedule, primarily for
>> storing panic information and handling watchdogs at panic and
>> in kgdb.  For that you have to event-drive it so you can poll.
>> I've abandoned those changes, but this small set looked
>> like it has some useful stuff.
>>
>> Thanks for the review, I'll look at pulling out some of the good things
> Thank you, I'll be happy to review and test the new series, hopefully
> faster than I did for this one. Now that the i2c-i801 driver works on
> my system again, it should be much easier.

Ok, thanks.

BTW, I have a working i801 device on qemu, if that helps you.  I'm
working to get it into mainline there.  What's in qemu now is only
marginally functional.

>> (and getting rid of hwpec from i801_block_transaction_byte_by_byte
>> since it's not used there any more).
> Did it ever work? And more importantly, does the hardware support it?
> Before cleaning up the code, I'd like to make sure the driver supports
> PEC in all cases where the hardware itself supports it. I'll do some
> tests.
>

The docs are kind of unclear.  I didn't find anything that said it
didn't work, but I got that impression from some place.  I never
tested it out.

-corey

      reply	other threads:[~2016-05-26 12:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 17:09 [PATCH 0/5] minyard
2016-01-19 17:09 ` [PATCH 1/5] i2c-i801: hwpec and check_pre cleanups minyard
2016-05-25  9:30   ` Jean Delvare
2016-05-25 11:04   ` Jean Delvare
2016-01-19 17:09 ` [PATCH 2/5] i2c-i801: Move hostcfg set/reset to i801_access() minyard
2016-05-25 11:42   ` Jean Delvare
2016-01-19 17:09 ` [PATCH 3/5] i2c-i801: Move PEC handling into i2c_block_transaction() minyard
2016-05-25 12:00   ` Jean Delvare
2016-01-19 17:09 ` [PATCH 4/5] i2c-i801: clean up block transaction minyard
2016-05-25 12:31   ` Jean Delvare
2016-01-19 17:09 ` [PATCH 5/5] i2c-i801: Remove redundant code and event-drive minyard
2016-05-25 12:52   ` Jean Delvare
2016-05-25 16:58     ` Corey Minyard
2016-05-26  7:17       ` Jean Delvare
2016-05-26 12:15         ` Corey Minyard [this message]

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=5746E8E0.7060301@acm.org \
    --to=minyard@acm.org \
    --cc=cminyard@mvista.com \
    --cc=jdelvare@suse.de \
    --cc=linux-i2c@vger.kernel.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.