* Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: Sekhar Nori @ 2017-01-12 7:39 UTC (permalink / raw)
To: David Lechner
Cc: Kevin Hilman, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1dd57ac3-554f-7d66-97b0-b76c3ddc7854@lechnology.com>
On Wednesday 11 January 2017 09:55 PM, David Lechner wrote:
>>> +&spi0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> +
>>> + flash@0 {
>>> + compatible = "n25q128a13", "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <50000000>;
>>> + ti,spi-wdelay = <8>;
>>> +
>>> + /* Partitions are based on the official firmware from LEGO */
>>> + partitions {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + partition@0 {
>>> + label = "U-Boot";
>>> + reg = <0 0x40000>;
>>> + };
>>> +
>>> + partition@40000 {
>>> + label = "U-Boot Env";
>>> + reg = <0x40000 0x10000>;
>>> + };
>>> +
>>> + partition@50000 {
>>> + label = "Kernel";
>>> + reg = <0x50000 0x200000>;
>>> + };
>>> +
>>> + partition@250000 {
>>> + label = "Filesystem";
>>> + reg = <0x250000 0xa50000>;
>>> + };
>>> +
>>> + partition@cb0000 {
>>> + label = "Storage";
>>> + reg = <0xcb0000 0x2f0000>;
>>> + };
>>> + };
>>> + };
>>> +
>>> + adc@3 {
>>> + compatible = "ti-ads7957";
>>
>> So looks like this works because of_register_spi_device() sets up
>> modalias of spi device from compatible string. I am fine with it, just
>> highlighting it here to make sure this is acceptable practice. I did not
>> really find any precedence for using SPI device name as compatible
>> property in existing DTS files.
>
> Indeed. It looks like this sort of "trivial" device binding is just used
> for i2c devices. I will submit some patches to add proper device tree
> bindings and change this to "ti,ads7957".
Alright, if you are going to do that, then I suggest you respin this
patch with the adc node dropped for now. That way we can ensure basic
board support in v4.11. If dependencies pan out, the adc can go in too
as a separate patch.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH linux v2 2/6] hwmon: occ: Add sysfs interface
From: kbuild test robot @ 2017-01-12 7:39 UTC (permalink / raw)
To: eajames.ibm
Cc: kbuild-all, linux, devicetree, jdelvare, corbet, linux-doc,
linux-hwmon, linux-i2c, linux-kernel, mark.rutland, robh+dt, wsa,
andrew, joel, benh, Edward A. James
In-Reply-To: <1484158237-10014-3-git-send-email-eajames.ibm@gmail.com>
Hi Edward,
[auto build test WARNING on hwmon/hwmon-next]
[also build test WARNING on v4.10-rc3 next-20170111]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/eajames-ibm-gmail-com/hwmon-Add-core-On-Chip-Controller-support-for-POWER-CPUs/20170112-150440
base: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next
coccinelle warnings: (new ones prefixed by >>)
>> drivers/hwmon/occ/occ_sysfs.c:265:9-16: WARNING: ERR_CAST can be used with hwmon -> dev
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] hwmon: occ: fix err_cast.cocci warnings
From: kbuild test robot @ 2017-01-12 7:39 UTC (permalink / raw)
To: eajames.ibm
Cc: kbuild-all, linux, devicetree, jdelvare, corbet, linux-doc,
linux-hwmon, linux-i2c, linux-kernel, mark.rutland, robh+dt, wsa,
andrew, joel, benh, Edward A. James
In-Reply-To: <1484158237-10014-3-git-send-email-eajames.ibm@gmail.com>
drivers/hwmon/occ/occ_sysfs.c:265:9-16: WARNING: ERR_CAST can be used with hwmon -> dev
Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))
Generated by: scripts/coccinelle/api/err_cast.cocci
CC: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
occ_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwmon/occ/occ_sysfs.c
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -262,7 +262,7 @@ struct occ_sysfs *occ_sysfs_start(struct
if (IS_ERR(hwmon->dev)) {
dev_err(dev, "cannot register hwmon device %s: %ld\n",
hwmon->hwmon_name, PTR_ERR(hwmon->dev));
- return ERR_PTR(PTR_ERR(hwmon->dev));
+ return ERR_CAST(hwmon->dev);
}
return hwmon;
^ permalink raw reply
* Isn't gen3 peripheral bus 32-bit?
From: Nikita Yushchenko @ 2017-01-12 7:42 UTC (permalink / raw)
To: linux-renesas-soc, devicetree; +Cc: Artemi Ivanov, Magnus Damm
Hi
R-Car GEN3 PCIe modules have 32-bit connect to internal AXI bus.
Could please somebody with lowlevel hardware knowledge answer, if this
is PCIe module limitation, or internal bus limitation.
Depending on that, different modification of renesas/r8a779[56].dtsi
files is needed: either
- wrap only pcie nodes into 32-bit sub-node of /soc, or
- turn entire /soc subtree to 32-bit.
Problem I'm trying to solve is related to DMA ranges handling.
Architecture code needs explicit information on DMA range
limitations caused by interconnect. See [1] thread for details.
Nikita
[1] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg10449.html
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Greg KH @ 2017-01-12 7:43 UTC (permalink / raw)
To: Cyril Bur
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
xow-hpIqsD4AKlfQT0dZR+AlfA, jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112002910.3650-4-cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jan 12, 2017 at 11:29:09AM +1100, Cyril Bur wrote:
> This driver exposes a reserved chunk of BMC ram to userspace as well as
> an ioctl interface to control the BMC<->HOST mapping of the LPC bus.
> This allows for a communication channel between the BMC and the host
Why not make this a UIO driver? Why does it have to be a character
device?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Greg KH @ 2017-01-12 7:47 UTC (permalink / raw)
To: Cyril Bur
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
xow-hpIqsD4AKlfQT0dZR+AlfA, jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112002910.3650-4-cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jan 12, 2017 at 11:29:09AM +1100, Cyril Bur wrote:
> +static ssize_t lpc_ctrl_read(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + if (!access_ok(VERIFY_WRITE, buf, count))
> + return -EFAULT;
> +
> + return -EPERM;
> +}
> +
> +static ssize_t lpc_ctrl_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + if (!access_ok(VERIFY_READ, buf, count))
> + return -EFAULT;
> +
> + return -EPERM;
> +}
Those functions don't actually do anything, so why even include them?
And don't call access_ok(), it's racy and no driver should ever do that.
> +static long lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
> + unsigned long param)
> +{
> + long rc;
> + struct lpc_mapping map;
> + struct lpc_ctrl *lpc_ctrl = file_lpc_ctrl(file);
> + void __user *p = (void __user *)param;
> +
> + switch (cmd) {
> + case LPC_CTRL_IOCTL_SIZE:
> + return copy_to_user(p, &lpc_ctrl->size,
> + sizeof(lpc_ctrl->size)) ? -EFAULT : 0;
> + case LPC_CTRL_IOCTL_MAP:
> + if (copy_from_user(&map, p, sizeof(map)))
> + return -EFAULT;
> +
> +
> + /*
> + * The top half of HICR7 is the MSB of the BMC address of the
> + * mapping.
> + * The bottom half of HICR7 is the MSB of the HOST LPC
> + * firmware space address of the mapping.
> + *
> + * The 1 bits in the top of half of HICR8 represent the bits
> + * (in the requested address) that should be ignored and
> + * replaced with those from the top half of HICR7.
> + * The 1 bits in the bottom half of HICR8 represent the bits
> + * (in the requested address) that should be kept and pass
> + * into the BMC address space.
> + */
> +
> + rc = regmap_write(lpc_ctrl->regmap, HICR7,
> + (lpc_ctrl->base | (map.hostaddr >> 16)));
> + if (rc)
> + return rc;
> +
> + rc = regmap_write(lpc_ctrl->regmap, HICR8,
> + (~(map.size - 1)) | ((map.size >> 16) - 1));
Look Ma, a kernel exploit!
{sigh}
Your assignment is to go find a whiteboard/blackboard/whatever and write
on it 100 times:
All input is evil.
I want to see the picture of that before you send any more kernel patches.
> +static int lpc_ctrl_release(struct inode *inode, struct file *file)
> +{
> + atomic_dec(&lpc_ctrl_open_count);
Totally unneeded and unnecessary, why do you care?
Again, use UIO, it will save you from yourself...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/3] Adding DT support for TI HECC module
From: Yegor Yefremov @ 2017-01-12 7:59 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Andrey Skvortsov, hs-ynQEQJNshbs, Marc Kleine-Budde
In-Reply-To: <20170112004757.GZ2630-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Thu, Jan 12, 2017 at 1:47 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> [170111 13:52]:
>> On Wed, Jan 11, 2017 at 3:05 PM, <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> > From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> >
>> > This is an attempt to revive DT support for TI HECC that was started in 2015.
>> >
>> > I haven't changed much because not all questions could be fully answered:
>> >
>> > * Should HECC use "am3505" as compatible?
>>
>> I mean "ti,am3505-hecc"
>
> Yeah it should use the device name for the driver.
>
>> > * What should be done to the offsets (ti,scc-ram-offset, ti,hecc-ram-offset, ti,mbx-offset)?
>
> The devicetree maintainers need to ack the binding doc. Maybe
> send that as a first patch?
The question is whether to place these settings into dtsi (as it was
done in the original patch) or in the driver itself.
Yegor
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 1/1] iio: adc: tlc4541: add support for TI tlc4541 adc
From: Phil Reid @ 2017-01-12 8:17 UTC (permalink / raw)
To: Peter Meerwald-Stadler
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <86fa08f8-8c4f-8ca6-5880-02d4df937011-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On 12/01/2017 11:51, Phil Reid wrote:
> On 11/01/2017 17:17, Peter Meerwald-Stadler wrote:
>> On Wed, 11 Jan 2017, Phil Reid wrote:
>>
>>> Oops, title should be PATCH V2.
>>>
>>> On 11/01/2017 14:51, Phil Reid wrote:
>>>> This adds TI's tlc4541 16-bit ADC driver. Which is a single channel
>>>> ADC. Supports raw and trigger buffer access.
>>>> Also supports the tlc3541 14-bit device, which has not been tested.
>>>> Implementation of the tlc3541 is fairly straight forward thou.
>>
>> comments below
>>
>>>
>>>> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
>>>> ---
>>>>
>>>> Notes:
>>>> Changes from v1:
>>>> - Add tlc3541 support and chan spec.
>>>> - remove fields that where already 0 from TLC4541_V_CHAN macro
>>>> - Increase rx_buf size in tlc4541_state to avoid copy in
>>>> tlc4541_trigger_handle
>>>> - Remove erroneous be16_to_cpu in tlc4541_trigger_handle
>>>> - Docs/binding: spi -> SPI & add ti,tlc3541
>>>>
>>>> I haven't add Rob's Ack due to adding a new compatible string.
>>>>
>>>> I tried to ".index = 1" from the spec as suggested by Peter, but that
>>>> didn't
>>>> seem to work. Perhaps remove of .channel was the intended target.
>>
>> the only between index = 0/1 should be that the channel is called
>> in_voltage0_raw vs in_voltage_raw in sysfs -- maybe there is an issue in
>> iio_readdev?
>>
>
> Did a little more testing and the problem looks to be in libiio.
>
>
> Here's the output from iio and list of sysfs files when "indexed = 1"
> iio:device8: tlc4541 (buffer capable)
> 2 channels found:
> voltage0: (input, index: 0, format: be:U16/16>>0)
> 2 channel-specific attributes found:
> attr 0: raw value: 174
> attr 1: scale value: 0.076293945
> timestamp: (input, index: 1, format: le:S64/64>>0)
> 1 device-specific attributes found:
> attr 0: current_timestamp_clock value: realtime
>
> root@cyclone5:~# ls /sys/bus/iio/devices/iio\:device8/*
> /sys/bus/iio/devices/iio:device8/current_timestamp_clock /sys/bus/iio/devices/iio:device8/in_voltage_scale
> /sys/bus/iio/devices/iio:device8/dev /sys/bus/iio/devices/iio:device8/name
> /sys/bus/iio/devices/iio:device8/in_voltage0_raw /sys/bus/iio/devices/iio:device8/uevent
>
> /sys/bus/iio/devices/iio:device8/buffer:
> enable length watermark
>
> /sys/bus/iio/devices/iio:device8/of_node:
> #io-channel-cells enable-dma name reg spi-max-frequency
> compatible linux,phandle phandle spi-cpha vref-supply
>
> /sys/bus/iio/devices/iio:device8/power:
> autosuspend_delay_ms control runtime_active_time runtime_status runtime_suspended_time
>
> /sys/bus/iio/devices/iio:device8/scan_elements:
> in_timestamp_en in_timestamp_index in_timestamp_type in_voltage0_en in_voltage0_index in_voltage0_type
>
> /sys/bus/iio/devices/iio:device8/subsystem:
> devices drivers drivers_autoprobe drivers_probe uevent
>
> /sys/bus/iio/devices/iio:device8/trigger:
> current_trigger
>
> And the same when "indexed = 0"
>
> iio:device8: tlc4541 (buffer capable)
> 2 channels found:
> voltage: (input)
> 2 channel-specific attributes found:
> attr 0: raw value: 173
> attr 1: scale value: 0.076293945
> timestamp: (input, index: 1, format: le:S64/64>>0)
> 1 device-specific attributes found:
> attr 0: current_timestamp_clock value: realtime
>
> root@cyclone5:~# ls /sys/bus/iio/devices/iio\:device8/*
> /sys/bus/iio/devices/iio:device8/current_timestamp_clock /sys/bus/iio/devices/iio:device8/in_voltage_scale
> /sys/bus/iio/devices/iio:device8/dev /sys/bus/iio/devices/iio:device8/name
> /sys/bus/iio/devices/iio:device8/in_voltage_raw /sys/bus/iio/devices/iio:device8/uevent
>
> /sys/bus/iio/devices/iio:device8/buffer:
> enable length watermark
>
> /sys/bus/iio/devices/iio:device8/of_node:
> #io-channel-cells enable-dma name reg spi-max-frequency
> compatible linux,phandle phandle spi-cpha vref-supply
>
> /sys/bus/iio/devices/iio:device8/power:
> autosuspend_delay_ms control runtime_active_time runtime_status runtime_suspended_time
>
> /sys/bus/iio/devices/iio:device8/scan_elements:
> in_timestamp_en in_timestamp_index in_timestamp_type in_voltage_en in_voltage_index in_voltage_type
>
> /sys/bus/iio/devices/iio:device8/subsystem:
> devices drivers drivers_autoprobe drivers_probe uevent
>
> /sys/bus/iio/devices/iio:device8/trigger:
> current_trigger
>
> The iio scope application also does not allow the tlc4541 channel to be selected when "indexed = 0".
>
> I've had a bit of play with some test apps but it looks like to me libiio is not parsing the
> scan_elements folder correctly when the channels are not indexed.
> Haven't located exactly where as yet.
>
> So is the correct path here to fix libiio?
>
> I'm using libiio from git build a few weeks ago, I'll try updating to see if it fixes anything.
> Last commit was:
> 9838779 - Paul Cercueil , 3 weeks ago : Local backend: Return scan result even if 0 devices
>
I've made a change in libiio that seems to fix this but cause other problems.
In libiio local.c in add_attr_or_channel_helper
Setting strict to false in the call is_channel seems to result in iio_info and iio_readdev
behaving the same for both the indexed and non indexed config of tlc4541.
root@cyclone5:~# mkdir /sys/kernel/config/iio/triggers/hrtimer/hr1
root@cyclone5:~# iio_readdev -t hr1 -s 10 -b 10 tlc4541 | hexdump
WARNING: High-speed mode not enabled
0000000 b400 0000 0000 0000 9214 852b f2cc 1498
0000010 a900 00ff 0000 0000 a860 85c3 f2cc 1498
0000020 a600 0000 0000 0000 2f54 865c f2cc 1498
0000030 a900 00ff 0000 0000 ad74 86f4 f2cc 1498
0000040 a700 0000 0000 0000 405c 878d f2cc 1498
0000050 ab00 0000 0000 0000 dbf0 8825 f2cc 1498
0000060 aa00 0000 0000 0000 6b90 88be f2cc 1498
0000070 aa00 00ff 0000 0000 16f6 8957 f2cc 1498
0000080 aa00 0000 0000 0000 a1c8 89ef f2cc 1498
0000090 a900 0000 0000 0000 30d2 8a88 f2cc 1498
00000a0
root@cyclone5:~# ls /sys/bus/iio/devices/iio\:device8/ -la
drwxr-xr-x 6 root root 0 Nov 24 04:41 .
drwxr-xr-x 5 root root 0 Nov 24 04:41 ..
drwxr-xr-x 2 root root 0 Jan 12 06:04 buffer
-rw-r--r-- 1 root root 4096 Jan 12 06:04 current_timestamp_clock
-r--r--r-- 1 root root 4096 Jan 12 06:04 dev
-rw-r--r-- 1 root root 4096 Jan 12 06:04 in_voltage_raw
-rw-r--r-- 1 root root 4096 Jan 12 06:04 in_voltage_scale
-r--r--r-- 1 root root 4096 Jan 12 06:04 name
lrwxrwxrwx 1 root root 0 Jan 12 06:04 of_node ->
../../../../../../../../../../../firmware/devicetree/base/soc/i2c@ffc05000/nxp,pca9540@70/i2c@1/sc18is603@0x29/tlc4541@0
drwxr-xr-x 2 root root 0 Jan 12 06:04 power
drwxr-xr-x 2 root root 0 Jan 12 06:04 scan_elements
lrwxrwxrwx 1 root root 0 Jan 12 06:04 subsystem -> ../../../../../../../../../../../bus/iio
drwxr-xr-x 2 root root 0 Jan 12 06:04 trigger
-rw-r--r-- 1 root root 4096 Nov 24 04:41 uevent
And iio_info now shows the format
iio:device8: tlc4541 (buffer capable)
2 channels found:
voltage: (input, index: 0, format: be:U16/16>>0)
2 channel-specific attributes found:
attr 0: raw value: 185
attr 1: scale value: 0.076293945
timestamp: (input, index: 1, format: le:S64/64>>0)
1 device-specific attributes found:
attr 0: current_timestamp_clock value: realtime
This call was added by Lars-Peter on 26 Jan 2016.
With the intention of detecting channels with index.
However it does seem to break shared attributes on other devices where the channel
don't have scan elements.
Possibly it has something to do with a combination of their being a scan element and
being non indexed.
Any suggestion appreciated.
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-12 8:23 UTC (permalink / raw)
To: Andreas Färber,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Matthias Brugger, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Lai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3fecb422-8185-7ee0-c203-2bfdc4fd1393-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Hi Andreas,
had a look last night why the ethernet dtsi was not added and it
obviously was not added as we were waiting for the clk-mt2701 to be
merged. the ethernet dtsi will have phandles pointing at the clk nodes
which did not exist at the time. same is true for the PWM code.
i sat down last night and worked out what pending patches i still have
for mt7623 and out of the ~80 required to get v4.4 working i only need
around 10 for v4.10-rc1.
i started to rebase these patches last night and will have time to test
them tomorrow or early next week. as the pwrap node alone is around 200
lines of devicetree we need to figure out a way to add this to the dts
files without duplicating it. i'll try to post a series early next week
that we can then discuss and rebase your geekboard patches on.
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933
From: Geert Uytterhoeven @ 2017-01-12 8:25 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-clk, Michael Turquette, Stephen Boyd, Laurent Pinchart,
Rob Herring, devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170112010324.28068-1-marek.vasut@gmail.com>
Hi Marek,
On Thu, Jan 12, 2017 at 2:03 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips.
> These are I2C clock generators with optional clock source from
> either XTal or dedicated clock generator and, depending on the
> model, two or more clock outputs.
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Add mapping between the clock specifier and physical pins of the chip
> ---
> .../devicetree/bindings/clock/idt,versaclock5.txt | 65 ++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> new file mode 100644
> index 000000000000..87e9c47a89a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> @@ -0,0 +1,65 @@
> +==Mapping between clock specifier and physical pins==
> +
> +When referencing the provided clock in the DT using phandle and
> +clock specifier, the following mapping applies:
> +
> +5P49V5923:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT2
> +
> +5P49V5933:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT4
I'm a bit puzzled by the use of "OUT4".
According to the datasheets, both '5923 and '5933 have OUT1 and OUT2.
The '5933 datasheet has a single reference to OUT4 ("The OUT1 to OUT4 clock
outputs"), but that may be a copy and paste error from a datasheet for a part
with 4 outputs.
Apart from that:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] pinctrl: core: Fix regression caused by delayed work for hogs
From: Geert Uytterhoeven @ 2017-01-12 8:43 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Gary Bisson, Linux-Renesas
In-Reply-To: <20170111221334.26194-1-tony@atomide.com>
Hi Tony,
On Wed, Jan 11, 2017 at 11:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
> regression at least with sh-pfc that is also a GPIO controller as
> noted by Geert Uytterhoeven <geert@linux-m68k.org>.
>
> As the original pinctrl_register() has issues calling pin controller
> driver functions early before the controller has finished registering,
> we can't just revert commit df61b366af26. That would break the drivers
> using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
>
> So let's fix the issue with the following steps as a single patch:
>
> 1. Revert the late_init parts of commit df61b366af26.
>
> The late_init clearly won't work and we have to just give up
> on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
> GENERIC_PINMUX_FUNCTIONS.
>
> 2. Split pinctrl_register() into two parts
>
> By splitting pinctrl_register() into pinctrl_init_controller()
> and pinctrl_create_and_start() we have better control over when
> it's safe to call pinctrl_create().
>
> 3. Introduce a new pinctrl_register_and_init() function
>
> As suggested by Linus Walleij <linus.walleij@linaro.org>, we
> can just introduce a new function for the controllers that need
> pinctrl_create() called later.
>
> 4. Convert the four known problem cases to use new function
>
> Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
> to use the new function to fix the issues. The rest of the drivers
> can be converted later. Let's also update Documentation/pinctrl.txt
> accordingly because of the known issues with pinctrl_register().
>
> Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Gary Bisson <gary.bisson@boundarydevices.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Thanks, this fixes r8a7740/armadillo.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings
From: Simon Horman @ 2017-01-12 9:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Brandt, Ulf Hansson, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdW2Gx+t2uQUmYkQQoD7tB5us+CFXXpU1J3OW2Lzbsv77Q@mail.gmail.com>
On Thu, Jan 12, 2017 at 08:36:10AM +0100, Geert Uytterhoeven wrote:
> Hi Chris,
>
> On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt <chris.brandt@renesas.com> wrote:
> > Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> >
> > ---
> > v3:
> > * added list of how many interrupts each SOC has
> > v2:
> > * added interrupt description
>
> Thanks or the update!
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Marc Zyngier @ 2017-01-12 9:11 UTC (permalink / raw)
To: Ding Tianhong, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <6c33e4e9-6472-4738-aea2-55dcaab3a94f-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On 12/01/17 04:23, Ding Tianhong wrote:
> Hi Marc:
>
> How about this v7, if any suggestions very grateful.
It's been less than 5 days since you posted this. I'll get to it once I
finish reviewing all the other patches that are sitting in the queue
right before yours.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-12 9:13 UTC (permalink / raw)
To: Sebastian Hesselbarth, Linus Walleij, Gregory CLEMENT,
Thomas Petazzoni
Cc: Mark Rutland, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Kalyan Kinthada, Rob Herring, Laxman Dewangan,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <95cb4240-e77b-5eaa-1920-4d9e26028038@gmail.com>
On 12/01/17 09:56, Sebastian Hesselbarth wrote:
> On 01/11/2017 03:44 PM, Linus Walleij wrote:
>> On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
>> <chris.packham@alliedtelesis.co.nz> wrote:
>>
>>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>>
>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>> from Marvell.
>>>
>>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>
>> I am waiting for an ACK or comment from the maintainers on
>> this patch. Sebastian?
>
> Sorry for the ignorance.
>
> I don't have the patch to reply to inline, but:
>
> - In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
> - MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
> - MPP_MODE6 binding "gpio" and driver "gpo" differ.
> - MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
> - MPP_MODE19 binding mentiones "dev","rb" but driver does not.
> - MPP_MODE20 binding "gpio" and driver "gpo" differ.
> - MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
> - MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
> - remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.
>
> Most of it is cosmetic stuff, so if you fix it feel free to add my
>
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Hi Sebastian,
Hopefully I can get a v4 out with the above fixed soon.
One point on "gpio" vs "gpo" this one isn't a typo. Some of these pins
can be driven as outputs but can't be used as inputs. From a pinctrl
driver point of view there is no difference but I did want to convey
that from a system design point of view if you really need something to
be an input you shouldn't use one of these pins. This is also noted in
the datasheets so it doesn't necessarily need repeating. If you still
want me to use "gpio" in the code and binding I'm happy to do so.
^ permalink raw reply
* Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Maxime Ripard @ 2017-01-12 9:28 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20161209110419.28981-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote:
> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
> VBUS power supply for both max current and min voltage supplied. This
> series of patch adds the possibility to set these limits from sysfs.
>
> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
> the former can set the VBUS power supply max current to 100mA, unlike
> the latter. The AXP223 VBUS power supply driver used to probe on the
> AXP221 compatible. This series of patch introduces a new compatible for
> the AXP223 to be able to set the current max limit to 100mA.
>
> With that new compatible, boards having the AXP223 see their DT updated
> to use the VBUS power supply driver with the correct compatible.
>
> This series of patch also migrates from of_device_is_compatible function
> to the data field of of_device_id to identify the compatible used to
> probe. This improves the code readability.
>
> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
Applied all the DT patches. I also fixed all the prefixes. Please make
sure to look at what prefixes are used by a given subsystem next time.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/5] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
From: Balbir Singh @ 2017-01-12 9:42 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Daniel Lezcano, Michael Neuling,
Vaidyanathan Srinivasan, Shreyas B. Prabhu, Shilpasri G Bhat,
Stewart Smith, Balbir Singh, Oliver O'Halloran, linuxppc-dev,
linux-kernel, linux-pm, devicetree, Rob Herring, mark.rutland
In-Reply-To: <1484039224-5630-2-git-send-email-ego@linux.vnet.ibm.com>
On Tue, Jan 10, 2017 at 02:37:00PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Currently all the low-power idle states are expected to wake up
> at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ
> that puts the CPU to an idle state and never returns.
>
> On ISA v3.0, when the ESL and EC bits in the PSSCR are zero, the CPU
> is expected to wake up at the next instruction of the idle
> instruction.
>
> This patch adds a new macro named IDLE_STATE_ENTER_SEQ_NORET for the
> no-return variant and reuses the name IDLE_STATE_ENTER_SEQ
> for a variant that allows resuming operation at the instruction next
> to the idle-instruction.
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> No changes from v4
>
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
From: Balbir Singh @ 2017-01-12 9:47 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Stewart Smith, devicetree, Michael Neuling, linux-pm,
Shreyas B. Prabhu, Daniel Lezcano, Rafael J. Wysocki,
linux-kernel, Rob Herring, Paul Mackerras, Shilpasri G Bhat,
Oliver O'Halloran, mark.rutland, linuxppc-dev
In-Reply-To: <1484039224-5630-3-git-send-email-ego@linux.vnet.ibm.com>
On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Balbir pointed out that in idle_book3s.S and powernv/idle.c some
> functions and variables had power9 in their names while some others
> had arch300.
>
I would prefer power9 to arch300
Balbir Singh.
^ permalink raw reply
* Re: [PATCH linux v2 0/6] drivers: hwmon: Add On-Chip Controller driver
From: Wolfram Sang @ 2017-01-12 9:56 UTC (permalink / raw)
To: eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-0h96xk9xTtrk1uMJSBkQmQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
jdelvare-IBi9RG/b67k, corbet-T1hC0tSOHrs,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, andrew-zrmu5oMJ5Fs,
joel-U3u1mxZcP9KHXe+LvDLADg,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Edward A. James
In-Reply-To: <1484158237-10014-1-git-send-email-eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
> This patchset adds a hwmon driver to support the OCC (On-Chip Controller)
> on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management
> Controller). The OCC is an embedded processor that provides real time
> power and thermal monitoring.
Please don't cc the I2C list for I2C client drivers unless you have a
specific question about the I2C framework. Same as you usually don't add
the PCI list for every PCI (client) card.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 0/2] Use data tune for CMD line tune
From: Yong Mao @ 2017-01-12 10:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, devicetree, Nicolas Boichat, srv_heupstream,
Javier Martinez Canillas, Catalin Marinas, Will Deacon,
Douglas Anderson, yong mao, linux-kernel, Chunfeng Yun,
Rob Herring, linux-mediatek, linux-arm-kernel, Philipp Zabel,
Greg Kroah-Hartman, Matthias Brugger, linux-mmc, Eddie Huang,
Chaotian Jing
CMD response CRC error may cause cannot boot up
Change to use data tune for CMD line
Separate cmd internal delay for HS200/HS400 mode
yong mao (2):
mmc: mediatek: Use data tune for CMD line tune
mmc: dt-bindings: update Mediatek MMC bindings
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 6 +
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +
drivers/mmc/host/mtk-sd.c | 169 ++++++++++++++++++++---
3 files changed, 155 insertions(+), 23 deletions(-)
--
1.8.1.1
^ permalink raw reply
* [PATCH 1/2] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-12 10:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, devicetree, Nicolas Boichat, srv_heupstream,
Javier Martinez Canillas, Catalin Marinas, Will Deacon,
Douglas Anderson, yong mao, linux-kernel, Chunfeng Yun,
Rob Herring, linux-mediatek, linux-arm-kernel, Philipp Zabel,
Greg Kroah-Hartman, Matthias Brugger, linux-mmc, Eddie Huang,
Chaotian Jing
In-Reply-To: <1484215490-7494-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
CMD response CRC error may cause cannot boot up
Change to use data tune for CMD line
Separate cmd internal delay for HS200/HS400 mode
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +
drivers/mmc/host/mtk-sd.c | 169 +++++++++++++++++++++++----
2 files changed, 149 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 0ecaad4..29c3100 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -134,6 +134,9 @@
bus-width = <8>;
max-frequency = <50000000>;
cap-mmc-highspeed;
+ hs200-cmd-int-delay = <26>;
+ hs400-cmd-int-delay = <14>;
+ cmd-resp-sel = <0>; /* 0: rising, 1: falling */
vmmc-supply = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
non-removable;
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 80ba034..93eb395 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -75,6 +75,7 @@
#define MSDC_PATCH_BIT1 0xb4
#define MSDC_PAD_TUNE 0xec
#define PAD_DS_TUNE 0x188
+#define PAD_CMD_TUNE 0x18c
#define EMMC50_CFG0 0x208
/*--------------------------------------------------------------------------*/
@@ -210,12 +211,17 @@
#define MSDC_PATCH_BIT_SPCPUSH (0x1 << 29) /* RW */
#define MSDC_PATCH_BIT_DECRCTMO (0x1 << 30) /* RW */
-#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
-#define MSDC_PAD_TUNE_CMDRDLY (0x1f << 16) /* RW */
+#define MSDC_PAD_TUNE_DATWRDLY (0x1f << 0) /* RW */
+#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
+#define MSDC_PAD_TUNE_CMDRDLY (0x1f << 16) /* RW */
+#define MSDC_PAD_TUNE_CMDRRDLY (0x1f << 22) /* RW */
+#define MSDC_PAD_TUNE_CLKTDLY (0x1f << 27) /* RW */
-#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
-#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
-#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
+#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
+#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
+#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
+
+#define PAD_CMD_TUNE_RX_DLY3 (0x1f << 1) /* RW */
#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0) /* RW */
#define EMMC50_CFG_CRCSTS_EDGE (0x1 << 3) /* RW */
@@ -236,7 +242,9 @@
#define CMD_TIMEOUT (HZ/10 * 5) /* 100ms x5 */
#define DAT_TIMEOUT (HZ * 5) /* 1000ms x5 */
-#define PAD_DELAY_MAX 32 /* PAD delay cells */
+#define PAD_DELAY_MAX 32 /* PAD delay cells */
+#define ENOUGH_MARGIN_MIN 12 /* Enough Margin */
+#define PREFER_START_POS_MAX 4 /* Prefer start position */
/*--------------------------------------------------------------------------*/
/* Descriptor Structure */
/*--------------------------------------------------------------------------*/
@@ -284,12 +292,14 @@ struct msdc_save_para {
u32 patch_bit0;
u32 patch_bit1;
u32 pad_ds_tune;
+ u32 pad_cmd_tune;
u32 emmc50_cfg0;
};
struct msdc_tune_para {
u32 iocon;
u32 pad_tune;
+ u32 pad_cmd_tune;
};
struct msdc_delay_phase {
@@ -331,6 +341,9 @@ struct msdc_host {
unsigned char timing;
bool vqmmc_enabled;
u32 hs400_ds_delay;
+ u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
+ u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
+ u32 hs200_cmd_resp_sel; /* cmd response sample selection */
bool hs400_mode; /* current eMMC will run at hs400 mode */
struct msdc_save_para save_para; /* used when gate HCLK */
struct msdc_tune_para def_tune_para; /* default tune setting */
@@ -596,12 +609,21 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
*/
if (host->sclk <= 52000000) {
writel(host->def_tune_para.iocon, host->base + MSDC_IOCON);
- writel(host->def_tune_para.pad_tune, host->base + MSDC_PAD_TUNE);
+ writel(host->def_tune_para.pad_tune,
+ host->base + MSDC_PAD_TUNE);
} else {
- writel(host->saved_tune_para.iocon, host->base + MSDC_IOCON);
- writel(host->saved_tune_para.pad_tune, host->base + MSDC_PAD_TUNE);
+ writel(host->saved_tune_para.iocon,
+ host->base + MSDC_IOCON);
+ writel(host->saved_tune_para.pad_tune,
+ host->base + MSDC_PAD_TUNE);
+ writel(host->saved_tune_para.pad_cmd_tune,
+ host->base + PAD_CMD_TUNE);
}
+ if (timing == MMC_TIMING_MMC_HS400)
+ sdr_set_field(host->base + PAD_CMD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs400_cmd_int_delay);
dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
}
@@ -1302,7 +1324,8 @@ static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
len_final = len;
}
start += len ? len : 1;
- if (len >= 8 && start_final < 4)
+ if (len >= ENOUGH_MARGIN_MIN &&
+ start_final < PREFER_START_POS_MAX)
break;
}
@@ -1325,48 +1348,128 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
struct msdc_host *host = mmc_priv(mmc);
u32 rise_delay = 0, fall_delay = 0;
struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
+ struct msdc_delay_phase internal_delay_phase;
u8 final_delay, final_maxlen;
+ u32 internal_delay = 0;
int cmd_err;
- int i;
+ int i, j;
+ if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+ mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs200_cmd_int_delay);
sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
for (i = 0 ; i < PAD_DELAY_MAX; i++) {
sdr_set_field(host->base + MSDC_PAD_TUNE,
MSDC_PAD_TUNE_CMDRDLY, i);
- mmc_send_tuning(mmc, opcode, &cmd_err);
- if (!cmd_err)
- rise_delay |= (1 << i);
+ for (j = 0; j < 3; j++) {
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err) {
+ rise_delay |= (1 << i);
+ } else {
+ rise_delay &= ~(1 << i);
+ break;
+ }
+ }
}
final_rise_delay = get_best_delay(host, rise_delay);
/* if rising edge has enough margin, then do not scan falling edge */
- if (final_rise_delay.maxlen >= 10 ||
- (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
+ if (final_rise_delay.maxlen >= ENOUGH_MARGIN_MIN &&
+ final_rise_delay.start < PREFER_START_POS_MAX)
goto skip_fall;
sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
for (i = 0; i < PAD_DELAY_MAX; i++) {
sdr_set_field(host->base + MSDC_PAD_TUNE,
MSDC_PAD_TUNE_CMDRDLY, i);
- mmc_send_tuning(mmc, opcode, &cmd_err);
- if (!cmd_err)
- fall_delay |= (1 << i);
+ for (j = 0; j < 3; j++) {
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err) {
+ fall_delay |= (1 << i);
+ } else {
+ fall_delay &= ~(1 << i);
+ break;
+ };
+ }
}
final_fall_delay = get_best_delay(host, fall_delay);
skip_fall:
final_maxlen = max(final_rise_delay.maxlen, final_fall_delay.maxlen);
+ if (final_fall_delay.maxlen >= ENOUGH_MARGIN_MIN &&
+ final_fall_delay.start < PREFER_START_POS_MAX)
+ final_maxlen = final_fall_delay.maxlen;
if (final_maxlen == final_rise_delay.maxlen) {
sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
- sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRDLY,
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRDLY,
final_rise_delay.final_phase);
final_delay = final_rise_delay.final_phase;
} else {
sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
- sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRDLY,
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRDLY,
final_fall_delay.final_phase);
final_delay = final_fall_delay.final_phase;
}
+ if (host->hs200_cmd_int_delay)
+ goto skip_internal;
+ for (i = 0; i < PAD_DELAY_MAX; i++) {
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY, i);
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err)
+ internal_delay |= (1 << i);
+ }
+ dev_info(host->dev, "Final internal delay: 0x%x\n", internal_delay);
+ internal_delay_phase = get_best_delay(host, internal_delay);
+ sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRRDLY,
+ internal_delay_phase.final_phase);
+skip_internal:
+ dev_info(host->dev, "Final cmd pad delay: %x\n", final_delay);
+ return final_delay == 0xff ? -EIO : 0;
+}
+
+static int hs400_tune_response(struct mmc_host *mmc, u32 opcode)
+{
+ struct msdc_host *host = mmc_priv(mmc);
+ u32 cmd_delay = 0;
+ struct msdc_delay_phase final_cmd_delay = { 0,};
+ u8 final_delay;
+ int cmd_err;
+ int i, j;
+
+ /* select EMMC50 PAD CMD tune */
+ sdr_set_bits(host->base + PAD_CMD_TUNE, BIT(0));
+
+ if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+ mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs200_cmd_int_delay);
+ sdr_set_field(host->base + MSDC_IOCON, MSDC_IOCON_RSPL,
+ host->hs200_cmd_resp_sel);
+ for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+ sdr_set_field(host->base + PAD_CMD_TUNE,
+ PAD_CMD_TUNE_RX_DLY3, i);
+ for (j = 0; j < 3; j++) {
+ mmc_send_tuning(mmc, opcode, &cmd_err);
+ if (!cmd_err) {
+ cmd_delay |= (1 << i);
+ } else {
+ cmd_delay &= ~(1 << i);
+ break;
+ }
+ }
+ }
+ final_cmd_delay = get_best_delay(host, cmd_delay);
+ sdr_set_field(host->base + PAD_CMD_TUNE, PAD_CMD_TUNE_RX_DLY3,
+ final_cmd_delay.final_phase);
+ final_delay = final_cmd_delay.final_phase;
+
+ dev_info(host->dev, "Final cmd pad delay: %x\n", final_delay);
return final_delay == 0xff ? -EIO : 0;
}
@@ -1389,7 +1492,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
}
final_rise_delay = get_best_delay(host, rise_delay);
/* if rising edge has enough margin, then do not scan falling edge */
- if (final_rise_delay.maxlen >= 10 ||
+ if (final_rise_delay.maxlen >= ENOUGH_MARGIN_MIN ||
(final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
goto skip_fall;
@@ -1422,6 +1525,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
final_delay = final_fall_delay.final_phase;
}
+ dev_info(host->dev, "Final data pad delay: %x\n", final_delay);
return final_delay == 0xff ? -EIO : 0;
}
@@ -1430,10 +1534,13 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
struct msdc_host *host = mmc_priv(mmc);
int ret;
+ if (host->hs400_mode)
+ ret = hs400_tune_response(mmc, opcode);
+ else
ret = msdc_tune_response(mmc, opcode);
if (ret == -EIO) {
dev_err(host->dev, "Tune response fail!\n");
- return ret;
+ goto out;
}
if (host->hs400_mode == false) {
ret = msdc_tune_data(mmc, opcode);
@@ -1443,6 +1550,8 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
host->saved_tune_para.iocon = readl(host->base + MSDC_IOCON);
host->saved_tune_para.pad_tune = readl(host->base + MSDC_PAD_TUNE);
+ host->saved_tune_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
+out:
return ret;
}
@@ -1553,6 +1662,18 @@ static int msdc_drv_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
host->hs400_ds_delay);
+ if (!of_property_read_u32(pdev->dev.of_node, "hs200-cmd-int-delay",
+ &host->hs200_cmd_int_delay))
+ dev_dbg(&pdev->dev, "host->hs200-cmd-int-delay: %x\n",
+ host->hs200_cmd_int_delay);
+ if (!of_property_read_u32(pdev->dev.of_node, "hs400-cmd-int-delay",
+ &host->hs400_cmd_int_delay))
+ dev_dbg(&pdev->dev, "host->hs400-cmd-int-delay: %x\n",
+ host->hs400_cmd_int_delay);
+ if (!of_property_read_u32(pdev->dev.of_node, "cmd-resp-sel",
+ &host->hs200_cmd_resp_sel))
+ dev_dbg(&pdev->dev, "host->hs200_cmd-resp-sel: %x\n",
+ host->hs200_cmd_resp_sel);
host->dev = &pdev->dev;
host->mmc = mmc;
host->src_clk_freq = clk_get_rate(host->src_clk);
@@ -1663,6 +1784,7 @@ static void msdc_save_reg(struct msdc_host *host)
host->save_para.patch_bit0 = readl(host->base + MSDC_PATCH_BIT);
host->save_para.patch_bit1 = readl(host->base + MSDC_PATCH_BIT1);
host->save_para.pad_ds_tune = readl(host->base + PAD_DS_TUNE);
+ host->save_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
host->save_para.emmc50_cfg0 = readl(host->base + EMMC50_CFG0);
}
@@ -1675,6 +1797,7 @@ static void msdc_restore_reg(struct msdc_host *host)
writel(host->save_para.patch_bit0, host->base + MSDC_PATCH_BIT);
writel(host->save_para.patch_bit1, host->base + MSDC_PATCH_BIT1);
writel(host->save_para.pad_ds_tune, host->base + PAD_DS_TUNE);
+ writel(host->save_para.pad_cmd_tune, host->base + PAD_CMD_TUNE);
writel(host->save_para.emmc50_cfg0, host->base + EMMC50_CFG0);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] mmc: dt-bindings: update Mediatek MMC bindings
From: Yong Mao @ 2017-01-12 10:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Boichat,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Javier Martinez Canillas,
Catalin Marinas, Will Deacon, Douglas Anderson, yong mao,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunfeng Yun, Rob Herring,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Greg Kroah-Hartman, Matthias Brugger,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Eddie Huang, Chaotian Jing
In-Reply-To: <1484215490-7494-1-git-send-email-yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: yong mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Add description for hs200-cmd-int-delay
Add description for hs400-cmd-int-delay
Add description for cmd-resp-sel
Signed-off-by: Yong Mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 0120c7f..2dbb3b0 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -21,6 +21,9 @@ Optional properties:
- assigned-clocks: PLL of the source clock
- assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
- hs400-ds-delay: HS400 DS delay setting
+- hs200-cmd-int-delay: HS200 command internal delay setting
+- hs400-cmd-int-delay: HS400 command internal delay setting
+- cmd-resp-sel: command response sample selection
Examples:
mmc0: mmc@11230000 {
@@ -38,4 +41,7 @@ mmc0: mmc@11230000 {
assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
hs400-ds-delay = <0x14015>;
+ hs200-cmd-int-delay = <26>;
+ hs400-cmd-int-delay = <14>;
+ cmd-resp-sel = <0>; /* 0: rising, 1: falling */
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v5 3/5] cpuidle:powernv: Add helper function to populate powernv idle states.
From: Balbir Singh @ 2017-01-12 10:04 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Stewart Smith, devicetree, Michael Neuling, linux-pm,
Shreyas B. Prabhu, Daniel Lezcano, Rafael J. Wysocki,
linux-kernel, Rob Herring, Paul Mackerras, Shilpasri G Bhat,
Oliver O'Halloran, mark.rutland, linuxppc-dev
In-Reply-To: <1484039224-5630-4-git-send-email-ego@linux.vnet.ibm.com>
On Tue, Jan 10, 2017 at 02:37:02PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> In the current code for powernv_add_idle_states, there is a lot of code
> duplication while initializing an idle state in powernv_states table.
>
> Add an inline helper function to populate the powernv_states[] table
> for a given idle state. Invoke this for populating the "Nap",
> "Fastsleep" and the stop states in powernv_add_idle_states.
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> --
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] mmc: dt-bindings: update Mediatek MMC bindings
From: Ulf Hansson @ 2017-01-12 10:15 UTC (permalink / raw)
To: Yong Mao
Cc: Rob Herring, Mark Rutland, Chaotian Jing, Eddie Huang,
Chunfeng Yun, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-mediatek
In-Reply-To: <1484215490-7494-3-git-send-email-yong.mao@mediatek.com>
-trimmed cc list (future wise, I suggest you be more careful whom to
keep on cc/to)
On 12 January 2017 at 11:04, Yong Mao <yong.mao@mediatek.com> wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> Add description for hs200-cmd-int-delay
> Add description for hs400-cmd-int-delay
> Add description for cmd-resp-sel
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
The changes to DTS bindings should come prior the actual code change
using the bindings. Please make this patch 1 instead.
Otherwise this looks good to me.
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..2dbb3b0 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,9 @@ Optional properties:
> - assigned-clocks: PLL of the source clock
> - assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
> - hs400-ds-delay: HS400 DS delay setting
> +- hs200-cmd-int-delay: HS200 command internal delay setting
> +- hs400-cmd-int-delay: HS400 command internal delay setting
> +- cmd-resp-sel: command response sample selection
>
> Examples:
> mmc0: mmc@11230000 {
> @@ -38,4 +41,7 @@ mmc0: mmc@11230000 {
> assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
> assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
> hs400-ds-delay = <0x14015>;
> + hs200-cmd-int-delay = <26>;
> + hs400-cmd-int-delay = <14>;
> + cmd-resp-sel = <0>; /* 0: rising, 1: falling */
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Cyril Bur @ 2017-01-12 10:16 UTC (permalink / raw)
To: Greg KH
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
xow-hpIqsD4AKlfQT0dZR+AlfA, jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112074750.GB23943-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thu, 2017-01-12 at 08:47 +0100, Greg KH wrote:
> On Thu, Jan 12, 2017 at 11:29:09AM +1100, Cyril Bur wrote:
> > +static ssize_t lpc_ctrl_read(struct file *file, char __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + if (!access_ok(VERIFY_WRITE, buf, count))
> > + return -EFAULT;
> > +
> > + return -EPERM;
> > +}
> > +
> > +static ssize_t lpc_ctrl_write(struct file *file, const char __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + if (!access_ok(VERIFY_READ, buf, count))
> > + return -EFAULT;
> > +
> > + return -EPERM;
> > +}
>
Hello Greg,
> Those functions don't actually do anything, so why even include them?
>
Apologies, I should be more careful with what I send.
> And don't call access_ok(), it's racy and no driver should ever do that.
>
Oh, duly noted. I'll be sure to check out how and why. Perhaps it
would be wise that no driver actually do that, I'm quite sure I used
other drivers as examples of best practice.
> > +static long lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
> > + unsigned long param)
> > +{
> > + long rc;
> > + struct lpc_mapping map;
> > + struct lpc_ctrl *lpc_ctrl = file_lpc_ctrl(file);
> > + void __user *p = (void __user *)param;
> > +
> > + switch (cmd) {
> > + case LPC_CTRL_IOCTL_SIZE:
> > + return copy_to_user(p, &lpc_ctrl->size,
> > + sizeof(lpc_ctrl->size)) ? -EFAULT : 0;
> > + case LPC_CTRL_IOCTL_MAP:
> > + if (copy_from_user(&map, p, sizeof(map)))
> > + return -EFAULT;
> > +
> > +
> > + /*
> > + * The top half of HICR7 is the MSB of the BMC address of the
> > + * mapping.
> > + * The bottom half of HICR7 is the MSB of the HOST LPC
> > + * firmware space address of the mapping.
> > + *
> > + * The 1 bits in the top of half of HICR8 represent the bits
> > + * (in the requested address) that should be ignored and
> > + * replaced with those from the top half of HICR7.
> > + * The 1 bits in the bottom half of HICR8 represent the bits
> > + * (in the requested address) that should be kept and pass
> > + * into the BMC address space.
> > + */
> > +
> > + rc = regmap_write(lpc_ctrl->regmap, HICR7,
> > + (lpc_ctrl->base | (map.hostaddr >> 16)));
> > + if (rc)
> > + return rc;
> > +
> > + rc = regmap_write(lpc_ctrl->regmap, HICR8,
> > + (~(map.size - 1)) | ((map.size >> 16) - 1));
>
> Look Ma, a kernel exploit!
>
So 'evil' input here could allow the host to control the bmc,
personally I file that under 'stupid' input. Also, stupid but not
accidental, I don't believe one could accidentally come up with such
input, although you never know what silly things human beings sometimes
do. For what its worth, I'm not even sure that can happen but I'll
grant you the benifit of the doubt.
> {sigh}
>
> Your assignment is to go find a whiteboard/blackboard/whatever and write
> on it 100 times:
> All input is evil.
>
> I want to see the picture of that before you send any more kernel patches.
>
> > +static int lpc_ctrl_release(struct inode *inode, struct file *file)
> > +{
> > + atomic_dec(&lpc_ctrl_open_count);
>
> Totally unneeded and unnecessary, why do you care?
>
My aim here was to only have one process playing with the LPC mapping
registers at a time.
> Again, use UIO, it will save you from yourself...
>
Thank-you! This is the first I've heard of UIO and I'll investigate
furthur!
Sincerely,
Cyril
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 00/37] PCI: Support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2017-01-12 10:25 UTC (permalink / raw)
To: Bjorn Helgaas, Jingoo Han, Joao Pinto, Arnd Bergmann
Cc: linux-pci, linux-doc, linux-kernel, devicetree, linux-omap,
linux-arm-kernel, linux-samsung-soc, linuxppc-dev,
linux-arm-kernel, linux-arm-msm, nsekhar, kishon
The RFC series that was sent before this patch series can be found at [1].
The patches are split here so that it can be better reviewed.
This main purpose of this patch series is to
*) add PCI endpoint core layer
*) modifie designware/dra7xx driver to be configured in EP mode
*) add a PCI endpoint *test* function driver and corresponding host
driver
Major Improvements from RFC:
*) support multi-function devices (hw supported not virtual)
*) Access host side buffers
*) Raise MSI interrupts
*) Add user space program to use the host side PCI driver
*) Adapt all other users of designware to use the new design (only
compile tested. Since I have only dra7xx boards, the new design
has only been tested in dra7xx. I'd require the help of others
to test the platforms they have access to).
This patch series has been developed on top of 4.10-rc1, [2] & [3]
[1] -> https://lwn.net/Articles/700605/
[2] -> https://lkml.org/lkml/2016/12/28/34
[3] -> https://lkml.org/lkml/2017/1/11/238
I've also pushed the tree to
git://git.ti.com/linux-phy/linux-phy.git pci_ep_v1
Using PCI EPF Test:
ON THE EP SIDE:
***************
/* EP function is configured using configfs */
# mount -t configfs none /sys/kernel/config
/* PCI EP core layer creates "pci_ep" entry in configfs */
# cd /sys/kernel/config/pci_ep/
/*
* This is the 1st step in creating an endpoint function. This
* creates the endpoint device.
*/
# mkdir dev
/*
* dev has 2 entries. *epc* for binding a EPC device and *epf*
* is a directory containing all the functions of the endpoint
*/
# ls dev
epc epf
/*
* This creates the endpoint function device *instance*. The string
* before the .<num> suffix will identify the driver this
* EP function will bind to.
* Just pci_epf_test is also valid. The .<num> suffix is used
* if there are multiple PCI controllers and all of them wants
* to use the same function.
*/
# mkdir dev/epf/pci_epf_test.0
/*
* When the above command is given, the function device will
* also be bound to a function driver. To find the list of
* function drivers available in the system, use the following
* command. To create a new driver, the following can be referred
* drivers/pci/endpoint/functions/pci-epf-test.c
*/
# ls /sys/bus/pci-epf/drivers
pci_epf_test
/* Now configure the endpoint function */
/* These are the fields that can be configured */
# ls dev/epf/pci_epf_test.0/
baseclass_code function progif_code subsys_id
cache_line_size interrupt_pin revid subsys_vendor_id
deviceid msi_interrupts subclass_code vendorid
/* The function driver will populate these fields with default values */
# cat dev/epf/pci_epf_test.0/vendorid
0xffff
# cat dev/epf/pci_epf_test.0/interrupt_pin
0x0001
/* The user can configure any of these fields */
# echo 0x104c > dev/epf/pci_epf_test.0/vendorid
# echo 16 > dev/epf/pci_epf_test.0/msi_interrupts
/*
* Next is binding this function driver to the controller driver. In
* order to find the possible controller drivers that this function
* driver can be bound to, the following sysfs entry can be used
*/
# ls /sys/class/pci_epc/
51000000.pci
/* Now bind the function driver to the controller driver */
# echo "51000000.pcie_ep" > epc
[ 494.743487] dra7-pcie 51000000.pcie: no free inbound window
[ 494.749367] pci_epf_test pci_epf_test.0: failed to set BAR4
[ 494.755238] dra7-pcie 51000000.pcie: no free inbound window
[ 494.761451] pci_epf_test pci_epf_test.0: failed to set BAR5
/*
* the above error messages are due to non availability of free
* inbound windows. So the function drivers in dra7xx can use
* only 4 (BAR0..BAR3) BARs
*/
/****** PCI endpoint is configured ******/
ON THE HOST SIDE:
*****************
# ./pcitest.sh
BAR tests
BAR0: OKAY
BAR1: OKAY
BAR2: OKAY
BAR3: OKAY
BAR4: NOT OKAY
BAR5: NOT OKAY
Interrupt tests
LEGACY IRQ: NOT OKAY
MSI1: OKAY
MSI2: OKAY
MSI3: OKAY
MSI4: OKAY
MSI5: OKAY
MSI6: OKAY
MSI7: OKAY
MSI8: OKAY
MSI9: OKAY
MSI10: OKAY
MSI11: OKAY
MSI12: OKAY
MSI13: OKAY
MSI14: OKAY
MSI15: OKAY
MSI16: OKAY
MSI17: NOT OKAY
MSI18: NOT OKAY
MSI19: NOT OKAY
MSI20: NOT OKAY
MSI21: NOT OKAY
MSI22: NOT OKAY
MSI23: NOT OKAY
MSI24: NOT OKAY
MSI25: NOT OKAY
MSI26: NOT OKAY
MSI27: NOT OKAY
MSI28: NOT OKAY
MSI29: NOT OKAY
MSI30: NOT OKAY
MSI31: NOT OKAY
MSI32: NOT OKAY
Read Tests
READ ( 1 bytes): OKAY
READ ( 1024 bytes): OKAY
READ ( 1025 bytes): OKAY
READ (1024000 bytes): OKAY
READ (1024001 bytes): OKAY
Write Tests
WRITE ( 1 bytes): OKAY
WRITE ( 1024 bytes): OKAY
WRITE ( 1025 bytes): OKAY
WRITE (1024000 bytes): OKAY
WRITE (1024001 bytes): OKAY
Copy Tests
COPY ( 1 bytes): OKAY
COPY ( 1024 bytes): OKAY
COPY ( 1025 bytes): OKAY
COPY (1024000 bytes): OKAY
COPY (1024001 bytes): OKAY
Kishon Vijay Abraham I (37):
PCI: dwc: dra7xx: Group all host related setup in add_pcie_port
PCI: dwc: designware: Add new *ops* for cpu addr fixup
PCI: dwc: dra7xx: Populate cpu_addr_fixup ops
PCI: dwc: designware: Move the register defines to designware header
file
PCI: dwc: Add platform_set_drvdata
PCI: dwc: Rename cfg_read/cfg_write to read/write
PCI: dwc: designware: Get device pointer at the start of
dw_pcie_host_init
PCI: dwc: Split *struct pcie_port* into host only and core structures
PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc
PCI: dwc: designware: Fix style errors in pcie-designware.c
PCI: dwc: Split pcie-designware.c into host and core files
PCI: dwc: Create a new config symbol to enable pci dwc host
PCI: dwc: Remove dependency of designware to CONFIG_PCI
PCI: endpoint: Add EP core layer to enable EP controller and EP
functions
Documentation: PCI: Guide to use PCI Endpoint Core Layer
PCI: endpoint: Introduce configfs entry for configuring EP functions
Documentation: PCI: Guide to use pci endpoint configfs
Documentation: PCI: Add specification for the *pci test* function
device
PCI: endpoint: functions: Add an EP function to test PCI
Documentation: PCI: Add binding documentation for pci-test endpoint
function
PCI: dwc: Modify dbi accessors to take dbi_base as argument
PCI: dwc: Modify dbi accessors to access data of 4/2/1 bytes
PCI: dwc: Add *ops* to start and stop pcie link
PCI: dwc: designware: Add EP mode support
dt-bindings: PCI: Add dt bindings for pci designware EP mode
PCI: dwc: dra7xx: Facilitate wrapper and msi interrupts to be enabled
independently
PCI: dwc: dra7xx: Add EP mode support
dt-bindings: PCI: dra7xx: Add dt bindings for pci dra7xx EP mode
PCI: dwc: dra7xx: Workaround for errata id i870
dt-bindings: PCI: dra7xx: Add dt bindings to enable legacy mode
misc: Add host side pci driver for pci test function device
Documentation: misc-devices: Add Documentation for pci-endpoint-test
driver
tools: PCI: Add a userspace tool to test PCI endpoint
tools: PCI: Add sample test script to invoke pcitest
MAINTAINERS: add PCI EP maintainer
ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to
SW_WKUP
ARM: dts: DRA7: Add pcie1 dt node for EP mode
Documentation/PCI/00-INDEX | 8 +
.../PCI/endpoint/function/binding/pci-test.txt | 17 +
Documentation/PCI/endpoint/pci-endpoint-cfs.txt | 84 ++
Documentation/PCI/endpoint/pci-endpoint.txt | 190 +++++
Documentation/PCI/endpoint/pci-test-function.txt | 66 ++
.../devicetree/bindings/pci/designware-pcie.txt | 26 +-
Documentation/devicetree/bindings/pci/ti-pci.txt | 41 +-
Documentation/misc-devices/pci-endpoint-test.txt | 35 +
MAINTAINERS | 9 +
arch/arm/boot/dts/am572x-idk.dts | 7 +-
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 7 +-
arch/arm/boot/dts/dra7-evm.dts | 4 +
arch/arm/boot/dts/dra7.dtsi | 22 +-
arch/arm/boot/dts/dra72-evm-common.dtsi | 4 +
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
drivers/Makefile | 5 +
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/pci_endpoint_test.c | 533 ++++++++++++
drivers/pci/Kconfig | 1 +
drivers/pci/Makefile | 3 -
drivers/pci/dwc/Kconfig | 73 +-
drivers/pci/dwc/Makefile | 6 +-
drivers/pci/dwc/pci-dra7xx.c | 372 +++++++--
drivers/pci/dwc/pci-exynos.c | 83 +-
drivers/pci/dwc/pci-imx6.c | 142 ++--
drivers/pci/dwc/pci-keystone-dw.c | 91 +-
drivers/pci/dwc/pci-keystone.c | 56 +-
drivers/pci/dwc/pci-keystone.h | 4 +-
drivers/pci/dwc/pci-layerscape.c | 93 ++-
drivers/pci/dwc/pcie-armada8k.c | 92 ++-
drivers/pci/dwc/pcie-artpec6.c | 51 +-
drivers/pci/dwc/pcie-designware-ep.c | 342 ++++++++
drivers/pci/dwc/pcie-designware-host.c | 620 ++++++++++++++
drivers/pci/dwc/pcie-designware-plat.c | 29 +-
drivers/pci/dwc/pcie-designware.c | 868 ++++----------------
drivers/pci/dwc/pcie-designware.h | 254 +++++-
drivers/pci/dwc/pcie-hisi.c | 60 +-
drivers/pci/dwc/pcie-qcom.c | 72 +-
drivers/pci/dwc/pcie-spear13xx.c | 85 +-
drivers/pci/endpoint/Kconfig | 25 +
drivers/pci/endpoint/Makefile | 7 +
drivers/pci/endpoint/functions/Kconfig | 12 +
drivers/pci/endpoint/functions/Makefile | 5 +
drivers/pci/endpoint/functions/pci-epf-test.c | 513 ++++++++++++
drivers/pci/endpoint/pci-ep-cfs.c | 427 ++++++++++
drivers/pci/endpoint/pci-epc-core.c | 548 ++++++++++++
drivers/pci/endpoint/pci-epc-mem.c | 143 ++++
drivers/pci/endpoint/pci-epf-core.c | 347 ++++++++
include/linux/mod_devicetable.h | 10 +
include/linux/pci-epc.h | 141 ++++
include/linux/pci-epf.h | 160 ++++
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/pcitest.h | 19 +
tools/pci/pcitest.c | 186 +++++
tools/pci/pcitest.sh | 56 ++
56 files changed, 5880 insertions(+), 1185 deletions(-)
create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt
create mode 100644 Documentation/PCI/endpoint/pci-endpoint-cfs.txt
create mode 100644 Documentation/PCI/endpoint/pci-endpoint.txt
create mode 100644 Documentation/PCI/endpoint/pci-test-function.txt
create mode 100644 Documentation/misc-devices/pci-endpoint-test.txt
create mode 100644 drivers/misc/pci_endpoint_test.c
create mode 100644 drivers/pci/dwc/pcie-designware-ep.c
create mode 100644 drivers/pci/dwc/pcie-designware-host.c
create mode 100644 drivers/pci/endpoint/Kconfig
create mode 100644 drivers/pci/endpoint/Makefile
create mode 100644 drivers/pci/endpoint/functions/Kconfig
create mode 100644 drivers/pci/endpoint/functions/Makefile
create mode 100644 drivers/pci/endpoint/functions/pci-epf-test.c
create mode 100644 drivers/pci/endpoint/pci-ep-cfs.c
create mode 100644 drivers/pci/endpoint/pci-epc-core.c
create mode 100644 drivers/pci/endpoint/pci-epc-mem.c
create mode 100644 drivers/pci/endpoint/pci-epf-core.c
create mode 100644 include/linux/pci-epc.h
create mode 100644 include/linux/pci-epf.h
create mode 100644 include/uapi/linux/pcitest.h
create mode 100644 tools/pci/pcitest.c
create mode 100644 tools/pci/pcitest.sh
--
1.7.9.5
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox