Re: [PATCH 1/2] regulator: anatop-regulator: Remove unneeded check
On Fri, Dec 20, 2013 at 11:42:09AM -0200, Fabio Estevam wrote: > From: Fabio Estevam > > At the 'anatop_probe_end' error path, the variable 'ret' is known to be > non-zero, so there is no need to check it. > > Signed-off-by: Fabio Estevam > --- > drivers/regulator/anatop-regulator.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/regulator/anatop-regulator.c > b/drivers/regulator/anatop-regulator.c > index c734d09..0a3597b 100644 > --- a/drivers/regulator/anatop-regulator.c > +++ b/drivers/regulator/anatop-regulator.c > @@ -211,8 +211,7 @@ static int anatop_regulator_probe(struct platform_device > *pdev) > platform_set_drvdata(pdev, rdev); > > anatop_probe_end: > - if (ret) > - kfree(sreg->name); > + kfree(sreg->name); NAK With the change, a successful probe will end up with calling this kfree() as well. Shawn > > return ret; > } > -- > 1.8.1.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strictly confidential,
-- Dear friend, I know that this message will come to you as a surprise. I am Nyejiowanka Gogo from Burkina Faso the Accounting and Auditing Manager bank of Africa (B.O.A), Ouagadougou I hoped that you will not expose or betray this trust and confident that I am about to repose on you for the mutual benefit of our families. I need your urgent assistance in transferring the sum of (usd$25m) million to your account within 10 to 14 banking days. This money has been dormant for years in our bank without claim. I want the bank to release the money to you as the nearest person to our deceased customer (the owner of the account) died along with his supposed next of kin in an air crash since July, 2000. I don't want the money to go into our bank treasurer account as an abandoned fund. So this is the reason why I contacted you so that the bank can release the money to you as the next of kin to the deceased customer. Please I would like you to keep this proposal as a top secret and delete it if you are not upon receipt of your reply, I will give you full details on how the business will be executed and also note that you will have 40% of the above mentioned sum if you agree to handle this business with me? And 10% will be set aside for any expenses that warrant on the process before the fund get into your bank account such as telephone calls bills (etc). Finally send your photo or your international passports for more identification. (1)Your Full Name (2)You Age (3) Sex (4)You Country (5)You Telephone Number (6)Your Occupation Best Regards, Mr. Nyejiowanka Gogo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user
On Fri, 2013-12-20 at 14:01 +, Mel Gorman wrote: > On Thu, Dec 19, 2013 at 05:02:02PM -0800, Andrew Morton wrote: > > On Wed, 18 Dec 2013 15:53:59 +0900 Joonsoo Kim > > wrote: > > > > > If parallel fault occur, we can fail to allocate a hugepage, > > > because many threads dequeue a hugepage to handle a fault of same address. > > > This makes reserved pool shortage just for a little while and this cause > > > faulting thread who can get hugepages to get a SIGBUS signal. > > > > > > To solve this problem, we already have a nice solution, that is, > > > a hugetlb_instantiation_mutex. This blocks other threads to dive into > > > a fault handler. This solve the problem clearly, but it introduce > > > performance degradation, because it serialize all fault handling. > > > > > > Now, I try to remove a hugetlb_instantiation_mutex to get rid of > > > performance degradation. > > > > So the whole point of the patch is to improve performance, but the > > changelog doesn't include any performance measurements! > > > > I don't really deal with hugetlbfs any more and I have not examined this > series but I remember why I never really cared about this mutex. It wrecks > fault scalability but AFAIK fault scalability almost never mattered for > workloads using hugetlbfs. The most common user of hugetlbfs by far is > sysv shared memory. The memory is faulted early in the lifetime of the > workload and after that it does not matter. At worst, it hurts application > startup time but that is still poor motivation for putting a lot of work > into removing the mutex. Yep, important hugepage workloads initially pound heavily on this lock, then it naturally decreases. > Microbenchmarks will be able to trigger problems in this area but it'd > be important to check if any workload that matters is actually hitting > that problem. I was thinking of writing one to actually get some numbers for this patchset -- I don't know of any benchmark that might stress this lock. However I first measured the amount of cycles it costs to start an Oracle DB and things went south with these changes. A simple 'startup immediate' calls hugetlb_fault() ~5000 times. For a vanilla kernel, this costs ~7.5 billion cycles and with this patchset it goes up to ~27.1 billion. While there is naturally a fair amount of variation, these changes do seem to do more harm than good, at least in real world scenarios. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hi
Diploma? http://tiny.cc/gdjpc13gaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] ARM: msm: Add support for APQ8074 Dragonboard
On 12/20, Arnd Bergmann wrote:
> On Friday 20 December 2013, David Brown wrote:
> > diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
> > index 16e6183..1f11d93 100644
> > --- a/arch/arm/mach-msm/board-dt.c
> > +++ b/arch/arm/mach-msm/board-dt.c
> > @@ -26,7 +26,16 @@ static const char * const msm_dt_match[] __initconst = {
> > NULL
> > };
> >
> > +static const char * const apq8074_dt_match[] __initconst = {
> > + "qcom,apq8074-dragonboard",
> > + NULL
> > +};
> > +
> > DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
> > .smp = smp_ops(msm_smp_ops),
> > .dt_compat = msm_dt_match,
> > MACHINE_END
> > +
> > +DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
> > + .dt_compat = apq8074_dt_match,
> > +MACHINE_END
> > --
>
> Why can't you reuse the MSM_DT definition and just add the dragonboard
> to the list of compatible machines? The presence of the smp_ops pointer
> should not matter if you don't support SMP.
>
If the smp_ops are present we'll try to boot the secondary CPUs
with the Scorpion boot sequence instead of the Krait boot
sequence. This will quickly hang the system. We can properly
handle this with my SMP patches[1]. In fact, we can delete this
entire file if those patches are accepted. Please take a look.
I'll Cc you on them when I resend.
[1] https://lkml.org/lkml/2013/11/1/622
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Overføring av midler
Kjære venn, God morgen, Mitt navn er Michael Erwin, jeg jobber med en finans-hus her i Nederland. Under min selskapets siste møte og undersøkelse av bankkontoene innenfor vårt selskap, min avdeling fant en sovende konto med en enorm sum av US $ 55,500,000.00 ($ 55.5 millioner) som ble avsatt av en sen Mr. Williams fra England før hans død. Fra vår undersøkelse hadde han ingen pårørende for å kreve disse midlene. Ifølge den nederlandske bankregulering bare en utlending kan stå som pårørende, med tanke på at innskyter var en ikke-nederlandsk. Jeg trenger din tillatelse til å stå som en partner av vår avdøde kunde, slik at midlene kan frigjøres og overføres til din bankkonto umiddelbart. På slutten av transaksjonen 40% vil være for deg og 60% vil være for meg og mine kolleger. Jeg jobber fortsatt med den finansielle huset, og det er grunnen til at jeg trenger en annen part til å jobbe med. Jeg har i min besittelse alle de nødvendige dokumentene for å ha denne transaksjonen gjennomføres med hell. Ytterligere informasjon vil bli gitt ved mottak av din raskt svar. Vær oppmerksom på at denne transaksjonen er risikofritt , er alt jeg trenger fra deg din ærlighet og tillit . Vi ber deg svare tilbake til meg gjennom min direkte epost ( micheal_er...@aim.com ) Med vennlig hilsen. Micheal Erwin . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/12] clk: Add regmap core helpers for enable/disable/is_enabled
On 12/18, Mike Turquette wrote:
> Quoting Stephen Boyd (2013-10-16 00:40:06)
> > struct clk_hw {
> > struct clk *clk;
> > const struct clk_init_data *init;
> > struct regmap *regmap;
> > + unsigned int enable_reg;
> > + unsigned int enable_mask;
> > + bool enable_is_inverted;
>
> Thanks for submitting this patch.
>
> Adding all of this stuff to struct clk_hw makes me a sad panda. You are
> essentially sharing a common set of ops for clocks that use regmap as
> their io operation back-end, and that is a good thing.
>
> However, why not just do this as drivers/clk/clk-regmap.c, or
> drivers/clk/clk-gate-regmap.c?
These new members aren't exclusively for use by the regmap code.
For example, we could extend the gate clock implementation to
store the enable bit in the 'enable_mask' member. They also
aren't used exclusively by simple gates. If you look at this
patch series you'll see that I call the helpers from hardware
specific ops when I want to do the gate operation in addition to
something else like polling a status bit.
What is the concern though? I can only guess that perhaps not
every clock type will have a bit to toggle and so putting the
information here would unnecessarily penalize those clocks? How
many clocks in a particular system don't have an on/off
capability? On MSM hardware I can only count 5 or so out of 200
that don't have on/off capabilities so it didn't seem worth the
effort to have a struct inside a struct inside a struct just to
save a 100 bytes of data.
If I understand you, I could make clk-regmap.c and struct
clk_regmap like so:
struct clk_regmap {
struct regmap *regmap;
unsigned int enable_reg;
unsigned int enable_mask;
bool enable_is_inverted;
struct clk_hw hw;
};
int clk_is_enabled_regmap(struct clk_hw *hw)
{
...
That certainly avoids adding members to struct clk_hw, but it
also means that if we want to use this structure and augment it
with something like a status bit poll we need to make a third
structure to wrap the clk_regmap struct. That makes me a sad
panda.
The reason is because we'll need to add a registration function
like clk_regmap_register(). I would like to just have an array of
clk_hw pointers that I iterate through and call clk_register()
on, without having to think/worry that this clock is a basic
clock that doesn't use a regmap so I should call clk_register()
and this other clock is wrapping a clk_regmap struct so I need to
call clk_regmap_register(). I guess I could have more arrays or
pair the clk_hw pointers with some registration function pointer,
but that doesn't make me feel much better.
> Putting the clk_ops callback functions in
> drivers/clk/clk.c is a little weird and putting those struct members
> into struct clk_hw is definitely strange.
In the regulator framework we have helpers.c. I could make a
similar file for these very similar helpers.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup
On Fri, 2013-12-20 at 11:54 -0800, Linus Torvalds wrote: > On Fri, Dec 20, 2013 at 11:30 AM, Davidlohr Bueso wrote: > > > > So we'd need the barrier right after the ticket increment (ie: the xadd > > TICKET_LOCK_INC in x86), and cannot rely on the barrier after the lock > > is taken as we could miss waiters that are just spinning trying to take > > it. Is this implicitly guaranteed across all archs? > > Not necessarily. But I don't see why threads spinning on it would be > special? If you spin on things, you've already updated the head > counter, so even spinners *are* visible, even if they haven't actually > gotten the lock yet. Fair enough, just making sure we're covering all cases. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] mfd: twl6040: Staticize local variable
'twl6040_patch' is local to this file.
Signed-off-by: Sachin Kamat
Cc: Peter Ujfalusi
---
drivers/mfd/twl6040.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 51b6df1a7949..75316fb33448 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -86,7 +86,7 @@ static struct reg_default twl6040_defaults[] = {
{ 0x2E, 0x00 }, /* REG_STATUS (ro) */
};
-struct reg_default twl6040_patch[] = {
+static struct reg_default twl6040_patch[] = {
/* Select I2C bus access to dual access registers */
{ TWL6040_REG_ACCCTL, 0x09 },
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mfd: rtl8411: Staticize local symbol
'rtl8411_init_common_params' is local to this file.
Signed-off-by: Sachin Kamat
---
drivers/mfd/rtl8411.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index ada38ad54e87..fdd34c883d86 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -470,7 +470,7 @@ static const u32 rtl8411b_qfn48_ms_pull_ctl_disable_tbl[] =
{
0,
};
-void rtl8411_init_common_params(struct rtsx_pcr *pcr)
+static void rtl8411_init_common_params(struct rtsx_pcr *pcr)
{
pcr->extra_caps = EXTRA_CAPS_SD_SDR50 | EXTRA_CAPS_SD_SDR104;
pcr->num_slots = 2;
--
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] perf config: ignore generated files in feature-checks
>From ce62a386df25ec50e13487c7b56e09c71c2abf4c Mon Sep 17 00:00:00 2001 From: Chunwei Chen Date: Sat, 21 Dec 2013 13:15:07 +0800 Subject: [PATCH] perf config: ignore generated files in feature-checks 1. Rename the test-* binary files to test-*.bin for easier pattern matching as suggested by Ingo. 2. Ignore *.bin and *.d files. Signed-off-by: Chunwei Chen --- tools/perf/config/Makefile | 6 +- tools/perf/config/feature-checks/.gitignore | 2 + tools/perf/config/feature-checks/Makefile | 110 ++-- 3 files changed, 60 insertions(+), 58 deletions(-) create mode 100644 tools/perf/config/feature-checks/.gitignore diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 5a1f4df..14faeeb 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -126,7 +126,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C config/feature-checks test-$1.bin >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) @@ -173,7 +173,7 @@ CORE_FEATURE_TESTS =\ # to skip the print-out of the long features list if the file # existed before and after it was built: # -ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),) +ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all.bin),) test-all-failed := 1 else test-all-failed := 0 @@ -203,7 +203,7 @@ ifeq ($(feature-all), 1) # $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat))) else - $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1) + $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(addsuffix .bin,$(CORE_FEATURE_TESTS)) >/dev/null 2>&1) $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat))) endif diff --git a/tools/perf/config/feature-checks/.gitignore b/tools/perf/config/feature-checks/.gitignore new file mode 100644 index 000..80f3da0 --- /dev/null +++ b/tools/perf/config/feature-checks/.gitignore @@ -0,0 +1,2 @@ +*.d +*.bin diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index bc86462..7cf6fcd 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -1,90 +1,90 @@ FILES= \ - test-all\ - test-backtrace \ - test-bionic \ - test-dwarf \ - test-fortify-source \ - test-glibc \ - test-gtk2 \ - test-gtk2-infobar \ - test-hello \ - test-libaudit \ - test-libbfd \ - test-liberty\ - test-liberty-z \ - test-cplus-demangle \ - test-libelf \ - test-libelf-getphdrnum \ - test-libelf-mmap\ - test-libnuma\ - test-libperl\ - test-libpython \ - test-libpython-version \ - test-libslang \ - test-libunwind \ - test-libunwind-debug-frame \ - test-on-exit\ - test-stackprotector-all \ - test-timerfd + test-all.bin\ + test-backtrace.bin \ + test-bionic.bin \ + test-dwarf.bin \ + test-fortify-source.bin \ + test-glibc.bin \ + test-gtk2.bin \ + test-gtk2-infobar.bin \ + test-hello.bin \ + test-libaudit.bin \ + test-libbfd.bin \ + test-liberty.bin\ + test-liberty-z.bin \ + test-cplus-demangle.bin \ + test-libelf.bin \ + test-libelf-getphdrnum.bin \ + test-libelf-mmap.bin\ + test-libnuma.bin\ + test-libperl.bin\ + test-libpython.bin \ + test-libpython-version.bin \ + test-libslang.bin \ + test-libunwind.bin \ +
MAINTAINERS: Describe differences between F: and N: patterns
There is a difference in how scripts/get_maintainer.pl treats F: and N: file pattern matches. Describe those differences in the MAINTAINERS file. Signed-off-by: Joe Perches --- On Fri, 2013-12-20 at 21:21 +0100, Uwe Kleine-König wrote: > Acked-by: Greg Kroah-Hartman > Acked-by: Mark Brown > Signed-off-by: Uwe Kleine-König > On Fri, Dec 20, 2013 at 11:55:30PM +0400, Alexander Shiyan wrote: > > [...] > > > +F: arch/arm/boot/dts/efm32* > > > +F: arch/arm/configs/efm32_defconfig > > > +F: arch/arm/include/debug/efm32.S > > > +F: arch/arm/mach-efm32/ > > > +F: drivers/clk/clk-efm32gg.c > > > +F: drivers/clocksource/time-efm32.c > > > +F: drivers/spi/spi-efm32.c > > > +F: drivers/tty/serial/efm32-uart.c > > > +F: include/dt-bindings/clock/efm32-cmu.h > > > +F: include/linux/platform_data/efm32-* > > > > Maybe "N" keyword with "efm32" is better here? > ah, didn't know about that. Nice. > > So the changes since v1 are: > - use N: efm32 > - add acks from Greg and Mark >I assume it's ok to keep them for v2 assuming they mean them being OK with >me maintaining the efm32 stuff and not the way to express that in >MAINTAINERS. MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1344816..ebdb523 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -93,6 +93,11 @@ Descriptions of section entries: N: Files and directories with regex patterns. N: [^a-z]tegra all files whose path contains the word tegra One pattern per line. Multiple N: lines acceptable. + scripts/get_maintainer.pl has different behavior for files that + match F: pattern and matches of N: patterns. By default, + get_maintainer will not look at git log history when an F: pattern + match occurs. When an N: match occurs, git log history is used + to also notify the people that have git commit signatures. X: Files and directories that are NOT maintained, same rules as F: Files exclusions are tested before file matches. Can be useful for excluding a specific subdirectory, for instance: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 07/14] rtc-efi: add GMTOFF support to rtc_efi
於 五，2013-12-20 於 15:11 +，Matthew Garrett 提到： > On Thu, 2013-12-19 at 15:51 +0800, Lee, Chun-Yi wrote: > > This patch adds 2 new iotrl: RTC_RD_GMTOFF and RTC_SET_GMTOFF to > > rtc_efi support get/set gmt offset that mapping to the GUN's tm_gmtoff > > extension (Seconds east of UTC). > > Shouldn't this information also be exported via the rtc-sysfs interface? > Thanks for your suggestion, I will also export it to rtc-sysfs. Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] module: fix coding style
Seunghun Lee writes:
> Fix coding style of module.h
Thanks, applied.
Cheers,
Rusty.
>
> Signed-off-by: Seunghun Lee
> ---
> include/linux/module.h | 62
>
> 1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 46e548f..eaf60ff 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -29,8 +29,7 @@
>
> #define MODULE_NAME_LEN MAX_PARAM_PREFIX_LEN
>
> -struct modversion_info
> -{
> +struct modversion_info {
> unsigned long crc;
> char name[MODULE_NAME_LEN];
> };
> @@ -84,12 +83,12 @@ void sort_main_extable(void);
> void trim_init_extable(struct module *m);
>
> #ifdef MODULE
> -#define MODULE_GENERIC_TABLE(gtype,name) \
> +#define MODULE_GENERIC_TABLE(gtype, name)\
> extern const struct gtype##_id __mod_##gtype##_table \
>__attribute__ ((unused, alias(__stringify(name
>
> #else /* !MODULE */
> -#define MODULE_GENERIC_TABLE(gtype,name)
> +#define MODULE_GENERIC_TABLE(gtype, name)
> #endif
>
> /* Generic info of form tag = "info" */
> @@ -126,7 +125,7 @@ extern const struct gtype##_id __mod_##gtype##_table
> \
> * is a GPL combined work.
> *
> * This exists for several reasons
> - * 1.So modinfo can show license info for users wanting to vet their
> setup
> + * 1.So modinfo can show license info for users wanting to vet their
> setup
> * is free
> * 2.So the community can ignore bug reports including proprietary
> modules
> * 3.So vendors can do likewise based on their own policies
> @@ -138,27 +137,29 @@ extern const struct gtype##_id __mod_##gtype##_table
> \
> * authors use multiple MODULE_AUTHOR() statements/lines.
> */
> #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
> -
> +
> /* What your module does. */
> #define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
> _description)
>
> -#define MODULE_DEVICE_TABLE(type,name) \
> - MODULE_GENERIC_TABLE(type##_device,name)
> +#define MODULE_DEVICE_TABLE(type, name) \
> + MODULE_GENERIC_TABLE(type##_device, name)
>
> /* Version of form [:][-].
> - Or for CVS/RCS ID version, everything but the number is stripped.
> - : A (small) unsigned integer which allows you to start versions
> - anew. If not mentioned, it's zero. eg. "2:1.0" is after
> -"1:2.0".
> - : The may contain only alphanumerics and the
> - character `.'. Ordered by numeric sort for numeric parts,
> -ascii sort for ascii parts (as per RPM or DEB algorithm).
> - : Like , but inserted for local
> - customizations, eg "rh3" or "rusty1".
> -
> - Using this automatically adds a checksum of the .c files and the
> - local headers in "srcversion".
> -*/
> + * Or for CVS/RCS ID version, everything but the number is stripped.
> + * : A (small) unsigned integer which allows you to start versions
> + * anew. If not mentioned, it's zero. eg. "2:1.0" is after
> + * "1:2.0".
> +
> + * : The may contain only alphanumerics and the
> + * character `.'. Ordered by numeric sort for numeric parts,
> + * ascii sort for ascii parts (as per RPM or DEB algorithm).
> +
> + * : Like , but inserted for local
> + * customizations, eg "rh3" or "rusty1".
> +
> + * Using this automatically adds a checksum of the .c files and the
> + * local headers in "srcversion".
> + */
>
> #if defined(MODULE) || !defined(CONFIG_SYSFS)
> #define MODULE_VERSION(_version) MODULE_INFO(version, _version)
> @@ -226,8 +227,7 @@ struct module_ref {
> unsigned long decs;
> } __attribute((aligned(2 * sizeof(unsigned long;
>
> -struct module
> -{
> +struct module {
> enum module_state state;
>
> /* Member of list of modules */
> @@ -480,8 +480,8 @@ static inline void module_put(struct module *module)
> static inline void __module_get(struct module *module)
> {
> }
> -#define symbol_put(x) do { } while(0)
> -#define symbol_put_addr(p) do { } while(0)
> +#define symbol_put(x) do { } while (0)
> +#define symbol_put_addr(p) do { } while (0)
>
> #endif /* CONFIG_MODULE_UNLOAD */
> int ref_module(struct module *a, struct module *b);
> @@ -507,8 +507,8 @@ int lookup_module_symbol_attrs(unsigned long addr,
> unsigned long *size, unsigned
> /* For extable.c to search modules' exception tables. */
> const struct exception_table_entry *search_module_extables(unsigned long
> addr);
>
> -int register_module_notifier(struct notifier_block * nb);
> -int unregister_module_notifier(struct notifier_block * nb);
> +int register_module_notifier(struct notifier_block *nb);
> +int unregister_module_notifier(struct notifier_block *nb);
>
> extern void print_modules(void);
>
> @@ -548,8 +548,8 @@ static inline bool is_module_text_address(unsigned long
> addr)
>
> /* Get/put a kernel symbol (calls should
[PATCH 1/5] Documentation: APM X-Gene SoC Ethernet DTS binding documentation
Documentation explaining dts nodes.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
.../devicetree/bindings/net/apm-xgene-enet.txt | 67
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
new file mode 100644
index 000..8b88b74
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -0,0 +1,67 @@
+APM X-Gene SoC Ethernet nodes
+
+Ethernet nodes are defined to describe on-chip ethernet interfaces in
+APM X-Gene SoC. Ethernet subsystem communicates with a central Queue Manager
+(QMTM) using messages for transmit, receive and allocating data buffers.
+There are multiple ethernet interfaces in APM X-Gene SoC. Each ethernet
+interface has its own node. Its corresponding clock nodes are shown below.
+
+Required properties:
+- compatible : Shall be "apm,xgene-enet"
+- reg : First memory resource shall be the Ethernet CSR
+ memory resource for indirect MAC access.
+ Second memory resource shall be the Ethernet CSR
+ memory resource.
+ Third memory resource shall be the Ethernet CSR
+ memory resource for indirect MII access.
+- slave-name : Shall be QMTM slave name.
+- interrupts : First interrupt resource shall be the Ethernet global
+ Error interrupt.
+ : Second interrupt resource shall be the Ethernet MAC
+ Error interrupt.
+ : Third interrupt resource shall be the Ethernet QM
+ interface interrupt.
+- clocks : Reference to the clock entry.
+- local-mac-address: Shall be ethernet mac address.
+- max-frame-size : Shall be maximum ethernet frame size.
+- devid: Shall be ethernet interface number.
+- phyid: Shall be ethernet MII phy address.
+- phy-mode : Shall be ethernet MII mode.
+
+Optional properties:
+- status : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+
+Example:
+ eth8clk: eth8clk {
+ compatible = "apm,xgene-device-clock";
+ clock-names = "eth8clk";
+ status = "ok";
+ };
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0x30>,
+ <0x0 0x1702 0x0 0x1>,
+ <0x0 0x1702 0x0 0x20>;
+ slave-name = "RGMII";
+ interrupts = <0x0 0x38 0x4>,
+<0x0 0x39 0x4>,
+<0x0 0x3a 0x4>;
+ clocks = < 0>;
+ local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
+ max-frame-size = <0x233a>;
+ devid = <8>;
+ phyid = <3>;
+ phy-mode = "rgmii";
+ };
+
+/* Board-specific peripheral configurations */
+aliases {
+ ethernet0 =
+};
+
+ {
+status = "ok";
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] drivers: net: APM X-Gene SoC Ethernet driver error handling
Error handling and error interrupt handler code. Signed-off-by: Iyappan Subramanian Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- drivers/net/ethernet/apm/xgene/Makefile |3 +- drivers/net/ethernet/apm/xgene/xgene_enet_csr.h | 265 +++- drivers/net/ethernet/apm/xgene/xgene_enet_err.c | 715 ++ drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 27 + drivers/net/ethernet/apm/xgene/xgene_enet_main.h |4 + 5 files changed, 1011 insertions(+), 3 deletions(-) create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_err.c diff --git a/drivers/net/ethernet/apm/xgene/Makefile b/drivers/net/ethernet/apm/xgene/Makefile index 16dfc6c..091547e 100644 --- a/drivers/net/ethernet/apm/xgene/Makefile +++ b/drivers/net/ethernet/apm/xgene/Makefile @@ -5,6 +5,7 @@ xgene-enet-objs := \ xgene_enet_common.o \ xgene_enet_mac.o\ - xgene_enet_main.o + xgene_enet_main.o \ + xgene_enet_err.o obj-$(CONFIG_NET_XGENE) += xgene-enet.o diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h b/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h index c6b49c9..858d155 100644 --- a/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h @@ -19,6 +19,13 @@ #ifndef __XGENE_ENET_CSR_H__ #define __XGENE_ENET_CSR_H__ +#define RSIF_INT_REG0_ADDR 0x0054 +#define RSIF_FINT_REG0_ADDR 0x005c +#define TSIF_INT_REG0_ADDR 0x012c +#define TSIF_FINT_REG0_ADDR 0x0134 +#define TSO_INT_REG0_ADDR0x0324 +#define SPI2SAP_INT_REG0_ADDR0x0448 +#define RX_TX_BUF_CHKSM_INT_REG0_ADDR0x052c #define ENET_SPARE_CFG_REG_ADDR 0x0750 #define RSIF_CONFIG_REG_ADDR 0x0010 #define RSIF_RAM_DBG_REG0_ADDR 0x0048 @@ -33,7 +40,108 @@ #define TSIF_MSS_REG1_0_ADDR 0x0110 #define TSO_CFG_0_ADDR 0x0314 #define TSO_CFG_INSERT_VLAN_0_ADDR 0x031c -#define CFG_RSIF_FPBUFF_TIMEOUT_EN_WR(src) (((u32)(src)<<31) & 0x8000) +#define CFG_RSIF_FPBUFF_TIMEOUT_EN_WR(src) \ + (((u32)(src)<<31) & 0x8000) +#define RSIF_LCL_RXBUF_FIFO_OVERFL_INTR_RXPRT10_MASK 0x2000 +#define RSIF_LCL_RXBUF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x2000)>>29) +#define RSIF_LCL_RXBUF_FIFO_UNDERFL_INTR_RXPRT10_MASK0x1000 +#define RSIF_LCL_RXBUF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x1000)>>28) +#define RSIF_CHKSUM_BUFF_FIFO_OVERFL_INTR_RXPRT10_MASK 0x0800 +#define RSIF_CHKSUM_BUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0800)>>27) +#define RSIF_CHKSUM_BUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK 0x0400 +#define RSIF_CHKSUM_BUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0400)>>26) +#define RSIF_TIMESTAMP_BUFF_FIFO_OVERFL_INTR_RXPRT10_MASK0x0200 +#define RSIF_TIMESTAMP_BUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0200)>>25) +#define RSIF_TIMESTAMP_BUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK 0x0100 +#define RSIF_TIMESTAMP_BUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0100)>>24) +#define RSIF_ERR_BUFF_FIFO_OVERFL_INTR_RXPRT10_MASK 0x0080 +#define RSIF_ERR_BUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0080)>>23) +#define RSIF_ERR_BUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK 0x0040 +#define RSIF_ERR_BUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0040)>>22) +#define RSIF_CLEBUFF_FIFO_OVERFL_INTR_RXPRT10_MASK 0x0020 +#define RSIF_CLEBUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0020)>>21) +#define RSIF_CLEBUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK 0x0010 +#define RSIF_CLEBUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0010)>>20) +#define RSIF_CTRLBUFF_FIFO_OVERFL_INTR_RXPRT10_MASK 0x0008 +#define RSIF_CTRLBUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0008)>>19) +#define RSIF_CTRLBUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK 0x0004 +#define RSIF_CTRLBUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0004)>>18) +#define RSIF_BUF_FIFO_OVERFL_INTR_RXPRT10_MASK 0x0002 +#define RSIF_BUF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \ + (((src) & 0x0002)>>17) +#define RSIF_BUF_FIFO_UNDERFL_INTR_RXPRT10_MASK
[PATCH 2/5] arm64: dts: APM X-Gene SoC Ethernet device tree nodes
Device tree files for APM X-Gene SoC Ethernet.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
arch/arm64/boot/dts/apm-mustang.dts |8
arch/arm64/boot/dts/apm-storm.dtsi | 19 +++
2 files changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-mustang.dts
b/arch/arm64/boot/dts/apm-mustang.dts
index 1247ca1..ccb2771 100644
--- a/arch/arm64/boot/dts/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -17,6 +17,10 @@
model = "APM X-Gene Mustang board";
compatible = "apm,mustang", "apm,xgene-storm";
+aliases {
+ethernet0 =
+};
+
chosen { };
memory {
@@ -24,3 +28,7 @@
reg = < 0x1 0x 0x0 0x8000 >; /* Updated by
bootloader */
};
};
+
+ {
+status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index f64f946..9c7b8cd 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -204,5 +204,24 @@
#clock-cells = <1>;
clocks = < 0>;
};
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0x30>,
+ <0x0 0x1702 0x0 0x1>,
+ <0x0 0x1702 0x0 0x20>;
+ slave-name = "RGMII";
+ interrupts = <0x0 0x38 0x4>,
+<0x0 0x39 0x4>,
+<0x0 0x3a 0x4>;
+ #clock-cells = <1>;
+ clocks = < 0>;
+ local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
+ max-frame-size = <0x233a>;
+ devid = <8>;
+ phyid = <3>;
+ phy-mode = "rgmii";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] drivers: net: APM X-Gene SoC Ethernet driver ethtool support
Ethtool support for APM X-Gene SoC ethernet driver.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
drivers/net/ethernet/apm/xgene/Makefile |3 +-
drivers/net/ethernet/apm/xgene/xgene_enet_csr.h |4 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c |1 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.h |1 +
drivers/net/ethernet/apm/xgene/xgene_enet_tools.c | 296 +
5 files changed, 304 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_tools.c
diff --git a/drivers/net/ethernet/apm/xgene/Makefile
b/drivers/net/ethernet/apm/xgene/Makefile
index 091547e..472710d 100644
--- a/drivers/net/ethernet/apm/xgene/Makefile
+++ b/drivers/net/ethernet/apm/xgene/Makefile
@@ -6,6 +6,7 @@ xgene-enet-objs := \
xgene_enet_common.o \
xgene_enet_mac.o\
xgene_enet_main.o \
- xgene_enet_err.o
+ xgene_enet_err.o\
+ xgene_enet_tools.o
obj-$(CONFIG_NET_XGENE) += xgene-enet.o
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h
b/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h
index 858d155..5ca0d81 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_csr.h
@@ -357,6 +357,10 @@
#define INTERFACE_CONTROL_ADDR 0x0038
#define STATION_ADDR0_ADDR 0x0040
#define STATION_ADDR1_ADDR 0x0044
+#define RX_FLOW_EN1_MASK 0x0020
+#define TX_FLOW_EN1_MASK 0x0010
+#define RX_FLOW_EN1_RD(src) (((src) & 0x0020)>>5)
+#define TX_FLOW_EN1_RD(src) (((src) & 0x0010)>>4)
#define SCAN_CYCLE_MASK 0x0002
#define SOFT_RESET1_MASK 0x8000
#define MAX_FRAME_LEN_SET(dst, src) \
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 90f53b8..77d3fd8 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1416,6 +1416,7 @@ static int xgene_enet_init_hw(struct xgene_enet_pdev
*pdev)
/* Ethtool checks the capabilities/features in hw_features flag */
ndev->hw_features = ndev->features;
+ SET_ETHTOOL_OPS(ndev, _ethtool_ops);
rc = register_netdev(ndev);
if (rc) {
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index b25bb37..b95f129 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -173,4 +173,5 @@ void xgene_enet_init_priv(struct xgene_enet_priv *priv);
int xgene_enet_parse_error(u8 LErr, int qid);
void xgene_enet_register_err_irqs(struct net_device *ndev);
+extern const struct ethtool_ops xgene_ethtool_ops;
#endif /* __XGENE_ENET_MAIN_H__ */
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_tools.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_tools.c
new file mode 100644
index 000..d99f42b
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_tools.c
@@ -0,0 +1,296 @@
+/* AppliedMicro X-Gene SoC Ethernet Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Authors:Hrishikesh Karanjikar
+ * Ravi Patel
+ * Iyappan Subramanian
+ * Keyur Chudgar
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include "xgene_enet_csr.h"
+#include "xgene_enet_main.h"
+
+struct xgene_stats {
+ char stat_string[ETH_GSTRING_LEN];
+ int sizeof_stat;
+ int stat_offset;
+};
+
+static const struct xgene_stats xgene_gstrings_stats[] = {
+ { "rx_bytes",
+ FIELD_SIZEOF(struct xgene_enet_pdev,
+ stats.rx_stats.rx_byte_count),
+ offsetof(struct xgene_enet_pdev, stats.rx_stats.rx_byte_count)
+ },
+ { "rx_packets",
+ FIELD_SIZEOF(struct xgene_enet_pdev,
+ stats.rx_stats.rx_packet_count),
+ offsetof(struct xgene_enet_pdev, stats.rx_stats.rx_packet_count)
+ },
+ { "rx_fcs_err",
+ FIELD_SIZEOF(struct xgene_enet_pdev,
+
[PATCH 0/5] drivers: net: Adding support for APM X-Gene SoC Ethernet base driver
APM X-Gene SoC Ethernet subsystem communicates with a central Queue Manager (QMTM) using messages for transmit, receive and allocating data buffers. There are multiple ethernet interfaces in APM X-Gene SoC. Signed-off-by: Iyappan Subramanian Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- Iyappan Subramanian (5): Documentation: APM X-Gene SoC Ethernet DTS binding documentation arm64: dts: APM X-Gene SoC Ethernet device tree nodes drivers: net: APM X-Gene SoC Ethernet base driver drivers: net: APM X-Gene SoC Ethernet driver error handling drivers: net: APM X-Gene SoC Ethernet driver ethtool support .../devicetree/bindings/net/apm-xgene-enet.txt | 67 + MAINTAINERS|7 + arch/arm64/boot/dts/apm-mustang.dts|8 + arch/arm64/boot/dts/apm-storm.dtsi | 19 + drivers/net/ethernet/Kconfig |1 + drivers/net/ethernet/Makefile |1 + drivers/net/ethernet/apm/Kconfig |1 + drivers/net/ethernet/apm/Makefile |5 + drivers/net/ethernet/apm/xgene/Kconfig | 10 + drivers/net/ethernet/apm/xgene/Makefile| 12 + drivers/net/ethernet/apm/xgene/xgene_enet_common.c | 497 ++ drivers/net/ethernet/apm/xgene/xgene_enet_common.h | 450 ++ drivers/net/ethernet/apm/xgene/xgene_enet_csr.h| 427 ++ drivers/net/ethernet/apm/xgene/xgene_enet_err.c| 715 + drivers/net/ethernet/apm/xgene/xgene_enet_mac.c| 520 +++ drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 1609 drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 177 +++ drivers/net/ethernet/apm/xgene/xgene_enet_tools.c | 296 18 files changed, 4822 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt create mode 100644 drivers/net/ethernet/apm/Kconfig create mode 100644 drivers/net/ethernet/apm/Makefile create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig create mode 100644 drivers/net/ethernet/apm/xgene/Makefile create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_common.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_common.h create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_csr.h create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_err.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_mac.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_tools.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
On 12/20/2013 05:32 PM, Eric W. Biederman wrote: > > Stuff and nonsense. bzImage is just an ugly wrapper around an ELF > image. > Not really. We put the ELF image in there to help Xen and presumably kexec, but there are actually quite a few issues with it... for one thing, as currently built there are megabytes of zeroes in it for no good reason. Even if you don't need the entry code, the additional metadata is meaningful. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Project
May I request for your partnership to execute a project in Asia, revert if interested -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Broken initrd compression settings in 3.13
On Fri, Dec 20, 2013 at 6:23 PM, Jeff Layton wrote: > > But, what's the point of setting INITRD_COMPRESS-y at all if you're not > going to export INITRD_COMPRESS? Would it be better to just remove that > entire block in the Makefile (i.e. just revert PJP's patch?) I ended up committing the minimal change that I was testing, leaving the core code in, just disabling it so that everything works for me on F20. I may happen to think that the kernel shouldn't try to pick the format, but I'm willing to leave the door open for somebody arguing for that approach. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] null_blk: corrections to documentation
On 12/20/13 15:10, Matias Bjorling wrote: > From: Matias Bjørling > > Randy Dunlap reported a couple of grammar errors and unfortunate usages of > socket/node/core. > > Signed-off-by: Matias Bjorling > --- Thanks, looks good. Acked-by: Randy Dunlap -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Broken initrd compression settings in 3.13
On Fri, 20 Dec 2013 18:15:29 -0800 Linus Torvalds wrote: > On Fri, Dec 20, 2013 at 5:39 PM, Andrew Morton > wrote: > > On Fri, 20 Dec 2013 16:41:43 -0800 Linus Torvalds > > wrote: > >> > >> (a) most sane people don't even have lz4 _installed_, so dracut won't > >> actually succeed > >> > >> (b) there's no way to select the compression level (unlike the > >> INITRAMFS_COMPRESSION thing that actually has a choice) > >> > >> (c) even if you *do* have lz4, it doesn't actually work, because > >> while that causes the new F20 dracut to compress the initramfs with > >> lz4, the end result is completely broken, because the F20 "lsinitrd" > >> scripts don't understand the end result, so now the whole kernel > >> install fails. > >> > >> (a) and (b) are very much kernel bugs. > > > > Jeff sent the below this morning. Will that fix (a)? > > Yes, it fixes (a), at least to some degree, in that at least > defaulting to bzip2 is a lot more sane than defaulting to lz4. I > suspect most everybody has bzip2 installed. And at least on my current > F20 install, it looks like lsinitrd understands to use zcat, bzcat or > xzcat on the resulting initrd image (and bzcat does that bzip2 > decoding). > > So I think Jeff's patch at least fixes the symptoms. > > That said, I think it does nothing *but* fix the symptoms, and we're > actually still better off with the 3.12 behavior which was to never > set INITRD_COMPRESS at all. Because quite frankly, there's currently > no way for the kernel to know what the right compressor is. bz2 may > well work, but can you guarantee it? I certainly can't.. > > Now, if we asked the user, that would be a different thing. But right > now we very much don't ask the user, and we just pick one at random. > > We're better off not picking a compression method at all, at which > point the distro "installkernel" will do whatever the distro does. > > Linus That works for me, you can drop my patch... But, what's the point of setting INITRD_COMPRESS-y at all if you're not going to export INITRD_COMPRESS? Would it be better to just remove that entire block in the Makefile (i.e. just revert PJP's patch?) -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] futex: Avoid taking hb lock if nothing to wakeup
On Fri, 2013-12-20 at 18:34 -0800, Darren Hart wrote: > On Fri, 2013-12-20 at 17:36 -0800, Davidlohr Bueso wrote: > > On Thu, 2013-12-19 at 15:14 -0800, Linus Torvalds wrote: > > > On Thu, Dec 19, 2013 at 10:45 AM, Davidlohr Bueso > > > wrote: > > > > > > > > - increment the counter at queue_lock() as we always end up calling > > > > queue_me() which adds the element to the list. Upon any error, > > > > queue_unlock() is called for housekeeping, for which we decrement > > > > to mach the increment done in queue_lock(). > > > > > > > > - decrement the counter at __unqueue_me() to reflect when an element is > > > > removed from the queue for wakeup related purposes. > > > > > > I still hate this whole separate counter thing. It seems really annoying. > > > > > > If re-ordering things didn't work out, then why can't just the counter > > > we *already* have in the spinlock itself work as the counter? Your > > > counter update logic seems to basically match when you take the > > > spinlock anyway. > > > > So the following has passed all testing, just like the atomics variant. > > Thoughts? > > Do you have similar performance numbers for comparison? I presume they > were *very* similar to the atomics version - I think you hinted at that > in a previous post? Performance isn't a factor, both approaches are pretty much identical. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf and Kconfig
On 12/20/13 16:39, Alexis Berlemont wrote: > Hi, > > Here is a proposal of a small contribution which tries to fulfill the > task "Use Kconfig to allow selecting features and build minimal > version of perf,..." displayed on the todo page of the perf > wiki (https://perf.wiki.kernel.org/index.php/Todo). > > I tried to continue the work started by David Ahern > (https://github.com/dsahern/linux.git branch:perf-config). This > version relies on the features detection tests available in > linux/tools/perf/config/feature-checks so as to enable some > configuration options (at least by default). > > This little task is not complete; more Kconfig options should be added > for each perf tool (top, record, report, ...). > > I just wanted to ask whether you consider this proposal as interesting > enough for inclusion and if you are ok with the way it is implemented. > > The code is available here: https://github.com/aberlemont/linux.git > - branch: perf-config. Hi, The correct way to have any code reviewed is to post the code (not a link to it) on the mailing list. thanks, -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/4] arm64: boot: dts: Add DTS entries for APM X-Gene SoC Queue Manager/Traffic Manager
This patch adds APM X-Gene SoC Queue Manager/Traffic Manager DTS entries.
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
arch/arm64/boot/dts/apm-storm.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..f64f946 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -152,6 +152,11 @@
reg = <0x0 0x1703C000 0x0 0x1000>;
reg-names = "csr-reg";
clock-output-names = "qmlclk";
+ status = "ok";
+ csr-offset = <0x0>;
+ csr-mask = <0x3>;
+ enable-offset = <0x8>;
+ enable-mask = <0x3>;
};
ethclk: ethclk {
@@ -187,5 +192,17 @@
interrupt-parent = <>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ qmlite: qmtm@1703 {
+ compatible = "apm,xgene-qmtm-lite";
+ reg = <0x0 0x1703 0x0 0x1>,
+ <0x0 0x1000 0x0 0x40>;
+ slave-name = "CPU_QMTM3";
+ interrupts = <0x0 0x40 0x4>,
+<0x0 0x3c 0x4>;
+ status = "ok";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/4] misc: xgene: Add base driver for APM X-Gene SoC Queue Manager/Traffic Manager
This patch adds APM X-Gene SoC Queue Manager/Traffic Manager base driver. QMTM is requried by Ethernet, PktDMA (XOR Engine) and Security Engine subsystems. Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- MAINTAINERS|7 + drivers/misc/Kconfig |1 + drivers/misc/Makefile |1 + drivers/misc/xgene/Kconfig |1 + drivers/misc/xgene/Makefile|5 + drivers/misc/xgene/qmtm/Kconfig|9 + drivers/misc/xgene/qmtm/Makefile |7 + drivers/misc/xgene/qmtm/xgene_qmtm_main.c | 761 drivers/misc/xgene/qmtm/xgene_qmtm_main.h | 134 + drivers/misc/xgene/qmtm/xgene_qmtm_storm.c | 370 ++ drivers/misc/xgene/qmtm/xgene_qmtm_storm.h | 139 + include/misc/xgene/xgene_qmtm.h| 277 ++ 12 files changed, 1712 insertions(+) create mode 100644 drivers/misc/xgene/Kconfig create mode 100644 drivers/misc/xgene/Makefile create mode 100644 drivers/misc/xgene/qmtm/Kconfig create mode 100644 drivers/misc/xgene/qmtm/Makefile create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_main.c create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_main.h create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_storm.c create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_storm.h create mode 100644 include/misc/xgene/xgene_qmtm.h diff --git a/MAINTAINERS b/MAINTAINERS index f216db8..920cae8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -665,6 +665,13 @@ S: Maintained F: drivers/net/appletalk/ F: net/appletalk/ +APPLIEDMICRO (APM) X-GENE SOC QUEUE MANAGER/TRAFFIC MANAGER (QMTM) DRIVER +M: Ravi Patel +M: Keyur Chudgar +S: Maintained +F: drivers/misc/xgene/ +F: include/misc/xgene/xgene_qmtm.h + APTINA CAMERA SENSOR PLL M: Laurent Pinchart L: linux-me...@vger.kernel.org diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index a3e291d..b309553 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -525,4 +525,5 @@ source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" source "drivers/misc/vmw_vmci/Kconfig" source "drivers/misc/mic/Kconfig" +source "drivers/misc/xgene/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index f45473e..0fd3b1b 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -53,3 +53,4 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o obj-$(CONFIG_SRAM) += sram.o obj-y += mic/ +obj-$(CONFIG_ARCH_XGENE) += xgene/ diff --git a/drivers/misc/xgene/Kconfig b/drivers/misc/xgene/Kconfig new file mode 100644 index 000..8f38568 --- /dev/null +++ b/drivers/misc/xgene/Kconfig @@ -0,0 +1 @@ +source "drivers/misc/xgene/qmtm/Kconfig" diff --git a/drivers/misc/xgene/Makefile b/drivers/misc/xgene/Makefile new file mode 100644 index 000..198c2e6 --- /dev/null +++ b/drivers/misc/xgene/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for APM X-GENE misc drivers. +# + +obj-$(CONFIG_XGENE_QMTM) += qmtm/ diff --git a/drivers/misc/xgene/qmtm/Kconfig b/drivers/misc/xgene/qmtm/Kconfig new file mode 100644 index 000..8efda4d --- /dev/null +++ b/drivers/misc/xgene/qmtm/Kconfig @@ -0,0 +1,9 @@ +config XGENE_QMTM + tristate "APM X-Gene Queue Manager/Traffic Manager driver" + depends on ARM64 || COMPILE_TEST + default y + help + This option enables APM X-Gene Queue Manager Traffic Manager (QMTM) + driver support. + QMTM is required for Ethernet, PktDMA (XOR Engine) and Security + Engine. diff --git a/drivers/misc/xgene/qmtm/Makefile b/drivers/misc/xgene/qmtm/Makefile new file mode 100644 index 000..68c2a86 --- /dev/null +++ b/drivers/misc/xgene/qmtm/Makefile @@ -0,0 +1,7 @@ +# +# Makefile for APM X-GENE Queue Manager Traffic Manager driver. +# + +obj-$(CONFIG_XGENE_QMTM) += xgene-qmtm.o + +xgene-qmtm-objs := xgene_qmtm_main.o xgene_qmtm_storm.o diff --git a/drivers/misc/xgene/qmtm/xgene_qmtm_main.c b/drivers/misc/xgene/qmtm/xgene_qmtm_main.c new file mode 100644 index 000..cda63e0 --- /dev/null +++ b/drivers/misc/xgene/qmtm/xgene_qmtm_main.c @@ -0,0 +1,761 @@ +/* + * AppliedMicro X-Gene SOC Queue Manager/Traffic Manager driver + * + * Copyright (c) 2013 Applied Micro Circuits Corporation. + * Author: Ravi Patel + * Keyur Chudgar + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include
[PATCH V2 1/4] Documentation: Add documentation for APM X-Gene SoC Queue Manager/Traffic Manager DTS binding
This patch adds device tree binding documentation for APM X-Gene SoC
Queue Manager/Traffic Manager.
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
.../devicetree/bindings/misc/apm-xgene-qmtm.txt| 51
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/apm-xgene-qmtm.txt
diff --git a/Documentation/devicetree/bindings/misc/apm-xgene-qmtm.txt
b/Documentation/devicetree/bindings/misc/apm-xgene-qmtm.txt
new file mode 100644
index 000..c3fcbd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/apm-xgene-qmtm.txt
@@ -0,0 +1,51 @@
+* APM X-Gene SoC Queue Manager/Traffic Manager nodes
+
+QMTM nodes are defined to describe on-chip Queue Managers in APM X-Gene SoC.
+APM X-Gene SoC Ethernet, PktDMA (XOR Engine), and Security Engine subsystems
+communicate with a central Queue Manager using messages which include
+information about the work to be performed and the location of the associated
+data buffers. There are multiple instances of QMTM. Each QMTM instance has its
+own node. Its corresponding clock nodes are shown below.
+
+Required properties:
+- compatible : Shall be "apm,xgene-qmtm-lite" for QMLite instance
+- reg : First memory resource shall be the QMTM CSR memory
+ resource.
+ Second memory resource shall be the QMTM IO-Fabric
+ memory resource.
+- slave-name : Shall be "CPU_QMTM3" which is receiver for ingress
+ work messages for the QMTM. Here receiver is CPU.
+- interrupts : First interrupt resource shall be the QMTM Error
+ interrupt.
+ Remaining interrupt resources shall be the Ingress
+ work message interrupt mapping for receiver,
+ receiving work messages for the QMTM.
+- clocks : Reference to the clock entry.
+
+Optional properties:
+- status : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+
+Example:
+ qmlclk: qmlclk {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clock-names = "qmlclk";
+ status = "ok";
+ csr-offset = <0x0>;
+ csr-mask = <0x3>;
+ enable-offset = <0x8>;
+ enable-mask = <0x3>;
+ };
+
+ qmlite: qmtm@1703 {
+ compatible = "apm,xgene-qmtm-lite";
+ reg = <0x0 0x1703 0x0 0x1>,
+ <0x0 0x1000 0x0 0x40>;
+ slave-name = "CPU_QMTM3";
+ interrupts = <0x0 0x40 0x4>,
+<0x0 0x3c 0x4>;
+ status = "ok";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager
This patch adds support for APM X-Gene SoC Queue Manager/Traffic Manager. QMTM is required by APM X-Gene SoC Ethernet, PktDMA (XOR Engine) and Security Engine subsystems. All subsystems communicate with QMTM using messages which include information about the work to be performed and the location of associated data buffers. V2: * Adding COMPILE_TEST dependency for QMTM in Kconfig * Updated license banner as per review comments * Fixed alignment for macros * Changed EXPORT_SYMBOL to EXPORT_SYMBOL_GPL V1: * inital version Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- Ravi Patel (4): Documentation: Add documentation for APM X-Gene SoC Queue Manager/Traffic Manager DTS binding misc: xgene: Add base driver for APM X-Gene SoC Queue Manager/Traffic Manager arm64: boot: dts: Add DTS entries for APM X-Gene SoC Queue Manager/Traffic Manager misc: xgene: Add error handling for APM X-Gene SoC Queue Manager/Traffic Manager .../devicetree/bindings/misc/apm-xgene-qmtm.txt| 51 ++ MAINTAINERS|7 + arch/arm64/boot/dts/apm-storm.dtsi | 17 + drivers/misc/Kconfig |1 + drivers/misc/Makefile |1 + drivers/misc/xgene/Kconfig |1 + drivers/misc/xgene/Makefile|5 + drivers/misc/xgene/qmtm/Kconfig|9 + drivers/misc/xgene/qmtm/Makefile |7 + drivers/misc/xgene/qmtm/xgene_qmtm_error.c | 283 drivers/misc/xgene/qmtm/xgene_qmtm_main.c | 765 drivers/misc/xgene/qmtm/xgene_qmtm_main.h | 138 drivers/misc/xgene/qmtm/xgene_qmtm_storm.c | 370 ++ drivers/misc/xgene/qmtm/xgene_qmtm_storm.h | 139 include/misc/xgene/xgene_qmtm.h| 277 +++ 15 files changed, 2071 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/apm-xgene-qmtm.txt create mode 100644 drivers/misc/xgene/Kconfig create mode 100644 drivers/misc/xgene/Makefile create mode 100644 drivers/misc/xgene/qmtm/Kconfig create mode 100644 drivers/misc/xgene/qmtm/Makefile create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_error.c create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_main.c create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_main.h create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_storm.c create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_storm.h create mode 100644 include/misc/xgene/xgene_qmtm.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/4] misc: xgene: Add error handling for APM X-Gene SoC Queue Manager/Traffic Manager
This patch adds support for error handling in APM X-Gene SoC Queue
Manager/Traffic Manager.
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
drivers/misc/xgene/qmtm/Makefile |2 +-
drivers/misc/xgene/qmtm/xgene_qmtm_error.c | 283
drivers/misc/xgene/qmtm/xgene_qmtm_main.c |6 +-
drivers/misc/xgene/qmtm/xgene_qmtm_main.h |4 +
4 files changed, 293 insertions(+), 2 deletions(-)
create mode 100644 drivers/misc/xgene/qmtm/xgene_qmtm_error.c
diff --git a/drivers/misc/xgene/qmtm/Makefile b/drivers/misc/xgene/qmtm/Makefile
index 68c2a86..8448253 100644
--- a/drivers/misc/xgene/qmtm/Makefile
+++ b/drivers/misc/xgene/qmtm/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_XGENE_QMTM) += xgene-qmtm.o
-xgene-qmtm-objs := xgene_qmtm_main.o xgene_qmtm_storm.o
+xgene-qmtm-objs := xgene_qmtm_main.o xgene_qmtm_storm.o xgene_qmtm_error.o
diff --git a/drivers/misc/xgene/qmtm/xgene_qmtm_error.c
b/drivers/misc/xgene/qmtm/xgene_qmtm_error.c
new file mode 100644
index 000..5b4f4a9
--- /dev/null
+++ b/drivers/misc/xgene/qmtm/xgene_qmtm_error.c
@@ -0,0 +1,283 @@
+/*
+ * AppliedMicro X-Gene SOC Queue Manager/Traffic Manager driver
+ *
+ * Copyright (c) 2013 Applied Micro Circuits Corporation.
+ * Author: Ravi Patel
+ * Keyur Chudgar
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include "xgene_qmtm_main.h"
+
+#define QM_INTERRUPT_ADDR 0x0124
+#define QM_INTERRUPTMASK_ADDR 0x0128
+#define QUEUE_NOT_EMPTYMASK_MASK 0x8000
+#define ACR_FIFO_CRITICALMASK_MASK 0x0008
+#define QPCORE_ACR_ERRORMASK_MASK 0x0004
+#define DEQ_AXI_ERRORMASK_MASK 0x0002
+#define PBM_DEC_ERRORMASK_MASK 0x0001
+
+#define CSR_PBM_ERRINF_ADDR0x0134
+#define ACR_QID_RD(src) (((src) & 0x00ffc000)>>14)
+#define QID_RD(src) (((src) & 0x03ff))
+
+#define CSR_MSGRD_ERRINF_ADDR 0x0138
+
+#define CSR_ERRQ_ADDR 0x0218
+#define UNEXPECTED_EN_SET(dst, src) \
+ (((dst) & ~0x8000) | (((u32)(src)<<31) & 0x8000))
+#define UNEXPECTED_QID_SET(dst, src) \
+ (((dst) & ~0x03ff) | (((u32)(src)<<16) & 0x03ff))
+#define EXPECTED_EN_SET(dst, src) \
+ (((dst) & ~0x8000) | (((u32)(src)<<15) & 0x8000))
+#define EXPECTED_QID_SET(dst, src) \
+ (((dst) & ~0x03ff) | (((u32)(src)) & 0x03ff))
+
+/* QMTM Error Reporting */
+enum xgene_qmtm_lerr {
+ QMTM_NO_ERR,
+ QMTM_MSG_SIZE_ERR,
+ QMTM_HOP_COUNT_ERR,
+ QMTM_VQ_ENQ_ERR,
+ QMTM_DISABLEDQ_ENQ_ERR,
+ QMTM_Q_OVERFLOW_ERR,
+ QMTM_ENQUEUE_ERR,
+ QMTM_DEQUEUE_ERR,
+};
+
+/* Parse Error Message received on Error Queue */
+static void xgene_qmtm_error_msg(struct xgene_qmtm_qinfo *qinfo,
+struct xgene_qmtm_msg32 *msg)
+{
+ struct xgene_qmtm_msg16 *msg16 = >msg16;
+ struct device *dev = >qmtm->pdev->dev;
+ u16 queue_id = qinfo->queue_id;
+
+ dev_err(dev, "Error ELErr[%d] LErr[%d] for Qid[%d]\n",
+ msg16->ELErr, msg16->LErr, queue_id);
+
+ switch (msg16->LErr) {
+ case QMTM_MSG_SIZE_ERR:
+ dev_err(dev, "Msg Size Error for Enqueue on Queue %d\n",
+ queue_id);
+ break;
+ case QMTM_HOP_COUNT_ERR:
+ dev_err(dev, "Hop count error, hop count of 3 for Queue %d\n",
+ queue_id);
+ break;
+ case QMTM_VQ_ENQ_ERR:
+ dev_err(dev, "Enqueue on Virtual Queue %d\n", queue_id);
+ break;
+ case QMTM_DISABLEDQ_ENQ_ERR:
+ dev_err(dev, "Enqueue on disabled Queue %d\n", queue_id);
+ break;
+ case QMTM_Q_OVERFLOW_ERR:
+ dev_err(dev, "Queue %d overflow, message sent to Error Queue\n",
+ queue_id);
+ break;
+ case QMTM_ENQUEUE_ERR:
+ dev_err(dev, "Enqueue Queue\n");
+ break;
+ case QMTM_DEQUEUE_ERR:
+ dev_err(dev, "Dequeue Queue\n");
+ break;
+ default:
+ dev_err(dev, "Unknown Error\n");
+ break;
+ }
+}
+
+static void xgene_qmtm_error(struct xgene_qmtm *qmtm)
+{
+ struct device *dev = >pdev->dev;
+ struct xgene_qmtm_qinfo qinfo;
+ u32 status;
+ u32 pbm_err;
+ u32 msgrd_err;
+
+ memset(, 0, sizeof(qinfo));
+ qinfo.qmtm = qmtm;
+
+ xgene_qmtm_rd32(qmtm,
Re: [PATCH v2] fuse: Fix IOC_[GS]ET{FLAGS,VERSION} argument size brokenness.
On Fri, Dec 20, 2013 at 07:09:23PM -0700, Andreas Dilger wrote:
> To be honest, FS_IOC_SETVERSION isn't used by many/any users, so it might be
> better to avoid doing anything with that for now.
>
> In the past we even talked about adding a deprecation warning for that ioctl
> since it adds complexity for little value.
I suspect that most FUSE servers don't handle any of these four ioctls,
but so long as they're there, we ought to make them less surprising to
userspace.
As far as getting rid of SETVERSION, I think that's best left to a fs driver
(or a fuse server) to make that decision, unless everyone wants to eliminate
SETVERSION entirely? I don't remember anyone complaining when I proposed to
disable SETVERSION on metadata_csum ext4 filesystems, but that's hardly
conclusive. :)
The only providers of SETVERSION seem to be ext[234], reiser3, and ocfs2.
--D
>
> Cheers, Andreas
>
> > On Dec 20, 2013, at 16:35, "Darrick J. Wong"
> > wrote:
> >
> > The IOC_[GS]ETFLAGS and IOC_[GS]ETVERSION ioctls, despite being
> > defined to take a "long" parameter, actually take "int" parameters.
> > FUSE unfortunately assumed that the ioctl definitions never lie, and
> > transfers a long's worth of data in and out of userspace, which causes
> > stack smashing in chattr, and other bugs elsewhere.
> >
> > So, special-case this in FUSE so that we don't crash userland.
> >
> > v2: Do the same for the IOC_[GS]ETVERSION ioctls, as Richard Hansen
> >points out.
> >
> > Signed-off-by: Darrick J. Wong
> > ---
> > fs/fuse/file.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> > index 7e70506..f8766ab 100644
> > --- a/fs/fuse/file.c
> > +++ b/fs/fuse/file.c
> > @@ -2385,6 +2385,22 @@ long fuse_do_ioctl(struct file *file, unsigned int
> > cmd, unsigned long arg,
> >iov->iov_base = (void __user *)arg;
> >iov->iov_len = _IOC_SIZE(cmd);
> >
> > +/*
> > + * The IOC_[GS]ETFLAGS and IOC_[GS]ETVERSION ioctls take int
> > + * parameters even though the ioctl definition specifies long.
> > + * Userland has been expecting int for ages (and chattr
> > + * segfaults on FUSE filesystems), so special case that here.
> > + * The IOC32 variants were declared with int, so they don't
> > + * need this correction.
> > + */
> > +switch (cmd) {
> > +case FS_IOC_GETFLAGS:
> > +case FS_IOC_SETFLAGS:
> > +case FS_IOC_GETVERSION:
> > +case FS_IOC_SETVERSION:
> > +iov->iov_len = sizeof(int);
> > +}
> > +
> >if (_IOC_DIR(cmd) & _IOC_WRITE) {
> >in_iov = iov;
> >in_iovs = 1;
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME
於 五，2013-12-20 於 22:45 +0100，Rafael J. Wysocki 提到： > On Friday, December 20, 2013 01:10:26 PM H. Peter Anvin wrote: > > On 12/19/2013 09:38 PM, joeyli wrote: > > > > > > If don't use EFI time, then the first priority is using ACPI TAD if it > > > present. Due to ACPI TAD is a generic acpi device that's need OS parsing > > > DSDT table before set system time. > > > > > > Either move DSDT parser from subsystem initial stage to start_kernel or > > > move timekeeping initial to after DSDT be parsed. Which one you think is > > > more possible and risk less? Then I will try that way. > > > > > > > I discussed the DSDT/SSDT parsing issue with Rafael and he claims it > > would require a lot of restructuring. Unfortunately ACPI is at this > > point done rather late, as I understand. All of this is a big problem. > > My understanding, however, is that to use the TAD, we don't actually need to > create a struct acpi_device for it. We just need a handle to the ACPICA > object which can be found using acpi_get_devices() as soon as the namespace > has been extracted from the DSDT and friends. That in turn happens in > acpi_early_init(), which is called from start_kernel() right before > efi_late_init(). > > Is that early enough? > > Rafael > Thanks for your good suggestion, then I have a direction on using ACPI TAD earlier. Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Broken initrd compression settings in 3.13
On Fri, Dec 20, 2013 at 6:33 PM, Jeff Layton wrote: > > Perhaps a better solution for this would be to instead export an > env var with a list of the compression algorithms that the kernel > supports. Then installkernel or dracut could use that info to make a > semi-intelligent decision based on that and what tools are installed. > > ...or maybe a separate env var for each one that it supports: > > $INITRD_COMPRESS_LZ4 > $INITRD_COMPRESS_BZIP2 > $INITRD_COMPRESS_GZIP > > ...etc. Agreed, either of those would work. Of course, so does just "distro selects whatever compression method it thinks is best, and when you compile a kernel for that distro, you need to make sure that that kernel knows how to uncompress the initrd". Which quite frankly is the sanest approach of all. *Especially* considering that right now we default to supporting all the initrd compression methods. And it has the advantage of not needing anything like this at all. When you compile a kernel, you already need to compile in support for the stuff the distro needs. This is no different, really. So I think the whole "kernel tells the distro what compression method to use" approach is broken and silly, and the wrong way around. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] futex: Avoid taking hb lock if nothing to wakeup
On Fri, 2013-12-20 at 17:36 -0800, Davidlohr Bueso wrote: > On Thu, 2013-12-19 at 15:14 -0800, Linus Torvalds wrote: > > On Thu, Dec 19, 2013 at 10:45 AM, Davidlohr Bueso wrote: > > > > > > - increment the counter at queue_lock() as we always end up calling > > > queue_me() which adds the element to the list. Upon any error, > > > queue_unlock() is called for housekeeping, for which we decrement > > > to mach the increment done in queue_lock(). > > > > > > - decrement the counter at __unqueue_me() to reflect when an element is > > > removed from the queue for wakeup related purposes. > > > > I still hate this whole separate counter thing. It seems really annoying. > > > > If re-ordering things didn't work out, then why can't just the counter > > we *already* have in the spinlock itself work as the counter? Your > > counter update logic seems to basically match when you take the > > spinlock anyway. > > So the following has passed all testing, just like the atomics variant. > Thoughts? Do you have similar performance numbers for comparison? I presume they were *very* similar to the atomics version - I think you hinted at that in a previous post? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/6] ARM: pinctrl: Add Broadcom Capri pinctrl driver
On 13-12-18 03:56 PM, Sherman Yin wrote:
On 13-12-12 12:54 PM, Linus Walleij wrote:
+/*
+ * Write to the register using the value and mask if current value
is different
+ */
+static void capri_reg_write(struct pinctrl_dev *pctldev,
+ void __iomem *reg,
+ u32 val,
+ u32 mask)
+{
+ u32 old_val;
+ u32 new_val;
+
+ old_val = readl(reg);
+ new_val = (old_val & ~mask) | (val & mask);
+
+ if (new_val == old_val) {
+ dev_dbg(pctldev->dev,
+ "Reg 0x%p=0x%x (no change)\n",
+ reg, old_val);
+ return;
+ }
+
+ dev_dbg(pctldev->dev,
+ "Reg 0x%p change from 0x%x to 0x%x\n",
+ reg, old_val, new_val);
+ writel(new_val, reg);
+}
This is a reimplementation of regmap for MMIO.
See drivers/base/regmap/regmap-mmio.c
Notice how regmap_update_bits() is used throughout the
kernel.
If you want to do this, use regmap.
Ok.
As you can see in v4 of my patchset, I've changed my driver to use the
mmio regmap. However, as I was tracing through regmap_update_bits(), it
looks like I have to go through a lot of checks and function pointers
just to do a simple write to a register. Also, I have to select
REGMAP_MMIO which brings in a bunch of code as well.
I understand the benefits of using common code, but in this case it
seems there is a lot of extra code and run-time overhead to use regmap.
In the end it also doesn't buy much in terms of functionality.
Just a quick note - it looks like the 2nd parameter of
regmap_update_bits() wants the offset of a register (offset from
regmap_mmio_context.regs). So calling the parameter "reg" is a little
confusing, at least in the MMIO case.
Regards,
Sherman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Broken initrd compression settings in 3.13
On Fri, 20 Dec 2013 18:15:29 -0800 Linus Torvalds wrote: > On Fri, Dec 20, 2013 at 5:39 PM, Andrew Morton > wrote: > > On Fri, 20 Dec 2013 16:41:43 -0800 Linus Torvalds > > wrote: > >> > >> (a) most sane people don't even have lz4 _installed_, so dracut won't > >> actually succeed > >> > >> (b) there's no way to select the compression level (unlike the > >> INITRAMFS_COMPRESSION thing that actually has a choice) > >> > >> (c) even if you *do* have lz4, it doesn't actually work, because > >> while that causes the new F20 dracut to compress the initramfs with > >> lz4, the end result is completely broken, because the F20 "lsinitrd" > >> scripts don't understand the end result, so now the whole kernel > >> install fails. > >> > >> (a) and (b) are very much kernel bugs. > > > > Jeff sent the below this morning. Will that fix (a)? > > Yes, it fixes (a), at least to some degree, in that at least > defaulting to bzip2 is a lot more sane than defaulting to lz4. I > suspect most everybody has bzip2 installed. And at least on my current > F20 install, it looks like lsinitrd understands to use zcat, bzcat or > xzcat on the resulting initrd image (and bzcat does that bzip2 > decoding). > > So I think Jeff's patch at least fixes the symptoms. > > That said, I think it does nothing *but* fix the symptoms, and we're > actually still better off with the 3.12 behavior which was to never > set INITRD_COMPRESS at all. Because quite frankly, there's currently > no way for the kernel to know what the right compressor is. bz2 may > well work, but can you guarantee it? I certainly can't.. > > Now, if we asked the user, that would be a different thing. But right > now we very much don't ask the user, and we just pick one at random. > > We're better off not picking a compression method at all, at which > point the distro "installkernel" will do whatever the distro does. > > Linus Perhaps a better solution for this would be to instead export an env var with a list of the compression algorithms that the kernel supports. Then installkernel or dracut could use that info to make a semi-intelligent decision based on that and what tools are installed. ...or maybe a separate env var for each one that it supports: $INITRD_COMPRESS_LZ4 $INITRD_COMPRESS_BZIP2 $INITRD_COMPRESS_GZIP ...etc. -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 2/4] pinctrl: Add pinctrl binding for Broadcom Capri SoCs
Adds pinctrl driver devicetree binding for Broadcom Capri (BCM281xx) SoCs.
Signed-off-by: Sherman Yin
Reviewed-by: Christian Daudt
Reviewed-by: Matt Porter
---
v4: Changed valid values for "bias-pull-up" property for I2C pins. Expanded
pin configuration node example.
v3: Use generic pin config properties instead of brcm-specific ones. Clarified
pin types (standard, i2c, hdmi).
v2: Use hyphens instead of underscore in DT property names.
---
.../bindings/pinctrl/brcm,capri-pinctrl.txt| 461
1 file changed, 461 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt
new file mode 100644
index 000..9e9e9ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt
@@ -0,0 +1,461 @@
+Broadcom Capri Pin Controller
+
+This is a pin controller for the Broadcom BCM281xx SoC family, which includes
+BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs.
+
+=== Pin Controller Node ===
+
+Required Properties:
+
+- compatible: Must be "brcm,capri-pinctrl".
+- reg: Base address of the PAD Controller register block and the size
+ of the block.
+
+For example, the following is the bare minimum node:
+
+ pinctrl@35004800 {
+ compatible = "brcm,capri-pinctrl";
+ reg = <0x35004800 0x430>;
+ };
+
+As a pin controller device, in addition to the required properties, this node
+should also contain the pin configuration nodes that client devices reference,
+if any.
+
+=== Pin Configuration Node ===
+
+Each pin configuration node is a sub-node of the pin controller node and is a
+container of an arbitrary number of subnodes, called pin group nodes in this
+document.
+
+Please refer to the pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the definition of a
+"pin configuration node".
+
+=== Pin Group Node ===
+
+A pin group node specifies the desired pin mux and/or pin configuration for an
+arbitrary number of pins. The name of the pin group node is optional and not
+used.
+
+A pin group node only affects the properties specified in the node, and has no
+effect on any properties that are omitted.
+
+The pin group node accepts a subset of the generic pin config properties. For
+details generic pin config properties, please refer to pinctrl-bindings.txt
+and .
+
+Each pin controlled by this pin controller belong to one of three types:
+Standard, I2C, and HDMI. Each type accepts a different set of pin config
+properties. A list of pins and their types is provided below.
+
+Required Properties (applicable to all pins):
+
+- pins:Multiple strings. Specifies the name(s) of one or more
pins to
+ be configured by this node.
+
+Optional Properties (for standard pins):
+
+- function:String. Specifies the pin mux selection. Values
+ must be one of: "alt1", "alt2", "alt3", "alt4"
+- input-schmitt-enable:No arguments. Enable schmitt-trigger
mode.
+- input-schmitt-disable: No arguments. Disable schmitt-trigger mode.
+- bias-pull-up:No arguments. Pull up on pin.
+- bias-pull-down: No arguments. Pull down on pin.
+- bias-disable:No arguments. Disable pin bias.
+- slew-rate: Integer. Meaning depends on configured pin mux:
+ *_SCL or *_SDA:
+ 0: Standard(100kbps)& Fast(400kbps) mode
+ 1: Highspeed (3.4Mbps) mode
+ IC_DM or IC_DP:
+ 0: normal slew rate
+ 1: fast slew rate
+ Otherwise:
+ 0: fast slew rate
+ 1: normal slew rate
+- input-enable:No arguements. Enable input (does not
affect
+ output.)
+- input-disable: No arguements. Disable input (does not affect
+ output.)
+- drive-strength: Integer. Drive strength in mA. Valid values are
+ 2, 4, 6, 8, 10, 12, 14, 16 mA.
+
+Optional Properties (for I2C pins):
+
+- function:String. Specifies the pin mux selection. Values
+ must be one of: "alt1", "alt2", "alt3", "alt4"
+- bias-pull-up:Integer. Pull up strength in Ohm. There
are 3
+ pull-up resisitors (1.2k, 1.8k, 2.7k) available
+ in parallel for I2C pins, so the valid values
+
Re: [PATCH v3 3/6] pinctrl: Make PINCTRL selectable by defconfig/menuconfig
On 13-12-20 12:58 PM, Arnd Bergmann wrote: On Friday 20 December 2013, Linus Walleij wrote: On Tue, Dec 17, 2013 at 1:18 AM, Bjorn Andersson wrote: No matter how we build the individual pinctrl drivers we will always need the pinctrl framework in a multi-soc zImage; so I can't see that we gain anything from being able to compile PINCTRL as a module. I discussed this matter with Christian on IRC and I believe we could basically do "select PINCTRL" on ARCH_MULTIPLATFORM as the vast majority of multiplatforms appear to be using this anyway, this would make the submenu for pin control pop up in menuconfig for this, and make it possible to move different subdrivers to modules if desired. MULTIPLATFORM does not seem to be about saving footprint bytes on a very fine-granular level anyway, more about doing the module loading/unloading approach to footprint. Let's review the list of platforms that don't select PINCTRL. There are some platforms that are indeed sensitive about memory footprint, and I promised people that converting to multiplatform won't cause a significant increase in kernel binary size as long as no other platforms are enabled. Arnd Ok, for this driver, I'll just select PINCTRL under the ARCH_BCM_MOBILE. We can move this to ARCH_MULTIPLATFORM once we're sure this is okay for other platforms. Regards, Sherman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 0/6] Add Broadcom Capri pinctrl driver
The following patches adds a pinctrl driver for Broadcom Capri (BCM281xx) SoCs. The first patch, adding the void * to pinctrl_pin_desc, has been previously discussed with LinusW. See this thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/165880.html --- v4: - removed patch to add new properties to generic pinconfig (merged) - Updated bias-pull-up property to accept R value in Ohms instead of an enum - move PINCTRL_CAPRI to defconfig - Use regmap MMIO v3: Re-worked driver to be based on generic pinconfig, addressed review comments and other supporting changes: - moved config selection from Kconfig to defconfig - added slew-rate, input enable, input disable properties for generic pinconfig - added a description for PINCTRL config v2: Use hyphens instead of underscore in DT property names. Sherman Yin (6): pinctrl: Add void * to pinctrl_pin_desc pinctrl: Adds slew-rate, input-enable/disable pinctrl: Make PINCTRL selectable by defconfig/menuconfig pinctrl: Add pinctrl binding for Broadcom Capri SoCs ARM: pinctrl: Add Broadcom Capri pinctrl driver pinctrl: Enable pinctrl for Broadcom Capri SoCs .../bindings/pinctrl/brcm,capri-pinctrl.txt| 429 ++ .../bindings/pinctrl/pinctrl-bindings.txt |3 + arch/arm/boot/dts/bcm11351.dtsi|4 + arch/arm/configs/bcm_defconfig |5 + drivers/pinctrl/Kconfig| 13 +- drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinconf-generic.c |4 + drivers/pinctrl/pinctrl-capri.c| 1408 include/linux/pinctrl/pinconf-generic.h|4 + include/linux/pinctrl/pinctrl.h|2 + 10 files changed, 1872 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-capri.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken initrd compression settings in 3.13
On Fri, Dec 20, 2013 at 5:39 PM, Andrew Morton wrote: > On Fri, 20 Dec 2013 16:41:43 -0800 Linus Torvalds > wrote: >> >> (a) most sane people don't even have lz4 _installed_, so dracut won't >> actually succeed >> >> (b) there's no way to select the compression level (unlike the >> INITRAMFS_COMPRESSION thing that actually has a choice) >> >> (c) even if you *do* have lz4, it doesn't actually work, because >> while that causes the new F20 dracut to compress the initramfs with >> lz4, the end result is completely broken, because the F20 "lsinitrd" >> scripts don't understand the end result, so now the whole kernel >> install fails. >> >> (a) and (b) are very much kernel bugs. > > Jeff sent the below this morning. Will that fix (a)? Yes, it fixes (a), at least to some degree, in that at least defaulting to bzip2 is a lot more sane than defaulting to lz4. I suspect most everybody has bzip2 installed. And at least on my current F20 install, it looks like lsinitrd understands to use zcat, bzcat or xzcat on the resulting initrd image (and bzcat does that bzip2 decoding). So I think Jeff's patch at least fixes the symptoms. That said, I think it does nothing *but* fix the symptoms, and we're actually still better off with the 3.12 behavior which was to never set INITRD_COMPRESS at all. Because quite frankly, there's currently no way for the kernel to know what the right compressor is. bz2 may well work, but can you guarantee it? I certainly can't.. Now, if we asked the user, that would be a different thing. But right now we very much don't ask the user, and we just pick one at random. We're better off not picking a compression method at all, at which point the distro "installkernel" will do whatever the distro does. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 1/4] pinctrl: Add void * to pinctrl_pin_desc
drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.
Signed-off-by: Sherman Yin
Reviewed-by: Christian Daudt
Reviewed-by: Matt Porter
---
v4: no change
v3: no change
v2: no change
---
include/linux/pinctrl/pinctrl.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
index fefb886..cc8e1af 100644
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -32,10 +32,12 @@ struct device_node;
* pins, pads or other muxable units in this struct
* @number: unique pin number from the global pin number space
* @name: a name for this pin
+ * @drv_data: driver-defined per-pin data. pinctrl core does not touch this
*/
struct pinctrl_pin_desc {
unsigned number;
const char *name;
+ void *drv_data;
};
/* Convenience macro to define a single named or anonymous pin descriptor */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs. Signed-off-by: Sherman Yin Reviewed-by: Christian Daudt Reviewed-by: Matt Porter --- v4: - PINCTRL selected in Kconfig, PINCTRL_CAPRI selected in bcm_defconfig - make use of regmap - change CAPRI_PIN_UPDATE from macro to inline function. - Handle pull-up strength arg in Ohm instead of enum v3: Re-work driver to be based on generic pin config. Moved config selection from Kconfig to bcm_defconfig. v2: Use hyphens instead of underscore in DT property names. --- arch/arm/configs/bcm_defconfig |1 + arch/arm/mach-bcm/Kconfig |1 + drivers/pinctrl/Kconfig | 12 + drivers/pinctrl/Makefile|1 + drivers/pinctrl/pinctrl-capri.c | 1454 +++ 5 files changed, 1469 insertions(+) create mode 100644 drivers/pinctrl/pinctrl-capri.c diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig index 287ac1d..bede511 100644 --- a/arch/arm/configs/bcm_defconfig +++ b/arch/arm/configs/bcm_defconfig @@ -126,3 +126,4 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_XZ_DEC=y CONFIG_AVERAGE=y +CONFIG_PINCTRL_CAPRI=y diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 9fe6d88..b1aa6a9 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -25,6 +25,7 @@ config ARCH_BCM_MOBILE select TICK_ONESHOT select CACHE_L2X0 select HAVE_ARM_ARCH_TIMER + select PINCTRL help This enables support for systems based on Broadcom mobile SoCs. It currently supports the 'BCM281XX' family, which includes diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index 33f9dc1..a9f6405 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -104,6 +104,18 @@ config PINCTRL_BCM2835 select PINMUX select PINCONF +config PINCTRL_CAPRI + bool "Broadcom Capri pinctrl driver" + select PINMUX + select PINCONF + select GENERIC_PINCONF + select REGMAP_MMIO + help + Say Y here to support Broadcom Capri pinctrl driver, which is used for + the BCM281xx SoC family, including BCM11130, BCM11140, BCM11351, + BCM28145, and BCM28155 SoCs. This driver requires the pinctrl + framework. GPIO is provided by a separate GPIO driver. + config PINCTRL_IMX bool select PINMUX diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index 4f7be29..86cac40 100644 --- a/drivers/pinctrl/Makefile +++ b/drivers/pinctrl/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_PINCTRL_BF60x) += pinctrl-adi2-bf60x.o obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o obj-$(CONFIG_PINCTRL_BAYTRAIL) += pinctrl-baytrail.o +obj-$(CONFIG_PINCTRL_CAPRI)+= pinctrl-capri.o obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx.o obj-$(CONFIG_PINCTRL_IMX1_CORE)+= pinctrl-imx1-core.o obj-$(CONFIG_PINCTRL_IMX27)+= pinctrl-imx27.o diff --git a/drivers/pinctrl/pinctrl-capri.c b/drivers/pinctrl/pinctrl-capri.c new file mode 100644 index 000..4669c53 --- /dev/null +++ b/drivers/pinctrl/pinctrl-capri.c @@ -0,0 +1,1454 @@ +/* + * Copyright (C) 2013 Broadcom Corporation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "core.h" +#include "pinctrl-utils.h" + +/* Capri Pin Control Registers Definitions */ + +/* Function Select bits are the same for all pin control registers */ +#define CAPRI_PIN_REG_F_SEL_MASK 0x0700 +#define CAPRI_PIN_REG_F_SEL_SHIFT 8 + +/* Standard pin register */ +#define CAPRI_STD_PIN_REG_DRV_STR_MASK 0x0007 +#define CAPRI_STD_PIN_REG_DRV_STR_SHIFT0 +#define CAPRI_STD_PIN_REG_INPUT_DIS_MASK 0x0008 +#define CAPRI_STD_PIN_REG_INPUT_DIS_SHIFT 3 +#define CAPRI_STD_PIN_REG_SLEW_MASK0x0010 +#define CAPRI_STD_PIN_REG_SLEW_SHIFT 4 +#define CAPRI_STD_PIN_REG_PULL_UP_MASK 0x0020 +#define CAPRI_STD_PIN_REG_PULL_UP_SHIFT5 +#define CAPRI_STD_PIN_REG_PULL_DN_MASK 0x0040 +#define CAPRI_STD_PIN_REG_PULL_DN_SHIFT6 +#define CAPRI_STD_PIN_REG_HYST_MASK0x0080 +#define CAPRI_STD_PIN_REG_HYST_SHIFT 7 + +/* I2C pin register */ +#define CAPRI_I2C_PIN_REG_INPUT_DIS_MASK 0x0004 +#define CAPRI_I2C_PIN_REG_INPUT_DIS_SHIFT 2 +#define CAPRI_I2C_PIN_REG_SLEW_MASK0x0008 +#define
[PATCH -next] mfd: twl6040: fix sparse non static symbol warning
From: Wei Yongjun
Fixes the following sparse warning:
drivers/mfd/twl6040.c:89:20: warning:
symbol 'twl6040_patch' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/mfd/twl6040.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 51b6df1..75316fb 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -86,7 +86,7 @@ static struct reg_default twl6040_defaults[] = {
{ 0x2E, 0x00 }, /* REG_STATUS (ro) */
};
-struct reg_default twl6040_patch[] = {
+static struct reg_default twl6040_patch[] = {
/* Select I2C bus access to dual access registers */
{ TWL6040_REG_ACCCTL, 0x09 },
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 4/4] pinctrl: Enable pinctrl for Broadcom Capri SoCs
Enable pinctrl for Broadcom Capri (BCM281xx) SoCs.
Signed-off-by: Sherman Yin
Reviewed-by: Christian Daudt
Reviewed-by: Matt Porter
---
v4: no change
v3: No change.
v2: Use hyphens instead of underscore in DT property names.
---
arch/arm/boot/dts/bcm11351.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index b0c0610..dd8e878 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -142,4 +142,8 @@
status = "disabled";
};
+ pinctrl@35004800 {
+ compatible = "brcm,capri-pinctrl";
+ reg = <0x35004800 0x430>;
+ };
};
--
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 v2] fuse: Fix IOC_[GS]ET{FLAGS,VERSION} argument size brokenness.
To be honest, FS_IOC_SETVERSION isn't used by many/any users, so it might be
better to avoid doing anything with that for now.
In the past we even talked about adding a deprecation warning for that ioctl
since it adds complexity for little value.
Cheers, Andreas
> On Dec 20, 2013, at 16:35, "Darrick J. Wong" wrote:
>
> The IOC_[GS]ETFLAGS and IOC_[GS]ETVERSION ioctls, despite being
> defined to take a "long" parameter, actually take "int" parameters.
> FUSE unfortunately assumed that the ioctl definitions never lie, and
> transfers a long's worth of data in and out of userspace, which causes
> stack smashing in chattr, and other bugs elsewhere.
>
> So, special-case this in FUSE so that we don't crash userland.
>
> v2: Do the same for the IOC_[GS]ETVERSION ioctls, as Richard Hansen
>points out.
>
> Signed-off-by: Darrick J. Wong
> ---
> fs/fuse/file.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 7e70506..f8766ab 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -2385,6 +2385,22 @@ long fuse_do_ioctl(struct file *file, unsigned int
> cmd, unsigned long arg,
>iov->iov_base = (void __user *)arg;
>iov->iov_len = _IOC_SIZE(cmd);
>
> +/*
> + * The IOC_[GS]ETFLAGS and IOC_[GS]ETVERSION ioctls take int
> + * parameters even though the ioctl definition specifies long.
> + * Userland has been expecting int for ages (and chattr
> + * segfaults on FUSE filesystems), so special case that here.
> + * The IOC32 variants were declared with int, so they don't
> + * need this correction.
> + */
> +switch (cmd) {
> +case FS_IOC_GETFLAGS:
> +case FS_IOC_SETFLAGS:
> +case FS_IOC_GETVERSION:
> +case FS_IOC_SETVERSION:
> +iov->iov_len = sizeof(int);
> +}
> +
>if (_IOC_DIR(cmd) & _IOC_WRITE) {
>in_iov = iov;
>in_iovs = 1;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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] drivers: target: target_core_mod: use div64_u64_rem() instead of operator '%' for u64
In kernel, need use div64_u64_rem() instead of operator '%' for u64, or
can not pass compiling (with allmodconfig under metag):
MODPOST 2909 modules
ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
Also need u64 type cast for u32 variable multiply u32 variable, or will
cause type overflow issue.
Signed-off-by: Chen Gang
---
drivers/target/target_core_alua.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/target/target_core_alua.c
b/drivers/target/target_core_alua.c
index dc0d399..ff2aadc 100644
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -489,7 +489,8 @@ static inline int core_alua_state_lba_dependent(
u64 first_lba = map->lba_map_first_lba;
if (segment_mult) {
- start_lba = lba % (segment_size * segment_mult);
+ u64 tmp = (u64)segment_size * segment_mult;
+ div64_u64_rem(lba, tmp, _lba);
last_lba = first_lba + segment_size - 1;
if (start_lba >= first_lba &&
start_lba <= last_lba) {
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re : Re: [PATCH] Squashfs: add asynchronous read support
> Please don't break thread. > You should reply to my mail instead of your original post. Sorry, It seems to be my mailer issue. I'm trying to fix it. > It's a result which isn't what I want to know. > What I wnat to know is why upper layer issues more I/O per second. > For example, you read 32K so MM layer will prepare 8 pages to read in but > at issuing at a first page, squashfs make 32 pages and fill the page cache > if we assume you use 128K compression so MM layer's already prepared 7 > page > would be freed without further I/O and do_generic_file_read will wait for > completion by lock_page without further I/O queueing. It's not suprising. > One of page freed is a READA marked page so readahead couldn't work. > If readahead works, it would be just by luck. Actually, by simulation > 64K dd, I found readahead logic would be triggered but it's just by luck > and it's not intended, I think. MM layer's readahead pages would not be freed immediately. Squashfs can use them by grab_cache_page_nowait and READA marked page is available. Intentional or not, readahead works pretty well. I checked in experiment. > If first issued I/O complete, squashfs decompress the I/O with 128K pages > so all 4 iteration(128K/32K) would be hit in page cache. > If all 128K hit in page cache, mm layer start to issue next I/O and > repeat above logic until you ends up reading all file size. > So my opition is that upper layer wouldn't issue more I/O logically. > If it worked, it's not what we expect but side-effect. > > That's why I'd like to know what's your thought for increasing IOPS. > Please, could you say your thought why IOPS increased, not a result > on low level driver? It is because readahead can works asynchronously in background. Suppose that you read a large file by 128k partially and contiguously like "dd bs=128k". Two IOs can be issued per 128k reading, First IO is for intended pages, second IO is for readahead. If first IO hit in cache thank to previous readahead, no wait for IO completion is needed, because intended page is up-to-date already. But, current squashfs waits for second IO's completion unnecessarily. That is one of reason that we should move page's up-to-date to the asynchronous area like my patch. > Anyway, in my opinion, we should take care of MM layer's readahead for > enhance sequential I/O. For it, we should use buffer pages passed by MM > instead of freeing them and allocating new pages in squashfs. > IMHO, it would be better to implement squashfs_readpages but my insight > is very weak so I guess Phillip will give more good idea/insight about > the issue. That's a good point. Also, I think my patch is another way which can be implemented without significant impact on current implementation and I wait for Phillip's comment. Thanks Chanho -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] rtc-efi: register rtc-efi device when EFI enabled
On 12/20/2013 05:24 PM, joeyli wrote: > 於 五，2013-12-20 於 13:04 -0800，H. Peter Anvin 提到： >> >> Actually, it doesn't have to reprogram the clock ... it just needs to >> know if another OS has already done so. All Linux needs to do is to be >> able to derive UTC from whatever the RTC is set to and to be able to >> keep it consistent. >> > > It's dependent on a right boot initial priority of distribution. -ENOPARSE > Here have a discussion of adjusting system clock by TZ (from ACPI or > UEFI): > Discussion on BIOS/CMOS/UEFI clock in local time > http://www.spinics.net/lists/util-linux-ng/msg07639.html > > and, > from Ted Ts'o in the mail thread > https://lkml.org/lkml/2008/1/8/195 > > If kernel use the TZ field from ACPI TAD or EFI to adjust system > clock when booting, then it can avoid buggy distributions adjust > system clock AFTER e2fsck is run. > > Using ACPI TAD should after DSDT parsing in subsystem initial stage, > so I choice EFI time services before we can move DSDT parser to > start_kernel(). > Yes, of course. That is irrelevant to needing to reprogram the clock, though. My argument is very simple: if we have to rely on EFI, we can get the offset in the boot stub before ExitBootServices(), and then simply never change it. That way we still pick up if another operating system has changed it, and it will still reflect the proper UTC time. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/4] sb_edac: Claim a different PCI device
sb_edac controls a large number of different PCI functions. Rather
than registering as a normal PCI driver for all of them, it
registers for just one so that it gets probed and, at probe time, it
looks for all the others.
Coincidentally, the device it registers for also contains the SMBUS
registers, so the PCI core will refuse to probe both sb_edac and an
iMC SMBUS driver. The drivers don't actually conflict, so just
change sb_edac's device table to probe a different device.
An alternative fix would be to merge the two drivers, but sb_edac
will also refuse to load on non-ECC systems, whereas the i2c_imc
is still useful without ECC.
The only user-visible change should be that sb_edac appears to bind
a different device.
Cc: Mauro Carvalho Chehab
Cc: Rui Wang
Signed-off-by: Andy Lutomirski
---
drivers/edac/sb_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 06426f6..26e8ea9 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -432,7 +432,7 @@ static const struct pci_id_table
pci_dev_descr_ibridge_table[] = {
* pci_device_id table for which devices we are looking for
*/
static DEFINE_PCI_DEVICE_TABLE(sbridge_pci_tbl) = {
- {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
{0,}/* 0 terminated list. */
};
--
1.8.3.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 v6 4/4] i2c, i2c_imc: Add DIMM bus code
Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
contains DIMMs. This will probe (and autoload modules!) for useful
SMBUS devices that live on DIMMs. i2c_imc calls it.
As more SMBUS-addressable DIMM components become supported, this
code can be extended to probe for them.
Signed-off-by: Andy Lutomirski
---
drivers/i2c/busses/Kconfig| 4 ++
drivers/i2c/busses/Makefile | 4 ++
drivers/i2c/busses/dimm-bus.c | 97 +++
drivers/i2c/busses/i2c-imc.c | 3 ++
include/linux/i2c/dimm-bus.h | 24 +++
5 files changed, 132 insertions(+)
create mode 100644 drivers/i2c/busses/dimm-bus.c
create mode 100644 include/linux/i2c/dimm-bus.h
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 0fe76cc..8b46ad8 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -135,6 +135,10 @@ config I2C_ISMT
This driver can also be built as a module. If so, the module will be
called i2c-ismt.
+config I2C_DIMM_BUS
+ tristate
+ default n
+
config I2C_IMC
tristate "Intel iMC (LGA 2011) SMBus Controller"
depends on PCI && X86
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index ea2a6a5..91827cb 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -25,6 +25,10 @@ obj-$(CONFIG_I2C_SIS96X) += i2c-sis96x.o
obj-$(CONFIG_I2C_VIA) += i2c-via.o
obj-$(CONFIG_I2C_VIAPRO) += i2c-viapro.o
+# DIMM busses
+obj-$(CONFIG_I2C_DIMM_BUS) += dimm-bus.o
+obj-$(CONFIG_I2C_IMC) += i2c-imc.o
+
# Mac SMBus host controller drivers
obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
obj-$(CONFIG_I2C_POWERMAC) += i2c-powermac.o
diff --git a/drivers/i2c/busses/dimm-bus.c b/drivers/i2c/busses/dimm-bus.c
new file mode 100644
index 000..0968428
--- /dev/null
+++ b/drivers/i2c/busses/dimm-bus.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2013 Andrew Lutomirski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+static bool probe_addr(struct i2c_adapter *adapter, int addr)
+{
+ /*
+* So far, all known devices that live on DIMMs can be safely
+* and reliably detected by trying to read a byte at address
+* zero. (The exception is the SPD write protection control,
+* which can't be probed and requires special hardware and/or
+* quick writes to access, and has no driver.)
+*/
+ union i2c_smbus_data dummy;
+ return i2c_smbus_xfer(adapter, addr, 0, I2C_SMBUS_READ, 0,
+ I2C_SMBUS_BYTE_DATA, ) >= 0;
+}
+
+/**
+ * i2c_scan_dimm_bus() - Scans an SMBUS segment known to contain DIMMs
+ * @adapter: The SMBUS adapter to scan
+ *
+ * This function tells the DIMM-bus code that the adapter is known to
+ * contain DIMMs. i2c_scan_dimm_bus will probe for devices known to
+ * live on DIMMs.
+ *
+ * Do NOT call this function on general-purpose system SMBUS segments
+ * unless you know that the only things on the bus are DIMMs.
+ * Otherwise is it very likely to mis-identify other things on the
+ * bus.
+ *
+ * Callers are advised not to set adapter->class = I2C_CLASS_SPD.
+ */
+void i2c_scan_dimm_bus(struct i2c_adapter *adapter)
+{
+ struct i2c_board_info info = {};
+ int slot;
+
+ /*
+* We probe with "read byte data". If any DIMM SMBUS driver can't
+* support that access type, this function should be updated.
+*/
+ if (WARN_ON(!i2c_check_functionality(adapter,
+ I2C_FUNC_SMBUS_READ_BYTE_DATA)))
+ return;
+
+ /*
+* Addresses on DIMMs use the three low bits to identify the slot
+* and the four high bits to identify the device type. Known
+* devices are:
+*
+* - 0x50 - 0x57: SPD (Serial Presence Detect) EEPROM
+* - 0x30 - 0x37: SPD WP control -- not worth trying to probe
+* - 0x18 - 0x1f: TSOD (Temperature Sensor on DIMM)
+*
+* There may be more some day.
+*/
+ for (slot = 0; slot < 8; slot++) {
+ /* If there's no SPD, then assume there's no DIMM here. */
+ if (!probe_addr(adapter, 0x50 | slot))
+ continue;
+
+ strcpy(info.type, "spd");
+
[PATCH v6 0/4] iMC SMBUS driver and DIMM bus probing
Intel LGA2011 machines have dedicated SMBUS controllers for DIMM sockets. Because they're dedicated, they can be safely and accurately probed, since all devices on them are known to be attached to DIMMs. The devices found are: - SPD EEPROMs - TSODs (Temperature Sensor on DIMMs) - Other interesting things, with drivers hopefully to follow... This patch series adds a simple generic layer for probing for DIMMs over SMBUS and an i2c bus driver for the iMC controller found on Intel LGA2011 chips. It now uses only modern infrastructure -- new-style I2C probing and the at24 (instead of eeprom) driver. I've tested this on a Core i7 Extreme and on a Xeon E5 server. I haven't tested it on an LGA2011 Ivy Bridge box, since I don't have one. Patches 1-3 are useful even without patch 4. I'm still hoping for feedback on patch 4. Changes from v5: - Rebase to a6ddeee32dad (i.e. -linus from today) and re-test Changes from v4: - Added the sb_edac changes -- i2c_imc and sb_edac can now coexist - Added some paranoid race detection. - The driver now confirms its ability to claim software control of the SMBUS master. This prevents unpleasant problems on systems that enable CLTT (closed loop thermal throttling). - Reordered the patches so that the DIMM bus code is last. Changes from v3: - Dropped redundant "tsod" driver - Dropped eeprom modalias - Switched to probing for the "eeprom" and "jc42" Andy Lutomirski (4): Move Intel SNB device ids from sb_edac to pci_ids.h sb_edac: Claim a different PCI device i2c_imc: New driver for Intel's iMC, found on LGA2011 chips i2c, i2c_imc: Add DIMM bus code drivers/edac/sb_edac.c| 32 +-- drivers/i2c/busses/Kconfig| 19 ++ drivers/i2c/busses/Makefile | 5 + drivers/i2c/busses/dimm-bus.c | 97 drivers/i2c/busses/i2c-imc.c | 562 ++ include/linux/i2c/dimm-bus.h | 24 ++ include/linux/pci_ids.h | 15 ++ 7 files changed, 723 insertions(+), 31 deletions(-) create mode 100644 drivers/i2c/busses/dimm-bus.c create mode 100644 drivers/i2c/busses/i2c-imc.c create mode 100644 include/linux/i2c/dimm-bus.h -- 1.8.3.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 v6 1/4] Move Intel SNB device ids from sb_edac to pci_ids.h
The i2c_imc driver will use two of them, and moving only part of
the list seems messier.
Cc: Mauro Carvalho Chehab
Cc: Rui Wang
Signed-off-by: Andy Lutomirski
---
drivers/edac/sb_edac.c | 30 --
include/linux/pci_ids.h | 15 +++
2 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index d7f1b57..06426f6 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -52,36 +52,6 @@ static int probed;
#define GET_BITFIELD(v, lo, hi)\
(((v) & GENMASK_ULL(hi, lo)) >> (lo))
-/*
- * sbridge Memory Controller Registers
- */
-
-/*
- * FIXME: For now, let's order by device function, as it makes
- * easier for driver's development process. This table should be
- * moved to pci_id.h when submitted upstream
- */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD0 0x3cf4 /* 12.6 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD1 0x3cf6 /* 12.7 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_BR 0x3cf5 /* 13.6 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA00x3ca0 /* 14.0 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA 0x3ca8 /* 15.0 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_RAS0x3c71 /* 15.1 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0 0x3caa /* 15.2 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD1 0x3cab /* 15.3 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD2 0x3cac /* 15.4 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD3 0x3cad /* 15.5 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO 0x3cb8 /* 17.0 */
-
- /*
-* Currently, unused, but will be needed in the future
-* implementations, as they hold the error counters
-*/
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR0 0x3c72 /* 16.2 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR1 0x3c73 /* 16.3 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR2 0x3c76 /* 16.6 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR3 0x3c77 /* 16.7 */
-
/* Devices 12 Function 6, Offsets 0x80 to 0xcc */
static const u32 sbridge_dram_rule[] = {
0x80, 0x88, 0x90, 0x98, 0xa0,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 97fbecd..6dc4b18 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2812,7 +2812,22 @@
#define PCI_DEVICE_ID_INTEL_UNC_R2PCIE 0x3c43
#define PCI_DEVICE_ID_INTEL_UNC_R3QPI0 0x3c44
#define PCI_DEVICE_ID_INTEL_UNC_R3QPI1 0x3c45
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_RAS0x3c71 /* 15.1 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR0 0x3c72 /* 16.2 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR1 0x3c73 /* 16.3 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR2 0x3c76 /* 16.6 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR3 0x3c77 /* 16.7 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA00x3ca0 /* 14.0 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA 0x3ca8 /* 15.0 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0 0x3caa /* 15.2 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD1 0x3cab /* 15.3 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD2 0x3cac /* 15.4 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD3 0x3cad /* 15.5 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO 0x3cb8 /* 17.0 */
#define PCI_DEVICE_ID_INTEL_JAKETOWN_UBOX 0x3ce0
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD0 0x3cf4 /* 12.6 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_BR 0x3cf5 /* 13.6 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD1 0x3cf6 /* 12.7 */
#define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
#define PCI_DEVICE_ID_INTEL_5100_160x65f0
#define PCI_DEVICE_ID_INTEL_5100_190x65f3
--
1.8.3.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 v6 3/4] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips
Sandy Bridge Xeon and Extreme chips have integrated memory controllers with (rather limited) onboard SMBUS masters. This driver gives access to the bus. Signed-off-by: Andy Lutomirski --- drivers/i2c/busses/Kconfig | 15 ++ drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-imc.c | 559 +++ 3 files changed, 575 insertions(+) create mode 100644 drivers/i2c/busses/i2c-imc.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 3b26129..0fe76cc 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -135,6 +135,21 @@ config I2C_ISMT This driver can also be built as a module. If so, the module will be called i2c-ismt. +config I2C_IMC + tristate "Intel iMC (LGA 2011) SMBus Controller" + depends on PCI && X86 + select I2C_DIMM_BUS + help + If you say yes to this option, support will be included for the Intel + Integrated Memory Controller SMBus host controller interface. This + controller is found on LGA 2011 Xeons and Core i7 Extremes. + + It is possibly, although unlikely, that the use of this driver will + interfere with your platform's RAM thermal management. + + This driver can also be built as a module. If so, the module will be + called i2c-imc. + config I2C_PIIX4 tristate "Intel PIIX4 and compatible (ATI/AMD/Serverworks/Broadcom/SMSC)" depends on PCI diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index c73eb0e..ea2a6a5 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o obj-$(CONFIG_I2C_I801) += i2c-i801.o obj-$(CONFIG_I2C_ISCH) += i2c-isch.o obj-$(CONFIG_I2C_ISMT) += i2c-ismt.o +obj-$(CONFIG_I2C_IMC) += i2c-imc.o obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o obj-$(CONFIG_I2C_NFORCE2_S4985)+= i2c-nforce2-s4985.o obj-$(CONFIG_I2C_PIIX4)+= i2c-piix4.o diff --git a/drivers/i2c/busses/i2c-imc.c b/drivers/i2c/busses/i2c-imc.c new file mode 100644 index 000..c846077 --- /dev/null +++ b/drivers/i2c/busses/i2c-imc.c @@ -0,0 +1,559 @@ +/* + * Copyright (c) 2013 Andrew Lutomirski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include +#include +#include +#include +#include + +/* + * The datasheet can be found here, for example: + * http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-1600-2600-vol-2-datasheet.pdf + * + * There seem to be quite a few bugs or spec errors, though: + * + * - A successful transaction sets WOD and RDO. + * + * - The docs for TSOD_POLL_EN make no sense (see imc_channel_claim). + * + * - Erratum BT109, which says: + * + * The processor may not complete SMBus (System Management Bus) + * transactions targeting the TSOD (Temperature Sensor On DIMM) + * when Package C-States are enabled. Due to this erratum, if the + * processor transitions into a Package C-State while an SMBus + * transaction with the TSOD is in process, the processor will + * suspend receipt of the transaction. The transaction completes + * while the processor is in a Package C-State. Upon exiting + * Package C-State, the processor will attempt to resume the + * SMBus transaction, detect a protocol violation, and log an + * error. + * + * The description notwithstanding, I've seen difficult-to-reproduce + * issues when the system goes completely idle (so package C-states can + * be entered) while software-initiated SMBUS transactions are in + * progress. + */ + +/* Register offsets (in PCI configuration space) */ +#define SMBSTAT(i) (0x180 + 0x10*i) +#define SMBCMD(i) (0x184 + 0x10*i) +#define SMBCNTL(i) (0x188 + 0x10*i) +#define SMB_TSOD_POLL_RATE_CNTR(i) (0x18C + 0x10*i) +#define SMB_TSOD_POLL_RATE (0x1A8) + +/* SMBSTAT fields */ +#define SMBSTAT_RDO(1U << 31) /* Read Data Valid */ +#define SMBSTAT_WOD(1U << 30) /* Write Operation Done */ +#define SMBSTAT_SBE(1U << 29) /* SMBus Error */ +#define SMBSTAT_SMB_BUSY (1U << 28) /* SMBus Busy State */ +/* 26:24 is the last automatically polled TSOD
Re: Broken initrd compression settings in 3.13
On Fri, 20 Dec 2013 16:41:43 -0800 Linus Torvalds
wrote:
> So commit 1bf49dd4be0b ("./Makefile: export initial ramdisk
> compression config option") seems to be totally broken.
>
> And I'm not saying that because Jan fixed a make-3.80 incompatibility
> in commit 7ac181568342 ("fix build with make 3.80")
>
> I'm saying that because it sets and exports the INITRD_COMPRESS
> environment variable completely incorrectly, as far as I can tell.
>
> And it looks like nobody noticed, because apparently dracut didn't use
> to care about that INITRD_COMPRESS environment variable at all. But as
> of a F20 update yesterday, apparently dracut actually does care, and
> as a result nothing actually works.
>
> That setting is f*cking moronic. It sets INITRD_COMPRESS to 'lz4' if
> RD_LZ4 is set. But RD_LZ4 is *always* set (unless you go into some
> expert settings), so basically what that commit does is to always set
> INITRD_COMPRESS to lz4.
>
> Why is that wrong?
>
> It's wrong because
>
> (a) most sane people don't even have lz4 _installed_, so dracut won't
> actually succeed
>
> (b) there's no way to select the compression level (unlike the
> INITRAMFS_COMPRESSION thing that actually has a choice)
>
> (c) even if you *do* have lz4, it doesn't actually work, because
> while that causes the new F20 dracut to compress the initramfs with
> lz4, the end result is completely broken, because the F20 "lsinitrd"
> scripts don't understand the end result, so now the whole kernel
> install fails.
>
> Now, it could be argued that this is a F20 bug, and the fact that F20
> has a dracut that can generate a lz4 initrd, but has other tools that
> then cannot handle it is arguably indeed a buglet in F20. So the (c)
> part is arguably a F20 problem.
>
> HOWEVER.
>
> (a) and (b) are very much kernel bugs.
>
> I'm going to remove that export of INITRD_COMPRESS, since right now
> that value is broken and useless. No way does it make sense to
> mindlessly default to a compressor that most people don't have, and
> that doesn't work with most tools.
Jeff sent the below this morning. Will that fix (a)?
From: Jeff Layton
Subject: Makefile: fix order of INITRD_COMPRESS-y assignments
Commit 7ac181568342ec ("fix build with make 3.80") changed how the
Makefile handles the INITRD_COMPRESS-y assignment in order to make it work
properly with older versions of make. Unfortunately, it also changes the
behavior of how that assignment works when multiple CONFIG_RD_* options
are set, such that they are now preferred in the reverse order of the way
they were before.
Reverse the order of assignments to try and preserve the earlier
precedence in this situation.
Signed-off-by: Jeff Layton
Cc: Jan Beulich
Cc: P J P
Signed-off-by: Andrew Morton
---
Makefile |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -puN Makefile~makefile-fix-order-of-initrd_compress-y-assignments Makefile
--- a/Makefile~makefile-fix-order-of-initrd_compress-y-assignments
+++ a/Makefile
@@ -733,11 +733,11 @@ export mod_strip_cmd
# This shall be used by the dracut(8) tool while creating an initramfs image.
#
INITRD_COMPRESS-y := gzip
-INITRD_COMPRESS-$(CONFIG_RD_BZIP2) := bzip2
-INITRD_COMPRESS-$(CONFIG_RD_LZMA) := lzma
-INITRD_COMPRESS-$(CONFIG_RD_XZ):= xz
-INITRD_COMPRESS-$(CONFIG_RD_LZO) := lzo
INITRD_COMPRESS-$(CONFIG_RD_LZ4) := lz4
+INITRD_COMPRESS-$(CONFIG_RD_LZO) := lzo
+INITRD_COMPRESS-$(CONFIG_RD_XZ):= xz
+INITRD_COMPRESS-$(CONFIG_RD_LZMA) := lzma
+INITRD_COMPRESS-$(CONFIG_RD_BZIP2) := bzip2
export INITRD_COMPRESS := $(INITRD_COMPRESS-y)
ifdef CONFIG_MODULE_SIG_ALL
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup
On Thu, 2013-12-19 at 15:14 -0800, Linus Torvalds wrote: > On Thu, Dec 19, 2013 at 10:45 AM, Davidlohr Bueso wrote: > > > > - increment the counter at queue_lock() as we always end up calling > > queue_me() which adds the element to the list. Upon any error, > > queue_unlock() is called for housekeeping, for which we decrement > > to mach the increment done in queue_lock(). > > > > - decrement the counter at __unqueue_me() to reflect when an element is > > removed from the queue for wakeup related purposes. > > I still hate this whole separate counter thing. It seems really annoying. > > If re-ordering things didn't work out, then why can't just the counter > we *already* have in the spinlock itself work as the counter? Your > counter update logic seems to basically match when you take the > spinlock anyway. So the following has passed all testing, just like the atomics variant. Thoughts? Thanks, Davidlohr diff --git a/kernel/futex.c b/kernel/futex.c index fcc6850..c8c7ce5 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -73,19 +73,22 @@ * Basic futex operation and ordering guarantees: * * The waiter reads the futex value in user space and calls - * futex_wait(). This function computes the hash bucket and acquires - * the hash bucket lock. After that it reads the futex user space value - * again and verifies that the data has not changed. If it has not - * changed it enqueues itself into the hash bucket, releases the hash + * futex_wait(). It computes the hash bucket and acquires the hash + * bucket lock. After that it reads the futex user space value again + * and verifies that the data has not changed. If it has not changed + * it enqueues itself into the hash bucket, releases the hash * bucket lock and schedules. * * The waker side modifies the user space value of the futex and calls - * futex_wake(). This functions computes the hash bucket and acquires - * the hash bucket lock. Then it looks for waiters on that futex in the - * hash bucket and wakes them. + * futex_wake(). It computes the hash bucket and acquires the hash + * bucket lock. Then it looks for waiters on that futex in the hash + * bucket and wakes them. * - * Note that the spin_lock serializes waiters and wakers, so that the - * following scenario is avoided: + * In scenarios where wakeups are called and no tasks are blocked on a futex, + * taking the hb spinlock can be avoided and simply return. In order for this + * optimization to work, ordering guarantees must exist so that the waiter + * being added to the list is acknowledged when the list is concurrently being + * checked by the waker, avoiding scenarios like the following: * * CPU 0 CPU 1 * val = *futex; @@ -106,24 +109,50 @@ * This would cause the waiter on CPU 0 to wait forever because it * missed the transition of the user space value from val to newval * and the waker did not find the waiter in the hash bucket queue. - * The spinlock serializes that: + * + * The correct serialization ensures that a waiter either observes + * the changed user space value before blocking or is woken by a + * concurrent waker: * * CPU 0 CPU 1 * val = *futex; * sys_futex(WAIT, futex, val); * futex_wait(futex, val); - * lock(hash_bucket(futex)); - * uval = *futex; - * *futex = newval; - * sys_futex(WAKE, futex); - * futex_wake(futex); - * lock(hash_bucket(futex)); + * + * waiters++; + * mb(); (A) <-- paired with -. + * | + * lock(hash_bucket(futex)); | + * | + * uval = *futex; | + * |*futex = newval; + * |sys_futex(WAKE, futex); + * | futex_wake(futex); + * | + * `---> mb(); (B) * if (uval == val) - * queue(); + * queue(); * unlock(hash_bucket(futex)); - * schedule(); if (!queue_empty()) - * wake_waiters(futex); - * unlock(hash_bucket(futex)); + * schedule(); if (waiters) + * lock(hash_bucket(futex)); + * wake_waiters(futex); + * unlock(hash_bucket(futex)); + * + * Where (A) orders the waiters increment and the futex value read -- this + * is guaranteed by the head counter in the hb spinlock; and where (B) + * orders the write to futex and the waiters read. + * + * This yields the following case (where X:=waiters, Y:=futex): + * + * X = Y = 0 + * + * w[X]=1 w[Y]=1 + * MB MB + *
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
"H. Peter Anvin" writes: > On 12/20/2013 03:11 PM, Eric W. Biederman wrote: >> >> In that case the chrome folks would simply have to use an ELF format >> kernel and not a bzImage. >> > > This is starting to feel like everything is going in the direction of a > massive feature regression. bzImage may be weird (it has definitely > grown organically), but the features that have been added to it have > generally been for a reason, e.g. kernel relocation and so on. Stuff and nonsense. bzImage is just an ugly wrapper around an ELF image. I am just arguing that we expose the clean portable underpinnings and make that work. It absolutely does not make sense to make a solution that only works for x86. ELF is what ever other architecture uses so we absolutely have to make any feature we build work with ELF. At a very basic level for this feature ELF is good enough. bzImage isn't. Given that in the worst case distro's will have to package a second binary of the same kernel in their kernel rpm. I don't know that there is any point in supporting anything else except ELF in the kernel. Given that the package and distribution are going to have to change anyway to include signing a change in file format hardly seems scary. But my point above was really that ELF is sufficient for the use case of doing file based verification base on fd's in addition to the use case of using detached signatures. Which is really a long winded way of saying the argument "But but but my distro only ships a bzImage today" is a horrible techinical argument. I am not fundamentally opposed to supporting other file formats but given that ELF wins on both practical and techincal grounds ELF should be the primary file format for kexec_file_load. We can worry about other file formats once ELF is shown to work. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] rtc-efi: register rtc-efi device when EFI enabled
於 五，2013-12-20 於 13:04 -0800，H. Peter Anvin 提到： > On 12/20/2013 07:14 AM, Matthew Garrett wrote: > > On Fri, 2013-12-20 at 11:37 +0100, Borislav Petkov wrote: > >> On Thu, Dec 19, 2013 at 08:30:48PM -0800, H. Peter Anvin wrote: > >>> On 12/19/2013 08:24 PM, joeyli wrote: > I agreed, but userspace application should not be too often to access > RTC. Maybe only when system boot and set timezone. > >>> > >>> This is, quite frankly, an idiotic argument. > >> > >> TBH, I've been struggling with the question too - and it might even be a > >> stupid question - but what is that absolute need to be able to get the > >> TZ in userspace? Why should I care? > >> > >> Can we get some use cases for stupid people like me please? > > > > Dual-boot environments will tend to have the RTC in local time, not UTC. > > That means that userspace has to reprogram the clock over daylight > > savings changes, and to do that it must know whether another OS has > > already done so. > > > > Actually, it doesn't have to reprogram the clock ... it just needs to > know if another OS has already done so. All Linux needs to do is to be > able to derive UTC from whatever the RTC is set to and to be able to > keep it consistent. > > -hpa > > It's dependent on a right boot initial priority of distribution. Here have a discussion of adjusting system clock by TZ (from ACPI or UEFI): Discussion on BIOS/CMOS/UEFI clock in local time http://www.spinics.net/lists/util-linux-ng/msg07639.html and, from Ted Ts'o in the mail thread https://lkml.org/lkml/2008/1/8/195 If kernel use the TZ field from ACPI TAD or EFI to adjust system clock when booting, then it can avoid buggy distributions adjust system clock AFTER e2fsck is run. Using ACPI TAD should after DSDT parsing in subsystem initial stage, so I choice EFI time services before we can move DSDT parser to start_kernel(). Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] intel-gtt: Read 64bit for gmar_bus_addr
On Fri, Dec 20, 2013 at 4:27 PM, Bjorn Helgaas wrote:
> Why are we reading these BARs directly anyway? These look like
> standard PCI BARs (I810_GMADDR == 0x10 and I915_GMADDR == 0x18), so
> the PCI core should already be reading them correctly, shouldn't it?
> Can't we just use pcibios_resource_to_bus(pci_resource_start())?
>
> It looks like i810_setup(), i830_setup(), and i9xx_setup() have the
> same problem and should also be using pci_resource_start() or
> something similar.
Agreed.
should be sth like:
Index: linux-2.6/drivers/char/agp/intel-gtt.c
===
--- linux-2.6.orig/drivers/char/agp/intel-gtt.c
+++ linux-2.6/drivers/char/agp/intel-gtt.c
@@ -608,9 +608,9 @@ static bool intel_gtt_can_wc(void)
static int intel_gtt_init(void)
{
- u32 gma_addr;
+ struct pci_bus_region r;
u32 gtt_map_size;
- int ret;
+ int ret, idx;
ret = intel_private.driver->setup();
if (ret != 0)
@@ -660,13 +660,14 @@ static int intel_gtt_init(void)
}
if (INTEL_GTT_GEN <= 2)
- pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
- _addr);
+ idx = 0; /* I810_GMADDR */
else
- pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
- _addr);
+ idx = 2; /* I915_GMADDR */
- intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
+ pcibios_resource_to_bus(intel_private.pcidev->bus, ,
+ _private.pcidev->resource[idx]);
+
+ intel_private.gma_bus_addr = r.start;
return 0;
}
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index b8e2014..0250017 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -608,9 +608,9 @@ static bool intel_gtt_can_wc(void)
static int intel_gtt_init(void)
{
- u32 gma_addr;
+ struct pci_bus_region r;
u32 gtt_map_size;
- int ret;
+ int ret, idx;
ret = intel_private.driver->setup();
if (ret != 0)
@@ -660,13 +660,14 @@ static int intel_gtt_init(void)
}
if (INTEL_GTT_GEN <= 2)
- pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
- _addr);
+ idx = 0; /* I810_GMADDR */
else
- pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
- _addr);
+ idx = 2; /* I915_GMADDR */
+
+ pcibios_resource_to_bus(intel_private.pcidev->bus, ,
+_private.pcidev->resource[idx]);
- intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
+ intel_private.gma_bus_addr = r.start;
return 0;
}
[PATCH v2 1/3] x86: intel-mid: sfi_handle_*_dev() should check for pdata error code
When Intel MID finds a match between SFI table from FW and registered
SFI devices, it will execute platform initialization code, acquire
platform data and register platform device to probe the driver.
But if platform initialization code fails, Intel MID will still register
platform device even though it's likely it won't work properly.
This patch handles this error condition in more graceful way.
Since 'NULL' is a valid return value, this patch makes
sfi_handle_*_dev() functions to use IS_ERR() to validate returned pdata.
Then, it prevents sfi_handle_*_dev() to register device in case
intel_mid_sfi_get_pdata() failed to execute.
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/sfi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/platform/intel-mid/sfi.c
b/arch/x86/platform/intel-mid/sfi.c
index 80a52288555c..1d5d20b088fa 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -337,6 +337,8 @@ static void __init sfi_handle_ipc_dev(struct
sfi_device_table_entry *pentry,
pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
pentry->name, pentry->irq);
pdata = intel_mid_sfi_get_pdata(dev, pentry);
+ if (IS_ERR(pdata))
+ return;
pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
@@ -370,6 +372,8 @@ static void __init sfi_handle_spi_dev(struct
sfi_device_table_entry *pentry,
spi_info.chip_select);
pdata = intel_mid_sfi_get_pdata(dev, _info);
+ if (IS_ERR(pdata))
+ return;
spi_info.platform_data = pdata;
if (dev->delay)
@@ -395,6 +399,8 @@ static void __init sfi_handle_i2c_dev(struct
sfi_device_table_entry *pentry,
i2c_info.addr);
pdata = intel_mid_sfi_get_pdata(dev, _info);
i2c_info.platform_data = pdata;
+ if (IS_ERR(pdata))
+ return;
if (dev->delay)
intel_scu_i2c_device_register(pentry->host_num, _info);
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] x86: intel-mid: platform code should return error when failing
All Intel MID platform code are responsible for:
- execute platform initialization code
- return platform data (when there's one)
But currently it's ambiguous the error condition during platform
initialization and the lack of platform data. In both cases platform
code will return NULL.
This patch fixes such situation. From now on NULL is a valid case when
there is no platform data and ERR_PTR() is used for error conditions.
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/device_libs/platform_emc1403.c | 6 --
arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c | 2 +-
arch/x86/platform/intel-mid/device_libs/platform_lis331.c| 6 --
arch/x86/platform/intel-mid/device_libs/platform_max7315.c | 6 +++---
arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c | 4 ++--
arch/x86/platform/intel-mid/device_libs/platform_msic_gpio.c | 2 +-
arch/x86/platform/intel-mid/device_libs/platform_msic_ocd.c | 2 +-
arch/x86/platform/intel-mid/device_libs/platform_pmic_gpio.c | 2 +-
arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c | 6 ++
arch/x86/platform/intel-mid/device_libs/platform_tca6416.c | 6 +++---
10 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
b/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
index 0d942c1d26d5..58933daa606d 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
@@ -22,8 +22,10 @@ static void __init *emc1403_platform_data(void *info)
int intr = get_gpio_by_name("thermal_int");
int intr2nd = get_gpio_by_name("thermal_alert");
- if (intr == -1 || intr2nd == -1)
- return NULL;
+ if (intr < 0)
+ return ERR_PTR(intr);
+ if (intr2nd < 0)
+ return ERR_PTR(intr2nd);
i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
intr2nd_pdata = intr2nd + INTEL_MID_IRQ_OFFSET;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
b/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
index a013a4834bbe..dccae6b0413f 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
@@ -66,7 +66,7 @@ static int __init pb_keys_init(void)
gb[i].gpio = get_gpio_by_name(gb[i].desc);
pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
gb[i].gpio);
- if (gb[i].gpio == -1)
+ if (gb[i].gpio < 0)
continue;
if (i != good)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
b/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
index 15278c11f714..506856c418a6 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
@@ -21,8 +21,10 @@ static void __init *lis331dl_platform_data(void *info)
int intr = get_gpio_by_name("accel_int");
int intr2nd = get_gpio_by_name("accel_2");
- if (intr == -1 || intr2nd == -1)
- return NULL;
+ if (intr < 0)
+ return ERR_PTR(intr);
+ if (intr2nd < 0)
+ return ERR_PTR(intr2nd);
i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
intr2nd_pdata = intr2nd + INTEL_MID_IRQ_OFFSET;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
b/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
index 94ade10024ae..d25ec6d4b606 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
@@ -31,7 +31,7 @@ static void __init *max7315_platform_data(void *info)
if (nr == MAX7315_NUM) {
pr_err("too many max7315s, we only support %d\n",
MAX7315_NUM);
- return NULL;
+ return ERR_PTR(-EINVAL);
}
/* we have several max7315 on the board, we only need load several
* instances of the same pca953x driver to cover them
@@ -48,8 +48,8 @@ static void __init *max7315_platform_data(void *info)
gpio_base = get_gpio_by_name(base_pin_name);
intr = get_gpio_by_name(intr_pin_name);
- if (gpio_base == -1)
- return NULL;
+ if (gpio_base < 0)
+ return ERR_PTR(gpio_base);
max7315->gpio_base = gpio_base;
if (intr != -1) {
i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
b/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
index dd28d63c84fb..c0a8fe7791a0 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
@@ -19,8 +19,8 @@
[PATCH v2 3/3] x86: intel-mid: return proper error code from get_gpio_by_name()
get_gpio_by_name() should return an error code instead of hardcoded -1. Signed-off-by: David Cohen --- arch/x86/platform/intel-mid/sfi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/intel-mid/sfi.c b/arch/x86/platform/intel-mid/sfi.c index 1d5d20b088fa..438306ebed05 100644 --- a/arch/x86/platform/intel-mid/sfi.c +++ b/arch/x86/platform/intel-mid/sfi.c @@ -224,7 +224,7 @@ int get_gpio_by_name(const char *name) if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN)) return pentry->pin_no; } - return -1; + return -EINVAL; } void __init intel_scu_device_register(struct platform_device *pdev) -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] x86: intel-mid: handle platform code error in better way
Hi, These patches are meant to improve how Intel MID detects error in its platform code. Currently it's ambiguous when platform code returns NULL due to error or due to lack of platform data in valid situations. With these patches, errors will be handled by ERR_PTR()/PTR_ERR() macros. Br, David Cohen --- David Cohen (3): x86: intel-mid: sfi_handle_*_dev() should check for pdata error code x86: intel-mid: platform code should return error when failing x86: intel-mid: return proper error code from get_gpio_by_name() arch/x86/platform/intel-mid/device_libs/platform_emc1403.c | 6 -- arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c | 2 +- arch/x86/platform/intel-mid/device_libs/platform_lis331.c| 6 -- arch/x86/platform/intel-mid/device_libs/platform_max7315.c | 6 +++--- arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c | 4 ++-- arch/x86/platform/intel-mid/device_libs/platform_msic_gpio.c | 2 +- arch/x86/platform/intel-mid/device_libs/platform_msic_ocd.c | 2 +- arch/x86/platform/intel-mid/device_libs/platform_pmic_gpio.c | 2 +- arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c | 6 ++ arch/x86/platform/intel-mid/device_libs/platform_tca6416.c | 6 +++--- arch/x86/platform/intel-mid/sfi.c| 8 +++- 11 files changed, 33 insertions(+), 17 deletions(-) -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf and Kconfig
[adding perf maintainers] On 12/20/13, 5:39 PM, Alexis Berlemont wrote: Hi, Here is a proposal of a small contribution which tries to fulfill the task "Use Kconfig to allow selecting features and build minimal version of perf,..." displayed on the todo page of the perf wiki (https://perf.wiki.kernel.org/index.php/Todo). I tried to continue the work started by David Ahern (https://github.com/dsahern/linux.git branch:perf-config). This version relies on the features detection tests available in linux/tools/perf/config/feature-checks so as to enable some configuration options (at least by default). This little task is not complete; more Kconfig options should be added for each perf tool (top, record, report, ...). I just wanted to ask whether you consider this proposal as interesting enough for inclusion and if you are ok with the way it is implemented. The code is available here: https://github.com/aberlemont/linux.git - branch: perf-config. I know Jiri has an attempt in his tree and there have been a few discussions since then as well. I'll take a look at it next week. I would like to see it completed; I just don't have the time to do it. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dma-buf: avoid using IS_ERR_OR_NULL
dma_buf_map_attachment and dma_buf_vmap can return NULL or
ERR_PTR on a error. This encourages a common buggy pattern in
callers:
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt))
return PTR_ERR(sgt);
This causes the caller to return 0 on an error. IS_ERR_OR_NULL
is almost always a sign of poorly-defined error handling.
This patch converts dma_buf_map_attachment to always return
ERR_PTR, and fixes the callers that incorrectly handled NULL.
There are a few more callers that were not checking for NULL
at all, which would have dereferenced a NULL pointer later.
There are also a few more callers that correctly handled NULL
and ERR_PTR differently, I left those alone but they could also
be modified to delete the NULL check.
This patch also converts dma_buf_vmap to always return NULL.
All the callers to dma_buf_vmap only check for NULL, and would
have dereferenced an ERR_PTR and panic'd if one was ever
returned. This is not consistent with the rest of the dma buf
APIs, but matches the expectations of all of the callers.
Signed-off-by: Colin Cross
---
drivers/base/dma-buf.c | 18 +++---
drivers/gpu/drm/drm_prime.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..cfe1d8bc7bb8 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Returns struct dma_buf_attachment * for this attachment; may return negative
- * error codes.
- *
+ * Returns struct dma_buf_attachment * for this attachment; returns ERR_PTR on
+ * error.
*/
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
@@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
* @attach:[in]attachment whose scatterlist is to be returned
* @direction: [in]direction of DMA transfer
*
- * Returns sg_table containing the scatterlist to be returned; may return NULL
- * or ERR_PTR.
- *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error.
*/
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
enum dma_data_direction direction)
@@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
return ERR_PTR(-EINVAL);
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
return sg_table;
}
@@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
+ *
+ * Returns NULL on error.
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
@@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
BUG_ON(dmabuf->vmap_ptr);
ptr = dmabuf->ops->vmap(dmabuf);
- if (IS_ERR_OR_NULL(ptr))
+ if (WARN_ON_ONCE(IS_ERR(ptr)))
+ ptr = NULL;
+ if (!ptr)
goto out_unlock;
dmabuf->vmap_ptr = ptr;
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 56805c39c906..bb516fdd195d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
get_dma_buf(dma_buf);
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR_OR_NULL(sgt)) {
+ if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc5e770..c786cd4f457b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -224,7 +224,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
get_dma_buf(dma_buf);
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR_OR_NULL(sgt)) {
+ if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 33d3871d1e13..880be0782dd9 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -719,7 +719,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
Broken initrd compression settings in 3.13
So commit 1bf49dd4be0b ("./Makefile: export initial ramdisk
compression config option") seems to be totally broken.
And I'm not saying that because Jan fixed a make-3.80 incompatibility
in commit 7ac181568342 ("fix build with make 3.80")
I'm saying that because it sets and exports the INITRD_COMPRESS
environment variable completely incorrectly, as far as I can tell.
And it looks like nobody noticed, because apparently dracut didn't use
to care about that INITRD_COMPRESS environment variable at all. But as
of a F20 update yesterday, apparently dracut actually does care, and
as a result nothing actually works.
That setting is f*cking moronic. It sets INITRD_COMPRESS to 'lz4' if
RD_LZ4 is set. But RD_LZ4 is *always* set (unless you go into some
expert settings), so basically what that commit does is to always set
INITRD_COMPRESS to lz4.
Why is that wrong?
It's wrong because
(a) most sane people don't even have lz4 _installed_, so dracut won't
actually succeed
(b) there's no way to select the compression level (unlike the
INITRAMFS_COMPRESSION thing that actually has a choice)
(c) even if you *do* have lz4, it doesn't actually work, because
while that causes the new F20 dracut to compress the initramfs with
lz4, the end result is completely broken, because the F20 "lsinitrd"
scripts don't understand the end result, so now the whole kernel
install fails.
Now, it could be argued that this is a F20 bug, and the fact that F20
has a dracut that can generate a lz4 initrd, but has other tools that
then cannot handle it is arguably indeed a buglet in F20. So the (c)
part is arguably a F20 problem.
HOWEVER.
(a) and (b) are very much kernel bugs.
I'm going to remove that export of INITRD_COMPRESS, since right now
that value is broken and useless. No way does it make sense to
mindlessly default to a compressor that most people don't have, and
that doesn't work with most tools.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
perf and Kconfig
Hi, Here is a proposal of a small contribution which tries to fulfill the task "Use Kconfig to allow selecting features and build minimal version of perf,..." displayed on the todo page of the perf wiki (https://perf.wiki.kernel.org/index.php/Todo). I tried to continue the work started by David Ahern (https://github.com/dsahern/linux.git branch:perf-config). This version relies on the features detection tests available in linux/tools/perf/config/feature-checks so as to enable some configuration options (at least by default). This little task is not complete; more Kconfig options should be added for each perf tool (top, record, report, ...). I just wanted to ask whether you consider this proposal as interesting enough for inclusion and if you are ok with the way it is implemented. The code is available here: https://github.com/aberlemont/linux.git - branch: perf-config. Alexis. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: module: BUG in copy_module_from_fd
On 12/20/2013 06:40 PM, Sasha Levin wrote: Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew. This reproduced twice with the same call trace, so I suspect it's something specific with the way the module subsystem calls vfs_getattr rather than something odd in vfs. Sorry, forget that. Just got one that has nothing to do with modules: BUG: unable to handle kernel paging request at 880429d40010 [ 2935.385056] IP: [] generic_fillattr+0xd/0xa0 [ 2935.386268] PGD 857a067 PUD 857d067 PMD 42fe93067 PTE 800429d40060 [ 2935.387998] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2935.389936] Dumping ftrace buffer: [ 2935.390321](ftrace buffer empty) [ 2935.390321] Modules linked in: [ 2935.390321] CPU: 22 PID: 57475 Comm: trinity-c598 Tainted: GW 3.13.0-rc4- next-20131220-sasha-00014-gd62f590-dirty #2 [ 2935.390321] task: 88005d88 ti: 88004e3be000 task.ti: 88004e3be000 [ 2935.390321] RIP: 0010:[] [] generic_fillattr+0x d/0xa0 [ 2935.390321] RSP: 0018:88004e3bfe58 EFLAGS: 00010246 [ 2935.390321] RAX: 880429d4 RBX: 88015bf9e5d0 RCX: 88015b700a20 [ 2935.390321] RDX: RSI: 88004e3bfee8 RDI: 88042a078550 [ 2935.390321] RBP: 88004e3bfe58 R08: 88042a078550 R09: [ 2935.390321] R10: 0001 R11: R12: 88004e3bfee8 [ 2935.390321] R13: 88004e3bfee8 R14: R15: 0010 [ 2935.390321] FS: 7ff7f4855700() GS:880161a0() knlGS: [ 2935.390321] CS: 0010 DS: ES: CR0: 8005003b [ 2935.390321] CR2: 880429d40010 CR3: 35487000 CR4: 06e0 [ 2935.390321] Stack: [ 2935.390321] 88004e3bfe68 812d79f8 88004e3bfe88 812d7fe7 [ 2935.390321] 88015bf9e5c0 88004e3bfed8 812d81f2 [ 2935.390321] 88004e3bfeb8 88005d88 81249435 0256 [ 2935.390321] Call Trace: [ 2935.390321] [] vfs_getattr_nosec+0x38/0x40 [ 2935.390321] [] vfs_getattr+0x37/0x50 [ 2935.390321] [] vfs_fstat+0x42/0x70 [ 2935.390321] [] ? context_tracking_user_exit+0x195/0x1d0 [ 2935.390321] [] SYSC_newfstat+0x1f/0x40 [ 2935.390321] [] ? trace_hardirqs_on+0xd/0x10 [ 2935.390321] [] ? syscall_trace_enter+0x32/0x290 [ 2935.390321] [] ? tracesys+0x7e/0xe2 [ 2935.390321] [] SyS_newfstat+0xe/0x10 [ 2935.390321] [] tracesys+0xdd/0xe2 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] intel-gtt: Read 64bit for gmar_bus_addr
On Mon, Nov 25, 2013 at 6:28 PM, Yinghai Lu wrote:
> That bar could be 64bit pref mem and above 4G.
>
> -v2: refresh to 3.13-rc1
>
> Signed-off-by: Yinghai Lu
> Cc: David Airlie
> Reviewed-by: Daniel Vetter
> ---
> drivers/char/agp/intel-gtt.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index b8e2014..b929e9d 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -609,8 +609,10 @@ static bool intel_gtt_can_wc(void)
> static int intel_gtt_init(void)
> {
> u32 gma_addr;
> + u32 addr_hi = 0;
> u32 gtt_map_size;
> int ret;
> + int pos;
>
> ret = intel_private.driver->setup();
> if (ret != 0)
> @@ -660,13 +662,17 @@ static int intel_gtt_init(void)
> }
>
> if (INTEL_GTT_GEN <= 2)
> - pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
> - _addr);
> + pos = I810_GMADDR;
> else
> - pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
> - _addr);
> + pos = I915_GMADDR;
> +
> + pci_read_config_dword(intel_private.pcidev, pos, _addr);
> +
> + if (gma_addr & PCI_BASE_ADDRESS_MEM_TYPE_64)
> + pci_read_config_dword(intel_private.pcidev, pos + 4,
> _hi);
Why are we reading these BARs directly anyway? These look like
standard PCI BARs (I810_GMADDR == 0x10 and I915_GMADDR == 0x18), so
the PCI core should already be reading them correctly, shouldn't it?
Can't we just use pcibios_resource_to_bus(pci_resource_start())?
It looks like i810_setup(), i830_setup(), and i9xx_setup() have the
same problem and should also be using pci_resource_start() or
something similar.
And I'm confused because the i915_gmch_probe() path fills in
gtt->mappable_base with the bus address, but the gen6_gmch_probe()
path uses the resource, i.e., the CPU, address. That looks broken to
me.
agp_serverworks_probe() looks like another place that should not be
reading the BARs directly.
>
> intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
> + intel_private.gma_bus_addr |= (u64)addr_hi << 32;
>
> return 0;
> }
> --
> 1.8.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/
[tip:x86/x32] x86, x32: Use __kernel_long_t/ __kernel_ulong_t in x86-64 stat.h
Commit-ID: b70fedc15892de8bc78f711d7821dd0916cc5508
Gitweb: http://git.kernel.org/tip/b70fedc15892de8bc78f711d7821dd0916cc5508
Author: H.J. Lu
AuthorDate: Mon, 16 Dec 2013 16:09:51 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 20 Dec 2013 16:04:35 -0800
x86, x32: Use __kernel_long_t/__kernel_ulong_t in x86-64 stat.h
Both x32 and x86-64 use the same stat system call interface. But x32
long is 32-bit. This patch changes x86 uapi to use
__kernel_long_t/__kernel_ulong_t in x86-64 stat.
Signed-off-by: H.J. Lu
Link:
http://lkml.kernel.org/r/CAMe9rOquPtWEro0GQ=Z95pZJ=c7ggkshynjn4fbib4p445x...@mail.gmail.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/uapi/asm/stat.h | 42 +---
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/x86/include/uapi/asm/stat.h b/arch/x86/include/uapi/asm/stat.h
index 7b3ddc3..bc03eb5 100644
--- a/arch/x86/include/uapi/asm/stat.h
+++ b/arch/x86/include/uapi/asm/stat.h
@@ -1,6 +1,8 @@
#ifndef _ASM_X86_STAT_H
#define _ASM_X86_STAT_H
+#include
+
#define STAT_HAVE_NSEC 1
#ifdef __i386__
@@ -78,26 +80,26 @@ struct stat64 {
#else /* __i386__ */
struct stat {
- unsigned long st_dev;
- unsigned long st_ino;
- unsigned long st_nlink;
-
- unsigned intst_mode;
- unsigned intst_uid;
- unsigned intst_gid;
- unsigned int__pad0;
- unsigned long st_rdev;
- longst_size;
- longst_blksize;
- longst_blocks; /* Number 512-byte blocks allocated. */
-
- unsigned long st_atime;
- unsigned long st_atime_nsec;
- unsigned long st_mtime;
- unsigned long st_mtime_nsec;
- unsigned long st_ctime;
- unsigned long st_ctime_nsec;
- long__unused[3];
+ __kernel_ulong_tst_dev;
+ __kernel_ulong_tst_ino;
+ __kernel_ulong_tst_nlink;
+
+ unsigned intst_mode;
+ unsigned intst_uid;
+ unsigned intst_gid;
+ unsigned int__pad0;
+ __kernel_ulong_tst_rdev;
+ __kernel_long_t st_size;
+ __kernel_long_t st_blksize;
+ __kernel_long_t st_blocks; /* Number 512-byte blocks
allocated. */
+
+ __kernel_ulong_tst_atime;
+ __kernel_ulong_tst_atime_nsec;
+ __kernel_ulong_tst_mtime;
+ __kernel_ulong_tst_mtime_nsec;
+ __kernel_ulong_tst_ctime;
+ __kernel_ulong_tst_ctime_nsec;
+ __kernel_long_t __unused[3];
};
/* We don't need to memset the whole thing just to initialize the padding */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/x32] x86, x32: Use __kernel_long_t for __statfs_word
Commit-ID: 79dbbc60493f357912d5f1da5a23147ba0c01c7a Gitweb: http://git.kernel.org/tip/79dbbc60493f357912d5f1da5a23147ba0c01c7a Author: H.J. Lu AuthorDate: Mon, 16 Dec 2013 16:12:57 -0800 Committer: H. Peter Anvin CommitDate: Fri, 20 Dec 2013 16:06:21 -0800 x86, x32: Use __kernel_long_t for __statfs_word x32 statfs system call is the same as x86-64 statfs system call, which uses 64-bit integer for __statfs_word. This patch defines __statfs_word as __kernel_long_t instead of long. Signed-off-by: H.J. Lu Link: http://lkml.kernel.org/r/came9rorcpphvc5g8u9n7d%2bpxvgdu1g598pge3erfw7pr-ie...@mail.gmail.com Cc: Arnd Bergmann Signed-off-by: H. Peter Anvin --- include/uapi/asm-generic/statfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/asm-generic/statfs.h b/include/uapi/asm-generic/statfs.h index 0999647..cb89cc7 100644 --- a/include/uapi/asm-generic/statfs.h +++ b/include/uapi/asm-generic/statfs.h @@ -13,7 +13,7 @@ */ #ifndef __statfs_word #if __BITS_PER_LONG == 64 -#define __statfs_word long +#define __statfs_word __kernel_long_t #else #define __statfs_word __u32 #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Add check for number of available vectors before CPU down [v3]
On 12/20/2013 03:06 PM, Luck, Tony wrote: >> I haven't double checked, but I'm assuming the hot plug locks are held >> while you are doing this. > > I dug into that when looking at v2 - the whole thing is under "stop_machine()" > so locking was not an issue. > > Reviewed-by: Tony Luck > Awesome, thank you! I have queued this up for Linus already as a fix for 3.13, as it seems important enough. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] hyperv: Fix race between probe and open calls
Moving the register_netdev to the end of probe to prevent
possible open call happens before NetVSP is connected.
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
---
drivers/net/hyperv/netvsc_drv.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index f813572..71baeb3 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -261,9 +261,7 @@ int netvsc_recv_callback(struct hv_device *device_obj,
struct sk_buff *skb;
net = ((struct netvsc_device *)hv_get_drvdata(device_obj))->ndev;
- if (!net) {
- netdev_err(net, "got receive callback but net device"
- " not initialized yet\n");
+ if (!net || net->reg_state != NETREG_REGISTERED) {
packet->status = NVSP_STAT_FAIL;
return 0;
}
@@ -435,19 +433,11 @@ static int netvsc_probe(struct hv_device *dev,
SET_ETHTOOL_OPS(net, _ops);
SET_NETDEV_DEV(net, >device);
- ret = register_netdev(net);
- if (ret != 0) {
- pr_err("Unable to register netdev.\n");
- free_netdev(net);
- goto out;
- }
-
/* Notify the netvsc driver of the new device */
device_info.ring_size = ring_size;
ret = rndis_filter_device_add(dev, _info);
if (ret != 0) {
netdev_err(net, "unable to add netvsc device (ret %d)\n", ret);
- unregister_netdev(net);
free_netdev(net);
hv_set_drvdata(dev, NULL);
return ret;
@@ -456,7 +446,13 @@ static int netvsc_probe(struct hv_device *dev,
netif_carrier_on(net);
-out:
+ ret = register_netdev(net);
+ if (ret != 0) {
+ pr_err("Unable to register netdev.\n");
+ rndis_filter_device_remove(dev);
+ free_netdev(net);
+ }
+
return ret;
}
--
1.7.4.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 v1] xhci: Switch Intel Lynx Point ports to EHCI on shutdown
On Fri, Dec 20, 2013 at 12:41:11PM +0200, Denis Turischev wrote: > > Also, which kernel are you experiencing this issue on? In 3.12, I > > queued a separate patch to deal with spurious reboot issues on Lynx > > Point: > > > > commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 > Sorry, I indeed tested not on the latest kernel version, Ubuntu 3.13-rc3 has > this patch and it works > for me. What does "Ubuntu 3.13-rc3" mean? Where did you get your kernel from? Also, do you have an HP system, or is this a different vendor? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
module: BUG in copy_module_from_fd
Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew. This reproduced twice with the same call trace, so I suspect it's something specific with the way the module subsystem calls vfs_getattr rather than something odd in vfs. [ 1694.568277] BUG: unable to handle kernel paging request at 88022adf8010 [ 1694.570053] IP: [] generic_fillattr+0xd/0xa0 [ 1694.570053] PGD 8577067 PUD 42effb067 PMD 42eea4067 PTE 80022adf8060 [ 1694.570053] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1694.570053] Dumping ftrace buffer: [ 1694.570053](ftrace buffer empty) [ 1694.570053] Modules linked in: [ 1694.570053] CPU: 60 PID: 35977 Comm: trinity-child60 Tainted: GW 3.13.0-r c4-next-20131219-sasha-00014-g94c0243-dirty #4166 [ 1694.570053] task: 8801064b8000 ti: 88013b56a000 task.ti: 88013b56a000 [ 1694.570053] waiting module removal not supported: please upgrade [ 1694.570053] RIP: 0010:[] [] generic_fillattr+0x d/0xa0 [ 1694.570053] RSP: 0018:88013b56bdd8 EFLAGS: 00010246 [ 1694.570053] RAX: 88022adf8000 RBX: 88018d5202d0 RCX: 8801584537b0 [ 1694.570053] RDX: 0001 RSI: 88013b56be28 RDI: 88022c450550 [ 1694.570053] RBP: 88013b56bdd8 R08: 88022c450550 R09: [ 1694.570053] R10: 0001 R11: R12: 88013b56be28 [ 1694.570053] R13: 88013b56bee8 R14: R15: 0193 [ 1694.570053] FS: 7f9d4b25f700() GS:88006600() knlGS: [ 1694.570053] CS: 0010 DS: ES: CR0: 80050033 [ 1694.570053] CR2: 88022adf8010 CR3: 00013b565000 CR4: 06e0 [ 1694.570053] Stack: [ 1694.570053] 88013b56bde8 812d78b8 88013b56be08 812d7ea7 [ 1694.570053] 88018d5202c0 88013b56bec8 811d76e5 [ 1694.570053] 0001 811759a6 88013b56be58 81194e1a [ 1694.570053] Call Trace: [ 1694.570053] [] vfs_getattr_nosec+0x38/0x40 [ 1694.570053] [] vfs_getattr+0x37/0x50 [ 1694.570053] [] copy_module_from_fd+0x65/0x150 [ 1694.570053] [] ? vtime_account_user+0x96/0xb0 [ 1694.570053] [] ? __lock_release+0x1da/0x1f0 [ 1694.570053] [] ? vtime_account_user+0x96/0xb0 [ 1694.570053] [] ? context_tracking_user_exit+0xb8/0x1d0 [ 1694.570053] [] ? security_capable+0x18/0x20 [ 1694.570053] [] SyS_finit_module+0xa3/0x100 [ 1694.570053] [] tracesys+0xdd/0xe2 [ 1694.570053] Code: 89 c8 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b 7d f8 c9 c3 90 90 90 90 90 90 55 48 89 e5 66 66 66 66 90 48 8b 47 28 <8b> 40 10 89 46 08 48 8b 47 40 48 89 06 0f b7 07 66 89 46 0c 8b [ 1694.570053] RIP [] generic_fillattr+0xd/0xa0 [ 1694.570053] RSP [ 1694.570053] CR2: 88022adf8010 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86, irq: Change check_vectors() to check_irq_vectors_for_cpu_disable()
Commit-ID: 9d69bb2cd96221b35bcabb3c1ffe84160bcf1b9f
Gitweb: http://git.kernel.org/tip/9d69bb2cd96221b35bcabb3c1ffe84160bcf1b9f
Author: H. Peter Anvin
AuthorDate: Fri, 20 Dec 2013 15:34:22 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 20 Dec 2013 15:34:22 -0800
x86, irq: Change check_vectors() to check_irq_vectors_for_cpu_disable()
In the context of smpboot.c especially, it is not at all obvious what
"check_vectors" actually mean. Since this function is only called in
one place, without arguments, we can afford to be a bit more verbose
with the function name and make it clear at a glance what the function
does.
Cc: Prarit Bhargava
Link:
http://lkml.kernel.org/r/1387554609-9823-1-git-send-email-pra...@redhat.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/irq.h | 2 +-
arch/x86/kernel/irq.c | 2 +-
arch/x86/kernel/smpboot.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
index dfd7372..cb6cfcd 100644
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -25,7 +25,7 @@ extern void irq_ctx_init(int cpu);
#ifdef CONFIG_HOTPLUG_CPU
#include
-extern int check_vectors(void);
+extern int check_irq_vectors_for_cpu_disable(void);
extern void fixup_irqs(void);
extern void irq_force_complete_move(int);
#endif
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 483f111..7d40698 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -266,7 +266,7 @@ EXPORT_SYMBOL_GPL(vector_used_by_percpu_irq);
* This cpu is going to be removed and its vectors migrated to the remaining
* online cpus. Check to see if there are enough vectors in the remaining
cpus.
*/
-int check_vectors(void)
+int check_irq_vectors_for_cpu_disable(void)
{
int irq, cpu;
unsigned int vector, this_count, count;
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 7ac6654..391ea52 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1314,7 +1314,7 @@ int native_cpu_disable(void)
{
int ret;
- ret = check_vectors();
+ ret = check_irq_vectors_for_cpu_disable();
if (ret)
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86: Add check for number of available vectors before CPU down
Commit-ID: 5fd782a0553cf9572bd38cb877ee6fbf070ef651 Gitweb: http://git.kernel.org/tip/5fd782a0553cf9572bd38cb877ee6fbf070ef651 Author: Prarit Bhargava AuthorDate: Fri, 20 Dec 2013 10:50:09 -0500 Committer: H. Peter Anvin CommitDate: Fri, 20 Dec 2013 15:24:04 -0800 x86: Add check for number of available vectors before CPU down Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791 When a cpu is downed on a system, the irqs on the cpu are assigned to other cpus. It is possible, however, that when a cpu is downed there aren't enough free vectors on the remaining cpus to account for the vectors from the cpu that is being downed. This results in an interesting "overflow" condition where irqs are "assigned" to a CPU but are not handled. For example, when downing cpus on a 1-64 logical processor system: [ 232.021745] smpboot: CPU 61 is now offline [ 238.480275] smpboot: CPU 62 is now offline [ 245.991080] [ cut here ] [ 245.996270] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x246/0x250() [ 246.005688] NETDEV WATCHDOG: p786p1 (ixgbe): transmit queue 0 timed out [ 246.013070] Modules linked in: lockd sunrpc iTCO_wdt iTCO_vendor_support sb_edac ixgbe microcode e1000e pcspkr joydev edac_core lpc_ich ioatdma ptp mdio mfd_core i2c_i801 dca pps_core i2c_core wmi acpi_cpufreq isci libsas scsi_transport_sas [ 246.037633] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0+ #14 [ 246.044451] Hardware name: Intel Corporation S4600LH ../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013 [ 246.057371] 0009 88081fa03d40 8164fbf6 88081fa0ee48 [ 246.065728] 88081fa03d90 88081fa03d80 81054ecc 88081fa13040 [ 246.074073] 88200cce 0040 [ 246.082430] Call Trace: [ 246.085174][] dump_stack+0x46/0x58 [ 246.091633] [] warn_slowpath_common+0x8c/0xc0 [ 246.098352] [] warn_slowpath_fmt+0x46/0x50 [ 246.104786] [] dev_watchdog+0x246/0x250 [ 246.110923] [] ? dev_deactivate_queue.constprop.31+0x80/0x80 [ 246.119097] [] call_timer_fn+0x3a/0x110 [ 246.125224] [] ? update_process_times+0x6f/0x80 [ 246.132137] [] ? dev_deactivate_queue.constprop.31+0x80/0x80 [ 246.140308] [] run_timer_softirq+0x1f0/0x2a0 [ 246.146933] [] __do_softirq+0xe0/0x220 [ 246.152976] [] call_softirq+0x1c/0x30 [ 246.158920] [] do_softirq+0x55/0x90 [ 246.164670] [] irq_exit+0xa5/0xb0 [ 246.170227] [] smp_apic_timer_interrupt+0x4a/0x60 [ 246.177324] [] apic_timer_interrupt+0x6a/0x70 [ 246.184041][] ? cpuidle_enter_state+0x5b/0xe0 [ 246.191559] [] ? cpuidle_enter_state+0x57/0xe0 [ 246.198374] [] cpuidle_idle_call+0xbd/0x200 [ 246.204900] [] arch_cpu_idle+0xe/0x30 [ 246.210846] [] cpu_startup_entry+0xd0/0x250 [ 246.217371] [] rest_init+0x77/0x80 [ 246.223028] [] start_kernel+0x3ee/0x3fb [ 246.229165] [] ? repair_env_string+0x5e/0x5e [ 246.235787] [] x86_64_start_reservations+0x2a/0x2c [ 246.242990] [] x86_64_start_kernel+0xf8/0xfc [ 246.249610] ---[ end trace fb74fdef54d79039 ]--- [ 246.254807] ixgbe :c2:00.0 p786p1: initiating reset due to tx timeout [ 246.262489] ixgbe :c2:00.0 p786p1: Reset adapter Last login: Mon Nov 11 08:35:14 from 10.18.17.119 [root@(none) ~]# [ 246.792676] ixgbe :c2:00.0 p786p1: detected SFP+: 5 [ 249.231598] ixgbe :c2:00.0 p786p1: NIC Link is Up 10 Gbps, Flow Control: RX/TX [ 246.792676] ixgbe :c2:00.0 p786p1: detected SFP+: 5 [ 249.231598] ixgbe :c2:00.0 p786p1: NIC Link is Up 10 Gbps, Flow Control: RX/TX (last lines keep repeating. ixgbe driver is dead until module reload.) If the downed cpu has more vectors than are free on the remaining cpus on the system, it is possible that some vectors are "orphaned" even though they are assigned to a cpu. In this case, since the ixgbe driver had a watchdog, the watchdog fired and notified that something was wrong. This patch adds a function, check_vectors(), to compare the number of vectors on the CPU going down and compares it to the number of vectors available on the system. If there aren't enough vectors for the CPU to go down, an error is returned and propogated back to userspace. v2: Do not need to look at percpu irqs v3: Need to check affinity to prevent counting of MSIs in IOAPIC Lowest Priority Mode Signed-off-by: Prarit Bhargava Link: http://lkml.kernel.org/r/1387554609-9823-1-git-send-email-pra...@redhat.com Reviewed-by: Andi Kleen Cc: Michel Lespinasse Cc: Seiji Aguchi Cc: Yang Zhang Cc: Paul Gortmaker Cc: Janet Morgan Cc: Tony Luck Cc: Ruiv Wang Cc: Gong Chen Signed-off-by: H. Peter Anvin Cc: # see note below [ hpa: I'm tagging this for -stable, as it is a serious failure on these large systems, but this is definitely a policy call for the -stable maintainers. ] --- arch/x86/include/asm/irq.h | 1 + arch/x86/kernel/irq.c | 44
[PATCH v2] fuse: Fix IOC_[GS]ET{FLAGS,VERSION} argument size brokenness.
The IOC_[GS]ETFLAGS and IOC_[GS]ETVERSION ioctls, despite being
defined to take a "long" parameter, actually take "int" parameters.
FUSE unfortunately assumed that the ioctl definitions never lie, and
transfers a long's worth of data in and out of userspace, which causes
stack smashing in chattr, and other bugs elsewhere.
So, special-case this in FUSE so that we don't crash userland.
v2: Do the same for the IOC_[GS]ETVERSION ioctls, as Richard Hansen
points out.
Signed-off-by: Darrick J. Wong
---
fs/fuse/file.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 7e70506..f8766ab 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2385,6 +2385,22 @@ long fuse_do_ioctl(struct file *file, unsigned int cmd,
unsigned long arg,
iov->iov_base = (void __user *)arg;
iov->iov_len = _IOC_SIZE(cmd);
+ /*
+* The IOC_[GS]ETFLAGS and IOC_[GS]ETVERSION ioctls take int
+* parameters even though the ioctl definition specifies long.
+* Userland has been expecting int for ages (and chattr
+* segfaults on FUSE filesystems), so special case that here.
+* The IOC32 variants were declared with int, so they don't
+* need this correction.
+*/
+ switch (cmd) {
+ case FS_IOC_GETFLAGS:
+ case FS_IOC_SETFLAGS:
+ case FS_IOC_GETVERSION:
+ case FS_IOC_SETVERSION:
+ iov->iov_len = sizeof(int);
+ }
+
if (_IOC_DIR(cmd) & _IOC_WRITE) {
in_iov = iov;
in_iovs = 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] rds: prevent dereference of a NULL device in rds_iw_laddr_check
Hello. On 12/21/2013 02:18 AM, Sasha Levin wrote: Binding might result in a NULL device which is later dereferenced without checking. Signed-off-by: Sasha Levin --- net/rds/iw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rds/iw.c b/net/rds/iw.c index 7826d46..0298920 100644 --- a/net/rds/iw.c +++ b/net/rds/iw.c @@ -239,7 +239,8 @@ static int rds_iw_laddr_check(__be32 addr) ret = rdma_bind_addr(cm_id, (struct sockaddr *)); /* due to this, we will claim to support IB devices unless we check node_type. */ - if (ret || cm_id->device->node_type != RDMA_NODE_RNIC) + if (ret || !cm_id->device || +cm_id->device->node_type != RDMA_NODE_RNIC) Indent with tabs and then spaces, not with spaces only please, so that the line aligns under 'ret'. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/13] sched: Add bandwidth management for sched_dl
On Fri, 20 Dec 2013 22:44:13 +0100
Peter Zijlstra wrote:
> @@ -5056,10 +5018,28 @@ static int sched_cpu_inactive(struct not
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_DOWN_PREPARE:
> set_cpu_active((long)hcpu, false);
> - return NOTIFY_OK;
> - default:
> - return NOTIFY_DONE;
> + break;
> }
> +
> + switch (action) {
> + case CPU_DOWN_PREPARE: /* explicitly allow suspend */
Instead of the double switch (which is quite confusing), what about
just adding:
if (!(action & CPU_TASKS_FROZEN))
I mean, the above switch gets called for both cases, this only gets
called for the one case. This case is a subset of the above. I don't
see why an if () would not be better than a double (confusing) switch().
Also, it seems that this change also does not return NOTIFY_DONE if
something other than CPU_DOWN_PREPARE is passed in.
-- Steve
> + {
> + struct dl_bw *dl_b = dl_bw_of(cpu);
> + bool overflow;
> + int cpus;
> +
> + raw_spin_lock_irqsave(_b->lock, flags);
> + cpus = dl_bw_cpus(cpu);
> + overflow = __dl_overflow(dl_b, cpus, 0, 0);
> + raw_spin_unlock_irqrestore(_b->lock, flags);
> +
> + if (overflow)
> + return notifier_from_errno(-EBUSY);
> + }
> + break;
> + }
> +
> + return NOTIFY_OK;
> }
>
> static int __init migration_init(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
On 12/20/2013 03:11 PM, Eric W. Biederman wrote: > > In that case the chrome folks would simply have to use an ELF format > kernel and not a bzImage. > This is starting to feel like everything is going in the direction of a massive feature regression. bzImage may be weird (it has definitely grown organically), but the features that have been added to it have generally been for a reason, e.g. kernel relocation and so on. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman wrote: > Vivek Goyal writes: > >> On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote: >>> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote: > >>> IMO it's up to user land to search lists of certificates, and present >>> only the final chain of trust to the kernel for checking. >>> >>> ELF is the preferred format for most sane OSes and firmware, and a detached >>> signature would probably be simplest to check. If we have the choice, >>> without restrictions from braindead boot loaders, ELF should be first. >>> And if the pesigning isn't usable and another sig is needed anyway, >>> why not apply that to vmlinux(.gz) ? >> >> I have yet to look deeper into it that if we can sign elf images and >> just use elf loader. And can use space extract the elf image out of >> a bzImage and pass it to kernel. >> >> Even if it is doable, one disadvantage seemed to be that extracted >> elf images will have to be written to a file so thta it's file descriptor >> can be passed to kernel. And that assumed writable root and we chrome >> folks seems to have setups where root is not writable. > > In that case the chrome folks would simply have to use an ELF format > kernel and not a bzImage. If we're doing fd origin verification (not signatures), can't we continue to use a regular bzImage? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rds: prevent dereference of a NULL device in rds_iw_laddr_check
Binding might result in a NULL device which is later dereferenced
without checking.
Signed-off-by: Sasha Levin
---
net/rds/iw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rds/iw.c b/net/rds/iw.c
index 7826d46..0298920 100644
--- a/net/rds/iw.c
+++ b/net/rds/iw.c
@@ -239,7 +239,8 @@ static int rds_iw_laddr_check(__be32 addr)
ret = rdma_bind_addr(cm_id, (struct sockaddr *));
/* due to this, we will claim to support IB devices unless we
check node_type. */
- if (ret || cm_id->device->node_type != RDMA_NODE_RNIC)
+ if (ret || !cm_id->device ||
+cm_id->device->node_type != RDMA_NODE_RNIC)
ret = -EADDRNOTAVAIL;
rdsdebug("addr %pI4 ret %d node type %d\n",
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] null_blk: corrections to documentation
From: Matias Bjørling Randy Dunlap reported a couple of grammar errors and unfortunate usages of socket/node/core. Signed-off-by: Matias Bjorling --- Documentation/block/null_blk.txt | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index 9e1b047..5603dad 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -18,7 +18,7 @@ The following instances are possible: - Bio-based. IO requests are submitted directly to the device driver. - Directly accepts bio data structure and returns them. -All of them has a completion queue for each core in the system. +All of them have a completion queue for each core in the system. II. Module parameters applicable for all instances: @@ -30,7 +30,7 @@ queue_mode=[0-2]: Default: 2-Multi-queue 2: Multi-queue. home_node=[0--nr_nodes]: Default: NUMA_NO_NODE - Selects what socket the data structures is allocated from. + Selects what CPU node the data structures are allocated from. gb=[Size in GB]: Default: 250GB The size of the device reported to the system. @@ -38,34 +38,34 @@ gb=[Size in GB]: Default: 250GB bs=[Block size (in bytes)]: Default: 512 bytes The block size reported to the system. -nr_devices=[Num. devices]: Default: 2 +nr_devices=[Number of devices]: Default: 2 Number of block devices instantiated. They are instantiated as /dev/nullb0, etc. -irq_mode=[0-2]: Default: Soft-irq +irq_mode=[0-2]: Default: 1-Soft-irq The completion mode used for completing IOs to the block-layer. 0: None. - 1: Soft-irq. Uses ipi to complete IOs across sockets. Simulates the overhead - when IOs are issued from another socket than the home the device is + 1: Soft-irq. Uses IPI to complete IOs across CPU nodes. Simulates the overhead + when IOs are issued from another CPU node than the home the device is connected to. 2: Timer: Waits a specific period (completion_nsec) for each IO before completion. -completion_nsec=[Num. ns]: Default: 10.000ns +completion_nsec=[ns]: Default: 10.000ns Combined with irq_mode=2 (timer). The time each completion event must wait. submit_queues=[0..nr_cpus]: The number of submission queues attached to the device driver. If unset, it defaults to 1 on single-queue and bio-based instances. For multi-queue, - its ignored when use_per_node_hctx module parameter is 1. + it is ignored when use_per_node_hctx module parameter is 1. -hw_queue_depth=[0..qdepth]: Defaults: 64 +hw_queue_depth=[0..qdepth]: Default: 64 The hardware queue depth of the device. III: Multi-queue specific parameters -use_per_node_hctx=[0/1]: Defaults: 1 +use_per_node_hctx=[0/1]: Default: 1 If 1, the multi-queue block layer is instantiated with a hardware dispatch queue for each CPU node in the system. If 0, it is instantiated with the number of queues defined in the submit_queues parameter. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
Vivek Goyal writes: > On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote: >> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote: >> IMO it's up to user land to search lists of certificates, and present >> only the final chain of trust to the kernel for checking. >> >> ELF is the preferred format for most sane OSes and firmware, and a detached >> signature would probably be simplest to check. If we have the choice, >> without restrictions from braindead boot loaders, ELF should be first. >> And if the pesigning isn't usable and another sig is needed anyway, >> why not apply that to vmlinux(.gz) ? > > I have yet to look deeper into it that if we can sign elf images and > just use elf loader. And can use space extract the elf image out of > a bzImage and pass it to kernel. > > Even if it is doable, one disadvantage seemed to be that extracted > elf images will have to be written to a file so thta it's file descriptor > can be passed to kernel. And that assumed writable root and we chrome > folks seems to have setups where root is not writable. In that case the chrome folks would simply have to use an ELF format kernel and not a bzImage. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] null_blk: support submit_queues on use_per_node_hctx
From: Matias Bjørling
In the case of both the submit_queues param and use_per_node_hctx param
are used. We limit the number af submit_queues to the number of online
nodes.
If the submit_queues is a multiple of nr_online_nodes, its trivial. Simply map
them to the nodes. For example: 8 submit queues are mapped as node0[0,1],
node1[2,3], ...
If uneven, we are left with an uneven number of submit_queues that must be
mapped. These are mapped toward the first node and onward. E.g. 5
submit queues mapped onto 4 nodes are mapped as node0[0,1], node1[2], ...
Signed-off-by: Matias Bjorling
---
drivers/block/null_blk.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 9b0311b..528f4e4 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -1,4 +1,5 @@
#include
+
#include
#include
#include
@@ -346,8 +347,37 @@ static int null_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *rq)
static struct blk_mq_hw_ctx *null_alloc_hctx(struct blk_mq_reg *reg, unsigned
int hctx_index)
{
- return kzalloc_node(sizeof(struct blk_mq_hw_ctx), GFP_KERNEL,
- hctx_index);
+ int b_size = DIV_ROUND_UP(reg->nr_hw_queues, nr_online_nodes);
+ int tip = (reg->nr_hw_queues % nr_online_nodes);
+ int node = 0, i, n;
+
+ /*
+* Split submit queues evenly wrt to the number of nodes. If uneven,
+* fill the first buckets with one extra, until the rest is filled with
+* no extra.
+*/
+ for (i = 0, n = 1; i < hctx_index; i++, n++) {
+ if (n % b_size == 0) {
+ n = 0;
+ node++;
+
+ tip--;
+ if (!tip)
+ b_size = reg->nr_hw_queues / nr_online_nodes;
+ }
+ }
+
+ /*
+* A node might not be online, therefore map the relative node id to the
+* real node id.
+*/
+ for_each_online_node(n) {
+ if (!node)
+ break;
+ node--;
+ }
+
+ return kzalloc_node(sizeof(struct blk_mq_hw_ctx), GFP_KERNEL, n);
}
static void null_free_hctx(struct blk_mq_hw_ctx *hctx, unsigned int hctx_index)
@@ -591,10 +621,11 @@ static int __init null_init(void)
#endif
if (queue_mode == NULL_Q_MQ && use_per_node_hctx) {
- if (submit_queues > 0)
+ if (submit_queues < nr_online_nodes) {
pr_warn("null_blk: submit_queues param is set to %u.",
nr_online_nodes);
- submit_queues = nr_online_nodes;
+ submit_queues = nr_online_nodes;
+ }
} else if (submit_queues > nr_cpu_ids)
submit_queues = nr_cpu_ids;
else if (!submit_queues)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: Fix IOC_[GS]ETFLAGS argument size brokenness
On Fri, Dec 20, 2013 at 01:19:27AM -0500, Richard Hansen wrote:
> On 2013-12-19 18:27, Darrick J. Wong wrote:
> > The IOC_[GS]ETFLAGS ioctls, despite being defined to take a "long"
> > parameter, actually take "int" parameters. FUSE unfortunately assumed
> > that the ioctl definitions never lie, and transfers a long's worth of
> > data in and out of userspace, which causes stack smashing in chattr,
> > and other bugs elsewhere.
> >
> > So, special-case this in FUSE, and document this int/long quirk in
> > include/uapi/linux/fs.h.
> >
> > Signed-off-by: Darrick J. Wong
> > ---
> > fs/fuse/file.c | 11 +++
> > include/uapi/linux/fs.h |1 +
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> > index 7e70506..5fa8181 100644
> > --- a/fs/fuse/file.c
> > +++ b/fs/fuse/file.c
> > @@ -2385,6 +2385,17 @@ long fuse_do_ioctl(struct file *file, unsigned int
> > cmd, unsigned long arg,
> > iov->iov_base = (void __user *)arg;
> > iov->iov_len = _IOC_SIZE(cmd);
> >
> > + /*
> > +* The IOC_[GS]ETFLAGS ioctls take int parameters even though
> > +* the ioctl definition specifies long. Userland has been
> > +* expecting int for ages (and chattr segfaults on FUSE
> > +* filesystems), so special case that here. The IOC32
> > +* variants were declared with int, so they don't need this.
> > +*/
> > + if (cmd == FS_IOC_GETFLAGS || cmd == FS_IOC_SETFLAGS) {
> > + iov->iov_len = sizeof(int);
> > + }
> > +
> > if (_IOC_DIR(cmd) & _IOC_WRITE) {
> > in_iov = iov;
> > in_iovs = 1;
> > diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> > index 6c28b61..bc8aa8e 100644
> > --- a/include/uapi/linux/fs.h
> > +++ b/include/uapi/linux/fs.h
> > @@ -154,6 +154,7 @@ struct inodes_stat_t {
> > #define FITHAW _IOWR('X', 120, int)/* Thaw */
> > #define FITRIM _IOWR('X', 121, struct fstrim_range)/* Trim
> > */
> >
> > +/* IOC_[GS]ETFLAGS take an int argument despite being defined to take
> > long. */
> > #defineFS_IOC_GETFLAGS _IOR('f', 1, long)
> > #defineFS_IOC_SETFLAGS _IOW('f', 2, long)
> > #defineFS_IOC_GETVERSION _IOR('v', 1, long)
>
> This change to include/uapi/linux/fs.h is similar to but not as thorough as:
>
> http://mid.gmane.org/1385548839-16617-1-git-send-email-aurel...@aurel32.net
> https://lkml.org/lkml/2013/11/27/93
>
> (The above linked patch is the patch Aurelien referenced in the
> "Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls" thread on
> linux-fsdevel; see
> .)
Aha! I thought I'd seen something like that on the list, though it doesn't
seem to be in -rc. Thank you for pointing that out.
And yes, now that I look at all the [GS]ETVERSION implementations, I think FUSE
could special-case those two ioctls too.
--D
>
> -Richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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 2/3] null_blk: set use_per_node_hctx param to false
From: Matias Bjørling
The defaults for the module is to instantiate itself with blk-mq and a
submit queue for each CPU node in the system.
To save resources, initialize instead with a single submit queue.
Signed-off-by: Matias Bjorling
---
Documentation/block/null_blk.txt | 9 +
drivers/block/null_blk.c | 4 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt
index 5603dad..b2830b4 100644
--- a/Documentation/block/null_blk.txt
+++ b/Documentation/block/null_blk.txt
@@ -65,7 +65,8 @@ hw_queue_depth=[0..qdepth]: Default: 64
III: Multi-queue specific parameters
-use_per_node_hctx=[0/1]: Default: 1
- If 1, the multi-queue block layer is instantiated with a hardware dispatch
- queue for each CPU node in the system. If 0, it is instantiated with the
- number of queues defined in the submit_queues parameter.
+use_per_node_hctx=[0/1]: Default: 0
+ 0: The number of submit queues are set to the value of the submit_queues
+ parameter.
+ 1: The multi-queue block layer is instantiated with a hardware dispatch
+ queue for each CPU node in the system.
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 8f2e7c3..9b0311b 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -101,9 +101,9 @@ static int hw_queue_depth = 64;
module_param(hw_queue_depth, int, S_IRUGO);
MODULE_PARM_DESC(hw_queue_depth, "Queue depth for each hardware queue.
Default: 64");
-static bool use_per_node_hctx = true;
+static bool use_per_node_hctx = false;
module_param(use_per_node_hctx, bool, S_IRUGO);
-MODULE_PARM_DESC(use_per_node_hctx, "Use per-node allocation for hardware
context queues. Default: true");
+MODULE_PARM_DESC(use_per_node_hctx, "Use per-node allocation for hardware
context queues. Default: false");
static void put_tag(struct nullb_queue *nq, unsigned int tag)
{
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] null_blk: documentation, defaults and mapping
Hi, These three patches cover: * Incorporated the feedback from Randy Dunlap into documentation. Can be merged with the previous documentation commit (6824518). * Set use_per_node_hctx to false per default to save resources. * Allow submit_queues and use_per_node_hctx to be used simultanesly. If the submit_queues is a multiple of nr_online_nodes, its trivial. Simply map them to the nodes. For example: 8 submit queues are mapped as node0[0,1], node1[2,3], ... If uneven, we are left with an uneven number of submit_queues that must be mapped. These are mapped toward the first node and onward. E.g. 5 submit queues mapped onto 4 nodes are mapped as node0[0,1], node1[2], ... Matias Bjørling (3): null_blk: corrections to documentation null_blk: set use_per_node_hctx param to false null_blk: support submit_queues on use_per_node_hctx Documentation/block/null_blk.txt | 27 + drivers/block/null_blk.c | 43 ++-- 2 files changed, 51 insertions(+), 19 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/ARM: fix ARMs __ffs() to conform to avoid warning with NO_BOOTMEM
On Fri, Dec 20, 2013 at 05:39:25PM -0500, Santosh Shilimkar wrote: > Russell, > > On Friday 13 December 2013 07:38 PM, Santosh Shilimkar wrote: > > Building ARM with NO_BOOTMEM generates below warning. > > > > mm/nobootmem.c: In function _free_pages_memory___: > > mm/nobootmem.c:88:11: warning: comparison of distinct pointer types lacks a > > cast > > > > order = min(MAX_ORDER - 1UL, __ffs(start)); > > > > ARM's __ffs() differs from other architectures in that it ends up being > > an int, whereas almost everyone else is unsigned long. > > > > So fix ARMs __ffs() to conform to other architectures. Suggested by > > Russell King > > > > Some more details in below thread - > > https://lkml.org/lkml/2013/12/9/807 > > > > Cc: Andrew Morton > > Cc: Russell King > > Signed-off-by: Santosh Shilimkar > > --- > Is this patch inline with what we discussed off-list ? It is. > If you ack it, it can go into the Andrews tree to kill that one last > warning with the memblock series. Thanks Acked-by: Russell King Please note that I'm rather busy at the moment dealing with a complete change in networking here (I've not read much in the way of email over the last couple of days). Also note that my Internet connection is highly unstable and experiencing a large amount of packet loss due to this wonderful thing called "FTTC"... which when working properly only gives me around 5Mbps. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Add check for number of available vectors before CPU down [v3]
> I haven't double checked, but I'm assuming the hot plug locks are held > while you are doing this. I dug into that when looking at v2 - the whole thing is under "stop_machine()" so locking was not an issue. Reviewed-by: Tony Luck -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/ARM: fix ARMs __ffs() to conform to avoid warning with NO_BOOTMEM
On Friday 20 December 2013 05:55 PM, Russell King - ARM Linux wrote: > On Fri, Dec 20, 2013 at 05:39:25PM -0500, Santosh Shilimkar wrote: >> Russell, >> >> On Friday 13 December 2013 07:38 PM, Santosh Shilimkar wrote: >>> Building ARM with NO_BOOTMEM generates below warning. >>> >>> mm/nobootmem.c: In function _free_pages_memory___: >>> mm/nobootmem.c:88:11: warning: comparison of distinct pointer types lacks a >>> cast >>> >>> order = min(MAX_ORDER - 1UL, __ffs(start)); >>> >>> ARM's __ffs() differs from other architectures in that it ends up being >>> an int, whereas almost everyone else is unsigned long. >>> >>> So fix ARMs __ffs() to conform to other architectures. Suggested by >>> Russell King >>> >>> Some more details in below thread - >>> https://lkml.org/lkml/2013/12/9/807 >>> >>> Cc: Andrew Morton >>> Cc: Russell King >>> Signed-off-by: Santosh Shilimkar >>> --- >> Is this patch inline with what we discussed off-list ? > > It is. > >> If you ack it, it can go into the Andrews tree to kill that one last >> warning with the memblock series. Thanks > > Acked-by: Russell King > Great !! Andrew, Can you please pick the $subject patch as well in your mm tree ? Thanks regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Add check for number of available vectors before CPU down [v3]
On Fri, Dec 20, 2013 at 10:50:09AM -0500, Prarit Bhargava wrote: > I tested across various systems with both the linux.git and linux-next.git > trees and do not see any false positives. The patch behaves as expected on > a system with 590 IRQs allocated at boot time; the system refuses to down cpu > 62. I read the patch and it looks good to me I haven't double checked, but I'm assuming the hot plug locks are held while you are doing this. Reviewed-by: Andi Kleen -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/ARM: fix ARMs __ffs() to conform to avoid warning with NO_BOOTMEM
Russell,
On Friday 13 December 2013 07:38 PM, Santosh Shilimkar wrote:
> Building ARM with NO_BOOTMEM generates below warning.
>
> mm/nobootmem.c: In function _free_pages_memory___:
> mm/nobootmem.c:88:11: warning: comparison of distinct pointer types lacks a
> cast
>
> order = min(MAX_ORDER - 1UL, __ffs(start));
>
> ARM's __ffs() differs from other architectures in that it ends up being
> an int, whereas almost everyone else is unsigned long.
>
> So fix ARMs __ffs() to conform to other architectures. Suggested by
> Russell King
>
> Some more details in below thread -
> https://lkml.org/lkml/2013/12/9/807
>
> Cc: Andrew Morton
> Cc: Russell King
> Signed-off-by: Santosh Shilimkar
> ---
Is this patch inline with what we discussed off-list ?
If you ack it, it can go into the Andrews tree to kill that one last
warning with the memblock series. Thanks
> arch/arm/include/asm/bitops.h | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index e691ec9..5f41d81 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -270,10 +270,25 @@ static inline int fls(int x)
> return ret;
> }
>
> -#define __fls(x) (fls(x) - 1)
> -#define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
> -#define __ffs(x) (ffs(x) - 1)
> -#define ffz(x) __ffs( ~(x) )
> +static inline unsigned long __fls(unsigned long x)
> +{
> + return fls(x) - 1;
> +}
> +
> +static inline int ffs(int x)
> +{
> + return fls(x & -x);
> +}
> +
> +static inline unsigned long __ffs(unsigned long x)
> +{
> + return ffs(x) - 1;
> +}
> +
> +static inline unsigned long ffz(unsigned long x)
> +{
> + return __ffs(~x);
> +}
>
> #endif
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: input: fix input sysfs path for hid devices
On Thu, 19 Dec 2013, David Herrmann wrote: > wrote: > > we used to set the parent of the input device as the parent of > > the hid bus. This was introduced when we created hid as a real bus, and > > to keep backward compatibility. Now, it's time to proper set the parent > > so that sysfs has an idea of which input device is attached to > > which hid device. > > > > Signed-off-by: Benjamin Tissoires > > --- > > > > Hi Jiri, > > > > well, the regression test did not showed anything bad, and a look at the hid > > drivers also showed that no drivers should be armed by that. > > > > I think this is valuable because it will give a better understanding of the > > actual mapping hardware/inputs. Like a touchscreen with pen + touch will > > have > > the same hid parent, and I expect X/Wayland to be able to detect this at > > some > > point to keep the mapping correctly between the two input devices and the > > screen. > > > > I also need that for hid-replay, so that I can be sure which input is > > attached > > to which uhid device, and give up the heuristics I currently use. > > I was just wondering where we have multiple HID devices on a single > parent, but yeah, uhid is a good example. I actually have no > objections to this patch and it looks fine. But I cannot tell whether > anyone relies on this. > > I'd say we should give it a try. Agreed, let's take it for 3.14, and if anyone complains about breakage caused by this (which I don't expect), we'll revert to the previous state. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/23] mm/memblock: Add memblock memory allocation apis
On Saturday 14 December 2013 02:48 PM, Santosh Shilimkar wrote:
> On Saturday 14 December 2013 06:08 AM, Tejun Heo wrote:
>> Hello, Santosh.
>>
>> On Fri, Dec 13, 2013 at 07:52:42PM -0500, Santosh Shilimkar wrote:
> +static void * __init memblock_virt_alloc_internal(
> + phys_addr_t size, phys_addr_t align,
> + phys_addr_t min_addr, phys_addr_t max_addr,
> + int nid)
> +{
> + phys_addr_t alloc;
> + void *ptr;
> +
> + if (nid == MAX_NUMNODES)
> + pr_warn("%s: usage of MAX_NUMNODES is depricated. Use
> NUMA_NO_NODE\n",
> + __func__);
Why not use WARN_ONCE()? Also, shouldn't nid be set to NUMA_NO_NODE
here?
>>> You want all the users using MAX_NUMNODES to know about it so that
>>> the wrong usage can be fixed. WARN_ONCE will hide that.
>>
>> Well, it doesn't really help anyone to be printing multiple messages
>> without any info on who was the caller and if this thing is gonna be
>> in mainline triggering of the warning should be rare anyway. It's
>> more of a tool to gather one-off cases in the wild. WARN_ONCE()
>> usually is the better choice as otherwise the warnings can swamp the
>> machine and console output in certain cases.
>>
> Fair enough.
>
...
> + if (nid != NUMA_NO_NODE) {
Otherwise, the above test is broken.
>>> So the idea was just to warn the users and allow them to fix
>>> the code. Well we are just allowing the existing users of using
>>> either MAX_NUMNODES or NUMA_NO_NODE continue to work. Thats what
>>> we discussed, right ?
>>
>> Huh? Yeah, sure. You're testing @nid against MAX_NUMNODES at the
>> beginning of the function. If it's MAX_NUMNODES, you print a warning
>> but nothing else, so the if() conditional above, which should succeed,
>> would fail. Am I missing sth here?
>>
> I get it now. Sorry I missed your point in first part. We will fix this.
>
Posted an incremental fix based on above discussion. You have been
copied on the patch.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/memblock: use WARN_ONCE when MAX_NUMNODES passed as input parameter
From: Grygorii Strashko
Check nid parameter and produce warning if it has deprecated MAX_NUMNODES
value. Also re-assign NUMA_NO_NODE value to the nid parameter in this case.
These will help to identify the wrong API usage (the caller) and make code
simpler.
Cc: Yinghai Lu
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Grygorii Strashko
Signed-off-by: Santosh Shilimkar
---
Incremental update on the memblock series as suggested by Tejun in
below thread:
https://lkml.org/lkml/2013/12/14/159
mm/memblock.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index 71b11d9..6af873a 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -707,11 +707,9 @@ void __init_memblock __next_free_mem_range(u64 *idx, int
nid,
struct memblock_type *rsv =
int mi = *idx & 0x;
int ri = *idx >> 32;
- bool check_node = (nid != NUMA_NO_NODE) && (nid != MAX_NUMNODES);
- if (nid == MAX_NUMNODES)
- pr_warn_once("%s: Usage of MAX_NUMNODES is depricated. Use
NUMA_NO_NODE instead\n",
-__func__);
+ if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is
deprecated. Use NUMA_NO_NODE instead\n"))
+ nid = NUMA_NO_NODE;
for ( ; mi < mem->cnt; mi++) {
struct memblock_region *m = >regions[mi];
@@ -719,7 +717,7 @@ void __init_memblock __next_free_mem_range(u64 *idx, int
nid,
phys_addr_t m_end = m->base + m->size;
/* only memory regions are associated with nodes, check it */
- if (check_node && nid != memblock_get_region_node(m))
+ if (nid != NUMA_NO_NODE && nid != memblock_get_region_node(m))
continue;
/* scan areas before each reservation for intersection */
@@ -775,11 +773,9 @@ void __init_memblock __next_free_mem_range_rev(u64 *idx,
int nid,
struct memblock_type *rsv =
int mi = *idx & 0x;
int ri = *idx >> 32;
- bool check_node = (nid != NUMA_NO_NODE) && (nid != MAX_NUMNODES);
- if (nid == MAX_NUMNODES)
- pr_warn_once("%s: Usage of MAX_NUMNODES is depricated. Use
NUMA_NO_NODE instead\n",
-__func__);
+ if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is
deprecated. Use NUMA_NO_NODE instead\n"))
+ nid = NUMA_NO_NODE;
if (*idx == (u64)ULLONG_MAX) {
mi = mem->cnt - 1;
@@ -792,7 +788,7 @@ void __init_memblock __next_free_mem_range_rev(u64 *idx,
int nid,
phys_addr_t m_end = m->base + m->size;
/* only memory regions are associated with nodes, check it */
- if (check_node && nid != memblock_get_region_node(m))
+ if (nid != NUMA_NO_NODE && nid != memblock_get_region_node(m))
continue;
/* scan areas before each reservation for intersection */
@@ -980,9 +976,8 @@ static void * __init memblock_virt_alloc_internal(
phys_addr_t alloc;
void *ptr;
- if (nid == MAX_NUMNODES)
- pr_warn("%s: usage of MAX_NUMNODES is depricated. Use
NUMA_NO_NODE\n",
- __func__);
+ if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is
deprecated. Use NUMA_NO_NODE instead\n"))
+ nid = NUMA_NO_NODE;
/*
* Detect any accidental use of these APIs after slab is ready, as at
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: fix build of split ptlock code
Commit 597d795a2a78 ('mm: do not allocate page->ptl dynamically, if
spinlock_t fits to long') restructures some allocators that are compiled
even if USE_SPLIT_PTLOCKS arn't used. It results in compilation failure:
mm/memory.c:4282:6: error: 'struct page' has no member named 'ptl'
mm/memory.c:4288:12: error: 'struct page' has no member named 'ptl'
Add in the missing ifdef.
Fixes: 597d795a2a78 ('mm: do not allocate page->ptl dynamically, if spinlock_t
fits to long')
Signed-off-by: Olof Johansson
Cc: Kirill A. Shutemov
Cc: Hugh Dickins
---
mm/memory.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index b6e211b..6768ce9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4271,7 +4271,7 @@ void copy_user_huge_page(struct page *dst, struct page
*src,
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
-#if ALLOC_SPLIT_PTLOCKS
+#if USE_SPLIT_PTE_PTLOCKS && ALLOC_SPLIT_PTLOCKS
bool ptlock_alloc(struct page *page)
{
spinlock_t *ptl;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] e1000: avoid potential deadlock in e1000_do_[read|write]_eeprom()
If eeprom->word_size is zero, e1000_do_[read|write]_eeprom() invoke e1000_init_eeprom_params() to reinit eeprom params. That is not a good idea since e1000_init_eeprom_params() calls e1000_read_eeprom() if eeprom->type is e1000_eeprom_spi. That means a deadlock on e1000_eeprom_lock. At the same time it is unclear if the reinit is needed at all. e1000_init_eeprom_params() is called from probe, so it should succeed before any activities of the module start. The patch suggests to remove the try to reinit eeprom params. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/net/ethernet/intel/e1000/e1000_hw.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.c b/drivers/net/ethernet/intel/e1000/e1000_hw.c index 2879b9631e15..a0317348ebde 100644 --- a/drivers/net/ethernet/intel/e1000/e1000_hw.c +++ b/drivers/net/ethernet/intel/e1000/e1000_hw.c @@ -3982,10 +3982,6 @@ static s32 e1000_do_read_eeprom(struct e1000_hw *hw, u16 offset, u16 words, return E1000_SUCCESS; } - /* If eeprom is not yet detected, do so now */ - if (eeprom->word_size == 0) - e1000_init_eeprom_params(hw); - /* A check for invalid values: offset too large, too many words, and * not enough words. */ @@ -4162,10 +4158,6 @@ static s32 e1000_do_write_eeprom(struct e1000_hw *hw, u16 offset, u16 words, return E1000_SUCCESS; } - /* If eeprom is not yet detected, do so now */ - if (eeprom->word_size == 0) - e1000_init_eeprom_params(hw); - /* A check for invalid values: offset too large, too many words, and * not enough words. */ -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME
On 12/20/2013 02:53 AM, Thomas Renninger wrote: > On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote: >> On 12/19/2013 08:05 PM, joeyli wrote: >>> Then that means the priority of PNP0B0x is higher then "CMOS RTC Not >>> Present" flag. ACPI spec doesn't have clear definition on this. >> >> According to the Microsoft requirements documents, such a platform is >> broken and shouldn't exist. > > Is this a public document? > Probably not but if, a pointer in this thread would help. > Does Microsoft mention ACPI Time and Alarm Device interface in > such a document already? > This is the document... I can't remember who sent me the link to it: http://goo.gl/R7S9Mk -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
