Re: [PATCH 2/5] x86/intel_rdt: Improvements to parsing schemata
On Fri, 10 Mar 2017, Luck, Tony wrote: > On Fri, Mar 10, 2017 at 07:58:51PM +0100, Thomas Gleixner wrote: > > Well, we have several options to tackle this: > > > > 1) Have schemata files for each resource > > > >schemata_l2, _l3 _mb > > > > 2) Request a full overwrite every time (all entries required) > > > >That still does not require ordering > > > > 3) Allow full overwrite and 'append' mode > > > >echo "" > schemata > > > >Overwrites the whole file. It does not require all entries to be > >supplied. Non supplied entries are reset to default > > > >echo "" >> schemata > > > >"Appends" the supplied entries by overwriting the existing ones. > > > > My favourite would be #1, but I have no strong opinions other than not > > caring about resource write ordering for #2 and #3. > > If you are going to head in the direction of partial update, then > why not go for: > > 4) Drop the code that check that the user wrote all >the fields as well as the check for all the lines. Just update >the bits they list, and leave the rest unchanged. > > I.e. the user could say: > > # echo "L3:1=0x3f" > schemata > > if they just wanted to update resource L3, instance 1. Even better > I don't think there is much benefit to the overwrite vs. append > semantics for the user. Agreed. Thanks, tglx
[GIT PULL] Staging driver warning fixes for 4.11-rc2
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.11-rc2 for you to fetch changes up to 69eb1596b4df8ca834ba6f9a3df40f78943f6dca: staging: octeon: remove unused variable (2017-03-08 09:45:07 +0100) Staging driver fixes for 4.11-rc2 Here are two small build warning fixes for some staging drivers that Arnd has found on his valiant quest to get the kernel to build properly with no warnings. Both of these have been in linux-next this week and resolve the reported issues. Signed-off-by: Greg Kroah-Hartman Arnd Bergmann (2): staging/vc04_services: add CONFIG_OF dependency staging: octeon: remove unused variable drivers/staging/octeon/ethernet-rx.c | 1 - drivers/staging/vc04_services/Kconfig | 1 + 2 files changed, 1 insertion(+), 1 deletion(-)
[GIT PULL] TTY/Serial driver fixes for 4.11-rc2
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.11-rc2 for you to fetch changes up to f98c7bce570bdbe344b74ff5daa7dfeef3f22929: serial: samsung: Continue to work if DMA request fails (2017-03-07 19:58:37 +0100) TTY/Serial fixes for 4.11-rc2 Here are 2 bugfixes for tty stuff for 4.11-rc2. One of them resolves the pretty bad bug in the n_hdlc code that Alexander Popov found and fixed and has been reported everywhere. The other just fixes a samsung serial driver issue when DMA fails on some systems. Both have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Alexander Popov (1): tty: n_hdlc: get rid of racy n_hdlc.tbuf Krzysztof Kozlowski (1): serial: samsung: Continue to work if DMA request fails drivers/tty/n_hdlc.c | 132 ++- drivers/tty/serial/samsung.c | 6 +- 2 files changed, 73 insertions(+), 65 deletions(-)
[GIT PULL] USB/PHY driver fixes for 4.11-rc2
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-4.11-rc2
for you to fetch changes up to dcc7620cad5ad1326a78f4031a7bf4f0e5b42984:
usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci
controllers (2017-03-09 18:00:39 +0100)
USB fixes for 4.11-rc2
Here is a number of different USB fixes for 4.11-rc2. Seems like there
were a lot of unresolved issues that people have been finding for this
subsystem, and a bunch of good security auditing happening as well from
Johan Hovold. There's the usual batch of gadget driver fixes and xhci
issues resolved as well.
All of these have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman
Arnd Bergmann (1):
usb: gadget: udc: atmel: fix debug output
Christophe JAILLET (1):
USB: gadgetfs: Fix a potential memory leak in 'dev_config()'
Chunfeng Yun (2):
usb: xhci-mtk: check hcc_params after adding primary hcd
usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct
Felipe Balbi (4):
usb: dwc3: gadget: make Set Endpoint Configuration macros safe
usb: gadget: function: f_fs: pass companion descriptor along
usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue
usb: dwc3: gadget: make to increment req->remaining in all cases
Franck Demathieu (1):
usb: dwc3: Fix incorrect type for utmi mode
Greg Kroah-Hartman (2):
Merge tag 'fixes-for-v4.11-rc2' of git://git.kernel.org/.../balbi/usb
into usb-linus
Merge tag 'usb-serial-4.11-rc2' of
git://git.kernel.org/.../johan/usb-serial into usb-linus
Guenter Roeck (1):
usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci
controllers
Janusz Dziedzic (1):
Revert "usb: gadget: f_fs: Fix ExtCompat descriptor validation"
Javier Martinez Canillas (1):
usb: phy: isp1301: Add OF device ID table
Jelle Martijn Kok (1):
usb: ohci-at91: Do not drop unhandled USB suspend control requests
Johan Hovold (9):
USB: serial: digi_acceleport: fix OOB-event processing
USB: serial: io_ti: fix NULL-deref in interrupt callback
USB: serial: omninet: fix reference leaks at open
USB: serial: omninet: drop open callback
USB: serial: io_ti: fix information leak in completion handler
USB: serial: safe_serial: fix information leak in completion handler
USB: iowarrior: fix NULL-deref at probe
USB: iowarrior: fix NULL-deref in write
USB: serial: digi_acceleport: fix OOB-event processing
John Keeping (1):
usb: gadget: configs: plug memory leak
Peter Chen (2):
usb: gadget: dummy_hcd: clear usb_gadget region before registration
usb: host: xhci-dbg: HCIVERSION should be a binary number
Petr Cvek (1):
usb: gadget: pxa27x: Test for a valid argument pointer
Raz Manor (1):
usb: gadget: udc: net2280: Fix tmp reusage in net2280 driver
Richard Leitner (4):
usb: usb251xb: remove max_{power,current}_{sp,bp} properties
usb: usb251xb: dt: add unit suffix to oc-delay and power-on-time
doc: dt-bindings: usb251xb: mark reg as required
MAINTAINERS: usb251xb: remove reference inexistent file
Roger Quadros (3):
Revert "usb: gadget: uvc: Add missing call for additional setup data"
usb: dwc3: gadget: Fix system suspend/resume on TI platforms
usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()
Tobias Jakobi (1):
usb-storage: Add ignore-residue quirk for Initio INIC-3619
Documentation/devicetree/bindings/usb/usb251xb.txt | 53 +--
MAINTAINERS| 1 -
drivers/usb/dwc3/dwc3-omap.c | 3 +-
drivers/usb/dwc3/gadget.c | 76 +++---
drivers/usb/dwc3/gadget.h | 14 ++--
drivers/usb/gadget/configfs.c | 1 +
drivers/usb/gadget/function/f_fs.c | 17 -
drivers/usb/gadget/function/f_uvc.c| 7 --
drivers/usb/gadget/legacy/inode.c | 4 +-
drivers/usb/gadget/udc/atmel_usba_udc.c| 4 +-
drivers/usb/gadget/udc/dummy_hcd.c | 2 +
drivers/usb/gadget/udc/net2280.c | 25 +++
drivers/usb/gadget/udc/pxa27x_udc.c| 5 +-
drivers/usb/host/ohci-at91.c | 4 +-
drivers/usb/host/xhci-dbg.c| 2 +-
drivers/usb/host/xhci-mtk.c| 7 +-
drivers/usb/host/xhci-plat.c | 2 +
drivers/usb/host/xhci-tegra.c | 1 -
drivers/usb/misc/iowarrior.c | 21 --
drivers/usb/misc/usb251x
Re: [PATCH v5 01/19] block: DAC960: Replace PCI pool old API
Hi Romain, [auto build test WARNING on scsi/for-next] [also build test WARNING on v4.11-rc1 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Romain-Perier/Replace-PCI-pool-by-DMA-pool-API/20170311-133849 base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next coccinelle warnings: (new ones prefixed by >>) >> drivers/block/DAC960.c:441:3-19: WARNING: NULL check before freeing >> functions like kfree, debugfs_remove, debugfs_remove_recursive or >> usb_free_urb is not needed. Maybe consider reorganizing relevant code to >> avoid passing NULL values. drivers/block/DAC960.c:446:1-17: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] block: DAC960: fix ifnullfree.cocci warnings
drivers/block/DAC960.c:441:3-19: WARNING: NULL check before freeing functions
like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not
needed. Maybe consider reorganizing relevant code to avoid passing NULL values.
drivers/block/DAC960.c:446:1-17: WARNING: NULL check before freeing functions
like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not
needed. Maybe consider reorganizing relevant code to avoid passing NULL values.
NULL check before some freeing functions is not needed.
Based on checkpatch warning
"kfree(NULL) is safe this check is probably not required"
and kfreeaddr.cocci by Julia Lawall.
Generated by: scripts/coccinelle/free/ifnullfree.cocci
CC: Romain Perier
Signed-off-by: Fengguang Wu
---
DAC960.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -437,13 +437,11 @@ static void DAC960_DestroyAuxiliaryStruc
Controller->CurrentStatusBuffer = NULL;
}
- if (ScatterGatherPool != NULL)
- dma_pool_destroy(ScatterGatherPool);
+ dma_pool_destroy(ScatterGatherPool);
if (Controller->FirmwareType == DAC960_V1_Controller)
return;
- if (RequestSensePool != NULL)
- dma_pool_destroy(RequestSensePool);
+ dma_pool_destroy(RequestSensePool);
for (i = 0; i < DAC960_MaxLogicalDrives; i++) {
kfree(Controller->V2.LogicalDeviceInformation[i]);
Re: [Outreachy kernel] [PATCH 1/3] staging: sm750fb: function prototype argument should have an identifier name
On Sat, 11 Mar 2017, Arushi Singhal wrote:
> function prototype arguments like 'struct vb_device_info *','unsigned
> long' etc. should have an identifier name.
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/sm750fb/ddk750_display.h | 2 +-
> drivers/staging/sm750fb/ddk750_mode.h| 2 +-
> drivers/staging/sm750fb/ddk750_power.h | 2 +-
> drivers/staging/sm750fb/sm750.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_display.h
> b/drivers/staging/sm750fb/ddk750_display.h
> index e2a3f84ca4c5..609bf742efff 100644
> --- a/drivers/staging/sm750fb/ddk750_display.h
> +++ b/drivers/staging/sm750fb/ddk750_display.h
> @@ -102,6 +102,6 @@ typedef enum _disp_output_t {
> }
> disp_output_t;
>
> -void ddk750_setLogicalDispOut(disp_output_t);
> +void ddk750_setLogicalDispOut(disp_output_t output);
>
> #endif
> diff --git a/drivers/staging/sm750fb/ddk750_mode.h
> b/drivers/staging/sm750fb/ddk750_mode.h
> index 2183e664cf4b..6d204b8b4a01 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.h
> +++ b/drivers/staging/sm750fb/ddk750_mode.h
> @@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
> }
> mode_parameter_t;
>
> -int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
> +int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
There are typedefs here that you could get rid of in a future patch.
>
> #endif
> diff --git a/drivers/staging/sm750fb/ddk750_power.h
> b/drivers/staging/sm750fb/ddk750_power.h
> index ec0b99d6a7ad..44c4fc587e96 100644
> --- a/drivers/staging/sm750fb/ddk750_power.h
> +++ b/drivers/staging/sm750fb/ddk750_power.h
> @@ -14,7 +14,7 @@ DPMS_t;
> (peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
> }
>
> -void ddk750_set_dpms(DPMS_t);
> +void ddk750_set_dpms(DPMS_t state);
> void sm750_set_power_mode(unsigned int powerMode);
> void sm750_set_current_gate(unsigned int gate);
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index 306711ed55f9..5ea455dee949 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -184,7 +184,7 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
> }
>
> int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> -int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
> +int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> void hw_sm750_initAccel(struct sm750_dev *);
This prototype should be updated too.
julia
> int hw_sm750_deWait(void);
> int hw_sm750le_deWait(void);
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170311032410.8265-2-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: enable USB Host Nodes
Hi Martin,
On 10 March 2017 at 01:06, Martin Blumenstingl
wrote:
> Hi Anand,
>
> On Thu, Mar 9, 2017 at 6:58 PM, Anand Moon wrote:
>>> Hi Anand,
>>>
>>> For this specific use case, the only way to manage this is to use the
>>> Work-In-Progress
>>> Power Sequence Library proposer by Peter Chen at :
>>> https://lkml.org/lkml/2016/11/13/315
>>>
>>> Since this is the USB Hub reset link and has no direct link with either the
>>> USB controller
>>> or the USB PHY, and the USB Hus cannot be modeled (yet ?) in the DT.
>>>
>>> One intermediate, but crappy, solution would be to add a GPIO hog until the
>>> power
>>> sequence code has been merged, with a proper big fat warning in the dts
>>> file.
>>>
>>> You can find doc about the gpio-hog in :
>>> Documentation/devicetree/bindings/gpio/gpio.txt
>>>
>>> It should look like :
>>>
>>> usb-hub {
>>> gpio-hog;
>>> gpios = ;
>>> output-high;
>>> line-name = "usb-hub-reset";
>>> };
>>>
>>> in the gpio_ao controller node.
>>>
>>> Neil
>>
>> Thanks for this input.
>>
>> I will check this series of patches, and work on this new approach.
> you might want to look at the following two patches as well: [0] and [1]
> I didn't test them as I don't have an Odroid-C2 but they should work
> with the series that Neil has mentioned. feel free to take my patches
> and fix them where needed
>
>
> Regards,
> Martin
>
> [0]
> https://github.com/xdarklight/linux/commit/f0bc8f826b465fbf24279ce78654b65282790dc6
> [1]
> https://github.com/xdarklight/linux/commit/7b5a69bf5bad992249aa39a96360fe90ccde9cd5
As pointed by Neil
For this specific use case, the only way to manage this is to use the
Work-In-Progress
Power Sequence Library proposer by Peter Chen at :
https://lkml.org/lkml/2017/1/5/33 (updated v11)
Using above series I was able to get the usb nodes to work correctly
on Odroid C2.
Although the series of patches did not clean apply completely.
I manage to get this working with your above patches. I will submit
the patches soon.
root@odroid64:~# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
root@odroid64:~#
Best Regards
-Anand Moon
Re: [Outreachy kernel] [PATCH 3/3] staging: sm750fb: Alignment should match open parenthesis
On Sat, 11 Mar 2017, Arushi Singhal wrote:
> Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/sm750fb/ddk750_mode.c | 79
> +--
> 1 file changed, 39 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_mode.c
> b/drivers/staging/sm750fb/ddk750_mode.c
> index 45af806c8d55..eea5aef2956f 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.c
> +++ b/drivers/staging/sm750fb/ddk750_mode.c
> @@ -28,9 +28,9 @@ static unsigned long
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
> poke32(CRT_AUTO_CENTERING_TL, 0);
>
> poke32(CRT_AUTO_CENTERING_BR,
> - (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> - CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> - ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
> +(((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> + CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> +((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
>
> /*
>* Assume common fields in dispControl have been properly set before
> @@ -72,8 +72,7 @@ static unsigned long
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
> }
>
> /* only timing related registers will be programed */
> -static int programModeRegisters(mode_parameter_t *pModeParam,
> - struct pll_value *pll)
> +static int programModeRegisters(mode_parameter_t *pModeParam, struct
> pll_value *pll)
> {
> int ret = 0;
> int cnt = 0;
> @@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t
> *pModeParam,
> /* programe secondary pixel clock */
> poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
> poke32(CRT_HORIZONTAL_TOTAL,
> - (((pModeParam->horizontal_total - 1) <<
> - CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> - CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->horizontal_display_end - 1) &
> - CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->horizontal_total - 1) <<
> + CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> + CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->horizontal_display_end - 1) &
> + CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
This code seems quite hard to read. Maybe you could introduce some new
variables based on the parameter names of poke32, and store the argument
of poke32 in those variables before making the call. Then you could also
shorten the names of the constants a little, by using HORIZ and VERT
instead of HORIZONTAL and VERTICAL. That might let eg the shift
operations fit on one line.
To find out the types of the new variables, you would need to look at the
definition of poke32 and see how the variables are used there.
Unfortunately poke32 is a macro, so it doesn't give type information
directly.
julia
>
> poke32(CRT_HORIZONTAL_SYNC,
> - ((pModeParam->horizontal_sync_width <<
> - CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> - CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> - ((pModeParam->horizontal_sync_start - 1) &
> - CRT_HORIZONTAL_SYNC_START_MASK));
> +((pModeParam->horizontal_sync_width <<
> + CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> + CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> +((pModeParam->horizontal_sync_start - 1) &
> + CRT_HORIZONTAL_SYNC_START_MASK));
>
> poke32(CRT_VERTICAL_TOTAL,
> - (((pModeParam->vertical_total - 1) <<
> - CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> - CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->vertical_display_end - 1) &
> - CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->vertical_total - 1) <<
> + CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> + CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->vertical_display_end - 1) &
> + CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
>
> poke32(CRT_VERTICAL_SYNC,
> - ((pModeParam->vertical_sync_height <<
> - CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> - CRT_VERTICAL_SYNC_HEIGHT_MASK) |
> - ((pModeParam->vertical_sync_start - 1) &
> - CRT_VERTICAL_SYNC_START_MASK));
> +((pModeParam->vertical_sync_height <<
> + CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> +
Re: [Outreachy kernel] [PATCH 00/10] staging: iio: Remove exceptional & on functions name
On Sat, 11 Mar 2017, simran singhal wrote: > This patch-series removes exceptional & on functions name. The semantic patch shown does nothing to check that the use of & is exception in the given file. It just removes all the & on function names. julia > > simran singhal (10): > staging: iio: ad7192: Remove exceptional & on function name > staging: iio: ad7780: Remove exceptional & on function name > staging: iio: cdc: ad7746: Remove exceptional & on function name > staging: iio: cdc: ad7152: Remove exceptional & on function name > staging: iio: adis16240: Remove exceptional & on function name > staging: iio: adis16201: Remove exceptional & on function name > staging: iio: adis16209: Remove exceptional & on function name > staging: iio: adis16203: Remove exceptional & on function name > staging: iio: resolver: Remove exceptional & on function name > staging: iio: gyro: Remove exceptional & on function name > > drivers/staging/iio/accel/adis16201.c | 4 ++-- > drivers/staging/iio/accel/adis16203.c | 4 ++-- > drivers/staging/iio/accel/adis16209.c | 4 ++-- > drivers/staging/iio/accel/adis16240.c | 4 ++-- > drivers/staging/iio/adc/ad7192.c | 12 ++-- > drivers/staging/iio/adc/ad7780.c | 2 +- > drivers/staging/iio/cdc/ad7152.c | 6 +++--- > drivers/staging/iio/cdc/ad7746.c | 4 ++-- > drivers/staging/iio/gyro/adis16060_core.c | 2 +- > drivers/staging/iio/resolver/ad2s1200.c | 2 +- > drivers/staging/iio/resolver/ad2s90.c | 2 +- > 11 files changed, 23 insertions(+), 23 deletions(-) > > -- > 2.7.4 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/1489203401-17518-1-git-send-email-singhalsimran0%40gmail.com. > For more options, visit https://groups.google.com/d/optout. >
[PATCH v4 5/8] phy: phy-mt65xx-usb3: add support for new version phy
There are some variations from mt2701 to mt2712: 1. banks shared by multiple ports are put back into each port, such as SPLLC and U2FREQ; 2. add a new bank MISC for u2port, and CHIP for u3port; 3. bank's offset in each port are also rearranged; Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 344 ++--- 1 file changed, 217 insertions(+), 127 deletions(-) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index 7ffac6c..02977f3 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -23,46 +23,54 @@ #include #include -/* - * for sifslv2 register, but exclude port's; - * relative to USB3_SIF2_BASE base address - */ -#define SSUSB_SIFSLV_SPLLC 0x -#define SSUSB_SIFSLV_U2FREQ0x0100 - -/* offsets of banks in each u2phy registers */ -#define SSUSB_SIFSLV_U2PHY_COM_BASE0x -/* offsets of banks in each u3phy registers */ -#define SSUSB_SIFSLV_U3PHYD_BASE 0x -#define SSUSB_SIFSLV_U3PHYA_BASE 0x0200 - -#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) +/* version V1 sub-banks offset base address */ +/* banks shared by multiple phys */ +#define SSUSB_SIFSLV_V1_SPLLC 0x000 /* shared by u3 phys */ +#define SSUSB_SIFSLV_V1_U2FREQ 0x100 /* shared by u2 phys */ +/* u2 phy bank */ +#define SSUSB_SIFSLV_V1_U2PHY_COM 0x000 +/* u3 phy banks */ +#define SSUSB_SIFSLV_V1_U3PHYD 0x000 +#define SSUSB_SIFSLV_V1_U3PHYA 0x200 + +/* version V2 sub-banks offset base address */ +/* u2 phy banks */ +#define SSUSB_SIFSLV_V2_MISC 0x000 +#define SSUSB_SIFSLV_V2_U2FREQ 0x100 +#define SSUSB_SIFSLV_V2_U2PHY_COM 0x300 +/* u3 phy banks */ +#define SSUSB_SIFSLV_V2_SPLLC 0x000 +#define SSUSB_SIFSLV_V2_CHIP 0x100 +#define SSUSB_SIFSLV_V2_U3PHYD 0x200 +#define SSUSB_SIFSLV_V2_U3PHYA 0x400 + +#define U3P_USBPHYACR0 0x000 #define PA0_RG_U2PLL_FORCE_ON BIT(15) -#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) +#define U3P_USBPHYACR2 0x008 #define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18) -#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) +#define U3P_USBPHYACR5 0x014 #define PA5_RG_U2_HSTX_SRCAL_ENBIT(15) #define PA5_RG_U2_HSTX_SRCTRL GENMASK(14, 12) #define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) #define PA5_RG_U2_HS_100U_U3_ENBIT(11) -#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) +#define U3P_USBPHYACR6 0x018 #define PA6_RG_U2_BC11_SW_EN BIT(23) #define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) #define PA6_RG_U2_SQTH GENMASK(3, 0) #define PA6_RG_U2_SQTH_VAL(x) (0xf & (x)) -#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) +#define U3P_U2PHYACR4 0x020 #define P2C_RG_USB20_GPIO_CTL BIT(9) #define P2C_USB20_GPIO_MODEBIT(8) #define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) -#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) +#define U3D_U2PHYDCR0 0x060 #define P2C_RG_SIF_U2PLL_FORCE_ON BIT(24) -#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) +#define U3P_U2PHYDTM0 0x068 #define P2C_FORCE_UART_EN BIT(26) #define P2C_FORCE_DATAIN BIT(23) #define P2C_FORCE_DM_PULLDOWN BIT(21) @@ -84,59 +92,56 @@ P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \ P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL) -#define U3P_U2PHYDTM1 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x006C) +#define U3P_U2PHYDTM1 0x06C #define P2C_RG_UART_EN BIT(16) #define P2C_RG_VBUSVALID BIT(5) #define P2C_RG_SESSEND BIT(4) #define P2C_RG_AVALID BIT(2) -#define U3P_U3_PHYA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x) -#define P3A_RG_U3_VUSB10_ONBIT(5) - -#define U3P_U3_PHYA_REG6 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018) +#define U3P_U3_PHYA_REG6 0x018 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28) #define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28) -#define U3P_U3_PHYA_REG9 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024) +#define U3P_U3_PHYA_REG9 0x024 #define P3A_RG_RX_DAC_MUX GENMASK(5, 1) #define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1) -#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100) +#define U3P_U3_PHYA_DA_REG00x100 #define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10) #define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10) -#define U3P_U3_PHYD_LFPS1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x000c) +#define U3P_U3_PHYD_LFPS1 0x00c #define P3D_RG_FWAKE_THGENMASK(21, 16) #define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16) -#define U3P_PHYD_CDR1
[PATCH v4 3/8] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.
So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 149 +
1 file changed, 75 insertions(+), 74 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 4fd47d0..7fff482 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
#define SSUSB_SIFSLV_SPLLC 0x
#define SSUSB_SIFSLV_U2FREQ0x0100
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE 0x
+#define SSUSB_SIFSLV_U3PHYA_BASE 0x0200
#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
#define PA0_RG_U2PLL_FORCE_ON BIT(15)
@@ -49,7 +49,6 @@
#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN BIT(31)
#define PA6_RG_U2_BC11_SW_EN BIT(23)
#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20)
#define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
#define P2C_RG_SESSEND BIT(4)
#define P2C_RG_AVALID BIT(2)
-#define U3P_U3_PHYA_REG0 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
#define P3A_RG_U3_VUSB10_ONBIT(5)
-#define U3P_U3_PHYA_REG6 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
#define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
#define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28)
-#define U3P_U3_PHYA_REG9 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
#define P3A_RG_RX_DAC_MUX GENMASK(5, 1)
#define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1)
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
#define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10)
#define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10)
@@ -160,7 +159,7 @@ struct mt65xx_phy_instance {
struct mt65xx_u3phy {
struct device *dev;
- void __iomem *sif_base; /* include sif2, but exclude port's */
+ void __iomem *sif_base; /* only shared sif */
struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
@@ -190,7 +189,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
- tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+ tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
/* enable frequency meter */
@@ -238,6 +237,56 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
}
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
+{
+ void __iomem *port_base = instance->port_base;
+ u32 tmp;
+
+ /* gating PCIe Analog XTAL clock */
+ tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+ tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+ writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+ /* gating XSQ */
+ tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+ tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+ tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+ writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+ tmp = readl(port_base + U3P_U3_PHYA_REG9);
+ tmp &= ~P3A_RG_RX_DAC_MUX;
+ tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+ writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+ tmp = readl(port_base + U3P_U3_PHYA_REG6);
+ tmp &= ~P3A_RG_TX_EIDLE_CM;
+ tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+ writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+ tmp = readl(port_base + U3P_PHYD_CDR1);
+ tmp &= ~(P3
[PATCH v4 8/8] dt-bindings: phy-mt65xx-usb: add support for new version phy
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 93 +---
1 file changed, 80 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..0acc5a9 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,12 +6,11 @@ This binding describes a usb3.0 phy for mt65xx platforms of
Medaitek SoC.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
"mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
+ - clocks : (deprecated, use port's clocks instead) a list of phandle +
+ clock-specifier pairs, one for each entry in clock-names
+ - clock-names : (deprecated, use port's one instead) must contain
"u3phya_ref": for reference clock of usb3.0 analog phy.
Required nodes : a sub-node is required for each port the controller
@@ -19,8 +18,19 @@ Required nodes : a sub-node is required for each port
the controller
'reg' property is used inside these nodes to describe
the controller's topology.
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
Required properties (port (child) node):
- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref": 48M reference clock for HighSpeed analog phy; and 26M
+ reference clock for SuperSpeed analog phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -31,21 +41,31 @@ Example:
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: usb-phy@11290800 {
+ reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: usb-phy@11290900 {
+ reg = <0 0x11290800 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: usb-phy@11291000 {
+ reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +84,54 @@ Example:
usb30: usb@1127 {
...
- phys = <&phy_port0 PHY_TYPE_USB3>;
- phy-names = "usb3-0";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ phy-names = "usb2-0", "usb3-0";
...
};
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared 0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHY
[PATCH v4 6/8] arm64: dts: mt8173: split usb SuperSpeed port into two ports
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 6922252..1dc4629 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -731,8 +731,9 @@
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
interrupts = ;
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u3port0 PHY_TYPE_USB3>,
+ <&u2port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
<&clk26m>,
@@ -770,14 +771,20 @@
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: usb-phy@11290800 {
+ reg = <0 0x11290800 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: usb-phy@11290900 {
+ reg = <0 0x11290900 0 0x700>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: usb-phy@11291000 {
+ reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
--
1.7.9.5
[PATCH v4 7/8] arm64: dts: mt8173: move clock from phy node into port nodes
there is a reference clock for each port, HighSpeed port is 48M,
and SuperSpeed port is usually 26M. it is flexible to move it
into port node, then unused clock can be disabled.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 1dc4629..1c9e0d5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -764,8 +764,6 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -773,18 +771,24 @@
u2port0: usb-phy@11290800 {
reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
u3port0: usb-phy@11290900 {
reg = <0 0x11290900 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
u2port1: usb-phy@11291000 {
reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
--
1.7.9.5
[PATCH v4 4/8] phy: phy-mt65xx-usb3: move clock from phy node into port nodes
each port has its own reference clock, the HighSpeed port is 48M,
and the SuperSpeed port is usually 26M, put them into port node for
flexibility, this can close clock if the port is not used.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 7fff482..7ffac6c 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -153,6 +153,7 @@ struct mt65xx_phy_pdata {
struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
+ struct clk *ref_clk;/* reference clock of anolog phy */
u32 index;
u8 type;
};
@@ -160,7 +161,8 @@ struct mt65xx_phy_instance {
struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* only shared sif */
- struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
+ /* deprecated, use @ref_clk instead in phy instance */
+ struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -455,6 +457,12 @@ static int mt65xx_phy_init(struct phy *phy)
return ret;
}
+ ret = clk_prepare_enable(instance->ref_clk);
+ if (ret) {
+ dev_err(u3phy->dev, "failed to enable ref_clk\n");
+ return ret;
+ }
+
if (instance->type == PHY_TYPE_USB2)
phy_instance_init(u3phy, instance);
else
@@ -494,6 +502,7 @@ static int mt65xx_phy_exit(struct phy *phy)
if (instance->type == PHY_TYPE_USB2)
phy_instance_exit(u3phy, instance);
+ clk_disable_unprepare(instance->ref_clk);
clk_disable_unprepare(u3phy->u3phya_ref);
return 0;
}
@@ -594,10 +603,13 @@ static int mt65xx_u3phy_probe(struct platform_device
*pdev)
return PTR_ERR(u3phy->sif_base);
}
+ /* it's deprecated, make it optional for backward compatibility */
u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
if (IS_ERR(u3phy->u3phya_ref)) {
- dev_err(dev, "error to get u3phya_ref\n");
- return PTR_ERR(u3phy->u3phya_ref);
+ if (PTR_ERR(u3phy->u3phya_ref) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ u3phy->u3phya_ref = NULL;
}
port = 0;
@@ -638,6 +650,17 @@ static int mt65xx_u3phy_probe(struct platform_device *pdev)
instance->index = port;
phy_set_drvdata(phy, instance);
port++;
+
+ /* if deprecated clock is provided, ignore instance's one */
+ if (u3phy->u3phya_ref)
+ continue;
+
+ instance->ref_clk = devm_clk_get(&phy->dev, "ref");
+ if (IS_ERR(instance->ref_clk)) {
+ dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
+ retval = PTR_ERR(instance->ref_clk);
+ goto put_child;
+ }
}
provider = devm_of_phy_provider_register(dev, mt65xx_phy_xlate);
--
1.7.9.5
[PATCH v4 1/8] phy: phy-mt65xx-usb3: improve RX detection stable time
The default value of RX detection stable time is 10us, and this margin is too big for some critical cases which cause U3 link fail and link to U2(probability is about 1%). So change it to 5us. Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index d972067..fe2392a 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -112,6 +112,14 @@ #define P3D_RG_CDR_BIR_LTD0GENMASK(12, 8) #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8) +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128) +#define P3D_RG_RXDET_STB2_SET GENMASK(17, 9) +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9) + +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c) +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0) +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x)(0x1ff & (x)) + #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018) #define XC3_RG_U3_XTAL_RX_PWD BIT(9) #define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8) @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3); writel(tmp, port_base + U3P_PHYD_CDR1); + tmp = readl(port_base + U3P_U3_PHYD_RXDET1); + tmp &= ~P3D_RG_RXDET_STB2_SET; + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10); + writel(tmp, port_base + U3P_U3_PHYD_RXDET1); + + tmp = readl(port_base + U3P_U3_PHYD_RXDET2); + tmp &= ~P3D_RG_RXDET_STB2_SET_P3; + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10); + writel(tmp, port_base + U3P_U3_PHYD_RXDET2); + dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index); } -- 1.7.9.5
[PATCH v4 2/8] phy: phy-mt65xx-usb3: increase LFPS filter threshold
Increase LFPS filter threshold to avoid some fake remote wakeup signal which cause U3 link fail and link to U2 only at about 0.01% probability. Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c |9 + 1 file changed, 9 insertions(+) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index fe2392a..4fd47d0 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -106,6 +106,10 @@ #define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10) #define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10) +#define U3P_U3_PHYD_LFPS1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x000c) +#define P3D_RG_FWAKE_THGENMASK(21, 16) +#define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16) + #define U3P_PHYD_CDR1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x005c) #define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24) #define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 24) @@ -303,6 +307,11 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3); writel(tmp, port_base + U3P_PHYD_CDR1); + tmp = readl(port_base + U3P_U3_PHYD_LFPS1); + tmp &= ~P3D_RG_FWAKE_TH; + tmp |= P3D_RG_FWAKE_TH_VAL(0x34); + writel(tmp, port_base + U3P_U3_PHYD_LFPS1); + tmp = readl(port_base + U3P_U3_PHYD_RXDET1); tmp &= ~P3D_RG_RXDET_STB2_SET; tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10); -- 1.7.9.5
[PATCH v2] MAINTAINERS: Add maintianer entry for crypto/s5p-sss
Add Krzysztof Kozlowski and Vladimir Zapolskiy as maintainers of s5p-sss driver for handling reviews, testing and getting bug reports from the users. Cc: Vladimir Zapolskiy Cc: Herbert Xu Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. Add also Vladimir --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 57634d0f3486..94b221714fa8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10985,6 +10985,14 @@ F: Documentation/devicetree/bindings/regulator/samsung,s2m*.txt F: Documentation/devicetree/bindings/regulator/samsung,s5m*.txt F: Documentation/devicetree/bindings/clock/samsung,s2mps11.txt +SAMSUNG S5P Security SubSystem (SSS) DRIVER +M: Krzysztof Kozlowski +M: Vladimir Zapolskiy +L: linux-cry...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org +S: Maintained +F: drivers/crypto/s5p-sss.c + SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS M: Kyungmin Park M: Sylwester Nawrocki -- 2.9.3
Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss
On Fri, Mar 10, 2017 at 11:18:13PM +0200, Vladimir Zapolskiy wrote: > Hi Krzysztof, > > On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote: > > Beside developing of this driver recently, I handle also reviews and > > bug reports from users so having a maintainer entry will ensure that I > > will be CC-ed on important emails. > > if you assume that the driver needs a special maintainership, can you > add me as a co-maintainer? I'll review new changes as usual and do > regression testing on legacy SoCs. Of course, I'll send a v2. Best regards, Krzysztof
Re: oops with 4.9.13-rt12 under mild load (and no rt-tasks active)
On Fri, 2017-03-10 at 19:47 +, Nicholas Mc Guire wrote: > Has anyone seen 4.9.13-rt12 oopses related to ext4 or vfs in general ? FWIW, here it's seen quite a bit of hefty use on boxen large and small with no trouble. That said, @stable has a large pile queued for 4.9, 8 for ext4, some of which don't sound all that benign. -Mike
Re: [PATCH] scripts: objdiff: Ignore debug info when comparing
2017-02-17 6:18 GMT+09:00 Stephen Boyd : > If the kernel is configured to be built with debug symbols, or > has bug tables, comparing files may not work if line numbers > change. This makes comparing object files with these options > harder to do. Let's strip out the debug info and drop the > __bug_table here so that we don't see false positives. There may > be other things to drop later, and it may be architecture > specific, but this works for me with my ARM64 build. > > Cc: Masahiro Yamada > Cc: Jason Cooper > Signed-off-by: Stephen Boyd Applied to linux-kbuild/misc with Jason's Reviewed-by. Thanks! Best Regards Masahiro Yamada
Re: [RESEND][PATCH] Kbuild: fix file name in comment about extra gcc checks
2017-03-10 11:01 GMT+09:00 Seung-Woo Kim : > Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn, > so the file name in comment needs to be fixed. > > Signed-off-by: Seung-Woo Kim > --- > Makefile |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index 165cf97..faa9d26 100644 > --- a/Makefile > +++ b/Makefile > @@ -707,7 +707,7 @@ KBUILD_CFLAGS += $(call cc-option, > -fcatch-undefined-behavior) > else > > # These warnings generated too much noise in a regular build. > -# Use make W=1 to enable them (see scripts/Makefile.build) > +# Use make W=1 to enable them (see scripts/Makefile.extrawarn) > KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) > KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) > endif Applied to linux-kbuild/kbuild. Thanks! -- Best Regards Masahiro Yamada
Re: Kbuild maintainership
Hi Michal, 2017-03-10 19:15 GMT+09:00 Michal Marek : > On 2017-03-10 10:17, Stephen Rothwell wrote: >> I assume that I will get a request to change the kbuild-current and >> kbuilt trees in linux-next soon. In the meantime, should I remove the >> current ones? > > There is one genksyms fix in kbuild.git#kbuild which is not in mainline. > Masahiro, can you please pull it into your tree and give Stephen the url > and branches? Pulled into the (new) linux-kbuild/kbuild -- Best Regards Masahiro Yamada
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Hi Nicolas, 2017-03-11 1:34 GMT+09:00 Nicolas Dichtel : > Le 02/03/2017 à 17:56, Nicolas Dichtel a écrit : >> Patches #1 and #2 are just cleanup: some exported headers were still under >> a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was >> not under an uapi directory. >> After these three patches, all exported headers are under an uapi directory: >> path #4 stops searching files in non uapi directories. >> The patch #5 was spotted by code review: there is no in-tree user of this >> functionality. >> Patch #6 fixes some warnings/errors reported by 0-day tests. >> Patch #7 to #9 fix some errors when the corresponding files are included by >> userland. >> Patches #10 and #11 remove the need to list explicitly headers. Now all files >> under an uapi directory are exported. >> >> This series has been tested with a 'make headers_install' on x86 and a >> 'make headers_install_all'. I've checked the result of both commands. >> >> This patch is built against linus tree. If I must rebase it against the >> kbuild >> tree, just tell me. >> Michal, is this series going through your tree? > Still waiting to know who may take this series in its tree ;-) I will take care of this. > kbuild tree has not been updated since two months (4.10-rc1) :/ Michal's tree is not active these days. Going forward, I will queue up Kbuild patches in my repository. BTW, this series does not apply cleanly. If you could rebase it onto v4.11-rc1 tag, it would be helpful. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH v2] firmware/Makefile: force recompilation if makefile changes
Hi Luis, 2017-01-24 0:07 GMT+09:00 Luis R. Rodriguez : > If you modify the target asm we currently do not force the > recompilation of the firmware files. The target asm is in > the firmware/Makefile, peg this file as a dependency to > require re-compilation of firmware targets when the asm > changes. > > Signed-off-by: Luis R. Rodriguez > --- > > Michal, > > I had this patch as part of my linker table series [0] but have split it > off as its a small atomic separate change and can go in separately. Greg > prefers this be reviewed by the kbuild tree so sending it your way. > This v2 has no modifications, just resending it to the kbuild tree. > > [0] https://lkml.kernel.org/r/20170115211057.17167-1-mcg...@kernel.org > > firmware/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/firmware/Makefile b/firmware/Makefile > index e297e1b52636..fa3e81c2a97b 100644 > --- a/firmware/Makefile > +++ b/firmware/Makefile > @@ -176,7 +176,8 @@ quiet_cmd_fwbin = MK_FW $@ > wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \ > include/config/ppc32.h include/config/ppc64.h \ > include/config/superh32.h include/config/superh64.h \ > - include/config/x86_32.h include/config/x86_64.h) > + include/config/x86_32.h include/config/x86_64.h \ > + firmware/Makefile) > > $(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps) > $(call cmd,fwbin,$(patsubst %.gen.S,%,$@)) Why don't you use $(call filechk,...) or $(call if_changed,...) instead of wordsize_deps ? -- Best Regards Masahiro Yamada
Re: [PATCH 4.4 49/91] ext4: preserve the needs_recovery flag when the journal is aborted
On Fri, 2017-03-10 at 15:14 -0500, Theodore Ts'o wrote:
> On Fri, Mar 10, 2017 at 04:58:02PM +, Ben Hutchings wrote:
> > > ---
> > > fs/ext4/super.c |6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > --- a/fs/ext4/super.c
> > > +++ b/fs/ext4/super.c
> >
> > [...]
> > > @@ -802,9 +803,10 @@ static void ext4_put_super(struct super_
> > > destroy_workqueue(sbi->rsv_conversion_wq);
> > >
> > > if (sbi->s_journal) {
> > > + aborted = is_journal_aborted(sbi->s_journal);
> > > err = jbd2_journal_destroy(sbi->s_journal);
> > > sbi->s_journal = NULL;
> > > - if (err < 0)
> > > + if ((err < 0) && !aborted)
> > > ext4_abort(sb, "Couldn't clean up the journal");
> >
> > [...]
> >
> > Shouldn't the aborted flag also be set here when err < 0?
>
> Nice catch. That's a separate issue (the bug was there before this
> commit), though I'll send a separate patch to fix this in mainline and
> then cc stable, OK?
Sure, that's not an objection to including this patch in stable now.
Ben.
--
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.
signature.asc
Description: This is a digitally signed message part
[PATCH] netfilter: Force fake conntrack entry to be at least 8 bytes aligned
Since the nfct and nfctinfo have been combined, the nf_conn structure
must be at least 8 bytes aligned, as the 3 LSB bits are used for the
nfctinfo. But there's a fake nf_conn structure to denote untracked
connections, which is created by a PER_CPU construct. This does not
guarantee that it will be 8 bytes aligned and can break the logic in
determining the correct nfctinfo.
I triggered this on a 32bit machine with the following error:
BUG: unable to handle kernel NULL pointer dereference at 0af4
IP: nf_ct_deliver_cached_events+0x1b/0xfb
*pdpt = 31962001 *pde =
Oops: [#1] SMP
[Modules linked in: ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables ipv6 crc_ccitt ppdev r8169 parport_pc parport
OK ]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-test+ #75
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
task: c126ec00 task.stack: c1258000
EIP: nf_ct_deliver_cached_events+0x1b/0xfb
EFLAGS: 00010202 CPU: 0
EAX: 0021cd01 EBX: ECX: 27b0c767 EDX: 32bcb17a
ESI: f34135c0 EDI: f34135c0 EBP: f2debd60 ESP: f2debd3c
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 80050033 CR2: 0af4 CR3: 309a0440 CR4: 001406f0
Call Trace:
? ipv6_skip_exthdr+0xac/0xcb
ipv6_confirm+0x10c/0x119 [nf_conntrack_ipv6]
nf_hook_slow+0x22/0xc7
nf_hook+0x9a/0xad [ipv6]
? ip6t_do_table+0x356/0x379 [ip6_tables]
? ip6_fragment+0x9e9/0x9e9 [ipv6]
ip6_output+0xee/0x107 [ipv6]
? ip6_fragment+0x9e9/0x9e9 [ipv6]
dst_output+0x36/0x4d [ipv6]
NF_HOOK.constprop.37+0xb2/0xba [ipv6]
? icmp6_dst_alloc+0x2c/0xfd [ipv6]
? local_bh_enable+0x14/0x14 [ipv6]
mld_sendpack+0x1c5/0x281 [ipv6]
? mark_held_locks+0x40/0x5c
mld_ifc_timer_expire+0x1f6/0x21e [ipv6]
call_timer_fn+0x135/0x283
? detach_if_pending+0x55/0x55
? mld_dad_timer_expire+0x3e/0x3e [ipv6]
__run_timers+0x111/0x14b
? mld_dad_timer_expire+0x3e/0x3e [ipv6]
run_timer_softirq+0x1c/0x36
__do_softirq+0x185/0x37c
? test_ti_thread_flag.constprop.19+0xd/0xd
do_softirq_own_stack+0x22/0x28
irq_exit+0x5a/0xa4
smp_apic_timer_interrupt+0x2a/0x34
apic_timer_interrupt+0x37/0x3c
By using DEFINE/DECLARE_PER_CPU_ALIGNED we can enforce at least 8 byte
alignment as all cache line sizes are at least 8 bytes or more.
Fixes: a9e419dc7be6 ("netfilter: merge ctinfo into nfct pointer storage area")
Signed-off-by: Steven Rostedt (VMware)
---
diff --git a/include/net/netfilter/nf_conntrack.h
b/include/net/netfilter/nf_conntrack.h
index f540f9a..1960587 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -244,7 +244,7 @@ extern s32 (*nf_ct_nat_offset)(const struct nf_conn *ct,
u32 seq);
/* Fake conntrack entry for untracked connections */
-DECLARE_PER_CPU(struct nf_conn, nf_conntrack_untracked);
+DECLARE_PER_CPU_ALIGNED(struct nf_conn, nf_conntrack_untracked);
static inline struct nf_conn *nf_ct_untracked_get(void)
{
return raw_cpu_ptr(&nf_conntrack_untracked);
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 071b97f..ffb78e5 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -181,7 +181,11 @@ EXPORT_SYMBOL_GPL(nf_conntrack_htable_size);
unsigned int nf_conntrack_max __read_mostly;
seqcount_t nf_conntrack_generation __read_mostly;
-DEFINE_PER_CPU(struct nf_conn, nf_conntrack_untracked);
+/* nf_conn must be 8 bytes aligned, as the 3 LSB bits are used
+ * for the nfctinfo. We cheat by (ab)using the PER CPU cache line
+ * alignment to enforce this.
+ */
+DEFINE_PER_CPU_ALIGNED(struct nf_conn, nf_conntrack_untracked);
EXPORT_PER_CPU_SYMBOL(nf_conntrack_untracked);
static unsigned int nf_conntrack_hash_rnd __read_mostly;
Re: [PATCH 1/3] ata: add Palmchip BK3710 PATA controller driver
Hi Bartlomiej,
[auto build test WARNING on tj-libata/for-next]
[also build test WARNING on v4.11-rc1 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bartlomiej-Zolnierkiewicz/ata-add-Palmchip-BK3710-PATA-controller-driver/20170311-095152
base: https://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-next
config: arm-davinci_all_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/ata/pata_bk3710.c: In function 'pata_bk3710_set_piomode':
>> drivers/ata/pata_bk3710.c:223:5: warning: 'cycle_time' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
if (!cycle_time)
^
vim +/cycle_time +223 drivers/ata/pata_bk3710.c
207 const u16 *id = adev->id;
208 unsigned int cycle_time;
209 int is_slave = adev->devno;
210 const u8 pio = adev->pio_mode - XFER_PIO_0;
211
212 if (id[ATA_ID_FIELD_VALID] & 2) {
213 if (ata_id_has_iordy(id))
214 cycle_time = id[ATA_ID_EIDE_PIO_IORDY];
215 else
216 cycle_time = id[ATA_ID_EIDE_PIO];
217
218 /* conservative "downgrade" for all pre-ATA2 drives */
219 if (pio < 3 && cycle_time < t->cycle)
220 cycle_time = 0; /* use standard timing */
221 }
222
> 223 if (!cycle_time)
224 cycle_time = t->cycle;
225
226 pata_bk3710_setpiomode(base, pair, is_slave, cycle_time, pio);
227 }
228
229 static void pata_bk3710_chipinit(void __iomem *base)
230 {
231 /*
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] irqdomain: handle the per-CPU irq trigger type settings
Hi Gleixner,
Thank you very much for your comment and review, I will update it later.
>
>
>
> On Fri, 10 Mar 2017, gengdongjiu wrote:
>
>> when devices parse and map an per-cpu interrupt into linux virq space
>> using irq_of_parse_and_map API, it will always be failed if needs to set
>> the specified irq trigger type, because irq_set_irq_type is only for 1-N
>> mode interrupt source, not for per-cpu interrupt source. so handle
>> per-cpu
>> IRQs for this failure.
>
> Please format your changelogs proper into sections:
>
> 1) Context
>
> 2) Problem
>
> 3) Solution
>
> Writing one big lump of a sentence is just unreadable.
>
> Aside of that:
>
> 1) No indentation of the changelog
> 2) Sentences start with upper case letters
> 3) Function references want () after the function name
>
> Aside
>
>>
>> Signed-off-by: Dongjiu Geng
>>Zhanghai bin
>
> That SOB is bogus.
>
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index 9fd618d..8116cf2 100755
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -542,8 +542,16 @@ unsigned int irq_create_of_mapping(struct
>> of_phandle_args *irq_data)
>>
>> /* Set type if specified and different than the current one */
>> if (type != IRQ_TYPE_NONE &&
>> - type != irq_get_trigger_type(virq))
>> - irq_set_irq_type(virq, type);
>> + type != irq_get_trigger_type(virq)) {
>> + int ret = 0;
>> + struct irq_data *irq_data = irq_get_irq_data(virq);
>> +
>> + ret = irq_set_irq_type(virq, type);
>> +
>> +/* Handle per-cpu IRQ: just save type in irq_data */
>> + if (-EINVAL == ret && irq_data)
>> + irqd_set_trigger_type(irq_data, type);
>
> This is completely broken. That stores a trigger type for any interrupt if
> the set type function fails.
>
> You fail to explain
>
> - WHY irq_set_irq_type() fails for these per cpu interrupts
>
> - WHY storing the type in irqdata solves anything
>
> - WHAT sets the type in the actual interrupt hardware
>
> That information should be in the changelog
>
> Thanks,
>
> tglx
>
> .
>
Re: [PATCH v2] don't forget to call pd_online_fn when activate policy
> On Mar 10, 2017, at 8:46 PM, zhouchengming wrote:
>
>> On 2017/3/10 23:12, Jens Axboe wrote:
>>> On 03/08/2017 07:20 PM, Zhou Chengming wrote:
>>> When we activate policy on the request_queue, we will create policy_date
>>> for all the existing blkgs of the request_queue, so we should call
>>> pd_init_fn() and pd_online_fn() on these newly created policy_data.
>>>
>>> Signed-off-by: Zhou Chengming
>>> ---
>>> block/blk-cgroup.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
>>> index 8ba0af7..0dd9e76 100644
>>> --- a/block/blk-cgroup.c
>>> +++ b/block/blk-cgroup.c
>>> @@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q,
>>> pd->plid = pol->plid;
>>> if (pol->pd_init_fn)
>>> pol->pd_init_fn(pd);
>>> +
>>> +if (pol->pd_online_fn) {
>>> +spin_lock(blkg->blkcg->lock);
>>> +pol->pd_online_fn(pd);
>>> +spin_unlock(blkg->blkcg->lock);
>>> +}
>>
>> You didn't even compile this, did you?
>>
>
> Sorry for my carelessness. It's a very minor change, so I didn't compile...
> I will send a patch-v3 that I have compiled. Sorry again..
I don't care how trivial it seems. You always ALWAYS compile and test. Always.
Don't ever send untested patches again, and not even compiling is unforgivable.
[PATCH v3] don't forget to call pd_online_fn when activate policy
When we activate policy on the request_queue, we will create policy_date
for all the existing blkgs of the request_queue, so we should call
pd_init_fn() and pd_online_fn() on these newly created policy_data.
Signed-off-by: Zhou Chengming
---
block/blk-cgroup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 8ba0af7..1eba1d2 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q,
pd->plid = pol->plid;
if (pol->pd_init_fn)
pol->pd_init_fn(pd);
+
+ if (pol->pd_online_fn) {
+ spin_lock(&blkg->blkcg->lock);
+ pol->pd_online_fn(pd);
+ spin_unlock(&blkg->blkcg->lock);
+ }
}
__set_bit(pol->plid, q->blkcg_pols);
--
1.8.3.1
Re: [PATCH v2] don't forget to call pd_online_fn when activate policy
On 2017/3/10 23:12, Jens Axboe wrote:
On 03/08/2017 07:20 PM, Zhou Chengming wrote:
When we activate policy on the request_queue, we will create policy_date
for all the existing blkgs of the request_queue, so we should call
pd_init_fn() and pd_online_fn() on these newly created policy_data.
Signed-off-by: Zhou Chengming
---
block/blk-cgroup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 8ba0af7..0dd9e76 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1254,6 +1254,12 @@ int blkcg_activate_policy(struct request_queue *q,
pd->plid = pol->plid;
if (pol->pd_init_fn)
pol->pd_init_fn(pd);
+
+ if (pol->pd_online_fn) {
+ spin_lock(blkg->blkcg->lock);
+ pol->pd_online_fn(pd);
+ spin_unlock(blkg->blkcg->lock);
+ }
You didn't even compile this, did you?
Sorry for my carelessness. It's a very minor change, so I didn't compile...
I will send a patch-v3 that I have compiled. Sorry again..
Re: [PATCH RFC] mm/vmscan: donot retry shrink zones when memcg is disabled
On Fri, Mar 10, 2017 at 6:19 PM, Yisheng Xie wrote:
> From: Yisheng Xie
>
> When we enter do_try_to_free_pages, the may_thrash is always clear, and
> it will retry shrink zones to tap cgroup's reserves memory by setting
> may_thrash when the former shrink_zones reclaim nothing.
>
> However, if CONFIG_MEMCG=n, it should not do this useless retry at all,
> for we do not have any cgroup's reserves memory to tap, and we have
> already done hard work and made no progress.
>
> Signed-off-by: Yisheng Xie
> ---
> mm/vmscan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index bc8031e..b03ccc1 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2808,7 +2808,7 @@ static unsigned long do_try_to_free_pages(struct
> zonelist *zonelist,
> return 1;
>
> /* Untapped cgroup reserves? Don't OOM, retry. */
> - if (!sc->may_thrash) {
> + if (!sc->may_thrash && IS_ENABLED(CONFIG_MEMCG)) {
In my opinion it should be even more restrictive (restricting
cgroup_disabled=memory boot option and cgroup legacy hierarchy). So,
instead of IS_ENABLED(CONFIG_MEMCG), the check should be something
like (cgroup_subsys_enabled(memory_cgrp_subsys) &&
cgroup_subsys_on_dfl(memory_cgrp_subsys)).
> sc->priority = initial_priority;
> sc->may_thrash = 1;
> goto retry;
> --
> 1.9.1
>
>
>
[PATCH 03/10] staging: iio: cdc: ad7746: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/cdc/ad7746.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 81f8b9e..6294de7 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -664,8 +664,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
static const struct iio_info ad7746_info = {
.attrs = &ad7746_attribute_group,
- .read_raw = &ad7746_read_raw,
- .write_raw = &ad7746_write_raw,
+ .read_raw = ad7746_read_raw,
+ .write_raw = ad7746_write_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 06/10] staging: iio: adis16201: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16201.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16201.c
b/drivers/staging/iio/accel/adis16201.c
index d6c8658..7565268 100644
--- a/drivers/staging/iio/accel/adis16201.c
+++ b/drivers/staging/iio/accel/adis16201.c
@@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16201_channels[] = {
};
static const struct iio_info adis16201_info = {
- .read_raw = &adis16201_read_raw,
- .write_raw = &adis16201_write_raw,
+ .read_raw = adis16201_read_raw,
+ .write_raw = adis16201_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 05/10] staging: iio: adis16240: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16240.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16240.c
b/drivers/staging/iio/accel/adis16240.c
index 27d7f6a..37a29dc 100644
--- a/drivers/staging/iio/accel/adis16240.c
+++ b/drivers/staging/iio/accel/adis16240.c
@@ -373,8 +373,8 @@ static const struct attribute_group
adis16240_attribute_group = {
static const struct iio_info adis16240_info = {
.attrs = &adis16240_attribute_group,
- .read_raw = &adis16240_read_raw,
- .write_raw = &adis16240_write_raw,
+ .read_raw = adis16240_read_raw,
+ .write_raw = adis16240_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 04/10] staging: iio: cdc: ad7152: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/cdc/ad7152.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7152.c b/drivers/staging/iio/cdc/ad7152.c
index e8609b8..59ef93c 100644
--- a/drivers/staging/iio/cdc/ad7152.c
+++ b/drivers/staging/iio/cdc/ad7152.c
@@ -441,9 +441,9 @@ static int ad7152_write_raw_get_fmt(struct iio_dev
*indio_dev,
static const struct iio_info ad7152_info = {
.attrs = &ad7152_attribute_group,
- .read_raw = &ad7152_read_raw,
- .write_raw = &ad7152_write_raw,
- .write_raw_get_fmt = &ad7152_write_raw_get_fmt,
+ .read_raw = ad7152_read_raw,
+ .write_raw = ad7152_write_raw,
+ .write_raw_get_fmt = ad7152_write_raw_get_fmt,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 02/10] staging: iio: ad7780: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/adc/ad7780.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index e149600..dec3ba6 100644
--- a/drivers/staging/iio/adc/ad7780.c
+++ b/drivers/staging/iio/adc/ad7780.c
@@ -154,7 +154,7 @@ static const struct ad7780_chip_info ad7780_chip_info_tbl[]
= {
};
static const struct iio_info ad7780_info = {
- .read_raw = &ad7780_read_raw,
+ .read_raw = ad7780_read_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 10/10] staging: iio: gyro: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/gyro/adis16060_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/gyro/adis16060_core.c
b/drivers/staging/iio/gyro/adis16060_core.c
index ab816a2..c9d46e7 100644
--- a/drivers/staging/iio/gyro/adis16060_core.c
+++ b/drivers/staging/iio/gyro/adis16060_core.c
@@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
}
static const struct iio_info adis16060_info = {
- .read_raw = &adis16060_read_raw,
+ .read_raw = adis16060_read_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 09/10] staging: iio: resolver: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/resolver/ad2s1200.c | 2 +-
drivers/staging/iio/resolver/ad2s90.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/resolver/ad2s1200.c
b/drivers/staging/iio/resolver/ad2s1200.c
index 82b2d88..a37e199 100644
--- a/drivers/staging/iio/resolver/ad2s1200.c
+++ b/drivers/staging/iio/resolver/ad2s1200.c
@@ -97,7 +97,7 @@ static const struct iio_chan_spec ad2s1200_channels[] = {
};
static const struct iio_info ad2s1200_info = {
- .read_raw = &ad2s1200_read_raw,
+ .read_raw = ad2s1200_read_raw,
.driver_module = THIS_MODULE,
};
diff --git a/drivers/staging/iio/resolver/ad2s90.c
b/drivers/staging/iio/resolver/ad2s90.c
index 5b1c0db..b227090 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -47,7 +47,7 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
}
static const struct iio_info ad2s90_info = {
- .read_raw = &ad2s90_read_raw,
+ .read_raw = ad2s90_read_raw,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 07/10] staging: iio: adis16209: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16209.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16209.c
b/drivers/staging/iio/accel/adis16209.c
index 8ff537f..56bc2ac 100644
--- a/drivers/staging/iio/accel/adis16209.c
+++ b/drivers/staging/iio/accel/adis16209.c
@@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16209_channels[] = {
};
static const struct iio_info adis16209_info = {
- .read_raw = &adis16209_read_raw,
- .write_raw = &adis16209_write_raw,
+ .read_raw = adis16209_read_raw,
+ .write_raw = adis16209_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 08/10] staging: iio: adis16203: Remove exceptional & on function name
In this file, function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/accel/adis16203.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16203.c
b/drivers/staging/iio/accel/adis16203.c
index 68189ad..b59755a 100644
--- a/drivers/staging/iio/accel/adis16203.c
+++ b/drivers/staging/iio/accel/adis16203.c
@@ -233,8 +233,8 @@ static const struct iio_chan_spec adis16203_channels[] = {
};
static const struct iio_info adis16203_info = {
- .read_raw = &adis16203_read_raw,
- .write_raw = &adis16203_write_raw,
+ .read_raw = adis16203_read_raw,
+ .write_raw = adis16203_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
};
--
2.7.4
[PATCH 01/10] staging: iio: ad7192: Remove exceptional & on function name
In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
//
@r@
identifier f;
@@
f(...) { ... }
@@
identifier r.f;
@@
- &f
+ f
//
Signed-off-by: simran singhal
---
drivers/staging/iio/adc/ad7192.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index 4fc8588..d11c6de 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -564,18 +564,18 @@ static int ad7192_write_raw_get_fmt(struct iio_dev
*indio_dev,
}
static const struct iio_info ad7192_info = {
- .read_raw = &ad7192_read_raw,
- .write_raw = &ad7192_write_raw,
- .write_raw_get_fmt = &ad7192_write_raw_get_fmt,
+ .read_raw = ad7192_read_raw,
+ .write_raw = ad7192_write_raw,
+ .write_raw_get_fmt = ad7192_write_raw_get_fmt,
.attrs = &ad7192_attribute_group,
.validate_trigger = ad_sd_validate_trigger,
.driver_module = THIS_MODULE,
};
static const struct iio_info ad7195_info = {
- .read_raw = &ad7192_read_raw,
- .write_raw = &ad7192_write_raw,
- .write_raw_get_fmt = &ad7192_write_raw_get_fmt,
+ .read_raw = ad7192_read_raw,
+ .write_raw = ad7192_write_raw,
+ .write_raw_get_fmt = ad7192_write_raw_get_fmt,
.attrs = &ad7195_attribute_group,
.validate_trigger = ad_sd_validate_trigger,
.driver_module = THIS_MODULE,
--
2.7.4
[PATCH 00/10] staging: iio: Remove exceptional & on functions name
This patch-series removes exceptional & on functions name. simran singhal (10): staging: iio: ad7192: Remove exceptional & on function name staging: iio: ad7780: Remove exceptional & on function name staging: iio: cdc: ad7746: Remove exceptional & on function name staging: iio: cdc: ad7152: Remove exceptional & on function name staging: iio: adis16240: Remove exceptional & on function name staging: iio: adis16201: Remove exceptional & on function name staging: iio: adis16209: Remove exceptional & on function name staging: iio: adis16203: Remove exceptional & on function name staging: iio: resolver: Remove exceptional & on function name staging: iio: gyro: Remove exceptional & on function name drivers/staging/iio/accel/adis16201.c | 4 ++-- drivers/staging/iio/accel/adis16203.c | 4 ++-- drivers/staging/iio/accel/adis16209.c | 4 ++-- drivers/staging/iio/accel/adis16240.c | 4 ++-- drivers/staging/iio/adc/ad7192.c | 12 ++-- drivers/staging/iio/adc/ad7780.c | 2 +- drivers/staging/iio/cdc/ad7152.c | 6 +++--- drivers/staging/iio/cdc/ad7746.c | 4 ++-- drivers/staging/iio/gyro/adis16060_core.c | 2 +- drivers/staging/iio/resolver/ad2s1200.c | 2 +- drivers/staging/iio/resolver/ad2s90.c | 2 +- 11 files changed, 23 insertions(+), 23 deletions(-) -- 2.7.4
[PATCH 1/3] staging: sm750fb: function prototype argument should have an identifier name
function prototype arguments like 'struct vb_device_info *','unsigned
long' etc. should have an identifier name.
Signed-off-by: Arushi Singhal
---
drivers/staging/sm750fb/ddk750_display.h | 2 +-
drivers/staging/sm750fb/ddk750_mode.h| 2 +-
drivers/staging/sm750fb/ddk750_power.h | 2 +-
drivers/staging/sm750fb/sm750.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_display.h
b/drivers/staging/sm750fb/ddk750_display.h
index e2a3f84ca4c5..609bf742efff 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -102,6 +102,6 @@ typedef enum _disp_output_t {
}
disp_output_t;
-void ddk750_setLogicalDispOut(disp_output_t);
+void ddk750_setLogicalDispOut(disp_output_t output);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_mode.h
b/drivers/staging/sm750fb/ddk750_mode.h
index 2183e664cf4b..6d204b8b4a01 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
}
mode_parameter_t;
-int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
+int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h
b/drivers/staging/sm750fb/ddk750_power.h
index ec0b99d6a7ad..44c4fc587e96 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -14,7 +14,7 @@ DPMS_t;
(peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
}
-void ddk750_set_dpms(DPMS_t);
+void ddk750_set_dpms(DPMS_t state);
void sm750_set_power_mode(unsigned int powerMode);
void sm750_set_current_gate(unsigned int gate);
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 306711ed55f9..5ea455dee949 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -184,7 +184,7 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
}
int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
-int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
+int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
void hw_sm750_initAccel(struct sm750_dev *);
int hw_sm750_deWait(void);
int hw_sm750le_deWait(void);
--
2.11.0
[PATCH 2/3] staging: sm750fb: fixes add blank line after function/struct/union/enum declarations
This patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.
Signed-off-by: Arushi Singhal
---
drivers/staging/sm750fb/sm750_cursor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c
b/drivers/staging/sm750fb/sm750_cursor.c
index 612e9ab9d569..b64dc8a4a8fb 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -54,6 +54,7 @@ void sm750_hw_cursor_enable(struct lynx_cursor *cursor)
reg = (cursor->offset & HWC_ADDRESS_ADDRESS_MASK) | HWC_ADDRESS_ENABLE;
poke32(HWC_ADDRESS, reg);
}
+
void sm750_hw_cursor_disable(struct lynx_cursor *cursor)
{
poke32(HWC_ADDRESS, 0);
@@ -65,6 +66,7 @@ void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
cursor->w = w;
cursor->h = h;
}
+
void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
int x, int y)
{
@@ -74,6 +76,7 @@ void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
(x & HWC_LOCATION_X_MASK);
poke32(HWC_LOCATION, reg);
}
+
void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
u32 fg, u32 bg)
{
--
2.11.0
[PATCH 3/3] staging: sm750fb: Alignment should match open parenthesis
Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".
Signed-off-by: Arushi Singhal
---
drivers/staging/sm750fb/ddk750_mode.c | 79 +--
1 file changed, 39 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_mode.c
b/drivers/staging/sm750fb/ddk750_mode.c
index 45af806c8d55..eea5aef2956f 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -28,9 +28,9 @@ static unsigned long
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
poke32(CRT_AUTO_CENTERING_TL, 0);
poke32(CRT_AUTO_CENTERING_BR,
- (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
- CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
- ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
+ (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
+ CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
+ ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
/*
* Assume common fields in dispControl have been properly set before
@@ -72,8 +72,7 @@ static unsigned long
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
}
/* only timing related registers will be programed */
-static int programModeRegisters(mode_parameter_t *pModeParam,
- struct pll_value *pll)
+static int programModeRegisters(mode_parameter_t *pModeParam, struct pll_value
*pll)
{
int ret = 0;
int cnt = 0;
@@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t
*pModeParam,
/* programe secondary pixel clock */
poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
poke32(CRT_HORIZONTAL_TOTAL,
- (((pModeParam->horizontal_total - 1) <<
- CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
- CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
- ((pModeParam->horizontal_display_end - 1) &
- CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
+ (((pModeParam->horizontal_total - 1) <<
+CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
+ CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
+ ((pModeParam->horizontal_display_end - 1) &
+ CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
poke32(CRT_HORIZONTAL_SYNC,
- ((pModeParam->horizontal_sync_width <<
- CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
- CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
- ((pModeParam->horizontal_sync_start - 1) &
- CRT_HORIZONTAL_SYNC_START_MASK));
+ ((pModeParam->horizontal_sync_width <<
+CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
+ CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
+ ((pModeParam->horizontal_sync_start - 1) &
+ CRT_HORIZONTAL_SYNC_START_MASK));
poke32(CRT_VERTICAL_TOTAL,
- (((pModeParam->vertical_total - 1) <<
- CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
- CRT_VERTICAL_TOTAL_TOTAL_MASK) |
- ((pModeParam->vertical_display_end - 1) &
- CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
+ (((pModeParam->vertical_total - 1) <<
+CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
+ CRT_VERTICAL_TOTAL_TOTAL_MASK) |
+ ((pModeParam->vertical_display_end - 1) &
+ CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
poke32(CRT_VERTICAL_SYNC,
- ((pModeParam->vertical_sync_height <<
- CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
- CRT_VERTICAL_SYNC_HEIGHT_MASK) |
- ((pModeParam->vertical_sync_start - 1) &
- CRT_VERTICAL_SYNC_START_MASK));
+ ((pModeParam->vertical_sync_height <<
+CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
+ CRT_VERTICAL_SYNC_HEIGHT_MASK) |
+ ((pModeParam->vertical_sync_start - 1) &
+ CRT_VERTICAL_SYNC_START_MASK));
tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
if (pModeParam->vertical_sync_polarity)
@@ -140,25 +139,25 @@ static int programModeRegisters(mode_parameter_t
*pModeParam,
poke32(PANEL_HORIZONTAL_TOTAL, reg);
poke32(PANEL_HORIZONTAL_SYNC,
- ((pModeParam->horizontal_sync_width <<
- PANEL_HORIZONTAL_SYNC_WIDTH_SHIFT) &
- PANEL_HORIZONTAL_SYNC_WIDTH_MASK) |
- ((pModeParam->
[PATCH 0/3] staging: sm750fb: multiple checkpatch issues
Improve readability by fixing multiple checkpatch.pl issues in sm750fb driver. Arushi Singhal (3): staging: sm750fb: function prototype argument should have an identifier name staging: sm750fb: fixes add blank line after function/struct/union/enum declarations staging: sm750fb: Alignment should match open parenthesis drivers/staging/sm750fb/ddk750_display.h | 2 +- drivers/staging/sm750fb/ddk750_mode.c| 79 drivers/staging/sm750fb/ddk750_mode.h| 2 +- drivers/staging/sm750fb/ddk750_power.h | 2 +- drivers/staging/sm750fb/sm750.h | 2 +- drivers/staging/sm750fb/sm750_cursor.c | 3 ++ 6 files changed, 46 insertions(+), 44 deletions(-) -- 2.11.0
[PATCH V2] Staging: bcm2835: Fixed style of block comments
Fixed style of block comments across whole driver
Found using checkpatch
Signed-off-by: Derek Robson
---
Version #1 had ugly long subject name.
.../media/platform/bcm2835/bcm2835-camera.c| 24 ++
drivers/staging/media/platform/bcm2835/controls.c | 22 +++-
.../staging/media/platform/bcm2835/mmal-msg-port.h | 6 --
drivers/staging/media/platform/bcm2835/mmal-msg.h | 18
.../staging/media/platform/bcm2835/mmal-vchiq.c| 3 ++-
.../staging/media/platform/bcm2835/mmal-vchiq.h| 4 ++--
6 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index ca15a698e018..25beca62a8a9 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -239,8 +239,9 @@ static struct mmal_fmt *get_format(struct v4l2_format *f)
}
/* --
- Videobuf queue operations
- --*/
+ * Videobuf queue operations
+ * --
+ */
static int queue_setup(struct vb2_queue *vq,
unsigned int *nbuffers, unsigned int *nplanes,
@@ -668,8 +669,9 @@ static struct vb2_ops bm2835_mmal_video_qops = {
};
/* --
- IOCTL operations
- --*/
+ * IOCTL operations
+ * --
+ */
static int set_overlay_params(struct bm2835_mmal_dev *dev,
struct vchiq_mmal_port *port)
@@ -834,7 +836,8 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
struct v4l2_framebuffer *a)
{
/* The video overlay must stay within the framebuffer and can't be
- positioned independently. */
+* positioned independently.
+*/
struct bm2835_mmal_dev *dev = video_drvdata(file);
struct vchiq_mmal_port *preview_port =
&dev->component[MMAL_COMPONENT_CAMERA]->
@@ -1291,7 +1294,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void
*priv,
}
/* If the format is unsupported v4l2 says we should switch to
-* a supported one and not return an error. */
+* a supported one and not return an error.
+*/
mfmt = get_format(f);
if (!mfmt) {
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
@@ -1485,7 +1489,8 @@ static const struct v4l2_ioctl_ops
camera0_ioctl_ops_gstreamer = {
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
/* Remove this function ptr to fix gstreamer bug
- .vidioc_enum_framesizes = vidioc_enum_framesizes, */
+* .vidioc_enum_framesizes = vidioc_enum_framesizes,
+*/
.vidioc_enum_frameintervals = vidioc_enum_frameintervals,
.vidioc_g_parm= vidioc_g_parm,
.vidioc_s_parm= vidioc_s_parm,
@@ -1498,8 +1503,9 @@ static const struct v4l2_ioctl_ops
camera0_ioctl_ops_gstreamer = {
};
/* --
- Driver init/finalise
- --*/
+ * Driver init/finalise
+ * --
+ */
static const struct v4l2_file_operations camera0_fops = {
.owner = THIS_MODULE,
diff --git a/drivers/staging/media/platform/bcm2835/controls.c
b/drivers/staging/media/platform/bcm2835/controls.c
index a40987b2e75d..16fa40c904e7 100644
--- a/drivers/staging/media/platform/bcm2835/controls.c
+++ b/drivers/staging/media/platform/bcm2835/controls.c
@@ -90,7 +90,8 @@ struct bm2835_mmal_v4l2_ctrl {
u32 id; /* v4l2 control identifier */
enum bm2835_mmal_ctrl_type type;
/* control minimum value or
-* mask for MMAL_CONTROL_TYPE_STD_MENU */
+* mask for MMAL_CONTROL_TYPE_STD_MENU
+*/
s32 min;
s32 max; /* maximum value of control */
s32 def; /* default value of control */
@@ -398,10 +399,10 @@ static int ctrl_set_metering_mode(struct bm2835_mmal_dev
*dev,
break;
/* todo matrix weighting not added to Linux API till 3.9
- case V4L2_EXPOSURE_METERING_MATRIX:
- dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_MATRIX;
- break;
- */
+* case V4L2_EXPOSURE_METERING_MATRIX:
+* dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_MATRIX;
+* break;
+*/
}
if (dev->scene_mode == V4L2_SCENE_MODE_NONE) {
@@ -982,8 +983,9 @@ static const struct bm2835_mmal_v4l2_ctrl
[PATCH v1] soc: rockchip: power-domain: Fix clang warning about negative shift count
The following warning is generated when building with clang:
drivers/soc/rockchip/pm_domains.c:726:22: error: shift count is negative
[-Werror,-Wshift-count-negative]
[RK3399_PD_TCPD0] = DOMAIN_RK3399(8, 8, -1, false),
^~
drivers/soc/rockchip/pm_domains.c:101:2: note: expanded from macro
'DOMAIN_RK3399'
DOMAIN(pwr, status, req, req, req, wakeup)
^~
drivers/soc/rockchip/pm_domains.c:88:27: note: expanded from macro 'DOMAIN'
.req_mask = (req >= 0) ? BIT(req) : 0, \
^~~~
include/linux/bitops.h:6:24: note: expanded from macro 'BIT'
The BIT macro is evaluated with the negative value -1, even though the
resulting value would not be assigned. To fix this we only pass values
between 0 and 63 to BIT(). Unfortunately this means that we lose the
benefit of the compiler checking for out of bounds errors.
Signed-off-by: Matthias Kaehlcke
---
drivers/soc/rockchip/pm_domains.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 1c78c42416c6..6f2bb1222992 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -77,13 +77,15 @@ struct rockchip_pmu {
#define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
+#define RK_MASK(bit) ((bit >= 0) ? BIT(bit & 0x3f) : 0)
+
#define DOMAIN(pwr, status, req, idle, ack, wakeup)\
-{ \
- .pwr_mask = (pwr >= 0) ? BIT(pwr) : 0, \
- .status_mask = (status >= 0) ? BIT(status) : 0, \
- .req_mask = (req >= 0) ? BIT(req) : 0, \
- .idle_mask = (idle >= 0) ? BIT(idle) : 0, \
- .ack_mask = (ack >= 0) ? BIT(ack) : 0, \
+{ \
+ .pwr_mask = RK_MASK(pwr), \
+ .status_mask = RK_MASK(status), \
+ .req_mask = RK_MASK(req), \
+ .idle_mask = RK_MASK(idle), \
+ .ack_mask = RK_MASK(ack), \
.active_wakeup = wakeup,\
}
--
2.12.0.246.ga2ecc84866-goog
[PATCH RFC] mm/vmscan: donot retry shrink zones when memcg is disabled
From: Yisheng Xie
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, if CONFIG_MEMCG=n, it should not do this useless retry at all,
for we do not have any cgroup's reserves memory to tap, and we have
already done hard work and made no progress.
Signed-off-by: Yisheng Xie
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bc8031e..b03ccc1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2808,7 +2808,7 @@ static unsigned long do_try_to_free_pages(struct zonelist
*zonelist,
return 1;
/* Untapped cgroup reserves? Don't OOM, retry. */
- if (!sc->may_thrash) {
+ if (!sc->may_thrash && IS_ENABLED(CONFIG_MEMCG)) {
sc->priority = initial_priority;
sc->may_thrash = 1;
goto retry;
--
1.9.1
[PATCH linux v4 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver
This binding provides interface for adding values related to ASPEED
AST2400/2500 PWM and Fan tach controller support.
The PWM controller can support upto 8 PWM output ports.
The Fan tach controller can support upto 16 tachometer inputs.
Signed-off-by: Jaghathiswari Rankappagounder Natarajan
---
v4:
- Used 'reg'
v3:
- Made the structure more common
v2:
- Removed '_' in node and property names
- Gave some explanation for the properties used
.../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 86 ++
1 file changed, 86 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
new file mode 100644
index ..0dfd2841ace3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -0,0 +1,86 @@
+ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 8 fans supported. Each fan can have one PWM output and
+one/two Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 1.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,aspeed2400-pwm-tacho" for AST2400 or
+ "aspeed,aspeed2500-pwm-tacho" for AST2500.
+
+- clocks : a fixed clock providing input clock frequency(PWM
+ and Fan Tach clock)
+
+fan subnode format:
+===
+Under fan subnode there can upto 8 child nodes, with each child node
+representing a fan. If there are 8 fans each fan can have one PWM port and
+one/two Fan tach inputs.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+ integer value in the range 0 to 7 with 0 indicating PWM port A and
+ 7 indicating PWM port H.
+
+ Atleast one tach subnode is required. Each tach subnode represents a fan
+ tach input.
+ tach subnode format:
+
+ Required properties for each child node:
+ - fan-ctrl-gpios : should specify the tachometer input GPIO pin on the
hardware.
+Fan Tachometer function can only work when GPIO is in
+”input mode”.
+
+ - fan-tach-ch : should specify the Fan tach input channel.
+ integer value in the range 0 through 15, with 0 indicating
+ Fan tach channel 0 and 15 indicating Fan tach channel 15.
+
+Examples:
+
+pwmtachofixedclk: fixedclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+}
+
+pwmtacho: pwmtachocontroller@1e786000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x1E786000 0x1000>;
+ compatible = "aspeed,aspeed2500-pwm-tacho";
+ clocks = <&pwmtachofixedclk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
+
+ fan0 {
+ reg = /bits/ 8 <0x00>;
+ tach0 {
+ fan-ctrl-gpios = <&gpio ASPEED_GPIO(O, 0)
GPIO_ACTIVE_HIGH>;
+ fan-tach-ch = /bits/ 8 <0x00>;
+ };
+ };
+
+ fan1 {
+ reg = /bits/ 8 <0x01>;
+ tach0 {
+ fan-ctrl-gpios = <&gpio ASPEED_GPIO(O, 1)
GPIO_ACTIVE_HIGH>;
+ fan-tach-ch = /bits/ 8 <0x01>;
+ };
+ tach1 {
+ fan-ctrl-gpios = <&gpio ASPEED_GPIO(O, 2)
GPIO_ACTIVE_HIGH>;
+ fan-tach-ch = /bits/ 8 <0x02>;
+ };
+ };
+};
--
2.12.0.246.ga2ecc84866-goog
[PATCH linux v4 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports. The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer inputs. The device driver matches on the device tree node. The configuration values are read from the device tree and written to the respective registers. The driver provides a sysfs entries through which the user can configure the duty-cycle value (ranging from 0 to 100 percent) and read the fan tach rpm value. Signed-off-by: Jaghathiswari Rankappagounder Natarajan --- v4: - Modified this driver to suit the representation in the devicetree v3: - Only sent out device tree documentation; did not send this driver v2: - Used BIT() - Used regmap - Avoided division when raw data is 0 - Removed empty lines between declaration - Removed macros; Used two attribute groups and used is_visible callback - Returned error when properties are undefined - Removed .owner field - Used PTR_ERR_OR_ZERO - Removed explicit of_node_put for child nodes Documentation/hwmon/aspeed-pwm-tacho | 22 + drivers/hwmon/Kconfig| 9 + drivers/hwmon/Makefile | 1 + drivers/hwmon/aspeed-pwm-tacho.c | 866 +++ 4 files changed, 898 insertions(+) create mode 100644 Documentation/hwmon/aspeed-pwm-tacho create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c diff --git a/Documentation/hwmon/aspeed-pwm-tacho b/Documentation/hwmon/aspeed-pwm-tacho new file mode 100644 index ..0e9ec6d5f900 --- /dev/null +++ b/Documentation/hwmon/aspeed-pwm-tacho @@ -0,0 +1,22 @@ +Kernel driver aspeed-pwm-tacho +== + +Supported chips: + ASPEED AST2400/2500 + +Authors: + + +Description: + +This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho +controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho +controller supports upto 16 tachometer inputs. + +The driver provides the following sensor accesses in sysfs: + +fanX_input ro provide current fan rotation value in RPM as reported + by the fan to the device. + +pwmX rw get or set PWM fan control value. This is an integer + value between 0(off) and 255(full speed). diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 45cef3d2c75c..757b5b0705bf 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -341,6 +341,15 @@ config SENSORS_ASB100 This driver can also be built as a module. If so, the module will be called asb100. +config SENSORS_ASPEED + tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver" + help + This driver provides support for ASPEED AST2400/AST2500 PWM + and Fan Tacho controllers. + + This driver can also be built as a module. If so, the module + will be called aspeed_pwm_tacho. + config SENSORS_ATXP1 tristate "Attansic ATXP1 VID controller" depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index aecf4ba17460..83025cc9bb45 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o +obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c new file mode 100644 index ..d354b7a958ad --- /dev/null +++ b/drivers/hwmon/aspeed-pwm-tacho.c @@ -0,0 +1,866 @@ +/* + * Copyright (c) 2016 Google, Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 or later as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* ASPEED PWM & FAN Tach Register Definition */ +#define ASPEED_PTCR_CTRL 0x00 +#define ASPEED_PTCR_CLK_CTRL 0x04 +#define ASPEED_PTCR_DUTY0_CTRL 0x08 +#define ASPEED_PTCR_DUTY1_CTRL 0x0c +#define ASPEED_PTCR_TYPEM_CTRL 0x10 +#define ASPEED_PTCR_TYPEM_CTRL10x14 +#define ASPEED_PTCR_TYPEN_CTRL 0x18 +#define ASPEED_PTCR_TYPEN_CTRL10x1c +#define ASPEED_PTCR_TACH_SOURCE0x20 +#define ASPEED_PTCR_TRIGGER0x28 +#define ASPEED_PTCR_RESULT 0x2c +#define ASPEED_PTCR_INTR_CTRL 0x30 +#define ASPEED_PTCR_INTR_STS 0x34 +#define ASPEED_PTCR_TYPEM_LIMIT0x38 +#define ASPEED_PTCR_TYPEN_LIMIT0x3C +#define ASPEED_PTCR_CTRL_EXT 0x40 +#define ASPEED_PTCR_CLK_CTRL_EXT 0x44 +#
[PATCH linux v4 0/2] Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver
Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver. Patches based on the upstream tag 4.9. Changes made in Version 4 are indicated in the individual patches. The AST2400/AST2500 PWM controller can support 8 PWM output ports. The AST2400/AST2500 Fan Tach controller can support 16 tachometer inputs. The hwmon driver provides sysfs entries through which the user can configure the duty cycle for the particular PWM output port and read the fan rpm value for the particular tachometer input. Added devicetree binding documentation for AST2400/AST2500 PWM and Fan Tach support. Tested on Zaius board (which has AST2500 chip) and observed that when duty cycle is lowered then the fan speed is lowered and lower fan rpm value( corresponding to the duty cycle) is reported and when the duty cycle is increased then the fan speed increases and higher fan rpm value(corresponding to the duty cycle) is reported. Jaghathiswari Rankappagounder Natarajan (2): Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver drivers: hwmon: Support for ASPEED PWM/Fan tach .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 86 ++ Documentation/hwmon/aspeed-pwm-tacho | 22 + drivers/hwmon/Kconfig | 9 + drivers/hwmon/Makefile | 1 + drivers/hwmon/aspeed-pwm-tacho.c | 866 + 5 files changed, 984 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt create mode 100644 Documentation/hwmon/aspeed-pwm-tacho create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c -- 2.12.0.246.ga2ecc84866-goog
Re: [PATCH 1/1] x86/cqm: Cqm requirements
> > Fine. So we need this for ONE particular use case. And if that is not well > documented including the underlying mechanics to analyze the data then this > will be a nice source of confusion for Joe User. > > I still think that this can be done differently while keeping the overhead > small. > > You look at this from the existing perf mechanics which require high > overhead context switching machinery. But that's just wrong because that's > not how the cache and bandwidth monitoring works. > > Contrary to the other perf counters, CQM and MBM are based on a context > selectable set of counters which do not require readout and reconfiguration > when the switch happens. > > Especially with CAT in play, the context switch overhead is there already > when CAT partitions need to be switched. So switching the RMID at the same > time is basically free, if we are smart enough to do an equivalent to the > CLOSID context switch mechanics and ideally combine both into a single MSR > write. > > With that the low overhead periodic sampling can read N counters which are > related to the monitored set and provide N separate results. For bandwidth > the aggregation is a simple ADD and for cache residency it's pointless. > > Just because perf was designed with the regular performance counters in > mind (way before that CQM/MBM stuff came around) does not mean that we > cannot change/extend that if it makes sense. > > And looking at the way Cache/Bandwidth allocation and monitoring works, it > makes a lot of sense. Definitely more than shoving it into the current mode > of operandi with duct tape just because we can. > You made a point. The use case I described can be better served with the low overhead monitoring groups that Fenghua is working on. Then that info can be merged with the per-CPU profile collected for non-RDT events. I am ok removing the perf-like CPU filtering from the requirements. Thanks, David
Re: [PATCH v7] mm: Add memory allocation watchdog kernel thread.
Michal Hocko wrote: > So, we have means to debug these issues. Some of them are rather coarse > and your watchdog can collect much more and maybe give us a clue much > quicker but we still have to judge whether all this is really needed > because it doesn't come for free. Have you considered this aspect? Sigh... You are ultimately ignoring the reality. Educating everybody to master debugging tools does not come for free. If I liken your argumentation to security modules, it looks like the following. "There is already SELinux. SELinux can do everything. Thus, AppArmor is not needed. I don't care about users/customers who cannot administrate SELinux." The reality is different. We need tools which users/customers can afford using. You had better getting away from existing debug tools which kernel developers are using. First of all, SysRq is an emergency tool and therefore it requires administrator's intervention. Your argumentation sounds to me that "Give up debugging unless you can sit on in front of console of Linux systems 24-7" which is already impossible. SysRq-t cannot print seq= and delay= fields because information of in-flight allocation request is not accessible from "struct task_struct", making extremely difficult to judge whether progress is made when several SysRq-t snapshots are taken. Also, year by year it is getting difficult to use vmcore for analysis because vmcore might include sensitive data (even after filtering out user pages). I saw cases where vmcore cannot be sent to support centers due to e.g. organization's information control rules. Sometimes we have to analyze from only kernel messages. Some pieces of information extracted by running scripts against /usr/bin/crash on cutomer's side might be available, but in general we can't assume that the whole memory image which includes whatever information is available. In most cases, administrators can't capture even SysRq-t; let alone vmcore. Therefore, automatic watchdog is highly appreciated. Have you considered this aspect?
[PATCH] usbnet: smsc95xx: Reduce logging noise
An insert/remove stress test generated the following log message sequence.
usb 7-1.1: New USB device found, idVendor=0424, idProduct=ec00
usb 7-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x0114: -22
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
Error reading MII_ACCESS
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
MII is busy in smsc95xx_mdio_read
... repeat 100+ times ...
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
MII is busy in smsc95xx_mdio_read
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
timeout on PHY Reset
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
Failed to init PHY
smsc95xx 7-1.1:1.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -22
smsc95xx: probe of 7-1.1:1.0 failed with error -22
usb usb7: USB disconnect, device number 1
usb 7-1: USB disconnect, device number 2
usb 7-1.1: USB disconnect, device number 3
Use netdev_dbg() instead of netdev_warn() for the repeating messages
to reduce logging noise.
Signed-off-by: Guenter Roeck
---
drivers/net/usb/smsc95xx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 831aa33d078a..f69e9e031973 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -100,8 +100,8 @@ static int __must_check __smsc95xx_read_reg(struct usbnet
*dev, u32 index,
| USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, index, &buf, 4);
if (unlikely(ret < 0)) {
- netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n",
- index, ret);
+ netdev_dbg(dev->net, "Failed to read reg index 0x%08x: %d\n",
+ index, ret);
return ret;
}
@@ -174,7 +174,7 @@ static int __must_check __smsc95xx_phy_wait_not_busy(struct
usbnet *dev,
do {
ret = __smsc95xx_read_reg(dev, MII_ADDR, &val, in_pm);
if (ret < 0) {
- netdev_warn(dev->net, "Error reading MII_ACCESS\n");
+ netdev_dbg(dev->net, "Error reading MII_ACCESS\n");
return ret;
}
@@ -197,7 +197,7 @@ static int __smsc95xx_mdio_read(struct net_device *netdev,
int phy_id, int idx,
/* confirm MII not busy */
ret = __smsc95xx_phy_wait_not_busy(dev, in_pm);
if (ret < 0) {
- netdev_warn(dev->net, "MII is busy in smsc95xx_mdio_read\n");
+ netdev_dbg(dev->net, "MII is busy in smsc95xx_mdio_read\n");
goto done;
}
--
2.7.4
Re: [PATCH 4.10 000/167] 4.10.2-stable review
On Fri, Mar 10, 2017 at 5:04 PM, Guenter Roeck wrote: > On 03/10/2017 03:52 PM, Kevin Hilman wrote: >> >> On Fri, Mar 10, 2017 at 3:24 PM, Kevin Hilman >> wrote: >>> >>> kernelci.org bot writes: >>> stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/ Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/ Tree: stable-rc Branch: local/linux-4.10.y Git Describe: v4.10.1-168-gcdc1f9d24aac Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 101 unique boards, 25 SoC families, 30 builds out of 204 Boot Regressions Detected: arm: multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: am335x-pepper: lab-baylibre-seattle: new failure (last pass: v4.10-21-gd23a9821d397) >>> >>> >>> This one is a new regression, and a first attempt at bisect was >>> inconclusive. >> >> >> Bisect fingered the commit below. I confirmed that reverting that >> commit on top of stable-rc/linux-4.10.y gets this am335x-pepper >> platform booting again. What's rather strange is that this boot test >> is using a .cpio.gz initramfs, and not using any ext4 filesystem. >> > > Does that even make sense ? Just wondering, after the problems we are > currently > experiencing with nios2. Those "bisected" as well to a commit associated > with > code which never executed. It turned out that the change in code size caused > completely unrelated memory overwrites to be observed. Reverting the patch > in > question also seemed to "fix" the problem. Only, of course, that wasn't > true. > > Maybe something similar is happening here ? Right, I'm not confident at all in what's actually going wrong here, but I ran out of time to keep digging, so I thought I'd at least report the results. Kevin
[PATCH 2/4] mwifiex: set adapter->dev before starting to use mwifiex_dbg()
The mwifiex_dbg() log handler utilizes the struct device in
adapter->dev. Without it, it decides not to print anything.
As of commit 2e02b5814217 ("mwifiex: Allow mwifiex early access to device
structure"), we started assigning that pointer only after we finished
mwifiex_register() -- this effectively neuters any mwifiex_dbg() logging
done before this point.
Let's move the device assignment into mwifiex_register().
Fixes: 2e02b5814217 ("mwifiex: Allow mwifiex early access to device structure")
Cc: Rajat Jain
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c
b/drivers/net/wireless/marvell/mwifiex/main.c
index 5ebca1d0cfc7..43d040e02e4d 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -57,8 +57,8 @@ MODULE_PARM_DESC(mfg_mode, "manufacturing mode enable:1,
disable:0");
* In case of any errors during inittialization, this function also ensures
* proper cleanup before exiting.
*/
-static int mwifiex_register(void *card, struct mwifiex_if_ops *if_ops,
- void **padapter)
+static int mwifiex_register(void *card, struct device *dev,
+ struct mwifiex_if_ops *if_ops, void **padapter)
{
struct mwifiex_adapter *adapter;
int i;
@@ -68,6 +68,7 @@ static int mwifiex_register(void *card, struct mwifiex_if_ops
*if_ops,
return -ENOMEM;
*padapter = adapter;
+ adapter->dev = dev;
adapter->card = card;
/* Save interface specific operations in adapter */
@@ -1568,12 +1569,11 @@ mwifiex_add_card(void *card, struct completion *fw_done,
{
struct mwifiex_adapter *adapter;
- if (mwifiex_register(card, if_ops, (void **)&adapter)) {
+ if (mwifiex_register(card, dev, if_ops, (void **)&adapter)) {
pr_err("%s: software init failed\n", __func__);
goto err_init_sw;
}
- adapter->dev = dev;
mwifiex_probe_of(adapter);
adapter->iface_type = iface_type;
--
2.12.0.246.ga2ecc84866-goog
[PATCH 1/4] mwifiex: pcie: don't leak DMA buffers when removing
When PCIe FLR support was added, much of the remove/release code for
PCIe was migrated to ->down_dev(), but ->down_dev() is never called for
device removal. Let's refactor the cleanup to be done in both cases.
Also, drop the comments above mwifiex_cleanup_pcie(), because they were
clearly wrong, and it's better to have clear and obvious code than to
detail the code steps in comments anyway.
Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
Cc:
Signed-off-by: Brian Norris
---
I don't think there's any code path in which we see ->down_dev() followed by
->cleanup_if(), with no ->up_dev() in between? (Or, what happens if PCIe FLR
fails?) But if so, then this could cause a double free. It could use a close
review.
drivers/net/wireless/marvell/mwifiex/pcie.c | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 5438483fcefe..eae1cc58a310 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2732,6 +2732,21 @@ static void mwifiex_pcie_device_dump(struct
mwifiex_adapter *adapter)
schedule_work(&card->work);
}
+static void mwifiex_pcie_free_buffers(struct mwifiex_adapter *adapter)
+{
+ struct pcie_service_card *card = adapter->card;
+ const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+
+ if (reg->sleep_cookie)
+ mwifiex_pcie_delete_sleep_cookie_buf(adapter);
+
+ mwifiex_pcie_delete_cmdrsp_buf(adapter);
+ mwifiex_pcie_delete_evtbd_ring(adapter);
+ mwifiex_pcie_delete_rxbd_ring(adapter);
+ mwifiex_pcie_delete_txbd_ring(adapter);
+ card->cmdrsp_buf = NULL;
+}
+
/*
* This function initializes the PCI-E host memory space, WCB rings, etc.
*
@@ -2843,13 +2858,6 @@ static int mwifiex_init_pcie(struct mwifiex_adapter
*adapter)
/*
* This function cleans up the allocated card buffers.
- *
- * The following are freed by this function -
- * - TXBD ring buffers
- * - RXBD ring buffers
- * - Event BD ring buffers
- * - Command response ring buffer
- * - Sleep cookie buffer
*/
static void mwifiex_cleanup_pcie(struct mwifiex_adapter *adapter)
{
@@ -2868,6 +2876,8 @@ static void mwifiex_cleanup_pcie(struct mwifiex_adapter
*adapter)
"Failed to write driver not-ready
signature\n");
}
+ mwifiex_pcie_free_buffers(adapter);
+
if (pdev) {
pci_iounmap(pdev, card->pci_mmap);
pci_iounmap(pdev, card->pci_mmap1);
@@ -3119,10 +3129,7 @@ static void mwifiex_pcie_up_dev(struct mwifiex_adapter
*adapter)
pci_iounmap(pdev, card->pci_mmap1);
}
-/* This function cleans up the PCI-E host memory space.
- * Some code is extracted from mwifiex_unregister_dev()
- *
- */
+/* This function cleans up the PCI-E host memory space. */
static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
@@ -3133,14 +3140,7 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter
*adapter)
adapter->seq_num = 0;
- if (reg->sleep_cookie)
- mwifiex_pcie_delete_sleep_cookie_buf(adapter);
-
- mwifiex_pcie_delete_cmdrsp_buf(adapter);
- mwifiex_pcie_delete_evtbd_ring(adapter);
- mwifiex_pcie_delete_rxbd_ring(adapter);
- mwifiex_pcie_delete_txbd_ring(adapter);
- card->cmdrsp_buf = NULL;
+ mwifiex_pcie_free_buffers(adapter);
}
static struct mwifiex_if_ops pcie_ops = {
--
2.12.0.246.ga2ecc84866-goog
[PATCH 3/4] mwifiex: uninit wakeup info when removing device
We manually init wakeup info, but we don't detach it on device removal.
This means that if we (for example) rmmod + modprobe the driver, the
device framework might return -EEXIST the second time, and we'll
complain in the logs:
[ 839.311881] mwifiex_pcie :01:00.0: fail to init wakeup for mwifiex
AFAICT, there's no other negative effect.
But we can fix this by disabling wakeup on remove, similar to what a few
other drivers do (e.g., the power supply framework).
This code (and bug) has existed on SDIO for a while, but it got moved
around and enabled for PCIe with commit 853402a00823 ("mwifiex: Enable
WoWLAN for both sdio and pcie").
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c
b/drivers/net/wireless/marvell/mwifiex/main.c
index 43d040e02e4d..b62e03d11c2e 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1718,6 +1718,9 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter)
wiphy_unregister(adapter->wiphy);
wiphy_free(adapter->wiphy);
+ if (adapter->irq_wakeup >= 0)
+ device_init_wakeup(adapter->dev, false);
+
/* Unregister device */
mwifiex_dbg(adapter, INFO,
"info: unregister device\n");
--
2.12.0.246.ga2ecc84866-goog
[PATCH 4/4] mwifiex: pcie: de-duplicate buffer allocation code
This code was duplicated as part of the PCIe FLR code added to this
driver. Let's de-duplicate it to:
* make things easier to read (mwifiex_pcie_free_buffers() now has a
corresponding mwifiex_pcie_alloc_buffers())
* reduce likelihood of bugs
* make error logging equally verbose
* save lines of code!
Also drop some of the commentary that isn't really needed.
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 157
1 file changed, 66 insertions(+), 91 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index eae1cc58a310..889d87086913 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2732,6 +2732,61 @@ static void mwifiex_pcie_device_dump(struct
mwifiex_adapter *adapter)
schedule_work(&card->work);
}
+static int mwifiex_pcie_alloc_buffers(struct mwifiex_adapter *adapter)
+{
+ struct pcie_service_card *card = adapter->card;
+ const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+ int ret;
+
+ card->cmdrsp_buf = NULL;
+ ret = mwifiex_pcie_create_txbd_ring(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to create txbd ring\n");
+ goto err_cre_txbd;
+ }
+
+ ret = mwifiex_pcie_create_rxbd_ring(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to create rxbd ring\n");
+ goto err_cre_rxbd;
+ }
+
+ ret = mwifiex_pcie_create_evtbd_ring(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to create evtbd ring\n");
+ goto err_cre_evtbd;
+ }
+
+ ret = mwifiex_pcie_alloc_cmdrsp_buf(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to allocate cmdbuf
buffer\n");
+ goto err_alloc_cmdbuf;
+ }
+
+ if (reg->sleep_cookie) {
+ ret = mwifiex_pcie_alloc_sleep_cookie_buf(adapter);
+ if (ret) {
+ mwifiex_dbg(adapter, ERROR, "Failed to allocate
sleep_cookie buffer\n");
+ goto err_alloc_cookie;
+ }
+ } else {
+ card->sleep_cookie_vbase = NULL;
+ }
+
+ return 0;
+
+err_alloc_cookie:
+ mwifiex_pcie_delete_cmdrsp_buf(adapter);
+err_alloc_cmdbuf:
+ mwifiex_pcie_delete_evtbd_ring(adapter);
+err_cre_evtbd:
+ mwifiex_pcie_delete_rxbd_ring(adapter);
+err_cre_rxbd:
+ mwifiex_pcie_delete_txbd_ring(adapter);
+err_cre_txbd:
+ return ret;
+}
+
static void mwifiex_pcie_free_buffers(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
@@ -2749,20 +2804,12 @@ static void mwifiex_pcie_free_buffers(struct
mwifiex_adapter *adapter)
/*
* This function initializes the PCI-E host memory space, WCB rings, etc.
- *
- * The following initializations steps are followed -
- * - Allocate TXBD ring buffers
- * - Allocate RXBD ring buffers
- * - Allocate event BD ring buffers
- * - Allocate command response ring buffer
- * - Allocate sleep cookie buffer
*/
static int mwifiex_init_pcie(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
int ret;
struct pci_dev *pdev = card->dev;
- const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
pci_set_drvdata(pdev, card);
@@ -2811,37 +2858,13 @@ static int mwifiex_init_pcie(struct mwifiex_adapter
*adapter)
pr_notice("PCI memory map Virt0: %p PCI memory map Virt2: %p\n",
card->pci_mmap, card->pci_mmap1);
- card->cmdrsp_buf = NULL;
- ret = mwifiex_pcie_create_txbd_ring(adapter);
+ ret = mwifiex_pcie_alloc_buffers(adapter);
if (ret)
- goto err_cre_txbd;
- ret = mwifiex_pcie_create_rxbd_ring(adapter);
- if (ret)
- goto err_cre_rxbd;
- ret = mwifiex_pcie_create_evtbd_ring(adapter);
- if (ret)
- goto err_cre_evtbd;
- ret = mwifiex_pcie_alloc_cmdrsp_buf(adapter);
- if (ret)
- goto err_alloc_cmdbuf;
- if (reg->sleep_cookie) {
- ret = mwifiex_pcie_alloc_sleep_cookie_buf(adapter);
- if (ret)
- goto err_alloc_cookie;
- } else {
- card->sleep_cookie_vbase = NULL;
- }
- return ret;
+ goto err_alloc_buffers;
-err_alloc_cookie:
- mwifiex_pcie_delete_cmdrsp_buf(adapter);
-err_alloc_cmdbuf:
- mwifiex_pcie_delete_evtbd_ring(adapter);
-err_cre_evtbd:
- mwifiex_pcie_delete_rxbd_ring(adapter);
-err_cre_rxbd:
- mwifiex_pcie_delete_txbd_ring(adapter);
-err_cre_txbd:
+ return 0;
+
+err_alloc_buffers:
pci_iounmap(pdev, card->pci_mmap1);
err_iomap2:
pci_release_region(pdev, 2);
@@ -3053,22 +3076,15 @@
[PATCH 0/4] mwifiex: several bugfixes
Hi, I've been stressing a few aspects of this driver on 4.11-rc1, and I've noticed several bugs. The first 3 are probably bugfix material for the current cycle IMO, and the 4th is some more cleanup that matches the patterns introduced in the 1st bugfix. I have more patches coming sometime, but they're mostly just refactoring and cleaning up things at the moment (no further bugfixes yet), so I thought I'd send this stack out first. Regards, Brian Brian Norris (4): mwifiex: pcie: don't leak DMA buffers when removing mwifiex: set adapter->dev before starting to use mwifiex_dbg() mwifiex: uninit wakeup info when removing device mwifiex: pcie: de-duplicate buffer allocation code drivers/net/wireless/marvell/mwifiex/main.c | 11 +- drivers/net/wireless/marvell/mwifiex/pcie.c | 195 2 files changed, 92 insertions(+), 114 deletions(-) -- 2.12.0.246.ga2ecc84866-goog
[PATCH] x86/mce: Don't print all MCEs when mcelog is active
From: Andi Kleen
Since
cd9c57c x86/MCE: Dump MCE to dmesg if no consumers
in 4.9 all MCEs are printed even when mcelog is running. This fixes
the code again to not print when mcelog is running, because it
already takes care of the logging and predicting.
This fixes spamming all xterms for corrected errors which
is really not needed.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/mcheck/mce.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 537c6647d84c..036fc03aefbd 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -54,6 +54,8 @@
static DEFINE_MUTEX(mce_chrdev_read_mutex);
+static int mce_chrdev_open_count; /* #times opened */
+
#define mce_log_get_idx_check(p) \
({ \
RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held() && \
@@ -601,6 +603,10 @@ static int mce_default_notifier(struct notifier_block *nb,
unsigned long val,
if (atomic_read(&num_notifiers) > 2)
return NOTIFY_DONE;
+ /* Don't print when mcelog is running */
+ if (mce_chrdev_open_count > 0)
+ return NOTIFY_DONE;
+
__print_mce(m);
return NOTIFY_DONE;
@@ -1871,7 +1877,6 @@ void mcheck_cpu_clear(struct cpuinfo_x86 *c)
*/
static DEFINE_SPINLOCK(mce_chrdev_state_lock);
-static int mce_chrdev_open_count; /* #times opened */
static int mce_chrdev_open_exclu; /* already open exclusive? */
static int mce_chrdev_open(struct inode *inode, struct file *file)
--
2.9.3
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote: > On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev wrote: > > 10.03.2017 05:39, Andy Lutomirski пишет: > > > >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote: > >>> > >>> 09.03.2017 04:15, Ricardo Neri пишет: > >>> > On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > > > > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > >> > >> 08.03.2017 19:06, Andy Lutomirski пишет: > >>> > >>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > > 08.03.2017 03:32, Ricardo Neri пишет: > > > > These are the instructions covered by UMIP: > > * SGDT - Store Global Descriptor Table > > * SIDT - Store Interrupt Descriptor Table > > * SLDT - Store Local Descriptor Table > > * SMSW - Store Machine Status Word > > * STR - Store Task Register > > > > This patchset initially treated tasks running in virtual-8086 > > > > mode as a > > > > special case. However, I received clarification that DOSEMU[8] > > > > does not > > > > support applications that use these instructions. > >>> > >>> Can you remind me what was special about it? It looks like you > > > > still > >>> > >>> emulate them in v8086 mode. > >> > >> Indeed, sorry, I meant prot mode here. :) > >> So I wonder what was cited to be special about v86. > > Initially my patches disabled UMIP on virtual-8086 instructions, without > regards of protected mode (i.e., UMIP was always enabled). I didn't have > emulation at the time. Then, I added emulation code that now covers > protected and virtual-8086 modes. I guess it is not special anymore. > >>> > >>> But isn't SLDT&friends just throw UD in v86? > >>> How does UMIP affect this? How does your patch affect > >>> this? > >> > >> Er, right. Ricardo, your code may need fixing. But don't you have a > >> test case for this? > > > > Why would you need one? > > Or do you really want to allow these instructions > > in v86 by the means of emulation? If so - this wasn't > > clearly stated in the patch description, neither it was > > properly discussed, it seems. > > What I meant was: if the patches incorrectly started making these > instructions work in vm86 mode where they used to cause a vm86 exit, > then that's a bug that the selftest should have caught. Yes, this is the case. I will fix this behavior... and update the test cases.
Re: [PATCH] fs: switch order of CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH checks
On Fri, 10 Mar 2017, Stephen Smalley wrote: > generic_permission() presently checks CAP_DAC_OVERRIDE prior to > CAP_DAC_READ_SEARCH. This can cause misleading audit messages when > using a LSM such as SELinux or AppArmor, since CAP_DAC_OVERRIDE > may not be required for the operation. Flip the order of the > tests so that CAP_DAC_OVERRIDE is only checked when required for > the operation. > > Signed-off-by: Stephen Smalley Acked-by: James Morris -- James Morris
Re: [PATCH 4.10 000/167] 4.10.2-stable review
On 03/10/2017 03:52 PM, Kevin Hilman wrote: On Fri, Mar 10, 2017 at 3:24 PM, Kevin Hilman wrote: kernelci.org bot writes: stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/ Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/ Tree: stable-rc Branch: local/linux-4.10.y Git Describe: v4.10.1-168-gcdc1f9d24aac Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 101 unique boards, 25 SoC families, 30 builds out of 204 Boot Regressions Detected: arm: multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: am335x-pepper: lab-baylibre-seattle: new failure (last pass: v4.10-21-gd23a9821d397) This one is a new regression, and a first attempt at bisect was inconclusive. Bisect fingered the commit below. I confirmed that reverting that commit on top of stable-rc/linux-4.10.y gets this am335x-pepper platform booting again. What's rather strange is that this boot test is using a .cpio.gz initramfs, and not using any ext4 filesystem. Does that even make sense ? Just wondering, after the problems we are currently experiencing with nios2. Those "bisected" as well to a commit associated with code which never executed. It turned out that the change in code size caused completely unrelated memory overwrites to be observed. Reverting the patch in question also seemed to "fix" the problem. Only, of course, that wasn't true. Maybe something similar is happening here ? Guenter 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 is the first bad commit commit 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 Author: Theodore Ts'o Date: Sat Feb 4 23:04:00 2017 -0500 ext4: fix inline data error paths commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream. The write_end() function must always unlock the page and drop its ref count, even on an error. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman Kevin
Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()
On Fri, Mar 10 2017, Lars Ellenberg wrote:
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)
>> */
>> blk_qc_t generic_make_request(struct bio *bio)
>> {
>> - struct bio_list bio_list_on_stack;
>> + /*
>> +* bio_list_on_stack[0] contains bios submitted by the current
>> +* make_request_fn.
>> +* bio_list_on_stack[1] contains bios that were submitted before
>> +* the current make_request_fn, but that haven't been processed
>> +* yet.
>> +*/
>> + struct bio_list bio_list_on_stack[2];
>> blk_qc_t ret = BLK_QC_T_NONE;
>
> May I suggest that, if you intend to assign something that is not a
> plain &(struct bio_list), but a &(struct bio_list[2]),
> you change the task member so it is renamed (current->bio_list vs
> current->bio_lists, plural, is what I did last year).
> Or you will break external modules, silently, and horribly (or,
> rather, they won't notice, but break the kernel).
> Examples of such modules would be DRBD, ZFS, quite possibly others.
>
This is exactly what I didn't in my first draft (bio_list -> bio_lists),
but then I reverted that change because it didn't seem to be worth the
noise.
It isn't much noise, sched.h, bcache/btree.c, md/dm-bufio.c, and
md/raid1.c get minor changes.
But as I'm hoping to get rid of all of those uses, renaming before
removing seemed pointless ... though admittedly that is what I did for
bioset_create() I wondered about that too.
The example you give later:
struct bio_list *tmp = current->bio_list;
current->bio_list = NULL;
submit_bio()
current->bio_list = tmp;
won't cause any problem. Whatever lists the parent generic_make_request
is holding onto will be untouched during the submit_bio() call, and will
be exactly as it expects them when this caller returns.
If some out-of-tree code does anything with ->bio_list that makes sense
with the previous code, then it will still make sense with the new
code. However there will be a few bios that it didn't get too look at.
These will all be bios that were submitted by a device further up the
stack (closer to the filesystem), so they *should* be irrelevant.
I could probably come up with some weird behaviour that might have
worked before but now wouldn't quite work the same way. But just fixing
bugs can sometimes affect an out-of-tree driver in a strange way because
it was assuming those bugs.
I hope that I'll soon be able to remove punt_bios_to_rescuer and
flush_current_bio_list, after which current->bio_list can really be
just a list again. I don't think it is worth changing the name for a
transient situation.
But thanks for the review - it encouraged me to think though the
consequences again and I'm now more confident.
I actually now think that change probably wasn't necessary. It is
safer though. It ensures that current functionality isn't removed
without a clear justification.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
[PATCH] auxdisplay: use setup_timer
Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/auxdisplay/img-ascii-lcd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/auxdisplay/img-ascii-lcd.c b/drivers/auxdisplay/img-ascii-lcd.c index bf43b5d..1f30b7e 100644 --- a/drivers/auxdisplay/img-ascii-lcd.c +++ b/drivers/auxdisplay/img-ascii-lcd.c @@ -393,9 +393,7 @@ static int img_ascii_lcd_probe(struct platform_device *pdev) ctx->scroll_rate = HZ / 2; /* initialise a timer for scrolling the message */ - init_timer(&ctx->timer); - ctx->timer.function = img_ascii_lcd_scroll; - ctx->timer.data = (unsigned long)ctx; + setup_timer(&ctx->timer, img_ascii_lcd_scroll, (unsigned long)ctx); platform_set_drvdata(pdev, ctx); -- 2.9.3
[PATCH] libata: use setup_deferrable_timer
Use setup_deferrable_timer() instead of init_timer_deferrable() to simplify the code. Signed-off-by: Geliang Tang --- drivers/ata/libata-core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index ca75823..55d3c8b 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -5902,9 +5902,9 @@ struct ata_port *ata_port_alloc(struct ata_host *host) INIT_LIST_HEAD(&ap->eh_done_q); init_waitqueue_head(&ap->eh_wait_q); init_completion(&ap->park_req_pending); - init_timer_deferrable(&ap->fastdrain_timer); - ap->fastdrain_timer.function = ata_eh_fastdrain_timerfn; - ap->fastdrain_timer.data = (unsigned long)ap; + setup_deferrable_timer(&ap->fastdrain_timer, + ata_eh_fastdrain_timerfn, + (unsigned long)ap); ap->cbl = ATA_CBL_NONE; -- 2.9.3
[PATCH] fs/ocfs2/cluster: use setup_timer
Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- fs/ocfs2/cluster/tcp.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c index 4348027..de51b23 100644 --- a/fs/ocfs2/cluster/tcp.c +++ b/fs/ocfs2/cluster/tcp.c @@ -450,9 +450,8 @@ static struct o2net_sock_container *sc_alloc(struct o2nm_node *node) INIT_WORK(&sc->sc_shutdown_work, o2net_shutdown_sc); INIT_DELAYED_WORK(&sc->sc_keepalive_work, o2net_sc_send_keep_req); - init_timer(&sc->sc_idle_timeout); - sc->sc_idle_timeout.function = o2net_idle_timer; - sc->sc_idle_timeout.data = (unsigned long)sc; + setup_timer(&sc->sc_idle_timeout, o2net_idle_timer, + (unsigned long)sc); sclog(sc, "alloced\n"); -- 2.9.3
[PATCH] ambassador: use setup_timer
Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/atm/ambassador.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c index 4a61079..906705e 100644 --- a/drivers/atm/ambassador.c +++ b/drivers/atm/ambassador.c @@ -2267,9 +2267,8 @@ static int amb_probe(struct pci_dev *pci_dev, dev->atm_dev->ci_range.vpi_bits = NUM_VPI_BITS; dev->atm_dev->ci_range.vci_bits = NUM_VCI_BITS; - init_timer(&dev->housekeeping); - dev->housekeeping.function = do_housekeeping; - dev->housekeeping.data = (unsigned long) dev; + setup_timer(&dev->housekeeping, do_housekeeping, + (unsigned long)dev); mod_timer(&dev->housekeeping, jiffies); // enable host interrupts -- 2.9.3
[PATCH] Bluetooth: bluecard: use setup_timer
Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/bluetooth/bluecard_cs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/bluecard_cs.c b/drivers/bluetooth/bluecard_cs.c index c0b3b55..007c0a4 100644 --- a/drivers/bluetooth/bluecard_cs.c +++ b/drivers/bluetooth/bluecard_cs.c @@ -695,9 +695,8 @@ static int bluecard_open(struct bluecard_info *info) spin_lock_init(&(info->lock)); - init_timer(&(info->timer)); - info->timer.function = &bluecard_activity_led_timeout; - info->timer.data = (u_long)info; + setup_timer(&(info->timer), &bluecard_activity_led_timeout, + (u_long)info); skb_queue_head_init(&(info->txq)); -- 2.9.3
[PATCH] drop_monitor: use setup_timer
Use setup_timer() instead of init_timer() to simplify the code.
Signed-off-by: Geliang Tang
---
net/core/drop_monitor.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index fb55327..70ccda2 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -412,9 +412,8 @@ static int __init init_net_drop_monitor(void)
for_each_possible_cpu(cpu) {
data = &per_cpu(dm_cpu_data, cpu);
INIT_WORK(&data->dm_alert_work, send_dm_alert);
- init_timer(&data->send_timer);
- data->send_timer.data = (unsigned long)data;
- data->send_timer.function = sched_send_work;
+ setup_timer(&data->send_timer, sched_send_work,
+ (unsigned long)data);
spin_lock_init(&data->lock);
reset_per_cpu_data(data);
}
--
2.9.3
[PATCH] ACPI / APEI: use setup_deferrable_timer
Use setup_deferrable_timer() instead of init_timer_deferrable() to
simplify the code.
Signed-off-by: Geliang Tang
---
drivers/acpi/apei/ghes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index b192b42..33ca196 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1005,9 +1005,8 @@ static int ghes_probe(struct platform_device *ghes_dev)
switch (generic->notify.type) {
case ACPI_HEST_NOTIFY_POLLED:
- ghes->timer.function = ghes_poll_func;
- ghes->timer.data = (unsigned long)ghes;
- init_timer_deferrable(&ghes->timer);
+ setup_deferrable_timer(&ghes->timer, ghes_poll_func,
+ (unsigned long)ghes);
ghes_add_timer(ghes);
break;
case ACPI_HEST_NOTIFY_EXTERNAL:
--
2.9.3
[PATCH] tpm_crb: check for bad response size
Make sure size of response buffer is at least 6 bytes, or
we will underflow and pass large size_t to memcpy_fromio().
This was encountered while testing earlier version of
locality patchset.
Fixes: 30fc8d138e912 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jerry Snitselaar
---
drivers/char/tpm/tpm_crb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 89dc8a176ff1..cda4f312d1c9 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -236,7 +236,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t
count)
memcpy_fromio(buf, priv->rsp, 6);
expected = be32_to_cpup((__be32 *) &buf[2]);
- if (expected > count)
+ if (expected > count || expected < 6)
return -EIO;
memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
--
2.11.0.258.ge05806da9
[PATCH] debugfs: set no_llseek in DEFINE_DEBUGFS_ATTRIBUTE
In DEFINE_DEBUGFS_ATTRIBUTE() macro, since we use nonseekable_open() to
open, we should use no_llseek() to seek, not generic_file_llseek().
Signed-off-by: Geliang Tang
---
include/linux/debugfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 7dff776..9174b0d 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -74,7 +74,7 @@ static const struct file_operations __fops = {
\
.release = simple_attr_release, \
.read= debugfs_attr_read, \
.write = debugfs_attr_write, \
- .llseek = generic_file_llseek, \
+ .llseek = no_llseek, \
}
#if defined(CONFIG_DEBUG_FS)
--
2.9.3
Re: [PATCH v2 1/2] add driver for cypress cy8cmbr3102
Hi Patrick,
On Tue, Feb 21, 2017 at 07:40:20AM +0100, Patrick Vogelaar wrote:
> Version 2:
> * removed .owner
> * based on branch next
A better changelog would be nice: the kid of device, limitations, etc.
>
> Signed-off-by: Patrick Vogelaar
> ---
> drivers/input/misc/Kconfig | 12 +++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/cy8cmbr3102.c | 221
> +++
> 3 files changed, 234 insertions(+)
> create mode 100644 drivers/input/misc/cy8cmbr3102.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 5b6c522..be3071e 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -822,4 +822,16 @@ config INPUT_HISI_POWERKEY
> To compile this driver as a module, choose M here: the
> module will be called hisi_powerkey.
>
> +config INPUT_CY8CMBR3102
> + tristate "Cypress CY8CMBR3102 CapSense Express controller"
> + depends on I2C
> + select INPUT_POLLDEV
> + default n
"default n" can be omitted.
> + help
> + Say yes here to enable support for the Cypress CY8CMBR3102
> + CapSense Express controller.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called cy8cmbr3102.
> +
> endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index b10523f..f9959ed 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -77,3 +77,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
> obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
> obj-$(CONFIG_INPUT_YEALINK) += yealink.o
> obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
> +obj-$(CONFIG_INPUT_CY8CMBR3102) += cy8cmbr3102.o
> diff --git a/drivers/input/misc/cy8cmbr3102.c
> b/drivers/input/misc/cy8cmbr3102.c
> new file mode 100644
> index 000..ed67a63
> --- /dev/null
> +++ b/drivers/input/misc/cy8cmbr3102.c
> @@ -0,0 +1,221 @@
> +/* Driver for Cypress CY8CMBR3102 CapSense Express Controller
> + *
> + * (C) 2017 by Gigatronik Technologies GmbH
> + * Author: Patrick Vogelaar
> + * All rights reserved.
> + *
> + * This code is based on mma8450.c and atmel_captouch.c.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * 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.
> + *
> + * NOTE: This implementation does not implement the full range of functions
> the
> + * Cypress CY8CMBR3102 CapSense Express controller provides. It only
> implements
> + * its use for connected touch buttons (yet).
> + */
> +
> +#define DRV_VERSION "0.1"
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* I2C Registers */
> +#define CY8CMBR3102_DEVICE_ID_REG0x90
> +#define CY8CMBR3102_BUTTON_STAT 0xAA
> +
> +
> +#define CY8CMBR3102_MAX_NUM_OF_BUTTONS 0x02
> +#define CY8CMBR3102_DRV_NAME "cy8cmbr3102"
> +#define CY8CMBR3102_POLL_INTERVAL200
> +#define CY8CMBR3102_POLL_INTERVAL_MAX300
> +#define CY8CMBR3102_DEVICE_ID2561
> +#define CY8CMBR3102_MAX_RETRY5
> +
> +/*
> + * @i2c_client: I2C slave device client pointer
> + * @idev: Input (polled) device pointer
This kind of comments are not really helpful and just clutter the
source. Anyone looking at the structure can see that they are dealing
with i2c client pointer and polled input device pointer.
> + * @num_btn: Number of buttons
> + * @keycodes: map of button# to KeyCode
> + * @cy8cmbr3102_lock: mutex lock
> + */
> +struct cy8cmbr3102_device {
> + struct i2c_client *client;
> + struct input_polled_dev *idev;
> + u32 num_btn;
> + u32 keycodes[CY8CMBR3102_MAX_NUM_OF_BUTTONS];
> + struct mutex cy8cmbr3102_lock;
I do not think you need this mutex: we will not run several instances of
poll function simultaneously.
> +};
> +
> +static const struct i2c_device_id cy8cmbr3102_idtable[] = {
> + {"cy8cmbr3102", 0},
> + {}
Extra indent.
> +};
> +MODULE_DEVICE_TABLE(i2c, cy8cmbr3102_idtable);
Please move to the driver structure.
> +
> +static void cy8cmbr3102_poll(struct input_polled_dev *idev)
> +{
> + struct cy8cmbr3102_device *dev = idev->private;
> + int i, ret, btn_state;
> +
> + mutex_lock(&dev->cy8cmbr3102_lock);
> +
> + ret = i2c_smbus_read_word_data(dev->client, CY8CMBR3102_BUTTON_STAT);
> + if (ret < 0) {
> + dev_err(&dev->client->dev, "i2c io error: %d\n", ret);
> +
Re: [PATCH v3 0/3] meson-gx: Add mali-450 support
Neil Armstrong writes: > Since the merge of the Mali dt bindings at [1], add support for Mali clocks > and DT node. > > The Mali is clocked by two identical clock paths behind a glitch free mux > to safely change frequency while running. > So these clocks must be added to the meson-gxbb clock controller. > > > Changes since v2 at [5] : > - Rebased on v2 Audio Clocks patchset from Jerome Brunet at [6] Due to this dependency, I'd prefer patches 1-2 go through the clk tree (into an immutable branch along with the audio changes) and then I'll pick up the DT change through the amlogic tree. Kevin > - Marked parents names list as static > - Reworded patch 3 commit message > > Changes since v1 at [2] : > - Remove GP0 fixes, this will pushed later, for base frequency it can depend > on fclk_div3 > - Add GXL support > - rebase on clk-next and jbrunet's patchset at [3] and [4] > - get rid of composite clocks, this adds more clocks IDs and exposes 2 more > clocks > > [6] http://lkml.kernel.org/r/20170309104154.28295-1-jbru...@baylibre.com > [5] > http://lkml.kernel.org/r/1488365164-22861-1-git-send-email-narmstr...@baylibre.com > [4] http://lkml.kernel.org/r/20170228093016.5624-1-jbru...@baylibre.com > [3] http://lkml.kernel.org/r/20170228133002.17894-1-jbru...@baylibre.com > [2] > http://lkml.kernel.org/r/1486721084-1383-1-git-send-email-narmstr...@baylibre.com > [1] > http://lkml.kernel.org/r/b098c4fa9fce88361cca20417978734d0e1b5cca.1485939041.git-series.maxime.rip...@free-electrons.com > > Neil Armstrong (3): > clk: meson-gxbb: Add MALI clock IDS > clk: meson-gxbb: Add MALI clocks > ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL > > arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 37 ++ > arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 43 +++ > arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi | 1 + > arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 1 + > drivers/clk/meson/gxbb.c | 139 > +++ > drivers/clk/meson/gxbb.h | 9 +- > include/dt-bindings/clock/gxbb-clkc.h| 5 + > 7 files changed, 234 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free}
Hi Kuninori, On Thu, Mar 09, 2017 at 12:53:50AM +, Kuninori Morimoto wrote: > > All I know is that I'm definitely hitting a NULL > > platform->driver->pcm_new callback, and that either reverting your patch > > or applying the patch I just sent fixes it. > > I want to know why this happen. > Can you show me which driver is calling snd_soc_add_platform() in your case ? There are 4 drivers calling that: snd_soc_dummy_probe rt5514_spi_probe 2 instances of snd_dmaengine_pcm_register, via rockchip_i2s_probe Only the latter two seem to run the assignment here: if (platform_drv->pcm_new) platform->component.pcm_new = snd_soc_platform_drv_pcm_new; Both snd_soc_dummy_probe and rt5514_spi_probe find ->pcm_new NULL here. I'm running with the sound/soc/rockchip/rk3399_gru_sound.c platform driver. If it helps, I'm using the DT posted at [1]. IIUC, the "RT5514 DSP" link is trying to link up a "snd-soc-dummy" instance. I'm fairly thoroughly confused. Any better ideas? Brian [1] https://www.spinics.net/lists/arm-kernel/msg561964.html [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS
Re: [PATCH v2 0/9] clk: meson: update clock controller for audio support
Jerome Brunet writes: > This patchset is a first round of update to the meson clock controllers > to bring audio support. The patchset is based on clk-next. It could be > rebased on amlogic tree later on, if you prefer the patches to go through > Kevin's tree. I'd prefer these go through the clk tree, and get an immutable branch that I can use for my stuff that goes through the arm-soc tree. Kevin > First patch fix an issue found while writing patch 5 (Giving ternary > operator to SET_PARM) > > Following Stephen comment on the v1, patch 2 adds the const qualifiers > missing upstream. > > Patches 3 and 4 put the generic muxes and divisors declaration in tables so > the register address fixup works in the same way as the clock gates. We are > going to add more of these clock types for audio or gpu support, so we > can't continue to fix addresses individually like it is currently done. > > Patches 5 to 8 improve the support of the mpll clocks, now allowing the > rate to be set. Among other things, the mplls are the parent clocks of the > i2s and spdif clocks. > > Patch 9 expose the clock gates required to power on the i2s output. > > These patches have been tested on the meson gxbb p200 board, as part of the > ongoing work to bring audio support to meson SoC family. > > Changes since v1 [0]: > * Add SET_PARM fix to the series > * Add missing const qualifiers to the clock arrays > * No more additional patches required as SAR clocks have been merged > > [0]: http://lkml.kernel.org/r/20170228133002.17894-1-jbru...@baylibre.com > > Jerome Brunet (9): > clk: meson: fix SET_PARM macro > clk: meson: add missing const qualifiers on gate arrays > clk: meson8b: put dividers and muxes in tables > clk: gxbb: put dividers and muxes in tables > clk: meson: mpll: add rw operation > clk: meson: gxbb: mpll: use rw operation > clk: meson8b: add the mplls clocks 0, 1 and 2 > clk: meson: mpll: correct N2 maximum value > dt-bindings: clk: gxbb: expose i2s output clock gates > > drivers/clk/meson/clk-mpll.c | 152 > -- > drivers/clk/meson/clkc.h | 6 +- > drivers/clk/meson/gxbb.c | 66 --- > drivers/clk/meson/gxbb.h | 10 +-- > drivers/clk/meson/meson8b.c | 127 ++-- > drivers/clk/meson/meson8b.h | 20 - > include/dt-bindings/clock/gxbb-clkc.h | 5 ++ > 7 files changed, 356 insertions(+), 30 deletions(-)
Re: linux-next: WARNING: CPU: 1 PID: 24110 at fs/dcache.c:1445 umount_check+0x81/0x90
We have reproduced the same issue on the Linus' tree (24c534bb16):
https://s3.amazonaws.com/archive.travis-ci.org/jobs/209936923/log.txt
[ 702.992802] BUG: Dentry 95b3006c4b40{i=8deba,n=default} still
in use (1) [unmount of proc proc]
[ 703.002345] [ cut here ]
[ 703.002355] WARNING: CPU: 1 PID: 1248 at fs/dcache.c:1445
umount_check+0x81/0x90
[ 703.002357] Modules linked in:
[ 703.002363] CPU: 1 PID: 1248 Comm: zdtm_ct Not tainted 4.11.0-rc1+ #1
[ 703.002365] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01/2011
[ 703.002367] Call Trace:
[ 703.002377] dump_stack+0x85/0xc9
[ 703.002383] __warn+0xd1/0xf0
[ 703.002389] ? dentry_free+0x90/0x90
[ 703.002392] warn_slowpath_null+0x1d/0x20
[ 703.002394] umount_check+0x81/0x90
[ 703.002396] d_walk+0xef/0x4e0
[ 703.002398] ? do_one_tree+0x26/0x40
[ 703.002405] do_one_tree+0x26/0x40
[ 703.002407] shrink_dcache_for_umount+0x2d/0xa0
[ 703.002412] generic_shutdown_super+0x1f/0x100
[ 703.002415] kill_anon_super+0x12/0x20
[ 703.002419] proc_kill_sb+0x40/0x50
[ 703.002422] deactivate_locked_super+0x43/0x70
[ 703.002425] deactivate_super+0x46/0x60
[ 703.002429] cleanup_mnt+0x3f/0x80
[ 703.002431] __cleanup_mnt+0x12/0x20
[ 703.002434] task_work_run+0x83/0xc0
[ 703.002439] do_exit+0x318/0xc90
[ 703.002443] ? trace_hardirqs_on_caller+0xf9/0x1c0
[ 703.002447] do_group_exit+0x4c/0xc0
[ 703.002450] SyS_exit_group+0x14/0x20
[ 703.002455] entry_SYSCALL_64_fastpath+0x23/0xc6
[ 703.002459] RIP: 0033:0x2aac6fecf1b9
[ 703.002461] RSP: 002b:7ffe9c78f7e8 EFLAGS: 0246 ORIG_RAX:
00e7
[ 703.002465] RAX: ffda RBX: 0010 RCX: 2aac6fecf1b9
[ 703.002467] RDX: RSI: RDI:
[ 703.002468] RBP: 7ffe9c78f7e0 R08: 003c R09: 00e7
[ 703.002470] R10: ff60 R11: 0246 R12: 0001
[ 703.002472] R13: 2aac701cde80 R14: R15: 7ffe9c78f750
[ 703.002484] ---[ end trace a371a2301e08cbc1 ]---
zdtm_ct is a small program to create a container:
https://github.com/xemul/criu/blob/master/test/zdtm_ct.c
On Fri, Mar 10, 2017 at 11:28 AM, Andrei Vagin wrote:
> Hello,
>
> We run CRIU tests on linux-next periodically and here is a new bug:
>
> [ 430.017231] BUG: Dentry 8e4ab9a7b6c0{i=41b2e,n=default} still
> in use (1) [unmount of proc proc]
> [ 430.027843] [ cut here ]
> [ 430.027854] WARNING: CPU: 1 PID: 24110 at fs/dcache.c:1445
> umount_check+0x81/0x90
> [ 430.027857] Modules linked in: bridge stp llc nf_conntrack_netlink
> nfnetlink autofs4 netlink_diag af_packet_diag udp_diag tcp_diag
> inet_diag unix_diag ip6table_filter ip6_tables binfmt_misc dm_crypt
> ppdev xt_tcpudp xt_conntrack xt_mark iptable_filter ipt_MASQUERADE
> nf_nat_masquerade_ipv4 xt_addrtype iptable_nat nf_conntrack_ipv4
> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c ip_tables
> x_tables parport_pc input_leds serio_raw parport pvpanic i2c_piix4
> mac_hid btrfs xor raid6_pq crct10dif_pclmul crc32_pclmul
> ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd
> glue_helper psmouse virtio_scsi
> [ 430.027962] CPU: 1 PID: 24110 Comm: zdtm_ct Not tainted
> 4.11.0-rc1-next-20170309 #1
> [ 430.027964] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS Google 01/01/2011
> [ 430.027966] Call Trace:
> [ 430.027975] dump_stack+0x85/0xc9
> [ 430.027983] __warn+0xd1/0xf0
> [ 430.027989] ? dentry_free+0x90/0x90
> [ 430.027993] warn_slowpath_null+0x1d/0x20
> [ 430.027996] umount_check+0x81/0x90
> [ 430.027999] d_walk+0xef/0x4e0
> [ 430.028005] ? do_one_tree+0x26/0x40
> [ 430.028015] do_one_tree+0x26/0x40
> [ 430.028019] shrink_dcache_for_umount+0x2d/0xa0
> [ 430.028024] generic_shutdown_super+0x1f/0x100
> [ 430.028028] kill_anon_super+0x12/0x20
> [ 430.028033] proc_kill_sb+0x40/0x50
> [ 430.028037] deactivate_locked_super+0x43/0x70
> [ 430.028041] deactivate_super+0x46/0x60
> [ 430.028047] cleanup_mnt+0x3f/0x80
> [ 430.028050] __cleanup_mnt+0x12/0x20
> [ 430.028056] task_work_run+0x83/0xc0
> [ 430.028061] do_exit+0x318/0xc90
> [ 430.028068] ? trace_hardirqs_on_caller+0xf9/0x1c0
> [ 430.028073] do_group_exit+0x4c/0xc0
> [ 430.028077] SyS_exit_group+0x14/0x20
> [ 430.028083] entry_SYSCALL_64_fastpath+0x23/0xc2
> [ 430.028086] RIP: 0033:0x2af672eb81b9
> [ 430.028088] RSP: 002b:7fffbccef618 EFLAGS: 0246 ORIG_RAX:
> 00e7
> [ 430.028092] RAX: ffda RBX: 0010 RCX:
> 2af672eb81b9
> [ 430.028094] RDX: RSI: RDI:
>
> [ 430.028096] RBP: 7fffbccef610 R08: 003c R09:
> 00e7
> [ 430.028098] R10: ff60 R11: 0246 R12:
> 0001
> [ 430.028100] R13: 2af6731b6e80 R14: R15:
>
[PATCH 1/2] x86/xsave: Move xsave initialization to after parsing early parameters
From: Andi Kleen Move the XSAVE initialization code to be after parsing early parameters. I don't see any reason why the FPU code needs to be initialized that early, nothing else in the initialization phase uses XSAVE. This is useful to be able to handle command line parameters in the XSAVE initialization code. Signed-off-by: Andi Kleen --- arch/x86/kernel/cpu/common.c | 1 - arch/x86/kernel/setup.c | 3 +++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 58094a1f9e9d..db16a28d49a1 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -844,7 +844,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c) } setup_force_cpu_cap(X86_FEATURE_ALWAYS); - fpu__init_system(c); } void __init early_cpu_init(void) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 4bf0c8926a1c..2a85efc37e1f 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -90,6 +90,7 @@ #include #include #include +#include #include #include @@ -987,6 +988,8 @@ void __init setup_arch(char **cmdline_p) parse_early_param(); + fpu__init_system(&boot_cpu_data); + #ifdef CONFIG_MEMORY_HOTPLUG /* * Memory used by the kernel cannot be hot-removed because Linux -- 2.9.3
[PATCH 2/2] x86/fpu: Support disabling AVX and AVX512
From: Andi Kleen
For performance testing it is useful to be able to disable AVX
and AVX512. User programs check in XGETBV if AVX is supported
by the OS. If we don't initialize the XSAVE state for AVX it will
appear as if the OS is not supporting AVX. For kernel users we
can also clear the internal cpu feature bits.
This patch implements disable options for AVX and AVX512 for
the XSAVE code.
I originally considered a generic argument that would disable
any XSAVE feature, but it turns out you need special code
to also disable all the CPUID bits, because otherwise
kernel code may assume it exists, when it doesn't. MPX
already has an own disable flag. Not clear it is useful
for the others. So we only do it for AVX/AVX512 for now.
Signed-off-by: Andi Kleen
---
Documentation/admin-guide/kernel-parameters.txt | 3 ++
arch/x86/kernel/fpu/xstate.c| 61 +
2 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45caabada..d9ae4a2c07ab 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -785,6 +785,9 @@
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
+ disable_avx [X86] Disable support for AVX on Intel CPUs.
+ disable_avx512 [X86] Disable support for AVX512 on Intel CPUs.
+
disable_1tb_segments [PPC]
Disables the use of 1TB hash page table segments. This
causes the kernel to fall back to 256MB segments which
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index c24ac1efb12d..cf75638ec657 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -16,6 +16,20 @@
#include
+enum xsave_features {
+ XSAVE_X87,
+ XSAVE_SSE,
+ XSAVE_AVX,
+ XSAVE_MPX_BOUNDS,
+ XSAVE_MPX_CSR,
+ XSAVE_AVX512_OPMASK,
+ XSAVE_AVX512_HI256,
+ XSAVE_AVX512_ZMM_HI256,
+ XSAVE_PT,
+ XSAVE_PKU,
+ XSAVE_UNKNOWN
+};
+
/*
* Although we spell it out in here, the Processor Trace
* xfeature is completely unused. We use other mechanisms
@@ -41,6 +55,8 @@ static const char *xfeature_names[] =
*/
u64 xfeatures_mask __read_mostly;
+u64 xfeatures_disabled __initdata;
+
static unsigned int xstate_offsets[XFEATURE_MAX] = { [ 0 ... XFEATURE_MAX - 1]
= -1};
static unsigned int xstate_sizes[XFEATURE_MAX] = { [ 0 ... XFEATURE_MAX - 1]
= -1};
static unsigned int xstate_comp_offsets[sizeof(xfeatures_mask)*8];
@@ -52,6 +68,21 @@ static unsigned int
xstate_comp_offsets[sizeof(xfeatures_mask)*8];
*/
unsigned int fpu_user_xstate_size;
+static void clear_avx512(void)
+{
+ setup_clear_cpu_cap(X86_FEATURE_AVX512F);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512IFMA);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512PF);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512ER);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512CD);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512DQ);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512BW);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512VL);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512VBMI);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512_4VNNIW);
+ setup_clear_cpu_cap(X86_FEATURE_AVX512_4FMAPS);
+}
+
/*
* Clear all of the X86_FEATURE_* bits that are unavailable
* when the CPU has no XSAVE support.
@@ -64,17 +95,9 @@ void fpu__xstate_clear_all_cpu_caps(void)
setup_clear_cpu_cap(X86_FEATURE_XSAVES);
setup_clear_cpu_cap(X86_FEATURE_AVX);
setup_clear_cpu_cap(X86_FEATURE_AVX2);
- setup_clear_cpu_cap(X86_FEATURE_AVX512F);
- setup_clear_cpu_cap(X86_FEATURE_AVX512IFMA);
- setup_clear_cpu_cap(X86_FEATURE_AVX512PF);
- setup_clear_cpu_cap(X86_FEATURE_AVX512ER);
- setup_clear_cpu_cap(X86_FEATURE_AVX512CD);
- setup_clear_cpu_cap(X86_FEATURE_AVX512DQ);
- setup_clear_cpu_cap(X86_FEATURE_AVX512BW);
- setup_clear_cpu_cap(X86_FEATURE_AVX512VL);
+ clear_avx512();
setup_clear_cpu_cap(X86_FEATURE_MPX);
setup_clear_cpu_cap(X86_FEATURE_XGETBV1);
- setup_clear_cpu_cap(X86_FEATURE_AVX512VBMI);
setup_clear_cpu_cap(X86_FEATURE_PKU);
setup_clear_cpu_cap(X86_FEATURE_AVX512_4VNNIW);
setup_clear_cpu_cap(X86_FEATURE_AVX512_4FMAPS);
@@ -735,6 +758,7 @@ void __init fpu__init_system_xstate(void)
goto out_disable;
}
+ xfeatures_mask &= ~xfeatures_disabled;
xfeatures_mask &= fpu__get_supported_xfeatures_mask();
/* Enable xstate instructions to be able to continue with
initialization: */
@@ -1080,3 +1104,22 @@ int copyin_to_xsaves(const void *kbuf, const void __user
*ubuf,
return 0;
}
+
+static int __init parse_disable_avx512(char *str)
+{
+ xfeatures_disabled |= BIT(XSAVE_AVX512_OPMASK)
[PATCH] x86-32: fix tlb flushing when lguest clears PGE
Fengguang reported [1] random corruptions from various locations on
x86-32 after commits d2852a224050 ("arch: add ARCH_HAS_SET_MEMORY
config") and 9d876e79df6a ("bpf: fix unlocking of jited image when
module ronx not set") that uses the former. While x86-32 doesn't
have a JIT like x86_64, the bpf_prog_lock_ro() and bpf_prog_unlock_ro()
got enabled due to ARCH_HAS_SET_MEMORY, whereas Fengguang's test
kernel doesn't have module support built in and therefore never
had the DEBUG_SET_MODULE_RONX setting enabled.
After investigating the crashes further, it turned out that using
set_memory_ro() and set_memory_rw() didn't have the desired effect,
for example, setting the pages as read-only on x86-32 would still
let probe_kernel_write() succeed without error. This behavior would
manifest itself in situations where the vmalloc'ed buffer was accessed
prior to set_memory_*() such as in case of bpf_prog_alloc(). In
cases where it wasn't, the page attribute changes seemed to have
taken effect, leading to the conclusion that a TLB invalidate
didn't happen. Moreover, it turned out that this issue reproduced
with qemu in "-cpu kvm64" mode, but not for "-cpu host". When the
issue occurs, change_page_attr_set_clr() did trigger a TLB flush
as expected via __flush_tlb_all() through cpa_flush_range(), though.
There are 3 variants for issuing a TLB flush: invpcid_flush_all()
(depends on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE),
cr4 based flush (depends on X86_FEATURE_PGE), and cr3 based flush.
For "-cpu host" case in my setup, the flush used invpcid_flush_all()
variant, whereas for "-cpu kvm64", the flush was cr4 based. Switching
the kvm64 case to cr3 manually worked fine, and further investigating
the cr4 one turned out that X86_CR4_PGE bit was not set in cr4
register, meaning the __native_flush_tlb_global_irq_disabled() wrote
cr4 twice with the same value instead of clearing X86_CR4_PGE in the
first write to trigger the flush.
It turned out that X86_CR4_PGE was cleared from cr4 during init
from lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE
bit is also cleared from there due to concerns of using PGE in
guest kernel that can lead to hard to trace bugs (see bff672e630a0
("lguest: documentation V: Host") in init()). The CPU feature bits
are cleared in dynamic boot_cpu_data, but they never propagated to
__flush_tlb_all() as it uses static_cpu_has() instead of boot_cpu_has()
for testing which variant of TLB flushing to use, meaning they still
used the old setting of the host kernel.
Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would
propagate to static_cpu_has() checks is too late at this point as
sections have been patched already, so for now, it seems reasonable
to switch back to boot_cpu_has(X86_FEATURE_PGE) as it was prior to
commit c109bf95992b ("x86/cpufeature: Remove cpu_has_pge"). This
lets the TLB flush trigger via cr3 as originally intended, properly
makes the new page attributes visible and thus fixes the crashes
seen by Fengguang.
[1] https://lkml.org/lkml/2017/3/1/344
Fixes: c109bf95992b ("x86/cpufeature: Remove cpu_has_pge")
Reported-by: Fengguang Wu
Signed-off-by: Daniel Borkmann
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Thomas Gleixner
Cc: Kees Cook
Cc: Laura Abbott
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Rusty Russell
Cc: Alexei Starovoitov
Cc: David S. Miller
---
arch/x86/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 6fa8594..fc5abff 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -188,7 +188,7 @@ static inline void __native_flush_tlb_single(unsigned long
addr)
static inline void __flush_tlb_all(void)
{
- if (static_cpu_has(X86_FEATURE_PGE))
+ if (boot_cpu_has(X86_FEATURE_PGE))
__flush_tlb_global();
else
__flush_tlb();
--
1.9.3
Re: tty crash in Linux 4.6
> This patch works, I've had no tty crashes since applying it.
>
> I've seen that you haven't sent this patch yet to Linux-4.7-rc and
> Linux-4.6-stable. Will you? Or did you create a different patch?
We are hitting this now on powerpc. This patch never seemed to make
it upstream (drivers/tty/tty_ldisc.c hasn't been touched in 1 year).
Peter, can we take this patch as is, or do you have an updated version?
Mikey
> Mikulas
>
>
> On Tue, 17 May 2016, Peter Hurley wrote:
>
> > On 05/17/2016 08:57 AM, Peter Hurley wrote:
> > > On 05/16/2016 04:36 PM, Peter Hurley wrote:
> > >> > Hi Mikulas,
> > >> >
> > >> > On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
> > >>> >> Hi
> > >>> >>
> > >>> >> In the kernel 4.6 I get crashes in the tty layer. I can reproduce the
> > >>> >> crash by logging into the machine with ssh and typing before the
> > >>> >> prompt
> > >>> >> appears.
> > >> >
> > >> > Thanks for the report.
> > >> > I tried to reproduce this a number of times on different machines
> > >> > with no luck.
> > >
> > > I was able to reproduce this crash with a test jig.
> > > The patch below fixed it, but I'm testing a better patch now, which
> > > I'll get to you asap.
> >
> > --- >% ---
> > Subject: [PATCH] tty: Fix ldisc crash on reopened tty
> >
> > If the tty has been hungup, the ldisc instance may have been destroyed.
> > Continued input to the tty will be ignored as long as the ldisc instance
> > is not visible to the flush_to_ldisc kworker. However, when the tty
> > is reopened and a new ldisc instance is created, the flush_to_ldisc
> > kworker can obtain an ldisc reference before the new ldisc is
> > completely initialized. This will likely crash:
> >
> > BUG: unable to handle kernel paging request at 2260
> > IP: [] n_tty_receive_buf_common+0x6d/0xb80
> > PGD 2ab581067 PUD 290c11067 PMD 0
> > Oops: [#1] PREEMPT SMP
> > Modules linked in: nls_iso8859_1 ip6table_filter [.]
> > CPU: 2 PID: 103 Comm: kworker/u16:1 Not tainted 4.6.0-rc7+wip-xeon+debug
> > #rc7+wip
> > Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11
> > 04/30/2012
> > Workqueue: events_unbound flush_to_ldisc
> > task: 8802ad16d100 ti: 8802ad31c000 task.ti: 8802ad31c000
> > RIP: 0010:[] []
> > n_tty_receive_buf_common+0x6d/0xb80
> > RSP: 0018:8802ad31fc70 EFLAGS: 00010296
> > RAX: RBX: 8802aaddd800 RCX: 0001
> > RDX: RSI: 810db48f RDI: 0246
> > RBP: 8802ad31fd08 R08: R09: 0001
> > R10: 8802aadddb28 R11: 0001 R12: 8800ba6da808
> > R13: 8802ad18be80 R14: 8800ba6da858 R15: 8800ba6da800
> > FS: () GS:8802b0a0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 2260 CR3: 00028ee5d000 CR4: 06e0
> > Stack:
> > 81531219 8802aadddab8 8802aae0 8802aa78
> > 0001 8800ba6da858 8800ba6da860 8802ad31fd30
> > 81885f78 81531219 0002
> > Call Trace:
> > [] ? flush_to_ldisc+0x49/0xd0
> > [] ? mutex_lock_nested+0x2c8/0x430
> > [] ? flush_to_ldisc+0x49/0xd0
> > [] n_tty_receive_buf2+0x14/0x20
> > [] tty_ldisc_receive_buf+0x22/0x50
> > [] flush_to_ldisc+0xbe/0xd0
> > [] process_one_work+0x1ed/0x6e0
> > [] ? process_one_work+0x16f/0x6e0
> > [] worker_thread+0x4e/0x490
> > [] ? process_one_work+0x6e0/0x6e0
> > [] kthread+0xf2/0x110
> > [] ? preempt_count_sub+0x4c/0x80
> > [] ret_from_fork+0x22/0x50
> > [] ? kthread_create_on_node+0x220/0x220
> > Code: ff ff e8 27 a0 35 00 48 8d 83 78 05 00 00 c7 45 c0 00 00 00 00 48 89
> > 45 80 48
> >8d 83 e0 05 00 00 48 89 85 78 ff ff ff 48 8b 45 b8 <48> 8b b8 60 22
> > 00 00 48
> >8b 30 89 f8 8b 8b 88 04 00 00 29 f0 8d
> > RIP [] n_tty_receive_buf_common+0x6d/0xb80
> > RSP
> > CR2: 2260
> >
> > Ensure the kworker cannot obtain the ldisc reference until the new ldisc
> > is completely initialized.
> >
> > Fixes: 892d1fa7eaae ("tty: Destroy ldisc instance on hangup")
> > Reported-by: Mikulas Patocka
> > Signed-off-by: Peter Hurley
> > ---
> > drivers/tty/tty_ldisc.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
> > index cdd063f..bda0c85 100644
> > --- a/drivers/tty/tty_ldisc.c
> > +++ b/drivers/tty/tty_ldisc.c
> > @@ -669,16 +669,17 @@ int tty_ldisc_reinit(struct tty_struct *tty, int disc)
> > tty_ldisc_put(tty->ldisc);
> > }
> >
> > - /* switch the line discipline */
> > - tty->ldisc = ld;
> > tty_set_termios_ldisc(tty, disc);
> > - retval = tty_ldisc_open(tty, tty->ldisc);
> > + retval = tty_ldisc_open(tty, ld);
> > if (retval) {
> > if (!WARN_ON(disc == N_TTY)) {
> > -
Re: [PATCH] tpm_crb: request and relinquish locality 0
On Sat, Mar 11, 2017 at 01:58:00AM +0200, Jarkko Sakkinen wrote: > Added two new callbacks to struct tpm_class_ops: > > - request_locality > - relinquish_locality > > These are called before sending and receiving data from the TPM. If we are going to add new ops, I think we should also adjust the existing drivers to use this mechanism as well? eg tis just calls its request_locality as the first thing in send.. Jason
Re: [PATCH 3/3] ARM64: dts: meson-gx: Prepend GX generic compatible like other nodes
Neil Armstrong writes:
> Signed-off-by: Neil Armstrong
Could use a bit more changelog here (in order to support generic
drivers that work for all GX family, blah, blah...)
Kevin
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index 06d70bf..a010ab9 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -233,7 +233,7 @@
> };
>
> i2c_A: i2c@8500 {
> - compatible = "amlogic,meson-gxbb-i2c";
> + compatible = "amlogic,meson-gx-i2c",
> "amlogic,meson-gxbb-i2c";
> reg = <0x0 0x08500 0x0 0x20>;
> interrupts = ;
> #address-cells = <1>;
> @@ -279,7 +279,7 @@
> };
>
> i2c_B: i2c@87c0 {
> - compatible = "amlogic,meson-gxbb-i2c";
> + compatible = "amlogic,meson-gx-i2c",
> "amlogic,meson-gxbb-i2c";
> reg = <0x0 0x087c0 0x0 0x20>;
> interrupts = ;
> #address-cells = <1>;
> @@ -288,7 +288,7 @@
> };
>
> i2c_C: i2c@87e0 {
> - compatible = "amlogic,meson-gxbb-i2c";
> + compatible = "amlogic,meson-gx-i2c",
> "amlogic,meson-gxbb-i2c";
> reg = <0x0 0x087e0 0x0 0x20>;
> interrupts = ;
> #address-cells = <1>;
> @@ -297,7 +297,7 @@
> };
>
> spifc: spi@8c80 {
> - compatible = "amlogic,meson-gxbb-spifc";
> + compatible = "amlogic,meson-gx-spifc",
> "amlogic,meson-gxbb-spifc";
> reg = <0x0 0x08c80 0x0 0x80>;
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -325,7 +325,7 @@
> };
>
> sram: sram@c800 {
> - compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
> + compatible = "amlogic,meson-gx-sram",
> "amlogic,meson-gxbb-sram", "mmio-sram";
> reg = <0x0 0xc800 0x0 0x14000>;
>
> #address-cells = <1>;
> @@ -333,12 +333,12 @@
> ranges = <0 0x0 0xc800 0x14000>;
>
> cpu_scp_lpri: scp-shmem@0 {
> - compatible = "amlogic,meson-gxbb-scp-shmem";
> + compatible = "amlogic,meson-gx-scp-shmem",
> "amlogic,meson-gxbb-scp-shmem";
> reg = <0x13000 0x400>;
> };
>
> cpu_scp_hpri: scp-shmem@200 {
> - compatible = "amlogic,meson-gxbb-scp-shmem";
> + compatible = "amlogic,meson-gx-scp-shmem",
> "amlogic,meson-gxbb-scp-shmem";
> reg = <0x13400 0x400>;
> };
> };
> @@ -390,7 +390,7 @@
> };
>
> ir: ir@580 {
> - compatible = "amlogic,meson-gxbb-ir";
> + compatible = "amlogic,meson-gx-ir",
> "amlogic,meson-gxbb-ir";
> reg = <0x0 0x00580 0x0 0x40>;
> interrupts = ;
> status = "disabled";
Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free}
On Thu, Mar 09, 2017 at 12:09:18PM +0100, Mark Brown wrote:
> On Wed, Mar 08, 2017 at 03:18:54PM -0800, Brian Norris wrote:
> > Not all platform drivers have pcm_{new,free} callbacks. Seen with a
> > "snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c.
> >
> > Resolves an OOPS seen on v4.11-rc1 with Google Kevin (Samsung Chromebook
> > Plus):
> >
> > [2.863304] rk3399-gru-sound sound: HiFi <-> ff88.i2s mapping ok
> > [2.886930] rk3399-gru-sound sound: rt5514-aif1 <-> ff88.i2s mapping
> > ok
>
> Please think hard before including complete backtraces in upstream
> reports, they are very large and contain almost no useful information
> relative to their size so often obscure the relevant content in your
> message. If part of the backtrace is usefully illustrative then it's
> usually better to pull out the relevant sections.
I did think, and I did trim the trace significantly. I believe (or
believed; maybe incorrectly) that much of the remaining context *was*
useful, and that it could have answered some of Kuninori's questions, if
he chose to dig himself. As admitted in the commit message, I don't
really understand all of the relationships here, so it's hard to
highlight "only the relevant sections".
I'm sorry that my post did not meet your standards though. Next time
I'll just post a revert with little context and no attempt to understand
what actually went wrong.
Regards,
Brian
Re: [PATCH 1/3] ARM64: dts: meson-gx: Finally move common nodes to GX dtsi
Neil Armstrong writes:
> Signed-off-by: Neil Armstrong
Could use a bit more changelog here (probably what you have in the cover
letter.)
Otherwise, looks good. Thanks for the cleanup.
Kevin
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 24
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 43
> ++---
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 8 ++
> 3 files changed, 40 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index 5d995f7..2d8dc6f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -296,6 +296,14 @@
> status = "disabled";
> };
>
> + spifc: spi@8c80 {
> + compatible = "amlogic,meson-gxbb-spifc";
> + reg = <0x0 0x08c80 0x0 0x80>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> watchdog@98d0 {
> compatible = "amlogic,meson-gx-wdt",
> "amlogic,meson-gxbb-wdt";
> reg = <0x0 0x098d0 0x0 0x10>;
> @@ -342,6 +350,13 @@
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xc810 0x0 0x10>;
>
> + clkc_AO: clock-controller@040 {
> + compatible = "amlogic,gx-aoclkc",
> "amlogic,gxbb-aoclkc";
> + reg = <0x0 0x00040 0x0 0x4>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> uart_AO: serial@4c0 {
> compatible = "amlogic,meson-uart";
> reg = <0x0 0x004c0 0x0 0x14>;
> @@ -358,6 +373,15 @@
> status = "disabled";
> };
>
> + i2c_AO: i2c@500 {
> + compatible = "amlogic,meson-gx-i2c",
> "amlogic,meson-gxbb-i2c";
> + reg = <0x0 0x500 0x0 0x20>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> pwm_AO_ab: pwm@550 {
> compatible = "amlogic,meson-gx-pwm",
> "amlogic,meson-gxbb-pwm";
> reg = <0x0 0x00550 0x0 0x10>;
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 04b3324..c2c41aa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -97,17 +97,6 @@
> };
> };
>
> -&cbus {
> - spifc: spi@8c80 {
> - compatible = "amlogic,meson-gxbb-spifc";
> - reg = <0x0 0x08c80 0x0 0x80>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - clocks = <&clkc CLKID_SPI>;
> - status = "disabled";
> - };
> -};
> -
> ðmac {
> clocks = <&clkc CLKID_ETH>,
><&clkc CLKID_FCLK_DIV2>,
> @@ -204,30 +193,6 @@
> };
> };
> };
> -
> - clkc_AO: clock-controller@040 {
> - compatible = "amlogic,gxbb-aoclkc";
> - reg = <0x0 0x00040 0x0 0x4>;
> - #clock-cells = <1>;
> - #reset-cells = <1>;
> - };
> -
> - pwm_ab_AO: pwm@550 {
> - compatible = "amlogic,meson-gxbb-pwm";
> - reg = <0x0 0x0550 0x0 0x10>;
> - #pwm-cells = <3>;
> - status = "disabled";
> - };
> -
> - i2c_AO: i2c@500 {
> - compatible = "amlogic,meson-gxbb-i2c";
> - reg = <0x0 0x500 0x0 0x20>;
> - interrupts = ;
> - clocks = <&clkc CLKID_AO_I2C>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - status = "disabled";
> - };
> };
>
> &periphs {
> @@ -482,6 +447,10 @@
> clocks = <&clkc CLKID_I2C>;
> };
>
> +&i2c_AO {
> + clocks = <&clkc CLKID_AO_I2C>;
> +};
> +
> &i2c_B {
> clocks = <&clkc CLKID_I2C>;
> };
> @@ -521,6 +490,10 @@
> clock-names = "core", "clkin0", "clkin1";
> };
>
> +&spifc {
> + clocks = <&clkc CLKID_SPI>;
> +};
> +
> &vpu {
> compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index 17cd546..37ed7a0 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Sat, 2017-03-11 at 02:58 +0300, Stas Sergeev wrote: > 11.03.2017 02:47, Ricardo Neri пишет: > >> > It doesn't need to be a matter of this particular > patch set, i.e. this proposal should not trigger a > v7 resend of all 21 patches. :) But it would be useful > for the future development of dosemu2. > >>> Would dosemu2 use 32-bit processes in order to keep segmentation? If it > >>> could use 64-bit processes, emulation is not used in this case and the > >>> SIGSEGV is delivered to user space. > >> It does use the mix: 64bit process but some segments > >> are 32bit for DOS code. > > Do you mean that dosemu2 will start as a 64-bit process and will jump to > > 32-bit code segments? > Yes, so the offending insns are executed only in 32bit > and 16bit segments, even if the process itself is 64bit. > I guess you handle 16bit segments same as 32bit ones. I have code to handle 16-bit and 32-bit address encodings differently. Segmentation is used if !user_64bit_mode(regs). In such a case, the emulation code will check the segment descriptor D flag and the address-size overrides prefix to determine the address size and use 16-bit or 32-bit address encodings as applicable. > > > My emulation code should work in this case as it > > will use segmentation in 32-bit code descriptors. Is there anything else > > needed? > If I understand you correctly, you are saying that SLDT > executed in 64bit code segment, will inevitably segfault > to userspace. Correct. > If this is the case and it makes your code > simpler, then its perfectly fine with me as dosemu does > not do this and the 64bit DOS progs are not anticipated. But if 32-bit or 16-bit code segments are used emulation will be used. Thanks and BR, Ricardo
Re: tty layer NULL pointer reference with 4.10
Andi Kleen writes: > Hi, > > I had a large systems with lots of cores stop responding to new ssh > requests. It turned out it crashed in the tty layer. The system > has a serial console and had some active sshs and screen Correction. This may have been a linux-next kernel, not 4.10 I'll see if I can reproduce it again. -Andi > > [24922.097093] BUG: unable to handle kernel paging request at 2260 > [24922.64] IP: n_tty_receive_buf_common+0x6d/0xc60 > [24922.122869] PGD 0 > [24922.138890] Oops: [#1] SMP > [24922.148268] Modules linked in: > [24922.157613] CPU: 0 PID: 9947 Comm: kworker/u449:1 Not tainted > 4.10.0-g70afbe1-dirty #9 > [24922.189392] Workqueue: events_unbound flush_to_ldisc > [24922.200888] task: 88084eda8000 task.stack: c9002502c000 > [24922.213484] RIP: 0010:n_tty_receive_buf_common+0x6d/0xc60 > [24922.225700] RSP: 0018:c9002502fd30 EFLAGS: 00010297 > [24922.237444] RAX: RBX: 88105cf72800 RCX: > 00d8 > [24922.251407] RDX: 8000 RSI: 88085f00b448 RDI: > 88105cf728c0 > [24922.265229] RBP: c9002502fdc8 R08: 0001 R09: > > [24922.279328] R10: 15a7c208b8ba R11: 88085f29d400 R12: > 88085f00b548 > [24922.293085] R13: 00d8 R14: 88105deb5800 R15: > 88085de5c008 > [24922.306790] FS: () GS:88085f40() > knlGS: > [24922.321635] CS: 0010 DS: ES: CR0: 80050033 > [24922.333765] CR2: 2260 CR3: 01e0a000 CR4: > 007406f0 > [24922.347455] DR0: DR1: DR2: > > [24922.361097] DR3: DR6: fffe0ff0 DR7: > 0400 > [24922.374599] PKRU: 5554 > [24922.383213] Call Trace: > [24922.391330] ? account_entity_dequeue+0x65/0xa0 > [24922.401747] n_tty_receive_buf2+0x14/0x20 > [24922.411513] tty_ldisc_receive_buf+0x22/0x50 > [24922.421492] tty_port_default_receive_buf+0x45/0x60 > [24922.432138] flush_to_ldisc+0x99/0xb0 > [24922.441357] process_one_work+0x16c/0x420 > [24922.450885] worker_thread+0x4b/0x480 > [24922.459976] kthread+0x101/0x140 > [24922.468481] ? process_one_work+0x420/0x420 > [24922.478078] ? kthread_park+0x90/0x90 > [24922.487495] ret_from_fork+0x29/0x40 > [24922.496259] Code: ff ff e8 57 b1 43 00 48 8d 83 00 02 00 00 c7 45 > c0 00 00 00 00 48 89 45 80 48 8d 83 28 02 00 00 48 89 85 78 ff ff ff > 48 8b 45 b8 <48> 8b b8 60 22 00 00 48 8b 30 8b 8b 10 01 00 00 89 f8 29 > f0 f6 > [24922.527211] RIP: n_tty_receive_buf_common+0x6d/0xc60 RSP: c9002502fd30 > [24922.539855] CR2: 2260 > [24922.559634] ---[ end trace dab97c7b5cf9c543 ]--- > > -Andi
Re: [f2fs-dev] [PATCH 1/2] f2fs: le16_to_cpu for xattr->e_value_size
On 3/11/2017 01:53, Jaegeuk Kim wrote:
> This patch fixes missing le16 conversion, reported by kbuild test robot.
>
> Fixes: 5f35a2cd5 ("f2fs: Don't update the xattr data that same as the exist")
> Signed-off-by: Jaegeuk Kim
Reviewed-by: Kinglong Mee
> ---
> fs/f2fs/xattr.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
> index 7298a4488f7f..aff7619e3f96 100644
> --- a/fs/f2fs/xattr.c
> +++ b/fs/f2fs/xattr.c
> @@ -546,7 +546,9 @@ static bool f2fs_xattr_value_same(struct f2fs_xattr_entry
> *entry,
> const void *value, size_t size)
> {
> void *pval = entry->e_name + entry->e_name_len;
> - return (entry->e_value_size == size) && !memcmp(pval, value, size);
> +
> + return (le16_to_cpu(entry->e_value_size) == size) &&
> + !memcmp(pval, value, size);
> }
>
> static int __f2fs_setxattr(struct inode *inode, int index,
>
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: > 10.03.2017 05:39, Andy Lutomirski пишет: > > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote: > >> 09.03.2017 04:15, Ricardo Neri пишет: > >> > >>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > > 08.03.2017 19:06, Andy Lutomirski пишет: > >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > >>> 08.03.2017 03:32, Ricardo Neri пишет: > These are the instructions covered by UMIP: > * SGDT - Store Global Descriptor Table > * SIDT - Store Interrupt Descriptor Table > * SLDT - Store Local Descriptor Table > * SMSW - Store Machine Status Word > * STR - Store Task Register > > This patchset initially treated tasks running in virtual-8086 > mode as a > special case. However, I received clarification that DOSEMU[8] > does not > support applications that use these instructions. > >> Can you remind me what was special about it? It looks like you > still > >> emulate them in v8086 mode. > > Indeed, sorry, I meant prot mode here. :) > > So I wonder what was cited to be special about v86. > >>> Initially my patches disabled UMIP on virtual-8086 instructions, without > >>> regards of protected mode (i.e., UMIP was always enabled). I didn't have > >>> emulation at the time. Then, I added emulation code that now covers > >>> protected and virtual-8086 modes. I guess it is not special anymore. > >> But isn't SLDT&friends just throw UD in v86? > >> How does UMIP affect this? How does your patch affect > >> this? > > Er, right. Ricardo, your code may need fixing. But don't you have a > > test case for this? > Why would you need one? > Or do you really want to allow these instructions > in v86 by the means of emulation? If so - this wasn't > clearly stated in the patch description, neither it was > properly discussed, it seems. It str and sldt can be emulated in vm86 but as Andy mention, the behavior sould be the same with and without emulation. Thanks and BR, Ricardo
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
11.03.2017 02:47, Ricardo Neri пишет: It doesn't need to be a matter of this particular patch set, i.e. this proposal should not trigger a v7 resend of all 21 patches. :) But it would be useful for the future development of dosemu2. Would dosemu2 use 32-bit processes in order to keep segmentation? If it could use 64-bit processes, emulation is not used in this case and the SIGSEGV is delivered to user space. It does use the mix: 64bit process but some segments are 32bit for DOS code. Do you mean that dosemu2 will start as a 64-bit process and will jump to 32-bit code segments? Yes, so the offending insns are executed only in 32bit and 16bit segments, even if the process itself is 64bit. I guess you handle 16bit segments same as 32bit ones. My emulation code should work in this case as it will use segmentation in 32-bit code descriptors. Is there anything else needed? If I understand you correctly, you are saying that SLDT executed in 64bit code segment, will inevitably segfault to userspace. If this is the case and it makes your code simpler, then its perfectly fine with me as dosemu does not do this and the 64bit DOS progs are not anticipated.
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Thu, 2017-03-09 at 18:39 -0800, Andy Lutomirski wrote: > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote: > > 09.03.2017 04:15, Ricardo Neri пишет: > > > >> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > >>> > >>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > > 08.03.2017 19:06, Andy Lutomirski пишет: > > > > On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > >> > >> 08.03.2017 03:32, Ricardo Neri пишет: > >>> > >>> These are the instructions covered by UMIP: > >>> * SGDT - Store Global Descriptor Table > >>> * SIDT - Store Interrupt Descriptor Table > >>> * SLDT - Store Local Descriptor Table > >>> * SMSW - Store Machine Status Word > >>> * STR - Store Task Register > >>> > >>> This patchset initially treated tasks running in virtual-8086 > >>> > >>> mode as a > >>> > >>> special case. However, I received clarification that DOSEMU[8] > >>> > >>> does not > >>> > >>> support applications that use these instructions. > > > > Can you remind me what was special about it? It looks like you > >>> > >>> still > > > > emulate them in v8086 mode. > > Indeed, sorry, I meant prot mode here. :) > So I wonder what was cited to be special about v86. > >> > >> Initially my patches disabled UMIP on virtual-8086 instructions, without > >> regards of protected mode (i.e., UMIP was always enabled). I didn't have > >> emulation at the time. Then, I added emulation code that now covers > >> protected and virtual-8086 modes. I guess it is not special anymore. > > > > But isn't SLDT&friends just throw UD in v86? > > How does UMIP affect this? How does your patch affect > > this? > > Er, right. Ricardo, your code may need fixing. But don't you have a > test case for this? The behavior should be the same with and without > your patches applied. The exception is #UD, not #GP, so maybe your > code just never executes in the vm86 case. Ouch! Yes, I am afraid my code will attempt to emulate sldt in vm86 mode. The test cases that I have for vm86 are only for the instructions that are valid in vm86: smsw, sidt and sgdt. I will add test cases for str and sldt and make sure that a #UD is issued. Would this trigger a v7 series? Thanks and BR, Ricardo > > --Andy
[PATCH] tpm_crb: request and relinquish locality 0
Added two new callbacks to struct tpm_class_ops:
- request_locality
- relinquish_locality
These are called before sending and receiving data from the TPM.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 9 +
drivers/char/tpm/tpm_crb.c | 41 +++-
include/linux/tpm.h | 3 ++-
3 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index bd2128e..ae6aafa 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -369,6 +369,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const u8 *buf,
size_t bufsiz,
if (chip->dev.parent)
pm_runtime_get_sync(chip->dev.parent);
+ if (chip->ops->request_locality) {
+ rc = chip->ops->request_locality(chip);
+ if (rc)
+ goto out;
+ }
+
rc = chip->ops->send(chip, (u8 *) buf, count);
if (rc < 0) {
dev_err(&chip->dev,
@@ -410,6 +416,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const u8 *buf,
size_t bufsiz,
dev_err(&chip->dev,
"tpm_transmit: tpm_recv: error %zd\n", rc);
out:
+ if (chip->ops->relinquish_locality)
+ chip->ops->relinquish_locality(chip);
+
if (chip->dev.parent)
pm_runtime_put_sync(chip->dev.parent);
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 3245618..89dc8a176 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -34,6 +34,15 @@ enum crb_defaults {
CRB_ACPI_START_INDEX = 1,
};
+enum crb_loc_ctrl {
+ CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
+ CRB_LOC_CTRL_RELINQUISH = BIT(1),
+};
+
+enum crb_loc_state {
+ CRB_LOC_STATE_LOC_ASSIGNED = BIT(1),
+};
+
enum crb_ctrl_req {
CRB_CTRL_REQ_CMD_READY = BIT(0),
CRB_CTRL_REQ_GO_IDLE= BIT(1),
@@ -172,6 +181,35 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
return 0;
}
+static int crb_request_locality(struct tpm_chip *chip)
+{
+ struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+
+ if (!priv->regs_h)
+ return 0;
+
+ iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, &priv->regs_h->loc_ctrl);
+ if (!crb_wait_for_reg_32(&priv->regs_h->loc_state,
+CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
+CRB_LOC_STATE_LOC_ASSIGNED, /* value */
+TPM2_TIMEOUT_C)) {
+ dev_warn(&chip->dev, "TPM_LOC_STATE_x.requestAccess timed
out\n");
+ return -ETIME;
+ }
+
+ return 0;
+}
+
+static void crb_relinquish_locality(struct tpm_chip *chip)
+{
+ struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+
+ if (!priv->regs_h)
+ return;
+
+ iowrite32(CRB_LOC_CTRL_RELINQUISH, &priv->regs_h->loc_ctrl);
+}
+
static u8 crb_status(struct tpm_chip *chip)
{
struct crb_priv *priv = dev_get_drvdata(&chip->dev);
@@ -198,7 +236,6 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t
count)
memcpy_fromio(buf, priv->rsp, 6);
expected = be32_to_cpup((__be32 *) &buf[2]);
-
if (expected > count)
return -EIO;
@@ -279,6 +316,8 @@ static const struct tpm_class_ops tpm_crb = {
.send = crb_send,
.cancel = crb_cancel,
.req_canceled = crb_req_canceled,
+ .request_locality = crb_request_locality,
+ .relinquish_locality = crb_relinquish_locality,
.req_complete_mask = CRB_DRV_STS_COMPLETE,
.req_complete_val = CRB_DRV_STS_COMPLETE,
};
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index da158f0..0ac6ea6 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -48,7 +48,8 @@ struct tpm_class_ops {
u8 (*status) (struct tpm_chip *chip);
bool (*update_timeouts)(struct tpm_chip *chip,
unsigned long *timeout_cap);
-
+ int (*request_locality)(struct tpm_chip *chip);
+ void (*relinquish_locality)(struct tpm_chip *chip);
};
#if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
--
2.9.3
Re: [RFC] Add option to mount only a pids subset
On Tue, Mar 07, 2017 at 08:24:12AM -0800, Andy Lutomirski wrote: > On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov > wrote: > > > > After discussion with Oleg Nesterov I reimplement my patch as an additional > > option for /proc. This option affects the mountpoint. It means that in one > > pid namespace it possible to have both the whole traditional /proc and > > /proc with only pids subset. > > > > I like this. I think you should split it into two patches, though: > one that reworks how procfs gets mounted and one that makes adds the > new functionality. Sure, but first I wanted to discuss the idea. My patch isn't very useful without the ability to add additional files. I will split it into parts in the new version. -- Rgrds, legion
Re: [PATCH 4.10 000/167] 4.10.2-stable review
On Fri, Mar 10, 2017 at 3:24 PM, Kevin Hilman wrote: > kernelci.org bot writes: > >> stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict >> (v4.10.1-168-gcdc1f9d24aac) >> >> Full Boot Summary: >> https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/ >> Full Build Summary: >> https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/ >> >> Tree: stable-rc >> Branch: local/linux-4.10.y >> Git Describe: v4.10.1-168-gcdc1f9d24aac >> Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb >> Git URL: >> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> Tested: 101 unique boards, 25 SoC families, 30 builds out of 204 >> >> Boot Regressions Detected: >> >> arm: >> >> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: >> am335x-pepper: >> lab-baylibre-seattle: new failure (last pass: >> v4.10-21-gd23a9821d397) > > This one is a new regression, and a first attempt at bisect was > inconclusive. Bisect fingered the commit below. I confirmed that reverting that commit on top of stable-rc/linux-4.10.y gets this am335x-pepper platform booting again. What's rather strange is that this boot test is using a .cpio.gz initramfs, and not using any ext4 filesystem. 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 is the first bad commit commit 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 Author: Theodore Ts'o Date: Sat Feb 4 23:04:00 2017 -0500 ext4: fix inline data error paths commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream. The write_end() function must always unlock the page and drop its ref count, even on an error. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman Kevin
