Re: [PATCH 0/2] mtd: oobtest: Add parameter to ignore bitflip errors within specified limit
On Tue, Oct 21, 2014 at 04:53:26PM +0300, Roger Quadros wrote:
> Hi,
>
> The oobtest case uses raw NAND read/writes to OOB area bypassing the error
> correction
> mechanism
Hmm, I suppose that's the case. I intended for
ecc.{read,write}_oob_raw() vs. ecc.{read,write}_oob() to provide a
distinction, but most drivers use identical implementations for both,
and both are 'raw.' Now that I think about it again, I'm not sure
there's really a good use for an ECC-protected OOB read/write operation.
If you're intending to use ECC, you should be writing data+OOB (i.e.,
nand_do_{read,write}_ops()).
> and hence is bound to be affected by bitflip errors which are normal
> in NAND memories. (e.g. we can never get DRA7-evm's NAND to fully pass
> mtd_oobtest).
>
> In these patches we add a module parameter "bitflip_limit" to specify how many
> bitflips per page are tolerable. Not specifiing the parameter defaults to old
> behaviour (i.e. zero bitflips tolerated).
> Specifying bitflip_limit=1 makes us pass on DRA7-evm with 0 errors.
>
> Introduce a new memcmpshow() function that shows the data byte where
> comparison failed.
> This is useful for debugging. The same function is also used to calculate
> number of
> bitflip errors over the data block.
It's possible this sort of function could be useful for the other test
modules too. But we can keep it local for now.
Pushed both to l2-mtd.git.
Brian
--
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/
[GIT PULL] scheduler fixes
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 6e998916dfe327e785e7c2447959b2c1a3ea4930 sched/cputime: Fix
clock_nanosleep()/clock_gettime() inconsistency
Misc fixes: two NUMA fixes, two cputime fixes and an RCU/lockdep
fix.
Thanks,
Ingo
-->
Andrey Ryabinin (1):
sched/numa: Fix out of bounds read in sched_init_numa()
Kirill Tkhai (1):
sched: Remove lockdep check in sched_move_task()
Peter Zijlstra (2):
sched/numa: Avoid selecting oneself as swap target
sched/cputime: Fix cpu_timer_sample_group() double accounting
Stanislaw Gruszka (1):
sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency
include/linux/kernel_stat.h| 5
kernel/sched/core.c| 63 ++
kernel/sched/deadline.c| 2 ++
kernel/sched/fair.c| 14 ++
kernel/sched/rt.c | 2 ++
kernel/sched/sched.h | 2 ++
kernel/time/posix-cpu-timers.c | 2 +-
7 files changed, 42 insertions(+), 48 deletions(-)
diff --git a/include/linux/kernel_stat.h b/include/linux/kernel_stat.h
index 8422b4ed6882..b9376cd5a187 100644
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -77,11 +77,6 @@ static inline unsigned int kstat_cpu_irqs_sum(unsigned int
cpu)
return kstat_cpu(cpu).irqs_sum;
}
-/*
- * Lock/unlock the current runqueue - to extract task statistics:
- */
-extern unsigned long long task_delta_exec(struct task_struct *);
-
extern void account_user_time(struct task_struct *, cputime_t, cputime_t);
extern void account_system_time(struct task_struct *, int, cputime_t,
cputime_t);
extern void account_steal_time(cputime_t);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 240157c13ddc..24beb9bb4c3e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2475,44 +2475,6 @@ EXPORT_PER_CPU_SYMBOL(kstat);
EXPORT_PER_CPU_SYMBOL(kernel_cpustat);
/*
- * Return any ns on the sched_clock that have not yet been accounted in
- * @p in case that task is currently running.
- *
- * Called with task_rq_lock() held on @rq.
- */
-static u64 do_task_delta_exec(struct task_struct *p, struct rq *rq)
-{
- u64 ns = 0;
-
- /*
-* Must be ->curr _and_ ->on_rq. If dequeued, we would
-* project cycles that may never be accounted to this
-* thread, breaking clock_gettime().
-*/
- if (task_current(rq, p) && task_on_rq_queued(p)) {
- update_rq_clock(rq);
- ns = rq_clock_task(rq) - p->se.exec_start;
- if ((s64)ns < 0)
- ns = 0;
- }
-
- return ns;
-}
-
-unsigned long long task_delta_exec(struct task_struct *p)
-{
- unsigned long flags;
- struct rq *rq;
- u64 ns = 0;
-
- rq = task_rq_lock(p, );
- ns = do_task_delta_exec(p, rq);
- task_rq_unlock(rq, p, );
-
- return ns;
-}
-
-/*
* Return accounted runtime for the task.
* In case the task is currently running, return the runtime plus current's
* pending runtime that have not been accounted yet.
@@ -2521,7 +2483,7 @@ unsigned long long task_sched_runtime(struct task_struct
*p)
{
unsigned long flags;
struct rq *rq;
- u64 ns = 0;
+ u64 ns;
#if defined(CONFIG_64BIT) && defined(CONFIG_SMP)
/*
@@ -2540,7 +2502,16 @@ unsigned long long task_sched_runtime(struct task_struct
*p)
#endif
rq = task_rq_lock(p, );
- ns = p->se.sum_exec_runtime + do_task_delta_exec(p, rq);
+ /*
+* Must be ->curr _and_ ->on_rq. If dequeued, we would
+* project cycles that may never be accounted to this
+* thread, breaking clock_gettime().
+*/
+ if (task_current(rq, p) && task_on_rq_queued(p)) {
+ update_rq_clock(rq);
+ p->sched_class->update_curr(rq);
+ }
+ ns = p->se.sum_exec_runtime;
task_rq_unlock(rq, p, );
return ns;
@@ -6368,6 +6339,10 @@ static void sched_init_numa(void)
if (!sched_debug())
break;
}
+
+ if (!level)
+ return;
+
/*
* 'level' contains the number of unique distances, excluding the
* identity distance node_distance(i,i).
@@ -7444,8 +7419,12 @@ void sched_move_task(struct task_struct *tsk)
if (unlikely(running))
put_prev_task(rq, tsk);
- tg = container_of(task_css_check(tsk, cpu_cgrp_id,
- lockdep_is_held(>sighand->siglock)),
+ /*
+* All callers are synchronized by task_rq_lock(); we do not use RCU
+* which is pointless here. Thus, we pass "true" to task_css_check()
+* to prevent lockdep warnings.
+*/
+ tg = container_of(task_css_check(tsk, cpu_cgrp_id, true),
RE: [PATCH] hv: hv_fcopy: drop the obsolete message on transfer failure
> -Original Message-
> From: KY Srinivasan
> Sent: Thursday, November 20, 2014 6:59 AM
> > diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c index
> > 23b2ce2..177122a 100644
> > --- a/drivers/hv/hv_fcopy.c
> > +++ b/drivers/hv/hv_fcopy.c
> > @@ -86,6 +86,15 @@ static void fcopy_work_func(struct work_struct
> > *dummy)
> > * process the pending transaction.
> > */
> > fcopy_respond_to_host(HV_E_FAIL);
> > +
> > +/* In the case the user-space daemon crashes, hangs or is killed, we
> > + * need to down the semaphore, otherwise, after the daemon starts
> > next
> > + * time, the obsolete data in fcopy_transaction.message or
> > + * fcopy_transaction.fcopy_msg will be used immediately.
> > + */
> > +if (down_trylock(_transaction.read_sema))
> > +pr_debug("FCP: failed to acquire the semaphore\n");
> > +
> > }
>
> When the daemon is killed, we currently reset the state in the release
> function. Why can't we cleanup the semaphore state (initialize) here as well.
>
> K. Y
Hi KY,
1) The down_trylock() here is necessary: the daemon can fail to respond in 5
seconds due to many reasons, e.g., the VM's CPU and I/O are too busy. In this
case, the daemon may become running later(NOTE: in this example, the daemon
is not killed), but from the host user's point of view, the PowerShell
copy-vmfile command has failed, so here we have to 'down' the semaphore
anyway, otherwise, the daemon can get obsolete data.
2) If we add a line
sema_init(_transaction.read_sema, 0);
in fcopy_release(), it seems OK at a glance, but we have to handle the race
condition: the above down_trylock() and the sema_init() can, in theory, run
simultaneously on different virtual CPUs. It's tricky to address this.
3) So I think we can reuse the same semaphore without an actually unnecessary
re-initialization. :-)
Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 20
Hi all, Changes since 20141119: The asm-generic tree lost its build failure. The omap_dss2 tree still had its build failure for which I applied a patch. The devicetree tree gained a conflict against the devicetree-current tree. Non-merge commits (relative to Linus' tree): 7146 7140 files changed, 242712 insertions(+), 180038 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 229 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (fc14f9c1272f Linux 3.18-rc5) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (08b964ff3c51 ARM: 8198/1: make kuser helpers depend on MMU) Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/fixes (d7ce4377494a powerpc/fsl_msi: mark the msi cascade handler IRQF_NO_THREAD) Merging sparc/master (fc14f9c1272f Linux 3.18-rc5) Merging net/master (ee7255ada313 cxgb4i : Don't block unload/cxgb4 unload when remote closes TCP connection) Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes') Merging sound-current/for-linus (6676f3081f7e ALSA: hda - fix the mic mute led problem for Latitude E5550) Merging pci-current/for-linus (6aa87f0986ed PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_t) Merging wireless/master (6158fb37d1b0 Merge tag 'mac80211-for-john-2014-11-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4) Merging tty.current/tty-linus (206c5f60a3d9 Linux 3.18-rc4) Merging usb.current/usb-linus (2aea83a484fc Merge tag 'fixes-for-v3.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code) Merging usb-serial-fixes/usb-linus (75bcbf29c284 USB: ssu100: fix overrun-error reporting) Merging staging.current/staging-linus (206c5f60a3d9 Linux 3.18-rc4) Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3) Merging input-current/for-linus (bce4f9e764c3 Input: synaptics - adjust min/max on Thinkpad E540) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read API and fix stack corruption) Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (817d2001c709 of/selftest: Fix testing when /aliases is missing) Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Merging kselftest-fixes/fixes (884716497d4c selftests/timers: change test to use ksft framework) Merging drm-intel-fixes/for-linux-next-fixes (0485c9dc24ec drm/i915: Kick fbdev before vgacon) Merging asm-gene
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 68055915c1c22489f9658bd2b7391bb11b2cf4e4 perf/x86/intel/uncore: Fix
boot crash on SBOX PMU on Haswell-EP
Misc fixes: two Intel uncore driver fixes, a CPU-hotplug fix and
a build dependencies fix.
Thanks,
Ingo
-->
Andi Kleen (2):
perf/x86/intel/uncore: Fix IRP uncore register offsets on Haswell EP
perf/x86/intel/uncore: Fix boot crash on SBOX PMU on Haswell-EP
Mark Rutland (1):
perf: Fix corruption of sibling list with hotplug
Peter Zijlstra (Intel) (1):
perf/x86: Fix embarrasing typo
arch/x86/Kconfig | 2 +-
.../x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 49 --
kernel/events/core.c | 8 ++--
3 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ded8a6774ac9..41a503c15862 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -144,7 +144,7 @@ config INSTRUCTION_DECODER
config PERF_EVENTS_INTEL_UNCORE
def_bool y
- depends on PERF_EVENTS && SUP_SUP_INTEL && PCI
+ depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
config OUTPUT_FORMAT
string
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
index adf138eac85c..f9ed429d6e4f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
@@ -486,14 +486,17 @@ static struct attribute_group
snbep_uncore_qpi_format_group = {
.attrs = snbep_uncore_qpi_formats_attr,
};
-#define SNBEP_UNCORE_MSR_OPS_COMMON_INIT() \
- .init_box = snbep_uncore_msr_init_box,\
+#define __SNBEP_UNCORE_MSR_OPS_COMMON_INIT() \
.disable_box= snbep_uncore_msr_disable_box, \
.enable_box = snbep_uncore_msr_enable_box, \
.disable_event = snbep_uncore_msr_disable_event, \
.enable_event = snbep_uncore_msr_enable_event,\
.read_counter = uncore_msr_read_counter
+#define SNBEP_UNCORE_MSR_OPS_COMMON_INIT() \
+ __SNBEP_UNCORE_MSR_OPS_COMMON_INIT(), \
+ .init_box = snbep_uncore_msr_init_box \
+
static struct intel_uncore_ops snbep_uncore_msr_ops = {
SNBEP_UNCORE_MSR_OPS_COMMON_INIT(),
};
@@ -1919,6 +1922,30 @@ static struct intel_uncore_type hswep_uncore_cbox = {
.format_group = _uncore_cbox_format_group,
};
+/*
+ * Write SBOX Initialization register bit by bit to avoid spurious #GPs
+ */
+static void hswep_uncore_sbox_msr_init_box(struct intel_uncore_box *box)
+{
+ unsigned msr = uncore_msr_box_ctl(box);
+
+ if (msr) {
+ u64 init = SNBEP_PMON_BOX_CTL_INT;
+ u64 flags = 0;
+ int i;
+
+ for_each_set_bit(i, (unsigned long *), 64) {
+ flags |= (1ULL << i);
+ wrmsrl(msr, flags);
+ }
+ }
+}
+
+static struct intel_uncore_ops hswep_uncore_sbox_msr_ops = {
+ __SNBEP_UNCORE_MSR_OPS_COMMON_INIT(),
+ .init_box = hswep_uncore_sbox_msr_init_box
+};
+
static struct attribute *hswep_uncore_sbox_formats_attr[] = {
_attr_event.attr,
_attr_umask.attr,
@@ -1944,7 +1971,7 @@ static struct intel_uncore_type hswep_uncore_sbox = {
.event_mask = HSWEP_S_MSR_PMON_RAW_EVENT_MASK,
.box_ctl= HSWEP_S0_MSR_PMON_BOX_CTL,
.msr_offset = HSWEP_SBOX_MSR_OFFSET,
- .ops= _uncore_msr_ops,
+ .ops= _uncore_sbox_msr_ops,
.format_group = _uncore_sbox_format_group,
};
@@ -2025,13 +2052,27 @@ static struct intel_uncore_type hswep_uncore_imc = {
SNBEP_UNCORE_PCI_COMMON_INIT(),
};
+static unsigned hswep_uncore_irp_ctrs[] = {0xa0, 0xa8, 0xb0, 0xb8};
+
+static u64 hswep_uncore_irp_read_counter(struct intel_uncore_box *box, struct
perf_event *event)
+{
+ struct pci_dev *pdev = box->pci_dev;
+ struct hw_perf_event *hwc = >hw;
+ u64 count = 0;
+
+ pci_read_config_dword(pdev, hswep_uncore_irp_ctrs[hwc->idx], (u32
*));
+ pci_read_config_dword(pdev, hswep_uncore_irp_ctrs[hwc->idx] + 4, (u32
*) + 1);
+
+ return count;
+}
+
static struct intel_uncore_ops hswep_uncore_irp_ops = {
.init_box = snbep_uncore_pci_init_box,
.disable_box= snbep_uncore_pci_disable_box,
.enable_box = snbep_uncore_pci_enable_box,
.disable_event = ivbep_uncore_irp_disable_event,
.enable_event = ivbep_uncore_irp_enable_event,
- .read_counter = ivbep_uncore_irp_read_counter,
+ .read_counter
Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep
* Andy Lutomirski wrote: > On Wed, Nov 19, 2014 at 3:59 PM, Linus Torvalds > wrote: > > On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski > > wrote: > >> > >> My only real objection is that it's going to be ugly and > >> error prone. It'll have to be something like: > > > > No. > > > >> because the whole point of this series is to make the IST > >> entries not be atomic when they come from userspace. > > > > Andy, you need to lay off the drugs. > > > > No drugs, just imprecision. This series doesn't change NMI > handling at all. It only changes machine_check int3, debug, > and stack_segment. (Why is #SS using IST stacks anyway?) We made most of those preemptible in -rt and changed it away from the IST. I never got a good explanation from anyone for why they were IST in the first place - histeric accident or such. Feel free to clean this up too! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clk: Propagate prepare and enable when reparenting orphans
On Wed, Nov 19, 2014 at 09:15:41PM -0800, Doug Anderson wrote: > Mike, > > On Wed, Nov 19, 2014 at 6:30 PM, Mike Turquette wrote: > > Quoting Doug Anderson (2014-11-07 17:06:58) > >> With the existing code, if you find a parent for an orhpan that has > >> already been prepared / enabled, you won't enable the parent. That > >> can cause later problems since the clock tree isn't in a consistent > >> state. Fix by propagating the prepare and enable. > >> > >> NOTE: this does bring up the question about whether the enable of the > >> orphan actually made sense. If the orphan's parent wasn't enabled by > >> default (by the bootloader or the default state of the hardware) then > >> the original enable of the orphan probably didn't do what the caller > >> though it would. Some users of the orphan might have preferred an > >> EPROBE_DEFER be returned until we had a full path to a root clock. > >> This patch doesn't address those concerns and really just syncs up the > >> state. > > > > -ECANOFWORMS > > > > I'm thinking about this patch but I haven't quite made up my mind. It is > > reasonable, but also some nice kind of error might be preferable when > > preparing/enabling an orphaned clock. > > > > Under what conditions might a clock be orphaned? An obvious example is > > just bad luck during the thundering herd of clock registrations from a > > driver. In this case deferring the probe might be a good idea. > > > > However what about the case where a loadable module provides the parent > > clock? It might be a long time before the orphan clocks gets picked up > > from the orphanage. Is deferring probe the right thing here as well? > > I will defer to your wisdom here. I agree that these are the two > primary solutions and I've picked one, but I have no idea which will > be more of a PITA in the long run. > > Note: I'm not sure that anyone expects EPROBE_DEFER to be returned > from a clk_enable() (do they?). It almost seems like the right answer > is to fail to allow anyone to clk_get() any clock that doesn't have a > path to root. EPROBE_DEFER only makes sense in driver's probe paths and so I would be very against adding it to clk_enable() which is called from many places in the kernel. If we decide to go with EPROBE_DEFER then returning it from clk_get() seems like a much better choice since it is normally called during probing. 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: crypto: user - Allow get request with empty driver name
On Thu, Nov 20, 2014 at 08:11:42AM +0100, Steffen Klassert wrote: > > I think this is not sufficient, crypto_alg_match() will now return the first > algorithm in crypto_alg_list that matches cra_name. We would need to extend > crypto_alg_match() to return the algorithm with the highest priority in that > case. It doesn't really matter because all implementations must provide exactly the same set of parameters for a given algorithm so it's good enough for what Stephan wants to do. But yes an interface to grab the highest priority algorithm would be useful too so patches are welcome :) Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/
[tip:perf/core] perf hists: Fix up srcline histogram key formatting
Commit-ID: b2d53671cdb0cf5070d56359821eb812669bb1ad
Gitweb: http://git.kernel.org/tip/b2d53671cdb0cf5070d56359821eb812669bb1ad
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 18 Nov 2014 18:02:51 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:48 -0300
perf hists: Fix up srcline histogram key formatting
Problem introduced in:
commit 5b5916696051 "perf report: Honor column width setting"
Where the left justification signal was after the width, which ended up,
when the width was, say, 11, always printing:
%11.11-s
Instead of src:line left justified and limited to 11 chars.
Resulting in a like:
70.93% %11.11-s [.] f2 tcall
When it should instead be:
70.93% tcall.c:5[.] f2 tcall
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Borislav Petkov
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-2xnt0vqkoox52etq2qhye...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/sort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 9402885..82a5596 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -309,7 +309,7 @@ sort__srcline_cmp(struct hist_entry *left, struct
hist_entry *right)
static int hist_entry__srcline_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
- return repsep_snprintf(bf, size, "%*.*-s", width, width, he->srcline);
+ return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcline);
}
struct sort_entry sort_srcline = {
--
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: For the problem when using swiotlb
On Thursday 20 November 2014 10:57:53 Ding Tianhong wrote: > On 2014/11/19 16:45, Arnd Bergmann wrote: > > On Wednesday 19 November 2014 11:17:15 Ding Tianhong wrote: > >> On 2014/11/18 2:09, Catalin Marinas wrote: > >>> On Mon, Nov 17, 2014 at 12:18:42PM +, Arnd Bergmann wrote: > >> Thanks everyone, I think I found the way to fix it, need to enable > >> DMA_CMA, to reserve a big memory > >> for CMA and set coherent mask for dev, then dma_alloc and dma_mapping will > >> not use the swiotlb until > >> the memory out of mask or swiotlb_force is enabled. > >> > >> If I still understand uncorrectly, please inform me. > >> > > > > Please do not use CMA to work around the problem, but fix the underlying bug > > instead. > > > > The driver should call 'dma_set_mask_and_coherent()' with the appropriate > > dma mask, and check whether that succeeded. However, the code implementing > > dma_set_mask_and_coherent on arm64 also needs to be changed to look up > > the dma-ranges property (see of_dma_configure()), and check if the mask > > is possible. > > > The dma_pfn_offset looks only support arm32, but my platform is aarch64 and I > check the latest kernel version, > I think the dma-rangs still could not work for aarch64, so maybe we should > add dma_pfn_offset for aarch64 first. > I didn't mean the dma_pfn_offset. The problem is that the of_dma_configure code currently doesn't look at the mask. As I explained in my reply to Catalin, it should set the mask to the size of the dma-ranges if that is 32-bit or smaller, and dma_set_mask should look at the same dma-ranges property to decide what to set the mask to when a driver asks for a mask larger than 64-bit. Arnd -- 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/
[GIT PULL] core/urgent fix
Linus, Please pull the latest core-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-urgent-for-linus # HEAD: 00b4d9a14125f1e51874def2b9de6092e007412d bitops: Fix shift overflow in GENMASK macros Fix GENMASK macro shift overflow. Thanks, Ingo --> Maxime COQUELIN (1): bitops: Fix shift overflow in GENMASK macros include/linux/bitops.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index be5fd38bd5a0..5d858e02997f 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -18,8 +18,11 @@ * position @h. For example * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. */ -#define GENMASK(h, l) (((U32_C(1) << ((h) - (l) + 1)) - 1) << (l)) -#define GENMASK_ULL(h, l) (((U64_C(1) << ((h) - (l) + 1)) - 1) << (l)) +#define GENMASK(h, l) \ + (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h + +#define GENMASK_ULL(h, l) \ + (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h extern unsigned int __sw_hweight8(unsigned int w); extern unsigned int __sw_hweight16(unsigned int w); -- 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/
[tip:perf/core] perf tools: Only override the default : tid comm entry
Commit-ID: a84808083688d82d7f1e5786ccf5df0ff7d448cb
Gitweb: http://git.kernel.org/tip/a84808083688d82d7f1e5786ccf5df0ff7d448cb
Author: Adrian Hunter
AuthorDate: Tue, 11 Nov 2014 16:16:41 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:37:26 -0300
perf tools: Only override the default :tid comm entry
Events may still be ordered even if there are no timestamps e.g. if the
data is recorded per-thread.
Also synthesized COMM events have a timestamp of zero.
Consequently it is better to keep comm entries even if they have a
timestamp of zero.
However, when a struct thread is created the command string is not known
and a comm entry with a string of the form ":" is used.
In that case thread->comm_set is false and the comm entry should be
overridden.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1415715423-15563-4-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/thread.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index a2157f0..9ebc8b1 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -103,15 +103,14 @@ struct comm *thread__exec_comm(const struct thread
*thread)
return last;
}
-/* CHECKME: time should always be 0 if event aren't ordered */
int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp,
bool exec)
{
struct comm *new, *curr = thread__comm(thread);
int err;
- /* Override latest entry if it had no specific time coverage */
- if (!curr->start && !curr->exec) {
+ /* Override the default :tid entry */
+ if (!thread->comm_set) {
err = comm__override(curr, str, timestamp, exec);
if (err)
return err;
--
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/
[tip:perf/core] perf evlist: Do not poll events that use the system_wide flag
Commit-ID: f90d194a867a5a1db51789b8c4e99bcd196be6bb
Gitweb: http://git.kernel.org/tip/f90d194a867a5a1db51789b8c4e99bcd196be6bb
Author: Adrian Hunter
AuthorDate: Tue, 11 Nov 2014 16:16:39 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:48 -0300
perf evlist: Do not poll events that use the system_wide flag
The system_wide flag causes a selected event to be opened always without
a pid.
Consequently it will never get a POLLHUP, but it is used for tracking in
combination with other events, so it should not need to be polled
anyway.
Therefore don't add it for polling.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1415715423-15563-2-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 7e23dae..cfbe2b9 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -816,7 +816,15 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist
*evlist, int idx,
perf_evlist__mmap_get(evlist, idx);
}
- if (__perf_evlist__add_pollfd(evlist, fd, idx) < 0) {
+ /*
+* The system_wide flag causes a selected event to be opened
+* always without a pid. Consequently it will never get a
+* POLLHUP, but it is used for tracking in combination with
+* other events, so it should not need to be polled anyway.
+* Therefore don't add it for polling.
+*/
+ if (!evsel->system_wide &&
+ __perf_evlist__add_pollfd(evlist, fd, idx) < 0) {
perf_evlist__mmap_put(evlist, idx);
return -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/
[tip:perf/core] perf tools: Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore
Commit-ID: 4b34f19b66ad29f10af90ad396131adbd16d737f Gitweb: http://git.kernel.org/tip/4b34f19b66ad29f10af90ad396131adbd16d737f Author: Adrian Hunter AuthorDate: Tue, 11 Nov 2014 16:16:40 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 19 Nov 2014 12:34:24 -0300 perf tools: Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore Recently added executables Add perf-read-vdso32 and perf-read-vdsox32 need to be added to .gitignore. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1415715423-15563-3-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/.gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 717221e..40399c3 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -2,6 +2,8 @@ PERF-CFLAGS PERF-GUI-VARS PERF-VERSION-FILE perf +perf-read-vdso32 +perf-read-vdsox32 perf-help perf-record perf-report -- 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/
[tip:perf/core] perf evsel: Fix ftrace:function event recording
Commit-ID: f140373bc904d9541e3f8e985d3810864e34c735 Gitweb: http://git.kernel.org/tip/f140373bc904d9541e3f8e985d3810864e34c735 Author: Jiri Olsa AuthorDate: Thu, 13 Nov 2014 18:21:03 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 19 Nov 2014 12:33:48 -0300 perf evsel: Fix ftrace:function event recording Following patch fails (-EINVAL) ftrace:function with enabled user space callchains: cfa77bc4af2c perf: Disallow user-space callchains for function trace events We need to follow in perf tool itself and explicitly set the perf_event_attr::exclude_callchain_user flag for ftrace:function event. Reported-by: Steven Rostedt Signed-off-by: Jiri Olsa Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/1415899263-24820-1-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/evsel.c | 8 1 file changed, 8 insertions(+) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 34344ff..f2dc91f 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -658,6 +658,14 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts) attr->mmap_data = track; } + /* +* We don't allow user space callchains for function trace +* event, due to issues with page faults while tracing page +* fault handler and its overall trickiness nature. +*/ + if (perf_evsel__is_function_event(evsel)) + evsel->attr.exclude_callchain_user = 1; + if (callchain_param.enabled && !evsel->no_aux_samples) perf_evsel__config_callgraph(evsel); -- 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/
[tip:perf/core] perf callchain: Factor out adding new call chain entries
Commit-ID: 37592b8afb7151994e760d1727c264329d9c13c8
Gitweb: http://git.kernel.org/tip/37592b8afb7151994e760d1727c264329d9c13c8
Author: Andi Kleen
AuthorDate: Wed, 12 Nov 2014 18:05:19 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:47 -0300
perf callchain: Factor out adding new call chain entries
Move the code to resolve and add a new callchain entry into a new
add_callchain_ip function. This will be used in the next patches to add
LBRs too.
No change in behavior.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-2-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 51 +--
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 52e9490..84390ee 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1381,6 +1381,34 @@ struct mem_info *sample__resolve_mem(struct perf_sample
*sample,
return mi;
}
+static int add_callchain_ip(struct thread *thread,
+ struct symbol **parent,
+ struct addr_location *root_al,
+ int cpumode,
+ u64 ip)
+{
+ struct addr_location al;
+
+ al.filtered = 0;
+ al.sym = NULL;
+ thread__find_addr_location(thread, cpumode, MAP__FUNCTION,
+ ip, );
+ if (al.sym != NULL) {
+ if (sort__has_parent && !*parent &&
+ symbol__match_regex(al.sym, _regex))
+ *parent = al.sym;
+ else if (have_ignore_callees && root_al &&
+ symbol__match_regex(al.sym, _callees_regex)) {
+ /* Treat this symbol as the root,
+ forgetting its callees. */
+ *root_al = al;
+ callchain_cursor_reset(_cursor);
+ }
+ }
+
+ return callchain_cursor_append(_cursor, ip, al.map, al.sym);
+}
+
struct branch_info *sample__resolve_bstack(struct perf_sample *sample,
struct addr_location *al)
{
@@ -1427,7 +1455,6 @@ static int thread__resolve_callchain_sample(struct thread
*thread,
for (i = 0; i < chain_nr; i++) {
u64 ip;
- struct addr_location al;
if (callchain_param.order == ORDER_CALLEE)
j = i;
@@ -1464,24 +1491,10 @@ static int thread__resolve_callchain_sample(struct
thread *thread,
continue;
}
- al.filtered = 0;
- thread__find_addr_location(thread, cpumode,
- MAP__FUNCTION, ip, );
- if (al.sym != NULL) {
- if (sort__has_parent && !*parent &&
- symbol__match_regex(al.sym, _regex))
- *parent = al.sym;
- else if (have_ignore_callees && root_al &&
- symbol__match_regex(al.sym, _callees_regex)) {
- /* Treat this symbol as the root,
- forgetting its callees. */
- *root_al = al;
- callchain_cursor_reset(_cursor);
- }
- }
-
- err = callchain_cursor_append(_cursor,
- ip, al.map, al.sym);
+ err = add_callchain_ip(thread, parent, root_al,
+ cpumode, ip);
+ if (err == -EINVAL)
+ break;
if (err)
return err;
}
--
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/
[tip:perf/core] perf diff: Add missing handler for PERF_RECORD_MMAP2 events
Commit-ID: 68ca9d65b88420c2c97948a0640bad13405129e7
Gitweb: http://git.kernel.org/tip/68ca9d65b88420c2c97948a0640bad13405129e7
Author: Kan Liang
AuthorDate: Tue, 18 Nov 2014 11:38:18 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:48 -0300
perf diff: Add missing handler for PERF_RECORD_MMAP2 events
Without mmap2, perf diff fails to find the symbol name. The default
symbol sort key doesn't work well.
Signed-off-by: Kan Liang
Acked-by: Namhyung Kim
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1416328700-1836-2-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-diff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 25114c9..1ce425d 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -357,6 +357,7 @@ static int diff__process_sample_event(struct perf_tool
*tool __maybe_unused,
static struct perf_tool tool = {
.sample = diff__process_sample_event,
.mmap = perf_event__process_mmap,
+ .mmap2 = perf_event__process_mmap2,
.comm = perf_event__process_comm,
.exit = perf_event__process_exit,
.fork = perf_event__process_fork,
--
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/
[tip:perf/core] perf annotate: Support source line numbers in annotate
Commit-ID: e592488c01d51763de847fcecb3d969231a483a9
Gitweb: http://git.kernel.org/tip/e592488c01d51763de847fcecb3d969231a483a9
Author: Andi Kleen
AuthorDate: Wed, 12 Nov 2014 18:05:26 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:48 -0300
perf annotate: Support source line numbers in annotate
With srcline key/sort'ing it's useful to have line numbers in the
annotate window. This patch implements this.
Use objdump -l to request the line numbers and save them in the line
structure. Then the browser displays them for source lines.
The line numbers are not displayed by default, but can be toggled on
with 'k'
There is one unfortunate problem with this setup. For lines not
containing source and which are outside functions objdump -l reports
line numbers off by a few: it always reports the first line number in
the next function even for lines that are outside the function.
I haven't found a nice way to detect/correct this. Probably objdump has
to be fixed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=16433
The line numbers are still useful even with these problems, as most are
correct and the ones which are not are nearby.
v2: Fix help text. Handle (discriminator...) output in objdump.
Left align the line numbers.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-9-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/annotate.c | 13 -
tools/perf/util/annotate.c| 30 +-
tools/perf/util/annotate.h| 1 +
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index f0697a3..1e0a2fd 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -27,6 +27,7 @@ static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
+show_linenr,
show_nr_jumps;
} annotate_browser__opts = {
.use_offset = true,
@@ -128,7 +129,11 @@ static void annotate_browser__write(struct ui_browser
*browser, void *entry, int
if (!*dl->line)
slsmg_write_nstring(" ", width - pcnt_width);
else if (dl->offset == -1) {
- printed = scnprintf(bf, sizeof(bf), "%*s ",
+ if (dl->line_nr && annotate_browser__opts.show_linenr)
+ printed = scnprintf(bf, sizeof(bf), "%-*d ",
+ ab->addr_width + 1, dl->line_nr);
+ else
+ printed = scnprintf(bf, sizeof(bf), "%*s ",
ab->addr_width, " ");
slsmg_write_nstring(bf, printed);
slsmg_write_nstring(dl->line, width - printed - pcnt_width + 1);
@@ -733,6 +738,7 @@ static int annotate_browser__run(struct annotate_browser
*browser,
"o Toggle disassembler output/simplified view\n"
"s Toggle source code view\n"
"/ Search string\n"
+ "k Toggle line numbers\n"
"r Run available scripts\n"
"? Search string backwards\n");
continue;
@@ -741,6 +747,10 @@ static int annotate_browser__run(struct annotate_browser
*browser,
script_browse(NULL);
continue;
}
+ case 'k':
+ annotate_browser__opts.show_linenr =
+ !annotate_browser__opts.show_linenr;
+ break;
case 'H':
nd = browser->curr_hot;
break;
@@ -984,6 +994,7 @@ static struct annotate_config {
} annotate__configs[] = {
ANNOTATE_CFG(hide_src_code),
ANNOTATE_CFG(jump_arrows),
+ ANNOTATE_CFG(show_linenr),
ANNOTATE_CFG(show_nr_jumps),
ANNOTATE_CFG(use_offset),
};
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 873c877..e5670f1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -17,11 +17,13 @@
#include "debug.h"
#include "annotate.h"
#include "evsel.h"
+#include
#include
#include
const char *disassembler_style;
const char *objdump_path;
+static regex_t file_lineno;
static struct ins *ins__find(const char *name);
static int disasm_line__parse(char *line, char **namep, char **rawp);
@@ -570,13 +572,15 @@ out_free_name:
return -1;
}
-static struct disasm_line *disasm_line__new(s64 offset, char *line, size_t
privsize)
+static struct disasm_line *disasm_line__new(s64 offset, char *line,
+ size_t privsize, int line_nr)
{
struct disasm_line *dl =
[tip:perf/core] perf tools: Fix annotation with kcore
Commit-ID: ee205503f2333d639550eaed37abb455733510a3
Gitweb: http://git.kernel.org/tip/ee205503f2333d639550eaed37abb455733510a3
Author: Adrian Hunter
AuthorDate: Tue, 11 Nov 2014 12:04:54 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:47 -0300
perf tools: Fix annotation with kcore
Patch "perf tools: Fix build-id matching on vmlinux" breaks annotation
with kcore. The problem is that symbol__annotate() first gets the
filename based on the build-id which was previously not set.
This patch provides a quick fix, however there should probably be only
one way to determine the filename. e.g. symbol__annotate() should use
the same way as dso__data_fd().
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1415700294-30816-1-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 7dabde1..873c877 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -915,6 +915,8 @@ int symbol__annotate(struct symbol *sym, struct map *map,
size_t privsize)
return -ENOMEM;
}
goto fallback;
+ } else if (dso__is_kcore(dso)) {
+ goto fallback;
} else if (readlink(symfs_filename, command, sizeof(command)) < 0 ||
strstr(command, "[kernel.kallsyms]") ||
access(symfs_filename, R_OK)) {
--
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/
[tip:perf/core] perf symbols: Fallback to kallsyms when using the minimal 'ELF' loader
Commit-ID: 162bcc17bb876772793ca070ebd6488cfdae09bf
Gitweb: http://git.kernel.org/tip/162bcc17bb876772793ca070ebd6488cfdae09bf
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 11 Nov 2014 11:25:28 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:46 -0300
perf symbols: Fallback to kallsyms when using the minimal 'ELF' loader
The minimal ELF loader should not return 1 when it manages to read the
vmlinux build-id, it should instead return 0, meaning that it hasn't
loaded any symbols, since it doesn't parses ELF at all.
That way, the main symbol.c routines will understand that it is
necessary to continue looking for a file with symbols, and when no
libelf is linked, that means it will eventually try kallsyms.
Reported-by: Peter Zijlstra
Tested-by: Peter Zijlstra
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/2014130326.gt18...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/symbol-minimal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index c9541fe..fa585c6 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -341,7 +341,6 @@ int dso__load_sym(struct dso *dso, struct map *map
__maybe_unused,
if (filename__read_build_id(ss->name, build_id, BUILD_ID_SIZE) > 0) {
dso__set_build_id(dso, build_id);
- return 1;
}
return 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/
[tip:perf/core] perf callchain: Use al.addr to set up call chain
Commit-ID: 5550171b2a9f8df26ff483051d060db06376b26d Gitweb: http://git.kernel.org/tip/5550171b2a9f8df26ff483051d060db06376b26d Author: Andi Kleen AuthorDate: Wed, 12 Nov 2014 18:05:21 -0800 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 19 Nov 2014 12:33:47 -0300 perf callchain: Use al.addr to set up call chain Use the relative address, this makes get_srcline work correctly in the end. Signed-off-by: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1415844328-4884-4-git-send-email-a...@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/machine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c index 84390ee..d97309c 100644 --- a/tools/perf/util/machine.c +++ b/tools/perf/util/machine.c @@ -1406,7 +1406,7 @@ static int add_callchain_ip(struct thread *thread, } } - return callchain_cursor_append(_cursor, ip, al.map, al.sym); + return callchain_cursor_append(_cursor, al.addr, al.map, al.sym); } struct branch_info *sample__resolve_bstack(struct perf_sample *sample, -- 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/
[tip:perf/core] perf test: fix typo in python test
Commit-ID: 887e73d7f42c6a146b572a0577e9875ccca66f37
Gitweb: http://git.kernel.org/tip/887e73d7f42c6a146b572a0577e9875ccca66f37
Author: WANG Chao
AuthorDate: Wed, 12 Nov 2014 16:27:05 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:47 -0300
perf test: fix typo in python test
Library loading in python syntax should be 'import perf', not 'use perf'.
Signed-off-by: WANG Chao
Cc: Adrian Hunter
Cc: Ingo Molnar
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1415780826-13250-1-git-send-email-chaow...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/builtin-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 162c978..4b7d9ab 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -85,7 +85,7 @@ static struct test {
.func = test__hists_link,
},
{
- .desc = "Try 'use perf' in python, checking link problems",
+ .desc = "Try 'import perf' in python, checking link problems",
.func = test__python_use,
},
{
--
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/
[tip:perf/core] perf tools: Only print base source file for srcline
Commit-ID: 2de217688e8f086bf6d920d530401b56fcbc6eff
Gitweb: http://git.kernel.org/tip/2de217688e8f086bf6d920d530401b56fcbc6eff
Author: Andi Kleen
AuthorDate: Wed, 12 Nov 2014 18:05:25 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:47 -0300
perf tools: Only print base source file for srcline
For perf report with --sort srcline only print the base source file
name. This makes the results generally fit much better to the screen.
The path is usually not that useful anyways because it is often from
different systems.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-8-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/srcline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index f3e4bc5..77c1806 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -274,7 +274,7 @@ char *get_srcline(struct dso *dso, unsigned long addr)
if (!addr2line(dso_name, addr, , , dso))
goto out;
- if (asprintf(, "%s:%u", file, line) < 0) {
+ if (asprintf(, "%s:%u", basename(file), line) < 0) {
free(file);
goto out;
}
--
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/
[tip:perf/core] perf callchain: Use a common function to resolve symbol or name
Commit-ID: 2989ccaac48f8c3da7f77101bbf98e0ea8773d83
Gitweb: http://git.kernel.org/tip/2989ccaac48f8c3da7f77101bbf98e0ea8773d83
Author: Andi Kleen
AuthorDate: Wed, 12 Nov 2014 18:05:23 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:47 -0300
perf callchain: Use a common function to resolve symbol or name
Refactor the duplicated code to resolve the symbol name or
the address of a symbol into a single function.
Used in next patch to add common functionality.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-6-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 17 -
tools/perf/ui/gtk/hists.c | 11 +--
tools/perf/ui/stdio/hist.c | 23 +--
tools/perf/util/callchain.c| 19 +++
tools/perf/util/callchain.h| 3 +++
5 files changed, 32 insertions(+), 41 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index cfb976b..12c17c5 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -463,23 +463,6 @@ out:
return key;
}
-static char *callchain_list__sym_name(struct callchain_list *cl,
- char *bf, size_t bfsize, bool show_dso)
-{
- int printed;
-
- if (cl->ms.sym)
- printed = scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
- else
- printed = scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
-
- if (show_dso)
- scnprintf(bf + printed, bfsize - printed, " %s",
- cl->ms.map ? cl->ms.map->dso->short_name : "unknown");
-
- return bf;
-}
-
struct callchain_print_arg {
/* for hists browser */
off_t row_offset;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index fc654fb..4b3585e 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -89,15 +89,6 @@ void perf_gtk__init_hpp(void)
perf_gtk__hpp_color_overhead_acc;
}
-static void callchain_list__sym_name(struct callchain_list *cl,
-char *bf, size_t bfsize)
-{
- if (cl->ms.sym)
- scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
- else
- scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
-}
-
static void perf_gtk__add_callchain(struct rb_root *root, GtkTreeStore *store,
GtkTreeIter *parent, int col, u64 total)
{
@@ -128,7 +119,7 @@ static void perf_gtk__add_callchain(struct rb_root *root,
GtkTreeStore *store,
scnprintf(buf, sizeof(buf), "%5.2f%%", percent);
gtk_tree_store_set(store, , 0, buf, -1);
- callchain_list__sym_name(chain, buf, sizeof(buf));
+ callchain_list__sym_name(chain, buf, sizeof(buf),
false);
gtk_tree_store_set(store, , col, buf, -1);
if (need_new_parent) {
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 15b451a..dfcbc90 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -41,6 +41,7 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct
callchain_list *chain,
{
int i;
size_t ret = 0;
+ char bf[1024];
ret += callchain__fprintf_left_margin(fp, left_margin);
for (i = 0; i < depth; i++) {
@@ -56,11 +57,8 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct
callchain_list *chain,
} else
ret += fprintf(fp, "%s", " ");
}
- if (chain->ms.sym)
- ret += fprintf(fp, "%s\n", chain->ms.sym->name);
- else
- ret += fprintf(fp, "0x%0" PRIx64 "\n", chain->ip);
-
+ fputs(callchain_list__sym_name(chain, bf, sizeof(bf), false), fp);
+ fputc('\n', fp);
return ret;
}
@@ -168,6 +166,7 @@ static size_t callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
struct rb_node *node;
int i = 0;
int ret = 0;
+ char bf[1024];
/*
* If have one single callchain root, don't bother printing
@@ -196,10 +195,8 @@ static size_t callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
} else
ret += callchain__fprintf_left_margin(fp,
left_margin);
- if (chain->ms.sym)
- ret += fprintf(fp, " %s\n",
chain->ms.sym->name);
- else
- ret += fprintf(fp, " %p\n", (void
*)(long)chain->ip);
+ ret += fprintf(fp, "%s\n",
callchain_list__sym_name(chain, bf, sizeof(bf),
+ false));
if (++entries_printed ==
[tip:perf/core] perf build-id: Move disable_buildid_cache() to util/build-id.c
Commit-ID: 73c5d224b4514575abe0dd89b43adbde937429c3
Gitweb: http://git.kernel.org/tip/73c5d224b4514575abe0dd89b43adbde937429c3
Author: Namhyung Kim
AuthorDate: Fri, 7 Nov 2014 22:57:56 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Nov 2014 12:33:46 -0300
perf build-id: Move disable_buildid_cache() to util/build-id.c
Also move static variable no_buildid_cache and check it in the
perf_session_cache_build_ids().
Signed-off-by: Namhyung Kim
Cc: Aravinda Prasad
Cc: Brendan Gregg
Cc: Hemant Kumar
Cc: Ingo Molnar
Cc: Masami Hiramatsu
Cc: Oleg Nesterov
Cc: Pekka Enberg
Cc: Peter Zijlstra
Cc: Srikar Dronamraju
Cc: Vasant Hegde
Cc: system...@sourceware.org
Link:
http://lkml.kernel.org/r/1415368677-3794-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/build-id.c | 11 +++
tools/perf/util/build-id.h | 1 +
tools/perf/util/header.c | 10 +-
tools/perf/util/util.h | 1 -
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index dd2a3e5..e8d79e5 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -18,6 +18,9 @@
#include "header.h"
#include "vdso.h"
+
+static bool no_buildid_cache;
+
int build_id__mark_dso_hit(struct perf_tool *tool __maybe_unused,
union perf_event *event,
struct perf_sample *sample,
@@ -251,6 +254,11 @@ int dsos__hit_all(struct perf_session *session)
return 0;
}
+void disable_buildid_cache(void)
+{
+ no_buildid_cache = true;
+}
+
int build_id_cache__add_s(const char *sbuild_id, const char *debugdir,
const char *name, bool is_kallsyms, bool is_vdso)
{
@@ -404,6 +412,9 @@ int perf_session__cache_build_ids(struct perf_session
*session)
int ret;
char debugdir[PATH_MAX];
+ if (no_buildid_cache)
+ return 0;
+
snprintf(debugdir, sizeof(debugdir), "%s", buildid_dir);
if (mkdir(debugdir, 0755) != 0 && errno != EEXIST)
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index 666a3bd..8236319 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -25,5 +25,6 @@ int perf_session__cache_build_ids(struct perf_session
*session);
int build_id_cache__add_s(const char *sbuild_id, const char *debugdir,
const char *name, bool is_kallsyms, bool is_vdso);
int build_id_cache__remove_s(const char *sbuild_id, const char *debugdir);
+void disable_buildid_cache(void);
#endif
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 05fab7a..b20e40c 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -24,8 +24,6 @@
#include "build-id.h"
#include "data.h"
-static bool no_buildid_cache = false;
-
static u32 header_argc;
static const char **header_argv;
@@ -191,8 +189,7 @@ static int write_build_id(int fd, struct perf_header *h,
pr_debug("failed to write buildid table\n");
return err;
}
- if (!no_buildid_cache)
- perf_session__cache_build_ids(session);
+ perf_session__cache_build_ids(session);
return 0;
}
@@ -2791,8 +2788,3 @@ int perf_event__process_build_id(struct perf_tool *tool
__maybe_unused,
session);
return 0;
}
-
-void disable_buildid_cache(void)
-{
- no_buildid_cache = true;
-}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 7dc44cf..76d23d8 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -154,7 +154,6 @@ extern void set_die_routine(void (*routine)(const char
*err, va_list params) NOR
extern int prefixcmp(const char *str, const char *prefix);
extern void set_buildid_dir(void);
-extern void disable_buildid_cache(void);
static inline const char *skip_prefix(const char *str, const char *prefix)
{
--
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/
[tip:perf/core] perf tools: Clean up libelf feature support code
Commit-ID: 5e2d4d0e88dac4003cf96aca00d63aff2314391e Gitweb: http://git.kernel.org/tip/5e2d4d0e88dac4003cf96aca00d63aff2314391e Author: Namhyung Kim AuthorDate: Fri, 7 Nov 2014 14:20:06 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 19 Nov 2014 12:33:46 -0300 perf tools: Clean up libelf feature support code Current EXTLIBS contains -lelf by default and removes it when libelf is not detected. This is little bit confusing since we can now build perf without libelf so there's no need to handle it differently than other libraries. Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: David Ahern Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1415337606-2186-3-git-send-email-namhy...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 2 -- tools/perf/config/Makefile | 5 +++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index aecf61dc..478efa9 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -497,8 +497,6 @@ ifneq ($(OUTPUT),) endif ifdef NO_LIBELF -EXTLIBS := $(filter-out -lelf,$(EXTLIBS)) - # Remove ELF/DWARF dependent codes LIB_OBJS := $(filter-out $(OUTPUT)util/symbol-elf.o,$(LIB_OBJS)) LIB_OBJS := $(filter-out $(OUTPUT)util/dwarf-aux.o,$(LIB_OBJS)) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 79f906c..5d4b039 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -150,7 +150,7 @@ CFLAGS += -std=gnu99 # adding assembler files missing the .GNU-stack linker note. LDFLAGS += -Wl,-z,noexecstack -EXTLIBS = -lelf -lpthread -lrt -lm -ldl +EXTLIBS = -lpthread -lrt -lm -ldl ifneq ($(OUTPUT),) OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/ @@ -354,6 +354,7 @@ endif # NO_LIBELF ifndef NO_LIBELF CFLAGS += -DHAVE_LIBELF_SUPPORT + EXTLIBS += -lelf ifeq ($(feature-libelf-mmap), 1) CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT @@ -373,7 +374,7 @@ ifndef NO_LIBELF else CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS) LDFLAGS += $(LIBDW_LDFLAGS) - EXTLIBS += -lelf -ldw + EXTLIBS += -ldw endif # PERF_HAVE_DWARF_REGS endif # NO_DWARF endif # NO_LIBELF -- 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: [GIT PULL 00/16] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 2565711fb7d7c28e0cd93c8971b520d1b10b857c: > > perf: Improve the perf_sample_data struct layout (2014-11-16 11:42:04 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo > > for you to fetch changes up to a84808083688d82d7f1e5786ccf5df0ff7d448cb: > > perf tools: Only override the default :tid comm entry (2014-11-19 12:37:26 > -0300) > > > perf/core improvements and fixes: > > User visible fixes: > > - Fallback to kallsyms when using the minimal 'ELF' loader (Arnaldo Carvalho > de Melo) > > - Fix annotation with kcore (Adrian Hunter) > > - Fix up srcline histogram key formatting (Arnaldo Carvalho de Melo) > > - Add missing handler for PERF_RECORD_MMAP2 events in 'perf diff' (Kan Liang) > > User visible changes/new features: > > - Only print base source file for srcline histogram sort key (Andi Kleen) > > - Support source line numbers in annotate using a hotkey (Andi Kleen) > > Infrastructure: > > - Do not poll events that use the system_wide flag (Adrian Hunter) > > - Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore (Adrian Hunter) > > perf tools: Only override the default :tid comm entry (Adrian Hunter) > > - Factor out adding new call chain entries (Andi Kleen) > > - Use al.addr to set up call chain (Andi Kleen) > > - Use a common function to resolve symbol or name (Andi Kleen) > > - Fix ftrace:function event recording (Jiri Olsa) > > - Move disable_buildid_cache() to util/build-id.c (Namhyung Kim) > > - Clean up libelf feature support code (Namhyung Kim) > > - fix typo in python 'perf test' (WANG Chao) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Adrian Hunter (4): > perf tools: Fix annotation with kcore > perf evlist: Do not poll events that use the system_wide flag > perf tools: Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore > perf tools: Only override the default :tid comm entry > > Andi Kleen (5): > perf callchain: Factor out adding new call chain entries > perf callchain: Use al.addr to set up call chain > perf callchain: Use a common function to resolve symbol or name > perf tools: Only print base source file for srcline > perf annotate: Support source line numbers in annotate > > Arnaldo Carvalho de Melo (2): > perf symbols: Fallback to kallsyms when using the minimal 'ELF' loader > perf hists: Fix up srcline histogram key formatting > > Jiri Olsa (1): > perf evsel: Fix ftrace:function event recording > > Kan Liang (1): > perf diff: Add missing handler for PERF_RECORD_MMAP2 events > > Namhyung Kim (2): > perf build-id: Move disable_buildid_cache() to util/build-id.c > perf tools: Clean up libelf feature support code > > WANG Chao (1): > perf test: fix typo in python test > > tools/perf/.gitignore | 2 ++ > tools/perf/Makefile.perf | 2 -- > tools/perf/builtin-diff.c | 1 + > tools/perf/config/Makefile| 5 ++-- > tools/perf/tests/builtin-test.c | 2 +- > tools/perf/ui/browsers/annotate.c | 13 +- > tools/perf/ui/browsers/hists.c| 17 - > tools/perf/ui/gtk/hists.c | 11 + > tools/perf/ui/stdio/hist.c| 23 +++--- > tools/perf/util/annotate.c| 32 > tools/perf/util/annotate.h| 1 + > tools/perf/util/build-id.c| 11 + > tools/perf/util/build-id.h| 1 + > tools/perf/util/callchain.c | 19 +++ > tools/perf/util/callchain.h | 3 +++ > tools/perf/util/evlist.c | 10 +++- > tools/perf/util/evsel.c | 8 ++ > tools/perf/util/header.c | 10 +--- > tools/perf/util/machine.c | 51 > --- > tools/perf/util/sort.c| 2 +- > tools/perf/util/srcline.c | 2 +- > tools/perf/util/symbol-minimal.c | 1 - > tools/perf/util/thread.c | 5 ++-- > tools/perf/util/util.h| 1 - > 24 files changed, 145 insertions(+), 88 deletions(-) Pulled into tip:perf/core, thanks a lot Arnaldo! Ingo -- 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/
[GIT PULL] dmaengine fixes
Hi Linus, We have couple of fixes for dmaengine queued up, please consider pull to receive: - dma mempcy fix for dma configuration of sun6i by Maxime - pl330 got rest. First the fixing allocation for data buffers by Liviu and then Jon's fixed for fifo width and usage The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: Linus Torvalds (1): Linux 3.18-rc3 are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git fixes Jon Medhurst (2): dmaengine: pl330: Align DMA memcpy operations to MFIFO width dmaengine: pl330: Limit MFIFO usage for memcpy to avoid exhausting entries Liviu Dudau (1): dmaengine: Fix allocation size for PL330 data buffer depth. Maxime Ripard (1): dmaengine: sun6i: Fix memcpy operation drivers/dma/pl330.c | 23 - drivers/dma/sun6i-dma.c | 61 +++ 2 files changed, 46 insertions(+), 38 deletions(-) Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
(2014/11/18 23:52), Will Deacon wrote:
> Hi David,
>
> On Tue, Nov 18, 2014 at 06:32:55AM +, David Long wrote:
>> From: "David A. Long"
>>
>> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>
> [...]
>
>> diff --git a/arch/arm64/include/asm/ptrace.h
>> b/arch/arm64/include/asm/ptrace.h
>> index d3e782a..24cc048 100644
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -111,6 +111,8 @@ struct pt_regs {
>> u64 syscallno;
>> };
>>
>> +#define MAX_REG_OFFSET (offsetof(struct pt_regs, orig_x0))
>
> Is orig_x0 actually useful to this API? If not, we could instead operate on
> the user_pt_regs structure, and define the maximum offset in terms of sizeof
> that.
It depends on the architecture, but this patch provides the common interface
for kprobe-tracer. I think this code looks OK, since kprobe-tracer doesn't
use user_pt_regs.
>
>> +#define ARM_cpsrpstate
>> +#define ARM_pc pc
>> +#define ARM_sp sp
>> +#define ARM_lr regs[30]
>> +#define ARM_fp regs[29]
>> +#define ARM_x28 regs[28]
>> +#define ARM_x27 regs[27]
>
> [...]
>
> I don't think we need these #defines.
Agreed.
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
[PATCH] sched, cleanup, dm bufio: Replace dm_bufio_cond_resched with might_resched
The judge of need_resched() before _cond_resched() in dm_bufio_cond_resched()
is no need. Because _cond_resched() itself judges should_resched() which means
need and can resched. In addition, might_resched() can do all these.
Signed-off-by: Yao Dongdong
---
drivers/md/dm-bufio.c | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index afe7971..3660a24 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -186,19 +186,6 @@ static void dm_bufio_unlock(struct dm_bufio_client *c)
mutex_unlock(>lock);
}
-/*
- * FIXME Move to sched.h?
- */
-#ifdef CONFIG_PREEMPT_VOLUNTARY
-# define dm_bufio_cond_resched() \
-do { \
- if (unlikely(need_resched())) \
- _cond_resched();\
-} while (0)
-#else
-# define dm_bufio_cond_resched()do { } while (0)
-#endif
-
/**/
/*
@@ -648,7 +635,7 @@ static void __flush_write_list(struct list_head *write_list)
list_entry(write_list->next, struct dm_buffer,
write_list);
list_del(>write_list);
submit_io(b, WRITE, b->block, write_endio);
- dm_bufio_cond_resched();
+ might_resched();
}
blk_finish_plug();
}
@@ -687,7 +674,7 @@ static struct dm_buffer *__get_unclaimed_buffer(struct
dm_bufio_client *c)
__unlink_buffer(b);
return b;
}
- dm_bufio_cond_resched();
+ might_resched();
}
list_for_each_entry_reverse(b, >lru[LIST_DIRTY], lru_list) {
@@ -698,7 +685,7 @@ static struct dm_buffer *__get_unclaimed_buffer(struct
dm_bufio_client *c)
__unlink_buffer(b);
return b;
}
- dm_bufio_cond_resched();
+ might_resched();
}
return NULL;
@@ -830,7 +817,7 @@ static void __write_dirty_buffers_async(struct
dm_bufio_client *c, int no_wait,
return;
__write_dirty_buffer(b, write_list);
- dm_bufio_cond_resched();
+ might_resched();
}
}
@@ -880,7 +867,7 @@ static void __check_watermark(struct dm_bufio_client *c,
return;
__free_buffer_wake(b);
- dm_bufio_cond_resched();
+ might_resched();
}
if (c->n_buffers[LIST_DIRTY] > threshold_buffers)
@@ -896,7 +883,7 @@ static struct dm_buffer *__find(struct dm_bufio_client *c,
sector_t block)
hlist_for_each_entry(b, >cache_hash[DM_BUFIO_HASH(block)],
hash_list) {
- dm_bufio_cond_resched();
+ might_resched();
if (b->block == block)
return b;
}
@@ -1090,7 +1077,7 @@ void dm_bufio_prefetch(struct dm_bufio_client *c,
submit_io(b, READ, b->block, read_endio);
dm_bufio_release(b);
- dm_bufio_cond_resched();
+ might_resched();
if (!n_blocks)
goto flush_plug;
@@ -1211,7 +1198,7 @@ again:
!test_bit(B_WRITING, >state))
__relink_lru(b, LIST_CLEAN);
- dm_bufio_cond_resched();
+ might_resched();
/*
* If we dropped the lock, the list is no longer consistent,
@@ -1473,7 +1460,7 @@ static long __scan(struct dm_bufio_client *c, unsigned
long nr_to_scan,
freed += __cleanup_old_buffer(b, gfp_mask, 0);
if (!--nr_to_scan)
return freed;
- dm_bufio_cond_resched();
+ might_resched();
}
}
return freed;
@@ -1704,11 +1691,11 @@ static void cleanup_old_buffers(void)
struct dm_buffer, lru_list);
if (!__cleanup_old_buffer(b, 0, max_age * HZ))
break;
- dm_bufio_cond_resched();
+ might_resched();
}
dm_bufio_unlock(c);
- dm_bufio_cond_resched();
+ might_resched();
}
mutex_unlock(_bufio_clients_lock);
}
--
1.8.3.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/
[PATCH 18/22] [SCSI] mpt3sas: Update MPI2 strings to MPI2.5
Update MPI2 strings to MPI2.5.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 3 +--
drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 4322d7c..5fafd51 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3891,7 +3891,7 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc, int
sleep_flag)
mpi_request.WhoInit = MPI2_WHOINIT_HOST_DRIVER;
mpi_request.VF_ID = 0; /* TODO */
mpi_request.VP_ID = 0;
- mpi_request.MsgVersion = cpu_to_le16(MPI2_VERSION);
+ mpi_request.MsgVersion = cpu_to_le16(MPI25_VERSION);
mpi_request.HeaderVersion = cpu_to_le16(MPI2_HEADER_VERSION);
if (_base_is_controller_msix_enabled(ioc))
@@ -4759,7 +4759,6 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
ioc->build_sg_scmd = &_base_build_sg_scmd_ieee;
ioc->build_sg = &_base_build_sg_ieee;
ioc->build_zero_len_sge = &_base_build_zero_len_sge_ieee;
- ioc->mpi25 = 1;
ioc->sge_size_ieee = sizeof(Mpi2IeeeSgeSimple64_t);
/*
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 4c07f17..c27e94e 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -818,7 +818,6 @@ struct MPT3SAS_ADAPTER {
MPT_BUILD_SG_SCMD build_sg_scmd;
MPT_BUILD_SGbuild_sg;
MPT_BUILD_ZERO_LEN_SGE build_zero_len_sge;
- u8 mpi25;
u16 sge_size_ieee;
/* function ptr for MPI sg elements only */
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/22] [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00
Bump mpt3sas Driver version to v5.100.00.00 Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index dba4d66..4c07f17 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -71,8 +71,8 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "04.100.00.00" -#define MPT3SAS_MAJOR_VERSION 4 +#define MPT3SAS_DRIVER_VERSION "05.100.00.00" +#define MPT3SAS_MAJOR_VERSION 5 #define MPT3SAS_MINOR_VERSION 100 #define MPT3SAS_BUILD_VERSION 0 #define MPT3SAS_RELEASE_VERSION00 -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/22] [SCSI] mpt2sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081
For any SCSI command, if the driver receives IOC status = SCSI_IOC_TERMINATED
and log info = 0x32010081
then that command will be completed with DID_RESET host status.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 38acb91..c6bb136 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -4574,6 +4574,10 @@ _scsih_io_done(struct MPT2SAS_ADAPTER *ioc, u16 smid, u8
msix_index, u32 reply)
scmd->result = DID_TRANSPORT_DISRUPTED << 16;
goto out;
}
+ if (log_info == 0x32010081) {
+ scmd->result = DID_RESET << 16;
+ break;
+ }
scmd->result = DID_SOFT_ERROR << 16;
break;
case MPI2_IOCSTATUS_SCSI_TASK_TERMINATED:
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 22/22] [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00
Bump mpt3sas driver version to v6.100.00.00. Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index 9608e3a..035a244 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -71,8 +71,8 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "05.100.00.00" -#define MPT3SAS_MAJOR_VERSION 5 +#define MPT3SAS_DRIVER_VERSION "06.100.00.00" +#define MPT3SAS_MAJOR_VERSION 6 #define MPT3SAS_MINOR_VERSION 100 #define MPT3SAS_BUILD_VERSION 0 #define MPT3SAS_RELEASE_VERSION00 -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/22] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
In this patch, increased the number of MSIX vector support for SAS3 C0 HBAs to
up-to 96.
Following are changes that are done in this patch
1. Support this feature only for SAS3 C0 cards and also only when reply post
free queue count is greater than 8.
2. Instead of using single ReplyPostHostIndex system interface, here 12
ReplyPostHostIndex system interfaces are used. reply post free queues numbered
from 0 to 7 use the first ReplyPostHostIndex system interface to update its
corresponding ReplyPostHostIndex values, reply post free queues numbered from 8
to 15 will use the second ReplyPostHostIndex system interface and so on. These
12 ReplyPostHostIndex system interfaces address are saved in the array
replyPostRegisterIndex[].
3. Update the ReplyPostHostIndex value of corresponding reply post free queue
in the (its msix_index/8)th entry of replyPostRegisterIndex[] array after
processing the reply post descriptor.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 70 +
drivers/scsi/mpt3sas/mpt3sas_base.h | 7 +++-
2 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index d9f1943..958a870 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -83,7 +83,7 @@ static int msix_disable = -1;
module_param(msix_disable, int, 0);
MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts (default=0)");
-static int max_msix_vectors = 8;
+static int max_msix_vectors = -1;
module_param(max_msix_vectors, int, 0);
MODULE_PARM_DESC(max_msix_vectors,
" max msix vectors - (default=8)");
@@ -1009,8 +1009,15 @@ _base_interrupt(int irq, void *bus_id)
}
wmb();
- writel(reply_q->reply_post_host_index | (msix_index <<
- MPI2_RPHI_MSIX_INDEX_SHIFT), >chip->ReplyPostHostIndex);
+ if (ioc->msix96_vector) {
+ writel(reply_q->reply_post_host_index | ((msix_index & 7) <<
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc->replyPostRegisterIndex[msix_index/8]);
+ } else {
+ writel(reply_q->reply_post_host_index | (msix_index <<
+ MPI2_RPHI_MSIX_INDEX_SHIFT),
+ >chip->ReplyPostHostIndex);
+ }
atomic_dec(_q->busy);
return IRQ_HANDLED;
}
@@ -1560,8 +1567,6 @@ _base_check_enable_msix(struct MPT3SAS_ADAPTER *ioc)
pci_read_config_word(ioc->pdev, base + 2, _control);
ioc->msix_vector_count = (message_control & 0x3FF) + 1;
- if (ioc->msix_vector_count > 8)
- ioc->msix_vector_count = 8;
dinitprintk(ioc, pr_info(MPT3SAS_FMT
"msix is supported, vector_count(%d)\n",
ioc->name, ioc->msix_vector_count));
@@ -1873,6 +1878,31 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
if (r)
goto out_fail;
+ /* Use the Combined reply queue feature only for SAS3 C0 HBAs and
+* also only when reply queue count is greater than 8
+*/
+ if (ioc->msix96_vector && ioc->reply_queue_count > 8) {
+ /* If this is an 96 vector supported device,
+ set up ReplyPostIndex addresses */
+ ioc->replyPostRegisterIndex = kcalloc(12,
+ sizeof(resource_size_t *), GFP_KERNEL);
+ if (!ioc->replyPostRegisterIndex) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "allocation for reply Post Register Index failed!!!\n",
+ ioc->name));
+ r = -ENOMEM;
+ goto out_fail;
+ }
+
+ for (i = 0; i < 12; i++) {
+ ioc->replyPostRegisterIndex[i] = (resource_size_t *)
+ ((u8 *)>chip->Doorbell +
+ MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
+ (i * 0x10));
+ }
+ } else
+ ioc->msix96_vector = 0;
+
list_for_each_entry(reply_q, >reply_queue_list, list)
pr_info(MPT3SAS_FMT "%s: IRQ %d\n",
reply_q->name, ((ioc->msix_enable) ? "PCI-MSI-X enabled" :
@@ -1894,6 +1924,8 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
pci_release_selected_regions(ioc->pdev, ioc->bars);
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
+ if (ioc->msix96_vector)
+ kfree(ioc->replyPostRegisterIndex);
return r;
}
@@ -4512,8 +4544,16 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
/* initialize reply post host index */
list_for_each_entry(reply_q, >reply_queue_list, list) {
- writel(reply_q->msix_index <<
[PATCH 20/22] [SCSI] mpt3sas: Add branding string support for OEM's HBA
Added the following Dell branding to the mpt3sas driver.
"VendorID" "DeviceID" "SubsystemVendor ID" "SubsystemDevice ID" Dell
Branding String
0x10000x0097 0x1028 0x1F46DELL
12Gbps HBA
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 36
drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5fafd51..cc1bfef 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2338,6 +2338,41 @@ _base_display_intel_branding(struct MPT3SAS_ADAPTER *ioc)
/**
+ * _base_display_dell_branding - Display branding string
+ * @ioc: per adapter object
+ *
+ * Return nothing.
+ */
+static void
+_base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
+{
+ if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
+ return;
+
+ switch (ioc->pdev->device) {
+ case MPI25_MFGPAGE_DEVID_SAS3008:
+ switch (ioc->pdev->subsystem_device) {
+ case MPT3SAS_DELL_12G_HBA_SSDID:
+ pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+ MPT3SAS_DELL_12G_HBA_BRANDING);
+ break;
+ default:
+ pr_info(MPT3SAS_FMT
+ "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
+ ioc->pdev->subsystem_device);
+ break;
+ }
+ break;
+ default:
+ pr_info(MPT3SAS_FMT
+ "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
+ ioc->pdev->subsystem_device);
+ break;
+ }
+}
+
+
+/**
* _base_display_ioc_capabilities - Disply IOC's capabilities.
* @ioc: per adapter object
*
@@ -2367,6 +2402,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER
*ioc)
bios_version & 0x00FF);
_base_display_intel_branding(ioc);
+ _base_display_dell_branding(ioc);
pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index c27e94e..f2ce5a5 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -152,6 +152,17 @@
#define MPT3SAS_INTEL_RS3UC080_SSDID0x3524
/*
+ * Dell HBA branding
+ */
+#define MPT3SAS_DELL_12G_HBA_BRANDING \
+ "Dell 12Gbps HBA"
+
+/*
+ * Dell HBA SSDIDs
+ */
+#define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
+
+/*
* status bits for ioc->diag_buffer_status
*/
#define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/22] [SCSI] mpt3sas: Added module parameter 'unblock_io' to unblock IO's during disk addition
During hot-plugging of a disk(having a flaky link), the disk addition
stops and any further disk addition or removal doesn't happen on that
controller.
This is because, when driver receives DELAY_NOT_RESPONDING for a disk when it
is undergoing
addition in the SCSI Mid layer, the driver would block the I/O to that disk
resulting in a deadlock. i.e the disk addition work couldn't be completed
as it can't send any I/O to the disk as I/Os are blocked. Any device removal
(TARGET_NOT_RESPONDING)
or link update(RC_PHY_CHANGED) couldn't be processed as they are in the queue
to get processed after disk addition.
Description of Change:
To handle such cases, unblock the I/Os to the disk in ISR context if the disk
is undergoing
addition. The I/Os would get unblocked only if the driver receives
RC_PHY_CHANGED reason
code when the device addition is within the SAS Transport layer.
An module parameter 'unblock_io' is introduced which needs to be set to have
this
functionality enabled. By default this functionality is disabled.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 4 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 63 +---
drivers/scsi/mpt3sas/mpt3sas_transport.c | 14 +++
3 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 348b3f6..7dd5510 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -294,7 +294,8 @@ struct _internal_cmd {
* @responding: used in _scsih_sas_device_mark_responding
* @fast_path: fast path feature enable bit
* @pfa_led_on: flag for PFA LED status
- *
+ * @pend_sas_rphy_add: flag to check if device is in sas_rphy_add()
+ * addition routine
*/
struct _sas_device {
struct list_head list;
@@ -315,6 +316,7 @@ struct _sas_device {
u8 responding;
u8 fast_path;
u8 pfa_led_on;
+ u8 pend_sas_rphy_add;
};
/**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 1b9a3a9..1ca5f98 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -111,6 +111,11 @@ static int missing_delay[2] = {-1, -1};
module_param_array(missing_delay, int, NULL, 0);
MODULE_PARM_DESC(missing_delay, " device missing delay , io missing delay");
+static int unblock_io;
+module_param(unblock_io, int, 0);
+MODULE_PARM_DESC(unblock_io,
+"unblocks IO if set to 1 when device is undergoing addition (default=0)");
+
/* scsi-mid layer global parmeter is max_report_luns, which is 511 */
#define MPT3SAS_MAX_LUN (16895)
static u64 max_lun = MPT3SAS_MAX_LUN;
@@ -2629,6 +2634,34 @@ _scsih_ublock_io_device(struct MPT3SAS_ADAPTER *ioc, u64
sas_address)
}
}
+/*
+ *_scsih_ublock_io_device_to_running - set the device state to SDEV_RUNNING
+ *@ioc: per adapter object
+ *@sas_addr: sas address
+ *
+ *unblock the device to receive IO during device addition. Device
+ *responsiveness is not checked before unblocking
+ */
+static void
+_scsih_ublock_io_device_to_running(struct MPT3SAS_ADAPTER *ioc, u64
sas_address)
+{
+ struct MPT3SAS_DEVICE *sas_device_priv_data;
+ struct scsi_device *sdev;
+
+ shost_for_each_device(sdev, ioc->shost) {
+ sas_device_priv_data = sdev->hostdata;
+ if (!sas_device_priv_data)
+ continue;
+ if (sas_device_priv_data->sas_target->sas_address
+ != sas_address)
+ continue;
+ if (sas_device_priv_data->block) {
+ sas_device_priv_data->block = 0;
+ scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+ }
+ }
+}
+
/**
* _scsih_block_io_all_device - set the device state to SDEV_BLOCK
* @ioc: per adapter object
@@ -2736,20 +2769,22 @@ _scsih_block_io_to_children_attached_to_ex(struct
MPT3SAS_ADAPTER *ioc,
}
/**
- * _scsih_block_io_to_children_attached_directly
+ * _scsih_handle_io_to_children_attached_directly
* @ioc: per adapter object
* @event_data: topology change event data
*
- * This routine set sdev state to SDEV_BLOCK for all devices
+ * This routine set sdev state to SDEV_BLOCK or SDEV_RUNNING for all devices
* direct attached during device pull.
*/
static void
-_scsih_block_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc,
+_scsih_handle_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc,
Mpi2EventDataSasTopologyChangeList_t *event_data)
{
int i;
u16 handle;
u16 reason_code;
+ struct _sas_device *sas_device;
+ u8 link_rate, prev_link_rate;
for (i = 0; i < event_data->NumEntries; i++) {
handle = le16_to_cpu(event_data->PHY[i].AttachedDevHandle);
@@ -2759,6 +2794,24 @@ _scsih_block_io_to_children_attached_directly(struct
MPT3SAS_ADAPTER *ioc,
[PATCH 00/22] mpt2sas, mpt3sas: SAS2 Phase 19,20 and SAS3 Phase 4,5 patches
Please consider this Patch set for next kernel release. Highlights of this patch set: - 96 MSIX vector support for SAS3 HBA's, - Log Temperature threshold exceeds message for any temperature sensor, - Updating the copy right information, - Provide physical location of target drives by printing Enclosure level, Enclosure address, Slot number etc, - Displaying OEM's HBA branding String, - MPI file's update, - Some driver fixes. Sreekanth Reddy (22): [SCSI] mpt2sas: MPI2 Rev AA (2.00.19) specifications [SCSI] mpt2sas, mpt3sas: Added support to log message when Temperature Threshold exceeds for any Sensor mpt2sas, mpt3sas: Fail the host reset initiated due to discovery related I/O timeouts at driver load time [SCSI] mpt2sas: Bump driver version to 19.100.00.00 [SCSI] mpt2sas: MPI2 Rev BB (2.00.20) specification and 2.00.35 header files [SCSI] mpt2sas, mpt3sas: Removing uppper boundary restriction for the module parameter max_sgl_entries [SCSI] mpt2sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081 [SCSI] mpt2sas, mpt3sas: Update Attribution Language to Avago [SCSI] mpt2sas, mpt3sas: Added a support to set cpu affinity for each MSIX vector enabled by the HBA [SCSI] mpt2sas: Bump driver version to 20.100.00.00 [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support mpt3sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state. [SCSI] mpt3sas: Added module parameter 'unblock_io' to unblock IO's during disk addition [SCSI] mpt2sas, mpt3sas: Remove redundancy code while freeing the controller resources. [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications. [SCSI] mpt3sas: Provides the physical location of sas drives [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00 [SCSI] mpt3sas: Update MPI2 strings to MPI2.5 [SCSI] mpt3sas: MPI 2.5 Rev J (2.5.5) specification and 2.00.34 header files [SCSI] mpt3sas: Add branding string support for OEM's HBA mpt3sas: Add branding string support for OEM custom HBA [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00 drivers/scsi/mpt2sas/mpi/mpi2.h | 7 +- drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h| 51 - drivers/scsi/mpt2sas/mpi/mpi2_ioc.h | 4 +- drivers/scsi/mpt2sas/mpi/mpi2_tool.h| 6 +- drivers/scsi/mpt2sas/mpt2sas_base.c | 79 +-- drivers/scsi/mpt2sas/mpt2sas_base.h | 15 +- drivers/scsi/mpt2sas/mpt2sas_config.c | 39 +++- drivers/scsi/mpt2sas/mpt2sas_ctl.c | 3 +- drivers/scsi/mpt2sas/mpt2sas_ctl.h | 3 +- drivers/scsi/mpt2sas/mpt2sas_debug.h| 3 +- drivers/scsi/mpt2sas/mpt2sas_scsih.c| 47 +++- drivers/scsi/mpt2sas/mpt2sas_transport.c| 3 +- drivers/scsi/mpt3sas/mpi/mpi2.h | 7 +- drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h| 39 +++- drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 4 +- drivers/scsi/mpt3sas/mpi/mpi2_tool.h| 4 +- drivers/scsi/mpt3sas/mpt3sas_base.c | 282 --- drivers/scsi/mpt3sas/mpt3sas_base.h | 51 - drivers/scsi/mpt3sas/mpt3sas_config.c | 39 +++- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 3 +- drivers/scsi/mpt3sas/mpt3sas_ctl.h | 3 +- drivers/scsi/mpt3sas/mpt3sas_debug.h| 3 +- drivers/scsi/mpt3sas/mpt3sas_scsih.c| 343 drivers/scsi/mpt3sas/mpt3sas_transport.c| 17 +- drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c | 3 +- drivers/scsi/mpt3sas/mpt3sas_trigger_diag.h | 3 +- 26 files changed, 913 insertions(+), 148 deletions(-) -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/22] [SCSI] mpt2sas, mpt3sas: Update Attribution Language to Avago
Copyright, Trademark & Confidentiality legal statements throughout source code changed from LSI to Avago. Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt2sas/mpt2sas_base.c | 3 ++- drivers/scsi/mpt2sas/mpt2sas_base.h | 5 +++-- drivers/scsi/mpt2sas/mpt2sas_config.c | 3 ++- drivers/scsi/mpt2sas/mpt2sas_ctl.c | 3 ++- drivers/scsi/mpt2sas/mpt2sas_ctl.h | 3 ++- drivers/scsi/mpt2sas/mpt2sas_debug.h| 3 ++- drivers/scsi/mpt2sas/mpt2sas_scsih.c| 3 ++- drivers/scsi/mpt2sas/mpt2sas_transport.c| 3 ++- drivers/scsi/mpt3sas/mpt3sas_base.c | 3 ++- drivers/scsi/mpt3sas/mpt3sas_base.h | 5 +++-- drivers/scsi/mpt3sas/mpt3sas_config.c | 3 ++- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 3 ++- drivers/scsi/mpt3sas/mpt3sas_ctl.h | 3 ++- drivers/scsi/mpt3sas/mpt3sas_debug.h| 3 ++- drivers/scsi/mpt3sas/mpt3sas_scsih.c| 3 ++- drivers/scsi/mpt3sas/mpt3sas_transport.c| 3 ++- drivers/scsi/mpt3sas/mpt3sas_trigger_diag.c | 3 ++- drivers/scsi/mpt3sas/mpt3sas_trigger_diag.h | 3 ++- 18 files changed, 38 insertions(+), 20 deletions(-) diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c index adb99e5..f10ee41 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.c +++ b/drivers/scsi/mpt2sas/mpt2sas_base.c @@ -4,7 +4,8 @@ * * This code is based on drivers/scsi/mpt2sas/mpt2_base.c * Copyright (C) 2007-2014 LSI Corporation - * (mailto:dl-mptfusionli...@lsi.com) + * Copyright (C) 20013-2014 Avago Technologies + * (mailto: mpt-fusionlinux@avagotech.com) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h b/drivers/scsi/mpt2sas/mpt2sas_base.h index 3faad45..72bffec 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.h +++ b/drivers/scsi/mpt2sas/mpt2sas_base.h @@ -4,7 +4,8 @@ * * This code is based on drivers/scsi/mpt2sas/mpt2_base.h * Copyright (C) 2007-2014 LSI Corporation - * (mailto:dl-mptfusionli...@lsi.com) + * Copyright (C) 20013-2014 Avago Technologies + * (mailto: mpt-fusionlinux@avagotech.com) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -67,7 +68,7 @@ /* driver versioning info */ #define MPT2SAS_DRIVER_NAME"mpt2sas" -#define MPT2SAS_AUTHOR "LSI Corporation " +#define MPT2SAS_AUTHOR "Avago Technologies " #define MPT2SAS_DESCRIPTION"LSI MPT Fusion SAS 2.0 Device Driver" #define MPT2SAS_DRIVER_VERSION "19.100.00.00" #define MPT2SAS_MAJOR_VERSION 19 diff --git a/drivers/scsi/mpt2sas/mpt2sas_config.c b/drivers/scsi/mpt2sas/mpt2sas_config.c index 41a8f84..c43815b 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_config.c +++ b/drivers/scsi/mpt2sas/mpt2sas_config.c @@ -3,7 +3,8 @@ * * This code is based on drivers/scsi/mpt2sas/mpt2_base.c * Copyright (C) 2007-2014 LSI Corporation - * (mailto:dl-mptfusionli...@lsi.com) + * Copyright (C) 20013-2014 Avago Technologies + * (mailto: mpt-fusionlinux@avagotech.com) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License diff --git a/drivers/scsi/mpt2sas/mpt2sas_ctl.c b/drivers/scsi/mpt2sas/mpt2sas_ctl.c index ca4e563..4e50960 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_ctl.c +++ b/drivers/scsi/mpt2sas/mpt2sas_ctl.c @@ -4,7 +4,8 @@ * * This code is based on drivers/scsi/mpt2sas/mpt2_ctl.c * Copyright (C) 2007-2014 LSI Corporation - * (mailto:dl-mptfusionli...@lsi.com) + * Copyright (C) 20013-2014 Avago Technologies + * (mailto: mpt-fusionlinux@avagotech.com) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License diff --git a/drivers/scsi/mpt2sas/mpt2sas_ctl.h b/drivers/scsi/mpt2sas/mpt2sas_ctl.h index fa0567c..5df1cbe 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_ctl.h +++ b/drivers/scsi/mpt2sas/mpt2sas_ctl.h @@ -4,7 +4,8 @@ * * This code is based on drivers/scsi/mpt2sas/mpt2_ctl.h * Copyright (C) 2007-2014 LSI Corporation - * (mailto:dl-mptfusionli...@lsi.com) + * Copyright (C) 20013-2014 Avago Technologies + * (mailto: mpt-fusionlinux@avagotech.com) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License diff --git a/drivers/scsi/mpt2sas/mpt2sas_debug.h b/drivers/scsi/mpt2sas/mpt2sas_debug.h index cc57ef3..277120d 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_debug.h +++ b/drivers/scsi/mpt2sas/mpt2sas_debug.h @@ -3,7 +3,8 @@ * * This code is based on drivers/scsi/mpt2sas/mpt2_debug.c * Copyright (C) 2007-2014 LSI Corporation - * (mailto:dl-mptfusionli...@lsi.com) + * Copyright (C) 20013-2014 Avago Technologies + * (mailto: mpt-fusionlinux@avagotech.com) * * This program is free
[PATCH 04/22] [SCSI] mpt2sas: Bump driver version to 19.100.00.00
Bump driver version to 19.100.00.00. Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt2sas/mpt2sas_base.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h b/drivers/scsi/mpt2sas/mpt2sas_base.h index 8a41a4e..3faad45 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.h +++ b/drivers/scsi/mpt2sas/mpt2sas_base.h @@ -69,8 +69,8 @@ #define MPT2SAS_DRIVER_NAME"mpt2sas" #define MPT2SAS_AUTHOR "LSI Corporation " #define MPT2SAS_DESCRIPTION"LSI MPT Fusion SAS 2.0 Device Driver" -#define MPT2SAS_DRIVER_VERSION "18.100.00.00" -#define MPT2SAS_MAJOR_VERSION 18 +#define MPT2SAS_DRIVER_VERSION "19.100.00.00" +#define MPT2SAS_MAJOR_VERSION 19 #define MPT2SAS_MINOR_VERSION 100 #define MPT2SAS_BUILD_VERSION 00 #define MPT2SAS_RELEASE_VERSION00 -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/22] [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications.
Update MPI 2.5 Release: MPI 2.5 Rev I (2.5.4) specification and 2.00.33 header
files
Below is the change set from the MPI specification for I Rev
1) Added Base Enclosure Level bit to the Flags field of Manufacturing Page 7.
2) Updated description of the MaxTargetPortConnectTime field of SAS IO Unit
Page 1.
3) Added EnclosureLevel and ConnectorName fields to SAS Device Page 0. Also,
added EnclosureLevel and ConnectorName Valid bit to the Flags field.
4) Added EnclosureLevel field to SAS Enclosure Page 0. Also, added
EnclosureLevel Valid bit to the Flags field.
5) Added value for BIOS image to HashImageType.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpi/mpi2.h | 6 --
drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 27 +--
drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 4 +++-
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index c34c115..d730c5c 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -8,7 +8,7 @@
* scatter/gather formats.
* Creation Date: June 21, 2006
*
- * mpi2.h Version: 02.00.31
+ * mpi2.h Version: 02.00.33
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -88,6 +88,8 @@
* Added MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET.
* 04-09-13 02.00.30 Bumped MPI2_HEADER_VERSION_UNIT.
* 04-17-13 02.00.31 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 08-19-13 02.00.32 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 12-05-13 02.00.33 Bumped MPI2_HEADER_VERSION_UNIT.
* --
*/
@@ -121,7 +123,7 @@
#define MPI2_VERSION_02_05 (0x0205)
/*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x1F)
+#define MPI2_HEADER_VERSION_UNIT(0x21)
#define MPI2_HEADER_VERSION_DEV (0x00)
#define MPI2_HEADER_VERSION_UNIT_MASK (0xFF00)
#define MPI2_HEADER_VERSION_UNIT_SHIFT (8)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index e261a31..62dfbf6 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -6,7 +6,7 @@
* Title: MPI Configuration messages and pages
* Creation Date: November 10, 2006
*
- * mpi2_cnfg.h Version: 02.00.26
+ * mpi2_cnfg.h Version: 02.00.27
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -165,6 +165,16 @@
* match the specification.
* 08-19-13 02.00.26 Added reserved words to MPI2_CONFIG_PAGE_IO_UNIT_7 for
* future use.
+ * 12-05-13 02.00.27 Added MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL for
+ *MPI2_CONFIG_PAGE_MAN_7.
+ *Added EnclosureLevel and ConnectorName fields to
+ *MPI2_CONFIG_PAGE_SAS_DEV_0.
+ *Added MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID for
+ *MPI2_CONFIG_PAGE_SAS_DEV_0.
+ *Added EnclosureLevel field to
+ *MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
+ *Added MPI2_SAS_ENCLS0_FLAGS_ENCL_LEVEL_VALID for
+ *MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
* --
*/
@@ -724,6 +734,7 @@ typedef struct _MPI2_CONFIG_PAGE_MAN_7 {
#define MPI2_MANUFACTURING7_PAGEVERSION (0x01)
/*defines for the Flags field */
+#define MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL (0x0008)
#define MPI2_MANPAGE7_FLAG_EVENTREPLAY_SLOT_ORDER (0x0002)
#define MPI2_MANPAGE7_FLAG_USE_SLOT_INFO(0x0001)
@@ -2633,9 +2644,9 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
U8
ControlGroup; /*0x2E */
U8
- Reserved1; /*0x2F */
+ EnclosureLevel; /*0x2F */
U32
- Reserved2; /*0x30 */
+ ConnectorName[4]; /*0x30 */
U32
Reserved3; /*0x34 */
} MPI2_CONFIG_PAGE_SAS_DEV_0,
@@ -2643,7 +2654,7 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
Mpi2SasDevicePage0_t,
*pMpi2SasDevicePage0_t;
-#define MPI2_SASDEVICE0_PAGEVERSION (0x08)
+#define MPI2_SASDEVICE0_PAGEVERSION (0x09)
/*values for SAS Device Page 0 AccessStatus field */
#define MPI2_SAS_DEVICE0_ASTATUS_NO_ERRORS (0x00)
@@ -2683,6 +2694,7 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
#define MPI2_SAS_DEVICE0_FLAGS_SATA_NCQ_SUPPORTED (0x0020)
#define MPI2_SAS_DEVICE0_FLAGS_SATA_FUA_SUPPORTED (0x0010)
#define
[PATCH 16/22] [SCSI] mpt3sas: Provides the physical location of sas drives
This Patch will provide more details of the devices such as slot number,
enclosure logical id, enclosure level & connector name in the following
scenarios,
- When end device is added in the topology,
- When the end device is removed from the setup,
- When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET during
error handling,
- When any command to the device fails with Sense key Hardware error or Medium
error or Unit Attention,
- When firmware returns device error or device not ready status for the end
device,
- When a Predicted fault is detected on an end device.
This information can be used by the user to identify the location of the
desired drive in the topology.
Driver will get these information by reading the sas device page0.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 238 +--
2 files changed, 201 insertions(+), 39 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 7dd5510..dba4d66 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -317,6 +317,8 @@ struct _sas_device {
u8 fast_path;
u8 pfa_led_on;
u8 pend_sas_rphy_add;
+ u8 enclosure_level;
+ u8 connector_name[4];
};
/**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 1ca5f98..9c77045 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -590,6 +590,22 @@ _scsih_sas_device_remove(struct MPT3SAS_ADAPTER *ioc,
if (!sas_device)
return;
+ pr_info(MPT3SAS_FMT
+ "removing handle(0x%04x), sas_addr(0x%016llx)\n",
+ ioc->name, sas_device->handle,
+ (unsigned long long) sas_device->sas_address);
+
+ if (sas_device->enclosure_handle != 0)
+ pr_info(MPT3SAS_FMT
+ "removing enclosure logical id(0x%016llx), slot(%d)\n",
+ ioc->name, (unsigned long long)
+ sas_device->enclosure_logical_id, sas_device->slot);
+
+ if (sas_device->connector_name[0] != '\0')
+ pr_info(MPT3SAS_FMT
+ "removing enclosure level(0x%04x), connector name( %s)\n",
+ ioc->name, sas_device->enclosure_level,
+ sas_device->connector_name);
spin_lock_irqsave(>sas_device_lock, flags);
list_del(_device->list);
@@ -668,6 +684,18 @@ _scsih_sas_device_add(struct MPT3SAS_ADAPTER *ioc,
ioc->name, __func__, sas_device->handle,
(unsigned long long)sas_device->sas_address));
+ if (sas_device->enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "%s: enclosure logical id(0x%016llx), slot( %d)\n",
+ ioc->name, __func__, (unsigned long long)
+ sas_device->enclosure_logical_id, sas_device->slot));
+
+ if (sas_device->connector_name[0] != '\0')
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "%s: enclosure level(0x%04x), connector name( %s)\n",
+ ioc->name, __func__,
+ sas_device->enclosure_level, sas_device->connector_name));
+
spin_lock_irqsave(>sas_device_lock, flags);
list_add_tail(_device->list, >sas_device_list);
spin_unlock_irqrestore(>sas_device_lock, flags);
@@ -709,6 +737,18 @@ _scsih_sas_device_init_add(struct MPT3SAS_ADAPTER *ioc,
__func__, sas_device->handle,
(unsigned long long)sas_device->sas_address));
+ if (sas_device->enclosure_handle != 0)
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "%s: enclosure logical id(0x%016llx), slot( %d)\n",
+ ioc->name, __func__, (unsigned long long)
+ sas_device->enclosure_logical_id, sas_device->slot));
+
+ if (sas_device->connector_name[0] != '\0')
+ dewtprintk(ioc, pr_info(MPT3SAS_FMT
+ "%s: enclosure level(0x%04x), connector name( %s)\n",
+ ioc->name, __func__, sas_device->enclosure_level,
+ sas_device->connector_name));
+
spin_lock_irqsave(>sas_device_lock, flags);
list_add_tail(_device->list, >sas_device_init_list);
_scsih_determine_boot_device(ioc, sas_device, 0);
@@ -1800,10 +1840,16 @@ _scsih_slave_configure(struct scsi_device *sdev)
"sas_addr(0x%016llx), phy(%d), device_name(0x%016llx)\n",
ds, handle, (unsigned long long)sas_device->sas_address,
sas_device->phy, (unsigned long long)sas_device->device_name);
- sdev_printk(KERN_INFO, sdev,
- "%s: enclosure_logical_id(0x%016llx), slot(%d)\n",
- ds, (unsigned long long)
- sas_device->enclosure_logical_id, sas_device->slot);
+
Re: [PATCH net V3] virtio-net: validate features during probe
On 11/20/2014 03:02 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 02:10:35PM +0800, Jason Wang wrote:
>> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
>> is not set but one of features depending on it is.
>> That's not a friendly way to report errors to
>> hypervisors.
>> Let's check, and fail probe instead.
>>
>> Cc: Rusty Russell
>> Cc: Cornelia Huck
>> Cc: Wanlong Gao
>> Signed-off-by: Michael S. Tsirkin
>> Signed-off-by: Jason Wang
>
> Looks good, minor nits below:
>
>> ---
>> Changes from V2:
>> - only check the features for ctrl vq (this fix the real bug)
>> - better error message and simplify API
>> ---
>> drivers/net/virtio_net.c | 37 +
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index ec2a8b4..a6bcfce 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1673,6 +1673,40 @@ static const struct attribute_group
>> virtio_net_mrg_rx_group = {
>> };
>> #endif
>>
>> +static bool virtnet_fail_on_feature(struct virtio_device *vdev,
>> +unsigned int fbit,
>> +const char *fname, const char *dname)
>> +{
>> +if (!virtio_has_feature(vdev, fbit))
>> +return false;
>> +
>> +dev_err(>dev, "Hypervisor bug: advertise feature %s but not %s",
> Well we don't know it's a hypervisor. How about:
> Device bug: advertises feature %s but not %s.
Ok.
>> +fname, dname);
>> +
>> +return true;
>> +}
>> +
>> +#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
>> +virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
> I would pass dbit directly, and supply a string from caller,
> instead if #dbit, this way it can be any string.
Right, this is better.
>> +
>> +static bool virtnet_validate_features(struct virtio_device *vdev)
>> +{
>> +if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
>> +(VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
>> + VIRTIO_NET_F_CTRL_VQ) ||
>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
>> + VIRTIO_NET_F_CTRL_VQ) ||
>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
>> + VIRTIO_NET_F_TRL_VQ) ||
> Typo: VIRTIO_NET_F_CTRL_VQ.
>
>
Wil fix this and post V4.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/22] [SCSI] mpt2sas, mpt3sas: Remove redundancy code while freeing the controller resources.
Removed the redundancy code while freeing the controller resources.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 49 ++-
drivers/scsi/mpt3sas/mpt3sas_base.c | 57 +
2 files changed, 61 insertions(+), 45 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 7286cd2..79626d9 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1501,6 +1501,33 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
}
/**
+ * mpt2sas_base_unmap_resources - free controller resources
+ * @ioc: per adapter object
+ */
+void
+mpt2sas_base_unmap_resources(struct MPT2SAS_ADAPTER *ioc)
+{
+ struct pci_dev *pdev = ioc->pdev;
+
+ dexitprintk(ioc, printk(MPT2SAS_FMT "%s\n",
+ ioc->name, __func__));
+
+ _base_free_irq(ioc);
+ _base_disable_msix(ioc);
+
+ if (ioc->chip_phys) {
+ iounmap(ioc->chip);
+ ioc->chip_phys = 0;
+ }
+
+ if (pci_is_enabled(pdev)) {
+ pci_release_selected_regions(ioc->pdev, ioc->bars);
+ pci_disable_pcie_error_reporting(pdev);
+ pci_disable_device(pdev);
+ }
+}
+
+/**
* mpt2sas_base_map_resources - map in controller resources (io/irq/memap)
* @ioc: per adapter object
*
@@ -1606,12 +1633,7 @@ mpt2sas_base_map_resources(struct MPT2SAS_ADAPTER *ioc)
return 0;
out_fail:
- if (ioc->chip_phys)
- iounmap(ioc->chip);
- ioc->chip_phys = 0;
- pci_release_selected_regions(ioc->pdev, ioc->bars);
- pci_disable_pcie_error_reporting(pdev);
- pci_disable_device(pdev);
+ mpt2sas_base_unmap_resources(ioc);
return r;
}
@@ -4422,8 +,6 @@ _base_make_ioc_operational(struct MPT2SAS_ADAPTER *ioc,
int sleep_flag)
void
mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
{
- struct pci_dev *pdev = ioc->pdev;
-
dexitprintk(ioc, printk(MPT2SAS_INFO_FMT "%s\n", ioc->name,
__func__));
@@ -4434,18 +4454,7 @@ mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
ioc->shost_recovery = 0;
}
- _base_free_irq(ioc);
- _base_disable_msix(ioc);
-
- if (ioc->chip_phys && ioc->chip)
- iounmap(ioc->chip);
- ioc->chip_phys = 0;
-
- if (pci_is_enabled(pdev)) {
- pci_release_selected_regions(ioc->pdev, ioc->bars);
- pci_disable_pcie_error_reporting(pdev);
- pci_disable_device(pdev);
- }
+ mpt2sas_base_unmap_resources(ioc);
return;
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 527f91b..4322d7c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1791,6 +1791,36 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
}
/**
+ * mpt3sas_base_unmap_resources - free controller resources
+ * @ioc: per adapter object
+ */
+void
+mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
+{
+ struct pci_dev *pdev = ioc->pdev;
+
+ dexitprintk(ioc, printk(MPT3SAS_FMT "%s\n",
+ ioc->name, __func__));
+
+ _base_free_irq(ioc);
+ _base_disable_msix(ioc);
+
+ if (ioc->msix96_vector)
+ kfree(ioc->replyPostRegisterIndex);
+
+ if (ioc->chip_phys) {
+ iounmap(ioc->chip);
+ ioc->chip_phys = 0;
+ }
+
+ if (pci_is_enabled(pdev)) {
+ pci_release_selected_regions(ioc->pdev, ioc->bars);
+ pci_disable_pcie_error_reporting(pdev);
+ pci_disable_device(pdev);
+ }
+}
+
+/**
* mpt3sas_base_map_resources - map in controller resources (io/irq/memap)
* @ioc: per adapter object
*
@@ -1918,14 +1948,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
return 0;
out_fail:
- if (ioc->chip_phys)
- iounmap(ioc->chip);
- ioc->chip_phys = 0;
- pci_release_selected_regions(ioc->pdev, ioc->bars);
- pci_disable_pcie_error_reporting(pdev);
- pci_disable_device(pdev);
- if (ioc->msix96_vector)
- kfree(ioc->replyPostRegisterIndex);
+ mpt3sas_base_unmap_resources(ioc);
return r;
}
@@ -4657,8 +4680,6 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
void
mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc)
{
- struct pci_dev *pdev = ioc->pdev;
-
dexitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
__func__));
@@ -4669,21 +4690,7 @@ mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc)
ioc->shost_recovery = 0;
}
- _base_free_irq(ioc);
- _base_disable_msix(ioc);
-
- if (ioc->msix96_vector)
- kfree(ioc->replyPostRegisterIndex);
-
- if (ioc->chip_phys && ioc->chip)
-
[PATCH 12/22] mpt3sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state.
Driver initialization fails if driver tries to send IOC facts request message
when the IOC is in reset or in a fault state.
This patch will make sure that
1.Driver to send IOC facts request message only if HBA is in operational or
ready state.
2.If IOC is in fault state, a diagnostic reset would be issued.
3.If IOC is in reset state then driver will wait for 10 seconds to exit out of
reset state.
If the HBA continues to be in reset state, then the HBA wouldn't be claimed
by the driver.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 958a870..527f91b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3159,6 +3159,9 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32
ioc_state, int timeout,
* Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to doorbell.
*/
static int
+_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+
+static int
_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
int sleep_flag)
{
@@ -3701,6 +3704,61 @@ _base_get_port_facts(struct MPT3SAS_ADAPTER *ioc, int
port, int sleep_flag)
}
/**
+ * _base_wait_for_iocstate - Wait until the card is in READY or OPERATIONAL
+ * @ioc: per adapter object
+ * @timeout:
+ * @sleep_flag: CAN_SLEEP or NO_SLEEP
+ *
+ * Returns 0 for success, non-zero for failure.
+ */
+static int
+_base_wait_for_iocstate(struct MPT3SAS_ADAPTER *ioc, int timeout,
+ int sleep_flag)
+{
+ u32 ioc_state;
+ int rc;
+
+ dinitprintk(ioc, printk(MPT3SAS_FMT "%s\n", ioc->name,
+ __func__));
+
+ if (ioc->pci_error_recovery)
+ return 0;
+
+ ioc_state = mpt3sas_base_get_iocstate(ioc, 0);
+ dhsprintk(ioc, printk(MPT3SAS_FMT "%s: ioc_state(0x%08x)\n",
+ ioc->name, __func__, ioc_state));
+
+ if (((ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_READY) ||
+ (ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_OPERATIONAL)
+ return 0;
+
+ if (ioc_state & MPI2_DOORBELL_USED) {
+ dhsprintk(ioc, printk(MPT3SAS_FMT
+ "unexpected doorbell active!\n", ioc->name));
+ goto issue_diag_reset;
+ }
+
+ if ((ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_FAULT) {
+ mpt3sas_base_fault_info(ioc, ioc_state &
+ MPI2_DOORBELL_DATA_MASK);
+ goto issue_diag_reset;
+ }
+
+ ioc_state = _base_wait_on_iocstate(ioc, MPI2_IOC_STATE_READY,
+ timeout, sleep_flag);
+ if (ioc_state) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "%s: failed going to ready state (ioc_state=0x%x)\n",
+ ioc->name, __func__, ioc_state));
+ return -EFAULT;
+ }
+
+ issue_diag_reset:
+ rc = _base_diag_reset(ioc, sleep_flag);
+ return rc;
+}
+
+/**
* _base_get_ioc_facts - obtain ioc facts reply and save in ioc
* @ioc: per adapter object
* @sleep_flag: CAN_SLEEP or NO_SLEEP
@@ -3718,6 +3776,13 @@ _base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int
sleep_flag)
dinitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
__func__));
+ r = _base_wait_for_iocstate(ioc, 10, sleep_flag);
+ if (r) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "%s: failed getting to correct state\n",
+ ioc->name, __func__));
+ return r;
+ }
mpi_reply_sz = sizeof(Mpi2IOCFactsReply_t);
mpi_request_sz = sizeof(Mpi2IOCFactsRequest_t);
memset(_request, 0, mpi_request_sz);
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/22] [SCSI] mpt2sas: MPI2 Rev BB (2.00.20) specification and 2.00.35 header files
Change List in this MPI2 specification, 1. Added SSUTimeout field to MPI2_CONFIG_PAGE_BIOS_1, and more defines for the BiosOptions field. Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt2sas/mpi/mpi2.h | 5 +++-- drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h | 17 ++--- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/mpt2sas/mpi/mpi2.h b/drivers/scsi/mpt2sas/mpi/mpi2.h index 76cde3f..7fc6f23 100644 --- a/drivers/scsi/mpt2sas/mpi/mpi2.h +++ b/drivers/scsi/mpt2sas/mpi/mpi2.h @@ -8,7 +8,7 @@ * scatter/gather formats. * Creation Date: June 21, 2006 * - * mpi2.h Version: 02.00.34 + * mpi2.h Version: 02.00.35 * * Version History * --- @@ -85,6 +85,7 @@ * 08-19-13 02.00.32 Bumped MPI2_HEADER_VERSION_UNIT. * 12-05-13 02.00.33 Bumped MPI2_HEADER_VERSION_UNIT. * 01-08-14 02.00.34 Bumped MPI2_HEADER_VERSION_UNIT. + * 06-13-14 02.00.35 Bumped MPI2_HEADER_VERSION_UNIT. * -- */ @@ -110,7 +111,7 @@ #define MPI2_VERSION_02_00 (0x0200) /* versioning for this MPI header set */ -#define MPI2_HEADER_VERSION_UNIT(0x20) +#define MPI2_HEADER_VERSION_UNIT(0x23) #define MPI2_HEADER_VERSION_DEV (0x00) #define MPI2_HEADER_VERSION_UNIT_MASK (0xFF00) #define MPI2_HEADER_VERSION_UNIT_SHIFT (8) diff --git a/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h b/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h index f055310..d3e4319 100644 --- a/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h +++ b/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h @@ -6,7 +6,7 @@ * Title: MPI Configuration messages and pages * Creation Date: November 10, 2006 * - *mpi2_cnfg.h Version: 02.00.28 + *mpi2_cnfg.h Version: 02.00.29 * * Version History * --- @@ -169,6 +169,8 @@ * MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0. * 01-08-14 02.00.28 Added more defines for the BiosOptions field of * MPI2_CONFIG_PAGE_BIOS_1. + * 06-13-14 02.00.29 Added SSUTimeout field to MPI2_CONFIG_PAGE_BIOS_1, and + * more defines for the BiosOptions field. * -- */ @@ -1237,7 +1239,9 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 MPI2_CONFIG_PAGE_HEADER Header; /* 0x00 */ U32 BiosOptions;/* 0x04 */ U32 IOCSettings;/* 0x08 */ - U32 Reserved1; /* 0x0C */ + U8 SSUTimeout; /* 0x0C */ + U8 Reserved1; /* 0x0D */ + U16 Reserved2; /* 0x0E */ U32 DeviceSettings; /* 0x10 */ U16 NumberOfDevices;/* 0x14 */ U16 UEFIVersion;/* 0x16 */ @@ -1248,9 +1252,16 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 } MPI2_CONFIG_PAGE_BIOS_1, MPI2_POINTER PTR_MPI2_CONFIG_PAGE_BIOS_1, Mpi2BiosPage1_t, MPI2_POINTER pMpi2BiosPage1_t; -#define MPI2_BIOSPAGE1_PAGEVERSION (0x06) +#define MPI2_BIOSPAGE1_PAGEVERSION (0x07) /* values for BIOS Page 1 BiosOptions field */ +#define MPI2_BIOSPAGE1_OPTIONS_PNS_MASK(0x3800) +#define MPI2_BIOSPAGE1_OPTIONS_PNS_PBDHL (0x) +#define MPI2_BIOSPAGE1_OPTIONS_PNS_ENCSLOSURE (0x0800) +#define MPI2_BIOSPAGE1_OPTIONS_PNS_LWWID (0x1000) +#define MPI2_BIOSPAGE1_OPTIONS_PNS_PSENS (0x1800) +#define MPI2_BIOSPAGE1_OPTIONS_PNS_ESPHY (0x2000) + #define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS (0x0400) #define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD (0x0300) -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/22] [SCSI] mpt2sas, mpt3sas: Removing uppper boundary restriction for the module parameter max_sgl_entries
1. Removed the upper boundary restriction for the module parameter
max_sgl_entries. Earlier, the max_sgl_entries was capped at the
SCSI_MAX_SG_SEGMENTS kernel definition. With this change, the user would be
able to set the max_sgl_entries to any value.
2. Added a print for the message log whenever the user sets the max_sgl_entries
to a value greater than SCSI_MAX_SG_SEGMENTS to warn about the kernel
definition overriding.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 9 ++---
drivers/scsi/mpt3sas/mpt3sas_base.c | 5 -
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 13d1d5b..adb99e5 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -2492,9 +2492,12 @@ _base_allocate_memory_pools(struct MPT2SAS_ADAPTER *ioc,
int sleep_flag)
/* command line tunables for max sgl entries */
if (max_sgl_entries != -1) {
- ioc->shost->sg_tablesize = (max_sgl_entries <
- MPT2SAS_SG_DEPTH) ? max_sgl_entries :
- MPT2SAS_SG_DEPTH;
+ if (max_sgl_entries > MPT2SAS_SG_DEPTH)
+ printk(MPT2SAS_WARN_FMT
+"setting max_sgl_entries(%d), overriding kernel"
+" defined SCSI_MAX_SG_SEGMENTS(%d)\n", ioc->name,
+ max_sgl_entries, MPT2SAS_SG_DEPTH);
+ ioc->shost->sg_tablesize = max_sgl_entries;
} else {
ioc->shost->sg_tablesize = MPT2SAS_SG_DEPTH;
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index f1918cf..35d4780 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2667,7 +2667,10 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc,
int sleep_flag)
if (sg_tablesize < MPT3SAS_MIN_PHYS_SEGMENTS)
sg_tablesize = MPT3SAS_MIN_PHYS_SEGMENTS;
else if (sg_tablesize > MPT3SAS_MAX_PHYS_SEGMENTS)
- sg_tablesize = MPT3SAS_MAX_PHYS_SEGMENTS;
+ pr_warn(MPT3SAS_FMT
+"setting max_sgl_entries(%d), overriding kernel"
+" defined SCSI_MAX_SG_SEGMENTS(%d)\n", ioc->name,
+max_sgl_entries, MPT3SAS_MAX_PHYS_SEGMENTS);
ioc->shost->sg_tablesize = sg_tablesize;
ioc->hi_priority_depth = facts->HighPriorityCredit;
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/22] [SCSI] mpt2sas: Bump driver version to 20.100.00.00
Bump mpt2sas driver version to 20.100.00.00. Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt2sas/mpt2sas_base.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h b/drivers/scsi/mpt2sas/mpt2sas_base.h index 72bffec..ed14084 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.h +++ b/drivers/scsi/mpt2sas/mpt2sas_base.h @@ -70,8 +70,8 @@ #define MPT2SAS_DRIVER_NAME"mpt2sas" #define MPT2SAS_AUTHOR "Avago Technologies " #define MPT2SAS_DESCRIPTION"LSI MPT Fusion SAS 2.0 Device Driver" -#define MPT2SAS_DRIVER_VERSION "19.100.00.00" -#define MPT2SAS_MAJOR_VERSION 19 +#define MPT2SAS_DRIVER_VERSION "20.100.00.00" +#define MPT2SAS_MAJOR_VERSION 20 #define MPT2SAS_MINOR_VERSION 100 #define MPT2SAS_BUILD_VERSION 00 #define MPT2SAS_RELEASE_VERSION00 -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 21/22] mpt3sas: Add branding string support for OEM custom HBA
Add the following OEM's branding to the mpt3sas driver.
"VendorID" "DeviceID" "SubsystemVendor ID" "SubsystemDevice ID" Cisco
Branding String
0x1000 0x97 SVID = 0x1137 0x014C Cisco
9300-8E 12G SAS HBA
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 34 ++
drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index cc1bfef..088c138 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2371,6 +2371,39 @@ _base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
}
}
+/**
+ * _base_display_cisco_branding - Display branding string
+ * @ioc: per adapter object
+ *
+ * Return nothing.
+ */
+static void
+_base_display_cisco_branding(struct MPT3SAS_ADAPTER *ioc)
+{
+ if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_CISCO)
+ return;
+
+ switch (ioc->pdev->device) {
+ case MPI25_MFGPAGE_DEVID_SAS3008:
+ switch (ioc->pdev->subsystem_device) {
+ case MPT3SAS_CISCO_12G_HBA_SSDID:
+ pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+ MPT3SAS_CISCO_12G_HBA_BRANDING);
+ break;
+ default:
+ pr_info(MPT3SAS_FMT
+ "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
+ ioc->name, ioc->pdev->subsystem_device);
+ break;
+ }
+ break;
+ default:
+pr_info(MPT3SAS_FMT
+ "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
+ ioc->name, ioc->pdev->subsystem_device);
+ break;
+ }
+}
/**
* _base_display_ioc_capabilities - Disply IOC's capabilities.
@@ -2403,6 +2436,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER
*ioc)
_base_display_intel_branding(ioc);
_base_display_dell_branding(ioc);
+ _base_display_cisco_branding(ioc);
pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index f2ce5a5..9608e3a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -163,6 +163,17 @@
#define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
/*
+ * Cisco HBA branding
+ */
+#define MPT3SAS_CISCO_12G_HBA_BRANDING \
+ "Cisco 9300-8E 12G SAS HBA"
+
+/*
+ * Cisco HBA SSSDIDs
+ */
+ #define MPT3SAS_CISCO_12G_HBA_SSDID 0x14C
+
+/*
* status bits for ioc->diag_buffer_status
*/
#define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/22] [SCSI] mpt3sas: MPI 2.5 Rev J (2.5.5) specification and 2.00.34 header files
Following is the change set,
1. Added more defines for the BiosOptions field of MPI2_CONFIG_PAGE_BIOS_1.
2. Added MPI2_TOOLBOX_CLEAN_BIT26_PRODUCT_SPECIFIC definition.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpi/mpi2.h | 5 +++--
drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 14 --
drivers/scsi/mpt3sas/mpi/mpi2_tool.h | 4 +++-
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index d730c5c..c2d127c 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -8,7 +8,7 @@
* scatter/gather formats.
* Creation Date: June 21, 2006
*
- * mpi2.h Version: 02.00.33
+ * mpi2.h Version: 02.00.34
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -90,6 +90,7 @@
* 04-17-13 02.00.31 Bumped MPI2_HEADER_VERSION_UNIT.
* 08-19-13 02.00.32 Bumped MPI2_HEADER_VERSION_UNIT.
* 12-05-13 02.00.33 Bumped MPI2_HEADER_VERSION_UNIT.
+ * 01-08-14 02.00.34 Bumped MPI2_HEADER_VERSION_UNIT
* --
*/
@@ -123,7 +124,7 @@
#define MPI2_VERSION_02_05 (0x0205)
/*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x21)
+#define MPI2_HEADER_VERSION_UNIT(0x22)
#define MPI2_HEADER_VERSION_DEV (0x00)
#define MPI2_HEADER_VERSION_UNIT_MASK (0xFF00)
#define MPI2_HEADER_VERSION_UNIT_SHIFT (8)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index 62dfbf6..66f2cc1 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -6,7 +6,7 @@
* Title: MPI Configuration messages and pages
* Creation Date: November 10, 2006
*
- * mpi2_cnfg.h Version: 02.00.27
+ * mpi2_cnfg.h Version: 02.00.28
*
* NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
* prefix are for use only on MPI v2.5 products, and must not be used
@@ -175,6 +175,8 @@
*MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
*Added MPI2_SAS_ENCLS0_FLAGS_ENCL_LEVEL_VALID for
*MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
+ * 01-08-14 02.00.28 Added more defines for the BiosOptions field of
+ *MPI2_CONFIG_PAGE_BIOS_1.
* --
*/
@@ -1334,9 +1336,17 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
*PTR_MPI2_CONFIG_PAGE_BIOS_1,
Mpi2BiosPage1_t, *pMpi2BiosPage1_t;
-#define MPI2_BIOSPAGE1_PAGEVERSION (0x05)
+#define MPI2_BIOSPAGE1_PAGEVERSION (0x06)
/*values for BIOS Page 1 BiosOptions field */
+#define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS(0x0400)
+
+#define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD (0x0300)
+#define MPI2_BIOSPAGE1_OPTIONS_USE_BIT0_REGISTRATION_UEFI_BSD (0x)
+#define MPI2_BIOSPAGE1_OPTIONS_FULL_REGISTRATION_UEFI_BSD (0x0100)
+#define MPI2_BIOSPAGE1_OPTIONS_ADAPTER_REGISTRATION_UEFI_BSD (0x0200)
+#define MPI2_BIOSPAGE1_OPTIONS_DISABLE_REGISTRATION_UEFI_BSD (0x0300)
+
#define MPI2_BIOSPAGE1_OPTIONS_MASK_OEM_ID (0x00F0)
#define MPI2_BIOSPAGE1_OPTIONS_LSI_OEM_ID (0x)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
b/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
index 904910d..1629e5b 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_tool.h
@@ -6,7 +6,7 @@
* Title: MPI diagnostic tool structures and definitions
* Creation Date: March 26, 2007
*
- * mpi2_tool.h Version: 02.00.11
+ * mpi2_tool.h Version: 02.00.12
*
* Version History
* ---
@@ -33,6 +33,7 @@
* 07-26-12 02.00.10 Modified MPI2_TOOLBOX_DIAGNOSTIC_CLI_REQUEST so that
* it uses MPI Chain SGE as well as MPI Simple SGE.
* 08-19-13 02.00.11 Added MPI2_TOOLBOX_TEXT_DISPLAY_TOOL and related info.
+ * 01-08-14 02.00.12 Added MPI2_TOOLBOX_CLEAN_BIT26_PRODUCT_SPECIFIC.
* --
*/
@@ -100,6 +101,7 @@ typedef struct _MPI2_TOOLBOX_CLEAN_REQUEST {
#define MPI2_TOOLBOX_CLEAN_OTHER_PERSIST_PAGES (0x2000)
#define MPI2_TOOLBOX_CLEAN_FW_CURRENT (0x1000)
#define MPI2_TOOLBOX_CLEAN_FW_BACKUP(0x0800)
+#define MPI2_TOOLBOX_CLEAN_BIT26_PRODUCT_SPECIFIC (0x0400)
#define MPI2_TOOLBOX_CLEAN_MEGARAID (0x0200)
#define MPI2_TOOLBOX_CLEAN_INITIALIZATION (0x0100)
#define MPI2_TOOLBOX_CLEAN_FLASH(0x0004)
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe
Re: crypto: user - Allow get request with empty driver name
On Thu, Nov 20, 2014 at 12:46:50PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 05:23:23AM +0100, Stephan Mueller wrote:
> >
> > Here is the code:
> >
> > static int crypto_report(struct sk_buff *in_skb, struct nlmsghdr *in_nlh,
> > struct nlattr **attrs)
> > {
> > ...
> > if (!p->cru_driver_name[0])
> > return -EINVAL;
>
> OK let's fix this.
>
> crypto: user - Allow get request with empty driver name
>
> Currently all get requests with an empty driver name fail with
> EINVAL. Since most users actually want to supply an empty driver
> name this patch removes this check.
>
> Signed-off-by: Herbert Xu
>
> diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
> index e2a34fe..0bb30ac 100644
> --- a/crypto/crypto_user.c
> +++ b/crypto/crypto_user.c
> @@ -201,10 +201,7 @@ static int crypto_report(struct sk_buff *in_skb, struct
> nlmsghdr *in_nlh,
> if (!null_terminated(p->cru_name) ||
> !null_terminated(p->cru_driver_name))
> return -EINVAL;
>
> - if (!p->cru_driver_name[0])
> - return -EINVAL;
> -
> - alg = crypto_alg_match(p, 1);
> + alg = crypto_alg_match(p, 0);
I think this is not sufficient, crypto_alg_match() will now return the first
algorithm in crypto_alg_list that matches cra_name. We would need to extend
crypto_alg_match() to return the algorithm with the highest priority in that
case.
--
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 02/22] [SCSI] mpt2sas, mpt3sas: Added support to log message when Temperature Threshold exceeds for any Sensor
This patch will log a message when driver receives "Temperature Threshold
exceeded" event from any temperature sensor.
The message will look similar to like
mpt3sas0: Temperature Threshold flags a b c d exceeded for Sensor: x !!!
mpt3sas0: Current Temp In Celsius: y
where a b c d are threshold flags 0 1 2 3
Change_set:
1. Get the number of sensor count of this IOC by reading IO Unit page 8 at
driver initialization time.
2. Also unmask the Temperature Threshold Event at driver initialization time,
3. Whenever a MPI2_EVENT_TEMP_THRESHOLD event is received from the firmware
then print the sensor number, the maximum threshold number it has exceed and
the current temperature of this sensor.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 7 +++
drivers/scsi/mpt2sas/mpt2sas_base.h | 6 ++
drivers/scsi/mpt2sas/mpt2sas_config.c | 36 +++
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 31 ++
drivers/scsi/mpt3sas/mpt3sas_base.c | 8
drivers/scsi/mpt3sas/mpt3sas_base.h | 6 ++
drivers/scsi/mpt3sas/mpt3sas_config.c | 36 +++
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 31 ++
8 files changed, 161 insertions(+)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 58e4521..13d1d5b 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -639,6 +639,9 @@ _base_display_event_data(struct MPT2SAS_ADAPTER *ioc,
if (!ioc->hide_ir_msg)
desc = "Log Entry Added";
break;
+ case MPI2_EVENT_TEMP_THRESHOLD:
+ desc = "Temperature Threshold";
+ break;
}
if (!desc)
@@ -2338,6 +2341,7 @@ _base_static_config_pages(struct MPT2SAS_ADAPTER *ioc)
mpt2sas_config_get_ioc_pg8(ioc, _reply, >ioc_pg8);
mpt2sas_config_get_iounit_pg0(ioc, _reply, >iounit_pg0);
mpt2sas_config_get_iounit_pg1(ioc, _reply, >iounit_pg1);
+ mpt2sas_config_get_iounit_pg8(ioc, _reply, >iounit_pg8);
_base_display_ioc_capabilities(ioc);
/*
@@ -2355,6 +2359,8 @@ _base_static_config_pages(struct MPT2SAS_ADAPTER *ioc)
ioc->iounit_pg1.Flags = cpu_to_le32(iounit_pg1_flags);
mpt2sas_config_set_iounit_pg1(ioc, _reply, >iounit_pg1);
+ if (ioc->iounit_pg8.NumSensors)
+ ioc->temp_sensors_count = ioc->iounit_pg8.NumSensors;
}
/**
@@ -4594,6 +4600,7 @@ mpt2sas_base_attach(struct MPT2SAS_ADAPTER *ioc)
_base_unmask_events(ioc, MPI2_EVENT_IR_PHYSICAL_DISK);
_base_unmask_events(ioc, MPI2_EVENT_IR_OPERATION_STATUS);
_base_unmask_events(ioc, MPI2_EVENT_LOG_ENTRY_ADDED);
+ _base_unmask_events(ioc, MPI2_EVENT_TEMP_THRESHOLD);
r = _base_make_ioc_operational(ioc, CAN_SLEEP);
if (r)
goto out_free_resources;
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h
b/drivers/scsi/mpt2sas/mpt2sas_base.h
index 239f169..8a41a4e 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.h
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.h
@@ -725,6 +725,7 @@ typedef void (*MPT2SAS_FLUSH_RUNNING_CMDS)(struct
MPT2SAS_ADAPTER *ioc);
* @ioc_pg8: static ioc page 8
* @iounit_pg0: static iounit page 0
* @iounit_pg1: static iounit page 1
+ * @iounit_pg8: static iounit page 8
* @sas_hba: sas host object
* @sas_expander_list: expander object list
* @sas_node_lock:
@@ -795,6 +796,7 @@ typedef void (*MPT2SAS_FLUSH_RUNNING_CMDS)(struct
MPT2SAS_ADAPTER *ioc);
* @reply_post_host_index: head index in the pool where FW completes IO
* @delayed_tr_list: target reset link list
* @delayed_tr_volume_list: volume target reset link list
+ * @@temp_sensors_count: flag to carry the number of temperature sensors
*/
struct MPT2SAS_ADAPTER {
struct list_head list;
@@ -892,6 +894,7 @@ struct MPT2SAS_ADAPTER {
Mpi2IOCPage8_t ioc_pg8;
Mpi2IOUnitPage0_t iounit_pg0;
Mpi2IOUnitPage1_t iounit_pg1;
+ Mpi2IOUnitPage8_t iounit_pg8;
struct _boot_device req_boot_device;
struct _boot_device req_alt_boot_device;
@@ -992,6 +995,7 @@ struct MPT2SAS_ADAPTER {
struct list_head delayed_tr_list;
struct list_head delayed_tr_volume_list;
+ u8 temp_sensors_count;
/* diag buffer support */
u8 *diag_buffer[MPI2_DIAG_BUF_TYPE_COUNT];
@@ -1120,6 +1124,8 @@ int mpt2sas_config_get_iounit_pg1(struct MPT2SAS_ADAPTER
*ioc, Mpi2ConfigReply_t
*mpi_reply, Mpi2IOUnitPage1_t *config_page);
int mpt2sas_config_set_iounit_pg1(struct MPT2SAS_ADAPTER *ioc,
Mpi2ConfigReply_t
*mpi_reply, Mpi2IOUnitPage1_t *config_page);
+int mpt2sas_config_get_iounit_pg8(struct MPT2SAS_ADAPTER *ioc,
+ Mpi2ConfigReply_t *mpi_reply, Mpi2IOUnitPage8_t *config_page);
int mpt2sas_config_get_iounit_pg3(struct MPT2SAS_ADAPTER *ioc,
Mpi2ConfigReply_t
[PATCH 01/22] [SCSI] mpt2sas: MPI2 Rev AA (2.00.19) specifications
Below is the changeset from the MPI specification and 2.00.34 header files 1) Defined additional bits in the BiosOptions field of BIOS Page 1 to allow for finer control of X86 BIOS and UEFI BSD. 2) For the Clean Tool, reserved bit 26 of the Flags field for product specific use. Signed-off-by: Sreekanth Reddy --- drivers/scsi/mpt2sas/mpi/mpi2.h | 4 +++- drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h | 38 +--- drivers/scsi/mpt2sas/mpi/mpi2_ioc.h | 4 +++- drivers/scsi/mpt2sas/mpi/mpi2_tool.h | 6 -- 4 files changed, 41 insertions(+), 11 deletions(-) diff --git a/drivers/scsi/mpt2sas/mpi/mpi2.h b/drivers/scsi/mpt2sas/mpi/mpi2.h index 088eefa..76cde3f 100644 --- a/drivers/scsi/mpt2sas/mpi/mpi2.h +++ b/drivers/scsi/mpt2sas/mpi/mpi2.h @@ -8,7 +8,7 @@ * scatter/gather formats. * Creation Date: June 21, 2006 * - * mpi2.h Version: 02.00.32 + * mpi2.h Version: 02.00.34 * * Version History * --- @@ -83,6 +83,8 @@ * 04-09-13 02.00.30 Bumped MPI2_HEADER_VERSION_UNIT. * 04-17-13 02.00.31 Bumped MPI2_HEADER_VERSION_UNIT. * 08-19-13 02.00.32 Bumped MPI2_HEADER_VERSION_UNIT. + * 12-05-13 02.00.33 Bumped MPI2_HEADER_VERSION_UNIT. + * 01-08-14 02.00.34 Bumped MPI2_HEADER_VERSION_UNIT. * -- */ diff --git a/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h b/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h index 510ef0d..f055310 100644 --- a/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h +++ b/drivers/scsi/mpt2sas/mpi/mpi2_cnfg.h @@ -6,7 +6,7 @@ * Title: MPI Configuration messages and pages * Creation Date: November 10, 2006 * - *mpi2_cnfg.h Version: 02.00.26 + *mpi2_cnfg.h Version: 02.00.28 * * Version History * --- @@ -157,6 +157,18 @@ * 04-09-13 02.00.25 Added MPI2_IOUNITPAGE1_ATA_SECURITY_FREEZE_LOCK. * Fixed MPI2_IOUNITPAGE5_DMA_CAP_MASK_MAX_REQUESTS to * match the specification. + * 12-05-13 02.00.27 Added MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL for + * MPI2_CONFIG_PAGE_MAN_7. + * Added EnclosureLevel and ConnectorName fields to + * MPI2_CONFIG_PAGE_SAS_DEV_0. + * Added MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID for + * MPI2_CONFIG_PAGE_SAS_DEV_0. + * Added EnclosureLevel field to + * MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0. + * Added MPI2_SAS_ENCLS0_FLAGS_ENCL_LEVEL_VALID for + * MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0. + * 01-08-14 02.00.28 Added more defines for the BiosOptions field of + * MPI2_CONFIG_PAGE_BIOS_1. * -- */ @@ -706,6 +718,7 @@ typedef struct _MPI2_CONFIG_PAGE_MAN_7 #define MPI2_MANUFACTURING7_PAGEVERSION (0x01) /* defines for the Flags field */ +#define MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL (0x0008) #define MPI2_MANPAGE7_FLAG_EVENTREPLAY_SLOT_ORDER (0x0002) #define MPI2_MANPAGE7_FLAG_USE_SLOT_INFO(0x0001) @@ -1235,9 +1248,17 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 } MPI2_CONFIG_PAGE_BIOS_1, MPI2_POINTER PTR_MPI2_CONFIG_PAGE_BIOS_1, Mpi2BiosPage1_t, MPI2_POINTER pMpi2BiosPage1_t; -#define MPI2_BIOSPAGE1_PAGEVERSION (0x05) +#define MPI2_BIOSPAGE1_PAGEVERSION (0x06) /* values for BIOS Page 1 BiosOptions field */ +#define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS (0x0400) + +#define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD (0x0300) +#define MPI2_BIOSPAGE1_OPTIONS_USE_BIT0_REGISTRATION_UEFI_BSD (0x) +#define MPI2_BIOSPAGE1_OPTIONS_FULL_REGISTRATION_UEFI_BSD (0x0100) +#define MPI2_BIOSPAGE1_OPTIONS_ADAPTER_REGISTRATION_UEFI_BSD(0x0200) +#define MPI2_BIOSPAGE1_OPTIONS_DISABLE_REGISTRATION_UEFI_BSD(0x0300) + #define MPI2_BIOSPAGE1_OPTIONS_MASK_OEM_ID (0x00F0) #define MPI2_BIOSPAGE1_OPTIONS_LSI_OEM_ID (0x) @@ -2420,13 +2441,13 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 U8 PortGroups; /* 0x2C */ U8 DmaGroup; /* 0x2D */ U8 ControlGroup; /* 0x2E */ -U8 Reserved1; /* 0x2F */ -U32 Reserved2; /* 0x30 */ + U8 EnclosureLevel; /* 0x2F */ + U8 ConnectorName[4]; /* 0x30 */ U32 Reserved3; /* 0x34 */ } MPI2_CONFIG_PAGE_SAS_DEV_0, MPI2_POINTER PTR_MPI2_CONFIG_PAGE_SAS_DEV_0,
[PATCH 09/22] [SCSI] mpt2sas, mpt3sas: Added a support to set cpu affinity for each MSIX vector enabled by the HBA
Added a support to set cpu affinity mask for each MSIX vector enabled by the
HBA,
So that by runnig the irqbalancer, interrupts can be balanced among the cpus.
Change_set:
1. Call the API irq_set_affinity_hint for each MSIX vector to affiniate it with
avalibale online cpus at driver inilization time.
2. At the driver unload time, call this same API to release the cpu affinity
mask for each MSIx vector by providing the NULL value in cpumask argument.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 11 +++
drivers/scsi/mpt3sas/mpt3sas_base.c | 11 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index f10ee41..7286cd2 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1301,6 +1301,7 @@ _base_free_irq(struct MPT2SAS_ADAPTER *ioc)
list_for_each_entry_safe(reply_q, next, >reply_queue_list, list) {
list_del(_q->list);
synchronize_irq(reply_q->vector);
+ irq_set_affinity_hint(reply_q->vector, NULL);
free_irq(reply_q->vector, reply_q);
kfree(reply_q);
}
@@ -1419,6 +1420,7 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
int r;
int i;
u8 try_msix = 0;
+ int cpu;
if (msix_disable == -1 || msix_disable == 0)
try_msix = 1;
@@ -1467,6 +1469,7 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
}
ioc->msix_enable = 1;
+ cpu = cpumask_first(cpu_online_mask);
for (i = 0, a = entries; i < ioc->reply_queue_count; i++, a++) {
r = _base_request_irq(ioc, i, a->vector);
if (r) {
@@ -1475,6 +1478,14 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
kfree(entries);
goto try_ioapic;
}
+ dinitprintk(ioc, printk(MPT2SAS_INFO_FMT
+ "cpu %d affinity hint for vector %d\n",
+ioc->name, cpu, a->vector));
+ if (irq_set_affinity_hint(a->vector, get_cpu_mask(cpu)))
+ dinitprintk(ioc, printk(MPT2SAS_INFO_FMT
+ "error setting affinity hint for cpu %d\n",
+ ioc->name, cpu));
+ cpu = cpumask_next(cpu, cpu_online_mask);
}
kfree(entries);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index ce18ad2..d9f1943 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1585,6 +1585,7 @@ _base_free_irq(struct MPT3SAS_ADAPTER *ioc)
list_for_each_entry_safe(reply_q, next, >reply_queue_list, list) {
list_del(_q->list);
synchronize_irq(reply_q->vector);
+ irq_set_affinity_hint(reply_q->vector, NULL);
free_irq(reply_q->vector, reply_q);
kfree(reply_q);
}
@@ -1703,6 +1704,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
int r;
int i;
u8 try_msix = 0;
+ int cpu;
if (msix_disable == -1 || msix_disable == 0)
try_msix = 1;
@@ -1752,6 +1754,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
}
ioc->msix_enable = 1;
+ cpu = cpumask_first(cpu_online_mask);
for (i = 0, a = entries; i < ioc->reply_queue_count; i++, a++) {
r = _base_request_irq(ioc, i, a->vector);
if (r) {
@@ -1760,6 +1763,14 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
kfree(entries);
goto try_ioapic;
}
+ dinitprintk(ioc, pr_info(MPT3SAS_FMT
+ "cpu %d affinity hint for vector %d\n",
+ioc->name, cpu, a->vector));
+ if (irq_set_affinity_hint(a->vector, get_cpu_mask(cpu)))
+ dinitprintk(ioc, pr_info(MPT3SAS_FMT
+"error setting affinity hint for cpu %d\n",
+ioc->name, cpu));
+ cpu = cpumask_next(cpu, cpu_online_mask);
}
kfree(entries);
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/22] [PATCH] mpt2sas, mpt3sas: Fail the host reset initiated due to discovery related I/O timeouts at driver load time
When a flaky disk is there in a topology then during driver load,
discovery related I/O times out; which results in SCSI error recovery
initiating host reset and then the controller won't see any disk.
In this patch, The driver would return FAILED status to the host reset
initiated due to discovery related I/O timeout if ioc->is_driver_loading
is set. This flag would be set until we exit out of scsih_scan_finished().
i.e.
During device discovery if one of the disk is flaky
(which responds to some discovery commands and doesn't respond to some)
the driver wouldn't perform host reset for discovery related I/O timeout.
Instead it would return Failure for the host reset resulting in the
flaky disk getting removed by the SCSI Mid layer,
so other disks would be added correctly.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 9 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 8
2 files changed, 17 insertions(+)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index bca0cc9..38acb91 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -2760,9 +2760,18 @@ _scsih_host_reset(struct scsi_cmnd *scmd)
ioc->name, scmd);
scsi_print_command(scmd);
+ if (ioc->is_driver_loading) {
+ printk(MPT2SAS_INFO_FMT "Blocking the host reset\n",
+ ioc->name);
+ r = FAILED;
+ goto out;
+ }
+
retval = mpt2sas_base_hard_reset_handler(ioc, CAN_SLEEP,
FORCE_BIG_HAMMER);
r = (retval < 0) ? FAILED : SUCCESS;
+
+ out:
printk(MPT2SAS_INFO_FMT "host reset: %s scmd(%p)\n",
ioc->name, ((r == SUCCESS) ? "SUCCESS" : "FAILED"), scmd);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 4d341a9..8c942c6 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2415,9 +2415,17 @@ _scsih_host_reset(struct scsi_cmnd *scmd)
ioc->name, scmd);
scsi_print_command(scmd);
+ if (ioc->is_driver_loading) {
+ pr_info(MPT3SAS_FMT "Blocking the host reset\n",
+ ioc->name);
+ r = FAILED;
+ goto out;
+ }
+
retval = mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
FORCE_BIG_HAMMER);
r = (retval < 0) ? FAILED : SUCCESS;
+out:
pr_info(MPT3SAS_FMT "host reset: %s scmd(%p)\n",
ioc->name, ((r == SUCCESS) ? "SUCCESS" : "FAILED"), scmd);
--
2.0.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/
[no subject]
Do you need a loan if yes contact us now.with:Name Amount Duration to j.rodriiguezd...@gmail.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 v2 2/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
On Tue, 4 Nov 2014, Vignesh R wrote:
> This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
> hwmod structures of tscadc has been moved to ipblock_data so that it can
> be reused in am43xx. The clock domain names are separately set for am33xx
> and am43xx. Thus tscadc dt entries can now be added to am43xx board
> dt files.
>
> Signed-off-by: Vignesh R
...
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
> index 6e57b8ad0db5..b92a7c7825fa 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
...
> +static void am33xx_hwmod_clockdomain(void)
> +{
> + CLKDMNAME(am33xx_l4_hs_hwmod, "l4hs_clkdm");
> + CLKDMNAME(am33xx_adc_tsc_hwmod, "l4_wkup_clkdm");
> +}
> +
> +static void am43xx_hwmod_clockdomain(void)
> +{
> + CLKDMNAME(am33xx_l4_hs_hwmod, "l3_clkdm");
> + CLKDMNAME(am33xx_adc_tsc_hwmod, "l3s_tsc_clkdm");
> +}
> +
...
> + am33xx_hwmod_clockdomain();
I looked at this patch and the one before it. Is there some reason why we
need to share these two hwmods between AM33xx and AM43xx? It seems
cleaner just to add the ADC data directly to the AM43xx hwmod data file,
not touch the AM33xx data, and not add another runtime data update for the
clockdomains. Unless there's something that I'm missing?
- Paul
--
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] KVM: ia64: remove
On Wed, Nov 19, 2014 at 10:05:43PM +0100, Paolo Bonzini wrote: > KVM for ia64 has been marked as broken not just once, but twice even, > and the last patch from the maintainer is now roughly 5 years old. > Time for it to rest in piece. > Acked-by: Gleb Natapov Next step is to move ioapic bits into arch :) > Signed-off-by: Paolo Bonzini > --- > The patch was edited to keep its size decent, by dropping > all the removed lines from the deleted files. > > MAINTAINERS |9 - > arch/ia64/Kconfig |3 - > arch/ia64/Makefile |1 - > arch/ia64/include/asm/kvm_host.h| 609 -- > arch/ia64/include/asm/pvclock-abi.h | 48 - > arch/ia64/include/uapi/asm/kvm.h| 268 - > arch/ia64/kvm/Kconfig | 66 -- > arch/ia64/kvm/Makefile | 67 -- > arch/ia64/kvm/asm-offsets.c | 241 > arch/ia64/kvm/irq.h | 33 - > arch/ia64/kvm/kvm-ia64.c| 1942 -- > arch/ia64/kvm/kvm_fw.c | 674 --- > arch/ia64/kvm/kvm_lib.c | 21 - > arch/ia64/kvm/kvm_minstate.h| 266 - > arch/ia64/kvm/lapic.h | 30 - > arch/ia64/kvm/memcpy.S |1 - > arch/ia64/kvm/memset.S |1 - > arch/ia64/kvm/misc.h| 94 -- > arch/ia64/kvm/mmio.c| 336 -- > arch/ia64/kvm/optvfault.S | 1090 - > arch/ia64/kvm/process.c | 1024 > arch/ia64/kvm/trampoline.S | 1038 > arch/ia64/kvm/vcpu.c| 2209 > --- > arch/ia64/kvm/vcpu.h| 752 > arch/ia64/kvm/vmm.c | 99 -- > arch/ia64/kvm/vmm_ivt.S | 1392 -- > arch/ia64/kvm/vti.h | 290 - > arch/ia64/kvm/vtlb.c| 640 -- > virt/kvm/ioapic.c | 5 - > virt/kvm/ioapic.h | 1 - > virt/kvm/irq_comm.c | 22 - > 31 files changed, 13272 deletions(-) > delete mode 100644 arch/ia64/include/asm/kvm_host.h > delete mode 100644 arch/ia64/include/asm/pvclock-abi.h > delete mode 100644 arch/ia64/include/uapi/asm/kvm.h > delete mode 100644 arch/ia64/kvm/Kconfig > delete mode 100644 arch/ia64/kvm/Makefile > delete mode 100644 arch/ia64/kvm/asm-offsets.c > delete mode 100644 arch/ia64/kvm/irq.h > delete mode 100644 arch/ia64/kvm/kvm-ia64.c > delete mode 100644 arch/ia64/kvm/kvm_fw.c > delete mode 100644 arch/ia64/kvm/kvm_lib.c > delete mode 100644 arch/ia64/kvm/kvm_minstate.h > delete mode 100644 arch/ia64/kvm/lapic.h > delete mode 100644 arch/ia64/kvm/memcpy.S > delete mode 100644 arch/ia64/kvm/memset.S > delete mode 100644 arch/ia64/kvm/misc.h > delete mode 100644 arch/ia64/kvm/mmio.c > delete mode 100644 arch/ia64/kvm/optvfault.S > delete mode 100644 arch/ia64/kvm/process.c > delete mode 100644 arch/ia64/kvm/trampoline.S > delete mode 100644 arch/ia64/kvm/vcpu.c > delete mode 100644 arch/ia64/kvm/vcpu.h > delete mode 100644 arch/ia64/kvm/vmm.c > delete mode 100644 arch/ia64/kvm/vmm_ivt.S > delete mode 100644 arch/ia64/kvm/vti.h > delete mode 100644 arch/ia64/kvm/vtlb.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a12edf2624e5..56705138ca74 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5244,15 +5244,6 @@ S: Supported > F: arch/powerpc/include/asm/kvm* > F: arch/powerpc/kvm/ > > -KERNEL VIRTUAL MACHINE For Itanium (KVM/IA64) > -M: Xiantao Zhang > -L: kvm-i...@vger.kernel.org > -W: http://kvm.qumranet.com > -S: Supported > -F: Documentation/ia64/kvm.txt > -F: arch/ia64/include/asm/kvm* > -F: arch/ia64/kvm/ > - > KERNEL VIRTUAL MACHINE for s390 (KVM/s390) > M: Christian Borntraeger > M: Cornelia Huck > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index c84c88d7..11afe7ab1981 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -21,7 +21,6 @@ config IA64 > select HAVE_DYNAMIC_FTRACE if (!ITANIUM) > select HAVE_FUNCTION_TRACER > select HAVE_DMA_ATTRS > - select HAVE_KVM > select TTY > select HAVE_ARCH_TRACEHOOK > select HAVE_DMA_API_DEBUG > @@ -640,8 +639,6 @@ source "security/Kconfig" > > source "crypto/Kconfig" > > -source "arch/ia64/kvm/Kconfig" > - > source "lib/Kconfig" > > config IOMMU_HELPER > diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile > index 5441b14994fc..970d0bd99621 100644 > --- a/arch/ia64/Makefile > +++ b/arch/ia64/Makefile > @@ -53,7 +53,6 @@ core-$(CONFIG_IA64_HP_ZX1) += arch/ia64/dig/ > core-$(CONFIG_IA64_HP_ZX1_SWIOTLB) += arch/ia64/dig/ > core-$(CONFIG_IA64_SGI_SN2) += arch/ia64/sn/ > core-$(CONFIG_IA64_SGI_UV) += arch/ia64/uv/ > -core-$(CONFIG_KVM) += arch/ia64/kvm/ > > drivers-$(CONFIG_PCI)
[RFC Patch V1] genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU
With Posted-Interrupts support in Intel CPU and IOMMU, an external
interrupt from assigned-devices could be directly delivered to a
virtual CPU in a virtual machine. Instead of hacking KVM and Intel
IOMMU drivers, we propose a platform independent interface to target
an interrupt to a specific virtual CPU in a virtual machine, or set
virtual CPU affinity for an interrupt.
By adopting this new interface and the hierarchy irqdomain, we could
easily support posted-interrupts on Intel platforms, and also provide
flexible enough interfaces for other platforms to support similar
features.
We may also cooperate between set_affinity() and set_vcpu_affinity()
in IRQ core or irq chip drivers.
Here is the usage scenario for this interface:
Guest update MSI/MSI-X interrupt configuratoin
-->QEMU and KVM handle this
-->KVM call this interface (passing posted interrupts descriptor
and guest vector)
-->irq core will transfer the control to IOMMU
-->IOMMU will do the real work of updating IRTE (IRTE has new
format for VT-d Posted-Interrupts)
You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html
Signed-off-by: Jiang Liu
Signed-off-by: Feng Wu
---
include/linux/irq.h |6 ++
kernel/irq/manage.c | 19 +++
2 files changed, 25 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 8badf34baf0f..0a3c8ac38ffb 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -29,6 +29,7 @@
struct seq_file;
struct module;
struct msi_msg;
+struct irq_vcpu_id;
/*
* IRQ line status.
@@ -323,6 +324,8 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data
*d)
* irq_request_resources
* @irq_compose_msi_msg: optional to compose message content for MSI
* @irq_write_msi_msg: optional to write message content for MSI
+ * @irq_set_vcpu_affinity: optional to target a virtual CPU in a virtual
+ * machine
* @flags: chip specific flags
*/
struct irq_chip {
@@ -362,6 +365,8 @@ struct irq_chip {
void(*irq_compose_msi_msg)(struct irq_data *data, struct
msi_msg *msg);
void(*irq_write_msi_msg)(struct irq_data *data, struct
msi_msg *msg);
+ int (*irq_set_vcpu_affinity)(struct irq_data *data, struct
irq_vcpu_id *vcpu_id);
+
unsigned long flags;
};
@@ -415,6 +420,7 @@ extern void irq_cpu_online(void);
extern void irq_cpu_offline(void);
extern int irq_set_affinity_locked(struct irq_data *data,
const struct cpumask *cpumask, bool force);
+extern int irq_set_vcpu_affinity(unsigned int irq, struct irq_vcpu_id
*vcpu_id);
#if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_PENDING_IRQ)
void irq_move_irq(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 80692373abd6..4ae8f243293a 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -247,6 +247,25 @@ int irq_set_affinity_hint(unsigned int irq, const struct
cpumask *m)
}
EXPORT_SYMBOL_GPL(irq_set_affinity_hint);
+int irq_set_vcpu_affinity(unsigned int irq, struct irq_vcpu_id *vcpu_id)
+{
+ struct irq_desc *desc = irq_to_desc(irq);
+ struct irq_chip *chip;
+ unsigned long flags;
+ int ret = -ENOSYS;
+
+ if (!desc)
+ return -EINVAL;
+
+ raw_spin_lock_irqsave(>lock, flags);
+ chip = desc->irq_data.chip;
+ if (chip && chip->irq_set_vcpu_affinity)
+ ret = chip->irq_set_vcpu_affinity(>irq_data, vcpu_id);
+ raw_spin_unlock_irqrestore(>lock, flags);
+
+ return ret;
+}
+
static void irq_affinity_notify(struct work_struct *work)
{
struct irq_affinity_notify *notify =
--
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 v2 02/10] crypto: AF_ALG: user space interface for cipher info
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote: > Am Dienstag, 18. November 2014, 22:08:23 schrieb Herbert Xu: > > Hi Herbert, Steffen, > > > > > We already have crypto_user so you should be extending that to > > cover what's missing. > > After playing a bit with the interface, I think it falls short supporting > AF_ALG in the following way: > > crypto_user cannot be applied to the currently active cipher that one has > open > with AF_ALG. For getting information, one has to call crypto_user with the > cra_driver_name of a cipher. (Why is that limitation, btw (see crypto_report > and the use of cru_driver_name?) crypto_report() was intended to provide informations of one implementation of a algorithm, so it was required to specify this algorithm exactly with cru_driver_name. We could extend crypto_report() to provide informations of the algorithm with the highest priority that matches cra_name. Or, we also have crypto_dump_report(). This basically provides informations on all instantiated algorithms, similar to /proc/crypto. We could extend this in a way that you can provide a cra_name. Then it can dump out the informations of all algorithms that match cra_name. -- 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 net V3] virtio-net: validate features during probe
On Thu, Nov 20, 2014 at 02:10:35PM +0800, Jason Wang wrote:
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell
> Cc: Cornelia Huck
> Cc: Wanlong Gao
> Signed-off-by: Michael S. Tsirkin
> Signed-off-by: Jason Wang
Looks good, minor nits below:
> ---
> Changes from V2:
> - only check the features for ctrl vq (this fix the real bug)
> - better error message and simplify API
> ---
> drivers/net/virtio_net.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index ec2a8b4..a6bcfce 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1673,6 +1673,40 @@ static const struct attribute_group
> virtio_net_mrg_rx_group = {
> };
> #endif
>
> +static bool virtnet_fail_on_feature(struct virtio_device *vdev,
> + unsigned int fbit,
> + const char *fname, const char *dname)
> +{
> + if (!virtio_has_feature(vdev, fbit))
> + return false;
> +
> + dev_err(>dev, "Hypervisor bug: advertise feature %s but not %s",
Well we don't know it's a hypervisor. How about:
Device bug: advertises feature %s but not %s.
> + fname, dname);
> +
> + return true;
> +}
> +
> +#define VIRTNET_FAIL_ON(vdev, fbit, dbit)\
> + virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
I would pass dbit directly, and supply a string from caller,
instead if #dbit, this way it can be any string.
> +
> +static bool virtnet_validate_features(struct virtio_device *vdev)
> +{
> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
> + VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
> + VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
> + VIRTIO_NET_F_TRL_VQ) ||
Typo: VIRTIO_NET_F_CTRL_VQ.
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
> + VIRTIO_NET_F_CTRL_VQ))) {
> + return false;
> + }
> +
> + return true;
> +}
> +
> static int virtnet_probe(struct virtio_device *vdev)
> {
> int i, err;
> @@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
> struct virtnet_info *vi;
> u16 max_queue_pairs;
>
> + if (!virtnet_validate_features(vdev))
> + return -EINVAL;
> +
> /* Find if host supports multiqueue virtio_net device */
> err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
> struct virtio_net_config,
> --
> 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] random: Remove unused arch_has_random[_seed]()
arch_has_random() and arch_has_random_seed() were added in 7b878d4b48c4
"random: Add arch_has_random[_seed]()".
arch_has_random() was never used.
arch_has_random_seed() was used in arch_random_refill(), but that usage
was removed in 48d6be955a71 "random: limit the contribution of the hw
rng to at most half".
If they're not used save arch code the trouble of implementing them.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/archrandom.h | 9 -
arch/x86/include/asm/archrandom.h | 3 ---
include/linux/random.h| 8
3 files changed, 20 deletions(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch/powerpc/include/asm/archrandom.h
index bde531103638..801beba4e64b 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -25,11 +25,6 @@ static inline int arch_get_random_int(unsigned int *v)
return rc;
}
-static inline int arch_has_random(void)
-{
- return !!ppc_md.get_random_long;
-}
-
int powernv_get_random_long(unsigned long *v);
static inline int arch_get_random_seed_long(unsigned long *v)
@@ -40,10 +35,6 @@ static inline int arch_get_random_seed_int(unsigned int *v)
{
return 0;
}
-static inline int arch_has_random_seed(void)
-{
- return 0;
-}
#endif /* CONFIG_ARCH_RANDOM */
diff --git a/arch/x86/include/asm/archrandom.h
b/arch/x86/include/asm/archrandom.h
index 69f1366f1aa3..6ad7f6d3f97f 100644
--- a/arch/x86/include/asm/archrandom.h
+++ b/arch/x86/include/asm/archrandom.h
@@ -114,9 +114,6 @@ GET_SEED(arch_get_random_seed_int, unsigned int,
RDSEED_INT, ASM_NOP4);
#endif /* CONFIG_X86_64 */
-#define arch_has_random() static_cpu_has(X86_FEATURE_RDRAND)
-#define arch_has_random_seed() static_cpu_has(X86_FEATURE_RDSEED)
-
#else
static inline int rdrand_long(unsigned long *v)
diff --git a/include/linux/random.h b/include/linux/random.h
index b05856e16b75..6d6e1424184e 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -88,10 +88,6 @@ static inline int arch_get_random_int(unsigned int *v)
{
return 0;
}
-static inline int arch_has_random(void)
-{
- return 0;
-}
static inline int arch_get_random_seed_long(unsigned long *v)
{
return 0;
@@ -100,10 +96,6 @@ static inline int arch_get_random_seed_int(unsigned int *v)
{
return 0;
}
-static inline int arch_has_random_seed(void)
-{
- return 0;
-}
#endif
/* Pseudo random number generator from numerical recipes. */
--
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: [RFC PATCH v4] ACPICA/Events: Add support to ensure GPE is disabled by default for handlers.
Hi, Kirill Could also help to confirm if this patch can also fix the issue. Please help to validate the 2 fix patchsets separately. Thanks in advance. Best regards -Lv > From: Zheng, Lv > Sent: Thursday, November 20, 2014 2:45 PM > > On some platforms, GPE is not disabled by default after ACPI hardware is > enabled. This confuses GPE drivers. This patch adds support to disable GPE > by default for GPE handler drivers. > > Signed-off-by: Lv Zheng > Cc: Kirill A. Shutemov > --- > drivers/acpi/acpica/evxface.c |7 +++ > 1 file changed, 7 insertions(+) > > Index: linux-acpica/drivers/acpi/acpica/evxface.c > === > --- linux-acpica.orig/drivers/acpi/acpica/evxface.c > +++ linux-acpica/drivers/acpi/acpica/evxface.c > @@ -821,6 +821,14 @@ acpi_install_gpe_handler(acpi_handle gpe > ~(ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK); > gpe_event_info->flags |= (u8)(type | ACPI_GPE_DISPATCH_HANDLER); > > + /* > + * Make sure that the GPE is disabled by default for the GPE > + * handler driver. It is expected that the GPE handler driver > + * should invoke acpi_enable_gpe() after installing the GPE > + * handler. > + */ > + (void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE); > + > acpi_os_release_lock(acpi_gbl_gpe_lock, flags); > > unlock_and_exit: -- 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 v4] ACPICA/Events: Add support to ensure GPE is disabled by default for handlers.
On some platforms, GPE is not disabled by default after ACPI hardware is enabled. This confuses GPE drivers. This patch adds support to disable GPE by default for GPE handler drivers. Signed-off-by: Lv Zheng Cc: Kirill A. Shutemov --- drivers/acpi/acpica/evxface.c |7 +++ 1 file changed, 7 insertions(+) Index: linux-acpica/drivers/acpi/acpica/evxface.c === --- linux-acpica.orig/drivers/acpi/acpica/evxface.c +++ linux-acpica/drivers/acpi/acpica/evxface.c @@ -821,6 +821,14 @@ acpi_install_gpe_handler(acpi_handle gpe ~(ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK); gpe_event_info->flags |= (u8)(type | ACPI_GPE_DISPATCH_HANDLER); + /* +* Make sure that the GPE is disabled by default for the GPE +* handler driver. It is expected that the GPE handler driver +* should invoke acpi_enable_gpe() after installing the GPE +* handler. +*/ + (void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE); + acpi_os_release_lock(acpi_gbl_gpe_lock, flags); unlock_and_exit: -- 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: [f2fs-dev] [PATCH 1/3] f2fs: call flush_dcache_page when the page was updated
On Thu, Nov 20, 2014 at 03:04:10PM +0900, Changman Lee wrote:
> Hi Jaegeuk,
>
> We should call flush_dcache_page before kunmap because the purpose of the
> cache flush is to address aliasing problem related to virtual address.
Oh, I just followed zero_user_segments below.
static inline void zero_user_segments(struct page *page,
unsigned start1, unsigned end1,
unsigned start2, unsigned end2)
{
void *kaddr = kmap_atomic(page);
BUG_ON(end1 > PAGE_SIZE || end2 > PAGE_SIZE);
if (end1 > start1)
memset(kaddr + start1, 0, end1 - start1);
if (end2 > start2)
memset(kaddr + start2, 0, end2 - start2);
kunmap_atomic(kaddr);
flush_dcache_page(page);
}
Is this a wrong reference? Or, a bug?
Anyway I modified as below.
Thanks,
>From 7cb7b27c8cd2efc8a31d79239bef5b41c6e79216 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Tue, 18 Nov 2014 10:50:21 -0800
Subject: [PATCH] f2fs: call flush_dcache_page when the page was updated
Whenever f2fs updates mapped pages, it needs to call flush_dcache_page.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/dir.c| 7 ++-
fs/f2fs/inline.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 5a49995..fabf4ee 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -287,8 +287,10 @@ void f2fs_set_link(struct inode *dir, struct
f2fs_dir_entry *de,
f2fs_wait_on_page_writeback(page, type);
de->ino = cpu_to_le32(inode->i_ino);
set_de_type(de, inode);
- if (!f2fs_has_inline_dentry(dir))
+ if (!f2fs_has_inline_dentry(dir)) {
+ flush_dcache_page(page);
kunmap(page);
+ }
set_page_dirty(page);
dir->i_mtime = dir->i_ctime = CURRENT_TIME;
mark_inode_dirty(dir);
@@ -365,6 +367,7 @@ static int make_empty_dir(struct inode *inode,
make_dentry_ptr(, (void *)dentry_blk, 1);
do_make_empty_dir(inode, parent, );
+ flush_dcache_page(dentry_page);
kunmap_atomic(dentry_blk);
set_page_dirty(dentry_page);
@@ -578,6 +581,7 @@ fail:
update_inode_page(dir);
clear_inode_flag(F2FS_I(dir), FI_UPDATE_DIR);
}
+ flush_dcache_page(dentry_page);
kunmap(dentry_page);
f2fs_put_page(dentry_page, 1);
return err;
@@ -660,6 +664,7 @@ void f2fs_delete_entry(struct f2fs_dir_entry *dentry,
struct page *page,
bit_pos = find_next_bit_le(_blk->dentry_bitmap,
NR_DENTRY_IN_BLOCK,
0);
+ flush_dcache_page(page);
kunmap(page); /* kunmap - pair of f2fs_find_entry */
set_page_dirty(page);
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index f26fb87..4291c1f 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -106,6 +106,7 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn,
struct page *page)
src_addr = inline_data_addr(dn->inode_page);
dst_addr = kmap_atomic(page);
memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
+ flush_dcache_page(page);
kunmap_atomic(dst_addr);
SetPageUptodate(page);
no_update:
@@ -357,6 +358,7 @@ static int f2fs_convert_inline_dir(struct inode *dir,
struct page *ipage,
memcpy(dentry_blk->filename, inline_dentry->filename,
NR_INLINE_DENTRY * F2FS_SLOT_LEN);
+ flush_dcache_page(page);
kunmap_atomic(dentry_blk);
SetPageUptodate(page);
set_page_dirty(page);
--
2.1.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] perf tools: Fix segfault due to invalid kernel dso access
Arnaldo,
Could you please consider applying this?
Thanks,
Namhyung
On Tue, 18 Nov 2014 13:30:28 +0900, Namhyung Kim wrote:
> Jiri reported that the commit 96d78059d6d9 ("perf tools: Make vmlinux
> short name more like kallsyms short name") segfaults on perf script.
>
> When processing kernel mmap event, it should access the 'kernel'
> variable as sometimes it cannot find a matching dso from build-id
> table so 'dso' might be invalid.
>
> Reported-by: Jiri Olsa
> Tested-by: Jiri Olsa
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/machine.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 52e94902afb1..85033d80fd6a 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1106,8 +1106,8 @@ static int machine__process_kernel_mmap_event(struct
> machine *machine,
> if (__machine__create_kernel_maps(machine, kernel) < 0)
> goto out_problem;
>
> - if (strstr(dso->long_name, "vmlinux"))
> - dso__set_short_name(dso, "[kernel.vmlinux]", false);
> + if (strstr(kernel->long_name, "vmlinux"))
> + dso__set_short_name(kernel, "[kernel.vmlinux]", false);
>
> machine__set_kernel_mmap_len(machine, event);
--
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: [GIT PULL] SCSI fixes for 3.18-rc4
On Sun, Nov 16, 2014 at 08:17:32AM -0800, James Bottomley wrote: > This is a set of six fixes and a MAINTAINER update. The fixes are two > multipath (one in Test Unit Ready handling for the path checkers and one > in the section of code that sends a start unit after failover; both of > these were perturbed by the scsi-mq update), a CD-ROM door locking fix > that was likewise introduced by scsi-mq and three driver fixes for a > previous code update in cxgb4i, megaraid_sas and bnx2fc. FYI, the multipath issue actually is due much older EH changes, not due to blk-mq work. -- 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 v5 2/2] tracing: add additional marks to signal very large time
Hello,
On Thu, Nov 20, 2014 at 03:05:43PM +0900, Namhyung Kim wrote:
> Hi Steve and Byungchul,
>
> On Wed, 19 Nov 2014 20:06:04 -0500, Steven Rostedt wrote:
> > On Thu, 20 Nov 2014 09:15:35 +0900
> > byungchul.p...@lge.com wrote:
> >> -static unsigned long preempt_mark_thresh_us = 100;
> >> +#undef MARK
> >> +#define MARK(v, s) {.val = v, .sym = s}
> >> +/* trace overhead mark */
> >> +static const struct trace_mark {
> >> + unsigned long long val; /* unit: nsec */
> >> + charsym;
> >> +} mark[] = {
> >> + MARK(10ULL , '$'), /* 1 sec */
> >> + MARK(100ULL , '#'), /* 1000 usecs */
> >> + MARK(10ULL , '!'), /* 100 usecs */
> >> + MARK(1ULL , '+'), /* 10 usecs */
> >> + MARK(0ULL , ' '), /* 0 usecs */
> >> +};
> >> +#undef MARK
> >> +
> >> +char trace_find_mark(unsigned long long d)
> >> +{
> >> + int i;
> >> + int size = ARRAY_SIZE(mark);
> >> +
> >> + for (i = 0; i < size; i++) {
> >> + if (d >= mark[i].val)
> >> + break;
> >> + }
> >> +
> >> + return (i == size)? ' ' : mark[i].sym;
> >
> > Change this to:
> >
> > /* The break from loop must have been hit */
> > if (WARN_ON_ONCE(i == size))
> > return ' ';
>
> I think it's impossible since it's always true that 'd >= 0'.
>
If someone won't define "MARK(0ULL, ' ')", then i think it can happen. :)
Thanks,
Byungchul
> Thanks,
> Namhyung
>
> >
> > return mark[i].sym;
> >
> > -- Steve
> >
> >
> >> +}
> >>
> >> static int
> >> lat_print_timestamp(struct trace_iterator *iter, u64 next_ts)
> >> @@ -506,8 +532,7 @@ lat_print_timestamp(struct trace_iterator *iter, u64
> >> next_ts)
> >>return trace_seq_printf(
> >>s, " %4lldus%c: ",
> >>abs_ts,
> >> - rel_ts > preempt_mark_thresh_us ? '!' :
> >> -rel_ts > 1 ? '+' : ' ');
> >> + trace_find_mark(rel_ts * NSEC_PER_USEC));
> >>} else { /* !verbose && !in_ns */
> >>return trace_seq_printf(s, " %4lld: ", abs_ts);
> >>}
> >> @@ -692,7 +717,7 @@ int register_ftrace_event(struct trace_event *event)
> >>goto out;
> >>
> >>} else {
> >> -
> >> +
> >>event->type = next_event_type++;
> >>list = _event_list;
> >>}
> --
> 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/
--
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: [PATCHv6 5/5] hwspinlock/omap: add support for dt nodes
Hi Bjorn, On Thu, Nov 20, 2014 at 2:43 AM, Bjorn Andersson wrote: > I still have a huge problem understanding the awesomeness with the > "base_id". If you have a SoC with 2 hwlock blocks; say 8+8 locks, used > for interaction with e.g. a modem and a video core respectively. > Why would you in either remote system offset the locks with 8? > Wouldn't e.g the modem use locks hwlock0:0-7 and video core use locks > hwlock1:0-7? Please see below > What systems use more than one hwlock block None that we know of. This concern was raised some time ago by Arnd and since it was easy to deal with we added the 'base_id' notion. > and do you know of any reasons why these hwlocks are globally numbered? Because on an heterogeneous asymmetric multiprocessing systems you sometimes have use cases where hwlocks are dynamically allocated and their id numbers need to be synchronized between user space applications, the Linux kernel, and entities running on remote processors (which are likely not running Linux). For this to work we have to have some system-wide global hwlocks naming that is predefined and known to all processors. A mere number seems like the simplest naming method. A dynamic hwlock request API could return "hwlock1:0" but a mere 8 seems easier to deal with. 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: [PATCH] KVM: ia64: remove
On 20/11/2014 02:16, Chen, Tiejun wrote: > On 2014/11/20 5:05, Paolo Bonzini wrote: >> KVM for ia64 has been marked as broken not just once, but twice even, >> and the last patch from the maintainer is now roughly 5 years old. >> Time for it to rest in piece. >> >> Signed-off-by: Paolo Bonzini >> --- > > I think we also need to sync this in Documentation: > > Documentation: virtual: kvm: remove ia64 > > kvm/ia64 would be gone so just clean Documentation. > > Signed-off-by: Tiejun Chen > --- > Documentation/ia64/kvm.txt | 83 > - > Documentation/ia64/paravirt_ops.txt | 8 ++-- > Documentation/virtual/kvm/api.txt | 45 ++-- > 3 files changed, 26 insertions(+), 110 deletions(-) > delete mode 100644 Documentation/ia64/kvm.txt > > diff --git a/Documentation/ia64/kvm.txt b/Documentation/ia64/kvm.txt > deleted file mode 100644 > index ffb5c80..000 > --- a/Documentation/ia64/kvm.txt > +++ /dev/null > @@ -1,83 +0,0 @@ > -Currently, kvm module is in EXPERIMENTAL stage on IA64. This means that > -interfaces are not stable enough to use. So, please don't run critical > -applications in virtual machine. > -We will try our best to improve it in future versions! > - > - Guide: How to boot up guests on kvm/ia64 > - > -This guide is to describe how to enable kvm support for IA-64 systems. > - > -1. Get the kvm source from git.kernel.org. > - Userspace source: > - git clone > git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git > - Kernel Source: > - git clone > git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git > - > -2. Compile the source code. > - 2.1 Compile userspace code: > - (1)cd ./kvm-userspace > - (2)./configure > - (3)cd kernel > - (4)make sync LINUX= $kernel_dir (kernel_dir is the > directory of kernel source.) > - (5)cd .. > - (6)make qemu > - (7)cd qemu; make install > - > - 2.2 Compile kernel source code: > - (1) cd ./$kernel_dir > - (2) Make menuconfig > - (3) Enter into virtualization option, and choose kvm. > - (4) make > - (5) Once (4) done, make modules_install > - (6) Make initrd, and use new kernel to reboot up host > machine. > - (7) Once (6) done, cd $kernel_dir/arch/ia64/kvm > - (8) insmod kvm.ko; insmod kvm-intel.ko > - > -Note: For step 2, please make sure that host page size == > TARGET_PAGE_SIZE of qemu, otherwise, may fail. > - > -3. Get Guest Firmware named as Flash.fd, and put it under right place: > - (1) If you have the guest firmware (binary) released by Intel > Corp for Xen, use it directly. > - > - (2) If you have no firmware at hand, Please download its source > from > - hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg > - you can get the firmware's binary in the directory of > efi-vfirmware.hg/binaries. > - > - (3) Rename the firmware you owned to Flash.fd, and copy it to > /usr/local/share/qemu > - > -4. Boot up Linux or Windows guests: > - 4.1 Create or install a image for guest boot. If you have xen > experience, it should be easy. > - > - 4.2 Boot up guests use the following command. > - /usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda > $your_image > - (xx is the number of virtual processors for the guest, > now the maximum value is 4) > - > -5. Known possible issue on some platforms with old Firmware. > - > -In the event of strange host crash issues, try to solve it through > either of the following ways: > - > -(1): Upgrade your Firmware to the latest one. > - > -(2): Applying the below patch to kernel source. > -diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S > -index 0b53344..f02b0f7 100644 > a/arch/ia64/kernel/pal.S > -+++ b/arch/ia64/kernel/pal.S > -@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static) > - mov ar.pfs = loc1 > - mov rp = loc0 > - ;; > -- srlz.d // serialize restoration of psr.l > -+ srlz.i // serialize restoration of psr.l > -+ ;; > - br.ret.sptk.many b0 > - END(ia64_pal_call_static) > - > -6. Bug report: > - If you found any issues when use kvm/ia64, Please post the bug > info to kvm-ia64-devel mailing list. > - https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/ > - > -Thanks for your interest! Let's work together, and make kvm/ia64 > stronger and stronger! > - > - > - Xiantao > Zhang > - 2008.3.10 > diff --git a/Documentation/ia64/paravirt_ops.txt > b/Documentation/ia64/paravirt_ops.txt > index 39ded02..3a1f36b 100644 > --- a/Documentation/ia64/paravirt_ops.txt > +++
Re: [PATCH v4 3/3] tracing: add additional marks to signal very large delay
Hi, namhyung On Thu, Nov 20, 2014 at 03:11:19PM +0900, Namhyung Kim wrote: > On Wed, 19 Nov 2014 13:35:15 -0500, Steven Rostedt wrote: > > On Tue, 18 Nov 2014 14:57:26 +0900 > > byungchul.p...@lge.com wrote: > > > >> From: Byungchul Park > >> > >> Currently, some tracers tracing latency print "!" or "+" just after time > >> to signal overhead, depending on the interval between events. Even it is > >> usually enough to do that, we sometimes need to be signaled for bigger > >> interval than 100 micro seconds. > >> > >> Signed-off-by: Byungchul Park > >> --- > >> Documentation/trace/ftrace.txt |8 +--- > >> kernel/trace/trace_output.c| 23 ++- > >> 2 files changed, 23 insertions(+), 8 deletions(-) > >> > >> diff --git a/Documentation/trace/ftrace.txt > >> b/Documentation/trace/ftrace.txt > >> index f827e2f..64efb3e 100644 > >> --- a/Documentation/trace/ftrace.txt > >> +++ b/Documentation/trace/ftrace.txt > >> @@ -680,9 +680,11 @@ The above is mostly meaningful for kernel developers. > >> needs to be fixed to be only relative to the same CPU. > >> The marks are determined by the difference between this > >> current trace and the next trace. > >> -'!' - greater than preempt_mark_thresh (default 100) > >> -'+' - greater than 1 microsecond > >> -' ' - less than or equal to 1 microsecond. > >> +'$' - greater than 1 second > >> +'#' - greater than 1000 microsecond > >> +'!' - greater than 100 microsecond > >> +'+' - greater than 10 microsecond > > I've noticed that it's now changed from 1 msec to 10 msec. Is it okay? > Yes it is okay. Steve asked for changing the value. :) Thanks, Byungchul > Thanks, > Namhyung > > > >> +' ' - less than or equal to 10 microsecond. > >> > >>The rest is the same as the 'trace' file. > -- > 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/ -- 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 net] tcp: fix connect() invalid -EADDRNOTAVAIL error
On Thu, 2014-11-20 at 14:44 +1100, Jonathan Maxwell wrote: > > > Prerequisites for this to happen: > > > 1) The local tcp port range must be exhausted. > > > 2) A process must have called bind() followed by connect() for all > > > local ports. > > > > How the bind() is done exactly ? How SO_REUSEADDR is used ? > > It fails regardless. I tried both with and without for the client and > server programs. > This is the missing part from the programs. By not using SO_REUSEADDR, programs basically do not allow another programs to use same port. > But removing the bind() and just calling connect() from the initial > program > then a subsequent connect() from a separate program succeeds. It seems > that > this is inconsistent behaviour. The proposed fix makes it behave the > same for > > both cases. This not consistent behavior is well known and somehow expected by some applications. bind() requests the kernel that this socket has a reserved port. It means the socket can later disconnect from the target, and reconnect to another, using _same_ source port, or chose to listen() on this port. That is why kernel is so picky, otherwise the listen() might fail later... This is part of BSD socket semantic. You have to use SO_REUSEADDR on both programs to relax these constraints. Your change might break existing programs, really expecting kernel to behave as requested. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/10] crypto: AF_ALG: user space interface for cipher info
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote: > > Btw: is there an example that uses that interface? The ordering of data > structures in the netlink message is not really clear from looking at the > code. I wrote to tool that uses this API some time ago, it is still a bit rudimentary but should work. You can find it at: https://sourceforge.net/projects/crconf/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/3] perf tools: enable LBR call stack support
On Wed, 19 Nov 2014 14:32:08 +, Kan Liang wrote:
>> On Tue, 18 Nov 2014 16:36:55 -0500, kan liang wrote:
>> > + if (attr->exclude_user) {
>> > + attr->exclude_user = 0;
>> > +
>> > + pr_warning("LBR callstack option is only
>> > available"
>> > + " to get user callchain information."
>> > + " Force exclude_user to 0.\n");
>> > + }
>>
>> I'm not sure what's in a higher priority - maybe I missed earlier discussion.
>> IOW what about this?
>>
>> if (attr->exclude_user) {
>> pr_warning("LBR callstack option is only
>> available"
>> " to get user callchain
>> information.\n");
>
> I think either is fine. I'd like to add more info "Falling back to
> framepointers."
> based on your changes.
> So the user know what they will get then.
>
> What do you think?
Looks good to me. But I still slightly prefer not to override user
settings. But it's not a strong opinion though - I'd like to here from
others.
Thanks,
Namhyung
>
> pr_warning("LBR callstack option is only available"
>" to get user callchain information."
> " Falling back to framepointers.\n");
>
> pr_ warning ("Cannot use LBR callstack with branch stack"
> " Falling back to framepointers.\n");
--
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] perf tool: Add sort key symoff for perf diff
Hi Kan,
On Wed, 19 Nov 2014 14:17:33 +, Kan Liang wrote:
>>
>> On Tue, 18 Nov 2014 11:38:20 -0500, kan liang wrote:
>> > From: Kan Liang
>> >
>> > Sometime, especially debugging scaling issue, the function level diff
>> > may be high granularity. The user may want to do deeper diff analysis
>> > for some cache or lock issue. The "symoff" key can let the user sort
>> > differential profile by ips. This feature should only work when the
>> > perf.data comes from same binary.
>>
>> I think the symoff sort key now works well for different (i.e. modified)
>> binaries too.
>
> For different binaries, the function may be changed. So the offset may
> point to different code.
> What about this?
> "This feature should work when the perf.data comes from
> either same binary or same function of different binary."
> Or just simply remove this sentence.
I'd like to remove it. :)
>
>>
>> >
>> > -s::
>> > --sort=::
>> > - Sort by key(s): pid, comm, dso, symbol, cpu, parent, srcline.
>> > - Please see description of --sort in the perf-report man page.
>> > + Sort by key(s): pid, comm, dso, symbol, cpu, parent, srcline, symoff.
>> > +
>> > + - symoff: exact symbol + offset address executed at the time of
>> sample.
>> > + (for same binary compare)
>>
>> Ditto. And symoff is not only for perf diff, but it should work for normal
>> perf report also. So you'd better move the description to perf report man
>> page IMHO.
>
> OK, I will do it, and also remove "(for same binary compare)"
Thanks!
>
>>
>>
>> > +
>> > + For other keys, please see description of --sort in the perf-report
>> man page.
>> >
>> > -t::
>> > --field-separator=::
>> > diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
>> > index 1ce425d..03a4001 100644
>> > --- a/tools/perf/builtin-diff.c
>> > +++ b/tools/perf/builtin-diff.c
>> > @@ -744,7 +744,7 @@ static const struct option options[] = {
>> >OPT_STRING('S', "symbols", _conf.sym_list_str,
>> "symbol[,symbol...]",
>> > "only consider these symbols"),
>> >OPT_STRING('s', "sort", _order, "key[,key2...]",
>> > - "sort by key(s): pid, comm, dso, symbol, parent, cpu,
>> srcline, ..."
>> > + "sort by key(s): pid, comm, dso, symbol, parent, cpu,
>> srcline, symoff, ..."
>> > " Please refer the man page for the complete list."),
>> >OPT_STRING('t', "field-separator", _conf.field_sep,
>> "separator",
>> > "separator for columns, no spaces will be added between
>> "
>> > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index
>> > 6e88b9e..3d8a71b 100644
>> > --- a/tools/perf/util/hist.c
>> > +++ b/tools/perf/util/hist.c
>> > @@ -67,13 +67,14 @@ void hists__calc_col_len(struct hists *hists, struct
>> hist_entry *h)
>> >symlen = h->ms.sym->namelen + 4;
>> >if (verbose)
>> >symlen += BITS_PER_LONG / 4 + 2 + 3;
>> > - hists__new_col_len(hists, HISTC_SYMBOL, symlen);
>> >} else {
>> >symlen = unresolved_col_width + 4 + 2;
>> > - hists__new_col_len(hists, HISTC_SYMBOL, symlen);
>> >hists__set_unres_dso_col_len(hists, HISTC_DSO);
>> >}
>> >
>> > + hists__new_col_len(hists, HISTC_SYMBOL, symlen);
>> > + hists__new_col_len(hists, HISTC_SYMOFF, symlen);
>>
>> SYMOFF will need larger length at least 6 (for "+0xYYY"). Idealy 3 + symbol
>> size in hexdigit?
>>
>
> We also need to handle the case which doesn't have symbol available.
> What about this?
I'm fine with it (but I believe you'll fix the indentation).
Thanks,
Namhyung
> /*
> + * +6 accounts for '"+0xYYY ' symoff info
> * +4 accounts for '[x] ' priv level info
> * +2 accounts for 0x prefix on raw addresses
> * +3 accounts for ' y ' symtab origin info
> */
> if (h->ms.sym) {
> symlen = h->ms.sym->namelen + 4;
> if (verbose)
> symlen += BITS_PER_LONG / 4 + 2 + 3;
> hists__new_col_len(hists, HISTC_SYMBOL, symlen);
>
> + symlen = h->ms.sym->namelen + 6
> + hists__new_col_len(hists, HISTC_SYMOFF, symlen);
> } else {
> symlen = unresolved_col_width + 4 + 2;
> hists__new_col_len(hists, HISTC_SYMBOL, symlen);
> hists__set_unres_dso_col_len(hists, HISTC_DSO);
> + symlen = unresolved_col_width + 2
> + hists__new_col_len(hists, HISTC_SYMOFF, symlen);
> }
--
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] perf tool: Add sort key symoff for perf diff
On Tue, 18 Nov 2014 18:13:19 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 18, 2014 at 11:38:20AM -0500, kan.li...@intel.com escreveu: >> From: Kan Liang >> >> Sometime, especially debugging scaling issue, the function level diff >> may be high granularity. The user may want to do deeper diff analysis >> for some cache or lock issue. The "symoff" key can let the user sort >> differential profile by ips. This feature should only work when the >> perf.data comes from same binary. > > So, to avoid having people scratching heads, and since we have the > build-id for both perf.data files, hence for both binaries being > compared, can we check the build ids and either refuse to do the diff or > print a big warning about different binaries being compared? Why do you think so? I think it's fine to use symoff for different binaries for same reason as the symbol sort key. Even if some functions were changed, other DSOs and/or functions still have same offset and thus have meaningful diff result IMHO. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/1] misc: st32fwu: Add stm32 upgrade protocol handling
On Sat, Nov 8, 2014 at 9:29 PM, Karol Wrona wrote:
> Adds stm32 bootloader protocol handling.
>
Hi Karol,
Sorry for not being able to reply earlier. I'm finally back after a
period off-line.
I have implemented a first version of SPI flash upgrade in the
user-mode tool "stm32flash". I will submit it upstream after further
cleanup.
Anyway, now I have much clear idea about the SPI bootloader protocol
and differences with I2C and UART variants (already in "stm32flash").
There are few details in your driver that don't match the bootloader
protocol over SPI described in AN4268.
Can you please check with the documents you have and with your HW?
I'm using the document Rev.2 available in ST website at
http://www.st.com/web/en/resource/technical/document/application_note/DM00081379.pdf
Cannot find a previous revision to compare them.
> SPI transfers are done using DMA safe buffer which is allocated once per
> spi upgrade life cycle. Now it supports only SPI bus but it looks that UART
> or I2C are quite similar and it can be used as start platform for implementing
> their handling.
>
> It was tested on STM32F401 MCU.
>
> Change-Id: I5e5b441310c897ff822e65041531d80ea0e7426c
> Signed-off-by: Karol Wrona
> Acked-by: Kyungmin Park
> ---
> drivers/misc/Kconfig |1 +
> drivers/misc/Makefile |1 +
> drivers/misc/stm32fwu/Kconfig |6 +
> drivers/misc/stm32fwu/Makefile |1 +
> drivers/misc/stm32fwu/stm32_core.c | 403
>
> drivers/misc/stm32fwu/stm32_core.h | 81
> drivers/misc/stm32fwu/stm32_spi.c | 108 ++
> include/linux/stm32fwu.h | 49 +
> 8 files changed, 650 insertions(+)
> create mode 100644 drivers/misc/stm32fwu/Kconfig
> create mode 100644 drivers/misc/stm32fwu/Makefile
> create mode 100644 drivers/misc/stm32fwu/stm32_core.c
> create mode 100644 drivers/misc/stm32fwu/stm32_core.h
> create mode 100644 drivers/misc/stm32fwu/stm32_spi.c
> create mode 100644 include/linux/stm32fwu.h
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index bbeb451..b2e68c1 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -528,4 +528,5 @@ source "drivers/misc/mic/Kconfig"
> source "drivers/misc/genwqe/Kconfig"
> source "drivers/misc/echo/Kconfig"
> source "drivers/misc/cxl/Kconfig"
> +source "drivers/misc/stm32fwu/Kconfig"
> endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 7d5c4cd..88c8999 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -56,3 +56,4 @@ obj-$(CONFIG_GENWQE) += genwqe/
> obj-$(CONFIG_ECHO) += echo/
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE) += cxl/
> +obj-$(CONFIG_STM32_UPGRADE_PROTOCOL) += stm32fwu/
> diff --git a/drivers/misc/stm32fwu/Kconfig b/drivers/misc/stm32fwu/Kconfig
> new file mode 100644
> index 000..1484441
> --- /dev/null
> +++ b/drivers/misc/stm32fwu/Kconfig
> @@ -0,0 +1,6 @@
> +config STM32_UPGRADE_PROTOCOL
> + tristate "STM32 upgrade protocol support"
> + depends on SPI
> + help
> + STM32 microcontroller bootloader upgrade protocol.
> + Say Y if you want to use it.
> diff --git a/drivers/misc/stm32fwu/Makefile b/drivers/misc/stm32fwu/Makefile
> new file mode 100644
> index 000..1617530
> --- /dev/null
> +++ b/drivers/misc/stm32fwu/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_STM32_UPGRADE_PROTOCOL) += stm32_core.o stm32_spi.o
> diff --git a/drivers/misc/stm32fwu/stm32_core.c
> b/drivers/misc/stm32fwu/stm32_core.c
> new file mode 100644
> index 000..4c48cd8
> --- /dev/null
> +++ b/drivers/misc/stm32fwu/stm32_core.c
> @@ -0,0 +1,403 @@
> +/*
> + * Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "stm32_core.h"
> +
> +static inline int stm32fwu_wait_for_ack(struct stm32fwu_fw *fw, u32 retries)
> +{
> + return fw->wait_for_ack(fw, retries);
> +}
> +
> +static inline int stm32fwu_send_cmd(struct stm32fwu_fw *fw, u8 cmd,
> + u32 timeout)
> +{
> + struct stm32fwu_cmd cm = {
> + .cmd = cmd,
> + .neg_cmd = ~cmd,
> + .timeout = timeout,
> + };
> +
> + return fw->send_cmd(fw, );
> +}
> +
> +static inline int stm32fwu_write(struct
Re: frequent lockups in 3.18rc4
On Wed, Nov 19, 2014 at 6:42 PM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 5:16 PM, Andy Lutomirski wrote: >> >> And you were calling me crazy? :) > > Hey, I'm crazy like a fox. > >> We could be restarting just about anything if that happens. Except >> that if we double-faulted on a trap gate entry instead of an interrupt >> gate entry, then we can't restart, and, unless we can somehow decode >> the error code usefully (it's woefully undocumented), int 0x80 and >> int3 might be impossible to handle correctly if it double-faults. And >> please don't suggest moving int 0x80 to an IST stack :) > > No, no. So tell me if this won't work: > > - when forking a new process, make sure we allocate the vmalloc stack > *before* we copy the vm > > - this should guarantee that all new processes will at least have its > *own* stack always in its page tables, since vmalloc always fills in > the page table of the current page tables of the thread doing the > vmalloc. This gets interesting for kernel threads that don't really have an mm in the first place, though. > > HOWEVER, that leaves the task switch *to* that process, and making > sure that the stack pointer is ok in between the "switch %rsp" and > "switch %cr3". > > So then we make the rule be: switch %cr3 *before* switching %rsp, and > only in between those places can we get in trouble. Yes/no? > Kernel threads aside, sure. And we do it in this order anyway, I think. > And that small section is all with interrupts disabled, and nothing > should take an exception. The C code might take a double fault on a > regular access to the old stack (the *new* stack is guaranteed to be > mapped, but the old stack is not), but that should be very similar to > what we already do with "iret". So we can just fill in the page tables > and return. Unless we try to dump the stack from an NMI or something, but that should be fine regardless. > > For safety, add a percpu counter that is cleared before the %cr3 > setting, to make sure that we only do a *single* double-fault, but it > really sounds pretty safe. No? I wouldn't be surprised if that's just as expensive as just fixing up the pgd in the first place. The fixup is just: if (unlikely(pte_none(mm->pgd[pgd_address(rsp)]))) fix it; or something like that. > > The only deadly thing would be NMI, but that's an IST anyway, so not > an issue. No other traps should be able to happen except the double > page table miss. > > But hey, maybe I'm not crazy like a fox. Maybe I'm just plain crazy, > and I missed something else. I actually kind of like it, other than the kernel thread issue. We should arguably ditch lazy mm for kernel threads in favor of PCID, but that's a different story. Or we could beg Intel to give us separate kernel and user page table hierarchies. --Andy > > And no, I don't think the above is necessarily a *good* idea. But it > doesn't seem really overly complicated either. > > Linus -- Andy Lutomirski AMA Capital Management, LLC -- 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 net V3] virtio-net: validate features during probe
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell
Cc: Cornelia Huck
Cc: Wanlong Gao
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
Changes from V2:
- only check the features for ctrl vq (this fix the real bug)
- better error message and simplify API
---
drivers/net/virtio_net.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..a6bcfce 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1673,6 +1673,40 @@ static const struct attribute_group
virtio_net_mrg_rx_group = {
};
#endif
+static bool virtnet_fail_on_feature(struct virtio_device *vdev,
+ unsigned int fbit,
+ const char *fname, const char *dname)
+{
+ if (!virtio_has_feature(vdev, fbit))
+ return false;
+
+ dev_err(>dev, "Hypervisor bug: advertise feature %s but not %s",
+ fname, dname);
+
+ return true;
+}
+
+#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
+ virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
+
+static bool virtnet_validate_features(struct virtio_device *vdev)
+{
+ if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
+ (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
+VIRTIO_NET_F_CTRL_VQ) ||
+VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
+VIRTIO_NET_F_CTRL_VQ) ||
+VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
+VIRTIO_NET_F_TRL_VQ) ||
+VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, VIRTIO_NET_F_CTRL_VQ) ||
+VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
+VIRTIO_NET_F_CTRL_VQ))) {
+ return false;
+ }
+
+ return true;
+}
+
static int virtnet_probe(struct virtio_device *vdev)
{
int i, err;
@@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
struct virtnet_info *vi;
u16 max_queue_pairs;
+ if (!virtnet_validate_features(vdev))
+ return -EINVAL;
+
/* Find if host supports multiqueue virtio_net device */
err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
struct virtio_net_config,
--
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 3/3] tracing: add additional marks to signal very large delay
On Wed, 19 Nov 2014 13:35:15 -0500, Steven Rostedt wrote: > On Tue, 18 Nov 2014 14:57:26 +0900 > byungchul.p...@lge.com wrote: > >> From: Byungchul Park >> >> Currently, some tracers tracing latency print "!" or "+" just after time >> to signal overhead, depending on the interval between events. Even it is >> usually enough to do that, we sometimes need to be signaled for bigger >> interval than 100 micro seconds. >> >> Signed-off-by: Byungchul Park >> --- >> Documentation/trace/ftrace.txt |8 +--- >> kernel/trace/trace_output.c| 23 ++- >> 2 files changed, 23 insertions(+), 8 deletions(-) >> >> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt >> index f827e2f..64efb3e 100644 >> --- a/Documentation/trace/ftrace.txt >> +++ b/Documentation/trace/ftrace.txt >> @@ -680,9 +680,11 @@ The above is mostly meaningful for kernel developers. >> needs to be fixed to be only relative to the same CPU. >> The marks are determined by the difference between this >> current trace and the next trace. >> - '!' - greater than preempt_mark_thresh (default 100) >> - '+' - greater than 1 microsecond >> - ' ' - less than or equal to 1 microsecond. >> + '$' - greater than 1 second >> + '#' - greater than 1000 microsecond >> + '!' - greater than 100 microsecond >> + '+' - greater than 10 microsecond I've noticed that it's now changed from 1 msec to 10 msec. Is it okay? Thanks, Namhyung >> + ' ' - less than or equal to 10 microsecond. >> >>The rest is the same as the 'trace' file. -- 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: BUG in scsi_lib.c due to a bad commit
I
Hi Barto,
sorry for the late reply, and thanks for drilling down the exact
conditions.
I think we have some issues with the lack of the host lock vs error
handling, but I still don't undertand the details.
I've got a test patch for you that just adds the host lock back in a few
places while keeing the atomic_t. Can you try to reproduce with that
one?
When breaking an existing setup in software it's always the softwares
fault, btw..
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 994eb08..99b77f7 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -311,16 +311,16 @@ void scsi_device_unbusy(struct scsi_device *sdev)
struct scsi_target *starget = scsi_target(sdev);
unsigned long flags;
+ spin_lock_irqsave(shost->host_lock, flags);
atomic_dec(>host_busy);
if (starget->can_queue > 0)
atomic_dec(>target_busy);
if (unlikely(scsi_host_in_recovery(shost) &&
(shost->host_failed || shost->host_eh_scheduled))) {
- spin_lock_irqsave(shost->host_lock, flags);
scsi_eh_wakeup(shost);
- spin_unlock_irqrestore(shost->host_lock, flags);
}
+ spin_unlock_irqrestore(shost->host_lock, flags);
atomic_dec(>device_busy);
}
@@ -1504,6 +1504,8 @@ static inline int scsi_host_queue_ready(struct
request_queue *q,
if (scsi_host_in_recovery(shost))
return 0;
+ spin_lock_irq(shost->host_lock);
+
busy = atomic_inc_return(>host_busy) - 1;
if (atomic_read(>host_blocked) > 0) {
if (busy)
@@ -1527,21 +1529,19 @@ static inline int scsi_host_queue_ready(struct
request_queue *q,
/* We're OK to process the command, so we can't be starved */
if (!list_empty(>starved_entry)) {
- spin_lock_irq(shost->host_lock);
if (!list_empty(>starved_entry))
list_del_init(>starved_entry);
- spin_unlock_irq(shost->host_lock);
}
+ spin_unlock_irq(shost->host_lock);
return 1;
starved:
- spin_lock_irq(shost->host_lock);
if (list_empty(>starved_entry))
list_add_tail(>starved_entry, >starved_list);
- spin_unlock_irq(shost->host_lock);
out_dec:
atomic_dec(>host_busy);
+ spin_unlock_irq(shost->host_lock);
return 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 v5 2/2] tracing: add additional marks to signal very large time
Hi Steve and Byungchul,
On Wed, 19 Nov 2014 20:06:04 -0500, Steven Rostedt wrote:
> On Thu, 20 Nov 2014 09:15:35 +0900
> byungchul.p...@lge.com wrote:
>> -static unsigned long preempt_mark_thresh_us = 100;
>> +#undef MARK
>> +#define MARK(v, s) {.val = v, .sym = s}
>> +/* trace overhead mark */
>> +static const struct trace_mark {
>> +unsigned long long val; /* unit: nsec */
>> +charsym;
>> +} mark[] = {
>> +MARK(10ULL , '$'), /* 1 sec */
>> +MARK(100ULL , '#'), /* 1000 usecs */
>> +MARK(10ULL , '!'), /* 100 usecs */
>> +MARK(1ULL , '+'), /* 10 usecs */
>> +MARK(0ULL , ' '), /* 0 usecs */
>> +};
>> +#undef MARK
>> +
>> +char trace_find_mark(unsigned long long d)
>> +{
>> +int i;
>> +int size = ARRAY_SIZE(mark);
>> +
>> +for (i = 0; i < size; i++) {
>> +if (d >= mark[i].val)
>> +break;
>> +}
>> +
>> +return (i == size)? ' ' : mark[i].sym;
>
> Change this to:
>
> /* The break from loop must have been hit */
> if (WARN_ON_ONCE(i == size))
> return ' ';
I think it's impossible since it's always true that 'd >= 0'.
Thanks,
Namhyung
>
> return mark[i].sym;
>
> -- Steve
>
>
>> +}
>>
>> static int
>> lat_print_timestamp(struct trace_iterator *iter, u64 next_ts)
>> @@ -506,8 +532,7 @@ lat_print_timestamp(struct trace_iterator *iter, u64
>> next_ts)
>> return trace_seq_printf(
>> s, " %4lldus%c: ",
>> abs_ts,
>> -rel_ts > preempt_mark_thresh_us ? '!' :
>> - rel_ts > 1 ? '+' : ' ');
>> +trace_find_mark(rel_ts * NSEC_PER_USEC));
>> } else { /* !verbose && !in_ns */
>> return trace_seq_printf(s, " %4lld: ", abs_ts);
>> }
>> @@ -692,7 +717,7 @@ int register_ftrace_event(struct trace_event *event)
>> goto out;
>>
>> } else {
>> -
>> +
>> event->type = next_event_type++;
>> list = _event_list;
>> }
--
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: [f2fs-dev] [PATCH 1/3] f2fs: call flush_dcache_page when the page was updated
Hi Jaegeuk,
We should call flush_dcache_page before kunmap because the purpose of the cache
flush is to address aliasing problem related to virtual address.
On Wed, Nov 19, 2014 at 02:35:08PM -0800, Jaegeuk Kim wrote:
> Whenever f2fs updates mapped pages, it needs to call flush_dcache_page.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/dir.c| 7 ++-
> fs/f2fs/inline.c | 4 +++-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index 5a49995..312fbfc 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -287,8 +287,10 @@ void f2fs_set_link(struct inode *dir, struct
> f2fs_dir_entry *de,
> f2fs_wait_on_page_writeback(page, type);
> de->ino = cpu_to_le32(inode->i_ino);
> set_de_type(de, inode);
> - if (!f2fs_has_inline_dentry(dir))
> + if (!f2fs_has_inline_dentry(dir)) {
> kunmap(page);
> + flush_dcache_page(page);
> + }
> set_page_dirty(page);
> dir->i_mtime = dir->i_ctime = CURRENT_TIME;
> mark_inode_dirty(dir);
> @@ -366,6 +368,7 @@ static int make_empty_dir(struct inode *inode,
> do_make_empty_dir(inode, parent, );
>
> kunmap_atomic(dentry_blk);
> + flush_dcache_page(dentry_page);
>
> set_page_dirty(dentry_page);
> f2fs_put_page(dentry_page, 1);
> @@ -579,6 +582,7 @@ fail:
> clear_inode_flag(F2FS_I(dir), FI_UPDATE_DIR);
> }
> kunmap(dentry_page);
> + flush_dcache_page(dentry_page);
> f2fs_put_page(dentry_page, 1);
> return err;
> }
> @@ -661,6 +665,7 @@ void f2fs_delete_entry(struct f2fs_dir_entry *dentry,
> struct page *page,
> NR_DENTRY_IN_BLOCK,
> 0);
> kunmap(page); /* kunmap - pair of f2fs_find_entry */
> + flush_dcache_page(page);
> set_page_dirty(page);
>
> dir->i_ctime = dir->i_mtime = CURRENT_TIME;
> diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
> index f26fb87..8b7cc51 100644
> --- a/fs/f2fs/inline.c
> +++ b/fs/f2fs/inline.c
> @@ -45,8 +45,8 @@ void read_inline_data(struct page *page, struct page *ipage)
> src_addr = inline_data_addr(ipage);
> dst_addr = kmap_atomic(page);
> memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
> - flush_dcache_page(page);
> kunmap_atomic(dst_addr);
> + flush_dcache_page(page);
> SetPageUptodate(page);
> }
>
> @@ -107,6 +107,7 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn,
> struct page *page)
> dst_addr = kmap_atomic(page);
> memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
> kunmap_atomic(dst_addr);
> + flush_dcache_page(page);
> SetPageUptodate(page);
> no_update:
> /* write data page to try to make data consistent */
> @@ -358,6 +359,7 @@ static int f2fs_convert_inline_dir(struct inode *dir,
> struct page *ipage,
> NR_INLINE_DENTRY * F2FS_SLOT_LEN);
>
> kunmap_atomic(dentry_blk);
> + flush_dcache_page(page);
> SetPageUptodate(page);
> set_page_dirty(page);
>
> --
> 2.1.1
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751=/4140/ostg.clktrk
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] exynos: Move pmu driver to driver/soc folder and add exynos7 support
On Wed, Nov 19, 2014 at 1:34 PM, Kukjin Kim wrote:
> On 11/13/14 17:56, amit daniel kachhap wrote:
>> On Sat, Nov 8, 2014 at 6:46 PM, Amit Daniel Kachhap
>> wrote:
>>> This patch series[1 - 6] performs,
>>>
>>> 1) Moves pmu driver to driver/soc/samsung folder. Some discussion happened
>>> about
>>>this in the v1 version. Finally adding it in driver/soc folder as it too
>>> SoC
>>>specific and not a general driver. Entire discussion can be found here
>>> (A).
>>> 2) Registers this driver as MFD client driver. This will be used by clients
>>> like exynos pm
>>>sleep and pm domain driver.
>>> 3) Add exynos7 PMU support.
>>>
>>> Changes from V1:
>>> * Move pmu driver in driver/soc/samsung folder
>>> * Removed the power domain features. They will posted as a separate series.
>>> * Added exynos7 PMU support.
>>> * Link to v1 can be found here (B)
>>>
>>> This patch has dependency on following patches posted earlier by Pankaj (C),
>>> which is accepted by maintainer.
>>>
>>> Patch 6 was earlier posted by Abhilash (D) which has been reposted here
>>> with some
>>> extra changes.
>>>
>>> This complete patch series is rebased on linux-next.
>>>
>>> (A) - http://www.spinics.net/lists/linux-samsung-soc/msg38444.html
>>> (B) - http://www.spinics.net/lists/linux-samsung-soc/msg38442.html
>>> (C) - https://lkml.org/lkml/2014/10/6/581
>>> (D) - http://www.spinics.net/lists/arm-kernel/msg358230.html
>>>
>>> Amit Daniel Kachhap (6):
>>> ARM: EXYNOS: Move pmu specific header files under "linux/soc/samsung"
>>> drivers: soc: Add support for Exynos PMU driver
>>> drivers: soc: samsung: Fix a spelling mistake
>>> soc: samsung: exynos-pmu: Register exynos-pmu driver as a mfd driver
>>> driver: soc: exynos-pmu: Add an API to be called after wakeup
>>> drivers: soc: samsung: Add support for Exynos7 pmu
>>>
>>> .../devicetree/bindings/arm/samsung/pmu.txt|1 +
>>> arch/arm/mach-exynos/Makefile |2 +-
>>> arch/arm/mach-exynos/exynos.c |2 +-
>>> arch/arm/mach-exynos/mcpm-exynos.c |2 +-
>>> arch/arm/mach-exynos/platsmp.c |2 +-
>>> arch/arm/mach-exynos/pm.c |4 +-
>>> arch/arm/mach-exynos/regs-pmu.h| 335 ---
>>> arch/arm/mach-exynos/suspend.c |3 +-
>>> drivers/soc/Kconfig|1 +
>>> drivers/soc/Makefile |1 +
>>> drivers/soc/samsung/Kconfig| 19 +
>>> drivers/soc/samsung/Makefile |1 +
>>> .../pmu.c => drivers/soc/samsung/exynos-pmu.c | 471 ++-
>>
>> Hi Olof/Kukjin,
>>
>> I am not sure that driver/soc/samsung/* shall go in whose tree.
>> I am preparing the next version so if any comment from your side
>> please let me know.
>>
> In my opinion, it should be sent out via samsung tree because some PM
> related changes are in samsung tree and I'd like to apply exynos7 stuff
> in samsung tree as well... Please make sure your patches are based on
> top of samsung tree.
Thanks for clarification, Just posted the v3 version on top Samsung
for-next tree.
Regards,
Amit
>
> - Kukjin
>
>> Regards,
>> Amit
>>
>>> .../linux/soc/samsung}/exynos-pmu.h|6 +
>>> include/linux/soc/samsung/exynos-regs-pmu.h| 608
>>>
>>> 15 files changed, 1109 insertions(+), 349 deletions(-)
>>> delete mode 100644 arch/arm/mach-exynos/regs-pmu.h
>>> create mode 100644 drivers/soc/samsung/Kconfig
>>> create mode 100644 drivers/soc/samsung/Makefile
>>> rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (50%)
>>> rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h
>>> (78%)
>>> create mode 100644 include/linux/soc/samsung/exynos-regs-pmu.h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v8 2/6] arm64: ptrace: allow tracer to skip a system call
On 11/20/2014 02:13 PM, AKASHI Takahiro wrote:
On 11/20/2014 04:06 AM, Will Deacon wrote:
On Wed, Nov 19, 2014 at 08:46:19AM +, AKASHI Takahiro wrote:
On 11/18/2014 11:04 PM, Will Deacon wrote:
On Tue, Nov 18, 2014 at 01:10:34AM +, AKASHI Takahiro wrote:
+if (((int)regs->syscallno == -1) && (orig_syscallno == -1)) {
+/*
+ * user-issued syscall(-1):
+ * RESTRICTION: We always return ENOSYS whatever value is
+ * stored in x0 (a return value) at this point.
+ * Normally, with ptrace off, syscall(-1) returns -ENOSYS.
+ * With ptrace on, however, if a tracer didn't pay any
+ * attention to user-issued syscall(-1) and just let it go
+ * without a hack here, it would return a value in x0 as in
+ * other system call cases. This means that this system call
+ * might succeed and see any bogus return value.
+ * This should be definitely avoided.
+ */
+regs->regs[0] = -ENOSYS;
+}
I'm still really uncomfortable with this, and it doesn't seem to match what
arch/arm/ does either.
Yeah, I know but
as I mentioned before, syscall(-1) will be signaled on arm, and so we don't
have to care about a return value :)
What does x86 do?
On x86, syscall(-1) returns -ENOSYS if not traced, and we can change a return
value if traced.
Doesn't it also prevent a tracer from skipping syscall(-1)?
Syscall(-1) will return -ENOSYS whether or not a syscallno is explicitly
replaced with -1 by a tracer, and, in this sense, it is *skipped*.
Ok, but now userspace sees -ENOSYS for a skipped system call in that case,
whereas it would usually see whatever the trace put in x0, right?
Yes.
If you don't really like this behavior, how about this patch instead of my
[2/6] patch?
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 726b910..1ef57d0 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -668,8 +668,15 @@ ENDPROC(el0_svc)
* switches, and waiting for our parent to respond.
*/
__sys_trace:
+ cmp w8, #-1 // default errno for invalid
I needed to correct the code here:
w8 should be w26, thinking of compat syscalls.
+ b.ne1f // system call
+ mov x0, #-ENOSYS
+ str x0, [sp, #S_X0]
+1:
and this part might better be generalized like the following:
__sys_trace:
cmp w26, w25// cannot use x26 and x25 here
b.hs1f // scno > sc_nr || scno < 0
b 2f
1:
mov x0, #-ENOSYS
str x0, [sp, #S_X0]
2:
If you will be comfortable, I will submit a new patch soon.
-Takahiro AKASHI
mov x0, sp
bl syscall_trace_enter
+ cmp w0, #-1 // skip the syscall?
+ b.eq__sys_trace_return_skipped
adr lr, __sys_trace_return // return address
uxtwscno, w0// syscall number (possibly
new)
mov x1, sp // pointer to regs
@@ -684,6 +691,7 @@ __sys_trace:
__sys_trace_return:
str x0, [sp]// save returned x0
+__sys_trace_return_skipped:
mov x0, sp
bl syscall_trace_exit
b ret_to_user
With this change, I believe, syscall(-1) returns -ENOSYS by default whether
traced
or not, and still you can change a return value when tracing.
(But a drawback here is that a tracer will see -ENOSYS in x0 even at syscall
entry
for syscall(-1).)
-Takahiro AKASHI
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kconfig: Fix compiler warning
Fixes gcc warning when building linux-next:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
jump->offset = strlen(r->s);
^
scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here
struct jump_key *jump;
^
HOSTLD scripts/kconfig/conf
Moved the initialization of struct jump_key *jump outside the first
'if' branch so it can be available throughout the function.
Also uses the preferred pointer syntax for passing the size of a struct.
Tested on next-20141119.
Signed-off-by: Eddie Kovsky
---
scripts/kconfig/menu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index a26cc5d2a9b0..a728d23949e7 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -559,8 +559,8 @@ static void get_prompt_str(struct gstr *r, struct property
*prop,
if (location == NULL && accessible)
location = menu;
}
+ jump = xmalloc(sizeof(*jump));
if (head && location) {
- jump = xmalloc(sizeof(struct jump_key));
if (menu_is_visible(prop->menu)) {
/*
--
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 v3 5/5] arm: exynos: Select SOC_SAMSUNG config option
The config option SOC_SAMSUNG is needed to enable all soc samsung drivers inside driver/soc/samsung folder. Currently, this will be useful to enable exynos pmu driver which is moved to that folder. Signed-off-by: Amit Daniel Kachhap --- arch/arm/mach-exynos/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b9e3f1c..17880b6 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -25,6 +25,7 @@ menuconfig ARCH_EXYNOS select S5P_DEV_MFC select SRAM select MFD_SYSCON + select SOC_SAMSUNG help Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) -- 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 v3 4/5] drivers: soc: exynos-pmu: Add support for Exynos7
Add PMU settings for exynos7. This is required for future suspend-to-ram,
cpuidle and power domain support.
Note: In this patch some static declarations lines are over 80
characters per line for easy redability.
Reviewed-by: Pankaj Dubey
Signed-off-by: Eunseok Choi
Signed-off-by: Abhilash Kesavan
Signed-off-by: Amit Daniel Kachhap
---
.../devicetree/bindings/arm/samsung/pmu.txt|1 +
drivers/soc/samsung/exynos-pmu.c | 430 +++-
include/linux/soc/samsung/exynos-regs-pmu.h| 273 +
3 files changed, 701 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..67b2113 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+ - "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index f8896bc..62a320e 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -39,6 +40,7 @@ struct exynos_pmu_context {
static void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
+extern u32 exynos_get_eint_wake_mask(void);
static inline void pmu_raw_writel(u32 val, u32 offset)
{
@@ -494,6 +496,211 @@ static struct exynos_pmu_conf exynos5420_pmu_config[] = {
{ PMU_TABLE_END,},
};
+static const struct exynos_pmu_conf exynos7_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } } */
+ { EXYNOS7_ATLAS_CPU0_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CPUSEQUENCER_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_ATLAS_CPU1_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CPUSEQUENCER_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_ATLAS_CPU2_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CPUSEQUENCER_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_ATLAS_CPU3_SYS_PWR_REG, { 0x0, 0x0, 0x8
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CPUSEQUENCER_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_ATLAS_NONCPU_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_ATLAS_DBG_SYS_PWR_REG,{ 0x0, 0x0, 0x0
} },
+ { EXYNOS7_ATLAS_L2_SYS_PWR_REG, { 0x0, 0x0, 0x0
} },
+ { EXYNOS7_CLKSTOP_CMU_TOP_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_CLKRUN_CMU_TOP_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_RESET_CMU_TOP_SYS_PWR_REG,{ 0x1, 0x0, 0x0
} },
+ { EXYNOS7_RESET_CPUCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_CLKSTOP_CMU_MIF_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_CLKRUN_CMU_MIF_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_RESET_CMU_MIF_SYS_PWR_REG,{ 0x1, 0x1, 0x0
} },
+ { EXYNOS7_DDRPHY_DLLLOCK_SYS_PWR_REG, { 0x1, 0x1, 0x1
} },
+ { EXYNOS7_DISABLE_PLL_CMU_TOP_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_DISABLE_PLL_CMU_MIF_SYS_PWR_REG, { 0x1, 0x0, 0x0
} },
+ { EXYNOS7_TOP_BUS_SYS_PWR_REG, { 0x7, 0x0, 0x0
} },
+ { EXYNOS7_TOP_RETENTION_SYS_PWR_REG,{ 0x1, 0x0, 0x1
} },
+ { EXYNOS7_TOP_PWR_SYS_PWR_REG, { 0x3, 0x0, 0x3
} },
+ { EXYNOS7_TOP_BUS_MIF_SYS_PWR_REG, { 0x7, 0x0, 0x0
} },
+ { EXYNOS7_TOP_RETENTION_MIF_SYS_PWR_REG,{ 0x1, 0x0, 0x1
} },
+ {
Re: [PATCH] clk: rockchip: change hierarchy for some clocks
Mike, On Wed, Nov 19, 2014 at 6:55 PM, Mike Turquette wrote: > Quoting Doug Anderson (2014-11-04 13:32:49) >> Kever >> >> On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang >> wrote: >> > This patch change the hierarchy for some clocks, to met the following >> > bus hierarchy: >> > hclk_usb_peri is bus clock for >> > |- hclk_otg0, >> > |- hclk_host0, >> > |- hclk_host1, >> > |- hclk_hsic >> > >> > hclk_emem is bus clock for >> > |- hclk_nandc0 >> > |- hclk_nandc1 >> > >> > hclk_mem is bus clock for >> > |- hclk_sdmmc >> > |- hclk_sdio0 >> > |- hclk_sdio1 >> > |- hclk_emmc >> >> So as I understand it the "parent" clocks aren't really parents but >> are actually peer clocks. That is if "hclk_usb_peri" is gated >> "hclk_otg0" continues to run. ...but the OTG periperhal is useless >> without "hclk_usb_peri" also being enabled. >> >> There doesn't seem to be any real downside to modeling thing as you >> have done it, though it's not quite a true representation of the >> world. A slightly more true representation would be to make it so >> that whenever "hclk_otg0" is enabled/disabled that it makes an >> enable/disable call to "hclk_usb_peri". I think you'd have to >> subclass the gate clock and patch your stuff in the "enable" function. >> >> I'm personally OK with things landing as you've described it (I can >> see no downside), but it seems like this at least deserves a comment >> (either in the code or the commit message). >> >> If Mike T. thinks that we should use a more truthful model or if >> there's some better way to express this, you should of course listen >> to him and not to me. > > I'm coming back to this thread sort of late (V2 is posted but the > discussion is here in V1). I strongly believe that we should model the > hardware closely, unless there is a convincing reason to do otherwise. > That makes it more maintainable and more debuggable (e.g. the code > matches the data sheet). > > Seems like there isn't a reason to make these clocks follow a > parent/child relationship except for convenience? > > To clarify further, the requirement for enabling/maintaining the clocks > isn't really about the clocks themselves, but about the downstream IP > that consumes the clocks, right? In that case it is the downstream > driver's responsibility to enable/disable these clocks to spec, not the > clock driver's job to hide these details. I don't think it's the downstream driver's job in this case. Let me see if I can describe it as I understand it: 1. We've got 4 different USB IP blocks _plus_ an IP block that all 4 blocks are connected to that helps interconnect them to the rest of the system. 2. The USB IP blocks are not accessible unless the interconnect is clocked. 3. The Interconnect's clock is not truly the parent of the USB IP blocks. You could maybe draw it like this (assumes fixed width) clk_interconnect | +--+ +-+ -clk_usb1---| USB1 |==bus==| | +--+ | | +--+ | | -clk_usb2---| USB2 |==bus==| inter- |==bus== +--+ | connect | +--+ | | -clk_usb3---| USB3 |==bus==| | +--+ +-+ The USB driver shouldn't need to know that there is an interconnect hooking up the USB block to the rest of the system. It's an artifact of the SoC. The USB driver should just turn on its bus clock. In a pure sense we should have it so that if we turn on any of clk_usb1, clk_usb2, or clk_usb3 we should tun on the interconnect. ...but we shouldn't describe them as parents because in the hardware there's no real parent child relationship. ...but since we don't care about the rate of the clk_interconnect (we can't control it separately) and if we list clk_usb1, clk_usb2, and clk_usb3 as children of clk_interconnect we magically get everything we want... -Doug -- 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 3/5] driver: soc: exynos-pmu: Add an API to be called after wakeup
This patch adds an API exynos_sys_powerup_conf to be called after system sleep
wakeup. This will useful for exynos7 SoC to perform resume related
initialisations. This is similar to currently existing API
exynos_sys_powerdown_conf.
Reviewed-by: Pankaj Dubey
Signed-off-by: Amit Daniel Kachhap
---
drivers/soc/samsung/exynos-pmu.c |9 +
include/linux/soc/samsung/exynos-pmu.h |1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index aa43e04..f8896bc 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -29,6 +29,7 @@ struct exynos_pmu_data {
void (*pmu_init)(void);
void (*powerdown_conf)(enum sys_powerdown);
+ void (*powerup_conf)(enum sys_powerdown);
};
struct exynos_pmu_context {
@@ -637,6 +638,14 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
}
}
+void exynos_sys_powerup_conf(enum sys_powerdown mode)
+{
+ const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
+
+ if (pmu_data->powerup_conf)
+ pmu_data->powerup_conf(mode);
+}
+
static void exynos5250_pmu_init(void)
{
unsigned int value;
diff --git a/include/linux/soc/samsung/exynos-pmu.h
b/include/linux/soc/samsung/exynos-pmu.h
index a2ab0d5..b497712 100644
--- a/include/linux/soc/samsung/exynos-pmu.h
+++ b/include/linux/soc/samsung/exynos-pmu.h
@@ -20,5 +20,6 @@ enum sys_powerdown {
};
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void exynos_sys_powerup_conf(enum sys_powerdown mode);
#endif /* __EXYNOS_PMU_H */
--
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 v3 1/5] ARM: EXYNOS: Move pmu specific header files under "linux/soc/samsung"
Moving Exynos PMU specific header file into "include/linux/soc/samsung"
thus updated affected files under "mach-exynos" to use new location of
these header files.
Signed-off-by: Pankaj Dubey
Signed-off-by: Amit Daniel Kachhap
---
arch/arm/mach-exynos/exynos.c |2 +-
arch/arm/mach-exynos/mcpm-exynos.c |2 +-
arch/arm/mach-exynos/platsmp.c |2 +-
arch/arm/mach-exynos/pm.c |4 ++--
arch/arm/mach-exynos/pmu.c |6 ++
arch/arm/mach-exynos/suspend.c |4 ++--
.../linux/soc/samsung}/exynos-pmu.h|0
.../linux/soc/samsung/exynos-regs-pmu.h|0
8 files changed, 9 insertions(+), 11 deletions(-)
rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (100%)
rename arch/arm/mach-exynos/regs-pmu.h =>
include/linux/soc/samsung/exynos-regs-pmu.h (100%)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8f638ad..63d0450 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,7 +30,6 @@
#include "common.h"
#include "mfc.h"
-#include "regs-pmu.h"
#include "regs-sys.h"
void __iomem *pmu_base_addr;
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index b0d3c2e..c5e17b0 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -16,12 +16,12 @@
#include
#include
#include
+#include
#include
#include
#include
-#include "regs-pmu.h"
#include "common.h"
#define EXYNOS5420_CPUS_PER_CLUSTER4
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 7a1ebfe..d6e7f49 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,7 +31,6 @@
#include
#include "common.h"
-#include "regs-pmu.h"
extern void exynos4_secondary_startup(void);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 86f3ecd..1a981e0 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -26,8 +28,6 @@
#include
#include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
#include "regs-sys.h"
static inline void __iomem *exynos_boot_vector_addr(void)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 6c8a76d..aa43e04 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -13,10 +13,8 @@
#include
#include
#include
-
-
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
+#include
+#include
#define PMU_TABLE_END (-1U)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f8e7dcd..80cf7ac 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -33,9 +35,7 @@
#include
#include "common.h"
-#include "regs-pmu.h"
#include "regs-sys.h"
-#include "exynos-pmu.h"
#define S5P_CHECK_SLEEP 0x0BAD
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/include/linux/soc/samsung/exynos-pmu.h
similarity index 100%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to include/linux/soc/samsung/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/regs-pmu.h
b/include/linux/soc/samsung/exynos-regs-pmu.h
similarity index 100%
rename from arch/arm/mach-exynos/regs-pmu.h
rename to include/linux/soc/samsung/exynos-regs-pmu.h
--
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 v3 2/5] drivers: soc: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from "arm/mach-exynos" to "drivers/soc/samsung". This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC support, there is a need of this PMU driver in driver/* folder. This driver uses existing DT binding information and there should be no functionality change in the supported platforms. Signed-off-by: Pankaj Dubey Signed-off-by: Amit Daniel Kachhap --- arch/arm/mach-exynos/Makefile |2 +- drivers/soc/Kconfig|1 + drivers/soc/Makefile |1 + drivers/soc/samsung/Kconfig| 20 drivers/soc/samsung/Makefile |1 + .../pmu.c => drivers/soc/samsung/exynos-pmu.c |0 6 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%) diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index bcefb54..b91b382 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree) # Core -obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o +obj-$(CONFIG_ARCH_EXYNOS) += exynos.o exynos-smc.o firmware.o obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o obj-$(CONFIG_PM_SLEEP) += suspend.o diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 76d6bd4..90f33b9 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -3,5 +3,6 @@ menu "SOC (System On Chip) specific Drivers" source "drivers/soc/qcom/Kconfig" source "drivers/soc/ti/Kconfig" source "drivers/soc/versatile/Kconfig" +source "drivers/soc/samsung/Kconfig" endmenu diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d..44d220d 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM) += qcom/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ obj-$(CONFIG_PLAT_VERSATILE) += versatile/ +obj-$(CONFIG_ARCH_EXYNOS) += samsung/ diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig new file mode 100644 index 000..a424ebc --- /dev/null +++ b/drivers/soc/samsung/Kconfig @@ -0,0 +1,20 @@ +# +# SAMSUNG SOC drivers +# +menuconfig SOC_SAMSUNG + bool "Samsung SOC drivers support" + +if SOC_SAMSUNG + +config EXYNOS_PMU + bool "Support Exynos Power Management Unit" + depends on ARCH_EXYNOS + default y + help + Exynos SoC have Power Management Unit (PMU) which controls power and + operation state of various components in Exynos SoC. This driver + provides implementation of PMU driver and provides various + functionality like initialisation and transition to various low power + states. + +endif #SOC_SAMSUNG diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile new file mode 100644 index 000..5a879c6 --- /dev/null +++ b/drivers/soc/samsung/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/soc/samsung/exynos-pmu.c similarity index 100% rename from arch/arm/mach-exynos/pmu.c rename to drivers/soc/samsung/exynos-pmu.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 v3 0/5] exynos: Move pmu driver to driver/soc folder and add exynos7 support
This patch series [1 - 5] performs,
1) Moves pmu driver to driver/soc/samsung folder. This is needed as exynos7 is
an arm64 based platform and hence PMU driver should be in driver folder.
Some discussion happened about this in the v1 version. Finally adding it in
driver/soc folder as it too SoC specific and not a general driver.
Entire discussion can be found here (A).
2) Add exynos7 PMU support.
3) Enables the driver for 32bit arm exynos platforms.
Changes from V2:
* Added review comment changes suggested by Pankaj.
* Removed mfd client support in this patch series. This will be added later in
the power domain patch series.
* Link to V2 can be found here (B)
Changes from V1:
* Move pmu driver in driver/soc/samsung folder
* Removed the power domain features. They will posted as a separate series.
* Added exynos7 PMU support.
* Link to v1 can be found here (A)
This complete patch series is rebased on Kukjin for-next tree.
(A) - http://www.spinics.net/lists/linux-samsung-soc/msg38442.html
(B) - http://www.spinics.net/lists/arm-kernel/msg375910.html
Amit Daniel Kachhap (5):
ARM: EXYNOS: Move pmu specific header files under "linux/soc/samsung"
drivers: soc: Add support for Exynos PMU driver
driver: soc: exynos-pmu: Add an API to be called after wakeup
drivers: soc: exynos-pmu: Add support for Exynos7
arm: exynos: Select SOC_SAMSUNG config option
.../devicetree/bindings/arm/samsung/pmu.txt|1 +
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/Makefile |2 +-
arch/arm/mach-exynos/exynos.c |2 +-
arch/arm/mach-exynos/mcpm-exynos.c |2 +-
arch/arm/mach-exynos/platsmp.c |2 +-
arch/arm/mach-exynos/pm.c |4 +-
arch/arm/mach-exynos/suspend.c |4 +-
drivers/soc/Kconfig|1 +
drivers/soc/Makefile |1 +
drivers/soc/samsung/Kconfig| 20 +
drivers/soc/samsung/Makefile |1 +
.../pmu.c => drivers/soc/samsung/exynos-pmu.c | 445 +++-
.../linux/soc/samsung}/exynos-pmu.h|1 +
.../linux/soc/samsung/exynos-regs-pmu.h| 273
15 files changed, 745 insertions(+), 15 deletions(-)
create mode 100644 drivers/soc/samsung/Kconfig
create mode 100644 drivers/soc/samsung/Makefile
rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (63%)
rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (89%)
rename arch/arm/mach-exynos/regs-pmu.h =>
include/linux/soc/samsung/exynos-regs-pmu.h (63%)
--
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 3.17 000/141] 3.17.4-stable review
On 11/19/2014 12:50 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.17.4 release. There are 141 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 21 20:51:28 UTC 2014. Anything received after that time might be too late. Build results: total: 133 pass: 132 fail: 1 Failed builds: avr32:atngw100mkii_evklcd101_defconfig Qemu test results: total: 30 pass: 30 fail: 0 Details at http://server.roeck-us.net:8010/builders. Guenter -- 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.14 000/122] 3.14.25-stable review
On 11/19/2014 12:50 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.25 release. There are 122 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 21 20:51:52 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0 Details at http://server.roeck-us.net:8010/builders. Guenter -- 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.10 00/70] 3.10.61-stable review
On 11/19/2014 12:51 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.61 release. There are 70 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 21 20:51:58 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu test results: total: 27 pass: 27 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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 net] virtio-net: validate features during probe
On 11/19/2014 05:39 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2014 at 05:33:26PM +0800, Jason Wang wrote:
>> On 11/19/2014 04:59 PM, Michael S. Tsirkin wrote:
>>> On Wed, Nov 19, 2014 at 02:35:39PM +0800, Jason Wang wrote:
This patch validates feature dependencies during probe and fail the probing
if a dependency is missed. This fixes the issues of hitting BUG()
when qemu fails to advertise features correctly. One example is booting
guest with ctrl_vq=off through qemu.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Cornelia Huck
Cc: Wanlong Gao
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 93
1 file changed, 93 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..4a0ad46 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1673,6 +1673,95 @@ static const struct attribute_group
virtio_net_mrg_rx_group = {
};
#endif
+static int virtnet_validate_features(struct virtio_device *dev,
+ unsigned int *table,
+ int table_size,
+ unsigned int feature)
+{
+ int i;
+
+ if (!virtio_has_feature(dev, feature)) {
+ for (i = 0; i < table_size; i++) {
+ unsigned int f = table[i];
+
+ if (virtio_has_feature(dev, f)) {
+ dev_err(>dev,
+ "buggy hyperviser: feature 0x%x was
advertised but its dependency 0x%x was not",
>>> This line's way too long.
>> Yes. (Anyway it pass checkpatch.pl since it forbids quoted string to be
>> split)
[...]
+
static int virtnet_probe(struct virtio_device *vdev)
{
int i, err;
@@ -1680,6 +1769,10 @@ static int virtnet_probe(struct virtio_device *vdev)
struct virtnet_info *vi;
u16 max_queue_pairs;
+ err = virtnet_check_features(vdev);
+ if (err)
+ return -EINVAL;
+
/* Find if host supports multiqueue virtio_net device */
err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
struct virtio_net_config,
>>> The API seems too complex, and you still had to open-code ECN logic.
>>> Just open-code most of it.
>> Yes, the ECN could be done through the same way as ctrl_vq did.
>>
>> How about move those checking into virtio core by just letting device
>> export its dependency table?
> So far we only have this for net, let's not add
> one-off APIs.
>
>>> You can use a helper macro to output a
>>> friendly message without code duplication.
>>> For example like the below (completely untested)?
>>>
>>>
>>> I would also like to split things: dependencies on
>>> VIRTIO_NET_F_CTRL_VQ might go into this kernel,
>>> since they help fix BUG.
>>>
>>> Others should wait since they don't fix any crashes, and there's a small
>>> chance of a regression for some hypervisor in the field.
>> Probably ok but not sure, since the rest features are all related to
>> csum and offloading, we are in fact depends on network core to fix them.
> Well it does fix them so ... there's no bug, is there?
>
No.
>>> -->
>>>
>>> virtio-net: friendlier handling of misconfigured hypervisors
>>>
>>> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
>>> is not set but one of features depending on it is.
>>> That's not a friendly way to report errors to
>>> hypervisors.
>>> Let's check, and fail probe instead.
>>>
>>> Signed-off-by: Michael S. Tsirkin
>>>
>>> ---
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 26e1330..7a7d1a3 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -1673,6 +1673,21 @@ static const struct attribute_group
>>> virtio_net_mrg_rx_group = {
>>> };
>>> #endif
>>>
>>> +bool __virtnet_fail_on_feature(struct virtio_device *vdev, unsigned int
>>> fbit,
>>> + const char *fname)
>>> +{
>>> + if (!virtio_has_feature(vdev, fbit))
>>> + return false;
>>> +
>>> +dev_err(>dev, "missing requirements for feature bit %d: %s\n",
>>> + fbit, fname);
>>> +
>>> + return true;
>>> +}
>>> +
>>> +#define VIRTNET_FAIL_ON(vdev, fbit) \
>>> + __virtnet_fail_on_feature(vdev, fbit, #fbit)
>>> +
>>> static int virtnet_probe(struct virtio_device *vdev)
>>> {
>>> int i, err;
>>> @@ -1680,6 +1695,14 @@ static int virtnet_probe(struct virtio_device *vdev)
>>> struct virtnet_info *vi;
>>> u16 max_queue_pairs;
>>>
>>> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
>>> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX) ||
>>> +VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN) ||
>>> +VIRTNET_FAIL_ON(vdev,
gfs2: gfs2_dir_get_hash_table(): avoiding deferred vfree() is easy here...
vfree() is allowed under spinlock these days, but it's cheaper when
it doesn't step into deferred case and here it's very easy to avoid.
Signed-off-by: Al Viro
---
fs/gfs2/dir.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index c247fed..c5a34f0 100644
--- a/fs/gfs2/dir.c
+++ b/fs/gfs2/dir.c
@@ -370,11 +370,12 @@ static __be64 *gfs2_dir_get_hash_table(struct gfs2_inode
*ip)
}
spin_lock(>i_lock);
- if (ip->i_hash_cache)
- kvfree(hc);
- else
+ if (likely(!ip->i_hash_cache)) {
ip->i_hash_cache = hc;
+ hc = NULL;
+ }
spin_unlock(>i_lock);
+ kvfree(hc);
return ip->i_hash_cache;
}
--
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/
gfs2: use kvfree() instead of open-coding it
Signed-off-by: Al Viro
---
fs/gfs2/dir.c | 40
fs/gfs2/quota.c |9 ++---
2 files changed, 10 insertions(+), 39 deletions(-)
diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index 5d4261f..c247fed 100644
--- a/fs/gfs2/dir.c
+++ b/fs/gfs2/dir.c
@@ -365,22 +365,15 @@ static __be64 *gfs2_dir_get_hash_table(struct gfs2_inode
*ip)
ret = gfs2_dir_read_data(ip, hc, hsize);
if (ret < 0) {
- if (is_vmalloc_addr(hc))
- vfree(hc);
- else
- kfree(hc);
+ kvfree(hc);
return ERR_PTR(ret);
}
spin_lock(>i_lock);
- if (ip->i_hash_cache) {
- if (is_vmalloc_addr(hc))
- vfree(hc);
- else
- kfree(hc);
- } else {
+ if (ip->i_hash_cache)
+ kvfree(hc);
+ else
ip->i_hash_cache = hc;
- }
spin_unlock(>i_lock);
return ip->i_hash_cache;
@@ -396,10 +389,7 @@ void gfs2_dir_hash_inval(struct gfs2_inode *ip)
{
__be64 *hc = ip->i_hash_cache;
ip->i_hash_cache = NULL;
- if (is_vmalloc_addr(hc))
- vfree(hc);
- else
- kfree(hc);
+ kvfree(hc);
}
static inline int gfs2_dirent_sentinel(const struct gfs2_dirent *dent)
@@ -1168,10 +1158,7 @@ fail:
gfs2_dinode_out(dip, dibh->b_data);
brelse(dibh);
out_kfree:
- if (is_vmalloc_addr(hc2))
- vfree(hc2);
- else
- kfree(hc2);
+ kvfree(hc2);
return error;
}
@@ -1302,14 +1289,6 @@ static void *gfs2_alloc_sort_buffer(unsigned size)
return ptr;
}
-static void gfs2_free_sort_buffer(void *ptr)
-{
- if (is_vmalloc_addr(ptr))
- vfree(ptr);
- else
- kfree(ptr);
-}
-
static int gfs2_dir_read_leaf(struct inode *inode, struct dir_context *ctx,
int *copied, unsigned *depth,
u64 leaf_no)
@@ -1393,7 +1372,7 @@ static int gfs2_dir_read_leaf(struct inode *inode, struct
dir_context *ctx,
out_free:
for(i = 0; i < leaf; i++)
brelse(larr[i]);
- gfs2_free_sort_buffer(larr);
+ kvfree(larr);
out:
return error;
}
@@ -2004,10 +1983,7 @@ out_rlist:
gfs2_rlist_free();
gfs2_quota_unhold(dip);
out:
- if (is_vmalloc_addr(ht))
- vfree(ht);
- else
- kfree(ht);
+ kvfree(ht);
return error;
}
diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
index 64b29f7..c8b148b 100644
--- a/fs/gfs2/quota.c
+++ b/fs/gfs2/quota.c
@@ -1360,13 +1360,8 @@ void gfs2_quota_cleanup(struct gfs2_sbd *sdp)
gfs2_assert_warn(sdp, !atomic_read(>sd_quota_count));
- if (sdp->sd_quota_bitmap) {
- if (is_vmalloc_addr(sdp->sd_quota_bitmap))
- vfree(sdp->sd_quota_bitmap);
- else
- kfree(sdp->sd_quota_bitmap);
- sdp->sd_quota_bitmap = NULL;
- }
+ kvfree(sdp->sd_quota_bitmap);
+ sdp->sd_quota_bitmap = NULL;
}
static void quotad_error(struct gfs2_sbd *sdp, const char *msg, int error)
--
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 v2] clk: Propagate prepare and enable when reparenting orphans
Mike, On Wed, Nov 19, 2014 at 6:30 PM, Mike Turquette wrote: > Quoting Doug Anderson (2014-11-07 17:06:58) >> With the existing code, if you find a parent for an orhpan that has >> already been prepared / enabled, you won't enable the parent. That >> can cause later problems since the clock tree isn't in a consistent >> state. Fix by propagating the prepare and enable. >> >> NOTE: this does bring up the question about whether the enable of the >> orphan actually made sense. If the orphan's parent wasn't enabled by >> default (by the bootloader or the default state of the hardware) then >> the original enable of the orphan probably didn't do what the caller >> though it would. Some users of the orphan might have preferred an >> EPROBE_DEFER be returned until we had a full path to a root clock. >> This patch doesn't address those concerns and really just syncs up the >> state. > > -ECANOFWORMS > > I'm thinking about this patch but I haven't quite made up my mind. It is > reasonable, but also some nice kind of error might be preferable when > preparing/enabling an orphaned clock. > > Under what conditions might a clock be orphaned? An obvious example is > just bad luck during the thundering herd of clock registrations from a > driver. In this case deferring the probe might be a good idea. > > However what about the case where a loadable module provides the parent > clock? It might be a long time before the orphan clocks gets picked up > from the orphanage. Is deferring probe the right thing here as well? I will defer to your wisdom here. I agree that these are the two primary solutions and I've picked one, but I have no idea which will be more of a PITA in the long run. Note: I'm not sure that anyone expects EPROBE_DEFER to be returned from a clk_enable() (do they?). It almost seems like the right answer is to fail to allow anyone to clk_get() any clock that doesn't have a path to root. I will say that without this patch or the EPROBE_DEFER solution we have a clear bug. You can get into a situation where a clock is enabled/prepared but its parent isn't. -Doug -- 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/
