linux-kernel - Re: [PATCH 3/4] devicetree: bindings: Add defeature-repeated-start property for Cadence I2C

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFcVECJwFoFd6GrmF282CG+fELnYb=FNCTDq=RYKky_dHha=Jg@mail.gmail.com>
Date:	Tue, 2 Dec 2014 18:40:13 +0530
From:	Harini Katakam <harinikatakamlinux@...il.com>
To:	Wolfram Sang <wsa@...-dreams.de>
Cc:	Mark Rutland <mark.rutland@....com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"michal.simek@...inx.com" <michal.simek@...inx.com>,
	"soren.brinkmann@...inx.com" <soren.brinkmann@...inx.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"vishnum@...inx.com" <vishnum@...inx.com>
Subject: Re: [PATCH 3/4] devicetree: bindings: Add defeature-repeated-start
 property for Cadence I2C

Hi,

On Tue, Dec 2, 2014 at 6:22 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
>> >> +  - defeature-repeated-start: Include this property to defeature repeated start
>> >> +                           This defeature is due to a few bugs in the
>> >> +                           I2C controller.
>> >> +                           Completion interrupt after a read/receive
>> >> +                           operation is NOT obtained if HOLD bit is set
>> >> +                           at that time. Because of this bug, repeated start
>> >> +                           will only work if there are no transfers following
>> >> +                           a read/receive transfer.
>> >> +                           If HOLD is held for long without a transfer,
>> >> +                           invalid read transactions are generated by the
>> >> +                           controller due to a HW timeout related bug.
>> >
>> > I'm not keen on the name; it sounds like we're disabling a feature
>> > rather than describing the problem (and "defeature" is not a common
>> > term in this sense, "disable" would be better).
>> >
>> > It sounds like there are two issues with staying in the HOLD state? Lost
>> > completion IRQs and a separate HW timeout bug? Or are the two related?
>> >
>>
>> Yes, there are two issues here and they are not related.
>> But a combination of both is leading to not using repeated start.
>> The intention was to defeature except that it works in some scenarios
>> (such as a typical write+read in that order with repeated start)
>> and there are people who already use the driver with slaves that need this.
>
> That should not be handled using a binding. If you get a transfer (at
> runtime) with criteria you don't support, return with -EOPNOTSUPP from
> the master xfer routine.
>

I put a check in place for one failure condition that we know (will
change the error code returned).
But given the bugs, it will be useful to just disable it if the system doesn't
require repeated start.
If you think DT entry is not the way to go, do you think a CONFIG option or
something better will work?
We chose a DT property because there is a good chance the user has multiple
cadence I2C controllers - one connected to a slave that needs repeated start
(like a power controller) and another that doesn't care.

Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/