Re: Warning from free_init_pages with large initrd
On September 25, 2016 11:22:04 PM PDT, Sitsofe Wheeler wrote: >On 26 September 2016 at 03:14, H. Peter Anvin wrote: >> On 09/24/16 08:32, Sitsofe Wheeler wrote: >>> >>> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel >>> throws the following warning: >>> >> [...] >>> >>> The initrd is big because it holds all the files in the ISO (see >>> https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd for how it >was >>> made). The issue was originally filed on >>> https://bugzilla.redhat.com/show_bug.cgi?id=1274966 but was usually >>> against older kernels... >> >> How big is big? > >The one that matches that backtrace is 1385 Mbytes and was made from a >Fedora rawhide ISO. Here are some sizes in megabytes from different >versions of Fedora: >960 20/initrd0.img >1416 21/initrd0.img >1379 22/initrd0.img >1430 23/initrd0.img >1492 24/initrd.img Also: compressed or uncompressed (if it makes a difference?) -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Re: Warning from free_init_pages with large initrd
On September 25, 2016 11:22:04 PM PDT, Sitsofe Wheeler wrote: >On 26 September 2016 at 03:14, H. Peter Anvin wrote: >> On 09/24/16 08:32, Sitsofe Wheeler wrote: >>> >>> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel >>> throws the following warning: >>> >> [...] >>> >>> The initrd is big because it holds all the files in the ISO (see >>> https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd for how it >was >>> made). The issue was originally filed on >>> https://bugzilla.redhat.com/show_bug.cgi?id=1274966 but was usually >>> against older kernels... >> >> How big is big? > >The one that matches that backtrace is 1385 Mbytes and was made from a >Fedora rawhide ISO. Here are some sizes in megabytes from different >versions of Fedora: >960 20/initrd0.img >1416 21/initrd0.img >1379 22/initrd0.img >1430 23/initrd0.img >1492 24/initrd.img And they all fail? Also, is this BIOS or EFI? When loading under BIOS there is currently a 2 GB limit with most loaders; it would have been 4 GB except that Grub had a bug (sigh.) -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Re: [PATCH] pinctrl: qcom: fix masking of pinmux functions
On Mon, Sep 12, 2016 at 2:36 AM, John Crispin wrote:
> The following commit introduced a regression by not properly masking the
> calculated value.
>
> commit 47a01ee9a6c39fe1 ("pinctrl: qcom: Clear all function selection bits")
>
> Signed-off-by: John Crispin
Now I'm confused how it ever worked but agreed, the code looks wrong.
Reviewed-by: Stephen Boyd
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 51c42d7..775c883 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -156,7 +156,7 @@ static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev,
> spin_lock_irqsave(&pctrl->lock, flags);
>
> val = readl(pctrl->regs + g->ctl_reg);
> - val &= mask;
> + val &= ~mask;
> val |= i << g->mux_bit;
> writel(val, pctrl->regs + g->ctl_reg);
>
Re: [PATCH] drm/sun4i: rgb: Enable panel after controller
On Fri, Sep 23, 2016 at 11:43:55PM +1000, Jonathan Liu wrote: > Hi Maxime, > > On 23 September 2016 at 23:16, Maxime Ripard > wrote: > > On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote: > >> Hi Maxime, > >> > >> On Thursday, 22 September 2016, Maxime Ripard > >> >> com> wrote: > >> > >> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote: > >> > > The panel should be enabled after the controller so that the panel > >> > > prepare/enable delays are properly taken into account. Similarly, the > >> > > panel should be disabled before the controller so that the panel > >> > > unprepare/disable delays are properly taken into account. > >> > > > >> > > This is useful for avoiding visual glitches. > >> > > >> > This is not really taking any delays into account, especially since > >> > drm_panel_enable and prepare are suppose to block until their > >> > operation is complete. > >> > >> > >> drm_panel_prepare turns on power to the LCD using enable-gpios property of > >> the panel and then blocks for prepare delay. The prepare delay for panel > >> can be set to how long it takes between the time the panel is powered to > >> when it is ready to receive images. If backlight property is specified the > >> backlight will be off while the panel is powered on. > >> > >> drm_panel_enable blocks for enable delay and then turns on the backlight. > >> The enable delay can be set to how long it takes for panel to start making > >> the image visible after receiving the first valid frame. For example if the > >> panel starts off as white and the TFT takes some time to initialize to > >> black before it shows the image being received. > >> > >> Refer to drivers/gpu/drm/panel-panel.simple.c for details. > > > > From drm_panel.h: > > > > """ > > * drm_panel_enable - enable a panel > > * @panel: DRM panel > > * > > * Calling this function will cause the panel display drivers to be turned on > > * and the backlight to be enabled. Content will be visible on screen after > > * this call completes. > > """ > > > > """ > > * drm_panel_prepare - power on a panel > > * @panel: DRM panel > > * > > * Calling this function will enable power and deassert any reset signals to > > * the panel. After this has completed it is possible to communicate with any > > * integrated circuitry via a command bus. > > """ > > > > Those comments clearly says that the caller should not have to deal > > with the delays, even more so by just moving calls around and hoping > > that the code running in between is adding enough delay for the panel > > to behave properly. > > > > Maxime > > > > -- > > Maxime Ripard, Free Electrons > > Embedded Linux and Kernel engineering > > http://free-electrons.com > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_panel.h#n34 > > In comment for struct drm_panel_funcs: > /** > * struct drm_panel_funcs - perform operations on a given panel > * @disable: disable panel (turn off back light, etc.) > * @unprepare: turn off panel > * @prepare: turn on panel and perform set up > * @enable: enable panel (turn on back light, etc.) > * @get_modes: add modes to the connector that the panel is attached to and > * return the number of modes added > * @get_timings: copy display timings into the provided array and return > * the number of display timings available > * > * The .prepare() function is typically called before the display controller > * starts to transmit video data. Panel drivers can use this to turn the panel > * on and wait for it to become ready. If additional configuration is required > * (via a control bus such as I2C, SPI or DSI for example) this is a good time > * to do that. > * > * After the display controller has started transmitting video data, it's safe > * to call the .enable() function. This will typically enable the backlight to > * make the image on screen visible. Some panels require a certain amount of > * time or frames before the image is displayed. This function is responsible > * for taking this into account before enabling the backlight to avoid visual > * glitches. > * > * Before stopping video transmission from the display controller it can be > * necessary to turn off the panel to avoid visual glitches. This is done in > * the .disable() function. Analogously to .enable() this typically involves > * turning off the backlight and waiting for some time to make sure no image > * is visible on the panel. It is then safe for the display controller to > * cease transmission of video data. > * > * To save power when no video data is transmitted, a driver can power down > * the panel. This is the job of the .unprepare() function. > */ It kind of make my point. When drm_panel_enable is called, the content is visible, and there's no extra delay needed. If what you want to fix is that the panel is enabled before the controller, hence resulting in garbage on the screen while the controller is setup, then your commit
Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
Hi Oliver, Sorry for the slow answer. On Fri, Sep 09, 2016 at 11:01:08AM +0200, Olliver Schinagl wrote: > > > > > *chip, struct pwm_device *pwm) > > > > > spin_lock(&sun4i_pwm->ctrl_lock); > > > > > val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG); > > > > > val &= ~BIT_CH(PWM_EN, pwm->hwpwm); > > > > > + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG); > > > > > + spin_unlock(&sun4i_pwm->ctrl_lock); > > > > > + > > > > > + /* Allow for the PWM hardware to finish its last > > > > > toggle. > > > > > The pulse > > > > > + * may have just started and thus we should wait a > > > > > full > > > > > period. > > > > > + */ > > > > > + ndelay(pwm_get_period(pwm)); > > > > > > > > Can't that use the ready bit as well? > > > It depends whatever is cheaper. If we disable the pwm, we have to > > > commit that request to hardware first. Then we have to read back > > > the > > > has ready and in the strange situation it is not, wait for it to > > > become > > > ready? > > > > If it works like you were suggesting, yes. > > > > > > > > Also, that would mean we would loop in a spin lock, or keep > > > setting/clearing an additional spinlock to read the ready bit. > > > > You're using a spin_lock, so it's not that bad, but I was just > > suggesting replacing the ndelay. > > If you say the spin_lock + wait for the ready is just as expensive as > the ndelay, or the ndelay is less preferred, then I gladly make the > change; For the spin_lock part, I was just comparing it to a spin_lock_irqsave, which is pretty expensive since it masks all the interrupts in the system, introducing latencies. > but I think we need the ndelay for the else where we do not > have the ready flag (A10 or A13 iirc?) H, good point. But that would also apply to your second patch then, wouldn't it? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] nfp: bpf: improve handling for disabled BPF syscall
From: Arnd Bergmann
Date: Fri, 23 Sep 2016 22:23:59 +0200
> I stumbled over a new warning during randconfig testing,
> with CONFIG_BPF_SYSCALL disabled:
>
> drivers/net/ethernet/netronome/nfp/nfp_net_offload.c: In function
> 'nfp_net_bpf_offload':
> drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: '*((void
> *)&res+4)' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error:
> 'res.n_instr' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>
> As far as I can tell, this is a false positive caused by the compiler
> getting confused about a function that is partially inlined, but it's
> easy to avoid while improving the code:
>
> The nfp_bpf_jit() stub helper for that configuration is unusual as it
> is defined in a header file but not marked 'static inline'. By moving
> the compile-time check into the caller using the IS_ENABLED() macro,
> we can remove that stub and simplify the nfp_net_bpf_offload_prepare()
> function enough to unconfuse the compiler.
>
> Fixes: 7533fdc0f77f ("nfp: bpf: add hardware bpf offload")
> Signed-off-by: Arnd Bergmann
Applied, thanks.
[PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
From: Liav Rehana
During the calculation of the nsec variable in the inline function
timekeeping_delta_to_ns, it may undergo a sign extension if its msb
is set just before the shift. The sign extension may, in some cases,
gain it a value near the maximum value of the 64-bit range. This is
bad when it is later used in a division function, such as
__iter_div_u64_rem, where the amount of loops it will go through to
calculate the division will be too large. One can encounter such a
problem, for example, when trying to connect through ftp from an
outside host to the operation system. When the OS is too overloaded,
delta will get a high enough value for the msb of the sum
delta * tkr->mult + tkr->xtime_nsec to be set, and so after the
shift the nsec variable will gain a value similar to
0xff00. Using a variable with such a value in the
inline function __iter_div_u64_rem will take too long, making the
ftp connection attempt seem to get stuck.
The following commit fixes that chance of sign extension, while
maintaining the type of the nsec variable as signed for other
functions that use this variable, for possible legit negative
time intervals.
Signed-off-by: Liav Rehana
---
kernel/time/timekeeping.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 479d25c..f2c0067 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -299,10 +299,10 @@ u32 (*arch_gettimeoffset)(void) =
default_arch_gettimeoffset;
static inline u32 arch_gettimeoffset(void) { return 0; }
#endif
-static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
+static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
cycle_t delta)
{
- s64 nsec;
+ u64 nsec;
nsec = delta * tkr->mult + tkr->xtime_nsec;
nsec >>= tkr->shift;
--
1.7.1
Re: [PATCH v7 0/8] power: add power sequence library
On Tue, Sep 20, 2016 at 11:36:39AM +0800, Peter Chen wrote: > Hi all, > > This is a follow-up for my last power sequence framework patch set [1]. > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of > power sequence instances will be added at postcore_initcall, the match > criteria is compatible string first, if the compatible string is not > matched between dts and library, it will try to use generic power sequence. > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off > if only one power sequence instance is needed, for more power sequences > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub > driver). > > In future, if there are special power sequence requirements, the special > power sequence library can be created. > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use > two hot-plug devices to simulate this use case, the related binding > change is updated at patch [1/6], The udoo board changes were tested > using my last power sequence patch set.[3] > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also > need to power on itself before it can be found by ULPI bus. > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html > [2] http://www.spinics.net/lists/linux-usb/msg143106.html > [3] http://www.spinics.net/lists/linux-usb/msg142815.html > > Changes for v7: > - Create kinds of power sequence instance at postcore_initcall, and match > the instance with node using compatible string, the beneit of this is > the host driver doesn't need to consider which pwrseq instance needs > to be used, and pwrseq core will match it, however, it eats some memories > if less power sequence instances are used. [Patch 2/8] > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch > 2/8] > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not > use device_node for parameters at pwrseq_on. [Patch 2/8] > - Simplify the caller to use power sequence, follows Alan's commnets [Patch > 4/8] > - Tested three pwrseq instances together using both specific compatible > string and > generic libraries. > Hi Vaibhav, would you please test if this series can support your case, you can add one instance like pwrseq_compatible_sample? If you are busy now, but think this series can satisfy your requirement, please ack it. I will delete pwrseq_compatible_sample, and only submit the generic one at next revision, you can add it later, thanks. Peter > Changes for v6: > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6]) > - Change chipidea core of_node assignment for coming user. (patch [5/6]) > - Applies Joshua Clayton's three dts changes for two boards, > the USB device's reg has only #address-cells, but without #size-cells. > > Changes for v5: > - Delete pwrseq_register/pwrseq_unregister, which is useless currently > - Fix the linker error when the pwrseq user is compiled as module > > Changes for v4: > - Create the patch on next-20160722 > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6] > - Using more friendly wait method for reset gpio [Patch 2/6] > - Support multiple input clocks [Patch 2/6] > - Add Rob Herring's ack for DT changes > - Add Joshua Clayton's Tested-by > > Changes for v3: > - Delete "power-sequence" property at binding-doc, and change related code > at both library and user code. > - Change binding-doc example node name with Rob's comments > - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags, > add additional code request gpio with proper gpio flags > - Add Philipp Zabel's Ack and MAINTAINER's entry > > Changes for v2: > - Delete "pwrseq" prefix and clock-names for properties at dt binding > - Should use structure not but its pointer for kzalloc > - Since chipidea core has no of_node, let core's of_node equals glue > layer's at core's probe > > Joshua Clayton (2): > ARM: dts: imx6qdl: Enable usb node children with > ARM: dts: imx6q-evi: Fix onboard hub reset line > > Peter Chen (6): > binding-doc: power: pwrseq-generic: add binding doc for generic power > sequence library > power: add power sequence library > binding-doc: usb: usb-device: add optional properties for power > sequence > usb: core: add power sequence handling for USB devices > usb: chipidea: let chipidea core device of_node equal's glue layer > device of_node > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property > > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++ > .../devicetree/bindings/usb/usb-device.txt | 10 +- > MAINTAINERS| 9 + > arch/arm/boot/dts/imx6q-evi.dts| 25 +-- > arch/arm/boot/dts/imx6qdl-udoo.dtsi| 26 ++- > arch/arm/boot/dts/imx6qdl.dtsi | 6 + > drivers/power/Kconfig | 1 + > drivers/power
Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression
Hi, Jaegeuk, "Huang, Ying" writes: > Jaegeuk Kim writes: > >> Hello, >> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote: >>> Hi Jaegeuk, >>> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression >>> > > >> > >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via mdadm. The >>> > > >> > steps for aim7 is, >>> > > >> > >>> > > >> > cat > workfile <>> > > >> > FILESIZE: 1M >>> > > >> > POOLSIZE: 10M >>> > > >> > 10 sync_disk_rw >>> > > >> > EOF >>> > > >> > >>> > > >> > ( >>> > > >> > echo $HOSTNAME >>> > > >> > echo sync_disk_rw >>> > > >> > >>> > > >> > echo 1 >>> > > >> > echo 600 >>> > > >> > echo 2 >>> > > >> > echo 600 >>> > > >> > echo 1 >>> > > >> > ) | ./multitask -t & >>> > > >> >>> > > >> Any update on these 2 regressions? Is the information is enough for >>> > > >> you >>> > > >> to reproduce? >>> > > > >>> > > > Sorry, I've had no time to dig this due to business travel now. >>> > > > I'll check that when back to US. >>> > > >>> > > Any update? >>> > >>> > Sorry, how can I get multitask binary? >>> >>> It's part of aim7, which can be downloaded here: >>> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z >> >> Thank you for the codes. >> >> I've run this workload on the latest f2fs and compared performance having >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM) >> Interestingly, I could find slight performance improvement rather than >> regression. :( >> Not sure how to reproduce this. > > I think the difference lies on disk used. The ramdisk is used in the > original test, but it appears that your memory is too small to setup the > RAM disk for test. So it may be impossible for you to reproduce the > test unless you can find more memory :) > > But we can help you to root cause the issue. What additional data do > you want? perf-profile data before and after the patch? Any update to this regression? Best Regards, Huang, Ying
Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression
Hi, Christoph, "Huang, Ying" writes: > Hi, Christoph, > > "Huang, Ying" writes: > >> Christoph Hellwig writes: >> >>> Snipping the long contest: >>> >>> I think there are three observations here: >>> >>> (1) removing the mark_page_accessed (which is the only significant >>> change in the parent commit) hurts the >>> aim7/1BRD_48G-xfs-disk_rr-3000-performance/ivb44 test. >>> I'd still rather stick to the filemap version and let the >>> VM people sort it out. How do the numbers for this test >>> look for XFS vs say ext4 and btrfs? >>> (2) lots of additional spinlock contention in the new case. A quick >>> check shows that I fat-fingered my rewrite so that we do >>> the xfs_inode_set_eofblocks_tag call now for the pure lookup >>> case, and pretty much all new cycles come from that. >>> (3) Boy, are those xfs_inode_set_eofblocks_tag calls expensive, and >>> we're already doing way to many even without my little bug above. >>> >>> So I've force pushed a new version of the iomap-fixes branch with >>> (2) fixed, and also a little patch to xfs_inode_set_eofblocks_tag a >>> lot less expensive slotted in before that. Would be good to see >>> the numbers with that. >> >> For the original reported regression, the test result is as follow, >> >> = >> compiler/cpufreq_governor/debug-setup/disk/fs/kconfig/load/rootfs/tbox_group/test/testcase: >> >> gcc-6/performance/profile/1BRD_48G/xfs/x86_64-rhel/3000/debian-x86_64-2015-02-07.cgz/ivb44/disk_wrt/aim7 >> >> commit: >> f0c6bcba74ac51cb77aadb33ad35cb2dc1ad1506 (parent of first bad commit) >> 68a9f5e7007c1afa2cf6830b690a90d0187c0684 (first bad commit) >> 99091700659f4df965e138b38b4fa26a29b7eade (base of your fixes branch) >> bf4dc6e4ecc2a3d042029319bc8cd4204c185610 (head of your fixes branch) >> >> f0c6bcba74ac51cb 68a9f5e7007c1afa2cf6830b69 99091700659f4df965e138b38b >> bf4dc6e4ecc2a3d042029319bc >> -- -- >> -- >> %stddev %change %stddev %change %stddev >> %change %stddev >> \ |\ |\ >>|\ >> 484435 ± 0% -13.3% 420004 ± 0% -17.0% 402250 ± 0% >> -15.6% 408998 ± 0% aim7.jobs-per-min > > It appears the original reported regression hasn't bee resolved by your > commit. Could you take a look at the test results and the perf data? Any update to this regression? Best Regards, Huang, Ying >> >> And the perf data is as follow, >> >> "perf-profile.func.cycles-pp.intel_idle": 20.25, >> "perf-profile.func.cycles-pp.memset_erms": 11.72, >> "perf-profile.func.cycles-pp.copy_user_enhanced_fast_string": 8.37, >> "perf-profile.func.cycles-pp.__block_commit_write.isra.21": 3.49, >> "perf-profile.func.cycles-pp.block_write_end": 1.77, >> "perf-profile.func.cycles-pp.native_queued_spin_lock_slowpath": 1.63, >> "perf-profile.func.cycles-pp.unlock_page": 1.58, >> "perf-profile.func.cycles-pp.___might_sleep": 1.56, >> "perf-profile.func.cycles-pp.__block_write_begin_int": 1.33, >> "perf-profile.func.cycles-pp.iov_iter_copy_from_user_atomic": 1.23, >> "perf-profile.func.cycles-pp.up_write": 1.21, >> "perf-profile.func.cycles-pp.__mark_inode_dirty": 1.18, >> "perf-profile.func.cycles-pp.down_write": 1.06, >> "perf-profile.func.cycles-pp.mark_buffer_dirty": 0.94, >> "perf-profile.func.cycles-pp.generic_write_end": 0.92, >> "perf-profile.func.cycles-pp.__radix_tree_lookup": 0.91, >> "perf-profile.func.cycles-pp._raw_spin_lock": 0.81, >> "perf-profile.func.cycles-pp.entry_SYSCALL_64_fastpath": 0.79, >> "perf-profile.func.cycles-pp.__might_sleep": 0.79, >> "perf-profile.func.cycles-pp.xfs_file_iomap_begin_delay.isra.9": 0.7, >> "perf-profile.func.cycles-pp.__list_del_entry": 0.7, >> "perf-profile.func.cycles-pp.vfs_write": 0.69, >> "perf-profile.func.cycles-pp.drop_buffers": 0.68, >> "perf-profile.func.cycles-pp.xfs_file_write_iter": 0.67, >> "perf-profile.func.cycles-pp.rwsem_spin_on_owner": 0.67, >> >> Best Regards, >> Huang, Ying >> ___ >> LKP mailing list >> l...@lists.01.org >> https://lists.01.org/mailman/listinfo/lkp
Re: [PATCH] net: hns: mark symbols static where possible
From: Baoyou Xie Date: Sun, 25 Sep 2016 17:34:06 +0800 > We get a few warnings when building kernel with W=1: Patch does not apply to net-next.
Re: [PATCH] net: hip04: mark tx_done() static
From: Baoyou Xie Date: Sun, 25 Sep 2016 17:19:04 +0800 > We get 1 warning when building kernel with W=1: > drivers/net/ethernet/hisilicon/hip04_eth.c:603:22: warning: no previous > prototype for 'tx_done' [-Wmissing-prototypes] > > In fact, this function is only used in the file in which it is > declared and don't need a declaration, but can be made static. > so this patch marks this function with 'static'. > > Signed-off-by: Baoyou Xie Applied.
Re: [PATCH] net: hisilicon: mark symbols static where possible
From: Baoyou Xie Date: Sun, 25 Sep 2016 17:16:44 +0800 > We get 2 warnings when building kernel with W=1: > drivers/net/ethernet/hisilicon/hisi_femac.c:943:5: warning: no previous > prototype for 'hisi_femac_drv_suspend' [-Wmissing-prototypes] > drivers/net/ethernet/hisilicon/hisi_femac.c:960:5: warning: no previous > prototype for 'hisi_femac_drv_resume' [-Wmissing-prototypes] > > In fact, these two functions are only used in the file in which they are > declared and don't need a declaration, but can be made static. > so this patch marks these functions with 'static'. > > Signed-off-by: Baoyou Xie Applied.
Re: [PATCH] net: bcmgenet: remove unused function in bcmgenet.c
From: Baoyou Xie Date: Sun, 25 Sep 2016 14:23:15 +0800 > We get 1 warning when building kernel with W=1: > drivers/net/ethernet/broadcom/genet/bcmgenet.c:2763:5: warning: no previous > prototype for 'bcmgenet_hfb_add_filter' [-Wmissing-prototypes] > > In fact, this function is implemented in > drivers/net/ethernet/broadcom/genet/bcmgenet.c, but be called > by no one, thus can be removed. > > So this patch removes the unused functions. > > Signed-off-by: Baoyou Xie Applied.
Re: [PATCH] net: mvneta: mark symbols static where possible
From: Baoyou Xie Date: Sun, 25 Sep 2016 17:20:41 +0800 > We get 2 warnings when building kernel with W=1: > drivers/net/ethernet/marvell/mvneta.c:639:27: warning: no previous prototype > for 'mvneta_get_stats64' [-Wmissing-prototypes] > drivers/net/ethernet/marvell/mvneta.c:3529:5: warning: no previous prototype > for 'mvneta_ethtool_set_link_ksettings' [-Wmissing-prototypes] > > In fact, these two functions are only used in the file in which they are > declared and don't need a declaration, but can be made static. > so this patch marks these functions with 'static'. > > Signed-off-by: Baoyou Xie Applied.
Re: [PATCH] cxgb4: mark symbols static where possible
From: Baoyou Xie Date: Sun, 25 Sep 2016 14:10:09 +0800 > We get 10 warnings when building kernel with W=1: > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:304:5: warning: no previous > prototype for 'cxgb4_dcb_enabled' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:194:5: warning: no previous > prototype for 'setup_sge_queues_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:241:6: warning: no previous > prototype for 'free_sge_queues_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:268:5: warning: no previous > prototype for 'cfg_queues_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:344:6: warning: no previous > prototype for 'free_queues_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:353:5: warning: no previous > prototype for 'request_msix_queue_irqs_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:379:6: warning: no previous > prototype for 'free_msix_queue_irqs_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:393:6: warning: no previous > prototype for 'name_msix_vecs_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:433:6: warning: no previous > prototype for 'enable_rx_uld' [-Wmissing-prototypes] > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:442:6: warning: no previous > prototype for 'quiesce_rx_uld' [-Wmissing-prototypes] > > In fact, these functions are only used in the file in which they are > declared and don't need a declaration, but can be made static. > so this patch marks these functions with 'static'. > > Signed-off-by: Baoyou Xie Applied.
Re: [PATCH v3] arm: dts: zynq: Add MicroZed board support
On 23.9.2016 11:48, Jagan Teki wrote:
> From: Jagan Teki
>
> Added basic dts support for MicroZed board.
>
> - UART
> - SDHCI
> - Ethernet
>
> Cc: Soren Brinkmann
> Cc: Michal Simek
> Signed-off-by: Jagan Teki
> ---
> Changes for v3:
> - Add Xilinx copyright
> Changes for v2:
> - Add SDHCI
> - Add Ethernet
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/zynq-microzed.dts | 96
> +
> 2 files changed, 97 insertions(+)
> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..4d7b858 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
> wm8750-apc8750.dtb \
> wm8850-w70v2.dtb
> dtb-$(CONFIG_ARCH_ZYNQ) += \
> + zynq-microzed.dtb \
> zynq-parallella.dtb \
> zynq-zc702.dtb \
> zynq-zc706.dtb \
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts
> b/arch/arm/boot/dts/zynq-microzed.dts
> new file mode 100644
> index 000..b9376a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2016 Jagan Teki
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MicroZED Development Board";
> + compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x4000>;
> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb0_default>;
> +};
> +
> +&pinctrl0 {
> + pinctrl_usb0_default: usb0-default {
> + mux {
> + groups = "usb0_0_grp";
> + function = "usb0";
> + };
> +
> + conf {
> + groups = "usb0_0_grp";
> + slew-rate = <0>;
> + io-standard = <1>;
> + };
> +
> + conf-rx {
> + pins = "MIO29", "MIO31", "MIO36";
> + bias-high-impedance;
> + };
> +
> + conf-tx {
> + pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
> +"MIO35", "MIO37", "MIO38", "MIO39";
> + bias-disable;
> + };
> + };
> +};
>
Applied.
Thanks,
Michal
Re: Warning from free_init_pages with large initrd
On 26 September 2016 at 03:14, H. Peter Anvin wrote: > On 09/24/16 08:32, Sitsofe Wheeler wrote: >> >> While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel >> throws the following warning: >> > [...] >> >> The initrd is big because it holds all the files in the ISO (see >> https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd for how it was >> made). The issue was originally filed on >> https://bugzilla.redhat.com/show_bug.cgi?id=1274966 but was usually >> against older kernels... > > How big is big? The one that matches that backtrace is 1385 Mbytes and was made from a Fedora rawhide ISO. Here are some sizes in megabytes from different versions of Fedora: 960 20/initrd0.img 1416 21/initrd0.img 1379 22/initrd0.img 1430 23/initrd0.img 1492 24/initrd.img -- Sitsofe | http://sucs.org/~sits/
Re: [PATCH] tty/serial: atmel: fix fractional baud rate computation
Hello, On Wed, Sep 21, 2016 at 12:44:14PM +0200, Nicolas Ferre wrote: > From: Alexey Starikovskiy > > The problem with previous code was it rounded values in wrong > place and produced wrong baud rate in some cases. > > Signed-off-by: Alexey Starikovskiy > [nicolas.fe...@atmel.com: port to newer kernel and add commit log] > Signed-off-by: Nicolas Ferre I first thought this patch results in not always picking the optimal divider in some cases. But given the right error function (i.e. error(r) = abs(1/r_target - 1/r_actual) which minimizes the error in the time domain and so guarantees the maximal count of matched samples) it can be proved to result in the right values (assuming no overflow etc.). As writing formulas in email is cumbersome, see the attachment for a prove. Reviewed-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | baudrate.pdf Description: Adobe PDF document
Re: [RFC PATCH 00/11] pci: support for configurable PCI endpoint
Hi Arnd,
On Thursday 22 September 2016 07:04 PM, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
>> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
>>> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I
>>> wrote:
>>> I've added the drivers/ntb maintainers to Cc, given that there is
>>> a certain degree of overlap between your work and the existing
>>> code, I think they should be part of the discussion.
>>>
Known Limitation:
*) Does not support multi-function devices
>>>
>>> If I understand it right, this was a problem for USB and adding
>>> it later made it somewhat inconsistent. Maybe we can at least
>>> try to come up with an idea of how multi-function devices
>>> could be handled even if we don't implement it until someone
>>> actually needs it.
>>
>> Actually IMO multi-function device in PCI should be much simpler than it is
>> for
>> USB. In the case of USB, all the functions in a multi-function device will
>> share the same *usb configuration* . (USB device can have multiple
>> configuration but only one can be enabled at a time). A multi-function USB
>> device will still have a single vendor-id/product-id/class... So I think a
>> separate library (composite.c) in USB makes sense.
>
> Ok, makes sense.
>
>> But in the case of PCI, every function can be treated independently since all
>> the functions have it's own 4KB configuration space. Each function can be
>> configured independently. Each can have it's own vendor-id/product-id/class..
>> I'm not sure if we'll need a separate library for PCI like we have for USB.
>
> I think it depends on whether we want to add the software multi-function
> support you mention.
>
>> Now the restriction for not allowing multi-function device is because of the
>> following structure definition.
>>
>> struct pci_epc {
>> ..
>> struct pci_epf *epf;
>> ..
>> };
>>
>> EPC has a single reference to EPF and it is used *only* to notify the
>> function
>> driver when the link is up. (If this can be changed to use notification
>> mechanism, multi-function devices can be supported here)
>>
>> One more place where this restriction arises is in designware driver
>>
>> struct dw_pcie_ep {
>> ..
>> u8 bar_to_atu[6];
>> ..
>> };
>>
>> We use single ATU window to configure a BAR (in BAR). If there are multiple
>> functions, then this should also be modified since each function has 6 BARs.
>>
>> This can be fixed without much effort unless some other issue props up.
>
> Ok.
>
>>>
>>> Is your hardware able to make the PCIe endpoint look like
>>> a device with multiple PCI functions, or would one have to
>>> do this in software inside of a single PCI function if we
>>> ever need it?
>>
>> The hardware I have doesn't support multiple PCI functions (like having a
>> separate configuration space for each function). It has a dedicated space for
>> configuration space supporting only one function. [Section 24.9.7.3.2
>> PCIe_SS_EP_CFG_DBICS Register Description in [1]].
>>
>> yeah, it has to be done in software (but that won't be multi-function device
>> in
>> PCI terms).
>>
>> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
>
> Ok, so in theory there can be other hardware (and quite likely is)
> that supports multiple functions, and we can extend the framework
> to support them without major obstacles, but your hardware doesn't,
> so you kept it simple with one hardcoded function, right?
right, PCIe can have upto 8 functions. So the issues with the current framework
has to be fixed. I don't expect major obstacles with this as of now.
>
> Seems completely reasonable to me.
>
TODO:
*) access buffers in RC
*) raise MSI interrupts
*) Enable user space control for the RC side PCI driver
>>>
>>> The user space control would end up just being one of several
>>> gadget drivers, right? E.g. gadget drivers for standard hardware
>>> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
>>> drivers while a user space driver can be used for things that
>>> are more unusual and that don't need to interface to another
>>> part of the kernel?
>>
>> Actually I didn't mean that. It was more with respect to the host side PCI
>> test
>> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
>> itself. I wanted to change this so that the user controls which tests to run.
>> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
>> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
>> to perform various PCI tests.
>
> Ok, I see. So what I described above would be yet another function
> driver that can be implemented, but so far, you have not planned
> to do that because there was not need, right?
right. I felt pci_endpoint_test is the generic function that would be of
interest to all the vendors. Any new function can be added by taking
pci_end
[PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
From: Liav Rehana
During the calculation of the nsec variable in the inline function
timekeeping_delta_to_ns, it may undergo a sign extension if its msb
is set just before the shift. The sign extension may, in some cases,
gain it a value near the maximum value of the 64-bit range. This is
bad when it is later used in a division function, such as
__iter_div_u64_rem, where the amount of loops it will go through to
calculate the division will be too large.
The following commit fixes that chance of sign extension, while
maintaining the type of the nsec variable as signed for other
functions that use this variable, for possible legit negative
time intervals.
Signed-off-by: Liav Rehana
---
kernel/time/timekeeping.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 479d25c..f2c0067 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -299,10 +299,10 @@ u32 (*arch_gettimeoffset)(void) =
default_arch_gettimeoffset;
static inline u32 arch_gettimeoffset(void) { return 0; }
#endif
-static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
+static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
cycle_t delta)
{
- s64 nsec;
+ u64 nsec;
nsec = delta * tkr->mult + tkr->xtime_nsec;
nsec >>= tkr->shift;
--
1.7.1
Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
On Sun, Sep 25, 2016 at 10:45 PM, Liav Rehana wrote: > From: Liav Rehana > > During the calculation of the nsec variable in the inline function > timekeeping_delta_to_ns, it may undergo a sign extension if its msb > is set just before the shift. The sign extension may, in some cases, > gain it a value near the maximum value of the 64-bit range. This is > bad when it is later used in a division function, such as > __iter_div_u64_rem, where the amount of loops it will go through to > calculate the division will be too large. > The following commit fixes that chance of sign extension, while > maintaining the type of the nsec variable as signed for other > functions that use this variable, for possible legit negative > time intervals. Apologies for my foggy memory here (just got off a plane). But remind me, is this something that you actually ran into, or is it more of just a theoretical concern? If it is something that you did trip on, please describe your case in the changelog so that the proper urgency is applied when weighing if such a commit should go into -stable. thanks -john
Re: [PATCH v2 1/2] i2c: octeon: thunderx: Check bus state before starting a transaction
On Sat, Sep 24, 2016 at 11:24:19AM +0200, Wolfram Sang wrote: > On Fri, Sep 23, 2016 at 11:40:38AM +0200, Jan Glauber wrote: > > Add an additional status check before starting a transaction. If the > > check fails wait for some time to tolerate multi-master mode. After the > > timeout expires trigger the recovery. > > > > Signed-off-by: Jan Glauber > > Need to think more about it, needs to wait for next cycle. > OK, please share your thoughts when you get to it. --Jan
RE: [PATCH 1/3] megaraid_sas: mark symbols static where possible
>-Original Message-
>From: Baoyou Xie [mailto:baoyou@linaro.org]
>Sent: Sunday, September 25, 2016 11:21 AM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@avagotech.com; linux-s...@vger.kernel.org; linux-
>ker...@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
>xie.bao...@zte.com.cn
>Subject: [PATCH 1/3] megaraid_sas: mark symbols static where possible
>
>We get a few warnings when building kernel with W=1:
>drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no previous
prototype
>for 'mega_mod64' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no previous
prototype
>for 'mega_div64_32' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:177:6: warning: no previous
prototype
>for 'MR_PopulateDrvRaidMap' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:315:5: warning: no previous
prototype
>for 'MR_GetSpanBlock' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:451:5: warning: no previous
prototype
>for 'mr_spanset_get_span_block' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:692:4: warning: no previous
prototype
>for 'get_arm' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:815:4: warning: no previous
prototype
>for 'MR_GetPhyParams' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fp.c:1293:4: warning: no previous
>prototype for 'megasas_get_best_arm_pd' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:106:1: warning: no previous
>prototype for 'megasas_enable_intr_fusion' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:127:1: warning: no previous
>prototype for 'megasas_disable_intr_fusion' [-Wmissing-prototypes]
>
>In fact, these functions are only used in the file in which they are
declared and
>don't need a declaration, but can be made static.
>so this patch marks these functions with 'static'.
>
>Signed-off-by: Baoyou Xie
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++--
> drivers/scsi/megaraid/megaraid_sas_fp.c | 30 ++---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 52
+++--
> 3 files changed, 48 insertions(+), 40 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c236c4d..1b033da 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -209,7 +209,7 @@ static int megasas_get_ld_vf_affiliation(struct
>megasas_instance *instance, int megasas_check_mpio_paths(struct
>megasas_instance *instance,
>struct scsi_cmnd *scmd);
>
>-int
>+static int
> megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd
>*cmd) {
> instance->instancet->fire_cmd(instance,
>@@ -2057,7 +2057,7 @@ megasas_internal_reset_defer_cmds(struct
>megasas_instance *instance); static void
process_fw_state_change_wq(struct
>work_struct *work);
>
>-void megasas_do_ocr(struct megasas_instance *instance)
>+static void megasas_do_ocr(struct megasas_instance *instance)
> {
> if ((instance->pdev->device == PCI_DEVICE_ID_LSI_SAS1064R) ||
> (instance->pdev->device == PCI_DEVICE_ID_DELL_PERC5) || @@ -
>3981,7 +3981,7 @@ int megasas_alloc_cmds(struct megasas_instance
*instance)
> * Return 0 for only Fusion adapter, if driver load/unload is not in
progress
> * or FW is not under OCR.
> */
>-inline int
>+static inline int
> dcmd_timeout_ocr_possible(struct megasas_instance *instance) {
>
> if (!instance->ctrl_context)
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
>b/drivers/scsi/megaraid/megaraid_sas_fp.c
>index e413113..d22bb59 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
>@@ -91,7 +91,7 @@ static u8 mr_spanset_get_phy_params(struct
>megasas_instance *instance, u32 ld, static u64 get_row_from_strip(struct
>megasas_instance *instance, u32 ld,
> u64 strip, struct MR_DRV_RAID_MAP_ALL *map);
>
>-u32 mega_mod64(u64 dividend, u32 divisor)
>+static u32 mega_mod64(u64 dividend, u32 divisor)
> {
> u64 d;
> u32 remainder;
>@@ -109,7 +109,7 @@ u32 mega_mod64(u64 dividend, u32 divisor)
> *
> * @return quotient
> **/
>-u64 mega_div64_32(uint64_t dividend, uint32_t divisor)
>+static u64 mega_div64_32(uint64_t dividend, uint32_t divisor)
> {
> u32 remainder;
> u64 d;
>@@ -174,7 +174,7 @@ static struct MR_LD_SPAN *MR_LdSpanPtrGet(u32 ld,
>u32 span,
> /*
> * This function will Populate Driver Map using firmware raid map
> */
>-void MR_PopulateDrvRaidMap(struct megasas_instance *instance)
>+static void MR_PopulateDrvRaidMap(struct megasas_instance *instance)
> {
> struct fusion_context *fusion = instance->ctrl_context;
> struct MR_FW_RAID_MAP_ALL *fw_map_old= NULL;
>@@ -312,8 +312,8 @@ u8 MR_ValidateMap
Re: [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
Hi Philipp, 2016-09-20 19:44 GMT+09:00 Philipp Zabel : > Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada: >> Hi Philipp, >> >> >> 2016-09-20 16:30 GMT+09:00 Philipp Zabel : >> > Hi Masahiro, >> > >> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada: >> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been >> >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig. >> >> >> >> Signed-off-by: Masahiro Yamada >> >> --- >> >> >> >> Philipp, >> >> >> >> IIRC, you mentioned that you were planning to consolidate the double >> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER. >> >> >> >> I have not seen it in the ML, so I am sending this. >> >> >> >> Please let me know if you have some updates. >> > >> > I had started to doodle a bit, see >> > >> > git fetch git://git.pengutronix.de/git/pza/linux.git >> > refs/heads/reset/kconfig >> > >> > but I haven't found time for cleanup and testing. >> >> >> OK, I will merge this patch for now. >> >> >> >> BTW, I did not understand some of your commits under way. >> >> >> commit 7fe911f9c83737449565db03bebf953d3d94bbbf >> Author: Philipp Zabel >> Date: Tue Aug 9 11:18:51 2016 +0200 >> >> dmaengine: sunx6i: do not depend on reset controller framework >> >> The reset controller framework provides inline function stubs if >> disabled. >> >> Signed-off-by: Philipp Zabel >> >> >> >> >> >> As far as I see from drivers/dma/sun6i-dma.c, >> the reset control is mandatory for this driver. >> >> Why are you removing the dependency? >> >> >> Don't you care if it works on run-time >> as long as it can build? > > I have not thought about this too hard, it's just there because the > reset framework is not a build dependency (anymore). Some patches were > necessary to remove dependency loops, but I think this one could just be > dropped. I have not taken a close look at it, but if "dependency loops" is the reason for the change, please mention it in the git-log. I do not think we should remove the "depends on" only for the reason "inline function stubs are already provided". -- Best Regards Masahiro Yamada
Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)
Andrey Utkin writes: > On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote: >> I wonder if the following fixes the problem (completely untested). > > I have given this a run, and it still hangs. Does (only) adding the pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val); in solo_reg_write() help? -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
drivers/iio/pressure/bmp280-core.c:985: undefined reference to `devm_gpiod_get'
Hi Linus, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 08895a8b6b06ed2323cd97a36ee40a116b3db8ed commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on UM date: 5 weeks ago config: um-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc935): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoaddr': (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametonetaddr': (.text+0x1d465): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoproto': (.text+0x1d685): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoport': (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking drivers/built-in.o: In function `fwnode_get_named_gpiod': drivers/gpio/gpiolib.c:3215: undefined reference to `of_get_named_gpiod_flags' drivers/built-in.o: In function `gpiod_get_index': drivers/gpio/gpiolib.c:3140: undefined reference to `of_get_named_gpiod_flags' drivers/built-in.o: In function `bgpio_map': drivers/gpio/gpio-mmio.c:571: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `dwapb_gpio_probe': drivers/gpio/gpio-dwapb.c:554: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `zx_gpio_probe': drivers/gpio/gpio-zx.c:229: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `lp872x_probe': drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one' drivers/regulator/lp872x.c:746: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `max8952_pmic_probe': drivers/regulator/max8952.c:249: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `max8973_probe': drivers/regulator/max8973-regulator.c:715: undefined reference to `devm_gpio_request_one' drivers/regulator/max8973-regulator.c:770: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `pwm_regulator_probe': drivers/regulator/pwm-regulator.c:387: undefined reference to `devm_gpiod_get_optional' drivers/built-in.o: In function `tps62360_probe': drivers/regulator/tps62360-regulator.c:433: undefined reference to `devm_gpio_request_one' drivers/regulator/tps62360-regulator.c:444: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `fdp_nci_i2c_probe': drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get' drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev': drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free' drivers/built-in.o: In function `nfcmrvl_nci_register_dev': drivers/nfc/nfcmrvl/main.c:127: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `st21nfca_hci_i2c_probe': drivers/nfc/st21nfca/i2c.c:597: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `st_nci_i2c_probe': drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `nxp_nci_i2c_probe': drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one' drivers/built-in.o: In function `mdio_gpio_probe': drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request' drivers/built-in.o: In function `at803x_probe': drivers/net/phy/at803x.c:283: undefined reference to `devm_gpiod_get_optional' drivers/built-in.o: In function `xgene_mdio_probe': dri
Re: [PATCH 0/2] NFS: Use complete() instead complete_all()
Hi Anna, On 09/23/2016 03:48 PM, Anna Schumaker wrote: Besides trying to analys all the code paths to the wait_for_completion() call and convince myself that there is only one waiter, I also run a few tests: - some fio benchmarks - pynfs -cthon04 Thanks for the patches, and for the extensive testing! I haven't tried them with xfstests yet, but They look okay to me otherwise. Assuming I don't see any new failures there I'll plan on adding them for v4.9. I tried a few tests from xfstests but I was not sure which make sense to run, that's why I went for the more NFS specific tests. I'll see what happens when I run the generic tests from xfstests. Should all of them pass? cheers, daniel
Re: [RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not
On 23-09-16, 15:07, Dave Gerlach wrote:
> The OPP framework allows each OPP to set a opp-supported-hw property
> which provides values that are matched against supported_hw values
> provided by the platform to limit support for certain OPPs on specific
> hardware. Currently, if the platform does not set supported_hw values,
> all OPPs are interpreted as supported, even if they have provided their
> own opp-supported-hw values.
>
> If an OPP has provided opp-supported-hw, it is indicating that there is
> some specific hardware configuration it is supported by. These constraints
> should be honored, and if no supported_hw has been provided by the
> platform, there is no way to determine if that OPP is actually supported,
> so it should be marked as not supported.
>
> Signed-off-by: Dave Gerlach
> ---
> drivers/base/power/opp/of.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
> index 1dfd3dd92624..af9f8968 100644
> --- a/drivers/base/power/opp/of.c
> +++ b/drivers/base/power/opp/of.c
> @@ -71,8 +71,18 @@ static bool _opp_is_supported(struct device *dev, struct
> opp_table *opp_table,
> u32 version;
> int ret;
>
> - if (!opp_table->supported_hw)
> - return true;
> + if (!opp_table->supported_hw) {
> + /*
> + * In the case that no supported_hw has been set by the
> + * platform but there is an opp-supported-hw value set for
> + * an OPP then the OPP should not be enabled as there is
> + * no way to see if the hardware supports it.
> + */
> + if (of_find_property(np, "opp-supported-hw", NULL))
> + return false;
> + else
> + return true;
> + }
>
> while (count--) {
> ret = of_property_read_u32_index(np, "opp-supported-hw", count,
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 09/12] x86/process: Pin the target stack in get_wchan()
On Fri, Sep 23, 2016 at 08:34:43PM +0200, Jann Horn wrote: > On Fri, Sep 23, 2016 at 11:28:26AM -0700, Kees Cook wrote: > > Does CRIU use this? I wouldn't expect so, since they're using ptrace, > > IIUC, to freeze/restore. > > As far as I can tell: > > parse_pid_stat() parses them into a struct proc_pid_stat as "esp" and "eip", > but those struct members are never used (like, probably, most other members > of that struct). Yes, that's my reading of it too. > child_opened_proc.c just opens /proc/%d/stat and then closes it again > immediately. This is just a test for ordering of things that are restored, and it could use any file in /proc, stat was just convenient. > So in summary: I don't think so. Yep, agreed. Tycho
Re: [PATCH 2/2] PM / OPP: Multiple regulators aren't supported yet
On 23-09-16, 14:59, Rob Herring wrote:
> On Wed, Sep 21, 2016 at 03:02:50PM +0530, Viresh Kumar wrote:
> > Multiple regulators per device aren't supported yet by the kernel code
> > and the bindings provided in documentation aren't sufficient to handle
> > that case (as there is no way for kernel code to link multiple
> > voltage/current values to a power supply).
>
> What do you mean? Because the supplies are in the cpu node?
Not just that. For example if two supplies are present in CPU node like:
ABC-supply and XYZ-supply. And the values present in OPP node are like:
opp00 {
opp-hz = /bits/ 64 <17>;
/* ABC supplyXYZ
supply */
opp-microvolt = <130 130 130>, <140
140 140>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
Then the code can get regulators with those names (ABC and XYZ), but it can't
figure out which triplet in the "opp-microvolt" property belongs to which
supply.
I am working on some solution to that, but wanted to keep the entire series self
sufficient and so removing the leftovers first in this patch.
--
viresh
Re: [PATCH] phy: meson-usb2: Fix build dependency
On Wednesday 21 September 2016 09:43 AM, Axel Lin wrote: > 2016-09-21 12:06 GMT+08:00 Kishon Vijay Abraham I : >> >> >> On Monday 19 September 2016 10:14 PM, Kevin Hilman wrote: >>> Martin Blumenstingl writes: >>> Hi Axel, On Fri, Sep 16, 2016 at 4:07 AM, Axel Lin wrote: > of_usb_get_dr_mode_by_phy will not be compiled if !USB_COMMON, fix below > build error: > > drivers/built-in.o: In function `phy_meson_usb2_probe': > debugfs.c:(.text+0x76b4): undefined reference to > `of_usb_get_dr_mode_by_phy' > Makefile:961: recipe for target 'vmlinux' failed > make: *** [vmlinux] Error 1 > > Signed-off-by: Axel Lin > --- > drivers/phy/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 6ad87ec..cc27c12 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -458,6 +458,8 @@ config PHY_MESON_USB2 > tristate "Meson USB2 PHY driver" > default ARCH_MESON > depends on OF && (ARCH_MESON || COMPILE_TEST) > + depends on USB_SUPPORT > + select USB_COMMON > select GENERIC_PHY > help > Enable this to support the Meson USB2 PHYs found in Meson8b > -- > 2.7.4 > thanks for this patch! How do we handle patches for drivers which will (unfortunately) not land in the linux 4.8 - should I integrate that into v3 of the patch (which I'll have to send anyways) or do we keep them separate? Maybe Kishon and/or Kevin can share their opinion on this. >> >> Since you are anyways planning to send v3, merge this patch too. > > I got confused why this driver appears in linux-next but it's not from phy > tree? I thought it's because other dependency so it needs to go via other > tree, > but looks like not the case. And the driver does not get Kishon's Ack? > > BTW, Kishon, do you consider to add phy tree to linux-next? yes.. that's been pending for a long time. -Kishon
Re: [PATCH 1/2] PM / OPP: compatible is an optional property
On 23-09-16, 14:55, Rob Herring wrote: > On Fri, Sep 23, 2016 at 10:45:26AM +0530, Viresh Kumar wrote: > > On 22-09-16, 12:24, Stephen Boyd wrote: > > > On 09/21/2016 02:32 AM, Viresh Kumar wrote: > > > > It was never compulsory to have a compatible string in the OPP table. > > > > Fix the documentation to mark it optional. > > > > > > NAK. > > > > > Also update its description a bit. > > > > > > > > Signed-off-by: Viresh Kumar > > > > --- > > > > > > Why? I'd prefer the compatible string to be required so we know what > > > sort of node it is. > > Agreed. > > > Okay, the code doesn't have any checks for it then and that needs to be > > fixed. > > Why? The kernel is not a DT validator. Hmm.. I thought it should be checking if it can parse those bindings or not. What if someone adds compatible property as "foo" for OPP node? Should the OPP code even try to parse it? > > Just for my clarity, for platforms with special OPP bindings and so a > > different > > compatible string like: "operating-points-v2-XYZ", should the compatible > > string > > contain both "operating-points-v2" and the above one? It would be easier to > > check for "operating-points-v2" in that case from core code. > > That would imply operating-points-v2-XYZ has extra properties or is > different in some way. If an OS only understanding operating-points-v2 > will work, then yes it should have both. If not, then no. Well, in this case that can't be done fully, so we should have only the -xyz one. Got it, thanks. -- viresh
Re: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
On 12-09-16, 14:55, Stephen Boyd wrote:
> On 08/29, Viresh Kumar wrote:
> > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > + struct cpufreq_frequency_table *table,
> > > + int volt)
> > > +{
> > > + struct opp_table *opp_table;
> > > + struct cpufreq_frequency_table *pos;
> > > + struct dev_pm_opp *opp;
> > > +
> > > + if (!volt)
> > > + return 0;
> > > +
> > > + rcu_read_lock();
> > > +
> > > + opp_table = _find_opp_table(cpu_dev);
> > > + if (IS_ERR(opp_table)) {
> > > + rcu_read_unlock();
> > > + return PTR_ERR(opp_table);
> > > + }
> > > +
> > > + cpufreq_for_each_valid_entry(pos, table) {
> > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > + true);
> > > + if (IS_ERR(opp))
> > > + continue;
> > > +
> > > + opp->u_volt += volt;
> > > + opp->u_volt_min += volt;
> > > + opp->u_volt_max += volt;
> > > + }
> > > +
> > > + rcu_read_unlock();
> > > +
> > > + return 0;
> > > +}
> >
> > I wouldn't prefer altering the opp tables from individual drivers at all.
> > At the
> > least, it should be done via some helpers exposed by the core.
> >
> > But before that I would like to hear from Stephen a bit as I recall he was
> > also
> > working on something similar.
> >
>
> I had a patch to modify the voltage at runtime for the "current"
> OPP. Now that we have regulator and clk control inside OPP that
> became a little easier to do without having to do some notifier
> from the OPP layer to the consumers. I haven't had time to revive
> those patches though. Should we do that?
Perhaps yes, we should have a common place for doing all that.
> Does this need to modify
> anything besides the OPP the device is currently running at?
Finlye, can you please answer this ?
--
viresh
Re: [PATCH 2/3] g_NCR5380: Reduce overrides[] from array to struct
On Sat, 24 Sep 2016, Ondrej Zary wrote: > Remove compile-time card type definition GENERIC_NCR5380_OVERRIDE. Then > remove all code iterating the overrides[] array and reduce it to struct > card. There is a reference to the compile-time override in Documentation/scsi/g_NCR5380.txt which needs to be removed also. The patch looks fine aside from that. --
Re: [PATCH] cpufreq: st: add missing \n to end of dev_err message
On 25-09-16, 14:40, Colin King wrote:
> From: Colin Ian King
>
> Trival fix, dev_err message is missing a \n, so add it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/cpufreq/sti-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> index 0404203..b366e6d 100644
> --- a/drivers/cpufreq/sti-cpufreq.c
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -163,7 +163,7 @@ static int sti_cpufreq_set_opp_info(void)
>
> reg_fields = sti_cpufreq_match();
> if (!reg_fields) {
> - dev_err(dev, "This SoC doesn't support voltage scaling");
> + dev_err(dev, "This SoC doesn't support voltage scaling\n");
> return -ENODEV;
> }
>
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH] cpufreq: kirkwood: add missing \n to end of dev_err messages
On 25-09-16, 14:35, Colin King wrote:
> From: Colin Ian King
>
> Trival fix, dev_err messages are missing a \n, so add it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/cpufreq/kirkwood-cpufreq.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index be42f10..1b9bcd7 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -123,7 +123,7 @@ static int kirkwood_cpufreq_probe(struct platform_device
> *pdev)
>
> priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
> if (IS_ERR(priv.cpu_clk)) {
> - dev_err(priv.dev, "Unable to get cpuclk");
> + dev_err(priv.dev, "Unable to get cpuclk\n");
> return PTR_ERR(priv.cpu_clk);
> }
>
> @@ -132,7 +132,7 @@ static int kirkwood_cpufreq_probe(struct platform_device
> *pdev)
>
> priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");
> if (IS_ERR(priv.ddr_clk)) {
> - dev_err(priv.dev, "Unable to get ddrclk");
> + dev_err(priv.dev, "Unable to get ddrclk\n");
> err = PTR_ERR(priv.ddr_clk);
> goto out_cpu;
> }
> @@ -142,7 +142,7 @@ static int kirkwood_cpufreq_probe(struct platform_device
> *pdev)
>
> priv.powersave_clk = of_clk_get_by_name(np, "powersave");
> if (IS_ERR(priv.powersave_clk)) {
> - dev_err(priv.dev, "Unable to get powersave");
> + dev_err(priv.dev, "Unable to get powersave\n");
> err = PTR_ERR(priv.powersave_clk);
> goto out_ddr;
> }
> @@ -155,7 +155,7 @@ static int kirkwood_cpufreq_probe(struct platform_device
> *pdev)
> if (!err)
> return 0;
>
> - dev_err(priv.dev, "Failed to register cpufreq driver");
> + dev_err(priv.dev, "Failed to register cpufreq driver\n");
>
> clk_disable_unprepare(priv.powersave_clk);
> out_ddr:
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH] net: smc91x: take into account register shift
From: Robert Jarzmik Date: Sun, 25 Sep 2016 23:00:45 +0200 > This aligns smc91x with its cousin, namely smc911x.c. > This also allows the driver to run also in a device-tree based lubbock > board build, on which it was tested. > > Signed-off-by: Robert Jarzmik Applied to net-next, thanks.
Re: [PATCH][V2] cxgb4: fix -ve error check on a signed iq
From: Colin King Date: Sun, 25 Sep 2016 14:14:45 -0700 > From: Colin Ian King > > iq is unsigned, so the error check for iq < 0 has no effect so errors > can slip past this check. Fix this by making iq signed and also > get_filter_steerq return a signed int so a -ve error can be returned. > > Signed-off-by: Colin Ian King Applied, thanks.
[PATCH v2] Staging: android: fixed permissions style issue
Fixed a coding style issue. Changed symbolic permissions to octal. Signed-off-by: Eric Salem --- drivers/staging/android/lowmemorykiller.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index 80d7adf..ec3b665 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -204,10 +204,9 @@ device_initcall(lowmem_init); * not really modular, but the easiest way to keep compat with existing * bootargs behaviour is to continue using module_param here. */ -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR); -module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, -S_IRUGO | S_IWUSR); +module_param_named(cost, lowmem_shrinker.seeks, int, 0644); +module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, 0644); module_param_array_named(minfree, lowmem_minfree, uint, &lowmem_minfree_size, -S_IRUGO | S_IWUSR); -module_param_named(debug_level, lowmem_debug_level, uint, S_IRUGO | S_IWUSR); +0644); +module_param_named(debug_level, lowmem_debug_level, uint, 0644); -- 2.7.4 On 09/25/2016 10:00 PM, Joe Perches wrote: > On Sun, 2016-09-25 at 21:47 -0500, Eric Salem wrote: >> Fixed a coding style issue. Changed symbolic permissions to octal. > > If you do these, please shorten the lines where possible. > >> diff --git a/drivers/staging/android/lowmemorykiller.c >> b/drivers/staging/android/lowmemorykiller.c > [] >> @@ -204,10 +204,10 @@ device_initcall(lowmem_init); >> * not really modular, but the easiest way to keep compat with existing >> * bootargs behaviour is to continue using module_param here. >> */ >> -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR); >> +module_param_named(cost, lowmem_shrinker.seeks, int, 0644); >> module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, >> - S_IRUGO | S_IWUSR); >> + 0644); > > module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, 0644); > > etc... >
Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-16 18:16:05)
> > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > we need to change this mux to forward the D+/D- lines to either
> > > > the port or the hub. Therefore, introduce a driver for this
> > > > device that intercepts extcon USB_HOST events and logically
> > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > attached. When the cable goes away, it will logically deassert
> > > > the gpio and mux the "device" lines.
> > > >
> > > > [1]
> > > > https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > >
> > > > Cc: MyungJoo Ham
> > > > Cc: Chanwoo Choi
> > > > Cc:
> > > > Signed-off-by: Stephen Boyd
> > > > ---
> > > >
> > > > Should I make the extcon part optional? I could see a case where there
> > > > are two
> > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > software may want to mux between them at runtime. If we mandate an
> > > > extcon,
> > > > that won't be possible to support. Perhaps it would be better to have
> > > > the node, but connect it to the usb controller with a phandle (maybe
> > > > of_graph
> > > > endpoints would be useful too) so that when the controller wants to mux
> > > > over
> > > > a port it can do so.
> > >
> > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > haven't written any code around it, but the idea is to allow the binding
> > > to specify how the mux is connected to upstream and downstream D+/D-
> > > lines. This way, we can do some dt parsing of the endpoints and their
> > > parent nodes to figure out if the mux needs to be set high or low to use
> > > a device connector or a usb hub based on if the id cable is present.
> > > Maybe I'm over thinking things though and we could just have a DT
> > > property for that.
> > >
> > > soc {
> > > usb@78d9000 {
> > > extcon = <&usb_id>, <&usb_id>;
> >
> > Why you have two same extcon phandler? From my mind, one should id,
> > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > vbus support, how you support vbus detection for
> > connection/disconnection with PC for your chipidea msm patch set?
>
> This was already in the dts files for db410c. In the chipidea binding
> one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> that great on this board because we only have on gpio for this.
I think extcon-usb-gpio.c needs to extend for supporting vbus event,
otherwise, the micro-b cable's connect/disconnect will introduce
EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
vbus event.
--
Best Regards,
Peter Chen
Re: [PATCH 3/3] g_NCR5380: Stop using scsi_module.c
On Sat, 24 Sep 2016, Ondrej Zary wrote:
> Convert g_NCR5380 to use scsi_add_host instead of scsi_module.c
> Use pnp_driver and isa_driver to manage cards.
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/g_NCR5380.c | 310
> +-
> drivers/scsi/g_NCR5380.h |8 --
> 2 files changed, 169 insertions(+), 149 deletions(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 5162de6..6cf6b00 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -30,24 +30,25 @@
> #include "NCR5380.h"
> #include
> #include
> -#include
> +#include
> +#include
> #include
>
> -static int ncr_irq;
> -static int ncr_dma;
> -static int ncr_addr;
> -static int ncr_5380;
> -static int ncr_53c400;
> -static int ncr_53c400a;
> -static int dtc_3181e;
> -static int hp_c2502;
> -
> -static struct card {
> - NCR5380_map_type NCR5380_map_name;
> - int irq;
> - int dma;
> - int board; /* Use NCR53c400, Ricoh, etc. extensions ? */
> -} card;
> +#define MAX_CARDS 8
> +
> +static int irq[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +module_param_array(irq, int, NULL, 0);
> +MODULE_PARM_DESC(irq, "IRQ number(s)");
> +
> +static int base[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +module_param_array(base, int, NULL, 0);
> +MODULE_PARM_DESC(base, "base address(es)");
> +
> +static int card[] = { -1, -1, -1, -1, -1, -1, -1, -1 };
> +module_param_array(card, int, NULL, 0);
> +MODULE_PARM_DESC(card, "card type (0=NCR5380, 1=NCR53C400, 2=NCR53C400A,
> 3=DTC3181E, 4=HP C2502)");
> +
> +MODULE_LICENSE("GPL");
If you are going to change all of the module parameters and break every
user's setup, at least explain what changed and why in the commit log and
update the documentation in the kernel tree.
If you really want to help those users (most of whom gain nothing from
this patch) you could also update the documentation elsewhere:
http://www.sane-project.org/man/sane-scsi.5.html
http://www.xsane.org/rauch-domain/sane-umax/sane-umax-config-doc.html
http://www.meier-geinitz.de/sane/mustek-backend/
I'm not in favour of this patch, but Christoph liked it so I'll leave it
at that.
>
> #ifndef SCSI_G_NCR5380_MEM
> /*
> @@ -73,17 +74,9 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
> }
> #endif
>
> -/**
> - * generic_NCR5380_detect - look for NCR5380 controllers
> - * @tpnt: the scsi template
> - *
> - * Scan for the present of NCR5380, NCR53C400, NCR53C400A, DTC3181E
> - * and DTC436(ISAPnP) controllers.
> - *
> - * Locks: none
> - */
> -
> -static int __init generic_NCR5380_detect(struct scsi_host_template *tpnt)
> +static struct Scsi_Host *generic_NCR5380_hw_init(
> + struct scsi_host_template *tpnt, struct device *pdev,
> + int base, int irq, int board)
This allocates and returns a Scsi_Host so the name is misleading.
But the name isn't the only problem; the real problem has already been
pointed out by Christoph: the caller needs the error code to be returned
not the Scsi_Host pointer.
> {
> unsigned int *ports;
> u8 *magic = NULL;
> @@ -108,64 +101,13 @@ static int __init generic_NCR5380_detect(struct
> scsi_host_template *tpnt)
> struct Scsi_Host *instance;
> struct NCR5380_hostdata *hostdata;
> #ifdef SCSI_G_NCR5380_MEM
> - unsigned long base;
> void __iomem *iomem;
> resource_size_t iomem_size;
> #endif
>
> - if (ncr_irq)
> - card.irq = ncr_irq;
> - if (ncr_dma)
> - card.dma = ncr_dma;
> - if (ncr_addr)
> - card.NCR5380_map_name = (NCR5380_map_type) ncr_addr;
> - if (ncr_5380)
> - card.board = BOARD_NCR5380;
> - else if (ncr_53c400)
> - card.board = BOARD_NCR53C400;
> - else if (ncr_53c400a)
> - card.board = BOARD_NCR53C400A;
> - else if (dtc_3181e)
> - card.board = BOARD_DTC3181E;
> - else if (hp_c2502)
> - card.board = BOARD_HP_C2502;
> -#ifndef SCSI_G_NCR5380_MEM
> - if (isapnp_present()) {
> - struct pnp_dev *dev = NULL;
> - while ((dev = pnp_find_dev(NULL, ISAPNP_VENDOR('D', 'T', 'C'),
> ISAPNP_FUNCTION(0x436e), dev))) {
> - if (pnp_device_attach(dev) < 0)
> - continue;
> - if (pnp_activate_dev(dev) < 0) {
> - printk(KERN_ERR "dtc436e probe: activate
> failed\n");
> - pnp_device_detach(dev);
> - continue;
> - }
> - if (!pnp_port_valid(dev, 0)) {
> - printk(KERN_ERR "dtc436e probe: no valid
> port\n");
> - pnp_device_detach(dev);
> - continue;
> - }
> - if (pnp_irq_valid(dev, 0))
> - card.irq = pnp_i
Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out
Shaohua Li writes: > On Fri, Sep 23, 2016 at 10:32:39AM +0800, Huang, Ying wrote: >> Rik van Riel writes: >> >> > On Thu, 2016-09-22 at 15:56 -0700, Shaohua Li wrote: >> >> On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote: >> >> >. >> >> > - It will help the memory fragmentation, especially when the THP is >> >> > . heavily used by the applications.. The 2M continuous pages will >> >> > be >> >> > . free up after THP swapping out. >> >> >> >> So this is impossible without THP swapin. While 2M swapout makes a >> >> lot of >> >> sense, I doubt 2M swapin is really useful. What kind of application >> >> is >> >> 'optimized' to do sequential memory access? >> > >> > I suspect a lot of this will depend on the ratio of storage >> > speed to CPU & RAM speed. >> > >> > When swapping to a spinning disk, it makes sense to avoid >> > extra memory use on swapin, and work in 4kB blocks. >> >> For spinning disk, the THP swap optimization will be turned off in >> current implementation. Because huge swap cluster allocation based on >> swap cluster management, which is available only for non-rotating block >> devices (blk_queue_nonrot()). > > For 2m swapin, as long as one byte is changed in the 2m, next time we must do > 2m swapout. There is huge waste of memory and IO bandwidth and increases > unnecessary memory pressure. 2M IO will very easily saturate a very fast SSD > and makes IO the bottleneck. Not sure about NVRAM though. One solution is to make 2M swapin configurable, maybe via a sysfs file in /sys/kernel/mm/transparent_hugepage/, so that we can turn on it only for really fast storage devices, such as NVRAM, etc. Best Regards, Huang, Ying
RE: [v12, 0/8] Fix eSDHC host version register bug
Any comments about this version patchset ?
:)
> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
>
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS| 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++
> drivers/clk/clk-qoriq.c| 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig| 2 +-
> drivers/soc/fsl/Kconfig| 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257
> +
> include/linux/fsl/guts.h | 125 ++
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h| 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-) rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
RE: [PATCH V1] regulator: pv88080: Update regulator for PV88080 BB silicon support
On September 25, 2016 3:23 AM, Mark Brown wrote:
> On Wed, Sep 21, 2016 at 01:44:39PM +0900, Eric Jeong wrote:
>
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id pv88080_dt_ids[] = {
> > + { .compatible = "pvs,pv88080-aa", .data = (void *)TYPE_PV88080_AA },
> > + { .compatible = "pvs,pv88080-ba", .data = (void *)TYPE_PV88080_BA },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, pv88080_dt_ids); #endif
>
> This doesn't list the old compatible string and therefore ends up breaking
> since the code defaults to assuming something it hasn't heard of is BB when
> it seems more likely that old DTs using the old compatible string will be for
> boards that also use the old silicon. It would be much better practice to
> explicitly list the old compatible string and how we handle it, that won't
> break
> in future and avoids this kind of error.
>
> Is it really not possible to read the chip revision from the device using ID
> registers? That'd be even better.
The address of ID register is different between each chip revision.
So, It is difficult to read the chip revision from the device using ID register.
And, I will send a patch with old compatible.
Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error
On Sun, Sep 25, 2016 at 7:25 PM, Dave Chinner wrote:
>> You have some nasty unicode corruption. The email is marked as being
>>
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>
> It's whatever git-send-email spat out. I was under the impression it
> encodes like that whenever it sees a utf-8 character in a commit...
Yes. But it assumes that the commit text was in UTF-8 too. So I
suspect it happened as you were writing the commit message:
> I turned off utf-8 support in vim on the machine I write all my code
> on
I guess that's probably it. You probably had vim try to convert it to
latin1 or something, and the odd utf-8 tick/back-tick thing doesn't do
so cleanly, so..
>- I got sick of stupid stray marks in my code, digraphs being
> composed when I just want to replace a single character, git sending
> patches in utf-8 encoding because I copied a SoB with a utf-8
> character in the name, etc
Hmm. Generally, the only place we should have non-us-ascii tensd to be
exactly those names. But a sane editor should "just work" and not do
odd crazy digraph crap or things like that. But I don't use vim, so I
don't know what the magic incantation for sanity there is.
> 7 characters, 12 characters, whatever. Neither make any sense in
> commit messages by themselves without the short description that
> goes along with the hash.
No, I agree, the right format for describing a commit tends to be
along the lines of
.. commit %h ("%s") ..
exactly like you did. It's just that with 12 characters in the hex
format, people will still be able to cut-and-paste the hash into git
to get the full commit details even a year from now. With just 7 hex
digits, you may well end up in the situation where you do
git show e23d415
and git says
error: short SHA1 e23d415 is ambiguous.
fatal: ambiguous argument 'e23d415': unknown revision or path not
in the working tree.
(it's not ambiguous today, but in a year or two it quite possibly will be).
It's not impossible to figure out the different possible ambiguous
commits, but it's just inconvenient.
Right now, of the roughly 618,000 commits in the mainline tree, about
98% can be uniquely represented with 7 hex digits. But about 2% o
commits need eight or more hex digits to be unique (the git ID space
includes all the tree and blob objects too, so the uniqueness is not
just "unique within commits", but any kernel git object).
Linus
Re: [PATCH] Staging: android: fixed permissions style issue
On Sun, 2016-09-25 at 21:47 -0500, Eric Salem wrote: > Fixed a coding style issue. Changed symbolic permissions to octal. If you do these, please shorten the lines where possible. > diff --git a/drivers/staging/android/lowmemorykiller.c > b/drivers/staging/android/lowmemorykiller.c [] > @@ -204,10 +204,10 @@ device_initcall(lowmem_init); > * not really modular, but the easiest way to keep compat with existing > * bootargs behaviour is to continue using module_param here. > */ > -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR); > +module_param_named(cost, lowmem_shrinker.seeks, int, 0644); > module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, > - S_IRUGO | S_IWUSR); > + 0644); module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, 0644); etc...
[PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"
This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
because the "fix" is bogus. That report descriptor is different in
hardware (see below) and it's the way the hardware works, it can't be
fixed at this level because it reuses axes by design.
What this change tried to fix is a regression caused by commit 20aef664f139
("HID: input: force generic axis to be mapped to their user space axis") by
working around the problem and trying to change the report descriptor in
hid-dr, which obviously can't work and introduces more breakage because it
adds another unnecessary layer of multiplexing/indirection, making the
dragonrise gamepad practically unusable in userspace.
This needs to be fixed where the regression was initially introduced in
hid-input (the next patch does this).
Here's the descriptor taken directly from the device via lsusb:
HID Device Descriptor:
bLength 9
bDescriptorType33
bcdHID 1.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType34 Report
wDescriptorLength 101
Report Descriptor: (length is 101)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x04 ] 4
Joystick
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Main ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x05 ] 5
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x35 ] 53
Rotate-Z
Item(Main ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Global): Report Size, data= [ 0x04 ] 4
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Global): Logical Maximum, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
Item(Global): Unit, data= [ 0x14 ] 20
System: English Rotation, Unit: Degrees
Item(Local ): Usage, data= [ 0x39 ] 57
Hat Switch
Item(Main ): Input, data= [ 0x42 ] 66
Data Variable Absolute No_Wrap Linear
Preferred_State Null_State Non_Volatile Bitfield
Item(Global): Unit, data= [ 0x00 ] 0
System: None, Unit: (None)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x0c ] 12
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Global): Usage Page, data= [ 0x09 ] 9
Buttons
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
Button 1 (Primary)
Item(Local ): Usage Maximum, data= [ 0x0c ] 12
(null)
Item(Main ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
(null)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Main ): End Collection, data=none
Item(Main ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 0xf
[PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise
Commit 79346d620e9d ("HID: input: force generic axis to be mapped to their
user space axis") made mapping generic axes to their userspace equivalents
mandatory and some lower end gamepads which were depending on the previous
behaviour suffered severe regressions because they were reusing axes and
expecting hid-input to multiplex their map to the respective userspace axis
by always searching for and using the next available axis.
Now the result is that different device axes appear on a single axis in
userspace, which is clearly a regression in the hid-input driver because it
needs to continue to handle this hardware as expected before the forcing
to provide the same interface to userspace.
Since these lower-end gamepads like 0079:0006 are definitely the exception,
create a quirk to fix them.
Signed-off-by: Ioan-Adrian Ratiu
---
drivers/hid/hid-dr.c| 2 ++
drivers/hid/hid-input.c | 16 +++-
include/linux/hid.h | 1 +
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-dr.c b/drivers/hid/hid-dr.c
index 2523f8a..27fc826 100644
--- a/drivers/hid/hid-dr.c
+++ b/drivers/hid/hid-dr.c
@@ -274,6 +274,8 @@ static int dr_probe(struct hid_device *hdev, const struct
hid_device_id *id)
hid_hw_stop(hdev);
goto err;
}
+ /* has only 5 axes and reuses X, Y */
+ hdev->quirks |= HID_QUIRK_REUSE_AXES;
break;
}
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index fb9ace1..1cc6fe4 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -633,11 +633,17 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
/* These usage IDs map directly to the usage codes. */
case HID_GD_X: case HID_GD_Y: case HID_GD_Z:
case HID_GD_RX: case HID_GD_RY: case HID_GD_RZ:
- if (field->flags & HID_MAIN_ITEM_RELATIVE)
- map_rel(usage->hid & 0xf);
- else
- map_abs_clear(usage->hid & 0xf);
- break;
+
+ /* if quirk is active don't force the userspace mapping,
+* instead search and use the next available axis.
+*/
+ if (!(device->quirks & HID_QUIRK_REUSE_AXES)) {
+ if (field->flags & HID_MAIN_ITEM_RELATIVE)
+ map_rel(usage->hid & 0xf);
+ else
+ map_abs_clear(usage->hid & 0xf);
+ break;
+ }
case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 75b66ec..0979920 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -320,6 +320,7 @@ struct hid_item {
#define HID_QUIRK_NO_EMPTY_INPUT 0x0100
#define HID_QUIRK_NO_INIT_INPUT_REPORTS0x0200
#define HID_QUIRK_ALWAYS_POLL 0x0400
+#define HID_QUIRK_REUSE_AXES 0x0800
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x0001
#define HID_QUIRK_SKIP_OUTPUT_REPORT_ID0x0002
#define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x0004
--
2.10.0
Re: [PATCH v2 1/1] mm/hugetlb: fix memory offline with hugepage size > memory block size
On 9/23/16 7:03 PM, Gerald Schaefer wrote:
On Fri, 23 Sep 2016 14:40:33 +0800
Rui Teng wrote:
On 9/22/16 5:51 PM, Michal Hocko wrote:
On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb page
with a size > memory block size.
When no other smaller hugetlb page sizes are present, the VM_BUG_ON()
will trigger directly. In the other case we will run into an addressing
exception later, because dissolve_free_huge_page() will not work on the
head page of the compound hugetlb page which will result in a NULL
hstate from page_hstate().
To fix this, first remove the VM_BUG_ON() because it is wrong, and then
use the compound head page in dissolve_free_huge_page().
OK so dissolve_free_huge_page will work also on tail pages now which
makes some sense. I would appreciate also few words why do we want to
sacrifice something as precious as gigantic page rather than fail the
page block offline. Dave pointed out dim offline usecase for example.
Also change locking in dissolve_free_huge_page(), so that it only takes
the lock when actually removing a hugepage.
From a quick look it seems this has been broken since introduced by
c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle
hugepage"). Do we want to have this backported to stable? In any way
Fixes: SHA1 would be really nice.
If the huge page hot-plug function was introduced by c8721bbbdd36, and
it has already indicated that the gigantic page is not supported:
"As for larger hugepages (1GB for x86_64), it's not easy to do
hotremove over them because it's larger than memory block. So
we now simply leave it to fail as it is."
Is it possible that the gigantic page hot-plugin has never been
supported?
Offlining blocks with gigantic pages only fails when they are in-use,
I guess that was meant by the description. Maybe it was also meant to
fail in any case, but that was not was the patch did.
With free gigantic pages, it looks like it only ever worked when
offlining the first block of a gigantic page. And as long as you only
have gigantic pages, the VM_BUG_ON() would actually have triggered on
every block that is not gigantic-page-aligned, even if the block is not
part of any gigantic page at all.
I have not met the VM_BUG_ON() issue on my powerpc architecture. Seems
it does not always have the align issue on other architectures.
Given the age of the patch it is a little bit surprising that it never
struck anyone, and that we now have found it on two architectures at
once :-)
I made another patch for this problem, and also tried to apply the
first version of this patch on my system too. But they only postpone
the error happened. The HugePages_Free will be changed from 2 to 1, if I
offline a huge page. I think it does not have a correct roll back.
# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total: 2
HugePages_Free:1
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 16777216 kB
HugePages_Free is supposed to be reduced when offlining a block, but
then HugePages_Total should also be reduced, so that is strange. On my
system both were reduced. Does this happen with any version of my patch?
No, I only tested your first version. I do not have any question on
your patch, because the error was not introduced by your patch.
What do you mean with postpone the error? Can you reproduce the BUG_ON
or the addressing exception with my patch?
I mean the gigantic offlining function does not work at all on my
environment, even if the correct head page has been found. My method is
to filter all the tail pages out, and your method is to find head page
from tail pages.
Since you can offline gigantic page successful, I think such function
is supported now. I will debug the problem on my environment.
I will make more test on it, but can any one confirm that this function
has been implemented and tested before?
[PATCH] Staging: android: fixed permissions style issue
Fixed a coding style issue. Changed symbolic permissions to octal. Signed-off-by: Eric Salem --- drivers/staging/android/lowmemorykiller.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index 80d7adf..553a3ee 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -204,10 +204,10 @@ device_initcall(lowmem_init); * not really modular, but the easiest way to keep compat with existing * bootargs behaviour is to continue using module_param here. */ -module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR); +module_param_named(cost, lowmem_shrinker.seeks, int, 0644); module_param_array_named(adj, lowmem_adj, short, &lowmem_adj_size, -S_IRUGO | S_IWUSR); +0644); module_param_array_named(minfree, lowmem_minfree, uint, &lowmem_minfree_size, -S_IRUGO | S_IWUSR); -module_param_named(debug_level, lowmem_debug_level, uint, S_IRUGO | S_IWUSR); +0644); +module_param_named(debug_level, lowmem_debug_level, uint, 0644); -- 2.7.4
[PATCH] sched: Change READ_ONCE(jiffies) into jiffies
A quote from Documentation/memory_barriers.txt:
For example, because 'jiffies' is marked volatile, it is never
necessary to say READ_ONCE(jiffies). The reason for this is
that READ_ONCE() and WRITE_ONCE() are implemented as volatile
casts, which has no effect when its argument is already marked
volatile.
Hence change all 'READ_ONCE(jiffies)' occurrences into 'jiffies'.
Signed-off-by: Bart Van Assche
Cc: Peter Zijlstra
Cc: Oleg Nesterov
---
kernel/sched/core.c| 2 +-
kernel/sched/cputime.c | 4 ++--
kernel/sched/fair.c| 8
kernel/sched/wait.c| 6 --
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..edb811e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3100,7 +3100,7 @@ void scheduler_tick(void)
u64 scheduler_tick_max_deferment(void)
{
struct rq *rq = this_rq();
- unsigned long next, now = READ_ONCE(jiffies);
+ unsigned long next, now = jiffies;
next = rq->last_sched_tick + HZ;
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index a846cf8..9aecaad 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -691,7 +691,7 @@ void thread_group_cputime_adjusted(struct task_struct *p,
cputime_t *ut, cputime
#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
static cputime_t vtime_delta(struct task_struct *tsk)
{
- unsigned long now = READ_ONCE(jiffies);
+ unsigned long now = jiffies;
if (time_before(now, (unsigned long)tsk->vtime_snap))
return 0;
@@ -701,7 +701,7 @@ static cputime_t vtime_delta(struct task_struct *tsk)
static cputime_t get_vtime_delta(struct task_struct *tsk)
{
- unsigned long now = READ_ONCE(jiffies);
+ unsigned long now = jiffies;
cputime_t delta, other;
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 039de34..db5ae54 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4802,7 +4802,7 @@ static void cpu_load_update_idle(struct rq *this_rq)
if (weighted_cpuload(cpu_of(this_rq)))
return;
- cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0);
+ cpu_load_update_nohz(this_rq, jiffies, 0);
}
/*
@@ -4828,7 +4828,7 @@ void cpu_load_update_nohz_start(void)
*/
void cpu_load_update_nohz_stop(void)
{
- unsigned long curr_jiffies = READ_ONCE(jiffies);
+ unsigned long curr_jiffies = jiffies;
struct rq *this_rq = this_rq();
unsigned long load;
@@ -4851,7 +4851,7 @@ static void cpu_load_update_periodic(struct rq *this_rq,
unsigned long load)
{
#ifdef CONFIG_NO_HZ_COMMON
/* See the mess around cpu_load_update_nohz(). */
- this_rq->last_load_update_tick = READ_ONCE(jiffies);
+ this_rq->last_load_update_tick = jiffies;
#endif
cpu_load_update(this_rq, load, 1);
}
@@ -4864,7 +4864,7 @@ void cpu_load_update_active(struct rq *this_rq)
unsigned long load = weighted_cpuload(cpu_of(this_rq));
if (tick_nohz_tick_stopped())
- cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), load);
+ cpu_load_update_nohz(this_rq, jiffies, load);
else
cpu_load_update_periodic(this_rq, load);
}
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index f15d6b6..af4959d 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -601,7 +601,8 @@ EXPORT_SYMBOL(bit_wait_io);
__sched int bit_wait_timeout(struct wait_bit_key *word, int mode)
{
- unsigned long now = READ_ONCE(jiffies);
+ unsigned long now = jiffies;
+
if (time_after_eq(now, word->timeout))
return -EAGAIN;
schedule_timeout(word->timeout - now);
@@ -613,7 +614,8 @@ EXPORT_SYMBOL_GPL(bit_wait_timeout);
__sched int bit_wait_io_timeout(struct wait_bit_key *word, int mode)
{
- unsigned long now = READ_ONCE(jiffies);
+ unsigned long now = jiffies;
+
if (time_after_eq(now, word->timeout))
return -EAGAIN;
io_schedule_timeout(word->timeout - now);
--
2.10.0
About 1000Mbps capability for the GMAC of RK3288
I have confirmed the 1000Mbps won't work with kernel 4.4, I have to disable it in dts. The TRM shows that it may not support 1000Mbps, as the gmac_speed in GRF_SOC_CON1 is just a bit length flag. Also I have test the performance at the firefly plus with upstream kernel, it even looks bad at 100Mpbs mode, only 5~6 MBytes per second. I wonder whether it is the hardware design problem or some problem in driver, I would report if I got more information. Forwarded Message Subject: About 1000Mbps with RK3288 and performance Date: Tue, 20 Sep 2016 09:31:57 +0800 From: Randy Li Organization: Fuzhou Rockchip To: david...@rock-chips.com CC: roger.c...@rock-chips.com Hello Wu Have you guys confirmed the RK3288 EVB with 1000Mbps network? I meet this issue in the weekend. The kernel is 4.4, when I connected the board into a 1000Mbps switch(Dell PowerConnect Serial), the speed negatived 1000Mbps at both side(I checked with console in switch), but the network can't work at all. I have downgrade the speed to 100Mbps or packages loss is nearly 100%. Also I have been reported with performance of ethernet in Upstream kernel, it could barely 5-6MBytes in my test, do you have some idea about this? You could dial internal number 8308 to talk with me. Yours Randy -- Randy Li The third produce department === This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Fuzhou Rockchip Electronics, INC. China mainland] ===
RE: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update
There is only one different which is adding a new empty line for coding
style.
> if (!error)
> - error = elants_i2c_query_fw_id(ts);
> + error = error2;
> +
> if (!error)
> error = elants_i2c_query_fw_version(ts);
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Saturday, September 24, 2016 5:31 AM
To: Johnny Chuang
Cc: Daniel Kurtz; Jennifer Tsai; linux-kernel@vger.kernel.org;
linux-in...@vger.kernel.org; James Chen; Paul Liang; Jeff Chuang; Agnes
Cheng
Subject: Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode
for FW update
On Fri, Sep 23, 2016 at 04:01:17PM +0800, Johnny Chuang wrote:
> This CL takes the responsibility for getting product/hardware id on
> recovery mode.
> It will fix firmware update script could not find correspond firmware
> file name on recovery mode.
> BTW, firmware must need to support reading product/hardware id on boot
> code.
>
> Signed-off-by: Johnny Chuang
This appears to be exactly the same as to what I already have in my "next"
branch...
> ---
> drivers/input/touchscreen/elants_i2c.c | 31
> ---
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index ac09855..02aec28 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -298,7 +298,7 @@ static u16 elants_i2c_parse_version(u8 *buf)
> return get_unaligned_be32(buf) >> 4; }
>
> -static int elants_i2c_query_fw_id(struct elants_data *ts)
> +static int elants_i2c_query_hw_version(struct elants_data *ts)
> {
> struct i2c_client *client = ts->client;
> int error, retry_cnt;
> @@ -318,8 +318,13 @@ static int elants_i2c_query_fw_id(struct elants_data
*ts)
> error, (int)sizeof(resp), resp);
> }
>
> - dev_err(&client->dev,
> - "Failed to read fw id or fw id is invalid\n");
> + if (error) {
> + dev_err(&client->dev,
> + "Failed to read fw id: %d\n", error);
> + return error;
> + }
> +
> + dev_err(&client->dev, "Invalid fw id: %#04x\n", ts->hw_version);
>
> return -EINVAL;
> }
> @@ -508,7 +513,7 @@ static int elants_i2c_fastboot(struct i2c_client
> *client) static int elants_i2c_initialize(struct elants_data *ts) {
> struct i2c_client *client = ts->client;
> - int error, retry_cnt;
> + int error, error2, retry_cnt;
> const u8 hello_packet[] = { 0x55, 0x55, 0x55, 0x55 };
> const u8 recov_packet[] = { 0x55, 0x55, 0x80, 0x80 };
> u8 buf[HEADER_SIZE];
> @@ -553,18 +558,22 @@ static int elants_i2c_initialize(struct elants_data
*ts)
> }
> }
>
> + /* hw version is available even if device in recovery state */
> + error2 = elants_i2c_query_hw_version(ts);
> if (!error)
> - error = elants_i2c_query_fw_id(ts);
> + error = error2;
> +
> if (!error)
> error = elants_i2c_query_fw_version(ts);
> + if (!error)
> + error = elants_i2c_query_test_version(ts);
> + if (!error)
> + error = elants_i2c_query_bc_version(ts);
> + if (!error)
> + error = elants_i2c_query_ts_info(ts);
>
> - if (error) {
> + if (error)
> ts->iap_mode = ELAN_IAP_RECOVERY;
> - } else {
> - elants_i2c_query_test_version(ts);
> - elants_i2c_query_bc_version(ts);
> - elants_i2c_query_ts_info(ts);
> - }
>
> return 0;
> }
> --
> 1.8.3.2
>
--
Dmitry
Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error
On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> Thanks, applied.
>
> I did happen to notice:
>
> On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner wrote:
> >
> > ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> > ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used
> > [-Werror=unused-but-set-variable]
>
> You have some nasty unicode corruption. The email is marked as being
>
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
It's whatever git-send-email spat out. I was under the impression it
encodes like that whenever it sees a utf-8 character in a commit...
> but those are not the right unicode characters. I think gcc actually
> uses back-tick and tick (which is ugly as hell in many fonts since
> they aren't generally necessarily symmetric, but oh well). So some
> cut-and-paste path of yours corrupted the utf8.
Yup, normally I remember to fix that up when composing the patch -
ever since GNU went to those fucked up "grammatically correct"
non-ascii quotes it's caused problems with pasting error messages
into ascii-only contexts.
> Obviously not a big deal, but you might want to look at your character
> set setting in your mailer or other environment. Perhaps some odd
> non-utf8 editor environment or something?
I turned off utf-8 support in vim on the machine I write all my code
on - I got sick of stupid stray marks in my code, digraphs being
composed when I just want to replace a single character, git sending
patches in utf-8 encoding because I copied a SoB with a utf-8
character in the name, etc
> I also noticed:
>
> > This is a regression caused by commit e23d415 ("fix
> > fault_in_multipages_...() on architectures with no-op access_ok()").
>
> I'd suggest doing
>
> git config --global core.abbrev 12
Ok.
> because the default git commit shortening value of 7 is practically
> too short for the kernel these days.
7 characters, 12 characters, whatever. Neither make any sense in
commit messages by themselves without the short description that
goes along with the hash.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
Aw
Benötigen Sie eine Finanzierung? Haben Sie einen Kredit für geschäftliche oder persönliche Bedürfnisse und Projektfinanzierung benötigen? Möchten Sie Ihr Unternehmen zu refinanzieren? Unser Unternehmen ist in den Vereinigten Staaten und Europa. Wir bieten Ihnen ein Darlehen für jede Person oder Gesellschaft mit einem Anteil von 3% pro Jahr. Für weitere Informationen, kontaktieren Sie uns bitte per E-Mail: info.accessf...@gmail.com
RE: [v6,2/2] QE: remove PPCisms for QE
On Sun, Sep 25, 2016 at 12:19PM -0500, Scott Wood wrote: > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Sunday, September 25, 2016 12:19 PM > To: Qiang Zhao > Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie > ; linux-kernel@vger.kernel.org > Subject: Re: [v6,2/2] QE: remove PPCisms for QE > > On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote: > > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote: > > > QE was supported on PowerPC, and dependent on PPC, Now it is > > > supported on other platforms. so remove PPCisms. > > > > > > Signed-off-by: Zhao Qiang > > > --- > > > Changes for v2: > > > - na > > > Changes for v3: > > > - add NO_IRQ > > > Changes for v4: > > > - modify spin_event_timeout to opencoded timeout loop > > > - remove NO_IRQ > > > - modify virq_to_hw to opencoed code Changes for v5: > > > - modify commit msg > > > - modify depends of QUICC_ENGINE > > > - add kerneldoc header for qe_issue_cmd Changes for v6: > > > - add dependency on FSL_SOC and PPC32 for drivers > > > depending on QUICC_ENGING but not available on ARM > > > > > > drivers/irqchip/qe_ic.c| 28 +++- > > > drivers/net/ethernet/freescale/Kconfig | 10 ++--- > > > drivers/soc/fsl/qe/Kconfig | 2 +- > > > drivers/soc/fsl/qe/qe.c| 80 > > > -- > > > drivers/soc/fsl/qe/qe_io.c | 42 -- > > > drivers/soc/fsl/qe/qe_tdm.c| 8 ++-- > > > drivers/soc/fsl/qe/ucc.c | 10 ++--- > > > drivers/soc/fsl/qe/ucc_fast.c | 68 ++--- > > > drivers/tty/serial/Kconfig | 2 +- > > > drivers/usb/gadget/udc/Kconfig | 2 +- > > > drivers/usb/host/Kconfig | 2 +- > > > include/soc/fsl/qe/qe.h| 1 - > > > include/soc/fsl/qe/qe_ic.h | 12 ++--- > > > 13 files changed, 141 insertions(+), 126 deletions(-) > > > > I assume this means you'll be updating > > http://patchwork.ozlabs.org/patch/654473/ > > to be based on top of this... > > Apparently that assumption was wrong, since I now see that you're patching > drivers/irqchip/qe_ic.c rather than drivers/soc/fsl/qe/qe_ic.c. > Please keep the drivers/irqchip stuff separate and send to the appropriate > maintainers. > You means separate drivers/irqchip/qe_ic.c part from this patch and send it with the other qe_ic patches? Is it acceptable if I modify qe_ic.c with drivers/soc/fsl/qe/qe_ic.c, then send qe_ic patches to move qe_ic to drivers/irqchip? BR -Zhao Qiang
[PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE
Use a bit more consistent style with kernel loglevels without
using macro argument concatenation.
Miscellanea:
o Single statement macros don't need do {} while (0)
Signed-off-by: Joe Perches
---
drivers/gpu/drm/i915/intel_guc_loader.c | 22 --
include/drm/drmP.h | 26 +-
2 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6fd39efb7894..bc4f9895f356 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -566,7 +566,7 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
- DRM_NOTE("GuC firmware load failed: %d\n", err);
+ DRM_NOTICE("GuC firmware load failed: %d\n", err);
else
DRM_WARN("GuC firmware load failed: %d\n", err);
@@ -574,7 +574,7 @@ int intel_guc_setup(struct drm_device *dev)
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not
supported\n");
if (ret == 0)
- DRM_NOTE("Falling back from GuC submission to execlist
mode\n");
+ DRM_NOTICE("Falling back from GuC submission to
execlist mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -606,7 +606,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
- DRM_NOTE("Firmware header is missing\n");
+ DRM_NOTICE("Firmware header is missing\n");
goto fail;
}
@@ -618,7 +618,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
- DRM_NOTE("CSS header definition mismatch\n");
+ DRM_NOTICE("CSS header definition mismatch\n");
goto fail;
}
@@ -628,7 +628,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
- DRM_NOTE("RSA key size is bad\n");
+ DRM_NOTICE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -637,14 +637,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
- DRM_NOTE("Missing firmware components\n");
+ DRM_NOTICE("Missing firmware components\n");
goto fail;
}
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
- DRM_NOTE("Firmware is too large to fit in WOPCM\n");
+ DRM_NOTICE("Firmware is too large to fit in WOPCM\n");
goto fail;
}
@@ -659,9 +659,11 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
if (guc_fw->guc_fw_major_found != guc_fw->guc_fw_major_wanted ||
guc_fw->guc_fw_minor_found < guc_fw->guc_fw_minor_wanted) {
- DRM_NOTE("GuC firmware version %d.%d, required %d.%d\n",
- guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found,
- guc_fw->guc_fw_major_wanted,
guc_fw->guc_fw_minor_wanted);
+ DRM_NOTICE("GuC firmware version %d.%d, required %d.%d\n",
+ guc_fw->guc_fw_major_found,
+ guc_fw->guc_fw_minor_found,
+ guc_fw->guc_fw_major_wanted,
+ guc_fw->guc_fw_minor_wanted);
err = -ENOEXEC;
goto fail;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c53dc90942e0..95cd04aa9bf7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,25 +168,25 @@ void drm_printk(const char *level, unsigned int category,
/** \name Macros to make printk easier */
/*@{*/
-#define _DRM_PRINTK(once, level, fmt, ...) \
- do {\
- printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
- } while (0)
+#define _drm_printk(level, fmt, ...)
[PATCH 0/2] drm: Neaten and reduce object size
Joe Perches (2): drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE drm: Simplify drm_printk to reduce object size quite a bit drivers/gpu/drm/drm_drv.c | 5 +-- drivers/gpu/drm/i915/intel_guc_loader.c | 22 +++-- include/drm/drmP.h | 56 - 3 files changed, 42 insertions(+), 41 deletions(-) -- 2.10.0.rc2.1.g053435c
[PATCH 2/2] drm: Simplify drm_printk to reduce object size quite a bit
Remove function name and special " *ERROR*" from argument list
$ size drivers/gpu/drm/built-in.o* (x86-32 defconfig, most drm selected)
textdata bss dec hex filename
5635366 182579 14328 5832273 58fe51 drivers/gpu/drm/built-in.o.new
5779552 182579 14328 5976459 5b318b drivers/gpu/drm/built-in.o.old
Using "%ps", __builtin_return_address(0) is the same as "%s", __func__
except for static inlines, but it's more or less the same output.
Miscellanea:
o Convert args... to ##__VA_ARGS__
o The equivalent DRM_DEV_ macros are rarely used and not
worth conversion
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_drv.c | 5 +++--
include/drm/drmP.h| 30 ++
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 80c7f25b5b74..6efdba4993fc 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -89,7 +89,6 @@ void drm_dev_printk(const struct device *dev, const char
*level,
EXPORT_SYMBOL(drm_dev_printk);
void drm_printk(const char *level, unsigned int category,
- const char *function_name, const char *prefix,
const char *format, ...)
{
struct va_format vaf;
@@ -102,7 +101,9 @@ void drm_printk(const char *level, unsigned int category,
vaf.fmt = format;
vaf.va = &args;
- printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
+ printk("%s" "[" DRM_NAME ":%ps]%s %pV",
+ level, __builtin_return_address(0),
+ strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", &vaf);
va_end(args);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 95cd04aa9bf7..4729c543d877 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -140,9 +140,8 @@ void drm_dev_printk(const struct device *dev, const char
*level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
-extern __printf(5, 6)
+extern __printf(3, 4)
void drm_printk(const char *level, unsigned int category,
- const char *function_name, const char *prefix,
const char *format, ...);
/***/
@@ -198,8 +197,7 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
fmt, ##__VA_ARGS__)
#define DRM_ERROR(fmt, ...)\
- drm_printk(KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt,\
- ##__VA_ARGS__)
+ drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
@@ -241,38 +239,38 @@ void drm_printk(const char *level, unsigned int category,
#define DRM_DEV_DEBUG(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
##args)
-#define DRM_DEBUG(fmt, args...)
\
- drm_printk(KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, ##args)
+#define DRM_DEBUG(fmt, ...)\
+ drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
fmt, ##args)
-#define DRM_DEBUG_DRIVER(fmt, args...) \
- drm_printk(KERN_DEBUG, DRM_UT_DRIVER, __func__, "", fmt, ##args)
+#define DRM_DEBUG_DRIVER(fmt, ...) \
+ drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_KMS(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, \
##args)
-#define DRM_DEBUG_KMS(fmt, args...)\
- drm_printk(KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, ##args)
+#define DRM_DEBUG_KMS(fmt, ...)\
+ drm_printk(KERN_DEBUG, DRM_UT_KMS, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_PRIME(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_PRIME, __func__, "", \
fmt, ##args)
-#define DRM_DEBUG_PRIME(fmt, args...) \
- drm_printk(KERN_DEBUG, DRM_UT_PRIME, __func__, "", fmt, ##args)
+#define DRM_DEBUG_PRIME(fmt, ...) \
+ drm_printk(KERN_DEBUG, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_ATOMIC(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ATOMIC, __func__, "",\
fmt, ##args)
Re: Warning from free_init_pages with large initrd
On 09/24/16 08:32, Sitsofe Wheeler wrote: > Hi, > > While trying to PXE boot a Fedora LiveISO on VMware ESXi the kernel > throws the following warning: > [...] > > The initrd is big because it holds all the files in the ISO (see > https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd for how it was > made). The issue was originally filed on > https://bugzilla.redhat.com/show_bug.cgi?id=1274966 but was usually > against older kernels... > How big is big?
внимания;
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...8715gdo7q2..2016 Почты технической поддержки ©2016 спасибо системы администратор
Linux 4.8-rc8
So as already mentioned last week (and hinted at as a possibility), here's rc8. Things actually did start to calm down this week, but I didn't get the feeling that there was no point in doing one final rc, so here we are. I expect the final 4.8 release next weekend, unless something really unexpected comes up. There's a few straggling entries on Thorsten's regression list, but nothing that makes me go "we need to hold off 4.8". And things realy were pretty quiet, with just mostly random small fixes. See the shortlog below, but it's small things all over: mostly drivers, with some arch and crypto, and small MM and filesystem fixes. And a smattering of networking. Linus --- AKASHI Takahiro (1): arm64: kgdb: handle read-only text / modules Aaro Koskinen (2): MIPS: Octeon: mangle-port: fix build failure with VDSO code MIPS: Octeon: Fix platform bus probing Al Viro (2): fix fault_in_multipages_...() on architectures with no-op access_ok() fix memory leaks in tracing_buffers_splice_read() Alexander Shishkin (2): perf/x86/intel/bts: Make it an exclusive PMU perf/core: Limit matching exclusive events to one PMU Alexandre Bounine (1): rapidio/rio_cm: avoid GFP_KERNEL in atomic context Amitoj Kaur Chawla (1): MIPS: ath79: Fix test for error return of clk_register_fixed_factor(). Andrew Lunn (1): MAINTAINERS: Add an entry for the core network DSA code Ard Biesheuvel (2): crypto: arm/aes-ctr - fix NULL dereference in tail processing crypto: arm64/aes-ctr - fix NULL dereference in tail processing Arnd Bergmann (1): Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning Ashish Samant (1): ocfs2: fix start offset to ocfs2_zero_range_for_truncate() Baoquan He (1): bnx2: Reset device during driver initialization Beni Lev (1): iwlwifi: mvm: update TX queue before making a copy of the skb Christoph Hellwig (1): blk-mq: skip unmapped queues in blk_mq_alloc_request_hctx Christophe Jaillet (1): drivers: net: phy: xgene: Fix 'remove' function Dave Chinner (1): fault_in_multipages_readable() throws set-but-unused error David Daney (1): arm64: Call numa_store_cpu_info() earlier. Ebru Akagunduz (1): mm, thp: fix leaking mapped pte in __collapse_huge_page_swapin() Eric Dumazet (3): tcp: fix overflow in __tcp_retransmit_skb() net: avoid sk_forward_alloc overflows net: get rid of an signed integer overflow in ip_idents_reserve() Fabio Estevam (1): can: flexcan: fix resume function Felix Fietkau (2): mac80211: fix tim recalculation after PS response mac80211: fix sequence number assignment for PS response frames Filipe Manco (1): xen-netback: fix error handling on netback_probe() Florian Fainelli (1): MAINTAINERS: update email for VLYNQ bus entry Gao Feng (1): netfilter: synproxy: Check oom when adding synproxy and seqadj ct extensions Geert Uytterhoeven (1): [media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success Giuseppe CAVALLARO (1): stmmac: fix PWRDWN into the PMT register for global unicast. Hans Verkuil (17): [media] cec: rename cec_devnode fhs_lock to just lock [media] cec: improve locking [media] cec-funcs.h: fix typo: && should be & [media] cec-funcs.h: add reply argument for Record On/Off [media] cec: improve dqevent documentation [media] cec: add CEC_LOG_ADDRS_FL_ALLOW_UNREG_FALLBACK flag [media] cec: set unclaimed addresses to CEC_LOG_ADDR_INVALID [media] cec: add item to TODO [media] cec: ignore messages when log_addr_mask == 0 [media] mtk-vcodec: add HAS_DMA dependency [media] pulse8-cec: set correct Signal Free Time [media] pulse8-cec: fix error handling [media] cec-edid: check for IEEE identifier [media] cec-funcs.h: add missing vendor-specific messages [media] cec: don't Feature Abort broadcast msgs when unregistered [media] cec: fix ioctl return code when not registered [media] cx23885/saa7134: assign q->dev to the PCI device Hans Wippel (1): qeth: restore device features after recovery Hans de Goede (2): Input: silead_gsl1680 - document firmware-name, fix implementation Input: silead_gsl1680 - use "silead/" prefix for firmware loading Hariprasad Shenai (1): cxgb4/cxgb4vf: Allocate more queues for 25G and 100G adapter Herbert Xu (4): crypto: echainiv - Replace chaining with multiplication crypto: skcipher - Fix blkcipher walk OOM crash KEYS: Fix skcipher IV clobbering crypto: rsa-pkcs1pad - Handle leading zero for decryption Huacai Chen (1): MIPS: Add a missing ".set pop" in an early commit Hugh Dickins (2): huge tmpfs: fix Committed_AS leak mm: delete unnecessary and unsafe init_tlb_ubc() Ian Kent (1): autofs: use dentry flags to block walks during expire Ilan Tayari (1):
Re: undefined reference to `printk'
Hi Joe, On Sat, Sep 24, 2016 at 08:46:26PM -0700, Joe Perches wrote: On Sun, 2016-09-25 at 11:40 +0800, kbuild test robot wrote: Hi Joe, Hey Fengguang It's probably a bug fix that unveils the link errors. I think all of these reports about compiler-gcc integrations are bogons. Yes, sorry for the noises again! tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9c0e28a7be656d737fb18998e2dcb0b8ce595643 commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various compiler-gcc[345].h files It looks there are different commit SHA1 in different trees for that patch. I'll match it by patch subject rather than commit id. Cheers, Fengguang
Re: [PATCH 00/14] perf clang: Support compiling BPF script use builtin clang
On 2016/9/24 23:16, Alexei Starovoitov wrote: On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote: This patch set is the first step to implement features I announced in LinuxCon NA 2016. See page 31 of: http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf This patch set links LLVM and Clang libraries to perf, so perf is able to compile BPF script to BPF object on the fly. Nice! So single perf binary won't have llvm external dependency anymore or both ways will be maintained? The command line stays the same? Yes. This patch set doesn't change interface. It compiles BPF script with builtin clang, and if it fail, fall back to external clang. If I understand the patches correctly, this set is establishing the basic functionality and more complex features coming? Yes. Following steps are: 1. Ease of use improvement: automatically include BPF functions declaration and macros. 2. Perf's hook: compile part of BPF script into native code, run them in perf when something happen. Create a channel, coordinate BPF and native code use bpf-output event. 3. Define a new language to support common profiling task. I'm not very clear what the new language should be. It may looks like lua, perf converts it to C then to LLVM IR with builtin clang. Thank you.
RE: [PATCH] pm8001: mark symbols static where possible
Thanks for fix.
Acked-by: Lindar Liu
> -Original Message-
> From: Baoyou Xie [mailto:baoyou@linaro.org]
> Sent: Friday, September 23, 2016 9:54 PM
> To: jinpu.w...@profitbricks.com; lindar_...@usish.com;
> j...@linux.vnet.ibm.com; martin.peter...@oracle.com
> Cc: pmc...@pmcs.com; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
> xie.bao...@zte.com.cn
> Subject: [PATCH] pm8001: mark symbols static where possible
>
> We get 2 warnings when building kernel with W=1:
> drivers/scsi/pm8001/pm8001_sas.c:530:23: warning: no previous prototype
> for 'pm8001_alloc_dev' [-Wmissing-prototypes]
> drivers/scsi/pm8001/pm8001_hwi.c:4495:5: warning: no previous prototype
> for 'pm8001_chip_phy_stop_req' [-Wmissing-prototypes]
>
> In fact, these functions are only used in the file in which they are
declared and
> don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie
> ---
> drivers/scsi/pm8001/pm8001_hwi.c | 4 ++--
> drivers/scsi/pm8001/pm8001_sas.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 04e67a1..10546fa 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -4492,8 +4492,8 @@ pm8001_chip_phy_start_req(struct
> pm8001_hba_info *pm8001_ha, u8 phy_id)
> * @num: the inbound queue number
> * @phy_id: the phy id which we wanted to start up.
> */
> -int pm8001_chip_phy_stop_req(struct pm8001_hba_info *pm8001_ha,
> - u8 phy_id)
> +static int pm8001_chip_phy_stop_req(struct pm8001_hba_info
> *pm8001_ha,
> + u8 phy_id)
> {
> struct phy_stop_req payload;
> struct inbound_queue_table *circularQ; diff --git
> a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c
> index dc33dfa..ce584c3 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -527,7 +527,7 @@ void pm8001_ccb_task_free(struct pm8001_hba_info
> *pm8001_ha,
>* pm8001_alloc_dev - find a empty pm8001_device
>* @pm8001_ha: our hba card information
>*/
> -struct pm8001_device *pm8001_alloc_dev(struct pm8001_hba_info
> *pm8001_ha)
> +static struct pm8001_device *pm8001_alloc_dev(struct pm8001_hba_info
> +*pm8001_ha)
> {
> u32 dev;
> for (dev = 0; dev < PM8001_MAX_DEVICES; dev++) {
> --
> 2.7.4
Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error
Thanks, applied.
I did happen to notice:
On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner wrote:
>
> ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used
> [-Werror=unused-but-set-variable]
You have some nasty unicode corruption. The email is marked as being
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
but those are not the right unicode characters. I think gcc actually
uses back-tick and tick (which is ugly as hell in many fonts since
they aren't generally necessarily symmetric, but oh well). So some
cut-and-paste path of yours corrupted the utf8.
Obviously not a big deal, but you might want to look at your character
set setting in your mailer or other environment. Perhaps some odd
non-utf8 editor environment or something?
I also noticed:
> This is a regression caused by commit e23d415 ("fix
> fault_in_multipages_...() on architectures with no-op access_ok()").
I'd suggest doing
git config --global core.abbrev 12
because the default git commit shortening value of 7 is practically
too short for the kernel these days. What can I say? I was naïve, and
based my original abbreviation decision on the BitKeeper numbers,
where we were just about to hit 64k commits. So seven hex digits
seemed plenty. And now, ten years later, I just look stupid.
Anyway - while git will always pick a shortname that is unique (ie it
will add characters until it is unique), it's unique only at that
moment in time. And practically speaking seven hex digits can easily
have collisions in the hear future (ie it already happens with many
commits).
So telling git "give me a minimum of 12 hex digits in hash
abbreviations" should be fairly safe for a while.
I guess I should ping Junio and see if we can just change the default,
but for smaller projects the default abbreviation is likely still
reasonable. So I've been just mentioning that simple "set core.abbrev
to 12" to kernel people..
Linus
Re: [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing
On Sun, Sep 25, 2016 at 5:49 PM, Rik van Riel wrote: > > Reading the code for a little bit, it looks like get_user_pages > interprets both PROT_NONE and PAGE_NUMA ptes as present, and will > simply return the page to the caller. So the thing is, I don't think the code should even get that far. It should just fail in check_vma_flags() (possibly after doing the fast-lookup of the page tables, but that would fail with PROT_NONE). But thanks to FOLL_FORCE, it doesn't. So things that actually use the page array and prot_none can get access to the underlying data. Linus
Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out
On Sun, Sep 25, 2016 at 12:18:49PM -0700, Shaohua Li wrote: > On Fri, Sep 23, 2016 at 10:32:39AM +0800, Huang, Ying wrote: > > Rik van Riel writes: > > > > > On Thu, 2016-09-22 at 15:56 -0700, Shaohua Li wrote: > > >> On Wed, Sep 07, 2016 at 09:45:59AM -0700, Huang, Ying wrote: > > >> > > > >> > - It will help the memory fragmentation, especially when the THP is > > >> > heavily used by the applications. The 2M continuous pages will > > >> > be > > >> > free up after THP swapping out. > > >> > > >> So this is impossible without THP swapin. While 2M swapout makes a > > >> lot of > > >> sense, I doubt 2M swapin is really useful. What kind of application > > >> is > > >> 'optimized' to do sequential memory access? > > > > > > I suspect a lot of this will depend on the ratio of storage > > > speed to CPU & RAM speed. > > > > > > When swapping to a spinning disk, it makes sense to avoid > > > extra memory use on swapin, and work in 4kB blocks. > > > > For spinning disk, the THP swap optimization will be turned off in > > current implementation. Because huge swap cluster allocation based on > > swap cluster management, which is available only for non-rotating block > > devices (blk_queue_nonrot()). > > For 2m swapin, as long as one byte is changed in the 2m, next time we must do > 2m swapout. There is huge waste of memory and IO bandwidth and increases > unnecessary memory pressure. 2M IO will very easily saturate a very fast SSD I agree. No doubt THP swapout is helpful for overall performance but THP swapin should be more careful. It would cause memory pressure which could evict warm pages which mitigates THP's benefit. THP swapin also would increase minor fault latency, too. If we want to swap in a THP, I think we need something to guarantee that subpages in a THP swapped out were hot and temporal locality so that it's worth to swap in a THP page to lose other memory kept in in memory. Maybe it would not matter so much in MADVISE mode where userspace knows pros and cons and choosed it. The problem would be there in ALWAYS mode. One of idea is we can raise bar to collapse THP page higher, for example, reducing khugepaged_max_ptes_none and introducing khugepaged_max_pte_ref. With that, khugepaged would collapse 4K pages into a THP only if most of subpages are mapped and hot.
Re: [PATCH] f2fs: remove dirty inode pages in error path
On 2016/9/25 1:47, Jaegeuk Kim wrote: > On Sat, Sep 24, 2016 at 09:02:02AM +0800, Chao Yu wrote: >> On 2016/9/24 5:11, Jaegeuk Kim wrote: >>> When getting EIO while handling orphan inodes, we can get some dirty node >>> pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try >>> to flush node pages. But in this case, we should prevent to do that, since >>> we will try again from the start. >> >> We are protected since we set SBI_POR_DOING flag in sb, so we are safe now? > > Safe, but we get an infinite loop to flush node pages. Got it. Thanks, > >> >> Thanks, > > . >
Re: [PATCH 2/3] f2fs: support checkpoint error injection
On 2016/9/25 2:10, Jaegeuk Kim wrote: > On Sat, Sep 24, 2016 at 11:32:08AM +0800, Chao Yu wrote: >> On 2016/9/24 8:52, Jaegeuk Kim wrote: >>> On Sat, Sep 24, 2016 at 08:46:54AM +0800, Chao Yu wrote: Hi Jaegeuk, On 2016/9/24 7:53, Jaegeuk Kim wrote: > Hi Chao, > > The basic rule is to stop every operations once CP_ERROR_FLAG is set. > But, this patch simply breaks the rule. > For example, f2fs_write_data_page() currently exits with > mapping_set_error(). > So this patch incurs missing dentry blocks in a valid checkpoint. Yes, that's right. How about triggering checkpoint error in f2fs_stop_checkpoint? >>> >>> Let's just use src/godown in xfstests, since we don't need to trigger this >>> multiple times in runtime. >> >> After we inject checkpoint error into f2fs at first time, all write IOs will >> be >> refused to be writebacked to storage, meanwhile read IOs can continuously go >> through f2fs, so with checkpoint error injection being supported, we can >> support >> to trigger random analogously power off by f2fs itself, instead of using >> tools. >> It means it doesn't needs specified test cases where we must use godown >> ioctl, >> but with normal testcases in xfstest/fsstress/lkp, in CP error injection >> enabled >> f2fs, we can test power off cases. > > But, in this approach, the test coverage would be quite limited. > In my testcase, I'm randomly injecting godown while fsstress is running, which > mimics really random power failures, as I believe. I'm running this infinitely > with fscking at every run. > > Anyway, in order to do this without godown, how about background_gc thread to > trigger f2fs_stop_checkpoint? Yeap, better. What do you think of adding random f2fs_stop_checkpoint in f2fs_balance_fs? power off can be triggered if gc thread is not running. Thanks, > >> >> Thanks, > > . >
Re: [PATCH V2] staging: rtl8172: usb_intf.c: Fixed block comment coding style
On 09/25/2016 06:00 PM, Gonçalo Salazar wrote:
Fixed a block comment indentation in the rtl8712 usb_intf.c file.
Made this as a first commit.
Resubmitted with updated subject.
Please let me know of any feedback you have.
I missed this last time, but everything above the --- line goes into the
permanent record. Are you sure you want all this to be there? Any chatty remarks
and any description of what changed in subsequent submissions should be below
the ---. The maintainer will see them, but they are stripped before they get
merged into the repo.
Larry
Thanks,
Gonçalo Salazar
Signed-off-by: Gonçalo Salazar
---
drivers/staging/rtl8712/usb_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index 3fc65b2..897d462 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -369,7 +369,7 @@ static const struct device_type wlan_type = {
*
* notes: drv_init() is called when the bus driver has located a card for us
* to support. We accept the new device by returning 0.
-*/
+ */
static int r871xu_drv_init(struct usb_interface *pusb_intf,
const struct usb_device_id *pdid)
{
Re: [PATCH 4/3] g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio
On Mon, Sep 26, 2016 at 10:37:13AM +1000, Finn Thain wrote: > Let's not do that yet. I have a patch series that fixes the type casting > and related issues that I will post soon. I expect that Ondrej's patches > will be ready before mine are, so I'll rebase mine on this work before I > ask him to test my patches. Ok, even better.
[PATCH 11/11 RESEND] staging: dgnc: introduce find_board_by_major()
It was used to get a board structure with dgnc_BoardsByMajor array.
But this driver already has the array for managing initialized board
as dgap_board[]. It can be used for searching the board structure
by major number.
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
drivers/staging/dgnc/dgnc_tty.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index ba724ab..a486a86 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -45,7 +45,6 @@
/*
* internal variables
*/
-static struct dgnc_board *dgnc_BoardsByMajor[256];
static unsigned char *dgnc_TmpWriteBuf;
/*
@@ -251,8 +250,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
goto free_print_driver;
}
- dgnc_BoardsByMajor[brd->serial_driver->major] = brd;
-
return 0;
free_print_driver:
@@ -388,7 +385,6 @@ void dgnc_cleanup_tty(struct dgnc_board *brd)
{
int i = 0;
- dgnc_BoardsByMajor[brd->serial_driver->major] = NULL;
for (i = 0; i < brd->nasync; i++) {
if (brd->channels[i])
dgnc_remove_tty_sysfs(brd->channels[i]->
@@ -397,7 +393,6 @@ void dgnc_cleanup_tty(struct dgnc_board *brd)
}
tty_unregister_driver(brd->serial_driver);
- dgnc_BoardsByMajor[brd->print_driver->major] = NULL;
for (i = 0; i < brd->nasync; i++) {
if (brd->channels[i])
dgnc_remove_tty_sysfs(brd->channels[i]->
@@ -935,6 +930,24 @@ void dgnc_wakeup_writes(struct channel_t *ch)
spin_unlock_irqrestore(&ch->ch_lock, flags);
}
+struct dgnc_board *find_board_by_major(unsigned int major)
+{
+ int i;
+
+ for (i = 0; i < MAXBOARDS; i++) {
+ struct dgnc_board *brd = dgnc_board[i];
+
+ if (!brd)
+ return NULL;
+
+ if (major == brd->serial_driver->major ||
+ major == brd->print_driver->major)
+ return brd;
+ }
+
+ return NULL;
+}
+
/
*
* TTY Entry points and helper functions
@@ -964,7 +977,7 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
return -ENXIO;
/* Get board pointer from our array of majors we have allocated */
- brd = dgnc_BoardsByMajor[major];
+ brd = find_board_by_major(major);
if (!brd)
return -ENXIO;
--
1.9.1
Re: [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing
On Sun, 2016-09-25 at 15:50 -0700, Linus Torvalds wrote: > On Sun, Sep 25, 2016 at 3:34 PM, Rik van Riel > wrote: > > > > > > The patch looks good to me, too. > > > > Acked-by: Rik van Riel > > Thanks, amended the commit since I hadn't pushed out yet. > > Btw, the only reason this bug could happen is that we do that > "force=1" for remote vm accesses, which turns into FOLL_FORCE, which > in turn will turn into us allowing an access even when we technically > shouldn't. > > I'd really like to re-open the "drop FOLL_FORCE entirely" discussion, > because the thing really is disgusting. > > I realize that debuggers etc sometimes would want to punch through > PROT_NONE protections, Reading the code for a little bit, it looks like get_user_pages interprets both PROT_NONE and PAGE_NUMA ptes as present, and will simply return the page to the caller. Furthermore, if a page in a PROT_NONE VMA is actually not present, it should be faulted in with PROT_NONE permissions, after which the page is passed to the debugger. That is, punching through PROT_NONE permissions should only happen from outside of the process. Inside the process, PROT_NONE should be preserved regardless of FOLL_FORCE. -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
[PATCH 10/11 RESEND] staging: dgnc: remove useless variables
The dgnc_major_serial_registered and dgnc_major_serial_registered
do not need to use to check whether the tty driver is registered or not.
These variables are used only in dgnc_cleanup_tty() function,
This function will be called normally with initialized board structure.
It means the dgnc_cleanup_tty() cannot be called with unregistered tty.
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
drivers/staging/dgnc/dgnc_driver.h | 3 --
drivers/staging/dgnc/dgnc_tty.c| 64 +++---
2 files changed, 25 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.h
b/drivers/staging/dgnc/dgnc_driver.h
index 747a100..8792026 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -203,9 +203,6 @@ struct dgnc_board {
struct tty_driver *print_driver;
charprint_name[200];
- booldgnc_major_serial_registered;
- booldgnc_major_transparent_print_registered;
-
u16 dpatype;/* The board "type",
* as defined by DPA
*/
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 5befd28..ba724ab 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -204,15 +204,11 @@ int dgnc_tty_register(struct dgnc_board *brd)
*/
tty_set_operations(brd->serial_driver, &dgnc_tty_ops);
- if (!brd->dgnc_major_serial_registered) {
- /* Register tty devices */
- rc = tty_register_driver(brd->serial_driver);
- if (rc < 0) {
- dev_dbg(&brd->pdev->dev,
- "Can't register tty device (%d)\n", rc);
- goto free_serial_driver;
- }
- brd->dgnc_major_serial_registered = true;
+ rc = tty_register_driver(brd->serial_driver);
+ if (rc < 0) {
+ dev_dbg(&brd->pdev->dev,
+ "Can't register tty device (%d)\n", rc);
+ goto free_serial_driver;
}
/*
@@ -247,16 +243,12 @@ int dgnc_tty_register(struct dgnc_board *brd)
*/
tty_set_operations(brd->print_driver, &dgnc_tty_ops);
- if (!brd->dgnc_major_transparent_print_registered) {
- /* Register Transparent Print devices */
- rc = tty_register_driver(brd->print_driver);
- if (rc < 0) {
- dev_dbg(&brd->pdev->dev,
- "Can't register Transparent Print device(%d)\n",
- rc);
- goto free_print_driver;
- }
- brd->dgnc_major_transparent_print_registered = true;
+ rc = tty_register_driver(brd->print_driver);
+ if (rc < 0) {
+ dev_dbg(&brd->pdev->dev,
+ "Can't register Transparent Print device(%d)\n",
+ rc);
+ goto free_print_driver;
}
dgnc_BoardsByMajor[brd->serial_driver->major] = brd;
@@ -396,29 +388,23 @@ void dgnc_cleanup_tty(struct dgnc_board *brd)
{
int i = 0;
- if (brd->dgnc_major_serial_registered) {
- dgnc_BoardsByMajor[brd->serial_driver->major] = NULL;
- for (i = 0; i < brd->nasync; i++) {
- if (brd->channels[i])
- dgnc_remove_tty_sysfs(brd->channels[i]->
- ch_tun.un_sysfs);
- tty_unregister_device(brd->serial_driver, i);
- }
- tty_unregister_driver(brd->serial_driver);
- brd->dgnc_major_serial_registered = false;
+ dgnc_BoardsByMajor[brd->serial_driver->major] = NULL;
+ for (i = 0; i < brd->nasync; i++) {
+ if (brd->channels[i])
+ dgnc_remove_tty_sysfs(brd->channels[i]->
+ ch_tun.un_sysfs);
+ tty_unregister_device(brd->serial_driver, i);
}
+ tty_unregister_driver(brd->serial_driver);
- if (brd->dgnc_major_transparent_print_registered) {
- dgnc_BoardsByMajor[brd->print_driver->major] = NULL;
- for (i = 0; i < brd->nasync; i++) {
- if (brd->channels[i])
- dgnc_remove_tty_sysfs(brd->channels[i]->
- ch_pun.un_sysfs);
- tty_unregister_device(brd->print_driver, i);
- }
- tty_unregister_driver(brd->print_driver);
- brd->dgnc_major_transparent_print_registered = false;
+ dgnc_BoardsByMajor[brd->print_driver->major] = NULL;
+ for (i = 0; i < brd->nasync; i++
[PATCH 09/11 V2 RESEND] staging: dgnc: rename dgnc_tty_uninit() to dgnc_cleanup_tty()
The dgnc_tty_uninit() doesn't match with dgnc_tty_init() at all.
And also the dgnc_cleanup_tty() is only called for exiting the module.
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
V2: The subject line was cut off, I put it completely and update
change log.
drivers/staging/dgnc/dgnc_driver.c | 2 +-
drivers/staging/dgnc/dgnc_tty.c| 4 ++--
drivers/staging/dgnc/dgnc_tty.h| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 81ce5c4..fd372d3 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -147,7 +147,7 @@ static void cleanup(bool sysfiles)
for (i = 0; i < dgnc_num_boards; ++i) {
dgnc_remove_ports_sysfiles(dgnc_board[i]);
- dgnc_tty_uninit(dgnc_board[i]);
+ dgnc_cleanup_tty(dgnc_board[i]);
dgnc_cleanup_board(dgnc_board[i]);
}
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 893f473..5befd28 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -387,12 +387,12 @@ void dgnc_tty_post_uninit(void)
}
/*
- * dgnc_tty_uninit()
+ * dgnc_cleanup_tty()
*
* Uninitialize the TTY portion of this driver. Free all memory and
* resources.
*/
-void dgnc_tty_uninit(struct dgnc_board *brd)
+void dgnc_cleanup_tty(struct dgnc_board *brd)
{
int i = 0;
diff --git a/drivers/staging/dgnc/dgnc_tty.h b/drivers/staging/dgnc/dgnc_tty.h
index f065c8f..24c9a41 100644
--- a/drivers/staging/dgnc/dgnc_tty.h
+++ b/drivers/staging/dgnc/dgnc_tty.h
@@ -25,7 +25,7 @@ int dgnc_tty_preinit(void);
int dgnc_tty_init(struct dgnc_board *);
void dgnc_tty_post_uninit(void);
-void dgnc_tty_uninit(struct dgnc_board *);
+void dgnc_cleanup_tty(struct dgnc_board *);
void dgnc_input(struct channel_t *ch);
void dgnc_carrier(struct channel_t *ch);
--
1.9.1
[PATCH 08/11 RESEND] staging: dgnc: introduce the dgnc_free_irq()
The dgnc_free_irq() will free the requested IRQ from
the dgnc_request_irq().
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
drivers/staging/dgnc/dgnc_driver.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 70e68b5..81ce5c4 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -38,6 +38,7 @@ MODULE_SUPPORTED_DEVICE("dgnc");
*/
static int dgnc_start(void);
static int dgnc_request_irq(struct dgnc_board *brd);
+static void dgnc_free_irq(struct dgnc_board *brd);
static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
@@ -305,7 +306,7 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
rc = dgnc_tty_init(brd);
if (rc < 0) {
pr_err(DRVSTR ": Can't init tty devices (%d)\n", rc);
- goto unregister_tty;
+ goto free_irq;
}
brd->state = BOARD_READY;
@@ -317,6 +318,8 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
return 0;
+free_irq:
+ dgnc_free_irq(brd);
unregister_tty:
dgnc_tty_unregister(brd);
@@ -577,6 +580,12 @@ static int dgnc_request_irq(struct dgnc_board *brd)
return rc;
}
+static void dgnc_free_irq(struct dgnc_board *brd)
+{
+ if (brd->irq)
+ free_irq(brd->irq, brd);
+}
+
/*
* Remap PCI memory.
*/
--
1.9.1
[PATCH 07/11 V2 RESEND] staging: dgnc: rename dgnc_finalize_board_init() to dgnc_request_irq()
The dgnc_finalize_board_init() function has only job for
requesting the IRQ. It should be renamed to dgnc_request_irq()
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
V2: The subject line was cut off, I put it completely and update
change log.
drivers/staging/dgnc/dgnc_driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index ffe55a2..70e68b5 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -37,7 +37,7 @@ MODULE_SUPPORTED_DEVICE("dgnc");
*
*/
static int dgnc_start(void);
-static int dgnc_finalize_board_init(struct dgnc_board *brd);
+static int dgnc_request_irq(struct dgnc_board *brd);
static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
@@ -296,7 +296,7 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto failed;
}
- rc = dgnc_finalize_board_init(brd);
+ rc = dgnc_request_irq(brd);
if (rc < 0) {
pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
goto unregister_tty;
@@ -558,7 +558,7 @@ failed:
return ERR_PTR(rc);
}
-static int dgnc_finalize_board_init(struct dgnc_board *brd)
+static int dgnc_request_irq(struct dgnc_board *brd)
{
int rc = 0;
--
1.9.1
[PATCH 06/11 RESEND] staging: dgnc: introduce the dgnc_tty_unregister()
The dgnc_tty_unregister() will be called when
the dgnc_tty_register() is failed.
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
drivers/staging/dgnc/dgnc_driver.c | 7 +--
drivers/staging/dgnc/dgnc_tty.c| 8
drivers/staging/dgnc/dgnc_tty.h| 1 +
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index a95d13c..ffe55a2 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -299,13 +299,13 @@ static int dgnc_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
rc = dgnc_finalize_board_init(brd);
if (rc < 0) {
pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
- goto failed;
+ goto unregister_tty;
}
rc = dgnc_tty_init(brd);
if (rc < 0) {
pr_err(DRVSTR ": Can't init tty devices (%d)\n", rc);
- goto failed;
+ goto unregister_tty;
}
brd->state = BOARD_READY;
@@ -317,6 +317,9 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
return 0;
+unregister_tty:
+ dgnc_tty_unregister(brd);
+
failed:
kfree(brd);
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index fd46ef0..893f473 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -273,6 +273,14 @@ free_serial_driver:
return rc;
}
+void dgnc_tty_unregister(struct dgnc_board *brd)
+{
+ tty_unregister_driver(brd->print_driver);
+ tty_unregister_driver(brd->serial_driver);
+ put_tty_driver(brd->print_driver);
+ put_tty_driver(brd->serial_driver);
+}
+
/*
* dgnc_tty_init()
*
diff --git a/drivers/staging/dgnc/dgnc_tty.h b/drivers/staging/dgnc/dgnc_tty.h
index 21d3369..f065c8f 100644
--- a/drivers/staging/dgnc/dgnc_tty.h
+++ b/drivers/staging/dgnc/dgnc_tty.h
@@ -19,6 +19,7 @@
#include "dgnc_driver.h"
intdgnc_tty_register(struct dgnc_board *brd);
+void dgnc_tty_unregister(struct dgnc_board *brd);
intdgnc_tty_preinit(void);
int dgnc_tty_init(struct dgnc_board *);
--
1.9.1
[PATCH 05/11 V2 RESEND] staging: dgnc: move functions unrelated with dgnc_found_board()
The functions related with tty device initialization are needed
to be moved from dgnc_found_board() to dgnc_init_one().
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
V2: The subject line was cut off, I put it completely and update
change log.
drivers/staging/dgnc/dgnc_driver.c | 81 --
1 file changed, 43 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 0114e78..a95d13c 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -38,7 +38,7 @@ MODULE_SUPPORTED_DEVICE("dgnc");
*/
static int dgnc_start(void);
static int dgnc_finalize_board_init(struct dgnc_board *brd);
-static int dgnc_found_board(struct pci_dev *pdev, int id);
+static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
static int dgnc_init_one(struct pci_dev *pdev,
@@ -274,6 +274,7 @@ failed_class:
static int dgnc_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
int rc;
+ struct dgnc_board *brd;
/* wake up and enable device */
rc = pci_enable_device(pdev);
@@ -281,9 +282,43 @@ static int dgnc_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (rc)
return -EIO;
- rc = dgnc_found_board(pdev, ent->driver_data);
- if (rc == 0)
- dgnc_num_boards++;
+ brd = dgnc_found_board(pdev, ent->driver_data);
+ if (IS_ERR(brd))
+ return PTR_ERR(brd);
+
+ /*
+* Do tty device initialization.
+*/
+
+ rc = dgnc_tty_register(brd);
+ if (rc < 0) {
+ pr_err(DRVSTR ": Can't register tty devices (%d)\n", rc);
+ goto failed;
+ }
+
+ rc = dgnc_finalize_board_init(brd);
+ if (rc < 0) {
+ pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
+ goto failed;
+ }
+
+ rc = dgnc_tty_init(brd);
+ if (rc < 0) {
+ pr_err(DRVSTR ": Can't init tty devices (%d)\n", rc);
+ goto failed;
+ }
+
+ brd->state = BOARD_READY;
+ brd->dpastatus = BD_RUNNING;
+
+ dgnc_create_ports_sysfiles(brd);
+
+ dgnc_board[dgnc_num_boards++] = brd;
+
+ return 0;
+
+failed:
+ kfree(brd);
return rc;
}
@@ -345,7 +380,7 @@ static void dgnc_cleanup_board(struct dgnc_board *brd)
*
* A board has been found, init it.
*/
-static int dgnc_found_board(struct pci_dev *pdev, int id)
+static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id)
{
struct dgnc_board *brd;
unsigned int pci_irq;
@@ -355,7 +390,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
/* get the board structure and prep it */
brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
/* store the info for the board we've found */
brd->magic = DGNC_BOARD_MAGIC;
@@ -505,33 +540,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
goto failed;
}
- /*
-* Do tty device initialization.
-*/
-
- rc = dgnc_tty_register(brd);
- if (rc < 0) {
- pr_err(DRVSTR ": Can't register tty devices (%d)\n", rc);
- goto failed;
- }
-
- rc = dgnc_finalize_board_init(brd);
- if (rc < 0) {
- pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
- goto failed;
- }
-
- rc = dgnc_tty_init(brd);
- if (rc < 0) {
- pr_err(DRVSTR ": Can't init tty devices (%d)\n", rc);
- goto failed;
- }
-
- brd->state = BOARD_READY;
- brd->dpastatus = BD_RUNNING;
-
- dgnc_create_ports_sysfiles(brd);
-
/* init our poll helper tasklet */
tasklet_init(&brd->helper_tasklet,
brd->bd_ops->tasklet,
@@ -539,15 +547,12 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
wake_up_interruptible(&brd->state_wait);
- dgnc_board[dgnc_num_boards] = brd;
-
- return 0;
+ return brd;
failed:
- dgnc_tty_uninit(brd);
kfree(brd);
- return rc;
+ return ERR_PTR(rc);
}
static int dgnc_finalize_board_init(struct dgnc_board *brd)
--
1.9.1
Re: [PATCH 1/3] g_NCR5380: Remove deprecated __setup
On Sat, 24 Sep 2016, Ondrej Zary wrote:
> Remove deprecated __setup for parsing command line parameters.
> g_NCR5380.* parameters could be used instead.
Removing useful features is deprecated too.
The best reason I can see for removing the __setup parameters is that the
g_NCR5380 module parameters clash with those of the g_NCR5380_mmio module
(when both are built-in). But only a custom kernel would configure them as
built-in drivers, and it probably would not have both drivers enabled. So
a clash seems unlikely.
Anyway, Christoph seems to be OK with this so I won't object. But if you
assume that no-one has built-in g_NCR5380{,_mmio} drivers, or you believe
that the benefit outweighs the inconvenience of the breakage caused, then
the commit log should explain that.
--
>
> Signed-off-by: Ondrej Zary
> ---
> drivers/scsi/g_NCR5380.c | 135
> --
> 1 file changed, 135 deletions(-)
>
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 516bd6c..7e50b44e 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -56,136 +56,6 @@ static struct override {
>
> #define NO_OVERRIDES ARRAY_SIZE(overrides)
>
> -#ifndef MODULE
> -
> -/**
> - * internal_setup - handle lilo command string override
> - * @board: BOARD_* identifier for the board
> - * @str: unused
> - * @ints: numeric parameters
> - *
> - * Do LILO command line initialization of the overrides array. Display
> - * errors when needed
> - *
> - * Locks: none
> - */
> -
> -static void __init internal_setup(int board, char *str, int *ints)
> -{
> - static int commandline_current;
> - switch (board) {
> - case BOARD_NCR5380:
> - if (ints[0] != 2 && ints[0] != 3) {
> - printk(KERN_ERR "generic_NCR5380_setup : usage
> ncr5380=" STRVAL(NCR5380_map_name) ",irq,dma\n");
> - return;
> - }
> - break;
> - case BOARD_NCR53C400:
> - if (ints[0] != 2) {
> - printk(KERN_ERR "generic_NCR53C400_setup : usage
> ncr53c400=" STRVAL(NCR5380_map_name) ",irq\n");
> - return;
> - }
> - break;
> - case BOARD_NCR53C400A:
> - if (ints[0] != 2) {
> - printk(KERN_ERR "generic_NCR53C400A_setup : usage
> ncr53c400a=" STRVAL(NCR5380_map_name) ",irq\n");
> - return;
> - }
> - break;
> - case BOARD_DTC3181E:
> - if (ints[0] != 2) {
> - printk("generic_DTC3181E_setup : usage dtc3181e="
> STRVAL(NCR5380_map_name) ",irq\n");
> - return;
> - }
> - break;
> - }
> -
> - if (commandline_current < NO_OVERRIDES) {
> - overrides[commandline_current].NCR5380_map_name =
> (NCR5380_map_type) ints[1];
> - overrides[commandline_current].irq = ints[2];
> - if (ints[0] == 3)
> - overrides[commandline_current].dma = ints[3];
> - else
> - overrides[commandline_current].dma = DMA_NONE;
> - overrides[commandline_current].board = board;
> - ++commandline_current;
> - }
> -}
> -
> -
> -/**
> - * do_NCR53C80_setup - set up entry point
> - * @str: unused
> - *
> - * Setup function invoked at boot to parse the ncr5380= command
> - * line.
> - */
> -
> -static int __init do_NCR5380_setup(char *str)
> -{
> - int ints[10];
> -
> - get_options(str, ARRAY_SIZE(ints), ints);
> - internal_setup(BOARD_NCR5380, str, ints);
> - return 1;
> -}
> -
> -/**
> - * do_NCR53C400_setup - set up entry point
> - * @str: unused
> - * @ints: integer parameters from kernel setup code
> - *
> - * Setup function invoked at boot to parse the ncr53c400= command
> - * line.
> - */
> -
> -static int __init do_NCR53C400_setup(char *str)
> -{
> - int ints[10];
> -
> - get_options(str, ARRAY_SIZE(ints), ints);
> - internal_setup(BOARD_NCR53C400, str, ints);
> - return 1;
> -}
> -
> -/**
> - * do_NCR53C400A_setup - set up entry point
> - * @str: unused
> - * @ints: integer parameters from kernel setup code
> - *
> - * Setup function invoked at boot to parse the ncr53c400a= command
> - * line.
> - */
> -
> -static int __init do_NCR53C400A_setup(char *str)
> -{
> - int ints[10];
> -
> - get_options(str, ARRAY_SIZE(ints), ints);
> - internal_setup(BOARD_NCR53C400A, str, ints);
> - return 1;
> -}
> -
> -/**
> - * do_DTC3181E_setup - set up entry point
> - * @str: unused
> - * @ints: integer parameters from kernel setup code
> - *
> - * Setup function invoked at boot to parse the dtc3181e= command
> - * line.
> - */
> -
> -static int __init do_DTC3181E_setup(char *str)
> -{
> - int ints[10];
> -
> - get_options(str, AR
[PATCH 04/11] staging: dgnc: kfree for board structure in dgnc_found_board()
The board structure should be freed when any function was failed
in dgnc_found_board(). And the board strucure will be stored
into dgnc_board array when the dgnc_found_board() function has no error.
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
V2: The subject line was cut off, I put it completely and update
change log.
drivers/staging/dgnc/dgnc_driver.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 58cebf4..0114e78 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -353,9 +353,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
int rc = 0;
/* get the board structure and prep it */
- dgnc_board[dgnc_num_boards] = kzalloc(sizeof(*brd), GFP_KERNEL);
- brd = dgnc_board[dgnc_num_boards];
-
+ brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
return -ENOMEM;
@@ -411,7 +409,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
if (!brd->membase) {
dev_err(&brd->pdev->dev,
"Card has no PCI IO resources, failing.\n");
- return -ENODEV;
+ rc = -ENODEV;
+ goto failed;
}
brd->membase_end = pci_resource_end(pdev, 4);
@@ -502,7 +501,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
default:
dev_err(&brd->pdev->dev,
"Didn't find any compatible Neo/Classic PCI boards.\n");
- return -ENXIO;
+ rc = -ENXIO;
+ goto failed;
}
/*
@@ -539,14 +539,15 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
wake_up_interruptible(&brd->state_wait);
+ dgnc_board[dgnc_num_boards] = brd;
+
return 0;
failed:
dgnc_tty_uninit(brd);
- brd->state = BOARD_FAILED;
- brd->dpastatus = BD_NOFEP;
+ kfree(brd);
- return -ENXIO;
+ return rc;
}
static int dgnc_finalize_board_init(struct dgnc_board *brd)
--
1.9.1
[PATCH 03/11 V2 RESEND] staging: dgnc: missing NULL check for ioremap in dgnc_do_remap()
The ioremap() function can be failed, so it need to have error
handling in dgnc_do_remap(). And also the return type of
dgnc_do_remap() should be changed from "void" to "int"
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
V2: The subject line was cut off, I put it completely and update
change log.
drivers/staging/dgnc/dgnc_driver.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index c87b3de..58cebf4 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -43,7 +43,7 @@ static void dgnc_cleanup_board(struct dgnc_board
*brd);
static voiddgnc_poll_handler(ulong dummy);
static int dgnc_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent);
-static voiddgnc_do_remap(struct dgnc_board *brd);
+static int dgnc_do_remap(struct dgnc_board *brd);
/*
* File operations permitted on Control/Management major.
@@ -431,7 +431,10 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->bd_uart_offset = 0x8;
brd->bd_dividend = 921600;
- dgnc_do_remap(brd);
+ rc = dgnc_do_remap(brd);
+
+ if (rc < 0)
+ goto failed;
/* Get and store the board VPD, if it exists */
brd->bd_ops->vpd(brd);
@@ -483,15 +486,17 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->bd_uart_offset = 0x200;
brd->bd_dividend = 921600;
- dgnc_do_remap(brd);
+ rc = dgnc_do_remap(brd);
- if (brd->re_map_membase) {
- /* Read and store the dvid after remapping */
- brd->dvid = readb(brd->re_map_membase + 0x8D);
+ if (rc < 0)
+ goto failed;
+
+ /* Read and store the dvid after remapping */
+ brd->dvid = readb(brd->re_map_membase + 0x8D);
+
+ /* Get and store the board VPD, if it exists */
+ brd->bd_ops->vpd(brd);
- /* Get and store the board VPD, if it exists */
- brd->bd_ops->vpd(brd);
- }
break;
default:
@@ -566,9 +571,15 @@ static int dgnc_finalize_board_init(struct dgnc_board *brd)
/*
* Remap PCI memory.
*/
-static void dgnc_do_remap(struct dgnc_board *brd)
+static int dgnc_do_remap(struct dgnc_board *brd)
{
+ int rc = 0;
+
brd->re_map_membase = ioremap(brd->membase, 0x1000);
+ if (!brd->re_map_membase)
+ rc = -ENOMEM;
+
+ return rc;
}
/*
--
1.9.1
[PATCH 02/11 RESEND] staging: dgnc: remove useless message buffer
There is a temporary message buffer for the boot message
in dgnc_found_board() but the buffer was not used anywhere in
dgnc driver.
Signed-off-by: Daeseok Youn
---
RESEND: send the whole series again. Because I missed some patches
when the V2 patches sent.
drivers/staging/dgnc/dgnc_driver.c | 28
drivers/staging/dgnc/dgnc_driver.h | 6 --
2 files changed, 34 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index b598034..c87b3de 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -324,17 +324,6 @@ static void dgnc_cleanup_board(struct dgnc_board *brd)
brd->re_map_membase = NULL;
}
- if (brd->msgbuf_head) {
- unsigned long flags;
-
- spin_lock_irqsave(&dgnc_global_lock, flags);
- brd->msgbuf = NULL;
- dev_dbg(&brd->pdev->dev, "%s\n", brd->msgbuf_head);
- kfree(brd->msgbuf_head);
- brd->msgbuf_head = NULL;
- spin_unlock_irqrestore(&dgnc_global_lock, flags);
- }
-
/* Free all allocated channels structs */
for (i = 0; i < MAXPORTS ; i++) {
if (brd->channels[i]) {
@@ -362,7 +351,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
unsigned int pci_irq;
int i = 0;
int rc = 0;
- unsigned long flags;
/* get the board structure and prep it */
dgnc_board[dgnc_num_boards] = kzalloc(sizeof(*brd), GFP_KERNEL);
@@ -371,15 +359,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
if (!brd)
return -ENOMEM;
- /* make a temporary message buffer for the boot messages */
- brd->msgbuf_head = kcalloc(8192, sizeof(u8), GFP_KERNEL);
- brd->msgbuf = brd->msgbuf_head;
-
- if (!brd->msgbuf) {
- kfree(brd);
- return -ENOMEM;
- }
-
/* store the info for the board we've found */
brd->magic = DGNC_BOARD_MAGIC;
brd->boardnum = dgnc_num_boards;
@@ -553,13 +532,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->bd_ops->tasklet,
(unsigned long)brd);
- spin_lock_irqsave(&dgnc_global_lock, flags);
- brd->msgbuf = NULL;
- dev_dbg(&brd->pdev->dev, "%s\n", brd->msgbuf_head);
- kfree(brd->msgbuf_head);
- brd->msgbuf_head = NULL;
- spin_unlock_irqrestore(&dgnc_global_lock, flags);
-
wake_up_interruptible(&brd->state_wait);
return 0;
diff --git a/drivers/staging/dgnc/dgnc_driver.h
b/drivers/staging/dgnc/dgnc_driver.h
index 88d2696..747a100 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -213,12 +213,6 @@ struct dgnc_board {
* as defined by DPA
*/
- /*
-* Mgmt data.
-*/
- char*msgbuf_head;
- char*msgbuf;
-
uintbd_dividend;/* Board/UARTs specific dividend */
struct board_ops *bd_ops;
--
1.9.1
[PATCH 01/11 V2 RESEND] staging: dgnc: remove redundant initialization for channel array
The channel array in board_t was initialized in dgnc_found_board() with NULL. But the channel is going to initialize in dgnc_tty_init(). So the channel array doesn't need to set NULL for initailization. Signed-off-by: Daeseok Youn --- RESEND: send the whole series again. Because I missed some patches when the V2 patches sent. V2: The subject line was cut off, I put it completely and update change log. drivers/staging/dgnc/dgnc_driver.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_driver.c b/drivers/staging/dgnc/dgnc_driver.c index 01e948c..b598034 100644 --- a/drivers/staging/dgnc/dgnc_driver.c +++ b/drivers/staging/dgnc/dgnc_driver.c @@ -400,9 +400,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id) brd->state = BOARD_FOUND; - for (i = 0; i < MAXPORTS; i++) - brd->channels[i] = NULL; - /* store which card & revision we have */ pci_read_config_word(pdev, PCI_SUBSYSTEM_VENDOR_ID, &brd->subvendor); pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &brd->subdevice); -- 1.9.1
Re: [PATCH 4/3] g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio
On Sun, 25 Sep 2016, Christoph Hellwig wrote:
> On Sun, Sep 25, 2016 at 09:39:20PM +0200, Ondrej Zary wrote:
>
> > #define NCR5380_read(reg) \
> > + ioread8(((struct NCR5380_hostdata *)shost_priv(instance))->iomem + \
> > + ((struct NCR5380_hostdata *)shost_priv(instance))->offset + \
> > + (reg))
> > #define NCR5380_write(reg, value) \
> > - outb(value, instance->io_port + (reg))
> > + iowrite8(value, ((struct NCR5380_hostdata
> > *)shost_priv(instance))->iomem + \
> > + ((struct NCR5380_hostdata *)shost_priv(instance))->offset + \
> > + (reg))
>
> Can we make these #defines point to inline helper functions that avoid
> the casting magic, e.g. something like
>
> static inline void g_NCR5380_write(struct Scsi_Host *instance, u32 reg,
> u8 value)
> {
> struct NCR5380_hostdata *host = shost_priv(instance);
>
> iowrite8(value, host->iomem, host->offset + reg);
> }
>
> #define NCR5380_write(reg, value)
> g_NCR5380_write(instance, reg, value)
Let's not do that yet. I have a patch series that fixes the type casting
and related issues that I will post soon. I expect that Ondrej's patches
will be ready before mine are, so I'll rebase mine on this work before I
ask him to test my patches.
--
Re: [PATCH 01/11 V2] staging: dgnc: remove redundant initialization for channel array
2016-09-23 21:15 GMT+09:00 Greg KH : > On Fri, Sep 23, 2016 at 10:25:02AM +0900, Daeseok Youn wrote: >> The channel array in board_t was initialized in dgnc_found_board() >> with NULL. But the channel is going to initialize in dgnc_tty_init() >> again. So the channel array doesn't need to set NULL >> for initailization in dgnc_found_board(). >> >> Signed-off-by: Daeseok Youn >> --- >> V2: The subject line was cut off, I put it completely and update >> change log. > > I only got 6 patches of an 11 patch series here, what happened? I sent only updated 6 patches of series, I will resend 11 patches again. Thanks. Regards, Daeseok Youn. > > Please resend the whole series. > > thanks, > > greg k-h
[PATCH 4/5] irqtime: Consolidate accounting synchronization with u64_stats API
The irqtime accounting currently implement its own ad hoc implementation
of u64_stats API. Lets rather consolidate it with the appropriate
library.
Reviewed-by: Rik van Riel
Cc: Paolo Bonzini
Cc: Wanpeng Li
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Eric Dumazet
Cc: Rik van Riel
Signed-off-by: Frederic Weisbecker
---
kernel/sched/cputime.c | 31 +---
kernel/sched/sched.h | 55 +++---
2 files changed, 30 insertions(+), 56 deletions(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 94b1a72..1cea2f1 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -23,10 +23,8 @@
* task when irq is in progress while we read rq->clock. That is a worthy
* compromise in place of having locks on each irq in account_system_time.
*/
-DEFINE_PER_CPU(u64, cpu_hardirq_time);
-DEFINE_PER_CPU(u64, cpu_softirq_time);
+DEFINE_PER_CPU(struct irqtime, cpu_irqtime);
-static DEFINE_PER_CPU(u64, irq_start_time);
static int sched_clock_irqtime;
void enable_sched_clock_irqtime(void)
@@ -39,16 +37,13 @@ void disable_sched_clock_irqtime(void)
sched_clock_irqtime = 0;
}
-#ifndef CONFIG_64BIT
-DEFINE_PER_CPU(seqcount_t, irq_time_seq);
-#endif /* CONFIG_64BIT */
-
/*
* Called before incrementing preempt_count on {soft,}irq_enter
* and before decrementing preempt_count on {soft,}irq_exit.
*/
void irqtime_account_irq(struct task_struct *curr)
{
+ struct irqtime *irqtime = this_cpu_ptr(&cpu_irqtime);
s64 delta;
int cpu;
@@ -56,10 +51,10 @@ void irqtime_account_irq(struct task_struct *curr)
return;
cpu = smp_processor_id();
- delta = sched_clock_cpu(cpu) - __this_cpu_read(irq_start_time);
- __this_cpu_add(irq_start_time, delta);
+ delta = sched_clock_cpu(cpu) - irqtime->irq_start_time;
+ irqtime->irq_start_time += delta;
- irq_time_write_begin();
+ u64_stats_update_begin(&irqtime->sync);
/*
* We do not account for softirq time from ksoftirqd here.
* We want to continue accounting softirq time to ksoftirqd thread
@@ -67,11 +62,11 @@ void irqtime_account_irq(struct task_struct *curr)
* that do not consume any time, but still wants to run.
*/
if (hardirq_count())
- __this_cpu_add(cpu_hardirq_time, delta);
+ irqtime->hardirq_time += delta;
else if (in_serving_softirq() && curr != this_cpu_ksoftirqd())
- __this_cpu_add(cpu_softirq_time, delta);
+ irqtime->softirq_time += delta;
- irq_time_write_end();
+ u64_stats_update_end(&irqtime->sync);
}
EXPORT_SYMBOL_GPL(irqtime_account_irq);
@@ -79,9 +74,10 @@ static cputime_t irqtime_account_hi_update(cputime_t maxtime)
{
u64 *cpustat = kcpustat_this_cpu->cpustat;
cputime_t irq_cputime;
+ u64 nsecs;
- irq_cputime = nsecs_to_cputime64(__this_cpu_read(cpu_hardirq_time)) -
- cpustat[CPUTIME_IRQ];
+ nsecs = __this_cpu_read(cpu_irqtime.hardirq_time);
+ irq_cputime = nsecs_to_cputime64(nsecs) - cpustat[CPUTIME_IRQ];
irq_cputime = min(irq_cputime, maxtime);
cpustat[CPUTIME_IRQ] += irq_cputime;
@@ -92,9 +88,10 @@ static cputime_t irqtime_account_si_update(cputime_t maxtime)
{
u64 *cpustat = kcpustat_this_cpu->cpustat;
cputime_t softirq_cputime;
+ u64 nsecs;
- softirq_cputime = nsecs_to_cputime64(__this_cpu_read(cpu_softirq_time))
-
- cpustat[CPUTIME_SOFTIRQ];
+ nsecs = __this_cpu_read(cpu_irqtime.softirq_time);
+ softirq_cputime = nsecs_to_cputime64(nsecs) - cpustat[CPUTIME_SOFTIRQ];
softirq_cputime = min(softirq_cputime, maxtime);
cpustat[CPUTIME_SOFTIRQ] += softirq_cputime;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 420c05d..daf9193 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1711,52 +1712,28 @@ static inline void nohz_balance_exit_idle(unsigned int
cpu) { }
#endif
#ifdef CONFIG_IRQ_TIME_ACCOUNTING
-
-DECLARE_PER_CPU(u64, cpu_hardirq_time);
-DECLARE_PER_CPU(u64, cpu_softirq_time);
-
-#ifndef CONFIG_64BIT
-DECLARE_PER_CPU(seqcount_t, irq_time_seq);
-
-static inline void irq_time_write_begin(void)
-{
- __this_cpu_inc(irq_time_seq.sequence);
- smp_wmb();
-}
-
-static inline void irq_time_write_end(void)
-{
- smp_wmb();
- __this_cpu_inc(irq_time_seq.sequence);
-}
+struct irqtime {
+ u64 hardirq_time;
+ u64 softirq_time;
+ u64 irq_start_time;
+ struct u64_stats_sync sync;
+};
+
+DECLARE_PER_CPU(struct irqtime, cpu_irqtime);
static inline u64 irq_time_read(int cpu)
{
- u64 irq_time;
- unsigned seq;
+ struct irqtime *i
[PATCH 3/5] u64_stats: Introduce IRQs disabled helpers
Introduce light versions of u64_stats helpers for context where
either preempt or IRQs are disabled. This way we can make this library
usable by scheduler irqtime accounting which currenty implement its
ad-hoc version.
Cc: Rik van Riel
Cc: Paolo Bonzini
Cc: Wanpeng Li
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Eric Dumazet
Signed-off-by: Frederic Weisbecker
---
include/linux/u64_stats_sync.h | 51 ++
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
index d3a2bb7..650f3dd 100644
--- a/include/linux/u64_stats_sync.h
+++ b/include/linux/u64_stats_sync.h
@@ -103,29 +103,40 @@ static inline void u64_stats_update_end_raw(struct
u64_stats_sync *syncp)
#endif
}
+static inline unsigned int __u64_stats_fetch_begin(const struct u64_stats_sync
*syncp)
+{
+#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
+ return read_seqcount_begin(&syncp->seq);
+#else
+ return 0;
+#endif
+}
+
static inline unsigned int u64_stats_fetch_begin(const struct u64_stats_sync
*syncp)
{
-#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
- return read_seqcount_begin(&syncp->seq);
-#else
-#if BITS_PER_LONG==32
+#if BITS_PER_LONG==32 && !defined(CONFIG_SMP)
preempt_disable();
#endif
- return 0;
+ return __u64_stats_fetch_begin(syncp);
+}
+
+static inline bool __u64_stats_fetch_retry(const struct u64_stats_sync *syncp,
+unsigned int start)
+{
+#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
+ return read_seqcount_retry(&syncp->seq, start);
+#else
+ return false;
#endif
}
static inline bool u64_stats_fetch_retry(const struct u64_stats_sync *syncp,
unsigned int start)
{
-#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
- return read_seqcount_retry(&syncp->seq, start);
-#else
-#if BITS_PER_LONG==32
+#if BITS_PER_LONG==32 && !defined(CONFIG_SMP)
preempt_enable();
#endif
- return false;
-#endif
+ return __u64_stats_fetch_retry(syncp, start);
}
/*
@@ -136,27 +147,19 @@ static inline bool u64_stats_fetch_retry(const struct
u64_stats_sync *syncp,
*/
static inline unsigned int u64_stats_fetch_begin_irq(const struct
u64_stats_sync *syncp)
{
-#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
- return read_seqcount_begin(&syncp->seq);
-#else
-#if BITS_PER_LONG==32
+#if BITS_PER_LONG==32 && !defined(CONFIG_SMP)
local_irq_disable();
#endif
- return 0;
-#endif
+ return __u64_stats_fetch_begin(syncp);
}
static inline bool u64_stats_fetch_retry_irq(const struct u64_stats_sync
*syncp,
-unsigned int start)
+unsigned int start)
{
-#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
- return read_seqcount_retry(&syncp->seq, start);
-#else
-#if BITS_PER_LONG==32
+#if BITS_PER_LONG==32 && !defined(CONFIG_SMP)
local_irq_enable();
#endif
- return false;
-#endif
+ return __u64_stats_fetch_retry(syncp, start);
}
#endif /* _LINUX_U64_STATS_SYNC_H */
--
2.7.4
[PATCH 2/5] irqtime: Remove needless IRQs disablement on kcpustat update
The callers of the functions performing irqtime kcpustat updates have
IRQS disabled, no need to disable them again.
Reviewed-by: Rik van Riel
Cc: Paolo Bonzini
Cc: Wanpeng Li
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Eric Dumazet
Cc: Rik van Riel
Signed-off-by: Frederic Weisbecker
---
kernel/sched/cputime.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index f111076..94b1a72 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -78,30 +78,26 @@ EXPORT_SYMBOL_GPL(irqtime_account_irq);
static cputime_t irqtime_account_hi_update(cputime_t maxtime)
{
u64 *cpustat = kcpustat_this_cpu->cpustat;
- unsigned long flags;
cputime_t irq_cputime;
- local_irq_save(flags);
irq_cputime = nsecs_to_cputime64(__this_cpu_read(cpu_hardirq_time)) -
cpustat[CPUTIME_IRQ];
irq_cputime = min(irq_cputime, maxtime);
cpustat[CPUTIME_IRQ] += irq_cputime;
- local_irq_restore(flags);
+
return irq_cputime;
}
static cputime_t irqtime_account_si_update(cputime_t maxtime)
{
u64 *cpustat = kcpustat_this_cpu->cpustat;
- unsigned long flags;
cputime_t softirq_cputime;
- local_irq_save(flags);
softirq_cputime = nsecs_to_cputime64(__this_cpu_read(cpu_softirq_time))
-
cpustat[CPUTIME_SOFTIRQ];
softirq_cputime = min(softirq_cputime, maxtime);
cpustat[CPUTIME_SOFTIRQ] += softirq_cputime;
- local_irq_restore(flags);
+
return softirq_cputime;
}
@@ -295,6 +291,9 @@ static inline cputime_t account_other_time(cputime_t max)
{
cputime_t accounted;
+ /* Shall be converted to a lockdep-enabled lightweight check */
+ WARN_ON_ONCE(!irqs_disabled());
+
accounted = steal_account_process_time(max);
if (accounted < max)
--
2.7.4
[PATCH 5/5] irqtime: Consolidate irqtime flushing code
The code performing irqtime nsecs stats flushing to kcpustat is roughly
the same for hardirq and softirq. So lets consolidate that common code.
Reviewed-by: Rik van Riel
Cc: Paolo Bonzini
Cc: Wanpeng Li
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Eric Dumazet
Cc: Rik van Riel
Signed-off-by: Frederic Weisbecker
---
kernel/sched/cputime.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 1cea2f1..5ebee31 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -70,32 +70,28 @@ void irqtime_account_irq(struct task_struct *curr)
}
EXPORT_SYMBOL_GPL(irqtime_account_irq);
-static cputime_t irqtime_account_hi_update(cputime_t maxtime)
+static cputime_t irqtime_account_update(u64 irqtime, int idx, cputime_t
maxtime)
{
u64 *cpustat = kcpustat_this_cpu->cpustat;
cputime_t irq_cputime;
- u64 nsecs;
- nsecs = __this_cpu_read(cpu_irqtime.hardirq_time);
- irq_cputime = nsecs_to_cputime64(nsecs) - cpustat[CPUTIME_IRQ];
+ irq_cputime = nsecs_to_cputime64(irqtime) - cpustat[idx];
irq_cputime = min(irq_cputime, maxtime);
- cpustat[CPUTIME_IRQ] += irq_cputime;
+ cpustat[idx] += irq_cputime;
return irq_cputime;
}
+static cputime_t irqtime_account_hi_update(cputime_t maxtime)
+{
+ return irqtime_account_update(__this_cpu_read(cpu_irqtime.hardirq_time),
+ CPUTIME_IRQ, maxtime);
+}
+
static cputime_t irqtime_account_si_update(cputime_t maxtime)
{
- u64 *cpustat = kcpustat_this_cpu->cpustat;
- cputime_t softirq_cputime;
- u64 nsecs;
-
- nsecs = __this_cpu_read(cpu_irqtime.softirq_time);
- softirq_cputime = nsecs_to_cputime64(nsecs) - cpustat[CPUTIME_SOFTIRQ];
- softirq_cputime = min(softirq_cputime, maxtime);
- cpustat[CPUTIME_SOFTIRQ] += softirq_cputime;
-
- return softirq_cputime;
+ return irqtime_account_update(__this_cpu_read(cpu_irqtime.softirq_time),
+ CPUTIME_SOFTIRQ, maxtime);
}
#else /* CONFIG_IRQ_TIME_ACCOUNTING */
--
2.7.4
[PATCH 1/5] irqtime: No need for preempt-safe accessors
We can safely use the preempt-unsafe accessors for irqtime when we flush its counters to kcpustat as IRQs are disabled at this time. Reviewed-by: Rik van Riel Cc: Paolo Bonzini Cc: Wanpeng Li Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: Rik van Riel Signed-off-by: Frederic Weisbecker --- kernel/sched/cputime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index b93c72d..f111076 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -82,7 +82,7 @@ static cputime_t irqtime_account_hi_update(cputime_t maxtime) cputime_t irq_cputime; local_irq_save(flags); - irq_cputime = nsecs_to_cputime64(this_cpu_read(cpu_hardirq_time)) - + irq_cputime = nsecs_to_cputime64(__this_cpu_read(cpu_hardirq_time)) - cpustat[CPUTIME_IRQ]; irq_cputime = min(irq_cputime, maxtime); cpustat[CPUTIME_IRQ] += irq_cputime; @@ -97,7 +97,7 @@ static cputime_t irqtime_account_si_update(cputime_t maxtime) cputime_t softirq_cputime; local_irq_save(flags); - softirq_cputime = nsecs_to_cputime64(this_cpu_read(cpu_softirq_time)) - + softirq_cputime = nsecs_to_cputime64(__this_cpu_read(cpu_softirq_time)) - cpustat[CPUTIME_SOFTIRQ]; softirq_cputime = min(softirq_cputime, maxtime); cpustat[CPUTIME_SOFTIRQ] += softirq_cputime; -- 2.7.4
[PATCH 0/5] sched/cputime: irqtime cleanups v2
This second version fixes the ifdeffery issues reported by Paolo Bonzini and includes Rick's reviewed-by tags. I also intended to include Peterz's patch for lockdep assertion on irqs disabled but unfortunately I get false positives as irqs_disabled() doesn't always imply !current->hardirqs_enabled. This seems to happen during the boot with IRQs interrupting lockdep internals while current->lockdep_recursion == 1. Therefore the trace_hardirqs_off() on x86 IRQ entry gets ignored. I'll investigate further and try to get that fixed in order to introduce lockdep_assert_irqs_disabled() properly but that's outside the scope of this patchset now. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git sched/irqtime-v2 HEAD: e336b2491bf02e95ff3387e7d7a8276b22c8b5f3 Thanks, Frederic --- Frederic Weisbecker (5): irqtime: No need for preempt-safe accessors irqtime: Remove needless IRQs disablement on kcpustat update u64_stats: Introduce IRQs disabled helpers irqtime: Consolidate accounting synchronization with u64_stats API irqtime: Consolidate irqtime flushing code include/linux/u64_stats_sync.h | 45 +++ kernel/sched/cputime.c | 54 ++ kernel/sched/sched.h | 53 - 3 files changed, 62 insertions(+), 90 deletions(-)
[PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error
From: Dave Chinner
When building XFS with -Werror, it now fails with:
./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used
[-Werror=unused-but-set-variable]
volatile char c;
^
This is a regression caused by commit e23d415 ("fix
fault_in_multipages_...() on architectures with no-op access_ok()").
Fix it by re-adding the "(void)c" trick taht was previously used to
make the compiler think the variable is used.
Signed-off-by: Dave Chinner
---
include/linux/pagemap.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 7e3d537..01e8443 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -620,6 +620,7 @@ static inline int fault_in_multipages_readable(const char
__user *uaddr,
return __get_user(c, end);
}
+ (void)c;
return 0;
}
--
2.8.0.rc3
Re: [PATCH 4/3] g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio
On Sun, Sep 25, 2016 at 09:39:20PM +0200, Ondrej Zary wrote:
> Merge the PIO and MMIO code (with the help of ioport_map) in g_NCR5380 and
> delete g_NCR5380_mmio.
Awesome! this looks great to me, but we probably should thrown
in a MODULE_ALIAS for g_NCR5380_mmio so that existing module
configurations keep working.
> #define NCR5380_read(reg) \
> + ioread8(((struct NCR5380_hostdata *)shost_priv(instance))->iomem + \
> + ((struct NCR5380_hostdata *)shost_priv(instance))->offset + \
> + (reg))
> #define NCR5380_write(reg, value) \
> - outb(value, instance->io_port + (reg))
> + iowrite8(value, ((struct NCR5380_hostdata
> *)shost_priv(instance))->iomem + \
> + ((struct NCR5380_hostdata *)shost_priv(instance))->offset + \
> + (reg))
Can we make these #defines point to inline helper functions that avoid
the casting magic, e.g. something like
static inline void g_NCR5380_write(struct Scsi_Host *instance, u32 reg,
u8 value)
{
struct NCR5380_hostdata *host = shost_priv(instance);
iowrite8(value, host->iomem, host->offset + reg);
}
#define NCR5380_write(reg, value)
g_NCR5380_write(instance, reg, value)
Re: [PATCH 3/3] g_NCR5380: Stop using scsi_module.c
> +static int generic_NCR5380_isa_match(struct device *pdev, unsigned int ndev)
> +{
> + struct Scsi_Host *sh = NULL;
> +
> + sh = generic_NCR5380_hw_init(&driver_template, pdev, base[ndev],
> + irq[ndev], card[ndev]);
> + if (!sh && base[ndev])
> + printk(KERN_WARNING "Card not found at address 0x%03x\n",
> + base[ndev]);
> + if (!sh)
> + return 0;
>
> + dev_set_drvdata(pdev, sh);
Any reason not to move the dev_set_drvdata into generic_NCR5380_hw_init?
That would also allow to properly propagate the error down to the
caller, which would be useful for the PNP case.
Otherwise this look great to me.
Re: [PATCH 2/3] g_NCR5380: Reduce overrides[] from array to struct
On Sat, Sep 24, 2016 at 08:59:04PM +0200, Ondrej Zary wrote: > Remove compile-time card type definition GENERIC_NCR5380_OVERRIDE. > Then remove all code iterating the overrides[] array and reduce it to > struct card. > > Signed-off-by: Ondrej Zary Looks great! Reviewed-by: Christoph Hellwig
Re: [PATCH 1/3] g_NCR5380: Remove deprecated __setup
On Sat, Sep 24, 2016 at 08:59:03PM +0200, Ondrej Zary wrote: > Remove deprecated __setup for parsing command line parameters. > g_NCR5380.* parameters could be used instead. This assumes everyone has moved over to it. But I suspect the remaining hand full of users could adjust..
Re: [PATCH 3/6] isdn/hisax: add function declarations
On Sunday 25 September 2016, Baoyou Xie wrote: > > > @@ -1350,3 +1350,63 @@ static inline struct pci_dev > > *hisax_find_pci_device(unsigned int vendor, > > > } > > > > > > #endif > > > + > > > +#if CARD_TELES3 > > > +int setup_teles3(struct IsdnCard *card); > > > +#endif > > > + > > > +#if CARD_TELESPCI > > > +int setup_telespci(struct IsdnCard *card); > > > +#endif > > > + > > > > When you add the declarations here, just leave out the #if guards, > > and put all the declarations here unconditionally, as we normally > > do in the kernel. > > > > oh, in this case, we can leave the declarations out the #if guards. > but I suggest we don't do that still, cause of some declarations used by > function parameters may reply on the macro. They all have the same 'struct IsdnCard' argument, which is already visible (otherwise none of them would work). Arnd
