* [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Michael S. Tsirkin @ 2016-12-15 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481778865-27667-1-git-send-email-mst@redhat.com>
__bitwise__ used to mean "yes, please enable sparse checks
unconditionally", but now that we dropped __CHECK_ENDIAN__
__bitwise is exactly the same.
There aren't many users, replace it by __bitwise everywhere.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
drivers/md/dm-cache-block-types.h | 6 +++---
drivers/net/ethernet/sun/sunhme.h | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
include/linux/mmzone.h | 2 +-
include/linux/serial_core.h | 4 ++--
include/linux/types.h | 4 ++--
include/scsi/iscsi_proto.h | 2 +-
include/target/target_core_base.h | 2 +-
include/uapi/linux/virtio_types.h | 6 +++---
net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
net/mac80211/ieee80211_i.h | 4 ++--
12 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
index 21391fa..e55d1f5 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
@@ -26,7 +26,7 @@
#include <linux/types.h>
-typedef unsigned int __bitwise__ samsung_gpio_pull_t;
+typedef unsigned int __bitwise samsung_gpio_pull_t;
/* forward declaration if gpio-core.h hasn't been included */
struct samsung_gpio_chip;
diff --git a/drivers/md/dm-cache-block-types.h b/drivers/md/dm-cache-block-types.h
index bed4ad4..389c9e8 100644
--- a/drivers/md/dm-cache-block-types.h
+++ b/drivers/md/dm-cache-block-types.h
@@ -17,9 +17,9 @@
* discard bitset.
*/
-typedef dm_block_t __bitwise__ dm_oblock_t;
-typedef uint32_t __bitwise__ dm_cblock_t;
-typedef dm_block_t __bitwise__ dm_dblock_t;
+typedef dm_block_t __bitwise dm_oblock_t;
+typedef uint32_t __bitwise dm_cblock_t;
+typedef dm_block_t __bitwise dm_dblock_t;
static inline dm_oblock_t to_oblock(dm_block_t b)
{
diff --git a/drivers/net/ethernet/sun/sunhme.h b/drivers/net/ethernet/sun/sunhme.h
index f430765..4a8d5b1 100644
--- a/drivers/net/ethernet/sun/sunhme.h
+++ b/drivers/net/ethernet/sun/sunhme.h
@@ -302,7 +302,7 @@
* Always write the address first before setting the ownership
* bits to avoid races with the hardware scanning the ring.
*/
-typedef u32 __bitwise__ hme32;
+typedef u32 __bitwise hme32;
struct happy_meal_rxd {
hme32 rx_flags;
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
index 1ad0ec1..84813b5 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
@@ -228,7 +228,7 @@ enum iwl_ucode_tlv_flag {
IWL_UCODE_TLV_FLAGS_BCAST_FILTERING = BIT(29),
};
-typedef unsigned int __bitwise__ iwl_ucode_tlv_api_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
/**
* enum iwl_ucode_tlv_api - ucode api
@@ -258,7 +258,7 @@ enum iwl_ucode_tlv_api {
#endif
};
-typedef unsigned int __bitwise__ iwl_ucode_tlv_capa_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_capa_t;
/**
* enum iwl_ucode_tlv_capa - ucode capabilities
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0f088f3..36d9896 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -246,7 +246,7 @@ struct lruvec {
#define ISOLATE_UNEVICTABLE ((__force isolate_mode_t)0x8)
/* LRU Isolation modes. */
-typedef unsigned __bitwise__ isolate_mode_t;
+typedef unsigned __bitwise isolate_mode_t;
enum zone_watermarks {
WMARK_MIN,
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5d49488..5def8e8 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -111,8 +111,8 @@ struct uart_icount {
__u32 buf_overrun;
};
-typedef unsigned int __bitwise__ upf_t;
-typedef unsigned int __bitwise__ upstat_t;
+typedef unsigned int __bitwise upf_t;
+typedef unsigned int __bitwise upstat_t;
struct uart_port {
spinlock_t lock; /* port lock */
diff --git a/include/linux/types.h b/include/linux/types.h
index baf7183..d501ad3 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -154,8 +154,8 @@ typedef u64 dma_addr_t;
typedef u32 dma_addr_t;
#endif
-typedef unsigned __bitwise__ gfp_t;
-typedef unsigned __bitwise__ fmode_t;
+typedef unsigned __bitwise gfp_t;
+typedef unsigned __bitwise fmode_t;
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
index c1260d8..df156f1 100644
--- a/include/scsi/iscsi_proto.h
+++ b/include/scsi/iscsi_proto.h
@@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
#define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
/* initiator tags; opaque for target */
-typedef uint32_t __bitwise__ itt_t;
+typedef uint32_t __bitwise itt_t;
/* below makes sense only for initiator that created this tag */
#define build_itt(itt, age) ((__force itt_t)\
((itt) | ((age) << ISCSI_AGE_SHIFT)))
diff --git a/include/target/target_core_base.h b/include/target/target_core_base.h
index c211900..0055828 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -149,7 +149,7 @@ enum se_cmd_flags_table {
* Used by transport_send_check_condition_and_sense()
* to signal which ASC/ASCQ sense payload should be built.
*/
-typedef unsigned __bitwise__ sense_reason_t;
+typedef unsigned __bitwise sense_reason_t;
enum tcm_sense_reason_table {
#define R(x) (__force sense_reason_t )(x)
diff --git a/include/uapi/linux/virtio_types.h b/include/uapi/linux/virtio_types.h
index e845e8c..55c3b73 100644
--- a/include/uapi/linux/virtio_types.h
+++ b/include/uapi/linux/virtio_types.h
@@ -39,8 +39,8 @@
* - __le{16,32,64} for standard-compliant virtio devices
*/
-typedef __u16 __bitwise__ __virtio16;
-typedef __u32 __bitwise__ __virtio32;
-typedef __u64 __bitwise__ __virtio64;
+typedef __u16 __bitwise __virtio16;
+typedef __u32 __bitwise __virtio32;
+typedef __u64 __bitwise __virtio64;
#endif /* _UAPI_LINUX_VIRTIO_TYPES_H */
diff --git a/net/ieee802154/6lowpan/6lowpan_i.h b/net/ieee802154/6lowpan/6lowpan_i.h
index 5ac7789..ac7c96b 100644
--- a/net/ieee802154/6lowpan/6lowpan_i.h
+++ b/net/ieee802154/6lowpan/6lowpan_i.h
@@ -7,7 +7,7 @@
#include <net/inet_frag.h>
#include <net/6lowpan.h>
-typedef unsigned __bitwise__ lowpan_rx_result;
+typedef unsigned __bitwise lowpan_rx_result;
#define RX_CONTINUE ((__force lowpan_rx_result) 0u)
#define RX_DROP_UNUSABLE ((__force lowpan_rx_result) 1u)
#define RX_DROP ((__force lowpan_rx_result) 2u)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index d37a577..b2069fb 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -159,7 +159,7 @@ enum ieee80211_bss_valid_data_flags {
IEEE80211_BSS_VALID_ERP = BIT(3)
};
-typedef unsigned __bitwise__ ieee80211_tx_result;
+typedef unsigned __bitwise ieee80211_tx_result;
#define TX_CONTINUE ((__force ieee80211_tx_result) 0u)
#define TX_DROP ((__force ieee80211_tx_result) 1u)
#define TX_QUEUED ((__force ieee80211_tx_result) 2u)
@@ -180,7 +180,7 @@ struct ieee80211_tx_data {
};
-typedef unsigned __bitwise__ ieee80211_rx_result;
+typedef unsigned __bitwise ieee80211_rx_result;
#define RX_CONTINUE ((__force ieee80211_rx_result) 0u)
#define RX_DROP_UNUSABLE ((__force ieee80211_rx_result) 1u)
#define RX_DROP_MONITOR ((__force ieee80211_rx_result) 2u)
--
MST
^ permalink raw reply related
* [PATCH 0/8] enable endian checks for all sparse builds
From: Michael S. Tsirkin @ 2016-12-15 5:15 UTC (permalink / raw)
To: linux-arm-kernel
This is just a reposting of the patch that enables endian checks, with addition
of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere.
I plan to include this in my pull request unless I hear otherwise.
Michael S. Tsirkin (8):
linux/types.h: enable endian checks for all sparse builds
tools: enable endian checks for all sparse builds
Documentation/sparse: drop __bitwise__
checkpatch: replace __bitwise__ with __bitwise
linux: drop __bitwise__ everywhere
Documentation/sparse: drop __CHECK_ENDIAN__
fs/logfs: drop __CHECK_ENDIAN__
Makefile: drop -D__CHECK_ENDIAN__ from cflags
Documentation/translations/zh_CN/sparse.txt | 7 +------
arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
drivers/md/dm-cache-block-types.h | 6 +++---
drivers/net/ethernet/sun/sunhme.h | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
fs/logfs/logfs.h | 4 +---
include/linux/mmzone.h | 2 +-
include/linux/serial_core.h | 4 ++--
include/linux/types.h | 4 ++--
include/scsi/iscsi_proto.h | 2 +-
include/target/target_core_base.h | 2 +-
include/uapi/linux/types.h | 4 ----
include/uapi/linux/virtio_types.h | 6 +++---
net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
net/mac80211/ieee80211_i.h | 4 ++--
tools/include/linux/types.h | 4 ----
Documentation/dev-tools/sparse.rst | 14 +-------------
drivers/bluetooth/Makefile | 2 --
drivers/net/can/Makefile | 1 -
drivers/net/ethernet/altera/Makefile | 1 -
drivers/net/ethernet/atheros/alx/Makefile | 1 -
drivers/net/ethernet/freescale/Makefile | 2 --
drivers/net/wireless/ath/Makefile | 2 --
drivers/net/wireless/ath/wil6210/Makefile | 2 --
drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
drivers/net/wireless/intel/iwlegacy/Makefile | 2 --
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
drivers/net/wireless/intersil/orinoco/Makefile | 3 ---
drivers/net/wireless/mediatek/mt7601u/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile | 2 --
drivers/net/wireless/ti/wl1251/Makefile | 2 --
drivers/net/wireless/ti/wlcore/Makefile | 2 --
drivers/staging/rtl8188eu/Makefile | 2 +-
drivers/staging/rtl8192e/Makefile | 2 --
drivers/staging/rtl8192e/rtl8192e/Makefile | 2 --
net/bluetooth/Makefile | 2 --
net/ieee802154/Makefile | 2 --
net/mac80211/Makefile | 2 +-
net/mac802154/Makefile | 2 --
net/wireless/Makefile | 2 --
scripts/checkpatch.pl | 4 ++--
56 files changed, 30 insertions(+), 120 deletions(-)
--
MST
^ permalink raw reply
* [PATCH v2 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
From: Chanwoo Choi @ 2016-12-15 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481173091-9728-2-git-send-email-cw00.choi@samsung.com>
Dear Sylwester,
Could you please review this patch?
--
Regards,
Chanwoo Choi
On 2016? 12? 08? 13:58, Chanwoo Choi wrote:
> The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are
> disabled, the system halt happen. Following clock must be always enabled.
> - CLK_ACLK_BUS0_400 : NoC's bus clock for PERIC/PERIS/FSYS/MSCL
> - CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
> - CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP
>
> Also, this patch adds the CLK_SET_RATE_PARENT flag to the CLK_SCLK_JPEG_MSCL
> because this clock should be used for bus frequency scaling. This clock need to
> be changed on the fly with CLK_SET_RATE_PARENT flag.
>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc:linux-clk at vger.kernel.org
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/clk/samsung/clk-exynos5433.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5433.c b/drivers/clk/samsung/clk-exynos5433.c
> index f096bd7df40c..0db5204c307c 100644
> --- a/drivers/clk/samsung/clk-exynos5433.c
> +++ b/drivers/clk/samsung/clk-exynos5433.c
> @@ -549,10 +549,10 @@
> 29, CLK_IGNORE_UNUSED, 0),
> GATE(CLK_ACLK_BUS0_400, "aclk_bus0_400", "div_aclk_bus0_400",
> ENABLE_ACLK_TOP, 26,
> - CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
> + CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
> GATE(CLK_ACLK_BUS1_400, "aclk_bus1_400", "div_aclk_bus1_400",
> ENABLE_ACLK_TOP, 25,
> - CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
> + CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
> GATE(CLK_ACLK_IMEM_200, "aclk_imem_200", "div_aclk_imem_266",
> ENABLE_ACLK_TOP, 24,
> CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
> @@ -616,7 +616,7 @@
>
> /* ENABLE_SCLK_TOP_MSCL */
> GATE(CLK_SCLK_JPEG_MSCL, "sclk_jpeg_mscl", "div_sclk_jpeg",
> - ENABLE_SCLK_TOP_MSCL, 0, 0, 0),
> + ENABLE_SCLK_TOP_MSCL, 0, CLK_SET_RATE_PARENT, 0),
>
> /* ENABLE_SCLK_TOP_CAM1 */
> GATE(CLK_SCLK_ISP_SENSOR2, "sclk_isp_sensor2", "div_sclk_isp_sensor2_b",
> @@ -1382,7 +1382,7 @@ static void __init exynos5433_cmu_cpif_init(struct device_node *np)
> /* ENABLE_ACLK_MIF3 */
> GATE(CLK_ACLK_BUS2_400, "aclk_bus2_400", "div_aclk_bus2_400",
> ENABLE_ACLK_MIF3, 4,
> - CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
> + CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
> GATE(CLK_ACLK_DISP_333, "aclk_disp_333", "div_aclk_disp_333",
> ENABLE_ACLK_MIF3, 1,
> CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
>
^ permalink raw reply
* [PATCH] builddeb: Use aarch64 instead of arm64 for UTS_MACHINE
From: Victor Chong @ 2016-12-15 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481280644-15614-1-git-send-email-will.deacon@arm.com>
Hi Will,
Just found out that a similar patch was submitted earlier back in Nov.
https://patchwork.kernel.org/patch/9444665/
Thanks!
On Fri, Dec 9, 2016 at 7:50 PM, Will Deacon <will.deacon@arm.com> wrote:
> From: Michal Marek <mmarek@suse.com>
>
> On arm64-based systems, uname -m reports "aarch64", so this is what
> we should be using for UTS_MACHINE and matching that in the builddeb
> script instead of "arm64".
>
> There was a patch fixing this:
>
> https://patchwork.kernel.org/patch/9305483/
>
> but I accidentally merged v1 of the patch, which omitted the update to
> builddeb. This patch follows up with that missing hunk.
>
> Reported-by: Victor Chong <victor.chong@linaro.org>
> Signed-off-by: Michal Marek <mmarek@suse.com>
> [will: salvaged missing hunk from original patch]
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> scripts/package/builddeb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 8ea9fd2b6573..9530b1634a02 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -51,7 +51,7 @@ set_debarch() {
> debarch=hppa ;;
> mips*)
> debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG && echo el || true) ;;
> - arm64)
> + aarch64*)
> debarch=arm64 ;;
> arm*)
> if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Brian Norris @ 2016-12-15 3:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ce521da-119a-2de8-026c-5992fedfef43@rock-chips.com>
On Thu, Dec 15, 2016 at 10:41:04AM +0800, Xing Zheng wrote:
> // Frank
>
> Hi Doug, Brain,
> Thanks for the reply.
> Sorry I forgot these patches have been sent earlier, and Frank
> have some explained and discussed with Heiko.
> Please see https://patchwork.kernel.org/patch/9255245/
> Perhaps we can move to that patch tree to continue the discussion.
>
> I think Frank and William will help us to continue checking these.
I only briefly read that discussion, but AFAICT it doesn't actually
address all the comments/quetions we had here. For instance, the
power_off() vs. delayed-work race in your USB2 PHY driver (is that
intentional?). Also, the question of why PHY (auto?)suspend is relevant.
I'll check again tomorrow.
Brian
^ permalink raw reply
* [PATCH] arm64: mm: Fix NOMAP page initialization
From: Yisheng Xie @ 2016-12-15 3:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214094542.GE5588@rric.localdomain>
hi Robert,
On 2016/12/14 17:45, Robert Richter wrote:
> On 12.12.16 17:53:02, Yisheng Xie wrote:
>> It seems that memblock_is_memory() is also too strict for early_pfn_valid,
>> so what about this patch, which use common pfn_valid as early_pfn_valid
>> when CONFIG_HAVE_ARCH_PFN_VALID=y:
>> ------------
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 0f088f3..9d596f3 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -1200,7 +1200,17 @@ static inline int pfn_present(unsigned long pfn)
>> #define pfn_to_nid(pfn) (0)
>> #endif
>>
>> +#ifdef CONFIG_HAVE_ARCH_PFN_VALID
>> +static inline int early_pfn_valid(unsigned long pfn)
>> +{
>> + if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>> + return 0;
>> + return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
>> +}
>
> I sent a V2 patch that uses pfn_present(). This only initilizes
> sections with memory.
hmm? maybe I do not quite catch what your mean, but I do not think
pfn_present is right for this case.
IMO, The valid_section() means the section with mem_map, not section with memory.
And:
pfn_present
-> present_section
which means the section is present but may not have mem_map, so it may not
have page struct at all for that section.
Please let me know, if I miss anything.
Thanks,
Yisheng Xie.
>
> -Robert
>
>> +#define early_pfn_valid early_pfn_valid
>> +#else
>> #define early_pfn_valid(pfn) pfn_valid(pfn)
>> +#endif
>> void sparse_init(void);
>> #else
>> #define sparse_init() do {} while (0)
>>
>>
>>
>
>
^ permalink raw reply
* [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: zhong jiang @ 2016-12-15 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Qh8N+fagYqtO_04fZ=Wxg5S-=4bmPD0bxQrSyb+NZvw@mail.gmail.com>
On 2016/12/14 22:45, Ard Biesheuvel wrote:
> On 14 December 2016 at 14:19, zhongjiang <zhongjiang@huawei.com> wrote:
>> From: zhong jiang <zhongjiang@huawei.com>
>>
>> I think that CONT_PTE_SHIFT is more reasonable even if they are some
>> value. and the patch is not any functional change.
>>
> This may be the case for 64k pages, but not for 16k pages, and I
> actually think add_default_hugepagesz() could be made unconditional,
> given that both 64k on 4k kernels and 2 MB on 16k kernels are useful
> hugepage sizes that are not otherwise available by default.
I agree that we can make add_default_hugepagesz() to be unconditional.
but I do not know the history why it did so at that time. The patch
just is based on the current kernel.
by the way, please review the second patch if you have time. Any comment
will be welcomed.
Thanks
zhongjiang
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
>> ---
>> arch/arm64/mm/hugetlbpage.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
>> index 2e49bd2..0a4c97b 100644
>> --- a/arch/arm64/mm/hugetlbpage.c
>> +++ b/arch/arm64/mm/hugetlbpage.c
>> @@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
>> static __init int add_default_hugepagesz(void)
>> {
>> if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
>> - hugetlb_add_hstate(CONT_PMD_SHIFT);
>> + hugetlb_add_hstate(CONT_PTE_SHIFT);
>> return 0;
>> }
>> arch_initcall(add_default_hugepagesz);
>> --
>> 1.8.3.1
>>
> .
>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Xing Zheng @ 2016-12-15 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UU4JdRjRgEvc_wxprvi6bo46+jd=x2m2QzOe4uJmuRPA@mail.gmail.com>
// Frank
Hi Doug, Brain,
Thanks for the reply.
Sorry I forgot these patches have been sent earlier, and Frank have
some explained and discussed with Heiko.
Please see https://patchwork.kernel.org/patch/9255245/
Perhaps we can move to that patch tree to continue the discussion.
I think Frank and William will help us to continue checking these.
Thanks
? 2016?12?15? 08:10, Doug Anderson ??:
> Hi,
>
> On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
>> From: William wu <wulf@rock-chips.com>
>>
>> We found that the suspend process was blocked when it run into
>> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>>
>> The root cause is that usb2-phy suspended earlier than ehci/ohci
>> (usb2-phy will be auto suspended if no devices plug-in).
> This is really weird, but I can confirm it is true on my system too
> (kernel-4.4 based). At least I see:
>
> [ 208.012065] calling usb1+ @ 4984, parent: fe380000.usb, cb: usb_dev_suspend
> [ 208.569112] calling ff770000.syscon:usb2-phy at e450+ @ 4983, parent:
> ff770000.syscon, cb: platform_pm_suspend
> [ 208.569113] call ff770000.syscon:usb2-phy at e450+ returned 0 after 0 usecs
> [ 208.569439] calling fe380000.usb+ @ 4983, parent: platform, cb:
> platform_pm_suspend
> [ 208.569444] call fe380000.usb+ returned 0 after 4 usecs
>
>
> In general I thought that suspend order was supposed to be related to
> probe order. So if your probe order is A, B, C then your suspend
> order would be C, B, A. ...and we know for sure that the USB PHY
> needs to probe _before_ the main USB controller. If it didn't then
> you'd get an EPROBE_DEFER in the USB controller, right? So that means
> that the USB controller should be suspending before its PHY.
>
> Any chance this is somehow related to async probe? I'm not a huge
> expert on async probe but I guess I could imagine things getting
> confused if you had a sequence like this:
>
> 1. Start USB probe (async)
> 2. Start PHY probe
> 3. Finish PHY probe
> 4. In USB probe, ask for PHY--no problems since PHY probe finished
> 5. Finish USB probe
>
> The probe order would be USB before PHY even though the USB probe
> _depended_ on the PHY probe being finished... :-/ Anyway, probably
> I'm just misunderstanding something and someone can tell me how dumb I
> am...
>
> I also notice that the ehci_platform_power_off() function we're
> actually making PHY commands right before the same commands that turn
> off our clocks. Presumably those commands aren't really so good to do
> if the PHY has already been suspended?
>
> Actually, does the PHY suspend from platform_pm_suspend() actually
> even do anything? It doesn't look like it. It looks as if all the
> PHY cares about is init/exit and on/off... ...and it looks as if the
> PHY should be turned off by the EHCI controller at about the same time
> it turns off its clocks...
>
> I haven't fully dug, but is there any chance that things are getting
> confused between the OTG PHY and the Host PHY? Maybe when we turn off
> the OTG PHY it turns off something that the host PHY needs?
>
>
>> and the
>> clk-480m provided by it was disabled if no module used. However,
>> some suspend process related ehci/ohci are base on this clock,
>> so we should refer it into ehci/ohci driver to prevent this case.
> Though I don't actually have details about the internals of the chip,
> it does seem highly likely that the USB block actually uses this clock
> for some things, so it doesn't seem insane (to me) to have the USB
> controller request that the clock be on. So, in general, I don't have
> lots of objections to including the USB PHY Clock here.
>
> ...but I think you have the wrong clock (please correct me if I'm
> wrong). I think you really wanted your input clock to be
> "clk_usbphy0_480m", not "clk_usbphy0_480m_src". Specifically I
> believe there is a gate between the clock outputted by the PHY and the
> USB Controller itself. I'm guessing that the gate is only there
> between the PHY and the "clk_usbphy_480m" MUX.
>
> As evidence, I have a totally functioning system right now where
> "clk_usbphy0_480m_src" is currently gated.
>
> That means really you should be changing your clocks to this (untested):
>
> clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> <&u2phy0>;
>
> ...and then you could drop the other two patches in this series.
>
> ===
>
> OK, I actually briefly tested my proposed change and it at least seems
> to build and boot OK. You'd have to test it to make sure it makes
> your tests pass...
>
> ===
>
> So I guess to summarize all the above:
>
> * It seems to me like there's some deeper root cause and your patch
> will at most put a band-aid on it. Seems like digging out the root
> cause is a good idea.
>
> * Though I don't believe it solves the root problem, the idea of the
> USB Controller holding onto the PHY clock doesn't seem wrong.
>
> * You're holding onto the wrong clock in your patch--you want the one
> before the gate (I think).
>
>
> -Doug
>
>
>
--
- Xing Zheng
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Brian Norris @ 2016-12-15 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215004737.GA32652@google.com>
On Wed, Dec 14, 2016 at 04:47:38PM -0800, Brian Norris wrote:
> On Wed, Dec 14, 2016 at 04:10:38PM -0800, Doug Anderson wrote:
> > On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> > > From: William wu <wulf@rock-chips.com>
> > >
> > > We found that the suspend process was blocked when it run into
> > > ehci/ohci module due to clk-480m of usb2-phy was disabled.
One more thing: why is the USB2 PHY relevant to the OHCI controller? And
if it is relevant, why isn't there a PHY phandle for it in
usb_host0_ohci and usb_host1_ohci in rk3399.dtsi? As it stands, your
patch is hacking in USB2 clock references for OHCI, but you're not
actually managing the PHY there at all. Seems like you'd want to do
all-or-nothing if there's a functional dependency between the OHCI
controllers and the USB2 PHYs.
Brian
^ permalink raw reply
* [PATCH] arm: Adjust memory boundaries after reservations
From: Laura Abbott @ 2016-12-15 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235827.GI14217@n2100.armlinux.org.uk>
On 12/14/2016 03:58 PM, Russell King - ARM Linux wrote:
> On Tue, Dec 13, 2016 at 06:11:41PM -0800, Laura Abbott wrote:
>> The poorly named sanity_check_meminfo is responsible for setting up the
>> boundary for lowmem/highmem. This needs to be set up before memblock
>> reservations can occur. At the time memblock reservations can occur,
>> memory can also be removed from the system. This can throw off the
>> calculation of the lowmem/highmem boundary. On some systems this may be
>> harmless, on others this may result in incorrect ranges being passed to
>> the main memory allocator. Correct this by recalcuating the
>> lowmem/highmem boundary after all reservations have been made.
>> As part of this, rename sanity_check_meminfo to actually refect what the
>> function is doing.
>
> I think this needs more explanation - after reading that, I'm left
> wondering wtf is going on...
>
> Let's say that the memory boundary was at 0x30000000. Memory from
> 0x2f000000 to 0x30000000 is stolen, which reserves it and removes
> it from the available memory.
>
> Since the memory is no longer available, why would the stolen range
> end up being passed to the main memory allocator?
>
> How is this any different from the boot loader omitting the memory
> range in the first place?
>
The issue ends up coming in with find_limits
static void __init find_limits(unsigned long *min, unsigned long *max_low,
unsigned long *max_high)
{
*max_low = PFN_DOWN(memblock_get_current_limit());
*min = PFN_UP(memblock_start_of_DRAM());
*max_high = PFN_DOWN(memblock_end_of_DRAM());
}
the memblock limit never gets updated after removal but memblock_end_of_DRAM
does. When the last block of ram is removed, the end of DRAM ends up being
lower than the limit. On the i.MX system with a small amount of ram but
CONFIG_HIGHMEM enabled, this ends up with an incorrect calculation for
the amount of ram to go in the highmem zone in zone_sizes_init.
Thanks,
Laura
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Brian Norris @ 2016-12-15 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UU4JdRjRgEvc_wxprvi6bo46+jd=x2m2QzOe4uJmuRPA@mail.gmail.com>
Hi,
I think Doug is probably right on most accounts, and I haven't
thoroughly investigated all the claims. But a few thoughts:
On Wed, Dec 14, 2016 at 04:10:38PM -0800, Doug Anderson wrote:
> On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> > From: William wu <wulf@rock-chips.com>
> >
> > We found that the suspend process was blocked when it run into
> > ehci/ohci module due to clk-480m of usb2-phy was disabled.
> >
> > The root cause is that usb2-phy suspended earlier than ehci/ohci
> > (usb2-phy will be auto suspended if no devices plug-in).
When you say "suspend" do you mean USB runtime suspend (i.e., auto
suspend) or do you mean system suspend (i.e., driver .suspend()
callbacks)? The latter are empty intentionally for PHY drivers, since
PHY state is managed by the consumer driver (i.e., the controller
driver). And the former doesn't actually disable any clocks AFAIK, so
that's a red herring IIUC.
> This is really weird, but I can confirm it is true on my system too
> (kernel-4.4 based). At least I see:
>
> [ 208.012065] calling usb1+ @ 4984, parent: fe380000.usb, cb: usb_dev_suspend
> [ 208.569112] calling ff770000.syscon:usb2-phy at e450+ @ 4983, parent:
> ff770000.syscon, cb: platform_pm_suspend
> [ 208.569113] call ff770000.syscon:usb2-phy at e450+ returned 0 after 0 usecs
> [ 208.569439] calling fe380000.usb+ @ 4983, parent: platform, cb:
> platform_pm_suspend
> [ 208.569444] call fe380000.usb+ returned 0 after 4 usecs
>
>
> In general I thought that suspend order was supposed to be related to
> probe order. So if your probe order is A, B, C then your suspend
> order would be C, B, A. ...and we know for sure that the USB PHY
> needs to probe _before_ the main USB controller. If it didn't then
> you'd get an EPROBE_DEFER in the USB controller, right? So that means
> that the USB controller should be suspending before its PHY.
>
> Any chance this is somehow related to async probe? I'm not a huge
> expert on async probe but I guess I could imagine things getting
> confused if you had a sequence like this:
>
> 1. Start USB probe (async)
> 2. Start PHY probe
> 3. Finish PHY probe
> 4. In USB probe, ask for PHY--no problems since PHY probe finished
> 5. Finish USB probe
>
> The probe order would be USB before PHY even though the USB probe
> _depended_ on the PHY probe being finished... :-/ Anyway, probably
> I'm just misunderstanding something and someone can tell me how dumb I
> am...
That may well be true. There isn't a single defined probe order as soon
as you involve async probe, right? So things get a little fuzzier. Also,
I know if you're talking about async suspend/resume, the driver core
only (until quite recently? [1]) respects parent/child relationships.
But I'm not sure of all the async details right now, and async suspend
isn't typically used for the controllers AFAIK -- just for the
hubs/devices.
Anyway, I don't think that's relevant at all because:
> I also notice that the ehci_platform_power_off() function we're
> actually making PHY commands right before the same commands that turn
> off our clocks. Presumably those commands aren't really so good to do
> if the PHY has already been suspended?
>
> Actually, does the PHY suspend from platform_pm_suspend() actually
> even do anything? It doesn't look like it. It looks as if all the
> PHY cares about is init/exit and on/off... ...and it looks as if the
> PHY should be turned off by the EHCI controller at about the same time
> it turns off its clocks...
Right, PHY drivers don't do anything at suspend/resume, since I guess
they presume the consuming driver (the controller) will handle state
transitions (power off, exit).
> I haven't fully dug, but is there any chance that things are getting
> confused between the OTG PHY and the Host PHY? Maybe when we turn off
> the OTG PHY it turns off something that the host PHY needs?
Random thing I noticed: there seems to be a race in
phy-rockchip-inno-usb2.c, if we're worried about the 480M clock getting
disabled too early. See:
static int rockchip_usb2phy_power_off(struct phy *phy)
{
...
clk_disable_unprepare(rphy->clk480m);
...
}
static int rockchip_usb2phy_exit(struct phy *phy)
{
struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
if (rport->port_id == USB2PHY_PORT_OTG &&
rport->mode != USB_DR_MODE_HOST) {
cancel_delayed_work_sync(&rport->otg_sm_work);
cancel_delayed_work_sync(&rport->chg_work);
} else if (rport->port_id == USB2PHY_PORT_HOST)
cancel_delayed_work_sync(&rport->sm_work);
return 0;
}
I believe that means any of those work handlers can still be running while
after power_off() -- and therefore can be running after we've disabled the
clock. Might this be your problem?
If so, you're papering that bug by keeping a clock reference in the
controller, which implicitly defers the *actual*
clock_disable_unprepare() until much later.
Brian
[1] commit 9ed9895370ae ("driver core: Functional dependencies tracking
support")
^ permalink raw reply
* [PATCH 2/3] clk: rockchip: rk3399: export 480M_SRC clocks id for usbphy0/usbphy1
From: Doug Anderson @ 2016-12-15 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481710301-1454-3-git-send-email-zhengxing@rock-chips.com>
Hi,
On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> This patch exports USBPHYx_480M_SRC clocks for usbphy.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> drivers/clk/rockchip/clk-rk3399.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
As mentioned in the dts patch, I don't think you need these since I'm
under the impression that nobody gets this clock. I think the USB
Controller get the ungated version of this clock.
-Doug
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Robin Murphy @ 2016-12-15 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612150109.20868@pali>
On Thu, 15 Dec 2016 01:09:20 +0100
Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Thursday 15 December 2016 00:52:24 Russell King - ARM Linux wrote:
> > On Wed, Dec 14, 2016 at 10:12:43PM +0100, Pali Roh?r wrote:
> > > Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi
> > > usage") broke support for setting cmdline on Nokia N900 via
> > > CONFIG_CMDLINE.
> > >
> > > It is because arm code booted in DT mode parse cmdline only via
> > > function early_init_dt_scan_chosen() and that function does not
> > > fill variable boot_command_line when DTB does not contain /chosen
> > > entry. It is called from function early_init_dt_scan_nodes() in
> > > setup_machine_fdt().
> > >
> > > This patch fixes it by explicitly filling boot_command_line in
> > > function setup_machine_fdt() after calling
> > > early_init_dt_scan_nodes() in case boot_command_line still remains
> > > empty.
> >
> > This looks like a hack.
> >
> > First, the matter of the ATAGs compatibility. The decompressor
> > relies on there being a pre-existing /chosen node to insert the
> > command line and other parameters into. If we've dropped it (by
> > dropping skeleton.dtsi) then we've just regressed more than just
> > N900 - the decompressor won't be able to merge the ATAGs into the
> > concatenated FDT.
>
> Hm... I did not think about it. But right this can be broken too...
>
> > Second, CONFIG_CMDLINE has never been in place on DT systems - it's
> > something atags_parse.c has been dealing with which isn't involved
> > on DT. For DT, we expect the command line to be passed in.
>
> If cmdline is not in DT, but /chosen exists, then function
> early_init_dt_scan_chosen() use cmdline from CONFIG_CMDLINE.
>
> > Now, given that, I find your commit message rather fishy. You seem
> > to be claiming that CONFIG_CMDLINE used to work, but the fact is,
> > we've never had it working on device tree systems.
>
> Looks like that CONFIG_CMDLINE really did not worked (correctly) on
> DT booted systems... We have already discussed about it on #armlinux
>
> > Instead, what I think was going on is that the bug you're seeing is
> > that the removal of skeleton.dtsi results in the /chosen node being
> > absent, which in turn prevents the decompressor picking the various
> > parameters out of the ATAGs and dropping them into the DT blob.
>
> In my case, bootloader did not provided any cmdline in ATAG, so
> decompressor did not parsed any cmdline...
>
> > That, to me, sounds like a regression, and the fix is not to hack
> > support for an unrelated feature, but to fix the original problem -
> > and I think in this case, it's reasonable to ask for the offending
> > commit to be reverted.
>
> I will let decision to others, who created and accepted that patch
> 008a2ebcd677. What I need is working CONFIG_CMDLINE as I had it
> before as bootloader for Nokia N900 does not pass any cmdline -- and
> without it I cannot boot userspace.
Isn't that what CONFIG_CMDLINE_FORCE is for?
Or you could, y'know, just add a chosen node to the N900 DT to put it
back in the same state as before...
Robin.
> But still, I would like to see working CONFIG_CMDLINE support for DT
> systems. Other systems (e.g. arm ATAG based or x86) have it.
>
> What is reason that CONFIG_CMDLINE is not supported for DT?
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH 07/39] ARM: dts: armada-370-rd: Correct license text
From: Florian Fainelli @ 2016-12-15 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214223746.23066-8-alexandre.belloni@free-electrons.com>
On 12/14/2016 02:37 PM, Alexandre Belloni wrote:
> The license test has been mangled at some point then copy pasted across
> multiple files. Restore it to what it should be.
> Note that this is not intended as a license change.
>
> Cc: Arnaud Ebalard <arno@natisbad.org>
> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Cc: Florian Fainelli <florian@openwrt.org>
> Cc: Simon Baatz <gmbnomis@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Doug Anderson @ 2016-12-15 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481710301-1454-4-git-send-email-zhengxing@rock-chips.com>
Hi,
On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> From: William wu <wulf@rock-chips.com>
>
> We found that the suspend process was blocked when it run into
> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>
> The root cause is that usb2-phy suspended earlier than ehci/ohci
> (usb2-phy will be auto suspended if no devices plug-in).
This is really weird, but I can confirm it is true on my system too
(kernel-4.4 based). At least I see:
[ 208.012065] calling usb1+ @ 4984, parent: fe380000.usb, cb: usb_dev_suspend
[ 208.569112] calling ff770000.syscon:usb2-phy at e450+ @ 4983, parent:
ff770000.syscon, cb: platform_pm_suspend
[ 208.569113] call ff770000.syscon:usb2-phy at e450+ returned 0 after 0 usecs
[ 208.569439] calling fe380000.usb+ @ 4983, parent: platform, cb:
platform_pm_suspend
[ 208.569444] call fe380000.usb+ returned 0 after 4 usecs
In general I thought that suspend order was supposed to be related to
probe order. So if your probe order is A, B, C then your suspend
order would be C, B, A. ...and we know for sure that the USB PHY
needs to probe _before_ the main USB controller. If it didn't then
you'd get an EPROBE_DEFER in the USB controller, right? So that means
that the USB controller should be suspending before its PHY.
Any chance this is somehow related to async probe? I'm not a huge
expert on async probe but I guess I could imagine things getting
confused if you had a sequence like this:
1. Start USB probe (async)
2. Start PHY probe
3. Finish PHY probe
4. In USB probe, ask for PHY--no problems since PHY probe finished
5. Finish USB probe
The probe order would be USB before PHY even though the USB probe
_depended_ on the PHY probe being finished... :-/ Anyway, probably
I'm just misunderstanding something and someone can tell me how dumb I
am...
I also notice that the ehci_platform_power_off() function we're
actually making PHY commands right before the same commands that turn
off our clocks. Presumably those commands aren't really so good to do
if the PHY has already been suspended?
Actually, does the PHY suspend from platform_pm_suspend() actually
even do anything? It doesn't look like it. It looks as if all the
PHY cares about is init/exit and on/off... ...and it looks as if the
PHY should be turned off by the EHCI controller at about the same time
it turns off its clocks...
I haven't fully dug, but is there any chance that things are getting
confused between the OTG PHY and the Host PHY? Maybe when we turn off
the OTG PHY it turns off something that the host PHY needs?
> and the
> clk-480m provided by it was disabled if no module used. However,
> some suspend process related ehci/ohci are base on this clock,
> so we should refer it into ehci/ohci driver to prevent this case.
Though I don't actually have details about the internals of the chip,
it does seem highly likely that the USB block actually uses this clock
for some things, so it doesn't seem insane (to me) to have the USB
controller request that the clock be on. So, in general, I don't have
lots of objections to including the USB PHY Clock here.
...but I think you have the wrong clock (please correct me if I'm
wrong). I think you really wanted your input clock to be
"clk_usbphy0_480m", not "clk_usbphy0_480m_src". Specifically I
believe there is a gate between the clock outputted by the PHY and the
USB Controller itself. I'm guessing that the gate is only there
between the PHY and the "clk_usbphy_480m" MUX.
As evidence, I have a totally functioning system right now where
"clk_usbphy0_480m_src" is currently gated.
That means really you should be changing your clocks to this (untested):
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
<&u2phy0>;
...and then you could drop the other two patches in this series.
===
OK, I actually briefly tested my proposed change and it at least seems
to build and boot OK. You'd have to test it to make sure it makes
your tests pass...
===
So I guess to summarize all the above:
* It seems to me like there's some deeper root cause and your patch
will at most put a band-aid on it. Seems like digging out the root
cause is a good idea.
* Though I don't believe it solves the root problem, the idea of the
USB Controller holding onto the PHY clock doesn't seem wrong.
* You're holding onto the wrong clock in your patch--you want the one
before the gate (I think).
-Doug
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Pali Rohár @ 2016-12-15 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235224.GH14217@n2100.armlinux.org.uk>
On Thursday 15 December 2016 00:52:24 Russell King - ARM Linux wrote:
> On Wed, Dec 14, 2016 at 10:12:43PM +0100, Pali Roh?r wrote:
> > Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi usage")
> > broke support for setting cmdline on Nokia N900 via
> > CONFIG_CMDLINE.
> >
> > It is because arm code booted in DT mode parse cmdline only via
> > function early_init_dt_scan_chosen() and that function does not
> > fill variable boot_command_line when DTB does not contain /chosen
> > entry. It is called from function early_init_dt_scan_nodes() in
> > setup_machine_fdt().
> >
> > This patch fixes it by explicitly filling boot_command_line in
> > function setup_machine_fdt() after calling
> > early_init_dt_scan_nodes() in case boot_command_line still remains
> > empty.
>
> This looks like a hack.
>
> First, the matter of the ATAGs compatibility. The decompressor
> relies on there being a pre-existing /chosen node to insert the
> command line and other parameters into. If we've dropped it (by
> dropping skeleton.dtsi) then we've just regressed more than just
> N900 - the decompressor won't be able to merge the ATAGs into the
> concatenated FDT.
Hm... I did not think about it. But right this can be broken too...
> Second, CONFIG_CMDLINE has never been in place on DT systems - it's
> something atags_parse.c has been dealing with which isn't involved on
> DT. For DT, we expect the command line to be passed in.
If cmdline is not in DT, but /chosen exists, then function
early_init_dt_scan_chosen() use cmdline from CONFIG_CMDLINE.
> Now, given that, I find your commit message rather fishy. You seem
> to be claiming that CONFIG_CMDLINE used to work, but the fact is,
> we've never had it working on device tree systems.
Looks like that CONFIG_CMDLINE really did not worked (correctly) on DT
booted systems... We have already discussed about it on #armlinux
> Instead, what I think was going on is that the bug you're seeing is
> that the removal of skeleton.dtsi results in the /chosen node being
> absent, which in turn prevents the decompressor picking the various
> parameters out of the ATAGs and dropping them into the DT blob.
In my case, bootloader did not provided any cmdline in ATAG, so
decompressor did not parsed any cmdline...
> That, to me, sounds like a regression, and the fix is not to hack
> support for an unrelated feature, but to fix the original problem -
> and I think in this case, it's reasonable to ask for the offending
> commit to be reverted.
I will let decision to others, who created and accepted that patch
008a2ebcd677. What I need is working CONFIG_CMDLINE as I had it before
as bootloader for Nokia N900 does not pass any cmdline -- and without it
I cannot boot userspace.
But still, I would like to see working CONFIG_CMDLINE support for DT
systems. Other systems (e.g. arm ATAG based or x86) have it.
What is reason that CONFIG_CMDLINE is not supported for DT?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/19624c67/attachment-0001.sig>
^ permalink raw reply
* [RFC PATCH 4/4] staging: android: ion: Call dma_map_sg for syncing and mapping
From: Laura Abbott @ 2016-12-15 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481760463-3515-1-git-send-email-labbott@redhat.com>
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Not-signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion.c | 61 ++++++++++++++++++++++++++++++---------
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 86dba07..5177d79 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -776,6 +776,11 @@ static struct sg_table *dup_sg_table(struct sg_table *table)
return new_table;
}
+static void free_duped_table(struct sg_table *table)
+{
+ sg_free_table(table);
+ kfree(table);
+}
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
@@ -784,15 +789,29 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
struct sg_table *table;
- return dup_sg_table(buffer->sg_table);
+ /*
+ * TODO: Need to sync wrt CPU or device completely owning?
+ */
+
+ table = dup_sg_table(buffer->sg_table);
+
+ if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+ direction)){
+ ret = -ENOMEM;
+ goto err;
+ }
+
+err:
+ free_duped_table(table);
+ return ERR_PTR(ret);
}
static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
- sg_free_table(table);
- kfree(table);
+ dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+ free_duped_table(table);
}
struct ion_vma_list {
@@ -889,16 +908,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
- if (!buffer->heap->ops->map_kernel) {
- pr_err("%s: map kernel is not implemented by this heap.\n",
- __func__);
- return -ENODEV;
+ /*
+ * TODO: Move this elsewhere because we don't always need a vaddr
+ */
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ vaddr = ion_buffer_kmap_get(buffer);
+ mutex_unlock(&buffer->lock);
}
- mutex_lock(&buffer->lock);
- vaddr = ion_buffer_kmap_get(buffer);
- mutex_unlock(&buffer->lock);
- return PTR_ERR_OR_ZERO(vaddr);
+ /*
+ * Close enough right now? Flag to skip sync?
+ */
+ if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+ buffer->sg_table->nents,
+ DMA_BIDIRECTIONAL))
+ return -ENOMEM;
+
+ return 0;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -906,9 +933,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
{
struct ion_buffer *buffer = dmabuf->priv;
- mutex_lock(&buffer->lock);
- ion_buffer_kmap_put(buffer);
- mutex_unlock(&buffer->lock);
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ ion_buffer_kmap_put(buffer);
+ mutex_unlock(&buffer->lock);
+ }
+
+ dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+ buffer->sg_table->nents,
+ DMA_BIDIRECTIONAL);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 3/4] staging: android: ion: Remove page faulting support
From: Laura Abbott @ 2016-12-15 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481760463-3515-1-git-send-email-labbott@redhat.com>
Unclear if this is wanted or needed?
Not-signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion.c | 74 ---------------------------------------
1 file changed, 74 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 76b874a0..86dba07 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
#include "ion_priv.h"
#include "compat_ion.h"
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
- return (buffer->flags & ION_FLAG_CACHED) &&
- !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
bool ion_buffer_cached(struct ion_buffer *buffer)
{
return !!(buffer->flags & ION_FLAG_CACHED);
}
-static inline struct page *ion_buffer_page(struct page *page)
-{
- return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
- return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
- *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
- *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
/* this function should only be called while dev->lock is held */
static void ion_buffer_add(struct ion_device *dev,
struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
- if (ion_buffer_fault_user_mappings(buffer)) {
- int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
- struct scatterlist *sg;
- int i, j, k = 0;
-
- buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
- if (!buffer->pages) {
- ret = -ENOMEM;
- goto err1;
- }
-
- for_each_sg(table->sgl, sg, table->nents, i) {
- struct page *page = sg_page(sg);
-
- for (j = 0; j < sg->length / PAGE_SIZE; j++)
- buffer->pages[k++] = page++;
- }
- }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(&buffer->vmas);
@@ -845,25 +800,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
};
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
- struct ion_buffer *buffer = vma->vm_private_data;
- unsigned long pfn;
- int ret;
-
- mutex_lock(&buffer->lock);
- ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
- BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
- pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
- ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
- mutex_unlock(&buffer->lock);
- if (ret)
- return VM_FAULT_ERROR;
-
- return VM_FAULT_NOPAGE;
-}
-
static void ion_vm_open(struct vm_area_struct *vma)
{
struct ion_buffer *buffer = vma->vm_private_data;
@@ -900,7 +836,6 @@ static void ion_vm_close(struct vm_area_struct *vma)
static const struct vm_operations_struct ion_vma_ops = {
.open = ion_vm_open,
.close = ion_vm_close,
- .fault = ion_vm_fault,
};
static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
@@ -914,15 +849,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
return -EINVAL;
}
- if (ion_buffer_fault_user_mappings(buffer)) {
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
- VM_DONTDUMP;
- vma->vm_private_data = buffer;
- vma->vm_ops = &ion_vma_ops;
- ion_vm_open(vma);
- return 0;
- }
-
if (!(buffer->flags & ION_FLAG_CACHED))
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 2/4] staging: android: ion: Duplicate sg_table
From: Laura Abbott @ 2016-12-15 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481760463-3515-1-git-send-email-labbott@redhat.com>
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Not-signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 8dd0932..76b874a0 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,19 +795,49 @@ void ion_client_destroy(struct ion_client *client)
}
EXPORT_SYMBOL(ion_client_destroy);
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlisg *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+ if (ret) {
+ kfree(table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ memcpy(new_sg, sg, sizeof(*sg));
+ sg->dma_address = 0;
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
+ struct sg_table *table;
- return buffer->sg_table;
+ return dup_sg_table(buffer->sg_table);
}
static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ sg_free_table(table);
+ kfree(table);
}
struct ion_vma_list {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/4] staging: android: ion: Some cleanup
From: Laura Abbott @ 2016-12-15 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481760463-3515-1-git-send-email-labbott@redhat.com>
- dmap_cnt isn't used. Remove it.
- Ion has been using dma apis incorrectly to sync the caches.
Remove bad usage in preparation for something better.
- The alignment field doesn't actually change the alignment of an
allocation, it only serves as an error check. This is basically
pointless. Remove the field.
Not-signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion-ioctl.c | 6 --
drivers/staging/android/ion/ion.c | 92 ++-----------------------
drivers/staging/android/ion/ion.h | 5 +-
drivers/staging/android/ion/ion_carveout_heap.c | 16 +----
drivers/staging/android/ion/ion_chunk_heap.c | 15 +---
drivers/staging/android/ion/ion_cma_heap.c | 5 +-
drivers/staging/android/ion/ion_page_pool.c | 3 -
drivers/staging/android/ion/ion_priv.h | 4 +-
drivers/staging/android/ion/ion_system_heap.c | 14 +---
9 files changed, 16 insertions(+), 144 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
index 7e7431d..a27db9d 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
struct ion_handle *handle;
handle = ion_alloc(client, data.allocation.len,
- data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
data.handle.handle = handle->id;
break;
}
- case ION_IOC_SYNC:
- {
- ret = ion_sync_for_device(client, data.fd.fd);
- break;
- }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index d5cc307..8dd0932 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
- unsigned long align,
unsigned long flags)
{
struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
buffer->flags = flags;
kref_init(&buffer->ref);
- ret = heap->ops->allocate(heap, buffer, len, align, flags);
+ ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
ion_heap_freelist_drain(heap, 0);
- ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+ ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct ion_handle *handle)
}
struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
- size_t align, unsigned int heap_id_mask,
+ unsigned int heap_id_mask,
unsigned int flags)
{
struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
struct ion_heap *heap;
int ret;
- pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
- len, align, heap_id_mask, flags);
+ pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+ len, heap_id_mask, flags);
/*
* traverse the list of heaps available in this system in priority
* order. If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
- buffer = ion_buffer_create(heap, dev, len, align, flags);
+ buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
@@ -797,17 +795,12 @@ void ion_client_destroy(struct ion_client *client)
}
EXPORT_SYMBOL(ion_client_destroy);
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
- struct device *dev,
- enum dma_data_direction direction);
-
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
- ion_buffer_sync_for_device(buffer, attachment->dev, direction);
return buffer->sg_table;
}
@@ -817,60 +810,11 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
{
}
-void ion_pages_sync_for_device(struct device *dev, struct page *page,
- size_t size, enum dma_data_direction dir)
-{
- struct scatterlist sg;
-
- sg_init_table(&sg, 1);
- sg_set_page(&sg, page, size, 0);
- /*
- * This is not correct - sg_dma_address needs a dma_addr_t that is valid
- * for the targeted device, but this works on the currently targeted
- * hardware.
- */
- sg_dma_address(&sg) = page_to_phys(page);
- dma_sync_sg_for_device(dev, &sg, 1, dir);
-}
-
struct ion_vma_list {
struct list_head list;
struct vm_area_struct *vma;
};
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
- struct device *dev,
- enum dma_data_direction dir)
-{
- struct ion_vma_list *vma_list;
- int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
- int i;
-
- pr_debug("%s: syncing for device %s\n", __func__,
- dev ? dev_name(dev) : "null");
-
- if (!ion_buffer_fault_user_mappings(buffer))
- return;
-
- mutex_lock(&buffer->lock);
- for (i = 0; i < pages; i++) {
- struct page *page = buffer->pages[i];
-
- if (ion_buffer_page_is_dirty(page))
- ion_pages_sync_for_device(dev, ion_buffer_page(page),
- PAGE_SIZE, dir);
-
- ion_buffer_page_clean(buffer->pages + i);
- }
- list_for_each_entry(vma_list, &buffer->vmas, list) {
- struct vm_area_struct *vma = vma_list->vma;
-
- zap_page_range(vma, vma->vm_start, vma->vm_end - vma->vm_start,
- NULL);
- }
- mutex_unlock(&buffer->lock);
-}
-
static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct ion_buffer *buffer = vma->vm_private_data;
@@ -1135,30 +1079,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
}
EXPORT_SYMBOL(ion_import_dma_buf_fd);
-int ion_sync_for_device(struct ion_client *client, int fd)
-{
- struct dma_buf *dmabuf;
- struct ion_buffer *buffer;
-
- dmabuf = dma_buf_get(fd);
- if (IS_ERR(dmabuf))
- return PTR_ERR(dmabuf);
-
- /* if this memory came from ion */
- if (dmabuf->ops != &dma_buf_ops) {
- pr_err("%s: can not sync dmabuf from another exporter\n",
- __func__);
- dma_buf_put(dmabuf);
- return -EINVAL;
- }
- buffer = dmabuf->priv;
-
- dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
- buffer->sg_table->nents, DMA_BIDIRECTIONAL);
- dma_buf_put(dmabuf);
- return 0;
-}
-
int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
{
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
index 93dafb4..3b4bff5 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -45,7 +45,6 @@ struct ion_buffer;
* @name: used for debug purposes
* @base: base address of heap in physical memory if applicable
* @size: size of the heap in bytes if applicable
- * @align: required alignment in physical memory if applicable
* @priv: private info passed from the board file
*
* Provided by the board file.
@@ -93,8 +92,6 @@ void ion_client_destroy(struct ion_client *client);
* ion_alloc - allocate ion memory
* @client: the client
* @len: size of the allocation
- * @align: requested allocation alignment, lots of hardware blocks
- * have alignment requirements of some kind
* @heap_id_mask: mask of heaps to allocate from, if multiple bits are set
* heaps will be tried in order from highest to lowest
* id
@@ -106,7 +103,7 @@ void ion_client_destroy(struct ion_client *client);
* an opaque handle to it.
*/
struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
- size_t align, unsigned int heap_id_mask,
+ unsigned int heap_id_mask,
unsigned int flags);
/**
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c b/drivers/staging/android/ion/ion_carveout_heap.c
index a8ea973..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -34,8 +34,7 @@ struct ion_carveout_heap {
};
static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
- unsigned long size,
- unsigned long align)
+ unsigned long size)
{
struct ion_carveout_heap *carveout_heap =
container_of(heap, struct ion_carveout_heap, heap);
@@ -60,16 +59,13 @@ static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
static int ion_carveout_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
- unsigned long size, unsigned long align,
+ unsigned long size,
unsigned long flags)
{
struct sg_table *table;
ion_phys_addr_t paddr;
int ret;
- if (align > PAGE_SIZE)
- return -EINVAL;
-
table = kmalloc(sizeof(*table), GFP_KERNEL);
if (!table)
return -ENOMEM;
@@ -77,7 +73,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
if (ret)
goto err_free;
- paddr = ion_carveout_allocate(heap, size, align);
+ paddr = ion_carveout_allocate(heap, size);
if (paddr == ION_CARVEOUT_ALLOCATE_FAIL) {
ret = -ENOMEM;
goto err_free_table;
@@ -104,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
ion_heap_buffer_zero(buffer);
- if (ion_buffer_cached(buffer))
- dma_sync_sg_for_device(NULL, table->sgl, table->nents,
- DMA_BIDIRECTIONAL);
-
ion_carveout_free(heap, paddr, buffer->size);
sg_free_table(table);
kfree(table);
@@ -132,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data)
page = pfn_to_page(PFN_DOWN(heap_data->base));
size = heap_data->size;
- ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
-
ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c b/drivers/staging/android/ion/ion_chunk_heap.c
index 70495dc..46e13f6 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -35,7 +35,7 @@ struct ion_chunk_heap {
static int ion_chunk_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
- unsigned long size, unsigned long align,
+ unsigned long size,
unsigned long flags)
{
struct ion_chunk_heap *chunk_heap =
@@ -46,9 +46,6 @@ static int ion_chunk_heap_allocate(struct ion_heap *heap,
unsigned long num_chunks;
unsigned long allocated_size;
- if (align > chunk_heap->chunk_size)
- return -EINVAL;
-
allocated_size = ALIGN(size, chunk_heap->chunk_size);
num_chunks = allocated_size / chunk_heap->chunk_size;
@@ -104,10 +101,6 @@ static void ion_chunk_heap_free(struct ion_buffer *buffer)
ion_heap_buffer_zero(buffer);
- if (ion_buffer_cached(buffer))
- dma_sync_sg_for_device(NULL, table->sgl, table->nents,
- DMA_BIDIRECTIONAL);
-
for_each_sg(table->sgl, sg, table->nents, i) {
gen_pool_free(chunk_heap->pool, page_to_phys(sg_page(sg)),
sg->length);
@@ -135,8 +128,6 @@ struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
page = pfn_to_page(PFN_DOWN(heap_data->base));
size = heap_data->size;
- ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
-
ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
if (ret)
return ERR_PTR(ret);
@@ -160,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
chunk_heap->heap.ops = &chunk_heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
- pr_debug("%s: base %lu size %zu align %ld\n", __func__,
- chunk_heap->base, heap_data->size, heap_data->align);
+ pr_debug("%s: base %lu size %zu \n", __func__,
+ chunk_heap->base, heap_data->size);
return &chunk_heap->heap;
diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
index 6c7de74..81780ed 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -42,7 +42,7 @@ struct ion_cma_buffer_info {
/* ION CMA heap operations functions */
static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
- unsigned long len, unsigned long align,
+ unsigned long len,
unsigned long flags)
{
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
@@ -54,9 +54,6 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
if (buffer->flags & ION_FLAG_CACHED)
return -EINVAL;
- if (align > PAGE_SIZE)
- return -EINVAL;
-
info = kzalloc(sizeof(struct ion_cma_buffer_info), GFP_KERNEL);
if (!info)
return ION_CMA_ALLOCATE_FAILED;
diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
index aea89c1..532eda7 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -30,9 +30,6 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
if (!page)
return NULL;
- if (!pool->cached)
- ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
- DMA_BIDIRECTIONAL);
return page;
}
diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index 3c3b324..869a948 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -44,7 +44,6 @@
* @lock: protects the buffers cnt fields
* @kmap_cnt: number of times the buffer is mapped to the kernel
* @vaddr: the kernel mapping if kmap_cnt is not zero
- * @dmap_cnt: number of times the buffer is mapped for dma
* @sg_table: the sg table for the buffer if dmap_cnt is not zero
* @pages: flat array of pages in the buffer -- used by fault
* handler and only valid for buffers that are faulted in
@@ -70,7 +69,6 @@ struct ion_buffer {
struct mutex lock;
int kmap_cnt;
void *vaddr;
- int dmap_cnt;
struct sg_table *sg_table;
struct page **pages;
struct list_head vmas;
@@ -174,7 +172,7 @@ struct ion_handle {
struct ion_heap_ops {
int (*allocate)(struct ion_heap *heap,
struct ion_buffer *buffer, unsigned long len,
- unsigned long align, unsigned long flags);
+ unsigned long flags);
void (*free)(struct ion_buffer *buffer);
void * (*map_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
void (*unmap_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index 3ebbb75..a33331b 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -75,9 +75,6 @@ static struct page *alloc_buffer_page(struct ion_system_heap *heap,
page = ion_page_pool_alloc(pool);
- if (cached)
- ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
- DMA_BIDIRECTIONAL);
return page;
}
@@ -129,7 +126,7 @@ static struct page *alloc_largest_available(struct ion_system_heap *heap,
static int ion_system_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
- unsigned long size, unsigned long align,
+ unsigned long size,
unsigned long flags)
{
struct ion_system_heap *sys_heap = container_of(heap,
@@ -143,9 +140,6 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
unsigned long size_remaining = PAGE_ALIGN(size);
unsigned int max_order = orders[0];
- if (align > PAGE_SIZE)
- return -EINVAL;
-
if (size / PAGE_SIZE > totalram_pages / 2)
return -ENOMEM;
@@ -372,7 +366,6 @@ void ion_system_heap_destroy(struct ion_heap *heap)
static int ion_system_contig_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
unsigned long len,
- unsigned long align,
unsigned long flags)
{
int order = get_order(len);
@@ -381,9 +374,6 @@ static int ion_system_contig_heap_allocate(struct ion_heap *heap,
unsigned long i;
int ret;
- if (align > (PAGE_SIZE << order))
- return -EINVAL;
-
page = alloc_pages(low_order_gfp_flags, order);
if (!page)
return -ENOMEM;
@@ -408,8 +398,6 @@ static int ion_system_contig_heap_allocate(struct ion_heap *heap,
buffer->sg_table = table;
- ion_pages_sync_for_device(NULL, page, len, DMA_BIDIRECTIONAL);
-
return 0;
free_table:
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/4] Ion caching (yet again) proof of concept
From: Laura Abbott @ 2016-12-15 0:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I've been (once again) looking at alternate caching models for Ion. Part of
this work is also to make Ion fit better in to the dma_buf model.
Ion is a bit unusual for dma_buf. Most drivers that support dma_buf have two
parts: exporting buffers that a driver allocates and importing buffers
allocated elsewhere for use by the driver. Ion is basically designed to export
only and not import buffers from other drivers (the need for import is also
on my TODO list) Even more unusual, there is no actual 'driver' to map into.
Ion currently does nothing except pass back the same sg_table each time without
calling dma_map.
The description of the .map_dma_buf function in dma_buf_ops
* @map_dma_buf: returns list of scatter pages allocated, increases usecount
* of the buffer. Requires atleast one attach to be called
* before. Returned sg list should already be mapped into
* _device_ address space. This call may sleep. May also return
* -EINTR. Should return -EINVAL if attach hasn't been called yet.
So Ion is definitely not doing this correctly. This ties back into correcting
the caching model. If we call dma_map_sg/dma_unmap_sg with begin_cpu_access,
this should be enough to allow the caches to always be properly synchronized
and means we can drop the various dma_sync calls floating around. This is going
to violate one of the big fat comments in ion_buffer_create
/*
* this will set up dma addresses for the sglist -- it is not
* technically correct as per the dma api -- a specific
* device isn't really taking ownership here. However, in practice on
* our systems the only dma_address space is physical addresses.
* Additionally, we can't afford the overhead of invalidating every
* allocation via dma_map_sg. The implicit contract here is that
* memory coming from the heaps is ready for dma, ie if it has a
* cached mapping that mapping has been invalidated
*/
for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
sg_dma_address(sg) = sg_phys(sg);
sg_dma_len(sg) = sg->length;
}
The overhead of invalidating is a valid concern. I'm hoping that the
architecture has either evolved such that this won't be a problem or we can
figure out some clever use of DMA_ATTR_SKIP_CPU_SYNC.
As part of this, I'm considering dropping the fault synchronization. If we have
explicit use begin_cpu_access and use of the dma_buf sync ioctls, I don't think
it should be necessary.
I have a 'pre-RFC' tree at https://pagure.io/kernel-ion/branch/ion_cache_proof_dec14
Yes, the patches are not bisectable and there is more to be done. These have
been compile tested only and haven't been hooked up to anything to actually run
(another actually big TODO). I'm mostly looking for feedback if this looks like
the right direction and if there are going to be major problems with this
approach. I don't actually anticipate this getting merged into
drivers/staging/android/ion but this is the easiest way to continue discussion.
Thanks,
Laura
Laura Abbott (4):
staging: android: ion: Some cleanup
staging: android: ion: Duplicate sg_table
staging: android: ion: Remove page faulting support
staging: android: ion: Call dma_map_sg for syncing and mapping
drivers/staging/android/ion/ion-ioctl.c | 6 -
drivers/staging/android/ion/ion.c | 251 ++++++++----------------
drivers/staging/android/ion/ion.h | 5 +-
drivers/staging/android/ion/ion_carveout_heap.c | 16 +-
drivers/staging/android/ion/ion_chunk_heap.c | 15 +-
drivers/staging/android/ion/ion_cma_heap.c | 5 +-
drivers/staging/android/ion/ion_page_pool.c | 3 -
drivers/staging/android/ion/ion_priv.h | 4 +-
drivers/staging/android/ion/ion_system_heap.c | 14 +-
9 files changed, 90 insertions(+), 229 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: dts: tegra124-apalis: Correct license text
From: Alexandre Belloni @ 2016-12-15 0:04 UTC (permalink / raw)
To: linux-arm-kernel
The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/tegra124-apalis-emc.dtsi | 10 +++++-----
arch/arm/boot/dts/tegra124-apalis-eval.dts | 10 +++++-----
arch/arm/boot/dts/tegra124-apalis.dtsi | 10 +++++-----
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
index ca2c3a557895..0e3013ff6c63 100644
--- a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
@@ -10,17 +10,17 @@
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
- * This file is distributed in the hope that it will be useful
+ * This file 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.
*
- * Or, alternatively
+ * Or, alternatively,
*
* b) Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
@@ -29,11 +29,11 @@
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts b/arch/arm/boot/dts/tegra124-apalis-eval.dts
index 653044a44f0d..dec449f7b574 100644
--- a/arch/arm/boot/dts/tegra124-apalis-eval.dts
+++ b/arch/arm/boot/dts/tegra124-apalis-eval.dts
@@ -10,17 +10,17 @@
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
- * This file is distributed in the hope that it will be useful
+ * This file 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.
*
- * Or, alternatively
+ * Or, alternatively,
*
* b) Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
@@ -29,11 +29,11 @@
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index e7a73db17613..fa96556f5a45 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -10,17 +10,17 @@
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
- * This file is distributed in the hope that it will be useful
+ * This file 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.
*
- * Or, alternatively
+ * Or, alternatively,
*
* b) Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
@@ -29,11 +29,11 @@
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
--
2.10.2
^ permalink raw reply related
* [PATCH] arm: Adjust memory boundaries after reservations
From: Russell King - ARM Linux @ 2016-12-14 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481681501-13788-1-git-send-email-labbott@redhat.com>
On Tue, Dec 13, 2016 at 06:11:41PM -0800, Laura Abbott wrote:
> The poorly named sanity_check_meminfo is responsible for setting up the
> boundary for lowmem/highmem. This needs to be set up before memblock
> reservations can occur. At the time memblock reservations can occur,
> memory can also be removed from the system. This can throw off the
> calculation of the lowmem/highmem boundary. On some systems this may be
> harmless, on others this may result in incorrect ranges being passed to
> the main memory allocator. Correct this by recalcuating the
> lowmem/highmem boundary after all reservations have been made.
> As part of this, rename sanity_check_meminfo to actually refect what the
> function is doing.
I think this needs more explanation - after reading that, I'm left
wondering wtf is going on...
Let's say that the memory boundary was at 0x30000000. Memory from
0x2f000000 to 0x30000000 is stolen, which reserves it and removes
it from the available memory.
Since the memory is no longer available, why would the stolen range
end up being passed to the main memory allocator?
How is this any different from the boot loader omitting the memory
range in the first place?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 37/37] ARM: dts: vfxxx: Correct license text
From: Alexandre Belloni @ 2016-12-14 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235746.7108-1-alexandre.belloni@free-electrons.com>
The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.
Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Bill Pringlemeir <bpringlemeir@nbsps.com>
Cc: Cory Tusar <cory.tusar@pid1solutions.com>
Cc: Frank Li <Frank.Li@freescale.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Sanchayan Maity <maitysanchayan@gmail.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/vfxxx.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2c13ec696ac5..d7d77779bb3a 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -10,17 +10,17 @@
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
- * This file is distributed in the hope that it will be useful
+ * This file 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.
*
- * Or, alternatively
+ * Or, alternatively,
*
* b) Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
@@ -29,11 +29,11 @@
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
--
2.10.2
^ permalink raw reply related
* [PATCH 36/37] ARM: dts: vf610-zii-dev-rev-b: Correct license text
From: Alexandre Belloni @ 2016-12-14 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235746.7108-1-alexandre.belloni@free-electrons.com>
The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Cory Tusar <cory.tusar@pid1solutions.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 5c1fcab4a6f7..8c77f0c72c5e 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -13,17 +13,17 @@
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
- * This file is distributed in the hope that it will be useful
+ * This file 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.
*
- * Or, alternatively
+ * Or, alternatively,
*
* b) Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
@@ -32,11 +32,11 @@
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
--
2.10.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox