[PATCH] staging: speakup: One function call less in speakup_win_enable()
From: Markus Elfring
Date: Sat, 6 Jul 2019 10:03:56 +0200
Avoid an extra function call by using a ternary operator instead of
a conditional statement.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/staging/speakup/main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 488f2539aa9a..03bbc9a4dbb3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1917,10 +1917,9 @@ static void speakup_win_enable(struct vc_data *vc)
return;
}
win_enabled ^= 1;
- if (win_enabled)
- synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCED));
- else
- synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCE_DISABLED));
+ synth_printf("%s\n", spk_msg_get(win_enabled
+? MSG_WINDOW_SILENCED
+: MSG_WINDOW_SILENCE_DISABLED));
}
static void speakup_bits(struct vc_data *vc)
--
2.22.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: octeon: One function call less in cvm_oct_common_set_multicast_list()
From: Markus Elfring Date: Sat, 6 Jul 2019 10:48:23 +0200 Avoid an extra function call by using a ternary operator instead of a conditional statement. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/staging/octeon/ethernet.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 8847a11c212f..93f127a0b287 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -337,13 +337,8 @@ static void cvm_oct_common_set_multicast_list(struct net_device *dev) cvmx_write_csr(CVMX_GMXX_RXX_ADR_CTL(index, interface), control.u64); - if (dev->flags & IFF_PROMISC) - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 0); - else - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 1); - + cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN(index, interface), + dev->flags & IFF_PROMISC ? 0 : 1); cvmx_write_csr(CVMX_GMXX_PRTX_CFG(index, interface), gmx_cfg.u64); } -- 2.22.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: octeon: One function call less in cvm_oct_common_set_multicast_list()
From: Markus Elfring Date: Sat, 6 Jul 2019 10:48:23 +0200 Avoid an extra function call by using a ternary operator instead of a conditional statement. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/staging/octeon/ethernet.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 8847a11c212f..93f127a0b287 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -337,13 +337,8 @@ static void cvm_oct_common_set_multicast_list(struct net_device *dev) cvmx_write_csr(CVMX_GMXX_RXX_ADR_CTL(index, interface), control.u64); - if (dev->flags & IFF_PROMISC) - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 0); - else - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 1); - + cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN(index, interface), + dev->flags & IFF_PROMISC ? 0 : 1); cvmx_write_csr(CVMX_GMXX_PRTX_CFG(index, interface), gmx_cfg.u64); } -- 2.22.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues
Hi Brett, On Fri, Jul 5, 2019 at 8:44 PM Brett Neumeier wrote: > > On Wed, Jun 26, 2019 at 7:45 AM Sergio Paracuellos > wrote: > > No problem, I also miss them rewritting code. That is bad :((. > > > BTW, I applied that on top of your other recent fixes (that ones > > > you pushed to gregkh for staging). So I tested with the > > > updated GPIO reset code. > > Ok, anyway.. I have just sent the change jus to have the same code behaviour > > that was being there before. > > FWIW, I have the same results as Greg -- the 4.2 driver works every > time, staging-next frequently hangs. I see, thanks for letting me know. We have to figure out what is wrong and why we don't get an stable pci link. > > Out of curiosity, if it's not too complex an answer to go into, what's > the benefit of the staging-next driver? Is there a reason to prefer it > to the 4.2 driver? In terms of stability, the driver which is in staging-next now is not always working as expected, so I really apologize for that because main changes have been done by myself. In the other hand, you have to think what is staging tree for. Staging contains drivers that are not ready to be properly mainlined into the "real" tree because they are not clean enough, the use old apis and so on. The idea of staging is to have a temporal place to properly clean drivers in order to get them properly added into the official mainline tree and directories. Doing that it will always be supported in the kernel and it won't be deleted for the tree. The mt7621 pci driver is now clean enough to give it a try to be mainlined but we have to achieve the problem of pci link stability that sometimes gets the driver to hang. Again, sorry for the inconvenience and any debug traces searching for the problem, ideas or patches repairing the current problem are very welcome. I don't have hardware to test my changes on, so it is a bit difficult for me to help more in these days. Hope this helps. Best regards, Sergio Paracuellos > > -- > Brett Neumeier (bneume...@gmail.com) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: One function call less in speakup_win_enable()
Markus Elfring, le sam. 06 juil. 2019 10:15:30 +0200, a ecrit:
> From: Markus Elfring
> Date: Sat, 6 Jul 2019 10:03:56 +0200
>
> Avoid an extra function call by using a ternary operator instead of
> a conditional statement.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Reviewed-by: Samuel Thibault
> ---
> drivers/staging/speakup/main.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 488f2539aa9a..03bbc9a4dbb3 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1917,10 +1917,9 @@ static void speakup_win_enable(struct vc_data *vc)
> return;
> }
> win_enabled ^= 1;
> - if (win_enabled)
> - synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCED));
> - else
> - synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCE_DISABLED));
> + synth_printf("%s\n", spk_msg_get(win_enabled
> + ? MSG_WINDOW_SILENCED
> + : MSG_WINDOW_SILENCE_DISABLED));
> }
>
> static void speakup_bits(struct vc_data *vc)
> --
> 2.22.0
>
--
Samuel
--- christ gives channel operator status to Dieu
-+- #ens-mim and hell -+-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: One function call less in speakup_win_enable()
On Sat, Jul 06, 2019 at 11:00:19AM +0200, Samuel Thibault wrote: > Markus Elfring, le sam. 06 juil. 2019 10:15:30 +0200, a ecrit: > > From: Markus Elfring > > Date: Sat, 6 Jul 2019 10:03:56 +0200 > > > > Avoid an extra function call by using a ternary operator instead of > > a conditional statement. > > > > This issue was detected by using the Coccinelle software. > > > > Signed-off-by: Markus Elfring > > Reviewed-by: Samuel Thibault Sorry, but this author/bot is in my kill-file and I no longer accept patches from them. And I HATE ternary operators anyway, so it's not like I would take this patch if it came from someone else :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/7] staging: most: Use spinlock_t instead of struct spinlock
On Thu, Jul 04, 2019 at 05:38:00PM +0200, Sebastian Andrzej Siewior wrote: > For spinlocks the type spinlock_t should be used instead of "struct > spinlock". Why? > Use spinlock_t for spinlock's definition. Why? I agree it makes the code smaller, but why is this required? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-pci: Fix compiler error 'slot' may be used uninitialized
Hi René,
On Fri, Jul 5, 2019 at 10:35 PM René van Dorst wrote:
>
> In commit 802a2f7b2fe3 ("staging: mt7621-pci: factor out
> 'mt7621_pcie_enable_port' function"), slot = port->slot; line was removed.
> Also other dev_err() print parameter was changed from slot to port->slot.
> So the same should be done here.
>
> This also fixes compiler error:
> drivers/staging/mt7621-pci/pci-mt7621.c: In function 'mt7621_pci_probe':
> ./include/linux/device.h:1490:2: warning: 'slot' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> _dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
> ^
> drivers/staging/mt7621-pci/pci-mt7621.c:504:6: note: 'slot' was declared here
> u32 slot;
> ^~~~
>
> Fixes: 802a2f7b2fe3 ("staging: mt7621-pci: factor out
> 'mt7621_pcie_enable_port' function")
> Signed-off-by: René van Dorst
> ---
> drivers/staging/mt7621-pci/pci-mt7621.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
> b/drivers/staging/mt7621-pci/pci-mt7621.c
> index 03d919a94552..81600c03cae1 100644
> --- a/drivers/staging/mt7621-pci/pci-mt7621.c
> +++ b/drivers/staging/mt7621-pci/pci-mt7621.c
> @@ -511,7 +511,7 @@ static void mt7621_pcie_enable_ports(struct mt7621_pcie
> *pcie)
> port->slot);
> continue;
> }
> - dev_info(dev, "PCIE%d enabled\n", slot);
> + dev_info(dev, "PCIE%d enabled\n", port->slot);
> num_slots_enabled++;
> }
> }
> --
> 2.20.1
>
I don't know what tree and branch are you using for this but this is
kind of old code... You should
use staging git tree, 'staging-next' branch for staging patches to
avoid problems like this.
Best regards,
Sergio Paracuellos
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-pci: Fix compiler error 'slot' may be used uninitialized
Quoting Sergio Paracuellos :
Hi Sergio,
Hi René,
On Fri, Jul 5, 2019 at 10:35 PM René van Dorst wrote:
In commit 802a2f7b2fe3 ("staging: mt7621-pci: factor out
'mt7621_pcie_enable_port' function"), slot = port->slot; line was removed.
Also other dev_err() print parameter was changed from slot to port->slot.
So the same should be done here.
This also fixes compiler error:
drivers/staging/mt7621-pci/pci-mt7621.c: In function 'mt7621_pci_probe':
./include/linux/device.h:1490:2: warning: 'slot' may be used
uninitialized in this function [-Wmaybe-uninitialized]
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
^
drivers/staging/mt7621-pci/pci-mt7621.c:504:6: note: 'slot' was
declared here
u32 slot;
^~~~
Fixes: 802a2f7b2fe3 ("staging: mt7621-pci: factor out
'mt7621_pcie_enable_port' function")
Signed-off-by: René van Dorst
---
drivers/staging/mt7621-pci/pci-mt7621.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 03d919a94552..81600c03cae1 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -511,7 +511,7 @@ static void mt7621_pcie_enable_ports(struct
mt7621_pcie *pcie)
port->slot);
continue;
}
- dev_info(dev, "PCIE%d enabled\n", slot);
+ dev_info(dev, "PCIE%d enabled\n", port->slot);
num_slots_enabled++;
}
}
--
2.20.1
I don't know what tree and branch are you using for this but this is
kind of old code... You should
use staging git tree, 'staging-next' branch for staging patches to
avoid problems like this.
I am using net-next tree for my mt7621 ethernet development.
So I see this warning a lot.
I didn't know about the staging-next branch.
I think I only checked the master branch.
I see now that the pci driver has changed a lot.
Sorry for the noise.
Greats,
René
Best regards,
Sergio Paracuellos
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues
On Sat, Jul 6, 2019 at 4:00 AM Sergio Paracuellos wrote: > > Out of curiosity, if it's not too complex an answer to go into, what's > > the benefit of the staging-next driver? Is there a reason to prefer it > > to the 4.2 driver? > > In terms of stability, the driver which is in staging-next now is not > always working as expected, > so I really apologize for that because main changes have been done by > myself. In the other hand, > you have to think what is staging tree for. Staging contains drivers > that are not ready to be properly > mainlined into the "real" tree because they are not clean enough, the > use old apis and so on. The idea > of staging is to have a temporal place to properly clean drivers in > order to get them properly added into > the official mainline tree and directories. Doing that it will always > be supported in the kernel and it won't be > deleted for the tree. The mt7621 pci driver is now clean enough to > give it a try to be mainlined but we have to > achieve the problem of pci link stability that sometimes gets the > driver to hang. I'm sorry, I think my question was unclear! I am not complaining about the instability introduced in the current driver. I understand that dealing with hardware is complicated and sometimes things are broken for a while -- especially in staging or experimental drivers. That doesn't bother me! I am curious, though, about the motivation for this change -- obviously there must be some reason you rewrote the driver, but it's not at all clear to me. I see that with the staging driver it looks like maybe the 4.20 driver was split into the PCI controller driver and a separate PCI PHY driver? If that's the main architectural change, what's better about splitting them up that way? Again, I understand that sometimes a question sounds really simple but the answer is long and involved, and I don't want to take up a lot of your time or energy. So if it is more complicated than a thirty-second explanation, that's cool. -- Brett Neumeier (bneume...@gmail.com) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-pci: Handle minor issues
Hi Brett, On Sat, Jul 6, 2019 at 3:43 PM Brett Neumeier wrote: > > On Sat, Jul 6, 2019 at 4:00 AM Sergio Paracuellos > wrote: > > > Out of curiosity, if it's not too complex an answer to go into, what's > > > the benefit of the staging-next driver? Is there a reason to prefer it > > > to the 4.2 driver? > > > > In terms of stability, the driver which is in staging-next now is not > > always working as expected, > > so I really apologize for that because main changes have been done by > > myself. In the other hand, > > you have to think what is staging tree for. Staging contains drivers > > that are not ready to be properly > > mainlined into the "real" tree because they are not clean enough, the > > use old apis and so on. The idea > > of staging is to have a temporal place to properly clean drivers in > > order to get them properly added into > > the official mainline tree and directories. Doing that it will always > > be supported in the kernel and it won't be > > deleted for the tree. The mt7621 pci driver is now clean enough to > > give it a try to be mainlined but we have to > > achieve the problem of pci link stability that sometimes gets the > > driver to hang. > > I'm sorry, I think my question was unclear! I am not complaining about > the instability introduced in the current driver. I understand that > dealing with hardware is complicated and sometimes things are broken > for a while -- especially in staging or experimental drivers. That > doesn't bother me! > > I am curious, though, about the motivation for this change -- > obviously there must be some reason you rewrote the driver, but it's > not at all clear to me. The original driver was using legacy pci code, the 4.20 version also have a lot of changes in order to use current generic pci apis which is the way to go. Just looking at the code, you can see real differences with readability and maintainability. Those two are really important. Or at least for me they are :) > I see that with the staging driver it looks > like maybe the 4.20 driver was split into the PCI controller driver > and a separate PCI PHY driver? If that's the main architectural > change, what's better about splitting them up that way? Well, it really depends of the hardware. In this case in order to get a chance to be properly mainlined (which is the main reason for making changes in a staging driver and should be the final aim) pci phy part and pci host controller driver seems neccessary because of how mt7621 SoC is described. There are not the only changes comparing it with the 4.20 version. With current staging version, all is properly described using device tree instead of having hardcoded stuff which is not clean at all (reset lines, phy, hw resources...),. The only thing is not clear yet is that we are using pci clocks for the RC and ports because there is not a "ralink" clock gate driver and other similar drivers directly access to registers without using a custom clock driver for that. And another important thing for making this changes is because it is fun and you learn a lot in the way :)) > > Again, I understand that sometimes a question sounds really simple but > the answer is long and involved, and I don't want to take up a lot of > your time or energy. So if it is more complicated than a thirty-second > explanation, that's cool. No problem at all :) No time / energy consuming. I think if you are curious is always better to ask :-). Best regards, Sergio Paracuellos > > -- > Brett Neumeier (bneume...@gmail.com) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Staging status of speakup
On Fri, 15 Mar 2019 20:18:31 -0700 Greg Kroah-Hartman wrote: > On Fri, Mar 15, 2019 at 01:01:27PM +, Okash Khawaja wrote: > > Hi, > > > > We have made progress on the items in TODO file of speakup driver in > > staging directory and wanted to get some clarity on the remaining > > items. Below is a summary of status of each item along with the > > quotes from TODO file. > > > > 1. "The first issue has to do with the way speakup communicates > > with serial ports. Currently, we communicate directly with the > > hardware ports. This however conflicts with the standard serial > > port drivers, which poses various problems. This is also not > > working for modern hardware such as PCI-based serial ports. Also, > > there is not a way we can communicate with USB devices. The > > current serial port handling code is in serialio.c in this > > directory." > > > > Drivers for all external synths now use TTY to communcate with the > > devices. Only ones still using direct communication with hardware > > ports are internal synths: acntpc, decpc, dtlk and keypc. These are > > typically ISA cards and generally hardware which is difficult to > > make work. We can leave these in staging. > > Ok, that's fine. > > > 2. "Some places are currently using in_atomic() because speakup > > functions are called in various contexts, and a couple of things > > can't happen in these cases. Pushing work to some worker thread > > would probably help, as was already done for the serial port > > driving part." > > > > There aren't any uses of in_atomic anymore. Commit d7500135802c > > "Staging: speakup: Move pasting into a work item" was the last one > > that removed such uses. > > Great, let's remove that todo item then. > > > 3. "There is a duplication of the selection functions in > > selections.c. These functions should get exported from > > drivers/char/selection.c (clear_selection notably) and used from > > there instead." > > > > This is yet to be done. I guess drivers/char/selection.c is now > > under drivers/tty/vt/selection.c. > > Yes, someone should update the todo item :) > > > 4. "The kobjects may have to move to a more proper place in /sys.The > > discussion on lkml resulted to putting speech synthesizers in the > > "speech" class, and the speakup screen reader itself > > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being > > handled by userland tools." > > > > Although this makes logical sense, the change will mean changing > > interface with userspace and hence the user space tools. I tried to > > search the lkml discussion but couldn't find it. It will be good to > > know your thoughts on this. > > I don't remember, sorry. I can review the kobject/sysfs usage if you > think it is "good enough" now and see if I find anything > objectionable. > > > 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. > > > > In addition to above, there are likely code style issues which will > > need to be fixed. > > > > We are very keen to get speakup out of staging both, for settling > > the driver but also for getting included in distros which build > > only the mainline drivers. > > That's great, I am glad to see this happen. How about work on the > selection thing and then I can review the kobject stuff in a few > weeks, and then we can start moving things for 5.2? Hi Greg, Apologies for the delay. I de-duplicated selection code in speakup to use code that's already in kernel (commit ids 496124e5e16e and 41f13084506a). Following items are what remain now: 1. moving kobjects location 2. fixing garbled text I couldn't replicate garbled text but Simon (also in CC list) is looking into it. Can you please advise on the way forward? Thanks, Okash ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/7] staging: most: Use spinlock_t instead of struct spinlock
On 2019-07-06 12:02:53 [+0200], Greg Kroah-Hartman wrote:
> On Thu, Jul 04, 2019 at 05:38:00PM +0200, Sebastian Andrzej Siewior wrote:
> > For spinlocks the type spinlock_t should be used instead of "struct
> > spinlock".
>
> Why?
>
> > Use spinlock_t for spinlock's definition.
>
> Why? I agree it makes the code smaller, but why is this required?
I remember PeterZ pointing out to stick to the typedef and it is
probably better to stick with the typdef since we have it. It was like
that since it was first introduced (2.1.25 for i386).
We have a checkpatch warning for that [0].
This series has only 7 patches (excluding the powerpc bits) so almost
everyone else is using just the typdef.
[0] 88982fea52d01 ("checkpatch: warn when declaring "struct spinlock foo;"")
from Dec 2012
> thanks,
>
> greg k-h
Sebastian
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Staging status of speakup
On Sat, Jul 06, 2019 at 08:08:57PM +0100, Okash Khawaja wrote: > On Fri, 15 Mar 2019 20:18:31 -0700 > Greg Kroah-Hartman wrote: > > > On Fri, Mar 15, 2019 at 01:01:27PM +, Okash Khawaja wrote: > > > Hi, > > > > > > We have made progress on the items in TODO file of speakup driver in > > > staging directory and wanted to get some clarity on the remaining > > > items. Below is a summary of status of each item along with the > > > quotes from TODO file. > > > > > > 1. "The first issue has to do with the way speakup communicates > > > with serial ports. Currently, we communicate directly with the > > > hardware ports. This however conflicts with the standard serial > > > port drivers, which poses various problems. This is also not > > > working for modern hardware such as PCI-based serial ports. Also, > > > there is not a way we can communicate with USB devices. The > > > current serial port handling code is in serialio.c in this > > > directory." > > > > > > Drivers for all external synths now use TTY to communcate with the > > > devices. Only ones still using direct communication with hardware > > > ports are internal synths: acntpc, decpc, dtlk and keypc. These are > > > typically ISA cards and generally hardware which is difficult to > > > make work. We can leave these in staging. > > > > Ok, that's fine. > > > > > 2. "Some places are currently using in_atomic() because speakup > > > functions are called in various contexts, and a couple of things > > > can't happen in these cases. Pushing work to some worker thread > > > would probably help, as was already done for the serial port > > > driving part." > > > > > > There aren't any uses of in_atomic anymore. Commit d7500135802c > > > "Staging: speakup: Move pasting into a work item" was the last one > > > that removed such uses. > > > > Great, let's remove that todo item then. > > > > > 3. "There is a duplication of the selection functions in > > > selections.c. These functions should get exported from > > > drivers/char/selection.c (clear_selection notably) and used from > > > there instead." > > > > > > This is yet to be done. I guess drivers/char/selection.c is now > > > under drivers/tty/vt/selection.c. > > > > Yes, someone should update the todo item :) > > > > > 4. "The kobjects may have to move to a more proper place in /sys.The > > > discussion on lkml resulted to putting speech synthesizers in the > > > "speech" class, and the speakup screen reader itself > > > into /sys/class/vtconsole/vtcon0/speakup, the nasty path being > > > handled by userland tools." > > > > > > Although this makes logical sense, the change will mean changing > > > interface with userspace and hence the user space tools. I tried to > > > search the lkml discussion but couldn't find it. It will be good to > > > know your thoughts on this. > > > > I don't remember, sorry. I can review the kobject/sysfs usage if you > > think it is "good enough" now and see if I find anything > > objectionable. > > > > > 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. > > > > > > In addition to above, there are likely code style issues which will > > > need to be fixed. > > > > > > We are very keen to get speakup out of staging both, for settling > > > the driver but also for getting included in distros which build > > > only the mainline drivers. > > > > That's great, I am glad to see this happen. How about work on the > > selection thing and then I can review the kobject stuff in a few > > weeks, and then we can start moving things for 5.2? > > Hi Greg, > > Apologies for the delay. I de-duplicated selection code in speakup to > use code that's already in kernel (commit ids 496124e5e16e and > 41f13084506a). Following items are what remain now: > > 1. moving kobjects location > 2. fixing garbled text > > I couldn't replicate garbled text but Simon (also in CC list) is > looking into it. > > Can you please advise on the way forward? I don't think the "garbled text" is an issue to get this out of staging if others do not see this. It can be fixed like any other bug at a later point if it is figured out. The kobject stuff does need to be looked at. Let me carve out some time next week to do that and I will let you know what I see/recommend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
