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 th
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
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 t
> --- 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
> 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
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://d
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
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
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
> 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 w
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: fi
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
> 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-de
> 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 tha
> 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
> 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
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 e
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 to
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...@lin
}
>
> -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
> 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
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 enumer
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
_
> > 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
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 d
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 cha
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:
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;
> > > +
> + 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
> 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
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 e
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 IS
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
> > 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
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 */
> ^~
> 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
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 th
> + 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
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
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
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...@l
> 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
___
> 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 whe
> > 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 i
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,
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).
No
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 u
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 t
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
___
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_aud
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
_
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,
> > > >
&g
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
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 u
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 i
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
56 matches
Mail list logo
