[PATCH] et131x: fix allocation failures
We should check the ring allocations don't fail.
If we get a fail we need to clean up properly. The allocator assumes the
deallocator will be used on failure, but it isn't. Make sure the
right deallocator is always called and add a missing check against
fbr allocation failure.
[v2]: Correct check logic
Signed-off-by: Alan Cox
---
drivers/staging/et131x/et131x.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 6413500..cc600df 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -2124,7 +2124,11 @@ static int et131x_rx_dma_memory_alloc(struct
et131x_adapter *adapter)
/* Alloc memory for the lookup table */
rx_ring->fbr[0] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
+ if (rx_ring->fbr[0] == NULL)
+ return -ENOMEM;
rx_ring->fbr[1] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
+ if (rx_ring->fbr[1] == NULL)
+ return -ENOMEM;
/* The first thing we will do is configure the sizes of the buffer
* rings. These will change based on jumbo packet support. Larger
@@ -2289,7 +2293,7 @@ static void et131x_rx_dma_memory_free(struct
et131x_adapter *adapter)
for (id = 0; id < NUM_FBRS; id++) {
fbr = rx_ring->fbr[id];
- if (!fbr->ring_virtaddr)
+ if (!fbr || !fbr->ring_virtaddr)
continue;
/* First the packet memory */
@@ -3591,6 +3595,7 @@ static int et131x_adapter_memory_alloc(struct
et131x_adapter *adapter)
if (status) {
dev_err(&adapter->pdev->dev,
"et131x_tx_dma_memory_alloc FAILED\n");
+ et131x_tx_dma_memory_free(adapter);
return status;
}
/* Receive buffer memory allocation */
@@ -3598,7 +3603,7 @@ static int et131x_adapter_memory_alloc(struct
et131x_adapter *adapter)
if (status) {
dev_err(&adapter->pdev->dev,
"et131x_rx_dma_memory_alloc FAILED\n");
- et131x_tx_dma_memory_free(adapter);
+ et131x_adapter_memory_free(adapter);
return status;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/25] Change tty_port(standard)_install's return type
On Tue, 4 Sep 2018 11:44:26 +0900 Jaejoong Kim wrote: > Many drivers with tty use the tty_stand_install(). But, there is no > need to handle the error, since it always returns 0. And what happens if another change means it can fail again. It's just a property of the current implementation that it can't. It used to fail. This seems to be a ton of unneccessary churn that will end up just having to be reversed again some day in the future. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 21/30] usb: host: ehci-tegra: Support OPP and SoC core voltage scaling
On Thu, Nov 05, 2020 at 02:44:18AM +0300, Dmitry Osipenko wrote:
> Add initial OPP and SoC core voltage scaling support to the Tegra EHCI
> driver. This is required for enabling system-wide DVFS on older Tegra
> SoCs.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by: Dmitry Osipenko
> ---
I'm no expert on OPP stuff, but some of what you have done here looks
peculiar.
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> index 869d9c4de5fc..0976577f54b4 100644
> --- a/drivers/usb/host/ehci-tegra.c
> +++ b/drivers/usb/host/ehci-tegra.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -364,6 +365,79 @@ static void tegra_ehci_unmap_urb_for_dma(struct usb_hcd
> *hcd, struct urb *urb)
> free_dma_aligned_buffer(urb);
> }
>
> +static void tegra_ehci_deinit_opp_table(void *data)
> +{
> + struct device *dev = data;
> + struct opp_table *opp_table;
> +
> + opp_table = dev_pm_opp_get_opp_table(dev);
> + dev_pm_opp_of_remove_table(dev);
> + dev_pm_opp_put_regulators(opp_table);
> + dev_pm_opp_put_opp_table(opp_table);
> +}
> +
> +static int devm_tegra_ehci_init_opp_table(struct device *dev)
> +{
> + unsigned long rate = ULONG_MAX;
> + struct opp_table *opp_table;
> + const char *rname = "core";
> + struct dev_pm_opp *opp;
> + int err;
> +
> + /* legacy device-trees don't have OPP table */
> + if (!device_property_present(dev, "operating-points-v2"))
> + return 0;
> +
> + /* voltage scaling is optional */
> + if (device_property_present(dev, "core-supply"))
> + opp_table = dev_pm_opp_set_regulators(dev, &rname, 1);
> + else
> + opp_table = dev_pm_opp_get_opp_table(dev);
> +
> + if (IS_ERR(opp_table))
> + return dev_err_probe(dev, PTR_ERR(opp_table),
> + "failed to prepare OPP table\n");
> +
> + err = dev_pm_opp_of_add_table(dev);
> + if (err) {
> + dev_err(dev, "failed to add OPP table: %d\n", err);
> + goto put_table;
> + }
> +
> + /* find suitable OPP for the maximum clock rate */
> + opp = dev_pm_opp_find_freq_floor(dev, &rate);
> + err = PTR_ERR_OR_ZERO(opp);
> + if (err) {
> + dev_err(dev, "failed to get OPP: %d\n", err);
> + goto remove_table;
> + }
> +
> + dev_pm_opp_put(opp);
> +
> + /*
> + * First dummy rate-set initializes voltage vote by setting voltage
> + * in accordance to the clock rate.
> + */
> + err = dev_pm_opp_set_rate(dev, rate);
> + if (err) {
> + dev_err(dev, "failed to initialize OPP clock: %d\n", err);
> + goto remove_table;
> + }
> +
> + err = devm_add_action(dev, tegra_ehci_deinit_opp_table, dev);
> + if (err)
> + goto remove_table;
> +
> + return 0;
> +
> +remove_table:
> + dev_pm_opp_of_remove_table(dev);
> +put_table:
> + dev_pm_opp_put_regulators(opp_table);
Do you really want to use the same error unwinding for opp_table values
obtained from dev_pm_opp_set_regulators() as from
dev_pm_opp_get_opp_table()?
> +
> + return err;
> +}
> +
> static const struct tegra_ehci_soc_config tegra30_soc_config = {
> .has_hostpc = true,
> };
> @@ -431,6 +505,11 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> goto cleanup_hcd_create;
> }
>
> + err = devm_tegra_ehci_init_opp_table(&pdev->dev);
> + if (err)
> + return dev_err_probe(&pdev->dev, err,
> + "Failed to initialize OPP\n");
Why log a second error message? Just return err.
Alan Stern
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Staging status of speakup
On Sat, 16 Mar 2019 10:35:43 +0100 Samuel Thibault wrote: > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit: > > Okash Khawaja writes: > > > Finally there is an issue where text in output buffer sometimes gets > > > garbled on SMP systems, but we can continue working on it after the > > > driver is moved out of staging, if that's okay. Basically we need a > > > reproducer of this issue. > > > > What kind of reproducer do you need here? It's straightforward to > > reproduce in casual use, at least with a software synthesizer. > > The problem is that neither Okash nor I are even casual users of > speakup, so we need a walk-through of the kind of operation that > produces the issue. It does not have to be reproducible each time it is > done. Perhaps (I really don't know what that bug is about actually) it > is a matter of putting text in the selection buffer, and try to paste it > 100 times, and once every 10 times it will be garbled, for instance. paste_selection still says /* Insert the contents of the selection buffer into the * queue of the tty associated with the current console. * Invoked by ioctl(). * * Locking: called without locks. Calls the ldisc wrongly with * unsafe methods, */ from which I deduce that with everyone using X nobody ever bothered to fix it. So before you look too hard at the speakup code you might want to review the interaction with selection.c too. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver
vice is in use at a time?
> +
> + /* add urb to queue list */
> + spin_lock_irqsave(&ep->ep_lock, irq_flags);
> + list_add_tail(&maurb->urb_list, &ep->urb_list);
> + spin_unlock_irqrestore(&ep->ep_lock, irq_flags);
Yet another class of spinlocks!
> + /* add urb to ma hcd urb list */
> + spin_lock_irqsave(&mhcd.urb_list_lock, irq_flags);
And another! You really shouldn't need more than one lock.
> + list_add_tail(&maurb->ma_hcd_urb_list, &mhcd.enqueue_urb_list);
> + spin_unlock_irqrestore(&mhcd.urb_list_lock, irq_flags);
> +
> + /* send to MA transfer process */
> + wake_up(&mhcd.waitq);
> +
> + return ret;
> +}
> +
> +/**
> + * Dequeues an URB.
> + */
> +static int mausb_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int
> status)
> +{
> + int ret = 0;
> + struct mausb_host_ep*ep = usb_to_ma_endpoint(urb->ep);
> + struct mausb_urb*maurb = usb_urb_to_mausb_urb(urb);
> + unsigned long irq_flags;
> +
> + /* For debugging - we want to know who initiated URB dequeue. */
> + dump_stack();
Debugging things like this should be removed before a patch is submitted.
That's enough for now. Obviously there are a lot of issues in this
driver which need to be fixed up.
Alan Stern
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [V2 PATCH 02/10] added media agnostic (MA) USB HCD roothubs
On Wed, 12 Nov 2014, Sean O. Stalley wrote:
> > > --- /dev/null
> > > +++ b/drivers/staging/mausb/drivers/mausb_hub.c
> >
> > > +/**
> > > + * Returns true if the given is the superspeed HCD. Note: The primary
> > > HCD is
> > > + * High Speed and the shared HCD is SuperSpeed.
> > > + */
> >
> > Why in that order?
> >
>
> We should probably switch this & make the superspeed hub primary.
> That way we match the xhci driver.
xhci-hcd makes the high-speed hcd the primary one. This is because it
registers the high-speed hcd before the SuperSpeed hcd. There was a
good reason for doing it this way, but I can't remember what it was
(it's buried somewhere in the email archives).
That's why when you look at the output from lsusb or something similar,
a SuperSpeed root hub has a bus number that is one higher than its peer
high-speed root hub.
> > > +int mausb_hub_status_data(struct usb_hcd *hcd, char *buf)
> > > +{
> > > + int i;
> > > + u16 port_change = 0;
> > > + u32 status = 0;
> > > + int ret = 1;
> > > + struct mausb_hcd *mhcd = usb_hcd_to_mausb_hcd(hcd);
> > > + struct mausb_root_hub*roothub = usb_hcd_to_roothub(hcd);
> > > +
> > > + /*
> > > + * Buf should never be more that 2 bytes. USB 3.0 hubs cannot have
> > > + * more than 15 downstream ports.
> > > + */
> > > + buf[0] = 0;
> > > + if (MAUSB_ROOTHUB_NUM_PORTS > 7) {
> > > + buf[1] = 0;
> > > + ret++;
> > > + }
> >
> > Endianness bug.
> >
>
> Could you elaborate?
> It was my understanding that this buffer was host-endian.
> Is this an unacceptable way to clear the buffer?
I don't understand Oliver's objection here. The buffer is
little-endian, just as it is for real hubs. The code seems correct.
Alan Stern
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver
On Wed, 12 Nov 2014, Sean O. Stalley wrote: > On Tue, Nov 11, 2014 at 10:54:30AM -0500, Alan Stern wrote: > > On Mon, 10 Nov 2014, Stephanie Wallick wrote: > > > > > +static struct mausb_hcd mhcd; > > > > Only one statically-allocated structure? What if somebody wants to > > have more than one of these things in their system? > > > > Our plan to support multiple MA devices is to have them all connected > to the same virtual host controller, so only 1 would be needed. > > Would you prefer we have 1 host controller instance per MA device? > We are definitely open to suggestions on how this should be architected. I haven't read the MA USB spec, so I don't know how it's intended to work. Still, what happens if you create a virtual host controller with, say, 16 ports, and then someone wants to connect a 17th MA device? Also, I noticed that your patch adds a new bus type for these MA host controllers. It really seems like overkill to have a whole new bus type if there's only going to be one device on it. > If we get rid of these locks, endpoints can't run simultaneously. > MA USB IN endpoints have to copy data, which could take a while. I don't know what you mean by "run simultaneously". Certainly multiple network packets can be transmitted and received concurrently even if you use a single spinlock, since your locking won't affect the networking subsystem. > Couldn't this cause a bottleneck? Probably not enough to matter. After all, the other host controller drivers rely on a single spinlock. And if it did matter, you could drop the spinlock while copying the data. Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver
On Fri, 14 Nov 2014, Sean O. Stalley wrote: > To summarize the spec: > MA USB groups a host & connected devices into MA service sets (MSS). > The architectural limit is 254 MA devices per MSS. > > If the host needs to connect more devices than that, It can start a > new MSS and connect to 254 more MA devices. > > > > Is supporting up to 254 devices on one machine sufficient? It's probably more than enough. > Would it make sense (and does the usb stack support) having 254 root > ports on one host controller? If so, we could make our host > controller instance have 254 ports. I'm guessing the hub driver may have > a problem with this (especially for superspeed). The USB stack is likely to have problems if there are more than 31 ports on any hub. > If that doesn't make sense (or isn't supported), we can have 1 host > controller instance per MA device. Would that be preferred? It doesn't make much difference. Whatever you think will be easier to support. You might check and see how usbip does it. > > Also, I noticed that your patch adds a new bus type for these MA host > > controllers. It really seems like overkill to have a whole new bus > > type if there's only going to be one device on it. > > The bus was added when we were quickly trying to replace the platform > device code. It's probably not the right thing to do. > > I'm still not sure why we can't make our hcd a platform device, > especially since dummy_hcd & the usbip's hcd are both platform devices. A platform device is the right way to go. Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: atomisp: activate ATOMISP2401 support
On Mon, 11 Sep 2017 20:49:27 +0200 Vincent Hervieux wrote: > Currently atomisp module supports Intel's Baytrail SoC and contains > some compilation switches to support Intel's Cherrytrail SoC instead. > The patchset aims to : > - 1/2: activate ATOMISP2400 or ATOMISP2401 from the menu. > - 2/2: fix compilation errors for ATOMISP2401. > I'm not so confident with patch 2/2, as it is only working around the non > declared functions by using the 2400 path. As I couln't find any > declaration/definition for the ISP2401 missing functions...So any help would > be appreciated. > Also patch 2/2 doesn't correct any cosmetic changes reported by checkpatch.pl > as explained in TODO step 6. Please don't. Right now we know what work is to be done and tested. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: atomisp: add a driver for ov5648 camera sensor
> Would it make sense to first get the other drivers to upstream and > then see what's the status of atomisp? Agreed > the board specific information from firmware is conveyed to the > sensor drivers will change to what the rest of the sensor drivers are > using. I think a most straightforward way would be to amend the ACPI > tables to include the necessary information. I don't see that happening. The firmware they have today is the firmware they will always have, and for any new devices we manage to get going is probably going to end up entirely hardcoded. > For this reason I'm tempted to postpone applying this patch at least > until the other drivers are available. Yes - unless someone has a different controller and that sensor on a board so can test it that way ? Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()
On Wed, 2017-11-22 at 00:31 -0500, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 > as > where a PCI device is present. This restricts the device drivers to > be > reused for other domain numbers. The ISP v2 will always been in domain 0. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()
On Wed, 22 Nov 2017 12:20:47 + Alan Cox wrote: > On Wed, 2017-11-22 at 00:31 -0500, Sinan Kaya wrote: > > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 > > as > > where a PCI device is present. This restricts the device drivers to > > be > > reused for other domain numbers. > > The ISP v2 will always been in domain 0. For the ISP it doesn't matter - if it cleans up general assumptions then you have my ACK for it. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, 27 Nov 2017 16:21:41 +0100 Arnd Bergmann wrote: > timespec overflows in 2038 on 32-bit architectures, and the > getnstimeofday() suffers from possible time jumps, so the > timestamps here are better done using ktime_get(), which has > neither of those problems. > > In case of ov2680, we don't seem to use the timestamp at > all, so I just remove it. > > Signed-off-by: Arnd Bergmann Reviewed-by: Alan Cox ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/3] media: staging: atomisp: fixed some checkpatch integer type warnings.
On Mon, 27 Nov 2017 12:44:50 + Jeremy Sowden wrote: > Changed the types of some arrays from int16_t to s16W Which are the same type, except int16_t is the standard form. No point. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.
> There are 35 defaults defined by macros like this, most of them much > more complicated that IA_CSS_DEFAULT_ISP_MEM_PARAMS, and a few members > are initialized to non-zero values. My plan, therefore, is to convert > everything to use designated initializers, and then start removing the > zeroes afterwards. Where they are only used once in the tree it might be even cleaner to just do static struct foo = FOO_DEFAULT_BAR; foo.x = 12; foo.bar = &foo; etc in the code. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] media: atomisp: delete zero-valued struct members.
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe_public.h
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe_public.h
> @@ -152,14 +152,6 @@ struct ia_css_pipe_config {
> };
>
Thani you that's a really good cleanup.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
TRADING ACCOUNT
Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market. We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices . we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? What is the procedure for our account opening and credit line application ? Cordially KELLY ALAN CFM INTERNATIONAL 2 BOULEVARD DU GAL MARTIAL VALIN 75015 PARIS REG N° 302 527 700 VAT N° FR90 302527700 TEL +33171025367 FAX +33177759149 https://www.cfmaeroengines.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
TRADING ACCOUNT
Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market. We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices . we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? What is the procedure for our account opening and credit line application ? Cordially KELLY ALAN CFM INTERNATIONAL 2 BOULEVARD DU GAL MARTIAL VALIN 75015 PARIS REG N° 302 527 700 VAT N° FR90 302527700 TEL +33171025367 FAX +33177759149 https://www.cfmaeroengines.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
TRADING ACCOUNT
Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market. We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices . we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? What is the procedure for our account opening and credit line application ? Cordially KELLY ALAN CFM INTERNATIONAL 2 BOULEVARD DU GAL MARTIAL VALIN 75015 PARIS REG N° 302 527 700 VAT N° FR90 302527700 TEL +33171025367 FAX +33177759149 https://www.cfmaeroengines.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 209/209] drivers/staging/media/atomisp/i2c/imx/otp_brcc064_e2prom.c:72:3-8: WARNING: invalid free of devm_ allocated data (fwd)
On Wed, 2017-03-01 at 11:25 +0100, Julia Lawall wrote: > In both of the cited files (only one is shown), buffer is allocated > using > devm_kzalloc, so the kfree is not appropriate. > Thanks I'll get these fixed up. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: atomisp: potential underflow in atomisp_get_metadata_by_type()
On Mon, 2017-03-13 at 15:34 +0300, Dan Carpenter wrote: > md_type is an enum. On my tests, GCC treats it as unsigned but > according to the C standard it's an implementation dependant thing so > we > should check for negatives. Can do but the kernel assumes GNU C everywhere else. Acked-by: Alan Cox Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: atomisp: use k{v}zalloc instead of k{v}alloc and memset
On Mon, 2017-03-13 at 19:54 +0900, Daeseok Youn wrote: > If the atomisp_kernel_zalloc() has "true" as a second parameter, it > tries to allocate zeroing memory from kmalloc(vmalloc) and memset. > But using kzalloc is rather than kmalloc followed by memset with 0. > (vzalloc is for same reason with kzalloc) This is true but please don't apply this. There are about five other layers of indirection for memory allocators that want removing first so that the driver just uses the correct kmalloc/kzalloc/kv* functions in the right places. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/6] staging: media: atomisp: fix build when PM is disabled
> + if (IS_ENABLED(CONFI_PM)) {
I think not.
Please actually test build both ways at the very least.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/6] staging: media: atomisp: fill properly hmm_bo_type_strings when ION is disabled
On Wed, 2017-03-15 at 14:09 -0400, Jérémy Lefaure wrote: > When CONFIG_ION is disabled, HMM_BO_LAST is 3. In this case, "i" > should > not be added in hmm_bo_type_strings. No the goal is to remove ifdefs - that's not the way to go with driver clean up. Instead the array size should always cover the four strings. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [bug report] staging/atomisp: Add support for the Intel IPU v2
> 457 if (ret) > 458 return ret; > ^^ > We're returning directly with the lock held. We should either unlock > before returning or do a goto out but I'm not sure which. unlock and return (although clearly this path never happens in the real world since that bug is in lots of product 8)). Added to my queue. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: atomisp: fix build error
On Thu, 2017-03-23 at 21:12 +0800, Geliang Tang wrote: > Fix the following build error: > > CC drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o > drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: > error: excess elements in array initializer [-Werror] > "i", /* ion */ > ^~~ NAK I've sent a patch to sort this out properly we shouldn't be using string arrays for single char values to start with... Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: atomisp: remove ifdef around HMM_BO_ION
> > 2 -- > > 1 file changed, 2 deletions(-) > > Ugh, Alan, what's going on here, I thought you fixed this? I sent you a patch that removed the arrays entirely and turned it into a single string as well as removing the define. Not quite sure what happened but I've resynched to -next and I'll send you it with the next batch of patches. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: media: atomisp: Fix style. remove space before ',' and convert to tabs.
On Wed, 2017-03-29 at 09:57 -0700, Daniel Cashman wrote: > From: Dan Cashman > > Signed-off-by: Dan Cashman As the TODO asks - please no whitespace cleanups yet. They make it harder to keep other cleanups that fix (or mostly remove) code applying. Nothing wrong with the patch otherwise - but it should also have something in the commit message. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: atomisp: simplify the if condition in atomisp_freq_scaling()
On Thu, 2017-03-30 at 15:24 +0900, Daeseok Youn wrote: > The condition line in if-statement is needed to be shorthen to > improve readability. > > Signed-off-by: Daeseok Youn > --- How about a define for ATOMISP_IS_CHT(isp) instead - as we will need these tests in other places where there are ISP2400/ISP2401 ifdefs ? Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] media: staging: atomisp: Fix an error handling path in 'lm3554_probe()'
On Fri, 2018-05-11 at 17:09 +0200, Julia Lawall wrote: > > On Fri, 11 May 2018, Christophe JAILLET wrote: > > > The use of 'fail1' and 'fail2' is not correct. Reorder these calls > > to > > branch at the right place of the error handling path. > > Maybe it would be good to improve the names at the same time? Its scheduled for deletion - please don't bother. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V4] Fix pointer cast for 32 bits arch
On Thu, 2015-04-16 at 20:01 +0300, Dan Carpenter wrote:
> On Thu, Apr 16, 2015 at 06:14:55PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Apr 16, 2015 at 3:39 PM, Peter Senna Tschudin
> > wrote:
> > > --- a/drivers/staging/goldfish/goldfish_audio.c
> > > +++ b/drivers/staging/goldfish/goldfish_audio.c
> > > @@ -63,7 +63,7 @@ struct goldfish_audio {
> > > #define AUDIO_READ(data, addr) (readl(data->reg_base + addr))
> > > #define AUDIO_WRITE(data, addr, x) (writel(x, data->reg_base + addr))
> > > #define AUDIO_WRITE64(data, addr, addr2, x)\
> > > - (gf_write64((u64)(x), data->reg_base + addr,
> > > data->reg_base+addr2))
> > > + (gf_write_ptr((void *)(x), data->reg_base + addr,
> > > data->reg_base+addr2))
> >
> > This one should not be converted, as all callers pass a dma_addr_t, which
> > may
> > be 64-bit on 32-bit systems, i.e. larger than void *.
>
> Ugh... You're right.
>
> I've been avoiding asking this but I can't any longer. What is
> gf_write64() actually doing? We are writing dma addresses, user space
> pointers and kernel space pointers to this hardware?
>
> This stuff doesn't seem to make any kind of sense and I can easily
> imagine a situation where it wrote a 64 bit pointer. Then we partially
> write over it with a 32 bit userspace pointer. Then it writes somewhere
> totally unintended.
>
> This thing doesn't make any sort of sense to me.
Its a 64 on 64 or 32 on 32 virtual machine. Goldfish is used for Android
emulation for all the system level phone emulation tools. On the
emulation side it provides an interface for the emulated OS but makes no
effort to emulate it as if it was a real hardware. If you think of it as
a funky emulator interface all is good. If you think about it as
"hardware" you've got the wrong model and chunks of Goldfish make less
sense.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V4] Fix pointer cast for 32 bits arch
On Fri, 2015-04-17 at 11:20 +0300, Dan Carpenter wrote: > Actually, my patch seems like a good idea to me but it's one of those > things that someone should probably test. Unless someone can test > goldfish on a 32 bit system with 64 bit dma addresses No such "system" exists. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V4] Fix pointer cast for 32 bits arch
On Fri, 2015-04-17 at 16:59 +0300, Dan Carpenter wrote: > On Fri, Apr 17, 2015 at 02:31:49PM +0100, Alan Cox wrote: > > On Fri, 2015-04-17 at 11:20 +0300, Dan Carpenter wrote: > > > Actually, my patch seems like a good idea to me but it's one of those > > > things that someone should probably test. Unless someone can test > > > goldfish on a 32 bit system with 64 bit dma addresses > > > > No such "system" exists. > > I don't understand. We definitely can have 64bit dma addresses on > x86_32. Yes but no actual Goldfish environment is built that way ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: i2o: fixed various code style issues in i2o_block.c
On Sat, 2015-04-18 at 22:12 +0200, Yorick Rommers wrote: > From: Yorick > > This is a patch that fixes errors regarding whitespaces and split strings. Wouldn't worry. The i2o layer is in staging because it is about to be dropped from the kernel unless someone steps up to maintain it. Given its unlikely anyone even has hardware I doubt that will happen. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) wrote: > This patch removes unwanted semicolon around close braces of code blocks The i2o driver moved into staging ready to be deleted unless someone steps up with hardware willing to maintain it (which is rather unlikely). Nothing wrong with removing all those semi-colons or the submission, it's just you are patching something going away! Thanks for the patch though - and better luck next time 8) Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Fri, 2015-05-01 at 09:41 +0200, gre...@linuxfoundation.org wrote: > On Thu, Apr 30, 2015 at 11:25:48PM +0100, One Thousand Gnomes wrote: > > On Thu, 30 Apr 2015 16:14:06 +0200 > > "gre...@linuxfoundation.org" wrote: > > > > > On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote: > > > > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) > > > > wrote: > > > > > This patch removes unwanted semicolon around close braces of code > > > > > blocks > > > > > > > > > > > > The i2o driver moved into staging ready to be deleted unless someone > > > > steps up with hardware willing to maintain it (which is rather > > > > unlikely). > > > > > > I think it's now time to delete these, want me to do that for 4.2? I > > > can queue that up in my tree now, so that we don't see any more cleanup > > > patches being made for them? > > > > Yeah I think it can go > > I was about to delete it, but what about drivers/scsi/dpt/dpti_i2o.* ? > Should that be removed as well? Possibly but that ought to go via staging and really is one for the SCSI folks to call. The dpt_i2o was a bit more common than i2o proper. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: i2o: Remove unwanted semicolon
> > Possibly but that ought to go via staging and really is one for the SCSI > > folks to call. The dpt_i2o was a bit more common than i2o proper. > > But if the staging i2o core is removed, doesn't that mean that this > driver will stop working? It uses code in uapi i2o.h, which I'm > guessing is implemented in the staging i2o core. They are separate drivers. dpt_i2o intentionally shares some API bits but they stand alone. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path
On Mon, 2014-02-24 at 16:54 -0800, Greg Kroah-Hartman wrote: > On Sat, Feb 22, 2014 at 12:33:36PM +0800, Zhao, Gang wrote: > > On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote: > > > On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote: > > >> > If we add your patch and the reviewer does a search for fb[0] then it > > >> > is > > >> > confusing what the right thing to do is. > > >> > > >> My fault. I should remove that two lines of code in > > >> et131x_rx_dma_memory_free(), although they don't break the code. > > >> > > > > > > Think about what you are saying here for a minute. > > > > Oh, a cold makes me stupid. that two lines of code is needed > > definitively. > > > > So is additional modification needed to let this patch be accepted ? > > As I can't take this as-is, yes. Sorry I'm completely lost here, can someone explain the problem they are seeing after the changes ? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: usbip: claim ports used by shared devices
On Tue, 4 Mar 2014, Valentina Manea wrote:
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 90e18f6..a91dc1f 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -62,23 +62,6 @@
> /* Mutual exclusion for removal, open, and release */
> DEFINE_MUTEX(usbfs_mutex);
>
> -struct dev_state {
> - struct list_head list; /* state list */
> - struct usb_device *dev;
> - struct file *file;
> - spinlock_t lock;/* protects the async urb lists */
> - struct list_head async_pending;
> - struct list_head async_completed;
> - wait_queue_head_t wait; /* wake up if a request completed */
> - unsigned int discsignr;
> - struct pid *disc_pid;
> - const struct cred *cred;
> - void __user *disccontext;
> - unsigned long ifclaimed;
> - u32 secid;
> - u32 disabled_bulk_eps;
> -};
> -
Don't remove this definition.
> diff --git a/include/linux/usb.h b/include/linux/usb.h
> index 22de4af..e0843a4 100644
> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -366,6 +366,24 @@ struct usb_bus {
> #endif
> };
>
> +struct dev_state {
> + struct list_head list; /* state list */
> + struct usb_device *dev;
> + struct file *file;
> + spinlock_t lock;/* protects the async urb lists */
> + struct list_head async_pending;
> + struct list_head async_completed;
> + wait_queue_head_t wait; /* wake up if a request completed */
> + unsigned int discsignr;
> + struct pid *disc_pid;
> + const struct cred *cred;
> + void __user *disccontext;
> + unsigned long ifclaimed;
> + u32 secid;
> + u32 disabled_bulk_eps;
> +};
And don't put this here. Instead, just put
struct dev_state;
Alan Stern
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: usbip: claim ports used by shared devices
On Thu, 6 Mar 2014, Valentina Manea wrote: > A device should not be able to be used concurrently both by > the server and the client. Claiming the port used by the > shared device ensures no interface drivers bind to it and > that it is not usable from the server. > > Signed-off-by: Valentina Manea > --- > Changes since v1: > * add commit description > * move struct dev_state definition back to usb/core/devio.c For the changes to the USB core: Acked-by: Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: octeon-usb: prevent memory corruption
On Thu, 20 Mar 2014, David Laight wrote: > From: Aaro Koskinen > > octeon-hcd will crash the kernel when SLOB is used. This usually happens > > after the 18-byte control transfer when a device descriptor is read. > > The DMA engine is always transfering full 32-bit words and if the > > transfer is shorter, some random garbage appears after the buffer. > > The problem is not visible with SLUB since it rounds up the allocations > > to word boundary, and the extra bytes will go undetected. > > > > Fix by providing quirk functions for DMA map/unmap that allocate a bigger > > temporary buffer when necessary. Tested by booting EdgeRouter Lite > > to USB stick root file system with SLAB, SLOB and SLUB kernels. > > Wouldn't it be simpler to just round up the existing allocation? > (With a comment that some DMA controllers write whole words.) No doubt it would be simpler. The problem is that octeon-hcd doesn't make these allocations; they are carried out by other parts of the kernel. Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] staging: atomisp: remove enable_isp_irq function and add disable_isp_irq
On Fri, 2017-04-07 at 14:56 +0900, Daeseok Youn wrote: > Enable/Disable ISP irq is switched with "enable" parameter of > enable_isp_irq(). It would be better splited to two such as > enable_isp_irq()/disable_isp_irq(). > > But the enable_isp_irq() is no use in atomisp_cmd.c file. > So remove the enable_isp_irq() function and add > disable_isp_irq function only. All 3 added to my tree - thanks Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/media: make atomisp vlv2_plat_clock explicitly non-modular
> I'm pretty sure we want this code to be built as a module, so maybe a > Kconfig change would resolve the issue instead? > > Alan, any thoughts? It's a tiny chunk of platform helper code. It probably ultimately belongs in arch/x86 somewhere or folded into the driver. At the moment it won't build modular. I'm fine with the change, it strips out more pointless code so helps see what tiny bits of code in there are actually used for anything real. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control
> + if (!(tmp_termios.c_cflag & CRTSCTS)) {
> + tmp_termios.c_cflag |= CRTSCTS;
> + ret = tty_set_termios(tty, &tmp_termios);
> + if (ret)
> + pr_warn("speakup: Failed to set hardware flow
> control\n");
You should check the tty c_cflag after the call rather than rely on an
error code. Strictly speaking tty_set_termios should error if no tty bits
are changed by the request but it never has on Linux. Instead check the
tty gave you the result you wanted.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control
On Thu, 11 May 2017 09:29:14 +0100
Okash Khawaja wrote:
> Hi Alan,
>
> On Wed, May 10, 2017 at 08:41:51PM +0100, Alan Cox wrote:
> > > + if (!(tmp_termios.c_cflag & CRTSCTS)) {
> > > + tmp_termios.c_cflag |= CRTSCTS;
> > > + ret = tty_set_termios(tty, &tmp_termios);
> > > + if (ret)
> > > + pr_warn("speakup: Failed to set hardware flow
> > > control\n");
> >
> > You should check the tty c_cflag after the call rather than rely on an
> > error code. Strictly speaking tty_set_termios should error if no tty bits
> > are changed by the request but it never has on Linux. Instead check the
> > tty gave you the result you wanted.
> Thanks. I will replace the check for return value with check for c_cflag.
>
> May be we should fix this in tty_set_termios?
Possibly. It however changes the external kernel ABI. It's also not a
simple memcmp because any undefined bits must be ignored.
Make a patch, try it and see what breaks ? If nothing breaks then yes it
makes sense IMHO too.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control
On Fri, 12 May 2017 20:35:18 +0100
Okash Khawaja wrote:
> On Thu, May 11, 2017 at 02:33:14PM +0100, Alan Cox wrote:
> > On Thu, 11 May 2017 09:29:14 +0100
> > Okash Khawaja wrote:
> >
> > > Hi Alan,
> > >
> > > On Wed, May 10, 2017 at 08:41:51PM +0100, Alan Cox wrote:
> > > > > + if (!(tmp_termios.c_cflag & CRTSCTS)) {
> > > > > + tmp_termios.c_cflag |= CRTSCTS;
> > > > > + ret = tty_set_termios(tty, &tmp_termios);
> > > > > + if (ret)
> > > > > + pr_warn("speakup: Failed to set hardware flow
> > > > > control\n");
> > > >
> > > > You should check the tty c_cflag after the call rather than rely on an
> > > > error code. Strictly speaking tty_set_termios should error if no tty
> > > > bits
> > > > are changed by the request but it never has on Linux. Instead check the
> > > > tty gave you the result you wanted.
> > > Thanks. I will replace the check for return value with check for c_cflag.
> > >
> > > May be we should fix this in tty_set_termios?
> >
> > Possibly. It however changes the external kernel ABI. It's also not a
> > simple memcmp because any undefined bits must be ignored.
> >
> > Make a patch, try it and see what breaks ? If nothing breaks then yes it
> > makes sense IMHO too.
>
> Right, thanks for the heads up. I'll see if I get round to doing it. For
> external kernel ABI, will we need to check libc implementations of
> termios functions? Will that be sufficient?
I think the only way you find out is to try it and run a distro like
that. If it seems ok submit the patch to linux-next with a clear note it
potentially changes the ABI so if people find bugs it can be reverted.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: media: fix missing blank line coding style issue in atomisp_tpg.c
On Wed, 2017-05-17 at 21:48 -0400, Manny Vindiola wrote:
> This is a patch to the atomisp_tpg.c file that fixes up a missing
> blank line warning found by the checkpatch.pl tool
>
> Signed-off-by: Manny Vindiola
> ---
> drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
> index 996d1bd..48b9604 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
> @@ -56,6 +56,7 @@ static int tpg_set_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_format *format)
> {
> struct v4l2_mbus_framefmt *fmt = &format->format;
> +
> if (format->pad)
> return -EINVAL;
> /* only raw8 grbg is supported by TPG */
The TODO fille for this driver specifically says not to send formatting
patches at this point.
There is no point making trivial spacing changes in code that needs
lots of real work. It's like polishing your car when the doors have
fallen off.
Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/13] staging: media: atomisp queued up patches
On Thu, 2017-05-18 at 11:10 -0300, Mauro Carvalho Chehab wrote: > Em Thu, 18 May 2017 15:50:09 +0200 > Greg Kroah-Hartman escreveu: > > > > > Hi Mauro, > > > > Here's the set of accumulated atomisp staging patches that I had in > > my > > to-review mailbox. After this, my queue is empty, the driver is > > all > > yours! > > Thanks! > > Alan, please let me know if you prefer if I don't apply any of > such patches, otherwise I should be merging them tomorrow ;) I will assume you've merged them and resync the internal patch queue I have here to that. At the moment I'm still slowly trying to unthread some of the fascinating layers of indirection without actually breaking anything. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] pci-hyperv: Use only 16 bit integer for PCI domain
> > Signed-off-by: Haiyang Zhang > > --- > > According to Stephen Hemminger , there are > additional programs, like X.org, DPDK, are also using 16-bit only > PCI domain numbers. So, I'm submitting this patch for re-consideration. The correct way to handle this is to send the needed patches to DPDK and to X.org both of whom will I am sure be delighted to get it fixed in their codebase. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)
On Mon, 29 May 2017 02:06:41 +0800 Chen Guanqiao wrote: > Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings. > > Signed-off-by: Chen Guanqiao > --- Reviewed-by: Alan Cox ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Firmware for staging atomisp driver
On Sun, 2017-05-28 at 14:30 +0200, Hans de Goede wrote: > I started with an Asus T100TA after fixing 2 oopses in the sensor > driver there I found out that the BIOS does not allow to put the > ISP in PCI mode and that there is no code to drive it in ACPI > enumerated mode. In ACPI mode it's enumerated as part of the GPU but beyond that I don't know how it works and haven't been able to find out. I am guessing at this point that the extra node in the acpidump under the GPU gives the base address, but no idea where the IRQ comes from. Power management on the BYT devices via PCI is broken anyway so that bit shouldn't matter. > So I moved to a generic Insyde T701 tablet which does allow > this. After fixing some more sensor driver issues there I was > ready to actually load the atomisp driver, but I could not > find the exact firmware required, I did find a version which > is close: "irci_stable_candrpv_0415_20150423_1753" > and tried that but that causes the atomisp driver to explode > in a backtrace which contains atomisp_load_firmware() so that > one seems no good. The firmware has to exactly match. If you look in the atomisp code you'll see that there are offsets which basically appear to be memory addresses in the firmware as built that time. > Can someone help me to get the right firmware ? Yep. > The TODO says: "can also be extracted from the upgrade kit" > about the firmware files, but it is not clear to me what / > where the "upgrade kit" is. The Android upgrade kit for your device. So your platforms equivalent of https://www.asus.com/Tablets/ASUS_MeMO_Pad_7_ME176C/HelpDesk_Download/ > More in general it would be a good idea if someone inside Intel > would try to get permission to add the firmware to linux-firmware. I spent 6 months trying, but even though you can go to your product vendors website and download it I've not been able to 8(. > > Anyways I will send out the patches I've currently, once I've > the right firmware I will continue working on this. Really appreciate the work you are doing on this. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Firmware for staging atomisp driver
> I'm asking because that is hard to believe given e.g. the recursion bug > I've just fixed. It was kind of working yes (with libxcam and a simple test tool). The recursion one was my fault. I didn't mean that one to go upstream as I was still debugging it. The older code handled it right until I moved the test. > Can someone provide step-by-step instructions for how to get this > driver working? Need to restore my backup to get the set up I had (I broke my memopad somewhat with one of my tests and it ate it's disk). But basically I was using https://github.com/01org/libxcam/wiki/Tests Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: goldfish: Add DMA support using dma_alloc_coherent
> unnecessarily used when DMA can do the job. Coherent mapping is > allocated > by means of dma_alloc_coherent so that the device and CPU are in > sync. It's also not freed 8) As far as I can see you can replace the devm_kzalloc of cmd->params with a dma_alloc_coherent, and ensure you free it when the device is destroyed, rather than allocating a new buffer each command. You also want dma_handle to be a u64 - dma_handle_t might be 32 or 64 bit and due to a historical (and IMHO dim) bit of design C doesn't define right or left shifting by >= the size of the type as "0" but as "undefined". Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: goldfish: Add DMA support using dma_alloc_coherent
> Yes I will free it using dma_free_coherent. Why should devm_kzalloc > be > replaced with dma_alloc_coherent ? I was trying to replace _pa() Why keep allocating and freeing a buffer rather than having a single buffer allocated once (as it is in the old driver). Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: atomisp: gc0310: constify acpi_device_id.
On Thu, 2017-07-06 at 21:50 +0530, Arvind Yadav wrote:
> acpi_device_id are not supposed to change at runtime. All functions
> working with acpi_device_id provided by work with
> const acpi_device_id. So mark the non-const structs as const.
>
> File size before:
> text data bss dec hex
> filename
> 10297 1888 0 12185 2f99
> drivers/staging/media/atomisp/i2c/gc0310.o
>
> File size After adding 'const':
> text data bss dec hex
> filename
> 10361 1824 0 12185 2f99
> drivers/staging/media/atomisp/i2c/gc0310.o
>
> Signed-off-by: Arvind Yadav
> ---
> drivers/staging/media/atomisp/i2c/gc0310.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
> b/drivers/staging/media/atomisp/i2c/gc0310.c
> index 1ec616a..c8162bb 100644
> --- a/drivers/staging/media/atomisp/i2c/gc0310.c
> +++ b/drivers/staging/media/atomisp/i2c/gc0310.c
> @@ -1453,7 +1453,7 @@ static int gc0310_probe(struct i2c_client
> *client,
> return ret;
> }
>
> -static struct acpi_device_id gc0310_acpi_match[] = {
> +static const struct acpi_device_id gc0310_acpi_match[] = {
> {"XXGC0310"},
> {},
> };
(All four)
Acked-by: Alan Cox
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: atomisp: replace kmalloc & memcpy with kmemdup
On Fri, 2017-07-07 at 17:20 +0530, Hari Prasath wrote: > kmemdup can be used to replace kmalloc followed by a memcpy.This was > pointed out by the coccinelle tool. And kstrdup could do the job even better I think ? Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export
On Sun, 09 Jul 2017 12:41:53 +0100 Okash Khawaja wrote: > On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote: > > Overall, the idea looks sane to me. Keeping userspace from opening a > > tty that the kernel has opened internally makes sense, hopefully > > userspace doesn't get too confused when that happens. I don't think we > > normally return -EBUSY from an open call, have you seen what happens > > with apps when you do this (like minicom?) > > > I tested this wil minincom, picocom and commands like "echo foo > > /dev/ttyS0". They all correctly report "Device or resource busy". > > I have addressed all the comments you made. I have also split the patch > into three. Following is summary of each. If the tty counts are being misreported then it would be better to fix the code to actually manage the counts properly. The core tty code is telling you that the tty is not in a valid state. While this is of itself a good API to have, the underlying reference miscounting ought IMHO to be fixed as well. Also you don't need a new TTY_KOPENED flag as far as I can see. All tty's have a usage count and active bit flags already. Use those. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch] staging: speakup: safely close tty
On Fri, 7 Jul 2017 20:13:01 +0100 Okash Khawaja wrote: > Speakup opens tty using tty_open_by_driver. When closing, it calls > tty_ldisc_release but doesn't close and remove the tty itself. As a > result, that tty cannot then be opened from user space. This patch calls > tty_release_struct which ensures that tty is safely removed and freed > up. It also calls tty_ldisc_release, so speakup doesn't need to call it. > > This patch also unregisters N_SPEAKUP. It is registered when a speakup > module is loaded. What happens if after you register it someone assigns that ldisc to another tty as well ? You should register the ldisc when the relevant module is initialized and release it only when the module is unloaded. That way the module ref counts will handle cases where someone uses the ldisc with something else. I'd also btw strongly recommend putting the ldisc and the speakup tty driver as different modules. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export
> When opening from kernel, we don't use file pointer. The count mismatch > is between tty->count and #fd's. So opening from kernel leads to #fd's > being less than tty->count. I thought this difference is relevant to > user-space opening of tty, and not to kernel opening of tty. Can you > suggest how to address this mismatch? Your kernel reference is the same as having a file open reference so I think this actually needs addressing in the maths. In other words count the number of kernel references and also add that into the test for check_tty_count (kernel references + #fds == count). I'd really like to keep this right because that check has a long history of catching really nasty race conditions in the tty code. The open/close/hangup code is really fragile so worth the debugability. > Ah may be I didn't notice the active bit. Is it one of the #defines in > tty.h? Can usage count and active bit be used to differentiate between > whether the tty was opened by kernel or user? It only tells you whether the port is currently active for some purpose, not which. If you still want to implement exclusivity between kernel and user then it needs another flag, but I think that flag should be in port->flags as it is a property of the physical interface. (Take a look at tty_port_open for example) Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch] staging: speakup: safely close tty
> spk_ttyio_initialise_ldisc is called separately for each module (e.g. > speakup_apollo, speakup_ltlk etc) when it is loaded. spk_ttyio_release > is also called separately for each module when it is unloaded. The ldisc > stays around until the last of the modules is unloaded. What guarantees that someone hasn't decided to set the ldisc on unrelated hardware to speakup (eg on a pty/tty pair). > > > > > I'd also btw strongly recommend putting the ldisc and the speakup tty > > driver as different modules. > Sure, that makes sense. I will do that following these patches. If the ldisc is just unregistered when the module implementing it is unloaded then the ref counts on the ldisc module should do everything needed if the above isn't correctly handled, and if it is will still be cleaner. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export
> Sure. I can fix the tty->count mismatch based on Alan's suggestion. However I > don't understand why the exclusivity flag should belong to tty_port and not > tty_struct. It will be good to know why. We are trying to move all the flags that we can and structs into the tty_port, except any that are used internally within the struct tty level code. The main reason for this is to make the object lifetimes and locking simpler - because the tty_port lasts for the time the hardware is present. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export
> The patch is untested but I can work on this if that fits in with the > plans for tty. I think this is the right direction. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: atomisp: use kvmalloc/kvzalloc
On Mon, 2017-08-07 at 21:44 +0800, Geliang Tang wrote: > Use kvmalloc()/kvzalloc() instead of atomisp_kernel_malloc() > /atomisp_kernel_zalloc(). > > Signed-off-by: Geliang Tang Definitely better now we have kvmalloc/kvzalloc. Thanks Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: usbip: convert usbip-host driver to usb_device_driver
On Thu, 23 Jan 2014, Valentina Manea wrote: > 1. The usbip_status file is no longer created for interface 0, but for > the whole device (such as > /sys/devices/pci:00/:00:01.2/usb1/1-1/usbip_status). > 2. Per interface information, such as interface class or protocol, is > no longer sent/received. Only device specific information is > transmitted. > 3. Since the driver was moved one level below in the USB architecture, > there is no need to bind/unbind each interface, just the device as a > whole. If you don't bind the interfaces, they will naturally bind to their normal drivers on the host. You probably don't want that to happen. (Although, at the moment, I don't see how you can prevent it.) Also, in your patch, stub_probe() calls usb_choose_configuration(). Shouldn't that be done by the client, since the client now has access to the entire device? Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Move DWC2 driver out of staging
On Fri, 31 Jan 2014, Stephen Warren wrote:
> This is due to the following code:
>
> static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd,
>struct usb_host_endpoint *ep)
> {
> struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> ...
> struct usb_device *udev;
> ...
> udev = to_usb_device(hsotg->dev);
> ...
> usb_settoggle(udev, epnum, is_out, 0);
> if (is_control)
> usb_settoggle(udev, epnum, !is_out, 0);
>
> The problem is that hsotg->dev is assigned as follows:
>
> static int dwc2_driver_probe(struct platform_device *dev)
> ...
> hsotg = devm_kzalloc(&dev->dev, sizeof(*hsotg), GFP_KERNEL);
> ...
> hsotg->dev = &dev->dev;
>
> As such, it's not legal to call to_usb_device() on it.
This clearly is a bug. I suspect the driver has other bugs too, such
as not holding the private lock over a large enough region.
> What ends up happening, simply due to memory allocation order, is that
> the memory writes inside usb_settoggle() end up setting the SDHCI struct
> platform_device's num_resources to 0, so that it's call to
> platform_get_resource() fails.
>
> With the DWC2 move patch reverted, some other random piece of memory is
> being corrupted, which just happens not to cause any visible problem.
> Likely it's some other struct platform_device that's already had its
> resources read by the time DWC2 probes and corrupts them.
>
> (Yes, this was hard to find!)
>
> I honestly can't see how to solve this myself, since the whole DWC2
> driver doesn't seem to have a struct usb_device * hanging around that we
> can stash somewhere for it to look up later. Perhaps someone more
> familiar with the USB stack can help with that.
The correct solution is to set
qh = ep->hcpriv;
udev = qh->udev;
However, the driver doesn't store udev in qh (dwc2_qh_init() should do
this, but it doesn't). In fact, the field doesn't even exist.
Alan Stern
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: goldfish: fix direct copy_to_user() from __iomem
On Sun, 2014-06-22 at 03:29 -0400, James A Shackleford wrote: > This patch allocates a few pages and performs an ioread8_rep() from the bus > address, which are then copied to userspace. This fixes the sparse warning: > > drivers/staging/goldfish/goldfish_audio.c:136:43: warning: incorrect type in > argument 2 (different address spaces) > drivers/staging/goldfish/goldfish_audio.c:136:43:expected void const *from > drivers/staging/goldfish/goldfish_audio.c:136:43:got char [noderef] > *read_buffer > > which was a result of performing a copy_to_user() directly from the bus > address > to the userspace, which can be unsafe across some architectures. Goldfish is a specific architecture. It shouldn't be doing direct xcopies like that - which is why the code is in staging but at the same time allocating a buffer each call and doing extra copies is not the right answer. It should be mapping the pages when they are first set up. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Status of RMI4 drivers?
On Fri, 2014-07-04 at 21:48 +0300, Kristina Martšenko wrote: > Hi, > > I'm going over some "older" drivers in the staging tree and wanted to > ask about cptm1217 and ste_rmi4. They've been in staging for three and a > half years now, waiting for the upstream Synaptics RMI4 drivers. From > what I understand, the RMI4 development is happening in the > synaptics-rmi4 branch of Dmitry's git tree. Does anyone have any idea > when the RMI4 code might be "ready" and get merged properly? How is that > going? I'd be quite happy to move cptm1217 out of staging, however its now been there so many years waiting the rumoured RMI4 driver that I don't have hardware to do any testing on it, so it would need to be a straight move. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: goldfish_audio.c: sparse warning of incorrect type
On Sun, 2014-08-31 at 13:02 -0700, Greg Kroah-Hartman wrote: > Adding Alan Cox, as he pushed this driver upstream... It's sort of a false positive. The existing code will work fine. Arguably all of this should be using the dma_ APIs. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on sep?
On Fri, 2014-07-25 at 20:17 +0300, Kristina Martšenko wrote: > On 23/06/14 23:32, Kristina Martšenko wrote: > > Hi Mark, > > > > I'm helping Greg do a bit of cleanup in the staging tree. I noticed that > > nobody seems to have worked towards moving sep out of staging in over a > > year. Are there any plans to clean it up and move it out soon? > > No response from Mark here. > > Alan, Jayant, either of you know what the status of the sep staging > driver is? I believe "works last time anyone checked". I don't think we have anyone officially working on the early Intel phone cpus for upstream any more. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on sep?
On Fri, 2014-07-25 at 21:54 -0700, Greg KH wrote: > On Fri, Jul 25, 2014 at 10:54:47PM +0100, Alan Cox wrote: > > On Fri, 2014-07-25 at 20:17 +0300, Kristina Martšenko wrote: > > > On 23/06/14 23:32, Kristina Martšenko wrote: > > > > Hi Mark, > > > > > > > > I'm helping Greg do a bit of cleanup in the staging tree. I noticed that > > > > nobody seems to have worked towards moving sep out of staging in over a > > > > year. Are there any plans to clean it up and move it out soon? > > > > > > No response from Mark here. > > > > > > Alan, Jayant, either of you know what the status of the sep staging > > > driver is? > > > > I believe "works last time anyone checked". I don't think we have anyone > > officially working on the early Intel phone cpus for upstream any more. > > So can we just drop it then? If no one is working on moving it out of > staging, it should go. Probably ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency
On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
wrote:
Hi Geert,
This essentially removes this commit
commit 1c8cb409491403036919dd1c6b45013dc8835a44
Author: Sudip Mukherjee
Date: Wed Aug 3 13:45:46 2016 -0700
drivers/fpga/Kconfig: fix build failure
While building m32r allmodconfig the build is failing with the error:
ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined!
Xilinx Zynq FPGA is using DMA but there was no dependency while
building.
Link:
http://lkml.kernel.org/r/1464346526-13913-1-git-send-email-sudipm.mukher...@gmail.com
Signed-off-by: Sudip Mukherjee
Acked-by: Moritz Fischer
Cc: Alan Tull
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Alan
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Mark Brown
> Acked-by: Robin Murphy
> ---
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/fpga/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index f47ef848bcd056d5..fd539132542e30ee 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP
> config FPGA_MGR_ZYNQ_FPGA
> tristate "Xilinx Zynq FPGA"
> depends on ARCH_ZYNQ || COMPILE_TEST
> - depends on HAS_DMA
> help
> FPGA manager driver support for Xilinx Zynq FPGAs.
>
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency
On Tue, Mar 20, 2018 at 5:04 AM, Geert Uytterhoeven
wrote:
Hi Geert,
> Hi Alan,
>
> On Mon, Mar 19, 2018 at 5:06 PM, Alan Tull wrote:
>> On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
>> wrote:
>> This essentially removes this commit
>>
>> commit 1c8cb409491403036919dd1c6b45013dc8835a44
>> Author: Sudip Mukherjee
>> Date: Wed Aug 3 13:45:46 2016 -0700
>>
>> drivers/fpga/Kconfig: fix build failure
>>
>> While building m32r allmodconfig the build is failing with the error:
>>
>> ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined!
>>
>> Xilinx Zynq FPGA is using DMA but there was no dependency while
>> building.
>>
>> Link:
>> http://lkml.kernel.org/r/1464346526-13913-1-git-send-email-sudipm.mukher...@gmail.com
>> Signed-off-by: Sudip Mukherjee
>> Acked-by: Moritz Fischer
>> Cc: Alan Tull
>> Signed-off-by: Andrew Morton
>> Signed-off-by: Linus Torvalds
>
> Yes it does. The major change is that the first (core) series introduces
> all needed dummies to do successful compile-testing on NO_DMA=y platforms.
OK yes, I looked at the first patch that does the fix. Looks good.
Thanks for doing this.
>
>>> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
>>> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
>>> In most cases this other symbol is an architecture or platform specific
>>> symbol, or PCI.
>>>
>>> Generic symbols and drivers without platform dependencies keep their
>>> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
>>> cannot work anyway.
>>>
>>> This simplifies the dependencies, and allows to improve compile-testing.
>>>
>>> Signed-off-by: Geert Uytterhoeven
>>> Reviewed-by: Mark Brown
>>> Acked-by: Robin Murphy
Acked-by: Alan Tull
Regards,
Alan
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ozwpan: Convert printk to dev_dbg()
On Tue, 25 Jun 2013, Rupesh Gujare wrote: > On 25/06/13 18:02, Greg KH wrote: > > On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote: > >> convert all debug messages from printk to dev_dbg() & add kernel config to > >> enable/disable these messages during compilation. > > No, just use the built-in dynamic debug code in the kernel, no need to > > provide any new macros or functions or most importantly, no new Kconfig > > options. > > > > New macro (oz_trace) is being used as pointer to "struct device *" is > not available in all functions for dev_dbg() function. > Please let me know if there is better way to handle this, I will be > happy to rework on this. It depends on the situation. In many cases there _is_ a struct device associated with the log message, even if a pointer to that device isn't available in the function. The proper solution in those cases is to make it available, by passing the function an extra "struct device *" argument. In a few cases there really is no device associated with the message. For example, if the module prints out a message when it is first loaded, there probably is no device around at that time. However, in most cases there _is_ an associated device. Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
On Thu, 19 Sep 2013, Russell King wrote: > The correct way for a driver to specify the coherent DMA mask is > not to directly access the field in the struct device, but to use > dma_set_coherent_mask(). Only arch and bus code should access this > member directly. > > Convert all direct write accesses to using the correct API. > > Signed-off-by: Russell King > diff --git a/drivers/usb/host/ehci-platform.c > b/drivers/usb/host/ehci-platform.c > index f6b790c..5b0cd2d 100644 > --- a/drivers/usb/host/ehci-platform.c > +++ b/drivers/usb/host/ehci-platform.c > @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device *dev) > dev->dev.platform_data = &ehci_platform_defaults; > if (!dev->dev.dma_mask) > dev->dev.dma_mask = &dev->dev.coherent_dma_mask; > - if (!dev->dev.coherent_dma_mask) > - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + err = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32)); > + if (err) > + return err; > > pdata = dev_get_platdata(&dev->dev); ehci-platform.c is a generic file, intended for use by multiple platforms. Is it not possible that on some platforms, the arch or bus code may already have initialized the DMA masks? Isn't something like this (i.e., DMA bindings) planned for Device Tree? By eliminating the tests above and calling dma_set_coherent_mask or dma_coerce_mask_and_coherent unconditionally, this patch (and the next) would overwrite those initial settings. I don't know to what extent the same may be true for the other, platform-specific, drivers changed by this patch. But it's something to be aware of. Alan Stern ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] usb: Improves USB2.0 write performance
On Tue, Aug 30, 2022 at 04:43:25PM +0800, Hu Xiaoying wrote: > USB external storage device(0x0b05:1932), use gnome-disk-utility tools > to test usb write < 30MB/s. if does not to load module of uas for this device > , can increase the write speed from 20MB/s to more than 40MB/s. > > Signed-off-by: Hu Xiaoying This email address "@gmail.com" is different from the address you used when you submitted the patch "@kylinos.cn". The two addresses must be the same. > --- You should put here (just after the "---" line) a description of how this patch version is different from all the earlier versions. Do that and submit it as [PATCH v4], and make sure you explain how it is different from versions 1, 2, and 3. There are lots of examples of patches like this in the mailing list archives. Look at some of them to see what they do. Alan Stern > drivers/usb/storage/unusual_uas.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/storage/unusual_uas.h > b/drivers/usb/storage/unusual_uas.h > index 4051c8cd0cd8..3925c7c67915 100644 > --- a/drivers/usb/storage/unusual_uas.h > +++ b/drivers/usb/storage/unusual_uas.h > @@ -62,6 +62,13 @@ UNUSUAL_DEV(0x0984, 0x0301, 0x0128, 0x0128, > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_IGNORE_UAS), > > +/* Reported-by: Tom Hu */ > +UNUSUAL_DEV(0x0b05, 0x1932, 0x, 0x, > + "ASUS", > + "External HDD", > + USB_SC_DEVICE, USB_PR_DEVICE, NULL, > + US_FL_IGNORE_UAS), > + > /* Reported-by: David Webb */ > UNUSUAL_DEV(0x0bc2, 0x331a, 0x, 0x, > "Seagate", > -- > 2.25.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Odlitky-pořádek
Dobré ráno, Hledám firmy, které jsou ochotné uvažovat o změně dodavatele nabízejícího hliníkové tlakové odlitky. Garantujeme opakovatelnou kvalitu detailů s nízkou drsností povrchu a vysokou odolností proti korozi. Výrobky chráníme pasivačním povlakem na bázi chemie Surtec 650 v plně automatizovaném procesu ponoru. Detaily práškově lakujeme na robotické lince od renomované švýcarské firmy. Pokud vidíte příležitost ke spolupráci, kontaktujte mě. Alan Beran ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Why did you authorized Mrs. Lyndia Paulson to receive your funds $4.800.000 us dollars from this office?,
MONEY GRAM. AROPORT INTL DE COTONOU COTONOU. Office of Mrs. ALAN UDE. Attn,Dear Funds beneficiary. I am Mrs. ALAN UDE., Official Director.Money Gram-Benin Confirm to us urgent, Why did you authorized Mrs. Lyndia Paulson to receive your funds $4.800.000 us dollars from this office?, I need your urgent response now because this woman contacted us again this morning with all her mailing address stating that you are very ill, meanwhile you have advised her to claim the funds on your behalf, i am real confuse now, and i need to hear from you urgent before our office will release your transfer to this woman, Here is the address she forward to us this morning where your funds will be transfer to her.Please do you know this address? Full name, Mrs. Lyndia Paulson Address. 21644 Vaca Dr. Eckert Colorado 81418 Country. USA Also i want you to know that we have cut down the transfer fees to $23.00 only for your help, to enable you afford it, this is because we need all our real customers to receive their funds before the end of this year 2019, due after this physical year 2019, all remaining and unclaimed funds in our office will be cancelled, so you are advised to try and send the remaining $23.00 today so that you can pick up your first $US5000.00 immediately today, I promise you with all of my life, no more fees, this $23.00 is the last fee you will pay to receive your transfer now, once i receive it, you must pick up first $US5000.00 at your Money Gram today, and i will send you another US$5000.00 tomorrow morning, i just plan to make sure that you receive at least $100,000.00 US Dollars before the Christmas day, to enable you celebrate a good Christmas with your family. Note Iam only here to help you out and make sure you did not lose your transfer total amount of $4.8m us dollars to Mrs. Lyndia Paulson ok. So try and send the $23.00 today once you receive this email ok. God bless you, it is your time to rejoice and be happy forever. Send the transfer fee $23.00 to us by Money Gram. Receiver's Name----Alan Ude Country--Benin City address-Cotonou Amount--23.00 dollars Only Text Question-Honest Answer-Trust Thanks I wait for your urgent response Mrs. ALAN UDE., Official Director.Money Gram-Benin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
