[PATCH v3] platform: cros_ec: Reduce ligthbar get version command
By default, the lightbar commands are set to the
biggest lightbar command and response. That length is greater than 128
bytes and may not work on all machines.
But all EC are probed for lightbar by sending a get version request.
Set that request size precisely.
Before the command would be:
cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194, insize:
128, result: 0
Afer:
cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1, insize: 8,
result: 0
Fixes: a841178445bb7 ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Gwendal Grignou
---
Changes since v2:
- Add fix field where the inefficiency was present.
Changes since v1:
- Remove BUG and TEST fields.
drivers/platform/chrome/cros_ec_lightbar.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
b/drivers/platform/chrome/cros_ec_lightbar.c
index b59180bff5a3e..ef61298c30bdd 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -116,6 +116,8 @@ static int get_lightbar_version(struct cros_ec_dev *ec,
param = (struct ec_params_lightbar *)msg->data;
param->cmd = LIGHTBAR_CMD_VERSION;
+ msg->outsize = sizeof(param->cmd);
+ msg->result = sizeof(resp->version);
ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
if (ret < 0) {
ret = 0;
--
2.28.0.402.g5ffc5be6b7-goog
Re: [PATCH v2] platform: cros_ec: Reduce ligthbar get version command
On Sat, Aug 29, 2020 at 8:54 AM Jonathan Cameron wrote:
>
> On Tue, 25 Aug 2020 17:29:45 -0700
> Gwendal Grignou wrote:
>
> > By default, the lightbar commands are set to the
> > biggest lightbar command and response. That length is greater than 128
> > bytes and may not work on all machines.
> > But all EC are probed for lightbar by sending a get version request.
> > Set that request size precisely.
> >
> > Before the command would be:
> > cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194,
> > insize: 128, result: 0
> > Afer:
> > cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1, insize:
> > 8, result: 0
> >
> > Signed-off-by: Gwendal Grignou
> Hi Gwendal,
>
> Description seems to me to suggest this is a fix?
> Are there known machines on which it doesn't work currently?
We have a prototype [without lightbar] where the command size was
limited to 128 bytes.
Given we issue a get_lightbar_version on all chromebooks, we had a
failure on this prototype. Devices with a lightbar must support a
command size greater or equal to 194 bytes.
Beside helping the prototype to boot, this patch slightly speeds up
the enumeration of devices managed by the EC.
>
> If so, please can I have a fixes tag. If it's just a precaution
> against future problems then let me know and I can add it for the
> next merge window.
Done in v3.
Note I made a mistake by sending the patch to linux-iio as it targeted
platform/chromeos.
>
> Thanks,
>
> Jonathan
>
> > ---
> > Changes since v1:
> > - Remove BUG and TEST fields.
> >
> > drivers/platform/chrome/cros_ec_lightbar.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
> > b/drivers/platform/chrome/cros_ec_lightbar.c
> > index b59180bff5a3e..ef61298c30bdd 100644
> > --- a/drivers/platform/chrome/cros_ec_lightbar.c
> > +++ b/drivers/platform/chrome/cros_ec_lightbar.c
> > @@ -116,6 +116,8 @@ static int get_lightbar_version(struct cros_ec_dev *ec,
> >
> > param = (struct ec_params_lightbar *)msg->data;
> > param->cmd = LIGHTBAR_CMD_VERSION;
> > + msg->outsize = sizeof(param->cmd);
> > + msg->result = sizeof(resp->version);
> > ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
> > if (ret < 0) {
> > ret = 0;
>
[GIT PULL] EDAC urgent for v5.9-rc3
Hi Linus,
please pull a single fix for the ghes_edac driver to properly clear
state on remove, when testing with CONFIG_DEBUG_TEST_DRIVER_REMOVE.
Thx.
---
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
tags/edac_urgent_for_v5.9_rc3
for you to fetch changes up to b972fdba8665d75109ade0357739f46af6415d2a:
EDAC/ghes: Fix NULL pointer dereference in ghes_edac_register() (2020-08-27
18:04:07 +0200)
A fix to properly clear ghes_edac driver state on driver remove so that
a subsequent load can probe the system properly; by Shiju Jose.
Shiju Jose (1):
EDAC/ghes: Fix NULL pointer dereference in ghes_edac_register()
drivers/edac/ghes_edac.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index da60c29468a7..54ebc8afc6b1 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -55,6 +55,8 @@ static DEFINE_SPINLOCK(ghes_lock);
static bool __read_mostly force_load;
module_param(force_load, bool, 0);
+static bool system_scanned;
+
/* Memory Device - Type 17 of SMBIOS spec */
struct memdev_dmi_entry {
u8 type;
@@ -225,14 +227,12 @@ static void enumerate_dimms(const struct dmi_header *dh,
void *arg)
static void ghes_scan_system(void)
{
- static bool scanned;
-
- if (scanned)
+ if (system_scanned)
return;
dmi_walk(enumerate_dimms, &ghes_hw);
- scanned = true;
+ system_scanned = true;
}
void ghes_edac_report_mem_error(int sev, struct cper_sec_mem_err *mem_err)
@@ -631,6 +631,8 @@ void ghes_edac_unregister(struct ghes *ghes)
mutex_lock(&ghes_reg_mutex);
+ system_scanned = false;
+
if (!refcount_dec_and_test(&ghes_refcount))
goto unlock;
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG
Nürnberg
Re: [PATCH 2/5] arm64: dts: imx8mm-beacon-kit: Add missing build through Makefile
On Sun, Aug 23, 2020 at 07:20:16PM +0200, Krzysztof Kozlowski wrote: > Add missing imx8mm-beacon-kit.dts object in Makefile so it will be build > when building dtbs. > > Signed-off-by: Krzysztof Kozlowski We have applied a patch from Rob [1] for that. Shawn [1] https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/fixes&id=56e79dfd036b538940227fb31371c1cd67b2467f > --- > arch/arm64/boot/dts/freescale/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/freescale/Makefile > b/arch/arm64/boot/dts/freescale/Makefile > index a39f0a1723e0..903c0eb61290 100644 > --- a/arch/arm64/boot/dts/freescale/Makefile > +++ b/arch/arm64/boot/dts/freescale/Makefile > @@ -28,6 +28,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb > dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb > dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb > dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb > -- > 2.17.1 >
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On Sat, Aug 29, 2020 at 2:54 AM Edward Shishkin wrote: > > On 08/28/2020 01:50 AM, Edward Shishkin wrote: > > > > > > On 08/27/2020 11:53 PM, Metztli Information Technology wrote: > >> On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin > >> wrote: > >>> > >>> [...] > >>> > > FYI Although not officially, the Debian metaframework Buster AMD64 > distribution might be the first to support native installation of > Reiser4 SFRN 5.1.3, kernel and reiser4progs 2.0.3, file system > utilities. > > I have already made a couple of successful Metztli Reiser4 SFRN 5 > native installations onto ~100 GB slices, which root file system is > formatted in 'Reiser5' and 1 GB /boot in JFS. > https://metztli.it/reiser5 (Screenshot 600x338 size) > > The upgraded netboot installation media metztli-reiser4-sfrn5.iso is > available at: > https://sourceforge.net/projects/debian-reiser4/ > as well as > https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso > https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso.SHA256SUM > > Likely the brick/volume feature(s) will be useful in Cloud fabric > infrastructures, like Google's, where reiser4 excels. > > The current SFRN 5.1.3 -patched Zstd -compressed kernel in the > installation media is Debian's 5.7.10. > >>> > >>> > >>> wow, reiser5 from the box? I might want to try.. > >> Well, it is more of a 'reference implementation' as there are persons > >> who reached out to me because their builds succeeded, they were able > >> to format in reiser4 SFRN x.y.z, but they were not able to mount their > >> partition(s). > >> Turns out, they were inadvertently mixing SFRN 4.0.2 with 5.1.3, > >> either in the reiser4 kernel patch -- released with the same in both > >> instances -- or in the reiser4progs. > > > > > > Yeah, some confusion can take place. Plus unsupported old 4.0.2 > > volumes (a special build with CONFIG_REISER4_OLD=y is required to > > mount them), which is a payment for performance. > > > > > >> > >>> > > The installer defaults to create the root system reiser5 -formatted > partition as: > mkfs.reiser4 -yo "create=reg42" > >>> > >>> > >>> "reg42" is default profile in reiser4progs-2.0.3 (check by > >>> "mkfs.reiser4 -p") - there is no need to specify it via option. > >> Acknowledged. Thanks. > >> > >>> > >>> Have you had a chance to play with logical volumes (add/remove > >>> bricks, etc)? > >> That is coming up. I still have to create/customize an image of > >> Metztli Reiser4 SFRN5 for a Google Compute Engine (GCE) minimal ~200GB > >> instance for evaluation. > >> Fact is 'not all clouds are created equal' -- even if KVM -based. For > >> instance, reiser4 SFRN 4.0.2 on a trial Linode small ~80GB SSD > >> slice(s) with 2 virtual cpus frequently hung under short sustained > >> disk/network I/O usage. > >> I have not experienced that with reiser4 SFRN 4.0.2 on GCE -- where > >> sometimes I allocate eight to sixteen virtual cpus with 16, 32, or > >> even 64, GBs of RAM, on a region hosting AMD Epyc, for fast kernel > >> building ops. > >> > >> But testing a relatively small bootable image first will usually > >> provide insight if adding one, two... eight, TB slices will make sense > >> later on. > > > > > > I played with your media on a virtual machine. The basic volume > > operations work, however, I guess, adding brick(s) to "/" will cause > > problems at next boot: someone has to register all the bricks before > > mounting "/"... > > > It is important to register all bricks *before* mounting "/", as the > registration procedure collects information need for volume activation > (including transaction replay, etc). > > So at boot time before mounting "/" we need to scan the system and for > each found block device call a brick registration procedure. The problem > is that I don't know what do we actually have before mounting "/". > > Brick registration can be performed by calling "volume.reiser4 -g". > However, it accepts device name, that we obviously don't have, as all > the names are in "/", which is not yet mounted. > > I guess that solution exists (and possibly locates in initrd), because, > it is perfectly possible to boot e.g. with root over LVM (a special > utility scans the system and collects information about devices- > components of the logical volume). Any ideas? man initramfs-tools Under debian there are: /etc/initramfs-tools/hooks/ /usr/share/initramfs-tools/hooks/ Observing the latter, we can see that it contains executable scripts for reiserfs, lvm2, etc.; hence, every time an update-initramfs command is performed to create/update an initrd.img-`uname -r` these scripts are bundled into the initrd image. An executable script, i.e., named reiser5, might also be added to perform the 'brick registration procedure', then subsequently running update-initramfs for its inclusion into the initrd image. > > Thanks, > Edward.
drivers/usb/gadget/udc/tegra-xudc.c:2257:26: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1127b219ce9481c84edad9711626d856127d5e51
commit: 49db427232fe2c357d23a2d62e2db1d431f95051 usb: gadget: Add UDC driver
for tegra XUSB device mode controller
date: 10 months ago
config: arm64-randconfig-s031-20200830 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 49db427232fe2c357d23a2d62e2db1d431f95051
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/usb/gadget/udc/tegra-xudc.c:611:9: sparse: sparse: undefined
identifier 'tegra_xusb_padctl_set_vbus_override'
drivers/usb/gadget/udc/tegra-xudc.c:628:9: sparse: sparse: undefined
identifier 'tegra_xusb_padctl_set_vbus_override'
drivers/usb/gadget/udc/tegra-xudc.c:711:25: sparse: sparse: undefined
identifier 'tegra_xusb_padctl_set_vbus_override'
drivers/usb/gadget/udc/tegra-xudc.c:713:25: sparse: sparse: undefined
identifier 'tegra_xusb_padctl_set_vbus_override'
drivers/usb/gadget/udc/tegra-xudc.c:741:31: sparse: sparse: undefined
identifier 'tegra_phy_xusb_utmi_port_reset'
>> drivers/usb/gadget/udc/tegra-xudc.c:2257:26: sparse: sparse: incorrect type
>> in assignment (different base types) @@ expected unsigned short
>> [usertype] status_buf @@ got restricted __le16 [usertype] @@
>> drivers/usb/gadget/udc/tegra-xudc.c:2257:26: sparse: expected unsigned
>> short [usertype] status_buf
>> drivers/usb/gadget/udc/tegra-xudc.c:2257:26: sparse: got restricted
>> __le16 [usertype]
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49db427232fe2c357d23a2d62e2db1d431f95051
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 49db427232fe2c357d23a2d62e2db1d431f95051
vim +2257 drivers/usb/gadget/udc/tegra-xudc.c
2197
2198 static int tegra_xudc_ep0_get_status(struct tegra_xudc *xudc,
2199 struct usb_ctrlrequest *ctrl)
2200 {
2201 struct tegra_xudc_ep_context *ep_ctx;
2202 u32 val, ep, index = le16_to_cpu(ctrl->wIndex);
2203 u16 status = 0;
2204
2205 if (!(ctrl->bRequestType & USB_DIR_IN))
2206 return -EINVAL;
2207
2208 if ((le16_to_cpu(ctrl->wValue) != 0) ||
2209 (le16_to_cpu(ctrl->wLength) != 2))
2210 return -EINVAL;
2211
2212 switch (ctrl->bRequestType & USB_RECIP_MASK) {
2213 case USB_RECIP_DEVICE:
2214 val = xudc_readl(xudc, PORTPM);
2215
2216 if (xudc->selfpowered)
2217 status |= BIT(USB_DEVICE_SELF_POWERED);
2218
2219 if ((xudc->gadget.speed < USB_SPEED_SUPER) &&
2220 (val & PORTPM_RWE))
2221 status |= BIT(USB_DEVICE_REMOTE_WAKEUP);
2223 if (xudc->gadget.speed == USB_SPEED_SUPER) {
2224 if (val & PORTPM_U1E)
2225 status |= BIT(USB_DEV_STAT_U1_ENABLED);
2226 if (val & PORTPM_U2E)
2227 status |= BIT(USB_DEV_STAT_U2_ENABLED);
2228 }
2229 break;
2230 case USB_RECIP_INTERFACE:
2231 if (xudc->gadget.speed == USB_SPEED_SUPER) {
2232 status |= USB_INTRF_STAT_FUNC_RW_CAP;
2233 val = xudc_readl(xudc, PORTPM);
2234 if (val & PORTPM_FRWE)
2235 status |= USB_INTRF_STAT_FUNC_RW;
2236 }
2237 break;
2238 case USB_RECIP_ENDPOINT:
2239 ep = (index & USB_ENDPOINT_NUMBER_MASK) * 2 +
2240 ((index & USB_DIR_IN) ? 1 : 0);
2241 ep_ctx = &xudc->ep_context[ep];
2242
2243 if ((xudc->device_state != USB_STATE_CONFIGURED) &&
2244 ((xudc->device_state != USB_STATE_ADDRESS) || (ep
!= 0)))
2245 return -EINVAL;
2246
2247 if (ep_ctx_read_stat
Re: [PATCH 3/5] arm64: dts: imx8mm-beacon-som: Align regulator names with schema
On Sun, Aug 23, 2020 at 07:20:17PM +0200, Krzysztof Kozlowski wrote: > Device tree schema expects regulator names to be lowercase. This fixes > dtbs_check warnings like: > > pmic@4b: regulators:LDO1:regulator-name:0: 'LDO1' does not match > '^ldo[1-6]$' > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: [PATCH 1/5] dt-bindings: arm: fsl: Add Beacon i.MX8M Mini Development Kit binding
On Sun, Aug 23, 2020 at 07:20:15PM +0200, Krzysztof Kozlowski wrote: > Document the binding for Beacon EmbeddedWorks i.MX8M Mini Development > Kit board. > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: [PATCH 5/5] arm64: dts: imx8mm-evk: Align regulator names with schema
On Sun, Aug 23, 2020 at 07:20:19PM +0200, Krzysztof Kozlowski wrote: > Device tree schema expects regulator names to be lowercase. This fixes > dtbs_check warnings like: > > pmic@4b: regulators:LDO1:regulator-name:0: 'LDO1' does not match > '^ldo[1-6]$' > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: [PATCH 4/5] arm64: dts: imx8mm-beacon-som: Fix atmel,24c64 EEPROM compatible
On Sun, Aug 23, 2020 at 07:20:18PM +0200, Krzysztof Kozlowski wrote: > Correct the EEPROM node compatible to match device tree schema (invalid > space, unknown ID) to fix dtbs_check warnings: > > arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: eeprom@50: > compatible: ['microchip, at24c64d', 'atmel,24c64'] is not valid under any > of the given schemas > arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: eeprom@50: > compatible:0: 'microchip, at24c64d' does not match > '^[a-zA-Z][a-zA-Z0-9,+\\-._]+$' > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: [RFC/RFT PATCH 3/6] arm64, numa: Move pcibus_to_node definition to generic numa code
On Sat, Aug 29, 2020 at 7:54 PM Bjorn Helgaas wrote:
>
> On Fri, Aug 28, 2020 at 06:11:50PM -0700, Atish Patra wrote:
> > On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas wrote:
> > > On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> > > > On Fri, 14 Aug 2020 14:47:22 -0700
> > > > Atish Patra wrote:
> > > >
> > > > > pcibus_to_node is used only when numa is enabled and does not depend
> > > > > on ISA. Thus, it can be moved the generic numa implementation.
> > > > >
> > > > > Signed-off-by: Atish Patra
> > > >
> > > > From a more general unification point of view, there seem to
> > > > be two ways architectures implement this.
> > > > Either
> > > >
> > > > bus->sysdata.node
> > > >
> > > > Or as here.
> > > > There are weird other options, but let us ignore those :)
> > > >
> > > > That is going to take a bit of unwinding should we
> > > > want to take this unification further and perhaps we want to think
> > > > about doing this in pci generic code rather than here?
> > > >
> > > > Perhaps this is one we are better keeping architecture specific for
> > > > now?
> > > >
> > > > +CC Bjorn and Linux-pci
> > > >
> > > >
> > > > > ---
> > > > > arch/arm64/kernel/pci.c | 10 --
> > > > > drivers/base/arch_numa.c | 11 +++
> > > > > 2 files changed, 11 insertions(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > > > index 1006ed2d7c60..07c122946c11 100644
> > > > > --- a/arch/arm64/kernel/pci.c
> > > > > +++ b/arch/arm64/kernel/pci.c
> > > > > @@ -54,16 +54,6 @@ int raw_pci_write(unsigned int domain, unsigned
> > > > > int bus,
> > > > > return b->ops->write(b, devfn, reg, len, val);
> > > > > }
> > > > >
> > > > > -#ifdef CONFIG_NUMA
> > > > > -
> > > > > -int pcibus_to_node(struct pci_bus *bus)
> > > > > -{
> > > > > - return dev_to_node(&bus->dev);
> > > > > -}
> > > > > -EXPORT_SYMBOL(pcibus_to_node);
> > > > > -
> > > > > -#endif
> > > > > -
> > > > > #ifdef CONFIG_ACPI
> > > > >
> > > > > struct acpi_pci_generic_root_info {
> > > > > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
> > > > > index 83341c807240..4ab1b20a615d 100644
> > > > > --- a/drivers/base/arch_numa.c
> > > > > +++ b/drivers/base/arch_numa.c
> > > > > @@ -11,6 +11,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > >
> > > > > #ifdef CONFIG_ARM64
> > > > > @@ -60,6 +61,16 @@ EXPORT_SYMBOL(cpumask_of_node);
> > > > >
> > > > > #endif
> > > > >
> > > > > +#ifdef CONFIG_PCI
> > > > > +
> > > > > +int pcibus_to_node(struct pci_bus *bus)
> > > > > +{
> > > > > + return dev_to_node(&bus->dev);
> > > > > +}
> > > > > +EXPORT_SYMBOL(pcibus_to_node);
> > > > > +
> > > > > +#endif
> > >
> > > I certainly agree that this should not be arch-specific, but I'm not
> > > really in favor of adding this PCI gunk in drivers/base.
> > >
> > > I think we can do better (eventually) by getting rid of
> > > pcibus_to_node() completely. It's not used very much except by
> > > cpumask_of_pcibus(), which itself is hardly used at all.
> > >
> > I am a bit confused here. A quick grep suggested that pcibus_to_node()
> > is also called from generic pci probe,
> > controller and few drivers(block, infiniband) as well. Maybe I am
> > missing something here ?
>
> I didn't say it was *only* used by cpumask_of_pcibus(). 13 of the 29
> calls are from cpumask_of_pcibus().
>
Ahh okay. Sorry I misunderstood that.
> As you point out, there are a few drivers that use it. They typically
> have a pci_dev, so they do the equivalent of pcibus_to_node(pdev->bus).
> That seems silly; they should just do dev_to_node(&pdev->dev) instead.
>
That covers the use case for ARM64. There are other arch implementations
as well which retrieve node information from sysdata which seems to be
type casted to different structures on different arch.
What should be done for those ?
> I looked at this once, and it seems like there might have been a
> wrinkle like the pdev->dev node not being set correctly or something.
> If that's the case, I think it should be fixed.
>
> > We can move the pcibus_to_node to arch specific code for now if that's
> > what is preferred.
>
> Now I'm the one who's confused :) Most arches, including arm64,
> already have arch-specific implementations of pcibus_to_node(). I
> didn't look at the rest of the series to see if there's a reason you
> need to move pcibus_to_node() from arch/arm64/kernel/pci.c to
> drivers//base/arch_numa.c. If you don't need to, I would just leave
> it where it is.
>
The reason I moved it from arch/arm64/kernel/pci.c to drivers//base/arch_numa.c.
so that we don't have to define it for RISC-V. But it's just a single
line function and
we can define it in RISC-V as well. I will try that in v2.
> > > > > static void numa_update_cpu(unsigned int cpu, bool remove)
> > > > > {
> > > > > int nid = cpu_to_node(cpu);
--
Regards,
Atish
Re: [PATCH 06/17] virt: acrn: Introduce VM management interfaces
On Sat, Aug 29, 2020 at 07:04:36PM +0800, Shuo A Liu wrote:
> Hi Greg,
>
> On Fri 28.Aug'20 at 12:27:38 +0200, Greg Kroah-Hartman wrote:
> > On Tue, Aug 25, 2020 at 10:45:06AM +0800, shuo.a@intel.com wrote:
> > > + default:
> > > + pr_warn("Unknown IOCTL 0x%x!\n", cmd);
> > > + ret = -EINVAL;
> >
> > Wrong error value here, right?
>
> Right, it should be -ENOIOCTLCMD.
It could, but really, just return the correct error for this, to prevent
the core from having to do the conversion.
The reviewers at Intel who should have read this before submitting it,
know the correct value to return for an illegal ioctl, please go ask
them.
> However, i found many instances in kernel drivers return -EINVAL for no
> ioctl command support. :)
Then they too are wrong. No need to add known bugs before the code is
accepted.
See the comments above the is_unrecognized_ioctl() in block/ioctl.c for
all of the details and why -EINVAL is not the correct thing to do here.
thanks,
greg k-h
Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()
On 2020/8/29 20:10, Pavel Machek wrote:
Hi!
The value av7110->debi_virt is stored in DMA memory, and it is assigned
to data, and thus data[0] can be modified at any time by malicious
hardware. In this case, "if (data[0] < 2)" can be passed, but then
data[0] can be changed into a large number, which may cause buffer
overflow when the code "av7110->ci_slot[data[0]]" is used.
To fix this possible bug, data[0] is assigned to a local variable, which
replaces the use of data[0].
I'm pretty sure hardware capable of manipulating memory can work
around any such checks, but...
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
case DATA_CI_GET:
{
u8 *data = av7110->debi_virt;
+ u8 data_0 = data[0];
- if ((data[0] < 2) && data[2] == 0xff) {
+ if (data_0 < 2 && data[2] == 0xff) {
int flags = 0;
if (data[5] > 0)
flags |= CA_CI_MODULE_PRESENT;
if (data[5] > 5)
flags |= CA_CI_MODULE_READY;
- av7110->ci_slot[data[0]].flags = flags;
+ av7110->ci_slot[data_0].flags = flags;
This does not even do what it says. Compiler is still free to access
data[0] multiple times. It needs READ_ONCE() to be effective.
Thanks for this advice, I will submit a v2 patch soon.
Best wishes,
Jia-Ju Bai
[PATCH] staging: rtl8188eu: use __func__ in os_dep
Use __func__ instead of hardcoded function names to clear
checkpatch warnings.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/os_dep/ioctl_linux.c| 80 +--
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 36 -
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 14 ++--
3 files changed, 65 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 13f12edd81cd..dbcfdd7cae32 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -314,26 +314,26 @@ static int wpa_set_auth_algs(struct net_device *dev, u32
value)
int ret = 0;
if ((value & AUTH_ALG_SHARED_KEY) && (value & AUTH_ALG_OPEN_SYSTEM)) {
- DBG_88E("wpa_set_auth_algs, AUTH_ALG_SHARED_KEY and
AUTH_ALG_OPEN_SYSTEM [value:0x%x]\n", value);
+ DBG_88E("%s, AUTH_ALG_SHARED_KEY and AUTH_ALG_OPEN_SYSTEM
[value:0x%x]\n", __func__, value);
padapter->securitypriv.ndisencryptstatus =
Ndis802_11Encryption1Enabled;
padapter->securitypriv.ndisauthtype =
Ndis802_11AuthModeAutoSwitch;
padapter->securitypriv.dot11AuthAlgrthm = dot11AuthAlgrthm_Auto;
} else if (value & AUTH_ALG_SHARED_KEY) {
- DBG_88E("wpa_set_auth_algs, AUTH_ALG_SHARED_KEY
[value:0x%x]\n", value);
+ DBG_88E("%s, AUTH_ALG_SHARED_KEY [value:0x%x]\n", __func__,
value);
padapter->securitypriv.ndisencryptstatus =
Ndis802_11Encryption1Enabled;
padapter->securitypriv.ndisauthtype = Ndis802_11AuthModeShared;
padapter->securitypriv.dot11AuthAlgrthm =
dot11AuthAlgrthm_Shared;
} else if (value & AUTH_ALG_OPEN_SYSTEM) {
- DBG_88E("wpa_set_auth_algs, AUTH_ALG_OPEN_SYSTEM\n");
+ DBG_88E("%s, AUTH_ALG_OPEN_SYSTEM\n", __func__);
if (padapter->securitypriv.ndisauthtype <
Ndis802_11AuthModeWPAPSK) {
padapter->securitypriv.ndisauthtype =
Ndis802_11AuthModeOpen;
padapter->securitypriv.dot11AuthAlgrthm =
dot11AuthAlgrthm_Open;
}
} else if (value & AUTH_ALG_LEAP) {
- DBG_88E("wpa_set_auth_algs, AUTH_ALG_LEAP\n");
+ DBG_88E("%s, AUTH_ALG_LEAP\n", __func__);
} else {
- DBG_88E("wpa_set_auth_algs, error!\n");
+ DBG_88E("%s, error!\n", __func__);
ret = -EINVAL;
}
return ret;
@@ -367,8 +367,8 @@ static int wpa_set_encryption(struct net_device *dev,
struct ieee_param *param,
}
if (strcmp(param->u.crypt.alg, "WEP") == 0) {
- RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_err_,
("wpa_set_encryption, crypt.alg = WEP\n"));
- DBG_88E("wpa_set_encryption, crypt.alg = WEP\n");
+ RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_err_, ("%s, crypt.alg
= WEP\n", __func__));
+ DBG_88E("%s, crypt.alg = WEP\n", __func__);
padapter->securitypriv.ndisencryptstatus =
Ndis802_11Encryption1Enabled;
padapter->securitypriv.dot11PrivacyAlgrthm = _WEP40_;
@@ -390,7 +390,7 @@ static int wpa_set_encryption(struct net_device *dev,
struct ieee_param *param,
wep_total_len = wep_key_len + offsetof(struct
ndis_802_11_wep, KeyMaterial);
pwep = (struct ndis_802_11_wep
*)rtw_malloc(wep_total_len);
if (!pwep) {
- RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_err_,
(" wpa_set_encryption: pwep allocate fail !!!\n"));
+ RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_err_,
("%s: pwep allocate fail !!!\n", __func__));
goto exit;
}
memset(pwep, 0, wep_total_len);
@@ -603,8 +603,8 @@ static int rtw_set_wpa_ie(struct adapter *padapter, char
*pie, unsigned short ie
}
RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_info_,
-("rtw_set_wpa_ie: pairwise_cipher = 0x%08x
padapter->securitypriv.ndisencryptstatus =%d
padapter->securitypriv.ndisauthtype =%d\n",
-pairwise_cipher, padapter->securitypriv.ndisencryptstatus,
padapter->securitypriv.ndisauthtype));
+("%s: pairwise_cipher = 0x%08x
padapter->securitypriv.ndisencryptstatus =%d
padapter->securitypriv.ndisauthtype =%d\n",
+ __func__, pairwise_cipher,
padapter->securitypriv.ndisencryptstatus, padapter->securitypriv.ndisauthtype));
exit:
kfree(buf);
return ret;
@@ -660,7 +660,7 @@ static int rtw_wx_set_freq(struct net_device *dev,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra)
{
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_notice_, ("+rtw_wx_set_freq\n"));
+
Re: [PATCH trivial] xtensa: fix Kconfig typo
On Sat, Aug 29, 2020 at 10:57 PM Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Correct trivial typo (ful -> full).
>
> Fixes: 76743c0e0915 ("xtensa: move kernel memory layout to platform options")
> Signed-off-by: Randy Dunlap
> Cc: Chris Zankel
> Cc: Max Filippov
> Cc: linux-xte...@linux-xtensa.org
> Cc: Jiri Kosina
> ---
> arch/xtensa/Kconfig |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Max Filippov
--
Thanks.
-- Max
Re: [PATCH 01/19] char_dev: replace cdev_map with an xarray
On Sun, Aug 30, 2020 at 08:24:27AM +0200, Christoph Hellwig wrote: > None of the complicated overlapping regions bits of the kobj_map are > required for the character device lookup, so just a trivial xarray > instead. > > Signed-off-by: Christoph Hellwig Reviewed-by: Greg Kroah-Hartman
Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()
On 2020/8/30 1:16, Laurent Pinchart wrote:
On Sat, Aug 29, 2020 at 02:10:20PM +0200, Pavel Machek wrote:
Hi!
The value av7110->debi_virt is stored in DMA memory, and it is assigned
to data, and thus data[0] can be modified at any time by malicious
hardware. In this case, "if (data[0] < 2)" can be passed, but then
data[0] can be changed into a large number, which may cause buffer
overflow when the code "av7110->ci_slot[data[0]]" is used.
To fix this possible bug, data[0] is assigned to a local variable, which
replaces the use of data[0].
I'm pretty sure hardware capable of manipulating memory can work
around any such checks, but...
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
case DATA_CI_GET:
{
u8 *data = av7110->debi_virt;
+ u8 data_0 = data[0];
- if ((data[0] < 2) && data[2] == 0xff) {
+ if (data_0 < 2 && data[2] == 0xff) {
int flags = 0;
if (data[5] > 0)
flags |= CA_CI_MODULE_PRESENT;
if (data[5] > 5)
flags |= CA_CI_MODULE_READY;
- av7110->ci_slot[data[0]].flags = flags;
+ av7110->ci_slot[data_0].flags = flags;
This does not even do what it says. Compiler is still free to access
data[0] multiple times. It needs READ_ONCE() to be effective.
Yes, it seems quite dubious to me. If we *really* want to guard against
rogue hardware here, the whole DMA buffer should be copied. I don't
think it's worth it, a rogue PCI device can do much more harm.
From the original driver code, data[0] is considered to be bad and thus
it should be checked, because the content of the DMA buffer may be
problematic.
Based on this consideration, data[0] can be also modified to bypass the
check, and thus its value should be copied to a local variable for the
check and use.
I agree with Pavel that the compiler optimization may drop the copying
operation, and thus READ_ONCE() should be used here.
I will submit a v2 patch soon.
Best wishes,
Jia-Ju Bai
Re: [PATCH 19/19] block: switch gendisk lookup to a simple xarray
On Sun, Aug 30, 2020 at 08:24:45AM +0200, Christoph Hellwig wrote: > Now that bdev_map is only used for finding gendisks, we can use > a simple xarray instead of the regions tracking structure for it. > > Signed-off-by: Christoph Hellwig > --- > block/genhd.c | 208 -- > include/linux/genhd.h | 7 -- > 2 files changed, 37 insertions(+), 178 deletions(-) Reviewed-by: Greg Kroah-Hartman
[PATCH] USB: PHY: JZ4770: Use the generic PHY framework.
Used the generic PHY framework API to create the PHY,
and move the driver to driver/phy/ingenic.
Tested-by: 周正 (Zhou Zheng)
Co-developed-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
drivers/phy/Kconfig| 1 +
drivers/phy/Makefile | 1 +
drivers/phy/ingenic/Kconfig| 12 ++
drivers/phy/ingenic/Makefile | 2 +
.../phy-jz4770.c => phy/ingenic/phy-ingenic-usb.c} | 236 -
drivers/usb/phy/Kconfig| 8 -
drivers/usb/phy/Makefile | 1 -
7 files changed, 155 insertions(+), 106 deletions(-)
create mode 100644 drivers/phy/ingenic/Kconfig
create mode 100644 drivers/phy/ingenic/Makefile
rename drivers/{usb/phy/phy-jz4770.c => phy/ingenic/phy-ingenic-usb.c} (63%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index de9362c25c07..0534b0fdd057 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -55,6 +55,7 @@ source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
source "drivers/phy/freescale/Kconfig"
source "drivers/phy/hisilicon/Kconfig"
+source "drivers/phy/ingenic/Kconfig"
source "drivers/phy/lantiq/Kconfig"
source "drivers/phy/marvell/Kconfig"
source "drivers/phy/mediatek/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c27408e4daae..ab24f0d20763 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -14,6 +14,7 @@ obj-y += allwinner/ \
cadence/ \
freescale/ \
hisilicon/ \
+ ingenic/ \
intel/ \
lantiq/ \
marvell/ \
diff --git a/drivers/phy/ingenic/Kconfig b/drivers/phy/ingenic/Kconfig
new file mode 100644
index ..b9581eae89dd
--- /dev/null
+++ b/drivers/phy/ingenic/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Phy drivers for Ingenic platforms
+#
+config PHY_INGENIC_USB
+ tristate "Ingenic SoCs USB PHY Driver"
+ depends on (MACH_INGENIC && MIPS) || COMPILE_TEST
+ depends on USB_SUPPORT
+ select GENERIC_PHY
+ help
+ This driver provides USB PHY support for the USB controller found
+ on the JZ-series and X-series SoCs from Ingenic.
diff --git a/drivers/phy/ingenic/Makefile b/drivers/phy/ingenic/Makefile
new file mode 100644
index ..65d5ea00fc9d
--- /dev/null
+++ b/drivers/phy/ingenic/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += phy-ingenic-usb.o
diff --git a/drivers/usb/phy/phy-jz4770.c
b/drivers/phy/ingenic/phy-ingenic-usb.c
similarity index 63%
rename from drivers/usb/phy/phy-jz4770.c
rename to drivers/phy/ingenic/phy-ingenic-usb.c
index f6d3731581eb..14029d89cd70 100644
--- a/drivers/usb/phy/phy-jz4770.c
+++ b/drivers/phy/ingenic/phy-ingenic-usb.c
@@ -7,12 +7,12 @@
*/
#include
+#include
#include
#include
#include
#include
-#include
-#include
+#include
/* OTGPHY register offsets */
#define REG_USBPCR_OFFSET 0x00
@@ -97,68 +97,49 @@ enum ingenic_usb_phy_version {
struct ingenic_soc_info {
enum ingenic_usb_phy_version version;
- void (*usb_phy_init)(struct usb_phy *phy);
+ void (*usb_phy_init)(struct phy *phy);
};
-struct jz4770_phy {
+struct ingenic_usb_phy {
const struct ingenic_soc_info *soc_info;
- struct usb_phy phy;
- struct usb_otg otg;
+ struct phy *phy;
struct device *dev;
void __iomem *base;
struct clk *clk;
struct regulator *vcc_supply;
};
-static inline struct jz4770_phy *otg_to_jz4770_phy(struct usb_otg *otg)
+static int ingenic_usb_phy_init(struct phy *phy)
{
- return container_of(otg, struct jz4770_phy, otg);
-}
-
-static inline struct jz4770_phy *phy_to_jz4770_phy(struct usb_phy *phy)
-{
- return container_of(phy, struct jz4770_phy, phy);
-}
-
-static int ingenic_usb_phy_set_peripheral(struct usb_otg *otg,
-struct usb_gadget *gadget)
-{
- struct jz4770_phy *priv = otg_to_jz4770_phy(otg);
- u32 reg;
+ struct ingenic_usb_phy *priv = phy_get_drvdata(phy);
+ int err;
- if (priv->soc_info->version >= ID_X1000) {
- reg = readl(priv->base + REG_USBPCR1_OFFSET);
- reg |= USBPCR1_BVLD_REG;
- writel(reg, priv->base + REG_USBPCR1_OFFSET);
+ err = clk_prepare_enable(priv->clk);
+ if (err) {
+ dev_err(priv->dev, "Unable to start clock: %d\n", err);
+ return err;
}
- reg = readl(priv->base + REG_USBPCR_OFFSET);
-
[PATCH] USB: PHY: JZ4770: Use the generic PHY framework.
Used the generic PHY framework API to create the PHY,
and move the driver to driver/phy/ingenic.
Tested-by: 周正 (Zhou Zheng)
Co-developed-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 漆鹏振 (Qi Pengzhen)
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
drivers/phy/Kconfig| 1 +
drivers/phy/Makefile | 1 +
drivers/phy/ingenic/Kconfig| 12 ++
drivers/phy/ingenic/Makefile | 2 +
.../phy-jz4770.c => phy/ingenic/phy-ingenic-usb.c} | 236 -
drivers/usb/phy/Kconfig| 8 -
drivers/usb/phy/Makefile | 1 -
7 files changed, 155 insertions(+), 106 deletions(-)
create mode 100644 drivers/phy/ingenic/Kconfig
create mode 100644 drivers/phy/ingenic/Makefile
rename drivers/{usb/phy/phy-jz4770.c => phy/ingenic/phy-ingenic-usb.c} (63%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index de9362c25c07..0534b0fdd057 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -55,6 +55,7 @@ source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
source "drivers/phy/freescale/Kconfig"
source "drivers/phy/hisilicon/Kconfig"
+source "drivers/phy/ingenic/Kconfig"
source "drivers/phy/lantiq/Kconfig"
source "drivers/phy/marvell/Kconfig"
source "drivers/phy/mediatek/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c27408e4daae..ab24f0d20763 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -14,6 +14,7 @@ obj-y += allwinner/ \
cadence/ \
freescale/ \
hisilicon/ \
+ ingenic/ \
intel/ \
lantiq/ \
marvell/ \
diff --git a/drivers/phy/ingenic/Kconfig b/drivers/phy/ingenic/Kconfig
new file mode 100644
index ..b9581eae89dd
--- /dev/null
+++ b/drivers/phy/ingenic/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Phy drivers for Ingenic platforms
+#
+config PHY_INGENIC_USB
+ tristate "Ingenic SoCs USB PHY Driver"
+ depends on (MACH_INGENIC && MIPS) || COMPILE_TEST
+ depends on USB_SUPPORT
+ select GENERIC_PHY
+ help
+ This driver provides USB PHY support for the USB controller found
+ on the JZ-series and X-series SoCs from Ingenic.
diff --git a/drivers/phy/ingenic/Makefile b/drivers/phy/ingenic/Makefile
new file mode 100644
index ..65d5ea00fc9d
--- /dev/null
+++ b/drivers/phy/ingenic/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += phy-ingenic-usb.o
diff --git a/drivers/usb/phy/phy-jz4770.c
b/drivers/phy/ingenic/phy-ingenic-usb.c
similarity index 63%
rename from drivers/usb/phy/phy-jz4770.c
rename to drivers/phy/ingenic/phy-ingenic-usb.c
index f6d3731581eb..14029d89cd70 100644
--- a/drivers/usb/phy/phy-jz4770.c
+++ b/drivers/phy/ingenic/phy-ingenic-usb.c
@@ -7,12 +7,12 @@
*/
#include
+#include
#include
#include
#include
#include
-#include
-#include
+#include
/* OTGPHY register offsets */
#define REG_USBPCR_OFFSET 0x00
@@ -97,68 +97,49 @@ enum ingenic_usb_phy_version {
struct ingenic_soc_info {
enum ingenic_usb_phy_version version;
- void (*usb_phy_init)(struct usb_phy *phy);
+ void (*usb_phy_init)(struct phy *phy);
};
-struct jz4770_phy {
+struct ingenic_usb_phy {
const struct ingenic_soc_info *soc_info;
- struct usb_phy phy;
- struct usb_otg otg;
+ struct phy *phy;
struct device *dev;
void __iomem *base;
struct clk *clk;
struct regulator *vcc_supply;
};
-static inline struct jz4770_phy *otg_to_jz4770_phy(struct usb_otg *otg)
+static int ingenic_usb_phy_init(struct phy *phy)
{
- return container_of(otg, struct jz4770_phy, otg);
-}
-
-static inline struct jz4770_phy *phy_to_jz4770_phy(struct usb_phy *phy)
-{
- return container_of(phy, struct jz4770_phy, phy);
-}
-
-static int ingenic_usb_phy_set_peripheral(struct usb_otg *otg,
-struct usb_gadget *gadget)
-{
- struct jz4770_phy *priv = otg_to_jz4770_phy(otg);
- u32 reg;
+ struct ingenic_usb_phy *priv = phy_get_drvdata(phy);
+ int err;
- if (priv->soc_info->version >= ID_X1000) {
- reg = readl(priv->base + REG_USBPCR1_OFFSET);
- reg |= USBPCR1_BVLD_REG;
- writel(reg, priv->base + REG_USBPCR1_OFFSET);
+ err = clk_prepare_enable(priv->clk);
+ if (err) {
+ dev_err(priv->dev, "Unable to start clock: %d\n", err);
+ return err;
}
- reg = readl(priv->base + REG_USBPCR_OFFSET);
-
Re: [net-next v5 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices
Hi David, On Wed, Aug 26, 2020 at 07:34:46AM -0700, David Miller wrote: > From: Vadym Kochan > Date: Wed, 26 Aug 2020 11:17:44 +0300 > > > Initially there was (in RFC patch set), not locking, but _rcu list API > > used, because the port list is modified only by 1 writer when creating > > the port or deleting it on switch uninit (the really theoretical case > > which might happen is that event might be received at that time which > > causes to loop over this list to find the port), as I understand > > correctly list_add_rcu is safe to use with no additional locking if there > > is 1 > > writer and many readers ? So can I use back this approach ? > > Are you really certain only one writer can exist at one time? Yes, list_add() is called on: prestera_pci_probe() -> prestera_device_register() -> prestera_switch_init() -> prestera_create_ports() and list_del() is called on: prestera_pci_remove() -> prestera_device_unregister() -> prestera_switch_fini() -> prestera_destroy_ports() in all other cases the port_list is used for port lookup on rx or when event is received from the fw. So I really think that at least RCU list API might be used or rw lock. In early version the ports were creating before fw event handlers registration, but in this version the ports are creating after event handlers are registered so it really needs locking. Regarding DMA comments, looks like I can get rid of those bounce buffer handling because swiotlb can handle this ? In that case looks like just DMA map/unmap and sync should be enough. Regards, Vadym Kochan
Re: [PATCH v3 1/3] riscv: Set more data to cacheinfo
Hi,
On Fri, Aug 28, 2020 at 10:09 AM Zong Li wrote:
>
> Set cacheinfo.{size,sets,line_size} for each cache node, then we can
> get these information from userland through auxiliary vector.
>
> Signed-off-by: Zong Li
> ---
> arch/riscv/kernel/cacheinfo.c | 59 ++-
> 1 file changed, 44 insertions(+), 15 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index bd0f122965c3..8b85abfbd77a 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -25,12 +25,46 @@ cache_get_priv_group(struct cacheinfo *this_leaf)
> return NULL;
> }
>
> -static void ci_leaf_init(struct cacheinfo *this_leaf,
> -struct device_node *node,
> -enum cache_type type, unsigned int level)
> +static void ci_leaf_init(struct cacheinfo *this_leaf, enum cache_type type,
> +unsigned int level, unsigned int size,
> +unsigned int sets, unsigned int line_size)
> {
> this_leaf->level = level;
> this_leaf->type = type;
> + this_leaf->size = size;
> + this_leaf->number_of_sets = sets;
> + this_leaf->coherency_line_size = line_size;
> +
> + /*
> +* If the cache is fully associative, there is no need to
> +* check the other properties.
> +*/
> + if (!(sets == 1) && (sets > 0 && size > 0 && line_size > 0))
Can you explain what this is attempting to do? AFAICT, the if
expression can be reduced to "sets > 1 && size > 0 && size > 0", but
what do you mean with the comment about fully associative caches?
> + this_leaf->ways_of_associativity = (size / sets) / line_size;
> +}
Re: [EXT] [PATCH] bnx2x: correct a mistake when show error code
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c > b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c > index 1426c691c7c4..0346771396ce 100644 > --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c > +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c > @@ -13562,9 +13560,8 @@ static int bnx2x_ext_phy_common_init(struct bnx2x > *bp, u32 shmem_base_path[], > } > > if (rc) > - netdev_err(bp->dev, "Warning: PHY was not initialized," > - " Port %d\n", > - 0); > + netdev_err(bp->dev, "Warning: PHY was not initialized, Port > %d\n", > +rc); > return rc; Hi Yi, Thanks, but if you want to report rc in this trace - then state "rc = %d" explicitly in the string. Because now its "Port %d" but you put error code in there... Thanks, Igor
Re: [net-next v5 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x)
Hi Chris,
On Wed, Aug 26, 2020 at 04:30:35AM +, Chris Packham wrote:
> Hi Vadym,
>
> On 26/08/20 12:20 am, Vadym Kochan wrote:
> > Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> > ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> > wireless SMB deployment.
> I think there's a typo here or possibly in patch 1. The AC3x family has
> model numbers 98DX3255, 98DX3256, 98DX3257, 98DX3258, 98DX3259,
> 98DX3265, 98DX3268. I'm not sure which variant you're specifically
> targeting but in patch 1 you add the PCI device 0xC804 which corresponds
> to the 98DX3255.
Looks like I need fix the commit message to refer to hw id which is used
in PCI match table.
> > Prestera Switchdev is a firmware based driver that operates via PCI bus.
> > The
> > current implementation supports only boards designed for the Marvell
> > Switchdev
> > solution and requires special firmware.
> >
> > This driver implementation includes only L1, basic L2 support, and RX/TX.
> >
> > The core Prestera switching logic is implemented in prestera_main.c, there
> > is
> > an intermediate hw layer between core logic and firmware. It is
> > implemented in prestera_hw.c, the purpose of it is to encapsulate hw
> > related logic, in future there is a plan to support more devices with
> > different HW related configurations.
> >
> > The following Switchdev features are supported:
> >
> > - VLAN-aware bridge offloading
> > - VLAN-unaware bridge offloading
> > - FDB offloading (learning, ageing)
> > - Switchport configuration
> >
> > The original firmware image is uploaded to the linux-firmware repository.
> >
> > PATCH v5:
> > 0) add Co-developed tags for people who was involved in development.
> >
> > 1) Make SPDX license as separate comment
> >
> > 2) Change 'u8 *' -> 'void *', It allows to avoid not-needed u8*
> > casting.
> >
> > 3) Remove "," in terminated enum's.
> >
> > 4) Use GENMASK(end, start) where it is applicable in.
> >
> > 5) Remove not-needed 'u8 *' casting.
> >
> > 6) Apply common error-check pattern
> >
> > 7) Use ether_addr_copy instead of memcpy
> >
> > 8) Use define for maximum MAC address range (255)
> >
> > 9) Simplify prestera_port_state_set() in prestera_main.c by
> > using separate if-blocks for state setting:
> >
> > if (is_up) {
> > ...
> > } else {
> > ...
> > }
> >
> >which makes logic more understandable.
> >
> > 10) Simplify sdma tx wait logic when checking/updating tx_ring->burst.
> >
> > 11) Remove not-needed packed & aligned attributes
> >
> > 12) Use USEC_PER_MSEC as multiplier when converting ms -> usec on
> > calling
> > readl_poll_timeout.
> >
> > 13) Simplified some error path handling by simple return error code in.
> >
> > 14) Remove not-needed err assignment in.
> >
> > 15) Use dev_err() in prestera_devlink_register(...).
> >
> > Patches updated:
> > [1] net: marvell: prestera: Add driver for Prestera family ASIC
> > devices
> > [2] net: marvell: prestera: Add PCI interface support
> > [3] net: marvell: prestera: Add basic devlink support
> > [4] net: marvell: prestera: Add ethtool interface support
> > [5] net: marvell: prestera: Add Switchdev driver implementation
> >
> > PATCH v4:
> > 1) Use prestera_ prefix in netdev_ops variable.
> >
> > 2) Kconfig: use 'default PRESTERA' build type for CONFIG_PRESTERA_PCI
> > to be
> > synced by default with prestera core module.
> >
> > 3) Use memcpy_xxio helpers in prestera_pci.c for IO buffer copying.
> >
> > 4) Generate fw image path via snprintf() instead of macroses.
> >
> > 5) Use pcim_ helpers in prestera_pci.c which simplified the
> > probe/remove logic.
> >
> > 6) Removed not needed initializations of variables which are used in
> > readl_poll_xxx() helpers.
> >
> > 7) Fixed few grammar mistakes in patch[2] description.
> >
> > 8) Export only prestera_ethtool_ops struct instead of each
> > ethtool handler.
> >
> > 9) Add check for prestera_dev_check() in switchdev event handling to
> > make sure there is no wrong topology.
> >
> > Patches updated:
> > [1] net: marvell: prestera: Add driver for Prestera family ASIC
> > devices
> > [2] net: marvell: prestera: Add PCI interface support
> > [4] net: marvell: prestera: Add ethtool interface support
> > [5] net: marvell: prestera: Add Switchdev driver implementation
> >
> > PATCH v3:
> > 1) Simplify __be32 type casting in prestera_dsa.c
> >
> > 2) Added per-patch changelog under "---" line.
> >
> > PATCH v2:
> > 1) Use devlink_port_type_clear()
> >
> > 2) Add _MS prefix to timeout defines.
> >
> > 3) Remove not-needed packed attribute from the firmware ipc structs,
> > also the firmware image needs to be uploade
Re: [PATCH v3 3/3] riscv: Add cache information in AUX vector
On Fri, Aug 28, 2020 at 10:09 AM Zong Li wrote:
> +uintptr_t get_cache_geometry(u32 level, enum cache_type type)
> +{
> + struct cacheinfo *this_leaf = get_cacheinfo(level, type);
> + uintptr_t ret = (this_leaf->ways_of_associativity << 16 |
> +this_leaf->coherency_line_size);
You are dereferencing "this_leaf" without checking if it's NULL here.
> +
> + return this_leaf ? ret : 0;
> +}
- Pekka
[PATCH v1] i2c: npcm7xx: bug fix timeout (usec instead of msec)
i2c: npcm7xx: bug fix timeout (usec instead of msec)
Signed-off-by: Tali Perry
---
drivers/i2c/busses/i2c-npcm7xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-npcm7xx.c b/drivers/i2c/busses/i2c-npcm7xx.c
index 75f07138a6fa..c118f93a2610 100644
--- a/drivers/i2c/busses/i2c-npcm7xx.c
+++ b/drivers/i2c/busses/i2c-npcm7xx.c
@@ -2094,7 +2094,7 @@ static int npcm_i2c_master_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
}
/* Adaptive TimeOut: astimated time in usec + 100% margin */
- timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
+ timeout_usec = (2 * 1000 / bus->bus_freq) * (2 + nread + nwrite);
timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
--
2.22.0
[PATCH] rtc: s3c: Simplify with dev_err_probe()
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski
---
drivers/rtc/rtc-s3c.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index e1b50e682fc4..24a41909f049 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -494,13 +494,8 @@ static int s3c_rtc_probe(struct platform_device *pdev)
if (info->data->needs_src_clk) {
info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
if (IS_ERR(info->rtc_src_clk)) {
- ret = PTR_ERR(info->rtc_src_clk);
- if (ret != -EPROBE_DEFER)
- dev_err(&pdev->dev,
- "failed to find rtc source clock\n");
- else
- dev_dbg(&pdev->dev,
- "probe deferred due to missing rtc src
clk\n");
+ ret = dev_err_probe(&pdev->dev,
PTR_ERR(info->rtc_src_clk),
+ "failed to find rtc source
clock\n");
goto err_src_clk;
}
ret = clk_prepare_enable(info->rtc_src_clk);
--
2.17.1
Re: [PATCH v2 2/3] media: i2c: Add support for the OV8865 image sensor
Hi "Kévin, Thank you for the patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on sunxi/sunxi/for-next robh/for-next v5.9-rc2 next-20200828] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/K-vin-L-h-pital/Add-support-of-OV8865-camera/20200828-211747 base: git://linuxtv.org/media_tree.git master config: x86_64-rhel compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> drivers/media/i2c/Kconfig:741:error: recursive dependency detected! drivers/media/i2c/Kconfig:741: symbol VIDEO_IMX214 depends on V4L2_FWNODE drivers/media/v4l2-core/Kconfig:71: symbol V4L2_FWNODE is selected by VIDEO_OV8865 drivers/media/i2c/Kconfig:1036: symbol VIDEO_OV8865 depends on VIDEO_V4L2_SUBDEV_API drivers/media/v4l2-core/Kconfig:19: symbol VIDEO_V4L2_SUBDEV_API depends on MEDIA_CONTROLLER drivers/media/Kconfig:168: symbol MEDIA_CONTROLLER is selected by VIDEO_IMX214 For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" # https://github.com/0day-ci/linux/commit/15f1e4a812c9d0e0352da215cd3de05e4a07b8d7 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review K-vin-L-h-pital/Add-support-of-OV8865-camera/20200828-211747 git checkout 15f1e4a812c9d0e0352da215cd3de05e4a07b8d7 vim +741 drivers/media/i2c/Kconfig 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 718 5c57ae64e8bccc6 Mauro Carvalho Chehab 2020-04-15 719 menu "Camera sensor devices" 5c57ae64e8bccc6 Mauro Carvalho Chehab 2020-04-15 720 visible if MEDIA_CAMERA_SUPPORT f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 721 f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 722 config VIDEO_APTINA_PLL f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 723 tristate f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 724 f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 725 config VIDEO_SMIAPP_PLL f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 726 tristate f48fd1514212b5c Mauro Carvalho Chehab 2020-03-25 727 e62138403a841e4 Shawn Tu 2019-11-01 728 config VIDEO_HI556 e62138403a841e4 Shawn Tu 2019-11-01 729 tristate "Hynix Hi-556 sensor support" 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 730 depends on I2C && VIDEO_V4L2 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 731 select MEDIA_CONTROLLER 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 732 select VIDEO_V4L2_SUBDEV_API e62138403a841e4 Shawn Tu 2019-11-01 733 select V4L2_FWNODE e62138403a841e4 Shawn Tu 2019-11-01 734 help e62138403a841e4 Shawn Tu 2019-11-01 735 This is a Video4Linux2 sensor driver for the Hynix e62138403a841e4 Shawn Tu 2019-11-01 736 Hi-556 camera. e62138403a841e4 Shawn Tu 2019-11-01 737 e62138403a841e4 Shawn Tu 2019-11-01 738 To compile this driver as a module, choose M here: the e62138403a841e4 Shawn Tu 2019-11-01 739 module will be called hi556. e62138403a841e4 Shawn Tu 2019-11-01 740 4361905962417ef Ricardo Ribalda 2018-10-05 @741 config VIDEO_IMX214 4361905962417ef Ricardo Ribalda 2018-10-05 742 tristate "Sony IMX214 sensor support" 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 743 depends on GPIOLIB && I2C && VIDEO_V4L2 4361905962417ef Ricardo Ribalda 2018-10-05 744 depends on V4L2_FWNODE 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 745 select MEDIA_CONTROLLER 32a363d0b0b142f Mauro Carvalho Chehab 2020-03-25 746 select VIDEO_V4L2_SUBDEV_API 6de18fa3bd1dd51 Ian Kumlien 2020-02-26 747 select REGMAP_I2C 4361905962417ef Ricardo Ribalda 2018-10-05 748 help 4361905962417ef Ricardo Ribalda 2018-10-05 749 This is a Video4Linux2 sensor driver for the Sony 4361905962417ef Ricardo Ribalda 2018-10-05 750 IMX214 camera. 4361905962417ef Ricardo Ribalda 2018-10-05 751 4361905962417ef Ricardo Ribalda 2018-10-05 752 To compile this driver as a module, choose M here: the 4361905962417ef Ricardo Ribalda 2018-10-05 753 module will be called imx214. 4361905962417ef Ricardo Ribalda 2018-10-05 754 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v1] [media] netup_unidvb: use generic power management
On Tue, Jul 28, 2020 at 02:57:17PM +0530, Vaibhav Gupta wrote:
> The .suspend() and .resume() callbacks are not defined for this driver.
> Still, their power management structure follows the legacy framework. To
> bring it under the generic framework, simply remove the binding of
> callbacks from "struct pci_driver".
Unlisted fields in a static struct initializer will get set to 0 (or NULL
for pointers) already. Removing the NULL initializers will not change
anything.
Possibly you want to remove the redundant initializers but your commit
message should say so.
Sean
>
> Signed-off-by: Vaibhav Gupta
> ---
> drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> index 80a7c41baa90..6f3125c2d097 100644
> --- a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> +++ b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> @@ -1016,8 +1016,6 @@ static struct pci_driver netup_unidvb_pci_driver = {
> .id_table = netup_unidvb_pci_tbl,
> .probe= netup_unidvb_initdev,
> .remove = netup_unidvb_finidev,
> - .suspend = NULL,
> - .resume = NULL,
> };
>
> module_pci_driver(netup_unidvb_pci_driver);
> --
> 2.27.0
[PATCH] mm/memory-failure: Fix return wrong value when isolate page fail
When we isolate page fail, we should not return 0, because we do not
set page HWPoison on any page.
Signed-off-by: Muchun Song
---
mm/memory-failure.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 696505f56910..4eb3c42ffe35 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1850,6 +1850,7 @@ static int __soft_offline_page(struct page *page)
} else {
pr_info("soft offline: %#lx: %s isolation failed: %d, page
count %d, type %lx (%pGp)\n",
pfn, msg_page[huge], ret, page_count(page),
page->flags, &page->flags);
+ ret = -EBUSY;
}
return ret;
}
--
2.11.0
Re: [PATCH 05/17] virt: acrn: Introduce ACRN HSM basic driver
Hi Dave,
On Sat 29.Aug'20 at 9:12:22 -0700, Dave Hansen wrote:
On 8/29/20 3:46 AM, Shuo A Liu wrote:
On Fri 28.Aug'20 at 12:25:59 +0200, Greg Kroah-Hartman wrote:
On Tue, Aug 25, 2020 at 10:45:05AM +0800, shuo.a@intel.com wrote:
+static long acrn_dev_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long ioctl_param)
+{
+ if (cmd == ACRN_IOCTL_GET_API_VERSION) {
+ if (copy_to_user((void __user *)ioctl_param,
+ &api_version, sizeof(api_version)))
+ return -EFAULT;
Why are you versioning your api? Shouldn't that not be a thing and you
either support an ioctl or you do not?
The API version here is more for the hypercalls.
The hypercalls might evolve later
They might evolve, but the old ones must always keep working. Right?
Yes, it's right.
and the version indicates which set of interfaces (include the
paramters' format) should be used by user space tools. Currently,
it's used rarely.
Why do you need this when the core kernel doesn't? We add syscalls,
ioctl()s and prctl()s all the time, but nothing is versioned.
Indeed. It looks a bit odd.
This sounds like something you need to remove from the series.
OK. I will remove the api version related code.
Thanks
shuo
[PATCH] media: pci: ttpci: av7110: avoid compiler optimization of reading data[0] in debiirq()
In debiirq(), data_0 stores the value of data[0], but it can be dropped
by compiler optimization. Thus, data[0] is read through READ_ONCE().
Fixes: 6499a0db9b0f ("media: pci: ttpci: av7110: fix possible buffer overflow
caused by bad DMA value in debiirq()")
Reported-by: Pavel Machek
Signed-off-by: Jia-Ju Bai
---
drivers/media/pci/ttpci/av7110.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c
index bf36b1e22b63..f7d098d5b198 100644
--- a/drivers/media/pci/ttpci/av7110.c
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -406,7 +406,7 @@ static void debiirq(unsigned long cookie)
case DATA_CI_GET:
{
u8 *data = av7110->debi_virt;
- u8 data_0 = data[0];
+ u8 data_0 = READ_ONCE(data[0]);
if (data_0 < 2 && data[2] == 0xff) {
int flags = 0;
--
2.17.1
Re: [PATCH] media: pci: ttpci: av7110: avoid compiler optimization of reading data[0] in debiirq()
On Sun, Aug 30, 2020 at 04:20:42PM +0800, Jia-Ju Bai wrote:
> In debiirq(), data_0 stores the value of data[0], but it can be dropped
> by compiler optimization. Thus, data[0] is read through READ_ONCE().
>
> Fixes: 6499a0db9b0f ("media: pci: ttpci: av7110: fix possible buffer overflow
> caused by bad DMA value in debiirq()")
> Reported-by: Pavel Machek
Pavel reported that your patch was garbage, if you are trying to defend
against a malicious pci device. READ_ONCE() will not help here.
Sean
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/media/pci/ttpci/av7110.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/ttpci/av7110.c
> b/drivers/media/pci/ttpci/av7110.c
> index bf36b1e22b63..f7d098d5b198 100644
> --- a/drivers/media/pci/ttpci/av7110.c
> +++ b/drivers/media/pci/ttpci/av7110.c
> @@ -406,7 +406,7 @@ static void debiirq(unsigned long cookie)
> case DATA_CI_GET:
> {
> u8 *data = av7110->debi_virt;
> - u8 data_0 = data[0];
> + u8 data_0 = READ_ONCE(data[0]);
>
> if (data_0 < 2 && data[2] == 0xff) {
> int flags = 0;
> --
> 2.17.1
Re: [PATCH 1/2] mm: use add_page_to_lru_list()/page_lru()/page_off_lru()
在 2020/8/30 上午2:12, Yu Zhao 写道:
> On Thu, Aug 27, 2020 at 05:42:01PM -0600, Yu Zhao wrote:
>> This is a trivial but worth having clean-up patch. There should be
>> no side effects except page->lru is temporarily poisoned after it's
>> deleted but before it's added to the new list in move_pages_to_lru()
>> (which is not a problem).
>>
>> Signed-off-by: Yu Zhao
>
> Hi Alex, I just realized your
> [v18,08/32] mm/vmscan: remove unnecessary lruvec adding
> at
> https://patchwork.kernel.org/patch/11733123/
> also touches move_pages_to_lru(). I agree it's better not to add
> a page we are going to free to the list in the first place. The
> rest in this patch would be too trivial to be a separate one (on
> top of yours).
>
> So would you mind taking of the clean-up too in your series? I'll
> drop this one then. Thanks.
>
>> ---
>> mm/swap.c | 4 +---
>> mm/vmscan.c | 14 --
>> 2 files changed, 5 insertions(+), 13 deletions(-)
>>
>> diff --git a/mm/swap.c b/mm/swap.c
>> index 40bf20a75278..2735ecf0f566 100644
>> --- a/mm/swap.c
>> +++ b/mm/swap.c
>> @@ -597,11 +597,9 @@ static void lru_lazyfree_fn(struct page *page, struct
>> lruvec *lruvec,
>> {
>> if (PageLRU(page) && PageAnon(page) && PageSwapBacked(page) &&
>> !PageSwapCache(page) && !PageUnevictable(page)) {
>> -bool active = PageActive(page);
>> int nr_pages = thp_nr_pages(page);
>>
>> -del_page_from_lru_list(page, lruvec,
>> - LRU_INACTIVE_ANON + active);
>> +del_page_from_lru_list(page, lruvec, page_lru(page));
>> ClearPageActive(page);
>> ClearPageReferenced(page);
>> /*
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 99e1796eb833..b479ced26cd3 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -1845,13 +1845,12 @@ static unsigned noinline_for_stack
>> move_pages_to_lru(struct lruvec *lruvec,
>> int nr_pages, nr_moved = 0;
>> LIST_HEAD(pages_to_free);
>> struct page *page;
>> -enum lru_list lru;
>>
>> while (!list_empty(list)) {
>> page = lru_to_page(list);
>> VM_BUG_ON_PAGE(PageLRU(page), page);
>> +list_del(&page->lru);
>> if (unlikely(!page_evictable(page))) {
>> -list_del(&page->lru);
>> spin_unlock_irq(&pgdat->lru_lock);
>> putback_lru_page(page);
>> spin_lock_irq(&pgdat->lru_lock);
>> @@ -1860,16 +1859,10 @@ static unsigned noinline_for_stack
>> move_pages_to_lru(struct lruvec *lruvec,
>> lruvec = mem_cgroup_page_lruvec(page, pgdat);
>>
>> SetPageLRU(page);
>> -lru = page_lru(page);
>> -
>> -nr_pages = thp_nr_pages(page);
>> -update_lru_size(lruvec, lru, page_zonenum(page), nr_pages);
>> -list_move(&page->lru, &lruvec->lists[lru]);
>> +add_page_to_lru_list(page, lruvec, page_lru(page));
>>
>> if (put_page_testzero(page)) {
>> -__ClearPageLRU(page);
it's interesting to know the PageLRU left has no bad impact in real life.
it justs seems a path confliction with my that patch.
>> -__ClearPageActive(page);
>> -del_page_from_lru_list(page, lruvec, lru);
>> +del_page_from_lru_list(page, lruvec,
>> page_off_lru(page));
>>
>> if (unlikely(PageCompound(page))) {
>> spin_unlock_irq(&pgdat->lru_lock);
>> @@ -1878,6 +1871,7 @@ static unsigned noinline_for_stack
>> move_pages_to_lru(struct lruvec *lruvec,
>> } else
>> list_add(&page->lru, &pages_to_free);
>> } else {
>> +nr_pages = thp_nr_pages(page);
>> nr_moved += nr_pages;
>> if (PageActive(page))
>> workingset_age_nonresident(lruvec, nr_pages);
>> --
>> 2.28.0.402.g5ffc5be6b7-goog
>>
[PATCH rdma-next v1 00/10] Restore failure of destroy commands
From: Leon Romanovsky Changelog: v1: * Changed returned value in efa_destroy_ah() from EINVAL to EOPNOTSUPP v0: * https://lore.kernel.org/lkml/20200824103247.1088464-1-l...@kernel.org - Hi, This series restores the ability to fail on destroy commands, due to the fact that mlx5_ib DEVX implementation interleaved ib_core objects with FW objects without sharing reference counters. In a retrospective, every part of the mlx5_ib flow is correct. It started from IBTA which was written by HW engineers with HW in mind and they allowed to fail in destruction. FW implemented it with symmetrical interface like any other command and propagated error back to the kernel, which forwarded it to the libibverbs and kernel ULPs. Libibverbs was designed with IBTA spec in hand putting destroy errors in stone. Up till mlx5_ib DEVX, it worked well, because the IB verbs objects are counted by the kernel and ib_core ensures that FW destroy will success by managing various reference counters on such objects. The extension of the mlx5 driver changed this flow when allowed DEVX objects that are not managed by ib_core to be interleaved with the ones under ib_core responsibility. The drivers that want to implement DEVX flows, must ensure that FW/HW destroys are performed as early as possible before any other internal cleanup. After HW destroys, drivers are not allowed to fail. This series includes two patches (WQ and "potential race") that will require extra work in mlx5_ib, they both theoretical. WQ is not in use in DEVX, but is needed to make interface symmetrical to other objects. "Potential race" is in ULP flow that ensures that SRQ is destoyed in proper order. Thanks Leon Romanovsky (10): RDMA: Restore ability to fail on PD deallocate RDMA: Restore ability to fail on AH destroy RDMA/mlx5: Issue FW command to destroy SRQ on reentry RDMA/mlx5: Fix potential race between destroy and CQE poll RDMA: Restore ability to fail on SRQ destroy RDMA/core: Delete function indirection for alloc/free kernel CQ RDMA: Allow fail of destroy CQ RDMA: Change XRCD destroy return value RDMA: Restore ability to return error for destroy WQ RDMA: Make counters destroy symmetrical drivers/infiniband/core/cq.c | 36 +++--- drivers/infiniband/core/uverbs_std_types.c| 3 +- .../core/uverbs_std_types_counters.c | 4 +- drivers/infiniband/core/uverbs_std_types_wq.c | 2 +- drivers/infiniband/core/verbs.c | 56 +++--- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 12 +- drivers/infiniband/hw/bnxt_re/ib_verbs.h | 8 +- drivers/infiniband/hw/cxgb4/cq.c | 3 +- drivers/infiniband/hw/cxgb4/iw_cxgb4.h| 4 +- drivers/infiniband/hw/cxgb4/provider.c| 3 +- drivers/infiniband/hw/cxgb4/qp.c | 3 +- drivers/infiniband/hw/efa/efa.h | 6 +- drivers/infiniband/hw/efa/efa_verbs.c | 11 +- drivers/infiniband/hw/hns/hns_roce_ah.c | 5 - drivers/infiniband/hw/hns/hns_roce_cq.c | 3 +- drivers/infiniband/hw/hns/hns_roce_device.h | 13 ++- drivers/infiniband/hw/hns/hns_roce_hw_v1.c| 3 +- drivers/infiniband/hw/hns/hns_roce_pd.c | 3 +- drivers/infiniband/hw/hns/hns_roce_srq.c | 3 +- drivers/infiniband/hw/i40iw/i40iw_verbs.c | 6 +- drivers/infiniband/hw/mlx4/ah.c | 5 - drivers/infiniband/hw/mlx4/cq.c | 3 +- drivers/infiniband/hw/mlx4/main.c | 6 +- drivers/infiniband/hw/mlx4/mlx4_ib.h | 11 +- drivers/infiniband/hw/mlx4/qp.c | 3 +- drivers/infiniband/hw/mlx4/srq.c | 3 +- drivers/infiniband/hw/mlx5/ah.c | 5 - drivers/infiniband/hw/mlx5/cmd.c | 4 +- drivers/infiniband/hw/mlx5/cmd.h | 2 +- drivers/infiniband/hw/mlx5/counters.c | 3 +- drivers/infiniband/hw/mlx5/cq.c | 21 ++-- drivers/infiniband/hw/mlx5/main.c | 4 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 13 ++- drivers/infiniband/hw/mlx5/qp.c | 12 +- drivers/infiniband/hw/mlx5/qp.h | 4 +- drivers/infiniband/hw/mlx5/qpc.c | 5 +- drivers/infiniband/hw/mlx5/srq.c | 26 ++--- drivers/infiniband/hw/mlx5/srq.h | 2 +- drivers/infiniband/hw/mlx5/srq_cmd.c | 22 +++- drivers/infiniband/hw/mthca/mthca_provider.c | 12 +- drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 3 +- drivers/infiniband/hw/ocrdma/ocrdma_ah.h | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 11 +- drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 6 +- drivers/infiniband/hw/qedr/verbs.c| 14 ++- drivers/infiniband/hw/qedr/verbs.h| 8 +- drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 7 +- drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 4 +- drivers/infi
[PATCH] dt-bindings: gpu: arm,mali-utgard: Use unevaluatedProperties
Additional properties or nodes actually might appear (e.g. operating points table) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300: 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index 6226d31ec4b7..021690391bea 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -119,7 +119,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false allOf: - if: -- 2.17.1
Re: [PATCH v1] [media] netup_unidvb: use generic power management
On Sun, Aug 30, 2020 at 09:10:04AM +0100, Sean Young wrote: > On Tue, Jul 28, 2020 at 02:57:17PM +0530, Vaibhav Gupta wrote: > > The .suspend() and .resume() callbacks are not defined for this driver. > > Still, their power management structure follows the legacy framework. To > > bring it under the generic framework, simply remove the binding of > > callbacks from "struct pci_driver". > > Unlisted fields in a static struct initializer will get set to 0 (or NULL > for pointers) already. Removing the NULL initializers will not change > anything. > > Possibly you want to remove the redundant initializers but your commit > message should say so. > > > Sean > Hello Sean, Yes, you are right. I mentioned a general commit message. I will send a v2 with suggested changes. Thank you Vaibhav Gupta
Re: [PATCH v1] i2c: npcm7xx: bug fix timeout (usec instead of msec)
Hi Tali,
On Sun, Aug 30, 2020 at 11:09 AM Tali Perry wrote:
>
> i2c: npcm7xx: bug fix timeout (usec instead of msec)
>
> Signed-off-by: Tali Perry
> ---
> drivers/i2c/busses/i2c-npcm7xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-npcm7xx.c
> b/drivers/i2c/busses/i2c-npcm7xx.c
> index 75f07138a6fa..c118f93a2610 100644
> --- a/drivers/i2c/busses/i2c-npcm7xx.c
> +++ b/drivers/i2c/busses/i2c-npcm7xx.c
> @@ -2094,7 +2094,7 @@ static int npcm_i2c_master_xfer(struct i2c_adapter
> *adap, struct i2c_msg *msgs,
> }
>
> /* Adaptive TimeOut: astimated time in usec + 100% margin */
> - timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
I suggest to add a short description like:
2: double the timeout for clock stretching case
9: bits per transaction (including the avk/nack)
100: micro second in a second
timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread + nwrite);
> + timeout_usec = (2 * 1000 / bus->bus_freq) * (2 + nread + nwrite);
> timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
> if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
>
> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
> --
> 2.22.0
>
--
Regards,
Avi
[PATCH] dt-bindings: gpu: arm,mali-utgard: Correct Maxime's email
Update the address of Maxime Ripard as one in @free-electrons.com does not work. Cc: Maxime Ripard Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index 021690391bea..869ef648644e 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -8,7 +8,7 @@ title: ARM Mali Utgard GPU maintainers: - Rob Herring - - Maxime Ripard + - Maxime Ripard - Heiko Stuebner properties: -- 2.17.1
Re: [PATCH V2] sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
On Sat, 29 Aug 2020, Joe Perches wrote:
> On Sat, 2020-08-29 at 16:48 -0700, Joe Perches wrote:
> > Output defects can exist in sysfs content using sprintf and snprintf.
> >
> > sprintf does not know the PAGE_SIZE maximum of the temporary buffer
> > used for outputting sysfs content and it's possible to overrun the
> > PAGE_SIZE buffer length.
> >
> > Add a generic sysfs_emit function that knows that the size of the
> > temporary buffer and ensures that no overrun is done.
> >
> > Add a generic sysfs_emit_at function that can be used in multiple
> > call situations that also ensures that no overrun is done.
>
> This preliminary coccinelle script converts ~5000 instances treewide.
> There are still many remaining instances that could be converted.
Except for the issue with the ...s that has been discussed, this looks
basically reasonable to me.
julia
>
> $ git grep -w sysfs_emit -- '*.[ch]'|wc -l
> 4702
> $ git grep -w sysfs_emit_at -- '*.[ch]'|wc -l
> 229
>
> $ cat sysfs_emit.cocci
> @@
> identifier d_show =~ "^.*show.*$";
> identifier arg1, arg2, arg3;
> @@
> ssize_t d_show(struct device *
> - arg1
> + dev
> , struct device_attribute *
> - arg2
> + attr
> , char *
> - arg3
> + buf
> )
> {
> ...
> (
> - arg1
> + dev
> |
> - arg2
> + attr
> |
> - arg3
> + buf
> )
> ...
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> return
> - sprintf(buf,
> + sysfs_emit(buf,
> ...);
> ...>
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> return
> - snprintf(buf, PAGE_SIZE,
> + sysfs_emit(buf,
> ...);
> ...>
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> return
> - scnprintf(buf, PAGE_SIZE,
> + sysfs_emit(buf,
> ...);
> ...>
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> expression chr;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> return
> - strcpy(buf, chr);
> + sysfs_emit(buf, chr);
> ...>
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> identifier len;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> len =
> - sprintf(buf,
> + sysfs_emit(buf,
> ...);
> ...>
> return len;
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> identifier len;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> len =
> - snprintf(buf, PAGE_SIZE,
> + sysfs_emit(buf,
> ...);
> ...>
> return len;
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> identifier len;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> len =
> - scnprintf(buf, PAGE_SIZE,
> + sysfs_emit(buf,
> ...);
> ...>
> return len;
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> identifier len;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> <...
> - len += scnprintf(buf + len, PAGE_SIZE - len,
> + len += sysfs_emit_at(buf, len,
> ...);
> ...>
> return len;
> }
>
> @@
> identifier d_show =~ "^.*show.*$";
> identifier dev, attr, buf;
> expression chr;
> @@
>
> ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> - strcpy(buf, chr);
> - return strlen(buf);
> + return sysfs_emit(buf, chr);
> }
>
> @@
> identifier k_show =~ "^.*show.*$";
> identifier arg1, arg2, arg3;
> @@
> ssize_t k_show(struct kobject *
> - arg1
> + kobj
> , struct kobj_attribute *
> - arg2
> + attr
> , char *
> - arg3
> + buf
> )
> {
> ...
> (
> - arg1
> + kobj
> |
> - arg2
> + attr
> |
> - arg3
> + buf
> )
> ...
> }
>
> @@
> identifier k_show =~ "^.*show.*$";
> identifier kobj, attr, buf;
> @@
>
> ssize_t k_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> {
> <...
> return
> - sprintf(buf,
> + sysfs_emit(buf,
> ...);
> ...>
> }
>
> @@
> identifier k_show =~ "^.*show.*$";
> identifier kobj, attr, buf;
> @@
>
> ssize_t k_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> {
> <...
> return
> - snprintf(buf, PAGE_SIZE,
> + sysfs_emit(buf,
> ...);
> ...>
> }
>
> @@
> identifier k_show =~ "^.*sho
Re: [PATCH 5/5] powerpc: use the generic dma_ops_bypass mode
Hello,
On 7/8/20 5:24 PM, Christoph Hellwig wrote:
> Use the DMA API bypass mechanism for direct window mappings. This uses
> common code and speed up the direct mapping case by avoiding indirect
> calls just when not using dma ops at all. It also fixes a problem where
> the sync_* methods were using the bypass check for DMA allocations, but
> those are part of the streaming ops.
>
> Note that this patch loses the DMA_ATTR_WEAK_ORDERING override, which
> has never been well defined, as is only used by a few drivers, which
> IIRC never showed up in the typical Cell blade setups that are affected
> by the ordering workaround.
>
> Fixes: efd176a04bef ("powerpc/pseries/dma: Allow SWIOTLB")
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/device.h | 5 --
> arch/powerpc/kernel/dma-iommu.c | 90 ---
> 3 files changed, 10 insertions(+), 86 deletions(-)
I am seeing corruptions on a couple of POWER9 systems (boston) when
stressed with IO. stress-ng gives some results but I have first seen
it when compiling the kernel in a guest and this is still the best way
to raise the issue.
These systems have of a SAS Adaptec controller :
0003:01:00.0 Serial Attached SCSI controller: Adaptec Series 8 12G SAS/PCIe 3
(rev 01)
When the failure occurs, the POWERPC EEH interrupt fires and dumps
lowlevel PHB4 registers among which :
[ 2179.251069490,3] PHB#0003[0:3]: phbErrorStatus = 0280
[ 2179.251117476,3] PHB#0003[0:3]: phbFirstErrorStatus = 0200
The bits raised identify a PPC 'TCE' error, which means it is related
to DMAs. See below for more details.
Reverting this patch "fixes" the issue but it is probably else where,
in some other layers or in the aacraid driver. How should I proceed
to get more information ?
Thanks,
C.
[ 2054.970339] EEH: Frozen PE#1fd on PHB#3 detected
[ 2054.970375] EEH: PE location: UOPWR.BOS0019-Node0-Onboard SAS, PHB location:
N/A
[ 2179.249415973,3] PHB#0003[0:3]: brdgCtl = 0002
[ 2179.249515795,3] PHB#0003[0:3]: deviceStatus = 00060040
[ 2179.249596452,3] PHB#0003[0:3]: slotStatus = 00402000
[ 2179.249633728,3] PHB#0003[0:3]: linkStatus = a0830008
[ 2179.249674807,3] PHB#0003[0:3]: devCmdStatus = 00100107
[ 2179.249725974,3] PHB#0003[0:3]: devSecStatus = 00100107
[ 2179.249773550,3] PHB#0003[0:3]: rootErrorStatus =
[ 2179.249809823,3] PHB#0003[0:3]: corrErrorStatus =
[ 2179.249850439,3] PHB#0003[0:3]:uncorrErrorStatus =
[ 2179.249887411,3] PHB#0003[0:3]: devctl = 0040
[ 2179.249928677,3] PHB#0003[0:3]: devStat = 0006
[ 2179.249967150,3] PHB#0003[0:3]: tlpHdr1 =
[ 2179.250054987,3] PHB#0003[0:3]: tlpHdr2 =
[ 2179.250146600,3] PHB#0003[0:3]: tlpHdr3 =
[ 2179.250262780,3] PHB#0003[0:3]: tlpHdr4 =
[ 2179.250343101,3] PHB#0003[0:3]: sourceId =
[ 2179.250514264,3] PHB#0003[0:3]: nFir =
[ 2179.250717971,3] PHB#0003[0:3]: nFirMask = 0030001c
[ 2179.250791474,3] PHB#0003[0:3]: nFirWOF =
[ 2179.250842054,3] PHB#0003[0:3]: phbPlssr = 001c
[ 2179.250886003,3] PHB#0003[0:3]: phbCsr = 001c
[ 2179.250929859,3] PHB#0003[0:3]: lemFir = 00010080
[ 2179.250973720,3] PHB#0003[0:3]: lemErrorMask =
[ 2179.251018622,3] PHB#0003[0:3]: lemWOF = 0080
[ 2179.251069490,3] PHB#0003[0:3]: phbErrorStatus = 0280
[ 2179.251117476,3] PHB#0003[0:3]: phbFirstErrorStatus = 0200
[ 2179.251162218,3] PHB#0003[0:3]: phbErrorLog0 = 214898000240
[ 2179.251206251,3] PHB#0003[0:3]: phbErrorLog1 = a0084000
[ 2179.251253096,3] PHB#0003[0:3]:phbTxeErrorStatus =
[ 2179.265087656,3] PHB#0003[0:3]: phbTxeFirstErrorStatus =
[ 2179.265142247,3] PHB#0003[0:3]: phbTxeErrorLog0 =
[ 2179.265189734,3] PHB#0003[0:3]: phbTxeErrorLog1 =
[ 2179.266335296,3] PHB#0003[0:3]: phbRxeArbErrorStatus =
[ 2179.266380366,3] PHB#0003[0:3]: phbRxeArbFrstErrorStatus =
[ 2179.266426523,3] PHB#0003[0:3]: phbRxeArbErrorLog0 =
[ 2179.267537283,3] PHB#0003[0:3]: phbRxeArbErrorLog1 =
[ 2179.267581708,3] PHB#0003[0:3]: phbRxeMrgErrorStatus =
[ 2179.267628324,3] PHB#0003[0:3]: phbRxeMrgFrstErrorStatus =
[ 2179.268748771,3] PHB#0003[0:3]: phbRxeMrgErrorLog
Re: [PATCH] fat: Avoid oops when bdi->io_pages==0
Matthew Wilcox writes: > On Sun, Aug 30, 2020 at 10:54:35AM +0900, OGAWA Hirofumi wrote: >> Matthew Wilcox writes: >> >> Hm, io_pages is limited by driver setting too, and io_pages can be lower >> than ra_pages, e.g. usb storage. >> >> Assuming ra_pages is user intent of readahead window. So if io_pages is >> lower than ra_pages, this try ra_pages to align of io_pages chunk, but >> not bigger than ra_pages. Because if block layer splits I/O requests to >> hard limit, then I/O is not optimal. >> >> So it is intent, I can be misunderstanding though. > > Looking at this some more, I'm not sure it makes sense to consult ->io_pages > at all. I see how it gets set to 0 -- the admin can write '1' to > /sys/block//queue/max_sectors_kb and that gets turned into 0 > in ->io_pages. if (max_sectors_kb > max_hw_sectors_kb || max_sectors_kb < page_kb) return -EINVAL; It should not set to 0 via /sys/.../max_sectors_kb. However the default of bdi->io_pages is 0. So it happened if a driver didn't initialized it. > But I'm not sure it makes any sense to respect that. Looking at > mm/readahead.c, all it does is limit the size of a read request which > exceeds the current readahead window. It's not used to limit the > readahead window itself. For example: > > unsigned long max_pages = ra->ra_pages; > ... > if (req_size > max_pages && bdi->io_pages > max_pages) > max_pages = min(req_size, bdi->io_pages); > > Setting io_pages below ra_pages has no effect. So maybe fat should also > disregard it? |---| requested blocks [before] ra_pages |===|===|===| io_pages |-|-|-| req |-|-|---|---| [after] ra_pages |=|=|=| io_pages |-|-|-| req |-|-|---| This path is known the large sequential read there. Well, anyway, this intent is to use [after] as 3 req, instead of [before] as 4 req. Thanks. -- OGAWA Hirofumi
Re: sysfs output without newlines
On Sat, Aug 29, 2020 at 11:23:43AM -0700, Joe Perches wrote: > While doing an investigation for a possible treewide conversion of > sysfs output using sprintf/snprintf/scnprintf, I discovered > several instances of sysfs output without terminating newlines. > > It seems likely all of these should have newline terminations > or have the \n\r termination changed to a single newline. > > Anyone have any objection to patches adding newlines to these > in their original forms using sprintf/snprintf/scnprintf? No objection for me, patches for my subsystems will be gladly taken. thanks, greg k-h
Re: [PATCH RFC 2/2] sysfs: add helper macro for showing simple integer values
On Sun, Aug 30, 2020 at 12:37:17AM +0100, Alex Dewar wrote:
> sysfs attributes are supposed to be only single values, which are
> printed into a buffer of PAGE_SIZE. Accordingly, for many simple
> attributes, sprintf() can be used like so:
> static ssize_t my_show(..., char *buf)
> {
> ...
> return sprintf("%d\n", my_integer);
> }
>
> The problem is that whilst this use of sprintf() is memory safe, other
> cases where e.g. a possibly unterminated string is passed as input, are
> not and so use of sprintf() here might make it more difficult to
> identify these problematic cases.
>
> Define a macro, sysfs_sprinti(), which outputs the value of a single
> integer to a buffer (with terminating "\n\0") and returns the size written.
> This way, we can convert over the some of the trivially correct users of
> sprintf() and decrease its usage in the kernel source tree.
>
> Another advantage of this approach is that we can now statically check
> the type of the integer so that e.g. an unsigned long long will be
> formatted as %llu. This will fix cases where the wrong format string has
> been passed to sprintf().
>
> Signed-off-by: Alex Dewar
> ---
> include/linux/sysfs.h | 31 +++
> 1 file changed, 31 insertions(+)
Did you try this out? Don't you need to return the number of bytes
written?
I like Joe's patches better, this feels like more work...
thanks,
greg k-h
Re: [Linux-kernel-mentees] [PATCH] net: bluetooth: Fix null pointer deref in hci_phy_link_complete_evt
On Sat, Aug 29, 2020 at 10:27:12PM +0530, Anmol Karn wrote: > Fix null pointer deref in hci_phy_link_complete_evt, there was no > checking there for the hcon->amp_mgr->l2cap_conn->hconn, and also > in hci_cmd_work, for hdev->sent_cmd. > > To fix this issue Add pointer checking in hci_cmd_work and > hci_phy_link_complete_evt. > [Linux-next-20200827] > > This patch corrected some mistakes from previous patch. So this is a v2? That should go below the --- line, right? And you should have a v2 in the subject line like the documentation asks? Can you redo this please? thanks, greg k-h
Re: [Linux-kernel-mentees] [PATCH] net: bluetooth: Fix null pointer deref in hci_phy_link_complete_evt
On Sat, Aug 29, 2020 at 10:27:12PM +0530, Anmol Karn wrote:
> Fix null pointer deref in hci_phy_link_complete_evt, there was no
> checking there for the hcon->amp_mgr->l2cap_conn->hconn, and also
> in hci_cmd_work, for hdev->sent_cmd.
>
> To fix this issue Add pointer checking in hci_cmd_work and
> hci_phy_link_complete_evt.
> [Linux-next-20200827]
>
> This patch corrected some mistakes from previous patch.
>
> Reported-by: syzbot+0bef568258653cff2...@syzkaller.appspotmail.com
> Link:
> https://syzkaller.appspot.com/bug?id=0d93140da5a82305a66a136af99b088b75177b99
> Signed-off-by: Anmol Karn
> ---
> net/bluetooth/hci_core.c | 5 -
> net/bluetooth/hci_event.c | 4
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 68bfe57b6625..996efd654e7a 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -4922,7 +4922,10 @@ static void hci_cmd_work(struct work_struct *work)
>
> kfree_skb(hdev->sent_cmd);
>
> - hdev->sent_cmd = skb_clone(skb, GFP_KERNEL);
> + if (hdev->sent_cmd) {
> + hdev->sent_cmd = skb_clone(skb, GFP_KERNEL);
> + }
How can sent_cmd be NULL here? Are you sure something previous to this
shouldn't be fixed instead?
> +
> if (hdev->sent_cmd) {
> if (hci_req_status_pend(hdev))
> hci_dev_set_flag(hdev, HCI_CMD_PENDING);
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 4b7fc430793c..1e7d9bee9111 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -4941,6 +4941,10 @@ static void hci_phy_link_complete_evt(struct hci_dev
> *hdev,
> hci_dev_unlock(hdev);
> return;
> }
> + if (!(hcon->amp_mgr->l2cap_conn->hcon)) {
> + hci_dev_unlock(hdev);
> + return;
> + }
How can this be triggered?
thanks,
greg k-h
Re: [PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs
Hi! > > > The phydev name is not particularly nice: > > > > > > !mdio-mux!mdio@1!switch@0!mdio:00 ... > > > 400d.ethernet-1:00 > > > 400d.ethernet-1:01 > > > fixed-0:00 > > > > Not nice, I see. In particular, it contains ":"... which would be a > > problem. > > > > > The interface name are: > > > > > > 1: lo: > > > 2: eth0: > > > 3: eth1: ... > > > 13: optical3@eth1: > > > 14: optical4@eth1: > > > > OTOH... renaming LEDs when interface is renamed... sounds like a > > disaster, too. > > I don't think it is. The stack has all the needed support. There is a > notification before the rename, and another notification after the > rename. Things like bonding, combing two interfaces into one and load > balancing, etc. hook these notifiers. There is plenty of examples to > follow. What i don't know about is the lifetime of files under > /sys/class/led, does the destroying of an LED block while one of the > files is open?. Well, there may be no problems on the networking side, but I'd prefer not to make LED side more complex. Files could be open, and userland could have assumptions about LEDs not changing names... > > > You could make a good guess at matching to two together, but it is > > > error prone. Phys are low level things which the user is not really > > > involved in. They interact with interface names. ethtool, ip, etc, all > > > use interface names. In fact, i don't know of any tool which uses > > > phydev names. > > > > So... proposal: > > > > Users should not be dealing with sysfs interface directly, anyway. We > > should have a tool for that. It can live in kernel/tools somewhere, I > > guess. > > We already have one, ethtool(1). Well... ethtool is for networking, we'll want to have a ledtool, too :-). > > Would we name leds phy0:... (with simple incrementing number), and > > expose either interface name or phydev name as a attribute? > > > > So user could do > > > > cat /sys/class/leds/phy14:green:foobar/netdev > > lan5@eth1: > > Which is the wrong way around. ethtool will be passed the interface > name and an PHY descriptor of some sort, and it has to go search > through all the LEDs to find the one with this attribute. I would be > much more likely to add a sysfs link from > /sys/class/net/lan5/phy:left:green to > /sys/class/leds/phy14:left:green. Okay, that might be even better, as it provides links in the more useful direction. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: [PATCH] iio: adc: rockchip_saradc: Select IIO_TRIGGERED_BUFFER
Hi Jonathan,
On 8/29/20 3:57 PM, Jonathan Cameron wrote:
> On Fri, 28 Aug 2020 18:42:42 +0100
> Alexandru Elisei wrote:
>
>> Building the Rockchip saradc driver can trigger the following error if the
>> driver is compiled into the kernel, but the IIO triggered buffer is not:
>>
>> aarch64-linux-gnu-ld: drivers/iio/adc/rockchip_saradc.o: in function
>> `rockchip_saradc_probe':
>> /path/to/linux/drivers/iio/adc/rockchip_saradc.c:427: undefined reference to
>> `devm_iio_triggered_buffer_setup'
>>
>> This is because commit 4e130dc7b413 ("iio: adc: rockchip_saradc: Add
>> support iio buffers") added support for industrial I/O triggered buffers,
>> but didn't update Kconfig to build the required file. Fix that.
>>
>> Fixes: 4e130dc7b413 ("iio: adc: rockchip_saradc: Add support iio buffers")
>> Signed-off-by: Alexandru Elisei
> Sorry, I've had a patch queued to fix this for a while, but had a
> vacation just after merge window occurred that delayed me sending it out.
>
> Will send a pull sometime this weekend.
>
> Jonathan
That's great, thank you!
Thanks,
Alex
Re: Boot failure on gru-scarlet-inx with 5.9-rc2
Hi Samuel, On 2020-08-29 21:54, Samuel Dionne-Riel wrote: Hi, The patch "of: address: Work around missing device_type property in pcie nodes" by Marc Zyngier, d1ac0002dd297069bb8448c2764c9c31c4668441, causes the "DUMO" variant of the gru-scarlet-inx, at the very least, to not boot. A gru-kevin reportedly had no issues booting (further), though it most likely had a different kernel configuration. Do you have a pointer to the device-tree for this system? I couldn't spot anything amiss in the scarlet-inx DT, but I'm not sure the system you have is that exact one. Even a DTB would help. The fact that Kevin still boots is a good indication that the issue could be with with the board-specific changes layered on top of the GRU base. My own rk3399 systems are running with this patch. Using a SuzyQ cable, there is absolutely no serial output at boot, while reverting the commit (and this commit alone) on top of v5.9-rc2 works just as it did with v5.9-rc1. Do you have "earlycon" on the kernel command-line? From this point on, I don't know what's the usual process, so bear with me if I forgot to provide relevant information, or made a faux-pas by CC-ing too many people or not enough. No need to worry, and thank you for reporting the issue. Could you try replacing the problematic patch with [1], and let me know whether this changes anything on your end? This patch probably isn't the right approach, but it would certainly help pointing me in the right direction. Thanks, M. [1] https://lore.kernel.org/lkml/20200815125112.462652-2-...@kernel.org/ -- Jazz is not dead. It just smells funny...
[PATCH v2] netup_unidvb: drop initialization of PM pointers
The .suspend() and .resume() callbacks are not defined for this driver.
Thus, just the unlisting of PM pointers in the struct initializer will make
no change in its behavior. Still unlisting is necessary so as to get rid of
.suspend and .resume pointers as they are part of the legacy framework and
should not be used in the driver code explicitly.
Signed-off-by: Vaibhav Gupta
---
drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
index 80a7c41baa90..6f3125c2d097 100644
--- a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
+++ b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
@@ -1016,8 +1016,6 @@ static struct pci_driver netup_unidvb_pci_driver = {
.id_table = netup_unidvb_pci_tbl,
.probe= netup_unidvb_initdev,
.remove = netup_unidvb_finidev,
- .suspend = NULL,
- .resume = NULL,
};
module_pci_driver(netup_unidvb_pci_driver);
--
2.28.0
Re: [PATCH v2] KVM: nVMX: fix the layout of struct kvm_vmx_nested_state_hdr
On 27/08/20 22:40, Sean Christopherson wrote:
> Paolo pushed an alternative solution for 5.8, commit 5e105c88ab485 ("KVM:
> nVMX: check for invalid hdr.vmx.flags"). His argument was that there was
> no point in adding proper padding since we already broke the ABI, i.e.
> damage done.
>
> So rather than pad the struct, which doesn't magically fix the ABI for old
> userspace, just check for unsupported flags. That gives decent odds of
> failing the ioctl() for old userspace if it's passing garbage (through no
> fault of its own), prevents new userspace from setting unsupported flags,
> and allows KVM to grow the struct by conditioning consumption of new fields
> on an associated flag.
In general userspace (as a hygiene/future-proofing measure) should
generally zero the contents of structs before filling in some fields
only. There was no guarantee that smm wouldn't grow new fields that
would have occupied the padding, for example. The general solution we
use is flags fields and checking them.
(The original KVM_GET/SET_NESTED_STATE patches did add a generic flags
fields, but not a VMX-specific one).
Paolo
Re: [PATCH v2] KVM: nVMX: fix the layout of struct kvm_vmx_nested_state_hdr
On 27/08/20 22:40, Sean Christopherson wrote:
> Paolo pushed an alternative solution for 5.8, commit 5e105c88ab485 ("KVM:
> nVMX: check for invalid hdr.vmx.flags"). His argument was that there was
> no point in adding proper padding since we already broke the ABI, i.e.
> damage done.
>
> So rather than pad the struct, which doesn't magically fix the ABI for old
> userspace, just check for unsupported flags. That gives decent odds of
> failing the ioctl() for old userspace if it's passing garbage (through no
> fault of its own), prevents new userspace from setting unsupported flags,
> and allows KVM to grow the struct by conditioning consumption of new fields
> on an associated flag.
In general userspace (as a hygiene/future-proofing measure) should
generally zero the contents of structs before filling in some fields
only. There was no guarantee that smm wouldn't grow new fields that
would have occupied the padding, for example. The general solution we
use is flags fields and checking them.
(The original KVM_GET/SET_NESTED_STATE patches did add a generic flags
fields, but not a VMX-specific one field).
Paolo
[PATCH] ALSA: rockchip: fix a possible divide-by-zero bug in rockchip_i2s_hw_params()
The variable bclk_rate is checked in:
if (bclk_rate && mclk_rate % bclk_rate)
This indicates that bclk_rate can be zero.
If so, a divide-by-zero bug will occur:
div_bclk = mclk_rate / bclk_rate;
To fix this possible bug, the function returns -EINVAL when bclk_rate is
zero.
Signed-off-by: Tuo Li
---
sound/soc/rockchip/rockchip_i2s.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/rockchip_i2s.c
b/sound/soc/rockchip/rockchip_i2s.c
index d1438753edb4..dd0836c32639 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -279,7 +279,9 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream
*substream,
if (i2s->is_master_mode) {
mclk_rate = clk_get_rate(i2s->mclk);
bclk_rate = 2 * 32 * params_rate(params);
- if (bclk_rate && mclk_rate % bclk_rate)
+ if (bclk_rate == 0)
+ return -EINVAL;
+ if (mclk_rate % bclk_rate)
return -EINVAL;
div_bclk = mclk_rate / bclk_rate;
--
2.17.1
Re: [ALTERNATE PATCH] memblock: fix min_low_pfn/max_low_pfn build errors
Hi Randy, On Sat, Aug 29, 2020 at 08:40:51AM -0700, Randy Dunlap wrote: > On 8/29/20 6:04 AM, Mike Rapoport wrote: > > On Fri, Aug 28, 2020 at 05:01:39PM -0700, Randy Dunlap wrote: > >> Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors > >> on arch/microblaze/ and arch/ia64/: (e.g.) > > > > Please don't. This would give driver developers a wrong impression that > > these variables can be used to query memory boundaries, but this is not > > the case, at least not on all architectures. > > > > I would prefer fixing it up locally for microblaze and ia64. > > I did that. > and that's why this is labeled as an ALTERNATE PATCH. I've seen that, I just wanted to make sure that Andrew wouldn't pick this one :) I can help with taking microblaze and ia64 patches via memblock tree once we have Acks from the arch maintainers. > thanks. > -- > ~Randy > -- Sincerely yours, Mike.
Re: [PATCH v2 2/2] mm/pageblock: remove false sharing in pageblock_flags
在 2020/8/20 上午12:50, Alexander Duyck 写道: > On Wed, Aug 19, 2020 at 1:11 AM Alex Shi wrote: >> >> >> >> 在 2020/8/19 下午3:57, Anshuman Khandual 写道: >>> >>> >>> On 08/19/2020 11:17 AM, Alex Shi wrote: Current pageblock_flags is only 4 bits, so it has to share a char size in cmpxchg when get set, the false sharing cause perf drop. If we incrase the bits up to 8, false sharing would gone in cmpxchg. and the only cost is half char per pageblock, which is half char per 128MB on x86, 4 chars in 1 GB. >>> >>> Agreed that increase in memory utilization is negligible here but does >>> this really improve performance ? >>> >> >> It's no doubt in theory. and it would had a bad impact according to >> commit e380bebe4771548 mm, compaction: keep migration source private to a >> single >> >> but I do have some problem in running thpscale/mmtest. I'd like to see if >> anyone >> could give a try. >> >> BTW, I naturally hate the false sharing even it's in theory. Anyone who >> doesn't? :) > > You keep bringing up false sharing but you don't fix the false sharing > by doing this. You are still allowing the flags for multiple > pageblocks per cacheline so you still have false sharing even after > this. yes, the cacheline false sharing is still there. But as you pointed, cmpxchg level false sharing could be addressed much by the patchset. > > What I believe you are attempting to address is the fact that multiple > pageblocks share a single long value and that long is being used with > a cmpxchg so you end up with multiple threads potentially all banging > on the same value and watching it change. However the field currently > consists of only 4 bits, 3 of them for migratetype and 1 for the skip > bit. In the case of the 3 bit portion a cmpxchg makes sense and is > usually protected by the zone lock so you would only have one thread > accessing it in most cases with the possible exception of a section > that spans multiple zones. > > For the case such as the skip bit and MIGRATE_UNMOVABLE (0x0) where we > would be clearing or setting the entire mask maybe it would make more > sense to simply use an atomic_or or atomic_and depending on if you are > setting or clearing the flag? It would allow you to avoid the spinning > or having to read the word before performing the operation since you > would just be directly applying an AND or OR via a mask value. Right that the different level to fix this problem, but narrow the cmpxchg comparsion is still needed and helpful. Thanks Alex >
Re: [PATCH 05/11] kconfig: qconf: show data column all the time
On Sun, Aug 30, 2020 at 1:54 PM Randy Dunlap wrote: > > On 8/29/20 1:14 AM, Masahiro Yamada wrote: > > The next commit will allow users to edit "int", "hex", "string" > > menus in-place from the data column. > > > > The data column should be always displayed. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > scripts/kconfig/qconf.cc | 29 + > > scripts/kconfig/qconf.h | 5 + > > 2 files changed, 2 insertions(+), 32 deletions(-) > > > > I am trying to edit LOG_BUF_SHIFT, which has a value of 17 > (this is x86_64). My goal is to use Qt gadgets with least modification and align with the standard behavior as much as possible. > I want to change the 7 to 9, making it 19, so I double-click on the "17" > (single-click won't give me an edit cursor). Yes. You need to double-click the cell to open up the editor. Single-click is not enough. It is the same for a simple example program using QTreeWidgetItem. So, it is the standard behavior of the Qt library. > The edit cursor is > immediately after the "17", so it's like > 17| > with the | cursor blinking. Same for me. And the "17" is highlighted. > What I expect to be able to do is > Backspace, enter 9, press Enter, and the new value is 19. > But Backspace does nothing. That is different from what I see on my machine (matacity of Ubuntu). After I double-clicked the cell, the entire "17" is high-lighted. Backspace deleted "17" entirely for me. The same behavior for a simple example, and it makes sense since Backspace should delete the selected characters. If Backspace does not work at all for you, was it perhaps captured somewhere else on your machine? > I just have to enter the complete new > value: 19. So IMO it does not act like an edit box so much as a > replacement box. I am re-implementing a new way to edit values. It does not need to act as before. > Also, the new value that I enter is displayed/written over the old value, > so I see 17 in white-on-blue and over that I see 19 in black until I > press Enter, then I see only 19 in white-on-blue. I do not see such a weirdness either on my machine. I see only the new value I am entering. I have no idea what makes it work differently for you. > > BTW, if I edit DEFAULT_HOSTNAME, which begins as "(none)" and I change it > to "xyz" and then change it to , it becomes > CONFIG_DEFAULT_HOSTNAME="" > Should I have to enter "(none)" to get it back to (none)? I guess so. It is a text string, "(none)", which is not an empty string. See init/Kconfig. config DEFAULT_HOSTNAME string "Default hostname" default "(none)" -- Best Regards Masahiro Yamada
[GIT PULL] USB fixes for 5.9-rc3 - take 2
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.9-rc3 for you to fetch changes up to 20934c0de13b49a072fb1e0ca79fe0fe0e40eae5: usb: storage: Add unusual_uas entry for Sony PSZ drives (2020-08-28 09:23:16 +0200) USB fixes for 5.9-rc3 - take 2 Let's try this again... Here are some USB fixes for 5.9-rc3. This differs from the previous pull request for this release in that: - the usb gadget patch now does not break some systems, and actually does what it was intended to do. Many thanks to Marek Szyprowski for quickly noticing and testing the patch from Andy Shevchenko to resolve this issue. - some more new USB quirks have been added to get some new devices to work properly based on user reports. Other than that, the original pull request patches are all here, and they contain: - usb gadget driver fixes - xhci driver fixes - typec fixes - new quirks and ids - fixes for USB patches that went into 5.9-rc1. All of these have been tested in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Alan Stern (3): USB: yurex: Fix bad gfp argument USB: quirks: Ignore duplicate endpoint on Sound Devices MixPre-D usb: storage: Add unusual_uas entry for Sony PSZ drives Andy Shevchenko (2): usb: hcd: Fix use after free in usb_hcd_pci_remove() USB: gadget: u_f: Unbreak offset calculation in VLAs Badhri Jagan Sridharan (1): usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA 2.3.1.2 failures Bastien Nocera (2): USB: Also match device drivers using the ->match vfunc USB: Fix device driver race Brooke Basile (2): USB: gadget: u_f: add overflow checks to VLA macros USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb() Christophe JAILLET (1): usb: gadget: f_tcm: Fix some resource leaks in some error paths Cyril Roelandt (1): USB: Ignore UAS for JMicron JMS567 ATA/ATAPI Bridge Ding Hui (1): xhci: Always restore EP_SOFT_CLEAR_TOGGLE even if ep reset failed Evgeny Novikov (1): USB: lvtest: return proper error code in probe Greg Kroah-Hartman (1): Merge tag 'fixes-for-v5.9-rc2' of git://git.kernel.org/.../balbi/usb into usb-linus Hans de Goede (4): usb: typec: ucsi: Fix AB BA lock inversion usb: typec: ucsi: Fix 2 unlocked ucsi_run_command calls usb: typec: ucsi: Rework ppm_lock handling usb: typec: ucsi: Hold con->lock for the entire duration of ucsi_register_port() Heikki Krogerus (1): tools: usb: move to tools buildsystem JC Kuo (2): usb: host: xhci-tegra: otg usb2/usb3 port init usb: host: xhci-tegra: fix tegra_xusb_get_phy() Kai-Heng Feng (2): USB: quirks: Add no-lpm quirk for another Raydium touchscreen xhci: Do warm-reset when both CAS and XDEV_RESUME are set Li Jun (1): usb: host: xhci: fix ep context print mismatch in debugfs M. Vefa Bicakci (1): usbip: Implement a match function to fix usbip Tang Bin (1): usb: host: ohci-exynos: Fix error handling in exynos_ohci_probe() Thinh Nguyen (4): usb: dwc3: gadget: Don't setup more than requested usb: dwc3: gadget: Fix handling ZLP usb: dwc3: gadget: Handle ZLP for sg requests usb: uas: Add quirk for PNY Pro Elite Tom Rix (1): USB: cdc-acm: rework notification_buffer resizing Vinod Koul (1): usb: renesas-xhci: remove version check 周琰杰 (Zhou Yanjie) (1): USB: PHY: JZ4770: Fix static checker warning. drivers/usb/class/cdc-acm.c | 22 --- drivers/usb/core/driver.c| 40 - drivers/usb/core/generic.c | 5 +- drivers/usb/core/hcd-pci.c | 5 +- drivers/usb/core/quirks.c| 7 +++ drivers/usb/dwc3/gadget.c| 107 +-- drivers/usb/gadget/function/f_ncm.c | 81 ++ drivers/usb/gadget/function/f_tcm.c | 7 ++- drivers/usb/gadget/u_f.h | 38 + drivers/usb/host/ohci-exynos.c | 5 +- drivers/usb/host/xhci-debugfs.c | 8 +-- drivers/usb/host/xhci-hub.c | 19 --- drivers/usb/host/xhci-pci-renesas.c | 19 +-- drivers/usb/host/xhci-tegra.c| 4 +- drivers/usb/host/xhci.c | 3 +- drivers/usb/misc/lvstest.c | 2 +- drivers/usb/misc/yurex.c | 2 +- drivers/usb/phy/phy-jz4770.c | 1 + drivers/usb/storage/unusual_devs.h | 2 +- drivers/usb/storage/unusual_uas.h| 14 + drivers/usb/typec/tcpm/tcpm.c| 28 - drivers/usb/typec/ucsi
Re: [PATCH 06/11] kconfig: qconf: allow to edit "int", "hex", "string" menus in-place
On Sun, Aug 30, 2020 at 1:54 PM Randy Dunlap wrote: > > On 8/29/20 1:14 AM, Masahiro Yamada wrote: > > Previously, when you double-clicked the "int", "hex", or "string" menus, > > a line-edit gadget showed up to allow you to input the value, which > > looked clumsy. > > > > Also, it was buggy; the editor opened even if the config option was not > > editable. For example, just try to double-click CC_VERSION_TEXT, which > > has no prompt. > > > > This commit sub-classes QStyleItemDelegate to allow users to edit > > "int", "hex", "string" menus in-place. Just double-click (or press > > the F2 key) in the data column. Then, an editor widget is placed on > > top of the item view. > > The F2 key doesn't work for me. I guess that's a desktop environment > issue (I am using Xfce). F2 works for me. I am using metacity on Ubuntu. > > The two methods are overridden: > > > > createEditor - process only when the data column is being accessed > > and the menu is visible. Otherwise, return nullptr to disallow editing. > > > > setModelData - take the new data from the editor, and set it to the > > addressed symbol. If it was successful, update all the list windows. > > Otherwise, (the reason for the failure is possibly the input data was > > out of range), set the old value back to the editor. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > scripts/kconfig/qconf.cc | 93 > > scripts/kconfig/qconf.h | 15 +++ > > 2 files changed, 91 insertions(+), 17 deletions(-) > > > > > -- > ~Randy > -- Best Regards Masahiro Yamada
Re: [PATCH] clk: versatile: Add of_node_put() before return statement
On Sat, Aug 29, 2020 at 7:57 PM Sumera Priyadarsini wrote: > Every iteration of for_each_available_child_of_node() decrements > the reference count of the previous node, however when control is > transferred from the middle of the loop, as in the case of a return > or break or goto, there is no decrement thus ultimately resulting in > a memory leak. > > Fix a potential memory leak in clk-impd1.c by inserting > of_node_put() before a return statement. > > Issue found with Coccinelle. > > Signed-off-by: Sumera Priyadarsini Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v2 1/2] mm/pageblock: mitigation cmpxchg false sharing in pageblock flags
在 2020/8/19 下午4:04, David Hildenbrand 写道: > On 19.08.20 09:55, Anshuman Khandual wrote: >> >> >> On 08/19/2020 11:17 AM, Alex Shi wrote: >>> pageblock_flags is used as long, since every pageblock_flags is just 4 >>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags, >>> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock >>> flags. It would cause long waiting for sync. >>> >>> If we could change the pageblock_flags variable as char, we could use >>> char size cmpxchg, which just sync up with 2 pageblock flags. it could >>> relief much false sharing in cmpxchg. >> >> Do you have numbers demonstrating claimed performance improvement >> after this change ? >> > > I asked for that in v1 and there are no performance numbers to justify > the change. IMHO, that will be required to consider this for inclusion, > otherwise it's just code churn resulting in an (although minimal) > additional memory consumption. > Just got some time to run thpscale on my 4*HT cores machine, here is the data: I run each of kernel for 3 times, pageblock kernel is the 5.9-rc2 with this 2 patches, the plp1 is the first patch on 5.9-rc2, and rc2 is 5.9-rc2 kernel. We could found the system and total time is slight less than original kernel. pageblock pageblock pageblockplp1plp1 plp1 rc2 rc2 rc2 pageblock 1616-216-3 1 2 3 a b c a Duration User 14.81 15.24 14.55 15.28 14.66 14.63 14.76 14.97 14.38 15.07 Duration System84.44 88.38 90.64 92.65 94.01 90.58 100.43 89.15 88.89 84.04 Duration Elapsed 98.83 99.06 99.81 99.65 100.26 99.90 100.30 99.24 99.14 98.87 And I also add tracing for patchset effect, which show the cmpxchg failure times get clearly less. Performance counter stats for './run-mmtests.sh -c configs/config-workload-thpscale rc2-b': 6,720 compaction:mm_compaction_isolate_migratepages 13,526 compaction:mm_compaction_isolate_freepages 4,052 compaction:mm_compaction_migratepages 34,199 compaction:mm_compaction_begin 34,199 compaction:mm_compaction_end 21,784 compaction:mm_compaction_try_to_compact_pages 71,606 compaction:mm_compaction_finished 106,545 compaction:mm_compaction_suitable 0 compaction:mm_compaction_deferred 0 compaction:mm_compaction_defer_compaction 2,977 compaction:mm_compaction_defer_reset 0 compaction:mm_compaction_kcompactd_sleep 0 compaction:mm_compaction_wakeup_kcompactd 0 compaction:mm_compaction_kcompactd_wake 1,046 pageblock:hit_cmpxchg 114.914303988 seconds time elapsed 15.754797000 seconds user 89.712251000 seconds sys Performance counter stats for './run-mmtests.sh -c configs/config-workload-thpscale pageblock-a': 602 compaction:mm_compaction_isolate_migratepages 3,710 compaction:mm_compaction_isolate_freepages 402 compaction:mm_compaction_migratepages 43,116 compaction:mm_compaction_begin 43,116 compaction:mm_compaction_end 24,810 compaction:mm_compaction_try_to_compact_pages 86,527 compaction:mm_compaction_finished 125,819 compaction:mm_compaction_suitable 2 compaction:mm_compaction_deferred 0 compaction:mm_compaction_defer_compaction 271 compaction:mm_compaction_defer_reset 0 compaction:mm_compaction_kcompactd_sleep 0 compaction:mm_compaction_wakeup_kcompactd 0 compaction:mm_compaction_kcompactd_wake 369 pageblock:hit_cmpxchg 107.405499745 seconds time elapsed 15.830967000 seconds user 84.559767000 seconds sys commit 36cea76895637c0c18ce8590c0f43a3e453fbf8f Author: Alex Shi Date: Wed Aug 19 17:26:26 2020 +0800 add cmpxchg tracing Signed-off-by: Alex Shi diff --git a/include/trace/events/pageblock.h b/include/trace/events/pageblock.h new file mode 100644 index ..003c2d716f82 --- /dev/null +++ b/include/trace/events/pageblock.h @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM pageblock + +#if !defined(_TRACE_PAGEBLOCK_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_PAGEBLOCK_H + +#include + +TRACE_EVENT(hit_cmpxchg, + + TP_PROTO(char byte), + + TP_ARGS(byte), + + TP_STRUCT__ent
[PATCH rdma-next v1 00/13] Track memory allocation with restrack DB help
From: Leon Romanovsky Changelog: v1: * Fixed rebase error, deleted second assignment of qp_type. * Rebased code on latests rdma-next, the changes in cma.c caused to change in patch "RDMA/cma: Delete from restrack DB after successful destroy". * Dropped patch of port assignment, it is already done as part of this series. * I didn't add @calller description, regular users should not use _named() funciton. v0: https://lore.kernel.org/lkml/20200824104415.1090901-1-l...@kernel.org -- Hi, The resource tracker has built-in kref counter to synchronize object release. It makes restrack perfect choice to be responsible for the memory lifetime of any object in which restrack entry is embedded. In order to make it, the restrack was changed to be mandatory and all callers of rdma_restrack_add() started to rely on result returned from that call. Being mandatory means that all objects specific to restrack type must be tracked. Before this series, the restrack and rdmatool were aid tools in debug session of user space applications, this caused to some of the functionality to be left behind, like support XRC QPs, device memory MRs and QP0/QP1 in multi-port devices. This series fixes all mentioned above without extending rdmatool at all. Thanks Leon Romanovsky (13): RDMA/cma: Delete from restrack DB after successful destroy RDMA/mlx5: Don't call to restrack recursively RDMA/restrack: Count references to the verbs objects RDMA/restrack: Simplify restrack tracking in kernel flows RDMA/restrack: Improve readability in task name management RDMA/cma: Be strict with attaching to CMA device RDMA/core: Allow drivers to disable restrack DB RDMA/counter: Combine allocation and bind logic RDMA/restrack: Store all special QPs in restrack DB RDMA/restrack: Make restrack DB mandatory for IB objects RDMA/restrack: Support all QP types RDMA/core: Track device memory MRs RDMA/restrack: Drop valid restrack field as source of ambiguity drivers/infiniband/core/cma.c | 225 +++--- drivers/infiniband/core/core_priv.h | 39 ++- drivers/infiniband/core/counters.c| 178 +++--- drivers/infiniband/core/cq.c | 24 +- drivers/infiniband/core/rdma_core.c | 3 +- drivers/infiniband/core/restrack.c| 208 drivers/infiniband/core/restrack.h| 10 +- drivers/infiniband/core/uverbs_cmd.c | 50 +++- drivers/infiniband/core/uverbs_std_types_cq.c | 12 +- drivers/infiniband/core/uverbs_std_types_mr.c | 10 + drivers/infiniband/core/uverbs_std_types_qp.c | 4 +- drivers/infiniband/core/verbs.c | 91 +-- drivers/infiniband/hw/mlx5/gsi.c | 16 +- drivers/infiniband/hw/mlx5/qp.c | 2 +- include/rdma/ib_verbs.h | 10 +- include/rdma/restrack.h | 46 ++-- 16 files changed, 537 insertions(+), 391 deletions(-) -- 2.26.2
Re: [PATCH v2 1/2] mm/pageblock: mitigation cmpxchg false sharing in pageblock flags
在 2020/8/19 下午3:55, Anshuman Khandual 写道:
>
>
> On 08/19/2020 11:17 AM, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
>> flags. It would cause long waiting for sync.
>>
>> If we could change the pageblock_flags variable as char, we could use
>> char size cmpxchg, which just sync up with 2 pageblock flags. it could
>> relief much false sharing in cmpxchg.
>
> Do you have numbers demonstrating claimed performance improvement
> after this change ?
>
the performance data show in another email.
LKP reported the arm6 has a bug on this patchset, since it has no cmpxchgb
solution, so maybe let's fallback to cmpxchg on it.
>From db3d97ba8cc5e206b440bd40a92ef6955ad86bc0 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Tue, 18 Aug 2020 15:51:18 +0800
Subject: [PATCH v2 3/3] armv6: fix armv6 build issue
Arm v6 can not simulate cmpxchg1 func, so we have to use cmpxchg4 on it.
arm-linux-gnueabi-ld: mm/page_alloc.o: in function `set_pfnblock_flags_mask':
(.text+0x32b4): undefined reference to `__bad_cmpxchg'
arm-linux-gnueabi-ld: (.text+0x32e0): undefined reference to `__bad_cmpxchg'
arm-linux-gnueabi-ld:
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.o: in function
`hw_atl_b0_get_mac_temp':
hw_atl_b0.c:(.text+0x30fc): undefined reference to `__bad_udelay'
Reported-by: kernel test robot
Signed-off-by: Alex Shi
Cc: Andrew Morton
Cc: Baolin Wang
Cc: Russell King
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
mm/page_alloc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7da09d66233b..c09146a8946c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -517,7 +517,11 @@ void set_pfnblock_flags_mask(struct page *page, unsigned
long flags,
{
unsigned char *bitmap;
unsigned long bitidx, byte_bitidx;
+#ifdef CONFIG_CPU_V6
+ unsigned long old_byte, byte;
+#else
unsigned char old_byte, byte;
+#endif
BUILD_BUG_ON(NR_PAGEBLOCK_BITS != BITS_PER_BYTE);
BUILD_BUG_ON(MIGRATE_TYPES > (1 << PB_migratetype_bits));
@@ -532,9 +536,18 @@ void set_pfnblock_flags_mask(struct page *page, unsigned
long flags,
mask <<= bitidx;
flags <<= bitidx;
+#ifdef CONFIG_CPU_V6
+ byte = (unsigned long)READ_ONCE(bitmap[byte_bitidx]);
+#else
byte = READ_ONCE(bitmap[byte_bitidx]);
+#endif
for (;;) {
+#ifdef CONFIG_CPU_V6
+ /* arm v6 has no cmpxchgb function, so still false sharing long
word */
+ old_byte = cmpxchg((unsigned long*)&bitmap[byte_bitidx], byte,
(byte & ~mask) | flags);
+#else
old_byte = cmpxchg(&bitmap[byte_bitidx], byte, (byte & ~mask) |
flags);
+#endif
if (byte == old_byte)
break;
byte = old_byte;
--
1.8.3.1
Re: [PATCH v2 00/23] Use asm-generic for mmu_context no-op functions
On Thu, Aug 27, 2020 at 12:52:26AM +1000, Nicholas Piggin wrote: > It would be nice to be able to modify mmu_context functions or add a > hook without updating all architectures, many of which will be no-ops. > > The motivation for this series is a change to lazy mmu handling, but > this series stands on its own as a good cleanup whether or not we end > up making that change. I really like this series, I just have some small comments in reply to patch 1, otherwise feel free to add Acked-by: Mike Rapoport > Arnd, is this something you could take through your asm-generic tree? > (assuming arch maintainers are okay with it) > > Thanks, > Nick > > Since v1: > - Added acks and feedback from various people. > - Fixed a nommu build error caught by ktp. > - Dropped unicore32. > > Nicholas Piggin (23): > asm-generic: add generic MMU versions of mmu context functions > alpha: use asm-generic/mmu_context.h for no-op implementations > arc: use asm-generic/mmu_context.h for no-op implementations > arm: use asm-generic/mmu_context.h for no-op implementations > arm64: use asm-generic/mmu_context.h for no-op implementations > csky: use asm-generic/mmu_context.h for no-op implementations > hexagon: use asm-generic/mmu_context.h for no-op implementations > ia64: use asm-generic/mmu_context.h for no-op implementations > m68k: use asm-generic/mmu_context.h for no-op implementations > microblaze: use asm-generic/mmu_context.h for no-op implementations > mips: use asm-generic/mmu_context.h for no-op implementations > nds32: use asm-generic/mmu_context.h for no-op implementations > nios2: use asm-generic/mmu_context.h for no-op implementations > openrisc: use asm-generic/mmu_context.h for no-op implementations > parisc: use asm-generic/mmu_context.h for no-op implementations > powerpc: use asm-generic/mmu_context.h for no-op implementations > riscv: use asm-generic/mmu_context.h for no-op implementations > s390: use asm-generic/mmu_context.h for no-op implementations > sh: use asm-generic/mmu_context.h for no-op implementations > sparc: use asm-generic/mmu_context.h for no-op implementations > um: use asm-generic/mmu_context.h for no-op implementations > x86: use asm-generic/mmu_context.h for no-op implementations > xtensa: use asm-generic/mmu_context.h for no-op implementations > > arch/alpha/include/asm/mmu_context.h | 12 ++--- > arch/arc/include/asm/mmu_context.h | 17 +++--- > arch/arm/include/asm/mmu_context.h | 26 ++--- > arch/arm64/include/asm/mmu_context.h | 9 ++-- > arch/csky/include/asm/mmu_context.h | 8 ++- > arch/hexagon/include/asm/mmu_context.h | 33 ++-- > arch/ia64/include/asm/mmu_context.h | 17 ++ > arch/m68k/include/asm/mmu_context.h | 47 +++- > arch/microblaze/include/asm/mmu_context.h| 2 +- > arch/microblaze/include/asm/mmu_context_mm.h | 8 +-- > arch/microblaze/include/asm/processor.h | 3 -- > arch/mips/include/asm/mmu_context.h | 11 ++-- > arch/nds32/include/asm/mmu_context.h | 10 +--- > arch/nios2/include/asm/mmu_context.h | 21 ++-- > arch/openrisc/include/asm/mmu_context.h | 8 ++- > arch/parisc/include/asm/mmu_context.h| 12 ++--- > arch/powerpc/include/asm/mmu_context.h | 22 +++- > arch/riscv/include/asm/mmu_context.h | 22 +--- > arch/s390/include/asm/mmu_context.h | 9 ++-- > arch/sh/include/asm/mmu_context.h| 7 ++- > arch/sh/include/asm/mmu_context_32.h | 9 > arch/sparc/include/asm/mmu_context_32.h | 10 ++-- > arch/sparc/include/asm/mmu_context_64.h | 10 ++-- > arch/um/include/asm/mmu_context.h| 12 ++--- > arch/x86/include/asm/mmu_context.h | 6 +++ > arch/xtensa/include/asm/mmu_context.h| 11 ++-- > arch/xtensa/include/asm/nommu_context.h | 26 + > include/asm-generic/mmu_context.h| 57 +++- > include/asm-generic/nommu_context.h | 19 +++ > 29 files changed, 166 insertions(+), 298 deletions(-) > create mode 100644 include/asm-generic/nommu_context.h > > -- > 2.23.0 > > -- Sincerely yours, Mike.
Re: [PATCH v2 1/2] mm/pageblock: mitigation cmpxchg false sharing in pageblock flags
On Sun, Aug 30, 2020 at 06:14:33PM +0800, Alex Shi wrote:
> +++ b/mm/page_alloc.c
> @@ -532,9 +536,18 @@ void set_pfnblock_flags_mask(struct page *page, unsigned
> long flags,
> mask <<= bitidx;
> flags <<= bitidx;
>
> +#ifdef CONFIG_CPU_V6
> + byte = (unsigned long)READ_ONCE(bitmap[byte_bitidx]);
> +#else
> byte = READ_ONCE(bitmap[byte_bitidx]);
> +#endif
> for (;;) {
> +#ifdef CONFIG_CPU_V6
> + /* arm v6 has no cmpxchgb function, so still false sharing long
> word */
> + old_byte = cmpxchg((unsigned long*)&bitmap[byte_bitidx], byte,
> (byte & ~mask) | flags);
> +#else
> old_byte = cmpxchg(&bitmap[byte_bitidx], byte, (byte & ~mask) |
> flags);
> +#endif
Good grief, no. Either come up with an appropriate abstraction or
abandon this patch. We can't possibly put this kind of ifdef in the
memory allocator!
Re: [PATCH] USB: PHY: JZ4770: Use the generic PHY framework.
Hi "周琰杰,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20200828]
[cannot apply to balbi-usb/testing/next linus/master phy/next v5.9-rc2 v5.9-rc1
v5.8 v5.9-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Zhou-Yanjie/USB-PHY-JZ4770-Use-the-generic-PHY-framework/20200830-154912
base:b36c969764ab12faebb74711c942fa3e6eaf1e96
config: x86_64-randconfig-a012-20200830 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c10e63677f5d20f18010f8f68c631ddc97546f7d)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/phy/ingenic/phy-ingenic-usb.c:312:34: warning: unused variable
>> 'ingenic_usb_phy_of_matches' [-Wunused-const-variable]
static const struct of_device_id ingenic_usb_phy_of_matches[] = {
^
1 warning generated.
#
https://github.com/0day-ci/linux/commit/ab23f57890f43ef92dc601678a07b7754cc1833b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Zhou-Yanjie/USB-PHY-JZ4770-Use-the-generic-PHY-framework/20200830-154912
git checkout ab23f57890f43ef92dc601678a07b7754cc1833b
vim +/ingenic_usb_phy_of_matches +312 drivers/phy/ingenic/phy-ingenic-usb.c
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 311)
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 @312)
static const struct of_device_id ingenic_usb_phy_of_matches[] = {
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 313)
{ .compatible = "ingenic,jz4770-phy", .data = &jz4770_soc_info },
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 314)
{ .compatible = "ingenic,jz4780-phy", .data = &jz4780_soc_info },
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 315)
{ .compatible = "ingenic,x1000-phy", .data = &x1000_soc_info },
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 316)
{ .compatible = "ingenic,x1830-phy", .data = &x1830_soc_info },
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 317)
{ /* sentinel */ }
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 318)
};
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 319)
MODULE_DEVICE_TABLE(of, ingenic_usb_phy_of_matches);
2a6c0b82e65128c drivers/usb/phy/phy-jz4770.c 周琰杰 (Zhou Yanjie 2020-07-23 320)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] remoteproc: scp: add COMPILE_TEST dependency
Em Fri, 21 Aug 2020 20:58:32 +0900 Alexandre Courbot escreveu: > This will improve this driver's build coverage. There is a pending pull request for media which seems to depend on this patch. Without it, COMPILE_TEST breaks at linux-media git tree, if I pick it. See: https://lore.kernel.org/linux-media/20200830104650.0dd4d...@coco.lan/T/#t The best here would be to get an ack from the remoteproc maintainers to get this patch merged via the media tree. Alternatively, this patch could be applied on a stable topic branch at remoteproc tree, which would be merged at the media tree, or cherry-picked on media after being committed at remoteproc tree. Regards, Mauro > > Reported-by: Ezequiel Garcia > Signed-off-by: Alexandre Courbot > --- > drivers/remoteproc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index c6659dfea7c7..d1fcada71017 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -43,7 +43,7 @@ config INGENIC_VPU_RPROC > > config MTK_SCP > tristate "Mediatek SCP support" > - depends on ARCH_MEDIATEK > + depends on ARCH_MEDIATEK || COMPILE_TEST > select RPMSG_MTK_SCP > help > Say y here to support Mediatek's System Companion Processor (SCP) via Thanks, Mauro
Re: [PATCH] ASoC: rt5682: Prefer async probe
On Sat, Aug 29, 2020 at 7:20 AM Douglas Anderson wrote:
>
> The probe of rt5682 is pretty slow. A quick measurement shows that it
> takes ~650 ms on at least one board. There's no reason to block all
> other drivers waiting for this probe to finish. Set the flag to allow
> other drivers to probe while we're probing.
>
> Signed-off-by: Douglas Anderson
> ---
> NOTE: I haven't done any analysis of the driver to see _why_ it's so
> slow, only that I have measured it to be slow. Someone could
> certainly take the time to profile / optimize it, but in any case it
> still won't hurt to be async.
Hi Doug, thank you for the fix.
There are multiple usleep in the probe of rt5682 driver.
The major one is a 300 ms sleep after the regulator turns on.
There are other sleeps for several tens of ms.
>
>
> This is a very safe flag to turn on since:
>
> 1. It's not like our probe order was defined by anything anyway. When
> we probe is at the whim of when our i2c controller probes and that can
> be any time.
>
> 2. If some other driver needs us then they have to handle the fact
> that we might not have probed yet anyway.
Agree.
soc-core already handled this by returning -EPROBE_DEFER when a
component is not found.
So the machine driver can probe again.
Even in the current behavior, we already see machine driver probe
again when the codec driver is not ready,
so I think adding this async flag will not affect the machine driver.
>
>
> 3. There may be other drivers probing at the same time as us anyway
> because _they_ used async probe.
>
> While I won't say that it's impossible to tickle a bug by turning on
> async probe, I would assert that in almost all cases the bug was
> already there and needed to be fixed anyway.
>
> sound/soc/codecs/rt5682-i2c.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
> index 85aba311bdc8..6b4e0eb30c89 100644
> --- a/sound/soc/codecs/rt5682-i2c.c
> +++ b/sound/soc/codecs/rt5682-i2c.c
> @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
> .name = "rt5682",
> .of_match_table = rt5682_of_match,
> .acpi_match_table = rt5682_acpi_match,
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
One thing I am wondering is that there has not been any usage in codec
driver for this.
I think every codec driver can use this, and take the benefit of a
possible faster boot time ?
>
> },
> .probe = rt5682_i2c_probe,
> .shutdown = rt5682_i2c_shutdown,
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
[PATCH] dt-bindings: leds: common: Add mmc0 as default trigger
MMC could be a default trigger so add a pattern to match it and fix dtbs_check warnings like: arch/arm/boot/dts/exynos4412-odroidx.dt.yaml: leds: led2:linux,default-trigger:0: 'mmc0' is not one of ['backlight', 'default-on', 'heartbeat', 'disk-activity', 'ide-disk', 'timer', 'pattern'] From schema: Documentation/devicetree/bindings/leds/leds-gpio.yaml Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/leds/common.yaml | 39 ++- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index a2a541bca73c..6b38f9f3792c 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -78,25 +78,26 @@ properties: This parameter, if present, is a string defining the trigger assigned to the LED. $ref: /schemas/types.yaml#definitions/string - -enum: -# LED will act as a back-light, controlled by the framebuffer system - - backlight -# LED will turn on (but for leds-gpio see "default-state" property in -# Documentation/devicetree/bindings/leds/leds-gpio.yaml) - - default-on -# LED "double" flashes at a load average based rate - - heartbeat -# LED indicates disk activity - - disk-activity -# LED indicates IDE disk activity (deprecated), in new implementations -# use "disk-activity" - - ide-disk -# LED flashes at a fixed, configurable rate - - timer -# LED alters the brightness for the specified duration with one software -# timer (requires "led-pattern" property) - - pattern +oneOf: + - enum: +# LED will act as a back-light, controlled by the framebuffer system + - backlight +# LED will turn on (but for leds-gpio see "default-state" property in +# Documentation/devicetree/bindings/leds/leds-gpio.yaml) + - default-on +# LED "double" flashes at a load average based rate + - heartbeat +# LED indicates disk activity + - disk-activity +# LED indicates IDE disk activity (deprecated), in new implementations +# use "disk-activity" + - ide-disk +# LED flashes at a fixed, configurable rate + - timer +# LED alters the brightness for the specified duration with one software +# timer (requires "led-pattern" property) + - pattern + - pattern: "^mmc[0-9]+$" led-pattern: description: | -- 2.17.1
Re: [PATCH v2] platform: cros_ec: Reduce ligthbar get version command
On Sun, 30 Aug 2020 00:00:02 -0700
Gwendal Grignou wrote:
> On Sat, Aug 29, 2020 at 8:54 AM Jonathan Cameron wrote:
> >
> > On Tue, 25 Aug 2020 17:29:45 -0700
> > Gwendal Grignou wrote:
> >
> > > By default, the lightbar commands are set to the
> > > biggest lightbar command and response. That length is greater than 128
> > > bytes and may not work on all machines.
> > > But all EC are probed for lightbar by sending a get version request.
> > > Set that request size precisely.
> > >
> > > Before the command would be:
> > > cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194,
> > > insize: 128, result: 0
> > > Afer:
> > > cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1,
> > > insize: 8, result: 0
> > >
> > > Signed-off-by: Gwendal Grignou
> > Hi Gwendal,
> >
> > Description seems to me to suggest this is a fix?
> > Are there known machines on which it doesn't work currently?
> We have a prototype [without lightbar] where the command size was
> limited to 128 bytes.
> Given we issue a get_lightbar_version on all chromebooks, we had a
> failure on this prototype. Devices with a lightbar must support a
> command size greater or equal to 194 bytes.
> Beside helping the prototype to boot, this patch slightly speeds up
> the enumeration of devices managed by the EC.
> >
> > If so, please can I have a fixes tag. If it's just a precaution
> > against future problems then let me know and I can add it for the
> > next merge window.
> Done in v3.
> Note I made a mistake by sending the patch to linux-iio as it targeted
> platform/chromeos.
I hadn't even noticed that it wasn't in IIO. Oops :)
Jonathan
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > Changes since v1:
> > > - Remove BUG and TEST fields.
> > >
> > > drivers/platform/chrome/cros_ec_lightbar.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
> > > b/drivers/platform/chrome/cros_ec_lightbar.c
> > > index b59180bff5a3e..ef61298c30bdd 100644
> > > --- a/drivers/platform/chrome/cros_ec_lightbar.c
> > > +++ b/drivers/platform/chrome/cros_ec_lightbar.c
> > > @@ -116,6 +116,8 @@ static int get_lightbar_version(struct cros_ec_dev
> > > *ec,
> > >
> > > param = (struct ec_params_lightbar *)msg->data;
> > > param->cmd = LIGHTBAR_CMD_VERSION;
> > > + msg->outsize = sizeof(param->cmd);
> > > + msg->result = sizeof(resp->version);
> > > ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
> > > if (ret < 0) {
> > > ret = 0;
> >
Re: [RFC PATCH v2] iio: core: Add optional symbolic label to a device channel
On Mon, 24 Aug 2020 11:36:46 +0300
Cristian Pop wrote:
> If a label is defined in the device tree for this channel add that
> to the channel specific attributes. This is useful for userspace to
> be able to identify an individual channel.
>
> Signed-off-by: Cristian Pop
> ---
> Changes in v2:
> - Move label check before "read_raw" callback.
> - Move the responsability to of parsing channel labels, to the
> driver.
>
> drivers/iio/industrialio-core.c | 10 --
> include/linux/iio/iio.h | 2 ++
> include/linux/iio/types.h | 1 +
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 1527f01a44f1..32277e94f02d 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -135,6 +135,7 @@ static const char * const iio_modifier_names[] = {
> /* relies on pairs of these shared then separate */
> static const char * const iio_chan_info_postfix[] = {
> [IIO_CHAN_INFO_RAW] = "raw",
> + [IIO_CHAN_INFO_LABEL] = "label",
> [IIO_CHAN_INFO_PROCESSED] = "input",
> [IIO_CHAN_INFO_SCALE] = "scale",
> [IIO_CHAN_INFO_OFFSET] = "offset",
> @@ -653,14 +654,18 @@ static ssize_t iio_read_channel_info(struct device *dev,
> int ret;
> int val_len = 2;
>
> - if (indio_dev->info->read_raw_multi)
> + if (indio_dev->info->read_raw_multi) {
> ret = indio_dev->info->read_raw_multi(indio_dev, this_attr->c,
> INDIO_MAX_RAW_ELEMENTS,
> vals, &val_len,
> this_attr->address);
> - else
> + } else {
> ret = indio_dev->info->read_raw(indio_dev, this_attr->c,
> &vals[0], &vals[1], this_attr->address);
> + if (ret < 0 && this_attr->address == IIO_CHAN_INFO_LABEL &&
> + this_attr->c->label_name)
I'm not keen on this. We shouldn't be calling read_raw at all in this path.
There is no way it can return a valid label.
> + return sprintf(buf, "%s\n", this_attr->c->label_name);
> + }
>
> if (ret < 0)
> return ret;
> @@ -1399,6 +1404,7 @@ static int iio_device_register_sysfs(struct iio_dev
> *indio_dev)
> attrcount_orig++;
> }
> attrcount = attrcount_orig;
> +
Please avoid unrelated white space changes.
> /*
>* New channel registration method - relies on the fact a group does
>* not need to be initialized if its name is NULL.
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index a1be82e74c93..39209f3b62be 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -223,6 +223,7 @@ struct iio_event_spec {
> * correspond to the first name that the channel is
> referred
> * to by in the datasheet (e.g. IND), or the nearest
> * possible compound name (e.g. IND-INC).
> + * @label_name: Unique name to identify which channel this is.
> * @modified:Does a modifier apply to this channel. What
> these are
> * depends on the channel type. Modifier is set in
> * channel2. Examples are IIO_MOD_X for axial sensors about
> @@ -260,6 +261,7 @@ struct iio_chan_spec {
> const struct iio_chan_spec_ext_info *ext_info;
> const char *extend_name;
> const char *datasheet_name;
> + const char *label_name;
This can't be part of chan_spec as that is constant in many drivers.
We need a separate way of doing this. Don't use info_mask,
but register it separately for each channel in a similar way
to we do the name and label attributes for the whole device.
I would add a new callback to iio_info that is passed the
iio_chan_spec and returns a const char * for the label name.
The driver would be responsible for doing a lookup based
on what it has cached from the dt parse, probably indexed
off address or scan_index (that can be driver specific)
To create the attribute you need to add this to
iio_device_register_sysfs and use the various core
functions to build the attribute name in a similar fashion to
that done for info mask elements.
It will be more complex than your approach, but make it more
'separable' as a feature in drivers.
Jonathan
> unsignedmodified:1;
> unsignedindexed:1;
> unsignedoutput:1;
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index e6fd3645963c..c8f65f476eb2 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -34,6 +34,7 @@ enum iio_available_type {
>
> enum iio_chan_info_enum {
> IIO_CHAN_INFO_RAW = 0,
> + IIO_CHAN_INFO_
[PATCH 2/2] dt-bindings: sound: odroid: Use unevaluatedProperties
Additional properties or nodes actually might appear (e.g. assigned-clocks) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm/boot/dts/exynos5422-odroidxu3.dt.yaml: sound: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/sound/samsung,odroid.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml index 8ff2d39e7d17..de1be3d6d1e9 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml @@ -69,7 +69,7 @@ required: - cpu - codec -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.17.1
[PATCH 1/2] dt-bindings: sound: midas-audio: Correct parsing sound-dai phandles
The "sound-dai" property has cells therefore phandle-array should be used, even if it is just one phandle. This fixes dtbs_check warnings like: arch/arm/boot/dts/exynos4412-trats2.dt.yaml: sound: cpu:sound-dai:0:1: missing phandle tag in 0 arch/arm/boot/dts/exynos4412-trats2.dt.yaml: sound: cpu:sound-dai:0: [158, 0] is too long Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/sound/samsung,midas-audio.yaml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml index 1c755de686f7..578928e67e5c 100644 --- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml @@ -21,7 +21,8 @@ properties: type: object properties: sound-dai: -$ref: /schemas/types.yaml#/definitions/phandle +$ref: /schemas/types.yaml#/definitions/phandle-array +maxItems: 1 description: phandle to the I2S controller required: - sound-dai @@ -30,7 +31,8 @@ properties: type: object properties: sound-dai: -$ref: /schemas/types.yaml#/definitions/phandle +$ref: /schemas/types.yaml#/definitions/phandle-array +maxItems: 1 description: phandle to the WM1811 CODEC required: - sound-dai -- 2.17.1
[PATCH] dt-bindings: gpu: samsung-rotator: Use unevaluatedProperties
Additional properties or nodes actually might appear (e.g. power domains) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281: 'iommus', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml index 665c6e3b31d3..c897c687bdab 100644 --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml @@ -36,7 +36,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.17.1
Re: [PATCH v2] powerpc/32s: Disable VMAP stack which CONFIG_ADB_PMU
On Thu, 27 Aug 2020 18:30:27 + (UTC), Christophe Leroy wrote: > low_sleep_handler() can't restore the context from virtual > stack because the stack can hardly be accessed with MMU OFF. > > For now, disable VMAP stack when CONFIG_ADB_PMU is selected. Applied to powerpc/fixes. [1/1] powerpc/32s: Disable VMAP stack which CONFIG_ADB_PMU https://git.kernel.org/powerpc/c/4a133eb351ccc275683ad49305d0b04dde903733 cheers
Re: [PATCH] Documentation: submit-checklist: add Documentation clean builds
On Sun, Aug 23, 2020 at 05:38:12PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Add to Documentation/process/submit-checklist.rst that patch > submitters should run "make htmldocs" and verify that any > Documentation/ changes (patches) are clean (no new warnings/errors). > > Signed-off-by: Randy Dunlap > --- > Documentation/process/submit-checklist.rst |4 > 1 file changed, 4 insertions(+) > > --- linux-next-20200821.orig/Documentation/process/submit-checklist.rst > +++ linux-next-20200821/Documentation/process/submit-checklist.rst > @@ -24,6 +24,10 @@ and elsewhere regarding submitting Linux > >c) Builds successfully when using ``O=builddir`` > > + d) Any Documentation/ changes build successfully without warnings/errors. Maybe "... without new warnings/errors"? Unfortunately we still have plenty of old ones... > + Use ``make htmldocs`` or ``make pdfdocs`` to check the build and > + fix any issues. > + > 3) Builds on multiple CPU architectures by using local cross-compile tools > or some other build farm. > > -- Sincerely yours, Mike.
Re: [PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
On Fri, Aug 28, 2020 at 03:30:32PM -0700, Kyung Min Park wrote: > Should I mention the tool specifically although the tool is WIP? Well, if you wanna look at it that way, the whole kernel is constantly and forever WIP. :-) Also, if there's some functionality missing, pointing to it might make people send patches. > As you commented previously, should I use > tools/arch/x86/tools/cpuid/cpuid as the future tool and its location? Yeah, let's just drop the second "tools", i.e., tools/arch/x86/kcpuid/ or so should be good enough. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:259:19: error: unused function 'rq_prio'
Hi Nick,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1127b219ce9481c84edad9711626d856127d5e51
commit: 9f4069b055d1508c833115df7493b6e0001e5c9b drm/i915: re-disable
-Wframe-address
date: 4 months ago
config: x86_64-randconfig-r016-20200830 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c10e63677f5d20f18010f8f68c631ddc97546f7d)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 9f4069b055d1508c833115df7493b6e0001e5c9b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:259:19: error: unused
>> function 'rq_prio' [-Werror,-Wunused-function]
static inline int rq_prio(const struct i915_request *rq)
^
1 error generated.
--
>> drivers/gpu/drm/i915/gvt/gtt.c:267:19: error: unused function 'get_pt_type'
>> [-Werror,-Wunused-function]
static inline int get_pt_type(int type)
^
>> drivers/gpu/drm/i915/gvt/gtt.c:590:20: error: unused function
>> 'ppgtt_set_guest_root_entry' [-Werror,-Wunused-function]
static inline void ppgtt_set_guest_root_entry(struct intel_vgpu_mm *mm,
^
2 errors generated.
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f4069b055d1508c833115df7493b6e0001e5c9b
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9f4069b055d1508c833115df7493b6e0001e5c9b
vim +/rq_prio +259 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
34ba5a80f249cd drivers/gpu/drm/i915/i915_guc_submission.c Chris Wilson
2016-11-29 258
22b7a426bbe1eb drivers/gpu/drm/i915/intel_guc_submission.c Chris Wilson
2019-06-20 @259 static inline int rq_prio(const struct i915_request *rq)
77f0d0e925e8a0 drivers/gpu/drm/i915/i915_guc_submission.c Chris Wilson
2017-05-17 260 {
22b7a426bbe1eb drivers/gpu/drm/i915/intel_guc_submission.c Chris Wilson
2019-06-20 261 return rq->sched.attr.priority | __NO_PREEMPTION;
77f0d0e925e8a0 drivers/gpu/drm/i915/i915_guc_submission.c Chris Wilson
2017-05-17 262 }
77f0d0e925e8a0 drivers/gpu/drm/i915/i915_guc_submission.c Chris Wilson
2017-05-17 263
:: The code at line 259 was first introduced by commit
:: 22b7a426bbe1ebe1520f92da4cd1617d1e1b5fc4 drm/i915/execlists:
Preempt-to-busy
:: TO: Chris Wilson
:: CC: Chris Wilson
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] fbdev: remove mbx framebuffer driver
From: Mike Rapoport
The only in-tree user for mbx driver for Intel 2700G graphics chip was
cm-x270 platform. Since this platform was removed by the commit
9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards") there is no
point to keep the obsolete framebuffer driver.
Signed-off-by: Mike Rapoport
---
.../userspace-api/ioctl/ioctl-number.rst |2 -
drivers/video/fbdev/Kconfig | 19 -
drivers/video/fbdev/Makefile |1 -
drivers/video/fbdev/mbx/Makefile |4 -
drivers/video/fbdev/mbx/mbxdebugfs.c | 232
drivers/video/fbdev/mbx/mbxfb.c | 1053 -
drivers/video/fbdev/mbx/reg_bits.h| 614 --
drivers/video/fbdev/mbx/regs.h| 196 ---
include/video/mbxfb.h | 99 --
9 files changed, 2220 deletions(-)
delete mode 100644 drivers/video/fbdev/mbx/Makefile
delete mode 100644 drivers/video/fbdev/mbx/mbxdebugfs.c
delete mode 100644 drivers/video/fbdev/mbx/mbxfb.c
delete mode 100644 drivers/video/fbdev/mbx/reg_bits.h
delete mode 100644 drivers/video/fbdev/mbx/regs.h
delete mode 100644 include/video/mbxfb.h
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 2a198838fca9..a20102f7db69 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -356,8 +356,6 @@ Code Seq#Include File
Comments
0xEC 00-01 drivers/platform/chrome/cros_ec_dev.h ChromeOS
EC driver
0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in
development)
-0xF4 00-1F video/mbxfb.h mbxfb
-
0xF6 allLTTng
Linux Trace Toolkit Next Generation
0xFD alllinux/dm-ioctl.h
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index b2c9dd4f0cb5..e36578258b5b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1775,25 +1775,6 @@ config PXA3XX_GCU
If you compile this as a module, it will be called pxa3xx_gcu.
-config FB_MBX
- tristate "2700G LCD framebuffer support"
- depends on FB && ARCH_PXA
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- help
- Framebuffer driver for the Intel 2700G (Marathon) Graphics
- Accelerator
-
-config FB_MBX_DEBUG
- bool "Enable debugging info via debugfs"
- depends on FB_MBX && DEBUG_FS
- help
- Enable this if you want debugging information using the debug
- filesystem (debugfs)
-
- If unsure, say N.
-
config FB_FSL_DIU
tristate "Freescale DIU framebuffer support"
depends on FB && FSL_SOC
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index cad4fb64442a..2ff8849ffde6 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -31,7 +31,6 @@ obj-$(CONFIG_FB_VIA)+= via/
obj-$(CONFIG_FB_KYRO) += kyro/
obj-$(CONFIG_FB_SAVAGE) += savage/
obj-$(CONFIG_FB_GEODE) += geode/
-obj-$(CONFIG_FB_MBX) += mbx/
obj-$(CONFIG_FB_NEOMAGIC) += neofb.o
obj-$(CONFIG_FB_3DFX) += tdfxfb.o
obj-$(CONFIG_FB_CONTROL) += controlfb.o
diff --git a/drivers/video/fbdev/mbx/Makefile b/drivers/video/fbdev/mbx/Makefile
deleted file mode 100644
index 3e8e7ff41f18..
--- a/drivers/video/fbdev/mbx/Makefile
+++ /dev/null
@@ -1,4 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-# Makefile for the 2700G controller driver.
-
-obj-y += mbxfb.o
diff --git a/drivers/video/fbdev/mbx/mbxdebugfs.c
b/drivers/video/fbdev/mbx/mbxdebugfs.c
deleted file mode 100644
index 09af721638fb..
--- a/drivers/video/fbdev/mbx/mbxdebugfs.c
+++ /dev/null
@@ -1,232 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-#include
-
-#define BIG_BUFFER_SIZE(1024)
-
-static char big_buffer[BIG_BUFFER_SIZE];
-
-struct mbxfb_debugfs_data {
- struct dentry *dir;
- struct dentry *sysconf;
- struct dentry *clock;
- struct dentry *display;
- struct dentry *gsctl;
- struct dentry *sdram;
- struct dentry *misc;
-};
-
-static ssize_t write_file_dummy(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- return count;
-}
-
-static ssize_t sysconf_read_file(struct file *file, char __user *userbuf,
-
Re: [PATCH] fsldma: fsl_ioread64*() do not need lower_32_bits()
On Sat, Aug 29, 2020 at 10:29:55AM -0700, Linus Torvalds wrote: > On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck > wrote: > > > > But the pointer is already 32-bit, so simply cast the pointer to u32. > > Yeah, that code was completely pointless. If the pointer had actually > been 64-bit, the old code would have warned too. > > The odd thing is that the fsl_iowrite64() functions make sense. It's > only the fsl_ioread64() functions that seem to be written by somebody > who is really confused. > > That said, this patch only humors the confusion. The cast to 'u32' is > completely pointless. In fact, it seems to be actively wrong, because > it means that the later "fsl_addr + 1" is done entirely incorrectly - > it now literally adds "1" to an integer value, while the iowrite() > functions will add one to a "u32 __iomem *" pointer (so will do > pointer arithmetic, and add 4). > My bad. I had noticed the '+ 1' and so automatically assumed 'OK, pointer arithmetic now' without noticing that the cast was done only after the addition. Grrr. FWIW, the version you committed looks much better to me. -- Luc
[PATCH v2] i2c: npcm7xx: bug fix timeout (usec instead of msec)
i2c: npcm7xx: bug fix timeout (usec instead of msec)
Signed-off-by: Tali Perry
---
drivers/i2c/busses/i2c-npcm7xx.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-npcm7xx.c b/drivers/i2c/busses/i2c-npcm7xx.c
index 75f07138a6fa..abb334492a3d 100644
--- a/drivers/i2c/busses/i2c-npcm7xx.c
+++ b/drivers/i2c/busses/i2c-npcm7xx.c
@@ -2093,8 +2093,13 @@ static int npcm_i2c_master_xfer(struct i2c_adapter
*adap, struct i2c_msg *msgs,
}
}
- /* Adaptive TimeOut: astimated time in usec + 100% margin */
- timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
+ /*
+* Adaptive TimeOut: estimated time in usec + 100% margin:
+* 2: double the timeout for clock stretching case
+* 9: bits per transaction (including the ack/nack)
+* 100: micro second in a second
+*/
+ timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread + nwrite);
timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
--
2.22.0
Re: [Linux-kernel-mentees] [PATCH] net: bluetooth: Fix null pointer deref in hci_phy_link_complete_evt
On Sun, Aug 30, 2020 at 11:19:17AM +0200, Greg KH wrote:
> On Sat, Aug 29, 2020 at 10:27:12PM +0530, Anmol Karn wrote:
> > Fix null pointer deref in hci_phy_link_complete_evt, there was no
> > checking there for the hcon->amp_mgr->l2cap_conn->hconn, and also
> > in hci_cmd_work, for hdev->sent_cmd.
> >
> > To fix this issue Add pointer checking in hci_cmd_work and
> > hci_phy_link_complete_evt.
> > [Linux-next-20200827]
> >
> > This patch corrected some mistakes from previous patch.
> >
> > Reported-by: syzbot+0bef568258653cff2...@syzkaller.appspotmail.com
> > Link:
> > https://syzkaller.appspot.com/bug?id=0d93140da5a82305a66a136af99b088b75177b99
> > Signed-off-by: Anmol Karn
> > ---
> > net/bluetooth/hci_core.c | 5 -
> > net/bluetooth/hci_event.c | 4
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 68bfe57b6625..996efd654e7a 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -4922,7 +4922,10 @@ static void hci_cmd_work(struct work_struct *work)
> >
> > kfree_skb(hdev->sent_cmd);
> >
> > - hdev->sent_cmd = skb_clone(skb, GFP_KERNEL);
> > + if (hdev->sent_cmd) {
> > + hdev->sent_cmd = skb_clone(skb, GFP_KERNEL);
> > + }
>
> How can sent_cmd be NULL here? Are you sure something previous to this
> shouldn't be fixed instead?
Sir, sent_cmd was freed before this condition check, thats why i checked it,
i think i should check it before the free of hdev->sent_cmd like,
if (hdev->sent_cmd)
kfree_skb(hdev->sent_cmd);
what's your opininon on this.
>
>
> > +
> > if (hdev->sent_cmd) {
> > if (hci_req_status_pend(hdev))
> > hci_dev_set_flag(hdev, HCI_CMD_PENDING);
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 4b7fc430793c..1e7d9bee9111 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -4941,6 +4941,10 @@ static void hci_phy_link_complete_evt(struct hci_dev
> > *hdev,
> > hci_dev_unlock(hdev);
> > return;
> > }
> > + if (!(hcon->amp_mgr->l2cap_conn->hcon)) {
> > + hci_dev_unlock(hdev);
> > + return;
> > + }
>
> How can this be triggered?
syzbot showed that this line is accessed irrespective of the null value it
contains, so added a
pointer check for that.
please give some opinions on this,
if (!bredr_hcon) {
hci_dev_unlock(hdev);
return;
}
Thanks,
Anmol Karn
[GIT PULL] Please pull powerpc/linux.git powerpc-5.9-4 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 5.9: The following changes since commit 64ef8f2c4791940d7f3945507b6a45c20d959260: powerpc/perf/hv-24x7: Move cpumask file to top folder of hv-24x7 driver (2020-08-21 23:35:27 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.9-4 for you to fetch changes up to 4a133eb351ccc275683ad49305d0b04dde903733: powerpc/32s: Disable VMAP stack which CONFIG_ADB_PMU (2020-08-28 12:03:18 +1000) - -- powerpc fixes for 5.9 #4 Revert our removal of PROT_SAO, at least one user expressed an interest in using it on Power9. Instead don't allow it to be used in guests unless enabled explicitly at compile time. A fix for a crash introduced by a recent change to FP handling. Revert a change to our idle code that left Power10 with no idle support. One minor fix for the new scv system call path to set PPR. Fix a crash in our "generic" PMU if branch stack events were enabled. A fix for the IMC PMU, to correctly identify host kernel samples. The ADB_PMU powermac code was found to be incompatible with VMAP_STACK, so make them incompatible in Kconfig until the code can be fixed. A build fix in drivers/video/fbdev/controlfb.c, and a documentation fix. Thanks to: Alexey Kardashevskiy, Athira Rajeev, Christophe Leroy, Giuseppe Sacco, Madhavan Srinivasan, Milton Miller, Nicholas Piggin, Pratik Rajesh Sampat, Randy Dunlap, Shawn Anastasio, Vaidyanathan Srinivasan. - -- Alexey Kardashevskiy (1): powerpc/perf: Fix crashes with generic_compat_pmu & BHRB Athira Rajeev (1): powerpc/perf: Fix reading of MSR[HV/PR] bits in trace-imc Christophe Leroy (1): powerpc/32s: Disable VMAP stack which CONFIG_ADB_PMU Michael Ellerman (2): video: fbdev: controlfb: Fix build for COMPILE_TEST=y && PPC_PMAC=n powerpc/64s: Fix crash in load_fp_state() due to fpexc_mode Nicholas Piggin (1): powerpc/64s: scv entry should set PPR Pratik Rajesh Sampat (1): Revert "powerpc/powernv/idle: Replace CPU feature check with PVR check" Randy Dunlap (1): Documentation/powerpc: fix malformed table in syscall64-abi Shawn Anastasio (3): Revert "powerpc/64s: Remove PROT_SAO support" powerpc/64s: Disallow PROT_SAO in LPARs by default selftests/powerpc: Update PROT_SAO test to skip ISA 3.1 Documentation/powerpc/syscall64-abi.rst | 4 +- arch/powerpc/Kconfig | 12 ++ arch/powerpc/include/asm/book3s/64/pgtable.h | 8 ++-- arch/powerpc/include/asm/cputable.h | 10 ++--- arch/powerpc/include/asm/mman.h | 31 -- arch/powerpc/include/asm/nohash/64/pgtable.h | 2 + arch/powerpc/include/uapi/asm/mman.h | 2 +- arch/powerpc/kernel/dt_cpu_ftrs.c | 2 +- arch/powerpc/kernel/entry_64.S| 4 ++ arch/powerpc/kernel/process.c | 12 -- arch/powerpc/mm/book3s64/hash_utils.c | 2 + arch/powerpc/perf/core-book3s.c | 19 ++--- arch/powerpc/perf/imc-pmu.c | 4 +- arch/powerpc/platforms/Kconfig.cputype| 2 +- arch/powerpc/platforms/powernv/idle.c | 2 +- drivers/video/fbdev/controlfb.c | 2 + include/linux/mm.h| 2 + include/trace/events/mmflags.h| 2 + mm/ksm.c | 4 ++ tools/testing/selftests/powerpc/mm/.gitignore | 1 + tools/testing/selftests/powerpc/mm/Makefile | 4 +- tools/testing/selftests/powerpc/mm/prot_sao.c | 43 22 files changed, 144 insertions(+), 30 deletions(-) create mode 100644 tools/testing/selftests/powerpc/mm/prot_sao.c -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl9LmmkACgkQUevqPMjh pYBw8w//RQpss9mLAe8NTVBF9bV6sMRWaTugjaRwQIIzbhu21eygaIcW9d4XFtXz xVB83HHRoD4ND+DH/7rOq6ZCIzusbfeqhm0uRBzkrlwVZuo4Y/ZuCvW+0Bo06qRp nkayAtpoI1wGoeWQcHUpHunZgwQTbWVNAo1yRo4cm8ux5wP88E1iEiZdNXcP/IPr V3p0BGYpCrwuNUKE54N3JPOHRP1UILBff1agjfhfctTTVY+tUB5katgMxYh8Euv+ HVTm7U5QHnvkqhLSxdP76UP6R1DCN+E8GruXbDpR+ofJ5PLd1TgY5w3CLNjE88Pn fnM7GigG6xB3x/DunbVOD3RRGKKg6FFJIRvJ6YrSEWkf84IUKxsQ6Y0Noeb2bLs9 04C5hN0d7GBi7JSjW0nZZvB3jZT0ptiAl3BggEhOshfaqyloogOHEk4pxyXG2/ja fkTFDdhEgNBO/iAjGCsXaUmaSa1OimpENKNZtosPL6dYbG/FFQ2UgKz+lUR7jsD8 5uH8H1gKH1565JmRfckcplX2hkwPteVDQ2HzSQAD3KyjIMmvDPLCAynTlvxxxn/V wPeoXpeD1DDZA7RSiV+jaVtjK6rNcjbAUUOhlngigSiXCjBvfsA4lDhovQzivsOF E1TRnWSmCrTlV21+rtSZjbEdg/WLiBIHVu0DLGjcSw/XeaVa9g8= =3NM9 -END PGP SIGNATURE-
[PATCH] get_maintainer: add email addresses from dts files
MAINTAINER file will get bloated quickly if individual section entry
is created for each .dts/.dtsi file. Add the email address from dts
files to get_maintainer output for saving unnecessary patching on
MAINTAINER file.
Suggested-by: Joe Perches
Signed-off-by: Shawn Guo
---
scripts/get_maintainer.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 484d2fbf5921..b8e104028359 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -436,7 +436,7 @@ sub maintainers_in_file {
return if ($file =~ m@\bMAINTAINERS$@);
-if (-f $file && ($email_file_emails || $file =~ /\.yaml$/)) {
+if (-f $file && ($email_file_emails || $file =~ /\.(?:yaml|dtsi?)$/)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };
--
2.17.1
Re: fsl_espi errors on v5.7.15
Excerpts from Chris Packham's message of August 28, 2020 8:07 am:
> On 27/08/20 7:12 pm, Nicholas Piggin wrote:
>> Excerpts from Heiner Kallweit's message of August 26, 2020 4:38 pm:
>>> On 26.08.2020 08:07, Chris Packham wrote:
On 26/08/20 1:48 pm, Chris Packham wrote:
> On 26/08/20 10:22 am, Chris Packham wrote:
>> On 25/08/20 7:22 pm, Heiner Kallweit wrote:
>>
>>
>>> I've been staring at spi-fsl-espi.c for while now and I think I've
identified a couple of deficiencies that may or may not be related
to my
issue.
First I think the 'Transfer done but SPIE_DON isn't set' message
can be
generated spuriously. In fsl_espi_irq() we read the ESPI_SPIE
register.
We also write back to it to clear the current events. We re-read it in
fsl_espi_cpu_irq() and complain when SPIE_DON is not set. But we can
naturally end up in that situation if we're doing a large read.
Consider
the messages for reading a block of data from a spi-nor chip
tx = READ_OP + ADDR
rx = data
We setup the transfer and pump out the tx_buf. The first interrupt
goes
off and ESPI_SPIE has SPIM_DON and SPIM_RXT set. We empty the rx fifo,
clear ESPI_SPIE and wait for the next interrupt. The next interrupt
fires and this time we have ESPI_SPIE with just SPIM_RXT set. This
continues until we've received all the data and we finish with
ESPI_SPIE
having only SPIM_RXT set. When we re-read it we complain that SPIE_DON
isn't set.
The other deficiency is that we only get an interrupt when the
amount of
data in the rx fifo is above FSL_ESPI_RXTHR. If there are fewer than
FSL_ESPI_RXTHR left to be received we will never pull them out of
the fifo.
>>> SPIM_DON will trigger an interrupt once the last characters have been
>>> transferred, and read the remaining characters from the FIFO.
>> The T2080RM that I have says the following about the DON bit
>>
>> "Last character was transmitted. The last character was transmitted
>> and a new command can be written for the next frame."
>>
>> That does at least seem to fit with my assertion that it's all about
>> the TX direction. But the fact that it doesn't happen all the time
>> throws some doubt on it.
>>
>>> I think the reason I'm seeing some variability is because of how fast
(or slow) the interrupts get processed and how fast the spi-nor
chip can
fill the CPUs rx fifo.
>>> To rule out timing issues at high bus frequencies I initially asked
>>> for re-testing at lower frequencies. If you e.g. limit the bus to 1 MHz
>>> or even less, then timing shouldn't be an issue.
>> Yes I've currently got spi-max-frequency = <100>; in my dts. I
>> would also expect a slower frequency would fit my "DON is for TX"
>> narrative.
>>> Last relevant functional changes have been done almost 4 years ago.
>>> And yours is the first such report I see. So question is what could
>>> be so
>>> special with your setup that it seems you're the only one being
>>> affected.
>>> The scenarios you describe are standard, therefore much more people
>>> should be affected in case of a driver bug.
>> Agreed. But even on my hardware (which may have a latent issue
>> despite being in the field for going on 5 years) the issue only
>> triggers under some fairly specific circumstances.
>>> You said that kernel config impacts how frequently the issue happens.
>>> Therefore question is what's the diff in kernel config, and how could
>>> the differences be related to SPI.
>> It did seem to be somewhat random. Things like CONFIG_PREEMPT have an
>> impact but every time I found something that seemed to be having an
>> impact I've been able to disprove it. I actually think its about how
>> busy the system is which may or may not affect when we get round to
>> processing the interrupts.
>>
>> I have managed to get the 'Transfer done but SPIE_DON isn't set!' to
>> occur on the T2080RDB.
>>
>> I've had to add the following to expose the environment as a mtd
>> partition
>>
>> diff --git a/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
>> b/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
>> index ff87e67c70da..fbf95fc1fd68 100644
>> --- a/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
>> +++ b/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
>> @@ -116,6 +116,15 @@ flash@0 {
>> compatible = "micron,n25q512ax3",
>> "jedec,spi-nor";
>> reg = <0>;
>> spi-max-frequency = <1000>; /*
>> input clock */
>> +
>> +
Re: possible deadlock in proc_pid_syscall (2)
pet...@infradead.org writes:
> On Fri, Aug 28, 2020 at 07:01:17AM -0500, Eric W. Biederman wrote:
>> This feels like an issue where perf can just do too much under
>> exec_update_mutex. In particular calling kern_path from
>> create_local_trace_uprobe. Calling into the vfs at the very least
>> makes it impossible to know exactly which locks will be taken.
>>
>> Thoughts?
>
>> > -> #1 (&ovl_i_mutex_dir_key[depth]){}-{3:3}:
>> >down_read+0x96/0x420 kernel/locking/rwsem.c:1492
>> >inode_lock_shared include/linux/fs.h:789 [inline]
>> >lookup_slow fs/namei.c:1560 [inline]
>> >walk_component+0x409/0x6a0 fs/namei.c:1860
>> >lookup_last fs/namei.c:2309 [inline]
>> >path_lookupat+0x1ba/0x830 fs/namei.c:2333
>> >filename_lookup+0x19f/0x560 fs/namei.c:2366
>> >create_local_trace_uprobe+0x87/0x4e0
>> > kernel/trace/trace_uprobe.c:1574
>> >perf_uprobe_init+0x132/0x210 kernel/trace/trace_event_perf.c:323
>> >perf_uprobe_event_init+0xff/0x1c0 kernel/events/core.c:9580
>> >perf_try_init_event+0x12a/0x560 kernel/events/core.c:10899
>> >perf_init_event kernel/events/core.c:10951 [inline]
>> >perf_event_alloc.part.0+0xdee/0x3770 kernel/events/core.c:11229
>> >perf_event_alloc kernel/events/core.c:11608 [inline]
>> >__do_sys_perf_event_open+0x72c/0x2cb0 kernel/events/core.c:11724
>> >do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Right, so we hold the mutex fairly long there, supposedly to ensure
> privs don't change out from under us.
>
> We do the permission checks early -- no point in doing anything else if
> we're not allowed, but we then have to hold this mutex until the event
> is actually installed according to that comment.
>
> /me goes look at git history:
>
> 6914303824bb5 - changed cred_guard_mutex into exec_update_mutex
> 79c9ce57eb2d5 - introduces cred_guard_mutex
>
> So that latter commit explains the race we're guarding against. Without
> this we can install the event after execve() which might have changed
> privs on us.
>
> I'm open to suggestions on how to do this differently.
>
> Could we check privs twice instead?
>
> Something like the completely untested below..
That might work.
I am thinking that for cases where we want to do significant work it
might be better to ask the process to pause at someplace safe (probably
get_signal) and then do all of the work when we know nothing is changing
in the process.
I don't really like the idea of checking and then checking again. We
might have to do it but it feels like the model is wrong somewhere.
Given that this is tricky to hit in practice, and given that I am
already working the general problem of how to sort out the locking I am
going to work this with the rest of the thorny issues of in exec. This
feels like a case where the proper solution is that we simply need
something better than a mutex.
I had not realized before this how much setting up tracing in
perf_even_open looks like attaching a debugger in ptrace_attach.
I need to look at this some more but I suspect exec should be
treating a tracer like exec currently treats a ptracer for
purposes of permission checks. So I think we may have more issues
than simply the possibility of deadlock on exec_update_mutex.
Eric
> ---
> diff --git a/include/linux/freelist.h b/include/linux/freelist.h
> new file mode 100644
> index ..e69de29bb2d1
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 5bfe8e3c6e44..14e6c9bbfcda 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -11701,21 +11701,9 @@ SYSCALL_DEFINE5(perf_event_open,
> }
>
> if (task) {
> - err =
> mutex_lock_interruptible(&task->signal->exec_update_mutex);
> - if (err)
> - goto err_task;
> -
> - /*
> - * Preserve ptrace permission check for backwards compatibility.
> - *
> - * We must hold exec_update_mutex across this and any potential
> - * perf_install_in_context() call for this new event to
> - * serialize against exec() altering our credentials (and the
> - * perf_event_exit_task() that could imply).
> - */
> err = -EACCES;
> if (!perfmon_capable() && !ptrace_may_access(task,
> PTRACE_MODE_READ_REALCREDS))
> - goto err_cred;
> + goto err_task;
> }
>
> if (flags & PERF_FLAG_PID_CGROUP)
> @@ -11844,6 +11832,24 @@ SYSCALL_DEFINE5(perf_event_open,
> goto err_context;
> }
>
> + if (task) {
> + err =
> mutex_lock_interruptible(&task->signal->exec_update_mutex);
> + if (err)
> + goto err_file;
> +
> + /*
> + * Preserve ptrace permission check for backwards compatibility
Re: [PATCH] iio: pulse: Support PWM capture with TI AM3358 eCAP module
On Tue, 18 Aug 2020 10:36:14 -0500
Darren Schachter wrote:
> This IIO driver adds support for PWM capture with the TI eCAP module.
> This driver is based on Matt Porter's eCAP driver from January 2014,
> which was never merged into the mainline [1]. Like Matt's code, this
> driver implements interrupt driven triggered buffer capture. However,
> the driver has been updated based on previous suggestions in the IIO
> mailing list. Additionally, support for prescalar control and finer
> polarity control has been included. Users can now configure the
> polarities of CAP1 and CAP2 individually, allowing for the measurement
> of a signal's high-time, low-time, or period.
>
> [1] https://marc.info/?l=linux-iio&m=145968010427392&w=2
>
> Signed-off-by: Darren Schachter
Hi Darren,
I'll review this as is, but from earlier feedback it seems we have
some other questions to answer before potentially taking this
into IIO.
There is a fair bit of new ABI in here that all needs documenting.
Thanks,
Jonathan
> ---
> drivers/iio/Kconfig | 1 +
> drivers/iio/Makefile | 1 +
> drivers/iio/industrialio-core.c | 1 +
> drivers/iio/pulse/Kconfig| 18 +
> drivers/iio/pulse/Makefile | 6 +
> drivers/iio/pulse/pulse_tiecap.c | 585 +++
> include/uapi/linux/iio/types.h | 1 +
> 7 files changed, 613 insertions(+)
> create mode 100644 drivers/iio/pulse/Kconfig
> create mode 100644 drivers/iio/pulse/Makefile
> create mode 100644 drivers/iio/pulse/pulse_tiecap.c
>
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index d5c073a8aa3e..0351b0dd209e 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -93,6 +93,7 @@ source "drivers/iio/potentiometer/Kconfig"
> source "drivers/iio/potentiostat/Kconfig"
> source "drivers/iio/pressure/Kconfig"
> source "drivers/iio/proximity/Kconfig"
> +source "drivers/iio/pulse/Kconfig"
> source "drivers/iio/resolver/Kconfig"
> source "drivers/iio/temperature/Kconfig"
>
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index 1712011c0f4a..8a26c4a53b31 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -36,6 +36,7 @@ obj-y += potentiometer/
> obj-y += potentiostat/
> obj-y += pressure/
> obj-y += proximity/
> +obj-y += pulse/
> obj-y += resolver/
> obj-y += temperature/
> obj-y += trigger/
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 352533342702..6f4f0be474ef 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -86,6 +86,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> [IIO_MASSCONCENTRATION] = "massconcentration",
> + [IIO_PULSE] = "pulse",
> };
>
> static const char * const iio_modifier_names[] = {
> diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
> new file mode 100644
> index ..802873df2d62
> --- /dev/null
> +++ b/drivers/iio/pulse/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# Pulse Capture Devices
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Pulse Capture Devices"
> +
> +config IIO_TIECAP
> + tristate "TI ECAP Pulse Capture"
> + depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE ||
> ARCH_K3 || COMPILE_TEST
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + If you say yes here you get support for the TI ECAP peripheral
> + in pulse capture mode. This driver can also be built as a
> + module. If so, the module will be called pulse_tiecap.
> +
> +endmenu
> diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
> new file mode 100644
> index ..8eefe9dd230b
> --- /dev/null
> +++ b/drivers/iio/pulse/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for IIO PWM Capture Device
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_IIO_TIECAP) += pulse_tiecap.o
> \ No newline at end of file
Fix that.
> diff --git a/drivers/iio/pulse/pulse_tiecap.c
> b/drivers/iio/pulse/pulse_tiecap.c
> new file mode 100644
> index ..feec6078895d
> --- /dev/null
> +++ b/drivers/iio/pulse/pulse_tiecap.c
> @@ -0,0 +1,585 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +/*
> + * ECAP pulse capture driver
> + *
> + * Copyright (C) 2020 Linaro Limited
> + * Author: Matt Porter
> + * Author: Darren Schachter
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
No need to repeat the license text if you have SPDX header.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
Re: [PATCH v2] i2c: npcm7xx: bug fix timeout (usec instead of msec)
On Sun, Aug 30, 2020 at 3:21 PM Tali Perry wrote:
>
> i2c: npcm7xx: bug fix timeout (usec instead of msec)
>
> Signed-off-by: Tali Perry
Reviewed-by: Avi Fishman
> ---
> drivers/i2c/busses/i2c-npcm7xx.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-npcm7xx.c
> b/drivers/i2c/busses/i2c-npcm7xx.c
> index 75f07138a6fa..abb334492a3d 100644
> --- a/drivers/i2c/busses/i2c-npcm7xx.c
> +++ b/drivers/i2c/busses/i2c-npcm7xx.c
> @@ -2093,8 +2093,13 @@ static int npcm_i2c_master_xfer(struct i2c_adapter
> *adap, struct i2c_msg *msgs,
> }
> }
>
> - /* Adaptive TimeOut: astimated time in usec + 100% margin */
> - timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
> + /*
> +* Adaptive TimeOut: estimated time in usec + 100% margin:
> +* 2: double the timeout for clock stretching case
> +* 9: bits per transaction (including the ack/nack)
> +* 100: micro second in a second
> +*/
> + timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread +
> nwrite);
> timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
> if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
>
> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
> --
> 2.22.0
>
--
Regards,
Avi
Re: [PATCH v6 2/3] MAINTAINERS: Add Purism Librem 5 section to the list
On Fri, Aug 21, 2020 at 02:17:54PM +0200, Martin Kepplinger wrote: > Add development information for the devicetree files for hardware > by Purism SPC. > > Signed-off-by: Martin Kepplinger I decided to drop this patch from my queue, as I took the suggestion from Joe and sent a patch to have get_maintainer report email address in the dts file. Shawn [1] https://lkml.org/lkml/2020/8/30/118 > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ac79fdbdf8d0..70a09eb3e6d6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14061,6 +14061,13 @@ T: git git://linuxtv.org/media_tree.git > F: Documentation/admin-guide/media/pulse8-cec.rst > F: drivers/media/cec/usb/pulse8/ > > +PURISM LIBREM 5 > +M: Purism Kernel Team > +S: Supported > +B: https://source.puri.sm/Librem5/linux-next/issues > +T: https://source.puri.sm/Librem5/linux-next > +F: arch/arm64/boot/dts/freescale/imx8mq-librem5* > + > PVRUSB2 VIDEO4LINUX DRIVER > M: Mike Isely > L: pvru...@isely.net (subscribers-only) > -- > 2.20.1 >
[PATCH] veth: fix memory leak in veth_newlink()
when register_netdevice(dev) fails we should check whether struct veth_rq has been allocated via ndo_init callback and free it, because, depending on the code path, register_netdevice() might not call priv_destructor() callback Reported-and-tested-by: syzbot+59ef240dd8f0ed759...@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=59ef240dd8f0ed7598a8 Signed-off-by: Rustam Kovhaev --- drivers/net/veth.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/veth.c b/drivers/net/veth.c index a475f48d43c4..e40ca62a046a 100644 --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -1394,7 +1394,9 @@ static int veth_newlink(struct net *src_net, struct net_device *dev, return 0; err_register_dev: - /* nothing to do */ + priv = netdev_priv(dev); + if (priv->rq) + veth_dev_free(dev); err_configure_peer: unregister_netdevice(peer); return err; -- 2.28.0
Re: [PATCH v2] drm/vkms: add alpha-premultiplied color blending
Reviewed-by: Rodrigo Siqueira
On 08/25, Melissa Wen wrote:
> The VKMS blend function was ignoring the alpha channel and just
> overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a
> warning when running the kms_cursor_crc/cursor-alpha-transparent test
> case. In IGT, cairo_format_argb32 uses premultiplied alpha (according to
> documentation). Also current DRM assumption is that alpha is
> premultiplied. Therefore, this patch considers premultiplied alpha
> blending eq to compose vaddr_src with vaddr_dst.
>
> This change removes the following cursor-alpha-transparent warning:
> "Suspicious CRC: All values are 0."
>
> --
>
> v2:
> - static for local functions
> - const for the read-only variable argb_src
> - replaces variable names
> - drops unnecessary comment
>
> --
>
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 55
> 1 file changed, 39 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4f3b07a32b60..eaecc5a6c5db 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -32,8 +32,6 @@ static uint32_t compute_crc(void *vaddr_out, struct
> vkms_composer *composer)
> src_offset = composer->offset
>+ (i * composer->pitch)
>+ (j * composer->cpp);
> - /* XRGB format ignores Alpha channel */
> - bitmap_clear(vaddr_out + src_offset, 24, 8);
> crc = crc32_le(crc, vaddr_out + src_offset,
> sizeof(u32));
> }
> @@ -42,27 +40,51 @@ static uint32_t compute_crc(void *vaddr_out, struct
> vkms_composer *composer)
> return crc;
> }
>
> +static u8 blend_channel(u8 src, u8 dst, u8 alpha)
> +{
> + u32 pre_blend;
> + u8 new_color;
> +
> + pre_blend = (src * 255 + dst * (255 - alpha));
> +
> + /* Faster div by 255 */
> + new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8);
> +
> + return new_color;
> +}
> +
> +static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
> +{
> + u8 alpha;
> +
> + alpha = argb_src[3];
> + argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha);
> + argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha);
> + argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha);
> + /* Opaque primary */
> + argb_dst[3] = 0xFF;
> +}
> +
> /**
> * blend - blend value at vaddr_src with value at vaddr_dst
> * @vaddr_dst: destination address
> * @vaddr_src: source address
> - * @dest_composer: destination framebuffer's metadata
> + * @dst_composer: destination framebuffer's metadata
> * @src_composer: source framebuffer's metadata
> *
> - * Blend value at vaddr_src with value at vaddr_dst.
> - * Currently, this function write value of vaddr_src on value
> - * at vaddr_dst using buffer's metadata to locate the new values
> - * from vaddr_src and their destination at vaddr_dst.
> - *
> - * TODO: Use the alpha value to blend vaddr_src with vaddr_dst
> - *instead of overwriting it.
> + * Blend the vaddr_src value with the vaddr_dst value using the
> pre-multiplied
> + * alpha blending equation, since DRM currently assumes that the pixel color
> + * values have already been pre-multiplied with the alpha channel values. See
> + * more drm_plane_create_blend_mode_property(). This function uses buffer's
> + * metadata to locate the new composite values at vaddr_dst.
> */
> static void blend(void *vaddr_dst, void *vaddr_src,
> - struct vkms_composer *dest_composer,
> + struct vkms_composer *dst_composer,
> struct vkms_composer *src_composer)
> {
> int i, j, j_dst, i_dst;
> int offset_src, offset_dst;
> + u8 *pixel_dst, *pixel_src;
>
> int x_src = src_composer->src.x1 >> 16;
> int y_src = src_composer->src.y1 >> 16;
> @@ -77,15 +99,16 @@ static void blend(void *vaddr_dst, void *vaddr_src,
>
> for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> - offset_dst = dest_composer->offset
> - + (i_dst * dest_composer->pitch)
> - + (j_dst++ * dest_composer->cpp);
> + offset_dst = dst_composer->offset
> + + (i_dst * dst_composer->pitch)
> + + (j_dst++ * dst_composer->cpp);
> offset_src = src_composer->offset
>+ (i * src_composer->pitch)
>+ (j * src_composer->cpp);
>
> - memcpy(vaddr_dst + offset_dst,
> -
Re: [PATCH] arm64: dts: imx8mm-beacon-baseboard: Correct LED default state
On Mon, Aug 24, 2020 at 09:15:46AM +0200, Krzysztof Kozlowski wrote: > There is no LED default state "none". leds-gpio driver maps it to > "off", so correct them to fix dtbs_check warnings like: > > arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: > leds: led0:default-state:0: 'none' is not one of ['on', 'off', 'keep'] > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
[PATCH 01/33] ARM: dts: exynos: Silence i2c-gpio dtschema warning in Galaxy I9100
The name of I2C controller over GPIO lines node ends with '-gpio' which
confuses dtschema:
/arch/arm/boot/dts/exynos4210-i9100.dt.yaml: /: i2c-gpio:
{'compatible': ['i2c-gpio'], ... 'maxim,over-volt': [[4500]]}} is not of
type 'array'
From schema:
lib/python3.6/site-packages/dtschema/schemas/gpio/gpio-consumer.yaml
Add a '-0' suffix to silence it. This pattern on naming i2c-gpio is
already present in many other dts. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-i9100.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts
b/arch/arm/boot/dts/exynos4210-i9100.dts
index 6d0c04d77a39..3eb11cc2c3c5 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -123,7 +123,7 @@
reset-gpios = <&gpl1 2 GPIO_ACTIVE_LOW>;
};
- i2c_max17042_fuel: i2c-gpio {
+ i2c_max17042_fuel: i2c-gpio-0 {
compatible = "i2c-gpio";
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1
[PATCH 02/33] ARM: dts: exynos: Correct GPU regulator properties in Galaxy I9100
The regulator property 'regulator-microvolt-offset' should be put next
to regulator definition, not consumer.
The property 'regulator-microsecs-delay' is not valid at all.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-i9100.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts
b/arch/arm/boot/dts/exynos4210-i9100.dts
index 3eb11cc2c3c5..6fa57d1fa1d7 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -304,8 +304,6 @@
status = "okay";
mali-supply = <&vg3d_breg>;
- regulator-microvolt-offset = <5>;
- regulator-microsecs-delay = <50>;
};
&hsotg {
@@ -524,6 +522,7 @@
regulator-name = "G3D_1.1V";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <120>;
+ regulator-microvolt-offset = <5>;
regulator-always-on;
};
--
2.17.1
[PATCH 03/33] ARM: dts: exynos: Correct S3C RTC bindings and enable it in Galaxy I9100
The S3C RTC requires 32768 Hz clock as input which is provided by PMIC
(Maxim MAX8997). However there is no clock provided for the PMIC and
the driver registers the clock as regulator. This is an old driver
which will not be updated so add a workaround:
1. Enable the "clock" regulator in PMIC,
2. Add a fixed-clock to fill missing clock phandle reference in S3C RTC.
This allows to enable the S3C RTC and fixes dtbs_check warnings:
arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rtc@1007: clocks: [[5, 346]]
is too short
arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rtc@1007: clock-names:
['rtc'] is too short
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-i9100.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts
b/arch/arm/boot/dts/exynos4210-i9100.dts
index 6fa57d1fa1d7..d63274c8539d 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -209,6 +209,13 @@
compatible = "samsung,clock-xusbxti";
clock-frequency = <2400>;
};
+
+ pmic_ap_clk: pmic-ap-clk {
+ /* Workaround for missing clock on max8997 PMIC */
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
};
thermal-zones {
@@ -568,6 +575,11 @@
regulator-max-microvolt = <410>;
regulator-always-on;
};
+
+ EN32KHZ_AP {
+ regulator-name = "EN32KHZ_AP";
+ regulator-always-on;
+ };
};
};
};
@@ -688,6 +700,12 @@
};
};
+&rtc {
+ status = "okay";
+ clocks = <&clock CLK_RTC>, <&pmic_ap_clk>;
+ clock-names = "rtc", "rtc_src";
+};
+
&sdhci_0 {
status = "okay";
--
2.17.1
[PATCH 04/33] ARM: dts: exynos: Correct S3C RTC bindings and enable it in Origen
The S3C RTC requires 32768 Hz clock as input which is provided by PMIC
(Maxim MAX8997). However there is no clock provided for the PMIC and
the driver registers the clock as regulator. This is an old driver
which will not be updated so add a workaround:
1. Enable the "clock" regulator in PMIC,
2. Add a fixed-clock to fill missing clock phandle reference in S3C RTC.
This allows to enable the S3C RTC and fixes dtbs_check warnings:
arch/arm/boot/dts/exynos4210-origen.dt.yaml: rtc@1007: clocks: [[5, 346]]
is too short
arch/arm/boot/dts/exynos4210-origen.dt.yaml: rtc@1007: clock-names:
['rtc'] is too short
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-origen.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 890525b10d22..747221bbb856 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -100,6 +100,13 @@
compatible = "samsung,clock-xusbxti";
clock-frequency = <2400>;
};
+
+ pmic_ap_clk: pmic-ap-clk {
+ /* Workaround for missing clock on max8997 PMIC */
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
};
display-timings {
@@ -286,6 +293,11 @@
regulator-boot-on;
regulator-always-on;
};
+
+ EN32KHZ_AP {
+ regulator-name = "EN32KHZ_AP";
+ regulator-always-on;
+ };
};
};
};
@@ -331,6 +343,8 @@
&rtc {
status = "okay";
+ clocks = <&clock CLK_RTC>, <&pmic_ap_clk>;
+ clock-names = "rtc", "rtc_src";
};
&tmu {
--
2.17.1
[PATCH 10/33] ARM: dts: exynos: Add and enable 32 kHz modem clock in Trats
The PMIC has a 32768 Hz clock used by the modem which is implemented by
driver as a regulator. Add and enable it to be sure modem get's its
signal.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-trats.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 634f009b622e..0f3af293d9d3 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -456,6 +456,11 @@
regulator-name = "EN32KHZ_AP";
regulator-always-on;
};
+
+ EN32KHZ_CP {
+ regulator-name = "EN32KHZ_CP";
+ regulator-always-on;
+ };
};
};
};
--
2.17.1
[PATCH 11/33] ARM: dts: exynos: Remove empty camera pinctrl configuration in Trats
The camera's pinctrl configuration is simply empty and not effective.
Remove it to fix dtbs_check warning:
arch/arm/boot/dts/exynos4210-trats.dt.yaml: camera: pinctrl-0: True is not of
type 'array'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-trats.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 0f3af293d9d3..33b40f619dea 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -159,8 +159,6 @@
};
&camera {
- pinctrl-names = "default";
- pinctrl-0 = <>;
status = "okay";
};
--
2.17.1
[PATCH 17/33] ARM: dts: exynos: Override thermal by label in Galaxy I9000
Using full paths to extend or override a device tree node is error prone
since if there was a typo error, a new node will be created instead of
extending the node as it was desired. This will lead to run-time errors
that could be hard to detect.
A mistyped label on the other hand, will cause a dtc compile error
(during build time).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-i9100.dts | 28 --
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts
b/arch/arm/boot/dts/exynos4210-i9100.dts
index 5623e17889a5..799b69e1a93a 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -217,21 +217,6 @@
clock-frequency = <32768>;
};
};
-
- thermal-zones {
- cpu_thermal: cpu-thermal {
- cooling-maps {
- map0 {
- /* Corresponds to 800MHz */
- cooling-device = <&cpu0 2 2>;
- };
- map1 {
- /* Corresponds to 200MHz */
- cooling-device = <&cpu0 4 4>;
- };
- };
- };
- };
};
&camera {
@@ -242,6 +227,19 @@
cpu0-supply = <&varm_breg>;
};
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ /* Corresponds to 800MHz */
+ cooling-device = <&cpu0 2 2>;
+ };
+ map1 {
+ /* Corresponds to 200MHz */
+ cooling-device = <&cpu0 4 4>;
+ };
+ };
+};
+
&ehci {
status = "okay";
--
2.17.1
[PATCH 13/33] ARM: dts: exynos: Align SPI GPIO node name with dtschema in Universal C210
The device tree schema expects SPI controller to be named "spi",
otherwise dtbs_check complain with a warning like:
arch/arm/boot/dts/exynos4210-universal_c210.dt.yaml: spi-lcd:
$nodename:0: 'spi-lcd' does not match '^spi(@.*|-[0-9a-f])*$'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 7c83ce019b44..3509fdf8f245 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -119,7 +119,7 @@
enable-active-high;
};
- spi-lcd {
+ spi-3 {
compatible = "spi-gpio";
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1
[PATCH 18/33] ARM: dts: exynos: Override thermal by label in Trats
Using full paths to extend or override a device tree node is error prone
since if there was a typo error, a new node will be created instead of
extending the node as it was desired. This will lead to run-time errors
that could be hard to detect.
A mistyped label on the other hand, will cause a dtc compile error
(during build time).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-trats.dts | 29 --
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 33b40f619dea..75483e08b4b4 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -140,22 +140,6 @@
clock-frequency = <32768>;
};
};
-
- thermal-zones {
- cpu_thermal: cpu-thermal {
- cooling-maps {
- map0 {
-/* Corresponds to 800MHz at freq_table */
-cooling-device = <&cpu0 2 2>, <&cpu1 2 2>;
- };
- map1 {
-/* Corresponds to 200MHz at freq_table */
-cooling-device = <&cpu0 4 4>, <&cpu1 4 4>;
- };
- };
- };
- };
-
};
&camera {
@@ -166,6 +150,19 @@
cpu0-supply = <&varm_breg>;
};
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ /* Corresponds to 800MHz at freq_table */
+ cooling-device = <&cpu0 2 2>, <&cpu1 2 2>;
+ };
+ map1 {
+ /* Corresponds to 200MHz at freq_table */
+ cooling-device = <&cpu0 4 4>, <&cpu1 4 4>;
+ };
+ };
+};
+
&dsi_0 {
vddcore-supply = <&vusb_reg>;
vddio-supply = <&vmipi_reg>;
--
2.17.1
