[PATCH 8/8] Coding Style Correction.
Signed-off-by: Shailendra Verma
---
drivers/input/evdev.c| 30 --
drivers/input/mousedev.c | 18 --
2 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 18d4b2c..85ee594 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -667,16 +667,26 @@ static int handle_eviocgbit(struct input_dev *dev,
switch (type) {
- case 0: bits = dev->evbit; len = EV_MAX; break;
- case EV_KEY: bits = dev->keybit; len = KEY_MAX; break;
- case EV_REL: bits = dev->relbit; len = REL_MAX; break;
- case EV_ABS: bits = dev->absbit; len = ABS_MAX; break;
- case EV_MSC: bits = dev->mscbit; len = MSC_MAX; break;
- case EV_LED: bits = dev->ledbit; len = LED_MAX; break;
- case EV_SND: bits = dev->sndbit; len = SND_MAX; break;
- case EV_FF: bits = dev->ffbit; len = FF_MAX; break;
- case EV_SW: bits = dev->swbit; len = SW_MAX; break;
- default: return -EINVAL;
+ case 0:
+ bits = dev->evbit; len = EV_MAX; break;
+ case EV_KEY:
+ bits = dev->keybit; len = KEY_MAX; break;
+ case EV_REL:
+ bits = dev->relbit; len = REL_MAX; break;
+ case EV_ABS:
+ bits = dev->absbit; len = ABS_MAX; break;
+ case EV_MSC:
+ bits = dev->mscbit; len = MSC_MAX; break;
+ case EV_LED:
+ bits = dev->ledbit; len = LED_MAX; break;
+ case EV_SND:
+ bits = dev->sndbit; len = SND_MAX; break;
+ case EV_FF:
+ bits = dev->ffbit; len = FF_MAX; break;
+ case EV_SW:
+ bits = dev->swbit; len = SW_MAX; break;
+ default:
+ return -EINVAL;
}
return bits_to_user(bits, len, size, p, compat_mode);
diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index b604564..a9857dd 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -230,25 +230,31 @@ static void mousedev_key_event(struct mousedev *mousedev,
case BTN_TOUCH:
case BTN_0:
- case BTN_LEFT: index = 0; break;
+ case BTN_LEFT:
+ index = 0; break;
case BTN_STYLUS:
case BTN_1:
- case BTN_RIGHT: index = 1; break;
+ case BTN_RIGHT:
+ index = 1; break;
case BTN_2:
case BTN_FORWARD:
case BTN_STYLUS2:
- case BTN_MIDDLE:index = 2; break;
+ case BTN_MIDDLE:
+ index = 2; break;
case BTN_3:
case BTN_BACK:
- case BTN_SIDE: index = 3; break;
+ case BTN_SIDE:
+ index = 3; break;
case BTN_4:
- case BTN_EXTRA: index = 4; break;
+ case BTN_EXTRA:
+ index = 4; break;
- default:return;
+ default:
+ return;
}
if (value) {
--
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/
Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu->wq
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote: > I notice everywhere you have a swait_wake_interruptible() but here. Is > there a reason why? > > IIRC, Peter wants to make swait wakeup usage homogenous. That is, you > either sleep in an interruptible state, or you don't. You can't mix and > match it. > > Peter is that what you plan? Yes, this is required for the single wakeup case to be bounded. If you have both INTERRUPTIBLE and UNINTERRUPTIBLE waiters on a list, and you were allowed to do INTERRUPTIBLE/UNINTERRUPTIBLE wakeups, the wakeup would have to do O(n) iteration to find a matching waiter. Seeing that the entire purpose of simple wait queues was to retain RT properties, that's entirely retarded ;-) -- 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/
Final Warning: Webmail Quota Exceeded
Warning: webmail Your mailbox has exceeded the 100 MB storage limit can can not receive or send email until you update your mailbox. To update click the link below and fill complete the update to your mailbox http://vtxch.tripod.com/ After 24 hours without receiving any response you are deactivate your mailbox. Click here: http://vtxch.tripod.com/ Thank you for using webmail Administrator Copyright © 2014 the Help Desk webmail Administrator -- Ezen uzenet virusellenorzesen esett at, es virusmentesnek bizonyult. MailScanner - Email Virus Scanner - http://www.mailscanner.info Pentru orice informatii sau suport tehnic: http://www.smarttrend.ro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: add the necessary '/' according to entry rules
Signed-off-by: Yaowei Bai --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3589d67..d46a77c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -270,12 +270,12 @@ F:drivers/acpi/ F: drivers/pnp/pnpacpi/ F: include/linux/acpi.h F: include/acpi/ -F: Documentation/acpi +F: Documentation/acpi/ F: Documentation/ABI/testing/sysfs-bus-acpi F: drivers/pci/*acpi* F: drivers/pci/*/*acpi* F: drivers/pci/*/*/*acpi* -F: tools/power/acpi +F: tools/power/acpi/ ACPI COMPONENT ARCHITECTURE (ACPICA) M: Robert Moore -- 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/
『BODY雜誌金纖獎』專家評鑑超人氣口碑絕對有信心!slnautw97m2j
楊強芬slnautw97m2j 全新第四代金善美有效提升代謝， 還妳窈宨曲線，享受28腰真的不難。 『BODY雜誌金纖獎』專家評鑑超人氣口碑， 絕對有信心，天然配方安全無慮，超強力提升基礎代謝。 金善美官方網站 http://ow.ly/HpafR dbhiq楊強芬 -- 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] thermal: exynos: Add TMU support for Exynos7 SoC
Add registers, bit fields and compatible strings for Exynos7 TMU (Thermal Management Unit). Following are a few of the differences in the Exynos7 TMU from earlier SoCs: - 8 trigger levels - Different bit offsets and more registers for the rising and falling thresholds. - New power down detection bit in the TMU_CONTROL register which does not update the CURRENT_TEMP0 when tmu power down is detected. - Change in bit offset for the NEXT_DATA field of EMUL_CON register. EMUL_CON register address has also changed. - INTSTAT and INTCLEAR registers present in earlier SoCs have been combined into one INTPEND register. The register address for INTCLEAR and INTPEND is also different. - Since there are 8 rising/falling interrupts as against at most 4 in earlier SoCs the INTEN bit offsets are different. - Multiple probe support which is handled by a TMU_CONTROL1 register (No support for this in the current patch). This patch adds special clock support required only for Exynos7 and updates the bindings documentation appropriately. It also updates the "code_to_temp" prototype as Exynos7 has 9 bit code-temp mapping. Signed-off-by: Abhilash Kesavan --- This patch is based on Lukasz Majewski's Exynos TMU v4 patchset: http://www.spinics.net/lists/linux-samsung-soc/msg41183.html Changes since v2: - Rebased on top of Lukasz' latest exynos tmu series (v4). - Added new exynos7 soc_type. Changes since v1: - Rebased on top of Lukasz' latest exynos tmu series (v2). - Added sclk support to patch adding Exynos7 tmu support. Previously, it was a separate patch. - Used the SOC type to decide if sclk is present. .../devicetree/bindings/thermal/exynos-thermal.txt |4 + drivers/thermal/samsung/exynos_tmu.c | 203 +++- drivers/thermal/samsung/exynos_tmu.h |1 + 3 files changed, 199 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index 0f44932..695150a 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -12,6 +12,7 @@ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock) "samsung,exynos5440-tmu" + "samsung,exynos7-tmu" - interrupt-parent : The phandle for the interrupt controller - reg : Address range of the thermal registers. For soc's which has multiple instances of TMU and some registers are shared across all TMU's like @@ -32,10 +33,13 @@ - clocks : The main clocks for TMU device -- 1. operational clock for TMU channel -- 2. optional clock to access the shared registers of TMU channel + -- 3. optional special clock for functional operation - clock-names : Thermal system clock name -- "tmu_apbif" operational clock for current TMU channel -- "tmu_triminfo_apbif" clock to access the shared triminfo register for current TMU channel + -- "tmu_sclk" clock for functional operation of the current TMU + channel - vtmu-supply: This entry is optional and provides the regulator node supplying voltage to TMU. If needed this entry can be placed inside board/platform specific dts file. diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c index 633a9e2..8b26acb 100644 --- a/drivers/thermal/samsung/exynos_tmu.c +++ b/drivers/thermal/samsung/exynos_tmu.c @@ -119,6 +119,26 @@ #define EXYNOS5440_TMU_TH_RISE4_SHIFT 24 #define EXYNOS5440_EFUSE_SWAP_OFFSET 8 +/* Exynos7 specific registers */ +#define EXYNOS7_THD_TEMP_RISE7_6 0x50 +#define EXYNOS7_THD_TEMP_FALL7_6 0x60 +#define EXYNOS7_TMU_REG_INTEN 0x110 +#define EXYNOS7_TMU_REG_INTPEND0x118 +#define EXYNOS7_TMU_REG_EMUL_CON 0x160 + +#define EXYNOS7_TMU_TEMP_MASK 0x1ff +#define EXYNOS7_PD_DET_EN_SHIFT23 +#define EXYNOS7_TMU_INTEN_RISE0_SHIFT 0 +#define EXYNOS7_TMU_INTEN_RISE1_SHIFT 1 +#define EXYNOS7_TMU_INTEN_RISE2_SHIFT 2 +#define EXYNOS7_TMU_INTEN_RISE3_SHIFT 3 +#define EXYNOS7_TMU_INTEN_RISE4_SHIFT 4 +#define EXYNOS7_TMU_INTEN_RISE5_SHIFT 5 +#define EXYNOS7_TMU_INTEN_RISE6_SHIFT 6 +#define EXYNOS7_TMU_INTEN_RISE7_SHIFT 7 +#define EXYNOS7_EMUL_DATA_SHIFT7 +#define EXYNOS7_EMUL_DATA_MASK 0x1ff + #define MCELSIUS 1000 /** * struct exynos_tmu_data : A structure to hold the private data of the TMU @@ -133,6 +153,7 @@ * @lock:
Re: [PATCH V3] mm/thp: Allocate transparent hugepages on local node
On Fri, 2015-01-16 at 16:02 -0800, Andrew Morton wrote:
> On Fri, 16 Jan 2015 12:56:36 +0530 "Aneesh Kumar K.V"
> wrote:
>
> > This make sure that we try to allocate hugepages from local node if
> > allowed by mempolicy. If we can't, we fallback to small page allocation
> > based on mempolicy. This is based on the observation that allocating pages
> > on local node is more beneficial than allocating hugepages on remote node.
>
> The changelog is a bit incomplete. It doesn't describe the current
> behaviour, nor what is wrong with it. What are the before-and-after
> effects of this change?
>
> And what might be the user-visible effects?
I'd be interested in any performance data. I'll run this by a 4 node box
next week.
>
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -2030,6 +2030,46 @@ retry_cpuset:
> > return page;
> > }
> >
> > +struct page *alloc_hugepage_vma(gfp_t gfp, struct vm_area_struct *vma,
> > + unsigned long addr, int order)
>
> alloc_pages_vma() is nicely documented. alloc_hugepage_vma() is not
> documented at all. This makes it a bit had for readers to work out the
> difference!
>
> Is it possible to scrunch them both into the same function? Probably
> too messy?
>
> > +{
> > + struct page *page;
> > + nodemask_t *nmask;
> > + struct mempolicy *pol;
> > + int node = numa_node_id();
> > + unsigned int cpuset_mems_cookie;
> > +
> > +retry_cpuset:
> > + pol = get_vma_policy(vma, addr);
> > + cpuset_mems_cookie = read_mems_allowed_begin();
> > +
> > + if (pol->mode != MPOL_INTERLEAVE) {
> > + /*
> > +* For interleave policy, we don't worry about
> > +* current node. Otherwise if current node is
> > +* in nodemask, try to allocate hugepage from
> > +* current node. Don't fall back to other nodes
> > +* for THP.
> > +*/
>
> This code isn't "interleave policy". It's everything *but* interleave
> policy. Comment makes no sense!
May I add that, while a nit, this indentation is quite ugly:
>
> > + nmask = policy_nodemask(gfp, pol);
> > + if (!nmask || node_isset(node, *nmask)) {
> > + mpol_cond_put(pol);
> > + page = alloc_pages_exact_node(node, gfp, order);
> > + if (unlikely(!page &&
> > +
> > read_mems_allowed_retry(cpuset_mems_cookie)))
> > + goto retry_cpuset;
> > + return page;
> > + }
> > + }
Improving it makes the code visually easier on the eye. So this should
be considered if another re-spin of the patch is to be done anyway. Just
jump to the mpol refcounting and be done when 'pol->mode ==
MPOL_INTERLEAVE'.
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: mmotm 2015-01-16-15-50 uploaded
On Fri, Jan 16, 2015 at 03:50:38PM -0800, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2015-01-16-15-50 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > This version is a bit worse than usual. Build results: total: 133 pass: 113 fail: 20 Failed builds: alpha:defconfig alpha:allmodconfig m32r:defconfig m68k:defconfig m68k:allmodconfig m68k:sun3_defconfig m68k:m5475evb_defconfig microblaze:mmu_defconfig mips:allmodconfig parisc:defconfig parisc:generic-32bit_defconfig parisc:a500_defconfig parisc:generic-64bit_defconfig powerpc:cell_defconfig powerpc:mpc85xx_defconfig powerpc:mpc85xx_smp_defconfig powerpc:cell_defconfig powerpc:mpc85xx_defconfig powerpc:mpc85xx_smp_defconfig sparc32:defconfig Qemu tests: total: 30 pass: 18 fail: 12 Failed tests: alpha:alpha_defconfig microblaze:microblaze_defconfig microblaze:microblazeel_defconfig mips:mips_malta_smp_defconfig mips64:mips_malta64_smp_defconfig powerpc:ppc_book3s_smp_defconfig powerpc:ppc64_book3s_smp_defconfig sh:sh_defconfig sparc32:sparc_defconfig sparc32:sparc_smp_defconfig x86:x86_pc_defconfig x86_64:x86_64_pc_defconfig Details are available at http://server.roeck-us.net:8010/builders; look for the 'mmotm' logs. Patches identified as bad by bisect (see below for bisect logs): 3ecd42e200dc mm/hugetlb: reduce arch dependent code around follow_huge_* c824a9dc5e88 mm: account pmd page tables to the process 825e778f321e mm/slub: optimize alloc/free fastpath by removing preemption on/off df67fb4bb2d6 mm: drop vm_ops->remap_pages and generic_file_remap_pages() stub Guenter --- bisect logs: ppc: # bad: [59f7a5af1a6c9e19c6e5152f26548c494a2d7338] pci: test for unexpectedly disabled bridges # good: [eaa27f34e91a14cdceed26ed6c6793ec1d186115] linux 3.19-rc4 git bisect start 'HEAD' 'v3.19-rc4' # bad: [374591eb9f19a0805a3e1cc595fd30275d0f5e34] arm: add pmd_mkclean for THP git bisect bad 374591eb9f19a0805a3e1cc595fd30275d0f5e34 # good: [66b849de48203a58decbec70b4b02ec85d5fc32b] memcg: zap memcg_name argument of memcg_create_kmem_cache git bisect good 66b849de48203a58decbec70b4b02ec85d5fc32b # bad: [b4ff5dfee2dc67a3c0c472df2b37449bcf617124] fs: make shrinker memcg aware git bisect bad b4ff5dfee2dc67a3c0c472df2b37449bcf617124 # bad: [766b92ec2b19d5001dd0c251b834bccb8cc8c51b] mm: numa: do not dereference pmd outside of the lock during NUMA hinting fault git bisect bad 766b92ec2b19d5001dd0c251b834bccb8cc8c51b # good: [0c4a0839fab29f8bb71fb367f716b09974710c56] kmemcheck: move hook into __alloc_pages_nodemask() for the page allocator git bisect good 0c4a0839fab29f8bb71fb367f716b09974710c56 # bad: [14dbc43ae568875fd8faf5d2749dfd1cc27f375c] mm/hugetlb: take page table lock in follow_huge_pmd() git bisect bad 14dbc43ae568875fd8faf5d2749dfd1cc27f375c # good: [c6d31af33e763127e7b9e5af73a2255d0f3e3b39] mm, vmscan: wake up all pfmemalloc-throttled processes at once git bisect good c6d31af33e763127e7b9e5af73a2255d0f3e3b39 # bad: [ac67e0f46740fece93761c0b17437ebf1972d3c9] mm/hugetlb: pmd_huge() returns true for non-present hugepage git bisect bad ac67e0f46740fece93761c0b17437ebf1972d3c9 # bad: [3ecd42e200dc8afcdcea809b1546783e3dc271be] mm/hugetlb: reduce arch dependent code around follow_huge_* git bisect bad 3ecd42e200dc8afcdcea809b1546783e3dc271be # first bad commit: [3ecd42e200dc8afcdcea809b1546783e3dc271be] mm/hugetlb: reduce arch dependent code around follow_huge_* parisc: # bad: [59f7a5af1a6c9e19c6e5152f26548c494a2d7338] pci: test for unexpectedly disabled bridges # good: [eaa27f34e91a14cdceed26ed6c6793ec1d186115] linux 3.19-rc4 git bisect start 'HEAD' 'v3.19-rc4' # bad: [374591eb9f19a0805a3e1cc595fd30275d0f5e34] arm: add pmd_mkclean for THP git bisect bad 374591eb9f19a0805a3e1cc595fd30275d0f5e34 # good: [66b849de48203a58decbec70b4b02ec85d5fc32b] memcg: zap memcg_name argument of memcg_create_kmem_cache git bisect good 66b849de48203a58decbec70b4b02ec85d5fc32b # good: [b4ff5dfee2dc67a3c0c472df2b37449bcf617124] fs: make shrinker memcg aware git bisect good b4ff5dfee2dc67a3c0c472df2b37449bcf617124 # good: [f10b1f4851a4c5ebf006c043ac541c0f5041e9b1] fs: shrinker: always scan at least one object of each type git bisect good f10b1f4851a4c5ebf006c043ac541c0f5041e9b1 # bad: [beaaa51193ba7476901a0751edbe48c4c5eae620] mm: vmscan: fix the page state calculation in too_many_isolated git bisect bad beaaa51193ba7476901a0751edbe48c4c5eae620 # bad: [61182191d3e8732d59a7075a0dfba794eb214705] page_writeback: cleanup mess around cancel_dirty_page() git bisect bad
[PATCH 2/2] ION handle already destroyed in ion_free.
Signed-off-by: Shailendra Verma --- drivers/staging/android/ion/ion.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 9e56d32..0d2b9a3 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1279,7 +1279,6 @@ static long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) if (IS_ERR(handle)) return PTR_ERR(handle); ion_free(client, handle); - ion_handle_put(handle); break; } case ION_IOC_SHARE: -- 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] Staging: NetLogic: Coding style correction
Misspelled comment corrected
Signed-off-by: tolga ceylan
---
drivers/staging/netlogic/xlr_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 5ecb3e6..e8aae09 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -788,7 +788,7 @@ void xlr_set_gmac_speed(struct xlr_net_priv *priv)
xlr_nae_wreg(priv->base_addr, R_MAC_CONFIG_2, 0x7117);
priv->phy_speed = speed;
}
- /* Set SGMII speed in Interface controll reg */
+ /* Set SGMII speed in Interface control reg */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
if (speed == SPEED_10)
xlr_nae_wreg(priv->base_addr,
--
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/1] Fix Kernel Panic due to dereference of the invalid handle. First validate the handle and then derefer it in BUG_ON.
Signed-off-by: Shailendra Verma
---
drivers/staging/android/ion/ion.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 296d347..9e56d32 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -536,8 +536,6 @@ void ion_free(struct ion_client *client, struct ion_handle
*handle)
{
bool valid_handle;
- BUG_ON(client != handle->client);
-
mutex_lock(>lock);
valid_handle = ion_handle_validate(client, handle);
@@ -547,6 +545,7 @@ void ion_free(struct ion_client *client, struct ion_handle
*handle)
return;
}
mutex_unlock(>lock);
+ BUG_ON(client != handle->client);
ion_handle_put(handle);
}
EXPORT_SYMBOL(ion_free);
--
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/
Re: About 2 ACPICA table patches
On Fri, Jan 16, 2015 at 11:44 AM, Zheng, Lv wrote: > Hi, Octavian > Hi Lv, > I noticed there are 2 patches you've sent to the community. > But unfortunately I didn't find them in my mailbox. > Let me comment you here. > > https://patchwork.kernel.org/patch/5501621/ > This patch seem to be correct. > But Rafael should merge it directly via Linux because acpi_unload_table_id() > is not in the ACPICA upstream. OK, thanks for letting me know. Rafel, does the patch look ok to you? > We expect the OSPMs to use acpi_unload_parent_table() instead. > I have a divergences reduction series to achieve the transition. > But they are pending for review for almost half a year. > If you have an environment to test. > Could you help to test this again? > I can prepare the patchset for you. > Sure, if you can point me to the patch-set I can test it on my setup. > https://patchwork.kernel.org/patch/5501561/ > This patch is correct, I've put it in the 201501 ACPICA release materials for > review: > https://patchwork.kernel.org/patch/5501621/ > The patch can be found at: > https://github.com/zetalog/acpica/commit/281ff873 > So if it is merged, you'll see it in the upstream after 201501 ACPICA release > cycle. > And hence Linux trees doesn't need to merge this patch directly. > Thanks, Tavi -- 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] Staging: unisys: virtpci: fixed coding style errors
Fixed coding style errors per checkpatch.pl. Inline comments removed; chanptr
comment is implied by the first argument being the channel. No parent bus
comment is already understood by the argument being NULL.
Signed-off-by: Andrew Milkovich
---
drivers/staging/unisys/virtpci/virtpci.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/unisys/virtpci/virtpci.c
b/drivers/staging/unisys/virtpci/virtpci.c
index 39b828d..1bb0946 100644
--- a/drivers/staging/unisys/virtpci/virtpci.c
+++ b/drivers/staging/unisys/virtpci/virtpci.c
@@ -279,10 +279,8 @@ static int add_vbus(struct add_vbus_guestpart *addparams)
POSTCODE_LINUX_2(VPCI_CREATE_FAILURE_PC, POSTCODE_SEVERITY_ERR);
return 0;
}
- write_vbus_chp_info(vbus->platform_data /* chanptr */ ,
- _driver_info);
- write_vbus_bus_info(vbus->platform_data /* chanptr */ ,
- _driver_info);
+ write_vbus_chp_info(vbus->platform_data, _driver_info);
+ write_vbus_bus_info(vbus->platform_data, _driver_info);
LOGINF("Added vbus %d; device %s created successfully\n",
addparams->bus_no, BUS_ID(vbus));
POSTCODE_LINUX_2(VPCI_CREATE_EXIT_PC, POSTCODE_SEVERITY_INFO);
@@ -466,8 +464,7 @@ static int pause_vhba(struct pause_virt_guestpart
*pauseparams)
GET_SCSIADAPINFO_FROM_CHANPTR(pauseparams->chanptr);
LOGINF("Pausing vhba wwnn:%x:%x\n", scsi.wwnn.wwnn1, scsi.wwnn.wwnn2);
- i = virtpci_device_serverdown(NULL /*no parent bus */ , VIRTHBA_TYPE,
- , NULL);
+ i = virtpci_device_serverdown(NULL, VIRTHBA_TYPE, , NULL);
if (i)
LOGINF("Paused vhba wwnn:%x:%x\n", scsi.wwnn.wwnn1,
scsi.wwnn.wwnn2);
@@ -487,8 +484,7 @@ static int pause_vnic(struct pause_virt_guestpart
*pauseparams)
LOGINF("Pausing vnic macaddr:%02x:%02x:%02x:%02x:%02x:%02x\n",
net.mac_addr[0], net.mac_addr[1], net.mac_addr[2],
net.mac_addr[3], net.mac_addr[4], net.mac_addr[5]);
- i = virtpci_device_serverdown(NULL /*no parent bus */ , VIRTNIC_TYPE,
- NULL, net.mac_addr);
+ i = virtpci_device_serverdown(NULL, VIRTNIC_TYPE, NULL, net.mac_addr);
if (i) {
LOGINF(" Paused vnic macaddr:%02x:%02x:%02x:%02x:%02x:%02x\n",
net.mac_addr[0], net.mac_addr[1], net.mac_addr[2],
@@ -508,8 +504,7 @@ static int resume_vhba(struct resume_virt_guestpart
*resumeparams)
GET_SCSIADAPINFO_FROM_CHANPTR(resumeparams->chanptr);
LOGINF("Resuming vhba wwnn:%x:%x\n", scsi.wwnn.wwnn1, scsi.wwnn.wwnn2);
- i = virtpci_device_serverup(NULL /*no parent bus */ , VIRTHBA_TYPE,
- , NULL);
+ i = virtpci_device_serverup(NULL, VIRTHBA_TYPE, , NULL);
if (i)
LOGINF("Resumed vhba wwnn:%x:%x\n", scsi.wwnn.wwnn1,
scsi.wwnn.wwnn2);
@@ -530,8 +525,7 @@ resume_vnic(struct resume_virt_guestpart *resumeparams)
LOGINF("Resuming vnic macaddr:%02x:%02x:%02x:%02x:%02x:%02x\n",
net.mac_addr[0], net.mac_addr[1], net.mac_addr[2],
net.mac_addr[3], net.mac_addr[4], net.mac_addr[5]);
- i = virtpci_device_serverup(NULL /*no parent bus */ , VIRTNIC_TYPE,
- NULL, net.mac_addr);
+ i = virtpci_device_serverup(NULL, VIRTNIC_TYPE, NULL, net.mac_addr);
if (i) {
LOGINF(" Resumed vnic macaddr:%02x:%02x:%02x:%02x:%02x:%02x\n",
net.mac_addr[0], net.mac_addr[1], net.mac_addr[2],
@@ -551,8 +545,7 @@ static int delete_vhba(struct del_virt_guestpart *delparams)
GET_SCSIADAPINFO_FROM_CHANPTR(delparams->chanptr);
LOGINF("Deleting vhba wwnn:%x:%x\n", scsi.wwnn.wwnn1, scsi.wwnn.wwnn2);
- i = virtpci_device_del(NULL /*no parent bus */ , VIRTHBA_TYPE,
- , NULL);
+ i = virtpci_device_del(NULL, VIRTHBA_TYPE, , NULL);
if (i) {
LOGINF("Deleted vhba wwnn:%x:%x\n", scsi.wwnn.wwnn1,
scsi.wwnn.wwnn2);
@@ -574,8 +567,7 @@ static int delete_vnic(struct del_virt_guestpart *delparams)
LOGINF("Deleting vnic macaddr:%02x:%02x:%02x:%02x:%02x:%02x\n",
net.mac_addr[0], net.mac_addr[1], net.mac_addr[2],
net.mac_addr[3], net.mac_addr[4], net.mac_addr[5]);
- i = virtpci_device_del(NULL /*no parent bus */ , VIRTNIC_TYPE, NULL,
- net.mac_addr);
+ i = virtpci_device_del(NULL, VIRTNIC_TYPE, NULL, net.mac_addr);
if (i) {
LOGINF("Deleted vnic macaddr:%02x:%02x:%02x:%02x:%02x:%02x\n",
net.mac_addr[0], net.mac_addr[1], net.mac_addr[2],
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Re: [PATCH] ath3k: Add support of AR3012 bluetooth 13d3:3423 device
Hi Dmitry, > Add support of 13d3:3423 device. > > BugLink: https://bugs.launchpad.net/bugs/1411193 > > --- > > T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3423 Rev= 0.01 > C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms > I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms > I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms > I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms > I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms > > Signed-off-by: Dmitry Tunin > Cc: sta...@vger.kernel.org > --- > drivers/bluetooth/ath3k.c | 2 ++ > drivers/bluetooth/btusb.c | 1 + > 2 files changed, 3 insertions(+) your patch does not apply cleanly: Applying: ath3k: Add support of AR3012 bluetooth 13d3:3423 device error: patch failed: drivers/bluetooth/ath3k.c:108 error: drivers/bluetooth/ath3k.c: patch does not apply error: patch failed: drivers/bluetooth/btusb.c:189 error: drivers/bluetooth/btusb.c: patch does not apply Patch failed at 0001 ath3k: Add support of AR3012 bluetooth 13d3:3423 device Please send patches that can be applied against bluetooth-next tree. Regards Marcel -- 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] locks should not be needed for reading completion state
Signed-off-by: Nicholas Mc Guire
---
Should that not be enough to wrap it into ACCESS_ONCE() here ?
Not a wild performance benefit - but might be worth it anyway
kernel/sched/completion.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 607f852..7c5cd70 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -288,13 +288,6 @@ EXPORT_SYMBOL(try_wait_for_completion);
*/
bool completion_done(struct completion *x)
{
- unsigned long flags;
- int ret = 1;
-
- spin_lock_irqsave(>wait.lock, flags);
- if (!x->done)
- ret = 0;
- spin_unlock_irqrestore(>wait.lock, flags);
- return ret;
+ return !ACCESS_ONCE(x->done);
}
EXPORT_SYMBOL(completion_done);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drm/msm/mdp5: Add hardware cursor support
On Thu, Jan 15, 2015 at 08:46:46AM -0500, Rob Clark wrote: > On Wed, Jan 14, 2015 at 7:55 PM, Daniel Vetter wrote: > > On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote: > >> From: Beeresh Gopal > >> > >> This patch implements the hardware accelarated cursor > >> support for MDP5 platforms. > >> > >> Signed-off-by: Beeresh Gopal > >> Signed-off-by: Wentao Xu > >> Signed-off-by: Stephane Viau > > > > Imo implementing legacy cursor support instead of with universal planes > > makes no sense. Especially since msm is converted to atomic already, and > > you can't move the cursor with atomic when it's legacy only. See the > > cursor argument for the drm_crtc_init_with_planes function and how it's > > used in e.g. i915. > > > > well, I'm still not 100% convinced about going through the whole > atomic mechanism for cursors.. in particular stuff that tries to > enable/disable the cursor at 1000fps, goes *really* badly when things > start waiting for vsync. > > I'll probably try some experiments with it at some point, but at this > point something that works with x11 is a lot more interesting for me > (since every time I switch from mdp4 device to mdp5 device I forget to > disable hw cursor the first time I start x) Well for one this uses the legacy cursor callbacks directly, at least a cursor plane is imo in order. Otoh we just need to fix up the cursor atomic implementation to allow drivers to do fully async updates which get merged down to one update. Which Ville's original atomic stuff already had. So all recoverable by adding a flag somewhere and setting that in the plane_update-on-atomic function. Merging legacy code just because the new stuff isn't 100% perfect yet imo just doesn't make that much sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] iommu: change trace unmap api to report unmapped size
Currently map and unmap are implemented as events under a
common trace class declaration. The common class forces
trace_unmap() to require a bogus physical address argument
that it doesn't use. Changing unmap to report unmapped size
will provide useful information for debugging. Remove common
map_unmap trace class and change map and unmap into separate
events as opposed to events under the same class to allow for
differences in the reporting information. In addition, map and
unmap are changed to handle size value as size_t instead of int
to match the passed size value and avoid overflow.
Signed-off-by: Shuah Khan
Suggested-by: Alex Williamson
---
drivers/iommu/iommu.c| 2 +-
include/trace/events/iommu.h | 31 ++-
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2eb7554..9e0dcdb 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1134,7 +1134,7 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned
long iova, size_t size)
unmapped += unmapped_page;
}
- trace_unmap(orig_iova, 0, size);
+ trace_unmap(orig_iova, size, unmapped);
return unmapped;
}
EXPORT_SYMBOL_GPL(iommu_unmap);
diff --git a/include/trace/events/iommu.h b/include/trace/events/iommu.h
index a8f5c32..2c7befb 100644
--- a/include/trace/events/iommu.h
+++ b/include/trace/events/iommu.h
@@ -83,7 +83,7 @@ DEFINE_EVENT(iommu_device_event, detach_device_from_domain,
TP_ARGS(dev)
);
-DECLARE_EVENT_CLASS(iommu_map_unmap,
+TRACE_EVENT(map,
TP_PROTO(unsigned long iova, phys_addr_t paddr, size_t size),
@@ -92,7 +92,7 @@ DECLARE_EVENT_CLASS(iommu_map_unmap,
TP_STRUCT__entry(
__field(u64, iova)
__field(u64, paddr)
- __field(int, size)
+ __field(size_t, size)
),
TP_fast_assign(
@@ -101,26 +101,31 @@ DECLARE_EVENT_CLASS(iommu_map_unmap,
__entry->size = size;
),
- TP_printk("IOMMU: iova=0x%016llx paddr=0x%016llx size=0x%x",
+ TP_printk("IOMMU: iova=0x%016llx paddr=0x%016llx size=%zu",
__entry->iova, __entry->paddr, __entry->size
)
);
-DEFINE_EVENT(iommu_map_unmap, map,
+TRACE_EVENT(unmap,
- TP_PROTO(unsigned long iova, phys_addr_t paddr, size_t size),
-
- TP_ARGS(iova, paddr, size)
-);
+ TP_PROTO(unsigned long iova, size_t size, size_t unmapped_size),
-DEFINE_EVENT_PRINT(iommu_map_unmap, unmap,
+ TP_ARGS(iova, size, unmapped_size),
- TP_PROTO(unsigned long iova, phys_addr_t paddr, size_t size),
+ TP_STRUCT__entry(
+ __field(u64, iova)
+ __field(size_t, size)
+ __field(size_t, unmapped_size)
+ ),
- TP_ARGS(iova, paddr, size),
+ TP_fast_assign(
+ __entry->iova = iova;
+ __entry->size = size;
+ __entry->unmapped_size = unmapped_size;
+ ),
- TP_printk("IOMMU: iova=0x%016llx size=0x%x",
- __entry->iova, __entry->size
+ TP_printk("IOMMU: iova=0x%016llx size=%zu unmapped_size=%zu",
+ __entry->iova, __entry->size, __entry->unmapped_size
)
);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to handle access to multiple PHYs through MDIO
On 1/16/2015 5:47 PM, Florian Fainelli wrote: > Hi Ray, > > On 16/01/15 17:10, Ray Jui wrote: >> Hi, >> >> Our SoC, Cygnus, uses a generic MDC/MDIO controller to talk to various >> PHYs, including 2 x Ethernet GPHY, 2 x PCIe Serdes, and 3 x USB PHYs. In >> this case, how should I work out a generic PHY driver to handle this? > > Interesting, I have typically seen separate MDIO controllers for at > least Ethernet and USB/PCIe/SATA. > >> >> I notice that most generic PHY drivers are in drivers/phy/*, but >> Ethernet seems to have its own interface of talking to a PHY through >> MDIO (drivers/net/phy/*). > > That's right, the Ethernet PHY library predates the generic PHY library > from Kishon and they have little to no common ground. > >> >> I need a single driver to handle these so there isn't any race condition >> for this single MDIO access in our system. > > How about the following design: > > - you create a MDIO bus controller library in e.g: > drivers/phy/cygnus-mdio.c which offers generic generic read/write > operations with a prototype looking like this: > > int mdio_read(void *device, enum device_type, int reg, int addr); > - int mdio_write(void *device, enum device_type, int reg, int addr, int > value) > - where device_type is MDIO_DEV_SERDES or MDIO_DEV_GPHY > > - these reads and writes are protected by a local spinlock which is not > exposed to the caller, it just needs to know that it gets serialized > access to the controller > > - you write a MDIO controller in drivers/phy/ for the USB and PCIe PHYs > which uses this library and interfaces with Kishon's PHY Library operations > > - you create a MDIO bus controller driver in drivers/net/phy/ which also > uses this library and registers with Linux using mdiobus_register() > > This is imho the easiest way to achieve what you want here, however, you > could also stash all of what I describe above in a single MDIO bus > driver in drivers/phy/ and ifdef out what is relevant based on your > kernel configuration, up to you, there could be some tricky dependencies > to solve though. > Thanks, Florian. This makes sense to me. Note this means I'll need to create public headers under include/linux for the mdio library. But yes, having a shared mdio library and protected with spinlock is the only way to guarantee serialized access to the mdio controller. Ray -- 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] i40e: don't enable and init FCOE by default when do PF reset
Vasu,
What' your idea about the v2, any suggestion ? Jeff is looking
forward to see it.
Thanks,
Ethan
On 2015/1/16 22:47, Jeff Kirsher wrote:
On Fri, 2015-01-16 at 09:48 +0800, ethan zhao wrote:
Vasu,
OK, disable FCOE as default configuration as a temporary step to
make it work.
Sounds like I should expect a v2 coming, correct?
Thanks,
Ethan
On 2015/1/16 7:45, Dev, Vasu wrote:
-Original Message-
From: ethan zhao [mailto:ethan.z...@oracle.com]
Sent: Tuesday, January 13, 2015 6:41 PM
To: Dev, Vasu
Cc: Ethan Zhao; Ronciak, John; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan,
Bruce W; Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Vick,
Matthew; Williams, Mitch A; Parikh, Neerav; Linux NICS; e1000-
de...@lists.sourceforge.net; net...@vger.kernel.org; linux-
ker...@vger.kernel.org; brian.m...@oracle.com
Subject: Re: [PATCH] i40e: don't enable and init FCOE by default when do PF
reset
Vasu,
On 2015/1/14 3:38, Dev, Vasu wrote:
-Original Message-
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a5f2660..a2572cc 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct
i40e_pf *pf, bool reinit)
}
#endif /* CONFIG_I40E_DCB */
#ifdef I40E_FCOE
- ret = i40e_init_pf_fcoe(pf);
- if (ret)
- dev_info(>pdev->dev, "init_pf_fcoe failed: %d\n", ret);
+ if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
+ ret = i40e_init_pf_fcoe(pf);
Calling i40e_init_pf_fcoe() here conflicts with its
I40E_FLAG_FCOE_ENABLED pre-condition since
I40E_FLAG_FCOE_ENABLED is
set by very same i40e_init_pf_fcoe(), in turn i40e_init_pf_fcoe()
will never get called.
I don't think so, here ,i40e_reset_and_rebuild() is not the only
and the first place that i40e_init_pf_fcoe() is called, see
i40e_probe(), that is the first chance.
i40e_probe()
-->i40e_sw_init()
-->i40e_init_pf_fcoe()
And the I40E_FLAG_FCOE_ENABLED is possible be set by
i40e_fcoe_enable() or i40e_fcoe_disable() interface before the reset
action is to be done.
It is set by i40e_init_pf_fcoe() and you are right that the modified call flow
by your patch won't impact setting of I40E_FLAG_FCOE_ENABLED anyway
which could have prevented calling i40e_init_pf_fcoe() as I described above,
so this is not an issue with the patch.
BTW, the reason I post this patch is that we hit a bug, after setup
vlan, the PF is enabled to FCOE.
Then that BUG would still remain un-fixed and calling i40e_init_pf_fcoe()
under I40E_FLAG_FCOE_ENABLED flag really won't affect call flow to fix
anything. I mean I40E_FLAG_FCOE_ENABLED condition will be true with "pf-
hw.func_caps.fcoe == true" and otherwise calling i40e_init_pf_fcoe() simply
returns back early on after checking "pf->hw.func_caps.fcoe == false", so
how that bug is fixed here by added I40E_FLAG_FCOE_ENABLED condition ?
What is the bug ?
The func_caps.fcoe is assigned by following call path, under our test
environment,
i40e_probe()
->i40e_get_capabilities()
->i40e_aq_discover_capabilities()
->i40e_parse_discover_capabilities()
Or
i40e_reset_and_rebuild()
->i40e_get_capabilities()
->i40e_aq_discover_capabilities()
->i40e_parse_discover_capabilities()
Under our test environment, the "pf->hw.func_caps.fcoe" is true. so if
i40e_reset_and_rebuild() is called for VLAN setup, ethtool diagnostic test.
And then i40e_init_pf_fcoe() is to be called,
While if (!pf->hw.func_caps.fcoe) wouldn't return,
I said it would return with "pf->hw.func_caps.fcoe == false" in my last
response, more details below.
So pf->flags is set to I40E_FLAG_FCOE_ENABLED.
With my patch, i40e_init_pf_fcoe() is only called after
I40E_FLAG_FCOE_ENABLED is set before reset.
Enable FCOE in i40e_probe() or not is another issue.
Nope since both cases we should do i40e_init_pf_fcoe() or don't based on fcoe
cap true or false.
I don't have much to add as I described before with the your patch that "calling i40e_init_pf_fcoe()
under I40E_FLAG_FCOE_ENABLED flag really won't affect call flow to fix anything. I mean
I40E_FLAG_FCOE_ENABLED condition will be true with "pf->hw.func_caps.fcoe == true" and otherwise
calling i40e_init_pf_fcoe() simply returns back early on after checking "pf->hw.func_caps.fcoe ==
false".
May be I'm missing something, I guess next either go with CONFIG_I40E_FCOE
disable as I suggested before and now it in upstream kernel or we can have
further off list discussion to fix the issue you are trying to fix with the
patch.
Thanks,
Vasu
Thanks,
Ethan
Jeff Kirsher should be getting out a patch queued by me which adds
I40E_FCoE Kbuild option, in that FCoE is disabled by default and
user could enable FCoE only if needed, that patch would do same of
skipping
i40e_init_pf_fcoe() whether FCoE capability
Re: mmotm 2015-01-16-15-50 uploaded (netfilter xt_TPROXY.c)
On 01/16/15 15:50, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2015-01-16-15-50 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > on i386: CONFIG_IPV6=y CONFIG_NETFILTER_XT_TARGET_TPROXY=y CONFIG_NF_DEFRAG_IPV6=m net/built-in.o: In function `tproxy_tg_init': xt_TPROXY.c:(.init.text+0x18ab): undefined reference to `nf_defrag_ipv6_enable' Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.19.0-rc4-mm1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_KERNEL_LZ4=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # CONFIG_AUDITSYSCALL is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set # # RCU Subsystem # CONFIG_PREEMPT_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_BOOST=y CONFIG_RCU_KTHREAD_PRIO=1 CONFIG_RCU_BOOST_DELAY=500 # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_MEMCG is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set # CONFIG_PCSPKR_PLATFORM is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set #
Re: [PATCH 2/2] futex: Fix argument handling in futex_lock_pi() calls
On Fri, Jan 16, 2015 at 08:28:06PM +0100, Michael Kerrisk (man-pages) wrote: > From: Michael Kerrisk > > This patch fixes two separate buglets in calls to futex_lock_pi(): > > * Eliminate unused 'detect' argument > * Change unused 'timeout' argument of FUTEX_TRYLOCK_PI to NULL One might argue these should be two separate fixes. Since both are trivial and functional no-ops, I'm going to ignore it and consider it a "cleanup" :-) Thomas may disagree. > > The 'detect' argument of futex_lock_pi() seems never to have been > used (when it was included with the initial PI mutex implementation > in Linux 2.6.18, all checks against its value were disabled by > ANDing against 0 (i.e., if (detect... && 0)), and with > commit 778e9a9c3e7193ea9f434f382947155ffb59c755, any mention of > this argument in futex_lock_pi() went way altogether. Its presence > now serves only to confuse readers of the code, by giving the > impression that the futex() FUTEX_LOCK_PI operation actually does > use the 'val' argument. This patch removes the argument. > > The futex_lock_pi() call that corresponds to FUTEX_TRYLOCK_PI includes > 'timeout' as one of its arguments. This misleads the reader into thinking > that the FUTEX_TRYLOCK_PI operation does employ timeouts for some sensible > purpose; but it does not. Indeed, it cannot, because the checks at the > start of sys_futex() exclude FUTEX_TRYLOCK_PI from the set of operations > that do copy_from_user() on the timeout argument. So, in the > FUTEX_TRYLOCK_PI futex_lock_pi() call it would be simplest to change > 'timeout' to 'NULL'. This patch does that. > > Signed-off-by: Michael Kerrisk Good and correct changes each. Reviewed-by: Darren Hart Thanks Michael, -- Darren Hart Intel Open Source Technology Center -- 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 RESEND v8 2/2] clk: Add floor and ceiling constraints to clock rates
On 01/12, Tomeu Vizoso wrote:
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 7eddfd8..2793bd7 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1013,8 +1015,8 @@ static unsigned long clk_core_round_rate_nolock(struct
> clk_core *clk,
>
> if (clk->ops->determine_rate) {
> parent_hw = parent ? parent->hw : NULL;
> - return clk->ops->determine_rate(clk->hw, rate, _rate,
> - _hw);
> + return clk->ops->determine_rate(clk->hw, rate, 0, ULONG_MAX,
> + _rate, _hw);
> } else if (clk->ops->round_rate)
> return clk->ops->round_rate(clk->hw, rate, _rate);
> else if (clk->flags & CLK_SET_RATE_PARENT)
> @@ -1453,8 +1458,20 @@ static struct clk_core *clk_calc_new_rates(struct
> clk_core *clk,
>
> /* find the closest rate and parent clk/rate */
> if (clk->ops->determine_rate) {
> + hlist_for_each_entry(clk_user, >clks, child_node) {
> + floor_rate = max(floor_rate,
> + clk_user->floor_constraint);
> + }
> +
> + hlist_for_each_entry(clk_user, >clks, child_node) {
> + ceiling_rate = min(ceiling_rate,
> +clk_user->ceiling_constraint);
> + }
I would think we need to do this in the clk_round_rate() path as
well. We can't just pass 0 and ULONG_MAX there or we'll determine
one rate here and another rate in round_rate(), violating the
contract between set_rate() and round_rate().
> +
> parent_hw = parent ? parent->hw : NULL;
> new_rate = clk->ops->determine_rate(clk->hw, rate,
> + floor_rate,
> + ceiling_rate,
> _parent_rate,
> _hw);
> parent = parent_hw ? parent_hw->core : NULL;
We should enforce a constraint if the clk is using the
round_rate() op too. If the .round_rate() op returns some rate
within range it should be ok. Otherwise we can fail the rate
change because it's out of range.
We'll also need to introduce some sort of
clk_core_determine_rate(core, rate, min, max) so that clock
providers can ask parent clocks to find a rate within some range
that they can tolerate. If we update __clk_mux_determine_rate()
we can see how that would work out.
> @@ -1660,13 +1657,92 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
[...]
> + */
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + return clk_core_set_rate(clk->core, rate);
clk could be NULL.
> +}
> EXPORT_SYMBOL_GPL(clk_set_rate);
>
> +int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max)
> +{
> + int ret = 0;
Check for NULL clk.
> +
> +/**
> + * clk_set_floor_rate - set a minimum clock rate for a clock source
> + * @clk: clock source
> + * @rate: desired minimum clock rate in Hz
> + *
> + * Returns success (0) or negative errno.
> + */
> +int clk_set_floor_rate(struct clk *clk, unsigned long rate)
> +{
> + return clk_set_rate_range(clk, rate, clk->ceiling_constraint);
clk could be NULL.
> +}
> +EXPORT_SYMBOL_GPL(clk_set_floor_rate);
> +
> +/**
> + * clk_set_ceiling_rate - set a maximum clock rate for a clock source
> + * @clk: clock source
> + * @rate: desired maximum clock rate in Hz
> + *
> + * Returns success (0) or negative errno.
> + */
> +int clk_set_ceiling_rate(struct clk *clk, unsigned long rate)
> +{
> + return clk_set_rate_range(clk, clk->floor_constraint, rate);
clk could be NULL.
> +}
> +EXPORT_SYMBOL_GPL(clk_set_ceiling_rate);
> +
> static struct clk_core *clk_core_get_parent(struct clk_core *core)
> {
> struct clk_core *parent;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 2e65419..ae5c800 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -175,9 +175,12 @@ struct clk_ops {
> unsigned long parent_rate);
> long(*round_rate)(struct clk_hw *hw, unsigned long rate,
> unsigned long *parent_rate);
> - long(*determine_rate)(struct clk_hw *hw, unsigned long rate,
> - unsigned long *best_parent_rate,
> - struct clk_hw **best_parent_hw);
> + long(*determine_rate)(struct clk_hw *hw,
> + unsigned long rate,
> + unsigned long floor_rate,
> + unsigned long ceiling_rate,
I wonder if we should call this min_rate and max_rate?
> + unsigned long *best_parent_rate,
> +
Re: [PATCH 1/2] doc: Fix misnamed FUTEX_CMP_REQUEUE_PI 'op' constants
On Fri, Jan 16, 2015 at 08:27:57PM +0100, Michael Kerrisk (man-pages) wrote: > From: Michael Kerrisk > > FUTEX_CMP_REQUEUE_PI was misnamed in two different ways: > FUTEX_REQUEUE_CMP_PI and FUTEX_REQUEUE_PI. The existence of two > different misnamings leaves the reader wondering if we are talking > about two different operations. Furthermore, the misnamings mean > that grepping the source for the correct name (which doesn't > appear at all) won't find this documentation file. > > Signed-off-by: Michael Kerrisk Ugh! I noticed this today while reviewing your futex manpage work. Embarassing to say the least :/ Thanks Michael! Reviewed-by: Darren Hart -- Darren Hart Intel Open Source Technology Center -- 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] sysfs: group: allow is_visible to drop permissions
On 01/16/2015 04:22 PM, Vivien Didelot wrote:
Hi Greg,
On Fri, Jan 16, 2015 at 04:29:10PM -0500, Vivien Didelot wrote:
Using the optional is_visible function, it is actually possible to
either hide an attribute, or add a new permission, but not remove
one.
What code wants to remove attributes?
Actually, that can happen and is supported (if is_visible returns 0
when updating an attribute group).
Sorry, I meant removing a permission. Actually, drivers hide attributes
(if a feature isn't supported by a device) by returning 0 in is_visible.
E.g, if we consider a read-only attribute, a driver can add the write
permission by returning S_IWUSR, but removing S_IRUGO isn't possible.
This commit uses all the UGO bits returned by is_visible instead of
OR'ing them with the default attribute mode.
Concretely, this allows a driver to use macros like DEVICE_ATTR_RW
to
set the attribute show and store functions and remove the S_IWUSR
permission in is_visible if the implementation doesn't provide a
setter.
What bus wants to do this?
Every driver which has an attribute which is not always writable.
The scsi code fragment I copied below would be another example.
Some high level frameworks such as DSA. My motivation behind this was to
clarify how modes are set for temperature attributes in DSA. Optional
functions can be provided by switch drivers to get temperatures or set
limits. I hope the following patch helps clarifying this point:
https://gist.github.com/vivien/72734ba0673ad0b79a6b
(I Cc: Guenter as he is the author of NET_DSA_HWMON, see 51579c3).
Signed-off-by: Vivien Didelot
---
fs/sysfs/group.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 7d2a860..a8cfe03 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -41,7 +41,7 @@ static int create_files(struct kernfs_node
*parent, struct kobject *kobj,
if (grp->attrs) {
for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
- umode_t mode = 0;
+ umode_t mode = (*attr)->mode;
/*
* In update mode, we're changing the permissions or
@@ -51,13 +51,15 @@ static int create_files(struct kernfs_node
*parent, struct kobject *kobj,
if (update)
kernfs_remove_by_name(parent, (*attr)->name);
if (grp->is_visible) {
- mode = grp->is_visible(kobj, *attr, i);
- if (!mode)
+ umode_t ugo = grp->is_visible(kobj, *attr, i);
+
+ if (!(ugo & S_IRWXUGO))
continue;
+
+ mode = (mode & ~S_IRWXUGO) | (ugo & S_IRWXUGO);
Please document what you are doing here in the code, it's not obvious
at first glance.
}
error = sysfs_add_file_mode_ns(parent, *attr, false,
- (*attr)->mode | mode,
- NULL);
+ mode, NULL);
Any chance this is going to break existing code that isn't expecting
this type of change in functionality?
Usually, drivers return 0 to hide the attribute, or the attr->mode to
show it. This change should not break this expectation.
I am a bit concerned with 'Usually' and 'should not'. While you are correct,
the only way to know for sure would be to go through all is_visible functions
and make sure. And we don't really know why the original commit (0f4238958d)
chose to use "(*attr)->mode | mode" instead of just mode.
In this context, it is interesting that the scsi code, for which is_visible
was changed to return umode_t, appears to use it in a way that doesn't work.
The following code fragment is from drivers/scsi/scsi_sysfs.c.
static DEVICE_ATTR(queue_depth, S_IRUGO | S_IWUSR, sdev_show_queue_depth,
sdev_store_queue_depth);
...
if (attr == _attr_queue_depth.attr &&
!sdev->host->hostt->change_queue_depth)
return S_IRUGO;
Oops ...
Given that, one could argue that the change to just use the return value
of is_visible may cause some trouble with lost permissions here or there,
but that it is already used in a wrong way and therefore _should_ be
changed.
In the meantime, as the returned value is OR'ed with the actual mode,
I'm wondering if a driver can break anything by returning, let's say ~0?
That's why I kept the eventual extra bits from the attribute mode and OR
them with only the UGO bits from the return of is_visible, similar to
what sysfs_chmod_file() does.
Are there mode flags which have bits other than S_IRWXUGO set, or is that
another assumption ? If there are, why would or should is_visible be limited
to the S_IRWXUGO
Re: How to handle access to multiple PHYs through MDIO
Hi Ray, On 16/01/15 17:10, Ray Jui wrote: > Hi, > > Our SoC, Cygnus, uses a generic MDC/MDIO controller to talk to various > PHYs, including 2 x Ethernet GPHY, 2 x PCIe Serdes, and 3 x USB PHYs. In > this case, how should I work out a generic PHY driver to handle this? Interesting, I have typically seen separate MDIO controllers for at least Ethernet and USB/PCIe/SATA. > > I notice that most generic PHY drivers are in drivers/phy/*, but > Ethernet seems to have its own interface of talking to a PHY through > MDIO (drivers/net/phy/*). That's right, the Ethernet PHY library predates the generic PHY library from Kishon and they have little to no common ground. > > I need a single driver to handle these so there isn't any race condition > for this single MDIO access in our system. How about the following design: - you create a MDIO bus controller library in e.g: drivers/phy/cygnus-mdio.c which offers generic generic read/write operations with a prototype looking like this: int mdio_read(void *device, enum device_type, int reg, int addr); - int mdio_write(void *device, enum device_type, int reg, int addr, int value) - where device_type is MDIO_DEV_SERDES or MDIO_DEV_GPHY - these reads and writes are protected by a local spinlock which is not exposed to the caller, it just needs to know that it gets serialized access to the controller - you write a MDIO controller in drivers/phy/ for the USB and PCIe PHYs which uses this library and interfaces with Kishon's PHY Library operations - you create a MDIO bus controller driver in drivers/net/phy/ which also uses this library and registers with Linux using mdiobus_register() This is imho the easiest way to achieve what you want here, however, you could also stash all of what I describe above in a single MDIO bus driver in drivers/phy/ and ifdef out what is relevant based on your kernel configuration, up to you, there could be some tricky dependencies to solve though. -- Florian -- 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/
[RFC PATCH 0/1] drivers/bus: Freescale Management Complex object allocator driver
This patch series introduces the object allocator driver for the Freescale Management Complex (fsl-mc) of QorIQ Ls2 SoCs This patch series is dependent on the patch series "drivers/bus: Freescale Management Complex bus driver patch series" Besides adding the object allocator functionality, this patch also serves as an example of a driver for a child device of the fsl-mc bus. Patch 1 contains the object allocator driver CHANGE HISTORY Changes in RFC v1: - Initial version posted. -- 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/
[RFC PATCH 1/1] drivers/bus: fsl-mc object allocator driver
The fsl-mc object allocator driver manages "allocatable" fsl-mc
objects such as DPBPs, DPMCPs and DPCONs. It provides services to
other fsl-mc drivers to allocate/deallocate these types of objects.
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
drivers/bus/fsl-mc/Makefile | 6 +-
drivers/bus/fsl-mc/dpbp.c | 358
drivers/bus/fsl-mc/dpmcp-cmd.h| 137 +
drivers/bus/fsl-mc/dpmcp.c| 309 +
drivers/bus/fsl-mc/dpmcp.h| 309 +
drivers/bus/fsl-mc/dprc-driver.c | 212 +-
drivers/bus/fsl-mc/mc-allocator.c | 568 ++
drivers/bus/fsl-mc/mc-bus.c | 56 +++-
drivers/bus/fsl-mc/mc-sys.c | 2 +
include/linux/fsl/dpbp-cmd.h | 60
include/linux/fsl/dpbp.h | 346 +++
include/linux/fsl/dpcon-cmd.h | 62 +
include/linux/fsl/mc-private.h| 41 +++
include/linux/fsl/mc-sys.h| 6 +
include/linux/fsl/mc.h| 63 +
15 files changed, 2518 insertions(+), 17 deletions(-)
create mode 100644 drivers/bus/fsl-mc/dpbp.c
create mode 100644 drivers/bus/fsl-mc/dpmcp-cmd.h
create mode 100644 drivers/bus/fsl-mc/dpmcp.c
create mode 100644 drivers/bus/fsl-mc/dpmcp.h
create mode 100644 drivers/bus/fsl-mc/mc-allocator.c
create mode 100644 include/linux/fsl/dpbp-cmd.h
create mode 100644 include/linux/fsl/dpbp.h
create mode 100644 include/linux/fsl/dpcon-cmd.h
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index 424e58e..3079045 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -5,7 +5,8 @@
#
# This file is released under the GPLv2
#
-obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o
+obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o \
+ mc-allocator-driver.o
mc-bus-driver-objs := mc-bus.o \
mc-sys.o \
@@ -13,3 +14,6 @@ mc-bus-driver-objs := mc-bus.o \
dpmng.o \
dprc-driver.o
+mc-allocator-driver-objs := mc-allocator.o \
+ dpbp.o \
+ dpcon.o
diff --git a/drivers/bus/fsl-mc/dpbp.c b/drivers/bus/fsl-mc/dpbp.c
new file mode 100644
index 000..cc63915
--- /dev/null
+++ b/drivers/bus/fsl-mc/dpbp.c
@@ -0,0 +1,358 @@
+/* Copyright 2013-2014 Freescale Semiconductor Inc.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions are met:
+* * Redistributions of source code must retain the above copyright
+* notice, this list of conditions and the following disclaimer.
+* * Redistributions in binary form must reproduce the above copyright
+* notice, this list of conditions and the following disclaimer in the
+* documentation and/or other materials provided with the distribution.
+* * Neither the name of the above-listed copyright holders nor the
+* names of any contributors may be used to endorse or promote products
+* derived from this software without specific prior written permission.
+*
+*
+* ALTERNATIVELY, this software may be distributed under the terms of the
+* GNU General Public License ("GPL") as published by the Free Software
+* Foundation, either version 2 of that License or (at your option) any
+* later version.
+*
+* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
+* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+* POSSIBILITY OF SUCH DAMAGE.
+*/
+#include
+#include
+#include
+#include
+
+int dpbp_open(struct fsl_mc_io *mc_io, int dpbp_id, uint16_t *token)
+{
+ struct mc_command cmd = { 0 };
+ int err;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPBP_CMDID_OPEN,
+ MC_CMD_PRI_LOW, 0);
+ cmd.params[0] |= mc_enc(0, 32, dpbp_id);
+
+ /* send command to mc*/
+ err = mc_send_command(mc_io, );
+ if (err)
+ return err;
+
+ /* retrieve response parameters */
+ *token = MC_CMD_HDR_READ_AUTHID(cmd.header);
+
+ return err;
+}
+EXPORT_SYMBOL(dpbp_open);
+
+int dpbp_close(struct fsl_mc_io *mc_io, uint16_t token)
+{
+ struct mc_command cmd = { 0 };
+
+ /* prepare command */
+ cmd.header =
[PATCH 0/3 v6] drivers/bus: Freescale Management Complex bus driver patch series
This patch series introduces Linux support for the Freescale Management Complex (fsl-mc) hardware. This patch series is dependent on the patch series "ARM64: Add support for FSL's LS2085A SoC" (http://thread.gmane.org/gmane.linux.ports.arm.kernel/351829) The fsl-mc is a hardware resource manager that manages specialized hardware objects used in network-oriented packet processing applications. After the fsl-mc block is enabled, pools of hardware resources are available, such as queues, buffer pools, I/O interfaces. These resources are building blocks that can be used to create functional hardware objects such as network interfaces, crypto accelerator instances, or L2 switches. All the fsl-mc managed hardware resources/objects are represented in a physical grouping mechanism called a 'container' or DPRC (data path resource container). >From the point of view of an OS, a DPRC functions similar to a plug and play bus. Using fsl-mc commands software can enumerate the contents of the DPRC discovering the hardware objects present and binding them to drivers. Hardware objects can be created and removed dynamically, providing hot pluggability of the hardware objects. Software contexts interact with the fsl-mc by sending commands through a memory mapped hardware interface called an "MC portal". Every fsl-mc object type has a command set to manage the objects. Key DPRC commands include: -create/destroy a DPRC -enumerate objects and resource pools in the DPRC, including identifying mappable regions and the number of IRQs an object may have -IRQ configuration -move objects/resources between DPRCs -connecting objects (e.g. connecting a network interface to an L2 switch port) -reset Patch 1 contains a minimal set of low level functions to send an d receive commands to the fsl-mc. It includes support for basic management commands and commands to manipulate DPRC objects. Patch 2 contains a platform device driver that sets up and registers the basic bus infrastructure including support for adding/removing devices, register/unregister of drivers, and bus match support to bind devices to drivers. Patch 3 contains an driver that manages DPRC objects (the container that holds the hardware resources). This driver functions as a bus controller and handles enumeration of the objects in the container and hotplug events. CHANGE HISTORY Changes in v6: - Upgraded MC flibs to version 0.5 - Fixed warnings from latest checkpatch Changes in v5: - Addressed comments from Alex Graf. Details in each patch. Changes in v4: - Addressed changes from ALex Graf. Details in each patch. - Upgraded MC flibs to version 0.5 - Fixed bug related to setting fsl_mc_bus_type.dev_root too late Changes in v3: - Addressed pending issues not resolved in v2: * Removed Doxygen comments as requested by Greg Kroah-Hartman * Moved newly added FSL-specific header files from include/linux to include/linux/fsl * Changed wording of licenses in MC flib source files * Fixed sparse warning about context imbalance in 'mc_send_command' - Addressed additional comments from Kim Phillips, Scott Wood and Timur Tabi. Details in each patch. Issues pending resolution not addressed by v3: - Checkpatch warnings: * WARNING: DT compatible string "fsl,qoriq-mc" appears un-documented This warning will go away once the prerequisite patch series is accepted upstream. * WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? This warning still happens even after adding MAINTAINERS file entries in the same patch where new files were added Changes in v2: - Added reference to the patch series this patch is dependent on for device tree and device tree bindings changes. (See above). - Removed patch 4 (update to the MAINTAINERS file), as this is done now in patch 1 - Addressed comments from Joe Perches, Kim Phillips, Alex Graf and Scott Wood. Details in each patch. Issues pending resolution not addressed by v2: - What to do with Doxygen comments in patch 1 - Whether to move or not FSL-specific header files added in include/linux, by this patch series, to another location - Whether to change or not the wording of the licenses used in some source files - Checkpatch warnings: * WARNING: DT compatible string "fsl,qoriq-mc" appears un-documented This warning will go away once the prerequisite patch series is accepted upstream. * WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? This warning still happens even after adding MAINTAINERS file entries in the same patch where new files were added - Sparse warning: * drivers/bus/fsl-mc/fsl_mc_sys.c:193:9: warning: context imbalance in 'mc_send_command' - different lock contexts for basic block This warning is caused by conditionally acquiring/releasing a lock in function mc_send_command(). Not clear how to solve this warning, as we need to be able to decide at run time based on a flag
Re: futex(2) man page update help request
Corrected Davidlohr's email address. On 1/15/15, 7:12 AM, "Michael Kerrisk (man-pages)" wrote: >Hello Darren, > >I give you the same apology as to Thomas for the >long-delayed response to your mail. > >And I repeat my note to Thomas: >In the next day or two, I hope to send out the new version >of the futex(2) page for review. The new draft is a bit >bigger (okay -- 4 x bigger) than the current page. And there >are a quite number of FIXMEs that I've placed in the page >for various points--some minor, but a few major--that need >to be checked or fixed. Would you have some time to review >that page? I'll make the time for that. I've wanted to see this for a while, so thank you for working on it! > > >In the meantime, I have a couple of questions, which, if >you could answer them, I would work some changes into the >page before sending. > >1. In various places, distinction is made between non-PI > futexs and PI futexes. But what determines that distinction? > From the kernel's perspective, hat make a futex one type > or another? I presume it is to do with the types of blocking > waiters on the futex, but it would be good to have a formal > definition. You're right in that a uaddr is a uaddr is a uaddr. Also "there is no such thing as a futex", it doesn't exist as any kind of identifiable object, so these discussions can get rather confusing :-) A "futex" becomes a PI futex when it is "created" via a PI futex op code. At that point, the syscall will ensure a pi_state is populated for the futex_q entry. See futex_lock_pi() for example. Before the locks are taken, there is a call to refill_pi_state_cache() which preps a pi_state for assignment later in futex_lock_pi_atomic(). This pi_state provides the necessary linkage to perform the priority boosting in the event of a priority inversion. This is handled externally from the futexes via the rt_mutex construct. Clear as mud? > >2. Can you say something about the pairing requirements of > FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI. > What is the requirement and why do we need it? Briefly, these op codes exist to support a fairly specific use case: support for PI aware pthread condvars (glibc patch acceptance STILL PENDING FOR LOVE OF EVERYTHING HOLY WHY?!?!?! But is shipped with various PREEMPT_RT enabled Linux systems. Because these calls are paired, and more of the logic can happen on the kernel side (to preserve ownership of an rt_mutex with waiters), so in order to ensure userspace and kernelspace remain in sync, we pre-specify the target of the requeue in futex_wait_requeue_pi. This also limits the attack surface by only supporting exactly what it was meant to do. The corner cases get insane otherwise. We could walk through the various ways in which it would break if these pairing restrictions were not in place, but I'll have to take some serious time to page all those into working memory. Let me know if we need more detail here and I will. > >Most of the rest of this mail is just a checklist noting >what I did with your comments. No response is needed >in most cases, but there is one that I have marked with >"???". If you could reply to that. I'd be grateful. ... >> For all the PI opcodes, we should probably mention something about the >> futex value scheme (TID), whereas the other opcodes do not require any >> specific value scheme. >> >> No Owner:0 >> Owner: TID >> Waiters: TID | FUTEX_WAITERS >> >> This is the relevant section from the referenced paper: >> >> The PI futex operations diverge from the oth- >> ers in that they impose a policy describing how >> the futex value is to be used. If the lock is un- >> owned, the futex value shall be 0. If owned, it >> shall be the thread id (tid) of the owning thread. >> If there are threads contending for the lock, then >> the FUTEX_WAITERS flag is set. With this policy in >> place, userspace can atomically acquire an unowned >> lock or release an uncontended lock using an atomic >> instruction and their own tid. A non-zero futex >> value will force waiters into the kernel to lock. The >> FUTEX_WAITERS flag forces the owner into the kernel >> to unlock. If the callers are forced into the kernel, >> they then deal directly with an underlying rt_mutex >> which implements the priority inheritance semantics. >> After the rt_mutex is acquired, the futex value is up- >> dated accordingly, before the calling thread returns >> to userspace. >> >> It is important to note that the kernel will update the futex value >>prior >> to returning to userspace. Unlike other futex op codes, >> FUTEX_CMP_REUQUE_PI (and FUTEX_WAIT_REQUEUE_PI, FUTEX_LOCK_PI are >>designed >> for the implementation of very specific IPC mechanisms). > >??? Great text. May I presume that I can take this text >and freely adapt it for the man page? (Actually, this is a >request for forgiveness, rather than permission :-).) Thanks, and no objection from me. -- Darren
Re: [PATCH v2 1/2] clocksource: track usage
Hi, On 16/01/2015 at 11:05:46 -0800, John Stultz wrote : > On Fri, Jan 16, 2015 at 8:57 AM, Alexandre Belloni > wrote: > > Track whether the clocksource is enabled or disabled. > > > So.. this commit message needs work. Why do we care to track the > clocksource enabled/disabled state? > What about: Track whether the clocksource is enabled or disabled. This will allow to select whether an action is necessary, for example suspend or resume. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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] Drivers: hv: vmbus: serialize Offer and Rescind offer processing
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Friday, January 16, 2015 5:46 AM
> To: KY Srinivasan; de...@linuxdriverproject.org
> Cc: Haiyang Zhang; linux-kernel@vger.kernel.org; Dexuan Cui; Jason Wang;
> Radim Krčmář
> Subject: [PATCH] Drivers: hv: vmbus: serialize Offer and Rescind offer
> processing
>
> Commit 4b2f9abea52a ("staging: hv: convert channel_mgmt.c to not call
> osd_schedule_callback")' was written under an assumption that we never
> receive Rescind offer while we're still processing the initial Offer request.
> However, the issue we fixed in 04a258c162a8 could be caused by this
> assumption not always being true.
>
> In particular, we need to protect against the following:
> 1) Receiving a Rescind offer after we do queue_work() for processing an
> Offer
>request and before we actually enter vmbus_process_offer(). work.func
> points
>to vmbus_process_offer() at this moment and in vmbus_onoffer_rescind()
> we do
>another queue_work() without a check so we'll enter
> vmbus_process_offer()
>twice.
> 2) Receiving a Rescind offer after we enter vmbus_process_offer() and
>especially after we set >state = CHANNEL_OPEN_STATE. Many things can
> go
>wrong in that case, e.g. we can call free_channel() while we're still using
>it.
>
> Implement the required protection by changing work->func at the very end
> of
> vmbus_process_offer() and checking work->func in
> vmbus_onoffer_rescind().
> pr_warn here serves only one purpose, it shows us the collision between
> Offer and Rescind offer actually happened. In case the assumption in
> 4b2f9abea52af3 was right and such collision is impossible this commit changes
> nothing.
It is clear that an offer that has not been made cannot be rescinded. So if a
rescind were to come while
we are in the process of handling the offer, we should deal with the rescind as
well after the processing of the offer is done.
Your patch does not do this; essentially we could miss handling a rescind
message. We could tweak your patch to
deal with this case. If a rescind message comes in while we are still
processing the offer, we should process the
rescind message in the same context. We can add this check at the end of the
function that processes the offer.
If the offer is processed fully when the rescind message comes in then we can
process the rescind request in its own
work context.
>
> I also fix one additional issue with this patch: vmbus_device_create() result
> is
> not being checked in vmbus_process_offer() and it can fail if kzalloc() fails.
Please have this fix in a separate patch.
Thanks,
K. Y
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 2/3 v6] drivers/bus: Freescale Management Complex (fsl-mc) bus driver
Platform device driver that sets up the basic bus infrastructure for the fsl-mc bus type, including support for adding/removing fsl-mc devices, register/unregister of fsl-mc drivers, and bus match support to bind devices to drivers. Signed-off-by: J. German Rivera Signed-off-by: Stuart Yoder --- Changes addressed in v6: - Fixed new checkpatch warnings Changes addressed in v5: - Addressed comments from Alex Graf: * Renamed dprc_get_container_id() call as dpmng_get_container_id(). * Added TODO comment to use the 'ranges' property of the fsl-mc DT node. Changes addressed in v4: - Addressed comments from Alex Graf: * Added missing scope limitations and more descriptive help text for the FSL_MC_BUS config option. - Fixed bug related to setting fsl_mc_bus_type.dev_root too late. Changes in v3: - Addressed changes from Kim Phillips: * Renamed files: drivers/bus/fsl-mc/fsl_mc_bus.c -> drivers/bus/fsl-mc/mc-bus.c include/linux/fsl_mc.h -> include/linux/fsl/mc.h include/linux/fsl_mc_private.h -> include/linux/fsl/mc-private.h - Addressed comments from Timur Tabi: * Changed all functions that had goto out/error when no common cleanup was done, to just have multiple return points. * Replaced error cleanup boolean flags with multiple exit points. Changes in v2: - Addressed comment from Joe Perches: * Changed pr_debug to dev_dbg in fsl_mc_bus_match - Addressed comments from Kim Phillips and Alex Graf: * Changed version check to allow the driver to run with MC firmware that has major version number greater than or equal to the driver's major version number. * Removed minor version check - Removed unused variable parent_dev in fsl_mc_device_remove drivers/bus/Kconfig| 3 + drivers/bus/Makefile | 3 + drivers/bus/fsl-mc/Kconfig | 24 ++ drivers/bus/fsl-mc/Makefile| 14 + drivers/bus/fsl-mc/mc-bus.c| 585 + include/linux/fsl/mc-private.h | 33 +++ include/linux/fsl/mc.h | 137 ++ 7 files changed, 799 insertions(+) create mode 100644 drivers/bus/fsl-mc/Kconfig create mode 100644 drivers/bus/fsl-mc/Makefile create mode 100644 drivers/bus/fsl-mc/mc-bus.c create mode 100644 include/linux/fsl/mc-private.h create mode 100644 include/linux/fsl/mc.h diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index b99729e..dde3ec2 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -67,4 +67,7 @@ config VEXPRESS_CONFIG help Platform configuration infrastructure for the ARM Ltd. Versatile Express. + +source "drivers/bus/fsl-mc/Kconfig" + endmenu diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 2973c18..6abcab1 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -15,3 +15,6 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o obj-$(CONFIG_ARM_CCN) += arm-ccn.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o + +# Freescale Management Complex (MC) bus drivers +obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/ diff --git a/drivers/bus/fsl-mc/Kconfig b/drivers/bus/fsl-mc/Kconfig new file mode 100644 index 000..0d779d9 --- /dev/null +++ b/drivers/bus/fsl-mc/Kconfig @@ -0,0 +1,24 @@ +# +# Freescale Management Complex (MC) bus drivers +# +# Copyright (C) 2014 Freescale Semiconductor, Inc. +# +# This file is released under the GPLv2 +# + +config FSL_MC_BUS + tristate "Freescale Management Complex (MC) bus driver" + depends on OF && ARM64 + help + Driver to enable the bus infrastructure for the Freescale + QorIQ Management Complex (fsl-mc). The fsl-mc is a hardware + module of the QorIQ LS2 SoCs, that does resource management + for hardware building-blocks in the SoC that can be used + to dynamically create networking hardware objects such as + network interfaces (NICs), crypto accelerator instances, + or L2 switches. + + Only enable this option when building the kernel for + Freescale QorQIQ LS2 SoCs. + + diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile new file mode 100644 index 000..decd339 --- /dev/null +++ b/drivers/bus/fsl-mc/Makefile @@ -0,0 +1,14 @@ +# +# Freescale Management Complex (MC) bus drivers +# +# Copyright (C) 2014 Freescale Semiconductor, Inc. +# +# This file is released under the GPLv2 +# +obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o + +mc-bus-driver-objs := mc-bus.o \ + mc-sys.o \ + dprc.o \ + dpmng.o + diff --git a/drivers/bus/fsl-mc/mc-bus.c b/drivers/bus/fsl-mc/mc-bus.c new file mode 100644 index 000..e6f3d62 --- /dev/null +++ b/drivers/bus/fsl-mc/mc-bus.c @@ -0,0 +1,585 @@ +/* + * Freescale Management Complex (MC) bus driver + * + * Copyright (C) 2014 Freescale Semiconductor, Inc. + * Author: German Rivera + * + * This file is licensed under the terms of the GNU General Public + * License version
[PATCH 3/3 v6] drivers/bus: Device driver for FSL-MC DPRC devices
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
Changes in v6:
- Fixed new checkpatch warnings
Changes in v5:
None
Changes in v4:
- Addressed comments from Alex Graf:
* Fixed typo in comment
Changes in v3:
- Addressed comments from Kim Phillips:
* Renamed files:
drivers/bus/fsl-mc/fsl_mc_dprc.c -> drivers/bus/fsl-mc/dprc-driver.c
- Addressed comments from Timur Tabi:
* Changed dprc_scan_container() to just return dprc_scan_objects()
* Changed all functions that had goto out/error when no common cleanup
was done, to just have multiple return points.
* Replaced error cleanup boolean flags with multiple exit points.
* REmoved __must_chewck from dprc_scan_*() functions
Changes in v2:
- Addressed comments from Kim Phillips:
* Fix warning in drivers/bus/fsl-mc/fsl_mc_dprc.c:173
* Fixed linker errors when MC bus driver built as module
drivers/bus/fsl-mc/Makefile | 3 +-
drivers/bus/fsl-mc/dprc-driver.c | 383 +++
drivers/bus/fsl-mc/mc-bus.c | 8 +
include/linux/fsl/mc-private.h | 10 +
4 files changed, 403 insertions(+), 1 deletion(-)
create mode 100644 drivers/bus/fsl-mc/dprc-driver.c
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index decd339..424e58e 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o
mc-bus-driver-objs := mc-bus.o \
mc-sys.o \
dprc.o \
- dpmng.o
+ dpmng.o \
+ dprc-driver.o
diff --git a/drivers/bus/fsl-mc/dprc-driver.c b/drivers/bus/fsl-mc/dprc-driver.c
new file mode 100644
index 000..5d07e30
--- /dev/null
+++ b/drivers/bus/fsl-mc/dprc-driver.c
@@ -0,0 +1,383 @@
+/*
+ * Freescale data path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "dprc-cmd.h"
+
+struct dprc_child_objs {
+ int child_count;
+ struct dprc_obj_desc *child_array;
+};
+
+static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void *data)
+{
+ int i;
+ struct dprc_child_objs *objs;
+ struct fsl_mc_device *mc_dev;
+
+ WARN_ON(!dev);
+ WARN_ON(!data);
+ mc_dev = to_fsl_mc_device(dev);
+ objs = data;
+
+ for (i = 0; i < objs->child_count; i++) {
+ struct dprc_obj_desc *obj_desc = >child_array[i];
+
+ if (strlen(obj_desc->type) != 0 &&
+ FSL_MC_DEVICE_MATCH(mc_dev, obj_desc))
+ break;
+ }
+
+ if (i == objs->child_count)
+ fsl_mc_device_remove(mc_dev);
+
+ return 0;
+}
+
+static int __fsl_mc_device_remove(struct device *dev, void *data)
+{
+ WARN_ON(!dev);
+ WARN_ON(data);
+ fsl_mc_device_remove(to_fsl_mc_device(dev));
+ return 0;
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
+ struct dprc_obj_desc *obj_desc_array,
+ int num_child_objects_in_mc)
+{
+ if (num_child_objects_in_mc != 0) {
+ /*
+* Remove child objects that are in the DPRC in Linux,
+* but not in the MC:
+*/
+ struct dprc_child_objs objs;
+
+ objs.child_count = num_child_objects_in_mc;
+ objs.child_array = obj_desc_array;
+ device_for_each_child(_bus_dev->dev, ,
+ __fsl_mc_device_remove_if_not_in_mc);
+ } else {
+ /*
+* There are no child objects for this DPRC in the MC.
+* So, remove all the child devices from Linux:
+*/
+ device_for_each_child(_bus_dev->dev, NULL,
+ __fsl_mc_device_remove);
+ }
+}
+
+static int __fsl_mc_device_match(struct device *dev, void *data)
+{
+
Re: futex(2) man page update help request
On 1/16/15, 4:56 PM, "Davidlohr Bueso" wrote:
>On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
>> On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
>> > On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
>> >
>> >> Hello Thomas,
>> >>
>> >> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
>> >>> On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
>> > [EINVAL] uaddr equal uaddr2. Requeue to same futex.
>>
>> ??? I added this, but does this error not occur only for PI
>>requeues?
>> >>>
>> >>> It's equally wrong for normal futexes. And its actually the same
>>code
>> >>> checking for this for all variants.
>> >>
>> >> I don't understand "equally wrong" in your reply, I'm sorry. Do you
>> >> mean:
>> >>
>> >> a) This error text should be there for both normal and PI requeues
>> >
>> > It is there for both. The requeue code has that check independent of
>> > the requeue type (normal/pi). It never makes sense to requeue
>> > something to itself whether normal or pi futex. We added this for PI,
>> > because there it is harmful, but we did not special case it. So normal
>> > futexes get the same treatment.
>>
>> Hello Thomas,
>>
>> Color me stupid, but I can't see this in futex_requeue(). Where is that
>> check that is "independent of the requeue type (normal/pi)"?
>>
>> When I look through futex_requeue(), all the likely looking sources
>> of EINVAL are governed by a check on the 'requeue_pi' argument.
>
>Yeah, its not very straightforward, I was also scratching my head. First
>we do:
>
> if (requeue_pi) {
> /*
>* Requeue PI only works on two distinct uaddrs. This
>* check is only valid for private futexes. See below.
>*/
> if (uaddr1 == uaddr2)
> return -EINVAL;
We check here to abort as early as possible for the usual security reasons.
>
>Then:
>
> /*
>* The check above which compares uaddrs is not sufficient for
>* shared futexes. We need to compare the keys:
>*/
> if (requeue_pi && match_futex(, )) {
> ret = -EINVAL;
> goto out_put_keys;
> }
>
>I wonder why we're checking for requeue_pi again, when, at least
>according to the comments, it should be for shared. I guess it would
>make sense depending on the mappings as the keys are the only true way
>of determining if both futexes are the same, so perhaps:
>
> if ((requeue_pi || (flags & FLAGS_SHARED)) && match_futex())
No, the rule only applies to requeue_pi. This check is the for-sure
version of the uaddr comparison above. We could add if flags &
FLAGS_SHARED, but I'm not sure it's worth it.
--
Darren Hart
Intel Open Source Technology Center
--
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/
How to handle access to multiple PHYs through MDIO
Hi, Our SoC, Cygnus, uses a generic MDC/MDIO controller to talk to various PHYs, including 2 x Ethernet GPHY, 2 x PCIe Serdes, and 3 x USB PHYs. In this case, how should I work out a generic PHY driver to handle this? I notice that most generic PHY drivers are in drivers/phy/*, but Ethernet seems to have its own interface of talking to a PHY through MDIO (drivers/net/phy/*). I need a single driver to handle these so there isn't any race condition for this single MDIO access in our system. Thanks, Ray -- 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/3 v6] drivers/bus: Added Freescale Management Complex APIs
APIs to access the Management Complex (MC) hardware module of Freescale LS2 SoCs. This patch includes APIs to check the MC firmware version and to manipulate DPRC objects in the MC. Signed-off-by: J. German Rivera Signed-off-by: Stuart Yoder --- Changes in v6: - Upgraded MC flibs for MC firmware 0.5.3 - Fixed new checkpatch warnings Changes in v5: - Addressed comments from Alex Graf: * Removed unused variable in mc_send_command() * Renamed dprc_get_container_id() as dpmng_get_container_id() and moved corresponding code from dprc.[hc] to dpmng.[hc], as "get_container_id" is not really an operation on a DPRC object, but it is a general MC management operation. * Ensure that strings sent/received to/from the MC fw for DPRC commands are null-terminated. Changes in v4: - Addressed comments from Alex Graf: * Added file description for files that did not have one * Removed Marshalling/unmarshalling macros invoked in MC command wrapper functions, and instead do the marshalling/ unmarshalling directly in these functions. * Added type cast u32 in status range-check in mc_status_to_error() * Moved mc_write_command() and mc_read_response() inline function to mc_sys.c as they are only used in that file * Renamed u64_enc() as mc_enc() and u64_dec() as mc_dec() - Upgraded MC flibs for MC firmware 0.5 Changes in v3: - Addressed comment from Greg Kroah-Hartman: * Removed doxygen comments - Addressed comment from Scott Wood: * Replaced udelay() call with usleep_range() call in polling loop - Addressed comments from Kim Phillips: * Fixed license text in all files * Renamed files: drivers/bus/fsl-mc/fsl_dpmng_cmd.h -> drivers/bus/fsl-mc/dpmng-cmd.h drivers/bus/fsl-mc/fsl_dprc_cmd.h -> drivers/bus/fsl-mc/dprc-cmd.h drivers/bus/fsl-mc/fsl_mc_sys.c -> drivers/bus/fsl-mc/mc-sys.c include/linux/fsl_dpmng.h -> include/linux/fsl/dpmng.h include/linux/fsl_dprc.h -> include/linux/fsl/dprc.h include/linux/fsl_mc_cmd.h -> include/linux/fsl/mc-cmd.h include/linux/fsl_mc_sys.h -> include/linux/fsl/mc-sys.h * Changed dpmng_load_iop() to take the DMA address directly, instead of the image virtual address. * Removed if and WARN_ON that checks for NULL fsl_destroy_mc_io() * Removed locking from mc_send_command(). Now the caller of MC flib APIs is responsible for protecting concurrent accesses to the same MC portal. Changes in v2: - Addressed comment from Joe Perches: * Refactored logic to actively fail on err and proceed at the same indent level on success, for all functions in dprc.c and dpmng.c. - Addressed comments from Kim Phillips: * Fixed warning in mc_send_command * Changed serialization logic in mc_send_command() to only use spinlock_irqsave() when both threads and interrupt handlers concurrently access the same portal. * Changed switch to lookup table in mc_status_to_error() * Removed macros iowrite64(), ioread64(), ENOTSUP from fsl_mc_sys.h * Removed #ifdef side for FSL_MC_FIRMWARE in fsl_mc_cmd.h * Changed non-devm_ API calls to devm_ API calls and refactored fsl_create_mc_io()/fsl_destroy_mc_io() to simplify cleanup logic. - Addressed comments from Scott Wood: * Return -ENXIO instead of -EFAULT when ioremap_nocache() fails - Addressed comments from Alex Graf: * Added MAINTAINERS file entries for new files * Added dev param to fsl_create_mc_io(), to enable the use of devm_ APIs in this function and fsl_destroy_mc_io(). * Changed the value of the timeout for MC command completion to be a function of HZ instead of a hard-coded jiffies value. MAINTAINERS| 8 + drivers/bus/fsl-mc/dpmng-cmd.h | 47 +++ drivers/bus/fsl-mc/dpmng.c | 78 drivers/bus/fsl-mc/dprc-cmd.h | 84 drivers/bus/fsl-mc/dprc.c | 913 + drivers/bus/fsl-mc/mc-sys.c| 283 + include/linux/fsl/dpmng.h | 80 include/linux/fsl/dprc.h | 801 include/linux/fsl/mc-cmd.h | 113 + include/linux/fsl/mc-sys.h | 70 10 files changed, 2477 insertions(+) create mode 100644 drivers/bus/fsl-mc/dpmng-cmd.h create mode 100644 drivers/bus/fsl-mc/dpmng.c create mode 100644 drivers/bus/fsl-mc/dprc-cmd.h create mode 100644 drivers/bus/fsl-mc/dprc.c create mode 100644 drivers/bus/fsl-mc/mc-sys.c create mode 100644 include/linux/fsl/dpmng.h create mode 100644 include/linux/fsl/dprc.h create mode 100644 include/linux/fsl/mc-cmd.h create mode 100644 include/linux/fsl/mc-sys.h diff --git a/MAINTAINERS b/MAINTAINERS index 8bed045..81701af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4075,6 +4075,14 @@ F: sound/soc/fsl/fsl* F: sound/soc/fsl/imx* F: sound/soc/fsl/mpc8610_hpcd.c +FREESCALE QORIQ MANAGEMENT COMPLEX DRIVER +M: J. German Rivera +L: linux-kernel@vger.kernel.org +S: Maintained +F:
Re: [PATCH RESEND v8 1/2] clk: Make clk API return per-user struct clk instances
On 01/12, Tomeu Vizoso wrote:
> Moves clock state to struct clk_core, but takes care to change as little API
> as
> possible.
>
> struct clk_hw still has a pointer to a struct clk, which is the
> implementation's per-user clk instance, for backwards compatibility.
>
> The struct clk that clk_get_parent() returns isn't owned by the caller, but by
> the clock implementation, so the former shouldn't call clk_put() on it.
>
> Because some boards in mach-omap2 still register clocks statically, their
> clock
> registration had to be updated to take into account that the clock information
> is stored in struct clk_core now.
>
> Signed-off-by: Tomeu Vizoso
>
Looks mostly good. Missing some NULL checks mostly.
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index f4963b7..7eddfd8 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -114,7 +123,7 @@ static struct hlist_head *orphan_list[] = {
> +static void clk_summary_show_one(struct seq_file *s, struct clk_core *c, int
> level)
> {
> if (!c)
> return;
> @@ -122,14 +131,14 @@ static void clk_summary_show_one(struct seq_file *s,
> struct clk *c, int level)
[...]
> -static void clk_summary_show_subtree(struct seq_file *s, struct clk *c,
> +static void clk_summary_show_subtree(struct seq_file *s, struct clk_core *c,
>int level)
> {
> - struct clk *child;
> + struct clk_core *child;
>
> if (!c)
> return;
> @@ -172,7 +181,7 @@ static const struct file_operations clk_summary_fops = {
> .release= single_release,
> };
>
> -static void clk_dump_one(struct seq_file *s, struct clk *c, int level)
> +static void clk_dump_one(struct seq_file *s, struct clk_core *c, int level)
> {
> if (!c)
> return;
> @@ -180,14 +189,14 @@ static void clk_dump_one(struct seq_file *s, struct clk
> *c, int level)
[...]
> -static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
> +static void clk_dump_subtree(struct seq_file *s, struct clk_core *c, int
> level)
> {
> - struct clk *child;
> + struct clk_core *child;
>
> if (!c)
> return;
> @@ -418,19 +427,20 @@ static int __init clk_debug_init(void)
[...]
>
> /* caller must hold prepare_lock */
> -static void clk_unprepare_unused_subtree(struct clk *clk)
> +static void clk_unprepare_unused_subtree(struct clk_core *clk)
> {
> - struct clk *child;
> + struct clk_core *child;
>
> if (!clk)
> return;
> @@ -453,9 +463,9 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
> }
>
> /* caller must hold prepare_lock */
> -static void clk_disable_unused_subtree(struct clk *clk)
> +static void clk_disable_unused_subtree(struct clk_core *clk)
> {
> - struct clk *child;
> + struct clk_core *child;
> unsigned long flags;
>
> if (!clk)
Note: These NULL checks look bogus. No need to fix them here, but
a patch to remove them would be nice.
> @@ -532,48 +542,59 @@ late_initcall_sync(clk_disable_unused);
[...]
> +
> +struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
> +{
> + struct clk_core *parent;
> +
> + parent = clk_core_get_parent_by_index(clk->core, index);
I suppose clk could be NULL here (although this is mostly a
clk-provider function). At least before we would return NULL in
such a case so we should keep the same behavior instead of NULL
deref.
> +
> + return !parent ? NULL : parent->hw->clk;
> +}
> EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
>
> @@ -593,9 +614,14 @@ unsigned long __clk_get_rate(struct clk *clk)
> out:
> return ret;
> }
> +
> +unsigned long __clk_get_rate(struct clk *clk)
> +{
> + return clk_core_get_rate_nolock(clk->core);
Oops. clk can be NULL here. We should check for that and return
0.
> +}
> EXPORT_SYMBOL_GPL(__clk_get_rate);
>
> @@ -630,7 +656,12 @@ out:
> return !!ret;
> }
>
> -bool __clk_is_enabled(struct clk *clk)
> +bool __clk_is_prepared(struct clk *clk)
> +{
> + return clk_core_is_prepared(clk->core);
Oops. clk can be NULL here. Return false if so. Or drop the
function entirely? It looks like it may become unused.
> +}
> @@ -650,12 +681,17 @@ bool __clk_is_enabled(struct clk *clk)
> out:
> return !!ret;
> }
> +
> +bool __clk_is_enabled(struct clk *clk)
> +{
> + return clk_core_is_enabled(clk->core);
Oops. clk can be NULL here. Return false if so.
> +}
> EXPORT_SYMBOL_GPL(__clk_is_enabled);
>
> @@ -762,7 +805,12 @@ void __clk_unprepare(struct clk *clk)
> if (clk->ops->unprepare)
> clk->ops->unprepare(clk->hw);
>
> - __clk_unprepare(clk->parent);
> + clk_core_unprepare(clk->parent);
> +}
> +
> +void __clk_unprepare(struct clk *clk)
> +{
> + clk_core_unprepare(clk->core);
OOps. clk can be NULL here. Bail early if so.
> }
>
> /**
> @@ -813,6 +861,11 @@ int __clk_prepare(struct clk *clk)
> return 0;
> }
>
> +int __clk_prepare(struct
Directory for platform specific power management code
Hi, Can someone please tell me the best location for platform specific power management code, e.g., the code that puts a specific SoC into deep sleep. I'm working on a project for an SoC called Cygnus from Broadcom. I think arch/arm/mach-bcm/* is the best location, but given that the trend is to move code from arch directories into drivers/* (e.g., drivers/clk/*), I thought I would double check here. Thanks, Ray -- 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: futex(2) man page update help request
On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
> On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
> > On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
> >
> >> Hello Thomas,
> >>
> >> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
> >>> On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
> > [EINVAL] uaddr equal uaddr2. Requeue to same futex.
>
> ??? I added this, but does this error not occur only for PI requeues?
> >>>
> >>> It's equally wrong for normal futexes. And its actually the same code
> >>> checking for this for all variants.
> >>
> >> I don't understand "equally wrong" in your reply, I'm sorry. Do you
> >> mean:
> >>
> >> a) This error text should be there for both normal and PI requeues
> >
> > It is there for both. The requeue code has that check independent of
> > the requeue type (normal/pi). It never makes sense to requeue
> > something to itself whether normal or pi futex. We added this for PI,
> > because there it is harmful, but we did not special case it. So normal
> > futexes get the same treatment.
>
> Hello Thomas,
>
> Color me stupid, but I can't see this in futex_requeue(). Where is that
> check that is "independent of the requeue type (normal/pi)"?
>
> When I look through futex_requeue(), all the likely looking sources
> of EINVAL are governed by a check on the 'requeue_pi' argument.
Yeah, its not very straightforward, I was also scratching my head. First
we do:
if (requeue_pi) {
/*
* Requeue PI only works on two distinct uaddrs. This
* check is only valid for private futexes. See below.
*/
if (uaddr1 == uaddr2)
return -EINVAL;
Then:
/*
* The check above which compares uaddrs is not sufficient for
* shared futexes. We need to compare the keys:
*/
if (requeue_pi && match_futex(, )) {
ret = -EINVAL;
goto out_put_keys;
}
I wonder why we're checking for requeue_pi again, when, at least
according to the comments, it should be for shared. I guess it would
make sense depending on the mappings as the keys are the only true way
of determining if both futexes are the same, so perhaps:
if ((requeue_pi || (flags & FLAGS_SHARED)) && match_futex())
That would also align with the retry labels.
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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
Mark, On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland wrote: >> The hwlock is a basic hardware primitive that allow synchronization >> between different processors in the system, which may be running Linux >> as well as other operating systems, and may have no other means of >> communication. >> >> The hwlock id numbers are predefined, global and static across the >> entire system: Linux may boot well after other operating systems are >> already running and using these hwlocks to communicate, and therefore, >> in order to use these hardware devices, it must not enumerate them >> differently than the rest of the system. > > That's not true. > > In order to communicate it must agree with the other users as to the > meaning of each instance, and the protocol for use. That doesn't > necessarily mean that Linux needs to know the numerical ID from a > datasheet, and regardless that ID is separate from the logical ID Linux > uses internally. Let me describe hwspinlocks a bit more so we all get to know it better and can then agree on a proper solution. - What makes handling of hwspinlock ID numbers convenient is the fact that it's not based on random datasheet numbers. In fact, hwspinlocks is just special memory: usually datasheets just define the base address and the size of the hwspinlock area. So any numerical ID we use to call the locks themselves are already logical and sane, similar to the way we handle memory (i.e. if we have 32 locks we'll always use 0..31). So hwlocks ids are very much like memory addressing, and not irq numbers. - Sometimes Linux will have to dynamically allocate a hwlock, and send the ID of the allocated lock to a remote processor (which may not be running Linux). - Sometimes a remote processor, which may not be running Linux, will have to dynamically allocate a hwlock, and send the ID of the allocated lock to us (another processor running Linux) We cannot tell in advance what kind of IPC is going to be used for sending and receiving this hwlock ID. Some are handled by Linux (kernel) and some by the user space. So we must be able to expose an ID the system will understand as well as receive one. Thanks, Ohad. -- 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: futex(2) man page update help request
On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)" wrote: >On 01/16/2015 04:20 PM, Thomas Gleixner wrote: >> On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote: >> >>> Hello Thomas, >>> >>> On 01/15/2015 11:23 PM, Thomas Gleixner wrote: On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote: >> [EINVAL] uaddr equal uaddr2. Requeue to same futex. > > ??? I added this, but does this error not occur only for PI requeues? It's equally wrong for normal futexes. And its actually the same code checking for this for all variants. >>> >>> I don't understand "equally wrong" in your reply, I'm sorry. Do you >>> mean: >>> >>> a) This error text should be there for both normal and PI requeues >> >> It is there for both. The requeue code has that check independent of >> the requeue type (normal/pi). It never makes sense to requeue >> something to itself whether normal or pi futex. We added this for PI, >> because there it is harmful, but we did not special case it. So normal >> futexes get the same treatment. > >Hello Thomas, > >Color me stupid, but I can't see this in futex_requeue(). Where is that >check that is "independent of the requeue type (normal/pi)"? > >When I look through futex_requeue(), all the likely looking sources >of EINVAL are governed by a check on the 'requeue_pi' argument. Right, in the non-PI case, I believe there are valid use cases: move to the back of the FIFO, for example (OK, maybe the only example?). Both tests ensuring uaddr1 != uaddr2 are under the requeue_pi conditional block. The second compares the keys in case they are not FUTEX_PRIVATE (uaddrs would be different, but still the same backing store). Thomas, am I missing a test for this someplace else? -- Darren Hart Intel Open Source Technology Center -- 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 00/13] Add kdbus implementation
On Fri, Jan 16, 2015 at 7:26 PM, Daniel Mack wrote: > Hi Josh, > > On 01/16/2015 11:18 PM, Greg Kroah-Hartman wrote: >> On Fri, Jan 16, 2015 at 05:07:25PM -0500, Josh Boyer wrote: >>> The code.google.com tree has commits >>> from 2 days ago, but it still calls d_materialise_unique in fs.c >>> whereas the patchset you've posted uses the correct d_splice_alias. >>> So the code.google.com tree doesn't actually compile against 3.19-rcX. >>> >>> I'm confused where we're supposed to track things now. > > The code.google.com repository is where we do all the development, and > the code is made to build external kernel modules for 3.18. The patches > sent in this series are meant for 3.19 and 3.20 kernels, and while they > are based on the exact same sources, the patches differ in the following > minor details: > > * Code is moved to appropriate locations, such as ipc/kdbus, >include/uapi, tools/testing/selftests/kdbus/, Documentation/ etc. > > * Include file location amendments, "kdbus.h" vs. > > * Added iov_iter_kvec() usage, as that's a new API in v3.19 > > * The file system magic number is moved to include/uapi/linux/magic.h > > * d_materialise_unique() is renamed to d_splice_alias() to catch up >with changes in 3.19 > > > The commit this patch set is based on is tagged as "lkml-v3" in the > upstream repository now. OK, thanks for the explanation. I wonder if it would be possible to have branches for each kernel version in the code.google.com repo? I build kdbus against a number of kernels and trying to chase down different repos and patch sets to match might get to be a chore. I mean, I'm all for doing closet development to get stuff ready for upstream but it's hard for others to keep up when the closet keeps moving :) josh -- 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 00/13] Add kdbus implementation
Hi Josh, On 01/16/2015 11:18 PM, Greg Kroah-Hartman wrote: > On Fri, Jan 16, 2015 at 05:07:25PM -0500, Josh Boyer wrote: >> The code.google.com tree has commits >> from 2 days ago, but it still calls d_materialise_unique in fs.c >> whereas the patchset you've posted uses the correct d_splice_alias. >> So the code.google.com tree doesn't actually compile against 3.19-rcX. >> >> I'm confused where we're supposed to track things now. The code.google.com repository is where we do all the development, and the code is made to build external kernel modules for 3.18. The patches sent in this series are meant for 3.19 and 3.20 kernels, and while they are based on the exact same sources, the patches differ in the following minor details: * Code is moved to appropriate locations, such as ipc/kdbus, include/uapi, tools/testing/selftests/kdbus/, Documentation/ etc. * Include file location amendments, "kdbus.h" vs. * Added iov_iter_kvec() usage, as that's a new API in v3.19 * The file system magic number is moved to include/uapi/linux/magic.h * d_materialise_unique() is renamed to d_splice_alias() to catch up with changes in 3.19 The commit this patch set is based on is tagged as "lkml-v3" in the upstream repository now. Thanks, Daniel -- 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 01/01] modules: Add missing word to comment
Add missing 'which' in comment.
Signed-off-by: Sharon Dvir
---
diff --git a/include/linux/mod_devicetable.h
b/include/linux/mod_devicetable.h
index 745def8..470a240 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -53,9 +53,9 @@ struct ieee1394_device_id {
/**
* struct usb_device_id - identifies USB devices for probing and
hotplugging
- * @match_flags: Bit mask controlling of the other fields are used to
match
- * against new devices. Any field except for driver_info may be
used,
- * although some only make sense in conjunction with other fields.
+ * @match_flags: Bit mask controlling which of the other fields are
used to
+ * match against new devices. Any field except for driver_info may
be
+ * used, although some only make sense in conjunction with other
fields.
* This is usually set by a USB_DEVICE_*() macro, which sets all
* other fields in this structure except for driver_info.
* @idVendor: USB vendor ID for a device; numbers are assigned
--
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/
[RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
Using kasprintf to get the function name makes us look up the name
twice, along with all the vsnprintf overhead of parsing the format
string etc. It also means there is an allocation failure case to deal
with. Since symbol_string in vsprintf.c would anyway allocate an array
of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
here.
Signed-off-by: Rasmus Villemoes
---
Notes:
I don't know how expensive it is to do the symbol lookup for each
initcall. It might be worthwhile adding an
if (list_empty(_initcalls))
return false;
at the very beginning of initcall_blacklisted(), since this is a debug
feature and the blacklist is indeed usually empty.
init/main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/init/main.c b/init/main.c
index 61b993767db5..286602b677de 100644
--- a/init/main.c
+++ b/init/main.c
@@ -733,22 +733,18 @@ static bool __init_or_module
initcall_blacklisted(initcall_t fn)
{
struct list_head *tmp;
struct blacklist_entry *entry;
- char *fn_name;
+ char fn_name[KSYM_SYMBOL_LEN];
- fn_name = kasprintf(GFP_KERNEL, "%pf", fn);
- if (!fn_name)
- return false;
+ sprint_symbol_no_offset(fn_name, (unsigned long)fn);
list_for_each(tmp, _initcalls) {
entry = list_entry(tmp, struct blacklist_entry, next);
if (!strcmp(fn_name, entry->buf)) {
pr_debug("initcall %s blacklisted\n", fn_name);
- kfree(fn_name);
return true;
}
}
- kfree(fn_name);
return false;
}
#else
--
2.1.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/
Re: [PATCH] sysfs: group: allow is_visible to drop permissions
Hi Greg,
> On Fri, Jan 16, 2015 at 04:29:10PM -0500, Vivien Didelot wrote:
> > Using the optional is_visible function, it is actually possible to
> > either hide an attribute, or add a new permission, but not remove
> > one.
>
> What code wants to remove attributes?
Sorry, I meant removing a permission. Actually, drivers hide attributes
(if a feature isn't supported by a device) by returning 0 in is_visible.
E.g, if we consider a read-only attribute, a driver can add the write
permission by returning S_IWUSR, but removing S_IRUGO isn't possible.
> > This commit uses all the UGO bits returned by is_visible instead of
> > OR'ing them with the default attribute mode.
> >
> > Concretely, this allows a driver to use macros like DEVICE_ATTR_RW
> > to
> > set the attribute show and store functions and remove the S_IWUSR
> > permission in is_visible if the implementation doesn't provide a
> > setter.
>
> What bus wants to do this?
Some high level frameworks such as DSA. My motivation behind this was to
clarify how modes are set for temperature attributes in DSA. Optional
functions can be provided by switch drivers to get temperatures or set
limits. I hope the following patch helps clarifying this point:
https://gist.github.com/vivien/72734ba0673ad0b79a6b
(I Cc: Guenter as he is the author of NET_DSA_HWMON, see 51579c3).
> > Signed-off-by: Vivien Didelot
> > ---
> > fs/sysfs/group.c | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> > index 7d2a860..a8cfe03 100644
> > --- a/fs/sysfs/group.c
> > +++ b/fs/sysfs/group.c
> > @@ -41,7 +41,7 @@ static int create_files(struct kernfs_node
> > *parent, struct kobject *kobj,
> >
> > if (grp->attrs) {
> > for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> > - umode_t mode = 0;
> > + umode_t mode = (*attr)->mode;
> >
> > /*
> > * In update mode, we're changing the permissions or
> > @@ -51,13 +51,15 @@ static int create_files(struct kernfs_node
> > *parent, struct kobject *kobj,
> > if (update)
> > kernfs_remove_by_name(parent, (*attr)->name);
> > if (grp->is_visible) {
> > - mode = grp->is_visible(kobj, *attr, i);
> > - if (!mode)
> > + umode_t ugo = grp->is_visible(kobj, *attr, i);
> > +
> > + if (!(ugo & S_IRWXUGO))
> > continue;
> > +
> > + mode = (mode & ~S_IRWXUGO) | (ugo & S_IRWXUGO);
>
> Please document what you are doing here in the code, it's not obvious
> at first glance.
>
> > }
> > error = sysfs_add_file_mode_ns(parent, *attr, false,
> > - (*attr)->mode | mode,
> > - NULL);
> > + mode, NULL);
>
> Any chance this is going to break existing code that isn't expecting
> this type of change in functionality?
Usually, drivers return 0 to hide the attribute, or the attr->mode to
show it. This change should not break this expectation.
In the meantime, as the returned value is OR'ed with the actual mode,
I'm wondering if a driver can break anything by returning, let's say ~0?
That's why I kept the eventual extra bits from the attribute mode and OR
them with only the UGO bits from the return of is_visible, similar to
what sysfs_chmod_file() does.
thanks,
-v
--
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 2/3] x86_64,entry: Use sysret to return to userspace when possible
The x86_64 entry code currently jumps through complex and inconsistent hoops to try to minimize the impact of syscall exit work. For a true fast-path syscall, almost nothing needs to be done, so returning is just a check for exit work and sysret. For a full slow-path return from a syscall, the C exit hook is invoked if needed and we join the iret path. Using iret to return to userspace is very slow, so the entry code has accumulated various special cases to try to do certain forms of exit work without invoking iret. This is error-prone, since it duplicates assembly code paths, and it's dangerous, since sysret can malfunction in interesting ways if used carelessly. It's also inefficient, since a lot of useful cases aren't optimized and therefore force an iret out of a combination of paranoia and the fact that no one has bothered to write even more asm code to avoid it. I would argue that this approach is backwards. Rather than trying to avoid the iret path, we should instead try to make the iret path fast. Under a specific set of conditions, iret is unnecessary. In particular, if RIP==RCX, RFLAGS==R11, RIP is canonical, RF is not set, and both SS and CS are as expected, then movq 32(%rsp),%rsp;sysret does the same thing as iret. This set of conditions is nearly always satisfied on return from syscalls, and it can even occasionally be satisfied on return from an irq. Even with the careful checks for sysret applicability, this cuts nearly 80ns off of the overhead from syscalls with unoptimized exit work. This includes tracing and context tracking, and any return that invokes KVM's user return notifier. For example, the cost of getpid with CONFIG_CONTEXT_TRACKING_FORCE=y drops from ~360ns to ~280ns on my computer. This may allow the removal and even eventual conversion to C of a respectable amount of exit asm. This may require further tweaking to give the full benefit on Xen. It may be worthwhile to adjust signal delivery and exec to try hit the sysret path. This does not optimize returns to 32-bit userspace. Making the same optimization for CS == __USER32_CS is conceptually straightforward, but it will require some tedious code to handle the differences between sysretl and sysexitl. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/entry_64.S | 54 ++ 1 file changed, 54 insertions(+) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 501212f14c87..eeab4cf8b2c9 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -794,6 +794,60 @@ retint_swapgs: /* return to user-space */ */ DISABLE_INTERRUPTS(CLBR_ANY) TRACE_IRQS_IRETQ + + /* +* Try to use SYSRET instead of IRET if we're returning to +* a completely clean 64-bit userspace context. +*/ + movq (RCX-R11)(%rsp), %rcx + cmpq %rcx,(RIP-R11)(%rsp) /* RCX == RIP */ + jne opportunistic_sysret_failed + + /* +* On Intel CPUs, sysret with non-canonical RCX/RIP will #GP +* in kernel space. This essentially lets the user take over +* the kernel, since userspace controls RSP. It's not worth +* testing for canonicalness exactly -- this check detects any +* of the 17 high bits set, which is true for non-canonical +* or kernel addresses. (This will pessimize vsyscall=native. +* Big deal.) +* +* If virtual addresses ever become wider, this will need +* to be updated to remain correct on both old and new CPUs. +*/ + .ifne __VIRTUAL_MASK_SHIFT - 47 + .error "virtual address width changed -- sysret checks need update" + .endif + shr $__VIRTUAL_MASK_SHIFT, %rcx + jnz opportunistic_sysret_failed + + cmpq $__USER_CS,(CS-R11)(%rsp) /* CS must match SYSRET */ + jne opportunistic_sysret_failed + + movq (R11-ARGOFFSET)(%rsp), %r11 + cmpq %r11,(EFLAGS-ARGOFFSET)(%rsp) /* R11 == RFLAGS */ + jne opportunistic_sysret_failed + + testq $X86_EFLAGS_RF,%r11 /* sysret can't restore RF */ + jnz opportunistic_sysret_failed + + /* nothing to check for RSP */ + + cmpq $__USER_DS,(SS-ARGOFFSET)(%rsp)/* SS must match SYSRET */ + jne opportunistic_sysret_failed + + /* +* We win! This label is here just for ease of understanding +* perf profiles. Nothing jumps here. +*/ +irq_return_via_sysret: + CFI_REMEMBER_STATE + RESTORE_ARGS 1,8,1 + movq (RSP-RIP)(%rsp),%rsp + USERGS_SYSRET64 + CFI_RESTORE_STATE + +opportunistic_sysret_failed: SWAPGS jmp restore_args -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
[PATCH v2 3/3] x86_64,entry: Remove the syscall exit audit and schedule optimizations
We used to optimize rescheduling and audit on syscall exit. Now that the full slow path is reasonably fast, remove these optimizations. Syscall exit auditing is now handled exclusively by syscall_trace_leave. This adds something like 10ns to the previously optimized paths on my computer, presumably due mostly to SAVE_REST / RESTORE_REST. I think that we should eventually replace both the syscall and non-paranoid interrupt exit slow paths with a pair of C functions along the lines of the syscall entry hooks. Acked-by: Borislav Petkov Signed-off-by: Andy Lutomirski --- arch/x86/kernel/entry_64.S | 52 +- 1 file changed, 5 insertions(+), 47 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index eeab4cf8b2c9..db13655c3a2a 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -361,15 +361,12 @@ system_call_fastpath: * Has incomplete stack frame and undefined top of stack. */ ret_from_sys_call: - movl $_TIF_ALLWORK_MASK,%edi - /* edi: flagmask */ -sysret_check: + testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) + jnz int_ret_from_sys_call_fixup /* Go the the slow path */ + LOCKDEP_SYS_EXIT DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF - movl TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET),%edx - andl %edi,%edx - jnz sysret_careful CFI_REMEMBER_STATE /* * sysretq will re-enable interrupts: @@ -383,49 +380,10 @@ sysret_check: USERGS_SYSRET64 CFI_RESTORE_STATE - /* Handle reschedules */ - /* edx: work, edi: workmask */ -sysret_careful: - bt $TIF_NEED_RESCHED,%edx - jnc sysret_signal - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) - pushq_cfi %rdi - SCHEDULE_USER - popq_cfi %rdi - jmp sysret_check - /* Handle a signal */ -sysret_signal: - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) -#ifdef CONFIG_AUDITSYSCALL - bt $TIF_SYSCALL_AUDIT,%edx - jc sysret_audit -#endif - /* -* We have a signal, or exit tracing or single-step. -* These all wind up with the iret return path anyway, -* so just join that path right now. -*/ +int_ret_from_sys_call_fixup: FIXUP_TOP_OF_STACK %r11, -ARGOFFSET - jmp int_check_syscall_exit_work - -#ifdef CONFIG_AUDITSYSCALL - /* -* Return fast path for syscall audit. Call __audit_syscall_exit() -* directly and then jump back to the fast path with TIF_SYSCALL_AUDIT -* masked off. -*/ -sysret_audit: - movq RAX-ARGOFFSET(%rsp),%rsi /* second arg, syscall return value */ - cmpq $-MAX_ERRNO,%rsi /* is it < -MAX_ERRNO? */ - setbe %al /* 1 if so, 0 if not */ - movzbl %al,%edi /* zero-extend that into %edi */ - call __audit_syscall_exit - movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi - jmp sysret_check -#endif /* CONFIG_AUDITSYSCALL */ + jmp int_ret_from_sys_call /* Do syscall tracing */ tracesys: -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] x86_64,entry: Rearrange the syscall exit optimizations
Linus, I suspect you'll either like or hate this series. Or maybe you'll think it's crazy but you'll like it anyway. I'm curious which of those is the case. :) The syscall exit asm is a big mess. There's a really fast path, some kind of fast path code (with a hard-coded optimization for audit), and the really slow path. The result is that it's very hard to work with this code. There are some asm paths that are much slower than they should be (context tracking is a major offender), but no one really wants to add even more asm to speed them up. This series takes a different, unorthodox approach. Rather than trying to avoid entering the very slow iret path, it adds a way back out of the iret path. The result is a dramatic speedup for context tracking, user return notification, and similar code, as the cost of a few lines of tricky asm. Nonetheless, it's barely a net addition of asm code, because we get to remove the fast path optimizations for audit and rescheduling. Thoughts? If this works, it opens the door for a lot of further consolidation of the exit code. Note: patch 1 in this series has been floating around on the list for quite a while. It's mandatory for this series to work, because the buglet that it fixes almost completely defeats the optimization that I'm introducing. Note: Some optimization along these lines is probably certainly needed to get anything resembling acceptable performance out of the FPU changes that Rik is working on. Andy Lutomirski (3): x86_64,entry: Fix RCX for traced syscalls x86_64,entry: Use sysret to return to userspace when possible x86_64,entry: Remove the syscall exit audit and schedule optimizations arch/x86/kernel/entry_64.S | 109 + 1 file changed, 61 insertions(+), 48 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] x86_64,entry: Fix RCX for traced syscalls
The int_ret_from_sys_call and syscall tracing code disagrees with
the sysret path as to the value of RCX.
The Intel SDM, the AMD APM, and my laptop all agree that sysret
returns with RCX == RIP. The syscall tracing code does not respect
this property.
For example, this program:
int main()
{
extern const char syscall_rip[];
unsigned long rcx = 1;
unsigned long orig_rcx = rcx;
asm ("mov $-1, %%eax\n\t"
"syscall\n\t"
"syscall_rip:"
: "+c" (rcx) : : "r11");
printf("syscall: RCX = %lX RIP = %lX orig RCX = %lx\n",
rcx, (unsigned long)syscall_rip, orig_rcx);
return 0;
}
prints:
syscall: RCX = 400556 RIP = 400556 orig RCX = 1
Running it under strace gives this instead:
syscall: RCX = RIP = 400556 orig RCX = 1
This changes FIXUP_TOP_OF_STACK to match sysret, causing the test to
show RCX == RIP even under strace.
It looks like this is a partial revert of:
88e4bc32686e [PATCH] x86-64 architecture specific sync for 2.5.8
from the historic git tree.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/entry_64.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 7d59df23e5bb..501212f14c87 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -143,7 +143,8 @@ ENDPROC(native_usergs_sysret64)
movq \tmp,RSP+\offset(%rsp)
movq $__USER_DS,SS+\offset(%rsp)
movq $__USER_CS,CS+\offset(%rsp)
- movq $-1,RCX+\offset(%rsp)
+ movq RIP+\offset(%rsp),\tmp /* get rip */
+ movq \tmp,RCX+\offset(%rsp) /* copy it to rcx as sysret would do */
movq R11+\offset(%rsp),\tmp /* get eflags */
movq \tmp,EFLAGS+\offset(%rsp)
.endm
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] gpio: Cygnus: add GPIO driver
On 1/16/2015 2:14 AM, Linus Walleij wrote: > On Tue, Jan 13, 2015 at 6:05 PM, Ray Jui wrote: >> On 1/13/2015 12:53 AM, Linus Walleij wrote: >>> On Tue, Dec 16, 2014 at 3:18 AM, Ray Jui wrote: >>> +/* drive strength control for ASIU GPIO */ +#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58 + +/* drive strength control for CCM GPIO */ +#define CYGNUS_GPIO_CCM_DRV0_CTRL_OFFSET 0x00 >>> >>> This stuff (drive strength) is pin control, pin config. >>> It does not belong in a pure GPIO driver. If you're >>> making a combined pin control + GPIO driver, it >>> shall be put in drivers/pinctrl/* >>> >> Okay, I have some questions here. Are you suggesting me to register this >> driver to both the pinctrl subsystem and gpiolib and move it to under >> drivers/pinctrl/*? > > Either you can have a combined driver in drivers/pinctrl/* > which has one probe() function calling pinctrl_register(), > gpiochip_add(), gpiochip_add_pin_range(), having the gpio > parts call into the pin control backend with > pinctrl_request_gpio(), pinctrl_free_gpio(), > pinctrl_gpio_direction_input(), pinctrl_gpio_direction_output(). > > Or you can split it in one driver in drivers/pinctrl/* > dealing with just the pin control stuff, and another driver > in drivers/gpio/* dealing with the GPIO stuff, each with one > probe() function. > > If they are using the same register range, the first approach > is probably most intuitive. If the pin control and GPIO parts > are separated in different register ranges, probably the > second approach is the best. > >> Or Are you suggesting me to combine this driver with the other Cygnus >> pinctrl driver (which only supports pinmux)? > > Depends on which hardware block the pin control-like > registers belongs in. See per above. > >> Note in Cygnus, all pinmux logic is done in the pinmux block. And there >> are 3 GPIO controllers, that handle GPIO, drive strength of the GPIO >> pins, internal pull up/down of the GPIO pins, which are handled in this >> driver. So this driver is generic to all 3 GPIO controllers, as you can >> see from the device tree bindings, there are 3 nodes. >> >> Therefore, I think it makes sense to have one pinmux driver that handles >> the pinmux block, and one generic pinctrl + gpio driver that handles >> functions supported by all 3 GPIO controllers. Does this make sense to you? > > Yep. > > Some hardware designs put the software-controlled biasing > resistors in the GPIO block electronically connected to the actual > pins, so that e.g. the biasing will be available if some MMC or > whatever is using the same pins in another muxing. In such > situations it's quite evident that they need to be a combined > GPIO and pin controller. > > I have some regrets that bolting a second pin controller to the > GPIO chip make things a bit complex but it's a price we have > to pay for getting some kind of generic interface. > > Yours, > Linus Walleij > Okay. In summary, I think both of us think the following approach makes sense in my situation: - leave pinmux in pinctrl-bcm-cygnus.c - leave pinctrl + gpio in pinctrl-bcm-cygnus-gpio.c under drivers/pinctrl/* But by thinking about this more, I thought this would create duplicated pinctrl descriptors in our system, one from the pinmux driver, and the other from this pinctrl+gpio driver. That is probably undesirable? By reviewing various drivers in the pinctrl directory, I found what pinctrl-u300.c and pinctrl-coh901.c does seems to serve as a good model for me to follow: - pinctrl-u300.c is the pinmux driver - pinctrl-coh901.c is the gpio+pinctrl driver The GPIO pinctrl logic is in the coh901 block, so pinctrl-coh901.c exposed two public functions u300_gpio_config_get, u300_gpio_config_set that pinctrl-u300.c can use. The u300 populates all pinmux/pinctrl related functions into the subsystem. This way there's only one pinctrl descriptor, populated through pinctrl-u300.c. Does that model make more sense to you? Thanks, Ray -- 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 4/5] pstore: add pmsg
> Cool, seems reasonable to me. Thanks for the respins! I've applied it - but I have a nagging worry about it being user accessible. We've limited access to some pstore features on platforms that only support backend drivers that write to limited lifetime flash storage - efivars & erst. Should we do that for this too? -Tony
Re: [PATCH 1/2] INPUT/HID: add touch support for SiS touch driver
On Fri, Jan 16, 2015 at 5:11 AM, Oliver Neukum wrote: > On Fri, 2015-01-16 at 18:59 +0800, 曾婷葳 (tammy_tseng) wrote: >> Hey, Oliver >> >> On Mon, Jan 12, 2015 at 7:50 PM, Oliver Neukum wrote: >> On Mon, 2015-01-12 at 18:53 +0800, 曾婷葳 (tammy_tseng) wrote: >> > > (Skip the code diff...) >> > >> > Again macros for endianness >> > >> > And the driver has a great number of conditional compilations are they >> > really needed? The driver as is has a number of issues and is hard to >> > review due to the use of "//" for comments and a lot of conditional >> > compilation and unnecessary variables used for constants. Could you >> > fix this up and resubmit? >> >> Thanks for the reply. I've modified the code >> (sis_i2c.c/sis_i2c.h/Kconfig/Makefile) to fix them. >> Please help check them if anything needs to fix. > > Hi, > > I started from the lower end. I hope you find my comments > useful. A few general points need to be made before the > code is ready for review (it is obviously not ready for > inclusion) Also: - it was sent as base64 so it can't be applied using normal tools - it has DOS line endings - even after decoding it does not apply - dtor@dtor-ws:~/kernel/work$ ./scripts/checkpatch.pl --no-signoff sis-decoded.patch ... total: 677 errors, 355 warnings, 1479 lines checked Please make sure your code at least conforms to the kernel coding style before resubmitting. Thanks. -- Dmitry -- 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] mm/thp: Allocate transparent hugepages on local node
On Fri, 16 Jan 2015 12:56:36 +0530 "Aneesh Kumar K.V"
wrote:
> This make sure that we try to allocate hugepages from local node if
> allowed by mempolicy. If we can't, we fallback to small page allocation
> based on mempolicy. This is based on the observation that allocating pages
> on local node is more beneficial than allocating hugepages on remote node.
The changelog is a bit incomplete. It doesn't describe the current
behaviour, nor what is wrong with it. What are the before-and-after
effects of this change?
And what might be the user-visible effects?
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2030,6 +2030,46 @@ retry_cpuset:
> return page;
> }
>
> +struct page *alloc_hugepage_vma(gfp_t gfp, struct vm_area_struct *vma,
> + unsigned long addr, int order)
alloc_pages_vma() is nicely documented. alloc_hugepage_vma() is not
documented at all. This makes it a bit had for readers to work out the
difference!
Is it possible to scrunch them both into the same function? Probably
too messy?
> +{
> + struct page *page;
> + nodemask_t *nmask;
> + struct mempolicy *pol;
> + int node = numa_node_id();
> + unsigned int cpuset_mems_cookie;
> +
> +retry_cpuset:
> + pol = get_vma_policy(vma, addr);
> + cpuset_mems_cookie = read_mems_allowed_begin();
> +
> + if (pol->mode != MPOL_INTERLEAVE) {
> + /*
> + * For interleave policy, we don't worry about
> + * current node. Otherwise if current node is
> + * in nodemask, try to allocate hugepage from
> + * current node. Don't fall back to other nodes
> + * for THP.
> + */
This code isn't "interleave policy". It's everything *but* interleave
policy. Comment makes no sense!
> + nmask = policy_nodemask(gfp, pol);
> + if (!nmask || node_isset(node, *nmask)) {
> + mpol_cond_put(pol);
> + page = alloc_pages_exact_node(node, gfp, order);
> + if (unlikely(!page &&
> +
> read_mems_allowed_retry(cpuset_mems_cookie)))
> + goto retry_cpuset;
> + return page;
> + }
> + }
> + mpol_cond_put(pol);
> + /*
> + * if current node is not part of node mask, try
> + * the allocation from any node, and we can do retry
> + * in that case.
> + */
> + return alloc_pages_vma(gfp, order, vma, addr, node);
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: entry-common: fix forgotten set of thread_info->syscall
On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
> wrote:
>> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
>>> On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
>>> wrote:
>>> > On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
>>> >> On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook wrote:
>>> >> > One interesting thing I noticed (which is unchanged by this series),
>>> >> > but pulling ARM_r7 during the seccomp ptrace event shows __NR_poll,
>>> >> > not __NR_restart_syscall, even though it was a __NR_restart_syscall
>>> >> > trap from seccomp. Is there a better place to see the actual syscall?
>>> >>
>>> >> As I understand we do not push new r7 to the stack, and ptrace uses the
>>> >> old value.
>>> >
>>> > And why should we push r7 to the stack? ptrace should be using the
>>> > recorded system call number, rather than poking about on the stack
>>> > itself.
>>>
>>> Probably we should not, but the behaviour comparing arm to x86 is different.
>>
>> We definitely should not, because changing the stacked value changes the
>> value in r7 after the syscall has returned. We have guaranteed that the
>> value will be preserved across syscalls for years, so we really should
>> not be changing that.
>
> Yeah, we can't mess with the registers. I was just asking for
> clarification on how this is visible to userspace.
>
>>
>>> Also there is no any way from userspace to figure out what syscall was
>>> restarted, if you do not trace each syscall enter and exit from the
>>> very beginning.
>>
>> Thinking about ptrace, that's been true for years.
>>
>> It really depends whether you consider the restart syscall a userspace
>> thing or a kernelspace thing. When you consider that the vast majority
>> of syscall restarts are done internally in the kernel, and we just
>> re-issue the syscall, it immediately brings up the question "why is
>> the restart block method different?" and "should the restart block
>> method be visible to userspace?"
>>
>> IMHO, it is prudent not to expose kernel internals to userspace unless
>> there is a real reason to, otherwise they become part of the userspace
>> API.
>
> I couldn't agree more, but restart_syscall is already visible to
> userspace: it can be called directly, for example. And it's visible to
> tracers.
>
> Unfortunately, the difference here is the visibility during trace
> trap. On x86, it's exposed but on ARM, there's no way (that I can
> find) to query the "true" syscall, even though the true syscall is
> what triggers the tracer. The syscall number isn't provided by any
> element of the ptrace event system, nor through siginfo, and must be
> examined on a per-arch basis from registers.
>
> Seccomp does, however, provide a mechanism to pass arbitrary event
> data on a TRACE event, so poll vs restart_syscall can be distinguished
> that way.
>
> It seems even strace doesn't know how to find this information. For example:
>
> x86:
> poll([{fd=3, events=POLLIN}], 1, 4294967295
> ) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=994, si_uid=1000} ---
> --- stopped by SIGSTOP ---
> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=994, si_uid=1000} ---
> restart_syscall(<... resuming interrupted call ...>
>
> ARM:
> poll([{fd=3, events=POLLIN}], 1, -1
> )= ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=20563, si_uid=0} ---
> --- stopped by SIGSTOP ---
> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=20563, si_uid=0} ---
> poll([{fd=3, events=POLLIN}], 1, -1
>
> Would it make sense to add REGSET_SYSTEM_CALL to ARM? (Though this
> begs the question, "Is restart_syscall visible during a trace on
> arm64?", which I'll have to go check...)
So, some further testing:
- native arm64 presents "poll" again even to seccomp when
restart_syscall is triggered (both via regs[8] and
NT_ARM_SYSTEM_CALL).
- compat mode on arm64 _does_ show syscall_restart (via ARM_r7).
Which of these behaviors is intentional? :)
-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/
mmotm 2015-01-16-15-50 uploaded
The mm-of-the-moment snapshot 2015-01-16-15-50 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.19-rc4: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * mm-page_alloc-embed-oom-killing-naturally-into-allocation-slowpath.patch * x86-build-replace-perl-script-with-shell-script.patch * memcg-remove-extra-newlines-from-memcg-oom-kill-log.patch * mm-vmscan-fix-highidx-argument-type.patch * jffs2-bugfix-of-summary-length.patch * fanotify-only-destroy-mark-when-both-mask-and-ignored_mask-are-cleared.patch * fanotify-dont-recalculate-a-marks-mask-if-only-the-ignored-mask-changed.patch * fanotify-dont-recalculate-a-marks-mask-if-only-the-ignored-mask-changed-checkpatch-fixes.patch * fanotify-dont-set-fan_ondir-implicitly-on-a-marks-ignored-mask.patch * fanotify-dont-set-fan_ondir-implicitly-on-a-marks-ignored-mask-checkpatch-fixes.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * build-superh-without-config_expert.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * ocfs2-dlm-add-missing-dlm_lock_put-when-recovery-master-down.patch * ocfs2-remove-unnecessary-else-in-ocfs2_set_acl.patch * ocfs2-fix-uninitialized-variable-access.patch * ocfs2-fix-wrong-comment.patch * ocfs2-fix-snprintf-format-specifier-in-dlmdebugc.patch * ocfs2-xattr-remove-unused-function.patch * ocfs2-quota_local-remove-unused-function.patch * ocfs2-dlm-dlmdomain-remove-unused-function.patch * ocfs2-fix-journal-commit-deadlock-in-ocfs2_convert_inline_data_to_extents.patch * ocfs2-add-a-mount-option-journal_async_commit-on-ocfs2-filesystem.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch * ocfs2-eliminate-the-static-flag-of-some-functions.patch * ocfs2-add-functions-to-add-and-remove-inode-in-orphan-dir.patch * ocfs2-add-orphan-recovery-types-in-ocfs2_recover_orphans.patch * ocfs2-implement-ocfs2_direct_io_write.patch * ocfs2-allocate-blocks-in-ocfs2_direct_io_get_blocks.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-appending.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-fill-holes.patch * ocfs2-fix-leftover-orphan-entry-caused-by-append-o_direct-write-crash.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * fs-make-generic_block_fiemap-sig-tolerant.patch * fs-make-generic_block_fiemap-sig-tolerant-fix.patch mm.patch * mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off.patch *
[PATCH] iommu: fix trace_unmap() to report original iova
iommu_unmap() calls trace_unmap() with changed iova and original
size. trace_unmap() should report original iova instead. Change
iommu_unmap() to call trace_unmap() with original iova.
Signed-off-by: Shuah Khan
Reported-by: Alex Williamson
---
drivers/iommu/iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index fbf8827..2eb7554 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1094,6 +1094,7 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned
long iova, size_t size)
{
size_t unmapped_page, unmapped = 0;
unsigned int min_pagesz;
+ unsigned long orig_iova = iova;
if (unlikely(domain->ops->unmap == NULL ||
domain->ops->pgsize_bitmap == 0UL))
@@ -1133,7 +1134,7 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned
long iova, size_t size)
unmapped += unmapped_page;
}
- trace_unmap(iova, 0, size);
+ trace_unmap(orig_iova, 0, size);
return unmapped;
}
EXPORT_SYMBOL_GPL(iommu_unmap);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..ff5fb6a 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -70,6 +70,26 @@
};
};
+ i2c0: i2c@18008000 {
+ compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+ reg = <0x18008000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@1800b000 {
+ compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+ reg = <0x1800b000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
uart0: serial@1802 {
compatible = "snps,dw-apb-uart";
reg = <0x1802 0x100>;
--
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 v5 1/3] i2c: iProc: define Broadcom iProc I2C binding
Document the I2C device tree binding for Broadcom iProc family of
SoCs
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or 40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+
+Example:
+ i2c0: i2c@18008000 {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x18008000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+
+ codec: wm8750@1a {
+ compatible = "wlf,wm8750";
+ reg = <0x1a>;
+ };
+ };
--
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 v5 0/3] Add I2C support to Broadcom iProc
This patchset contains the initial I2C support for Broadcom iProc family of SoCs. The iProc I2C controller has separate internal TX and RX FIFOs, each has a size of 64 bytes. The iProc I2C controller supports two bus speeds including standard mode (100 kHz) and fast mode (400 kHz) Changes from v4: - Remove redundant header file includes - Change the logic that waits for the host controller to be idle to simply return -EBUSY - Use proper print level and error codes in the driver - Allow zero length message in the driver to support I2C_SMBUS_QUICK - Change back to use devm_request_irq. Disable interrupt in the remove function so there's no outstanding I2C interrupt when the driver is being removed from the framework - Other minor miscellaneous improvements and fixes Changes from v3: - Add config dependency to COMPILE_TEST to allow the driver to be build tested by other platforms - Improve CPU utilization efficiency in the loop of waiting for bus to idle - Add more comment in the driver to clarify the way how the "start busy" interrupt is triggered from the I2C controller - Fix inconsistent coding style and format - Improve the bus speed validation logic in the driver - Add code to free the interrupt line in driver's remove function. Also change to use non-devm API to request the interrupt line - Other miscellaneous improvements and fixes Changes from v2: - Have the I2C driver default to y so it does not need to be selected from ARCH_BCM_IPROC. This also helps to get rid of one patch. The driver still depends on ARCH_BCM_IPROC - Get rid of redundant check on resource returned by platform_get_resource Changes from v1: - Fix function argument parenthesis - Get rid of redundant driver owner field Ray Jui (3): i2c: iProc: define Broadcom iProc I2C binding i2c: iproc: Add Broadcom iProc I2C Driver ARM: dts: add I2C device nodes for Broadcom Cygnus .../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37 ++ arch/arm/boot/dts/bcm-cygnus.dtsi | 20 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-bcm-iproc.c | 493 5 files changed, 561 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c -- 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 v5 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-bcm-iproc.c | 493
3 files changed, 504 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 31e8308..af76d23 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -372,6 +372,16 @@ config I2C_BCM2835
This support is also available as a module. If so, the module
will be called i2c-bcm2835.
+config I2C_BCM_IPROC
+ tristate "Broadcom iProc I2C controller"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
+ help
+ If you say yes to this option, support will be included for the
+ Broadcom iProc I2C controller.
+
+ If you don't know what to do here, say N.
+
config I2C_BCM_KONA
tristate "BCM Kona I2C adapter"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 56388f6..d93b509 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o
+obj-$(CONFIG_I2C_BCM_IPROC)+= i2c-bcm-iproc.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
obj-$(CONFIG_I2C_CADENCE) += i2c-cadence.o
obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
new file mode 100644
index 000..a92d8f5
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -0,0 +1,493 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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
+
+#define CFG_OFFSET 0x00
+#define CFG_RESET_SHIFT 31
+#define CFG_EN_SHIFT 30
+#define CFG_M_RETRY_CNT_SHIFT16
+#define CFG_M_RETRY_CNT_MASK 0x0f
+
+#define TIM_CFG_OFFSET 0x04
+#define TIM_CFG_MODE_400_SHIFT 31
+
+#define M_FIFO_CTRL_OFFSET 0x0c
+#define M_FIFO_RX_FLUSH_SHIFT31
+#define M_FIFO_TX_FLUSH_SHIFT30
+#define M_FIFO_RX_CNT_SHIFT 16
+#define M_FIFO_RX_CNT_MASK 0x7f
+#define M_FIFO_RX_THLD_SHIFT 8
+#define M_FIFO_RX_THLD_MASK 0x3f
+
+#define M_CMD_OFFSET 0x30
+#define M_CMD_START_BUSY_SHIFT 31
+#define M_CMD_STATUS_SHIFT 25
+#define M_CMD_STATUS_MASK0x07
+#define M_CMD_STATUS_SUCCESS 0x0
+#define M_CMD_STATUS_LOST_ARB0x1
+#define M_CMD_STATUS_NACK_ADDR 0x2
+#define M_CMD_STATUS_NACK_DATA 0x3
+#define M_CMD_STATUS_TIMEOUT 0x4
+#define M_CMD_PROTOCOL_SHIFT 9
+#define M_CMD_PROTOCOL_MASK 0xf
+#define M_CMD_PROTOCOL_BLK_WR0x7
+#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PEC_SHIFT 8
+#define M_CMD_RD_CNT_SHIFT 0
+#define M_CMD_RD_CNT_MASK0xff
+
+#define IE_OFFSET0x38
+#define IE_M_RX_FIFO_FULL_SHIFT 31
+#define IE_M_RX_THLD_SHIFT 30
+#define IE_M_START_BUSY_SHIFT28
+
+#define IS_OFFSET0x3c
+#define IS_M_RX_FIFO_FULL_SHIFT 31
+#define IS_M_RX_THLD_SHIFT 30
+#define IS_M_START_BUSY_SHIFT28
+
+#define M_TX_OFFSET 0x40
+#define M_TX_WR_STATUS_SHIFT 31
+#define M_TX_DATA_SHIFT 0
+#define M_TX_DATA_MASK 0xff
+
+#define M_RX_OFFSET 0x44
+#define M_RX_STATUS_SHIFT30
+#define M_RX_STATUS_MASK 0x03
+#define M_RX_PEC_ERR_SHIFT 29
+#define M_RX_DATA_SHIFT 0
+#define M_RX_DATA_MASK 0xff
+
+#define I2C_TIMEOUT_MESC 100
+#define M_TX_RX_FIFO_SIZE64
+
+enum bus_speed_index {
+ I2C_SPD_100K = 0,
+ I2C_SPD_400K,
+};
+
+struct bcm_iproc_i2c_dev {
+ struct device *device;
+
[PATCH 2/8] driver-core: add asynchronous probing support for drivers
Some devices take a long time when initializing, and not all drivers are
suited to initialize their devices when they are open. For example,
input drivers need to interrogate their devices in order to publish
device's capabilities before userspace will open them. When such drivers
are compiled into kernel they may stall entire kernel initialization.
This change allows drivers request for their probe functions to be
called asynchronously during driver and device registration (manual
binding is still synchronous). Because async_schedule is used to perform
asynchronous calls module loading will still wait for the probing to
complete.
This change is based on earlier patch by "Luis R. Rodriguez"
Signed-off-by: Dmitry Torokhov
---
drivers/base/base.h| 1 +
drivers/base/bus.c | 31 +++---
drivers/base/dd.c | 149 ++---
include/linux/device.h | 21 +++
4 files changed, 175 insertions(+), 27 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 251c5d3..fd3347d 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -116,6 +116,7 @@ static inline int driver_match_device(struct device_driver
*drv,
{
return drv->bus->match ? drv->bus->match(dev, drv) : 1;
}
+extern bool driver_allows_async_probing(struct device_driver *drv);
extern int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups);
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 876bae5..a3d71ad 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -10,6 +10,7 @@
*
*/
+#include
#include
#include
#include
@@ -549,15 +550,12 @@ void bus_probe_device(struct device *dev)
{
struct bus_type *bus = dev->bus;
struct subsys_interface *sif;
- int ret;
if (!bus)
return;
- if (bus->p->drivers_autoprobe) {
- ret = device_attach(dev);
- WARN_ON(ret < 0);
- }
+ if (bus->p->drivers_autoprobe)
+ device_initial_probe(dev);
mutex_lock(>p->mutex);
list_for_each_entry(sif, >p->interfaces, node)
@@ -659,6 +657,17 @@ static ssize_t uevent_store(struct device_driver *drv,
const char *buf,
}
static DRIVER_ATTR_WO(uevent);
+static void driver_attach_async(void *_drv, async_cookie_t cookie)
+{
+ struct device_driver *drv = _drv;
+ int ret;
+
+ ret = driver_attach(drv);
+
+ pr_debug("bus: '%s': driver %s async attach completed: %d\n",
+drv->bus->name, drv->name, ret);
+}
+
/**
* bus_add_driver - Add a driver to the bus.
* @drv: driver.
@@ -691,9 +700,15 @@ int bus_add_driver(struct device_driver *drv)
klist_add_tail(>knode_bus, >p->klist_drivers);
if (drv->bus->p->drivers_autoprobe) {
- error = driver_attach(drv);
- if (error)
- goto out_unregister;
+ if (driver_allows_async_probing(drv)) {
+ pr_debug("bus: '%s': probing driver %s
asynchronously\n",
+ drv->bus->name, drv->name);
+ async_schedule(driver_attach_async, drv);
+ } else {
+ error = driver_attach(drv);
+ if (error)
+ goto out_unregister;
+ }
}
module_add_driver(drv->owner, drv);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index cdc779c..f9f4831 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -402,31 +402,95 @@ int driver_probe_device(struct device_driver *drv, struct
device *dev)
return ret;
}
-static int __device_attach(struct device_driver *drv, void *data)
+bool driver_allows_async_probing(struct device_driver *drv)
{
- struct device *dev = data;
+ return drv->probe_type == PROBE_PREFER_ASYNCHRONOUS;
+}
+
+struct device_attach_data {
+ struct device *dev;
+
+ /*
+* Indicates whether we are are considering asynchronous probing or
+* not. Only initial binding after device or driver registration
+* (including deferral processing) may be done asynchronously, the
+* rest is always synchronous, as we expect it is being done by
+* request from userspace.
+*/
+ bool check_async;
+
+ /*
+* Indicates if we are binding synchronous or asynchronous drivers.
+* When asynchronous probing is enabled we'll execute 2 passes
+* over drivers: first pass doing synchronous probing and second
+* doing asynchronous probing (if synchronous did not succeed -
+* most likely because there was no driver requiring synchronous
+* probing - and we found asynchronous driver during first pass).
+* The 2 passes are done because we can't shoot asynchronous
+* probe for given device and driver from bus_for_each_drv() since
+*
[PATCH 7/8] module: add core_param_unsafe
Similarly to module_param_unsafe(), add the helper to be used by core
code wishing to expose unsafe debugging or testing parameters that taint
the kernel when set.
Signed-off-by: Dmitry Torokhov
---
include/linux/moduleparam.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1392370..6480dca 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -310,6 +310,15 @@ static inline void __kernel_param_unlock(void)
#define core_param(name, var, type, perm) \
param_check_##type(name, &(var)); \
__module_param_call("", name, _ops_##type, , perm, -1, 0)
+
+/**
+ * core_param_unsafe - same as core_param but taints kernel
+ */
+#define core_param_unsafe(name, var, type, perm) \
+ param_check_##type(name, &(var)); \
+ __module_param_call("", name, _ops_##type, , perm,\
+ -1, KERNEL_PARAM_FL_UNSAFE)
+
#endif /* !MODULE */
/**
--
2.2.0.rc0.207.ga3a616c
--
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 6/8] amd64_edac: enforce synchronous probe
From: Luis R. Rodriguez
While testing asynchronous PCI probe on this driver I noticed it failed
so enforce just synchronouse probe for now. Asynchronous probe is not
used by default and requires userepace intervention. Patches for its
support will be merged later.
The reason async probe fails is that the init call for this driver
relies on probe to have finished for at least one device. This needs to
be addressed before enabling async probe.
Reviewed-by: Tejun Heo
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Dmitry Torokhov
---
drivers/edac/amd64_edac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 17638d7..58acced 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2983,6 +2983,7 @@ static struct pci_driver amd64_pci_driver = {
.probe = probe_one_instance,
.remove = remove_one_instance,
.id_table = amd64_pci_table,
+ .driver.probe_type = PROBE_FORCE_SYNCHRONOUS,
};
static void setup_pci_device(void)
--
2.2.0.rc0.207.ga3a616c
--
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/8] module: add extra argument for parse_params() callback
From: Luis R. Rodriguez
This adds an extra argument onto parse_params() to be used
as a way to make the unused callback a bit more useful and
generic by allowing the caller to pass on a data structure
of its choice. An example use case is to allow us to easily
make module parameters for every module which we will do
next.
@ parse @
identifier name, args, params, num, level_min, level_max;
identifier unknown, param, val, doing;
type s16;
@@
extern char *parse_args(const char *name,
char *args,
const struct kernel_param *params,
unsigned num,
s16 level_min,
s16 level_max,
+void *arg,
int (*unknown)(char *param, char *val,
const char *doing
+ , void *arg
));
@ parse_mod @
identifier name, args, params, num, level_min, level_max;
identifier unknown, param, val, doing;
type s16;
@@
char *parse_args(const char *name,
char *args,
const struct kernel_param *params,
unsigned num,
s16 level_min,
s16 level_max,
+void *arg,
int (*unknown)(char *param, char *val,
const char *doing
+ , void *arg
))
{
...
}
@ parse_args_found @
expression R, E1, E2, E3, E4, E5, E6;
identifier func;
@@
(
R =
parse_args(E1, E2, E3, E4, E5, E6,
+ NULL,
func);
|
R =
parse_args(E1, E2, E3, E4, E5, E6,
+ NULL,
);
|
R =
parse_args(E1, E2, E3, E4, E5, E6,
+ NULL,
NULL);
|
parse_args(E1, E2, E3, E4, E5, E6,
+ NULL,
func);
|
parse_args(E1, E2, E3, E4, E5, E6,
+ NULL,
);
|
parse_args(E1, E2, E3, E4, E5, E6,
+ NULL,
NULL);
)
@ parse_args_unused depends on parse_args_found @
identifier parse_args_found.func;
@@
int func(char *param, char *val, const char *unused
+, void *arg
)
{
...
}
@ mod_unused depends on parse_args_found @
identifier parse_args_found.func;
expression A1, A2, A3;
@@
- func(A1, A2, A3);
+ func(A1, A2, A3, NULL);
Generated-by: Coccinelle SmPL
Cc: co...@systeme.lip6.fr
Cc: Tejun Heo
Cc: Arjan van de Ven
Cc: Greg Kroah-Hartman
Cc: Rusty Russell
Cc: Christoph Hellwig
Cc: Felipe Contreras
Cc: Ewan Milne
Cc: Jean Delvare
Cc: Hannes Reinecke
Cc: Jani Nikula
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Tejun Heo
Acked-by: Rusty Russell
Signed-off-by: Luis R. Rodriguez
---
arch/powerpc/mm/hugetlbpage.c | 4 ++--
include/linux/moduleparam.h | 3 ++-
init/main.c | 25 +++--
kernel/module.c | 6 --
kernel/params.c | 11 +++
lib/dynamic_debug.c | 4 ++--
6 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 620d0ec..ae0c479 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -336,7 +336,7 @@ int alloc_bootmem_huge_page(struct hstate *hstate)
unsigned long gpage_npages[MMU_PAGE_COUNT];
static int __init do_gpage_early_setup(char *param, char *val,
- const char *unused)
+ const char *unused, void *arg)
{
static phys_addr_t size;
unsigned long npages;
@@ -385,7 +385,7 @@ void __init reserve_hugetlb_gpages(void)
strlcpy(cmdline, boot_command_line, COMMAND_LINE_SIZE);
parse_args("hugetlb gpages", cmdline, NULL, 0, 0, 0,
- _gpage_early_setup);
+ NULL, _gpage_early_setup);
/*
* Walk gpage list in reverse, allocating larger page sizes first.
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1c9effa..1392370 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -357,8 +357,9 @@ extern char *parse_args(const char *name,
unsigned num,
s16 level_min,
s16 level_max,
+ void *arg,
int (*unknown)(char *param, char *val,
- const char *doing));
+const char *doing, void *arg));
/* Called by module remove. */
#ifdef CONFIG_SYSFS
diff --git a/init/main.c b/init/main.c
index cf95428..9596c65 100644
--- a/init/main.c
+++
[PATCH 8/8] driver-core: allow forcing async probing for modules and builtins
From: Luis R. Rodriguez
Folks wishing to test enabling async probe for all built-in drivers
and/or for all modules can enable
__DEBUG__kernel_force_builtin_async_probe or
__DEBUG__kernel_force_modules_async_probe kernel parameters.
Using either one will taint your kernel.
Signed-off-by: Luis R. Rodriguez
[Dmitry: split off from another patch, split into 2 parameters, moved
over to core_param_unsafe()]
Signed-off-by: Dmitry Torokhov
---
Documentation/kernel-parameters.txt | 10 ++
drivers/base/dd.c | 13 +
kernel/module.c | 7 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index af034a2..b09c4ac 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -931,6 +931,16 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
module.async_probe [KNL]
Enable asynchronous probe on this module.
+ __DEBUG__kernel_force_builtin_async_probe [KNL]
+ Enable asynchronous probe on all built-in drivers.
+ This is is testing parameter and using it will taint
+ your kernel.
+
+ __DEBUG__kernel_force_modules_async_probe [KNL]
+ Enable asynchronous probe on all modules. This is
+ is testing parameter and using it will taint your
+ kernel.
+
early_ioremap_debug [KNL]
Enable debug messages in early_ioremap support. This
is useful for tracking down temporary early mappings
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 1308e08..4d00734 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -402,6 +403,10 @@ int driver_probe_device(struct device_driver *drv, struct
device *dev)
return ret;
}
+static bool force_builtin_async_probe;
+core_param_unsafe(__DEBUG__kernel_force_builtin_async_probe,
+ force_builtin_async_probe, bool, 0644);
+
bool driver_allows_async_probing(struct device_driver *drv)
{
switch (drv->probe_type) {
@@ -412,10 +417,10 @@ bool driver_allows_async_probing(struct device_driver
*drv)
return false;
default:
- if (drv->owner && drv->owner->async_probe_requested)
- return true;
-
- return false;
+ if (drv->owner)
+ return drv->owner->async_probe_requested;
+ else
+ return force_builtin_async_probe;
}
}
diff --git a/kernel/module.c b/kernel/module.c
index 80639fa..8d667ef 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3196,6 +3196,10 @@ static int unknown_module_param_cb(char *param, char
*val, const char *modname,
return 0;
}
+static bool force_modules_async_probe;
+core_param_unsafe(__DEBUG__kernel_force_modules_async_probe,
+ force_modules_async_probe, bool, 0644);
+
/* Allocate and load the module: note that size of section 0 is always
zero, and we rely on this for optional sections. */
static int load_module(struct load_info *info, const char __user *uargs,
@@ -3290,6 +3294,9 @@ static int load_module(struct load_info *info, const char
__user *uargs,
if (err)
goto ddebug_cleanup;
+ if (force_modules_async_probe)
+ mod->async_probe_requested = true;
+
/* Module is ready to execute: parsing args may do that. */
after_dashes = parse_args(mod->name, mod->args, mod->kp, mod->num_kp,
-32768, 32767, NULL,
--
2.2.0.rc0.207.ga3a616c
--
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/8] driver-core: add driver module asynchronous probe support
From: Luis R. Rodriguez
Some init systems may wish to express the desire to have device drivers
run their probe() code asynchronously. This implements support for this
and allows userspace to request async probe as a preference through a
generic shared device driver module parameter, async_probe.
Implementation for async probe is supported through a module parameter
given that since synchronous probe has been prevalent for years some
userspace might exist which relies on the fact that the device driver
will probe synchronously and the assumption that devices it provides
will be immediately available after this.
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Dmitry Torokhov
---
Documentation/kernel-parameters.txt | 3 +++
drivers/base/dd.c | 8 +++-
include/linux/device.h | 8 +---
include/linux/module.h | 2 ++
kernel/module.c | 12 ++--
5 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 176d4fe..af034a2 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -928,6 +928,9 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Enable debug messages at boot time. See
Documentation/dynamic-debug-howto.txt for details.
+ module.async_probe [KNL]
+ Enable asynchronous probe on this module.
+
early_ioremap_debug [KNL]
Enable debug messages in early_ioremap support. This
is useful for tracking down temporary early mappings
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index f9f4831..b3ec0aa 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -404,7 +404,13 @@ int driver_probe_device(struct device_driver *drv, struct
device *dev)
bool driver_allows_async_probing(struct device_driver *drv)
{
- return drv->probe_type == PROBE_PREFER_ASYNCHRONOUS;
+ if (drv->probe_type == PROBE_PREFER_ASYNCHRONOUS)
+ return true;
+
+ if (drv->owner && drv->owner->async_probe_requested)
+ return true;
+
+ return false;
}
struct device_attach_data {
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ace4c0..ae5a165 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -200,16 +200,18 @@ extern struct klist *bus_get_device_klist(struct bus_type
*bus);
*respective probe routines. This tells the core what to
*expect and prefer.
*
- * @PROBE_SYNCHRONOUS: Default. Drivers expect their probe routines
+ * @PROBE_DEFAULT_STRATEGY: Drivers expect their probe routines
*to run synchronously with driver and device registration
*(with the exception of -EPROBE_DEFER handling - re-probing
- *always ends up being done asynchronously).
+ *always ends up being done asynchronously) unless user
+ *explicitly requested asynchronous probing via module
+ *parameter.
* @PROBE_PREFER_ASYNCHRONOUS: Drivers for "slow" devices which
*probing order is not essential for booting the system may
*opt into executing their probes asynchronously.
*/
enum probe_type {
- PROBE_SYNCHRONOUS,
+ PROBE_DEFAULT_STRATEGY,
PROBE_PREFER_ASYNCHRONOUS,
};
diff --git a/include/linux/module.h b/include/linux/module.h
index ebfb0e1..2b70e71 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -257,6 +257,8 @@ struct module {
bool sig_ok;
#endif
+ bool async_probe_requested;
+
/* symbols that will be GPL-only in the near future. */
const struct kernel_symbol *gpl_future_syms;
const unsigned long *gpl_future_crcs;
diff --git a/kernel/module.c b/kernel/module.c
index f5b28b6..80639fa 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3042,7 +3042,7 @@ static int do_init_module(struct module *mod)
*
* http://thread.gmane.org/gmane.linux.kernel/1420814
*/
- if (current->flags & PF_USED_ASYNC)
+ if (!mod->async_probe_requested && (current->flags & PF_USED_ASYNC))
async_synchronize_full();
mutex_lock(_mutex);
@@ -3181,8 +3181,16 @@ out:
static int unknown_module_param_cb(char *param, char *val, const char *modname,
void *arg)
{
+ struct module *mod = arg;
+ int ret;
+
+ if (strcmp(param, "async_probe") == 0) {
+ mod->async_probe_requested = true;
+ return 0;
+ }
+
/* Check for magic 'dyndbg' arg */
- int ret = ddebug_dyndbg_module_param_cb(param, val, modname);
+ ret = ddebug_dyndbg_module_param_cb(param, val, modname);
if (ret != 0)
pr_warn("%s: unknown parameter '%s' ignored\n", modname, param);
return 0;
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this
[PATCH 4/8] driver-core: enable drivers to opt-out of async probe
From: Luis R. Rodriguez
Some drivers do not work well when their probes are run asynchronously.
Usually it is because driver bug or not optimal driver organization.
Until they are all fixed properly let's allow them opt out of
asynchronous probing.
Signed-off-by: Luis R. Rodriguez
Signed-off-by: Dmitry Torokhov
---
drivers/base/dd.c | 14 ++
include/linux/device.h | 15 +--
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index b3ec0aa..1308e08 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -404,13 +404,19 @@ int driver_probe_device(struct device_driver *drv, struct
device *dev)
bool driver_allows_async_probing(struct device_driver *drv)
{
- if (drv->probe_type == PROBE_PREFER_ASYNCHRONOUS)
+ switch (drv->probe_type) {
+ case PROBE_PREFER_ASYNCHRONOUS:
return true;
- if (drv->owner && drv->owner->async_probe_requested)
- return true;
+ case PROBE_FORCE_SYNCHRONOUS:
+ return false;
+
+ default:
+ if (drv->owner && drv->owner->async_probe_requested)
+ return true;
- return false;
+ return false;
+ }
}
struct device_attach_data {
diff --git a/include/linux/device.h b/include/linux/device.h
index ae5a165..a17e46f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -200,19 +200,21 @@ extern struct klist *bus_get_device_klist(struct bus_type
*bus);
*respective probe routines. This tells the core what to
*expect and prefer.
*
- * @PROBE_DEFAULT_STRATEGY: Drivers expect their probe routines
- *to run synchronously with driver and device registration
- *(with the exception of -EPROBE_DEFER handling - re-probing
- *always ends up being done asynchronously) unless user
- *explicitly requested asynchronous probing via module
- *parameter.
+ * @PROBE_DEFAULT_STRATEGY: Used by drivers that are normally probed
+ *synchronously, but work just as fine when probed asynchronously
+ *when user requests it via module parameter.
* @PROBE_PREFER_ASYNCHRONOUS: Drivers for "slow" devices which
*probing order is not essential for booting the system may
*opt into executing their probes asynchronously.
+ * @PROBE_FORCE_SYNCHRONOUS: Use this to annotate drivers that need
+ *their probe routines to run synchronously with driver and
+ *device registration (with the exception of -EPROBE_DEFER
+ *handling - re-probing always ends up being done asynchronously).
*/
enum probe_type {
PROBE_DEFAULT_STRATEGY,
PROBE_PREFER_ASYNCHRONOUS,
+ PROBE_FORCE_SYNCHRONOUS,
};
/**
@@ -222,6 +224,7 @@ enum probe_type {
* @owner: The module owner.
* @mod_name: Used for built-in modules.
* @suppress_bind_attrs: Disables bind/unbind via sysfs.
+ * @probe_type: type of probe to use
* @of_match_table: The open firmware table.
* @acpi_match_table: The ACPI match table.
* @probe: Called to query the existence of a specific device,
--
2.2.0.rc0.207.ga3a616c
--
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/8] driver-core: platform_driver_probe() must probe synchronously
Because it checks, after trying to register driver, if there are any
devices that driver successfully bound to, driver's probe routine must
be run synchronously.
Signed-off-by: Dmitry Torokhov
---
drivers/base/platform.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9421fed..5c9e1b6 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -604,6 +604,19 @@ int __init_or_module __platform_driver_probe(struct
platform_driver *drv,
{
int retval, code;
+ if (drv->driver.probe_type == PROBE_PREFER_ASYNCHRONOUS) {
+ pr_err("%s: drivers registered with %s can not be probed
asynchronously\n",
+drv->driver.name, __func__);
+ return -EINVAL;
+ }
+
+ /*
+* We have to run our probes synchronously because we check if
+* we find any devices to bind to and exit with error if there
+* are any.
+*/
+ drv->driver.probe_type = PROBE_FORCE_SYNCHRONOUS;
+
/*
* Prevent driver from requesting probe deferral to avoid further
* futile probe attempts.
--
2.2.0.rc0.207.ga3a616c
--
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/8] Asynchronous device/driver probing support
This series is a combination of changes proposed by Luis a couple months ago and implementation used by Chrome OS. The issue we are trying to solve here is "slow" devices and drivers spending "too much time" in their probe() methods and it affects: - overall kernel boot process when drivers are compiled into the kernel and slow devices stall entire boot progress; - systemd desire to time out module loading process. Unlike Luis' proposal we do make use of asycn_schedule() infrastructure instead of using a dedicated workqueue, so all existing synchronization points in kernel that wait for device registration still work the same. Also, the asynchronous probing is done not only during driver registration (i.e. when devices are probed asynchronously only if they are registered before the driver), but also during device registration and deferred probe handling. This way slow devices do not stall kernel boot even when drivers are compiled into the kernel. The last patch is for adventurous people to try and force fully-asynchronous boot. It works for me with limited success - I can boot Rockhip-based box to userspace as long as I force serial to be sychronously probed and ignore the fact that most devices are using "dummy" regulators as regulator subsystem really expects regulators to be registered in orderly fashion on OF-based systems. Thanks, Dmitry Dmitry Torokhov (3): driver-core: add asynchronous probing support for drivers driver-core: platform_driver_probe() must probe synchronously module: add core_param_unsafe Luis R. Rodriguez (5): module: add extra argument for parse_params() callback driver-core: add driver module asynchronous probe support driver-core: enable drivers to opt-out of async probe amd64_edac: enforce synchronous probe driver-core: allow forcing async probing for modules and builtins Documentation/kernel-parameters.txt | 13 +++ arch/powerpc/mm/hugetlbpage.c | 4 +- drivers/base/base.h | 1 + drivers/base/bus.c | 31 +-- drivers/base/dd.c | 166 +++- drivers/base/platform.c | 13 +++ drivers/edac/amd64_edac.c | 1 + include/linux/device.h | 26 ++ include/linux/module.h | 2 + include/linux/moduleparam.h | 12 ++- init/main.c | 25 +++--- kernel/module.c | 25 +- kernel/params.c | 11 ++- lib/dynamic_debug.c | 4 +- 14 files changed, 284 insertions(+), 50 deletions(-) -- 2.2.0.rc0.207.ga3a616c -- 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 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
On 1/16/2015 11:48 AM, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Jan 16, 2015 at 11:24:09AM -0800, Ray Jui wrote:
+ i2c0: i2c@18008000 {
+ compatible = "brcm,iproc-i2c";
>>> in patch 2 you wrote the driver is for a family of SoCs, right? Then I'd
>>> make this:
>>>
>>> compatible = "brcm,$mysoc-iproc-i2c", "brcm,iproc-i2c";
>>>
>> Sorry could you please help to explain the intention here? Note the
>> iProc I2C IP can be found in various iProc family of SoCs, but to my
>> best knowledge, there hasn't been any changes of the IP in any of those
>> SoCs.
> This is just for making the device tree stable in the future. Consider
> your gentle hardware engineers "fix" a small issue for the next
> generation iproc SoC "pony" that needs an incompatible software change.
>
> Then you can fix the driver without updating the device trees by
> switching to the SoC specific compatible string for "pony". And in case
> the hardware engineers didn't tell you that there is a change and the
> need for the software change is only detected when the machines are
> already shipped, you're happy if you can fix your kernel without needing
> to change the bootloader that provides the dtb.
> So start already today to add the (for now unused) compatible string.
>
>> Is the compatible ID "brcm,$mysoc-iproc-i2c" only to clarify that it's
>> for a specific SoC? If so, what should the compatible ID array look
>> like? Should it be changed to the following?
>>
>> static const struct of_device_id bcm_iproc_i2c_of_match[] = {
>> { .compatible = "brcm,iproc-i2c" },
>> { .compatible = "brcm,$mysoc-iproc-i2c" },
>> {},
>> };
> No, there is no need, see above.
>
> If something is still unclear, don't hesitate to ask.
>
> Best regards
> Uwe
>
Okay got it. Thanks for the explanation!
--
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 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()
On Fri, Jan 16, 2015 at 3:15 PM, Yinghai Lu wrote: > On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang wrote: >> Pci_bus_add_devices() should not be placed in pci_scan_bus(). >> Now pci device will be added to driver core once its >> creation. All things left in pci_bus_add_devices() are >> driver attachment and other trivial sysfs things. >> Pci_scan_bus() should be the function responsible for >> scanning PCI devices, not including driver attachment. >> Other, some callers(m68k,unicore32,alpha) of pci_scan_bus() >> will call pci_bus_size_bridges() and pci_bus_assign_resources() >> after pci_scan_bus(). >> >> E.g. >> In m68k >> mcf_pci_init() >> pci_scan_bus() >> ... >> pci_bus_add_devices() --- try to attach driver >> pci_fixup_irqs() >> pci_bus_size_bridges() >> pci_bus_assign_resources() >> >> It is not correct, resources should be assigned correctly >> before attaching driver. > No, for booting path, at that time pci drivers are *NOT* loaded yet. Thanks 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/
Re: [PATCH 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()
On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang wrote: > Pci_bus_add_devices() should not be placed in pci_scan_bus(). > Now pci device will be added to driver core once its > creation. All things left in pci_bus_add_devices() are > driver attachment and other trivial sysfs things. > Pci_scan_bus() should be the function responsible for > scanning PCI devices, not including driver attachment. > Other, some callers(m68k,unicore32,alpha) of pci_scan_bus() > will call pci_bus_size_bridges() and pci_bus_assign_resources() > after pci_scan_bus(). > > E.g. > In m68k > mcf_pci_init() > pci_scan_bus() > ... > pci_bus_add_devices() --- try to attach driver > pci_fixup_irqs() > pci_bus_size_bridges() > pci_bus_assign_resources() > > It is not correct, resources should be assigned correctly > before attaching driver. No, at that time pci drivers are loaded yet. Thanks 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/
Re: [PATCH] MAINTAINERS: Add entry for Maxim PMIC-s on Samsung boards
On Fri, Jan 16, 2015 at 12:19:50PM +0100, Krzysztof Kozlowski wrote: > Add myself as supporter for Maxim 77686 PMIC and Maxim 14577/77693 MUIC > drivers: Acked-by: Mark Brown (and any future versions adding Chanwoo or other people.) signature.asc Description: Digital signature
Re: [PATCH] MAINTAINERS: Add entry for Maxim PMIC-s on Samsung boards
On Fri, Jan 16, 2015 at 9:21 PM, Krzysztof Kozlowski wrote: > On pią, 2015-01-16 at 20:51 +0900, Chanwoo Choi wrote: >> Hi Krzysztof, >> >> On 01/16/2015 08:19 PM, Krzysztof Kozlowski wrote: >> > Add myself as supporter for Maxim 77686 PMIC and Maxim 14577/77693 MUIC >> > drivers: >> > - mfd (all of them), >> > - extcon (extcon-max14577, extcon-max77693) >> > - power (max14577_charger.c, 77693 on LKML [1]), >> > - regulator (all of them), >> > - clock (clk-max77686.c) >> > - RTC (rtc-max77686.c). >> > >> > Lately I am the author of major contributors to them. These >> > drivers are used on Exynos-based boards (Trats 2, Gear 1 and Gear 2). >> > >> > [1] https://lkml.org/lkml/2015/1/5/139 >> > >> > Signed-off-by: Krzysztof Kozlowski >> > Cc: MyungJoo Ham >> > cc: Chanwoo Choi >> > Cc: Samuel Ortiz >> > Cc: Lee Jones >> > Cc: Sebastian Reichel >> > Cc: Dmitry Eremin-Solenikov >> > Cc: David Woodhouse >> > Cc: Liam Girdwood >> > Cc: Mark Brown >> > Cc: Mike Turquette >> > Cc: Stephen Boyd >> > Cc: Alessandro Zummo >> > --- >> > MAINTAINERS | 15 +++ >> > 1 file changed, 15 insertions(+) >> > >> > diff --git a/MAINTAINERS b/MAINTAINERS >> > index f017a30eb280..b033fb499186 100644 >> > --- a/MAINTAINERS >> > +++ b/MAINTAINERS >> > @@ -6143,6 +6143,21 @@ F: >> > Documentation/devicetree/bindings/i2c/max6697.txt >> > F: drivers/hwmon/max6697.c >> > F: include/linux/platform_data/max6697.h >> > >> > +MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS >> > +M: Krzysztof Kozlowski >> > +L: linux-kernel@vger.kernel.org >> > +S: Supported >> > +F: drivers/*/*max14577*.c >> > +F: drivers/*/*max77686*.c >> > +F: drivers/*/*max77693*.c >> >> I knew that you did implement max14577 series because I did cowork to >> implement it with you. >> >> But, >> The drivers/extcon/extcon-max77693.c was implemented by me >> and extcon-max14577.c was implemented by me and you. >> >> The initial version of drivers/mfd/max77876.c, drivers/regulator/max77686.c >> was implemented by Jonghwa Lee(jonghwa3@samsung.com). >> >> The initial version of drivers/mfd/max77693.c was implmented by me >> and drivers/mfd/max77693.c by Jonghwa Lee. >> > > Yes, your are right. However I do not change the ownership or authorship > of these drivers here. You and the others will still be the authors. > Being the initial author is somehow different then reviewing and > developing the driver further. > > Although you didn't say that explicitly here but if you think there > should be an entry also for you than I would appreciate it fully. Yes, If you agree,I think you better add an entry for me. Except for power-supply drivers, I did co-work to implement these drivers with you. Best Regards, Chanwoo Choi -- 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] [media] cx231xx: fix usbdev leak on failure paths in cx231xx_usb_probe()
Commit b7085c086475 ("cx231xx: convert from pr_foo to dev_foo")
moves usb_get_dev(interface_to_usbdev(interface)) to the beginning
of cx231xx_usb_probe() to use udev->dev in dev_err(),
but it does not make sure usbdev is put on all failure paths.
Later dev_err(udev->dev) was replaced by dev_err(d).
So the patch moves usb_get_dev() below (before the first use)
and fixes another failure path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index ae05d591f228..33c2fa2e7596 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1403,7 +1403,6 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
struct usb_interface_assoc_descriptor *assoc_desc;
ifnum = interface->altsetting[0].desc.bInterfaceNumber;
- udev = usb_get_dev(interface_to_usbdev(interface));
/*
* Interface number 0 - IR interface (handled by mceusb driver)
@@ -1424,11 +1423,13 @@ static int cx231xx_usb_probe(struct usb_interface
*interface,
}
} while (test_and_set_bit(nr, _devused));
+ udev = usb_get_dev(interface_to_usbdev(interface));
+
/* allocate memory for our device state and initialize it */
dev = devm_kzalloc(>dev, sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
- clear_bit(nr, _devused);
- return -ENOMEM;
+ retval = -ENOMEM;
+ goto err_if;
}
snprintf(dev->name, 29, "cx231xx #%d", nr);
--
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/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 1/15/2015 4:07 AM, Wolfram Sang wrote:
>>> +static int bcm_iproc_i2c_remove(struct platform_device *pdev)
>>> +{
>>> + struct bcm_iproc_i2c_dev *iproc_i2c = platform_get_drvdata(pdev);
>>> +
>>> + i2c_del_adapter(_i2c->adapter);
>> You need to free the irq before i2c_del_adapter.
>
> One could also keep using devm_request_irq and disable all interrupts
> sources here?
>
Okay this makes sense. Will use devm_request_irq and disable interrupt
in the remove function. Thanks.
> Thanks for the reviews, Uwe!
>
>Wolfram
>
--
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] ddr: Use less generic identifiers
Am 04.01.2015 um 16:48 schrieb Richard Weinberger:
> At least on UML this identifiers clash with register names.
> Use something less generic than Rx, Cx and Cx.
>
> CC lib//jedec_ddr_data.o
> In file included from ./arch/um/include/asm/ptrace-generic.h:11:0,
> from ./arch/x86/um/asm/ptrace.h:8,
> from ./arch/x86/include/asm/alternative.h:8,
> from ./arch/x86/include/asm/bitops.h:16,
> from include/linux/bitops.h:36,
> from include/linux/kernel.h:10,
> from include/linux/list.h:8,
> from include/linux/module.h:9,
> from lib//jedec_ddr_data.c:14:
> ./arch/x86/include/uapi/asm/ptrace-abi.h:28:0: warning: "R15" redefined
> [enabled by default]
> #define R15 0
>
> Signed-off-by: Richard Weinberger
> ---
> Please note that this patch is untested.
>
> Thanks,
> //richard
> ---
> drivers/memory/emif.c | 4 ++--
> include/memory/jedec_ddr.h | 36 ++--
> lib/jedec_ddr_data.c | 20 ++--
> 3 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
> index 04644e7..e0aa09f 100644
> --- a/drivers/memory/emif.c
> +++ b/drivers/memory/emif.c
> @@ -439,7 +439,7 @@ static u32 get_sdram_tim_1_shdw(const struct
> lpddr2_timings *timings,
> val = max(min_tck->tWTR, DIV_ROUND_UP(timings->tWTR, t_ck)) - 1;
> tim1 |= val << T_WTR_SHIFT;
>
> - if (addressing->num_banks == B8)
> + if (addressing->num_banks == DDR_BANK_8)
> val = DIV_ROUND_UP(timings->tFAW, t_ck*4);
> else
> val = max(min_tck->tRRD, DIV_ROUND_UP(timings->tRRD, t_ck));
> @@ -476,7 +476,7 @@ static u32 get_sdram_tim_1_shdw_derated(const struct
> lpddr2_timings *timings,
>* tFAW is approximately 4 times tRRD. So add 1875*4 = 7500ps
>* to tFAW for de-rating
>*/
> - if (addressing->num_banks == B8) {
> + if (addressing->num_banks == DDR_BANK_8) {
> val = DIV_ROUND_UP(timings->tFAW + 7500, 4 * t_ck) - 1;
> } else {
> val = DIV_ROUND_UP(timings->tRRD + 1875, t_ck);
> diff --git a/include/memory/jedec_ddr.h b/include/memory/jedec_ddr.h
> index ddad0f8..39144d0 100644
> --- a/include/memory/jedec_ddr.h
> +++ b/include/memory/jedec_ddr.h
> @@ -40,28 +40,28 @@
> #define DDR_IO_WIDTH_32 4
>
> /* Number of Row bits */
> -#define R9 9
> -#define R10 10
> -#define R11 11
> -#define R12 12
> -#define R13 13
> -#define R14 14
> -#define R15 15
> -#define R16 16
> +#define DDR_ROW_99
> +#define DDR_ROW_10 10
> +#define DDR_ROW_11 11
> +#define DDR_ROW_12 12
> +#define DDR_ROW_13 13
> +#define DDR_ROW_14 14
> +#define DDR_ROW_15 15
> +#define DDR_ROW_16 16
>
> /* Number of Column bits */
> -#define C7 7
> -#define C8 8
> -#define C9 9
> -#define C10 10
> -#define C11 11
> -#define C12 12
> +#define DDR_COL_77
> +#define DDR_COL_88
> +#define DDR_COL_99
> +#define DDR_COL_10 10
> +#define DDR_COL_11 11
> +#define DDR_COL_12 12
>
> /* Number of Banks */
> -#define B1 0
> -#define B2 1
> -#define B4 2
> -#define B8 3
> +#define DDR_BANK_1 0
> +#define DDR_BANK_2 1
> +#define DDR_BANK_4 2
> +#define DDR_BANK_8 3
>
> /* Refresh rate in nano-seconds */
> #define T_REFI_15_6 15600
> diff --git a/lib/jedec_ddr_data.c b/lib/jedec_ddr_data.c
> index 6d2cbf1..2181be4 100644
> --- a/lib/jedec_ddr_data.c
> +++ b/lib/jedec_ddr_data.c
> @@ -16,16 +16,16 @@
> /* LPDDR2 addressing details from JESD209-2 section 2.4 */
> const struct lpddr2_addressing
> lpddr2_jedec_addressing_table[NUM_DDR_ADDR_TABLE_ENTRIES] = {
> - {B4, T_REFI_15_6, T_RFC_90}, /* 64M */
> - {B4, T_REFI_15_6, T_RFC_90}, /* 128M */
> - {B4, T_REFI_7_8, T_RFC_90}, /* 256M */
> - {B4, T_REFI_7_8, T_RFC_90}, /* 512M */
> - {B8, T_REFI_7_8, T_RFC_130}, /* 1GS4 */
> - {B8, T_REFI_3_9, T_RFC_130}, /* 2GS4 */
> - {B8, T_REFI_3_9, T_RFC_130}, /* 4G */
> - {B8, T_REFI_3_9, T_RFC_210}, /* 8G */
> - {B4, T_REFI_7_8, T_RFC_130}, /* 1GS2 */
> - {B4, T_REFI_3_9, T_RFC_130}, /* 2GS2 */
> + {DDR_BANK_4, T_REFI_15_6, T_RFC_90}, /* 64M */
> + {DDR_BANK_4, T_REFI_15_6, T_RFC_90}, /* 128M */
> + {DDR_BANK_4, T_REFI_7_8, T_RFC_90}, /* 256M */
> + {DDR_BANK_4, T_REFI_7_8, T_RFC_90}, /* 512M */
> + {DDR_BANK_8, T_REFI_7_8, T_RFC_130}, /* 1GS4 */
> + {DDR_BANK_8,
Re: [PATCH v3 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 1/15/2015 3:59 AM, Wolfram Sang wrote: + case M_CMD_STATUS_LOST_ARB: + dev_err(dev->device, "lost bus arbitration\n"); >>> I wouldn't dev_err that, only dev_dbg. I'm not sure how usual the errors >>> for the next two cases is, maybe degrade them to dev_dbg, too? >>> >> These errors are rare, and it's nice to keep them at the dev_err level >> so the user will be more aware. > > This is wrong. Arbitration lost and NACK is pretty standard stuff on an > I2C bus. User doesn't need to know about it, it is just noise in the > logs. Timeout is different, you can report that (although I should > probably move such a message into the core). Please also use the proper > errno codes defined in Documentation/i2c/fault-codes. They should be > distinct enough to drop the messages. > Okay will do. >> + return -EREMOTEIO; + + case M_CMD_STATUS_NACK_ADDR: + dev_err(dev->device, "NAK addr:0x%02x\n", dev->msg->addr); + return -EREMOTEIO; + + case M_CMD_STATUS_NACK_DATA: + dev_err(dev->device, "NAK data\n"); + return -EREMOTEIO; + + case M_CMD_STATUS_TIMEOUT: + dev_err(dev->device, "bus timeout\n"); + return -ETIMEDOUT; + + default: + dev_err(dev->device, "unknown error code=%d\n", val); + return -EREMOTEIO; + } + + return -EREMOTEIO; +} -- 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/4 v4] brd: Fix all partitions BUGs
On 01/16/2015 03:32 PM, Tony Luck wrote: > On Wed, Jan 7, 2015 at 8:07 AM, Boaz Harrosh wrote: >> From: Boaz Harrosh >> >> This patch fixes up brd's partitions scheme, now enjoying all worlds. > > linux-next-20150116 includes this as commit > 937af5ecd0591e84ee54180fa97dcbe9bbe5fed6 > > On ia64 I'm seeing: > ram0: unknown partition table > ram1: unknown partition table > ... > ram15: unknown partition table > > At first I blamed c8fa31730fc7 "brd: Request from fdisk 4k alignment" because > it > has all sorts of comments about PAGE_SIZE and 4k ... and my page size isn't > 4k. But, reverting that one didn't help. > > reverting 937af5ecd0 does make the message go away. Boaz, why wasn't GENHD_FL_SUPPRESS_PARTITION_INFO retained? -- Jens Axboe -- 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] i2c-ocores: add common clock support
> "Max" == Max Filippov writes: > Allow bus clock specification as a common clock handle. This makes this > controller easier to use in a setup based on common clock framework. > Signed-off-by: Max Filippov Looks sensible to me - Thanks. Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard -- 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] Documentation: fix blackfin gptimers-example build errors
From: Randy Dunlap Don't build the blackfin gptimers-example module when BFIN_GPTIMERS is not enabled. Allow the build when BFIN_GPTIMERS is =y or =m. I believe that this patch fixes these build errors, but I don't have a build environment to test this. ERROR: "disable_gptimers" [Documentation/blackfin/gptimers-example.ko] undefined! ERROR: "enable_gptimers" [Documentation/blackfin/gptimers-example.ko] undefined! ERROR: "set_gptimer_config" [Documentation/blackfin/gptimers-example.ko] undefined! ERROR: "clear_gptimer_intr" [Documentation/blackfin/gptimers-example.ko] undefined! ERROR: "get_gptimer_period" [Documentation/blackfin/gptimers-example.ko] undefined! ERROR: "get_gptimer_pwidth" [Documentation/blackfin/gptimers-example.ko] undefined! ERROR: "get_gptimer_intr" [Documentation/blackfin/gptimers-example.ko] undefined! Reported-by: Fenggaung Wu Signed-off-by: Randy Dunlap --- Documentation/blackfin/Makefile |2 ++ 1 file changed, 2 insertions(+) --- lnx-319-rc4.orig/Documentation/blackfin/Makefile +++ lnx-319-rc4/Documentation/blackfin/Makefile @@ -1,3 +1,5 @@ ifneq ($(CONFIG_BLACKFIN),) +ifneq ($(CONFIG_BFIN_GPTIMERS,) obj-m := gptimers-example.o endif +endif -- 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/4 v4] brd: Fix all partitions BUGs
On Wed, Jan 7, 2015 at 8:07 AM, Boaz Harrosh wrote: > From: Boaz Harrosh > > This patch fixes up brd's partitions scheme, now enjoying all worlds. linux-next-20150116 includes this as commit 937af5ecd0591e84ee54180fa97dcbe9bbe5fed6 On ia64 I'm seeing: ram0: unknown partition table ram1: unknown partition table ... ram15: unknown partition table At first I blamed c8fa31730fc7 "brd: Request from fdisk 4k alignment" because it has all sorts of comments about PAGE_SIZE and 4k ... and my page size isn't 4k. But, reverting that one didn't help. reverting 937af5ecd0 does make the message go away. -Tony -- 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] clk: fractional-divider: prevent division by zero
On 01/16/2015 04:37 AM, Heikki Krogerus wrote:
> Preventing division by zero condition by making sure that
> the initial n and m values are not 0.
>
> Signed-off-by: Heikki Krogerus
> ---
> drivers/clk/clk-fractional-divider.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/clk/clk-fractional-divider.c
> b/drivers/clk/clk-fractional-divider.c
> index 82a59d0..dc91da7 100644
> --- a/drivers/clk/clk-fractional-divider.c
> +++ b/drivers/clk/clk-fractional-divider.c
> @@ -104,6 +104,7 @@ struct clk *clk_register_fractional_divider(struct device
> *dev,
> struct clk_fractional_divider *fd;
> struct clk_init_data init;
> struct clk *clk;
> + u32 val;
>
> fd = kzalloc(sizeof(*fd), GFP_KERNEL);
> if (!fd) {
> @@ -126,6 +127,14 @@ struct clk *clk_register_fractional_divider(struct
> device *dev,
> fd->lock = lock;
> fd->hw.init =
>
> + /* Prevent division by zero */
> + val = clk_readl(fd->reg);
> + if (!(val & fd->nmask))
> + val |= 1 << fd->nshift;
> + if (!(val & fd->mmask))
> + val |= 1 << fd->mshift;
> + clk_writel(val, fd->reg);
> +
> clk = clk_register(dev, >hw);
> if (IS_ERR(clk))
> kfree(fd);
Sorry I don't understand this at all. Does your hardware support a value
of 0 in the register? Doesn't that mean "bypass" so that the rate of the
parent bypasses the divider? If so, why aren't we fixing the
recalc_rate() logic to check for a special case of 0?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] sysfs: group: allow is_visible to drop permissions
On Fri, Jan 16, 2015 at 04:29:10PM -0500, Vivien Didelot wrote:
> Using the optional is_visible function, it is actually possible to
> either hide an attribute, or add a new permission, but not remove one.
What code wants to remove attributes?
> This commit uses all the UGO bits returned by is_visible instead of
> OR'ing them with the default attribute mode.
>
> Concretely, this allows a driver to use macros like DEVICE_ATTR_RW to
> set the attribute show and store functions and remove the S_IWUSR
> permission in is_visible if the implementation doesn't provide a setter.
What bus wants to do this?
> Signed-off-by: Vivien Didelot
> ---
> fs/sysfs/group.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index 7d2a860..a8cfe03 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -41,7 +41,7 @@ static int create_files(struct kernfs_node *parent, struct
> kobject *kobj,
>
> if (grp->attrs) {
> for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> - umode_t mode = 0;
> + umode_t mode = (*attr)->mode;
>
> /*
>* In update mode, we're changing the permissions or
> @@ -51,13 +51,15 @@ static int create_files(struct kernfs_node *parent,
> struct kobject *kobj,
> if (update)
> kernfs_remove_by_name(parent, (*attr)->name);
> if (grp->is_visible) {
> - mode = grp->is_visible(kobj, *attr, i);
> - if (!mode)
> + umode_t ugo = grp->is_visible(kobj, *attr, i);
> +
> + if (!(ugo & S_IRWXUGO))
> continue;
> +
> + mode = (mode & ~S_IRWXUGO) | (ugo & S_IRWXUGO);
Please document what you are doing here in the code, it's not obvious at
first glance.
> }
> error = sysfs_add_file_mode_ns(parent, *attr, false,
> -(*attr)->mode | mode,
> -NULL);
> +mode, NULL);
Any chance this is going to break existing code that isn't expecting
this type of change in functionality?
thanks,
greg k-h
--
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 00/13] Add kdbus implementation
On Fri, Jan 16, 2015 at 05:07:25PM -0500, Josh Boyer wrote: > On Fri, Jan 16, 2015 at 2:16 PM, Greg Kroah-Hartman > wrote: > > This can also be found in a git tree, the kdbus branch of char-misc.git at: > > https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/ > > Is this now the canonical tree? I ask because the github tree hasn't > been updated in quite some time. That's my fault, it's just a mirror of the code.google.com tree for people who like to use github. It's now updated. > The code.google.com tree has commits > from 2 days ago, but it still calls d_materialise_unique in fs.c > whereas the patchset you've posted uses the correct d_splice_alias. > So the code.google.com tree doesn't actually compile against 3.19-rcX. > > I'm confused where we're supposed to track things now. I think the google tree is the "correct" one, but when generating patches, apis are tweaked to work properly with the latest -rc kernel for submission. Daniel knows more though, he's the one generating the patchsets, I don't know how he's doing it exactly. thanks, greg k-h -- 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/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 1/15/2015 12:41 AM, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Jan 14, 2015 at 02:23:32PM -0800, Ray Jui wrote:
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
> some of them are not needed. I tested on amd64 and efm32 and could drop
> linux/device.h, linux/sched.h, linux/clk.h. (BTW, I wonder that you
> don't need clk handling.)
Thanks. Will delete redundant header includes. I haven't found any
clocks in Cygnus clock data sheet that are labeled i2c. I suspect the
I2C clock is derived directly from the crystal and therefore we have no
gating control. As you can see, the rates of 100K and 400K are set
directly in the I2C block internal registers. That implies the I2C core
clock is fixed.
>
>> +#define TIM_CFG_OFFSET 0x04
>> +#define TIME_CFG_MODE_400_SHIFT 31
> Is the register name and the bit name prefix really different or is this
> a typo?
>
Yeah, typo. Will fix.
>> +static int __wait_for_bus_idle(struct bcm_iproc_i2c_dev *iproc_i2c)
> A bcm_iproc_i2c prefix would be nice here.
>
>> +static int bcm_iproc_i2c_format_addr(struct bcm_iproc_i2c_dev *iproc_i2c,
>> + struct i2c_msg *msg, u8 *addr)
>> +{
>> +
>> +if (msg->flags & I2C_M_TEN) {
>> +dev_err(iproc_i2c->device, "no support for 10-bit address\n");
>> +return -EINVAL;
>> +}
>> +
>> +*addr = (msg->addr << 1);
> You can also drop the parentheses.
>
Yes
>> +switch (val) {
>> +case M_CMD_STATUS_SUCCESS:
>> +return 0;
>> +
>> +case M_CMD_STATUS_LOST_ARB:
>> +dev_err(iproc_i2c->device, "lost bus arbitration\n");
>> +return -EREMOTEIO;
>> +
>> +case M_CMD_STATUS_NACK_ADDR:
>> +dev_err(iproc_i2c->device, "NAK addr:0x%02x\n",
>> +iproc_i2c->msg->addr);
>> +return -EREMOTEIO;
>> +
>> +case M_CMD_STATUS_NACK_DATA:
>> +dev_err(iproc_i2c->device, "NAK data\n");
>> +return -EREMOTEIO;
>> +
>> +case M_CMD_STATUS_TIMEOUT:
>> +dev_err(iproc_i2c->device, "bus timeout\n");
>> +return -ETIMEDOUT;
>> +
>> +default:
>> +dev_err(iproc_i2c->device, "unknown error code=%d\n", val);
>> +return -EREMOTEIO;
>> +}
>> +
>> +return -EREMOTEIO;
> This is not reached.
>
Will delete.
>> +}
>> +
>> +static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev
>> *iproc_i2c,
>> + struct i2c_msg *msg)
>> +{
>> +int ret, i;
>> +u8 addr;
>> +u32 val;
>> +unsigned long time_left = msecs_to_jiffies(I2C_TIMEOUT_MESC);
>> +
>> +if (msg->len < 1 || msg->len > M_TX_RX_FIFO_SIZE - 1) {
> Is the < 1 a hardware or a software limitation? That means your driver
> doesn't support I2C_SMBUS_QUICK which is used for example by i2cdetect.
>
Actually a SW issue. Will fix.
>> +dev_err(iproc_i2c->device,
>> +"supported data length is 1 - %u bytes\n",
>> +M_TX_RX_FIFO_SIZE - 1);
>> +return -EINVAL;
>> +}
>> +
>> +iproc_i2c->msg = msg;
> Can it happen that iproc_i2c->msg still holds an uncompleted message
> here or is this serialized by the core? Wolfram? Either here something
> like:
>
> if (iproc_i2c->msg)
> return -EBUSY;
>
> and
>
> iproc_i2c->msg = NULL;
>
> when a transfer is completed is needed, or the respective code can be
> dropped from other drivers (e.g. i2c-efm32).
> On the other hand .msg is only used in bcm_iproc_i2c_check_status() to
> give a diagnostic message. Maybe you can drop .msg and instead give it
> as an additional parameter to bcm_iproc_i2c_check_status().
>
Yes, I'll drop .msg in iproc_i2c.
>> +ret = __wait_for_bus_idle(iproc_i2c);
>> +if (ret)
>> +return ret;
> I would still prefer to have something like:
>
> if (bcm_iproc_i2c_bus_busy())
> return -EBUSY;
>
> instead of a tight loop here.
>
Okay. Will do.
>> +ret = bcm_iproc_i2c_format_addr(iproc_i2c, msg, );
>> +if (ret)
>> +return ret;
>> +
>> +/* load slave address into the TX FIFO */
>> +writel(addr, iproc_i2c->base + M_TX_OFFSET);
>> +
>> +/* for a write transaction, load data into the TX FIFO */
>> +if (!(msg->flags & I2C_M_RD)) {
>> +for (i = 0; i < msg->len; i++) {
>> +val = msg->buf[i];
>> +
>> +/* mark the last byte */
>> +if (i == msg->len - 1)
>> +val |= 1 << M_TX_WR_STATUS_SHIFT;
> What happens if you don't mark this last byte? Could this be used to
> support transfers bigger than the fifo size?
>
I do not think so. According to the iProc I2C block programming guide,
one always needs to mark the last byte in a write operation.
>> +/*
>> + * Enable the "start busy" interrupt,
Re: [PATCH v3 00/13] Add kdbus implementation
On Fri, Jan 16, 2015 at 2:16 PM, Greg Kroah-Hartman wrote: > This can also be found in a git tree, the kdbus branch of char-misc.git at: > https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/ Is this now the canonical tree? I ask because the github tree hasn't been updated in quite some time. The code.google.com tree has commits from 2 days ago, but it still calls d_materialise_unique in fs.c whereas the patchset you've posted uses the correct d_splice_alias. So the code.google.com tree doesn't actually compile against 3.19-rcX. I'm confused where we're supposed to track things now. josh -- 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] clk: qcom: Add EBI2 clocks for IPQ806x
On 01/16/2015 06:48 AM, Archit Taneja wrote:
> The NAND controller within EBI2 requires EBI2_CLK and EBI2_ALWAYS_ON_CLK
> clocks.
> Create structs for these clocks so that they can be used by the NAND
> controller
> driver. Add an entry for EBI2_AON_CLK in the gcc-ipq806x DT binding document.
>
> Cc: Stephen Boyd
> Signed-off-by: Archit Taneja
Looks ok. I couldn't find this used in the downstream sources though.
Can you point me to it? I'm mostly worried that this is a shared
resource that never should be turned off, so exposing it to drivers may
not be the right idea.
> +static struct clk_branch ebi2_aon_clk = {
> + .hwcg_reg = 0x3b00,
> + .hwcg_bit = 6,
> + .halt_reg = 0x2fcc,
> + .halt_bit = 0,
> + .clkr = {
> + .enable_reg = 0x3b00,
> + .enable_mask = BIT(8),
> + .hw.init = &(struct clk_init_data){
> + .name = "ebi2_always_on_clk",
>
Can this be ebi2_aon_clk to match the macro?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] ath3k: Add support of AR3012 bluetooth 13d3:3423 device
Add support of 13d3:3423 device.
BugLink: https://bugs.launchpad.net/bugs/1411193
---
T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3423 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Dmitry Tunin
Cc: sta...@vger.kernel.org
---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 1ee27ac..13a64d0 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -108,6 +108,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3393) },
{ USB_DEVICE(0x13d3, 0x3402) },
{ USB_DEVICE(0x13d3, 0x3408) },
+ { USB_DEVICE(0x13d3, 0x3423) },
{ USB_DEVICE(0x13d3, 0x3432) },
/* Atheros AR5BBU12 with sflash firmware */
@@ -162,6 +163,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 4a6495a..1211c74 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -189,6 +189,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
--
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 -mm v7 00/13] pagewalk: improve vma handling, apply to new users
On Fri, 16 Jan 2015 18:32:17 +0200 "Kirill A. Shutemov" wrote: > On Fri, Nov 07, 2014 at 07:01:51AM +, Naoya Horiguchi wrote: > > This series is ver.7 of page table walker patchset. > > > > I apologize about my long delay since previous version (I have moved to > > Japan last month and no machine access for a while.) > > I just rebased this onto mmotm-2014-11-05-16-01. I had some conflicts but > > the resolution was not hard. > > Trinity showed no bug at least in my environment. > > Andrew, any chance you'll find time for the patchset? > That was 2+ months ago - the patches have decayed somewhat. I'm only seeing a few rejects so I'll have a play with them, see how it all looks. -- 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 4/6] arm64: Kprobes instruction simulation support
On 01/14/15 04:32, Pratyush Anand wrote:
On Sun, Jan 11, 2015 at 9:33 AM, David Long wrote:
From: Sandeepa Prabhu
Add support for AArch64 instruction simulation in kprobes.
Kprobes needs simulation of instructions that cannot be stepped
from different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.
Following instruction catagories are simulated:
- All branching instructions(conditional, register, and immediate)
- Literal access instructions(load-literal, adr/adrp)
Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP. Kprobes considers
this case as 'miss'.
changes since v3:
from David A. Long:
1) Fix incorrect simulate_ldrsw_literal() semantics.
2) Use instruction test functions instead of private parse table.
from Will Cohen:
3) Remove PC adjustments when simulating an instruction.
4) Fix displacement calculations.
Signed-off-by: Sandeepa Prabhu
Signed-off-by: William Cohen
Signed-off-by: David A. Long
---
[...]
static bool aarch64_insn_is_steppable(u32 insn)
{
@@ -60,6 +130,32 @@ arm_kprobe_decode_insn(kprobe_opcode_t insn, struct
arch_specific_insn *asi)
*/
if (aarch64_insn_is_steppable(insn))
return INSN_GOOD;
+
+ asi->prepare = prepare_none;
+
+ if (aarch64_insn_is_bcond(insn)) {
+ asi->prepare = prepare_bcond;
+ asi->handler = simulate_b_cond;
+ } else if (aarch64_insn_is_cb(insn)) {
+ asi->prepare = prepare_cbz_cbnz;
+ asi->handler = simulate_cbz_cbnz;
+ } else if (aarch64_insn_is_tb(insn)) {
+ asi->prepare = prepare_tbz_tbnz;
+ asi->handler = simulate_tbz_tbnz;
+ } else if (aarch64_insn_is_adr(insn))
aarch64_insn_is_adr should be modified to aarch64_insn_is_adr_adrp
Yes.
+ asi->handler = simulate_adr_adrp;
+ else if (aarch64_insn_is_b_bl(insn))
+ asi->handler = simulate_b_bl;
+ else if (aarch64_insn_is_ldr_lit(insn))
+ asi->handler = simulate_ldr_literal;
+ else if (aarch64_insn_is_ldrsw_lit(insn))
+ asi->handler = simulate_ldrsw_literal;
also
else if (aarch64_insn_is_br_blr(insn) || aarch64_insn_is_ret(insn))
asi->handler = simulate_br_blr_ret;
Yes.
~Pratyush
-dl
--
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] sysfs: group: allow is_visible to drop permissions
Using the optional is_visible function, it is actually possible to
either hide an attribute, or add a new permission, but not remove one.
This commit uses all the UGO bits returned by is_visible instead of
OR'ing them with the default attribute mode.
Concretely, this allows a driver to use macros like DEVICE_ATTR_RW to
set the attribute show and store functions and remove the S_IWUSR
permission in is_visible if the implementation doesn't provide a setter.
Signed-off-by: Vivien Didelot
---
fs/sysfs/group.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 7d2a860..a8cfe03 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -41,7 +41,7 @@ static int create_files(struct kernfs_node *parent, struct
kobject *kobj,
if (grp->attrs) {
for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
- umode_t mode = 0;
+ umode_t mode = (*attr)->mode;
/*
* In update mode, we're changing the permissions or
@@ -51,13 +51,15 @@ static int create_files(struct kernfs_node *parent, struct
kobject *kobj,
if (update)
kernfs_remove_by_name(parent, (*attr)->name);
if (grp->is_visible) {
- mode = grp->is_visible(kobj, *attr, i);
- if (!mode)
+ umode_t ugo = grp->is_visible(kobj, *attr, i);
+
+ if (!(ugo & S_IRWXUGO))
continue;
+
+ mode = (mode & ~S_IRWXUGO) | (ugo & S_IRWXUGO);
}
error = sysfs_add_file_mode_ns(parent, *attr, false,
- (*attr)->mode | mode,
- NULL);
+ mode, NULL);
if (unlikely(error))
break;
}
--
2.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/
Payment
Dear Recipient, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds. Gloria Peter -- 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/6] arm64: Add more test functions to insn.c
On 01/14/15 04:32, Pratyush Anand wrote:
On Sun, Jan 11, 2015 at 9:33 AM, David Long wrote:
From: "David A. Long"
Certain instructions are hard to execute correctly out-of-line (as in
kprobes). Test functions are added to insn.[hc] to identify these. The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.
Signed-off-by: David A. Long
---
arch/arm64/include/asm/insn.h | 21 +++--
arch/arm64/kernel/insn.c | 18 ++
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index e2ff32a..466afd4 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -223,8 +223,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32
code) \
static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
{ return (val); }
+__AARCH64_INSN_FUNCS(adr, 0x9F00, 0x1000)
Should n't it be
__AARCH64_INSN_FUNCS(adr_adrp, 0x1F00, 0x1000)
So, that it also take care about adrp
Yes, that does look like a mistake.
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF00, 0xD800)
[...]
+bool aarch64_insn_uses_literal(u32 insn)
+{
+ /* ldr/ldrsw (literal), prfm */
+
+ return aarch64_insn_is_ldr_lit(insn) ||
+ aarch64_insn_is_ldrsw_lit(insn) ||
also aarch64_insn_is_adr_adrp(insn) ||
Yup.
+ aarch64_insn_is_prfm_lit(insn);
+}
+
+bool aarch64_insn_is_branch(u32 insn)
+{
+ /* b, bl, cb*, tb*, b.cond, br, blr */
+
+ return aarch64_insn_is_b_bl_cb_tb(insn) ||
+ aarch64_insn_is_br_blr(insn) ||
also aarch64_insn_is_ret(insn) ||
The goal was to catch intructions that use a PC-relative branch, since
the PC will not be what is expected. Of course any instruction that
changes the PC will have a problem too because the PC will be rewritten
after the probe is completed. So, yeah, this needs to be fixed.
+ aarch64_insn_is_bcond(insn);
+}
+
/*
-dl
--
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 03/10] perf machine: Fix __machine__findnew_thread() error path
From: Namhyung Kim
When thread__init_map_groups() fails, a new thread should be removed
from the rbtree since it's gonna be freed. Also update last match cache
only if the function succeeded.
Reported-by: David Ahern
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 94de3e48b490..1bca3a9f2b16 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -389,7 +389,6 @@ static struct thread *__machine__findnew_thread(struct
machine *machine,
if (th != NULL) {
rb_link_node(>rb_node, parent, p);
rb_insert_color(>rb_node, >threads);
- machine->last_match = th;
/*
* We have to initialize map_groups separately
@@ -400,9 +399,12 @@ static struct thread *__machine__findnew_thread(struct
machine *machine,
* leader and that would screwed the rb tree.
*/
if (thread__init_map_groups(th, machine)) {
+ rb_erase(>rb_node, >threads);
thread__delete(th);
return NULL;
}
+
+ machine->last_match = th;
}
return th;
--
1.9.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 05/10] perf tools: Fix statfs.f_type data type mismatch build error with uclibc
From: Alexey Brodkin ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers statfs defines f_type to be U32 which causes perf build breakage http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h --->8--- CC fs/fs.o fs/fs.c: In function 'fs__valid_mount': fs/fs.c:82:24: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] else if (st_fs.f_type != magic) ^ cc1: all warnings being treated as errors --->8--- Signed-off-by: Alexey Brodkin Acked-by: Jiri Olsa Cc: Borislav Petkov Cc: Cody P Schafer Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Vineet Gupta Link: http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgu...@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/api/fs/debugfs.c | 2 +- tools/lib/api/fs/fs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c index a74fba6d7743..86ea2d7b8845 100644 --- a/tools/lib/api/fs/debugfs.c +++ b/tools/lib/api/fs/debugfs.c @@ -67,7 +67,7 @@ int debugfs_valid_mountpoint(const char *debugfs) if (statfs(debugfs, _fs) < 0) return -ENOENT; - else if (st_fs.f_type != (long) DEBUGFS_MAGIC) + else if ((long)st_fs.f_type != (long)DEBUGFS_MAGIC) return -ENOENT; return 0; diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c index 65d9be3f9887..128ef6332a6b 100644 --- a/tools/lib/api/fs/fs.c +++ b/tools/lib/api/fs/fs.c @@ -79,7 +79,7 @@ static int fs__valid_mount(const char *fs, long magic) if (statfs(fs, _fs) < 0) return -ENOENT; - else if (st_fs.f_type != magic) + else if ((long)st_fs.f_type != magic) return -ENOENT; return 0; -- 1.9.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 10/10] perf tools powerpc: Use dwfl_report_elf() instead of offline.
From: Sukadev Bhattiprolu
dwfl_report_offline() works only when libraries are prelinked.
Replace dwfl_report_offline() with dwfl_report_elf() so we correctly
extract debug info even from libraries that are not prelinked.
Reported-by: Jiri Olsa
Signed-off-by: Sukadev Bhattiprolu
Tested-by: Jiri Olsa
Cc: Jiri Olsa
Cc: Michael Ellerman
Link: http://lkml.kernel.org/r/20150114221045.ga17...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/powerpc/util/skip-callchain-idx.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index 3bb50eac5542..0c370f81e002 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -103,7 +103,7 @@ static Dwarf_Frame *get_eh_frame(Dwfl_Module *mod,
Dwarf_Addr pc)
return NULL;
}
- result = dwarf_cfi_addrframe(cfi, pc, );
+ result = dwarf_cfi_addrframe(cfi, pc-bias, );
if (result) {
pr_debug("%s(): %s\n", __func__, dwfl_errmsg(-1));
return NULL;
@@ -128,7 +128,7 @@ static Dwarf_Frame *get_dwarf_frame(Dwfl_Module *mod,
Dwarf_Addr pc)
return NULL;
}
- result = dwarf_cfi_addrframe(cfi, pc, );
+ result = dwarf_cfi_addrframe(cfi, pc-bias, );
if (result) {
pr_debug("%s(): %s\n", __func__, dwfl_errmsg(-1));
return NULL;
@@ -145,7 +145,7 @@ static Dwarf_Frame *get_dwarf_frame(Dwfl_Module *mod,
Dwarf_Addr pc)
* yet used)
* -1 in case of errors
*/
-static int check_return_addr(struct dso *dso, Dwarf_Addr pc)
+static int check_return_addr(struct dso *dso, u64 map_start, Dwarf_Addr pc)
{
int rc = -1;
Dwfl*dwfl;
@@ -155,6 +155,7 @@ static int check_return_addr(struct dso *dso, Dwarf_Addr pc)
Dwarf_Addr start = pc;
Dwarf_Addr end = pc;
boolsignalp;
+ const char *exec_file = dso->long_name;
dwfl = dso->dwfl;
@@ -165,8 +166,10 @@ static int check_return_addr(struct dso *dso, Dwarf_Addr
pc)
return -1;
}
- if (dwfl_report_offline(dwfl, "", dso->long_name, -1) == NULL) {
- pr_debug("dwfl_report_offline() failed %s\n",
+ mod = dwfl_report_elf(dwfl, exec_file, exec_file, -1,
+ map_start, false);
+ if (!mod) {
+ pr_debug("dwfl_report_elf() failed %s\n",
dwarf_errmsg(-1));
/*
* We normally cache the DWARF debug info and never
@@ -256,10 +259,10 @@ int arch_skip_callchain_idx(struct thread *thread, struct
ip_callchain *chain)
return skip_slot;
}
- rc = check_return_addr(dso, ip);
+ rc = check_return_addr(dso, al.map->start, ip);
- pr_debug("DSO %s, nr %" PRIx64 ", ip 0x%" PRIx64 "rc %d\n",
- dso->long_name, chain->nr, ip, rc);
+ pr_debug("[DSO %s, sym %s, ip 0x%" PRIx64 "] rc %d\n",
+ dso->long_name, al.sym->name, ip, rc);
if (rc == 0) {
/*
--
1.9.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 06/10] perf tools: Elide strlcpy warning with uclibc
From: Vineet Gupta ->8-- CC bench/sched-pipe.o In file included from builtin-annotate.c:13:0: util/cache.h:76:15: warning: redundant redeclaration of 'strlcpy' [-Wredundant-decls] extern size_t strlcpy(char *dest, const char *src, size_t size); ^ In file included from util/util.h:55:0, from builtin.h:4, from builtin-annotate.c:8: ~/vineetg/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/string.h:396:15: note: previous declaration of 'strlcpy' was here extern size_t strlcpy(char *__restrict dst, const char *__restrict src, ->8-- Signed-off-by: Vineet Gupta Cc: Alexey Brodkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1421156604-30603-3-git-send-email-vgu...@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/cache.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h index 5cf9e1b5989d..d04d770d90f6 100644 --- a/tools/perf/util/cache.h +++ b/tools/perf/util/cache.h @@ -71,7 +71,9 @@ extern char *perf_path(const char *fmt, ...) __attribute__((format (printf, 1, 2 extern char *perf_pathdup(const char *fmt, ...) __attribute__((format (printf, 1, 2))); +#ifndef __UCLIBC__ /* Matches the libc/libbsd function attribute so we declare this unconditionally: */ extern size_t strlcpy(char *dest, const char *src, size_t size); +#endif #endif /* __PERF_CACHE_H */ -- 1.9.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 07/10] perf tools: Avoid build splat for syscall numbers with uclibc
From: Vineet Gupta
This is due to duplicated unistd inclusion (via uClibc headers + kernel headers)
Also seen on ARM uClibc based tools
--- ARC build -->8-
CC util/evlist.o
In file included from
~/arc/k.org/arch/arc/include/uapi/asm/unistd.h:25:0,
from util/../perf-sys.h:10,
from util/../perf.h:15,
from util/event.h:7,
from util/event.c:3:
~/arc/k.org/include/uapi/asm-generic/unistd.h:906:0:
warning: "__NR_fcntl64" redefined [enabled by default]
#define __NR_fcntl64 __NR3264_fcntl
^
In file included from
~/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/sys/syscall.h:24:0,
from util/../perf-sys.h:6,
->8---
--- ARM build -->8-
CC FPIC plugin_scsi.o
In file included from util/../perf-sys.h:9:0,
from util/../perf.h:15,
from util/cache.h:7,
from perf.c:12:
~/arc/k.org/arch/arm/include/uapi/asm/unistd.h:28:0:
warning: "__NR_restart_syscall" redefined [enabled by default]
In file included from
~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/syscall.h:25:0,
from util/../perf-sys.h:6,
from util/../perf.h:15,
from util/cache.h:7,
from perf.c:12:
~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/sysnum.h:17:0:
note: this is the location of the previous definition
->8---
Signed-off-by: Vineet Gupta
Cc: Alexey Brodkin
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1421156604-30603-4-git-send-email-vgu...@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/sched-pipe.c | 2 +-
tools/perf/builtin-top.c | 1 -
tools/perf/perf-sys.h | 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 07a8d7646a15..005cc283790c 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -19,12 +19,12 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
+#include
#include
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 961cea183a83..616f0fcb4701 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -66,7 +66,6 @@
#include
#include
-#include
#include
static volatile int done;
diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index a3b13d7dc1d4..6ef68165c9db 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -6,7 +6,6 @@
#include
#include
#include
-#include
#if defined(__i386__)
#define mb() asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
--
1.9.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/
