Re: [PATCH (net.git) 0/3] stmmac: fix PTP support
On Wed, Oct 26, 2016 at 2:28 PM, Richard Cochran wrote: > On Wed, Oct 26, 2016 at 08:56:01AM +0200, Giuseppe Cavallaro wrote: >> This subset of patches aim to fix the PTP support >> for the stmmac and especially for 4.x chip series. >> While setting PTP on an ST box with 4.00a Ethernet >> core, the kernel panics due to a broken settings >> of the descriptors. The patches review the >> register configuration, the algo used for configuring >> the protocol, the way to get the timestamp inside >> the RX/TX descriptors and, in the end, the statistics >> displayed by ethtool. >> >> Giuseppe Cavallaro (3): >> stmmac: update the PTP header file >> stmmac: fix PTP support for GMAC4 >> stmmac: fix PTP type ethtool stats > > Acked-by: Richard Cochran Acked-by: Rayagond Kokatanur -- wwr Rayagond
Re: [PATCH (net.git) 2/3] stmmac: fix PTP support for GMAC4
On Wed, Nov 2, 2016 at 12:04 PM, Giuseppe CAVALLARO
wrote:
> Hello Rayagond
>
> if patches are ok, can we consider you Acked-by ?
Yes.
>
> Thx
> Peppe
>
>
> On 10/27/2016 12:51 PM, Rayagond Kokatanur wrote:
>>
>> On Thu, Oct 27, 2016 at 4:02 PM, Giuseppe CAVALLARO
>> wrote:
>>>
>>> Hello Rayagond !
>>>
>>> On 10/27/2016 12:25 PM, Rayagond Kokatanur wrote:
>
>
> +static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
>>
>> {
>> struct dma_desc *p = (struct dma_desc *)desc;
>> + int ret = -EINVAL;
>> +
>> + /* Get the status from normal w/b descriptor */
>> + if (likely(p->des3 & TDES3_RS1V)) {
>> + if (likely(p->des1 & RDES1_TIMESTAMP_AVAILABLE)) {
>> + int i = 0;
>> +
>> + /* Check if timestamp is OK from context
>> descriptor */
>> + do {
>> + ret = dwmac4_rx_check_timestamp(desc);
Here, "desc" is not pointing to next descriptor (ie context
descriptor). Driver should check the context descriptor.
>>>
>>>
>>>
>>> you are right and this is done by the caller: stmmac_get_rx_hwtstamp
>>
>>
>> Yes.
>>
>>>
>>> Cheers
>>> peppe
>>>
>>
>>
>>
>
--
wwr
Rayagond
[PATCH] clk: rockchip: fix some clocks' name to be more standard style
Fix aclk_emmcgrf to aclk_emmc_grf, and fix aclk_emmccore to be
aclk_emmc_core.
Signed-off-by: Jianqun Xu
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index 2c7cba7..b3df2c6 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -935,11 +935,11 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
RK3399_CLKGATE_CON(6), 13, GFLAGS),
COMPOSITE_NOGATE(ACLK_EMMC, "aclk_emmc", mux_aclk_emmc_p,
CLK_IGNORE_UNUSED,
RK3399_CLKSEL_CON(21), 7, 1, MFLAGS, 0, 5, DFLAGS),
- GATE(ACLK_EMMC_CORE, "aclk_emmccore", "aclk_emmc", CLK_IGNORE_UNUSED,
+ GATE(ACLK_EMMC_CORE, "aclk_emmc_core", "aclk_emmc", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 8, GFLAGS),
GATE(ACLK_EMMC_NOC, "aclk_emmc_noc", "aclk_emmc", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 9, GFLAGS),
- GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", CLK_IGNORE_UNUSED,
+ GATE(ACLK_EMMC_GRF, "aclk_emmc_grf", "aclk_emmc", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 10, GFLAGS),
/* perilp0 */
--
1.9.1
Re: [PATCH v2] f2fs: replace a build-time warning with runtime WARN_ON
Hi Arnd, Jaegeuk,
It is trivial, but it's better keep commit *title*, commit log and code
consistent. :)
Thanks,
On 2016/10/27 23:32, Arnd Bergmann wrote:
> gcc is unsure about the use of last_ofs_in_node, which might happen
> without a prior initialization:
>
> fs/f2fs//git/arm-soc/fs/f2fs/data.c: In function ‘f2fs_map_blocks’:
> fs/f2fs/data.c:799:54: warning: ‘last_ofs_in_node’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
>if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) {
>
> As pointed out by Chao Yu, the code is actually correct as 'prealloc'
> is only set if the last_ofs_in_node has been set, the two always
> get updated together.
>
> This initializes last_ofs_in_node to dn.ofs_in_node for each
> new dnode at the start of the 'next_block' loop, which at that
> point is a correct initialization as well. I assume that compilers
> that correctly track the contents of the variables and do not
> warn about the condition also figure out that they can eliminate
> the extra assignment here.
>
> Fixes: 46008c6d4232 ("f2fs: support in batch multi blocks preallocation")
> Signed-off-by: Arnd Bergmann
> ---
> fs/f2fs/data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> v2: use simpler workaround, as discussed with Chao Yu.
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 68edb47f5f71..cf5ec39f907d 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -713,7 +713,7 @@ int f2fs_map_blocks(struct inode *inode, struct
> f2fs_map_blocks *map,
> }
>
> prealloc = 0;
> - ofs_in_node = dn.ofs_in_node;
> + last_ofs_in_node = ofs_in_node = dn.ofs_in_node;
> end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
>
> next_block:
>
[PATCH] igb/e1000: correct register comments
Signed-off-by: Cao jin --- drivers/net/ethernet/intel/igb/e1000_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igb/e1000_regs.h b/drivers/net/ethernet/intel/igb/e1000_regs.h index d84afdd..58adbf2 100644 --- a/drivers/net/ethernet/intel/igb/e1000_regs.h +++ b/drivers/net/ethernet/intel/igb/e1000_regs.h @@ -320,7 +320,7 @@ #define E1000_VT_CTL 0x0581C /* VMDq Control - RW */ #define E1000_WUC 0x05800 /* Wakeup Control - RW */ #define E1000_WUFC 0x05808 /* Wakeup Filter Control - RW */ -#define E1000_WUS 0x05810 /* Wakeup Status - RO */ +#define E1000_WUS 0x05810 /* Wakeup Status - R/W1C */ #define E1000_MANC 0x05820 /* Management Control - RW */ #define E1000_IPAV 0x05838 /* IP Address Valid - RW */ #define E1000_WUPL 0x05900 /* Wakeup Packet Length - RW */ -- 2.1.0
Re: [char-misc:char-misc-testing] warning
Hi Randy, On Tue, 1 Nov 2016 09:34:04 -0700 Randy Dunlap wrote: > On 11/01/16 09:02, Robin van der Gracht wrote: > > Hi Tobias, > > > > On Tue, 1 Nov 2016 16:33:03 +0100 > > Tobias Jakobi wrote: > > > >> Hello Robin, > >> > >> I'm afraid I can't help you with that. The series was done as a request > >> by Daniel Vetter, see here for reference: > >> http://www.spinics.net/lists/dri-devel/msg113011.html > > So.. I should contact Daniel Vetter about this..? > > > >> I don't have any nouveau platform here. > > > > Me neither, the warning is shown when invoking Kconfig. So when I use > > the config file supplied on my previous email, and start a build or a > > menuconfig on my (x86_64) system its showing. > > > The kconfig warning is in mainline now and it has nothing to do with the > new HT16K33 driver. > > How is nouveau supposed to provide backlight support? > It selects FB_BACKLIGHT but FB_BACKLIGHT depends on FB, which is not > enabled in the supplied .config file. Yes, exactly! I think that line should have been removed along with the other FB deps. Regards, -- Robin van der Gracht Protonic Holland
Re: [PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling
Hi Rama,
[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.9-rc3 next-20161028]
[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/Rama-Krishna-Phani-A/iio-adc-spmi-vadc-Changes-to-support-different-scaling/20161025-141253
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All warnings (new ones prefixed by >>):
drivers/iio/adc/qcom-spmi-vadc.c: In function 'vadc_scale_fn':
>> drivers/iio/adc/qcom-spmi-vadc.c:632:4: warning: comparison of distinct
>> pointer types lacks a cast
drivers/iio/adc/qcom-spmi-vadc.c:646:4: warning: comparison of distinct
pointer types lacks a cast
vim +632 drivers/iio/adc/qcom-spmi-vadc.c
616 int ret;
617
618 switch (prop->scale_function) {
619
620 case SCALE_DEFAULT:
621 vadc_scale_calib(vadc, adc_code, prop, &voltage);
622
623 prescale = &vadc_prescale_ratios[prop->prescale];
624 voltage = voltage * prescale->den;
625 return div64_s64(voltage, prescale->num);
626
627 case SCALE_THERM_100K_PULLUP:
628 case SCALE_XOTHERM:
629 vadc_scale_calib(vadc, adc_code, prop, &voltage);
630
631 if (prop->calibration == VADC_CALIB_ABSOLUTE)
> 632 do_div(voltage, 1000);
633
634 vadc_map_voltage_temp(adcmap_100k_104ef_104fb,
635
ARRAY_SIZE(adcmap_100k_104ef_104fb),
636voltage, &result);
637 result *= 1000;
638 return result;
639
640 case SCALE_PMIC_THERM:
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
Hi Srini,
On Wed, Oct 26, 2016 at 7:27 PM, Srinivas Kandagatla
wrote:
> Hi Vivek,
>
> Thanks for consolidating qmp phy support for both usb and pcie.
On vacation, so responses are bit late. Please bear with me.
>
> On 19/10/16 11:43, Vivek Gautam wrote:
>>
>> Qualcomm SOCs have QMP phy controller that provides support
>> to a number of controller, viz. PCIe, UFS, and USB.
>> Add a new driver, based on generic phy framework, for this
>> phy controller.
>>
>> USB3-phy changes: Based on phy-msm-ssusb-qmp driver available on
>> msm-4.4 kernel @codeaurora[1].
>> PCIe-phy changes: Based on msm8996-pcie-phy driver posted by
>> Srinivas [2].
>>
>> [1]
>> https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18
>> [2] https://patchwork.kernel.org/patch/9318947/
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Kishon Vijay Abraham I
>
>
> very few minor nits which needs fixing in next version.
>
> I have tested this patch on DB820c PCIE with ethernet and SATA ports.
>
> Tested-by: Srinivas Kandagatla
Thanks for testing the patch.
>
>
>> ---
>> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 61 ++
>> drivers/phy/Kconfig|8 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-qcom-qmp.c | 1154
>>
>> 4 files changed, 1224 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> create mode 100644 drivers/phy/phy-qcom-qmp.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> new file mode 100644
>> index 000..90214aa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>> @@ -0,0 +1,61 @@
>> +Qualcomm QMP PHY
>> +
>> +
>> +QMP phy controller supports physical layer functionality for a number of
>> +controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
>> +
>> +Required properties:
>> + - compatible: compatible list, contains:
>> + "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
>> + "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
>> + - reg: offset and length of the PHY register set.
>> + - #phy-cells: must be 1
>> +- Cell after phy phandle should be the port (lane) number.
>> + - clocks: a list of phandles and clock-specifier pairs,
>> + one for each entry in clock-names.
>> + - clock-names: must be "cfg_ahb" for phy config clock,
>> + "aux" for phy aux clock,
>> + "ref_clk" for 19.2 MHz ref clk,
>> + "ref_clk_src" for reference clock source,
>> + "pipe" for pipe clock specific to
>> + each port/lane (Optional).
>
>
>> + - resets: a list of phandles and reset controller specifier pairs,
>> + one for each entry in reset-names.
>> + - reset-names: must be "phy" for reset of phy block,
>> + "common" for phy common block reset,
>> + "cfg" for phy's ahb cfg block reset (Optional).
>> + "port" for reset specific to
>> + each port/lane. (Optional)
>> + - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
>> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll
>> block.
>> +
>> +Optional properties:
>> + - vddp-ref-clk-supply: Phandle to a regulator supply to any specific
>> refclk
>> + pll block.
>> +
>> +Example:
>> + pcie_phy: pciephy@34000 {
>> + compatible = "qcom,qmp-14nm-pcie-phy";
>
>
> Fix this according to the compatibilities listed above.
Sure, will fix this.
>
>
>> + reg = <0x034000 0x3fff>;
>> + #phy-cells = <1>;
>> +
>> + clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
>> + <&gcc GCC_PCIE_PHY_CFG_AHB_CLK>,
>> + <&gcc GCC_PCIE_0_PIPE_CLK>,
>> + <&gcc GCC_PCIE_1_PIPE_CLK>,
>> + <&gcc GCC_PCIE_2_PIPE_CLK>;
>> + clock-names = "aux", "cfg_ahb",
>> + "pipe0", "pipe1", "pipe2";
>> +
>> + vdda-phy-supply = <&pm8994_l28>;
>> + vdda-pll-supply = <&pm8994_l12>;
>> +
>> + resets = <&gcc GCC_PCIE_PHY_BCR>,
>> + <&gcc GCC_PCIE_PHY_COM_BCR>,
>> + <&gcc GCC_PCIE_PHY_COM_NOCSR_BCR>,
>> + <&gcc GCC_PCIE_0_PHY_BCR>,
>> + <&gcc GCC_PCIE_1_PHY_BCR>,
>> + <&gcc GCC_PCIE_2_PHY_BCR>;
>> + reset-names = "phy", "common", "cfg",
>> + "lane0", "lane1", "lane2";
>> + };
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 5547984..d5e2b50f 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -
Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
On Thu, Oct 27, 2016 at 2:48 AM, Rob Herring wrote: > On Wed, Oct 19, 2016 at 04:13:47PM +0530, Vivek Gautam wrote: >> Qualcomm SOCs have QMP phy controller that provides support >> to a number of controller, viz. PCIe, UFS, and USB. >> Add a new driver, based on generic phy framework, for this >> phy controller. >> >> USB3-phy changes: Based on phy-msm-ssusb-qmp driver available on >> msm-4.4 kernel @codeaurora[1]. >> PCIe-phy changes: Based on msm8996-pcie-phy driver posted by >> Srinivas [2]. >> >> [1] >> https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18 >> [2] https://patchwork.kernel.org/patch/9318947/ >> >> Signed-off-by: Vivek Gautam >> Cc: Kishon Vijay Abraham I >> --- >> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 61 ++ > > Acked-by: Rob Herring Thanks Rob. Regards Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] acer-wmi: setup accelerometer when machine has appropriate notify event
Hi Darren,
Thanks for your review!
On Tue, Nov 01, 2016 at 10:28:51AM -0700, Darren Hart wrote:
> On Tue, Nov 01, 2016 at 12:33:32PM +0800, Lee, Chun-Yi wrote:
> > The accelerometer event relies on on the ACERWMID_EVENT_GUID notify.
> > So, this patch changes the codes to setup accelerometer input device
> > when detected ACERWMID_EVENT_GUID. It avoids that the accel input
> > device created on every acer machines.
> >
> > In addition, patch adds a clearly parsing logic of accelerometer hid
> > to acer_wmi_get_handle_cb callback function. It is positive matching
> > the "SENR" name with "BST0001" device to avoid non-supported hardware.
> >
> > Reported-by: Bjørn Mork
> > Tested-by: Bjørn Mork
> > Cc: Darren Hart
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > drivers/platform/x86/acer-wmi.c | 22 ++
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/platform/x86/acer-wmi.c
> > b/drivers/platform/x86/acer-wmi.c
> > index 79d64ea..3bb3162 100644
> > --- a/drivers/platform/x86/acer-wmi.c
> > +++ b/drivers/platform/x86/acer-wmi.c
> > @@ -1808,11 +1808,24 @@ static int __init acer_wmi_enable_lm(void)
> > return status;
> > }
> >
> > +#define ACER_WMID_ACCEL_HID"BST0001"
> > +
> > static acpi_status __init acer_wmi_get_handle_cb(acpi_handle ah, u32 level,
> > void *ctx, void **retval)
> > {
> > + struct acpi_device *dev;
> > +
> > + if (strcmp(ctx, "SENR")) {
Here must be "if (!strcmp(ctx, "SENR"))", it's my mistake.
I will send v2 patch.
> > + if (acpi_bus_get_device(ah, &dev))
> > + return AE_OK;
> > + if (!strcmp(ACER_WMID_ACCEL_HID, acpi_device_hid(dev)))
> > + return AE_OK;
> > + } else
> > + return AE_OK;
> > +
> > *(acpi_handle *)retval = ah;
> > - return AE_OK;
> > +
> > + return AE_CTRL_TERMINATE;
>
> I don't understand this change. Previously, we assigned retval to ah and
> returned AE_OK. Now, we either do not assign retval and still return AE_OK, or
> we do assign it and then return AE_CTRL_TERMINATE
>
> I would have expected to see something more like:
>
> if (we should setup the accelerometer)
> reval = ah
> return AE_OK
>
> return AE_CTRL_TERMINATE
>
> If I'm misunderstanding this, can you please try to explain - a comment in the
> function would be useful.
>
> Thanks,
>
Base on the function name "acer_wmi_get_handle_cb", it will be a generic
callback function for any caller who uses acer_wmi_get_handle(). And
acer_wmi_get_handle() uses acpi_get_devices(), the acpi_get_devices() allows
that HID is NULL. So that's better to check the context name and HID in
callback.
Like this (after my mistake got fixed):
static acpi_status __init acer_wmi_get_handle_cb(acpi_handle ah, u32 level,
void *ctx, void **retval)
{
+ struct acpi_device *dev;
+
/* if context is "SENR", then make sure that HID matches with BST0001 */
+ if (!strcmp(ctx, "SENR")) {
+ if (acpi_bus_get_device(ah, &dev))
+ return AE_OK;
/* if HID doesn't match then skip this device to next */
+ if (!strcmp(ACER_WMID_ACCEL_HID, acpi_device_hid(dev)))
+ return AE_OK;
/* if this device do not match any context, then just skip it to next */
+ } else
+ return AE_OK;
+
/* if match with context and HID, then return handler */
*(acpi_handle *)retval = ah;
- return AE_OK;
+
/* return AE_CTRL_TERMINATE to exit acpi_ns_walk_namespace() because we
found handler */
+ return AE_CTRL_TERMINATE;
}
Thanks a lot!
Joey Lee
Re: [f2fs-dev] [PATCH 2/3] f2fs: use __set_page_dirty_nobuffers directly
Hi Jaegeuk,
On 2016/10/21 10:28, Jaegeuk Kim wrote:
> This patch replaces the copied code with original generic function.
Will we plan to do further enhance inside f2fs_set_page_dirty_nobuffers, if we
don't it's better revert fe76b796fc5194cc3d57265002e3a748566d073f, as we don't
need to wrap __set_page_dirty_nobuffers.
BTW, does the original patch make memory cgroup functionality problematic?
Thanks,
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/data.c | 29 -
> fs/f2fs/f2fs.h | 6 +-
> 2 files changed, 5 insertions(+), 30 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 68edb47..3954315 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1801,35 +1801,6 @@ int f2fs_release_page(struct page *page, gfp_t wait)
> return 1;
> }
>
> -/*
> - * This was copied from __set_page_dirty_buffers which gives higher
> performance
> - * in very high speed storages. (e.g., pmem)
> - */
> -void f2fs_set_page_dirty_nobuffers(struct page *page)
> -{
> - struct address_space *mapping = page->mapping;
> - unsigned long flags;
> -
> - if (unlikely(!mapping))
> - return;
> -
> - spin_lock(&mapping->private_lock);
> - lock_page_memcg(page);
> - SetPageDirty(page);
> - spin_unlock(&mapping->private_lock);
> -
> - spin_lock_irqsave(&mapping->tree_lock, flags);
> - WARN_ON_ONCE(!PageUptodate(page));
> - account_page_dirtied(page, mapping);
> - radix_tree_tag_set(&mapping->page_tree,
> - page_index(page), PAGECACHE_TAG_DIRTY);
> - spin_unlock_irqrestore(&mapping->tree_lock, flags);
> - unlock_page_memcg(page);
> -
> - __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
> - return;
> -}
> -
> static int f2fs_set_data_page_dirty(struct page *page)
> {
> struct address_space *mapping = page->mapping;
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 168f939..b66a04c 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1960,6 +1960,11 @@ static inline unsigned long f2fs_find_next_bit(const
> void *addr,
> return find_next_bit(addr, size, offset + 2);
> }
>
> +static inline void f2fs_set_page_dirty_nobuffers(struct page *page)
> +{
> + __set_page_dirty_nobuffers(page);
> +}
> +
> #define get_inode_mode(i) \
> ((is_inode_flag_set(i, FI_ACL_MODE)) ? \
>(F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
> @@ -2200,7 +2205,6 @@ struct page *get_new_data_page(struct inode *, struct
> page *, pgoff_t, bool);
> int do_write_data_page(struct f2fs_io_info *);
> int f2fs_map_blocks(struct inode *, struct f2fs_map_blocks *, int, int);
> int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *, u64, u64);
> -void f2fs_set_page_dirty_nobuffers(struct page *);
> void f2fs_invalidate_page(struct page *, unsigned int, unsigned int);
> int f2fs_release_page(struct page *, gfp_t);
> #ifdef CONFIG_MIGRATION
>
Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation
Hi,
On Mon, 31 Oct 2016 06:59:04 +0100 Sascha Hauer wrote:
> As said, even the commit 7b27c160c68 introducing the register clk did not
> enable the clock consistently for all register accesses. Maybe it's best
> to include the following patch so that we can find a clear culprit and
> do not bury the ipg clock changes in larger patches.
>
> Sascha
>
> -8<---
>
> From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer
> Date: Mon, 31 Oct 2016 06:45:33 +0100
> Subject: [PATCH] pwm: imx: remove ipg clock
>
> The use of the ipg clock was introduced with commit 7b27c160c6. In the
> commit message it was claimed that the ipg clock is enabled for register
> accesses. This is true for the ->config() callback, but not for the
> ->set_enable() callback. Given that the ipg clock is not consistently
> enabled for all register accesses we can assume that either it is not
> required at all or that the current code does not work.
> Remove the ipg clock code for now so that it's no longer in the way of
> refactoring the driver.
>
> Signed-off-by: Sascha Hauer
> Cc: Philipp Zabel
> ---
> drivers/pwm/pwm-imx.c | 19 +--
> 1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> index d600fd5..70609ef2 100644
> --- a/drivers/pwm/pwm-imx.c
> +++ b/drivers/pwm/pwm-imx.c
> @@ -49,7 +49,6 @@
>
> struct imx_chip {
> struct clk *clk_per;
> - struct clk *clk_ipg;
>
> void __iomem*mmio_base;
>
> @@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
> struct pwm_device *pwm, int duty_ns, int period_ns)
> {
> struct imx_chip *imx = to_imx_chip(chip);
> - int ret;
> -
> - ret = clk_prepare_enable(imx->clk_ipg);
> - if (ret)
> - return ret;
>
> - ret = imx->config(chip, pwm, duty_ns, period_ns);
> -
> - clk_disable_unprepare(imx->clk_ipg);
> -
> - return ret;
> + return imx->config(chip, pwm, duty_ns, period_ns);
> }
>
> static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> @@ -293,13 +283,6 @@ static int imx_pwm_probe(struct platform_device *pdev)
> return PTR_ERR(imx->clk_per);
> }
>
> - imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> - if (IS_ERR(imx->clk_ipg)) {
> - dev_err(&pdev->dev, "getting ipg clock failed with %ld\n",
> - PTR_ERR(imx->clk_ipg));
> - return PTR_ERR(imx->clk_ipg);
> - }
> -
> imx->chip.ops = &imx_pwm_ops;
> imx->chip.dev = &pdev->dev;
> imx->chip.base = -1;
>
If the IPG clock is not needed by the driver it should be removed from
DT as well.
Lothar Waßmann
Re: [PATCH V4] mtd: nand: add Loongson1 NAND driver
On Wed, 2 Nov 2016 09:52:06 +0800
Keguang Zhang wrote:
> From: Kelvin Cheung
>
> This patch adds NAND driver for Loongson1B.
>
> Signed-off-by: Kelvin Cheung
>
> ---
> v4:
>Retrieve the controller from nand_hw_control.
> v3:
>Replace __raw_readl/__raw_writel with readl/writel.
>Split ls1x_nand into two structures: ls1x_nand_chip and
>ls1x_nand_controller.
> V2:
>Modify the dependency in Kconfig due to the changes of DMA
>module.
> ---
> drivers/mtd/nand/Kconfig | 8 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/loongson1_nand.c | 571
> ++
> 3 files changed, 580 insertions(+)
> create mode 100644 drivers/mtd/nand/loongson1_nand.c
>
[...]
> +static void ls1x_nand_cmdfunc(struct mtd_info *mtd, unsigned int command,
> + int column, int page_addr)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct ls1x_nand_controller *nandc =
> + to_ls1x_nand_controller(chip->controller);
> +
> + dev_dbg(mtd->dev.parent, "cmd = 0x%02x, col = 0x%08x, page = 0x%08x\n",
> + command, column, page_addr);
> +
> + if (command == NAND_CMD_RNDOUT) {
> + nandc->buf_off = column;
> + return;
> + }
> +
> + /*set address, buffer length and buffer offset */
> + if (column != -1 || page_addr != -1)
> + set_addr_len(mtd, command, column, page_addr);
> +
> + /*prepare NAND command */
> + switch (command) {
> + case NAND_CMD_RESET:
> + nandc->cmd_ctrl = CMD_RESET;
> + break;
> + case NAND_CMD_STATUS:
> + nandc->cmd_ctrl = CMD_STATUS;
> + break;
> + case NAND_CMD_READID:
> + nandc->cmd_ctrl = CMD_READID;
> + break;
> + case NAND_CMD_READ0:
> + nandc->cmd_ctrl = OP_SPARE | OP_MAIN | CMD_READ;
> + break;
> + case NAND_CMD_READOOB:
> + nandc->cmd_ctrl = OP_SPARE | CMD_READ;
> + break;
> + case NAND_CMD_ERASE1:
> + nandc->cmd_ctrl = CMD_ERASE;
> + break;
> + case NAND_CMD_PAGEPROG:
> + break;
> + case NAND_CMD_SEQIN:
> + if (column < mtd->writesize)
> + nandc->cmd_ctrl = OP_SPARE | OP_MAIN | CMD_WRITE;
> + else
> + nandc->cmd_ctrl = OP_SPARE | CMD_WRITE;
> + default:
> + return;
> + }
Sorry, but I'm still convinced this driver does not fit in the NAND
subsystem, or at least not the one we have now.
You're just supporting a limited number of the commands a raw NAND can
support (for example, no SET_FEATURE support, which is required for
ONFI NANDs), and your ->cmdfunc() implementation clearly shows that
you're converting all low-level commands into high-level ones.
Can you try to implement the mtd_info hooks directly? This only things
you'll miss are the nand_ids table and the BBT code, but I guess this is
something we can expose so that you don't have to re-use it.
Of course, you'll also have to convert absolute addresses into
page/block numbers, but that's not the hard part of the job.
You may also want to have a look at [1]. I started to abstract away the
NAND interface type to share some code between SPI NANDs and raw NANDs.
By implementing this interface, you'll at least be able to re-use the
BBT code.
I'm really sorry to ask you that now, after you've reworked most of the
driver to address my comments, but the more I look at it the more I
feel it's just a big hack to make it fit in a framework that was not
designed to support such "high-level" controllers.
Regards,
Boris
> +
> + /*set NAND command */
> + set_cmd(nandc, nandc->cmd_ctrl);
> + /*trigger NAND operation */
> + start_nand(nandc);
> + /*trigger DMA for R/W operation */
> + if (command == NAND_CMD_READ0 || command == NAND_CMD_READOOB)
> + start_dma(mtd, nandc->buf_len, false);
> + else if (command == NAND_CMD_PAGEPROG)
> + start_dma(mtd, nandc->buf_len, true);
> + nand_wait_ready(mtd);
> +
> + if (command == NAND_CMD_STATUS) {
> + nandc->datareg[0] = (char)(nand_readl(nandc, NAND_STATUS) >> 8);
> + /*work around hardware bug for invalid STATUS */
> + nandc->datareg[0] |= 0xc0;
> + nandc->data_ptr = nandc->datareg;
> + } else if (command == NAND_CMD_READID) {
> + nandc->datareg[0] = (char)(nand_readl(nandc, NAND_IDH));
> + nandc->datareg[1] = (char)(nand_readl(nandc, NAND_IDL) >> 24);
> + nandc->datareg[2] = (char)(nand_readl(nandc, NAND_IDL) >> 16);
> + nandc->datareg[3] = (char)(nand_readl(nandc, NAND_IDL) >> 8);
> + nandc->datareg[4] = (char)(nand_readl(nandc, NAND_IDL));
> + nandc->data_ptr = nandc->datareg;
> + }
> +
> + nandc->cmd_ctrl = 0;
> +}
[1]http://lkml.iu.edu/hypermail/linux/ke
[PATCH v2 2/4] ASoC: dapm: Implement stereo mixer control support
While DAPM is mono or single channel, its controls can be shared between
widgets, such as sharing one stereo mixer control between the left and
right channel widgets. An example such as the following routes
[Line In Left]-[Left Mixer]
^
^ ^ | ^
(inputs)(paths) (outputs)
v v | v
v
[Line In Right][Right Mixer]
where we have separate widgets and paths for the left and right channels
from "Line In" to "Mixer", but a shared stereo mixer control for the
2 paths.
This patch introduces support for such shared mixer controls, allowing
more than 1 path to be attached to a single stereo control, and being
able to control left/right channels independently.
Signed-off-by: Chen-Yu Tsai
---
sound/soc/soc-dapm.c | 141 ---
1 file changed, 112 insertions(+), 29 deletions(-)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 32e7af9b93d5..27dd02e57b31 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -330,6 +330,11 @@ static int dapm_kcontrol_data_alloc(struct
snd_soc_dapm_widget *widget,
case snd_soc_dapm_mixer_named_ctl:
mc = (struct soc_mixer_control *)kcontrol->private_value;
+ if (mc->autodisable && snd_soc_volsw_is_stereo(mc))
+ dev_warn(widget->dapm->dev,
+"ASoC: Unsupported stereo autodisable control
'%s'\n",
+ctrl_name);
+
if (mc->autodisable) {
struct snd_soc_dapm_widget template;
@@ -723,7 +728,8 @@ static int dapm_connect_mux(struct snd_soc_dapm_context
*dapm,
}
/* set up initial codec paths */
-static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i)
+static void dapm_set_mixer_path_status(struct snd_soc_dapm_path *p, int i,
+ int nth_path)
{
struct soc_mixer_control *mc = (struct soc_mixer_control *)
p->sink->kcontrol_news[i].private_value;
@@ -736,7 +742,25 @@ static void dapm_set_mixer_path_status(struct
snd_soc_dapm_path *p, int i)
if (reg != SND_SOC_NOPM) {
soc_dapm_read(p->sink->dapm, reg, &val);
- val = (val >> shift) & mask;
+ /*
+* The nth_path argument allows this function to know
+* which path of a kcontrol it is setting the initial
+* status for. Ideally this would support any number
+* of paths and channels. But since kcontrols only come
+* in mono and stereo variants, we are limited to 2
+* channels.
+*
+* The following code assumes for stereo controls the
+* first path is the left channel, and all remaining
+* paths are the right channel.
+*/
+ if (snd_soc_volsw_is_stereo(mc) && nth_path > 0) {
+ if (reg != mc->rreg)
+ soc_dapm_read(p->sink->dapm, mc->rreg, &val);
+ val = (val >> mc->rshift) & mask;
+ } else {
+ val = (val >> shift) & mask;
+ }
if (invert)
val = max - val;
p->connect = !!val;
@@ -749,13 +773,13 @@ static void dapm_set_mixer_path_status(struct
snd_soc_dapm_path *p, int i)
static int dapm_connect_mixer(struct snd_soc_dapm_context *dapm,
struct snd_soc_dapm_path *path, const char *control_name)
{
- int i;
+ int i, nth_path = 0;
/* search for mixer kcontrol */
for (i = 0; i < path->sink->num_kcontrols; i++) {
if (!strcmp(control_name, path->sink->kcontrol_news[i].name)) {
path->name = path->sink->kcontrol_news[i].name;
- dapm_set_mixer_path_status(path, i);
+ dapm_set_mixer_path_status(path, i, nth_path++);
return 0;
}
}
@@ -2186,7 +2210,8 @@ EXPORT_SYMBOL_GPL(snd_soc_dapm_mux_update_power);
/* test and update the power status of a mixer or switch widget */
static int soc_dapm_mixer_update_power(struct snd_soc_card *card,
- struct snd_kcontrol *kcontrol, int connect)
+ struct snd_kcontrol *kcontrol,
+ int connect, int rconnect)
{
struct snd_soc_dapm_path *path;
int found = 0;
@@ -2195,8 +2220,33 @@ static int soc_dapm_mixer_update_power(struct
snd_soc_card *card,
/* find dapm widget path assoc with kcontrol */
dapm_kcontrol_for_each_path(path, kcontrol) {
+
[PATCH v2 3/4] ASoC: dapm: Introduce DAPM_DOUBLE dual channel control type
A DAPM_DOUBLE control type can be used for dual channel mixer input
selectors / mute controls in one register, possibly toggling both
channels together.
The control is meant to be shared by 2 widgets, 1 for each channel,
such that the mixer control exposed to userspace remains a combined
stereo control.
Signed-off-by: Chen-Yu Tsai
---
include/sound/soc-dapm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index d5f466ce..f74ec19687f8 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -272,6 +272,11 @@ struct device;
/* dapm kcontrol types */
+#define SOC_DAPM_DOUBLE(xname, reg, lshift, rshift, max, invert) \
+{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
+ .info = snd_soc_info_volsw, \
+ .get = snd_soc_dapm_get_volsw, .put = snd_soc_dapm_put_volsw, \
+ .private_value = SOC_DOUBLE_VALUE(reg, lshift, rshift, max, invert, 0) }
#define SOC_DAPM_SINGLE(xname, reg, shift, max, invert) \
{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
.info = snd_soc_info_volsw, \
--
2.10.2
[PATCH v2 4/4] ASoC: dapm: Introduce DAPM_DOUBLE_R dual channel dual register control type
A DAPM_DOUBLE_R control type can be used for dual channel mixer input
selectors / mute controls across 2 registers, possibly toggling both
channels together.
The control is meant to be shared by 2 widgets, 1 for each channel,
such that the mixer control exposed to userspace remains a combined
stereo control.
Signed-off-by: Chen-Yu Tsai
---
include/sound/soc-dapm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index f74ec19687f8..a466f4bdc835 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -277,6 +277,11 @@ struct device;
.info = snd_soc_info_volsw, \
.get = snd_soc_dapm_get_volsw, .put = snd_soc_dapm_put_volsw, \
.private_value = SOC_DOUBLE_VALUE(reg, lshift, rshift, max, invert, 0) }
+#define SOC_DAPM_DOUBLE_R(xname, lreg, rreg, shift, max, invert) \
+{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
+ .info = snd_soc_info_volsw, \
+ .get = snd_soc_dapm_get_volsw, .put = snd_soc_dapm_put_volsw, \
+ .private_value = SOC_DOUBLE_R_VALUE(lreg, rreg, shift, max, invert) }
#define SOC_DAPM_SINGLE(xname, reg, shift, max, invert) \
{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
.info = snd_soc_info_volsw, \
--
2.10.2
Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation
On Wed, Nov 02, 2016 at 08:18:52AM +0100, Lothar Waßmann wrote:
> Hi,
>
> On Mon, 31 Oct 2016 06:59:04 +0100 Sascha Hauer wrote:
> > As said, even the commit 7b27c160c68 introducing the register clk did not
> > enable the clock consistently for all register accesses. Maybe it's best
> > to include the following patch so that we can find a clear culprit and
> > do not bury the ipg clock changes in larger patches.
> >
> > Sascha
> >
> > -8<---
> >
> > From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
> > From: Sascha Hauer
> > Date: Mon, 31 Oct 2016 06:45:33 +0100
> > Subject: [PATCH] pwm: imx: remove ipg clock
> >
> > The use of the ipg clock was introduced with commit 7b27c160c6. In the
> > commit message it was claimed that the ipg clock is enabled for register
> > accesses. This is true for the ->config() callback, but not for the
> > ->set_enable() callback. Given that the ipg clock is not consistently
> > enabled for all register accesses we can assume that either it is not
> > required at all or that the current code does not work.
> > Remove the ipg clock code for now so that it's no longer in the way of
> > refactoring the driver.
> >
> > Signed-off-by: Sascha Hauer
> > Cc: Philipp Zabel
> > ---
> > drivers/pwm/pwm-imx.c | 19 +--
> > 1 file changed, 1 insertion(+), 18 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index d600fd5..70609ef2 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -49,7 +49,6 @@
> >
> > struct imx_chip {
> > struct clk *clk_per;
> > - struct clk *clk_ipg;
> >
> > void __iomem*mmio_base;
> >
> > @@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
> > struct pwm_device *pwm, int duty_ns, int period_ns)
> > {
> > struct imx_chip *imx = to_imx_chip(chip);
> > - int ret;
> > -
> > - ret = clk_prepare_enable(imx->clk_ipg);
> > - if (ret)
> > - return ret;
> >
> > - ret = imx->config(chip, pwm, duty_ns, period_ns);
> > -
> > - clk_disable_unprepare(imx->clk_ipg);
> > -
> > - return ret;
> > + return imx->config(chip, pwm, duty_ns, period_ns);
> > }
> >
> > static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> > @@ -293,13 +283,6 @@ static int imx_pwm_probe(struct platform_device *pdev)
> > return PTR_ERR(imx->clk_per);
> > }
> >
> > - imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > - if (IS_ERR(imx->clk_ipg)) {
> > - dev_err(&pdev->dev, "getting ipg clock failed with %ld\n",
> > - PTR_ERR(imx->clk_ipg));
> > - return PTR_ERR(imx->clk_ipg);
> > - }
> > -
> > imx->chip.ops = &imx_pwm_ops;
> > imx->chip.dev = &pdev->dev;
> > imx->chip.base = -1;
> >
> If the IPG clock is not needed by the driver it should be removed from
> DT as well.
No, it's only the half truth that it's not needed. It would indeed be
needed if the driver used the ipg clock as source for the PWM (PWMCR[17:16] =
0b01).
The driver currently doesn't do this, so it doesn't need the clock. We
should still leave the clocks in the dts files in case we decide to use
that clock later.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v2 1/4] ASoC: dapm: Support second register for DAPM control updates
To support double channel shared controls split across 2 registers, one
for each channel, we must be able to update both registers together.
Add a second set of register fields to struct snd_soc_dapm_update, and
update the DAPM control writeback (put) callbacks to support this.
For codecs that use custom events which call into DAPM to do updates,
also clear struct snd_soc_dapm_update before using it, so the second
set of fields remains clean.
Signed-off-by: Chen-Yu Tsai
---
include/sound/soc-dapm.h | 4
sound/soc/codecs/adau17x1.c| 2 +-
sound/soc/codecs/tlv320aic3x.c | 2 +-
sound/soc/codecs/wm9712.c | 2 +-
sound/soc/codecs/wm9713.c | 2 +-
sound/soc/soc-dapm.c | 13 +++--
6 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index f60d755f7ac6..d5f466ce 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -615,6 +615,10 @@ struct snd_soc_dapm_update {
int reg;
int mask;
int val;
+ int reg2;
+ int mask2;
+ int val2;
+ bool has_second_set;
};
struct snd_soc_dapm_wcache {
diff --git a/sound/soc/codecs/adau17x1.c b/sound/soc/codecs/adau17x1.c
index 439aa3ff1f99..b36511d965c8 100644
--- a/sound/soc/codecs/adau17x1.c
+++ b/sound/soc/codecs/adau17x1.c
@@ -160,7 +160,7 @@ static int adau17x1_dsp_mux_enum_put(struct snd_kcontrol
*kcontrol,
struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
struct adau *adau = snd_soc_codec_get_drvdata(codec);
struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
- struct snd_soc_dapm_update update;
+ struct snd_soc_dapm_update update = { 0 };
unsigned int stream = e->shift_l;
unsigned int val, change;
int reg;
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 5a8d96ec058c..8877b74b0510 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -157,7 +157,7 @@ static int snd_soc_dapm_put_volsw_aic3x(struct snd_kcontrol
*kcontrol,
unsigned int mask = (1 << fls(max)) - 1;
unsigned int invert = mc->invert;
unsigned short val;
- struct snd_soc_dapm_update update;
+ struct snd_soc_dapm_update update = { 0 };
int connect, change;
val = (ucontrol->value.integer.value[0] & mask);
diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c
index 557709eac698..85f7c5bb8b82 100644
--- a/sound/soc/codecs/wm9712.c
+++ b/sound/soc/codecs/wm9712.c
@@ -187,7 +187,7 @@ static int wm9712_hp_mixer_put(struct snd_kcontrol
*kcontrol,
struct soc_mixer_control *mc =
(struct soc_mixer_control *)kcontrol->private_value;
unsigned int mixer, mask, shift, old;
- struct snd_soc_dapm_update update;
+ struct snd_soc_dapm_update update = { 0 };
bool change;
mixer = mc->shift >> 8;
diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
index e4301ddb1b84..7e4822185feb 100644
--- a/sound/soc/codecs/wm9713.c
+++ b/sound/soc/codecs/wm9713.c
@@ -231,7 +231,7 @@ static int wm9713_hp_mixer_put(struct snd_kcontrol
*kcontrol,
struct soc_mixer_control *mc =
(struct soc_mixer_control *)kcontrol->private_value;
unsigned int mixer, mask, shift, old;
- struct snd_soc_dapm_update update;
+ struct snd_soc_dapm_update update = { 0 };
bool change;
mixer = mc->shift >> 8;
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 3bbe32ee4630..32e7af9b93d5 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1626,6 +1626,15 @@ static void dapm_widget_update(struct snd_soc_card *card)
dev_err(w->dapm->dev, "ASoC: %s DAPM update failed: %d\n",
w->name, ret);
+ if (update->has_second_set) {
+ ret = soc_dapm_update_bits(w->dapm, update->reg2,
+ update->mask2, update->val2);
+ if (ret < 0)
+ dev_err(w->dapm->dev,
+ "ASoC: %s DAPM update failed: %d\n",
+ w->name, ret);
+ }
+
for (wi = 0; wi < wlist->num_widgets; wi++) {
w = wlist->widgets[wi];
@@ -3084,7 +3093,7 @@ int snd_soc_dapm_put_volsw(struct snd_kcontrol *kcontrol,
unsigned int invert = mc->invert;
unsigned int val;
int connect, change, reg_change = 0;
- struct snd_soc_dapm_update update;
+ struct snd_soc_dapm_update update = { NULL };
int ret = 0;
if (snd_soc_volsw_is_stereo(mc))
@@ -3192,7 +3201,7 @@ int snd_soc_dapm_put_enum_double(struct snd_kcontrol
*kcontrol,
unsigned int *item = ucontrol->value.enumerated.item;
unsigned int val, change, reg_change = 0;
unsigned int mask;
- struct snd_soc_dapm_update update;
+ stru
[PATCH] CHROMIUM: ec: register shutdown function to clear delayed works
This patch applies on top of "mfd: cros_ec: Add EC console read structures
definitions" (https://patchwork.kernel.org/patch/9294887/).
Reboot or shutdown during delayed works could corrupt
communication with EC, and certain I2C controller may not
be able to recover from the error state.
BUG=chrome-os-partner:58823
TEST=factory run-in test for 200+ times
Signed-off-by: Daniel Hung-yu Wu
---
drivers/platform/chrome/cros_ec_dev.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_dev.c
b/drivers/platform/chrome/cros_ec_dev.c
index 7d51f69..137c0ce 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -308,6 +308,14 @@ static int ec_device_remove(struct platform_device *pdev)
return 0;
}
+static void ec_device_shutdown(struct platform_device *pdev)
+{
+ struct cros_ec_dev *ec = dev_get_drvdata(&pdev->dev);
+
+ /* Be sure to clear up debugfs delayed works */
+ cros_ec_debugfs_remove(ec);
+}
+
static const struct platform_device_id cros_ec_id[] = {
{ "cros-ec-ctl", 0 },
{ /* sentinel */ },
@@ -320,6 +328,7 @@ static struct platform_driver cros_ec_dev_driver = {
},
.probe = ec_device_probe,
.remove = ec_device_remove,
+ .shutdown = ec_device_shutdown,
};
static int __init cros_ec_dev_init(void)
--
2.8.0.rc3.226.g39d4020
[PATCH v2 0/4] ASoC: DAPM: Support stereo controls shared between widgets
Hi everyone, This was part of my Allwinner A31 audio codec support series. As I split up some patches, the series was getting somewhat large. Hence I'm sending out the ASoC DAPM core changes separately. The remaining Allwinner specific patches will be sent later. The complete series can be found here [1], if people need a real use case as reference. While DAPM is mono or single channel, its controls can be shared between widgets, such as sharing one stereo mixer control between the left and right channel widgets. An example such as the following routes [Line In Left]-[Left Mixer] ^ ^ ^ | ^ (inputs)(paths) (outputs) v v | v v [Line In Right][Right Mixer] where we have separate widgets and paths for the left and right channels from "Line In" to "Mixer", but a shared stereo mixer control for the 2 paths. By having a stereo mixer control, we expose to userspace a sane mixer interface. Otherwise we would have a bunch of "X Left Playback Switch" and "X Right Playback Switch" controls. This series introduces support for such shared mixer controls, allowing more than 1 path to be attached to a single stereo control, and allowing control of left/right channels independently. The DAPM control types DAPM_DOUBLE and DAPM_DOUBLE_R are added. Changes since v1: - Expaned commit message for "ASoC: dapm: Implement stereo mixer control support" - Expanded comments in dapm_set_mixer_path_status and soc_dapm_mixer_update_power - Check assumption of field width < (bits in unsigned int / 2) in snd_soc_dapm_put_volsw - Print warning when adding stereo "autodisable" controls which is not supported - Use NULL for struct snd_soc_dapm_update initializer, as the first field is a pointer, to avoid compiler warnings. Regards ChenYu [1] https://github.com/wens/linux/commits/a31-audio-v2 Chen-Yu Tsai (4): ASoC: dapm: Support second register for DAPM control updates ASoC: dapm: Implement stereo mixer control support ASoC: dapm: Introduce DAPM_DOUBLE dual channel control type ASoC: dapm: Introduce DAPM_DOUBLE_R dual channel dual register control type include/sound/soc-dapm.h | 14 sound/soc/codecs/adau17x1.c| 2 +- sound/soc/codecs/tlv320aic3x.c | 2 +- sound/soc/codecs/wm9712.c | 2 +- sound/soc/codecs/wm9713.c | 2 +- sound/soc/soc-dapm.c | 154 - 6 files changed, 141 insertions(+), 35 deletions(-) -- 2.10.2
[PATCH v9 0/5] mxs-lradc: Split driver into MFD
Split existing driver mxs-lradc into MFD with touchscreen and
IIO part.
Tested on I.MX28.
Ksenija Stanojevic (5):
mfd: mxs-lradc: Add support for mxs-lradc MFD
iio: adc: mxs-lradc: Add support for adc driver
input: touchscreen: mxs-lradc: Add support for touchscreen
iio: adc: mxs-lradc: Remove driver
mfd: Move binding document
.../bindings/{iio/adc => mfd}/mxs-lradc.txt|0
drivers/iio/adc/Kconfig| 27 +-
drivers/iio/adc/Makefile |2 +-
drivers/iio/adc/mxs-lradc-adc.c| 845 ++
drivers/iio/adc/mxs-lradc.c| 1750
drivers/input/touchscreen/Kconfig | 10 +
drivers/input/touchscreen/Makefile |1 +
drivers/input/touchscreen/mxs-lradc-ts.c | 743 +
drivers/mfd/Kconfig| 17 +
drivers/mfd/Makefile |1 +
drivers/mfd/mxs-lradc.c| 249 +++
include/linux/mfd/mxs-lradc.h | 203 +++
12 files changed, 2083 insertions(+), 1765 deletions(-)
rename Documentation/devicetree/bindings/{iio/adc => mfd}/mxs-lradc.txt (100%)
create mode 100644 drivers/iio/adc/mxs-lradc-adc.c
delete mode 100644 drivers/iio/adc/mxs-lradc.c
create mode 100644 drivers/input/touchscreen/mxs-lradc-ts.c
create mode 100644 drivers/mfd/mxs-lradc.c
create mode 100644 include/linux/mfd/mxs-lradc.h
--
1.9.1
[PATCH v9 3/5] input: touchscreen: mxs-lradc: Add support for touchscreen
Add 4-wire/5-wire touchscreen controller.
Signed-off-by: Ksenija Stanojevic
---
Changes in v9:
- none
Changes in v8:
- rebase onto 4.9-rc1
Changes in v7:
- remove touch_ret variable in probe and use ret instead
- make error check on of_property_read_u32 in probe
Changes in v6:
- update copyright
Changes in v5:
- add field void __iomem *base to struct mxs_lradc_adc
- change arguments in all functions for accessing I/O memory
to follow the previous change.
- use devm_ioremap for mapping I/O memory
Changes in v4:
- update copyright
- use platform_get_irq_byname
- use irq_of_parse_and_map
Changes in v3:
- make buffer large enough for timestamps
- remove unnecessary blank lines
Changes in v2:
- improve commit message
- do not change spacing in Kconfig
- impove formating
- remove wrapper show_scale_avail
- use correct syntax for comments
- use devm_iio_trigger_alloc
- do not allocate buffer dynamically
- use iio_device_claim_*_mode helpers
- add spinlock in struct mxs_lradc_ts to enable locking in interrupt handler
- only grab irqs that are relevant to adc
- remove blank line at the end of the file
- change licence to GPL
- add copyright
drivers/input/touchscreen/Kconfig| 10 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/mxs-lradc-ts.c | 743 +++
3 files changed, 754 insertions(+)
create mode 100644 drivers/input/touchscreen/mxs-lradc-ts.c
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index efca013..8ff915e 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -841,6 +841,16 @@ config TOUCHSCREEN_USB_COMPOSITE
To compile this driver as a module, choose M here: the
module will be called usbtouchscreen.
+config TOUCHSCREEN_MXS_LRADC
+ tristate "Freescale i.MX23/i.MX28 LRADC touchscreen"
+ depends on MFD_MXS_LRADC
+ help
+ Say Y here if you have a touchscreen connected to the low-resolution
+ analog-to-digital converter (LRADC) on an i.MX23 or i.MX28 processor.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mxs-lradc-ts.
+
config TOUCHSCREEN_MX25
tristate "Freescale i.MX25 touchscreen input driver"
depends on MFD_MX25_TSADC
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 81b8645..97e1bb7 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
obj-$(CONFIG_TOUCHSCREEN_IPROC)+= bcm_iproc_tsc.o
obj-$(CONFIG_TOUCHSCREEN_LPC32XX) += lpc32xx_ts.o
obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
+obj-$(CONFIG_TOUCHSCREEN_MXS_LRADC) += mxs-lradc-ts.o
obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
obj-$(CONFIG_TOUCHSCREEN_MC13783) += mc13783_ts.o
obj-$(CONFIG_TOUCHSCREEN_MCS5000) += mcs5000_ts.o
diff --git a/drivers/input/touchscreen/mxs-lradc-ts.c
b/drivers/input/touchscreen/mxs-lradc-ts.c
new file mode 100644
index 000..a59102b
--- /dev/null
+++ b/drivers/input/touchscreen/mxs-lradc-ts.c
@@ -0,0 +1,743 @@
+/*
+ * Freescale MXS LRADC touchscreen driver
+ *
+ * Copyright (c) 2012 DENX Software Engineering, GmbH.
+ * Copyright (c) 2016 Ksenija Stanojevic
+ *
+ * Authors:
+ * Marek Vasut
+ * Ksenija Stanojevic
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+const char *mxs_lradc_ts_irq_names[] = {
+ "mxs-lradc-touchscreen",
+ "mxs-lradc-channel6",
+ "mxs-lradc-channel7",
+};
+
+/*
+ * Touchscreen handling
+ */
+enum mxs_lradc_ts_plate {
+ LRADC_TOUCH = 0,
+ LRADC_SAMPLE_X,
+ LRADC_SAMPLE_Y,
+ LRADC_SAMPLE_PRESSURE,
+ LRADC_SAMPLE_VALID,
+};
+
+struct mxs_lradc_ts {
+ struct mxs_lradc*lradc;
+ struct device *dev;
+
+ void __iomem*base;
+ /*
+* When the touchscreen is enabled, we give it two private virtual
+* channels: #6 and #7. This means that only 6 virtual channels (instead
+* of 8) will be available for buffered capture.
+*/
+#define TOUCHSCREEN_VCHANNEL1 7
+#define TOUCHSCREEN_VCHANNEL2 6
+
+ struct input_dev*ts_input;
+
+ enum mxs_lradc_ts_plate cur_plate
[PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD
Add core files for low resolution analog-to-digital converter (mxs-lradc)
MFD driver.
Signed-off-by: Ksenija Stanojevic
---
Changes in v9:
- improve commit message.
Changes in v8:
- rebase onto 4.9-rc1
Changes in v7:
- define macros ADC_CELL and TSC_CELL
- remove one cell and dynamically set them in the switch()
- fail in the touchscreen driver instead of mfd driver if
hardware doesn't contain a touchscreen
Changes in v6:
- update copyright
- add kernel-doc header for struct mxs-lradc
- add error message
- change EINVAL to ENODEV
- use PLATFORM_DEVID_NONE instead -1
- cosmetic fixes
Changes in v5:
- use DEFINE_RES_MEM
- don't pass ioreammaped adress to platform cells
- move comment outside of struct mxs_lradc
- change type of argument in mxs_lradc_reg_set, mxs_lradc_reg_clear,
mxs_lradc_reg_wrt (struct mxs_lradc * -> void __iomem *)
Changes in v4:
- update copyright
- use DEFINE_RES_IRQ_NAMED
- remove mxs_lradc_add_device function
- use struct mfd_cell in static form
- improve spacing
- remove unnecessary comment
- remove platform_get_irq
- remove touch_ret and use ret instead
- rename use_touchscreen to touchscreen_wire
- use goto statements
- remove irq[13], irq_count and irq_name from struct mxs_lradc
- remove all defines from inside the struct definition
Changes in v3:
- add note to commit message
- move switch statement into if(touch_ret == 0) branch
- add MODULE_AUTHOR
Changes in v2:
- do not change spacing in Kconfig
- make struct mfd_cell part of struct mxs_lradc
- use switch instead of if in mxs_lradc_irq_mask
- use only necessary header files in mxs_lradc.h
- use devm_mfd_add_device
- use separate function to register mfd device
- change licence to GPL
- add copyright
drivers/mfd/Kconfig | 17 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/mxs-lradc.c | 249 ++
include/linux/mfd/mxs-lradc.h | 203 ++
4 files changed, 470 insertions(+)
create mode 100644 drivers/mfd/mxs-lradc.c
create mode 100644 include/linux/mfd/mxs-lradc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df644..bdd88cf 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -326,6 +326,23 @@ config MFD_MC13XXX_I2C
help
Select this if your MC13xxx is connected via an I2C bus.
+config MFD_MXS_LRADC
+ tristate "Freescale i.MX23/i.MX28 LRADC"
+ depends on ARCH_MXS || COMPILE_TEST
+ select MFD_CORE
+ select STMP_DEVICE
+ help
+ Say yes here to build support for the Low Resolution
+ Analog-to-Digital Converter (LRADC) found on the i.MX23 and i.MX28
+ processors. This driver provides common support for accessing the
+ device, additional drivers must be enabled in order to use the
+ functionality of the device:
+ mxs-lradc-adc for ADC readings
+ mxs-lradc-ts for touchscreen support
+
+ This driver can also be built as a module. If so, the module will be
+ called mxs-lradc.
+
config MFD_MX25_TSADC
tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
select REGMAP_MMIO
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9834e66..057ca15 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -211,3 +211,4 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
+obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
diff --git a/drivers/mfd/mxs-lradc.c b/drivers/mfd/mxs-lradc.c
new file mode 100644
index 000..ffc8f2e
--- /dev/null
+++ b/drivers/mfd/mxs-lradc.c
@@ -0,0 +1,249 @@
+/*
+ * Freescale MXS Low Resolution Analog-to-Digital Converter driver
+ *
+ * Copyright (c) 2012 DENX Software Engineering, GmbH.
+ * Copyright (c) 2016 Ksenija Stanojevic
+ *
+ * Authors:
+ * Marek Vasut
+ * Ksenija Stanojevic
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MXS_LRADC_BASE 0x8005
+#define ADC_CELL 0
+#define TSC_CELL 1
+
+enum mx23_lradc_irqs {
+ MX23_LRADC_TS_IRQ = 0,
+ MX23_LRADC_CH0_IRQ,
+ MX23_LRADC_CH1_IRQ,
+ MX23_LRADC_CH2_IRQ,
+ MX23_LRADC_CH3_IRQ,
+ MX23_LRADC_CH4_IRQ,
+ MX23_LRADC_CH5_IRQ,
+ MX23_LRADC_CH6_IRQ,
+ MX23_LRA
[PATCH v9 5/5] mfd: Move binding document
The bindings, which are now used in MFD, need also to be
documented in the MFD binding document.
Signed-off-by: Ksenija Stanojevic
---
Changes in v9:
- format patch using -M option
Changes in v8:
- rebase onto 4.9-rc1
Changes in v7:
- add to the patchset
Documentation/devicetree/bindings/{iio/adc => mfd}/mxs-lradc.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{iio/adc => mfd}/mxs-lradc.txt (100%)
diff --git a/Documentation/devicetree/bindings/iio/adc/mxs-lradc.txt
b/Documentation/devicetree/bindings/mfd/mxs-lradc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/iio/adc/mxs-lradc.txt
rename to Documentation/devicetree/bindings/mfd/mxs-lradc.txt
--
1.9.1
[PATCH v9 4/5] iio: adc: mxs-lradc: Remove driver
Since the driver has been split into mfd there is no reason for it to
stay, so remove it.
Signed-off-by: Ksenija Stanojevic
Acked-by: Jonathan Cameron
---
Changes in v9:
- none
Changes in v8:
- rebase onto 4.9-rc1
Changes in v7:
- none
Changes in v6:
- none
Changes in v5:
- none
Changes in v4:
- none
Changes in v3:
- none
Changes in v2:
- add to the patchset
drivers/iio/adc/Kconfig | 14 -
drivers/iio/adc/Makefile|1 -
drivers/iio/adc/mxs-lradc.c | 1750 ---
3 files changed, 1765 deletions(-)
delete mode 100644 drivers/iio/adc/mxs-lradc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 6414397..02c7592 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -362,20 +362,6 @@ config MEN_Z188_ADC
This driver can also be built as a module. If so, the module will be
called men_z188_adc.
-config MXS_LRADC
-tristate "Freescale i.MX23/i.MX28 LRADC"
-depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
-depends on INPUT
-select STMP_DEVICE
-select IIO_BUFFER
-select IIO_TRIGGERED_BUFFER
-help
- Say yes here to build support for i.MX23/i.MX28 LRADC convertor
- built into these chips.
-
- To compile this driver as a module, choose M here: the
- module will be called mxs-lradc.
-
config NAU7802
tristate "Nuvoton NAU7802 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index e62ebeb..131c466 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -35,7 +35,6 @@ obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_MXS_LRADC_ADC) += mxs-lradc-adc.o
-obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_NAU7802) += nau7802.o
obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
diff --git a/drivers/iio/adc/mxs-lradc.c b/drivers/iio/adc/mxs-lradc.c
deleted file mode 100644
index b84d37c..000
--- a/drivers/iio/adc/mxs-lradc.c
+++ /dev/null
@@ -1,1750 +0,0 @@
-/*
- * Freescale MXS LRADC driver
- *
- * Copyright (c) 2012 DENX Software Engineering, GmbH.
- * Marek Vasut
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define DRIVER_NAME"mxs-lradc"
-
-#define LRADC_MAX_DELAY_CHANS 4
-#define LRADC_MAX_MAPPED_CHANS 8
-#define LRADC_MAX_TOTAL_CHANS 16
-
-#define LRADC_DELAY_TIMER_HZ 2000
-
-/*
- * Make this runtime configurable if necessary. Currently, if the buffered mode
- * is enabled, the LRADC takes LRADC_DELAY_TIMER_LOOP samples of data before
- * triggering IRQ. The sampling happens every (LRADC_DELAY_TIMER_PER / 2000)
- * seconds. The result is that the samples arrive every 500mS.
- */
-#define LRADC_DELAY_TIMER_PER 200
-#define LRADC_DELAY_TIMER_LOOP 5
-
-/*
- * Once the pen touches the touchscreen, the touchscreen switches from
- * IRQ-driven mode to polling mode to prevent interrupt storm. The polling
- * is realized by worker thread, which is called every 20 or so milliseconds.
- * This gives the touchscreen enough fluency and does not strain the system
- * too much.
- */
-#define LRADC_TS_SAMPLE_DELAY_MS 5
-
-/*
- * The LRADC reads the following amount of samples from each touchscreen
- * channel and the driver then computes average of these.
- */
-#define LRADC_TS_SAMPLE_AMOUNT 4
-
-enum mxs_lradc_id {
- IMX23_LRADC,
- IMX28_LRADC,
-};
-
-static const char * const mx23_lradc_irq_names[] = {
- "mxs-lradc-touchscreen",
- "mxs-lradc-channel0",
- "mxs-lradc-channel1",
- "mxs-lradc-channel2",
- "mxs-lradc-channel3",
- "mxs-lradc-channel4",
- "mxs-lradc-channel5",
- "mxs-lradc-channel6",
- "mxs-lradc-channel7",
-};
-
-static const char * const mx28_lradc_irq_names[] = {
- "mxs-lradc-touchscreen",
- "mxs-lradc-thresh0",
- "mxs-lradc-thresh1",
- "mxs-lradc-channel0",
- "mxs-lradc-channel1",
- "mxs-lradc-channel2",
- "mxs-lradc-channel3",
- "mxs-lradc-channel4",
- "mxs-lradc-channel5",
- "mxs-lradc-channel6",
- "
[PATCH v9 2/5] iio: adc: mxs-lradc: Add support for adc driver
Add support for sixteen-channel 12-bit resolution ADC and its functions,
which include general-purpose ADC readings, battery voltage measurement,
and die temperature measurement.
Signed-off-by: Ksenija Stanojevic
Reviewed-by: Jonathan Cameron
---
Changes in v9:
- none
Changes in v8:
- rebase onto 4.9-rc1
Changes in v7:
- none
Changes in v6:
- update copyright
Changes in v5:
- add field void __iomem *base to struct mxs_lradc_adc
- change arguments in all functions for accessing I/O memory
to follow the previous change.
- use devm_ioremap for mapping I/O memory
Changes in v4:
- update copyright
- use platform_get_irq_byname
- use irq_of_parse_and_map
Changes in v3:
- make buffer large enough for timestamps
- remove unnecessary blank lines
Changes in v2:
- improve commit message
- do not change spacing in Kconfig
- impove formating
- remove wrapper show_scale_avail
- use correct syntax for comments
- use devm_iio_trigger_alloc
- do not allocate buffer dynamically
- use iio_device_claim_*_mode helpers
- add spinlock in struct mxs_lradc_ts to enable locking in interrupt handler
- only grab irqs that are relevant to adc
- remove blank line at the end of the file
- change licence to GPL
- add copyright
drivers/iio/adc/Kconfig | 13 +
drivers/iio/adc/Makefile| 1 +
drivers/iio/adc/mxs-lradc-adc.c | 845
3 files changed, 859 insertions(+)
create mode 100644 drivers/iio/adc/mxs-lradc-adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7edcf32..6414397 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -207,6 +207,19 @@ config EXYNOS_ADC
To compile this driver as a module, choose M here: the module will be
called exynos_adc.
+config MXS_LRADC_ADC
+ tristate "Freescale i.MX23/i.MX28 LRADC ADC"
+ depends on MFD_MXS_LRADC
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for the ADC functions of the
+ i.MX23/i.MX28 LRADC. This includes general-purpose ADC readings,
+ battery voltage measurement, and die temperature measurement.
+
+ This driver can also be built as a module. If so, the module will be
+ called mxs-lradc-adc.
+
config FSL_MX25_ADC
tristate "Freescale MX25 ADC driver"
depends on MFD_MX25_TSADC
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..e62ebeb 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
+obj-$(CONFIG_MXS_LRADC_ADC) += mxs-lradc-adc.o
obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_NAU7802) += nau7802.o
obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
diff --git a/drivers/iio/adc/mxs-lradc-adc.c b/drivers/iio/adc/mxs-lradc-adc.c
new file mode 100644
index 000..6943220
--- /dev/null
+++ b/drivers/iio/adc/mxs-lradc-adc.c
@@ -0,0 +1,845 @@
+/*
+ * Freescale MXS LRADC ADC driver
+ *
+ * Copyright (c) 2012 DENX Software Engineering, GmbH.
+ * Copyright (c) 2016 Ksenija Stanojevic
+ *
+ * Authors:
+ * Marek Vasut
+ * Ksenija Stanojevic
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Make this runtime configurable if necessary. Currently, if the buffered mode
+ * is enabled, the LRADC takes LRADC_DELAY_TIMER_LOOP samples of data before
+ * triggering IRQ. The sampling happens every (LRADC_DELAY_TIMER_PER / 2000)
+ * seconds. The result is that the samples arrive every 500mS.
+ */
+#define LRADC_DELAY_TIMER_PER 200
+#define LRADC_DELAY_TIMER_LOOP 5
+
+#define VREF_MV_BASE 1850
+
+const char *mx23_lradc_adc_irq_names[] = {
+ "mxs-lradc-channel0",
+ "mxs-lradc-channel1",
+ "mxs-lradc-channel2",
+ "mxs-lradc-channel3",
+ "mxs-lradc-channel4",
+ "mxs-lradc-channel5",
+};
+
+const char *mx28_lradc_adc_irq_names[] = {
+ "mxs-lradc-thresh0",
+ "mxs-lradc-thresh1",
+ "mxs-lradc-channel0",
+ "mxs-lradc-channel1",
+ "mxs-lradc-channel2",
+ "mxs-lradc-channel3",
+ "mxs-lradc-channel4",
+ "mxs-lradc-channel5",
+ "mxs-lradc-button0",
+ "mx
[PATCH 1/2] phy: rockchip-inno-usb2: support otg-port for rk3399
The rk3399 SoC USB2 PHY is comprised of one Host port and
one OTG port. And OTG port is for USB2.0 part of USB3.0 OTG
controller, as a part to construct a fully feature Type-C
subsystem.
With this patch, we can support OTG port with the following
functions:
- Support BC1.2 charger detect, and use extcon notifier to
send USB charger types to power driver.
- Support PHY suspend for power management.
- Support OTG Host only mode.
- Hold a wakelock when work as SDP(e.g. connect to PC).
Also, correct 480MHz output clock stable time. We found that
the system crashed due to 480MHz output clock of USB2 PHY was
unstable after clock had been enabled by gpu module.
Theoretically, 1 millisecond is a critical value for 480 output
clock stable time, so we try changing the delay time to 1.2
millisecond to avoid this issue.
Signed-off-by: William Wu
---
drivers/phy/phy-rockchip-inno-usb2.c | 609 +--
1 file changed, 578 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..352cf87 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -30,11 +31,16 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
+#include
#define BIT_WRITEABLE_SHIFT16
-#define SCHEDULE_DELAY (60 * HZ)
+#define SCHEDULE_DELAY (60 * HZ)
+#define OTG_SCHEDULE_DELAY (2 * HZ)
enum rockchip_usb2phy_port_id {
USB2PHY_PORT_OTG,
@@ -49,6 +55,37 @@ enum rockchip_usb2phy_host_state {
PHY_STATE_FS_LS_ONLINE = 4,
};
+/**
+ * Different states involved in USB charger detection.
+ * USB_CHG_STATE_UNDEFINED USB charger is not connected or detection
+ * process is not yet started.
+ * USB_CHG_STATE_WAIT_FOR_DCD Waiting for Data pins contact.
+ * USB_CHG_STATE_DCD_DONE Data pin contact is detected.
+ * USB_CHG_STATE_PRIMARY_DONE Primary detection is completed (Detects
+ * between SDP and DCP/CDP).
+ * USB_CHG_STATE_SECONDARY_DONESecondary detection is completed
(Detects
+ * between DCP and CDP).
+ * USB_CHG_STATE_DETECTED USB charger type is determined.
+ */
+enum usb_chg_state {
+ USB_CHG_STATE_UNDEFINED = 0,
+ USB_CHG_STATE_WAIT_FOR_DCD,
+ USB_CHG_STATE_DCD_DONE,
+ USB_CHG_STATE_PRIMARY_DONE,
+ USB_CHG_STATE_SECONDARY_DONE,
+ USB_CHG_STATE_DETECTED,
+};
+
+static const unsigned int rockchip_usb2phy_extcon_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_CHG_USB_SDP,
+ EXTCON_CHG_USB_CDP,
+ EXTCON_CHG_USB_DCP,
+ EXTCON_CHG_USB_SLOW,
+ EXTCON_NONE,
+};
+
struct usb2phy_reg {
unsigned intoffset;
unsigned intbitend;
@@ -58,19 +95,55 @@ struct usb2phy_reg {
};
/**
+ * struct rockchip_chg_det_reg: usb charger detect registers
+ * @cp_det: charging port detected successfully.
+ * @dcp_det: dedicated charging port detected successfully.
+ * @dp_det: assert data pin connect successfully.
+ * @idm_sink_en: open dm sink curren.
+ * @idp_sink_en: open dp sink current.
+ * @idp_src_en: open dm source current.
+ * @rdm_pdwn_en: open dm pull down resistor.
+ * @vdm_src_en: open dm voltage source.
+ * @vdp_src_en: open dp voltage source.
+ * @opmode: utmi operational mode.
+ */
+struct rockchip_chg_det_reg {
+ struct usb2phy_reg cp_det;
+ struct usb2phy_reg dcp_det;
+ struct usb2phy_reg dp_det;
+ struct usb2phy_reg idm_sink_en;
+ struct usb2phy_reg idp_sink_en;
+ struct usb2phy_reg idp_src_en;
+ struct usb2phy_reg rdm_pdwn_en;
+ struct usb2phy_reg vdm_src_en;
+ struct usb2phy_reg vdp_src_en;
+ struct usb2phy_reg opmode;
+};
+
+/**
* struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
* @phy_sus: phy suspend register.
+ * @bvalid_det_en: vbus valid rise detection enable register.
+ * @bvalid_det_st: vbus valid rise detection status register.
+ * @bvalid_det_clr: vbus valid rise detection clear register.
* @ls_det_en: linestate detection enable register.
* @ls_det_st: linestate detection state register.
* @ls_det_clr: linestate detection clear register.
+ * @utmi_avalid: utmi vbus avalid status register.
+ * @utmi_bvalid: utmi vbus bvalid status register.
* @utmi_ls: utmi linestate state register.
* @utmi_hstdet: utmi host disconnect register.
*/
struct rockchip_usb2phy_port_cfg {
struct usb2phy_reg phy_sus;
+ struct usb2phy_reg bvalid_det_en;
+ struct usb2phy_reg bvalid_det_st;
+ struct usb2phy_reg bvalid_det_clr;
struct usb2phy_reg ls_det_en;
struct usb2phy_reg ls_det_st;
struct usb2phy_reg ls_det_clr;
+ stru
[PATCH 0/2] support USB2 PHY OTG port for rk3399
This series add support for rk3399 USB2 PHY0 and PHY1 OTG port. rk3399 has two USB2 PHYs, and each USB2 PHY is comprised of one Host port and one OTG port. We have supported Host port before, and try to support OTG port now. Test on rk3399-evb board. William Wu (2): phy: rockchip-inno-usb2: support otg-port for rk3399 arm64: dts: rockchip: add usb2-phy otg-port support for rk3399 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 21 ++ drivers/phy/phy-rockchip-inno-usb2.c | 609 +-- 2 files changed, 599 insertions(+), 31 deletions(-) -- 2.0.0
[PATCH 2/2] arm64: dts: rockchip: add usb2-phy otg-port support for rk3399
Add otg-port nodes for both u2phy0 and u2phy1. The otg-port can
be used for USB2.0 part of USB3.0 OTG controller.
Signed-off-by: William Wu
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b65c193..ea2df51 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1095,6 +1095,17 @@
clock-output-names = "clk_usbphy0_480m";
status = "disabled";
+ u2phy0_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ,
+,
+;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+
+
u2phy0_host: host-port {
#phy-cells = <0>;
interrupts = ;
@@ -1112,6 +1123,16 @@
clock-output-names = "clk_usbphy1_480m";
status = "disabled";
+ u2phy1_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = ,
+,
+;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+
u2phy1_host: host-port {
#phy-cells = <0>;
interrupts = ;
--
2.0.0
Re: [PATCH 1/6] NCR5380: Use probe_irq_*() for IRQ probing
On Mon, 31 Oct 2016, Ondrej Zary wrote:
> Use standard probe_irq_on() and probe_irq_off() functions instead of own
> implementation. This prevents warning messages like this in the kernel
> log: genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080
> (i8042)
>
> Move the IRQ trigger code to a separate function so it can be used for
> other purposes (testing if the IRQ works) and move the code from NCR5380
> to g_NCR5380.
>
> Also add missing IRQ reset before and after the probe.
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/NCR5380.c | 77
> +-
> drivers/scsi/NCR5380.h |1 -
> drivers/scsi/g_NCR5380.c | 50 +-
> 3 files changed, 50 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
> index d849ffa..4f5ca79 100644
> --- a/drivers/scsi/NCR5380.c
> +++ b/drivers/scsi/NCR5380.c
> @@ -97,9 +97,6 @@
> * and macros and include this file in your driver.
> *
> * These macros control options :
> - * AUTOPROBE_IRQ - if defined, the NCR5380_probe_irq() function will be
> - * defined.
> - *
> * AUTOSENSE - if defined, REQUEST SENSE will be performed automatically
> * for commands that return with a CHECK CONDITION status.
> *
> @@ -127,9 +124,7 @@
> * NCR5380_dma_residual - residual byte count
> *
> * The generic driver is initialized by calling NCR5380_init(instance),
> - * after setting the appropriate host specific fields and ID. If the
> - * driver wishes to autoprobe for an IRQ line, the
> NCR5380_probe_irq(instance,
> - * possible) function may be used.
> + * after setting the appropriate host specific fields and ID.
> */
>
> #ifndef NCR5380_io_delay
> @@ -351,76 +346,6 @@ static void NCR5380_print_phase(struct Scsi_Host
> *instance)
> }
> #endif
>
> -
> -static int probe_irq;
> -
> -/**
> - * probe_intr- helper for IRQ autoprobe
> - * @irq: interrupt number
> - * @dev_id: unused
> - * @regs: unused
> - *
> - * Set a flag to indicate the IRQ in question was received. This is
> - * used by the IRQ probe code.
> - */
> -
> -static irqreturn_t probe_intr(int irq, void *dev_id)
> -{
> - probe_irq = irq;
> - return IRQ_HANDLED;
> -}
> -
> -/**
> - * NCR5380_probe_irq - find the IRQ of an NCR5380
> - * @instance: NCR5380 controller
> - * @possible: bitmask of ISA IRQ lines
> - *
> - * Autoprobe for the IRQ line used by the NCR5380 by triggering an IRQ
> - * and then looking to see what interrupt actually turned up.
> - */
> -
> -static int __maybe_unused NCR5380_probe_irq(struct Scsi_Host *instance,
> - int possible)
> -{
> - struct NCR5380_hostdata *hostdata = shost_priv(instance);
> - unsigned long timeout;
> - int trying_irqs, i, mask;
> -
> - for (trying_irqs = 0, i = 1, mask = 2; i < 16; ++i, mask <<= 1)
> - if ((mask & possible) && (request_irq(i, &probe_intr, 0,
> "NCR-probe", NULL) == 0))
> - trying_irqs |= mask;
> -
> - timeout = jiffies + msecs_to_jiffies(250);
> - probe_irq = NO_IRQ;
> -
> - /*
> - * A interrupt is triggered whenever BSY = false, SEL = true
> - * and a bit set in the SELECT_ENABLE_REG is asserted on the
> - * SCSI bus.
> - *
> - * Note that the bus is only driven when the phase control signals
> - * (I/O, C/D, and MSG) match those in the TCR, so we must reset that
> - * to zero.
> - */
> -
> - NCR5380_write(TARGET_COMMAND_REG, 0);
> - NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
> - NCR5380_write(OUTPUT_DATA_REG, hostdata->id_mask);
> - NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE | ICR_ASSERT_DATA |
> ICR_ASSERT_SEL);
> -
> - while (probe_irq == NO_IRQ && time_before(jiffies, timeout))
> - schedule_timeout_uninterruptible(1);
> -
> - NCR5380_write(SELECT_ENABLE_REG, 0);
> - NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
> -
> - for (i = 1, mask = 2; i < 16; ++i, mask <<= 1)
> - if (trying_irqs & mask)
> - free_irq(i, NULL);
> -
> - return probe_irq;
> -}
> -
> /**
> * NCR58380_info - report driver and host information
> * @instance: relevant scsi host instance
> diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
> index 3c6ce54..4724558 100644
> --- a/drivers/scsi/NCR5380.h
> +++ b/drivers/scsi/NCR5380.h
> @@ -290,7 +290,6 @@ static inline struct scsi_cmnd *NCR5380_to_scmd(struct
> NCR5380_cmd *ncmd_ptr)
> #define NCR5380_dprint_phase(flg, arg) do {} while (0)
> #endif
>
> -static int NCR5380_probe_irq(struct Scsi_Host *instance, int possible);
> static int NCR5380_init(struct Scsi_Host *instance, int flags);
> static int NCR5380_maybe_reset_bus(struct Scsi_Host *);
> static void NCR5380_exit(struct Scsi_Host *instance);
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 7299ad9..09c660b 100644
> -
Re: [PATCH 2/6] g_NCR5380: Test the IRQ before accepting it
On Mon, 31 Oct 2016, Ondrej Zary wrote:
> Trigger an IRQ first with a test IRQ handler to find out if it really
> works. Disable the IRQ if not.
>
> This prevents hang when incorrect IRQ was specified by user.
>
Once again, how does it cause a hang?
If the user specifies an IRQ, we should trust them. If they don't specify
an IRQ then probe (as in patch 5/6).
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/g_NCR5380.c | 44 +---
> 1 file changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 09c660b..0d1f6ad 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -115,6 +115,32 @@ static int NCR5380_probe_irq(struct Scsi_Host *instance)
> return irq;
> }
>
> +static bool irq_working;
> +
> +static irqreturn_t test_irq(int irq, void *dev_id)
> +{
> + irq_working = true;
> + return IRQ_HANDLED;
> +}
> +
> +/* test if the IRQ is working */
> +static int NCR5380_test_irq(struct Scsi_Host *instance, int irq)
> +{
> + struct NCR5380_hostdata *hostdata = shost_priv(instance);
> +
> + irq_working = false;
> + if (request_irq(irq, test_irq, 0, "NCR5380-irqtest", NULL))
> + return -EBUSY;
> + NCR5380_trigger_irq(instance);
> + NCR5380_read(RESET_PARITY_INTERRUPT_REG);
> + free_irq(irq, NULL);
> +
> + if (!irq_working)
> + return -EIO;
> +
> + return 0;
> +}
> +
IMO the extra complexity is not justified by the possibility of machines
with misconfigured BIOS or incorrect module parameters.
I don't want another irq probing mechanism. We just got rid of one.
But I won't mind if the SCSI maintainers who know ISA better than I do
would like to review this.
> /*
> * Configure I/O address of 53C400A or DTC436 by writing magic numbers
> * to ports 0x779 and 0x379.
> @@ -323,9 +349,21 @@ static int generic_NCR5380_init_one(struct
> scsi_host_template *tpnt,
> /* set IRQ for HP C2502 */
> if (board == BOARD_HP_C2502)
> magic_configure(port_idx, instance->irq, magic);
> - if (request_irq(instance->irq, generic_NCR5380_intr,
> - 0, "NCR5380", instance)) {
> - printk(KERN_WARNING "scsi%d : IRQ%d not free,
> interrupts disabled\n", instance->host_no, instance->irq);
> + ret = NCR5380_test_irq(instance, instance->irq);
> + if (ret) {
> + printk(KERN_WARNING "scsi%d : IRQ%d not %s, interrupts
> disabled\n",
> +instance->host_no, instance->irq,
> +(ret == -EBUSY) ? "free" : "working");
> + instance->irq = NO_IRQ;
> + }
> + }
> +
> + if (instance->irq != NO_IRQ) {
> + if (request_irq(instance->irq, generic_NCR5380_intr, 0,
> + "NCR5380", instance)) {
> + printk(KERN_WARNING "scsi%d : IRQ%d not free,
> interrupts disabled\n",
> +instance->host_no,
> +instance->irq);
> instance->irq = NO_IRQ;
> }
> }
>
--
Re: [PATCH 3/6] g_NCR5380: Check for chip presence before calling NCR5380_init()
On Mon, 31 Oct 2016, Ondrej Zary wrote:
> Write and read back MODE_REG to check if the chip is really there
> before doing more initialization.
>
> This prevents hang when incorrect I/O address was specified by user (in
> the most common case where no device is present there so all reads
> result in 0xff).
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/g_NCR5380.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 0d1f6ad..e713dba 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -322,6 +322,13 @@ static int generic_NCR5380_init_one(struct
> scsi_host_template *tpnt,
> }
> }
>
> + /* check if the chip is really there */
> + NCR5380_write(MODE_REG, 0);
> + if (NCR5380_read(MODE_REG) != 0) {
Wouldn't it be more accurate to write,
/* Check for some kind of device. A vacant slot reads 0xff. */
?
> + ret = -ENODEV;
> + goto out_unregister;
> + }
> +
> ret = NCR5380_init(instance, flags | FLAG_LATE_DMA_SETUP);
> if (ret)
> goto out_unregister;
>
--
Re: [PATCH 4/6] g_NCR5380: Add IRQ auto-configuration for HP C2502
On Mon, 31 Oct 2016, Ondrej Zary wrote:
> Find free and working IRQ automatically on HP C2502 cards.
> Also allow IRQ 9 to work (aliases to IRQ 2 on the card).
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/g_NCR5380.c | 29 +++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index e713dba..27fc499 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -156,6 +156,8 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
> outb(magic[4], 0x379);
>
> /* allowed IRQs for HP C2502 */
> + if (irq == 9)
> + irq = 2;
> if (irq != 2 && irq != 3 && irq != 4 && irq != 5 && irq != 7)
> irq = 0;
> if (idx >= 0 && idx <= 7)
> @@ -163,6 +165,21 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
> outb(cfg, 0x379);
> }
>
> +/* find a free and working IRQ (for HP C2502) */
> +static int NCR5380_find_irq(struct Scsi_Host *instance, u8 irqs[],
> + int port_idx, u8 magic[])
> +{
> + int i;
> +
> + for (i = 0; irqs[i]; i++) {
> + magic_configure(port_idx, irqs[i], magic);
> + if (NCR5380_test_irq(instance, irqs[i]) == 0)
> + return irqs[i];
The NCR5380_test_irq routine in patch 2/6 doesn't work for shared irqs, so
you may not get the IRQ you would expect. (The core driver does support
shared irqs, BTW.)
Also, you've ignored the irq module parameters. From the user's point of
view, surely the least surprising thing is to attempt to configure the
card for whatever irq the user asked for.
If the specified irq isn't supported by the board, just log an error and
fail. If you want to be user friendly, print a message to tell them what
irqs the card supports.
If the user asks for IRQ_AUTO, just configure the board for a hard-coded
default, say 9, and print a warning message to say so.
Either way, if request_irq fails just continue with NO_IRQ, as per usual.
To me that's the most flexible and least surprising behaviour. But again,
if someone with more ISA knowledge wishes to weigh in, that's fine too.
> + }
> + magic_configure(port_idx, 0, magic);
> + return NO_IRQ;
> +}
> +
> static unsigned int ncr_53c400a_ports[] = {
> 0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350, 0
> };
> @@ -175,6 +192,9 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
> static u8 hp_c2502_magic[] = { /* HP C2502 */
> 0x0f, 0x22, 0xf0, 0x20, 0x80
> };
> +static u8 hp_c2502_irqs[] = {
> + 9, 5, 7, 3, 4, 0
> +};
>
> static int generic_NCR5380_init_one(struct scsi_host_template *tpnt,
> struct device *pdev, int base, int irq, int board)
> @@ -345,8 +365,13 @@ static int generic_NCR5380_init_one(struct
> scsi_host_template *tpnt,
>
> if (irq != IRQ_AUTO)
> instance->irq = irq;
> - else
> - instance->irq = NCR5380_probe_irq(instance);
> + else {
> + if (board == BOARD_HP_C2502)
> + instance->irq = NCR5380_find_irq(instance,
> + hp_c2502_irqs, port_idx, magic);
> + else
> + instance->irq = NCR5380_probe_irq(instance);
> + }
>
> /* Compatibility with documented NCR5380 kernel parameters */
> if (instance->irq == 255)
>
--
Re: [PATCH 5/6] g_NCR5380: Autoprobe IRQ by default
On Mon, 31 Oct 2016, Ondrej Zary wrote:
> IRQ probing seems to work fine now. Default to autoprobe for IRQ instead
> of disabling it.
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/g_NCR5380.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 27fc499..6a08d3e 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -52,9 +52,9 @@
> module_param(dtc_3181e, int, 0);
> module_param(hp_c2502, int, 0);
>
> -static int irq[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +static int irq[] = { IRQ_AUTO, IRQ_AUTO, IRQ_AUTO, IRQ_AUTO, IRQ_AUTO,
> IRQ_AUTO, IRQ_AUTO, IRQ_AUTO };
> module_param_array(irq, int, NULL, 0);
> -MODULE_PARM_DESC(irq, "IRQ number(s)");
> +MODULE_PARM_DESC(irq, "IRQ number(s) (0=disable, 254=auto [default])");
>
> static int base[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> module_param_array(base, int, NULL, 0);
>
I think this patch is incomplete and you should add these changes:
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 7299ad9..0bf0322 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -44,7 +44,7 @@ static int ncr_53c400;
static int ncr_53c400a;
static int dtc_3181e;
static int hp_c2502;
-module_param(ncr_irq, int, 0);
+module_param(ncr_irq, int, IRQ_AUTO);
module_param(ncr_addr, int, 0);
module_param(ncr_5380, int, 0);
module_param(ncr_53c400, int, 0);
@@ -597,7 +597,7 @@ static int __init generic_NCR5380_init(void)
int ret = 0;
/* compatibility with old-style parameters */
- if (irq[0] == 0 && base[0] == 0 && card[0] == -1) {
+ if (irq[0] == IRQ_AUTO && base[0] == 0 && card[0] == -1) {
irq[0] = ncr_irq;
base[0] = ncr_addr;
if (ncr_5380)
--
Re: [PATCH 6/6] g_NCR5380: Fix release region in error handling
On Mon, 31 Oct 2016, Ondrej Zary wrote:
> When a SW-configurable card is specified but not found, the driver
> releases wrong region, causing the following message in kernel log:
> Trying to free nonexistent resource <-000f>
>
> Fix it by assigning base earlier.
>
> Signed-off-by: Ondrej Zary
This fix is not related to the others in this series. It could go at the
beginning where it is easy to cherry-pick.
Fixes: a8cfbcaec0c1 ("scsi: g_NCR5380: Stop using scsi_module.c")
Acked-by: Finn Thain
> ---
> drivers/scsi/g_NCR5380.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 6a08d3e..d33e71f 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -258,12 +258,12 @@ static int generic_NCR5380_init_one(struct
> scsi_host_template *tpnt,
> if (ports[i]) {
> /* At this point we have our region reserved */
> magic_configure(i, 0, magic); /* no IRQ yet */
> - outb(0xc0, ports[i] + 9);
> - if (inb(ports[i] + 9) != 0x80) {
> + base = ports[i];
> + outb(0xc0, base + 9);
> + if (inb(base + 9) != 0x80) {
> ret = -ENODEV;
> goto out_release;
> }
> - base = ports[i];
> port_idx = i;
> } else
> return -EINVAL;
>
--
Re: [PATCH] soc: qcom: Add SoC info driver
On 10/27/2016 7:11 PM, Arnd Bergmann wrote: > On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote: >> On 10/26/2016 8:16 PM, Arnd Bergmann wrote: >>> On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote: On 10/26/2016 7:35 PM, Arnd Bergmann wrote: >>> As we are talking about generic soc_device_attribute fields, I was >>> hoping that >>> having a vendor field would be helpful as along with family it would >>> provide >>> a more thorough information. Also as more than one foundries may be >>> used for >>> a soc, can we have a field say foundry_id to provide this information. > My first feeling is that this 'vendor' information can should be > derived from the family. It's also not clear what would happen > to this when a company gets bought. E.g. the Oxnas product family > was subsequently owned by Oxford, PLX, Avago and Broadcom, and the > mxs family was Sigmatel, Freescale, now NXP and might soon be > Qualcomm. What would you put in there in this case? Okay, not having vendor field is fine for me. Could you also suggest something about the foundry_id field. >>> >>> This one seems more well-defined, so it's probably ok to add. What >>> would be the use case of reading this? Would you want to read it >>> just from user space or also from the kernel? >>> >> >> As of now the use case I can think of, only involve reading this from user >> space. For example for the same soc, coming from different foundries with >> different manufacturing process, we may have a situation where some >> inconsistent >> h/w behavior is being observed only on parts received from a certain foundry >> and in those cases this information may help in segregation of problematic >> socs >> and may also be used in testing these socs under a different set of settings >> like >> voltage, frequency etc. >> >>> Maybe this can be combined with a manufacturing process, which probably >>> falls into a similar category, so we could have something like >>> "TSMC 28ULP" as a string in there. >>> >> >> Yes. Having a manufacturing process as part of foundry-id can provide a more >> thorough information. > > Ok, sounds good. Let's do it like this. We can always add support for > in-kernel matching of this string if needed later. > Thanks for the feedback. So how should I proceed now, should I i. send one patch first that adds the serial_number and foundry_id fields in generic soc_dev_attribute structure and then send my modified socinfo driver as per new soc_dev_attribute structure or ii. send both the changes as 2 separate patches of the same patch set. or iii. Continue with the current soc_dev_attribute structure and modify the socinfo driver once soc_dev_attribute structure has serial_number and foundry_id fields. > Arnd > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 09/60] dm: dm.c: replace 'bio->bi_vcnt == 1' with !bio_multiple_segments
On Wed, Nov 2, 2016 at 11:09 AM, Kent Overstreet wrote: > On Mon, Oct 31, 2016 at 08:29:01AM -0700, Christoph Hellwig wrote: >> On Sat, Oct 29, 2016 at 04:08:08PM +0800, Ming Lei wrote: >> > Avoid to access .bi_vcnt directly, because it may be not what >> > the driver expected any more after supporting multipage bvec. >> > >> > Signed-off-by: Ming Lei >> >> It would be really nice to have a comment in the code why it's >> even checking for multiple segments. > > Or ideally refactor the code to not care about multiple segments at all. The check on 'bio->bi_vcnt == 1' is introduced in commit de3ec86dff160(dm: don't start current request if it would've merged with the previous), which fixed one performance issue.[1] Looks the idea of the patch is to delay dispatching the rq if it would've merged with previous request and the rq is small(single bvec). I guess the motivation is to try to increase chance of merging with the delay. But why does the code check on 'bio->bi_vcnt == 1'? Once the bio is submitted, .bi_vcnt isn't changed any more and merging doesn't change it too. So should the check have been on blk_rq_bytes(rq)? Mike, please correct me if my understanding is wrong. [1] https://www.redhat.com/archives/dm-devel/2015-March/msg00014.html thanks, Ming Lei
Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation
Hi,
On Wed, 2 Nov 2016 08:36:14 +0100 Sascha Hauer wrote:
> On Wed, Nov 02, 2016 at 08:18:52AM +0100, Lothar Waßmann wrote:
> > Hi,
> >
> > On Mon, 31 Oct 2016 06:59:04 +0100 Sascha Hauer wrote:
> > > As said, even the commit 7b27c160c68 introducing the register clk did not
> > > enable the clock consistently for all register accesses. Maybe it's best
> > > to include the following patch so that we can find a clear culprit and
> > > do not bury the ipg clock changes in larger patches.
> > >
> > > Sascha
> > >
> > > -8<---
> > >
> > > From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
> > > From: Sascha Hauer
> > > Date: Mon, 31 Oct 2016 06:45:33 +0100
> > > Subject: [PATCH] pwm: imx: remove ipg clock
> > >
> > > The use of the ipg clock was introduced with commit 7b27c160c6. In the
> > > commit message it was claimed that the ipg clock is enabled for register
> > > accesses. This is true for the ->config() callback, but not for the
> > > ->set_enable() callback. Given that the ipg clock is not consistently
> > > enabled for all register accesses we can assume that either it is not
> > > required at all or that the current code does not work.
> > > Remove the ipg clock code for now so that it's no longer in the way of
> > > refactoring the driver.
> > >
> > > Signed-off-by: Sascha Hauer
> > > Cc: Philipp Zabel
> > > ---
> > > drivers/pwm/pwm-imx.c | 19 +--
> > > 1 file changed, 1 insertion(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > > index d600fd5..70609ef2 100644
> > > --- a/drivers/pwm/pwm-imx.c
> > > +++ b/drivers/pwm/pwm-imx.c
> > > @@ -49,7 +49,6 @@
> > >
> > > struct imx_chip {
> > > struct clk *clk_per;
> > > - struct clk *clk_ipg;
> > >
> > > void __iomem*mmio_base;
> > >
> > > @@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
> > > struct pwm_device *pwm, int duty_ns, int period_ns)
> > > {
> > > struct imx_chip *imx = to_imx_chip(chip);
> > > - int ret;
> > > -
> > > - ret = clk_prepare_enable(imx->clk_ipg);
> > > - if (ret)
> > > - return ret;
> > >
> > > - ret = imx->config(chip, pwm, duty_ns, period_ns);
> > > -
> > > - clk_disable_unprepare(imx->clk_ipg);
> > > -
> > > - return ret;
> > > + return imx->config(chip, pwm, duty_ns, period_ns);
> > > }
> > >
> > > static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> > > @@ -293,13 +283,6 @@ static int imx_pwm_probe(struct platform_device
> > > *pdev)
> > > return PTR_ERR(imx->clk_per);
> > > }
> > >
> > > - imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > > - if (IS_ERR(imx->clk_ipg)) {
> > > - dev_err(&pdev->dev, "getting ipg clock failed with %ld\n",
> > > - PTR_ERR(imx->clk_ipg));
> > > - return PTR_ERR(imx->clk_ipg);
> > > - }
> > > -
> > > imx->chip.ops = &imx_pwm_ops;
> > > imx->chip.dev = &pdev->dev;
> > > imx->chip.base = -1;
> > >
> > If the IPG clock is not needed by the driver it should be removed from
> > DT as well.
>
> No, it's only the half truth that it's not needed. It would indeed be
> needed if the driver used the ipg clock as source for the PWM (PWMCR[17:16] =
> 0b01).
>
That's a different story!
Currently the DT specifies two clocks for the PWM:
1. register access clock (which we now know is unnecessary)
2. PWM source clock
In the case mentioned above, the IPG clock has to be specified as the
SECOND clock entry in DT, because otherwise the clock won't be
enabled/disabled as required!
Lothar Waßmann
Re: [PATCH v6 0/5] Functional dependencies between devices
Hi Greg, On 2016-10-31 18:47, Greg Kroah-Hartman wrote: On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote: Let me quote from the previous intro messages for this series first: Time for another update. :-) Fewer changes this time, mostly to address issues found by Lukas and Marek. The most significant one is to make device_link_add() cope with the case when the consumer device has not been registered yet when it is called. The supplier device still is required to be registered and the function will return NULL if that is not the case. Another significant change is in patch [4/5] that now makes the core apply pm_runtime_get_sync()/pm_runtime_put() to supplier devices around the probing of a consumer one (in analogy with the parent). One more update after some conversations during LinuxCon Europe. The main point was to make it possible for device_link_add() to figure out the initial state of the link instead of expecting the caller to provide it which might not be reliable enough in general. In this version device_link_add() takes three arguments, the supplier and consumer pointers and flags and it sets the correct initial state of the link automatically (unless invoked with the "stateless" flag, of course). The cost is one additional field in struct device (I moved all of the links-related fields in struct device to a separate sub-structure while at it) to track the "driver presence status" of the device (to be used by device_link_add()). In addition to that, the links list walks in the core.c and dd.c code are under the device links mutex now, so the iternal link spinlock is not needed any more and I have renamed symbols to distinguish between flags, link states and device "driver presence statuses". The most significant change in this revision with respect to the previous one is related to the fact that SRCU is not available on some architectures, so the code falls back to using an RW semaphore for synchronization if SRCU is not there. Fortunately, the code changes needed for that turned out to be quite straightforward and confined to the second patch. Apart from this, the flags are defined using BIT(x) now (instead of open coding the latter in the flag definitions). Updated is mostly patch [2/5]. Patches [1,3,5/5] have not changed (except for trivial rebasing) and patch [4/5] needed to be refreshed on top of the modified [2/5]. FWIW, I've run the series through 0-day which has not reported any problems with it. Great, they are now applied to my tree, thanks again for doing this work. Thanks for merging those patches! Could you provide a stable tag with them, so I can ask Joerg to merge my Exynos IOMMU PM patches on top of it via IOMMU tree? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCHv2 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
On Mon, 31 Oct 2016, Thor Thayer wrote:
> On 10/31/2016 03:02 AM, Lee Jones wrote:
> > On Thu, 27 Oct 2016, ttha...@opensource.altera.com wrote:
> >
> > > From: Thor Thayer
> > >
> > > Add the Altera Arria10 DevKit System Resource Monitor functionality
> > > to the MFD device.
> > >
> > > Signed-off-by: Thor Thayer
> > > ---
> > > v2 Change from -mon to -monitor for clarity
> > > ---
> > > drivers/mfd/altera-a10sr.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
> > > index 06e1f7f..30de652 100644
> > > --- a/drivers/mfd/altera-a10sr.c
> > > +++ b/drivers/mfd/altera-a10sr.c
> > > @@ -33,6 +33,10 @@
> > > .name = "altr_a10sr_gpio",
> > > .of_compatible = "altr,a10sr-gpio",
> > > },
> > > + {
> > > + .name = "altr_a10sr_monitor",
> > > + .of_compatible = "altr,a10sr-monitor",
> >
> > So long as you use whichever compatible you agree on with Rob:
> >
> > For my own reference:
> > Acked-for-MFD-by: Lee Jones
> >
> I'm getting a "Non-standard signature" warning for this (even if I make
> everything lower-case).
>
> Would you prefer I submit it with the warning or should I change it to
> "Acked-by"?
Please submit it as you see it. I will amend when applying.
> Thanks for reviewing!
>
> Thor
>
> > > + },
> > > };
> > >
> > > static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] CHROMIUM: ec: register shutdown function to clear delayed works
On Wed, Oct 26, 2016 at 03:22:14PM +0100, Lee Jones wrote:
> On Wed, 26 Oct 2016, Lee Jones wrote:
>
> > On Mon, 24 Oct 2016, Daniel Hung-yu Wu wrote:
> >
> > > This patch applies on top of "mfd: cros_ec: Add EC console read structures
> > > definitions" (https://patchwork.kernel.org/patch/9294887/).
> > >
> > > This patch is currently against a linux 3.18 kernel.
> > >
> > > Reboot or shutdown during delayed works could corrupt communication with
> > > EC,
> > > and certain I2C controller may not be able to recover from the error
> > > state.
> > > A shutdown function is registered to clear delayed works or wait for them
> > > to
> > > finish.
> > >
> > > Signed-off-by: Daniel Hung-yu Wu
> > > ---
> > > drivers/mfd/cros_ec_dev.c | 9 +
> > > 1 file changed, 9 insertions(+)
> >
> > Applied, thanks.
>
> Ah, I thought you'd at least ported it to Mainline!
>
> You need to do that before posting patches.
>
> > > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> > > index 8618a7c..3e548f1 100644
> > > --- a/drivers/mfd/cros_ec_dev.c
> > > +++ b/drivers/mfd/cros_ec_dev.c
> > > @@ -613,6 +613,14 @@ static int ec_device_remove(struct platform_device
> > > *pdev)
> > > return 0;
> > > }
> > >
> > > +static void ec_device_shutdown(struct platform_device *pdev)
> > > +{
> > > + struct cros_ec_dev *ec = dev_get_drvdata(&pdev->dev);
> > > +
> > > + /* Be sure to clear up debugfs delayed works */
> > > + cros_ec_debugfs_remove(ec);
> > > +}
> > > +
> > > static int ec_device_suspend(struct device *dev)
> > > {
> > > struct cros_ec_dev *ec = dev_get_drvdata(dev);
> > > @@ -656,6 +664,7 @@ static struct platform_driver cros_ec_dev_driver = {
> > > },
> > > .probe = ec_device_probe,
> > > .remove = ec_device_remove,
> > > + .shutdown = ec_device_shutdown,
> > > };
> > >
> > > static int __init cros_ec_dev_init(void)
> >
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
The patch for Mainline is submitted. Thanks.
Re: [PATCH v10 18/19] docs: Sysfs ABI for mediated device framework
On 10/31/2016 12:49 PM, Jike Song wrote: > On 10/27/2016 05:29 AM, Kirti Wankhede wrote: >> Added details of sysfs ABI for mediated device framework >> >> Signed-off-by: Kirti Wankhede >> Signed-off-by: Neo Jia >> Change-Id: Icb0fd4ed58a2fa793fbcb1c3d5009a4403c1f3ac >> --- >> Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111 >> ++ >> 1 file changed, 111 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-bus-vfio-mdev >> >> diff --git a/Documentation/ABI/testing/sysfs-bus-vfio-mdev >> b/Documentation/ABI/testing/sysfs-bus-vfio-mdev >> new file mode 100644 >> index ..452dbe39270e >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-bus-vfio-mdev >> @@ -0,0 +1,111 @@ >> +What: /sys/...//mdev_supported_types/ >> +Date: October 2016 >> +Contact:Kirti Wankhede >> +Description: >> +This directory contains list of directories of currently >> +supported mediated device types and their details for >> +. Supported type attributes are defined by the >> +vendor driver who registers with Mediated device framework. >> +Each supported type is a directory whose name is created >> +by adding the device driver string as a prefix to the >> +string provided by the vendor driver. >> + >> +What: /sys/...//mdev_supported_types// >> +Date: October 2016 >> +Contact:Kirti Wankhede >> +Description: >> +This directory gives details of supported type, like name, >> +description, available_instances, device_api etc. >> +'device_api' and 'available_instances' are mandatory >> +attributes to be provided by vendor driver. 'name', >> +'description' and other vendor driver specific attributes >> +are optional. >> + > > Hi Kirti, > > Is there any checking in the mdev framework that mandatory attributes > are actually provided? > No. These are exposed so that libvirt can use those to create devices. If those are not provided, libvirt would not work. Kirti.
Re: [PATCH v10 01/19] vfio: Mediated device Core driver
On 10/29/2016 11:41 PM, Jike Song wrote:
> On 10/29/2016 06:06 PM, Kirti Wankhede wrote:
>>
>>
>> On 10/29/2016 10:00 AM, Jike Song wrote:
>>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
+int mdev_register_device(struct device *dev, const struct parent_ops *ops)
+{
+ int ret;
+ struct parent_device *parent;
+
+ /* check for mandatory ops */
+ if (!ops || !ops->create || !ops->remove || !ops->supported_type_groups)
+ return -EINVAL;
+
+ dev = get_device(dev);
+ if (!dev)
+ return -EINVAL;
+
+ mutex_lock(&parent_list_lock);
+
+ /* Check for duplicate */
+ parent = __find_parent_device(dev);
+ if (parent) {
+ ret = -EEXIST;
+ goto add_dev_err;
+ }
+
+ parent = kzalloc(sizeof(*parent), GFP_KERNEL);
+ if (!parent) {
+ ret = -ENOMEM;
+ goto add_dev_err;
+ }
+
+ kref_init(&parent->ref);
+ mutex_init(&parent->lock);
+
+ parent->dev = dev;
+ parent->ops = ops;
+
+ ret = parent_create_sysfs_files(parent);
+ if (ret) {
+ mutex_unlock(&parent_list_lock);
+ mdev_put_parent(parent);
+ return ret;
+ }
+
+ ret = class_compat_create_link(mdev_bus_compat_class, dev, NULL);
+ if (ret)
+ dev_warn(dev, "Failed to create compatibility class link\n");
+
>>>
>>> Hi Kirti,
>>>
>>> Like I replied to previous version:
>>>
>>> http://www.spinics.net/lists/kvm/msg139331.html
>>>
>>
>> Hi Jike,
>>
>> I saw your reply but by that time v10 version of patch series was out
>> for review.
>>
>
> Ah..yes, I forgot that :)
>
>>> You can always check if mdev_bus_compat_class already registered
>>> here, and register it if not yet. Same logic should be adopted to
>>> mdev_init.
>>>
>>> Current implementation will simply panic if configured as builtin,
>>> which is rare but far from impossible.
>>>
>>
>> Can you verify attached patch with v10 patch-set whether this works for you?
>> I'll incorporate this change in my next version.
>>
>
> Seems cool. But would you please also keep the register in mdev_init(),
> just check the 'in case it was already registered' case? Thanks!
>
The class is used only to keep symbolic to the devices which are
registered to mdev framework. So I think its ok to register this class
when first device is registered.
Thanks,
Kirti
Re: [PATCH 1/6] NCR5380: Use probe_irq_*() for IRQ probing
On Wednesday 02 November 2016, Finn Thain wrote:
> On Mon, 31 Oct 2016, Ondrej Zary wrote:
> > Use standard probe_irq_on() and probe_irq_off() functions instead of own
> > implementation. This prevents warning messages like this in the kernel
> > log: genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080
> > (i8042)
> >
> > Move the IRQ trigger code to a separate function so it can be used for
> > other purposes (testing if the IRQ works) and move the code from NCR5380
> > to g_NCR5380.
> >
> > Also add missing IRQ reset before and after the probe.
> >
> > Signed-off-by: Ondrej Zary
> > ---
> > drivers/scsi/NCR5380.c | 77
> > +- drivers/scsi/NCR5380.h |
> >1 -
> > drivers/scsi/g_NCR5380.c | 50 +-
> > 3 files changed, 50 insertions(+), 78 deletions(-)
> >
> > diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
> > index d849ffa..4f5ca79 100644
> > --- a/drivers/scsi/NCR5380.c
> > +++ b/drivers/scsi/NCR5380.c
> > @@ -97,9 +97,6 @@
> > * and macros and include this file in your driver.
> > *
> > * These macros control options :
> > - * AUTOPROBE_IRQ - if defined, the NCR5380_probe_irq() function will be
> > - * defined.
> > - *
> > * AUTOSENSE - if defined, REQUEST SENSE will be performed automatically
> > * for commands that return with a CHECK CONDITION status.
> > *
> > @@ -127,9 +124,7 @@
> > * NCR5380_dma_residual - residual byte count
> > *
> > * The generic driver is initialized by calling NCR5380_init(instance),
> > - * after setting the appropriate host specific fields and ID. If the
> > - * driver wishes to autoprobe for an IRQ line, the
> > NCR5380_probe_irq(instance, - * possible) function may be used.
> > + * after setting the appropriate host specific fields and ID.
> > */
> >
> > #ifndef NCR5380_io_delay
> > @@ -351,76 +346,6 @@ static void NCR5380_print_phase(struct Scsi_Host
> > *instance) }
> > #endif
> >
> > -
> > -static int probe_irq;
> > -
> > -/**
> > - * probe_intr - helper for IRQ autoprobe
> > - * @irq: interrupt number
> > - * @dev_id: unused
> > - * @regs: unused
> > - *
> > - * Set a flag to indicate the IRQ in question was received. This is
> > - * used by the IRQ probe code.
> > - */
> > -
> > -static irqreturn_t probe_intr(int irq, void *dev_id)
> > -{
> > - probe_irq = irq;
> > - return IRQ_HANDLED;
> > -}
> > -
> > -/**
> > - * NCR5380_probe_irq - find the IRQ of an NCR5380
> > - * @instance: NCR5380 controller
> > - * @possible: bitmask of ISA IRQ lines
> > - *
> > - * Autoprobe for the IRQ line used by the NCR5380 by triggering an IRQ
> > - * and then looking to see what interrupt actually turned up.
> > - */
> > -
> > -static int __maybe_unused NCR5380_probe_irq(struct Scsi_Host *instance,
> > - int possible)
> > -{
> > - struct NCR5380_hostdata *hostdata = shost_priv(instance);
> > - unsigned long timeout;
> > - int trying_irqs, i, mask;
> > -
> > - for (trying_irqs = 0, i = 1, mask = 2; i < 16; ++i, mask <<= 1)
> > - if ((mask & possible) && (request_irq(i, &probe_intr, 0,
> > "NCR-probe",
> > NULL) == 0)) - trying_irqs |= mask;
> > -
> > - timeout = jiffies + msecs_to_jiffies(250);
> > - probe_irq = NO_IRQ;
> > -
> > - /*
> > -* A interrupt is triggered whenever BSY = false, SEL = true
> > -* and a bit set in the SELECT_ENABLE_REG is asserted on the
> > -* SCSI bus.
> > -*
> > -* Note that the bus is only driven when the phase control signals
> > -* (I/O, C/D, and MSG) match those in the TCR, so we must reset that
> > -* to zero.
> > -*/
> > -
> > - NCR5380_write(TARGET_COMMAND_REG, 0);
> > - NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
> > - NCR5380_write(OUTPUT_DATA_REG, hostdata->id_mask);
> > - NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE | ICR_ASSERT_DATA |
> > ICR_ASSERT_SEL); -
> > - while (probe_irq == NO_IRQ && time_before(jiffies, timeout))
> > - schedule_timeout_uninterruptible(1);
> > -
> > - NCR5380_write(SELECT_ENABLE_REG, 0);
> > - NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
> > -
> > - for (i = 1, mask = 2; i < 16; ++i, mask <<= 1)
> > - if (trying_irqs & mask)
> > - free_irq(i, NULL);
> > -
> > - return probe_irq;
> > -}
> > -
> > /**
> > * NCR58380_info - report driver and host information
> > * @instance: relevant scsi host instance
> > diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
> > index 3c6ce54..4724558 100644
> > --- a/drivers/scsi/NCR5380.h
> > +++ b/drivers/scsi/NCR5380.h
> > @@ -290,7 +290,6 @@ static inline struct scsi_cmnd
> > *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr) #define
> > NCR5380_dprint_phase(flg, arg) do {} while (0)
> > #endif
> >
> > -static int NCR5380_probe_irq(struct Scsi_Host *instance, int possible);
> > static int NCR5380_init(struct Scsi_Host *instance, i
Re: [PATCH v10 07/19] vfio iommu type1: Update argument of vaddr_get_pfn()
On 10/28/2016 11:31 AM, Jike Song wrote:
> On 10/27/2016 08:24 PM, Kirti Wankhede wrote:
>>
>>
>> On 10/27/2016 5:41 PM, Jike Song wrote:
>>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
Update arguments of vaddr_get_pfn() to take struct mm_struct *mm as input
argument.
Signed-off-by: Kirti Wankhede
Signed-off-by: Neo Jia
Change-Id: I885fd4cd4a9f66f4ee2c1caf58267464ec239f52
---
drivers/vfio/vfio_iommu_type1.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c
b/drivers/vfio/vfio_iommu_type1.c
index 72fee415044a..3d916b965492 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -228,20 +228,31 @@ static int put_pfn(unsigned long pfn, int prot)
return 0;
}
-static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long
*pfn)
+static int vaddr_get_pfn(struct mm_struct *remote_mm, unsigned long vaddr,
+ int prot, unsigned long *pfn)
{
struct page *page[1];
struct vm_area_struct *vma;
+ struct mm_struct *mm = (remote_mm ? remote_mm : current->mm);
int ret = -EFAULT;
- if (get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE), page) == 1) {
+ if (remote_mm) {
+ down_read(&mm->mmap_sem);
+ ret = get_user_pages_remote(NULL, mm, vaddr, 1,
+ !!(prot & IOMMU_WRITE), 0, page, NULL);
>>>
>>> Hi Kirti,
>>>
>>> It seems that get_user_pages_remote has only 7 args but you somehow gives 8
>>> here?
>>>
>>
>> I had tested this patch with linux-next. It has 8 arguments, see mm/gup.c:
>>
>> long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
>> unsigned long start, unsigned long nr_pages,
>> int write, int force, struct page **pages,
>> struct vm_area_struct **vmas)
>> {
>> return __get_user_pages_locked(tsk, mm, start, nr_pages, write,
>> force,
>>pages, vmas, NULL, false,
>>FOLL_TOUCH | FOLL_REMOTE);
>> }
>> EXPORT_SYMBOL(get_user_pages_remote);
>
> It's queer. I checked:
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/mm/gup.c
>
> It still has 7 args.
>
> I believe you have seen this change somewhere, would you share the repo url
> and branch name of the linux-next you based on?
>
Sorry, my git was synced just few changes behind this change. I'll make
sure that I test the patch set at top of tree.
Thanks,
Kirti
Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation
On Wed, Nov 02, 2016 at 08:56:20AM +0100, Lothar Waßmann wrote:
> Hi,
>
> On Wed, 2 Nov 2016 08:36:14 +0100 Sascha Hauer wrote:
> > On Wed, Nov 02, 2016 at 08:18:52AM +0100, Lothar Waßmann wrote:
> > > Hi,
> > >
> > > On Mon, 31 Oct 2016 06:59:04 +0100 Sascha Hauer wrote:
> > > > As said, even the commit 7b27c160c68 introducing the register clk did
> > > > not
> > > > enable the clock consistently for all register accesses. Maybe it's best
> > > > to include the following patch so that we can find a clear culprit and
> > > > do not bury the ipg clock changes in larger patches.
> > > >
> > > > Sascha
> > > >
> > > > -8<---
> > > >
> > > > From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
> > > > From: Sascha Hauer
> > > > Date: Mon, 31 Oct 2016 06:45:33 +0100
> > > > Subject: [PATCH] pwm: imx: remove ipg clock
> > > >
> > > > The use of the ipg clock was introduced with commit 7b27c160c6. In the
> > > > commit message it was claimed that the ipg clock is enabled for register
> > > > accesses. This is true for the ->config() callback, but not for the
> > > > ->set_enable() callback. Given that the ipg clock is not consistently
> > > > enabled for all register accesses we can assume that either it is not
> > > > required at all or that the current code does not work.
> > > > Remove the ipg clock code for now so that it's no longer in the way of
> > > > refactoring the driver.
> > > >
> > > > Signed-off-by: Sascha Hauer
> > > > Cc: Philipp Zabel
> > > > ---
> > > > drivers/pwm/pwm-imx.c | 19 +--
> > > > 1 file changed, 1 insertion(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > > > index d600fd5..70609ef2 100644
> > > > --- a/drivers/pwm/pwm-imx.c
> > > > +++ b/drivers/pwm/pwm-imx.c
> > > > @@ -49,7 +49,6 @@
> > > >
> > > > struct imx_chip {
> > > > struct clk *clk_per;
> > > > - struct clk *clk_ipg;
> > > >
> > > > void __iomem*mmio_base;
> > > >
> > > > @@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
> > > > struct pwm_device *pwm, int duty_ns, int period_ns)
> > > > {
> > > > struct imx_chip *imx = to_imx_chip(chip);
> > > > - int ret;
> > > > -
> > > > - ret = clk_prepare_enable(imx->clk_ipg);
> > > > - if (ret)
> > > > - return ret;
> > > >
> > > > - ret = imx->config(chip, pwm, duty_ns, period_ns);
> > > > -
> > > > - clk_disable_unprepare(imx->clk_ipg);
> > > > -
> > > > - return ret;
> > > > + return imx->config(chip, pwm, duty_ns, period_ns);
> > > > }
> > > >
> > > > static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device
> > > > *pwm)
> > > > @@ -293,13 +283,6 @@ static int imx_pwm_probe(struct platform_device
> > > > *pdev)
> > > > return PTR_ERR(imx->clk_per);
> > > > }
> > > >
> > > > - imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > > > - if (IS_ERR(imx->clk_ipg)) {
> > > > - dev_err(&pdev->dev, "getting ipg clock failed with
> > > > %ld\n",
> > > > - PTR_ERR(imx->clk_ipg));
> > > > - return PTR_ERR(imx->clk_ipg);
> > > > - }
> > > > -
> > > > imx->chip.ops = &imx_pwm_ops;
> > > > imx->chip.dev = &pdev->dev;
> > > > imx->chip.base = -1;
> > > >
> > > If the IPG clock is not needed by the driver it should be removed from
> > > DT as well.
> >
> > No, it's only the half truth that it's not needed. It would indeed be
> > needed if the driver used the ipg clock as source for the PWM (PWMCR[17:16]
> > = 0b01).
> >
> That's a different story!
> Currently the DT specifies two clocks for the PWM:
> 1. register access clock (which we now know is unnecessary)
> 2. PWM source clock
> In the case mentioned above, the IPG clock has to be specified as the
> SECOND clock entry in DT, because otherwise the clock won't be
> enabled/disabled as required!
Since the driver gets its clock by name (clk_get(&pdev->dev, "per"/"ipg"))
the position in the DT doesn't matter at all.
The only thing that isn't accurate is that the "ipg" clock in the device
tree is not for register access, but itself a clock to be used as PWM
source. This is no functional problem though.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver
On Tue, Nov 1, 2016 at 2:35 PM, Sergei Shtylyov
wrote:
>> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
>
> [...]
>>
>> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
>> iounmap(base);
>> #endif /* CONFIG_ARM_ARCH_TIMER */
>>
>> - rcar_gen2_clocks_init(mode);
>> + of_clk_init(NULL);
>> clocksource_probe();
>> }
>>
>
> This hunk no longer applies to devel.
Indeed, but I can't update it, as we can't have all mach-shmobile changes in
the clock tree. So Simon will have to resolve the conflict later.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [RFC 12/14] regmap: SoundWire: Add regmap support for SoundWire bus
On Fri, Oct 28, 2016 at 07:03:55PM +0100, Mark Brown wrote:
> On Fri, Oct 21, 2016 at 06:11:10PM +0530, Hardik Shah wrote:
>
> > +static inline void get_t_size(size_t *t_val_size, size_t *t_size,
> > + int *reg_addr,
> > + int *offset,
> > + size_t *val_size)
> > +{
> > +
> > + *t_val_size += *t_size;
> > + *offset += *t_size;
>
> So, I started by taking a look at this patch to get a sense of what the
> API would look like and I see that we're not following CodingStyle with
> everything indented twice :(
>
Sorry Mark for delayed response, there was festival holidays in India, so I
was not able to reply.
Regarding two tabs, it got missed for this function somehow, I will fix it
in next patchset.
> > +static int regmap_sdw_gather_write(void *context,
> > + const void *reg, size_t reg_size,
> > + const void *val, size_t val_size)
> > +{
>
> > + if (!sdw)
> > + return 0;
>
> Silently ignoring errors :(
>
This should never happen ideally. This was extra check to make sure there is
not kernel crash. I can remove it as well.
> > + if (val_size > SDW_MAX_REG_ADDR)
> > + t_size = SDW_MAX_REG_ADDR - reg_command;
> > + else
> > + t_size = val_size;
>
> This needs at least some kind of comment?
I will add few comments here.
--
Re: [PATCH 1/2] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
Hi Rob, On Thu, Oct 27, 2016 at 2:46 AM, Rob Herring wrote: > On Wed, Oct 19, 2016 at 04:13:46PM +0530, Vivek Gautam wrote: >> PHY transceiver driver for QUSB2 phy controller that provides >> HighSpeed functionality for DWC3 controller present on >> Qualcomm chipsets. >> >> This driver is based on phy-msm-qusb driver available in >> msm-4.4 kernel @codeaurora[1] >> >> [1] >> https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18 >> >> Signed-off-by: Vivek Gautam >> Cc: Kishon Vijay Abraham I >> --- >> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 37 ++ > > It's preferred the bindings are a separate patch. Sure, will prepare a separate patch for bindings doc for both the phy patches. > >> drivers/phy/Kconfig| 10 + >> drivers/phy/Makefile | 1 + >> drivers/phy/phy-qcom-qusb2.c | 577 >> + >> 4 files changed, 625 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> create mode 100644 drivers/phy/phy-qcom-qusb2.c >> >> diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> new file mode 100644 >> index 000..97c9ce7 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt >> @@ -0,0 +1,37 @@ >> +Qualcomm QUSB2 phy controller >> += >> + >> +QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets. >> + >> +Required properties: >> + - compatible: compatible list, contains "qcom,msm8996-qusb2-phy". >> + - reg: offset and length of the PHY register set. >> + - #phy-cells: must be 0. >> + >> + - clocks: a list of phandles and clock-specifier pairs, >> +one for each entry in clock-names. >> + - clock-names: must be "cfg_ahb" for phy config clock, >> + "ref_clk" for 19.2 MHz ref clk, >> + "ref_clk_src" reference clock source. >> + "iface" for phy interface clock (Optional). >> + >> + - vdd-phy-supply: Phandle to a regulator supply to PHY core block. >> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll >> block. >> + - vdda-phy-dpdm: Phandle to 3.1V regulator supply to Dp/Dm port signals. >> + >> + - resets: a list of phandles and reset controller specifier pairs, >> +one for each entry in reset-names. >> + - reset-names: must be "phy" for reset of phy block. >> + >> +Optional properties: >> + - nvmem-cells: a list of phandles to nvmem cells that contain fused >> + tuning parameters for qusb2 phy, one for each entry >> + in nvmem-cell-names. >> + - nvmem-cell-names: must be "tune2_hstx_trim_efuse" for cell containing >> + HS Tx trim value. >> + - qcom,hstx-trim-bit-offset: bit offset within nvmem cell for >> + HS Tx trim value. >> + - qcom,hstx-trim-bit-len: bit length of HS Tx trim value within nvmem cell. > > When does this change? Why is it not just a different nvmem cell? This is per-controller bit fields. So for example, msm8996 that has couple of controllers, has these bits as a part of same cell of 32bits. Bits 21:24 for controller-1, and 25-28 for controller-2. I thought of using the 'reg' and 'bit' properties of nvmem cell, but was unsuccessful in using the same. Hi Srini, Can you please help me with this ? We have one register of 32 bits (representing one nvmem cell), that has the value for both the QUSB2 controllers. So, we just need to read the values that are placed in two different nibbles, for the two controllers, using nvmem cell device tree properties (may be 'reg' and 'bit' properties). Thanks Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] clk: fix link error for rcar-gen2
Hi Simon,
On Mon, Oct 31, 2016 at 10:52 AM, Simon Horman wrote:
> From: Simon Horman
> Subject: [PATCH] ARM: shmobile: only call rcar_gen2_clocks_init() if present
>
> The RZ/G1M (r8a7743) uses the R-Car Gen2 core, but not the R-Car Gen2 clock
> driver. This is a harbinger of a transition for R-Car Gen2 SoCs. As the
> process to get all the required pieces in place is somewhat complex it
> seems useful to try to disentangle dependencies where possible.
>
> The approach here is to temporarily disable calling rcar_gen2_clocks_init()
> if no R-Car Gen2 SoC are configured and thus the symbol will not be
> present.
>
> Fixes: 1254f607fc3d ("ARM: shmobile: r8a7743: basic SoC support")
> Signed-off-by: Simon Horman
> ---
>
> The current likely path to removing need for this is for
> "[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode
> pin state" to be accepted. In particular patch 20 removes the call to
> rcar_gen2_clocks_init() in rcar_gen2_timer_init().
> ---
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> index 875bcb8c1026..657262556dc4 100644
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> @@ -131,7 +131,13 @@ void __init rcar_gen2_timer_init(void)
> iounmap(base);
> #endif /* CONFIG_ARM_ARCH_TIMER */
>
> - rcar_gen2_clocks_init(mode);
> + if (IS_ENABLED(CONFIG_ARCH_R8A7790) ||
> + IS_ENABLED(CONFIG_ARCH_R8A7791) ||
> + IS_ENABLED(CONFIG_ARCH_R8A7792) ||
> + IS_ENABLED(CONFIG_ARCH_R8A7793) ||
> + IS_ENABLED(CONFIG_ARCH_R8A7794))
> + rcar_gen2_clocks_init(mode);
Upon second thought (triggered bySergei conflict notification), this needs
an else clause:
else
of_clk_init(NULL);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor
Hi! > >>I'll have to go through the patches, et8ek8 driver is probably not > >>enough to get useful video. platform/video-bus-switch.c is needed for > >>camera switching, then some omap3isp patches to bind flash and > >>autofocus into the subdevice. > >> > >>Then, device tree support on n900 can be added. > > > >I briefly discussed with with Sebastian. > > > >Do you think the elusive support for the secondary camera is worth keeping > >out the main camera from the DT in mainline? As long as there's a reasonable > >way to get it working, I'd just merge that. If someone ever gets the > >secondary camera working properly and nicely with the video bus switch, > >that's cool, we'll somehow deal with the problem then. But frankly I don't > >think it's very useful even if we get there: the quality is really bad. > > > > Yes, lets merge what we have till now, it will be way easier to improve on > it once it is part of the mainline. > > BTW, I have (had) patched VBS working almost without problems, when it comes > to it I'll dig it. Do you have a version that switches on runtime? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor
On 2.11.2016 10:15, Pavel Machek wrote: Hi! I'll have to go through the patches, et8ek8 driver is probably not enough to get useful video. platform/video-bus-switch.c is needed for camera switching, then some omap3isp patches to bind flash and autofocus into the subdevice. Then, device tree support on n900 can be added. I briefly discussed with with Sebastian. Do you think the elusive support for the secondary camera is worth keeping out the main camera from the DT in mainline? As long as there's a reasonable way to get it working, I'd just merge that. If someone ever gets the secondary camera working properly and nicely with the video bus switch, that's cool, we'll somehow deal with the problem then. But frankly I don't think it's very useful even if we get there: the quality is really bad. Yes, lets merge what we have till now, it will be way easier to improve on it once it is part of the mainline. BTW, I have (had) patched VBS working almost without problems, when it comes to it I'll dig it. Do you have a version that switches on runtime? Best regards, Pavel IIRC yes, but I might be wrong, it was a while I was playing with it. Ivo
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
Hi! > >> >> Better then previous one. > >> >> > >> >> But my version of bq27xxx_battery.c already contains this: > >> > > >> > This is for allowing udev rule to set the properties as well. > >> > otherwise a kinda crude RUN = " echo value > > >> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required. > >> > >> Any thoughts on this? > > > > I'd say echo value > > > /sys/module/bq27xxx_battery/parameters/poll_interval .. is quite > > adequate solution...? > > > > Alternatively, convince us that something else is useful for everyone, > > and we can do the right thing (poll more often when battery is nearly > > empty), automatically... > > Ok should have had the patchset set it per device, and not use the > global poll_interval. Of need to add some logic to see if uses the > global poll_interval or it's own setting. > > There are times where you could have multiple batteries connected to > multiple fuel gauges, and want to up the polling interval on certain > ones that are discharging at different rates. > > But of course I'll let you guys let me know if this seems useful at all. I agree per-device polling would be cleaner. But unless you have hardware with more than one bq27xxx, I'd avoid the work... Now... its also possible that poll_interval should change itself (within kernel) to do the right thing. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v3] drm: bridge: add DesignWare HDMI I2S audio support
On Wed, Nov 02, 2016 at 01:18:35AM +, Kuninori Morimoto wrote: > + platform = platform_device_register_full(&pdevinfo); > + if (IS_ERR_OR_NULL(platform)) > + return PTR_ERR(platform); This is wrong. If platform is NULL, PTR_ERR() will return zero, which will be interpreted as success. Please, avoid using IS_ERR_OR_NULL(), it leads to exactly this kind of cockup - and it's unnecessary here because platform_device_register_full() does not return NULL. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH 4/6] g_NCR5380: Add IRQ auto-configuration for HP C2502
On Wednesday 02 November 2016, Finn Thain wrote:
> On Mon, 31 Oct 2016, Ondrej Zary wrote:
> > Find free and working IRQ automatically on HP C2502 cards.
> > Also allow IRQ 9 to work (aliases to IRQ 2 on the card).
> >
> > Signed-off-by: Ondrej Zary
> > ---
> > drivers/scsi/g_NCR5380.c | 29 +++--
> > 1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> > index e713dba..27fc499 100644
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -156,6 +156,8 @@ static void magic_configure(int idx, u8 irq, u8
> > magic[]) outb(magic[4], 0x379);
> >
> > /* allowed IRQs for HP C2502 */
> > + if (irq == 9)
> > + irq = 2;
> > if (irq != 2 && irq != 3 && irq != 4 && irq != 5 && irq != 7)
> > irq = 0;
> > if (idx >= 0 && idx <= 7)
> > @@ -163,6 +165,21 @@ static void magic_configure(int idx, u8 irq, u8
> > magic[]) outb(cfg, 0x379);
> > }
> >
> > +/* find a free and working IRQ (for HP C2502) */
> > +static int NCR5380_find_irq(struct Scsi_Host *instance, u8 irqs[],
> > + int port_idx, u8 magic[])
> > +{
> > + int i;
> > +
> > + for (i = 0; irqs[i]; i++) {
> > + magic_configure(port_idx, irqs[i], magic);
> > + if (NCR5380_test_irq(instance, irqs[i]) == 0)
> > + return irqs[i];
>
> The NCR5380_test_irq routine in patch 2/6 doesn't work for shared irqs, so
> you may not get the IRQ you would expect. (The core driver does support
> shared irqs, BTW.)
ISA bus does not support IRQ sharing.
> Also, you've ignored the irq module parameters. From the user's point of
> view, surely the least surprising thing is to attempt to configure the
> card for whatever irq the user asked for.
I haven't. NCR5380_find_irq is only called when irq is set to IRQ_AUTO.
> If the specified irq isn't supported by the board, just log an error and
> fail. If you want to be user friendly, print a message to tell them what
> irqs the card supports.
If the IRQ is not supported (or does not work), user gets a warning and the
driver continues with IRQ disabled.
> If the user asks for IRQ_AUTO, just configure the board for a hard-coded
> default, say 9, and print a warning message to say so.
The card is almost Plug&Play. The base address is already configured
automatically by the driver so doing the same for IRQ makes sense.
> Either way, if request_irq fails just continue with NO_IRQ, as per usual.
>
> To me that's the most flexible and least surprising behaviour. But again,
> if someone with more ISA knowledge wishes to weigh in, that's fine too.
>
> > + }
> > + magic_configure(port_idx, 0, magic);
> > + return NO_IRQ;
> > +}
> > +
> > static unsigned int ncr_53c400a_ports[] = {
> > 0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350, 0
> > };
> > @@ -175,6 +192,9 @@ static void magic_configure(int idx, u8 irq, u8
> > magic[]) static u8 hp_c2502_magic[] = { /* HP C2502 */
> > 0x0f, 0x22, 0xf0, 0x20, 0x80
> > };
> > +static u8 hp_c2502_irqs[] = {
> > + 9, 5, 7, 3, 4, 0
> > +};
> >
> > static int generic_NCR5380_init_one(struct scsi_host_template *tpnt,
> > struct device *pdev, int base, int irq, int board)
> > @@ -345,8 +365,13 @@ static int generic_NCR5380_init_one(struct
> > scsi_host_template *tpnt,
> >
> > if (irq != IRQ_AUTO)
> > instance->irq = irq;
> > - else
> > - instance->irq = NCR5380_probe_irq(instance);
> > + else {
> > + if (board == BOARD_HP_C2502)
> > + instance->irq = NCR5380_find_irq(instance,
> > + hp_c2502_irqs, port_idx, magic);
> > + else
> > + instance->irq = NCR5380_probe_irq(instance);
> > + }
> >
> > /* Compatibility with documented NCR5380 kernel parameters */
> > if (instance->irq == 255)
--
Ondrej Zary
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read()
On Tue, Nov 01, 2016 at 05:39:40PM +0100, Jan Kara wrote:
> On Mon 31-10-16 21:10:35, Kirill A. Shutemov wrote:
> > > If I understand the motivation right, it is mostly about being able to
> > > mmap
> > > PMD-sized chunks to userspace. So my naive idea would be that we could
> > > just
> > > implement it by allocating PMD sized chunks of pages when adding pages to
> > > page cache, we don't even have to read them all unless we come from PMD
> > > fault path.
> >
> > Well, no. We have one PG_{uptodate,dirty,writeback,mappedtodisk,etc}
> > per-hugepage, one common list of buffer heads...
> >
> > PG_dirty and PG_uptodate behaviour inhered from anon-THP (where handling
> > it otherwise doesn't make sense) and handling it differently for file-THP
> > is nightmare from maintenance POV.
>
> But the complexity of two different page sizes for page cache and *each*
> filesystem that wants to support it does not make the maintenance easy
> either.
I think with time we can make small pages just a subcase of huge pages.
And some generalization can be made once more than one filesystem with
backing storage will adopt huge pages.
> So I'm not convinced that using the same rules for anon-THP and
> file-THP is a clear win.
We already have file-THP with the same rules: tmpfs. Backing storage is
what changes the picture.
> And if we have these two options neither of which has negligible
> maintenance cost, I'd also like to see more justification for why it is
> a good idea to have file-THP for normal filesystems. Do you have any
> performance numbers that show it is a win under some realistic workload?
See below. As usual with huge pages, they make sense when you plenty of
memory.
> I'd also note that having PMD-sized pages has some obvious disadvantages as
> well:
>
> 1) I'm not sure buffer head handling code will quite scale to 512 or even
> 2048 buffer_heads on a linked list referenced from a page. It may work but
> I suspect the performance will suck.
Yes, buffer_head list doesn't scale. That's the main reason (along with 4)
why syscall-based IO sucks. We spend a lot of time looking for desired
block.
We need to switch to some other data structure for storing buffer_heads.
Is there a reason why we have list there in first place?
Why not just array?
I will look into it, but this sounds like a separate infrastructure change
project.
> 2) PMD-sized pages result in increased space & memory usage.
Space? Do you mean disk space? Not really: we still don't write beyond
i_size or into holes.
Behaviour wrt to holes may change with mmap()-IO as we have less
granularity, but the same can be seen just between different
architectures: 4k vs. 64k base page size.
> 3) In ext4 we have to estimate how much metadata we may need to modify when
> allocating blocks underlying a page in the worst case (you don't seem to
> update this estimate in your patch set). With 2048 blocks underlying a page,
> each possibly in a different block group, it is a lot of metadata forcing
> us to reserve a large transaction (not sure if you'll be able to even
> reserve such large transaction with the default journal size), which again
> makes things slower.
I didn't saw this on profiles. And xfstests looks fine. I probably need to
run them with 1k blocks once again.
> 4) As you have noted some places like write_begin() still depend on 4k
> pages which creates a strange mix of places that use subpages and that use
> head pages.
Yes, this need to be addressed to restore syscall-IO performance and take
advantage of huge pages.
But again, it's an infrastructure change that would likely affect
interface between VFS and filesystems. It deserves a separate patchset.
> All this would be a non-issue (well, except 2 I guess) if we just didn't
> expose filesystems to the fact that something like file-THP exists.
The numbers below generated with fio. The working set is relatively small,
so it fits into page cache and writing set doesn't hit dirty_ratio.
I think the mmap performance should be enough to justify initial inclusion
of an experimental feature: it useful for workloads that targets mmap()-IO.
It will take time to get feature mature anyway.
Configuration:
- 2x E5-2697v2, 64G RAM;
- INTEL SSDSC2CW24;
- IO request size is 4k;
- 8 processes, 512MB data set each;
Workload
read/write baselinestddev huge=always stddev change
sync-read
read 21439.00 348.1420297.33 259.62 -5.33%
sync-write
write 6833.20 147.08 3630.13 52.86 -46.88%
sync-readwrite
read 4377.17 17.53 2366.33 19.52 -45.94%
write 4378.50 17.83 2365.80 19.94 -45.97%
sync-randread
read 5491.20 66.6614664.00 288.29 167.05%
sync-randwrite
write 6396.13 98.79 2035.80
Re: [PATCH v1] iio: adc: at91: add suspend and resume callback
On Wed, Nov 02, 2016 at 10:40:16AM +0800, Wenyou Yang wrote:
> Add suspend/resume callback, support the pinctrl sleep state when
> the system suspend as well.
>
> Signed-off-by: Wenyou Yang
> ---
>
> drivers/iio/adc/at91_adc.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index bbdac07..ffa81a1 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> /* Registers */
> #define AT91_ADC_CR 0x00/* Control Register */
> @@ -1347,6 +1348,39 @@ static int at91_adc_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM
I would use CONFIG_PM_SLEEP
> +static int at91_adc_suspend(struct device *dev)
> +{
> + struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
> + struct at91_adc_state *st = iio_priv(idev);
> +
> + pinctrl_pm_select_sleep_state(dev);
> + clk_disable_unprepare(st->clk);
> +
> + return 0;
> +}
> +
> +static int at91_adc_resume(struct device *dev)
> +{
> + struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
> + struct at91_adc_state *st = iio_priv(idev);
> +
> + clk_prepare_enable(st->clk);
> + pinctrl_pm_select_default_state(dev);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops at91_adc_pm_ops = {
> + .suspend = at91_adc_suspend,
> + .resume = at91_adc_resume,
> +};
> +
> +#define AT91_ADC_PM_OPS (&at91_adc_pm_ops)
> +#else
> +#define AT91_ADC_PM_OPS NULL
> +#endif
> +
and this macro: SET_SYSTEM_SLEEP_PM_OPS
Regards
Ludovic
> static struct at91_adc_caps at91sam9260_caps = {
> .calc_startup_ticks = calc_startup_ticks_9260,
> .num_channels = 4,
> @@ -1441,6 +1475,7 @@ static struct platform_driver at91_adc_driver = {
> .driver = {
> .name = DRIVER_NAME,
> .of_match_table = of_match_ptr(at91_adc_dt_ids),
> + .pm = AT91_ADC_PM_OPS,
> },
> };
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/6] Advantech iManager EC driver set
The Advantech iManager is a custom embedded controller based on ITE IT8518 or IT8528 EC (depending on PCB). It runs a custom firmware that provides access to features such as GPIO, I2C/SMbus, hwmon, watchdog, and backlight/brightness control. All drivers are being managed by the iManager (mfd) core driver. It acts as a 'gateway' and handles communications between EC and sub-drivers. The imanager-core follows a similar concept as Kontron's kempld-core driver. During core init, the device id list is retrieved from the firmware and an internal device list is being created. This list is then passed down to managed drivers. The out-of-tree iManager driver set is maintained at https://www.github.com/rvido/iManager Notebook manufactures such as Dell (XPS series) or Razerzone (Razer Blade) are using similar ITE ECs or even the same ones to implement their own embedded functions. Due to the level of firmware customization which those ITE ECs provide, the iManager EC driver set is incompatible with those vendors solutions (and probably others too). Note that v1..v3 were submitted in Jan. 2016. It took some time to apply suggested changes. However, I kept the original versioning to avoid conflict with previous patch submissions. Thanks to Krzysztof Kozłowski, Guenter Roeck, and Lee Jones for their invaluable feedback. Those drivers clearly needed to be further improved and cleaned. Changes from v3: - Merge imanager-ec-* with corresponding drivers This eliminates static init vars and reduces code size - Remove Documentation/devicetree/bindings/mfd/imanager.txt No support for DT - Add API comments - List include files in alphabetic order - Run patches through ./scripts/checkpatch.pl --strict - Remove headers except imanger.h/imanager-ec.h Store them in include/linux/mfd/ imanager-core: - Reduce amount of exported functions in core - Use usleep_range() instead of udelay() - Use dev_info() or dev_warn() where necessary - Fix register/probing and __init/__exit - Optimize imanager_read_device_config() - Shrink down EC device table to known and supported devices - Define flags with BIT() - Use new imanager device struct i2c-imanager: - Add support for multiple I2C/SMbus adapters - Use new imanager device struct imanager-hwmon-* gpio-imanager: imanager_bl: imanager_wdt: - Define flags with BIT() - Use new imanager device struct Changes from v2: - Remove .owner from platform_driver in: drivers/gpio/imanager-bl drivers/gpio/imanager-core.c drivers/gpio/imanager-i2c.c drivers/gpio/imanager-hwmon.c Changes from v1: - Remove .owner from platform_driver in drivers/gpio/imanager-gpio.c - Remove .owner from platform_driver in drivers/gpio/imanager-wdt.c - Replace 2015 by 2016 in all files Richard Vidal-Dorsch (6): Add Advantech iManager MFD core driver Add Advantech iManager GPIO driver Add Advantech iManager HWmon driver Add Advantech iManager I2C driver Add Advantech iManager Backlight driver Add Advantech iManager Watchdog driver drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-imanager.c | 155 + drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile|1 + drivers/hwmon/imanager-hwmon.c| 1226 + drivers/i2c/busses/Kconfig| 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-imanager.c | 461 + drivers/mfd/Kconfig | 18 + drivers/mfd/Makefile |1 + drivers/mfd/imanager-core.c | 941 + drivers/video/backlight/Kconfig |8 + drivers/video/backlight/Makefile |1 + drivers/video/backlight/imanager_bl.c | 210 ++ drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile |1 + drivers/watchdog/imanager_wdt.c | 303 include/linux/mfd/imanager-ec.h | 228 ++ include/linux/mfd/imanager.h | 221 ++ 20 files changed, 3819 insertions(+) create mode 100644 drivers/gpio/gpio-imanager.c create mode 100644 drivers/hwmon/imanager-hwmon.c create mode 100644 drivers/i2c/busses/i2c-imanager.c create mode 100644 drivers/mfd/imanager-core.c create mode 100644 drivers/video/backlight/imanager_bl.c create mode 100644 drivers/watchdog/imanager_wdt.c create mode 100644 include/linux/mfd/imanager-ec.h create mode 100644 include/linux/mfd/imanager.h -- 2.10.1
Re: [PATCH] clk: fix link error for rcar-gen2
On Wed, Nov 02, 2016 at 09:14:02AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Mon, Oct 31, 2016 at 10:52 AM, Simon Horman wrote:
> > From: Simon Horman
> > Subject: [PATCH] ARM: shmobile: only call rcar_gen2_clocks_init() if present
> >
> > The RZ/G1M (r8a7743) uses the R-Car Gen2 core, but not the R-Car Gen2 clock
> > driver. This is a harbinger of a transition for R-Car Gen2 SoCs. As the
> > process to get all the required pieces in place is somewhat complex it
> > seems useful to try to disentangle dependencies where possible.
> >
> > The approach here is to temporarily disable calling rcar_gen2_clocks_init()
> > if no R-Car Gen2 SoC are configured and thus the symbol will not be
> > present.
> >
> > Fixes: 1254f607fc3d ("ARM: shmobile: r8a7743: basic SoC support")
> > Signed-off-by: Simon Horman
> > ---
> >
> > The current likely path to removing need for this is for
> > "[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode
> > pin state" to be accepted. In particular patch 20 removes the call to
> > rcar_gen2_clocks_init() in rcar_gen2_timer_init().
> > ---
> > arch/arm/mach-shmobile/setup-rcar-gen2.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > index 875bcb8c1026..657262556dc4 100644
> > --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > @@ -131,7 +131,13 @@ void __init rcar_gen2_timer_init(void)
> > iounmap(base);
> > #endif /* CONFIG_ARM_ARCH_TIMER */
> >
> > - rcar_gen2_clocks_init(mode);
> > + if (IS_ENABLED(CONFIG_ARCH_R8A7790) ||
> > + IS_ENABLED(CONFIG_ARCH_R8A7791) ||
> > + IS_ENABLED(CONFIG_ARCH_R8A7792) ||
> > + IS_ENABLED(CONFIG_ARCH_R8A7793) ||
> > + IS_ENABLED(CONFIG_ARCH_R8A7794))
> > + rcar_gen2_clocks_init(mode);
>
> Upon second thought (triggered bySergei conflict notification), this needs
> an else clause:
>
> else
> of_clk_init(NULL);
Thanks, I will add that.
[PATCH v4 6/6] Add Advantech iManager Watchdog driver
Signed-off-by: Richard Vidal-Dorsch
---
drivers/watchdog/Kconfig| 11 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imanager_wdt.c | 303
3 files changed, 315 insertions(+)
create mode 100644 drivers/watchdog/imanager_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fdd3228..d6859da 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -912,6 +912,17 @@ config WAFER_WDT
To compile this driver as a module, choose M here: the
module will be called wafer5823wdt.
+config IMANAGER_WDT
+ tristate "Advantech iManager Watchdog"
+ depends on MFD_IMANAGER
+ select WATCHDOG_CORE
+ help
+ Support for Advantech iManager watchdog on some Advantech
+ SOM, MIO, AIMB, and PCM modules/boards.
+
+ This driver can also be built as a module. If so, the module
+ will be called imanager_wdt.
+
config I6300ESB_WDT
tristate "Intel 6300ESB Timer/Watchdog"
depends on PCI
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index caa9f4a..eb7fccf 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -117,6 +117,7 @@ endif
obj-$(CONFIG_IT8712F_WDT) += it8712f_wdt.o
obj-$(CONFIG_IT87_WDT) += it87_wdt.o
obj-$(CONFIG_HP_WATCHDOG) += hpwdt.o
+obj-$(CONFIG_IMANAGER_WDT) += imanager_wdt.o
obj-$(CONFIG_KEMPLD_WDT) += kempld_wdt.o
obj-$(CONFIG_SC1200_WDT) += sc1200wdt.o
obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o
diff --git a/drivers/watchdog/imanager_wdt.c b/drivers/watchdog/imanager_wdt.c
new file mode 100644
index 000..53b409e
--- /dev/null
+++ b/drivers/watchdog/imanager_wdt.c
@@ -0,0 +1,303 @@
+/*
+ * Advantech iManager Watchdog driver
+ *
+ * Copyright (C) 2016 Advantech Co., Ltd.
+ * Author: Richard Vidal-Dorsch
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define WDT_DEFAULT_TIMEOUT30 /* seconds */
+#define WDT_FREQ 10 /* Hz */
+
+struct imanager_wdt_data {
+ struct imanager_device_data *imgr;
+ struct watchdog_device wdt;
+ ulong last_updated;
+ uint timeout;
+};
+
+static uint timeout = WDT_DEFAULT_TIMEOUT;
+module_param(timeout, uint, 0444);
+MODULE_PARM_DESC(timeout,
+"Watchdog timeout in seconds. 1 <= timeout <= 65534, default="
+__MODULE_STRING(WDT_DEFAULT_TIMEOUT) ".");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0444);
+MODULE_PARM_DESC(nowayout,
+"Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+enum wdt_ctrl {
+ START = 1, STOP, RESET, GET_TIMEOUT, SET_TIMEOUT, STOPBOOT = 8
+};
+
+enum imanager_wdt_event {
+ WDT_EVT_NONE,
+ WDT_EVT_DELAY,
+ WDT_EVT_PWRBTN,
+ WDT_EVT_NMI,
+ WDT_EVT_RESET,
+ WDT_EVT_WDPIN,
+ WDT_EVT_SCI,
+};
+
+struct event_delay {
+ u16 delay,
+ pwrbtn,
+ nmi,
+ reset,
+ wdpin,
+ sci,
+ dummy;
+} __attribute__((__packed__));
+
+static int imanager_wdt_ctrl(struct imanager_ec_data *ec, int ctrl,
+int event_type, uint timeout)
+{
+ struct imanager_ec_message msg = {
+ IMANAGER_MSG_SIMPLE(0, 0, ctrl, NULL)
+ };
+ u8 *fevent = &msg.u.data[0];
+ struct event_delay *event = (struct event_delay *)&msg.u.data[1];
+ int val;
+
+ if (ctrl == SET_TIMEOUT) {
+ memset(event, 0xff, sizeof(*event));
+ msg.wlen = sizeof(*event);
+ *fevent = 0;
+ val = (!timeout) ? 0x : cpu_to_be16(timeout * WDT_FREQ);
+
+ switch (event_type) {
+ case WDT_EVT_DELAY:
+ event->delay = val;
+ break;
+ case WDT_EVT_PWRBTN:
+ event->pwrbtn = val;
+ break;
+ case WDT_EVT_NMI:
+ event->nmi = val;
+ break;
+ case WDT_EVT_RESET:
+ event->reset = val;
+ break;
+ case WDT_EVT_WDPIN:
+ event->wdpin = val;
+ break;
+ case WDT_EVT_SCI:
+ event->sci = val;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+
+ return imanager_write(ec, EC_CMD_WDT_CTRL, &msg);
+}
+
+static i
[PATCH v4 5/6] Add Advantech iManager Backlight driver
Signed-off-by: Richard Vidal-Dorsch
---
drivers/video/backlight/Kconfig | 8 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/imanager_bl.c | 210 ++
3 files changed, 219 insertions(+)
create mode 100644 drivers/video/backlight/imanager_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..2dac696 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -251,6 +251,14 @@ config BACKLIGHT_HP700
If you have an HP Jornada 700 series,
say Y to include backlight control driver.
+config BACKLIGHT_IMANAGER
+ tristate "Advantech iManager Backlight/Brightness"
+ depends on MFD_IMANAGER
+ help
+ This enables support for Advantech iManager Backlight and
+ Brightness control of some Advantech SOM, MIO, AIMB, and
+ PCM modules/boards.
+
config BACKLIGHT_CARILLO_RANCH
tristate "Intel Carillo Ranch Backlight Driver"
depends on LCD_CLASS_DEVICE && PCI && X86 && FB_LE80578
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..713b406 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_BACKLIGHT_GENERIC) += generic_bl.o
obj-$(CONFIG_BACKLIGHT_GPIO) += gpio_backlight.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
+obj-$(CONFIG_BACKLIGHT_IMANAGER) += imanager_bl.o
obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
diff --git a/drivers/video/backlight/imanager_bl.c
b/drivers/video/backlight/imanager_bl.c
new file mode 100644
index 000..d8b4e3d
--- /dev/null
+++ b/drivers/video/backlight/imanager_bl.c
@@ -0,0 +1,210 @@
+/*
+ * Advantech iManager Backlight driver
+ * Partially derived from wm831x_bl
+ *
+ * Copyright (C) 2016 Advantech Co., Ltd.
+ * Author: Richard Vidal-Dorsch
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BL_MAX_PWM 100
+
+enum backlight_units { BL_UNIT_1 = 0, BL_UNIT_2 };
+
+static bool polarity = PWM_POLARITY_NORMAL;
+module_param(polarity, bool, 0444);
+MODULE_PARM_DESC(polarity, "Select backlight polarity (inverted := 1)");
+
+static ushort unit = BL_UNIT_1;
+module_param(unit, ushort, 0444);
+MODULE_PARM_DESC(unit, "Select backlight control unit [0, 1] (defaults to 0)");
+
+struct imanager_backlight_data {
+ struct imanager_device_data *imgr;
+};
+
+struct brightness_level {
+ uint value : 7,/* Brightness Value - LSB [6..0] */
+enable : 1;/* Brightness Enable - MSB [7] */
+};
+
+struct backlight_ctrl {
+ uint enable : 1,/* Backlight Control Enable - LSB [0] */
+pwmpol : 1,/* PWM Polarity - bit [1] */
+blpol : 1,/* Backlight Polarity - bit [2] */
+dnc: 5;/* Don't care - bit [7..3] */
+};
+
+static int imanager_bl_enable(struct imanager_ec_data *ec, int unit)
+{
+ u8 val8;
+ struct brightness_level *ctrl = (struct brightness_level *)&val8;
+ u8 devid = ec->bl.attr[unit]->did;
+ u8 bl_unit = ec->bl.brightness[unit];
+ int ret;
+
+ ret = imanager_read_ram(ec, EC_RAM_ACPI, bl_unit, &val8, sizeof(val8));
+ if (ret < 0)
+ return ret;
+
+ ctrl->enable = 1;
+
+ return imanager_write_ram(ec, EC_RAM_ACPI, devid, &val8, sizeof(val8));
+}
+
+static int imanager_bl_set_polarity(struct imanager_ec_data *ec, uint polarity)
+{
+ u8 val8;
+ struct backlight_ctrl *ctrl = (struct backlight_ctrl *)&val8;
+ int ret;
+
+ ret = imanager_read_ram(ec, EC_RAM_ACPI, EC_OFFSET_BACKLIGHT_CTRL,
+ &val8, sizeof(val8));
+ if (ret < 0)
+ return ret;
+
+ ctrl->blpol = polarity ? 1 : 0;
+
+ return imanager_write_ram(ec, EC_RAM_ACPI, EC_OFFSET_BACKLIGHT_CTRL,
+ &val8, sizeof(val8));
+}
+
+static int imanager_bl_get_brightness(struct backlight_device *bd)
+{
+ struct imanager_backlight_data *data = bl_get_data(bd);
+ struct imanager_device_data *imgr = data->imgr;
+ u8 devid = imgr->ec.bl.attr[unit]->did;
+ int pwm;
+
+ mutex_lock(&imgr->lock);
+
+ pwm = imanager_read8(&imgr->ec, EC_CMD_HWP_RD, devid);
+ if (pwm < 0) {
+ dev
[PATCH v4 2/6] Add Advantech iManager GPIO driver
Signed-off-by: Richard Vidal-Dorsch
---
drivers/gpio/Kconfig | 10 +++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-imanager.c | 155 +++
3 files changed, 166 insertions(+)
create mode 100644 drivers/gpio/gpio-imanager.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d011cb8..52e371f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -884,6 +884,16 @@ config HTC_EGPIO
several HTC phones. It provides basic support for input
pins, output pins, and irqs.
+config GPIO_IMANAGER
+ tristate "Advantech iManager GPIO"
+ depends on MFD_IMANAGER
+ help
+ This enables support for the iManager GPIO interface on some
+ Advantech SOM, MIO, AIMB, and PCM modules/boards.
+
+ This driver can also be built as a module. If so, the module will be
+ called gpio-imanager.
+
config GPIO_JANZ_TTL
tristate "Janz VMOD-TTL Digital IO Module"
depends on MFD_JANZ_CMODIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ab28a2d..e1250eb 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_GPIO_GPIO_MM)+= gpio-gpio-mm.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
obj-$(CONFIG_HTC_EGPIO)+= gpio-htc-egpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
+obj-$(CONFIG_GPIO_IMANAGER)+= gpio-imanager.o
obj-$(CONFIG_GPIO_IOP) += gpio-iop.o
obj-$(CONFIG_GPIO_IT87)+= gpio-it87.o
obj-$(CONFIG_GPIO_JANZ_TTL)+= gpio-janz-ttl.o
diff --git a/drivers/gpio/gpio-imanager.c b/drivers/gpio/gpio-imanager.c
new file mode 100644
index 000..f60592b
--- /dev/null
+++ b/drivers/gpio/gpio-imanager.c
@@ -0,0 +1,155 @@
+/*
+ * Advantech iManager GPIO driver
+ *
+ * Copyright (C) 2016 Advantech Co., Ltd.
+ * Author: Richard Vidal-Dorsch
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EC_GPIOF_DIR_OUT BIT(6)
+#define EC_GPIOF_DIR_INBIT(7)
+
+struct imanager_gpio_data {
+ struct imanager_device_data *imgr;
+ struct gpio_chip chip;
+};
+
+static int imanager_gpio_direction_in(struct gpio_chip *chip, uint offset)
+{
+ struct imanager_gpio_data *data = gpiochip_get_data(chip);
+ struct imanager_device_data *imgr = data->imgr;
+ struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
+
+ mutex_lock(&imgr->lock);
+ imanager_write8(&imgr->ec, EC_CMD_GPIO_DIR_WR, attr->did,
+ EC_GPIOF_DIR_IN);
+ mutex_unlock(&imgr->lock);
+
+ return 0;
+}
+
+static int
+imanager_gpio_direction_out(struct gpio_chip *chip, uint offset, int val)
+{
+ struct imanager_gpio_data *data = gpiochip_get_data(chip);
+ struct imanager_device_data *imgr = data->imgr;
+ struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
+
+ mutex_lock(&imgr->lock);
+ imanager_write8(&imgr->ec, EC_CMD_GPIO_DIR_WR, attr->did,
+ EC_GPIOF_DIR_OUT);
+ mutex_unlock(&imgr->lock);
+
+ return 0;
+}
+
+static int imanager_gpio_get_direction(struct gpio_chip *chip, uint offset)
+{
+ struct imanager_gpio_data *data = gpiochip_get_data(chip);
+ struct imanager_device_data *imgr = data->imgr;
+ struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
+ int ret;
+
+ mutex_lock(&imgr->lock);
+ ret = imanager_read8(&imgr->ec, EC_CMD_GPIO_DIR_RD, attr->did);
+ mutex_unlock(&imgr->lock);
+
+ return ret & EC_GPIOF_DIR_IN ? GPIOF_DIR_IN : GPIOF_DIR_OUT;
+}
+
+static int imanager_gpio_get(struct gpio_chip *chip, uint offset)
+{
+ struct imanager_gpio_data *data = gpiochip_get_data(chip);
+ struct imanager_device_data *imgr = data->imgr;
+ struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
+ int ret;
+
+ mutex_lock(&imgr->lock);
+ ret = imanager_read8(&imgr->ec, EC_CMD_HWP_RD, attr->did);
+ mutex_unlock(&imgr->lock);
+
+ return ret;
+}
+
+static void imanager_gpio_set(struct gpio_chip *chip, uint offset, int val)
+{
+ struct imanager_gpio_data *data = gpiochip_get_data(chip);
+ struct imanager_device_data *imgr = data->imgr;
+ struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
+
+ mutex_lock(&imgr->lock);
+ imanager_write8(&imgr->ec, EC_CMD_HWP_WR, attr->did, val);
+ mutex_unlock(&imgr->lock);
+}
+
+static int imanager_gpio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct imana
[PATCH v4 1/6] Add Advantech iManager MFD core driver
This patch adds Advantech iManager Embedded Controller MFD core driver.
This mfd core dirver provides an interface for GPIO, I2C, HWmon,
Watchdog, and Backlight/Brightness control.
Signed-off-by: Richard Vidal-Dorsch
---
drivers/mfd/Kconfig | 18 +
drivers/mfd/Makefile| 1 +
drivers/mfd/imanager-core.c | 941
include/linux/mfd/imanager-ec.h | 228 ++
include/linux/mfd/imanager.h| 221 ++
5 files changed, 1409 insertions(+)
create mode 100644 drivers/mfd/imanager-core.c
create mode 100644 include/linux/mfd/imanager-ec.h
create mode 100644 include/linux/mfd/imanager.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df644..294c19d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -388,6 +388,24 @@ config MFD_INTEL_QUARK_I2C_GPIO
their respective IO driver.
The GPIO exports a total amount of 8 interrupt-capable GPIOs.
+config MFD_IMANAGER
+ tristate "Advantech iManager EC device"
+ select MFD_CORE
+ help
+ This is the core driver for Advantech iManager Embedded Controller
+ found on some Advantech SOM, MIO, AIMB, and PCM modules/boards. The
+ EC may provide functions like GPIO, I2C bus, HW monitoring, Watchdog,
+ and backlight/brightness control.
+
+ The following Advantech boards are supported:
+ * All SOM modules newer than SOM-5788
+ * MIO-5250/5251/5270/5271/5272/5290 and newer
+ * PCM-9389/9365/9376 and newer
+ * AIMB-273/274/230/231 and newer
+
+ This driver can also be built as a module. If so, the module
+ will be called imanager-core.
+
config LPC_ICH
tristate "Intel ICH LPC"
depends on PCI
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9834e66..e4b0a4d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -156,6 +156,7 @@ obj-$(CONFIG_MFD_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_AB8500_CORE) += ab8500-core.o ab8500-sysctrl.o
obj-$(CONFIG_MFD_TIMBERDALE)+= timberdale.o
obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
+obj-$(CONFIG_MFD_IMANAGER) += imanager-core.o
obj-$(CONFIG_MFD_KEMPLD) += kempld-core.o
obj-$(CONFIG_MFD_INTEL_QUARK_I2C_GPIO) += intel_quark_i2c_gpio.o
obj-$(CONFIG_LPC_SCH) += lpc_sch.o
diff --git a/drivers/mfd/imanager-core.c b/drivers/mfd/imanager-core.c
new file mode 100644
index 000..2ec1b79
--- /dev/null
+++ b/drivers/mfd/imanager-core.c
@@ -0,0 +1,941 @@
+/*
+ * Advantech iManager MFD driver
+ * Partially derived from kempld-core
+ *
+ * Copyright (C) 2016 Advantech Co., Ltd.
+ * Author: Richard Vidal-Dorsch
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum kinds { IT8518, IT8528 };
+
+static struct platform_device *imanager_pdev;
+
+static const char * const chip_names[] = {
+ "it8518",
+ "it8528",
+ NULL
+};
+
+static const struct imanager_ec_device ecdev_table[] = {
+ /* GPIO */
+ { IMANAGER_EC_DEVICE(GPIO0, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO1, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO2, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO3, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO4, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO5, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO6, GPIO, -1) },
+ { IMANAGER_EC_DEVICE(GPIO7, GPIO, -1) },
+ /* FAN */
+ { IMANAGER_EC_DEVICE(CPUFAN_2P, PWM, 2) },
+ { IMANAGER_EC_DEVICE(CPUFAN_4P, PWM, 4) },
+ { IMANAGER_EC_DEVICE(SYSFAN1_2P, PWM, 2) },
+ { IMANAGER_EC_DEVICE(SYSFAN1_4P, PWM, 4) },
+ { IMANAGER_EC_DEVICE(SYSFAN2_2P, PWM, 2) },
+ { IMANAGER_EC_DEVICE(SYSFAN2_4P, PWM, 4) },
+ /* ADC */
+ { IMANAGER_EC_DEVICE(ADC12VS0,ADC, 1) },
+ { IMANAGER_EC_DEVICE(ADC12VS0_2, ADC, 2) },
+ { IMANAGER_EC_DEVICE(ADC12VS0_10, ADC, 10) },
+ { IMANAGER_EC_DEVICE(ADC5VS0, ADC, 1) },
+ { IMANAGER_EC_DEVICE(ADC5VS0_2, ADC, 2) },
+ { IMANAGER_EC_DEVICE(ADC5VS0_10, ADC, 10) },
+ { IMANAGER_EC_DEVICE(ADC5VS5, ADC, 1) },
+ { IMANAGER_EC_DEVICE(ADC5VS5_2, ADC, 2) },
+ { IMANAGER_EC_DEVICE(ADC5VS5_10, ADC, 10) },
+ { IMANAGER_EC_DEVICE(ADC33VS0,ADC, 1) },
+ { IMANAGER_EC_DEVICE(ADC33VS0_2, ADC, 2) },
+ { IMANAGER_EC_DEVICE(ADC33VS0_10, ADC, 10) },
+ { IMANAGER_EC_DEVICE(CMOSBAT, ADC, 1) },
+ { IMANAGER_EC_DEVICE(CMOSBAT_2, ADC, 2) },
+ { IMANAGER_EC_DEVICE(CMOSBAT_10, ADC,
[PATCH] KVM: x86: drop TSC offsetting kvm_x86_ops to fix KVM_GET/SET_CLOCK
Since commit a545ab6a0085 ("kvm: x86: add tsc_offset field to struct
kvm_vcpu_arch", 2016-09-07) the offset between host and L1 TSC is
cached and need not be fished out of the VMCS or VMCB. This means
that we can implement adjust_tsc_offset_guest and read_l1_tsc
entirely in generic code. The simplification is particularly
significant for VMX code, where vmx->nested.vmcs01_tsc_offset
was duplicating what is now in vcpu->arch.tsc_offset. Therefore
the vmcs01_tsc_offset can be dropped completely.
More importantly, this fixes KVM_GET_CLOCK/KVM_SET_CLOCK
which, after commit 108b249c453d ("KVM: x86: introduce get_kvmclock_ns",
2016-09-01) called read_l1_tsc while the VMCS was not loaded.
It thus returned bogus values on Intel CPUs.
Fixes: 108b249c453dd7132599ab6dc7e435a7036c193f
Reported-by: Roman Kagan
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_host.h | 3 ---
arch/x86/kvm/svm.c | 23 ---
arch/x86/kvm/vmx.c | 39 +++
arch/x86/kvm/x86.c | 6 +++---
4 files changed, 6 insertions(+), 65 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4b20f7304b9c..bdde80731f49 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -948,7 +948,6 @@ struct kvm_x86_ops {
int (*get_lpage_level)(void);
bool (*rdtscp_supported)(void);
bool (*invpcid_supported)(void);
- void (*adjust_tsc_offset_guest)(struct kvm_vcpu *vcpu, s64 adjustment);
void (*set_tdp_cr3)(struct kvm_vcpu *vcpu, unsigned long cr3);
@@ -958,8 +957,6 @@ struct kvm_x86_ops {
void (*write_tsc_offset)(struct kvm_vcpu *vcpu, u64 offset);
- u64 (*read_l1_tsc)(struct kvm_vcpu *vcpu, u64 host_tsc);
-
void (*get_exit_info)(struct kvm_vcpu *vcpu, u64 *info1, u64 *info2);
int (*check_intercept)(struct kvm_vcpu *vcpu,
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f8157a36ab09..8ca1eca5038d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1138,21 +1138,6 @@ static void svm_write_tsc_offset(struct kvm_vcpu *vcpu,
u64 offset)
mark_dirty(svm->vmcb, VMCB_INTERCEPTS);
}
-static void svm_adjust_tsc_offset_guest(struct kvm_vcpu *vcpu, s64 adjustment)
-{
- struct vcpu_svm *svm = to_svm(vcpu);
-
- svm->vmcb->control.tsc_offset += adjustment;
- if (is_guest_mode(vcpu))
- svm->nested.hsave->control.tsc_offset += adjustment;
- else
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
-svm->vmcb->control.tsc_offset - adjustment,
-svm->vmcb->control.tsc_offset);
-
- mark_dirty(svm->vmcb, VMCB_INTERCEPTS);
-}
-
static void avic_init_vmcb(struct vcpu_svm *svm)
{
struct vmcb *vmcb = svm->vmcb;
@@ -3449,12 +3434,6 @@ static int cr8_write_interception(struct vcpu_svm *svm)
return 0;
}
-static u64 svm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc)
-{
- struct vmcb *vmcb = get_host_vmcb(to_svm(vcpu));
- return vmcb->control.tsc_offset + host_tsc;
-}
-
static int svm_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
struct vcpu_svm *svm = to_svm(vcpu);
@@ -5422,8 +5401,6 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.has_wbinvd_exit = svm_has_wbinvd_exit,
.write_tsc_offset = svm_write_tsc_offset,
- .adjust_tsc_offset_guest = svm_adjust_tsc_offset_guest,
- .read_l1_tsc = svm_read_l1_tsc,
.set_tdp_cr3 = set_tdp_cr3,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 74a4df993a51..754c3a7f444a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -421,7 +421,6 @@ struct nested_vmx {
/* vmcs02_list cache of VMCSs recently used to run L2 guests */
struct list_head vmcs02_pool;
int vmcs02_num;
- u64 vmcs01_tsc_offset;
bool change_vmcs01_virtual_x2apic_mode;
/* L2 must run next, and mustn't decide to exit to L1. */
bool nested_run_pending;
@@ -2605,20 +2604,6 @@ static u64 guest_read_tsc(struct kvm_vcpu *vcpu)
}
/*
- * Like guest_read_tsc, but always returns L1's notion of the timestamp
- * counter, even if a nested guest (L2) is currently running.
- */
-static u64 vmx_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc)
-{
- u64 tsc_offset;
-
- tsc_offset = is_guest_mode(vcpu) ?
- to_vmx(vcpu)->nested.vmcs01_tsc_offset :
- vmcs_read64(TSC_OFFSET);
- return host_tsc + tsc_offset;
-}
-
-/*
* writes 'offset' into guest's timestamp counter offset register
*/
static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset)
@@ -2631,7 +2616,6 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu,
u64 offset)
* to the newly set TSC to get L2's TSC.
*/
struct vmcs12 *vmcs12;
- to_vmx(vcpu)
[PATCH v4 4/6] Add Advantech iManager I2C driver
Signed-off-by: Richard Vidal-Dorsch
---
drivers/i2c/busses/Kconfig| 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-imanager.c | 461 ++
3 files changed, 472 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-imanager.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..7d1ecb4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -42,6 +42,16 @@ config I2C_ALI15X3
This driver can also be built as a module. If so, the module
will be called i2c-ali15x3.
+config I2C_IMANAGER
+ tristate "Advantech iManager I2C Interface"
+ depends on MFD_IMANAGER
+ help
+ This enables support for Advantech iManager I2C of some
+ Advantech SOM, MIO, AIMB, and PCM modules/boards.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-imanager.
+
config I2C_AMD756
tristate "AMD 756/766/768/8111 and nVidia nForce"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 29764cc..d9ff210 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_GPIO)+= i2c-gpio.o
obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
obj-$(CONFIG_I2C_HIX5HD2) += i2c-hix5hd2.o
obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
+obj-$(CONFIG_I2C_IMANAGER) += i2c-imanager.o
obj-$(CONFIG_I2C_IMG) += i2c-img-scb.o
obj-$(CONFIG_I2C_IMX) += i2c-imx.o
obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
diff --git a/drivers/i2c/busses/i2c-imanager.c
b/drivers/i2c/busses/i2c-imanager.c
new file mode 100644
index 000..15c496d
--- /dev/null
+++ b/drivers/i2c/busses/i2c-imanager.c
@@ -0,0 +1,461 @@
+/*
+ * Advantech iManager SMBus bus driver
+ *
+ * Copyright (C) 2016 Advantech Co., Ltd.
+ * Author: Richard Vidal-Dorsch
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_SMBUS_BLOCK_SIZE 32UL
+#define I2C_MAX_READ_SIZE I2C_SMBUS_BLOCK_SIZE
+#define I2C_MAX_WRITE_SIZE (I2C_SMBUS_BLOCK_SIZE - 1)
+
+#define EC_HWRAM_OFFSET_STATUS 0UL
+
+#define I2C_ERR_PROTO 0x19UL
+#define I2C_ERR_TIMEOUT0x18UL
+#define I2C_ERR_ACCESS 0x17UL
+#define I2C_ERR_UNKNOWN0x13UL
+#define I2C_ERR_ADDR_NACK 0x10UL
+
+#define SMBUS_FREQ_50KHZ 0x0100
+#define SMBUS_FREQ_100KHZ 0x0200
+#define SMBUS_FREQ_400KHZ 0x0300
+
+#define imanager_i2c_wr_combined(ec, message) \
+ imanager_i2c_block_wr_rw_combined(ec, message, EC_CMD_I2C_WR)
+
+#define imanager_i2c_rw_combined(ec, message) \
+ imanager_i2c_block_wr_rw_combined(ec, message, EC_CMD_I2C_RW)
+
+struct ec_i2c_status {
+ u32 error : 7;
+ u32 complete: 1;
+};
+
+struct adapter_info {
+ struct i2c_adapter adapter;
+ int smb_devid;
+};
+
+struct imanager_i2c_data {
+ struct device *dev;
+ struct imanager_device_data *imgr;
+ struct adapter_info adap_info[EC_MAX_SMB_NUM];
+ int nadap;
+};
+
+static int imanager_i2c_eval_status(u8 status)
+{
+ struct ec_i2c_status *_status = (struct ec_i2c_status *)&status;
+
+ switch (_status->error) {
+ case 0:
+ return 0;
+ case I2C_ERR_ADDR_NACK:
+ return -ENXIO;
+ case I2C_ERR_ACCESS:
+ return -EACCES;
+ case I2C_ERR_UNKNOWN:
+ return -EAGAIN;
+ case I2C_ERR_TIMEOUT:
+ return -ETIME;
+ case I2C_ERR_PROTO:
+ return -EPROTO;
+ }
+
+ return -EIO;
+}
+
+static int imanager_i2c_wait_proc_complete(struct imanager_ec_data *ec)
+{
+ int ret, i;
+ u8 val;
+
+ for (i = 0; i < EC_MAX_RETRY; i++) {
+ ret = imanager_read_ram(ec, EC_RAM_HW, EC_HWRAM_OFFSET_STATUS,
+ &val, sizeof(val));
+ if (ret < 0)
+ return ret;
+
+ if (!val)
+ return 0;
+
+ usleep_range(EC_DELAY_MIN, EC_DELAY_MAX);
+ }
+
+ return -ETIME;
+}
+
+static int imanager_i2c_block_wr_rw_combined(struct imanager_ec_data *ec,
+struct imanager_ec_message *msg,
+unsigned int protocol)
+{
+ int ret;
+
+ ret = imanager_i2c_wait_proc_complete(ec);
+ if (ret)
+ return ret;
+
+ ret = imanager_write(ec, protocol, msg);
+ if (ret)
+
[PATCH v4 3/6] Add Advantech iManager HWmon driver
Signed-off-by: Richard Vidal-Dorsch
---
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/imanager-hwmon.c | 1226
3 files changed, 1238 insertions(+)
create mode 100644 drivers/hwmon/imanager-hwmon.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d..7a9db12 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -625,6 +625,17 @@ config SENSORS_CORETEMP
sensor inside your CPU. Most of the family 6 CPUs
are supported. Check Documentation/hwmon/coretemp for details.
+config SENSORS_IMANAGER
+ tristate "Advantech iManager Hardware Monitoring"
+ depends on MFD_IMANAGER
+ select HWMON_VID
+ help
+ This enables support for Advantech iManager hardware monitoring
+ of some Advantech SOM, MIO, AIMB, and PCM modules/boards.
+
+ This driver can also be built as a module. If so, the module
+ will be called imanager-hwmon.
+
config SENSORS_IT87
tristate "ITE IT87xx and compatibles"
depends on !PPC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba..3f489ae 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
+obj-$(CONFIG_SENSORS_IMANAGER) += imanager-hwmon.o
obj-$(CONFIG_SENSORS_INA209) += ina209.o
obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
obj-$(CONFIG_SENSORS_INA3221) += ina3221.o
diff --git a/drivers/hwmon/imanager-hwmon.c b/drivers/hwmon/imanager-hwmon.c
new file mode 100644
index 000..af72c35
--- /dev/null
+++ b/drivers/hwmon/imanager-hwmon.c
@@ -0,0 +1,1226 @@
+/*
+ * Advantech iManager Hardware Monitoring driver
+ * Partially derived from nct6775
+ *
+ * Copyright (C) 2016 Advantech Co., Ltd.
+ * Author: Richard Vidal-Dorsch
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Voltage computation (10-bit ADC, 0..3V input) */
+#define SCALE_IN 2933 /* (3000mV / (2^10 - 1)) * 1000 */
+
+#define HWM_STATUS_UNDEFINED_ITEM 2UL
+#define HWM_STATUS_UNDEFINED_DID 3UL
+#define HWM_STATUS_UNDEFINED_HWPIN 4UL
+
+/* iManager EC FW pwm[1-*]_mode values are switched */
+enum imanager_pwm_mode { CTRL_PWM, CTRL_RPM };
+/* EC FW defines pwm_enable mode 'full speed' besides mode 'off' */
+enum imanager_pwm_enable { MODE_OFF, MODE_FULL, MODE_MANUAL, MODE_AUTO };
+
+/*
+ * iManager FAN device defs
+ */
+struct fan_dev_config {
+ u8 did,
+ hwpin,
+ tachoid,
+ status,
+ control,
+ temp_max,
+ temp_min,
+ temp_stop,
+ pwm_max,
+ pwm_min;
+ u16 rpm_max;
+ u16 rpm_min;
+ u8 debounce; /* debounce time, not used */
+ u8 temp; /* Current Thermal Zone Temperature */
+ u16 rpm_target; /* RPM Target Speed, not used */
+} __attribute__((__packed__));
+
+struct fan_alert_limit {
+ u16 min,
+ max;
+} __attribute__((__packed__));
+
+struct fan_status {
+ u32 sysctl : 1,/* System Control flag */
+ tacho : 1,/* FAN tacho source defined */
+ pulse : 1,/* FAN pulse type defined */
+ thermal : 1,/* Thermal zone init */
+ i2clink : 1,/* I2C protocol fail flag (thermal sensor) */
+ dnc : 1,/* don't care */
+ mode: 2;/* FAN Control mode */
+};
+
+/**
+ * FAN Control bit field
+ * enable: 0:Disabled, 1:Enabled
+ * type: 0:PWM, 1:RPM
+ * pulse:0:Undefined 1:2 Pulses 2:4 Pulses
+ * tacho:1:CPU FAN, 2:SYS FAN1, 3:SYS FAN2
+ * mode: 0:Off, 1:Full, 2:Manual, 3:Auto
+ */
+struct fan_ctrl {
+ u32 enable : 1,/* SmartFAN control on/off */
+ type: 1,/* FAN control type [0, 1] PWM/RPM */
+ pulse : 2,/* FAN pulse [0..2] */
+ tacho : 2,/* FAN Tacho Input [1..3] */
+ mode: 2;/* off/full/manual/auto */
+};
+
+/* Default Voltage Sensors */
+struct imanager_hwmon_adc {
+ bool valid; /* if set, below values are valid */
+ unsigned int value;
+ unsigned int min;
+ unsigned int max;
+ unsigned int average;
+ unsigned int lowest;
+
Re: [PATCH v2 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.
Hi Oliver,
Thanks for reviewing the patch!
On Tue, Nov 01, 2016 at 07:32:58PM +1100, Oliver O'Halloran wrote:
> On Thu, Oct 27, 2016 at 7:35 PM, Gautham R. Shenoy
> wrote:
> > From: "Gautham R. Shenoy"
> >
> > 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
> > ---
> > drivers/cpuidle/cpuidle-powernv.c | 82
> > +++
> > include/linux/cpuidle.h | 1 +
> > 2 files changed, 49 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle-powernv.c
> > b/drivers/cpuidle/cpuidle-powernv.c
> > index 7fe442c..11b22b9 100644
> > --- a/drivers/cpuidle/cpuidle-powernv.c
> > +++ b/drivers/cpuidle/cpuidle-powernv.c
> > @@ -167,6 +167,28 @@ static int powernv_cpuidle_driver_init(void)
> > return 0;
> > }
> >
> > +static inline void add_powernv_state(int index, const char *name,
> > +unsigned int flags,
> > +int (*idle_fn)(struct cpuidle_device *,
> > + struct cpuidle_driver *,
> > + int),
> > +unsigned int target_residency,
> > +unsigned int exit_latency,
> > +u64 psscr_val)
> > +{
> > + strncpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> > + strncpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
>
> If the supplied name is equal to CPUIDLE_NAME_LEN then strncpy() won't
> terminate the string. The least annoying fix is to memset() the whole
> structure to zero and set n to CPUIDLE_NAME_LEN - 1.
I will change this to use strlcpy as Paul suggested in the reply.
>
> > + powernv_states[index].flags = flags;
> > + powernv_states[index].target_residency = target_residency;
> > + powernv_states[index].exit_latency = exit_latency;
> > + powernv_states[index].enter = idle_fn;
> > +
> > + if (idle_fn != stop_loop)
> > + return;
>
> This can probably be deleted. The nap/sleep loops don't look at the
> psscr setting and you've passed in a dummy value of zero anyway.
The subsequent patch adds the missing bits to the psscr_val if we are
running on the older firmware. But in any case, as you rightly pointed
out we don't use psscr_table in nap/sleep loops. So this can go.
>
> > +
> > + stop_psscr_table[index] = psscr_val;
> > +}
> > +
> > static int powernv_add_idle_states(void)
> > {
> > struct device_node *power_mgt;
> > @@ -236,6 +258,7 @@ static int powernv_add_idle_states(void)
> > "ibm,cpu-idle-state-residency-ns", residency_ns,
> > dt_idle_states);
> >
> > for (i = 0; i < dt_idle_states; i++) {
> > + unsigned int exit_latency, target_residency;
> > /*
> > * If an idle state has exit latency beyond
> > * POWERNV_THRESHOLD_LATENCY_NS then don't use it
> > @@ -244,27 +267,30 @@ static int powernv_add_idle_states(void)
> > if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
> > continue;
> >
> > + exit_latency = ((unsigned int)latency_ns[i]) / 1000;
> > + target_residency = (!rc) ? ((unsigned int)residency_ns[i])
> > : 0;
> > + /*
> > +* Firmware passes residency values in ns.
> > +* cpuidle expects it in us.
> > +*/
> > + target_residency /= 1000;
> > +
> > /*
> > * Cpuidle accepts exit_latency and target_residency in us.
>
> This comment says the same thing as the one above.
Will clean this up to reflect the state of the code.
>
> > * Use default target_residency values if f/w does not
> > expose it.
> > */
> > if (flags[i] & OPAL_PM_NAP_ENABLED) {
> > + target_residency = 100;
>
> Hmm, the above comment says that we should only use the default value
> for target_residency if firmware hasn't provided a value. Is there a
> reason we always use the hard coded value?
Ah, good catch! I should be setting target_residency to the default
value only if it is not set by the firmware. Will fix this.
>
> > /* Add NAP state */
> > - strcpy(powernv_states[nr_idle_states].name, "Nap");
> > - strcpy(powernv_states[nr_idle_states].desc, "Nap");
> > - powernv_states[nr_idle_states].flags = 0;
> > - powernv_stat
Re: [PATCH] sdhci-esdhc-imx: fix bus-width for 1-bit operation.
Hi Leonardo, On Tue, Nov 1, 2016 at 11:58 PM, Leonardo G. Veiga wrote: > From: Leonardo Graboski Veiga > > The 1-bit operation mode, enabled by seeting the 'bus-width' property of > the device tree 'esdhc' node to <1>, not work while using SD card. > > The behavior is only noticed when only the data pin 0 is connected to the > hardware. A series of kernel errors are printed to the console, all of them > returning the following error message followed by some explanation: > mmcblk0: error -84 transferring data > > If four data lines are connected, it ignores the device-tree > property and works in 4-bit mode of operation without errors. The hardware > used for testing does not support 8-bit mode. > > Check the 'bus-width' property and if set to <1>, enable the > SDHCI_QUIRK_FORCE_1_BIT_DATA quirk. > > Signed-off-by: Leonardo Graboski Veiga > --- > drivers/mmc/host/sdhci-esdhc-imx.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c > b/drivers/mmc/host/sdhci-esdhc-imx.c > index c9fbc4c3..88d7d22 100644 > --- a/drivers/mmc/host/sdhci-esdhc-imx.c > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c > @@ -1003,6 +1003,10 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev, > host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; > } > > + if (!of_property_read_u32(np, "bus-width", &boarddata->max_bus_width) > + && boarddata->max_bus_width == 1) > + host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; > + This looks like a common SDHCI driver issue that it assumes the default bus-width as 4 bit if no SDHCI_QUIRK_FORCE_1_BIT_DATA specified. if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA)) mmc->caps |= MMC_CAP_4_BIT_DATA; And I'm not sure Andrian or Ulf would like to see people keep using this quirk. IMHO we probably could totally remove it since bus-width already tells what the driver needs. Andrian & Ulf, Comments? > /* call to generic mmc_of_parse to support additional capabilities */ > ret = mmc_of_parse(host->mmc); > if (ret) > -- > 2.7.4 > Regards Dong Aisheng
Re: [PATCH 2/2] mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read during __sdhci_read_caps
On 28/10/16 18:56, Zach Brown wrote:
> The sdhci capabilities register can be incorrect. The sdhci-caps-mask
> and sdhci-caps dt properties specify which bits of the register are
> incorrect and what their values should be. This patch makes the sdhci
> driver use those properties to correct the caps during
> __sdhci_read_caps.
>
> During __sdhci_read_caps
> Use the sdhci-caps-mask property to turn off the incorrect bits of the
> sdhci register after reading them.
> Use the sdhci-caps to turn on bits after using sdhci-caps-mask to turn
> off the incorrect ones.
>
> Signed-off-by: Zach Brown
Apart from minor style issue:
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 1e25b01..d5feae4 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -2991,6 +2992,8 @@ static int sdhci_set_dma_mask(struct sdhci_host *host)
> void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32
> *caps1)
> {
> u16 v;
> + u64 dt_caps_mask = 0;
> + u64 dt_caps = 0;
>
> if (host->read_caps)
> return;
> @@ -3005,18 +3008,35 @@ void __sdhci_read_caps(struct sdhci_host *host, u16
> *ver, u32 *caps, u32 *caps1)
>
> sdhci_do_reset(host, SDHCI_RESET_ALL);
>
> + of_property_read_u64(mmc_dev(host->mmc)->of_node,
> + "sdhci-caps-mask", &dt_caps_mask);
> + of_property_read_u64(mmc_dev(host->mmc)->of_node,
> + "sdhci-caps", &dt_caps);
> +
> v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
> host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
>
> if (host->quirks & SDHCI_QUIRK_MISSING_CAPS)
> return;
>
> - host->caps = caps ? *caps : sdhci_readl(host, SDHCI_CAPABILITIES);
> + if (caps)
> + host->caps = *caps;
> + else {
All branches of 'if' should have {}.
i.e. refer results of ./scripts/checkpatch.pl --strict
> + host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
> + host->caps &= ~lower_32_bits(dt_caps_mask);
> + host->caps |= lower_32_bits(dt_caps);
> + }
>
> if (host->version < SDHCI_SPEC_300)
> return;
>
> - host->caps1 = caps1 ? *caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1);
> + if (caps1)
> + host->caps1 = *caps1;
> + else {
Ditto
> + host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
> + host->caps1 &= ~upper_32_bits(dt_caps_mask);
> + host->caps1 |= upper_32_bits(dt_caps);
> + }
> }
> EXPORT_SYMBOL_GPL(__sdhci_read_caps);
>
>
Re: [PATCH] ASoC: sun4i-codec: Enable bus clock after getting GPIO
On Tue, Nov 01, 2016 at 02:31:55PM +0800, Chen-Yu Tsai wrote: > In the current probe function the GPIO is acquired after the codec's > bus clock is enabled. However if it fails to acquire the GPIO due to > a deferred probe, it does not disable the bus clock before bailing out. > This would result in the clock being enabled multiple times. > > Move the code that enables the bus clock after the part that gets the > GPIO, maintaining a separation between resource acquisition and device > enablement in the probe function. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation
Hi,
On Wed, 2 Nov 2016 09:06:45 +0100 Sascha Hauer wrote:
> On Wed, Nov 02, 2016 at 08:56:20AM +0100, Lothar Waßmann wrote:
> > Hi,
> >
> > On Wed, 2 Nov 2016 08:36:14 +0100 Sascha Hauer wrote:
> > > On Wed, Nov 02, 2016 at 08:18:52AM +0100, Lothar Waßmann wrote:
> > > > Hi,
> > > >
> > > > On Mon, 31 Oct 2016 06:59:04 +0100 Sascha Hauer wrote:
> > > > > As said, even the commit 7b27c160c68 introducing the register clk did
> > > > > not
> > > > > enable the clock consistently for all register accesses. Maybe it's
> > > > > best
> > > > > to include the following patch so that we can find a clear culprit and
> > > > > do not bury the ipg clock changes in larger patches.
> > > > >
> > > > > Sascha
> > > > >
> > > > > -8<---
> > > > >
> > > > > From 30b77e83269a58c2cb5ce6de8be647e027030d34 Mon Sep 17 00:00:00 2001
> > > > > From: Sascha Hauer
> > > > > Date: Mon, 31 Oct 2016 06:45:33 +0100
> > > > > Subject: [PATCH] pwm: imx: remove ipg clock
> > > > >
> > > > > The use of the ipg clock was introduced with commit 7b27c160c6. In the
> > > > > commit message it was claimed that the ipg clock is enabled for
> > > > > register
> > > > > accesses. This is true for the ->config() callback, but not for the
> > > > > ->set_enable() callback. Given that the ipg clock is not consistently
> > > > > enabled for all register accesses we can assume that either it is not
> > > > > required at all or that the current code does not work.
> > > > > Remove the ipg clock code for now so that it's no longer in the way of
> > > > > refactoring the driver.
> > > > >
> > > > > Signed-off-by: Sascha Hauer
> > > > > Cc: Philipp Zabel
> > > > > ---
> > > > > drivers/pwm/pwm-imx.c | 19 +--
> > > > > 1 file changed, 1 insertion(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > > > > index d600fd5..70609ef2 100644
> > > > > --- a/drivers/pwm/pwm-imx.c
> > > > > +++ b/drivers/pwm/pwm-imx.c
> > > > > @@ -49,7 +49,6 @@
> > > > >
> > > > > struct imx_chip {
> > > > > struct clk *clk_per;
> > > > > - struct clk *clk_ipg;
> > > > >
> > > > > void __iomem*mmio_base;
> > > > >
> > > > > @@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
> > > > > struct pwm_device *pwm, int duty_ns, int period_ns)
> > > > > {
> > > > > struct imx_chip *imx = to_imx_chip(chip);
> > > > > - int ret;
> > > > > -
> > > > > - ret = clk_prepare_enable(imx->clk_ipg);
> > > > > - if (ret)
> > > > > - return ret;
> > > > >
> > > > > - ret = imx->config(chip, pwm, duty_ns, period_ns);
> > > > > -
> > > > > - clk_disable_unprepare(imx->clk_ipg);
> > > > > -
> > > > > - return ret;
> > > > > + return imx->config(chip, pwm, duty_ns, period_ns);
> > > > > }
> > > > >
> > > > > static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device
> > > > > *pwm)
> > > > > @@ -293,13 +283,6 @@ static int imx_pwm_probe(struct platform_device
> > > > > *pdev)
> > > > > return PTR_ERR(imx->clk_per);
> > > > > }
> > > > >
> > > > > - imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > > > > - if (IS_ERR(imx->clk_ipg)) {
> > > > > - dev_err(&pdev->dev, "getting ipg clock failed with
> > > > > %ld\n",
> > > > > - PTR_ERR(imx->clk_ipg));
> > > > > - return PTR_ERR(imx->clk_ipg);
> > > > > - }
> > > > > -
> > > > > imx->chip.ops = &imx_pwm_ops;
> > > > > imx->chip.dev = &pdev->dev;
> > > > > imx->chip.base = -1;
> > > > >
> > > > If the IPG clock is not needed by the driver it should be removed from
> > > > DT as well.
> > >
> > > No, it's only the half truth that it's not needed. It would indeed be
> > > needed if the driver used the ipg clock as source for the PWM
> > > (PWMCR[17:16] = 0b01).
> > >
> > That's a different story!
> > Currently the DT specifies two clocks for the PWM:
> > 1. register access clock (which we now know is unnecessary)
> > 2. PWM source clock
> > In the case mentioned above, the IPG clock has to be specified as the
> > SECOND clock entry in DT, because otherwise the clock won't be
> > enabled/disabled as required!
>
> Since the driver gets its clock by name (clk_get(&pdev->dev, "per"/"ipg"))
> the position in the DT doesn't matter at all.
>
Do you really think so?
The driver does a lookup for a clock named 'ipg' which it doesn't use
at all with your proposed patcht and a lookup for the 'per' clock which
it enables/disables whenever the PWM output is switched inactive/active.
Since the clock named 'per' is the second clock in DTB it is moot to
have the ipg clock in the first position when intending to use it as
PWM source clock!
> The only thing that isn't accurate is that the "ipg" clock in the device
> tree is not for register access, but itself a clock to be used as PWM
> source. This i
Re: [PATCH] PM / sleep: fix device reference leak in test_suspend
On Tue 2016-11-01 11:49:56, Johan Hovold wrote:
> Make sure to drop the reference taken by class_find_device() after
> opening the rtc device.
>
> Fixes: 77437fd4e61f ("pm: boot time suspend selftest")
> Signed-off-by: Johan Hovold
Acked-by: Pavel Machek
> ---
> kernel/power/suspend_test.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/power/suspend_test.c b/kernel/power/suspend_test.c
> index 084452e34a12..bdff5ed57f10 100644
> --- a/kernel/power/suspend_test.c
> +++ b/kernel/power/suspend_test.c
> @@ -203,8 +203,10 @@ static int __init test_suspend(void)
>
> /* RTCs have initialized by now too ... can we use one? */
> dev = class_find_device(rtc_class, NULL, NULL, has_wakealarm);
> - if (dev)
> + if (dev) {
> rtc = rtc_class_open(dev_name(dev));
> + put_device(dev);
> + }
> if (!rtc) {
> printk(warn_no_rtc);
> return 0;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
[PATCH 2/3] powerpc: Add encoding for couple of load/store instructions
These encodings will be used in subsequent patch that test emulate_step for load/store instructions. Signed-off-by: Ravi Bangoria --- arch/powerpc/include/asm/ppc-opcode.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index 0132831..a17a09a 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -284,6 +284,13 @@ #define PPC_INST_BRANCH_COND 0x4080 #define PPC_INST_LBZCIX0x7c0006aa #define PPC_INST_STBCIX0x7c0007aa +#define PPC_INST_LWZX 0x7c2e +#define PPC_INST_LFSX 0x7c00042e +#define PPC_INST_STFSX 0x7c00052e +#define PPC_INST_LFDX 0x7c0004ae +#define PPC_INST_STFDX 0x7c0005ae +#define PPC_INST_LVX 0x7cce +#define PPC_INST_STVX 0x7c0001ce /* macros to insert fields into opcodes */ #define ___PPC_RA(a) (((a) & 0x1f) << 16) -- 1.8.3.1
[PATCH 0/3] powerpc: Emulation support for load/store instructions on LE
emulate_step is the basic infrastructure which is used by number of other kernel infrastructures like kprobe, hw-breakpoint(data breakpoint) etc. In case of kprobe, enabling emulation of load/store instructions will speedup the execution of probed instruction. In case of kernel-space breakpoint, causative instruction is first get emulated before executing user registered handler. If emulation fails, hw-breakpoint is disabled with error. As emulate_step does not support load/store instructions on LE, kernel-space hw-breakpoint infrastructure is broken on LE. emulate_step() uses a number of underlying kernel functions that were initially not enabled for LE. This has been rectified since. So, fix emulate_step() for LE for the corresponding instructions. Also add selftest which will run at boot if CONFIG_KPROBES_SANITY_TEST and CONFIG_PPC64 is set. Changes w.r.t. RFC: - Enable emulation support for all types of (Normal, Floating Point, Vector and Vector Scalar) load/store instructions. - Introduce selftest to test emulate_step for load/store instructions. Ravi Bangoria (3): powerpc: Emulation support for load/store instructions on LE powerpc: Add encoding for couple of load/store instructions powerpc: emulate_step test for load/store instructions arch/powerpc/include/asm/ppc-opcode.h | 7 + arch/powerpc/include/asm/sstep.h | 8 + arch/powerpc/kernel/kprobes.c | 2 + arch/powerpc/lib/Makefile | 4 + arch/powerpc/lib/sstep.c | 20 -- arch/powerpc/lib/test_emulate_step.c | 439 ++ 6 files changed, 460 insertions(+), 20 deletions(-) create mode 100644 arch/powerpc/lib/test_emulate_step.c -- 1.8.3.1
[PATCH 3/3] powerpc: emulate_step test for load/store instructions
Add new selftest that test emulate_step for Normal, Floating Point,
Vector and Vector Scalar - load/store instructions. Test should run
at boot time if CONFIG_KPROBES_SANITY_TEST and CONFIG_PPC64 is set.
Sample log:
[0.762063] emulate_step smoke test: start.
[0.762219] emulate_step smoke test: ld : PASS
[0.762434] emulate_step smoke test: lwz: PASS
[0.762653] emulate_step smoke test: lwzx : PASS
[0.762867] emulate_step smoke test: std: PASS
[0.763082] emulate_step smoke test: ldarx / stdcx. : PASS
[0.763302] emulate_step smoke test: lfsx : PASS
[0.763514] emulate_step smoke test: stfsx : PASS
[0.763727] emulate_step smoke test: lfdx : PASS
[0.763942] emulate_step smoke test: stfdx : PASS
[0.764134] emulate_step smoke test: lvx: PASS
[0.764349] emulate_step smoke test: stvx : PASS
[0.764575] emulate_step smoke test: lxvd2x : PASS
[0.764788] emulate_step smoke test: stxvd2x: PASS
[0.764997] emulate_step smoke test: complete.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/sstep.h | 8 +
arch/powerpc/kernel/kprobes.c| 2 +
arch/powerpc/lib/Makefile| 4 +
arch/powerpc/lib/test_emulate_step.c | 439 +++
4 files changed, 453 insertions(+)
create mode 100644 arch/powerpc/lib/test_emulate_step.c
diff --git a/arch/powerpc/include/asm/sstep.h b/arch/powerpc/include/asm/sstep.h
index d3a42cc..d6d3630 100644
--- a/arch/powerpc/include/asm/sstep.h
+++ b/arch/powerpc/include/asm/sstep.h
@@ -87,3 +87,11 @@ struct instruction_op {
extern int analyse_instr(struct instruction_op *op, struct pt_regs *regs,
unsigned int instr);
+
+#if defined(CONFIG_KPROBES_SANITY_TEST) && defined(CONFIG_PPC64)
+void test_emulate_step(void);
+#else
+static inline void test_emulate_step(void)
+{
+}
+#endif
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index e785cc9..01d8002 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -544,6 +544,8 @@ int __kprobes longjmp_break_handler(struct kprobe *p,
struct pt_regs *regs)
int __init arch_init_kprobes(void)
{
+ test_emulate_step();
+
return register_kprobe(&trampoline_p);
}
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 309361e8..7d046ca 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -35,3 +35,7 @@ obj-$(CONFIG_ALTIVEC) += xor_vmx.o
CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
obj-$(CONFIG_PPC64) += $(obj64-y)
+
+ifeq ($(CONFIG_PPC64), y)
+obj-$(CONFIG_KPROBES_SANITY_TEST) += test_emulate_step.o
+endif
diff --git a/arch/powerpc/lib/test_emulate_step.c
b/arch/powerpc/lib/test_emulate_step.c
new file mode 100644
index 000..887d1db
--- /dev/null
+++ b/arch/powerpc/lib/test_emulate_step.c
@@ -0,0 +1,439 @@
+/*
+ * test_emulate_step.c - simple sanity test for emulate_step load/store
+ * instructions
+ *
+ * Copyright IBM Corp. 2016
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
+ * the GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) "emulate_step smoke test: " fmt
+
+#include
+#include
+#include
+
+#define IMM_L(i) ((uintptr_t)(i) & 0x)
+
+/*
+ * Defined with TEST_ prefix so it does not conflict with other
+ * definitions.
+ */
+#define TEST_LD(r, base, i)(PPC_INST_LD | ___PPC_RT(r) | \
+ ___PPC_RA(base) | IMM_L(i))
+#define TEST_LWZ(r, base, i) (PPC_INST_LWZ | ___PPC_RT(r) | \
+ ___PPC_RA(base) | IMM_L(i))
+#define TEST_LWZX(t, a, b) (PPC_INST_LWZX | ___PPC_RT(t) | \
+ ___PPC_RA(a) | ___PPC_RB(b))
+#define TEST_STD(r, base, i) (PPC_INST_STD | ___PPC_RS(r) | \
+ ___PPC_RA(base) | ((i) & 0xfffc))
+#define TEST_LDARX(t, a, b, eh)(PPC_INST_LDARX | ___PPC_RT(t) |
\
+ ___PPC_RA(a) | ___PPC_RB(b) | \
+ __PPC_EH(eh))
+#define TEST_STDCX(s, a, b)(PPC_INST_STDCX | ___PPC_RS(s) |\
+ ___PPC_RA(a) | ___PPC_RB(b))
+#define TEST_LFSX(t, a, b) (PPC_INST_LFSX | ___PPC_RT(t) | \
+ ___PPC_RA(a)
[PATCH 1/3] powerpc: Emulation support for load/store instructions on LE
emulate_step() uses a number of underlying kernel functions that were
initially not enabled for LE. This has been rectified since. So, fix
emulate_step() for LE for the corresponding instructions.
Reported-by: Anton Blanchard
Signed-off-by: Ravi Bangoria
---
arch/powerpc/lib/sstep.c | 20
1 file changed, 20 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 3362299..6ca3b90 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1807,8 +1807,6 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
goto instr_done;
case LARX:
- if (regs->msr & MSR_LE)
- return 0;
if (op.ea & (size - 1))
break; /* can't handle misaligned */
err = -EFAULT;
@@ -1832,8 +1830,6 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
goto ldst_done;
case STCX:
- if (regs->msr & MSR_LE)
- return 0;
if (op.ea & (size - 1))
break; /* can't handle misaligned */
err = -EFAULT;
@@ -1859,8 +1855,6 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
goto ldst_done;
case LOAD:
- if (regs->msr & MSR_LE)
- return 0;
err = read_mem(®s->gpr[op.reg], op.ea, size, regs);
if (!err) {
if (op.type & SIGNEXT)
@@ -1872,8 +1866,6 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
#ifdef CONFIG_PPC_FPU
case LOAD_FP:
- if (regs->msr & MSR_LE)
- return 0;
if (size == 4)
err = do_fp_load(op.reg, do_lfs, op.ea, size, regs);
else
@@ -1882,15 +1874,11 @@ int __kprobes emulate_step(struct pt_regs *regs,
unsigned int instr)
#endif
#ifdef CONFIG_ALTIVEC
case LOAD_VMX:
- if (regs->msr & MSR_LE)
- return 0;
err = do_vec_load(op.reg, do_lvx, op.ea & ~0xfUL, regs);
goto ldst_done;
#endif
#ifdef CONFIG_VSX
case LOAD_VSX:
- if (regs->msr & MSR_LE)
- return 0;
err = do_vsx_load(op.reg, do_lxvd2x, op.ea, regs);
goto ldst_done;
#endif
@@ -1913,8 +1901,6 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
goto instr_done;
case STORE:
- if (regs->msr & MSR_LE)
- return 0;
if ((op.type & UPDATE) && size == sizeof(long) &&
op.reg == 1 && op.update_reg == 1 &&
!(regs->msr & MSR_PR) &&
@@ -1927,8 +1913,6 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
#ifdef CONFIG_PPC_FPU
case STORE_FP:
- if (regs->msr & MSR_LE)
- return 0;
if (size == 4)
err = do_fp_store(op.reg, do_stfs, op.ea, size, regs);
else
@@ -1937,15 +1921,11 @@ int __kprobes emulate_step(struct pt_regs *regs,
unsigned int instr)
#endif
#ifdef CONFIG_ALTIVEC
case STORE_VMX:
- if (regs->msr & MSR_LE)
- return 0;
err = do_vec_store(op.reg, do_stvx, op.ea & ~0xfUL, regs);
goto ldst_done;
#endif
#ifdef CONFIG_VSX
case STORE_VSX:
- if (regs->msr & MSR_LE)
- return 0;
err = do_vsx_store(op.reg, do_stxvd2x, op.ea, regs);
goto ldst_done;
#endif
--
1.8.3.1
Re: [PATCH v2 3/6] usb: ehci: fsl: use bus->sysdev for DMA configuration
Hi Arnd,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Sriram-Dash/inherit-dma-configuration-from-parent-dev/20161102-141353
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: powerpc-mpc8313_rdb_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
drivers/usb/host/ehci-fsl.c: In function 'fsl_ehci_drv_probe':
>> drivers/usb/host/ehci-fsl.c:99:56: error: invalid type argument of '->'
>> (have 'struct device')
hcd = __usb_create_hcd(&fsl_ehci_hc_driver, &pdev->dev->parent,
^~
vim +99 drivers/usb/host/ehci-fsl.c
93 "Found HC with no IRQ. Check %s setup!\n",
94 dev_name(&pdev->dev));
95 return -ENODEV;
96 }
97 irq = res->start;
98
> 99 hcd = __usb_create_hcd(&fsl_ehci_hc_driver, &pdev->dev->parent,
100 &pdev->dev, dev_name(&pdev->dev), NULL);
101 if (!hcd) {
102 retval = -ENOMEM;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
Hi Jon, On 10/31/2016 04:14 PM, Jon Hunter wrote: > Hi Rajendra, > > On 06/10/16 09:43, Rajendra Nayak wrote: >> >> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>> Hi Rajendra, >>> >>> On 06/10/16 07:04, Rajendra Nayak wrote: On 09/20/2016 03:58 PM, Jon Hunter wrote: > The Tegra124/210 XUSB subsystem (that consists of both host and device > controllers) is partitioned across 3 PM domains which are: > - XUSBA: Superspeed logic (for USB 3.0) > - XUSBB: Device controller > - XUSBC: Host controller > > These power domains are not nested and can be powered-up and down > independently of one another. In practice different scenarios require > different combinations of the power domains, for example: > - Superspeed host: XUSBA and XUSBC > - Superspeed device: XUSBA and XUSBB > > Although it could be possible to logically nest both the XUSBB and XUSBC > domains under the XUSBA, superspeed may not always be used/required and > so this would keep it on unnecessarily. Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains for a device (which then will *all* be powered on/off together) or does it also provide for more granular control of these powerdomains? >>> >>> Only to specify multiple power-domains for a device and not the later. >>> The above statement seems to suggest you would need more granular control of these powerdomains (like keeping XUSBA off in case superspeed it not needed) but I can't seem to figure out how you achieve it with this series. >>> >>> It is an interesting point but today we have always kept the superspeed >>> partition on if the device is configured for superspeed regardless of >>> what is actually connected. I will check to see if the h/w would allow >>> us to turn it off if a non-superspeed device is in use but I did not >>> think so. >>> >>> Do you have any interesting use-cases that would make use of this or >>> require other such enhancements? >> >> We do have atleast a few devices which need to control multiple power >> domains, >> I will need to look more to see if any of them can be controlled >> individually. >> The downstream code we have models these (powerdomains) as regulators and >> the drivers hence have individual control on each (specifying multiple >> -supply's >> in DT) > > Were you able to check to see if you need to have individual control for the > power-domains? I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, so for things like firmware image loading you ideally need only venus PD to be ON, but during an encode/decode operation you would need all 3 to be ON. The downstream driver turns *all* of them together, and does not control them individually. For upstream, the way we have it working (the driver is not merged) is by having venus be the parent of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as the powerdomain for the video decode block in DT. So in summary, there is still no need to control them individually, but given there is no way to specify more than one powerdomain for a given device, we are ending up hooking up some parent/child relations in the powerdomain code. regards, Rajendra -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 1/2] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
Hi Kishon,
On Thu, Oct 27, 2016 at 1:26 AM, Kishon Vijay Abraham I wrote:
> Hi,
I am currently on vacation, so the responses are delayed a bit.
Please bear with me.
>
> On Wednesday 19 October 2016 04:13 PM, Vivek Gautam wrote:
>> PHY transceiver driver for QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller present on
>> Qualcomm chipsets.
>>
>> This driver is based on phy-msm-qusb driver available in
>> msm-4.4 kernel @codeaurora[1]
>>
>> [1]
>> https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18
>
> I'd prefer only LKML links in commit msg. This can be part of the comment
> section below ---.
Sure, will use LKML links only.
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Kishon Vijay Abraham I
>> ---
>> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 37 ++
>> drivers/phy/Kconfig| 10 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qcom-qusb2.c | 577
>> +
>> 4 files changed, 625 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>> create mode 100644 drivers/phy/phy-qcom-qusb2.c
[snip]
>> +struct qusb2_phy_init_tbl {
>> + unsigned int reg_offset;
>> + unsigned int cfg_val;
>> +};
>> +#define QCOM_QUSB2_PHY_INIT_CFG(reg, val) \
>> + { \
>> + .reg_offset = reg, \
>> + .cfg_val = val, \
>> + }
>> +
>> +static struct qusb2_phy_init_tbl msm8996_phy_init_tbl[] = {
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xF8),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xB3),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xC0),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TEST2, 0x14),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_AUTOPGM_CTL1, 0x9F),
>> + QCOM_QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>> +};
> we should generalize this so that it could be used for any phys. All these
> tuning parameters can come from dt.
>
> phy,tx-swing = ;
> phy,rx-swing = ;
> phy,tx-compensation = ;
> phy,rx-compensation = ;
> ..
>
> We have to identify all the calibration parameters and add a dt property for
> each parameter. The phy-core can just use these properties to calibrate or
> tune
> the PHY.
Yes, that will make life easier.
Things look simpler with this qusb2 phy driver.
But, same is not the case with the qmp-phy driver
that supports few other phys on msm chipsets.
That qmp phy driver has a list of ~100 odd registers that
need to be programmed during initialization.
We, then, don't need to touch those settings any time later.
The settings include, the common PLL settings, tx, rx and the
pcs settings.
I will take a look at these drivers once again, and see if we can group
the settings and make few generic bindings that can be utilized
but the phy drivers in general.
>
>> +
>> +struct qusb2_phy_init_cfg {
>> + struct qusb2_phy_init_tbl *phy_init_tbl;
>> + int phy_init_tbl_sz;
>> +};
>> +
>> +const struct qusb2_phy_init_cfg msm8996_phy_init_cfg = {
>> + .phy_init_tbl = msm8996_phy_init_tbl,
>> + .phy_init_tbl_sz = ARRAY_SIZE(msm8996_phy_init_tbl),
>> +};
>> +
>> +/**
>> + * struct qusb2_phy: Structure holding qusb2 phy attributes.
>> + *
>> + * @phy: pointer to generic phy.
>> + * @base: pointer to iomapped memory space for qubs2 phy.
>> + *
>> + * @cfg_ahb_clk: pointer to AHB2PHY interface clock.
>> + * @ref_clk: pointer to reference clock.
>> + * @ref_clk_src: pointer to source to reference clock.
>> + * @iface_src: pointer to phy interface clock.
>> + * @clk_enabled: check if clocks are enabled.
>
> Why is this needed? IMO this should not be used. clk framework can handle this
> better since it maintains a reference count for clk_enable/clk_disable.
Ok, will remove this.
>> + *
>> + * @phy_reset: Pointer to phy reset control
>> + *
>> + * @vdda_phy: vdd supply to the phy core block.
>> + * @vdda_pll: 1.8V vdd supply to ref_clk block.
>> + * @vdda_phy_dpdm: 3.1V vdd supply to Dp/Dm port signals.
>> + * @pwr_enabled: check if the regulators are enabled.
>
> same here.
will remove this as well.
>> + * @tcsr: pointer to TCSR syscon register map.
>> + * @clk_scheme_offset: offset to PHY_CLK_SCHEME register in TCSR map.
>> + * @cfg: phy initialization config data
>> + */
>> +struct qusb2_phy {
>> + struct phy *phy;
>> + void __iomem *base;
>> +
>> + struct clk *cfg_ahb_clk;
>> + struct clk *ref_clk;
>> + struct clk *ref_clk_src;
>> + struct clk *iface_clk;
>> + bool clk_enabled;
>> +
>> + struct reset_control *phy_reset;
>> +
>> + struct regulator *vdd_phy;
>> + struct regula
Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
Hi Stephen,
Thanks for your answers!
On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd wrote:
> On 10/31, Geert Uytterhoeven wrote:
>> Hi Mike, Stephen, Arnd, Olof, Kevin,
>>
>> Is the merge strategy [see # below] OK for you?
>> Thanks a lot!
>>
>> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman wrote:
>> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> >> wrote:
>> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> > state of the mode pins either by a call from the platform code, or
>> >> > directly by using a hardcoded register access. This is a bit messy, and
>> >> > creates a dependency between driver and platform code.
>> >> >
>> >> > This patch series converts the various Renesas R-Car clock drivers
>> >> > and support code from reading the mode pin states using a hardcoded
>> >> > register access to using a new minimalistic R-Car RST driver.
>> >> >
>> >> > All R-Car clock drivers will rely on the presence in DT of a device node
>> >> > for the RST module. Backwards compatibility with old DTBs is retained
>> >> > only for R-Car Gen2, which has fallback code using its own private copy
>> >> > of rcar_gen2_read_mode_pins().
>> >> >
>> >> > After this, there is still one remaining user of
>> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >> >
>> >> > This series consists of 5 parts:
>> >> > A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >> > driver,
>> >> > B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >> > files,
>> >> > C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >> > RST driver,
>> >> > D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >> > from the platform code,
>> >> > E. Patches 21-23 remove dead code from the clock drivers.
>> >> >
>> >> > As is usually the case with moving functionality from platform code to
>> >> > DT, there are lots of hard dependencies:
>> >> > - The DT updates in Part B can be merged as soon as the DT bindings in
>> >> > Part A have been approved,
>> >> > - The clock driver updates in Part C depend functionally on the driver
>> >> > code in Part A, and on the DT updates in Part B,
>> >> > - The board code cleanups in Part D depend on the clock driver updates
>> >> > in Part C,
>> >> > - The block driver cleanups in part E depend on the board code
>> >> > cleanups in part D.
>> >> >
>> >> > Hence to maintain the required lockstep between SoC driver, clock
>> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> >> > all patches in a single branch against v4.9-rc1, and send pull requests
>> >> > to both Mike/Stephen (clock) and Simon (rest).
>> >> >
>> >> > ***
>> >>
>> >> > - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >> > approach above?
>> >>
>> >> Is this OK for you?
>>
>> #
>>
>> (link to the full series at
>> https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
>
> Would the pull requests for clk also have dts changes at the base
> of the tree? Perhaps clk side can just ack the clk patches and
Yes they would: this is moving functionality from platform code to DT.
Without the DT updates, it will break bisection (except for R-Car Gen2,
where we have fallback code to handle old DTBs).
> then have it all routed through arm-soc? The only worry I have is
> if we need to make some sort of change in clk side that conflicts
> with these changes. I don't usually like taking dts changes
> through clk tree, so I'd like to avoid that if possible.
Everything could go through arm-soc only with your Acked-by.
However, there are new clock drivers pending on this series.
Either they have to go through arm-soc, too, or this series would
be pulled into the clk tree with these new clock drivers.
> Part E could happen anytime after everything else happens, so
> that doesn't seem like a concern.
Part E can indeed by postponed.
But if parts A-D are applied together, there's no reason to postpone part E.
> Part C could also be made to
> only call into the new reset drivers if the reset dts nodes are
> present? If that's done then we could merge clk patches anytime
> and remove the dead code and the node search at some later time
> when everything has settled?
That would require adding more backwards compatibility code for
old DTBs, even for platform where we're not interested in maintaining
that. In addition, Part C depends on the header file for the reset driver
to compile the clock driver, even if you would add some D
[PATCH V2] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map
This is a workaround for VHT-enabled STAs which break the spec
and have the VHT-MCS Rx map filled in with value 3 for all eight
spacial streams, an example is AR9462 in AP mode.
As per spec, in section 22.1.1 Introduction to the VHT PHY
A VHT STA shall support at least single spactial stream VHT-MCSs
0 to 7 (transmit and receive) in all supported channel widths.
Some devices in STA mode will get firmware assert when trying to
associate, examples are QCA9377 & QCA6174.
Packet example of broken VHT Cap IE of AR9462:
Tag: VHT Capabilities (IEEE Std 802.11ac/D3.1)
Tag Number: VHT Capabilities (IEEE Std 802.11ac/D3.1) (191)
Tag length: 12
VHT Capabilities Info: 0x
VHT Supported MCS Set
Rx MCS Map: 0x
..11 = Rx 1 SS: Not Supported (0x0003)
11.. = Rx 2 SS: Not Supported (0x0003)
..11 = Rx 3 SS: Not Supported (0x0003)
11.. = Rx 4 SS: Not Supported (0x0003)
..11 = Rx 5 SS: Not Supported (0x0003)
11.. = Rx 6 SS: Not Supported (0x0003)
..11 = Rx 7 SS: Not Supported (0x0003)
11.. = Rx 8 SS: Not Supported (0x0003)
...0 = Rx Highest Long GI Data Rate (in Mb/s, 0 =
subfield not in use): 0x
Tx MCS Map: 0x
...0 = Tx Highest Long GI Data Rate (in Mb/s, 0 =
subfield not in use): 0x
Signed-off-by: Filip Matusiak
---
net/mac80211/vht.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..6832bf6 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -270,6 +270,22 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct
ieee80211_sub_if_data *sdata,
vht_cap->vht_mcs.tx_mcs_map |= cpu_to_le16(peer_tx << i * 2);
}
+ /*
+* This is a workaround for VHT-enabled STAs which break the spec
+* and have the VHT-MCS Rx map filled in with value 3 for all eight
+* spacial streams, an example is AR9462.
+*
+* As per spec, in section 22.1.1 Introduction to the VHT PHY
+* A VHT STA shall support at least single spactial stream VHT-MCSs
+* 0 to 7 (transmit and receive) in all supported channel widths.
+*/
+ if (vht_cap->vht_mcs.rx_mcs_map == cpu_to_le16(0x)) {
+ vht_cap->vht_supported = false;
+ sdata_info(sdata, "Ignoring VHT IE from %pM due to invalid
rx_mcs_map\n",
+ sta->addr);
+ return;
+ }
+
/* finally set up the bandwidth */
switch (vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
--
2.7.4
[PATCH V3 3/6] arm64: Handle TRAP_TRACE for user mode as well
uprobe registers a handler at step_hook. So, single_step_handler now
checks for user mode as well if there is a valid hook.
Signed-off-by: Pratyush Anand
---
arch/arm64/kernel/debug-monitors.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index 73ae90ef434c..a8f8de012250 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -226,6 +226,8 @@ static void send_user_sigtrap(int si_code)
static int single_step_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
+ bool handler_found = false;
+
/*
* If we are stepping a pending breakpoint, call the hw_breakpoint
* handler first.
@@ -233,7 +235,14 @@ static int single_step_handler(unsigned long addr,
unsigned int esr,
if (!reinstall_suspended_bps(regs))
return 0;
- if (user_mode(regs)) {
+#ifdef CONFIG_KPROBES
+ if (kprobe_single_step_handler(regs, esr) == DBG_HOOK_HANDLED)
+ handler_found = true;
+#endif
+ if (!handler_found && call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
+ handler_found = true;
+
+ if (!handler_found && user_mode(regs)) {
send_user_sigtrap(TRAP_TRACE);
/*
@@ -243,15 +252,8 @@ static int single_step_handler(unsigned long addr,
unsigned int esr,
* to the active-not-pending state).
*/
user_rewind_single_step(current);
- } else {
-#ifdef CONFIG_KPROBES
- if (kprobe_single_step_handler(regs, esr) == DBG_HOOK_HANDLED)
- return 0;
-#endif
- if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
- return 0;
-
- pr_warning("Unexpected kernel single-step exception at EL1\n");
+ } else if (!handler_found) {
+ pr_warn("Unexpected kernel single-step exception at EL1\n");
/*
* Re-enable stepping since we know that we will be
* returning to regs.
--
2.7.4
[PATCH V3 0/6] ARM64: Uprobe support added
Changes since v2: * arm64 specific is_trap_insn() removed. Using default implementation. * arch_uprobe_analyze_insn() returns -ENOTSUPP for 32bit task probe. V2 was here: https://lkml.org/lkml/2016/9/27/58 Patches have been rebased on v4.9-rc3. They have been tested with mustang and seattle platform for following test cases. 1. Step-able instructions, like sub, ldr, add etc. 2. Simulation-able like ret, cbnz, cbz etc. 3. uretprobe 4. Reject-able instructions like sev, wfe etc. 5. trapped and abort xol path 6. probe at unaligned user address. 7. longjump test cases aarch32 task probing is not yet supported. Pratyush Anand (6): arm64: kprobe: protect/rename few definitions to be reused by uprobe arm64: kgdb_step_brk_fn: ignore other's exception arm64: Handle TRAP_TRACE for user mode as well arm64: Handle TRAP_BRKPT for user mode as well arm64: introduce mm context flag to keep 32 bit task information arm64: Add uprobe support arch/arm64/Kconfig | 3 + arch/arm64/include/asm/cacheflush.h | 1 + arch/arm64/include/asm/debug-monitors.h | 3 + arch/arm64/include/asm/elf.h| 12 +- arch/arm64/include/asm/mmu.h| 1 + arch/arm64/include/asm/probes.h | 19 +-- arch/arm64/include/asm/ptrace.h | 8 ++ arch/arm64/include/asm/thread_info.h| 5 +- arch/arm64/include/asm/uprobes.h| 36 ++ arch/arm64/kernel/debug-monitors.c | 40 +++--- arch/arm64/kernel/kgdb.c| 3 + arch/arm64/kernel/probes/Makefile | 2 + arch/arm64/kernel/probes/decode-insn.c | 32 ++--- arch/arm64/kernel/probes/decode-insn.h | 8 +- arch/arm64/kernel/probes/kprobes.c | 36 +++--- arch/arm64/kernel/probes/uprobes.c | 216 arch/arm64/kernel/signal.c | 3 + arch/arm64/mm/flush.c | 2 +- 18 files changed, 366 insertions(+), 64 deletions(-) create mode 100644 arch/arm64/include/asm/uprobes.h create mode 100644 arch/arm64/kernel/probes/uprobes.c -- 2.7.4
[PATCH V3 2/6] arm64: kgdb_step_brk_fn: ignore other's exception
ARM64 step exception does not have any syndrome information. So, it is
responsibility of exception handler to take care that they handle it
only if exception was raised for them.
Since kgdb_step_brk_fn() always returns 0, therefore we might have problem
when we will have other step handler registered as well.
This patch fixes kgdb_step_brk_fn() to return error in case of step handler
was not meant for kgdb.
Signed-off-by: Pratyush Anand
---
arch/arm64/kernel/kgdb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index e017a9493b92..d217c9e95b06 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -247,6 +247,9 @@ NOKPROBE_SYMBOL(kgdb_compiled_brk_fn);
static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr)
{
+ if (!kgdb_single_step)
+ return DBG_HOOK_ERROR;
+
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
--
2.7.4
[PATCH V3 1/6] arm64: kprobe: protect/rename few definitions to be reused by uprobe
decode-insn code has to be reused by arm64 uprobe implementation as well.
Therefore, this patch protects some portion of kprobe code and renames few
other, so that decode-insn functionality can be reused by uprobe even when
CONFIG_KPROBES is not defined.
kprobe_opcode_t and struct arch_specific_insn are also defined by
linux/kprobes.h, when CONFIG_KPROBES is not defined. So, protect these
definitions in asm/probes.h.
linux/kprobes.h already includes asm/kprobes.h. Therefore, remove inclusion
of asm/kprobes.h from decode-insn.c.
There are some definitions like kprobe_insn and kprobes_handler_t etc can
be re-used by uprobe. So, it would be better to remove 'k' from their
names.
struct arch_specific_insn is specific to kprobe. Therefore, introduce a new
struct arch_probe_insn which will be common for both kprobe and uprobe, so
that decode-insn code can be shared. Modify kprobe code accordingly.
Function arm_probe_decode_insn() will be needed by uprobe as well. So make
it global.
Signed-off-by: Pratyush Anand
---
arch/arm64/include/asm/probes.h| 19 ++
arch/arm64/kernel/probes/decode-insn.c | 32 --
arch/arm64/kernel/probes/decode-insn.h | 8 ++--
arch/arm64/kernel/probes/kprobes.c | 36 +-
4 files changed, 52 insertions(+), 43 deletions(-)
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
index 5af574d632fa..e175a825b187 100644
--- a/arch/arm64/include/asm/probes.h
+++ b/arch/arm64/include/asm/probes.h
@@ -17,19 +17,22 @@
#include
-struct kprobe;
-struct arch_specific_insn;
-
-typedef u32 kprobe_opcode_t;
-typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
+typedef u32 probe_opcode_t;
+typedef void (probes_handler_t) (u32 opcode, long addr, struct pt_regs *);
/* architecture specific copy of original instruction */
-struct arch_specific_insn {
- kprobe_opcode_t *insn;
+struct arch_probe_insn {
+ probe_opcode_t *insn;
pstate_check_t *pstate_cc;
- kprobes_handler_t *handler;
+ probes_handler_t *handler;
/* restore address after step xol */
unsigned long restore;
};
+#ifdef CONFIG_KPROBES
+typedef u32 kprobe_opcode_t;
+struct arch_specific_insn {
+ struct arch_probe_insn api;
+};
+#endif
#endif
diff --git a/arch/arm64/kernel/probes/decode-insn.c
b/arch/arm64/kernel/probes/decode-insn.c
index d1731bf977ef..8a29d2982eec 100644
--- a/arch/arm64/kernel/probes/decode-insn.c
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -78,8 +78,8 @@ static bool __kprobes aarch64_insn_is_steppable(u32 insn)
* INSN_GOOD If instruction is supported and uses instruction slot,
* INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
*/
-static enum kprobe_insn __kprobes
-arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
+enum probe_insn __kprobes
+arm_probe_decode_insn(probe_opcode_t insn, struct arch_probe_insn *api)
{
/*
* Instructions reading or modifying the PC won't work from the XOL
@@ -89,26 +89,26 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct
arch_specific_insn *asi)
return INSN_GOOD;
if (aarch64_insn_is_bcond(insn)) {
- asi->handler = simulate_b_cond;
+ api->handler = simulate_b_cond;
} else if (aarch64_insn_is_cbz(insn) ||
aarch64_insn_is_cbnz(insn)) {
- asi->handler = simulate_cbz_cbnz;
+ api->handler = simulate_cbz_cbnz;
} else if (aarch64_insn_is_tbz(insn) ||
aarch64_insn_is_tbnz(insn)) {
- asi->handler = simulate_tbz_tbnz;
+ api->handler = simulate_tbz_tbnz;
} else if (aarch64_insn_is_adr_adrp(insn)) {
- asi->handler = simulate_adr_adrp;
+ api->handler = simulate_adr_adrp;
} else if (aarch64_insn_is_b(insn) ||
aarch64_insn_is_bl(insn)) {
- asi->handler = simulate_b_bl;
+ api->handler = simulate_b_bl;
} else if (aarch64_insn_is_br(insn) ||
aarch64_insn_is_blr(insn) ||
aarch64_insn_is_ret(insn)) {
- asi->handler = simulate_br_blr_ret;
+ api->handler = simulate_br_blr_ret;
} else if (aarch64_insn_is_ldr_lit(insn)) {
- asi->handler = simulate_ldr_literal;
+ api->handler = simulate_ldr_literal;
} else if (aarch64_insn_is_ldrsw_lit(insn)) {
- asi->handler = simulate_ldrsw_literal;
+ api->handler = simulate_ldrsw_literal;
} else {
/*
* Instruction cannot be stepped out-of-line and we don't
@@ -120,6 +120,7 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct
arch_specific_insn *asi)
return INSN_GOOD_NO_SLOT;
}
+#ifdef CONFIG_KPROBES
static bool __kprobes
is_probed_address_atomic(kprobe_opcode_t *scan_start, k
[PATCH V3 5/6] arm64: introduce mm context flag to keep 32 bit task information
We need to decide in some cases like uprobe instruction analysis that
whether the current mm context belongs to a 32 bit task or 64 bit.
This patch has introduced an unsigned flag variable in mm_context_t.
Currently, we set and clear TIF_32BIT depending on the condition that
whether an elf binary load sets personality for 32 bit or 64 bit
respectively.
Signed-off-by: Pratyush Anand
---
arch/arm64/include/asm/elf.h | 12 ++--
arch/arm64/include/asm/mmu.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index a55384f4a5d7..5d1700425efe 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -138,7 +138,11 @@ typedef struct user_fpsimd_state elf_fpregset_t;
*/
#define ELF_PLAT_INIT(_r, load_addr) (_r)->regs[0] = 0
-#define SET_PERSONALITY(ex)clear_thread_flag(TIF_32BIT);
+#define SET_PERSONALITY(ex)\
+({ \
+ clear_bit(TIF_32BIT, ¤t->mm->context.flags); \
+ clear_thread_flag(TIF_32BIT); \
+})
/* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
#define ARCH_DLINFO\
@@ -183,7 +187,11 @@ typedef compat_elf_greg_t
compat_elf_gregset_t[COMPAT_ELF_NGREG];
((x)->e_flags & EF_ARM_EABI_MASK))
#define compat_start_threadcompat_start_thread
-#define COMPAT_SET_PERSONALITY(ex) set_thread_flag(TIF_32BIT);
+#define COMPAT_SET_PERSONALITY(ex) \
+({ \
+ set_bit(TIF_32BIT, ¤t->mm->context.flags);\
+ set_thread_flag(TIF_32BIT); \
+ })
#define COMPAT_ARCH_DLINFO
extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
int uses_interp);
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 8d9fce037b2f..d4fa21543771 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -19,6 +19,7 @@
typedef struct {
atomic64_t id;
void*vdso;
+ unsigned long flags;
} mm_context_t;
/*
--
2.7.4
[PATCH V3 4/6] arm64: Handle TRAP_BRKPT for user mode as well
uprobe is registered at break_hook with a unique ESR code. So, when a
TRAP_BRKPT occurs, call_break_hook checks if it was for uprobe. If not,
then send a SIGTRAP to user.
Signed-off-by: Pratyush Anand
---
arch/arm64/kernel/debug-monitors.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index a8f8de012250..605df76f0a06 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -306,16 +306,20 @@ NOKPROBE_SYMBOL(call_break_hook);
static int brk_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
- if (user_mode(regs)) {
- send_user_sigtrap(TRAP_BRKPT);
- }
+ bool handler_found = false;
+
#ifdef CONFIG_KPROBES
- else if ((esr & BRK64_ESR_MASK) == BRK64_ESR_KPROBES) {
- if (kprobe_breakpoint_handler(regs, esr) != DBG_HOOK_HANDLED)
- return -EFAULT;
+ if ((esr & BRK64_ESR_MASK) == BRK64_ESR_KPROBES) {
+ if (kprobe_breakpoint_handler(regs, esr) == DBG_HOOK_HANDLED)
+ handler_found = true;
}
#endif
- else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
+ if (!handler_found && call_break_hook(regs, esr) == DBG_HOOK_HANDLED)
+ handler_found = true;
+
+ if (!handler_found && user_mode(regs)) {
+ send_user_sigtrap(TRAP_BRKPT);
+ } else if (!handler_found) {
pr_warn("Unexpected kernel BRK exception at EL1\n");
return -EFAULT;
}
--
2.7.4
Re: [PATCH v2][RESEND] seq_file: don't set read position for invalid iterator
On Mon, Oct 31, 2016 at 10:32:21AM +0100, Tomasz Majchrzak wrote:
> On Wed, Oct 26, 2016 at 11:17:13AM +0200, Miklos Szeredi wrote:
> > On Wed, Oct 12, 2016 at 2:07 PM, Tomasz Majchrzak
> > wrote:
> > > If kernfs file is empty on a first read, successive read operations
> > > using the same file descriptor will return no data, even when data is
> > > available. Default kernfs 'seq_next' implementation advances iterator
> > > position even when next object is not there. Kernfs 'seq_start' for
> > > following requests will not return iterator as position is already on
> > > the second object.
> > >
> > > This bug doesn't allow to monitor badblocks sysfs files from MD raid.
> > > They are initially empty but if data appears at some stage, userspace is
> > > not able to read it. It doesn't affect any released applications but it
> > > is necessary for upcoming bad block support for external metadata in MD
> > > raid.
> >
> > What is the expectation from the userspace application? Should
> > seq_file support "tail -f" as more data is added to the file? AFAICS
> > this patch doesn't address that generally, just the empty->nonempty
> > transition (with the single record case).
>
> Yes, it fixes only empty-nonempty transition. I believe it already works
> fine ("tail -f") if the file cursor is in the middle of the file,
"tail -f" works if there are multiple records. It doesn't work for the "single"
style of seq_file used by sysfs.
> however
> mdmon never performs such operation - it "acknowledges" entry read from the
> start of one sysfs file (unacknowledged_bad_blocks) via other sysfs file
> (bad_blocks) and reads the sysfs file again from the start (there is new
> data at position 0 at this stage).
>
> My patch just resolves a regression introduced by a fix for multiple record
> file: 4cdfe84b514 ("deal with the first call of ->show() generating no
> output").
The above commit (from 2.6.27) didn't change the beavior relative to sysfs
files, AFAICS. Before that commit the index was incremented if the first
iterator was empty, just like after the patch.
> It makes it consistent with rest of the code in seq_file
> (seq_read, traverse) - new iterator position is ignored if valid iterator
> has not been returned.
Your patch doesn't seem to make the behavior consistent, it just special cases
the last record being empty. What if the last two (three, etc) records are
empty? It would be consistent if m->index always pointed to the first record
matching the given file position, for example.
But I doubt that we actually need to do that. For example just special casing
the zero offset (always translating to zero index) would be conceptually simpler
and equivalent to your patch for the sysfs case.
But see below. I still don't see what you gain by not doing the open/read/close
when polling the badblocks file.
> > Why does userspace app not do open+read+close each time it polls the
> > badblocks file?
>
> This excerpt from mdadm/mdmon-design.txt file explains it:
>
> "
> The 'monitor' has the primary role of monitoring the array for
> important state changes and updating the metadata accordingly. As
> writes to the array can be blocked until 'monitor' completes and
> acknowledges the update, it much be very careful not to block itself.
> In particular it must not block waiting for any write to complete else
> it could deadlock. This means that it must not allocate memory as
> doing this can require dirty memory to be written out and if the
> system choose to write to the array that mdmon is monitoring, the
> memory allocation could deadlock.
>
> So 'monitor' must never allocate memory and must limit the number of
> other system call it performs. It may:
> - use select (or poll) to wait for activity on a file descriptor
> - read from a sysfs file descriptor
> - write to a sysfs file descriptor
> - write the metadata out to the block devices using O_DIRECT
> - send a signal (kill) to the manager thread
>
> It must not e.g. open files or do anything similar that might allocate
> resources.
> "
seq_read() *will* allocate memory; see seq_buf_alloc().
Thanks,
Miklos
Re: [PATCH 3/4] cputime/powerpc/s390: make scaled cputime arch specific
On 10/31/2016 01:36 PM, Stanislaw Gruszka wrote:
> Only s390 and powerpc have hardware facilities allowing to measure
> cputimes scaled by frequency. On all other architectures
> utimescaled/stimescaled are equal to utime/stime (however they are
> accounted separately).
>
> Patch remove {u,s}timescaled accounting on all architectures except
> powerpc and s390, where those values are explicitly accounted on proper
> places.
If we remove it everywhere else (and assuming that there are no users then)
I aks myself if we should remove this as well from s390.
We already had to optimize this because the initial code caused some
regressions (commit f341b8dff9 s390/vtime: limit MT scaling value updates).
The code still adds a multiply and a divide to do_account_vtime (and 2
multiplies and 2 divides into vtime_account_irq_enter) which is still
noticeable in perf annotate for switch intense workload.
Martin are you aware of any user of that values?
>
> Signed-off-by: Stanislaw Gruszka
> ---
> arch/ia64/kernel/time.c |4 +-
> arch/powerpc/Kconfig|1 +
> arch/powerpc/kernel/time.c |6 +++-
> arch/s390/Kconfig |1 +
> arch/s390/kernel/vtime.c|9 --
> include/linux/kernel_stat.h |4 +-
> include/linux/sched.h | 23
> kernel/fork.c |2 +
> kernel/sched/cputime.c | 61 ++
> 9 files changed, 50 insertions(+), 61 deletions(-)
>
> diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
> index 6f892b9..021f44a 100644
> --- a/arch/ia64/kernel/time.c
> +++ b/arch/ia64/kernel/time.c
> @@ -68,7 +68,7 @@ void vtime_account_user(struct task_struct *tsk)
>
> if (ti->ac_utime) {
> delta_utime = cycle_to_cputime(ti->ac_utime);
> - account_user_time(tsk, delta_utime, delta_utime);
> + account_user_time(tsk, delta_utime);
> ti->ac_utime = 0;
> }
> }
> @@ -112,7 +112,7 @@ void vtime_account_system(struct task_struct *tsk)
> {
> cputime_t delta = vtime_delta(tsk);
>
> - account_system_time(tsk, 0, delta, delta);
> + account_system_time(tsk, 0, delta);
> }
> EXPORT_SYMBOL_GPL(vtime_account_system);
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 65fba4c..c7f120a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -160,6 +160,7 @@ config PPC
> select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
> select GENERIC_CPU_AUTOPROBE
> select HAVE_VIRT_CPU_ACCOUNTING
> + select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE
> select HAVE_ARCH_HARDENED_USERCOPY
> select HAVE_KERNEL_GZIP
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 8105198..be9751f 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -358,7 +358,8 @@ void vtime_account_system(struct task_struct *tsk)
> unsigned long delta, sys_scaled, stolen;
>
> delta = vtime_delta(tsk, &sys_scaled, &stolen);
> - account_system_time(tsk, 0, delta, sys_scaled);
> + account_system_time(tsk, 0, delta);
> + tsk->stimescaled += sys_scaled;
> if (stolen)
> account_steal_time(stolen);
> }
> @@ -391,7 +392,8 @@ void vtime_account_user(struct task_struct *tsk)
> acct->user_time = 0;
> acct->user_time_scaled = 0;
> acct->utime_sspurr = 0;
> - account_user_time(tsk, utime, utimescaled);
> + account_user_time(tsk, utime);
> + tsk->utimescaled += utimescaled;
> }
>
> #ifdef CONFIG_PPC32
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 426481d..028f97b 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -171,6 +171,7 @@ config S390
> select SYSCTL_EXCEPTION_TRACE
> select TTY
> select VIRT_CPU_ACCOUNTING
> + select ARCH_HAS_SCALED_CPUTIME
> select VIRT_TO_BUS
> select HAVE_NMI
>
> diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
> index 856e30d..90eeb7c 100644
> --- a/arch/s390/kernel/vtime.c
> +++ b/arch/s390/kernel/vtime.c
> @@ -137,8 +137,10 @@ static int do_account_vtime(struct task_struct *tsk, int
> hardirq_offset)
> user_scaled = (user_scaled * mult) / div;
> system_scaled = (system_scaled * mult) / div;
> }
> - account_user_time(tsk, user, user_scaled);
> - account_system_time(tsk, hardirq_offset, system, system_scaled);
> + account_user_time(tsk, user);
> + tsk->utimescaled += user_scaled;
> + account_system_time(tsk, hardirq_offset, system)
> + tsk->stimescaled += system_scaled;
>
> steal = S390_lowcore.steal_timer;
> if ((s64) steal > 0) {
> @@ -202,7 +204,8 @@ void vtime_account_irq_enter(struct task_struct *tsk)
>
> system_scaled = (system_scaled * mult) / div;
> }
> - account_system_time(tsk, 0, system, system_scaled);
> + account_system_time(tsk, 0, system);
> +
[PATCH V3 6/6] arm64: Add uprobe support
This patch adds support for uprobe on ARM64 architecture.
Unit tests for following have been done so far and they have been found
working
1. Step-able instructions, like sub, ldr, add etc.
2. Simulation-able like ret, cbnz, cbz etc.
3. uretprobe
4. Reject-able instructions like sev, wfe etc.
5. trapped and abort xol path
6. probe at unaligned user address.
7. longjump test cases
Currently it does not support aarch32 instruction probing.
Signed-off-by: Pratyush Anand
---
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/cacheflush.h | 1 +
arch/arm64/include/asm/debug-monitors.h | 3 +
arch/arm64/include/asm/ptrace.h | 8 ++
arch/arm64/include/asm/thread_info.h| 5 +-
arch/arm64/include/asm/uprobes.h| 36 ++
arch/arm64/kernel/probes/Makefile | 2 +
arch/arm64/kernel/probes/uprobes.c | 216
arch/arm64/kernel/signal.c | 3 +
arch/arm64/mm/flush.c | 2 +-
10 files changed, 277 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/include/asm/uprobes.h
create mode 100644 arch/arm64/kernel/probes/uprobes.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef880d234..77a807a844ac 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -238,6 +238,9 @@ config PGTABLE_LEVELS
default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47
default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48
+config ARCH_SUPPORTS_UPROBES
+ def_bool y
+
source "init/Kconfig"
source "kernel/Kconfig.freezer"
diff --git a/arch/arm64/include/asm/cacheflush.h
b/arch/arm64/include/asm/cacheflush.h
index 2e5fb976a572..e9f64ecb75ce 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -71,6 +71,7 @@ extern void __flush_dcache_area(void *addr, size_t len);
extern void __clean_dcache_area_poc(void *addr, size_t len);
extern void __clean_dcache_area_pou(void *addr, size_t len);
extern long __flush_cache_user_range(unsigned long start, unsigned long end);
+extern void sync_icache_aliases(void *kaddr, unsigned long len);
static inline void flush_cache_mm(struct mm_struct *mm)
{
diff --git a/arch/arm64/include/asm/debug-monitors.h
b/arch/arm64/include/asm/debug-monitors.h
index b71420a12f26..a44cf5225429 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -68,6 +68,9 @@
#define BRK64_ESR_MASK 0x
#define BRK64_ESR_KPROBES 0x0004
#define BRK64_OPCODE_KPROBES (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
+/* uprobes BRK opcodes with ESR encoding */
+#define BRK64_ESR_UPROBES 0x0005
+#define BRK64_OPCODE_UPROBES (AARCH64_BREAK_MON | (BRK64_ESR_UPROBES << 5))
/* AArch32 */
#define DBG_ESR_EVT_BKPT 0x4
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index ada08b5b036d..513daf050e84 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -217,6 +217,14 @@ int valid_user_regs(struct user_pt_regs *regs, struct
task_struct *task);
#include
+#define procedure_link_pointer(regs) ((regs)->regs[30])
+
+static inline void procedure_link_pointer_set(struct pt_regs *regs,
+ unsigned long val)
+{
+ procedure_link_pointer(regs) = val;
+}
+
#undef profile_pc
extern unsigned long profile_pc(struct pt_regs *regs);
diff --git a/arch/arm64/include/asm/thread_info.h
b/arch/arm64/include/asm/thread_info.h
index e9ea5a6bd449..f6859831462e 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -112,6 +112,7 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_NEED_RESCHED 1
#define TIF_NOTIFY_RESUME 2 /* callback before returning to user */
#define TIF_FOREIGN_FPSTATE3 /* CPU's FP state is not current's */
+#define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */
#define TIF_NOHZ 7
#define TIF_SYSCALL_TRACE 8
#define TIF_SYSCALL_AUDIT 9
@@ -132,10 +133,12 @@ static inline struct thread_info
*current_thread_info(void)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SYSCALL_TRACEPOINT(1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_32BIT (1 << TIF_32BIT)
#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
-_TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE)
+_TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
+_TIF_UPROBE)
#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
_TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
diff --git a/arch/arm64/include/asm/uprobes.h b/arch/arm64/include
[PATCH 2/3] soc/tegra: pmc: Add interface to get IO pad power status
Add API to get the IO pad power status of the Tegra IO pads.
This will help client driver to get the current power status
of IO pads for handling IO pad power.
Signed-off-by: Laxman Dewangan
---
Based on the branch
(https://github.com/thierryreding/linux/tree/tegra186).
This was sent earlier but not applied so resending it as new patch after
rebasing it.
drivers/soc/tegra/pmc.c | 22 ++
include/soc/tegra/pmc.h | 6 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb3715f..44546bd 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -1063,6 +1063,28 @@ int tegra_io_pad_power_disable(enum tegra_io_pad id)
}
EXPORT_SYMBOL(tegra_io_pad_power_disable);
+int tegra_io_pad_power_get_status(enum tegra_io_pad id)
+{
+ const struct tegra_io_pad_soc *pad;
+ unsigned long status;
+ u32 value;
+ int bit;
+
+ pad = tegra_io_pad_find(pmc, id);
+ if (!pad)
+ return -ENOENT;
+
+ if (pad->dpd == UINT_MAX)
+ return -ENOTSUPP;
+
+ status = (pad->dpd < 32) ? IO_DPD_STATUS : IO_DPD2_STATUS;
+ bit = pad->dpd % 32;
+ value = tegra_pmc_readl(status);
+
+ return !!(value & BIT(bit));
+}
+EXPORT_SYMBOL(tegra_io_pad_power_get_status);
+
int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage)
{
diff --git a/include/soc/tegra/pmc.h b/include/soc/tegra/pmc.h
index 9c314a6..18cf172 100644
--- a/include/soc/tegra/pmc.h
+++ b/include/soc/tegra/pmc.h
@@ -152,6 +152,7 @@ int tegra_powergate_sequence_power_up(unsigned int id,
struct clk *clk,
int tegra_io_pad_power_enable(enum tegra_io_pad id);
int tegra_io_pad_power_disable(enum tegra_io_pad id);
+int tegra_io_pad_power_get_status(enum tegra_io_pad id);
int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage);
int tegra_io_pad_get_voltage(enum tegra_io_pad id);
@@ -193,6 +194,11 @@ static inline int tegra_io_pad_power_disable(enum
tegra_io_pad id)
return -ENOSYS;
}
+static inline int tegra_io_pad_power_get_status(enum tegra_io_pad id)
+{
+ return -ENOSYS;
+}
+
static inline int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage)
{
--
2.1.4
[PATCH 1/3] soc/tegra: pmc: Remove legacy Tegra I/O rail API
Remove tegra_io_rail_power_on() and tegra_io_rail_power_off()
from header as client has been moved to new APIs.
Signed-off-by: Laxman Dewangan
---
Based on the branch
(https://github.com/thierryreding/linux/tree/tegra186).
This is just residual of earlier applied patch
commit 7cf94b5869b99c1fc0da8699542c8f3644537c33
Author: Thierry Reding
soc/tegra: pmc: Remove legacy Tegra I/O rail API
Possibly it can be squashed on the change.
include/soc/tegra/pmc.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/soc/tegra/pmc.h b/include/soc/tegra/pmc.h
index 52780a77..9c314a6 100644
--- a/include/soc/tegra/pmc.h
+++ b/include/soc/tegra/pmc.h
@@ -203,16 +203,6 @@ static inline int tegra_io_pad_get_voltage(enum
tegra_io_pad id)
{
return -ENOSYS;
}
-
-static inline int tegra_io_rail_power_on(unsigned int id)
-{
- return -ENOSYS;
-}
-
-static inline int tegra_io_rail_power_off(unsigned int id)
-{
- return -ENOSYS;
-}
#endif /* CONFIG_ARCH_TEGRA */
#endif /* __SOC_TEGRA_PMC_H__ */
--
2.1.4
Re: [PATCH net-next 07/11] net: dsa: mv88e6xxx: add port link setter
On Wed, Nov 02, 2016 at 02:07:09AM +0100, Vivien Didelot wrote: > Hi Andrew, > > Andrew Lunn writes: > > >> +#define LINK_UNKNOWN -1 > >> + > >> + /* Port's MAC link state > >> + * LINK_UNKNOWN for normal link detection, 0 to force link down, > >> + * otherwise force link up. > >> + */ > >> + int (*port_set_link)(struct mv88e6xxx_chip *chip, int port, int link); > > > > Maybe LINK_AUTO would be better than UNKNOWN? Or LINK_UNFORCED. > > I used LINK_UNKNOWN to be consistent with the supported SPEED_UNKNOWN > and DUPLEX_UNKNOWN values of PHY devices. Hi Vivien These are i think for reporting back to user space what duplex or link is currently being used. But here you are setting, not reporting. Setting something to an unknown state is rather odd, and in fact, it is not unknown, it is unforced. Andrew
Re: [PATCH 1/2] phy: rockchip-inno-usb2: support otg-port for rk3399
Hi William, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.9-rc3 next-20161028] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/William-Wu/support-USB2-PHY-OTG-port-for-rk3399/20161102-160006 base: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> drivers/phy/phy-rockchip-inno-usb2.c:39:28: fatal error: linux/wakelock.h: >> No such file or directory #include ^ compilation terminated. vim +39 drivers/phy/phy-rockchip-inno-usb2.c 33 #include 34 #include 35 #include 36 #include 37 #include 38 #include > 39 #include 40 41 #define BIT_WRITEABLE_SHIFT 16 42 #define SCHEDULE_DELAY (60 * HZ) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v2] iio: adc: at91: add suspend and resume callback
Add suspend/resume callback, support the pinctrl sleep state when
the system suspend as well.
Signed-off-by: Wenyou Yang
---
Changes in v2:
- Use CONFIG_PM_SLEEP.
- Use SIMPLE_DEV_PM_OPS macro.
drivers/iio/adc/at91_adc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index bbdac07..34b928c 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/* Registers */
#define AT91_ADC_CR0x00/* Control Register */
@@ -1347,6 +1348,32 @@ static int at91_adc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int at91_adc_suspend(struct device *dev)
+{
+ struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
+ struct at91_adc_state *st = iio_priv(idev);
+
+ pinctrl_pm_select_sleep_state(dev);
+ clk_disable_unprepare(st->clk);
+
+ return 0;
+}
+
+static int at91_adc_resume(struct device *dev)
+{
+ struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
+ struct at91_adc_state *st = iio_priv(idev);
+
+ clk_prepare_enable(st->clk);
+ pinctrl_pm_select_default_state(dev);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(at91_adc_pm_ops, at91_adc_suspend, at91_adc_resume);
+
static struct at91_adc_caps at91sam9260_caps = {
.calc_startup_ticks = calc_startup_ticks_9260,
.num_channels = 4,
@@ -1441,6 +1468,7 @@ static struct platform_driver at91_adc_driver = {
.driver = {
.name = DRIVER_NAME,
.of_match_table = of_match_ptr(at91_adc_dt_ids),
+ .pm = &at91_adc_pm_ops,
},
};
--
2.7.4
[PATCH 0/2] pinctrl: tegra: Add support for IO pad control
NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO power rail sources. When IO interface are not used then IO pads can be configure in low power state to reduce the power from that IO pads. This series add the support of configuration of IO pad via pinctrl framework. The io pad driver uses the tegra PMC interface. --- This driver was sent earlier for review along with soc/tegra pmc changes. During review, decided to first conclude in soc/tegra pmc patches and then review this. Thierry applied the pmc patches in the private tree https://github.com/thierryreding/linux/tree/tegra186 and he wanted to have the patches for user of the new APIs so that it can be pushed to mainline. Sending the pinctrl driver. This needs Ack/reviewed from pinctrl subsystem i.e. Linus Welleij to apply in the Thierry's T186 branch along with PMC patches. Laxman Dewangan (2): pinctrl: tegra: Add DT binding for io pads control pinctrl: tegra: Add driver to configure voltage and power of io pads .../bindings/pinctrl/nvidia,tegra-io-pad.txt | 112 +++ drivers/pinctrl/tegra/Kconfig | 12 + drivers/pinctrl/tegra/Makefile | 1 + drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c | 369 + include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h | 21 ++ 5 files changed, 515 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h -- 2.1.4
[PATCH 0/3] soc/tegra: pmc: Add support for IO pad configuration and sub-driver
Tegra SoC support the configutaion of IO pads to multi-level voltage and low power state. The conifguration is done via pictrl framework and the io pad driver in pinctrl frameowrk uses the APIs from pmc to access PMC registers. This series add the API to get the IO pad power status and register the pmc child devices like IO pad drvier. The patches were send earlier part of different series but applied partially in the Thierry's t186 branch https://github.com/thierryreding/linux/tree/tegra186. Resending the patches as the new start to avoid any confusion. This need to be applied in https://github.com/thierryreding/linux/tree/tegra186 Laxman Dewangan (3): soc/tegra: pmc: Remove legacy Tegra I/O rail API soc/tegra: pmc: Add interface to get IO pad power status soc/tegra: pmc: Register PMC child devices as platform device drivers/soc/tegra/pmc.c | 81 + include/soc/tegra/pmc.h | 14 +++-- 2 files changed, 86 insertions(+), 9 deletions(-) -- 2.1.4
[PATCH 1/2] pinctrl: tegra: Add DT binding for io pads control
NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power state of some of its IO pads. The IO pads can work in the voltage of the 1.8V and 3.3V of IO power rail sources. When IO interface are not used then IO pads can be configure in low power state to reduce the power from that IO pads. On Tegra124, the IO power rail source is auto detected by SoC and hence it is only require to configure in low power mode if IO pads are not used. On T210 onwards, the auto-detection is removed from SoC and hence SW must configure the PMC register explicitly to set proper voltage in IO pads based on IO rail power source voltage. Add DT binding document for detailing the DT properties for configuring IO pads voltage levels and its power state. Signed-off-by: Laxman Dewangan --- On top of the branch from Thierry's T186 work https://github.com/thierryreding/linux/tree/tegra186 .../bindings/pinctrl/nvidia,tegra-io-pad.txt | 112 + include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h | 21 2 files changed, 133 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt new file mode 100644 index 000..15cd21c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt @@ -0,0 +1,112 @@ +NVIDIA Tegra PMC IO pad controller + +NVIDIA Tegra124 and later SoCs support the multi-voltage level and +low power state of some of its IO pads. The IO pads can work in +the voltage of the 1.8V and 3.3V of IO power rail sources. When IO +interface are not used then IO pads can be configure in low power +state to reduce the power from that IO pads. + +On Tegra124, the IO power rail source is auto detected by SoC and hence +it is only require to configure in low power mode if IO pads are not +used. + +On T210 onwards, the auto-detection is removed from SoC and hence SW +must configure the PMC register explicitly to set proper voltage in +IO pads based on IO rail power source voltage. + +The voltage configurations and low power state of IO pads should be done +in boot if it is not going to change other wise dynamically based on IO +rail voltage on that IO pads and usage of IO pads + +The DT property of the io pads must be under the node of pmc i.e. +pmc@7000e400 for Tegra124 onwards. + +Please refer to in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Tegra's pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for an +IO pads, or a list of IO pads. This configuration can include the voltage and +power enable/disable control + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. Each subnode only affects those +parameters that are explicitly listed. Unspecified is represented as an absent +property, + +See the TRM to determine which properties and values apply to each IO pads. +Macro values for property values are defined in + + +The voltage supported on the pads are 1.8V and 3.3V. The enums are defined as: + For 1.8V, use TEGRA_IO_PAD_POWER_SOURCE_180UV + For 3.3V, use TEGRA_IO_PAD_POWER_SOURCE_330UV + +Required subnode-properties: +== +- pins : An array of strings. Each string contains the name of an IO pads. Valid +values for these names are listed below. + +Optional subnode-properties: +== +-nvidia,power-source-voltage: Integer. The voltage level of IO pads. The + valid values are 1.8V and 3.3V. Macros are + defined for these voltage levels in + + Use TEGRA_IO_PAD_POWER_SOURCE_180UV for 1.8V + Use TEGRA_IO_PAD_POWER_SOURCE_330UV for 3.3V + + All IO pads do not support the 1.8V/3.3V + configurations. Valid values for "pins" are + audio-hv, dmic, gpio, sdmmc1, sdmmc3, spi-hv. + +Other than above, following properties are supported from generic pin +configuration explained in . +low-power-enable: enable low power mode. +low-power-disable: disable low power mode. + +Valid values for pin for T124 are: + audio, bb, cam, comp, csia, csib, csie, dsi, dsib, dsic, dsid, hdmi, + hsic, hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2, + pex-ctrl, sdmmc1, sdmmc3, sdmmc4, sys-ddc, uart, usb0, usb1, usb2, + usb-bias + + All above pins support low power mode. + +Valid val
Re: [PATCH v2] EFI loader: remove redundant code
Hello Eugene,
On 2 November 2016 at 04:18, Eugene Korenevsky wrote:
> *e820ext is always NULL in 'alloc_e820ext()' (see the code of 'exit_boot()').
> Without loss of generality we can replace freeing with returning
> EFI_INVALID_PARAMETER. So if the caller would ever incorrectly pass non-NULL
> *e820ext, he will obtain a returned error code.
>
What exactly are you trying to fix here? Adding new artificial failure
modes is hardly worth it when all you are doing is cleaning up code
that by itself is correct to begin with, but is simply never called.
> ---
> arch/x86/boot/compressed/eboot.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c
> b/arch/x86/boot/compressed/eboot.c
> index cc69e37..6cc66c7 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -956,11 +956,8 @@ static efi_status_t alloc_e820ext(u32 nr_desc, struct
> setup_data **e820ext,
> size = sizeof(struct setup_data) +
> sizeof(struct e820entry) * nr_desc;
>
> - if (*e820ext) {
> - efi_call_early(free_pool, *e820ext);
> - *e820ext = NULL;
> - *e820ext_size = 0;
> - }
> + if (*e820ext)
> + return EFI_INVALID_PARAMETER;
>
> status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
> size, (void **)e820ext);
> --
> 2.10.2
>
[PATCH 3/3] soc/tegra: pmc: Register PMC child devices as platform device
Power Management Controller(PMC) of Tegra does the multiple chip
power management related functionality for internal and IO interfacing.
Some of the functionalities are power gating of IP blocks, IO pads
voltage and power state configuration, system power state configurations,
wakeup controls etc.
Different functionalities of the PMC are provided through different
framework like IO pads control can be provided through pinctrl framework,
IO power control is via misc driver etc. All sub functionalities are
represented as PMC child devices.
Register the PMC child devices as platform device and fill the child
devices table for Tegra124 and Tegra210.
Signed-off-by: Laxman Dewangan
---
Based on the branch
(https://github.com/thierryreding/linux/tree/tegra186).
This was sent earlier but not applied so resending it as new patch
after rebasing it.
drivers/soc/tegra/pmc.c | 59 +
1 file changed, 59 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 44546bd..916a94b 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -145,6 +145,9 @@ struct tegra_pmc_soc {
const struct tegra_io_pad_soc *io_pads;
unsigned int num_io_pads;
+
+ const char **sub_devs_name;
+ unsigned int num_sub_devs;
};
/**
@@ -169,6 +172,7 @@ struct tegra_pmc_soc {
* @lp0_vec_size: size of the LP0 warm boot code
* @powergates_available: Bitmap of available power gates
* @powergates_lock: mutex for power gate register access
+ * @plat_subdevs: Platform device for PMC child devices.
*/
struct tegra_pmc {
struct device *dev;
@@ -195,6 +199,7 @@ struct tegra_pmc {
DECLARE_BITMAP(powergates_available, TEGRA_POWERGATE_MAX);
struct mutex powergates_lock;
+ struct platform_device **plat_subdevs;
};
static struct tegra_pmc *pmc = &(struct tegra_pmc) {
@@ -1375,6 +1380,43 @@ static void tegra_pmc_init_tsense_reset(struct tegra_pmc
*pmc)
of_node_put(np);
}
+static int tegra_pmc_init_sub_devs(struct tegra_pmc *pmc)
+{
+ int ret, i;
+
+ if (!pmc->soc->num_sub_devs)
+ return 0;
+
+ pmc->plat_subdevs = devm_kzalloc(pmc->dev, pmc->soc->num_sub_devs *
+sizeof(**pmc->plat_subdevs),
+GFP_KERNEL);
+ if (!pmc->plat_subdevs)
+ return -ENOMEM;
+
+ for (i = 0; i < pmc->soc->num_sub_devs; ++i) {
+ pmc->plat_subdevs[i] = platform_device_register_data(pmc->dev,
+ pmc->soc->sub_devs_name[i],
+ 0, NULL, 0);
+ if (IS_ERR(pmc->plat_subdevs[i])) {
+ ret = PTR_ERR(pmc->plat_subdevs[i]);
+ dev_err(pmc->dev,
+ "Failed to register platform device for %s:
%d\n",
+ pmc->soc->sub_devs_name[i], ret);
+ goto pdev_cleanups;
+ }
+ }
+
+ return 0;
+
+pdev_cleanups:
+ while (--i >= 0) {
+ platform_device_unregister(pmc->plat_subdevs[i]);
+ pmc->plat_subdevs[i] = NULL;
+ }
+
+ return ret;
+}
+
static int tegra_pmc_probe(struct platform_device *pdev)
{
void __iomem *base;
@@ -1426,6 +1468,11 @@ static int tegra_pmc_probe(struct platform_device *pdev)
return err;
}
+ err = tegra_pmc_init_sub_devs(pmc);
+ if (err < 0)
+ dev_warn(pmc->dev, "Failed to register PMC sub devices: %d\n",
+err);
+
mutex_lock(&pmc->powergates_lock);
iounmap(pmc->base);
pmc->base = base;
@@ -1608,6 +1655,10 @@ static const struct tegra_io_pad_soc tegra124_io_pads[]
= {
{ .id = TEGRA_IO_PAD_USB_BIAS, .dpd = 12, .voltage = UINT_MAX },
};
+static const char *tegra124_sub_devs_name[] = {
+ "pinctrl-t124-io-pad",
+};
+
static const struct tegra_pmc_soc tegra124_pmc_soc = {
.num_powergates = ARRAY_SIZE(tegra124_powergates),
.powergates = tegra124_powergates,
@@ -1617,6 +1668,8 @@ static const struct tegra_pmc_soc tegra124_pmc_soc = {
.has_gpu_clamps = true,
.num_io_pads = ARRAY_SIZE(tegra124_io_pads),
.io_pads = tegra124_io_pads,
+ .sub_devs_name = tegra124_sub_devs_name,
+ .num_sub_devs = ARRAY_SIZE(tegra124_sub_devs_name),
};
static const char * const tegra210_powergates[] = {
@@ -1694,6 +1747,10 @@ static const struct tegra_io_pad_soc tegra210_io_pads[]
= {
{ .id = TEGRA_IO_PAD_USB_BIAS, .dpd = 12, .voltage = UINT_MAX },
};
+static const char *tegra210_sub_devs_name[] = {
+ "pinctrl-t210-io-pad",
+};
+
static const struct tegra_pmc_soc tegra210_pmc_soc = {
.num_powergates = ARRAY_SIZE(tegra210_powergates),
.powergates = tegra210_powergates,
@@ -1703,6 +1760,8 @@ st
