Re: [PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board
On Thu, 05 Feb 2015 23:13:58 +0100 Sebastian Hesselbarth wrote: > > At this moment, I am trying to configure the framebuffer, but as Moine > > told me,it seems there is not video driver support for this board in > > DT... :( . > > Not quite true. Video is made up of at least 4 different devices: > Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or > VGA. > > We do have a driver for the framebuffer (armada_drm) and there is great > work from Russell King and others on the GPU and Decode engine (IIRC). Yes, but it has no DT support. Mine has. > If you are using the sb-a510, I can see from the manual, that DVI > transmitter is SIL164.. AFAIS there is a driver for it, that maybe > needs some polishing. Nobody ever tested VGA, but it shouldn't be too > hard to add support for it as it is directly supported by the > framebuffer HW. This asks for some VGA encoder/connector module. Actually, as Gabriel told me that his screen is directly connected to the RGB LCD output, I wrote a simple panel for him. This module just gets the display timings from the DT. > One quite important driver at least for Dove is a clock source for > video. Internal clock generators for video are way to limited with > respect to frequencies to allow any useful resolution. >From my previous tests with the si5351 in the Cubox, most video modes should work without external clocks. > I'll see if I can have a look at the dts stuff this weekend.. that > way we'll have at least the basic done before moving to the other > devices. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Linaro-acpi] [PATCH v8 11/21] ARM64 / ACPI: Get PSCI flags in FADT for PSCI init
Hi Lorenzo, Al,
On 2015年02月06日 03:03, Al Stone wrote:
On 02/05/2015 10:49 AM, Lorenzo Pieralisi wrote:
Hi Al,
Howdy, Lorenzo.
On Thu, Feb 05, 2015 at 05:11:31PM +, Al Stone wrote:
On 02/04/2015 09:43 AM, Lorenzo Pieralisi wrote:
On Mon, Feb 02, 2015 at 12:45:39PM +, Hanjun Guo wrote:
From: Graeme Gregory
There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the firmware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).
FADT table contains such information in ACPI 5.1, FADT table was
parsed in ACPI table init and copy to struct acpi_gbl_FADT, so
use the flags in struct acpi_gbl_FADT for PSCI init.
So you do rely on a global FADT being available, if you use it for PSCI
detection you can use it for ACPI revision detection too, right ?
Point is, either we should not use the global FADT table, or we use
it consistently, or there is something I am unaware of that prevents
you from using in some code paths and I would like to understand
why.
The FADT is a required table for arm64, as noted in the documentation
and the SBBR. While unfortunately the spec does not say it is mandatory,
even x86 systems are pretty useless without it. So yes, we rely on it
being available, not only for the PSCI info, but other flags such as
HW_REDUCED_ACPI.
I suppose it does not have to be globally scoped. However, the FADT is
frequently used, especially on x86, so it makes sense to me from an
efficiency standpoint to have a global reference to it.
I'm not sure I understand what is meant by using FADT for ACPI revision
detection; there are fields in the FADT that provide a major and minor
number for the FADT itself, but I don't believe there's any guarantee
those will be the same as the level of the specification that is being
supported by the kernel (chances are they will, but it's not mandatory).
I've probably just missed a part of a thread somewhere; could you point
me to where the inconsistency lies? I'm just not understanding right this
second
Yes, it is my fault, I was referring to another thread/patch (9), where you
need to check the FADT revision to "validate it" (ie >= 5.1) for the arm64
kernel. What I am saying is: if the global FADT is there to parse PSCI
info, it is there to check the FADT revision too, I do not necessarily
see the need for calling acpi_table_parse() again to do it, the FADT
revision checking can be carried out as for PSCI, that's all I wanted
to say.
Aha. I understand now. Another colleague was also trying to explain this
to me and I think I just hadn't had enough coffee yet. The underlying ACPI
code maps tables into the kernel in two phases; it may be that when the code
in patch 9 is run, the global table is not yet available, while here it is;
I don't recall off-hand.
I'll take a look at this and talk it over with Hanjun. If the global table
is available, it would indeed make sense to be consistent.
I had dig into the code and found out that struct acpi_gbl_FADT will be
available with correct value only if FADT is presented by firmware.
acpi_table_init() will be called before parsing FADT for PSCI flag in
this patch set.
In acpi_table_init()
acpi_initialize_tables()
acpi_tb_parse_root_table()
In acpi_tb_parse_root_table()
if (ACPI_SUCCESS(status) &&
ACPI_COMPARE_NAME(_gbl_root_table_list.
tables[table_index].signature,
ACPI_SIG_FADT)) {
acpi_tb_parse_fadt(table_index);
}
And acpi_tb_parse_fadt(table_index) will copy the
fadt table to global struct acpi_gbl_FADT.
so it seems that we can use global struct acpi_gbl_FADT directly to
check the FADT revision, but it is only available with firmware
presented the FADT table, so check for the FADT table is still needed
for some bad firmware without FADT.
Why PSCI flag can be used without any check for the availability
of FADT? because we already disable ACPI if
(acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt))
failed (no FADT tabled found), and PSCI flag will not be used
later.
So I think we can keep the code as it is for now, and I think
it is the safest way to do it, does it make sense?
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bfin_can: rewrite the blackfin style of read/write to common ones
On 02/06/2015 07:25 AM, Aaron Wu wrote: > Replace the blackfin arch dependent style of bfin_read/bfin_write with > common readw/writew Patch 1 & 2 are fine, 3 needs some whitespace improvements (see my reply for more details). regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 3/3] bfin_can: move and merge the content of header file into driver body
On 02/06/2015 07:25 AM, Aaron Wu wrote:
> Header file was in arch dependent location
> arch/blackfin/include/asm/bfin_can.h,
> Now move and merge the useful contents of header file into driver code, note
> the original header file is reserved for full register sets access test by
> other
> code so it survives.
^^^
Trailing whitespace :)
>
> Signed-off-by: Aaron Wu
> ---
> drivers/net/can/bfin_can.c | 114
> +++-
> 1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
> index 259d09a..63fab5c 100644
> --- a/drivers/net/can/bfin_can.c
> +++ b/drivers/net/can/bfin_can.c
> @@ -20,13 +20,125 @@
> #include
> #include
>
> -#include
> #include
>
> #define DRV_NAME "bfin_can"
> #define BFIN_CAN_TIMEOUT 100
> #define TX_ECHO_SKB_MAX 1
>
> +/* transmit and receive channels */
> +
> +#define TRANSMIT_CHL24
> +#define RECEIVE_STD_CHL0
> +#define RECEIVE_EXT_CHL4
> +#define RECEIVE_RTR_CHL8
> +#define RECEIVE_EXT_RTR_CHL12
> +#define MAX_CHL_NUMBER32
Please fix the indention, use one space only.
> +
> +/* All Blackfin system MMRs are padded to 32bits even if the register
> + * itself is only 16bits. So use a helper macro to streamline this
> +*/
> +#define __BFP(m) u16 m; u16 __pad_##m
> +
> + /* bfin can registers layout
> + */
> +struct bfin_can_mask_regs {
> + __BFP(aml);
> + __BFP(amh);
> +};
> +
> +struct bfin_can_channel_regs {
> + /* data[0,2,4,6] -> data{0,1,2,3} while data[1,3,5,7] is padding */
> + u16 data[8];
> + __BFP(dlc);
^ please remove that space
> + __BFP(tsv);
> + __BFP(id0);
> + __BFP(id1);
> +};
> +
> +struct bfin_can_regs {
> + /* global control and status registers
> + */
> + __BFP(mc1); /* offset 0x00 */
^^^
please use tab(s) instead of spaces here.
> + __BFP(md1); /* offset 0x04 */
> + __BFP(trs1); /* offset 0x08 */
> + __BFP(trr1); /* offset 0x0c */
> + __BFP(ta1); /* offset 0x10 */
> + __BFP(aa1); /* offset 0x14 */
> + __BFP(rmp1); /* offset 0x18 */
> + __BFP(rml1); /* offset 0x1c */
> + __BFP(mbtif1);/* offset 0x20 */
> + __BFP(mbrif1);/* offset 0x24 */
> + __BFP(mbim1); /* offset 0x28 */
> + __BFP(rfh1); /* offset 0x2c */
> + __BFP(opss1); /* offset 0x30 */
> + u32 __pad1[3];
> + __BFP(mc2); /* offset 0x40 */
^
please remove that space.
> + __BFP(md2); /* offset 0x44 */
> + __BFP(trs2); /* offset 0x48 */
> + __BFP(trr2); /* offset 0x4c */
> + __BFP(ta2); /* offset 0x50 */
> + __BFP(aa2); /* offset 0x54 */
> + __BFP(rmp2); /* offset 0x58 */
> + __BFP(rml2); /* offset 0x5c */
> + __BFP(mbtif2);/* offset 0x60 */
> + __BFP(mbrif2);/* offset 0x64 */
> + __BFP(mbim2); /* offset 0x68 */
> + __BFP(rfh2); /* offset 0x6c */
> + __BFP(opss2); /* offset 0x70 */
> + u32 __pad2[3];
> + __BFP(clock); /* offset 0x80 */
^
same here
> + __BFP(timing);/* offset 0x84 */
> + __BFP(debug); /* offset 0x88 */
> + __BFP(status);/* offset 0x8c */
> + __BFP(cec); /* offset 0x90 */
> + __BFP(gis); /* offset 0x94 */
> + __BFP(gim); /* offset 0x98 */
> + __BFP(gif); /* offset 0x9c */
> + __BFP(control); /* offset 0xa0 */
> + __BFP(intr); /* offset 0xa4 */
> + __BFP(version); /* offset 0xa8 */
> + __BFP(mbtd); /* offset 0xac */
> + __BFP(ewr); /* offset 0xb0 */
> + __BFP(esr); /* offset 0xb4 */
> + u32 __pad3[2];
> + __BFP(ucreg); /* offset 0xc0 */
^
same here
> + __BFP(uccnt); /* offset 0xc4 */
> + __BFP(ucrc); /* offset 0xc8 */
> + __BFP(uccnf); /* offset 0xcc */
> + u32 __pad4[1];
> + __BFP(version2); /* offset 0xd4 */
^
same here
> + u32 __pad5[10];
> +
> + /* channel(mailbox) mask and message registers
> + */
/* single line comment should look like this */
> + struct bfin_can_mask_regs msk[MAX_CHL_NUMBER];/* offset 0x100 */
> + struct bfin_can_channel_regs chl[MAX_CHL_NUMBER]; /* offset 0x200 */
> +};
> +
> +#undef __BFP
> +
> +#define SRS 0x0001 /* Software Reset */
^^^ ^^
single space here probably one tab here
> +#define SER 0x0008 /* Stuff Error */
> +#define BOIM 0x0008 /* Enable Bus Off Interrupt */
> +#define CCR 0x0080 /* CAN Configuration Mode Request */
> +#define
Re: [PATCH -next] drm/nouveau/clk: Use plain "/" for 32-bit division
Hi Alexandre,
On Fri, Feb 6, 2015 at 7:50 AM, Alexandre Courbot wrote:
> On 02/05/2015 01:02 AM, Geert Uytterhoeven wrote:
>> On 32-bit platforms using asm-generic/div64.h:
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function
>> 'gk20a_pllg_calc_rate':
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning:
>> comparison of distinct pointer types lacks a cast
>>do_div(rate, divider);
>>
>> ^
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right
>> shift count >= width of type
>>do_div(rate, divider);
>>^
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing
>> argument 1 of '__div64_32' from incompatible pointer type
>>do_div(rate, divider);
>>
>> ^
>> In file included from arch/parisc/include/generated/asm/div64.h:1:0,
>> from include/linux/kernel.h:124,
>> from include/linux/list.h:8,
>> from include/linux/preempt.h:10,
>> from include/linux/spinlock.h:50,
>> from include/linux/mmzone.h:7,
>> from include/linux/gfp.h:5,
>> from include/linux/slab.h:14,
>> from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
>> from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
>> from
>> drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
>> from
>> drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
>> from
>> drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
>> from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
>> include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but
>> argument is of type 'u32 *'
>> extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
>> ^
>>
>> do_div() is meant for 64-bit by 32-bit division, but both the dividend
>> and divisor are 32-bit here. Hence use plain "/" instead.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> Compile-tested only.
>>
>> parisc/allmodconfig:
>> http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
>> ---
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> index 65c532742b08d1c6..022595876ea4dc85 100644
>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> @@ -144,9 +144,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)
>>
>> rate = priv->parent_rate * priv->n;
>> divider = priv->m * pl_to_div[priv->pl];
>> - do_div(rate, divider);
>>
>> - return rate / 2;
>> + return rate / divider / 2;
>
>
> I agree there is a problem here, but considering the theoretical values that
> rate can take, could we rather fix this by making rate a u64? With the
> current maximum values of priv->parent_rate and priv->n, rate might approach
> dangerously to the u32 limit and I believe casting it to u64 would be safer.
Yes, that's better.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC] kvm: x86: add halt_poll module parameter
On 06/02/2015 00:34, Marcelo Tosatti wrote: > You want at least a basic procedure to estimate a value > (its a function of the device after all). I will add a tracepoint. > Rather than halt_successful_poll's, i suppose the optimum > can be estimated from a dataset containing entries > in the form: > > interrupt time - hlt time > > Then choose a given value from that table. Yes. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Hi Mark, 2015-02-06 3:25 GMT+08:00 Mark Rutland : > On Thu, Feb 05, 2015 at 09:24:36AM +, Bintian Wang wrote: >> Add clock drivers for hi6220 SoC, this driver controls the SoC >> registers to supply different clocks to different IPs in the SoC. >> >> We add one divider clock for hi6220 because the divider in hi6220 >> also has a mask bit but it doesnot obey the rule defined by flag >> "CLK_DIVIDER_HIWORD_MASK", we can not get index of the mask bit by >> left shift fixed bits (e.g. 16 bits), so we add this divider clock >> to handle it. >> >> This patch also enables this clock driver for ARCH_HISI and document >> devicetree bindings. >> >> Signed-off-by: Bintian Wang >> Reviewed-by: Haojian Zhuang >> Reviewed-by: Zhangfei Gao >> --- >> .../devicetree/bindings/clock/hi6220-clock.txt | 30 +++ >> arch/arm64/Kconfig |1 + >> drivers/clk/Kconfig|2 + >> drivers/clk/Makefile |4 +- >> drivers/clk/hisilicon/Kconfig |5 + >> drivers/clk/hisilicon/Makefile |1 + >> drivers/clk/hisilicon/clk-hi6220.c | 284 >> >> drivers/clk/hisilicon/clk.c| 29 ++ >> drivers/clk/hisilicon/clk.h| 17 ++ >> drivers/clk/hisilicon/clkdivider-hi6220.c | 273 >> +++ >> include/dt-bindings/clock/hi6220-clock.h | 172 >> 11 files changed, 815 insertions(+), 3 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt >> create mode 100644 drivers/clk/hisilicon/Kconfig >> create mode 100644 drivers/clk/hisilicon/clk-hi6220.c >> create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c >> create mode 100644 include/dt-bindings/clock/hi6220-clock.h >> >> diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt >> b/Documentation/devicetree/bindings/clock/hi6220-clock.txt >> new file mode 100644 >> index 000..a3ddda1 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt >> @@ -0,0 +1,30 @@ >> +* Hisilicon Hi6220 Clock Controller >> + >> +The hi6220 clock controller generates and supplies clock to various >> +controllers within the hi6220 SoC. >> + >> +Required Properties: >> + >> +- compatible: should be one of the following: >> + - "hisilicon,hi6220-clock-ao" - controller for those clocks under SoC >> + power always on(AO) domain, it is the sub node of SoC power AO >> + controller in dts file. >> + - "hisilicon,hi6220-clock-sys" - controller for those clocks under SoC >> + system control domain, it is the sub node of SoC system controller >> + in dts file. >> + - "hisilicon,hi6220-clock-media" - controller for those clocks under >> + SoC media control domain, it is the sub node of SoC media controller >> + in dts file. >> + - "hisilicon,hi6220-clock-power" - controller for those clocks under >> + SoC power control domain, it is the sub node of SoC power controller >> + in dts file. > > These all refer to things which aren't documented (yet). > > Please sort out your patches so that any documentation you depend on > comes earlier. > > Please also separate documentation from code. Note that dt includes are > _bindings_ and should be added with the relevant documentation. Thanks for help to review, I also think separate documentation from code is better way, it will be fixed in next version. Thanks, Bintian > 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC] video: fbdev: sis: condition with no effect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tormod Volden wrote:
> On Thu, Feb 5, 2015 at 9:45 PM, Scot Doyle wrote:
>> On Wed, 4 Feb 2015, Nicholas Mc Guire wrote:
>>> The if and the else branch code are identical - so the condition has no
>>> effect on the effective code - this patch removes the condition and the
>>> duplicated code.
>>>
>>> Signed-off-by: Nicholas Mc Guire
>>> ---
>>>
>>> This code has been in here since commit 544393fe584d ("sisfb update") so I
>>> guess it is
>>> safe to simply remove the duplicated code if nobody noticed for 10 years.
>>>
>>> Note that the code is not really CodingStyle compliant - the lines inserted
>>> were formatted
>>> to satisfy the coding style but I'm unsure if it is not better to leave it
>>> in the
>>> old format.
>>>
>>> Patch was only compile tested with x86_64_defconfig +
>>> CONFIG_FB_SIS=m, CONFIG_FB_SIS_300=y, CONFIG_FB_SIS_315=y
>>>
>>> Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
>>>
>>> drivers/video/fbdev/sis/init301.c |9 ++---
>>> 1 file changed, 2 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/sis/init301.c
>>> b/drivers/video/fbdev/sis/init301.c
>>> index 295e0de..9533a8ab 100644
>>> --- a/drivers/video/fbdev/sis/init301.c
>>> +++ b/drivers/video/fbdev/sis/init301.c
>>> @@ -7971,13 +7971,8 @@ SiS_SetCHTVReg(struct SiS_Private *SiS_Pr, unsigned
>>> short ModeNo, unsigned short
>>> }
>>>} else { /* PAL
>>> */
>>> /* We don't play around with FSCI in PAL mode */
>>> - if(resindex == 0x04) {
>>> -SiS_SetCH70xxANDOR(SiS_Pr,0x20,0x00,0xEF); /* loop
>>> filter off */
>>> -SiS_SetCH70xxANDOR(SiS_Pr,0x21,0x01,0xFE); /* ACIV on */
>>> - } else {
>>> -SiS_SetCH70xxANDOR(SiS_Pr,0x20,0x00,0xEF); /* loop
>>> filter off */
>>> -SiS_SetCH70xxANDOR(SiS_Pr,0x21,0x01,0xFE); /* ACIV on */
>>> - }
>>> + SiS_SetCH70xxANDOR(SiS_Pr, 0x20, 0x00, 0xEF); /* loop filter off */
>>> + SiS_SetCH70xxANDOR(SiS_Pr, 0x21, 0x01, 0xFE); /* ACIV on */
>>>}
>>>
>>> #endif /* 300 */
>> The code covering the PAL case had this redundancy when it was introduced
>> in Linux 2.4.19.
>>
>> Lines 7934-7981 consider three variables: PAL, overscan, and resindex.
>> Given the "#ifdef 0" block, couldn't the current six sections collapse
>> into two? One for (!PAL && overscan && resindex==5) and another for the
>> rest?
>
> Are we sure there isn't a typo in one of the duplicate clauses? Or
> wrong copy-pasting? Generally I am skeptical to "fixing" code without
> understanding what is behind or testing it, and just cosmetically
> brush over it. For now at least it is obvious that there is something
> wrong. In case (although an unlikely one) someone who understands the
> code and knows this chip comes along, he would quickly spot this.
> After your "fixups" this will be all forgotten. Additionally it adds
> to the impression that this code is being maintained, which is wrong.
>
> I would understand an argument about annoying compiler warnings and
> the like, but in that case I would prefer to #if 0 it instead of
> "prettifying" it.
>
> 0.02
> Tormod
>
The code is partly unfinished due to a lack of hardware to test this
with. SiS announced SiS+Chrontel 7019 combos at some point but I have
never seen one. The code was written based on the Chrontel datasheets,
which weren't clear to some extent, and there wasn't ever any test
hardware. I don't recall this one exactly, but identical if-else
statements mean that one alternative is (assumingly) correct, while the
other is uncertain and/or untested. I left such redunant if-statements
in the code to remember the conditions and the fact that there is a
second alternative.
Considering the long time I'd say it's safe to simplify this.
A word on other changes I monitored recently: Please bear in mind that
with video hardware reading and writing registers is not simple like
reading and writing to memory. Sometimes reading causes an effect in the
hardware as well (latches, etc), so removing seemingly redundant
GetReg/SetReg sequences might actually have an effect.
Regards
Thomas
- --
Thomas Winischhofer
thomas AT winischhofer DOT net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFU1GaUzydIRAktyUcRAuQlAJ9NL3moUDf0yUMbE9qi4L26hT69NwCcDOk2
GyZjN8fic9bITTtdK9OG0R8=
=s9pA
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] tracing: add additional IO tracepoints
Add tracepoints according to IO data stream to trace data propagate
in vfs, fs, block layers.
Signed-off-by: He Kuang
---
block/bio.c| 1 +
block/blk-core.c | 4 +++
drivers/scsi/virtio_scsi.c | 3 ++
fs/ext4/page-io.c | 4 +++
include/trace/events/block.h | 81 ++
include/trace/events/ext4.h| 21 +++
include/trace/events/filemap.h | 25 +
include/trace/events/scsi.h| 21 +++
mm/filemap.c | 2 ++
9 files changed, 162 insertions(+)
diff --git a/block/bio.c b/block/bio.c
index 471d738..208fb63 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1827,6 +1827,7 @@ void bio_endio(struct bio *bio, int error)
} else {
if (bio->bi_end_io)
bio->bi_end_io(bio, error);
+ trace_bio_endio(bio);
bio = NULL;
}
}
diff --git a/block/blk-core.c b/block/blk-core.c
index 30f6153..7a8ceff 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1442,6 +1442,7 @@ bool bio_attempt_back_merge(struct request_queue *q,
struct request *req,
req->ioprio = ioprio_best(req->ioprio, bio_prio(bio));
blk_account_io_start(req, false);
+ trace_bio_attempt_back_merge(req, bio);
return true;
}
@@ -1466,6 +1467,7 @@ bool bio_attempt_front_merge(struct request_queue *q,
struct request *req,
req->ioprio = ioprio_best(req->ioprio, bio_prio(bio));
blk_account_io_start(req, false);
+ trace_bio_attempt_front_merge(req, bio);
return true;
}
@@ -1612,6 +1614,8 @@ get_rq:
* Returns with the queue unlocked.
*/
req = get_request(q, rw_flags, bio, GFP_NOIO);
+ trace_blk_queue_bio(req, bio);
+
if (IS_ERR(req)) {
bio_endio(bio, PTR_ERR(req)); /* @q is dead */
goto out_unlock;
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..9fde3e0 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
#define VIRTIO_SCSI_MEMPOOL_SZ 64
#define VIRTIO_SCSI_EVENT_LEN 8
#define VIRTIO_SCSI_VQ_BASE 2
@@ -464,6 +466,7 @@ static int virtscsi_add_cmd(struct virtqueue *vq,
sgs[out_num + in_num++] = in->sgl;
}
+ trace_virtscsi_add_cmd(vq, sc->request);
return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, GFP_ATOMIC);
}
diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index b24a254..d5b618d 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -31,6 +31,8 @@
#include "xattr.h"
#include "acl.h"
+#include
+
static struct kmem_cache *io_end_cachep;
int __init ext4_init_pageio(void)
@@ -478,6 +480,8 @@ int ext4_bio_write_page(struct ext4_io_submit *io,
redirty_page_for_writepage(wbc, page);
break;
}
+ trace_ext4_bio_write_page(io, page);
+
nr_submitted++;
clear_buffer_dirty(bh);
} while ((bh = bh->b_this_page) != head);
diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index e8a5eca..67b572c 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -667,6 +667,87 @@ TRACE_EVENT(block_rq_remap,
(unsigned long long)__entry->old_sector, __entry->nr_bios)
);
+TRACE_EVENT(blk_queue_bio,
+
+ TP_PROTO(struct request *rq, struct bio* bio),
+
+ TP_ARGS(rq, bio),
+
+ TP_STRUCT__entry(
+ __field( void* ,rq_base )
+ __field( void*, bio_base)
+ ),
+
+ TP_fast_assign(
+ __entry->rq_base = rq;
+ __entry->bio_base = bio;
+ ),
+
+ TP_printk("Node3 bio=%p rq=%p",
+ __entry->bio_base,
+ __entry->rq_base)
+ );
+
+TRACE_EVENT(bio_attempt_back_merge,
+
+ TP_PROTO(struct request *rq, struct bio* bio),
+
+ TP_ARGS(rq, bio),
+
+ TP_STRUCT__entry(
+ __field( void*, rq_base )
+ __field( void*, bio_base)
+ ),
+
+ TP_fast_assign(
+ __entry->rq_base= rq;
+ __entry->bio_base = bio;
+ ),
+
+ TP_printk("Node3 bio=%p rq=%p",
+ __entry->bio_base,
+ __entry->rq_base)
+ );
+
+TRACE_EVENT(bio_attempt_front_merge,
+
+ TP_PROTO(struct request *rq, struct bio* bio),
+
+ TP_ARGS(rq, bio),
+
+ TP_STRUCT__entry(
+ __field( void*, rq_base )
+ __field( void*, bio_base)
+ ),
+
+ TP_fast_assign(
+ __entry->rq_base= rq;
+ __entry->bio_base = bio;
+ ),
+
+ TP_printk("Node3 bio=%p
[RFC 2/2] samples: bpf: IO profiling example
For the first node, we sample and record its characteristic
(eg. address), and add the result to a global hash table. For other
nodes, they'll be traced when their context matches the characteristics
in previous tables.
Signed-off-by: He Kuang
---
samples/bpf/Makefile | 4 +
samples/bpf/tracex5_kern.c | 195 +
samples/bpf/tracex5_user.c | 56 +
3 files changed, 255 insertions(+)
create mode 100644 samples/bpf/tracex5_kern.c
create mode 100644 samples/bpf/tracex5_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index aec1f52..529deb7 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -11,6 +11,7 @@ hostprogs-y += tracex1
hostprogs-y += tracex2
hostprogs-y += tracex3
hostprogs-y += tracex4
+hostprogs-y += tracex5
dropmon-objs := dropmon.o libbpf.o
test_verifier-objs := test_verifier.o libbpf.o
@@ -22,6 +23,7 @@ tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
+tracex5-objs := bpf_load.o libbpf.o tracex5_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -31,6 +33,7 @@ always += tracex1_kern.o
always += tracex2_kern.o
always += tracex3_kern.o
always += tracex4_kern.o
+always += tracex5_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
HOSTCFLAGS += -I$(objtree)/include/uapi/
@@ -43,6 +46,7 @@ HOSTLOADLIBES_tracex1 += -lelf
HOSTLOADLIBES_tracex2 += -lelf
HOSTLOADLIBES_tracex3 += -lelf
HOSTLOADLIBES_tracex4 += -lelf
+HOSTLOADLIBES_tracex5 += -lelf
# point this to your LLVM backend with bpf support
#LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex5_kern.c b/samples/bpf/tracex5_kern.c
new file mode 100644
index 000..67c03b0
--- /dev/null
+++ b/samples/bpf/tracex5_kern.c
@@ -0,0 +1,195 @@
+/*
+ In this example, we placed several nodes in kernel source, all these
+ nodes in the data stream path, and represent the data transfer.
+
+ we sampling on the first node and record the characteristic in it, add
+ to a global hash table, then the next node will be traced when it's
+ context matches the characteristics in previous tables.'
+*/
+#include
+#include
+#include
+#include
+#include "bpf_helpers.h"
+
+#include
+#include
+
+struct globals {
+ int num_samples;
+ int samples;
+};
+
+struct bpf_map_def SEC("maps") global_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(struct globals),
+ .max_entries = 1,
+};
+
+/* trigger table: symbol(page) */
+struct bpf_map_def SEC("maps") trigger_page_hash = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(u64),
+ .value_size = sizeof(int),
+ .max_entries = 512,
+};
+
+/* trigger table: symbol(bio) */
+struct bpf_map_def SEC("maps") trigger_bio_hash = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(u64),
+ .value_size = sizeof(int),
+ .max_entries = 512,
+};
+
+
+/* trigger table symbol(req) */
+struct bpf_map_def SEC("maps") trigger_req_hash = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(u64),
+ .value_size = sizeof(int),
+ .max_entries = 512,
+};
+
+//iov -> page
+SEC("events/filemap/iov_iter_copy_from_user_atomic")
+int node1(struct bpf_context *ctx)
+{
+ int ind = 0;
+ struct globals *g = bpf_map_lookup_elem(_map, );
+
+ if (!g)
+ return 0;
+
+ g->num_samples++;
+ if ((g->num_samples >> 10) * 1024 == g->num_samples) {
+ struct page* page = (struct page*)ctx->arg1;
+ int fill = 1;
+
+ __sync_fetch_and_add(>samples, 1);
+
+ bpf_map_update_elem(_page_hash, , , BPF_ANY);
+
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
+/*
+ ext4.h is not in the include pathes, it's not convenient to fetch
+ struct fields now.
+
+ Though in this example we should avoid this, but if we want to use
+ bio->bi_iter, we should use the struct definition.
+*/
+struct ext4_io_submit {
+ int io_op;
+ struct bio *io_bio;
+};
+
+//page -> bio
+SEC("events/ext4/ext4_bio_write_page")
+int node_2(struct bpf_context *ctx)
+{
+ u64 page_addr = ctx->arg2;
+ struct ext4_io_submit* io = (struct ext4_io_submit*)ctx->arg1;
+ struct bio* bio = bpf_fetch_ptr(>io_bio);
+ void *value;
+ int fill = 1;
+
+ value = bpf_map_lookup_elem(_page_hash, _addr);
+ if (!value)
+ return 0;
+
+ bpf_map_update_elem(_bio_hash, , , BPF_ANY);
+ return 1;
+}
+
+//bio -> rq case1
+SEC("events/block/blk_queue_bio")
+int node_3_1(struct bpf_context *ctx)
+{
+ struct request *request = (struct request*)ctx->arg1;
+ struct bio* bio = (struct bio * )ctx->arg2;
+ void
[RFC 0/2] Experience on full stack profiling using eBPF.
Hi Alexei, We are working on full stack system profiling tools and found your eBPF is an amazing start point for us. However, during our prototype designing and implementing we also found some limitations on it. I'd like to share our experience with you in this mailing list, and I hope you and others can provide comments and suggestions for us. Our goal is to profile production systems by analyzing end-to-end trace of particular procedures, including full IO request through sys_write() system call to underlying disk driver, full network processes through sys_sendto() to NIC driver and even full database query through client initiating to server processing to client finalizing. To avoid heavy tracing overhead and overwhelming data, we randomly sample a few out of huge amounts of procedures, only trace events caused by them at different layers and leave other procedures work normally. As a result, we make as few traces as possible for our profiling with the minimal effect to system performance. In this series of RFC we provide a very rough implementation which traces at different layers for IO processes in a QEMU system. Patch 1/2 deploys some new tracepoints at each layer of IO stack, patch 2/2 attaches eBPF programs on them. eBPF programs select events according to their trigger conditions, and propagate these conditions to eBPF programs at lower layers. We use hash tables to record trigger conditions. Our prototype is able to sample one sys_write() call among all write by a dd command. The result is as follow: dd-985[000] 54878.066046: iov_iter_copy_from_user_atomic: Node1 iov=011c0010 page=ea0001eebb40 ... kworker/ [000] 54886.746406: ext4_bio_write_page: Node2 page=ea0001eebb40 bio=88007c249540 kworker/ [000] 54886.750054: bio_attempt_back_merge: Node3 bio=88007c249540 rq=88007c3d4158 ... kworker/ [000] d... 54886.828480: virtscsi_add_cmd: Node4 req=88007c3d4158 index=2 ... tracex5-9 [000] .Ns. 54886.840415: bio_endio: Node5 bio=88007c249540 The result trace log is less than 20 lines, which will be more than 1 lines without sampling and conditions. We can easily get a graph like this from the above result trace: S1/2/3 are samples. S1S2 S3 | | | (vfs)pagecache -> timeline S1S2 S3 | | | (block)request -> timeline S1S2 S3 | | | bio_end -> timeline During our work we found that eBPF can be improved so we can make our life easier: 1. BPF prog cannot use div/mod operator, which is useful in sampling. 2. BPF is a filter, the output trace goes to trace pipe, sometimes we may need a structured trace output like perf.data, so we can record more in filter function. BPF Array table is a good place to record data, but the index is restricted to 4 byte size. 3. Though most of events are filtered out, the eBPF program attached to tracepoints still run for every execution. We should find a way to minimize performance overhead for those events filtered out. 4. Provide a more user-friendly interface for user to use. Thanks for your work. Signed-off-by: He Kuang He Kuang (2): tracing: add additional IO tracepoints samples: bpf: IO profiling example block/bio.c| 1 + block/blk-core.c | 4 + drivers/scsi/virtio_scsi.c | 3 + fs/ext4/page-io.c | 4 + include/trace/events/block.h | 81 + include/trace/events/ext4.h| 21 + include/trace/events/filemap.h | 25 ++ include/trace/events/scsi.h| 21 + mm/filemap.c | 2 + samples/bpf/Makefile | 4 + samples/bpf/tracex5_kern.c | 195 + samples/bpf/tracex5_user.c | 56 12 files changed, 417 insertions(+) create mode 100644 samples/bpf/tracex5_kern.c create mode 100644 samples/bpf/tracex5_user.c -- 2.2.0.33.gc18b867 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V5 2/3] bfin_can: rewrite the driver into common style with MMU
Hi Marc,
Thanks for your quick review and comments, I've made 3 changes accordingly in
V6. Patches have passed function verification on blackfin board and
scripts/checkpach.pl with 0 error/warning.
Best regards,
Aaron
> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: 2015年2月5日 19:06
> To: Wu, Aaron; w...@grandegger.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-devel
> Subject: Re: [PATCH V5 2/3] bfin_can: rewrite the driver into common style
> with
> MMU
>
> On 02/05/2015 11:44 AM, Aaron Wu wrote:
> > Rewrite the blackfin CAN driver into more common style in three ways:
> > part 1/3: rewrite blackfin style of read/write into common
> > readw/writew part 2/3: introduce ioremap to be compitable with MMU
> > enabled arch part 3/3: merge the header file from the blackfin arch
> > dependent location to driver code directly, note the original copy of
> > more completed bfin_can.h in arch depentdent location is reserved for
> > reg test purpose
> >
> > V5 changes: merge contents of header file into drivere code in patch
> > 3/3
> > V4 changes: remove unused variable in patch 2/3
> > V3 changes: remove redundant cast in patch 2/3
> > V2 changes: split patch into two parts
> > V1 changes: rewrite code into common style
> >
> > Signed-off-by: Aaron Wu
> > ---
> > drivers/net/can/bfin_can.c | 22 --
> > 1 file changed, 8 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
> > index 0a5eff4..0209c14 100644
> > --- a/drivers/net/can/bfin_can.c
> > +++ b/drivers/net/can/bfin_can.c
> > @@ -551,16 +551,10 @@ static int bfin_can_probe(struct platform_device
> *pdev)
> > goto exit;
> > }
> >
> > - if (!request_mem_region(res_mem->start, resource_size(res_mem),
> > - dev_name(>dev))) {
> > - err = -EBUSY;
> > - goto exit;
> > - }
> > -
> > /* request peripheral pins */
> > err = peripheral_request_list(pdata, dev_name(>dev));
> > if (err)
> > - goto exit_mem_release;
> > + goto exit;
> >
> > dev = alloc_bfin_candev();
> > if (!dev) {
> > @@ -569,7 +563,13 @@ static int bfin_can_probe(struct platform_device
> *pdev)
> > }
> >
> > priv = netdev_priv(dev);
> > - priv->membase = (void __iomem *)res_mem->start;
> > +
> > + priv->membase = devm_ioremap_resource(>dev, res_mem);
> > + if (IS_ERR(priv->membase)) {
> > + dev_err(>dev, "Cannot map IO\n");
>
> devm_ioremap_resource() already prints an error message.
>
> Marc
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[RFT/PATCH] Input: bfin_rotary - introduce open and close methods
Introduce open and close methods for the input device to postpone enabling
the device until it is needed.
Signed-off-by: Dmitry Torokhov
---
Hi Sonic,
Could you please tell me if the driver still works with this parch?
Thanks!
drivers/input/misc/bfin_rotary.c | 70
1 file changed, 42 insertions(+), 28 deletions(-)
diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
index 09d7612..1bc9409 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -35,6 +35,10 @@ struct bfin_rot {
unsigned int down_key;
unsigned int button_key;
unsigned int rel_code;
+
+ unsigned short mode;
+ unsigned short debounce;
+
unsigned short cnt_config;
unsigned short cnt_imask;
unsigned short cnt_debounce;
@@ -94,6 +98,35 @@ static irqreturn_t bfin_rotary_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static int bfin_rotary_open(struct input_dev *input)
+{
+ struct bfin_rot *rotary = input_get_drvdata(input);
+ unsigned short val;
+
+ if (rotary->mode & ROT_DEBE)
+ writew(rotary->debounce & DPRESCALE,
+ rotary->base + CNT_DEBOUNCE_OFF);
+
+ writew(rotary->mode & ~CNTE, rotary->base + CNT_CONFIG_OFF);
+
+ val = UCIE | DCIE;
+ if (rotary->button_key)
+ val |= CZMIE;
+ writew(val, rotary->base + CNT_IMASK_OFF);
+
+ writew(rotary->mode | CNTE, rotary->base + CNT_CONFIG_OFF);
+
+ return 0;
+}
+
+static void bfin_rotary_close(struct input_dev *input)
+{
+ struct bfin_rot *rotary = input_get_drvdata(input);
+
+ writew(0, rotary->base + CNT_CONFIG_OFF);
+ writew(0, rotary->base + CNT_IMASK_OFF);
+}
+
static void bfin_rotary_free_action(void *data)
{
peripheral_free_list(data);
@@ -154,6 +187,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
rotary->button_key = pdata->rotary_button_key;
rotary->rel_code = pdata->rotary_rel_code;
+ rotary->mode = pdata->mode;
+ rotary->debounce = pdata->debounce;
+
input->name = pdev->name;
input->phys = "bfin-rotary/input0";
input->dev.parent = >dev;
@@ -165,6 +201,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
input->id.product = 0x0001;
input->id.version = 0x0100;
+ input->open = bfin_rotary_open;
+ input->close = bfin_rotary_close;
+
if (rotary->up_key) {
__set_bit(EV_KEY, input->evbit);
__set_bit(rotary->up_key, input->keybit);
@@ -179,6 +218,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
__set_bit(rotary->button_key, input->keybit);
}
+ /* Quiesce the device before requesting irq */
+ bfin_rotary_close(input);
+
rotary->irq = platform_get_irq(pdev, 0);
if (rotary->irq < 0) {
dev_err(dev, "No rotary IRQ specified\n");
@@ -199,39 +241,12 @@ static int bfin_rotary_probe(struct platform_device *pdev)
return error;
}
- if (pdata->rotary_button_key)
- writew(CZMIE, rotary->base + CNT_IMASK_OFF);
-
- if (pdata->mode & ROT_DEBE)
- writew(pdata->debounce & DPRESCALE,
- rotary->base + CNT_DEBOUNCE_OFF);
-
- if (pdata->mode)
- writew(readw(rotary->base + CNT_CONFIG_OFF) |
- (pdata->mode & ~CNTE),
- rotary->base + CNT_CONFIG_OFF);
-
- writew(readw(rotary->base + CNT_IMASK_OFF) | UCIE | DCIE,
- rotary->base + CNT_IMASK_OFF);
- writew(readw(rotary->base + CNT_CONFIG_OFF) | CNTE,
- rotary->base + CNT_CONFIG_OFF);
-
platform_set_drvdata(pdev, rotary);
device_init_wakeup(>dev, 1);
return 0;
}
-static int bfin_rotary_remove(struct platform_device *pdev)
-{
- struct bfin_rot *rotary = platform_get_drvdata(pdev);
-
- writew(0, rotary->base + CNT_CONFIG_OFF);
- writew(0, rotary->base + CNT_IMASK_OFF);
-
- return 0;
-}
-
static int __maybe_unused bfin_rotary_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -270,7 +285,6 @@ static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
static struct platform_driver bfin_rotary_device_driver = {
.probe = bfin_rotary_probe,
- .remove = bfin_rotary_remove,
.driver = {
.name = "bfin-rotary",
.pm = _rotary_pm_ops,
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] af_packet: don't pass empty blocks for PACKET_V3
On 05.02.2015 23:01:38 +0300 Willem de Bruijn wrote:
On Wed, Feb 4, 2015 at 9:58 PM, Alexander Drozdov wrote:
Don't close an empty block on timeout. Its meaningless to
pass it to the user. Moreover, passing empty blocks wastes
CPU & buffer space increasing probability of packets
dropping on small timeouts.
Side effect of this patch is indefinite user-space wait
in poll on idle links. But, I believe its better to set
timeout for poll(2) when needed than to get empty blocks
every millisecond when not needed.
This change would break existing applications that have come
to depend on the periodic signal.
I don't disagree with the argument that the data ready signal
should be sent only when a block is full or a timer expires and
at least some data is waiting, but that is moot at this point.
I missed something. As pointed by Guy Harris ,
before the previous patch periodic signal was not delivered. The previous patch
(da413eec729dae5dc by Dan Collins ) is for 3.19 kernel
only.
Should we care about existing 3.19-only applications?
Signed-off-by: Alexander Drozdov
---
net/packet/af_packet.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 9cfe2e1..9a2f70a 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -698,6 +698,10 @@ static void prb_retire_rx_blk_timer_expired(unsigned long
data)
if (pkc->last_kactive_blk_num == pkc->kactive_blk_num) {
if (!frozen) {
+ if (!BLOCK_NUM_PKTS(pbd)) {
+ /* An empty block. Just refresh the timer. */
+ goto refresh_timer;
+ }
prb_retire_current_block(pkc, po, TP_STATUS_BLK_TMO);
if (!prb_dispatch_next_block(pkc, po))
goto refresh_timer;
@@ -798,7 +802,11 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
h1->ts_last_pkt.ts_sec = last_pkt->tp_sec;
h1->ts_last_pkt.ts_nsec = last_pkt->tp_nsec;
} else {
- /* Ok, we tmo'd - so get the current time */
+ /* Ok, we tmo'd - so get the current time.
+*
+* It shouldn't really happen as we don't close empty
+* blocks. See prb_retire_rx_blk_timer_expired().
+*/
struct timespec ts;
getnstimeofday();
h1->ts_last_pkt.ts_sec = ts.tv_sec;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: brcm80211: Delete unnecessary checks before two function calls
> From: Markus Elfring > Date: Wed, 4 Feb 2015 20:28:49 +0100 > > The functions brcmu_pkt_buf_free_skb() and usb_free_urb() test whether > their argument is NULL and then return immediately. Thus the test around > the call is not needed. > > Signed-off-by: Markus Elfring Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: hostap: Delete an unnecessary check before the function call "kfree"
> From: Markus Elfring > Date: Wed, 4 Feb 2015 20:06:39 +0100 > > The kfree() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: orinoco: Delete an unnecessary check before the function call "kfree"
> From: Markus Elfring > Date: Wed, 4 Feb 2015 19:53:11 +0100 > > The kfree() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] drm/nouveau/clk: Use plain "/" for 32-bit division
Hi Geert, On 02/05/2015 01:02 AM, Geert Uytterhoeven wrote: On 32-bit platforms using asm-generic/div64.h: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function 'gk20a_pllg_calc_rate': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison of distinct pointer types lacks a cast do_div(rate, divider); ^ drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift count >= width of type do_div(rate, divider); ^ drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing argument 1 of '__div64_32' from incompatible pointer type do_div(rate, divider); ^ In file included from arch/parisc/include/generated/asm/div64.h:1:0, from include/linux/kernel.h:124, from include/linux/list.h:8, from include/linux/preempt.h:10, from include/linux/spinlock.h:50, from include/linux/mmzone.h:7, from include/linux/gfp.h:5, from include/linux/slab.h:14, from drivers/gpu/drm/nouveau/include/nvif/os.h:5, from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3, from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3, from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3, from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3, from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25: include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is of type 'u32 *' extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); ^ do_div() is meant for 64-bit by 32-bit division, but both the dividend and divisor are 32-bit here. Hence use plain "/" instead. Signed-off-by: Geert Uytterhoeven --- Compile-tested only. parisc/allmodconfig: http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/ --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c index 65c532742b08d1c6..022595876ea4dc85 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c @@ -144,9 +144,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv) rate = priv->parent_rate * priv->n; divider = priv->m * pl_to_div[priv->pl]; - do_div(rate, divider); - return rate / 2; + return rate / divider / 2; I agree there is a problem here, but considering the theoretical values that rate can take, could we rather fix this by making rate a u64? With the current maximum values of priv->parent_rate and priv->n, rate might approach dangerously to the u32 limit and I believe casting it to u64 would be safer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ath9k: Delete an unnecessary check before the function call"relay_close"
> From: Markus Elfring > Date: Wed, 4 Feb 2015 18:48:28 +0100 > > The relay_close() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [1/2] cw1200: Delete an unnecessary check before the function call "release_firmware"
> From: Markus Elfring > Date: Wed, 4 Feb 2015 16:32:15 +0100 > > The release_firmware() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks, 2 patches applied to wireless-drivers-next.git: df970d39b90e cw1200: Delete an unnecessary check before the function call "release_firmware" ee4ddad82356 cw1200: Less function calls in cw1200_load_firmware_cw1200() after error detection Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [1/3] orinoco: orinoco_plx use msecs_to_jiffies for conversion
> This is only an API consolidation and should make things more readable > it replaces var * HZ / 1000 by msecs_to_jiffies(var). > > Signed-off-by: Nicholas Mc Guire Thanks, 3 patches applied to wireless-drivers-next.git: ab458cc85fa2 orinoco: orinoco_plx use msecs_to_jiffies for conversion 3427da4597ae orinoco: orinoco_pci use msecs_to_jiffies for conversion c1f1f6663b3c orinoco: orinoco_tmd use msecs_to_jiffies for conversion Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: sched: memory corruption on completing completions
On 02/06/2015 04:27 AM, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso wrote:
It is possible that the paravirt spinlocks could be saved by:
- moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking code.
Ouch, to avoid deadlocks they explicitly need the unlock to occur before
the slowpath tail flag is read.
Well, just make the unlock do the actual real unlock operation
("fastpath"), leaving the TICKET_SLOWPATH_FLAG alone. The unlock path
can *test* the flag and do whatever kicking it needs to get people
started again, but not clear it again.
This is definitely a good idea, will think more on this.
(especially since any remote possibility of forgetting to wake up the
lock-waiter would result in eventual hang of kvm guest).
Hopeful to come up with a solution soon.
/me agreeing with the fact that we did not have the 'lifetime' in mind
during the design :(.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: cw1200: use msecs_to_jiffies for conversion
> This is only an API consolidation to make things more readable. > Instances of HZ / CONST are replaced by appropriate msecs_to_jiffies(). > > Signed-off-by: Nicholas Mc Guire Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] arm64,hi6220: Enable Hisilicon Hi6220 SoC
Hello Olof, 2015-02-06 14:18 GMT+08:00 Olof Johansson : > > On Thu, Feb 5, 2015 at 8:21 PM, Brent Wang wrote: > > Hello Olof and Tyler, > > > > 2015-02-06 7:52 GMT+08:00 Tyler Baker : > >> > >> On 5 February 2015 at 11:02, Olof Johansson wrote: > >> > On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker > >> > wrote: > >> >> Hi Bintian, > >> >> > >> >> On 5 February 2015 at 01:24, Bintian Wang > >> >> wrote: > >> >>> Hello, > >> >>> > >> >>> Hi6220 is one mobile solution of Hisilicon, this patchset contains > >> >>> initial support for Hi6220 SoC and HiKey development board, which > >> >>> is based on ARM Cortex A53 architecture. Initial support is minimal > >> >>> and includes just the arch configuration, clock driver, device tree > >> >>> configuration. > >> >>> > >> >>> Many peripheral drivers will be submitted later. > >> >>> > >> >>> Any comments will be appreciated! > >> >>> > >> >>> Thanks, > >> >>> > >> >>> Bintian Wang (3): > >> >>> arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig > >> >>> clk: hi6220: Clock driver support for Hisilicon hi6220 SoC > >> >>> arm64: dts: Add dts files for Hisilicon Hi6220 SoC > >> >> > >> >> Thanks for posting these! I've applied this series on top of > >> >> next-20150204, however there was some fuzz that needed to be cleaned > >> >> up on 3/3 [1]. I've confirmed the platform is booting to a basic user > >> >> space without issue. > >> > > >> > From ramdisk only, right? > >> > >> Correct, ramdisk only. > >> > >> > Given the timing of the posting of this > >> > patch set, I'm not going to merge it for 3.20. Hopefully for 3.21 > >> > there will be some more peripheral support as well -- at least some > >> > sort of storage device. > >> > >> Seem fair to me. I also hope to see more patches posted shortly. > > > > Yes, the mmc and sd drivers will be submitted soon, should they be included > > in this patchset? I have thought submitting this patch first for review, if > > there > > is no problem for this patchset and then submit other drivers, you know, > > other > > drivers will depend on this patchset. > > > The drivers should ideally not depend on the SoC patchset -- the > driver can go in independently. The DTS updates to specify the > hardware should go in through arm-soc even if the driver itself (and > the binding document update) should go in through the driver subsystem > instead. > > > So, you can choose if you want to post everything as a long series, > and cc different maintainers on the various parts of the series -- or > you can post each driver or subsystem as a patchset on its own and let > that get merged through respective maintainer. The latter is most > common these days. I think the latter is a better way, thank you! > > > > -Olof -- Best Regards, Bintian === Don't be nervous, just be happy! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V6 3/3] bfin_can: move and merge the content of header file into driver body
Header file was in arch dependent location arch/blackfin/include/asm/bfin_can.h,
Now move and merge the useful contents of header file into driver code, note
the original header file is reserved for full register sets access test by other
code so it survives.
Signed-off-by: Aaron Wu
---
drivers/net/can/bfin_can.c | 114 +++-
1 file changed, 113 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index 259d09a..63fab5c 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -20,13 +20,125 @@
#include
#include
-#include
#include
#define DRV_NAME "bfin_can"
#define BFIN_CAN_TIMEOUT 100
#define TX_ECHO_SKB_MAX 1
+/* transmit and receive channels */
+
+#define TRANSMIT_CHL24
+#define RECEIVE_STD_CHL0
+#define RECEIVE_EXT_CHL4
+#define RECEIVE_RTR_CHL8
+#define RECEIVE_EXT_RTR_CHL12
+#define MAX_CHL_NUMBER32
+
+/* All Blackfin system MMRs are padded to 32bits even if the register
+ * itself is only 16bits. So use a helper macro to streamline this
+*/
+#define __BFP(m) u16 m; u16 __pad_##m
+
+ /* bfin can registers layout
+ */
+struct bfin_can_mask_regs {
+ __BFP(aml);
+ __BFP(amh);
+};
+
+struct bfin_can_channel_regs {
+ /* data[0,2,4,6] -> data{0,1,2,3} while data[1,3,5,7] is padding */
+ u16 data[8];
+__BFP(dlc);
+ __BFP(tsv);
+ __BFP(id0);
+ __BFP(id1);
+};
+
+struct bfin_can_regs {
+ /* global control and status registers
+*/
+ __BFP(mc1); /* offset 0x00 */
+ __BFP(md1); /* offset 0x04 */
+ __BFP(trs1); /* offset 0x08 */
+ __BFP(trr1); /* offset 0x0c */
+ __BFP(ta1); /* offset 0x10 */
+ __BFP(aa1); /* offset 0x14 */
+ __BFP(rmp1); /* offset 0x18 */
+ __BFP(rml1); /* offset 0x1c */
+ __BFP(mbtif1);/* offset 0x20 */
+ __BFP(mbrif1);/* offset 0x24 */
+ __BFP(mbim1); /* offset 0x28 */
+ __BFP(rfh1); /* offset 0x2c */
+ __BFP(opss1); /* offset 0x30 */
+ u32 __pad1[3];
+__BFP(mc2); /* offset 0x40 */
+ __BFP(md2); /* offset 0x44 */
+ __BFP(trs2); /* offset 0x48 */
+ __BFP(trr2); /* offset 0x4c */
+ __BFP(ta2); /* offset 0x50 */
+ __BFP(aa2); /* offset 0x54 */
+ __BFP(rmp2); /* offset 0x58 */
+ __BFP(rml2); /* offset 0x5c */
+ __BFP(mbtif2);/* offset 0x60 */
+ __BFP(mbrif2);/* offset 0x64 */
+ __BFP(mbim2); /* offset 0x68 */
+ __BFP(rfh2); /* offset 0x6c */
+ __BFP(opss2); /* offset 0x70 */
+ u32 __pad2[3];
+__BFP(clock); /* offset 0x80 */
+ __BFP(timing);/* offset 0x84 */
+ __BFP(debug); /* offset 0x88 */
+ __BFP(status);/* offset 0x8c */
+ __BFP(cec); /* offset 0x90 */
+ __BFP(gis); /* offset 0x94 */
+ __BFP(gim); /* offset 0x98 */
+ __BFP(gif); /* offset 0x9c */
+ __BFP(control); /* offset 0xa0 */
+ __BFP(intr); /* offset 0xa4 */
+ __BFP(version); /* offset 0xa8 */
+ __BFP(mbtd); /* offset 0xac */
+ __BFP(ewr); /* offset 0xb0 */
+ __BFP(esr); /* offset 0xb4 */
+ u32 __pad3[2];
+__BFP(ucreg); /* offset 0xc0 */
+ __BFP(uccnt); /* offset 0xc4 */
+ __BFP(ucrc); /* offset 0xc8 */
+ __BFP(uccnf); /* offset 0xcc */
+ u32 __pad4[1];
+__BFP(version2); /* offset 0xd4 */
+ u32 __pad5[10];
+
+ /* channel(mailbox) mask and message registers
+*/
+ struct bfin_can_mask_regs msk[MAX_CHL_NUMBER];/* offset 0x100 */
+ struct bfin_can_channel_regs chl[MAX_CHL_NUMBER]; /* offset 0x200 */
+};
+
+#undef __BFP
+
+#define SRS 0x0001 /* Software Reset */
+#define SER 0x0008 /* Stuff Error */
+#define BOIM 0x0008 /* Enable Bus Off Interrupt */
+#define CCR 0x0080 /* CAN Configuration Mode Request */
+#define CCA 0x0080 /* Configuration Mode Acknowledge */
+#define SAM 0x0080 /* Sampling */
+#define AME 0x8000 /* Acceptance Mask Enable */
+#define RMLIM 0x0080 /* Enable RX Message Lost Interrupt */
+#define RMLIS 0x0080 /* RX Message Lost IRQ Status */
+#define RTR 0x4000 /* Remote Frame Transmission Request */
+#define BOIS 0x0008 /* Bus Off IRQ Status */
+#define IDE 0x2000 /* Identifier Extension */
+#define EPIS 0x0004 /* Error-Passive Mode IRQ Status */
+#define EPIM 0x0004 /* Enable
[PATCH V6 1/3] bfin_can: rewrite the blackfin style of read/write to common ones
Replace the blackfin arch dependent style of bfin_read/bfin_write with
common readw/writew
Signed-off-by: Aaron Wu
---
drivers/net/can/bfin_can.c | 126 +---
1 file changed, 60 insertions(+), 66 deletions(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index 417d5099..0a5eff4 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -78,8 +78,8 @@ static int bfin_can_set_bittiming(struct net_device *dev)
if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES)
timing |= SAM;
- bfin_write(>clock, clk);
- bfin_write(>timing, timing);
+ writew(clk, >clock);
+ writew(timing, >timing);
netdev_info(dev, "setting CLOCK=0x%04x TIMING=0x%04x\n", clk, timing);
@@ -94,16 +94,14 @@ static void bfin_can_set_reset_mode(struct net_device *dev)
int i;
/* disable interrupts */
- bfin_write(>mbim1, 0);
- bfin_write(>mbim2, 0);
- bfin_write(>gim, 0);
+ writew(0, >mbim1);
+ writew(0, >mbim2);
+ writew(0, >gim);
/* reset can and enter configuration mode */
- bfin_write(>control, SRS | CCR);
- SSYNC();
- bfin_write(>control, CCR);
- SSYNC();
- while (!(bfin_read(>control) & CCA)) {
+ writew(SRS | CCR, >control);
+ writew(CCR, >control);
+ while (!(readw(>control) & CCA)) {
udelay(10);
if (--timeout == 0) {
netdev_err(dev, "fail to enter configuration mode\n");
@@ -116,34 +114,33 @@ static void bfin_can_set_reset_mode(struct net_device
*dev)
* by writing to CAN Mailbox Configuration Registers 1 and 2
* For all bits: 0 - Mailbox disabled, 1 - Mailbox enabled
*/
- bfin_write(>mc1, 0);
- bfin_write(>mc2, 0);
+ writew(0, >mc1);
+ writew(0, >mc2);
/* Set Mailbox Direction */
- bfin_write(>md1, 0x); /* mailbox 1-16 are RX */
- bfin_write(>md2, 0); /* mailbox 17-32 are TX */
+ writew(0x, >md1); /* mailbox 1-16 are RX */
+ writew(0, >md2); /* mailbox 17-32 are TX */
/* RECEIVE_STD_CHL */
for (i = 0; i < 2; i++) {
- bfin_write(>chl[RECEIVE_STD_CHL + i].id0, 0);
- bfin_write(>chl[RECEIVE_STD_CHL + i].id1, AME);
- bfin_write(>chl[RECEIVE_STD_CHL + i].dlc, 0);
- bfin_write(>msk[RECEIVE_STD_CHL + i].amh, 0x1FFF);
- bfin_write(>msk[RECEIVE_STD_CHL + i].aml, 0x);
+ writew(0, >chl[RECEIVE_STD_CHL + i].id0);
+ writew(AME, >chl[RECEIVE_STD_CHL + i].id1);
+ writew(0, >chl[RECEIVE_STD_CHL + i].dlc);
+ writew(0x1FFF, >msk[RECEIVE_STD_CHL + i].amh);
+ writew(0x, >msk[RECEIVE_STD_CHL + i].aml);
}
/* RECEIVE_EXT_CHL */
for (i = 0; i < 2; i++) {
- bfin_write(>chl[RECEIVE_EXT_CHL + i].id0, 0);
- bfin_write(>chl[RECEIVE_EXT_CHL + i].id1, AME | IDE);
- bfin_write(>chl[RECEIVE_EXT_CHL + i].dlc, 0);
- bfin_write(>msk[RECEIVE_EXT_CHL + i].amh, 0x1FFF);
- bfin_write(>msk[RECEIVE_EXT_CHL + i].aml, 0x);
+ writew(0, >chl[RECEIVE_EXT_CHL + i].id0);
+ writew(AME | IDE, >chl[RECEIVE_EXT_CHL + i].id1);
+ writew(0, >chl[RECEIVE_EXT_CHL + i].dlc);
+ writew(0x1FFF, >msk[RECEIVE_EXT_CHL + i].amh);
+ writew(0x, >msk[RECEIVE_EXT_CHL + i].aml);
}
- bfin_write(>mc2, BIT(TRANSMIT_CHL - 16));
- bfin_write(>mc1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
- SSYNC();
+ writew(BIT(TRANSMIT_CHL - 16), >mc2);
+ writew(BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL), >mc1);
priv->can.state = CAN_STATE_STOPPED;
}
@@ -157,9 +154,9 @@ static void bfin_can_set_normal_mode(struct net_device *dev)
/*
* leave configuration mode
*/
- bfin_write(>control, bfin_read(>control) & ~CCR);
+ writew(readw(>control) & ~CCR, >control);
- while (bfin_read(>status) & CCA) {
+ while (readw(>status) & CCA) {
udelay(10);
if (--timeout == 0) {
netdev_err(dev, "fail to leave configuration mode\n");
@@ -170,26 +167,25 @@ static void bfin_can_set_normal_mode(struct net_device
*dev)
/*
* clear _All_ tx and rx interrupts
*/
- bfin_write(>mbtif1, 0x);
- bfin_write(>mbtif2, 0x);
- bfin_write(>mbrif1, 0x);
- bfin_write(>mbrif2, 0x);
+ writew(0x, >mbtif1);
+ writew(0x, >mbtif2);
+ writew(0x, >mbrif1);
+ writew(0x, >mbrif2);
/*
* clear global interrupt status register
*/
- bfin_write(>gis, 0x7FF); /* overwrites with '1' */
+ writew(0x7FF, >gis); /* overwrites with '1' */
[PATCH V6 2/3] bfin_can: introduce ioremap to comply to the arch with MMU
Blackfin was built without MMU, old driver code access the IO space by
physical address, introduce the ioremap approach to be compitable with
the common style supporting MMU enabled arch.
Signed-off-by: Aaron Wu
---
drivers/net/can/bfin_can.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index 0a5eff4..259d09a 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -551,16 +551,10 @@ static int bfin_can_probe(struct platform_device *pdev)
goto exit;
}
- if (!request_mem_region(res_mem->start, resource_size(res_mem),
- dev_name(>dev))) {
- err = -EBUSY;
- goto exit;
- }
-
/* request peripheral pins */
err = peripheral_request_list(pdata, dev_name(>dev));
if (err)
- goto exit_mem_release;
+ goto exit;
dev = alloc_bfin_candev();
if (!dev) {
@@ -569,7 +563,13 @@ static int bfin_can_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
- priv->membase = (void __iomem *)res_mem->start;
+
+ priv->membase = devm_ioremap_resource(>dev, res_mem);
+ if (IS_ERR(priv->membase)) {
+ err = PTR_ERR(priv->membase);
+ goto exit_peri_pin_free;
+ }
+
priv->rx_irq = rx_irq->start;
priv->tx_irq = tx_irq->start;
priv->err_irq = err_irq->start;
@@ -601,8 +601,6 @@ exit_candev_free:
free_candev(dev);
exit_peri_pin_free:
peripheral_free_list(pdata);
-exit_mem_release:
- release_mem_region(res_mem->start, resource_size(res_mem));
exit:
return err;
}
@@ -611,15 +609,11 @@ static int bfin_can_remove(struct platform_device *pdev)
{
struct net_device *dev = platform_get_drvdata(pdev);
struct bfin_can_priv *priv = netdev_priv(dev);
- struct resource *res;
bfin_can_set_reset_mode(dev);
unregister_candev(dev);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, resource_size(res));
-
peripheral_free_list(priv->pin_list);
free_candev(dev);
--
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 2/2] f2fs: don't discard next free dnode page for an umount checkpoint
Hi Chao,
On Thu, Feb 05, 2015 at 04:16:04PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Tuesday, February 03, 2015 7:38 AM
> > To: Chao Yu
> > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 2/2] f2fs: don't discard next free dnode page for an
> > umount checkpoint
> >
> > Hi Chao,
> >
> > On Sat, Jan 31, 2015 at 05:06:59PM +0800, Chao Yu wrote:
> > > Previously, discard_next_dnode is added before a checkpoint to prevent
> > > that we
> > > may meet a garbage dnode page readed from next free blkaddr in recover
> > > flow.
> > >
> > > Since f2fs will skip recovery flow for a clean umount image, this
> > > condition will
> > > never happen.
> > >
> > > So it's safe for us to leave next free dnode as it is in an umount
> > > checkpoint.
> > >
> > > Signed-off-by: Chao Yu
> > > ---
> > > fs/f2fs/checkpoint.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > > index f7cdcad..991fd0a 100644
> > > --- a/fs/f2fs/checkpoint.c
> > > +++ b/fs/f2fs/checkpoint.c
> > > @@ -905,8 +905,12 @@ static void do_checkpoint(struct f2fs_sb_info *sbi,
> > > struct cp_control
> > *cpc)
> > > /*
> > >* This avoids to conduct wrong roll-forward operations and uses
> > >* metapages, so should be called prior to sync_meta_pages below.
> > > + * But if we are in an umount checkpoint, we'd better skip this
> > > + * because we will not enter recovery flow to use the next free
> > > + * blkaddr when mounting it.
> > >*/
> > > - discard_next_dnode(sbi, NEXT_FREE_BLKADDR(sbi, curseg));
> > > + if (cpc->reason != CP_UMOUNT)
> > > + discard_next_dnode(sbi, NEXT_FREE_BLKADDR(sbi, curseg));
> >
> > The reason for discard_next_dnode is to avoid wrong execution due to old
> > mkfs.f2fs which remains gabage data.
> > It needs to do all the time.
>
> Maybe my previously understanding is wrong.
>
> Is this issue due to old mkfs.f2fs do not discard entire flash storage device
> when formating? Or another bug of mkfs? If so, can you please offer a fix
> commit id of mkfs?
commit ffbada4298c7aed059bb99a8d553d6dd555963c0
Author: Jaegeuk Kim
Date: Mon Nov 11 13:29:11 2013 +0900
mkfs: remove stale node blocks
If the device does not support discard, we should write zero blocks
to avoid roll-forward recovery.
Thanks,
>
> I'm curious about how this happened. :-)
>
> Thanks,
> >
> > Thanks,
> >
> > >
> > > /* Flush all the NAT/SIT pages */
> > > while (get_pages(sbi, F2FS_DIRTY_META)) {
> > > --
> > > 2.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: [PATCH 0/3] arm64,hi6220: Enable Hisilicon Hi6220 SoC
On Thu, Feb 5, 2015 at 8:21 PM, Brent Wang wrote: > Hello Olof and Tyler, > > 2015-02-06 7:52 GMT+08:00 Tyler Baker : >> >> On 5 February 2015 at 11:02, Olof Johansson wrote: >> > On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker >> > wrote: >> >> Hi Bintian, >> >> >> >> On 5 February 2015 at 01:24, Bintian Wang >> >> wrote: >> >>> Hello, >> >>> >> >>> Hi6220 is one mobile solution of Hisilicon, this patchset contains >> >>> initial support for Hi6220 SoC and HiKey development board, which >> >>> is based on ARM Cortex A53 architecture. Initial support is minimal >> >>> and includes just the arch configuration, clock driver, device tree >> >>> configuration. >> >>> >> >>> Many peripheral drivers will be submitted later. >> >>> >> >>> Any comments will be appreciated! >> >>> >> >>> Thanks, >> >>> >> >>> Bintian Wang (3): >> >>> arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig >> >>> clk: hi6220: Clock driver support for Hisilicon hi6220 SoC >> >>> arm64: dts: Add dts files for Hisilicon Hi6220 SoC >> >> >> >> Thanks for posting these! I've applied this series on top of >> >> next-20150204, however there was some fuzz that needed to be cleaned >> >> up on 3/3 [1]. I've confirmed the platform is booting to a basic user >> >> space without issue. >> > >> > From ramdisk only, right? >> >> Correct, ramdisk only. >> >> > Given the timing of the posting of this >> > patch set, I'm not going to merge it for 3.20. Hopefully for 3.21 >> > there will be some more peripheral support as well -- at least some >> > sort of storage device. >> >> Seem fair to me. I also hope to see more patches posted shortly. > > Yes, the mmc and sd drivers will be submitted soon, should they be included > in this patchset? I have thought submitting this patch first for review, if > there > is no problem for this patchset and then submit other drivers, you know, > other > drivers will depend on this patchset. The drivers should ideally not depend on the SoC patchset -- the driver can go in independently. The DTS updates to specify the hardware should go in through arm-soc even if the driver itself (and the binding document update) should go in through the driver subsystem instead. So, you can choose if you want to post everything as a long series, and cc different maintainers on the various parts of the series -- or you can post each driver or subsystem as a patchset on its own and let that get merged through respective maintainer. The latter is most common these days. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH 5/5 v4] f2fs: introduce a batched trim
Hi Chao,
Something like this?
Change log from v3:
o align to section size
This patch introduces a batched trimming feature, which submits split discard
commands.
This is to avoid long latency due to huge trim commands.
If fstrim was triggered ranging from 0 to the end of device, we should lock
all the checkpoint-related mutexes, resulting in very long latency.
Signed-off-by: Jaegeuk Kim
---
Documentation/ABI/testing/sysfs-fs-f2fs | 6 ++
Documentation/filesystems/f2fs.txt | 4
fs/f2fs/f2fs.h | 7 +++
fs/f2fs/segment.c | 17 -
fs/f2fs/super.c | 2 ++
5 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 6f9157f..2c4cc42 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -74,3 +74,9 @@ Date: March 2014
Contact: "Jaegeuk Kim"
Description:
Controls the memory footprint used by f2fs.
+
+What: /sys/fs/f2fs//trim_sections
+Date: February 2015
+Contact: "Jaegeuk Kim"
+Description:
+Controls the trimming rate in batch mode.
diff --git a/Documentation/filesystems/f2fs.txt
b/Documentation/filesystems/f2fs.txt
index 6758aa3..dac11d7 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -199,6 +199,10 @@ Files in /sys/fs/f2fs/
checkpoint is triggered, and issued during the
checkpoint. By default, it is disabled with 0.
+ trim_sectionsThis parameter controls the number of sections
+ to be trimmed out in batch mode when FITRIM
+ conducts. 32 sections is set by default.
+
ipu_policy This parameter controls the policy of in-place
updates in f2fs. There are five policies:
0x01: F2FS_IPU_FORCE, 0x02: F2FS_IPU_SSR,
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index db1ff55..d82a10a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -105,6 +105,10 @@ enum {
CP_DISCARD,
};
+#define DEF_BATCHED_TRIM_SECTIONS 32
+#define BATCHED_TRIM_SEGMENTS(sbi) \
+ (SM_I(sbi)->trim_sections * (sbi)->segs_per_sec)
+
struct cp_control {
int reason;
__u64 trim_start;
@@ -448,6 +452,9 @@ struct f2fs_sm_info {
int nr_discards;/* # of discards in the list */
int max_discards; /* max. discards to be issued */
+ /* for batched trimming */
+ int trim_sections; /* # of sections to trim */
+
struct list_head sit_entry_set; /* sit entry set list */
unsigned int ipu_policy;/* in-place-update policy */
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 5ea57ec..9f278d1 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1066,14 +1066,19 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct
fstrim_range *range)
end_segno = (end >= MAX_BLKADDR(sbi)) ? MAIN_SEGS(sbi) - 1 :
GET_SEGNO(sbi, end);
cpc.reason = CP_DISCARD;
- cpc.trim_start = start_segno;
- cpc.trim_end = end_segno;
cpc.trim_minlen = range->minlen >> sbi->log_blocksize;
/* do checkpoint to issue discard commands safely */
- mutex_lock(>gc_mutex);
- write_checkpoint(sbi, );
- mutex_unlock(>gc_mutex);
+ for (; start_segno <= end_segno; start_segno = cpc.trim_end + 1) {
+ cpc.trim_start = start_segno;
+ cpc.trim_end = min_t(unsigned int, rounddown(start_segno +
+ BATCHED_TRIM_SEGMENTS(sbi),
+ sbi->segs_per_sec) - 1, end_segno);
+
+ mutex_lock(>gc_mutex);
+ write_checkpoint(sbi, );
+ mutex_unlock(>gc_mutex);
+ }
out:
range->len = cpc.trimmed << sbi->log_blocksize;
return 0;
@@ -2127,6 +2132,8 @@ int build_segment_manager(struct f2fs_sb_info *sbi)
sm_info->nr_discards = 0;
sm_info->max_discards = 0;
+ sm_info->trim_sections = DEF_BATCHED_TRIM_SECTIONS;
+
INIT_LIST_HEAD(_info->sit_entry_set);
if (test_opt(sbi, FLUSH_MERGE) && !f2fs_readonly(sbi->sb)) {
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 1e92c2e..f2fe666 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -195,6 +195,7 @@ F2FS_RW_ATTR(GC_THREAD, f2fs_gc_kthread,
gc_no_gc_sleep_time, no_gc_sleep_time);
F2FS_RW_ATTR(GC_THREAD, f2fs_gc_kthread, gc_idle, gc_idle);
F2FS_RW_ATTR(SM_INFO, f2fs_sm_info, reclaim_segments, rec_prefree_segments);
F2FS_RW_ATTR(SM_INFO, f2fs_sm_info, max_small_discards, max_discards);
+F2FS_RW_ATTR(SM_INFO, f2fs_sm_info,
[PATCH] edac: fix memory leaks on failure path in edac_init()
edac_init() does not deallocate already allocated resources on failure path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/edac/edac_module.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/edac_module.c b/drivers/edac/edac_module.c
index e6d1691dfa45..a256dcb31d03 100644
--- a/drivers/edac/edac_module.c
+++ b/drivers/edac/edac_module.c
@@ -112,7 +112,7 @@ static int __init edac_init(void)
err = edac_mc_sysfs_init();
if (err)
- goto error;
+ goto err_sysfs;
edac_debugfs_init();
@@ -120,12 +120,15 @@ static int __init edac_init(void)
err = edac_workqueue_setup();
if (err) {
edac_printk(KERN_ERR, EDAC_MC, "init WorkQueue failure\n");
- goto error;
+ goto err_wq;
}
return 0;
-error:
+err_wq:
+ edac_debugfs_exit();
+ edac_mc_sysfs_exit();
+err_sysfs:
return err;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: bfin_rotary - mark suspend and resume code as __maybe_unused
Instead of using #ifdef to guard potentially unused suspend and resume code
let's mark them as __maybe_unused so they still get discarded if they are
not used but we do not get warning. This allows for better compile coverage.
Signed-off-by: Dmitry Torokhov
---
drivers/input/misc/bfin_rotary.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
index a39793c..09d7612 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -232,8 +232,7 @@ static int bfin_rotary_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int bfin_rotary_suspend(struct device *dev)
+static int __maybe_unused bfin_rotary_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct bfin_rot *rotary = platform_get_drvdata(pdev);
@@ -248,7 +247,7 @@ static int bfin_rotary_suspend(struct device *dev)
return 0;
}
-static int bfin_rotary_resume(struct device *dev)
+static int __maybe_unused bfin_rotary_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct bfin_rot *rotary = platform_get_drvdata(pdev);
@@ -266,20 +265,15 @@ static int bfin_rotary_resume(struct device *dev)
return 0;
}
-static const struct dev_pm_ops bfin_rotary_pm_ops = {
- .suspend= bfin_rotary_suspend,
- .resume = bfin_rotary_resume,
-};
-#endif
+static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
+bfin_rotary_suspend, bfin_rotary_resume);
static struct platform_driver bfin_rotary_device_driver = {
.probe = bfin_rotary_probe,
.remove = bfin_rotary_remove,
.driver = {
.name = "bfin-rotary",
-#ifdef CONFIG_PM
.pm = _rotary_pm_ops,
-#endif
},
};
module_platform_driver(bfin_rotary_device_driver);
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cifs: smb2_clone_range() - exit on unhandled error
Merged into cifs-2.6.git On Wed, Feb 4, 2015 at 7:10 AM, Sachin Prabhu wrote: > While attempting to clone a file on a samba server, we receive a > STATUS_INVALID_DEVICE_REQUEST. This is mapped to -EOPNOTSUPP which > isn't handled in smb2_clone_range(). We end up looping in the while loop > making same call to the samba server over and over again. > > The proposed fix is to exit and return the error value when encountered > with an unhandled error. > > Cc: > Signed-off-by: Sachin Prabhu > --- > fs/cifs/smb2ops.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c > index 96b5d40..eab05e1 100644 > --- a/fs/cifs/smb2ops.c > +++ b/fs/cifs/smb2ops.c > @@ -684,7 +684,8 @@ smb2_clone_range(const unsigned int xid, > > /* No need to change MaxChunks since already set to 1 > */ > chunk_sizes_updated = true; > - } > + } else > + goto cchunk_out; > } > > cchunk_out: > -- > 2.1.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] efi, x86: Add a "debug" option to the efi= cmdline
On Thu, Feb 05, 2015 at 08:28:58AM -0600, Borislav Petkov wrote: > On Thu, Feb 05, 2015 at 07:45:10AM -0500, Parmeshwr Prasad wrote: > > It is better if we add some printk from efifb messages. > > Please review the below patch. > > First of all, we saw you patch. > > Then, > > > From 7fbac896ab87f1b37646ac2f49bb8216ec330642 Mon Sep 17 00:00:00 2001 > > From: Parmeshwr Prasad > > Date: Wed, 4 Feb 2015 06:50:32 -0500 > > Subject: [PATCH] efi, x86: Add a debug option to the efi= cmdline > > yours has the same Subject as mine. This is not how we do patches. > Consult Documentation/SubmittingPatches about how to do them properly. > > What is more, your patch doesn't have a commit message. But it needs one. > > Fix all that, send it as a *separate* patch after mine has been applied > and people will take a look then. I am really sorry that I could not mentioned for what purpose this patch is . I wanted this patch to be included along with your patch. As your patch is To add “debug” cmdline in efi=””. There are some messages in efifb which appears while booting. I thought of Putting that messages under efi=”debug” cmdline. When efi=debug is given Then only efifb messages should appear. > > > > > Signed-off-by: Parmeshwr Prasad > > --- > > drivers/video/fbdev/efifb.c | 49 > > + > > 1 file changed, 27 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > > index 4bfff34..505bc56 100644 > > --- a/drivers/video/fbdev/efifb.c > > +++ b/drivers/video/fbdev/efifb.c > > @@ -145,7 +145,8 @@ static int efifb_probe(struct platform_device *dev) > > printk(KERN_DEBUG "efifb: invalid framebuffer address\n"); > > return -ENODEV; > > } > > - printk(KERN_INFO "efifb: probing for efifb\n"); > > + if (efi_enabled(EFI_DBG)) > > + printk(KERN_INFO "efifb: probing for efifb\n"); > > If we're going to use the "efifb" prefix, change those to pr_info and > define pr_fmt - lotsa examples in the kernel sources. > > More importantly, you'd need a consensus from people that the printks in > efifb are really not interesting and should be behind efi=debug. > > HTH. > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > -- > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" 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 v17 1/7] mm: support madvise(MADV_FREE)
Hi Shaohua, On Thu, Feb 05, 2015 at 04:33:11PM -0800, Shaohua Li wrote: > > Hi Minchan, > > Sorry to jump in this thread so later, and if some issues are discussed > before. > I'm interesting in this patch, so tried it here. I use a simple test with No problem at all. Interest is always win over ignorance. > jemalloc. Obviously this can improve performance when there is no memory > pressure. Did you try setup with memory pressure? Sure but it was not a huge memory system like yours. > > In my test, jemalloc will map 61G vma, and use about 32G memory without > MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because > madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely. > slightly to make it work without swap), I got oom. If swap is enabled, my You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging. > system is totally stalled because of swap activity. Without the MADV_FREE, > everything is ok. Considering we definitely don't want to waste too much > memory, a system with memory pressure is normal, so sounds MADV_FREE will > introduce big trouble here. > > Did you think about move the MADV_FREE pages to the head of inactive LRU, so > they can be reclaimed easily? I think it's desirable if the page lived in active LRU. The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind. In last LSF/MM, there was concern about data's hotness. Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example. The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later. However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict. In summary, I like your suggestion. Thanks. > > Thanks, > Shaohua > > On Wed, Feb 04, 2015 at 08:47:22AM +0900, Minchan Kim wrote: > > Hello, Michael > > > > On Tue, Feb 03, 2015 at 05:39:24PM +0100, Michael Kerrisk (man-pages) wrote: > > > Hello Minchan (and Michal) > > > > > > I did not see this patch until just now when Michael explicitly > > > mentioned it in another discussion because > > > (a) it was buried in an LMKL thread that started a topic > > > that was not about a man-pages patch. > > > (b) linux-man@ was not CCed. > > > > Sorry about that. > > > > > > > > When resubmitting this patch, could you please To:me and CC linux-man@ > > > and give the mail a suitable subject line indicating a man-pages patch. > > > > Sure. > > > > > > > > On 12/05/2014 09:32 AM, Michal Hocko wrote: > > > > On Fri 05-12-14 16:08:16, Minchan Kim wrote: > > > > [...] > > > >> From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001 > > > >> From: Minchan Kim > > > >> Date: Mon, 1 Dec 2014 08:53:55 +0900 > > > >> Subject: [PATCH] madvise.2: Document MADV_FREE > > > >> > > > >> Signed-off-by: Minchan Kim > > > > > > > > Reviewed-by: Michal Hocko > > > > > > > > Thanks! > > > > > > > >> --- > > > >> man2/madvise.2 | 12 > > > >> 1 file changed, 12 insertions(+) > > > >> > > > >> diff --git a/man2/madvise.2 b/man2/madvise.2 > > > >> index 032ead7..fc1aaca 100644 > > > >> --- a/man2/madvise.2 > > > >> +++ b/man2/madvise.2 > > > >> @@ -265,6 +265,18 @@ file (see > > > >> .BR MADV_DODUMP " (since Linux 3.4)" > > > >> Undo the effect of an earlier > > > >> .BR MADV_DONTDUMP . > > > >> +.TP > > > >> +.BR MADV_FREE " (since Linux 3.19)" > > > >> +Tell the kernel that contents in the specified address range are no > > > >> +longer important and the range will be overwritten. When there is > > > >> +demand for memory, the system will free pages associated with the > > > >> +specified address range. In this instance, the next time a page in the > > > >> +address range is referenced, it will contain all zeroes. Otherwise, > > > >> +it will contain the data that was there prior to the MADV_FREE call. > > > >> +References made to the address range will not make the system read > > >
Re: [PATCH] dma: mmp-pdma: fix irq handler overwrite physical chan issue
On 4 February 2015 at 14:16, Qiao Zhou wrote: > Some dma channels may be reserved for other purpose in other layer, > like secure driver in EL2/EL3. PDMA driver can see the interrupt > status, but it should not try to handle related interrupt, since it > doesn't belong to PDMA driver in kernel. These interrupts should be > handled by corresponding client/module.Otherwise, it will overwrite > illegal memory and cause unexpected issues, since pdma driver only > requests resources for pdma channels. > > In PDMA driver, the reserved channels are at the end of total 32 > channels. If we find interrupt bit index is not smaller than total > dma channels, we should ignore it. > > Signed-off-by: Qiao Zhou Acked-by: Zhangfei Gao Thanks for the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] Fix power domains handling on exynos542x
Hi, On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote: > Hello Andrzej, > > Thanks a lot for finally finding what was causing the HDMI issue. > > On 02/05/2015 01:35 PM, Andrzej Hajda wrote: >> Hi, >> >> Exynos chipsets since 542x have asynchronous bridges connecting different >> IPs. >> These bridges should be operational during power domain switching, ie >> associated >> clocks cannot be gated. >> This patchset adds binding to provide such clocks per power domain and adds >> code >> which enables them during domain on/off operation. >> >> This patchset fixes power domain issues with disp1 domain and HDMI (some of >> them) >> on Odroid XU3: >> - disp1 power domain can be turned off, >> - no more "imprecise external abort" faults. >> >> The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos >> platforms' [1]. >> > > It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2]. > >> It was successfully tested on OdroidXU3. >> >> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743 > > Your patches looks good to me so please feel free to add: > > Reviewed-by: Javier Martinez Canillas > > I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power > domain power-domain disable failed" message and the system crash are gone. > Really gone out "Power domain power-domain disable failed" message? Still i get the message from second try, # modetest -M exynos -s 23@21:1920x1080 setting mode 1920x1080@XR24 on connectors 23, crtc 21 # modetest -M exynos -s 23@21:1920x1080 setting mode 1920x1080@XR24 on connectors 23, crtc 21 [ 39.608881] Power domain power-domain disable failed # modetest -M exynos -s 23@21:1920x1080 setting mode 1920x1080@XR24 on connectors 23, crtc 21 [ 42.827637] Power domain power-domain disable failed ... Thanks. > Tested-by: Javier Martinez Canillas > > Best regards, > Javier > > [2]: https://lkml.org/lkml/2015/1/20/235 > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/29] lguest: have --rng read from /dev/urandom not /dev/random.
Theoretical debates aside, now it boots.
Signed-off-by: Rusty Russell
---
tools/lguest/lguest.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c
index 32cf2ce15d69..3f7f2326cd9a 100644
--- a/tools/lguest/lguest.c
+++ b/tools/lguest/lguest.c
@@ -1733,9 +1733,9 @@ static void setup_block_file(const char *filename)
}
/*L:211
- * Our random number generator device reads from /dev/random into the Guest's
+ * Our random number generator device reads from /dev/urandom into the Guest's
* input buffers. The usual case is that the Guest doesn't want random numbers
- * and so has no buffers although /dev/random is still readable, whereas
+ * and so has no buffers although /dev/urandom is still readable, whereas
* console is the reverse.
*
* The same logic applies, however.
@@ -1763,7 +1763,7 @@ static void rng_input(struct virtqueue *vq)
while (!iov_empty(iov, in_num)) {
len = readv(rng_info->rfd, iov, in_num);
if (len <= 0)
- err(1, "Read from /dev/random gave %i", len);
+ err(1, "Read from /dev/urandom gave %i", len);
iov_consume(iov, in_num, NULL, len);
totlen += len;
}
@@ -1780,8 +1780,8 @@ static void setup_rng(void)
struct device *dev;
struct rng_info *rng_info = malloc(sizeof(*rng_info));
- /* Our device's privat info simply contains the /dev/random fd. */
- rng_info->rfd = open_or_die("/dev/random", O_RDONLY);
+ /* Our device's private info simply contains the /dev/urandom fd. */
+ rng_info->rfd = open_or_die("/dev/urandom", O_RDONLY);
/* Create the new device. */
dev = new_device("rng", VIRTIO_ID_RNG);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/29] lguest: write more information to userspace about pending traps.
This is preparation for userspace handling MMIO and ioport accesses.
Signed-off-by: Rusty Russell
---
drivers/lguest/core.c | 7 ---
drivers/lguest/hypercalls.c | 7 ---
drivers/lguest/lg.h | 3 ++-
drivers/lguest/lguest_user.c| 14 +-
include/linux/lguest_launcher.h | 13 +
tools/lguest/lguest.c | 16 ++--
6 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index cdb2f9aa5860..9159dbc583f6 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -229,16 +229,17 @@ int run_guest(struct lg_cpu *cpu, unsigned long __user
*user)
* It's possible the Guest did a NOTIFY hypercall to the
* Launcher.
*/
- if (cpu->pending_notify) {
+ if (cpu->pending.trap) {
/*
* Does it just needs to write to a registered
* eventfd (ie. the appropriate virtqueue thread)?
*/
if (!send_notify_to_eventfd(cpu)) {
/* OK, we tell the main Launcher. */
- if (put_user(cpu->pending_notify, user))
+ if (copy_to_user(user, >pending,
+sizeof(cpu->pending)))
return -EFAULT;
- return sizeof(cpu->pending_notify);
+ return sizeof(cpu->pending);
}
}
diff --git a/drivers/lguest/hypercalls.c b/drivers/lguest/hypercalls.c
index 83511eb0923d..5dd1fb8a6610 100644
--- a/drivers/lguest/hypercalls.c
+++ b/drivers/lguest/hypercalls.c
@@ -118,7 +118,8 @@ static void do_hcall(struct lg_cpu *cpu, struct hcall_args
*args)
cpu->halted = 1;
break;
case LHCALL_NOTIFY:
- cpu->pending_notify = args->arg1;
+ cpu->pending.trap = LGUEST_TRAP_ENTRY;
+ cpu->pending.addr = args->arg1;
break;
default:
/* It should be an architecture-specific hypercall. */
@@ -189,7 +190,7 @@ static void do_async_hcalls(struct lg_cpu *cpu)
* Stop doing hypercalls if they want to notify the Launcher:
* it needs to service this first.
*/
- if (cpu->pending_notify)
+ if (cpu->pending.trap)
break;
}
}
@@ -280,7 +281,7 @@ void do_hypercalls(struct lg_cpu *cpu)
* NOTIFY to the Launcher, we want to return now. Otherwise we do
* the hypercall.
*/
- if (!cpu->pending_notify) {
+ if (!cpu->pending.trap) {
do_hcall(cpu, cpu->hcall);
/*
* Tricky point: we reset the hcall pointer to mark the
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
index 1c98bf74fd68..020fec5bb072 100644
--- a/drivers/lguest/lg.h
+++ b/drivers/lguest/lg.h
@@ -50,7 +50,8 @@ struct lg_cpu {
/* Bitmap of what has changed: see CHANGED_* above. */
int changed;
- unsigned long pending_notify; /* pfn from LHCALL_NOTIFY */
+ /* Pending operation. */
+ struct lguest_pending pending;
unsigned long *reg_read; /* register from LHREQ_GETREG */
diff --git a/drivers/lguest/lguest_user.c b/drivers/lguest/lguest_user.c
index 7f14c152dd23..dcf9efd94cf4 100644
--- a/drivers/lguest/lguest_user.c
+++ b/drivers/lguest/lguest_user.c
@@ -29,6 +29,10 @@ bool send_notify_to_eventfd(struct lg_cpu *cpu)
unsigned int i;
struct lg_eventfd_map *map;
+ /* We only connect LHCALL_NOTIFY to event fds, not other traps. */
+ if (cpu->pending.trap != LGUEST_TRAP_ENTRY)
+ return false;
+
/*
* This "rcu_read_lock()" helps track when someone is still looking at
* the (RCU-using) eventfds array. It's not actually a lock at all;
@@ -52,9 +56,9 @@ bool send_notify_to_eventfd(struct lg_cpu *cpu)
* we'll continue to use the old array and just won't see the new one.
*/
for (i = 0; i < map->num; i++) {
- if (map->map[i].addr == cpu->pending_notify) {
+ if (map->map[i].addr == cpu->pending.addr) {
eventfd_signal(map->map[i].event, 1);
- cpu->pending_notify = 0;
+ cpu->pending.trap = 0;
break;
}
}
@@ -62,7 +66,7 @@ bool send_notify_to_eventfd(struct lg_cpu *cpu)
rcu_read_unlock();
/* If we cleared the notification, it's because we found a match. */
- return cpu->pending_notify == 0;
+ return cpu->pending.trap == 0;
}
/*L:055
@@ -282,8 +286,8 @@ static ssize_t read(struct file *file, char __user *user,
[PATCH 02/29] lguest: add operations to get/set a register from the Launcher.
We use the ptrace API struct, and we currently don't let them set
anything but the normal registers (we'd have to filter the others).
Signed-off-by: Rusty Russell
---
drivers/lguest/core.c | 8 +++
drivers/lguest/lg.h | 3 +++
drivers/lguest/lguest_user.c| 49 +
drivers/lguest/x86/core.c | 46 ++
include/linux/lguest_launcher.h | 2 ++
5 files changed, 108 insertions(+)
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index 6590558d1d31..cdb2f9aa5860 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -208,6 +208,14 @@ void __lgwrite(struct lg_cpu *cpu, unsigned long addr,
const void *b,
*/
int run_guest(struct lg_cpu *cpu, unsigned long __user *user)
{
+ /* If the launcher asked for a register with LHREQ_GETREG */
+ if (cpu->reg_read) {
+ if (put_user(*cpu->reg_read, user))
+ return -EFAULT;
+ cpu->reg_read = NULL;
+ return sizeof(*cpu->reg_read);
+ }
+
/* We stop running once the Guest is dead. */
while (!cpu->lg->dead) {
unsigned int irq;
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
index 2eef40be4c04..1c98bf74fd68 100644
--- a/drivers/lguest/lg.h
+++ b/drivers/lguest/lg.h
@@ -52,6 +52,8 @@ struct lg_cpu {
unsigned long pending_notify; /* pfn from LHCALL_NOTIFY */
+ unsigned long *reg_read; /* register from LHREQ_GETREG */
+
/* At end of a page shared mapped over lguest_pages in guest. */
unsigned long regs_page;
struct lguest_regs *regs;
@@ -210,6 +212,7 @@ void lguest_arch_handle_trap(struct lg_cpu *cpu);
int lguest_arch_init_hypercalls(struct lg_cpu *cpu);
int lguest_arch_do_hcall(struct lg_cpu *cpu, struct hcall_args *args);
void lguest_arch_setup_regs(struct lg_cpu *cpu, unsigned long start);
+unsigned long *lguest_arch_regptr(struct lg_cpu *cpu, size_t reg_off, bool
any);
/* /switcher.S: */
extern char start_switcher_text[], end_switcher_text[], switch_to_guest[];
diff --git a/drivers/lguest/lguest_user.c b/drivers/lguest/lguest_user.c
index 4263f4cc8c55..7f14c152dd23 100644
--- a/drivers/lguest/lguest_user.c
+++ b/drivers/lguest/lguest_user.c
@@ -173,6 +173,51 @@ static int attach_eventfd(struct lguest *lg, const
unsigned long __user *input)
return err;
}
+/* The Launcher can get the registers, and also set some of them. */
+static int getreg_setup(struct lg_cpu *cpu, const unsigned long __user *input)
+{
+ unsigned long which;
+
+ /* We re-use the ptrace structure to specify which register to read. */
+ if (get_user(which, input) != 0)
+ return -EFAULT;
+
+ /*
+* We set up the cpu register pointer, and their next read will
+* actually get the value (instead of running the guest).
+*
+* The last argument 'true' says we can access any register.
+*/
+ cpu->reg_read = lguest_arch_regptr(cpu, which, true);
+ if (!cpu->reg_read)
+ return -ENOENT;
+
+ /* And because this is a write() call, we return the length used. */
+ return sizeof(unsigned long) * 2;
+}
+
+static int setreg(struct lg_cpu *cpu, const unsigned long __user *input)
+{
+ unsigned long which, value, *reg;
+
+ /* We re-use the ptrace structure to specify which register to read. */
+ if (get_user(which, input) != 0)
+ return -EFAULT;
+ input++;
+ if (get_user(value, input) != 0)
+ return -EFAULT;
+
+ /* The last argument 'false' means we can't access all registers. */
+ reg = lguest_arch_regptr(cpu, which, false);
+ if (!reg)
+ return -ENOENT;
+
+ *reg = value;
+
+ /* And because this is a write() call, we return the length used. */
+ return sizeof(unsigned long) * 3;
+}
+
/*L:050
* Sending an interrupt is done by writing LHREQ_IRQ and an interrupt
* number to /dev/lguest.
@@ -434,6 +479,10 @@ static ssize_t write(struct file *file, const char __user
*in,
return user_send_irq(cpu, input);
case LHREQ_EVENTFD:
return attach_eventfd(lg, input);
+ case LHREQ_GETREG:
+ return getreg_setup(cpu, input);
+ case LHREQ_SETREG:
+ return setreg(cpu, input);
default:
return -EINVAL;
}
diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
index 922a1acbf652..f7a16b4ea456 100644
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -181,6 +181,52 @@ static void run_guest_once(struct lg_cpu *cpu, struct
lguest_pages *pages)
}
/*:*/
+unsigned long *lguest_arch_regptr(struct lg_cpu *cpu, size_t reg_off, bool any)
+{
+ switch (reg_off) {
+ case offsetof(struct pt_regs, bx):
+ return >regs->ebx;
+ case offsetof(struct pt_regs, cx):
+
[PATCH 07/29] lguest: suppress PS/2 keyboard polling.
While hacking on getting I/O out to the lguest launcher, I noticed that returning 0xFF for the PS/2 keyboard status made it spin for a while thinking there was a key pending. Fix this by returning 1 instead of 0xFF. Signed-off-by: Rusty Russell --- tools/lguest/lguest.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index b2217657f62c..485fe13db12e 100644 --- a/tools/lguest/lguest.c +++ b/tools/lguest/lguest.c @@ -1259,6 +1259,10 @@ static void emulate_insn(const u8 insn[]) else mask = 0x; + /* This is the PS/2 keyboard status; 1 means ready for output */ + if (port == 0x64) + val = 1; + /* * If it was an "IN" instruction, they expect the result to be read * into %eax, so we change %eax. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/29] lguest: send trap 13 through to userspace.
We copy 7 bytes at eip for userspace's instruction decode; we have to
carefully handle the case where eip is at the end of a page. We can't
leave this to userspace since kernel has all the page table decode
logic.
The decode logic moves to userspace, basically unchanged.
Signed-off-by: Rusty Russell
---
drivers/lguest/x86/core.c | 133 +
tools/lguest/lguest.c | 149 ++
2 files changed, 192 insertions(+), 90 deletions(-)
diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
index f7a16b4ea456..42e87bf14113 100644
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -314,95 +314,52 @@ void lguest_arch_run_guest(struct lg_cpu *cpu)
* usually attached to a PC.
*
* When the Guest uses one of these instructions, we get a trap (General
- * Protection Fault) and come here. We see if it's one of those troublesome
- * instructions and skip over it. We return true if we did.
+ * Protection Fault) and come here. We queue this to be sent out to the
+ * Launcher to handle.
*/
-static int emulate_insn(struct lg_cpu *cpu)
-{
- u8 insn;
- unsigned int insnlen = 0, in = 0, small_operand = 0;
- /*
-* The eip contains the *virtual* address of the Guest's instruction:
-* walk the Guest's page tables to find the "physical" address.
-*/
- unsigned long physaddr = guest_pa(cpu, cpu->regs->eip);
-
- /*
-* This must be the Guest kernel trying to do something, not userspace!
-* The bottom two bits of the CS segment register are the privilege
-* level.
-*/
- if ((cpu->regs->cs & 3) != GUEST_PL)
- return 0;
- /* Decoding x86 instructions is icky. */
- insn = lgread(cpu, physaddr, u8);
-
- /*
-* Around 2.6.33, the kernel started using an emulation for the
-* cmpxchg8b instruction in early boot on many configurations. This
-* code isn't paravirtualized, and it tries to disable interrupts.
-* Ignore it, which will Mostly Work.
-*/
- if (insn == 0xfa) {
- /* "cli", or Clear Interrupt Enable instruction. Skip it. */
- cpu->regs->eip++;
- return 1;
+/*
+ * The eip contains the *virtual* address of the Guest's instruction:
+ * we copy the instruction here so the Launcher doesn't have to walk
+ * the page tables to decode it. We handle the case (eg. in a kernel
+ * module) where the instruction is over two pages, and the pages are
+ * virtually but not physically contiguous.
+ *
+ * The longest possible x86 instruction is 15 bytes, but we don't handle
+ * anything that strange.
+ */
+static void copy_from_guest(struct lg_cpu *cpu,
+ void *dst, unsigned long vaddr, size_t len)
+{
+ size_t to_page_end = PAGE_SIZE - (vaddr % PAGE_SIZE);
+ unsigned long paddr;
+
+ BUG_ON(len > PAGE_SIZE);
+
+ /* If it goes over a page, copy in two parts. */
+ if (len > to_page_end) {
+ /* But make sure the next page is mapped! */
+ if (__guest_pa(cpu, vaddr + to_page_end, ))
+ copy_from_guest(cpu, dst + to_page_end,
+ vaddr + to_page_end,
+ len - to_page_end);
+ else
+ /* Otherwise fill with zeroes. */
+ memset(dst + to_page_end, 0, len - to_page_end);
+ len = to_page_end;
}
- /*
-* 0x66 is an "operand prefix". It means a 16, not 32 bit in/out.
-*/
- if (insn == 0x66) {
- small_operand = 1;
- /* The instruction is 1 byte so far, read the next byte. */
- insnlen = 1;
- insn = lgread(cpu, physaddr + insnlen, u8);
- }
+ /* This will kill the guest if it isn't mapped, but that
+* shouldn't happen. */
+ __lgread(cpu, dst, guest_pa(cpu, vaddr), len);
+}
- /*
-* We can ignore the lower bit for the moment and decode the 4 opcodes
-* we need to emulate.
-*/
- switch (insn & 0xFE) {
- case 0xE4: /* in ,%al */
- insnlen += 2;
- in = 1;
- break;
- case 0xEC: /* in (%dx),%al */
- insnlen += 1;
- in = 1;
- break;
- case 0xE6: /* out%al, */
- insnlen += 2;
- break;
- case 0xEE: /* out%al,(%dx) */
- insnlen += 1;
- break;
- default:
- /* OK, we don't know what this is, can't emulate. */
- return 0;
- }
- /*
-* If it was an "IN" instruction, they expect the result to be read
-* into %eax, so we change %eax. We always return all-ones, which
-* traditionally means "there's nothing
[PATCH 05/29] lguest: add infrastructure to check mappings.
We normally abort the guest unconditionally when it gives us a bad address,
but in the next patch we want to copy some bytes which may not be mapped.
Signed-off-by: Rusty Russell
---
drivers/lguest/lg.h | 1 +
drivers/lguest/page_tables.c | 42 +-
2 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
index 020fec5bb072..9da4f351e077 100644
--- a/drivers/lguest/lg.h
+++ b/drivers/lguest/lg.h
@@ -202,6 +202,7 @@ void guest_set_pte(struct lg_cpu *cpu, unsigned long gpgdir,
void map_switcher_in_guest(struct lg_cpu *cpu, struct lguest_pages *pages);
bool demand_page(struct lg_cpu *cpu, unsigned long cr2, int errcode);
void pin_page(struct lg_cpu *cpu, unsigned long vaddr);
+bool __guest_pa(struct lg_cpu *cpu, unsigned long vaddr, unsigned long *paddr);
unsigned long guest_pa(struct lg_cpu *cpu, unsigned long vaddr);
void page_table_guest_data_init(struct lg_cpu *cpu);
diff --git a/drivers/lguest/page_tables.c b/drivers/lguest/page_tables.c
index e8b55c3a6170..69c35caa955a 100644
--- a/drivers/lguest/page_tables.c
+++ b/drivers/lguest/page_tables.c
@@ -647,7 +647,7 @@ void guest_pagetable_flush_user(struct lg_cpu *cpu)
/*:*/
/* We walk down the guest page tables to get a guest-physical address */
-unsigned long guest_pa(struct lg_cpu *cpu, unsigned long vaddr)
+bool __guest_pa(struct lg_cpu *cpu, unsigned long vaddr, unsigned long *paddr)
{
pgd_t gpgd;
pte_t gpte;
@@ -656,31 +656,47 @@ unsigned long guest_pa(struct lg_cpu *cpu, unsigned long
vaddr)
#endif
/* Still not set up? Just map 1:1. */
- if (unlikely(cpu->linear_pages))
- return vaddr;
+ if (unlikely(cpu->linear_pages)) {
+ *paddr = vaddr;
+ return true;
+ }
/* First step: get the top-level Guest page table entry. */
gpgd = lgread(cpu, gpgd_addr(cpu, vaddr), pgd_t);
/* Toplevel not present? We can't map it in. */
- if (!(pgd_flags(gpgd) & _PAGE_PRESENT)) {
- kill_guest(cpu, "Bad address %#lx", vaddr);
- return -1UL;
- }
+ if (!(pgd_flags(gpgd) & _PAGE_PRESENT))
+ goto fail;
#ifdef CONFIG_X86_PAE
gpmd = lgread(cpu, gpmd_addr(gpgd, vaddr), pmd_t);
- if (!(pmd_flags(gpmd) & _PAGE_PRESENT)) {
- kill_guest(cpu, "Bad address %#lx", vaddr);
- return -1UL;
- }
+ if (!(pmd_flags(gpmd) & _PAGE_PRESENT))
+ goto fail;
gpte = lgread(cpu, gpte_addr(cpu, gpmd, vaddr), pte_t);
#else
gpte = lgread(cpu, gpte_addr(cpu, gpgd, vaddr), pte_t);
#endif
if (!(pte_flags(gpte) & _PAGE_PRESENT))
- kill_guest(cpu, "Bad address %#lx", vaddr);
+ goto fail;
+
+ *paddr = pte_pfn(gpte) * PAGE_SIZE | (vaddr & ~PAGE_MASK);
+ return true;
+
+fail:
+ *paddr = -1UL;
+ return false;
+}
- return pte_pfn(gpte) * PAGE_SIZE | (vaddr & ~PAGE_MASK);
+/*
+ * This is the version we normally use: kills the Guest if it uses a
+ * bad address
+ */
+unsigned long guest_pa(struct lg_cpu *cpu, unsigned long vaddr)
+{
+ unsigned long paddr;
+
+ if (!__guest_pa(cpu, vaddr, ))
+ kill_guest(cpu, "Bad address %#lx", vaddr);
+ return paddr;
}
/*
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/29] lguest: add infrastructure for userspace to deliver a trap to the guest.
This is required for instruction emulation to move to userspace.
Signed-off-by: Rusty Russell
---
drivers/lguest/lguest_user.c| 19 +++
include/linux/lguest_launcher.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/lguest/lguest_user.c b/drivers/lguest/lguest_user.c
index dcf9efd94cf4..be996d173615 100644
--- a/drivers/lguest/lguest_user.c
+++ b/drivers/lguest/lguest_user.c
@@ -243,6 +243,23 @@ static int user_send_irq(struct lg_cpu *cpu, const
unsigned long __user *input)
return 0;
}
+/*L:053
+ * Deliver a trap: this is used by the Launcher if it can't emulate
+ * an instruction.
+ */
+static int trap(struct lg_cpu *cpu, const unsigned long __user *input)
+{
+ unsigned long trapnum;
+
+ if (get_user(trapnum, input) != 0)
+ return -EFAULT;
+
+ if (!deliver_trap(cpu, trapnum))
+ return -EINVAL;
+
+ return 0;
+}
+
/*L:040
* Once our Guest is initialized, the Launcher makes it run by reading
* from /dev/lguest.
@@ -487,6 +504,8 @@ static ssize_t write(struct file *file, const char __user
*in,
return getreg_setup(cpu, input);
case LHREQ_SETREG:
return setreg(cpu, input);
+ case LHREQ_TRAP:
+ return trap(cpu, input);
default:
return -EINVAL;
}
diff --git a/include/linux/lguest_launcher.h b/include/linux/lguest_launcher.h
index c4451ebece47..3c402b843e03 100644
--- a/include/linux/lguest_launcher.h
+++ b/include/linux/lguest_launcher.h
@@ -65,6 +65,7 @@ enum lguest_req
LHREQ_EVENTFD, /* + address, fd. */
LHREQ_GETREG, /* + offset within struct pt_regs (then read value). */
LHREQ_SETREG, /* + offset within struct pt_regs, value. */
+ LHREQ_TRAP, /* + trap number to deliver to guest. */
};
/*
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/29] lguest: add iomem region, where guest page faults get sent to userspace.
This lets us implement PCI.
Signed-off-by: Rusty Russell
---
drivers/lguest/lg.h | 7 ++-
drivers/lguest/lguest_user.c | 3 ++-
drivers/lguest/page_tables.c | 33 ++---
drivers/lguest/x86/core.c| 19 ++-
tools/lguest/lguest.c| 3 ++-
5 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
index 9da4f351e077..eb81abc05995 100644
--- a/drivers/lguest/lg.h
+++ b/drivers/lguest/lg.h
@@ -97,8 +97,12 @@ struct lguest {
struct lg_cpu cpus[NR_CPUS];
unsigned int nr_cpus;
+ /* Valid guest memory pages must be < this. */
u32 pfn_limit;
+ /* Device memory is >= pfn_limit and < device_limit. */
+ u32 device_limit;
+
/*
* This provides the offset to the base of guest-physical memory in the
* Launcher.
@@ -200,7 +204,8 @@ void guest_pagetable_flush_user(struct lg_cpu *cpu);
void guest_set_pte(struct lg_cpu *cpu, unsigned long gpgdir,
unsigned long vaddr, pte_t val);
void map_switcher_in_guest(struct lg_cpu *cpu, struct lguest_pages *pages);
-bool demand_page(struct lg_cpu *cpu, unsigned long cr2, int errcode);
+bool demand_page(struct lg_cpu *cpu, unsigned long cr2, int errcode,
+unsigned long *iomem);
void pin_page(struct lg_cpu *cpu, unsigned long vaddr);
bool __guest_pa(struct lg_cpu *cpu, unsigned long vaddr, unsigned long *paddr);
unsigned long guest_pa(struct lg_cpu *cpu, unsigned long vaddr);
diff --git a/drivers/lguest/lguest_user.c b/drivers/lguest/lguest_user.c
index be996d173615..c8b0e8575b44 100644
--- a/drivers/lguest/lguest_user.c
+++ b/drivers/lguest/lguest_user.c
@@ -385,7 +385,7 @@ static int initialize(struct file *file, const unsigned
long __user *input)
/* "struct lguest" contains all we (the Host) know about a Guest. */
struct lguest *lg;
int err;
- unsigned long args[3];
+ unsigned long args[4];
/*
* We grab the Big Lguest lock, which protects against multiple
@@ -419,6 +419,7 @@ static int initialize(struct file *file, const unsigned
long __user *input)
/* Populate the easy fields of our "struct lguest" */
lg->mem_base = (void __user *)args[0];
lg->pfn_limit = args[1];
+ lg->device_limit = args[3];
/* This is the first cpu (cpu 0) and it will start booting at args[2] */
err = lg_cpu_start(>cpus[0], 0, args[2]);
diff --git a/drivers/lguest/page_tables.c b/drivers/lguest/page_tables.c
index 69c35caa955a..e3abebc912c0 100644
--- a/drivers/lguest/page_tables.c
+++ b/drivers/lguest/page_tables.c
@@ -250,6 +250,16 @@ static void release_pte(pte_t pte)
}
/*:*/
+static bool gpte_in_iomem(struct lg_cpu *cpu, pte_t gpte)
+{
+ /* We don't handle large pages. */
+ if (pte_flags(gpte) & _PAGE_PSE)
+ return false;
+
+ return (pte_pfn(gpte) >= cpu->lg->pfn_limit
+ && pte_pfn(gpte) < cpu->lg->device_limit);
+}
+
static bool check_gpte(struct lg_cpu *cpu, pte_t gpte)
{
if ((pte_flags(gpte) & _PAGE_PSE) ||
@@ -374,8 +384,14 @@ static pte_t *find_spte(struct lg_cpu *cpu, unsigned long
vaddr, bool allocate,
*
* If we fixed up the fault (ie. we mapped the address), this routine returns
* true. Otherwise, it was a real fault and we need to tell the Guest.
+ *
+ * There's a corner case: they're trying to access memory between
+ * pfn_limit and device_limit, which is I/O memory. In this case, we
+ * return false and set @iomem to the physical address, so the the
+ * Launcher can handle the instruction manually.
*/
-bool demand_page(struct lg_cpu *cpu, unsigned long vaddr, int errcode)
+bool demand_page(struct lg_cpu *cpu, unsigned long vaddr, int errcode,
+unsigned long *iomem)
{
unsigned long gpte_ptr;
pte_t gpte;
@@ -383,6 +399,8 @@ bool demand_page(struct lg_cpu *cpu, unsigned long vaddr,
int errcode)
pmd_t gpmd;
pgd_t gpgd;
+ *iomem = 0;
+
/* We never demand page the Switcher, so trying is a mistake. */
if (vaddr >= switcher_addr)
return false;
@@ -459,6 +477,12 @@ bool demand_page(struct lg_cpu *cpu, unsigned long vaddr,
int errcode)
if ((errcode & 4) && !(pte_flags(gpte) & _PAGE_USER))
return false;
+ /* If they're accessing io memory, we expect a fault. */
+ if (gpte_in_iomem(cpu, gpte)) {
+ *iomem = (pte_pfn(gpte) << PAGE_SHIFT) | (vaddr & ~PAGE_MASK);
+ return false;
+ }
+
/*
* Check that the Guest PTE flags are OK, and the page number is below
* the pfn_limit (ie. not mapping the Launcher binary).
@@ -553,7 +577,9 @@ static bool page_writable(struct lg_cpu *cpu, unsigned long
vaddr)
*/
void pin_page(struct lg_cpu *cpu, unsigned long vaddr)
{
- if (!page_writable(cpu, vaddr) && !demand_page(cpu, vaddr, 2))
+
[PATCH 00/29] lguest virtio PCI 1.0 adaptation.
Hi all! I've just spent a week changing lguest from its own custom virtio bus to PCI, and from legacy virtio to modern (1.0). I did this mainly to test the Linux implementation. The first 11 patches set up the framework for routing more traps to the Lguest launcher, so we can intercept ioport and MMIO instructions. Patches 12-15 implement emulation of virtio over PCI devices, and then 16-19 convert the four devices we support. 20-23 remove the obsolete lguest bus support. 24-27 change the guest to bang the emerg_wr register (via the pci config space MMIO accessor window) to perform early boot messages. It's slow and ugly, but it works. Finally, the last two patches remove the last of the old hypercall notification mechanism. Cheers! Rusty. Rusty Russell (29): lguest: have --rng read from /dev/urandom not /dev/random. lguest: add operations to get/set a register from the Launcher. lguest: write more information to userspace about pending traps. lguest: add infrastructure for userspace to deliver a trap to the guest. lguest: add infrastructure to check mappings. lguest: send trap 13 through to userspace. lguest: suppress PS/2 keyboard polling. lguest: don't disable iospace. lguest: add iomem region, where guest page faults get sent to userspace. lguest: disable ACPI explicitly. lguest: Override pcibios_enable_irq/pcibios_disable_irq to our stupid PIC lguest: add PCI emulation. lguest: implement virtio-PCI MMIO accesses. lguest: fix failure to find linux/virtio_types.h lguest: add a dummy PCI host bridge. lguest: Convert block device to virtio 1.0 PCI. lguest: Convert net device to virtio 1.0 PCI. lguest: Convert entropy device to virtio 1.0 PCI. lguest: Convert console device to virtio 1.0 PCI. lguest: define VIRTIO_CONFIG_NO_LEGACY in example launcher. lguest: remove support for lguest bus. lguest: remove support for lguest bus in demonstration launcher. lguest: remove lguest bus definitions from header. lguest: support emerg_wr in console device in example launcher. lguest: support backdoor window. lguest: always put console in PCI slot #1. lguest: use the PCI console device's emerg_wr for early boot messages. lguest: remove NOTIFY facility from demonstration launcher. lguest: remove NOTIFY call and eventfd facility. arch/x86/include/asm/lguest_hcall.h |1 - arch/x86/lguest/boot.c | 182 - drivers/lguest/Makefile |3 - drivers/lguest/core.c | 29 +- drivers/lguest/hypercalls.c |7 +- drivers/lguest/lg.h | 26 +- drivers/lguest/lguest_device.c | 540 - drivers/lguest/lguest_user.c| 221 ++ drivers/lguest/page_tables.c| 75 +- drivers/lguest/x86/core.c | 198 ++--- include/linux/lguest_launcher.h | 61 +- tools/lguest/Makefile |8 +- tools/lguest/lguest.c | 1443 +++ 13 files changed, 1572 insertions(+), 1222 deletions(-) delete mode 100644 drivers/lguest/lguest_device.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/29] lguest: don't disable iospace.
This no longer speeds up boot (IDE got better, I guess), but it does stop us probing for a PCI bus. Signed-off-by: Rusty Russell --- arch/x86/lguest/boot.c | 8 1 file changed, 8 deletions(-) diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c index c1c1544b8485..47ec7f201d27 100644 --- a/arch/x86/lguest/boot.c +++ b/arch/x86/lguest/boot.c @@ -1400,14 +1400,6 @@ __init void lguest_init(void) atomic_notifier_chain_register(_notifier_list, ); /* -* The IDE code spends about 3 seconds probing for disks: if we reserve -* all the I/O ports up front it can't get them and so doesn't probe. -* Other device drivers are similar (but less severe). This cuts the -* kernel boot time on my machine from 4.1 seconds to 0.45 seconds. -*/ - paravirt_disable_iospace(); - - /* * This is messy CPU setup stuff which the native boot code does before * start_kernel, so we have to do, too: */ -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: mmp-tdma: refine dma disable and dma-pos update
On 5 February 2015 at 20:54, Qiao Zhou wrote: > Below are the refinements. > 1. Set DMA abort bit when disabling dma channel. This will clear > the remaining data in dma FIFO, to fix channel-swap issue. > 2. Read DMA HW pointer when updating DMA status. Previously dma > position is calculated by adding one period size in dma interrupt. > This is inaccurate/insufficient for some high-quality audio APP. > Since interrupt bottom half handler has variable schedule delay, > it causes big error when calculating sample delay. Read the actual > HW pointer and feedback can improve the accuracy. > 3. Do some minor code clean. > > Signed-off-by: Qiao Zhou Acked-by: Zhangfei Gao Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] virtio: Don't expose legacy block features when VIRTIO_BLK_NO_LEGACY defined.
This allows modern implementations to ensure they don't use legacy
feature bits or SCSI commands (which are not used in v1.0 non-legacy).
Signed-off-by: Rusty Russell
---
include/uapi/linux/virtio_blk.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
index 247c8ba8544a..3c53eec4ae22 100644
--- a/include/uapi/linux/virtio_blk.h
+++ b/include/uapi/linux/virtio_blk.h
@@ -31,22 +31,25 @@
#include
/* Feature bits */
-#define VIRTIO_BLK_F_BARRIER 0 /* Does host support barriers? */
#define VIRTIO_BLK_F_SIZE_MAX 1 /* Indicates maximum segment size */
#define VIRTIO_BLK_F_SEG_MAX 2 /* Indicates maximum # of segments */
#define VIRTIO_BLK_F_GEOMETRY 4 /* Legacy geometry available */
#define VIRTIO_BLK_F_RO5 /* Disk is read-only */
#define VIRTIO_BLK_F_BLK_SIZE 6 /* Block size of disk is available*/
-#define VIRTIO_BLK_F_SCSI 7 /* Supports scsi command passthru */
-#define VIRTIO_BLK_F_WCE 9 /* Writeback mode enabled after reset */
#define VIRTIO_BLK_F_TOPOLOGY 10 /* Topology information is available */
-#define VIRTIO_BLK_F_CONFIG_WCE11 /* Writeback mode available in
config */
#define VIRTIO_BLK_F_MQ12 /* support more than one vq */
+/* Legacy feature bits */
+#ifndef VIRTIO_BLK_NO_LEGACY
+#define VIRTIO_BLK_F_BARRIER 0 /* Does host support barriers? */
+#define VIRTIO_BLK_F_SCSI 7 /* Supports scsi command passthru */
+#define VIRTIO_BLK_F_WCE 9 /* Writeback mode enabled after reset */
+#define VIRTIO_BLK_F_CONFIG_WCE11 /* Writeback mode available in
config */
#ifndef __KERNEL__
/* Old (deprecated) name for VIRTIO_BLK_F_WCE. */
#define VIRTIO_BLK_F_FLUSH VIRTIO_BLK_F_WCE
#endif
+#endif /* !VIRTIO_BLK_NO_LEGACY */
#define VIRTIO_BLK_ID_BYTES20 /* ID string length */
@@ -100,8 +103,10 @@ struct virtio_blk_config {
#define VIRTIO_BLK_T_IN0
#define VIRTIO_BLK_T_OUT 1
+#ifndef VIRTIO_BLK_NO_LEGACY
/* This bit says it's a scsi command, not an actual read or write. */
#define VIRTIO_BLK_T_SCSI_CMD 2
+#endif /* VIRTIO_BLK_NO_LEGACY */
/* Cache flush command */
#define VIRTIO_BLK_T_FLUSH 4
@@ -109,8 +114,10 @@ struct virtio_blk_config {
/* Get device ID command */
#define VIRTIO_BLK_T_GET_ID8
+#ifndef VIRTIO_BLK_NO_LEGACY
/* Barrier before this op. */
#define VIRTIO_BLK_T_BARRIER 0x8000
+#endif /* !VIRTIO_BLK_NO_LEGACY */
/* This is the first element of the read scatter-gather list. */
struct virtio_blk_outhdr {
@@ -122,12 +129,14 @@ struct virtio_blk_outhdr {
__virtio64 sector;
};
+#ifndef VIRTIO_BLK_NO_LEGACY
struct virtio_scsi_inhdr {
__virtio32 errors;
__virtio32 data_len;
__virtio32 sense_len;
__virtio32 residual;
};
+#endif /* !VIRTIO_BLK_NO_LEGACY */
/* And this is the final byte of the write scatter-gather list. */
#define VIRTIO_BLK_S_OK0
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined.
In particular, the virtio header always has the u16 num_buffers field.
We define a new 'struct virtio_net_modern_hdr' for this (rather than
simply calling it 'struct virtio_net_hdr', to avoid nasty type errors
if some parts of a project define VIRTIO_NET_NO_LEGACY and some don't.
Signed-off-by: Rusty Russell
---
include/uapi/linux/virtio_net.h | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index b5f1677b291c..32754f3000e8 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -35,7 +35,6 @@
#define VIRTIO_NET_F_CSUM 0 /* Host handles pkts w/ partial csum */
#define VIRTIO_NET_F_GUEST_CSUM1 /* Guest handles pkts w/
partial csum */
#define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
-#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
#define VIRTIO_NET_F_GUEST_TSO47 /* Guest can handle TSOv4 in. */
#define VIRTIO_NET_F_GUEST_TSO68 /* Guest can handle TSOv6 in. */
#define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] w/ ECN in. */
@@ -56,6 +55,10 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#ifndef VIRTIO_NET_NO_LEGACY
+#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
+#endif /* VIRTIO_NET_NO_LEGACY */
+
#define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
#define VIRTIO_NET_S_ANNOUNCE 2 /* Announcement is needed */
@@ -71,8 +74,9 @@ struct virtio_net_config {
__u16 max_virtqueue_pairs;
} __attribute__((packed));
+#ifndef VIRTIO_NET_NO_LEGACY
/* This header comes first in the scatter-gather list.
- * If VIRTIO_F_ANY_LAYOUT is not negotiated, it must
+ * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it must
* be the first element of the scatter-gather list. If you don't
* specify GSO or CSUM features, you can simply ignore the header. */
struct virtio_net_hdr {
@@ -97,6 +101,28 @@ struct virtio_net_hdr_mrg_rxbuf {
struct virtio_net_hdr hdr;
__virtio16 num_buffers; /* Number of merged rx buffers */
};
+#else /* ... VIRTIO_NET_NO_LEGACY */
+/*
+ * This header comes first in the scatter-gather list. If you don't
+ * specify GSO or CSUM features, you can simply ignore the header.
+ */
+struct virtio_net_modern_hdr {
+#define VIRTIO_NET_HDR_F_NEEDS_CSUM1 /* Use csum_start, csum_offset
*/
+#define VIRTIO_NET_HDR_F_DATA_VALID2 /* Csum is valid */
+ __u8 flags;
+#define VIRTIO_NET_HDR_GSO_NONE0 /* Not a GSO frame */
+#define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
+#define VIRTIO_NET_HDR_GSO_UDP 3 /* GSO frame, IPv4 UDP (UFO) */
+#define VIRTIO_NET_HDR_GSO_TCPV6 4 /* GSO frame, IPv6 TCP */
+#define VIRTIO_NET_HDR_GSO_ECN 0x80/* TCP has ECN set */
+ __u8 gso_type;
+ __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
+ __virtio16 gso_size;/* Bytes to append to hdr_len per frame */
+ __virtio16 csum_start; /* Position to start checksumming from */
+ __virtio16 csum_offset; /* Offset after that to place checksum */
+ __virtio16 num_buffers; /* Number of merged rx buffers */
+};
+#endif /* ...VIRTIO_NET_NO_LEGACY */
/*
* Control virtqueue data structures
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] virtio: don't require a config space on the console device.
Strictly, it's only needed when we have features (size or multiport).
Signed-off-by: Rusty Russell
---
drivers/char/virtio_console.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 26afb56a8073..8f182b0015b5 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1986,10 +1986,14 @@ static int virtcons_probe(struct virtio_device *vdev)
bool multiport;
bool early = early_put_chars != NULL;
- if (!vdev->config->get) {
- dev_err(>dev, "%s failure: config access disabled\n",
- __func__);
- return -EINVAL;
+ /* We only need a config space if features are offered */
+ if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_SIZE)
+ || virtio_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT)) {
+ if (!vdev->config->get) {
+ dev_err(>dev, "%s failure: config access
disabled\n",
+ __func__);
+ return -EINVAL;
+ }
}
/* Ensure to read early_put_chars now */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] virtio: Don't expose legacy config features when VIRTIO_CONFIG_NO_LEGACY defined.
The VIRTIO_F_ANY_LAYOUT and VIRTIO_F_NOTIFY_ON_EMPTY features are pre-1.0 only. Signed-off-by: Rusty Russell --- include/uapi/linux/virtio_config.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h index a6d0cdeaacd4..c18264df9504 100644 --- a/include/uapi/linux/virtio_config.h +++ b/include/uapi/linux/virtio_config.h @@ -49,12 +49,14 @@ #define VIRTIO_TRANSPORT_F_START 28 #define VIRTIO_TRANSPORT_F_END 33 +#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've * suppressed them? */ #define VIRTIO_F_NOTIFY_ON_EMPTY 24 /* Can the device handle any descriptor layout? */ #define VIRTIO_F_ANY_LAYOUT27 +#endif /* VIRTIO_CONFIG_NO_LEGACY */ /* v1.0 compliant. */ #define VIRTIO_F_VERSION_1 32 -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] virtio: define VIRTIO_PCI_CAP_PCI_CFG in header.
This provides backdoor access to the device MMIOs, and every device should
have one. From the virtio 1.0 spec (CS03):
4.1.4.7.1 Device Requirements: PCI configuration access capability
The device MUST present at least one VIRTIO_PCI_CAP_PCI_CFG capability.
Signed-off-by: Rusty Russell
---
include/uapi/linux/virtio_pci.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 3b7e4d2765fb..75301468359f 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -109,8 +109,10 @@
#define VIRTIO_PCI_CAP_NOTIFY_CFG 2
/* ISR access */
#define VIRTIO_PCI_CAP_ISR_CFG 3
-/* Device specific confiuration */
+/* Device specific configuration */
#define VIRTIO_PCI_CAP_DEVICE_CFG 4
+/* PCI configuration access */
+#define VIRTIO_PCI_CAP_PCI_CFG 5
/* This is the PCI capability header: */
struct virtio_pci_cap {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] virtio 1.0 cleanups and one fix.
Hi all, Some minor fixes for my virtio-next tree. Michael, does QEMU implement the (compuslory!) VIRTIO_PCI_CAP_PCI_CFG field? I'm guessing not, since it wasn't defined in the Linux header :( Rusty Russell (5): virtio: define VIRTIO_PCI_CAP_PCI_CFG in header. virtio: Don't expose legacy block features when VIRTIO_BLK_NO_LEGACY defined. virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined. virtio: Don't expose legacy config features when VIRTIO_CONFIG_NO_LEGACY defined. virtio: don't require a config space on the console device. drivers/char/virtio_console.c | 12 include/uapi/linux/virtio_blk.h| 17 + include/uapi/linux/virtio_config.h | 2 ++ include/uapi/linux/virtio_net.h| 30 -- include/uapi/linux/virtio_pci.h| 4 +++- 5 files changed, 54 insertions(+), 11 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] af_packet: don't pass empty blocks for PACKET_V3
On 06.02.2015 00:16:30 +0300 Guy Harris wrote: On Feb 5, 2015, at 12:01 PM, Willem de Bruijn wrote: On Wed, Feb 4, 2015 at 9:58 PM, Alexander Drozdov wrote: Don't close an empty block on timeout. Its meaningless to pass it to the user. Moreover, passing empty blocks wastes CPU & buffer space increasing probability of packets dropping on small timeouts. Side effect of this patch is indefinite user-space wait in poll on idle links. But, I believe its better to set timeout for poll(2) when needed than to get empty blocks every millisecond when not needed. This change would break existing applications that have come to depend on the periodic signal. I don't disagree with the argument that the data ready signal should be sent only when a block is full or a timer expires and at least some data is waiting, but that is moot at this point. For what it's worth, the BPF packet capture mechanism (which really needs a new name, to distinguish itself from the BPF packet filter language and its implementation(s), but I digress) has the same issue - when the timer expires, a wakeup is delivered even if there are no packets to read. *However*, if there are no packets available, the buffers aren't rotated, so the empty buffer is left around to be filled up with packets, rather than being made the hold buffer. Given that before the previous TPACKET_V3 change, wakeups were delivered when packets arrived rather than when a block was closed, presumably code using TPACKET_V3 was capable of dealing with wakeups being delivered when no new blocks had been made available to userland; could TPACKET_V3 work a bit more like BPF and deliver a wakeup when the timer expires *without* closing the empty block? Thank you all for your comments! I'll try to create two patches: 1. Wakeup by timeout without closing the empty block 2. Allow to not wakeup by timeout (the feature should be explicitly requested by a user) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: update ops->oobretlen in concat_write_oob
On Tue, Jan 20, 2015 at 10:35:32AM +0100, Niklas Cassel wrote: > In concat_read_oob both retlen and oobretlen is updated. > concat_write_oob previously only updated retlen. > > Signed-off-by: Niklas Cassel Pushed to l2-mtd.git. Thanks. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 4/11] xfsprogs: xfs_io: add finsert command for insert range
> Hi Namjae, Hi Dave, > > On Fri, Feb 06, 2015 at 10:40:33AM +1100, Dave Chinner wrote: > > On Thu, Jan 22, 2015 at 12:11:59AM +0900, Namjae Jeon wrote: > > > From: Namjae Jeon > > > > > > Add finsert command for fallocate FALLOC_FL_INSERT_RANGE flag. > > > > > > Signed-off-by: Namjae Jeon > > > Signed-off-by: Ashish Sangwan > > > Reviewed-by: Brian Foster > > > > I've just pulled this patch into xfsprogs in preparation for getting > > this functionality fully reviewed and merged in the 3.21 kernel > > cycle. > > xfs/293 3s ... - output mismatch (see > /home/dave/src/xfstests-dev/results//xfs/293.out.bad) > --- tests/xfs/293.out 2014-01-20 16:57:34.0 +1100 > +++ /home/dave/src/xfstests-dev/results//xfs/293.out.bad2015-02-06 > 12:21:47.0 +1100 > @@ -1,2 +1,3 @@ > QA output created by 293 > Silence is golden > +finsert not documented in the xfs_io manpage > . > > Can you send a patch that updates the xfs_io man page, please? Okay, I will send it soon. Thanks a lot! > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.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 v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables
On Wed, Jan 21, 2015 at 03:24:20PM +, Lee Jones wrote: > To trim down on the amount of properties used by this driver and to conform > to the newly agreed method of acquiring syscfg registers/offsets, we now > obtain this information using match tables. Where did this agreement happen? Are you only referring to the previous patch? I think I asked this previously, and I didn't get an answer. Also, I realized that all this boot device / syscfg gymnastics is just for one simple fact; your driver is trying to hide the fact that your system can't reliably handle 4-byte addressing for the boot device. Even if you try your best at toggling 4-byte addressing before/after each read/write/erase, you still are vulnerable to power cuts during the operation. This is a bad design, and we have consistently agreed that we aren't going to work around that in Linux. Better solutions: hook up a reset line to your flash; improve your boot ROM / bootloader to handle 4-byte addressing for large flash. What's the possibility of dropping all this 4-byte address toggling shenanigans? This will be a blocker to merging with spi-nor.c. > In the process we are deprecating the old generic compatible string and > providing 3 shiny new ones for each of the support platforms. The > deprecated compatible string will be removed in due course. Aren't you already removing the compatible string? (You changed this in the latest revision.) > Cc: devicet...@vger.kernel.org > Signed-off-by: Lee Jones [snip] Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: denali: remove unnecessary stubs
On Tue, Jan 13, 2015 at 01:29:17PM +0900, Masahiro Yamada wrote: > This driver uses NAND_ECC_HW_SYNDROME mode. The nand_scan_tail() > function would not complain about missing ecc->calculate, > ecc->correct, ecc->hwctl handlers. > > Signed-off-by: Masahiro Yamada Pushed to l2-mtd.git. Thanks. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mtd: nand: omap: drop condition with no effect
On Wed, Feb 04, 2015 at 12:24:06PM -0500, Nicholas Mc Guire wrote: > The if and the else branch code are identical - so the condition has no > effect on the effective code. This patch removes the condition and the > duplicated code and updates the documentation as suggested by > Roger Quadros . > > Acked-by: Roger Quadros > Signed-off-by: Nicholas Mc Guire Applied to l2-mtd.git. Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2 1/7] trace: fix the glob match in __unregister_ftrace_function_probe()
From: Al Viro
For patterns starting with '*' we need to match against 'search', not
'glob'.
Signed-off-by: Al Viro
---
kernel/trace/ftrace.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 224e768..67ecd14 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3761,12 +3761,10 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
char str[KSYM_SYMBOL_LEN];
int type = MATCH_FULL;
int i, len = 0;
- char *search;
+ char *search = NULL;
int ret;
- if (glob && (strcmp(glob, "*") == 0 || !strlen(glob)))
- glob = NULL;
- else if (glob) {
+ if (glob && *glob && strcmp(glob, "*") != 0) {
int not;
type = filter_parse_regex(glob, strlen(glob), , );
@@ -3799,10 +3797,10 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
continue;
/* do this last, since it is the most expensive */
- if (glob) {
+ if (search) {
kallsyms_lookup(entry->ip, NULL, NULL,
NULL, str);
- if (!ftrace_match(str, glob, len, type))
+ if (!ftrace_match(str, search, len, type))
continue;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2 6/7] trace: constify filter_parse_regex(), match_records(), ftrace_match() and ftrace_match_record()
From: Al Viro
Stop modifying the glob in filter_parse_regex(); the only reason
for doing that is one strlen() call done right after we'd stored
that NUL and we can find the length of substring directly -
we know where it starts and we know which byte were we trying to
replace with NUL.
With that done, we can make filter_parse_regex() take const char *
(and return const char * via *search). And that immediately
propagates to match_records(), ftrace_match() and ftrace_match_record() -
they can take the glob as const char * now.
Signed-off-by: Al Viro
---
kernel/trace/ftrace.c | 14 +++---
kernel/trace/trace.h | 2 +-
kernel/trace/trace_events_filter.c | 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f640458..b5b0aca 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3362,7 +3362,7 @@ ftrace_notrace_open(struct inode *inode, struct file
*file)
inode, file);
}
-static int ftrace_match(char *str, char *regex, int len, int type)
+static int ftrace_match(char *str, const char *regex, int len, int type)
{
int matched = 0;
int slen = strlen(str);
@@ -3417,7 +3417,7 @@ enter_record(struct ftrace_hash *hash, struct dyn_ftrace
*rec, int not)
static int
ftrace_match_record(struct dyn_ftrace *rec, char *mod,
- char *regex, int len, int type)
+ const char *regex, int len, int type)
{
char str[KSYM_SYMBOL_LEN];
char *modname;
@@ -3438,13 +3438,13 @@ ftrace_match_record(struct dyn_ftrace *rec, char *mod,
}
static int
-match_records(struct ftrace_hash *hash, char *buff,
+match_records(struct ftrace_hash *hash, const char *buff,
int len, char *mod, int not)
{
struct ftrace_page *pg;
struct dyn_ftrace *rec;
int type = MATCH_FULL;
- char *search = buff;
+ const char *search = buff;
int found = 0;
int ret;
@@ -3648,7 +3648,7 @@ register_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
int type, len = strlen(glob), not;
unsigned long key;
int count = 0;
- char *search;
+ const char *search;
int ret;
type = filter_parse_regex(glob, , , );
@@ -3759,7 +3759,7 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
char str[KSYM_SYMBOL_LEN];
int type = MATCH_FULL;
int i, len = 0;
- char *search = NULL;
+ const char *search = NULL;
int ret;
if (glob && *glob && strcmp(glob, "*") != 0) {
@@ -4548,7 +4548,7 @@ ftrace_set_func(unsigned long *array, int *idx, int size,
char *buffer)
int search_len = strlen(buffer);
int fail = 1;
int type, not;
- char *search;
+ const char *search;
bool exists;
int i;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 7483205..09279c5 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1051,7 +1051,7 @@ struct filter_pred {
};
extern enum regex_type
-filter_parse_regex(char *buff, int *len, char **search, int *not);
+filter_parse_regex(const char *buff, int *len, const char **search, int *not);
extern void print_event_filter(struct ftrace_event_file *file,
struct trace_seq *s);
extern int apply_event_filter(struct ftrace_event_file *file,
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 6a659e1..5cefdd8 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -321,7 +321,8 @@ static int regex_match_end(char *str, struct regex *r, int
len)
* not returns 1 if buff started with a '!'
* 0 otherwise.
*/
-enum regex_type filter_parse_regex(char *buff, int *len, char **search, int
*not)
+enum regex_type filter_parse_regex(const char *buff, int *len,
+ const char **search, int *not)
{
int type = MATCH_FULL;
int i;
@@ -345,12 +346,11 @@ enum regex_type filter_parse_regex(char *buff, int *len,
char **search, int *not
type = MATCH_MIDDLE_ONLY;
else
type = MATCH_FRONT_ONLY;
- buff[i] = 0;
break;
}
}
}
- *len = strlen(*search);
+ *len = buff + i - *search;
return type;
}
@@ -358,7 +358,7 @@ enum regex_type filter_parse_regex(char *buff, int *len,
char **search, int *not
static void filter_build_regex(struct filter_pred *pred)
{
struct regex *r = >regex;
- char *search;
+ const char *search;
enum regex_type type = MATCH_FULL;
int not = 0;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe
[RFC][PATCH v2 4/7] ftrace: switch matching to memcmp() and memmem()
From: Al Viro
now we don't need the glob substring being matched to get
NUL-terminated by filter_parse_regex()
Signed-off-by: Al Viro
---
kernel/trace/ftrace.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 67ecd14..a369a54 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3365,24 +3365,26 @@ ftrace_notrace_open(struct inode *inode, struct file
*file)
static int ftrace_match(char *str, char *regex, int len, int type)
{
int matched = 0;
- int slen;
+ int slen = strlen(str);
+
+ if (slen < len)
+ return 0;
switch (type) {
case MATCH_FULL:
- if (strcmp(str, regex) == 0)
+ if (slen == len && memcmp(str, regex, len) == 0)
matched = 1;
break;
case MATCH_FRONT_ONLY:
- if (strncmp(str, regex, len) == 0)
+ if (memcmp(str, regex, len) == 0)
matched = 1;
break;
case MATCH_MIDDLE_ONLY:
- if (strstr(str, regex))
+ if (memmem(str, slen, regex, len))
matched = 1;
break;
case MATCH_END_ONLY:
- slen = strlen(str);
- if (slen >= len && memcmp(str + slen - len, regex, len) == 0)
+ if (memcmp(str + slen - len, regex, len) == 0)
matched = 1;
break;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2 2/7] implement memmem()
From: Al Viro
Signed-off-by: Al Viro
---
include/linux/string.h | 1 +
lib/string.c | 34 ++
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index 2e22a2e..87f9fba 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -75,6 +75,7 @@ extern char * strstr(const char *, const char *);
#endif
#ifndef __HAVE_ARCH_STRNSTR
extern char * strnstr(const char *, const char *, size_t);
+extern void * memmem(const void *, size_t, const void *, size_t);
#endif
#ifndef __HAVE_ARCH_STRLEN
extern __kernel_size_t strlen(const char *);
diff --git a/lib/string.c b/lib/string.c
index 1006330..2035dbe 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -740,27 +740,37 @@ EXPORT_SYMBOL(strstr);
#endif
#ifndef __HAVE_ARCH_STRNSTR
+
/**
- * strnstr - Find the first substring in a length-limited string
+ * memmem - Find the first length-limited substring in a length-limited string
* @s1: The string to be searched
+ * @len1: the maximum number of characters to search
* @s2: The string to search for
- * @len: the maximum number of characters to search
+ * @len2: the length of the string being searched
*/
-char *strnstr(const char *s1, const char *s2, size_t len)
+void *memmem(const void *s1, size_t len1, const void *s2, size_t len2)
{
- size_t l2;
-
- l2 = strlen(s2);
- if (!l2)
- return (char *)s1;
- while (len >= l2) {
- len--;
- if (!memcmp(s1, s2, l2))
- return (char *)s1;
+ if (!len2)
+ return (void *)s1;
+ while (len1 >= len2) {
+ len1--;
+ if (!memcmp(s1, s2, len2))
+ return (void *)s1;
s1++;
}
return NULL;
}
+EXPORT_SYMBOL(memmem);
+/**
+ * strnstr - Find the first substring in a length-limited string
+ * @s1: The string to be searched
+ * @s2: The string to search for
+ * @len: the maximum number of characters to search
+ */
+char *strnstr(const char *s1, const char *s2, size_t len)
+{
+ return memmem(s1, len, s2, strlen(s2));
+}
EXPORT_SYMBOL(strnstr);
#endif
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2 5/7] trace: make filter_parse_regex() provide the length of substring to compare with
From: Al Viro
By this point the only thing that cares about
NUL-termination of substring found by filter_parse_regex() is
strlen() done immediately by all its callers. Once we have found
the length, that's it - we won't be looking at more than that
many bytes in the substring in question.
This commit consolidates those strlen() calls into one
done by filter_parse_regex() itself. To report the length to the
callers, we switch to passing 'len' argument of filter_parse_regex()
by address and use it to pass the length of our substring on the
way out.
The next commit will eliminate modifying the string
completely - filter_parse_regex() has enough information to find
the length of the substring without bothering with this strlen()
call.
Signed-off-by: Al Viro
---
kernel/trace/ftrace.c | 24 +---
kernel/trace/trace.h | 2 +-
kernel/trace/trace_events_filter.c | 10 +-
3 files changed, 15 insertions(+), 21 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a369a54..f640458 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3441,7 +3441,6 @@ static int
match_records(struct ftrace_hash *hash, char *buff,
int len, char *mod, int not)
{
- unsigned search_len = 0;
struct ftrace_page *pg;
struct dyn_ftrace *rec;
int type = MATCH_FULL;
@@ -3449,10 +3448,8 @@ match_records(struct ftrace_hash *hash, char *buff,
int found = 0;
int ret;
- if (len) {
- type = filter_parse_regex(buff, len, , );
- search_len = strlen(search);
- }
+ if (len)
+ type = filter_parse_regex(buff, , , );
mutex_lock(_lock);
@@ -3460,7 +3457,7 @@ match_records(struct ftrace_hash *hash, char *buff,
goto out_unlock;
do_for_each_ftrace_rec(pg, rec) {
- if (ftrace_match_record(rec, mod, search, search_len, type)) {
+ if (ftrace_match_record(rec, mod, search, len, type)) {
ret = enter_record(hash, rec, not);
if (ret < 0) {
found = ret;
@@ -3648,14 +3645,13 @@ register_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
struct ftrace_hash *hash;
struct ftrace_page *pg;
struct dyn_ftrace *rec;
- int type, len, not;
+ int type, len = strlen(glob), not;
unsigned long key;
int count = 0;
char *search;
int ret;
- type = filter_parse_regex(glob, strlen(glob), , );
- len = strlen(search);
+ type = filter_parse_regex(glob, , , );
/* we do not support '!' for function probes */
if (WARN_ON(not))
@@ -3768,9 +3764,9 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
if (glob && *glob && strcmp(glob, "*") != 0) {
int not;
+ len = strlen(glob);
- type = filter_parse_regex(glob, strlen(glob), , );
- len = strlen(search);
+ type = filter_parse_regex(glob, , , );
/* we do not support '!' for function probes */
if (WARN_ON(not))
@@ -4549,7 +4545,7 @@ ftrace_set_func(unsigned long *array, int *idx, int size,
char *buffer)
{
struct dyn_ftrace *rec;
struct ftrace_page *pg;
- int search_len;
+ int search_len = strlen(buffer);
int fail = 1;
int type, not;
char *search;
@@ -4557,12 +4553,10 @@ ftrace_set_func(unsigned long *array, int *idx, int
size, char *buffer)
int i;
/* decode regex */
- type = filter_parse_regex(buffer, strlen(buffer), , );
+ type = filter_parse_regex(buffer, _len, , );
if (!not && *idx >= size)
return -EBUSY;
- search_len = strlen(search);
-
mutex_lock(_lock);
if (unlikely(ftrace_disabled)) {
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 8de48ba..7483205 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1051,7 +1051,7 @@ struct filter_pred {
};
extern enum regex_type
-filter_parse_regex(char *buff, int len, char **search, int *not);
+filter_parse_regex(char *buff, int *len, char **search, int *not);
extern void print_event_filter(struct ftrace_event_file *file,
struct trace_seq *s);
extern int apply_event_filter(struct ftrace_event_file *file,
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 6c4a96b..6a659e1 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -321,7 +321,7 @@ static int regex_match_end(char *str, struct regex *r, int
len)
* not returns 1 if buff started with a '!'
* 0 otherwise.
*/
-enum regex_type filter_parse_regex(char *buff, int len, char **search, int
*not)
+enum regex_type
[RFC][PATCH v2 3/7] trace_events_filter.c: switch to memcmp() and memmem() for matching
From: Al Viro
we know the lengths in advance...
Signed-off-by: Al Viro
---
kernel/trace/trace_events_filter.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index ced69da..6c4a96b 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -271,21 +271,25 @@ static int filter_pred_none(struct filter_pred *pred,
void *event)
static int regex_match_full(char *str, struct regex *r, int len)
{
- if (strncmp(str, r->pattern, len) == 0)
+ if (len - 1 != r->len)
+ return 0;
+ if (memcmp(str, r->pattern, r->len) == 0)
return 1;
return 0;
}
static int regex_match_front(char *str, struct regex *r, int len)
{
- if (strncmp(str, r->pattern, r->len) == 0)
+ if (len - 1 < r->len)
+ return 0;
+ if (memcmp(str, r->pattern, r->len) == 0)
return 1;
return 0;
}
static int regex_match_middle(char *str, struct regex *r, int len)
{
- if (strnstr(str, r->pattern, len))
+ if (memmem(str, len, r->pattern, r->len))
return 1;
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2 7/7] trace: constify glob arguments all way up to ftrace_function_set_regexp()
From: Al Viro
Signed-off-by: Al Viro
---
include/linux/ftrace.h | 8
kernel/trace/ftrace.c | 14 +++---
kernel/trace/trace_events_filter.c | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 1da6029..ca33305 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -360,12 +360,12 @@ struct dyn_ftrace {
int ftrace_force_update(void);
int ftrace_set_filter_ip(struct ftrace_ops *ops, unsigned long ip,
int remove, int reset);
-int ftrace_set_filter(struct ftrace_ops *ops, unsigned char *buf,
+int ftrace_set_filter(struct ftrace_ops *ops, const unsigned char *buf,
int len, int reset);
-int ftrace_set_notrace(struct ftrace_ops *ops, unsigned char *buf,
+int ftrace_set_notrace(struct ftrace_ops *ops, const unsigned char *buf,
int len, int reset);
-void ftrace_set_global_filter(unsigned char *buf, int len, int reset);
-void ftrace_set_global_notrace(unsigned char *buf, int len, int reset);
+void ftrace_set_global_filter(const unsigned char *buf, int len, int reset);
+void ftrace_set_global_notrace(const unsigned char *buf, int len, int reset);
void ftrace_free_filter(struct ftrace_ops *ops);
int register_ftrace_command(struct ftrace_func_command *cmd);
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b5b0aca..6035c08 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3473,7 +3473,7 @@ match_records(struct ftrace_hash *hash, const char *buff,
}
static int
-ftrace_match_records(struct ftrace_hash *hash, char *buff, int len)
+ftrace_match_records(struct ftrace_hash *hash, const char *buff, int len)
{
return match_records(hash, buff, len, NULL, 0);
}
@@ -4040,7 +4040,7 @@ static void ftrace_ops_update_code(struct ftrace_ops *ops,
}
static int
-ftrace_set_hash(struct ftrace_ops *ops, unsigned char *buf, int len,
+ftrace_set_hash(struct ftrace_ops *ops, const unsigned char *buf, int len,
unsigned long ip, int remove, int reset, int enable)
{
struct ftrace_hash **orig_hash;
@@ -4123,7 +4123,7 @@ int ftrace_set_filter_ip(struct ftrace_ops *ops, unsigned
long ip,
EXPORT_SYMBOL_GPL(ftrace_set_filter_ip);
static int
-ftrace_set_regex(struct ftrace_ops *ops, unsigned char *buf, int len,
+ftrace_set_regex(struct ftrace_ops *ops, const unsigned char *buf, int len,
int reset, int enable)
{
return ftrace_set_hash(ops, buf, len, 0, 0, reset, enable);
@@ -4139,7 +4139,7 @@ ftrace_set_regex(struct ftrace_ops *ops, unsigned char
*buf, int len,
* Filters denote which functions should be enabled when tracing is enabled.
* If @buf is NULL and reset is set, all functions will be enabled for tracing.
*/
-int ftrace_set_filter(struct ftrace_ops *ops, unsigned char *buf,
+int ftrace_set_filter(struct ftrace_ops *ops, const unsigned char *buf,
int len, int reset)
{
ftrace_ops_init(ops);
@@ -4158,7 +4158,7 @@ EXPORT_SYMBOL_GPL(ftrace_set_filter);
* is enabled. If @buf is NULL and reset is set, all functions will be enabled
* for tracing.
*/
-int ftrace_set_notrace(struct ftrace_ops *ops, unsigned char *buf,
+int ftrace_set_notrace(struct ftrace_ops *ops, const unsigned char *buf,
int len, int reset)
{
ftrace_ops_init(ops);
@@ -4174,7 +4174,7 @@ EXPORT_SYMBOL_GPL(ftrace_set_notrace);
* Filters denote which functions should be enabled when tracing is enabled.
* If @buf is NULL and reset is set, all functions will be enabled for tracing.
*/
-void ftrace_set_global_filter(unsigned char *buf, int len, int reset)
+void ftrace_set_global_filter(const unsigned char *buf, int len, int reset)
{
ftrace_set_regex(_ops, buf, len, reset, 1);
}
@@ -4190,7 +4190,7 @@ EXPORT_SYMBOL_GPL(ftrace_set_global_filter);
* is enabled. If @buf is NULL and reset is set, all functions will be enabled
* for tracing.
*/
-void ftrace_set_global_notrace(unsigned char *buf, int len, int reset)
+void ftrace_set_global_notrace(const unsigned char *buf, int len, int reset)
{
ftrace_set_regex(_ops, buf, len, reset, 0);
}
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 5cefdd8..96ce797 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -2098,7 +2098,7 @@ ftrace_function_filter_re(char *buf, int len, int *count)
}
static int ftrace_function_set_regexp(struct ftrace_ops *ops, int filter,
- int reset, char *re, int len)
+ int reset, const char *re, int len)
{
int ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH] llist: Fix missing memory barrier
Hi Mathieu, On Thu, Feb 5, 2015 at 10:06 PM, Mathieu Desnoyers wrote: > A smp_read_barrier_depends() appears to be missing in llist_del_first(). > It should only matter for Alpha in practice. Adding it after the check > of entry against NULL allows skipping the barrier in a common case. We recently decided on using lockless_dereference() instead of hard-coding smp_read_barrier_depends()[1]. The advantage is that lockless_dereference() clearly shows what loads are being ordered. Could you resend the patch using that API? Thanks! [1] http://lkml.iu.edu/hypermail/linux/kernel/1410.3/04561.html > > Signed-off-by: Mathieu Desnoyers > CC: Huang Ying > CC: Paul McKenney > CC: David Howells > --- > lib/llist.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/llist.c b/lib/llist.c > index f76196d..72861f3 100644 > --- a/lib/llist.c > +++ b/lib/llist.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > > /** > @@ -72,6 +73,12 @@ struct llist_node *llist_del_first(struct llist_head *head) > if (entry == NULL) > return NULL; > old_entry = entry; > + /* > +* Load entry before entry->next. Matches the implicit > +* memory barrier before the cmpxchg in llist_add_batch(), > +* which ensures entry->next is stored before entry. > +*/ > + smp_read_barrier_depends(); > next = entry->next; > entry = cmpxchg(>first, old_entry, next); > if (entry == old_entry) > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-next v2 1/7] r8152: adjust rx_bottom
If a error occurs when submitting rx, skip the remaining submissions
and try to submit them again next time.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b74a272..41a1cbc 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1643,7 +1643,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
{
unsigned long flags;
struct list_head *cursor, *next, rx_queue;
- int work_done = 0;
+ int ret = 0, work_done = 0;
if (!skb_queue_empty(>rx_queue)) {
while (work_done < budget) {
@@ -1734,7 +1734,18 @@ find_next_rx:
}
submit:
- r8152_submit_rx(tp, agg, GFP_ATOMIC);
+ if (!ret) {
+ ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
+ } else {
+ urb->actual_length = 0;
+ list_add_tail(>list, next);
+ }
+ }
+
+ if (!list_empty(_queue)) {
+ spin_lock_irqsave(>rx_lock, flags);
+ list_splice_tail(_queue, >rx_done);
+ spin_unlock_irqrestore(>rx_lock, flags);
}
out1:
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 0/7] r8152: adjust the code
V2: Correct the subject of patch #5. Replace "link feed" with "line feed". v1: Code adjustment. Hayes Wang (7): r8152: adjust rx_bottom r8152: adjust lpm timer r8152: check linking status with netif_carrier_ok r8152: check RTL8152_UNPLUG for rtl8152_close r8152: adjust the line feed for hw_features r8152: replace get_protocol with vlan_get_protocol r8152: use BIT macro drivers/net/usb/r8152.c | 99 +++-- 1 file changed, 46 insertions(+), 53 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 2/7] r8152: adjust lpm timer
Set LPM timer to 500us, except for RTL_VER_04 which doesn't link at USB 3.0. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 41a1cbc..ff122fa 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3256,10 +3256,10 @@ static void r8153_init(struct r8152 *tp) ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_LPM_CTRL); ocp_data &= ~LPM_TIMER_MASK; - if (tp->udev->speed == USB_SPEED_SUPER) - ocp_data |= LPM_TIMER_500US; - else + if (tp->version == RTL_VER_04 && tp->udev->speed != USB_SPEED_SUPER) ocp_data |= LPM_TIMER_500MS; + else + ocp_data |= LPM_TIMER_500US; ocp_write_byte(tp, MCU_TYPE_USB, USB_LPM_CTRL, ocp_data); ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_AFE_CTRL2); -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 4/7] r8152: check RTL8152_UNPLUG for rtl8152_close
It is unnecessary to accress the hw register if the device is unplugged.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 6667809..aade7b5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3046,7 +3046,7 @@ static int rtl8152_close(struct net_device *netdev)
netif_stop_queue(netdev);
res = usb_autopm_get_interface(tp->intf);
- if (res < 0) {
+ if (res < 0 || test_bit(RTL8152_UNPLUG, >flags)) {
rtl_drop_queued_tx(tp);
rtl_stop_rx(tp);
} else {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 5/7] r8152: adjust the line feed for hw_features
Keep NETIF_F_HW_VLAN_CTAG_RX and NETIF_F_HW_VLAN_CTAG_TX at the same line. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index aade7b5..8bdd477 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3908,8 +3908,7 @@ static int rtl8152_probe(struct usb_interface *intf, netdev->hw_features = NETIF_F_RXCSUM | NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO | NETIF_F_FRAGLIST | NETIF_F_IPV6_CSUM | NETIF_F_TSO6 | - NETIF_F_HW_VLAN_CTAG_RX | - NETIF_F_HW_VLAN_CTAG_TX; + NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_TX; netdev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | NETIF_F_IPV6_CSUM | NETIF_F_TSO6; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 7/7] r8152: use BIT macro
Use BIT macro to replace (1 << bits).
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 24e6aef9..5980ac6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -489,16 +489,16 @@ struct rx_desc {
#define RX_LEN_MASK0x7fff
__le32 opts2;
-#define RD_UDP_CS (1 << 23)
-#define RD_TCP_CS (1 << 22)
-#define RD_IPV6_CS (1 << 20)
-#define RD_IPV4_CS (1 << 19)
+#define RD_UDP_CS BIT(23)
+#define RD_TCP_CS BIT(22)
+#define RD_IPV6_CS BIT(20)
+#define RD_IPV4_CS BIT(19)
__le32 opts3;
-#define IPF(1 << 23) /* IP checksum fail */
-#define UDPF (1 << 22) /* UDP checksum fail */
-#define TCPF (1 << 21) /* TCP checksum fail */
-#define RX_VLAN_TAG(1 << 16)
+#define IPFBIT(23) /* IP checksum fail */
+#define UDPF BIT(22) /* UDP checksum fail */
+#define TCPF BIT(21) /* TCP checksum fail */
+#define RX_VLAN_TAGBIT(16)
__le32 opts4;
__le32 opts5;
@@ -507,24 +507,24 @@ struct rx_desc {
struct tx_desc {
__le32 opts1;
-#define TX_FS (1 << 31) /* First segment of a packet */
-#define TX_LS (1 << 30) /* Final segment of a packet */
-#define GTSENDV4 (1 << 28)
-#define GTSENDV6 (1 << 27)
+#define TX_FS BIT(31) /* First segment of a packet */
+#define TX_LS BIT(30) /* Final segment of a packet */
+#define GTSENDV4 BIT(28)
+#define GTSENDV6 BIT(27)
#define GTTCPHO_SHIFT 18
#define GTTCPHO_MAX0x7fU
#define TX_LEN_MAX 0x3U
__le32 opts2;
-#define UDP_CS (1 << 31) /* Calculate UDP/IP checksum */
-#define TCP_CS (1 << 30) /* Calculate TCP/IP checksum */
-#define IPV4_CS(1 << 29) /* Calculate IPv4 checksum */
-#define IPV6_CS(1 << 28) /* Calculate IPv6 checksum */
+#define UDP_CS BIT(31) /* Calculate UDP/IP checksum */
+#define TCP_CS BIT(30) /* Calculate TCP/IP checksum */
+#define IPV4_CSBIT(29) /* Calculate IPv4 checksum */
+#define IPV6_CSBIT(28) /* Calculate IPv6 checksum */
#define MSS_SHIFT 17
#define MSS_MAX0x7ffU
#define TCPHO_SHIFT17
#define TCPHO_MAX 0x7ffU
-#define TX_VLAN_TAG(1 << 16)
+#define TX_VLAN_TAGBIT(16)
};
struct r8152;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 3/7] r8152: check linking status with netif_carrier_ok
Replace (tp->speed & LINK_STATUS) with netif_carrier_ok().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ff122fa..6667809 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -581,7 +581,6 @@ struct r8152 {
u16 ocp_base;
u8 *intr_buff;
u8 version;
- u8 speed;
};
enum rtl_version {
@@ -1157,12 +1156,12 @@ static void intr_callback(struct urb *urb)
d = urb->transfer_buffer;
if (INTR_LINK & __le16_to_cpu(d[0])) {
- if (!(tp->speed & LINK_STATUS)) {
+ if (!netif_carrier_ok(tp->netdev)) {
set_bit(RTL8152_LINK_CHG, >flags);
schedule_delayed_work(>schedule, 0);
}
} else {
- if (tp->speed & LINK_STATUS) {
+ if (netif_carrier_ok(tp->netdev)) {
set_bit(RTL8152_LINK_CHG, >flags);
schedule_delayed_work(>schedule, 0);
}
@@ -1894,7 +1893,7 @@ static void rtl8152_set_rx_mode(struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- if (tp->speed & LINK_STATUS) {
+ if (netif_carrier_ok(netdev)) {
set_bit(RTL8152_SET_RX_MODE, >flags);
schedule_delayed_work(>schedule, 0);
}
@@ -2918,21 +2917,20 @@ static void set_carrier(struct r8152 *tp)
speed = rtl8152_get_speed(tp);
if (speed & LINK_STATUS) {
- if (!(tp->speed & LINK_STATUS)) {
+ if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, >flags);
netif_carrier_on(netdev);
rtl_start_rx(tp);
}
} else {
- if (tp->speed & LINK_STATUS) {
+ if (netif_carrier_ok(netdev)) {
netif_carrier_off(netdev);
napi_disable(>napi);
tp->rtl_ops.disable(tp);
napi_enable(>napi);
}
}
- tp->speed = speed;
}
static void rtl_work_func_t(struct work_struct *work)
@@ -2964,7 +2962,7 @@ static void rtl_work_func_t(struct work_struct *work)
/* don't schedule napi before linking */
if (test_bit(SCHEDULE_NAPI, >flags) &&
- (tp->speed & LINK_STATUS)) {
+ netif_carrier_ok(tp->netdev)) {
clear_bit(SCHEDULE_NAPI, >flags);
napi_schedule(>napi);
}
@@ -2987,8 +2985,7 @@ static int rtl8152_open(struct net_device *netdev)
if (res)
goto out;
- /* set speed to 0 to avoid autoresume try to submit rx */
- tp->speed = 0;
+ netif_carrier_off(netdev);
res = usb_autopm_get_interface(tp->intf);
if (res < 0) {
@@ -3005,7 +3002,7 @@ static int rtl8152_open(struct net_device *netdev)
cancel_delayed_work_sync(>schedule);
/* disable the tx/rx, if the workqueue has enabled them. */
- if (tp->speed & LINK_STATUS)
+ if (netif_carrier_ok(netdev))
tp->rtl_ops.disable(tp);
}
@@ -3014,7 +3011,6 @@ static int rtl8152_open(struct net_device *netdev)
rtl8152_set_speed(tp, AUTONEG_ENABLE,
tp->mii.supports_gmii ? SPEED_1000 : SPEED_100,
DUPLEX_FULL);
- tp->speed = 0;
netif_carrier_off(netdev);
netif_start_queue(netdev);
set_bit(WORK_ENABLE, >flags);
@@ -3340,7 +3336,7 @@ static int rtl8152_resume(struct usb_interface *intf)
rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, >flags);
set_bit(WORK_ENABLE, >flags);
- if (tp->speed & LINK_STATUS)
+ if (netif_carrier_ok(tp->netdev))
rtl_start_rx(tp);
} else {
tp->rtl_ops.up(tp);
@@ -3348,7 +3344,6 @@ static int rtl8152_resume(struct usb_interface *intf)
tp->mii.supports_gmii ?
SPEED_1000 : SPEED_100,
DUPLEX_FULL);
- tp->speed = 0;
netif_carrier_off(tp->netdev);
set_bit(WORK_ENABLE, >flags);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 6/7] r8152: replace get_protocol with vlan_get_protocol
vlan_get_protocol() has been defined and use it to replace
get_protocol().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8bdd477..24e6aef9 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1330,18 +1330,6 @@ static struct tx_agg *r8152_get_tx_agg(struct r8152 *tp)
return agg;
}
-static inline __be16 get_protocol(struct sk_buff *skb)
-{
- __be16 protocol;
-
- if (skb->protocol == htons(ETH_P_8021Q))
- protocol = vlan_eth_hdr(skb)->h_vlan_encapsulated_proto;
- else
- protocol = skb->protocol;
-
- return protocol;
-}
-
/* r8152_csum_workaround()
* The hw limites the value the transport offset. When the offset is out of the
* range, calculate the checksum by sw.
@@ -1447,7 +1435,7 @@ static int r8152_tx_csum(struct r8152 *tp, struct tx_desc
*desc,
goto unavailable;
}
- switch (get_protocol(skb)) {
+ switch (vlan_get_protocol(skb)) {
case htons(ETH_P_IP):
opts1 |= GTSENDV4;
break;
@@ -1478,7 +1466,7 @@ static int r8152_tx_csum(struct r8152 *tp, struct tx_desc
*desc,
goto unavailable;
}
- switch (get_protocol(skb)) {
+ switch (vlan_get_protocol(skb)) {
case htons(ETH_P_IP):
opts2 |= IPV4_CS;
ip_protocol = ip_hdr(skb)->protocol;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Question] should we export set_suspend_voltage()?
Hi, Liam & Mark:
seems at present, the set_suspend_voltage() is designed to cover the suspend
voltage handling from board level, when the system enters into the suspend;
but the behavior of my chip is as following:
a) there are two sets of registers to configure one regulator's voltage
separately, one is for active mode, the other is for the low power mode, say,
suspend-to-ram;
b) both of the sets have control bits independently;
c) once the low power mode is triggered, by external signal, for example,
pull-down a gpio, the regulator switches to use the registers for low power
mode;
d) the consumers have different requirements for the voltage in low power mode
according to different scenario, IOW, we cannot assume a fix value when system
boots up;
So
do you think it's good to export the set_suspend_voltage()? to make it
controllable by the regulator itself?
another method in my opinion is add a set of virtual-regulator for this usage?
could you please share your advice?
thanks very much;
--
Yi
ZhangN�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] llist: Fix missing memory barrier
A smp_read_barrier_depends() appears to be missing in llist_del_first(). It should only matter for Alpha in practice. Adding it after the check of entry against NULL allows skipping the barrier in a common case. Signed-off-by: Mathieu Desnoyers CC: Huang Ying CC: Paul McKenney CC: David Howells --- lib/llist.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/lib/llist.c b/lib/llist.c index f76196d..72861f3 100644 --- a/lib/llist.c +++ b/lib/llist.c @@ -26,6 +26,7 @@ #include #include #include +#include /** @@ -72,6 +73,12 @@ struct llist_node *llist_del_first(struct llist_head *head) if (entry == NULL) return NULL; old_entry = entry; + /* +* Load entry before entry->next. Matches the implicit +* memory barrier before the cmpxchg in llist_add_batch(), +* which ensures entry->next is stored before entry. +*/ + smp_read_barrier_depends(); next = entry->next; entry = cmpxchg(>first, old_entry, next); if (entry == old_entry) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 4/11] xfsprogs: xfs_io: add finsert command for insert range
Hi Namjae, On Fri, Feb 06, 2015 at 10:40:33AM +1100, Dave Chinner wrote: > On Thu, Jan 22, 2015 at 12:11:59AM +0900, Namjae Jeon wrote: > > From: Namjae Jeon > > > > Add finsert command for fallocate FALLOC_FL_INSERT_RANGE flag. > > > > Signed-off-by: Namjae Jeon > > Signed-off-by: Ashish Sangwan > > Reviewed-by: Brian Foster > > I've just pulled this patch into xfsprogs in preparation for getting > this functionality fully reviewed and merged in the 3.21 kernel > cycle. xfs/293 3s ... - output mismatch (see /home/dave/src/xfstests-dev/results//xfs/293.out.bad) --- tests/xfs/293.out 2014-01-20 16:57:34.0 +1100 +++ /home/dave/src/xfstests-dev/results//xfs/293.out.bad2015-02-06 12:21:47.0 +1100 @@ -1,2 +1,3 @@ QA output created by 293 Silence is golden +finsert not documented in the xfs_io manpage . Can you send a patch that updates the xfs_io man page, please? Cheers, Dave. -- Dave Chinner da...@fromorbit.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/
[RFC][PATCH] perf: Implement read_group() PMU operation
From: Sukadev Bhattiprolu
Date: Thu Feb 5 20:56:20 EST 2015 -0300
Subject: [RFC][PATCH] perf: Implement read_group() PMU operation
This is a lightly tested, exploratory patch to allow PMUs to return
several counters at once. Appreciate any comments :-)
Unlike normal hardware PMCs, the 24x7 counters[1] in Power8 are stored
in memory and accessed via a hypervisor call (HCALL). A major aspect
of the HCALL is that it allows retireving _SEVERAL_ counters at once
(unlike regular PMCs, which are read one at a time).
This patch implements a ->read_group() PMU operation that tries to
take advantage of this ability to read several counters at once. A
PMU that implements the ->read_group() operation would allow users
to retrieve several counters at once and get a more consistent
snapshot.
NOTE: This patch has a TODO in h_24x7_event_read_group() in that it
still does multiple HCALLS. I think that can be optimized
independently, once the pmu->read_group() interface itself is
finalized.
Appreciate comments on the ->read_group interface and best managing the
interfaces between the core and PMU layers - eg: Ok for hv-24x7 PMU to
to walk the ->sibling_list ?
[1] Some notes about 24x7 counters:
Power8 supports 24x7 counters[1] which differ from traditional PMCs
in several ways:
- The 24x7 counters are always on and counting. Rather than
start/stop the PMCs, we read/report the _change_ in values
in the counters during the execution of the workload.
- The 24x7 counters are not tied to a task context (they are
always on).
- Rather than reading the event counts from registers, we make
a hypervisor call (HCALL) to retrieve counts. The HCALL allows
retrieving a large number of counters in a single call.
- These counters don't generate interrupts when they overflow (so
sampling does not apply to these counters).
---
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d36314..b69fbdf 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -232,6 +232,13 @@ struct pmu {
void (*read)(struct perf_event *event);
/*
+* Read a group of counters.
+*/
+ int (*read_group) (struct perf_event *event,
+ u64 *values,
+ int ncounters);
+
+ /*
* Group events scheduling is treated as a transaction, add
* group events as a whole and perform one schedulability test.
* If the test fails, roll back the whole group
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 934687f..026a9d0 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3549,10 +3549,43 @@ static int perf_event_read_group(struct perf_event
*event,
struct perf_event *leader = event->group_leader, *sub;
int n = 0, size = 0, ret = -EFAULT;
struct perf_event_context *ctx = leader->ctx;
+ u64 *valuesp;
u64 values[5];
+ int use_group_read;
u64 count, enabled, running;
+ struct pmu *pmu = event->pmu;
+
+ /*
+* If PMU supports group read and group read is requested,
+* allocate memory before taking the mutex.
+*/
+ use_group_read = 0;
+ if ((read_format & PERF_FORMAT_GROUP) && pmu->read_group) {
+ use_group_read++;
+ }
+
+ if (use_group_read) {
+ valuesp = kzalloc(leader->nr_siblings * sizeof(u64),
GFP_KERNEL);
+ if (!valuesp)
+ return -ENOMEM;
+ }
mutex_lock(>mutex);
+
+ if (use_group_read) {
+ ret = pmu->read_group(leader, valuesp, leader->nr_siblings);
+ if (ret >= 0) {
+ size = ret * sizeof(u64);
+
+ ret = size;
+ if (copy_to_user(buf, valuesp, size))
+ ret = -EFAULT;
+ }
+
+ kfree(valuesp);
+ goto unlock;
+ }
+
count = perf_event_read_value(leader, , );
values[n++] = 1 + leader->nr_siblings;
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 9445a82..cd48cf0 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1071,12 +1071,33 @@ static int h_24x7_event_init(struct perf_event *event)
struct hv_perf_caps caps;
unsigned domain;
unsigned long hret;
+ u64 read_format, inv_flags;
u64 ct;
/* Not our event */
if (event->attr.type != event->pmu->type)
return -ENOENT;
+ /*
+* We don't support enabled/running times with PERF_FORMAT_GROUP.
+* The ->read_group() operation is intended to be used in continous
+* monitoring mode, so these time values are
Re: [PATCH v8 2/2] drivers/gpio: Altera soft IP GPIO driver
On Wed, 2015-01-14 at 10:58 +0100, Linus Walleij wrote:
> On Wed, Dec 24, 2014 at 9:22 AM, wrote:
>
> > From: Tien Hock Loh
> >
> > Adds a new driver for Altera soft GPIO IP. The driver is able to
> > do read/write and allows GPIO to be a interrupt controller.
> >
> > Tested on Altera GHRD on interrupt handling and IO.
> >
> > Signed-off-by: Tien Hock Loh
>
> (...)
> > +config GPIO_ALTERA
> > + tristate "Altera GPIO"
> > + depends on OF_GPIO
>
> select GPIOLIB_IRQCHIP
>
> Also, I think (see below)
>
> select GENERIC_GPIO
>
> > +#include
>
> #include
>
> should be just fine instead of this old header.
>
> > +#include
> > +#include
> > +#include
> > +#include
>
> Should not be needed.
>
> > +#include
> > +#include
>
> None of these should be needed.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> #include
>
> with GENERIC_GPIO (see below).
OK
> > +
> > +#define ALTERA_GPIO_MAX_NGPIO 32
> > +#define ALTERA_GPIO_DATA 0x0
> > +#define ALTERA_GPIO_DIR0x4
> > +#define ALTERA_GPIO_IRQ_MASK 0x8
> > +#define ALTERA_GPIO_EDGE_CAP 0xc
> > +
> > +/**
> > +* struct altera_gpio_chip
> > +* @mmchip : memory mapped chip structure.
> > +* @gpio_lock : synchronization lock so that new irq/set/get
> > requests
> > + will be blocked until the current one completes.
> > +* @interrupt_trigger : specifies the hardware configured IRQ trigger type
> > + (rising, falling, both, high)
> > +* @mapped_irq : kernel mapped irq number.
> > +*/
> > +struct altera_gpio_chip {
> > + struct of_mm_gpio_chip mmchip;
> > + spinlock_t gpio_lock;
> > + int interrupt_trigger;
> > + int mapped_irq;
> > +};
> > +
> > +static void altera_gpio_irq_unmask(struct irq_data *d)
> > +{
> > + struct altera_gpio_chip *altera_gc;
> > + struct of_mm_gpio_chip *mm_gc;
> > + unsigned long flags;
> > + u32 intmask;
> > +
> > + altera_gc = irq_data_get_irq_chip_data(d);
> > + mm_gc = _gc->mmchip;
> > +
> > + spin_lock_irqsave(_gc->gpio_lock, flags);
> > + intmask = readl(mm_gc->regs + ALTERA_GPIO_IRQ_MASK);
> > + /* Set ALTERA_GPIO_IRQ_MASK bit to unmask */
> > + intmask |= BIT(irqd_to_hwirq(d));
> > + writel(intmask, mm_gc->regs + ALTERA_GPIO_IRQ_MASK);
> > + spin_unlock_irqrestore(_gc->gpio_lock, flags);
> > +}
> > +
> > +static void altera_gpio_irq_mask(struct irq_data *d)
> > +{
> > + struct altera_gpio_chip *altera_gc;
> > + struct of_mm_gpio_chip *mm_gc;
> > + unsigned long flags;
> > + u32 intmask;
> > +
> > + altera_gc = irq_data_get_irq_chip_data(d);
> > + mm_gc = _gc->mmchip;
> > +
> > + spin_lock_irqsave(_gc->gpio_lock, flags);
> > + intmask = readl(mm_gc->regs + ALTERA_GPIO_IRQ_MASK);
> > + /* Clear ALTERA_GPIO_IRQ_MASK bit to mask */
> > + intmask &= ~BIT(irqd_to_hwirq(d));
> > + writel(intmask, mm_gc->regs + ALTERA_GPIO_IRQ_MASK);
> > + spin_unlock_irqrestore(_gc->gpio_lock, flags);
> > +}
> > +
> > +static int altera_gpio_irq_set_type(struct irq_data *d,
> > + unsigned int type)
> > +{
> > + struct altera_gpio_chip *altera_gc = irq_data_get_irq_chip_data(d);
> > +
> > + altera_gc = irq_data_get_irq_chip_data(d);
> > +
> > + if (type == IRQ_TYPE_NONE)
> > + return 0;
> > + if (type == IRQ_TYPE_LEVEL_HIGH &&
> > + altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH)
> > + return 0;
> > + if (type == IRQ_TYPE_EDGE_RISING &&
> > + altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_RISING)
> > + return 0;
> > + if (type == IRQ_TYPE_EDGE_FALLING &&
> > + altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_FALLING)
> > + return 0;
> > + if (type == IRQ_TYPE_EDGE_BOTH &&
> > + altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_BOTH)
> > + return 0;
> > +
> > + return -EINVAL;
> > +}
>
> It took me a while to understand this. Write in a comment that
> this is a hardware that is synthesized for a specific trigger
> type, and that there is no way to software-configure the
> trigger type.
>
OK noted.
> > +
> > +static unsigned int altera_gpio_irq_startup(struct irq_data *d)
> > +{
> > + altera_gpio_irq_unmask(d);
> > +
> > + return 0;
> > +}
> > +
> > +static void altera_gpio_irq_shutdown(struct irq_data *d)
> > +{
> > + altera_gpio_irq_mask(d);
> > +}
>
> Instead of those pointless functions just assign
> the unmask/mask functions in the vtable right below.
>
OK
> > +
> > +static struct irq_chip altera_irq_chip = {
> > + .name = "altera-gpio",
> > + .irq_mask = altera_gpio_irq_mask,
> > + .irq_unmask =
Re: [PATCH v5 3/5] x86: Split syscall_trace_enter into two phases
On Thu, Feb 5, 2015 at 6:32 PM, Dmitry V. Levin wrote: > On Thu, Feb 05, 2015 at 04:09:06PM -0800, Andy Lutomirski wrote: >> On Thu, Feb 5, 2015 at 3:49 PM, Kees Cook wrote: >> > On Thu, Feb 5, 2015 at 3:39 PM, Dmitry V. Levin wrote: > [...] >> >> There is a clear difference: before these changes, SECCOMP_RET_ERRNO used >> >> to keep the syscall number unchanged and suppress syscall-exit-stop event, >> >> which was awful because userspace cannot distinguish syscall-enter-stop >> >> from syscall-exit-stop and therefore relies on the kernel that >> >> syscall-enter-stop is followed by syscall-exit-stop (or tracee's death, >> >> etc.). >> >> >> >> After these changes, SECCOMP_RET_ERRNO no longer causes syscall-exit-stop >> >> events to be suppressed, but now the syscall number is lost. >> > >> > Ah-ha! Okay, thanks, I understand now. I think this means seccomp >> > phase1 should not treat RET_ERRNO as a "skip" event. Andy, what do you >> > think here? >> >> I still don't quite see how this change caused this. > > I have a test for this at > http://sourceforge.net/p/strace/code/ci/HEAD/~/tree/test/seccomp.c > >> I can play with >> it a bit more. But RET_ERRNO *has* to be some kind of skip event, >> because it needs to skip the syscall. >> >> We could change this by treating RET_ERRNO as an instruction to enter >> phase 2 and then asking for a skip in phase 2 without changing >> orig_ax, but IMO this is pretty ugly. >> >> I think this all kind of sucks. We're trying to run ptrace after >> seccomp, so ptrace is seeing the syscalls as transformed by seccomp. >> That means that if we use RET_TRAP, then ptrace will see the >> possibly-modified syscall, if we use RET_ERRNO, then ptrace is (IMO >> correctly given the current design) showing syscall -1, and if we use >> RET_KILL, then ptrace just sees the process mysteriously die. > > Userspace is usually not prepared to see syscall -1. > For example, strace had to be patched, otherwise it just skipped such > syscalls as "not a syscall" events or did other improper things: > http://sourceforge.net/p/strace/code/ci/c3948327717c29b10b5e00a436dc138b4ab1a486 > http://sourceforge.net/p/strace/code/ci/8e398b6c4020fb2d33a5b3e40271ebf63199b891 > The x32 thing is a legit ABI bug, I'd argue. I'd be happy to submit a patch to fix that (clear the x32 bit if we're not x32). > A slightly different but related story: userspace is also not prepared > to handle large errno values produced by seccomp filters like this: > BPF_STMT(BPF_RET, SECCOMP_RET_ERRNO | SECCOMP_RET_DATA) > > For example, glibc assumes that syscalls do not return errno values greater > than 0xfff: > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sysdep.h#l55 > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/syscall.S#l20 > > If it isn't too late, I'd recommend changing SECCOMP_RET_DATA mask > applied in SECCOMP_RET_ERRNO case from current 0x to 0xfff. I think this is solidly in the "don't do that" category. Seccomp lets you tamper with syscalls. If you tamper wrong, then you lose. Kees, what do you think about reversing the whole thing so that ptracers always see the original syscall? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [alsa-devel] [PATCH baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static
2015-02-06 1:11 GMT+08:00 Mark Brown : > On Fri, Feb 06, 2015 at 01:03:52AM +0800, kbuild test robot wrote: >> sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' >> was not declared. Should it be static? > > This file isn't in an upstream tree, should this patch have been sent > upstream (I suspect non-upstream trees may need a bit of filtering in > the scripts)? the file is new and under developing. so no patch for it yet. is it possible to modify kbuild script? > > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -barry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/5] x86: Split syscall_trace_enter into two phases
On Thu, Feb 05, 2015 at 04:09:06PM -0800, Andy Lutomirski wrote: > On Thu, Feb 5, 2015 at 3:49 PM, Kees Cook wrote: > > On Thu, Feb 5, 2015 at 3:39 PM, Dmitry V. Levin wrote: [...] > >> There is a clear difference: before these changes, SECCOMP_RET_ERRNO used > >> to keep the syscall number unchanged and suppress syscall-exit-stop event, > >> which was awful because userspace cannot distinguish syscall-enter-stop > >> from syscall-exit-stop and therefore relies on the kernel that > >> syscall-enter-stop is followed by syscall-exit-stop (or tracee's death, > >> etc.). > >> > >> After these changes, SECCOMP_RET_ERRNO no longer causes syscall-exit-stop > >> events to be suppressed, but now the syscall number is lost. > > > > Ah-ha! Okay, thanks, I understand now. I think this means seccomp > > phase1 should not treat RET_ERRNO as a "skip" event. Andy, what do you > > think here? > > I still don't quite see how this change caused this. I have a test for this at http://sourceforge.net/p/strace/code/ci/HEAD/~/tree/test/seccomp.c > I can play with > it a bit more. But RET_ERRNO *has* to be some kind of skip event, > because it needs to skip the syscall. > > We could change this by treating RET_ERRNO as an instruction to enter > phase 2 and then asking for a skip in phase 2 without changing > orig_ax, but IMO this is pretty ugly. > > I think this all kind of sucks. We're trying to run ptrace after > seccomp, so ptrace is seeing the syscalls as transformed by seccomp. > That means that if we use RET_TRAP, then ptrace will see the > possibly-modified syscall, if we use RET_ERRNO, then ptrace is (IMO > correctly given the current design) showing syscall -1, and if we use > RET_KILL, then ptrace just sees the process mysteriously die. Userspace is usually not prepared to see syscall -1. For example, strace had to be patched, otherwise it just skipped such syscalls as "not a syscall" events or did other improper things: http://sourceforge.net/p/strace/code/ci/c3948327717c29b10b5e00a436dc138b4ab1a486 http://sourceforge.net/p/strace/code/ci/8e398b6c4020fb2d33a5b3e40271ebf63199b891 A slightly different but related story: userspace is also not prepared to handle large errno values produced by seccomp filters like this: BPF_STMT(BPF_RET, SECCOMP_RET_ERRNO | SECCOMP_RET_DATA) For example, glibc assumes that syscalls do not return errno values greater than 0xfff: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sysdep.h#l55 https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/syscall.S#l20 If it isn't too late, I'd recommend changing SECCOMP_RET_DATA mask applied in SECCOMP_RET_ERRNO case from current 0x to 0xfff. -- ldv -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.
The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
While in different platform and different requirements this seems improper.
So modifing the IO_TLB_SEGSIZE to io_tlb_segsize which can
configure by kernel cmdline.
Signed-off-by: Chuansheng Liu
Signed-off-by: Zhang Dongxing
Signed-off-by: Wang Xiaoming
---
patch v1 make this change at Kconfig
which needs to edit the .config manually.
https://lkml.org/lkml/2015/1/25/571
arch/mips/cavium-octeon/dma-octeon.c |2 +-
arch/mips/netlogic/common/nlm-dma.c |2 +-
drivers/xen/swiotlb-xen.c|6 +++---
include/linux/swiotlb.h |8 +--
lib/swiotlb.c| 39 --
5 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/arch/mips/cavium-octeon/dma-octeon.c
b/arch/mips/cavium-octeon/dma-octeon.c
index 3778655..a521af6 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -312,7 +312,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 64 * (1<<20);
#endif
swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs << IO_TLB_SHIFT;
octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/arch/mips/netlogic/common/nlm-dma.c
b/arch/mips/netlogic/common/nlm-dma.c
index f3d4ae8..eeffa8f 100644
--- a/arch/mips/netlogic/common/nlm-dma.c
+++ b/arch/mips/netlogic/common/nlm-dma.c
@@ -99,7 +99,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 1 << 20; /* 1 MB for now */
swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs << IO_TLB_SHIFT;
nlm_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..3b3e9fe 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -164,11 +164,11 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
dma_addr_t dma_handle;
phys_addr_t p = virt_to_phys(buf);
- dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
+ dma_bits = get_order(io_tlb_segsize << IO_TLB_SHIFT) + PAGE_SHIFT;
i = 0;
do {
- int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
+ int slabs = min(nslabs - i, (unsigned long)io_tlb_segsize);
do {
rc = xen_create_contiguous_region(
@@ -187,7 +187,7 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
{
if (!nr_tbl) {
xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
- xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
+ xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, io_tlb_segsize);
} else
xen_io_tlb_nslabs = nr_tbl;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e7a018e..13506db 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -8,13 +8,7 @@ struct dma_attrs;
struct scatterlist;
extern int swiotlb_force;
-
-/*
- * Maximum allowable number of contiguous slabs to map,
- * must be a power of 2. What is the appropriate value ?
- * The complexity of {map,unmap}_single is linearly dependent on this value.
- */
-#define IO_TLB_SEGSIZE 128
+extern int io_tlb_segsize;
/*
* log of the size of each IO TLB slab. The number of slabs is command line
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 4abda07..50c415a 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -56,6 +56,15 @@
int swiotlb_force;
/*
+ * Maximum allowable number of contiguous slabs to map,
+ * must be a power of 2. What is the appropriate value ?
+ * define io_tlb_segsize as a parameter
+ * which can be changed dynamically in config file for special usage.
+ * The complexity of {map,unmap}_single is linearly dependent on this value.
+ */
+int io_tlb_segsize = 128;
+
+/*
* Used to do a quick range check in swiotlb_tbl_unmap_single and
* swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
* API.
@@ -97,12 +106,20 @@ static DEFINE_SPINLOCK(io_tlb_lock);
static int late_alloc;
static int __init
+setup_io_tlb_segsize(char *str)
+{
+ get_option(, _tlb_segsize);
+ return 0;
+}
+__setup("io_tlb_segsize=", setup_io_tlb_segsize);
+
+static int __init
setup_io_tlb_npages(char *str)
{
if (isdigit(*str)) {
io_tlb_nslabs = simple_strtoul(str, , 0);
- /* avoid tail segment of size < IO_TLB_SEGSIZE */
- io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
+ /* avoid tail segment of size < io_tlb_segsize */
+ io_tlb_nslabs =
Re: [RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series
On Thu, Feb 5, 2015 at 8:49 PM, Dmitry Torokhov wrote: > On Thu, Feb 05, 2015 at 05:33:07PM -0800, Andrew Duggan wrote: >> On 02/05/2015 12:38 PM, Benjamin Tissoires wrote: >> >Lenovos 2015 series has the physical tracktick buttons wired >> >through the touchpad. The kernel should re-route them through >> >the pass-through interface. >> > >> >Signed-off-by: Benjamin Tissoires >> >--- >> > >> >Hi Dmitry, >> > >> >Well, in one of your replies regarding the Synaptics Lenovo 2015 >> >series, you mentioned that you wouldn't mind having the trackstick >> >buttons re-routed through the trackstick (pass-through interface). >> > >> >I came out with this patch (checkpatch complains a lot about it but >> >today's setup is not that convenient), and I'd like to hear what you >> >think of it. >> > >> >If you agree to go this path, I'll remove the warnings from checkpatch >> >and do a proper submission. >> > >> >The patch is still not future proof (if Synaptics updates the board like >> >they did for the *40 series, we will need to fix this all over again), >> >so I might have a little bit more of work to do. Anyway, it works. >> >> I discovered that there is a firmware query to determine if the >> touchpad has stick buttons which are wired to the touchpad and are >> reported as extended buttons. Query $01 bit 17 indicates that Query >> $10 exists. Then Query $10 bit 0 indicates indicates the extended >> buttons should be mapped to the guest stick buttons. >> >> Additional information and some diagrams are in the pdf here: >> https://www.dropbox.com/s/vv1j4zsytgrw7mm/synaptics-tp-stick-buttons.pdf?dl=0 > > Awesome, thanks Andrew. > Yep, definitively awesome. Also the firmware bump when you will fix the auto-repeat key will greatly help us. I'll prepare a patch series tomorrow! Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 02/05/15 07:45, Quentin Lambert wrote: > > On 05/02/2015 00:26, Stephen Boyd wrote: >>> If you want me to I can enlarge the search to other directories. >> Yes please do. And if you could share the coccinelle patch that would be >> great. Thanks. >> > structclk.cocci is the coccinelle patch > structclk-arm.patch is the result I got when applying it to the > arch/arm directory > > Is there anything else I can do to help? > > Thanks for the coccinelle patch. Thinking more about it, I don't think we care if the pointer is dereferenced because that would require a definition of struct clk and that is most likely not the case outside of the clock framework. Did you scan the entire kernel? I'm running it now but it seems to be taking a while. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 08/13] mtd: st_spi_fsm: Update the JEDEC probe to handle extended READIDs
On Wed, Jan 21, 2015 at 01:02:04PM +, Lee Jones wrote: > On Mon, 12 Jan 2015, Brian Norris wrote: > > On Mon, Dec 15, 2014 at 11:59:15AM +, Lee Jones wrote: > > > The previous code was based on 3-byte JEDEC IDs, with a possible 2-byte > > > extension. However, devices are now emerging that return 6 or more bytes > > > of > > > READID data and the additional bytes are required to differentiate between > > > variants or generations of similar devices. > > > > > > This patch refactors the device table and JEDEC probe code to handle > > > arbitrary > > > length READIDs, with the standard JEDEC definition now becoming a special > > > case. > > > Functionally, there should be no change in behaviour. A subsequent patch > > > will > > > update the table with extended READIDs where applicable. > > > > BTW, how's that promise going, where you work on adapting this driver to > > the spi-nor framework? We've already done some of this same work there. > > I have pushed this point within ST and someone has agreed to do the > work. Last I heard it relied on these patches, but I'll ask again. OK. > > > +#define RDID(...) __VA_ARGS__ /* Dummy macro to protect array argument. > > > */ > > > > What? What needs "protected"? > > You're asking me questions I can't answer I'm afraid and Angus has now > left the building. I guess he thinks __VA_ARGS__ will prevent some > kind of overflow? If you don't understand your own code, how can I be expected to maintain it? This one's pretty trivial and harmless, but an accumulation of answers like this don't exactly put me in a good mood. FWIW, I expect the comment has nothing to do with the __VA_ARGS__; it's just commenting that he has placed a macro around the array just in case somebody needs/wants to rearrange formats later. That way, we don't necessarily have to rewrite the whole table, but can just change the macros. So the __VA_ARGS__ is just there to make the compiler happy (it thinks an array argument to a macro actually looks like more than one argument), and the comment is only mildly descriptive of its purpose. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/13] mtd: st_spi_fsm: Align with ST's internal development
On Wed, Jan 21, 2015 at 12:49:30PM +, Lee Jones wrote: > On Mon, 12 Jan 2015, Brian Norris wrote: > > Typically "simpler" and "reducing the cost of having lots of extra DT > > properties" aren't good enough reasons for immediately breaking an > > existing DT binding. We usually expect to support both for some period > > of time. > > Only once a binding has became ABI. As there are no users of this > driver yet (this will change after this sync'ing patch-set has been > applied), so we can safely consider this binding to be in-progress and > as such, not yet ABI, thus we can do this ol' switch-aroo without the > usual 6 month deprecation period. OK, fine with me. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Input - synaptics: do not release extra buttons once they are pressed
On 02/04/2015 01:29 PM, Benjamin Tissoires wrote: On Feb 02 2015 or thereabouts, Benjamin Tissoires wrote: On Mon, Feb 2, 2015 at 4:46 PM, Dmitry Torokhov wrote: On Wed, Jan 28, 2015 at 03:10:05PM -0500, Benjamin Tissoires wrote: The current code releases the extra buttons right after they are pressed. As soon as a new serio report comes in, the hw state is reset to 0 and so the buttons are released. Check for the report type before acting on the current extra buttons state. No: "If Ext is 0 (if bit 1 of bytes 1 and 4 are the same) then there are no external buttons being pressed (or all external buttons have been released)." - Synaptics PS/2 TouchPad Interfacing Guide PN: 511-000275-01 Rev. B Hmm, indeed, the current code follows the spec. Yeah! a new firmware bug! So when I dumped the ps/2 reports, I clearly saw the release report being sent with the Ext bit to 1, and other reports were in between with no information (because no fingers were on the touchpad). OK, so with the hardware, here are the results: After each incoming event (being a button or touch), when there is no more information to send (i.e. touch released or button pressed or released), I receive 80 times the following buffer: 80 00 00 c0 00 00 The number 80 seems quite consistant, though I got once 96. Not sure that this repeated buffer might be of interest however. When a finger is touched on the sensor, I receive the following: b0 ba 35 c0 8d ed <- first finger down on the sensor b0 ba 3b c0 6f d0 b0 ba 3b c2 6d d0 <- button 1 pressed b0 ba 3b c0 6f d0 b0 ba 3b c0 6f d0 b0 ba 3c c2 6c d0 <- button 1 released b0 ba 3c c0 6f d0 90 ba 26 c0 6f d0 80 00 00 c0 00 00 <- first finger released from the sensor 80 00 00 c0 00 00 <- repeated 80 times So here, either the spec is wrong, either the Synaptics with FW 8.1 in the Lenovos are not following it. But I clearly see that the extended buttons are reported only when the Ext bit is 1. Andrew, could you help us determine which way to go? Ideally, could you point out at a firmware version where we could be sure that the spec has not been followed so we can add a quirk in the driver? I got confirmation that this is a firmware bug and that it has probably been there since 2011. This bug is definitely in 8.1 and probably several versions before it. But, we haven't shipped anything with extended buttons in a long time, so applying the quirk to firmware revision 8.1 should be adequate. When we fix the bug we will bump the minor version. Andrew Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i40e: fix sparse warning
On Thu, 2015-02-05 at 15:13 +, Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > this patch fixes following sparse warning: > > i40e_lan_hmc.c:911:24: warning: constant 0x is so big > it is unsigned long > > Signed-off-by: Lad, Prabhakar > --- > Found this issue on linux-next (gcc version 4.8.2, > sparse version 0.4.5-rc1)and applies on top linux-next. > > drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I already have a fix in my queue to resolve this issue, so I am dropping your patch. signature.asc Description: This is a digitally signed message part
Re: [RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series
On Thu, Feb 05, 2015 at 05:33:07PM -0800, Andrew Duggan wrote: > On 02/05/2015 12:38 PM, Benjamin Tissoires wrote: > >Lenovos 2015 series has the physical tracktick buttons wired > >through the touchpad. The kernel should re-route them through > >the pass-through interface. > > > >Signed-off-by: Benjamin Tissoires > >--- > > > >Hi Dmitry, > > > >Well, in one of your replies regarding the Synaptics Lenovo 2015 > >series, you mentioned that you wouldn't mind having the trackstick > >buttons re-routed through the trackstick (pass-through interface). > > > >I came out with this patch (checkpatch complains a lot about it but > >today's setup is not that convenient), and I'd like to hear what you > >think of it. > > > >If you agree to go this path, I'll remove the warnings from checkpatch > >and do a proper submission. > > > >The patch is still not future proof (if Synaptics updates the board like > >they did for the *40 series, we will need to fix this all over again), > >so I might have a little bit more of work to do. Anyway, it works. > > I discovered that there is a firmware query to determine if the > touchpad has stick buttons which are wired to the touchpad and are > reported as extended buttons. Query $01 bit 17 indicates that Query > $10 exists. Then Query $10 bit 0 indicates indicates the extended > buttons should be mapped to the guest stick buttons. > > Additional information and some diagrams are in the pdf here: > https://www.dropbox.com/s/vv1j4zsytgrw7mm/synaptics-tp-stick-buttons.pdf?dl=0 Awesome, thanks Andrew. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 02/05/15 08:02, Quentin Lambert wrote:
> Sorry let me do that properly.
>
> On 05/02/2015 16:45, Quentin Lambert wrote:
>>
>> On 05/02/2015 00:26, Stephen Boyd wrote:
If you want me to I can enlarge the search to other directories.
>>> Yes please do. And if you could share the coccinelle patch that
>>> would be
>>> great. Thanks.
>>>
>> structclk.cocci is the coccinelle patch
>> structclk-arm.patch is the result I got when applying it to the
>> arch/arm directory
>>
>> Is there anything else I can do to help?
>>
>>
>
> These are the new instances I found by applying the patch to arch/arm
> directory:
>
> ./arch/arm/mach-imx/mach-imx6q.c
> @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
> * set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad
> * (external OSC), and we need to clear the bit.
> */
> clksel = ptp_clk == enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP :
> IMX6Q_GPR1_ENET_CLK_SEL_PAD;
> gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> if (!IS_ERR(gpr))
This one looks like a real problem and it could probably use a
clk_equal(struct clk *a, struct clk *b) function.
>
> ./arch/arm/mach-shmobile/clock-r8a73a4.c
> @@ -139,7 +139,6 @@ static int pll_set_parent(struct clk *cl
>
> /* Search the parent */
> for (i = 0; i < clk->parent_num; i++)
> if (clk->parent_table[i] == parent)
> break;
>
> if (i == clk->parent_num)
>
> ./arch/arm/mach-shmobile/clock-sh7372.c
> @@ -223,7 +223,6 @@ static int pllc2_set_parent(struct clk *
>
> /* Search the parent */
> for (i = 0; i < clk->parent_num; i++)
> if (clk->parent_table[i] == parent)
> break;
>
> if (i == clk->parent_num)
>
> ./arch/arm/mach-shmobile/clock-r8a7740.c
> @@ -195,7 +195,6 @@ static int usb24s_set_parent(struct clk
>
> /* Search the parent */
> for (i = 0; i < clk->parent_num; i++)
> if (clk->parent_table[i] == parent)
> break;
>
> if (i == clk->parent_num)
>
>
>
I don't think shmobile uses the CCF so this should be safe, but we
should probably fix them up to also use a clk_equal() function that just
does pointer comparisons.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/8] KEYS: exec request-key within the requesting task's init namespace
On Thu, 2015-02-05 at 15:14 +, David Howells wrote: > > > + /* If running within a container use the container namespace */ > > + if (current->nsproxy->net_ns != _net) > > Is that a viable check? Is it possible to have a container that shares > networking details? That's up for discussion. I thought about it and concluded that the check is probably not sufficient for any of the cases. I left it like that because I'm not sure exactly what the use cases are, hoping it promote discussion and here we are. I also think the current container environments don't share net namespace with the root init net namspace, necessarily, because thy are containers, ;) TBH I haven't looked at the user space container creation code but I expect it could be done that way if it was needed, so the answer is yes and no, ;) The questions then are do we need to check anything else, and what environment should the callback use in the different cases, and what other cases might break if we change it? For example, should the fs namespace also be checked for all of these cases, since we're executing a callback, or is whatever that's set to in the container always what's required for locating the executable. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] inotify: update documentation to reflect code changes
Hi Andrew Morton, I noticed there is no a git tree about notify, and i don't know which tree this patch should be included in. Can you include this patch in your git tree? Best regards! On 2015/2/5 22:49, Jan Kara wrote: > On Wed 04-02-15 11:01:56, Zhang Zhen wrote: >> The inotify interface has changed a lot. The user interface was >> too old, and the kernel interface was removed by Eric Paris in >> commit: 2dfc1ca inotify: remove inotify in kernel interface. >> >> Change v1 -> v2: >> - Deleted the user interface following Heinrich's and Honza's suggestion >> >> Signed-off-by: Zhang Zhen > You can add: > Acked-by: Jan Kara > > Honza > >> --- >> Documentation/filesystems/inotify.txt | 197 >> +- >> 1 file changed, 3 insertions(+), 194 deletions(-) >> >> diff --git a/Documentation/filesystems/inotify.txt >> b/Documentation/filesystems/inotify.txt >> index cfd0271..51f61db 100644 >> --- a/Documentation/filesystems/inotify.txt >> +++ b/Documentation/filesystems/inotify.txt >> @@ -4,201 +4,10 @@ >> >> >> Document started 15 Mar 2005 by Robert Love >> +Document updated 4 Jan 2015 by Zhang Zhen >> +--Deleted obsoleted interface, just refer to manpages for user >> interface. >> >> - >> -(i) User Interface >> - >> -Inotify is controlled by a set of three system calls and normal file I/O on >> a >> -returned file descriptor. >> - >> -First step in using inotify is to initialise an inotify instance: >> - >> -int fd = inotify_init (); >> - >> -Each instance is associated with a unique, ordered queue. >> - >> -Change events are managed by "watches". A watch is an (object,mask) pair >> where >> -the object is a file or directory and the mask is a bit mask of one or more >> -inotify events that the application wishes to receive. See >> >> -for valid events. A watch is referenced by a watch descriptor, or wd. >> - >> -Watches are added via a path to the file. >> - >> -Watches on a directory will return events on any files inside of the >> directory. >> - >> -Adding a watch is simple: >> - >> -int wd = inotify_add_watch (fd, path, mask); >> - >> -Where "fd" is the return value from inotify_init(), path is the path to the >> -object to watch, and mask is the watch mask (see ). >> - >> -You can update an existing watch in the same manner, by passing in a new >> mask. >> - >> -An existing watch is removed via >> - >> -int ret = inotify_rm_watch (fd, wd); >> - >> -Events are provided in the form of an inotify_event structure that is >> read(2) >> -from a given inotify instance. The filename is of dynamic length and >> follows >> -the struct. It is of size len. The filename is padded with null bytes to >> -ensure proper alignment. This padding is reflected in len. >> - >> -You can slurp multiple events by passing a large buffer, for example >> - >> -size_t len = read (fd, buf, BUF_LEN); >> - >> -Where "buf" is a pointer to an array of "inotify_event" structures at least >> -BUF_LEN bytes in size. The above example will return as many events as are >> -available and fit in BUF_LEN. >> - >> -Each inotify instance fd is also select()- and poll()-able. >> - >> -You can find the size of the current event queue via the standard FIONREAD >> -ioctl on the fd returned by inotify_init(). >> - >> -All watches are destroyed and cleaned up on close. >> - >> - >> -(ii) >> - >> -Prototypes: >> - >> -int inotify_init (void); >> -int inotify_add_watch (int fd, const char *path, __u32 mask); >> -int inotify_rm_watch (int fd, __u32 mask); >> - >> - >> -(iii) Kernel Interface >> - >> -Inotify's kernel API consists a set of functions for managing watches and an >> -event callback. >> - >> -To use the kernel API, you must first initialize an inotify instance with a >> set >> -of inotify_operations. You are given an opaque inotify_handle, which you >> use >> -for any further calls to inotify. >> - >> -struct inotify_handle *ih = inotify_init(my_event_handler); >> - >> -You must provide a function for processing events and a function for >> destroying >> -the inotify watch. >> - >> -void handle_event(struct inotify_watch *watch, u32 wd, u32 mask, >> - u32 cookie, const char *name, struct inode *inode) >> - >> -watch - the pointer to the inotify_watch that triggered this call >> -wd - the watch descriptor >> -mask - describes the event that occurred >> -cookie - an identifier for synchronizing events >> -name - the dentry name for affected files in a directory-based event >> -inode - the affected inode in a directory-based event >> - >> -void destroy_watch(struct inotify_watch *watch) >> - >> -You may add watches by providing a pre-allocated and initialized >> inotify_watch >> -structure and specifying the inode to watch along with an inotify event >> mask. >> -You must pin the inode during the call. You will likely wish to embed
[PATCH v2] clkdev: Always allocate a struct clk and call __clk_get() w/ CCF
of_clk_get_by_clkspec() returns a struct clk pointer but it
doesn't create a new handle for the consumers when we're using
the common clock framework. Instead it just returns whatever the
clk provider hands out. When the consumers go to call clk_put()
we get an Oops.
Unable to handle kernel paging request at virtual address 00200200
pgd = c0004000
[00200200] *pgd=
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc1-00104-ga251361a-dirty #992
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
task: ee00b000 ti: ee088000 task.ti: ee088000
PC is at __clk_put+0x24/0xd0
LR is at clk_prepare_lock+0xc/0xec
pc : []lr : []psr: 2153
sp : ee089de8 ip : fp :
r10: ee02f480 r9 : 0001 r8 :
r7 : ee031cc0 r6 : ee089e08 r5 : r4 : ee02f480
r3 : 00100100 r2 : 00200200 r1 : 091e r0 : 0001
Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 4000404a DAC: 0015
Process swapper/0 (pid: 1, stack limit = 0xee088238)
Stack: (0xee089de8 to 0xee08a000)
9de0: ee7c8f14 c03f0ec8 ee089e08 c0718dc8 0001
9e00: c04ee0f0 ee7e0844 0001 0181 c04edb58 ee2bd320
9e20: c011dc5c ee16a1e0 c0718dc8 ee16a1e0 ee2bd1e0
9e40: c0641740 ee16a1e0 ee2bd320 c0718dc8 ee1d3e10 ee1d3e10
9e60: c0769a88 c0718dc8 c02c3124 c02c310c ee1d3e10
9e80: c07b4eec c0769a88 c02c1d0c ee1d3e10 c0769a88 ee1d3e44
9ea0: c07091dc c02c1eb8 c0769a88 c02c1e2c c02c0544 ee005478 ee1676c0
9ec0: c0769a88 ee3a4e80 c0760ce8 c02c150c c0669b90 c0769a88 c0746cd8 c0769a88
9ee0: c0746cd8 ee2bc4c0 c0778c00 c02c24e0 c0746cd8 c0746cd8 c07091f0
9f00: c0008944 c04f405c 0025 ee00b000 6153 c074ab00
9f20: c074ab90 6153 ef7fca5d c050860c 00b6 c0036b88
9f40: c065ecc4 c06bc728 0006 0006 c074ab30 ef7fca40 c0739bdc 0006
9f60: c0718dbc c0778c00 00b6 c0718dc8 c06ed598 c06edd64 0006 0006
9f80: c06ed598 c003b438 c04e64f4
9fa0: c04e64fc c000e838
9fc0:
9fe0: 0013 c0c0c0c0 c0c0c0c0
[] (__clk_put) from [] (of_clk_set_defaults+0xe0/0x2c0)
[] (of_clk_set_defaults) from []
(platform_drv_probe+0x18/0xa4)
[] (platform_drv_probe) from []
(driver_probe_device+0x10c/0x22c)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[] (bus_for_each_dev) from [] (bus_add_driver+0xd4/0x1d0)
[] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[] (driver_register) from [] (fimc_md_init+0x14/0x30)
[] (fimc_md_init) from [] (do_one_initcall+0x80/0x1d0)
[] (do_one_initcall) from []
(kernel_init_freeable+0x108/0x1d4)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: ebfff4ae e5943014 e5942018 e353 (e5823000)
Let's create a per-user handle here so that clk_put() can
properly unlink it and free the handle. Now that we allocate a
clk structure here we need to free it if __clk_get() fails so
bury the __clk_get() call in __of_clk_get_from_provider(). We
need to handle the same problem in clk_get_sys() so export
__clk_free_clk() to clkdev.c and do the same thing, except let's
do some more inline functions to make this code #ifdef free.
This fixes the above crash, properly calls __clk_get() when
of_clk_get_from_provider() is called, and cleans up the clk
structure on the error path of clk_get_sys().
Fixes: 035a61c314eb "clk: Make clk API return per-user struct clk instances"
Reported-by: Sylwester Nawrocki
Reported-by: Alban Browaeys
Cc: Tomeu Vizoso
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c| 18 +
drivers/clk/clk.h| 19 +-
drivers/clk/clkdev.c | 56 ++--
3 files changed, 56 insertions(+), 37 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 113456030d66..5469d7714f5d 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2382,7 +2382,7 @@ struct clk *__clk_create_clk(struct clk_hw *hw, const
char *dev_id,
return clk;
}
-static void __clk_free_clk(struct clk *clk)
+void __clk_free_clk(struct clk *clk)
{
clk_prepare_lock();
hlist_del(>child_node);
@@ -2894,7 +2894,8 @@ void of_clk_del_provider(struct device_node *np)
}
EXPORT_SYMBOL_GPL(of_clk_del_provider);
-struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec,
+ const char *dev_id, const char *con_id)
{
struct
Re: [RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series
On 02/05/2015 12:38 PM, Benjamin Tissoires wrote:
Lenovos 2015 series has the physical tracktick buttons wired
through the touchpad. The kernel should re-route them through
the pass-through interface.
Signed-off-by: Benjamin Tissoires
---
Hi Dmitry,
Well, in one of your replies regarding the Synaptics Lenovo 2015
series, you mentioned that you wouldn't mind having the trackstick
buttons re-routed through the trackstick (pass-through interface).
I came out with this patch (checkpatch complains a lot about it but
today's setup is not that convenient), and I'd like to hear what you
think of it.
If you agree to go this path, I'll remove the warnings from checkpatch
and do a proper submission.
The patch is still not future proof (if Synaptics updates the board like
they did for the *40 series, we will need to fix this all over again),
so I might have a little bit more of work to do. Anyway, it works.
I discovered that there is a firmware query to determine if the touchpad
has stick buttons which are wired to the touchpad and are reported as
extended buttons. Query $01 bit 17 indicates that Query $10 exists. Then
Query $10 bit 0 indicates indicates the extended buttons should be
mapped to the guest stick buttons.
Additional information and some diagrams are in the pdf here:
https://www.dropbox.com/s/vv1j4zsytgrw7mm/synaptics-tp-stick-buttons.pdf?dl=0
Cheers,
Benjamin
drivers/input/mouse/synaptics.c | 55 -
drivers/input/mouse/synaptics.h | 2 ++
2 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index fc0099c..e32cac1 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -190,6 +190,11 @@ static const char * const topbuttonpad_pnp_ids[] = {
NULL
};
+static const char * const trackstick_buttons_pnp_ids[] = {
+ "LEN0048",
+ NULL
+};
+
/*
*Synaptics communications functions
/
@@ -512,18 +517,20 @@ static int synaptics_is_pt_packet(unsigned char *buf)
return (buf[0] & 0xFC) == 0x84 && (buf[3] & 0xCC) == 0xC4;
}
-static void synaptics_pass_pt_packet(struct serio *ptport, unsigned char *packet)
+static void synaptics_pass_pt_packet(struct psmouse *psmouse, struct serio
*ptport,
+ unsigned char *packet)
{
+ struct synaptics_data *priv = psmouse->private;
struct psmouse *child = serio_get_drvdata(ptport);
if (child && child->state == PSMOUSE_ACTIVATED) {
- serio_interrupt(ptport, packet[1], 0);
+ serio_interrupt(ptport, packet[1] | priv->pt_buttons, 0);
serio_interrupt(ptport, packet[4], 0);
serio_interrupt(ptport, packet[5], 0);
if (child->pktsize == 4)
serio_interrupt(ptport, packet[2], 0);
} else
- serio_interrupt(ptport, packet[1], 0);
+ serio_interrupt(ptport, packet[1] | priv->pt_buttons, 0);
}
static void synaptics_pt_activate(struct psmouse *psmouse)
@@ -782,11 +789,33 @@ static void synaptics_report_buttons(struct psmouse
*psmouse,
input_report_key(dev, BTN_BACK, hw->down);
}
- for (i = 0; i < ext_bits; i++) {
- input_report_key(dev, BTN_0 + 2 * i,
-hw->ext_buttons & (1 << i));
- input_report_key(dev, BTN_1 + 2 * i,
-hw->ext_buttons & (1 << (i + ext_bits)));
+ if (!priv->override_pt_buttons) {
+ for (i = 0; i < ext_bits; i++) {
+ input_report_key(dev, BTN_0 + 2 * i,
+hw->ext_buttons & (1 << i));
+ input_report_key(dev, BTN_1 + 2 * i,
+hw->ext_buttons & (1 << (i +
ext_bits)));
+ }
+ } else {
+ /*
+* This generation of touchpads has the trackstick buttons
+* physically wired to the touchpad. Re-route them through
+* the pass-through interface.
+*/
+ if (priv->pt_port &&
+ SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
+ ((psmouse->packet[0] ^ psmouse->packet[3]) & 0x02)) {
+ char buf[6] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ priv->pt_buttons = 0x00;
+ /* ext_bits is guaranteed to be <= 4 */
+ for (i = 0; i < ext_bits; i++) {
+ if (hw->ext_buttons & (1 << i))
+ priv->pt_buttons |= 1 << (2 * i);
+ if (hw->ext_buttons & (1 << (i + ext_bits)))
+
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 02/05/15 16:42, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
>> Actually we can bury the __clk_create_clk() inside
>> __of_clk_get_from_provider(). We should also move __clk_get() into there
>> because right now we have a hole where whoever calls
>> of_clk_get_from_provider() never calls __clk_get() on the clk, leading
>> to possible badness. v2 coming soon.
> There's some other issues here too...
>
> sound/soc/kirkwood/kirkwood-i2s.c:
>
> priv->clk = devm_clk_get(>dev, np ? "internal" : NULL);
> ...
> priv->extclk = devm_clk_get(>dev, "extclk");
> if (IS_ERR(priv->extclk)) {
> ...
> } else {
> if (priv->extclk == priv->clk) {
> devm_clk_put(>dev, priv->extclk);
> priv->extclk = ERR_PTR(-EINVAL);
> } else {
> dev_info(>dev, "found external clock\n");
> clk_prepare_enable(priv->extclk);
> soc_dai = kirkwood_i2s_dai_extclk;
> }
>
> It should be fine provided your "trick" is only done for DT clocks,
> but not for legacy - with legacy, a NULL in the clkdev tables will
> match both these requests, hence the need to compare the clk_get()
> return value to tell whether we get the same clock.
>
Are we still talking about of_clk_get_from_provider()? Or are we talking
about comparing struct clk pointers? From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the driver wants to know if extclk and clk are the same so it can do
something differently in kirkwood_set_rate(). Do we need some sort of
clk_equal(struct clk *a, struct clk *b) function for drivers like this?
Also, even on DT this could fail if the DT author made internal and
extclk map to the same clock provider and cell.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ixgbe: fix sparse warnings
On Thu, 2015-02-05 at 14:27 +, Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > this patch fixes following sparse warnings: > > ixgbe_x550.c:83:5: warning: symbol 'ixgbe_init_eeprom_params_X550' was > not declared. Should it be static? > ixgbe_x550.c:113:5: warning: symbol 'ixgbe_read_iosf_sb_reg_x550' was > not declared. Should it be static? > ixgbe_x550.c:161:5: warning: symbol 'ixgbe_read_ee_hostif_data_X550' > was not declared. Should it be static? > ixgbe_x550.c:196:5: warning: symbol 'ixgbe_read_ee_hostif_buffer_X550' > was not declared. Should it be static? > ixgbe_x550.c:334:5: warning: symbol 'ixgbe_calc_checksum_X550' was not > declared. Should it be static? > ixgbe_x550.c:410:5: warning: symbol 'ixgbe_calc_eeprom_checksum_X550' > was not declared. Should it be static? > ixgbe_x550.c:422:5: warning: symbol 'ixgbe_read_ee_hostif_X550' was > not declared. Should it be static? > ixgbe_x550.c:443:5: warning: symbol > 'ixgbe_validate_eeprom_checksum_X550' was not declared. Should it be > static? > ixgbe_x550.c:492:5: warning: symbol 'ixgbe_write_ee_hostif_data_X550' > was not declared. Should it be static? > ixgbe_x550.c:520:5: warning: symbol 'ixgbe_write_ee_hostif_X550' was > not declared. Should it be static? > ixgbe_x550.c:540:5: warning: symbol 'ixgbe_update_flash_X550' was not > declared. Should it be static? > ixgbe_x550.c:563:5: warning: symbol > 'ixgbe_update_eeprom_checksum_X550' was not declared. Should it be > static? > ixgbe_x550.c:603:5: warning: symbol > 'ixgbe_write_ee_hostif_buffer_X550' was not declared. Should it be > static? > ixgbe_x550.c:633:6: warning: symbol 'ixgbe_init_mac_link_ops_X550em' > was not declared. Should it be static? > ixgbe_x550.c:650:5: warning: symbol 'ixgbe_setup_sfp_modules_X550em' > was not declared. Should it be static? > ixgbe_x550.c:706:5: warning: symbol > 'ixgbe_get_link_capabilities_X550em' was not declared. Should it be > static? > ixgbe_x550.c:743:5: warning: symbol 'ixgbe_write_iosf_sb_reg_x550' was > not declared. Should it be static? > ixgbe_x550.c:907:5: warning: symbol 'ixgbe_setup_kx4_x550em' was not > declared. Should it be static? > ixgbe_x550.c:945:5: warning: symbol 'ixgbe_setup_kr_x550em' was not > declared. Should it be static? > ixgbe_x550.c:990:5: warning: symbol 'ixgbe_setup_internal_phy_x550em' > was not declared. Should it be static? > ixgbe_x550.c:1052:5: warning: symbol 'ixgbe_init_phy_ops_X550em' was > not declared. Should it be static? > ixgbe_x550.c:1105:23: warning: symbol 'ixgbe_get_media_type_X550em' > was not declared. Should it be static? > ixgbe_x550.c:1132:5: warning: symbol 'ixgbe_init_ext_t_x550em' was not > declared. Should it be static? > ixgbe_x550.c:1205:5: warning: symbol 'ixgbe_reset_hw_X550em' was not > declared. Should it be static? > > Signed-off-by: Lad, Prabhakar > --- > Found this issue on linux-next (gcc version 4.9.2, > sparse version 0.4.5-rc1)and applies on top linux-next. > > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 64 > ++- > 1 file changed, 34 insertions(+), 30 deletions(-) Don Skidmore already has a patch to resolve these warnings in my queue. So I will be dropping this patch. signature.asc Description: This is a digitally signed message part
Re: [PATCH] sched, autogroup: Fix failure when writing to cpu.rt_runtime_us
On 2015/2/5 22:25, Peter Zijlstra wrote:
> On Thu, Feb 05, 2015 at 04:33:24PM +0800, Zefan Li wrote:
>> This is how to reproduce the bug:
>>
>> int main() {
>> struct sched_param param = {.sched_priority=1};
>>
>> if (fork() > 0)
>> exit(0);
>>
>> setsid();
>>
>> if (sched_setscheduler(0, SCHED_RR, ) < 0){
>> perror("failed to sched_setscheduler()");
>> return -1;
>> }
>>
btw, if you move setscheduler() abvoe fork(), changing rt_runtime
will succeed.
>> while(1)
>> ;
>> }
>>
>> # ./test
>> # mount -t cgroup -o cpu xxx /cgroup
>> # cat /cgroup/cpu.rt_runtime_us
>> 95
>> # echo 94 > /cgroup/cpu.rt_runtime_us
>> Device or Resource busy
>
> That's -EBUSY, but you're changing an -EPERM condition. Neither your
> patch nor explanation of the matter make sense.
>
I'm not changing the -EPERM condition. I'm adding an else condition which
resets p->sched_task_group.
After running the test program, we have:
root
|
autogroup <-- the RT test program is now here
root.rt_runtime = 95
autogroup.rt_runtime = 0
Now if you try to change the rt_runtime of the root cgroup, it returns
-EBUSY.
That comes from:
static int tg_rt_schedulable(struct task_group *tg, void *data)
(
...
if (rt_bandwidth_enabled() && !runtime && tg_has_rt_tasks(tg))
return -EBUSY;
...
}
static inline int tg_has_rt_tasks(struct task_group *tg)
{
struct task_struct *g, *p;
for_each_process_thread(g, p) {
if (rt_task(p) && task_group(p) == tg)
return 1;
}
return 0;
}
here tg == autogroup, p == the test program, and task_group(p)
returns autogroup, which is wrong.
See this commit:
commit f44937718ce3b8360f72f6c68c9481712517a867
Author: Mike Galbraith
Date: Thu Jan 13 04:54:50 2011 +0100
sched, autogroup: Fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure
...
+ /*
+* Autogroup RT tasks are redirected to the root task group
...
+* the policy change to proceed. Thereafter, task_group()
+* returns _task_group, ...
+*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
