Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote: > I started using devm_kcalloc() but at least two reviewers convinced me > to just use kcalloc(). In addition, when I was using devm_kcalloc() > it was awkward because 'dev' is not available to this function. > > It comes down to whether unbind/binding the device N times is actually > a reasonable usage. As for my experience I've seen two cases: (1) my > overnight "bind/unbind the PCIe RC driver" script, and we have a > customer who does an unbind/bind as a hail mary to bring back life to > their dead EP device. If the latter case happens repeatedly, there > are bigger problems. We can't just leak the allocations. Do you have a pointer to the arguments against managed resources? I'm generally not a huge fan of the managed resources, but for a case like this they actually seem useful. If we don't use the managed resources we'll at leat need to explicitly free the resources when freeing the device. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: qlge: qlge_dbg: removed comment repition
> > A: http://en.wikipedia.org/wiki/Top_post > Q: Were do I find info about this thing called top-posting? > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > I will avoid such things and will do useful stuff. > > It has been less than 24 hours for a simple comment cleanup patch. > Please give maintainers time, they deal with thousands of patches a > week. > > Usually, if after 2 weeks, you have not gotten a response, you can > resend it. > > > I know that I should ask for reviews etc after a week but the change > > is for my eudyptula task and until it doesn't get merged little > > penguin will not pass the task for me so please look at it. > > If you knew that you should wait for at least a week, and yet you did > not, that implies that you somehow feel this comment cleanup patch is > more important than everyone else, which is a bit rude, don't you think? > > There are no such things as deadlines when it comes to upstream kernel > development, sorry. > Alright, I will wait and hope it gets accepted before 1st August or else I have patience. Thank You Dhiraj Sharma ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: qlge: qlge_dbg: removed comment repition
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Jul 29, 2020 at 11:06:56AM +0530, Dhiraj Sharma wrote: > Hello, It has been less than 24 hours for a simple comment cleanup patch. Please give maintainers time, they deal with thousands of patches a week. Usually, if after 2 weeks, you have not gotten a response, you can resend it. > I know that I should ask for reviews etc after a week but the change > is for my eudyptula task and until it doesn't get merged little > penguin will not pass the task for me so please look at it. If you knew that you should wait for at least a week, and yet you did not, that implies that you somehow feel this comment cleanup patch is more important than everyone else, which is a bit rude, don't you think? There are no such things as deadlines when it comes to upstream kernel development, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: qlge: qlge_dbg: removed comment repition
Hello, I know that I should ask for reviews etc after a week but the change is for my eudyptula task and until it doesn't get merged little penguin will not pass the task for me so please look at it. Thank You Dhiraj Sharma On Tue, Jul 28, 2020 at 11:56 PM Dhiraj Sharma wrote: > > Inside function ql_get_dump comment statement had a repition of word > "to" which I removed and checkpatch.pl ouputs zero error or warnings > now. > > Signed-off-by: Dhiraj Sharma > --- > drivers/staging/qlge/qlge_dbg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/qlge/qlge_dbg.c b/drivers/staging/qlge/qlge_dbg.c > index 985a6c341294..a55bf0b3e9dc 100644 > --- a/drivers/staging/qlge/qlge_dbg.c > +++ b/drivers/staging/qlge/qlge_dbg.c > @@ -1298,7 +1298,7 @@ void ql_get_dump(struct ql_adapter *qdev, void *buff) > * If the dump has already been taken and is stored > * in our internal buffer and if force dump is set then > * just start the spool to dump it to the log file > -* and also, take a snapshot of the general regs to > +* and also, take a snapshot of the general regs > * to the user's buffer or else take complete dump > * to the user's buffer if force is not set. > */ > -- > 2.17.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS 11536442a3b4e1de6890ea5e805908debb74f94a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: 11536442a3b4e1de6890ea5e805908debb74f94a Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode elapsed time: 1217m configs tested: 48 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: nxp imx8m CSI drivers
Hi Martin, On Tue, Jul 28, 2020 at 12:36:58PM +0200, Martin Kepplinger wrote: > On 09.07.20 11:32, Martin Kepplinger wrote: > > hi linux-media people, > > > > TL-DR: when exactly is "sd->entity.function == MEDIA_ENT_F_VID_MUX"? > > > > > > I try to use the camera on our librem5-devkit (imx8mq): I try to use > > only mainline drivers except for "mxc-mipi-csi2_yav" taken from > > linux-imx (which we can prepare to submit if a PoC works. This is the > > tree I'm experimenting with: > > > > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc4/librem5___csi > > > > * "imx7-media-csi" / imx-media-capture / imx-media-utils currently in > > staging (that should work according to NXP) > > * ov5640 mainline driver > > * mxc-mipi-csi2_yav from NXP tree (linux-imx) with > > v4l2_subdev_video_ops' mipi_csis_g_parm and mipi_csis_s_parm callbacks > > removed (due to missing API in mainline) > > > > the drivers probe and run but the following fails when trying to use the > > camera (gstreamer): > > > > in imx-media-utils' imx_media_pipeline_set_stream() the call to > > v4l2_subdev_call(sd, video, s_stream, 1) returns with 32 (broken pipe) > > and thus the application that tries to use the camera too. > > > > One problem is definitely the trees' last commit (that I did as a > > workaround) in this tree that makes the drivers probe but only by > > ignoring this probably needed check: > > > > imx7-media-csi's imx7_csi_notify_bound() callback implementation gets > > called during startup. But if (WARN_ON(sd->entity.function != > > MEDIA_ENT_F_VID_MUX)) is true so this is the wrong type of subdev (?). > > > > I just want to put this out there and check if the general approach is > > valid at all and if there's anything that comes to your mind. > > (added Pavel Machek) > > still I'm only on the librem5 Devkit: the situation regarding a tree > that should use the imx7-media-csi csi_bridge driver hasn't changed, see > above for the details. The tree I tried now is this one: > > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc7/librem5___csi_ml1 > > A tree that includes NXP's csi_bridge and mipi-csi drivers (and camera > driver) on the other hand works, and I have one based on v5.8-rcX too: > > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc7/librem5___csi_nxp > > Since I want to look into a different camera driver, I might use that > nxp-drivers tree to work on that, but our goal is obviously to use what > is already in staging and should work (the csi bridge driver at least). > In case you know more about the v4l2 details that don't match over > there, please have a look. For what it's worth, I'm debugging a complete system memory corruption with the imx staging camera driver on an i.MX7D, on v5.8-rc6. The issue didn't occur on v5.7. I however have a fairly large number of custom patches that I'm in the process of upstreaming on top of mainline for that driver, so I can't tell yet whether the problem is in my code or in v5.8-rc6. I haven't been able to use the staging driver as-is, neither on v5.7 nor on v5.8-rc6, with the camera sensor I'm working with (a Sony IMX296). I also get an EPIPE (32) error. Seems there's a reason why this driver is in staging :-) This however makes debugging more difficult as I can't test v5.8-rc6 without my custom changes. As for MEDIA_ENT_F_VID_MUX, the check is about verifying that the device connected directly to the input of the CSI (*not* MIPI CSI2) is the video mux that selects between the MIPI CSI2 receiver and the parallel sensor input. On i.MX7D, this models the "CSI Input MUX Control" bit in register IOMUXC_GPR_GPR5. On i.MX8M, there seems to be no such mux, as there seems to be no parallel sensor input. It should thus be safe to drop the check, but other adjustements to the routing and pipeline configuration logic in the driver will likely be needed. -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging : iio : Fixed a punctuation and a spelling mistake.
Added a missing comma and changed 'it it useful' to 'it is useful'. Signed-off-by: Ankit Baluni --- drivers/staging/iio/Documentation/overview.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/Documentation/overview.txt b/drivers/staging/iio/Documentation/overview.txt index ebdc64f451d7..00409d5dab4e 100644 --- a/drivers/staging/iio/Documentation/overview.txt +++ b/drivers/staging/iio/Documentation/overview.txt @@ -9,7 +9,7 @@ The aim is to fill the gap between the somewhat similar hwmon and input subsystems. Hwmon is very much directed at low sample rate sensors used in applications such as fan speed control and temperature measurement. Input is, as its name suggests focused on input -devices. In some cases there is considerable overlap between these and +devices. In some cases, there is considerable overlap between these and IIO. A typical device falling into this category would be connected via SPI @@ -38,7 +38,7 @@ series and Analog Devices ADXL345 accelerometers. Each buffer supports polling to establish when data is available. * Trigger and software buffer support. In many data analysis -applications it it useful to be able to capture data based on some +applications it is useful to be able to capture data based on some external signal (trigger). These triggers might be a data ready signal, a gpio line connected to some external system or an on processor periodic interrupt. A single trigger may initialize data -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging : media : atomisp : fixed a brace coding sytle issue
From: Ankit Baluni
Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.
Signed-off-by: Ankit Baluni
---
Changes in v2:
-Added more description about the patch.
-Added space before the symobol '<' in 'From'
and 'Signed-off-by' line.
drivers/staging/media/atomisp/pci/atomisp_cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 8ea65bef35d2..28b96b66f4f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -4981,9 +4981,8 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device
*isp,
case ATOMISP_CAMERA_PORT_SECONDARY:
return MIPI_PORT1_ID;
case ATOMISP_CAMERA_PORT_TERTIARY:
- if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID) {
+ if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID)
return MIPI_PORT1_ID + 1;
- }
/* fall through */
default:
dev_err(isp->dev, "unsupported port: %d\n", port);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ashmem: used const keyword
On Tue, 2020-07-28 at 23:29 +0530, Dhiraj Sharma wrote:
> I ran checkpatch.pl script which reported a warning to use const keyword
> on line 370.Therefore I made this change.
checkpatch is a brainless script.
Not everything it suggests is appropriate.
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c
[]
> @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file,
> unsigned long addr,
>
> static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
This can't work.
Please make sure to compile your proposed changes
_before_ you post them.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Hi Christoph,
On Tue, Jul 28, 2020 at 8:33 AM Christoph Hellwig wrote:
>
> A few tiny nitpicks:
>
> The subject should have the dma-mapping prefix, this doesn't
> really touch the device core.
>
> > - rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
> > + rc = of_dma_get_range(np, &map);
> > + rc = PTR_ERR_OR_ZERO(map);
>
> I don't think you need the PTR_ERR_OR_ZERO line here, of_dma_get_range
> returns the error.
Yes, that link needs to be deleted.
>
> > +int dma_set_offset_range(struct device *dev, phys_addr_t cpu_start,
> > + dma_addr_t dma_start, u64 size)hh
> > +{
> > + struct bus_dma_region *map;
> > + u64 offset = (u64)cpu_start - (u64)dma_start;
> > +
> > + if (!dev)
> > + return -ENODEV;
>
> I don't think we need the NULL protection here, all DMA API calls
> expect a device.
Yes, your review-patch removed it but left the comment about the
function returning -ENODEV. So I wasn't sure to leave it in or not.
>
> > + if (!offset)
> > + return 0;
> > +
> > + /*
> > + * See if a map already exists and we already encompass the new range:
> > + */
> > + if (dev->dma_range_map) {
> > + if (dma_range_overlaps(dev, cpu_start, dma_start, size,
> > offset))
> > + return 0;
> > + dev_err(dev, "attempt to add conflicting DMA range to
> > existing map\n");
> > + return -EINVAL;
> > + }
>
> And here why do we need the overlap check at all? I'd be tempted to
> always return an error for this case.
I believe the overlap check was your suggestion or at least in your
review-patch? I'm fine with just returning an error.
>
> What is the plan to merge this? Do you want all this to go into one
> tree, or get as many bits into the applicable trees for 5.9 and then
> finish up for 5.10? If the former I can apply it to the dma-mapping
> tree and just fix up the nitpicks.
Whatever you think is best -- I would be quite happy if you could
accept at least the "dma_range_map" commit. Of course I'd be most
happy if the entire patchset were accepted, but perhaps you can just
apply the "dma_range_map" commit, and I will continue to bang away at
getting the N-1 PCIe-related commits ack'd and accepted.
Thanks much!
Jim Quinlan
Broadcom STB
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Tue, Jul 28, 2020 at 11:05 AM Rob Herring wrote:
>
> On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan
> wrote:
> >
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> > capable of holding a single uniform offset and had no region bounds
> > checking.
> >
> > The function of_dma_get_range() has been modified so that it takes a single
> > argument -- the device node -- and returns a map, NULL, or an error code.
> > The map is an array that holds the information regarding the DMA regions.
> > Each range entry contains the address offset, the cpu_start address, the
> > dma_start address, and the size of the region.
> >
> > of_dma_configure() is the typical manner to set range offsets but there are
> > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> > driver code. These cases now invoke the function
> > dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
> >
> > Signed-off-by: Jim Quinlan
> > ---
>
> [...]
>
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 8eea3f6e29a4..4b718d199efe 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct
> > device_node *np, int index,
> > }
> > EXPORT_SYMBOL(of_io_request_and_map);
> >
> > +#ifdef CONFIG_HAS_DMA
> > /**
> > - * of_dma_get_range - Get DMA range info
> > + * of_dma_get_range - Get DMA range info and put it into a map array
> > * @np:device node to get DMA range info
> > - * @dma_addr: pointer to store initial DMA address of DMA range
> > - * @paddr: pointer to store initial CPU address of DMA range
> > - * @size: pointer to store size of DMA range
> > + * @map: dma range structure to return
> > *
> > * Look in bottom up direction for the first "dma-ranges" property
> > - * and parse it.
> > - * dma-ranges format:
> > + * and parse it. Put the information into a DMA offset map array.
> > + *
> > + * dma-ranges format:
> > * DMA addr (dma_addr) : naddr cells
> > * CPU addr (phys_addr_t) : pna cells
> > * size: nsize cells
> > *
> > - * It returns -ENODEV if "dma-ranges" property was not found
> > - * for this device in DT.
> > + * It returns -ENODEV if "dma-ranges" property was not found for this
> > + * device in the DT.
> > */
> > -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr,
> > u64 *size)
> > +int of_dma_get_range(struct device_node *np, const struct bus_dma_region
> > **map)
> > {
> > struct device_node *node = of_node_get(np);
> > const __be32 *ranges = NULL;
> > - int len;
> > - int ret = 0;
> > bool found_dma_ranges = false;
> > struct of_range_parser parser;
> > struct of_range range;
> > - u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> > + struct bus_dma_region *r;
> > + int len, num_ranges = 0;
> > + int ret;
> >
> > while (node) {
> > ranges = of_get_property(node, "dma-ranges", &len);
> > @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64
> > *dma_addr, u64 *paddr, u64 *siz
> > }
> >
> > of_dma_range_parser_init(&parser, node);
> > + for_each_of_range(&parser, &range)
> > + num_ranges++;
> > +
> > + of_dma_range_parser_init(&parser, node);
> > +
> > + ret = -ENOMEM;
> > + r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> > + if (!r)
> > + goto out;
>
> AFAICT, you have the error cases covered, but you are leaking memory
> if the device is removed.
Hi Rob,
I started using devm_kcalloc() but at least two reviewers convinced me
to just use kcalloc(). In addition, when I was using devm_kcalloc()
it was awkward because 'dev' is not available to this function.
It comes down to whether unbind/binding the device N times is actually
a reasonable usage. As for my experience I've seen two cases: (1) my
overnight "bind/unbind the PCIe RC driver" script, and we have a
customer who does an unbind/bind as a hail mary to bring back life to
their dead EP device. If the latter case happens repeatedly, there
are bigger problems.
>
>
> [...]
>b
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> > b/drivers/remoteproc/remoteproc_core.c
> > index 9f04c30c4aaf..49242dd6176e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc,
> > struct fw_rsc_vdev *rsc,
> > /* Initialise vdev subdevice */
> > snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> > rvdev->dev.parent = &rproc->dev;
> > - rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> > + rvdev->
[driver-core:debugfs_cleanup] BUILD SUCCESS e82507d326d05747a5fdea6065e99f5332b63ecd
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup branch HEAD: e82507d326d05747a5fdea6065e99f5332b63ecd debugfs: remove return value of debugfs_create_devm_seqfile() elapsed time: 1848m configs tested: 48 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging : rtl8712 : Fixed a coding sytle issue
Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.
Signed-off-by: Ankit Baluni
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c6f6ccd060bb..df6ae855f3c1 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -238,9 +238,8 @@ static char *translate_scan(struct _adapter *padapter,
/* parsing HT_CAP_IE */
p = r8712_get_ie(&pnetwork->network.IEs[12], _HT_CAPABILITY_IE_,
&ht_ielen, pnetwork->network.IELength - 12);
- if (p && ht_ielen > 0) {
+ if (p && ht_ielen > 0)
ht_cap = true;
- }
/* Add the protocol name */
iwe.cmd = SIOCGIWNAME;
if (r8712_is_cckratesonly_included(pnetwork->network.rates)) {
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:driver-core-testing] BUILD SUCCESS eea2c51f81df9df5123c042f07c7c6c33bf5fabb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-testing branch HEAD: eea2c51f81df9df5123c042f07c7c6c33bf5fabb Merge 5.8-rc7 into driver-core-next elapsed time: 1776m configs tested: 55 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm defconfig arm allyesconfig arm allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20200727 i386 randconfig-a016-20200727 i386 randconfig-a013-20200727 i386 randconfig-a012-20200727 i386 randconfig-a015-20200727 i386 randconfig-a011-20200727 i386 randconfig-a014-20200727 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 kexec x86_64 rhel-8.3 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/4] staging: rtl8723bs: include: Further clean up function declarations
On Sun, Jul 26, 2020 at 11:45 PM Aditya Jain wrote: > > On Sun, Jul 26, 2020 at 10:45 PM Joe Perches wrote: > > > > On Sun, 2020-07-26 at 17:02 +0200, Greg KH wrote: > > > On Sun, Jul 26, 2020 at 07:50:12PM +0530, Aditya Jain wrote: > > > > Cleaning up messy multiline function declarations in hal_phy_cfg.h > > [] > > > > diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h > > > > b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h > > [] > Ok, I'll merge this patch with the previous one. Had separated the two > to make the diffs smaller thinking they'll > be easier to review. But yeah, I get the point. > > > > -void > > > > -PHY_SetSwChnlBWMode8723B( > > > > -struct adapter *Adapter, > > > > -u8 channel, > > > > -enum CHANNEL_WIDTH Bandwidth, > > > > -u8 Offset40, > > > > -u8 Offset80 > > > > +void PHY_SetBWMode8723B(struct adapter *Adapter, > > > > + enum CHANNEL_WIDTH Bandwidth, /* 20M or 40M */ > > > > + unsigned char Offset/* Upper, Lower, or Don't > > > > care */ > > > > > > Those comments should go at the top of the function declaration, in > > > kernel doc format. > > > > Not every external function needs kernel-doc. > > > > This is a realtek staging driver that likely it will never be > > moved out of staging. > > > > > Should I just remove the comments then? Sorry, but I'm a newbie, and > not really sure what the function is or supposed to do. > I can try looking it up if kernel-doc is required here. Hi all, Any directions on how I should continue? > > Regards, > Aditya Jain Thanks and Regards, Aditya Jain ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] binder: Prevent context manager from incrementing ref 0
Thanks a lot for the detailed explanation, I understood now.
Martijn
On Tue, Jul 28, 2020 at 4:50 PM Jann Horn wrote:
>
> On Tue, Jul 28, 2020 at 3:50 PM Martijn Coenen wrote:
> > On Mon, Jul 27, 2020 at 2:04 PM Jann Horn wrote:
> > > - task B opens /dev/binder once, creating binder_proc instance P3
> > > - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
> > >transaction)
> > > - P2 receives the handle and uses it to call P3 (two-way transaction)
> > > - P3 calls P2 (via magic handle 0) (two-way transaction)
> > > - P2 calls P2 (via handle 1) (two-way transaction)
> >
> > Why do you need P3 involved at all? Could P2 just straight away make a
> > call on handle 1?
>
> Yes, it could, I think. IIRC these steps are necessary if you want to
> actually get a KASAN splat, instead of just a transaction-to-self with
> no further consequences. It has been a while since I looked at this,
> but I'll try to figure out again what was going on...
>
>
> A UAF occurs in the following code due to the transaction-to-self,
> because the "if (t->to_thread == thread)" is tricked into believing
> that the transaction has already been accepted.
>
> static int binder_thread_release(struct binder_proc *proc,
> struct binder_thread *thread)
> {
> struct binder_transaction *t;
> struct binder_transaction *send_reply = NULL;
> [...]
> t = thread->transaction_stack;
> if (t) {
> [...]
> if (t->to_thread == thread)
> send_reply = t;
> } else {
> [...]
> }
> [...]
> //NOTE: transaction is freed here because top-of-stack is
> // wrongly treated as already-accepted incoming transaction)
> if (send_reply)
> binder_send_failed_reply(send_reply, BR_DEAD_REPLY);
> //NOTE pending transaction work is processed here (transaction has not
> // yet been accepted)
> binder_release_work(proc, &thread->todo);
> [...]
> }
>
> An unaccepted transaction will only have a non-NULL ->to_thread if the
> transaction has a specific target thread; for a non-reply transaction,
> that is only the case if it is a two-way transaction that was sent
> while the binder call stack already contained the target task (iow,
> the transaction looks like a synchronous callback invocation).
>
> With the steps:
>
> - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
>transaction)
> - P2 receives the handle and uses it to call P3 (two-way transaction)
> - P3 calls P2 (via magic handle 0) (two-way transaction)
> - P2 calls P2 (via handle 1) (two-way transaction)
>
> the call stack will look like this:
>
> P3 -> P2 -> P3 -> P2 -> P2
>
> The initial call from P3 to P2 was IIRC just to give P2 a handle to
> P3; IIRC the relevant part of the call stack was:
>
> P2 -> P3 -> P2 -> P2
>
> Because P2 already occurs down in the call stack, the final
> transaction "P2 -> P2" is considered to be a callback and is
> thread-directed.
>
>
> The reason why P3 has to be created from task B is the "if
> (target_node && target_proc->pid == proc->pid)" check for transactions
> to reference 0.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ashmem: used const keyword
Alright, I have understood now that I should not trust on
checkpatch.pl script fully but partially it is indeed helpful. Please
don't criticize this script, it was my fault instead.
Before submitting code changes I would test them all, sorry for
wasting your time please ignore this patch changes now.
I will not commit such foolish mistakes now.
Thank you
Dhiraj Sharma
On Tue, Jul 28, 2020 at 11:55 PM Greg KH wrote:
>
> On Tue, Jul 28, 2020 at 11:29:35PM +0530, Dhiraj Sharma wrote:
> > I ran checkpatch.pl script which reported a warning to use const keyword
> > on line 370.Therefore I made this change.
> >
> > Signed-off-by: Dhiraj Sharma
> > ---
> > drivers/staging/android/ashmem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/android/ashmem.c
> > b/drivers/staging/android/ashmem.c
> > index c05a214191da..f9cfa15b785f 100644
> > --- a/drivers/staging/android/ashmem.c
> > +++ b/drivers/staging/android/ashmem.c
> > @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file,
> > unsigned long addr,
> >
> > static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> > {
> > - static struct file_operations vmfile_fops;
> > + static const struct file_operations vmfile_fops;
>
> You have now submitted two patches that you obviously never even built,
> which is the first step in kernel development :(
>
> Please be more careful next time.
>
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: qlge: qlge_dbg: removed comment repition
Inside function ql_get_dump comment statement had a repition of word "to" which I removed and checkpatch.pl ouputs zero error or warnings now. Signed-off-by: Dhiraj Sharma --- drivers/staging/qlge/qlge_dbg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/qlge/qlge_dbg.c b/drivers/staging/qlge/qlge_dbg.c index 985a6c341294..a55bf0b3e9dc 100644 --- a/drivers/staging/qlge/qlge_dbg.c +++ b/drivers/staging/qlge/qlge_dbg.c @@ -1298,7 +1298,7 @@ void ql_get_dump(struct ql_adapter *qdev, void *buff) * If the dump has already been taken and is stored * in our internal buffer and if force dump is set then * just start the spool to dump it to the log file -* and also, take a snapshot of the general regs to +* and also, take a snapshot of the general regs * to the user's buffer or else take complete dump * to the user's buffer if force is not set. */ -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ashmem: used const keyword
On Tue, Jul 28, 2020 at 11:29:35PM +0530, Dhiraj Sharma wrote:
> I ran checkpatch.pl script which reported a warning to use const keyword
> on line 370.Therefore I made this change.
>
> Signed-off-by: Dhiraj Sharma
> ---
> drivers/staging/android/ashmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c
> index c05a214191da..f9cfa15b785f 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file,
> unsigned long addr,
>
> static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
You have now submitted two patches that you obviously never even built,
which is the first step in kernel development :(
Please be more careful next time.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android: ashmem: used const keyword
I ran checkpatch.pl script which reported a warning to use const keyword
on line 370.Therefore I made this change.
Signed-off-by: Dhiraj Sharma
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index c05a214191da..f9cfa15b785f 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, unsigned
long addr,
static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
{
- static struct file_operations vmfile_fops;
+ static const struct file_operations vmfile_fops;
struct ashmem_area *asma = file->private_data;
int ret = 0;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] binder: Prevent context manager from incrementing ref 0
Thanks Jann, the change LGTM, one question on the repro scenario that
wasn't immediately obvious to me:
On Mon, Jul 27, 2020 at 2:04 PM Jann Horn wrote:
> - task B opens /dev/binder once, creating binder_proc instance P3
> - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
>transaction)
> - P2 receives the handle and uses it to call P3 (two-way transaction)
> - P3 calls P2 (via magic handle 0) (two-way transaction)
> - P2 calls P2 (via handle 1) (two-way transaction)
Why do you need P3 involved at all? Could P2 just straight away make a
call on handle 1?
>
> And then, if P2 does *NOT* accept the incoming transaction work, but
> instead closes the binder fd, we get a crash.
>
> Solve it by preventing the context manager from using ACQUIRE on ref 0.
> There shouldn't be any legitimate reason for the context manager to do
> that.
>
> Additionally, print a warning if someone manages to find another way to
> trigger a transaction-to-self bug in the future.
>
> Cc: sta...@vger.kernel.org
> Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
> Acked-by: Todd Kjos
Reviewed-by: Martijn Coenen
> Signed-off-by: Jann Horn
> ---
> fixed that broken binder_user_error() from the first version...
> I sent v1 while I had a dirty tree containing the missing fix. whoops.
>
> drivers/android/binder.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index f50c5f182bb5..5b310eea9e52 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2982,6 +2982,12 @@ static void binder_transaction(struct binder_proc
> *proc,
> goto err_dead_binder;
> }
> e->to_node = target_node->debug_id;
> + if (WARN_ON(proc == target_proc)) {
> + return_error = BR_FAILED_REPLY;
> + return_error_param = -EINVAL;
> + return_error_line = __LINE__;
> + goto err_invalid_target_handle;
> + }
> if (security_binder_transaction(proc->tsk,
> target_proc->tsk) < 0) {
> return_error = BR_FAILED_REPLY;
> @@ -3635,10 +3641,17 @@ static int binder_thread_write(struct binder_proc
> *proc,
> struct binder_node *ctx_mgr_node;
> mutex_lock(&context->context_mgr_node_lock);
> ctx_mgr_node =
> context->binder_context_mgr_node;
> - if (ctx_mgr_node)
> + if (ctx_mgr_node) {
> + if (ctx_mgr_node->proc == proc) {
> + binder_user_error("%d:%d
> context manager tried to acquire desc 0\n",
> + proc->pid,
> thread->pid);
> +
> mutex_unlock(&context->context_mgr_node_lock);
> + return -EINVAL;
> + }
> ret = binder_inc_ref_for_node(
> proc, ctx_mgr_node,
> strong, NULL, &rdata);
> + }
> mutex_unlock(&context->context_mgr_node_lock);
> }
> if (ret)
>
> base-commit: 2a89b99f580371b86ae9bafd6cbeccd3bfab524a
> --
> 2.28.0.rc0.142.g3c755180ce-goog
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
Hi Dhiraj, Thank you for the patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on staging/staging-testing soc/for-next v5.8-rc7 next-20200728] [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/Dhiraj-Sharma/media-usbvision-fixed-coding-style/20200728-223404 base: git://linuxtv.org/media_tree.git master config: x86_64-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 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/staging/media/usbvision/usbvision-video.c:157:56: error: macro >> "DEVICE_ATTR_RO" passed 4 arguments, but takes just 1 157 | static DEVICE_ATTR_RO(version, 0444, version_show, NULL); |^ In file included from include/linux/acpi.h:15, from include/linux/i2c.h:13, from drivers/staging/media/usbvision/usbvision-video.c:43: include/linux/device.h:131: note: macro "DEVICE_ATTR_RO" defined here 131 | #define DEVICE_ATTR_RO(_name) \ | >> drivers/staging/media/usbvision/usbvision-video.c:157:8: error: type >> defaults to 'int' in declaration of 'DEVICE_ATTR_RO' [-Werror=implicit-int] 157 | static DEVICE_ATTR_RO(version, 0444, version_show, NULL); |^~ drivers/staging/media/usbvision/usbvision-video.c:168:52: error: macro "DEVICE_ATTR_RO" passed 4 arguments, but takes just 1 168 | static DEVICE_ATTR_RO(model, 0444, model_show, NULL); |^ In file included from include/linux/acpi.h:15, from include/linux/i2c.h:13, from drivers/staging/media/usbvision/usbvision-video.c:43: include/linux/device.h:131: note: macro "DEVICE_ATTR_RO" defined here 131 | #define DEVICE_ATTR_RO(_name) \ | drivers/staging/media/usbvision/usbvision-video.c:168:8: error: type defaults to 'int' in declaration of 'DEVICE_ATTR_RO' [-Werror=implicit-int] 168 | static DEVICE_ATTR_RO(model, 0444, model_show, NULL); |^~ drivers/staging/media/usbvision/usbvision-video.c:180:48: error: macro "DEVICE_ATTR_RO" passed 4 arguments, but takes just 1 180 | static DEVICE_ATTR_RO(hue, 0444, hue_show, NULL); |^ In file included from include/linux/acpi.h:15, from include/linux/i2c.h:13, from drivers/staging/media/usbvision/usbvision-video.c:43: include/linux/device.h:131: note: macro "DEVICE_ATTR_RO" defined here 131 | #define DEVICE_ATTR_RO(_name) \ | drivers/staging/media/usbvision/usbvision-video.c:180:8: error: type defaults to 'int' in declaration of 'DEVICE_ATTR_RO' [-Werror=implicit-int] 180 | static DEVICE_ATTR_RO(hue, 0444, hue_show, NULL); |^~ drivers/staging/media/usbvision/usbvision-video.c:192:58: error: macro "DEVICE_ATTR_RO" passed 4 arguments, but takes just 1 192 | static DEVICE_ATTR_RO(contrast, 0444, contrast_show, NULL); | ^ In file included from include/linux/acpi.h:15, from include/linux/i2c.h:13, from drivers/staging/media/usbvision/usbvision-video.c:43: include/linux/device.h:131: note: macro "DEVICE_ATTR_RO" defined here 131 | #define DEVICE_ATTR_RO(_name) \ | drivers/staging/media/usbvision/usbvision-video.c:192:8: error: type defaults to 'int' in declaration of 'DEVICE_ATTR_RO' [-Werror=implicit-int] 192 | static DEVICE_ATTR_RO(contrast, 0444, contrast_show, NULL); |^~ drivers/staging/media/usbvision/usbvision-video.c:204:62: error: macro "DEVICE_ATTR_RO" passed 4 arguments, but takes just 1 204 | static DEVICE_ATTR_RO(brightness, 0444, brightness_show, NULL); | ^ In file included from include/linux/acpi.h:15, from include/linux/i2c.h:13, from drivers/staging/media/usbvision/usbvision-video.c:43: include/linux/device.h:131: note: macro "DEVICE_ATTR_RO" defined here 131 | #define DEVICE_ATTR_RO(_name) \ |
Re: [PATCH] media: usbvision: fixed coding style
Alright sorry, I will ignore this patch and will commit the new patch in another file. On Tue, Jul 28, 2020 at 10:28 PM Greg KH wrote: > > On Tue, Jul 28, 2020 at 10:13:22PM +0530, Dhiraj Sharma wrote: > > > As the bot said, only do one type of thing per patch, and "fix all > > > checkpatch errors/warnings" is not one type of thing. > > > > So should I send a fresh patch with minimal fixes? instead of replying > > to this mail with [PATCH 01] > > Why are you ignoring what Hans said? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
On Tue, Jul 28, 2020 at 10:13:22PM +0530, Dhiraj Sharma wrote: > > As the bot said, only do one type of thing per patch, and "fix all > > checkpatch errors/warnings" is not one type of thing. > > So should I send a fresh patch with minimal fixes? instead of replying > to this mail with [PATCH 01] Why are you ignoring what Hans said? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
> As the bot said, only do one type of thing per patch, and "fix all > checkpatch errors/warnings" is not one type of thing. So should I send a fresh patch with minimal fixes? instead of replying to this mail with [PATCH 01] ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
On Tue, Jul 28, 2020 at 09:14:24PM +0530, Dhiraj Sharma wrote: > Sorry, I didn't realize that I committed a mistake by not replying to > all. It was an accidental mistake which will not be committed in > future now. > > > > > That is not needed in a changelog text. > > > > Alright Sir. > > > Neither is this, please be specific about what you have fixed. My bot > > should kick in soon with more specifics... > > Sir there were checkpatch.pl styling issues and I fixed them all > together, so should I write a proper changelog as what all I fixed i.e > errors and warnings thrown by checkpatch.pl As the bot said, only do one type of thing per patch, and "fix all checkpatch errors/warnings" is not one type of thing. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
Sorry I had committed a mistake by not replying to all. > Hi Dhiraj, > > On 28/07/2020 16:30, Dhiraj Sharma wrote: > > As per eudyptula challenge task 10 I had to fix coding styles. Thus I > > used checkpatch.pl script and fixed a chunk of warnings and few errors. > > As both drivers/staging/media/usbvision/Kconfig and .../TODO say, this > driver is deprecated and will be removed by the end of this year. > > So don't bother with this driver. > > Regards, > > Hans Alright Sir, I read that and thought that it can be merged this year though. Next if i see such sentences I will not do that ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
Sorry, I didn't realize that I committed a mistake by not replying to all. It was an accidental mistake which will not be committed in future now. > > That is not needed in a changelog text. > Alright Sir. > Neither is this, please be specific about what you have fixed. My bot > should kick in soon with more specifics... Sir there were checkpatch.pl styling issues and I fixed them all together, so should I write a proper changelog as what all I fixed i.e errors and warnings thrown by checkpatch.pl On Tue, Jul 28, 2020 at 8:24 PM Greg KH wrote: > > On Tue, Jul 28, 2020 at 08:00:04PM +0530, Dhiraj Sharma wrote: > > As per eudyptula challenge task 10 I had to fix coding styles. > > That is not needed in a changelog text. > > > Thus I > > used checkpatch.pl script and fixed a chunk of warnings and few errors. > > Neither is this, please be specific about what you have fixed. My bot > should kick in soon with more specifics... > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
Hi Dhiraj,
On 28/07/2020 16:30, Dhiraj Sharma wrote:
> As per eudyptula challenge task 10 I had to fix coding styles. Thus I
> used checkpatch.pl script and fixed a chunk of warnings and few errors.
As both drivers/staging/media/usbvision/Kconfig and .../TODO say, this
driver is deprecated and will be removed by the end of this year.
So don't bother with this driver.
Regards,
Hans
>
> Signed-off-by: Dhiraj Sharma
> ---
> .../staging/media/usbvision/usbvision-video.c | 91 +++
> 1 file changed, 52 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/staging/media/usbvision/usbvision-video.c
> b/drivers/staging/media/usbvision/usbvision-video.c
> index 3ea25fdcf767..8b68e99a2813 100644
> --- a/drivers/staging/media/usbvision/usbvision-video.c
> +++ b/drivers/staging/media/usbvision/usbvision-video.c
> @@ -67,8 +67,8 @@
> #ifdef USBVISION_DEBUG
> #define PDEBUG(level, fmt, args...) { \
> if (video_debug & (level)) \
> - printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
> - __func__, __LINE__ , ## args); \
> + pr_debug(KBUILD_MODNAME ":[%s:%d] " fmt, \
> + __func__, __LINE__, ## args); \
> }
> #else
> #define PDEBUG(level, fmt, args...) do {} while (0)
> @@ -79,8 +79,8 @@
> #define DBG_MMAP (1 << 3)
>
> /* String operations */
> -#define rmspace(str) while (*str == ' ') str++;
> -#define goto2next(str) while (*str != ' ') str++; while (*str == ' ')
> str++;
> +#define rmspace(str) do { str++; } while (*str == ' ')
> +#define goto2next(str) do { str++; } while (*str != ' ' || *str == ' ')
>
>
> /* sequential number of usbvision device */
> @@ -145,27 +145,29 @@ MODULE_ALIAS(DRIVER_ALIAS);
> static inline struct usb_usbvision *cd_to_usbvision(struct device *cd)
> {
> struct video_device *vdev = to_video_device(cd);
> +
> return video_get_drvdata(vdev);
> }
>
> -static ssize_t show_version(struct device *cd,
> +static ssize_t version_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> return sprintf(buf, "%s\n", USBVISION_VERSION_STRING);
> }
> -static DEVICE_ATTR(version, S_IRUGO, show_version, NULL);
> +static DEVICE_ATTR_RO(version, 0444, version_show, NULL);
>
> -static ssize_t show_model(struct device *cd,
> +static ssize_t model_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> struct usb_usbvision *usbvision = video_get_drvdata(vdev);
> +
> return sprintf(buf, "%s\n",
>
> usbvision_device_data[usbvision->dev_model].model_string);
> }
> -static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
> +static DEVICE_ATTR_RO(model, 0444, model_show, NULL);
>
> -static ssize_t show_hue(struct device *cd,
> +static ssize_t hue_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -175,9 +177,9 @@ static ssize_t show_hue(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(hue, S_IRUGO, show_hue, NULL);
> +static DEVICE_ATTR_RO(hue, 0444, hue_show, NULL);
>
> -static ssize_t show_contrast(struct device *cd,
> +static ssize_t contrast_show(struct device *cd,
>struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -187,9 +189,9 @@ static ssize_t show_contrast(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(contrast, S_IRUGO, show_contrast, NULL);
> +static DEVICE_ATTR_RO(contrast, 0444, contrast_show, NULL);
>
> -static ssize_t show_brightness(struct device *cd,
> +static ssize_t brightness_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -199,9 +201,9 @@ static ssize_t show_brightness(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(brightness, S_IRUGO, show_brightness, NULL);
> +static DEVICE_ATTR_RO(brightness, 0444, brightness_show, NULL);
>
> -static ssize_t show_saturation(struct device *cd,
> +static ssize_t saturation_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -211,36 +213,39 @@ static ssize_t show_saturation(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(saturation, S_IRUGO, show_saturation, NULL);
> +static DEVICE_ATTR_RO(saturation, 0444, saturation_show, NULL);
>
> -static ssize_t show_streaming(struct device *cd,
> +static ssize_t streaming_show(struct device *cd,
> struct device_attribute *attr, char
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code. These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> Signed-off-by: Jim Quinlan
> ---
[...]
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8eea3f6e29a4..4b718d199efe 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct device_node
> *np, int index,
> }
> EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_HAS_DMA
> /**
> - * of_dma_get_range - Get DMA range info
> + * of_dma_get_range - Get DMA range info and put it into a map array
> * @np:device node to get DMA range info
> - * @dma_addr: pointer to store initial DMA address of DMA range
> - * @paddr: pointer to store initial CPU address of DMA range
> - * @size: pointer to store size of DMA range
> + * @map: dma range structure to return
> *
> * Look in bottom up direction for the first "dma-ranges" property
> - * and parse it.
> - * dma-ranges format:
> + * and parse it. Put the information into a DMA offset map array.
> + *
> + * dma-ranges format:
> * DMA addr (dma_addr) : naddr cells
> * CPU addr (phys_addr_t) : pna cells
> * size: nsize cells
> *
> - * It returns -ENODEV if "dma-ranges" property was not found
> - * for this device in DT.
> + * It returns -ENODEV if "dma-ranges" property was not found for this
> + * device in the DT.
> */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64
> *size)
> +int of_dma_get_range(struct device_node *np, const struct bus_dma_region
> **map)
> {
> struct device_node *node = of_node_get(np);
> const __be32 *ranges = NULL;
> - int len;
> - int ret = 0;
> bool found_dma_ranges = false;
> struct of_range_parser parser;
> struct of_range range;
> - u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> + struct bus_dma_region *r;
> + int len, num_ranges = 0;
> + int ret;
>
> while (node) {
> ranges = of_get_property(node, "dma-ranges", &len);
> @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64
> *dma_addr, u64 *paddr, u64 *siz
> }
>
> of_dma_range_parser_init(&parser, node);
> + for_each_of_range(&parser, &range)
> + num_ranges++;
> +
> + of_dma_range_parser_init(&parser, node);
> +
> + ret = -ENOMEM;
> + r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> + if (!r)
> + goto out;
AFAICT, you have the error cases covered, but you are leaking memory
if the device is removed.
[...]
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..49242dd6176e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
> fw_rsc_vdev *rsc,
> /* Initialise vdev subdevice */
> snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> rvdev->dev.parent = &rproc->dev;
> - rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> + rvdev->dev.dma_range_map = rproc->dev.parent->dma_range_map;
But doing this means you can't just free the dma_range_map. You need
to do a copy here or you'd have to refcount it. Or I suppose you could
check if it the child has a different dma_range_map ptr than the
parent.
Rob
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
On Tue, Jul 28, 2020 at 08:00:04PM +0530, Dhiraj Sharma wrote: > As per eudyptula challenge task 10 I had to fix coding styles. That is not needed in a changelog text. > Thus I > used checkpatch.pl script and fixed a chunk of warnings and few errors. Neither is this, please be specific about what you have fixed. My bot should kick in soon with more specifics... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: usbvision: fixed coding style
On Tue, Jul 28, 2020 at 08:00:04PM +0530, Dhiraj Sharma wrote:
> As per eudyptula challenge task 10 I had to fix coding styles. Thus I
> used checkpatch.pl script and fixed a chunk of warnings and few errors.
>
> Signed-off-by: Dhiraj Sharma
> ---
> .../staging/media/usbvision/usbvision-video.c | 91 +++
> 1 file changed, 52 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/staging/media/usbvision/usbvision-video.c
> b/drivers/staging/media/usbvision/usbvision-video.c
> index 3ea25fdcf767..8b68e99a2813 100644
> --- a/drivers/staging/media/usbvision/usbvision-video.c
> +++ b/drivers/staging/media/usbvision/usbvision-video.c
> @@ -67,8 +67,8 @@
> #ifdef USBVISION_DEBUG
> #define PDEBUG(level, fmt, args...) { \
> if (video_debug & (level)) \
> - printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
> - __func__, __LINE__ , ## args); \
> + pr_debug(KBUILD_MODNAME ":[%s:%d] " fmt, \
> + __func__, __LINE__, ## args); \
> }
> #else
> #define PDEBUG(level, fmt, args...) do {} while (0)
> @@ -79,8 +79,8 @@
> #define DBG_MMAP (1 << 3)
>
> /* String operations */
> -#define rmspace(str) while (*str == ' ') str++;
> -#define goto2next(str) while (*str != ' ') str++; while (*str == ' ')
> str++;
> +#define rmspace(str) do { str++; } while (*str == ' ')
> +#define goto2next(str) do { str++; } while (*str != ' ' || *str == ' ')
>
>
> /* sequential number of usbvision device */
> @@ -145,27 +145,29 @@ MODULE_ALIAS(DRIVER_ALIAS);
> static inline struct usb_usbvision *cd_to_usbvision(struct device *cd)
> {
> struct video_device *vdev = to_video_device(cd);
> +
> return video_get_drvdata(vdev);
> }
>
> -static ssize_t show_version(struct device *cd,
> +static ssize_t version_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> return sprintf(buf, "%s\n", USBVISION_VERSION_STRING);
> }
> -static DEVICE_ATTR(version, S_IRUGO, show_version, NULL);
> +static DEVICE_ATTR_RO(version, 0444, version_show, NULL);
>
> -static ssize_t show_model(struct device *cd,
> +static ssize_t model_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> struct usb_usbvision *usbvision = video_get_drvdata(vdev);
> +
> return sprintf(buf, "%s\n",
>
> usbvision_device_data[usbvision->dev_model].model_string);
> }
> -static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
> +static DEVICE_ATTR_RO(model, 0444, model_show, NULL);
>
> -static ssize_t show_hue(struct device *cd,
> +static ssize_t hue_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -175,9 +177,9 @@ static ssize_t show_hue(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(hue, S_IRUGO, show_hue, NULL);
> +static DEVICE_ATTR_RO(hue, 0444, hue_show, NULL);
>
> -static ssize_t show_contrast(struct device *cd,
> +static ssize_t contrast_show(struct device *cd,
>struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -187,9 +189,9 @@ static ssize_t show_contrast(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(contrast, S_IRUGO, show_contrast, NULL);
> +static DEVICE_ATTR_RO(contrast, 0444, contrast_show, NULL);
>
> -static ssize_t show_brightness(struct device *cd,
> +static ssize_t brightness_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -199,9 +201,9 @@ static ssize_t show_brightness(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(brightness, S_IRUGO, show_brightness, NULL);
> +static DEVICE_ATTR_RO(brightness, 0444, brightness_show, NULL);
>
> -static ssize_t show_saturation(struct device *cd,
> +static ssize_t saturation_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> @@ -211,36 +213,39 @@ static ssize_t show_saturation(struct device *cd,
>
> return sprintf(buf, "%d\n", val);
> }
> -static DEVICE_ATTR(saturation, S_IRUGO, show_saturation, NULL);
> +static DEVICE_ATTR_RO(saturation, 0444, saturation_show, NULL);
>
> -static ssize_t show_streaming(struct device *cd,
> +static ssize_t streaming_show(struct device *cd,
> struct device_attribute *attr, char *buf)
> {
> struct video_device *vdev = to_video_device(cd);
> struct usb_usbvision *usbvision = video_get_drvdata(vdev);
> +
> return sprintf(buf, "%s\n",
>
Re: [PATCH] media: atomisp-mt9m114: replace fixed function names
No I didn't intent to. I have sent another version. Thank you very much, Dan. Juan Antonio Aldea-Armenteros ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: usbvision: fixed coding style
As per eudyptula challenge task 10 I had to fix coding styles. Thus I
used checkpatch.pl script and fixed a chunk of warnings and few errors.
Signed-off-by: Dhiraj Sharma
---
.../staging/media/usbvision/usbvision-video.c | 91 +++
1 file changed, 52 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/media/usbvision/usbvision-video.c
b/drivers/staging/media/usbvision/usbvision-video.c
index 3ea25fdcf767..8b68e99a2813 100644
--- a/drivers/staging/media/usbvision/usbvision-video.c
+++ b/drivers/staging/media/usbvision/usbvision-video.c
@@ -67,8 +67,8 @@
#ifdef USBVISION_DEBUG
#define PDEBUG(level, fmt, args...) { \
if (video_debug & (level)) \
- printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
- __func__, __LINE__ , ## args); \
+ pr_debug(KBUILD_MODNAME ":[%s:%d] " fmt, \
+ __func__, __LINE__, ## args); \
}
#else
#define PDEBUG(level, fmt, args...) do {} while (0)
@@ -79,8 +79,8 @@
#define DBG_MMAP (1 << 3)
/* String operations */
-#define rmspace(str) while (*str == ' ') str++;
-#define goto2next(str) while (*str != ' ') str++; while (*str == ' ') str++;
+#define rmspace(str) do { str++; } while (*str == ' ')
+#define goto2next(str) do { str++; } while (*str != ' ' || *str == ' ')
/* sequential number of usbvision device */
@@ -145,27 +145,29 @@ MODULE_ALIAS(DRIVER_ALIAS);
static inline struct usb_usbvision *cd_to_usbvision(struct device *cd)
{
struct video_device *vdev = to_video_device(cd);
+
return video_get_drvdata(vdev);
}
-static ssize_t show_version(struct device *cd,
+static ssize_t version_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", USBVISION_VERSION_STRING);
}
-static DEVICE_ATTR(version, S_IRUGO, show_version, NULL);
+static DEVICE_ATTR_RO(version, 0444, version_show, NULL);
-static ssize_t show_model(struct device *cd,
+static ssize_t model_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
+
return sprintf(buf, "%s\n",
usbvision_device_data[usbvision->dev_model].model_string);
}
-static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
+static DEVICE_ATTR_RO(model, 0444, model_show, NULL);
-static ssize_t show_hue(struct device *cd,
+static ssize_t hue_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct video_device *vdev = to_video_device(cd);
@@ -175,9 +177,9 @@ static ssize_t show_hue(struct device *cd,
return sprintf(buf, "%d\n", val);
}
-static DEVICE_ATTR(hue, S_IRUGO, show_hue, NULL);
+static DEVICE_ATTR_RO(hue, 0444, hue_show, NULL);
-static ssize_t show_contrast(struct device *cd,
+static ssize_t contrast_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct video_device *vdev = to_video_device(cd);
@@ -187,9 +189,9 @@ static ssize_t show_contrast(struct device *cd,
return sprintf(buf, "%d\n", val);
}
-static DEVICE_ATTR(contrast, S_IRUGO, show_contrast, NULL);
+static DEVICE_ATTR_RO(contrast, 0444, contrast_show, NULL);
-static ssize_t show_brightness(struct device *cd,
+static ssize_t brightness_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct video_device *vdev = to_video_device(cd);
@@ -199,9 +201,9 @@ static ssize_t show_brightness(struct device *cd,
return sprintf(buf, "%d\n", val);
}
-static DEVICE_ATTR(brightness, S_IRUGO, show_brightness, NULL);
+static DEVICE_ATTR_RO(brightness, 0444, brightness_show, NULL);
-static ssize_t show_saturation(struct device *cd,
+static ssize_t saturation_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct video_device *vdev = to_video_device(cd);
@@ -211,36 +213,39 @@ static ssize_t show_saturation(struct device *cd,
return sprintf(buf, "%d\n", val);
}
-static DEVICE_ATTR(saturation, S_IRUGO, show_saturation, NULL);
+static DEVICE_ATTR_RO(saturation, 0444, saturation_show, NULL);
-static ssize_t show_streaming(struct device *cd,
+static ssize_t streaming_show(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
+
return sprintf(buf, "%s\n",
YES_NO(usbvision->streaming == stream_on ? 1 : 0));
}
-static DEVICE_ATTR(streaming, S_IRUGO, show_streaming, NULL);
+static DEVICE_ATTR_RO(streaming, 0444, streaming_show, NULL);
-static ssize_t show_compression(struct device *cd,
+static
[PATCH] staging: most: usb: remove NET dependency
This patch removes the dependency to NET as it is no longer needed. Signed-off-by: Christian Gromm --- drivers/staging/most/usb/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/most/usb/Kconfig b/drivers/staging/most/usb/Kconfig index 75dc25c..a47a973 100644 --- a/drivers/staging/most/usb/Kconfig +++ b/drivers/staging/most/usb/Kconfig @@ -5,10 +5,9 @@ config MOST_USB tristate "USB" - depends on USB && NET + depends on USB help Say Y here if you want to connect via USB to network transceiver. - This device driver depends on the networking AIM. To compile this driver as a module, choose M here: the module will be called most_usb. -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] staging: sm750fb: use generic power management
This patch is compile-tested only Thanks Vaibhav Gupta ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1] staging: sm750fb: use generic power management
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions, as through
the generic framework PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.
Signed-off-by: Vaibhav Gupta
---
drivers/staging/sm750fb/sm750.c | 91 ++---
1 file changed, 17 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index a1a82e59dfee..84fb585a5739 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -407,61 +407,29 @@ static inline unsigned int chan_to_field(unsigned int
chan,
return chan << bf->offset;
}
-#ifdef CONFIG_PM
-static int lynxfb_suspend(struct pci_dev *pdev, pm_message_t mesg)
+static int __maybe_unused lynxfb_suspend(struct device *dev)
{
struct fb_info *info;
struct sm750_dev *sm750_dev;
- int ret;
-
- if (mesg.event == pdev->dev.power.power_state.event)
- return 0;
-
- ret = 0;
- sm750_dev = pci_get_drvdata(pdev);
- switch (mesg.event) {
- case PM_EVENT_FREEZE:
- case PM_EVENT_PRETHAW:
- pdev->dev.power.power_state = mesg;
- return 0;
- }
+ sm750_dev = dev_get_drvdata(dev);
console_lock();
- if (mesg.event & PM_EVENT_SLEEP) {
- info = sm750_dev->fbinfo[0];
- if (info)
- /* 1 means do suspend */
- fb_set_suspend(info, 1);
- info = sm750_dev->fbinfo[1];
- if (info)
- /* 1 means do suspend */
- fb_set_suspend(info, 1);
-
- ret = pci_save_state(pdev);
- if (ret) {
- dev_err(&pdev->dev,
- "error:%d occurred in pci_save_state\n", ret);
- goto lynxfb_suspend_err;
- }
-
- ret = pci_set_power_state(pdev, pci_choose_state(pdev, mesg));
- if (ret) {
- dev_err(&pdev->dev,
- "error:%d occurred in pci_set_power_state\n",
- ret);
- goto lynxfb_suspend_err;
- }
- }
-
- pdev->dev.power.power_state = mesg;
+ info = sm750_dev->fbinfo[0];
+ if (info)
+ /* 1 means do suspend */
+ fb_set_suspend(info, 1);
+ info = sm750_dev->fbinfo[1];
+ if (info)
+ /* 1 means do suspend */
+ fb_set_suspend(info, 1);
-lynxfb_suspend_err:
console_unlock();
- return ret;
+ return 0;
}
-static int lynxfb_resume(struct pci_dev *pdev)
+static int __maybe_unused lynxfb_resume(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct fb_info *info;
struct sm750_dev *sm750_dev;
@@ -469,32 +437,10 @@ static int lynxfb_resume(struct pci_dev *pdev)
struct lynxfb_crtc *crtc;
struct lynx_cursor *cursor;
- int ret;
-
- ret = 0;
sm750_dev = pci_get_drvdata(pdev);
console_lock();
- ret = pci_set_power_state(pdev, PCI_D0);
- if (ret) {
- dev_err(&pdev->dev,
- "error:%d occurred in pci_set_power_state\n", ret);
- goto lynxfb_resume_err;
- }
-
- if (pdev->dev.power.power_state.event != PM_EVENT_FREEZE) {
- pci_restore_state(pdev);
- ret = pci_enable_device(pdev);
- if (ret) {
- dev_err(&pdev->dev,
- "error:%d occurred in pci_enable_device\n",
- ret);
- goto lynxfb_resume_err;
- }
- pci_set_master(pdev);
- }
-
hw_sm750_inithw(sm750_dev, pdev);
info = sm750_dev->fbinfo[0];
@@ -523,11 +469,9 @@ static int lynxfb_resume(struct pci_dev *pdev)
pdev->dev.power.power_state.event = PM_EVENT_RESUME;
-lynxfb_resume_err:
console_unlock();
- return ret;
+ return 0;
}
-#endif
static int lynxfb_ops_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
@@ -1210,15 +1154,14 @@ static const struct pci_device_id smi_pci_table[] = {
MODULE_DEVICE_TABLE(pci, smi_pci_table);
+static SIMPLE_DEV_PM_OPS(lynxfb_pm_ops, lynxfb_suspend, lynxfb_resume);
+
static struct pci_driver lynxfb_driver = {
.name = "sm750fb",
.id_
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
A few tiny nitpicks:
The subject should have the dma-mapping prefix, this doesn't
really touch the device core.
> - rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + rc = of_dma_get_range(np, &map);
> + rc = PTR_ERR_OR_ZERO(map);
I don't think you need the PTR_ERR_OR_ZERO line here, of_dma_get_range
returns the error.
> +int dma_set_offset_range(struct device *dev, phys_addr_t cpu_start,
> + dma_addr_t dma_start, u64 size)
> +{
> + struct bus_dma_region *map;
> + u64 offset = (u64)cpu_start - (u64)dma_start;
> +
> + if (!dev)
> + return -ENODEV;
I don't think we need the NULL protection here, all DMA API calls
expect a device.
> + if (!offset)
> + return 0;
> +
> + /*
> + * See if a map already exists and we already encompass the new range:
> + */
> + if (dev->dma_range_map) {
> + if (dma_range_overlaps(dev, cpu_start, dma_start, size, offset))
> + return 0;
> + dev_err(dev, "attempt to add conflicting DMA range to existing
> map\n");
> + return -EINVAL;
> + }
And here why do we need the overlap check at all? I'd be tempted to
always return an error for this case.
What is the plan to merge this? Do you want all this to go into one
tree, or get as many bits into the applicable trees for 5.9 and then
finish up for 5.10? If the former I can apply it to the dma-mapping
tree and just fix up the nitpicks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v5] drivers: most: add USB adapter driver
On Mon, 2020-07-27 at 07:59 -0700, Randy Dunlap wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > Hi-- > > On 7/27/20 1:30 AM, Christian Gromm wrote: > > This patch adds the usb driver source file most_usb.c and > > modifies the Makefile and Kconfig accordingly. > > > > Signed-off-by: Christian Gromm > > --- > > > > drivers/most/Kconfig| 12 + > > drivers/most/Makefile |2 + > > drivers/most/most_usb.c | 1170 > > +++ > > 3 files changed, 1184 insertions(+) > > create mode 100644 drivers/most/most_usb.c > > > > diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig > > index 58d7999..7b65320 100644 > > --- a/drivers/most/Kconfig > > +++ b/drivers/most/Kconfig > > @@ -13,3 +13,15 @@ menuconfig MOST > > module will be called most_core. > > > > If in doubt, say N here. > > + > > +if MOST > > +config MOST_USB_HDM > > + tristate "USB" > > + depends on USB && NET > > + help > > + Say Y here if you want to connect via USB to network > > transceiver. > > + This device depends on the networking AIM. > > What does that last sentence above mean? Nothing. This dependency is obsolete and needs to be removed. I'll fix this up. thanks, Chris ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: nxp imx8m CSI drivers
On 09.07.20 11:32, Martin Kepplinger wrote: > hi linux-media people, > > TL-DR: when exactly is "sd->entity.function == MEDIA_ENT_F_VID_MUX"? > > > I try to use the camera on our librem5-devkit (imx8mq): I try to use > only mainline drivers except for "mxc-mipi-csi2_yav" taken from > linux-imx (which we can prepare to submit if a PoC works. This is the > tree I'm experimenting with: > > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc4/librem5___csi > > * "imx7-media-csi" / imx-media-capture / imx-media-utils currently in > staging (that should work according to NXP) > * ov5640 mainline driver > * mxc-mipi-csi2_yav from NXP tree (linux-imx) with > v4l2_subdev_video_ops' mipi_csis_g_parm and mipi_csis_s_parm callbacks > removed (due to missing API in mainline) > > the drivers probe and run but the following fails when trying to use the > camera (gstreamer): > > in imx-media-utils' imx_media_pipeline_set_stream() the call to > v4l2_subdev_call(sd, video, s_stream, 1) returns with 32 (broken pipe) > and thus the application that tries to use the camera too. > > One problem is definitely the trees' last commit (that I did as a > workaround) in this tree that makes the drivers probe but only by > ignoring this probably needed check: > > imx7-media-csi's imx7_csi_notify_bound() callback implementation gets > called during startup. But if (WARN_ON(sd->entity.function != > MEDIA_ENT_F_VID_MUX)) is true so this is the wrong type of subdev (?). > > I just want to put this out there and check if the general approach is > valid at all and if there's anything that comes to your mind. > > thanks a lot, > martin > (added Pavel Machek) still I'm only on the librem5 Devkit: the situation regarding a tree that should use the imx7-media-csi csi_bridge driver hasn't changed, see above for the details. The tree I tried now is this one: https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc7/librem5___csi_ml1 A tree that includes NXP's csi_bridge and mipi-csi drivers (and camera driver) on the other hand works, and I have one based on v5.8-rcX too: https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.8-rc7/librem5___csi_nxp Since I want to look into a different camera driver, I might use that nxp-drivers tree to work on that, but our goal is obviously to use what is already in staging and should work (the csi bridge driver at least). In case you know more about the v4l2 details that don't match over there, please have a look. thanks a lot in advance, martin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging : media : atomisp : fixed a brace coding sytle issue
From: Ankit Baluni
Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.
Signed-off-by: Ankit Baluni
---
Added extra description and added space before '<' in above lines.
drivers/staging/media/atomisp/pci/atomisp_cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 8ea65bef35d2..28b96b66f4f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -4981,9 +4981,8 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device
*isp,
case ATOMISP_CAMERA_PORT_SECONDARY:
return MIPI_PORT1_ID;
case ATOMISP_CAMERA_PORT_TERTIARY:
- if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID) {
+ if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID)
return MIPI_PORT1_ID + 1;
- }
/* fall through */
default:
dev_err(isp->dev, "unsupported port: %d\n", port);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [v2] Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode
Thanks! regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging : media : atomisp : fixed a brace coding sytle issue
From: Ankit Baluni
Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.
Signed-off-by: Ankit Baluni
---
drivers/staging/media/atomisp/pci/atomisp_cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 8ea65bef35d2..28b96b66f4f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -4981,9 +4981,8 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device
*isp,
case ATOMISP_CAMERA_PORT_SECONDARY:
return MIPI_PORT1_ID;
case ATOMISP_CAMERA_PORT_TERTIARY:
- if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID) {
+ if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID)
return MIPI_PORT1_ID + 1;
- }
/* fall through */
default:
dev_err(isp->dev, "unsupported port: %d\n", port);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-next] BUILD SUCCESS 908e757daecf2120c3019fa630ae5d4c3cd7165b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-next branch HEAD: 908e757daecf2120c3019fa630ae5d4c3cd7165b Merge 5.8-rc7 into staging-next elapsed time: 1294m configs tested: 48 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm defconfig arm allyesconfig arm allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging : media : atomisp : fixed a brace coding sytle issue
On Tue, Jul 28, 2020 at 01:53:30PM +0530, Ankit wrote: > From: Ankit Baluni > > Removed braces for a 'if' condition as it contain only single line & > there is no need for braces for such case according to coding style > rules. > > Signed-off-by: Ankit Baluni > > --- > drivers/staging/media/atomisp/pci/atomisp_cmd.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) What changed from v1? Always put that below the --- line as the documentation asks for. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : media : atomisp : fixed a brace coding sytle issue
On Tue, Jul 28, 2020 at 03:00:10AM +0530, Ankit wrote: > From: Ankit Baluni You need a ' ' before the '<' character. > > Fixed a coding style issue. Be more descriptive of what you are doing, this is vague. > > Signed-off-by: Ankit Baluni Same here with the ' '. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] [v2] Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode
The variable authmode can be uninitialized. The danger would be if
it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid
this by setting it to zero instead. This is the approach that was
used in the rtl8723bs driver.
Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Co-developed-by: Dan Carpenter
Signed-off-by: Dan Carpenter
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Move the initialization after 'else' statement.
Refine commit message.
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 9de2d421f6b1..4f2abe1e14d5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1729,9 +1729,11 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8
*in_ie, u8 *out_ie, uint in_
if ((ndisauthmode == Ndis802_11AuthModeWPA) ||
(ndisauthmode == Ndis802_11AuthModeWPAPSK))
authmode = _WPA_IE_ID_;
- if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
+ else if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
(ndisauthmode == Ndis802_11AuthModeWPA2PSK))
authmode = _WPA2_IE_ID_;
+ else
+ authmode = 0x0;
if (check_fwstate(pmlmepriv, WIFI_UNDER_WPS)) {
memcpy(out_ie + ielength, psecuritypriv->wps_ie,
psecuritypriv->wps_ie_len);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
