Re: [RFC][PATCH 5/7] jump_label: Rework update logic
On Mon, Jul 27, 2015 at 06:30:05PM +0200, Peter Zijlstra wrote: > On Mon, Jul 27, 2015 at 12:47:14PM +0200, Peter Zijlstra wrote: > > @@ -68,13 +63,8 @@ void static_key_slow_inc(struct static_k > > return; > > > > jump_label_lock(); > > + if (atomic_inc_and_test(>enabled)) > > atomic_inc_return() == 1, works _much_ better. Confirmed. With this change, the jump_label_init() patch, plus the changes in s390 inline asm everything works for me. There are a couple of places in s390 code where the DEFINE_STATIC_KEY_FALSE and static_branch_likely() combination would make sense. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rsi: Fix failure to load firmware after memory leak fix and fix the leak
On 27-07-15 12:28, Kalle Valo wrote:
Mike Looijmans writes:
Fixes commit eae79b4f3e82ca63a53478a161b190a0d38fe526 ("rsi: fix memory leak
in rsi_load_ta_instructions()") which stopped the driver from functioning.
You can abbreviate the commit id:
Fixes commit eae79b4f3e82 ("rsi: fix memory leak in
rsi_load_ta_instructions()") which stopped the driver from functioning.
Firmware data has been allocated using vmalloc(), resulting in memory
that cannot be used for DMA. Hence the firmware was first copied to a
buffer allocated with kmalloc() in the original code. This patch reverts
the commit and only calls "kfree()" to release the buffer after sending
the data. This fixes the memory leak without breaking the driver.
Add a comment to the kmemdup() calls to explain why this is done.
Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.
Signed-off-by: Mike Looijmans
Add this before Signed-off-by line:
Fixes: eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
Cc: sta...@vger.kernel.org
Also no need to send email to sta...@vger.kernel.org list, this line is
enough and the stable team will pick the commit automatically.
I wondered why that happened, and just noticed that git send-email
automatically added this to the recipients. So it happened for v2 as well,
sorry for that.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] rsi: Fix failure to load firmware after memory leak fix and fix the leak
Fixes commit eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
which stopped the driver from functioning.
Firmware data has been allocated using vmalloc(), resulting in memory
that cannot be used for DMA. Hence the firmware was first copied to a
buffer allocated with kmalloc() in the original code. This patch reverts
the commit and only calls "kfree()" to release the buffer after sending
the data. This fixes the memory leak without breaking the driver.
Add a comment to the kmemdup() calls to explain why this is done, and abort
if memory allocation fails.
Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.
Fixes: eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
Signed-off-by: Mike Looijmans
Cc: sta...@vger.kernel.org
---
v2: Add "Fixes:" header and abbreviate git hashes.
Return -ENOMEM if kmemdup() fails.
drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 8 +++-
drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 4
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
index b6cc9ff..1c6788a 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
@@ -172,6 +172,7 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
(struct rsi_91x_sdiodev *)adapter->rsi_dev;
u32 len;
u32 num_blocks;
+ const u8 *fw;
const struct firmware *fw_entry = NULL;
u32 block_size = dev->tx_blk_size;
int status = 0;
@@ -200,6 +201,10 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
return status;
}
+ /* Copy firmware into DMA-accessible memory */
+ fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
+ if (!fw)
+ return -ENOMEM;
len = fw_entry->size;
if (len % 4)
@@ -210,7 +215,8 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
rsi_dbg(INIT_ZONE, "%s: Instruction size:%d\n", __func__, len);
rsi_dbg(INIT_ZONE, "%s: num blocks: %d\n", __func__, num_blocks);
- status = rsi_copy_to_card(common, fw_entry->data, len, num_blocks);
+ status = rsi_copy_to_card(common, fw, len, num_blocks);
+ kfree(fw);
release_firmware(fw_entry);
return status;
}
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
b/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
index 1106ce7..30c2cf7 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
@@ -146,7 +146,10 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
return status;
}
+ /* Copy firmware into DMA-accessible memory */
fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
+ if (!fw)
+ return -ENOMEM;
len = fw_entry->size;
if (len % 4)
@@ -158,6 +161,7 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
rsi_dbg(INIT_ZONE, "%s: num blocks: %d\n", __func__, num_blocks);
status = rsi_copy_to_card(common, fw, len, num_blocks);
+ kfree(fw);
release_firmware(fw_entry);
return status;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
Hi, On Sunday 26 July 2015 08:21 AM, chunfeng yun wrote: > hi, > On Wed, 2015-07-22 at 09:21 -0500, Felipe Balbi wrote: >> Hi, >> >> On Wed, Jul 22, 2015 at 10:05:43PM +0800, Chunfeng Yun wrote: >>> support usb3.0 phy of mt65xx SoCs >>> >>> Signed-off-by: Chunfeng Yun >> >> you missed Kishon here. >> > Thank you. >>> --- >>> drivers/phy/Kconfig | 9 + >>> drivers/phy/Makefile | 1 + >>> drivers/phy/phy-mt65xx-usb3.c | 426 >>> ++ >>> 3 files changed, 436 insertions(+) >>> create mode 100644 drivers/phy/phy-mt65xx-usb3.c >>> >>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig >>> index c0e6ede..019cf8b 100644 >>> --- a/drivers/phy/Kconfig >>> +++ b/drivers/phy/Kconfig >>> @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA >>> help >>> Support for SATA PHY on Hisilicon hix5hd2 Soc. >>> >>> +config PHY_MT65XX_USB3 >>> + tristate "Mediatek USB3.0 PHY Driver" >>> + depends on ARCH_MEDIATEK && OF >>> + select GENERIC_PHY >>> + help >>> + Say 'Y' here to add support for Mediatek USB3.0 PHY driver >>> + for mt65xx SoCs. it supports two usb2.0 ports and >>> + one usb3.0 port. >>> + >>> config PHY_SUN4I_USB >>> tristate "Allwinner sunxi SoC USB PHY driver" >>> depends on ARCH_SUNXI && HAS_IOMEM && OF >>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile >>> index f344e1b..3ceff2a 100644 >>> --- a/drivers/phy/Makefile >>> +++ b/drivers/phy/Makefile >>> @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= >>> phy-ti-pipe3.o >>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o >>> obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o >>> obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o >>> +obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o >>> obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o >>> obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o >>> obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o >>> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c >>> new file mode 100644 >>> index 000..5da4534 >>> --- /dev/null >>> +++ b/drivers/phy/phy-mt65xx-usb3.c >>> @@ -0,0 +1,426 @@ >>> +/* >>> + * Copyright (c) 2015 MediaTek Inc. >>> + * Author: Chunfeng.Yun >>> + * >>> + * This software is licensed under the terms of the GNU General Public >>> + * License version 2, as published by the Free Software Foundation, and >>> + * may be copied, distributed, and modified under those terms. >>> + * >>> + * 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 Lot of these #include are not required. Add only those what are required by this driver. >>> +#include >>> + >>> +/* >>> + * for sifslv2 register >>> + * relative to USB3_SIF2_BASE base address >>> + */ >>> +#define SSUSB_SIFSLV_SPLLC (0x) >>> +#define SSUSB_SIFSLV_U2PHY_COM_BASE(0x0800) Looks like all this base address can come from dt. >>> +#define SSUSB_SIFSLV_U3PHYD_BASE (0x0900) >>> +#define SSUSB_USB30_PHYA_SIV_B_BASE(0x0b00) >>> +#define SSUSB_SIFSLV_U3PHYA_DA_BASE(0x0c00) >>> + >>> +/*port1 refs. +0x800(refer to port0)*/ >>> +#define U3P_PORT_INTERVAL (0x800) /*based on port0 */ >>> +#define U3P_PHY_DELTA(index) ((U3P_PORT_INTERVAL) * (index)) >>> + >>> +#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) >>> +#define PA0_RG_U2PLL_FORCE_ON (0x1 << 15) >>> + >>> +#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) >>> +#define PA2_RG_SIF_U2PLL_FORCE_EN (0x1 << 18) >>> + >>> +#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) >>> +#define PA5_RG_U2_HSTX_SRCTRL (0x7 << 12) >>> +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) >>> +#define PA5_RG_U2_HS_100U_U3_EN(0x1 << 11) >>> + >>> +#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) >>> +#define PA6_RG_U2_ISO_EN (0x1 << 31) >>> +#define PA6_RG_U2_BC11_SW_EN (0x1 << 23) >>> +#define PA6_RG_U2_OTG_VBUSCMP_EN (0x1 << 20) >>> + >>> +#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) >>> +#define P2C_RG_USB20_GPIO_CTL (0x1 << 9) >>> +#define P2C_USB20_GPIO_MODE(0x1 << 8) >>> +#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | >>> P2C_USB20_GPIO_MODE) >>> + >>> +#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) >>> +#define P2C_RG_SIF_U2PLL_FORCE_ON (0x1 << 24) >>> + >>> +#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) >>> +#define P2C_FORCE_UART_EN (0x1 << 26)
Re: [PATCH] perf: fixing variable initialisation
Mathieu Poirier writes:
> Variable 'max_order' needs to be initialised to log2 of the
> number of pages invariant of the no scather-gather PMU option.
> Otherwise 'rb_alloc_aux_page' gets an order that is equal to
> '0', which prevents the private page information to be set
> properly.
But that wouldn't make sense: we're only using the private field in
pages at the bottom of high-order allocations, which only ever happen
for NO_SG devices. Otherwise, every page is the buffer is just an
individual page and doesn't need anything in the private field.
> Signed-off-by: Mathieu Poirier
> ---
> kernel/events/ring_buffer.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> index 96472824a752..bd3da7bebe9e 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -449,18 +449,18 @@ int rb_alloc_aux(struct ring_buffer *rb, struct
> perf_event *event,
> {
> bool overwrite = !(flags & RING_BUFFER_WRITABLE);
> int node = (event->cpu == -1) ? -1 : cpu_to_node(event->cpu);
> - int ret = -ENOMEM, max_order = 0;
> + int ret = -ENOMEM, max_order;
>
> if (!has_aux(event))
> return -ENOTSUPP;
>
> - if (event->pmu->capabilities & PERF_PMU_CAP_AUX_NO_SG) {
> - /*
> - * We need to start with the max_order that fits in nr_pages,
> - * not the other way around, hence ilog2() and not get_order.
> - */
> - max_order = ilog2(nr_pages);
> + /*
> + * We need to start with the max_order that fits in nr_pages,
> + * not the other way around, hence ilog2() and not get_order.
> + */
> + max_order = ilog2(nr_pages);
Also, nr_pages here is the whole buffer, but when we do use
page::private, we put an each individual high-order allocation's order
there, not the whole buffer's, which makes sense because you'd need to
know the former to program the HW properly, whereas the latter you'd get
as a parameter to pmu::setup_aux() callback anyway.
Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: sdhci-of-arasan: Get quirks from device tree
On 07/28/2015 03:07 AM, Shawn Lin wrote:
> On 2015/7/27 16:23, Michal Simek wrote:
>> On 07/27/2015 10:04 AM, Shawn Lin wrote:
>>> This patch adds the interface to get quirks from dts, and
>>> there is no need to assign different quirks by condition statement
>>> of arasan IP version.
>>>
>>> Signed-off-by: Shawn Lin
>>> ---
>>>
>>> drivers/mmc/host/sdhci-of-arasan.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c
>>> b/drivers/mmc/host/sdhci-of-arasan.c
>>> index ef5a7d2..db07788 100644
>>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>>> @@ -132,6 +132,7 @@ static SIMPLE_DEV_PM_OPS(sdhci_arasan_dev_pm_ops,
>>> sdhci_arasan_suspend,
>>> static int sdhci_arasan_probe(struct platform_device *pdev)
>>> {
>>> int ret;
>>> +u32 quirktab[2];
>>> struct clk *clk_xin;
>>> struct sdhci_host *host;
>>> struct sdhci_pltfm_host *pltfm_host;
>>> @@ -172,6 +173,12 @@ static int sdhci_arasan_probe(struct
>>> platform_device *pdev)
>>> goto clk_disable_all;
>>> }
>>> +if (of_property_read_u32_array(pdev->dev.of_node,
>>> + "arasan,quirks", [0], 2)) {
>> This is not documented anywhere that's why you should send binding to DT
>> mailing list and get ACK for it.
> Thanks, Michal. You'r right, and forgive me, a green hand, for my
> inappropriate patch.
>>> +host->quirks |= quirktab[0];
>>> +host->quirks2 |= quirktab[1];
>>> +}
>>> +
>>> if (of_device_is_compatible(pdev->dev.of_node,
>>> "arasan,sdhci-4.9a")) {
>>> host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
>>> host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
>>>
>> Also is there any binding which is done in this way?
> Thanks.
> BTW:
> I got a FPGA board w/ a sdhci-arasn emmc controller & PHY IP which can
> support emmc version 5.1.
> But I cannot find any documented details from IP databook for the
> vendor version, such as "sdhci-4.9a".
> The only one is "ACS eMMC5.1 PHY IP uses TSMC ESD I/O protection
> structures TMSC product name
> tphn28hpcgv2od3 Version 120a". Is "sdhci-120a" the version if I add a
> compatib node?
> Kindly hope you can elaborate more ：)
Is this xilinx board? If you look at TRM we have 8.9a arasan IP on Zynq
that's why we are using this compatible string. If you have different IP
version on your board feel free to extend compatible list and add
specific features for this IP.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [RFCv2 3/3] reset: reset-zynq: Adding support for Xilinx Zynq reset controller.
On 07/28/2015 06:59 AM, Moritz Fischer wrote:
> Hi Michal,
>
> On Mon, Jul 27, 2015 at 12:12 AM, Michal Simek wrote:
>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>> This adds a reset controller driver to control the Xilinx Zynq
>>> SoC's various resets.
>>>
>>> Signed-off-by: Moritz Fischer
>>> ---
>>> drivers/reset/Makefile | 1 +
>>> drivers/reset/reset-zynq.c | 142
>>> +
>>> 2 files changed, 143 insertions(+)
>>> create mode 100644 drivers/reset/reset-zynq.c
>>>
>>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>>> index 157d421..3fe50e7 100644
>>> --- a/drivers/reset/Makefile
>>> +++ b/drivers/reset/Makefile
>>> @@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>>> obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
>>> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>>> obj-$(CONFIG_ARCH_STI) += sti/
>>> +obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
>>> diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
>>> new file mode 100644
>>> index 000..05e37f8
>>> --- /dev/null
>>> +++ b/drivers/reset/reset-zynq.c
>>> @@ -0,0 +1,142 @@
>>> +/*
>>> + * Copyright (c) 2015, National Instruments Corp.
>>> + *
>>> + * Xilinx Zynq Reset controller driver
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; version 2 of the License.
>>> + *
>>> + * 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
>>> +
>>> +/* Offsets into SLCR regmap */
>>> +#define SLCR_RST_CTRL_OFFSET 0x200 /* FPGA Software Reset Control */
>>> +
>>> +#define NBANKS 18
>>> +
>>> +struct zynq_reset_data {
>>> + struct regmap *slcr;
>>> + struct reset_controller_dev rcdev;
>>> +};
>>> +
>>> +#define to_zynq_reset_data(p)\
>>> + container_of((p), struct zynq_reset_data, rcdev)
>>> +
>>> +static int zynq_reset_assert(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>>> +
>>> + int bank = id / BITS_PER_LONG;
>>> + int offset = id % BITS_PER_LONG;
>>> +
>>
>> Personally me I would also add debug message here to be simply enabled
>> for easier tracking.
> See below
>>
>>> + regmap_update_bits(priv->slcr,
>>> +SLCR_RST_CTRL_OFFSET + (bank * 4),
>>> +BIT(offset),
>>> +BIT(offset));
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int zynq_reset_deassert(struct reset_controller_dev *rcdev,
>>> +unsigned long id)
>>> +{
>>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>>> +
>>> + int bank = id / BITS_PER_LONG;
>>> + int offset = id % BITS_PER_LONG;
>>> +
>>
>> debug message here too.
> is:
> pr_debug("%s: bank: %u offset %u\n", __func__, bank, offset);
> accetable? Otherwise I'd have to carry around a struct dev* to use dev_dbg()
It is fine for me.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.
On 07/28/2015 07:03 AM, Moritz Fischer wrote: > Hi Michal, > > I agree we need to be careful with changing the bindings. > > On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek wrote: >> Hi Moritz, >> >> On 07/25/2015 02:21 AM, Moritz Fischer wrote: >>> Signed-off-by: Moritz Fischer >>> --- >>> arch/arm/boot/dts/zynq-7000.dtsi| 43 - >> >> This patch is nice in general but every change in binding should be >> discussed separately. There is also necessary to wire them up in the >> driver to do action. That's why I think that will be the best just to >> add the code to slcr and keep others untouched. > > Ok, just to clarify: You'd suggest to just add the rstc as child node > to the slcr, > and leave the other nodes untouched? yes and then add it on case-by-case basis. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
On 07/28/2015 06:55 AM, Moritz Fischer wrote:
> Hi Michal,
>
> On Sun, Jul 26, 2015 at 10:09 PM, Michal Simek wrote:
>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>> Signed-off-by: Moritz Fischer
>>> ---
>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13
>>> +
>>> 1 file changed, 13 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>> new file mode 100644
>>> index 000..ac4499e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>> @@ -0,0 +1,13 @@
>>> +Xilinx Zynq PL Reset Manager
>>
>> here
>>
>>> +
>>> +Required properties:
>>> +- compatible: "xlnx,zynq-reset-pl"
>>
>> Currently it is not just PL reset controller.
>>
>>> +- syscon <>;
>>
>>
>> missing : and please be more descriptive here.
>>
>>> +- #reset-cells: 1
>>> +
>>> +Example:
>>> + rstc: rstc@240 {
>>> + #reset-cells = <1>;
>>> + compatible = "xlnx,zynq-reset-pl";
>>
>> Compatible property should go first.
>>
>> I am missing that reg property
>>
>>> + syscon = <>;
>>> + };
>>>
>>
> Would something like this work:
>
> Xilinx Zynq Reset Manager
>
> The Zynq AP-SoC has several different resets.
>
> See Chapter 26 of the Zynq TRM (UG585) for more information about Zynq resets.
>
> Required properties:
> - compatible: "xlnx,zynq-reset"
> - reg: SLCR offset and size taken via syscon <0x200 0x50>
> - syscon: <>
> This should be a phandle to the Zynq's SLCR register.
> - #reset-cells: Must be 1
>
> The Zynq Reset Manager needs to be a child node of the SLCR.
>
> Example:
> rstc: rstc@200 {
> compatible = "xlnx,zynq-reset";
> reg = <0x200 0x50>;
> #reset-cells = <1>;
> syscon = <>;
> };
Looks good to me.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey
On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > From: S Twiss
> >
> > Add device tree bindings for the DA9062 OnKey driver component
> >
> > Signed-off-by: Steve Twiss
> >
> > ---
> > Changes in V3:
> > - Child driver specifics separated out into separate document
> >in this case ../input/da9062-onkey.txt
> > Changes in V2:
> > - No change
> >
> > This patch applies against linux-next and next-20150708
> >
> >
> > .../devicetree/bindings/input/da9062-onkey.txt | 36
> > ++
> > Documentation/devicetree/bindings/mfd/da9062.txt | 3 ++
>
> I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> 9063, folded into the onkey patch and applied.
Argh, da9062 core is not in mainline yet... OK, below is the patch I
had; if Lee does not pick it up I'll re-apply it when da9062 core hits
mainline.
Thanks.
--
Dmitry
Input: add DA9062 OnKey capability to DA9063 OnKey driver
From: S Twiss
Add DA9062 OnKey support into the existing DA9063 OnKey driver component by
using generic access tables for common register and bit mask definitions.
The following change will add generic register and bit mask support to the
DA9063 OnKey.
The following alterations have been made to the DA9063 OnKey:
- Addition of a da906x_chip_config structure to hold all
generic registers and bitmasks for this type of OnKey component.
- Addition of an struct of_device_id table for DA9063 and DA9062
defaults
- Refactoring functions to use struct da9063_onkey accesses to generic
registers/masks instead of using defines from registers.h
- Re-work of da9063_onkey_probe() to use of_match_node() and
dev_get_regmap() to provide initialisation of generic registers and
masks and access to regmap
Signed-off-by: Steve Twiss
Signed-off-by: Dmitry Torokhov
---
.../devicetree/bindings/input/da9062-onkey.txt | 32 +
drivers/input/misc/Kconfig |8 +
drivers/input/misc/da9063_onkey.c | 129
3 files changed, 140 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt
b/Documentation/devicetree/bindings/input/da9062-onkey.txt
new file mode 100644
index 000..ab0e048
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
@@ -0,0 +1,32 @@
+* Dialog DA9062/63 OnKey Module
+
+This module is part of the DA9062/DA9063. For more details about entire
+chips see Documentation/devicetree/bindings/mfd/da9062.txt and
+Documentation/devicetree/bindings/mfd/da9063.txt
+
+This module provides KEY_POWER, KEY_SLEEP and events.
+
+Required properties:
+
+ - compatible: should be one of:
+ dlg,da9062-onkey
+ dlg,da9063-onkey
+
+Optional properties:
+
+ - dlg,disable-key-power : Disable power-down using a long key-press. If this
+entry exists the OnKey driver will remove support for the KEY_POWER key
+press. If this entry does not exist then by default the key-press
+triggered power down is enabled and the OnKey will support both KEY_POWER
+and KEY_SLEEP.
+
+Example:
+
+ pmic0: da9062@58 {
+
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ dlg,disable-key-power;
+ };
+
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a81..d4b993d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -611,11 +611,11 @@ config INPUT_DA9055_ONKEY
will be called da9055_onkey.
config INPUT_DA9063_ONKEY
- tristate "Dialog DA9063 OnKey"
- depends on MFD_DA9063
+ tristate "Dialog DA9062/63 OnKey"
+ depends on MFD_DA9063 || MFD_DA9062
help
- Support the ONKEY of Dialog DA9063 Power Management IC as an
- input device reporting power button statue.
+ Support the ONKEY of Dialog DA9063 and DA9062 Power Management ICs
+ as an input device capable of reporting the power button status.
To compile this driver as a module, choose M here: the module
will be called da9063_onkey.
diff --git a/drivers/input/misc/da9063_onkey.c
b/drivers/input/misc/da9063_onkey.c
index f577585..8eb697d 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -1,5 +1,5 @@
/*
- * OnKey device driver for DA9063
+ * OnKey device driver for DA9063 and DA9062 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -24,36 +24,96 @@
#include
#include
#include
+#include
+#include
+
+struct da906x_chip_config {
+ /* REGS */
+ int onkey_status;
+ int onkey_pwr_signalling;
+ int onkey_fault_log;
+ int onkey_shutdown;
+ /* MASKS */
+ int onkey_nonkey_mask;
+
RE: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to genalloc
On Tue, 2015-07-28 at 5:21, Scott Wood wrote: > -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, July 28, 2015 5:21 AM > To: Zhao Qiang-B45475 > Cc: lau...@codeaurora.org; linux-kernel@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net; > catalin.mari...@arm.com; Xie Xiaobo-R63061 > Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to > genalloc > > On Mon, 2015-07-27 at 17:57 +0800, Zhao Qiang wrote: > > Where's the part that adds the ability to pass in data to each allocation > call, as per the previous discussion? You means to use gen_pool_alloc_data()? Previously you said that the format of data is algorithm-specific, So I think it is better to handle data in algorithm function. If you still prefer gen_pool_alloc_data(), I will modify it. But there still are details I want to confirm with you. 1. If use gen_pool_alloc_data(), should I pass data as a parameter? 2. Should I count align_mask in gen_pool_alloc_data(), meanwhile, add a align_mask to data as a member? 3. where to define the data, in genalloc.h or caller layer? > > -Scott
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of
function 'ioremap_uc' [-Werror=implicit-function-declaration]
par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
^
drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer
from integer without a cast
par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
^
Caused by commits
3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong
UC")
8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
The latter defines ioremap_uc() for x86 and those architectures that
use asm-generic/io.h - which is not all of them :-( . The former commit
then uses ioremap_uc().
I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/4] x86: modify_ldt improvement, test, and config option
This is intended for x86/urgent. Sorry for taking so long, but it seemed nice to avoid breaking Xen. This fixes the "dazed and confused" issue which was exposed by the CVE-2015-5157 fix. It's also probably a good general attack surface reduction, and it replaces some scary code with IMO less scary code. Also, servers and embedded systems should probably turn off modify_ldt. This makes that possible. Boris, could I get a Tested-by, assuming this works for you? Willy and Kees: I left the config option alone. The -tiny people will like it, and we can always add a sysctl of some sort later. Changes from v4: - Fix Xen even better (patch 1 is new). - Reorder the patches to make a little more sense. Changes from v3: - Hopefully fixed Xen. - Fixed 32-bit test case on 32-bit native kernel. - Fix bogus vumnap for some LDT sizes. - Strengthen test case to check all LDT sizes (catches bogus vunmap). - Lots of cleanups, mostly from Borislav. - Simplify IPI code using on_each_cpu_mask. Changes from v2: - Allocate ldt_struct and the LDT entries separately. This should fix Xen. - Stop using write_ldt_entry, since I'm pretty sure it's unnecessary now that we no longer mutate an in-use LDT. (Xen people, can you check?) Changes from v1: - The config option is new. - The test case is new. - Fixed a missing allocation failure check. - Fixed a use-after-free on fork(). Andy Lutomirski (4): x86/xen: Unmap aliases in xen_alloc_ldt and xen_free_ldt x86/ldt: Make modify_ldt synchronous selftests/x86, x86/ldt: Add a selftest for modify_ldt x86/ldt: Make modify_ldt optional arch/x86/Kconfig | 17 ++ arch/x86/include/asm/desc.h | 15 - arch/x86/include/asm/mmu.h| 5 +- arch/x86/include/asm/mmu_context.h| 68 - arch/x86/kernel/Makefile | 3 +- arch/x86/kernel/cpu/common.c | 4 +- arch/x86/kernel/cpu/perf_event.c | 16 +- arch/x86/kernel/ldt.c | 262 + arch/x86/kernel/process_64.c | 6 +- arch/x86/kernel/step.c| 8 +- arch/x86/power/cpu.c | 3 +- arch/x86/xen/enlighten.c | 12 + kernel/sys_ni.c | 1 + tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/ldt_gdt.c | 520 ++ 15 files changed, 787 insertions(+), 155 deletions(-) create mode 100644 tools/testing/selftests/x86/ldt_gdt.c -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/4] selftests/x86, x86/ldt: Add a selftest for modify_ldt
This tests general modify_ldt behavior (only writes, so far) as
well as synchronous updates via IPI. It fails on old kernels.
I called this ldt_gdt because I'll add set_thread_area tests to
it at some point.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/ldt_gdt.c | 520 ++
2 files changed, 521 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/x86/ldt_gdt.c
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index caa60d56d7d1..4138387b892c 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -4,7 +4,7 @@ include ../lib.mk
.PHONY: all all_32 all_64 warn_32bit_failure clean
-TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
+TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs ldt_gdt
TARGETS_C_32BIT_ONLY := entry_from_vm86
TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
diff --git a/tools/testing/selftests/x86/ldt_gdt.c
b/tools/testing/selftests/x86/ldt_gdt.c
new file mode 100644
index ..c27adfc9ae72
--- /dev/null
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -0,0 +1,520 @@
+/*
+ * ldt_gdt.c - Test cases for LDT and GDT access
+ * Copyright (c) 2015 Andrew Lutomirski
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AR_ACCESSED(1<<8)
+
+#define AR_TYPE_RODATA (0 * (1<<9))
+#define AR_TYPE_RWDATA (1 * (1<<9))
+#define AR_TYPE_RODATA_EXPDOWN (2 * (1<<9))
+#define AR_TYPE_RWDATA_EXPDOWN (3 * (1<<9))
+#define AR_TYPE_XOCODE (4 * (1<<9))
+#define AR_TYPE_XRCODE (5 * (1<<9))
+#define AR_TYPE_XOCODE_CONF(6 * (1<<9))
+#define AR_TYPE_XRCODE_CONF(7 * (1<<9))
+
+#define AR_DPL3(3 * (1<<13))
+
+#define AR_S (1 << 12)
+#define AR_P (1 << 15)
+#define AR_AVL (1 << 20)
+#define AR_L (1 << 21)
+#define AR_DB (1 << 22)
+#define AR_G (1 << 23)
+
+static int nerrs;
+
+static void check_invalid_segment(uint16_t index, int ldt)
+{
+ uint32_t has_limit = 0, has_ar = 0, limit, ar;
+ uint32_t selector = (index << 3) | (ldt << 2) | 3;
+
+ asm ("lsl %[selector], %[limit]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_limit]\n\t"
+"1:"
+: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
+: [selector] "r" (selector));
+ asm ("larl %[selector], %[ar]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_ar]\n\t"
+"1:"
+: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
+: [selector] "r" (selector));
+
+ if (has_limit || has_ar) {
+ printf("[FAIL]\t%s entry %hu is valid but should be invalid\n",
+ (ldt ? "LDT" : "GDT"), index);
+ nerrs++;
+ } else {
+ printf("[OK]\t%s entry %hu is invalid\n",
+ (ldt ? "LDT" : "GDT"), index);
+ }
+}
+
+static void check_valid_segment(uint16_t index, int ldt,
+ uint32_t expected_ar, uint32_t expected_limit,
+ bool verbose)
+{
+ uint32_t has_limit = 0, has_ar = 0, limit, ar;
+ uint32_t selector = (index << 3) | (ldt << 2) | 3;
+
+ asm ("lsl %[selector], %[limit]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_limit]\n\t"
+"1:"
+: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
+: [selector] "r" (selector));
+ asm ("larl %[selector], %[ar]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_ar]\n\t"
+"1:"
+: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
+: [selector] "r" (selector));
+
+ if (!has_limit || !has_ar) {
+ printf("[FAIL]\t%s entry %hu is invalid but should be valid\n",
+ (ldt ? "LDT" : "GDT"), index);
+ nerrs++;
+ return;
+ }
+
+ if (ar != expected_ar) {
+ printf("[FAIL]\t%s entry %hu has AR 0x%08X but expected
0x%08X\n",
+ (ldt ? "LDT" : "GDT"), index, ar, expected_ar);
+ nerrs++;
+ } else if (limit != expected_limit) {
+ printf("[FAIL]\t%s entry %hu has limit 0x%08X but expected
0x%08X\n",
+ (ldt ? "LDT" : "GDT"), index, limit, expected_limit);
+ nerrs++;
+ } else if (verbose) {
+ printf("[OK]\t%s entry %hu has AR 0x%08X and limit 0x%08X\n",
+ (ldt ? "LDT" : "GDT"), index, ar, limit);
+ }
+}
+
+static bool install_valid_mode(const struct user_desc *desc,
Re: [PATCH v4 7/7] arm64: dts: mt8173: Add subsystem clock controller device nodes
On Mon, 2015-07-27 at 03:21 -0700, Matthias Brugger wrote:
> On Monday, July 27, 2015 10:56:22 AM James Liao wrote:
> > Hi Daniel,
> >
> > On Fri, 2015-07-24 at 19:32 +0800, Daniel Kurtz wrote:
> > > > @@ -88,6 +88,13 @@
> > > >
> > > > #clock-cells = <0>;
> > > >
> > > > };
> > > >
> > > > + cpum_ck: dummy_clk {
> > >
> > > I'm not a big fan of this "dummy_clk".
> > > The 'name' part of the devicetree node is supposed to be generic.
> > > So, perhaps just oscillator@2, and move it down below clk32k:
> > > oscillator@1.
> >
> > > Otherwise:
> > cpum_ck is a test clock which only available in IC test. It's empty on
> > MT8173 evaluation or production boards. Should we name this kind of
> > empty clock as an oscillator? Or is there a better name for it?
> >
>
> So if it will never be part of any available boards, why do you want to add
> it?
infra_cpum is a clock gate, and its clock comes from an external clock.
In previous versions we named the external clock as "clk_null", but it's
not accepted. A specified name is preferred even it's not available on
some boards. So I named it as cpum_ck in this patch.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 4/4] x86/ldt: Make modify_ldt optional
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig | 17 +
arch/x86/include/asm/mmu.h | 2 ++
arch/x86/include/asm/mmu_context.h | 31 +++
arch/x86/kernel/Makefile | 3 ++-
arch/x86/kernel/cpu/perf_event.c | 4
arch/x86/kernel/process_64.c | 2 ++
arch/x86/kernel/step.c | 2 ++
kernel/sys_ni.c| 1 +
8 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d77d92..ede52be845db 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1015,6 +1015,7 @@ config VM86
config X86_16BIT
bool "Enable support for 16-bit segments" if EXPERT
default y
+ depends on MODIFY_LDT_SYSCALL
---help---
This option is required by programs like Wine to run 16-bit
protected mode legacy code on x86 processors. Disabling
@@ -2053,6 +2054,22 @@ config CMDLINE_OVERRIDE
This is used to work around broken boot loaders. This should
be set to 'N' under normal conditions.
+config MODIFY_LDT_SYSCALL
+ bool "Enable the LDT (local descriptor table)" if EXPERT
+ default y
+ ---help---
+ Linux can allow user programs to install a per-process x86
+Local Descriptor Table (LDT) using the modify_ldt(2) system
+call. This is required to run 16-bit or segmented code such as
+DOSEMU or some Wine programs. It is also used by some very old
+threading libraries.
+
+Enabling this feature adds a small amount of overhead to
+context switches and increases the low-level kernel attack
+surface. Disabling it removes the modify_ldt(2) system call.
+
+Saying 'N' here may make sense for embedded or server kernels.
+
source "kernel/livepatch/Kconfig"
endmenu
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 364d27481a52..55234d5e7160 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,7 +9,9 @@
* we put the segment information here.
*/
typedef struct {
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
+#endif
#ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 3fcff70c398e..08094eded318 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -33,6 +33,7 @@ static inline void load_mm_cr4(struct mm_struct *mm)
static inline void load_mm_cr4(struct mm_struct *mm) {}
#endif
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
/*
* ldt_structs can be allocated, used, and freed, but they are never
* modified while live.
@@ -48,10 +49,24 @@ struct ldt_struct {
int size;
};
+/*
+ * Used for LDT copy/destruction.
+ */
+int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
+void destroy_context(struct mm_struct *mm);
+#else /* CONFIG_MODIFY_LDT_SYSCALL */
+static inline int init_new_context(struct task_struct *tsk,
+ struct mm_struct *mm)
+{
+ return 0;
+}
+static inline void destroy_context(struct mm_struct *mm) {}
+#endif
+
static inline void load_mm_ldt(struct mm_struct *mm)
{
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
- DEBUG_LOCKS_WARN_ON(!irqs_disabled());
/* lockless_dereference synchronizes with smp_store_release */
ldt = lockless_dereference(mm->context.ldt);
@@ -74,14 +89,12 @@ static inline void load_mm_ldt(struct mm_struct *mm)
set_ldt(ldt->entries, ldt->size);
else
clear_LDT();
-}
-
-/*
- * Used for LDT copy/destruction.
- */
-int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
-void destroy_context(struct mm_struct *mm);
+#else
+ clear_LDT();
+#endif
+ DEBUG_LOCKS_WARN_ON(!irqs_disabled());
+}
static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
*tsk)
{
@@ -113,6 +126,7 @@ static inline void switch_mm(struct mm_struct *prev, struct
mm_struct *next,
/* Load per-mm CR4 state */
load_mm_cr4(next);
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
/*
* Load the LDT, if the LDT is different.
*
@@ -127,6 +141,7 @@ static inline void switch_mm(struct mm_struct *prev, struct
mm_struct *next,
*/
if (unlikely(prev->context.ldt != next->context.ldt))
load_mm_ldt(next);
+#endif
}
#ifdef CONFIG_SMP
else {
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0f15af41bd80..2b507befcd3f 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -24,7 +24,8 @@ CFLAGS_irq.o :=
[PATCH v5 1/4] x86/xen: Unmap aliases in xen_alloc_ldt and xen_free_ldt
I've been able to get an unmodified Xen guest to OOPS once after a lot of test iterations without this patch. I think this patch fixes the problem. I'm a bit surprised that we don't see much more severe LDT problems on Xen without this fix. Once the synchronous modify_ldt code causes modify_ldt to more aggressively reallocate the LDT, the OOPSes become much more common without this fix. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski --- arch/x86/xen/enlighten.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 0b95c9b8283f..e417d08c56c4 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -512,6 +513,10 @@ static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) for(i = 0; i < entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); + + /* If there are stray aliases, the LDT won't work. */ + if (is_vmalloc_addr(ldt)) + vm_unmap_aliases(); } static void xen_free_ldt(struct desc_struct *ldt, unsigned entries) @@ -519,6 +524,13 @@ static void xen_free_ldt(struct desc_struct *ldt, unsigned entries) const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* The set_aliased_prot call may OOPS due to a hypercall failure +* if there are any lazy vmap aliases of the page. We don't +* need to call vm_unmap_aliases() here, though, because we +* already eliminated any aliases in xen_alloc_ldt. +*/ + for(i = 0; i < entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL); } -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/4] x86/ldt: Make modify_ldt synchronous
modify_ldt has questionable locking and does not synchronize
threads. Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.
This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/desc.h| 15 ---
arch/x86/include/asm/mmu.h | 3 +-
arch/x86/include/asm/mmu_context.h | 53 +++-
arch/x86/kernel/cpu/common.c | 4 +-
arch/x86/kernel/cpu/perf_event.c | 12 +-
arch/x86/kernel/ldt.c | 262 -
arch/x86/kernel/process_64.c | 4 +-
arch/x86/kernel/step.c | 6 +-
arch/x86/power/cpu.c | 3 +-
9 files changed, 209 insertions(+), 153 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a0bf89fd2647..4e10d73cf018 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
}
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
- set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
- preempt_disable();
- load_LDT_nolock(pc);
- preempt_enable();
-}
-
static inline unsigned long get_desc_base(const struct desc_struct *desc)
{
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2)
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 09b9620a73b4..364d27481a52 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
* we put the segment information here.
*/
typedef struct {
- void *ldt;
- int size;
+ struct ldt_struct *ldt;
#ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 804a3a6030ca..3fcff70c398e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,49 @@ static inline void load_mm_cr4(struct mm_struct *mm) {}
#endif
/*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+ /*
+* Xen requires page-aligned LDTs with special permissions. This is
+* needed to prevent us from installing evil descriptors such as
+* call gates. On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+ struct desc_struct *entries;
+ int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+ struct ldt_struct *ldt;
+ DEBUG_LOCKS_WARN_ON(!irqs_disabled());
+
+ /* lockless_dereference synchronizes with smp_store_release */
+ ldt = lockless_dereference(mm->context.ldt);
+
+ /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active. The LDT will not be freed until
+* after the IPI is handled by all such CPUs. This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we don't want to change
+* the local LDT after an IPI loaded a newer value than the one
+* that we can see.
+*/
+
+ if (unlikely(ldt))
+ set_ldt(ldt->entries, ldt->size);
+ else
+ clear_LDT();
+}
+
+/*
* Used for LDT copy/destruction.
*/
int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
@@ -78,12 +121,12 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
* was called and then modify_ldt changed
* prev->context.ldt but suppressed an IPI to this CPU.
* In this case, prev->context.ldt != NULL, because we
-* never free an LDT while the mm still exists. That
-* means that next->context.ldt != prev->context.ldt,
-* because mms never share an LDT.
+* never set context.ldt to NULL while the mm still
+* exists. That means that next->context.ldt !=
+* prev->context.ldt, because mms never share an LDT.
*/
if (unlikely(prev->context.ldt != next->context.ldt))
- load_LDT_nolock(>context);
+ load_mm_ldt(next);
}
#ifdef CONFIG_SMP
else {
@@ -106,7 +149,7 @@ static inline void
Re: [PATCH V3 0/8] clean up wlan_bssdef.h
Something horrible seems to have happened in your patch sending process, and you have the same message over and over. Also, you don't really need to seen the patch to everyone who has ever touched the file. The following arguments can be useful: --nokeywords --nogit --nogit-fallback --norolestats julia On Mon, 27 Jul 2015, Joshua Clayton wrote: > The main goal of this series is to get rid of a needless typedef > in the rtl8712 wlan driver. > > In the course of fixing that, I found a bug that can (at least in theory) > lead to a overrun during a memcpy, as well as an identical struct with > a different name, which use the typedef. > Finally after cleaning up the typedef, change the name of the primary > variable that used the typedef from "SupportedRates" to "rates", to > conform to kernel coding style. > > Changes since V1: > Do not make other logic changes while Changing the name of SupportedRates > New patch 3/6 fixes a buggy comment that referred to the typedef > > Changes sinve V2: > broke former patch 4, which was too big for git-send-email into 3 parts > > Joshua Clayton (8): > staging: rtl8712: fix buggy size calculation > staging: rtl8712: simplify size calculation > staging: rtl8712: fix comment > staging: rtl8712: removed unused wrapper structs > staging: rtl8712: remove duplicate struct > staging: rtl8712: rename function > staging: rtl8712: remove typedefs > staging: rtl8712: change SupportedRates to rates > > drivers/staging/rtl8712/ieee80211.c | 22 ++--- > drivers/staging/rtl8712/rtl871x_cmd.c | 28 +--- > drivers/staging/rtl8712/rtl871x_cmd.h | 18 -- > drivers/staging/rtl8712/rtl871x_event.h | 2 +- > drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 36 ++-- > drivers/staging/rtl8712/rtl871x_mlme.c| 47 > ++- > drivers/staging/rtl8712/rtl871x_mlme.h| 2 +- > drivers/staging/rtl8712/rtl871x_mp_ioctl.c| 6 ++-- > drivers/staging/rtl8712/wlan_bssdef.h | 42 +++- > 9 files changed, 64 insertions(+), 139 deletions(-) > > -- > 2.4.6 > > From: Joshua Clayton > To: Larry Finger , > Florian Schilhabel , > Greg Kroah-Hartman , > Sudip Mukherjee , > Nitin Kuppelur , > Joshua Clayton , > Vaishali Thakkar , > Tapasweni Pathak , > Daniel Baluta , > Melike Yurtoglu , > Max Perepelitsyn , > Aya Mahfouz , > Cristina Opriceana , > Dogukan Ergun , > Julia Lawall , > Dan Carpenter , > Haneen Mohammed , > Rickard Strandqvist > Cc: de...@driverdev.osuosl.org, > linux-kernel@vger.kernel.org > Subject: [PATCH V3 0/8] clean up wlan_bssdef.h > Date: Mon, 27 Jul 2015 21:41:09 -0700 > Message-Id: > X-Mailer: git-send-email 2.4.6 > > The main goal of this series is to get rid of a needless typedef > in the rtl8712 wlan driver. > > In the course of fixing that, I found a bug that can (at least in theory) > lead to a overrun during a memcpy, as well as an identical struct with > a different name, which use the typedef. > Finally after cleaning up the typedef, change the name of the primary > variable that used the typedef from "SupportedRates" to "rates", to > conform to kernel coding style. > > Changes since V1: > Do not make other logic changes while Changing the name of SupportedRates > New patch 3/6 fixes a buggy comment that referred to the typedef > > Changes sinve V2: > broke former patch 4, which was too big for git-send-email into 3 parts > > Joshua Clayton (8): > staging: rtl8712: fix buggy size calculation > staging: rtl8712: simplify size calculation > staging: rtl8712: fix comment > staging: rtl8712: removed unused wrapper structs > staging: rtl8712: remove duplicate struct > staging: rtl8712: rename function > staging: rtl8712: remove typedefs > staging: rtl8712: change SupportedRates to rates > > drivers/staging/rtl8712/ieee80211.c | 22 ++--- > drivers/staging/rtl8712/rtl871x_cmd.c | 28 +--- > drivers/staging/rtl8712/rtl871x_cmd.h | 18 -- > drivers/staging/rtl8712/rtl871x_event.h | 2 +- > drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 36 ++-- > drivers/staging/rtl8712/rtl871x_mlme.c| 47 > ++- > drivers/staging/rtl8712/rtl871x_mlme.h| 2 +- > drivers/staging/rtl8712/rtl871x_mp_ioctl.c| 6 ++-- > drivers/staging/rtl8712/wlan_bssdef.h | 42 +++- > 9 files changed, 64 insertions(+), 139 deletions(-) > > -- > 2.4.6 > > From: Joshua Clayton > To: Larry Finger , > Florian Schilhabel , > Greg Kroah-Hartman , > Sudip Mukherjee , > Nitin Kuppelur , > Joshua Clayton , > Vaishali Thakkar , > Tapasweni Pathak , > Daniel Baluta , > Melike Yurtoglu , > Max Perepelitsyn , > Aya
[PATCH 2/2] tools/power/acpi: Enable build for EC userspace tool.
This patch allows EC userspace tool to be built as an ACPI tool.
Signed-off-by: Lv Zheng
---
tools/power/acpi/Makefile | 16
tools/power/acpi/tools/ec/Makefile | 33 ++---
2 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/tools/power/acpi/Makefile b/tools/power/acpi/Makefile
index 3d05237..e882c83 100644
--- a/tools/power/acpi/Makefile
+++ b/tools/power/acpi/Makefile
@@ -10,18 +10,18 @@
include ../../scripts/Makefile.include
-all: acpidump
-clean: acpidump_clean
-install: acpidump_install
-uninstall: acpidump_uninstall
+all: acpidump ec
+clean: acpidump_clean ec_clean
+install: acpidump_install ec_install
+uninstall: acpidump_uninstall ec_uninstall
-acpidump: FORCE
+acpidump ec: FORCE
$(call descend,tools/$@,all)
-acpidump_clean:
+acpidump_clean ec_clean:
$(call descend,tools/$(@:_clean=),clean)
-acpidump_install:
+acpidump_install ec_install:
$(call descend,tools/$(@:_install=),install)
-acpidump_uninstall:
+acpidump_uninstall ec_uninstall:
$(call descend,tools/$(@:_uninstall=),uninstall)
.PHONY: FORCE
diff --git a/tools/power/acpi/tools/ec/Makefile
b/tools/power/acpi/tools/ec/Makefile
index b7b0b92..75d8a12 100644
--- a/tools/power/acpi/tools/ec/Makefile
+++ b/tools/power/acpi/tools/ec/Makefile
@@ -1,22 +1,17 @@
-ec_access: ec_access.o
- $(ECHO) " LD " $@
- $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $< -o $@
- $(QUIET) $(STRIPCMD) $@
+# tools/power/acpi/tools/acpidump/Makefile - ACPI tool Makefile
+#
+# Copyright (c) 2015, Intel Corporation
+# Author: Lv Zheng
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; version 2
+# of the License.
-%.o: %.c
- $(ECHO) " CC " $@
- $(QUIET) $(CC) -c $(CFLAGS) -o $@ $<
+include ../../Makefile.config
-all: ec_access
+TOOL = ec
+TOOL_OBJS = \
+ ec_access.o
-install:
- $(INSTALL) -d $(DESTDIR)${sbindir}
- $(INSTALL_PROGRAM) ec_access $(DESTDIR)${sbindir}
-
-uninstall:
- - rm -f $(DESTDIR)${sbindir}/ec_access
-
-clean:
- -rm -f $(OUTPUT)ec_access
-
-.PHONY: all install uninstall
+include ../../Makefile.rules
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] tools/power/acpi: Add descend support in ACPI tools Makefile.
This patch splits tools/power/acpi/Makefile to support descend compling for
ACPI tools. In this patch tools/ec related stuff is removed as it is
originally not enabled.
Also a missing .o (utnonansi.o) is added to the acpidump/Makefile.
Signed-off-by: Lv Zheng
---
tools/power/acpi/Makefile| 168 +++---
tools/power/acpi/Makefile.config | 92
tools/power/acpi/Makefile.rules | 37 +++
tools/power/acpi/tools/acpidump/Makefile | 53 ++
4 files changed, 199 insertions(+), 151 deletions(-)
create mode 100644 tools/power/acpi/Makefile.config
create mode 100644 tools/power/acpi/Makefile.rules
create mode 100644 tools/power/acpi/tools/acpidump/Makefile
diff --git a/tools/power/acpi/Makefile b/tools/power/acpi/Makefile
index 3d1537b..3d05237 100644
--- a/tools/power/acpi/Makefile
+++ b/tools/power/acpi/Makefile
@@ -8,154 +8,20 @@
# as published by the Free Software Foundation; version 2
# of the License.
-OUTPUT=./
-ifeq ("$(origin O)", "command line")
- OUTPUT := $(O)/
-endif
-
-ifneq ($(OUTPUT),)
-# check that the output directory actually exists
-OUTDIR := $(shell cd $(OUTPUT) && /bin/pwd)
-$(if $(OUTDIR),, $(error output directory "$(OUTPUT)" does not exist))
-endif
-
-SUBDIRS = tools/ec
-
-# --- CONFIGURATION BEGIN ---
-
-# Set the following to `true' to make a unstripped, unoptimized
-# binary. Leave this set to `false' for production use.
-DEBUG ?= true
-
-# make the build silent. Set this to something else to make it noisy again.
-V ?= false
-
-# Prefix to the directories we're installing to
-DESTDIR ?=
-
-# --- CONFIGURATION END ---
-
-# Directory definitions. These are default and most probably
-# do not need to be changed. Please note that DESTDIR is
-# added in front of any of them
-
-bindir ?= /usr/bin
-sbindir ?= /usr/sbin
-mandir ?= /usr/man
-
-# Toolchain: what tools do we use, and what options do they need:
-
-INSTALL = /usr/bin/install -c
-INSTALL_PROGRAM = ${INSTALL}
-INSTALL_DATA = ${INSTALL} -m 644
-INSTALL_SCRIPT = ${INSTALL_PROGRAM}
-
-# If you are running a cross compiler, you may want to set this
-# to something more interesting, like "arm-linux-". If you want
-# to compile vs uClibc, that can be done here as well.
-CROSS = #/usr/i386-linux-uclibc/usr/bin/i386-uclibc-
-CC = $(CROSS)gcc
-LD = $(CROSS)gcc
-STRIP = $(CROSS)strip
-HOSTCC = gcc
-
-# check if compiler option is supported
-cc-supports = ${shell if $(CC) ${1} -S -o /dev/null -x c /dev/null > /dev/null
2>&1; then echo "$(1)"; fi;}
-
-# use '-Os' optimization if available, else use -O2
-OPTIMIZATION := $(call cc-supports,-Os,-O2)
-
-WARNINGS := -Wall
-WARNINGS += $(call cc-supports,-Wstrict-prototypes)
-WARNINGS += $(call cc-supports,-Wdeclaration-after-statement)
-
-KERNEL_INCLUDE := ../../../include
-ACPICA_INCLUDE := ../../../drivers/acpi/acpica
-CFLAGS += -D_LINUX -I$(KERNEL_INCLUDE) -I$(ACPICA_INCLUDE)
-CFLAGS += $(WARNINGS)
-
-ifeq ($(strip $(V)),false)
- QUIET=@
- ECHO=@echo
-else
- QUIET=
- ECHO=@\#
-endif
-export QUIET ECHO
-
-# if DEBUG is enabled, then we do not strip or optimize
-ifeq ($(strip $(DEBUG)),true)
- CFLAGS += -O1 -g -DDEBUG
- STRIPCMD = /bin/true -Since_we_are_debugging
-else
- CFLAGS += $(OPTIMIZATION) -fomit-frame-pointer
- STRIPCMD = $(STRIP) -s --remove-section=.note --remove-section=.comment
-endif
-
-# --- ACPIDUMP BEGIN ---
-
-vpath %.c \
- ../../../drivers/acpi/acpica\
- tools/acpidump\
- common\
- os_specific/service_layers
-
-CFLAGS += -DACPI_DUMP_APP -Itools/acpidump
-
-DUMP_OBJS = \
- apdump.o\
- apfiles.o\
- apmain.o\
- osunixdir.o\
- osunixmap.o\
- osunixxf.o\
- tbprint.o\
- tbxfroot.o\
- utbuffer.o\
- utdebug.o\
- utexcep.o\
- utglobal.o\
- utmath.o\
- utprint.o\
- utstring.o\
- utxferror.o\
- oslibcfs.o\
- oslinuxtbl.o\
- cmfsize.o\
- getopt.o
-
-DUMP_OBJS := $(addprefix $(OUTPUT)tools/acpidump/,$(DUMP_OBJS))
-
-$(OUTPUT)acpidump: $(DUMP_OBJS)
- $(ECHO) " LD " $@
- $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(DUMP_OBJS) -L$(OUTPUT) -o $@
- $(QUIET) $(STRIPCMD) $@
-
-$(OUTPUT)tools/acpidump/%.o: %.c
- $(ECHO) " CC " $@
- $(QUIET) $(CC) -c $(CFLAGS) -o $@ $<
-
-# --- ACPIDUMP END ---
-
-all: $(OUTPUT)acpidump
- echo $(OUTPUT)
-
-clean:
- -find $(OUTPUT) \( -not -type d \) -and \( -name '*~' -o -name
'*.[oas]' \) -type f -print \
-| xargs rm -f
- -rm -f $(OUTPUT)acpidump
-
-install-tools:
- $(INSTALL) -d $(DESTDIR)${sbindir}
- $(INSTALL_PROGRAM) $(OUTPUT)acpidump $(DESTDIR)${sbindir}
-
-install-man:
- $(INSTALL_DATA) -D man/acpidump.8 $(DESTDIR)${mandir}/man8/acpidump.8
-
-install: all install-tools install-man
-
-uninstall:
- - rm -f $(DESTDIR)${sbindir}/acpidump
- - rm -f
Re: [PATCH] cpufreq: Correct a freq check in cpufreq_set_policy
On 28-07-15, 11:34, Pan Xinhui wrote:
> From: Pan Xinhui
>
> This check was originally added by commit 9c9a43ed2734 ("[CPUFREQ]
> return error when failing to set minfreq").It attempt to return an error
> on obviously incorrect limits when we echo xxx >.../scaling_max,min_freq
> Actually we just need check if new_policy->min > new_policy->max.
> Because at least one of max/min is copied from cpufreq_get_policy().
>
> For example, when we echo xxx > .../scaling_min_freq, new_policy is
> copied from policy in cpufreq_get_policy. new_policy->max is same with
> policy->max. new_policy->min is set to a new value.
>
> Let me explain it in deduction method, first statment in if ():
> new_policy->min > policy->max
> policy->max == new_policy->max
> ==> new_policy->min > new_policy->max
>
> second statment in if():
> new_policy->max < policy->min
> policy->max < policy->min
> ==>new_policy->min > new_policy->max (induction method)
>
> So we have proved that we only need check if new_policy->min >
> new_policy->max.
>
> After apply this patch, we can also modify ->min and ->max in same time
> if new freq range is very much different from current freq range. For
> example, if current freq range is 48-96, then we want to set
> this range to 112-224, we would fail in the past because
> new_policy->min > policy->max. As long as the cpufreq range is valid, we
> has no reason to reject the user. So correct the check.
>
> Signed-off-by: Pan Xinhui
> ---
> drivers/cpufreq/cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 6424e05..8772346 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2276,7 +2276,7 @@ static int cpufreq_set_policy(struct cpufreq_policy
> *policy,
>
> memcpy(_policy->cpuinfo, >cpuinfo, sizeof(policy->cpuinfo));
>
> - if (new_policy->min > policy->max || new_policy->max < policy->min)
> + if (new_policy->min > new_policy->max)
> return -EINVAL;
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] tools/power/acpi: Fix ACPI tools build issues.
Currently tools/power/acpi is broken: 1. acpidump build is broken because utnonansi.o is not linked. 2. ec build is broken because descend build is not supported. This patch fixes the above issues. Lv Zheng (2): tools/power/acpi: Add descend support in ACPI tools Makefile. tools/power/acpi: Enable build for EC userspace tool. tools/power/acpi/Makefile| 168 +++--- tools/power/acpi/Makefile.config | 92 tools/power/acpi/Makefile.rules | 37 +++ tools/power/acpi/tools/acpidump/Makefile | 53 ++ tools/power/acpi/tools/ec/Makefile | 33 +++--- 5 files changed, 213 insertions(+), 170 deletions(-) create mode 100644 tools/power/acpi/Makefile.config create mode 100644 tools/power/acpi/Makefile.rules create mode 100644 tools/power/acpi/tools/acpidump/Makefile -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] usb: gadget: f_mass_storage: check quirk instead of UDC name
Use generic mechanism to check if UDC controller supports stalling. Signed-off-by: Robert Baldyga --- drivers/usb/gadget/function/f_mass_storage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c index 9e88e2b..a229194 100644 --- a/drivers/usb/gadget/function/f_mass_storage.c +++ b/drivers/usb/gadget/function/f_mass_storage.c @@ -2836,7 +2836,8 @@ int fsg_common_set_cdev(struct fsg_common *common, * halt bulk endpoints correctly. If one of them is present, * disable stalls. */ - common->can_stall = can_stall && !(gadget_is_at91(common->gadget)); + common->can_stall = can_stall && + gadget_is_stall_supported(common->gadget); return 0; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] usb: gadget: remove gadget_chips.h
This header file contains helpers for quirks based on UDC controller name. Since we have generic quirk bitfields in usb_gadget structure for all of these quirks we don't need to have this header any longer. This patch removes gadget_chips.h file and makes sure that it's no longer included anywhere in kernel sources. Signed-off-by: Robert Baldyga --- drivers/usb/gadget/epautoconf.c | 2 - drivers/usb/gadget/function/f_acm.c | 1 - drivers/usb/gadget/function/f_mass_storage.c | 1 - drivers/usb/gadget/function/f_obex.c | 1 - drivers/usb/gadget/function/f_serial.c | 1 - drivers/usb/gadget/function/f_sourcesink.c | 1 - drivers/usb/gadget/function/u_ether.h| 2 - drivers/usb/gadget/function/u_uac1.h | 2 - drivers/usb/gadget/legacy/audio.c| 1 - drivers/usb/gadget/legacy/gmidi.c| 2 - drivers/usb/gadget/legacy/hid.c | 1 - drivers/usb/gadget/legacy/nokia.c| 1 - drivers/usb/gadget/legacy/printer.c | 2 - drivers/usb/gadget/legacy/serial.c | 1 - drivers/usb/gadget/udc/gadget_chips.h| 55 15 files changed, 74 deletions(-) delete mode 100644 drivers/usb/gadget/udc/gadget_chips.h diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 254ece7..bde091f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -20,8 +20,6 @@ #include #include -#include "gadget_chips.h" - /** * usb_ep_autoconfig_ss() - choose an endpoint matching the ep * descriptor and ep companion descriptor diff --git a/drivers/usb/gadget/function/f_acm.c b/drivers/usb/gadget/function/f_acm.c index aad8165..be9df09 100644 --- a/drivers/usb/gadget/function/f_acm.c +++ b/drivers/usb/gadget/function/f_acm.c @@ -21,7 +21,6 @@ #include #include "u_serial.h" -#include "gadget_chips.h" /* diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c index a229194..b85e82f 100644 --- a/drivers/usb/gadget/function/f_mass_storage.c +++ b/drivers/usb/gadget/function/f_mass_storage.c @@ -219,7 +219,6 @@ #include #include -#include "gadget_chips.h" #include "configfs.h" diff --git a/drivers/usb/gadget/function/f_obex.c b/drivers/usb/gadget/function/f_obex.c index 2682d59..5460426 100644 --- a/drivers/usb/gadget/function/f_obex.c +++ b/drivers/usb/gadget/function/f_obex.c @@ -20,7 +20,6 @@ #include #include "u_serial.h" -#include "gadget_chips.h" /* diff --git a/drivers/usb/gadget/function/f_serial.c b/drivers/usb/gadget/function/f_serial.c index 2e02dfa..1d162e2 100644 --- a/drivers/usb/gadget/function/f_serial.c +++ b/drivers/usb/gadget/function/f_serial.c @@ -16,7 +16,6 @@ #include #include "u_serial.h" -#include "gadget_chips.h" /* diff --git a/drivers/usb/gadget/function/f_sourcesink.c b/drivers/usb/gadget/function/f_sourcesink.c index e6af171..cbfaf86 100644 --- a/drivers/usb/gadget/function/f_sourcesink.c +++ b/drivers/usb/gadget/function/f_sourcesink.c @@ -20,7 +20,6 @@ #include #include "g_zero.h" -#include "gadget_chips.h" #include "u_f.h" /* diff --git a/drivers/usb/gadget/function/u_ether.h b/drivers/usb/gadget/function/u_ether.h index 1384f00..c77145b 100644 --- a/drivers/usb/gadget/function/u_ether.h +++ b/drivers/usb/gadget/function/u_ether.h @@ -20,8 +20,6 @@ #include #include -#include "gadget_chips.h" - #define QMULT_DEFAULT 5 /* diff --git a/drivers/usb/gadget/function/u_uac1.h b/drivers/usb/gadget/function/u_uac1.h index fe386df..5c2ac8e 100644 --- a/drivers/usb/gadget/function/u_uac1.h +++ b/drivers/usb/gadget/function/u_uac1.h @@ -21,8 +21,6 @@ #include #include -#include "gadget_chips.h" - #define FILE_PCM_PLAYBACK "/dev/snd/pcmC0D0p" #define FILE_PCM_CAPTURE "/dev/snd/pcmC0D0c" #define FILE_CONTROL "/dev/snd/controlC0" diff --git a/drivers/usb/gadget/legacy/audio.c b/drivers/usb/gadget/legacy/audio.c index 9b2c1c6..685cf3b 100644 --- a/drivers/usb/gadget/legacy/audio.c +++ b/drivers/usb/gadget/legacy/audio.c @@ -15,7 +15,6 @@ #include #include -#include "gadget_chips.h" #define DRIVER_DESC"Linux USB Audio Gadget" #define DRIVER_VERSION "Feb 2, 2012" diff --git a/drivers/usb/gadget/legacy/gmidi.c b/drivers/usb/gadget/legacy/gmidi.c index 650568d..8a18348 100644 --- a/drivers/usb/gadget/legacy/gmidi.c +++ b/drivers/usb/gadget/legacy/gmidi.c @@ -35,8 +35,6 @@ #include #include -#include "gadget_chips.h" - #include "u_midi.h" /*-*/ diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c index e4874d3..7e5d2c4 100644 --- a/drivers/usb/gadget/legacy/hid.c +++ b/drivers/usb/gadget/legacy/hid.c @@ -19,7 +19,6 @@ #include #include -#include "gadget_chips.h" #define DRIVER_DESC"HID Gadget" #define
[PATCH 6/7] usb: gadget: apply generic altsetting support check mechanism
Replace calls of gadget_supports_altsettings() function (which check altset
support by comparing UDC controller name with hardcoded names) with
gadget_is_altset_supported() which checks generic quirk bitfield.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_obex.c | 2 +-
drivers/usb/gadget/function/u_ether.h | 2 +-
drivers/usb/gadget/legacy/nokia.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_obex.c
b/drivers/usb/gadget/function/f_obex.c
index 5519f85..2682d59 100644
--- a/drivers/usb/gadget/function/f_obex.c
+++ b/drivers/usb/gadget/function/f_obex.c
@@ -297,7 +297,7 @@ static inline bool can_support_obex(struct
usb_configuration *c)
*
* Altsettings are mandatory, however...
*/
- if (!gadget_supports_altsettings(c->cdev->gadget))
+ if (!gadget_is_altset_supported(c->cdev->gadget))
return false;
/* everything else is *probably* fine ... */
diff --git a/drivers/usb/gadget/function/u_ether.h
b/drivers/usb/gadget/function/u_ether.h
index 334b3894..1384f00 100644
--- a/drivers/usb/gadget/function/u_ether.h
+++ b/drivers/usb/gadget/function/u_ether.h
@@ -259,7 +259,7 @@ void gether_disconnect(struct gether *);
/* Some controllers can't support CDC Ethernet (ECM) ... */
static inline bool can_support_ecm(struct usb_gadget *gadget)
{
- if (!gadget_supports_altsettings(gadget))
+ if (!gadget_is_altset_supported(gadget))
return false;
/* Everything else is *presumably* fine ... but this is a bit
diff --git a/drivers/usb/gadget/legacy/nokia.c
b/drivers/usb/gadget/legacy/nokia.c
index 8902f45..264c97e 100644
--- a/drivers/usb/gadget/legacy/nokia.c
+++ b/drivers/usb/gadget/legacy/nokia.c
@@ -292,7 +292,7 @@ static int nokia_bind(struct usb_composite_dev *cdev)
nokia_config_500ma_driver.iConfiguration = status;
nokia_config_100ma_driver.iConfiguration = status;
- if (!gadget_supports_altsettings(gadget)) {
+ if (!gadget_is_altset_supported(gadget)) {
status = -ENODEV;
goto err_usb;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] usb: gadget: f_ecm/f_ncm: check quirk instead of UDC name
Use generic mechanism to check if UDC controller supports zlp. Signed-off-by: Robert Baldyga --- drivers/usb/gadget/function/f_ecm.c | 4 ++-- drivers/usb/gadget/function/f_ncm.c | 5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/function/f_ecm.c b/drivers/usb/gadget/function/f_ecm.c index 798760f..7b7424f 100644 --- a/drivers/usb/gadget/function/f_ecm.c +++ b/drivers/usb/gadget/function/f_ecm.c @@ -585,8 +585,8 @@ static int ecm_set_alt(struct usb_function *f, unsigned intf, unsigned alt) /* Enable zlps by default for ECM conformance; * override for musb_hdrc (avoids txdma ovhead). */ - ecm->port.is_zlp_ok = !(gadget_is_musbhdrc(cdev->gadget) - ); + ecm->port.is_zlp_ok = + gadget_is_zlp_supported(cdev->gadget); ecm->port.cdc_filter = DEFAULT_FILTER; DBG(cdev, "activate ecm\n"); net = gether_connect(>port); diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index bdcda9f..3f05c6bd 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -853,9 +853,8 @@ static int ncm_set_alt(struct usb_function *f, unsigned intf, unsigned alt) /* Enable zlps by default for NCM conformance; * override for musb_hdrc (avoids txdma ovhead) */ - ncm->port.is_zlp_ok = !( - gadget_is_musbhdrc(cdev->gadget) - ); + ncm->port.is_zlp_ok = + gadget_is_zlp_supported(cdev->gadget); ncm->port.cdc_filter = DEFAULT_FILTER; DBG(cdev, "activate ncm\n"); net = gether_connect(>port); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] usb: gadget: add 'quirk_altset_not_supp' to usb_gadget
Due to some UDC controllers may not support altsettings, usb gadget layer
needs to provide a generic way to inform gadget functions about non-standard
hardware limitations.
This patch adds 'quirk_altset_not_supp' field to struct usb_gadget and helper
function gadget_is_altset_supported(). It also sets 'quirk_altset_not_supp'
to 1 in pxa25x_udc and pxa27x_udc drivers, which have such limitation.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/pxa25x_udc.c | 1 +
drivers/usb/gadget/udc/pxa27x_udc.c | 1 +
include/linux/usb/gadget.h | 11 +++
3 files changed, 13 insertions(+)
diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c
b/drivers/usb/gadget/udc/pxa25x_udc.c
index f53e526..b82cb14 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -1176,6 +1176,7 @@ static void udc_reinit(struct pxa25x_udc *dev)
INIT_LIST_HEAD (>gadget.ep_list);
INIT_LIST_HEAD (>gadget.ep0->ep_list);
dev->ep0state = EP0_IDLE;
+ dev->gadget.quirk_altset_not_supp = 1;
/* basic endpoint records init */
for (i = 0; i < PXA_UDC_NUM_ENDPOINTS; i++) {
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 042f06b..670ac0b 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -1710,6 +1710,7 @@ static void udc_init_data(struct pxa_udc *dev)
INIT_LIST_HEAD(>gadget.ep_list);
INIT_LIST_HEAD(>gadget.ep0->ep_list);
dev->udc_usb_ep[0].pxa_ep = >pxa_ep[0];
+ dev->gadget.quirk_altset_not_supp = 1;
ep0_idle(dev);
/* PXA endpoints init */
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 91b71a3..5362faa 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -617,6 +617,7 @@ struct usb_gadget {
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
unsignedquirk_ep_out_aligned_size:1;
+ unsignedquirk_altset_not_supp:1;
unsignedis_selfpowered:1;
unsigneddeactivated:1;
unsignedconnected:1;
@@ -673,6 +674,16 @@ usb_ep_align_maybe(struct usb_gadget *g, struct usb_ep
*ep, size_t len)
}
/**
+ * gadget_is_altset_supported - return true iff the hardware supports
+ * altsettings
+ * @g: controller to check for quirk
+ */
+static inline int gadget_is_altset_supported(struct usb_gadget *g)
+{
+ return !g->quirk_altset_not_supp;
+}
+
+/**
* gadget_is_dualspeed - return true iff the hardware handles high speed
* @g: controller that might support both high and full speeds
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Add scaling frequency range support
On 28-07-15, 11:32, Pan Xinhui wrote: > From: Pan Xinhui > > Userspace at most time do cpufreq tests very much inconveniently. > Currently they have to echo min and max cpu freq separately like below: > echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq > echo 224 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq > > Add scaling_freq_range cpufreq attr to support userspace's demand. > Therefore it's easier for testers to write readable scripts like below: > echo 48-224 > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_freq_range > > Signed-off-by: Pan Xinhui > --- > drivers/cpufreq/cpufreq.c | 31 +++ > 1 file changed, 31 insertions(+) Okay, code looks fine but please updates Documentation as well. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] usb: gadget: add 'quirk_zlp_not_supp' to usb_gadget
Due to some UDC controllers may not support zlp, usb gadget layer
needs to provide a generic way to inform gadget functions about non-standard
hardware limitations.
This patch adds 'quirk_zlp_not_supp' field to struct usb_gadget and helper
function gadget_is_zlp_supported(). It also sets 'quirk_zlp_not_supp'
to 1 in musb UDC driver, which has such limitation.
Signed-off-by: Robert Baldyga
---
drivers/usb/musb/musb_gadget.c | 1 +
include/linux/usb/gadget.h | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 3a64cf2..4b14ced 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2121,6 +2121,7 @@ __acquires(musb->lock)
musb->g.b_hnp_enable = 0;
musb->g.a_alt_hnp_support = 0;
musb->g.a_hnp_support = 0;
+ musb->quirk_zlp_not_supp = 1;
/* Normal reset, as B-Device;
* or else after HNP, as A-Device
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 55cb6b2..6a413ab 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -619,6 +619,7 @@ struct usb_gadget {
unsignedquirk_ep_out_aligned_size:1;
unsignedquirk_altset_not_supp:1;
unsignedquirk_stall_not_supp:1;
+ unsignedquirk_zlp_not_supp:1;
unsignedis_selfpowered:1;
unsigneddeactivated:1;
unsignedconnected:1;
@@ -694,6 +695,15 @@ static inline int gadget_is_stall_supported(struct
usb_gadget *g)
}
/**
+ * gadget_is_zlp_supported - return true iff the hardware supports zlp
+ * @g: controller to check for quirk
+ */
+static inline int gadget_is_zlp_supported(struct usb_gadget *g)
+{
+ return !g->quirk_zlp_not_supp;
+}
+
+/**
* gadget_is_dualspeed - return true iff the hardware handles high speed
* @g: controller that might support both high and full speeds
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] usb: gadget: add 'quirk_stall_not_supp' to usb_gadget
Due to some UDC controllers may not support stalling, usb gadget layer
needs to provide a generic way to inform gadget functions about non-standard
hardware limitations.
This patch adds 'quirk_stall_not_supp' field to struct usb_gadget and helper
function gadget_is_stall_supported(). It also sets 'quirk_stall_not_supp'
to 1 in at91_udc driver, which has such limitation.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/at91_udc.c | 1 +
include/linux/usb/gadget.h| 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index a04b073..f663dce 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -839,6 +839,7 @@ static void udc_reinit(struct at91_udc *udc)
INIT_LIST_HEAD(>gadget.ep_list);
INIT_LIST_HEAD(>gadget.ep0->ep_list);
+ udc->gadget.quirk_stall_not_supp = 1;
for (i = 0; i < NUM_ENDPOINTS; i++) {
struct at91_ep *ep = >ep[i];
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 5362faa..55cb6b2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -618,6 +618,7 @@ struct usb_gadget {
unsigneda_alt_hnp_support:1;
unsignedquirk_ep_out_aligned_size:1;
unsignedquirk_altset_not_supp:1;
+ unsignedquirk_stall_not_supp:1;
unsignedis_selfpowered:1;
unsigneddeactivated:1;
unsignedconnected:1;
@@ -684,6 +685,15 @@ static inline int gadget_is_altset_supported(struct
usb_gadget *g)
}
/**
+ * gadget_is_stall_supported - return true iff the hardware supports stalling
+ * @g: controller to check for quirk
+ */
+static inline int gadget_is_stall_supported(struct usb_gadget *g)
+{
+ return !g->quirk_stall_not_supp;
+}
+
+/**
* gadget_is_dualspeed - return true iff the hardware handles high speed
* @g: controller that might support both high and full speeds
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] usb: gadget: get rid of UDC name-based quirks
Hello, This patch set replaces quirks based on UDC name with generic quirk bitfields in struct usb_gadget. It allows to avoid checking for UDC name in USB function drivers. Instead we have few quirk bitfields informing rather about chip-specific limitations than specific chip name. Thanks to this it's possible to handle new chips with similar hardware limitations without changing code of USB functions. IMPORTANT This patch set depends on my previous patch series. They should be applied in following order: 1. "usb: gadget: miscellaneous fixes" https://lkml.org/lkml/2015/7/13/122 2. "usb: gadget: rework ep matching and claiming mechanism" https://lkml.org/lkml/2015/7/27/181 3. this patchset Best regards, Robert Baldyga Robert Baldyga (7): usb: gadget: add 'quirk_altset_not_supp' to usb_gadget usb: gadget: add 'quirk_stall_not_supp' to usb_gadget usb: gadget: add 'quirk_zlp_not_supp' to usb_gadget usb: gadget: f_mass_storage: check quirk instead of UDC name usb: gadget: f_ecm/f_ncm: check quirk instead of UDC name usb: gadget: apply generic altsetting support check mechanism usb: gadget: remove gadget_chips.h drivers/usb/gadget/epautoconf.c | 2 - drivers/usb/gadget/function/f_acm.c | 1 - drivers/usb/gadget/function/f_ecm.c | 4 +- drivers/usb/gadget/function/f_mass_storage.c | 4 +- drivers/usb/gadget/function/f_ncm.c | 5 +-- drivers/usb/gadget/function/f_obex.c | 3 +- drivers/usb/gadget/function/f_serial.c | 1 - drivers/usb/gadget/function/f_sourcesink.c | 1 - drivers/usb/gadget/function/u_ether.h| 4 +- drivers/usb/gadget/function/u_uac1.h | 2 - drivers/usb/gadget/legacy/audio.c| 1 - drivers/usb/gadget/legacy/gmidi.c| 2 - drivers/usb/gadget/legacy/hid.c | 1 - drivers/usb/gadget/legacy/nokia.c| 3 +- drivers/usb/gadget/legacy/printer.c | 2 - drivers/usb/gadget/legacy/serial.c | 1 - drivers/usb/gadget/udc/at91_udc.c| 1 + drivers/usb/gadget/udc/gadget_chips.h| 55 drivers/usb/gadget/udc/pxa25x_udc.c | 1 + drivers/usb/gadget/udc/pxa27x_udc.c | 1 + drivers/usb/musb/musb_gadget.c | 1 + include/linux/usb/gadget.h | 31 22 files changed, 44 insertions(+), 83 deletions(-) delete mode 100644 drivers/usb/gadget/udc/gadget_chips.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/7] clk: mediatek: Fix rate and dependency of MT8173 clocks
Hi,
On Mon, 2015-07-27 at 09:52 +0200, Heiko Stübner wrote:
> Am Montag, 27. Juli 2015, 14:19:41 schrieb Daniel Kurtz:
> > On Jul 27, 2015 12:52, "Sascha Hauer" wrote:
> > > On Fri, Jul 24, 2015 at 07:10:14PM +0800, Daniel Kurtz wrote:
> > > > > /* TOPCKGEN */
> > > > >
> > > > > #define CLK_TOP_CLKPH_MCK_O1
> > > > >
> > > > > -#define CLK_TOP_DPI2
> > > > >
> > > > > #define CLK_TOP_USB_SYSPLL_125M3
> > > >
> > > > I think we should renumber the rest of the CLK_TOP_*
> > >
> > > They shouldn't be renumbered at all as this makes all binary device
> > > trees out there useless. That may not be a big issue with the MT8173
> > > at the moment as there are hardly any binary device trees with the
> > > mainline device trees shipped, but still we should get used to not
> > > break existing device trees without need.
> >
> > As you mention, there are no devices shipped with mainline binary device
> > trees. So, let's just correct the numbering now while we still can do it
> > painlessly. It seems a bit unnecessary to preserve backwards compatibility
> > when we are still landing basic device support, like the clock tree.
>
> in general I'm with Sascha on this regarding breaking the dt, and I guess
> the empty number does not hurt this much. Another argument against
> renumbering would be that the clock is there, it's just not used in the
> code anymore, but the clock is acutally still there.
>
>
> But on the other hand, the clock hasn't been part of an official kernel
> release yet (not in 4.1), and if we want to follow protocol to the letter,
> the removal of the clock id itself is already breakage, because the
> binding-header is considered part of the dt and removing a constant
> could already cause breakage in some universe far far away :-)
>
> So you could try to convince the clock maintainers, that this might still
> be 4.2 material. Or do a smaller patch for 4.2 like the following, to at
> least follow the dt-protocol.
>
> Please also take a look at the mt8135 clock tree, to maybe fix this
> already too, before it becomes part of a release.
There is no non-existed clock in current MT8135 clock implementation. So
we just need to remove dpi_ck from MT8173 clocks.
I'll send a new patchset to remove dpi_ck in a small separated patch.
Best regards,
James
> --- 8< -
> From: Heiko Stuebner
> Date: Mon, 27 Jul 2015 09:41:56 +0200
> Subject: [PATCH] clk: mediatek: mt8173: remove unused dpi_ck clock
>
> The dpi_ck clock is not actually used and its source isn't 100% clear too.
> So remove it for the time being.
>
> Signed-off-by: Heiko Stuebner
> ---
> drivers/clk/mediatek/clk-mt8173.c | 1 -
> include/dt-bindings/clock/mt8173-clk.h | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 8b6523d..80871e2 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -26,7 +26,6 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
>
> static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
> FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> - FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> };
> diff --git a/include/dt-bindings/clock/mt8173-clk.h
> b/include/dt-bindings/clock/mt8173-clk.h
> index 4ad76ed..7230c38 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -18,7 +18,6 @@
> /* TOPCKGEN */
>
> #define CLK_TOP_CLKPH_MCK_O 1
> -#define CLK_TOP_DPI 2
> #define CLK_TOP_USB_SYSPLL_125M 3
> #define CLK_TOP_HDMITX_DIG_CTS 4
> #define CLK_TOP_ARMCA7PLL_754M 5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Correct a freq check in cpufreq_set_policy
hi, Viresh
thanks for your quick reply! :)
On 2015年07月28日 12:41, Viresh Kumar wrote:
> On 28-07-15, 11:34, Pan Xinhui wrote:
>> From: Pan Xinhui
>>
>> This check was originally added by commit 9c9a43ed2734 ("[CPUFREQ]
>> return error when failing to set minfreq").It attempt to return an error
>> on obviously incorrect limits when we echo xxx >.../scaling_max,min_freq
>> Actually we just need check if new_policy->min > new_policy->max.
>> Because at least one of max/min is copied from cpufreq_get_policy().
>>
>> For example, when we echo xxx > .../scaling_min_freq, new_policy is
>> copied from policy in cpufreq_get_policy. new_policy->max is same with
>> policy->max. new_policy->min is set to a new value.
>>
>> Let me explain it in deduction method, first statment in if ():
>> new_policy->min > policy->max
>> policy->max == new_policy->max
>> ==> new_policy->min > new_policy->max
>>
>> second statment in if():
>> new_policy->max < policy->min
>> policy->max < policy->min
>> ==>new_policy->min > new_policy->max (induction method)
>>
>> So we have proved that we only need check if new_policy->min >
>> new_policy->max.
>>
>> After apply this patch, we can also modify ->min and ->max in same time
>> if new freq range is very much different from current freq range. For
>> example, if current freq range is 48-96, then we want to set
>> this range to 112-224, we would fail in the past because
>> new_policy->min > policy->max. As long as the cpufreq range is valid, we
>> has no reason to reject the user. So correct the check.
>>
>> Signed-off-by: Pan Xinhui
>
> Does this patch depend on the other patch you sent where you are
> trying to update both min/max in the same call to
> cpufreq_set_policy()? If so, they should have been part of the same
> series in proper order, as you have sent them as separate patches.
>
Thanks for pointing out my mistakes. I will send them in a same series with
proper order.
Sorry for that.
> Now, if we don't consider your first patch at all, then this patch is
> obviously wrong. We need to take care of both the checks.
>
Agree, we need take care of every checks. BUT, As We have proved, it's equal to
check if (new_policy->min > new_policy->max). I don't why it's wrong.
with/without this patch, echo 0 > .../scaling_min_freq has no error. min freq
is just set to the limit min freq. I prefer to treat it as a feature. :)
So I don't add new_policy->min < policy->cpuinfo.min_freq || new_policy->max >
policy->cpuinfo.max_freq.
We have ->verify callback, no need to worry about that an out-of-limit cpufreq
will harm kernel.
This check is just to tell userspace that *the cpufreq you are trying to set is
wrong, pls double check.*
thanks
xinhui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/7] clk: mediatek: Add fixed clocks support for Mediatek SoC.
Hi Daniel, On Fri, 2015-07-24 at 19:33 +0800, Daniel Kurtz wrote: > Hi James, > > On Fri, Jul 24, 2015 at 11:01 AM, James Liao > wrote: > > > > +void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks, int num, > > + struct clk_onecell_data *clk_data) > > > void __init mtk_clk_register_fixed_clks(... It will be added in next patch. > > -extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, > > +void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, > > Technically, this hunk is unrelated and should probably be in its own patch. It will be in a separated patch. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v5 15/19] KVM: eventfd: add irq bypass consumer management
> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Monday, July 13, 2015 9:47 PM > To: Eric Auger; Wu, Feng; k...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: alex.william...@redhat.com; j...@8bytes.org > Subject: Re: [v5 15/19] KVM: eventfd: add irq bypass consumer management > > 13/07/2015 15:16, Eric Auger wrote: > >> > > >> > +irqfd->consumer.token = (void *)irqfd->eventfd; > >> > +kvm_arch_irq_consumer_init(>consumer); > > what if the architecture does not implement kvm_arch_irq_consumer_init? > > > > Also you are using here this single function kvm_arch_irq_consumer_init > > to do some irq bypass manager settings + attaching your > > irqfd->arch_update cb which does not really relate to IRQ bypass > > manager. I think I preferred the approach where start/top/add/del were > > exposed separately ([RFC v2 5/6] KVM: introduce kvm_arch functions for > > IRQ bypass). > > > > Why not adding another kvm_arch_irq_routing_update then, not necessarily > > linked to irq bypass manager. > > Yes, I also preferred the dummy kvm_arch_* functions to this approach > with an init function. You'd have to add dummy init functions anyway > for non-ARM, non-x86 architectures. I think dummy kvm_arch_* is okay for me. However, my point is that currently 'add_producer ' and 'del_producer ' are mandatory, other callbacks are optional. In patch "[RFC v2 5/6] KVM: introduce kvm_arch functions for IRQ bypass " and "[RFC v2 6/6] KVM: eventfd: add irq bypass consumer management ", it provides all the callbacks, which means we need to implement dummy arch specific functions no matter it is necessary. In that case, seems it is pointless to make some of the callbacks optional. Anyway, if you guys are fine with the dummy approach, I am good! :) Thanks, Feng > > Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
On Mon, 2015-07-27 at 15:11 +0100, Will Deacon wrote:
> On Mon, Jul 27, 2015 at 03:05:38PM +0100, Robin Murphy wrote:
> > On 27/07/15 05:21, Yong Wu wrote:
> > > + } else {/* page or largepage */
> > > + if (quirk & IO_PGTABLE_QUIRK_SHORT_MTK) {
> > > + if (large) { /* special Bit */
> >
> > This definitely needs a better comment! What exactly are you doing here
> > and what is that quirk all about?
> > >>>
> > >>> I use this quirk is for MTK Special Bit as we don't have the XN bit in
> > >>> pagetable.
> > >>
> > >> I'm still not really clear about what this is.
> > >
> > > There is some difference between the standard spec and MTK HW,
> > > Our hw don't implement some bits, like XN and AP.
> > > So I add a quirk for MTK special.
> >
> > When you say it doesn't implement these bits, do you mean that having
> > them set will lead to Bad Things happening in the hardware, or that it
> > will simply ignore them and not enforce any of the protections they
> > imply? The former case would definitely want clearly documenting
> > somewhere, whereas for the latter case I'm not sure it's even worth the
> > complication of having a quirk - if the value doesn't matter there seems
> > little point in doing a special dance just for the sake of semantic
> > correctness of the in-memory PTEs, in my opinion.
>
> Agreed. We should only use quirks if the current (architecturally
> compliant) code causes real issues with the hardware. Then the quirk can
> be used to either avoid the problematic routines or to take extra steps
> to make things work as the architecture intended.
>
> I've asked how this IOMMU differs from the architecture on a number of
> occasions, but I'm still yet to receive a response other than "it's special".
>
After check further with DE, Our pagetable is refer to ARM-v7's
short-descriptor which is a little different from ARM-v8. like bit0(PXN)
in section and supersection, I didn't read ARM-v7 spec before, so I add
a MTK quirk to disable PXN bit in section and supersection.(if the PXN
bit is wrote in ARM-v7 spec, HW will page fault.)
Then I write this code according to ARM-v8 spec defaultly, and add a
ARM-v7 quirk?
And there is a little different between ARM-v7 spec and MTK pagetable.
It's the XN(bit0) in small page. MTK don't implement XN bit.
The bit[1:0] in MTK's small page should be 2'b10, if it's 2'b11, HW will
page fault.
(MTK don't implement AP bits too, but HW don't use them, it is ok even
though AP bits is wrote)
In the end, I will add two quirk like this, is it OK?
//===
#define ARM_PGTABLE_QUIRK_SHORT_ARM_V7 BIT(2) /* for ARM-v7 while
default is the ARM-v8 spec */
#define ARM_PGTABLE_QUIRK_SHORT_MTK BIT(3) /* MTK special */
//===
In the ARM_V7 quirk, I only disable PXN bit in section and supersection,
In the MTK quirk, I only disbable XN in small page.
The other bits seems the same. I'm not sure I write clearly and It seems
we could not copy a image of mtk pagetable here..If any question, please
help tell me.
Thanks very much.
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.
Hi Michal, I agree we need to be careful with changing the bindings. On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek wrote: > Hi Moritz, > > On 07/25/2015 02:21 AM, Moritz Fischer wrote: >> Signed-off-by: Moritz Fischer >> --- >> arch/arm/boot/dts/zynq-7000.dtsi| 43 - > > This patch is nice in general but every change in binding should be > discussed separately. There is also necessary to wire them up in the > driver to do action. That's why I think that will be the best just to > add the code to slcr and keep others untouched. Ok, just to clarify: You'd suggest to just add the rstc as child node to the slcr, and leave the other nodes untouched? > > For example MACB/GEM is one example. Adding names to this node and > extending driver to work properly with reset means that all others MACB > users will be affected. Definitely this patch should be ACKed by Nicolas. > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ > Maintainer of Linux kernel - Xilinx Zynq ARM architecture > Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform > > Cheers, Moritz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 3/3] reset: reset-zynq: Adding support for Xilinx Zynq reset controller.
Hi Michal,
On Mon, Jul 27, 2015 at 12:12 AM, Michal Simek wrote:
> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>> This adds a reset controller driver to control the Xilinx Zynq
>> SoC's various resets.
>>
>> Signed-off-by: Moritz Fischer
>> ---
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-zynq.c | 142
>> +
>> 2 files changed, 143 insertions(+)
>> create mode 100644 drivers/reset/reset-zynq.c
>>
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index 157d421..3fe50e7 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>> obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
>> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>> obj-$(CONFIG_ARCH_STI) += sti/
>> +obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
>> diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
>> new file mode 100644
>> index 000..05e37f8
>> --- /dev/null
>> +++ b/drivers/reset/reset-zynq.c
>> @@ -0,0 +1,142 @@
>> +/*
>> + * Copyright (c) 2015, National Instruments Corp.
>> + *
>> + * Xilinx Zynq Reset controller driver
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; version 2 of the License.
>> + *
>> + * 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
>> +
>> +/* Offsets into SLCR regmap */
>> +#define SLCR_RST_CTRL_OFFSET 0x200 /* FPGA Software Reset Control */
>> +
>> +#define NBANKS 18
>> +
>> +struct zynq_reset_data {
>> + struct regmap *slcr;
>> + struct reset_controller_dev rcdev;
>> +};
>> +
>> +#define to_zynq_reset_data(p)\
>> + container_of((p), struct zynq_reset_data, rcdev)
>> +
>> +static int zynq_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>> +
>> + int bank = id / BITS_PER_LONG;
>> + int offset = id % BITS_PER_LONG;
>> +
>
> Personally me I would also add debug message here to be simply enabled
> for easier tracking.
See below
>
>> + regmap_update_bits(priv->slcr,
>> +SLCR_RST_CTRL_OFFSET + (bank * 4),
>> +BIT(offset),
>> +BIT(offset));
>> +
>> + return 0;
>> +}
>> +
>> +static int zynq_reset_deassert(struct reset_controller_dev *rcdev,
>> +unsigned long id)
>> +{
>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>> +
>> + int bank = id / BITS_PER_LONG;
>> + int offset = id % BITS_PER_LONG;
>> +
>
> debug message here too.
is:
pr_debug("%s: bank: %u offset %u\n", __func__, bank, offset);
accetable? Otherwise I'd have to carry around a struct dev* to use dev_dbg()
>
>> + regmap_update_bits(priv->slcr,
>> +SLCR_RST_CTRL_OFFSET + (bank * 4),
>> +BIT(offset),
>> +~BIT(offset));
>> +
>> + return 0;
>> +}
>> +
>> +static int zynq_reset_status(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>> +
>> + int bank = id / BITS_PER_LONG;
>> + int offset = id % BITS_PER_LONG;
>> + u32 reg;
>> +
>> + regmap_read(priv->slcr, SLCR_RST_CTRL_OFFSET + (bank * 4), );
>
> debug message here too.
>
>> +
>> + return !(reg & BIT(offset));
>> +}
>> +
>> +static const struct reset_control_ops zynq_reset_ops = {
>
> Remove const here - there is sparse warning.
>
>> + .assert = zynq_reset_assert,
>> + .deassert = zynq_reset_deassert,
>> + .status = zynq_reset_status,
>> +};
>> +
>> +static int zynq_reset_probe(struct platform_device *pdev)
>> +{
>> + struct zynq_reset_data *priv;
>> +
>> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> + platform_set_drvdata(pdev, priv);
>> +
>> + priv->slcr = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
>> + "syscon");
>> + if (IS_ERR(priv->slcr)) {
>> + dev_err(>dev, "unable to get zynq-slcr regmap");
>> + return PTR_ERR(priv->slcr);
>> + }
>> +
>> + priv->rcdev.owner = THIS_MODULE;
>> + priv->rcdev.nr_resets = NBANKS * BITS_PER_LONG;
>> + priv->rcdev.ops = _reset_ops;
>> + priv->rcdev.of_node = pdev->dev.of_node;
>> + reset_controller_register(>rcdev);
>> +
>> + return 0;
>> +}
Re: [PATCH] cpufreq: Add scaling frequency range support
hi, Viresh thanks for your reply :) On 2015年07月28日 12:29, Viresh Kumar wrote: > On 28-07-15, 11:32, Pan Xinhui wrote: >> From: Pan Xinhui >> >> Userspace at most time do cpufreq tests very much inconveniently. >> Currently they have to echo min and max cpu freq separately like below: >> echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq >> echo 224 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq >> >> Add scaling_freq_range cpufreq attr to support userspace's demand. >> Therefore it's easier for testers to write readable scripts like below: >> echo 48-224 > >> /sys/devices/system/cpu/cpu0/cpufreq/scaling_freq_range > > I don't think this brings any good change, we already have support for > that with min/max freqs and I don't see how scripts can be less > readable with that. > yes, min/max are supported, however it is inconvenient. sometime it's very easy to cause obscure bugs. For example, some one might write a script like below. echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 96 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq .//other works echo 112 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 224 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq ...//other works But it did not work when we echo 112000 to min-freq, as the current max freq is smaller than it. It's hard to figure it out in a big script... we have many such scripts. I admit this is a bug in script. If we can support *set freq range*, it's a very good option for usesapce to change the cpufreq. People working in useespace will be thankful to us :) > So, why to add redundant files at all? Also note that we can't remove > the old interface as that will break the ABI. > fully agree! we can't break the ABI. So i just add this feature which is very helpful. :) thanks xinhui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Hi Michal,
On Sun, Jul 26, 2015 at 10:09 PM, Michal Simek wrote:
> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>> Signed-off-by: Moritz Fischer
>> ---
>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
>> 1 file changed, 13 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> new file mode 100644
>> index 000..ac4499e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> @@ -0,0 +1,13 @@
>> +Xilinx Zynq PL Reset Manager
>
> here
>
>> +
>> +Required properties:
>> +- compatible: "xlnx,zynq-reset-pl"
>
> Currently it is not just PL reset controller.
>
>> +- syscon <>;
>
>
> missing : and please be more descriptive here.
>
>> +- #reset-cells: 1
>> +
>> +Example:
>> + rstc: rstc@240 {
>> + #reset-cells = <1>;
>> + compatible = "xlnx,zynq-reset-pl";
>
> Compatible property should go first.
>
> I am missing that reg property
>
>> + syscon = <>;
>> + };
>>
>
Would something like this work:
Xilinx Zynq Reset Manager
The Zynq AP-SoC has several different resets.
See Chapter 26 of the Zynq TRM (UG585) for more information about Zynq resets.
Required properties:
- compatible: "xlnx,zynq-reset"
- reg: SLCR offset and size taken via syscon <0x200 0x50>
- syscon: <>
This should be a phandle to the Zynq's SLCR register.
- #reset-cells: Must be 1
The Zynq Reset Manager needs to be a child node of the SLCR.
Example:
rstc: rstc@200 {
compatible = "xlnx,zynq-reset";
reg = <0x200 0x50>;
#reset-cells = <1>;
syscon = <>;
};
> Thanks,
> Michal
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
>
>
Thanks for your feedback,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Hi Sören,
thanks for your feedback.
On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
wrote:
> Hi Moritz,
>
> On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
>> Signed-off-by: Moritz Fischer
>> ---
>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
>> 1 file changed, 13 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> new file mode 100644
>> index 000..ac4499e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> @@ -0,0 +1,13 @@
>> +Xilinx Zynq PL Reset Manager
>> +
>> +Required properties:
>> +- compatible: "xlnx,zynq-reset-pl"
>> +- syscon <>;
>> +- #reset-cells: 1
>> +
>> +Example:
>> + rstc: rstc@240 {
>> + #reset-cells = <1>;
>> + compatible = "xlnx,zynq-reset-pl";
>> + syscon = <>;
>> + };
>
> I think you also have to add the outputs and make them part of the
> binding. Otherwise you'd have to read the implementation to find
> out what device should be hooked up to which output of the reset-controller.
Is something like this what you had in mind? I had that prepared for
the next round of patches:
Reset outputs:
0 : soft reset
32 : ddr reset
64 : topsw reset
96 : dmac reset
128: usb0 reset
129: usb1 reset
160: gem0 reset
161: gem1 reset
164: gem0 rx reset
165: gem1 rx reset
166: gem0 ref reset
167: gem1 ref reset
192: sdio0 reset
193: sdio1 reset
196: sdio0 ref reset
197: sdio1 ref reset
224: spi0 reset
225: spi1 reset
226: spi0 ref reset
227: spi1 ref reset
256: can0 reset
257: can1 reset
258: can0 ref reset
259: can1 ref reset
288: i2c0 reset
289: i2c1 reset
320: uart0 reset
321: uart1 reset
322: uart0 ref reset
323: uart1 ref reset
352: gpio reset
384: lqspi reset
385: qspi ref reset
416: smc reset
417: smc ref reset
448: ocm reset
512: fpga0 out reset
513: fpga1 out reset
514: fpga2 out reset
515: fpga3 out reset
544: a9 reset 0
545: a9 reset 1
552: peri reset
> Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[REPOST PATCH] kexec: Remove the unnecessary conditional judgement to simplify the code logic
Transforming PFN(Page Frame Number) to struct page is never failure, so
we can simplify the code logic to do the image->control_page assignment
directly in the loop, and remove the unnecessary conditional judgement.
Signed-off-by: Minfei Huang
Acked-by: Dave Young
Acked-by: Vivek Goyal
---
kernel/kexec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 6f1ed75..cf82474 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -807,11 +807,10 @@ static struct page
*kimage_alloc_crash_control_pages(struct kimage *image,
/* If I don't overlap any segments I have found my hole! */
if (i == image->nr_segments) {
pages = pfn_to_page(hole_start >> PAGE_SHIFT);
+ image->control_page = hole_end;
break;
}
}
- if (pages)
- image->control_page = hole_end;
return pages;
}
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb/gadget: make composite gadget meet usb compliance for vbus draw
>From 08df419517694c4dd9ff328f5644b46a99c2999e Mon Sep 17 00:00:00 2001
From: "Du, Changbin"
Date: Thu, 23 Jul 2015 20:08:04 +0800
Subject: [PATCH v2] usb/gadget: make composite gadget meet usb compliance for
vbus draw
USB-IF compliance requirement limits the vbus current according to
current state. USB2 Spec requires that un-configured current must
be <= 100mA, for USB3 is 150mA, OTG is 2.5mA. So set corresponding
vbus draw current according to device mode.
Signed-off-by: Du, Changbin
---
drivers/usb/gadget/composite.c | 39 ---
drivers/usb/gadget/configfs.c | 2 +-
include/linux/usb/composite.h | 1 +
include/uapi/linux/usb/ch9.h | 9 +
4 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 4e3447b..b3896e9 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -610,6 +610,21 @@ static void device_qual(struct usb_composite_dev *cdev)
qual->bRESERVED = 0;
}
+static unsigned unconfigured_vbus_draw(struct usb_composite_dev *cdev)
+{
+ struct usb_gadget *g = cdev->gadget;
+ unsigned power;
+
+ if (gadget_is_otg(g))
+ power = USB_OTG_UNCONF_STATE_VBUS_MAX_DRAW;
+ else if (g->speed == USB_SPEED_SUPER)
+ power = USB3_UNCONF_STATE_VBUS_MAX_DRAW;
+ else
+ power = USB2_UNCONF_STATE_VBUS_MAX_DRAW;
+
+ return power;
+}
+
/*-*/
static void reset_config(struct usb_composite_dev *cdev)
@@ -634,7 +649,7 @@ static int set_config(struct usb_composite_dev *cdev,
struct usb_gadget *gadget = cdev->gadget;
struct usb_configuration *c = NULL;
int result = -EINVAL;
- unsignedpower = gadget_is_otg(gadget) ? 8 : 100;
+ unsignedpower = unconfigured_vbus_draw(cdev);
int tmp;
if (number) {
@@ -1829,6 +1844,15 @@ done:
return value;
}
+void composite_reset(struct usb_gadget *gadget)
+{
+ struct usb_composite_dev *cdev = get_gadget_data(gadget);
+
+ DBG(cdev, "reset\n");
+ usb_gadget_vbus_draw(gadget, unconfigured_vbus_draw(cdev));
+ composite_disconnect(gadget);
+}
+
void composite_disconnect(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
@@ -2095,7 +2119,7 @@ void composite_suspend(struct usb_gadget *gadget)
cdev->suspended = 1;
- usb_gadget_vbus_draw(gadget, 2);
+ usb_gadget_vbus_draw(gadget, USB_SUSPEND_STATE_VBUS_MAX_DRAW);
}
void composite_resume(struct usb_gadget *gadget)
@@ -2117,10 +2141,11 @@ void composite_resume(struct usb_gadget *gadget)
}
maxpower = cdev->config->MaxPower;
-
- usb_gadget_vbus_draw(gadget, maxpower ?
- maxpower : CONFIG_USB_GADGET_VBUS_DRAW);
- }
+ if (!maxpower)
+ maxpower = CONFIG_USB_GADGET_VBUS_DRAW;
+ } else
+ maxpower = unconfigured_vbus_draw(cdev);
+ usb_gadget_vbus_draw(gadget, maxpower);
cdev->suspended = 0;
}
@@ -2132,7 +2157,7 @@ static const struct usb_gadget_driver
composite_driver_template = {
.unbind = composite_unbind,
.setup = composite_setup,
- .reset = composite_disconnect,
+ .reset = composite_reset,
.disconnect = composite_disconnect,
.suspend= composite_suspend,
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 0495c94..e16335d 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1449,7 +1449,7 @@ static const struct usb_gadget_driver
configfs_driver_template = {
.unbind = configfs_composite_unbind,
.setup = composite_setup,
- .reset = composite_disconnect,
+ .reset = composite_reset,
.disconnect = composite_disconnect,
.suspend= composite_suspend,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 2511469..825ad39 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -506,6 +506,7 @@ extern struct usb_string *usb_gstrings_attach(struct
usb_composite_dev *cdev,
extern int usb_string_ids_n(struct usb_composite_dev *c, unsigned n);
+extern void composite_reset(struct usb_gadget *gadget);
extern void composite_disconnect(struct usb_gadget *gadget);
extern int composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl);
diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index aa33fd1..ab216bf 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -996,4 +996,13 @@ struct
Re: [PATCH] kexec: Remove the unnecessary conditional judgement to simplify the code logic
On 07/28/15 at 01:30pm, Simon Horman wrote: > On Mon, Jul 27, 2015 at 09:44:53AM -0400, Vivek Goyal wrote: > > On Sat, Jun 06, 2015 at 02:14:12PM +0800, Minfei Huang wrote: > > > From: Minfei Huang > > > > > > Transforming PFN(Page Frame Number) to struct page is never failure, so > > > we can simplify the code logic to do the image->control_page assignment > > > directly in the loop, and remove the unnecessary conditional judgement. > > > > > > Signed-off-by: Minfei Huang > > > > Looks good to me. > > > > Acked-by: Vivek Goyal > > FWIW, this probably needs to be reposted to Andrew Morton with appropriate > Acks and CCs in order to proceed into his tree and then Linus's. Thanks. I will repost it to Andrew Morton. Thanks Minfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Correct a freq check in cpufreq_set_policy
On 28-07-15, 11:34, Pan Xinhui wrote:
> From: Pan Xinhui
>
> This check was originally added by commit 9c9a43ed2734 ("[CPUFREQ]
> return error when failing to set minfreq").It attempt to return an error
> on obviously incorrect limits when we echo xxx >.../scaling_max,min_freq
> Actually we just need check if new_policy->min > new_policy->max.
> Because at least one of max/min is copied from cpufreq_get_policy().
>
> For example, when we echo xxx > .../scaling_min_freq, new_policy is
> copied from policy in cpufreq_get_policy. new_policy->max is same with
> policy->max. new_policy->min is set to a new value.
>
> Let me explain it in deduction method, first statment in if ():
> new_policy->min > policy->max
> policy->max == new_policy->max
> ==> new_policy->min > new_policy->max
>
> second statment in if():
> new_policy->max < policy->min
> policy->max < policy->min
> ==>new_policy->min > new_policy->max (induction method)
>
> So we have proved that we only need check if new_policy->min >
> new_policy->max.
>
> After apply this patch, we can also modify ->min and ->max in same time
> if new freq range is very much different from current freq range. For
> example, if current freq range is 48-96, then we want to set
> this range to 112-224, we would fail in the past because
> new_policy->min > policy->max. As long as the cpufreq range is valid, we
> has no reason to reject the user. So correct the check.
>
> Signed-off-by: Pan Xinhui
Does this patch depend on the other patch you sent where you are
trying to update both min/max in the same call to
cpufreq_set_policy()? If so, they should have been part of the same
series in proper order, as you have sent them as separate patches.
Now, if we don't consider your first patch at all, then this patch is
obviously wrong. We need to take care of both the checks.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 4/8] staging: rtl8712: removed unused wrapper structs
Remove wrapper structs that just wrap struct ndis_wlan_bssid_ex,
and are unused.
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_cmd.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.h
b/drivers/staging/rtl8712/rtl871x_cmd.h
index cb8225b..818cd88 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.h
+++ b/drivers/staging/rtl8712/rtl871x_cmd.h
@@ -123,15 +123,6 @@ struct usb_suspend_parm {
};
/*
- * Caller Mode: Infra, Ad-Hoc
- * Notes: To join the specified bss
- * Command Event Mode
- */
-struct joinbss_parm {
- struct ndis_wlan_bssid_ex network;
-};
-
-/*
* Caller Mode: Infra, Ad-HoC(C)
* Notes: To disconnect the current associated BSS
* Command Mode
@@ -141,15 +132,6 @@ struct disconnect_parm {
};
/*
- * Caller Mode: AP, Ad-HoC(M)
- * Notes: To create a BSS
- * Command Mode
- */
-struct createbss_parm {
- struct ndis_wlan_bssid_ex network;
-};
-
-/*
* Caller Mode: AP, Ad-HoC, Infra
* Notes: To set the NIC mode of RTL8711
* Command Mode
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg Kroah-Hartman ,
Sudip Mukherjee ,
Nitin Kuppelur ,
Joshua Clayton ,
Vaishali Thakkar ,
Tapasweni Pathak ,
Daniel Baluta ,
Melike Yurtoglu ,
Max Perepelitsyn ,
Aya Mahfouz ,
Cristina Opriceana ,
Dogukan Ergun ,
Julia Lawall ,
Dan Carpenter ,
Haneen Mohammed ,
Rickard Strandqvist
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: [PATCH V3 4/8] staging: rtl8712: removed unused wrapper structs
Date: Mon, 27 Jul 2015 21:41:13 -0700
Message-Id:
<75dcdd4644344c7c4f0ccabf8a0e28bce7974349.1438057939.git.stillcompil...@gmail.com>
X-Mailer: git-send-email 2.4.6
In-Reply-To:
References:
In-Reply-To:
References:
Remove wrapper structs that just wrap struct ndis_wlan_bssid_ex,
and are unused.
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_cmd.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.h
b/drivers/staging/rtl8712/rtl871x_cmd.h
index cb8225b..818cd88 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.h
+++ b/drivers/staging/rtl8712/rtl871x_cmd.h
@@ -123,15 +123,6 @@ struct usb_suspend_parm {
};
/*
- * Caller Mode: Infra, Ad-Hoc
- * Notes: To join the specified bss
- * Command Event Mode
- */
-struct joinbss_parm {
- struct ndis_wlan_bssid_ex network;
-};
-
-/*
* Caller Mode: Infra, Ad-HoC(C)
* Notes: To disconnect the current associated BSS
* Command Mode
@@ -141,15 +132,6 @@ struct disconnect_parm {
};
/*
- * Caller Mode: AP, Ad-HoC(M)
- * Notes: To create a BSS
- * Command Mode
- */
-struct createbss_parm {
- struct ndis_wlan_bssid_ex network;
-};
-
-/*
* Caller Mode: AP, Ad-HoC, Infra
* Notes: To set the NIC mode of RTL8711
* Command Mode
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg Kroah-Hartman ,
Sudip Mukherjee ,
Nitin Kuppelur ,
Joshua Clayton ,
Vaishali Thakkar ,
Tapasweni Pathak ,
Daniel Baluta ,
Melike Yurtoglu ,
Max Perepelitsyn ,
Aya Mahfouz ,
Cristina Opriceana ,
Dogukan Ergun ,
Julia Lawall ,
Dan Carpenter ,
Haneen Mohammed ,
Rickard Strandqvist
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: [PATCH V3 4/8] staging: rtl8712: removed unused wrapper structs
Date: Mon, 27 Jul 2015 21:41:13 -0700
Message-Id:
<75dcdd4644344c7c4f0ccabf8a0e28bce7974349.1438057939.git.stillcompil...@gmail.com>
X-Mailer: git-send-email 2.4.6
In-Reply-To:
References:
In-Reply-To:
References:
Remove wrapper structs that just wrap struct ndis_wlan_bssid_ex,
and are unused.
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_cmd.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.h
b/drivers/staging/rtl8712/rtl871x_cmd.h
index cb8225b..818cd88 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.h
+++ b/drivers/staging/rtl8712/rtl871x_cmd.h
@@ -123,15 +123,6 @@ struct usb_suspend_parm {
};
/*
- * Caller Mode: Infra, Ad-Hoc
- * Notes: To join the specified bss
- * Command Event Mode
- */
-struct joinbss_parm {
- struct ndis_wlan_bssid_ex network;
-};
-
-/*
* Caller Mode: Infra, Ad-HoC(C)
* Notes: To disconnect the current associated BSS
* Command Mode
@@ -141,15 +132,6 @@ struct disconnect_parm {
};
/*
- * Caller Mode: AP, Ad-HoC(M)
- * Notes: To create a BSS
- * Command Mode
- */
-struct createbss_parm {
- struct ndis_wlan_bssid_ex network;
-};
-
-/*
* Caller Mode: AP, Ad-HoC, Infra
* Notes: To set the NIC mode of RTL8711
* Command Mode
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg
[PATCH V3 1/8] staging: rtl8712: fix buggy size calculation
r8712_get_ndis_wlan_bssid_ex_sz has a "6 * sizeof(unsigned long)"
where the underlying struct has a 6 * unsigned char.
Simplify the calculation by just subtracting the variable part from
the size of the struct.
This also gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_mlme.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index c044b0e..6b3451f 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -210,17 +210,7 @@ void r8712_generate_random_ibss(u8 *pibss)
uint r8712_get_ndis_wlan_bssid_ex_sz(struct ndis_wlan_bssid_ex *bss)
{
- uint t_len;
-
- t_len = sizeof(u32) + 6 * sizeof(unsigned long) + 2 +
- sizeof(struct ndis_802_11_ssid) + sizeof(u32) +
- sizeof(s32) +
- sizeof(enum NDIS_802_11_NETWORK_TYPE) +
- sizeof(struct NDIS_802_11_CONFIGURATION) +
- sizeof(enum NDIS_802_11_NETWORK_INFRASTRUCTURE) +
- sizeof(NDIS_802_11_RATES_EX) +
- sizeof(u32) + bss->IELength;
- return t_len;
+ return sizeof(*bss) + bss->IELength - MAX_IE_SZ;
}
u8 *r8712_get_capability_from_ie(u8 *ie)
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg Kroah-Hartman ,
Sudip Mukherjee ,
Nitin Kuppelur ,
Joshua Clayton ,
Vaishali Thakkar ,
Tapasweni Pathak ,
Daniel Baluta ,
Melike Yurtoglu ,
Max Perepelitsyn ,
Aya Mahfouz ,
Cristina Opriceana ,
Dogukan Ergun ,
Julia Lawall ,
Dan Carpenter ,
Haneen Mohammed ,
Rickard Strandqvist
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: [PATCH V3 1/8] staging: rtl8712: fix buggy size calculation
Date: Mon, 27 Jul 2015 21:41:10 -0700
Message-Id:
<305999598d7738feabdc8e5df5400b3e7be7f5ed.1438057939.git.stillcompil...@gmail.com>
X-Mailer: git-send-email 2.4.6
In-Reply-To:
References:
In-Reply-To:
References:
r8712_get_ndis_wlan_bssid_ex_sz has a "6 * sizeof(unsigned long)"
where the underlying struct has a 6 * unsigned char.
Simplify the calculation by just subtracting the variable part from
the size of the struct.
This also gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_mlme.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index c044b0e..6b3451f 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -210,17 +210,7 @@ void r8712_generate_random_ibss(u8 *pibss)
uint r8712_get_ndis_wlan_bssid_ex_sz(struct ndis_wlan_bssid_ex *bss)
{
- uint t_len;
-
- t_len = sizeof(u32) + 6 * sizeof(unsigned long) + 2 +
- sizeof(struct ndis_802_11_ssid) + sizeof(u32) +
- sizeof(s32) +
- sizeof(enum NDIS_802_11_NETWORK_TYPE) +
- sizeof(struct NDIS_802_11_CONFIGURATION) +
- sizeof(enum NDIS_802_11_NETWORK_INFRASTRUCTURE) +
- sizeof(NDIS_802_11_RATES_EX) +
- sizeof(u32) + bss->IELength;
- return t_len;
+ return sizeof(*bss) + bss->IELength - MAX_IE_SZ;
}
u8 *r8712_get_capability_from_ie(u8 *ie)
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg Kroah-Hartman ,
Sudip Mukherjee ,
Nitin Kuppelur ,
Joshua Clayton ,
Vaishali Thakkar ,
Tapasweni Pathak ,
Daniel Baluta ,
Melike Yurtoglu ,
Max Perepelitsyn ,
Aya Mahfouz ,
Cristina Opriceana ,
Dogukan Ergun ,
Julia Lawall ,
Dan Carpenter ,
Haneen Mohammed ,
Rickard Strandqvist
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: [PATCH V3 1/8] staging: rtl8712: fix buggy size calculation
Date: Mon, 27 Jul 2015 21:41:10 -0700
Message-Id:
<305999598d7738feabdc8e5df5400b3e7be7f5ed.1438057939.git.stillcompil...@gmail.com>
X-Mailer: git-send-email 2.4.6
In-Reply-To:
References:
In-Reply-To:
References:
r8712_get_ndis_wlan_bssid_ex_sz has a "6 * sizeof(unsigned long)"
where the underlying struct has a 6 * unsigned char.
Simplify the calculation by just subtracting the variable part from
the size of the struct.
This also gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_mlme.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
[PATCH V3 0/8] clean up wlan_bssdef.h
The main goal of this series is to get rid of a needless typedef in the rtl8712 wlan driver. In the course of fixing that, I found a bug that can (at least in theory) lead to a overrun during a memcpy, as well as an identical struct with a different name, which use the typedef. Finally after cleaning up the typedef, change the name of the primary variable that used the typedef from "SupportedRates" to "rates", to conform to kernel coding style. Changes since V1: Do not make other logic changes while Changing the name of SupportedRates New patch 3/6 fixes a buggy comment that referred to the typedef Changes sinve V2: broke former patch 4, which was too big for git-send-email into 3 parts Joshua Clayton (8): staging: rtl8712: fix buggy size calculation staging: rtl8712: simplify size calculation staging: rtl8712: fix comment staging: rtl8712: removed unused wrapper structs staging: rtl8712: remove duplicate struct staging: rtl8712: rename function staging: rtl8712: remove typedefs staging: rtl8712: change SupportedRates to rates drivers/staging/rtl8712/ieee80211.c | 22 ++--- drivers/staging/rtl8712/rtl871x_cmd.c | 28 +--- drivers/staging/rtl8712/rtl871x_cmd.h | 18 -- drivers/staging/rtl8712/rtl871x_event.h | 2 +- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 36 ++-- drivers/staging/rtl8712/rtl871x_mlme.c| 47 ++- drivers/staging/rtl8712/rtl871x_mlme.h| 2 +- drivers/staging/rtl8712/rtl871x_mp_ioctl.c| 6 ++-- drivers/staging/rtl8712/wlan_bssdef.h | 42 +++- 9 files changed, 64 insertions(+), 139 deletions(-) -- 2.4.6 From: Joshua Clayton To: Larry Finger , Florian Schilhabel , Greg Kroah-Hartman , Sudip Mukherjee , Nitin Kuppelur , Joshua Clayton , Vaishali Thakkar , Tapasweni Pathak , Daniel Baluta , Melike Yurtoglu , Max Perepelitsyn , Aya Mahfouz , Cristina Opriceana , Dogukan Ergun , Julia Lawall , Dan Carpenter , Haneen Mohammed , Rickard Strandqvist Cc: de...@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: [PATCH V3 0/8] clean up wlan_bssdef.h Date: Mon, 27 Jul 2015 21:41:09 -0700 Message-Id: X-Mailer: git-send-email 2.4.6 The main goal of this series is to get rid of a needless typedef in the rtl8712 wlan driver. In the course of fixing that, I found a bug that can (at least in theory) lead to a overrun during a memcpy, as well as an identical struct with a different name, which use the typedef. Finally after cleaning up the typedef, change the name of the primary variable that used the typedef from "SupportedRates" to "rates", to conform to kernel coding style. Changes since V1: Do not make other logic changes while Changing the name of SupportedRates New patch 3/6 fixes a buggy comment that referred to the typedef Changes sinve V2: broke former patch 4, which was too big for git-send-email into 3 parts Joshua Clayton (8): staging: rtl8712: fix buggy size calculation staging: rtl8712: simplify size calculation staging: rtl8712: fix comment staging: rtl8712: removed unused wrapper structs staging: rtl8712: remove duplicate struct staging: rtl8712: rename function staging: rtl8712: remove typedefs staging: rtl8712: change SupportedRates to rates drivers/staging/rtl8712/ieee80211.c | 22 ++--- drivers/staging/rtl8712/rtl871x_cmd.c | 28 +--- drivers/staging/rtl8712/rtl871x_cmd.h | 18 -- drivers/staging/rtl8712/rtl871x_event.h | 2 +- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 36 ++-- drivers/staging/rtl8712/rtl871x_mlme.c| 47 ++- drivers/staging/rtl8712/rtl871x_mlme.h| 2 +- drivers/staging/rtl8712/rtl871x_mp_ioctl.c| 6 ++-- drivers/staging/rtl8712/wlan_bssdef.h | 42 +++- 9 files changed, 64 insertions(+), 139 deletions(-) -- 2.4.6 From: Joshua Clayton To: Larry Finger , Florian Schilhabel , Greg Kroah-Hartman , Sudip Mukherjee , Nitin Kuppelur , Joshua Clayton , Vaishali Thakkar , Tapasweni Pathak , Daniel Baluta , Melike Yurtoglu , Max Perepelitsyn , Aya Mahfouz , Cristina Opriceana , Dogukan Ergun , Julia Lawall , Dan Carpenter , Haneen Mohammed , Rickard Strandqvist Cc: de...@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: [PATCH V3 0/8] clean up wlan_bssdef.h Date: Mon, 27 Jul 2015 21:41:09 -0700 Message-Id: X-Mailer: git-send-email 2.4.6 The main goal of this series is to get rid of a needless typedef in the rtl8712 wlan driver. In the course of fixing that, I found a bug that can (at least in theory) lead to a overrun
[PATCH V3 3/8] staging: rtl8712: fix comment
The old comment refers to a typedef name which is being removed,
and to a style of calculation which is no longer being used.
It falsely states that IELength is variable length, instead of IEs.
Change comment to simply state that the IEs field is a buffer of
variable size and that IELength refers to the current size.
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/wlan_bssdef.h | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8712/wlan_bssdef.h
b/drivers/staging/rtl8712/wlan_bssdef.h
index 2ea8a3d..8c5d6e7 100644
--- a/drivers/staging/rtl8712/wlan_bssdef.h
+++ b/drivers/staging/rtl8712/wlan_bssdef.h
@@ -83,17 +83,6 @@ struct NDIS_802_11_FIXED_IEs {
u16 Capabilities;
};
-/*
- * Length is the 4 bytes multiples of the sume of
- * 6 * sizeof (unsigned char) + 2 + sizeof (ndis_802_11_ssid) + sizeof (u32)
- * + sizeof (s32) + sizeof (NDIS_802_11_NETWORK_TYPE)
- * + sizeof (struct NDIS_802_11_CONFIGURATION)
- * + sizeof (NDIS_802_11_RATES_EX) + IELength
-
- * Except the IELength, all other fields are fixed length. Therefore, we can
- * define a macro to present the partial sum.
- */
-
struct ndis_wlan_bssid_ex {
u32 Length;
unsigned char MacAddress[6];
@@ -105,6 +94,7 @@ struct ndis_wlan_bssid_ex {
struct NDIS_802_11_CONFIGURATION Configuration;
enum NDIS_802_11_NETWORK_INFRASTRUCTURE InfrastructureMode;
NDIS_802_11_RATES_EX SupportedRates;
+ /* number of content bytes in EIs, which varies */
u32 IELength;
/*(timestamp, beacon interval, and capability information) */
u8 IEs[MAX_IE_SZ];
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg Kroah-Hartman ,
Sudip Mukherjee ,
Nitin Kuppelur ,
Joshua Clayton ,
Vaishali Thakkar ,
Tapasweni Pathak ,
Daniel Baluta ,
Melike Yurtoglu ,
Max Perepelitsyn ,
Aya Mahfouz ,
Cristina Opriceana ,
Dogukan Ergun ,
Julia Lawall ,
Dan Carpenter ,
Haneen Mohammed ,
Rickard Strandqvist
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: [PATCH V3 3/8] staging: rtl8712: fix comment
Date: Mon, 27 Jul 2015 21:41:12 -0700
Message-Id:
X-Mailer: git-send-email 2.4.6
In-Reply-To:
References:
In-Reply-To:
References:
The old comment refers to a typedef name which is being removed,
and to a style of calculation which is no longer being used.
It falsely states that IELength is variable length, instead of IEs.
Change comment to simply state that the IEs field is a buffer of
variable size and that IELength refers to the current size.
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/wlan_bssdef.h | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8712/wlan_bssdef.h
b/drivers/staging/rtl8712/wlan_bssdef.h
index 2ea8a3d..8c5d6e7 100644
--- a/drivers/staging/rtl8712/wlan_bssdef.h
+++ b/drivers/staging/rtl8712/wlan_bssdef.h
@@ -83,17 +83,6 @@ struct NDIS_802_11_FIXED_IEs {
u16 Capabilities;
};
-/*
- * Length is the 4 bytes multiples of the sume of
- * 6 * sizeof (unsigned char) + 2 + sizeof (ndis_802_11_ssid) + sizeof (u32)
- * + sizeof (s32) + sizeof (NDIS_802_11_NETWORK_TYPE)
- * + sizeof (struct NDIS_802_11_CONFIGURATION)
- * + sizeof (NDIS_802_11_RATES_EX) + IELength
-
- * Except the IELength, all other fields are fixed length. Therefore, we can
- * define a macro to present the partial sum.
- */
-
struct ndis_wlan_bssid_ex {
u32 Length;
unsigned char MacAddress[6];
@@ -105,6 +94,7 @@ struct ndis_wlan_bssid_ex {
struct NDIS_802_11_CONFIGURATION Configuration;
enum NDIS_802_11_NETWORK_INFRASTRUCTURE InfrastructureMode;
NDIS_802_11_RATES_EX SupportedRates;
+ /* number of content bytes in EIs, which varies */
u32 IELength;
/*(timestamp, beacon interval, and capability information) */
u8 IEs[MAX_IE_SZ];
--
2.4.6
From: Joshua Clayton
To: Larry Finger ,
Florian Schilhabel ,
Greg Kroah-Hartman ,
Sudip Mukherjee ,
Nitin Kuppelur ,
Joshua Clayton ,
Vaishali Thakkar ,
Tapasweni Pathak ,
Daniel Baluta ,
Melike Yurtoglu ,
Max Perepelitsyn ,
Aya Mahfouz ,
Cristina Opriceana ,
Dogukan Ergun ,
Julia Lawall ,
Dan Carpenter ,
Haneen Mohammed ,
Rickard Strandqvist
Cc: de...@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: [PATCH V3 3/8] staging: rtl8712: fix comment
Date: Mon, 27 Jul 2015 21:41:12 -0700
Message-Id:
X-Mailer: git-send-email 2.4.6
In-Reply-To:
References:
In-Reply-To:
References:
The old comment refers to a typedef name which is being removed,
and to a style of calculation which is no longer being used.
It falsely states that IELength is variable
Re: [PATCH v3 1/2] drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style
On Mon, Jul 27, 2015 at 05:04:41PM -0700, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > dma_alloc_writecombine()'s call and return value check is tangled in all > in one call. Untangle both calls according to kernel coding style. Acked-by: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] mtd: nand: Qualcomm NAND controller driver
Hi,
On 07/25/2015 06:21 AM, Stephen Boyd wrote:
On 07/21/2015 03:34 AM, Archit Taneja wrote:
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b2806a..31951fc 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -538,4 +538,11 @@ config MTD_NAND_HISI504
help
Enables support for NAND controller on Hisilicon SoC Hip04.
+config MTD_NAND_QCOM
+ tristate "Support for NAND on QCOM SoCs"
+ depends on ARCH_QCOM && QCOM_ADM
This is sort of annoying that the menu won't show up unless the ADM
driver is also enabled (which would be in a completely different area of
the configurator). Perhaps drop that requirement because it isn't
required to build?
That makes sense. I'll drop the QCOM_ADM requirement.
+ help
+ Enables support for NAND flash chips on SoCs containing the EBI2 NAND
+ controller. This controller is found on IPQ806x SoC.
+
endif # MTD_NAND
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
new file mode 100644
index 000..51c284c
--- /dev/null
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -0,0 +1,2019 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
Where is this used?
It isn't. I'll remove it.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
[..]
+/*
+ * the NAND controller performs reads/writes with ECC in 516 byte chunks.
+ * the driver calls the chunks 'step' or 'codeword' interchangeably
+ */
+#define NANDC_STEP_SIZE512
+
+/*
+ * the largest page size we support is 8K, this will have 16 steps/codewords
+ * of 512 bytes each
+ */
+#defineMAX_NUM_STEPS (SZ_8K / NANDC_STEP_SIZE)
+
+/* we read at most 3 registers per codeword scan */
+#define MAX_REG_RD (3 * MAX_NUM_STEPS)
+
+/* ECC modes */
+#define ECC_NONE BIT(0)
+#define ECC_RS_4BITBIT(1)
+#defineECC_BCH_4BITBIT(2)
+#defineECC_BCH_8BITBIT(3)
+
+struct desc_info {
+ struct list_head list;
+
+ enum dma_transfer_direction dir;
+ struct scatterlist sgl;
+ struct dma_async_tx_descriptor *dma_desc;
+};
+
+/*
+ * holds the current register values that we want to write. acts as a
contiguous
+ * chunk of memory which we use to write the controller registers through DMA.
+ */
+struct nandc_regs {
+ u32 cmd;
+ u32 addr0;
+ u32 addr1;
+ u32 chip_sel;
+ u32 exec;
+
+ u32 cfg0;
+ u32 cfg1;
+ u32 ecc_bch_cfg;
+
+ u32 clrflashstatus;
+ u32 clrreadstatus;
+
+ u32 cmd1;
+ u32 vld;
+
+ u32 orig_cmd1;
+ u32 orig_vld;
+
+ u32 ecc_buf_cfg;
+};
+
+/*
+ * @cmd_crci: ADM DMA CRCI for command flow control
+ * @data_crci: ADM DMA CRCI for data flow control
+ * @list: DMA descriptor list (list of desc_infos)
+ * @dma_done: completion param to denote end of last
+ * descriptor in the list
+ * @data_buffer: our local DMA buffer for page read/writes,
+ * used when we can't use the buffer provided
+ * by upper layers directly
+ * @buf_size/count/start: markers for chip->read_buf/write_buf functions
+ * @reg_read_buf: buffer for reading register data via DMA
+ * @reg_read_pos: marker for data read in reg_read_buf
+ * @cfg0, cfg1, cfg0_raw..:NANDc register configurations needed for
+ * ecc/non-ecc mode for the current nand flash
+ * device
+ * @regs: a contiguous chunk of memory for DMA register
+ * writes
+ * @ecc_strength: 4 bit or 8 bit ecc, received via DT
+ * @bus_width: 8 bit or 16 bit NAND bus width, received via DT
+ * @ecc_modes: supported ECC modes by the current controller,
+ * initialized via DT match data
+ * @cw_size: the number of bytes in a single step/codeword
+ * of a page, consisting of all data, ecc, spare
+ * and reserved bytes
+ * @cw_data: the number of bytes within a codeword protected
+ * by ECC
+ * @bch_enabled: flag
Re: [PATCH] kexec: Remove the unnecessary conditional judgement to simplify the code logic
On Mon, Jul 27, 2015 at 09:44:53AM -0400, Vivek Goyal wrote: > On Sat, Jun 06, 2015 at 02:14:12PM +0800, Minfei Huang wrote: > > From: Minfei Huang > > > > Transforming PFN(Page Frame Number) to struct page is never failure, so > > we can simplify the code logic to do the image->control_page assignment > > directly in the loop, and remove the unnecessary conditional judgement. > > > > Signed-off-by: Minfei Huang > > Looks good to me. > > Acked-by: Vivek Goyal FWIW, this probably needs to be reposted to Andrew Morton with appropriate Acks and CCs in order to proceed into his tree and then Linus's. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Add scaling frequency range support
On 28-07-15, 11:32, Pan Xinhui wrote: > From: Pan Xinhui > > Userspace at most time do cpufreq tests very much inconveniently. > Currently they have to echo min and max cpu freq separately like below: > echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq > echo 224 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq > > Add scaling_freq_range cpufreq attr to support userspace's demand. > Therefore it's easier for testers to write readable scripts like below: > echo 48-224 > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_freq_range I don't think this brings any good change, we already have support for that with min/max freqs and I don't see how scripts can be less readable with that. So, why to add redundant files at all? Also note that we can't remove the old interface as that will break the ABI. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb/gadget: make composite gadget meet usb compliance for vbus draw
> > From: Andrzej Pietrasiewicz [mailto:andrze...@samsung.com] Hi, > > > > What I mean is that in my opinion it should be done in a separate > > patch, because the newly introduced USB_VBUS_DRAW_SUSPEND is not > used > > anywhere else in your patch. The meaning of this change is "use a > > symbolic name rather than an explicit number" and it is unrelated to > > making composite gadget meet usb compliance for vbus draw. In other > > words, if you don't do this change at all the compliance is still > > maintained, because the value of USB_VBUS_DRAW_SUSPEND is 2 anyway, > so > > what the compiler eventually sees is the same whether the change is > > made or not. > > > > My idea: > > > > [PATCHv2 0/2] usb gadget vbus draw compilance > >[PATCHv2 1/2] usb: gadget: composite: avoid using a magic number > >>> substituting an explicit "2" with USB_VBUS_DRAW_SUSPEND goes > > here << > >[PATCHv2 2/2] usb: gadget: composite: meet usb compliance for vbus > draw > >>> the rest of your changes go here << > > > > > Hi, Andrzej. When I try to split into two patches, I realized that it is not applicable. Because the original code doesn't distinguish different usb types, but new symbols does. So I cannot make a patch just avoid using a magic number without modify the control logic. Hence, I'd prefer doing them in a signal patch. I will send new modified patch. Thanks! Changbin. > > > > Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] Add calls to translate Always Running Timer (ART) to system time
On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
wrote:
> +static bool checked_art_to_tsc(cycle_t *tsc)
> +{
> + if (!has_art())
> + return false;
> + *tsc = art_to_tsc(*tsc);
> + return true;
> +}
> +
> +static int art_to_rawmono64(struct timespec64 *rawmono, cycle_t art)
> +{
> + if (!checked_art_to_tsc())
> + return -ENXIO;
> + return tsc_to_rawmono64(rawmono, art);
> +}
> +EXPORT_SYMBOL(art_to_rawmono64);
This all seems to assume the TSC is the current clocksource, which it
may not be if the user has overridden it.
If instead there were a counter_to_rawmono64() which took the counter
value and maybe the name of the clocksource (if the strncmp is
affordable for your use), it might be easier for the core to provide
an error if the current timekeeping clocksource isn't the one the
counter value is based on. This would also allow the tsc_to_*()
midlayers to be dropped (since they don't seem to do much).
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Dear Purchasing manager, We supply kinds of PCB products, widely used in telecom, medical, LED and motor industries etc. Please kindly find our advantages as below. 1. 1-24layer, FR-4, Aluminum, also FPC board and PCBA assembly,ets… 2. Certificate: ISO14001， ISO 9001,TS16949, UL, etc…… 3. No MOQ and Flexible payment terms: paypal, T/T, L/C, Western Union etc… Price list will be sent to you asap. Any question, please let me know freely. Wish our products will be helpful for your business. Thanks Regards, Leon Zhang ** Sayfu Multilayer Circuits Co.,Limited Tel:+86-755-27759676 Cell: +86-13312967631 Fax:+86-755-26417917 Skype: eg_bruce Email: leon.zh...@sayfupcb.com Website: http://www.sfmpcb.com/ We are working with you and for you. P Please consider the environment before printing this e-mail Plnvwk9952.xls Description: application/msexcel
Re
Please contact me urgently for a transaction. Kind Regards Tan Wong --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/7] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
Hi Daniel,
On Fri, 2015-07-24 at 19:28 +0800, Daniel Kurtz wrote:
> On Fri, Jul 24, 2015 at 11:02 AM, James Liao
> wrote:
> > +struct clk *mtk_clk_register_ref2usb_tx(const char *name,
> > + const char *parent_name, void __iomem *reg)
>
> struct clk * __init mtk_clk_register_ref2usb_tx(
It will be added in next patch.
> >
> > #include
> > #include
> > -#include
> > -#include
>
> nit: this looks like an unrelated change that can be in its own patch.
It will be in a separated patch.
> >
> > +typedef struct clk *(*mtk_clk_register_ex)(const char *, const char *,
> > + void __iomem *);
> > +
> > +struct mtk_clk_ex {
> > + int id;
> > + const char *name;
> > + const char *parent;
> > + u32 reg_ofs;
> > + mtk_clk_register_ex reg_clk_ex;
>
>
> This "mtk_clk_ex" abstraction seems unnecessarily complicated for a
> one-off USB clock.
> Just call mtk_clk_register_ref2usb_tx() directly from mtk_apmixedsys_init().
Use a table to associate related constants and names is more readable,
such as:
APMIXED_EX(CLK_APMIXED_REF2USB_TX, "ref2usb_tx", ...
If we call mtk_clk_register_ref2usb_tx() directly, it will be:
clk = mtk_clk_register_ref2usb_tx("ref2usb_tx", ...);
clk_data-clks[CLK_APMIXED_REF2USB_TX] = clk;
Do you prefer the last one?
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Add functions producing system time given a backing counter value
On Mon, Jul 27, 2015 at 8:44 PM, John Stultz wrote: > On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall > wrote: >> * counter_to_rawmono64 >> * counter_to_mono64 >> * counter_to_realtime64 >> >> Enables drivers to translate a captured system clock counter to system >> time. This is useful for network and audio devices that capture timestamps >> in terms of both the system clock and device clock. > > Huh. So for counter_to_realtime64 & mono64, this seems to ignore the > fact that the multiplier is constantly adjusted and corrected. So that > calling the function twice with the same counter value may result in > different returned values. > > I've not yet groked the whole patchset, but it seems like there needs > to be some mechanism that ensures the counter value is captured and > used in the same (or at least close) interval that the timekeeper data > is valid for. So reading through. It looks like you only use art_to_realtime(), right? So again, since CLOCK_MONOTONIC and CLOCK_REALTIME are constaly being frequency adjusted, it might be best to construct this delta in the following way. Add counter_to_rawmono64(), which should be able to safely calculate the corresponding CLOCK_MONOTONIC_RAW time from any given cycle value. Use getnstime_raw_and_real() to get a immediate snapshot of current MONOTONIC_RAW and REALTIME clocks. Then calculate the delta between the snapshotted counter raw time, and the current raw time. Then apply that offset to the current realtime. The larger the raw-time delta, the larger the possible realtime error. But I think that will be as good as it gets. This should simplify the interfaces you're adding to the timekeeping core. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/1] serial: 8250_pci: add RS485 for F81504/508/512
Add RS485 control for Fintek F81504/508/512
F81504/508/512 can control their RTS with H/W mode.
PCI configuration space for each port is 0x40 + idx * 8 + 7.
When it set with 0x01, it's configured with RS232 mode.
RTS is controlled by MCR.
When it set with 0x11, it's configured with RS485 mode.
RTS is controlled by H/W, RTS low with idle & RX, high with TX.
When it set with 0x31, it's configured with RS485 mode.
RTS is controlled by H/W, RTS high with idle & RX, low with TX.
We will force 0x01 on pci_fintek_setup().
Changelog:
V2
1. change direct bit operation with meaningful define name.
2. due to F81504 series only support SER_RS485_ENABLED &
SER_RS485_RTS_ON_SEND. We'll clean non-support area of
struct serial_rs485.
3. change control method of SER_RS485_RTS_ON_SEND. In our
reference circuit, the transceiver default mode needed
in rx mode with RTS logic high, tx mode with RTS logic low.
If user set to SER_RS485_ENABLED(default), we should set
reg with 0x31. if SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND
will set reg to 0x11.
Signed-off-by: Peter Hung
---
drivers/tty/serial/8250/8250_pci.c | 61 ++
1 file changed, 61 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index e55f18b..5d16e14 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1685,11 +1685,60 @@ pci_brcm_trumanage_setup(struct serial_private *priv,
return ret;
}
+/* RTS will control by MCR if this bit is 0 */
+#define FINTEK_RTS_CONTROL_BY_HW BIT(4)
+/* only worked with FINTEK_RTS_CONTROL_BY_HW on */
+#define FINTEK_RTS_INVERT BIT(5)
+
+/* We should do proper H/W transceiver setting before change to RS485 mode */
+static int pci_fintek_rs485_config(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ u8 setting;
+ u8 *index = (u8 *) port->private_data;
+ struct pci_dev *pci_dev = container_of(port->dev, struct pci_dev,
+ dev);
+
+ pci_read_config_byte(pci_dev, 0x40 + 8 * *index + 7, );
+
+ if (rs485->flags & SER_RS485_ENABLED)
+ memset(rs485->padding, 0, sizeof(rs485->padding));
+ else
+ memset(rs485, 0, sizeof(*rs485));
+
+ /* F81504/508/512 not support RTS delay before or after send */
+ rs485->flags &= SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND;
+
+ if (rs485->flags & SER_RS485_ENABLED) {
+ /* Enable RTS H/W control mode */
+ setting |= FINTEK_RTS_CONTROL_BY_HW;
+
+ if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+ /* RTS driving high on TX */
+ setting &= ~FINTEK_RTS_INVERT;
+ } else {
+ /* RTS driving low on TX */
+ setting |= FINTEK_RTS_INVERT;
+ }
+
+ rs485->delay_rts_after_send = 0;
+ rs485->delay_rts_before_send = 0;
+ } else {
+ /* Disable RTS H/W control mode */
+ setting &= ~(FINTEK_RTS_CONTROL_BY_HW | FINTEK_RTS_INVERT);
+ }
+
+ pci_write_config_byte(pci_dev, 0x40 + 8 * *index + 7, setting);
+ port->rs485 = *rs485;
+ return 0;
+}
+
static int pci_fintek_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_8250_port *port, int idx)
{
struct pci_dev *pdev = priv->dev;
+ u8 *data;
u8 config_base;
u16 iobase;
@@ -1702,6 +1751,15 @@ static int pci_fintek_setup(struct serial_private *priv,
port->port.iotype = UPIO_PORT;
port->port.iobase = iobase;
+ port->port.rs485_config = pci_fintek_rs485_config;
+
+ data = devm_kzalloc(>dev, sizeof(u8), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* preserve index in PCI configuration space */
+ *data = idx;
+ port->port.private_data = data;
return 0;
}
@@ -1752,6 +1810,9 @@ static int pci_fintek_init(struct pci_dev *dev)
(u8)((iobase & 0xff00) >> 8));
pci_write_config_byte(dev, config_base + 0x06, dev->irq);
+
+ /* force init to RS232 Mode */
+ pci_write_config_byte(dev, config_base + 0x07, 0x01);
}
return max_port;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option
On 07/27/2015 11:16 PM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
wrote:
On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
wrote:
On 07/25/2015 01:36 AM, Andy Lutomirski wrote:
Here's v3. It fixes the "dazed and confused" issue, I hope. It's also
probably a good general attack surface reduction, and it replaces some
scary code with IMO less scary code.
Also, servers and embedded systems should probably turn off modify_ldt.
This makes that possible.
Xen people, can you take a look at this?
Willy and Kees: I left the config option alone. The -tiny people will
like it, and we can always add a sysctl of some sort later.
Changes from v3:
- Hopefully fixed Xen.
32b-on-32b fails in the same manner. (but non-zero LDT is taken care of)
- Fixed 32-bit test case on 32-bit native kernel.
I am not sure I see what changed.
I misplaced the fix in the wrong git commit, so I failed to sent it.
Oops.
I just sent v4.1 of patch 3. Can you try that?
I am hitting BUG() in Xen code (returning from a hypercall) when freeing LDT
in destroy_context(). Interestingly though when I run the test in the
debugger I get SIGILL (just like before) but no BUG().
Let me get back to you on that later today.
After forward-porting my virtio patches, I got this thing to run on
Xen. After several tries, I got:
[ 53.985707] [ cut here ]
[ 53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
[ 53.986677] invalid opcode: [#1] SMP
[ 53.986677] Modules linked in:
[ 53.986677] CPU: 0 PID: 1400 Comm: bash Not tainted 4.2.0-rc4+ #4
[ 53.986677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
04/01/2014
[ 53.986677] task: c2376180 ti: c0874000 task.ti: c0874000
[ 53.986677] EIP: 0061:[] EFLAGS: 00010282 CPU: 0
[ 53.986677] EIP is at set_aliased_prot+0xb2/0xc0
[ 53.986677] EAX: ffea EBX: cc3d1000 ECX: 0672e063 EDX: 8000
[ 53.986677] ESI: EDI: 8000 EBP: c0875e94 ESP: c0875e74
[ 53.986677] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[ 53.986677] CR0: 80050033 CR2: b77404d4 CR3: 020b6000 CR4: 00042660
[ 53.986677] Stack:
[ 53.986677] 8000 0672e063 21c0 cc3d1000 0001 cc3d2000
0b4a 0200
[ 53.986677] c0875ea8 c105312d c2317940 c2373a80 c0875eb4
c1062310 c01861c0
[ 53.986677] c0875ec0 c1062735 c01861c0 c0875ed4 c10a764e c7007a00
c2373a80
[ 53.986677] Call Trace:
[ 53.986677] [] xen_free_ldt+0x2d/0x40
[ 53.986677] [] free_ldt_struct.part.1+0x10/0x40
[ 53.986677] [] destroy_context+0x25/0x40
[ 53.986677] [] __mmdrop+0x1e/0xc0
[ 53.986677] [] finish_task_switch+0xd8/0x1a0
[ 53.986677] [] __schedule+0x316/0x950
[ 53.986677] [] schedule+0x26/0x70
[ 53.986677] [] do_wait+0x1b3/0x200
[ 53.986677] [] SyS_waitpid+0x67/0xd0
[ 53.986677] [] ? task_stopped_code+0x50/0x50
[ 53.986677] [] syscall_call+0x7/0x7
[ 53.986677] Code: e8 c1 e3 0c 81 eb 00 00 00 40 39 5d ec 74 11 8b
4d e4 8b 55 e0 31 f6 e8 dd e0 fa ff 85 c0 75 0d 83 c4 14 5b 5e 5f 5d
c3 90 0f 0b <0f> 0b 0f 0b 8d 76 00 8d bc 27 00 00 00 00 85 d2 74 31 55
89 e5
[ 53.986677] EIP: [] set_aliased_prot+0xb2/0xc0 SS:ESP 0069:c0875e74
[ 54.010069] ---[ end trace 89ac35b29c1c59bb ]---
Is that the error you're seeing?
If I change xen_free_ldt to:
static void xen_free_ldt(struct desc_struct *ldt, unsigned entries)
{
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
vm_unmap_aliases();
xen_mc_flush();
for(i = 0; i < entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL);
}
then it works. I don't know why this makes a difference.
(xen_mc_flush makes a little bit of sense to me. vm_unmap_aliases
doesn't.)
That fix makes sense if there's some way that the vmalloc area we're
freeing has an extra alias somewhere, which is very much possible. On
the other hand, I don't see how this happens without first doing an
MMUEXT_SET_LDT with an unexpectedly aliased address, and I would have
expected that to blow up and/or result in test case failures.
But I'm still confused, because it seems like Xen will never populate
the actual (hidden) LDT mapping unless the pages backing it are
unaliased and well-formed, which make me wonder why this stuff ever
worked. Wouldn't LDT access with pre-existing vmalloc aliases result
in segfaults?
The semantics seem to be very odd. xen_free_ldt with an aliased
address might fail (and OOPS), but actual access to the LDT with an
aliased address page faults.
Also, using kzalloc for everything fixes the problem, which suggests
that there really is something to my theory that the problem involves
unexpected aliases.
Yes, this is as far as I got as well (I didn't try unaliasing but now
that you found it -- it does indeed
Re: [PATCH 1/5] Add functions producing system time given a backing counter value
On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall wrote: > * counter_to_rawmono64 > * counter_to_mono64 > * counter_to_realtime64 > > Enables drivers to translate a captured system clock counter to system > time. This is useful for network and audio devices that capture timestamps > in terms of both the system clock and device clock. Huh. So for counter_to_realtime64 & mono64, this seems to ignore the fact that the multiplier is constantly adjusted and corrected. So that calling the function twice with the same counter value may result in different returned values. I've not yet groked the whole patchset, but it seems like there needs to be some mechanism that ensures the counter value is captured and used in the same (or at least close) interval that the timekeeper data is valid for. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Yama: remove needless CONFIG_SECURITY_YAMA_STACKED
On Thu, 23 Jul 2015, Kees Cook wrote: > Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded > config for Yama to be made to explicitly stack. Just selecting the main > Yama CONFIG will allow it to work, regardless of the major LSM. Since > distros using Yama are already forcing it to stack, this is effectively > a no-op change. > > Additionally add MAINTAINERS entry. > > Signed-off-by: Kees Cook Applied to -next. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: mediatek: fix transfer error handling
From: Liguo Zhang
Reset i2c dma engine in hw init function.
When occur i2c ack error, mtk_i2c_irq may is twice,
first is the ack error interrupt, then the complete interrupt,
so i2c->irq_stat need keep the two interrupt value, and only
call complete() for the complete interrupt.
Signed-off-by: Liguo Zhang
Signed-off-by: Eddie Huang
---
drivers/i2c/busses/i2c-mt65xx.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9920eef..57d11b7 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -59,6 +59,7 @@
#define I2C_DMA_START_EN 0x0001
#define I2C_DMA_INT_FLAG_NONE 0x
#define I2C_DMA_CLR_FLAG 0x
+#define I2C_DMA_HARD_RST 0x0002
#define I2C_DEFAULT_SPEED 10 /* hz */
#define MAX_FS_MODE_SPEED 40
@@ -81,6 +82,7 @@ enum DMA_REGS_OFFSET {
OFFSET_INT_FLAG = 0x0,
OFFSET_INT_EN = 0x04,
OFFSET_EN = 0x08,
+ OFFSET_RST = 0x0c,
OFFSET_CON = 0x18,
OFFSET_TX_MEM_ADDR = 0x1c,
OFFSET_RX_MEM_ADDR = 0x20,
@@ -262,6 +264,10 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN;
writew(control_reg, i2c->base + OFFSET_CONTROL);
writew(I2C_DELAY_LEN, i2c->base + OFFSET_DELAY_LEN);
+
+ writel(I2C_DMA_HARD_RST, i2c->pdmabase + OFFSET_RST);
+ udelay(50);
+ writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST);
}
/*
@@ -550,16 +556,20 @@ err_exit:
static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
{
struct mtk_i2c *i2c = dev_id;
- u16 restart_flag = 0;
+ u16 intr_stat = 0;
- if (i2c->dev_comp->auto_restart)
- restart_flag = I2C_RS_TRANSFER;
+ intr_stat = readw(i2c->base + OFFSET_INTR_STAT);
+ writew(intr_stat, i2c->base + OFFSET_INTR_STAT);
- i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT);
- writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR
- | I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_STAT);
+ /*
+* when occurs i2c ack error, mtk_i2c_irq is called twice,
+* first is the ack error interrupt, then the complete interrupt,
+* i2c->irq_stat need keep the two interrupt value.
+*/
+ i2c->irq_stat |= intr_stat;
- complete(>msg_complete);
+ if (i2c->irq_stat & I2C_TRANSAC_COMP)
+ complete(>msg_complete);
return IRQ_HANDLED;
}
@@ -729,3 +739,4 @@ module_platform_driver(mtk_i2c_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MediaTek I2C Bus Driver");
MODULE_AUTHOR("Xudong Chen ");
+MODULE_AUTHOR("Liguo Zhang ");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Correct a freq check in cpufreq_set_policy
From: Pan Xinhui
This check was originally added by commit 9c9a43ed2734 ("[CPUFREQ]
return error when failing to set minfreq").It attempt to return an error
on obviously incorrect limits when we echo xxx >.../scaling_max,min_freq
Actually we just need check if new_policy->min > new_policy->max.
Because at least one of max/min is copied from cpufreq_get_policy().
For example, when we echo xxx > .../scaling_min_freq, new_policy is
copied from policy in cpufreq_get_policy. new_policy->max is same with
policy->max. new_policy->min is set to a new value.
Let me explain it in deduction method, first statment in if ():
new_policy->min > policy->max
policy->max == new_policy->max
==> new_policy->min > new_policy->max
second statment in if():
new_policy->max < policy->min
policy->max < policy->min
==>new_policy->min > new_policy->max (induction method)
So we have proved that we only need check if new_policy->min >
new_policy->max.
After apply this patch, we can also modify ->min and ->max in same time
if new freq range is very much different from current freq range. For
example, if current freq range is 48-96, then we want to set
this range to 112-224, we would fail in the past because
new_policy->min > policy->max. As long as the cpufreq range is valid, we
has no reason to reject the user. So correct the check.
Signed-off-by: Pan Xinhui
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6424e05..8772346 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2276,7 +2276,7 @@ static int cpufreq_set_policy(struct cpufreq_policy
*policy,
memcpy(_policy->cpuinfo, >cpuinfo, sizeof(policy->cpuinfo));
- if (new_policy->min > policy->max || new_policy->max < policy->min)
+ if (new_policy->min > new_policy->max)
return -EINVAL;
/* verify the cpu speed can be set within this limit */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PULL] topic/crc-pmic
On Monday 27 July 2015 04:51 PM, Thierry Reding wrote: On Thu, Jul 23, 2015 at 09:38:46AM +0200, Daniel Vetter wrote: [...] On Thu, Jul 23, 2015 at 9:31 AM, Daniel Vetter wrote: [...] Shobhit Kumar (8): [...] pwm: crc: Add Crystalcove (CRC) PWM driver Would you mind removing this from your branch? I ended up manually applying a couple of changes that I had requested but ended up not getting addressed. Sorry if I missed, but I thought I had addressed all your comments in my last patch and did not see any further comments from you. Regards Shobhit When you drop it, let me know so I can push my branch to -next and have it not collide with your tree immediately. I assume it's in a branch that feeds into linux-next? Thierry ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Add scaling frequency range support
From: Pan Xinhui
Userspace at most time do cpufreq tests very much inconveniently.
Currently they have to echo min and max cpu freq separately like below:
echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 224 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
Add scaling_freq_range cpufreq attr to support userspace's demand.
Therefore it's easier for testers to write readable scripts like below:
echo 48-224 >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_freq_range
Signed-off-by: Pan Xinhui
---
drivers/cpufreq/cpufreq.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 26063af..6424e05 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -812,6 +812,35 @@ static ssize_t show_bios_limit(struct cpufreq_policy
*policy, char *buf)
return sprintf(buf, "%u\n", policy->cpuinfo.max_freq);
}
+static ssize_t store_scaling_freq_range(struct cpufreq_policy *policy,
+ char *buf, size_t count)
+{
+ int ret, temp_min, temp_max;
+ struct cpufreq_policy new_policy;
+
+ ret = cpufreq_get_policy(_policy, policy->cpu);
+ if (ret)
+ return -EINVAL;
+
+ ret = sscanf(buf, "%u-%u", _policy.min, _policy.max);
+ if (ret != 2)
+ return -EINVAL;
+
+ temp_min = new_policy.min;
+ temp_max = new_policy.max;
+ ret = cpufreq_set_policy(policy, _policy);
+ if (!ret) {
+ policy->user_policy.min = temp_min;
+ policy->user_policy.max = temp_max;
+ }
+ return ret ? ret : count;
+}
+
+static ssize_t show_scaling_freq_range(struct cpufreq_policy *policy, char
*buf)
+{
+ return sprintf(buf, "%u-%u\n", policy->min, policy->max);
+}
+
cpufreq_freq_attr_ro_perm(cpuinfo_cur_freq, 0400);
cpufreq_freq_attr_ro(cpuinfo_min_freq);
cpufreq_freq_attr_ro(cpuinfo_max_freq);
@@ -826,6 +855,7 @@ cpufreq_freq_attr_rw(scaling_min_freq);
cpufreq_freq_attr_rw(scaling_max_freq);
cpufreq_freq_attr_rw(scaling_governor);
cpufreq_freq_attr_rw(scaling_setspeed);
+cpufreq_freq_attr_rw(scaling_freq_range);
static struct attribute *default_attrs[] = {
_min_freq.attr,
@@ -839,6 +869,7 @@ static struct attribute *default_attrs[] = {
_driver.attr,
_available_governors.attr,
_setspeed.attr,
+ _freq_range.attr,
NULL
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option
On Mon, Jul 27, 2015 at 8:16 PM, Andy Lutomirski wrote:
> On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski wrote:
>> On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
>> wrote:
>>> On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
wrote:
>
> On 07/25/2015 01:36 AM, Andy Lutomirski wrote:
>>
>> Here's v3. It fixes the "dazed and confused" issue, I hope. It's also
>> probably a good general attack surface reduction, and it replaces some
>> scary code with IMO less scary code.
>>
>> Also, servers and embedded systems should probably turn off modify_ldt.
>> This makes that possible.
>>
>> Xen people, can you take a look at this?
>>
>> Willy and Kees: I left the config option alone. The -tiny people will
>> like it, and we can always add a sysctl of some sort later.
>>
>> Changes from v3:
>>- Hopefully fixed Xen.
>
>
> 32b-on-32b fails in the same manner. (but non-zero LDT is taken care of)
>
>>- Fixed 32-bit test case on 32-bit native kernel.
>
>
> I am not sure I see what changed.
I misplaced the fix in the wrong git commit, so I failed to sent it.
Oops.
I just sent v4.1 of patch 3. Can you try that?
>>>
>>>
>>>
>>> I am hitting BUG() in Xen code (returning from a hypercall) when freeing LDT
>>> in destroy_context(). Interestingly though when I run the test in the
>>> debugger I get SIGILL (just like before) but no BUG().
>>>
>>> Let me get back to you on that later today.
>>>
>>>
>>
>> After forward-porting my virtio patches, I got this thing to run on
>> Xen. After several tries, I got:
>>
>> [ 53.985707] [ cut here ]
>> [ 53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
>> [ 53.986677] invalid opcode: [#1] SMP
>> [ 53.986677] Modules linked in:
>> [ 53.986677] CPU: 0 PID: 1400 Comm: bash Not tainted 4.2.0-rc4+ #4
>> [ 53.986677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
>> 04/01/2014
>> [ 53.986677] task: c2376180 ti: c0874000 task.ti: c0874000
>> [ 53.986677] EIP: 0061:[] EFLAGS: 00010282 CPU: 0
>> [ 53.986677] EIP is at set_aliased_prot+0xb2/0xc0
>> [ 53.986677] EAX: ffea EBX: cc3d1000 ECX: 0672e063 EDX: 8000
>> [ 53.986677] ESI: EDI: 8000 EBP: c0875e94 ESP: c0875e74
>> [ 53.986677] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
>> [ 53.986677] CR0: 80050033 CR2: b77404d4 CR3: 020b6000 CR4: 00042660
>> [ 53.986677] Stack:
>> [ 53.986677] 8000 0672e063 21c0 cc3d1000 0001 cc3d2000
>> 0b4a 0200
>> [ 53.986677] c0875ea8 c105312d c2317940 c2373a80 c0875eb4
>> c1062310 c01861c0
>> [ 53.986677] c0875ec0 c1062735 c01861c0 c0875ed4 c10a764e c7007a00
>> c2373a80
>> [ 53.986677] Call Trace:
>> [ 53.986677] [] xen_free_ldt+0x2d/0x40
>> [ 53.986677] [] free_ldt_struct.part.1+0x10/0x40
>> [ 53.986677] [] destroy_context+0x25/0x40
>> [ 53.986677] [] __mmdrop+0x1e/0xc0
>> [ 53.986677] [] finish_task_switch+0xd8/0x1a0
>> [ 53.986677] [] __schedule+0x316/0x950
>> [ 53.986677] [] schedule+0x26/0x70
>> [ 53.986677] [] do_wait+0x1b3/0x200
>> [ 53.986677] [] SyS_waitpid+0x67/0xd0
>> [ 53.986677] [] ? task_stopped_code+0x50/0x50
>> [ 53.986677] [] syscall_call+0x7/0x7
>> [ 53.986677] Code: e8 c1 e3 0c 81 eb 00 00 00 40 39 5d ec 74 11 8b
>> 4d e4 8b 55 e0 31 f6 e8 dd e0 fa ff 85 c0 75 0d 83 c4 14 5b 5e 5f 5d
>> c3 90 0f 0b <0f> 0b 0f 0b 8d 76 00 8d bc 27 00 00 00 00 85 d2 74 31 55
>> 89 e5
>> [ 53.986677] EIP: [] set_aliased_prot+0xb2/0xc0 SS:ESP
>> 0069:c0875e74
>> [ 54.010069] ---[ end trace 89ac35b29c1c59bb ]---
>>
>> Is that the error you're seeing?
>>
>> If I change xen_free_ldt to:
>>
>> static void xen_free_ldt(struct desc_struct *ldt, unsigned entries)
>> {
>> const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
>> int i;
>>
>> vm_unmap_aliases();
>> xen_mc_flush();
>>
>> for(i = 0; i < entries; i += entries_per_page)
>> set_aliased_prot(ldt + i, PAGE_KERNEL);
>> }
>>
>> then it works. I don't know why this makes a difference.
>> (xen_mc_flush makes a little bit of sense to me. vm_unmap_aliases
>> doesn't.)
>>
>
> That fix makes sense if there's some way that the vmalloc area we're
> freeing has an extra alias somewhere, which is very much possible. On
> the other hand, I don't see how this happens without first doing an
> MMUEXT_SET_LDT with an unexpectedly aliased address, and I would have
> expected that to blow up and/or result in test case failures.
>
> But I'm still confused, because it seems like Xen will never populate
> the actual (hidden) LDT mapping unless the pages backing it are
> unaliased and well-formed, which make me wonder why this stuff ever
> worked. Wouldn't LDT access with pre-existing vmalloc aliases result
>
[PATCH v3 3/5] devicetree: soc: Add Qualcomm SMD based RPM DT binding
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.
The binding currently describes the rpm itself and the regulator
subnodes.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Moved from mfd
.../devicetree/bindings/soc/qcom,smd-rpm.txt | 117 +
1 file changed, 117 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
new file mode 100644
index ..e27f5c4c54fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
@@ -0,0 +1,117 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,rpm-msm8974"
+
+- qcom,smd-channels:
+ Usage: required
+ Value type:
+ Definition: Shared Memory channel used for communication with the RPM
+
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Regulators
+
+Regulator nodes are identified by their compatible:
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,rpm-pm8841-regulators"
+ "qcom,rpm-pm8941-regulators"
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+ Usage: optional (pm8841 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_l1_l3-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vdd_l4_l11-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l21-supply:
+- vin_5vs-supply:
+ Usage: optional (pm8941 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+The regulator node houses sub-nodes for each regulator within the device. Each
+sub-node is identified using the node's name, with valid values listed for each
+of the pmics below.
+
+pm8841:
+ s1, s2, s3, s4, s5, s6, s7, s8
+
+pm8941:
+ s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+ l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
+ lvs3, 5vs1, 5vs2
+
+The content of each sub-node is defined by the standard binding for regulators
-
+see regulator.txt.
+
+= EXAMPLE
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = < 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8974";
+ qcom,smd-channels = "rpm_requests";
+
+ pm8941-regulators {
+ compatible =
"qcom,rpm-pm8941-regulators";
+ vdd_l13_l20_l23_l24-supply =
<_boost>;
+
+ pm8941_s3: s3 {
+ regulator-min-microvolt =
<180>;
+ regulator-max-microvolt =
<180>;
+ };
+
+ pm8941_boost: s4 {
+ regulator-min-microvolt =
<500>;
+ regulator-max-microvolt =
<500>;
+ };
+
+ pm8941_l20: l20 {
+ regulator-min-microvolt =
<295>;
+ regulator-max-microvolt =
<295>;
+ };
+ };
+ };
+ };
+ };
+
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/5] soc: qcom: Driver for the Qualcomm RPM over SMD
Driver for the Resource Power Manager (RPM) found in Qualcomm 8974 based
devices.
The driver exposes resources that child drivers can operate on; to
implementing regulator, clock and bus frequency drivers.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Updated error handling path in RPM driver
- Moved to arch_initcall
- Moved from mfd
drivers/soc/qcom/Kconfig | 14 +++
drivers/soc/qcom/Makefile| 1 +
drivers/soc/qcom/smd-rpm.c | 244 +++
include/linux/soc/qcom/smd-rpm.h | 35 ++
4 files changed, 294 insertions(+)
create mode 100644 drivers/soc/qcom/smd-rpm.c
create mode 100644 include/linux/soc/qcom/smd-rpm.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 5c1a067b6677..65181d5d7574 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -26,6 +26,20 @@ config QCOM_SMD
providing communication channels to remote processors in Qualcomm
platforms.
+config QCOM_SMD_RPM
+ tristate "Qualcomm Resource Power Manager (RPM) over SMD"
+ depends on QCOM_SMD && OF
+ help
+ If you say yes to this option, support will be included for the
+ Resource Power Manager system found in the Qualcomm 8974 based
+ devices.
+
+ This is required to access many regulators, clocks and bus
+ frequencies controlled by the RPM on these devices.
+
+ Say M here if you want to include support for the Qualcomm RPM as a
+ module. This will build a module called "qcom-smd-rpm".
+
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f961a8796ed2..10a93d168e0e 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_PM) += spm.o
obj-$(CONFIG_QCOM_SMD) += smd.o
+obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
new file mode 100644
index ..1392ccf14a20
--- /dev/null
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+
+#define RPM_REQUEST_TIMEOUT (5 * HZ)
+
+/**
+ * struct qcom_smd_rpm - state of the rpm device driver
+ * @rpm_channel: reference to the smd channel
+ * @ack: completion for acks
+ * @lock: mutual exclusion around the send/complete pair
+ * @ack_status:result of the rpm request
+ */
+struct qcom_smd_rpm {
+ struct qcom_smd_channel *rpm_channel;
+
+ struct completion ack;
+ struct mutex lock;
+ int ack_status;
+};
+
+/**
+ * struct qcom_rpm_header - header for all rpm requests and responses
+ * @service_type: identifier of the service
+ * @length:length of the payload
+ */
+struct qcom_rpm_header {
+ u32 service_type;
+ u32 length;
+};
+
+/**
+ * struct qcom_rpm_request - request message to the rpm
+ * @msg_id:identifier of the outgoing message
+ * @flags: active/sleep state flags
+ * @type: resource type
+ * @id:resource id
+ * @data_len: length of the payload following this header
+ */
+struct qcom_rpm_request {
+ u32 msg_id;
+ u32 flags;
+ u32 type;
+ u32 id;
+ u32 data_len;
+};
+
+/**
+ * struct qcom_rpm_message - response message from the rpm
+ * @msg_type: indicator of the type of message
+ * @length:the size of this message, including the message header
+ * @msg_id:message id
+ * @message: textual message from the rpm
+ *
+ * Multiple of these messages can be stacked in an rpm message.
+ */
+struct qcom_rpm_message {
+ u32 msg_type;
+ u32 length;
+ union {
+ u32 msg_id;
+ u8 message[0];
+ };
+};
+
+#define RPM_SERVICE_TYPE_REQUEST 0x00716572 /* "req\0" */
+
+#define RPM_MSG_TYPE_ERR 0x00727265 /* "err\0" */
+#define RPM_MSG_TYPE_MSG_ID0x2367736d /* "msg#" */
+
+/**
+ * qcom_rpm_smd_write - write @buf to @type:@id
+ * @rpm: rpm handle
+ * @type: resource type
+ * @id:resource identifier
+ * @buf: the data to be
[PATCH v3 5/5] regulator: Regulator driver for the Qualcomm RPM
Driver for regulators exposed by the Resource Power Manager (RPM) found
in devices based on Qualcomm 8974 and newer platforms.
Reviewed-by: Mark Brown
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Updated Kconfig dependency to follow smd's move from mfd
drivers/regulator/Kconfig | 12 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom_smd-regulator.c | 349 +
3 files changed, 362 insertions(+)
create mode 100644 drivers/regulator/qcom_smd-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index a7b81f0185b5..dd991d08d778 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -514,6 +514,18 @@ config REGULATOR_QCOM_RPM
Qualcomm RPM as a module. The module will be named
"qcom_rpm-regulator".
+config REGULATOR_QCOM_SMD_RPM
+ tristate "Qualcomm SMD based RPM regulator driver"
+ depends on QCOM_SMD_RPM
+ help
+ If you say yes to this option, support will be included for the
+ regulators exposed by the Resource Power Manager found in Qualcomm
+ 8974 based devices.
+
+ Say M here if you want to include support for the regulators on the
+ Qualcomm RPM as a module. The module will be named
+ "qcom_smd-regulator".
+
config REGULATOR_QCOM_SPMI
tristate "Qualcomm SPMI regulator driver"
depends on SPMI || COMPILE_TEST
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6429e629dcb6..a00cffcf6bf9 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
new file mode 100644
index ..9d093ae36ba7
--- /dev/null
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -0,0 +1,349 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+
+struct qcom_rpm_reg {
+ struct device *dev;
+
+ struct qcom_smd_rpm *rpm;
+
+ u32 type;
+ u32 id;
+
+ struct regulator_desc desc;
+
+ int is_enabled;
+ int uV;
+};
+
+struct rpm_regulator_req {
+ u32 key;
+ u32 nbytes;
+ u32 value;
+};
+
+#define RPM_KEY_SWEN 0x6e657773 /* "swen" */
+#define RPM_KEY_UV 0x7675 /* "uv" */
+#define RPM_KEY_MA 0x616d /* "ma" */
+
+static int rpm_reg_write_active(struct qcom_rpm_reg *vreg,
+ struct rpm_regulator_req *req,
+ size_t size)
+{
+ return qcom_rpm_smd_write(vreg->rpm,
+ QCOM_SMD_RPM_ACTIVE_STATE,
+ vreg->type,
+ vreg->id,
+ req, size);
+}
+
+static int rpm_reg_enable(struct regulator_dev *rdev)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+ struct rpm_regulator_req req;
+ int ret;
+
+ req.key = RPM_KEY_SWEN;
+ req.nbytes = sizeof(u32);
+ req.value = 1;
+
+ ret = rpm_reg_write_active(vreg, , sizeof(req));
+ if (!ret)
+ vreg->is_enabled = 1;
+
+ return ret;
+}
+
+static int rpm_reg_is_enabled(struct regulator_dev *rdev)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+
+ return vreg->is_enabled;
+}
+
+static int rpm_reg_disable(struct regulator_dev *rdev)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+ struct rpm_regulator_req req;
+ int ret;
+
+ req.key = RPM_KEY_SWEN;
+ req.nbytes = sizeof(u32);
+ req.value = 0;
+
+ ret = rpm_reg_write_active(vreg, , sizeof(req));
+ if (!ret)
+ vreg->is_enabled = 0;
+
+ return ret;
+}
+
+static int rpm_reg_get_voltage(struct regulator_dev *rdev)
+{
+ struct qcom_rpm_reg *vreg =
[PATCH v3 0/5] Qualcomm Shared Memory & RPM drivers
The third iteration of the patches to add support for the regulators provided by the RPM on family B Qualcomm devices. This depends on the SMEM implementation that Andy already picked up. Changes since v2: - Made smd copy functions work on words for the word access channels - Corrected access of smem items from secure heap - Updated error handling path in RPM driver - Moved init of smd to postcore and rpm to arch - Minor nits from Georgi on the SMD code - Moved rpm driver from mfd to soc Bjorn Andersson (5): soc: qcom: Add device tree binding for Shared Memory Device soc: qcom: Add Shared Memory Driver devicetree: soc: Add Qualcomm SMD based RPM DT binding soc: qcom: Driver for the Qualcomm RPM over SMD regulator: Regulator driver for the Qualcomm RPM .../devicetree/bindings/soc/qcom,smd-rpm.txt | 117 ++ .../devicetree/bindings/soc/qcom/qcom,smd.txt | 79 ++ drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/qcom_smd-regulator.c | 349 ++ drivers/soc/qcom/Kconfig | 22 + drivers/soc/qcom/Makefile |2 + drivers/soc/qcom/smd-rpm.c | 244 drivers/soc/qcom/smd.c | 1319 include/linux/soc/qcom/smd-rpm.h | 35 + include/linux/soc/qcom/smd.h | 46 + 11 files changed, 2226 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt create mode 100644 drivers/regulator/qcom_smd-regulator.c create mode 100644 drivers/soc/qcom/smd-rpm.c create mode 100644 drivers/soc/qcom/smd.c create mode 100644 include/linux/soc/qcom/smd-rpm.h create mode 100644 include/linux/soc/qcom/smd.h -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/5] soc: qcom: Add Shared Memory Driver
This adds the Qualcomm Shared Memory Driver (SMD) providing
communication channels to remote processors, ontop of SMEM.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Made smd copy functions work on words for the word access channels
- Corrected access of smem items from secure heap
- Moved init of smd to postcore
- Minor nits from Georgi on the SMD code
drivers/soc/qcom/Kconfig |8 +
drivers/soc/qcom/Makefile|1 +
drivers/soc/qcom/smd.c | 1319 ++
include/linux/soc/qcom/smd.h | 46 ++
4 files changed, 1374 insertions(+)
create mode 100644 drivers/soc/qcom/smd.c
create mode 100644 include/linux/soc/qcom/smd.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 8544e1594c2c..5c1a067b6677 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -18,6 +18,14 @@ config QCOM_PM
modes. It interface with various system drivers to put the cores in
low power modes.
+config QCOM_SMD
+ tristate "Qualcomm Shared Memory Driver (SMD)"
+ depends on QCOM_SMEM
+ help
+ Say y here to enable support for the Qualcomm Shared Memory Driver
+ providing communication channels to remote processors in Qualcomm
+ platforms.
+
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 3a033c43c0ef..f961a8796ed2 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_PM) += spm.o
+obj-$(CONFIG_QCOM_SMD) += smd.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
new file mode 100644
index ..327adcf117c1
--- /dev/null
+++ b/drivers/soc/qcom/smd.c
@@ -0,0 +1,1319 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+
+/*
+ * The Qualcomm Shared Memory communication solution provides point-to-point
+ * channels for clients to send and receive streaming or packet based data.
+ *
+ * Each channel consists of a control item (channel info) and a ring buffer
+ * pair. The channel info carry information related to channel state, flow
+ * control and the offsets within the ring buffer.
+ *
+ * All allocated channels are listed in an allocation table, identifying the
+ * pair of items by name, type and remote processor.
+ *
+ * Upon creating a new channel the remote processor allocates channel info and
+ * ring buffer items from the smem heap and populate the allocation table. An
+ * interrupt is sent to the other end of the channel and a scan for new
+ * channels should be done. A channel never goes away, it will only change
+ * state.
+ *
+ * The remote processor signals it intent for bring up the communication
+ * channel by setting the state of its end of the channel to "opening" and
+ * sends out an interrupt. We detect this change and register a smd device to
+ * consume the channel. Upon finding a consumer we finish the handshake and the
+ * channel is up.
+ *
+ * Upon closing a channel, the remote processor will update the state of its
+ * end of the channel and signal us, we will then unregister any attached
+ * device and close our end of the channel.
+ *
+ * Devices attached to a channel can use the qcom_smd_send function to push
+ * data to the channel, this is done by copying the data into the tx ring
+ * buffer, updating the pointers in the channel info and signaling the remote
+ * processor.
+ *
+ * The remote processor does the equivalent when it transfer data and upon
+ * receiving the interrupt we check the channel info for new data and delivers
+ * this to the attached device. If the device is not ready to receive the data
+ * we leave it in the ring buffer for now.
+ */
+
+struct smd_channel_info;
+struct smd_channel_info_word;
+
+#define SMD_ALLOC_TBL_COUNT2
+#define SMD_ALLOC_TBL_SIZE 64
+
+/*
+ * This lists the various smem heap items relevant for the allocation table and
+ * smd channel entries.
+ */
+static const struct {
+ unsigned alloc_tbl_id;
+ unsigned info_base_id;
+ unsigned fifo_base_id;
+} smem_items[SMD_ALLOC_TBL_COUNT] = {
+ {
+
[PATCH v3 1/5] soc: qcom: Add device tree binding for Shared Memory Device
Add device tree binding documentation for the Qualcomm Shared Memory
Device, used for communication between the various CPUs in the Qualcomm
SoCs.
Signed-off-by: Bjorn Andersson
---
No changes since v2
.../devicetree/bindings/soc/qcom/qcom,smd.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
new file mode 100644
index ..f65c76db9859
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
@@ -0,0 +1,79 @@
+Qualcomm Shared Memory Driver (SMD) binding
+
+This binding describes the Qualcomm Shared Memory Driver, a fifo based
+communication channel for sending data between the various subsystems in
+Qualcomm platforms.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,smd"
+
+= EDGES
+
+Each subnode of the SMD node represents a remote subsystem or a remote
+processor of some sort - or in SMD language an "edge". The name of the edges
+are not important.
+The edge is described by the following properties:
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: should specify the IRQ used by the remote processor to
+ signal this processor about communication related updates
+
+- qcom,ipc:
+ Usage: required
+ Value type:
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the remote processor:
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,smd-edge:
+ Usage: required
+ Value type:
+ Definition: the identifier of the remote processor in the smd channel
+ allocation table
+
+= SMD DEVICES
+
+In turn, subnodes of the "edges" represent devices tied to SMD channels on that
+"edge". The names of the devices are not important. The properties of these
+nodes are defined by the individual bindings for the SMD devices - but must
+contain the following property:
+
+- qcom,smd-channels:
+ Usage: required
+ Value type:
+ Definition: a list of channels tied to this device, used for matching
+ the device to channels
+
+= EXAMPLE
+
+The following example represents a smd node, with one edge representing the
+"rpm" subsystem. For the "rpm" subsystem we have a device tied to the
+"rpm_request" channel.
+
+ apcs: syscon@f9011000 {
+ compatible = "syscon";
+ reg = <0xf9011000 0x1000>;
+ };
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = < 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8974";
+ qcom,smd-channels = "rpm_requests";
+
+ ...
+ };
+ };
+ };
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] ARM: dts: vf500-colibri: Add device tree node for touchscreen support
On Thu, Jul 16, 2015 at 08:43:20PM +0530, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
>
> Signed-off-by: Sanchayan Maity
> ---
> arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 4 +++
> arch/arm/boot/dts/vf500-colibri.dtsi| 46
> +
> 2 files changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c5efb57 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,7 @@
> model = "Toradex Colibri VF50 on Colibri Evaluation Board";
> compatible = "toradex,vf500-colibri_vf50-on-eval",
> "toradex,vf500-colibri_vf50", "fsl,vf500";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..7cbe341 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,50 @@
> memory {
> reg = <0x8000 0x800>;
> };
> +
> + touchctrl: vf50_touchctrl {
Minus rather than underscore should be used in node name. And node name
should be generic. "touchscreen" might be a good choice.
Shawn
> + compatible = "toradex,vf50-touchctrl";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + pen-detect-gpios = < 8 GPIO_ACTIVE_HIGH>;
> + pen-pullup-gpios = < 9 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + status = "disabled";
> + };
> +};
> +
> + {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x206d
> + VF610_PAD_PTA19__GPIO_9 0x206d
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0 0x2060
> + VF610_PAD_PTA19__ADC0_SE1 0x2060
> + VF610_PAD_PTA16__ADC1_SE0 0x2060
> + VF610_PAD_PTB2__ADC1_SE20x2060
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
> };
> --
> 2.4.6
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option
On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski wrote:
> On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
> wrote:
>> On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
>>>
>>> On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
>>> wrote:
On 07/25/2015 01:36 AM, Andy Lutomirski wrote:
>
> Here's v3. It fixes the "dazed and confused" issue, I hope. It's also
> probably a good general attack surface reduction, and it replaces some
> scary code with IMO less scary code.
>
> Also, servers and embedded systems should probably turn off modify_ldt.
> This makes that possible.
>
> Xen people, can you take a look at this?
>
> Willy and Kees: I left the config option alone. The -tiny people will
> like it, and we can always add a sysctl of some sort later.
>
> Changes from v3:
>- Hopefully fixed Xen.
32b-on-32b fails in the same manner. (but non-zero LDT is taken care of)
>- Fixed 32-bit test case on 32-bit native kernel.
I am not sure I see what changed.
>>>
>>> I misplaced the fix in the wrong git commit, so I failed to sent it.
>>> Oops.
>>>
>>> I just sent v4.1 of patch 3. Can you try that?
>>
>>
>>
>> I am hitting BUG() in Xen code (returning from a hypercall) when freeing LDT
>> in destroy_context(). Interestingly though when I run the test in the
>> debugger I get SIGILL (just like before) but no BUG().
>>
>> Let me get back to you on that later today.
>>
>>
>
> After forward-porting my virtio patches, I got this thing to run on
> Xen. After several tries, I got:
>
> [ 53.985707] [ cut here ]
> [ 53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
> [ 53.986677] invalid opcode: [#1] SMP
> [ 53.986677] Modules linked in:
> [ 53.986677] CPU: 0 PID: 1400 Comm: bash Not tainted 4.2.0-rc4+ #4
> [ 53.986677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
> 04/01/2014
> [ 53.986677] task: c2376180 ti: c0874000 task.ti: c0874000
> [ 53.986677] EIP: 0061:[] EFLAGS: 00010282 CPU: 0
> [ 53.986677] EIP is at set_aliased_prot+0xb2/0xc0
> [ 53.986677] EAX: ffea EBX: cc3d1000 ECX: 0672e063 EDX: 8000
> [ 53.986677] ESI: EDI: 8000 EBP: c0875e94 ESP: c0875e74
> [ 53.986677] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
> [ 53.986677] CR0: 80050033 CR2: b77404d4 CR3: 020b6000 CR4: 00042660
> [ 53.986677] Stack:
> [ 53.986677] 8000 0672e063 21c0 cc3d1000 0001 cc3d2000
> 0b4a 0200
> [ 53.986677] c0875ea8 c105312d c2317940 c2373a80 c0875eb4
> c1062310 c01861c0
> [ 53.986677] c0875ec0 c1062735 c01861c0 c0875ed4 c10a764e c7007a00
> c2373a80
> [ 53.986677] Call Trace:
> [ 53.986677] [] xen_free_ldt+0x2d/0x40
> [ 53.986677] [] free_ldt_struct.part.1+0x10/0x40
> [ 53.986677] [] destroy_context+0x25/0x40
> [ 53.986677] [] __mmdrop+0x1e/0xc0
> [ 53.986677] [] finish_task_switch+0xd8/0x1a0
> [ 53.986677] [] __schedule+0x316/0x950
> [ 53.986677] [] schedule+0x26/0x70
> [ 53.986677] [] do_wait+0x1b3/0x200
> [ 53.986677] [] SyS_waitpid+0x67/0xd0
> [ 53.986677] [] ? task_stopped_code+0x50/0x50
> [ 53.986677] [] syscall_call+0x7/0x7
> [ 53.986677] Code: e8 c1 e3 0c 81 eb 00 00 00 40 39 5d ec 74 11 8b
> 4d e4 8b 55 e0 31 f6 e8 dd e0 fa ff 85 c0 75 0d 83 c4 14 5b 5e 5f 5d
> c3 90 0f 0b <0f> 0b 0f 0b 8d 76 00 8d bc 27 00 00 00 00 85 d2 74 31 55
> 89 e5
> [ 53.986677] EIP: [] set_aliased_prot+0xb2/0xc0 SS:ESP
> 0069:c0875e74
> [ 54.010069] ---[ end trace 89ac35b29c1c59bb ]---
>
> Is that the error you're seeing?
>
> If I change xen_free_ldt to:
>
> static void xen_free_ldt(struct desc_struct *ldt, unsigned entries)
> {
> const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
> int i;
>
> vm_unmap_aliases();
> xen_mc_flush();
>
> for(i = 0; i < entries; i += entries_per_page)
> set_aliased_prot(ldt + i, PAGE_KERNEL);
> }
>
> then it works. I don't know why this makes a difference.
> (xen_mc_flush makes a little bit of sense to me. vm_unmap_aliases
> doesn't.)
>
That fix makes sense if there's some way that the vmalloc area we're
freeing has an extra alias somewhere, which is very much possible. On
the other hand, I don't see how this happens without first doing an
MMUEXT_SET_LDT with an unexpectedly aliased address, and I would have
expected that to blow up and/or result in test case failures.
But I'm still confused, because it seems like Xen will never populate
the actual (hidden) LDT mapping unless the pages backing it are
unaliased and well-formed, which make me wonder why this stuff ever
worked. Wouldn't LDT access with pre-existing vmalloc aliases result
in segfaults?
The semantics seem to be very odd. xen_free_ldt with an aliased
address might fail (and OOPS), but actual access to the LDT with an
aliased address page faults.
Also, using
Re: Revised futex(2) man page for review
On Mon, 2015-07-27 at 13:10 +0200, Michael Kerrisk (man-pages) wrote: > Hi David, > > On 03/31/2015 04:45 PM, Davidlohr Bueso wrote: > > On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote: > > > >>The condition is represented by the futex word, which is an address > >> in > >>memory supplied to the futex() system call, and the value at this > >> mem‐ > >>ory location. (While the virtual addresses for the same memory in > >> sep‐ > >>arate processes may not be equal, the kernel maps them > >> internally so > >>that the same memory mapped in different locations will correspond > >> for > >>futex() calls.) > >> > >>When executing a futex operation that requests to block a thread, > >> the > >>kernel will only block if the futex word has the value that the > >> calling > > > > Given the use of "word", you should probably state right away that > > futexes are only 32bit. > > So, I made the opening sentence here: > >The condition is represented by the futex word, which is an >address in memory supplied to the futex() system call, and the >32-bit value at this memory location. > > Okay? I think we can still improve :) I've re-read the whole first paragraphs, and have a few comments that touch upon this specific wording. Lets see. You have: >The futex() system call provides a method for waiting until a certain >condition becomes true. It is typically used as a blocking construct >in the context of shared-memory synchronization: The program implements >the majority of the synchronization in user space, and uses one of >operations of the system call when it is likely that it has to block >for a longer time until the condition becomes true. The program uses >another operation of the system call to wake anyone waiting for a par‐ >ticular condition. I've rephrased the next paragraph. How about adding this to follow? A futex is in essence a 32-bit user-space address. All futex operations and conditions are governed by this variable, from now on referred to as 'futex word'. As such, a futex is identified by the address in shared memory, which may or may not be shared between different processes. For virtual memory, the kernel will internally handle and resolve the later. This futex word, along with the value at its the memory location, are supplied to the futex() system call. Feel free to reword however you think is better. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: vfxxx: Add io-channel-cells property for ADC node
On Thu, Jul 16, 2015 at 08:43:19PM +0530, Sanchayan Maity wrote: > This commit adds io-channel-cells property to the ADC node. This > property is required in order for an IIO consumer driver to work. > Especially required for Colibri VF50, as the touchscreen driver > uses ADC channels with the ADC driver based on IIO framework. > > Signed-off-by: Sanchayan Maity Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Hi Moritz,
On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
> Signed-off-by: Moritz Fischer
> ---
> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
> 1 file changed, 13 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> new file mode 100644
> index 000..ac4499e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> @@ -0,0 +1,13 @@
> +Xilinx Zynq PL Reset Manager
> +
> +Required properties:
> +- compatible: "xlnx,zynq-reset-pl"
> +- syscon <>;
> +- #reset-cells: 1
> +
> +Example:
> + rstc: rstc@240 {
> + #reset-cells = <1>;
> + compatible = "xlnx,zynq-reset-pl";
> + syscon = <>;
> + };
I think you also have to add the outputs and make them part of the
binding. Otherwise you'd have to read the implementation to find
out what device should be hooked up to which output of the reset-controller.
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: dw_mmc: Fix coding style issues
This patch fixes the following issues reported by checkpatch.pl:
- use -EINVAL instead of -ENOSYS, to fix warning message:
"ENOSYS means 'invalid syscall nr' and nothing else"
- split lines whose length is greater than 80 characters
- avoid quoted string split across lines
- use min_t instead of min, to fix warning message:
"min() should probably be min_t(int, cnt, host->part_buf_count)"
Signed-off-by: Shawn Lin
---
drivers/mmc/host/dw_mmc.c | 85 ++-
1 file changed, 54 insertions(+), 31 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 40e9d8e..6aede38 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -235,8 +235,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
struct dw_mci *host = slot->host;
const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
u32 cmdr;
- cmd->error = -EINPROGRESS;
+ cmd->error = -EINPROGRESS;
cmdr = cmd->opcode;
if (cmd->opcode == MMC_STOP_TRANSMISSION ||
@@ -371,6 +371,7 @@ static void dw_mci_start_command(struct dw_mci *host,
cmd->arg, cmd_flags);
mci_writel(host, CMDARG, cmd->arg);
+ /* Make sure CMDARG is configured before CMD */
wmb();
dw_mci_wait_while_busy(host, cmd_flags);
@@ -380,6 +381,7 @@ static void dw_mci_start_command(struct dw_mci *host,
static inline void send_stop_abort(struct dw_mci *host, struct mmc_data *data)
{
struct mmc_command *stop = data->stop ? data->stop : >stop_abort;
+
dw_mci_start_command(host, stop, host->stop_cmdr);
}
@@ -463,6 +465,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
struct mmc_data *data,
unsigned int sg_len)
{
int i;
+
if (host->dma_64bit_address == 1) {
struct idmac_desc_64addr *desc = host->sg_cpu;
@@ -524,7 +527,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
struct mmc_data *data,
desc->des0 |= cpu_to_le32(IDMAC_DES0_LD);
}
- wmb();
+ wmb(); /* drain writebuffer */
}
static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
@@ -542,7 +545,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
temp |= SDMMC_CTRL_USE_IDMAC;
mci_writel(host, CTRL, temp);
- wmb();
+ wmb(); /* drain writebuffer */
/* Enable the IDMAC */
temp = mci_readl(host, BMOD);
@@ -589,7 +592,9 @@ static int dw_mci_idmac_init(struct dw_mci *host)
host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
/* Forward link the descriptor list */
- for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++,
p++) {
+ for (i = 0, p = host->sg_cpu;
+i < host->ring_size - 1;
+i++, p++) {
p->des3 = cpu_to_le32(host->sg_dma +
(sizeof(struct idmac_desc) * (i + 1)));
p->des1 = 0;
@@ -718,7 +723,7 @@ static void dw_mci_adjust_fifoth(struct dw_mci *host,
struct mmc_data *data)
u32 fifo_width = 1 << host->data_shift;
u32 blksz_depth = blksz / fifo_width, fifoth_val;
u32 msize = 0, rx_wmark = 1, tx_wmark, tx_wmark_invers;
- int idx = (sizeof(mszs) / sizeof(mszs[0])) - 1;
+ int idx = ARRAY_SIZE(mszs) - 1;
tx_wmark = (host->fifo_depth) / 2;
tx_wmark_invers = host->fifo_depth - tx_wmark;
@@ -843,6 +848,7 @@ static int dw_mci_submit_data_dma(struct dw_mci *host,
struct mmc_data *data)
static void dw_mci_submit_data(struct dw_mci *host, struct mmc_data *data)
{
unsigned long irqflags;
+ int flags = SG_MITER_ATOMIC;
u32 temp;
data->error = -EINPROGRESS;
@@ -859,7 +865,6 @@ static void dw_mci_submit_data(struct dw_mci *host, struct
mmc_data *data)
}
if (dw_mci_submit_data_dma(host, data)) {
- int flags = SG_MITER_ATOMIC;
if (host->data->flags & MMC_DATA_READ)
flags |= SG_MITER_TO_SG;
else
@@ -906,6 +911,7 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd,
u32 arg)
unsigned int cmd_status = 0;
mci_writel(host, CMDARG, arg);
+ /* Make sure CMDARG is configured before CMD */
wmb();
dw_mci_wait_while_busy(host, cmd);
mci_writel(host, CMD, SDMMC_CMD_START | cmd);
@@ -1019,6 +1025,7 @@ static void __dw_mci_start_request(struct dw_mci *host,
if (data) {
dw_mci_submit_data(host, data);
+ /* drain writebuffer */
wmb();
}
@@ -1384,14 +1391,15 @@ static int dw_mci_execute_tuning(struct mmc_host *mmc,
u32 opcode)
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host =
Re: [PATCH v3 1/7] dt/bindings: Add binding for the Raspberry Pi clock provider
On 07/24/2015 09:30 AM, Lee Jones wrote: > On Tue, 07 Jul 2015, Eric Anholt wrote: > >> Lee Jones writes: >> >>> If I were the Clock Maintainer, I would have probably missed this >>> patch. You _must_ intimate which subsystem you are submitting to. >>> The hardware clocks are not controllable by the ARM, so we have to make requests to the firmware to do so from the VPU side. This will let us replace fixed clocks in our DT with actual clock control (and correct frequency information). v2: Include the dt-bindings header in this commit instead of the next one. Make the clock indices match the firmware clock IDs. Rename the binding's compat string. Move the firmware phandle to be under a vendor-specific namespace. Signed-off-by: Eric Anholt --- .../clock/raspberrypi,bcm2835-firmware-clocks.txt | 25 ++ include/dt-bindings/clk/raspberrypi.h | 23 2 files changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt create mode 100644 include/dt-bindings/clk/raspberrypi.h diff --git a/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt new file mode 100644 index 000..0972602 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt @@ -0,0 +1,25 @@ +Raspberry Pi firmware clock provider. + +The Raspberry Pi architecture doesn't provide direct access to the +CLOCKMAN peripheral from the ARM side, so Linux has to make requests +to the VPU firmware to program them. + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible: Should be "raspberrypi,bcm2835-firmware-clocks" + +- #clock-cells: Shall have value <1>. The permitted clock-specifier +values can be found in +include/dt-bindings/clk/raspberrypi.h. + +- raspberrypi,firmware: Phandle to the firmware driver node. >>> >>> I think 'firmware' is a candidate for a generic phandle name. >> >> Stephen Warren asked in the last version that I change it from >> "firmware" to "raspberrypi,firmware", which made sense to me since we're >> not some core infrastructure using these references. Which should it >> be? > > We tend to use vendor specific bindings when others are unlikely to > make use of them. I would have thought that different vendors would > also make use of a generic 'firmware' phandle. The final decision > would probably be taken by the DT guys. I wouldn't expect there to be a need for a common firmware API for firmwares that don't implement some common standard (such as ACPI), since the operations supported by the firmwares will be firmware-specific, and hence not be amenable to generic clients (a client of the raspberrypi,firmware object may "translate" it to standard APIs such as clock, power domains, etc., while allowing other clients access to all the custom features). As such, I expect using a generic property name here isn't that useful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revised futex(2) man page for review
On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote: > SEE ALSO >get_robust_list(2), restart_syscall(2), futex(7) For pi futexes, I also suggest pthread_mutexattr_getprotocol(3), which is a common entry point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel low memory reserving failed
On Mon, Jul 27, 2015 at 5:52 PM, Baoquan He wrote: > On 07/22/15 at 04:47pm, Yinghai Lu wrote: > > Sorry for late reply. This problem is reported by customers. They usulay > don't like to make these things public. While for those systems with > good hard iommu support, it could also fail to initialize hw iommu and > then use swiotlb again, E.g in kdump kernel case. You can see in > intel_iommu_init() swiotlb is assigned to 0 only if intel iommu (namely vt-d) > is initialized successfully. There's possibility that hw iommu > initialization will fail, in this case kdump kernel will fail to boot > if no any low memory is given. So we can't make assumption that system > can boot always well without low memory. When we had crashkernel=,high working with auto low=40M. all system with crashkernel=,high worked. Now come one model (assume it is 16 socket system), and it could use crashkernel=,high crashkernel=256M,low. So it forces all auto_low be 256M. That is ugly. If the customer does not want to make the log public to make us to find good solution, why should we care about it ? why not just let them carry the "crashkernel=256M,low" all the way? Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function
'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
^
Caused by commit
e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")
from the mvebu tree interacting with commit
0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
from the tip tree.
I have applied the following merge fix patch for today:
From: Stephen Rothwell
Date: Tue, 28 Jul 2015 12:26:21 +1000
Subject: [PATCH] irqchip/gic: merge fix for "Remove redundant
gic_set_irqchip_flags"
Signed-off-by: Stephen Rothwell
---
arch/arm/mach-mvebu/board-v7.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a6d2b4d6701a..b5ef80f369e7 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -131,13 +131,6 @@ static int armada_375_external_abort_wa(unsigned long
addr, unsigned int fsr,
static void __init mvebu_init_irq(void)
{
- struct device_node *np;
-
- np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-gic");
- if (np)
- gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
- IRQCHIP_MASK_ON_SUSPEND);
- of_node_put(np);
irqchip_init();
mvebu_scu_enable();
coherency_init();
--
2.4.6
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LSM: LoadPin for module and firmware loading restrictions
On Mon, Jul 27, 2015 at 7:36 PM, James Morris wrote:
> On Mon, 27 Jul 2015, Kees Cook wrote:
>
>> On Sun, Jul 26, 2015 at 9:26 PM, James Morris wrote:
>> > On Thu, 23 Jul 2015, Kees Cook wrote:
>> >
>> >> +
>> >> +/*
>> >> + * Return an allocated string that has been escaped of special characters
>> >> + * and double quotes, making it safe to log in quotes.
>> >> + */
>> >> +static char *kstrdup_quotable(char *src)
>> >> +{
>> >
>> > Do you think these should go into a library?
>>
>> Possibly. There are some other areas of code that almost do the same
>> thing, but not exactly. Perhaps I'll first change Yama around to use
>> it, then send these again.
>
> Ok. Is this the same code being used in ChromeOS?
Essentially, yes. As the kernels used by Chrome OS don't have LSM
stacking, we merged a bunch of functionality into a single LSM.
LoadPin is a logical subset of that LSM.
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: ls1021a: audio: Add dts nodes for audio on LS1021A
On Wed, Jul 15, 2015 at 04:02:46PM +0800, Alison Wang wrote: > This patch adds dts nodes for audio on LS1021A. > > Signed-off-by: Alison Wang > Signed-off-by: Shawn Guo Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LSM: LoadPin for module and firmware loading restrictions
On Mon, 27 Jul 2015, Kees Cook wrote:
> On Sun, Jul 26, 2015 at 9:26 PM, James Morris wrote:
> > On Thu, 23 Jul 2015, Kees Cook wrote:
> >
> >> +
> >> +/*
> >> + * Return an allocated string that has been escaped of special characters
> >> + * and double quotes, making it safe to log in quotes.
> >> + */
> >> +static char *kstrdup_quotable(char *src)
> >> +{
> >
> > Do you think these should go into a library?
>
> Possibly. There are some other areas of code that almost do the same
> thing, but not exactly. Perhaps I'll first change Yama around to use
> it, then send these again.
Ok. Is this the same code being used in ChromeOS?
--
James Morris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation Framework
Hi Benjamin,
It looks like this framework only allows user space client to talk with trust
application, it there a plan to provide kernel side APIs for kernel space
client?
Please correct me if my understanding is wrong.
Thanks
Xiaoquan
-Original Message-
From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf
Of Benjamin Gaignard
Sent: Monday, July 27, 2015 6:12 PM
To: linux-me...@vger.kernel.org; Linux Kernel Mailing List;
dri-de...@lists.freedesktop.org; Hans Verkuil; Laurent Pinchart; Daniel Vetter;
Rob Clark; Thierry Reding; Sumit Semwal; Tom Cooksey; Daniel Stone
Cc: Linaro MM SIG Mailman List
Subject: Re: [Linaro-mm-sig] [PATCH v3 0/2] RFC: Secure Memory Allocation
Framework
Hi all,
This thread doesn't get any feedback...
What would be great is to know if this framework proposal fir with
your platform needs.
Maybe I haven't copy the good mailing lists so if you think there is
better ones do not hesitate to forward.
Regards,
Benjamin
2015-07-10 14:28 GMT+02:00 Benjamin Gaignard :
> version 3 changes:
> - Remove ioctl for allocator selection instead provide the name of
>the targeted allocator with allocation request.
>Selecting allocator from userland isn't the prefered way of working
>but is needed when the first user of the buffer is a software component.
> - Fix issues in case of error while creating smaf handle.
> - Fix module license.
> - Update libsmaf and tests to care of the SMAF API evolution
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>
> version 2 changes:
> - Add one ioctl to allow allocator selection from userspace.
>This is required for the uses case where the first user of
>the buffer is a software IP which can't perform dma_buf attachement.
> - Add name and ranking to allocator structure to be able to sort them.
> - Create a tiny library to test SMAF:
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> - Fix one issue when try to secure buffer without secure module registered
>
> The outcome of the previous RFC about how do secure data path was the need
> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>
> SMAF goal is to provide a framework that allow allocating and securing
> memory by using dma_buf. Each platform have it own way to perform those two
> features so SMAF design allow to register helper modules to perform them.
>
> To be sure to select the best allocation method for devices SMAF implement
> deferred allocation mechanism: memory allocation is only done when the first
> device effectively required it.
> Allocator modules have to implement a match() to let SMAF know if they are
> compatibles with devices needs.
> This patch set provide an example of allocator module which use
> dma_{alloc/free/mmap}_attrs() and check if at least one device have
> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
> a better name could be found for this file.
>
> Secure modules are responsibles of granting and revoking devices access rights
> on the memory. Secure module is also called to check if CPU map memory into
> kernel and user address spaces.
> An example of secure module implementation can be found here:
> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
> This code isn't yet part of the patch set because it depends on generic TEE
> which is still under discussion (https://lwn.net/Articles/644646/)
>
> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
> constraint aware allocator.
>
> Benjamin Gaignard (2):
> create SMAF module
> SMAF: add CMA allocator
>
> drivers/Kconfig| 2 +
> drivers/Makefile | 1 +
> drivers/smaf/Kconfig | 11 +
> drivers/smaf/Makefile | 2 +
> drivers/smaf/smaf-cma.c| 200 +++
> drivers/smaf/smaf-core.c | 735
> +
> include/linux/smaf-allocator.h | 54 +++
> include/linux/smaf-secure.h| 62
> include/uapi/linux/smaf.h | 52 +++
> 9 files changed, 1119 insertions(+)
> create mode 100644 drivers/smaf/Kconfig
> create mode 100644 drivers/smaf/Makefile
> create mode 100644 drivers/smaf/smaf-cma.c
> create mode 100644 drivers/smaf/smaf-core.c
> create mode 100644 include/linux/smaf-allocator.h
> create mode 100644 include/linux/smaf-secure.h
> create mode 100644 include/uapi/linux/smaf.h
>
> --
> 1.9.1
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
Cc'ing few people (whom I cc'd last time as well :)).
On 27-07-15, 16:20, Lee Jones wrote:
> These OPPs are used in ST's CPUFreq implementation.
>
> Signed-off-by: Lee Jones
> ---
>
> Changelog:
> - None, new patch
>
> Documentation/devicetree/bindings/power/opp-st.txt | 76
> ++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
>
> diff --git a/Documentation/devicetree/bindings/power/opp-st.txt
> b/Documentation/devicetree/bindings/power/opp-st.txt
> new file mode 100644
> index 000..6eb2a91
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/opp-st.txt
> @@ -0,0 +1,76 @@
> +STMicroelectronics OPP (Operating Performance Points) Bindings
> +--
> +
> +Frequency Scaling only
> +--
> +
> +Located in CPU's node:
> +
> +- operating-points : [See: ./opp.txt]
> +
> +Example [safe]
> +--
> +
> +cpus {
> + cpu@0 {
> + /* kHz uV */
> + operating-points = <150 0
> + 120 0
> + 80 0
> + 50 0>;
> + };
> +};
> +
> +Dynamic Voltage and Frequency Scaling (DVFS)
> +
> +
> +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
> +
> +- compatible : Should be "operating-points-v2-sti"
> +- opp{1..N} : Each 'oppX' subnode will contain the following
> properties:
Or should we mention:
- opp{1..N} : Each 'oppX' subnode shall contain below properties,
over what ./opp.txt defines:
?
> + - opp-hz: CPU frequency [Hz] for this OPP [See: ./opp.txt]
> + - st,avs: List of available voltages [uV] indexed by process
> code
> + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL]
> + - st,substrate : Substrate version this OPP is suitable for
> [0xFF means ALL]
> +- st,syscfg : Phandle to Major number register
> + First cell: offset to major number
> +- st,syscfg-eng : Phandle to Minor number and Pcode registers
> + First cell: offset to process code
> + Second cell: offset to minor number
> +
> +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not
> attempt to
> + artificially synthesise the opp{1..N} nodes or any of their
> descendants.
> + They are very platform specific and may damage the hardware if created
> + incorrectly.
> +
> +Example [unsafe]
> +
> +
> +cpus {
> + cpu@0 {
> + operating-points-v2 = <_opp_list>;
> + };
> +};
> +
> +/* */
> +/* # WARNING: Do not attempt to copy/replicate this node, # */
> +/* # it is only to be supplied by the bootloader !!! # */
> +/* */
> +cpu0-opp-list {
> + compatible = "operating-points-v2-sti";
> + st,syscfg = < [major_offset]>;
> + st,syscfg-eng = <_eng [pcode_offset] [minor_offset]>;
> +
> + opp0 {
> + opp-hz = <12>;
> + st,avs = <1110 1150 1100 1080 1040 1020 980 930>;
> + st,substrate= <0xff>;
> + st,cuts = <0xff>;
> + };
> + opp1 {
> + opp-hz = <15>;
> + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>;
> + st,substrate= <0xff>;
> + st,cuts = <0x2>;
> + };
> +};
I don't see more problems here, unless we can move some of this to the
generic bindings.
@Rob/Stephen: Please respond before it is late :)
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On 27-07-15, 16:20, Lee Jones wrote:
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
>
> Changelog:
> - Using OPP-v2
> - Moved (and linked) a bunch of documentation to ../power/
>
> .../devicetree/bindings/cpufreq/cpufreq-st.txt | 40
> ++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> new file mode 100644
> index 000..79add9d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> @@ -0,0 +1,40 @@
> +Binding for ST's CPUFreq driver
> +===
> +
> +Frequency Scaling only
> +--
> +
> +Located in CPU's node:
> +
> +- operating-points : [See: ../power/opp.txt]
> +
> +Example [safe]
> +--
> +
> +cpus {
> + cpu@0 {
> + /* kHz uV */
> + operating-points = <150 0
> + 120 0
> + 80 0
> + 50 0>;
> + };
> +};
> +
> +Dynamic Voltage and Frequency Scaling (DVFS)
> +
> +
> +Located in CPU's node:
> +
> +- operating-points-v2-sti: [See ../power/opp-st.txt]
> +
> +Example [unsafe]
> +
> +
> +cpus {
> + cpu@0 {
> + operating-points-v2 = <[OPP list phandle]>;
> + };
> +};
> +
> +For an example of an OPP list, see ../power/opp-st.txt.
I don't think you need this file/patch at all.. It is almost blank and
doesn't define a binding. And so there is no need to specify this at
all. Just an OPP binding file is enough.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Update][PATCH 7/7] cpufreq: Separate CPU device registration from CPU online
On 27-07-15, 23:55, Rafael J. Wysocki wrote: > +static void cpufreq_online(unsigned int cpu) As I said in the earlier message, I need the return value of this to be used for add_dev() callback. Which is required to retry probing the device if it wasn't ready on a earlier call, i.e. it returns -EPROBE_DEFER. My other patch already fixes the subsys layer for this. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option
On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
wrote:
> On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
>>
>> On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
>> wrote:
>>>
>>> On 07/25/2015 01:36 AM, Andy Lutomirski wrote:
Here's v3. It fixes the "dazed and confused" issue, I hope. It's also
probably a good general attack surface reduction, and it replaces some
scary code with IMO less scary code.
Also, servers and embedded systems should probably turn off modify_ldt.
This makes that possible.
Xen people, can you take a look at this?
Willy and Kees: I left the config option alone. The -tiny people will
like it, and we can always add a sysctl of some sort later.
Changes from v3:
- Hopefully fixed Xen.
>>>
>>>
>>> 32b-on-32b fails in the same manner. (but non-zero LDT is taken care of)
>>>
- Fixed 32-bit test case on 32-bit native kernel.
>>>
>>>
>>> I am not sure I see what changed.
>>
>> I misplaced the fix in the wrong git commit, so I failed to sent it.
>> Oops.
>>
>> I just sent v4.1 of patch 3. Can you try that?
>
>
>
> I am hitting BUG() in Xen code (returning from a hypercall) when freeing LDT
> in destroy_context(). Interestingly though when I run the test in the
> debugger I get SIGILL (just like before) but no BUG().
>
> Let me get back to you on that later today.
>
>
After forward-porting my virtio patches, I got this thing to run on
Xen. After several tries, I got:
[ 53.985707] [ cut here ]
[ 53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
[ 53.986677] invalid opcode: [#1] SMP
[ 53.986677] Modules linked in:
[ 53.986677] CPU: 0 PID: 1400 Comm: bash Not tainted 4.2.0-rc4+ #4
[ 53.986677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
04/01/2014
[ 53.986677] task: c2376180 ti: c0874000 task.ti: c0874000
[ 53.986677] EIP: 0061:[] EFLAGS: 00010282 CPU: 0
[ 53.986677] EIP is at set_aliased_prot+0xb2/0xc0
[ 53.986677] EAX: ffea EBX: cc3d1000 ECX: 0672e063 EDX: 8000
[ 53.986677] ESI: EDI: 8000 EBP: c0875e94 ESP: c0875e74
[ 53.986677] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[ 53.986677] CR0: 80050033 CR2: b77404d4 CR3: 020b6000 CR4: 00042660
[ 53.986677] Stack:
[ 53.986677] 8000 0672e063 21c0 cc3d1000 0001 cc3d2000
0b4a 0200
[ 53.986677] c0875ea8 c105312d c2317940 c2373a80 c0875eb4
c1062310 c01861c0
[ 53.986677] c0875ec0 c1062735 c01861c0 c0875ed4 c10a764e c7007a00
c2373a80
[ 53.986677] Call Trace:
[ 53.986677] [] xen_free_ldt+0x2d/0x40
[ 53.986677] [] free_ldt_struct.part.1+0x10/0x40
[ 53.986677] [] destroy_context+0x25/0x40
[ 53.986677] [] __mmdrop+0x1e/0xc0
[ 53.986677] [] finish_task_switch+0xd8/0x1a0
[ 53.986677] [] __schedule+0x316/0x950
[ 53.986677] [] schedule+0x26/0x70
[ 53.986677] [] do_wait+0x1b3/0x200
[ 53.986677] [] SyS_waitpid+0x67/0xd0
[ 53.986677] [] ? task_stopped_code+0x50/0x50
[ 53.986677] [] syscall_call+0x7/0x7
[ 53.986677] Code: e8 c1 e3 0c 81 eb 00 00 00 40 39 5d ec 74 11 8b
4d e4 8b 55 e0 31 f6 e8 dd e0 fa ff 85 c0 75 0d 83 c4 14 5b 5e 5f 5d
c3 90 0f 0b <0f> 0b 0f 0b 8d 76 00 8d bc 27 00 00 00 00 85 d2 74 31 55
89 e5
[ 53.986677] EIP: [] set_aliased_prot+0xb2/0xc0 SS:ESP 0069:c0875e74
[ 54.010069] ---[ end trace 89ac35b29c1c59bb ]---
Is that the error you're seeing?
If I change xen_free_ldt to:
static void xen_free_ldt(struct desc_struct *ldt, unsigned entries)
{
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
vm_unmap_aliases();
xen_mc_flush();
for(i = 0; i < entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL);
}
then it works. I don't know why this makes a difference.
(xen_mc_flush makes a little bit of sense to me. vm_unmap_aliases
doesn't.)
It's *possible* that there's some but in my code that causes a CPU to
retain a reference to a stale LDT, but I don't see it. Hmm. Is it
possible that, when a process exits, we kill the mm without
synchronously unlazying it everywhere else? Seems a bit hard to
imagine to me -- I don't see why this wouldn't blow up when the pgt
went away.
My best guess is that there's a silly race in which one CPU frees and
LDT before the other CPU flushes its hypercalls. But I don't really
believe this, because I got this trace:
[ 14.257546] Free LDT cb912000: CPU0 cb923000 CPU1 cb923000
[OK]All 5 iterations succeeded
root@(none):/# [ 15.824723] Free LDT cb923000: CPU0 (null) CPU1 (null)
[ 15.827404] [ cut here ]
[ 15.828349] kernel BUG at arch/x86/xen/enlighten.c:497!
[ 15.828349] invalid opcode: [#1] SMP
with this patch applied:
@@ -537,7 +542,9 @@ static void xen_set_ldt(const void *addr, unsigned entries)
MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
-
linux-next: manual merge of the tip tree with the arm-soc tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm/mach-shmobile/intc-sh73a0.c
between commit:
30f8925a57d8 ("ARM: shmobile: Remove legacy board code for KZM-A9-GT")
from the arm-soc tree and commit:
0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
from the tip tree.
I fixed it up (I just removed the file) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 7/25/15 3:04 AM, He Kuang wrote: I noticed that for 64-bit elf format, the reloc sections have 'Addend' in the entry, but there's no 'Addend' info in bpf elf file(64bit). I think there must be something wrong in the process of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the AT_name now, DW_AT_LOCATION still missed and need your help. looks like objdump/llvm-dwarfdump can only read known EM, but that that shouldn't be the problem for your dwarf reader right? It should be able to recognize id-s of ELF::R_X86_64_* relo used right? As far as AT_location for testprog.c it seems there is no info for local variables because they were optimized away. With -O0 I see AT_location being emitted. Also line number info seems to be good in both cases. But in our case, we don't need this anyway, no? we need to see the types of structs mainly or you have some other use cases? I think line number info would be great to correlate the error reported by verifier into specific line in C. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] net: mdio-octeon: Fix octeon_mdiobus_probe function for return values
From: Radha Mohan Chintakuntla
This patch fixes a possible crash in the octeon_mdiobus_probe function
if the return values are not handled properly.
Signed-off-by: Radha Mohan Chintakuntla
Signed-off-by: Tomasz Nowicki
---
drivers/net/phy/mdio-octeon.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/mdio-octeon.c b/drivers/net/phy/mdio-octeon.c
index 507aade..428ae75 100644
--- a/drivers/net/phy/mdio-octeon.c
+++ b/drivers/net/phy/mdio-octeon.c
@@ -277,24 +277,28 @@ static int octeon_mdiobus_probe(struct platform_device
*pdev)
return -ENOMEM;
res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
if (res_mem == NULL) {
dev_err(>dev, "found no memory resource\n");
- err = -ENXIO;
- goto fail;
+ return -ENXIO;
}
+
bus->mdio_phys = res_mem->start;
bus->regsize = resource_size(res_mem);
+
if (!devm_request_mem_region(>dev, bus->mdio_phys, bus->regsize,
res_mem->name)) {
dev_err(>dev, "request_mem_region failed\n");
- goto fail;
+ return -ENXIO;
}
+
bus->register_base =
(u64)devm_ioremap(>dev, bus->mdio_phys, bus->regsize);
+ if (!bus->register_base) {
+ dev_err(>dev, "dev_ioremap failed\n");
+ return -ENOMEM;
+ }
bus->mii_bus = mdiobus_alloc();
-
if (!bus->mii_bus)
goto fail;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] net: thunderx: Select CONFIG_MDIO_OCTEON for ThunderX NIC
From: Radha Mohan Chintakuntla The CONFIG_MDIO_OCTEON is required so that the ThunderX NIC driver can talk to the PHY drivers. Signed-off-by: Radha Mohan Chintakuntla --- drivers/net/ethernet/cavium/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig index c4d6bbe..3584420 100644 --- a/drivers/net/ethernet/cavium/Kconfig +++ b/drivers/net/ethernet/cavium/Kconfig @@ -37,6 +37,8 @@ configTHUNDER_NIC_BGX tristate "Thunder MAC interface driver (BGX)" depends on 64BIT default ARCH_THUNDER + select PHYLIB + select MDIO_OCTEON ---help--- This driver supports programming and controlling of MAC interface from NIC physical function driver. -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V2 PATCH 2/3] kexec: Fix race between panic() and crash_kexec() called directly
Hi,
(2015/07/27 23:55), Michal Hocko wrote:
> On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> [...]
>> @@ -1472,6 +1472,18 @@ void __weak crash_unmap_reserved_pages(void)
>>
>> void crash_kexec(struct pt_regs *regs)
>> {
>> +int old_cpu, this_cpu;
>> +
>> +/*
>> + * `old_cpu == -1' means we are the first comer and crash_kexec()
>> + * was called without entering panic().
>> + * `old_cpu == this_cpu' means crash_kexec() was called from panic().
>> + */
>> +this_cpu = raw_smp_processor_id();
>> +old_cpu = atomic_cmpxchg(_cpu, -1, this_cpu);
>> +if (old_cpu != -1 && old_cpu != this_cpu)
>> +return;
>> +
>> /* Take the kexec_mutex here to prevent sys_kexec_load
>> * running on one cpu from replacing the crash kernel
>> * we are using after a panic on a different cpu.
>> @@ -1491,6 +1503,14 @@ void crash_kexec(struct pt_regs *regs)
>> }
>> mutex_unlock(_mutex);
>> }
>> +
>> +/*
>> + * If we came here from panic(), we have to keep panicking_cpu
>> + * to prevent other cpus from entering panic(). Otherwise,
>> + * resetting it so that other cpus can enter panic()/crash_kexec().
>> + */
>> +if (old_cpu == this_cpu)
>> +atomic_set(_cpu, -1);
>
> This do the opposite what the comment says, wouldn't it? You should
> check old_cpu == -1.
Sorry, you are right. I performed same tests as for the
previous patch set, but I missed the test case for this
new logic.
> Also atomic_set doesn't imply memory barriers which
> might be a problem.
OK, I'll use atomic_xchg().
Regards,
--
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the renesas tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm/mach-shmobile/setup-r8a7779.c
between commit:
3fecc170e5b7 ("ARM: shmobile: r8a7779: Remove legacy SoC code")
from the renesas tree and commit:
0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-shmobile/setup-r8a7779.c
index c18d85a96c67,aea5cff9495d..
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@@ -60,12 -80,651 +60,10 @@@ static void __init r8a7779_map_io(void
#define INT2NTSR0 IOMEM(0xfe700060)
#define INT2NTSR1 IOMEM(0xfe700064)
-static struct renesas_intc_irqpin_config irqpin0_platform_data __initdata = {
- .irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
- .sense_bitfield_width = 2,
-};
-
-static struct resource irqpin0_resources[] __initdata = {
- DEFINE_RES_MEM(0xfe78001c, 4), /* ICR1 */
- DEFINE_RES_MEM(0xfe780010, 4), /* INTPRI */
- DEFINE_RES_MEM(0xfe780024, 4), /* INTREQ */
- DEFINE_RES_MEM(0xfe780044, 4), /* INTMSK0 */
- DEFINE_RES_MEM(0xfe780064, 4), /* INTMSKCLR0 */
- DEFINE_RES_IRQ(gic_spi(27)), /* IRQ0 */
- DEFINE_RES_IRQ(gic_spi(28)), /* IRQ1 */
- DEFINE_RES_IRQ(gic_spi(29)), /* IRQ2 */
- DEFINE_RES_IRQ(gic_spi(30)), /* IRQ3 */
-};
-
-void __init r8a7779_init_irq_extpin_dt(int irlm)
-{
- void __iomem *icr0 = ioremap_nocache(0xfe78, PAGE_SIZE);
- u32 tmp;
-
- if (!icr0) {
- pr_warn("r8a7779: unable to setup external irq pin mode\n");
- return;
- }
-
- tmp = ioread32(icr0);
- if (irlm)
- tmp |= 1 << 23; /* IRQ0 -> IRQ3 as individual pins */
- else
- tmp &= ~(1 << 23); /* IRL mode - not supported */
- tmp |= (1 << 21); /* LVLMODE = 1 */
- iowrite32(tmp, icr0);
- iounmap(icr0);
-}
-
-void __init r8a7779_init_irq_extpin(int irlm)
-{
- r8a7779_init_irq_extpin_dt(irlm);
- if (irlm)
- platform_device_register_resndata(
- NULL, "renesas_intc_irqpin", -1,
- irqpin0_resources, ARRAY_SIZE(irqpin0_resources),
- _platform_data, sizeof(irqpin0_platform_data));
-}
-
-/* PFC/GPIO */
-static struct resource r8a7779_pfc_resources[] = {
- DEFINE_RES_MEM(0xfffc, 0x023c),
-};
-
-static struct platform_device r8a7779_pfc_device = {
- .name = "pfc-r8a7779",
- .id = -1,
- .resource = r8a7779_pfc_resources,
- .num_resources = ARRAY_SIZE(r8a7779_pfc_resources),
-};
-
-#define R8A7779_GPIO(idx, npins) \
-static struct resource r8a7779_gpio##idx##_resources[] = {\
- DEFINE_RES_MEM(0xffc4 + (0x1000 * (idx)), 0x002c), \
- DEFINE_RES_IRQ(gic_iid(0xad + (idx))), \
-};\
- \
-static struct gpio_rcar_config r8a7779_gpio##idx##_platform_data = { \
- .gpio_base = 32 * (idx), \
- .irq_base = 0,\
- .number_of_pins = npins,\
- .pctl_name = "pfc-r8a7779",\
-};\
- \
-static struct platform_device r8a7779_gpio##idx##_device = { \
- .name = "gpio_rcar", \
- .id = idx, \
- .resource = r8a7779_gpio##idx##_resources,\
- .num_resources = ARRAY_SIZE(r8a7779_gpio##idx##_resources),\
- .dev= { \
- .platform_data = _gpio##idx##_platform_data, \
- }, \
-}
-
-R8A7779_GPIO(0, 32);
-R8A7779_GPIO(1, 32);
-R8A7779_GPIO(2, 32);
-R8A7779_GPIO(3, 32);
-R8A7779_GPIO(4, 32);
-R8A7779_GPIO(5, 32);
-R8A7779_GPIO(6, 9);
-
-static struct platform_device *r8a7779_pinctrl_devices[] __initdata = {
- _pfc_device,
- _gpio0_device,
- _gpio1_device,
- _gpio2_device,
- _gpio3_device,
- _gpio4_device,
- _gpio5_device,
- _gpio6_device,
-};
-
-void __init r8a7779_pinmux_init(void)
-{
- platform_add_devices(r8a7779_pinctrl_devices,
- ARRAY_SIZE(r8a7779_pinctrl_devices));
-}
-
-/* SCIF */
-#define R8A7779_SCIF(index, baseaddr,
[PATCH 1/3] net: mdio-octeon: Modify driver to work on both ThunderX and Octeon
From: Radha Mohan Chintakuntla
This patch modifies the mdio-octeon driver to work on both ThunderX and
Octeon SoCs from Cavium Inc.
Signed-off-by: Sunil Goutham
Signed-off-by: Radha Mohan Chintakuntla
Signed-off-by: David Daney
---
drivers/net/phy/Kconfig |9 ++-
drivers/net/phy/mdio-octeon.c | 122 +++-
2 files changed, 111 insertions(+), 20 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index cf18940..0d6af19 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -145,13 +145,14 @@ config MDIO_GPIO
will be called mdio-gpio.
config MDIO_OCTEON
- tristate "Support for MDIO buses on Octeon SOCs"
- depends on CAVIUM_OCTEON_SOC
+ tristate "Support for MDIO buses on Octeon and ThunderX SOCs"
+ depends on 64BIT
default y
help
- This module provides a driver for the Octeon MDIO busses.
- It is required by the Octeon Ethernet device drivers.
+ This module provides a driver for the Octeon and ThunderX MDIO
+ busses. It is required by the Octeon and ThunderX ethernet device
+ drivers.
If in doubt, say Y.
diff --git a/drivers/net/phy/mdio-octeon.c b/drivers/net/phy/mdio-octeon.c
index c838ad6..507aade 100644
--- a/drivers/net/phy/mdio-octeon.c
+++ b/drivers/net/phy/mdio-octeon.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,11 +15,12 @@
#include
#include
+#ifdef CONFIG_CAVIUM_OCTEON_SOC
#include
-#include
+#endif
-#define DRV_VERSION "1.0"
-#define DRV_DESCRIPTION "Cavium Networks Octeon SMI/MDIO driver"
+#define DRV_VERSION "1.1"
+#define DRV_DESCRIPTION "Cavium Networks Octeon/ThunderX SMI/MDIO driver"
#define SMI_CMD0x0
#define SMI_WR_DAT 0x8
@@ -26,6 +28,79 @@
#define SMI_CLK0x18
#define SMI_EN 0x20
+#ifdef __BIG_ENDIAN_BITFIELD
+#define OCT_MDIO_BITFIELD_FIELD(field, more) \
+ field; \
+ more
+
+#else
+#define OCT_MDIO_BITFIELD_FIELD(field, more) \
+ more\
+ field;
+
+#endif
+
+union cvmx_smix_clk {
+ uint64_t u64;
+ struct cvmx_smix_clk_s {
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_25_63:39,
+ OCT_MDIO_BITFIELD_FIELD(u64 mode:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_21_23:3,
+ OCT_MDIO_BITFIELD_FIELD(u64 sample_hi:5,
+ OCT_MDIO_BITFIELD_FIELD(u64 sample_mode:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_14_14:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 clk_idle:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 preamble:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 sample:4,
+ OCT_MDIO_BITFIELD_FIELD(u64 phase:8,
+ ;))
+ } s;
+};
+
+union cvmx_smix_cmd {
+ uint64_t u64;
+ struct cvmx_smix_cmd_s {
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_18_63:46,
+ OCT_MDIO_BITFIELD_FIELD(u64 phy_op:2,
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_13_15:3,
+ OCT_MDIO_BITFIELD_FIELD(u64 phy_adr:5,
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_5_7:3,
+ OCT_MDIO_BITFIELD_FIELD(u64 reg_adr:5,
+ ;))
+ } s;
+};
+
+union cvmx_smix_en {
+ uint64_t u64;
+ struct cvmx_smix_en_s {
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_1_63:63,
+ OCT_MDIO_BITFIELD_FIELD(u64 en:1,
+ ;))
+ } s;
+};
+
+union cvmx_smix_rd_dat {
+ uint64_t u64;
+ struct cvmx_smix_rd_dat_s {
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_18_63:46,
+ OCT_MDIO_BITFIELD_FIELD(u64 pending:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 val:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 dat:16,
+ ;
+ } s;
+};
+
+union cvmx_smix_wr_dat {
+ uint64_t u64;
+ struct cvmx_smix_wr_dat_s {
+ OCT_MDIO_BITFIELD_FIELD(u64 reserved_18_63:46,
+ OCT_MDIO_BITFIELD_FIELD(u64 pending:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 val:1,
+ OCT_MDIO_BITFIELD_FIELD(u64 dat:16,
+ ;
+ } s;
+};
+
enum octeon_mdiobus_mode {
UNINIT = 0,
C22,
@@ -41,6 +116,21 @@ struct octeon_mdiobus {
int phy_irq[PHY_MAX_ADDR];
};
+#ifdef CONFIG_CAVIUM_OCTEON_SOC
+static void oct_mdio_writeq(u64 val, u64 addr)
+{
+ cvmx_write_csr(addr, val);
+}
+
+static u64 oct_mdio_readq(u64 addr)
+{
+ return cvmx_read_csr(addr);
+}
+#else
+#define oct_mdio_writeq(val, addr) writeq_relaxed(val, (void *)addr)
+#define oct_mdio_readq(addr) readq_relaxed((void *)addr)
+#endif
+
static void octeon_mdiobus_set_mode(struct octeon_mdiobus *p,
enum octeon_mdiobus_mode m)
{
@@ -49,10 +139,10 @@ static void octeon_mdiobus_set_mode(struct octeon_mdiobus
*p,
if (m == p->mode)
return;
- smi_clk.u64 = cvmx_read_csr(p->register_base + SMI_CLK);
+ smi_clk.u64 =
