[PATCH 0/4] remove auto exit of production and added sysfs interface
This patch set introduces new sysfs entries for BMC status information as well as the ABI documention. The mfd core driver now does not exit the production mode automatically. The new sysfs entry allows the userland to exit the production mode if required. Andreas Werner (4): mfd/menf21bmc: remove auto exiting of production mode and add sysfs interface doc/ABI: added sysfs description for the menf21bmc MFD driver mfd/menf21bmc.c: add additional sysfs entries for BMC status information doc/ABI: add documentation for the additional sysfs status information .../ABI/testing/sysfs-bus-i2c-devices-menf21bmc| 40 ++ drivers/mfd/menf21bmc.c| 158 ++--- 2 files changed, 177 insertions(+), 21 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-menf21bmc -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
Okay, wrote up and tested the anchor date version. I think once you get over the initial weirdness of the approach this one is really much cleaner and safer. I tested this with the older rtc_tm_to_time() API and only ported it over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't have that yet... but it still compiles fine and the change was very trivial so I'm confident that it should work. I also did a big manual test for my conversion functions where I just threw a whole bunch of dates at them, results below for reference: [1.431216] jwerner: Testing translation functions: [1.431221] 2015-01-01 to_rockchip: 2015-01-02 to_gregorian: 2014-12-31 [1.431224] 2015-10-30 to_rockchip: 2015-10-31 to_gregorian: 2015-10-29 [1.431228] 2015-10-31 to_rockchip: 2015-11-01 to_gregorian: 2015-10-30 [1.431231] 2015-11-01 to_rockchip: 2015-11-02 to_gregorian: 2015-10-31 [1.431235] 2015-11-27 to_rockchip: 2015-11-28 to_gregorian: 2015-11-26 [1.431238] 2015-11-28 to_rockchip: 2015-11-29 to_gregorian: 2015-11-27 [1.431242] 2015-11-29 to_rockchip: 2015-11-30 to_gregorian: 2015-11-28 [1.431245] 2015-11-30 to_rockchip: 2015-12-01 to_gregorian: 2015-11-29 This one is actually a bug... to_rockchip should be 2015-11-31 here. It happens because the "compensate if we went back over" part of gregorian_to_rockchip() only checks whether we went over *backwards*, which happens if the date is after the anchor date. If it was before we can go back over forwards and I didn't bother to handle that case. I think this is fine since all affected dates lie in the past and there's no real-world use case where you'd ever need them to work again. [1.431249] 2015-11-31 to_rockchip: 2015-12-02 to_gregorian: 2015-11-30 [1.431252] 2015-12-01 to_rockchip: 2015-12-01 to_gregorian: 2015-12-01 [1.431256] 2015-12-02 to_rockchip: 2015-12-02 to_gregorian: 2015-12-02 [1.431259] 2015-12-03 to_rockchip: 2015-12-03 to_gregorian: 2015-12-03 [1.431262] 2015-12-04 to_rockchip: 2015-12-04 to_gregorian: 2015-12-04 [1.431266] 2015-12-05 to_rockchip: 2015-12-05 to_gregorian: 2015-12-05 [1.431269] 2015-12-30 to_rockchip: 2015-12-30 to_gregorian: 2015-12-30 [1.431273] 2015-12-31 to_rockchip: 2015-12-31 to_gregorian: 2015-12-31 [1.431276] 2016-01-01 to_rockchip: 2016-01-01 to_gregorian: 2016-01-01 [1.431279] 2016-10-30 to_rockchip: 2016-10-30 to_gregorian: 2016-10-30 [1.431283] 2016-10-31 to_rockchip: 2016-10-31 to_gregorian: 2016-10-31 [1.431287] 2016-11-01 to_rockchip: 2016-11-01 to_gregorian: 2016-11-01 [1.431291] 2016-11-27 to_rockchip: 2016-11-27 to_gregorian: 2016-11-27 [1.431295] 2016-11-28 to_rockchip: 2016-11-28 to_gregorian: 2016-11-28 [1.431299] 2016-11-29 to_rockchip: 2016-11-29 to_gregorian: 2016-11-29 [1.431302] 2016-11-30 to_rockchip: 2016-11-30 to_gregorian: 2016-11-30 [1.431306] 2016-11-31 to_rockchip: 2016-12-01 to_gregorian: 2016-12-01 [1.431310] 2016-12-01 to_rockchip: 2016-11-31 to_gregorian: 2016-12-02 [1.431313] 2016-12-02 to_rockchip: 2016-12-01 to_gregorian: 2016-12-03 [1.431317] 2016-12-03 to_rockchip: 2016-12-02 to_gregorian: 2016-12-04 [1.431321] 2016-12-04 to_rockchip: 2016-12-03 to_gregorian: 2016-12-05 [1.431324] 2016-12-05 to_rockchip: 2016-12-04 to_gregorian: 2016-12-06 [1.431328] 2016-12-30 to_rockchip: 2016-12-29 to_gregorian: 2016-12-31 [1.431332] 2016-12-31 to_rockchip: 2016-12-30 to_gregorian: 2017-01-01 [1.431335] 2017-01-01 to_rockchip: 2016-12-31 to_gregorian: 2017-01-02 [1.431338] 2017-10-30 to_rockchip: 2017-10-29 to_gregorian: 2017-10-31 [1.431342] 2017-10-31 to_rockchip: 2017-10-30 to_gregorian: 2017-11-01 [1.431345] 2017-11-01 to_rockchip: 2017-10-31 to_gregorian: 2017-11-02 [1.431349] 2017-11-27 to_rockchip: 2017-11-26 to_gregorian: 2017-11-28 [1.431352] 2017-11-28 to_rockchip: 2017-11-27 to_gregorian: 2017-11-29 [1.431356] 2017-11-29 to_rockchip: 2017-11-28 to_gregorian: 2017-11-30 [1.431359] 2017-11-30 to_rockchip: 2017-11-29 to_gregorian: 2017-12-01 [1.431363] 2017-11-31 to_rockchip: 2017-11-30 to_gregorian: 2017-12-02 [1.431366] 2017-12-01 to_rockchip: 2017-11-30 to_gregorian: 2017-12-03 [1.431369] 2017-12-02 to_rockchip: 2017-11-31 to_gregorian: 2017-12-04 [1.431373] 2017-12-03 to_rockchip: 2017-12-01 to_gregorian: 2017-12-05 [1.431376] 2017-12-04 to_rockchip: 2017-12-02 to_gregorian: 2017-12-06 [1.431380] 2017-12-05 to_rockchip: 2017-12-03 to_gregorian: 2017-12-07 [1.431383] 2017-12-30 to_rockchip: 2017-12-28 to_gregorian: 2018-01-01 [1.431386] 2017-12-31 to_rockchip: 2017-12-29 to_gregorian: 2018-01-02 [1.431389] 2020-01-01 to_rockchip: 2019-12-28 to_gregorian: 2020-01-05 [1.431393] 2020-10-30 to_rockchip: 2020-10-26 to_gregorian: 2020-11-03 [1.431397] 2020-10-31 to_rockchip: 2020-10-27 to_gregorian: 2020-11-04 [1.431400] 2020-11-01 to_rockchip: 2020-10-28 to_gregorian: 2020-11-05 [1.4
[PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar
insufficiently represented reality, and changed the rules about
calculating leap years to account for this. Similarly, in A.D. 2013
Rockchip hardware engineers found that the new Gregorian calendar still
contained flaws, and that the month of November should be counted up to
31 days instead. Unfortunately it takes a long time for calendar changes
to gain widespread adoption, and just like more than 300 years went by
before the last Protestant nation implemented Greg's proposal, we will
have to wait a while until all religions and operating system kernels
acknowledge the inherent advantages of the Rockchip system. Until then
we need to translate dates read from (and written to) Rockchip hardware
back to the Gregorian format.
This patch works by defining Jan 1st, 2016 as the arbitrary anchor date
on which Rockchip and Gregorian calendars are in sync. From that we can
translate arbitrary later dates back and forth by counting the number
of November/December transitons since the anchor date to determine the
offset between the calendars. We choose this method (rather than trying
to regularly "correct" the date stored in hardware) since it's the only
way to ensure perfect time-keeping even if the system may be shut down
for an unknown number of years. The drawback is that other software
reading the same hardware (e.g. mainboard firmware) must use the same
translation convention (including the same anchor date) to be able to
read and write correct timestamps from/to the RTC.
Signed-off-by: Julius Werner
---
drivers/rtc/rtc-rk808.c | 48
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 91ca0bc..35c9aad 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -56,6 +56,42 @@ struct rk808_rtc {
int irq;
};
+/*
+ * The Rockchip calendar used by the RK808 counts November with 31 days. We use
+ * these translation functions to convert its dates to/from the Gregorian
+ * calendar used by the rest of the world. We arbitrarily define Jan 1st, 2016
+ * as the day when both calendars were in sync, and treat all other dates
+ * relative to that.
+ * NOTE: Other system software (e.g. firmware) that reads the same hardware
must
+ * implement this exact same conversion algorithm, with the same anchor date.
+ */
+static time64_t nov2dec_transitions(struct rtc_time *tm)
+{
+ return (tm->tm_year + 1900) - 2016 + (tm->tm_mon + 1 > 11 ? 1 : 0);
+}
+
+static void rockchip_to_gregorian(struct rtc_time *tm)
+{
+ /* If it's Nov 31st, rtc_tm_to_time64() will count that like Dec 1st */
+ time64_t time = rtc_tm_to_time64(tm);
+ rtc_time64_to_tm(time + nov2dec_transitions(tm) * 86400, tm);
+}
+
+static void gregorian_to_rockchip(struct rtc_time *tm)
+{
+ time64_t extra_days = nov2dec_transitions(tm);
+ time64_t time = rtc_tm_to_time64(tm);
+ rtc_time64_to_tm(time - extra_days * 86400, tm);
+
+ /* Compensate if we went back over Nov 31st (will work up to 2381) */
+ if (nov2dec_transitions(tm) < extra_days) {
+ if (tm->tm_mon + 1 == 11)
+ tm->tm_mday++; /* This may result in 31! */
+ else
+ rtc_time64_to_tm(time - (extra_days - 1) * 86400, tm);
+ }
+}
+
/* Read current time and date in RTC */
static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
{
@@ -101,9 +137,10 @@ static int rk808_rtc_readtime(struct device *dev, struct
rtc_time *tm)
tm->tm_mon = (bcd2bin(rtc_data[4] & MONTHS_REG_MSK)) - 1;
tm->tm_year = (bcd2bin(rtc_data[5] & YEARS_REG_MSK)) + 100;
tm->tm_wday = bcd2bin(rtc_data[6] & WEEKS_REG_MSK);
+ rockchip_to_gregorian(tm);
dev_dbg(dev, "RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
- tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
+ tm->tm_wday, tm->tm_hour, tm->tm_min, tm->tm_sec);
return ret;
}
@@ -116,6 +153,10 @@ static int rk808_rtc_set_time(struct device *dev, struct
rtc_time *tm)
u8 rtc_data[NUM_TIME_REGS];
int ret;
+ dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
+ 1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+ tm->tm_wday, tm->tm_hour, tm->tm_min, tm->tm_sec);
+ gregorian_to_rockchip(tm);
rtc_data[0] = bin2bcd(tm->tm_sec);
rtc_data[1] = bin2bcd(tm->tm_min);
rtc_data[2] = bin2bcd(tm->tm_hour);
@@ -123,9 +164,6 @@ static int rk808_rtc_set_time(struct device *dev, struct
rtc_time *tm)
rtc_data[4] = bin2bcd(tm->tm_mon + 1);
rtc_data[5
Re: [lm-sensors] LM90 driver and ti tmp461 detection
On Sat, Dec 12, 2015 at 11:08:42AM +0100, Jean Delvare wrote: > Hallo Andreas, > > On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote: > > thanks for the register dump :-) > > Can you please share the register dump of your TMP461 with us? > > Thanks, > -- > Jean Delvare > SUSE L3 Support Hi, here is the register dump of the tmp461. It seemse that we really cannot detect if it is a tmp461 or a tmp451. Also the magic "ID Register" offset 0xff is 0x00 for both devices. 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 5a 00 2c 00 05 7f 80 7f 80 00 00 00 00 00 00 00Z.,.?... 10: 00 00 00 f0 00 80 03 00 00 7f 00 00 00 00 00 00...?.??..?.. 20: 7f 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 40 00???..X?...@. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00..U. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] LM90 driver and ti tmp461 detection
>Hallo Andreas, > > On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote: >> thanks for the register dump > > Can you please share the register dump of your TMP461 with us? > Hi, yes for sure. Currently i have just a evaluation board my CPU without this sensor, but I have received a tmp461 yesterday. As soon as I have soldered this sensor to the Eval board, I will send a register dump. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st
> I'll try to review and evaluate both solution by the end of the week (no > guarantee though). To summarize, it's a pretty simple trade-off. Do you: a) try to detect every time the RTC deviated from the real-world time and correct it instantly? This can be done most of the time but there are edge cases (when the system is completely powered off while the RTC ticks over Nov 31st) where you cannot detect it. Or, b) just completely let the RTC tick in its own world where every year has an extra day and convert that "calendar" to/from the real-world calendar on every access. This essentially relegates the RTC to a "dumb second counter" and the timestamp in its registers doesn't have any direct connection to the real world time anymore (unless you know the conversion algorithm). This has the nice advantage that it perfectly solves all use cases (time-keeping, accurate alarms, even when shut down or browning out at inopportune times)... the only real disadvantage is that other software (e.g. U-Boot) reading the same RTC must know about this and use the same conversion code to get the correct real-world time from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LM90 driver and ti tmp461 detection
... >On Thu, Dec 10, 2015 at 09:49:43AM -0800, Guenter Roeck wrote: > > > >I have a DT based board yes, but i have also planed to submit my changes > >and also wanted to implement the autodetection of the chip. > > > >I have also planned (or need) to implement the "n-Factor Correction" for the > >CPU diodes. There is a register to set this value in the tmp451 and tmp461. > >Would that make sense to add a DT property for the driver to be able > >to set this value? What do you think? > > > > See max6697.c for some examples. Maybe we can use similar bindings. > Seems to be a good way. I think I will also add the extended mode selection via DT. > Guenter > Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LM90 driver and ti tmp461 detection
... > On Thu, Dec 10, 2015 at 09:43:53AM -0800, Guenter Roeck wrote: > > > >There is one difference. The temperature ranges differ: > > > >TMP451: > >Standard Mode: 0 to +127 > >Extended Mode: -64 to +191 > > > >TMP461: > >Standard Mode: -40 to +127 > >Extended Mode: -64 to +191 > > > >Therefore the calcualtion is different then the tmp451 one. > > > Not really. The tmp451 will return 0 for negative temperatures in standard > mode, > the tmp461 will return negative (signed) values. Temperatures are stored > as signed values, so the code should be ok as is. Am I missing something ? > It will work to read the local and external temperature yes, but not for setting the temperatur. If setting in standard mode, the tmp451 part fix the value to 0-127 but for the tmp461 we have -40 to 127. I'v currently no chip here in the office to test it, hopefully I will get one next week. > >I also aggree with you with the magical ID register. I hate such > >kind of register with are not documented and may have a value. > > > >I have a DT based board yes, but i have also planed to submit my changes > >and also wanted to implement the autodetection of the chip. > > I don't think auto-detection (other than handling the chip as tmp451) > will be possible, but I am looking forward to seeing your patch(es). > Yes, i think autodetection makes it very crapy. May be i will find another solution. > > > >I have also planned (or need) to implement the "n-Factor Correction" for the > >CPU diodes. There is a register to set this value in the tmp451 and tmp461. > >Would that make sense to add a DT property for the driver to be able > >to set this value? What do you think? > > > Yes, since this is a board (hardware) property. Other chips have similar > registers. We'll just have to find a good set of property names and > descriptions. > Ok, I will find a way to do it :-) > Thanks, > Guenter > Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LM90 driver and ti tmp461 detection
On Thu, Dec 10, 2015 at 08:41:57AM -0800, Guenter Roeck wrote:
> On 12/10/2015 04:08 AM, Andreas Werner wrote:
> >Hi,
> >i have a temperature sensor device named "TI TMP461" which is quite the
> >same than the tmp451 which is already included in the lm90 driver.
> >
> >I just want to add the tmp461 to the driver but currently i have no way
> >to differ between the tmp461 and tmp451.
> >
> >The main different is that the tmp461 address can be configured by to Pins
> >whereas the tmp451 has a fixed address.
> >
> >The register layout is quite the same except that the tmp461 has one
> >register more (0x16 Channel Enable Register).
> >
> >Every zero bit is the same for both bits, so we cannot use these bits for
> >identification.
> >
> >Does anybody of you have a tmp451 to read out the register 0x16 (which is
> >not implement but i expect a value). May be we can use this to
> >identify the tmp461.
> >
>
> Here is a register dump.
>
> 00: 5d 69 00 04 08 bf 00 ff 53 00 00 00 00 00 00 00]i.???..S...
> 10: a0 00 00 00 00 f0 00 00 00 a9 00 00 00 00 00 00??...?..
> 20: b8 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 00 00???..X?.
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00..U.
>
> there is nothing to distinguish the two chips as far as I can see.
> Is your system a devicetree system ? If so, you can just
> provide a compatible statement such as
> compatible = "ti,tmp461", "ti,tmp451";
> or simply instantiate the chip as tmp451.
>
> Feel free to provide a patch adding '{ "tmp461", tmp451 },'
> to lm90_id as well as the necessary documentation, but I don't
> think there is anything we can do to detect the chip.
>
> On the other side, I am a bit concerned that the chip detection doesn't
> work well, since the chip ID register is really unsupported and just happens
> to return 0 for both chips. I wonder if there are other TI chips which may
> be mis-detected as TMP451.
>
> Thanks,
> Guenter
>
Hi,
thanks for the register dump :-)
There is one difference. The temperature ranges differ:
TMP451:
Standard Mode: 0 to +127
Extended Mode: -64 to +191
TMP461:
Standard Mode: -40 to +127
Extended Mode: -64 to +191
Therefore the calcualtion is different then the tmp451 one.
I also aggree with you with the magical ID register. I hate such
kind of register with are not documented and may have a value.
I have a DT based board yes, but i have also planed to submit my changes
and also wanted to implement the autodetection of the chip.
I have also planned (or need) to implement the "n-Factor Correction" for the
CPU diodes. There is a register to set this value in the tmp451 and tmp461.
Would that make sense to add a DT property for the driver to be able
to set this value? What do you think?
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
LM90 driver and ti tmp461 detection
Hi, i have a temperature sensor device named "TI TMP461" which is quite the same than the tmp451 which is already included in the lm90 driver. I just want to add the tmp461 to the driver but currently i have no way to differ between the tmp461 and tmp451. The main different is that the tmp461 address can be configured by to Pins whereas the tmp451 has a fixed address. The register layout is quite the same except that the tmp461 has one register more (0x16 Channel Enable Register). Every zero bit is the same for both bits, so we cannot use these bits for identification. Does anybody of you have a tmp451 to read out the register 0x16 (which is not implement but i expect a value). May be we can use this to identify the tmp461. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] RTC: RK808: Work around hardware bug on November 31st
> Thinking about all this: these's actually a totally different
> alternative approach we could take if you wanted. It would fix S5 and
> avoid all the anchor stuff, unless I'm crazy.
>
> Basically totally give up on the RTC time reflecting reality. Add a
> "real time to rk808" and "rk808 time to real time" function. Always
> use it when reading from rk808 and always use it when writing to
> rk808. Choose 2015 as the "truth" year if you want (or pick another
> year). In early 2016 the rk808 always contains 1 day back. In 2017
> the rk808 always contains 2 days back. Etc, etc, etc.
>
> The firmware would get confused, but ...
Well... other than that it's crazy and that I'd have to rewrite the
whole patch again, I can't come up with a good argument against this.
In Chromebook firmware the time is only needed for a debug log, so
we'd probably just be willing to accept it being wrong. If U-Boot ever
gets RK808 support, they'll probably just copy the Linux driver
wholesale anyway so they'll conform to the same system.
So if nobody else raises fundamental objections to this approach, I
guess I'll get started on another patch version. (Further replies
below for reference, but most of that stuff would then become moot.)
>> + struct rtc_time anchor_time;/* Last sync point with real world */
>
> Is this ever Nov 31st? Looks like it never is...
No, it's always an already corrected date.
> Review will be significantly easier if we break this up into two patches:
>
> 1. Brain-dead code movement. Move rk808_rtc_readtime() and
> rk808_rtc_set_time() with no functional changes.
>
> 2. This actual change.
Okay, I'll do that for the next rewrite.
>> + extra_days = nov31st_transitions(&rk808_rtc->anchor_time,
>> &alrm->time);
>> + if (alrm->time.tm_mon == 10 && alrm->time.tm_mday == 31) {
>> + dev_warn(dev, "read HW alarm date as Nov 31,
>> compensating\n");
>> + alrm->time.tm_mon = 11;
>> + alrm->time.tm_mday = 1 + extra_days;
>
> But what is it's been 30+ years?!?! :-P Not that this is seriously a
> problem, but you already handle this in the "else" case. Why not just
> set to 11/1 and get rid of the "else" below, so:
>
>...
>alrm->time.tm_mon = 11;
>alrm->time.tm_mday = 1;
> }
> if (extra_days) {
>...
Good point, that makes more sense.
>> + extra_days = nov31st_transitions(&rk808_rtc->anchor_time,
>> &alrm->time);
>> + if (extra_days) {
>> + unsigned long time;
>> + dev_warn(dev, "writing HW alarm date adjusted for %d
>> Nov31\n",
>> +extra_days);
>> + rtc_tm_to_time(&alrm->time, &time);
>> + rtc_time_to_tm(time - extra_days * 86400, &alrm->time);
>> + /* Compensate in case the subtraction went back over Nov
>> 31st */
>> + if (alrm->time.tm_mon == 10 &&
>> + alrm->time.tm_mday == 31 - extra_days)
>> + alrm->time.tm_mday++; /* This can result in 31! */
>
> Seems fishy somehow. You should be able to come up with scenarios
> where you need an alarm on 11/31 on each future year. Here I think
> you can only possibly get 11/31 if extra days == 1, right?
>
> So if it is Nov 30, 2015 and we want alarm on Dec 6, 2020
> extra days = 6:
> Nov 31, 2015
> Nov 31, 2016
> Nov 31, 2017
> Nov 31, 2018
> Nov 31, 2019
> Nov 31, 2020
>
> I think we need to set the alarm for Nov 31st 2020, right? Your
> subtraction should get you to Nov 30th and you need to add an extra
> day for that, but I don't _think_ your if test will. Did I mess up?
> As I said, I'm bad at this...
Hmm... right, I didn't think far enough here. I think I only
considered "what if it's Dec 1st in year X", but of course Dec 2nd and
so on may have the same issues. I think I really just need to change
that condition to (alrm->time.tm_mday >= 31 - extra_days) to get what
we need (at least up to 30 years in the future, after that it reaches
into October).
>> + /*
>> +* Try to initialize anchor point by reading "last read" shadow
>> +* timestamp, to catch Nov 31st transitions that happened while shut
>> +* down. This only works if no other code (e.g. firmware) has
>> +* transitioned GET_TIME before this point.
>> +*/
>> + ret = rk808_rtc_raw_read(&pdev->dev, &rk808_rtc->anchor_time);
>> + if (ret || rtc_valid_tm(&rk808_rtc->anchor_time))
>> + rk808_rtc->anchor_time.tm_mday = 0; /* invalidate */
>
> Ah, the rtc_valid_tm() keeps the anchor from every being Nov 31st. Got it.
At this point we cannot really get Nov 31st (in a way we'd want),
because we want the last time that was read by this driver before
shutdown. If that time was Nov 31st, it would have been immediately
corrected by the driver code (although, now that I think of it, there
is no further read() after that so the set() might not actually update
the shadow re
Re: [v2 0/2] ata/libata-eh.c: introduce ATA_FLAG_NO_LOG_PAGE
On Mon, Dec 07, 2015 at 10:26:30AM -0500, Tejun Heo wrote: > On Fri, Dec 04, 2015 at 06:12:24PM +0100, Andreas Werner wrote: > > This patchset add a new ata port flag ATA_FLAG_NO_LOG_PAGE to be able > > to blacklist ports/controller which e.g. locks up on a log page read. > > > > This flag is added to the sata_fsl driver which is the first affected > > one. > > > > The lockup was detected on Freescale P1013/P1022, T4240 using a ATP > > mSATA. > > The device failed during initialisation if the SATA device includes the > > devslp feature. > > > > With this patchset, we blacklist the fsl sata controller and return > > a error on any attempt to read a log page. This allows us to access > > the mSATA. > > Applied 1-2 to libata/for-4.4-fixes. > > Thanks. > > -- > tejun Thanks Tejun for the discussion and that the patch was applied :-) Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] RTC: RK808: Work around hardware bug on November 31st
In Fuzhou, China, the month of November seems to be having 31 days.
That's nice and all (I'm sure you can get a lot more done in a year that
way), but back here in other parts of the world we are not so lucky.
Therefore, we need to compensate for these extra days existing only in
the RTC's imagination when reading the time and dealing with alarms.
This patch is not a perfect workaround -- it only keeps the time stable
as long as the system is running or suspended. If the system is fully
shut down in November and only booted back up in December, the system
time may be incorrect and alarms that had been set before the shutdown
may fire on the wrong day. We're trying to catch and recover from this
by reading the RTC's last "shadow timestamp" (which only gets resynced
when transitioning the GET_TIME control bit) to figure out when the
system was shut down, but this is only reliable if no other code (e.g.
firmware) has read the RTC in-between.
Basic idea for the workaround:
- Whenever we set the time, we assume that timestamp to be correct
(synced to the real world). We store a copy of it in memory as an
anchor point (where we know our calendar matched the real world).
- Whenever we read the time, we can tell how many days of desync we have
by counting November/December transitions between the anchor timestamp
and the time read from the hardware. We adjust the hardware clock
accordingly to get back in sync (which also resets the anchor time).
- Whenever we set an alarm, we adjust the alarm time backwards by the
amount of days that we know we will lag behind at that point (by
counting the November/December transitions between our anchor point
and the alarm). This way, we will wake up on the right real world date
even though we cannot make adjustments while suspended.
- Whenever we read an alarm, we do the opposite (forward) adjustment for
the returned result to keep our outside interface free from this
madness (callers expect to be able to read back the alarm they wrote).
- Whenever we set the system time (which adjusts the anchor point), we
read out the (adjusted) alarm time beforehand and write it (newly
adjusted) back afterwards. This way, system time and alarm time will
always stay on the same calendar (as long as we're able to keep track
of our anchor point, at least).
Signed-off-by: Julius Werner
---
drivers/rtc/rtc-rk808.c | 282
1 file changed, 190 insertions(+), 92 deletions(-)
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 91ca0bc..2a6cd6f 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -54,103 +54,30 @@ struct rk808_rtc {
struct rk808 *rk808;
struct rtc_device *rtc;
int irq;
+ struct rtc_time anchor_time;/* Last sync point with real world */
};
-/* Read current time and date in RTC */
-static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
+/*
+ * RK808 has a hardware bug causing it to count 31 days in November. This
+ * function can calculate the amount of days that code needs to adjust for
+ * between two timestamps to compensate for this.
+ */
+static int nov31st_transitions(struct rtc_time *from, struct rtc_time *to)
{
- struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
- struct rk808 *rk808 = rk808_rtc->rk808;
- u8 rtc_data[NUM_TIME_REGS];
- int ret;
-
- /* Force an update of the shadowed registers right now */
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
-BIT_RTC_CTRL_REG_RTC_GET_TIME,
-BIT_RTC_CTRL_REG_RTC_GET_TIME);
- if (ret) {
- dev_err(dev, "Failed to update bits rtc_ctrl: %d\n", ret);
- return ret;
- }
-
- /*
-* After we set the GET_TIME bit, the rtc time can't be read
-* immediately. So we should wait up to 31.25 us, about one cycle of
-* 32khz. If we clear the GET_TIME bit here, the time of i2c transfer
-* certainly more than 31.25us: 16 * 2.5us at 400kHz bus frequency.
-*/
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
-BIT_RTC_CTRL_REG_RTC_GET_TIME,
-0);
- if (ret) {
- dev_err(dev, "Failed to update bits rtc_ctrl: %d\n", ret);
- return ret;
- }
+ int extra_days = to->tm_year - from->tm_year;
- ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG,
- rtc_data, NUM_TIME_REGS);
- if (ret) {
- dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
- return ret;
- }
+ /* Avoid adjusting anything for uninitialized timestamps */
+ if (from->tm_mday == 0 || to->tm_mday == 0)
+ re
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> Still, you're right that adding the GET_TIME check wouldn't hurt... at > worst it just does nothing. I'll try it out. Hmm... so it basically works (when you hack the RTC read out of the firmware), but only on reboot for some reason (which makes it way less useful). After a full power off I'm reading only zeroes out until I transition GET_TIME again. My guess would be that these shadow registers are not in the RTC power well... I've talked to Alex and he said that we disable the RK808's main power source in S5, but that devices without an EC (e.g. phones) would likely leave it on. So I guess it's still a good extra workaround to keep in the code, but it will never help on Chromebooks (and there's no point in hacking up our firmware for it). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> Technically you could still implement this and if firmware happens to > read the RTC (and doesn't correct things) then we won't be able to > correct things. ...but certainly if you read the old time and then > the new time and the old time was < 11/31 and the new time was >= > 11/31 you know you need to correct. > > I'd say that there's a good chance that other firmware (UBoot) doesn't > actually read the RTC anyway. Why would it? We only do it for even > log, right? Hah! Sounds like you assume U-Boot was doing the things it does with comprehensible reasoning. From my experience, that's a dangerous wager (not that I'm biased or anything... ;) ). FWIW, they seem to be having a huge (175kloc, of only the finest copied kernel code from 10+ years ago, I presume) repository of RTC drivers, a separate command line command to read/write to it, and an SNTP client. Still, you're right that adding the GET_TIME check wouldn't hurt... at worst it just does nothing. I'll try it out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
[+Alexandre... sorry, didn't notice that you somehow fell off the thread again, but I presume you get rtc-linux anyway] > Agreed, scheduling alarms in the future is also an important point. So > I guess I'll update the patch to fix alarm scheduling and S3 as well, > and we'll just ignore S5 as infeasible? Found another edge case trying to implement this: if you set an alarm on Nov 25th for Dec 5th, the code will have to adjust it to Dec 4th to account for the extra day. But if you then power off (or brownout) to S5 and don't power it on again until December, you have no way of knowing whether the already set alarm timestamp is on the Rockchip or the Gregorian calendar. You may or may not sync your current time back through an external source, but you have no way of knowing what you should do with the alarm. Other than that my current idea is roughly: - if the current time gets written, always assume the new date is correct - store a "last known timestamp" in memory on boot and on every write - if the current time gets read, adjust it forward by the amount of Nov 31sts since the stored timestamp (this adjustment itself constitutes a write) - if an alarm is written, adjust the timestamp written to hardware backward by the amount of Nov 31sts between the stored timestamp and the alarm time - if an alarm is read, adjust the returned result forward by the amount of Nov 31sts between the stored timestamp and the alarm time - if the current time gets written, read the alarm time before the write and write it back afterwards (the last known timestamp will change as a result of writing the current time, meaning the newly written hardware alarm time may be different from the old one) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> I was presuming that alarms were never set at power off time unless > power off happened due to an exceptional case. AKA: normal Linux > shutdown disables all alarms. Hmm... maybe I misunderstand how this works. Are alarms never used to wake from S5? (It doesn't seem to work on my HiSense Chromebook right now, but maybe that's just an artifact of our board design? I'm pretty sure I've seen S5-wakes work on other platforms... I doubt that RK808 is intrinsically incapable of that, it just depends on how you hook it up.) > RK808 has a shadowed register for saving a "frozen" RTC time. > When we setting "GET_TIME" to 1, the time will save in this shadowed > register. So if we do not set the "GET_TIME", we always get the last > time. > > read the old time before "get_time", and then read the time again for new > time. If the old time earlier than 12.1 && new time later than 12.1, we should > +1 day for the correct rtc time. Unfortunately, this doesn't work through S5 if system firmware also accesses the RTC and transitions GET_TIME on boot (which it does on Chromebooks). We could fix this for coreboot, but it's probably still a bad idea to rely on it since Linux should be as firmware-agnostic as possible. > I'm pretty certain that we need to handle correcting the alarm. > Setting an alarm for 10 seconds from now and getting the alarm firing > 1 day and 10 seconds from now seems like a pretty huge problem, at > least for any system that relies on the RTC alarm a lot. That pretty > much means that we need some way to identify problematic devices. > ...so I think if we have no revision register then we should either > assume all rk808 devices have this problem (and hope and pray that > Rockchip gives us a way to ID things if they ever add a fix) or come > up with some other type of solution (probe one time when the clock is > presumably wrong and store something somewhere in rk808 to indicate > that we've already probed) > Once we have to fix the alarm, handling S3 seems like it will be not > much more work. Agreed, scheduling alarms in the future is also an important point. So I guess I'll update the patch to fix alarm scheduling and S3 as well, and we'll just ignore S5 as infeasible? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi/spi-fsl-espi.c: Add spi cs polarity support
Add CS polarity flag to be able to set the CS polarity via the DT property spi-cs-high. Signed-off-by: Andreas Werner --- drivers/spi/spi-fsl-espi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c index c27124a..2dc70953 100644 --- a/drivers/spi/spi-fsl-espi.c +++ b/drivers/spi/spi-fsl-espi.c @@ -495,7 +495,7 @@ static int fsl_espi_setup(struct spi_device *spi) ®_base->csmode[spi->chip_select]); /* mask out bits we are going to set */ cs->hw_mode &= ~(CSMODE_CP_BEGIN_EDGECLK | CSMODE_CI_INACTIVEHIGH -| CSMODE_REV); +| CSMODE_REV | CSMODE_POL_1); if (spi->mode & SPI_CPHA) cs->hw_mode |= CSMODE_CP_BEGIN_EDGECLK; @@ -503,6 +503,8 @@ static int fsl_espi_setup(struct spi_device *spi) cs->hw_mode |= CSMODE_CI_INACTIVEHIGH; if (!(spi->mode & SPI_LSB_FIRST)) cs->hw_mode |= CSMODE_REV; + if (!(spi->mode & SPI_CS_HIGH)) + cs->hw_mode |= CSMODE_POL_1; /* Handle the loop mode */ loop_mode = mpc8xxx_spi_read_reg(®_base->mode); -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> If you set the alarm > for Dec 25th and it's currently Oct 31st then you'll have to adjust in > the alarm code and you'll really set it for Dec 24th. As per above, > we're in S3 (presumably) or have some persistent kernel state so we > know to adjust everything when we wake up (even if we wake up for a > non-alarm reason). How do you deal with the case where you set an alarm in late December, but you then power the system on earlier in December by other means? I think then you couldn't tell if the fix had already been applied? > You'll still get a failure if you set the alarm and then forcibly go > into S5 without software knowledge, then stay in S5 long enough to > cross over Nov 31st without seeing it (but somehow keep the RTC > state). ...but come on, that seems so incredibly rare! :-P I think you could just set it to "November 31st, disabled" at probe time (if it isn't already) and keep it like that indefinitely? I think as long as you don't need to actually use the alarm, that would work fine. Still, with the vast majority of practically existing devices with an RK808 almost constantly connected to some network, I'm not sure if a huge hack-around is really worth it here. (I guess we could still just do the S3 thing which is much less complicated, assuming we can guarantee correct identification.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> How would such a hook work? If userspace sees the system suspend on > Nov 30th and sees the system wake up on Dec 1st, how does it know > whether it should adjust? If it's truly Dec 1st then the kernel will > have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec > 2nd then the kernel will not have adjusted the date and the RTC will > have ticked past Nov 31 and onto Dec 1st. Userspace can't tell. > Userspace could try to parse "dmesg" and look to see if the kernel > adjusted, but that's ugly. Good point, I didn't think that through far enough. I guess parsing dmesg would be an option, but a pretty ugly one and it wouldn't be guaranteed to work if you got an early boot kernel crash after the correction. So, really, it seems like there's no reliable way to fix this for S5 (unless we start doing crazy things like writing to disk from kernel code). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> If a device is in S3 for the whole day that the glitch occurs and then > we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd, > right? That case _could_ be handled by knowing that the last time we > read the clock it was before 12/1 and that this time it is after > 11/30. Then we add the extra day. In order to do this, we'd have to > know that we're on hardware with the glitch, which I guess could > either be done with a device tree property or by spending 1 second > probing the device at bootup (that would be a bit of a pain...). > > Obviously the trick above wouldn't handle if the clock ticked when the > device was in S5, but I'd imagine that most systems treat the RTC as > slightly questionable on an initial bootup anyway (though I'd imagine > that they rely on it working across S3). True, we could do that. I don't think it makes much sense to differentiate between S3 and S5 like that, though... the problem can happen just the same after both, and I don't think there's a practical difference in how systems treat that (if userspace has ways to double-check the system time, such as syncing to a network time source, it should really be doing that after both resume and reboot). Of course, building a work-around like that for S5 will become more complicated and requires persistent storage. For Chromium OS, we're already planning to improve tlsdated such that I don't think this will be an issue anymore (making it schedule a resync after resume, not just after reboot, which is a probably a good idea in general). For other systems that don't have any kind of network time sync, I think the best solution would be to handle this completely with a small userspace hook on boot and resume (because you probably need to access the file system to keep track of the last seen time anyway, you can do the device identification through /proc/device-tree just as well, and this avoids putting too much hacky workaround logic into the kernel). The other thing that would worry me about this approach is that it requires perfect identification of the problem, and Rockchip will hopefully eventually be able to fix this either in RK808 or a successor chip that might use the same RTC interface (and thus driver). Detecting it at boot is probably a bad idea because a crash/brownout at the wrong moment will permanently leave you with a bad time. I really think fixing this as best as we easily can and leaving the hard edge-cases to userspace is the best approach here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v2 2/2] ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller for log page reads
Every attempt to issue a read log page command lockup the controller.
The command is currently sent if the sata device includes the devlsp feature
to read out the timing data.
This attempt to read the data, locks up the controller and the device
is not recognzied correctly (failed to set xfermode) and cannot be accessed.
This was found on Freescale P1013/P1022 and T4240 CPUs
using a ATP IG mSATA 4GB with the devslp feature.
fsl-sata ff718000.sata: Sata FSL Platform/CSB Driver init
[1.254195] scsi0 : sata_fsl
[1.256004] ata1: SATA max UDMA/133 irq 74
[1.370666] fsl-gianfar ethernet.3: enabled errata workarounds, flags: 0x4
[1.470671] fsl-gianfar ethernet.4: enabled errata workarounds, flags: 0x4
[1.775584] ata1: Signature Update detected @ 504 msecs
[1.947594] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.948366] ata1.00: ATA-8: ATP IG mSATA, 20150311, max UDMA/133
[1.948371] ata1.00: 7732368 sectors, multi 0: LBA
[1.948843] ata1.00: failed to get Identify Device Data, Emask 0x1
[1.948857] ata1.00: failed to set xfermode (err_mask=0x40)
[7.467557] ata1: Signature Update detected @ 504 msecs
[7.639560] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[7.651320] ata1.00: failed to get Identify Device Data, Emask 0x1
[7.651360] ata1.00: failed to set xfermode (err_mask=0x40)
[7.655628] ata1: limiting SATA link speed to 1.5 Gbps
[7.659458] ata1.00: limiting speed to UDMA/133:PIO3
[ 13.163554] ata1: Signature Update detected @ 504 msecs
[ 13.335558] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 13.347298] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 13.347334] ata1.00: failed to set xfermode (err_mask=0x40)
[ 13.351601] ata1.00: disabled
[ 13.353278] ata1: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen
t4
[ 13.359281] ata1: SError: { HostInt }
[ 13.361644] ata1: hard resetting link
Signed-off-by: Andreas Werner
---
drivers/ata/sata_fsl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 5389579..a723ae9 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -45,7 +45,8 @@ enum {
SATA_FSL_MAX_PRD_DIRECT = 16, /* Direct PRDT entries */
SATA_FSL_HOST_FLAGS = (ATA_FLAG_SATA | ATA_FLAG_PIO_DMA |
- ATA_FLAG_PMP | ATA_FLAG_NCQ | ATA_FLAG_AN),
+ ATA_FLAG_PMP | ATA_FLAG_NCQ |
+ ATA_FLAG_AN | ATA_FLAG_NO_LOG_PAGE),
SATA_FSL_MAX_CMDS = SATA_FSL_QUEUE_DEPTH,
SATA_FSL_CMD_HDR_SIZE = 16, /* 4 DWORDS */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v2 1/2] libata-eh.c: Introduce new ata port flag for controller which lockup on read log page
Some controller lockup on a ata_read_log_page.
Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
to blacklist a controller.
If this flag is set, any attempt to read a log page returns an error
without actually issuing the command.
Signed-off-by: Andreas Werner
---
drivers/ata/libata-eh.c | 9 +
include/linux/libata.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index cb0508a..c59c2bc 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1505,12 +1505,21 @@ static const char *ata_err_string(unsigned int err_mask)
unsigned int ata_read_log_page(struct ata_device *dev, u8 log,
u8 page, void *buf, unsigned int sectors)
{
+ unsigned long ap_flags = dev->link->ap->flags;
struct ata_taskfile tf;
unsigned int err_mask;
bool dma = false;
DPRINTK("read log page - log 0x%x, page 0x%x\n", log, page);
+ /*
+* Return error without actually issuing the
+* command on controller which e.g. lockup
+* on a read log page.
+*/
+ if (ap_flags & ATA_FLAG_NO_LOG_PAGE)
+ return AC_ERR_DEV;
+
retry:
ata_tf_init(dev, &tf);
if (dev->dma_mode && ata_id_has_read_log_dma_ext(dev->id) &&
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 83577f8..600c1e0 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -210,6 +210,7 @@ enum {
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
/* (doesn't imply presence) */
ATA_FLAG_SATA = (1 << 1),
+ ATA_FLAG_NO_LOG_PAGE= (1 << 5), /* do not issue log page read */
ATA_FLAG_NO_ATAPI = (1 << 6), /* No ATAPI support */
ATA_FLAG_PIO_DMA= (1 << 7), /* PIO cmds via DMA */
ATA_FLAG_PIO_LBA48 = (1 << 8), /* Host DMA engine is LBA28 only */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v2 0/2] ata/libata-eh.c: introduce ATA_FLAG_NO_LOG_PAGE
This patchset add a new ata port flag ATA_FLAG_NO_LOG_PAGE to be able to blacklist ports/controller which e.g. locks up on a log page read. This flag is added to the sata_fsl driver which is the first affected one. The lockup was detected on Freescale P1013/P1022, T4240 using a ATP mSATA. The device failed during initialisation if the SATA device includes the devslp feature. With this patchset, we blacklist the fsl sata controller and return a error on any attempt to read a log page. This allows us to access the mSATA. Changes in v2: fixed the build issue detected by the kbuild test robot Andreas Werner (2): libata-eh.c: Introduce new ata port flag for controller which lockup on read log page ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller for log page reads drivers/ata/libata-eh.c | 9 + drivers/ata/sata_fsl.c | 3 ++- include/linux/libata.h | 1 + 3 files changed, 12 insertions(+), 1 deletion(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:# libata: introduce ATA_FLAG_NO_LOG_PAGE
Hi, argh sorry send the wrong patches from a broken tree. Will send a v2 Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller for log page reads
Every attempt to issue a read log page command lockup the controller.
The command is currently sent if the sata device includes the devlsp feature
to read out the timing data.
This attempt to read the data, locks up the controller and the device
is not recognzied correctly (failed to set xfermode) and cannot be accessed.
This was found on Freescale P1013/P1022 and T4240 CPUs
using a ATP IG mSATA 4GB with the devslp feature.
fsl-sata ff718000.sata: Sata FSL Platform/CSB Driver init
[1.254195] scsi0 : sata_fsl
[1.256004] ata1: SATA max UDMA/133 irq 74
[1.370666] fsl-gianfar ethernet.3: enabled errata workarounds, flags: 0x4
[1.470671] fsl-gianfar ethernet.4: enabled errata workarounds, flags: 0x4
[1.775584] ata1: Signature Update detected @ 504 msecs
[1.947594] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.948366] ata1.00: ATA-8: ATP IG mSATA, 20150311, max UDMA/133
[1.948371] ata1.00: 7732368 sectors, multi 0: LBA
[1.948843] ata1.00: failed to get Identify Device Data, Emask 0x1
[1.948857] ata1.00: failed to set xfermode (err_mask=0x40)
[7.467557] ata1: Signature Update detected @ 504 msecs
[7.639560] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[7.651320] ata1.00: failed to get Identify Device Data, Emask 0x1
[7.651360] ata1.00: failed to set xfermode (err_mask=0x40)
[7.655628] ata1: limiting SATA link speed to 1.5 Gbps
[7.659458] ata1.00: limiting speed to UDMA/133:PIO3
[ 13.163554] ata1: Signature Update detected @ 504 msecs
[ 13.335558] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 13.347298] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 13.347334] ata1.00: failed to set xfermode (err_mask=0x40)
[ 13.351601] ata1.00: disabled
[ 13.353278] ata1: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen
t4
[ 13.359281] ata1: SError: { HostInt }
[ 13.361644] ata1: hard resetting link
Signed-off-by: Andreas Werner
---
drivers/ata/sata_fsl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 5389579..a723ae9 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -45,7 +45,8 @@ enum {
SATA_FSL_MAX_PRD_DIRECT = 16, /* Direct PRDT entries */
SATA_FSL_HOST_FLAGS = (ATA_FLAG_SATA | ATA_FLAG_PIO_DMA |
- ATA_FLAG_PMP | ATA_FLAG_NCQ | ATA_FLAG_AN),
+ ATA_FLAG_PMP | ATA_FLAG_NCQ |
+ ATA_FLAG_AN | ATA_FLAG_NO_LOG_PAGE),
SATA_FSL_MAX_CMDS = SATA_FSL_QUEUE_DEPTH,
SATA_FSL_CMD_HDR_SIZE = 16, /* 4 DWORDS */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] libata-eh.c: Introduce new ata port flag for controller which lockup on read log page
Some controller lockup on a ata_read_log_page.
Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
to blacklist a controller.
If this flag is set, any attempt to read a log page returns an error
without actually issuing the command.
Signed-off-by: Andreas Werner
---
drivers/ata/libata-eh.c | 9 +
include/linux/libata.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index cb0508a..f3e6277 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1505,12 +1505,21 @@ static const char *ata_err_string(unsigned int err_mask)
unsigned int ata_read_log_page(struct ata_device *dev, u8 log,
u8 page, void *buf, unsigned int sectors)
{
+ unsigned long ap_flags = dev->link->ap->flags;
struct ata_taskfile tf;
unsigned int err_mask;
bool dma = false;
DPRINTK("read log page - log 0x%x, page 0x%x\n", log, page);
+ /*
+* Return error without actually issuing the
+* command on controller which e.g. lockup
+* on a read log page.
+*/
+ if (flags & ATA_FLAG_NO_LOG_PAGE)
+ return AC_ERR_DEV;
+
retry:
ata_tf_init(dev, &tf);
if (dev->dma_mode && ata_id_has_read_log_dma_ext(dev->id) &&
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 83577f8..600c1e0 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -210,6 +210,7 @@ enum {
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
/* (doesn't imply presence) */
ATA_FLAG_SATA = (1 << 1),
+ ATA_FLAG_NO_LOG_PAGE= (1 << 5), /* do not issue log page read */
ATA_FLAG_NO_ATAPI = (1 << 6), /* No ATAPI support */
ATA_FLAG_PIO_DMA= (1 << 7), /* PIO cmds via DMA */
ATA_FLAG_PIO_LBA48 = (1 << 8), /* Host DMA engine is LBA28 only */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] libata: introduce ATA_FLAG_NO_LOG_PAGE
This patchset add a new ata port flag ATA_FLAG_NO_LOG_PAGE to be able to blacklist ports/controller which e.g. locks up on a log page read. This flag is added to the sata_fsl driver which is the first affected one. The lockup was detected on Freescale P1013/P1022, T4240 using a ATP mSATA. The device failed during initialisation if the SATA device includes the devslp feature. With this patchset, we blacklist the fsl sata controller and return a error on any attempt to read a log page. This allows us to access the mSATA. Andreas Werner (2): libata-eh.c: Introduce new ata port flag for controller which lockup on read log page ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller for log page reads drivers/ata/libata-eh.c | 9 + drivers/ata/sata_fsl.c | 3 ++- include/linux/libata.h | 1 + 3 files changed, 12 insertions(+), 1 deletion(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH] RTC: RK808: Work around hardware bug on November 31st
> I would have liked to be in copy of that mail. Maybe you used > get_maintainers on an old tree? Oops, yes, sorry, I ran it on a 3.14 backport and then just added people I found in older patches for that file. > I hope reading the time properly fails thanks to the rtc_valid_tm(tm) in > __rtc_read_time(). It should, yeah. I haven't tested it (beyond compiling) on master, and our version doesn't have that code yet, so I can't say for sure. > It will also happen if nobody reads the RTC time for that day (highly > improbable in a default configuration). Do you need that patch for 4.4 > or can it wait 4.5? True. I don't really need the patch to land in a particular release since we maintain our own tree with backports. It would probably still be nice if you can get it into the 4.4 LTS to reduce the chance this will hit anyone again next year. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata-core: devslp fails on ATP mSATA
On Thu, Dec 03, 2015 at 10:15:49AM -0500, Tejun Heo wrote: > Hello, > > On Thu, Dec 03, 2015 at 10:33:55AM +0100, Andreas Werner wrote: > > All the other "flag" fields in the structs are used and/or reserved > > and it seems to be no good place for such flags. > > You can use the port flags - ATA_FLAG_*. > > > What I am thinking about is. > > > > 1. Add new flag e.g. ATA_HORKAGE_NOLOG_PAGE_RD > > ATA_FLAG_NO_LOG_PAGE? That seems to be much more simpler than my idea :-) Did not see the port stuff, i was focused on the host struct. Thank you for the hint. I will prepare a Patch next week. > > Thanks. > > -- > tejun Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata-core: devslp fails on ATP mSATA
On Wed, Dec 02, 2015 at 11:47:53AM -0500, Tejun Heo wrote: > Hello, Andreas. > > On Wed, Dec 02, 2015 at 10:33:10AM +0100, Andreas Werner wrote: > > Blacklisting the controller would be a solution yes, but I just > > wanna wait the answer from the FAE to be sure we really have a > > problem. > > > > What kind of identifier can I use for blacklisting? The driver name > > from the host driver? (fsl-sata) I did not find any register > > in the sata controller to read out an ID. > > Whatever matches the affected controllers. If all sata_fsl > controllers are affected, the driver init code can set the flag > unconditionally. > > Thanks. > > -- > tejun Ok, setting the flag in the controller driver would be good. (still wating for the FAE for more info). As I can see the horkage field is only defind in "struct ata_dev" would it be time to add a horkage field to "struct ata_host"? All the other "flag" fields in the structs are used and/or reserved and it seems to be no good place for such flags. What I am thinking about is. 1. Add new flag e.g. ATA_HORKAGE_NOLOG_PAGE_RD 2. Add horkage field to ata_host struct 2. Set this flag in ata_host struct in the sata_fsl driver (init) 3. Copy the controller horkage flags over to struct ata_device in the ata_dev_configure function in libata At the end all flags set by the controller are applied to the ata device horkage flags, and can be used for blacklisting in libata. May be there are better solution, or i am missing something. What do you think about it? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RTC: RK808: Work around hardware bug on November 31st
In Fuzhou, China, the month of November seems to be having 31 days.
That's nice and all (I'm sure you can get a lot more done in a year that
way), but back here in other parts of the world we are not so lucky.
Therefore, if we read that date from the RTC we should correct it to
December 1st.
This is not a full workaround. Since the RTC actually ticks all the way
through that imaginary day, there's no easy way to detect and correct
this issue if the device was offline the whole time and allowed it to
tick through to December 1st on the Rockchip calendar (which would be
December 2nd on the Gregorian one). Those edge cases can only really be
solved by regularly syncing to an external time source (e.g. NTP).
Signed-off-by: Julius Werner
Reviewed-by: Chris Zhong
---
drivers/rtc/rtc-rk808.c | 93 ++---
1 file changed, 50 insertions(+), 43 deletions(-)
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 91ca0bc..b605b35 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -56,6 +56,50 @@ struct rk808_rtc {
int irq;
};
+/* Set current time and date in RTC */
+static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
+ struct rk808 *rk808 = rk808_rtc->rk808;
+ u8 rtc_data[NUM_TIME_REGS];
+ int ret;
+
+ rtc_data[0] = bin2bcd(tm->tm_sec);
+ rtc_data[1] = bin2bcd(tm->tm_min);
+ rtc_data[2] = bin2bcd(tm->tm_hour);
+ rtc_data[3] = bin2bcd(tm->tm_mday);
+ rtc_data[4] = bin2bcd(tm->tm_mon + 1);
+ rtc_data[5] = bin2bcd(tm->tm_year - 100);
+ rtc_data[6] = bin2bcd(tm->tm_wday);
+ dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
+ 1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+ tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
+
+ /* Stop RTC while updating the RTC registers */
+ ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+BIT_RTC_CTRL_REG_STOP_RTC_M,
+BIT_RTC_CTRL_REG_STOP_RTC_M);
+ if (ret) {
+ dev_err(dev, "Failed to update RTC control: %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_bulk_write(rk808->regmap, RK808_SECONDS_REG,
+ rtc_data, NUM_TIME_REGS);
+ if (ret) {
+ dev_err(dev, "Failed to bull write rtc_data: %d\n", ret);
+ return ret;
+ }
+ /* Start RTC again */
+ ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+BIT_RTC_CTRL_REG_STOP_RTC_M, 0);
+ if (ret) {
+ dev_err(dev, "Failed to update RTC control: %d\n", ret);
+ return ret;
+ }
+ return 0;
+}
+
/* Read current time and date in RTC */
static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
{
@@ -105,51 +149,14 @@ static int rk808_rtc_readtime(struct device *dev, struct
rtc_time *tm)
1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
- return ret;
-}
-
-/* Set current time and date in RTC */
-static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
-{
- struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
- struct rk808 *rk808 = rk808_rtc->rk808;
- u8 rtc_data[NUM_TIME_REGS];
- int ret;
-
- rtc_data[0] = bin2bcd(tm->tm_sec);
- rtc_data[1] = bin2bcd(tm->tm_min);
- rtc_data[2] = bin2bcd(tm->tm_hour);
- rtc_data[3] = bin2bcd(tm->tm_mday);
- rtc_data[4] = bin2bcd(tm->tm_mon + 1);
- rtc_data[5] = bin2bcd(tm->tm_year - 100);
- rtc_data[6] = bin2bcd(tm->tm_wday);
- dev_dbg(dev, "set RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
- 1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
- tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
-
- /* Stop RTC while updating the RTC registers */
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
-BIT_RTC_CTRL_REG_STOP_RTC_M,
-BIT_RTC_CTRL_REG_STOP_RTC_M);
- if (ret) {
- dev_err(dev, "Failed to update RTC control: %d\n", ret);
- return ret;
+ if (tm->tm_mon == 10 && tm->tm_mday == 31) {
+ dev_warn(dev, "correcting Nov 31st to Dec 1st (HW bug)\n");
+ tm->tm_mon = 11;
+ tm->tm_mday = 1;
+ rk808_rtc_set_time(dev, tm);
}
- ret = regmap_bulk_write(rk808->regmap, RK808_SECONDS_REG,
-
Re: libata-core: devslp fails on ATP mSATA
On Tue, Dec 01, 2015 at 02:04:10PM -0500, Tejun Heo wrote:
> On Tue, Dec 01, 2015 at 11:17:15AM -0500, Tejun Heo wrote:
> > So, I suppose this is a fallout from 9faa643855df ("libata: use
> > READ_LOG_DMA_EXT"). The description just says "we should try use it"
> > but is there any benefit from using NCQ variant of read log page? I
> > mean, it's used during config and error handling, so it's not like
> > queueing is gonna help anything. It ends up issuing NCQ commands on
> > controllers which don't support NCQ and causes failures on devices
> > which lie about supporting the feature.
>
> Hmmm... so, the controller locks up on READ_LOG_EXT issued as pio?
> That's just weird. I suppose you can blacklist the controller so that
> any attempt to read the log page fails without actually issuing the
> command.
>
> Thanks.
>
> --
> tejun
Hi,
yes since i am using 3.14 where the READ_LOG_DMA_EXT is not it, it
seems that the controller locks up even on READ_LOG_EXT as PIO.
I have checked the current ERRATA sheet of the CPU but there
are no issues regarding this problem.
Test on a Freescale T4240 show the same behaviour as on P1013/P1022.
It seems that some FSL Cpus are affected.
I have asked my FAE at Freescale if he has some information about
that kind of issue.
Blacklisting the controller would be a solution yes, but I just
wanna wait the answer from the FAE to be sure we really have a
problem.
What kind of identifier can I use for blacklisting? The driver name
from the host driver? (fsl-sata) I did not find any register
in the sata controller to read out an ID.
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata-core: devslp fails on ATP mSATA
Hi,
first sorry for the bad email format, but the IT decided to add my Email
signature as HTML
on the Exchange Server, this is why lkml rejected the email.
Therefore I will switch to my private address.
I do not think that the commit you mention is the root cause for this problem,
because it is mainline since 4.1 but i am currently using the 3.14 kernel.
In 3.14 there is only ATA_CMD_READ_LOG_EXT for the command and
ATA_PROT_PIO as the protocol.
Commit ID:
9faa643855df ("libata: useREAD_LOG_DMA_EXT")
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] usb: dwc2: hcd: fix split schedule issue
> To handle things smarter, I think I need to research how to deal with > hubs attached to hubs attached to hubs. For instance: > > dwc2 > -> multi_tt hub > -> single_tt hub > -> device 1 > -> device 2 Keep in mind that there's always at most one (active) TT between host and device. The TT is the point where high-speed traffic is translated to low-/full-speed traffic, so after that you cannot translate again. With multiple hubs you either have -> high-speed 2.0 hub (TT inactive / irrelevant for this path) -> multi or single TT 2.0 hub -> device or -> multi or single TT 2.0 hub -> full-speed 1.1 hub -> device All the information you need should already be in struct usb_device. If udev->tt->multi == 0, then it must be scheduled in the same group as all other devices it shares udev->tt (the same pointer address) with. If udev->tt->multi == 1, then it belongs in the same group as all that have the same udev->tt and the same udev->ttport. There's even a udev->tt->hcpriv where you could link a data structure (array) in to keep track of these matching devices. I agree that this is a nice-to-have optimization, though... it's more important to get the thing stable, and I think it's fine to assume that all low-/full-speed transfers go on the same bus for the first iteration. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions
Another point to note, which I think is what prevents the flow Alan
suggested from working, is this little snippet in DWC2's hub_control
GetPortStatus callback:
if (!hsotg->flags.b.port_connect_status) {
/*
* The port is disconnected, which means the core is
* either in device mode or it soon will be.
Just
* return 0's for the remainder of the port status
* since the port register can't be read if the core
* is in device mode.
*/
*(__le32 *)buf = cpu_to_le32(port_status);
break;
}
This is before it actually checks the register state of the port. So
it relies on dwc2_hcd_connect() and dwc2_hcd_disconnect() to be called
in the right order to give the correct answer for
USB_PORT_STAT_CONNECTION. This could maybe be improved but I don't
know what kind of weird interactions with device mode operation made
that snippet necessary in the first place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: Add driver for MEN 16Z127 GPIO controller
Yet another thing. if i will implement the open drain support, does it really makes sense to go with the generic gpio lib? I need to replace the direction_input and direction_outpu functions because if the userland set an open drain pin to input i need to set the pin to High-Z (driver "1") instead of setting the input bit in the direction register. So at the end there are just the "set" and "dat" functions used to drive an output and to get an input state. Alle other functions needs to be implemented in the driver. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: Add driver for MEN 16Z127 GPIO controller
Hi, i have an additional question regarding the Open Drain setting. The register is currently impelemented as a read/write register which means the pin mode is configurable by software to Push Pull or Open Drain. There is also the possiblity (normal way) that the HW (FPGA) configures each pin to the correct mode. Is there actually a way to set an output mode from userland or by the gpio API? I did not find anything about that. If there is no way, i will implement it without software control. I just read out the mode configuration and handle the pins as PP or Open Drain. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: Add driver for MEN 16Z127 GPIO controller
On Tue, Oct 06, 2015 at 09:35:51AM +0200, Linus Walleij wrote: > On Mon, Oct 5, 2015 at 8:09 PM, Andreas Werner wrote: > > > The 16Z127 is a GPIO controller on a MCB FPGA and has 32 > > configurable GPIOs. > > The GPIOs can be configured as inputs and outputs > > > > Signed-off-by: Andreas Werner > > This driver looks like it can use the generic MMIO library. Yes you are right, did not know about the gener MMIO lib but seems to be the right think for this driver. I will change that. > > select GPIO_GENERIC > #include > > Then look at example for how to do this, e.g. > drivers/gpio/gpio-74xx-mmio.c > > > +config GPIO_MENZ127 > > + tristate "MEN 16Z127 GPIO support" > > + depends on MCB > > Is this "MCB" symbol already upstream? It seems a bit short. > Yes MCB is already upstream and there is alreay a driver upstream named men_Z135_uart. MCB is called "MEN Chameleon Bus" which is out FPGA. The FPGA implements a table named "Chameleon Table" which describes the IPs in the FPGA. > > +#include > > +#include > > +#include > > +#include > > +#include > > Just > #include > OK, will change that. > > +#define MEN_Z127_CTRL 0x00 > > +#define MEN_Z127_PSR 0x04 > > +#define MEN_Z127_IRQR 0x08 > > +#define MEN_Z127_GPIODR0x0c > > +#define MEN_Z127_IER1 0x10 > > +#define MEN_Z127_IER2 0x14 > > It looks like it has interrupt support? > Yes there is an Interrupt support but not completly implemented in HW. My IC designer is currently in holiday and he is planned to do the IRQ work in a few weeks (month). The plan was to start without IRQ support and get the driver upstream. > > +#define MEN_Z127_DBER 0x18 > > Debounce? In that case, maybe implement .set_debounce from day 1? Yes did not want to implement this from day 1, but i think you are right I should do that, its not a complicated thing :-) > > > +#define MEN_Z127_ODER 0x1C > > And Open Drain? Maybe you should support that from day 1? > Need to check if this is current implementation is working, but should be no problem to implement this. > Yours, > Linus Walleij Thanks for your comments. I will send a v2 today or tomorrow. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: Add driver for MEN 16Z127 GPIO controller
The 16Z127 is a GPIO controller on a MCB FPGA and has 32
configurable GPIOs.
The GPIOs can be configured as inputs and outputs
Signed-off-by: Andreas Werner
---
drivers/gpio/Kconfig| 6 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-menz127.c | 186
3 files changed, 193 insertions(+)
create mode 100644 drivers/gpio/gpio-menz127.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8949b3f..329ebc4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -269,6 +269,12 @@ config GPIO_MB86S7X
help
Say yes here to support the GPIO controller in Fujitsu MB86S70 SoCs.
+config GPIO_MENZ127
+ tristate "MEN 16Z127 GPIO support"
+ depends on MCB
+ help
+Say yes here to support the MEN 16Z127 GPIO Controller.
+
config GPIO_MM_LANTIQ
bool "Lantiq Memory mapped GPIOs"
depends on LANTIQ && SOC_XWAY
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..2c48751 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_GPIO_MB86S7X)+= gpio-mb86s7x.o
obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o
obj-$(CONFIG_GPIO_MCP23S08)+= gpio-mcp23s08.o
+obj-$(CONFIG_GPIO_MENZ127) += gpio-menz127.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o
obj-$(CONFIG_GPIO_MOXART) += gpio-moxart.o
diff --git a/drivers/gpio/gpio-menz127.c b/drivers/gpio/gpio-menz127.c
new file mode 100644
index 000..599e61a
--- /dev/null
+++ b/drivers/gpio/gpio-menz127.c
@@ -0,0 +1,186 @@
+/*
+ * MEN 16Z127 GPIO driver
+ *
+ * Copyright (C) 2015 MEN Mikroelektronik GmbH (www.men.de)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MEN_Z127_CTRL 0x00
+#define MEN_Z127_PSR 0x04
+#define MEN_Z127_IRQR 0x08
+#define MEN_Z127_GPIODR0x0c
+#define MEN_Z127_IER1 0x10
+#define MEN_Z127_IER2 0x14
+#define MEN_Z127_DBER 0x18
+#define MEN_Z127_ODER 0x1C
+
+struct men_z127_gpio {
+ struct gpio_chip chip;
+ void __iomem *reg_base;
+ struct mcb_device *mdev;
+ struct resource *mem;
+ spinlock_t lock;
+};
+#define to_men_z127_gpio(gc) container_of(gc, struct men_z127_gpio, chip)
+
+static void men_z127_mod_reg(struct gpio_chip *chip, u32 reg, unsigned gpio,
+int val)
+{
+ struct men_z127_gpio *men_z127_gpio;
+ u32 reg_val;
+
+ men_z127_gpio = to_men_z127_gpio(chip);
+
+ spin_lock(&men_z127_gpio->lock);
+ reg_val = readl(men_z127_gpio->reg_base + reg);
+
+ if (val)
+ reg_val |= BIT(gpio);
+ else
+ reg_val &= ~BIT(gpio);
+
+ writel(reg_val, men_z127_gpio->reg_base + reg);
+ spin_unlock(&men_z127_gpio->lock);
+}
+
+static void men_z127_set_reg(struct gpio_chip *chip, u32 reg, unsigned gpio)
+{
+ men_z127_mod_reg(chip, reg, gpio, 1);
+}
+
+static void men_z127_clr_reg(struct gpio_chip *chip, u32 reg, unsigned gpio)
+{
+ men_z127_mod_reg(chip, reg, gpio, 0);
+}
+
+static int men_z127_dir_output(struct gpio_chip *chip, unsigned gpio,
+ int value)
+{
+ men_z127_set_reg(chip, MEN_Z127_GPIODR, gpio);
+ return 0;
+}
+
+static int men_z127_dir_input(struct gpio_chip *chip, unsigned gpio)
+{
+
+ men_z127_clr_reg(chip, MEN_Z127_GPIODR, gpio);
+ return 0;
+}
+
+static void men_z127_set(struct gpio_chip *chip, unsigned gpio, int value)
+{
+ if (value)
+ men_z127_set_reg(chip, MEN_Z127_CTRL, gpio);
+ else
+ men_z127_clr_reg(chip, MEN_Z127_CTRL, gpio);
+}
+
+static int men_z127_get(struct gpio_chip *chip, unsigned gpio)
+{
+ struct men_z127_gpio *men_z127_gpio;
+ u32 val;
+
+ men_z127_gpio = to_men_z127_gpio(chip);
+ val = readl(men_z127_gpio->reg_base + MEN_Z127_PSR);
+
+ return !!(val & BIT(gpio));
+}
+
+static struct gpio_chip men_z127_chip = {
+ .label = "men-z127-gpio",
+ .owner = THIS_MODULE,
+ .direction_input = men_z127_dir_input,
+ .direction_output = men_z127_dir_output,
+ .get = men_z127_get,
+ .set = men_z127_set,
+ .ngpio = 32,
+ .base = 0,
+};
+
+static int men_z127_probe(struct mcb_device *mdev,
+ const struct mcb_device_id *id)
+{
+ struct men_z127_gpio *men_z127_gpio;
+ struct device *dev = &mdev->dev;
+ struct resource *gpio_mem;
+ int ret;
+
+ men_z127_gpio = devm_kzalloc(dev, sizeof(struct men_z127_gpio),
+
[PATCH] tty: serial: men_z135_uart.c: use mcb memory region size instead of hardcoded one
There is no need to hardcode the MEN_Z135_MEM_SIZE. The MCB subsystem
already knowns the size which is located in the chameleon table.
MCB parse the chameleon table to get the resources of each IP and provide
the mcb_request_mem function to get those resources.
Use mcb_request_mem to get the resources. This function also takes care of
the memory region naming allocated by the driver for each of the instances.
Signed-off-by: Andreas Werner
---
drivers/tty/serial/men_z135_uart.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/men_z135_uart.c
b/drivers/tty/serial/men_z135_uart.c
index b90e7b3..3141aa2 100644
--- a/drivers/tty/serial/men_z135_uart.c
+++ b/drivers/tty/serial/men_z135_uart.c
@@ -35,8 +35,6 @@
#define MEN_Z135_BAUD_REG 0x810
#define MEN_Z135_TIMEOUT 0x814
-#define MEN_Z135_MEM_SIZE 0x818
-
#define IRQ_ID(x) ((x) & 0x1f)
#define MEN_Z135_IER_RXCIEN BIT(0) /* RX Space IRQ */
@@ -124,6 +122,7 @@ MODULE_PARM_DESC(rx_timeout, "RX timeout. "
struct men_z135_port {
struct uart_port port;
struct mcb_device *mdev;
+ struct resource *mem;
unsigned char *rxbuf;
u32 stat_reg;
spinlock_t lock;
@@ -734,22 +733,30 @@ static const char *men_z135_type(struct uart_port *port)
static void men_z135_release_port(struct uart_port *port)
{
+ struct men_z135_port *uart = to_men_z135(port);
+
iounmap(port->membase);
port->membase = NULL;
- release_mem_region(port->mapbase, MEN_Z135_MEM_SIZE);
+ mcb_release_mem(uart->mem);
}
static int men_z135_request_port(struct uart_port *port)
{
- int size = MEN_Z135_MEM_SIZE;
+ struct men_z135_port *uart = to_men_z135(port);
+ struct mcb_device *mdev = uart->mdev;
+ struct resource *mem;
+
+ mem = mcb_request_mem(uart->mdev, dev_name(&mdev->dev));
+ if (IS_ERR(mem))
+ return PTR_ERR(mem);
- if (!request_mem_region(port->mapbase, size, "men_z135_port"))
- return -EBUSY;
+ port->mapbase = mem->start;
+ uart->mem = mem;
- port->membase = ioremap(port->mapbase, MEN_Z135_MEM_SIZE);
+ port->membase = ioremap(mem->start, resource_size(mem));
if (port->membase == NULL) {
- release_mem_region(port->mapbase, MEN_Z135_MEM_SIZE);
+ mcb_release_mem(mem);
return -ENOMEM;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] backlight: lp855x: Make sure props struct is zeroed
> > From: Werner Johansson > > > > The driver occasionally got stuck in suspend mode or other strange > > states as those parts of the props struct were never initialized. > > Acked-by: Milo Kim > > Thanks for catching this. You're most welcome! These issues can be difficult to track down, the stack is unpredictable.. /wj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPOST PATCH 3/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
> But I don't see how you will make it work when the root hub itself is > not enabled for wakeup and a non-hub device plugged into one of the > root hub's ports is enabled. > > It seems like you would need a usb_hcd_wakeup_not_needed(hcd, port) > subroutine. We'd just put that in the Tegra platform driver, I guess. Iterate over all ports, call usb_wakeup_enabled_descendants() on the connected device (if any) and disable that port's PHY if it returns 0 or wasn't connected. Since usb_wakeup_enabled_descendants() also counts do_remote_wakeup from the device itself and is safe to call even on non-hubs, that should work for all cases. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPOST PATCH 3/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
> Doug, how would you feel about reworking the patch that exports > usb_wakeup_enabled_descendants()? Instead of doing it that way, create > and export a new subroutine in hcd.c called > usb_hcd_wakeup_not_needed(), or something similar. We have a use case with another host controller (Tegra, which I think is still in the process of being upstreamed) where we are able to power down PHYs (and thus reduce power consumption) per port. I think we should prefer the more flexible 'number of wake devices in subtree' interface to be able to support cases like that. (And for the simple case, 'if (usb_hcd_wakeup_not_needed(hcd))' and 'if (!usb_wakeup_enabled_descendants(hcd->self.root_hub))' look pretty similar anyway.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regmap: regmap-debugfs.c crash if max_register is not set
Hi,
i am currently working on a driver using regmap.
The test system i my Mac Book Air using the i2c-stub driver for the first tests.
The Kernel is the Arch Linux Kernel 4.0.2-1-ARCH.
First thing after setting up all the ranges was to check the debugfs.
After i did a cat on the ranges debugfs entry i got a oops.
[15776.817084] [ cut here ]
[15776.817097] WARNING: CPU: 1 PID: 7165 at
drivers/base/regmap/regmap-debugfs.c:151
regmap_debugfs_get_dump_start.part.0+0x1f7/0x260()
[15776.817099] Modules linked in: menaf07bmc(O) i2c_stub(O) regmap_i2c
rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver i2c_dev rfcomm
fuse bnep videodev media joydev msr ax88179_178a usbnet mii mousedev hid_apple
hid_generic uas snd_hda_codec_hdmi btusb bluetooth usbhid hid bcm5974
nls_iso8859_1 nls_cp437 vfat fat wl(PO) iTCO_wdt iTCO_vendor_support evdev
mac_hid coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal
intel_powerclamp kvm_intel kvm snd_hda_codec_cirrus snd_hda_codec_generic
crct10dif_pclmul i915 crc32_pclmul crc32c_intel ghash_clmulni_intel
applesmc led_class input_polldev hwmon snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep aesni_intel cfg80211 snd_pcm drm_kms_helper
aes_x86_64 lrw snd_timer gf128mul glue_helper snd ablk_helper cryptd drm pcspkr
thunderbolt i2c_i801
[15776.817160] dw_dmac_pci sbs lpc_ich bdc_pci battery rfkill dw_dmac_core
intel_gtt i2c_algo_bit sbshc i2c_core soundcore spi_pxa2xx_platform
apple_bl video ac mei_me button mei shpchp processor sch_fq_codel nfs lockd
grace sunrpc fscache ext4 crc16 mbcache jbd2 usb_storage sd_mod ahci
libahci libata scsi_mod xhci_pci xhci_hcd usbcore usb_common [last unloaded:
i2c_stub]
[15776.817193] CPU: 1 PID: 7165 Comm: cat Tainted: PW O
4.0.2-1-ARCH #1
[15776.817196] Hardware name: Apple Inc. MacBookAir6,1/Mac-35C1E88140C3E6CF,
BIOS MBA61.88Z.0099.B09.1402071141 02/07/2014
[15776.817198] 7c1475e9 880137fcbda8
81571be3
[15776.817202] 880137fcbde8
81074dda
[15776.817205] ff10200f 88008999c118 88008999c000
88008999c118
[15776.817208] Call Trace:
[15776.817218] [] dump_stack+0x4c/0x6e
[15776.817226] [] warn_slowpath_common+0x8a/0xc0
[15776.817230] [] warn_slowpath_null+0x1a/0x20
[15776.817234] []
regmap_debugfs_get_dump_start.part.0+0x1f7/0x260
[15776.817238] [] regmap_reg_ranges_read_file+0xb2/0x280
[15776.817245] [] __vfs_read+0x18/0x50
[15776.817248] [] vfs_read+0x87/0x140
[15776.817252] [] SyS_read+0x59/0xd0
[15776.817258] [] system_call_fastpath+0x12/0x17
[15776.817260] ---[ end trace bd5c1e41e89c5481 ]---
My regmap config is as following:
static const struct regmap_config menaf07_config = {
.reg_bits = 8,
.val_bits = 8,
.wr_table = &menaf07bmc_writeable_table,
.rd_table = &menaf07bmc_readable_table,
}
I checked the code in regmap-debugfs.c and found that the
regmap_debugfs_get_dump_start function use the max_register to itterate over
the ranges.
I set the max_register in the config to a valid value and everything worked
find.
In the documention of the regmap_config struct the max_register setting is
defined as "optional".
Should it be defined as mandatory do prevent such an oops? May be we can also
adapt the regmap_init
to check max_register for a valid value.
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regmap different register size
On Tue, May 26, 2015 at 02:00:39PM -0500, Felipe Balbi wrote: > Hi, > > On Tue, May 26, 2015 at 08:54:25PM +0200, Andreas Werner wrote: > > i have a question regarding regmap usage. > > > > I have a i2c multifunction device which does have a register and value > > width of 8bits except the revision register. The revision can only be > > read by a i2c block transfer. > > read revision during probe using i2c block transfer, cache the value in > your own driver structure and all subsequent reads just return the > cached value. Everything else should be ok via regmap. This is first > thing that came to mind, maybe there's a better way. > > -- > balbi This is what I want to do yes and i think this would be the only way to do it because there is no mechanism to handle different register sizes with regmap. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regmap different register size
Hi, i have a question regarding regmap usage. I have a i2c multifunction device which does have a register and value width of 8bits except the revision register. The revision can only be read by a i2c block transfer. Does it makes sense to read the Revision once by the i2c API and let the rest of the device read/write by regmap? Regmap should reduce code but in this case i had to check the i2c block functionality first then read the revisoin and then init the regmap stuff. May be in this case it would be better to use the i2c only instead of mixing i2c API and regmap. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Window watchdog driver design
On Thu, May 14, 2015 at 11:14:19PM -0700, Guenter Roeck wrote: > On 05/14/2015 10:43 PM, Andreas Werner wrote: > >On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote: > >>On 05/14/2015 07:09 AM, Andreas Werner wrote: > >>>On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote: > >>>>On 05/14/2015 04:56 AM, Andreas Werner wrote: > >>>>>Hi, > >>>>>in the next few weeks I need to write a driver for a window wachtdog > >>>>>implemented in a CPLD. I have some questions about the design > >>>>>of the driver and the best way to write this driver to also be able > >>>>>to submit it. > >>>>> > >>>>>The triggering and configuration of the Watchdog is done by several > >>>>>GPIOs which > >>>>>are connected to the CPLD watchdog device. The correct GPIOs are > >>>>>configurable > >>>>>using the Device Tree. > >>>>> > >>>>>1. Timeout > >>>>> The timeout values are defined in ms and start from 20ms to 2560ms. > >>>>> The timout is set by 3 GPIOs this means we have only 8 different > >>>>> timout values. It is also possible that a future Watchdog CPLD device > >>>>> does have different timeout values. > >>>>> > >>>>> Is it possible to set ms timeouts? It seems that the WDT API does > >>>>> only support a resolution of 1sec. > >>>>> > >>>>> One idea would be to use the API timeout as something like a timeout > >>>>> index to set the different values. Of course this needs to be > >>>>> documented. > >>>>> > >>>>> e.g. > >>>>> timeout (API) timeout in device > >>>>> 1 20ms > >>>>> 2 100ms > >>>>> 3 500ms > >>>>> ... ... > >>>>> > >>>>>2. Upper/Lower Window > >>>>> There is currently no support for a windowed watchdog in the wdt core. > >>>>> The lower window can be activated by a gpio and its timeout is defined > >>>>> as "upper windows timeout/4" > >>>>> > >>>>> What is the best way to implement those additional settings? Adding > >>>>> additional > >>>>> ioctl or export these in sysfs? > >>>>>-- > >>>> > >>>>Sorry for the maybe dumb question, but what is a window watchdog, > >>>>and what is the lower window timeout for (assuming the upper window > >>>>timeout causes the watchdog to expire) ? > >>>> > >>>>Guenter > >>>> > >>> > >>>Oh sorry forgot to describe it in more detail. > >>> > >>>If you have a watchdog window you do not have just one timeout where the > >>>watchdog can expire. > >>>You have a so called "window" to trigger it within. > >>> > >>> |<trig>| > >>>---lower timeoutupper timeout > >>> > >>>This means you have to trigger the watchdog not to late and not to early. > >>>This kind of watchdog is often used in embedded applications or more often > >>>in safety cases to fullfil requirements given e.g. by SIL1-SIL4 > >>>certifications. > >>> > >>>The lower timeout is set by a dedicated GPIO and the value will then > >>>"Upper timeout / 4". The > >>>upper timeout is set by 3 GPIOs to get different timeout values. > >>> > >> > >>Thanks a lot for the explanation. > >> > >>I would suggest to use a module parameter to enable the "lower timeout" > >>functionality. > >> > >>Timeouts have to be specified in seconds. > >> > >>Hope this helps, > >>Guenter > >> > > > >Thanks for the answer. > > > >The module parameter would be ok for me, but it would be better if i can > >enable/disable > >the lower window by the application. > > > You could try adding a sysfs attribute. > > >I know that the API defines the timout in seconds but what about ms? Is > >there no > >watchdog out there which has timout values < seconds?. > > > The ABI is the ABI, it has been there for a long time, an
Re: Window watchdog driver design
On Thu, May 14, 2015 at 11:14:19PM -0700, Guenter Roeck wrote: > On 05/14/2015 10:43 PM, Andreas Werner wrote: > >On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote: > >>On 05/14/2015 07:09 AM, Andreas Werner wrote: > >>>On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote: > >>>>On 05/14/2015 04:56 AM, Andreas Werner wrote: > >>>>>Hi, > >>>>>in the next few weeks I need to write a driver for a window wachtdog > >>>>>implemented in a CPLD. I have some questions about the design > >>>>>of the driver and the best way to write this driver to also be able > >>>>>to submit it. > >>>>> > >>>>>The triggering and configuration of the Watchdog is done by several > >>>>>GPIOs which > >>>>>are connected to the CPLD watchdog device. The correct GPIOs are > >>>>>configurable > >>>>>using the Device Tree. > >>>>> > >>>>>1. Timeout > >>>>> The timeout values are defined in ms and start from 20ms to 2560ms. > >>>>> The timout is set by 3 GPIOs this means we have only 8 different > >>>>> timout values. It is also possible that a future Watchdog CPLD device > >>>>> does have different timeout values. > >>>>> > >>>>> Is it possible to set ms timeouts? It seems that the WDT API does > >>>>> only support a resolution of 1sec. > >>>>> > >>>>> One idea would be to use the API timeout as something like a timeout > >>>>> index to set the different values. Of course this needs to be > >>>>> documented. > >>>>> > >>>>> e.g. > >>>>> timeout (API) timeout in device > >>>>> 1 20ms > >>>>> 2 100ms > >>>>> 3 500ms > >>>>> ... ... > >>>>> > >>>>>2. Upper/Lower Window > >>>>> There is currently no support for a windowed watchdog in the wdt core. > >>>>> The lower window can be activated by a gpio and its timeout is defined > >>>>> as "upper windows timeout/4" > >>>>> > >>>>> What is the best way to implement those additional settings? Adding > >>>>> additional > >>>>> ioctl or export these in sysfs? > >>>>>-- > >>>> > >>>>Sorry for the maybe dumb question, but what is a window watchdog, > >>>>and what is the lower window timeout for (assuming the upper window > >>>>timeout causes the watchdog to expire) ? > >>>> > >>>>Guenter > >>>> > >>> > >>>Oh sorry forgot to describe it in more detail. > >>> > >>>If you have a watchdog window you do not have just one timeout where the > >>>watchdog can expire. > >>>You have a so called "window" to trigger it within. > >>> > >>> |<trig>| > >>>---lower timeoutupper timeout > >>> > >>>This means you have to trigger the watchdog not to late and not to early. > >>>This kind of watchdog is often used in embedded applications or more often > >>>in safety cases to fullfil requirements given e.g. by SIL1-SIL4 > >>>certifications. > >>> > >>>The lower timeout is set by a dedicated GPIO and the value will then > >>>"Upper timeout / 4". The > >>>upper timeout is set by 3 GPIOs to get different timeout values. > >>> > >> > >>Thanks a lot for the explanation. > >> > >>I would suggest to use a module parameter to enable the "lower timeout" > >>functionality. > >> > >>Timeouts have to be specified in seconds. > >> > >>Hope this helps, > >>Guenter > >> > > > >Thanks for the answer. > > > >The module parameter would be ok for me, but it would be better if i can > >enable/disable > >the lower window by the application. > > > You could try adding a sysfs attribute. Yes that would be the best solution for that. Module Parameter would be also ok because normally you just want to enable the lower timeout or not but if you can do this in the application this would be the best. > > >I know that
Re: Window watchdog driver design
On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote: > On 05/14/2015 07:09 AM, Andreas Werner wrote: > >On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote: > >>On 05/14/2015 04:56 AM, Andreas Werner wrote: > >>>Hi, > >>>in the next few weeks I need to write a driver for a window wachtdog > >>>implemented in a CPLD. I have some questions about the design > >>>of the driver and the best way to write this driver to also be able > >>>to submit it. > >>> > >>>The triggering and configuration of the Watchdog is done by several GPIOs > >>>which > >>>are connected to the CPLD watchdog device. The correct GPIOs are > >>>configurable > >>>using the Device Tree. > >>> > >>>1. Timeout > >>> The timeout values are defined in ms and start from 20ms to 2560ms. > >>> The timout is set by 3 GPIOs this means we have only 8 different > >>> timout values. It is also possible that a future Watchdog CPLD device > >>> does have different timeout values. > >>> > >>> Is it possible to set ms timeouts? It seems that the WDT API does > >>> only support a resolution of 1sec. > >>> > >>> One idea would be to use the API timeout as something like a timeout > >>> index to set the different values. Of course this needs to be > >>> documented. > >>> > >>> e.g. > >>> timeout (API) timeout in device > >>> 1 20ms > >>> 2 100ms > >>> 3 500ms > >>> ... ... > >>> > >>>2. Upper/Lower Window > >>> There is currently no support for a windowed watchdog in the wdt core. > >>> The lower window can be activated by a gpio and its timeout is defined > >>> as "upper windows timeout/4" > >>> > >>> What is the best way to implement those additional settings? Adding > >>> additional > >>> ioctl or export these in sysfs? > >>>-- > >> > >>Sorry for the maybe dumb question, but what is a window watchdog, > >>and what is the lower window timeout for (assuming the upper window > >>timeout causes the watchdog to expire) ? > >> > >>Guenter > >> > > > >Oh sorry forgot to describe it in more detail. > > > >If you have a watchdog window you do not have just one timeout where the > >watchdog can expire. > >You have a so called "window" to trigger it within. > > > > |<trig>| > >---lower timeoutupper timeout > > > >This means you have to trigger the watchdog not to late and not to early. > >This kind of watchdog is often used in embedded applications or more often > >in safety cases to fullfil requirements given e.g. by SIL1-SIL4 > >certifications. > > > >The lower timeout is set by a dedicated GPIO and the value will then "Upper > >timeout / 4". The > >upper timeout is set by 3 GPIOs to get different timeout values. > > > > Thanks a lot for the explanation. > > I would suggest to use a module parameter to enable the "lower timeout" > functionality. > > Timeouts have to be specified in seconds. > > Hope this helps, > Guenter > Thanks for the answer. The module parameter would be ok for me, but it would be better if i can enable/disable the lower window by the application. I know that the API defines the timout in seconds but what about ms? Is there no watchdog out there which has timout values < seconds?. In my case I can only set 2 timouts (1sec and 2sec) but I need to support all 8 timeout values. The other thing is that my Watchdog can have differen timeout values depending on the CPLD and the customer requirements. I can not read out this values, they are only defined in the specification. This is why i had the idea with the table to only set some "indexes" for the timout to handle all the cases. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Window watchdog driver design
On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote: > On 05/14/2015 04:56 AM, Andreas Werner wrote: > >Hi, > >in the next few weeks I need to write a driver for a window wachtdog > >implemented in a CPLD. I have some questions about the design > >of the driver and the best way to write this driver to also be able > >to submit it. > > > >The triggering and configuration of the Watchdog is done by several GPIOs > >which > >are connected to the CPLD watchdog device. The correct GPIOs are configurable > >using the Device Tree. > > > >1. Timeout > > The timeout values are defined in ms and start from 20ms to 2560ms. > > The timout is set by 3 GPIOs this means we have only 8 different > > timout values. It is also possible that a future Watchdog CPLD device > > does have different timeout values. > > > > Is it possible to set ms timeouts? It seems that the WDT API does > > only support a resolution of 1sec. > > > > One idea would be to use the API timeout as something like a timeout > > index to set the different values. Of course this needs to be > > documented. > > > > e.g. > > timeout (API) timeout in device > > 1 20ms > > 2 100ms > > 3 500ms > > ... ... > > > >2. Upper/Lower Window > > There is currently no support for a windowed watchdog in the wdt core. > > The lower window can be activated by a gpio and its timeout is defined > > as "upper windows timeout/4" > > > > What is the best way to implement those additional settings? Adding > > additional > > ioctl or export these in sysfs? > >-- > > Sorry for the maybe dumb question, but what is a window watchdog, > and what is the lower window timeout for (assuming the upper window > timeout causes the watchdog to expire) ? > > Guenter > Oh sorry forgot to describe it in more detail. If you have a watchdog window you do not have just one timeout where the watchdog can expire. You have a so called "window" to trigger it within. |<trig>| ---lower timeoutupper timeout This means you have to trigger the watchdog not to late and not to early. This kind of watchdog is often used in embedded applications or more often in safety cases to fullfil requirements given e.g. by SIL1-SIL4 certifications. The lower timeout is set by a dedicated GPIO and the value will then "Upper timeout / 4". The upper timeout is set by 3 GPIOs to get different timeout values. If you have any further questions, to not hesitate to ask me. Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Window watchdog driver design
Hi, in the next few weeks I need to write a driver for a window wachtdog implemented in a CPLD. I have some questions about the design of the driver and the best way to write this driver to also be able to submit it. The triggering and configuration of the Watchdog is done by several GPIOs which are connected to the CPLD watchdog device. The correct GPIOs are configurable using the Device Tree. 1. Timeout The timeout values are defined in ms and start from 20ms to 2560ms. The timout is set by 3 GPIOs this means we have only 8 different timout values. It is also possible that a future Watchdog CPLD device does have different timeout values. Is it possible to set ms timeouts? It seems that the WDT API does only support a resolution of 1sec. One idea would be to use the API timeout as something like a timeout index to set the different values. Of course this needs to be documented. e.g. timeout (API) timeout in device 1 20ms 2 100ms 3 500ms ... ... 2. Upper/Lower Window There is currently no support for a windowed watchdog in the wdt core. The lower window can be activated by a gpio and its timeout is defined as "upper windows timeout/4" What is the best way to implement those additional settings? Adding additional ioctl or export these in sysfs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] spi/rockchip: Add device tree property to configure Rx Sample Delay
We have found that we can sometimes see read failures on boards with
high-capacitance SPI lines. It seems that the controller samples the Rx
data line too early, and its register interface has an "Rx Sample Delay"
setting to fine-tune against this issue.
This patch adds a new optional device tree entry that can configure this
delay in terms of nanoseconds. The kernel will calculate the
best-fitting amount of parent clock ticks to program the controller with
based on that.
Signed-off-by: Julius Werner
---
.../devicetree/bindings/spi/spi-rockchip.txt| 4
drivers/spi/spi-rockchip.c | 21 +
2 files changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 467dec4..0c491bd 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -24,6 +24,9 @@ Optional Properties:
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
- dma-names: DMA request names should include "tx" and "rx" if present.
+- rx-sample-delay-ns: nanoseconds to delay after the SCLK edge before sampling
+ Rx data (may need to be fine tuned for high capacitance lines).
+ No delay (0) by default.
Example:
@@ -33,6 +36,7 @@ Example:
reg = <0xff11 0x1000>;
dmas = <&pdma1 11>, <&pdma1 12>;
dma-names = "tx", "rx";
+ rx-sample-delay-ns = <10>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = ;
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 5e4e52c..f89cd5d 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -179,6 +179,7 @@ struct rockchip_spi {
u8 tmode;
u8 bpw;
u8 n_bytes;
+ u8 rsd_nsecs;
unsigned len;
u32 speed;
@@ -493,6 +494,7 @@ static void rockchip_spi_config(struct rockchip_spi *rs)
{
u32 div = 0;
u32 dmacr = 0;
+ int rsd = 0;
u32 cr0 = (CR0_BHT_8BIT << CR0_BHT_OFFSET)
| (CR0_SSD_ONE << CR0_SSD_OFFSET);
@@ -522,6 +524,20 @@ static void rockchip_spi_config(struct rockchip_spi *rs)
div = DIV_ROUND_UP(rs->max_freq, rs->speed);
div = (div + 1) & 0xfffe;
+ /* Rx sample delay is expressed in parent clock cycles (max 3) */
+ rsd = DIV_ROUND_CLOSEST(rs->rsd_nsecs * (rs->max_freq >> 8),
+ 10 >> 8);
+ if (!rsd && rs->rsd_nsecs) {
+ pr_warn_once("rockchip-spi: %u Hz are too slow to express %u ns
delay\n",
+rs->max_freq, rs->rsd_nsecs);
+ } else if (rsd > 3) {
+ rsd = 3;
+ pr_warn_once("rockchip-spi: %u Hz are too fast to express %u ns
delay, clamping at %u ns\n",
+rs->max_freq, rs->rsd_nsecs,
+rsd * 10U / rs->max_freq);
+ }
+ cr0 |= rsd << CR0_RSD_OFFSET;
+
writel_relaxed(cr0, rs->regs + ROCKCHIP_SPI_CTRLR0);
writel_relaxed(rs->len - 1, rs->regs + ROCKCHIP_SPI_CTRLR1);
@@ -614,6 +630,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
struct rockchip_spi *rs;
struct spi_master *master;
struct resource *mem;
+ u32 rsd_nsecs;
master = spi_alloc_master(&pdev->dev, sizeof(struct rockchip_spi));
if (!master)
@@ -665,6 +682,10 @@ static int rockchip_spi_probe(struct platform_device *pdev)
rs->dev = &pdev->dev;
rs->max_freq = clk_get_rate(rs->spiclk);
+ if (!of_property_read_u32(pdev->dev.of_node, "rx-sample-delay-ns",
+ &rsd_nsecs))
+ rs->rsd_nsecs = rsd_nsecs;
+
rs->fifo_len = get_fifo_len(rs);
if (!rs->fifo_len) {
dev_err(&pdev->dev, "Failed to get fifo length\n");
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] spi/rockchip: Round up clock rate divisor to err on the safe side
The Rockchip SPI driver currently calculates its clock rate divisor by integer dividing the parent rate by the target rate, and then rounding the result up to the next even number (since the divisor must be even). Clock rate divisors should always be rounded up, so that the resulting frequency is lower or equal to the target. This is correctly done in the second step here but not in the first, so we still have a risk of exceeding the desired target frequency (e.g. setting spi-max-frequency to 4000 with a parent clock of 9900 could lead to a divisor of 9900 / 4000 == 2 (which is even) that then results in an effective frequency of 9900 / 2 == 4950 (potentially exceeding the flash chip's specifications). This patch changes the division to round up to fix this problem. Signed-off-by: Julius Werner --- drivers/spi/spi-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c index 1a777dc..5e4e52c 100644 --- a/drivers/spi/spi-rockchip.c +++ b/drivers/spi/spi-rockchip.c @@ -519,7 +519,7 @@ static void rockchip_spi_config(struct rockchip_spi *rs) } /* div doesn't support odd number */ - div = max_t(u32, rs->max_freq / rs->speed, 1); + div = DIV_ROUND_UP(rs->max_freq, rs->speed); div = (div + 1) & 0xfffe; writel_relaxed(cr0, rs->regs + ROCKCHIP_SPI_CTRLR0); -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1] usb: dwc2: reduce dwc2 driver probe time
> @@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg) > gusbcfg = readl(hsotg->regs + GUSBCFG); > gusbcfg &= ~GUSBCFG_FORCEHOSTMODE; > writel(gusbcfg, hsotg->regs + GUSBCFG); > - usleep_range(10, 15); > + usleep_range(25000, 5); The point of usleep_range() is to coalesce multiple timer interrupts in idle systems for power efficiency. It's pretty pointless/harmful during probe anyway and there's almost never a reason to make the span larger than a few milliseconds. You should reduce this to something reasonable (e.g. usleep_range(25000, 26000) or even usleep_range(25000, 25000)) to save another chunk of time. Same applies to other delays above. > do you know what's the upper boundary for AHB clock ? How fast can it > be? It's not wise to change timers because "it works on my RK3288 > board", you need to guarantee that this won't break anybody else. But this code is already a loop that spins on the AHBIdle bit, right? It should work correctly regardless of the delay. The only question is whether the code could be more efficient with a longer sleep... but since the general recommendation is to delay for ranges less than 10us, and the AHB clock would need to be lower than 100KHz (the ones I see are usually in the range of tens or hundreds of MHz) to take longer than that, this seems reasonable to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] usb: Retry port status check on resume to work around RH bugs
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop of the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailable (and reenumerate with a new
handle).
Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..26bdd96 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2896,10 +2896,12 @@ static int port_is_suspended(struct usb_hub *hub,
unsigned portstatus)
*/
static int check_port_resume_type(struct usb_device *udev,
struct usb_hub *hub, int port1,
- int status, unsigned portchange, unsigned portstatus)
+ int status, u16 portchange, u16 portstatus)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
+ int retries = 3;
+ retry:
/* Is a warm reset needed to recover the connection? */
if (status == 0 && udev->reset_resume
&& hub_port_warm_reset_required(hub, port1, portstatus)) {
@@ -2907,10 +2909,17 @@ static int check_port_resume_type(struct usb_device
*udev,
}
/* Is the device still present? */
else if (status || port_is_suspended(hub, portstatus) ||
- !port_is_power_on(hub, portstatus) ||
- !(portstatus & USB_PORT_STAT_CONNECTION)) {
+ !port_is_power_on(hub, portstatus)) {
if (status >= 0)
status = -ENODEV;
+ } else if (!(portstatus & USB_PORT_STAT_CONNECTION)) {
+ if (retries--) {
+ usleep_range(200, 300);
+ status = hub_port_status(hub, port1, &portstatus,
+&portchange);
+ goto retry;
+ }
+ status = -ENODEV;
}
/* Can't do a normal resume if the port isn't enabled,
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb: Retry port status check on resume to work around RH bugs
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailabe (and reenumerate with a new
handle).
Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2896,10 +2896,12 @@ static int port_is_suspended(struct usb_hub *hub,
unsigned portstatus)
*/
static int check_port_resume_type(struct usb_device *udev,
struct usb_hub *hub, int port1,
- int status, unsigned portchange, unsigned portstatus)
+ int status, u16 portchange, u16 portstatus)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
+ int retries = 3;
+retry:
/* Is a warm reset needed to recover the connection? */
if (status == 0 && udev->reset_resume
&& hub_port_warm_reset_required(hub, port1, portstatus)) {
@@ -2909,8 +2911,15 @@ static int check_port_resume_type(struct usb_device
*udev,
else if (status || port_is_suspended(hub, portstatus) ||
!port_is_power_on(hub, portstatus) ||
!(portstatus & USB_PORT_STAT_CONNECTION)) {
- if (status >= 0)
+ if (status >= 0) {
+ if (retries--) {
+ usleep_range(200, 300);
+ status = hub_port_status(hub, port1,
+ &portstatus, &portchange);
+ goto retry;
+ }
status = -ENODEV;
+ }
}
/* Can't do a normal resume if the port isn't enabled,
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: Retry port status check on resume to work around RH bugs
> You should use a sleeping function call, not a delay. Whoops... yes, of course. Guess too much firmware work made me forget what multithreading is there for a moment. Will send a v2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: Retry port status check on resume to work around RH bugs
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailabe (and reenumerate with a new
handle).
Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2896,10 +2896,12 @@ static int port_is_suspended(struct usb_hub *hub,
unsigned portstatus)
*/
static int check_port_resume_type(struct usb_device *udev,
struct usb_hub *hub, int port1,
- int status, unsigned portchange, unsigned portstatus)
+ int status, u16 portchange, u16 portstatus)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
+ int retries = 3;
+retry:
/* Is a warm reset needed to recover the connection? */
if (status == 0 && udev->reset_resume
&& hub_port_warm_reset_required(hub, port1, portstatus)) {
@@ -2909,8 +2911,15 @@ static int check_port_resume_type(struct usb_device
*udev,
else if (status || port_is_suspended(hub, portstatus) ||
!port_is_power_on(hub, portstatus) ||
!(portstatus & USB_PORT_STAT_CONNECTION)) {
- if (status >= 0)
+ if (status >= 0) {
+ if (retries--) {
+ udelay(200);
+ status = hub_port_status(hub, port1,
+ &portstatus, &portchange);
+ goto retry;
+ }
status = -ENODEV;
+ }
}
/* Can't do a normal resume if the port isn't enabled,
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] USB: ehci-platform: Support ehci reset after resume quirk
>> The EHCI controller doesn't properly detect the case when > > "The" EHCI controller? I don't know what EHCI controller you're > talking about, but my controllers don't have any trouble detecting > device removal during suspend. This is similar to other SoC-based controllers that loose state in suspend, like on Samsung's Exynos. Usually we catch that with the FLAG_CF check in ehci_resume(). In the case of RK3288 it unfortunately leaves the CF flag (and other things, like PORTSC[PED] bits) set, although it doesn't react to any events correctly. If the device looses its power session the controller won't notice and then on resume get stuck trying to send resume signals to something that had been reset (or newly plugged in). I think since we can't trust the controller to do anything right, the safest thing is to fall back to the solution of resetting everything (at least we know that works), and since the FLAG_CF check doesn't work we need another solution to mark which controllers are affected. > Isn't this solution too extreme? What if the device was a flash > storage drive and it wasn't unplugged during suspend? This patch would > force it to be removed, messing up any mounted filesystems, when there > was no need. > > Can you find a better way to work around the problem? As Doug said, I think persist is the solution. We have essentially the same case: all we know is that there is now a device connected to the same port that a device had been connected during suspend... but with no guarantees whether it is the same device or in the same state. By forcing people to use persist, we acknowledge that this has the same risks (e.g. data corruption if a mounted mass storage device was swapped out for another one), and we benefit from the same safety checks like comparing the serial number. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2] usb: dwc2: resume root hub when device detect with suspend state
On Wed, Nov 19, 2014 at 1:47 AM, 李云志 wrote: > hi Julius & Alan > > Shall we use dwc2's private status "hsotg->lx_state" here instesd of > "hcd->state" for checking root hub is in suspend state ? > I see the EHCI driver do something like this(ehci->rh_state == > EHCI_RH_SUSPENDED) before resume the root hub. It's not this simple, because lx_state only relates to the status of the one port on the DWC2. That may be suspended even though the root hub is not. The USB core differentiates between suspending individual ports, and suspending the whole root hub (which should automatically suspend all ports in a host-controller-specific manner). This distinction may seem silly on DWC2 because there is only one port to suspend, but you still need to make it so that the USB core doesn't get confused. So the different things you need to keep track of are: * is the one port individually suspended (through the hub_control(SetPortFeature(PORT_SUSPEND)) method) * is the root hub suspended (through calling bus_suspend()) * if the root hub gets suspended (through bus_suspend()), had the port already been suspended before that (through a earlier hub_control())... this is the thing I mentioned in your other patch You can decide whether you want to bake that all into one variable somehow or make it three, but we need to be able to tell all of these things apart. The third bullet point will also require you to prevent races of hub_control() with bus_suspend() (not sure if the kernel already guarantees that or not), so I think we may have to rethink the way the spinlock works (because it currently doesn't cover that). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: dwc2: resume root hub when device detect with suspend state
>> You should be aware that it's not safe to use hcd->state for anything >> in a host controller driver. That field is owned by usbcore, not by >> the HCD, and it is not protected by any locks. >> >> Thus, for example, hcd->state does not get set to HC_STATE_SUSPENDED >> until some time after the bus_suspend routine has returned. A >> port-change interrupt might occur during that time interval. Looks like there is explicit code in hcd_bus_suspend() to check for that race condition right after setting hcd->state, or do I misinterpret that (the "Did we race with a root-hub wakeup event?" part)? Also, it seems xhci_bus_suspend() explicitly sets 'hcd->state = HC_STATE_SUSPENDED' before giving up the spinlock for some undocumented reason, maybe to avoid exactly this problem. We could just copy that trick if the hcd.c solution isn't enough (although the DWC2 bus_suspend/bus_resume in the other patch don't grab that spinlock right now, where I'm also not so sure if that's a good idea...). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: dwc2: resume root hub when device detect with suspend state
On Mon, Nov 17, 2014 at 5:14 AM, Kever Yang wrote: > After we implement the bus_suspend/resume, auto suspend id enabled. > The root hub will be auto suspend if there is no device connected, > we need to resume the root hub when a device connect detect. > > This patch tested on rk3288. > > Signed-off-by: Roy Li > Signed-off-by: Kever Yang > --- > > drivers/usb/dwc2/hcd_intr.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c > index 551ba87..c8299fd 100644 > --- a/drivers/usb/dwc2/hcd_intr.c > +++ b/drivers/usb/dwc2/hcd_intr.c > @@ -355,6 +355,13 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg) > hprt0_modify |= HPRT0_CONNDET; > > /* > +* Check if root hub is in suspend state > +* if root hub in suspend, resume it. > +*/ > + if ((bus->root_hub) && (hcd->state == HC_STATE_SUSPENDED)) What is bus->root_hub checking for? Is there any chance that this could be NULL here? > + usb_hcd_resume_root_hub(hcd); > + > + /* > * The Hub driver asserts a reset when it sees port connect > * status change flag > */ > -- > 1.9.1 Seems sensible in general. Does this actually fix the problem Doug was reporting? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] usb: dwc2: add bus suspend/resume for dwc2
> I will figure out how to make dwc2 detect the device connect after auto > suspend, > or disable the auto suspend feature for the dwc2 hcd. I think auto-suspend of the root hub device (which is what calls bus_suspend, but is not the host controller device itself) is expected to always happen and not really meant to be disabled. I'm surprised that the controller would fail to come back up, though. Does removing the PCGCTL part make it work? That's the only thing I can think of (but then again the function should immediately return if the port is not in L0, so if there is nothing plugged in the suspend shouldn't really do anything). Another thing might be that the port connect interrupt does not correctly resume the root hub. I don't really know many details about how that works, and it seems pretty complicated. But I can see that all other HCDs seem to call usb_hcd_resume_root_hub() from their interrupt handlers, which we don't. There's also a usb_hcd_start_port_resume() in EHCI which I'm not familiar with, that seems to have been added recently. And finally, it seems that all normal host controllers (UHCI/OHCI/EHCI/XHCI) now do the usb_hcd->uses_new_polling thing (where you're supposed to call hcd_poll_rh_status() from the HCD code)... the old polling code still seems to be in place, but without any relevant driver using I wouldn't be so sure if it's still functional. +Alan who should know HCD/core interactions much better and might have some ideas what the DWC2 driver is still missing right now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] checkpatch: Allow certain SI units with three characters
Checkpatch flags CamelCase identifiers in strict mode, but it has a
feature to ignore parts with only two characters to allow for SI units
like mV or uA. Unfortunately, not all SI units fit in two characters,
and not all are lower case followed by upper case.
This patch adds hardcoded detection for frequency and 1024-based size
units (Hz/KHz/MHz/GHz/THz and KiB/MiB/GiB/TiB), since allowing any three
character combinations might be too lenient. The list can later be
expanded as needed.
Signed-off-by: Julius Werner
---
scripts/checkpatch.pl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 374abf4..b947c75 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4056,7 +4056,9 @@ sub process {
#Ignore Page variants
$var !~
/^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
#Ignore SI style variants like nS, mV and dB (ie: max_uV,
regulator_min_uA_show)
- $var !~ /^(?:[a-z_]*?)_?[a-z][A-Z](?:_[a-z_]+)?$/) {
+ $var !~ /^(?:[a-z_]*?)_?[a-z][A-Z](?:_[a-z_]+)?$/ &&
+#Ignore some three character SI units explicitly, like MiB and KHz
+ $var !~
/^(?:[a-z_]*?)_?(?:[KMGT]iB|[KMGT]?Hz)(?:_[a-z_]+)?$/) {
while ($var =~ m{($Ident)}g) {
my $word = $1;
next if ($word !~
/[A-Z][a-z]|[a-z][A-Z]/);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: dwc2: add bus suspend/resume for dwc2
>> The contract for bus_suspend() is that it will suspend all ports not >> yet suspended, keep track of those ports and then only resume those in >> bus_resume() (compare, for example, how XHCI keeps track of that with >> xhci_bus_state.bus_suspended in xhci_bus_suspend/resume()). So you >> need something here to remember whether this function suspended the >> port or whether it had already been suspended, and then only resume >> the port in bus_resume() in the former case. > > In fact, the dwc2 controller only support one port, so the hprt0 > is the only one port we need to care. Yes, I know, but that one port still needs to play by the rules the USB core expects. All I'm saying is: if the port was already suspended during bus_suspend(), then the next bus_resume() should not resume it. The rest looks good to me now. But in order to get it really working, I think we'll still need the actual driver.pm suspend/resume methods, at least for the HCD_FLAG_HW_ACCESSIBLE and the usb_root_hub_lost_power() handling (probably better in a separate patch). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Make SI unit tolerance more lenient with 3-character units
Checkpatch flags CamelCase identifiers in strict mode, but it has a
feature to ignore parts with only two characters to allow for SI units
like mV or uA. Unfortunately, not all SI units fit in two characters,
and not all are lower case followed by upper case.
This patch changes the check from [a-z][A-Z] to [a-zA-Z]{1,3} (any
combination of up to three lower and upper case characters), so that it
will also allow units like MHz, As or KiB.
Signed-off-by: Julius Werner
---
scripts/checkpatch.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 374abf4..0bbd25a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4055,8 +4055,8 @@ sub process {
$var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
#Ignore Page variants
$var !~
/^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
-#Ignore SI style variants like nS, mV and dB (ie: max_uV,
regulator_min_uA_show)
- $var !~ /^(?:[a-z_]*?)_?[a-z][A-Z](?:_[a-z_]+)?$/) {
+#Ignore SI style variants like nS, mV, MHz and dB (ie: max_uV,
regulator_min_uA_show)
+ $var !~
/^(?:[a-z_]*?)_?[a-zA-Z]{1,3}(?:_[a-z_]+)?$/) {
while ($var =~ m{($Ident)}g) {
my $word = $1;
next if ($word !~
/[A-Z][a-z]|[a-z][A-Z]/);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: dwc2: add bus suspend/resume for dwc2
On Wed, Nov 5, 2014 at 5:30 PM, Kever Yang wrote:
> Hcd controller needs bus_suspend/resume, dwc2 controller make
> root hub generate suspend/resume signal with hprt0 register
> when work in host mode.
> After the root hub enter suspend, we can make controller enter
> low power state with PCGCTL register.
You say you do this, but I don't actually see you doing it (for the
not-connected case)?
>
> We also update the lx_state for hsotg state.
>
> This patch has tested on rk3288 with suspend/resume.
>
> Signed-off-by: Kever Yang
> ---
>
> Changes in v2:
> - update commit message
> - make dwc2 suspend/resume sourcecode work
>
> drivers/usb/dwc2/hcd.c | 78
> +++---
> 1 file changed, 67 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 0a0e6f0..01a415b 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1471,6 +1471,30 @@ static void dwc2_port_suspend(struct dwc2_hsotg
> *hsotg, u16 windex)
> }
> }
>
> +static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
> +{
> + u32 hprt0;
> +
> + /* After clear the Stop PHY clock bit, we should wait for a moment
> +* for PLL work stable with clock output.
> +*/
> + writel(0, hsotg->regs + PCGCTL);
> + usleep_range(2000, 4000);
> +
> + hprt0 = dwc2_read_hprt0(hsotg);
> + hprt0 |= HPRT0_RES;
> + writel(hprt0, hsotg->regs + HPRT0);
> + hprt0 &= ~HPRT0_SUSP;
> + /* according to USB2.0 Spec 7.1.7.7, the host must send the resume
> +* signal for at least 20ms
> +*/
> + usleep_range(2, 25000);
> +
> + hprt0 &= ~HPRT0_RES;
> + writel(hprt0, hsotg->regs + HPRT0);
> + hsotg->lx_state = DWC2_L0;
> +}
> +
> /* Handles hub class-specific requests */
> static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
> u16 wvalue, u16 windex, char *buf, u16
> wlength)
> @@ -1516,17 +1540,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg
> *hsotg, u16 typereq,
> case USB_PORT_FEAT_SUSPEND:
> dev_dbg(hsotg->dev,
> "ClearPortFeature USB_PORT_FEAT_SUSPEND\n");
> - writel(0, hsotg->regs + PCGCTL);
> - usleep_range(2, 4);
> -
> - hprt0 = dwc2_read_hprt0(hsotg);
> - hprt0 |= HPRT0_RES;
> - writel(hprt0, hsotg->regs + HPRT0);
> - hprt0 &= ~HPRT0_SUSP;
> - usleep_range(10, 15);
> -
> - hprt0 &= ~HPRT0_RES;
> - writel(hprt0, hsotg->regs + HPRT0);
I'm curious why this didn't change lx_state back to DWC2_L0 before...
Paul, do you know?
> + dwc2_port_resume(hsotg);
> break;
>
> case USB_PORT_FEAT_POWER:
> @@ -2299,6 +2313,44 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
> usleep_range(1000, 3000);
> }
>
> +static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
> +{
> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> + u32 hprt0;
> +
> + if (!((hsotg->op_state == OTG_STATE_B_HOST) ||
> + (hsotg->op_state == OTG_STATE_A_HOST)))
> + return 0;
> +
> + if (hsotg->lx_state != DWC2_L0)
What if the port is in L1 state? I don't think the driver supports LPM
right now, but the DWC2_L1 enum is defined so it may one day in the
future. Let's maybe at least add a TODO.
> + return 0;
In your original ChromiumOS version of this patch, you also set
PCGCTL_STOPPCLK here if the port was not connected. Is there a reason
that changed (does it not actually save power or something)?
> +
> + hprt0 = dwc2_read_hprt0(hsotg);
> + if (hprt0 & HPRT0_CONNSTS)
> + dwc2_port_suspend(hsotg, 1);
The contract for bus_suspend() is that it will suspend all ports not
yet suspended, keep track of those ports and then only resume those in
bus_resume() (compare, for example, how XHCI keeps track of that with
xhci_bus_state.bus_suspended in xhci_bus_suspend/resume()). So you
need something here to remember whether this function suspended the
port or whether it had already been suspended, and then only resume
the port in bus_resume() in the former case. Note that
dwc2_port_suspend() changes lx_state to DWC_L2 (at least in the
version I'm looking at right now), so you can't just rely on that
unless you explicitly set it back to something else here.
> +
> + return 0;
> +}
> +
> +static int _dwc2_hcd_resume(struct usb_hcd *hcd)
> +{
> + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> + u32 hprt0;
> +
> + if (!((hsotg->op_state == OTG_STATE_B_HOST) ||
> + (hsotg->op_state == OTG_STATE_A_HOST)))
> + return 0;
> +
> + if (hsotg->lx_state !=
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Mon, Oct 20, 2014 at 05:11:41PM +0800, Greg KH wrote: > On Mon, Oct 20, 2014 at 10:33:45AM +0200, Andreas Werner wrote: > > On Thu, Oct 16, 2014 at 01:44:02PM +0200, Andreas Werner wrote: > > > On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: > > > > * PGP Signed by an unknown key > > > > > > > > > > > > > I do not want to parse the things in userspace because this EEPROM > > > > > data > > > > > are related to the hardware and i want to give our customer the > > > > > easiest way > > > > > to access the data without installing any tool. > > > > > > > > I understand that point of view. From an upstream point of view, things > > > > may look different, though. > > > > > > > > > > I also understand your point of view :-). > > > Most customers wants just to have a running system without installing > > > anything. > > > And for me an EEPROM is so simple and should not need a complicated way > > > to access it. > > > > > > > > The current state to read the eeprom data is, that customer needs to > > > > > install a big > > > > > environment where the tool is integrated to have access to those kind > > > > > of simple > > > > > data or they have to write their own code. > > > > > > > > i2cget from i2c-tools? You could do a simple shell script to parse the > > > > data. Or do a board specific hook which reads the data and prints it to > > > > the logfiles... > > > > > > > > > > Yes of course there are a lot of possibilities. This was just an example > > > what we currently use and what was developed years ago. > > > > > > With a driver like this you can also define read only attributes to > > > prevent customer > > > to write or modify the data in the production section. With i2ctools you > > > can just > > > write any data to it you want. > > > > > > > > > Consider how bloated the sysfs-ABI might get if every vendor who > > > > > > uses an > > > > > > eeprom wants to expose the data this way? > > > > > > > > > > > > > > > > Yes and no. The possible sysfs entries gets bloated if every vendor > > > > > will do it > > > > > like this way, but normally there is just one Board EEPROM on the > > > > > board, therefore > > > > > only one driver gets loaded. > > > > > > > > I am not talking about runtime here, I don't care about that. I am > > > > talking about the ABI we create and we have to maintain basically > > > > forever. And with vendor specific configuartion data I have doubts with > > > > that being stable. > > > > > > > > > > Ok, but i do not think that we can make a "general" ABI definition for > > > those kind > > > of devices because every vendor will have its own data in the EEPROM > > > which he want > > > to have. > > > > > > > > I mean its the same for every i2c device like a temperature sensor, I > > > > > can also > > > > > read it from userspace without any special hwmon driver. > > > > > > > > These is a HUGE difference. If I read tempX_input, I don't need to care > > > > if the sensor is I2C or SPI or whatever. The kernel abstracts that away. > > > > The files you create are for your I2C EEPROM only. Data gets > > > > "reformatted" and access gets hidden, but nothing is abstracted away. > > > > It would be different if we had a generic convention for "serial_id" or > > > > stuff like that. But as configuration data is highly specific I don't > > > > see this coming. > > > > > > > > > > For a standard sysfs interface it is a huge difference yes. At the point > > > of few from the EEPROM device it is a device like a temp sensor which > > > could be different from vendor to vendor. > > > > > > Regards > > > Andy > > > > > > > Greg what do you think about that driver as a Maintainer of the sysfs? > > I maintain the sysfs core that drivers use, I don't dictate the policy > that those drivers create and send to userspace, that is up to the > maintainer of the subsystem. There are some basic rules of sysfs (one > value per file), but other than that, please work with the maintainer to > come up with an interface that will work for all types of this device, > not just a one-off interface which does not scale at all, as Wolfram has > pointed out. > Ok. > > To we have other ways to get those kind of drivers in the mainline kernel? > > Yes, work on a common interface that your driver can use, and it can be > accepted. Why do you not want to do that? > > thanks, > > greg k-h I have never talked about that I do not want to do it. I just want to discuss it with you. Right now we are at a point that i know that those kind of drivers can't be upstream and i will try to find a way of abstraction to get it upstream. Thanks Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Mon, Oct 20, 2014 at 10:24:22AM +0200, Wolfram Sang wrote: > * PGP Signed by an unknown key > > > Here it gets frustrating. It seems you have no idea what an OS is for, > > not even after I tried to describe it :( > I am pretty sure that i know what an OS is for. > Sorry, that might have been too strong. Still, we can't map any hardware > which is out there 1:1 into userspace, we need abstraction. > > If you want to help with this abstraction, this is more than > appreciated. If you want to keep your driver, this will have to stay > out-of-tree, I'm afraid. > Yes, my goal is to find a good way to get hardware support upstream, and it is also nice to discuss my point of view with your upstream point of few. And yes, i want to help to find a way to develope an abstraction. Regards Andy > Regards, > >Wolfram > > > * Unknown Key > * 0x14A029B6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Thu, Oct 16, 2014 at 01:44:02PM +0200, Andreas Werner wrote: > On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: > > * PGP Signed by an unknown key > > > > > > > I do not want to parse the things in userspace because this EEPROM data > > > are related to the hardware and i want to give our customer the easiest > > > way > > > to access the data without installing any tool. > > > > I understand that point of view. From an upstream point of view, things > > may look different, though. > > > > I also understand your point of view :-). > Most customers wants just to have a running system without installing > anything. > And for me an EEPROM is so simple and should not need a complicated way > to access it. > > > > The current state to read the eeprom data is, that customer needs to > > > install a big > > > environment where the tool is integrated to have access to those kind of > > > simple > > > data or they have to write their own code. > > > > i2cget from i2c-tools? You could do a simple shell script to parse the > > data. Or do a board specific hook which reads the data and prints it to > > the logfiles... > > > > Yes of course there are a lot of possibilities. This was just an example > what we currently use and what was developed years ago. > > With a driver like this you can also define read only attributes to prevent > customer > to write or modify the data in the production section. With i2ctools you can > just > write any data to it you want. > > > > > Consider how bloated the sysfs-ABI might get if every vendor who uses an > > > > eeprom wants to expose the data this way? > > > > > > > > > > Yes and no. The possible sysfs entries gets bloated if every vendor will > > > do it > > > like this way, but normally there is just one Board EEPROM on the board, > > > therefore > > > only one driver gets loaded. > > > > I am not talking about runtime here, I don't care about that. I am > > talking about the ABI we create and we have to maintain basically > > forever. And with vendor specific configuartion data I have doubts with > > that being stable. > > > > Ok, but i do not think that we can make a "general" ABI definition for those > kind > of devices because every vendor will have its own data in the EEPROM which he > want > to have. > > > > I mean its the same for every i2c device like a temperature sensor, I can > > > also > > > read it from userspace without any special hwmon driver. > > > > These is a HUGE difference. If I read tempX_input, I don't need to care > > if the sensor is I2C or SPI or whatever. The kernel abstracts that away. > > The files you create are for your I2C EEPROM only. Data gets > > "reformatted" and access gets hidden, but nothing is abstracted away. > > It would be different if we had a generic convention for "serial_id" or > > stuff like that. But as configuration data is highly specific I don't > > see this coming. > > > > For a standard sysfs interface it is a huge difference yes. At the point > of few from the EEPROM device it is a device like a temp sensor which > could be different from vendor to vendor. > > Regards > Andy > Greg what do you think about that driver as a Maintainer of the sysfs? To we have other ways to get those kind of drivers in the mainline kernel? Regards Andy > > > > * Unknown Key > > * 0x14A029B6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: > * PGP Signed by an unknown key > > > > I do not want to parse the things in userspace because this EEPROM data > > are related to the hardware and i want to give our customer the easiest way > > to access the data without installing any tool. > > I understand that point of view. From an upstream point of view, things > may look different, though. > I also understand your point of view :-). Most customers wants just to have a running system without installing anything. And for me an EEPROM is so simple and should not need a complicated way to access it. > > The current state to read the eeprom data is, that customer needs to > > install a big > > environment where the tool is integrated to have access to those kind of > > simple > > data or they have to write their own code. > > i2cget from i2c-tools? You could do a simple shell script to parse the > data. Or do a board specific hook which reads the data and prints it to > the logfiles... > Yes of course there are a lot of possibilities. This was just an example what we currently use and what was developed years ago. With a driver like this you can also define read only attributes to prevent customer to write or modify the data in the production section. With i2ctools you can just write any data to it you want. > > > Consider how bloated the sysfs-ABI might get if every vendor who uses an > > > eeprom wants to expose the data this way? > > > > > > > Yes and no. The possible sysfs entries gets bloated if every vendor will do > > it > > like this way, but normally there is just one Board EEPROM on the board, > > therefore > > only one driver gets loaded. > > I am not talking about runtime here, I don't care about that. I am > talking about the ABI we create and we have to maintain basically > forever. And with vendor specific configuartion data I have doubts with > that being stable. > Ok, but i do not think that we can make a "general" ABI definition for those kind of devices because every vendor will have its own data in the EEPROM which he want to have. > > I mean its the same for every i2c device like a temperature sensor, I can > > also > > read it from userspace without any special hwmon driver. > > These is a HUGE difference. If I read tempX_input, I don't need to care > if the sensor is I2C or SPI or whatever. The kernel abstracts that away. > The files you create are for your I2C EEPROM only. Data gets > "reformatted" and access gets hidden, but nothing is abstracted away. > It would be different if we had a generic convention for "serial_id" or > stuff like that. But as configuration data is highly specific I don't > see this coming. > For a standard sysfs interface it is a huge difference yes. At the point of few from the EEPROM device it is a device like a temp sensor which could be different from vendor to vendor. Regards Andy > > * Unknown Key > * 0x14A029B6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Thu, Oct 16, 2014 at 10:58:35AM +0200, Wolfram Sang wrote:
> * PGP Signed by an unknown key
>
> On Thu, Oct 16, 2014 at 10:15:08AM +0200, Andreas Werner wrote:
> > Added driver to support the MEN Board Information EEPROM.
> > The driver exports the production information as read only sysfs
> > entries, as well as a user section which is read/write accessible.
> >
> > Tested on PPC QorIQ and Intel Atom E680.
> >
> > Tested-by: Johannes Thumshirn
> > Signed-off-by: Andreas Werner
>
> I guess this is just a standard EEPROM with a well defined layout?
> Why don't you want to use the standard driver then and parse the thing
> in userspace?
>
Yes it is a standard 256byte eeprom.
I do not want to parse the things in userspace because this EEPROM data
are related to the hardware and i want to give our customer the easiest way
to access the data without installing any tool.
The current state to read the eeprom data is, that customer needs to install a
big
environment where the tool is integrated to have access to those kind of simple
data or they have to write their own code.
If our support department get some questions from the customer they always want
to have exact information about the board. Therefore I want to use this driver
and sysfs to get the informations as fast as possible without installing
anything.
> Consider how bloated the sysfs-ABI might get if every vendor who uses an
> eeprom wants to expose the data this way?
>
Yes and no. The possible sysfs entries gets bloated if every vendor will do it
like this way, but normally there is just one Board EEPROM on the board,
therefore
only one driver gets loaded.
I mean its the same for every i2c device like a temperature sensor, I can also
read it from userspace without any special hwmon driver.
> > +struct eeprom_data {
> > + uint8_t eeprod_id;
> > +
> > + uint8_t revision[3];
> > + uint32_t serialnr;
> > + uint8_t board_model;
> > + char hw_name[6];
> > +
> > + uint8_t reserved;
> > +
> > + __be16 prod_date;
> > + __be16 rep_date;
> > +
> > + uint8_t reserved2[4];
> > +};
>
> And what if the compiler reorders?
Shit you are right, I will pack it.#
>
>
> * Unknown Key
> * 0x14A029B6
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Thu, Oct 16, 2014 at 10:44:12AM +0200, Greg KH wrote:
> On Thu, Oct 16, 2014 at 10:15:08AM +0200, Andreas Werner wrote:
> > +struct eeprom_data {
> > + uint8_t eeprod_id;
>
> Please use the "real" kernel types, "u8" here, and "u32" in other places
> you use uint32_t (those are userspace types, not kernel types, sorry.)
>
You are right i will change it.
> > +static DEVICE_ATTR(eeprod_id, S_IRUGO, show_eeprod_id, NULL);
> > +static DEVICE_ATTR(revision, S_IRUGO, show_revision, NULL);
> > +static DEVICE_ATTR(serial, S_IRUGO, show_serialnr, NULL);
> > +static DEVICE_ATTR(hw_name, S_IRUGO, show_hw_name, NULL);
> > +static DEVICE_ATTR(prod_date, S_IRUGO, show_prod_date, NULL);
> > +static DEVICE_ATTR(rep_date, S_IRUGO, show_rep_date, NULL);
>
> DEVICE_ATTR_RO() please.
OK no problem, will change it.
Thanks.
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
Added driver to support the MEN Board Information EEPROM.
The driver exports the production information as read only sysfs
entries, as well as a user section which is read/write accessible.
Tested on PPC QorIQ and Intel Atom E680.
Tested-by: Johannes Thumshirn
Signed-off-by: Andreas Werner
---
MAINTAINERS | 6 +
drivers/misc/eeprom/Kconfig | 10 +
drivers/misc/eeprom/Makefile | 1 +
drivers/misc/eeprom/men_eeprod.c | 560 +++
4 files changed, 577 insertions(+)
create mode 100644 drivers/misc/eeprom/men_eeprod.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 503da28..88ede76 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6029,6 +6029,12 @@ F: drivers/leds/leds-menf21bmc.c
F: drivers/hwmon/menf21bmc_hwmon.c
F: Documentation/hwmon/menf21bmc
+MEN EEPROD (Board information EEPROM)
+M: Andreas Werner
+S: Supported
+F: drivers/misc/eeprom/men_eeprod.c
+F: Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod
+
METAG ARCHITECTURE
M: James Hogan
L: linux-me...@vger.kernel.org
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..e087d08 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -62,6 +62,16 @@ config EEPROM_MAX6875
This driver can also be built as a module. If so, the module
will be called max6875.
+config EEPROM_MEN_EEPROD
+ tristate "MEN Board Information EEPROM"
+ depends on I2C && SYSFS
+ help
+ If you say yes here you get support for the MEN Board Information
+ EEPROM. This driver supports read-only access to the production
+ data section, and read-write access to the user section.
+
+ This driver can also be built as a module. If so, the module
+ will be called men_eeprod.
config EEPROM_93CX6
tristate "EEPROM 93CX6 support"
diff --git a/drivers/misc/eeprom/Makefile b/drivers/misc/eeprom/Makefile
index 9507aec..8c70a81 100644
--- a/drivers/misc/eeprom/Makefile
+++ b/drivers/misc/eeprom/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_EEPROM_AT24) += at24.o
obj-$(CONFIG_EEPROM_AT25) += at25.o
obj-$(CONFIG_EEPROM_LEGACY)+= eeprom.o
obj-$(CONFIG_EEPROM_MAX6875) += max6875.o
+obj-$(CONFIG_EEPROM_MEN_EEPROD) += men_eeprod.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
obj-$(CONFIG_EEPROM_93XX46)+= eeprom_93xx46.o
obj-$(CONFIG_EEPROM_SUNXI_SID) += sunxi_sid.o
diff --git a/drivers/misc/eeprom/men_eeprod.c b/drivers/misc/eeprom/men_eeprod.c
new file mode 100644
index 000..28264df
--- /dev/null
+++ b/drivers/misc/eeprom/men_eeprod.c
@@ -0,0 +1,560 @@
+/*
+ * men_eeprod - MEN board information EEPROM driver.
+ *
+ * This is the driver for the Board Information EEPROM on almost
+ * all of the MEN boards.
+ * The driver exports each of the predefined eeprom sections as sysfs entries
+ * including an entry for user data.
+ *
+ * The EEPROM can be normally found at I2C address 0x57.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/*
+ * Supports the following EEPROM layouts:
+ *
+ * Nameeeprod_id user_section size
+ * --
+ * EEPROD2 0x0E232 byte
+ *
+ * See Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod
+ * for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EEPROM_ID_ADDR 0x00
+#define EEPROM_SIZE256
+#define EEPROD2_ID 0x0E
+
+#define DATE_YEAR_BIAS 1990
+
+/*
+ * Internal structure of the Board Information EEPROM
+ * production data section
+ */
+struct eeprom_data {
+ uint8_t eeprod_id;
+
+ uint8_t revision[3];
+ uint32_t serialnr;
+ uint8_t board_model;
+ char hw_name[6];
+
+ uint8_t reserved;
+
+ __be16 prod_date;
+ __be16 rep_date;
+
+ uint8_t reserved2[4];
+};
+
+struct men_eeprod_data {
+ struct bin_attribute user_section;
+ struct i2c_client *client;
+ struct eeprom_data eeprom;
+ struct mutex lock;
+ int smb_access;
+};
+
+static unsigned int i2c_timeout = 25;
+module_param(i2c_timeout, uint, 0);
+MODULE_PARM_DESC(i2c_timeout, "Time (in ms) to try reads and writes (default
25)");
+
+#define OFFSET_TO_USR_SECTION(off) (off + sizeof(struct eeprom_data))
+
+static inline int eeprod_get_day(__be16 eeprod_date)
+{
+ return be16_to_cpu(eeprod_date) & 0x001f;
+}
+
+static inline int eeprod_get_month(__be16 eeprod_date)
+{
+ return (be16_to_cpu(eeprod_date) >> 5) & 0x000f;
+}
+
+static inline int eeprod_get_year
[PATCH 0/2] Introduce MEN Board Information EEPROM driver
This patchset adds support for the MEN Board Information EEPROM. The EEPROM is assembled on almost all of the MEN hardware boards and is the main location to get information about the board. The driver exports the EEPROM data like production date, board name and serial number as read-only files as well as a user section for read-write access. There is also a ABI documentation for sysfs description included. Andreas Werner (2): drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver Documentation/ABI/testing/men_eeprod: Added sysfs description for men_eeprod .../ABI/testing/sysfs-bus-i2c-devices-men_eeprod | 69 +++ MAINTAINERS| 6 + drivers/misc/eeprom/Kconfig| 10 + drivers/misc/eeprom/Makefile | 1 + drivers/misc/eeprom/men_eeprod.c | 560 + 5 files changed, 646 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod create mode 100644 drivers/misc/eeprom/men_eeprod.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Documentation/ABI/testing/men_eeprod: Added sysfs description for men_eeprod
This patch adds the description for the men_eeprod. men_eeprod is a driver for the MEN Board Information EEPROM which exports the data using sysfs entries. Signed-off-by: Andreas Werner --- .../ABI/testing/sysfs-bus-i2c-devices-men_eeprod | 69 ++ 1 file changed, 69 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod b/Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod new file mode 100644 index 000..a488d0e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-men_eeprod @@ -0,0 +1,69 @@ +What: /sys/bus/i2c/devices/i2c-/-/eeprod_id +Date: October 2014 +Contact: Andreas Werner +Description: + Show the identifier of the EEPROM structure. + There are different layouts of the EEPROM with more or less + information. The ID identifies each of the layouts. + + Currently supported structure is EEPROD2 (0x0E) + +What: /sys/bus/i2c/devices/i2c-/-/revision +Date: October 2014 +Contact: Andreas Werner +Description: + Show the revision of the board. + Format of the revision field is XX.XX.XX + +What: /sys/bus/i2c/devices/i2c-/-/serialnr +Date: October 2014 +Contact: Andreas Werner +Description: + Show the serialnumber of the board. The serial number is + a decimal number. + +What: /sys/bus/i2c/devices/i2c-/-/hw_name +Date: October 2014 +Contact: Andreas Werner +Description: + Show the name of the board including the model. + There are boards which have different features such as + different size of RAM, the model identifies the different + types. + + Format of the hw_name is: . + Example: F075P00 where F75P is the hw_name and 00 the model. + +What: /sys/bus/i2c/devices/i2c-/-/prod_date +Date: October 2014 +Contact: Andreas Werner +Description: + Show the board production date. + + Format of the date: -MM-DD + +What: /sys/bus/i2c/devices/i2c-/-/rep_date +Date: October 2014 +Contact: Andreas Werner +Description: + Show the last repair date. + If the board returns back to the repair department, this field + will be programmed with the current date. + If the board has never returned, the field will be empty and + the read access to this sysfs entry returns -EINVAL. + + Format of the date: -MM-DD + +What: /sys/bus/i2c/devices/i2c-/-/user_section +Date: October 2014 +Contact: Andreas Werner +Description: + Read or write access to the user section of the EEPROM + This sysfs entry is a binary file where customer can write + there own data to. + The size of this file depends on the EEPROM layout which is + identified by the eeprod_id. + + eeprod_id user_section size + - + 0x0E232 byte -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] Introduce MEN 14F021P00 BMC driver series
On Wed, Sep 24, 2014 at 07:41:43PM +0100, Lee Jones wrote: > On Wed, 24 Sep 2014, Guenter Roeck wrote: > > > On Wed, Sep 24, 2014 at 09:33:32AM -0700, Bryan Wu wrote: > > > On Wed, Sep 24, 2014 at 9:18 AM, Lee Jones wrote: > > > > On Wed, 24 Sep 2014, Guenter Roeck wrote: > > > > > > > >> On Wed, Sep 24, 2014 at 03:48:29PM +0100, Lee Jones wrote: > > > >> > Guenter, Bryan, Wim, > > > >> > > > > >> > The following changes since commit > > > >> > 52addcf9d6669fa439387610bc65c92fa0980cef: > > > >> > > > > >> > Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) > > > >> > > > > >> > are available in the git repository at: > > > >> > > > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > > > >> > tags/mfd-hwmon-leds-watchdog-v3.18 > > > >> > > > > >> > for you to fetch changes up to > > > >> > 964356938fcd3c0001a786f55b9f0a0fbe47656a: > > > >> > > > > >> > hwmon: (menf21bmc) Introduce MEN14F021P00 BMC HWMON driver > > > >> > (2014-09-24 15:36:33 +0100) > > > >> > > > > >> > > > > >> > Immutable branch between MFD, HWMON, LEDs and Watchdog for v3.18 > > > >> > > > > >> I assume you'll push it all through mfd, correct ? > > > > > > > > The idea is for all the affected Maintainers to pull this branch in to > > > > their own trees. If you guys don't, there will be a good chance of > > > > conflict during the merge-window, which will subsequently upset Linus. > > > > > > > > So in answer to your question; yes I'll be taking this, but so should > > > > each of you. > > > > > > > > > > Thanks for this, man. What am I going to do here? Need I pull in all > > > the patches here into my LED tree or just one LED patch? I think if > > > you push this for Linus through MFD tree, I don't need to pull it into > > > my tree, right? > > > > > I did > > > > git remote add mfd git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > > git fetch --tags mfd > > git merge mfd-hwmon-leds-watchdog-v3.18 > > > > in both my hwmon-next and watchdog-next branches. Both are currently > > building, > > and already pushed into to my repository at kernel.org. > > > > So, effectively, when I send my pull request to Linus, all patches from > > mfd-hwmon-leds-watchdog-v3.18 will be included, ie the entire series. > > The same will happen when Lee sends his pull request, and Wim, and you. > > I believe that is what Lee is asking for. > > That's right. It's not okay to break this branch up. If it was, we > would have been able to apply our respective components into our own > trees from the beginning, but as there are interdependencies, breaking > up the branch could have nasty consequences depending on the order in > which they land in Mainline. Most likely bisectability will be > broken, which is not allowed. > Hi, please do not forget the MAINTAINERS Patch for this series. I have send it last week attached to this series. Thanks Regards Andy > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eeprom Board Information EEPROM
On Tue, Sep 16, 2014 at 01:14:36PM +0530, kavitha bk wrote:
> On Mon, Sep 15, 2014 at 10:52 PM, Andreas Werner wrote:
>
> > On Thu, Sep 04, 2014 at 09:59:53PM +0530, kavitha bk wrote:
> > > On Wed, Sep 3, 2014 at 8:04 PM, Andreas Werner
> > wrote:
> > >
> > > > Is there a way to access the eeprom data from within another driver?
> > > >
> > > Yes I had to access mac address from eeprom from smsc [ethernet driver]
> > > so I exported a function from eeprom driver
> > >
> > >
> > > > I have seen in at24 using the memory_accessor struct to allow access
> > e.g.
> > > > from platform driver,
> > > > but this is not want i want.
> > > >
> > > > Current driver sysfs iface:
> > > > Predefined sections exported (24byte):
> > > > - revision
> > > > - serialnr
> > > > - prod_date
> > > > - rep_date
> > > > - hw_name
> > > >
> > > > User memory (232 byte):
> > > > - user_eeprom (binary)
> > > >
> > > > This allows the userland to access the predefined data easily through
> > > > sysfs without
> > > > the need to format the eeprom bytes to get the right data.
> > > >
> > > > I also need an interface to have access within another driver e.g. we
> > have
> > > > an ethernet
> > > > driver which needs to read the serialnumber of the board.
> > > >
> > > > How can I do this?
> > > >
> > >
> > >
> > > Easy way is export a function in at24 driver but very bad it is
> > > Best way using memory_accessor.
> > > Explore memory_accessor
> > >
> > >
> > >
> > >
> > > struct memory_accessor *mem_acc =
> > driver->access_eeprom->serial_no
> > >
> > >
> > > if (!mem_acc->read || !mem_acc->write)
> > > return -EIO;
> > >
> > > ret = mem_acc->read(mem_acc, serial_no, offset, len);
> > > if (ret != len)
> > > return -EIO;
> > >
> > > return 0;
> > >
> > >
> > > > Regards
> > > > Andy
> > > >
> >
> > Hi,
> > i have checked the memory accessor. If i understand it right it is good if
> > I have some platform code.
> > The problem I have is, if I have some x86 system without platform config
> > (we normally have no BSP for x86)
> > the solution cannot work.
> >
> > Just a description of my problem.
> > I have an Ethernet driver which is a driver for a FPGA IP Core. The eth
> > runs at most on x86 systems.
> > Inside the driver i need a interface to the eeprom were I can access the
> > Serialnumber.
> >
> > For me the solution to export a function in the eeprom driver is the best
> > way to do it, isn´t it?
> >
>
>
> Yes may be it is appropriate to it this way in your case
>
Hi,
i have also tried to export a function, but the problem is that the data of the
eeprom is stored
in a structure of the eeprom driver, and i do not know how to get a
pointer/reference to
this structure to get access from within another driver.
Does anybody of you have another idea how to access eeprom data from within
another driver?
Thanks
Andy
> >
> > I hope it is clear what i want.
> >
> > Regards
> > Andy
> >
> >
> >
> >
> >
> > > > On Tue, Sep 02, 2014 at 01:30:52PM +0530, kavitha bk wrote:
> > > > > static ssize_t eeprom_read(struct device *dev,
> > > > > struct device_attribute *attr,
> > > > > char *buf) {
> > > > > struct i2c_client *client = to_i2c_client(dev);
> > > > > int ret = -1,i = 0;
> > > > > unsigned char sn[256];
> > > > >
> > > > > sn[0] = 0x00;
> > > > > sn[1] = 0x00;
> > > > >
> > > > > ret = i2c_master_send(client, sn, 2);
> > > > >
> > > > > if(ret == -1)
> > > > > pr_info("ERROR: I2C send error\n");
> > > > >
> > > > > ret = i2c_master_recv(client, sn, 256);
> > > > > if(ret == -1)
> > > > >
Re: [PATCH] MAINTAINERS: Adds Andreas Werner to maintainers list for MEN F21BMC
On Mon, Sep 15, 2014 at 11:42:19PM +0100, Lee Jones wrote: > On Mon, 15 Sep 2014, Andreas Werner wrote: > > > Added maintainer for the following MEN F21BMC drivers: > > - menf21bmc (MFD) > > - menf21bmc_wdt (Watchdog) > > - menf21bmc_hwmon (HWMON) > > - leds-menf21bmc (LED) > > > > Signed-off-by: Andreas Werner > > --- > > MAINTAINERS | 9 + > > 1 file changed, 9 insertions(+) > > Acked-by: Lee Jones > Thanks. I think we are almost complete. Just the Watchdog needs to be Acked if everything is ok. Regards Andy > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 65cc66d..c4a188c 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5938,6 +5938,15 @@ S: Supported > > F: drivers/mcb/ > > F: include/linux/mcb.h > > > > +MEN F21BMC (Board Management Controller) > > +M: Andreas Werner > > +S: Supported > > +F: drivers/mfd/menf21bmc.c > > +F: drivers/watchdog/menf21bmc_wdt.c > > +F: drivers/leds/leds-menf21bmc.c > > +F: drivers/hwmon/menf21bmc_hwmon.c > > +F: Documentation/hwmon/menf21bmc > > + > > METAG ARCHITECTURE > > M: James Hogan > > L: linux-me...@vger.kernel.org > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Adds Andreas Werner to maintainers list for MEN F21BMC
Added maintainer for the following MEN F21BMC drivers: - menf21bmc (MFD) - menf21bmc_wdt (Watchdog) - menf21bmc_hwmon (HWMON) - leds-menf21bmc (LED) Signed-off-by: Andreas Werner --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 65cc66d..c4a188c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5938,6 +5938,15 @@ S: Supported F: drivers/mcb/ F: include/linux/mcb.h +MEN F21BMC (Board Management Controller) +M: Andreas Werner +S: Supported +F: drivers/mfd/menf21bmc.c +F: drivers/watchdog/menf21bmc_wdt.c +F: drivers/leds/leds-menf21bmc.c +F: drivers/hwmon/menf21bmc_hwmon.c +F: Documentation/hwmon/menf21bmc + METAG ARCHITECTURE M: James Hogan L: linux-me...@vger.kernel.org -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
>> right, use that to call phy_init() at the right time, then you need to >> add a new ->calibrate() method which, likely, will only be used by you >> ;-) > so you mean, the xhci should itself call phy_init() at a time suitable, > so that ->calibrate() is not required at all ? I'm not sure if that's a good idea because it would require phy_init() and calibrate() to always mean the same thing. The calibrate() for Exynos5420 needs to be called both during boot and after system resume, but there might be other platforms that don't want to completely shutdown and reinit their PHYs during suspend/resume with the same functions used for boot. For example, Tegra5 (proposed driver at http://www.spinics.net/lists/linux-usb/msg113093.html) can power-gate the PHY during suspend, but that's not running the same code as in the phy_init()/phy_shutdown() methods (the posted patch doesn't contain all power-gating code yet, but you can get an idea about how it has to work from https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.10/drivers/usb/host/xhci-tegra.c). It would also mean that the initial phy_init() call must always come after the XHCI reset, and I am not sure if that would fit nicely with all platforms. > right, and what's more generic than adding the support for PHYs straight into > xHCI ? Well, if we are going to have a calibrate() method (as in "stuff the PHY does after every controller reset if it needs to"), we have to add it either to the XHCI stack or the USB core. I thought the USB core would be more generic, because in theory it's possible that e.g. an EHCI controller might have a similar requirement. (Also, we have the gen_phy pointer in a USB core structure (struct usb_hcd), so I thought making this feature generic to the USB core and thus available to all kinds of host controllers would be more natural.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eeprom Board Information EEPROM
On Mon, Sep 01, 2014 at 01:52:10PM +0530, kavitha bk wrote: > On Sat, Aug 30, 2014 at 2:26 AM, Andreas Werner wrote: > > > I have a question regarding a driver for a Board Information EEPROM. > > > > I want to give our customer easy access to our Board Information EEPROM > > which is an 256byte I2C eeprom. > > > > > > > > There is a defined structure of information at the beginning of the eeprom > > which includes board name, serialnumber, production date, repair date and > > a eeprom structure ident number. > > > > The rest of the eeprom is for user defined settings where customer can > > write > > any data to. > > > > I want to have access to the eeprom without any special to and without > > installing > > anything just running linux and to a cat/echo to sysfs entries to > > read/write > > data to the eeprom. > > > > What i want to do is to create sysfs entries for the pre defined settings > > and > > on entrie where customer can access the rest of the eeprom bytes. > > > > Is drivers/misc/eeprom the right place to put those kind of driver in? > > > Yes You can add here > > > Or are > > there any other options to write those kind of driver? > > > > Which eeprom are you using? You can explore CONFIG_EEPROM_AT24 driver for > writing a sys interface > Ok i will check it out. Thanks. Regards Andy > > > > > > > Regards > > Andy > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
eeprom Board Information EEPROM
I have a question regarding a driver for a Board Information EEPROM. I want to give our customer easy access to our Board Information EEPROM which is an 256byte I2C eeprom. There is a defined structure of information at the beginning of the eeprom which includes board name, serialnumber, production date, repair date and a eeprom structure ident number. The rest of the eeprom is for user defined settings where customer can write any data to. I want to have access to the eeprom without any special to and without installing anything just running linux and to a cat/echo to sysfs entries to read/write data to the eeprom. What i want to do is to create sysfs entries for the pre defined settings and on entrie where customer can access the rest of the eeprom bytes. Is drivers/misc/eeprom the right place to put those kind of driver in? Or are there any other options to write those kind of driver? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/4] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
On Fri, Aug 29, 2014 at 07:59:15AM +0100, Lee Jones wrote:
> On Thu, 28 Aug 2014, Bryan Wu wrote:
>
> > On Wed, Aug 27, 2014 at 10:52 AM, Andreas Werner
> > wrote:
> > > Added driver to support the 14F021P00 BMC LEDs.
> > > The BMC is a Board Management Controller including four LEDs which
> > > can be switched on and off.
> > >
> >
> > Please go ahead with my Ack
> > Acked-by: Bryan Wu
> >
> > Lee, will you merge this through your tree? I think we do that in one
> > shot is better.
>
> Yes, that's fine. Pull-request to follow.
>
Thanks to all for review.
Who of you does the Watchdog part? Is it the part of Wim to Ack the patch
if everythings is right or Guenther?
I ask because if everything is ok all the patches can go in completly that would
be nice.
Regards
Andy
> > > Signed-off-by: Andreas Werner
> > > ---
> > > drivers/leds/Kconfig | 9 +++
> > > drivers/leds/Makefile | 1 +
> > > drivers/leds/leds-menf21bmc.c | 131
> > > ++
> > > 3 files changed, 141 insertions(+)
> > > create mode 100644 drivers/leds/leds-menf21bmc.c
> > >
> > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > > index 27cf0cd..ec03457 100644
> > > --- a/drivers/leds/Kconfig
> > > +++ b/drivers/leds/Kconfig
> > > @@ -458,6 +458,15 @@ config LEDS_OT200
> > > This option enables support for the LEDs on the Bachmann OT200.
> > > Say Y to enable LEDs on the Bachmann OT200.
> > >
> > > +config LEDS_MENF21BMC
> > > + tristate "LED support for the MEN 14F021P00 BMC"
> > > + depends on LEDS_CLASS && MFD_MENF21BMC
> > > + help
> > > + Say Y here to include support for the MEN 14F021P00 BMC LEDs.
> > > +
> > > + This driver can also be built as a module. If so the module
> > > + will be called leds-menf21bmc.
> > > +
> > > comment "LED driver for blink(1) USB RGB LED is under Special HID
> > > drivers (HID_THINGM)"
> > >
> > > config LEDS_BLINKM
> > > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > > index 3c03666..cadc433 100644
> > > --- a/drivers/leds/Makefile
> > > +++ b/drivers/leds/Makefile
> > > @@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
> > > obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
> > > obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> > > obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> > > +obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> > >
> > > # LED SPI Drivers
> > > obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> > > diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
> > > new file mode 100644
> > > index 000..89dd577
> > > --- /dev/null
> > > +++ b/drivers/leds/leds-menf21bmc.c
> > > @@ -0,0 +1,131 @@
> > > +/*
> > > + * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
> > > + *
> > > + * This is the core LED driver of the MEN 14F021P00 BMC.
> > > + * There are four LEDs available which can be switched on and off.
> > > + * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
> > > + *
> > > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > modify it
> > > + * under the terms of the GNU General Public License as published by
> > > the
> > > + * Free Software Foundation; either version 2 of the License, or (at
> > > your
> > > + * option) any later version.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define BMC_CMD_LED_GET_SET0xA0
> > > +#define BMC_BIT_LED_STATUS BIT(0)
> > > +#define BMC_BIT_LED_HOTSWAPBIT(1)
> > > +#define BMC_BIT_LED_USER1 BIT(2)
> > > +#define BMC_BIT_LED_USER2 BIT(3)
> > > +
> > > +struct menf21bmc_led {
> > > + struct led_classdev cdev;
> > > + u8 led_bit;
> > > + const char *name;
> > > + struct i2c_client *i2c_client;
> > > +};
> > > +
> > > +static struct menf21bmc_led leds[] =
Re: [PATCH v6 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
On Wed, Aug 27, 2014 at 11:38:43AM -0700, Guenter Roeck wrote: > On Wed, Aug 27, 2014 at 07:53:06PM +0200, Andreas Werner wrote: > > Added driver to support the 14F021P00 BMC Hardware Monitoring. > > The BMC is a Board Management Controller including monitoring of the > > board voltages. > > > > Signed-off-by: Andreas Werner > > Looks good, though I do have one comment ... > > > + > > + hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, > > + "menf21bmc", drv_data, > > + menf21bmc_hwmon_groups); > > + if (IS_ERR(hwmon_dev)) > > + return PTR_ERR(hwmon_dev); > > + > > + dev_info(&pdev->dev, "MEN 14F021P00 BMC hwmon device enabled"); > > + > You removed the dev_info from the mfd driver but left it in the client > drivers. If you'd drop it here as well, you could use > 'return PTR_ERR_OR_ZERO(hwmon_dev);'. Just a suggestion, not mandatory. > > Either case, It is a nice info for every slave driver which are the drivers for accessing the features in the BMC. The mfd is just the driver who will instantiate the slaves. For the mfd the most important info is if there was an error. Anyway good idea with PTR_ERR_OR_ZERO. Thanks for the nice review and the comments. Regards Andy > > Reviewed-by: Guenter Roeck > > I assume this will go in through the mfd tree. > > Thanks, > Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 15 ++
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
3 files changed, 148 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..1020725 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,21 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED, HWMON and WDT.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
+ This driver can also be built as a module. If so the module
+ will be called menf21bmc.
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..37bf336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..1c27434
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,132 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_WDT_EXIT_PROD 0x18
+#define BMC_CMD_WDT_PROD_STAT 0x19
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+
+static struct mfd_cell menf21bmc_cell[] = {
+ { .name = "menf21bmc_wdt", },
+ { .name = "menf21bmc_led", },
+ { .name = "menf21bmc_hwmon", }
+};
+
+static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
+ if (val < 0)
+ return val;
+
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and exit the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(&client->dev,
+ "BMC in production mode. Exit production mode\n");
+
+ ret = i2c_smbus_write_byte(client, BMC_CMD_WDT_EXIT_PROD);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+menf21bmc_probe(struct i2c_client *client, const struct i2c_device_id *ids)
+{
+ int rev_major, rev_minor, rev_main;
+ int ret;
+
+ ret = i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BYTE);
+ if (!ret)
+ return -ENODEV;
+
+ rev_major = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAJOR);
+ if (rev_major < 0) {
+ dev_err(&client->dev, "failed to get BMC major revision\n");
+ return rev_major;
+ }
+
+ rev_minor = i2c_smbus_read_word_data(client, BMC_CMD_REV_MINOR);
+ if (rev_minor < 0) {
+ dev_err(&client->dev, "failed to get BMC minor revision\n");
+ return re
[PATCH v6 3/4] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controller including four LEDs which
can be switched on and off.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 9 +++
drivers/leds/Makefile | 1 +
drivers/leds/leds-menf21bmc.c | 131 ++
3 files changed, 141 insertions(+)
create mode 100644 drivers/leds/leds-menf21bmc.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 27cf0cd..ec03457 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -458,6 +458,15 @@ config LEDS_OT200
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
+config LEDS_MENF21BMC
+ tristate "LED support for the MEN 14F021P00 BMC"
+ depends on LEDS_CLASS && MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC LEDs.
+
+ This driver can also be built as a module. If so the module
+ will be called leds-menf21bmc.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3c03666..cadc433 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
new file mode 100644
index 000..89dd577
--- /dev/null
+++ b/drivers/leds/leds-menf21bmc.c
@@ -0,0 +1,131 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
+ *
+ * This is the core LED driver of the MEN 14F021P00 BMC.
+ * There are four LEDs available which can be switched on and off.
+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_LED_GET_SET0xA0
+#define BMC_BIT_LED_STATUS BIT(0)
+#define BMC_BIT_LED_HOTSWAPBIT(1)
+#define BMC_BIT_LED_USER1 BIT(2)
+#define BMC_BIT_LED_USER2 BIT(3)
+
+struct menf21bmc_led {
+ struct led_classdev cdev;
+ u8 led_bit;
+ const char *name;
+ struct i2c_client *i2c_client;
+};
+
+static struct menf21bmc_led leds[] = {
+ {
+ .name = "menf21bmc:led_status",
+ .led_bit = BMC_BIT_LED_STATUS,
+ },
+ {
+ .name = "menf21bmc:led_hotswap",
+ .led_bit = BMC_BIT_LED_HOTSWAP,
+ },
+ {
+ .name = "menf21bmc:led_user1",
+ .led_bit = BMC_BIT_LED_USER1,
+ },
+ {
+ .name = "menf21bmc:led_user2",
+ .led_bit = BMC_BIT_LED_USER2,
+ }
+};
+
+static DEFINE_MUTEX(led_lock);
+
+static void
+menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ int led_val;
+ struct menf21bmc_led *led = container_of(led_cdev,
+ struct menf21bmc_led, cdev);
+
+ mutex_lock(&led_lock);
+ led_val = i2c_smbus_read_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET);
+ if (led_val < 0)
+ goto err_out;
+
+ if (value == LED_OFF)
+ led_val &= ~led->led_bit;
+ else
+ led_val |= led->led_bit;
+
+ i2c_smbus_write_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET, led_val);
+err_out:
+ mutex_unlock(&led_lock);
+}
+
+static int menf21bmc_led_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct i2c_client *i2c_client = to_i2c_client(pdev->dev.parent);
+
+ for (i = 0; i < ARRAY_SIZE(leds); i++) {
+ leds[i].cdev.name = leds[i].name;
+ leds[i].cdev.brightness_set = menf21bmc_led_set;
+ leds[i].i2c_client = i2c_client;
+ ret = led_classdev_register(&pdev->dev, &leds[i].cdev);
+ if (ret < 0)
+ goto err_free_leds;
+ }
+ dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");
+
+ return 0;
+
+err_free_leds:
+ dev_err(&pde
[PATCH v6 2/4] drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/menf21bmc_wdt.c | 203 +++
3 files changed, 214 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..96d72c2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,16 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
+ This driver can also be built as a module. If so the module
+ will be called menf21bmc_wdt.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 468c320..de17014 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
diff --git a/drivers/watchdog/menf21bmc_wdt.c b/drivers/watchdog/menf21bmc_wdt.c
new file mode 100644
index 000..2042874
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wdt.c
@@ -0,0 +1,203 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wdt"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wdt {
+ struct watchdog_device wdt;
+ struct i2c_client *i2c_client;
+};
+
+static int menf21bmc_wdt_set_bootstatus(struct menf21bmc_wdt *data)
+{
+ int rst_rsn;
+
+ rst_rsn = i2c_smbus_read_byte_data(data->i2c_client, BMC_CMD_RST_RSN);
+ if (rst_rsn < 0)
+ return rst_rsn;
+
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_start(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_ON);
+}
+
+static int menf21bmc_wdt_stop(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte_data(drv_data->i2c_client,
+BMC_CMD_WD_OFF, BMC_WD_OFF_VAL);
+}
+
+static int
+menf21bmc_wdt_settimeout(struct watchdog_device *wdt, unsigned int timeout)
+{
+ int ret;
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ /*
+* BMC Watchdog does have a resolution of 100ms.
+* Watchdog API defines the timeout in seconds, so we have to
+* multiply the value.
+*/
+ ret = i2c_smbus_write_word_data(drv_data->i2c_client,
+ BMC_CMD_WD_TIME, timeout * 10);
+ if (ret < 0)
+ return ret;
+
+ wdt->timeout = timeout;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_ping(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2
[PATCH v6 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
Added driver to support the 14F021P00 BMC Hardware Monitoring.
The BMC is a Board Management Controller including monitoring of the
board voltages.
Signed-off-by: Andreas Werner
---
Documentation/hwmon/menf21bmc | 50 +
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/menf21bmc_hwmon.c | 230
4 files changed, 291 insertions(+)
create mode 100644 Documentation/hwmon/menf21bmc
create mode 100644 drivers/hwmon/menf21bmc_hwmon.c
diff --git a/Documentation/hwmon/menf21bmc b/Documentation/hwmon/menf21bmc
new file mode 100644
index 000..2a273a0
--- /dev/null
+++ b/Documentation/hwmon/menf21bmc
@@ -0,0 +1,50 @@
+Kernel driver menf21bmc_hwmon
+=
+
+Supported chips:
+ * MEN 14F021P00
+ Prefix: 'menf21bmc_hwmon'
+ Adresses scanned: -
+
+Author: Andreas Werner
+
+Description
+---
+
+The menf21bmc is a Board Management Controller (BMC) which provides an I2C
+interface to the host to access the features implemented in the BMC.
+
+This driver gives access to the voltage monitoring feature of the main
+voltages of the board.
+The voltage sensors are connected to the ADC inputs of the BMC which is
+a PIC16F917 Mikrocontroller.
+
+Usage Notes
+---
+
+This driver is part of the MFD driver named "menf21bmc" and does
+not auto-detect devices.
+You will have to instantiate the MFD driver explicitly.
+Please see Documentation/i2c/instantiating-devices for
+details.
+
+Sysfs entries
+-
+
+The following attributes are supported. All attributes are read only
+The Limits are read once by the driver.
+
+in0_input +3.3V input voltage
+in1_input +5.0V input voltage
+in2_input +12.0V input voltage
+in3_input +5V Standby input voltage
+in4_input VBAT (on board battery)
+
+in[0-4]_minMinimum voltage limit
+in[0-4]_maxMaximum voltage limit
+
+in0_label "MON_3_3V"
+in1_label "MON_5V"
+in2_label "MON_12V"
+in3_label "5V_STANDBY"
+in4_label "VBAT"
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 37908ff..1063d73 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -828,6 +828,16 @@ config SENSORS_MCP3021
This driver can also be built as a module. If so, the module
will be called mcp3021.
+config SENSORS_MENF21BMC_HWMON
+ tristate "MEN 14F021P00 BMC Hardware Monitoring"
+ depends on MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC
+ hardware monitoring.
+
+ This driver can also be built as a module. If so the module
+ will be called menf21bmc_hwmon.
+
config SENSORS_ADCXX
tristate "National Semiconductor ADCxxxSxxx"
depends on SPI_MASTER
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 1362382..56ab872 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
+obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o
obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
diff --git a/drivers/hwmon/menf21bmc_hwmon.c b/drivers/hwmon/menf21bmc_hwmon.c
new file mode 100644
index 000..c92229d
--- /dev/null
+++ b/drivers/hwmon/menf21bmc_hwmon.c
@@ -0,0 +1,230 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) hwmon driver.
+ *
+ * This is the core hwmon driver of the MEN 14F021P00 BMC.
+ * The BMC monitors the board voltages which can be access with this
+ * driver through sysfs.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "menf21bmc_hwmon"
+
+#define BMC_VOLT_COUNT 5
+#define MENF21BMC_V33 0
+#define MENF21BMC_V5 1
+#define MENF21BMC_V12 2
+#define MENF21BMC_V5_SB3
+#define MENF21BMC_VBAT 4
+
+#define IDX_TO_VOLT_MIN_CMD(idx) (0x40 + idx)
+#define IDX_TO_VOLT_MAX_CMD(idx) (0x50 + idx)
+#define IDX_TO_VOLT_INP_CMD(idx) (0x60 + idx)
+
+struct menf21bmc_hwmon {
+ bool valid;
+ struct i2c_client *i2c_client;
+ unsigned long last_update;
+ int in_val[BMC_VOLT_COUNT];
+ int in_min[BMC_VOLT_COUNT];
+ int in_max[BMC_VOLT_COUNT];
+};
+
+static const char *const input
[PATCH v6 0/4] Introduce MEN 14F021P00 BMC driver series
This patch set add support for the MEN 14F021P00 Board Management called BMC. The BMC is a PIC Mikrocontroller which assembled on almost all of our 3U Compact PCI CPU board and a few Box PCs. main part of the BMC is to start and monitor the board, but there are a lot more features which can be accessed using an I2C Host interface Features supported in this Patchset: - Watchdog - LEDs - HWMON The Patchset includes a MFD Core driver, Watchdog, hwmon and LEDs driver. Changes in v6: - fixed some style issues (80 chars, whitespaces, alignment) - fixed error handling in update function of hwmon slave - fixed whitespace error in hwmon documentation - added module name in each of the Kconfigs Changes in v5: - fixed I2C dependency in MFD Kconfig - added correct error handling in update function of the hwmon slave (Use of ERR_PTR) - add ATTRIBUTE_GROUP Macro in hwmon slave and deleted platform_set_drvdata Changes in v4: - fixed some style issues - fixed GPL license version - added hwmon voltage monitoring slave driver Changes in v3: - deleted i2c_smbus wrapper functions and use native one - some cosmentics and variable renaming to be more clear - renamed "leave production" mode to "exit production mode" Changes in v2: - changed i2c_smbus_read wrapper function to return both, value and error. - moved "leave production mode" from Watchdog driver to mfd core. - fixed some return values in the watchdog driver to return the original error value instead of -EIO. Andreas Werner (4): drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver Documentation/hwmon/menf21bmc| 50 + drivers/hwmon/Kconfig| 10 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/menf21bmc_hwmon.c | 230 +++ drivers/leds/Kconfig | 9 ++ drivers/leds/Makefile| 1 + drivers/leds/leds-menf21bmc.c| 131 ++ drivers/mfd/Kconfig | 15 +++ drivers/mfd/Makefile | 1 + drivers/mfd/menf21bmc.c | 132 ++ drivers/watchdog/Kconfig | 10 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/menf21bmc_wdt.c | 203 ++ 13 files changed, 794 insertions(+) create mode 100644 Documentation/hwmon/menf21bmc create mode 100644 drivers/hwmon/menf21bmc_hwmon.c create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wdt.c -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, Aug 27, 2014 at 12:01:42PM +0100, Lee Jones wrote:
> On Wed, 27 Aug 2014, Andreas Werner wrote:
> > On Wed, Aug 27, 2014 at 08:26:33AM +0100, Lee Jones wrote:
> > > On Tue, 26 Aug 2014, Andreas Werner wrote:
> > > > The MEN 14F021P00 Board Management Controller provides an
> > > > I2C interface to the host to access the feature implemented in the BMC.
> > > > The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> > > > Mikroelektronik
> > > > and on a few Box/Display Computer.
> > > >
> > > > Added MFD Core driver, supporting the I2C communication to the device.
> > > >
> > > > The MFD driver currently supports the following features:
> > > > - Watchdog
> > > > - LEDs
> > > > - Hwmon (voltage monitoring)
> > > >
> > > > Signed-off-by: Andreas Werner
> > > > Acked-by: Lee Jones
> > > > ---
> > > > drivers/mfd/Kconfig | 12 +
> > > > drivers/mfd/Makefile| 1 +
> > > > drivers/mfd/menf21bmc.c | 132
> > > >
> > > > 3 files changed, 145 insertions(+)
> > > > create mode 100644 drivers/mfd/menf21bmc.c
> > > >
> > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > > index b8d9ca0..6a9f101 100644
> > > > --- a/drivers/mfd/Kconfig
> > > > +++ b/drivers/mfd/Kconfig
> > > > @@ -453,6 +453,18 @@ config MFD_MAX8998
> > > > additional drivers must be enabled in order to use the
> > > > functionality
> > > > of the device.
> > > >
> > > > +config MFD_MENF21BMC
> > > > + tristate "MEN 14F021P00 Board Management Controller Support"
> > > > + depends on I2C
> > > > + select MFD_CORE
> > > > + help
> > > > + Say yes here to add support for the MEN 14F021P00 BMC
> > > > + which is a Board Management Controller connected to the I2C
> > > > bus.
> > > > + The device supports multiple sub-devices like LED, HWMON and
> > > > WDT.
> > >
> > > Nit: Whitespace error.
> > >
> >
> > I run checkpatch but did not find any whitespace error.
> > Where is it?
>
> After 'HWMON'.
>
Ah ok.
> > > > +MODULE_DEVICE_TABLE(i2c, menf21bmc_id_table);
> > > > +
> > > > +static struct i2c_driver menf21bmc_driver = {
> > > > + .driver.name= "menf21bmc",
> > > > + .id_table = menf21bmc_id_table,
> > > > + .probe = menf21bmc_probe,
> > > > + .remove = menf21bmc_remove,
> > > > +};
> > >
> > > No DT support?
> > >
> >
> > No not at the moment because it is used only on x86 system.
>
> Ah okay. Shouldn't the Kconfig depend on X86 then? What about ACPI?
Yes and no. Could be also instantiated manually withouth DT. (e.g. i2c sysfs)
So for me it is better to not depend on x86 to have the possibility to use
the driver without DT on another arch.
ACPI is no option because there are a lot boards out without
the BMC in ACPI Table.
I think i will implement DT support if we have on board which is not x86.
>
> > > > +module_i2c_driver(menf21bmc_driver);
> > > > +
> > > > +MODULE_DESCRIPTION("MEN 14F021P00 BMC mfd core driver");
> > >
> > > s/mfd/MFD
> > >
> > > > +MODULE_AUTHOR("Andreas Werner ");
> > > > +MODULE_LICENSE("GPL v2");
> > >
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, Aug 27, 2014 at 08:26:33AM +0100, Lee Jones wrote:
> On Tue, 26 Aug 2014, Andreas Werner wrote:
> > The MEN 14F021P00 Board Management Controller provides an
> > I2C interface to the host to access the feature implemented in the BMC.
> > The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> > Mikroelektronik
> > and on a few Box/Display Computer.
> >
> > Added MFD Core driver, supporting the I2C communication to the device.
> >
> > The MFD driver currently supports the following features:
> > - Watchdog
> > - LEDs
> > - Hwmon (voltage monitoring)
> >
> > Signed-off-by: Andreas Werner
> > Acked-by: Lee Jones
> > ---
> > drivers/mfd/Kconfig | 12 +
> > drivers/mfd/Makefile| 1 +
> > drivers/mfd/menf21bmc.c | 132
> >
> > 3 files changed, 145 insertions(+)
> > create mode 100644 drivers/mfd/menf21bmc.c
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index b8d9ca0..6a9f101 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -453,6 +453,18 @@ config MFD_MAX8998
> > additional drivers must be enabled in order to use the functionality
> > of the device.
> >
> > +config MFD_MENF21BMC
> > + tristate "MEN 14F021P00 Board Management Controller Support"
> > + depends on I2C
> > + select MFD_CORE
> > + help
> > + Say yes here to add support for the MEN 14F021P00 BMC
> > + which is a Board Management Controller connected to the I2C bus.
> > + The device supports multiple sub-devices like LED, HWMON and WDT.
>
> Nit: Whitespace error.
>
I run checkpatch but did not find any whitespace error.
Where is it?
...
> > +MODULE_DEVICE_TABLE(i2c, menf21bmc_id_table);
> > +
> > +static struct i2c_driver menf21bmc_driver = {
> > + .driver.name= "menf21bmc",
> > + .id_table = menf21bmc_id_table,
> > + .probe = menf21bmc_probe,
> > + .remove = menf21bmc_remove,
> > +};
>
> No DT support?
>
No not at the moment because it is used only on x86 system.
> > +module_i2c_driver(menf21bmc_driver);
> > +
> > +MODULE_DESCRIPTION("MEN 14F021P00 BMC mfd core driver");
>
> s/mfd/MFD
>
> > +MODULE_AUTHOR("Andreas Werner ");
> > +MODULE_LICENSE("GPL v2");
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, Aug 27, 2014 at 08:26:33AM +0100, Lee Jones wrote:
> On Tue, 26 Aug 2014, Andreas Werner wrote:
> > The MEN 14F021P00 Board Management Controller provides an
> > I2C interface to the host to access the feature implemented in the BMC.
> > The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> > Mikroelektronik
> > and on a few Box/Display Computer.
> >
> > Added MFD Core driver, supporting the I2C communication to the device.
> >
> > The MFD driver currently supports the following features:
> > - Watchdog
> > - LEDs
> > - Hwmon (voltage monitoring)
> >
> > Signed-off-by: Andreas Werner
> > Acked-by: Lee Jones
> > ---
> > drivers/mfd/Kconfig | 12 +
> > drivers/mfd/Makefile| 1 +
> > drivers/mfd/menf21bmc.c | 132
> >
> > 3 files changed, 145 insertions(+)
> > create mode 100644 drivers/mfd/menf21bmc.c
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index b8d9ca0..6a9f101 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -453,6 +453,18 @@ config MFD_MAX8998
> > additional drivers must be enabled in order to use the functionality
> > of the device.
> >
> > +config MFD_MENF21BMC
> > + tristate "MEN 14F021P00 Board Management Controller Support"
> > + depends on I2C
> > + select MFD_CORE
> > + help
> > + Say yes here to add support for the MEN 14F021P00 BMC
> > + which is a Board Management Controller connected to the I2C bus.
> > + The device supports multiple sub-devices like LED, HWMON and WDT.
>
> Nit: Whitespace error.
>
Forgot to run checkpatch on Kconfig since the last change. Will fix it.
> > + This driver provides common support for accessing the devices;
> > + additional drivers must be enabled in order to use the
> > + functionality of the BMC device.
> > +
> > config EZX_PCAP
> > bool "Motorola EZXPCAP Support"
> > depends on SPI_MASTER
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 4e2bc25..37bf336 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
> > obj-$(CONFIG_MFD_AS3722) += as3722.o
> > obj-$(CONFIG_MFD_STW481X) += stw481x.o
> > obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> > +obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
> >
> > intel-soc-pmic-objs:= intel_soc_pmic_core.o
> > intel_soc_pmic_crc.o
> > obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> > diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
> > new file mode 100644
> > index 000..a6eb03f
> > --- /dev/null
> > +++ b/drivers/mfd/menf21bmc.c
> > @@ -0,0 +1,132 @@
> > +/*
> > + * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
> > + *
> > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > it
> > + * under the terms of the GNU General Public License as published by
> > the
> > + * Free Software Foundation; either version 2 of the License, or (at
> > your
> > + * option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define BMC_CMD_WDT_EXIT_PROD 0x18
> > +#define BMC_CMD_WDT_PROD_STAT 0x19
> > +#define BMC_CMD_REV_MAJOR 0x80
> > +#define BMC_CMD_REV_MINOR 0x81
> > +#define BMC_CMD_REV_MAIN 0x82
> > +
> > +static struct mfd_cell menf21bmc_cell[] = {
> > + { .name = "menf21bmc_wdt", },
> > + { .name = "menf21bmc_led", },
> > + { .name = "menf21bmc_hwmon", }
> > +};
> > +
> > +static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
> > +{
> > + int val, ret;
> > +
> > + val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
> > + if (val < 0)
> > + return val;
> > +
> > + /*
> > +* Production mode should be not active after delivery of the Board.
> > +* To be sure we check it, inform the user and exit the mode
> > +* if active.
> > +*/
> > + if (val == 0x00) {
> > + dev_info(&client->dev,
> > +
Re: [PATCH v5 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
On Tue, Aug 26, 2014 at 10:15:41AM -0700, Guenter Roeck wrote: > On Tue, Aug 26, 2014 at 07:46:53PM +0200, Andreas Werner wrote: > > Added driver to support the 14F021P00 BMC Hardware Monitoring. > > The BMC is a Board Management Controller including monitoring of the > > board voltages. > > > > Signed-off-by: Andreas Werner > > Hi Andreas, > > Couple of additional comments below. Sorry I didn't notice earlier. > > Guenter > > > --- > > Documentation/hwmon/menf21bmc | 49 + > > drivers/hwmon/Kconfig | 7 ++ > > drivers/hwmon/Makefile | 1 + > > drivers/hwmon/menf21bmc_hwmon.c | 230 > > > > 4 files changed, 287 insertions(+) > > create mode 100644 Documentation/hwmon/menf21bmc > > create mode 100644 drivers/hwmon/menf21bmc_hwmon.c > > > > diff --git a/Documentation/hwmon/menf21bmc b/Documentation/hwmon/menf21bmc > > new file mode 100644 > > index 000..22b6840 > > --- /dev/null > > +++ b/Documentation/hwmon/menf21bmc > > @@ -0,0 +1,49 @@ > > +Kernel driver menf21bmc_hwmon > > +===== > > + > > +Supported chips: > > + * MEN 14F021P00 > > + Prefix: 'menf21bmc_hwmon' > > + Adresses scanned: - > > + > > +Author: Andreas Werner > > + > > +Description > > +--- > > + > > +The menf21bmc is a Board Management Controller (BMC) which provides an I2C > > +interface to the host to access the features implemented in the BMC. > > + > > +This driver gives access to the voltage monitoring feature of the main > > +voltages of the board. > > +The voltage sensors are connected to the ADC inputs of the BMC which is > > +a PIC16F917 Mikrocontroller. > > + > > +Usage Notes > > +--- > > + > > +This driver does not auto-detect devices. You will have to instantiate the > > +devices explicitly. Please see Documentation/i2c/instantiating-devices for > > +details. > > + > > +Sysfs entries > > +- > > + > > +The following attributes are supported. All attributes are read only > > +The Limits are read once by the driver. > > + > > +in0_input +3.3V input voltage > > +in1_input +5.0V input voltage > > +in2_input +12.0V input voltage > > +in3_input +5V Standby input voltage > > +in4_input VBAT (on board battery) > > + > > +in[0-4]_minMinimum voltage limit > > +in[0-4]_maxMaximum voltage limit > > + > > +in0_label "MON_3_3V" > > +in1_label "MON_5V" > > +in2_label "MON_12V" > > +in3_label "5V_STANDBY" > > +in4_label "VBAT" > > + > > The empty line adds a whitespace error when applying the patch. > OK, will delete the line. > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > > index 37908ff..db3a6eb 100644 > > --- a/drivers/hwmon/Kconfig > > +++ b/drivers/hwmon/Kconfig > > @@ -828,6 +828,13 @@ config SENSORS_MCP3021 > > This driver can also be built as a module. If so, the module > > will be called mcp3021. > > > > +config SENSORS_MENF21BMC_HWMON > > + tristate "MEN 14F021P00 BMC Hardware Monitoring" > > + depends on MFD_MENF21BMC > > + help > > + Say Y here to include support for the MEN 14F021P00 BMC > > + hardware monitoring. > > + > It is customary to add a note describing how the module is called > if the driver is built as module. > OK i just write a line which describes the module name. > > config SENSORS_ADCXX > > tristate "National Semiconductor ADCxxxSxxx" > > depends on SPI_MASTER > > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > > index 1362382..56ab872 100644 > > --- a/drivers/hwmon/Makefile > > +++ b/drivers/hwmon/Makefile > > @@ -114,6 +114,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o > > obj-$(CONFIG_SENSORS_MAX6697) += max6697.o > > obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o > > obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o > > +obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o > > obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o > > obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o > > obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o > > diff --git a/drivers/hwmon/menf21bmc_hwmon.c > > b/drivers/hwmon/menf21bmc_hwmon.c > > new file mode 100644 > > index 000..2eaec6a > > --- /dev/null
[PATCH v5 0/4] Introduce MEN 14F021P00 BMC driver series
This patch set add support for the MEN 14F021P00 Board Management called BMC. The BMC is a PIC Mikrocontroller which assembled on almost all of our 3U Compact PCI CPU board and a few Box PCs. main part of the BMC is to start and monitor the board, but there are a lot more features which can be accessed using an I2C Host interface Features supported in this Patchset: - Watchdog - LEDs - HWMON The Patchset includes a MFD Core driver, Watchdog, hwmon and LEDs driver. Changes in v5: - fixed I2C dependency in MFD Kconfig - added correct error handling in update function of the hwmon slave (Use of ERR_PTR) - add ATTRIBUTE_GROUP Macro in hwmon slave and deleted platform_set_drvdata Changes in v4: - fixed some style issues - fixed GPL license version - added hwmon voltage monitoring slave driver Changes in v3: - deleted i2c_smbus wrapper functions and use native one - some cosmentics and variable renaming to be more clear - renamed "leave production" mode to "exit production mode" Changes in v2: - changed i2c_smbus_read wrapper function to return both, value and error. - moved "leave production mode" from Watchdog driver to mfd core. - fixed some return values in the watchdog driver to return the original error value instead of -EIO. Andreas Werner (4): drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver Documentation/hwmon/menf21bmc| 49 + drivers/hwmon/Kconfig| 7 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/menf21bmc_hwmon.c | 230 +++ drivers/leds/Kconfig | 6 + drivers/leds/Makefile| 1 + drivers/leds/leds-menf21bmc.c| 131 ++ drivers/mfd/Kconfig | 12 ++ drivers/mfd/Makefile | 1 + drivers/mfd/menf21bmc.c | 132 ++ drivers/watchdog/Kconfig | 7 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/menf21bmc_wdt.c | 203 ++ 13 files changed, 781 insertions(+) create mode 100644 Documentation/hwmon/menf21bmc create mode 100644 drivers/hwmon/menf21bmc_hwmon.c create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wdt.c -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
Added driver to support the 14F021P00 BMC Hardware Monitoring.
The BMC is a Board Management Controller including monitoring of the
board voltages.
Signed-off-by: Andreas Werner
---
Documentation/hwmon/menf21bmc | 49 +
drivers/hwmon/Kconfig | 7 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/menf21bmc_hwmon.c | 230
4 files changed, 287 insertions(+)
create mode 100644 Documentation/hwmon/menf21bmc
create mode 100644 drivers/hwmon/menf21bmc_hwmon.c
diff --git a/Documentation/hwmon/menf21bmc b/Documentation/hwmon/menf21bmc
new file mode 100644
index 000..22b6840
--- /dev/null
+++ b/Documentation/hwmon/menf21bmc
@@ -0,0 +1,49 @@
+Kernel driver menf21bmc_hwmon
+=
+
+Supported chips:
+ * MEN 14F021P00
+ Prefix: 'menf21bmc_hwmon'
+ Adresses scanned: -
+
+Author: Andreas Werner
+
+Description
+---
+
+The menf21bmc is a Board Management Controller (BMC) which provides an I2C
+interface to the host to access the features implemented in the BMC.
+
+This driver gives access to the voltage monitoring feature of the main
+voltages of the board.
+The voltage sensors are connected to the ADC inputs of the BMC which is
+a PIC16F917 Mikrocontroller.
+
+Usage Notes
+---
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+
+Sysfs entries
+-
+
+The following attributes are supported. All attributes are read only
+The Limits are read once by the driver.
+
+in0_input +3.3V input voltage
+in1_input +5.0V input voltage
+in2_input +12.0V input voltage
+in3_input +5V Standby input voltage
+in4_input VBAT (on board battery)
+
+in[0-4]_minMinimum voltage limit
+in[0-4]_maxMaximum voltage limit
+
+in0_label "MON_3_3V"
+in1_label "MON_5V"
+in2_label "MON_12V"
+in3_label "5V_STANDBY"
+in4_label "VBAT"
+
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 37908ff..db3a6eb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -828,6 +828,13 @@ config SENSORS_MCP3021
This driver can also be built as a module. If so, the module
will be called mcp3021.
+config SENSORS_MENF21BMC_HWMON
+ tristate "MEN 14F021P00 BMC Hardware Monitoring"
+ depends on MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC
+ hardware monitoring.
+
config SENSORS_ADCXX
tristate "National Semiconductor ADCxxxSxxx"
depends on SPI_MASTER
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 1362382..56ab872 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
+obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o
obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
diff --git a/drivers/hwmon/menf21bmc_hwmon.c b/drivers/hwmon/menf21bmc_hwmon.c
new file mode 100644
index 000..2eaec6a
--- /dev/null
+++ b/drivers/hwmon/menf21bmc_hwmon.c
@@ -0,0 +1,230 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) hwmon driver.
+ *
+ * This is the core hwmon driver of the MEN 14F021P00 BMC.
+ * The BMC monitors the board voltages which can be access with this
+ * driver through sysfs.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "menf21bmc_hwmon"
+
+#define BMC_VOLT_COUNT 5
+#define MENF21BMC_V33 0
+#define MENF21BMC_V5 1
+#define MENF21BMC_V12 2
+#define MENF21BMC_V5_SB3
+#define MENF21BMC_VBAT 4
+
+#define IDX_TO_VOLT_MIN_CMD(idx) (0x40 + idx)
+#define IDX_TO_VOLT_MAX_CMD(idx) (0x50 + idx)
+#define IDX_TO_VOLT_INP_CMD(idx) (0x60 + idx)
+
+struct menf21bmc_hwmon {
+ char valid;
+ struct i2c_client *i2c_client;
+ unsigned long last_update;
+ u16 in_val[BMC_VOLT_COUNT];
+ u16 in_min[BMC_VOLT_COUNT];
+ u16 in_max[BMC_VOLT_COUNT];
+};
+
+static const char *const input_names[] = {
+ [MENF21BMC_V33] = "MON_3_3V",
+ [MENF21BMC_V5] = "MON_5V",
+ [MENF21BMC_V12] = "MON_12V",
+
[PATCH v5 3/4] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controller including four LEDs which
can be switched on and off.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-menf21bmc.c | 131 ++
3 files changed, 138 insertions(+)
create mode 100644 drivers/leds/leds-menf21bmc.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 27cf0cd..d38ff3f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -458,6 +458,12 @@ config LEDS_OT200
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
+config LEDS_MENF21BMC
+ tristate "LED support for the MEN 14F021P00 BMC"
+ depends on LEDS_CLASS && MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC LEDs.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3c03666..cadc433 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
new file mode 100644
index 000..4621f72
--- /dev/null
+++ b/drivers/leds/leds-menf21bmc.c
@@ -0,0 +1,131 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
+ *
+ * This is the core LED driver of the MEN 14F021P00 BMC.
+ * There are four LEDs available which can be switched on and off.
+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_LED_GET_SET0xA0
+#define BMC_BIT_LED_STATUS BIT(0)
+#define BMC_BIT_LED_HOTSWAPBIT(1)
+#define BMC_BIT_LED_USER1 BIT(2)
+#define BMC_BIT_LED_USER2 BIT(3)
+
+struct menf21bmc_led {
+ struct led_classdev cdev;
+ u8 led_bit;
+ const char *name;
+ struct i2c_client *i2c_client;
+};
+
+static struct menf21bmc_led leds[] = {
+ {
+ .name = "menf21bmc:led_status",
+ .led_bit = BMC_BIT_LED_STATUS,
+ },
+ {
+ .name = "menf21bmc:led_hotswap",
+ .led_bit = BMC_BIT_LED_HOTSWAP,
+ },
+ {
+ .name = "menf21bmc:led_user1",
+ .led_bit = BMC_BIT_LED_USER1,
+ },
+ {
+ .name = "menf21bmc:led_user2",
+ .led_bit = BMC_BIT_LED_USER2,
+ }
+};
+
+static DEFINE_MUTEX(led_lock);
+
+static void
+menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ int led_val;
+ struct menf21bmc_led *led = container_of(led_cdev,
+ struct menf21bmc_led, cdev);
+
+ mutex_lock(&led_lock);
+ led_val = i2c_smbus_read_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET);
+ if (led_val < 0)
+ goto err_out;
+
+ if (value == LED_OFF)
+ led_val &= ~led->led_bit;
+ else
+ led_val |= led->led_bit;
+
+ i2c_smbus_write_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET, led_val);
+err_out:
+ mutex_unlock(&led_lock);
+}
+
+static int menf21bmc_led_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct i2c_client *i2c_client = to_i2c_client(pdev->dev.parent);
+
+ for (i = 0; i < ARRAY_SIZE(leds); i++) {
+ leds[i].cdev.name = leds[i].name;
+ leds[i].cdev.brightness_set = menf21bmc_led_set;
+ leds[i].i2c_client = i2c_client;
+ ret = led_classdev_register(&pdev->dev, &leds[i].cdev);
+ if (ret < 0)
+ goto err_free_leds;
+ }
+ dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");
+
+ return 0;
+
+err_free_leds:
+ dev_err(&pdev->dev, "failed to register LED device\n");
+
+ for (i = i - 1; i >= 0; i--)
+
[PATCH v5 2/4] drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
Signed-off-by: Andreas Werner
Reviewed-by: Guenter Roeck
---
drivers/watchdog/Kconfig | 7 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/menf21bmc_wdt.c | 203 +++
3 files changed, 211 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..f96431d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 468c320..de17014 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
diff --git a/drivers/watchdog/menf21bmc_wdt.c b/drivers/watchdog/menf21bmc_wdt.c
new file mode 100644
index 000..604824d
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wdt.c
@@ -0,0 +1,203 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wdt"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wdt {
+ struct watchdog_device wdt;
+ struct i2c_client *i2c_client;
+};
+
+static int menf21bmc_wdt_set_bootstatus(struct menf21bmc_wdt *data)
+{
+ int rst_rsn;
+
+ rst_rsn = i2c_smbus_read_byte_data(data->i2c_client, BMC_CMD_RST_RSN);
+ if (rst_rsn < 0)
+ return rst_rsn;
+
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_start(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_ON);
+}
+
+static int menf21bmc_wdt_stop(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte_data(drv_data->i2c_client,
+ BMC_CMD_WD_OFF, BMC_WD_OFF_VAL);
+}
+
+static int
+menf21bmc_wdt_settimeout(struct watchdog_device *wdt, unsigned int timeout)
+{
+ int ret;
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ /*
+* BMC Watchdog does have a resolution of 100ms.
+* Watchdog API defines the timeout in seconds, so we have to
+* multiply the value.
+*/
+ ret = i2c_smbus_write_word_data(drv_data->i2c_client,
+ BMC_CMD_WD_TIME, timeout * 10);
+ if (ret < 0)
+ return ret;
+
+ wdt->timeout = timeout;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_ping(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_TRIG);
+}
+
+static const struct watchdog_info menf21bmc_wdt
[PATCH v5 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner
Acked-by: Lee Jones
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
3 files changed, 145 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..6a9f101 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED, HWMON and WDT.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..37bf336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..a6eb03f
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,132 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_WDT_EXIT_PROD 0x18
+#define BMC_CMD_WDT_PROD_STAT 0x19
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+
+static struct mfd_cell menf21bmc_cell[] = {
+ { .name = "menf21bmc_wdt", },
+ { .name = "menf21bmc_led", },
+ { .name = "menf21bmc_hwmon", }
+};
+
+static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
+ if (val < 0)
+ return val;
+
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and exit the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(&client->dev,
+ "BMC in production mode. Exit production mode\n");
+
+ ret = i2c_smbus_write_byte(client, BMC_CMD_WDT_EXIT_PROD);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+menf21bmc_probe(struct i2c_client *client, const struct i2c_device_id *ids)
+{
+ int ret;
+ int rev_major, rev_minor, rev_main;
+
+ ret = i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BYTE);
+ if (!ret)
+ return -ENODEV;
+
+ rev_major = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAJOR);
+ if (rev_major < 0) {
+ dev_err(&client->dev, "failed to get BMC major revision\n");
+ return rev_major;
+ }
+
+ rev_minor = i2c_smbus_read_word_data(client, BMC_CMD_REV_MINOR);
+ if (rev_minor < 0) {
+ dev_err(&client->dev, "failed to get BMC minor revision\n");
+ return rev_minor;
+ }
+
+ rev_main = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAIN);
+ if
