Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
On 01/25/19 at 03:08pm, Borislav Petkov wrote: > On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote: > > AFAIK, some people prefer to explictly reserve crash memory at high > > region even if it is possible to reserve at low area. May because > > <4G memory is limited on large server, they want to leave this for other > > use. > > > > Yinghai or Vivek should know more about the history, probably they can > > recall some initial reason. > > Yes, just "prefer" is not good enough. There should be a technical > reason why that's there. Got more about this, actually the thing is for large server with very huge memory and also possible a lot of io devices. The UEFI IO drivers could allocate a lot memory under 896M, so it will leave small room for crashkernel=X Also if the memory is huge, then copying the vmcore will be very slow, people want to use big makedumpfile bitmap buffer, and multithread, then kdump kernel needs more memory, they can choose ,high to get more memory. But for common use cases, if one does not need so much kdump memory reserved he/she can just use crashkernel=X. > > Also, if the user doesn't care, then the code should be free to force > "high" and thus probe a different range for allocation. As Pingfan/me mentioned in another reply, there are two reasons: 1. old kexec-tools can not load kernel to high memory 2. ,high will not work on some systems without some amounts of low memory so it nees reserve extra low memory, it is bad for people who do not want it. > > > Good question, still it may be some historical reason, but it is good to > > make them clear and rethink about it after long time. > > > > I also want to understand, need dig the log more. > > Good idea. That would be a very nice cleanup. :-) Let's review these different parameters: > crashkernel=size[KMG][@offset[KMG]] Did not get the initial commit for this, it should be the very old format, and kernel did not find the base address automatically for the size Other arches still use this, for example mips code seems needs explict @offset, see the function mips_parse_crashkernel in arch/mips/kernel/setup.c Probably there are other arches as well which only support this format. > crashkernel=range1:size1[,range2:size2,...][@offset] This is nice param which can help to dynamically reserve different size depends on system memory. > crashkernel=size[KMG],high > crashkernel=size[KMG],low We have talked about these two. It is not graceful, but seems no way to improve it due to the swiotlb issue. Thanks Dave
Re: System crash with perf_fuzzer (kernel: 5.0.0-rc3)
Hi Andi, On 1/25/19 9:30 PM, Andi Kleen wrote: >> [Fri Jan 25 10:28:53 2019] perf: interrupt took too long (2501 > 2500), >> lowering kernel.perf_event_max_sample_rate to 79750 >> [Fri Jan 25 10:29:08 2019] perf: interrupt took too long (3136 > 3126), >> lowering kernel.perf_event_max_sample_rate to 63750 >> [Fri Jan 25 10:29:11 2019] perf: interrupt took too long (4140 > 3920), >> lowering kernel.perf_event_max_sample_rate to 48250 >> [Fri Jan 25 10:29:11 2019] perf: interrupt took too long (5231 > 5175), >> lowering kernel.perf_event_max_sample_rate to 38000 >> [Fri Jan 25 10:29:11 2019] perf: interrupt took too long (6736 > 6538), >> lowering kernel.perf_event_max_sample_rate to 29500 > > These are fairly normal. I understand that throttling mechanism is designed exactly to do this. But I've observed that, everytime I run the fuzzer, max_sample_rates is been throttled down to 250 (which is CONFIG_HZ I guess). Doesn't this mean the interrupt time is somehow increasing gradually? Is that fine? Here is the sample dmesg: [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (2928 > 2500), lowering kernel.perf_event_max_sample_rate to 68250 [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (4363 > 3660), lowering kernel.perf_event_max_sample_rate to 45750 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 2.183 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (21382 > 5453), lowering kernel.perf_event_max_sample_rate to 9250 [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (34548 > 26727), lowering kernel.perf_event_max_sample_rate to 5750 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 3.509 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (61682 > 43185), lowering kernel.perf_event_max_sample_rate to 3000 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 3.593 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (89206 > 77102), lowering kernel.perf_event_max_sample_rate to 2000 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 3.619 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (120188 > 111507), lowering kernel.perf_event_max_sample_rate to 1500 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 3.782 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (171065 > 150235), lowering kernel.perf_event_max_sample_rate to 1000 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 4.066 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (226815 > 213831), lowering kernel.perf_event_max_sample_rate to 750 [Thu Jan 31 09:25:40 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 5.364 msecs [Thu Jan 31 09:25:40 2019] perf: interrupt took too long (300844 > 283518), lowering kernel.perf_event_max_sample_rate to 500 [Thu Jan 31 09:33:43 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 6.136 msecs [Thu Jan 31 09:50:35 2019] perf: interrupt took too long (378352 > 376055), lowering kernel.perf_event_max_sample_rate to 500 [Thu Jan 31 09:53:47 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 6.456 msecs [Thu Jan 31 09:57:31 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 11.002 msecs [Thu Jan 31 10:01:30 2019] perf: interrupt took too long (478447 > 472940), lowering kernel.perf_event_max_sample_rate to 250 [Thu Jan 31 12:28:31 2019] perf: interrupt took too long (601630 > 598058), lowering kernel.perf_event_max_sample_rate to 250 [Thu Jan 31 12:28:31 2019] perf: interrupt took too long (754288 > 752037), lowering kernel.perf_event_max_sample_rate to 250 [Thu Jan 31 12:43:13 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 12.781 msecs [Thu Jan 31 12:43:13 2019] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.583 msecs Thanks, Ravi
Re: [PATCH v8 5/7] tpm: move tpm_chip definition to include/linux/tpm.h
On 1/29/2019 9:34 PM, Jarkko Sakkinen wrote:
On Thu, Jan 24, 2019 at 04:49:08PM +0100, Roberto Sassu wrote:
-enum tpm_const {
- TPM_MINOR = 224,/* officially assigned */
- TPM_BUFSIZE = 4096,
- TPM_NUM_DEVICES = 65536,
- TPM_RETRY = 50, /* 5 seconds */
- TPM_NUM_EVENT_LOG_FILES = 3,
-};
Here using enum has been a bad idea in the first place, as they don't
relate in any meaningful way.
Replace the definition with the following in drivers/char/tpm/tpm.h:
#define TPM_MINOR 224 /* misc backwards compatibility */
#define TPM_BUFSIZE 4096
#define TPM_NUM_DEVICES 65536
#define TPM_RETRY 5 /* seconds */
Is 5 correct? TPM_RETRY was 50 before.
Roberto
And only add this to include/linux/tpm.h:
#define TPM_NUM_EVENT_LOG_FILES 3
Otherwise, this looks good.
/Jarkko
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
Darlehensangebot für 2% Zinssatz. Keine Vorabgebühren
Hallo, Wir bieten persönlichen Bedienung für alle Ihre finanziellen Bedürfnisse zu einem sehr niedrigen Zinssatz von 2%, bieten wir persönliche Darlehen, Schuldenkonsolidierung Darlehen, Risiko kapital, Geschäft-Darlehen, Bildungs kredite, Home kredit und Darlehen aus welchen Gründen auch immer und dringend. Mit einem Minimum von einem Jahr und einer maximalen Laufzeit von 30 Jahren. Bist du von deiner Bank abgelehnt worden? Haben Sie schlechte Kredit? Hast du unbezahlte Rechnungen? Bist du verschuldet? Müssen Sie ein Geschäft gründen? Nun, sorgen Sie sich nicht mehr, da wir einen zinsgünstigen Kredit für Sie finden. Unser Darlehen reicht von 6.000,00 Euro bis 800.000.000,00 Euro. Wir bieten auch Kreditbetrag in Pound £ und Dollar $. Ergreifen Sie diese Gelegenheit. Ihre Investition erfordert den besten Kredit Bedienung des Jahres. Für weitere Unterstützung und für jede interessierte Person kontaktieren Sie uns bitte per E-Mail: daviswri...@yandex.com
[PATCH] mmc: mmc: Fix HS setting in mmc_hs400_to_hs200()
mmc_hs400_to_hs200() begins with the card and host in HS400 mode. Therefore, any commands sent to the card should use HS400 timing. It is incorrect to reduce frequency to 50Mhz before sending the switch command, in this case, only reduce clock frequency to 50Mhz but without host timming change, host is still in hs400 mode but clock changed from 200Mhz to 50Mhz, which makes the tuning result unsuitable and cause the switch command gets response CRC error. this patch refers to mmc_select_hs400(), make the reduce clock frequency after card timing change. Signed-off-by: Chaotian Jing --- drivers/mmc/core/mmc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index da892a5..21b811e 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -1239,10 +1239,6 @@ int mmc_hs400_to_hs200(struct mmc_card *card) int err; u8 val; - /* Reduce frequency to HS */ - max_dtr = card->ext_csd.hs_max_dtr; - mmc_set_clock(host, max_dtr); - /* Switch HS400 to HS DDR */ val = EXT_CSD_TIMING_HS; err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, @@ -1253,6 +1249,10 @@ int mmc_hs400_to_hs200(struct mmc_card *card) mmc_set_timing(host, MMC_TIMING_MMC_DDR52); + /* Reduce frequency to HS */ + max_dtr = card->ext_csd.hs_max_dtr; + mmc_set_clock(host, max_dtr); + err = mmc_switch_status(card); if (err) goto out_err; -- 1.8.1.1.dirty
Re: [PATCH] PCI: Mediatek: Use resource_size function on resource object
On Thu, 2019-01-31 at 11:03 +0800, Honghui Zhang wrote: > On Wed, 2019-01-30 at 09:49 -0600, Bjorn Helgaas wrote: > > On Wed, Jan 02, 2019 at 02:03:53PM +0800, honghui.zh...@mediatek.com wrote: > > > From: Honghui Zhang > > > > > > drivers/pci/pcie-mediatek.c:720:13-16: WARNING: Suspicious code. > > > resource_size is maybe missing with mem > > > > > > Generated by: scripts/coccinelle/api/resource_size.cocci > > > > > > Signed-off-by: Honghui Zhang > > > --- > > > drivers/pci/controller/pcie-mediatek.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/pci/controller/pcie-mediatek.c > > > b/drivers/pci/controller/pcie-mediatek.c > > > index e307166..0168376 100644 > > > --- a/drivers/pci/controller/pcie-mediatek.c > > > +++ b/drivers/pci/controller/pcie-mediatek.c > > > @@ -654,7 +654,6 @@ static int mtk_pcie_startup_port_v2(struct > > > mtk_pcie_port *port) > > > struct resource *mem = &pcie->mem; > > > const struct mtk_pcie_soc *soc = port->pcie->soc; > > > u32 val; > > > - size_t size; > > > int err; > > > > > > /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */ > > > @@ -706,8 +705,7 @@ static int mtk_pcie_startup_port_v2(struct > > > mtk_pcie_port *port) > > > mtk_pcie_enable_msi(port); > > > > > > /* Set AHB to PCIe translation windows */ > > > - size = mem->end - mem->start; > > > - val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size)); > > > + val = lower_32_bits(mem->start) | > > > AHB2PCIE_SIZE(fls(resource_size(mem))); > > > > This is actually a fairly interesting change because it effectively > > changes this: > > > > fls(mem->end - mem->start) > > > > to this: > > > > fls(mem->end - mem->start + 1) > > > > And mem->end is the last valid address, so it changes something like > > this: > > > > fls(0x) # == 15 > > > > to this: > > > > fls(0x1)# == 16 > > > > So while this *looks* like a trivial warning fix, it likely fixes an > > important bug, and it's worth pointing out what that bug is in the > > changelog. > > > > > writel(val, port->base + PCIE_AHB_TRANS_BASE0_L); > > > > > > val = upper_32_bits(mem->start); > > This size will set the MMIO size, which means that the RC will translate > the MMIO access from mem->start to mem->end. > The real MMIO size is specified in devicetree, which is 0x1000_ for > both mt2712 and mt7622. > > This change make the size from fls(0x1000_) to fls(0x1000_0001), not > really change the values. > > I will update the commit message and add the information mentioned > above. > > Thanks for your kindly review. I was wrong, after take a look at the resource parser function, that it will initialize the res->end as res->start + res->size - 1. But this change is still Ok since it will change the MMIO from fls(0xfff_) to fls(0x1000_), this just enlarge the MMIO translate window size. The HW assigned MMIO is 0x1000_, but original code set this translate window to fls(0xfff_) = 0x800_ is fine in most case since all the EP device we connect never asked a MMIO window bigger than 0x800_. (As a matter of fact, most EP device will only ask for 4MB MMIO window size.) I will put this in the commit message. thanks. > > > > -- > > > 2.6.4 > > > > >
Re: [PATCH 4.20 000/117] 4.20.6-stable review
On Wed, Jan 30, 2019 at 07:04:39PM +0530, Naresh Kamboju wrote: > On Tue, 29 Jan 2019 at 17:08, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 4.20.6 release. > > There are 117 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jan 31 11:31:34 UTC 2019. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.6-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.20.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Summary > > > kernel: 4.20.6-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.20.y > git commit: ef18d4260339bf79aa387199f912d366aa7e4b93 > git describe: v4.20.5-119-gef18d4260339 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.20-oe/build/v4.20.5-119-gef18d4260339 > > No regressions (compared to build v4.20.5) > Thanks for testing these and letting me know. greg k-h
Re: [PATCH 4.14 00/68] 4.14.97-stable review
On Wed, Jan 30, 2019 at 12:51:12PM +, Jon Hunter wrote: > > On 29/01/2019 11:35, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.97 release. > > There are 68 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jan 31 11:31:10 UTC 2019. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.97-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > All tests are passing for Tegra ... > > Test results for stable-v4.14: > 8 builds: 8 pass, 0 fail > 16 boots: 16 pass, 0 fail > 14 tests: 14 pass, 0 fail > > Linux version:4.14.97-rc1-g958f665 > Boards tested:tegra124-jetson-tk1, tegra20-ventana, > tegra210-p2371-2180, tegra30-cardhu-a04 Thanks for testing two of these and letting me know. greg k-h
Re: [PATCH v2] usb: chipidea: Grab the (legacy) USB PHY by phandle first
Hello! On 30.01.2019 19:30, Paul Kocialkowski wrote: According to the chipidea driver bindings, the USB PHY is specified via the "phys" phandle node. However, this only takes effect for USB PHYs that use the common PHY framework. For legacy USB PHYs, a simple lookup based on the USB PHY type is done instead. This does not play out well when more than USB PHY is registered, since More than one? the first registered PHY matching the type will always be returned regardless of what the driver was bound to. Fix this by looking up the PHY based on the "phys" phandle node. Although generic PHYS and rather matched by their "phys-name" and not the "phys" phandle directly, there is no helper for similar lookup on legacy PHYs and it's probably not worth the effort to add it. When no legacy USB PHY is found by phandle, fallback to grabbing any registered USB2 PHY. This ensures backward compatibility if some users were actually relying on this mechanism. Signed-off-by: Paul Kocialkowski [...] MBR, Sergei
Re: [PATCH v7 0/3] Move pm_runtime accounted time to raw nsec
On Thu, 31 Jan 2019 at 00:51, Rafael J. Wysocki wrote: > > On Wednesday, January 23, 2019 8:50:12 AM CET Vincent Guittot wrote: > > Move pm_runtime accounted time to raw nsec. The subject of the patchset > > has changed as 1st patch o the previous versions has been queued by > > Rafael. > > > > Patch 1 set accounting_timestamp to 0 in pm_runtime_init and update it when > > enable. > > So we remove ordering constraint between timekeeping_init and > > pm_runtime_init > > > > Patch 2 moves time accounting on raw ns. This patch initially used > > ktime instead of raw ns but it was easier to move i915 driver on raw ns > > than on ktime. > > > > Change since v6: > > - move code that set accounting_timestamp in pm_runtime_enable > > > > Changes since v5: > > - removed patches already queued. > > - set accounting_timestamp to 0 in pm_runtime_init and update it when enable > > > > Changes since v4: > > -Update commit message > > > > Changes since v3: > > - Rebase on v4.20-rc7 without patch that has been queued by Rafael > > - Simplify the new interface pm_runtime_suspended_time() > > > > Changes since v2: > > - remove patch1 that has been queued by rafael > > - add new interface in pm_runtime to get accounted time > > - reorder patchset to prevent compilation error > > > > Changes since v1: > > - updated commit message of patch 1 > > - Added patches 2 & 3 to move runtime_pm accounting on raw ns > > > > Thara Gopinath (1): > > PM-runtime: Replace jiffies based accounting with ktime-based > > accounting > > > > Vincent Guittot (1): > > PM-runtime: update accounting_timestamp only when enable > > > > drivers/base/power/runtime.c | 26 -- > > drivers/base/power/sysfs.c | 11 --- > > include/linux/pm.h | 6 +++--- > > 3 files changed, 27 insertions(+), 16 deletions(-) > > Both patches applied, thanks! > I had some comment on v6, none that needs to prevent this from being applied and that can't be addressed as improvements on top. Feel free to add (if not too late) my: Reviewed-by: Ulf Hansson Kind regards Uffe
Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
On 01/29/19 at 01:25pm, Pingfan Liu wrote: > On Fri, Jan 25, 2019 at 10:08 PM Borislav Petkov wrote: > > > > On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote: > > > AFAIK, some people prefer to explictly reserve crash memory at high > > > region even if it is possible to reserve at low area. May because > > > <4G memory is limited on large server, they want to leave this for other > > > use. > > > > > > Yinghai or Vivek should know more about the history, probably they can > > > recall some initial reason. > > > Go through the git log, and I found the initial introduction of > crashkernel_high option. Refer to > commit 55a20ee7804ab64ac90bcdd4e2868a42829e2784 > Author: Yinghai Lu > Date: Mon Apr 15 22:23:47 2013 -0700 > > x86, kdump: Retore crashkernel= to allocate under 896M > > Vivek found old kexec-tools does not work new kernel anymore. > > So change back crashkernel= back to old behavoir, and add > crashkernel_high= > to let user decide if buffer could be above 4G, and also new > kexec-tools will > be needed. > > But kexec-tools-2.0.3, released at 2012, can run 4.20 kernel with > crashkernel=256M@5G, so I think only very old kexec-tools requires > memory under 896M. Due to -1.few people running latest kernel with > very old kexec-tools to date, -2. crashkernel=X is more popular than > crashkernel=X.high, it should be time to eliminate this limit of > crashkernel=X parameter, otherwise we will run into this bug. > As for crashkernel=,high, I think it is a more professional option for > who cares about the DMA32. On high-end machine, big reserved region is > used for crashkernel(e.g. in this case 384M), which make the crowed > situation under under 4GB memory worse. This seems answers the question why ,high is needed and why crashkernel=X can not allocate from high by default. Another reason for this question is for crashkernel=,high, a separate region under 4G is still needed. I searched some history bug/emails, previously the initial commit does not reserve low memory by default if ,high is used, but later Yinghai saw a regression bug in case iommu disabled. see below commit: commit c729de8fcea37a1c444e81857eace12494c804a9 Author: Yinghai Lu Date: Mon Apr 15 22:23:45 2013 -0700 x86, kdump: Set crashkernel_low automatically Chao said that kdump does does work well on his system on 3.8 without extra parameter, even iommu does not work with kdump. And now have to append crashkernel_low=Y in first kernel to make kdump work. We have now modified crashkernel=X to allocate memory beyong 4G (if available) and do not allocate low range for crashkernel if the user does not specify that with crashkernel_low=Y. This causes regression if iommu is not enabled. Without iommu, swiotlb needs to be setup in first 4G and there is no low memory available to second kernel. [snip] > > > Yes, just "prefer" is not good enough. There should be a technical > > reason why that's there. > > > > Also, if the user doesn't care, then the code should be free to force > > "high" and thus probe a different range for allocation. > > > Do you suggest to remove crashkernel=X,high parameter? I do not think it can be removed, because for ,high we also need extra low memory, it will cause confusion, most people are just fine without this. People can choose to use ,high if they really need it. Thanks Dave
答复: 答复: 答复: [PATCH][v4] tty: fix race between flush_to_ldisc and tty_open
> -邮件原件-
> 发件人: Greg KH [mailto:gre...@linuxfoundation.org]
> 发送时间: 2019年1月31日 14:52
> 收件人: Li,Rongqing
> 抄送: jsl...@suse.com; linux-kernel@vger.kernel.org; gko...@codeaurora.org;
> linux-ser...@vger.kernel.org
> 主题: Re: 答复: 答复: [PATCH][v4] tty: fix race between flush_to_ldisc and
> tty_open
>
> On Thu, Jan 31, 2019 at 02:15:35AM +, Li,Rongqing wrote:
> >
> >
> > > -邮件原件-
> > > 发件人: Greg KH [mailto:gre...@linuxfoundation.org]
> > > 发送时间: 2019年1月30日 21:17
> > > 收件人: Li,Rongqing
> > > 抄送: jsl...@suse.com; linux-kernel@vger.kernel.org;
> > > gko...@codeaurora.org; linux-ser...@vger.kernel.org
> > > 主题: Re: 答复: [PATCH][v4] tty: fix race between flush_to_ldisc and
> > > tty_open
> > >
> > > On Wed, Jan 30, 2019 at 12:48:42PM +, Li,Rongqing wrote:
> > > >
> > > >
> > > > > -邮件原件-
> > > > > 发件人: linux-kernel-ow...@vger.kernel.org
> > > > > [mailto:linux-kernel-ow...@vger.kernel.org] 代表 Greg KH
> > > > > 发送时间: 2019年1月30日 18:19
> > > > > 收件人: Li,Rongqing
> > > > > 抄送: jsl...@suse.com; linux-kernel@vger.kernel.org;
> > > > > gko...@codeaurora.org
> > > > > 主题: Re: [PATCH][v4] tty: fix race between flush_to_ldisc and
> > > > > tty_open
> > > > >
> > > > > On Fri, Jan 18, 2019 at 05:27:17PM +0800, Li RongQing wrote:
> > > > > > There still is a race window after the commit b027e2298bd588
> > > > > > ("tty: fix data race between tty_init_dev and flush of buf"),
> > > > > > and we encountered this crash issue if receive_buf call comes
> > > > > > before tty initialization completes in n_tty_open and
> > > > > > tty->driver_data may be NULL.
> > > > > >
> > > > > > CPU0CPU1
> > > > > >
> > > > > > n_tty_open
> > > > > >tty_init_dev
> > > > > > tty_ldisc_unlock
> > > > > >schedule
> flush_to_ldisc
> > > > > > receive_buf
> > > > > > tty_port_default_receive_buf
> > > > > >tty_ldisc_receive_buf
> > > > > > n_tty_receive_buf_common
> > > > > > __receive_buf
> > > > > >uart_flush_chars
> > > > > > uart_start
> > > > > > /*tty->driver_data is NULL*/
> > > > > >tty->ops->open
> > > > > >/*init tty->driver_data*/
> > > > > >
> > > > > > it can be fixed by extending ldisc semaphore lock in
> > > > > > tty_init_dev to driver_data initialized completely after
> > > > > > tty->ops->open(), but this will lead to put lock on one
> > > > > > function and unlock in some other function, and hard to
> > > > > > maintain, so fix this race only by checking
> > > > > > tty->driver_data when receiving, and return if
> > > > > > tty->tty->driver_data
> > > > > > is NULL
> > > > > >
> > > > > > Signed-off-by: Wang Li
> > > > > > Signed-off-by: Zhang Yu
> > > > > > Signed-off-by: Li RongQing
> > > > > > ---
> > > > > > V4: add version information
> > > > > > V3: not used ldisc semaphore lock, only checking
> > > > > > tty->driver_data with NULL
> > > > > > V2: fix building error by EXPORT_SYMBOL tty_ldisc_unlock
> > > > > > V1: extend ldisc lock to protect that tty->driver_data is
> > > > > > inited
> > > > > >
> > > > > > drivers/tty/tty_port.c | 3 +++
> > > > > > 1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
> > > > > > index
> > > > > > 044c3cbdcfa4..86d0bec38322 100644
> > > > > > --- a/drivers/tty/tty_port.c
> > > > > > +++ b/drivers/tty/tty_port.c
> > > > > > @@ -31,6 +31,9 @@ static int
> > > > > > tty_port_default_receive_buf(struct
> > > > > > tty_port
> > > > > *port,
> > > > > > if (!tty)
> > > > > > return 0;
> > > > > >
> > > > > > + if (!tty->driver_data)
> > > > > > + return 0;
> > > > > > +
> > > > >
> > > > > How is this working? What is setting driver_data to NULL to
> > > > > "stop" this
> > > race?
> > > > >
> > > >
> > > >
> > > > if tty->driver_data is NULL and return,
> > > > tty_port_default_receive_buf will not step to uart_start which
> > > > access tty->driver_data and trigger panic before tty_open, so it
> > > > can fix the system panic
> > > >
> > > > > There's no requirement that a tty driver set this field to NULL
> > > > > when it is
> > > "done"
> > > > > with the tty device, so I think you are just getting lucky in
> > > > > that your specific driver happens to be doing this.
> > > > >
> > > >
> > > > when tty_open is running, tty is allocated by kzalloc in
> > > > tty_init_dev which called by tty_open_by_driver, tty is inited to
> > > > 0
> > > >
> > > > > What driver are you testing this against?
> > > > >
> > > >
> > > > 8250
> > >
> > > Ok, as this is specific to the uart core, how about this patch instead:
> > >
> > > diff --git a/drivers/tty/serial/serial_core.c
> > > b/drivers/tty/serial/serial_core.c
> > > index 5c01bb6d1c24..b56a6
Re: linux-next: powerpc le qemu boot failure after merge of the akpm tree
(added Andrey Konovalov)
On Thu, Jan 31, 2019 at 07:15:26AM +0100, Christophe Leroy wrote:
>
> Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
> >Hi all,
> >
> >On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
> >wrote:
> >>
> >>[I am guessing that is is something in Andrew's tree that has caused
> >>this.]
> >>
> >>My qemu boot of the powerpc pseries_le_defconfig config failed like this:
> >>
> >>htab_hash_mask= 0x1
> >>-
> >>numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff]
> >>Kernel panic - not syncing: sparse_buffer_init: Failed to allocate
> >>2147483648 bytes align=0x1 nid=0 from=fff
> >>CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4 #2
> >>Call Trace:
> >>[c105bbd0] [c0b1345c] dump_stack+0xb0/0xf4 (unreliable)
> >>[c105bc10] [c020] panic+0x168/0x3b8
> >>[c105bcb0] [c0e701c8] sparse_init_nid+0x178/0x550
> >>[c105bd70] [c0e709b4] sparse_init+0x210/0x238
> >>[c105bdb0] [c0e468f4] initmem_init+0x1e0/0x260
> >>[c105be80] [c0e3b9b0] setup_arch+0x354/0x3d4
> >>[c105bef0] [c0e33afc] start_kernel+0x98/0x648
> >>[c105bf90] [c000b270] start_here_common+0x1c/0x52c
> >
> >A quick bisect leads to this:
> >
> >1c3c9328cde027eb875ba4692f0a5d66b0afe862 is the first bad commit
> >commit 1c3c9328cde027eb875ba4692f0a5d66b0afe862
> >Author: Mike Rapoport
> >Date: Thu Jan 31 10:51:32 2019 +1100
> >
> > treewide: add checks for the return value of memblock_alloc*()
> > Add check for the return value of memblock_alloc*() functions and call
> > panic() in case of error. The panic message repeats the one used by
> > panicing memblock allocators with adjustment of parameters to include
> > only
> > relevant ones.
> >
> >Which is just adding the panic we hit. So, presumably, the bug is in a
> >preceding patch :-(
> >
> >I have left the kernel not booting for today.
> >
>
> No I think the error is really in that patch, see my other mail.
>
> See https://elixir.bootlin.com/linux/v5.0-rc4/source/mm/memblock.c#L1455,
> memblock_alloc_try_nid_raw() is not supposed to panic, so the last hunk of
> this patch should be reverted.
>
> Found in total three problematic hunks in that patch:
>
> @@ -48,6 +53,11 @@ static phys_addr_t __init kasan_alloc_raw_page(int node)
> void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_KASAN, node);
> + if (!p)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> from=%llx\n",
> + __func__, PAGE_SIZE, PAGE_SIZE, node,
> + __pa(MAX_DMA_ADDRESS));
> +
> return __pa(p);
> }
I've looked more closely to the code that uses this function and it does
not seem to handle allocation error.
I can replace the panic with WARN(), but I think that panic() here is
appropriate.
Andrey, can you comment?
> @@ -211,6 +211,9 @@ static int __init iob_init(struct device_node *dn)
> iob_l2_base = memblock_alloc_try_nid_raw(1UL << 21, 1UL << 21,
> MEMBLOCK_LOW_LIMIT, 0x8000,
> NUMA_NO_NODE);
> + if (!iob_l2_base)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx
> max_addr=%x\n",
> + __func__, 1UL << 21, 1UL << 21, 0x8000);
>
> pr_info("IOBMAP L2 allocated at: %p\n", iob_l2_base);
This one is actually fixes my own mistake from one of the previous patches
that converted memblock_alloc_base() to memblock_alloc_try_nid_raw() without
adding the panic() (commit 47e382eb08cfa0199c4ea9f9cc73f1b48a3a4b1d
"powerpc: prefer memblock APIs returning virtual address")
> @@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long
> size, int nid)
> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> + if (!sparsemap_buf)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> from=%lx\n",
> + __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
> +
> sparsemap_buf_end = sparsemap_buf + size;
> }
This hunk was not needed as sparse can deal with this allocation failure.
Andrew, can you please add the below patch to as a fixup to "treewide: add
checks for the return value of memblock_alloc*()"?
>From 854f54b9d4fe52f477765b905a4b2c421d30f46e Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Thu, 31 Jan 2019 09:18:50 +0200
Subject: [PATCH] mm/sparse: don't panic if the allocation in
sparse_buffer_init fails
Addition of panic if memblock_alloc_try_nid_raw() call in
sparse_buffer_init() fails was over enthusiastic as
Re: System crash with perf_fuzzer (kernel: 5.0.0-rc3)
On Wed, Jan 30, 2019 at 07:36:48PM +0100, Jiri Olsa wrote: > On Fri, Jan 25, 2019 at 12:16:27PM +0530, Ravi Bangoria wrote: > > SNIP > > > [ 1432.176374] general protection fault: [#1] SMP PTI > > [ 1432.182253] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW > > 5.0.0-rc3-ravi-pfuzzer+ #1 > > > > [ 1432.192088] Hardware name: IBM CPU PLANAR > >-[8722xyz]-/00FL808, BIOS -[KOE162DUS-2.30]- 08/27/2018 > > [264/488] > > [ 1432.206120] RIP: 0010:perf_prepare_sample+0x8f/0x510 > > > > [ 1432.211679] Code: ff ff 41 f6 c4 01 0f 85 22 02 00 00 41 f6 c4 20 74 26 > > 4d 85 e4 0f 88 0c 01 00 00 4c 89 f6 4c 89 ff e8 f5 fe ff ff 49 89 45 70 > > <48> 8b 00 8d 04 c5 08 00 00 0 > > 0 66 01 43 06 41 f7 c4 00 04 00 00 74 > > > > [ 1432.232699] RSP: :95b3ff843a78 EFLAGS: 00010082 > > > > [ 1432.238548] RAX: 8d1217eb826cce00 RBX: 95b3ff843ad8 RCX: > > 001f > > [ 1432.246536] RDX: RSI: 355563e5 RDI: > > > > [ 1432.254522] RBP: 95b3ff843ab0 R08: d016493f3b42 R09: > > > > [ 1432.262508] R10: 95b3ff843a08 R11: R12: > > 800306e5 > > [ 1432.270495] R13: 95b3ff843bc0 R14: 95b3ff843b18 R15: > > 95b3f6b65800 > > > > [ 1432.278483] FS: () GS:95b3ff84() > > knlGS: > > [ 1432.287539] CS: 0010 DS: ES: CR0: 80050033 > > [ 1432.293969] CR2: 55bf7f768c90 CR3: 001fd220e005 CR4: > > 000606e0 > > [ 1432.301956] Call Trace: > > > > [ 1432.304697] > > > > > > [ 1432.306956] ? intel_pmu_drain_bts_buffer+0x194/0x230 > > > > > > [ 1432.312615] intel_pmu_drain_bts_buffer+0x160/0x230 > > > > > > [ 1432.318078] ? tick_nohz_irq_exit+0x31/0x40 > > > > > > [ 1432.322765] ? smp_call_function_single_interrupt+0x48/0xe0 > > [ 1432.328993] ? call_function_single_interrupt+0xf/0x20 > > [ 1432.334745] ? call_function_single_interrupt+0xa/0x20 > > > > [ 1432.340501] ? x86_schedule_events+0x1a0/0x2f0 > > > > > > [ 1432.345475] ? x86_pmu_commit_txn+0xb4/0x100 > > > > > > [ 1432.350258] ? find_busiest_group+0x47/0x5d0 > > > > > > [ 1432.355039] ? perf_event_set_state.part.42+0x12/0x50 > > > > > > [ 1432.360694] ? perf_mux_hrtimer_restart+0x40/0xb0 > > > > [ 1432.365960] intel_pmu_disable_event+0xae/0x100 > > > > [ 1432.371031] ? intel_pmu_disable_event+0xae/0x100 > > > > [ 1432.376297] x86_pmu_stop+0x7a/0xb0 > > > > [ 1432.380201] x86_pmu_del+0x57/0x120 > > > > > > [ 1432.384105] event_sched_out.isra.101+0x83/0x180 > > [ 1432.389272] group_sched_out.part.103+0x57/0xe0 > > > > [ 1432.394343] ctx_sched_out+0x188/0x240 > > > > [ 1432.398539] ctx_resched+0xa8/0xd0 > > > > [ 1432.402345] __perf_event_enable+0x193/0x1e0 > > > > [ 1432.407125] event_function+0x8e/0xc0 > > > > [ 1432.411222] remote_function+0x41/0x50
Re: [PATCH] can: flexcan: fix timeout when set small bitrate
On 1/31/19 7:58 AM, Joakim Zhang wrote: > From: Dong Aisheng > > Current we can meet timeout issue when setting a small bitrate > like 1 as follows: > root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1 > A link change request failed with some changes committed already. > Interface can0 may have been left with an inconsistent configuration, > please check. > RTNETLINK answers: Connection timed out Which SoC are you using? Which clock rate has the flexcan IP core? > It is caused by calling of flexcan_chip_unfreeze() timeout. > > Originally the code is using usleep_range(10, 20) for unfreeze operation, > but the patch (8badd65 can: flexcan: avoid calling usleep_range from > interrupt context) changed it into udelay(10) which is only a half delay > of before, there're also some other delay changes. > > After only changed unfreeze delay back to udelay(20), the issue is gone. > So other timeout values are kept the same as 8badd65 changed. Can you change FLEXCAN_TIMEOUT_US instead? > Signed-off-by: Dong Aisheng > Signed-off-by: Joakim Zhang > --- > drivers/net/can/flexcan.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c > index 2bca867bcfaa..1d3a9053bbeb 100644 > --- a/drivers/net/can/flexcan.c > +++ b/drivers/net/can/flexcan.c > @@ -530,7 +530,7 @@ static int flexcan_chip_unfreeze(struct flexcan_priv > *priv) > priv->write(reg, ®s->mcr); > > while (timeout-- && (priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK)) > - udelay(10); > + udelay(20); > > if (priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK) > return -ETIMEDOUT; > Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] usb: typec: tcpm: Correct the PPS out_volt calculation
On Wed, Jan 30, 2019 at 11:13:53AM +0800, Kyle Tso wrote:
> When Sink negotiates PPS, the voltage range of selected PPS APDO might
> not cover the previous voltage (out_volt). If the previous out_volt is
> lower than the new min_volt, the output voltage in RDO might be set to
> an invalid value. For instance, supposed that the previous voltage is
> 5V, and the new voltage range in the APDO is 7V-12V. Then the output
> voltage in the RDO should not be set to 5V which is lower than the
> possible min_volt 7V.
>
> Fix this by choosing the maximal value between the previous voltage and
> the new min_volt first. And ensure that this value will not exceed the
> new max_volt. The new out_volt will fall within the new voltage range
> while being the closest value compared to the previous out_volt.
>
> Signed-off-by: Kyle Tso
Fixes: c710d0bb76ff0 ("usb: typec: tcpm: Extend the matching rules on PPS APDO
selection")
Cc: stable...
Right? In any case:
Reviewed-by: Heikki Krogerus
> ---
> drivers/usb/typec/tcpm/tcpm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index f1d3e54210df..8f2af348bda5 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -2297,7 +2297,8 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
> pdo_pps_apdo_max_voltage(snk));
> port->pps_data.max_curr = min_pps_apdo_current(src, snk);
> port->pps_data.out_volt = min(port->pps_data.max_volt,
> - port->pps_data.out_volt);
> + max(port->pps_data.min_volt,
> + port->pps_data.out_volt));
> port->pps_data.op_curr = min(port->pps_data.max_curr,
>port->pps_data.op_curr);
> }
> --
> 2.20.1.495.gaa96b0ce6b-goog
thanks,
--
heikki
With due respect
Dear Friend, I know that this mail will come to you as a surprise as we have never met before, but need not to worry as I am contacting you independently of my investigation and no one is informed of this communication. I need your urgent assistance in transferring the sum of $11.3million immediately to your private account.The money has been here in our Bank lying dormant for years now without anybody coming for the claim of it. I want to release the money to you as the relative to our deceased customer (the account owner) who died a long with his supposed NEXT OF KIN since 16th October 2005. The Banking laws here does not allow such money to stay more than 14 years, because the money will be recalled to the Bank treasury account as unclaimed fund. By indicating your interest I will send you the full details on how the business will be executed. Please respond urgently and delete if you are not interested. Best Regards, Mr. Duna Wattara.
Re: [PATCH V11 1/4] dt-bindings: mmc: Add supports-cqe property
On Wed, 23 Jan 2019 at 20:30, Sowjanya Komatineni wrote: > > Add supports-cqe optional property for MMC hosts. > > This property is used to identify the specific host controller > supporting command queue. > > Signed-off-by: Sowjanya Komatineni > Reviewed-by: Thierry Reding Applied for next, thanks! Kind regards Uffe > --- > [V11]: Same as V10 > [V10]: This patch version moves supports-cqe property from vendor > specific MMC property to common MMC property. > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt > b/Documentation/devicetree/bindings/mmc/mmc.txt > index f5a0923b34ca..cdbcfd3a4ff2 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc.txt > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > @@ -62,6 +62,8 @@ Optional properties: >be referred to mmc-pwrseq-simple.txt. But now it's reused as a tunable > delay >waiting for I/O signalling and card power supply to be stable, regardless > of >whether pwrseq-simple is used. Default to 10ms if no available. > +- supports-cqe : The presence of this property indicates that the > corresponding > + MMC host controller supports HW command queue feature. > > *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers > line > polarity properties, we have to fix the meaning of the "normal" and > "inverted" > -- > 2.7.4 >
Re: [PATCH V11 3/4] mmc: sdhci: Add ADMA3 DMA support for V4 enabled host
On Wed, 23 Jan 2019 at 20:31, Sowjanya Komatineni wrote: > > Below are the supported DMA types in Host Control1 Register > with Version 4 enable > b'00 - SDMA > b'01 - Not Used > b'10 - ADMA2 > b'11 - ADMA2 or ADMA3 > > ADMA3 uses Command Descriptor to issue an SD command. > A multi-block data transfer is performed by using a pair of CMD > descriptor and ADMA2 descriptor. > > ADMA3 performs multiple of multi-block data transfer by using > Integrated Descriptor which is more suitable for Command Queuing > to fetch both Command and Transfer descriptors. > > Host Capabilities register indicates the supports of ADMA3 DMA. > > Signed-off-by: Sowjanya Komatineni > Acked-by: Adrian Hunter > Reviewed-by: Thierry Reding Applied for next, thanks! Kind regards Uffe > --- > [V11]: Fixed typo in commit message of this patch. > [V10]: Changes are same as V9 except this series has SDHCI core changes > into seperate patch > > drivers/mmc/host/sdhci.c | 9 - > drivers/mmc/host/sdhci.h | 2 ++ > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index a22e11a65658..c6afe793399e 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -3353,7 +3353,14 @@ void sdhci_cqe_enable(struct mmc_host *mmc) > > ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); > ctrl &= ~SDHCI_CTRL_DMA_MASK; > - if (host->flags & SDHCI_USE_64_BIT_DMA) > + /* > +* Host from V4.10 supports ADMA3 DMA type. > +* ADMA3 performs integrated descriptor which is more suitable > +* for cmd queuing to fetch both command and transfer descriptors. > +*/ > + if (host->v4_mode && (host->caps1 & SDHCI_CAN_DO_ADMA3)) > + ctrl |= SDHCI_CTRL_ADMA3; > + else if (host->flags & SDHCI_USE_64_BIT_DMA) > ctrl |= SDHCI_CTRL_ADMA64; > else > ctrl |= SDHCI_CTRL_ADMA32; > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h > index 6cc9a3c2ac66..4070be49d947 100644 > --- a/drivers/mmc/host/sdhci.h > +++ b/drivers/mmc/host/sdhci.h > @@ -88,6 +88,7 @@ > #define SDHCI_CTRL_ADMA1 0x08 > #define SDHCI_CTRL_ADMA320x10 > #define SDHCI_CTRL_ADMA640x18 > +#define SDHCI_CTRL_ADMA3 0x18 > #define SDHCI_CTRL_8BITBUS 0x20 > #define SDHCI_CTRL_CDTEST_INS 0x40 > #define SDHCI_CTRL_CDTEST_EN 0x80 > @@ -230,6 +231,7 @@ > #define SDHCI_RETUNING_MODE_SHIFT 14 > #define SDHCI_CLOCK_MUL_MASK 0x00FF > #define SDHCI_CLOCK_MUL_SHIFT 16 > +#define SDHCI_CAN_DO_ADMA30x0800 > #define SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */ > > #define SDHCI_CAPABILITIES_1 0x44 > -- > 2.7.4 >
Re: [PATCH V11 2/4] arm64: dts: tegra: Add CQE Support for SDMMC4
On Wed, 23 Jan 2019 at 20:30, Sowjanya Komatineni wrote: > > Add CQE Support for Tegra186 and Tegra194 SDMMC4 controller > > Signed-off-by: Sowjanya Komatineni To be clear, I am not picking this one as this should go via arm-soc. Kind regards Uffe > --- > arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 + > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi > b/arch/arm64/boot/dts/nvidia/tegra186.dtsi > index 22815db4a3ed..3dfdc4701934 100644 > --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi > +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi > @@ -319,6 +319,7 @@ > nvidia,default-trim = <0x9>; > nvidia,dqs-trim = <63>; > mmc-hs400-1_8v; > + supports-cqe; > status = "disabled"; > }; > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi > b/arch/arm64/boot/dts/nvidia/tegra194.dtsi > index 6dfa1ca0b851..9ce1c91d4596 100644 > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi > @@ -325,6 +325,7 @@ > clock-names = "sdhci"; > resets = <&bpmp TEGRA194_RESET_SDMMC4>; > reset-names = "sdhci"; > + supports-cqe; > status = "disabled"; > }; > > -- > 2.7.4 >
Re: [PATCH V11 4/4] mmc: tegra: HW Command Queue Support for Tegra SDMMC
On Wed, 23 Jan 2019 at 20:31, Sowjanya Komatineni
wrote:
>
> This patch adds HW Command Queue for supported Tegra SDMMC
> controllers.
>
> Signed-off-by: Sowjanya Komatineni
> Acked-by: Adrian Hunter
> Acked-by: Thierry Reding
Applied for next, thanks!
Kind regards
Uffe
> ---
> [v11]: Same as V10
> [V10]: Changes are same as V9 except this series has SDHCI core changes
> into seperate patch
>
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-tegra.c | 117
> +++--
> 2 files changed, 114 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index e26b8145efb3..0739d26c001b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -250,6 +250,7 @@ config MMC_SDHCI_TEGRA
> depends on ARCH_TEGRA
> depends on MMC_SDHCI_PLTFM
> select MMC_SDHCI_IO_ACCESSORS
> + select MMC_CQHCI
> help
> This selects the Tegra SD/MMC controller. If you have a Tegra
> platform with SD or MMC devices, say Y or M here.
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index e6ace31e2a41..d400f158bee4 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -33,6 +33,7 @@
> #include
>
> #include "sdhci-pltfm.h"
> +#include "cqhci.h"
>
> /* Tegra SDHOST controller vendor register definitions */
> #define SDHCI_TEGRA_VENDOR_CLOCK_CTRL 0x100
> @@ -89,6 +90,9 @@
> #define NVQUIRK_NEEDS_PAD_CONTROL BIT(7)
> #define NVQUIRK_DIS_CARD_CLK_CONFIG_TAPBIT(8)
>
> +/* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
> +#define SDHCI_TEGRA_CQE_BASE_ADDR 0xF000
> +
> struct sdhci_tegra_soc_data {
> const struct sdhci_pltfm_data *pdata;
> u32 nvquirks;
> @@ -128,6 +132,7 @@ struct sdhci_tegra {
> u32 default_tap;
> u32 default_trim;
> u32 dqs_trim;
> + bool enable_hwcq;
> };
>
> static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
> @@ -595,6 +600,20 @@ static void tegra_sdhci_parse_tap_and_trim(struct
> sdhci_host *host)
> tegra_host->dqs_trim = 0x11;
> }
>
> +static void tegra_sdhci_parse_dt(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
> +
> + if (device_property_read_bool(host->mmc->parent, "supports-cqe"))
> + tegra_host->enable_hwcq = true;
> + else
> + tegra_host->enable_hwcq = false;
> +
> + tegra_sdhci_parse_pad_autocal_dt(host);
> + tegra_sdhci_parse_tap_and_trim(host);
> +}
> +
> static void tegra_sdhci_set_clock(struct sdhci_host *host, unsigned int
> clock)
> {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> @@ -836,6 +855,49 @@ static void tegra_sdhci_voltage_switch(struct sdhci_host
> *host)
> tegra_host->pad_calib_required = true;
> }
>
> +static void sdhci_tegra_cqe_enable(struct mmc_host *mmc)
> +{
> + struct cqhci_host *cq_host = mmc->cqe_private;
> + u32 cqcfg = 0;
> +
> + /*
> +* Tegra SDMMC Controller design prevents write access to BLOCK_COUNT
> +* registers when CQE is enabled.
> +*/
> + cqcfg = cqhci_readl(cq_host, CQHCI_CFG);
> + if (cqcfg & CQHCI_ENABLE)
> + cqhci_writel(cq_host, (cqcfg & ~CQHCI_ENABLE), CQHCI_CFG);
> +
> + sdhci_cqe_enable(mmc);
> +
> + if (cqcfg & CQHCI_ENABLE)
> + cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
> +}
> +
> +static void sdhci_tegra_dumpregs(struct mmc_host *mmc)
> +{
> + sdhci_dumpregs(mmc_priv(mmc));
> +}
> +
> +static u32 sdhci_tegra_cqhci_irq(struct sdhci_host *host, u32 intmask)
> +{
> + int cmd_error = 0;
> + int data_error = 0;
> +
> + if (!sdhci_cqe_irq(host, intmask, &cmd_error, &data_error))
> + return intmask;
> +
> + cqhci_irq(host->mmc, intmask, cmd_error, data_error);
> +
> + return 0;
> +}
> +
> +static const struct cqhci_host_ops sdhci_tegra_cqhci_ops = {
> + .enable = sdhci_tegra_cqe_enable,
> + .disable = sdhci_cqe_disable,
> + .dumpregs = sdhci_tegra_dumpregs,
> +};
> +
> static const struct sdhci_ops tegra_sdhci_ops = {
> .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> @@ -989,6 +1051,7 @@ static const struct sdhci_ops tegra186_sdhci_ops = {
> .set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
> .voltage_switch = tegra_sdhci_voltage_switch,
> .get_max_clock = tegra_sdhci_get_max_clock,
> + .irq = sdhci_tegra_cqhci_irq,
> };
>
> static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
> @@ -1030,6 +1093,54 @@ static const struct of_device_id
> sdhci_tegra_dt_match[] = {
> };
> MODULE_DEVICE_TABLE
Re: [PATCH V2 3/4] irq: imx-irqsteer: change to use reg_num instead of irq_group
On Wed, Jan 30, 2019 at 9:23 PM Lucas Stach wrote:
[...]
> > > + /* one register bit map represents 32 input interrupts */
> > > + data->reg_num /= 32;
> > +
> > > if (IS_ENABLED(CONFIG_PM_SLEEP)) {
> > > data->saved_reg = devm_kzalloc(&pdev->dev,
> > > - sizeof(u32) * data->irq_groups * 2,
> > > + sizeof(u32) * data->reg_num,
> > GFP_KERNEL);
>
> Does this last parameter now fit on the line above?
>
No, 81 now. :)
Regards
Dong Aisheng
Re: [PATCH v2 1/5] PM / OPP: Introduce a power estimation helper
On 30-01-19, 17:05, Quentin Perret wrote:
> +static int __maybe_unused _get_cpu_power(unsigned long *mW, unsigned long
> *kHz,
> + int cpu)
> +{
> + struct device *cpu_dev;
> + struct dev_pm_opp *opp;
> + struct device_node *np;
> + unsigned long mV, Hz;
> + u32 cap;
> + u64 tmp;
> + int ret;
> +
> + cpu_dev = get_cpu_device(cpu);
> + if (!cpu_dev)
> + return -ENODEV;
> +
> + np = of_node_get(cpu_dev->of_node);
> + if (!np)
> + return -EINVAL;
> +
> + ret = of_property_read_u32(np, "dynamic-power-coefficient", &cap);
> + of_node_put(np);
> + if (ret)
> + return -EINVAL;
> +
> + Hz = *kHz * 1000;
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &Hz);
> + if (IS_ERR(opp))
> + return -EINVAL;
> +
> + mV = dev_pm_opp_get_voltage(opp) / 1000;
The voltage is also stored as triplet now a days and we must consider
the higher value for these calculations. Also what about the case of
multiple regulators here or performance-states ?
> + dev_pm_opp_put(opp);
> + if (!mV)
> + return -EINVAL;
> +
> + tmp = (u64)cap * mV * mV * (Hz / 100);
> + do_div(tmp, 10);
> +
> + *mW = (unsigned long)tmp;
I was thinking will it be better if we just save this information in
opp->power field during init, so we can just read a value here
instead. But I am still not sure :(
> + *kHz = Hz / 1000;
> +
> + return 0;
> +}
> +
> +/**
> + * dev_pm_opp_of_register_em() - Attempt to register an Energy Model
> + * @cpus : CPUs for which an Energy Model has to be registered
> + * @nr_opp : Number of OPPs to register in the Energy Model
> + *
> + * This checks whether the "dynamic-power-coefficient" devicetree binding has
> + * been specified, and tries to register an Energy Model with it if it has.
> + */
> +void dev_pm_opp_of_register_em(struct cpumask *cpus, int nr_opp)
> +{
> + struct em_data_callback em_cb = EM_DATA_CB(_get_cpu_power);
> + int ret, cpu = cpumask_first(cpus);
> + struct device *cpu_dev;
> + struct device_node *np;
> + u32 cap;
> +
> + cpu_dev = get_cpu_device(cpu);
> + if (!cpu_dev)
> + return;
> +
> + np = of_node_get(cpu_dev->of_node);
> + if (!np)
> + return;
> +
> + /* Don't register an EM without the right DT binding */
> + ret = of_property_read_u32(np, "dynamic-power-coefficient", &cap);
> + of_node_put(np);
> + if (ret || !cap)
> + return;
What if no voltage is supplied in DT ?
> +
> + em_register_perf_domain(cpus, nr_opp, &em_cb);
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index b895f4e79868..58ae08b024bd 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -327,6 +327,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device
> *cpu_dev, struct cpumask *cpuma
> struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
> struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
> int of_get_required_opp_performance_state(struct device_node *np, int index);
> +void dev_pm_opp_of_register_em(struct cpumask *cpus, int nr_opp);
> #else
> static inline int dev_pm_opp_of_add_table(struct device *dev)
> {
> @@ -365,6 +366,11 @@ static inline struct device_node
> *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> {
> return NULL;
> }
> +
> +static inline void dev_pm_opp_of_register_em(struct cpumask *cpus, int
> nr_opp)
> +{
> +}
> +
> static inline int of_get_required_opp_performance_state(struct device_node
> *np, int index)
> {
> return -ENOTSUPP;
> --
> 2.20.1
--
viresh
Re: [RFC PATCH v2 0/4] mm, memory_hotplug: allocate memmap from hotadded memory
On Wed 30-01-19 22:52:04, Oscar Salvador wrote: > On Tue, Jan 22, 2019 at 11:37:04AM +0100, Oscar Salvador wrote: > > I yet have to check a couple of things like creating an accounting item > > like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the memory that > > went in there, testing Hyper-V/Xen to see how they react to the fact that > > we are using the beginning of the memory-range for our own purposes, and to > > check the thing about gigantic pages + hotplug. > > I also have to check that there is no compilation/runtime errors when > > CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. > > But before that, I would like to get people's feedback about the overall > > design, and ideas/suggestions. > > just a friendly reminder if some feedback is possible :-) I will be off next week and will not get to this this week. -- Michal Hocko SUSE Labs
Re: [PATCH v2 1/5] PM / OPP: Introduce a power estimation helper
On 30-01-19, 11:07, Matthias Kaehlcke wrote: > On Wed, Jan 30, 2019 at 05:05:02PM +, Quentin Perret wrote: > > +static int __maybe_unused _get_cpu_power(unsigned long *mW, unsigned long > > *kHz, > > +int cpu) > > why __maybe_unused? Yeah, it isn't required I think. He probably added it for the case where CONFIG_ENERGY_MODEL=n, but even then an inline routine is defined which will accept it as argument and wouldn't do anything with it. Had it been a macro, we would have required __maybe_unused but not now. -- viresh
Re: [PATCH 4.20 000/117] 4.20.6-stable review
On Wed, Jan 30, 2019 at 02:14:35PM -0800, Guenter Roeck wrote: > On Tue, Jan 29, 2019 at 12:34:11PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.6 release. > > There are 117 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jan 31 11:31:34 UTC 2019. > > Anything received after that time might be too late. > > > > For v4.20.5-119-gef18d4260339: > > Build results: > total: 159 pass: 159 fail: 0 > Qemu test results: > total: 343 pass: 343 fail: 0 Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Thu, Jan 31, 2019 at 08:07:29AM +0100, Christophe Leroy wrote:
>
>
> Le 31/01/2019 à 07:44, Christophe Leroy a écrit :
> >
> >
> >Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
> >>On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
> >>>
> >>>
> >>>Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock
> allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: Guo Ren # c-sky
> Acked-by: Paul Burton # MIPS
> Acked-by: Heiko Carstens # s390
> Reviewed-by: Juergen Gross # Xen
> ---
> >>>
> >>>[...]
> >>>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 7ea5dc6..ad94242 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> >>>
> >>>[...]
> >>>
> @@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned
> long size, int nid)
> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> + if (!sparsemap_buf)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> from=%lx\n",
> + __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
> +
> >>>
> >>>memblock_alloc_try_nid_raw() does not panic (help explicitly says:
> >>>Does not
> >>>zero allocated memory, does not panic if request cannot be satisfied.).
> >>
> >>"Does not panic" does not mean it always succeeds.
> >
> >I agree, but at least here you are changing the behaviour by making it
> >panic explicitly. Are we sure there are not cases where the system could
> >just continue functionning ? Maybe a WARN_ON() would be enough there ?
>
> Looking more in details, it looks like everything is done to live with
> sparsemap_buf NULL, all functions using it check it so having it NULL
> shouldn't imply a panic I believe, see code below.
You are right, I'm preparing the fix right now.
> static void *sparsemap_buf __meminitdata;
> static void *sparsemap_buf_end __meminitdata;
>
> static void __init sparse_buffer_init(unsigned long size, int nid)
> {
> WARN_ON(sparsemap_buf); /* forgot to call sparse_buffer_fini()? */
> sparsemap_buf =
> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> sparsemap_buf_end = sparsemap_buf + size;
> }
>
> static void __init sparse_buffer_fini(void)
> {
> unsigned long size = sparsemap_buf_end - sparsemap_buf;
>
> if (sparsemap_buf && size > 0)
> memblock_free_early(__pa(sparsemap_buf), size);
> sparsemap_buf = NULL;
> }
>
> void * __meminit sparse_buffer_alloc(unsigned long size)
> {
> void *ptr = NULL;
>
> if (sparsemap_buf) {
> ptr = PTR_ALIGN(sparsemap_buf, size);
> if (ptr + size > sparsemap_buf_end)
> ptr = NULL;
> else
> sparsemap_buf = ptr + size;
> }
> return ptr;
> }
>
>
> Christophe
>
--
Sincerely yours,
Mike.
Re: linux-next: powerpc le qemu boot failure after merge of the akpm tree
Hi Mike, On Thu, 31 Jan 2019 08:39:30 +0200 Mike Rapoport wrote: > > On Thu, Jan 31, 2019 at 07:15:26AM +0100, Christophe Leroy wrote: > > > > Le 31/01/2019 à 07:06, Stephen Rothwell a écrit : > > >>My qemu boot of the powerpc pseries_le_defconfig config failed like this: > > >> > > >>htab_hash_mask= 0x1 > > >>- > > >>numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff] > > >>Kernel panic - not syncing: sparse_buffer_init: Failed to allocate > > >>2147483648 bytes align=0x1 nid=0 from=fff > > This means that sparse_buffer_init tries to allocate 2G for the > sparsemap_buf... > > Stephen, how many memory do you give to your VM? Exactly 2G. qemu-system-ppc64 -M pseries -m 2G The boot normally continue like this: rfi-flush: fallback displacement flush available count-cache-flush: software flush disabled. stf-barrier: hwsync barrier available PCI host bridge /pci@8002000 ranges: IO 0x2000..0x2000 -> 0x MEM 0x20008000..0x2000 -> 0x8000 MEM 0x2100..0x21ff -> 0x2100 PPC64 nvram contains 65536 bytes barrier-nospec: using ORI speculation barrier Zone ranges: Normal [mem 0x-0x7fff] Movable zone start for each node Early memory node ranges node 0: [mem 0x-0x7fff] Initmem setup node 0 [mem 0x-0x7fff] -- Cheers, Stephen Rothwell pgpMjX3L_pwYU.pgp Description: OpenPGP digital signature
Re: [PATCH v2] mm, oom: Tolerate processes sharing mm with different view of oom_score_adj.
On Thu 31-01-19 07:49:35, Tetsuo Handa wrote:
> This patch reverts both commit 44a70adec910d692 ("mm, oom_adj: make sure
> processes sharing mm have same view of oom_score_adj") and commit
> 97fd49c2355ffded ("mm, oom: kill all tasks sharing the mm") in order to
> close a race and reduce the latency at __set_oom_adj(), and reduces the
> warning at __oom_kill_process() in order to minimize the latency.
>
> Commit 36324a990cf578b5 ("oom: clear TIF_MEMDIE after oom_reaper managed
> to unmap the address space") introduced the worst case mentioned in
> 44a70adec910d692. But since the OOM killer skips mm with MMF_OOM_SKIP set,
> only administrators can trigger the worst case.
>
> Since 44a70adec910d692 did not take latency into account, we can "hold RCU
> for minutes and trigger RCU stall warnings" by calling printk() on many
> thousands of thread groups. Also, current code becomes a DoS attack vector
> which will allow "stalling for more than one month in unkillable state"
> simply printk()ing same messages when many thousands of thread groups
> tried to iterate __set_oom_adj() on each other.
>
> I also noticed that 44a70adec910d692 is racy [1], and trying to fix the
> race will require a global lock which is too costly for rare events. And
> Michal Hocko is thinking to change the oom_score_adj implementation to per
> mm_struct (with shadowed score stored in per task_struct in order to
> support vfork() => __set_oom_adj() => execve() sequence) so that we don't
> need the global lock.
>
> If the worst case in 44a70adec910d692 happened, it is an administrator's
> request. Therefore, before changing the oom_score_adj implementation,
> let's eliminate the DoS attack vector first.
This is really ridiculous. I have already nacked the previous version
and provided two ways around. The simplest one is to drop the printk.
The second one is to move oom_score_adj to the mm struct. Could you
explain why do you still push for this?
> [1]
> https://lkml.kernel.org/r/20181008011931epcms1p82dd01b7e5c067ea99946418bc97de46a@epcms1p8
>
> Signed-off-by: Tetsuo Handa
> Reported-by: Yong-Taek Lee
> Nacked-by: Michal Hocko
> ---
> fs/proc/base.c | 46 --
> include/linux/mm.h | 2 --
> mm/oom_kill.c | 10 ++
> 3 files changed, 6 insertions(+), 52 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 633a634..41ece8f 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1020,7 +1020,6 @@ static ssize_t oom_adj_read(struct file *file, char
> __user *buf, size_t count,
> static int __set_oom_adj(struct file *file, int oom_adj, bool legacy)
> {
> static DEFINE_MUTEX(oom_adj_mutex);
> - struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
>
> @@ -1050,55 +1049,10 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> }
> }
>
> - /*
> - * Make sure we will check other processes sharing the mm if this is
> - * not vfrok which wants its own oom_score_adj.
> - * pin the mm so it doesn't go away and get reused after task_unlock
> - */
> - if (!task->vfork_done) {
> - struct task_struct *p = find_lock_task_mm(task);
> -
> - if (p) {
> - if (atomic_read(&p->mm->mm_users) > 1) {
> - mm = p->mm;
> - mmgrab(mm);
> - }
> - task_unlock(p);
> - }
> - }
> -
> task->signal->oom_score_adj = oom_adj;
> if (!legacy && has_capability_noaudit(current, CAP_SYS_RESOURCE))
> task->signal->oom_score_adj_min = (short)oom_adj;
> trace_oom_score_adj_update(task);
> -
> - if (mm) {
> - struct task_struct *p;
> -
> - rcu_read_lock();
> - for_each_process(p) {
> - if (same_thread_group(task, p))
> - continue;
> -
> - /* do not touch kernel threads or the global init */
> - if (p->flags & PF_KTHREAD || is_global_init(p))
> - continue;
> -
> - task_lock(p);
> - if (!p->vfork_done && process_shares_mm(p, mm)) {
> - pr_info("updating oom_score_adj for %d (%s)
> from %d to %d because it shares mm with %d (%s). Report if this is
> unexpected.\n",
> - task_pid_nr(p), p->comm,
> - p->signal->oom_score_adj,
> oom_adj,
> - task_pid_nr(task), task->comm);
> - p->signal->oom_score_adj = oom_adj;
> - if (!legacy && has_capability_noaudit(current,
> CAP_SYS_RESOURCE))
> - p->signal->oom_score_adj_min =
> (short)oom_adj;
> -
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
Le 31/01/2019 à 07:44, Christophe Leroy a écrit :
Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock
allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren # c-sky
Acked-by: Paul Burton # MIPS
Acked-by: Heiko Carstens # s390
Reviewed-by: Juergen Gross # Xen
---
[...]
diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
[...]
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned
long size, int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
memblock_alloc_try_nid_raw() does not panic (help explicitly says:
Does not
zero allocated memory, does not panic if request cannot be satisfied.).
"Does not panic" does not mean it always succeeds.
I agree, but at least here you are changing the behaviour by making it
panic explicitly. Are we sure there are not cases where the system could
just continue functionning ? Maybe a WARN_ON() would be enough there ?
Looking more in details, it looks like everything is done to live with
sparsemap_buf NULL, all functions using it check it so having it NULL
shouldn't imply a panic I believe, see code below.
static void *sparsemap_buf __meminitdata;
static void *sparsemap_buf_end __meminitdata;
static void __init sparse_buffer_init(unsigned long size, int nid)
{
WARN_ON(sparsemap_buf); /* forgot to call sparse_buffer_fini()? */
sparsemap_buf =
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
sparsemap_buf_end = sparsemap_buf + size;
}
static void __init sparse_buffer_fini(void)
{
unsigned long size = sparsemap_buf_end - sparsemap_buf;
if (sparsemap_buf && size > 0)
memblock_free_early(__pa(sparsemap_buf), size);
sparsemap_buf = NULL;
}
void * __meminit sparse_buffer_alloc(unsigned long size)
{
void *ptr = NULL;
if (sparsemap_buf) {
ptr = PTR_ALIGN(sparsemap_buf, size);
if (ptr + size > sparsemap_buf_end)
ptr = NULL;
else
sparsemap_buf = ptr + size;
}
return ptr;
}
Christophe
Re: [PATCH] usb: typec: tcpm: Export partner Source Capabilities
On Thu, Jan 31, 2019 at 11:54:11AM +0800, Kyle Tso wrote:
> Provide a function to get the partner Source Capabilities.
>
> Signed-off-by: Kyle Tso
> ---
> drivers/usb/typec/tcpm/tcpm.c | 23 +++
> include/linux/usb/tcpm.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index f1d3e54210df..29cd84ba9960 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -4494,6 +4494,29 @@ int tcpm_update_sink_capabilities(struct tcpm_port
> *port, const u32 *pdo,
> }
> EXPORT_SYMBOL_GPL(tcpm_update_sink_capabilities);
>
> +/*
> + * Don't call this function in interrupt context. Caller needs to free the
> + * memory itself.
> + */
> +int tcpm_get_partner_src_caps(struct tcpm_port *port, u32 **src_pdo)
> +{
> + unsigned int nr_pdo;
> +
> + if (port->nr_source_caps == 0)
> + return -ENODATA;
> +
> + *src_pdo = kcalloc(port->nr_source_caps, sizeof(u32), GFP_KERNEL);
> + if (!src_pdo)
> + return -ENOMEM;
> +
> + mutex_lock(&port->lock);
> + nr_pdo = tcpm_copy_pdos(*src_pdo, port->source_caps,
> + port->nr_source_caps);
> + mutex_unlock(&port->lock);
> + return nr_pdo;
> +}
> +EXPORT_SYMBOL_GPL(tcpm_get_partner_src_caps);
We don't add new functions that no one uses :(
[PATCH] csky: fixup dead loop in show_stack
From: Guo Ren
When STACKTRACE is enabled, we must pass fp as stack for unwind,
otherwise random value in stack will casue a dead loop.
Signed-off-by: Guo Ren
Reported-by: Lu Baoquan
---
arch/csky/kernel/dumpstack.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/csky/kernel/dumpstack.c b/arch/csky/kernel/dumpstack.c
index 659253e..d67f977 100644
--- a/arch/csky/kernel/dumpstack.c
+++ b/arch/csky/kernel/dumpstack.c
@@ -38,7 +38,11 @@ void show_stack(struct task_struct *task, unsigned long
*stack)
if (task)
stack = (unsigned long *)thread_saved_fp(task);
else
+#ifdef CONFIG_STACKTRACE
+ asm volatile("mov %0, r8\n":"=r"(stack)::"memory");
+#else
stack = (unsigned long *)&stack;
+#endif
}
show_trace(stack);
--
2.7.4
Re: general protection fault in debugfs_create_files
On Thu, Jan 31, 2019 at 02:34:56PM +0900, Tetsuo Handa wrote:
> Hello, again.
>
> syzbot is hitting a similar crash due to debugfs_create_dir() returning
> -EEXIST.
> Should debugfs_create_dir() return NULL as well? Or should the caller use
> IS_ERR_OR_NULL() ?
>
> --- a/block/blk-mq-debugfs.c
> +++ b/block/blk-mq-debugfs.c
> @@ -861,6 +861,8 @@ int blk_mq_debugfs_register(struct request_queue *q)
> blk_debugfs_root);
> if (!q->debugfs_dir)
> return -ENOMEM;
> + if (IS_ERR(q->debugfs_dir))
> + printk("debugfs_create_dir=%ld\n", PTR_ERR(q->debugfs_dir));
>
> if (!debugfs_create_files(q->debugfs_dir, q,
> blk_mq_debugfs_queue_attrs))
>
I already posted this patch last Wednesday:
https://lore.kernel.org/lkml/20190123134854.ga25...@kroah.com/
to solve this problem.
I guess I should queue it up in my tree as well, to handle this issue.
I'll go do that now.
thanks,
greg k-h
Re: [PATCH] powerpc/prom_init: add __init markers to all functions
Hi Masahiro,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190130]
[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/Masahiro-Yamada/powerpc-prom_init-add-__init-markers-to-all-functions/20190131-134035
config: powerpc-mpc837x_mds_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> arch/powerpc/kernel/prom_init.c:511:19: error: 'prom_getproplen' defined but
>> not used [-Werror=unused-function]
static int __init prom_getproplen(phandle node, const char *pname)
^~~
cc1: all warnings being treated as errors
vim +/prom_getproplen +511 arch/powerpc/kernel/prom_init.c
510
> 511 static int __init prom_getproplen(phandle node, const char *pname)
512 {
513 return call_prom("getproplen", 2, 1, node, ADDR(pname));
514 }
515
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v6 06/20] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
On Wed, 2019-01-30 at 10:28 -0800, Evan Green wrote:
> On Mon, Dec 31, 2018 at 7:57 PM Yong Wu wrote:
> >
> > MediaTek extend the arm v7s descriptor to support the dram over 4GB.
> >
> > In the mt2712 and mt8173, it's called "4GB mode", the physical address
> > is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
> > is remapped to high address from 0x1__ to 0x1__, the
> > bit32 is always enabled. thus, in the M4U, we always enable the bit9
> > for all PTEs which means to enable bit32 of physical address.
>
> I got a little lost here. I get that you're trying to explain why you
> always used to set bit32 of the physical address. But I don't totally
> get the part about physical addresses being from 0x4000_ -
> 0x1_3fff_, but also from 0x1__-0x1__. Are you
> saying that the physical addresses from the iommu's perspective were
> always >0x1__?
Yes. From the IOMMU's perspective, the Physical address is from
0x1__ to 0x1__.
> But then from whose perspective is it 0x4000_? ...
I guess from SW point view. it is from 0x4000_ to 0x1_3fff_.
If 4GB mode is enabled, the memory property in dts like this:
memory@4000 {
device_type = "memory";
reg = <0 0x4000 0x0001 0x>;
};
> oh, or you're saying there was some sort of remapping
> facility that moved the physical addresses around?
>
> >
> > but in mt8183, M4U support the dram from 0x4000_ to 0x3__
> > which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
> > PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
> > 32bits.
> >
> > In order to unify code, in the "4GB mode", we add the bit32 for the
> > physical address manually in our driver.
> >
> > Correspondingly, Adding bit32 and bit33 for the PA in the iova_to_phys
> > has to been moved into v7s.
> >
> > Regarding whether the pagetable address could be over 4GB, the mt8183
> > support it while the previous mt8173 don't. thus keep it as is.
> >
> > Signed-off-by: Yong Wu
> > Reviewed-by: Robin Murphy
> > ---
> > drivers/iommu/io-pgtable-arm-v7s.c | 31 ---
> > drivers/iommu/io-pgtable.h | 7 +++
> > drivers/iommu/mtk_iommu.c | 14 --
> > drivers/iommu/mtk_iommu.h | 1 +
> > 4 files changed, 36 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> > b/drivers/iommu/io-pgtable-arm-v7s.c
> > index 11d8505..8803a35 100644
> > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > @@ -124,7 +124,9 @@
> > #define ARM_V7S_TEX_MASK 0x7
> > #define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) <<
> > ARM_V7S_TEX_SHIFT)
> >
> > -#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for 4GB
> > mode */
> > +/* MediaTek extend the two bits below for over 4GB mode */
> > +#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
> > +#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
>
> If other vendors start doing stuff like this we'll need a more generic
> way to handle this... but I guess until we see a pattern this is okay.
>
> >
> > /* *well, except for TEX on level 2 large pages, of course :( */
> > #define ARM_V7S_CONT_PAGE_TEX_SHIFT6
> > @@ -183,13 +185,22 @@ static dma_addr_t __arm_v7s_dma_addr(void *pages)
> > static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
> > struct io_pgtable_cfg *cfg)
> > {
> > - return paddr & ARM_V7S_LVL_MASK(lvl);
> > + arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
> > +
> > + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
> > + if (paddr & BIT_ULL(32))
> > + pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
> > + if (paddr & BIT_ULL(33))
> > + pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
> > + }
> > + return pte;
> > }
> >
> > static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
> > struct io_pgtable_cfg *cfg)
> > {
> > arm_v7s_iopte mask;
> > + phys_addr_t paddr;
> >
> > if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
> > mask = ARM_V7S_TABLE_MASK;
> > @@ -198,7 +209,14 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte,
> > int lvl,
> > else
> > mask = ARM_V7S_LVL_MASK(lvl);
> >
> > - return pte & mask;
> > + paddr = pte & mask;
> > + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
> > + if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > + paddr |= BIT_ULL(32);
> > + if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
> > + paddr |= BIT_ULL(33);
> > + }
> > + return paddr;
> > }
> >
> > static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
> > @@ -315,9 +333,6 @@ static arm_v7s_iopte arm_v7s
[PATCH] can: flexcan: fix timeout when set small bitrate
From: Dong Aisheng Current we can meet timeout issue when setting a small bitrate like 1 as follows: root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1 A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check. RTNETLINK answers: Connection timed out It is caused by calling of flexcan_chip_unfreeze() timeout. Originally the code is using usleep_range(10, 20) for unfreeze operation, but the patch (8badd65 can: flexcan: avoid calling usleep_range from interrupt context) changed it into udelay(10) which is only a half delay of before, there're also some other delay changes. After only changed unfreeze delay back to udelay(20), the issue is gone. So other timeout values are kept the same as 8badd65 changed. Signed-off-by: Dong Aisheng Signed-off-by: Joakim Zhang --- drivers/net/can/flexcan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index 2bca867bcfaa..1d3a9053bbeb 100644 --- a/drivers/net/can/flexcan.c +++ b/drivers/net/can/flexcan.c @@ -530,7 +530,7 @@ static int flexcan_chip_unfreeze(struct flexcan_priv *priv) priv->write(reg, ®s->mcr); while (timeout-- && (priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK)) - udelay(10); + udelay(20); if (priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK) return -ETIMEDOUT; -- 2.17.1
Re: 答复: 答复: [PATCH][v4] tty: fix race between flush_to_ldisc and tty_open
On Thu, Jan 31, 2019 at 02:15:35AM +, Li,Rongqing wrote:
>
>
> > -邮件原件-
> > 发件人: Greg KH [mailto:gre...@linuxfoundation.org]
> > 发送时间: 2019年1月30日 21:17
> > 收件人: Li,Rongqing
> > 抄送: jsl...@suse.com; linux-kernel@vger.kernel.org; gko...@codeaurora.org;
> > linux-ser...@vger.kernel.org
> > 主题: Re: 答复: [PATCH][v4] tty: fix race between flush_to_ldisc and tty_open
> >
> > On Wed, Jan 30, 2019 at 12:48:42PM +, Li,Rongqing wrote:
> > >
> > >
> > > > -邮件原件-
> > > > 发件人: linux-kernel-ow...@vger.kernel.org
> > > > [mailto:linux-kernel-ow...@vger.kernel.org] 代表 Greg KH
> > > > 发送时间: 2019年1月30日 18:19
> > > > 收件人: Li,Rongqing
> > > > 抄送: jsl...@suse.com; linux-kernel@vger.kernel.org;
> > > > gko...@codeaurora.org
> > > > 主题: Re: [PATCH][v4] tty: fix race between flush_to_ldisc and
> > > > tty_open
> > > >
> > > > On Fri, Jan 18, 2019 at 05:27:17PM +0800, Li RongQing wrote:
> > > > > There still is a race window after the commit b027e2298bd588
> > > > > ("tty: fix data race between tty_init_dev and flush of buf"), and
> > > > > we encountered this crash issue if receive_buf call comes before
> > > > > tty initialization completes in n_tty_open and
> > > > > tty->driver_data may be NULL.
> > > > >
> > > > > CPU0CPU1
> > > > >
> > > > > n_tty_open
> > > > >tty_init_dev
> > > > > tty_ldisc_unlock
> > > > >schedule flush_to_ldisc
> > > > > receive_buf
> > > > > tty_port_default_receive_buf
> > > > >tty_ldisc_receive_buf
> > > > > n_tty_receive_buf_common
> > > > > __receive_buf
> > > > >uart_flush_chars
> > > > > uart_start
> > > > > /*tty->driver_data is NULL*/
> > > > >tty->ops->open
> > > > >/*init tty->driver_data*/
> > > > >
> > > > > it can be fixed by extending ldisc semaphore lock in tty_init_dev
> > > > > to driver_data initialized completely after tty->ops->open(), but
> > > > > this will lead to put lock on one function and unlock in some
> > > > > other function, and hard to maintain, so fix this race only by
> > > > > checking
> > > > > tty->driver_data when receiving, and return if tty->driver_data
> > > > > is NULL
> > > > >
> > > > > Signed-off-by: Wang Li
> > > > > Signed-off-by: Zhang Yu
> > > > > Signed-off-by: Li RongQing
> > > > > ---
> > > > > V4: add version information
> > > > > V3: not used ldisc semaphore lock, only checking tty->driver_data
> > > > > with NULL
> > > > > V2: fix building error by EXPORT_SYMBOL tty_ldisc_unlock
> > > > > V1: extend ldisc lock to protect that tty->driver_data is inited
> > > > >
> > > > > drivers/tty/tty_port.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c index
> > > > > 044c3cbdcfa4..86d0bec38322 100644
> > > > > --- a/drivers/tty/tty_port.c
> > > > > +++ b/drivers/tty/tty_port.c
> > > > > @@ -31,6 +31,9 @@ static int tty_port_default_receive_buf(struct
> > > > > tty_port
> > > > *port,
> > > > > if (!tty)
> > > > > return 0;
> > > > >
> > > > > + if (!tty->driver_data)
> > > > > + return 0;
> > > > > +
> > > >
> > > > How is this working? What is setting driver_data to NULL to "stop" this
> > race?
> > > >
> > >
> > >
> > > if tty->driver_data is NULL and return, tty_port_default_receive_buf
> > > will not step to uart_start which access tty->driver_data and trigger
> > > panic before tty_open, so it can fix the system panic
> > >
> > > > There's no requirement that a tty driver set this field to NULL when it
> > > > is
> > "done"
> > > > with the tty device, so I think you are just getting lucky in that
> > > > your specific driver happens to be doing this.
> > > >
> > >
> > > when tty_open is running, tty is allocated by kzalloc in tty_init_dev
> > > which called by tty_open_by_driver, tty is inited to 0
> > >
> > > > What driver are you testing this against?
> > > >
> > >
> > > 8250
> >
> > Ok, as this is specific to the uart core, how about this patch instead:
> >
> > diff --git a/drivers/tty/serial/serial_core.c
> > b/drivers/tty/serial/serial_core.c
> > index 5c01bb6d1c24..b56a6250df3f 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -130,6 +130,9 @@ static void uart_start(struct tty_struct *tty)
> > struct uart_port *port;
> > unsigned long flags;
> >
> > + if (!state)
> > + return;
> > +
> > port = uart_port_lock(state, flags);
> > __uart_start(tty);
> > uart_port_unlock(port, flags);
>
>
> If move the check into uart_start, i am afraid that it maybe not fully fix
> this issue,
> Since n_tty_receive_buf_common maybe call n_tty_check_throttle/
> tty_unthrottle_safe which maybe use
[LSF/MM ATTEND ] memory reclaim with NUMA rebalancing
Michal Hocko writes: > Hi, > I would like to propose the following topic for the MM track. Different > group of people would like to use NVIDMMs as a low cost & slower memory > which is presented to the system as a NUMA node. We do have a NUMA API > but it doesn't really fit to "balance the memory between nodes" needs. > People would like to have hot pages in the regular RAM while cold pages > might be at lower speed NUMA nodes. We do have NUMA balancing for > promotion path but there is notIhing for the other direction. Can we > start considering memory reclaim to move pages to more distant and idle > NUMA nodes rather than reclaim them? There are certainly details that > will get quite complicated but I guess it is time to start discussing > this at least. I would be interested in this topic too. I would like to understand the API and how it can help exploit the different type of devices we have on OpenCAPI. IMHO there are few proposals related to this which we could discuss together 1. HMAT series which want to expose these devices as Numa nodes 2. The patch series from Dave Hansen which just uses Pmem as Numa node. 3. The patch series from Fengguang Wu which does prevent default allocation from these numa nodes by excluding them from zone list. 4. The patch series from Jerome Glisse which doesn't expose these as numa nodes. IMHO (3) is suggesting that we really don't want them as numa nodes. But since Numa is the only interface we currently have to present them as memory and control the allocation and migration we are forcing ourselves to Numa nodes and then excluding them from default allocation. -aneesh
Re: [RFC v2 PATCH] mm: vmscan: do not iterate all mem cgroups for global direct reclaim
On Wed 30-01-19 06:11:17, Yang Shi wrote:
> In current implementation, both kswapd and direct reclaim has to iterate
> all mem cgroups. It is not a problem before offline mem cgroups could
> be iterated. But, currently with iterating offline mem cgroups, it
> could be very time consuming. In our workloads, we saw over 400K mem
> cgroups accumulated in some cases, only a few hundred are online memcgs.
> Although kswapd could help out to reduce the number of memcgs, direct
> reclaim still get hit with iterating a number of offline memcgs in some
> cases. We experienced the responsiveness problems due to this
> occassionally.
>
> A simple test with pref shows it may take around 220ms to iterate 8K memcgs
> in direct reclaim:
> dd 13873 [011] 578.542919:
> vmscan:mm_vmscan_direct_reclaim_begin
> dd 13873 [011] 578.758689: vmscan:mm_vmscan_direct_reclaim_end
> So for 400K, it may take around 11 seconds to iterate all memcgs.
>
> Here just break the iteration once it reclaims enough pages as what
> memcg direct reclaim does. This may hurt the fairness among memcgs. But
> the cached iterator cookie could help to achieve the fairness more or
> less.
>
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Signed-off-by: Yang Shi
Acked-by: Michal Hocko
> ---
> v2: Added some test data in the commit log
> Updated commit log about iterator cookie could maintain fairness
> Dropped !global_reclaim() since !current_is_kswapd() is good enough
>
> mm/vmscan.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a714c4f..5e35796 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2764,16 +2764,15 @@ static bool shrink_node(pg_data_t *pgdat, struct
> scan_control *sc)
> sc->nr_reclaimed - reclaimed);
>
> /*
> - * Direct reclaim and kswapd have to scan all memory
> - * cgroups to fulfill the overall scan target for the
> - * node.
> + * Kswapd have to scan all memory cgroups to fulfill
> + * the overall scan target for the node.
>*
>* Limit reclaim, on the other hand, only cares about
>* nr_to_reclaim pages to be reclaimed and it will
>* retry with decreasing priority if one round over the
>* whole hierarchy is not sufficient.
>*/
> - if (!global_reclaim(sc) &&
> + if (!current_is_kswapd() &&
> sc->nr_reclaimed >= sc->nr_to_reclaim) {
> mem_cgroup_iter_break(root, memcg);
> break;
> --
> 1.8.3.1
>
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren # c-sky
Acked-by: Paul Burton# MIPS
Acked-by: Heiko Carstens # s390
Reviewed-by: Juergen Gross # Xen
---
[...]
diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
[...]
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long size,
int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does not
zero allocated memory, does not panic if request cannot be satisfied.).
"Does not panic" does not mean it always succeeds.
I agree, but at least here you are changing the behaviour by making it
panic explicitly. Are we sure there are not cases where the system could
just continue functionning ? Maybe a WARN_ON() would be enough there ?
Christophe
Stephen Rothwell reports a boot failure due to this change.
Please see my reply on that thread.
Christophe
sparsemap_buf_end = sparsemap_buf + size;
}
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
>
>
> Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
> >Add check for the return value of memblock_alloc*() functions and call
> >panic() in case of error.
> >The panic message repeats the one used by panicing memblock allocators with
> >adjustment of parameters to include only relevant ones.
> >
> >The replacement was mostly automated with semantic patches like the one
> >below with manual massaging of format strings.
> >
> >@@
> >expression ptr, size, align;
> >@@
> >ptr = memblock_alloc(size, align);
> >+ if (!ptr)
> >+panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> >size, align);
> >
> >Signed-off-by: Mike Rapoport
> >Reviewed-by: Guo Ren # c-sky
> >Acked-by: Paul Burton # MIPS
> >Acked-by: Heiko Carstens # s390
> >Reviewed-by: Juergen Gross # Xen
> >---
>
> [...]
>
> >diff --git a/mm/sparse.c b/mm/sparse.c
> >index 7ea5dc6..ad94242 100644
> >--- a/mm/sparse.c
> >+++ b/mm/sparse.c
>
> [...]
>
> >@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long
> >size, int nid)
> > memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> > __pa(MAX_DMA_ADDRESS),
> > MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> >+if (!sparsemap_buf)
> >+panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> >from=%lx\n",
> >+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
> >+
>
> memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does not
> zero allocated memory, does not panic if request cannot be satisfied.).
"Does not panic" does not mean it always succeeds.
> Stephen Rothwell reports a boot failure due to this change.
Please see my reply on that thread.
> Christophe
>
> > sparsemap_buf_end = sparsemap_buf + size;
> > }
> >
>
--
Sincerely yours,
Mike.
Re: [RFC PATCH v3 06/10] devicetree: bindings: Document first ROHM BD70528 bindings
Hello Rob,
Thanks for taking the carefull look once again =)
On Wed, Jan 30, 2019 at 12:53:44PM -0600, Rob Herring wrote:
> On Wed, Jan 30, 2019 at 11:09:55AM +0200, Matti Vaittinen wrote:
> > Document bindings for regulators (3 bucks, 3 LDOs and 2 LED
> > drivers) and 4 GPIO pins which can be configured for I/O or
> > as interrupt sources withe configurable trigger levels.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > .../devicetree/bindings/mfd/rohm,bd70528-pmic.txt | 104
> > +
snip
> > + - interrupt-parent: Phandle to the parent interrupt controller.
>
> Don't document this. It is implied and could be in a parent node.
Allright. I'll remove this then.
> > + - clock-frequency : Should be 32768
>
> Forget to drop this?
Well spotted. The rate should come from parent clock. I'll drop this
too.
> > +Example:
> > +/* external oscillator */
> > +osc: oscillator {
> > + compatible = "fixed-clock";
> > + #clock-cells = <1>;
> > + clock-frequency = <32768>;
> > + clock-output-names = "osc";
> > +};
> > +
> > +pmic: bd70528@4b {
>
> pmic@4b
>
> Node names should be generic.
Ok. I will change this.
Br,
Matti
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Re: linux-next: powerpc le qemu boot failure after merge of the akpm tree
On Thu, Jan 31, 2019 at 07:15:26AM +0100, Christophe Leroy wrote:
>
>
> Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
> >Hi all,
> >
> >On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
> >wrote:
> >>
> >>[I am guessing that is is something in Andrew's tree that has caused
> >>this.]
> >>
> >>My qemu boot of the powerpc pseries_le_defconfig config failed like this:
> >>
> >>htab_hash_mask= 0x1
> >>-
> >>numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff]
> >>Kernel panic - not syncing: sparse_buffer_init: Failed to allocate
> >>2147483648 bytes align=0x1 nid=0 from=fff
This means that sparse_buffer_init tries to allocate 2G for the sparsemap_buf...
Stephen, how many memory do you give to your VM?
> >>CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4 #2
> >>Call Trace:
> >>[c105bbd0] [c0b1345c] dump_stack+0xb0/0xf4 (unreliable)
> >>[c105bc10] [c020] panic+0x168/0x3b8
> >>[c105bcb0] [c0e701c8] sparse_init_nid+0x178/0x550
> >>[c105bd70] [c0e709b4] sparse_init+0x210/0x238
> >>[c105bdb0] [c0e468f4] initmem_init+0x1e0/0x260
> >>[c105be80] [c0e3b9b0] setup_arch+0x354/0x3d4
> >>[c105bef0] [c0e33afc] start_kernel+0x98/0x648
> >>[c105bf90] [c000b270] start_here_common+0x1c/0x52c
> >
> >A quick bisect leads to this:
> >
> >1c3c9328cde027eb875ba4692f0a5d66b0afe862 is the first bad commit
> >commit 1c3c9328cde027eb875ba4692f0a5d66b0afe862
> >Author: Mike Rapoport
> >Date: Thu Jan 31 10:51:32 2019 +1100
> >
> > treewide: add checks for the return value of memblock_alloc*()
> > Add check for the return value of memblock_alloc*() functions and call
> > panic() in case of error. The panic message repeats the one used by
> > panicing memblock allocators with adjustment of parameters to include
> > only
> > relevant ones.
> > The replacement was mostly automated with semantic patches like the one
> > below with manual massaging of format strings.
> > @@
> > expression ptr, size, align;
> > @@
> > ptr = memblock_alloc(size, align);
> > + if (!ptr)
> > + panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
> > __func__,
> > size, align);
> > Link:
> > http://lkml.kernel.org/r/1548057848-15136-20-git-send-email-r...@linux.ibm.com
> > Signed-off-by: Mike Rapoport
> > Reviewed-by: Guo Ren [c-sky]
> > Acked-by: Paul Burton [MIPS]
> > Acked-by: Heiko Carstens [s390]
> > Reviewed-by: Juergen Gross [Xen]
> > Reviewed-by: Geert Uytterhoeven [m68k]
> > Cc: Catalin Marinas
> > Cc: Christophe Leroy
> > Cc: Christoph Hellwig
> > Cc: "David S. Miller"
> > Cc: Dennis Zhou
> > Cc: Greentime Hu
> > Cc: Greg Kroah-Hartman
> > Cc: Guan Xuetao
> > Cc: Guo Ren
> > Cc: Mark Salter
> > Cc: Matt Turner
> > Cc: Max Filippov
> > Cc: Michael Ellerman
> > Cc: Michal Simek
> > Cc: Petr Mladek
> > Cc: Richard Weinberger
> > Cc: Rich Felker
> > Cc: Rob Herring
> > Cc: Rob Herring
> > Cc: Russell King
> > Cc: Stafford Horne
> > Cc: Tony Luck
> > Cc: Vineet Gupta
> > Cc: Yoshinori Sato
> > Signed-off-by: Andrew Morton
> >
> >Which is just adding the panic we hit. So, presumably, the bug is in a
> >preceding patch :-(
> >
> >I have left the kernel not booting for today.
> >
>
> No I think the error is really in that patch, see my other mail.
>
> See https://elixir.bootlin.com/linux/v5.0-rc4/source/mm/memblock.c#L1455,
> memblock_alloc_try_nid_raw() is not supposed to panic, so the last hunk of
> this patch should be reverted.
It is not supposed to panic, but it can still fail, so simply ignoring it's
return value seems a bit odd at least.
> Found in total three problematic hunks in that patch:
>
> @@ -48,6 +53,11 @@ static phys_addr_t __init kasan_alloc_raw_page(int node)
> void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_KASAN, node);
> + if (!p)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> from=%llx\n",
> + __func__, PAGE_SIZE, PAGE_SIZE, node,
> + __pa(MAX_DMA_ADDRESS));
> +
> return __pa(p);
> }
>
> @@ -211,6 +211,9 @@ static int __init iob_init(struct device_node *dn)
> iob_l2_base = memblock_alloc_try_nid_raw(1UL << 21, 1UL << 21,
> MEMBLOCK_LOW_LIMIT, 0x8000,
> NUMA_NO_NODE);
> + if (!iob_l2_base)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx
> max_addr=%x\n",
> + __func__, 1UL << 21, 1UL << 21, 0x8000);
>
Commit 594cc251fdd0 (user_access_begin does access_ok) made arch/sh stop booting on qemu.
That's what I bisected it to, anyway. Commit before that boots to a shell prompt under qemu-system-sh4 (built from today's git), after produces no console output (no boot messages, no nothin'). Rob # make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=sh4.miniconf # make ARCH=sh -j $(nproc) # boot arch/sh/boot/zImage CONFIG_CPU_SUBTYPE_SH7751R=y CONFIG_MMU=y CONFIG_MEMORY_START=0x0c00 CONFIG_VSYSCALL=y CONFIG_SH_FPU=y CONFIG_SH_RTS7751R2D=y CONFIG_RTS7751R2D_PLUS=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_SH_SCI_CONSOLE=y CONFIG_PCI=y CONFIG_NET_VENDOR_REALTEK=y CONFIG_8139CP=y CONFIG_PCI=y CONFIG_BLK_DEV_SD=y CONFIG_ATA=y CONFIG_ATA_SFF=y CONFIG_ATA_BMDMA=y CONFIG_PATA_PLATFORM=y #CONFIG_SPI=y #CONFIG_SPI_SH_SCI=y #CONFIG_MFD_SM501=y #CONFIG_RTC_CLASS=y #CONFIG_RTC_DRV_R9701=y #CONFIG_RTC_DRV_SH=y #CONFIG_RTC_HCTOSYS=y # CONFIG_EMBEDDED is not set CONFIG_EARLY_PRINTK=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_SCRIPT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_INITRD=y CONFIG_RD_GZIP=y CONFIG_BLK_DEV_LOOP=y CONFIG_EXT4_FS=y CONFIG_EXT4_USE_FOR_EXT2=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_UTF8=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IPV6=y CONFIG_NETDEVICES=y #CONFIG_NET_CORE=y #CONFIG_NETCONSOLE=y CONFIG_ETHERNET=y qemu-sh4.sh Description: application/shellscript
[PATCH] arm: dts: gta04: add pinctrl settings for wkup domain
There is one button and a notifier for incoming phone
calls/text messages for which we should wakeup from
suspend.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/omap3-gta04.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index d58c117e429f..6f11bf3ee4ed 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -224,6 +224,15 @@
};
};
+&omap3_pmx_wkup {
+ gpio1_pins: pinmux_gpio1_pins {
+ pinctrl-single,pins = <
+ OMAP3_WKUP_IOPAD(0x2a14, PIN_INPUT |
PIN_OFF_WAKEUPENABLE | MUX_MODE4) /* sys_boot5.gpio_7 */
+ OMAP3_WKUP_IOPAD(0x2a1a, PIN_INPUT |
PIN_OFF_WAKEUPENABLE | MUX_MODE4) /* sys_clkout.gpio_10 */
+ >;
+ };
+};
+
&omap3_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
@@ -642,6 +651,11 @@
status = "disabled";
};
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio1_pins>;
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
--
2.11.0
[PATCH V8 3/5] i2c: tegra: Add DMA Support
This patch adds DMA support for Tegra I2C.
Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
transfer size of the max FIFO depth and DMA mode is used for
transfer size higher than max FIFO depth to save CPU overhead.
PIO mode needs full intervention of CPU to fill or empty FIFO's
and also need to service multiple data requests interrupt for the
same transaction. This adds delay between data bytes of the same
transfer when CPU is fully loaded and some slave devices has
internal timeout for no bus activity and stops transaction to
avoid bus hang. DMA mode is helpful in such cases.
DMA mode is also helpful for Large transfers during downloading or
uploading FW over I2C to some external devices.
Signed-off-by: Sowjanya Komatineni
---
[V8] : Moved back dma init to i2c probe, removed ALL_PACKETS_XFER_COMPLETE
interrupt and using PACKETS_XFER_COMPLETE interrupt only and some
other fixes
Updated Kconfig for APB_DMA dependency
[V7] : Same as V6
[V6] : Updated for proper buffer allocation/freeing, channel release.
Updated to use exact xfer size for syncing dma buffer.
[V5] : Same as V4
[V4] : Updated to allocate DMA buffer only when DMA mode.
Updated to fall back to PIO mode when DMA channel request or
buffer allocation fails.
[V3] : Updated without additional buffer allocation.
[V2] : Updated based on V1 review feedback along with code cleanup for
proper implementation of DMA.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-tegra.c | 362 ++---
2 files changed, 339 insertions(+), 25 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f2c681971201..046aeb92a467 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1016,7 +1016,7 @@ config I2C_SYNQUACER
config I2C_TEGRA
tristate "NVIDIA Tegra internal I2C controller"
- depends on ARCH_TEGRA
+ depends on (ARCH_TEGRA && TEGRA20_APB_DMA)
help
If you say yes to this option, support will be included for the
I2C controller embedded in NVIDIA Tegra SOCs
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index c4892a47a483..025d63972e50 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -8,6 +8,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -44,6 +47,8 @@
#define I2C_FIFO_CONTROL_RX_FLUSH BIT(0)
#define I2C_FIFO_CONTROL_TX_TRIG_SHIFT 5
#define I2C_FIFO_CONTROL_RX_TRIG_SHIFT 2
+#define I2C_FIFO_CONTROL_TX_TRIG(x)(((x) - 1) << 5)
+#define I2C_FIFO_CONTROL_RX_TRIG(x)(((x) - 1) << 2)
#define I2C_FIFO_STATUS0x060
#define I2C_FIFO_STATUS_TX_MASK0xF0
#define I2C_FIFO_STATUS_TX_SHIFT 4
@@ -125,6 +130,19 @@
#define I2C_MST_FIFO_STATUS_TX_MASK0xff
#define I2C_MST_FIFO_STATUS_TX_SHIFT 16
+/* Packet header size in bytes */
+#define I2C_PACKET_HEADER_SIZE 12
+
+#define DATA_DMA_DIR_TX(1 << 0)
+#define DATA_DMA_DIR_RX(1 << 1)
+
+/*
+ * Upto I2C_PIO_MODE_MAX_LEN bytes, controller will use PIO mode,
+ * above this, controller will use DMA to fill FIFO.
+ * MAX PIO len is 20 bytes excluding packet header.
+ */
+#define I2C_PIO_MODE_MAX_LEN 32
+
/*
* msg_end_type: The bus control which need to be send at end of transfer.
* @MSG_END_STOP: Send stop pulse at end of transfer.
@@ -188,6 +206,7 @@ struct tegra_i2c_hw_feature {
* @fast_clk: clock reference for fast clock of I2C controller
* @rst: reset control for the I2C controller
* @base: ioremapped registers cookie
+ * @base_phys: Physical base address of the I2C controller
* @cont_id: I2C controller ID, used for packet header
* @irq: IRQ number of transfer complete interrupt
* @irq_disabled: used to track whether or not the interrupt is enabled
@@ -201,6 +220,14 @@ struct tegra_i2c_hw_feature {
* @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
* @is_multimaster_mode: track if I2C controller is in multi-master mode
* @xfer_lock: lock to serialize transfer submission and processing
+ * @has_dma: indicates if DMA can be utilized based on dma DT bindings
+ * @tx_dma_chan: DMA transmit channel
+ * @rx_dma_chan: DMA receive channel
+ * @dma_phys: handle to DMA resources
+ * @dma_buf: pointer to allocated DMA buffer
+ * @dma_buf_size: DMA buffer size
+ * @is_curr_dma_xfer: indicates active DMA transfer
+ * @dma_complete: DMA completion notifier
*/
struct tegra_i2c_dev {
struct device *dev;
@@ -210,6 +237,7 @@ struct tegra_i2c_dev {
struct clk *fast_clk;
struct reset_control *rst;
void __iomem *base;
+ phys_addr_t base_phys;
int cont_id;
int irq;
[PATCH V8 1/5] i2c: tegra: Sort all the include headers alphabetically
This patch sorts all the include headers alphabetically for the I2C tegra driver Signed-off-by: Sowjanya Komatineni --- [V3/V4/V5/V7/V8] : Removed unsued headers in tegra I2C [V2] : Added this in V2 to sort the headers in tegra I2C drivers/i2c/busses/i2c-tegra.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c index e417ebf7628c..15806c984859 100644 --- a/drivers/i2c/busses/i2c-tegra.c +++ b/drivers/i2c/busses/i2c-tegra.c @@ -6,24 +6,21 @@ * Author: Colin Cross */ -#include -#include -#include #include +#include #include #include -#include +#include #include -#include -#include -#include +#include +#include +#include #include -#include +#include #include +#include #include -#include - -#include +#include #define TEGRA_I2C_TIMEOUT (msecs_to_jiffies(1000)) #define BYTES_PER_FIFO_WORD 4 -- 2.7.4
[PATCH V8 5/5] i2c: tegra: Add I2C interface timing support
This patch adds I2C interface timing registers support for
proper bus rate configuration along with meeting the i2c spec
setup and hold times based on the tuning performed on Tegra210,
Tegra186 and Tegra194 platforms.
I2C_INTERFACE_TIMING_0 register contains TLOW and THIGH field
and Tegra I2C controller design uses them as a part of internal
clock divisor.
I2C_INTERFACE_TIMING_1 register contains the setup and hold times
for start and stop conditions.
Signed-off-by: Sowjanya Komatineni
---
[V8] : Updated to handle timing implementation within tegra_i2c_init directly
[V7] : Minor updates to timing implementation
[V5/V6] : Added this Interface timing patch in V5 of the patch series.
drivers/i2c/busses/i2c-tegra.c | 187 ++---
1 file changed, 158 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 435518cd91b6..fe5b89abc576 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -130,6 +130,15 @@
#define I2C_MST_FIFO_STATUS_TX_MASK0xff
#define I2C_MST_FIFO_STATUS_TX_SHIFT 16
+#define I2C_INTERFACE_TIMING_0 0x94
+#define I2C_THIGH_SHIFT8
+#define I2C_INTERFACE_TIMING_1 0x98
+
+#define I2C_STANDARD_MODE 10
+#define I2C_FAST_MODE 40
+#define I2C_FAST_PLUS_MODE 100
+#define I2C_HS_MODE350
+
/* Packet header size in bytes */
#define I2C_PACKET_HEADER_SIZE 12
@@ -167,7 +176,10 @@ enum msg_end_type {
* @has_config_load_reg: Has the config load register to load the new
* configuration.
* @clk_divisor_hs_mode: Clock divisor in HS mode.
- * @clk_divisor_std_fast_mode: Clock divisor in standard/fast mode. It is
+ * @clk_divisor_std_mode: Clock divisor in standard mode. It is
+ * applicable if there is no fast clock source i.e. single clock
+ * source.
+ * @clk_divisor_fast_mode: Clock divisor in fast mode. It is
* applicable if there is no fast clock source i.e. single clock
* source.
* @clk_divisor_fast_plus_mode: Clock divisor in fast mode plus. It is
@@ -182,6 +194,16 @@ enum msg_end_type {
* be transferred in one go.
* @supports_bus_clear: Bus Clear support to recover from bus hang during
* SDA stuck low from device for some unknown reasons.
+ * @tlow_std_mode: Low period of the clock in standard mode.
+ * @thigh_std_mode: High period of the clock in standard mode.
+ * @tlow_fast_fastplus_mode: Low period of the clock in fast/fast-plus modes.
+ * @thigh_fast_fastplus_mode: High period of the clock in fast/fast-plus modes.
+ * @setup_hold_time_std_mode: Setup and hold time for start and stop conditions
+ * in standard mode.
+ * @setup_hold_time_fast_fast_plus_mode: Setup and hold time for start and stop
+ * conditions in fast/fast-plus modes.
+ * @setup_hold_time_hs_mode: Setup and hold time for start and stop conditions
+ * in HS mode.
*/
struct tegra_i2c_hw_feature {
bool has_continue_xfer_support;
@@ -189,12 +211,20 @@ struct tegra_i2c_hw_feature {
bool has_single_clk_source;
bool has_config_load_reg;
int clk_divisor_hs_mode;
- int clk_divisor_std_fast_mode;
+ int clk_divisor_std_mode;
+ int clk_divisor_fast_mode;
u16 clk_divisor_fast_plus_mode;
bool has_multi_master_mode;
bool has_slcg_override_reg;
bool has_mst_fifo;
bool supports_bus_clear;
+ u8 tlow_std_mode;
+ u8 thigh_std_mode;
+ u8 tlow_fast_fastplus_mode;
+ u8 thigh_fast_fastplus_mode;
+ u32 setup_hold_time_std_mode;
+ u32 setup_hold_time_fast_fast_plus_mode;
+ u32 setup_hold_time_hs_mode;
};
/**
@@ -640,11 +670,13 @@ static int tegra_i2c_wait_for_config_load(struct
tegra_i2c_dev *i2c_dev)
return 0;
}
-static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
+static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, bool clk_reinit)
{
u32 val;
int err;
- u32 clk_divisor;
+ u32 clk_divisor, clk_multiplier;
+ u32 tsu_thd = 0;
+ u8 tlow, thigh;
err = pm_runtime_get_sync(i2c_dev->dev);
if (err < 0) {
@@ -674,6 +706,36 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
I2C_CLK_DIVISOR_STD_FAST_MODE_SHIFT;
i2c_writel(i2c_dev, clk_divisor, I2C_CLK_DIVISOR);
+ if ((i2c_dev->bus_clk_rate > I2C_STANDARD_MODE) &&
+ (i2c_dev->bus_clk_rate <= I2C_FAST_PLUS_MODE)) {
+ tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
+ thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
+ tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
+ } else {
+ tlow = i
[PATCH V8 4/5] i2c: tegra: Update transfer timeout
Tegra194 allows max of 64K bytes and Tegra186 and prior allows
max of 4K bytes of transfer per packet.
one sec timeout is not enough for transfers more than 10K bytes
at STD bus rate.
This patch updates I2C transfer timeout based on the transfer size
and I2C bus rate to allow enough time during max transfer size at
lower bus speed.
Signed-off-by: Sowjanya Komatineni
---
[V8] : Added comment with explaination of xfer time calculation
[V5/V6/V7] : Same as V4
[V4] : V4 series includes bus clear support and this patch is updated with
fixed timeout of 1sec for bus clear operation.
[V3] : Same as V2
[V2] : Added this patch in V2 series to allow enough time for data transfer
to happen.
This patch has dependency with DMA patch as TEGRA_I2C_TIMEOUT define
takes argument with this patch.
drivers/i2c/busses/i2c-tegra.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 025d63972e50..435518cd91b6 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -25,7 +25,7 @@
#include
#include
-#define TEGRA_I2C_TIMEOUT (msecs_to_jiffies(1000))
+#define TEGRA_I2C_TIMEOUT(ms) (msecs_to_jiffies(ms))
#define BYTES_PER_FIFO_WORD 4
#define I2C_CNFG 0x000
@@ -901,8 +901,9 @@ static int tegra_i2c_issue_bus_clear(struct tegra_i2c_dev
*i2c_dev)
i2c_writel(i2c_dev, reg, I2C_BUS_CLEAR_CNFG);
tegra_i2c_unmask_irq(i2c_dev, I2C_INT_BUS_CLR_DONE);
- time_left = wait_for_completion_timeout(&i2c_dev->msg_complete,
- TEGRA_I2C_TIMEOUT);
+ time_left = wait_for_completion_timeout(
+ &i2c_dev->msg_complete,
+ TEGRA_I2C_TIMEOUT(1000));
if (time_left == 0) {
dev_err(i2c_dev->dev, "timed out for bus clear\n");
return -ETIMEDOUT;
@@ -930,6 +931,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
int err = 0;
bool dma = false;
struct dma_chan *chan;
+ u16 xfer_time = 100;
tegra_i2c_flush_fifos(i2c_dev);
@@ -945,6 +947,13 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
xfer_size = msg->len + I2C_PACKET_HEADER_SIZE;
xfer_size = ALIGN(xfer_size, BYTES_PER_FIFO_WORD);
+ /*
+* Transfer time = Total bits / transfer rate
+* Total bits = 9 bits per byte (including ACK bit) + Start & stop bits
+*/
+ xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * 1000,
+ i2c_dev->bus_clk_rate);
+
dma = (xfer_size > I2C_PIO_MODE_MAX_LEN);
if (dma) {
err = tegra_i2c_init_dma_param(i2c_dev);
@@ -1063,7 +1072,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
time_left = wait_for_completion_timeout(
&i2c_dev->dma_complete,
- TEGRA_I2C_TIMEOUT);
+ TEGRA_I2C_TIMEOUT(xfer_time));
if (time_left == 0) {
dev_err(i2c_dev->dev, "DMA transfer timeout\n");
@@ -1086,7 +1095,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
}
time_left = wait_for_completion_timeout(&i2c_dev->msg_complete,
- TEGRA_I2C_TIMEOUT);
+ TEGRA_I2C_TIMEOUT(xfer_time));
tegra_i2c_mask_irq(i2c_dev, int_mask);
if (time_left == 0) {
--
2.7.4
[PATCH V8 2/5] i2c: tegra: Add Bus Clear Master Support
Bus clear feature of tegra i2c controller helps to recover from
bus hang when i2c master loses the bus arbitration due to the
slave device holding SDA LOW continuously for some unknown reasons.
Per I2C specification, the device that held the bus LOW should
release it within 9 clock pulses.
During bus clear operation, Tegra I2C controller sends 9 clock
pulses and terminates the transaction with STOP condition.
Upon successful bus clear operation, bus goes to idle state and
driver retries the transaction.
Signed-off-by: Sowjanya Komatineni
---
[V5/V6/V7/V8]: Same as V4
[V4]: Added I2C Bus Clear support patch to this version of series.
drivers/i2c/busses/i2c-tegra.c | 71 ++
1 file changed, 71 insertions(+)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 15806c984859..c4892a47a483 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -51,6 +51,7 @@
#define I2C_FIFO_STATUS_RX_SHIFT 0
#define I2C_INT_MASK 0x064
#define I2C_INT_STATUS 0x068
+#define I2C_INT_BUS_CLR_DONE BIT(11)
#define I2C_INT_PACKET_XFER_COMPLETE BIT(7)
#define I2C_INT_ALL_PACKETS_XFER_COMPLETE BIT(6)
#define I2C_INT_TX_FIFO_OVERFLOW BIT(5)
@@ -93,6 +94,15 @@
#define I2C_HEADER_MASTER_ADDR_SHIFT 12
#define I2C_HEADER_SLAVE_ADDR_SHIFT1
+#define I2C_BUS_CLEAR_CNFG 0x084
+#define I2C_BC_SCLK_THRESHOLD 9
+#define I2C_BC_SCLK_THRESHOLD_SHIFT16
+#define I2C_BC_STOP_COND BIT(2)
+#define I2C_BC_TERMINATE BIT(1)
+#define I2C_BC_ENABLE BIT(0)
+#define I2C_BUS_CLEAR_STATUS 0x088
+#define I2C_BC_STATUS BIT(0)
+
#define I2C_CONFIG_LOAD0x08C
#define I2C_MSTR_CONFIG_LOAD BIT(0)
#define I2C_SLV_CONFIG_LOADBIT(1)
@@ -152,6 +162,8 @@ enum msg_end_type {
* @has_mst_fifo: The I2C controller contains the new MST FIFO interface that
* provides additional features and allows for longer messages to
* be transferred in one go.
+ * @supports_bus_clear: Bus Clear support to recover from bus hang during
+ * SDA stuck low from device for some unknown reasons.
*/
struct tegra_i2c_hw_feature {
bool has_continue_xfer_support;
@@ -164,6 +176,7 @@ struct tegra_i2c_hw_feature {
bool has_multi_master_mode;
bool has_slcg_override_reg;
bool has_mst_fifo;
+ bool supports_bus_clear;
};
/**
@@ -636,6 +649,12 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
i2c_dev->msg_err |= I2C_ERR_ARBITRATION_LOST;
goto err;
}
+ /*
+* I2C transfer is terminated during the bus clear so skip
+* processing the other interrupts.
+*/
+ if (i2c_dev->hw->supports_bus_clear && (status & I2C_INT_BUS_CLR_DONE))
+ goto err;
if (i2c_dev->msg_read && (status & I2C_INT_RX_FIFO_DATA_REQ)) {
if (i2c_dev->msg_buf_remaining)
@@ -665,6 +684,8 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
tegra_i2c_mask_irq(i2c_dev, I2C_INT_NO_ACK | I2C_INT_ARBITRATION_LOST |
I2C_INT_PACKET_XFER_COMPLETE | I2C_INT_TX_FIFO_DATA_REQ |
I2C_INT_RX_FIFO_DATA_REQ);
+ if (i2c_dev->hw->supports_bus_clear)
+ tegra_i2c_mask_irq(i2c_dev, I2C_INT_BUS_CLR_DONE);
i2c_writel(i2c_dev, status, I2C_INT_STATUS);
if (i2c_dev->is_dvc)
dvc_writel(i2c_dev, DVC_STATUS_I2C_DONE_INTR, DVC_STATUS);
@@ -675,6 +696,43 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static int tegra_i2c_issue_bus_clear(struct tegra_i2c_dev *i2c_dev)
+{
+ int err;
+ unsigned long time_left;
+ u32 reg;
+
+ if (i2c_dev->hw->supports_bus_clear) {
+ reinit_completion(&i2c_dev->msg_complete);
+ reg = (I2C_BC_SCLK_THRESHOLD << I2C_BC_SCLK_THRESHOLD_SHIFT) |
+ I2C_BC_STOP_COND | I2C_BC_TERMINATE;
+ i2c_writel(i2c_dev, reg, I2C_BUS_CLEAR_CNFG);
+ if (i2c_dev->hw->has_config_load_reg) {
+ err = tegra_i2c_wait_for_config_load(i2c_dev);
+ if (err)
+ return err;
+ }
+ reg |= I2C_BC_ENABLE;
+ i2c_writel(i2c_dev, reg, I2C_BUS_CLEAR_CNFG);
+ tegra_i2c_unmask_irq(i2c_dev, I2C_INT_BUS_CLR_DONE);
+
+ time_left = wait_for_completion_timeout(&i2c_dev->msg_complete,
+ TEGRA_I2C_TIMEOUT);
+ if (time_left == 0) {
+ dev_err(i2c_dev-
Re: linux-next: powerpc le qemu boot failure after merge of the akpm tree
Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
Hi all,
On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
wrote:
[I am guessing that is is something in Andrew's tree that has caused
this.]
My qemu boot of the powerpc pseries_le_defconfig config failed like this:
htab_hash_mask= 0x1
-
numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff]
Kernel panic - not syncing: sparse_buffer_init: Failed to allocate 2147483648
bytes align=0x1 nid=0 from=fff
CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4 #2
Call Trace:
[c105bbd0] [c0b1345c] dump_stack+0xb0/0xf4 (unreliable)
[c105bc10] [c020] panic+0x168/0x3b8
[c105bcb0] [c0e701c8] sparse_init_nid+0x178/0x550
[c105bd70] [c0e709b4] sparse_init+0x210/0x238
[c105bdb0] [c0e468f4] initmem_init+0x1e0/0x260
[c105be80] [c0e3b9b0] setup_arch+0x354/0x3d4
[c105bef0] [c0e33afc] start_kernel+0x98/0x648
[c105bf90] [c000b270] start_here_common+0x1c/0x52c
A quick bisect leads to this:
1c3c9328cde027eb875ba4692f0a5d66b0afe862 is the first bad commit
commit 1c3c9328cde027eb875ba4692f0a5d66b0afe862
Author: Mike Rapoport
Date: Thu Jan 31 10:51:32 2019 +1100
treewide: add checks for the return value of memblock_alloc*()
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error. The panic message repeats the one used by
panicing memblock allocators with adjustment of parameters to include only
relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Link: http://lkml.kernel.org/r/1548057848-15136-20-git-send-email-r...@linux.ibm.com
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren [c-sky]
Acked-by: Paul Burton [MIPS]
Acked-by: Heiko Carstens [s390]
Reviewed-by: Juergen Gross [Xen]
Reviewed-by: Geert Uytterhoeven [m68k]
Cc: Catalin Marinas
Cc: Christophe Leroy
Cc: Christoph Hellwig
Cc: "David S. Miller"
Cc: Dennis Zhou
Cc: Greentime Hu
Cc: Greg Kroah-Hartman
Cc: Guan Xuetao
Cc: Guo Ren
Cc: Mark Salter
Cc: Matt Turner
Cc: Max Filippov
Cc: Michael Ellerman
Cc: Michal Simek
Cc: Petr Mladek
Cc: Richard Weinberger
Cc: Rich Felker
Cc: Rob Herring
Cc: Rob Herring
Cc: Russell King
Cc: Stafford Horne
Cc: Tony Luck
Cc: Vineet Gupta
Cc: Yoshinori Sato
Signed-off-by: Andrew Morton
Which is just adding the panic we hit. So, presumably, the bug is in a
preceding patch :-(
I have left the kernel not booting for today.
No I think the error is really in that patch, see my other mail.
See
https://elixir.bootlin.com/linux/v5.0-rc4/source/mm/memblock.c#L1455,
memblock_alloc_try_nid_raw() is not supposed to panic, so the last hunk
of this patch should be reverted.
Found in total three problematic hunks in that patch:
@@ -48,6 +53,11 @@ static phys_addr_t __init kasan_alloc_raw_page(int node)
void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_KASAN, node);
+ if (!p)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%llx\n",
+ __func__, PAGE_SIZE, PAGE_SIZE, node,
+ __pa(MAX_DMA_ADDRESS));
+
return __pa(p);
}
@@ -211,6 +211,9 @@ static int __init iob_init(struct device_node *dn)
iob_l2_base = memblock_alloc_try_nid_raw(1UL << 21, 1UL << 21,
MEMBLOCK_LOW_LIMIT, 0x8000,
NUMA_NO_NODE);
+ if (!iob_l2_base)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx
max_addr=%x\n",
+ __func__, 1UL << 21, 1UL << 21, 0x8000);
pr_info("IOBMAP L2 allocated at: %p\n", iob_l2_base);
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long
size, int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
sparsemap_buf_end = sparsemap_buf +
linux-next: Tree for Jan 31
Hi all, Changes since 20190130: The drm-intel-fixes tree lost its build failure. The ext3 tree gained a build failure for which I reverted a commit. The vfs tree still had its build failure for which I applied a patch. The vhost tree gained a conflict against the pci tree. The akpm-current tree gained a conflict against the tip tree. My qemu powerpcle boot tests failed. Non-merge commits (relative to Linus' tree): 4608 5344 files changed, 198916 insertions(+), 120760 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (1c0490ce9022 Merge tag 'iommu-fixes-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu) Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (7c2614bf7a1f Merge tag '5.0-rc3-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6) Merging arc-current/for-curr (46c95568661c ARCv2: Enable unaligned access in early ASM code) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (7fa1e2e6afa7 kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e15aa3b2b138 ucc_geth: Reset BQL queue when stopping device) Merging bpf/master (9d90436ece8f Merge branch 'typedef-func_proto') Merging ipsec/master (09db51241118 esp: Skip TX bytes accounting when sending from a request socket) Merging netfilter/master (bfe2599dd2f9 Merge branch 'qed-Bug-fixes') Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (13e62626c578 wlcore: sdio: Fixup power on/off sequence) Merging mac80211/master (93183bdbe73b cfg80211: extend range deviation for DMG) Merging rdma-fixes/for-rc (6ab4aba00f81 IB/ipoib: Fix for use-after-free in ipoib_cm_tx_start) Merging sound-current/for-linus (693abe11aa6b ALSA: hda/realtek - Fixed hp_pin no value) Merging sound-asoc-fixes/for-linus (2563c3f2fca3 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (5db93a904e9c Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (c96ca2283195 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (0084379b5a13 Merge remote-tracking branch 'lorenzo/pci/controller-fixes' into for-linus) Merging driver-core.current/driver-core-linus (37ea7b630ae5 debugfs: debugfs_lookup() should return NULL if not found) Merging tty.current/tty-linus (a1960e0f1639 staging: speakup: fix tty-operation NULL derefs) Merging usb.current/usb-linus (c418fd6c01fb usb: gadget: musb: fix short isoc packets with inventra dma) Merging us
Re: [RFC v3 5/5] cros_ec: differentiate SCP from EC by feature bit.
Hi Enric, On Wed, Jan 30, 2019 at 11:06 PM Enric Balletbo Serra wrote: > > Hi Lee, Pi-Hsun, > > Missatge de Lee Jones del dia dc., 30 de gen. > 2019 a les 14:07: > > > > On Mon, 21 Jan 2019, Pi-Hsun Shih wrote: > > > > > Since a SCP and EC would both exist on a system, and use the cros_ec_dev > > > driver, we need to differentiate between them for the userspace, or they > > > would both be registered at /dev/cros_ec, causing a conflict. > > > > > > Cc: Enric Balletbo Serra > > > Cc: Guenter Roeck > > > Signed-off-by: Pi-Hsun Shih > > > --- > > > Changes from v2: > > > - No change. > > > > > > Changes from v1: > > > - New patch extracted from Patch 5. > > > --- > > > drivers/mfd/cros_ec_dev.c| 9 + > > > include/linux/mfd/cros_ec.h | 1 + > > > include/linux/mfd/cros_ec_commands.h | 2 ++ > > > 3 files changed, 12 insertions(+) > > > > Just to clarify to the new Cc'ed list, I'm waiting on one of the > > Chromium guys to review before I put my mucky paws over it. > > > > Pi-Hsun, is this patchset still an RFC or you really want to see this > merged ASAP? If I am not mistaken there is still some work in progress > trying to push all the SCP stuff? > > Lee, personally I have some concerns. Looks like the cros_* family is > increasing quickly lately (cros_ec, cros_pd, cros_scp, cros_ish, > cros_fp ...) and I am wondering if we are really doing well all this. > To be honest, I'd like to take a deeper look before merge this, btw I > thought there was no hurry because of the RFC and I guess there are > still some scp things that are missing. I might be wrong, and if > that's not the case I can take a look deeper and the end of the week. > > Best regards, > Enric I don't think we need this to be merged ASAP. I feel that most of the todos are done though, so I'll drop the RFC tag and resend a v4 (which also contains some bug fixes found when testing). > > > > -- > > Lee Jones [李琼斯] > > Linaro Services Technical Lead > > Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren # c-sky
Acked-by: Paul Burton# MIPS
Acked-by: Heiko Carstens # s390
Reviewed-by: Juergen Gross # Xen
---
[...]
diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
[...]
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long size,
int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does
not zero allocated memory, does not panic if request cannot be satisfied.).
Stephen Rothwell reports a boot failure due to this change.
Christophe
sparsemap_buf_end = sparsemap_buf + size;
}
Re: linux-next: powerpc le qemu boot failure after merge of the akpm tree
Hi all,
On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
wrote:
>
> [I am guessing that is is something in Andrew's tree that has caused
> this.]
>
> My qemu boot of the powerpc pseries_le_defconfig config failed like this:
>
> htab_hash_mask= 0x1
> -
> numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff]
> Kernel panic - not syncing: sparse_buffer_init: Failed to allocate 2147483648
> bytes align=0x1 nid=0 from=fff
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4 #2
> Call Trace:
> [c105bbd0] [c0b1345c] dump_stack+0xb0/0xf4 (unreliable)
> [c105bc10] [c020] panic+0x168/0x3b8
> [c105bcb0] [c0e701c8] sparse_init_nid+0x178/0x550
> [c105bd70] [c0e709b4] sparse_init+0x210/0x238
> [c105bdb0] [c0e468f4] initmem_init+0x1e0/0x260
> [c105be80] [c0e3b9b0] setup_arch+0x354/0x3d4
> [c105bef0] [c0e33afc] start_kernel+0x98/0x648
> [c105bf90] [c000b270] start_here_common+0x1c/0x52c
A quick bisect leads to this:
1c3c9328cde027eb875ba4692f0a5d66b0afe862 is the first bad commit
commit 1c3c9328cde027eb875ba4692f0a5d66b0afe862
Author: Mike Rapoport
Date: Thu Jan 31 10:51:32 2019 +1100
treewide: add checks for the return value of memblock_alloc*()
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error. The panic message repeats the one used by
panicing memblock allocators with adjustment of parameters to include only
relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Link:
http://lkml.kernel.org/r/1548057848-15136-20-git-send-email-r...@linux.ibm.com
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren [c-sky]
Acked-by: Paul Burton [MIPS]
Acked-by: Heiko Carstens [s390]
Reviewed-by: Juergen Gross [Xen]
Reviewed-by: Geert Uytterhoeven [m68k]
Cc: Catalin Marinas
Cc: Christophe Leroy
Cc: Christoph Hellwig
Cc: "David S. Miller"
Cc: Dennis Zhou
Cc: Greentime Hu
Cc: Greg Kroah-Hartman
Cc: Guan Xuetao
Cc: Guo Ren
Cc: Mark Salter
Cc: Matt Turner
Cc: Max Filippov
Cc: Michael Ellerman
Cc: Michal Simek
Cc: Petr Mladek
Cc: Richard Weinberger
Cc: Rich Felker
Cc: Rob Herring
Cc: Rob Herring
Cc: Russell King
Cc: Stafford Horne
Cc: Tony Luck
Cc: Vineet Gupta
Cc: Yoshinori Sato
Signed-off-by: Andrew Morton
Which is just adding the panic we hit. So, presumably, the bug is in a
preceding patch :-(
I have left the kernel not booting for today.
--
Cheers,
Stephen Rothwell
pgpn5KkhEyCXq.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/3] slub: Do trivial comments fixes
On 31/01/2019 6.10, Tobin C. Harding wrote: From: "Tobin C. Harding" Hi Christopher, Here is a trivial patchset to wet my toes. This is my first patchset to mm, if there are some mm specific nuances in relation to when in the dev cycle (if ever) that minor (*cough* trivial) pathsets are acceptable please say so This patchset fixes comments strings in the SLUB subsystem. As per discussion at LCA I am working on getting my head around the SLUB allocator. If you specifically do *not* want me to do minor clean up while I'm reading please say so, I will not be offended. For the series: Reviewed-by: Pekka Enberg
Re: [PATCH] mm: Prevent mapping slab pages to userspace
On 25/01/2019 19.38, Matthew Wilcox wrote: It's never appropriate to map a page allocated by SLAB into userspace. A buggy device driver might try this, or an attacker might be able to find a way to make it happen. Signed-off-by: Matthew Wilcox Acked-by: Pekka Enberg A WARN_ON_ONCE() would be nice here to let those buggy drivers know that they will no longer work. --- mm/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index e11ca9dd823f..ce8c90b752be 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1451,7 +1451,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr, spinlock_t *ptl; retval = -EINVAL; - if (PageAnon(page)) + if (PageAnon(page) || PageSlab(page)) goto out; retval = -ENOMEM; flush_dcache_page(page);
Re: [PATCH] phy: ti-pipe3: Add set_mode callback to configure usb3 phy as pcie phy
Roger,
On 30/01/19 8:28 PM, Roger Quadros wrote:
> Kishon,
>
> On 24/01/19 12:48, Kishon Vijay Abraham I wrote:
>> DRA72 platform has the second instance of PHY shared between USB3
>> controller and PCIe controller with default as USB3 controller.
>> Since it is used with USB3 controller by default, it uses the
>> compatible specific to USB (ti,omap-usb3).
>>
>> Populate set_mode callback so that the USB3 PHY can be configured
>> to be used with PCIe controller.
>
> How about rewording this to,
>
> "On DRA72x SoCs, the USB3 PHY can be used either as USB Super-Speed
> lane or as PCIe Lane (i.e. second lane for PCIe_SS1 in 2 lane mode or single
> lane for PCIe_SS2). The default mode for the USB3 PHY is USB Super-Speed.
> Provide a way for the PHY user to choose the appropriate mode via the
> .set_mode hook"
hmm okay
>
> More comments below.
>
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> drivers/phy/ti/phy-ti-pipe3.c | 66 ---
>> 1 file changed, 54 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
>> index 68ce4a082b9b..8c98f366416d 100644
>> --- a/drivers/phy/ti/phy-ti-pipe3.c
>> +++ b/drivers/phy/ti/phy-ti-pipe3.c
>> @@ -56,6 +56,12 @@
>>
>> #define SATA_PLL_SOFT_RESET BIT(18)
>>
>> +#define PHY_RX_ANA_PRGRAMMABILITY_REG 0xC
>> +#define MEM_EN_PLLBYP BIT(7)
>> +
>> +#define PHY_TX_TEST_CONFIG 0x2C
>> +#define MEM_ENTESTCLK BIT(31)
>> +
>> #define PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
>> #define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
>>
>> @@ -110,6 +116,8 @@
>> #define PLL_IDLE_TIME 100 /* in milliseconds */
>> #define PLL_LOCK_TIME 100 /* in milliseconds */
>>
>> +#define PIPE3_PHY_DISABLE_SYNC_POWERBIT(4)
>> +
>> struct pipe3_dpll_params {
>> u16 m;
>> u8 n;
>> @@ -141,6 +149,7 @@ struct ti_pipe3 {
>> unsigned intpower_reg; /* power reg. index within syscon */
>> unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
>> boolsata_refclk_enabled;
>> +u32 mode;
>> };
>>
>> static struct pipe3_dpll_map dpll_map_usb[] = {
>> @@ -233,7 +242,10 @@ static int ti_pipe3_power_on(struct phy *x)
>> rate = rate / 100;
>> mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
>>OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
>> -val = PIPE3_PHY_TX_RX_POWERON << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
>> +val = PIPE3_PHY_TX_RX_POWERON;
>> +if (phy->mode == PHY_MODE_PCIE)
>> +val |= PIPE3_PHY_DISABLE_SYNC_POWER;
>
> Is this required only for the USB3 PHY being used as PCIe lane or can it
> be done for the PCIe PHY as well?
This setting was given only for USB3 PHY. I did check PCIe PHY (1-lane) to see
if this is causing issues before posting the patch.
Thinking again, it might be safer to just use this setting for USB3 PHY.
>
> I ask this because phy->mode can be PHY_MODE_PCIE for both USB3 PHY and PCIe
> PHY
> and it might break PCIe PHY as we don't do PIPE3_PHY_DISABLE_SYNC_POWER for
> that
> currently.
>
> Maybe this is safer?
>
> if (phy->mode == PHY_MODE_PCIE && of_device_is_compatible(node,
> "ti,phy-usb3"))
yeah..
>
>> +val <<= PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
>> val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
>>
>> ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
>> @@ -328,13 +340,11 @@ static void ti_pipe3_calibrate(struct ti_pipe3 *phy)
>> ti_pipe3_writel(phy->phy_rx, PCIEPHYRX_EQUALIZER, val);
>> }
>>
>> -static int ti_pipe3_init(struct phy *x)
>> +static int ti_pipe3_pcie_init(struct ti_pipe3 *phy)
>> {
>> -struct ti_pipe3 *phy = phy_get_drvdata(x);
>> -u32 val;
>> int ret = 0;
>> +u32 val;
>>
>> -ti_pipe3_enable_clocks(phy);
>> /*
>> * Set pcie_pcs register to 0x96 for proper functioning of phy
>> * as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
>> @@ -353,10 +363,31 @@ static int ti_pipe3_init(struct phy *x)
>> return ret;
>>
>> ti_pipe3_calibrate(phy);
>> -
>> -return 0;
>> +} else {
>
> How about
>
> else if (of_device_is_compatible(node, "ti,phy-usb3")) {
This check is implicit no?
> /* USB3 PHY being used as PCIe Lane */
>
>> +val = ti_pipe3_readl(phy->phy_rx,
>> + PHY_RX_ANA_PRGRAMMABILITY_REG);
>> +val |= MEM_EN_PLLBYP;
>> +ti_pipe3_writel(phy->phy_rx, PHY_RX_ANA_PRGRAMMABILITY_REG,
>> +val);
>> +val = ti_pipe3_readl(phy->phy_tx, PHY_TX_TEST_CONFIG);
>> +val |= MEM_ENTESTCLK;
>> +ti_pipe3_writel(phy->phy_tx, PHY_TX_TEST_CONFIG, val);
>> }
>>
>> +return 0;
>> +}
>> +
>> +static int ti_pipe3_init(struct phy *x)
>
Re: [PATCH] arch/arm/mm: Remove duplicate header
On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport wrote: > > On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > > On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder > > wrote: > > > > > > Remove duplicate headers which are included twice. > > > > > > Signed-off-by: Souptick Joarder > > Acked-by: Mike Rapoport > > > Any comment on this patch ? If no further comment, can we get this patch in queue for 5.1 ? > > > > > --- > > > arch/arm/mm/mmu.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > > > index f5cc1cc..dde3032 100644 > > > --- a/arch/arm/mm/mmu.c > > > +++ b/arch/arm/mm/mmu.c > > > @@ -23,7 +23,6 @@ > > > #include > > > #include > > > #include > > > -#include > > > #include > > > #include > > > #include > > > @@ -36,7 +35,6 @@ > > > #include > > > #include > > > #include > > > -#include > > > > > > #include "fault.h" > > > #include "mm.h" > > > -- > > > 1.9.1 > > > > > > > -- > Sincerely yours, > Mike. >
Re: [PATCH] lib: zstd: Mark expected switch fall-throughs
On Thu, Jan 31, 2019 at 12:30 PM Gustavo A. R. Silva
wrote:
>
>
>
> On 1/30/19 1:58 AM, Kees Cook wrote:
> > On Wed, Jan 30, 2019 at 12:34 PM Gustavo A. R. Silva
> > wrote:
> >>
> >> In preparation to enabling -Wimplicit-fallthrough, mark switch
> >> cases where we are expecting to fall through.
> >>
> >> This patch fixes the following warnings:
> >>
> >> lib/zstd/bitstream.h:261:30: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/bitstream.h:262:30: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/bitstream.h:263:30: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/bitstream.h:264:30: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/bitstream.h:265:30: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/compress.c:3183:16: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/decompress.c:1770:18: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/decompress.c:2376:15: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/decompress.c:2404:15: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/decompress.c:2435:16: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> lib/zstd/huf_compress.c: In function ‘HUF_compress1X_usingCTable’:
> >> lib/zstd/huf_compress.c:535:5: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> if (sizeof((stream)->bitContainer) * 8 < HUF_TABLELOG_MAX * 4 + 7) \
> >> ^
> >> lib/zstd/huf_compress.c:558:54: note: in expansion of macro
> >> ‘HUF_FLUSHBITS_2’
> >> case 3: HUF_encodeSymbol(&bitC, ip[n + 2], CTable);
> >> HUF_FLUSHBITS_2(&bitC);
> >> ^~~
> >> lib/zstd/huf_compress.c:559:2: note: here
> >> case 2: HUF_encodeSymbol(&bitC, ip[n + 1], CTable);
> >> HUF_FLUSHBITS_1(&bitC);
> >> ^~~~
> >> lib/zstd/huf_compress.c:531:5: warning: this statement may fall through
> >> [-Wimplicit-fallthrough=]
> >> if (sizeof((stream)->bitContainer) * 8 < HUF_TABLELOG_MAX * 2 + 7) \
> >> ^
> >> lib/zstd/huf_compress.c:559:54: note: in expansion of macro
> >> ‘HUF_FLUSHBITS_1’
> >> case 2: HUF_encodeSymbol(&bitC, ip[n + 1], CTable);
> >> HUF_FLUSHBITS_1(&bitC);
> >> ^~~
> >> lib/zstd/huf_compress.c:560:2: note: here
> >> case 1: HUF_encodeSymbol(&bitC, ip[n + 0], CTable); HUF_FLUSHBITS(&bitC);
> >> ^~~~
> >> AR lib/zstd//built-in.a
> >>
> >> Warning level 3 was used: -Wimplicit-fallthrough=3
> >>
> >> This patch is part of the ongoing efforts to enabling
> >> -Wimplicit-fallthrough.
> >>
> >> Signed-off-by: Gustavo A. R. Silva
> >> ---
> >> lib/zstd/bitstream.h| 5 +
> >> lib/zstd/compress.c | 1 +
> >> lib/zstd/decompress.c | 5 -
> >> lib/zstd/huf_compress.c | 2 ++
> >> 4 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/zstd/bitstream.h b/lib/zstd/bitstream.h
> >> index a826b99e1d63..3a49784d5c61 100644
> >> --- a/lib/zstd/bitstream.h
> >> +++ b/lib/zstd/bitstream.h
> >> @@ -259,10 +259,15 @@ ZSTD_STATIC size_t BIT_initDStream(BIT_DStream_t
> >> *bitD, const void *srcBuffer, s
> >> bitD->bitContainer = *(const BYTE *)(bitD->start);
> >> switch (srcSize) {
> >> case 7: bitD->bitContainer += (size_t)(((const BYTE
> >> *)(srcBuffer))[6]) << (sizeof(bitD->bitContainer) * 8 - 16);
> >> + /* fall through */
> >> case 6: bitD->bitContainer += (size_t)(((const BYTE
> >> *)(srcBuffer))[5]) << (sizeof(bitD->bitContainer) * 8 - 24);
> >> + /* fall through */
> >> case 5: bitD->bitContainer += (size_t)(((const BYTE
> >> *)(srcBuffer))[4]) << (sizeof(bitD->bitContainer) * 8 - 32);
> >> + /* fall through */
> >> case 4: bitD->bitContainer += (size_t)(((const BYTE
> >> *)(srcBuffer))[3]) << 24;
> >> + /* fall through */
> >> case 3: bitD->bitContainer += (size_t)(((const BYTE
> >> *)(srcBuffer))[2]) << 16;
> >> + /* fall through */
> >> case 2: bitD->bitContainer += (size_t)(((const BYTE
> >> *)(srcBuffer))[1]) << 8;
> >> default:;
> >> }
> >> diff --git a/lib/zstd/compress.c b/lib/zstd/compress.c
> >> index f9166cf4f7a9..5e0b67003e55 100644
> >> --- a/lib/zstd/compress.c
> >> +++ b/lib/zstd/compress.c
> >> @@ -3182,6 +3182,7 @@ static size_t
> >> ZSTD_compressStream_generic(ZSTD_CStream *zcs, void *dst, size_t *
> >> zcs->outBuffFlushedSize = 0;
> >> zcs->stage = zcss_flush; /* pass-throu
Re: [PATCH 0/4] powerpc/livepatch: reliable stack unwinder fixes
Jiri Kosina writes: > On Wed, 30 Jan 2019, Michael Ellerman wrote: > >> I'm happy to take it, unless there's some reason you'd rather it go via >> the LP tree? > > As this is more about reliable stack unwinding than live patching per se > (which is only a user of that facility), I'd actually slightly prefer if > it goes via your tree. Sure thing, I'll take it. cheers
Re: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return
Nicolai Stange writes: > Michael Ellerman writes: > >> Joe Lawrence writes: >>> From: Nicolai Stange >>> >>> The ppc64 specific implementation of the reliable stacktracer, >>> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable >>> trace" whenever it finds an exception frame on the stack. Stack frames >>> are classified as exception frames if the STACK_FRAME_REGS_MARKER magic, >>> as written by exception prologues, is found at a particular location. >>> >>> However, as observed by Joe Lawrence, it is possible in practice that >>> non-exception stack frames can alias with prior exception frames and thus, >>> that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER on >>> the stack. It in turn falsely reports an unreliable stacktrace and blocks >>> any live patching transition to finish. Said condition lasts until the >>> stack frame is overwritten/initialized by function call or other means. >>> >>> In principle, we could mitigate this by making the exception frame >>> classification condition in save_stack_trace_tsk_reliable() stronger: >>> in addition to testing for STACK_FRAME_REGS_MARKER, we could also take into >>> account that for all exceptions executing on the kernel stack >>> - their stack frames's backlink pointers always match what is saved >>> in their pt_regs instance's ->gpr[1] slot and that >>> - their exception frame size equals STACK_INT_FRAME_SIZE, a value >>> uncommonly large for non-exception frames. >>> >>> However, while these are currently true, relying on them would make the >>> reliable stacktrace implementation more sensitive towards future changes in >>> the exception entry code. Note that false negatives, i.e. not detecting >>> exception frames, would silently break the live patching consistency model. >>> >>> Furthermore, certain other places (diagnostic stacktraces, perf, xmon) >>> rely on STACK_FRAME_REGS_MARKER as well. >>> >>> Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER >>> for those exceptions running on the "normal" kernel stack and returning >>> to kernelspace: because the topmost frame is ignored by the reliable stack >>> tracer anyway, returns to userspace don't need to take care of clearing >>> the marker. >>> >>> Furthermore, as I don't have the ability to test this on Book 3E or >>> 32 bits, limit the change to Book 3S and 64 bits. >>> >>> Finally, make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on >>> PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended >>> on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies >>> PPC_BOOK3S_64, there's no functional change here. >> >> That has nothing to do with the fix and should really be in a separate >> patch. >> >> I can split it when applying. > > If you don't mind, that would be nice! Or simply drop that > chunk... Otherwise, let me know if I shall send a split v2 for this > patch [1/4] only. No worries, I split it out: commit a50d3250d7ae34c561177a1f9cfb79816fcbcff1 Author: Nicolai Stange AuthorDate: Thu Jan 31 16:41:50 2019 +1100 Commit: Michael Ellerman CommitDate: Thu Jan 31 16:43:29 2019 +1100 powerpc/64s: Make reliable stacktrace dependency clearer Make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies PPC_BOOK3S_64, there's no functional change here. Signed-off-by: Nicolai Stange Signed-off-by: Joe Lawrence [mpe: Split out of larger patch] Signed-off-by: Michael Ellerman diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 2890d36eb531..73bf87b1d274 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -220,7 +220,7 @@ config PPC select HAVE_PERF_USER_STACK_DUMP select HAVE_RCU_TABLE_FREE if SMP select HAVE_REGS_AND_STACK_ACCESS_API - select HAVE_RELIABLE_STACKTRACE if PPC64 && CPU_LITTLE_ENDIAN + select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select HAVE_SYSCALL_TRACEPOINTS select HAVE_VIRT_CPU_ACCOUNTING select HAVE_IRQ_TIME_ACCOUNTING cheers
Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem
On Wed, Jan 30, 2019 at 8:17 PM Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 07:28:12PM -0800, Dan Williams wrote:
[..]
> > > Again HMM API can evolve, i am happy to help with any such change, given
> > > it provides benefit to either mm or device driver (ie changing the HMM
> > > just for the sake of changing the HMM API would not make much sense to
> > > me).
> > >
> > > So if after converting driver A, B and C we see that it would be nicer
> > > to change HMM in someway then i will definitly do that and this patchset
> > > is a testimony of that. Converting ODP to use HMM is easier after this
> > > patchset and this patchset changes the HMM API. I will be updating the
> > > nouveau driver to the new API and use the new API for the other driver
> > > patchset i am working on.
> > >
> > > If i bump again into something that would be better done any differently
> > > i will definitly change the HMM API and update all upstream driver
> > > accordingly.
> > >
> > > I am a strong believer in full freedom for internal kernel API changes
> > > and my intention have always been to help and facilitate such process.
> > > I am sorry this was unclear to any body :( and i am hopping that this
> > > email make my intention clear.''
> >
> > A simple way to ensure that out-of-tree consumers don't come beat us
> > up over a backwards incompatible HMM change is to mark all the exports
> > with _GPL. I'm not requiring that, the devm_memremap_pages() fight was
> > hard enough, but the pace of new exports vs arrival of consumers for
> > those exports has me worried that this arrangement will fall over at
> > some point.
>
> I was reluctant with the devm_memremap_pages() GPL changes because i
> think we should not change symbol export after an initial choice have
> been made on those.
>
> I don't think GPL or non GPL export change one bit in respect to out
> of tree user. They know they can not make any legitimate regression
> claim, nor should we care. So i fail to see how GPL export would make
> it any different.
It does matter. It's a perennial fight. For a recent example see the
discussion around: "x86/fpu: Don't export __kernel_fpu_{begin,end}()".
If you're not sure you can keep an api trivially stable it should have
a GPL export to minimize the exposure surface of out-of-tree users
that might grow attached to it.
>
> > Another way to help allay these worries is commit to no new exports
> > without in-tree users. In general, that should go without saying for
> > any core changes for new or future hardware.
>
> I always intend to have an upstream user the issue is that the device
> driver tree and the mm tree move a different pace and there is always
> a chicken and egg problem. I do not think Andrew wants to have to
> merge driver patches through its tree, nor Linus want to have to merge
> drivers and mm trees in specific order. So it is easier to introduce
> mm change in one release and driver change in the next. This is what
> i am doing with ODP. Adding things necessary in 5.1 and working with
> Mellanox to have the ODP HMM patch fully tested and ready to go in
> 5.2 (the patch is available today and Mellanox have begin testing it
> AFAIK). So this is the guideline i will be following. Post mm bits
> with driver patches, push to merge mm bits one release and have the
> driver bits in the next. I do hope this sound fine to everyone.
The track record to date has not been "merge HMM patch in one release
and merge the driver updates the next". If that is the plan going
forward that's great, and I do appreciate that this set came with
driver changes, and maintain hope the existing exports don't go
user-less for too much longer.
> It is also easier for the driver folks as then they do not need to
> have a special tree just to test my changes. They can integrate it
> in their regular workflow ie merge the new kernel release in their
> tree and then start pilling up changes to their driver for the next
> kernel release.
Everyone agrees that coordinating cross-tree updates is hard, but it's
managaeble. HMM as far I can see is taking an unprecedented approach
to early merging of core infrastructure.
Re: general protection fault in debugfs_create_files
Hello, again.
syzbot is hitting a similar crash due to debugfs_create_dir() returning -EEXIST.
Should debugfs_create_dir() return NULL as well? Or should the caller use
IS_ERR_OR_NULL() ?
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -861,6 +861,8 @@ int blk_mq_debugfs_register(struct request_queue *q)
blk_debugfs_root);
if (!q->debugfs_dir)
return -ENOMEM;
+ if (IS_ERR(q->debugfs_dir))
+ printk("debugfs_create_dir=%ld\n", PTR_ERR(q->debugfs_dir));
if (!debugfs_create_files(q->debugfs_dir, q,
blk_mq_debugfs_queue_attrs))
--
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
while (1) {
if (fork() == 0) {
int fd = open("/dev/loop-control", O_RDWR);
ioctl(fd, 0x4c81, 0);
ioctl(fd, 0x4c80, 0);
close(fd);
_exit(0);
}
}
return 0;
}
--
[ 55.613954] debugfs_create_dir=-17
[ 55.617779] BUG: unable to handle kernel NULL pointer dereference at
0047
[ 55.622521] #PF error: [normal kernel read fault]
[ 55.625271] PGD 800109d7a067 P4D 800109d7a067 PUD 109d7b067 PMD 0
[ 55.630875] Oops: [#1] SMP DEBUG_PAGEALLOC PTI
[ 55.634621] CPU: 0 PID: 9122 Comm: a.out Not tainted
5.0.0-rc4-next-20190130+ #744
[ 55.638349] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 55.644608] RIP: 0010:debugfs_create_files+0x5/0x60
[ 55.647245] Code: 00 48 8d bb 28 05 00 00 e8 f8 34 43 00 48 8d bb 18 05 00
00 48 8b 75 00 5b 5d e9 06 e5 eb ff 66 0f 1f 44 00 00 55 48 89 fd 53 <48> 8b 47
58 48 89 d3 48 89 b0 90 03 00 00 48 8b 3a 48 85 ff 75 0e
[ 55.655741] RSP: 0018:a078839ebd50 EFLAGS: 00010246
[ 55.658403] RAX: ffef RBX: 8b130d1d8008 RCX:
[ 55.662047] RDX: b2e4d0a0 RSI: 8b130d1d8008 RDI: ffef
[ 55.665353] RBP: ffef R08: R09:
[ 55.668639] R10: 0001 R11: 0004 R12:
[ 55.671909] R13: 8b130d1d80d0 R14: 8b130d1d8600 R15: 8b132d12c1c8
[ 55.675171] FS: 7fda47cb6740() GS:8b133940()
knlGS:
[ 55.678789] CS: 0010 DS: ES: CR0: 80050033
[ 55.681596] CR2: 0047 CR3: 00010c014006 CR4: 001606f0
[ 55.684872] Call Trace:
[ 55.686606] blk_mq_debugfs_register+0x54/0x160
[ 55.689093] blk_register_queue+0xb2/0x190
[ 55.691396] __device_add_disk+0x31f/0x4f0
[ 55.693623] loop_add+0x1ef/0x280 [loop]
[ 55.695773] loop_control_ioctl+0x104/0x140 [loop]
[ 55.698190] do_vfs_ioctl+0x9f/0x6e0
[ 55.700202] ? lockdep_hardirqs_on+0x122/0x1b0
[ 55.702488] ? syscall_trace_enter+0x1c4/0x340
[ 55.707327] ? syscall_trace_enter+0x1c4/0x340
[ 55.709946] ksys_ioctl+0x5b/0x90
[ 55.712269] __x64_sys_ioctl+0x11/0x20
[ 55.714434] do_syscall_64+0x55/0x210
[ 55.719649] entry_SYSCALL_64_after_hwframe+0x49/0xbe
On 2019/01/31 3:53, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 02495e76ded5 Add linux-next specific files for 20190130
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=172ed528c0
> kernel config: https://syzkaller.appspot.com/x/.config?x=a2b2e9c0bc43c14d
> dashboard link: https://syzkaller.appspot.com/bug?extid=a9d09761be47db706560
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=149209ef40
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e00c2f40
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a9d09761be47db706...@syzkaller.appspotmail.com
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 8264 Comm: syz-executor060 Not tainted 5.0.0-rc4-next-20190130 #22
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:debugfs_create_files+0x2e/0x140 block/blk-mq-debugfs.c:842
> Code: 41 56 49 89 fe 41 55 41 54 49 89 f4 53 48 89 d3 e8 87 d0 f3 fd 49 8d 7e
> 58 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 e3
> 00 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b
> RSP: 0018:88809331f868 EFLAGS: 00010203
> RAX: dc00 RBX: 8881d400 RCX: 82d9f665
> RDX: 0008 RSI: 838e48c9 RDI: 0047
> RBP: 88809331f888 R08:
linux-next: powerpcle qemu boot failure after merge of the akpm tree
Hi all, [I am guessing that is is something in Andrew's tree that has caused this.] My qemu boot of the powerpc pseries_le_defconfig config failed like this: htab_hash_mask= 0x1 - numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff] Kernel panic - not syncing: sparse_buffer_init: Failed to allocate 2147483648 bytes align=0x1 nid=0 from=fff CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4 #2 Call Trace: [c105bbd0] [c0b1345c] dump_stack+0xb0/0xf4 (unreliable) [c105bc10] [c020] panic+0x168/0x3b8 [c105bcb0] [c0e701c8] sparse_init_nid+0x178/0x550 [c105bd70] [c0e709b4] sparse_init+0x210/0x238 [c105bdb0] [c0e468f4] initmem_init+0x1e0/0x260 [c105be80] [c0e3b9b0] setup_arch+0x354/0x3d4 [c105bef0] [c0e33afc] start_kernel+0x98/0x648 [c105bf90] [c000b270] start_here_common+0x1c/0x52c -- Cheers, Stephen Rothwell pgpl7hc2SZBcR.pgp Description: OpenPGP digital signature
Re: [PATCH] ipconfig: make the wait for carrier timeout configurable
From: Martin Kepplinger
Date: Mon, 28 Jan 2019 12:30:05 +0100
> From: Manfred Schlaegl
>
> commit 3fb72f1e6e61 ("ipconfig wait for carrier") added a
> "wait for carrier" policy, with a fixed worst case maximum wait
> of two minutes.
>
> This makes the wait for carrier timeout configurable (0 - 240 seconds).
>
> The informative timeout messages introduced with
> commit 5e404cd65860 ("ipconfig: add informative timeout messages while
> waiting for carrier") were adapted. Message output is done in a fixed
> interval of 20 seconds, just like before (240/12).
>
> Signed-off-by: Manfred Schlaegl
> Signed-off-by: Martin Kepplinger
I would prefer that this be implemented using a kernel command line
parameter.
That way you don't need to rebuild the kernel to adjust the value.
Thanks.
Re: [PATCH] Bluetooth: hci_uart: Switch pty driver to slave side in tty_set_termios()
On Wed, Jan 30, 2019 at 11:07:38AM +0100, Johan Hovold wrote:
> On Sun, Jan 27, 2019 at 10:53:02PM -0800, Myungho Jung wrote:
> > tty_set_termios() should be called with slave side of pty driver. So, If
> > tty driver is pty master, it needs to be switched to ->link.
>
> I'm not sure that's the right solution. PTYs are virtual devices used
> for IPC and neither end (master or slave) have support for modem
> control or baud rates.
>
> > Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com
> > Signed-off-by: Myungho Jung
> > ---
> > drivers/bluetooth/hci_ldisc.c | 20 +++-
> > 1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> > index fbf7b4df23ab..90c5ea8c399b 100644
> > --- a/drivers/bluetooth/hci_ldisc.c
> > +++ b/drivers/bluetooth/hci_ldisc.c
> > @@ -299,10 +299,18 @@ static int hci_uart_send_frame(struct hci_dev *hdev,
> > struct sk_buff *skb)
> > return 0;
> > }
> >
> > +/* If driver is pty master, return slave side */
> > +static struct tty_struct *hci_uart_get_real_tty(struct tty_struct *tty)
> > +{
> > + return (tty->driver->type == TTY_DRIVER_TYPE_PTY &&
> > +tty->driver->subtype == PTY_TYPE_MASTER) ? tty->link : tty;
> > +}
> > +
> > /* Flow control or un-flow control the device */
> > void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
> > {
> > struct tty_struct *tty = hu->tty;
> > + struct tty_struct *real_tty;
> > struct ktermios ktermios;
> > int status;
> > unsigned int set = 0;
> > @@ -314,11 +322,12 @@ void hci_uart_set_flow_control(struct hci_uart *hu,
> > bool enable)
> > return;
> > }
> >
> > + real_tty = hci_uart_get_real_tty(tty);
> > if (enable) {
> > /* Disable hardware flow control */
> > - ktermios = tty->termios;
> > + ktermios = real_tty->termios;
> > ktermios.c_cflag &= ~CRTSCTS;
> > - status = tty_set_termios(tty, &ktermios);
> > + status = tty_set_termios(real_tty, &ktermios);
> > BT_DBG("Disabling hardware flow control: %s",
> >status ? "failed" : "success");
>
> So instead of these pointless calls to set the slave termios and
> modem-control state, you might as well bail out early above (and
> similarly in set_baudrate()).
>
> Using n_hci for a master pty really makes no sense at all, so we could
> even bail out at ldisc open, but perhaps that can be discussed and
> addressed later.
>
> Johan
Hi Johan,
I fixed it to just return -EOPNOTSUPP if NULL in ath_setup().
Thanks,
Myungho
Re: [PATCH v2] iio: adc: ti-ads7950: inconsistency with spi msg
On Sat, Jan 26, 2019 at 10:30 AM Jonathan Cameron wrote:
>
> On Fri, 25 Jan 2019 10:20:22 -0800
> justinpo...@gmail.com wrote:
>
> > From: Justin Chen
> >
> > To read a channel we require 3 cycles to send, process, and receive
> > the data. The transfer buffer for the third transaction is left blank.
> > This leaves it up to the SPI driver to decide what to do.
> Interesting. I think that means you may have a bug in your SPI driver.
> The pointer in question is always left set to NULL in the adc
> driver (not explicitly but it will be because ultimately comes from
> a kzalloc).
>
> Documentation for an SPI message makes it clear that NULL is
> allowed. From include/linux/spi/spi.h
>
> "* Those segments always read the same number of bits as they
> * write; but one or the other is easily ignored by passing a null buffer
> * pointer. "
>
> Hmm. It does say 'ignored'. My assumption has always been that
> means it would be filled with zeros, but maybe I'm wrong.
>
> Mark?
>
I looked more into this and other SPI drivers do fill it with zeros.
I'll submit a patch for the SPI driver instead and see what the SPI
maintainers say.
Thanks,
Justin
> >
> > In one particular case, if the tx buffer is not set the spi driver
> > sets it to 0xff. This puts the ADC in a alarm programming state,
> > therefore the following read to a channel becomes erroneous.
> >
> > Instead of leaving us to the mercy of the SPI driver, we send the
> > ADC cmd on the third transaction to prevent inconsistent behavior.
> >
> > Fixes: 902c4b2446d4 ("iio: adc: New driver for TI ADS7950 chips")
> > Signed-off-by: Justin Chen
> > ---
> > drivers/iio/adc/ti-ads7950.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
> > index 0ad6359..1255d8b 100644
> > --- a/drivers/iio/adc/ti-ads7950.c
> > +++ b/drivers/iio/adc/ti-ads7950.c
> > @@ -422,6 +422,7 @@ static int ti_ads7950_probe(struct spi_device *spi)
> > st->scan_single_xfer[1].tx_buf = &st->single_tx;
> > st->scan_single_xfer[1].len = 2;
> > st->scan_single_xfer[1].cs_change = 1;
> > + st->scan_single_xfer[2].tx_buf = &st->single_tx;
> > st->scan_single_xfer[2].rx_buf = &st->single_rx;
> > st->scan_single_xfer[2].len = 2;
> >
>
[PATCH v2] arm64: dts: qcom: sdm845: Add clocks and iommus to WCN3990 WLAN node
From: Douglas Anderson
When commit be7019103469 ("dts: arm64/sdm845: Add WCN3990 WLAN module
device node") was posted upstream no clocks were specified. However,
when the pack was picked into the Chrome OS kernel tree (allegedly
directly from the mailing list post) it had clock properties.
I presume that the clock should be there, so let's add it.
Fixes: be7019103469 ("dts: arm64/sdm845: Add WCN3990 WLAN module device node")
Signed-off-by: Douglas Anderson
[bjorn: Add also the required iommus property]
Signed-off-by: Bjorn Andersson
---
Hijacking Doug's fixup patch to also add the missing iommus property. Without
this the MTP reboots once the ath10k is trying to exercise the copyengine.
arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cba09899282e..58f034664336 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2422,6 +2422,8 @@
reg = <0 0x1880 0 0x80>;
reg-names = "membase";
memory-region = <&wlan_msa_mem>;
+ clock-names = "cxo_ref_clk_pin";
+ clocks = <&rpmhcc RPMH_RF_CLK2>;
interrupts =
,
,
@@ -2435,6 +2437,7 @@
,
,
;
+ iommus = <&apps_smmu 0x0040 0x1>;
};
};
--
2.18.0
Re: [PATCH] Bluetooth: Add NULL check for tiocmget() and tiocmset()
On Wed, Jan 30, 2019 at 10:59:38AM +0100, Johan Hovold wrote: > On Sun, Jan 27, 2019 at 10:59:13PM -0800, Myungho Jung wrote: > > tiocmget() and tiocmset() operations are optional and some tty drivers > > like pty miss the operations. We need NULL check before referencing > > them. > > Good catch. I suggest splitting these fixes in two separate patches > (after addressing Marcel's comments). > > Don't forget to CC stable and add a Fixes-tag for each, as we we want to > have this backported to stable. > > > Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com > > Actually, these two bugs were never reported by sysbot AFAIKT so no need > to give credit to anyone else here. > > > Signed-off-by: Myungho Jung > > --- > > drivers/bluetooth/hci_ath.c | 13 - > > drivers/bluetooth/hci_ldisc.c | 5 + > > 2 files changed, 13 insertions(+), 5 deletions(-) > > Johan Hi Johan, Thanks for reviewing my patch. This change is not directly related to the issue that syzbot reported but the test will keep crashing without this fix because it will finally reach ath_hci_uart_work(). I updated and resubmitted patch. Thanks, Myungho
linux-next: build warning after merge of the akpm-current tree
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from arch/x86/include/asm/percpu.h:45,
from arch/x86/include/asm/current.h:6,
from include/linux/sched.h:12,
from include/linux/uaccess.h:5,
from fs/proc/base.c:51:
fs/proc/base.c: In function 'proc_smack_attr_dir_lookup':
include/linux/kernel.h:73:25: warning: passing argument 4 of
'proc_pident_lookup' makes pointer from integer without a cast
[-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~
fs/proc/base.c:2602:7: note: in expansion of macro 'ARRAY_SIZE'
ARRAY_SIZE(LSM##_attr_dir_stuff)); \
^~
fs/proc/base.c:2615:1: note: in expansion of macro 'LSM_DIR_OPS'
LSM_DIR_OPS(smack);
^~~
fs/proc/base.c:2454:31: note: expected 'const struct pid_entry *' but argument
is of type 'long unsigned int'
const struct pid_entry *end)
^~~
Introduced by commit
f6e3521a4c5b ("proc: calculate end pointer for /proc/*/* lookup at compile
time")
interacting with commit
6d9c939dbe4d ("procfs: add smack subdir to attrs")
from the security tree.
I have applied the following merge fix patch
From: Stephen Rothwell
Date: Thu, 31 Jan 2019 15:56:56 +1100
Subject: [PATCH] proc: merge fix for proc_pident_lookup() API change
Signed-off-by: Stephen Rothwell
---
fs/proc/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 4ac7f32c1929..3daca4367d29 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2599,7 +2599,7 @@ static struct dentry *proc_##LSM##_attr_dir_lookup(struct
inode *dir, \
{ \
return proc_pident_lookup(dir, dentry, \
LSM##_attr_dir_stuff, \
- ARRAY_SIZE(LSM##_attr_dir_stuff)); \
+ LSM##_attr_dir_stuff +
ARRAY_SIZE(LSM##_attr_dir_stuff)); \
} \
\
static const struct inode_operations proc_##LSM##_attr_dir_inode_ops = { \
--
2.20.1
---
Cheers,
Stephen Rothwell
pgpzYnqToccFd.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains
On Wed 30 Jan 16:39 PST 2019, Bjorn Andersson wrote:
> From: Rajendra Nayak
>
> With rpmh ARC resources being modelled as power domains with performance
> state, we need to proxy vote on these for SDM845.
> Add support to vote on multiple of them, now that genpd supports
> associating mutliple power domains to a device.
>
> Tested-by: Sibi Sankar
> Reviewed-by: Sibi Sankar
> Signed-off-by: Rajendra Nayak
> [bjorn: Drop device link, improve error handling, name things "proxy"]
> Signed-off-by: Bjorn Andersson
> ---
>
Applied
> Changes since v4:
> - None
>
> Changes since v3:
> - Rebased upon latest remoteproc branch
>
> drivers/remoteproc/qcom_q6v5_mss.c | 119 +++--
> 1 file changed, 114 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 07d1cc52a647..c32c63e351a0 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -25,6 +25,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -131,6 +133,7 @@ struct rproc_hexagon_res {
> char **proxy_clk_names;
> char **reset_clk_names;
> char **active_clk_names;
> + char **proxy_pd_names;
> int version;
> bool need_mem_protection;
> bool has_alt_reset;
> @@ -156,9 +159,11 @@ struct q6v5 {
> struct clk *active_clks[8];
> struct clk *reset_clks[4];
> struct clk *proxy_clks[4];
> + struct device *proxy_pds[3];
> int active_clk_count;
> int reset_clk_count;
> int proxy_clk_count;
> + int proxy_pd_count;
>
> struct reg_info active_regs[1];
> struct reg_info proxy_regs[3];
> @@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
> clk_disable_unprepare(clks[i]);
> }
>
> +static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
> +size_t pd_count)
> +{
> + int ret;
> + int i;
> +
> + for (i = 0; i < pd_count; i++) {
> + dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
> + ret = pm_runtime_get_sync(pds[i]);
> + if (ret < 0)
> + goto unroll_pd_votes;
> + }
> +
> + return 0;
> +
> +unroll_pd_votes:
> + for (i--; i >= 0; i--) {
> + dev_pm_genpd_set_performance_state(pds[i], 0);
> + pm_runtime_put(pds[i]);
> + }
> +
> + return ret;
> +};
> +
> +static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
> + size_t pd_count)
> +{
> + int i;
> +
> + for (i = 0; i < pd_count; i++) {
> + dev_pm_genpd_set_performance_state(pds[i], 0);
> + pm_runtime_put(pds[i]);
> + }
> +}
> +
> static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
> bool remote_owner, phys_addr_t addr,
> size_t size)
> @@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>
> qcom_q6v5_prepare(&qproc->q6v5);
>
> + ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> + if (ret < 0) {
> + dev_err(qproc->dev, "failed to enable proxy power domains\n");
> + goto disable_irqs;
> + }
> +
> ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
> qproc->proxy_reg_count);
> if (ret) {
> dev_err(qproc->dev, "failed to enable proxy supplies\n");
> - goto disable_irqs;
> + goto disable_proxy_pds;
> }
>
> ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
> @@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> disable_proxy_reg:
> q6v5_regulator_disable(qproc, qproc->proxy_regs,
> qproc->proxy_reg_count);
> +disable_proxy_pds:
> + q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> disable_irqs:
> qcom_q6v5_unprepare(&qproc->q6v5);
>
> @@ -841,6 +889,8 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
>
> ret = qcom_q6v5_unprepare(&qproc->q6v5);
> if (ret) {
> + q6v5_pds_disable(qproc, qproc->proxy_pds,
> + qproc->proxy_pd_count);
> q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
>qproc->proxy_clk_count);
> q6v5_regulator_disable(qproc, qproc->proxy_regs,
> @@ -1121,6 +1171,7 @@ static void qcom_msa_handover(struct qcom_q6v5 *q6v5)
>qproc->proxy_clk_count);
> q6v5_regulator_disable(qproc, qproc->proxy_regs,
> qproc->proxy_reg_count);
> + q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> }
>
> static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device *pdev)
> @@ -1181,6 +1232,45 @@ static int q6v5_init_clocks(struct device
Re: [PATCH v5 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845
On Wed 30 Jan 16:39 PST 2019, Bjorn Andersson wrote:
> The SDM845 MSS needs the load_state powerdomain voted for during the
> duration of the MSS being powered on, to let the AOSS know that it may
> not perform certain power save measures. So vote for this.
>
> Tested-by: Sibi Sankar
> Reviewed-by: Sibi Sankar
> Signed-off-by: Bjorn Andersson
> ---
>
Applied
> Changes since v4:
> - None
>
> Changes since v3:
> - None
>
> drivers/remoteproc/qcom_q6v5_mss.c | 31 --
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index c32c63e351a0..e30f5486fd20 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -133,6 +133,7 @@ struct rproc_hexagon_res {
> char **proxy_clk_names;
> char **reset_clk_names;
> char **active_clk_names;
> + char **active_pd_names;
> char **proxy_pd_names;
> int version;
> bool need_mem_protection;
> @@ -159,10 +160,12 @@ struct q6v5 {
> struct clk *active_clks[8];
> struct clk *reset_clks[4];
> struct clk *proxy_clks[4];
> + struct device *active_pds[1];
> struct device *proxy_pds[3];
> int active_clk_count;
> int reset_clk_count;
> int proxy_clk_count;
> + int active_pd_count;
> int proxy_pd_count;
>
> struct reg_info active_regs[1];
> @@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>
> qcom_q6v5_prepare(&qproc->q6v5);
>
> + ret = q6v5_pds_enable(qproc, qproc->active_pds, qproc->active_pd_count);
> + if (ret < 0) {
> + dev_err(qproc->dev, "failed to enable active power domains\n");
> + goto disable_irqs;
> + }
> +
> ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> if (ret < 0) {
> dev_err(qproc->dev, "failed to enable proxy power domains\n");
> - goto disable_irqs;
> + goto disable_active_pds;
> }
>
> ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
> @@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> qproc->proxy_reg_count);
> disable_proxy_pds:
> q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +disable_active_pds:
> + q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
> disable_irqs:
> qcom_q6v5_unprepare(&qproc->q6v5);
>
> @@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
>qproc->active_clk_count);
> q6v5_regulator_disable(qproc, qproc->active_regs,
> qproc->active_reg_count);
> + q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
>
> /* In case of failure or coredump scenario where reclaiming MBA memory
>* could not happen reclaim it here.
> @@ -1412,11 +1424,19 @@ static int q6v5_probe(struct platform_device *pdev)
> }
> qproc->active_reg_count = ret;
>
> + ret = q6v5_pds_attach(&pdev->dev, qproc->active_pds,
> + desc->active_pd_names);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to attach active power domains\n");
> + goto free_rproc;
> + }
> + qproc->active_pd_count = ret;
> +
> ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
> desc->proxy_pd_names);
> if (ret < 0) {
> dev_err(&pdev->dev, "Failed to init power domains\n");
> - goto free_rproc;
> + goto detach_active_pds;
> }
> qproc->proxy_pd_count = ret;
>
> @@ -1452,6 +1472,8 @@ static int q6v5_probe(struct platform_device *pdev)
>
> detach_proxy_pds:
> q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +detach_active_pds:
> + q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
> free_rproc:
> rproc_free(rproc);
>
> @@ -1469,6 +1491,7 @@ static int q6v5_remove(struct platform_device *pdev)
> qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
> qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
>
> + q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
> q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>
> rproc_free(qproc->rproc);
> @@ -1495,6 +1518,10 @@ static const struct rproc_hexagon_res sdm845_mss = {
> "mnoc_axi",
> NULL
> },
> + .active_pd_names = (char*[]){
> + "load_state",
> + NULL
> + },
> .proxy_pd_names = (char*[]){
> "cx",
> "mx",
> --
> 2.18.0
>
Re: [PATCH V7 3/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_do_alloc
Michael Ellerman writes: > "Aneesh Kumar K.V" writes: > >> The current code doesn't do page migration if the page allocated is a >> compound page. >> With HugeTLB migration support, we can end up allocating hugetlb pages from >> CMA region. Also, THP pages can be allocated from CMA region. This patch >> updates >> the code to handle compound pages correctly. The patch also switches to a >> single >> get_user_pages with the right count, instead of doing one get_user_pages per >> page. >> That avoids reading page table multiple times. > > It's not very obvious from the above description that the migration > logic is now being done by get_user_pages_longterm(), it just looks like > it's all being deleted in this patch. Would be good to mention that. > >> Since these page reference updates are long term pin, switch to >> get_user_pages_longterm. That makes sure we fail correctly if the guest RAM >> is backed by DAX pages. > > Can you explain that in more detail? DAX pages lifetime is dictated by file system rules and as such, we need to make sure that we free these pages on operations like truncate and punch hole. If we have long term pin on these pages, which are mostly return to userspace with elevated page count, the entity holding the long term pin may not be aware of the fact that file got truncated and the file system blocks possibly got reused. That can result in corruption. Work is going on to solve this issue by either making operations like truncate wait or to make these elevated reference counted page/file system blocks not to be released back to the file system free list. Till then we prevent long term pin on DAX pages. Now that we have an API for long term pin, we should ideally be using that in the vfio code. > >> The patch also converts the hpas member of mm_iommu_table_group_mem_t to a >> union. >> We use the same storage location to store pointers to struct page. We cannot >> update all the code path use struct page *, because we access hpas in real >> mode >> and we can't do that struct page * to pfn conversion in real mode. > > That's a pain, it's asking for bugs mixing two different values in the > same array. But I guess it's the least worst option. > > It sounds like that's a separate change you could do in a separate > patch. But it's not, because it's tied to the fact that we're doing a > single GUP call. -aneesh
[PATCH 1/2] mfd: at91-usart: Constify at91_usart_spi_subdev and at91_usart_serial_subdev
They are never get changed, make them constant.
While at it, fix indent as well.
Signed-off-by: Axel Lin
---
drivers/mfd/at91-usart.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
index d20747f612c1..684d3a8db661 100644
--- a/drivers/mfd/at91-usart.c
+++ b/drivers/mfd/at91-usart.c
@@ -15,15 +15,15 @@
#include
#include
-static struct mfd_cell at91_usart_spi_subdev = {
- .name = "at91_usart_spi",
- .of_compatible = "microchip,at91sam9g45-usart-spi",
- };
+static const struct mfd_cell at91_usart_spi_subdev = {
+ .name = "at91_usart_spi",
+ .of_compatible = "microchip,at91sam9g45-usart-spi",
+};
-static struct mfd_cell at91_usart_serial_subdev = {
- .name = "atmel_usart_serial",
- .of_compatible = "atmel,at91rm9200-usart-serial",
- };
+static const struct mfd_cell at91_usart_serial_subdev = {
+ .name = "atmel_usart_serial",
+ .of_compatible = "atmel,at91rm9200-usart-serial",
+};
static int at91_usart_mode_probe(struct platform_device *pdev)
{
--
2.17.1
[PATCH 2/2] mfd: at91-usart: No need to copy mfd_cell in probe
Use pointer instead.
Signed-off-by: Axel Lin
---
drivers/mfd/at91-usart.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
index 684d3a8db661..6a8351a4588e 100644
--- a/drivers/mfd/at91-usart.c
+++ b/drivers/mfd/at91-usart.c
@@ -27,17 +27,17 @@ static const struct mfd_cell at91_usart_serial_subdev = {
static int at91_usart_mode_probe(struct platform_device *pdev)
{
- struct mfd_cell cell;
+ const struct mfd_cell *cell;
u32 opmode = AT91_USART_MODE_SERIAL;
device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
switch (opmode) {
case AT91_USART_MODE_SPI:
- cell = at91_usart_spi_subdev;
+ cell = &at91_usart_spi_subdev;
break;
case AT91_USART_MODE_SERIAL:
- cell = at91_usart_serial_subdev;
+ cell = &at91_usart_serial_subdev;
break;
default:
dev_err(&pdev->dev, "atmel,usart-mode has an invalid value
%u\n",
@@ -45,7 +45,7 @@ static int at91_usart_mode_probe(struct platform_device *pdev)
return -EINVAL;
}
- return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, &cell, 1,
+ return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, cell, 1,
NULL, 0, NULL);
}
--
2.17.1
linux-next: manual merge of the akpm-current tree with the tip tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/sched.h
between commit:
15917dc02841 ("sched: Remove stale PF_MUTEX_TESTER bit")
from the tip tree and commit:
ca299cb98649 ("mm/cma: add PF flag to force non cma alloc")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/sched.h
index bb68abafac29,1ef3995b7564..
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1409,6 -1423,8 +1423,7 @@@ extern struct pid *cad_pid
#define PF_UMH0x0200 /* I'm an
Usermodehelper process */
#define PF_NO_SETAFFINITY 0x0400 /* Userland is not allowed to
meddle with cpus_allowed */
#define PF_MCE_EARLY 0x0800 /* Early kill for mce process
policy */
+ #define PF_MEMALLOC_NOCMA 0x1000 /* All allocation request will
have _GFP_MOVABLE cleared */
-#define PF_MUTEX_TESTER 0x2000 /* Thread belongs to
the rt mutex tester */
#define PF_FREEZER_SKIP 0x4000 /* Freezer should not
count it as freezable */
#define PF_SUSPEND_TASK 0x8000 /* This thread called
freeze_processes() and should not be frozen */
pgp4DkVDtoumO.pgp
Description: OpenPGP digital signature
Re: [PATCH V7 5/5] i2c: tegra: Add I2C interface timing support
В Wed, 30 Jan 2019 08:01:36 -0800
Sowjanya Komatineni пишет:
> This patch adds I2C interface timing registers support for
> proper bus rate configuration along with meeting the i2c spec
> setup and hold times based on the tuning performed on Tegra210,
> Tegra186 and Tegra194 platforms.
>
> I2C_INTERFACE_TIMING_0 register contains TLOW and THIGH field
> and Tegra I2C controller design uses them as a part of internal
> clock divisor.
>
> I2C_INTERFACE_TIMING_1 register contains the setup and hold times
> for start and stop conditions.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> [V7] : Minor updates to timing implementation
> [V5/V6] : Added this Interface timing patch in V5 of the patch
> series.
>
> drivers/i2c/busses/i2c-tegra.c | 192
> - 1 file changed, 169
> insertions(+), 23 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c
> b/drivers/i2c/busses/i2c-tegra.c index 623bf4f275cd..ad8eeac5a745
> 100644 --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -130,6 +130,15 @@
> #define I2C_MST_FIFO_STATUS_TX_MASK 0xff
> #define I2C_MST_FIFO_STATUS_TX_SHIFT 16
>
> +#define I2C_INTERFACE_TIMING_0 0x94
> +#define I2C_THIGH_SHIFT 8
> +#define I2C_INTERFACE_TIMING_1 0x98
> +
> +#define I2C_STANDARD_MODE10
> +#define I2C_FAST_MODE40
> +#define I2C_FAST_PLUS_MODE 100
> +#define I2C_HS_MODE 350
> +
> /* Packet header size in bytes */
> #define I2C_PACKET_HEADER_SIZE 12
>
> @@ -167,7 +176,10 @@ enum msg_end_type {
> * @has_config_load_reg: Has the config load register to load the new
> * configuration.
> * @clk_divisor_hs_mode: Clock divisor in HS mode.
> - * @clk_divisor_std_fast_mode: Clock divisor in standard/fast mode.
> It is
> + * @clk_divisor_std_mode: Clock divisor in standard mode. It is
> + * applicable if there is no fast clock source i.e.
> single clock
> + * source.
> + * @clk_divisor_fast_mode: Clock divisor in fast mode. It is
> * applicable if there is no fast clock source i.e.
> single clock
> * source.
> * @clk_divisor_fast_plus_mode: Clock divisor in fast mode plus. It
> is @@ -182,6 +194,16 @@ enum msg_end_type {
> * be transferred in one go.
> * @supports_bus_clear: Bus Clear support to recover from bus hang
> during
> * SDA stuck low from device for some unknown reasons.
> + * @tlow_std_mode: Low period of the clock in standard mode.
> + * @thigh_std_mode: High period of the clock in standard mode.
> + * @tlow_fast_fastplus_mode: Low period of the clock in
> fast/fast-plus modes.
> + * @thigh_fast_fastplus_mode: High period of the clock in
> fast/fast-plus modes.
> + * @setup_hold_time_std_mode: Setup and hold time for start and stop
> conditions
> + * in standard mode.
> + * @setup_hold_time_fast_fast_plus_mode: Setup and hold time for
> start and stop
> + * conditions in fast/fast-plus modes.
> + * @setup_hold_time_hs_mode: Setup and hold time for start and stop
> conditions
> + * in HS mode.
> */
> struct tegra_i2c_hw_feature {
> bool has_continue_xfer_support;
> @@ -189,12 +211,20 @@ struct tegra_i2c_hw_feature {
> bool has_single_clk_source;
> bool has_config_load_reg;
> int clk_divisor_hs_mode;
> - int clk_divisor_std_fast_mode;
> + int clk_divisor_std_mode;
> + int clk_divisor_fast_mode;
> u16 clk_divisor_fast_plus_mode;
> bool has_multi_master_mode;
> bool has_slcg_override_reg;
> bool has_mst_fifo;
> bool supports_bus_clear;
> + u8 tlow_std_mode;
> + u8 thigh_std_mode;
> + u8 tlow_fast_fastplus_mode;
> + u8 thigh_fast_fastplus_mode;
> + u32 setup_hold_time_std_mode;
> + u32 setup_hold_time_fast_fast_plus_mode;
> + u32 setup_hold_time_hs_mode;
> };
>
> /**
> @@ -262,6 +292,7 @@ struct tegra_i2c_dev {
> };
>
> static struct dma_chan *chan;
> +static bool first_init;
Same as for the chan, please don't use global variables.
> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
> unsigned long reg)
> @@ -639,6 +670,49 @@ static int tegra_i2c_wait_for_config_load(struct
> tegra_i2c_dev *i2c_dev) return 0;
> }
>
> +static int tegra_i2c_set_timing(struct tegra_i2c_dev *i2c_dev)
> +{
> + u32 val;
> + u32 tsu_thd = 0;
> + u8 tlow = 0;
> + u8 thigh = 0;
> + u32 clk_multiplier;
> + int err = 0;
> +
> + if ((i2c_dev->bus_clk_rate > I2C_STANDARD_MODE) &&
> + (i2c_dev->bus_clk_rate <= I2C_FAST_PLUS_MODE)) {
> + tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
> + thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
> + tsu_thd =
> i2c_dev->hw->setup_hold_time_fast_
Re: [PATCH v3 1/2] mm: add probe_user_read()
Christophe Leroy writes:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a pagefault_disable()/enable()
> pair, etc. :
> show_user_instructions()
> bad_stack_expansion()
> p9_hmi_special_emu()
> fsl_pci_mcheck_exception()
> read_user_stack_64()
> read_user_stack_32() on PPC64
> read_user_stack_32() on PPC32
> power_pmu_bhrb_to()
>
> In the same spirit as probe_kernel_read(), this patch adds
> probe_user_read().
>
> probe_user_read() does the same as probe_kernel_read() but
> first checks that it is really a user address.
>
> The patch defines this function as a static inline so the "size"
> variable can be examined for const-ness by the check_object_size()
> in __copy_from_user_inatomic()
>
> Signed-off-by: Christophe Leroy
> ---
> v3: Moved 'Returns:" comment after description.
> Explained in the commit log why the function is defined static inline
>
> v2: Added "Returns:" comment and removed probe_user_address()
>
> include/linux/uaccess.h | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index 37b226e8df13..ef99edd63da3 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -263,6 +263,40 @@ extern long strncpy_from_unsafe(char *dst, const void
> *unsafe_addr, long count);
> #define probe_kernel_address(addr, retval) \
> probe_kernel_read(&retval, addr, sizeof(retval))
>
> +/**
> + * probe_user_read(): safely attempt to read from a user location
> + * @dst: pointer to the buffer that shall take the data
> + * @src: address to read from
> + * @size: size of the data chunk
> + *
> + * Safely read from address @src to the buffer at @dst. If a kernel fault
> + * happens, handle that and return -EFAULT.
> + *
> + * We ensure that the copy_from_user is executed in atomic context so that
> + * do_page_fault() doesn't attempt to take mmap_sem. This makes
> + * probe_user_read() suitable for use within regions where the caller
> + * already holds mmap_sem, or other locks which nest inside mmap_sem.
> + *
> + * Returns: 0 on success, -EFAULT on error.
> + */
> +
> +#ifndef probe_user_read
> +static __always_inline long probe_user_read(void *dst, const void __user
> *src,
> + size_t size)
> +{
> + long ret;
> +
I wonder if we should explicitly switch to USER_DS here?
That would be sort of unusual, but the whole reason for this helper
existing is to make sure we safely read from user memory and not
accidentally from kernel.
cheers
> + if (!access_ok(src, size))
> + return -EFAULT;
> +
> + pagefault_disable();
> + ret = __copy_from_user_inatomic(dst, src, size);
> + pagefault_enable();
> +
> + return ret ? -EFAULT : 0;
> +}
> +#endif
> +
> #ifndef user_access_begin
> #define user_access_begin(ptr,len) access_ok(ptr, len)
> #define user_access_end() do { } while (0)
> --
> 2.13.3
Re: [RESEND PATCH v2] arm64: dts: qcom: msm8998: Add rpmcc node
On 1/30/2019 10:01 PM, Marc Gonzalez wrote:
Add MSM8998 Resource Power Manager Clock Controller DT node.
Reviewed-by: Jeffrey Hugo
Reviewed-by: Bjorn Andersson
Signed-off-by: Marc Gonzalez
---
Detach this patch from UFS series
Resend because SMTP server was blacklisted.
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index a6d66cf77403..6f4f4b79853b 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
/ {
@@ -266,6 +267,11 @@
rpm_requests: rpm-requests {
compatible = "qcom,rpm-msm8998";
qcom,glink-channels = "rpm_requests";
+
+ rpmcc: clock-controller {
+ compatible = "qcom,rpmcc-msm8998", "qcom,rpmcc";
+ #clock-cells = <1>;
+ };
};
};
Tested-by: Sai Prakash Ranjan
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v3 2/2] powerpc: use probe_user_read()
Christophe Leroy writes:
> Instead of opencoding, use probe_user_read() to failessly
> read a user location.
>
> Signed-off-by: Christophe Leroy
> ---
> v3: No change
>
> v2: Using probe_user_read() instead of probe_user_address()
>
> arch/powerpc/kernel/process.c | 12 +---
> arch/powerpc/mm/fault.c | 6 +-
> arch/powerpc/perf/callchain.c | 20 +++-
> arch/powerpc/perf/core-book3s.c | 8 +---
> arch/powerpc/sysdev/fsl_pci.c | 10 --
> 5 files changed, 10 insertions(+), 46 deletions(-)
Looks good.
Acked-by: Michael Ellerman
cheers
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index ce393df243aa..6a4b59d574c2 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1298,16 +1298,6 @@ void show_user_instructions(struct pt_regs *regs)
>
> pc = regs->nip - (NR_INSN_TO_PRINT * 3 / 4 * sizeof(int));
>
> - /*
> - * Make sure the NIP points at userspace, not kernel text/data or
> - * elsewhere.
> - */
> - if (!__access_ok(pc, NR_INSN_TO_PRINT * sizeof(int), USER_DS)) {
> - pr_info("%s[%d]: Bad NIP, not dumping instructions.\n",
> - current->comm, current->pid);
> - return;
> - }
> -
> seq_buf_init(&s, buf, sizeof(buf));
>
> while (n) {
> @@ -1318,7 +1308,7 @@ void show_user_instructions(struct pt_regs *regs)
> for (i = 0; i < 8 && n; i++, n--, pc += sizeof(int)) {
> int instr;
>
> - if (probe_kernel_address((const void *)pc, instr)) {
> + if (probe_user_read(&instr, (void __user *)pc,
> sizeof(instr))) {
> seq_buf_printf(&s, " ");
> continue;
> }
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 887f11bcf330..ec74305fa330 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -276,12 +276,8 @@ static bool bad_stack_expansion(struct pt_regs *regs,
> unsigned long address,
> if ((flags & FAULT_FLAG_WRITE) && (flags & FAULT_FLAG_USER) &&
> access_ok(nip, sizeof(*nip))) {
> unsigned int inst;
> - int res;
>
> - pagefault_disable();
> - res = __get_user_inatomic(inst, nip);
> - pagefault_enable();
> - if (!res)
> + if (!probe_user_read(&inst, nip, sizeof(inst)))
> return !store_updates_sp(inst);
> *must_retry = true;
> }
> diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
> index 0af051a1974e..0680efb2237b 100644
> --- a/arch/powerpc/perf/callchain.c
> +++ b/arch/powerpc/perf/callchain.c
> @@ -159,12 +159,8 @@ static int read_user_stack_64(unsigned long __user *ptr,
> unsigned long *ret)
> ((unsigned long)ptr & 7))
> return -EFAULT;
>
> - pagefault_disable();
> - if (!__get_user_inatomic(*ret, ptr)) {
> - pagefault_enable();
> + if (!probe_user_read(ret, ptr, sizeof(*ret)))
> return 0;
> - }
> - pagefault_enable();
>
> return read_user_stack_slow(ptr, ret, 8);
> }
> @@ -175,12 +171,8 @@ static int read_user_stack_32(unsigned int __user *ptr,
> unsigned int *ret)
> ((unsigned long)ptr & 3))
> return -EFAULT;
>
> - pagefault_disable();
> - if (!__get_user_inatomic(*ret, ptr)) {
> - pagefault_enable();
> + if (!probe_user_read(ret, ptr, sizeof(*ret)))
> return 0;
> - }
> - pagefault_enable();
>
> return read_user_stack_slow(ptr, ret, 4);
> }
> @@ -307,17 +299,11 @@ static inline int current_is_64bit(void)
> */
> static int read_user_stack_32(unsigned int __user *ptr, unsigned int *ret)
> {
> - int rc;
> -
> if ((unsigned long)ptr > TASK_SIZE - sizeof(unsigned int) ||
> ((unsigned long)ptr & 3))
> return -EFAULT;
>
> - pagefault_disable();
> - rc = __get_user_inatomic(*ret, ptr);
> - pagefault_enable();
> -
> - return rc;
> + return probe_user_read(ret, ptr, sizeof(*ret));
> }
>
> static inline void perf_callchain_user_64(struct perf_callchain_entry_ctx
> *entry,
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index b0723002a396..4b64ddf0db68 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -416,7 +416,6 @@ static void power_pmu_sched_task(struct
> perf_event_context *ctx, bool sched_in)
> static __u64 power_pmu_bhrb_to(u64 addr)
> {
> unsigned int instr;
> - int ret;
> __u64 target;
>
> if (is_kernel_addr(addr)) {
> @@ -427,13 +426,8 @@ static __u64 power_pmu_bhrb_to(u64 addr)
> }
>
> /
Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem
On Wed, Jan 30, 2019 at 07:28:12PM -0800, Dan Williams wrote: > On Wed, Jan 30, 2019 at 10:36 AM Jerome Glisse wrote: > [..] > > > > This > > > > is one of the motivation behind HMM ie have it as an impedence layer > > > > between mm and device drivers so that mm folks do not have to under- > > > > stand every single device driver but only have to understand the > > > > contract HMM has with all device driver that uses it. > > > > > > This gets to heart of my critique of the approach taken with HMM. The > > > above statement is antithetical to > > > Documentation/process/stable-api-nonsense.rst. If HMM is trying to set > > > expectations that device-driver projects can write to a "stable" HMM > > > api then HMM is setting those device-drivers up for failure. > > > > So i am not expressing myself correctly. If someone want to change mm > > in anyway that would affect HMM user, it can and it is welcome too > > (assuming that those change are wanted by the community and motivated > > for good reasons). Here by understanding HMM contract and preserving it > > what i mean is that all you have to do is update the HMM API in anyway > > that deliver the same result to the device driver. So what i means is > > that instead of having to understand each device driver. For instance > > you have HMM provide X so that driver can do Y; then what can be Z a > > replacement for X that allow driver to do Y. The point here is that > > HMM define what Y is and provide X for current kernel mm code. If X > > ever need to change so that core mm can evolve than you can and are > > more than welcome to do it. With HMM Y is defined and you only need to > > figure out how to achieve the same end result for the device driver. > > > > The point is that you do not have to go read each device driver to > > figure out Y.driver_foo, Y.driver_bar, ... you only have HMM that > > define what Y means and is ie this what device driver are trying to > > do. > > > > Obviously here i assume that we do not want to regress features ie > > we want to keep device driver features intact when we modify anything. > > The specific concern is HMM attempting to expand the regression > boundary beyond drivers that exist in the kernel. The regression > contract that has priority is the one established for in-tree users. > If an in-tree change to mm semantics is fine for in-tree mm users, but > breaks out of tree users the question to those out of tree users is > "why isn't your use case upstream?". HMM is not that use case in and > of itself. I do not worry about out of tree user and we should not worry about them. I care only about upstream driver (AMD, Intel, NVidia) and i will not do an HMM feature if i do not intend to use it in at least one of those upstream driver. Yes i have work with NVidia on the design simply because they are the market leader on GPU compute and have talented engineers that know a little about what would work well. Not working with them to get their input on design just because their driver is closed source seems radical to me. I believe i benefited from their valuable input. But in the end my aim is, and have always been, to make the upstream kernel driver the best as possible. I will talk with anyone that can help in achieving that objective. So do not worry about non upstream driver. > [..] > > Again HMM API can evolve, i am happy to help with any such change, given > > it provides benefit to either mm or device driver (ie changing the HMM > > just for the sake of changing the HMM API would not make much sense to > > me). > > > > So if after converting driver A, B and C we see that it would be nicer > > to change HMM in someway then i will definitly do that and this patchset > > is a testimony of that. Converting ODP to use HMM is easier after this > > patchset and this patchset changes the HMM API. I will be updating the > > nouveau driver to the new API and use the new API for the other driver > > patchset i am working on. > > > > If i bump again into something that would be better done any differently > > i will definitly change the HMM API and update all upstream driver > > accordingly. > > > > I am a strong believer in full freedom for internal kernel API changes > > and my intention have always been to help and facilitate such process. > > I am sorry this was unclear to any body :( and i am hopping that this > > email make my intention clear.'' > > A simple way to ensure that out-of-tree consumers don't come beat us > up over a backwards incompatible HMM change is to mark all the exports > with _GPL. I'm not requiring that, the devm_memremap_pages() fight was > hard enough, but the pace of new exports vs arrival of consumers for > those exports has me worried that this arrangement will fall over at > some point. I was reluctant with the devm_memremap_pages() GPL changes because i think we should not change symbol export after an initial choice have been made on those. I don't think GPL or non GPL export change one
Re: [PATCH] arm64: dts: qcom: qcs404: Add rpmcc node
On 25-01-19, 10:14, Bjorn Andersson wrote: > Add the rpm clock controller node, to provide the low-noise baseband > clock for the USB PHYs, among other things. Reviewed-by: Vinod Koul -- ~Vinod
linux-next: build failure after merge of the ext3 tree
Hi Jan,
After merging the ext3 tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
ld: fs/ext2/super.o: in function `ext2_fill_super':
super.c:(.text+0x1494): undefined reference to `__divdi3'
ld: super.c:(.text+0x14bc): undefined reference to `__divdi3'
Caused by commit
455d38a0e62f ("ext2: Fix underflow in ext2_max_size()")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgp_Fd5HqW5Zp.pgp
Description: OpenPGP digital signature
[PATCH 1/3] slub: Fix comment spelling mistake
From: "Tobin C. Harding"
SLUB include file contains spelling mistake.
Fix up spelling mistake.
Signed-off-by: Tobin C. Harding
---
include/linux/slub_def.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 3a1a1dbc6f49..201a635be846 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -81,7 +81,7 @@ struct kmem_cache_order_objects {
*/
struct kmem_cache {
struct kmem_cache_cpu __percpu *cpu_slab;
- /* Used for retriving partial slabs etc */
+ /* Used for retrieving partial slabs etc */
slab_flags_t flags;
unsigned long min_partial;
unsigned int size; /* The size of an object including meta data */
--
2.20.1
[PATCH 3/3] slub: Use C89 comment style
From: "Tobin C. Harding"
SLUB include file uses a c99 comment style. In line with the rest of
the kernel lets use c89 comment style.
Use C89 comment style.
Signed-off-by: Tobin C. Harding
---
include/linux/slub_def.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index d12d0e9300f5..c8e52206a761 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -151,7 +151,7 @@ struct kmem_cache {
#else
#define slub_cpu_partial(s)(0)
#define slub_set_cpu_partial(s, n)
-#endif // CONFIG_SLUB_CPU_PARTIAL
+#endif /* CONFIG_SLUB_CPU_PARTIAL */
#ifdef CONFIG_SYSFS
#define SLAB_SUPPORTS_SYSFS
--
2.20.1
[PATCH 2/3] slub: Capitialize comment string
From: "Tobin C. Harding"
SLUB include file has particularly clean comments, one comment string is
holding us back.
Capitialize comment string.
Signed-off-by: Tobin C. Harding
---
include/linux/slub_def.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 201a635be846..d12d0e9300f5 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -110,7 +110,7 @@ struct kmem_cache {
#endif
#ifdef CONFIG_MEMCG
struct memcg_cache_params memcg_params;
- /* for propagation, maximum size of a stored attr */
+ /* For propagation, maximum size of a stored attr */
unsigned int max_attr_size;
#ifdef CONFIG_SYSFS
struct kset *memcg_kset;
--
2.20.1
[PATCH 0/3] slub: Do trivial comments fixes
From: "Tobin C. Harding" Hi Christopher, Here is a trivial patchset to wet my toes. This is my first patchset to mm, if there are some mm specific nuances in relation to when in the dev cycle (if ever) that minor (*cough* trivial) pathsets are acceptable please say so This patchset fixes comments strings in the SLUB subsystem. As per discussion at LCA I am working on getting my head around the SLUB allocator. If you specifically do *not* want me to do minor clean up while I'm reading please say so, I will not be offended. thanks, Tobin. Tobin C. Harding (3): slub: Fix comment spelling mistake slub: Capitialize comment string slub: Use C89 comment style include/linux/slub_def.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.20.1
[PATCH] staging: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
drivers/staging/erofs/Makefile| 2 +-
drivers/staging/media/davinci_vpfe/Makefile | 2 +-
drivers/staging/most/Makefile | 2 +-
drivers/staging/most/cdev/Makefile| 2 +-
drivers/staging/most/dim2/Makefile| 2 +-
drivers/staging/most/i2c/Makefile | 2 +-
drivers/staging/most/net/Makefile | 2 +-
drivers/staging/most/sound/Makefile | 2 +-
drivers/staging/most/usb/Makefile | 2 +-
drivers/staging/most/video/Makefile | 2 +-
drivers/staging/rtl8192u/Makefile | 2 +-
drivers/staging/unisys/visorhba/Makefile | 3 +--
drivers/staging/unisys/visornic/Makefile | 3 +--
drivers/staging/vc04_services/bcm2835-audio/Makefile | 3 +--
drivers/staging/vc04_services/bcm2835-camera/Makefile | 2 +-
15 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/erofs/Makefile b/drivers/staging/erofs/Makefile
index c91b652..38ab344 100644
--- a/drivers/staging/erofs/Makefile
+++ b/drivers/staging/erofs/Makefile
@@ -6,7 +6,7 @@ ccflags-y += -Wall -DEROFS_VERSION=\"$(EROFS_VERSION)\"
obj-$(CONFIG_EROFS_FS) += erofs.o
# staging requirement: to be self-contained in its own directory
-ccflags-y += -I$(src)/include
+ccflags-y += -I $(srctree)/$(src)/include
erofs-objs := super.o inode.o data.o namei.o dir.o utils.o
erofs-$(CONFIG_EROFS_FS_XATTR) += xattr.o
erofs-$(CONFIG_EROFS_FS_ZIP) += unzip_vle.o unzip_vle_lz4.o
diff --git a/drivers/staging/media/davinci_vpfe/Makefile
b/drivers/staging/media/davinci_vpfe/Makefile
index 9c57042..9268e50 100644
--- a/drivers/staging/media/davinci_vpfe/Makefile
+++ b/drivers/staging/media/davinci_vpfe/Makefile
@@ -6,5 +6,5 @@ davinci-vfpe-objs := \
# Allow building it with COMPILE_TEST on other archs
ifndef CONFIG_ARCH_DAVINCI
-ccflags-y += -Iarch/arm/mach-davinci/include/
+ccflags-y += -I $(srctree)/arch/arm/mach-davinci/include/
endif
diff --git a/drivers/staging/most/Makefile b/drivers/staging/most/Makefile
index f8bcf48..c7662f6 100644
--- a/drivers/staging/most/Makefile
+++ b/drivers/staging/most/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_MOST) += most_core.o
most_core-y := core.o
-ccflags-y += -Idrivers/staging/
+ccflags-y += -I $(srctree)/drivers/staging/
obj-$(CONFIG_MOST_CDEV)+= cdev/
obj-$(CONFIG_MOST_NET) += net/
diff --git a/drivers/staging/most/cdev/Makefile
b/drivers/staging/most/cdev/Makefile
index afb9870..21b0bd7 100644
--- a/drivers/staging/most/cdev/Makefile
+++ b/drivers/staging/most/cdev/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_MOST_CDEV) += most_cdev.o
most_cdev-objs := cdev.o
-ccflags-y += -Idrivers/staging/
+ccflags-y += -I $(srctree)/drivers/staging/
diff --git a/drivers/staging/most/dim2/Makefile
b/drivers/staging/most/dim2/Makefile
index 66676f5..6d15f04 100644
--- a/drivers/staging/most/dim2/Makefile
+++ b/drivers/staging/most/dim2/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_MOST_DIM2) += most_dim2.o
most_dim2-objs := dim2.o hal.o sysfs.o
-ccflags-y += -Idrivers/staging/
+ccflags-y += -I $(srctree)/drivers/staging/
diff --git a/drivers/staging/most/i2c/Makefile
b/drivers/staging/most/i2c/Makefile
index a7d094c..c032fea 100644
--- a/drivers/staging/most/i2c/Makefile
+++ b/drivers/staging/most/i2c/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_MOST_I2C) += most_i2c.o
most_i2c-objs := i2c.o
-ccflags-y += -Idrivers/staging/
+ccflags-y += -I $(srctree)/drivers/staging/
diff --git a/drivers/staging/most/net/Makefile
b/drivers/staging/most/net/Makefile
index 54500aa..820faec 100644
--- a/drivers/staging/most/net/Makefile
+++ b/drivers/staging/most/net/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_MOST_NET) += most_net.o
most_net-objs := net.o
-ccflags-y += -Idrivers/staging/
+ccflags-y += -I $(srctree)/drivers/staging/
diff --git a/drivers/staging/most/sound/Makefile
b/drivers/staging/most/sound/Makefile
index eee8774..5bb55bb 100644
--- a/drivers/staging/most/sound/Makefile
+++ b/drivers/staging/most/sound/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_MOST_SOUND) += most_sound.o
most_sound-objs := sound.o
-ccflags-y += -Idrivers/staging/
+ccflags-y += -I $(srctree)/drivers/staging/
diff --git a/drivers/staging/most/usb/Makefile
b/drivers/staging/most/usb/Makefile
index 18d28cb..910cd08 100644
--- a/drivers/staging/most/usb/Makefile
+
Re: [PATCH V7 3/5] i2c: tegra: Add DMA Support
В Thu, 31 Jan 2019 03:34:59 +
Sowjanya Komatineni пишет:
> > I2C_INT_ALL_PACKETS_XFER_COMPLETE shall be masked for the PIO mode
> > I2C_INT_PACKET_XFER_COMPLETE shall be masked for the DMA mode, if
> > I'm not missing something.
> for packets with repeated start or continue xfer,
> PACKET_XFER_COMPLETE will be triggers for packets with stop bit, both
> PACKET_XFER_COMPLETE and ALL_PACKET_XFER_COMPLETE will be triggered.
> To be align with what PIO mode is doing, will not use
> ALL_PACKETS_XFER_COMPLETE for DMA in next version.
Sounds good.
> >
> > Handle the error-case here:
> >
> > if (i2c_dev->msg_err != I2C_ERR_NONE) {
> > dev_err(i2c_dev->dev, "i2c dma transfer failed\n");
> > goto i2c_recover;
> > }
> >
> >...
> > <--- end of tegra_i2c_xfer_msg() -->
> >
> > if (likely(i2c_dev->msg_err == I2C_ERR_NONE))
> > return 0;
> >
> > i2c_recover:
> > tegra_i2c_init(i2c_dev);
> > /* start recovery upon arbitration loss in single master
> > mode */ if (i2c_dev->msg_err == I2C_ERR_ARBITRATION_LOST) {
> > if (!i2c_dev->is_multimaster_mode)
> > return tegra_i2c_issue_bus_clear(i2c_dev);
> > return -EAGAIN;
> > }
> > if (i2c_dev->msg_err == I2C_ERR_NO_ACK) {
> > if (msg->flags & I2C_M_IGNORE_NAK)
> > return 0;
> > return -EREMOTEIO;
> > }
> >
> > return -EIO;
>
> When DMA transfer timeout, no need to check for ARB LOST or NO_ACK as
> if any of those interrupts trigger interrupt handler will terminate
> dmaengine and completes so DMA timeout will not be seen in those
> cases and falls thru msg_err check
>
Okay.
Re: [PATCH 4/6] mfd: Add support for the MediaTek MT6358 PMIC
On Wed, Jan 30, 2019 at 5:19 PM Hsin-Hsiung Wang
wrote:
>
> This adds support for the MediaTek MT6358 PMIC. This is a
> multifunction device with the following sub modules:
>
> - Regulator
> - RTC
> - Codec
> - Interrupt
>
> It is interfaced to the host controller using SPI interface
> by a proprietary hardware called PMIC wrapper or pwrap.
> MT6358 MFD is a child device of the pwrap.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/Makefile |2 +-
> drivers/mfd/mt6358-irq.c | 236 +
> drivers/mfd/mt6397-core.c| 62 +-
> include/linux/mfd/mt6358/core.h | 158 +++
> include/linux/mfd/mt6358/registers.h | 1926
> ++
> include/linux/mfd/mt6397/core.h |3 +
> 6 files changed, 2385 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mfd/mt6358-irq.c
> create mode 100644 include/linux/mfd/mt6358/core.h
> create mode 100644 include/linux/mfd/mt6358/registers.h
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 088e249..50be021 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o mt6358-irq.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
> diff --git a/drivers/mfd/mt6358-irq.c b/drivers/mfd/mt6358-irq.c
> new file mode 100644
> index 000..b29fdc1
> --- /dev/null
> +++ b/drivers/mfd/mt6358-irq.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2019 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct irq_top_t mt6358_ints[] = {
> + MT6358_TOP_GEN(BUCK),
> + MT6358_TOP_GEN(LDO),
> + MT6358_TOP_GEN(PSC),
> + MT6358_TOP_GEN(SCK),
> + MT6358_TOP_GEN(BM),
> + MT6358_TOP_GEN(HK),
> + MT6358_TOP_GEN(AUD),
> + MT6358_TOP_GEN(MISC),
> +};
> +
> +static int parsing_hwirq_to_top_group(unsigned int hwirq)
> +{
> + int top_group;
> +
> + for (top_group = 1; top_group < ARRAY_SIZE(mt6358_ints); top_group++)
> {
> + if (mt6358_ints[top_group].hwirq_base > hwirq) {
> + top_group--;
> + break;
> + }
> + }
> + return top_group;
> +}
> +
> +static void pmic_irq_enable(struct irq_data *data)
> +{
> + unsigned int hwirq = irqd_to_hwirq(data);
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irq_data = chip->irq_data;
> +
> + irq_data->enable_hwirq[hwirq] = 1;
> +}
> +
> +static void pmic_irq_disable(struct irq_data *data)
> +{
> + unsigned int hwirq = irqd_to_hwirq(data);
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irq_data = chip->irq_data;
> +
> + irq_data->enable_hwirq[hwirq] = 0;
> +}
> +
> +static void pmic_irq_lock(struct irq_data *data)
> +{
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> +
> + mutex_lock(&chip->irqlock);
> +}
> +
> +static void pmic_irq_sync_unlock(struct irq_data *data)
> +{
> + unsigned int i, top_gp, en_reg, int_regs, shift;
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irq_data = chip->irq_data;
> +
> + for (i = 0; i < irq_data->num_pmic_irqs; i++) {
> + if (irq_data->enable_hwirq[i] ==
> + irq_data->cache_hwirq[i])
> + continue;
> +
> + top_gp = parsing_hwirq_to_top_group(i);
> + int_regs = mt6358_ints[top_gp].num_int_bits /
> MT6358_REG_WIDTH;
> + en_reg = mt6358_ints[top_gp].en_reg +
> + mt6358_ints[top_gp].en_reg_shift * int_regs;
> + shift = (i - mt6358_ints[top_gp].hwirq_base) %
> MT6358_REG_WIDTH;
> + regmap_update_bits(chip->regmap, en_reg, 0x1 << shift,
> + irq_data->enable_hwirq[i] << shift);
> + irq_data->cache_hwirq[i] = irq_data->enable_hwirq[i];
> + }
> + mutex_unlock(&chip->irqlock);
> +}
> +
> +static int pmic_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + return 0;
> +}
> +
> +static struct irq_chip mt6358_irq_chip = {
> + .name = "mt6358-irq",
> + .irq_enable = pmic_irq_enable,
> + .irq_disable = pmic_irq_disable,
> + .irq_bus_lock = pmic_irq_lock,
> + .irq_bus_sync_unlock = pmic_irq_sy
[PATCH] drm: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
I put all gpu/drm changes into a single patch because
they are trivial conversion.
Please let me know if I need to split this into per-driver patches.
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/lib/Makefile| 2 +-
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/msm/Makefile| 6 +++---
drivers/gpu/drm/nouveau/Kbuild | 8
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index f76bcb9..b21ebb0 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -23,7 +23,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-FULL_AMD_PATH=$(src)/..
+FULL_AMD_PATH=$(srctree)/$(src)/..
DISPLAY_FOLDER_NAME=display
FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
diff --git a/drivers/gpu/drm/amd/lib/Makefile b/drivers/gpu/drm/amd/lib/Makefile
index 6902430..d534992 100644
--- a/drivers/gpu/drm/amd/lib/Makefile
+++ b/drivers/gpu/drm/amd/lib/Makefile
@@ -27,6 +27,6 @@
# driver components or later moved to kernel/lib for sharing with
# other drivers.
-ccflags-y := -I$(src)/../include
+ccflags-y := -I $(srctree)/$(src)/../include
obj-$(CONFIG_CHASH) += chash.o
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc7..a4a5a96 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,6 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
-ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
+ccflags-y += -I $(srctree)/$(src) -I
$(srctree)/$(src)/$(GVT_DIR)/
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 56a70c7..b7b1ebd 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/gpu/drm/msm
-ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
-ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
+ccflags-y := -I $(srctree)/$(src)
+ccflags-y += -I $(srctree)/$(src)/disp/dpu1
+ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
msm-y := \
adreno/adreno_device.o \
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index b17843d..b4bc88ad 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -1,7 +1,7 @@
-ccflags-y += -I$(src)/include
-ccflags-y += -I$(src)/include/nvkm
-ccflags-y += -I$(src)/nvkm
-ccflags-y += -I$(src)
+ccflags-y += -I $(srctree)/$(src)/include
+ccflags-y += -I $(srctree)/$(src)/include/nvkm
+ccflags-y += -I $(srctree)/$(src)/nvkm
+ccflags-y += -I $(srctree)/$(src)
# NVKM - HW resource manager
#- code also used by various userspace tools/tests
--
2.7.4
Re: [PATCH v3 2/3] drivers: platform: goldfish: goldfish_address_space: add a driver
> Also, why does the other Android "emulator", cuttlefish, not need > special drivers like this and the other goldfish drivers? Shouldn't you > be using the same interfaces that they use that are already merged > upstream? > Actually, now that cuttlefish works on a mainline kernel, can't we just > delete the existing goldfish code? cuttlefish is a separate emulator with different assumptions which do not work for us. Our emulator runs on Linux, Mac and Windows, it uses host's GPU directly for rendering. I am not sure how cuttlefish accesses host's GPU memory (it might not support this), but we need it to support coherent memory access for Vulcan. We also might use it to access host's camera pixels to avoid copying them. Please keep goldfish drivers.
[PATCH] usb: typec: tcpm: Export partner Source Capabilities
Provide a function to get the partner Source Capabilities.
Signed-off-by: Kyle Tso
---
drivers/usb/typec/tcpm/tcpm.c | 23 +++
include/linux/usb/tcpm.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index f1d3e54210df..29cd84ba9960 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4494,6 +4494,29 @@ int tcpm_update_sink_capabilities(struct tcpm_port
*port, const u32 *pdo,
}
EXPORT_SYMBOL_GPL(tcpm_update_sink_capabilities);
+/*
+ * Don't call this function in interrupt context. Caller needs to free the
+ * memory itself.
+ */
+int tcpm_get_partner_src_caps(struct tcpm_port *port, u32 **src_pdo)
+{
+ unsigned int nr_pdo;
+
+ if (port->nr_source_caps == 0)
+ return -ENODATA;
+
+ *src_pdo = kcalloc(port->nr_source_caps, sizeof(u32), GFP_KERNEL);
+ if (!src_pdo)
+ return -ENOMEM;
+
+ mutex_lock(&port->lock);
+ nr_pdo = tcpm_copy_pdos(*src_pdo, port->source_caps,
+ port->nr_source_caps);
+ mutex_unlock(&port->lock);
+ return nr_pdo;
+}
+EXPORT_SYMBOL_GPL(tcpm_get_partner_src_caps);
+
/* Power Supply access to expose source power information */
enum tcpm_psy_online_states {
TCPM_PSY_OFFLINE = 0,
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 50c74a77db55..fe56d759567c 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -173,5 +173,6 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
enum tcpm_transmit_status status);
void tcpm_pd_hard_reset(struct tcpm_port *port);
void tcpm_tcpc_reset(struct tcpm_port *port);
+int tcpm_get_partner_src_caps(struct tcpm_port *port, u32 **pdo);
#endif /* __LINUX_USB_TCPM_H */
--
2.20.1.495.gaa96b0ce6b-goog
Re: [PATCH] acpi_pm: Reduce PMTMR counter read contention
On 2019/1/30 16:06, Thomas Gleixner wrote: On Tue, 22 Jan 2019, Zhenzhong Duan wrote: On a large system with many CPUs, using PMTMR as the clock source can have a significant impact on the overall system performance because of the following reasons: 1) There is a single PMTMR counter shared by all the CPUs. 2) PMTMR counter reading is a very slow operation. Using PMTMR as the default clock source may happen when, for example, the TSC clock calibration exceeds the allowable tolerance and HPET disabled by nohpet on kernel command line. Sometimes the performance The question is why would anyone disable HPET on a larger machine when the TSC is wreckaged? There may be broken hardware where TSC is wreckaged. On our instances(X8-8/X7-8), TSC isn't wreckaged. Sometimes we are lucky to pass the bootup stage, then TSC is the final default clocksource. See log: [0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1910969940391419 ns [ 13.963224] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275000 ns [ 19.903175] clocksource: Switched to clocksource refined-jiffies [ 20.190467] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 2085701024 ns [ 20.201634] clocksource: Switched to clocksource acpi_pm [ 39.082577] clocksource: tsc: mask: 0x max_cycles: 0x2113ba2fe3c, max_idle_ns: 440795266816 ns [ 39.138781] clocksource: Switched to clocksource tsc When we are unlucky, logs: [0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1910969940391419 ns [ 19.905741] clocksource: Switched to clocksource refined-jiffies [ 20.181521] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 2085701024 ns [ 44.273786] watchdog: BUG: soft lockup - CPU#48 stuck for 23s! [swapper/48:0] [ 44.279992] watchdog: BUG: soft lockup - CPU#49 stuck for 23s! [migration/49:307] So we paniced when acpi_pm is initializing and is chosed as default clocksource temporarily, it paniced just because we add nohpet parameter. I'm not against the change per se, but I really want to understand why we need all the complexity for something which should never be used in a real world deployment. Hmm, it's a strong word of "never be used". Customers may happen to use nohpet(sanity test?) and report bug to us. Sometimes they does report a bug that reproduce with their customed config. There may also be BIOS setting HPET disabled. Thanks Zhenzhong
Re: [patch 0/2] genirq, proc: Speedup /proc/stat interrupt statistics
On 01/30/2019 05:00 PM, Thomas Gleixner wrote: > On Wed, 30 Jan 2019, Andrew Morton wrote: >> On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner >> wrote: >> >>> Waiman reported that on large systems with a large amount of interrupts the >>> readout of /proc/stat takes a long time to sum up the interrupt >>> statistics. In principle this is not a problem. but for unknown reasons >>> some enterprise quality software reads /proc/stat with a high frequency. >>> >>> The reason for this is that interrupt statistics are accounted per cpu. So >>> the /proc/stat logic has to sum up the interrupt stats for each interrupt. >>> >>> The following series addresses this by making the interrupt statitics code >>> in the core generate the sum directly and by making the loop in the >>> /proc/stat read function smarter. >>> >> Has the speedup been quantified? > Waiman should be able to provide numbers > > On a 4-socket IvyBridge-EX system (60-core 120-thread) and 3016 irqs, I ran a test program that read /proc/stat 50,000 time. Before the patch, the elapsed time was 18.436s (sys 18.380s). After the patch, it was 3.769s (sys 3.742s). It was an almost 80% reduction in execution time. It was better than I expected. I like that. Cheers, Longman
Re: [PATCH v5 15/20] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
On Wed, 2019-01-30 at 11:05 -0800, Evan Green wrote:
> On Mon, Dec 31, 2018 at 7:59 PM Yong Wu wrote:
> >
> > This patch only move the clk_prepare_enable and config_port into the
> > runtime suspend/resume callback. It doesn't change the code content
> > and sequence.
> >
> > This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
> > (SMI_BUS_SEL need to be restored after smi-common resume every time.)
> > Also it gives a chance to get rid of mtk_smi_larb_get/put which could
> > be a next topic.
> >
> > CC: Matthias Brugger
> > Signed-off-by: Yong Wu
>
> I believe this refactoring is a no-op as described, because the order is
> still:
> 1) mtk_smi_clk_enable(common)
> 2) mtk_smi_clk_enable(larb)
> 3) larb_gen->config_port()
>
> And teardown still happens in the opposite order, except for
Thanks your confirm.
> config_port, which they seem not to do in suspend.
After suspend, the HW engine should not work. config_port is not
helpful. At that time, use the HW default value.
> So, looks good to me.
>
> Reviewed-by: Evan Green
Thanks.
>
> > ---
> > drivers/memory/mtk-smi.c | 113
> > ++-
> > 1 file changed, 72 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> > index a430721..9790801 100644
> > --- a/drivers/memory/mtk-smi.c
> > +++ b/drivers/memory/mtk-smi.c
> > @@ -86,17 +86,13 @@ struct mtk_smi_larb { /* larb: local arbiter */
> > u32 *mmu;
> > };
> >
> > -static int mtk_smi_enable(const struct mtk_smi *smi)
> > +static int mtk_smi_clk_enable(const struct mtk_smi *smi)
> > {
> > int ret;
> >
> > - ret = pm_runtime_get_sync(smi->dev);
> > - if (ret < 0)
> > - return ret;
> > -
> > ret = clk_prepare_enable(smi->clk_apb);
> > if (ret)
> > - goto err_put_pm;
> > + return ret;
> >
> > ret = clk_prepare_enable(smi->clk_smi);
> > if (ret)
> > @@ -118,59 +114,28 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
> > clk_disable_unprepare(smi->clk_smi);
> > err_disable_apb:
> > clk_disable_unprepare(smi->clk_apb);
> > -err_put_pm:
> > - pm_runtime_put_sync(smi->dev);
> > return ret;
> > }
> >
> > -static void mtk_smi_disable(const struct mtk_smi *smi)
> > +static void mtk_smi_clk_disable(const struct mtk_smi *smi)
> > {
> > clk_disable_unprepare(smi->clk_gals1);
> > clk_disable_unprepare(smi->clk_gals0);
> > clk_disable_unprepare(smi->clk_smi);
> > clk_disable_unprepare(smi->clk_apb);
> > - pm_runtime_put_sync(smi->dev);
> > }
> >
> > int mtk_smi_larb_get(struct device *larbdev)
> > {
> > - struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> > - const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
> > - struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
> > - int ret;
> > + int ret = pm_runtime_get_sync(larbdev);
> >
> > - /* Enable the smi-common's power and clocks */
> > - ret = mtk_smi_enable(common);
> > - if (ret)
> > - return ret;
> > -
> > - /* Enable the larb's power and clocks */
> > - ret = mtk_smi_enable(&larb->smi);
> > - if (ret) {
> > - mtk_smi_disable(common);
> > - return ret;
> > - }
> > -
> > - /* Configure the iommu info for this larb */
> > - larb_gen->config_port(larbdev);
> > -
> > - return 0;
> > + return (ret < 0) ? ret : 0;
> > }
> > EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
> >
> > void mtk_smi_larb_put(struct device *larbdev)
> > {
> > - struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> > - struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
> > -
> > - /*
> > -* Don't de-configure the iommu info for this larb since there may
> > be
> > -* several modules in this larb.
> > -* The iommu info will be reset after power off.
> > -*/
> > -
> > - mtk_smi_disable(&larb->smi);
> > - mtk_smi_disable(common);
> > + pm_runtime_put_sync(larbdev);
> > }
> > EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
> >
> > @@ -385,12 +350,52 @@ static int mtk_smi_larb_remove(struct platform_device
> > *pdev)
> > return 0;
> > }
> >
> > +static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
> > +{
> > + struct mtk_smi_larb *larb = dev_get_drvdata(dev);
> > + const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
> > + int ret;
> > +
> > + /* Power on smi-common. */
> > + ret = pm_runtime_get_sync(larb->smi_common_dev);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = mtk_smi_clk_enable(&larb->smi);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to en
edge case in posix file lock deadlock detection
I'm having trouble figuring out how the kernel handles a particular case in deadlock detection on posix file locks. Here's the scenario: PID 1: locks byte 2 PID 3: locks byte 0 PID 2: locks byte 10 PID 1: locks byte 10 PID 2: locks bytes 0-2 inclusive The last step fails with EDEADLK, but I'm not sure how that is detected. The specified range conflicts with two different locks, and the first loop in posix_lock_inode would find whichever one comes first in the linked list, and pass that to the deadlock detector. If the lock on byte 2 comes first in the list, a cycle would be found between the lock on byte 2 and the lock on byte 10. But if the lock on byte 0 comes first, the deadlock detector would return NULL from what_owner_is_waiting_for on that lock since PID 3 has no other locks, and immediately succeed. What am I missing? Thanks, ~Theodore
RE: [PATCH V7 3/5] i2c: tegra: Add DMA Support
> I2C_INT_ALL_PACKETS_XFER_COMPLETE shall be masked for the PIO mode
> I2C_INT_PACKET_XFER_COMPLETE shall be masked for the DMA mode, if I'm not
> missing something.
>
for packets with repeated start or continue xfer, PACKET_XFER_COMPLETE will be
triggers
for packets with stop bit, both PACKET_XFER_COMPLETE and
ALL_PACKET_XFER_COMPLETE will be triggered.
To be align with what PIO mode is doing, will not use ALL_PACKETS_XFER_COMPLETE
for DMA in next version.
>
> Handle the error-case here:
>
> if (i2c_dev->msg_err != I2C_ERR_NONE) {
> dev_err(i2c_dev->dev, "i2c dma transfer failed\n");
> goto i2c_recover;
> }
>
>...
> <--- end of tegra_i2c_xfer_msg() -->
>
> if (likely(i2c_dev->msg_err == I2C_ERR_NONE))
> return 0;
>
> i2c_recover:
> tegra_i2c_init(i2c_dev);
> /* start recovery upon arbitration loss in single master mode */
> if (i2c_dev->msg_err == I2C_ERR_ARBITRATION_LOST) {
> if (!i2c_dev->is_multimaster_mode)
> return tegra_i2c_issue_bus_clear(i2c_dev);
> return -EAGAIN;
> }
> if (i2c_dev->msg_err == I2C_ERR_NO_ACK) {
> if (msg->flags & I2C_M_IGNORE_NAK)
> return 0;
> return -EREMOTEIO;
> }
>
> return -EIO;
When DMA transfer timeout, no need to check for ARB LOST or NO_ACK as if any of
those interrupts trigger interrupt handler will terminate dmaengine and
completes so DMA timeout will not be seen in those cases and falls thru msg_err
check
[PATCH] kvm: vmx: Fix typos in vmentry/vmexit control setting
Previously, 'commit f99e3daf94ff ("KVM: x86: Add Intel PT
virtualization work mode")' work mode' offered framework
to support Intel PT virtualization. However, the patch has
some typos in vmx_vmentry_ctrl() and vmx_vmexit_ctrl(), e.g.
used wrong flags and wrong variable, which will cause the
VM entry failure later.
Fixes: 'commit f99e3daf94ff ("KVM: x86: Add Intel PT virtualization work mode")'
Signed-off-by: Yu Zhang
---
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kvm/vmx/vmx.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 9932895..267de48 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -445,7 +445,8 @@ static inline u32 vmx_vmentry_ctrl(void)
{
u32 vmentry_ctrl = vmcs_config.vmentry_ctrl;
if (pt_mode == PT_MODE_SYSTEM)
- vmentry_ctrl &= ~(VM_EXIT_PT_CONCEAL_PIP |
VM_EXIT_CLEAR_IA32_RTIT_CTL);
+ vmentry_ctrl &= ~(VM_ENTRY_PT_CONCEAL_PIP |
+ VM_ENTRY_LOAD_IA32_RTIT_CTL);
/* Loading of EFER and PERF_GLOBAL_CTRL are toggled dynamically */
return vmentry_ctrl &
~(VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL |
VM_ENTRY_LOAD_IA32_EFER);
@@ -455,9 +456,10 @@ static inline u32 vmx_vmexit_ctrl(void)
{
u32 vmexit_ctrl = vmcs_config.vmexit_ctrl;
if (pt_mode == PT_MODE_SYSTEM)
- vmexit_ctrl &= ~(VM_ENTRY_PT_CONCEAL_PIP |
VM_ENTRY_LOAD_IA32_RTIT_CTL);
+ vmexit_ctrl &= ~(VM_EXIT_PT_CONCEAL_PIP |
+VM_EXIT_CLEAR_IA32_RTIT_CTL);
/* Loading of EFER and PERF_GLOBAL_CTRL are toggled dynamically */
- return vmcs_config.vmexit_ctrl &
+ return vmexit_ctrl &
~(VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL | VM_EXIT_LOAD_IA32_EFER);
}
--
1.9.1
