RE: [EXT] [PATCH net-next v2 1/4] net: ethernet: support of_get_mac_address new ERR_PTR error
From: Petr Štetiar Sent: Tuesday, May 7, 2019 5:25 AM
> There was NVMEM support added to of_get_mac_address, so it could now
> return ERR_PTR encoded error values, so we need to adjust all current users
> of of_get_mac_address to this new fact.
>
> While at it, remove superfluous is_valid_ether_addr as the MAC address
> returned from of_get_mac_address is always valid and checked by
> is_valid_ether_addr anyway.
>
> Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
> Signed-off-by: Petr Štetiar
Test the patch on i.MX8MQ platform that fix the mem abort issue that is
introduced in next-190507.
Tested-by: Fugang Duan
> ---
>
> This is defacto v5 of the previous 05/10 patch in the series, but since the
> v4 of this 05/10 patch wasn't picked up by the patchwork for some unknown
> reason, this patch wasn't applied with the other 9 patches in the series, so
> I'm resending it as a separate patch of this fixup series.
>
> Changes since v1:
>
> * added Fixes: tag
>
> Previous changelog (Patch 05/10):
>
> Changes since v3:
>
>* IS_ERR_OR_NULL -> IS_ERR
>
> Changes since v4:
>
>* I've just blindly replaced IS_ERR_OR_NULL with IS_ERR, but I've just
> realized, that in some cases we still need to check for NULL, so I've
> corrected it in following drivers/files:
>
> - broadcom/bgmac-bcma.c
> - marvell/pxa168_eth.c
> - samsung/sxgbe/sxgbe_platform.c
> - stmicro/stmmac/stmmac_main.c
> - wiznet/w5100.c
> - ethernet/eth.c
>
> drivers/net/ethernet/aeroflex/greth.c | 2 +-
> drivers/net/ethernet/allwinner/sun4i-emac.c | 2 +-
> drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
> drivers/net/ethernet/arc/emac_main.c | 2 +-
> drivers/net/ethernet/aurora/nb8800.c | 2 +-
> drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
> drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
> drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
> drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
> drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 2 +-
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
> drivers/net/ethernet/davicom/dm9000.c | 2 +-
> drivers/net/ethernet/ethoc.c | 2 +-
> drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
> drivers/net/ethernet/freescale/fec_main.c | 2 +-
> drivers/net/ethernet/freescale/fec_mpc52xx.c | 2 +-
> drivers/net/ethernet/freescale/fman/mac.c | 2 +-
> drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
> drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +-
> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
> drivers/net/ethernet/lantiq_xrx200.c | 2 +-
> drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
> drivers/net/ethernet/marvell/mvneta.c | 2 +-
> drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
> drivers/net/ethernet/marvell/sky2.c | 2 +-
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
> drivers/net/ethernet/micrel/ks8851.c | 2 +-
> drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
> drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
> drivers/net/ethernet/qualcomm/qca_spi.c | 2 +-
> drivers/net/ethernet/qualcomm/qca_uart.c | 2 +-
> drivers/net/ethernet/renesas/ravb_main.c | 2 +-
> drivers/net/ethernet/renesas/sh_eth.c | 2 +-
> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c | 2 +-
> drivers/net/ethernet/socionext/sni_ave.c | 2 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> drivers/net/ethernet/ti/cpsw.c| 2 +-
> drivers/net/ethernet/ti/netcp_core.c | 2 +-
> drivers/net/ethernet/wiznet/w5100.c | 2 +-
> drivers/net/ethernet/xilinx/ll_temac_main.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
> net/ethernet/eth.c| 2 +-
> 45 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/net/ethernet/aeroflex/greth.c
> b/drivers/net/ethernet/aeroflex/greth.c
> index 47e5984..7c5cf02 100644
> --- a/drivers/net/ethernet/aeroflex/greth.c
> +++ b/drivers/net/ethernet/aeroflex/greth.c
> @@ -1459,7 +1459,7 @@ static int greth_of_probe(struct platform_device
> *ofdev)
> const u8 *addr;
>
> addr = of_get_mac_address(ofdev->dev.of_node);
> - if (addr) {
> + if (!IS_ERR(addr)) {
> for (i = 0; i < 6; i++)
>
Re: [GIT PULL] Staging/IIO driver patches for 5.2-rc1
The pull request you sent on Tue, 7 May 2019 19:58:53 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > tags/staging-5.2-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e0dccbdf5ac7ccb9da5612100dedba302f3ebcfe Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] staging: iio: ad7150: use FIELD_GET and GENMASK
On 05/06, Ardelean, Alexandru wrote:
> On Sat, 2019-05-04 at 13:43 +0300, Alexandru Ardelean wrote:
> > [External]
> >
> >
> > On Sat, May 4, 2019 at 1:25 AM Melissa Wen wrote:
> > >
> > > Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask
> > > in
> > > one go. This makes the code more readable than explicit masking
> > > followed
> > > by a shift.
> > >
> >
> > This looks neat.
> > I'd have to remember to ack it from my work email.
>
> Acked-by: Alexandru Ardelean
>
> >
> > One minor comment inline, which would be the object of a new patch.
> >
> > > Signed-off-by: Melissa Wen
> > > ---
> > > drivers/staging/iio/cdc/ad7150.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/iio/cdc/ad7150.c
> > > b/drivers/staging/iio/cdc/ad7150.c
> > > index 24601ba7db88..4ba46fb6ac02 100644
> > > --- a/drivers/staging/iio/cdc/ad7150.c
> > > +++ b/drivers/staging/iio/cdc/ad7150.c
> > > @@ -5,6 +5,7 @@
> > > * Copyright 2010-2011 Analog Devices Inc.
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -44,6 +45,9 @@
> > > #define AD7150_SN0_REG 0x16
> > > #define AD7150_ID_REG 0x17
> > >
> > > +/* AD7150 masks */
> > > +#define AD7150_THRESHTYPE_MSK GENMASK(6, 5)
> > > +
> > > /**
> > > * struct ad7150_chip_info - instance specific chip data
> > > * @client: i2c client for this device
> > > @@ -136,7 +140,7 @@ static int ad7150_read_event_config(struct iio_dev
> > > *indio_dev,
> > > if (ret < 0)
> > > return ret;
> > >
> > > - threshtype = (ret >> 5) & 0x03;
> > > + threshtype = FIELD_GET(AD7150_THRESHTYPE_MSK, ret);
> > > adaptive = !!(ret & 0x80);
> >
> > Why not also do something similar for the `adaptive` value ?
Hi Alexandru,
Yes, I'm working on it! However, taking a look at the driver datasheet (Table
13, page 19), there seems to be a little mistake in choosing the variable name
and its meaning, since when bit(7) is 1 (true) the threshold is fixed, and not
adaptive. For this reason, I removed it from this patchset to mature the
solution. I will send it as a bug fix if I prove it's necessary.
Do you have any advice or feeling about it to share?
P.s.: Sorry for having previously sent an email with HTML.
Melissa
> >
> > >
> > > switch (type) {
> > > --
> > > 2.20.1
> > >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: iio: ad7150: improve driver readability
On 05/05, Jonathan Cameron wrote: > On Sat, 4 May 2019 14:12:22 +0300 > Alexandru Ardelean wrote: > > > On Sat, May 4, 2019 at 1:24 AM Melissa Wen wrote: > > > > > > This patchset solves readability issues in AD7150 code, such as clarify > > > register and mask definition, fashion improvement of mask uses, reduce > > > tedious operation and useless comments. > > > > > > > Hey, > > > > Two patches seem a bit noisy/un-needed. > > The other 2 are fine from me. > > > > This driver does need some work to move it out of staging. > > I am not sure what would be a big blocker for it, other than maybe it > > needs a device-tree binding doc (in YAML format). > > Maybe Jonathan remembers. > > > > Some other low-hanging-fruit ideas would be: > > 1) remove the code for platform_data ; that one seems forgotten from > > some other time; the interrupts should be coming from device-tree, > > from the i2c bindings > > 2) you could do a AD7150_EVENT_SPEC() macro (similar to > > AD7150_TIMEOUT() macro) and use it in the ad7150_events[] list; that > > would reduce a few lines > > 3) similar to 2), you could do a AD7150_CHANNEL(x) macro ; > > 4) in ad7150_event_handler() the checks could be wrapped into a macro, > > or maybe some function ; i am referring to "(int_status & > > AD7150_STATUS_OUT1) && (chip->old_state & AD7150_STATUS_OUT1)" checks > > ; those seem to be repeated > > 5) add of_match_table to the driver > > > > I (now) suspect that the reason this driver is still in staging is this > > comment: > > /* Timeouts not currently handled by core */ > > > > I wonder if things changed since then ? > > If not, it would be interesting to implement it in core. > Hmm. Timeouts are 'unusual' to put it lightly. > I'm thinking the ABI needs to perhaps be more specific but not sure what > a good naming is. > > Otherwise, I just took a quick look and can't see anything much else > that needs doing. Obviously something might come up in a thorough > review prior to moving it though! > > Jonathan > > > > Thanks > > Alex > > Hi Alexandru and Jonathan, Thank you for your help! Soon I will send a v2 with the fixes pointed out. I'm also including the ideas above in the work plan for this driver. P.s.: Sorry for having previously sent an email with HTML. Melissa > > > > > Melissa Wen (4): > > > staging: iio: ad7150: organize registers definition > > > staging: iio: ad7150: use FIELD_GET and GENMASK > > > staging: iio: ad7150: simplify i2c SMBus return treatment > > > staging: iio: ad7150: clean up of comments > > > > > > drivers/staging/iio/cdc/ad7150.c | 102 ++- > > > 1 file changed, 47 insertions(+), 55 deletions(-) > > > > > > -- > > > 2.20.1 > > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver patches for 5.2-rc1
On Tue, May 7, 2019 at 10:59 AM Greg KH wrote: > > All of these have been in linux-next for a while with no reported > issues, other than an odd gcc warning for one of the new drivers that > should be fixed up soon. Ok, that's truly a funky warning. But since I don't deal well with warnings, particularly during the merge window, I just fixed it up in the merge. The fix is to simply not have a bitfield base type of "unsigned char", and have it cross a char boundary. Instead the base type should just be "unsigned int". Of course, I couldn't test my change, but it shuts the compiler up, and it very much looks like the right thing. Linus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
From: Sultan Alsawaf Date: Tue, May 7, 2019 at 9:53 AM To: Suren Baghdasaryan Cc: Christian Brauner, Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione, Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim Murray, Michal Hocko, linux-mm, Arve Hjønnevåg, Ingo Molnar, Steven Rostedt, Oleg Nesterov, Joel Fernandes, Andy Lutomirski, kernel-team > On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote: > > Hi Sultan, > > Looks like you are posting this patch for devices that do not use > > userspace LMKD solution due to them using older kernels or due to > > their vendors sticking to in-kernel solution. If so, I see couple > > logistical issues with this patch. I don't see it being adopted in > > upstream kernel 5.x since it re-implements a deprecated mechanism even > > though vendors still use it. Vendors on the other hand, will not adopt > > it until you show evidence that it works way better than what > > lowmemorykilled driver does now. You would have to provide measurable > > data and explain your tests before they would consider spending time > > on this. > > Yes, this is mostly for the devices already produced that are forced to suffer > with poor memory management. I can't even convince vendors to fix kernel > memory leaks, so there's no way I'd be able to convince them of trying this > patch, especially since it seems like you're having trouble convincing vendors > to stop using lowmemorykiller in the first place. And thankfully, convincing > vendors isn't my job :) > > > On the implementation side I'm not convinced at all that this would > > work better on all devices and in all circumstances. We had cases when > > a new mechanism would show very good results until one usecase > > completely broke it. Bulk killing of processes that you are doing in > > your patch was a very good example of such a decision which later on > > we had to rethink. That's why baking these policies into kernel is > > very problematic. Another problem I see with the implementation that > > it ties process killing with the reclaim scan depth. It's very similar > > to how vmpressure works and vmpressure in my experience is very > > unpredictable. > > Could you elaborate a bit on why bulk killing isn't good? Yes. Several months ago we got reports that LMKD got very aggressive killing more processes in situations which did not require that many kills to recover from memory pressure. After investigation we tracked it to the bulk killing which would kill too many processes during a memory usage spike. When killing gradually the kills would be avoided, so we had to get back to a more balanced approach. The conceptual issue with bulk killing is that you can't cancel it when device recovers quicker than you expected. > > > > I linked in the previous message, Google made a rather large set of > > > > modifications to the supposedly-defunct lowmemorykiller.c not one month > > > > ago. > > > > What's going on? > > > > If you look into that commit, it adds ability to report kill stats. If > > that was a change in how that driver works it would be rejected. > > Fair, though it was quite strange seeing something that was supposedly totally > abandoned receiving a large chunk of code for reporting stats. > > Thanks, > Sultan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes
From: Petr Štetiar Date: Mon, 6 May 2019 23:24:43 +0200 > this patch series is an attempt to fix the mess, I've somehow managed to > introduce. > > First patch in this series is defacto v5 of the previous 05/10 patch in the > series, but since the v4 of this 05/10 patch wasn't picked up by the > patchwork for some unknown reason, this patch wasn't applied with the other > 9 patches in the series, so I'm resending it as a separate patch of this > fixup series again. > > Second patch is a result of this rebase against net-next tree, where I was > checking again all current users of of_get_mac_address and found out, that > there's new one in DSA, so I've converted this user to the new ERR_PTR > encoded error value as well. > > Third patch which was sent as v5 wasn't considered for merge, but I still > think, that we need to check for possible NULL value, thus current IS_ERR > check isn't sufficient and we need to use IS_ERR_OR_NULL instead. > > Fourth patch fixes warning reported by kbuild test robot. Series applied, thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote: > From: Christian Brauner > Date: Tue, May 7, 2019 at 3:58 AM > To: Sultan Alsawaf > Cc: Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione, > Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim > Murray, Michal Hocko, Suren Baghdasaryan, linux-mm, Arve Hjønnevåg, > Ingo Molnar, Steven Rostedt, Oleg Nesterov, Joel Fernandes, Andy > Lutomirski, kernel-team > > > On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote: > > > On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > > > > Given that any "new" android device that gets shipped "soon" should be > > > > using 4.9.y or newer, is this a real issue? > > > > > > It's certainly a real issue for those who can't buy brand new Android > > > devices > > > without software bugs every six months :) > > > > > Hi Sultan, > Looks like you are posting this patch for devices that do not use > userspace LMKD solution due to them using older kernels or due to > their vendors sticking to in-kernel solution. If so, I see couple > logistical issues with this patch. I don't see it being adopted in > upstream kernel 5.x since it re-implements a deprecated mechanism even > though vendors still use it. Vendors on the other hand, will not adopt > it until you show evidence that it works way better than what > lowmemorykilled driver does now. You would have to provide measurable > data and explain your tests before they would consider spending time > on this. > On the implementation side I'm not convinced at all that this would > work better on all devices and in all circumstances. We had cases when > a new mechanism would show very good results until one usecase > completely broke it. Bulk killing of processes that you are doing in > your patch was a very good example of such a decision which later on > we had to rethink. That's why baking these policies into kernel is > very problematic. Another problem I see with the implementation that > it ties process killing with the reclaim scan depth. It's very similar > to how vmpressure works and vmpressure in my experience is very > unpredictable. Yeah it does seem conceptually similar, good point. > > > Regardless, even if PSI were backported, a full-fledged LMKD using it has > > > yet to > > > be made, so it wouldn't be of much use now. > > > > This is work that is ongoing and requires kernel changes to make it > > feasible. One of the things that I have been working on for quite a > > while is the whole file descriptor for processes thing that is important > > for LMKD (Even though I never thought about this use-case when I started > > pitching this.). Joel and Daniel have joined in and are working on > > making LMKD possible. > > What I find odd is that every couple of weeks different solutions to the > > low memory problem are pitched. There is simple_lkml, there is LMKD, and > > there was a patchset that wanted to speed up memory reclaim at process > > kill-time by adding a new flag to the new pidfd_send_signal() syscall. > > That all seems - though related - rather uncoordinated. > > I'm not sure why pidfd_wait and expedited reclaim is seen as > uncoordinated effort. All of them are done to improve userspace LMKD. Christian, pidfd_wait and expedited reclaim are both coordinated efforts and solve different problems related to LMK. simple_lmk is entirely different effort that we already hesitated about when it was first posted, now we hesitate again due to the issues Suren and others mentioned. I think it is a better idea for Sultan to spend his time on using/improving PSI/LMKd than spending it on the simple_lmk. It could also be a good topic to discuss in the Android track of the Linux plumbers conference. thanks, - Joel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver patches for 5.2-rc1
The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.2-rc1
for you to fetch changes up to e2a5be107f52cefb9010ccae6f569c3ddaa954cc:
staging: kpc2000: kpc_spi: Fix build error for {read,write}q (2019-05-03
08:23:20 +0200)
Staging / IIO driver patches for 5.2-rc1
Here is the big staging and iio driver update for 5.2-rc1.
Lots of tiny fixes all over the staging and IIO driver trees here, along
with some new IIO drivers.
Also we ended up deleting two drivers, making this pull request remove a
few hundred thousand lines of code, always a nice thing to see. Both of
the drivers removed have been replaced with "real" drivers in their
various subsystem directories, and they will be coming to you from those
locations during this merge window.
There are some core vt/selection changes in here, that was due to some
cleanups needed for the speakup fixes. Those have all been acked by the
various subsystem maintainers (i.e. me), so those are ok.
We also added a few new drivers, for some odd hardware, giving new
developers plenty to work on with basic coding style cleanups to come in
the near future.
Other than that, nothing unusual here.
All of these have been in linux-next for a while with no reported
issues, other than an odd gcc warning for one of the new drivers that
should be fixed up soon.
Signed-off-by: Greg Kroah-Hartman
Aaro Koskinen (2):
staging: refer to TODO in Kconfig help text
staging: octeon-ethernet: add TODO
Adham Abozaeid (3):
staging: wilc1000: use cfg80211 ssid list instead of repacking it
staging: wilc1000: assign scan result callback before starting the scan
staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context
Alejandro Ismael Silva (1):
staging: vc04_services: Use tabs instead of spaces
Alexandru Ardelean (5):
iio: imu: adis16400: move trigger handler into adis16400_core
iio: imu: adis: generalize burst mode support
iio: imu: adis16400: move burst logic to ADIS lib
iio: imu: adis16400: rename adis16400_core.c -> adi16400.c
iio: imu: adis16400: move adis16400.h into adis16400.c
Anderson Reis (3):
iio:potentiostat:lmp91000: reduce line width and remove blank line
iio:potentiostat:lmp91000: invert if statement
iio:potentiostat:lmp91000: change dev_err message
Andreas Klinger (10):
dt-bindings: Add vendor prefix for MaxBotix
dt-bindings: maxbotix,mb1232: Add MaxBotix i2c ultrasonic rangers
mb1232.c: add distance iio sensor with i2c
MAINTAINERS: add maintainer for maxbotix ultrasonic driver
devantech-srf04.yaml: transform DT binding to YAML
avia-hx711.yaml: transform DT binding to YAML
bmp085.yaml: transform DT documentation of iio sensor into YAML
srf04.c: add maxbotix ultrasonic sensors
dt-bindings: iio: srf04: add Maxbotix ultrasonic iio proximity sensors
Kconfig: change configuration of srf04 ultrasonic iio sensor
Andrey Smirnov (6):
iio: imx7d_adc: Add local struct device pointer in imx7d_adc_probe()
iio: imx7d_adc: Replace pr_err with dev_err
iio: imx7d_adc: Use devm_platform_ioremap_resource()
iio: imx7d_adc: Simplify imx7d_adc_probe() with imx7d_adc_resume()
iio: imx7d_adc: Simplify imx7d_adc_remove() with imx7d_adc_suspend()
iio: imx7d_adc: Use devm_iio_device_register()
Andy Shevchenko (3):
iio: Allow to read mount matrix from ACPI
iio: buffer: Switch to bitmap_zalloc()
iio: Make possible to include driver.h first
Angus Ainslie (Purism) (5):
iio: light: vcnl4000 use word writes instead of byte writes
iio: light: vcnl4000 add devicetree hooks
dt-bindings: iio: light: add vcnl4000 devicetree bindings
iio: light: vcnl4000 add support for the VCNL4040 proximity and light
sensor
dt-bindings: iio: light: add vcnl4040 devicetree bindings
Anirudh Rayabharam (1):
staging: rtl8723bs: core: fix line over 80 characters warning
Antti Keränen (1):
staging: mt7621-pci-phy: prevent use of uninitialized variable
Anushka Shukla (1):
staging: rtl8192e: kconfig: use help over --help--
Arash Fotouhi (1):
Staging: comedi: ni_mio_common.c: Added blank line after declarations
Armando Miraglia (1):
staging: mediatek: addres minor style issues flagged by clang-format.
Bartlomiej Zolnierkiewicz (1):
staging: remove redundant 'default n' from Kconfig
Beatriz Martins de Carvalho (1):
staging: rtl8723bs: hal: replace spaces by tabs.
Beniamin Bia (2):
iio: adc: ad7616: Add support for AD7616 ADC
dt-bindings: iio: adc: Add AD7616 ADC documentation
Benjamin Gaignard (2):
Re: [GIT PULL] Staging/IIO driver patches for 5.2-rc1
On Tue, May 07, 2019 at 07:58:53PM +0200, Greg KH wrote:
> The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
>
> Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> tags/staging-5.2-rc1
>
> for you to fetch changes up to e2a5be107f52cefb9010ccae6f569c3ddaa954cc:
>
> staging: kpc2000: kpc_spi: Fix build error for {read,write}q (2019-05-03
> 08:23:20 +0200)
>
>
> Staging / IIO driver patches for 5.2-rc1
>
> Here is the big staging and iio driver update for 5.2-rc1.
>
> Lots of tiny fixes all over the staging and IIO driver trees here, along
> with some new IIO drivers.
>
> Also we ended up deleting two drivers, making this pull request remove a
> few hundred thousand lines of code, always a nice thing to see. Both of
> the drivers removed have been replaced with "real" drivers in their
> various subsystem directories, and they will be coming to you from those
> locations during this merge window.
>
> There are some core vt/selection changes in here, that was due to some
> cleanups needed for the speakup fixes. Those have all been acked by the
> various subsystem maintainers (i.e. me), so those are ok.
>
> We also added a few new drivers, for some odd hardware, giving new
> developers plenty to work on with basic coding style cleanups to come in
> the near future.
>
> Other than that, nothing unusual here.
>
> All of these have been in linux-next for a while with no reported
> issues, other than an odd gcc warning for one of the new drivers that
> should be fixed up soon.
>
> Signed-off-by: Greg Kroah-Hartman
I forgot to mention that the "counter" subsystem was added in here as
well, as it is needed by the IIO drivers and subsystem. It's reflected
in the shortlog and diffstat, but I forgot to cover it in the text
above, sorry.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 10:17:11AM -0700, Sultan Alsawaf wrote: > On Tue, May 07, 2019 at 01:09:21PM +0200, Greg Kroah-Hartman wrote: > > > It's even more odd that although a userspace solution is touted as the > > > proper > > > way to go on LKML, almost no Android OEMs are using it, and even in that > > > commit > > > I linked in the previous message, Google made a rather large set of > > > modifications to the supposedly-defunct lowmemorykiller.c not one month > > > ago. > > > What's going on? > > > > "almost no"? Again, Android Go is doing that, right? > > I'd check for myself, but I can't seem to find kernel source for an Android Go > device... > > This seems more confusing though. Why would the ultra-low-end devices use LMKD > while other devices use the broken lowmemorykiller driver? It's probably because the Android Go devices got a lot more "help" from people at Google than did the other devices you are looking at. Also, despite the older kernel version, they are probably running a newer version of Android userspace, specially tuned just for lower memory devices. So those 3.18.y based Android Go devices are newer than the 4.4.y based "full Android" devices on the market, and even some 4.9.y based devices. Yes, it is strange :) > > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. > > > > Qualcomm should never be used as an example of a company that has any > > idea of what to do in their kernel :) > > Agreed, but nearly all OEMs that use Qualcomm chipsets roll with Qualcomm's > kernel decisions, so Qualcomm has a bit of influence here. Yes, because almost no OEM wants to mess with their kernel, they just take QCOM's kernel and run with it. But don't take that for some sort of "best design practice" summary at all. > > > If PSI were backported to 4.4, or even 3.18, would it really be used? > > > > Why wouldn't it, if it worked properly? > > For the same mysterious reason that Qualcomm and others cling to > lowmemorykiller, I presume. This is part of what's been confusing me for quite > some time... QCOM's 4.4.y based kernel work was done 3-4 years ago, if not older. They didn't know that this was not the "right way" to do things. The Google developers have been working for the past few years to do it correct, but they can not go back in time to change old repos, sorry. Now that I understand you just want to work on your local device, that makes more sense. But I think you will have a better result trying to do a 4.4 backport of PSI combined with the userspace stuff, than to try to worry about your driver in 5.2 or newer. Or you can forward-port your kernel to 4.9, or better yet, 4.14. That would probably be a much better thing to do overall as 4.4 is really old now. Good luck! greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 12:58:27PM +0200, Christian Brauner wrote: > This is work that is ongoing and requires kernel changes to make it > feasible. One of the things that I have been working on for quite a > while is the whole file descriptor for processes thing that is important > for LMKD (Even though I never thought about this use-case when I started > pitching this.). Joel and Daniel have joined in and are working on > making LMKD possible. > What I find odd is that every couple of weeks different solutions to the > low memory problem are pitched. There is simple_lkml, there is LMKD, and > there was a patchset that wanted to speed up memory reclaim at process > kill-time by adding a new flag to the new pidfd_send_signal() syscall. > That all seems - though related - rather uncoordinated. Now granted, > coordinated is usually not how kernel development necessarily works but > it would probably be good to have some sort of direction and from what I > have seen LMKD seems to be the most coordinated effort. But that might > just be my impression. LMKD is just Android's userspace low-memory-killer daemon. It's been around for a while. This patch (simple_lmk) is meant to serve as an immediate solution for the devices that'll never see a single line of PSI code running on them, which amounts to... well, most Android devices currently in existence. I'm more of a cowboy who made this patch after waiting a few years for memory management improvements on Android that never happened. Though it looks like it's going to happen soon(ish?) for super new devices that'll have the privilege of shipping with PSI in use. On Tue, May 07, 2019 at 01:09:21PM +0200, Greg Kroah-Hartman wrote: > > It's even more odd that although a userspace solution is touted as the > > proper > > way to go on LKML, almost no Android OEMs are using it, and even in that > > commit > > I linked in the previous message, Google made a rather large set of > > modifications to the supposedly-defunct lowmemorykiller.c not one month ago. > > What's going on? > > "almost no"? Again, Android Go is doing that, right? I'd check for myself, but I can't seem to find kernel source for an Android Go device... This seems more confusing though. Why would the ultra-low-end devices use LMKD while other devices use the broken lowmemorykiller driver? > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. > > Qualcomm should never be used as an example of a company that has any > idea of what to do in their kernel :) Agreed, but nearly all OEMs that use Qualcomm chipsets roll with Qualcomm's kernel decisions, so Qualcomm has a bit of influence here. > > If PSI were backported to 4.4, or even 3.18, would it really be used? > > Why wouldn't it, if it worked properly? For the same mysterious reason that Qualcomm and others cling to lowmemorykiller, I presume. This is part of what's been confusing me for quite some time... > Please see the work that went into PSI and the patches around it. > There's also a lwn.net article last week about the further work ongoing > in this area. With all of that, you should see how in-kernel memory > killers are NOT the way to go. > > > Regardless, even if PSI were backported, a full-fledged LMKD using it has > > yet to > > be made, so it wouldn't be of much use now. > > "LMKD"? Again, PSI is in the 4.9.y android-common tree, so the > userspace side should be in AOSP, right? LMKD as in Android's low-memory-killer daemon. It is in AOSP, but it looks like it's still a work in progress. Thanks, Sultan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote: > Hi Sultan, > Looks like you are posting this patch for devices that do not use > userspace LMKD solution due to them using older kernels or due to > their vendors sticking to in-kernel solution. If so, I see couple > logistical issues with this patch. I don't see it being adopted in > upstream kernel 5.x since it re-implements a deprecated mechanism even > though vendors still use it. Vendors on the other hand, will not adopt > it until you show evidence that it works way better than what > lowmemorykilled driver does now. You would have to provide measurable > data and explain your tests before they would consider spending time > on this. Yes, this is mostly for the devices already produced that are forced to suffer with poor memory management. I can't even convince vendors to fix kernel memory leaks, so there's no way I'd be able to convince them of trying this patch, especially since it seems like you're having trouble convincing vendors to stop using lowmemorykiller in the first place. And thankfully, convincing vendors isn't my job :) > On the implementation side I'm not convinced at all that this would > work better on all devices and in all circumstances. We had cases when > a new mechanism would show very good results until one usecase > completely broke it. Bulk killing of processes that you are doing in > your patch was a very good example of such a decision which later on > we had to rethink. That's why baking these policies into kernel is > very problematic. Another problem I see with the implementation that > it ties process killing with the reclaim scan depth. It's very similar > to how vmpressure works and vmpressure in my experience is very > unpredictable. Could you elaborate a bit on why bulk killing isn't good? > > > I linked in the previous message, Google made a rather large set of > > > modifications to the supposedly-defunct lowmemorykiller.c not one month > > > ago. > > > What's going on? > > If you look into that commit, it adds ability to report kill stats. If > that was a change in how that driver works it would be rejected. Fair, though it was quite strange seeing something that was supposedly totally abandoned receiving a large chunk of code for reporting stats. Thanks, Sultan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote: > From: Christian Brauner > Date: Tue, May 7, 2019 at 3:58 AM > To: Sultan Alsawaf > Cc: Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione, > Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim > Murray, Michal Hocko, Suren Baghdasaryan, linux-mm, Arve Hjønnevåg, > Ingo Molnar, Steven Rostedt, Oleg Nesterov, Joel Fernandes, Andy > Lutomirski, kernel-team > > > On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote: > > > On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > > > > Given that any "new" android device that gets shipped "soon" should be > > > > using 4.9.y or newer, is this a real issue? > > > > > > It's certainly a real issue for those who can't buy brand new Android > > > devices > > > without software bugs every six months :) > > > > > Hi Sultan, > Looks like you are posting this patch for devices that do not use > userspace LMKD solution due to them using older kernels or due to > their vendors sticking to in-kernel solution. If so, I see couple > logistical issues with this patch. I don't see it being adopted in > upstream kernel 5.x since it re-implements a deprecated mechanism even > though vendors still use it. Vendors on the other hand, will not adopt > it until you show evidence that it works way better than what > lowmemorykilled driver does now. You would have to provide measurable > data and explain your tests before they would consider spending time > on this. > On the implementation side I'm not convinced at all that this would > work better on all devices and in all circumstances. We had cases when > a new mechanism would show very good results until one usecase > completely broke it. Bulk killing of processes that you are doing in > your patch was a very good example of such a decision which later on > we had to rethink. That's why baking these policies into kernel is > very problematic. Another problem I see with the implementation that > it ties process killing with the reclaim scan depth. It's very similar > to how vmpressure works and vmpressure in my experience is very > unpredictable. > > > > > And if it is, I'm sure that asking for those patches to be backported to > > > > 4.4.y would be just fine, have you asked? > > > > > > > > Note that I know of Android Go devices, running 3.18.y kernels, do NOT > > > > use the in-kernel memory killer, but instead use the userspace solution > > > > today. So trying to get another in-kernel memory killer solution added > > > > anywhere seems quite odd. > > > > > > It's even more odd that although a userspace solution is touted as the > > > proper > > > way to go on LKML, almost no Android OEMs are using it, and even in that > > > commit > > > > That's probably because without proper kernel changes this is rather > > tricky to use safely (see below). > > > > > I linked in the previous message, Google made a rather large set of > > > modifications to the supposedly-defunct lowmemorykiller.c not one month > > > ago. > > > What's going on? > > If you look into that commit, it adds ability to report kill stats. If > that was a change in how that driver works it would be rejected. > > > > > > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. If PSI > > > were > > > backported to 4.4, or even 3.18, would it really be used? I don't really > > > understand the aversion to an in-kernel memory killer on LKML despite the > > > rest > > > of the industry's attraction to it. Perhaps there's some inherently great > > > cost > > > in using the userspace solution that I'm unaware of? > > Vendors are cautious about adopting userspace solution and it is a > process to address all concerns but we are getting there. > > > > Regardless, even if PSI were backported, a full-fledged LMKD using it has > > > yet to > > > be made, so it wouldn't be of much use now. > > > > This is work that is ongoing and requires kernel changes to make it > > feasible. One of the things that I have been working on for quite a > > while is the whole file descriptor for processes thing that is important > > for LMKD (Even though I never thought about this use-case when I started > > pitching this.). Joel and Daniel have joined in and are working on > > making LMKD possible. > > What I find odd is that every couple of weeks different solutions to the > > low memory problem are pitched. There is simple_lkml, there is LMKD, and > > there was a patchset that wanted to speed up memory reclaim at process > > kill-time by adding a new flag to the new pidfd_send_signal() syscall. > > That all seems - though related - rather uncoordinated. > > I'm not sure why pidfd_wait and expedited reclaim is seen as > uncoordinated effort. All of them are done to improve userspace LMKD. If so that wasn't very obvious and there was some disagreement there as well whether this would be the right solution. In any case, the point is that LMKD seems to
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 05:31:54PM +0200, Oleg Nesterov wrote:
> I am not going to comment the intent, but to be honest I am skeptical too.
The general sentiment has been that this is a really bad idea, but I'm just a
frustrated Android user who wants his phone to not require mountains of zRAM
only to still manage memory poorly. Until I can go out and buy a non-Pixel phone
that uses PSI to make these decisions (and does a good job of it), I'm going to
stick to my hacky little driver for my personal devices. Many others who like to
hack their Android devices to make them last longer will probably find value in
this as well, since there are millions of people who use devices that'll never
seen any of PSI ported to their ancient 3.x kernels.
And yes, I know this would never be accepted to upstream in a million years. I
mostly wanted some code review and guidance, since mm code is pretty tricky :)
> On 05/06, Sultan Alsawaf wrote:
> >
> > +static unsigned long find_victims(struct victim_info *varr, int *vindex,
> > + int vmaxlen, int min_adj, int max_adj)
> > +{
> > + unsigned long pages_found = 0;
> > + int old_vindex = *vindex;
> > + struct task_struct *tsk;
> > +
> > + for_each_process(tsk) {
> > + struct task_struct *vtsk;
> > + unsigned long tasksize;
> > + short oom_score_adj;
> > +
> > + /* Make sure there's space left in the victim array */
> > + if (*vindex == vmaxlen)
> > + break;
> > +
> > + /* Don't kill current, kthreads, init, or duplicates */
> > + if (same_thread_group(tsk, current) ||
> > + tsk->flags & PF_KTHREAD ||
> > + is_global_init(tsk) ||
> > + vtsk_is_duplicate(varr, *vindex, tsk))
> > + continue;
> > +
> > + vtsk = find_lock_task_mm(tsk);
>
> Did you test this patch with lockdep enabled?
>
> If I read the patch correctly, lockdep should complain. vtsk_is_duplicate()
> ensures that we do not take the same ->alloc_lock twice or more, but lockdep
> can't know this.
Yeah, lockdep is fine with this, at least on 4.4.
> > +static void scan_and_kill(unsigned long pages_needed)
> > +{
> > + static DECLARE_WAIT_QUEUE_HEAD(victim_waitq);
> > + struct victim_info victims[MAX_VICTIMS];
> > + int i, nr_to_kill = 0, nr_victims = 0;
> > + unsigned long pages_found = 0;
> > + atomic_t victim_count;
> > +
> > + /*
> > +* Hold the tasklist lock so tasks don't disappear while scanning. This
> > +* is preferred to holding an RCU read lock so that the list of tasks
> > +* is guaranteed to be up to date. Keep preemption disabled until the
> > +* SIGKILLs are sent so the victim kill process isn't interrupted.
> > +*/
> > + read_lock(_lock);
> > + preempt_disable();
>
> read_lock() disables preemption, every task_lock() too, so this looks
> unnecessary.
Good point.
> > + for (i = 1; i < ARRAY_SIZE(adj_prio); i++) {
> > + pages_found += find_victims(victims, _victims, MAX_VICTIMS,
> > + adj_prio[i], adj_prio[i - 1]);
> > + if (pages_found >= pages_needed || nr_victims == MAX_VICTIMS)
> > + break;
> > + }
> > +
> > + /*
> > +* Calculate the number of tasks that need to be killed and quickly
> > +* release the references to those that'll live.
> > +*/
> > + for (i = 0, pages_found = 0; i < nr_victims; i++) {
> > + struct victim_info *victim = [i];
> > + struct task_struct *vtsk = victim->tsk;
> > +
> > + /* The victims' mm lock is taken in find_victims; release it */
> > + if (pages_found >= pages_needed) {
> > + task_unlock(vtsk);
> > + continue;
> > + }
> > +
> > + /*
> > +* Grab a reference to the victim so it doesn't disappear after
> > +* the tasklist lock is released.
> > +*/
> > + get_task_struct(vtsk);
>
> The comment doesn't look correct. the victim can't dissapear until
> task_unlock()
> below, it can't pass exit_mm().
I was always unsure about this and decided to hold a reference to the
task_struct to be safe. Thanks for clearing that up.
> > + pages_found += victim->size;
> > + nr_to_kill++;
> > + }
> > + read_unlock(_lock);
> > +
> > + /* Kill the victims */
> > + victim_count = (atomic_t)ATOMIC_INIT(nr_to_kill);
> > + for (i = 0; i < nr_to_kill; i++) {
> > + struct victim_info *victim = [i];
> > + struct task_struct *vtsk = victim->tsk;
> > +
> > + pr_info("Killing %s with adj %d to free %lu kiB\n", vtsk->comm,
> > + vtsk->signal->oom_score_adj,
> > + victim->size << (PAGE_SHIFT - 10));
> > +
> > + /* Configure the victim's mm to notify us when it's freed */
> > + vtsk->mm->slmk_waitq = _waitq;
> > +
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
From: Christian Brauner Date: Tue, May 7, 2019 at 3:58 AM To: Sultan Alsawaf Cc: Greg Kroah-Hartman, open list:ANDROID DRIVERS, Daniel Colascione, Todd Kjos, Kees Cook, Peter Zijlstra, Martijn Coenen, LKML, Tim Murray, Michal Hocko, Suren Baghdasaryan, linux-mm, Arve Hjønnevåg, Ingo Molnar, Steven Rostedt, Oleg Nesterov, Joel Fernandes, Andy Lutomirski, kernel-team > On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote: > > On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > > > Given that any "new" android device that gets shipped "soon" should be > > > using 4.9.y or newer, is this a real issue? > > > > It's certainly a real issue for those who can't buy brand new Android > > devices > > without software bugs every six months :) > > Hi Sultan, Looks like you are posting this patch for devices that do not use userspace LMKD solution due to them using older kernels or due to their vendors sticking to in-kernel solution. If so, I see couple logistical issues with this patch. I don't see it being adopted in upstream kernel 5.x since it re-implements a deprecated mechanism even though vendors still use it. Vendors on the other hand, will not adopt it until you show evidence that it works way better than what lowmemorykilled driver does now. You would have to provide measurable data and explain your tests before they would consider spending time on this. On the implementation side I'm not convinced at all that this would work better on all devices and in all circumstances. We had cases when a new mechanism would show very good results until one usecase completely broke it. Bulk killing of processes that you are doing in your patch was a very good example of such a decision which later on we had to rethink. That's why baking these policies into kernel is very problematic. Another problem I see with the implementation that it ties process killing with the reclaim scan depth. It's very similar to how vmpressure works and vmpressure in my experience is very unpredictable. > > > And if it is, I'm sure that asking for those patches to be backported to > > > 4.4.y would be just fine, have you asked? > > > > > > Note that I know of Android Go devices, running 3.18.y kernels, do NOT > > > use the in-kernel memory killer, but instead use the userspace solution > > > today. So trying to get another in-kernel memory killer solution added > > > anywhere seems quite odd. > > > > It's even more odd that although a userspace solution is touted as the > > proper > > way to go on LKML, almost no Android OEMs are using it, and even in that > > commit > > That's probably because without proper kernel changes this is rather > tricky to use safely (see below). > > > I linked in the previous message, Google made a rather large set of > > modifications to the supposedly-defunct lowmemorykiller.c not one month ago. > > What's going on? If you look into that commit, it adds ability to report kill stats. If that was a change in how that driver works it would be rejected. > > > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. If PSI were > > backported to 4.4, or even 3.18, would it really be used? I don't really > > understand the aversion to an in-kernel memory killer on LKML despite the > > rest > > of the industry's attraction to it. Perhaps there's some inherently great > > cost > > in using the userspace solution that I'm unaware of? Vendors are cautious about adopting userspace solution and it is a process to address all concerns but we are getting there. > > Regardless, even if PSI were backported, a full-fledged LMKD using it has > > yet to > > be made, so it wouldn't be of much use now. > > This is work that is ongoing and requires kernel changes to make it > feasible. One of the things that I have been working on for quite a > while is the whole file descriptor for processes thing that is important > for LMKD (Even though I never thought about this use-case when I started > pitching this.). Joel and Daniel have joined in and are working on > making LMKD possible. > What I find odd is that every couple of weeks different solutions to the > low memory problem are pitched. There is simple_lkml, there is LMKD, and > there was a patchset that wanted to speed up memory reclaim at process > kill-time by adding a new flag to the new pidfd_send_signal() syscall. > That all seems - though related - rather uncoordinated. I'm not sure why pidfd_wait and expedited reclaim is seen as uncoordinated effort. All of them are done to improve userspace LMKD. > Now granted, > coordinated is usually not how kernel development necessarily works but > it would probably be good to have some sort of direction and from what I > have seen LMKD seems to be the most coordinated effort. But that might > just be my impression. > > Christian Thanks, Suren. ___ devel mailing list de...@linuxdriverproject.org
[PATCH] Staging: rtl8723bs: os_dep: Remove braces from single if statement
Remove braces from single if statement to solve style issue found using
checkpatch,pl
Signed-off-by: Puranjay Mohan
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 052482554f74..96e989d1d53d 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -489,9 +489,8 @@ static int rtw_drv_init(
/* dev_alloc_name && register_netdev */
status = rtw_drv_register_netdev(if1);
- if (status != _SUCCESS) {
+ if (status != _SUCCESS)
goto free_if2;
- }
if (sdio_alloc_irq(dvobj) != _SUCCESS)
goto free_if2;
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
I am not going to comment the intent, but to be honest I am skeptical too.
On 05/06, Sultan Alsawaf wrote:
>
> +static unsigned long find_victims(struct victim_info *varr, int *vindex,
> + int vmaxlen, int min_adj, int max_adj)
> +{
> + unsigned long pages_found = 0;
> + int old_vindex = *vindex;
> + struct task_struct *tsk;
> +
> + for_each_process(tsk) {
> + struct task_struct *vtsk;
> + unsigned long tasksize;
> + short oom_score_adj;
> +
> + /* Make sure there's space left in the victim array */
> + if (*vindex == vmaxlen)
> + break;
> +
> + /* Don't kill current, kthreads, init, or duplicates */
> + if (same_thread_group(tsk, current) ||
> + tsk->flags & PF_KTHREAD ||
> + is_global_init(tsk) ||
> + vtsk_is_duplicate(varr, *vindex, tsk))
> + continue;
> +
> + vtsk = find_lock_task_mm(tsk);
Did you test this patch with lockdep enabled?
If I read the patch correctly, lockdep should complain. vtsk_is_duplicate()
ensures that we do not take the same ->alloc_lock twice or more, but lockdep
can't know this.
> +static void scan_and_kill(unsigned long pages_needed)
> +{
> + static DECLARE_WAIT_QUEUE_HEAD(victim_waitq);
> + struct victim_info victims[MAX_VICTIMS];
> + int i, nr_to_kill = 0, nr_victims = 0;
> + unsigned long pages_found = 0;
> + atomic_t victim_count;
> +
> + /*
> + * Hold the tasklist lock so tasks don't disappear while scanning. This
> + * is preferred to holding an RCU read lock so that the list of tasks
> + * is guaranteed to be up to date. Keep preemption disabled until the
> + * SIGKILLs are sent so the victim kill process isn't interrupted.
> + */
> + read_lock(_lock);
> + preempt_disable();
read_lock() disables preemption, every task_lock() too, so this looks
unnecessary.
> + for (i = 1; i < ARRAY_SIZE(adj_prio); i++) {
> + pages_found += find_victims(victims, _victims, MAX_VICTIMS,
> + adj_prio[i], adj_prio[i - 1]);
> + if (pages_found >= pages_needed || nr_victims == MAX_VICTIMS)
> + break;
> + }
> +
> + /*
> + * Calculate the number of tasks that need to be killed and quickly
> + * release the references to those that'll live.
> + */
> + for (i = 0, pages_found = 0; i < nr_victims; i++) {
> + struct victim_info *victim = [i];
> + struct task_struct *vtsk = victim->tsk;
> +
> + /* The victims' mm lock is taken in find_victims; release it */
> + if (pages_found >= pages_needed) {
> + task_unlock(vtsk);
> + continue;
> + }
> +
> + /*
> + * Grab a reference to the victim so it doesn't disappear after
> + * the tasklist lock is released.
> + */
> + get_task_struct(vtsk);
The comment doesn't look correct. the victim can't dissapear until task_unlock()
below, it can't pass exit_mm().
> + pages_found += victim->size;
> + nr_to_kill++;
> + }
> + read_unlock(_lock);
> +
> + /* Kill the victims */
> + victim_count = (atomic_t)ATOMIC_INIT(nr_to_kill);
> + for (i = 0; i < nr_to_kill; i++) {
> + struct victim_info *victim = [i];
> + struct task_struct *vtsk = victim->tsk;
> +
> + pr_info("Killing %s with adj %d to free %lu kiB\n", vtsk->comm,
> + vtsk->signal->oom_score_adj,
> + victim->size << (PAGE_SHIFT - 10));
> +
> + /* Configure the victim's mm to notify us when it's freed */
> + vtsk->mm->slmk_waitq = _waitq;
> + vtsk->mm->slmk_counter = _count;
> +
> + /* Accelerate the victim's death by forcing the kill signal */
> + do_send_sig_info(SIGKILL, SIG_INFO_TYPE, vtsk, true);
this should be PIDTYPE_TGID
> +
> + /* Finally release the victim's mm lock */
> + task_unlock(vtsk);
> + }
> + preempt_enable_no_resched();
See above. And I don't understand how can _no_resched() really help...
> +
> + /* Try to speed up the death process now that we can schedule again */
> + for (i = 0; i < nr_to_kill; i++) {
> + struct task_struct *vtsk = victims[i].tsk;
> +
> + /* Increase the victim's priority to make it die faster */
> + set_user_nice(vtsk, MIN_NICE);
> +
> + /* Allow the victim to run on any CPU */
> + set_cpus_allowed_ptr(vtsk, cpu_all_mask);
> +
> + /* Finally release the victim reference acquired earlier */
> + put_task_struct(vtsk);
> + }
> +
> + /* Wait
Re: [PATCH net-next v2 2/4] net: dsa: support of_get_mac_address new ERR_PTR error
On Tue, 7 May 2019 at 00:26, Petr Štetiar wrote:
>
> There was NVMEM support added to of_get_mac_address, so it could now
> return ERR_PTR encoded error values, so we need to adjust all current
> users of of_get_mac_address to this new fact.
>
> While at it, remove superfluous is_valid_ether_addr as the MAC address
> returned from of_get_mac_address is always valid and checked by
> is_valid_ether_addr anyway.
>
> Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
> Signed-off-by: Petr Štetiar
> ---
> net/dsa/slave.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 316bce9..fe7b6a6 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1418,7 +1418,7 @@ int dsa_slave_create(struct dsa_port *port)
> NETIF_F_HW_VLAN_CTAG_FILTER;
> slave_dev->hw_features |= NETIF_F_HW_TC;
> slave_dev->ethtool_ops = _slave_ethtool_ops;
> - if (port->mac && is_valid_ether_addr(port->mac))
> + if (!IS_ERR_OR_NULL(port->mac))
> ether_addr_copy(slave_dev->dev_addr, port->mac);
> else
> eth_hw_addr_inherit(slave_dev, master);
> --
> 1.9.1
>
Tested-by: Vladimir Oltean
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE
From: Dexuan Cui Sent: Tuesday, May 7, 2019 12:47 AM
>
> In the case of X86_PAE, unsigned long is u32, but the physical address type
> should be u64. Due to the bug here, the netvsc driver can not load
> successfully, and sometimes the VM can panic due to memory corruption (the
> hypervisor writes data to the wrong location).
>
> Fixes: 6ba34171bcbd ("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()")
> Cc: sta...@vger.kernel.org
> Cc: Michael Kelley
> Reported-and-tested-by: Juliana Rodrigueiro
>
> Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Mon 06-05-19 19:16:22, Sultan Alsawaf wrote: > This is a complete low memory killer solution for Android that is small > and simple. Processes are killed according to the priorities that > Android gives them, so that the least important processes are always > killed first. Processes are killed until memory deficits are satisfied, > as observed from kswapd struggling to free up pages. Simple LMK stops > killing processes when kswapd finally goes back to sleep. > > The only tunables are the desired amount of memory to be freed per > reclaim event and desired frequency of reclaim events. Simple LMK tries > to free at least the desired amount of memory per reclaim and waits > until all of its victims' memory is freed before proceeding to kill more > processes. Why do we need something like that in the kernel? I really do not like an idea of having two OOM killer implementations in the kernel. As already pointed out newer kernels can do PSI and older kernels can live with an out of tree code to achieve what they need. I do not see why we really need this code in the upstream kernel. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote: > On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > > Given that any "new" android device that gets shipped "soon" should be > > using 4.9.y or newer, is this a real issue? > > It's certainly a real issue for those who can't buy brand new Android devices > without software bugs every six months :) Heh. But, your "new code" isn't going to be going into any existing device, or any device that will come out this year. The soonest it would be would be next year, and by then, 4.9.y is fine. > > And if it is, I'm sure that asking for those patches to be backported to > > 4.4.y would be just fine, have you asked? > > > > Note that I know of Android Go devices, running 3.18.y kernels, do NOT > > use the in-kernel memory killer, but instead use the userspace solution > > today. So trying to get another in-kernel memory killer solution added > > anywhere seems quite odd. > > It's even more odd that although a userspace solution is touted as the proper > way to go on LKML, almost no Android OEMs are using it, and even in that > commit > I linked in the previous message, Google made a rather large set of > modifications to the supposedly-defunct lowmemorykiller.c not one month ago. > What's going on? "almost no"? Again, Android Go is doing that, right? And yes, there is still some 4.4 android-common work happening in this area, see this patch that just got merged: https://android-review.googlesource.com/c/kernel/common/+/953354 So, for 4.4.y based devices, that should be enough, right? > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. Qualcomm should never be used as an example of a company that has any idea of what to do in their kernel :) > If PSI were backported to 4.4, or even 3.18, would it really be used? Why wouldn't it, if it worked properly? > I don't really understand the aversion to an in-kernel memory killer > on LKML despite the rest of the industry's attraction to it. Perhaps > there's some inherently great cost in using the userspace solution > that I'm unaware of? Please see the work that went into PSI and the patches around it. There's also a lwn.net article last week about the further work ongoing in this area. With all of that, you should see how in-kernel memory killers are NOT the way to go. > Regardless, even if PSI were backported, a full-fledged LMKD using it has yet > to > be made, so it wouldn't be of much use now. "LMKD"? Again, PSI is in the 4.9.y android-common tree, so the userspace side should be in AOSP, right? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote: > On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > > Given that any "new" android device that gets shipped "soon" should be > > using 4.9.y or newer, is this a real issue? > > It's certainly a real issue for those who can't buy brand new Android devices > without software bugs every six months :) > > > And if it is, I'm sure that asking for those patches to be backported to > > 4.4.y would be just fine, have you asked? > > > > Note that I know of Android Go devices, running 3.18.y kernels, do NOT > > use the in-kernel memory killer, but instead use the userspace solution > > today. So trying to get another in-kernel memory killer solution added > > anywhere seems quite odd. > > It's even more odd that although a userspace solution is touted as the proper > way to go on LKML, almost no Android OEMs are using it, and even in that > commit That's probably because without proper kernel changes this is rather tricky to use safely (see below). > I linked in the previous message, Google made a rather large set of > modifications to the supposedly-defunct lowmemorykiller.c not one month ago. > What's going on? > > Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. If PSI were > backported to 4.4, or even 3.18, would it really be used? I don't really > understand the aversion to an in-kernel memory killer on LKML despite the rest > of the industry's attraction to it. Perhaps there's some inherently great cost > in using the userspace solution that I'm unaware of? > > Regardless, even if PSI were backported, a full-fledged LMKD using it has yet > to > be made, so it wouldn't be of much use now. This is work that is ongoing and requires kernel changes to make it feasible. One of the things that I have been working on for quite a while is the whole file descriptor for processes thing that is important for LMKD (Even though I never thought about this use-case when I started pitching this.). Joel and Daniel have joined in and are working on making LMKD possible. What I find odd is that every couple of weeks different solutions to the low memory problem are pitched. There is simple_lkml, there is LMKD, and there was a patchset that wanted to speed up memory reclaim at process kill-time by adding a new flag to the new pidfd_send_signal() syscall. That all seems - though related - rather uncoordinated. Now granted, coordinated is usually not how kernel development necessarily works but it would probably be good to have some sort of direction and from what I have seen LMKD seems to be the most coordinated effort. But that might just be my impression. Christian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes
Oh crap. You did add a Fixes tag. My bad. I should have been more clear/pro-active on Friday and we could have avoided this... Next time. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes
Hi Petr,
On Mon, May 6, 2019 at 11:25 PM Petr Štetiar wrote:
> this patch series is an attempt to fix the mess, I've somehow managed to
> introduce.
>
> First patch in this series is defacto v5 of the previous 05/10 patch in the
> series, but since the v4 of this 05/10 patch wasn't picked up by the
> patchwork for some unknown reason, this patch wasn't applied with the other
> 9 patches in the series, so I'm resending it as a separate patch of this
> fixup series again.
>
> Second patch is a result of this rebase against net-next tree, where I was
> checking again all current users of of_get_mac_address and found out, that
> there's new one in DSA, so I've converted this user to the new ERR_PTR
> encoded error value as well.
>
> Third patch which was sent as v5 wasn't considered for merge, but I still
> think, that we need to check for possible NULL value, thus current IS_ERR
> check isn't sufficient and we need to use IS_ERR_OR_NULL instead.
>
> Fourth patch fixes warning reported by kbuild test robot.
>
> Cheers,
>
> Petr
>
> Petr Štetiar (4):
> net: ethernet: support of_get_mac_address new ERR_PTR error
I didn't receive the patch through email, but patchwork does have it:
https://patchwork.ozlabs.org/patch/1096054/
This fixes the crash ("Unable to handle kernel paging request atvirtual
address fffe") I'm seeing with sh_eth on r8a7791/koelsch, so
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
netdev patchwork issues [Was: Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes]
Petr Štetiar [2019-05-07 10:39:18]: [adding Jeremy to the Cc: loop] > it was applied[2] to David's net-next tree, but unfortunately partialy, just 9 > patches out of 10, as the patch 05/10 in that series (which is patch 1/4 in > this series) never reached netdev mailing list and patchwork, probably because > of some netdev mailing list software and/or patchwork hiccup, very likely due > to the long list of recipients in that patch and as I'm not subscribed to the > netdev (due to the high traffic) I'm probably treaten somehow differently. For the record, I've following in my ~/.gitconfig: [sendemail.linux] tocmd ="`pwd`/scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nol" cccmd ="`pwd`/scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nom" and I've sent the patches with the following command: git send-email \ --to net...@vger.kernel.org \ --to 'David S. Miller ' \ --cc 'Andrew Lunn ' \ --cc 'Florian Fainelli ' \ --cc 'Heiner Kallweit ' \ --cc 'Frank Rowand ' \ --cc 'de...@driverdev.osuosl.org' \ --cc 'linux-ker...@vger.kernel.org' \ --cc 'Greg Kroah-Hartman ' \ --cc 'Maxime Ripard ' \ --identity linux tmp/nvmem-fix-v2/000* which resulted just in the following 4 bounces: * n...@openwrt.org (no such recipient) * ks.g...@samsung.com (no such recipient) * vipul.pan...@samsung.com (no such recipient) Your mail to 'linux-arm-kernel' with the subject [PATCH net-next v2 1/4] net: ethernet: support of_get_mac_address new ERR_PTR error Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message So maybe netdev have similar moderation stuff enabled, but doesn't send out this notices back? I've "fixed" the issue with the following workaround: git send-email \ --to net...@vger.kernel.org \ --in-reply-to '<1557177887-30446-1-git-send-email-yn...@true.cz>' \ tmp/nvmem-fix-v2/0001-net-ethernet-support-of_get_mac_address-new-ERR_PTR-.patch That is, just using netdev as the sole recipient and then the patch has appeared in the patchwork and in the mailing list archive as well. -- ynezz ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes
Dan Carpenter [2019-05-07 10:19:14]:
Hi,
> On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote:
> >
> > this patch series is an attempt to fix the mess, I've somehow managed to
> > introduce.
> >
> > First patch in this series is defacto v5 of the previous 05/10 patch in the
> > series, but since the v4 of this 05/10 patch wasn't picked up by the
> > patchwork for some unknown reason, this patch wasn't applied with the other
> > 9 patches in the series, so I'm resending it as a separate patch of this
> > fixup series again.
>
> I feel sort of ridiculous asking this over and over... Maybe your spam
> filter is eating my emails?
nope, I've read your email, that's the only reason I've sent out this v2 which
added Fixes: tag you've suggested in your email.
> This bug was introduced in https://patchwork.ozlabs.org/patch/1094916/
> "[v4,01/10] of_net: add NVMEM support to of_get_mac_address" but it
> looks like no one applied it.
this patch series is against net-next, and I've added Fixes: tag as you've
requested in this v2 series[1] (which expands to commit[2] in net-next):
Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
> You're acting as if it *was* applied but you refuse to answer my
> question who applied it and which to which tree so I can figure out what
> went wrong.
it was applied[2] to David's net-next tree, but unfortunately partialy, just 9
patches out of 10, as the patch 05/10 in that series (which is patch 1/4 in
this series) never reached netdev mailing list and patchwork, probably because
of some netdev mailing list software and/or patchwork hiccup, very likely due
to the long list of recipients in that patch and as I'm not subscribed to the
netdev (due to the high traffic) I'm probably treaten somehow differently.
So to sum it up, I've simply thought, that it was enough to send out v2 with
that Fixes: tag and considered it done.
> I only see comments from last Friday that it shouldn't be applied...
I'm sorry, but which comments do you mean exactly? Those about the
`nvmem-mac-address` DT (sysfs) entry? If that is the case, from my point of
view, I've provided reasonable arguments and nobody told me, that I'm wrong
with my reasoning or NACKed this explicitly, so David probably considered my
arguments good enough and merged it as it is? I don't have any other
explanation.
> I also told you on Friday in a different thread that that patch shouldn't be
> applied. Breaking git bisect is a bug, and we never do that.
Yes, and I agree with you, but I've simply thought, that if any of the
maintainers who previously reviewed the series didn't objected about this,
that they're possibly going to squash those patches by themselves during the
merging process or that they're going to tell me to do so and I would address
this in the latest interation of the patchset before merge.
Anyway, is there any possibility how to fix that now?
> I'm just very confused right now. What I'm trying to do is figure out in
> my head how this process failed so we can do better next time.
I'm just occasional contributor, so I'm sorry, but I can hardly provide any
input.
1. https://patchwork.ozlabs.org/patch/1096054/
2.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=d01f449c008a3f41fa44c603e28a7452ab8f8e68
Cheers,
Petr
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote: > Given that any "new" android device that gets shipped "soon" should be > using 4.9.y or newer, is this a real issue? It's certainly a real issue for those who can't buy brand new Android devices without software bugs every six months :) > And if it is, I'm sure that asking for those patches to be backported to > 4.4.y would be just fine, have you asked? > > Note that I know of Android Go devices, running 3.18.y kernels, do NOT > use the in-kernel memory killer, but instead use the userspace solution > today. So trying to get another in-kernel memory killer solution added > anywhere seems quite odd. It's even more odd that although a userspace solution is touted as the proper way to go on LKML, almost no Android OEMs are using it, and even in that commit I linked in the previous message, Google made a rather large set of modifications to the supposedly-defunct lowmemorykiller.c not one month ago. What's going on? Qualcomm still uses lowmemorykiller.c [1] on the Snapdragon 845. If PSI were backported to 4.4, or even 3.18, would it really be used? I don't really understand the aversion to an in-kernel memory killer on LKML despite the rest of the industry's attraction to it. Perhaps there's some inherently great cost in using the userspace solution that I'm unaware of? Regardless, even if PSI were backported, a full-fledged LMKD using it has yet to be made, so it wouldn't be of much use now. Thanks, Sultan [1] https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/arch/arm64/configs/sdm845_defconfig?h=LA.UM.7.3.r1-07400-sdm845.0#n492 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE
In the case of X86_PAE, unsigned long is u32, but the physical address type
should be u64. Due to the bug here, the netvsc driver can not load
successfully, and sometimes the VM can panic due to memory corruption (the
hypervisor writes data to the wrong location).
Fixes: 6ba34171bcbd ("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()")
Cc: sta...@vger.kernel.org
Cc: Michael Kelley
Reported-and-tested-by: Juliana Rodrigueiro
Signed-off-by: Dexuan Cui
---
drivers/hv/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 23381c41d087..aaaee5f93193 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -38,7 +38,7 @@
static unsigned long virt_to_hvpfn(void *addr)
{
- unsigned long paddr;
+ phys_addr_t paddr;
if (is_vmalloc_addr(addr))
paddr = page_to_phys(vmalloc_to_page(addr)) +
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes
On Tue, May 07, 2019 at 10:19:14AM +0300, Dan Carpenter wrote: > On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote: > > Hi, > > > > this patch series is an attempt to fix the mess, I've somehow managed to > > introduce. > > > > First patch in this series is defacto v5 of the previous 05/10 patch in the > > series, but since the v4 of this 05/10 patch wasn't picked up by the > > patchwork for some unknown reason, this patch wasn't applied with the other > > 9 patches in the series, so I'm resending it as a separate patch of this > > fixup series again. > > I feel sort of ridiculous asking this over and over... Maybe your spam > filter is eating my emails? > > This bug was introduced in https://patchwork.ozlabs.org/patch/1094916/ > "[v4,01/10] of_net: add NVMEM support to of_get_mac_address" but it > looks like no one applied it. > > You're acting as if it *was* applied but you refuse to answer my > question who applied it and which to which tree so I can figure out what > went wrong. > > I only see comments from last Friday that it shouldn't be applied... I > also told you on Friday in a different thread that that patch shouldn't > be applied. Breaking git bisect is a bug, and we never do that. I'm > just very confused right now... What I'm trying to do is figure out in > my head how this process failed so we can do better next time. Just to resend this, so that it hopefully does _not_ get stuck in a spam filter. Petr, please address Dan's comments, do not ignore them. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 12:27:21AM -0700, Sultan Alsawaf wrote: > On Tue, May 07, 2019 at 09:04:30AM +0200, Greg Kroah-Hartman wrote: > > Um, why can't "all" Android devices take the same patches that the Pixel > > phones are using today? They should all be in the public android-common > > kernel repositories that all Android devices should be syncing with on a > > weekly/monthly basis anyway, right? > > > > thanks, > > > > greg k-h > > Hi Greg, > > I only see PSI present in the android-common kernels for 4.9 and above. The > vast > majority of Android devices do not run a 4.9+ kernel. It seems unreasonable to > expect OEMs to toil with backporting PSI themselves to get decent memory > management. Given that any "new" android device that gets shipped "soon" should be using 4.9.y or newer, is this a real issue? And if it is, I'm sure that asking for those patches to be backported to 4.4.y would be just fine, have you asked? Note that I know of Android Go devices, running 3.18.y kernels, do NOT use the in-kernel memory killer, but instead use the userspace solution today. So trying to get another in-kernel memory killer solution added anywhere seems quite odd. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, May 07, 2019 at 09:04:30AM +0200, Greg Kroah-Hartman wrote: > Um, why can't "all" Android devices take the same patches that the Pixel > phones are using today? They should all be in the public android-common > kernel repositories that all Android devices should be syncing with on a > weekly/monthly basis anyway, right? > > thanks, > > greg k-h Hi Greg, I only see PSI present in the android-common kernels for 4.9 and above. The vast majority of Android devices do not run a 4.9+ kernel. It seems unreasonable to expect OEMs to toil with backporting PSI themselves to get decent memory management. But even if they did backport PSI, it wouldn't help too much because a PSI-enabled LMKD solution is not ready yet. It looks like a PSI-based LMKD is still under heavy development and won't be ready for all Android devices for quite some time. Additionally, it looks like the supposedly-dead lowmemorykiller.c is still being actively tweaked by Google [1], which does not instill confidence that a definitive LMK solution a la PSI is coming any time soon. Thanks, Sultan [1] https://android.googlesource.com/kernel/common/+/152bacdd85c46f0c76b00c4acc253e414513634c ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes
On Mon, May 06, 2019 at 11:24:43PM +0200, Petr Štetiar wrote: > Hi, > > this patch series is an attempt to fix the mess, I've somehow managed to > introduce. > > First patch in this series is defacto v5 of the previous 05/10 patch in the > series, but since the v4 of this 05/10 patch wasn't picked up by the > patchwork for some unknown reason, this patch wasn't applied with the other > 9 patches in the series, so I'm resending it as a separate patch of this > fixup series again. I feel sort of ridiculous asking this over and over... Maybe your spam filter is eating my emails? This bug was introduced in https://patchwork.ozlabs.org/patch/1094916/ "[v4,01/10] of_net: add NVMEM support to of_get_mac_address" but it looks like no one applied it. You're acting as if it *was* applied but you refuse to answer my question who applied it and which to which tree so I can figure out what went wrong. I only see comments from last Friday that it shouldn't be applied... I also told you on Friday in a different thread that that patch shouldn't be applied. Breaking git bisect is a bug, and we never do that. I'm just very confused right now... What I'm trying to do is figure out in my head how this process failed so we can do better next time. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Mon, May 06, 2019 at 07:16:22PM -0700, Sultan Alsawaf wrote: > This is a complete low memory killer solution for Android that is small > and simple. Processes are killed according to the priorities that > Android gives them, so that the least important processes are always > killed first. Processes are killed until memory deficits are satisfied, > as observed from kswapd struggling to free up pages. Simple LMK stops > killing processes when kswapd finally goes back to sleep. > > The only tunables are the desired amount of memory to be freed per > reclaim event and desired frequency of reclaim events. Simple LMK tries > to free at least the desired amount of memory per reclaim and waits > until all of its victims' memory is freed before proceeding to kill more > processes. > > Signed-off-by: Sultan Alsawaf > --- > Hello everyone, > > I've addressed some of the concerns that were brought up with the first > version > of the Simple LMK patch. I understand that a kernel-based solution like this > that contains policy decisions for a specific userspace is not the way to go, > but the Android ecosystem still has a pressing need for a low memory killer > that > works well. > > Most Android devices still use the ancient and deprecated lowmemorykiller.c > kernel driver; Simple LMK seeks to replace that, at the very least until PSI > and > a userspace daemon utilizing PSI are ready for *all* Android devices, and not > just the privileged Pixel phone line. Um, why can't "all" Android devices take the same patches that the Pixel phones are using today? They should all be in the public android-common kernel repositories that all Android devices should be syncing with on a weekly/monthly basis anyway, right? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
