Re: [PATCH 02/12] clocksource: sh_mtu2: Add clk_prepare/unprepare support
On Mon, Oct 28, 2013 at 11:49:19PM +0100, Laurent Pinchart wrote: > Prepare the clock at probe time, as there is no other appropriate place > in the driver where we're allowed to sleep. > > Cc: Daniel Lezcano > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Laurent Pinchart > --- > drivers/clocksource/sh_mtu2.c | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) Thanks Laurent, I have queued this up in the clocksources branch of my renesas tree. I will send a pull request to Mike once v3.13-rc1 has hit the shelves. Mike, please let me know if you would prefer something earlier than that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 03/12] clocksource: sh_tmu: Add clk_prepare/unprepare support
On Mon, Oct 28, 2013 at 11:49:20PM +0100, Laurent Pinchart wrote: > Prepare the clock at probe time, as there is no other appropriate place > in the driver where we're allowed to sleep. > > Cc: Daniel Lezcano > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Laurent Pinchart > --- > drivers/clocksource/sh_tmu.c | 20 +--- > 1 file changed, 17 insertions(+), 3 deletions(-) Thanks Laurent, I have queued this up in the clocksources branch of my renesas tree. I will send a pull request to Mike once v3.13-rc1 has hit the shelves. Mike, please let me know if you would prefer something earlier than that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] clocksource: sh_cmt: Add clk_prepare/unprepare support
On Mon, Oct 28, 2013 at 11:49:18PM +0100, Laurent Pinchart wrote:
> Prepare the clock at probe time, as there is no other appropriate place
> in the driver where we're allowed to sleep.
>
> Cc: Daniel Lezcano
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Laurent Pinchart
Thanks Laurent,
I have queued this up in the clocksources branch of my renesas tree.
I will send a pull request to Mike once v3.13-rc1 has hit the shelves.
Mike, please let me know if you would prefer something earlier than that.
> ---
> drivers/clocksource/sh_cmt.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
> index 0965e98..940341a 100644
> --- a/drivers/clocksource/sh_cmt.c
> +++ b/drivers/clocksource/sh_cmt.c
> @@ -634,12 +634,18 @@ static int sh_cmt_clock_event_next(unsigned long delta,
>
> static void sh_cmt_clock_event_suspend(struct clock_event_device *ced)
> {
> - pm_genpd_syscore_poweroff(_to_sh_cmt(ced)->pdev->dev);
> + struct sh_cmt_priv *p = ced_to_sh_cmt(ced);
> +
> + pm_genpd_syscore_poweroff(>pdev->dev);
> + clk_unprepare(p->clk);
> }
>
> static void sh_cmt_clock_event_resume(struct clock_event_device *ced)
> {
> - pm_genpd_syscore_poweron(_to_sh_cmt(ced)->pdev->dev);
> + struct sh_cmt_priv *p = ced_to_sh_cmt(ced);
> +
> + clk_prepare(p->clk);
> + pm_genpd_syscore_poweron(>pdev->dev);
> }
>
> static void sh_cmt_register_clockevent(struct sh_cmt_priv *p,
> @@ -737,6 +743,10 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct
> platform_device *pdev)
> goto err2;
> }
>
> + ret = clk_prepare(p->clk);
> + if (ret < 0)
> + goto err3;
> +
> if (res2 && (resource_size(res2) == 4)) {
> /* assume both CMSTR and CMCSR to be 32-bit */
> p->read_control = sh_cmt_read32;
> @@ -773,19 +783,21 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct
> platform_device *pdev)
> cfg->clocksource_rating);
> if (ret) {
> dev_err(>pdev->dev, "registration failed\n");
> - goto err3;
> + goto err4;
> }
> p->cs_enabled = false;
>
> ret = setup_irq(irq, >irqaction);
> if (ret) {
> dev_err(>pdev->dev, "failed to request irq %d\n", irq);
> - goto err3;
> + goto err4;
> }
>
> platform_set_drvdata(pdev, p);
>
> return 0;
> +err4:
> + clk_unprepare(p->clk);
> err3:
> clk_put(p->clk);
> err2:
> --
> 1.8.1.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arch: use ASM_NL instead of ';' for assembler new line character in the macro
On 10/29/2013 07:21 AM, Chen Gang wrote:
> For some assemblers, they use another character as newline in a macro
> (e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a
> macro) instead of ';' for it.
>
> Also need notice about code styles ('\t' for each line).
>
>
> Signed-off-by: Chen Gang
> ---
> arch/arc/include/asm/linkage.h |2 ++
> include/linux/linkage.h| 19 ---
Acked-by: Vineet Gupta
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] of: Add empty for_each_available_child_of_node() macro definition
On Mon, Oct 28, 2013 at 1:12 PM, Josh Cartwright wrote: > From: Sylwester Nawrocki > > Add this empty macro definition so users can be compiled without > excluding this macro call with preprocessor directives when CONFIG_OF > is disabled. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park I'm assuming the rest of this is not going to make 3.13, so I've applied this for 3.13. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI: remove unused ACPI_PROCFS Kconfig param
2013/10/28 Paul Bolle : > On Mon, 2013-10-28 at 07:22 +0100, Michael Opdenacker wrote: >> [...] CONFIG_ACPI_PROCFS is no longer used anywhere, neither in >> Makefiles nor in the source code. ACPI_PROCFS isn't event used in >> Kconfig files as an intermediate dependency. >> >> What I deduce from that is that even if you set CONFIG_ACPI_PROCFS=y in >> the kernel configuration, this will have no impact at all. > > About half a year ago I noticed that this Kconfig symbol is unused since > v2.6.38 [0]. As, apparently, nothing has changed it is currently unused > for over two and a half years. > > I still don't really understand the purpose of this symbol. But whatever > it is, it might as well be dropped. If it's ever needed again it could > be re-added. Or, perhaps, an entirely different approach could be used > to accomplish what that symbol is supposed to do. I prefer the later. I will add new sysfs interface for LID status and make all proc related code in the /driver/acpi/button.c under CONFIG_ACPI_PROCFS. > > > Paul Bolle > > [0] http://marc.info/?l=linux-acpi=136398635322975 > -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
Hi Ingo, On Sat, 26 Oct 2013 11:50:23 +0200, Ingo Molnar wrote: > * Srikar Dronamraju wrote: > >> Hi Pekka, >> >> > > >> > > You can now use it in all perf tools, such as: >> > > >> > > perf record -e libc:my_event -aR sleep 1 >> > >> > Is there a technical reason why 'perf list' could not show all the >> > available SDT markers on a system and that the 'market to event' >> > mapping cannot happen automatically? >> > >> >> Technically feasible. But then we would have to parse each of the >> libraries and executables to list them. Right? I am not sure if >> such a delay is acceptable. > > I'd say lets try Pekka's suggestion and make it more palatable if > there's complaints about the delay. (SSD systems are becoming > dominant and there the search should be reasonably fast.) > > We could also make 'perf list' more sophisticated, if invoked > naively as 'perf list' then maybe it should first display the > various event categories, with a (rough) count: > > $ perf list >34 hardware events # use 'perf list --hw'to list them >40 hw-cache events # use 'perf list --cache' to list them >20 software events # use 'perf list --sw'to list them > 2 raw events# use 'perf list --raw' to list them > 120 tracepoints # use 'perf list --tp'to list them > >10 SDT tracepoints # use 'perf list --sdt' to list them > > # use 'perf list -a' to list all events > # use 'perf list ./binary' to list events in a given binary > > I.e. bring a bit more structure into it. I like this. :) Note that 'perf list' already support this kind of filtering now: $ perf list hw cache sw tracepoint pmu or $ perf list sched:* It'd be great if this globbing also supports SDTs. And for 'perf list ./binary' case, it could detect libraries in the dependency list and then also scan them. > >> Also if a binary exists in a path thats is not covered in the >> default search, an user might believe that his binary may not have >> markers. I know the above reason is more of a user folly than a >> tooling issue. > > I think in 99% of the usecases people will either use pre-built > markers that come with their distro, or will be intimately aware of > the markers because they are in the very app they are developing. > > So I wouldn't worry about 'user has a weird binary' case too much. > > I agree with Pekka that making them easily discoverable and visible > as a coherent whole is really important. Agreed. We do need to improve the user experience of the perf tools! Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sched: Aggressive balance in domains whose groups share package resources
Hi Peter, On 10/28/2013 09:23 PM, Peter Zijlstra wrote: > On Mon, Oct 21, 2013 at 05:15:02PM +0530, Vaidyanathan Srinivasan wrote: >> From: Preeti U Murthy >> >> The current logic in load balance is such that after picking the >> busiest group, the load is attempted to be moved from the busiest cpu >> in that group to the dst_cpu. If the load cannot be moved from the >> busiest cpu to dst_cpu due to either tsk_cpus_allowed mask or cache >> hot tasks, then the dst_cpu is changed to be another idle cpu within >> the dst->grpmask. If even then, the load cannot be moved from the >> busiest cpu, then the source group is changed. The next busiest group >> is found and the above steps are repeated. >> >> However if the cpus in the group share package resources, then when >> a load movement from the busiest cpu in this group fails as above, >> instead of finding the next busiest group to move load from, find the >> next busiest cpu *within the same group* from which to move load away. >> By doing so, a conscious effort is made during load balancing to keep >> just one cpu busy as much as possible within domains that have >> SHARED_PKG_RESOURCES flag set unless under scenarios of high load. >> Having multiple cpus busy within a domain which share package resource >> could lead to a performance hit. >> >> A similar scenario arises in active load balancing as well. When the >> current task on the busiest cpu cannot be moved away due to task >> pinning, currently no more attempts at load balancing is made. > >> This >> patch checks if the balancing is being done on a group whose cpus >> share package resources. If so, then check if the load balancing can >> be done for other cpus in the same group. > > So I absolutely hate this patch... Also I'm not convinced I actually > understand the explanation above. > > Furthermore; there is nothing special about spreading tasks for > SHARED_PKG_RESOURCES and special casing that one case is just wrong. > > If anything it should be keyed off of SD_PREFER_SIBLING and or > cpu_power. At a SIBLING level, which has SHARED_PKG_RESOURCES set, cpu_power in fact takes care of ensuring that the scheduler mostly spreads the load when there is more than one running task by nominating the group as busy. But the issue that this patch is bringing to the front is a bit different; its not during the time of this nomination, its at the time of load balancing. It is explained below. So metrics like cpu_power and flags like SD_PREFER_SIBLING ensure that we spread the load by nominating such groups as busiest in update_sg_lb_stats() and update_sd_lb_stats(). So "nominating a group" as busiest by virtue of cpu_power or flags is taken care of. However, in load_balance(), if the imbalance cannot be offset by moving load from the busiest_cpu in the busiest_group, then today we do not try the *next busiest cpu in the group*; instead we try the next busiest_group. So whatever effort we put in by nominating this group as busiest, if the grp_power and flags do not favour tasks on it, seems relevant only if the busiest cpu in that group co-operates in offloading tasks. Should we not be trying our best to move load from any other cpu in this group ? This patch identifies one such situation, which led to too many tasks on a core and got me to ponder over this question. I agree that the fix in this patch is not right. But I thought this would open up discussion around the above question. Its true that iterating over all the cpus in a group during the actual load balance is too much of an overhead, but isn't there a balance we can strike during load balance iterations for such groups which have limited cpu power? > Thanks Regards Preeti U Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/6] export efi runtime memory mapping to sysfs
On 10/27/13 at 11:47am, Dave Young wrote: > kexec kernel will need exactly same mapping for > efi runtime memory ranges. Thus here export the > runtime ranges mapping to sysfs, kexec-tools > will assemble them and pass to 2nd kernel via > setup_data. > > Introducing a new directly /sys/firmware/efi/efi-runtime-map > Just like /sys/firmware/memmap. Containing below attribute > in each file of that directory: > attribute num_pages phys_addr type virt_addr > > It will not work for efi 32bit. Only x86_64 currently. > > Signed-off-by: Dave Young > --- > arch/x86/include/asm/efi.h |3 > arch/x86/platform/efi/efi.c| 11 ++ > drivers/firmware/efi/Kconfig | 10 + > drivers/firmware/efi/Makefile |1 > drivers/firmware/efi/efi-runtime-map.c | 166 > + > drivers/firmware/efi/efi.c |3 > 6 files changed, 193 insertions(+), 1 deletion(-) Remind myself: add below to Documentaion in next version: Documentation/ABI/testing/sysfs-efi-runtime-map -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
Hi Masami, On Tue, 29 Oct 2013 12:19:37 +0900, Masami Hiramatsu wrote: > (2013/10/29 2:48), Pekka Enberg wrote: >> For the 32-bit and 64-bit libc case, why cannot 'perf list' >> by default print out something like: >> >> $ perf list >> >>libc:setjmp [SDT marker group] >> >> and provide a '--fully-qualified' command line option that: >> >> $ perf list --fully-qualified >> >> libc:setjmp => libc32:setjmp, libc64:setjmp [SDT marker group] >> libc32:setjmp => libc:setjmp@/lib/libc.so.6 [SDT marker] >> libc64:setjmp => libc:setjmp@/lib64/libc.so.6 [SDT marker] >> >> and then teach 'perf trace' to deal with SDT marker groups >> where you trace two events, not one? > > Ah, that's a good idea. :) > And it also is needed for another probe event because > sometimes inlined functions have multiple instances. > I'd like to fold them as one event group. Yes, I'd love to see it as well. :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of "perf: Add a new sort order: SORT_INCLUSIVE"
On Mon, 28 Oct 2013 21:10:38 -0700, Arun Sharma wrote: > On 10/28/13 8:11 PM, Namhyung Kim wrote: > > Hey Namhyung: > >>> >>> Also, what's the reasoning for --cumulate not being an option under >>> perf record -g ..,? >> >> Sorry, I cannot understand you. The 'perf record' just saves sample >> data (and callchains) from the ring-buffer. All the processing happens >> in 'perf report'. I can't see what you expect from the 'perf record >> --cumulate'. Am I missing something? > > Yes - I meant to say perf report -g :) :) > >> -g [type,min[,limit],order] > > Specifically, along with callee, caller, we could have a third > option. Or we could have a new type (graph, fractal, cumulative). That's also fine by me. But I added --cumulate since it's quite different from other callchain behaviors. If we go with -g option, I'd like add it as a new type. > >>> Given that there are clear use cases in production involving complex >>> callgraphs, I'm for getting this support in first and then reconciling >>> the differences with perf record -b later. >> >> I think what Frederic said is that the code de-duplication of 'perf >> report' side. The branch stack and --cumulate are different - branch >> stack concentrates on the branch itself but --cumulate uses callchains >> to find parents and give some credit to them as side information. > > Me too. I brought it up with Stephane at some point in the last year > or so and there wasn't an obvious way to de-duplicate because of these > differences. Yeah, looking at the code, I can hardly find how I can do it. :-/ Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] perf tools: Split -g and --call-graph for record command
On Mon, 28 Oct 2013 12:20:53 -0600, David Ahern wrote: > On 10/28/13 11:46 AM, Arnaldo Carvalho de Melo wrote: >> Added this: >> >> --call-graph:: >> Setup and enable call-graph (stack chain/backtrace) recording, >> implies -g. >> >> Allows specifying "fp" (frame pointer) or "dwarf" >> (DWARF's CFI - Call Frame Information) as the method to collect >> the information used to show the call graphs. >> >> In some systems, where binaries are build wit gcc > > s/wit/with/ And also forgot to mention user stack dump size (and its default size) in case of "dwarf". Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] edac: Document Krait L1/L2 EDAC driver binding
On 10/28, Mark Rutland wrote: > On Tue, Oct 29, 2013 at 12:31:28AM +, Stephen Boyd wrote: > > + > > +Optional properties: > > +- interrupt-names: Should contain the interrupt names "l1_irq" and > > + "l2_irq" > > As with my comment on the parsing code, I'd prefer that if interrupt-names was > present it defined the order of interrupts. Otherwise it's redundant and of no > value. > > Otherwise, the binding looks fine to me: > > Acked-by: Mark Rutland How about I just drop the interrupt-names property? It isn't adding much and is a holdover from the vendor kernel. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Add Krait L2 accessor functions
On 10/28, Mark Rutland wrote: > On Tue, Oct 29, 2013 at 01:21:57AM +, Stephen Boyd wrote: > > On 10/28/13 18:19, Mark Rutland wrote: > > > It might be worth commmenting inline as to what register each of these is > > > accessing. Inevitably the commit message will become harder to find and > > > associate with the code over time. > > > > > > Similarly for get_l2_indirect_reg. > > > > Do you mean with the "@" syntax in the assembly? The 80-character limit > > is out to get me. > > I probably didn't mean inline :) > > How about a block comment above the first asm block like: > > /* > * Select the L2 window by poking l2cpselr, then write to the window via > * l2cpdr. > */ > Ok sure. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power_supply: Add charger control properties
On Sun, 27 Oct 2013 23:18:08 -0700 Anton Vorontsov wrote: > On Mon, Oct 28, 2013 at 03:36:36AM +, Tc, Jenny wrote: > > > But do we really want to control the chargers through the power_supply's > > > user-visible > > > interface? It makes the whole power supply thing so complicated that I'm > > > already losing > > > track of it. Right now I think I would prefer to move all the charger > > > logic out of the psy > > > class. > > > > > > > I think exposing properties make the logic generic, otherwise it may end up > > in having callback > > functions. > > > > Also there are some scenarios where the charging algorithm has to be in the > > user space. > > Which scenarios? > > Plus, I am more questioning if the power supply framework is the right > thing to control the *chargers*. Chargers are not the power supply to the > system or any device (well, except for the batteries themselves). I'm not sure this is (always) true. On my device (gta04.org) the battery, the USB OTG port, and a separate 5VDC input can each be the power source of the whole device. The USB and 5VDC cannot both be active concurrently, but either can be active together with the battery. The device can function without the battery, so the charger plugged into the USB-OTG must be supplying power to the system (not just the battery). The "charger" functionality sits between the battery and the external power supply monitoring the voltage on the battery and the current from the external supply. Based on these values (and some timers and a state machine) it enabled or disables the external supply and possibly imposes a current-limit on it. The three power sources all have "power_supply" devices registered (though the battery only does because it contains a bq27000 charger counter). I've been wondering where to put sysfs attributes to control the charging. I currently place them in the power_supply device for each external power source. That makes some sense for the 'current limit' value, but not for the 'battery volts at which to re-start charging' value. There is also a setting which affects whether the external source is switched off if the voltage drops below 4.4V. In some circumstances I want to leave the charger enabled then, as it could just mean the cyclist is taking a break and there should be current again soon. I think the sensible place for these tune-ables is with the battery. i.e. the power_supply that corresponds to the battery could register "min voltage" and "min current". The charger driver needs to know about this battery and about any power sources that can charge it, and uses the state of the battery to decide how to tune the state of the charger. I note that there is already something a lot like this between 88pm860x_battery.c and 88pm860x_charger.c They manage to locate each other and the charger call get_property and set_property on the battery. Maybe formalising this might be a useful way forward. I'm not sure that we really need a new driver-class for chargers. Maybe just a way to link external power supplies to battery power supplies, and maybe some agreement on what they are allowed to say to each other. Jenny: would something like that work for you?? Thanks, NeilBrown > > > Using the patch https://lkml.org/lkml/2013/7/25/204, > > the power supply change notification can be broadcasted. We can add > > notifier events > > for power_supply_register and thermal throttling. This way > > power_supply_charger.c can > > be a separate driver and it can listen to psy notifications to take actions. > > If you ever need this particular notifier, I am OK with it (but I'll > consider applying it only together with some its users). > > Basically, I am more against these three patches: > > [PATCH 3/7] power_supply: add throttle state > [PATCH 2/7] power_supply: add charger cable properties > [PATCH 1/7] power_supply: Add charger control properties (enable_charger part) > > These three add too much "charger" specifics to the power_supply stuff. I > think they deserve their own subsystem/class/whatever. > > Also, the battid framework is written without any notion of device/driver > separation, uses global variables, and I suspect it should not exist at > all (psy_get_batt_prop function makes me think that you should just > register the i2c/spi/w1 battery with the power_supply and not use the > ad-hoc stuff). > > 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/ signature.asc Description: PGP signature
Re: [PATCH] mm: cma: free cma page to buddy instead of being cpu hot page
Hello,
On Mon, Oct 28, 2013 at 07:42:49PM +0800, zhang.ming...@linaro.org wrote:
> From: Mingjun Zhang
>
> free_contig_range frees cma pages one by one and MIGRATE_CMA pages will be
> used as MIGRATE_MOVEABLE pages in the pcp list, it causes unnecessary
> migration action when these pages reused by CMA.
You are saying about the overhead but I'm not sure how much it is
because it wouldn't be frequent. Although it's frequent, migration is
already slow path and CMA migration is worse so I really wonder how much
pain is and how much this patch improve.
Having said that, it makes CMA allocation policy consistent which
is that CMA migration type is last fallback to minimize number of migration
and code peice you are adding is already low hit path so that I think
it has no problem.
>
> Signed-off-by: Mingjun Zhang
> ---
> mm/page_alloc.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0ee638f..84b9d84 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1362,7 +1362,8 @@ void free_hot_cold_page(struct page *page, int cold)
>* excessively into the page allocator
>*/
> if (migratetype >= MIGRATE_PCPTYPES) {
> - if (unlikely(is_migrate_isolate(migratetype))) {
> + if (unlikely(is_migrate_isolate(migratetype))
> + || is_migrate_cma(migratetype))
The concern is likely/unlikely usage is proper in this code peice.
If we don't use memory isolation, the code path is used for only
MIGRATE_RESERVE which is very rare allocation in normal workload.
Even, in memory isolation environement, I'm not sure how many
CMA/HOTPLUG is used compared to normal alloc/free.
So, I think below is more proper?
if (unlikely(migratetype >= MIGRATE_PCPTYPES)) {
if (is_migrate_isolate(migratetype) || is_migrate_cma(migratetype))
I know it's an another topic but I'd like to disucss it in this time because
we will forget such trivial thing later, again.
}
> free_one_page(zone, page, 0, migratetype);
> goto out;
> }
> --
> 1.7.9.5
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
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: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
On Mon, 2013-10-28 at 23:45 -0500, Bhushan Bharat-R65777 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 29, 2013 10:05 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder Stuart-B08248;
> > christoffer.d...@linaro.org; linux-kernel@vger.kernel.org;
> > a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395;
> > peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org;
> > gre...@linuxfoundation.org
> > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via
> > sysfs only
> >
> > On Mon, 2013-10-28 at 23:31 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, October 29, 2013 10:00 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder
> > > > Stuart-B08248; christoffer.d...@linaro.org;
> > > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > gre...@linuxfoundation.org
> > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > > binding via sysfs only
> > > >
> > > > On Mon, 2013-10-28 at 22:52 -0500, Bhushan Bharat-R65777 wrote:
> > > > > So when ids == NULL it does not check of vendor etc and calls
> > > > > pci_add_dynid()
> > > > which in turn calls driver_attach().
> > > > >
> > > > > If we change the above loop to break if ids->vendor == PCI_ANY_ID
> > > > >&& ids- subvendor == PCI_ANY_ID then also we will call pci_add_dyids().
> > > >
> > > > What problem are you trying to solve?
> > >
> > > new_id interface to continue working as before.
> >
> > In what specific way does this allow new_id to continue working as before?
> > Be
> > verbose.
>
>
> What I observed that this patch (kim's patch) new_id interface stops working.
Yes.
> This is found to be because store_new_id() checks for pdrv->id_table which
> is no more NULL, so the below check fails
I do not think that is the reason. The reason is because
sysfs_bind_only is set, and this is not a direct sysfs bind.
> if (ids) {
> ^^
> This is no more NULL, so enter inside the loop
>
> retval = -EINVAL;
> while (ids->vendor || ids->subvendor || ids->class_mask) {
> if (driver_data == ids->driver_data) {
> retval = 0;
> break;
> }
> ids++;
> }
> if (retval) /* No match */
> return retval;
> ^
> This is where it returns as -EINVAL
Why wouldn't it have broken out of the loop earlier, since driver_data
and ids->driver_data should both be zero? I assume this is with a patch
to do PCI_ANY_ID in vfio-pci.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 29, 2013 10:05 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder Stuart-B08248;
> christoffer.d...@linaro.org; linux-kernel@vger.kernel.org;
> a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395;
> peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via
> sysfs only
>
> On Mon, 2013-10-28 at 23:31 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, October 29, 2013 10:00 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder
> > > Stuart-B08248; christoffer.d...@linaro.org;
> > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > gre...@linuxfoundation.org
> > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > binding via sysfs only
> > >
> > > On Mon, 2013-10-28 at 22:52 -0500, Bhushan Bharat-R65777 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Tuesday, October 29, 2013 9:11 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder
> > > > > Stuart-B08248; christoffer.d...@linaro.org;
> > > > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > > gre...@linuxfoundation.org
> > > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > > > binding via sysfs only
> > > > >
> > > > > On Mon, 2013-10-28 at 22:38 -0500, Bhushan Bharat-R65777 wrote:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Monday, October 28, 2013 11:40 PM
> > > > > > > To: Alex Williamson
> > > > > > > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421;
> > > > > > > Yoder Stuart-B08248; christoffer.d...@linaro.org;
> > > > > > > linux-kernel@vger.kernel.org;
> > > > > > > a.mota...@virtualopensystems.com; ag...@suse.de; Sethi
> > > > > > > Varun-B16395; peter.mayd...@linaro.org;
> > > > > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > > > > gre...@linuxfoundation.org
> > > > > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for
> > > > > > > explicit binding via sysfs only
> > > > > > >
> > > > > > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote:
> > > > > > > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote:
> > > > > > > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
> > > > > > > > > > Force the vfio-pci driver to only be bound explicitly
> > > > > > > > > > via sysfs to avoid conflics with other drivers in the
> > > > > > > > > > event of a
> > > hotplug.
> > > > > > > > >
> > > > > > > > > We can't break userspace, so we can't disable the
> > > > > > > > > current method of binding devices to vfio-pci. We can
> > > > > > > > > add a new method and perhaps deprecate the existing
> > > > > > > > > mechanism to be removed at some point in the future.
> > > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > I thought the existing method involved using sysfs bind,
> > > > > > > > and this was just eliminating a race. How does the bind
> > > > > > > > get triggered
> > > currently?
> > > > > > >
> > > > > > > OK, so it seems it's relying on the write to new_id calling
> > > driver_attach().
> > > > > > > Sigh. I guess we could make driver-sysfs-bind-only be
> > > > > > > settable via sysfs, and have new-userspace set both that and
> > > > > > > PCI_ANY_ID (or the specific ID if userspace
> > > > > > > prefers) via new_id. The platform bus patches could
> > > > > > > continue as is, since there's no existing mechanism to break.
> > > > > >
> > > > > > What about changing the store_new_id() to bypass exact ids
> > > > > > check if driver
> > > > > have PCI_ANY_ID?
> > > > >
> > > > > I don't follow.
> > > >
> > > > store_new_id() function id defined as:
> > > >
> > > > static ssize_t store_new_id(struct device_driver *driver, const
> > > > char *buf, size_t count) {
> > > > struct pci_driver *pdrv = to_pci_driver(driver);
> > > > const struct pci_device_id *ids = pdrv->id_table;
> > > >
> > > >
> > > > /* Only accept driver_data values that match an existing
> > > > id_table
> > > >entry */
> > > > if (ids) {
> > > > retval = -EINVAL;
> > > > while (ids->vendor || ids->subvendor ||
> > > > ids->class_mask) {
> > > > if (driver_data == ids->driver_data) {
> > > > retval = 0;
>
Re: [PATCH v9 01/18] arm: make SWIOTLB available
ping?
On Fri, 25 Oct 2013, Stefano Stabellini wrote:
> Russell,
> this is the only patch that needs an ack at the moment.
> As you commented on it before and I have already addressed your comments
> few versions ago, unless you have any complaints I am going to add it to
> linux-next and I am thinking of merging it during the next merge window.
>
> On Fri, 25 Oct 2013, Stefano Stabellini wrote:
> > IOMMU_HELPER is needed because SWIOTLB calls iommu_is_span_boundary,
> > provided by lib/iommu_helper.c.
> >
> > Signed-off-by: Stefano Stabellini
> > Reviewed-by: Konrad Rzeszutek Wilk
> > CC: will.dea...@arm.com
> > CC: li...@arm.linux.org.uk
> >
> >
> > Changes in v8:
> > - use __phys_to_pfn and __pfn_to_phys.
> >
> > Changes in v7:
> > - dma_mark_clean: empty implementation;
> > - in dma_capable use coherent_dma_mask if dma_mask hasn't been
> > allocated.
> >
> > Changes in v6:
> > - check for dev->dma_mask being NULL in dma_capable.
> >
> > Changes in v5:
> > - implement dma_mark_clean using dmac_flush_range.
> >
> > Changes in v3:
> > - dma_capable: do not treat dma_mask as a limit;
> > - remove SWIOTLB dependency on NEED_SG_DMA_LENGTH.
> > ---
> > arch/arm/Kconfig |6 +
> > arch/arm/include/asm/dma-mapping.h | 37
> >
> > 2 files changed, 43 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 1ad6fb6..b08374f 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1872,6 +1872,12 @@ config CC_STACKPROTECTOR
> > neutralized via a kernel panic.
> > This feature requires gcc version 4.2 or above.
> >
> > +config SWIOTLB
> > + def_bool y
> > +
> > +config IOMMU_HELPER
> > + def_bool SWIOTLB
> > +
> > config XEN_DOM0
> > def_bool y
> > depends on XEN
> > diff --git a/arch/arm/include/asm/dma-mapping.h
> > b/arch/arm/include/asm/dma-mapping.h
> > index 5b579b9..01b5a3d 100644
> > --- a/arch/arm/include/asm/dma-mapping.h
> > +++ b/arch/arm/include/asm/dma-mapping.h
> > @@ -10,6 +10,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #define DMA_ERROR_CODE (~0)
> > extern struct dma_map_ops arm_dma_ops;
> > @@ -86,6 +87,42 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
> > void *addr)
> > }
> > #endif
> >
> > +static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> > +{
> > + unsigned int offset = paddr & ~PAGE_MASK;
> > + return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
> > +}
> > +
> > +static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t
> > dev_addr)
> > +{
> > + unsigned int offset = dev_addr & ~PAGE_MASK;
> > + return __pfn_to_phys(dma_to_pfn(dev, dev_addr)) + offset;
> > +}
> > +
> > +static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t
> > size)
> > +{
> > + u64 limit, mask;
> > +
> > + if (dev->dma_mask)
> > + mask = *dev->dma_mask;
> > + else
> > + mask = dev->coherent_dma_mask;
> > +
> > + if (mask == 0)
> > + return 0;
> > +
> > + limit = (mask + 1) & ~mask;
> > + if (limit && size > limit)
> > + return 0;
> > +
> > + if ((addr | (addr + size - 1)) & ~mask)
> > + return 0;
> > +
> > + return 1;
> > +}
> > +
> > +static inline void dma_mark_clean(void *addr, size_t size) { }
> > +
> > /*
> > * DMA errors are defined by all-bits-set in the DMA address.
> > */
> > --
> > 1.7.2.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 v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > > Hi Simon, > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman wrote: > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > > >> Hi Simon, > > >> > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman wrote: > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takas...@ops.dti.ne.jp wrote: > > >> >> Use common clock framework version of clock > > >> >> drivers/clk/shmobile/clk-emev2.c > > >> >> instead of sh-clkfwk version > > >> >> arch/arm/mach-shmobile/clock-emev2.c > > >> >> when it is configured as a part of multi-platform. > > >> >> > > >> >> Signed-off-by: Takashi Yoshii > > >> > > > >> > Thanks. > > >> > > > >> > I plan to add this patch to a new topic branch, > > >> > topic/emev2-common-clock, in the renesas tree and > > >> > queue it up from there for inclusion in mainline > > >> > if/when the first patch of this series is accepted > > >> > by Mike Turquette. > > >> > > >> Thanks for picking up patches, Simon. > > >> > > >> I think you can simply merge this patch after the following series: > > >> > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > > > This is already queued up. > > > > Yes, I know, thanks for that. I tried to explain the dependency in the > > 00/00 cover letter but I will try to be more clear next time! > > > > >> There are no build time dependencies on patch 1 and 2 so this patch > > >> can be merged independently. Regarding run-time operation, the > > >> multiplatform series above makes KZM9D DT reference only build for > > >> multiplatform, and in such case CCF is required. > > >> > > >> So if you want to keep KZM9D DT reference working until Mike Turquette > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > > >> have been merged. > > >> > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > > >> well merge this patch as well IMO. This > > >> multiplatform-update-series-merge-before-CCF plan will result in > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > > >> fine with me. > > > > > > I am mainly concerned that the bindings may change before > > > they are finally merged. And I thought it would be nice to avoid > > > having to fix up the usage of the bindings if they change. > > > > Sure, but the code in this patch looks like it simply starts DT CCF > > probing regardless of what the bindings look like. So I don't think > > you will have to worry about actual bindings detail. > > > > > But I'm happy to just queue-up patches 2 and 3 of this series > > > now if you prefer. > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by > > dependencies. =) > > Thanks, I understand now. > > I'll queue-up 3/3. Which I did. Then some time passed... Mike has accepted my pull-request for patch 1 of this series and accordingly I have queued-up this patch for v3.14. It should appear in the devel branch the next time that I push it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
On Mon, 2013-10-28 at 23:31 -0500, Bhushan Bharat-R65777 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 29, 2013 10:00 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder Stuart-B08248;
> > christoffer.d...@linaro.org; linux-kernel@vger.kernel.org;
> > a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395;
> > peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org;
> > gre...@linuxfoundation.org
> > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via
> > sysfs only
> >
> > On Mon, 2013-10-28 at 22:52 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, October 29, 2013 9:11 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder
> > > > Stuart-B08248; christoffer.d...@linaro.org;
> > > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > gre...@linuxfoundation.org
> > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > > binding via sysfs only
> > > >
> > > > On Mon, 2013-10-28 at 22:38 -0500, Bhushan Bharat-R65777 wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Monday, October 28, 2013 11:40 PM
> > > > > > To: Alex Williamson
> > > > > > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421;
> > > > > > Yoder Stuart-B08248; christoffer.d...@linaro.org;
> > > > > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > > > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > > > gre...@linuxfoundation.org
> > > > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > > > > binding via sysfs only
> > > > > >
> > > > > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote:
> > > > > > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote:
> > > > > > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
> > > > > > > > > Force the vfio-pci driver to only be bound explicitly via
> > > > > > > > > sysfs to avoid conflics with other drivers in the event of a
> > hotplug.
> > > > > > > >
> > > > > > > > We can't break userspace, so we can't disable the current
> > > > > > > > method of binding devices to vfio-pci. We can add a new
> > > > > > > > method and perhaps deprecate the existing mechanism to be
> > > > > > > > removed at some point in the future. Thanks,
> > > > > > >
> > > > > > > I thought the existing method involved using sysfs bind, and
> > > > > > > this was just eliminating a race. How does the bind get triggered
> > currently?
> > > > > >
> > > > > > OK, so it seems it's relying on the write to new_id calling
> > driver_attach().
> > > > > > Sigh. I guess we could make driver-sysfs-bind-only be settable
> > > > > > via sysfs, and have new-userspace set both that and PCI_ANY_ID
> > > > > > (or the specific ID if userspace
> > > > > > prefers) via new_id. The platform bus patches could continue as
> > > > > > is, since there's no existing mechanism to break.
> > > > >
> > > > > What about changing the store_new_id() to bypass exact ids check
> > > > > if driver
> > > > have PCI_ANY_ID?
> > > >
> > > > I don't follow.
> > >
> > > store_new_id() function id defined as:
> > >
> > > static ssize_t store_new_id(struct device_driver *driver, const char
> > > *buf, size_t count) {
> > > struct pci_driver *pdrv = to_pci_driver(driver);
> > > const struct pci_device_id *ids = pdrv->id_table;
> > >
> > >
> > > /* Only accept driver_data values that match an existing id_table
> > >entry */
> > > if (ids) {
> > > retval = -EINVAL;
> > > while (ids->vendor || ids->subvendor || ids->class_mask) {
> > > if (driver_data == ids->driver_data) {
> > > retval = 0;
> > > break;
> > > }
> > > ids++;
> > > }
> > > if (retval) /* No match */
> > > return retval;
> > > }
> > >
> > > retval = pci_add_dynid(pdrv, vendor, device, subvendor, subdevice,
> > >class, class_mask, driver_data);
> > >
> > >
> > > So when ids == NULL it does not check of vendor etc and calls
> > > pci_add_dynid()
> > which in turn calls driver_attach().
> > >
> > > If we change the above loop to break if ids->vendor == PCI_ANY_ID && ids-
> > >subvendor == PCI_ANY_ID then also we will call pci_add_dyids().
> >
> > What problem are you trying to solve?
>
> new_id interface to continue working as
Re: [PATCH v2] ARM: SMMU: add devices attached to the SMMU to an IOMMU group
On Mon, Oct 28, 2013 at 04:44:22PM +, Alex Williamson wrote: > On Fri, 2013-10-18 at 17:08 +0200, Antonios Motakis wrote: > > IOMMU groups are expected by certain users of the IOMMU API, > > e.g. VFIO. Add new devices found by the SMMU driver to an IOMMU > > group to satisfy those users. > > > > Changes from v1: > > * Added check that dev->archdata.iommu has not been set already by an IOMMU > >driver. This way we can also skip checking for an existing IOMMU group. > > > > Signed-off-by: Antonios Motakis > > > Looks ok to me. > > Acked-by: Alex Williamson Yup, looks fine to me too. I'm travelling until next week, so I'll start picking things up then. Cheers, Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of "perf: Add a new sort order: SORT_INCLUSIVE"
On 10/28/13 8:11 PM, Namhyung Kim wrote: Hey Namhyung: Also, what's the reasoning for --cumulate not being an option under perf record -g ..,? Sorry, I cannot understand you. The 'perf record' just saves sample data (and callchains) from the ring-buffer. All the processing happens in 'perf report'. I can't see what you expect from the 'perf record --cumulate'. Am I missing something? Yes - I meant to say perf report -g :) > -g [type,min[,limit],order] Specifically, along with callee, caller, we could have a third option. Or we could have a new type (graph, fractal, cumulative). Given that there are clear use cases in production involving complex callgraphs, I'm for getting this support in first and then reconciling the differences with perf record -b later. I think what Frederic said is that the code de-duplication of 'perf report' side. The branch stack and --cumulate are different - branch stack concentrates on the branch itself but --cumulate uses callchains to find parents and give some credit to them as side information. Me too. I brought it up with Stephane at some point in the last year or so and there wasn't an obvious way to de-duplicate because of these differences. -Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 29, 2013 10:00 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder Stuart-B08248;
> christoffer.d...@linaro.org; linux-kernel@vger.kernel.org;
> a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395;
> peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via
> sysfs only
>
> On Mon, 2013-10-28 at 22:52 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, October 29, 2013 9:11 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder
> > > Stuart-B08248; christoffer.d...@linaro.org;
> > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > gre...@linuxfoundation.org
> > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > binding via sysfs only
> > >
> > > On Mon, 2013-10-28 at 22:38 -0500, Bhushan Bharat-R65777 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Monday, October 28, 2013 11:40 PM
> > > > > To: Alex Williamson
> > > > > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421;
> > > > > Yoder Stuart-B08248; christoffer.d...@linaro.org;
> > > > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > > gre...@linuxfoundation.org
> > > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > > > binding via sysfs only
> > > > >
> > > > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote:
> > > > > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote:
> > > > > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
> > > > > > > > Force the vfio-pci driver to only be bound explicitly via
> > > > > > > > sysfs to avoid conflics with other drivers in the event of a
> hotplug.
> > > > > > >
> > > > > > > We can't break userspace, so we can't disable the current
> > > > > > > method of binding devices to vfio-pci. We can add a new
> > > > > > > method and perhaps deprecate the existing mechanism to be
> > > > > > > removed at some point in the future. Thanks,
> > > > > >
> > > > > > I thought the existing method involved using sysfs bind, and
> > > > > > this was just eliminating a race. How does the bind get triggered
> currently?
> > > > >
> > > > > OK, so it seems it's relying on the write to new_id calling
> driver_attach().
> > > > > Sigh. I guess we could make driver-sysfs-bind-only be settable
> > > > > via sysfs, and have new-userspace set both that and PCI_ANY_ID
> > > > > (or the specific ID if userspace
> > > > > prefers) via new_id. The platform bus patches could continue as
> > > > > is, since there's no existing mechanism to break.
> > > >
> > > > What about changing the store_new_id() to bypass exact ids check
> > > > if driver
> > > have PCI_ANY_ID?
> > >
> > > I don't follow.
> >
> > store_new_id() function id defined as:
> >
> > static ssize_t store_new_id(struct device_driver *driver, const char
> > *buf, size_t count) {
> > struct pci_driver *pdrv = to_pci_driver(driver);
> > const struct pci_device_id *ids = pdrv->id_table;
> >
> >
> > /* Only accept driver_data values that match an existing id_table
> >entry */
> > if (ids) {
> > retval = -EINVAL;
> > while (ids->vendor || ids->subvendor || ids->class_mask) {
> > if (driver_data == ids->driver_data) {
> > retval = 0;
> > break;
> > }
> > ids++;
> > }
> > if (retval) /* No match */
> > return retval;
> > }
> >
> > retval = pci_add_dynid(pdrv, vendor, device, subvendor, subdevice,
> >class, class_mask, driver_data);
> >
> >
> > So when ids == NULL it does not check of vendor etc and calls
> > pci_add_dynid()
> which in turn calls driver_attach().
> >
> > If we change the above loop to break if ids->vendor == PCI_ANY_ID && ids-
> >subvendor == PCI_ANY_ID then also we will call pci_add_dyids().
>
> What problem are you trying to solve?
new_id interface to continue working as before.
-Bharat
>
> -Scott
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
On Mon, 2013-10-28 at 22:52 -0500, Bhushan Bharat-R65777 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 29, 2013 9:11 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder Stuart-B08248;
> > christoffer.d...@linaro.org; linux-kernel@vger.kernel.org;
> > a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395;
> > peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org;
> > gre...@linuxfoundation.org
> > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via
> > sysfs only
> >
> > On Mon, 2013-10-28 at 22:38 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Monday, October 28, 2013 11:40 PM
> > > > To: Alex Williamson
> > > > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421; Yoder
> > > > Stuart-B08248; christoffer.d...@linaro.org;
> > > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > > gre...@linuxfoundation.org
> > > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > > binding via sysfs only
> > > >
> > > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote:
> > > > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote:
> > > > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
> > > > > > > Force the vfio-pci driver to only be bound explicitly via
> > > > > > > sysfs to avoid conflics with other drivers in the event of a
> > > > > > > hotplug.
> > > > > >
> > > > > > We can't break userspace, so we can't disable the current method
> > > > > > of binding devices to vfio-pci. We can add a new method and
> > > > > > perhaps deprecate the existing mechanism to be removed at some
> > > > > > point in the future. Thanks,
> > > > >
> > > > > I thought the existing method involved using sysfs bind, and this
> > > > > was just eliminating a race. How does the bind get triggered
> > > > > currently?
> > > >
> > > > OK, so it seems it's relying on the write to new_id calling
> > > > driver_attach().
> > > > Sigh. I guess we could make driver-sysfs-bind-only be settable via
> > > > sysfs, and have new-userspace set both that and PCI_ANY_ID (or the
> > > > specific ID if userspace
> > > > prefers) via new_id. The platform bus patches could continue as is,
> > > > since there's no existing mechanism to break.
> > >
> > > What about changing the store_new_id() to bypass exact ids check if driver
> > have PCI_ANY_ID?
> >
> > I don't follow.
>
> store_new_id() function id defined as:
>
> static ssize_t store_new_id(struct device_driver *driver, const char *buf,
> size_t count)
> {
> struct pci_driver *pdrv = to_pci_driver(driver);
> const struct pci_device_id *ids = pdrv->id_table;
>
>
> /* Only accept driver_data values that match an existing id_table
>entry */
> if (ids) {
> retval = -EINVAL;
> while (ids->vendor || ids->subvendor || ids->class_mask) {
> if (driver_data == ids->driver_data) {
> retval = 0;
> break;
> }
> ids++;
> }
> if (retval) /* No match */
> return retval;
> }
>
> retval = pci_add_dynid(pdrv, vendor, device, subvendor, subdevice,
>class, class_mask, driver_data);
>
>
>
> So when ids == NULL it does not check of vendor etc and calls pci_add_dynid()
> which in turn calls driver_attach().
>
> If we change the above loop to break if ids->vendor == PCI_ANY_ID &&
> ids->subvendor == PCI_ANY_ID then also we will call pci_add_dyids().
What problem are you trying to solve?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else
On Mon, Oct 28, 2013 at 02:07:48PM +, Vince Weaver wrote: > It's also a shame this change apprently didn't hit the linux-kernel list > as far as I can tell. I do my best to try to note all of the perf > ABI-related changes there, but if things like this are going to start > getting merged in architecture trees then things get that much harder > to keep track of. I can CC LKML on ARM perf patches if you think it will help, but all PMU backend patches go via their respective arch trees afaict. > > I don't want to be the `oddball' architecture (at least, not more than I am > > already :), but I do find it tricky to follow the required semantics of perf > > as opposed to `it happens to work this way', especially when so much of it > > is buried in the various arch backends. So if somebody using the thing on > > ARM has (what looks to me like) a valid issue, then I usually try and fix > > it. > > But it was global behavior that was common on all architectures. > > Now any cross-platform tool like PAPI is going to have to have a mess of > #ifdefs around every use of this ioctl, and it will only get worse if > other architectures decide to "fix" the problem too. What would you like me to do to fix this for you? Moving more code out of the backends and into the core will help maintain consistency between architectures, but that's a huge job. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] r8152 bug fixes
From: Hayes Wang Date: Mon, 28 Oct 2013 19:58:09 +0800 > These could fix some driver issues. > > Hayes Wang (5): > net/usb/r8152: fix tx/rx memory overflow > net/usb/r8152: make sure the tx checksum setting is correct > net/usb/r8152: modify the tx flow > net/usb/r8152: fix incorrect type in assignment > net/usb/r8152: code adjust These are not bug fixes, some of them are just cleanups. It is inappropriate to mix real bug fixes and non-bug fixes into a patch series. You must send purely the bug fixes for 'net' tree, and then later the code cleanups and other changes targetting the 'net-next' tree. Also, from patch #5: -Something else That is completely unacceptable. You must say what changes you are making, the above says nothing to me nor the person reading your commit messages in the future. In general, your commit messages are poorly written in that they contain not enough information for the person trying to understand your patches at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] net, datagram: fix the incorrect comment in zerocopy_sg_from_iovec()
From: Zhi Yong Wu Date: Mon, 28 Oct 2013 14:01:49 +0800 > From: Zhi Yong Wu > > Signed-off-by: Zhi Yong Wu Applied to net-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net, iovec: fix the incorrect comment in memcpy_fromiovecend()
From: Zhi Yong Wu Date: Mon, 28 Oct 2013 14:01:50 +0800 > From: Zhi Yong Wu > > Signed-off-by: Zhi Yong Wu Applied to net-next -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] vxlan: silence one build warning
From: Zhi Yong Wu Date: Mon, 28 Oct 2013 14:01:48 +0800 > From: Zhi Yong Wu > > drivers/net/vxlan.c: In function ‘vxlan_sock_add’: > drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in > this function [-Wmaybe-uninitialized] > drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here > LD drivers/net/built-in.o > > Signed-off-by: Zhi Yong Wu Applied to net-next.
Re: [PATCH] net, mc: fix the incorrect comments in two mc-related functions
From: Zhi Yong Wu Date: Mon, 28 Oct 2013 16:15:50 +0800 > From: Zhi Yong Wu > > Signed-off-by: Zhi Yong Wu Applied to net-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] 3.12.0-rcX IPv6 panic
On Mon, Oct 21, 2013 at 06:40:41PM -0500, Bob Tracy wrote: > On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote: > > On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote: > > > Actually, a regression: the 3.11 kernel is rock-solid stable on my > > > Alpha. > > > > > > Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by > > > executing the gogo6.net "gw6c" IPv6 client program. If the networking > > > layer is active, an "Oops" will eventually (within a day) occur regardless > > > of whether I attempt to run "gw6c". 3.12.0-rcX is stable as long as I > > > leave networking completely disabled. The error has persisted up through > > > -rc6. Apologies for not mentioning this earlier, but the state of my > > > PWS-433au has been questionable, and I wanted to make sure I had a > > > legitimate bug sighting. > > > > > > I'll have to transcribe the panic backtrace by hand: nothing makes it > > > into any of the system logs :-(. I *can* recall that every backtrace > > > I've seen thus far has included one of the skb_copy() variants near the > > > top of the list (first or second function). > > > > Try to capture the panic via serial console. Otherwise a picture > > would give us a first hint. Please watch out for lines like > > skb_(over|under)_panic. > > I'll get a screen capture of some kind for you within the next day or > so. > > > gw6c is a tunnel client? Can you post ip -6 tunnel ls? > > Assuming you meant "show [NAME]" (no "ls" option for the tunnel object), > that yields the following with "gw6c" running on a 3.11.0 kernel: > > smirkin:~# ip -6 tunnel show sit1 > sit1: any/ipv6 remote 4056:5874:: local 4500:0:0:4000:4029:: encaplimit 0 > hoplimit 0 tclass 0x00 flowlabel 0x0 (flowinfo 0x) > > I'm running the gw6c client in gateway mode: the Alpha is my IPv6 > gateway/firewall. Update: no significant change for 3.12.0-rc7. Can still reliably panic the system by running "gw6c" to set up the IPv6 tunnel. Here's a hand- transcribed backtrace: I hope it's sufficient... I would have included the stack/register dump, but about half of it had scrolled off the top of the screen. skb_copy_and_csum_bits+0x88/0x380 icmp_glue_bits+0x48/0xce0 __ip_append_data+0x8f4/0xb40 ip_append_data+0xb0/0x130 icmp_glue_bits+0x0/0xe0 icmp_glue_bits+0x0/0xe0 (yes: repeated once) icmp_push_reply+0x6c/0x190 icmp_send+0x3fc/0x4c0 ip_local_deliver_finish+0x20c/0x2e0 ip_rcv_finish+0x1d8/0x3d0 nf_ct_attach+0x32/0x40 ip_rcv_finish_0x148/0x3d0 __netif_receive_skb_core+0x27c/0x890 process_backlog+0xb8/0x1a0 net_rx_action+0xc8/0x210 __do_softirq+0x1a0/0x230 do_softirq+0x5c/0x70 irq_exit+0x68/0x80 handle_irq+0x90/0xf0 miata_srm_device_interrupt+0x30/0x50 do_entInt+0x1cc/0x1f0 __do_fault+0x3e0/0x5e0 ret_from_sys_call+0x0/0x10 entMM+0x9c/0xc0 do_page_fault+0x0/0x500 do_page_fault+0x48/0x500 entMM+0x9c/0xc0 filp_close+0x6c/0xe0 filp_close+0x98/0xe0 filp_close+0x6c/0xe0 filp_close+0x98/0xe0 __close_fd+0xb8/0xe0 Code: 44640003 e4600010 2032 a77de680 b67e0010 47f10410 47ff0411 --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/
[PATCH 04/11 V2] Staging: bcm: Replaces UCHAR with u8 in Adapter.h
This patch replace "UCHAR" with "u8"
in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h | 82 -
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 08bd9fc..26850bf 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -10,13 +10,13 @@
struct bcm_leader {
unsigned short Vcid;
unsigned short PLength;
- UCHAR Status;
- UCHAR Unused[3];
+ u8 Status;
+ u8 Unused[3];
} __packed;
struct bcm_packettosend {
struct bcm_leader Leader;
- UCHAR ucPayload;
+ u8 ucPayload;
} __packed;
struct bcm_control_packet {
@@ -27,7 +27,7 @@ struct bcm_control_packet {
struct bcm_link_request {
struct bcm_leader Leader;
- UCHAR szData[4];
+ u8 szData[4];
} __packed;
#define MAX_IP_RANGE_LENGTH 4
@@ -45,46 +45,46 @@ union bcm_ip_address {
ULONG ulIpv6Mask[MAX_IP_RANGE_LENGTH * 4]; /* Source Ip Mask
Address Range */
};
struct {
- UCHAR ucIpv4Address[MAX_IP_RANGE_LENGTH * IP_LENGTH_OF_ADDRESS];
- UCHAR ucIpv4Mask[MAX_IP_RANGE_LENGTH * IP_LENGTH_OF_ADDRESS];
+ u8 ucIpv4Address[MAX_IP_RANGE_LENGTH * IP_LENGTH_OF_ADDRESS];
+ u8 ucIpv4Mask[MAX_IP_RANGE_LENGTH * IP_LENGTH_OF_ADDRESS];
};
struct {
- UCHAR ucIpv6Address[MAX_IP_RANGE_LENGTH *
IPV6_ADDRESS_SIZEINBYTES];
- UCHAR ucIpv6Mask[MAX_IP_RANGE_LENGTH *
IPV6_ADDRESS_SIZEINBYTES];
+ u8 ucIpv6Address[MAX_IP_RANGE_LENGTH *
IPV6_ADDRESS_SIZEINBYTES];
+ u8 ucIpv6Mask[MAX_IP_RANGE_LENGTH * IPV6_ADDRESS_SIZEINBYTES];
};
};
struct bcm_hdr_suppression_contextinfo {
- UCHAR ucaHdrSuppressionInBuf[MAX_PHS_LENGTHS]; /* Intermediate buffer
to accumulate pkt Header for PHS */
- UCHAR ucaHdrSuppressionOutBuf[MAX_PHS_LENGTHS + PHSI_LEN]; /*
Intermediate buffer containing pkt Header after PHS */
+ u8 ucaHdrSuppressionInBuf[MAX_PHS_LENGTHS]; /* Intermediate buffer to
accumulate pkt Header for PHS */
+ u8 ucaHdrSuppressionOutBuf[MAX_PHS_LENGTHS + PHSI_LEN]; /* Intermediate
buffer containing pkt Header after PHS */
};
struct bcm_classifier_rule {
ULONG ulSFID;
- UCHAR ucReserved[2];
+ u8 ucReserved[2];
B_UINT16uiClassifierRuleIndex;
boolbUsed;
unsigned short usVCID_Value;
B_UINT8 u8ClassifierRulePriority; /* This field detemines the
Classifier Priority */
union bcm_ip_address stSrcIpAddress;
- UCHAR ucIPSourceAddressLength; /* Ip Source Address Length */
+ u8 ucIPSourceAddressLength; /* Ip Source Address Length */
union bcm_ip_address stDestIpAddress;
- UCHAR ucIPDestinationAddressLength; /* Ip Destination Address
Length */
- UCHAR ucIPTypeOfServiceLength; /* Type of service Length */
- UCHAR ucTosLow; /* Tos Low */
- UCHAR ucTosHigh; /* Tos High */
- UCHAR ucTosMask; /* Tos Mask */
-
- UCHAR ucProtocolLength; /* protocol Length */
- UCHAR ucProtocol[MAX_PROTOCOL_LENGTH]; /* protocol Length */
+ u8 ucIPDestinationAddressLength; /* Ip Destination Address Length
*/
+ u8 ucIPTypeOfServiceLength; /* Type of service Length */
+ u8 ucTosLow; /* Tos Low */
+ u8 ucTosHigh; /* Tos High */
+ u8 ucTosMask; /* Tos Mask */
+
+ u8 ucProtocolLength; /* protocol Length */
+ u8 ucProtocol[MAX_PROTOCOL_LENGTH]; /* protocol Length */
unsigned short usSrcPortRangeLo[MAX_PORT_RANGE];
unsigned short usSrcPortRangeHi[MAX_PORT_RANGE];
- UCHAR ucSrcPortRangeLength;
+ u8 ucSrcPortRangeLength;
unsigned short usDestPortRangeLo[MAX_PORT_RANGE];
unsigned short usDestPortRangeHi[MAX_PORT_RANGE];
- UCHAR ucDestPortRangeLength;
+ u8 ucDestPortRangeLength;
boolbProtocolValid;
boolbTOSValid;
@@ -92,22 +92,22 @@ struct bcm_classifier_rule {
boolbSrcIpValid;
/* For IPv6 Addressing */
- UCHAR ucDirection;
+ u8 ucDirection;
boolbIpv6Protocol;
UINT32 u32PHSRuleID;
struct bcm_phs_rule sPhsRule;
- UCHAR u8AssociatedPHSI;
+ u8 u8AssociatedPHSI;
/* Classification fields for ETH CS */
- UCHAR ucEthCSSrcMACLen;
- UCHAR au8EThCSSrcMAC[MAC_ADDRESS_SIZE];
- UCHAR au8EThCSSrcMACMask[MAC_ADDRESS_SIZE];
- UCHAR ucEthCSDestMACLen;
- UCHAR au8EThCSDestMAC[MAC_ADDRESS_SIZE];
[PATCH 00/11 V2] Staging: bcm: Cleanup Adapter.h
These patches fix several issues in Adapter.h Kevin McKinney (11): Staging: bcm: Fix WARNING: space prohibited before semicolon. Staging: bcm: Remove typedef for _U_IP_ADDRESS and call directly. Staging: bcm: Replace USHORT with unsigned short in Adapter.h Staging: bcm: Replaces UCHAR with u8 in Adapter.h Staging: bcm: Replace ULONG with unsigned long or u32 in Adapter.h Staging: bcm: Replace B_UINT16 with u16 in Adapter.h Staging: bcm: Replace B_UINT8 with u8 in Adapter.h Staging: bcm: Replace UINT32 with u32 in Adapter.h Staging: bcm: Replace UINT with unsigned int in Adapter.h Staging: bcm: Replace PVOID with void * in Adapter.h Staging: bcm: Replace LARGE_INTEGER with u64 in Adapter.h drivers/staging/bcm/Adapter.h | 298 - drivers/staging/bcm/Bcmchar.c |2 +- drivers/staging/bcm/CmHost.c |8 +- drivers/staging/bcm/Misc.c|8 +- 4 files changed, 158 insertions(+), 158 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/11 V2] Staging: bcm: Remove typedef for _U_IP_ADDRESS and call directly.
This patch removes typedef for _U_IP_ADDRESS, and
changes the name of the struct to bcm_ip_address. In
addition, any calls to struct "U_IP_ADDRESS" are
changed to call directly.
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 11fd7f1..33b5063 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -35,7 +35,7 @@ struct bcm_link_request {
#define MAX_PROTOCOL_LENGTH 32
#define IPV6_ADDRESS_SIZEINBYTES 0x10
-typedef union _U_IP_ADDRESS {
+union bcm_ip_address {
struct {
ULONG ulIpv4Addr[MAX_IP_RANGE_LENGTH]; /* Source Ip Address
Range */
ULONG ulIpv4Mask[MAX_IP_RANGE_LENGTH]; /* Source Ip Mask
Address Range */
@@ -52,7 +52,7 @@ typedef union _U_IP_ADDRESS {
UCHAR ucIpv6Address[MAX_IP_RANGE_LENGTH *
IPV6_ADDRESS_SIZEINBYTES];
UCHAR ucIpv6Mask[MAX_IP_RANGE_LENGTH *
IPV6_ADDRESS_SIZEINBYTES];
};
-} U_IP_ADDRESS;
+};
struct bcm_hdr_suppression_contextinfo {
UCHAR ucaHdrSuppressionInBuf[MAX_PHS_LENGTHS]; /* Intermediate buffer
to accumulate pkt Header for PHS */
@@ -66,10 +66,10 @@ struct bcm_classifier_rule {
boolbUsed;
USHORT usVCID_Value;
B_UINT8 u8ClassifierRulePriority; /* This field detemines the
Classifier Priority */
- U_IP_ADDRESSstSrcIpAddress;
+ union bcm_ip_address stSrcIpAddress;
UCHAR ucIPSourceAddressLength; /* Ip Source Address Length */
- U_IP_ADDRESSstDestIpAddress;
+ union bcm_ip_address stDestIpAddress;
UCHAR ucIPDestinationAddressLength; /* Ip Destination Address
Length */
UCHAR ucIPTypeOfServiceLength; /* Type of service Length */
UCHAR ucTosLow; /* Tos Low */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/11 V2] Staging: bcm: Replace UINT with unsigned int in Adapter.h
This patch replaces "UINT" with "unsigned
int" in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h | 84 -
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 35f480a..32343e3 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -21,7 +21,7 @@ struct bcm_packettosend {
struct bcm_control_packet {
PVOID ControlBuff;
- UINTControlBuffLen;
+ unsigned int ControlBuffLen;
struct bcm_control_packet *next;
} __packed;
@@ -124,7 +124,7 @@ struct bcm_packet_info {
/* classification extension Rule */
unsigned long ulSFID;
unsigned short usVCID_Value;
- UINTuiThreshold;
+ unsigned intuiThreshold;
/* This field determines the priority of the SF Queues */
u8 u8TrafficPriority;
@@ -134,29 +134,29 @@ struct bcm_packet_info {
u8 u8QueueType; /* BE or rtPS */
- UINTuiMaxBucketSize; /* maximum size of the bucket for the
queue */
- UINTuiCurrentQueueDepthOnTarget;
- UINTuiCurrentBytesOnHost;
- UINTuiCurrentPacketsOnHost;
- UINTuiDroppedCountBytes;
- UINTuiDroppedCountPackets;
- UINTuiSentBytes;
- UINTuiSentPackets;
- UINTuiCurrentDrainRate;
- UINTuiThisPeriodSentBytes;
+ unsigned intuiMaxBucketSize; /* maximum size of the bucket for the
queue */
+ unsigned intuiCurrentQueueDepthOnTarget;
+ unsigned intuiCurrentBytesOnHost;
+ unsigned intuiCurrentPacketsOnHost;
+ unsigned intuiDroppedCountBytes;
+ unsigned intuiDroppedCountPackets;
+ unsigned intuiSentBytes;
+ unsigned intuiSentPackets;
+ unsigned intuiCurrentDrainRate;
+ unsigned intuiThisPeriodSentBytes;
LARGE_INTEGER liDrainCalculated;
- UINTuiCurrentTokenCount;
+ unsigned intuiCurrentTokenCount;
LARGE_INTEGER liLastUpdateTokenAt;
- UINTuiMaxAllowedRate;
- UINTNumOfPacketsSent;
+ unsigned intuiMaxAllowedRate;
+ unsigned intNumOfPacketsSent;
u8 ucDirection;
unsigned short usCID;
struct bcm_mibs_parameters stMibsExtServiceFlowTable;
- UINTuiCurrentRxRate;
- UINTuiThisPeriodRxBytes;
- UINTuiTotalRxBytes;
- UINTuiTotalTxBytes;
- UINTuiPendedLast;
+ unsigned intuiCurrentRxRate;
+ unsigned intuiThisPeriodRxBytes;
+ unsigned intuiTotalRxBytes;
+ unsigned intuiTotalTxBytes;
+ unsigned intuiPendedLast;
u8 ucIpVersion;
union {
@@ -185,7 +185,7 @@ struct bcm_packet_info {
void*pstSFIndication;
struct timeval stLastUpdateTokenAt;
atomic_tuiPerSFTxResourceCount;
- UINTuiMaxLatency;
+ unsigned intuiMaxLatency;
u8 bIPCSSupport;
u8 bEthCSSupport;
};
@@ -208,9 +208,9 @@ struct bcm_targetdsx_buffer {
boolvalid;
};
-typedef int (*FP_FLASH_WRITE)(struct bcm_mini_adapter *, UINT, PVOID);
+typedef int (*FP_FLASH_WRITE)(struct bcm_mini_adapter *, unsigned int, PVOID);
-typedef int (*FP_FLASH_WRITE_STATUS)(struct bcm_mini_adapter *, UINT, PVOID);
+typedef int (*FP_FLASH_WRITE_STATUS)(struct bcm_mini_adapter *, unsigned int,
PVOID);
/*
* Driver adapter data structure
@@ -246,7 +246,7 @@ struct bcm_mini_adapter {
/* to keep track the no of byte received */
unsigned short PrevNumRecvDescs;
unsigned short CurrNumRecvDescs;
- UINTu32TotalDSD;
+ unsigned intu32TotalDSD;
struct bcm_packet_info PackInfo[NO_OF_QUEUES];
struct bcm_classifier_rule astClassifierTable[MAX_CLASSIFIERS];
boolTransferMode;
@@ -271,7 +271,7 @@ struct bcm_mini_adapter {
atomic_tindex_app_read_cntrlpkt;
atomic_tindex_wr_txcntrlpkt;
atomic_tindex_rd_txcntrlpkt;
- UINTindex_datpkt;
+ unsigned intindex_datpkt;
struct semaphorerdmwrmsync;
struct bcm_targetdsx_buffer
astTargetDsxBuffer[MAX_TARGET_DSX_BUFFERS];
@@ -316,14 +316,14 @@ struct bcm_mini_adapter {
struct file *,
unsigned int);
int (*interface_rdm)(PVOID,
- UINT,
+ unsigned int,
PVOID,
int);
int
[PATCH 10/11 V2] Staging: bcm: Replace PVOID with void * in Adapter.h
This patch replaces "PVOID" with "void *"
in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 32343e3..7055b83 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -20,7 +20,7 @@ struct bcm_packettosend {
} __packed;
struct bcm_control_packet {
- PVOID ControlBuff;
+ void *ControlBuff;
unsigned int ControlBuffLen;
struct bcm_control_packet *next;
} __packed;
@@ -208,9 +208,9 @@ struct bcm_targetdsx_buffer {
boolvalid;
};
-typedef int (*FP_FLASH_WRITE)(struct bcm_mini_adapter *, unsigned int, PVOID);
+typedef int (*FP_FLASH_WRITE)(struct bcm_mini_adapter *, unsigned int, void *);
-typedef int (*FP_FLASH_WRITE_STATUS)(struct bcm_mini_adapter *, unsigned int,
PVOID);
+typedef int (*FP_FLASH_WRITE_STATUS)(struct bcm_mini_adapter *, unsigned int,
void *);
/*
* Driver adapter data structure
@@ -308,22 +308,22 @@ struct bcm_mini_adapter {
/* Driver State for LED Blinking */
enum bcm_led_events DriverState;
/* Interface Specific */
- PVOID pvInterfaceAdapter;
- int (*bcm_file_download)(PVOID,
+ void *pvInterfaceAdapter;
+ int (*bcm_file_download)(void *,
struct file *,
unsigned int);
- int (*bcm_file_readback_from_chip)(PVOID,
+ int (*bcm_file_readback_from_chip)(void *,
struct file *,
unsigned int);
- int (*interface_rdm)(PVOID,
+ int (*interface_rdm)(void *,
unsigned int,
- PVOID,
+ void *,
int);
- int (*interface_wrm)(PVOID,
+ int (*interface_wrm)(void *,
unsigned int,
- PVOID,
+ void *,
int);
- int (*interface_transmit)(PVOID, PVOID , unsigned int);
+ int (*interface_transmit)(void *, void *, unsigned int);
boolIdleMode;
boolbDregRequestSentInIdleMode;
boolbTriedToWakeUpFromlowPowerMode;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/11 V2] Staging: bcm: Replace B_UINT8 with u8 in Adapter.h
This patch replaces "B_UINT8" with "u8"
in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 01788d3..f7620ab 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -65,7 +65,7 @@ struct bcm_classifier_rule {
u16 uiClassifierRuleIndex;
boolbUsed;
unsigned short usVCID_Value;
- B_UINT8 u8ClassifierRulePriority; /* This field detemines the
Classifier Priority */
+ u8 u8ClassifierRulePriority; /* This field detemines the
Classifier Priority */
union bcm_ip_address stSrcIpAddress;
u8 ucIPSourceAddressLength; /* Ip Source Address Length */
@@ -126,13 +126,13 @@ struct bcm_packet_info {
unsigned short usVCID_Value;
UINTuiThreshold;
/* This field determines the priority of the SF Queues */
- B_UINT8 u8TrafficPriority;
+ u8 u8TrafficPriority;
boolbValid;
boolbActive;
boolbActivateRequestSent;
- B_UINT8 u8QueueType; /* BE or rtPS */
+ u8 u8QueueType; /* BE or rtPS */
UINTuiMaxBucketSize; /* maximum size of the bucket for the
queue */
UINTuiCurrentQueueDepthOnTarget;
@@ -296,7 +296,7 @@ struct bcm_mini_adapter {
int DDRSetting;
unsigned long ulPowerSaveMode;
spinlock_t txtransmitlock;
- B_UINT8 txtransmit_running;
+ u8 txtransmit_running;
/* Thread for control packet handling */
struct task_struct *control_packet_handler;
/* thread for transmitting packets. */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 29, 2013 9:11 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Alex Williamson; Kim Phillips; Yoder Stuart-B08248;
> christoffer.d...@linaro.org; linux-kernel@vger.kernel.org;
> a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395;
> peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via
> sysfs only
>
> On Mon, 2013-10-28 at 22:38 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Monday, October 28, 2013 11:40 PM
> > > To: Alex Williamson
> > > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421; Yoder
> > > Stuart-B08248; christoffer.d...@linaro.org;
> > > linux-kernel@vger.kernel.org; a.mota...@virtualopensystems.com;
> > > ag...@suse.de; Sethi Varun-B16395; peter.mayd...@linaro.org;
> > > santosh.shu...@linaro.org; k...@vger.kernel.org;
> > > gre...@linuxfoundation.org
> > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit
> > > binding via sysfs only
> > >
> > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote:
> > > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote:
> > > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
> > > > > > Force the vfio-pci driver to only be bound explicitly via
> > > > > > sysfs to avoid conflics with other drivers in the event of a
> > > > > > hotplug.
> > > > >
> > > > > We can't break userspace, so we can't disable the current method
> > > > > of binding devices to vfio-pci. We can add a new method and
> > > > > perhaps deprecate the existing mechanism to be removed at some
> > > > > point in the future. Thanks,
> > > >
> > > > I thought the existing method involved using sysfs bind, and this
> > > > was just eliminating a race. How does the bind get triggered currently?
> > >
> > > OK, so it seems it's relying on the write to new_id calling
> > > driver_attach().
> > > Sigh. I guess we could make driver-sysfs-bind-only be settable via
> > > sysfs, and have new-userspace set both that and PCI_ANY_ID (or the
> > > specific ID if userspace
> > > prefers) via new_id. The platform bus patches could continue as is,
> > > since there's no existing mechanism to break.
> >
> > What about changing the store_new_id() to bypass exact ids check if driver
> have PCI_ANY_ID?
>
> I don't follow.
store_new_id() function id defined as:
static ssize_t store_new_id(struct device_driver *driver, const char *buf,
size_t count)
{
struct pci_driver *pdrv = to_pci_driver(driver);
const struct pci_device_id *ids = pdrv->id_table;
/* Only accept driver_data values that match an existing id_table
entry */
if (ids) {
retval = -EINVAL;
while (ids->vendor || ids->subvendor || ids->class_mask) {
if (driver_data == ids->driver_data) {
retval = 0;
break;
}
ids++;
}
if (retval) /* No match */
return retval;
}
retval = pci_add_dynid(pdrv, vendor, device, subvendor, subdevice,
class, class_mask, driver_data);
So when ids == NULL it does not check of vendor etc and calls pci_add_dynid()
which in turn calls driver_attach().
If we change the above loop to break if ids->vendor == PCI_ANY_ID &&
ids->subvendor == PCI_ANY_ID then also we will call pci_add_dyids().
-Bharat
>
> -Scott
>
[PATCH 08/11 V2] Staging: bcm: Replace UINT32 with u32 in Adapter.h
This patch replaces "UINT32" with "u32"
in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index f7620ab..35f480a 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -94,7 +94,7 @@ struct bcm_classifier_rule {
/* For IPv6 Addressing */
u8 ucDirection;
boolbIpv6Protocol;
- UINT32 u32PHSRuleID;
+ u32 u32PHSRuleID;
struct bcm_phs_rule sPhsRule;
u8 u8AssociatedPHSI;
@@ -340,11 +340,11 @@ struct bcm_mini_adapter {
boolAutoFirmDld;
boolbMipsConfig;
boolbDPLLConfig;
- UINT32 aTxPktSizeHist[MIBS_MAX_HIST_ENTRIES];
- UINT32 aRxPktSizeHist[MIBS_MAX_HIST_ENTRIES];
+ u32 aTxPktSizeHist[MIBS_MAX_HIST_ENTRIES];
+ u32 aRxPktSizeHist[MIBS_MAX_HIST_ENTRIES];
struct bcm_fragmented_packet_info
astFragmentedPktClassifierTable[MAX_FRAGMENTEDIP_CLASSIFICATION_ENTRIES];
atomic_tuiMBupdate;
- UINT32 PmuMode;
+ u32 PmuMode;
enum bcm_nvm_type eNVMType;
UINTuiSectorSize;
UINTuiSectorSizeInCFG;
@@ -388,7 +388,7 @@ struct bcm_mini_adapter {
boolbDoSuspend;
UINTsyscfgBefFwDld;
boolStopAllXaction;
- UINT32 liTimeSinceLastNetEntry; /* Used to Support
extended CAPI requirements from */
+ u32 liTimeSinceLastNetEntry; /* Used to Support
extended CAPI requirements from */
struct semaphoreLowPowerModeSync;
unsigned long liDrainCalculated;
UINTgpioBitMap;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/11 V2] Staging: bcm: Replace B_UINT16 with u16 in Adapter.h
This patch replaces "B_UINT16" with "u16"
in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index a5dab86..01788d3 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -62,7 +62,7 @@ struct bcm_hdr_suppression_contextinfo {
struct bcm_classifier_rule {
unsigned long ulSFID;
u8 ucReserved[2];
- B_UINT16uiClassifierRuleIndex;
+ u16 uiClassifierRuleIndex;
boolbUsed;
unsigned short usVCID_Value;
B_UINT8 u8ClassifierRulePriority; /* This field detemines the
Classifier Priority */
@@ -204,7 +204,7 @@ struct bcm_tarang_data {
struct bcm_targetdsx_buffer {
unsigned long ulTargetDsxBuffer;
- B_UINT16tid;
+ u16 tid;
boolvalid;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11 V2] Staging: bcm: Replace LARGE_INTEGER with u64 in Adapter.h
This patch replaces "LARGE_INTEGER" with "u64"
in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 7055b83..c373bc0 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -144,9 +144,9 @@ struct bcm_packet_info {
unsigned intuiSentPackets;
unsigned intuiCurrentDrainRate;
unsigned intuiThisPeriodSentBytes;
- LARGE_INTEGER liDrainCalculated;
+ u64 liDrainCalculated;
unsigned intuiCurrentTokenCount;
- LARGE_INTEGER liLastUpdateTokenAt;
+ u64 liLastUpdateTokenAt;
unsigned intuiMaxAllowedRate;
unsigned intNumOfPacketsSent;
u8 ucDirection;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/11 V2] Staging: bcm: Replace ULONG with unsigned long or u32 in Adapter.h
This patch replaces "ULONG" with "unsigned
long", or "u32" for ipv4 addresses, in
Adapter.h. For ipv4 addresses, all
formating is change to match u32 definition.
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h | 42 -
drivers/staging/bcm/Bcmchar.c |2 +-
drivers/staging/bcm/CmHost.c |8
drivers/staging/bcm/Misc.c|8
4 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 26850bf..a5dab86 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -37,12 +37,12 @@ struct bcm_link_request {
union bcm_ip_address {
struct {
- ULONG ulIpv4Addr[MAX_IP_RANGE_LENGTH]; /* Source Ip Address
Range */
- ULONG ulIpv4Mask[MAX_IP_RANGE_LENGTH]; /* Source Ip Mask
Address Range */
+ u32 ulIpv4Addr[MAX_IP_RANGE_LENGTH]; /* Source Ip Address Range
*/
+ u32 ulIpv4Mask[MAX_IP_RANGE_LENGTH]; /* Source Ip Mask Address
Range */
};
struct {
- ULONG ulIpv6Addr[MAX_IP_RANGE_LENGTH * 4]; /* Source Ip Address
Range */
- ULONG ulIpv6Mask[MAX_IP_RANGE_LENGTH * 4]; /* Source Ip Mask
Address Range */
+ unsigned long ulIpv6Addr[MAX_IP_RANGE_LENGTH * 4]; /* Source Ip
Address Range */
+ unsigned long ulIpv6Mask[MAX_IP_RANGE_LENGTH * 4]; /* Source Ip
Mask Address Range */
};
struct {
u8 ucIpv4Address[MAX_IP_RANGE_LENGTH * IP_LENGTH_OF_ADDRESS];
@@ -60,7 +60,7 @@ struct bcm_hdr_suppression_contextinfo {
};
struct bcm_classifier_rule {
- ULONG ulSFID;
+ unsigned long ulSFID;
u8 ucReserved[2];
B_UINT16uiClassifierRuleIndex;
boolbUsed;
@@ -114,7 +114,7 @@ struct bcm_classifier_rule {
struct bcm_fragmented_packet_info {
boolbUsed;
- ULONG ulSrcIpAddress;
+ unsigned long ulSrcIpAddress;
unsigned short usIpIdentification;
struct bcm_classifier_rule *pstMatchedClassifierEntry;
boolbOutOfOrderFragment;
@@ -122,7 +122,7 @@ struct bcm_fragmented_packet_info {
struct bcm_packet_info {
/* classification extension Rule */
- ULONG ulSFID;
+ unsigned long ulSFID;
unsigned short usVCID_Value;
UINTuiThreshold;
/* This field determines the priority of the SF Queues */
@@ -199,11 +199,11 @@ struct bcm_tarang_data {
boolMacTracingEnabled;
boolbApplicationToExit;
struct bcm_mibs_dropped_cntrl_msg stDroppedAppCntrlMsgs;
- ULONG RxCntrlMsgBitMask;
+ unsigned long RxCntrlMsgBitMask;
};
struct bcm_targetdsx_buffer {
- ULONG ulTargetDsxBuffer;
+ unsigned long ulTargetDsxBuffer;
B_UINT16tid;
boolvalid;
};
@@ -253,8 +253,8 @@ struct bcm_mini_adapter {
/*** qos **/
boolbETHCSEnabled;
- ULONG BEBucketSize;
- ULONG rtPSBucketSize;
+ unsigned long BEBucketSize;
+ unsigned long rtPSBucketSize;
u8 LinkStatus;
boolAutoLinkUp;
boolAutoSyncup;
@@ -275,9 +275,9 @@ struct bcm_mini_adapter {
struct semaphorerdmwrmsync;
struct bcm_targetdsx_buffer
astTargetDsxBuffer[MAX_TARGET_DSX_BUFFERS];
- ULONG ulFreeTargetBufferCnt;
- ULONG ulCurrentTargetBuffer;
- ULONG ulTotalTargetBuffersAvailable;
+ unsigned long ulFreeTargetBufferCnt;
+ unsigned long ulCurrentTargetBuffer;
+ unsigned long ulTotalTargetBuffersAvailable;
unsigned long chip_id;
wait_queue_head_t lowpower_mode_wait_queue;
boolbFlashBoot;
@@ -294,7 +294,7 @@ struct bcm_mini_adapter {
boolbIsAutoCorrectEnabled;
boolbDDRInitDone;
int DDRSetting;
- ULONG ulPowerSaveMode;
+ unsigned long ulPowerSaveMode;
spinlock_t txtransmitlock;
B_UINT8 txtransmit_running;
/* Thread for control packet handling */
@@ -356,9 +356,9 @@ struct bcm_mini_adapter {
* Generally it is Active DSD but in case of NVM RD/WR it might be
different.
*/
UINTulFlashCalStart;
- ULONG ulFlashControlSectionStart;
- ULONG ulFlashWriteSize;
- ULONG
[PATCH 01/11 V2] Staging: bcm: Fix WARNING: space prohibited before semicolon.
This patch removes a space before semicolon as
specified by checkpatch.pl.
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index d6c9630..11fd7f1 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -267,7 +267,7 @@ struct bcm_mini_adapter {
boolfw_download_done;
char*txctlpacket[MAX_CNTRL_PKTS];
- atomic_tcntrlpktCnt ;
+ atomic_tcntrlpktCnt;
atomic_tindex_app_read_cntrlpkt;
atomic_tindex_wr_txcntrlpkt;
atomic_tindex_rd_txcntrlpkt;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/11 V2] Staging: bcm: Replace USHORT with unsigned short in Adapter.h
This patch replaces "USHORT" with "unsigned
short" in Adapter.h
Signed-off-by: Kevin McKinney
---
drivers/staging/bcm/Adapter.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/bcm/Adapter.h b/drivers/staging/bcm/Adapter.h
index 33b5063..08bd9fc 100644
--- a/drivers/staging/bcm/Adapter.h
+++ b/drivers/staging/bcm/Adapter.h
@@ -8,8 +8,8 @@
#include "Debug.h"
struct bcm_leader {
- USHORT Vcid;
- USHORT PLength;
+ unsigned short Vcid;
+ unsigned short PLength;
UCHAR Status;
UCHAR Unused[3];
} __packed;
@@ -64,7 +64,7 @@ struct bcm_classifier_rule {
UCHAR ucReserved[2];
B_UINT16uiClassifierRuleIndex;
boolbUsed;
- USHORT usVCID_Value;
+ unsigned short usVCID_Value;
B_UINT8 u8ClassifierRulePriority; /* This field detemines the
Classifier Priority */
union bcm_ip_address stSrcIpAddress;
UCHAR ucIPSourceAddressLength; /* Ip Source Address Length */
@@ -78,12 +78,12 @@ struct bcm_classifier_rule {
UCHAR ucProtocolLength; /* protocol Length */
UCHAR ucProtocol[MAX_PROTOCOL_LENGTH]; /* protocol Length */
- USHORT usSrcPortRangeLo[MAX_PORT_RANGE];
- USHORT usSrcPortRangeHi[MAX_PORT_RANGE];
+ unsigned short usSrcPortRangeLo[MAX_PORT_RANGE];
+ unsigned short usSrcPortRangeHi[MAX_PORT_RANGE];
UCHAR ucSrcPortRangeLength;
- USHORT usDestPortRangeLo[MAX_PORT_RANGE];
- USHORT usDestPortRangeHi[MAX_PORT_RANGE];
+ unsigned short usDestPortRangeLo[MAX_PORT_RANGE];
+ unsigned short usDestPortRangeHi[MAX_PORT_RANGE];
UCHAR ucDestPortRangeLength;
boolbProtocolValid;
@@ -108,14 +108,14 @@ struct bcm_classifier_rule {
UCHAR ucEtherTypeLen;
UCHAR au8EthCSEtherType[NUM_ETHERTYPE_BYTES];
UCHAR usUserPriority[2];
- USHORT usVLANID;
- USHORT usValidityBitMap;
+ unsigned short usVLANID;
+ unsigned short usValidityBitMap;
};
struct bcm_fragmented_packet_info {
boolbUsed;
ULONG ulSrcIpAddress;
- USHORT usIpIdentification;
+ unsigned short usIpIdentification;
struct bcm_classifier_rule *pstMatchedClassifierEntry;
boolbOutOfOrderFragment;
};
@@ -123,7 +123,7 @@ struct bcm_fragmented_packet_info {
struct bcm_packet_info {
/* classification extension Rule */
ULONG ulSFID;
- USHORT usVCID_Value;
+ unsigned short usVCID_Value;
UINTuiThreshold;
/* This field determines the priority of the SF Queues */
B_UINT8 u8TrafficPriority;
@@ -150,7 +150,7 @@ struct bcm_packet_info {
UINTuiMaxAllowedRate;
UINTNumOfPacketsSent;
UCHAR ucDirection;
- USHORT usCID;
+ unsigned short usCID;
struct bcm_mibs_parameters stMibsExtServiceFlowTable;
UINTuiCurrentRxRate;
UINTuiThisPeriodRxBytes;
@@ -244,8 +244,8 @@ struct bcm_mini_adapter {
/* this to keep track of the Tx and Rx MailBox Registers. */
atomic_tCurrNumFreeTxDesc;
/* to keep track the no of byte received */
- USHORT PrevNumRecvDescs;
- USHORT CurrNumRecvDescs;
+ unsigned short PrevNumRecvDescs;
+ unsigned short CurrNumRecvDescs;
UINTu32TotalDSD;
struct bcm_packet_info PackInfo[NO_OF_QUEUES];
struct bcm_classifier_rule astClassifierTable[MAX_CLASSIFIERS];
@@ -284,7 +284,7 @@ struct bcm_mini_adapter {
boolbBinDownloaded;
boolbCfgDownloaded;
boolbSyncUpRequestSent;
- USHORT usBestEffortQueueIndex;
+ unsigned short usBestEffortQueueIndex;
wait_queue_head_t ioctl_fw_dnld_wait_queue;
boolwaiting_to_fw_download_done;
pid_t fw_download_process_pid;
@@ -400,7 +400,7 @@ struct bcm_mini_adapter {
struct bcm_eth_header {
UCHAR au8DestinationAddress[6];
UCHAR au8SourceAddress[6];
- USHORT u16Etype;
+ unsigned short u16Etype;
} __packed;
struct bcm_firmware_info {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: remove minor dead code
This removes a test whether the 'desc' variable is NULL.
This possibility has already been eliminated by the
below test earlier in the loop:
if (desc == NULL) {
dev_warn(pctldev->dev,
"could not get pin desc for pin %d\n",
pins[i]);
continue;
}
Found with Coverity: CID #1090078
Signed-off-by: Michael Opdenacker
---
drivers/pinctrl/pinmux.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 9d144a2..9248ce4 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -505,16 +505,14 @@ void pinmux_disable_setting(struct pinctrl_setting const
*setting)
pin_free(pctldev, pins[i], NULL);
} else {
const char *gname;
- const char *pname;
- pname = desc ? desc->name : "non-existing";
gname = pctlops->get_group_name(pctldev,
setting->data.mux.group);
dev_warn(pctldev->dev,
"not freeing pin %d (%s) as part of "
"deactivating group %s - it is already "
"used for some other setting",
-pins[i], pname, gname);
+pins[i], desc->name, gname);
}
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vexpress: remove declaration of vexpress_clk_of_init()
After commit:6e973d2c(clk: vexpress: Add separate SP810 driver), vexpress_clk_of_init() is unnecessary and removed, so kill it. Signed-off-by: Kefeng Wang --- include/linux/vexpress.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h index 617c01b..0e65172 100644 --- a/include/linux/vexpress.h +++ b/include/linux/vexpress.h @@ -122,6 +122,5 @@ struct clk *vexpress_osc_setup(struct device *dev); void vexpress_osc_of_setup(struct device_node *node); void vexpress_clk_init(void __iomem *sp810_base); -void vexpress_clk_of_init(void); #endif -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCHv5 4/4] Documentation: Add device tree bindings for Freescale FTM PWM.
> > This adds the Document for Freescale FTM PWM driver under > > Documentation/devicetree/bindings/pwm/. > > > > Signed-off-by: Xiubo Li > > --- > > .../devicetree/bindings/pwm/pwm-fsl-ftm.txt| 34 > ++ > > 1 file changed, 34 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt > > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt > > b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt > > new file mode 100644 > > index 000..175b762 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt > > @@ -0,0 +1,34 @@ > > +Freescale FTM PWM controller > > What does FTM stand for, and can we spell out PWM at least once early on. > "FTM" is for short of "FlexTimer Module", I'll use the full name then. > > + > > +Required properties: > > +- compatible: Should be "fsl,vf610-ftm-pwm" > > +- reg: Physical base address and length of the controller's registers > > +- #pwm-cells: Should be 3. See pwm.txt in this directory for a > > +description of > > + the cells format. > > +- clock-names : Includes the following module clock source entries: > > +"ftm0" (system clock), > > +"ftm0_fix_sel" (fixed frequency clock), > > +"ftm0_ext_sel" (external clock) > > +- clocks : Must contain a clock specifier for each entry in > > +clock-names, > > + See ../clock/clock-bindings.txt for details of the property values. > > +- fsl,pwm-counter-clk: The FTM PWM counter clock source, should be > > +one of the > > + entries in clock-names. > > Why do we need this, why not just have only the clock-names/clocks > reference the clk that is actually used? > As I have replied before, the FTM has two clock sources: the module clock and the counter clock. The counter clock source is selectable depends on different board and also the hardware design: + * FTM source clock is selectable * Source clock can be the system clock, the fixed frequency clock, or an external clock * Fixed frequency clock is an additional clock input to allow the selection of an on chip clock source other than the system clock * Selecting external clock connects FTM clock to a chip level input pin therefore allowing to synchronize the FTM counter with an off chip clock source - >From the above description we can see that the external clock source can allow >to synchronize the FTM counter with an off chip clock source. As the chip spec permits the counter clock source be selectable, so the different board maybe has different implementation, if the driver do not support, this will be a bug. > > +- pinctrl-names: must contain a "default" entry. > > +- pinctrl-NNN: One property must exist for each entry in pinctrl-names. > > + See ../pinctrl/pinctrl-bindings.txt for details of the property > values. > > let's drop the .. when making directory references. > Is absolute path " Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt " or just "pinctrl/pinctrl-bindings.txt " ? -- Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
On Mon, 2013-10-28 at 22:38 -0500, Bhushan Bharat-R65777 wrote: > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Monday, October 28, 2013 11:40 PM > > To: Alex Williamson > > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421; Yoder > > Stuart-B08248; > > christoffer.d...@linaro.org; linux-kernel@vger.kernel.org; > > a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395; > > peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org; > > gre...@linuxfoundation.org > > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via > > sysfs only > > > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote: > > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote: > > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote: > > > > > Force the vfio-pci driver to only be bound explicitly via sysfs to > > > > > avoid conflics with other drivers in the event of a hotplug. > > > > > > > > We can't break userspace, so we can't disable the current method of > > > > binding devices to vfio-pci. We can add a new method and perhaps > > > > deprecate the existing mechanism to be removed at some point in the > > > > future. Thanks, > > > > > > I thought the existing method involved using sysfs bind, and this was > > > just eliminating a race. How does the bind get triggered currently? > > > > OK, so it seems it's relying on the write to new_id calling driver_attach(). > > Sigh. I guess we could make driver-sysfs-bind-only be settable via sysfs, > > and > > have new-userspace set both that and PCI_ANY_ID (or the specific ID if > > userspace > > prefers) via new_id. The platform bus patches could continue as is, since > > there's no existing mechanism to break. > > What about changing the store_new_id() to bypass exact ids check if driver > have PCI_ANY_ID? I don't follow. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via sysfs only
> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, October 28, 2013 11:40 PM > To: Alex Williamson > Cc: Kim Phillips; Bhushan Bharat-R65777; Wood Scott-B07421; Yoder > Stuart-B08248; > christoffer.d...@linaro.org; linux-kernel@vger.kernel.org; > a.mota...@virtualopensystems.com; ag...@suse.de; Sethi Varun-B16395; > peter.mayd...@linaro.org; santosh.shu...@linaro.org; k...@vger.kernel.org; > gre...@linuxfoundation.org > Subject: Re: [PATCH 3/4] VFIO: pci: amend vfio-pci for explicit binding via > sysfs only > > On Mon, 2013-10-28 at 13:00 -0500, Scott Wood wrote: > > On Mon, 2013-10-28 at 11:47 -0600, Alex Williamson wrote: > > > On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote: > > > > Force the vfio-pci driver to only be bound explicitly via sysfs to > > > > avoid conflics with other drivers in the event of a hotplug. > > > > > > We can't break userspace, so we can't disable the current method of > > > binding devices to vfio-pci. We can add a new method and perhaps > > > deprecate the existing mechanism to be removed at some point in the > > > future. Thanks, > > > > I thought the existing method involved using sysfs bind, and this was > > just eliminating a race. How does the bind get triggered currently? > > OK, so it seems it's relying on the write to new_id calling driver_attach(). > Sigh. I guess we could make driver-sysfs-bind-only be settable via sysfs, and > have new-userspace set both that and PCI_ANY_ID (or the specific ID if > userspace > prefers) via new_id. The platform bus patches could continue as is, since > there's no existing mechanism to break. What about changing the store_new_id() to bypass exact ids check if driver have PCI_ANY_ID? -Bharat > > -Scott >
Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group
Hi Peter,
On 10/28/2013 07:20 PM, Peter Zijlstra wrote:
> On Thu, Oct 24, 2013 at 01:37:38PM +0530, Preeti U Murthy wrote:
>> kernel/sched/core.c |5 +
>> kernel/sched/fair.c | 38 --
>> kernel/sched/sched.h |1 +
>> 3 files changed, 26 insertions(+), 18 deletions(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index c06b8d3..c540392 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -5271,6 +5271,7 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
>> DEFINE_PER_CPU(int, sd_llc_size);
>> DEFINE_PER_CPU(int, sd_llc_id);
>> DEFINE_PER_CPU(struct sched_domain *, sd_numa);
>> +DEFINE_PER_CPU(struct sched_domain *, sd_busy);
>>
>> static void update_top_cache_domain(int cpu)
>> {
>> @@ -5290,6 +5291,10 @@ static void update_top_cache_domain(int cpu)
>>
>> sd = lowest_flag_domain(cpu, SD_NUMA);
>> rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
>> +
>> +sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES);
>> +if (sd)
>> +rcu_assign_pointer(per_cpu(sd_busy, cpu), sd->parent);
>> }
>>
>> /*
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index e9c9549..f66cfd9 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -6515,16 +6515,16 @@ static inline void nohz_balance_exit_idle(int cpu)
>> static inline void set_cpu_sd_state_busy(void)
>> {
>> struct sched_domain *sd;
>> +int cpu = smp_processor_id();
>>
>> rcu_read_lock();
>> +sd = rcu_dereference(per_cpu(sd_busy, cpu));
>>
>> if (!sd || !sd->nohz_idle)
>> goto unlock;
>> sd->nohz_idle = 0;
>>
>> +atomic_inc(>groups->sgp->nr_busy_cpus);
>> unlock:
>> rcu_read_unlock();
>> }
>> @@ -6532,16 +6532,16 @@ unlock:
>> void set_cpu_sd_state_idle(void)
>> {
>> struct sched_domain *sd;
>> +int cpu = smp_processor_id();
>>
>> rcu_read_lock();
>> +sd = rcu_dereference(per_cpu(sd_busy, cpu));
>>
>> if (!sd || sd->nohz_idle)
>> goto unlock;
>> sd->nohz_idle = 1;
>>
>> +atomic_dec(>groups->sgp->nr_busy_cpus);
>> unlock:
>> rcu_read_unlock();
>> }
>
> Oh nice, that gets rid of the multiple atomics, and it nicely splits
> this nohz logic into per topology groups -- now if only we could split
> the rest too :-)
I am sorry, I don't get you here. By the 'rest', do you refer to
nohz_kick_needed() as below? Or am I missing something?
>
>> @@ -6748,6 +6748,8 @@ static inline int nohz_kick_needed(struct rq *rq, int
>> cpu)
>> {
>> unsigned long now = jiffies;
>> struct sched_domain *sd;
>> +struct sched_group_power *sgp;
>> +int nr_busy;
>>
>> if (unlikely(idle_cpu(cpu)))
>> return 0;
>> @@ -6773,22 +6775,22 @@ static inline int nohz_kick_needed(struct rq *rq,
>> int cpu)
>> goto need_kick;
>>
>> rcu_read_lock();
>> +sd = rcu_dereference(per_cpu(sd_busy, cpu));
>>
>> +if (sd) {
>> +sgp = sd->groups->sgp;
>> +nr_busy = atomic_read(>nr_busy_cpus);
>>
>> +if (nr_busy > 1)
>> goto need_kick_unlock;
>> }
>
> OK, so far so good.
>
>> +
>> +sd = highest_flag_domain(cpu, SD_ASYM_PACKING);
>> +
>> +if (sd && (cpumask_first_and(nohz.idle_cpus_mask,
>> + sched_domain_span(sd)) < cpu))
>> +goto need_kick_unlock;
>> +
>> rcu_read_unlock();
>> return 0;
>
> This again is a bit sad; most archs will not have SD_ASYM_PACKING set at
> all; this means that they all will do a complete (and pointless) sched
> domain tree walk here.
There will not be a 'complete' sched domain tree walk right? The
iteration will break at the first level of the sched domain for those
archs which do not have SD_ASYM_PACKING set at all.
But it is true that doing a sched domain tree walk regularly is a bad
idea, might as well update the domain with SD_ASYM_PACKING flag set once
and query this domain when required.
I will send out the patch with sd_asym domain introduced rather than the
above.
Thanks
Regards
Preeti U Murthy
>
> It would be much better to also introduce sd_asym and do the analogous
> thing to the new sd_busy.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [3.11.4] Thunderbolt/PCI unplug oops in pci_pme_list_scan
On Wed, Oct 16, 2013 at 2:21 PM, Bjorn Helgaas wrote:
> On Tue, Oct 15, 2013 at 03:44:52AM +0100, Matthew Garrett wrote:
>> On Mon, Oct 14, 2013 at 05:50:38PM -0600, Bjorn Helgaas wrote:
>> > [+cc Rafael, Mika, Kirill, linux-pci]
>> >
>> > On Mon, Oct 14, 2013 at 4:47 PM, Andreas Noever
>> > wrote:
>> > > When I unplug the Thunderbolt ethernet adapter on my MacBookPro Linux
>> > > crashes a few seconds later. Using
>> > > echo 1 > /sys/bus/pci/devices/:08:00.0/remove
>> > > to remove a bridge two levels above the device triggers the fault
>> > > immediately:
>> >
>> > There have been significant changes in acpiphp related to Thunderbolt
>> > since v3.11.
>>
>> Apple don't expose Thunderbolt via ACPI, so it appears as native PCIe.
>> I'd be surprised if acpiphp makes a difference here.
>
> Yeah, you're right; I wasn't paying attention.
>
> We save a pci_dev pointer in the pci_pme_list, which of course has a
> longer lifetime than the pci_dev itself, but we don't acquire a reference
> on it, so I suspect the pci_dev got released before we got around to
> doing the pci_pme_list_scan().
>
> Andreas, can you try the patch below? It's against v3.12-rc2, but it
> should apply to v3.11, too.
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ad7fc72..8b0a2f3 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1580,6 +1580,7 @@ static void pci_pme_list_scan(struct work_struct *work)
> pci_pme_wakeup(pme_dev->dev, NULL);
> } else {
> list_del(_dev->list);
> + pci_dev_put(pme_dev->dev);
> kfree(pme_dev);
> }
> }
> @@ -1640,7 +1641,7 @@ void pci_pme_active(struct pci_dev *dev, bool enable)
> GFP_KERNEL);
> if (!pme_dev)
> goto out;
> - pme_dev->dev = dev;
> + pme_dev->dev = pci_dev_get(dev);
> mutex_lock(_pme_list_mutex);
> list_add(_dev->list, _pme_list);
> if (list_is_singular(_pme_list))
> @@ -1652,6 +1653,7 @@ void pci_pme_active(struct pci_dev *dev, bool enable)
> list_for_each_entry(pme_dev, _pme_list, list) {
> if (pme_dev->dev == dev) {
> list_del(_dev->list);
> + pci_dev_put(pme_dev->dev);
> kfree(pme_dev);
> break;
> }
The patch above covered up the problem, but is incorrect. The topology is:
08:00.0 PCI bridge to [bus 09-0a] Thunderbolt Upstream Port
09:00.0 PCI bridge to [bus 0a]Thunderbolt Downstream Port
0a:00.0 tg3 NIC
and the sequence leading to the crash is (edited for brevity):
remove_store(08:00.0)
pci_stop_and_remove_bus_device(08:00.0) # Upstream Port
pci_stop_bus_device(08:00.0)
pci_stop_bus_device(09:00.0)# Downstream Port
pci_stop_bus_device(0a:00.0) # tg3 device
pci_stop_dev(0a:00.0)
pci_pme_active(0a:00.0, false)# remove from pci_pme_list
device_del(0a:00.0)
device_release_driver
tg3_remove_one
unregister_netdev
dev->netdev_ops->ndo_stop # tg3_close
tg3_close
pci_wake_from_d3
pci_pme_active(dev, true) # add to pci_pme_list
pci_remove_bus_device(08:00.0)
pci_remove_bus_device(09:00.0)
pci_remove_bus_device(0a:00.0)
pci_destroy_dev(0a:00.0)
put_device(0a:00.0) # drop last tg3
pci_dev reference
...
pci_release_dev # pci_dev release function
kfree(0a:00.0)
...
pci_pme_list_scan
0a:00.0 still on list => use-after-free
The patch above avoids the crash by acquiring a reference when adding
to pci_pme_list, so when pci_destroy_dev() drops the reference, it's
not the *last* reference, so the pci_dev is not released.
The problem is that the reference acquired when we add to pci_pme_list
will *never* be dropped, so we leaked the pci_dev.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: "Du, Changbin"
In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
be called which calls free_netdev(net). Thus usbnet structure(alloced
with net_device structure) will be freed,too.
So we cannot call usbnet_link_change() if cdc_ncm_bind_common() return
error.
BUG: unable to handle kernel NULL pointer dereference at 0078
EIP is at usbnet_link_change+0x1e/0x80
Call Trace:
[] cdc_ncm_bind+0x3a/0x50
[] usbnet_probe+0x282/0x7d0
[] ? sysfs_new_dirent+0x6c/0x100
[] ? mutex_lock+0x13/0x40
[] cdc_ncm_probe+0x8/0x10
[] usb_probe_interface+0x187/0x2c0
[] ? driver_sysfs_add+0x6a/0x90
[] ? __driver_attach+0x90/0x90
[] driver_probe_device+0x74/0x360
[] ? usb_match_id+0x41/0x60
[] ? usb_device_match+0x4e/0x90
[] ? __driver_attach+0x90/0x90
[] __device_attach+0x39/0x50
[] bus_for_each_drv+0x34/0x70
[] device_attach+0x7b/0x90
[] ? __driver_attach+0x90/0x90
[] bus_probe_device+0x6f/0x90
[] device_add+0x558/0x630
[] ? usb_create_ep_devs+0x71/0xd0
[] ? create_intf_ep_devs+0x4b/0x70
[] usb_set_configuration+0x4bf/0x800
[] ? __driver_attach+0x90/0x90
[] generic_probe+0x2b/0x90
[] usb_probe_device+0x2c/0x70
[] driver_probe_device+0x74/0x360
Signed-off-by: Du, Changbin
---
drivers/net/usb/cdc_ncm.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..af37ecf 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -603,14 +603,15 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
-
- /*
-* We should get an event when network connection is "connected" or
-* "disconnected". Set network connection in "disconnected" state
-* (carrier is OFF) during attach, so the IP network stack does not
-* start IPv6 negotiation and more.
-*/
- usbnet_link_change(dev, 0, 0);
+ if (!ret) {
+ /*
+* We should get an event when network connection is "connected"
+* or "disconnected". Set network connection in "disconnected"
+* state (carrier is OFF) during attach, so the IP network stack
+* does not start IPv6 negotiation and more.
+*/
+ usbnet_link_change(dev, 0, 0);
+ }
return ret;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
(2013/10/29 2:48), Pekka Enberg wrote: > On 10/28/13 7:31 PM, Srikar Dronamraju wrote: But what if a system has both 32 bit libc and 64 bit libc? Wont we could end up with 2 libc:setjmp? Should we give some more intelligence into perf to choose the 64 bit libc over 32 bit one? >>> You can just trace both of them by default, no? >>> >> There has to be a one to one association with the event name and its >> mapping. Every event name will finally map to a unique inode and an >> offset. >> >> One option would be for perf to look at these markers and have a >> different event name for similar markers in different executables. > > I think we are talking past each other here. > > Yes, I understand that you need an fully qualified name > for a SDT marker but there's absolutely no reason to force > feed that to the user of 'perf trace'. > > For the 32-bit and 64-bit libc case, why cannot 'perf list' > by default print out something like: > > $ perf list > >libc:setjmp [SDT marker group] > > and provide a '--fully-qualified' command line option that: > > $ perf list --fully-qualified > > libc:setjmp => libc32:setjmp, libc64:setjmp [SDT marker group] > libc32:setjmp => libc:setjmp@/lib/libc.so.6 [SDT marker] > libc64:setjmp => libc:setjmp@/lib64/libc.so.6 [SDT marker] > > and then teach 'perf trace' to deal with SDT marker groups > where you trace two events, not one? Ah, that's a good idea. :) And it also is needed for another probe event because sometimes inlined functions have multiple instances. I'd like to fold them as one event group. Thank you! -- Masami HIRAMATSU IT Management 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: State of "perf: Add a new sort order: SORT_INCLUSIVE"
Hi Arun, On Mon, 28 Oct 2013 09:43:21 -0700, Arun Sharma wrote: > On 10/28/13 2:29 AM, Rodrigo Campos wrote: >> On Mon, Oct 28, 2013 at 06:09:30PM +0900, Namhyung Kim wrote: >>> On Mon, 28 Oct 2013 08:42:44 +, Rodrigo Campos wrote: On Mon, Oct 28, 2013 at 02:09:49PM +0900, Namhyung Kim wrote: > Anyway, You can find the series and discussion on the link below: > >https://lkml.org/lkml/2012/9/13/81 I've read the cover letter for that series and probably because I don't know about perf internals I have a question: How will "--culumate" interact with "--sort=dso" for example ? I mean, is it possible for that to show more than 100% ? (if you add all the 93.35% in your example in the cover letter, or something similar). Or "--culumate --sort=dso" will just group together all entries that have a dso in the call chain ? >>> >>> Hmm.. I think --cumulate option is only meaningful when sort order >>> includes symbol. Maybe I can add support for --sort=dso case as well >>> but not sure it's worth. Do you think it's really needed? >> >> I don't know if it is *needed*, but that was what I need :) > > I suspect that users will find creative ways of using these options to > solve real world problems and we shouldn't restrict usage any more > than we need to to protect against obvious bugs/crashes. > > Also, what's the reasoning for --cumulate not being an option under > perf record -g ..,? Sorry, I cannot understand you. The 'perf record' just saves sample data (and callchains) from the ring-buffer. All the processing happens in 'perf report'. I can't see what you expect from the 'perf record --cumulate'. Am I missing something? > > In order to integrate perf record -b and --cumulate, we'll have to > sort out the underlying infrastructure for processing callgraphs and > branch stacks. I think the main roadblock here is that one is > statistical and on many CPUs incomplete (only top N branches are > reported). > > Given that there are clear use cases in production involving complex > callgraphs, I'm for getting this support in first and then reconciling > the differences with perf record -b later. I think what Frederic said is that the code de-duplication of 'perf report' side. The branch stack and --cumulate are different - branch stack concentrates on the branch itself but --cumulate uses callchains to find parents and give some credit to them as side information. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] [trivial]doc:alsa: Fix typo in documentation/alsa
Correct spelling typo in documentation/alsa Signed-off-by: Masanari Iida --- Documentation/sound/alsa/ALSA-Configuration.txt | 2 +- Documentation/sound/alsa/Audiophile-Usb.txt | 2 +- Documentation/sound/alsa/CMIPCI.txt | 2 +- Documentation/sound/alsa/compress_offload.txt | 6 +++--- Documentation/sound/alsa/soc/DPCM.txt | 4 ++-- Documentation/sound/alsa/soc/dapm.txt | 4 ++-- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 95731a0..b8dd0df 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -616,7 +616,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. As default, snd-dummy drivers doesn't allocate the real buffers but either ignores read/write or mmap a single dummy page to all -buffer pages, in order to save the resouces. If your apps need +buffer pages, in order to save the resources. If your apps need the read/ written buffer data to be consistent, pass fake_buffer=0 option. diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt index 654dd3b..e7a5ed4 100644 --- a/Documentation/sound/alsa/Audiophile-Usb.txt +++ b/Documentation/sound/alsa/Audiophile-Usb.txt @@ -232,7 +232,7 @@ The parameter can be given: # modprobe snd-usb-audio index=1 device_setup=0x09 * Or while configuring the modules options in your modules configuration file - (tipically a .conf file in /etc/modprobe.d/ directory: + (typically a .conf file in /etc/modprobe.d/ directory: alias snd-card-1 snd-usb-audio options snd-usb-audio index=1 device_setup=0x09 diff --git a/Documentation/sound/alsa/CMIPCI.txt b/Documentation/sound/alsa/CMIPCI.txt index 16935c8..4e36e6e 100644 --- a/Documentation/sound/alsa/CMIPCI.txt +++ b/Documentation/sound/alsa/CMIPCI.txt @@ -87,7 +87,7 @@ with 4 channels, and use the interleaved 4 channel data. -There are some control switchs affecting to the speaker connections: +There are some control switches affecting to the speaker connections: "Line-In Mode" - an enum control to change the behavior of line-in jack. Either "Line-In", "Rear Output" or "Bass Output" can diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index fd74ff2..630c492 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -217,12 +217,12 @@ Not supported: would be enabled with ALSA kcontrols. - Audio policy/resource management. This API does not provide any - hooks to query the utilization of the audio DSP, nor any premption + hooks to query the utilization of the audio DSP, nor any preemption mechanisms. -- No notion of underun/overrun. Since the bytes written are compressed +- No notion of underrun/overrun. Since the bytes written are compressed in nature and data written/read doesn't translate directly to - rendered output in time, this does not deal with underrun/overun and + rendered output in time, this does not deal with underrun/overrun and maybe dealt in user-library Credits: diff --git a/Documentation/sound/alsa/soc/DPCM.txt b/Documentation/sound/alsa/soc/DPCM.txt index aa8546f..0110180 100644 --- a/Documentation/sound/alsa/soc/DPCM.txt +++ b/Documentation/sound/alsa/soc/DPCM.txt @@ -192,7 +192,7 @@ This BE DAI link connects DAI0 to the codec (in this case RT5460 AIF1). It sets the "no_pcm" flag to mark it has a BE and sets flags for supported stream directions using "dpcm_playback" and "dpcm_capture" above. -The BE has also flags set for ignoreing suspend and PM down time. This allows +The BE has also flags set for ignoring suspend and PM down time. This allows the BE to work in a hostless mode where the host CPU is not transferring data like a BT phone call :- @@ -328,7 +328,7 @@ The host can control the hostless link either by :- between both DAIs. 2) Hostless FE. This FE has a virtual connection to the BE DAI links on the DAPM -graph. Control is then carried out by the FE as regualar PCM operations. +graph. Control is then carried out by the FE as regular PCM operations. This method gives more control over the DAI links, but requires much more userspace code to control the link. Its recommended to use CODEC<->CODEC unless your HW needs more fine grained sequencing of the PCM ops. diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt index 7dfd88c..6faab48 100644 --- a/Documentation/sound/alsa/soc/dapm.txt +++ b/Documentation/sound/alsa/soc/dapm.txt @@ -30,7 +30,7 @@ There are 4 power domains within DAPM machine driver and responds to asynchronous events e.g when HP are inserted - 3. Path domain - audio susbsystem
Re: RFC: paravirtualizing perf_clock
On 10/28/13 7:15 AM, Peter Zijlstra wrote: Any suggestions on how to do this and without impacting performance. I noticed the MSR path seems to take about twice as long as the current implementation (which I believe results in rdtsc in the VM for x86 with stable TSC). So assuming all the TSCs are in fact stable; you could implement this by syncing up the guest TSC to the host TSC on guest boot. I don't think anything _should_ rely on the absolute TSC value. Of course you then also need to make sure the host and guest tsc multipliers (cyc2ns) are identical, you can play games with cyc2ns_offset if you're brave. This and the method Gleb mentioned both are going to be complex and fragile -- based assumptions on how the perf_clock timestamps are generated. For example, 489223e assumes you have the tracepoint enabled at VM start with some means of capturing the data (e.g., a perf-session active). In both cases the end result requires piecing together and re-generating the VM's timestamp on the events. For perf this means either modifying the tool to take parameters and an algorithm on how to modify the timestamp or a homegrown tool to regenerate the file with updated timestamps. To back out a bit, my end goal is to be able to create and merge perf-events from any context on a KVM-based host -- guest userspace, guest kernel space, host userspace and host kernel space (userspace events with a perf-clock timestamp is another topic ;-)). Having the events generated with the proper timestamp is the simpler approach than trying to collect various tidbits of data, massage timestamps (and hoping the clock source hasn't changed) and then merge events. And then for the cherry on top a design that works across architectures (e.g., x86 now, but arm later). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 2/3] Support for perf to probe into SDT markers:
(2013/10/29 2:31), Srikar Dronamraju wrote: >>> >>> But what if a system has both 32 bit libc and 64 bit libc? >>> Wont we could end up with 2 libc:setjmp? >>> Should we give some more intelligence into perf to choose the 64 bit >>> libc over 32 bit one? >> >> You can just trace both of them by default, no? >> > > There has to be a one to one association with the event name and its > mapping. Every event name will finally map to a unique inode and an > offset. > > One option would be for perf to look at these markers and have a > different event name for similar markers in different executables. Or, another idea is introducing hidden event group which automatically merges those similar markers and shows as one event alias name. :) Thank you, -- Masami HIRAMATSU IT Management 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/
linux-next: manual merge of the vfs tree with the v9fs tree
Hi Al,
Today's linux-next merge of the vfs tree got conflicts in
fs/9p/vfs_file.c, fs/9p/vfs_inode_dotl.c and fs/9p/vfs_inode.c between
commit 94876b5bb6a8 ("9P: introduction of a new cache=mmap model") from
the v9fs tree and commit 2b052ff59861 ("9p: make v9fs_cache_inode_
{get,put,set}_cookie empty inlines for !9P_CACHEFS") from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/9p/vfs_file.c
index d1ab081f6a4e,a0df3e73c2b1..
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@@ -107,12 -105,8 +107,10 @@@ int v9fs_file_open(struct inode *inode
v9inode->writeback_fid = (void *) fid;
}
mutex_unlock(>v_mutex);
- #ifdef CONFIG_9P_FSCACHE
- if (v9ses->cache)
+ /* previous check would also set cookie with CACHE_LOOSE?
+ * set_cookie does a check if v9inode->fscache anyway... */
+ if (v9ses->cache == CACHE_FSCACHE)
v9fs_cache_inode_set_cookie(inode, file);
- #endif
return 0;
out_error:
p9_client_clunk(file->private_data);
diff --cc fs/9p/vfs_inode.c
index fd077485426b,4e65aa903345..
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@@ -911,10 -901,8 +907,8 @@@ v9fs_vfs_atomic_open(struct inode *dir
goto error;
file->private_data = fid;
- #ifdef CONFIG_9P_FSCACHE
- if (v9ses->cache)
+ if (v9ses->cache == CACHE_LOOSE || v9ses->cache == CACHE_FSCACHE)
v9fs_cache_inode_set_cookie(dentry->d_inode, file);
- #endif
*opened |= FILE_CREATED;
out:
diff --cc fs/9p/vfs_inode_dotl.c
index e68ca293fc9d,4c10edec26a0..
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@@ -356,10 -353,8 +354,8 @@@ v9fs_vfs_atomic_open_dotl(struct inode
if (err)
goto err_clunk_old_fid;
file->private_data = ofid;
- #ifdef CONFIG_9P_FSCACHE
- if (v9ses->cache)
+ if (v9ses->cache == CACHE_LOOSE || v9ses->cache == CACHE_FSCACHE)
v9fs_cache_inode_set_cookie(inode, file);
- #endif
*opened |= FILE_CREATED;
out:
v9fs_put_acl(dacl, pacl);
pgp7NB1iIMqi5.pgp
Description: PGP signature
[PATCH v4] watchdog: w83627hf: Convert to watchdog infrastructure
Signed-off-by: Guenter Roeck
---
v4: Restore 'nowayout' module parameter
The changes cause a trivial conflict with 'watchdog: w83627hf: Auto-detect
IO address and supported chips'. Please let me know if I should re-send
the entire series.
drivers/watchdog/Kconfig|1 +
drivers/watchdog/w83627hf_wdt.c | 218 +--
2 files changed, 50 insertions(+), 169 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d1d53f3..dcaecd0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -868,6 +868,7 @@ config VIA_WDT
config W83627HF_WDT
tristate "W83627HF/W83627DHG Watchdog Timer"
depends on X86
+ select WATCHDOG_CORE
---help---
This is the driver for the hardware watchdog on the W83627HF chipset
as used in Advantech PC-9578 and Tyan S2721-533 motherboards
diff --git a/drivers/watchdog/w83627hf_wdt.c b/drivers/watchdog/w83627hf_wdt.c
index 92f1326..e204c2b 100644
--- a/drivers/watchdog/w83627hf_wdt.c
+++ b/drivers/watchdog/w83627hf_wdt.c
@@ -1,6 +1,9 @@
/*
* w83627hf/thf WDT driver
*
+ * (c) Copyright 2013 Guenter Roeck
+ * converted to watchdog infrastructure
+ *
* (c) Copyright 2007 Vlad Drukker
* added support for W83627THF.
*
@@ -31,31 +34,22 @@
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
#include
-#include
#include
-#include
-
#define WATCHDOG_NAME "w83627hf/thf/hg/dhg WDT"
#define WATCHDOG_TIMEOUT 60/* 60 sec default timeout */
-static unsigned long wdt_is_open;
-static char expect_close;
-static DEFINE_SPINLOCK(io_lock);
-
/* You must set this - there is no sane way to probe for this board. */
static int wdt_io = 0x2E;
module_param(wdt_io, int, 0);
MODULE_PARM_DESC(wdt_io, "w83627hf/thf WDT io port (default 0x2E)");
-static int timeout = WATCHDOG_TIMEOUT; /* in seconds */
+static int timeout;/* in seconds */
module_param(timeout, int, 0);
MODULE_PARM_DESC(timeout,
"Watchdog timeout in seconds. 1 <= timeout <= 255, default="
@@ -110,7 +104,7 @@ static void w83627hf_unselect_wd_register(void)
/* tyan motherboards seem to set F5 to 0x4C ?
* So explicitly init to appropriate value. */
-static void w83627hf_init(void)
+static void w83627hf_init(struct watchdog_device *wdog)
{
unsigned char t;
@@ -120,8 +114,8 @@ static void w83627hf_init(void)
t = inb_p(WDT_EFDR); /* read CRF6 */
if (t != 0) {
pr_info("Watchdog already running. Resetting timeout to %d
sec\n",
- timeout);
- outb_p(timeout, WDT_EFDR);/* Write back to CRF6 */
+ wdog->timeout);
+ outb_p(wdog->timeout, WDT_EFDR);/* Write back to CRF6 */
}
outb_p(0xF5, WDT_EFER); /* Select CRF5 */
@@ -141,10 +135,8 @@ static void w83627hf_init(void)
w83627hf_unselect_wd_register();
}
-static void wdt_set_time(int timeout)
+static int wdt_set_time(unsigned int timeout)
{
- spin_lock(_lock);
-
w83627hf_select_wd_register();
outb_p(0xF6, WDT_EFER);/* Select CRF6 */
@@ -152,34 +144,30 @@ static void wdt_set_time(int timeout)
w83627hf_unselect_wd_register();
- spin_unlock(_lock);
+ return 0;
}
-static int wdt_ping(void)
+static int wdt_start(struct watchdog_device *wdog)
{
- wdt_set_time(timeout);
- return 0;
+ return wdt_set_time(wdog->timeout);
}
-static int wdt_disable(void)
+static int wdt_stop(struct watchdog_device *wdog)
{
- wdt_set_time(0);
- return 0;
+ return wdt_set_time(0);
}
-static int wdt_set_heartbeat(int t)
+static int wdt_set_timeout(struct watchdog_device *wdog, unsigned int timeout)
{
- if (t < 1 || t > 255)
- return -EINVAL;
- timeout = t;
+ wdt_set_time(timeout);
+ wdog->timeout = timeout;
+
return 0;
}
-static int wdt_get_time(void)
+static unsigned int wdt_get_time(struct watchdog_device *wdog)
{
- int timeleft;
-
- spin_lock(_lock);
+ unsigned int timeleft;
w83627hf_select_wd_register();
@@ -188,124 +176,17 @@ static int wdt_get_time(void)
w83627hf_unselect_wd_register();
- spin_unlock(_lock);
-
return timeleft;
}
-static ssize_t wdt_write(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- if (count) {
- if (!nowayout) {
- size_t i;
-
- expect_close = 0;
-
- for (i = 0; i != count; i++) {
- char c;
- if (get_user(c, buf + i))
- return -EFAULT;
- if (c == 'V')
-
Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
> > > > 3. Then I merged the 'efi' branch of > > git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop. > > I used the patches from mailbox directly. > Fixed an conflict and merge them one by one. I remember I tried your efi branch, but the code is different from what you sent to list, thus I turned to use the mbox patches. -- Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
If a macro is only used within 2 times, and also its contents are within 2 lines, recommend to expand it to shrink code line. For our case, the macro is not portable either: some architectures' assembler may use another character to mark newline in a macro (e.g. '`' for arc), which will cause issue (e.g. arc with allmodconfig): LD init/built-in.o kernel/built-in.o: In function `load_module_signing_keys': kernel/modsign_pubkey.c:66: undefined reference to `modsign_certificate_list' kernel/modsign_pubkey.c:71: undefined reference to `modsign_certificate_list_end' kernel/modsign_pubkey.c:67: undefined reference to `modsign_certificate_list_end' If still want to use macro and let it portable enough, it will need additional line -- include additional header file (e.g "#include ", although it also need be fixed). Signed-off-by: Chen Gang --- kernel/modsign_certificate.S | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S index 4a9a86d..1967dcd 100644 --- a/kernel/modsign_certificate.S +++ b/kernel/modsign_certificate.S @@ -1,12 +1,10 @@ #include -#define GLOBAL(name) \ - .globl VMLINUX_SYMBOL(name);\ - VMLINUX_SYMBOL(name): - .section ".init.data","aw" -GLOBAL(modsign_certificate_list) + .globl VMLINUX_SYMBOL(modsign_certificate_list) +VMLINUX_SYMBOL(modsign_certificate_list): .incbin "signing_key.x509" .incbin "extra_certificates" -GLOBAL(modsign_certificate_list_end) + .globl VMLINUX_SYMBOL(modsign_certificate_list_end) +VMLINUX_SYMBOL(modsign_certificate_list_end): -- 1.7.7.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] commit: Add -f, --fixes option to add Fixes: line
On Mon, Oct 28, 2013 at 11:10:13PM +0100, Thomas Rast wrote: > * In your list > > > Fixes: > > Reported-by: > > Suggested-by: > > Improved-by: > > Acked-by: > > Reviewed-by: > > Tested-by: > > Signed-off-by: > > and I might add > > Cherry-picked-from: > Reverts: > > if one were to phrase that as a footer/pseudoheader, observe that > there are only two kinds of these: footers that contain identities, > and footers that contain references to commits. I think people put other things in, too. For example, cross-referencing bug-tracker ids. In fact, if I saw "fixes: XXX", I would expect the latter to be a tracker id. People do this a lot with GitHub issues, because GitHub will auto-close issue 123 if a commit with "fixes #123" is pushed to master. Because of the "#", no pseudo-header is needed, but I have also seen people use the footer style (I don't have any examples on-hand, though). That being said, in your examples: > So why not support these use-cases? We could have something like > footer.foo.* configuration, e.g. > > [footer "fixes"] > type = commit > suggest = true > [footer "acked-by"] > type = identity you could easily have "type=text" to handle arbitrary text. -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] commit: Add -f, --fixes option to add Fixes: line
On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote: > > A hook-based solution could do this. But a built-in "all-purpose" > > handler like "footer.Fixes.arg=commit", which was intended to be > > reusable, wouldn't be able to do such footer-specific extra work without > > having to create new special cases in git each time. > > Which begs the question (posed to all, not specifically to you): Why > would we want solve this issue in config instead of in hooks? The > hooks will always be more flexible and less dependent on making > changes in git.git. (...a suitably flexible hook could even use the > config options discussed above as input...) In both cases, we need the > user to actively enable the functionality (either installing hooks, or > setting up config), and in both cases we could bundle Git with > defaults that solve the common cases, so that is not a useful > differentiator between the two approaches. I would even venture to > ask: If we end up solving this problem in config and not in hooks, > then why do we bother having hooks in the first place? One thing that is much nicer with config vs hooks is that you can manage config for all of your repositories by tweaking ~/.gitconfig (and that is where I would expect this type of config to go). Managing hooks globally means having each repo symlink to a central hook area, and having the forethought to set up the symlink farm and use init.templatedir before cloning any repos. We could probably make this friendlier by reading from ~/.githooks and defining some semantics for multiple hooks. E.g., fall back to ~/.githooks if the repo hook is not executable, or possibly run them both (or even allow multiple instances of a hook in ~/.githooks, which can help organization), and consider the hook a failure if any of them fail. -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: spear: fix return value check in spear_setup_of_timer()
From: Wei Yongjun
In case of error, the function clk_get_sys() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
arch/arm/mach-spear/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
index d449673..3263a34 100644
--- a/arch/arm/mach-spear/time.c
+++ b/arch/arm/mach-spear/time.c
@@ -222,7 +222,7 @@ void __init spear_setup_of_timer(void)
}
gpt_clk = clk_get_sys("gpt0", NULL);
- if (!gpt_clk) {
+ if (IS_ERR(gpt_clk)) {
pr_err("%s:couldn't get clk for gpt\n", __func__);
goto err_iomap;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] befs: fix return value check in befs_iget()
From: Wei Yongjun In case of error, the function iget_locked() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun --- fs/befs/linuxvfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c index e9c75e2..d714dda 100644 --- a/fs/befs/linuxvfs.c +++ b/fs/befs/linuxvfs.c @@ -319,8 +319,8 @@ static struct inode *befs_iget(struct super_block *sb, unsigned long ino) befs_debug(sb, "---> befs_read_inode() " "inode = %lu", ino); inode = iget_locked(sb, ino); - if (IS_ERR(inode)) - return inode; + if (!inode) + return ERR_PTR(-ENOMEM); if (!(inode->i_state & I_NEW)) return inode; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: Support arch_irq_work_raise() via self IPIs
Stephen Boyd writes: > This will allow the scheduler tick to be restarted if we're in > full NOHZ mode. > > Cc: Kevin Hilman > Cc: Frederic Weisbecker > Signed-off-by: Stephen Boyd Minor nit, but I'd prefer a more verbose changelog (I forget things quickly and like to rely on changelogs for my memory.) Probably worth adding something like: "By default, irq_work is tied to the tick processing (update_process_times()) but in full NOHZ mode, no tick means no IRQ work. In order for IRQ work to be done in full NOHZ mode, a self-IPI is used to process IRQ work." Other than the changelog nit, patch looks good, feel free to add Reviewed-by: Kevin Hilman If Russell is OK with this, it can go to his patch system. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch: use ASM_NL instead of ';' for assembler new line character in the macro
For some assemblers, they use another character as newline in a macro
(e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a
macro) instead of ';' for it.
Also need notice about code styles ('\t' for each line).
Signed-off-by: Chen Gang
---
arch/arc/include/asm/linkage.h |2 ++
include/linux/linkage.h| 19 ---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index 0283e9e..66ee552 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -11,6 +11,8 @@
#ifdef __ASSEMBLY__
+#define ASM_NL ` /* use '`' to mark new line in macro */
+
/* Can't use the ENTRY macro in linux/linkage.h
* gas considers ';' as comment vs. newline
*/
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index d3e8ad2..a6a42dd 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -6,6 +6,11 @@
#include
#include
+/* Some toolchains use other characters (e.g. '`') to mark new line in macro */
+#ifndef ASM_NL
+#define ASM_NL ;
+#endif
+
#ifdef __cplusplus
#define CPP_ASMLINKAGE extern "C"
#else
@@ -75,21 +80,21 @@
#ifndef ENTRY
#define ENTRY(name) \
- .globl name; \
- ALIGN; \
- name:
+ .globl name ASM_NL \
+ ALIGN ASM_NL \
+ name:
#endif
#endif /* LINKER_SCRIPT */
#ifndef WEAK
#define WEAK(name)\
- .weak name;\
+ .weak name ASM_NL \
name:
#endif
#ifndef END
#define END(name) \
- .size name, .-name
+ .size name, .-name
#endif
/* If symbol 'name' is treated as a subroutine (gets called, and returns)
@@ -98,8 +103,8 @@
*/
#ifndef ENDPROC
#define ENDPROC(name) \
- .type name, @function; \
- END(name)
+ .type name, @function ASM_NL \
+ END(name)
#endif
#endif
--
1.7.7.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] 9p: unsigned/signed wrap in p9/unix modes.
2013/10/28 Geyslan Gregório Bem
>
> 2013/10/27 Eric Van Hensbergen
>>
>> Looks like the right approach. The one other optional thing I mentioned was
>> support for passing NULL for rdev and not trying to parse the device info
>> when rdev == NULL. Its a very slight optimization in the grand scheme of
>> things, but would seem to be cleaner for the folks calling the function who
>> don't touch rdev after the fact...
>>
>> -eric
>>
> Great. Let me do the changes this afternoon.
>
>
Hi Eric and all.
You requested to avoid the parsing of device when rdev is NULL, all
right? But I'm afraid that that manner the res (return value) can be
returned wrong when the bit mode is a device. Well, I did some
changes. In this new approach, when rdev is NULL, the function only
doesn't make the device, but returns the res (umode_t) nicely.
Tell me if this approach is correct. Do I have to modify something else?
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 94de6d1..e3d56f1 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -63,7 +63,7 @@ static const struct inode_operations
v9fs_symlink_inode_operations;
static u32 unixmode2p9mode(struct v9fs_session_info *v9ses, umode_t mode)
{
-int res;
+u32 res;
res = mode & 0777;
if (S_ISDIR(mode))
res |= P9_DMDIR;
@@ -125,10 +125,9 @@ static int p9mode2perm(struct v9fs_session_info *v9ses,
static umode_t p9mode2unixmode(struct v9fs_session_info *v9ses,
struct p9_wstat *stat, dev_t *rdev)
{
-int res;
+umode_t res;
u32 mode = stat->mode;
-*rdev = 0;
res = p9mode2perm(v9ses, stat);
if ((mode & P9_DMDIR) == P9_DMDIR)
@@ -144,10 +143,15 @@ static umode_t p9mode2unixmode(struct
v9fs_session_info *v9ses,
else if ((mode & P9_DMDEVICE) && (v9fs_proto_dotu(v9ses))
&& (v9ses->nodev == 0)) {
char type = 0, ext[32];
-int major = -1, minor = -1;
+u32 major = 0, minor = 0;
strlcpy(ext, stat->extension, sizeof(ext));
-sscanf(ext, "%c %u %u", , , );
+if (sscanf(ext, "%c %u %u", , , ) < 3) {
+p9_debug(P9_DEBUG_ERROR,
+ "It's necessary define type [%c], major [%u] and minor [%u]" \
+ "values when mode is P9_DMDEVICE\n", type, major, minor);
+goto err_dev;
+}
switch (type) {
case 'c':
res |= S_IFCHR;
@@ -158,11 +162,18 @@ static umode_t p9mode2unixmode(struct
v9fs_session_info *v9ses,
default:
p9_debug(P9_DEBUG_ERROR, "Unknown special type %c %s\n",
type, stat->extension);
-};
-*rdev = MKDEV(major, minor);
+goto err_dev;
+}
+/* Only make device if rdev pointer isn't NULL */
+if (rdev)
+*rdev = MKDEV(major, minor);
} else
res |= S_IFREG;
-
+goto ret;
+err_dev:
+if (rdev)
+rdev = ERR_PTR(-EIO);
+ret:
return res;
}
@@ -460,13 +471,12 @@ void v9fs_evict_inode(struct inode *inode)
static int v9fs_test_inode(struct inode *inode, void *data)
{
-int umode;
-dev_t rdev;
+umode_t umode;
struct v9fs_inode *v9inode = V9FS_I(inode);
struct p9_wstat *st = (struct p9_wstat *)data;
struct v9fs_session_info *v9ses = v9fs_inode2v9ses(inode);
-umode = p9mode2unixmode(v9ses, st, );
+umode = p9mode2unixmode(v9ses, st, NULL);
/* don't match inode of different type */
if ((inode->i_mode & S_IFMT) != (umode & S_IFMT))
return 0;
@@ -526,6 +536,10 @@ static struct inode *v9fs_qid_iget(struct super_block *sb,
*/
inode->i_ino = i_ino;
umode = p9mode2unixmode(v9ses, st, );
+if (IS_ERR_VALUE(rdev)) {
+retval = rdev;
+goto error;
+}
retval = v9fs_init_inode(v9ses, inode, umode, rdev);
if (retval)
goto error;
@@ -1461,8 +1475,7 @@ v9fs_vfs_mknod(struct inode *dir, struct dentry
*dentry, umode_t mode, dev_t rde
int v9fs_refresh_inode(struct p9_fid *fid, struct inode *inode)
{
-int umode;
-dev_t rdev;
+umode_t umode;
loff_t i_size;
struct p9_wstat *st;
struct v9fs_session_info *v9ses;
@@ -1474,7 +1487,7 @@ int v9fs_refresh_inode(struct p9_fid *fid,
struct inode *inode)
/*
* Don't update inode if the file type is different
*/
-umode = p9mode2unixmode(v9ses, st, );
+umode = p9mode2unixmode(v9ses, st, NULL);
if ((inode->i_mode & S_IFMT) != (umode & S_IFMT))
goto out;
--
Regards,
Geyslan G. Bem
hackingbits.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] arch: use ASM_NL instead of ';' for assembler new line character in the macro
On 10/29/2013 09:04 AM, Chen Gang wrote: > On 10/28/2013 09:45 PM, Vineet Gupta wrote: >> On 10/28/2013 04:00 PM, Chen Gang wrote: >>> For some toolchains, they use another character as newline in a macro >>> (e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a >>> macro) instead of ';' for it. >>> >>> Since "linux/export.h" are mainly used for exporting work, then our fix >>> more likely belongs to "linux/linkage.h", and we need add the related >>> checking in "linkage.h". >>> >>> Also need notice 80 columns wrap, and '\t' for each line. >>> >>> >>> Signed-off-by: Chen Gang >>> --- >>> arch/arc/include/asm/linkage.h|2 + >>> include/asm-generic/vmlinux.lds.h | 350 >>> +++-- >>> include/linux/linkage.h | 19 + >> >> Like Max said, please drop the linker script bits - they are OK - otherwise >> ARC >> kernel won't have been building at all. >> > > OK, thank you and Max, I will send patch v2 for it. > > Hmm... after this modification, it passed allmodconfig for x86_64. And > for arc, at least, it can build to "mm/" sub-directory (after here, I > stopped compiling). It seems I should not stopped when build to "mm/" sub-directory -- that will let myself find: "ld and as are really 'individual' enough, although both of them belong binutils". :-) > > >> And you also need to fix kernel/modsign_certificate.S as part of same >> patchset as >> that is where the problem started in first place. >> > > Hmm... can that be another patch? > > For "kernel/modsign_certificate.S", I recommend to expand the macro > which will shrink code line, either need not include additional header > file, I feel that will be simpler for both code reader and writers. > > > Thanks. > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [tpmdd-devel] [PATCH] tpm: MAINTAINERS: Add myself as tpm maintainer
Hey Peter, Yes, a cleanup there is way welcome. Please remove my name indeed, as it doesn't make sense at this point, the lists should suffice. I'll keep looking at the patches and try to review them for sure. Cheers and thanks again for stepping in. On Wed, Oct 23, 2013 at 9:10 PM, Peter Huewe wrote: > Hi Rajiv, >> Long time, no see.. > Good to see you again. > >> Peter, thank you a ton for stepping in. >> Since you're of course the owner (yes, we need such figure), >> let me know if my help is desirable or if you think there isn't >> additional bandwidth needed to maintain it. > > Thanks for the offer - I think I can handle the maintenance effort itself, > HOWEVER I would really like to see you sticking around here as a reviewer, > due to your experience, > especially for the stuff I'm submitting. > > The more reviewers the merrier ;) > > Whether you want to be listed in MAINTAINERS or the subscription to tpmdd is > enough is up to you. > Please tell me what you think, then I'd clean up the MAINTAINERS entry for > the tpm subsystem ;) > > Thanks, > Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] edac: Document Krait L1/L2 EDAC driver binding
On Tue, Oct 29, 2013 at 12:31:28AM +, Stephen Boyd wrote:
> The Krait L1/L2 error reporting device is made up of two
> interrupts, one per-CPU interrupt for the L1 caches and one
> interrupt for the L2 cache.
>
> Cc:
> Signed-off-by: Stephen Boyd
> ---
> .../devicetree/bindings/arm/qcom,krait-cache-erp.txt | 16
>
> 1 file changed, 16 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
> b/Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
> new file mode 100644
> index 000..01fe8a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
> @@ -0,0 +1,16 @@
> +* Qualcomm Krait L1 / L2 cache error reporting
> +
> +Required properties:
> +- compatible: Should be "qcom,krait-cache-erp"
> +- interrupts: Should contain the L1/CPU error interrupt number and
> + then the L2 cache error interrupt number
> +
> +Optional properties:
> +- interrupt-names: Should contain the interrupt names "l1_irq" and
> + "l2_irq"
As with my comment on the parsing code, I'd prefer that if interrupt-names was
present it defined the order of interrupts. Otherwise it's redundant and of no
value.
Otherwise, the binding looks fine to me:
Acked-by: Mark Rutland
> +
> +Example:
> + edac {
> + compatible = "qcom,krait-cache-erp";
> + interrupts = <1 9 0xf04>, <0 2 0x4>;
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
On Tue, Oct 29, 2013 at 12:26:26AM +0100, Sebastian Reichel wrote: > 1. The pin is named PMEN in the Nokia N900 schematics > 2. PMEN is described as "Power management enable - system shutdown" >in a crippled datasheet of the wl1253, which I found in the internet. > I don't think this is supposed to be handled by the regulator API. I agree, this sounds like a GPIO that the driver should be understanding directly to me. signature.asc Description: Digital signature
Re: [PATCH 3/6] ARM: Add Krait L2 accessor functions
On Tue, Oct 29, 2013 at 01:21:57AM +, Stephen Boyd wrote:
> On 10/28/13 18:19, Mark Rutland wrote:
> > On Tue, Oct 29, 2013 at 12:31:27AM +, Stephen Boyd wrote:
> >> Qualcomm's Krait CPUs have a handful of L2 cache controller
> >> registers that live behind a cp15 based indirection register.
> >> First you program the indirection register (l2cpselr) to point
> >> the L2 'window' register (l2cpdr) at what you want to read/write.
> >> Then you read/write the 'window' register to do what you want.
> >> The l2cpselr register is not banked per-cpu so we must lock
> >> around accesses to it to prevent other CPUs from re-pointing
> >> l2cpdr underneath us.
> >>
> >> Cc: Russell King
> >> Signed-off-by: Stephen Boyd
> >> ---
> >> arch/arm/common/Kconfig | 3 ++
> >> arch/arm/common/Makefile | 1 +
> >> arch/arm/common/krait-l2-accessors.c | 52
> >> +++
> >> arch/arm/include/asm/krait-l2-accessors.h | 20
> >> 4 files changed, 76 insertions(+)
> >> create mode 100644 arch/arm/common/krait-l2-accessors.c
> >> create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
> > [...]
> >
> >> +void set_l2_indirect_reg(u32 addr, u32 val)
> >> +{
> >> + unsigned long flags;
> >> +
> >> + raw_spin_lock_irqsave(_l2_lock, flags);
> >> +
> >> + asm volatile ("mcr p15, 3, %0, c15, c0, 6" : : "r" (addr));
> >> + isb();
> >> + asm volatile ("mcr p15, 3, %0, c15, c0, 7" : : "r" (val));
> >> + isb();
> >> +
> >> + raw_spin_unlock_irqrestore(_l2_lock, flags);
> >> +}
> >> +EXPORT_SYMBOL(set_l2_indirect_reg);
> > It might be worth commmenting inline as to what register each of these is
> > accessing. Inevitably the commit message will become harder to find and
> > associate with the code over time.
> >
> > Similarly for get_l2_indirect_reg.
>
> Do you mean with the "@" syntax in the assembly? The 80-character limit
> is out to get me.
I probably didn't mean inline :)
How about a block comment above the first asm block like:
/*
* Select the L2 window by poking l2cpselr, then write to the window via
* l2cpdr.
*/
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/6] edac: Add support for Krait CPU cache error detection
On Tue, Oct 29, 2013 at 12:31:29AM +, Stephen Boyd wrote:
> Add support for the Krait CPU cache error detection. This is a
> simplified version of the code originally written by Stepan
> Moskovchenko[1] ported to the EDAC device framework.
>
> [1]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/mach-msm/cache_erp.c?h=msm-3.4
>
> Cc: Stepan Moskovchenko
> Signed-off-by: Stephen Boyd
> ---
> drivers/edac/Kconfig | 8 ++
> drivers/edac/Makefile | 2 +
> drivers/edac/krait_edac.c | 336
> ++
> 3 files changed, 346 insertions(+)
> create mode 100644 drivers/edac/krait_edac.c
[...]
> +static int krait_edac_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct edac_device_ctl_info *edev;
> + struct krait_edac *p;
> + int l1_irq, l2_irq;
> + int ret;
> + int cpu;
> +
> + l1_irq = platform_get_irq(pdev, 0);
> + if (l1_irq < 0)
> + return l1_irq;
> +
> + l2_irq = platform_get_irq(pdev, 1);
> + if (l2_irq < 0)
> + return l2_irq;
As you have optional interrupt-names, I would prefer that you attempted to
request interrupts by name if interrupt-names is present. Otherwise
interrupt-names brings no value.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Add Krait L2 accessor functions
On 10/28/13 18:19, Mark Rutland wrote:
> On Tue, Oct 29, 2013 at 12:31:27AM +, Stephen Boyd wrote:
>> Qualcomm's Krait CPUs have a handful of L2 cache controller
>> registers that live behind a cp15 based indirection register.
>> First you program the indirection register (l2cpselr) to point
>> the L2 'window' register (l2cpdr) at what you want to read/write.
>> Then you read/write the 'window' register to do what you want.
>> The l2cpselr register is not banked per-cpu so we must lock
>> around accesses to it to prevent other CPUs from re-pointing
>> l2cpdr underneath us.
>>
>> Cc: Russell King
>> Signed-off-by: Stephen Boyd
>> ---
>> arch/arm/common/Kconfig | 3 ++
>> arch/arm/common/Makefile | 1 +
>> arch/arm/common/krait-l2-accessors.c | 52
>> +++
>> arch/arm/include/asm/krait-l2-accessors.h | 20
>> 4 files changed, 76 insertions(+)
>> create mode 100644 arch/arm/common/krait-l2-accessors.c
>> create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
> [...]
>
>> +void set_l2_indirect_reg(u32 addr, u32 val)
>> +{
>> +unsigned long flags;
>> +
>> +raw_spin_lock_irqsave(_l2_lock, flags);
>> +
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 6" : : "r" (addr));
>> +isb();
>> +asm volatile ("mcr p15, 3, %0, c15, c0, 7" : : "r" (val));
>> +isb();
>> +
>> +raw_spin_unlock_irqrestore(_l2_lock, flags);
>> +}
>> +EXPORT_SYMBOL(set_l2_indirect_reg);
> It might be worth commmenting inline as to what register each of these is
> accessing. Inevitably the commit message will become harder to find and
> associate with the code over time.
>
> Similarly for get_l2_indirect_reg.
Do you mean with the "@" syntax in the assembly? The 80-character limit
is out to get me.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Add Krait L2 accessor functions
On Tue, Oct 29, 2013 at 12:31:27AM +, Stephen Boyd wrote:
> Qualcomm's Krait CPUs have a handful of L2 cache controller
> registers that live behind a cp15 based indirection register.
> First you program the indirection register (l2cpselr) to point
> the L2 'window' register (l2cpdr) at what you want to read/write.
> Then you read/write the 'window' register to do what you want.
> The l2cpselr register is not banked per-cpu so we must lock
> around accesses to it to prevent other CPUs from re-pointing
> l2cpdr underneath us.
>
> Cc: Russell King
> Signed-off-by: Stephen Boyd
> ---
> arch/arm/common/Kconfig | 3 ++
> arch/arm/common/Makefile | 1 +
> arch/arm/common/krait-l2-accessors.c | 52
> +++
> arch/arm/include/asm/krait-l2-accessors.h | 20
> 4 files changed, 76 insertions(+)
> create mode 100644 arch/arm/common/krait-l2-accessors.c
> create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
[...]
> +void set_l2_indirect_reg(u32 addr, u32 val)
> +{
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(_l2_lock, flags);
> +
> + asm volatile ("mcr p15, 3, %0, c15, c0, 6" : : "r" (addr));
> + isb();
> + asm volatile ("mcr p15, 3, %0, c15, c0, 7" : : "r" (val));
> + isb();
> +
> + raw_spin_unlock_irqrestore(_l2_lock, flags);
> +}
> +EXPORT_SYMBOL(set_l2_indirect_reg);
It might be worth commmenting inline as to what register each of these is
accessing. Inevitably the commit message will become harder to find and
associate with the code over time.
Similarly for get_l2_indirect_reg.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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]tty:vt: Add NULL check to return value of kzalloc()
In extreme situation kzalloc in con_init may
return NULL, so we should check it to prevent
OOPS!
Signed-off-by: Wang YanQing
Reported-by: RUC_SoftSec
---
Changes:
v1-v2:
1:fix warning and error reported by scripts/checkpatch.pl
drivers/tty/vt/vc_screen.c | 6 --
drivers/tty/vt/vt.c| 12
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index d7799de..e0de4bc 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -662,7 +662,9 @@ int __init vcs_init(void)
device_create(vc_class, NULL, MKDEV(VCS_MAJOR, 0), NULL, "vcs");
device_create(vc_class, NULL, MKDEV(VCS_MAJOR, 128), NULL, "vcsa");
- for (i = 0; i < MIN_NR_CONSOLES; i++)
- vcs_make_sysfs(i);
+ for (i = 0; i < MIN_NR_CONSOLES; i++) {
+ if (vc_cons[i].d)
+ vcs_make_sysfs(i);
+ }
return 0;
}
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 740202d..8f490e9 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2885,6 +2885,8 @@ static int __init con_init(void)
for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data),
GFP_NOWAIT);
+ if (vc == NULL)
+ break;
INIT_WORK(_cons[currcons].SAK_work, vc_SAK);
tty_port_init(>port);
visual_init(vc, currcons, 1);
@@ -2892,8 +2894,18 @@ static int __init con_init(void)
vc_init(vc, vc->vc_rows, vc->vc_cols,
currcons || !vc->vc_sw->con_save_screen);
}
+ if (currcons < MIN_NR_CONSOLES)
+ pr_warn("Console: vt %d-%d initialization failed!\n",
+ currcons, MIN_NR_CONSOLES - 1);
+
currcons = fg_console = 0;
master_display_fg = vc = vc_cons[currcons].d;
+
+ if (vc == NULL) {
+ pr_warn("Console: no avaiable vt!\n");
+ console_unlock();
+ return 0;
+ }
set_origin(vc);
save_screen(vc);
gotoxy(vc, vc->vc_x, vc->vc_y);
--
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arc: include: asm: remove '__init' for setup_processor() and arc_init_IRQ()
On 10/28/2013 09:56 PM, Vineet Gupta wrote: > On 10/23/2013 07:42 AM, Chen Gang wrote: >> They haven't '__init' in definition, but has '__init' in declaration. >> And normal function start_kernel_secondary() may call setup_processor() >> which will call arc_init_IRQ(). >> >> So need remove '__init' for both of them. The related warning (with >> allmodconfig): >> >> MODPOST vmlinux.o >> WARNING: vmlinux.o(.text+0x3084): Section mismatch in reference from the >> function start_kernel_secondary() to the function >> .init.text:setup_processor() >> The function start_kernel_secondary() references >> the function __init setup_processor(). >> This is often because start_kernel_secondary lacks a __init >> annotation or the annotation of setup_processor is wrong. >> >> >> Signed-off-by: Chen Gang > > Applied for 3.13 > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arc: kernel: export symbol for pm_power_off in reset.c
On 10/28/2013 10:09 PM, Vineet Gupta wrote: > On 10/28/2013 09:19 AM, Chen Gang wrote: >> Need export symbol for it, or can not pass compiling, the related error >> with allmodconfig: >> >> MODPOST 2994 modules >> ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined! >> ERROR: "pm_power_off" [drivers/char/ipmi/ipmi_poweroff.ko] undefined! >> >> >> Signed-off-by: Chen Gang > > Applied for 3.13 > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arc: kernel: export symbol for save_stack_trace() in stacktrace.c
On 10/28/2013 10:06 PM, Vineet Gupta wrote: > On 10/28/2013 08:30 AM, Chen Gang wrote: >> Need export its symbol just like other architectures done, or can not >> pass compiling with allmodconfig, the related error: >> >> MODPOST 2994 modules >> ERROR: "save_stack_trace" [kernel/backtracetest.ko] undefined! >> ERROR: "save_stack_trace" >> [drivers/md/persistent-data/dm-persistent-data.ko] undefined! >> >> >> Signed-off-by: Chen Gang > > Applied for 3.13 > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arc: kernel: kgdb: add default implementation for kgdb_roundup_cpus()
On 10/28/2013 09:55 PM, Vineet Gupta wrote: > On 10/24/2013 09:21 AM, Chen Gang wrote: >> arc supports kgdb, but need update -- add function kgdb_roundup_cpus(), >> or can not pass compiling. At present, add the simple generic one just >> like other architectures(e.g. tile, mips ...). >> >> The related error (with allmodconfig): >> >> kernel/built-in.o: In function `kgdb_cpu_enter': >> kernel/debug/debug_core.c:580: undefined reference to `kgdb_roundup_cpus' >> >> >> Signed-off-by: Chen Gang > > Applied for 3.13. > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 2/2] usb: ffs/dwc3: pad epout buffer size when not aligned to maxpacketsize
DWC3 requires buffer size to be aligned to maxpacketsize of an out
endpoint. ffs_epfile_io() needs to pad epout buffer to match above
condition if DWC3 controller is used.
This patch solves an specific situation but a more generic solution
should be found.
Signed-off-by: David Cohen
---
drivers/usb/gadget/f_fs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 75e4b78..33880e6 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -27,6 +27,7 @@
#include
#include
+#include "gadget_chips.h"
#define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
@@ -755,10 +756,12 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file->private_data;
+ struct usb_gadget *gadget = epfile->ffs->gadget;
struct ffs_ep *ep;
char *data = NULL;
ssize_t ret;
int halt;
+ size_t orig_len = len;
goto first_try;
do {
@@ -794,6 +797,22 @@ first_try:
goto error;
}
+ /*
+* DWC3 requires buffer size to be aligned to maxpacketsize
+* of an out endpoint.
+* FIXME: a more generic solution might be necessary.
+*/
+ if (gadget_is_dwc3(gadget) && read &&
+ !IS_ALIGNED(len, ep->ep->desc->wMaxPacketSize)) {
+ size_t old_len = len;
+ len = roundup(orig_len,
+ (size_t)ep->ep->desc->wMaxPacketSize);
+ if (unlikely(data) && len > old_len) {
+ kfree(data);
+ data = NULL;
+ }
+ }
+
/* Allocate & copy */
if (!halt && !data) {
data = kzalloc(len, GFP_KERNEL);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 1/2] usb: gadget: re-introduce gadget_is_dwc3()
gadget_is_dwc3() is necessary to check whether we are running on
Desineware USB3 DRD controller.
This macro was previously removed by commit
ed9cbda63d45638b69ce62412e3a3c7b00644835 due to it wasn't needed
anymore. We're adding it again as things have changed.
Signed-off-by: David Cohen
---
drivers/usb/gadget/gadget_chips.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index bcd04bc..3186a5e 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -28,6 +28,7 @@
* do that for you.
*/
#define gadget_is_at91(g) (!strcmp("at91_udc", (g)->name))
+#define gadget_is_dwc3(g) (!strcmp("dwc3-gadget", (g)->name))
#define gadget_is_goku(g) (!strcmp("goku_udc", (g)->name))
#define gadget_is_musbhdrc(g) (!strcmp("musb-hdrc", (g)->name))
#define gadget_is_net2280(g) (!strcmp("net2280", (g)->name))
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arc: kernel: remove '__init' for first_lines_of_secondary()
On 10/28/2013 09:53 PM, Vineet Gupta wrote: > On 10/23/2013 07:46 AM, Chen Gang wrote: >> first_lines_of_secondary() is a '__init' function, but it may be called >> by __cpu_up() by _cpu_up() by cpu_up() which is a normal export symbol >> function. So recommend to remove '__init'. >> >> The related warning (with allmodconfig): >> >> MODPOST vmlinux.o >> WARNING: vmlinux.o(.text+0x315c): Section mismatch in reference from the >> function __cpu_up() to the function .init.text:first_lines_of_secondary() >> The function __cpu_up() references >> the function __init first_lines_of_secondary(). >> This is often because __cpu_up lacks a __init >> annotation or the annotation of first_lines_of_secondary is wrong. >> >> >> Signed-off-by: Chen Gang > > Applied for 3.13. But I'm planning to squash all the __init section annotation > fixes into one patch. OK with you ? > It is OK to me. They are all related with each other, although toolchain reports several warnings (originally, I made them based on warning items). Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 0/2] patchset to workaround f_fs for DWC3
Hi, These patches are a proposal to workaround f_fs when using DWC3 controller. Since DWC3 requires epout buffer size to be aligned to maxpacketsize, f_fs needs to pad buffer size to match the above case. This change is necessary to make Android's adbd service to work with f_fs instead of out-of-tree android gadget. If this same situation is happening in other still untested places, a more generic solution may be required. --- David Cohen (2): usb: gadget: re-introduce gadget_is_dwc3() usb: ffs/dwc3: pad epout buffer size when not aligned to maxpacketsize drivers/usb/gadget/f_fs.c | 19 +++ drivers/usb/gadget/gadget_chips.h | 1 + 2 files changed, 20 insertions(+) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev 4/5] f2fs: Key functions to handle inline data
Hi,
2013-10-29 (화), 01:20 +0800, Huajun Li:
> On Mon, Oct 28, 2013 at 8:43 PM, Jaegeuk Kim wrote:
> > Hi,
> >
> > 2013-10-26 (토), 00:01 +0800, Huajun Li:
> >> From: Huajun Li
> >>
> >> Functions to implement inline data read/write, and move inline data to
> >> normal data block when file size exceeds inline data limitation.
> >>
> >> Signed-off-by: Huajun Li
> >> Signed-off-by: Haicheng Li
> >> Signed-off-by: Weihong Xu
> >> ---
> >> fs/f2fs/Makefile |2 +-
> >> fs/f2fs/f2fs.h |7 +++
> >> fs/f2fs/inline.c | 144
> >> ++
> >> 3 files changed, 152 insertions(+), 1 deletion(-)
> >> create mode 100644 fs/f2fs/inline.c
> >>
> >
> > [snip]
> >
> >> +static int __f2fs_convert_inline_data(struct inode *inode, struct page
> >> *page)
> >> +{
> >> + int err;
> >> + struct page *ipage;
> >> + struct dnode_of_data dn;
> >> + void *src_addr, *dst_addr;
> >> + struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> >> +
> >
> > Here.. f2fs_lock_op(sbi);
> >
> >> + ipage = get_node_page(sbi, inode->i_ino);
> >> + if (IS_ERR(ipage))
> >> + return PTR_ERR(ipage);
> >> +
> >
> > Need to move f2fs_lock_op prior to get_node_page.
> >
> >> + /* i_addr[0] is not used for inline data,
> >
> > Coding style.
> > /*
> > * ...
> > */
> >
> >> + * so reserving new block will not destroy inline data */
> >> + err = f2fs_reserve_block(inode, , 0);
> >> + if (err) {
> >> + f2fs_put_page(ipage, 1);
> >> + f2fs_unlock_op(sbi);
> >> + return err;
> >> + }
> >
> > Need to move this too.
> >
> >> +
> >> + src_addr = inline_data_addr(ipage);
> >> + dst_addr = page_address(page);
> >> + zero_user_segment(page, 0, PAGE_CACHE_SIZE);
> >
> > + space for readability.
> >
> >> + /* Copy the whole inline data block */
> >> + memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
> >> + zero_user_segment(ipage, INLINE_DATA_OFFSET,
> >> + INLINE_DATA_OFFSET + MAX_INLINE_DATA);
> >> + clear_inode_flag(F2FS_I(inode), FI_INLINE_DATA);
> >> + set_raw_inline(F2FS_I(inode),
> >> + (struct f2fs_inode *)page_address(ipage));
>
> Thanks for your comments, I will update them according to above comments.
>
> >
> >--> sync_inode_page()?
> >
> IMO, we just handle file data, so do we still need call sync_inode_page() ?
I think sync_inode_page() is more suitable, since we need to sync
between i_size, i_blocks and its i_flag, inline_data, at this moment.
>
> >> +
> >> + set_page_dirty(ipage);
Need to consider skipping set_page_dirty(ipage).
> >> + f2fs_put_page(ipage, 1);
> >> + set_page_dirty(page);
> >
> > Here... f2fs_unlock_op(sbi);
> >
> > Here, we need to consider data consistency.
> > Let's think about the below scenario.
> > 1. inline_data was written.
> > 2. sync_fs is done.
> > 3. additional data were written.
> > : this triggers f2fs_convert_inline_data(), produces a page, and then
> > unsets the inline flag.
> > 4. checkpoint was done with updated inode page. Note that, checkpoint
> > doesn't guarantee any user data.
> > 5. sudden power-off is occurred.
> > -> Once power-off-recovery is done, we loose the inline_data which was
> > written successfully at step #2.
> >
> > So, I think we need to do f2fs_sync_file() procedure at this moment.
> > Any idea?
> >
>
> Yes, need consider this case carefully, thanks for your reminder.
>
> Considering sudden power-off may happen before f2fs_sync_file() is
> called, so how about following solutions:
> ...
> /* Copy the whole inline data block */
> memcpy(dst_addr, src_addr, MAX_INLINE_DATA);
>
> do f2fs_sync_file() procedure ( Or do write_data_page() procedure ? )
Ya, but it may still have some conditions to do this or not.
One of them is checking whether previous inline data should be recovered
or not, for example.
>
> zero_user_segment(ipage, INLINE_DATA_OFFSET, INLINE_DATA_OFFSET +
> MAX_INLINE_DATA);
> clear_inode_flag(F2FS_I(inode), FI_INLINE_DATA);
> set_raw_inline(F2FS_I(inode), (struct f2fs_inode *)page_address(ipage));
> ...
>
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +int f2fs_convert_inline_data(struct inode *inode,
> >> + struct page *p, unsigned flags)
> >> +{
> >> + int err;
> >> + struct page *page;
> >> +
> >> + if (p && !p->index) {
> >> + page = p;
> >> + } else {
> >> + page = grab_cache_page_write_begin(inode->i_mapping, 0,
> >> flags);
> >> + if (IS_ERR(page))
> >> + return PTR_ERR(page);
> >> + }
> >> +
> >> + err = __f2fs_convert_inline_data(inode, page);
> >> +
> >> + if (p && !p->index)
> >> + f2fs_put_page(page, 1);
> >> +
> >> + return err;
> >> +}
> >> +
> >> +int f2fs_write_inline_data(struct inode *inode,
> >> +
Re: [PATCHv2 1/3] Input: twl4030-keypad - add device tree support
On Mon, Oct 28, 2013 at 01:42:47AM -0500, Kumar Gala wrote: > > +This binding is based on the matrix-keymap binding with the following > > +changes: > > Maybe be a bit more specific and say 'based on the input/matrix-keymap.txt > binding'.. OK. > > + * keypad,num-rows and keypad,num-columns are required. > > Is linux,keymap required from matrix-keymap.txt? Yes, matrix-keymap.txt contains descriptions for the following: required: - linux,keymap optional: - keypad,num-rows - keypad,num-columns > > +Optional Properties specific to linux: > > +- linux,keypad-no-autorepeat: do no enable autorepeat feature. > > Does it make sense to update the matrix-keymap.txt binding to add > 'linux,keypad-no-autorepeat' there? At least according to devicetree documentation there are keymap-matrix.txt based drivers, which do not support "linux,keypad-no-autorepeat". -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] arch: use ASM_NL instead of ';' for assembler new line character in the macro
On 10/28/2013 09:45 PM, Vineet Gupta wrote: > On 10/28/2013 04:00 PM, Chen Gang wrote: >> For some toolchains, they use another character as newline in a macro >> (e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a >> macro) instead of ';' for it. >> >> Since "linux/export.h" are mainly used for exporting work, then our fix >> more likely belongs to "linux/linkage.h", and we need add the related >> checking in "linkage.h". >> >> Also need notice 80 columns wrap, and '\t' for each line. >> >> >> Signed-off-by: Chen Gang >> --- >> arch/arc/include/asm/linkage.h|2 + >> include/asm-generic/vmlinux.lds.h | 350 >> +++-- >> include/linux/linkage.h | 19 + > > Like Max said, please drop the linker script bits - they are OK - otherwise > ARC > kernel won't have been building at all. > OK, thank you and Max, I will send patch v2 for it. Hmm... after this modification, it passed allmodconfig for x86_64. And for arc, at least, it can build to "mm/" sub-directory (after here, I stopped compiling). > And you also need to fix kernel/modsign_certificate.S as part of same > patchset as > that is where the problem started in first place. > Hmm... can that be another patch? For "kernel/modsign_certificate.S", I recommend to expand the macro which will shrink code line, either need not include additional header file, I feel that will be simpler for both code reader and writers. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev 3/5] f2fs: Add a new function: f2fs_reserve_block()
Hi Huajun,
2013-10-29 (화), 00:53 +0800, Huajun Li:
> Hi Jaegeuk,
>
> Thanks for your kindly review and comments.
>
> On Mon, Oct 28, 2013 at 8:28 PM, Jaegeuk Kim wrote:
> > 2013-10-28 (월), 21:16 +0900, Jaegeuk Kim:
> > Hi,
> >
> >>
> >> 2013-10-26 (토), 00:01 +0800, Huajun Li:
> >> > From: Huajun Li
> >> >
> >> > Add the function f2fs_reserve_block() to easily reserve new blocks.
> >> >
> >> > Signed-off-by: Huajun Li
> >> > Signed-off-by: Haicheng Li
> >> > Signed-off-by: Weihong Xu
> >> > ---
> >> > fs/f2fs/data.c | 29 ++---
> >> > fs/f2fs/f2fs.h |1 +
> >> > 2 files changed, 19 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> >> > index c8887d8..7b31911 100644
> >> > --- a/fs/f2fs/data.c
> >> > +++ b/fs/f2fs/data.c
> >> > @@ -64,6 +64,23 @@ int reserve_new_block(struct dnode_of_data *dn)
> >> > return 0;
> >> > }
> >> >
> >> > +int f2fs_reserve_block(struct inode *inode,
> >> > + struct dnode_of_data *dn, pgoff_t index)
> >>
> >
> > We don't need to get dnode_of_data from parameters, since it is
> > used by this function only.
>
> After calling f2fs_reserve_block(), we need dn.data_blkaddr to check
> whether it is NEW_ADDR. So IMO, it's nice to keep this parameter.
>
Ah, got it.
BTW, I found another flows we can clean up wrt this issue.
How about this?
---
fs/f2fs/data.c | 51 +++
fs/f2fs/f2fs.h | 1 +
fs/f2fs/file.c | 39 ++-
3 files changed, 30 insertions(+), 61 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c8887d8..b8c4f76d 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -64,6 +64,22 @@ int reserve_new_block(struct dnode_of_data *dn)
return 0;
}
+int f2fs_reserve_block(struct dnode_of_data *dn, pgoff_t index)
+{
+ bool need_put = dn->inode_page ? false : true;
+ int err;
+
+ err = get_dnode_of_data(dn, index, ALLOC_NODE);
+ if (err)
+ return err;
+ if (dn->data_blkaddr == NULL_ADDR)
+ err = reserve_new_block(dn);
+
+ if (need_put)
+ f2fs_put_dnode(dn);
+ return err;
+}
+
static int check_extent_cache(struct inode *inode, pgoff_t pgofs,
struct buffer_head *bh_result)
{
@@ -300,19 +316,9 @@ struct page *get_new_data_page(struct inode *inode,
int err;
set_new_dnode(, inode, npage, npage, 0);
- err = get_dnode_of_data(, index, ALLOC_NODE);
+ err = f2fs_reserve_block(, index);
if (err)
return ERR_PTR(err);
-
- if (dn.data_blkaddr == NULL_ADDR) {
- if (reserve_new_block()) {
- if (!npage)
- f2fs_put_dnode();
- return ERR_PTR(-ENOSPC);
- }
- }
- if (!npage)
- f2fs_put_dnode();
repeat:
page = grab_cache_page(mapping, index);
if (!page)
@@ -644,21 +650,15 @@ repeat:
*pagep = page;
f2fs_lock_op(sbi);
-
set_new_dnode(, inode, NULL, NULL, 0);
- err = get_dnode_of_data(, index, ALLOC_NODE);
- if (err)
- goto err;
-
- if (dn.data_blkaddr == NULL_ADDR)
- err = reserve_new_block();
-
- f2fs_put_dnode();
- if (err)
- goto err;
-
+ err = f2fs_reserve_block(, index);
f2fs_unlock_op(sbi);
+ if (err) {
+ f2fs_put_page(page, 1);
+ return err;
+ }
+
if ((len == PAGE_CACHE_SIZE) || PageUptodate(page))
return 0;
@@ -691,11 +691,6 @@ out:
SetPageUptodate(page);
clear_cold_data(page);
return 0;
-
-err:
- f2fs_unlock_op(sbi);
- f2fs_put_page(page, 1);
- return err;
}
static int f2fs_write_end(struct file *file,
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c9d394c..e77ca20 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1112,6 +1112,7 @@ void destroy_checkpoint_caches(void);
* data.c
*/
int reserve_new_block(struct dnode_of_data *);
+int f2fs_reserve_block(struct dnode_of_data *, pgoff_t);
void update_extent_cache(block_t, struct dnode_of_data *);
struct page *find_data_page(struct inode *, pgoff_t, bool);
struct page *get_lock_data_page(struct inode *, pgoff_t);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 2d4190a..21ef0d1 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -33,7 +33,6 @@ static int f2fs_vm_page_mkwrite(struct vm_area_struct
*vma,
struct page *page = vmf->page;
struct inode *inode = file_inode(vma->vm_file);
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
- block_t old_blk_addr;
struct dnode_of_data dn;
int err;
@@ -44,24 +43,10 @@ static int f2fs_vm_page_mkwrite(struct
vm_area_struct *vma,
/* block allocation */
f2fs_lock_op(sbi);
[PATCH] tpm/tpm_ibmvtpm: fix unreachable code warning (smatch warning)
smatch complains:
/data/data-old/linux-2.6/drivers/char/tpm/tpm_ibmvtpm.c:510
ibmvtpm_crq_process() info: ignoring unreachable code.
-> The return is not necessary here, remove it
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ibmvtpm.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 2783a42..cab8d09 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -507,7 +507,6 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
dev_err(ibmvtpm->dev, "Unknown crq message type: %d\n",
crq->msg);
return;
}
- return;
case IBMVTPM_VALID_CMD:
switch (crq->msg) {
case VTPM_GET_RTCE_BUFFER_SIZE_RES:
--
1.7.8.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 v6 3/3] Staging: zram: Fix decrement of variable by calling bdput()
On Mon, Oct 28, 2013 at 05:54:39PM +0530, Rashika Kheria wrote: > As suggested by Jerome Marchand "The code in reset_store get the block device > (bdget_disk()) but it does not put it (bdput()) when it's done using it. > The usage count is therefor incremented but never decremented." > > Hence, this patch introduces a call to bdput() to decrement the variable > after usage. > > Signed-off-by: Rashika Kheria I think this patch is for stable, too. So, please read my previous reply. And please relocate this with [2/3] and do bdput in all of error cases in reset_store. > --- > drivers/staging/zram/zram_drv.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c > index 9027975..98dac15 100644 > --- a/drivers/staging/zram/zram_drv.c > +++ b/drivers/staging/zram/zram_drv.c > @@ -664,6 +664,7 @@ static ssize_t reset_store(struct device *dev, > > /* Make sure all pending I/O is finished */ > fsync_bdev(bdev); > + bdput(bdev); > > zram_reset_device(zram, true); > return len; > -- > 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/ -- 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: [PATCH v6 2/3] Staging: zram: Fix variable dereferenced before check
On Mon, Oct 28, 2013 at 05:53:40PM +0530, Rashika Kheria wrote: > This patch fixes the following Smatch warning in zram_drv.c- > drivers/staging/zram/zram_drv.c:899 > destroy_device() warn: variable dereferenced before check 'zram->disk' (see > line 896) > > Signed-off-by: Rashika Kheria Acked-by: Minchan Kim -- 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: [PATCH v6 1/3] Staging: zram: Fix access of NULL pointer
Hello Rashika, On Mon, Oct 28, 2013 at 05:51:38PM +0530, Rashika Kheria wrote: > This patch fixes the bug in reset_store caused by accessing NULL pointer. > Hence, It introduces a check for bdev. It also removes unnecessary check > of bdev for fsync_bdev(). It's better than old but I still want it more better. First of all, I hope patch description is more clear in case of bugfix patch because other maintainers from stable/distro or other people could understand well so they could judge once again whether they need to backport or not. If maintainer judge that it's not severe, even they couldn't backport. Patch description includes followin as, at least. 1. When this bug happens? 2. What's the result of user POV? 3. How to fix it. You were good for 2 and 3 but 1 I can help. If memory pressure is severe, inode could be reclaimed. In this case, bdget_disk can return NULL because allocation of inode in bdget could fail. I hope you could do better massage. In addition, this bug have been for a long time so it deserves backporting to stable tree. In such case, you could Cc stable tree with stable mark. Please refer Documentation/stable_kernel_rules.txt and others patches in LKML. After this year kernel summit, it seems to change something rule for marking stable but I thinks it's not solid so old rule still would be valid. Thanks! > > Signed-off-by: Rashika Kheria > --- > > This revision fixes the following issues of the previous revision- > Seperating patches into Bug fix and Smatch fix > > drivers/staging/zram/zram_drv.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c > index 2c4ed52..d640a8f 100644 > --- a/drivers/staging/zram/zram_drv.c > +++ b/drivers/staging/zram/zram_drv.c > @@ -648,6 +648,9 @@ static ssize_t reset_store(struct device *dev, > zram = dev_to_zram(dev); > bdev = bdget_disk(zram->disk, 0); > > + if (!bdev) > + return -EBUSY; > + > /* Do not reset an active device! */ > if (bdev->bd_holders) > return -EBUSY; > @@ -660,8 +663,7 @@ static ssize_t reset_store(struct device *dev, > return -EINVAL; > > /* Make sure all pending I/O is finished */ > - if (bdev) > - fsync_bdev(bdev); > + fsync_bdev(bdev); > > zram_reset_device(zram, true); > return len; > -- > 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/ -- 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: [PATCH v3 08/10] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On 10/28/13 11:12, Josh Cartwright wrote:
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 914c3d1..0a288cb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -476,6 +476,16 @@ config MFD_PM8XXX_IRQ
> This is required to use certain other PM 8xxx features, such as GPIO
> and MPP.
>
> +config MFD_PM8X41
> + bool "Qualcomm PM8X41 PMIC"
Can this be tristate?
> + depends on ARCH_MSM
It would be nice if we didn't have to depend on ARCH_MSM so we get some
more build coverage but the driver is so simple it probably doesn't matter.
> + select REGMAP_SPMI
> + help
> + This enables basic support for the Qualcomm 8941 and 8841 PMICs.
> These
> + PMICs are currently used with the Snapdragon 800 series of SoCs.
> Note, that
> + this will only be useful paired with descriptions of the independent
> functions
> + as children nodes in the device tree.
> +
> config MFD_RDC321X
> tristate "RDC R-321x southbridge"
> select MFD_CORE
> diff --git a/drivers/mfd/pm8x41.c b/drivers/mfd/pm8x41.c
> new file mode 100644
> index 000..0a57221
> --- /dev/nullalso
> +++ b/drivers/mfd/pm8x41.c
> @@ -0,0 +1,64 @@
[...]
> +
> +static int pm8x41_probe(struct spmi_device *sdev)
> +{
> + struct regmap *regmap;
> +
> + regmap = devm_regmap_init_spmi(sdev, _regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_dbg(>dev, "regmap creation failed.\n");
> + return PTR_ERR(regmap);
> + }
> +
> + return of_platform_populate(sdev->dev.of_node, NULL, NULL, >dev);
> +}
> +
> +static struct of_device_id pm8x41_id_table[] = {
const?
> + { "qcom,pm8841", },
> + { "qcom,pm8941", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pm8x41_id_table);
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] swiotlb-xen: fix error code returned by xen_swiotlb_map_sg_attrs
map_sg returns the number of elements mapped, not a dma_addr_t.
In case of error return 0, not DMA_ERROR_CODE.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 100962d..8af6862 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -548,7 +548,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct
scatterlist *sgl,
xen_swiotlb_unmap_sg_attrs(hwdev, sgl, i, dir,
attrs);
sg_dma_len(sgl) = 0;
- return DMA_ERROR_CODE;
+ return 0;
}
sg->dma_address = xen_phys_to_bus(map);
} else {
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] ARM: dts: msm: Add Krait edac node
Cc: David Brown
Signed-off-by: Stephen Boyd
---
This is based on the dts updates I sent two weeks ago to add mmio
architected timesr to qcom-msm8974.dtsi.
arch/arm/boot/dts/qcom-msm8974.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 152879d..7b15eb7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -32,6 +32,11 @@
clock-frequency = <1920>;
};
+ edac {
+ compatible = "qcom,krait-cache-erp";
+ interrupts = <1 9 0xf04>, <0 2 0>;
+ };
+
timer@f902 {
#address-cells = <1>;
#size-cells = <1>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] edac: Add support for Krait CPU cache error detection
Add support for the Krait CPU cache error detection. This is a
simplified version of the code originally written by Stepan
Moskovchenko[1] ported to the EDAC device framework.
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/mach-msm/cache_erp.c?h=msm-3.4
Cc: Stepan Moskovchenko
Signed-off-by: Stephen Boyd
---
drivers/edac/Kconfig | 8 ++
drivers/edac/Makefile | 2 +
drivers/edac/krait_edac.c | 336 ++
3 files changed, 346 insertions(+)
create mode 100644 drivers/edac/krait_edac.c
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 878f090..68f612d 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -368,4 +368,12 @@ config EDAC_OCTEON_PCI
Support for error detection and correction on the
Cavium Octeon family of SOCs.
+config EDAC_KRAIT_CACHE
+ tristate "Krait L1/L2 Cache"
+ depends on EDAC_MM_EDAC && ARCH_MSM
+ select KRAIT_L2_ACCESSORS
+ help
+ Support for error detection and correction on the
+ Krait L1/L2 cache controller.
+
endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 4154ed6..b6ea505 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -64,3 +64,5 @@ obj-$(CONFIG_EDAC_OCTEON_PC) += octeon_edac-pc.o
obj-$(CONFIG_EDAC_OCTEON_L2C) += octeon_edac-l2c.o
obj-$(CONFIG_EDAC_OCTEON_LMC) += octeon_edac-lmc.o
obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
+
+obj-$(CONFIG_EDAC_KRAIT_CACHE) += krait_edac.o
diff --git a/drivers/edac/krait_edac.c b/drivers/edac/krait_edac.c
new file mode 100644
index 000..89380a1
--- /dev/null
+++ b/drivers/edac/krait_edac.c
@@ -0,0 +1,336 @@
+/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "edac_core.h"
+
+#define CESR_DCTPE BIT(0)
+#define CESR_DCDPE BIT(1)
+#define CESR_ICTPE BIT(2)
+#define CESR_ICDPE BIT(3)
+#define CESR_DCTE (BIT(4) | BIT(5))
+#define CESR_ICTE (BIT(6) | BIT(7))
+#define CESR_TLBMH BIT(16)
+#define CESR_I_MASK0x00cc
+/* Print a message for everything but TLB MH events */
+#define CESR_PRINT_MASK0x00ff
+
+#define L2ESR 0x204
+#define L2ESR_MPDCDBIT(0)
+#define L2ESR_MPSLVBIT(1)
+#define L2ESR_TSESBBIT(2)
+#define L2ESR_TSEDBBIT(3)
+#define L2ESR_DSESBBIT(4)
+#define L2ESR_DSEDBBIT(5)
+#define L2ESR_MSE BIT(6)
+#define L2ESR_MPLDREXNOK BIT(8)
+#define L2ESR_CPU_MASK 0xf
+#define L2ESR_CPU_SHIFT16
+#define L2ESR_SP BIT(20)
+
+#define L2ESYNR0 0x208
+#define L2ESYNR1 0x209
+#define L2EAR0 0x20c
+#define L2EAR1 0x20d
+
+struct krait_edac {
+ int l1_irq;
+ struct edac_device_ctl_info * __percpu *edev;
+ struct notifier_block notifier;
+};
+
+struct krait_edac_error {
+ const char * const msg;
+ void (*func)(struct edac_device_ctl_info *edac_dev,
+ int inst_nr, int block_nr, const char *msg);
+};
+
+static unsigned int read_cesr(void)
+{
+ unsigned int cesr;
+
+ asm volatile ("mrc p15, 7, %0, c15, c0, 1" : "=r" (cesr));
+ return cesr;
+}
+
+static void write_cesr(unsigned int cesr)
+{
+ asm volatile ("mcr p15, 7, %0, c15, c0, 1" : : "r" (cesr));
+}
+
+static unsigned int read_cesynr(void)
+{
+ unsigned int cesynr;
+
+ asm volatile ("mrc p15, 7, %0, c15, c0, 3" : "=r" (cesynr));
+ return cesynr;
+}
+
+static irqreturn_t krait_l1_irq(int irq, void *dev_id)
+{
+ struct edac_device_ctl_info *edac = dev_id;
+ unsigned int cesr = read_cesr();
+ unsigned int i_cesynr, d_cesynr;
+ unsigned int cpu = smp_processor_id();
+ int print_regs = cesr & CESR_PRINT_MASK;
+ int i;
+ static const struct krait_edac_error errors[] = {
+ { "D-cache tag parity error", edac_device_handle_ue },
+ { "D-cache data parity error", edac_device_handle_ue },
+ { "I-cache tag parity error", edac_device_handle_ce },
+ { "I-cache data parity error", edac_device_handle_ce },
+ { "D-cache tag timing error",
[PATCH 3/6] ARM: Add Krait L2 accessor functions
Qualcomm's Krait CPUs have a handful of L2 cache controller
registers that live behind a cp15 based indirection register.
First you program the indirection register (l2cpselr) to point
the L2 'window' register (l2cpdr) at what you want to read/write.
Then you read/write the 'window' register to do what you want.
The l2cpselr register is not banked per-cpu so we must lock
around accesses to it to prevent other CPUs from re-pointing
l2cpdr underneath us.
Cc: Russell King
Signed-off-by: Stephen Boyd
---
arch/arm/common/Kconfig | 3 ++
arch/arm/common/Makefile | 1 +
arch/arm/common/krait-l2-accessors.c | 52 +++
arch/arm/include/asm/krait-l2-accessors.h | 20
4 files changed, 76 insertions(+)
create mode 100644 arch/arm/common/krait-l2-accessors.c
create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index c3a4e9c..9da52dc 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -9,6 +9,9 @@ config DMABOUNCE
bool
select ZONE_DMA
+config KRAIT_L2_ACCESSORS
+ bool
+
config SHARP_LOCOMO
bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 8c60f47..606131a 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ICST) += icst.o
obj-$(CONFIG_SA) += sa.o
obj-$(CONFIG_PCI_HOST_VIA82C505) += via82c505.o
obj-$(CONFIG_DMABOUNCE)+= dmabounce.o
+obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o
obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
diff --git a/arch/arm/common/krait-l2-accessors.c
b/arch/arm/common/krait-l2-accessors.c
new file mode 100644
index 000..c579794
--- /dev/null
+++ b/arch/arm/common/krait-l2-accessors.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2011-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+#include
+#include
+
+static DEFINE_RAW_SPINLOCK(krait_l2_lock);
+
+void set_l2_indirect_reg(u32 addr, u32 val)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(_l2_lock, flags);
+
+ asm volatile ("mcr p15, 3, %0, c15, c0, 6" : : "r" (addr));
+ isb();
+ asm volatile ("mcr p15, 3, %0, c15, c0, 7" : : "r" (val));
+ isb();
+
+ raw_spin_unlock_irqrestore(_l2_lock, flags);
+}
+EXPORT_SYMBOL(set_l2_indirect_reg);
+
+u32 get_l2_indirect_reg(u32 addr)
+{
+ u32 val;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(_l2_lock, flags);
+
+ asm volatile ("mcr p15, 3, %0, c15, c0, 6" : : "r" (addr));
+ isb();
+ asm volatile ("mrc p15, 3, %0, c15, c0, 7" : "=r" (val));
+
+ raw_spin_unlock_irqrestore(_l2_lock, flags);
+
+ return val;
+}
+EXPORT_SYMBOL(get_l2_indirect_reg);
diff --git a/arch/arm/include/asm/krait-l2-accessors.h
b/arch/arm/include/asm/krait-l2-accessors.h
new file mode 100644
index 000..d5305c4
--- /dev/null
+++ b/arch/arm/include/asm/krait-l2-accessors.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2011-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H
+#define __ASMARM_KRAIT_L2_ACCESSORS_H
+
+extern void set_l2_indirect_reg(u32 addr, u32 val);
+extern u32 get_l2_indirect_reg(u32 addr);
+
+#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] edac: Document Krait L1/L2 EDAC driver binding
The Krait L1/L2 error reporting device is made up of two
interrupts, one per-CPU interrupt for the L1 caches and one
interrupt for the L2 cache.
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/arm/qcom,krait-cache-erp.txt | 16
1 file changed, 16 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
diff --git a/Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
b/Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
new file mode 100644
index 000..01fe8a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,krait-cache-erp.txt
@@ -0,0 +1,16 @@
+* Qualcomm Krait L1 / L2 cache error reporting
+
+Required properties:
+- compatible: Should be "qcom,krait-cache-erp"
+- interrupts: Should contain the L1/CPU error interrupt number and
+ then the L2 cache error interrupt number
+
+Optional properties:
+- interrupt-names: Should contain the interrupt names "l1_irq" and
+ "l2_irq"
+
+Example:
+ edac {
+ compatible = "qcom,krait-cache-erp";
+ interrupts = <1 9 0xf04>, <0 2 0x4>;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
