RE: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC
Hello, On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote: > KyongHo Cho wrote @ Wed, 22 Aug 2012 14:47:00 +0200: > > > vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic > > context. > > Right. > > I've been thinking that kzalloc() may be enough here, since > vzalloc() was introduced to avoid allocation failure for big chunk of > memory, but I think that it's unlikely that the number of page array > can be so big. So I propose to drop vzalloc() here, and just simply to > use kzalloc only as below(*1). We already had a discussion about this, so I don't think it makes much sense to change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not be considered a problem for atomic allocations, because no sane driver will try to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call such try a serious bug, which we should not care here. Best regards -- Marek Szyprowski Samsung Poland R Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] powerpc: Uprobes port to powerpc
On Thu, Aug 23, 2012 at 02:28:20PM +1000, Michael Ellerman wrote:
> On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
> > From: Ananth N Mavinakayanahalli
> >
> > This is the port of uprobes to powerpc. Usage is similar to x86.
>
> Hi Ananth,
>
> Excuse my ignorance of uprobes, some comments inline ...
Thanks for the review Michael!
> > [root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
> > Added new event:
> > probe_libc:malloc(on 0xb4860)
> >
> > You can now use it in all perf tools, such as:
> >
> > perf record -e probe_libc:malloc -aR sleep 1
>
> Is there a test suite for any of this?
We don't have a formal testsuite yet, but the usual way of testing it is
to run kernbench while registering/unregistering a bunch of probes
periodically.
...
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
> > USA.
> > + *
> > + * Copyright (C) IBM Corporation, 2007-2012
>
> The lawyers say we shouldn't use (C).
Will remove that.
> Is it really copyright IBM 2007-2012? Or is that because you copied
> another header?
The later. This is adapted from the x86 version.
> > +typedef unsigned int uprobe_opcode_t;
>
> I'd prefer u32.
OK. Will change.
> It would be nice if someone could consolidate this with kprobe_opcode_t.
Thats on the TODO after the uprobes code stabilizes further.
I am wondering which file would be appropriate? We could either
consolidate a bunch of these into asm/kdebug.h or asm/ptrace.h. Any
preference/suggestion?
> > +#define MAX_UINSN_BYTES4
> > +#define UPROBE_XOL_SLOT_BYTES (MAX_UINSN_BYTES)
> > +
> > +#define UPROBE_SWBP_INSN 0x7fe8
>
> This is just "trap" ?
Yes. But since its referred to in arch agnostic code too, we'd have to alias
it thus.
> > +#define UPROBE_SWBP_INSN_SIZE 4 /* swbp insn size in bytes */
> > +
> > +#define IS_TW(instr) (((instr) & 0xfc0007fe) == 0x7c08)
> > +#define IS_TD(instr) (((instr) & 0xfc0007fe) == 0x7c88)
> > +#define IS_TDI(instr) (((instr) & 0xfc00) == 0x0800)
> > +#define IS_TWI(instr) (((instr) & 0xfc00) == 0x0c00)
> > +
> > +#define is_trap(instr) (IS_TW(instr) || IS_TD(instr) || \
> > + IS_TWI(instr) || IS_TDI(instr))
>
> These seem to be duplicated in kprobes.h, can we consolidate them.
Yes, similar to the opcode_t types above.
> > +struct arch_uprobe {
> > + u8 insn[MAX_UINSN_BYTES];
> > +};
>
> Why not uprobe_opcode_t insn ?
I had a similar discussion with Srikar while doing the port, but he has
reasons for this...
...
> > void do_notify_resume(struct pt_regs *regs, unsigned long
> > thread_info_flags)
> > {
> > + if (thread_info_flags & _TIF_UPROBE) {
> > + clear_thread_flag(TIF_UPROBE);
> > + uprobe_notify_resume(regs);
> > + }
>
> Presumably this ordering is crucial, ie. uprobes before signals.
Correct!
...
> > +#define UPROBE_TRAP_NR UINT_MAX
>
> In the comments below you talk about -1 a few times, but you actually
> mean UINT_MAX.
Correct. I will fix those references.
> > +/**
> > + * arch_uprobe_analyze_insn
>
> Analyze what about the instruction?
Depends on the architecture. On x86, we need to verify if the address is
at an instruction boundary, and if the instruction can be probed at all.
On powerpc, we have an easier time. We just validate the address is
aligned at instruction boundary and flag if the instruction at the
address is a trap variant.
> > + * @mm: the probed address space.
> > + * @arch_uprobe: the probepoint information.
> > + * @addr: vaddr to probe.
> > + * Return 0 on success or a -ve number on error.
> > + */
> > +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> > *mm, unsigned long addr)
> > +{
> > + unsigned int insn;
> > +
> > + if (addr & 0x03)
> > + return -EINVAL;
> > +
> > + memcpy(, auprobe->insn, MAX_UINSN_BYTES);
>
> We shouldn't need to use memcpy, we know it's a u32.
OK. Right now, its u8 insn[4], so I did this to be 'correct'. But I
agree we can just do an assignment.
> > + if (is_trap(insn))
> > + return -ENOTSUPP;
>
> A comment saying why we can't handle this would be nice.
Will add.
> > + return 0;
> > +}
>
>
> I am probably missing something, but why do we need to execute out of
> line?
I think Srikar answered that.
...
> > +/* callback routine for handling exceptions. */
> > +int arch_uprobe_exception_notify(struct notifier_block *self, unsigned
> > long val, void *data)
> > +{
> > + struct die_args *args = data;
> > + struct pt_regs *regs = args->regs;
> > +
> > + /* We are only interested in userspace traps */
> > + if (regs && !user_mode(regs))
> > + return NOTIFY_DONE;
>
> Do we ever get
Re: [PATCH v2] net: add new QCA alx ethernet driver
From: Date: Tue, 21 Aug 2012 00:42:29 +0800 > +config ALX_DEBUGFS > + bool "Qualcomm Atheros debugging interface" > + depends on ALX && DEBUG_FS > + ---help--- > + This option adds ability to debug and test L1F. It can > + support Qualcomm Atheros tools, including diagnostic, memcfg > + and SWOI. Sorry, no vendor specific interfaces, you have to remove this. Anything diagnostic you think is special and unique to your piece of hardware, is almost certainly not, and therefore needs to exist as a generic ethtool or similar interface that other drivers can plug into, not just your's. Driver specific interfaces suck for several reasons, not least of which is the fact that it leads to a terrible user experience. The same task must be done in different ways depending upon what piece of networking hardware and device driver are being used, which the user should never need to know. This is why we require that portable, sane, interfaces are added to ethtool for driver diagnostics. That way users can perform a task in the same way regardless of what hardware and driver are underneath. -- 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 2/3] power_supply: add new lp8788 charger driver
On Tue, Aug 14, 2012 at 02:32:50AM +, Kim, Milo wrote:
> Patch v3.
Thanks for the driver! It looks great, mostly cosmetic comments
down below.
> (a) use irq domain for handling charger interrupts
> (b) use scaled adc value rather than raw value
> : replace iio_read_channel_raw() with iio_read_channel_scale()
> (c) clean up charger-platform-data code
> (d) remove goto statement in _probe()
> (e) name change : from lp8788_unregister_psy() to lp8788_psy_unregister()
Only changelog? No description for the driver? Nothing exciting to
tell us about the hardware, e.g. why it's so great? :-)
> Signed-off-by: Milo(Woogyom) Kim
> ---
[...]
> @@ -0,0 +1,785 @@
> +/*
> + * TI LP8788 MFD - battery charger driver
> + *
> + * Copyright 2012 Texas Instruments
> + *
> + * Author: Milo(Woogyom) Kim
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* register address */
> +#define LP8788_CHG_STATUS0x07
> +#define LP8788_CHG_IDCIN 0x13
> +#define LP8788_CHG_IBATT 0x14
> +#define LP8788_CHG_VTERM 0x15
> +#define LP8788_CHG_EOC 0x16
> +
> +/* mask/shift bits */
> +#define LP8788_CHG_INPUT_STATE_M 0x03/* Addr 07h */
> +#define LP8788_CHG_STATE_M 0x3C
> +#define LP8788_CHG_STATE_S 2
> +#define LP8788_NO_BATT_M BIT(6)
> +#define LP8788_BAD_BATT_MBIT(7)
> +#define LP8788_CHG_IBATT_M 0x1F/* Addr 14h */
> +#define LP8788_CHG_VTERM_M 0x0F/* Addr 15h */
> +#define LP8788_CHG_EOC_LEVEL_M 0x30/* Addr 16h */
> +#define LP8788_CHG_EOC_LEVEL_S 4
> +#define LP8788_CHG_EOC_TIME_M0x0E
> +#define LP8788_CHG_EOC_TIME_S1
> +#define LP8788_CHG_EOC_MODE_MBIT(0)
> +
> +#define CHARGER_NAME "charger"
> +#define BATTERY_NAME "main_batt"
> +
> +#define LP8788_CHG_START 0x11
> +#define LP8788_CHG_END 0x1C
> +
> +#define BUF_SIZE 40
This is in the global namespace, although not exported, true.
Anyways, seems way too generic. I'd prepend it with LP8788_, or
at least LP_ for short.
> +#define LP8788_ISEL_MAX 23
> +#define LP8788_ISEL_STEP 50
> +#define LP8788_VTERM_MIN 4100
> +#define LP8788_VTERM_STEP25
> +#define MAX_BATT_CAPACITY100
> +#define MAX_CHG_IRQS 11
ditto.
> +
> +enum lp8788_charging_state {
> + OFF,
> + WARM_UP,
> + LOW_INPUT = 0x3,
> + PRECHARGE,
> + CC,
> + CV,
ditto.
> + MAINTENANCE,
> + BATTERY_FAULT,
> + SYSTEM_SUPPORT = 0xC,
> + HIGH_CURRENT = 0xF,
> + MAX_CHG_STATE,
> +};
> +
> +enum lp8788_charger_adc_sel {
> + VBATT,
> + BATT_TEMP,
> + NUM_CHG_ADC,
> +};
> +
> +enum lp8788_charger_input_state {
> + SYSTEM_SUPPLY = 1,
> + FULL_FUNCTION,
ditto ditto..
> +};
> +
> +/*
> + * struct lp8788_chg_irq
> + * @which: lp8788 interrupt id
> + * @virq : Linux IRQ number from irq_domain
> + */
> +struct lp8788_chg_irq {
> + enum lp8788_int_id which;
> + int virq;
> +};
[...]
> +static inline bool lp8788_is_valid_charger_register(u8 addr)
> +{
> + return (addr >= LP8788_CHG_START && addr <= LP8788_CHG_END);
No need for the outermost parenthesis.
> +}
> +
> +static int lp8788_update_charger_params(struct lp8788_charger *pchg)
> +{
> + struct lp8788 *lp = pchg->lp;
> + struct lp8788_charger_platform_data *pdata = pchg->pdata;
> + struct lp8788_chg_param *param;
> + int i, ret;
One declaration per line, please. I.e.
int i;
int ret;
> +
> + if (!pdata || !pdata->chg_params) {
> + dev_info(lp->dev, "skip updating charger parameters\n");
> + return 0;
> + }
[...]
> +static ssize_t lp8788_show_eoc_time(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct lp8788_charger *pchg = dev_get_drvdata(dev);
> + char *stime[] = { "400ms", "5min", "10min", "15min",
> + "20min", "25min", "30min" "No timeout" };
> + u8 val;
> +
> + lp8788_read_byte(pchg->lp, LP8788_CHG_EOC, );
> + val = (val & LP8788_CHG_EOC_TIME_M) >> LP8788_CHG_EOC_TIME_S;
> +
> + return scnprintf(buf, BUF_SIZE, "End Of Charge Time: %s\n", stime[val]);
> +}
> +
> +static ssize_t lp8788_show_eoc_level(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct lp8788_charger *pchg = dev_get_drvdata(dev);
> + char *abs_level[] = { "25mA", "49mA", "75mA", "98mA" };
> + char
Re: pci_get_subsys: GFP_KERNEL allocations with IRQs disabled
Hi Bjorn,
On Wed, 22 Aug 2012 11:02:52 -0700
Bjorn Helgaas wrote:
> On Wed, Aug 22, 2012 at 12:49 AM, Feng Tang wrote:
> > Hi Fengguang,
> >
> >
> > On Wed, 22 Aug 2012 10:50:08 +0800
> > Fengguang Wu wrote:
> >
> >> Feng,
> >>
> >> > I think it's pci_get_subsys() triggered this assert:
> >> >
> >> > /*
> >> > * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
> >> > */
> >> > if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
> >> > return;
> >>
> >> It's bisected down to this commit:
> >>
> >> commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448
> >> Author: Feng Tang
> >> AuthorDate: Wed May 30 23:15:41 2012 +0800
> >> Commit: Ingo Molnar
> >> CommitDate: Wed Jun 6 12:03:23 2012 +0200
> >>
> >> x86/reboot: Fix a warning message triggered by stop_other_cpus()
> >>
> >> Thanks,
> >> Fengguang
> >
> > Thanks for the bisection.
> >
> > Revert my commit should be a solution, but can we simply make the
> > pci_device_id
> > a local on stack one instead of using sleepable kmalloc for it, as this
> > sounds fragile when pci_get_subsys get called in a late system reboot stage?
>
> I think this is a great idea. Can you make this a real patch, with a
> changelog and Signed-off-by?
Thanks and will do.
>
> We should also remove the obsolete comment about early boot. I'm not
> sure the no_pci_devices() check is needed, either. And we can make
> the same simplification in pci_get_class().
Will check the no_pci_devices() part, and try to make it a separate
patch for easy reverting in case of error.
>
> >
> > diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> > index 993d4a0..e5ccede 100644
> > --- a/drivers/pci/search.c
> > +++ b/drivers/pci/search.c
> > @@ -246,7 +246,7 @@ struct pci_dev *pci_get_subsys(unsigned int vendor,
> > unsigned int device,
> >struct pci_dev *from)
> > {
> > + id.vendor = vendor;
> > + id.device = device;
> > + id.subvendor = ss_vendor;
> > + id.subdevice = ss_device;
> >
> > + pdev = pci_get_dev_by_id(, from);
>
> No need for "pdev" here, since we don't have to free anything.
ok, will directly return it.
Thanks,
Feng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] powerpc: Uprobes port to powerpc
>
> These seem to be duplicated in kprobes.h, can we consolidate them.
>
> > +struct arch_uprobe {
> > + u8 insn[MAX_UINSN_BYTES];
> > +};
>
> Why not uprobe_opcode_t insn ?
>
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs. uprobe_opcode_t
represents the size of the smallest breakpoint instruction for an arch.
Hence u8 works out the best. I know we could still use uprobe_opcode_t
and achieve the same. In which case, we would have to interpret
MAX_UINSN_BYTES differently. Do you see any advantages of using
uprobe_opcode_t instead of u8 across archs?
>
> > void do_notify_resume(struct pt_regs *regs, unsigned long
> > thread_info_flags)
> > {
> > + if (thread_info_flags & _TIF_UPROBE) {
> > + clear_thread_flag(TIF_UPROBE);
> > + uprobe_notify_resume(regs);
> > + }
>
> Presumably this ordering is crucial, ie. uprobes before signals.
>
Yes, we would want uprobes to have a say before do_signal can take a
look.
>
>
> I am probably missing something, but why do we need to execute out of
> line?
>
The other alternative to execute out of line is the current inline
singlestepping. In inline singlestepping, we would have to guard other
tasks from executing the same instruction.
Executing out of line solves this problem.
> > +/*
> > + * arch_uprobe_pre_xol - prepare to execute out of line.
> > + * @auprobe: the probepoint information.
> > + * @regs: reflects the saved user state of current task.
> > + */
> > +int arch_uprobe_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> > +{
> > + struct arch_uprobe_task *autask = >utask->autask;
> > +
> > + autask->saved_trap_nr = current->thread.trap_nr;
> > + current->thread.trap_nr = UPROBE_TRAP_NR;
> > + regs->nip = current->utask->xol_vaddr;
> > + return 0;
> > +}
> > +
> > +/**
> > + * uprobe_get_swbp_addr - compute address of swbp given post-swbp regs
> > + * @regs: Reflects the saved state of the task after it has hit a
> > breakpoint
> > + * instruction.
> > + * Return the address of the breakpoint instruction.
> > + */
> > +unsigned long uprobe_get_swbp_addr(struct pt_regs *regs)
> > +{
> > + return instruction_pointer(regs);
> > +}
>
> This seems like it would be better in asm/uprobes.h as a static inline,
> but that's not your fault.
>
We want archs to override uprobe_get_swbp_addr() if the default
uprobe_get_swbp_addr() doesnt suite for a particular arch. Do you have
better ways to achieve this. Initially we were using arch specific
callbacks from which we moved to using weak functions based on reviews.
> > + /*
> > +* emulate_step() returns 1 if the insn was successfully emulated.
> > +* For all other cases, we need to single-step in hardware.
> > +*/
> > + ret = emulate_step(regs, insn);
> > + if (ret > 0)
> > + return true;
>
> This actually emulates the instruction, ie. the contents of regs are
> changed based on the instruction.
>
> That seems to differ vs x86, where arch_uprobe_skip_sstep() just checks
> the instruction and returns true/false. Is that because on x86 they are
> only returning true for nops? ie. there is no emulation to be done?
>
Yes, In x86, we currently support skip for nop instructions, Once we add
code for skipping other instructions in x86, we could enhance them to
skip them too.
> It's a little surprising that can_skip_sstep() actually emulates the
> instruction, but again that's not your fault.
>
Are you saying its doing more than what the name suggests or to the fact
that can_skip_step should ideally be called just once?
--
Thanks and Regards
Srikar
--
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/
pci: question about the life cycle of pci_dev and its parent pci_bus
Hi, I have a question about the life cycle of pci_dev and its parent pci_bus. In pci_destroy_dev(), we remove the pci_dev from the bus_list, so pci_dev is isolated from its parent pci_bus, and their life cycle are independent too. But it seems that in pci_dev, we can still access the pci_bus from the pointer pci_dev->bus. To resolve such issue, I think during the pci_dev removal, there should be process to 1.prevent the reader incoming 2. ensure the current reader has exit. But can not find them. Could anyone tell me? Thanx, pingfan -- 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 Aug 23
Hi all, Changes since 20120822: New tree: pstore The tip tree gained a conflict against the rr tree. The rcu tree gained a conflict against the tip tree. The kvm tree gained a build failure so I used the version from next-20120822. The drivers-x86 tree still has its build failure so I used the version from next-20120817. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. The akpm tree lost a patcha that turned up elsewhere. 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" as mentioned in the FAQ on the wiki (see below). 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. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 196 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (fea7a08 Linux 3.6-rc3) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (8986873 ARM: 7490/1: Drop duplicate select for GENERIC_IRQ_PROBE) Merging m68k-current/for-linus (9e2760d m68k: Make sys_atomic_cmpxchg_32 work on classic m68k) Merging powerpc-merge/merge (ad36cb0 powerpc/kvm/book3s_32: Fix MTMSR_EERI macro) Merging sparc/master (6dab7ed Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm) Merging net/master (23dcfa6 Merge branch 'akpm' (Andrew's patch-bomb)) Merging sound-current/for-linus (042b92c ALSA: hda - Do not set GPIOs for speakers on IDT if there are no speakers) Merging pci-current/for-linus (046c653 PCI/PM: Add ABI document for sysfs file d3cold_allowed) Merging wireless/master (ea2d218 brcm80211: smac: set interface down on reset) Merging driver-core.current/driver-core-linus (ebdc828 dyndbg: fix for SOH in logging messages) Merging tty.current/tty-linus (38f8eef pmac_zilog,kdb: Fix console poll hook to return instead of loop) Merging usb.current/usb-linus (8f057d7 gpu/mfd/usb: Fix USB randconfig problems) Merging staging.current/staging-linus (6dab7ed Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm) Merging char-misc.current/char-misc-linus (f3261df 1-Wire: Add support for the maxim ds1825 temperature sensor) Merging input-current/for-linus (6f4d038 Input: wacom - add support for EMR on Cintiq 24HD touch) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (ce026cb crypto: caam - fix possible deadlock condition) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (22018e9 Me
Re: [PATCH 4/7] regulator: anatop-regulator: convert to use imx-syscon to access anatop register
On 08/22/2012 01:18 AM, Dong Aisheng wrote: > Signed-off-by: Dong Aisheng > diff --git a/drivers/regulator/anatop-regulator.c > b/drivers/regulator/anatop-regulator.c > @@ -109,7 +110,11 @@ static int __devinit anatop_regulator_probe(struct > platform_device *pdev) > rdesc->ops = _rops; > rdesc->type = REGULATOR_VOLTAGE; > rdesc->owner = THIS_MODULE; > - sreg->mfd = anatopmfd; > + > + sreg->anatop = of_parse_phandle(np, "fsl,anatop", 0); > + if (!sreg->anatop) > + return -ENODEV; In fact, that imx_syscon_lookup function I proposed could even do the of_parse_phandle() internally, so perhaps: foo->syscon_dev = imx_syscon_lookup(np, "fsl,anatop", 0); if (IS_ERR(foo->syscon_dev)) return PTR_ERR(foo->syscon_dev); with imx_syscon_lookup() internally knowing when to return EPROBE_DEFER rather than any other permanent error code (e.g. for missing property, bad phandle, etc.) -- 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] net/core/sock.c won't compile on alpha
On Thu, Aug 23, 2012 at 09:16:53AM +1200, Michael Cree wrote: > On 23/08/2012, at 12:14 AM, Bob Tracy wrote: > >Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the > >following compile-time error on alpha architecture: > > > >(...) > > CC net/core/sock.o > >net/core/sock.c:274:36: error: initializer element is not constant > > Try v3.6-rc3. It should be fixed now. That got it. Finally saw the discussion on the bug (from about a month ago -- thanks, Simon). --Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] mfd: add imx syscon driver based on regmap
On 08/22/2012 04:57 AM, Dong Aisheng wrote:
> On Wed, Aug 22, 2012 at 04:29:41PM +0800, Zhao Richard-B20223 wrote:
>> On Wed, Aug 22, 2012 at 03:18:42PM +0800, Dong Aisheng wrote:
>>> Add regmap based imx syscon driver.
>>> This is usually used for access misc bits in registers which does not belong
>>> to a specific module, for example, IOMUXC GPR and ANATOP.
>>> With this driver, we provide a standard API for client driver to call to
>>> access registers which are registered into syscon.
>>> +static int imx_syscon_match(struct device *dev, void *data)
>>> +{
>>> + struct imx_syscon *syscon = dev_get_drvdata(dev);
>>> + struct device_node *dn = data;
>>> +
>>> + return (syscon->dev->of_node == dn) ? 1 : 0;
>>> +}
>>> +
>>> +int imx_syscon_write(struct device_node *np, u32 reg, u32 val)
>>
>> For API function, is it better to use struct device rather not np?
>> - it won't need to search dev in below code every time it access
>>registers.
>
> The purpose is not require client driver to know the implementation details
> of imx_syscon_{read/write} API, it's more easy to use since client only
> needs pass the device node to which it wants to read/write.
>
> For search dev, it doesn't look like a big issue since it only search devices
> attached on the driver which is very quick.
> And hide it in common API does not require every client driver to write
> duplicated codes.
You could still implement a function:
struct device *imx_syscon_lookup(struct device_node *np)
... and require all clients to call that, and pass the dev to the other
functions. That'd still keep all the lookup code in one place, but
prevent it having to run every time, no matter how small it is.
I think such an API is required anyway, since client drivers need some
way to determine whether the imx_syscon driver is available yet, and if
not defer their probe until it is.
So, clients would do:
foo->syscon_dev = imx_syscon_lookup(np);
if (!foo->syscon_dev)
return -EPROBE_DEFER;
rather than:
foo->syscon_np = np;
Not too much overhead/boiler-plate in each client driver.
--
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] lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver
On Wed, 22 Aug 2012 22:55:43 +0100 Matthew Garrett wrote: > On Wed, Aug 22, 2012 at 09:55:12PM +0200, Wim Van Sebroeck wrote: > > > Any idea why the acpi_check_resource_conflict() check gives a conflict? > > Because the resource range is declared in ACPI and we assume that that > means the firmware wants to scribble on it. We'd need the output of > acpidump to work out whether that's safe or not. Good point, I checked the conflict for iTCO_wdt, the conflict exists on almost all the machines I have. According to ICH (7/8/9 etc)spec, the TCO watchdog has a 32 bytes long IO space resource, and the bit 9 of TCO1_STS register is "DMISCI_STS", which indicates whether a SCI happens, and will be cleared by writing 1 to it. Most of DSDT table will claim a TCO op region only for one bit: "DMISCI_STS" , as some method may need to access that bit. I think there is some risk, but it's quite safe as the DMISCI_STS bit has nothing to do with TCO driver itself, and TCO driver never access it, also this TCO driver has been there for years, and this resource conflict also exists for many generations hardware. Thanks, Feng -- 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 33/36] autonuma: powerpc port
On Thu, 2012-08-23 at 00:35 +0200, Andrea Arcangeli wrote: > I'm actually surprised you don't already check for PROTNONE > there. Anyway yes this is necessary, the whole concept of NUMA hinting > page faults is to make the pte not present, and to set another bit (be > it a reserved bit or PROTNONE doesn't change anything in that > respect). But another bit replacing _PAGE_PRESENT must exist. > > This change is zero cost at runtime, and 0x1 or 0x3 won't change a > thing for the CPU. We don't have PROTNONE on ppc, see below. .../... > > I'm concerned. We are already running short on RPN bits. We can't spare > > more. If you absolutely need a PTE bit, we'll need to explore ways to > > free some, but just reducing the RPN isn't an option. > > No way to do it without a spare bit. > > Note that this is now true for sched-numa rewrite as well because it > also introduced the NUMA hinting page faults of AutoNUMA (except what > it does during the fault is different there, but the mechanism of > firing them and the need of a spare pte bit is identical). > > But you must have a bit for protnone, don't you? You can implement it > with prot none, I can add the vma as parameter to some function to > achieve it if you need. It may be good idea to do anyway even if > there's no need on x86 at this point. So we don't do protnone, and now that you mention it, I think that means that some of our embedded stuff is busted :-) Basically PROT_NONE turns into _PAGE_PRESENT without _PAGE_USER for us. On server, user accesses effectively use the user protection bits due to the fact that the user segments are tagged as such. So the fact that PROT_NONE -> !_PAGE_USER for us is essentially enough. However, the embedded ppc situation is more interesting... and it looks like it is indeed broken, meaning that a user can coerce the kernel into accessing PROT_NONE on its behalf with copy_from_user & co (though read only really). Looks like the SW TLB handlers used on embedded should also check whether the address is a user or kernel address, and enforce _PAGE_USER in the former case. They might have done in the past, it's possible that it's code we lost, but as it is, it's broken. The case of HW loaded TLB embedded will need a different definition of PAGE_NONE as well I suspect. Kumar, can you have a look ? > > Think of what happens if PTE_4K_PFN is set... > > It may very well broken with PTE_4K_PFN is set, I'm not familiar with > that. If that's the case we'll just add an option to prevent > AUTONUMA=y to be set if PTE_4K_PFN is set thanks for the info. > > > Also you conveniently avoided all the other pte-*.h variants meaning you > > broke the build for everything except ppc64 with 64k pages. > > This can only be enabled on PPC64 in KConfig so no problem about > ppc32. I wasn't especially thinking of ppc32... there's also hash64-4k or embedded 64... Also pgtable.h is common, so all those added uses of _PAGE_NUMA_PTE to static inline functions are going to break the build unless _PAGE_NUMA_PTE is #defined to 0 when not used (we do that for a bunch of bits in pte-common.h already). > > > diff --git a/mm/autonuma.c b/mm/autonuma.c > > > index ada6c57..a4da3f3 100644 > > > --- a/mm/autonuma.c > > > +++ b/mm/autonuma.c > > > @@ -25,7 +25,7 @@ unsigned long autonuma_flags __read_mostly = > > > #ifdef CONFIG_AUTONUMA_DEFAULT_ENABLED > > > |(1< > > #endif > > > - |(1< > > + |(0< > > > That changes the default accross all architectures, is that ok vs. > > Andrea ? > > :) Indeed! But the next patch (34) undoes this hack. I just merged the > patch with "git am" and then introduced a proper way for the arch to > specify if the PMD scan is supported or not in an incremental > patch. Adding ppc64 support, and making the PMD scan mode arch > conditional are two separate things so I thought it was cleaner > keeping those in two separate patches but I can fold them if you > prefer. Ok. Cheers, Ben. -- 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: v3.6-rc1: modprobe hangs with sdhci failure on dell e6410
On 08/22/2012 10:11 PM, Arend van Spriel wrote:
> A quick search using google did not provide clues. Regardless if there
> is anything inserted the hang occurs.
your dmesg shows:
[ 241.908294] INFO: task modprobe:134 blocked for more than 120 seconds.
[ 241.908298] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 241.908301] modprobeD f48abbcc 0 134 98 0x
[ 241.908307] f48abc3c 0082 f59d0ebc f48abbcc c1289228 f4f3e480
c17b0380
[ 241.908313] c17b0380 c17b0380 1de51926 c17b0380 f59d5380 f4f3e480
f4853ed0
[ 241.908319] 0001 f48abc28 f59d0eb0 f4df3131 c17abe80
0003
[ 241.908326] Call Trace:
[ 241.908337] [] ? timerqueue_add+0x58/0xb0
[ 241.908345] [] schedule+0x23/0x60
[ 241.908349] [] schedule_hrtimeout_range_clock+0xaf/0x130
[ 241.908354] [] ? update_rmtp+0x80/0x80
[ 241.908359] [] ? hrtimer_start_range_ns+0x26/0x30
[ 241.908362] [] schedule_hrtimeout_range+0x17/0x20
[ 241.908369] [] usleep_range+0x39/0x40
[ 241.908384] [] sdhci_do_start_signal_voltage_switch+0x59/0x150
[sdhci]
[ 241.908390] [] sdhci_start_signal_voltage_switch+0x41/0x80 [sdhci]
[ 241.908401] [] mmc_set_signal_voltage+0x58/0xb0 [mmc_core]
[ 241.908411] [] mmc_power_up+0x85/0xf0 [mmc_core]
[ 241.908420] [] mmc_start_host+0x38/0x50 [mmc_core]
[ 241.908430] [] mmc_add_host+0x50/0x90 [mmc_core]
[ 241.908436] [] sdhci_add_host+0x837/0xbc0 [sdhci]
[ 241.908444] [] sdhci_pci_probe+0x3fc/0x5f0 [sdhci_pci]
[ 241.908449] [] ? _raw_spin_lock_irqsave+0x2f/0x50
[ 241.908455] [] local_pci_probe+0x47/0xb0
[ 241.908460] [] pci_device_probe+0x68/0x90
[ 241.908467] [] driver_probe_device+0x78/0x1f0
[ 241.908471] [] ? pci_match_device+0xb3/0xc0
[ 241.908476] [] __driver_attach+0x81/0x90
[ 241.908480] [] bus_for_each_dev+0x53/0x80
[ 241.908484] [] driver_attach+0x1e/0x20
[ 241.908488] [] ? driver_probe_device+0x1f0/0x1f0
[ 241.908491] [] bus_add_driver+0xb2/0x230
[ 241.908495] [] ? pci_dev_put+0x20/0x20
[ 241.908499] [] ? pci_dev_put+0x20/0x20
[ 241.908502] [] driver_register+0x6a/0x140
[ 241.908509] [] ? tracepoint_module_notify+0x12b/0x190
[ 241.908514] [] __pci_register_driver+0x44/0xb0
[ 241.908522] [] sdhci_drv_init+0x17/0x19 [sdhci_pci]
[ 241.908526] [] do_one_initcall+0x34/0x170
[ 241.908532] [] ? 0xf8085fff
[ 241.908539] [] sys_init_module+0xee/0x1460
[ 241.908542] [] ? free_notes_attrs+0x50/0x50
[ 241.908549] [] ? 0xf8072fff
[ 241.908556] [] sysenter_do_call+0x12/0x28
Looks like the usleep_range called in
sdhci_do_start_signal_voltage_switch blocked modprobe, maybe the timeout
never happens for whatever reason?
Can you please try the following patch:
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8ac5246..30ce05d 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1212,6 +1212,9 @@ static void mmc_power_up(struct mmc_host *host)
host->ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);
+ /* debug */
+ usleep_range(5000, 5500);
+
/* Set signal voltage to 3.3V */
mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, false);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a11dc3..a181c46 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1616,7 +1616,8 @@ static int sdhci_do_start_signal_voltage_switch(struct
sdhci_host *host,
* to 3.3V. If so, we change the voltage to 3.3V and return quickly.
*/
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
- if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
+ if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330 &&
+ (ctrl & SDHCI_CTRL_VDD_180)) {
/* Set 1.8V Signal Enable in the Host Control2 register to 0 */
ctrl &= ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
The above code did 2 things:
1 calling usleep_range in another place to see what happened;
2 avoid setting 3.3v signalling voltage if host is already at 3.3v
signalling voltage.
Thanks,
Aaron
--
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] power_supply: Add new power supply properties CHARGE_CURRENT/VOLTAGE_MAX
On Mon, Jul 30, 2012 at 12:49:21PM +0530, Ramakrishna Pallala wrote: > There are different types of chargers avalibale like AC, Solar, USB, etc.. > Even in USB we have different types SDP/DCP/CDP/ACA and all these > chargers have different o/p ratings. For example SDP supports only 500mA of > charge current whereas AC charger can support upto 8A or more. > > Similarly batteries also come with charge current and voltage ratings and > these ratings vary depending on its capacity and the technology used. > > This patch adds two new power supply properties CONSTANT_CHARGE_CURRENT_MAX > and > CONSTANT_CHARGE_CURRENT_MAX. > > Signed-off-by: Ramakrishna Pallala > --- Applied, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: replace __getblk_slow misfix by grow_dev_page fix
On Wed, 22 Aug 2012, Richard W.M. Jones wrote:
> On Tue, Aug 21, 2012 at 06:33:45PM -0700, Hugh Dickins wrote:
> > Jeff,
> >
> > Your commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow"),
> > already gone into 3.* stable, is not good. Could you and your testers
> > please give this alternative a try - I think it should work, and have
> > started it on a few days' memory load on 3.5, but not tried your case.
>
> I have tested your patch and it does NOT fix the problem in
> http://bugzilla.redhat.com/835019
> Kernel 3.6.0 + your patch => mount goes into a loop when mounting
> a small empty partition. Please do NOT apply this as it will
> cause a regression!
That was all very helpful information that you provided, thank you.
Sorry, I had missed how "block" is massaged as it's passed down a level.
The patch below fixes it for me, though it does have to change more than
I'd been hoping in such a fix. Perhaps I am just being silly to resist
repeating the call to blkdev_max_block(). Does this patch work for you?
Thanks,
Hugh
[PATCH] block: replace __getblk_slow misfix by grow_dev_page fix
Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow")
is not good: a successful call to grow_buffers() cannot guarantee
that the page won't be reclaimed before the immediate next call to
__find_get_block(), which is why there was always a loop there.
Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595:
inode #19278: block 664: comm cc1: unable to read itable block" on console,
which pointed to this commit.
I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs
sometimes fails from a missing header file, under memory pressure on
ppc G5. I've never seen this on x86, and I've never seen it on 3.5-rc7
itself, despite that commit being in there: bisection pointed to an
irrelevant pinctrl merge, but hard to tell when failure takes between
18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2).
(I've since found such __ext4_get_inode_loc errors in /var/log/messages
from previous weeks: why the message never appeared on console until
yesterday morning is a mystery for another day.)
Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus
a checkpatch nitfix). Simplify the interface between grow_buffers()
and grow_dev_page(), and avoid the infinite loop beyond end of device
by instead checking init_page_buffers()'s end_block there (I presume
that's more efficient than a repeated call to blkdev_max_block()),
returning -ENXIO to __getblk_slow() in that case.
And remove akpm's ten-year-old "__getblk() cannot fail ... weird"
comment, but that is worrying: are all users of __getblk() really
now prepared for a NULL bh beyond end of device, or will some oops??
Signed-off-by: Hugh Dickins
Cc: sta...@vger.kernel.org # 3.0 3.2 3.4 3.5
---
fs/buffer.c | 66 ++
1 file changed, 30 insertions(+), 36 deletions(-)
--- 3.6-rc3/fs/buffer.c 2012-08-04 09:19:20.644022328 -0700
+++ linux/fs/buffer.c 2012-08-22 17:11:57.143827063 -0700
@@ -914,7 +914,7 @@ link_dev_buffers(struct page *page, stru
/*
* Initialise the state of a blockdev page's buffers.
*/
-static void
+static sector_t
init_page_buffers(struct page *page, struct block_device *bdev,
sector_t block, int size)
{
@@ -936,33 +936,41 @@ init_page_buffers(struct page *page, str
block++;
bh = bh->b_this_page;
} while (bh != head);
+
+ /*
+* Caller needs to validate requested block against end of device.
+*/
+ return end_block;
}
/*
* Create the page-cache page that contains the requested block.
*
- * This is user purely for blockdev mappings.
+ * This is used purely for blockdev mappings.
*/
-static struct page *
+static int
grow_dev_page(struct block_device *bdev, sector_t block,
- pgoff_t index, int size)
+ pgoff_t index, int size, int sizebits)
{
struct inode *inode = bdev->bd_inode;
struct page *page;
struct buffer_head *bh;
+ sector_t end_block;
+ int ret = 0;/* Will call free_more_memory() */
page = find_or_create_page(inode->i_mapping, index,
(mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS)|__GFP_MOVABLE);
if (!page)
- return NULL;
+ return ret;
BUG_ON(!PageLocked(page));
if (page_has_buffers(page)) {
bh = page_buffers(page);
if (bh->b_size == size) {
- init_page_buffers(page, bdev, block, size);
- return page;
+ end_block = init_page_buffers(page, bdev,
+ index << sizebits, size);
+ goto done;
}
if (!try_to_free_buffers(page))
goto failed;
@@ -982,14
Re: [PATCH 0/2] charger-manager: Stop charging when charge cable is detached and code clean
On Thu, Aug 23, 2012 at 01:27:27PM +0900, Chanwoo Choi wrote: [...] > I did send additional patchset which has 5 patch and also include below > patch list, > if you may confuse due to duplicate patch, so I inform to you about > duplicate patch. > > Chanwoo Choi (2): >charger-manager: Disable regulator for charging when charger cable is > detached >charger-manager: Use replacement variable to check state of battery Understood, thanks for the heads up! The third patch of 0/5 patch set needs a thoughtful review, I'll surely get to it, but not today. Anton. -- 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: [RFT] xhci: Switch PPT ports to EHCI on shutdown.
On 08/07/2012 11:39 AM, Sarah Sharp wrote:
The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS. If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system. Some BIOS will work around this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown. The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.
Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names. One example
is Compulab's mini-desktop, the Intense-PC. Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.
The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp
Reported-by: Denis Turischev
Cc: sta...@vger.kernel.org
---
drivers/usb/host/pci-quirks.c |7 +++
drivers/usb/host/pci-quirks.h |1 +
drivers/usb/host/xhci-pci.c |9 +
drivers/usb/host/xhci.c |3 +++
drivers/usb/host/xhci.h |1 +
5 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index df0828c..c5e9e4a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -800,6 +800,13 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
}
EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
+{
+ pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
+ pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
+}
+EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+
/**
* PCI Quirks for xHCI.
*
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index b1002a8..ef004a5 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev);
void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
#else
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 92eaff6..9bfd4ca11 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -94,6 +94,15 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
xhci->limit_active_eps = 64;
xhci->quirks |= XHCI_SW_BW_CHECKING;
+ /*
+* PPT desktop boards DH77EB and DH77DF will power back on after
+* a few seconds of being shutdown. The fix for this is to
+* switch the ports from xHCI to EHCI on shutdown. We can't use
+* DMI information to find those particular boards (since each
+* vendor will change the board name), so we have to key off all
+* PPT chipsets.
+*/
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 95394e5..81aa10c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -659,6 +659,9 @@ void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ if (xhci->quirks && XHCI_SPURIOUS_REBOOT)
+ usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
This looks like a typo, think it should be & not &&. With this code, it
appears the quirk will always be triggered since XHCI_SPURIOUS_REBOOT is
non-zero.
+
spin_lock_irq(>lock);
xhci_halt(xhci);
spin_unlock_irq(>lock);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 96f49db..c713256 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1494,6 +1494,7 @@ struct xhci_hcd {
#define XHCI_TRUST_TX_LENGTH (1 << 10)
#define XHCI_LPM_SUPPORT (1 << 11)
#define XHCI_INTEL_HOST (1 << 12)
+#define XHCI_SPURIOUS_REBOOT (1 << 13)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
--
To
Re: [PATCH] Fixes for dw_dmac and atmel-mci for AP700x
On 8/21/2012 10:15 PM, Havard Skinnemoen wrote: > On Tue, Aug 21, 2012 at 1:31 AM, Arnd Bergmann > wrote: >> On Tuesday 21 August 2012, Viresh Kumar wrote: Is AVR32 a big-endian system? Probably big-endian, that's why values are > getting > swapped. And dw_dmac is the standard one, can call it little endian for the > time being. > > @Arnd: What should we do here? Yes, AVR32 is big-endian. I assume that dw_dmac can be either configured as little-endian or big-endian and that it is configured as big-endian on AVR32. >>> Just to understand a bit more on this always confusing endianess concept: >>> - For AVR32, readl is calling swab everytime. So whatever we write will get >>> swapped. >>> - What are the implications of dw_dmac configured in little/big endian? >>> >>> When we write something to register of a peripheral, whose endianess >>> property decides how it will get written. Processor or Peripheral? >> The device decides which accessor we need to use (readl, ioread, ioread_be, >> in_be, in_le, ...). The architecture code must ensure that this is >> implemented properly based on the CPU endianess. We don't have a proper >> accessor function that implements "device has same endianess as CPU". >> Using __raw_* is not a replacement for that. >> >> I don't mind adding such an accessor at all, and a number people have >> complained about the lack of this for some time, but you should be >> aware that a lot of peripherals that are intended to be used in >> "CPU-endian" mode eventually end up getting used in "wrong-endian" >> mode, e.g. when someone decides to put that peripheral on a PCI >> card and someone else sticks it into a machine that has a CPU >> with the opposed (or configurable) endianess. It would be nice if >> the likes of designware could at least pick one endianess per >> device they do, but the reality is that we have to deal with both >> variants and only the device driver can find out what it is. > A native-endian accessor would really help in this case. Back in 2006 > when I did the AVR32 port, that's what I thought __raw_ was, but I > suspect I was both wrong, and the semantics of the I/O accessors have > changed slightly over time. But since __raw_ did exactly what was > needed on both AVR32 (big endian) and AT91 ARM (little endian) > devices, I ended up using it for all on-chip devices. > > read[bwl] on the other hand was implemented for external device > access. Since the SMC controller on AP7000 is really bizarre > (basically big endian data with little endian addressing), these > accessors became pretty weird too. > > Anyway, if we want to purge all those inappropriate __raw accesses > from the Atmel drivers, we're going to need a replacement for internal > native-endian access. Right now, we don't have any. If I may summarize: Viresh replaced the __raw* accessor functions with readl/writel, because they will enforce a correct ordering of instructions exchanged with the peripheral. On the ARM configurations this worked ok, because both the device and the CPU are little endian. However, for AVR32 the driver got broken: readl/writel are little endian accessors. I looked up an earlier thread "MMIO and gcc re-ordering issue"*, in which Havard wrote: > I don't think adding barriers is the > right thing to do because they won't do anything useful in practice, so > it's hard to tell whether they are used "correctly". And it will hurt > performance at least on AVR32 since wmb() evaluates to a "sync" > instruction, which flushes the write buffer to RAM. Since MMIO writes > are unbuffered, that's pure overhead. Four years later, we still don't have a generic native-endian MMIO-access API which also introduce proper memory barriers. So for the moment, do we have a better solution than this: #ifdef CONFIG_AVR32 +#define dma_readl(dw, name) \ + __raw_readl(&(__dw_regs(dw)->name)) +#define dma_writel(dw, name, val) \ + __raw_writel((val), &(__dw_regs(dw)->name)) +#else #define dma_readl(dw, name) \ readl(&(__dw_regs(dw)->name)) #define dma_writel(dw, name, val) \ writel((val), &(__dw_regs(dw)->name)) +#endif and do the same for channel_readl/writel ? Hein *http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-05/msg13776.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 v4 2/2] powerpc: Uprobes port to powerpc
On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
> From: Ananth N Mavinakayanahalli
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
Hi Ananth,
Excuse my ignorance of uprobes, some comments inline ...
> [root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
> Added new event:
> probe_libc:malloc(on 0xb4860)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_libc:malloc -aR sleep 1
Is there a test suite for any of this?
> Index: linux-tip-16aug/arch/powerpc/include/asm/uprobes.h
> ===
> --- /dev/null
> +++ linux-tip-16aug/arch/powerpc/include/asm/uprobes.h
> @@ -0,0 +1,58 @@
> +#ifndef _ASM_UPROBES_H
> +#define _ASM_UPROBES_H
> +/*
> + * User-space Probes (UProbes) for powerpc
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + *
> + * Copyright (C) IBM Corporation, 2007-2012
The lawyers say we shouldn't use (C).
Is it really copyright IBM 2007-2012? Or is that because you copied
another header?
> +typedef unsigned int uprobe_opcode_t;
I'd prefer u32.
It would be nice if someone could consolidate this with kprobe_opcode_t.
> +#define MAX_UINSN_BYTES 4
> +#define UPROBE_XOL_SLOT_BYTES(MAX_UINSN_BYTES)
> +
> +#define UPROBE_SWBP_INSN 0x7fe8
This is just "trap" ?
> +#define UPROBE_SWBP_INSN_SIZE4 /* swbp insn size in bytes */
> +
> +#define IS_TW(instr) (((instr) & 0xfc0007fe) == 0x7c08)
> +#define IS_TD(instr) (((instr) & 0xfc0007fe) == 0x7c88)
> +#define IS_TDI(instr)(((instr) & 0xfc00) == 0x0800)
> +#define IS_TWI(instr)(((instr) & 0xfc00) == 0x0c00)
> +
> +#define is_trap(instr) (IS_TW(instr) || IS_TD(instr) || \
> + IS_TWI(instr) || IS_TDI(instr))
These seem to be duplicated in kprobes.h, can we consolidate them.
> +struct arch_uprobe {
> + u8 insn[MAX_UINSN_BYTES];
> +};
Why not uprobe_opcode_t insn ?
> Index: linux-tip-16aug/arch/powerpc/kernel/signal.c
> ===
> --- linux-tip-16aug.orig/arch/powerpc/kernel/signal.c
> +++ linux-tip-16aug/arch/powerpc/kernel/signal.c
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -157,6 +158,11 @@ static int do_signal(struct pt_regs *reg
>
> void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
> {
> + if (thread_info_flags & _TIF_UPROBE) {
> + clear_thread_flag(TIF_UPROBE);
> + uprobe_notify_resume(regs);
> + }
Presumably this ordering is crucial, ie. uprobes before signals.
> if (thread_info_flags & _TIF_SIGPENDING)
> do_signal(regs);
>
> Index: linux-tip-16aug/arch/powerpc/kernel/uprobes.c
> ===
> --- /dev/null
> +++ linux-tip-16aug/arch/powerpc/kernel/uprobes.c
> @@ -0,0 +1,180 @@
> +/*
> + * User-space Probes (UProbes) for powerpc
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + *
> + * Copyright (C) IBM Corporation, 2007-2012
> + *
> + * Adapted from the x86 port by Ananth N Mavinakayanahalli
>
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define UPROBE_TRAP_NR UINT_MAX
In the comments below you talk about -1 a few times, but you actually
mean UINT_MAX.
> +/**
> + *
Re: [PATCH 0/2] charger-manager: Stop charging when charge cable is detached and code clean
On 08/23/2012 12:10 PM, Anton Vorontsov wrote: > On Fri, Jul 27, 2012 at 02:01:25PM +0900, Chanwoo Choi wrote: >> This patchset fix bug related to stop charging when charger cable is >> detached and check return value of regulator_enable/disable() function >> to confirm correct operation of enabled or disabling regulator for >> charging. Second patch is code clean which remove unnecessary variable >> type. >> >> Chanwoo Choi (2): >> charger-manager: Disable regulator for charging when charger cable is >> detached >> charger-manager: Use replacement variable to check state of battery >> >> drivers/power/charger-manager.c | 21 ++--- >> include/linux/power/charger-manager.h |3 --- >> 2 files changed, 18 insertions(+), 6 deletions(-) > > Both applied, much thanks! > Thanks for your reply and applied it. I did send additional patchset which has 5 patch and also include below patch list, if you may confuse due to duplicate patch, so I inform to you about duplicate patch. Chanwoo Choi (2): charger-manager: Disable regulator for charging when charger cable is detached charger-manager: Use replacement variable to check state of battery You can check additional patchset for charger-manager: https://lkml.org/lkml/2012/8/21/68 Thanks and Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: export read_current_timer
On 8/23/2012 2:58 AM, Will Deacon wrote: > On Wed, Aug 22, 2012 at 06:57:20PM +0100, Stephen Boyd wrote: >> On 08/22/12 10:49, Will Deacon wrote: >>> On the topic of the timer stuff: Shinya/Stephen, did you have a chance to >>> look at the registration stuff that was proposed? I'm happy to push it if >>> people will actually use it. >> >> Yes I have tested it on our internal trees and it looks good. I plan to >> send a patch to move MSM's timers over to it later this week so that we >> have at least two users upstream. And I think other A9 MPcore platforms, namely OMAP and EXYNOS, would also be candidates, who tried to skip calibrate_delay() in the past (OMAP) or currently provide non-smp_twd timers as localtimers (EXYNOS). I may miss the latest status of those BSPs, but believe that we would have more users (>2) in the future. > Awesome, I'll dust that series off at -rc3 then. It works for me for weeks without troubles, looking forward to it. -- Shinya Kuribayashi Renesas Electronics -- 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 33/36] autonuma: powerpc port
* Benjamin Herrenschmidt [2012-08-23 08:56:34]: > On Thu, 2012-08-23 at 08:01 +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2012-08-22 at 16:59 +0200, Andrea Arcangeli wrote: > > > From: Vaidyanathan Srinivasan > > > > > > * PMD flaging is not required in powerpc since large pages > > > are tracked in ptes. > > > * Yet to be tested with large pages > > > * This is an initial patch that partially works > > > * knuma_scand and numa hinting page faults works > > > * Page migration is yet to be observed/verified > > > > > > Signed-off-by: Vaidyanathan Srinivasan > > > Signed-off-by: Andrea Arcangeli > > > > I don't like this. > > What I mean here is that it's fine as a proof of concept ;-) I don't > like it being in a series aimed at upstream... I agree. My intend was to get the ppc64 discussions started and also see what it takes to get autonuma to a new arch. > We can try to flush out the issues, but as it is, the patch isn't > upstreamable imho. Yes. The patch is still in RFC phase and good only for review/testing. > As for finding PTE bits, I have a few ideas we need to discuss, but > nothing simple I'm afraid. Sure Ben, lets try them and find the better fit. --Vaidy -- 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: Regression associated with commit c8628155ece3 - "tcp: reduce out_of_order memory use"
On Wed, 2012-08-22 at 16:33 -0500, Larry Finger wrote: > On 08/22/2012 12:15 AM, Eric Dumazet wrote: > > > > This particular commit is the start of a patches batch that ended in the > > generic TCP coalescing mechanism. > > > > It is known to have problem on drivers doing skb_clone() in their rx > > path. > > > > Current kernels should be ok, because coalescing doesnt happen if the > > destination skb is cloned (skb_cloned(to) in skb_try_coalesce()) > > The skb_clone() call is not the source of the problem for r8712u, as it is > only > used when a memory allocation fails, which is not happening. The suggestion > did > lead to another patch that I had been preparing. The initial allocation of RX > buffers used a size of 30720 bytes, while 9100 is sufficient to allow > aggregation. Upon reducing the buffer size, the driver now works for me. I am > now awaiting tests by the OP on the Red Hat bugzilla before sending the patch > upstream. > > So far, no ideas for the problem in connecting to WPA1 networks. > Changing the allocation size removes the problem ? thats really strange. If you try different sizes in the 9100-30720 range, can you pinpoint the failure threshold ? -- 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 3/3] spi: spi-davinci: convert to DMA engine API
On Wed, 2012-08-22 at 12:04 -0400, Matt Porter wrote: > for querying of these types of limitations. Right now, the > mmc driver implicitly knows that EDMA needs this restriction > but it's something that should be queried before calling > prep_slave(). that's something we need to add; exporting channel capabilities. We only tell that it slave or memcpy today, but we need to tell clients what are channel supported parameter ranges. -- ~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 1/4] ARM: export read_current_timer
On 8/23/2012 2:49 AM, Will Deacon wrote: > On Wed, Aug 22, 2012 at 06:15:14PM +0100, Stephen Boyd wrote: >> On 08/22/12 07:29, Arnd Bergmann wrote: >>> read_current_timer is used in the get_cycles() function when >>> ARM_ARCH_TIMER is set, and that function can be inlined into >>> driver modules, so we should export the function to avoid >>> errors like >>> >>> ERROR: "read_current_timer" [drivers/video/udlfb.ko] undefined! >>> ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined! >>> >>> Signed-off-by: Arnd Bergmann >>> Cc: Shinya Kuribayashi >> >> Acked-by: Stephen Boyd >> >> I ran into this last week but forgot to send the patch. Thanks. > > Looks good to me, thanks Arnd: > > Acked-by: Will Deacon I haven't hit with this so far with our configs though, but why not? Acked-by: Shinya Kuribayashi -- 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 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC
On Wed, Aug 22, 2012 at 03:36:48PM +0200, Hiroshi Doyu wrote: > Hi, > > KyongHo Cho wrote @ Wed, 22 Aug 2012 14:47:00 +0200: > > > vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic > > context. > > Right. > > I've been thinking that kzalloc() may be enough here, since > vzalloc() was introduced to avoid allocation failure for big chunk of > memory, but I think that it's unlikely that the number of page array > can be so big. So I propose to drop vzalloc() here, and just simply to > use kzalloc only as below(*1). > > For example, > > 1920(H) x 1080(W) x 4(bytes) ~= 8MiB > > For 8 MiB buffer, > 8(MiB) * 1024 = 8192(KiB) > 8192(KiB) / 4(KiB/page) = 2048 pages > sizeof(struct page *) = 4 bytes > 2048(pages) * 4(bytes/page) = 8192(bytes) = 8(KiB) > 8(KiB) / 4(KiB/page) = 2 pages > > If the above estimation is right(I hope;)), the necessary pages are > _at most_ 2 pages. If the system gets into the situation to fail to > allocate 2 contiguous pages, that's real the problem. I guess that > that kind of fragmentation problem would be solved with page migration > or something, especially nowadays devices are getting larger memories. In atomic context, VM have no choice except relying on kswapd so high order allocation can fail easily when memory fragementation is high. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2][PATCH 3/3] powerpc/kgdb: restore current_thread_info properly
On 08/23/2012 11:14 AM, Nicholas A. Bellinger wrote:
> On Thu, 2012-08-23 at 10:10 +0800, Tiejun Chen wrote:
>> For powerpc BooKE and e200, singlestep is handled on the critical/dbg
>> exception stack. This causes current_thread_info() to fail for kgdb
>> internal, so previously We work around this issue by copying
>> the thread_info from the kernel stack before calling kgdb_handle_exception,
>> and copying it back afterwards.
>>
>> But actually we don't do this properly. We should backup current_thread_info
>> then restore that when exit.
>>
>> Signed-off-by: Tiejun Chen
>> ---
>> v2: fix a typo in patch head description.
>>
>> arch/powerpc/kernel/kgdb.c | 11 +--
>> 1 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
>> index 05adb69..c470a40 100644
>> --- a/arch/powerpc/kernel/kgdb.c
>> +++ b/arch/powerpc/kernel/kgdb.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /*
>> * This table contains the mapping between PowerPC hardware trap types, and
>> @@ -153,6 +154,8 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
>> static int kgdb_singlestep(struct pt_regs *regs)
>> {
>> struct thread_info *thread_info, *exception_thread_info;
>> +struct thread_info *backup_current_thread_info = \
>> +(struct thread_info *)kmalloc(sizeof(struct thread_info),
>> GFP_KERNEL);
>>
>
> Looks like a rouge '\' in the above assignment..
Remove that :)
Thanks
Tiejun
--
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: linux-next: manual merge of the rcu tree with the tip tree
On Thu, Aug 23, 2012 at 01:01:43PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the rcu tree got a conflict in arch/Kconfig
> between commit b952741c8079 ("cputime: Generalize
> CONFIG_VIRT_CPU_ACCOUNTING") from the tip tree and commit 3dbdfc26e27f
> ("rcu: Settle config for userspace extended quiescent state") from the
> rcu tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Looks good, thank you!
Thanx, Paul
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc arch/Kconfig
> index 07db929,1c7c9be..000
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@@ -294,26 -274,14 +294,36 @@@ config SECCOMP_FILTE
>
> See Documentation/prctl/seccomp_filter.txt for details.
>
> +config HAVE_MOD_ARCH_SPECIFIC
> +bool
> +help
> + The arch uses struct mod_arch_specific to store data. Many arches
> + just need a simple module loader without arch specific data - those
> + should not enable this.
> +
> +config MODULES_USE_ELF_RELA
> +bool
> +help
> + Modules only use ELF RELA relocations. Modules with ELF REL
> + relocations will give an error.
> +
> +config MODULES_USE_ELF_REL
> +bool
> +help
> + Modules only use ELF REL relocations. Modules with ELF RELA
> + relocations will give an error.
> +
> +config HAVE_VIRT_CPU_ACCOUNTING
> +bool
> +
> + config HAVE_RCU_USER_QS
> + bool
> + help
> + Provide kernel entry/exit hooks necessary for userspace
> + RCU extended quiescent state. Syscalls need to be wrapped inside
> + rcu_user_exit()-rcu_user_enter() through the slow path using
> + TIF_NOHZ flag. Exceptions handlers must be wrapped as well. Irqs
> + are already protected inside rcu_irq_enter/rcu_irq_exit() but
> + preemption or signal handling on irq exit still need to be protected.
> +
> source "kernel/gcov/Kconfig"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the kvm tree
Hi all,
After merging the kvm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kvm/built-in.o: In function `.kvmppc_h_enter':
(.text+0x2494): undefined reference to `.gfn_to_hva_memslot'
Presumably caused by commit 4d8b81abc47b ("KVM: introduce readonly
memslot").
I have used the kvm tree from next-20120822 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpbsNlhL91Gt.pgp
Description: PGP signature
Re: [PATCH 74/74] lto, workaround: Mark do_futex noinline to prevent clobbering ebp
On 08/22/2012 07:29 PM, Andi Kleen wrote: How about just use register arguments for the first three arguments. This should work for the syscalls at least (may be too risky for all other asm entry points) Well, it's just an effort to convert each one in turn... And for syscalls with more than three generate a stub that saves on the stack explicitely. This could be done using the new fancy SYSCALL definition macros (except that arch/x86 would need to start using them too in its own code) I don't think there is any point. Just push the six potential arguments to the stack and be done with it. Or is there some subtle reason with syscall restart and updated args that prevents it? Perhaps newer gcc can do regparm(X), X > 3 too, may be worth trying. No, there is no such ABI defined. Don't have time to look into this currently though. Always the problem. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2][PATCH 3/3] powerpc/kgdb: restore current_thread_info properly
On Thu, 2012-08-23 at 10:10 +0800, Tiejun Chen wrote:
> For powerpc BooKE and e200, singlestep is handled on the critical/dbg
> exception stack. This causes current_thread_info() to fail for kgdb
> internal, so previously We work around this issue by copying
> the thread_info from the kernel stack before calling kgdb_handle_exception,
> and copying it back afterwards.
>
> But actually we don't do this properly. We should backup current_thread_info
> then restore that when exit.
>
> Signed-off-by: Tiejun Chen
> ---
> v2: fix a typo in patch head description.
>
> arch/powerpc/kernel/kgdb.c | 11 +--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 05adb69..c470a40 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * This table contains the mapping between PowerPC hardware trap types, and
> @@ -153,6 +154,8 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
> static int kgdb_singlestep(struct pt_regs *regs)
> {
> struct thread_info *thread_info, *exception_thread_info;
> + struct thread_info *backup_current_thread_info = \
> + (struct thread_info *)kmalloc(sizeof(struct thread_info),
> GFP_KERNEL);
>
Looks like a rouge '\' in the above assignment..
--
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: Re: [PATCH 3/5] trace-cmd: Support trace-agent of virtio-trace
Hi Steven,
(2012/08/22 22:51), Steven Rostedt wrote:
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
Add read path and control path to use trace-agent of virtio-trace.
When we use trace-agent, trace-cmd will be used as follows:
# AGENT_READ_DIR=/tmp/virtio-trace/tracing \
AGENT_CTL=/tmp/virtio-trace/agent-ctl-path.in \
TRACING_DIR=/tmp/virtio-trace/debugfs/tracing \\
Ha! You used "TRACING_DIR" but patch one introduces TRACE_DIR. Lets
change this to DEBUG_TRACING_DIR instead anyway.
Oh, sorry for the confusion.
Also, I don't like the generic environment variables. Perhaps
VIRTIO_TRACE_DIR, or AGENT_TRACE_DIR and AGENT_TRACE_CTL. Lets try to
keep the environment namespace sparse.
OK, I'll change these name of environment variables as follows:
AGENT_READ_DIR
AGENT_TRACE_CTL
GUEST_TRACING_DIR
trace-cmd record -e "sched:*"
Here, AGENT_READ_DIR is the path for a reading directory of virtio-trace,
AGENT_CTL is a control path of trace-agent, and TRACING_DIR is a debugfs path
of a guest.
Signed-off-by: Yoshihiro YUNOMAE
---
trace-cmd.h |1 +
trace-recorder.c | 57 +-
trace-util.c | 18 +
3 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/trace-cmd.h b/trace-cmd.h
index f904dc5..75506ed 100644
--- a/trace-cmd.h
+++ b/trace-cmd.h
@@ -72,6 +72,7 @@ static inline int tracecmd_host_bigendian(void)
}
char *tracecmd_find_tracing_dir(void);
+char *guest_agent_tracing_read_dir(void);
/* --- Opening and Reading the trace.dat file --- */
diff --git a/trace-recorder.c b/trace-recorder.c
index 215affc..3b750e9 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "trace-cmd.h"
@@ -43,6 +44,8 @@ struct tracecmd_recorder {
int page_size;
int cpu;
int stop;
+ int ctl_fd;
+ boolagent_existing;
Thanks for the reminder. I need to convert a lot to use 'bool' instead.
I'll change 'int' just for flag to use 'bool' as much as possible
after finishing this patch set.
};
void tracecmd_free_recorder(struct tracecmd_recorder *recorder)
@@ -59,11 +62,29 @@ void tracecmd_free_recorder(struct tracecmd_recorder
*recorder)
free(recorder);
}
+static char *use_trace_agent_dir(char *ctl_path,
+ struct tracecmd_recorder *recorder)
+{
+ ctl_path = strdup(ctl_path);
+ if (!ctl_path)
+ die("malloc");
+ warning("Use environmental control path: %s\n", ctl_path);
s/Use/Using/
OK, I'll correct this.
Thank you,
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@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/
Re: [PATCH 0/2] charger-manager: Stop charging when charge cable is detached and code clean
On Fri, Jul 27, 2012 at 02:01:25PM +0900, Chanwoo Choi wrote: > This patchset fix bug related to stop charging when charger cable is > detached and check return value of regulator_enable/disable() function > to confirm correct operation of enabled or disabling regulator for > charging. Second patch is code clean which remove unnecessary variable > type. > > Chanwoo Choi (2): > charger-manager: Disable regulator for charging when charger cable is > detached > charger-manager: Use replacement variable to check state of battery > > drivers/power/charger-manager.c | 21 ++--- > include/linux/power/charger-manager.h |3 --- > 2 files changed, 18 insertions(+), 6 deletions(-) Both applied, much 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 v2] smb347_charger: fix battery status reporting logic for charger faults
This patch checks for charger status register for determining the
battery charging status and reports Discharing/Charging/Not Charging/Full
accordingly.
This patch also adds the interrupt support for Safety Timer Expiration.
This interrupt is helpful in debugging the cause for charger fault.
Signed-off-by: Ramakrishna Pallala
---
drivers/power/smb347-charger.c | 97 +--
1 files changed, 82 insertions(+), 15 deletions(-)
diff --git a/drivers/power/smb347-charger.c b/drivers/power/smb347-charger.c
index 332dd01..c5b482b 100644
--- a/drivers/power/smb347-charger.c
+++ b/drivers/power/smb347-charger.c
@@ -80,6 +80,7 @@
#define CFG_FAULT_IRQ_DCIN_UV BIT(2)
#define CFG_STATUS_IRQ 0x0d
#define CFG_STATUS_IRQ_TERMINATION_OR_TAPERBIT(4)
+#define CFG_STATUS_IRQ_CHARGE_TIMEOUT BIT(7)
#define CFG_ADDRESS0x0e
/* Command registers */
@@ -96,6 +97,9 @@
#define IRQSTAT_C_TERMINATION_STAT BIT(0)
#define IRQSTAT_C_TERMINATION_IRQ BIT(1)
#define IRQSTAT_C_TAPER_IRQBIT(3)
+#define IRQSTAT_D 0x38
+#define IRQSTAT_D_CHARGE_TIMEOUT_STAT BIT(2)
+#define IRQSTAT_D_CHARGE_TIMEOUT_IRQ BIT(3)
#define IRQSTAT_E 0x39
#define IRQSTAT_E_USBIN_UV_STATBIT(0)
#define IRQSTAT_E_USBIN_UV_IRQ BIT(1)
@@ -109,8 +113,10 @@
#define STAT_B 0x3c
#define STAT_C 0x3d
#define STAT_C_CHG_ENABLED BIT(0)
+#define STAT_C_HOLDOFF_STATBIT(3)
#define STAT_C_CHG_MASK0x06
#define STAT_C_CHG_SHIFT 1
+#define STAT_C_CHG_TERMBIT(5)
#define STAT_C_CHARGER_ERROR BIT(6)
#define STAT_E 0x3f
@@ -701,7 +707,7 @@ fail:
static irqreturn_t smb347_interrupt(int irq, void *data)
{
struct smb347_charger *smb = data;
- unsigned int stat_c, irqstat_e, irqstat_c;
+ unsigned int stat_c, irqstat_c, irqstat_d, irqstat_e;
bool handled = false;
int ret;
@@ -717,6 +723,12 @@ static irqreturn_t smb347_interrupt(int irq, void *data)
return IRQ_NONE;
}
+ ret = regmap_read(smb->regmap, IRQSTAT_D, _d);
+ if (ret < 0) {
+ dev_warn(smb->dev, "reading IRQSTAT_D failed\n");
+ return IRQ_NONE;
+ }
+
ret = regmap_read(smb->regmap, IRQSTAT_E, _e);
if (ret < 0) {
dev_warn(smb->dev, "reading IRQSTAT_E failed\n");
@@ -724,13 +736,11 @@ static irqreturn_t smb347_interrupt(int irq, void *data)
}
/*
-* If we get charger error we report the error back to user and
-* disable charging.
+* If we get charger error we report the error back to user.
+* If the error is recovered charging will resume again.
*/
if (stat_c & STAT_C_CHARGER_ERROR) {
- dev_err(smb->dev, "error in charger, disabling charging\n");
-
- smb347_charging_disable(smb);
+ dev_err(smb->dev, "charging stopped due to charger error\n");
power_supply_changed(>battery);
handled = true;
}
@@ -743,6 +753,20 @@ static irqreturn_t smb347_interrupt(int irq, void *data)
if (irqstat_c & (IRQSTAT_C_TERMINATION_IRQ | IRQSTAT_C_TAPER_IRQ)) {
if (irqstat_c & IRQSTAT_C_TERMINATION_STAT)
power_supply_changed(>battery);
+ dev_dbg(smb->dev, "going to HW maintenance mode\n");
+ handled = true;
+ }
+
+ /*
+* If we got a charger timeout INT that means the charge
+* full is not detected with in charge timeout value.
+*/
+ if (irqstat_d & IRQSTAT_D_CHARGE_TIMEOUT_IRQ) {
+ dev_dbg(smb->dev, "total Charge Timeout INT received\n");
+
+ if (irqstat_d & IRQSTAT_D_CHARGE_TIMEOUT_STAT)
+ dev_warn(smb->dev, "charging stopped due to timeout\n");
+ power_supply_changed(>battery);
handled = true;
}
@@ -776,6 +800,7 @@ static int smb347_irq_set(struct smb347_charger *smb, bool
enable)
* Enable/disable interrupts for:
* - under voltage
* - termination current reached
+* - charger timeout
* - charger error
*/
ret = regmap_update_bits(smb->regmap, CFG_FAULT_IRQ, 0xff,
@@ -784,7 +809,8 @@ static int smb347_irq_set(struct smb347_charger *smb, bool
enable)
goto fail;
ret = regmap_update_bits(smb->regmap, CFG_STATUS_IRQ, 0xff,
- enable ? CFG_STATUS_IRQ_TERMINATION_OR_TAPER : 0);
+ enable ?
linux-next: manual merge of the rcu tree with the tip tree
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in arch/Kconfig
between commit b952741c8079 ("cputime: Generalize
CONFIG_VIRT_CPU_ACCOUNTING") from the tip tree and commit 3dbdfc26e27f
("rcu: Settle config for userspace extended quiescent state") from the
rcu tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/Kconfig
index 07db929,1c7c9be..000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -294,26 -274,14 +294,36 @@@ config SECCOMP_FILTE
See Documentation/prctl/seccomp_filter.txt for details.
+config HAVE_MOD_ARCH_SPECIFIC
+ bool
+ help
+The arch uses struct mod_arch_specific to store data. Many arches
+just need a simple module loader without arch specific data - those
+should not enable this.
+
+config MODULES_USE_ELF_RELA
+ bool
+ help
+Modules only use ELF RELA relocations. Modules with ELF REL
+relocations will give an error.
+
+config MODULES_USE_ELF_REL
+ bool
+ help
+Modules only use ELF REL relocations. Modules with ELF RELA
+relocations will give an error.
+
+config HAVE_VIRT_CPU_ACCOUNTING
+ bool
+
+ config HAVE_RCU_USER_QS
+ bool
+ help
+ Provide kernel entry/exit hooks necessary for userspace
+ RCU extended quiescent state. Syscalls need to be wrapped inside
+ rcu_user_exit()-rcu_user_enter() through the slow path using
+ TIF_NOHZ flag. Exceptions handlers must be wrapped as well. Irqs
+ are already protected inside rcu_irq_enter/rcu_irq_exit() but
+ preemption or signal handling on irq exit still need to be protected.
+
source "kernel/gcov/Kconfig"
pgp325J4d8hFH.pgp
Description: PGP signature
Re: [PATCH 2/5] trace-cmd: Use tracing directory to count CPUs
(2012/08/23 11:01), Masami Hiramatsu wrote: > (2012/08/22 22:41), Steven Rostedt wrote: >> On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote: >>> From: Masami Hiramatsu >>> >>> Count debugfs/tracing/per_cpu/cpu* to determine the >>> number of CPUs. >> >> I'm curious, do you find that sysconf doesn't return the # of CPUs the >> system has? > > No, sysconf returns the number of hosts CPUs, not guests. > >> I've had boxes where the per_cpu/cpu* had more cpus than the >> box actually holds. But this was a bug in the kernel, not the tool. This >> change log needs to have rational instead of just explaining what the >> patch does. > > Ah, I see. Hmm, then this should be enabled by a command line > option or an environment variable. Oops, I misunderstood. I'll add more comment for why this should be tried instead of sysconf. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology 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/
Re: [PATCH] power_supply: Add new power supply AUTHENTIC property
On Thu, Aug 23, 2012 at 06:50:21AM +0530, Ramakrishna Pallala wrote: > It is possible that users can use non-standard chargers > or use invalid batteries especially with mobile devices. > > This patch adds a new power supply property called 'AUTHENTIC' to > indicate this to the user(user space). > > Signed-off-by: Ramakrishna Pallala > --- Applied, thanks a lot! > Documentation/power/power_supply_class.txt |3 +++ > drivers/power/power_supply_sysfs.c |1 + > include/linux/power_supply.h |1 + > 3 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/Documentation/power/power_supply_class.txt > b/Documentation/power/power_supply_class.txt > index 2f0ddc1..29a1fcd 100644 > --- a/Documentation/power/power_supply_class.txt > +++ b/Documentation/power/power_supply_class.txt > @@ -81,6 +81,9 @@ This defines trickle and fast charges. For batteries that > are already charged or discharging, 'n/a' can be displayed (or > 'unknown', if the status is not known). > > +AUTHENTIC - indicates the power supp(battery or charger) connected Had to fix s/supp/supply/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ds2781_battery: convert to module_platform_driver
On Mon, Jul 30, 2012 at 04:29:10PM +0545, Devendra Naga wrote:
> module_platform_driver can be used to replace the
> platform_driver register and unregister functions,
> with the calls to module_init and module_exit,
>
> i.e. all the code that is doing like the below
>
> static int __init mymod_init(void)
> {
> return platform_driver_register(_operations);
> }
>
> static void __exit mymod_exit(void)
> {
> platform_driver_unregister(_operations);
> }
>
> module_init(mymod_init);
> module_exit(mymod_exit);
>
> can be replaced with
> module_platform_driver(drv_operations)...
>
> Signed-off-by: Devendra Naga
Nice! Both patches applied, thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the rr tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in arch/Kconfig
between commit bd029f48459a ("Make most arch asm/module.h files use
asm-generic/module.h") from the rr tree and commit b952741c8079
("cputime: Generalize CONFIG_VIRT_CPU_ACCOUNTING") from the tip tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/Kconfig
index 3450115,ea5feb6..000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -281,23 -294,7 +294,26 @@@ config SECCOMP_FILTE
See Documentation/prctl/seccomp_filter.txt for details.
+config HAVE_MOD_ARCH_SPECIFIC
+ bool
+ help
+The arch uses struct mod_arch_specific to store data. Many arches
+just need a simple module loader without arch specific data - those
+should not enable this.
+
+config MODULES_USE_ELF_RELA
+ bool
+ help
+Modules only use ELF RELA relocations. Modules with ELF REL
+relocations will give an error.
+
+config MODULES_USE_ELF_REL
+ bool
+ help
+Modules only use ELF REL relocations. Modules with ELF RELA
+relocations will give an error.
+
+ config HAVE_VIRT_CPU_ACCOUNTING
+ bool
+
source "kernel/gcov/Kconfig"
pgp3T6DDsZ0Wv.pgp
Description: PGP signature
Re: [PATCH] twl4030: It would be better not to use the 0b-prefix.
On Fri, Aug 17, 2012 at 07:30:46PM +1000, NeilBrown wrote: [...] > > -#define TWL4030_BBISEL_1000uA 0b11 > > +#define TWL4030_BBSEL_MASK 0x0c [...] > Thanks. I'd been meaning to send that patch, but life got in the way > recently. > > Acked-by: NeilBrown Thanks! Applied. -- 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] power_supply: Add new power supply AUTHENTIC property
It is possible that users can use non-standard chargers
or use invalid batteries especially with mobile devices.
This patch adds a new power supply property called 'AUTHENTIC' to
indicate this to the user(user space).
Signed-off-by: Ramakrishna Pallala
---
Documentation/power/power_supply_class.txt |3 +++
drivers/power/power_supply_sysfs.c |1 +
include/linux/power_supply.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 2f0ddc1..29a1fcd 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -81,6 +81,9 @@ This defines trickle and fast charges. For batteries that
are already charged or discharging, 'n/a' can be displayed (or
'unknown', if the status is not known).
+AUTHENTIC - indicates the power supp(battery or charger) connected
+to the platform is authentic(1) or non authentic(0).
+
HEALTH - represents health of the battery, values corresponds to
POWER_SUPPLY_HEALTH_*, defined in battery.h.
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 1d96614..be34a6d 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -138,6 +138,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(health),
POWER_SUPPLY_ATTR(present),
POWER_SUPPLY_ATTR(online),
+ POWER_SUPPLY_ATTR(authentic),
POWER_SUPPLY_ATTR(technology),
POWER_SUPPLY_ATTR(cycle_count),
POWER_SUPPLY_ATTR(voltage_max),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 3cfee0c..729768c 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -88,6 +88,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_AUTHENTIC,
POWER_SUPPLY_PROP_TECHNOLOGY,
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_VOLTAGE_MAX,
--
1.7.0.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 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote: > On i.MX6, we select ARM_CPU_SUSPEND when building with power management > support, but for some reason this was omitted on i.MX5. Normally we > build kernels for both together so the error only showed up in > randconfig tests. > > Without this patch, building imx5 standalone results in: > > arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume': > arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume' > So far, none of the functions in head-v7.S is used on imx5. Also since imx5 SoCs implement State Retention Power Gating in hardware, ARM_CPU_SUSPEND support will never be used on imx5. Maybe we should make head-v7.S only compile for imx6? Regards, Shawn > Signed-off-by: Arnd Bergmann > Cc: Eric Miao > Cc: Shawn Guo > Cc: sta...@vger.kernel.org > --- > arch/arm/mach-imx/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig > index afd542a..8e96573 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -89,6 +89,7 @@ config SOC_IMX5 > select ARCH_MXC_IOMUX_V3 > select ARCH_HAS_CPUFREQ > select ARCH_MX5 > + select ARM_CPU_SUSPEND if PM > bool > > config SOC_IMX50 > -- > 1.7.10 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power_supply: Remove broken mark for da9052-battery
On Wed, Aug 08, 2012 at 04:08:18PM +0800, Axel Lin wrote:
> The fix for MFD part is already merged so we can remove the broken mark
> for da9052-battery.
>
> Signed-off-by: Axel Lin
> ---
[...]
> - depends on BROKEN
Applied, thanks a lot!
Though, I had to apply the following right after:
commit bc909f27f55ceb8f950ced5cf3a26d6b26e86ca6
Author: Anton Vorontsov
Date: Wed Aug 22 19:29:44 2012 -0700
da9052-battery: Fix da9052_determine_vc_tbl_index's return value
The patch fixes the following warnings:
CHECK drivers/power/da9052-battery.c
drivers/power/da9052-battery.c:330:15: warning: symbol
'da9052_determine_vc_tbl_index' was not declared. Should it be static?
CC drivers/power/da9052-battery.o
drivers/power/da9052-battery.c: In function 'da9052_determine_vc_tbl_index':
drivers/power/da9052-battery.c:348:1: warning: control reaches end of
non-void function [-Wreturn-type]
Signed-off-by: Anton Vorontsov
diff --git a/drivers/power/da9052-battery.c b/drivers/power/da9052-battery.c
index a5f6a0e..20b86ed 100644
--- a/drivers/power/da9052-battery.c
+++ b/drivers/power/da9052-battery.c
@@ -327,7 +327,7 @@ static int da9052_bat_interpolate(int vbat_lower, int
vbat_upper,
return tmp;
}
-unsigned char da9052_determine_vc_tbl_index(unsigned char adc_temp)
+static unsigned char da9052_determine_vc_tbl_index(unsigned char adc_temp)
{
int i;
@@ -345,6 +345,13 @@ unsigned char da9052_determine_vc_tbl_index(unsigned char
adc_temp)
&& (adc_temp <= vc_tbl_ref[i]))
return i + 1;
}
+ /*
+* For some reason authors of the driver didn't presume that we can
+* end up here. It might be OK, but might be not, no one knows for
+* sure. Go check your battery, is it on fire?
+*/
+ WARN_ON(1);
+ return 0;
}
static int da9052_bat_read_capacity(struct da9052_battery *bat, int *capacity)
--
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: Unable to mount NFSROOT: pcie change breaks e1000?
On Thu, Aug 23, 2012 at 09:31:32AM +0800, Jiang Liu wrote:
> Hi Fengguang,
> Could you please help to verify whether following patch
> fixes the issue?
It works! Thank you for the quick fix!
Tested-by: Fengguang Wu
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index f6b491b..fac08f5 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -842,6 +842,9 @@ static int pci_save_pcie_state(struct pci_dev *dev)
> struct pci_cap_saved_state *save_state;
> u16 *cap;
>
> + if (!pci_is_pcie(dev))
> + return 0;
> +
> save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> if (!save_state) {
> dev_err(>dev, "buffer not found in %s\n", __func__);
>
> On 2012-8-23 8:46, Fengguang Wu wrote:
> > buffer not found
>
--
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 74/74] lto, workaround: Mark do_futex noinline to prevent clobbering ebp
> The right thing to do is to change head_32.S to not violate the i386 > ABI. Arguments pushed (by value) on the stack are property of the > callee, that is, they are volatile, so the hack of making them do double > duty as both being saved and passed as arguments is just plain bogus. > The problem is that it works "just well enough" that people (including > myself) keep hacking around it with hacks like this, with assembly > macros, and whatnot instead of fixing the root cause. How about just use register arguments for the first three arguments. This should work for the syscalls at least (may be too risky for all other asm entry points) And for syscalls with more than three generate a stub that saves on the stack explicitely. This could be done using the new fancy SYSCALL definition macros (except that arch/x86 would need to start using them too in its own code) Or is there some subtle reason with syscall restart and updated args that prevents it? Perhaps newer gcc can do regparm(X), X > 3 too, may be worth trying. Don't have time to look into this currently though. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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 v9 6/6] allower the user to disable pv event support
Signed-off-by: Wen Congyang
---
hw/pc_piix.c|6 +-
qemu-config.c |4
qemu-options.hx |3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index f73fb85..76d3de1 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -151,6 +151,8 @@ static void pc_init1(MemoryRegion *system_memory,
MemoryRegion *pci_memory;
MemoryRegion *rom_memory;
void *fw_cfg = NULL;
+QemuOptsList *list = qemu_find_opts("machine");
+bool enable_pv_event;
pc_cpus_init(cpu_model);
@@ -289,8 +291,10 @@ static void pc_init1(MemoryRegion *system_memory,
pc_pci_device_init(pci_bus);
}
+enable_pv_event = qemu_opt_get_bool(QTAILQ_FIRST(>head),
+"enable_pv_event", false);
#ifdef KVM_PV_EVENT_PORT
-if (kvm_enabled()) {
+if (kvm_enabled() && enable_pv_event) {
kvm_pv_event_init(isa_bus);
}
#endif
diff --git a/qemu-config.c b/qemu-config.c
index c05ffbc..a58bf71 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -612,6 +612,10 @@ static QemuOptsList qemu_machine_opts = {
.name = "dump-guest-core",
.type = QEMU_OPT_BOOL,
.help = "Include guest memory in a core dump",
+}, {
+.name = "enable_pv_event",
+.type = QEMU_OPT_BOOL,
+.help = "handle pv event"
},
{ /* End of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 3c411c4..c825d66 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -38,7 +38,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
"supported accelerators are kvm, xen, tcg (default: tcg)\n"
"kernel_irqchip=on|off controls accelerated irqchip
support\n"
"kvm_shadow_mem=size of KVM shadow MMU\n"
-"dump-guest-core=on|off include guest memory in a core
dump (default=on)\n",
+"dump-guest-core=on|off include guest memory in a core
dump (default=on)\n"
+"enable_pv_event=on|off controls pv event support\n",
QEMU_ARCH_ALL)
STEXI
@item -machine [type=]@var{name}[,prop=@var{value}[,...]]
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 5/6] introduce a new qom device to deal with panicked event
If the target is x86/x86_64, the guest's kernel will write 0x01 to the
port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
event according to panicked_action's value. The possible actions are:
1. emit QEVENT_GUEST_PANICKED only
2. emit QEVENT_GUEST_PANICKED and pause the guest
3. emit QEVENT_GUEST_PANICKED and poweroff the guest
4. emit QEVENT_GUEST_PANICKED and reset the guest
I/O ports does not work for some targets(for example: s390). And you
can implement another qom device, and include it's code into pv_event.c
for such target.
Note: if we emit QEVENT_GUEST_PANICKED only, and the management
application does not receive this event(the management may not
run when the event is emitted), the management won't know the
guest is panicked.
Signed-off-by: Wen Congyang
---
hw/kvm/Makefile.objs |2 +-
hw/kvm/pv_event.c| 190 ++
hw/pc_piix.c |9 +++
kvm.h|2 +
4 files changed, 202 insertions(+), 1 deletions(-)
create mode 100644 hw/kvm/pv_event.c
diff --git a/hw/kvm/Makefile.objs b/hw/kvm/Makefile.objs
index 226497a..23e3b30 100644
--- a/hw/kvm/Makefile.objs
+++ b/hw/kvm/Makefile.objs
@@ -1 +1 @@
-obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o
+obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pv_event.o
diff --git a/hw/kvm/pv_event.c b/hw/kvm/pv_event.c
new file mode 100644
index 000..c03dd22
--- /dev/null
+++ b/hw/kvm/pv_event.c
@@ -0,0 +1,190 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ * Wen Congyang
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Possible values for action parameter. */
+#define PANICKED_REPORT 1 /* emit QEVENT_GUEST_PANICKED only */
+#define PANICKED_PAUSE 2 /* emit QEVENT_GUEST_PANICKED and pause VM */
+#define PANICKED_POWEROFF 3 /* emit QEVENT_GUEST_PANICKED and quit VM */
+#define PANICKED_RESET 4 /* emit QEVENT_GUEST_PANICKED and reset VM */
+
+#define PV_EVENT_DRIVER "kvm_pv_event"
+
+struct PVEventAction {
+char *panicked_action;
+int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf) \
+DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+static void panicked_mon_event(const char *action)
+{
+QObject *data;
+
+data = qobject_from_jsonf("{ 'action': %s }", action);
+monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
+qobject_decref(data);
+}
+
+static void panicked_perform_action(uint32_t panicked_action)
+{
+switch (panicked_action) {
+case PANICKED_REPORT:
+panicked_mon_event("report");
+break;
+
+case PANICKED_PAUSE:
+panicked_mon_event("pause");
+vm_stop(RUN_STATE_GUEST_PANICKED);
+break;
+
+case PANICKED_POWEROFF:
+panicked_mon_event("poweroff");
+qemu_system_shutdown_request();
+break;
+
+case PANICKED_RESET:
+panicked_mon_event("reset");
+qemu_system_reset_request();
+break;
+}
+}
+
+static uint64_t supported_event(void)
+{
+return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct PVEventAction *conf)
+{
+if (event == KVM_PV_EVENT_PANICKED) {
+panicked_perform_action(conf->panicked_action_value);
+}
+}
+
+static int pv_event_init(struct PVEventAction *conf)
+{
+if (!conf->panicked_action) {
+conf->panicked_action_value = PANICKED_REPORT;
+} else if (strcasecmp(conf->panicked_action, "none") == 0) {
+conf->panicked_action_value = PANICKED_REPORT;
+} else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+conf->panicked_action_value = PANICKED_PAUSE;
+} else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+conf->panicked_action_value = PANICKED_POWEROFF;
+} else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+conf->panicked_action_value = PANICKED_RESET;
+} else {
+return -1;
+}
+
+return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include "hw/isa.h"
+
+typedef struct {
+ISADevice dev;
+struct PVEventAction conf;
+MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, target_phys_addr_t addr, unsigned
size)
+{
+return supported_event();
+}
+
+static void pv_io_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+unsigned size)
+{
+PVIOPortState *s = opaque;
+
+handle_event(val, >conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+.read = pv_io_read,
+.write = pv_io_write,
+.impl = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
[PATCH v9 4/6] add a new qevent: QEVENT_GUEST_PANICKED
This event will be emited when the guest is panicked.
Signed-off-by: Wen Congyang
---
monitor.c |1 +
monitor.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index 480f583..cd2adb7 100644
--- a/monitor.c
+++ b/monitor.c
@@ -455,6 +455,7 @@ static const char *monitor_event_names[] = {
[QEVENT_SUSPEND_DISK] = "SUSPEND_DISK",
[QEVENT_WAKEUP] = "WAKEUP",
[QEVENT_BALLOON_CHANGE] = "BALLOON_CHANGE",
+[QEVENT_GUEST_PANICKED] = "GUEST_PANICKED",
};
QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
diff --git a/monitor.h b/monitor.h
index 47d556b..f48a502 100644
--- a/monitor.h
+++ b/monitor.h
@@ -43,6 +43,7 @@ typedef enum MonitorEvent {
QEVENT_SUSPEND_DISK,
QEVENT_WAKEUP,
QEVENT_BALLOON_CHANGE,
+QEVENT_GUEST_PANICKED,
/* Add to 'monitor_event_names' array in monitor.c when
* defining new events here */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
The guest will be in this state when it is panicked.
Signed-off-by: Wen Congyang
---
qapi-schema.json |6 +-
qmp.c|3 ++-
vl.c |7 ++-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index bd8ad74..edb090a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -149,11 +149,15 @@
# @suspended: guest is suspended (ACPI S3)
#
# @watchdog: the watchdog action is configured to pause and has been triggered
+#
+# @guest-panicked: the panicked action is configured to pause and has been
+# triggered.
##
{ 'enum': 'RunState',
'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
+'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
+'guest-panicked' ] }
##
# @StatusInfo:
diff --git a/qmp.c b/qmp.c
index c5a20f1..f863f56 100644
--- a/qmp.c
+++ b/qmp.c
@@ -148,7 +148,8 @@ void qmp_cont(Error **errp)
error_set(errp, QERR_MIGRATION_EXPECTED);
return;
} else if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
- runstate_check(RUN_STATE_SHUTDOWN)) {
+ runstate_check(RUN_STATE_SHUTDOWN) ||
+ runstate_check(RUN_STATE_GUEST_PANICKED)) {
error_set(errp, QERR_RESET_REQUIRED);
return;
} else if (runstate_check(RUN_STATE_SUSPENDED)) {
diff --git a/vl.c b/vl.c
index 316a977..947b23a 100644
--- a/vl.c
+++ b/vl.c
@@ -373,6 +373,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
{ RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
{ RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
+{ RUN_STATE_RUNNING, RUN_STATE_GUEST_PANICKED },
{ RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
@@ -387,6 +388,9 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
{ RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
+{ RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
+{ RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },
+
{ RUN_STATE_MAX, RUN_STATE_MAX },
};
@@ -1607,7 +1611,8 @@ static bool main_loop_should_exit(void)
qemu_system_reset(VMRESET_REPORT);
resume_all_vcpus();
if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-runstate_check(RUN_STATE_SHUTDOWN)) {
+runstate_check(RUN_STATE_SHUTDOWN) ||
+runstate_check(RUN_STATE_GUEST_PANICKED)) {
bdrv_iterate(iostatus_bdrv_it, NULL);
vm_start();
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 2/6] kvm: Update kernel headers
Corresponding kvm.git hash: 35f2d16b with my patch for kvm
---
linux-headers/asm-s390/kvm.h |2 +-
linux-headers/asm-s390/kvm_para.h |2 +-
linux-headers/asm-x86/kvm.h |1 +
linux-headers/asm-x86/kvm_para.h |9 +
linux-headers/linux/kvm.h |3 +++
linux-headers/linux/kvm_para.h|6 ++
6 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index bdcbe0f..d25da59 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -1,7 +1,7 @@
#ifndef __LINUX_KVM_S390_H
#define __LINUX_KVM_S390_H
/*
- * asm-s390/kvm.h - KVM s390 specific structures and definitions
+ * KVM s390 specific structures and definitions
*
* Copyright IBM Corp. 2008
*
diff --git a/linux-headers/asm-s390/kvm_para.h
b/linux-headers/asm-s390/kvm_para.h
index 8e2dd67..870051f 100644
--- a/linux-headers/asm-s390/kvm_para.h
+++ b/linux-headers/asm-s390/kvm_para.h
@@ -1,5 +1,5 @@
/*
- * asm-s390/kvm_para.h - definition for paravirtual devices on s390
+ * definition for paravirtual devices on s390
*
* Copyright IBM Corp. 2008
*
diff --git a/linux-headers/asm-x86/kvm.h b/linux-headers/asm-x86/kvm.h
index e7d1c19..246617e 100644
--- a/linux-headers/asm-x86/kvm.h
+++ b/linux-headers/asm-x86/kvm.h
@@ -12,6 +12,7 @@
/* Select x86 specific features in */
#define __KVM_HAVE_PIT
#define __KVM_HAVE_IOAPIC
+#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_DEVICE_ASSIGNMENT
#define __KVM_HAVE_MSI
#define __KVM_HAVE_USER_NMI
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index f2ac46a..53aca59 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -22,6 +22,7 @@
#define KVM_FEATURE_CLOCKSOURCE23
#define KVM_FEATURE_ASYNC_PF 4
#define KVM_FEATURE_STEAL_TIME 5
+#define KVM_FEATURE_PV_EOI 6
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
@@ -37,6 +38,7 @@
#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
#define MSR_KVM_STEAL_TIME 0x4b564d03
+#define MSR_KVM_PV_EOI_EN 0x4b564d04
struct kvm_steal_time {
__u64 steal;
@@ -89,5 +91,12 @@ struct kvm_vcpu_pv_apf_data {
__u32 enabled;
};
+#define KVM_PV_EOI_BIT 0
+#define KVM_PV_EOI_MASK (0x1 << KVM_PV_EOI_BIT)
+#define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
+#define KVM_PV_EOI_DISABLED 0x0
+
+#define KVM_PV_EVENT_PORT (0x505UL)
+
#endif /* _ASM_X86_KVM_PARA_H */
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 5a9d4e3..4b9e575 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -617,6 +617,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_SIGNAL_MSI 77
#define KVM_CAP_PPC_GET_SMMU_INFO 78
#define KVM_CAP_S390_COW 79
+#define KVM_CAP_PPC_ALLOC_HTAB 80
#ifdef KVM_CAP_IRQ_ROUTING
@@ -828,6 +829,8 @@ struct kvm_s390_ucas_mapping {
#define KVM_SIGNAL_MSI_IOW(KVMIO, 0xa5, struct kvm_msi)
/* Available with KVM_CAP_PPC_GET_SMMU_INFO */
#define KVM_PPC_GET_SMMU_INFO_IOR(KVMIO, 0xa6, struct kvm_ppc_smmu_info)
+/* Available with KVM_CAP_PPC_ALLOC_HTAB */
+#define KVM_PPC_ALLOCATE_HTAB_IOWR(KVMIO, 0xa7, __u32)
/*
* ioctls for vcpu fds
diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
index 7bdcf93..f6be0bb 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -20,6 +20,12 @@
#define KVM_HC_FEATURES3
#define KVM_HC_PPC_MAP_MAGIC_PAGE 4
+/* The bit of supported pv event */
+#define KVM_PV_FEATURE_PANICKED0
+
+/* The pv event value */
+#define KVM_PV_EVENT_PANICKED 1
+
/*
* hypercalls use architecture specific
*/
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/6] start vm after reseting it
The guest should run after reseting it, but it does not run if its
old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.
We don't set runstate to RUN_STATE_PAUSED when reseting the guest,
so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or
RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).
Signed-off-by: Wen Congyang
---
block.h |2 ++
qmp.c |2 +-
vl.c|7 ---
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/block.h b/block.h
index 2e2be11..c3265c2 100644
--- a/block.h
+++ b/block.h
@@ -339,6 +339,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
void bdrv_set_in_use(BlockDriverState *bs, int in_use);
int bdrv_in_use(BlockDriverState *bs);
+void iostatus_bdrv_it(void *opaque, BlockDriverState *bs);
+
enum BlockAcctType {
BDRV_ACCT_READ,
BDRV_ACCT_WRITE,
diff --git a/qmp.c b/qmp.c
index 8463922..c5a20f1 100644
--- a/qmp.c
+++ b/qmp.c
@@ -125,7 +125,7 @@ SpiceInfo *qmp_query_spice(Error **errp)
};
#endif
-static void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
+void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
{
bdrv_iostatus_reset(bs);
}
diff --git a/vl.c b/vl.c
index 7c577fa..316a977 100644
--- a/vl.c
+++ b/vl.c
@@ -343,7 +343,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
{ RUN_STATE_INMIGRATE, RUN_STATE_PRELAUNCH },
-{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED },
+{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_RUNNING },
{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
{ RUN_STATE_IO_ERROR, RUN_STATE_RUNNING },
@@ -376,7 +376,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
-{ RUN_STATE_SHUTDOWN, RUN_STATE_PAUSED },
+{ RUN_STATE_SHUTDOWN, RUN_STATE_RUNNING },
{ RUN_STATE_SHUTDOWN, RUN_STATE_FINISH_MIGRATE },
{ RUN_STATE_DEBUG, RUN_STATE_SUSPENDED },
@@ -1608,7 +1608,8 @@ static bool main_loop_should_exit(void)
resume_all_vcpus();
if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
runstate_check(RUN_STATE_SHUTDOWN)) {
-runstate_set(RUN_STATE_PAUSED);
+bdrv_iterate(iostatus_bdrv_it, NULL);
+vm_start();
}
}
if (qemu_wakeup_requested()) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9] kvm: notify host when the guest is panicked
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
Signed-off-by: Wen Congyang
---
Documentation/virtual/kvm/pv_event.txt | 32
arch/ia64/include/asm/kvm_para.h | 14 ++
arch/powerpc/include/asm/kvm_para.h| 14 ++
arch/s390/include/asm/kvm_para.h | 14 ++
arch/x86/include/asm/kvm_para.h| 27 +++
arch/x86/kernel/kvm.c | 25 +
include/linux/kvm_para.h | 23 +++
7 files changed, 149 insertions(+), 0 deletions(-)
create mode 100644 Documentation/virtual/kvm/pv_event.txt
diff --git a/Documentation/virtual/kvm/pv_event.txt
b/Documentation/virtual/kvm/pv_event.txt
new file mode 100644
index 000..1b9fc4c
--- /dev/null
+++ b/Documentation/virtual/kvm/pv_event.txt
@@ -0,0 +1,32 @@
+The KVM paravirtual event interface
+=
+
+Initializing the paravirtual event interface
+==
+kvm_pv_event_init()
+Argiments:
+ None
+
+Return Value:
+ 0 : The guest kernel can use paravirtual event interface.
+ -1: The guest kernel can't use paravirtual event interface.
+
+Querying whether the event can be ejected
+==
+kvm_pv_has_feature()
+Arguments:
+ feature: The bit value of this paravirtual event to query
+
+Return Value:
+ 0: The guest kernel can't eject this paravirtual event.
+ 1: The guest kernel can eject this paravirtual event.
+
+
+Ejecting paravirtual event
+==
+kvm_pv_eject_event()
+Arguments:
+ event: The event to be ejected.
+
+Return Value:
+ None
diff --git a/arch/ia64/include/asm/kvm_para.h b/arch/ia64/include/asm/kvm_para.h
index 2019cb9..b5ec658 100644
--- a/arch/ia64/include/asm/kvm_para.h
+++ b/arch/ia64/include/asm/kvm_para.h
@@ -31,6 +31,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
return false;
}
+static inline int kvm_arch_pv_event_init(void)
+{
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
#endif
#endif
diff --git a/arch/powerpc/include/asm/kvm_para.h
b/arch/powerpc/include/asm/kvm_para.h
index c18916b..01b98c7 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -211,6 +211,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
return false;
}
+static inline int kvm_arch_pv_event_init(void)
+{
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
#endif /* __KERNEL__ */
#endif /* __POWERPC_KVM_PARA_H__ */
diff --git a/arch/s390/include/asm/kvm_para.h b/arch/s390/include/asm/kvm_para.h
index da44867..00ce058 100644
--- a/arch/s390/include/asm/kvm_para.h
+++ b/arch/s390/include/asm/kvm_para.h
@@ -154,6 +154,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
return false;
}
+static inline int kvm_arch_pv_event_init(void)
+{
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
#endif
#endif /* __S390_KVM_PARA_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 2f7712e..7d297f0 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -96,8 +96,11 @@ struct kvm_vcpu_pv_apf_data {
#define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
#define KVM_PV_EOI_DISABLED 0x0
+#define KVM_PV_EVENT_PORT (0x505UL)
+
#ifdef __KERNEL__
#include
+#include
extern void kvmclock_init(void);
extern int kvm_register_clock(char *txt);
@@ -228,6 +231,30 @@ static inline void kvm_disable_steal_time(void)
}
#endif
+static inline int kvm_arch_pv_event_init(void)
+{
+ if (!request_region(KVM_PV_EVENT_PORT, 1, "KVM_PV_EVENT"))
+ return -1;
+
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ unsigned int features = inl(KVM_PV_EVENT_PORT);
+
+ /* Reading from an invalid I/O port will return -1 */
+ if (features == ~0)
+ features = 0;
+
+ return features;
+}
+
Re: [PATCH 2/2] lp8727_charger: unregister power supply at error path of lp8727_register_psy
On Mon, Jul 30, 2012 at 04:47:44AM +, Pallala, Ramakrishna wrote: > > if (power_supply_register(pchg->dev, >usb)) > > - goto err_psy; > > + goto err_psy_ac; > > "err_psy_ac" label name is confusing. Why can't you use err_psy_usb > > > if (power_supply_register(pchg->dev, >batt)) > > - goto err_psy; > > + goto err_psy_usb; > > Same here, why don't you use err_psy_batt Thanks, folks! It was easy to change so I applied the following: commit 6297b5e54b5511d4e72e8d5fc3b139650adc74d8 Author: Devendra Naga Date: Sun Jul 29 23:31:55 2012 +0545 lp8727_charger: Unregister power supply at error path of lp8727_register_psy if usb power supply registration fails, we wont unregister the ac power supply if battery power supply registration fails, we wont unregister the usb, and ac supply, take care of those things and also no need of goto -err_mem: at the fail case of kzalloc simply can have return -ENOMEM Signed-off-by: Devendra Naga Signed-off-by: Anton Vorontsov diff --git a/drivers/power/lp8727_charger.c b/drivers/power/lp8727_charger.c index 6a364f4..4e37b26 100644 --- a/drivers/power/lp8727_charger.c +++ b/drivers/power/lp8727_charger.c @@ -362,7 +362,7 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy = kzalloc(sizeof(*psy), GFP_KERNEL); if (!psy) - goto err_mem; + return -ENOMEM; pchg->psy = psy; @@ -375,7 +375,7 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy->ac.num_supplicants = ARRAY_SIZE(battery_supplied_to); if (power_supply_register(pchg->dev, >ac)) - goto err_psy; + goto err_psy_ac; psy->usb.name = "usb"; psy->usb.type = POWER_SUPPLY_TYPE_USB; @@ -386,7 +386,7 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy->usb.num_supplicants = ARRAY_SIZE(battery_supplied_to); if (power_supply_register(pchg->dev, >usb)) - goto err_psy; + goto err_psy_usb; psy->batt.name = "main_batt"; psy->batt.type = POWER_SUPPLY_TYPE_BATTERY; @@ -396,13 +396,15 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy->batt.external_power_changed = lp8727_charger_changed; if (power_supply_register(pchg->dev, >batt)) - goto err_psy; + goto err_psy_batt; return 0; -err_mem: - return -ENOMEM; -err_psy: +err_psy_batt: + power_supply_unregister(>usb); +err_psy_usb: + power_supply_unregister(>ac); +err_psy_ac: kfree(psy); return -EPERM; } -- 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 1/5] mm: introduce a common interface for balloon pages mobility
On Wed, Aug 22, 2012 at 12:33:17PM +0300, Michael S. Tsirkin wrote: > Hmm, so this will busy wait which is unelegant. > We need some event IMO. No, it does not busy wait. leak_balloon() is mutual exclusive with migration steps, so for the case we have one racing against the other, we really want leak_balloon() dropping the mutex temporarily to allow migration complete its work of refilling vb->pages list. Also, leak_balloon() calls tell_host(), which will potentially make it to schedule for each round of vb->pfns leak_balloon() will release. So, when remove_common() calls leak_balloon() looping on vb->num_pages, that won't become a tight loop. The scheme was apparently working before this series, and it will remain working after it. > Also, reading num_pages without a lock here > which seems wrong. I'll protect it with vb->balloon_lock mutex. That will be consistent with the lock protection scheme this patch is introducing for struct virtio_balloon elements. > A similar concern applies to normal leaking > of the balloon: here we might leak less than > required, then wait for the next config change > event. Just as before, same thing here. If you leaked less than required, balloon() will keep calling leak_balloon() until the balloon target is reached. This scheme was working before, and it will keep working after this patch. > How about we signal config_change > event when pages are back to pages_list? I really don't know what to tell you here, but, to me, it seems like an overcomplication that isn't directly entangled with this patch purposes. Besides, you cannot expect compation / migration happening and racing against leak_balloon() all the time to make them signal events to the later, so we might just be creating a wait-forever condition for leak_balloon(), IMHO. Cheers! -- 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/
[v2][PATCH 3/3] powerpc/kgdb: restore current_thread_info properly
For powerpc BooKE and e200, singlestep is handled on the critical/dbg
exception stack. This causes current_thread_info() to fail for kgdb
internal, so previously We work around this issue by copying
the thread_info from the kernel stack before calling kgdb_handle_exception,
and copying it back afterwards.
But actually we don't do this properly. We should backup current_thread_info
then restore that when exit.
Signed-off-by: Tiejun Chen
---
v2: fix a typo in patch head description.
arch/powerpc/kernel/kgdb.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 05adb69..c470a40 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/*
* This table contains the mapping between PowerPC hardware trap types, and
@@ -153,6 +154,8 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
static int kgdb_singlestep(struct pt_regs *regs)
{
struct thread_info *thread_info, *exception_thread_info;
+ struct thread_info *backup_current_thread_info = \
+ (struct thread_info *)kmalloc(sizeof(struct thread_info),
GFP_KERNEL);
if (user_mode(regs))
return 0;
@@ -170,13 +173,17 @@ static int kgdb_singlestep(struct pt_regs *regs)
thread_info = (struct thread_info *)(regs->gpr[1] & ~(THREAD_SIZE-1));
exception_thread_info = current_thread_info();
- if (thread_info != exception_thread_info)
+ if (thread_info != exception_thread_info) {
+ /* Save the original current_thread_info. */
+ memcpy(backup_current_thread_info, exception_thread_info,
sizeof *thread_info);
memcpy(exception_thread_info, thread_info, sizeof *thread_info);
+ }
kgdb_handle_exception(0, SIGTRAP, 0, regs);
if (thread_info != exception_thread_info)
- memcpy(thread_info, exception_thread_info, sizeof *thread_info);
+ /* Restore current_thread_info lastly. */
+ memcpy(exception_thread_info, backup_current_thread_info,
sizeof *thread_info);
return 1;
}
--
1.5.6
--
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/
[v2][PATCH 1/3] kgdb,ppc: do not set kgdb_single_step on ppc
The kgdb_single_step flag has the possibility to indefinitely hang the system on an SMP system. The x86 arch have the same problem, and that problem was fixed by commit 8097551d9ab9b9e3630(kgdb,x86: do not set kgdb_single_step on x86). This patch does the same behaviors as x86's patch. Signed-off-by: Dongdong Deng Signed-off-by: Jason Wessel --- v2: nothing changed. arch/powerpc/kernel/kgdb.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c index 782bd0a..bbabc5a 100644 --- a/arch/powerpc/kernel/kgdb.c +++ b/arch/powerpc/kernel/kgdb.c @@ -410,7 +410,6 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code, #else linux_regs->msr |= MSR_SE; #endif - kgdb_single_step = 1; atomic_set(_cpu_doing_single_step, raw_smp_processor_id()); } -- 1.5.6 -- 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/
[v2][PATCH 2/3] powerpc: Bail out of KGDB when we've been triggered
We need to skip a breakpoint exception when it occurs after
a breakpoint has already been removed.
Signed-off-by: Tiejun Chen
---
v2: simply kgdb_skipexception() return path.
arch/powerpc/kernel/kgdb.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index bbabc5a..05adb69 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -101,6 +101,21 @@ static int computeSignal(unsigned int tt)
return SIGHUP; /* default for things we don't know about */
}
+/**
+ *
+ * kgdb_skipexception - Bail out of KGDB when we've been triggered.
+ * @exception: Exception vector number
+ * @regs: Current pt_regs.
+ *
+ * On some architectures we need to skip a breakpoint exception when
+ * it occurs after a breakpoint has been removed.
+ *
+ */
+int kgdb_skipexception(int exception, struct pt_regs *regs)
+{
+ return kgdb_isremovedbreak(regs->nip);
+}
+
static int kgdb_call_nmi_hook(struct pt_regs *regs)
{
kgdb_nmicallback(raw_smp_processor_id(), regs);
--
1.5.6
--
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 0/8] netdev/MIPS: Improvements to octeon_mgmt Ethernet driver.
From: David Daney Date: Tue, 21 Aug 2012 11:45:04 -0700 > From: David Daney > > Recent additions to the OCTEON SoC family have included enhancements > to the MIX (octeon_mgmt) Ethernet hardware. These include: > > o 1Gig support (up from 100M). > > o Hardware timestamping for PTP. > > Here we add support for these two features as well as some ethtool > improvements and cleanup of the MAC address handling. > > Patch 1/8 is a prerequisite for the rest, and lives in the MIPS > architecture part of the tree. Since octeon_mgmt devices are only > found in OCTEON SoCs we could merge the whole set via Ralf's tree, or > get Ralf to affix his Acked-by and have it go via the netdev tree. You can send this all via the MIPS tree, and feel free to add my: Acked-by: David S. Miller -- 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 74/74] lto, workaround: Mark do_futex noinline to prevent clobbering ebp
On 08/22/2012 05:17 PM, H. Peter Anvin wrote: On 08/18/2012 07:57 PM, Andi Kleen wrote: From: Andi Kleen On a 32bit build gcc 4.7 with LTO decides to clobber the 6th argument on the stack. Unfortunately this corrupts the user EBP and leads to later crashes. For now mark do_futex noinline to prevent this. I wish there was a generic way to handle this. Seems like a ticking time bomb problem. There is a generic way to handle this. This is actually a bug in Linux that has been known for at least 15 years and which we keep hacking around. The right thing to do is to change head_32.S to not violate the i386 ABI. Arguments pushed (by value) on the stack are property of the callee, that is, they are volatile, so the hack of making them do double duty as both being saved and passed as arguments is just plain bogus. The problem is that it works "just well enough" that people (including myself) keep hacking around it with hacks like this, with assembly macros, and whatnot instead of fixing the root cause. -hpa Just a clarification (Andi knows this, I'm sure, but others might not): this wasn't done the way it is for no reason; back when Linus originally wrote the code, i386 passed *all* arguments on the stack, and we still do that for "asmlinkage" functions on i386. Since gcc back then rarely if ever mucked with the stack arguments, it made sense to make them "double duty." Fixing this really should entail changing the invocation of system calls on i386 to use the regparm convention, which means we only need to push three arguments twice, rather than six. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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] power_supply: Add new power supply VALID property
> On Sun, Jul 29, 2012 at 09:01:54AM +0530, Ramakrishna Pallala wrote: > > It is possible that users can use non-standard chargers or use invalid > > batteries especially with mobile devices. > > Maybe 'original' or 'authentic' would be a better term for this? > For me, 'valid' is kind of too broad and confusing. :-/ > > [...] > > +VALID - indicates the power supply connected is valid(1) or > > +invalid(0) > > + > > But if you still think that 'valid' is a better term, can you please document > it in > more detail? Authentic looks fine too. I will resubmit the patch with more details. Thanks, Ram
Re: [PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed
On Wed, Aug 22, 2012 at 05:13:09PM +0200, Arnd Bergmann wrote: > The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers, > so it needs to select that code to be built. This problem has > apparently existed since the i.MX cpufreq code was first merged > in v3.6.37. > s/v3.6.37/v2.6.37? Otherwise, Acked-by: Shawn Guo > Building IMX without CPU_FREQ_TABLE results in: > > arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit': > arch/arm/plat-mxc/cpufreq.c:173: undefined reference to > `cpufreq_frequency_table_put_attr' > arch/arm/plat-mxc/built-in.o: In function `mxc_set_target': > arch/arm/plat-mxc/cpufreq.c:84: undefined reference to > `cpufreq_frequency_table_target' > arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed': > arch/arm/plat-mxc/cpufreq.c:65: undefined reference to > `cpufreq_frequency_table_verify' > arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init': > arch/arm/plat-mxc/cpufreq.c:154: undefined reference to > `cpufreq_frequency_table_cpuinfo' > arch/arm/plat-mxc/cpufreq.c:162: undefined reference to > `cpufreq_frequency_table_get_attr' > > Signed-off-by: Arnd Bergmann > Cc: Sascha Hauer > Cc: Yong Shen > Cc: Shawn Guo > Cc: sta...@vger.kernel.org > --- > arch/arm/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e91c7cd..84b5a0c 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig" > config CPU_FREQ_IMX > tristate "CPUfreq driver for i.MX CPUs" > depends on ARCH_MXC && CPU_FREQ > + select CPU_FREQ_TABLE > help > This enables the CPUfreq driver for i.MX CPUs. > > -- > 1.7.10 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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 4/6] ARM: imx: fix ksz9021rn_phy_fixup
On Wed, Aug 22, 2012 at 05:13:08PM +0200, Arnd Bergmann wrote: > The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to > set up an ethernet phy if they can. They do check whether > phylib is enabled, but unfortunately the functions can only > be called from platform code if phylib is builtin, not > if it is a module > > Without this patch, building with a modular phylib results in: > > arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init': > arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared > (first use in this function) > arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is > reported only once for each function it appears in > > The bug was originally reported by Artem Bityutskiy but only > partially fixed in ef441806 "ARM: imx6q: register phy fixup only when > CONFIG_PHYLIB is enabled". > > Signed-off-by: Arnd Bergmann > Cc: Artem Bityutskiy > Cc: Shawn Guo > Cc: Sascha Hauer Acked-by: Shawn Guo -- 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/6] ARM: imx: build pm-imx5 code only when PM is enabled
On Wed, Aug 22, 2012 at 05:13:07PM +0200, Arnd Bergmann wrote: > This moves the imx5 pm code out of the list of unconditionally > compiled files for imx5, mirroring what we already do for imx6 > and how it was done before the code was move from mach-mx5 to > mach-imx in v3.3. > > Without this patch, building with CONFIG_PM disabled results in: > > arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init' > arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition > of 'imx51_pm_init' was here > arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init' > arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition > of 'imx53_pm_init' was here > > Signed-off-by: Arnd Bergmann > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: sta...@vger.kernel.org Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] powerpc: Bail out of KGDB when we've been triggered
On 08/22/2012 11:07 PM, Tabi Timur-B04825 wrote:
> On Wed, Aug 22, 2012 at 5:43 AM, Tiejun Chen
> wrote:
>
>> +int kgdb_skipexception(int exception, struct pt_regs *regs)
>> +{
>> + if (kgdb_isremovedbreak(regs->nip))
>> + return 1;
>> +
>> + return 0;
>> +}
>
> int kgdb_skipexception(int exception, struct pt_regs *regs)
> {
> return !!kgdb_isremovedbreak(regs->nip));
> }
>
> If the caller only cares about zero vs. non-zero, you can drop the !!.
Yes, so 'return kgdb_isremovedbreak(regs->nip);' is already fine and simple.
I'll update this as v2 so thanks your comment.
Tiejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] trace-cmd: Use tracing directory to count CPUs
(2012/08/22 22:41), Steven Rostedt wrote: > On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote: >> From: Masami Hiramatsu >> >> Count debugfs/tracing/per_cpu/cpu* to determine the >> number of CPUs. > > I'm curious, do you find that sysconf doesn't return the # of CPUs the > system has? No, sysconf returns the number of hosts CPUs, not guests. > I've had boxes where the per_cpu/cpu* had more cpus than the > box actually holds. But this was a bug in the kernel, not the tool. This > change log needs to have rational instead of just explaining what the > patch does. Ah, I see. Hmm, then this should be enabled by a command line option or an environment variable. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology 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/
Re: [PATCH] power_supply: Add new power supply VALID property
On Sun, Jul 29, 2012 at 09:01:54AM +0530, Ramakrishna Pallala wrote: > It is possible that users can use non-standard chargers > or use invalid batteries especially with mobile devices. Maybe 'original' or 'authentic' would be a better term for this? For me, 'valid' is kind of too broad and confusing. :-/ [...] > +VALID - indicates the power supply connected is valid(1) or invalid(0) > + But if you still think that 'valid' is a better term, can you please document it in more detail? Thanks! Anton. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/14] drivers/power/ab8500_btemp.c: fix error return code
On Sun, Aug 19, 2012 at 10:44:22AM +0200, Julia Lawall wrote:
> From: Julia Lawall
[...]
> Signed-off-by: Julia Lawall
2,3,4,5,6 applied, thanks!
> ---
> drivers/power/ab8500_btemp.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/power/ab8500_btemp.c b/drivers/power/ab8500_btemp.c
> index bba3cca..2b76943 100644
> --- a/drivers/power/ab8500_btemp.c
> +++ b/drivers/power/ab8500_btemp.c
> @@ -1014,6 +1014,7 @@ static int __devinit ab8500_btemp_probe(struct
> platform_device *pdev)
> create_singlethread_workqueue("ab8500_btemp_wq");
> if (di->btemp_wq == NULL) {
> dev_err(di->dev, "failed to create work queue\n");
> + ret = -ENOMEM;
> goto free_device_info;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/32] provide interfaces to access PCIe capabilities registers
On 08/22/2012 12:28 PM, Bjorn Helgaas wrote:
On Mon, Aug 20, 2012 at 9:40 PM, Cui, Dexuan wrote:
Bjorn Helgaas wrote on 2012-08-21:
I am still concerned about reset_intel_82599_sfp_virtfn(). It looks
wrong and possibly unnecessary. It looks wrong because it sets
PCI_EXP_DEVCTL_BCR_FLR and blindly clears all other bits in
PCI_EXP_DEVCTL. Most of the bits are probably cleared by the FLR
anyway, but Aux Power PM Enable is RWS ("sticky"), so it is *not*
modified by FLR. Therefore, using reset_intel_82599_sfp_virtfn() has
the probably unintended side effect of clearing Aux Power PM Enable.
It looks possibly unnecessary because the generic pcie_flr() does
essentially the same thing, so it's not clear why we need a special
case for 82599.
I think reset_intel_82599_sfp_virtfn() is correct AND necessary.
(pcie_flr() doesn't work here)
Please note the 82599 VF is a special PCIe device that doesn't report
PCIe FLR capability though actually it does support that.
That is why we put it in quirks.c. :-)
The PCI_EXP_DEVCTL_AUX_PME bit of the 82599 VF is read-only and
always zero.
Please see
http://www.intel.com/content/dam/doc/datasheet/82599-10-gbe-controller-datasheet.pdf
9.5 Virtual Functions Configuration Space
Table 9.7 VF PCIe Configuration Space
9.5.2.2.1 VF Device Control Register (0xA8; RW)
Thanks, Dexuan!
The 82599 does report FLR in the DEVCAP for the PF (sec 9.3.10.4), but
not in the DEVCAP for the VF (sec 9.5), which indeed means we can't
use pcie_flr() on the VFs. I wonder whether this error appears in any
other devices.
It should not exist in any other VF device. The SRIOV spec states
that all VFs must support FLR. The 82599 quirk is just that...
The VF DEVCTL register (sec 9.5.2.2.1) is RO and zero except for
"Initiate FLR" unlike the PF DEVCTL (sec 9.3.10.5). The
read/modify/write done by pcie_flr() would work on the VF but is not
necessary.
The VF DEVSTA register (sec 9.5.2.2.2) does have an active
"Transaction Pending" bit. That suggests to me that we should wait
for it to be clear, as pcie_flr() does.
What would you think of a patch like the following? My idea is to
make it the same as pcie_flr() except for the absolutely necessary
differences. With this patch, the only difference is that we don't
look at the 82599 DEVCAP FLR bit.
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index aa77538..7a451ff 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3081,10 +3081,36 @@ static int reset_intel_generic_dev(struct
pci_dev *dev, int probe)
static int reset_intel_82599_sfp_virtfn(struct pci_dev *dev, int probe)
{
+ int i;
+ u16 status;
+
+ /*
+*
http://www.intel.com/content/dam/doc/datasheet/82599-10-gbe-controller-datasheet.pdf
+*
+* The 82599 supports FLR on VFs, but FLR support is reported only
+* in the PF DEVCAP (sec 9.3.10.4), not in the VF DEVCAP (sec 9.5).
+* Therefore, we can't use pcie_flr(), which checks the VF DEVCAP.
+*/
+
if (probe)
return 0;
- pcie_capability_write_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
+ /* Wait for Transaction Pending bit clean */
+ for (i = 0; i< 4; i++) {
+ if (i)
+ msleep((1<< (i - 1)) * 100);
+
+ pcie_capability_read_word(dev, PCI_EXP_DEVSTA,);
+ if (!(status& PCI_EXP_DEVSTA_TRPND))
+ goto clear;
+ }
+
+ dev_err(>dev, "transaction is not cleared; "
+ "proceeding with reset anyway\n");
+
+clear:
+ pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
+
msleep(100);
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: Unable to mount NFSROOT: pcie change breaks e1000?
Hi Fengguang,
Could you please help to verify whether following patch
fixes the issue?
Thanks!
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6b491b..fac08f5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -842,6 +842,9 @@ static int pci_save_pcie_state(struct pci_dev *dev)
struct pci_cap_saved_state *save_state;
u16 *cap;
+ if (!pci_is_pcie(dev))
+ return 0;
+
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
if (!save_state) {
dev_err(>dev, "buffer not found in %s\n", __func__);
On 2012-8-23 8:46, Fengguang Wu wrote:
> buffer not found
--
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/3] dmaengine: add TI EDMA DMA engine driver
Add a DMA engine driver for the TI EDMA controller. This driver
is implemented as a wrapper around the existing DaVinci private
DMA implementation. This approach allows for incremental conversion
of each peripheral driver to the DMA engine API. The EDMA driver
supports slave transfers but does not yet support cyclic transfers.
Signed-off-by: Matt Porter
---
drivers/dma/Kconfig | 10 +
drivers/dma/Makefile |1 +
drivers/dma/edma.c | 671 ++
include/linux/edma.h | 29 +++
4 files changed, 711 insertions(+)
create mode 100644 drivers/dma/edma.c
create mode 100644 include/linux/edma.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d06ea29..0351719 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -208,6 +208,16 @@ config SIRF_DMA
help
Enable support for the CSR SiRFprimaII DMA engine.
+config TI_EDMA
+ tristate "TI EDMA support"
+ depends on ARCH_DAVINCI
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ default n
+ help
+ Enable support for the TI EDMA controller. This DMA
+ engine is found on TI DaVinci and AM33xx parts.
+
config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
bool
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 4cf6b12..f5cf310 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_IMX_DMA) += imx-dma.o
obj-$(CONFIG_MXS_DMA) += mxs-dma.o
obj-$(CONFIG_TIMB_DMA) += timb_dma.o
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
+obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
new file mode 100644
index 000..05aea3c
--- /dev/null
+++ b/drivers/dma/edma.c
@@ -0,0 +1,671 @@
+/*
+ * TI EDMA DMA engine driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+/*
+ * This will go away when the private EDMA API is folded
+ * into this driver and the platform device(s) are
+ * instantiated in the arch code. We can only get away
+ * with this simplification because DA8XX may not be built
+ * in the same kernel image with other DaVinci parts. This
+ * avoids having to sprinkle dmaengine driver platform devices
+ * and data throughout all the existing board files.
+ */
+#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+#define EDMA_CTLRS 2
+#define EDMA_CHANS 32
+#else
+#define EDMA_CTLRS 1
+#define EDMA_CHANS 64
+#endif /* CONFIG_ARCH_DAVINCI_DA8XX */
+
+/* Max of 16 segments per channel to conserve PaRAM slots */
+#define MAX_NR_SG 16
+#define EDMA_MAX_SLOTS MAX_NR_SG
+#define EDMA_DESCRIPTORS 16
+
+struct edma_desc {
+ struct virt_dma_descvdesc;
+ struct list_headnode;
+ int absync;
+ int pset_nr;
+ struct edmacc_param pset[0];
+};
+
+struct edma_cc;
+
+struct edma_chan {
+ struct virt_dma_chanvchan;
+ struct list_headnode;
+ struct edma_desc*edesc;
+ struct edma_cc *ecc;
+ int ch_num;
+ boolalloced;
+ int slot[EDMA_MAX_SLOTS];
+ dma_addr_t addr;
+ int addr_width;
+ int maxburst;
+};
+
+struct edma_cc {
+ int ctlr;
+ struct dma_device dma_slave;
+ struct edma_chanslave_chans[EDMA_CHANS];
+ int num_slave_chans;
+ int dummy_slot;
+};
+
+static inline struct edma_cc *to_edma_cc(struct dma_device *d)
+{
+ return container_of(d, struct edma_cc, dma_slave);
+}
+
+static inline struct edma_chan *to_edma_chan(struct dma_chan *c)
+{
+ return container_of(c, struct edma_chan, vchan.chan);
+}
+
+static inline struct edma_desc
+*to_edma_desc(struct dma_async_tx_descriptor *tx)
+{
+ return container_of(tx, struct edma_desc, vdesc.tx);
+}
+
+static void edma_desc_free(struct virt_dma_desc *vdesc)
+{
+ kfree(container_of(vdesc,
[PATCH v3 3/3] spi: spi-davinci: convert to DMA engine API
Removes use of the DaVinci EDMA private DMA API and replaces
it with use of the DMA engine API.
Signed-off-by: Matt Porter
---
drivers/spi/spi-davinci.c | 292 -
1 file changed, 130 insertions(+), 162 deletions(-)
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 9b2901f..c1ec52d 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -25,13 +25,14 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
#include
-#include
#define SPI_NO_RESOURCE((resource_size_t)-1)
@@ -113,14 +114,6 @@
#define SPIDEF 0x4c
#define SPIFMT00x50
-/* We have 2 DMA channels per CS, one for RX and one for TX */
-struct davinci_spi_dma {
- int tx_channel;
- int rx_channel;
- int dummy_param_slot;
- enum dma_event_qeventq;
-};
-
/* SPI Controller driver's private data. */
struct davinci_spi {
struct spi_bitbang bitbang;
@@ -134,11 +127,14 @@ struct davinci_spi {
const void *tx;
void*rx;
-#define SPI_TMP_BUFSZ (SMP_CACHE_BYTES + 1)
- u8 rx_tmp_buf[SPI_TMP_BUFSZ];
int rcount;
int wcount;
- struct davinci_spi_dma dma;
+
+ struct dma_chan *dma_rx;
+ struct dma_chan *dma_tx;
+ int dma_rx_chnum;
+ int dma_tx_chnum;
+
struct davinci_spi_platform_data *pdata;
void(*get_rx)(u32 rx_data, struct davinci_spi *);
@@ -496,21 +492,23 @@ out:
return errors;
}
-static void davinci_spi_dma_callback(unsigned lch, u16 status, void *data)
+static void davinci_spi_dma_rx_callback(void *data)
{
- struct davinci_spi *dspi = data;
- struct davinci_spi_dma *dma = >dma;
+ struct davinci_spi *dspi = (struct davinci_spi *)data;
- edma_stop(lch);
+ dspi->rcount = 0;
- if (status == DMA_COMPLETE) {
- if (lch == dma->rx_channel)
- dspi->rcount = 0;
- if (lch == dma->tx_channel)
- dspi->wcount = 0;
- }
+ if (!dspi->wcount && !dspi->rcount)
+ complete(>done);
+}
- if ((!dspi->wcount && !dspi->rcount) || (status != DMA_COMPLETE))
+static void davinci_spi_dma_tx_callback(void *data)
+{
+ struct davinci_spi *dspi = (struct davinci_spi *)data;
+
+ dspi->wcount = 0;
+
+ if (!dspi->wcount && !dspi->rcount)
complete(>done);
}
@@ -526,20 +524,20 @@ static void davinci_spi_dma_callback(unsigned lch, u16
status, void *data)
static int davinci_spi_bufs(struct spi_device *spi, struct spi_transfer *t)
{
struct davinci_spi *dspi;
- int data_type, ret;
+ int data_type, ret = -ENOMEM;
u32 tx_data, spidat1;
u32 errors = 0;
struct davinci_spi_config *spicfg;
struct davinci_spi_platform_data *pdata;
unsigned uninitialized_var(rx_buf_count);
- struct device *sdev;
+ void *dummy_buf = NULL;
+ struct scatterlist sg_rx, sg_tx;
dspi = spi_master_get_devdata(spi->master);
pdata = dspi->pdata;
spicfg = (struct davinci_spi_config *)spi->controller_data;
if (!spicfg)
spicfg = _spi_default_cfg;
- sdev = dspi->bitbang.master->dev.parent;
/* convert len to words based on bits_per_word */
data_type = dspi->bytes_per_word[spi->chip_select];
@@ -567,112 +565,83 @@ static int davinci_spi_bufs(struct spi_device *spi,
struct spi_transfer *t)
spidat1 |= tx_data & 0x;
iowrite32(spidat1, dspi->base + SPIDAT1);
} else {
- struct davinci_spi_dma *dma;
- unsigned long tx_reg, rx_reg;
- struct edmacc_param param;
- void *rx_buf;
- int b, c;
-
- dma = >dma;
-
- tx_reg = (unsigned long)dspi->pbase + SPIDAT1;
- rx_reg = (unsigned long)dspi->pbase + SPIBUF;
-
- /*
-* Transmit DMA setup
-*
-* If there is transmit data, map the transmit buffer, set it
-* as the source of data and set the source B index to data
-* size. If there is no transmit data, set the transmit register
-* as the source of data, and set the source B index to zero.
-*
-* The destination is always the transmit register itself. And
-* the destination never increments.
-*/
-
- if (t->tx_buf) {
- t->tx_dma = dma_map_single(>dev, (void *)t->tx_buf,
-
[PATCH v3 2/3] mmc: davinci_mmc: convert to DMA engine API
Removes use of the DaVinci EDMA private DMA API and replaces
it with use of the DMA engine API.
Signed-off-by: Matt Porter
---
drivers/mmc/host/davinci_mmc.c | 271
1 file changed, 82 insertions(+), 189 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 7cf6c62..c5e1eeb 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -30,11 +30,12 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
-#include
/*
* Register Definitions
@@ -200,21 +201,13 @@ struct mmc_davinci_host {
u32 bytes_left;
u32 rxdma, txdma;
+ struct dma_chan *dma_tx;
+ struct dma_chan *dma_rx;
bool use_dma;
bool do_dma;
bool sdio_int;
bool active_request;
- /* Scatterlist DMA uses one or more parameter RAM entries:
-* the main one (associated with rxdma or txdma) plus zero or
-* more links. The entries for a given transfer differ only
-* by memory buffer (address, length) and link field.
-*/
- struct edmacc_param tx_template;
- struct edmacc_param rx_template;
- unsignedn_link;
- u32 links[MAX_NR_SG - 1];
-
/* For PIO we walk scatterlists one segment at a time. */
unsigned intsg_len;
struct scatterlist *sg;
@@ -410,153 +403,74 @@ static void mmc_davinci_start_command(struct
mmc_davinci_host *host,
static void davinci_abort_dma(struct mmc_davinci_host *host)
{
- int sync_dev;
+ struct dma_chan *sync_dev;
if (host->data_dir == DAVINCI_MMC_DATADIR_READ)
- sync_dev = host->rxdma;
+ sync_dev = host->dma_rx;
else
- sync_dev = host->txdma;
-
- edma_stop(sync_dev);
- edma_clean_channel(sync_dev);
-}
-
-static void
-mmc_davinci_xfer_done(struct mmc_davinci_host *host, struct mmc_data *data);
-
-static void mmc_davinci_dma_cb(unsigned channel, u16 ch_status, void *data)
-{
- if (DMA_COMPLETE != ch_status) {
- struct mmc_davinci_host *host = data;
-
- /* Currently means: DMA Event Missed, or "null" transfer
-* request was seen. In the future, TC errors (like bad
-* addresses) might be presented too.
-*/
- dev_warn(mmc_dev(host->mmc), "DMA %s error\n",
- (host->data->flags & MMC_DATA_WRITE)
- ? "write" : "read");
- host->data->error = -EIO;
- mmc_davinci_xfer_done(host, host->data);
- }
-}
-
-/* Set up tx or rx template, to be modified and updated later */
-static void __init mmc_davinci_dma_setup(struct mmc_davinci_host *host,
- bool tx, struct edmacc_param *template)
-{
- unsignedsync_dev;
- const u16 acnt = 4;
- const u16 bcnt = rw_threshold >> 2;
- const u16 ccnt = 0;
- u32 src_port = 0;
- u32 dst_port = 0;
- s16 src_bidx, dst_bidx;
- s16 src_cidx, dst_cidx;
-
- /*
-* A-B Sync transfer: each DMA request is for one "frame" of
-* rw_threshold bytes, broken into "acnt"-size chunks repeated
-* "bcnt" times. Each segment needs "ccnt" such frames; since
-* we tell the block layer our mmc->max_seg_size limit, we can
-* trust (later) that it's within bounds.
-*
-* The FIFOs are read/written in 4-byte chunks (acnt == 4) and
-* EDMA will optimize memory operations to use larger bursts.
-*/
- if (tx) {
- sync_dev = host->txdma;
-
- /* src_prt, ccnt, and link to be set up later */
- src_bidx = acnt;
- src_cidx = acnt * bcnt;
-
- dst_port = host->mem_res->start + DAVINCI_MMCDXR;
- dst_bidx = 0;
- dst_cidx = 0;
- } else {
- sync_dev = host->rxdma;
-
- src_port = host->mem_res->start + DAVINCI_MMCDRR;
- src_bidx = 0;
- src_cidx = 0;
-
- /* dst_prt, ccnt, and link to be set up later */
- dst_bidx = acnt;
- dst_cidx = acnt * bcnt;
- }
-
- /*
-* We can't use FIFO mode for the FIFOs because MMC FIFO addresses
-* are not 256-bit (32-byte) aligned. So we use INCR, and the W8BIT
-* parameter is ignored.
-*/
- edma_set_src(sync_dev, src_port, INCR, W8BIT);
- edma_set_dest(sync_dev, dst_port, INCR, W8BIT);
+ sync_dev = host->dma_tx;
- edma_set_src_index(sync_dev, src_bidx, src_cidx);
- edma_set_dest_index(sync_dev, dst_bidx, dst_cidx);
-
- edma_set_transfer_params(sync_dev, acnt, bcnt, ccnt, 8, ABSYNC);
-
-
[PATCH v3 0/3] DaVinci DMA engine conversion
Changes since v1: - Add virt-dma support. Better error checks and simplified descriptor handling. - Fix support for multiple EDMA controllers Tested on AM18x EVM with WL12xx on MMC1 Changes since v2: - Set default Kconfig state to off - Fix whitespace and indent issues - Simplify struct device * assignments - Remove unneeded chcnt in edma_chan_init - Remove unneeded conditional assignment of prep_slave_sg - Fix devm_* usage This series begins the conversion of the DaVinci private EDMA API implementation to a DMA engine driver and converts two of the three in-kernel users of the private EDMA API to DMA engine. The approach taken is similar to the recent OMAP DMA Engine conversion. The EDMA DMA Engine driver is a wrapper around the existing private EDMA implementation and registers the platform device within the driver. This allows the conversion series to stand alone with just the drivers and no changes to platform code. It also allows peripheral drivers to continue to use the private EDMA implementation until they are converted. The EDMA DMA Engine driver supports slave transfers only at this time. It is planned to add cyclic transfers in support of audio peripherals. There are three users of the private EDMA API in the kernel now: davinci_mmc, spi-davinci, and davinci-mcasp. This series provides DMA Engine conversions for the davinci_mmc and spi-davinci drivers which use the supported slave transfers. This series has been tested on an AM18x EVM and Hawkboard with driver performance comparable to that of the private EDMA API implementations. Both MMC0 and MMC1 are tested which handles the DA850/OMAP-L138/AM18x specific case where MMC1 uses DMA channels on a second EDMA channel controller. All other platforms have a simpler design with just a single EDMA channel controller. For those wanting to easily test this series, I've pushed a branch for each version to my github tree at https://github.com/ohporter/linux. The current branch is edma-dmaengine-v3. After this series, the current plan is to complete the mcasp driver conversion which includes adding cyclic dma support. This will then enable the removal and refactoring of the private EDMA API functionality into the EDMA DMA Engine driver. Since EDMA is also used on the AM33xx family of parts in mach-omap2/, the plan is to enable this driver on that platform as well. Matt Porter (3): dmaengine: add TI EDMA DMA engine driver mmc: davinci_mmc: convert to DMA engine API spi: spi-davinci: convert to DMA engine API drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/edma.c | 671 drivers/mmc/host/davinci_mmc.c | 271 +--- drivers/spi/spi-davinci.c | 292 - include/linux/edma.h | 29 ++ 6 files changed, 923 insertions(+), 351 deletions(-) create mode 100644 drivers/dma/edma.c create mode 100644 include/linux/edma.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/
RE: [PATCH v3 00/32] provide interfaces to access PCIe capabilities registers
Bjorn Helgaas wrote on 2012-08-23:
> On Mon, Aug 20, 2012 at 9:40 PM, Cui, Dexuan
> wrote:
>> Bjorn Helgaas wrote on 2012-08-21:
>
>>> I am still concerned about reset_intel_82599_sfp_virtfn(). It looks
>>> wrong and possibly unnecessary. It looks wrong because it sets
>>> PCI_EXP_DEVCTL_BCR_FLR and blindly clears all other bits in
>>> PCI_EXP_DEVCTL. Most of the bits are probably cleared by the FLR
>>> anyway, but Aux Power PM Enable is RWS ("sticky"), so it is *not*
>>> modified by FLR. Therefore, using reset_intel_82599_sfp_virtfn() has
>>> the probably unintended side effect of clearing Aux Power PM Enable.
>>>
>>> It looks possibly unnecessary because the generic pcie_flr() does
>>> essentially the same thing, so it's not clear why we need a special
>>> case for 82599.
>
>> I think reset_intel_82599_sfp_virtfn() is correct AND necessary.
>> (pcie_flr() doesn't work here)
>>
>> Please note the 82599 VF is a special PCIe device that doesn't report
>> PCIe FLR capability though actually it does support that.
>> That is why we put it in quirks.c. :-)
>>
>> The PCI_EXP_DEVCTL_AUX_PME bit of the 82599 VF is read-only and
>> always zero.
>>
>> Please see
>>
> http://www.intel.com/content/dam/doc/datasheet/82599-10-gbe-controller-
> datasheet.pdf
>> 9.5 Virtual Functions Configuration Space
>> Table 9.7 VF PCIe Configuration Space
>> 9.5.2.2.1 VF Device Control Register (0xA8; RW)
>
> Thanks, Dexuan!
>
> The 82599 does report FLR in the DEVCAP for the PF (sec 9.3.10.4), but
> not in the DEVCAP for the VF (sec 9.5), which indeed means we can't
> use pcie_flr() on the VFs. I wonder whether this error appears in any
> other devices.
>
> The VF DEVCTL register (sec 9.5.2.2.1) is RO and zero except for
> "Initiate FLR" unlike the PF DEVCTL (sec 9.3.10.5). The
> read/modify/write done by pcie_flr() would work on the VF but is not
> necessary.
>
> The VF DEVSTA register (sec 9.5.2.2.2) does have an active
> "Transaction Pending" bit. That suggests to me that we should wait
> for it to be clear, as pcie_flr() does.
I agree.
>
> What would you think of a patch like the following? My idea is to
> make it the same as pcie_flr() except for the absolutely necessary
> differences. With this patch, the only difference is that we don't
> look at the 82599 DEVCAP FLR bit.
Hi Bjorn,
Thanks for the patch!
It seems good to me (BTW, I don't have such a device at
hand to test)
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/
Re: [RFC PATCH 1/17] input: RMI4 public header file and documentation.
On 08/22/2012 02:45 PM, Dmitry Torokhov wrote: On Wednesday, August 22, 2012 09:08:00 PM Linus Walleij wrote: >On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny > wrote: > > >+/* Helper fn to convert a byte array representing a short in the RMI > >+ * endian-ness to a short in the native processor's specific endianness. Is RMI-endiannes different from BE and LE (joking)? Please simply state what on-wire endianness is and use xx_to_cpu() or cpu_to_xx() as needed. I think I mentioned it about a year ago already... Gronk. I thought I'd killed that. But obviously didn't do a thorough job. [Slinks off in embarrassment.] -- 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 01/17] hashtable: introduce a small and naive hashtable
Hi Tejun,
On 08/22/2012 08:01 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
>> +#define DEFINE_HASHTABLE(name, bits)
>> \
>> +struct hlist_head name[HASH_SIZE(bits)];
>
> Shouldn't this be something like the following?
>
> #define DEFINE_HASHTABLE(name, bits) \
> struct hlist_head name[HASH_SIZE(bits)] = \
> { [0 ... HASH_SIZE(bits) - 1] = HLIST_HEAD_INIT };
>
> Also, given that the declaration isn't non-trivial, you'll probably
> want a matching DECLARE_HASHTABLE() macro too.
I figured we might do a DEFINE_HASHTABLE() to prevent the need from using
hash_init() on hashtables defined this way, but I preferred not to since we may
end up wanting a more complex initialization (I'll explain why extensively
below).
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit
>> kernels. */
>> +#define hash_min(val, bits) ((sizeof(val)==4) ? hash_32((val), (bits)) :
>> hash_long((val), (bits)))
>
> Why is the branching condition sizeof(val) == 4 instead of <= 4?
No reason, will fix.
> Also, no biggie but why isn't this macro in caps?
I had this plan in my mind to move it into linux/hash.h at some stage later, and
the API there uses low caps even for macros (hash_long()).
>> +/**
>> + * hash_add_rcu_size - add an object to a rcu enabled hashtable
>> + * @hashtable: hashtable to add to
>> + * @bits: bit count used for hashing
>> + * @node: the hlist_node of the object to be added
>> + * @key: the key of the object to be added
>> + */
>> +#define hash_add_rcu_size(hashtable, bits, node, key)
>> \
>> +hlist_add_head_rcu(node, [hash_min(key, bits)]);
>> +
>> +/**
>> + * hash_add_rcu - add an object to a rcu enabled hashtable
>> + * @hashtable: hashtable to add to
>> + * @node: the hlist_node of the object to be added
>> + * @key: the key of the object to be added
>> + */
>> +#define hash_add_rcu(hashtable, node, key)
>> \
>> +hash_add_rcu_size(hashtable, HASH_BITS(hashtable), node, key)
>
> Or maybe we're better off with hash_head_size() and hash_head()? I'll
> expand on it later. Please bear with me.
>
>> +/**
>> + * hash_hashed - check whether an object is in any hashtable
>> + * @node: the hlist_node of the object to be checked
>> + */
>> +#define hash_hashed(node) (!hlist_unhashed(node))
>
> As the 'h' in hlist* stand for hash anyway and I think this type of
> thin wrappers tend to obfuscate more than anything else.
>
>> +/**
>> + * hash_del - remove an object from a hashtable
>> + * @node: hlist_node of the object to remove
>> + */
>> +static inline void hash_del(struct hlist_node *node)
>> +{
>> +hlist_del_init(node);
>> +}
>> +
>> +/**
>> + * hash_del_rcu - remove an object from a rcu enabled hashtable
>> + * @node: hlist_node of the object to remove
>> + */
>> +static inline void hash_del_rcu(struct hlist_node *node)
>> +{
>> +hlist_del_init_rcu(node);
>> +}
>
> If we do that, we can remove all these thin wrappers.
>
>> +#define hash_for_each_size(name, bits, bkt, node, obj, member)
>> \
>> +for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)
>> \
>> +hlist_for_each_entry(obj, node, [bkt], member)
> ..
>> +#define hash_for_each(name, bkt, node, obj, member)
>> \
>> +hash_for_each_size(name, HASH_BITS(name), bkt, node, obj, member)
> ...
>> +#define hash_for_each_rcu_size(name, bits, bkt, node, obj, member)
>> \
>> +for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)
>> \
>> +hlist_for_each_entry_rcu(obj, node, [bkt], member)
> ...
>> +#define hash_for_each_rcu(name, bkt, node, obj, member)
>> \
>> +hash_for_each_rcu_size(name, HASH_BITS(name), bkt, node, obj, member)
> ...
>> +#define hash_for_each_safe_size(name, bits, bkt, node, tmp, obj, member)
>> \
>> +for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)
>> \
>> +hlist_for_each_entry_safe(obj, node, tmp, [bkt], member)
> ...
>> +#define hash_for_each_safe(name, bkt, node, tmp, obj, member)
>> \
>> +hash_for_each_safe_size(name, HASH_BITS(name), bkt, node,
>> \
>> +tmp, obj, member)
> ...
>> +#define hash_for_each_possible_size(name, obj, bits, node, member, key)
>> \
>> +hlist_for_each_entry(obj, node, [hash_min(key, bits)], member)
> ...
>> +#define hash_for_each_possible(name, obj, node, member, key)
>> \
>> +hash_for_each_possible_size(name, obj, HASH_BITS(name), node, member,
>> key)
> ...
>> +#define hash_for_each_possible_rcu_size(name, obj, bits, node, member, key)
>> \
>> +hlist_for_each_entry_rcu(obj, node, [hash_min(key, bits)],
Re: [PATCH 74/74] lto, workaround: Mark do_futex noinline to prevent clobbering ebp
On 08/18/2012 07:57 PM, Andi Kleen wrote: > From: Andi Kleen > > On a 32bit build gcc 4.7 with LTO decides to clobber the 6th argument on the > stack. Unfortunately this corrupts the user EBP and leads to later crashes. > For now mark do_futex noinline to prevent this. > > I wish there was a generic way to handle this. Seems like a ticking time > bomb problem. > There is a generic way to handle this. This is actually a bug in Linux that has been known for at least 15 years and which we keep hacking around. The right thing to do is to change head_32.S to not violate the i386 ABI. Arguments pushed (by value) on the stack are property of the callee, that is, they are volatile, so the hack of making them do double duty as both being saved and passed as arguments is just plain bogus. The problem is that it works "just well enough" that people (including myself) keep hacking around it with hacks like this, with assembly macros, and whatnot instead of fixing the root cause. -hpa -- 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/
The Linux 3.2.y stable series is longterm
I intend to maintain Linux 3.2.y for at least as long as Debian 7.0 is supported. The end-of-life for each Debian release is 1 year after the following release, so this would probably be around the end of 2015. If anyone's interested in maintaining it even longer than that, I should be able to hand over the responsibility when the time comes. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
[PATCH 4/4] extcon: fixing typos
From: Peter Meerwald Signed-off-by: Peter Meerwald Signed-off-by: Myungjoo Ham --- drivers/extcon/extcon-class.c |8 include/linux/extcon.h| 18 +- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c index 481cfa0..946a318 100644 --- a/drivers/extcon/extcon-class.c +++ b/drivers/extcon/extcon-class.c @@ -443,7 +443,7 @@ static int _call_per_cable(struct notifier_block *nb, unsigned long val, /** * extcon_register_interest() - Register a notifier for a state change of a - * specific cable, not a entier set of cables of a + * specific cable, not an entier set of cables of a * extcon device. * @obj: an empty extcon_specific_cable_nb object to be returned. * @extcon_name: the name of extcon device. @@ -499,7 +499,7 @@ int extcon_unregister_interest(struct extcon_specific_cable_nb *obj) } /** - * extcon_register_notifier() - Register a notifee to get notified by + * extcon_register_notifier() - Register a notifiee to get notified by * any attach status changes from the extcon. * @edev: the extcon device. * @nb:a notifier block to be registered. @@ -516,7 +516,7 @@ int extcon_register_notifier(struct extcon_dev *edev, EXPORT_SYMBOL_GPL(extcon_register_notifier); /** - * extcon_unregister_notifier() - Unregister a notifee from the extcon device. + * extcon_unregister_notifier() - Unregister a notifiee from the extcon device. * @edev: the extcon device. * @nb:a registered notifier block to be unregistered. */ @@ -806,7 +806,7 @@ EXPORT_SYMBOL_GPL(extcon_dev_register); /** * extcon_dev_unregister() - Unregister the extcon device. - * @edev: the extcon device instance to be unregitered. + * @edev: the extcon device instance to be unregistered. * * Note that this does not call kfree(edev) because edev was not allocated * by this class. diff --git a/include/linux/extcon.h b/include/linux/extcon.h index cdd4014..7443a56 100644 --- a/include/linux/extcon.h +++ b/include/linux/extcon.h @@ -30,19 +30,19 @@ /* * The standard cable name is to help support general notifier - * and notifee device drivers to share the common names. + * and notifiee device drivers to share the common names. * Please use standard cable names unless your notifier device has * a very unique and abnormal cable or * the cable type is supposed to be used with only one unique - * pair of notifier/notifee devices. + * pair of notifier/notifiee devices. * * Please add any other "standard" cables used with extcon dev. * * You may add a dot and number to specify version or specification * of the specific cable if it is required. (e.g., "Fast-charger.18" * and "Fast-charger.10" for 1.8A and 1.0A chargers) - * However, the notifee and notifier should be able to handle such - * string and if the notifee can negotiate the protocol or idenify, + * However, the notifiee and notifier should be able to handle such + * string and if the notifiee can negotiate the protocol or identify, * you don't need such convention. This convention is helpful when * notifier can distinguish but notifiee cannot. */ @@ -76,7 +76,7 @@ struct extcon_cable; * struct extcon_dev - An extcon device represents one external connector. * @name The name of this extcon device. Parent device name is used * if NULL. - * @supported_cableArray of supported cable name ending with NULL. + * @supported_cableArray of supported cable names ending with NULL. * If supported_cable is NULL, cable name related APIs * are disabled. * @mutually_exclusive Array of mutually exclusive set of cables that cannot @@ -95,7 +95,7 @@ struct extcon_cable; * @state Attach/detach state of this extcon. Do not provide at * register-time * @nh Notifier for the state change events from this extcon - * @entry To support list of extcon devices so that uses can search + * @entry To support list of extcon devices so that users can search * for extcon devices based on the extcon name. * @lock * @max_supported Internal value to store the number of cables. @@ -199,7 +199,7 @@ extern int extcon_update_state(struct extcon_dev *edev, u32 mask, u32 state); /* * get/set_cable_state access each bit of the 32b encoded state value. * They are used to access the status of each cable based on the cable_name - * or cable_index, which is retrived by extcon_find_cable_index + * or cable_index, which is retrieved by extcon_find_cable_index */ extern int extcon_find_cable_index(struct extcon_dev *sdev, const char *cable_name); @@ -226,9 +226,9 @@ extern int extcon_unregister_interest(struct extcon_specific_cable_nb
[PATCH 2/4] extcon: fix typos in max77693 driver
From: Peter Meerwald Signed-off-by: Peter Meerwald Signed-off-by: MyungJoo Ham --- drivers/extcon/extcon-max77693.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c index 920a609..8bb438b 100644 --- a/drivers/extcon/extcon-max77693.c +++ b/drivers/extcon/extcon-max77693.c @@ -356,7 +356,7 @@ static int max77693_muic_adc_ground_handler(struct max77693_muic_info *info, extcon_set_cable_state(info->edev, "MHL", attached); break; default: - dev_err(info->dev, "faild to detect %s accessory\n", + dev_err(info->dev, "failed to detect %s accessory\n", attached ? "attached" : "detached"); dev_err(info->dev, "- adc:0x%x, adclow:0x%x, adc1k:0x%x\n", adc, adclow, adc1k); @@ -548,7 +548,7 @@ static void max77693_muic_irq_work(struct work_struct *work) curr_adc = info->status[0] & STATUS1_ADC_MASK; curr_adc >>= STATUS1_ADC_SHIFT; - /* Check accossory state which is either detached or attached */ + /* Check accessory state which is either detached or attached */ if (curr_adc == MAX77693_MUIC_ADC_OPEN) attached = false; @@ -564,7 +564,7 @@ static void max77693_muic_irq_work(struct work_struct *work) curr_chg_type = info->status[1] & STATUS2_CHGTYP_MASK; curr_chg_type >>= STATUS2_CHGTYP_SHIFT; - /* Check charger accossory state which + /* Check charger accessory state which is either detached or attached */ if (curr_chg_type == MAX77693_CHARGER_TYPE_NONE) attached = false; -- 1.7.0.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 3/4] extcon: fix typos in extcon-arizona
From: Peter Meerwald
Signed-off-by: Peter Meerwald
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-arizona.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index fa2114f..55fbc2f 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -348,7 +348,7 @@ static int __devinit arizona_extcon_probe(struct
platform_device *pdev)
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
if (!info) {
- dev_err(>dev, "failed to allocate memory\n");
+ dev_err(>dev, "Failed to allocate memory\n");
ret = -ENOMEM;
goto err;
}
@@ -385,7 +385,7 @@ static int __devinit arizona_extcon_probe(struct
platform_device *pdev)
ret = extcon_dev_register(>edev, arizona->dev);
if (ret < 0) {
- dev_err(arizona->dev, "extcon_dev_regster() failed: %d\n",
+ dev_err(arizona->dev, "extcon_dev_register() failed: %d\n",
ret);
goto err;
}
--
1.7.0.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 1/4] extcon: fix typos in sys-class-extcon
From: Peter Meerwald
Signed-off-by: Peter Meerwald
Signed-off-by: Chanwoo Choi
---
Documentation/ABI/testing/sysfs-class-extcon | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-extcon
b/Documentation/ABI/testing/sysfs-class-extcon
index 20ab361..57a7262 100644
--- a/Documentation/ABI/testing/sysfs-class-extcon
+++ b/Documentation/ABI/testing/sysfs-class-extcon
@@ -13,7 +13,7 @@ Description:
accessory cables have such capability. For example,
the 30-pin port of Nuri board (/arch/arm/mach-exynos)
may have both HDMI and Charger attached, or analog audio,
- video, and USB cables attached simulteneously.
+ video, and USB cables attached simultaneously.
If there are cables mutually exclusive with each other,
such binary relations may be expressed with extcon_dev's
@@ -35,7 +35,7 @@ Description:
The /sys/class/extcon/.../state shows and stores the cable
attach/detach information of the corresponding extcon object.
If the extcon object has an optional callback "show_state"
- defined, the showing function is overriden with the optional
+ defined, the showing function is overridden with the optional
callback.
If the default callback for showing function is used, the
@@ -46,19 +46,19 @@ Description:
TA=1
EAR_JACK=0
#
- In this example, the extcon device have USB_OTG and TA
+ In this example, the extcon device has USB_OTG and TA
cables attached and HDMI and EAR_JACK cables detached.
In order to update the state of an extcon device, enter a hex
- state number starting with 0x.
-echo 0xHEX > state
+ state number starting with 0x:
+ # echo 0xHEX > state
- This updates the whole state of the extcon dev.
+ This updates the whole state of the extcon device.
Inputs of all the methods are required to meet the
- mutually_exclusive contidions if they exist.
+ mutually_exclusive conditions if they exist.
It is recommended to use this "global" state interface if
- you need to enter the value atomically. The later state
+ you need to set the value atomically. The later state
interface associated with each cable cannot update
multiple cable states of an extcon device simultaneously.
@@ -73,7 +73,7 @@ What: /sys/class/extcon/.../cable.x/state
Date: February 2012
Contact: MyungJoo Ham
Description:
- The /sys/class/extcon/.../cable.x/name shows and stores the
+ The /sys/class/extcon/.../cable.x/state shows and stores the
state of cable "x" (integer between 0 and 31) of an extcon
device. The state value is either 0 (detached) or 1
(attached).
@@ -83,8 +83,8 @@ Date: December 2011
Contact: MyungJoo Ham
Description:
Shows the relations of mutually exclusiveness. For example,
- if the mutually_exclusive array of extcon_dev is
- {0x3, 0x5, 0xC, 0x0}, the, the output is:
+ if the mutually_exclusive array of extcon device is
+ {0x3, 0x5, 0xC, 0x0}, then the output is:
# ls mutually_exclusive/
0x3
0x5
--
1.7.0.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 0/4] extcon: fix typos
This patchset fix typos of extcon by Peter Meerwald. Peter Meerwald (4): extcon: fix typos in sys-class-extcon extcon: fix typos in max77693 driver extcon: fix typos in extcon-arizona extcon: fixing typos Documentation/ABI/testing/sysfs-class-extcon | 22 +++--- drivers/extcon/extcon-arizona.c |4 ++-- drivers/extcon/extcon-class.c|8 drivers/extcon/extcon-max77693.c |6 +++--- include/linux/extcon.h | 18 +- 5 files changed, 29 insertions(+), 29 deletions(-) -- 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 06/11] memcg: kmem controller infrastructure
On Wed, Aug 22 2012, Glauber Costa wrote:
> On 08/22/2012 01:50 AM, Greg Thelen wrote:
>> On Thu, Aug 09 2012, Glauber Costa wrote:
>>
>>> This patch introduces infrastructure for tracking kernel memory pages to
>>> a given memcg. This will happen whenever the caller includes the flag
>>> __GFP_KMEMCG flag, and the task belong to a memcg other than the root.
>>>
>>> In memcontrol.h those functions are wrapped in inline accessors. The
>>> idea is to later on, patch those with static branches, so we don't incur
>>> any overhead when no mem cgroups with limited kmem are being used.
>>>
>>> [ v2: improved comments and standardized function names ]
>>>
>>> Signed-off-by: Glauber Costa
>>> CC: Christoph Lameter
>>> CC: Pekka Enberg
>>> CC: Michal Hocko
>>> CC: Kamezawa Hiroyuki
>>> CC: Johannes Weiner
>>> ---
>>> include/linux/memcontrol.h | 79 +++
>>> mm/memcontrol.c| 185
>>> +
>>> 2 files changed, 264 insertions(+)
>>>
>>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>>> index 8d9489f..75b247e 100644
>>> --- a/include/linux/memcontrol.h
>>> +++ b/include/linux/memcontrol.h
>>> @@ -21,6 +21,7 @@
>>> #define _LINUX_MEMCONTROL_H
>>> #include
>>> #include
>>> +#include
>>>
>>> struct mem_cgroup;
>>> struct page_cgroup;
>>> @@ -399,6 +400,11 @@ struct sock;
>>> #ifdef CONFIG_MEMCG_KMEM
>>> void sock_update_memcg(struct sock *sk);
>>> void sock_release_memcg(struct sock *sk);
>>> +
>>> +#define memcg_kmem_on 1
>>> +bool __memcg_kmem_new_page(gfp_t gfp, void *handle, int order);
>>> +void __memcg_kmem_commit_page(struct page *page, void *handle, int order);
>>> +void __memcg_kmem_free_page(struct page *page, int order);
>>> #else
>>> static inline void sock_update_memcg(struct sock *sk)
>>> {
>>> @@ -406,6 +412,79 @@ static inline void sock_update_memcg(struct sock *sk)
>>> static inline void sock_release_memcg(struct sock *sk)
>>> {
>>> }
>>> +
>>> +#define memcg_kmem_on 0
>>> +static inline bool
>>> +__memcg_kmem_new_page(gfp_t gfp, void *handle, int order)
>>> +{
>>> + return false;
>>> +}
>>> +
>>> +static inline void __memcg_kmem_free_page(struct page *page, int order)
>>> +{
>>> +}
>>> +
>>> +static inline void
>>> +__memcg_kmem_commit_page(struct page *page, struct mem_cgroup *handle, int
>>> order)
>>> +{
>>> +}
>>> #endif /* CONFIG_MEMCG_KMEM */
>>> +
>>> +/**
>>> + * memcg_kmem_new_page: verify if a new kmem allocation is allowed.
>>> + * @gfp: the gfp allocation flags.
>>> + * @handle: a pointer to the memcg this was charged against.
>>> + * @order: allocation order.
>>> + *
>>> + * returns true if the memcg where the current task belongs can hold this
>>> + * allocation.
>>> + *
>>> + * We return true automatically if this allocation is not to be accounted
>>> to
>>> + * any memcg.
>>> + */
>>> +static __always_inline bool
>>> +memcg_kmem_new_page(gfp_t gfp, void *handle, int order)
>>> +{
>>> + if (!memcg_kmem_on)
>>> + return true;
>>> + if (!(gfp & __GFP_KMEMCG) || (gfp & __GFP_NOFAIL))
>>> + return true;
>>> + if (in_interrupt() || (!current->mm) || (current->flags & PF_KTHREAD))
>>> + return true;
>>> + return __memcg_kmem_new_page(gfp, handle, order);
>>> +}
>>> +
>>> +/**
>>> + * memcg_kmem_free_page: uncharge pages from memcg
>>> + * @page: pointer to struct page being freed
>>> + * @order: allocation order.
>>> + *
>>> + * there is no need to specify memcg here, since it is embedded in
>>> page_cgroup
>>> + */
>>> +static __always_inline void
>>> +memcg_kmem_free_page(struct page *page, int order)
>>> +{
>>> + if (memcg_kmem_on)
>>> + __memcg_kmem_free_page(page, order);
>>> +}
>>> +
>>> +/**
>>> + * memcg_kmem_commit_page: embeds correct memcg in a page
>>> + * @handle: a pointer to the memcg this was charged against.
>>> + * @page: pointer to struct page recently allocated
>>> + * @handle: the memcg structure we charged against
>>> + * @order: allocation order.
>>> + *
>>> + * Needs to be called after memcg_kmem_new_page, regardless of success or
>>> + * failure of the allocation. if @page is NULL, this function will revert
>>> the
>>> + * charges. Otherwise, it will commit the memcg given by @handle to the
>>> + * corresponding page_cgroup.
>>> + */
>>> +static __always_inline void
>>> +memcg_kmem_commit_page(struct page *page, struct mem_cgroup *handle, int
>>> order)
>>> +{
>>> + if (memcg_kmem_on)
>>> + __memcg_kmem_commit_page(page, handle, order);
>>> +}
>>> #endif /* _LINUX_MEMCONTROL_H */
>>>
>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>> index 54e93de..e9824c1 100644
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -10,6 +10,10 @@
>>> * Copyright (C) 2009 Nokia Corporation
>>> * Author: Kirill A. Shutemov
>>> *
>>> + * Kernel Memory Controller
>>> + * Copyright (C) 2012 Parallels Inc. and Google Inc.
>>> + * Authors: Glauber Costa and Suleiman Souhlal
>>> + *
Re: [PATCH] crypto: twofish - add x86_64/avx assembler implementation
On Wed, Aug 22, 2012 at 12:20 PM, Jussi Kivilinna
wrote:
> Quoting Borislav Petkov :
>
>> On Wed, Aug 22, 2012 at 07:35:12AM +0300, Jussi Kivilinna wrote:
>>> Looks that encryption lost ~0.4% while decryption gained ~1.8%.
>>>
>>> For 256 byte test, it's still slightly slower than twofish-3way
>>> (~3%). For 1k
>>> and 8k tests, it's ~5% faster.
>>>
>>> Here's very last test-patch, testing different ordering of fpu<->cpu reg
>>> instructions at few places.
>>
>> Hehe,.
>>
>> I don't mind testing patches, no worries there. Here are the results
>> this time, doesn't look better than the last run, AFAICT.
>>
>
> Actually it does look better, at least for encryption. Decryption had
> different
> ordering for test, which appears to be bad on bulldozer as it is on
> sandy-bridge.
>
> So, yet another patch then :)
>
> Interleaving at some new places (reordered lookup_32bit()s in G-macro) and
> doing one of the round rotations one round ahead. Also introduces some
> more paralellism inside lookup_32bit.
Outsider looking in here, but avoiding the 256-way lookup tables
entirely might be faster. Looking at the twofish code, one byte-wise
calculation looks like this:
a0 = x >> 4; b0 = x & 15;
a1 = a0 ^ b0; b1 = ror4[b0] ^ ashx[a0];
a2 = qt0[n][a1]; b2 = qt1[n][b1];
a3 = a2 ^ b2; b3 = ror4[b2] ^ ashx[a2];
a4 = qt2[n][a3]; b4 = qt3[n][b3];
return (b4 << 4) | a4;
This means that you can do something like this pseudocode (Intel
syntax). pshufb on ymm registers is AVX2, but splitting it into xmm
operations would probably be fine (as would using this for just a pure
SSE implementation!). On AVX2 you' have to double the tables for both
ways, naturally.
constants:
pb_0x0f = {0x0f,0x0f,0x0f ... }
ashx: lookup table
ror4: lookup table
qt0[n]: lookup table
qt1[n]: lookup table
qt2[n]: lookup table
qt3[n]: lookup table
vpandb0, in, pb_0x0f
vpsrlw a0, in, 4
vpanda0, a0, pb_0x0f; effectively vpsrlb, but that doesn't exist
vpxora1, a0, b0
vpshufb a0, ashx, a0
vpshufb b0, ror4, b0
vpxorb1, a0, b0
vpshufb a2, qt0[n], a1
vpshufb b2, qt1[n], b1
vpxora3, a2, b2
vpshufb a3, ashx, a2
vpshufb b3, ror4, b2
vpxorb3, a2, b2
vpshufb a4, qt2[n], a3
vpshufb b4, qt3[n], b3
vpsllw b4, b4, 4 ; effectively vpsrlb, but that doesn't exist
vporout, a4, b4
That's 15 instructions (plus maybe a move or two) to do 16 lookups for
SSE (~9 cycles by my guessing on a Nehalem). AVX would run into the
problem of lots of extra vinsert/vextract (just going 16-byte might be
better, might be not, depending on execution units). AVX2 would be
super fast (15 for 32).
If this works, this could be quite a bit faster with the table-based approach.
Jason
--
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: [ 43/46] KVM: x86 emulator: fix byte-sized MOVZX/MOVSX
On Sun, 2012-08-19 at 20:59 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.5-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Avi Kivity > > (cherry picked from commit 361cad2b50a2c92b91b6f568db860fabad3bf149) > > Commit 2adb5ad9fe1 removed ByteOp from MOVZX/MOVSX, replacing them by > SrcMem8, but neglected to fix the dependency in the emulation code > on ByteOp. This caused the instruction not to have any effect in > some circumstances. > > Fix by replacing the check for ByteOp with the equivalent src.op_bytes == 1. [...] Also needed for 3.4, based on the commit that's blamed. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: [ 40/46] KVM: PIC: call ack notifiers for irqs that are dropped form irr
On Sun, 2012-08-19 at 20:59 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.5-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Gleb Natapov > > (cherry picked from commit aea218f3cbbcaac249b6b2c98930a00d6d931f1e) > > After commit 242ec97c358256 PIT interrupts are no longer delivered after > PIC reset. It happens because PIT injects interrupt only if previous one > was acked, but since on PIC reset it is dropped from irr it will never > be delivered and hence acknowledged. Fix that by calling ack notifier on > PIC reset. [...] Based on the commit blamed for the regression, I think this is needed for 3.4 as well. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: [PATCH RESEND] extcon: fix typos in extcon-arizona
On 08/23/2012 04:27 AM, Peter Meerwald wrote:
> Signed-off-by: Peter Meerwald
> ---
> drivers/extcon/extcon-arizona.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 427a289..6d24822 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -313,7 +313,7 @@ static int __devinit arizona_extcon_probe(struct
> platform_device *pdev)
>
> info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
> if (!info) {
> - dev_err(>dev, "failed to allocate memory\n");
> + dev_err(>dev, "Failed to allocate memory\n");
> ret = -ENOMEM;
> goto err;
> }
> @@ -350,7 +350,7 @@ static int __devinit arizona_extcon_probe(struct
> platform_device *pdev)
>
> ret = extcon_dev_register(>edev, arizona->dev);
> if (ret < 0) {
> - dev_err(arizona->dev, "extcon_dev_regster() failed: %d\n",
> + dev_err(arizona->dev, "extcon_dev_register() failed: %d\n",
> ret);
> goto err;
> }
Signed-off-by: Chanwoo Choi
I will apply this patch to
http://10.90.51.51/cgi-bin/gitweb.cgi?p=linux-samsung;a=shortlog;h=refs/heads/extcon-for-next
and you can check it after some hours.
Thank you
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] extcon: fixing typos
On 08/23/2012 04:27 AM, Peter Meerwald wrote: > Signed-off-by: Peter Meerwald > --- > drivers/extcon/extcon_class.c |8 > include/linux/extcon.h| 18 +- > 2 files changed, 13 insertions(+), 13 deletions(-) > This patch is already replied by Myungjoo Ham, so you can check it following git repository. - http://10.90.51.51/cgi-bin/gitweb.cgi?p=linux-samsung;a=shortlog;h=refs/heads/extcon-for-next. But, file name of 'extcon_class.c' has been modified from extcon_class.c to extcon-class.c, so i did modify and apply it. you can see patch which rename file name(extcon-class.c, extcon-gpio.c) http://git.kernel.org/?p=linux/kernel/git/gregkh/driver-core.git;a=commit;h=0ea62503782699adf5757cb1d3cd9f880d13c48c Thank you, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] extcon: fix typos in max77693 driver
On 08/23/2012 04:27 AM, Peter Meerwald wrote: > Signed-off-by: Peter Meerwald > --- > drivers/extcon/extcon-max77693.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) This patch is already applied by Myungjoo Ham, so you can check it following git repository. - http://10.90.51.51/cgi-bin/gitweb.cgi?p=linux-samsung;a=shortlog;h=refs/heads/extcon-for-next Thank you Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] extcon: fix typos in sys-class-extcon
On 08/23/2012 04:27 AM, Peter Meerwald wrote:
> Signed-off-by: Peter Meerwald
> ---
> Documentation/ABI/testing/sysfs-class-extcon | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-extcon
> b/Documentation/ABI/testing/sysfs-class-extcon
> index 20ab361..57a7262 100644
> --- a/Documentation/ABI/testing/sysfs-class-extcon
> +++ b/Documentation/ABI/testing/sysfs-class-extcon
> @@ -13,7 +13,7 @@ Description:
> accessory cables have such capability. For example,
> the 30-pin port of Nuri board (/arch/arm/mach-exynos)
> may have both HDMI and Charger attached, or analog audio,
> - video, and USB cables attached simulteneously.
> + video, and USB cables attached simultaneously.
>
> If there are cables mutually exclusive with each other,
> such binary relations may be expressed with extcon_dev's
> @@ -35,7 +35,7 @@ Description:
> The /sys/class/extcon/.../state shows and stores the cable
> attach/detach information of the corresponding extcon object.
> If the extcon object has an optional callback "show_state"
> - defined, the showing function is overriden with the optional
> + defined, the showing function is overridden with the optional
> callback.
>
> If the default callback for showing function is used, the
> @@ -46,19 +46,19 @@ Description:
> TA=1
> EAR_JACK=0
> #
> - In this example, the extcon device have USB_OTG and TA
> + In this example, the extcon device has USB_OTG and TA
> cables attached and HDMI and EAR_JACK cables detached.
>
> In order to update the state of an extcon device, enter a hex
> - state number starting with 0x.
> - echo 0xHEX > state
> + state number starting with 0x:
> + # echo 0xHEX > state
>
> - This updates the whole state of the extcon dev.
> + This updates the whole state of the extcon device.
> Inputs of all the methods are required to meet the
> - mutually_exclusive contidions if they exist.
> + mutually_exclusive conditions if they exist.
>
> It is recommended to use this "global" state interface if
> - you need to enter the value atomically. The later state
> + you need to set the value atomically. The later state
> interface associated with each cable cannot update
> multiple cable states of an extcon device simultaneously.
>
> @@ -73,7 +73,7 @@ What: /sys/class/extcon/.../cable.x/state
> Date:February 2012
> Contact: MyungJoo Ham
> Description:
> - The /sys/class/extcon/.../cable.x/name shows and stores the
> + The /sys/class/extcon/.../cable.x/state shows and stores the
> state of cable "x" (integer between 0 and 31) of an extcon
> device. The state value is either 0 (detached) or 1
> (attached).
> @@ -83,8 +83,8 @@ Date: December 2011
> Contact: MyungJoo Ham
> Description:
> Shows the relations of mutually exclusiveness. For example,
> - if the mutually_exclusive array of extcon_dev is
> - {0x3, 0x5, 0xC, 0x0}, the, the output is:
> + if the mutually_exclusive array of extcon device is
> + {0x3, 0x5, 0xC, 0x0}, then the output is:
> # ls mutually_exclusive/
> 0x3
> 0x5
Signed-off-by: Chanwoo Choi
I will apply this patch to
http://10.90.51.51/cgi-bin/gitweb.cgi?p=linux-samsung;a=shortlog;h=refs/heads/extcon-for-next
and you can check it after some hours.
Thank you
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
On 23/08/12 04:01, Tejun Heo wrote:
> Hello, Sasha.
>
> On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
>> +#define DEFINE_HASHTABLE(name, bits)
>> \
>> +struct hlist_head name[HASH_SIZE(bits)];
>
> Shouldn't this be something like the following?
>
> #define DEFINE_HASHTABLE(name, bits) \
> struct hlist_head name[HASH_SIZE(bits)] = \
> { [0 ... HASH_SIZE(bits) - 1] = HLIST_HEAD_INIT };
>
> Also, given that the declaration isn't non-trivial, you'll probably
> want a matching DECLARE_HASHTABLE() macro too.
>
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit
>> kernels. */
>> +#define hash_min(val, bits) ((sizeof(val)==4) ? hash_32((val), (bits)) :
>> hash_long((val), (bits)))
>
> Why is the branching condition sizeof(val) == 4 instead of <= 4?
> Also, no biggie but why isn't this macro in caps?
It should probably use gcc's statement expression extensions to prevent
side-effect issues with the arguments:
#define hash_min ({ \
sizeof(val) <= 4 ? \
hash_32(val, bits) :\
hash_long(val, bits)); \
})
~Ryan
--
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: linux-next: New tree -- linux-pstore.git
Hi Anton, On Tue, 21 Aug 2012 19:50:37 -0700 Anton Vorontsov wrote: > > Can you please add linux-pstore.git tree to the linux-next, > the repository address is as follows: > > git://git.infradead.org/users/cbou/linux-pstore.git master > > This tree is dedicated to track pstore infrastructure fixes and > enhancements, currently it holds these commits: > > Anton Vorontsov (3): > pstore/ram: Fix possible NULL dereference > pstore/ram: Mark ramoops_pstore_write_buf() as notrace > MAINTAINERS: Add pstore maintainers > > Jovi Zhang (1): > pstore/ram: Add missing platform_device_unregister > > Randy Dunlap (1): > pstore/ram: Fix printk format warning I have added this tree from today. I note that Linus may require you to GPG sign a tag for him to fetch since your tree is not located on kernel.org (he likes them anyway). I have put just you as the contact in case of problems - if anyone else should also be listed, just let me know. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgpZJmD38Yx0w.pgp Description: PGP signature
Re: [PATCHv3 4/4] ARM: kprobes: make more tests conditional
On Wed, 2012-08-22 at 18:41 +, Arnd Bergmann wrote:
> On Wednesday 22 August 2012, Nicolas Pitre wrote:
> > On Wed, 22 Aug 2012, Arnd Bergmann wrote:
> > > >
> > > > The ldrex/strex instructions are available on ARMv6. It's only the d
> > > > variants (strexd/ldrexd) which are only available from ARMv6k.
> > >
> > > Ok. How is the version below then? I haven't tested this one yet.
> >
> > In fact, I think the b variants are ARMv6k+ as well. Only the plain
> > (non b non d) variants are available on ARMv6.
>
> Ok, third attempt then. This leaves ldrex for ARMv6 but marks
> {st,ld}rex{b,h,d} as V6K specific (which includes ARMv7).
ARMv7 does set CPU_32v6K, because arch/arm/mm/Kconfig has
config CPU_V7
bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB
|| MACH_REALVIEW_PBX
select CPU_32v6K
select CPU_32v7
but this seems more for peripheral reasons not because all the various
CPU configs systematically select the earlier architecture variants,
e.g. CPU_V7 doesn't select CPU_32v6.
So I would have been inclined to test for
#if defined(CONFIG_CPU_32v6K) || (__LINUX_ARM_ARCH__ >= 7)
but as the current patch is functionally correct I'm not going to
suggest a v4 patch :-)
If you do feel so inclined for a v4 however ;-) you could also make the
mls part of the patch tidier by moving the added #endif to instead
terminate the preceding "#if __LINUX_ARM_ARCH__ >= 6", i.e.
@@ -367,8 +367,10 @@ void kprobe_arm_test_cases(void)
TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
+#endif
+#if __LINUX_ARM_ARCH__ >= 7
TEST_RRR( "mls r0, r",1, VAL1,", r",2, VAL2,", r",3, VAL3,"")
TEST_RRR( "mlshi r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
TEST_RR( "mls lr, r",1, VAL2,", r",2, VAL3,", r13")
this looks funny in patch form, but the resulting source file is more
consistent with other conditional tests.
> Arnd
>
> 8<-
> From 6eab418c61c18393006f30d189e2f28d6e403040 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann
> Date: Thu, 16 Aug 2012 07:49:31 +
> Subject: [PATCH] ARM: kprobes: make more tests conditional
>
> The mls instruction is not available in ARMv6K or below, so we
> should make the test conditional on at least ARMv7. ldrexd/strexd
> are available in ARMv6K or ARMv7, which we can test by checking
> the CONFIG_CPU_32v6K symbol. Just testing for ARMv6 is not enough.
>
> /tmp/ccuMTZ8D.s: Assembler messages:
> /tmp/ccuMTZ8D.s:22188: Error: selected processor does not support ARM mode
> `mls r0,r1,r2,r3'
> /tmp/ccuMTZ8D.s:2: Error: selected processor does not support ARM mode
> `mlshi r7,r8,r9,r10'
> /tmp/ccuMTZ8D.s:22252: Error: selected processor does not support ARM mode
> `mls lr,r1,r2,r13'
>
> Signed-off-by: Arnd Bergmann
> Cc: Jon Medhurst
> Cc: Russell King
> Cc: Nicolas Pitre
> Cc: Leif Lindholm
> ---
> arch/arm/kernel/kprobes-test-arm.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/kprobes-test-arm.c
> b/arch/arm/kernel/kprobes-test-arm.c
> index 38c1a3b..58dd6c3 100644
> --- a/arch/arm/kernel/kprobes-test-arm.c
> +++ b/arch/arm/kernel/kprobes-test-arm.c
> @@ -367,9 +367,11 @@ void kprobe_arm_test_cases(void)
> TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
> TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
>
> +#if __LINUX_ARM_ARCH__ >= 7
> TEST_RRR( "mls r0, r",1, VAL1,", r",2, VAL2,", r",3, VAL3,"")
> TEST_RRR( "mlshi r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
> TEST_RR( "mls lr, r",1, VAL2,", r",2, VAL3,", r13")
> +#endif
> TEST_UNSUPPORTED(".word 0xe06f3291 @ mls pc, r1, r2, r3")
> TEST_UNSUPPORTED(".word 0xe060329f @ mls r0, pc, r2, r3")
> TEST_UNSUPPORTED(".word 0xe0603f91 @ mls r0, r1, pc, r3")
> @@ -456,6 +458,7 @@ void kprobe_arm_test_cases(void)
> TEST_UNSUPPORTED(".word 0xe1700090") /* Unallocated space */
> #if __LINUX_ARM_ARCH__ >= 6
> TEST_UNSUPPORTED("ldrex r2, [sp]")
> +#ifdef CONFIG_CPU_32v6K
> TEST_UNSUPPORTED("strexdr0, r2, r3, [sp]")
> TEST_UNSUPPORTED("ldrexdr2, r3, [sp]")
> TEST_UNSUPPORTED("strexbr0, r2, [sp]")
> @@ -463,6 +466,7 @@ void kprobe_arm_test_cases(void)
> TEST_UNSUPPORTED("strexhr0, r2, [sp]")
> TEST_UNSUPPORTED("ldrexhr2, [sp]")
> #endif
> +#endif
> TEST_GROUP("Extra load/store instructions")
>
> TEST_RPR( "strhr",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
--
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] omapdrm: use alloc_ordered_workqueue() instead of UNBOUND w/ max_active = 1
This is an equivalent conversion and will ease scheduled removal of
WQ_NON_REENTRANT.
Only compile tested.
Signed-off-by: Tejun Heo
---
drivers/staging/omapdrm/omap_drv.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 4beab94..672cb3a 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -571,8 +571,7 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
dev->dev_private = priv;
- priv->wq = alloc_workqueue("omapdrm",
- WQ_UNBOUND | WQ_NON_REENTRANT, 1);
+ priv->wq = alloc_ordered_workqueue("omapdrm", 0);
INIT_LIST_HEAD(>obj_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/
[tip:x86/microcode] x86, microcode, AMD: Rewrite patch application procedure
Commit-ID: 2efb05e8e9fa3510044e007b90263c73b6a83f84
Gitweb: http://git.kernel.org/tip/2efb05e8e9fa3510044e007b90263c73b6a83f84
Author: Borislav Petkov
AuthorDate: Wed, 1 Aug 2012 16:16:13 +0200
Committer: H. Peter Anvin
CommitDate: Wed, 22 Aug 2012 16:16:29 -0700
x86, microcode, AMD: Rewrite patch application procedure
Limit the access to userspace only on the BSP where we load the
container, verify the patches in it and put them in the patch cache.
Then, at application time, we lookup the correct patch in the cache and
use it.
When we need to reload the userspace container, we do that over the
reload interface:
echo 1 > /sys/devices/system/cpu/microcode/reload
which reloads (a possibly newer) container from userspace and applies
then the newest patches from there.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1344361461-10076-13-git-send-email...@amd64.org
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/microcode_amd.c | 236 ---
1 files changed, 121 insertions(+), 115 deletions(-)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index cacdc9a..5511216 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -75,9 +75,6 @@ struct microcode_amd {
static struct equiv_cpu_entry *equiv_cpu_table;
-/* page-sized ucode patch buffer */
-void *patch;
-
struct ucode_patch {
struct list_head plist;
void *data;
@@ -184,7 +181,7 @@ static int collect_cpu_info_amd(int cpu, struct
cpu_signature *csig)
return 0;
}
-static unsigned int verify_ucode_size(int cpu, u32 patch_size,
+static unsigned int verify_patch_size(int cpu, u32 patch_size,
unsigned int size)
{
struct cpuinfo_x86 *c = _data(cpu);
@@ -214,73 +211,25 @@ static unsigned int verify_ucode_size(int cpu, u32
patch_size,
return patch_size;
}
-/*
- * we signal a good patch is found by returning its size > 0
- */
-static int get_matching_microcode(int cpu, const u8 *ucode_ptr,
- unsigned int leftover_size, int rev,
- unsigned int *current_size)
-{
- struct microcode_header_amd *mc_hdr;
- unsigned int actual_size, patch_size;
- u16 equiv_cpu_id;
-
- /* size of the current patch we're staring at */
- patch_size = *(u32 *)(ucode_ptr + 4);
- *current_size = patch_size + SECTION_HDR_SIZE;
-
- equiv_cpu_id = find_equiv_id(cpu);
- if (!equiv_cpu_id)
- return 0;
-
- /*
-* let's look at the patch header itself now
-*/
- mc_hdr = (struct microcode_header_amd *)(ucode_ptr + SECTION_HDR_SIZE);
-
- if (mc_hdr->processor_rev_id != equiv_cpu_id)
- return 0;
-
- /* ucode might be chipset specific -- currently we don't support this */
- if (mc_hdr->nb_dev_id || mc_hdr->sb_dev_id) {
- pr_err("CPU%d: chipset specific code not yet supported\n",
- cpu);
- return 0;
- }
-
- if (mc_hdr->patch_id <= rev)
- return 0;
-
- /*
-* now that the header looks sane, verify its size
-*/
- actual_size = verify_ucode_size(cpu, patch_size, leftover_size);
- if (!actual_size)
- return 0;
-
- /* clear the patch buffer */
- memset(patch, 0, PAGE_SIZE);
-
- /* all looks ok, get the binary patch */
- memcpy(patch, ucode_ptr + SECTION_HDR_SIZE, actual_size);
-
- return actual_size;
-}
-
static int apply_microcode_amd(int cpu)
{
- u32 rev, dummy;
- int cpu_num = raw_smp_processor_id();
- struct ucode_cpu_info *uci = ucode_cpu_info + cpu_num;
- struct microcode_amd *mc_amd = uci->mc;
struct cpuinfo_x86 *c = _data(cpu);
+ struct microcode_amd *mc_amd;
+ struct ucode_cpu_info *uci;
+ struct ucode_patch *p;
+ u32 rev, dummy;
+
+ BUG_ON(raw_smp_processor_id() != cpu);
- /* We should bind the task to the CPU */
- BUG_ON(cpu_num != cpu);
+ uci = ucode_cpu_info + cpu;
- if (mc_amd == NULL)
+ p = find_patch(cpu);
+ if (!p)
return 0;
+ mc_amd = p->data;
+ uci->mc = p->data;
+
rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
/* need to apply patch? */
@@ -336,61 +285,113 @@ static void free_equiv_cpu_table(void)
equiv_cpu_table = NULL;
}
-static enum ucode_state
-generic_load_microcode(int cpu, const u8 *data, size_t size)
+static void cleanup(void)
{
- struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
- struct microcode_header_amd *mc_hdr = NULL;
- unsigned int mc_size, leftover, current_size = 0;
+ free_equiv_cpu_table();
+ free_cache();
+}
+
+/*
+ * We return the current size even if some of the checks failed so that
+ * we can skip over the next patch. If we return a
[tip:x86/microcode] x86, microcode, AMD: Add a small, per-family patches cache
Commit-ID: a3eb3b4da106a23b5d41bf915726172e31654a65
Gitweb: http://git.kernel.org/tip/a3eb3b4da106a23b5d41bf915726172e31654a65
Author: Borislav Petkov
AuthorDate: Wed, 1 Aug 2012 15:38:18 +0200
Committer: H. Peter Anvin
CommitDate: Wed, 22 Aug 2012 16:16:21 -0700
x86, microcode, AMD: Add a small, per-family patches cache
This is a trivial cache which collects all ucode patches for the current
family of CPUs on the system. If a newer patch appears due to the
container file being updated in userspace, we replace our cached version
with the new one.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1344361461-10076-12-git-send-email...@amd64.org
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/microcode_amd.c | 67 ++-
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index 03ed5af..cacdc9a 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -78,12 +78,22 @@ static struct equiv_cpu_entry *equiv_cpu_table;
/* page-sized ucode patch buffer */
void *patch;
+struct ucode_patch {
+ struct list_head plist;
+ void *data;
+ u32 patch_id;
+ u16 equiv_cpu;
+};
+
+static LIST_HEAD(pcache);
+
static u16 find_equiv_id(unsigned int cpu)
{
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
int i = 0;
- BUG_ON(equiv_cpu_table == NULL);
+ if (!equiv_cpu_table)
+ return 0;
while (equiv_cpu_table[i].installed_cpu != 0) {
if (uci->cpu_sig.sig == equiv_cpu_table[i].installed_cpu)
@@ -108,6 +118,61 @@ static u32 find_cpu_family_by_equiv_cpu(u16 equiv_cpu)
return 0;
}
+/*
+ * a small, trivial cache of per-family ucode patches
+ */
+static struct ucode_patch *cache_find_patch(u16 equiv_cpu)
+{
+ struct ucode_patch *p;
+
+ list_for_each_entry(p, , plist)
+ if (p->equiv_cpu == equiv_cpu)
+ return p;
+ return NULL;
+}
+
+static void update_cache(struct ucode_patch *new_patch)
+{
+ struct ucode_patch *p;
+
+ list_for_each_entry(p, , plist) {
+ if (p->equiv_cpu == new_patch->equiv_cpu) {
+ if (p->patch_id >= new_patch->patch_id)
+ /* we already have the latest patch */
+ return;
+
+ list_replace(>plist, _patch->plist);
+ kfree(p->data);
+ kfree(p);
+ return;
+ }
+ }
+ /* no patch found, add it */
+ list_add_tail(_patch->plist, );
+}
+
+static void free_cache(void)
+{
+ struct ucode_patch *p;
+
+ list_for_each_entry_reverse(p, , plist) {
+ __list_del(p->plist.prev, p->plist.next);
+ kfree(p->data);
+ kfree(p);
+ }
+}
+
+static struct ucode_patch *find_patch(unsigned int cpu)
+{
+ u16 equiv_id;
+
+ equiv_id = find_equiv_id(cpu);
+ if (!equiv_id)
+ return NULL;
+
+ return cache_find_patch(equiv_id);
+}
+
static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig)
{
struct cpuinfo_x86 *c = _data(cpu);
--
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:x86/microcode] x86, microcode, AMD: Add reverse equiv table search
Commit-ID: c96d2c0905cc48e34f2b37b775b59932c416b343
Gitweb: http://git.kernel.org/tip/c96d2c0905cc48e34f2b37b775b59932c416b343
Author: Borislav Petkov
AuthorDate: Wed, 1 Aug 2012 14:55:01 +0200
Committer: H. Peter Anvin
CommitDate: Wed, 22 Aug 2012 16:16:11 -0700
x86, microcode, AMD: Add reverse equiv table search
We search the equivalence table using the CPUID(1) signature of the
CPU in order to get the equivalence ID of the patch which we need to
apply. Add a function which does the reverse - it will be needed in
later patches.
While at it, pull the other equiv table function up in the file so that
it can be used by other functionality without forward declarations.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1344361461-10076-11-git-send-email...@amd64.org
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/microcode_amd.c | 46 +-
1 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index 94ecdaa..03ed5af 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -78,6 +78,36 @@ static struct equiv_cpu_entry *equiv_cpu_table;
/* page-sized ucode patch buffer */
void *patch;
+static u16 find_equiv_id(unsigned int cpu)
+{
+ struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+ int i = 0;
+
+ BUG_ON(equiv_cpu_table == NULL);
+
+ while (equiv_cpu_table[i].installed_cpu != 0) {
+ if (uci->cpu_sig.sig == equiv_cpu_table[i].installed_cpu)
+ return equiv_cpu_table[i].equiv_cpu;
+
+ i++;
+ }
+ return 0;
+}
+
+static u32 find_cpu_family_by_equiv_cpu(u16 equiv_cpu)
+{
+ int i = 0;
+
+ BUG_ON(!equiv_cpu_table);
+
+ while (equiv_cpu_table[i].equiv_cpu != 0) {
+ if (equiv_cpu == equiv_cpu_table[i].equiv_cpu)
+ return equiv_cpu_table[i].installed_cpu;
+ i++;
+ }
+ return 0;
+}
+
static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig)
{
struct cpuinfo_x86 *c = _data(cpu);
@@ -119,22 +149,6 @@ static unsigned int verify_ucode_size(int cpu, u32
patch_size,
return patch_size;
}
-static u16 find_equiv_id(unsigned int cpu)
-{
- struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
- int i = 0;
-
- BUG_ON(equiv_cpu_table == NULL);
-
- while (equiv_cpu_table[i].installed_cpu != 0) {
- if (uci->cpu_sig.sig == equiv_cpu_table[i].installed_cpu)
- return equiv_cpu_table[i].equiv_cpu;
-
- i++;
- }
- return 0;
-}
-
/*
* we signal a good patch is found by returning its size > 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:x86/microcode] x86, microcode: Add a refresh firmware flag to ->request_microcode_fw
Commit-ID: 48e30685caa8bdc4b8d4417d8ac31db59689742c
Gitweb: http://git.kernel.org/tip/48e30685caa8bdc4b8d4417d8ac31db59689742c
Author: Borislav Petkov
AuthorDate: Thu, 26 Jul 2012 15:51:00 +0200
Committer: H. Peter Anvin
CommitDate: Wed, 22 Aug 2012 16:15:58 -0700
x86, microcode: Add a refresh firmware flag to ->request_microcode_fw
This is done in preparation for teaching the ucode driver to either load
a new ucode patches container from userspace or use an already cached
version. No functionality change in this patch.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1344361461-10076-10-git-send-email...@amd64.org
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/microcode.h |4 ++--
arch/x86/kernel/microcode_amd.c |3 ++-
arch/x86/kernel/microcode_core.c | 11 ++-
arch/x86/kernel/microcode_intel.c |3 ++-
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 8813be6..43d921b 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -15,8 +15,8 @@ struct microcode_ops {
enum ucode_state (*request_microcode_user) (int cpu,
const void __user *buf, size_t size);
- enum ucode_state (*request_microcode_fw) (int cpu,
- struct device *device);
+ enum ucode_state (*request_microcode_fw) (int cpu, struct device *,
+ bool refresh_fw);
void (*microcode_fini_cpu) (int cpu);
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index 25d34b1..94ecdaa 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -330,7 +330,8 @@ out:
*
* These might be larger than 2K.
*/
-static enum ucode_state request_microcode_amd(int cpu, struct device *device)
+static enum ucode_state request_microcode_amd(int cpu, struct device *device,
+ bool refresh_fw)
{
char fw_name[36] = "amd-ucode/microcode_amd.bin";
const struct firmware *fw;
diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index dcde544..9420972 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -282,7 +282,7 @@ static int reload_for_cpu(int cpu)
if (!uci->valid)
return err;
- ustate = microcode_ops->request_microcode_fw(cpu, _pdev->dev);
+ ustate = microcode_ops->request_microcode_fw(cpu, _pdev->dev,
true);
if (ustate == UCODE_OK)
apply_microcode_on_target(cpu);
else
@@ -377,7 +377,7 @@ static enum ucode_state microcode_resume_cpu(int cpu)
return UCODE_OK;
}
-static enum ucode_state microcode_init_cpu(int cpu)
+static enum ucode_state microcode_init_cpu(int cpu, bool refresh_fw)
{
enum ucode_state ustate;
@@ -388,7 +388,8 @@ static enum ucode_state microcode_init_cpu(int cpu)
if (system_state != SYSTEM_RUNNING)
return UCODE_NFOUND;
- ustate = microcode_ops->request_microcode_fw(cpu, _pdev->dev);
+ ustate = microcode_ops->request_microcode_fw(cpu, _pdev->dev,
+refresh_fw);
if (ustate == UCODE_OK) {
pr_debug("CPU%d updated upon init\n", cpu);
@@ -405,7 +406,7 @@ static enum ucode_state microcode_update_cpu(int cpu)
if (uci->valid)
return microcode_resume_cpu(cpu);
- return microcode_init_cpu(cpu);
+ return microcode_init_cpu(cpu, false);
}
static int mc_device_add(struct device *dev, struct subsys_interface *sif)
@@ -421,7 +422,7 @@ static int mc_device_add(struct device *dev, struct
subsys_interface *sif)
if (err)
return err;
- if (microcode_init_cpu(cpu) == UCODE_ERROR)
+ if (microcode_init_cpu(cpu, true) == UCODE_ERROR)
return -EINVAL;
return err;
diff --git a/arch/x86/kernel/microcode_intel.c
b/arch/x86/kernel/microcode_intel.c
index 0327e2b..3544aed 100644
--- a/arch/x86/kernel/microcode_intel.c
+++ b/arch/x86/kernel/microcode_intel.c
@@ -405,7 +405,8 @@ static int get_ucode_fw(void *to, const void *from, size_t
n)
return 0;
}
-static enum ucode_state request_microcode_fw(int cpu, struct device *device)
+static enum ucode_state request_microcode_fw(int cpu, struct device *device,
+bool refresh_fw)
{
char name[30];
struct cpuinfo_x86 *c = _data(cpu);
--
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/
